UMTS Access Performance Optimization Gui

UMTS Access Performance
Optimization Guide
R1.0
UMTS Access Performance Optimization Guide Internal Use Only▲
LEGAL INFORMATION
By accepting this certain document of ZTE CORPORATIN you agree to the following terms. If you do
not agree to the following terms, please notice that you are not allowed to use this document.
Copyright © 2009 ZTE CORPORATION. Any rights not expressly granted herein are reserved. This
document contains proprietary information of ZTE CORPORATION. Any reproduction, transfer,
distribution, use or disclosure of this document or any portion of this document, in any form by any
means, without the prior written consent of ZTE CORPORATION is prohibited.
and are registered trademarks of ZTE CORPORATION. ZTE’s company name, logo
and product names referenced herein are either trademarks or registered trademarks of ZTE
CORPORATION. Other product and company names mentioned herein may be trademarks or trade
names of their respective owners. Without the prior written consent of ZTE CORPORATION or the
third party owner thereof, anyone’s access to this document should not be construed as granting,
by implication, estopped or otherwise, any license or right to use any marks appearing in the
document.
The design of this product complies with requirements of environmental protection and personal
security. This product shall be stored, used or discarded in accordance with product manual,
relevant contract or laws and regulations in relevant country (countries).
This document is provided “as is” and “as available”. Information contained in this document is
subject to continuous update without further notice due to improvement and update of ZTE
CORPORATION’s products and technologies.
ZTE CORPORATION
Address: NO. 55
Hi-tech Road South
ShenZhen
P.R.China
518057
Website: http://support.zte.com.cn
Email: doc@zte.com.cn
ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. I

Revision History
Product Version Document Version Serial Number Reason for Revision

V1.0 First published
Author
Prepared
Date Document Version Reviewed by Approved by
by
2010-07-09 R1.0 Liu
Wang Zhenhai Jin Zhengtuan
Jingyuan
ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. II

About This Document
Summary
Chapter Description
Brief introduction to access
1 Overview
performance optimization
Major measuring standards of
2 Evaluation Standards of Access Performance
access performance
Analysis of the key parts
3 Key Points Analysis of Access Performance Optimization concerning access performance
optimization
UMTS network access performance
4 Access Performance Optimization Through Daily Tests and
optimization based on DT, CQT and
Traffic Statistics
traffic statistics
Common access problems and
5 Access Performance Optimization Cases
solutions based on concrete cases
ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. III
TABLE OF CONTENTS
1 Overview...........................................................................................................1
2 Evaluation Standards of Access Performance..............................................3

2.1 System Accessibility...........................................................................................3
2.1.1 DT Testing Indicators of Accessibility.................................................................3
2.1.2 Traffic Statistical Testing Indicators of Availability...............................................3
2.2 System Access Delay........................................................................................4
3 Key Points Analysis of Access Performance Optimization..........................5

3.1 Access Failure...................................................................................................5
3.1.1 Analysis Process of Access Failure....................................................................5
3.1.2 Basic Checking and Analysis of Access Failure.................................................5
3.2 Low Access Success Rate...............................................................................14
3.2.1 Radio Parameter Configuration........................................................................14
3.3 Paging Delay...................................................................................................19
3.3.1 CS Paging Delay Process Analysis..................................................................19
3.3.2 PS Paging Setup Process Analysis..................................................................24
3.3.3 Methods to Reduce Paging Delay....................................................................26
4 Access Performance Optimization Through Daily Tests and Traffic

Statistics 28
4.1 Access Performance Analysis Through DT/CQT Test Data..............................28
4.1.1 Access Failure Defined by CNT/CNA...............................................................28
4.1.2 Categories of CS Originating Call Failures.......................................................28
4.1.3 Categories of CS Terminating Call Failures......................................................29
4.1.4 Categories of PS Access Failures....................................................................29
4.1.5 Analysis Procedure for Access Failure Discovered in DT/CQT........................30
4.2 Access Performance Analysis Through Traffic Statistic Data...........................49
4.2.1 General Methods to Analyze Traffic Statistic Data............................................50
4.2.2 Access Indexes Should be Analyzed During Traffic Statistics..........................51
5 Access Performance Optimization Cases....................................................67

5.1 UE Access Failure Caused by Incorrect Configured Cell Radius.....................67
5.1.1 Phenomenon...................................................................................................67
5.1.2 Analysis........................................................................................................... 67
5.1.3 Result............................................................................................................... 68
5.2 Case Study – CS Access Delay.......................................................................68
5.3 Case Study – PS Access Delay.......................................................................69
ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. IV

FIGURES
Figure 3-1 Access failure analysis process.............................................................................5

Figure 3-2 Checking whether the cell is barred in OMC-R....................................................12
Figure 3-3 Checking whether the cell is barred in OMC-R....................................................13
Figure 4-1 Analysis flow for access failures..........................................................................31
Figure 4-2 Processing flow for paging issue.........................................................................32
Figure 4-3 Analysis flow for RRC connection setup issue.....................................................35
Figure 4-4 Authentication failure (MAC Failure)....................................................................40
Figure 4-5 Sync failure.......................................................................................................... 41
Figure 4-6 Security mode complete......................................................................................41
Figure 4-7 Security mode reject............................................................................................42
Figure 4-8 RRC directed retry and redirection......................................................................48
Figure 4-9 RNC-level data analysis flow...............................................................................50
Figure 4-10 Cell-level data analysis flow...............................................................................51
Figure 4-11 Counters related to the paging loss of UEs at IDLE state..................................53
Figure 4-12 Counters related to the paging loss of UEs at PCH state..................................54
Figure 4-13 Counter related to RRC connection rejection.....................................................55
Figure 4-14 Counters related to CS RAB assignment failure................................................59
Figure 4-15 Counters related to PS RAB assignment failure................................................61
Figure 4-16 Counter related to RAB setup failure.................................................................64
TABLES
Table 2-1 Accessibility KPI Values of China Unicom...............................................................3

Table 2-2 Accessibility Statistical Indicators............................................................................4
Table 2-3 Access Delay Value Defined by China Unicom.......................................................4
Table 3-1 Relation Among the Cell Radius, Diversity Mode and Preamble Detection
Threshold................................................................................................................................ 9
Table 3-2 Proportion of Common Channels Power...............................................................17
Table 3-3 WCDMA Paging Delay Specified by China Unicom..............................................19
ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. V

1 Overview
The target of this guide is to provide the concept and method to perform UMTS network
access optimization to site engineers during the network KPI optimization and network
O&M process. It mainly introduces the evaluation method, testing method, data analysis
method, common problems and handling suggestions of network access performance,
and provides relevant background knowledge, principles, related parameters and data
handling tools as well.
In UMTS network, access performance refers to success rate and delay etc, which will
have great significance to users’ perception and OMC KPIs. And call connection setup
success rate and paging delay are the direct reflection of radio network quality. This
guide mainly discusses the access flow, and the common causes leading to access
failure and the relevant solutions.
This document concentrates on the problems such as whether the access is successful,
access success rate and access delay etc. First let’s talk about the concept of access
procedure. From radio perspective, access procedures include the UE searching for the
net after hooked on, random access, RRC setup and RAB setup etc. From the end user
perspective, access procedures starts from call dialing to call setup success, which
includes not only radio access but also the procedures happen in the fixed line. From
RAN perspective, radio access procedures should be focused on primarily cell search,
cell selection reselection, random access and RRC setup etc.
The above concept is established because in network optimization phase, radio

performance such as network coverage etc. should be focused on. Use UE or DT tool to
measure the pilot signals of the cell and observe whether UE can normally search for
cells, select and reselect cells, initiate random access, attachment, location
registration /update, and receive the normal service of the network so as to make site
adjustment (site spacing, antenna azimuth and downtilt etc.). Compared to RAB
establishment success rate, RRC connection establishment success rate can better
reflect the radio access performance, because RRC connection setup procedure covers
different procedures happen at the air-interface such as cell search, cell selection and
reselection, random access, while RAB setup success rate is more related to the
network factors such as equipment, transmission, and service parameters. And the
chance that the network factors may lead to access failure is small.
Paging delay indicates the delay occurred during the signaling proceeding of paging
setup, which involves the interaction and adjustment of signaling control parameters, a
great many NE equipment, and the handling is complicated. It must be noted that the
paging delay mentioned here and the service delay perceived by the user is different.
The paging delay mentioned here is the signaling delay while the delay perceived by
users also contains data transmission delay after the successful signaling setup and is
longer. This document only discusses the paging delay of signaling in the network.
ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 1

The guide contains the following five chapters:
Chapter 1 is overview.
Chapter 2 introduces the major measuring standards of access performance.
Chapter 3 introduces the analysis of the key parts concerning access performance
optimization.
Chapter 4 introduces how to perform UMTS network access performance optimization

based on DT, CQT and traffic statistics.
Chapter 5 presents the common access problems and solutions based on concrete
cases.

2 Evaluation Standards of Access

Performance
Access performance includes three relevant contents: system accessibility, availability
and access delay. Specific access performance measuring indicators can be obtained
through DT and traffic statistics.
2.1 System Accessibility
2.1.1 DT Testing Indicators of Accessibility

We can obtain system accessibility indicators such as connection setup success rate,
PS service setup success rate and PDP activation success rate through DT or CQT. We
will discuss the definition and analysis optimization methods of the indicators in chapter
four. In this section we only provide the referenced value of these indicators mainly from
China Unicom.
Table Evaluation Standards of Access Performance -1 Accessibility KPI Values of China

Unicom
Statistics
Indicators Services Referenced value
method
VC DT&CQT 98%
CS setup success rate
VP DT&CQT 97%
PS DT&CQT 97%
PS setup success rate
HSDPA DT&CQT 95%
Voice service setup
DT&CQT 5.5s
delay
VP service setup
Access delay DT&CQT 5.2s
delay
PS service setup
DT&CQT 2.8s
delay
2.1.2 Traffic Statistical Testing Indicators of Availability

We can use traffic statistical method to make performance statistics and problem
location, and the relevant indicators are RRC establishment success rate, RAB setup
success rate, radio connection establishment success rate and radio paging success
rate etc.

Table Evaluation Standards of Access Performance -2 Accessibility Statistical Indicators
Statistic Referenced
Indicators Services
methods values
Radio paging setup success rate N/A Stat. 85%
RRC setup success rate N/A Stat. 97%
Voice Stat. 98%
VP Stat. 98%
RAB setup success rate
PS Stat. 97%
HSDPA Stat. 97%
2.2 System Access Delay

Call delay indicates the delay occurred during the signaling proceeding of call setup,
which involves the interaction and adjustment of signaling control parameters, a great
many NE equipment, and the handling is complicated. The ideal call delay value defined
by China Unicom is shown in Table Evaluation Standards of Access Performance -3:
Table Evaluation Standards of Access Performance -3 Access Delay Value Defined by

China Unicom
CS12.2K originating delay 5.2s

CS12.2K terminating delay 4s (one paging) 15s (multiple pagings)
CS64K originating delay 5.5s
PS delay (HS) 2.8s

3 Key Points Analysis of Access

Performance Optimization
The theory introduced in the previous chapters helps us to have a detailed
understanding of the basic signaling in access procedures. In this chapter, we will
elaborate on the key points concerning the access performance optimization, mainly
focusing on the handling concept and procedures of access problems.
The problems of access performance mainly refer to access failure and low access
success rate. Access failure in the phases of site commissioning and single site
optimization is mainly caused by parameter configuration error; while access failure after
commercial launch is mainly caused by software version or equipment hardware, and
this problem has the highest handling priority and must be handle immediately. Low
access success rate problem will be reflected in the access KPIs of the traffic statistics
which will be put into the contract with the operator and therefore is of great significance.
3.1 Access Failure
3.1.1 Analysis Process of Access Failure

Here we present the analysis process for access failure:
Figure Key Points Analysis of Access Performance Optimization-1 Access failure

analysis process
错误！不能通过编辑域代码创建对象。
3.1.2 Basic Checking and Analysis of Access Failure
3.1.2.1 Alarm Checking
If the access failure problem mainly occurred in a single site, check the alarms of the
single site, especially the NodeB alarms. Check the history alarms and current alarms,
mainly focusing on critical alarms, i.e., the alarms relevant to transmission and hardware
equipment. If there are quite a lot of sites with faults, attention should be paid to RNC-
relevant alarms.

3.1.2.2 BPC Memory Checking
In one project, we have met the access failure caused by faulty DDR2 memory of BPC
board.
From the air interface, we can observe from the UE log that the UE has received the
rrcConnectionRelease message sent by the RNC air interface after sending the RRC
Connection Req message, with the cause value of releaseCause
directedsignallingconnectionre-establishment (DSCR). From RNC, there is no
signaling traced on the control panel, and there is no useful information contained in the
system logs.
Fault analysis and location: conduct DSCR operation and only CellUpdate request is
received from the UE; it is possible that the transmission packet error makes
RRCConnectionReq from the UE is decoded as CellUpdate at RNC side. Capture the
signaling trace on the user plane, and it shows that packets from the UE are all 0
packets, because Cciu event type 0 is CellUpdate by default, RNC will consider it to be
cell update and initiate rrcConnectionRelease. Because there is no corresponding
Ucpmc instance, signaling trace can’t be performed. Transmission packet capture shows
that the uplink packets from NodeB are all 0 packets, thus we can make the conclusion
that BP board of the NodeB gets faulty.
Solution: change BP board of the NodeB. Log on BP board of the NodeB, and run self-
check command to conform whether there are all 0 packets.
In another project, we meet the same problem. The statistics of the associate log shows
that the active set update complete message cannot be received when SFE and PTP
are added for soft handover. What’s more, the two cells have low call drop rate.
Therefore the problem may be that RRC setup message can’t be received. Signaling
trace at RNC user plane shows that packets from NodeB are all 0 packets, and is
decoded as data from RB1 and therefore is sent to the control panel and is discarded.
Node B engineers made inspections and found that the part of the FPGA in BPC DDR2
is faulty, which makes the NodeB send all 0 packets to RNC. Then, call drop happens.
Adding any cell of this site into the active set can easily lead to call drops. Previously the
problem usually occurs in the BPC board of the common channel, now with the increase
of users, it also occurs in the dedicated BPC board.
NodeB sends all 0 packets to RNC; therefore although lots of rach packets and FACH
packets can be seen at RNC side, no access succeeds. The ratio of rach packets to
FACH packets is 1:1, and normally the ratio should be 1:3.
The later NodeB version adds the self-check function of DDR2 memory and if there is
abnormality, alarms will be reported.

3.1.2.3 RRU Fault
RRU fault will affect the uplink and downlink signals, which can be judged through
channel self-check. Self-check can be carried out both in BPC and RRU channels.
1. Downlink self-check:
i. Telnet to BPC and open test mode:
m 0x61000064
ii. Telnet to RRU with faults, enter 0x0d000150 command, and conduct the
operation for several times. If the address is not changed, it is normal;
otherwise it is faulty.
iii. Telnet to BPC and close test mode:
m 0x61000064
2. Uplink self-check:
i. Telnet to RRU with faults, and open test mode:
m 0x0d000044
50
ii. Telnet to BPC of the RRU with faults, enter d 0x6100007c command. Conduct
the operation for several times. If the address is not changed, it is normal;
otherwise it is faulty. Note: BPC can only check whether the testing data in
IQ0 is normal or not, and can’t check the testing data of other IQs. Therefore,
if the uplink data of the RRU with faults is not transmitted via IQ0, this method
is not useful. Therefore, if the UL data of faulty RRU is not transmitted through
IQ0, this method cannot be used.
iii. Telnet to the RRU with faults and close test mode:
m 0x0d000044

3.1.2.4 Cell Health Degree Checking
Cell transmission power can be observed in PMS R99 cell performance measurement. It
contains cell receiving bandwidth power, digital transmission carrier power and analog
transmit carrier power.
When a cell is at zero load, the receiving bandwidth power is generally -105 dbm ~ -107
dbm (It usually refers to the power of the first carrier. Only when xxx is configured with
RX diversity, the power of the second carrier is considered). The receiving bandwidth
power of digital transmission carrier power and of analog transmission carrier power are
generally 35 dbm ~ 37 dbm.
As to the power configuration of the transmission power of the cell with zero load and
common transport channels, if broadcast channel (BCH) and common transport channel
(CCH) are not established, the total transmit power of the cell can be used for judgment.
It is planned to add alarm system when the minimum cell transmit power is lower than
certain threshold.
If the receiving power of the cell is excessively large, RRC connection setup complete
may not be received. In this case, uplink interference should be checked. Go to the site,
add load to the interface between the RRU and antenna system, and see whether
RTWP is reduced. If it is reduced, the interference probably comes from outside; if it is
not reduced, the interference may be caused by equipment fault which should be located
by RRU R&D engineers.
If the power is abnormal, check for the RRU-relevant alarms.
3.1.2.5 Common Transport Channel Checking
If the cell is correctly established, check on DMS whether the CCH of the cell is
successfully established. In one cell, one BCH, one FACH, one PCH and one RACH
should be established.
If the cell is not established, it may be caused by the following reasons:
 In ATM mode, check whether ATM addresses of RNC and NodeB are correct and
consistent; in IP mode, check whether there is any SCTP association interrupted
alarm, if there is any, check whether the IP parameters and flow parameters are
correct.
 Local cell IDs at NodeB and RNC sides are inconsistent.
 There are too many NodeBs configured in RCP.

 The site, BPC board, local cell or realtime cell is blocked.
 The TMA is turned off.
 Alarms exist on the BPC or RRU.
If the CCH can’t be established, check the following items:
 In ATM transmission mode, check whether ATM address are correct or not.
 Check whether the number, types of AAL2 at NodeB side and RNC side are
consistent or not.
 Check whether the jumper caps of the SA board are correctly connected. Normally
X1-X4 caps of SA board must be on, and X5 and X6 caps must be off.
If the above items are normal, change the CC board.
3.1.2.6 Parameter Checking
3.1.2.6.1 Preamble Configuration Checking
In R99 cell performance measurement in PMS, check whether cell access reject number
is abnormal. When there is no user accessed to the cell, the access reject number must
be 0.
If access preamble number, access accept number and access reject number are all
larger than or equal to 10, access performance will be affected.
The above situations are usually caused by configuration error of preamble detection
threshold. Different cell radii, diversity and non-diversity correspond to different preamble
detection thresholds. Table Key Points Analysis of Access Performance Optimization-4
shows the relationship among cell radius, diversity mode and preamble detection
threshold.
Table Key Points Analysis of Access Performance Optimization-4 Relation Among the
Cell Radius, Diversity Mode and Preamble Detection Threshold
PRACH PRACH message and

initial preamble power
Preamble deviation Pp-m
transmit
Detection
Parameter name power
Threshold,
constant Block Block
Tx (dB)
value Size=1*16 Size=1*36
[dB] 8 0
Double
2.5 km/ TTI=20 ms -21 -21 -1 2
antennas

PRACH PRACH message and

initial preamble power
Preamble deviation Pp-m
transmit
Detection
Parameter name power
Threshold,
constant Block Block
Tx (dB)
value Size=1*16 Size=1*36
[dB] 8 0
Single
message -21 -18 -1 2
antenna
5 km
Double
cell -21 -21 2 4
TTI=10 ms antennas
radius
message Single
-21 -18 2 4
antenna
Double
-21 -20 -1 2
TTI=20 ms antennas
message Single
10 km -19.5 -17 -1 2
antenna
cell
radius Double
-21 -20 2 4
TTI=10 ms antennas
message Single
-19.5 -17 2 4
antenna
Double
-21 -20 -1 2
TTI=20 ms antennas
message Single
40 km -21 -17 -1 2
antenna
cell
radius Double
-21 -20 2 4
TTI=10ms antennas
message Single
-21 -17 2 4
antenna
In the global parameters of the serving cell of RNC OMC, the preamble detection
threshold of the corresponding cell can be viewed and modified.
Note:
Preamble access threshold of the fields is generally -21. If the UE can get accessed in
remote areas, it is suggested to make a temporary modification; the final modification
must be reviewed by the chief engineers and experts.
3.1.2.6.2 Cell Radius and Time Delay
Cell radius and time delay can be viewed in local cell information on EOMS. The cell
radius decides the size of the search window of the uplink reception. The downlink
signaling is related to signaling strength, antenna tilt and topographic situations. The
downlink signaling may be far-reaching, such as on the sea, but the uplink signaling is

restricted by the cell radius, and preamble can’t be detected and access failure will
occur. What’s more, What’s more, if the repeater is used, the repeater and its feeder will
bring in extra delay, which will shorten the cell radius. In this case, the cell radius should
be increased.
3.1.2.6.3 Cell Capacity Degree
Currently the field cell is configured to be R99 + HSDPA + HSUPA. But the configuration
error may exist:
If R99 is not configured, calls can’t be made.
If HSDPA is not configured, the maximum download rate is 400 kbps.
3.1.2.6.4 Cell FACH Power
Cell FACH power is not strong enough, the UE in the areas near the site can get
accessed while the UE far from the site can’t get accessed.
3.1.2.7 Broadcast Packet Checking
The UE must receive the broadcast messages from the cell. Only after the UE knows the
cell information can it get accessed to the cell. If no broadcast packets is sent, there will
be no signals in the UE. If the content in the broadcast packets is not correct, access
may also fail.
1. No broadcast packets being sent.
No broadcast packet is sent. It can be viewed whether the broadcast packet fails to be
sent in the notification of the EMS.
It can also be checked in the R99 cell performance measurement in NodeB PMS.
There are a lot of reasons leading to 0 broadcast packet. For example, if UTRAN cells
are configured with GSM neighbor cells, but not configured externally, no broadcast
packet may be sent. If it is the case, contact the RNC R&D engineers to confirm the
problem through printing.
2. Incorrect content of the broadcast packets.
i. The cell is barred.
The most common situation is that cell barred occurs in the system information
block 3 (SIB3). When the cell is barred, cell can’t get accessed. Check the following
3 situations to see whether the cell is barred:

a) Use Qualcomm extensive digit monitor (QXDM) to capture broadcast

messages in the coverage area of the cell and in SIB3 to see whether
the cell is barred. This is the most convenient method.
Another method is to see whether there is cell barred in Cell Access

Restriction:
b) Check in OMC-R. If the cell is barred in OMC-R, the message at Uu

interface must be barred; If the cell is not barred in OMC-R, the message
at Uu interface may or may not be barred:
Figure Key Points Analysis of Access Performance Optimization-2 Checking whether

the cell is barred in OMC-R
c) Add the function of capturing the coded broadcast packets in the NodeB,
then the OMC will decode and confirm the broadcast content.
ii. The cell is Reserved.
The cell is reserved for the operators. Only SIM cards with AC=11 can be
accessed, SIM cards with AC=0-9 can’t be accessed. In Hongkong CSL project, the
cell is mistakenly reserved. Check whether the cell is reserved or not in SIB3.
Check whether the cell is barred or not in CellReservedForOperatorUse of
CellAccessRestriction.
For the operators, there are two methods to restrict the cells to be accessed. One is
to specify the status of the cell (reserved for the operators for control purpose),
another is through admission control, forbidding the users out of the designated AC
range to get accessed, and in this case, the user will be rejected for system load

reason. The users with the required AC level can get accessed. AC level is stored
in USIM.
Figure Key Points Analysis of Access Performance Optimization-3 Checking whether

the cell is barred in OMC-R
3.1.2.8 No Signaling from the Specified Cell in the Site
3.1.2.8.1 Favorable Signaling, Able to be Accessed, but not the

Specified Cell
Before the site commissioning, the transmission equipment is inversely connected. Its
configuration is made consistent with that of OMC-B instead of that of the site. The cell
can be established, but not the specified one.
3.1.2.8.2 Poor Signaling, only Adjacent Cells can be Accessed
After the site commissioning, the transmission equipment is adjusted, which leads to the
inverse connection of the transmission equipment and the cell can’t be established. The
cell ID in the cell establishment request is not consistent with the local cell ID in the
NodeB.

3.1.2.9 UE Terminal Fault Detection
In some cases, the access failure is caused by some specific terminal problem. When
access is denied, change another UE terminal.
3.2 Low Access Success Rate

RRC connection setup success rate reflects the UE absorbability of the RNC or cell.
RRC connection setup success indicates that the signaling connection has been
established between the UE and the network. There are two types of RRC connection
setup rates: one is relevant to the service; another is irrelevant to the service (location
upgrading, inter-system cell reselection and registration etc.). The former is an important
KPI to evaluate the paging setup success rate, the result of which can be used for
channel configuration adjustment. The later can be used for system load assessment.
When the UE in idle mode receives the request to establish signaling connection from
NAS, it will initiate RRC connection setup process. Upon receiving the request, the RNC
will decide whether to establish it or not and on which channel (DCH or CCH) to
establish it.
RRC connection setup complete rate (service-relevant) can be expressed as the ratio of
RRC connection setup complete number (corresponding to RRC CONNECTION SETUP
COMPLETE number received by RNC) to RRC connection setup request number (RRC
CONNECTION REQ number). This indicator should be recorded based on different
service type.
RRC connection setup complete rate (service-relevant) = RRC connection setup

complete number (service-relevant) /RRC connection setup request number (service-
relevant) *100%
Access success rate is related to parameters and equipment. In the following section,
we will first discuss how parameters affects access success rate, and then analyze what
leads to the low access success rate.
3.2.1 Radio Parameter Configuration
3.2.1.1 Too High Qqualmin and Qrxlevmin Values
The UE will read the value of Qqualmin and of Qrxlevmin in cell selection process and
judge whether the cell is suitable for residing in based on S criteria. If the cell satisfies S
criteria, the UE will consider the cell to be a suitable cell, reside in the cell, read the
required system information, and then initiate the location registration process. If
Qqualmin and Qrxlevmin are too highly configured, when the UE moves far from the
cell, and may not stay at the cell after the UE hooks off. Power control can ensure that
call drops do not occur when the UE moves far away. After the UE hooks off, it will

perform cell reselection, CCH signaling will be comparatively poor then, and if Qqualmin
and Qrxlevmin are too highly configured, UE cell reselection may fail.
By default, Qqualmin = -18 dB, and Qrxlevmin = -115 dBm. The parameters can be
configured according to the requirements at different network construction stage.
3.2.1.2 Unreasonable Access Threshold Configuration
Access threshold refers to the preamble threshold of PRACH.
The preamble threshold is defined to be PRACH preamble detection threshold. RNC

notifies NodeB through CCH setup signaling at Iub interface. Only when the preamble
power received during preamble period is larger than the threshold can the preamble be
confirmed. If the preamble threshold is set too small, misjudgment will be made, and
fake alarms will occur and the quality of random access demodulated signaling will be
deteriorated especially when the demodulation resources are inadequate. Fake alarms
will also lead to the invalid data transmission in downlink AICH, which will waste
downlink power and adds downlink interference. The probability of fake alarms can be
viewed in NodeB debugging bed, and it is usually 1 ‰. The value is considered to be too
high if it is higher than 1 ‰. If the preamble threshold is too big, the acquisition
probability of the preamble signaling will be reduced. And when the uplink transmit
power of the UE is comparatively strong, PRACH uplink interference will rise. This
parameter decides the random access demodulation quality and user access success
rate, which relates to access distance (coverage radius of the access channel × 2 ) and
NodeB configuration (four-antenna diversity or OTSR).
By default, the preamble threshold is -21.0 dB.
3.2.1.3 Unreasonable Configuration of Preamble Power Ramping Step and Retransmit

Number
The UE can obtain the preamble maximum retransmit number and preamble power
ramping step through receiving SIB3. If the UE has not received AI in the prescribed
time, after sending Preamble, one step will be added to the preamble power, and 1 will
be deducted from the retransmit counter. Retransmission will stop when the counter is
zero.
The value of preamble power ramping step will affect the raising speed of the transmit
power value of random access preamble. If the value is too small, many times of access
may be required, which will add to the preamble collision probability; if it is too big, the
access preamble power value may exceed the required one, which will add to the
system interference.
Normally, suppose the step value is fixed, the greater Preamble_Retrans_Max is, the
higher the random access success rate will be and PRACH load will increase
accordingly. In the cell with comparatively large traffic volume, an excessively big

maximum retransmit number may lead to the overloading and congestion of the radio
channel, and the UE access collision probability will increase and access success rate
and radio source utilization rate will be greatly reduced. In contrast, if
Preamble_Retrans_Max is too small, the preamble transmit power may not meet the
required value and the UE access success rate will be reduced. Therefore a reasonable
Preamble_Retrans_Max value is an important means to utilize the radio resources fully
and increase the access success rate.
These two parameters controls the UE access preamble ramping procedure, and their
values must be configured taking reducing uplink interference, improving access
success rate and reducing access delay etc. into consideration.
3.2.1.4 Unreasonable Configuration of Neighbor Cells
In the RRC CONNECTION REQUEST message, the pilot measurement information of

the local cell and adjacent cell from the UE can be viewed. These measurements are
made during the cell selection process, if the neighbor cell number in the system
broadcast message is great, it will take a long time for the UE to measure the quality of
the pilot signaling of the neighbor cells and the users’ access speed will be affected.
Therefore one important task of network optimization is to make a suitable neighbor cell
list for every donor cell defined in the preplanning phase, and delete useless neighbor
cells using the traffic statistics tool. For example, if two cells are configured to be the
neighbor cell of each other, but there are geographic obstacles such as a river among
the users in the two cells and handovers seldom happen, the two cells must not be
configured to be the neighbor cell of each other. This situation can hardly be considered
in the preplanning phase and therefore optimization must be performed in later phases.
Inversely, there may be missing configuration of neighbor cells. When the UE moves at
the edge of the cell and away from the NodeB and there is no neighbor cell configured in
the direction, access failure may occur. Therefore we should perform neighbor cell
configuration based on actual condition.
3.2.1.5 Unreasonable Synchronization Parameter Configuration
There are two situations: one is slow synchronization. When establishing radio links,
RNC will wait for NodeB to report RL RESTORE message after starting the timer. If
radio links can’t be synchronized in time, the timer will expire and RNC will initiate link
deletion process. Another is fast asynchronization, once the NodeB detects
asynchronization and will send the RL FAILURE message to RNC.
Uplink synchronization and asynchronization parameters are N_INSYNC_IND,

N_OUTSYNC_IND, and T_RLFAILURE. When the uplink is synchronized, radio link set
remains in the initiate status till Layer 1 receives N_INSYNC_IND continuous
synchronization indications. At this moment, the NodeB triggers the RL restore process,
indicating the RL is synchronized. Once the radio link restore process is triggered, radio
link set is considered to be synchronized. The NodeB will start the timer T_RLFAILURE
after receiving N_OUTSYNC_IND continuous asynchronization indications, and it must

stop and reset T_RLFAILURE after receiving N_INSYNC_IND synchronization

indications. If T_RLFAILURE times out, NodeB will trigger radio link failure process and
indicate which radio link set is asynchronized.
Downlink synchronization and asynchronization parameters are T312, N312, T313,

N313 and N315. When the UE starts to establish the dedicated channel, it will start
T312. When the UE detects N312 synchronization indications from L1, it will stop T312.
Once T312 expires, the physical channel setup will fail. When the UE detects N313
asynchronization indications from L1, it will stop T313. When the UE detects N315
synchronization indications from L1, it will stop T313. Once it expires, radio link setup will
fail.
Make adjustment based on actual condition, and pay attention to the balancing of the
parameters.
3.2.1.6 Excessively Low CCH Proportion
When the UE moves far from the site, the call can be hold; once the call is terminated,
the UE can’t access the network any more. The reason is: power control causes the
uplink and downlink power of the dedicated channel to increase when the UE moves far
away from the site, while the power of the common channels decreases continuously
because there is no power control; When the UE hooks off, cell reselection will fail and
the UE can’t camp on the cell. The proportion of the common channels power must not
be too great: too great power proportion will affect the capacity and too small power
proportion will result in poor coverage of the common channels and users can’t get
accessed. Normally it is reasonable to allocate about 20% of the total power to the
common channels.
Based on data from our friends and field tests, we have gotten the following values,
which can work as your reference:
Table Key Points Analysis of Access Performance Optimization-5 Proportion of

Common Channels Power
Power relative to Power

Channel Duty cycle
MAX BS power[dB] proportion
SCH -13 0.1
Primary CCPCH -13 0.9
Secondly CCPCH (carrying PCH) -13 0.25
Secondly CCPCH (carrying
-8 0.25
FACH)
CPICH -10 1
AICH -15 1
PICH -15 1
the proportion of the power of common channels to the

Power relative to Power

Channel Duty cycle
MAX BS power[dB] proportion
total power (configured with 2 SCCPCH)
In the preliminary network construction stage, it's recommended to set the power
proportion of the common channels a little higher.
3.2.1.7 Excessively Low Initial Power of UL & DL DCH
When the link is initially established, uplink or downlink synchronization fails. The link
asynchronization may be caused by the inadequate DPCCH pilot bits power. Downlink
DPCCH pilot bits power equals to the sum of DPDCH power and P03 (usually 3 dB).
Downlink open-loop power control is used to set the DPDCH initial transmit power, and
the DPDCH initial transmit power can be expressed as:
P = ( Ec/Io) req - CPICH_Ec/Io + Ppcpich
In the above expression, (Ec/Io) req is the Ec/Io needed for the UE to correctly receive
from the dedicated channel and should be configured based on MOD TYPSRB of the
specific service. CPICH_Ec/Io is the Ec/Io of the common pilot channel measured by the
UE, and is reported to UTRAN through RACH report. Its default value is -18dB, and can
be modified using the SET FRC of MML command. Ppcpich is the transmit power of the
common pilot channel.
The expression of the uplink initial transmit power is:
DPCCH_Initial_power = DPCCH_Power_offset - CPICH_RSCP
In the above expression, CPICH_RSCP is measured by the UE and

DPCCH_Power_offset is notified to the UE from RNC through RRC CONNECT SETUP
message.
Properly set the uplink and downlink initial transmit power to a higher value can enhance
access success rate. After the uplink and downlink synchronization succeeds, the inner
loop power control can regulate the excessively high power.
3.2.1.8 Excessively Low Initial UL ISIR Target Value of the DCH
After the UE successfully establishes the link, the uplink is out of synchronization. It can
be seen at Iub that the link is deleted when the NodeB reports RL FAILURE. If the initial
uplink SIR target value is excessively low, UE downlink power will be reduced under the
influence of inner-loop power control and because there will be delay for outer-loop
power control functions, uplink may be out of synchronization.

3.2.1.9 Excessively Small Cell Radius
Excessively small cell radius will make the UEs in the normal downlink coverage area
unable to get accessed to the network. In PMS cell measurement, RL restore and RI
establishment rate can help to decide whether the problem is caused by the cell radius.
3.2.1.10 UE Maximum Transmit Power
UE maximum transmit power is modified to be -21 dBm mistakenly and the UE can’t get
accessed even when it is very near the site.
3.3 Paging Delay

Paging delay is an important indicator to evaluate the performance of WCDMA network
and becomes the major concern of the operators. The operators have specified different
CS and PS paging delay time, which must be observed in our equipment. The following
is the CS and PS paging delay time specified by Unicom:
Table Key Points Analysis of Access Performance Optimization-6 WCDMA Paging

Delay Specified by China Unicom
CS12.2K originating delay 5.2 s
CS12.2K terminating delay 4 s (one paging) 15 s (multiple pagings)
CS64K originating delay 5.5 s
PS delay (HS) 2.8 s
The paging delay indicator specified by China Unicom is reasonable. Paging delay may
not meet the requirement due to several reasons: the commercial operation environment
is complicated; there may be equipment from different vendors; time such as random
time and air interface retransmit time are not controllable even when the signaling
control parameters are consistent. Therefore, we should make detailed analysis of the
paging setup process, find the reason for long time delay and see which link brings
about the delay, then we can solve the problem.
Paging delay indicates the delay occurred during the signaling proceeding of paging
setup, which involves the interaction and adjustment of signaling control parameters, a
great many NE equipment, and the handling is complicated. It must be noted that the
paging delay mentioned here and the service delay perceived by the user is different.
The paging delay mentioned here is the signaling delay while the delay perceived by
users also contains data transmission delay after the successful signaling setup and is
longer. This document only discusses the paging delay of signaling in the network.

3.3.1 CS Paging Delay Process Analysis
3.3.1.1 CS Originating Establishment Process Analysis
CS originating paging delay is defined as the time range from the originating UE initiating
RRC CONNECTION REQUEST to the originating UE receiving downlink direct transfer
message (Alerting), that is, the time difference between the following two signaling:
RRC Connection Request sent by UE
Downlink Direct Transfer (Alerting) received by UE
To ensure data reliability, multiple signaling statistics should be made to compute the
average value of paging delay. The expression is:
CCSD _ MO  AverageT  CC _ Alerting  T  RRC Connection Request 

CS
In the above expression, CCSD is the abbreviation of CS Call Setup Delay, T means
the time to receive or send the signaling. The originating process shows that UE
signaling time is needed to calculate the precisely originating paging setup delay.
The definition of CS originating service paging delay indicates that the process falls into
4 phases:
 RRC connection setup process
 CN signaling interaction process
 RAB setup process
 Process of waiting for the terminating Alerting message
In the following section, the four processes will be analyzed and the delay occurred in
the processes will be introduced.
3.3.1.1.1 RRC Connection Setup Process
There are three air-interface signaling in RRC connection setup process at UE side:
RRC Connection Request, RRC Connection Setup, and RRC Connection Setup
Complete.
Besides the above signaling, there are other two Iub signaling during RRC connection
setup process at RNC side: Radio Link Setup Request and Radio Link Setup
Response.
The following are major factors that will affect RRC connection setup delay:

 The transport channels that bear signaling are divided into the two types: DCH and
FACH. By default, only when DCH admission is rejected in the signaling phase will
the signaling be established in FACH, therefore generally we usually consider the
condition when the DCH is the transport channel. It must be noted that in RRC
phase, admission judgment will be made not only for hard resources such as CE
resource and code resource, but also for soft resource such as signaling user
number and power. Therefore when soft resource admission in RRC phase is
rejected, signaling will be transported in the FACH and the delay will be longer.
 Signaling transported in the DCH is classified into 13.6 K signaling and 3.4 K
signaling by rate. 13.6 K signaling is applied on site by default.
 T300 is the waiting time after the UE sending the RRC CONNECTION SETUP
REQUEST message. When the UE initiates RRC Connection Request, it will start
T300, and then terminate it after receiving RRC Connection Setup message from
the RNC. If T300 expires, RRC Connection Request will be retransmitted again. If
T300 is comparatively great, the waiting time for the UE to retransmit RRC
Connection Request will be too long, and RRC setup delay will be increased; If
T300 is too small, the UE will retransmit RRC Connection Request when RRC
connection setup is not completed and RRC connection can hardly be established.
The default parameter applied on site is 2 second and if the parameter should be
modified to optimize the delay, the two sides should be taken into consideration.
 N300 is the maximum retransmit times of RRC CONNECTION SETUP REQUEST

message. If the parameter is comparatively great, RRC will retransmit for many
times before the setup is completed, which will add to the RRC connection setup
delay; If it is too small, RRC connection setup success rate will be reduced.
3.3.1.1.2 CN Signaling Interaction Process
For CS originating service, there are three NAS signaling: Initial Direct Transfer (CM
Service Request), Uplink Direct Transfer (Setup), and Downlink Direct Transfer
(Call Proceeding).
The CN will start authentication, security mode command process and identity process.
Successful authentication process mainly contains two signaling: Downlink Direct
Transfer (Authentication Request) and Uplink Direct Transfer (Authentication
Response). Successful security mode command contains two signaling: Security Mode
Command and Security Mode Complete. Successful identity process contains two
signaling: Identity Request and Identity Response.
The time for the above process is mainly decided by the CN. For example, the CN will
control whether to initiate authentication process and security mode command process.
If these two processes fail, the CN may start other NAS process or terminate the paging
process. In order to reduce the delay in this phase, close some unnecessary processes
such as the authentication and security mode command process at the CN side,
especially the authentication process of the originating and terminating UEs, which will

last about 1s. In commercial network, decide whether to close some unnecessary
processes according to the requirements from the operator.
3.3.1.1.3 RAB Setup Process
RAB setup process can’t be reflected in UE signaling and the analysis of delay in this
process requires the RNC signaling.
For the UE, there are only two signaling: Radio Bearer Setup and Radio Bearer Setup
Complete. This process is very important and will add delay at the air-interface and
activation time should be considered. Activation time is identified using connection frame
number (CFN). The UE, NodeB and RNC would activate the new configuration
simultaneously and after the configuration becomes effective, the UE will send RB Setup
Complete message. If the activation time is set too early, the UE and NodeB may not
have the time to make internal processing; if the time point of activation time is too late,
after the UE and NodeB finish internal processing, they will wait for a considerably long
time to activate the new configuration, which will add paging delay. Therefore, activation
time should be reasonably configured to reduce the delay.
For the RNC, there is the following signaling in this process: RAB Assignment
Request, Radio Link Reconfiguration Prepare, Radio Links Reconfiguration
Ready, Radio Link Reconfiguration Commit, Radio Bearer Setup and Radio Bearer
Setup Complete.
Delay from Call Proceeding in the last phase to the CN sending the first message RAB
Assignment Request in this phase is introduced by the CN. For CNs of different
vendors, the time for the CN sending RAB assignment message to the originating and to
the terminating may be different. As to ZTE CN, the late assignment strategy is applied,
that is, after the CN sends Call Proceeding to the originating UE, it will page the
terminating UE, the terminating UE gives response and then paging setup process
starts, then the CN will sends RAB assignment to the terminating UE and sends RAB
assignment request to the originating UE. The sending of two RAB assignments are
separated by 100 ms. This process will consider the time to send RAB assignment and
the time between sending paging and paging response, and the time segment between
sending paging and receiving response is contained in the time from originating Call
Proceeding to sending RAB assignment.
3.3.1.1.4 Waiting Alerting from the Terminating UE
After RAB setup is completed, the originating UE will wait to receive the Alerting
message from the terminating UE and the whole paging process is completed.

3.3.1.2 CS Terminating Process Analysis
CS terminating paging delay is defined as the time difference from RNC receiving Iu
paging message to RNC receiving uplink direct transfer message (Alerting) from the
terminating UE, that is, the difference of the two signaling:
Paging received from CN
Uplink Direct Transfer (Alerting) received by RNC
It must be noted that from the system perspective, terminating paging delay is the time
between the CN sending the paging message and the CN receiving the Alerting
message from RNC. If only delay at the access network side is considered, the above
definition is appropriate.
Similar to the originating process, make many times of signaling to compute paging
delay average value and the expression is as follows:
CCSD _ MT  AverageT  RANAP _ Paging   T  CC _ Altering  

CS
In the expression, CCSD is the abbreviation of CS Call Setup Delay, T is the time point
to send and receive the signaling in the bracket and the expression can be used to
compute RNC signaling time for terminating delay precisely.
From CS terminating service paging delay, the process can be divided into 5 phases:
 Paging process
 Sending Alerting process
In the following section, five phases will be analyzed and delay will be introduced
separately.
3.3.1.2.1 Paging Process
The CN will send paging message to UTRAN through Iu paging message. UTRAN will
send the CN paging message to UE through Uu paging process, and then the paged UE
will initiate the signaling connection setup process with the CN.
Paging at Uu falls into two categories: Paging Type1 and Paging Type2. When the UE is
in connected state and is the terminating user, the RNC will page the UE in the DCH

using Paging Type2; when the UE is in idle state and is the terminating user, the RNC
will page the UE in paging channel (PCH) using Paging Type1.
Usually the UE will respond quicker to Paging Type2 than to Paging Type1 and RRC
connection setup process will be skipped and therefore the paging delay will be smaller.
But most paging happens when the UE is in idle state, therefore only the condition in idle
state is discussed.
The above analysis indicates that paging delay is divided into two parts: delay at Iu and
delay at Uu. The time to sending paging at Iu is decided by the CN, and paging delay at
Uu is related to RNC. For RNC, send a Paging Type1 message in the PCCH at a
suitable time to initiate paging at Uu and the paging time is related to the IMSI of the UE.
It is suggested to page the UE several times to add the possibility of the UE receiving
paging message and to reduce the paging delay at Uu. Currently the default number of
sending a paging message is 3 in the RNC.
3.3.1.2.2 RRC Connection Setup Process
The terminating RRC connection setup process is similar to the originating RRC
connection setup process which is described in section 3.3.1.1.1.
3.3.1.2.3 CN Signaling Interaction Process
For CS terminating service, there is three NAS signaling: Initial Direct Transfer (Paging
Response), Downlink Direct Transfer (Setup) and Uplink Direct Transfer (Call
Confirmed).
Terminating process is similar to the originating process and includes the authentication,
security mode and identity process. Refer to section 3.3.1.1.2. Whether authentication,
security mode and identity process are needed is decided by the CN.
3.3.1.2.4 RAB Setup Process
Terminating RAB setup process is similar to that of the originating. Refer to section
3.3.1.1.3.
3.3.1.2.5 Sending Alerting Process
After terminating RAB setup is completed, the Uplink Direct Transfer message
(alerting) will be sent and the terminating process is finished.
Note:

The originating UE receives the alerting message from the terminating UE and the
paging setup is completed. Therefore the originating paging delay includes the
terminating paging setup process and the terminating paging delay must be shorter than
the originating paging delay. Therefore usually CS paging setup delay refers to the
originating paging delay, sometimes includes the terminating paging delay. And we
should make statistics based on the requirements from the operators.
3.3.2 PS Paging Setup Process Analysis
PS service paging delay is defined as the time between the UE sending RRC
CONNECTION REQUEST and the UE receiving downlink direct transfer message
(Activate PDP context accept), that is, the difference between the following two
signaling:
RRC Connection Request sent by UE
Activate PDP Context Accept received by UE
To ensure the data reliability, make many times of signaling statistics and based on it
compute the average value of paging delay. The expression is as follows:
PCSD  AverageT  Activate PDP Contest Accept  T  RRC Connextion Request 

PS
In the expression, PCSD is the abbreviation of PS Call Setup Delay. T is the time spot
to send or receive the signaling in the bracket. As can be seen in PS setup process, UE
signaling time is required to compute PS paging setup delay.
The definition of PS service paging delay indicates that the process can be divided into
four phases:
 Process of waiting for the CN to send PDP activation and CN accept
In the following section, the four phases will be analyzed and delay will be introduced
separately.
3.3.2.1 RRC Connection Setup Process
PS RRC connection setup process is similar to CS originating process. Refer to section

3.3.1.1.1.

3.3.2.2 CN Signaling Interaction Process
For PS service, there are two NAS signaling: Initial Direct Transfer (Service Request)
and Uplink Direct Transfer (Activate PDP context request). Sometimes if the UE
initiates PS service when it is not successfully registered in the PS domain, Attach
process will be initiated, which will increase PS call establishment delay and should be
avoided.
For PS service, the CN will initiate authentication, security mode and identity process.
Refer to section 3.3.1.1.2.
3.3.2.3 RAB Setup Process
RAB setup process of PS service is similar to that of CS service. Refer to section

3.3.1.1.3.
3.3.2.4 Process of Waiting for the CN to Send PDP Activate Accept
After RAB setup is completed, the UE will receive the direct message Activate PDP
Context Accept from the CN, and then PS service setup is completed.
3.3.3 Methods to Reduce Paging Delay
3.3.3.1 Radio Coverage Optimization
If coverage is abnormal, poor coverage or frequent handover area occurs, the RRC
Connection Request message will be retransmitted and paging delay will increase. If
soft handover happens in the signaling phase, call delay will be increased by the time for
updating the active set
3.3.3.2 System Parameter Optimization
 After RRC Connection Setup Complete, check whether measurement control

related to measurement identity 11 has been sent. If it exists, disable the
measurement control of Detect Set of measurement identity 11. This
measurement is not necessary, and is only used for neighbor cell commissioning in
network optimization, therefore it can be deleted. The method is to disable the
detect set handover switch in the background without starting measurement task of
the detect set.
 Optimize RB setup process and configure reasonable activate time.
 Canceling RB reconfiguration after service setup will reduce paging delay of PS

service (paging delay of CS service may or may not be reduced). To cancel RB

reconfiguration, modify Time Poll (its index number is 0) of 13.6 kpbs service
subtype 4 and subtype 5 from 140 ms to 250 ms.
RB RB
reconfiguration 1.JPG
reconfiguration 2.JPG
 Discontinuous reception cycle (DRX) configuration
In the connection delay of the UE calling another UE, paging delay has a large
proportion. On one hand, if the inappropriate power configuration of the paging channel
and paging indication channel leads to paging retransmission, connection delay will be
added. On the other hand, DRX decides the time to send paging, and the excessively
great DRX configuration will bring about comparatively great delay.
If DRX is configured to be 6, 7 and 8, the paging cycle will be 640 ms, 1280 ms and
2560 ms. From the statistics probability perspective, if there are enough UEs and
enough calls, the traffic will follow Possion distribution and average access delay will
increase progressively. According to the field test result, when DRX is 8, paging delay is
mainly between 1 s to 1.5 s, with the maximum value reaching 2.5 s. When DRX is 6,
paging delay is mainly between 0.35 s to 0.95 s. Therefore delay will be greatly reduced
when DRX is set to be 6.
If DRX is set to be 6, UE power consumption will be great; therefore it should be

carefully designed. In the preliminary network operation phase, focus should be placed
on RAN performance improvement. Our vendors mainly set DRX to be 6.
3.3.3.3 Access Process Optimization
 In CN signaling interaction phase, disable some processes such as authentication

and identity, which is controlled by the CN.
 Quickening RAB assignment sending requires CN control and should use prior
paging mode.
 Adopt early and late assignment strategy reasonably. The difference lies in the time
to assign a TCH. As to the terminating UE, early assignment is to make assignment
before off-hook, and late assignment is to make assignment after off-hook. As to
the originating UE, early assignment is to make assignment before Alerting and late
assignment is to make assignment after Alerting. Early assignment will improve
paging connection success rate and late assignment will avoid the occupancy of
TCH resource during alerting and improve TCH utility. According to the test result,
late assignment will be 1.28 second quicker than early assignment to receive
Alerting message. Because late assignment mechanism will be quicker to receive
the response (alerting), late assignment mechanism is more reasonable, but
sometimes connection failure will occur, therefore it should be carefully considered
which mechanism to be applied.

4 Access Performance Optimization Through

Daily Tests and Traffic Statistics
4.1 Access Performance Analysis Through DT/CQT Test

Data
4.1.1 Access Failure Defined by CNT/CNA
Access failure means that the services are not successfully established. In the DT, the
frequently appeared access failures include voice call failure, VP call failure, and PDP
activation failure.
Generally, the DT data analysis tool can automatically estimate the access failure
problem based on the preset estimation conditions. ZTE CNT/CNA has defined access
failure as follows:
CS originating call failure: After the UE sends the RRC REQUEST message (among
which, IE establish cause is the Originating Conversational Call), it does not receive
the direct transfer message alerting.
CS terminating call failure: After the UE (called party) receives paging type 1, it does
not send the RRC CONNECTION REQUEST message with cause value of Terminating
Conversational Call, or it does send the RRC CONNECTION REQUEST message but
does not send the direct transfer message alerting to the CN.
4.1.2 Categories of CS Originating Call Failures
1. RRC Connection setup failure
The UE sends the RRC CONNECTION REQUEST message, the RNC does not
respond, or the UE receives the RRC CONNECTION REJECT message sent by the
RNC after the retransmission time reaches the threshold, and the wait time expires.
2. Initial direct transfer and security mode setup failure
After the UE sends the RRC CONNECTION SETUP COMPLETE message, it does no
send the NAS SETUP message.
3. RAB assignment failure

After the UE receives the CALL PROCEEDING message, it does not receive the RB
SETUP message sent by the RNC; or the UE sends RB SETUP FAIL after receiving the
RB SETUP message; or the UE receives the DISCONNECT message with cause value
which is not normal release after receiving the RB SETUP message. Note this refers to
the condition that the UE has not sent the RB SETUP CMP message yet.
4. Call failure after RAB assignment is completed
The originating UE receives the DISCONNECT/RELEASE message sent by the CN.
After the waiting time for the CONNECT or ALERTING message expires, the originating
UE starts the call clearing procedure. The protocol specifies that the UE starts the T303
timer after it sends the CM SERVICE REQUEST message. If the UE fails to receive the
CALL PROCEEDING, ALERTING, CONNECT, or RELEASE COMPLETE messages
before the T303 timer expires, it will start the clearing procedure. The UE enters the idle
state before it receives the Alerting message, and then it begins to receive the system
information.
4.1.3 Categories of CS Terminating Call Failures
The call failure can be divided into the following categories based on the stages:
1. RRC connection setup failure
After the UE sends the RRC CONNECTION REQUEST message, the RNC does not
respond, or the UE receives the RRC CONNECTION REJECT message sent by the
RNC.
2. Initial direct transfer and security mode setup failure
After the UE sends the RRC CONNECTION SETUP COMPLETE message, it does not
receive the direct transfer message of SETUP; or the UE sends the RELEASE
COMPLETE message; or the UE receives the DISCONNECT message from the CN.
3. RAB assignment failure
After the UE sends the CALL CONFIRM message, it does not receive the RB SETUP
message sent by the RNC; or the UE sends RB SETUP FAIL after receiving the RB
SETUP message; or the UE receives the DISCONNECT message with cause value
which is not normal release after receiving the RB SETUP message. Note this refers to
the condition that the UE has not sent the RB SETUP CMP message yet.
4. Call failure after RAB assignment is completed
The terminating UE receives the DISCONNECT/RELEASE message sent by the CN

after the originating UE sends the RB SETUP COMPLETE message.

4.1.4 Categories of PS Access Failures
The access failure in PS domain is similar to that in the CS domain, and can be divided
into access failure at RRC setup stage, access failure at Iu interface signaling setup
stage, access failure at the PDP activation stage, and access failure after the
assignment is completed. The access failure at the PDP activation stage is the most
important one. Its main phenomenon is that the UE receives the Activate PDP Context
Reject message after sending the Activate PDP Context Request message. The
access failure is mainly caused by problems at the CN side or incorrect setting of the
APN or rate at the UE side.
1. Access failures caused by the APN setting at the UE side
If the cause value of Activate PDP Context Reject is Missing or unknown APN, the
reason for the access failure is that the APN setting at the UE side is inconsistent with
that at the CN side. Check the APN setting at the UE side, and compare the setting with
the HLR APN. For the APN setting of the Probe and UE, see the Online Help file of
Genex Probe.
2. Access failures caused by the rate setting at the UE side
If the cause value of Activate PDP Context Reject is Service option not supported,
the access failure is mainly caused by the fact that rate requested by the UE is higher
than the rate subscribed when opening the account. Check the rate setting at the UE
side, and compare the setting with the rate subscribed when opening the account
(stored in the HLR). Confirm the APN and applied rate in the Activate PDP Context
Request message.
3. Access failures caused by the CN
If the cause values are not the values mentioned in the previous part, and the APN, rate
settings at the UE side are correct, the access failure may be caused by the CN, for
example, some interfaces of the CN are blocked. Under this condition, you can contact
the engineer in charge of the PS domain of the CN to locate the problem. In addition, if
this is the first time to debug the PS services, the access failure may be caused by the
fact that the APN setting at the HLR is inconsistent with that in GGSN, you can contact
the engineer in charge of the PS domain of the CN to solve this problem.
4.1.5 Analysis Procedure for Access Failure Discovered in DT/CQT
4.1.5.1 Analysis Flow for Access Failures
The following figure shows the analysis flow for access failures.

Figure Access Performance Optimization Through Daily Tests and Traffic Statistics -4
Analysis flow for access failures
The DT data analysis software, such as ZTE CNT/CNA and Dingli Pioneer/Navigator,
can ascertain the time of call fail, acquire the pilot information collected by the scanner
before and after the call fail, and acquire the information about the active set and
monitoring set collected by the UE and the signaling flow. The messages can help to
align the signaling collected by the UE with the single user tracing time of the RNC,
through which the time when the fault happened can be located.

Combined with the RNC single user tracing and the UE signaling flow, the engineer can
easily locate the problem following the flow described in the above figure. Then the
engineer can solve the problem from the following aspects: paging, RRC establishment,
RAB and RB establishment, authentication and encryption, and abnormal devices.
4.1.5.2 Paging Issue Analysis
Phenomena of paging issue: After the RAB assignment and CC Setup of the UE (calling
party) are completed, the UE receives the direct transfer message Disconnect when
waiting for the Alerting message. Usually there is no abnormality in the terminating
signaling process, however there is the condition that the UE receives the Paging
message but does not send the RRC connection setup request. The RNC single user
tracing of the terminating UE indicates that Paging message from the CN is received but
there is no subsequent message.
Reasons may lead to paging issue:
 The RNC does not send the Paging message.
 The power of the paging channel and paging indicator channel is too low.
 The UE performs the cell reselection.
Usually, the flow to deal with padding issue is as follows:

Processing flow for paging issue
The detailed processing flow is as follows:
1. The RNC has not sent the Paging message.
The RNC receives the Paging message sent by the CN, but the Uu interface fails to
forward the message. This is because that the capacity of the paging channel is
insufficient or the device is abnormal. Note: Currently, the network load is small, so the
problem of insufficient capacity may not appear; however, in the later stages, there may
be the case that the Paging message is blocked at the Uu interface.
2. The power of the paging channel and paging indicator channel is too low.
The RNC sends the Paging message, but the UE fails to receive the message. To solve
this problem, check the Ec/Io of the cell where the UE is camped on and of the
monitoring cell. If the CPICH Ec/Io of the cell where the UE is camped and CPICH Ec/Io
of the monitoring cell are too low (lower than -12 dB), the power of the PCH channel or
PICH channel is too low or the coverage at this spot is poor.
3. The UE performs the cell reselection.
If the signal quality of the cell where the UE is camped is bad while that of the monitoring
cell is good, the paging issue may be caused by cell reselection. Or, the UE upgrades
the location area/routing area when starts the paging, but the Paging message is still

sent to the original location area/routing area, then the UE cannot receive the Paging
message.
4.1.5.3 Analysis of RRC Connection Setup Issue
The RRC connection setup failure can be located by the UE signaling flow and the RNC
single user tracing. The RRC connection setup procedure consists of the following steps:
 The UE sends the RRC Connection Request message through RACH.
 The RNC sends the RRC Connection Setup message through FACH.
 After the UE establishes and synchronizes the DL dedicated channel, it sends the
RRC Connection Setup Complete message through the UL dedicated channel.
The RRC setup failure is generally caused by the following reasons:
 UL RACH problem
 Ratio between the powers configured for PACH and pilot channel
 Configuration of cell reselection parameters
 Low initial DL TX power
 Initial UL power control
 Congestion
 Abnormal devices
Among all these problems, the UL RACH problem, DL FACH power configuration
problem, cell reselection parameter configuration problem, and device problem are more
likely to happen.
The following figure shows the flow to analyze RRC connection setup issue.

Analysis flow for RRC connection setup issue
Start to analyze
the RRC connection issue
Whether the UE
sends the request message? N The UE is abnormal.
Whether the RNC N Adjust the PRACH

receives the message? or AICH parameters.
Whether the RNC Whether the RNC

sends the setup N sends the RRC REJ message? N Other issues
message?
Conduct the congestion

Y Y and admission
inspection.
Whether the UE Whether the UE

receives the setup N performs the cell reselection?
N Adjust the FACH power.
message?
Y Y Optimize the cell

reselection parameters.
Whether the UE Adjust the initial

sends the setup N DL TX power.
complete message?
Whether the RNC Adjust the open loop

receives the setup N parameters of the
complete message? dedicated UL channel.
Y End

4.1.5.3.1 RNC Fails to Receive the RRC_CONNECTION_REQ

Message Sent by the UE
Under this condition, if the Ec/Io of DL CPICH is low, this problem is caused by the
coverage issue.
Check the sending of RACH preamble and reception of AI on the OMC. Check the
sending times of preamble and the last TX power. Check the AI information from the UE
log (0 represents success, 1 represents failure, and 2 represents rejection).
Check the value of TFCI and CRC of the RACH message on the NodeB, through which,
you can confirm whether the reception of the message fails.
These two problems may be caused by poor radio link quality, or the following two
reasons: registration of PLMN fails, or the PLMN is forbidden, and the UE detects the
forbidden PLMN, thus it does not send the RRC CONN REQ message. For details, see
TS 23.122. 3.1.
Under this condition, if the Ec/Io of DL CPICH is larger than -14 dB, this problem is
caused by the RACH. The general causes are as follows:
 The power ramp of Preamble is insufficient.
 The UE output power is lower than required.
 The NodeB is faulty, and VSWR exists.
 Setting of cell radius is improper.
If the power ramp of preamble is insufficient, increase the preamble power ramp times.
For example, change the preamble power ramp times from 8 to 20.
If the UE output power is lower than the required value, the UE is faulty. There is no
special solution for this problem.
If the NodeB is faulty, check whether the VSWR exists.
If the cell radius setting is too small, the NodeB cannot synchronize the UEs outside the
cell radius and access failures will happen. This mainly happens in wide coverage
scenarios, such as rural and suburban.
4.1.5.3.2 UE Fails to Receive the RRC_CONNECTION_SETUP

Message Sent by RNC
The possible causes are as follows:

 Poor coverage
 Improper setting of cell selection and reselection parameters
The specific inspection methods are as follows:
 Check the CPICH Ec/Io, if it is lower than -12 dB (default configuration), and there
is no cell with better Ec/Io within the monitoring set, the problem is caused by poor
coverage.
 If there is any cell with better Ec/Io within the monitoring set, the problem is caused
by cell reselection.
The solutions are as follows:
1. Poor coverage
Capture the UE log to see the data reception of the FACH channel. If most of the
received packets are incorrect, the link quality is bad, or the FACH TX power configured
by the RNC is low. In addition, you can estimate whether the signal quality is too bad by
checking the RSSI of the signals received by the UE. Meanwhile, check whether the
time window appears through the NodeB abnormal probes or packets captured at the
Iub interface. Since the RRC connection is established on FACH, you can capture the
UE logs to see the packets reception status of FACH. Later, the RNC would retransmit
the RRC_CONNECTION_SETUP message every 700 ms if the transmission fails. This
can help to increase the RRC setup success rate.
2. Cell selection and reselection
Adjust cell selection and reselection parameters to speed up the cell selection and
reselection. This can help to solve the RRC connection setup failures caused by
improper setting of cell selection and reselection parameters.
Note: The RRC CONNECTION SETUP message is borne by FACH. After the UTRAN
receives the PRACH preamble, the UE sends the RRC CONNECTION REQUEST
message through RACH using the preamble transmit power. However, the preamble
transmit power can ramp continuously till the UE receives the response. Note this is also
restricted by the maximum retransmission times of the preamble. Therefore in areas with
poor coverage, the coverage of RACH and FACH may be imbalanced, then the UTRAN
can receive the RRC setup requests sent by the UE, while the UE cannot receive the
RRC CONNECTION SETUP message sent by the RNC.

4.1.5.3.3 RNC Sends RRC Connection Reject Message after

Receiving RRC Setup Request Message Sent by the UE
After the RNC sends the RRC Connection Reject message, check the specific cause
value. The cause value in the RRC Connection Reject message can be divided into
two types, congestion or unspecified.
Congestion indicates that the network is congested. Check the network load, including
the occupancy status of power, codes, and CEs. Check whether the network congestion
is caused by insufficient resources, and then give the responding capacity expansion
solution.
The RRC connection admission principles for HSDPA and R99 users are consistent, and
they both include power, codes, and CEs. The access to code resources should be paid
special attention to. If the code words of HSDPA users are statically allocated, and too
many code words are allocated to them, the access to RRC connection of HSDPA or
R99 users may easily fail. This is because the code words for the DL signaling channel
of HSDPA or R99 users are insufficient.
If the cause value is unspecified, the related log information should be checked to
ascertain the cause.
4.1.5.3.4 UE Fails to Send Setup Complete Message After Receiving

RRC Connection Setup Message
Under this condition, if the quality of DL signals is normal, the access failure may be
caused by the faulty UE. Or the initial power of the DL dedicated channel is too low and
the DL cannot be synchronized. This problem can be solved by adjusting the DL Eb/No.
4.1.5.3.5 UE Sends the RRC Setup Complete Message, but the RNC
Fails to Receive the Message
Generally, the problem that the RNC cannot receive the

RRC_CONNECTION_SETUP_COMPLETE message can be confirmed by the Trace
function of the RNC, or can be confirmed by checking whether the NodeB reports the
Restore message. If the NodeB does not report the Restore message, the UL is not
synchronized. This may be caused by incorrect configuration of the open loop power.
Reset the UE or change a UE, if the access still fails, check whether the RLC parameter
is properly set and modify it if is not improper, for example, you can increase the
retransmission times.

Since the UL initial power control would make the UE TX power increase, this kind of
problem seldom happens. If this kind of problem appears, you can increase the Constant
Value of the dedicated channel appropriately, thereby increasing the initial TX power of
the UL DPCCH of the UE.
Meanwhile, this problem is also related with the setting of the ULInitSIR parameter,
which has great influence on the initial UL synchronization at the initial radio link setup
stage. If this parameter is too large, the UL interference would be too large at the initial
radio link setup stage; if this parameter is too small, the UL synchronization time would
be prolonged, and then the initial synchronization would fail. This parameter is the RNC-
level parameter, and would influence the network performance greatly. Therefore, be
cautious when adjusting the parameter.
Note:
The RRC CONNECTION SETUP COMPLETE message is sent through the UL DPCH,
and the UE would measure the initial power of UL DPCCH based on the received IE
DPCCH_Power_offset and measured CPICH_RSCP.
DPCCH_Initial_power = DPCCH_Power_offset - CPICH_RSCP
DPCCH_Power_offset = Primary CPICH DL TX Power + UL Interference + Constant

Value. Constant Value can be configured at the OMC. If the value is too small, then the
UE cannot provide enough power to send the RRC CONNECTION SETUP COMPLETE
message.
4.1.5.4 Authentication Issue Analysis
If the authentication fails, the engineer should analyze the cause value in the
authentication failure message sent by the UE. The cause value can be divided into
MAC Failure and Sync Failure.
4.1.5.4.1 MAC Failure
When the UE performs the network authentication, it checks the AUTN parameters in
the authentication request sent by the network. If the MAC information is incorrect, the
UE would report that the authentication fails, and the cause value is MAC Failure, as
shown in the following figure.

Authentication failure (MAC Failure)
Reasons may lead to authentication failures:
 Illegal subscribers
 The settings of Ki and OP (OPc) of the subscriber in the USIM card and those in
HLR are different, which leads to the authentication failure.
This problem usually happens when the user starts to use a new USIM card. To locate
this problem you can check whether the Ki value and OP (OPc) value in the IMSI of the
account nformation are the same. Since the Ki and OP (OPc) parameters are already
set in the USIM card, which cannot be read through the card reader, the engineer should
be well aware of the Ki and OP (OPc) parameters in the USIM card before opening an
account, or burn the Ki and OPc of the USIM card into the values in HLR.
4.1.5.4.2 Sync Failure
Another reason that may lead to authentication failure is that the UE detects the SQN in
the AUTN parameter is incorrect. The cause value is Sync Failure, as shown in the
following figure.

Sync failure
Reasons may lead to authentication failures:
 Illegal subscribers
 Equipment fault
4.1.5.5 Security Mode Issue Analysis
The security mode control procedure refers to the procedure that the CN sends the
encryption message to the RNC. During this procedure, the CN and RNC would encrypt
the UE, and then the UE would use this encryption algorithm in the later services. Even if
the UE is handed over to other RNCs, it would still try to use the encryption algorithm,
and the parameters related to the encryption algorithm would be sent to the target RNC.
The following figure shows the security mode command flow.
Security mode complete
The following figure shows the security mode reject flow:

Security mode reject
The following reasons may lead to security mode reject:
 The UE cannot support the encryption algorithm.
 The encryption modes configuration of the RNC and CN are inconsistent, for
example, the MSC is configured with encryption algorithm of UEA0 and RNC is
configured with UEA1.
4.1.5.5.1 UE Capability Issue
Check the capability of the UE in the RRC Connect Setup CMP message. Currently, the
following types of UEs do not support encryption: NEC single-mode cellphone, NEC
C606, and NEC C616. The following UEs support encryption: Nokia 7600, Nokia 6650,
Moto A835, Qualcomm 6200, Qualcomm 6250, and Siemens U15.
If the security mode is rejected because the UE does not support it, change the UE.
4.1.5.5.2 Mismatching Encryption Modes Between the RNC and CN
You have to check the encryption modes of the MSC/SGSN and RNC to see whether
the encryption modes match with each other. The encryption modes of the MSC/SGSN
must be the same as that of the RNC.
If the encryption modes are different, set the MSC and SGSN to support all encryption
modes, and set the encryption modes of RNC to UEA0 or UEA1 based on the actual
condition.
4.1.5.6 PDP Activation Issue Analysis
The PDP activation failure refers to that the UE receives the Activate PDP Context
Reject message after sending the Activate PDP Context Request message. The
access failures are mainly caused by problems at the CN side or incorrect setting of the
APN or rate at the UE side.

1. Access failures caused by the APN setting at the UE side
If the cause value of Activate PDP Context Reject is Missing or unknown APN,
the access failure is because that the APN setting at the UE side is inconsistent
with that at the CN side. Check the APN setting at the UE side.
2. Access failures caused by the rate setting at the UE side
If the cause value of Activate PDP Context Reject is Service option not
supported, the access failure is caused by the fact that rate requested by the UE is
higher than the rate subscribed when opening the account. Check the rate setting
at the UE side, and compare the setting with the rate subscribed when opening the
account (stored in the HLR). Confirm the APN and applied rate in the Activate PDP
Context Request message.
3. Access failure caused by the CN
If the cause values are not the values mentioned in the previous part, and the
settings of APN and rate at the UE side are correct, the access failure may be
caused by the CN, for example, some interfaces of the CN are blocked. Under this
condition, you can contact the engineer in charge of the PS domain of the CN to
locate the problem.
In addition, if this is the first time to debug the PS services, the access failure may
be caused by the fact that the APN setting at the HLR is inconsistent with that in
GGSN, contact the engineer in charge of the PS domain of the CN to solve this
problem.
4.1.5.7 RAB or RB Setup Issue Analysis
If the RAB or RB setup fails, the RNC would return RAB assignment failure in the RAB
Assignment Response message. You can locate the specific cause value in the related
cell.
Issues that may lead to RAB/RB setup failure:
 The RNC rejects the RAB setup request since the parameters are incorrectly
configured.
 Access is denied.
 RAB setup fails because the UE returns RB setup failure.
 The RB setup at the air interface fails, which leads to the RAB setup failure.

4.1.5.7.1 The RNC Rejects the RAB Setup Request Since the
Parameters are Incorrectly Configured
This problem seldom happens in commercial network, and is generally caused by

operations of some special subscribers. Scenario: The UL account opening request and
activation application for the PS services has exceeded the capability of the UE, which
makes the RNC reject the RAB setup request. For example, the subscribed capacity of a
UE is 384 K at both the UL and DL, while the UE only supports 64 K at the UL, when the
user sends the AT command or uses the cellphone software (for example on the
SonyEricssion cellphone) to set the maximum UL/DL rate to 384 K in the QoS message
(for activating the PDP), then the RNC finds out that the requested maximum UL rate
exceeds the UE capability, and would return RAB setup failure.
The parameter configuration has exceeded the UE capability, which leads to the RAB
setup failure. The SGSN would renegotiate and send new RAB assignment request till
the request can be supported by the UE. Then the RAB assignment is completed. For
the user, the PDP can be successfully activated, and the acquired maximum UL rate is
the maximum rate that the UE can support. When the minimum guaranteed rate in the
QoS setting of the UE PDP activation request has exceeded the UE capacity, the
network would accept the UE PDP activation request with a comparatively low rate after
the network negotiation. However, when the UE finds out the negotiated rate is lower
than the minimum guarantee rate, it would send the PDP activation request again, which
would lead to PDP activation failure.
4.1.5.7.2 Access is Denied
For non-HSDPA users, their access to the network would be denied when the system
resources are insufficient, including power, channel codes, Iub transmission resources,
and Credit. This would lead to call setup failure. Under this condition, check the network
load, including the occupancy status of power, codes, Iub transmission resources, and
CE. Check whether the network congestion is caused by insufficient resources, and then
give the responding capacity expansion solution.
1. When the code words for HSDPA users are statically allocated, and too many code
words are allocated to HSDPA users, the access of non-HSDPA users would easily
fail. This is because the code words for the DL signaling channel are insufficient.
When the system resources are insufficient, and the access is denied, the RNC
(with version later than 1.5) can take different measures based on the setting of
RAB Downsizing Switch. For details, see scenario 3.
2. When the cell does not support the HSDPA services, the network access of R99
users is based on the admission threshold for R99 users. When the cell support the
HSDPA services and the power for HSDPA and R99 are statically allocated, the DL
admission power of non-HSDPA users is based on the formula: (Total power of the
cell – Power statically allocated to HSDPA) x Admission threshold. If the HSDPA

and R99 powers are dynamically allocated, the DL power admission threshold for
the non-HSDPA users still uses that for R99 users. The UL admission threshold is
based on the RTWP or the equivalent user number. If the UL load is too heavy, the
admission of the non-HSDPA users would fail.
3. When the bandwidth of the Iub interface is insufficient, if the user activates the R99
high-speed data services, the request would be denied for insufficient bandwidth at
the Iub interface. For example, if the transmission resources of one network are
insufficient, the AAL2 bandwidth of many cells only can support one 384 K service.
If one 12.2 K voice services already exist on AAL2, and the user wants to activate
the PS384K service, the Iub interface cannot provide sufficient bandwidth. For
RNC1.3, it would return SGSN RAB assignment failure, and the cause value in the
RAB Assignment Response message is that the applied rate cannot be provided,
and then the SGSN would renegotiate and send the RAB assignment request
again. For RNC1.5 or later versions with the RAB Downsizing Switch set to ON, it
would first reduce the rate. Then if the RNC can acquire the Iub resources, it
returns the RAB assignment success message to SGSN. If the RNC still cannot
acquire the Iub resources after the rate is reduced to 8 K, the RNC would return
RAB assignment failure message to SGSN. SGSN would determine whether to
start the negotiation based on its parameter setting.
For HSDPA users, the following conditions may also lead to access deny.
HSDPA and R99 static power allocation mode: Whether the following factors has
exceeded the threshold, such as HSDPA users supported by the NodeB, HSDPA users
supported by the cells, total bit rate of the cells, total guaranteed bit rate, and power to
ensure the guaranteed bit rate.
HSDPA and R99 dynamic power allocation mode: Whether the HSDPA users supported
by the NodeB or cell exceed the threshold.
For HSDPA users, when the bandwidth configured at the Iub interface is insufficient,
though their access would not be denied, their rate would be reduced. The AAL2PATH
for HSDPA and R99 are configured respectively, and the HSDPA AAL2PATH must be
configured as HSDPA_RT or HSDPA_NRT. If HSDPA AAL2PATH is configured as RT or
NRT (R99 AAL2PATH types), no RAB assignment failure would happen; however the
RNC would reduce the rate of HSDPA services to R99 384 Kbps.
4.1.5.7.3 UE Returns RB Setup Failure, which Leads to RAB Setup

Failure
The reason that the UE returns RB setup failure is incorrect user behavior.
There are two scenarios:

Scenario one: The UE already has 128 K data services in the DL; at that moment, it
receives the RB setup request from VP (either originating or terminating). Since most
UEs cannot simultaneously support the VP and high-speed PS services on the DL, it
returns the RB setup failure message, with cause value of unsupported configuration.
Scenario two: The 3G originating UE conducts the VP call, but the called party is in the
GSM network, and does not support the VP services. Then after the RNC receives the
RAB assignment request, the CN sends the Disconnect command after Call
Proceeding, and the cause value is Bearer capability not authorized. At this moment,
the UE has just received the RB_SETUP command, and has not finished the RB setup
yet. After receiving the Disconnect command, it sends RB setup failure, and the RNC
returns RAB setup failure, and the cause value is failure in radio interface procedure.
4.1.5.7.4 RAB Setup Failure Caused by RB Setup Failure at Air

Interface
RB setup failure may also be caused by that the UE does not respond the RB setup
command, then the RNC believes that the RB setup is failed. The failure phenomenon is
that the after the RNC sends the RB setup command, it fails to receive ACK or the RB
setup complete message. This problem mainly happens in areas with poor signal quality.
Two reasons may lead to poor signal quality, which are the UE is not at the optimal cell
when initiating the network access, or the coverage is poor.
When the UE initiates the network access when it is not camped on the optimal cell, it
would try to upgrade the active set to camp on the optimal cell. However, different
processes cannot be embedded together (both the network and the UE do not support),
the upgrade of active set can be performed only after RB setup is completed. Then, the
RB setup is performed in cells with poor signals, and may easily fail. To solve this
problem, you have to increase the activation threshold and rate for the co-channel cells
reselection, so that the UE can camp on the optimal cell and access the network from
this cell. For the network at the early stage with little network load, the UE co-channel
cell reselection activation threshold can be set to -4 dB, and the Treselction can be set to
1. For cells at the border of different LACs, these parameters can be set to a smaller
value to reduce the signaling flow of location upgrade.
The RB setup failure caused by poor coverage can be divided into two types: poor UL
signal quality and poor DL signal quality. If the coverage issue is caused by poor DL
coverage, the UE cannot receive the RB setup command. The poor coverage in the DL
is caused by the demodulation capacity of the UE or the RF performance. If the
coverage issue is caused by the poor UL coverage, the UE receives the RB setup
command, but the RAN cannot receive the ACK or RB setup complete message. This
may be caused by UL interference, and can be ascertained by checking RTWP.

4.1.5.8 Access Issues for Dual-Carrier Network
There are two types of networking mode for dual-carrier network.
 Scenario one: F1 uses R99 networking and F2 uses R99+HSDPA hybrid

networking.
 Scenario two: Both F1 and F2 use R99+HSDPA hybrid networking.
The network access of a single-carrier network has already been discussed in the
previous part, and the following part would only focus on the network access issue of the
dual-carrier network.
The network access of dual-carrier network includes the directed retry and redirection at
the RRC connection stage, and the RAB directed retry. The RAB directed retry consists
of the retry based on the services and the retry after the admission fails. The directed
retry and redirection algorithms can be used to improve the call successful setup rate fo r
the UE.
The following figure shows the RRC directed retry and redirection process at the RRC
connection setup stage.

RRC directed retry and redirection
UE RNC
1. RRC CONNECTION REQUEST
Y
Whether the resource
application succeeds?
Whether the N
candidate cell
exists? RRC directed retry estimation
No candidate
cell exists.
RRC directed retry estimation Redirection
estimation
Redirection
2 RRC CONNECTION REJECT
2 RRC CONNECTION SETUP
3 RRC CONNECTION SETUP COMPLETE
After receiving the request from the RRC, the RNC would use the admission algorithm to
calculate whether to allow the UE to establish RRC connection with the current cell
based on the cell load.
1. If the estimation result is Allow, the RNC would send the RRC CONNECTION
SETUP message to the UE to inform the UE to establish RRC connection.
2. If the estimation result is Reject, the RNC would use the directed retry algorithm
model to search for the cell satisfying the directed retry algorithm in the UE
candidate cell list. If cell satisfying the criteria exists, the RNC would send the target
cell information to the UE through the RRC CONNECTION SETUP message. If no
cell satisfies the criteria, the RNC redirection algorithm would search different
frequencies or radio access system (such as GSM), and send REDIRECTION to
the UE through the RRC CONNECTION REJECT message. The UE would resend
the access request at the specified frequency or system.

The RAB directed retry consists of the directed retry based on the services and directed
retry after the admission fails.
1. Directed retry based on services
Among the co-channel cells that cover the same area, if both R99 cells and HSDPA
cells exist, the users applying for R99 services should be distributed to R99 cells,
and the users apply for HSDPA services should be allocated to HSDPA cells, then
the R99 and HSDPA services can be allocated to different layers.
2. Directed retry after the admission fails
After the admission of the user fails, the UE can try to access the co-channel cells
which cover the same area, HCS inter-frequency cells, or inter-RAT cells (only for
AMR services).
If the admission of HSDPA services fails, and the directed retry also fails, the UE
can return to the DCH of this cell, and establish the RAB connection on the DCH.
As to scenario one of dual-carrier network, the current cell camping strategy is that the
UEs are preferentially camped on R99 cells. This can help to ensure that no inter-
frequency directed retry is required when the real-time services are initiated, which can
help to reduce the impact on the real-time services. Meanwhile, the HSDPA users can
be distributed to HSDPA cells through the directed retry based on services. Set the cell
selection and reselection parameter Qoffset2, n of f1 frequency to 20 dB, and Qoffset2,
n of f2 frequency to -20 dB. Meanwhile, change the inter-frequency reselection activation
threshold of f2 frequency to 8. As to scenario two of dual-carrier network, the cell
camping strategy is that the UEs are randomly camped on different cells. The UE would
access the network from the cell where the services are camped. All dual-carrier cells
use the default cell selection and reselection parameter.
In the above two networking scenarios, after the access fails, the R99 users would
perform the RRC or RAB directed retry, and the HSDPA users would perform the RAB
directed retry. If the directed retry of HSDPA services also fails, then the services would
return to the DCH of the local cell, and establish the RAB connection on the DCH.
4.2 Access Performance Analysis Through Traffic

Statistic Data
The traffic statistic data analysis is usually applied in the following two scenarios:
 Estimate the network performance, locate the KPIs that do not satisfy the network
performance requests, find the root cause, and improve the network performance.
 Early warning for the network performance: It can help to discover the factors that
may deteriorate the network performance in advance, and prevent the
deterioration.

This chapter would focus on scenario one and introduce how to analyze traffic statistic
data. The following part would introduce the analysis procedure and methods.
4.2.1 General Methods to Analyze Traffic Statistic Data
The traffic statistic data analysis can be divided into RNC-level and cell-level based on
the different statistic objects. The RNC-level data analysis focuses on the estimation and
analysis of the KPIs of the whole network. The cell-level data analysis focuses on
locating of abnormal cells. The cell-level data analysis flow is included in the RNC-level
data analysis flow.
In the practical application of traffic statistic analysis, the KPIs of the whole network
would first be estimated, and then the cell-level problems would be located. Therefore, in
RNC traffic statistics, the counters of failure causes are mostly of the cell level. In this
chapter, the analysis and location of the problem are mostly based on the cell-level KPIs.
4.2.1.1 RNC-Level Data Analysis Flow
RNC-level data analysis flow
First, check whether the RNC-level traffic statistics satisfy the requirement. If yes, the
analysis is completed. If not, the first N cells with worst KPIs should be located, and their

KPIs should be analyzed. After the cell faults are located and solved, analyze the new
traffic statistic data. If the traffic statistics satisfy the requirement, the analysis is
completed. If the problem still exists, repeat the steps till the KPIs satisfy the
requirement.
For details on the analysis method and flow about the abnormal cells, see the cell-level
data analysis flow.
4.2.1.2 RNC-Level Data Analysis Flow
Cell-level data analysis flow
First, check whether the cell does not satisfy the requirement exists. If no, the analysis is
completed. If yes, analyze the refined cause value, and find the main reason that leads
to the KPI deterioration, and give the corresponding solution. After the solution is
implemented, check the new traffic statistic data till all KPIs are satisfied.
4.2.2 Access Indexes Should be Analyzed During Traffic Statistics
4.2.2.1 Paging Class Traffic Statistic Indexes
When the CN pages the UE, it would send the PAGING message to the RNC. After the
RNC receives the message, it would send the PAGING TYPE 1 message or the
PAGING TYPE 2 message based on the UE state.

If the paged UE is at the IDLE, CELL_PCH, or URA_PCH states, the RNC would send
the PAGING TYPE 1 message to cells within the paging area. The PAGING TYPE 1
message is sent in the Paging Control Channel (PCCH).
If the paged UE is at the ICELL_FACH or CELL_DCH state, the RNC would send the
PAGING TYPE 2 message to the UE. The PAGING TYPE 2 message is sent in the
Dedicated Control Channel (DCCH).
UMTS Terrestrial Radio Access Network (UTRAN) can send the PAGING TYPE 1
message to the UE at IDLE, CELL_PACH, or URA_PCH states to trigger the UE to
modify the system information. Meanwhile, UTRAN can send the PAGING TYPE 1
message to the UE at CELL_PCH or URA_PCH states to trigger the UE to perform the
state migration to support the data transmission.
When the UE at the IDLE status receives the PAGING TYPE 1 message, it would send
the RRC CONNECTION REQUEST message to establish the RRC connection. When
the UE at CELL_PCH or URA_PCH state receives the PAGING TYPE 1 message, it
would send the CELL UPDATE message to the RNC, and the cause value is paging
response. For details, see 3GPP TS 25.331 and 3GPP TS 25.413.
The paging traffic statistics can be analyzed on the basis of the following KPIs:
 Paging loss of the UE (at IDLE state)
 Paging loss of the UE (at PCH state)
 Flow control
 PCH congestion
4.2.2.1.1 Paging Loss of the UE at IDLE State
As mentioned before, if the paged UE is at the IDLE state, the RNC would send the
PAGING TYPE 1 message to cells within the paging area. Therefore, this index is
counted on the basis of the RNC.
The counters are shown in the following figure.

Counters related to the paging loss of UEs at IDLE state
After the RNC receives the PAGING message from the CN, if the paged UE is at IDLE
state, it would send the PAGING TYPE 1 message to cells within the paging area
through the RNC. VS.RANAP.Paging.Att.IdleUE would be counted at point B.
After the RNC receives the RRC CONNECTION REQUEST message from the UE, if the
reason for the RRC connection setup is Terminating Conversational Call, Terminating
Streaming Call, Terminating Interactive Call, Terminating Background Call, Terminating
High Priority Signaling, Terminating Low Priority Signaling, or Terminating cause
unknown. VS.RANAP.Paging.Succ.IdleUE would be counted at point C.
Generally, the following reasons will lead to paging losses for UE at IDLE state:
 For the parameter configuration, you should check whether the configuration of the
paging related parameters comply with the baseline parameter configuration
requirement.
 The paging cannot be performed in areas with poor coverage, such as the indoor
areas with no coverage and blind spots, like the elevator.
4.2.2.1.2 Paging Loss of the UE at PCH State
As mentioned before, if the paged UE is at CELL_PCH or URA_PCH state, the RNC

would send the PAGING TYPE 1 message to all cells within the paging area. Then, the
UE would transit the state and support the data transmission. Therefore, this index is
counted on the basis of the RNC.

Counters related to the paging loss of UEs at PCH state
When the RNC sends the PAGING TYPE 1 message to UEs at CELL_PCH or
URA_PCH states, the VS.UTRAN.Paging1.Att would be counted at point A.
After the UE at CELL_PCH or URA_PCH state receives the PAGING TYPE 1 message,
it would send the CELL UPDATE message to the RNC with cause value of paging
response. After the RNC receives the CELL UPDATE message with cause value of
paging response, VS.UTRAN.SuccPage1 would be counted at point B.
Note:
The KPIs mentioned in the above part does not count the times that RNC sends the
PAGING TYPE 1 message (to inform the UE to change the system information).
Generally, the following reasons may lead to paging losses for UEs at the PCH state:
Parameter configuration: check whether the configuration of the paging related

parameters comply with the baseline parameter configuration requirement.
Coverage: The paging cannot be performed in areas with poor coverage, such as the
indoor areas with no coverage and blind spots, like the elevator.
4.2.2.1.3 Flow Control
When the Iu interface is at the flow control status, it would discard the paging message
sent by the CN. The following part shows the counters related to traffic statistics:
When the RNC receives the PAGING message sent by the CN, if the Iu interface is at
streaming control status, this PAGING message will be discarded, and the discarded
times would be counted.
When this problem happens, the network traffic volume must be very high, a capacity
expansion early warning should be issued.

4.2.2.1.4 PCH Channel Congestion
When the RNC receives the PAGING message sent by the CN, if the current paging
traffic volume has exceeded the maximum PCH capacity, the PCH channel would be
congested, and the paging message would be discarded.
If this problem happens, the paging volume of the cell must have reached the limit,
check the configuration of the repeated paging and the configuration of paging channel.
If this problem is caused by large traffic volume, you can solve this problem by splitting
the location area.
4.2.2.2 RRC Setup Success Rate
This section analyzes the causes that may lead to low RRC setup success rate, and
introduces the traffic statistics reflecting these causes and the related solutions.
In traffic statistics, the reasons that may lead to RRC connection failure can be divided
into the following types:
 The RRC connection request is rejected for the Iub interface failure.
 The RRC connection request is rejected for network congestion.
 The RRC connection fails for no response is received.
 The RRC connection fails for redirection.
From the RNC side, the RRC connection failures can be divided into two kinds:
Scenario one: When the RNC receives the RRC Connection Request message from
the UE, it would send the RRC Connection Reject message to the UE. Two kinds of
indexes are related to this scenario, which are “The RRC connection request is rejected
for the Iub interface” and “The RRC connection request is rejected for network
congestion.” The counter is shown by point A in the following figure.
Counter related to RRC connection rejection

Scenario two: After the RNC sends the RRC CONNECTION SETUP message, it does
not receive the RRC CONNECTION SETUP COMPLETE message or receives the RRC
CONNECTION SETUP FAILED message from the UE. The “The RRC connection fails
for no response is received” index is involved in this scenario.
4.2.2.2.1 RRC Connection Request is rejected for the Iub Interface

Failure
The scenario that the RRC connection request is rejected for the Iub interface can be
caused by the following types of reasons:
 Rejection of RRC setup request caused by RL setup failure
 Rejection of RRC setup request caused by AAL2 setup failure
1. Rejection of RRC setup request caused by RL setup failure
The RL setup failure seldom happens, and the possible causes are as follows:
Hardware failure of the NodeB, for example, the power amplifier is too hot (seldom
happens).
The NodeB CE number is limited. When the estimation of NodeB credits is

inaccurate and cannot reflect the actual occupancy status of the NodeB CEs, the
RNC would believe that the NodeB CEs are sufficient and send RL setup message
to the NodeB. The NodeB returns RL setup failure for the restriction of CEs.
If the RRC connection setup failure caused by the RL setup failure appears, check
the cell load status and ensure that the failure is not caused by insufficient CE
number. Check whether the equipment reports any alarm, and ensure that the
failure is not caused by the malfunction of air conditioners and power amplifiers.
For example, in the network of one operator, the RRC connection is rejected for
several hundreds of times at one time segment owing to this cause value. Later, the
engineer finds out that the over-heated alarm exists on the NodeB. Therefore, the
rejection may be caused by network load increasing or the ambient temperature,
such as the malfunction of the air conditioning system. If this problem does exist,
contact the NodeB maintenance engineer, otherwise the access and handover
success rate would be impacted.
2. Rejection of RRC setup request caused by AAL2 setup failure
AAL2 setup failure only happens when the AAL2 resources are limited, or the cell
malfunctions.

4.2.2.2.2 RRC Connection Request Rejection for Network

Congestion
For RRC connection failure caused by network congestion, check which type of
resources is insufficient. The radio resource congestion can be divided into the following
types:
 Power resources application failure
 UL CE resources application failure
 DL CE resources application failure
 Code resources application failure
The following part shows the counters related to traffic statistics:
1. Power resources application failure
If the application for the power resources fails, check whether the admission
parameters are set to the default value. If the parameters are reasonably set, you
can check the network load through the counters, such as traffic load and
equivalent user number. If the network load and the congestion rate have met the
capacity expansion requirement, perform the capacity expansion.
2. UL/DL CE resources application failure
It indicates the NodeB CE resources are insufficient. Check the configuration of the
NodeB CE resources based on the current traffic load.
3. Code resources application failure
It indicates the NodeB CE resources are insufficient. Check the configuration of the
NodeB CE resources based on the current traffic load.
4.2.2.2.3 RRC Connection Failure for Receiving no Response
The following two types of reasons may lead to this problem:
 The UE fails to receive the RRC CONNECTION SETUP message sent by the
RNC.
This may be caused by weak coverage, or improper configuration of cell selection

and reselection parameters. For details, see section 4.1.5.3.2 “UE Fails to Receive
the RRC_CONNECTION_SETUP Message Sent by RNC.”

 The UE sends the RRC CONNECTION SETUP COMPLETE message, but the
RNC fails to receive it.
This may be caused the low initial TX power of the UL dedicated channel. For
details, see section 4.1.5.3.5 “UE Sends the RRC Setup Complete Message, but
the RNC Fails to Receive the Message.”
4.2.2.2.4 Rejection of RRC Connection Request for Redirection
After the UE sends the RRC connection setup request, if the cell is congested or the
resource allocation fails and the RRC redirected retry also fails, the redirection algorithm
is triggered. If the cell that the UE tries to access has inter-frequency neighbor cells or
GSM neighbor cells, it would redirect the UE to inter-frequency neighbor cell or GSM cell
through Redirection info of the RRC connection reject message. If the cell is not
configured with inter-frequency or GSM neighbor cells, no Redirection info is
configured in the RRC connection reject message.
4.2.2.3 CS RAB Setup Success Rate
This index can help to learn the RAB setup success rate in the CS domain of the
RNC/Cell. The numerator and denominator counters in the KPI formula are classified
based on the CS services types, which are AMR, Video, 32 K voice services, voice
services of other rates, and CS data services. Meanwhile, the numerator counters can
be further divided into with queuing or without queuing types. The numerator represents
RAB successful setup times, and the denominator is the attempted RAB setup times.
Formula:
RAB Setup Success Rate (CS) = SUM (RNC/Cell data. The number of successful CS
RAB establishment. All sub measurement items) / SUM(RNC/Cell data. The number of
requested CS RAB establishment. All sub measurement items)
In the current traffic statistic data, the following items would lead to CS RAB setup
failure:
 Radio network causes
 Transmission network causes
The counters related to CS RAB assignment failure is shown in the following figure.

Counters related to CS RAB assignment failure
In this figure, point B represents that when the RNC sends the RAB ASSIGNMENT
RESPONSE message to the CN indicating the failure of RAB assignment, the counter
would count the number based on the specific reason. In this figure, the RB setup is
marked by dotted lines, which represents that this flow is optional.
4.2.2.3.1 Radio Network Causes
The RAB setup failure caused by radio network can be divided into the following types:
 CS RAB setup failure caused by relocation
 CS RAB setup failure caused by the radio interface procedure
 CS RAB setup failure caused by insufficient capability
 CS RAB setup failure caused by other radio network problems
1. CS RAB setup failure caused by relocation
The RNC receives the RAB ASSIGNMENT REQUEST message from the CN when
it is performing the relocation. Then, the RNC would neglect the message, and
returns RAB ASSIGNMENT REPONSE to the CN indicating the failure of RAB
assignment, and the cause value is Relocation Triggered. This seldom happens,
and can be neglected.
2. CS RAB setup failure caused by the radio interface procedure
When the RNC receives the RB Setup Failure message sent by the UE, it would
return RAB Assignment Response to the CN, with cause value Failure in the
Radio Interface Procedure.

For this problem, you must analyze the failure causes.
3. CS RAB setup failure caused by insufficient capability
This problem might be caused by the following reasons:
 Requested Traffic Class not Available (18)
 Requested Maximum Bit Rate not Available (20)
 Requested Maximum Bit Rate for DL not Available (33)
 Requested Maximum Bit Rate for UL not Available (34)
 Requested Guaranteed Bit Rate not Available (21)
 Requested Guaranteed Bit Rate for DL not Available (35)
 Requested Guaranteed Bit Rate for UL not Available (36)
 Requested Transfer Delay not Achievable (22)
This index usually appears when the cell is congested, such as Requested
Maximum Bit Rate not Available. Note that the following types of “failure caused
by radio resource congestion” will trigger this index:
 Rejection of CS RAB caused by insufficient power
 Rejection of CS RAB caused by insufficient UL CEs
 Rejection of CS RAB caused by insufficient DL CEs
 Rejection of CS RAB caused by insufficient code resources
 Rejection of CS RAB caused by insufficient bandwidth at Iub
Check the related index to ascertain the specific causes of the problem, and
provide the corresponding capacity expansion solution.
4. CS RAB setup failure caused by other radio network problems
The CS RAB assignment failure may also be caused by other factors, such as no
response for RB setup request.
Under this condition, you cannot locate the cause directly through the traffic
statistics. Then DT or other test methods can be used to locate the cause.
4.2.2.3.2 Transmission Network Causes
 Signaling Transport Resource Failure(65)
 Iu Transport Connection Failed to Establish(66)

If these indexes appear, the transmission network is faulty. Check whether the
transmission at the Iu interface is abnormal.
4.2.2.4 PS RAB Setup Success Rate
This index can help to learn the PS RAB setup success rate within the RNC/Cell. This
index partially reflects the user perception within the RNC. The numerator and
denominator counters in the KPI formula are classified based on the PS services types.
Meanwhile, the numerator counters can be further divided into with queuing or without
queuing types. The numerator represents RAB successful setup times, and the
denominator is the attempted RAB setup times.
Formula:
RAB Setup Success Rate (PS) = SUM (RNC/Cell data. The number of successful PS
RAB establishment. All sub measurement items) / SUM(RNC/Cell data. The number of
requested PS RAB establishment. All sub measurement items)
In the current traffic statistic data, the following items would lead to PS RAB setup
failure:
 Radio network causes
 Transmission network causes
 No available resources causes
 Other causes
The counters related to PS RAB assignment failure are shown in the following figure.

Counters related to PS RAB assignment failure
In this figure, point B represents that when the RNC sends the RAB ASSIGNMENT
RESPONSE message to the CN indicating the failure of RAB assignment, the counter
would count the number based on the specific reason. In this figure, the RB setup is
marked by dotted lines, which represents that this flow is optional.
4.2.2.4.1 Radio Network Causes
The RAB setup failure caused by radio network can be divided into the following types:
 PS RAB assignment failure caused by incorrectly configured parameters
 PS RAB setup failure caused by relocation
 PS RAB setup failure caused by the radio interface procedure
 PS RAB setup failure caused by insufficient capability
 PS RAB setup failure caused by other radio network problems
1. PS RAB assignment failure caused by incorrectly configured parameters
This index seldom happens, and can be neglected.
2. PS RAB setup failure caused by relocation
The RNC receives the RAB ASSIGNMENT REQUEST message from the CN when
it is performing the relocation. Then, the RNC would neglect the message, and
return RAB ASSIGNMENT REPONSE to the CN indicating the failure of RAB
assignment, and the cause value is Relocation Triggered. This seldom happens,
and can be neglected.

3. PS RAB setup failure caused by the radio interface procedure
When the RNC receives the RB Setup Failure message sent by the UE, it would
return RAB Assignment Response to the CN, with cause value Failure in the
Radio Interface Procedure.
For this problem, the failure causes must be analyzed.
4. PS RAB setup failure caused by insufficient capability
 Requested Traffic Class not Available (18)
 Requested Maximum Bit Rate not Available (20)
 Requested Maximum Bit Rate for DL not Available (33)
 Requested Maximum Bit Rate for UL not Available (34)
 Requested Guaranteed Bit Rate not Available (21)
 Requested Guaranteed Bit Rate for DL not Available (35)
 Requested Guaranteed Bit Rate for UL not Available (36)
 Requested Transfer Delay not Achievable (22)
This index usually appears when the cell is congested, such as Requested
Maximum Bit Rate not Available. The specific reason can be located in CDL.
Note that the following types of “failure caused by radio resource congestion” will
trigger this index:
 Rejection of PS RAB caused by insufficient power
 Rejection of PS RAB caused by insufficient UL CEs
 Rejection of PS RAB caused by insufficient DL CEs
 Rejection of PS RAB caused by insufficient code resources
 Rejection of PS RAB caused by insufficient bandwidth at Iub
5. PS RAB setup failure caused by other radio network problems
The PS RAB assignment failure may also be caused by other factors, such as no
response for RB setup request.
Under this condition, you cannot locate the cause directly through the traffic
statistics. Then DT or other test methods can be used to locate the cause.
4.2.2.4.2 Transmission Network Causes

 Signaling Transport Resource Failure(65)
 Iu Transport Connection Failed to Establish(66)
4.2.2.4.3 No Resources Available
The following reason would lead to PS RAB setup failure:
 No resource available
Here, resource refers to the equipment resource rather than radio layer resources( such
as power, codes, and CEs). This seldom happens, and can be neglected.
For HSDPA services, the cause for low RAB assignment success rate is the same as
that for low R99 PS RAB assignment success rate, thus would not be repeated here.
The traffic statistic indexes for PS RAB including both that for R99 PS services and
HSDPA services.
4.2.2.5 RB Setup Success Rate
In the current version, no counter is created for the RAB setup failure caused by RB
setup failure. And the causes for RB setup failure in CS and PS domains are not
distinguished yet, therefore, we cannot build a one-to-one corresponding relation
between the traffic statistic items for RB setup failure and RAB setup failure.
The following two types of reasons may lead to low RB setup success rate:
 RB setup failure
 No response for RB setup request
4.2.2.5.1 RB Setup Failure
RB setup failure refers to that the RNC receives the RB Setup Failure message after
sending the RB Setup message. The possible causes can be further divided into the
following categories:
 Configuration unsupported
 Physical channel failure
 Cell update occurred
 Invalid configuration
The counter related to RAB setup failure is shown in the following figure.

Counter related to RAB setup failure
As shown by point A, after the RNC receives the RADIO BEARER SETUP FAILURE
message sent by the UE, it starts to count in the cell where the UE is camped based on
the RB setup failure causes.
 Configuration unsupported
This is mainly caused by incorrect user behaviors: The UE already has 128 K data
services in the DL; at that moment, it receives the RB setup request from VP (either
originating or terminating). Since most UEs cannot support the VP and high-speed
PS services simultaneously on the DL, it returns the RB setup failure message, with
cause value of unsupported configuration.
 Physical channel failure
This problem seldom happens.
 Cell update occurred
The cell of the UE is updated during the RB SETUP procedure. This problem
seldom happens.
 Invalid configuration
This problem frequently happens. It refers to the following conditions: The

originating 3G UE conducts the VP call, but the terminating UE is in the GSM
network, and does not support the VP services. After the RNC receives the RAB
assignment request, the CN sends the Disconnect command after Call
Proceeding (cause value: Bearer capability not authorized). At this moment, the
UE receives the RB_SETUP command and has not started the RB setup yet, then
it returns the RB setup failure. Then, the RNC returns the RAB setup failure.

4.2.2.5.2 No Response to RB Setup
This problem frequently happens. It refers to that the UE fails to receive the RB SETUP
message or the RNC does not receive the response from the UE. Then the RNC
believes that the RB setup fails. This problem mainly happens in areas with poor signal
quality. Two reasons may lead to poor signal quality, which is the UE is not at the optimal
cell when initiating the network access, or the coverage is poor.
When the UE initiates the network access when it is not camped on the optimal cell, it
would try to upgrade the active set to camp on the optimal cell. However, different flows
cannot be embedded together (both the network and the terminal do not support), the
upgrade of active set can be performed only after RB setup is completed. Then, the RB
setup is performed in cells with weak signals, and may easily fail. To solve this problem,
increase the activation threshold and rate for the co-channel cells, so that the UE can
camp on the optimal cell and access the network from this cell. For the network at the
early stage with little network load, the UE co-channel cell reselection activation
threshold can be set to -4 dB, and the Treselction can be set to 1. For cells at the border
of different LACs, these parameters can be set to a smaller value to reduce the signaling
flow of location upgrade.
The RB setup failure caused by poor coverage can be divided into two conditions: poor
UL signal quality and poor DL signal quality. If the coverage issue is caused by poor DL
coverage, the UE cannot receive the RB setup command. The poor coverage in the DL
is caused by the demodulation capacity of the UE and the RF performance. If this
problem is caused by the poor UL coverage, the UE receives the RB setup command,
but the RAN cannot receive the ACK or RB setup complete message. This may be
caused by UL interference, and can be ascertained by checking the RTWP.

5 Access Performance Optimization Cases
5.1 UE Access Failure Caused by Incorrect Configured

Cell Radius
5.1.1 Phenomenon
In DT, we find that the UE can search for the cells but cannot access the network near
the market. The UE can normally search for the cells. Its RTWR rises when dialing the
number, but the access fails.
5.1.2 Analysis
From the above analysis, we can see that the DL is normal, and the RTWP rises,
therefore the UE must have sent the RRC connection request. Perform the following
steps to check this issue:
1. Check the cell and PRACH configurations, and the checking result is OK.
2. Check the noise figure of the target cell, and the checking result is OK.
3. Check the access statistics of the target cell, and no user accesses the network.
Check the related UL FPGA register value. The result is OK, and the UL channel is
normal. The reception of the system information in the DL is also OK.
4. The field engineer checks the network access near the base station and finds out
that only the coverage at the cell edge is bad. Then the engineer checks the cell
radius setting, which is 5000 m. Since the base station is at the top of the mountain,
the coverage radius is very large. The engineer changes the cell radius to 10 km,
and then the problem disappears.
The cell radius reflects the cell size.
The setting of the RRU cell radius should be the sum of 1.5 times of the distance
between the BBU and the RRU and the coverage radius of the cell. By doing this, we
can compensate the delay brought by the remote installation of the RRU. The 1.5 times
of the distance between the BBU and the RRU is to compensate for the refraction in the
optical fiber.

5.1.3 Result
After the cell radius is modified, the UE can access the network.
5.2 Case Study – CS Access Delay

In one project, the RNC is provided by our company, the CN is provided by Huawei, the
following table shows the signaling samples collected on two RNCs.
Signaling 1 (calling party)

No. Time Signaling Indication Duration
1 14:42:51.566 rrcConnectionRequest MO
2 14:42:53.376 downlinkDirectTransfer Call Proceeding
14:42:54.996 PagingMsg Paging 1.620 s
CN CS
3 14:42:55.086 RAB_AssignmentRequestMsg
Assignment
4 14:42:56.126 RAB_AssignmentResponseMsg AssignComplete
5 14:42:58.626 downlinkDirectTransfer Alerting
Total MO+MT 7.060 s
Signaling 1 (called party)

14:42:54.996 PagingMsg Paging
1 14:42:56.106 rrcConnectionRequest MT 1.110 s
CN CS
Assignment
5 14:42:58.516 uplinkDirectTransfer Alerting
Total MT only 2.410 s
Signaling 2 (calling party)

1 14:46:14.161 rrcConnectionRequest MO
2 14:46:16.181 downlinkDirectTransfer Call Proceeding
14:46:17.671 Iu - PagingMsg Iu Paging 1.490 s
CN CS
Assignment
5 14:46:20.741 downlinkDirectTransfer Alerting
Total MO+MT 6.580 s

Signaling 2 (called party)

14:46:17.671 PagingMsg Paging
1 14:46:18.301 rrcConnectionRequest MT 0.630 s
CN CS
Assignment
5 14:46:20.631 uplinkDirectTransfer Alerting
Total MT only 2.330 s
From the above signaling analysis, we can reach the following conclusion:
In this project, the CS call delay is around 7 s, while the acceptance criterion of China
Unicom is 5.2 s. The gap is large, and we should work on the improvement of the delay.
The access delay in ZTE device is 2.3 s to 2.4 s, and is within the normal scope.
The RAB assignment message of the calling party is sent after the Iu interface receives
the Paging message, which is the RAB delivery strategy of HW CN equipment.
From Call Proceeding to HW CN sends the paging demand through the Iu interface, 1.5s
would be needed. If this duration is reduced to less than 0.5 s, the call delay for CS
services would be greatly reduced.
5.3 Case Study – PS Access Delay

In one project, we have performed a comparison test on the PS services of the UEs in
ZTE and Huawei networks, the results are shown in the following tables.
ZTE UE LOG samples

No. Direction Signaling Time
1 UE -> RNC rrcConnectionRequest 21:37:12.096
2 UE <- RNC rrcConnectionSetup 21:37:12.537
3 UE -> RNC rrcConnectionSetupComplete 21:37:12.615
4 UE -> RNC initialDirectTransfer 21:37:12.622
5 UE <- RNC MeasurementControl(activeSet & monitored Set) 21:37:12.904
6 UE <- RNC MeasurementControl(detectedSet) 21:37:12.914
7 UE <- RNC Authentication and ciphering request 21:37:12.934
8 UE -> RNC Authentication and ciphering response 21:37:13.125
9 UE <- RNC securityModeCommand 21:37:13.334
10 UE -> RNC securityModeComplete 21:37:13.335
11 UE -> RNC Activate PDP context request 21:37:13.466

No. Direction Signaling Time

12 UE <- RNC radioBearerSetup 21:37:14.044
13 UE -> RNC radioBearerSetupComplete 21:37:14.558
14 UE <- RNC radioBearerReconfiguration 21:37:15.054
15 UE <- RNC Activate PDP context accept 21:37:15.254
Call delay for PS services 3.158s
Huawei UE LOG samples

No. Direction Signaling Time (s)
UE ->
1 rrcConnectionRequest 20:44:43.148
RNC
UE <-
2 rrcConnectionSetup 20:44:43.347
RNC
UE ->
3 rrcConnectionSetupComplete 20:44:43.442
RNC
UE ->
4 initialDirectTransfer 20:44:43.448
RNC
UE <- MeasurementControl(activeSet &
5 20:44:43.655
RNC monitoredSet)
UE <-
6 Authentication and ciphering request 20:44:43.686
RNC
UE -> Authentication and ciphering
7 20:44:43.864
RNC response
UE <-
8 securityModeCommand 20:44:44.005
RNC
UE ->
9 securityModeComplete 20:44:44.008
RNC
UE ->
10 Activate PDP context request 20:44:44.111
RNC
UE <-
11 radioBearerSetup 20:44:44.565
RNC
UE ->
12 radioBearerSetupComplete 20:44:44.958
RNC
UE <-
13 MeasurementControl(Identity 2) 20:44:45.215
RNC
UE <-
14 Activate PDP context accept 20:44:45.375
RNC
Call delay for PS services 2.227s
Comparison between the delay in ZTE and Huawei networks at several key signaling
points
ZTE
HW Duration
Start point End point Duration
(ms)
(ms)
Activate PDP context
rrcConnectionRequest 3158 2227
accept

ZTE
HW Duration
Start point End point Duration
(ms)
(ms)
rrcConnectionSetupCom
rrcConnectionRequest 519 294
plete
radioBearerSetupComple
radioBearerSetup 514 393
te
Activate PDP context Activate PDP context
1788 1264
request accept
The comparison between ZTE and Huawei networks show that the call delay for PS
services in ZTE network is 900 ms longer than that in Huawei network. The delay is
generated at the following points:
 The rrcConnection setup procedure is 220 ms longer than that in Huawei network.
This is caused by the parameter configuration of FACH. After the adjustment, the
delay can be shortened. After the adjustment, the FACH parameters have satisfied
the baseline requirement. The default TOAWS and TOAWE are 44 and 8.
 Different from Huawei network, a detectedSet message exists in ZTE network. This
signaling can help to detect the missing neighbor cells, which could facilitate the
future network planning and optimization; however, it will prolong the access time.
 The delay in Activate PDP context request and Activate PDP context accept in ZTE
network is longer than in Huawei network. This procedure contains the
radioBearerSetup procedure. We can see from the signaling that time reserved for
the activationTime in radioBearerSetup of ZTE network is longer than that in
Huawei network, which results in that the delay in ZTE network is 120 ms longer
than that in Huawei network. The reserved time can help to ensure that the UE can
correctly receive the DL data, which helps to improve the reliability of the DL data.
 Meanwhile, in the PDP activation procedure, an RB reassignment procedure exists

in ZTE network, which is different from that in Huawei network. This is because
ZTE network has modified the 13.6 Kbps signaling to 3.4 Kbps signaling to save
the system resources. The introduction of this procedure also prolongs the access
time.

UMTS Access Performance Optimization Gui

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UMTS Access Performance Optimization Gui

Încărcat de

Drepturi de autor:

Formate disponibile

UMTS Access Performance

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. I

Product Version Document Version Serial Number Reason for Revision

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. II

About This Document

2 Evaluation Standards of Access Performance..............................................3

3 Key Points Analysis of Access Performance Optimization..........................5

4 Access Performance Optimization Through Daily Tests and Traffic

5 Access Performance Optimization Cases....................................................67

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. IV

Figure 3-1 Access failure analysis process.............................................................................5

Table 2-1 Accessibility KPI Values of China Unicom...............................................................3

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. V

The above concept is established because in network optimization phase, radio

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 1

The guide contains the following five chapters:

Chapter 2 introduces the major measuring standards of access performance.

Chapter 4 introduces how to perform UMTS network access performance optimization

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 2

2 Evaluation Standards of Access

2.1 System Accessibility

2.1.1 DT Testing Indicators of Accessibility

Table Evaluation Standards of Access Performance -1 Accessibility KPI Values of China

2.1.2 Traffic Statistical Testing Indicators of Availability

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 3

Table Evaluation Standards of Access Performance -2 Accessibility Statistical Indicators

RRC setup success rate N/A Stat. 97%

Voice Stat. 98%

HSDPA Stat. 97%

2.2 System Access Delay

Table Evaluation Standards of Access Performance -3 Access Delay Value Defined by

CS12.2K originating delay 5.2s

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 4

3 Key Points Analysis of Access

3.1 Access Failure

3.1.1 Analysis Process of Access Failure

Figure Key Points Analysis of Access Performance Optimization-1 Access failure

3.1.2 Basic Checking and Analysis of Access Failure

3.1.2.1 Alarm Checking

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 5

3.1.2.2 BPC Memory Checking

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 6

3.1.2.3 RRU Fault

i. Telnet to BPC and open test mode:

iii. Telnet to BPC and close test mode:

i. Telnet to RRU with faults, and open test mode:

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 7

3.1.2.4 Cell Health Degree Checking

If the power is abnormal, check for the RRU-relevant alarms.

3.1.2.5 Common Transport Channel Checking

If the cell is not established, it may be caused by the following reasons:

 Local cell IDs at NodeB and RNC sides are inconsistent.

 There are too many NodeBs configured in RCP.

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 8

 The site, BPC board, local cell or realtime cell is blocked.

 The TMA is turned off.

 Alarms exist on the BPC or RRU.

If the CCH can’t be established, check the following items:

If the above items are normal, change the CC board.

3.1.2.6 Parameter Checking

3.1.2.6.1 Preamble Configuration Checking

PRACH PRACH message and

ZTE Confidential Proprietary © 2018 ZTE CORPORATION. All rights reserved. 9