WCDMA Radio Network Optimization Student Book PDF

WCDMA Radio Access Network Optimization
WCDMA Radio Access Network

Optimization
STUDENT BOOK
LZT 123 8297 R1C
LZT 123 8297 R1C © Ericsson 2006 -1-

DISCLAIMER
This book is a training document and contains simplifications.

Therefore, it must not be considered as a specification of the
system.
The contents of this document are subject to revision without

notice due to ongoing progress in methodology, design and
manufacturing.
Ericsson assumes no legal responsibility for any error or damage

resulting from the usage of this document.
This document is not intended to replace the technical

documentation that was shipped with your system. Always refer to
that technical documentation during operation and maintenance.
© Ericsson 2006
This document was produced by Ericsson.
• It is used for training purposes only and may not be copied or

reproduced in any manner without the express written consent
of Ericsson.
This Student Book, LZT 123 8297, R1C supports course number
LZU 108 6489 .
-2- © Ericsson 2006 LZT 123 8297 R1C

Table of Contents
Table of Contents
1 PERFORMANCE MONITORING OF A WCDMA RADIO

ACCESS NETWORK.....................................................................9
INTRODUCTION ..................................................................................13
KEY PERFORMANCE INDICATORS ..................................................15

PERFORMANCE MONITORING.................................................................... 17
QUALITY OF SERVICE .................................................................................. 18
PERFORMANCE ANALYSIS.......................................................................... 20
WCDMA RAN OPTIMIZATION WORKFLOW .....................................21

PREPARATIONS ............................................................................................ 21
ACCESSIBILITY MODULE ............................................................................. 23
RETAINABILITY MODULE ............................................................................. 23
INTEGRITY MODULE..................................................................................... 23
WCDMA RAN OPTIMIZATION MODULE WORKFLOW .....................24

PERFORMANCE MEASUREMENTS - STATISTICS ..................................... 24
RECOMMENDATION & IMPLEMENTATION ................................................. 27
VERIFICATION OF CHANGES ...................................................................... 27
STATISTICAL TEST METHODS..........................................................28
2 DATA COLLECTION...................................................................33
DATA COLLECTION............................................................................37
BUSY HOUR................................................................................................... 37
TYPES OF COUNTERS ................................................................................. 39
COUNTER CLASSIFICATION ........................................................................ 41
STATISTICS SETUP ...................................................................................... 42
ACTIVATION................................................................................................... 49
STATISTICAL DATA MART .................................................................50
3 SERVICE ACCESSIBILITY .........................................................51
ACCESSIBILITY ..................................................................................55
ACCESSIBILITY WORKFLOW ...........................................................55
LZT 123 8297 R1C © Ericsson 2006 -3-

WORST PERFORMING CELLS ..........................................................56
UE IN IDLE MODE ...............................................................................58

PLMN SELECTION......................................................................................... 59
CELL SELECTION.......................................................................................... 59
LA AND RA UPDATE...................................................................................... 60
PAGING .......................................................................................................... 62
SYSTEM INFORMATION ............................................................................... 66
RANDOM ACCESS..............................................................................68
UL OPEN LOOP POWER CONTROL ............................................................ 70
RRC CONNECTION SETUP................................................................72

EMERGENCY CALLS..................................................................................... 73
MODULE MP LOAD........................................................................................ 73
ADMISSION CONTROL BLOCK .................................................................... 74
LACK OF TRANSMISSION RESOURCES..................................................... 90
LOAD SHARING ............................................................................................. 90
RADIO LINK SETUP....................................................................................... 95
NAS PROCEDURES..........................................................................100
CM SERVICE REJECT................................................................................. 100
RADIO BEARER SETUP...................................................................101

UE CELL RESELECTION DURING HANDOVER ........................................ 105
UE CELL RESELECTION............................................................................. 106
TEMS INVESTIGATION FINDINGS...................................................108

PDP REJECTED........................................................................................... 108
PPP LINK CONTROL TERMINATED ........................................................... 108
4 SERVICE RETAINABILITY .......................................................111
RETAINIBILITY .................................................................................. 115
RETAINABILITY WORKFLOW.......................................................... 115
WORST CELLS ................................................................................. 116

SPEECH ....................................................................................................... 116
VIDEO ........................................................................................................... 116
PACKET SWITCHED DATA ......................................................................... 117
DROPPED CALLS............................................................................. 117
-4- © Ericsson 2006 LZT 123 8297 R1C

Table of Contents
UL OUT OF SYNCH ..................................................................................... 118

CONGESTION .............................................................................................. 126
WCDMA RAN HANDOVER .......................................................................... 129
SOFT/SOFTER HANDOVER........................................................................ 130
HSDPA MOBILITY ........................................................................................ 146
INTER-FREQUENCY HANDOVER .............................................................. 149
INTER-RAT HANDOVER.............................................................................. 152
MISSING NEIGHBOUR RELATIONS........................................................... 155
OTHER REASONS ....................................................................................... 156
WNCS (WCDMA NEIGHBOURING CELL SUPPORT) .....................157

LOSS OF ASU COMPLETE OR MEASUREMENT REPORTS.................... 159
INTER-RNC HANDOVER FAILURE............................................................. 161
UE RELATED PROBLEM ............................................................................. 162
5 SERVICE INTEGRITY ...............................................................165
INTEGRITY ........................................................................................169
INTEGRITY WORKFLOW..................................................................169
WORST CELLS .................................................................................171

FORMULAS .................................................................................................. 171
WCDMA POWER CONTROL ............................................................172

CRC – CYCLIC-REDUNDANCY CHECK ..................................................... 173
DL INNER LOOP .......................................................................................... 174
UL INNER LOOP .......................................................................................... 175
UL OUTER LOOP ......................................................................................... 176
POWER CONTROL ON HSDPA CHANNELS.............................................. 179
BLER PARAMETERS ........................................................................180
PACKET THROUGHPUT...................................................................181
HSDPA ...............................................................................................194
HW AND SW PREPARATIONS.................................................................... 194
OPTIMIZING THE HSDPA............................................................................ 195

HIGH DL BLER - NO RAB SETUP ............................................................... 200
LZT 123 8297 R1C © Ericsson 2006 -5-

HIGH DL BLER – DROPPED CALL ............................................................. 201
6 UETR AND GPEH .....................................................................203
UE TRAFFIC RECORDING (UETR) ..................................................207

UETR RECORDABLE MESSAGES AND MEASUREMENTS...................... 208
ADD A UETR SUBSCRIPTION PROFILE .................................................... 210
RETRIVE THE UETR LOGFILES ................................................................. 214
ANALYZE THE UETR LOGFILES ................................................................ 214
GENERAL PERFORMANCE EVENT HANDLING (GPEH)...............219

INITIATION OF GPEH .................................................................................. 220
GPEH FILES COLLECTION AND STORAGE .............................................. 222
GPEH FILE STRUCTURE ............................................................................ 223
GPEH FILE ANALYSIS USING RED............................................................ 227
GPEH FILE ANALYSIS USING TEMS ......................................................... 232
7 ABBREVIATIONS .....................................................................237
8 APPENDIX A: CELL PARAMETER AND

CONFIGURATIONS ..................................................................243
APPENDIX B: FORMULAS FOR KEY PERFORMANCE

INDICATORS.............................................................................249
KEY PERFORMANCE INDICATORS ................................................253
ACCESSIBILITY ................................................................................255
SERVICE SUCCESS SETUP RATE ............................................................ 255
IDLE MODE .................................................................................................. 257
RANDOM ACCESS ...................................................................................... 257
ADMISSION CONTROL ............................................................................... 258
RETAINABILITY ................................................................................260
DROPPED CALL RATE................................................................................ 260
MINUTES PER DROP .................................................................................. 261
HANDOVER FAILURE RATE ....................................................................... 262
IRAT HANDOVER......................................................................................... 264
CONGESTION .............................................................................................. 265
OTHER REASONS ....................................................................................... 265
INTEGRITY ........................................................................................267
-6- © Ericsson 2006 LZT 123 8297 R1C

Table of Contents
BLER............................................................................................................. 267
THROUGHPUT............................................................................................. 267
APPENDIX C: PREDEFINED STATISTICS PROFILES

COUNTERS...............................................................................271
SUMMARY .........................................................................................275
APPENDIX D: TABLE OF FIGURES.................................................291
APPENDIX E: INDEX.........................................................................297
LZT 123 8297 R1C © Ericsson 2006 -7-

Intentionally Blank
-8- © Ericsson 2006 LZT 123 8297 R1C

1 Performance Monitoring of a WCDMA Radio Access Network
1 Performance Monitoring of a WCDMA Radio

Access Network
Objectives
Upon completion of this chapter the student will be able to:
• Explain the difference between RAN Tuning and RAN

Optimization
• Describe how to monitor the RAN performance
• Describe the definition of Network Quality
• Describe the general optimization process
LZT 123 8297 R1C © 2006 Ericsson -9-

Intentionally Blank
- 10 - © Ericsson 2006 LZT 123 8297 R1C

INTRODUCTION ..................................................................................13
KEY PERFORMANCE INDICATORS ..................................................15

PERFORMANCE MONITORING.................................................................... 17
QUALITY OF SERVICE .................................................................................. 18
WCDMA RAN OPTIMIZATION WORKFLOW .....................................21

PREPARATIONS ............................................................................................ 21
ACCESSIBILITY MODULE ............................................................................. 23
RETAINABILITY MODULE ............................................................................. 23
INTEGRITY MODULE..................................................................................... 23
WCDMA RAN OPTIMIZATION MODULE WORKFLOW .....................24

PERFORMANCE MEASUREMENTS - STATISTICS ..................................... 24
RECOMMENDATION & IMPLEMENTATION ................................................. 27
VERIFICATION OF CHANGES ...................................................................... 27
STATISTICAL TEST METHODS..........................................................28
LZT 123 8297 R1C © 2006 Ericsson - 11 -

Intentionally Blank
- 12 - © Ericsson 2006 LZT 123 8297 R1C

INTRODUCTION
This book is aimed for network engineers who need to understand
the main issues in optimizing an Ericsson WCDMA radio network.
It explains the different steps and tools needed to achieve this from
an Ericsson perspective. Common radio related problems are
presented and analyzed and the purpose is to create a deeper
understanding of radio network optimization, resulting in
improvements in radio network performance.
RAN tuning is done to provide operators with a detailed

understanding of the underlying problems to address, such as
network design, UEs and system. It is performed when all
necessary nodes in the area are installed and operational and when
the network is stable and not yet commercially used. It is also
performed when new sites are installed in already commercially
launched areas.
Figure 1-1 Overview of the Radio Network evolution
RAN Optimization is starting when the radio network has been

tuned RAN Optimization identifies and solves radio network
problems in live networks together with the rising of subscribers in
the network.
LZT 123 8297 R1C © 2006 Ericsson - 13 -

Data from various system sources are analyzed and

recommendations are made. Ericsson offers different tools that are
used such as performance statistics, User Equipment Traffic
Recording (UETR), Cell Traffic Recording (CTR) and General
Performance Event Handling (GPEH). Information from drive tests
as well as subscriber feedback is also used.
– Tuning
z Establish network performance mainly using drive tests:
– To ensure it is possible to drive in the network without dropping calls
– To ensure it is possible to set up calls in the coverage area
z Analyze and describe underlying problems related to:
– Design
– UEs
– Systems
– Optimization
z Identify and improve radio network problems using statistics, recordings and events
z Establish subscriber behavior and perception
z Ensure that traffic growth can be handled
Figure 1-2. The difference between RAN tuning and RAN optimization
RAN Tuning is required to ensure good network quality and

identifies and solves radio network problems after the network has
been installed.
RAN tuning is done to provide operators with a detailed

understanding of the underlying problems to address, such as
network design, UEs and system. It is performed when all
necessary nodes in the area are installed and operational and when
the network is stable and not yet commercially used. It is also
performed when new sites are installed in already commercially
launched areas.
RAN Optimization can result in changes in the parameter setting

for the different functionalities such as idle mode, radio connection
supervision, power control, capacity management, handover and
channel switching.
- 14 - © Ericsson 2006 LZT 123 8297 R1C

KEY PERFORMANCE INDICATORS

To efficiently manage the performance of a cellular network, one
must be able to navigate through the data that is collected in the
network and determine the areas where improvement is needed.
Due to the vast amount of performance statistical data that is
collected by the WCDMA network, it can be confusing to correlate
all the data for the entire network and build a coherent picture. The
solution is to extract and calculate Key Performance Indicators
(KPIs), which are directly connected to the quality.
Observability covers all functions in UTRAN that serves to

monitor and analyze the performance and characteristics of the
UTRAN system. This can be done on various levels with different
target groups and requirements. The figure below illustrates a
model for Observability in UTRAN.
Figure 1-3 UTRAN Observability Model
The Key Performance Indexes represents the End-user perception

of a network on a macro level and are of typical interest for top-
level management as well as others within an operator. These
numbers are typically used to benchmark networks against each
other and to detect areas of problem.
The Performance Indicator level represents information on a

system level that does not explicitly qualifies in the macro level
end-user perspective model, but can indicate whether the system
performs good or bad. Performance Indicators do not necessarily
give enough details to allow a full detailed troubleshooting. The
data can also be used for planning and dimensioning. This data,
typically PM counters and also RES counters, is collected
continuously.
LZT 123 8297 R1C © 2006 Ericsson - 15 -

The Procedure level represents deeper troubleshooting and measure

system characteristics measurements. It involves measurement on
signaling and procedure/function levels to investigate problems
detected on higher levels. The amount of data on this level is
enormous and these measurements are generally user-initiated for a
specific purpose and area of the network, thereby limiting the
scope of the measurements. The typical source for this data is
GPEH events and the recording functions UETR and CTR.
Examining the KPIs for a network is a primary function of day-to-

day performance management. This will give the operator the
information regarding how the network is functioning:
• Does the network fulfill the performance requirements?
• Has the performance changed? Improved? Degraded?
• Where are the problem areas?
• What types of problems are being experienced?
Network performance monitoring is illustrated in Figure 1-4 below.
Good?
Bad?
Information
Overflow!!!
Goal:
Perceive the performance
at a glance
Solution:
• Extract and calculate, of all available information, Key Performance
Indicators (KPI), which are directly connected to the quality
• Information about why the network is performing as it is does not

need to be provided during this step
Figure 1-4 Network performance Monitoring
After determining the most pressing issues, the operator can then
utilize other statistical and event measurements to isolate issues,
troubleshoot the causes, and take the necessary corrective actions.
The operator can then use the KPIs to verify that the corrective
actions taken resolved the performance issues.
- 16 - © Ericsson 2006 LZT 123 8297 R1C

PERFORMANCE MONITORING
The sources for performance monitoring are:
• Statistical information counters from the network elements
• Traffic recordings (e.g. UETR, GPEH)
• Downlink information from single test mobiles (e.g., TEMS

Investigation)
• Downlink information from several special mobiles

distributed to selected users
• Autonomous measurements with special mobile / fixed

units (e.g. TEMS Automatic)
• Customer input (e.g., trouble tickets)Since drive testing can

be expensive, it isbeneficial to get the information to monitor the
radio network performance from the network elements, see Figure
1-5
below.
M SC SG SN
RNC RNC RNC UE

UE
UE
RBS RBS RBS RBS RBS RBS
N etw ork Inform ation M obile Inform ation
Figure 1-5. Measuring Network Quality
A great deal of performance management information is available

in the Core Network (CN) and the Universal Terrestrial Radio
Access Network (UTRAN). Some information, such as idle mode
and geographic information, is only directly available from the
User Equipment (UE). This information that is not directly
available from the network elements can often be estimated by
other information that is collected from the network elements.
LZT 123 8297 R1C © 2006 Ericsson - 17 -

Other
Management
Systems
Network
Core Network
Mun Management
Environment
OSS-RC
RNC TEMS
Iu Mur Mut
Mun
RNC Iur
Mub
RBS
RANAG
Iub RBS Uu
Iub
Radio Access UE
RBS
Network
UE User Equipment
RNC Radio Network Controller
Uu RBS Radio Base Station
OSS-RC Operation Support System – Radio Core
TEMS Test Equipment Mobile System
UE RANAG Radio Access Network Aggregator
Figure 1-6. WCDMA RAN Architecture
Note that the counters are implemented in the network elements

(e.g. Radio Network Controller (RNC), Radio Base Station (RBS)
and Radio Access Network Aggregator (RANAG), as illustrated in
Figure 1-6 above. Hence, statistics are generated by the network
elements but stored in a database within OSS. A post-processing
tool is needed for analyzing the data and for generating reports.
QUALITY OF SERVICE
The definition of Quality of Service (QoS) is how the user is
satisfied with the overall service. The QoS concept consists of six
different requirements (see Figure 1-7):
Service Accessibility Performance

The ability of a service to be obtained within specific tolerances
and other given conditions, when requested by the user. E.g. to be
able to get in contact with the network. In other words, the operator
has to observe the call setup success rate, paging success rate,
blocking probability etc.
Service Retainability Performance

The ability of a service, once obtained, to continue to be provided
under given conditions for the requested duration. E.g., the
operator has to observe the drop call rate.
Service Integrity Performance
- 18 - © Ericsson 2006 LZT 123 8297 R1C

The degree to which a service is provided without excessive

impairments, once obtained. E.g., the operator has to observe the
BLER and the throughput.
Service Support Performance

The ability of the operator to provide the service and assists in its
utilization.
Service Operability Performance

The ability of a service to be successfully and easily operated by a
user
Service Security Performance

The protection provided against unauthorized monitoring,
fraudulent use, malicious impairment, misuse, human mistake and
natural disaster.
These six QoS areas are illustrated in Figure 1-7 below.
User (subscriber)
Quality
of service
Service Service Service Service Service Service

Support Operability Accessibility Retainability Integrity Security
performance performance performance performance performance performance
Serveability performance
Quality of Service
Network Performance
Provider (operator)
Figure 1-7. Network Quality of Service (QoS).
By continuously measuring the QoS through monitoring the KPIs,

the operator should be able to:
• Detect problems in the network, and determine if the

quality requirements are not fulfilled.
LZT 123 8297 R1C © 2006 Ericsson - 19 -

• Locate problems geographically by isolating which area,

cell, or transceiver shows a problem.
• Detect areas for expansion by monitoring traffic levels and

determining where hardware addition is needed.
• Identify cells that are “money makers” as a function of

traffic carried. This is important in determining the severity
of a cell being out of service.
PERFORMANCE ANALYSIS
Performance Analysis is based on statistics (counters), field DL
measurement (TEMS), recordings (e.g., CTR and UETR) and
events (GPEH). The measurement results are correlated with
information as to how the network is defined (e.g., Configuration
Management (CM) data, CM change log) and how the hardware is
performing (e.g., Alarm logs).
While Performance Monitoring is a function of detecting and

localizing performance issues, Performance Analysis is a function
of determining the reason(s) for the performance issues and
possible solutions. Some of the areas that might need to be
addressed are illustrated in Figure 1-8 below:
y
What creates the problem?
• How can the problem be solved
Problems related to the radio network:
• Dimensioning, Planning, and Architecture
• Hardware Problems
• Uplink (UL) and/or Downlink (DL) Interference
• Handover (HO)/Inter Radio Access Technology (IRAT) HO
• Pilot Pollution
• Idle Mode Parameters
• Code Allocation
• Admission Control
• Connection Handling
• Power Control
• Security
• Other Cell Parameters
Figure 1-8 Performance Analyses
- 20 - © Ericsson 2006 LZT 123 8297 R1C

WCDMA RAN OPTIMIZATION WORKFLOW

The main purpose of optimizing a network is to ensure that any
service affecting faults related to the traffic load in the network
after initial tuning are corrected.
Preparations Accessibility Retainability Integrity

module module module
Consistency Idle mode HO Performance BLER
Check
Random
• P Access Neighbour Throughput
a
RRCr Connection SF Usage
a
m
NASe
t
RABer Assignments
s
• N
e
i
Figure 1-9 Optimization Process
The WCDMA RAN Optimization activity includes the following

main tasks shown in Figure 1-9
PREPARATIONS
Parameter Settings
In order to find this problem and to monitor it is to do a parameter
check. There are many problems that can be reduced from start if
this is done. (e.g. wrong power settings, wrong handover parameter
etc.)
Neighbor Relations
In order to find this problem and to monitor it is to do a neighbor
relations check. There are many problems that can be reduced from
start if this is done. If the neighbors are correctly defined, less
dropped calls will occur due to missing neighbors or too long
neighbor lists. Single defined neighbors will also be identified
which reduces the dropped calls.
LZT 123 8297 R1C © 2006 Ericsson - 21 -

Scrambling codes
In order to find this problem and to monitor it is to do a parameter
check. If the scrambling codes are reused to often this can affect
the accessibility but also the handover performance due to the UE
problem to detect the interfering SC.
Statistics
In order to find the problems in the network, the counters in the NE
must be activated, which means that profiles have to be created.
More information about this can be found in chapter 2, Data
Collection.
- 22 - © Ericsson 2006 LZT 123 8297 R1C

Cell Downtime
In order to select the worst performing cells, all cells have to be
available for the statistics. If some maintenance has been done on
some of the cells, this could have a large impact on the network
statistics. These cells should therefore be excluded from the
statistics during the maintenance period.
pmCellDowntimeMan - shows how many seconds during the

measurement period cell was manually blocked. During manual
downtime cell will not be available for service -
pmCellDowntimeAuto - shows how many seconds during the

measurement period cell was automatically blocked. During
downtime cell will not be available for service.
Alarms
Before looking for the problem causing sites it is important to fully
understand the sites performance in regards of HW faulty. If
checking the cells alarms it would give a good indication whether
there is a hardware problem at some of the sites.
ACCESSIBILITY MODULE
During this module the WCDMA RAN Network accessibility is
analyzed. The UE Idle mode behavior as well as the Random
Access process is analyzed in order to make the best performance
of the network. More information about this module can be found
in chapter 3, Service Accessibility
RETAINABILITY MODULE
During this module the WCDMA RAN Network retainability is
analyzed. The UE mobility behavior as well as the handover
performance is analyzed in order to make the best performance of
the network. More information about this module can be found in
chapter 4, Service Retainability
INTEGRITY MODULE
During this module the WCDMA RAN Network integrity is
analyzed. The BLER is analyzed in order to make the best
performance of the network. More information about this module
can be found in chapter 3, Service Integrity
LZT 123 8297 R1C © 2006 Ericsson - 23 -

WCDMA RAN OPTIMIZATION MODULE WORKFLOW

Each module in Figure 1-9 has an own workflow which is shown in
the Figure 1-10.
Other Modules
Performance Performance Recommendation Verification of
Measurements Analysis & changes
Implementation
Figure 1-10. Module process
The process is repeated for each module, where each module

represents one area of the service Observability blocks, like
accessibility, retainability and integrity (see Figure 1-7. Network
Quality of Service (QoS).).
PERFORMANCE MEASUREMENTS - STATISTICS

Radio network statistics data, i.e. RNC and cell level data should
be collected during both busy hours and normal traffic hours. For
performance statistics (counters) normally a predefined system
profile is up and running in RNC. If this predefined system profile
does not cover all counters that are needed for performance
monitoring, a user-defined profile should be setup and used during
analysis.
The following performance areas should be in the performance

statistics profile (predefined system profile or/and user-defined
profile):
RAB Handling, Admission, Admission Monitoring, Cell

Availability, Channel Quality, Congestion, Handover, Inter
Frequency Handover, IRAT Handover, Processor Supervision,
RRC Handling, Iur Channel Handling, Cell update, Connection
supervision and Channel Switching
Transport network performance statistics (counters) should be

collected during the same period that radio network performance
statistics is collected. Aal2Ap and VplTp are Managed Objects of
interest for transport network that should be monitored.
- 24 - © Ericsson 2006 LZT 123 8297 R1C

The duration of data collection should be for 3-4 days, 16-18 hours
including the busy hours for each day. Data related to the
maintenance window’s hour should not be used for analysis.
OSS- RC
OSS-RC is needed for creating of new performance statistics
or/and UETR/GPEH profiles. The defined profiles will also be
activated from OSS. ROP files will be fetched automatically and
stored in OSS-RC. Normally the data should be found in the
following directors:
Performance Statistics .xml files

/var/opt/ericsson/nms_umts_pms_seg/segment1/SubNetwork
Performance Recording .bin files

/var/opt/ericsson/nms_umts_red_reg/downloaded
For further information on location of the rop files, please see the
PM, Subscription Profiles and Performance Monitoring, Function
Description - 1/155 34-APR 901 91/3)
PERFORMANCE ANALYSIS
During this performance analysis, KPI from the Performance
measurements are evaluated in order to find problem cells or
problem geographical areas.
Worst cells
The worst cells are divided into several types of “worst performing
cells” and should also be optimized in this specific order.
1. Random access function. The methodology to optimize the

random access procedure is very passive due to lack of
performance monitoring counter. What can be done is just to
adjust the random access parameters and then to observe the
variations. Is the number of RRC connection request increased
after modifying random access parameters? Is the number of
missing RACH message reduced?
2. Accessibility load-sharing (inter-frequency and directed retry to

GSM). Is the number of denied admission high in the network?
3. RAB functionality. Identify RAB’s that are not performing in

line with targets, regarding retainability and integrity.
LZT 123 8297 R1C © 2006 Ericsson - 25 -

Review radio parameter settings (points below). Make consistency

check of the parameter settings and verify settings against Ericsson
default/recommended values.
Site configuration
Collect the site and antenna configuration information for every
type of these worst cells.
Geographic location
Check on map where the worst performing cells are located. Could
they be dependent on each other?
Drive Tests
Normally performance statistics used in the first place to give an
overall RNC status and show worst performance cells. During the
troubleshooting of call setup problem for worst performing cells,
other performance measurements are also needed in order to
provide more detailed information to facilitate analysis work.
Trouble shooting drive test with TEMS Investigation will be used

whenever it is needed to get detailed DL information.
UETR, GPEH, CTR

Performance Recording applications are used to collect
performance events and radio related measurements used for
detailed network performance analysis, troubleshooting and
network optimization.
UETR (User Equipment Traffic Recording) will be used in

combination with TEMS Investigation drive test data to provide
UL information (excluding reference drive test). UETR
performance recording data will be collected after the worst
performing cells are identified.
If more detailed information is needed, GPEH (General

Performance Event Handler) can be used together with the TEMS
Visualization. Then multiple calls on the cells guide the optimizer
in the right direction in order to implement the changes needed.
GPEH is an optional feature and not all operators will have

purchased the feature.
- 26 - © Ericsson 2006 LZT 123 8297 R1C

Activate GPEH for more information if needed. GPEH should be

used for providing detailed information for worst performing cells.
GPEH performance recording data will be collected after the worst
performing cells are identified.
CTR (Cell Traffic Recording) is a recording of selected

performance events, and/or radio related measurements, covering
specific cell, usually referred to as the recording area. The main
difference between CTR and UETR is that in UETR it is the
operator who decides which User Equipments (UEs) to record,
while in CTR any UE in a selected area may be recorded. The RNC
adds each received measurement and event into the CTR or UETR
file (depending on which is activated). The recordings are then
accumulated into files for the duration of Report Output Period
(ROP), and are stored in the network elements (NEs). The duration
of ROP is 15 minutes.
RECOMMENDATION & IMPLEMENTATION

Generally, there will be two types of finding from the data analysis.
Either the findings are related to Cell/RBS/RNC parameter
settings, or they are related to hardware configuration such as
antenna tilt or antenna height etc. A brief report should be produced
and presented to the customer, outlining the findings,
recommendations and arguments to justify the network changes.
The report should provide the customer with necessary input data
to be able to understand the nature of the problem, and why the
Change Requests (CR) is needed.
For every change which is identified as necessary a CR should be

raised and submitted to the RND or/and the Operation and
Maintenance organization and be agreed upon. Short lead times are
expected for implementing short-term changes such as parameters,
whilst long-term changes such as hardware configurations may
require lead times, which fall outside the time frame of the
retainability service.
VERIFICATION OF CHANGES
After implementation of changes (parameters, hardware etc)
network performance should be monitored in order to verify the
impact of changes. Performance statistics data should be collected
after change implementation and evaluate the network performance
in problem areas and RNC. If for any reason the implemented
changes caused any degradation of connection setup in RNC or/and
concerned problems areas, the changes should be rolled back and
other possible solutions need to be investigated.
LZT 123 8297 R1C © 2006 Ericsson - 27 -

The statistic data should be collected again after both trouble

shooting and function. The results should be compared before and
after optimization. The paging performance should be checked if it
has been improved after previous changes.
STATISTICAL TEST METHODS

When performing measurements in a radio network it is important
to understand that the system performance can change drastically
during a day. When comparing data sets before and after a change
it is important to select the measurement occasions so that the
different occasions have as equal conditions as possible.
There are two commonly used statistical methods when comparing

measurements before and after a change in a radio system i.e.
adjustment of a parameter or similar.
The statistical test methods should give some information on how

to judge whether or not a performance improvement has been
reached in the system after the change.
However these test methods presented below are recommended to

use when an improvement after a change in a network is not very
obvious statistically due to hourly/daily fluctuation of data.
Whenever an improvement is obvious statistically in a network
after a change, there is no need to use any test method.
Student’s t-test
Student's t-test, often known simply as the t-test, is one of the most
commonly used statistical tests for testing a hypothesis based on a
difference between sample means. The t-test determines a
probability that two populations are the same with respect to the
variable tested. It comes in two versions, the paired t-test and the
unpaired t-test.
Both versions are used to test the hypothesis that some variable
differs between two groups, but the paired test is specifically used
when each data point in one group corresponds to a matching data
point in the other group. The unpaired t-test is more general.
The t-test can be performed knowing just the means, standard

deviation, and number of data points.
- 28 - © Ericsson 2006 LZT 123 8297 R1C

The unpaired t-test the most general technique that can be used to
test whether a variable differs between two groups, and does not
require that the two groups be paired in any way. The samples can
also be of different sizes. In simple terms, the t-test compares the
actual difference between two means in relation to the variation in
the data expressed as the standard deviation of the difference
between the means.
Unpaired t-test process

For the t-test for independent samples, the same number of data
points in each group is not needed i.e. the sample taken before may
have more data point than the sample taken after. The assumption
is that the population follows a normal distribution, or more
correct, a t-distribution when the variances are estimated.
Below is an example of a network performance improvement

activity where a parameter change to reduce dropped call has been
verified for the same RNC during different hours before and after
parameter change.
Hour Drop
Before Drop After
1 3.93 0.9
2 2.82 1.33
3 2.72 1.1
4 2.26 1.03
5 2.8 1.81
6 3.59 2.58
7 1.73 0.74
8 2.79 1.86
9 2.83 1.65
10 2.82 2.13
11 1.24 3.05
12 2.19
13 3.75
Table 1- Speech Call Drop for RNC
1. Arrange the data under consideration in two columns as in Table 1.
It is assumed that Column Before (column B) contains the sample

before and Column After (Column C) contains the sample after a
network change.
2. From the Tools option at the top of the Excel screen, select Data
analysis to display Analysis options. If Data Analysis is not
available, load the Analysis ToolPak from Add-Ins under the tools
menu.
LZT 123 8297 R1C © 2006 Ericsson - 29 -

3. From the drop-down menu select t-Test: Two-Sample Assuming

Equal Variances
4. Click OK and enter cells B2-B14 for Variable range 1.
5. Select cells C2-C10 for Variable range 2.
6. Set Hypothesized Mean difference = 0
7. Tick the label box
8. Enter a free cell (e.g. E2) for the output range. Choose the top-left
cell of the area where the results of the analysis will be displayed.
Then click OK and the printout appears as in Table 2.
9. The test will ask what is the probability of obtaining our given results
by chance if there is no difference between the means i.e. our
Hypothesized Mean Difference is zero or our null-hypothesis zero
difference between the samples.
Two-Sample Assuming Equal

Variances
Before After
Mean 2.7146 1.6527
Variance 0.5541 0.5305
Observations 13 11
Pooled Variance 0.5434
Hypothesized Mean Difference 0
Df 22
t Stat 3.5163
P(T<=t) one-tail 0.0010
t Critical one-tail 1.7171
P(T<=t) two-tail 0.0019
t Critical two-tail 2.0739
Table 2- Output from unpaired t-test
As output from the analysis, the column means are given, the
variances of each sample, the number of observations, the
hypothesized mean difference, the degree of freedom (df), the
calculated t-value (t Stat) and four other entries.
The first two of these refer to a one-tailed t-test i.e. if testing only
that one particular mean is larger or smaller than the other. The
final two entries refer to a two-tailed test, where the direction of the
test i.e. is not specified, we do not know if the performance will be
better or worse a priori.
- 30 - © Ericsson 2006 LZT 123 8297 R1C

For most purposes, the two-tailed test is used. In each case the
probability, P(T<=t) are shown, that the calculated t-value is equal
to or less than the tabulated t-value, shown as the t critical.
If the P-value associated with the t-test is small i.e. below the risk
level of alpha = 0.05, there is evidence to reject the null hypothesis
in favor of the alternative. In other words, there is evidence that the
means are significantly different than assumed in out null
hypothesis.
If the P-value associated with the t-test is not small i.e. P(T<=t) >
0.05, there is not enough evidence to reject the null hypothesis, and
the conclusion are that there is evidence that the means are not
different from the hypothesized value. Thus the reported P(T<=t)
two-tail gives the probability of getting the calculated t-value by
chance alone.
In the example that probability is lower than the risk level of alpha
= 0.05, so the sample means are significantly different. It can be
stated that the result is 0.19% risk that we reject a null-hypothesis
that is true. The conclusion is thus that the drop rate is significant
lower afterwards on 5 % risk level.
LZT 123 8297 R1C © 2006 Ericsson - 31 -

Intentionally Blank
- 32 - © Ericsson 2006 LZT 123 8297 R1C

2 Data Collection
2 Data Collection
Objectives
Upon completion of this chapter the student will be able to:
• Understand what types of counters are available
• Understand the counter classification
• Explain how to activate the counters
• Understand how to calculate busy hour
LZT 123 8297 R1C © 2006 Ericsson - 33 -

Intentionally Blank
- 34 - © Ericsson 2006 LZT 123 8297 R1C

2 Data Collection
DATA COLLECTION............................................................................37
BUSY HOUR................................................................................................... 37
TYPES OF COUNTERS ................................................................................. 39
COUNTER CLASSIFICATION ........................................................................ 41
STATISTICS SETUP ...................................................................................... 42
ACTIVATION................................................................................................... 49
STATISTICAL DATA MART .................................................................50
LZT 123 8297 R1C © 2006 Ericsson - 35 -

Intentionally Blank
- 36 - © Ericsson 2006 LZT 123 8297 R1C

2 Data Collection
DATA COLLECTION
Performance Statistics are continuously collected from all Network
Elements (NE) and stored persistently in Operation Support
System, Radio and Core (OSS-RC). Statistics are mainly used for
the detection of problem areas and for monitoring the performance
of the network on a daily basis.
The complete WCDMA Radio Access Network (RAN)

Performance Management (PM) functionality receives support
from all WCDMA RAN nodes:
• Radio Base Station (RBS)
• Radio Network Controller (RNC)
• Radio Access Network Aggregator (RANAG – RXI)
• OSS-RC.
The traffic nodes provide the performance information through a

file interface. This information is collected by OSS-RC.
Performance Management Statistical files are stored in OSS-RC for
a predefined period of time, where they can be retrieved by
interested users. Open interfaces are provided so that report
generators and visualizing tools can retrieve the necessary data.
BUSY HOUR
The busy hour (BH) can be evaluated per cell for all selected cells.
Two alternative approaches can be used for the BH calculation. In
both cases, the counters values must be aggregated per cell and per
hour (that is for four Recording Output Periods, ROP).
• BH calculation based on the total number of successful

RRC Connection requests
• BH calculation based on the total payload concerning the

traffic carried in both UL and DL on dedicated and common
channels, both for PS and CS services.
In the first case, the BH evaluation can be based on the

pmTotNoRrcConnectReqSuccess counter. This counter increases at
every successfully established RRC connection. Per cell and within
the period under observation, the counter values must be
aggregated per hour (normalized to the available ROP periods).
LZT 123 8297 R1C © 2006 Ericsson - 37 -

The BH must be defined as the hour for which the aggregated value
is maximum.
In the second case, the BH can be evaluated by considering the

total payload considering the traffic carried both in UL and DL on
dedicated and common channels (both for PS and CS services).
However there are no payload counters specific for HSDPA. The
payload traffic counters carried by dedicated and common channels
that can be considered for the BH calculation are specified in the
table below.
Radio Connection type UL Payload counter DL Payload counter

Speech pmUlTrafficVolumeCs12 pmDlTrafficVolumeCs12
PS64/64 pmUlTrafficVolumePs64 pmDlTrafficVolumePs64
PS64/128 pmUlTrafficVolume Ps128 pmDlTrafficVolume Ps128
PS 64/384 pmUlTrafficVolume Ps384 pmDlTrafficVolume Ps384
CS 57.6 (streaming) pmUlTrafficVolumeCs57 pmDlTrafficVolumeCs57
CS 64 (UDI) pmUlTrafficVolumeCs57 pmDlTrafficVolumeCs57
Speech/PS 64 multirab pmUlTrafficVolumeCs12Ps64 pmDlTrafficVolumeCs12Ps64
PS Common pmUlTrafficVolumePsCommon pmDlTrafficVolumePsCommon
Table 2-1. Counters used for BH calculation
Figure 2-2. Example of traffic distributed over 10 days
Please note that the BH can occur at different times for different
types of services, as shown in the figure above
- 38 - © Ericsson 2006 LZT 123 8297 R1C

2 Data Collection
Please note that counter values for all cells might not be available
for all of the days and not always for all ROP periods during the
day. This could be due to that the RBS can be down, manually or
automatically and therefore not available regarding carrying traffic.
TYPES OF COUNTERS
The names of all the counters created in NEs start with pm, while
the names of the OSS-RC calculated statistics counters in start with
cm.
The following seven types of counters are available in a WCDMA

system:
Peg counters
A Peg counter is a counter that is increased by one at each
occurrence of a specific activity.
Gauge counters
A Gauge counter is a counter that can be increased or decreased
depending on the activity in the system. This can be a ATM
Adaptation Layer 2 Access Point Counters, pmExisOrigConns,
which is the number of existing connections for the AP originating
in this node.
Accumulator counters
An Accumulator counter is a counter that is increased by the value
of a sample. It indicates the total sum of all sample values taken
during a certain time. The name of an accumulator counter begins
either with pmSum or pmSumOfSamp.
Scan counters
A Scan counter is a counter that is increased by one each time the
corresponding accumulator counter is increased. It indicates how
many samples have been read, and added to the related
accumulator counter. A scan counter can therefore be considered a
specific kind of peg counter.
Due to these types of counters, it is possible to get the average

value of all samples by dividing the accumulator counter by the
scan counter. The name of a scan counter begins with pmSamples
or pmNoOfSamp.
LZT 123 8297 R1C © 2006 Ericsson - 39 -

ATrigAcc counters
ATrigAcc counter is a counter that is increased by the value of a
sample and the sampling is only done when there is some activity.
It indicates the total sum of all sample values taken during a certain
time. The sampling is only done if there is some activity ongoing
for the measured entity. The name of an TrigAcc counter begins
with pmSumAct.
ATrigAcc counters
ATrigScan counter is a counter that is increased by 1 each time the
corresponding TrigAcc counter is increased. It indicates how many
samples have been read, and added to the related TrigAcc counter.
The sampling is only done if there is some activity ongoing for the
measured entity. A TrigScan counter can therefore be considered a
specific kind of peg counter. Due to these types of counters, it is
possible to get the average value of all samples by dividing the
TrigAcc counter by the trigScan counter. The name of a TrigScan
counter begins with pmSamplesAct.
Probability Density Function counters

A Probability Density Function (PDF) counter is a list of range
values. A value is sampled (read) periodically. If the value falls
within a certain range, the range counter for that range is increased.
All range counter values are collected and stored in a ROP file at
the end of each reporting period.
For example, if SIR values are split into three ranges: Range1 = [-
11 dB – -4 dB], Range2 = [-4 dB – +4 dB], Range3 = (+4 dB – +20
dB], and a value is read every 3 minutes over a 15 minute period
(values = -10, -3, +5, +5, +6), then the three Range Counters are
reported as RangeCounter1 = 1, RangeCounter2 = 1,
RangeCounter3 = 3
Figure 2-3. Example of statistics from a PDF counter
Discrete distributed measurements
- 40 - © Ericsson 2006 LZT 123 8297 R1C

2 Data Collection
Discrete distributed measurements (DDM) are series of values

recorded during a reporting period. Each series of values may be of
one of the following measurement types:
• Accumulated over a measurement period and read at the

end of each measurement period (a gauge or peg counter)
• Averaged over the duration of a measurement period
• Read at a specific time (the measurement time), within the

measurement period (at a specific frame)
• At the end of a series of consecutive measurement periods

(the reporting period) all measurement values are collected
and stored in a ROP file.
For example, if a SIR value is read every 3 minutes over a 15–

minute period (values = -10, -3, +5, +5, +6), then 5 DDM
measurements are reported as Meas1 = -10, Meas2 = -3, Meas3 =
5, Meas4 = 5, Meas5 = 6.
Calculated Statistics counters

A Calculated Statistics counter is a counter whose value is
determined by other counters. The calculation is performed in the
OSS-RC Statistics database. The ROP files are opened in order to
be transferred into the database and the calculations are made by
the database itself during this process. This means that these
counters are not available when the Statistics Database is not
present.
Note: The names of all the counters created in NEs start with pm,
while the names of the OSS-RC calculated statistics counters in
start with cm.
COUNTER CLASSIFICATION
There are two general classifications of the statistic counters. First,
they can be grouped depending on where they are generated, that is
at which NE or they can be grouped depending on the area of
interest that is if they are:
• Radio Network – RNC specific counters
• Radio Network – RBS specific counters
• Transport Network counters.
LZT 123 8297 R1C © 2006 Ericsson - 41 -

In the following Figure, the grouping of counters into different NE

and different areas of interest is shown.
Table 2-4. Grouping the counters based on their NE Origin (SDM =

Statistical Data Mart)
STATISTICS SETUP
In order to monitor the statistics counter values throughout the
time, specific counters have to be active. Only when a counter is
active values are generated, collected and can be analyzed.
An overview is presented of the counter activation process using

the OSS-RC GUI but please note that it is also possible to activate
counters through the CORBA interface.
Statistics profiles
For the activation of one or more counters the user has to define a
statistics profile. A statistics profile is an entity in the OSS-RC GUI
that helps users to manipulate counter administration. The process
of creating a new statistics profile is shown in the following figure.
- 42 - © Ericsson 2006 LZT 123 8297 R1C

2 Data Collection
Figure 2-5. Statistics profile activation
One profile is typically defined in the steps shown corresponding to

the figure above:
1. NE type (RNC, RBS or RXI)
2. One or more NE instances
It is possible to include one, more or all NE instances into a profile.

All the actions performed at the profile will be automatically
performed for all the selected NE.
Note that if a new NE is setup in the RAN, it will not automatically

be included in the existing user-defined profiles. In P4 the user can
modify an existing profile and adding NE without suspending the
profile (see 4.3.4 Modify Active (Admin state) Statistics
Subscription Profile in doc USER GUIDE 1/1553-APR 901 91/3
Uen B)
3. MO Class (Standard) or MO Instance type (Cell/Cell Relation)
LZT 123 8297 R1C © 2006 Ericsson - 43 -

The MO Class is normally selected, that is all the existing MO

Instances are wanted for a statistics profile. In addition to this it is
possible to select only specific cells to be performance monitored.
This choice is available only for the RNC for Utran Cell and Utran
Relation counters.
4. Cell selection
If the MO Instance type is selected for a profile in the previous

step, it is possible to select the wanted cells. Only for these cells,
the counters (selected in the next step) will be possible to handle
through the profile.
Note that the MO instance selection is always done on the cell level
by the user. The selection of Utran Relations is done automatically
based on the cell selection in the following way – all the Utran
Relations where the selected cells appear as best serving
(soft/softer handover) or as source (inter-frequency handover) cells
are selected.
5. One or more selected counters (only the counters available to

the NE type of the profile)
Note that for RNC specific and Transport Network counters it is

possible to include and activate more than once the same counter
for the same NE for the same MO Instance. This would result in
duplicating the data in the statistics ROP files, causing unnecessary
increase of their size. It is highly recommended that each counter is
activated only once, that is through only one profile. For RBS
specific counters this is not valid – duplicated subscriptions to
already active counters will fail.
6. Scheduling
A user-defined statistics profile can be defined as:
• Continuous – the profile state changes only by the user
• Scheduled – the profile starts at a specified point in

time and stops after a specified duration
• Periodical – the profile starts at a specified point in

time, stops after a specified duration. This is repeated a
specified number of times in regular intervals.
- 44 - © Ericsson 2006 LZT 123 8297 R1C

2 Data Collection
Example: The profile “XYZ” is an RNC type profile of type

Standard (MO Class) for the RNC01 and RNC02 and is including
the counters pmCellDowntimeAuto and pmCellDowntimeMan. It is
of type continuous. Once created, the profile may be resumed (state
changed to active) or suspended (state changed to suspended). It
can also be modified, but only while in state suspended.
User-defined and Pre-defined profiles

When a profile is created by a user in OSS-RC it is called user-
defined profile. As opposed to user-defined there are pre-defined
profiles, which are available immediately after the start-up of new
NEs. They do not have to be specially created and they cannot be
modified. In the table below, the list and description of pre-defined
profiles is given.
Network Pre-defined Content

Element Profile
RNC Primary Counters needed for main Radio Network KPIs
RNC Secondary Most important counters for troubleshooting
RBS Primary Most important Radio Network counters on the RBS level
Table 2-6. Pre-defined profiles
In the following table, the main differences between user-defined

and pre-defined profiles from the user perspective are shown.
Action User-defined Profiles Pre-defined Profiles

Create Possible Not Possible
Modify Partially * Not Possible
Schedule Possible Continuous only
Suspend Possible Possible
Resume Possible Possible
Delete Possible Not Possible**
Possible for RNC for Utran Utran Cell Not Possible
Type MO Instance
and Utran Relation counters
Table 2-7. Main differences between user-defined and pre-defined
profiles
* The operator is allowed to change the attributes of all unlocked

user-defined Subscription Profiles with Inactive Admin state and/or
change the network element selection for an unlocked, standard
user defined standard statistics profile with Active Admin state.
LZT 123 8297 R1C © 2006 Ericsson - 45 -

** Pre-defined profiles can still be deleted but only via direct PM

IRP operations. Since they cannot be recreated it is strongly
recommended to perform the deletion with a great caution and
awareness.
For more information on what counters that are included in the

different predefined profiles, please see Appendix D in this student
book.
Statistics Scanner
Normally, users only need to know about profiles and counters in
order to use performance statistics.
The statistics profiles are only visible in the OSS-RC GUI. The
actual communication between OSS-RC and NEs is performed on
another level – through statistics scanners. A statistics scanner is a
sort of instance of a specific profile at a specific NE.
Figure 2-8. Profiles, Scanners and Counters – RNC example
In the figure above, the concept of profiles, scanners and counters

is shown on the example of an RNC node (same applies to RBS
and RXI nodes).
- 46 - © Ericsson 2006 LZT 123 8297 R1C

2 Data Collection
One profile (for example the RNC Profile “A”) may be mapped to
a corresponding scanner (“A”) at several NE instances (RNC1 and
RNC2). Another profile (RNC Profile “B”) may be mapped to only
one NE instance, and so on.
Profiles can be active or suspended. When active, all corresponding

scanners at selected NEs are also active. When a profile is inactive,
all its scanners are also inactive.
Normally, the users are handling all the performance statistics

administration through profiles. For troubleshooting purposes, or
other special cases, it is also possible to resume, suspend and
monitor each scanner individually through the OSS-RC GUI and
EM. Note that through the EM it is not possible to resume a
scanner.
Counter limitations
There are only two predefined scanners in the RNC. The first,
PREDEF.PRIMARY.STATS, contains only the most important
RNC radio network counters. These counters are typically used to
calculate high-level KPIs. The second,
PREDEF.SECONDARY.STATS, contains important counters,
typically used for troubleshooting.
Both PRIMARY and SECONDARY scanners are initially active on

startup of the RNC
Which counters that are available in the predefined scanners can be

found in the CPI, of Performance Statistics Description 25/1551-
AXD 105 03/1 Uen H
There are limitations on the total amount of counter instances that

can be simultaneously active in each NE:
• RNC – 750,000 incrementing counters with R4 HW or later on

the O&M board. The RNC can handle 1,700,000 counters in total
during a ROP, including counters that have been incremented and
zero-value counters.
• RBS – 17,000 counters
• RXI – 65,000 counters
Note that these limits apply when up to five scanners are running
on the RNC, including the two predefined scanners. With more
scanners active, the capacity is lower.
LZT 123 8297 R1C © 2006 Ericsson - 47 -

For more details on counter limitations please see section 3.4

Counter Limitations in CPI 85/1553-HSD 101 02/4 Uen. Rev C.
Before activating statistics profiles it is recommended to check if

the number of counters would exceed the limits for each NE.
It is recommended to, at least initially, do the counter dimension,

assuming that all Triggerable counters also are incremented. That
means that the dimensioning counter limit, depending on the HW.
It is very likely that a quite substantial percentage of the
Triggerable counters are not incremented for a specific ROP due to
that the triggering conditions for some of the counters are not
fulfilled. These non-incremented counters will then be an extra
margin.
To calculate the Total number of counters and the number of

Triggerable counters, a Spreadsheet exists, 5/1553-AXD 105 03/1
Uen E.
Counter Dimensioning
The counter capacities of the RBS and RXI are sufficient for
detailed Observability of the nodes. Due to the much higher
demand for counters in the RNC, there is a need to carefully
optimize the number of active RNC counters.
Due to the limitations on the maximum number of simultaneously

active counters in one RNC, it may be required to set some rules,
depending on the size of the RNC. For small RNC configurations,
all defined counters may be simultaneously active everywhere, so
the dimensioning is not necessary.
For large RNC configurations it is recommended to set the

following rules:
• Keep the primary profile active all the time, thus allowing the
radio network KPI performance monitoring on cell and higher
levels.
• Keep the secondary profile active all the time if possible. If not,
keep it active all the time when there is no other competing activity.
• Keep the most important UniSaalTp, Aal2Ap, NniSaalTp,

AtmPort, ImaGroup, ImaLink, VclTp, VpcTp and VplTp counters
active all the time.
This is for the continuous transport network KPI performance

monitoring.
- 48 - © Ericsson 2006 LZT 123 8297 R1C

2 Data Collection
• Define Radio Network troubleshooting clusters, typically about

20 RBSs.
Note that when doing a MO instance activation, i.e. selecting a sub-

set of the cells, etc., the maximum limit for each performance
monitoring is 72, 000 counter instances.
• Perform Radio Network troubleshooting on specific clusters, not

on the whole RNC.
Troubleshoot a function at a time, typically choose between

troubleshooting inter-frequency handover, soft/softer handover,
inter-RAT handover, transport network functions or all other radio
network functions. The reason for this is that some functions
contribute with a substantial number of counters, so their belonging
counters cannot be simultaneously active.
Note that some functions’ counters (handover and all cell based
counters) can be activated per cluster and some not (transport
network counters).
To not create unnecessary large files, use only one measurement

(scanner) each for MO class initiated UtranRelation measurements
and GsmRelation measurements. If two or more measurements
(scanners) are used for MO class initiated UtranRelation
measurements, the identity of the UtranRelations are repeated in
the file and that will increase the file size considerably.
Set the parameter counterAlarmThreshold so that a warning

alarm is issued when that allowed limit for the Total number of
counters is reached. It is by default set to 80%.
ACTIVATION
Once the wanted profiles and counters are activated, their values
are generated and being collected after each reporting period. A
reporting period is always set to 15min starting at the 00, 15, 30 or
45 minute in an hour. When all profiles at one NE get suspended,
the generation and collection stops for that NE.
When a counter is active, a value is generated every Result Output

Period (ROP). At the end of each ROP, all the counter values
produced during that period are stored in one ROP file at the NE.
This file is in XML format and compressed using GZIP. The ROP
period is 15 minutes.
LZT 123 8297 R1C © 2006 Ericsson - 49 -

The statistics ROP files are then collected by the OSS-RC and
stored in its file system for a configurable period of time (these
values can be changed by modifying OSS-RC parameters. If the
Statistical Data Mart (SDM) is present, the data can be stored for
up to one year.
STATISTICAL DATA MART

The Statistics Data Mart is a database available for storing the
statistics counters. It provides the ability to store the data for up to
one year. All stored data can be accessed through the SQL
interface. The SDM offers the ability to aggregate the raw data
based on time and object, provides data reliability indicators, and
generates the Calculated Statistics counters.
The SDM is an optional feature in OSS-RC3 and not standard.
The time aggregation is performed for different periods – hour, day,

peak hours/day and week.
The object aggregation is performed only for the Utran Cell

counters as they are aggregated on the RNC and then together with
other RNC counters up-to System level.
- 50 - © Ericsson 2006 LZT 123 8297 R1C

3 Service Accessibility
Objectives
Upon completion of this chapter, the student will be able to:
• Understand how to analyze and interpret the collected data

in order to improve the Call Setup process
• Analyze RAN performance and propose adjustments related

to accessibility
LZT 123 8297 R1C © 2006 Ericsson - 51 -

Intentionally Blank
- 52 - © Ericsson 2006 LZT 123 8297 R1C

ACCESSIBILITY ..................................................................................55
ACCESSIBILITY WORKFLOW ...........................................................55
WORST PERFORMING CELLS ..........................................................56
UE IN IDLE MODE ...............................................................................58

PLMN SELECTION......................................................................................... 59
CELL SELECTION.......................................................................................... 59
LA AND RA UPDATE...................................................................................... 60
PAGING .......................................................................................................... 62
SYSTEM INFORMATION ............................................................................... 66
RANDOM ACCESS..............................................................................68
UL OPEN LOOP POWER CONTROL ............................................................ 70
RRC CONNECTION SETUP................................................................72

EMERGENCY CALLS..................................................................................... 73
MODULE MP LOAD........................................................................................ 73
ADMISSION CONTROL BLOCK .................................................................... 74
LACK OF TRANSMISSION RESOURCES..................................................... 90
LOAD SHARING ............................................................................................. 90
RADIO LINK SETUP....................................................................................... 95
NAS PROCEDURES..........................................................................100
CM SERVICE REJECT................................................................................. 100
RADIO BEARER SETUP...................................................................101

UE CELL RESELECTION DURING HANDOVER ........................................ 105
UE CELL RESELECTION............................................................................. 106

PDP REJECTED........................................................................................... 108
PPP LINK CONTROL TERMINATED ........................................................... 108
LZT 123 8297 R1C © 2006 Ericsson - 53 -

Intentionally Blank
- 54 - © Ericsson 2006 LZT 123 8297 R1C

ACCESSIBILITY
This is the first module that should be optimized. Accessibility is
defined as the ability of a user to obtain requested service from the
system. The figure below is showing a mobile originating call setup
and all the different actions taken before a call is established.
Mobile Originating Call Setup
Random Access
RRC Connection Setup
NAS procedures:
Service Request
Authentication Security
RAB Assignment
Figure 3-1 A mobile originating call setup and the different action taken
ACCESSIBILITY WORKFLOW
Below the Figure 3-2 is showing the Accessibility workflow.
At performance monitoring the worst cells regarding accessibility

is sorted out.
At performance analysis the worst cells are analyzed in the same

order as the mobile will originate a call setup.
Through the Recommendation and Implementation phase

parameters will be looked upon in order to make a change of the
networks performance.
LZT 123 8297 R1C © 2006 Ericsson - 55 -

Through the Verification phase, the collected statistics before

anything is implemented is compared to the statistics collected
after the implementation is done. This is to ensure that there have
been an improvement.
Other Modules
Implementation
Idle mode Squal, Srxlev, qQualmin,
RRC Connection qRxLevMin,
Random Access maxTxPowerUl, t3212,
NAS t3312, aichPower,
RAB Assignment powerOffsetP0,
preambleRetransMax,
constantValueCprach
pmTotNoRrcConnectCsSucc
pmTotNoRrcConnectPsSucc
pmNoRabEstablishAttempt<RAB>
pmNoRabEstablishSuccess<RAB>
pmNoPageDiscardCmpLoadC
pmNoPagingAttemptUtranRejected
Figure 3-2 A The Accessibility workflow
At the end of the workflow, when the verification of the

implemented changes is done, then the optimizer should continue
to the other modules, in this case the retainability module.
WORST PERFORMING CELLS

The most important is to find the worst cells regarding
accessibility. It can be tricky because there are many setup success
rates for RRC connection,
• CS RRC connection,
• PS RRC connection,
• CS RAB and
• PS RAB.
- 56 - © Ericsson 2006 LZT 123 8297 R1C

There are two categories of KPIs:
• 1st category KPIs is to identify which cells/RBSs having

accessibility problems (e.g. RRC connection successful rate
and RAB establishment successful rate)
• 2nd category KPIs is to imply the reasons of failures (e.g.

admission control deny).
In order to find areas with high RRC or RAB establishment

failures, the 1st category KPIs should be used to identify the 10-15
worst performing cells and their surrounding cells. Afterwards,
using 2nd category KPIs estimates the reasons of failures.
The issue is which setup success rate(s) should be used for finding
worst cells. Therefore, a formula to combine all individual success
rates is needed.
Then from the result of the formula, “worst” performing cell can be
found by analyzing the setup success rate of a cell with the weight
factor (in terms of percentage of RRC attempt, e.g. total number of
RRC attempts of that cell / total number of RRC attempts in whole
RNC) in a certain time period, for example consequent 7 days.
If the optimization strategy is to handle all the worst cells regarding

a certain service, then formulas for each service should be used.
Accessibility for CS services:
⎛ pmTotNoRrcConnectReqCsSuccess ⎞ ⎛ pmTotNoRabEstablishSuccess < RAB > ⎞

100 × ⎜⎜ ⎟⎟ × ⎜⎜ ⎟⎟
⎝ pmTotNoRrcConnectReqCs ⎠ ⎝ pmmTotNoRabEstablishAttempt < RAB > ⎠
Where <RAB> = Speech, CS64 or CS57
Accessibility for PS services:
⎛ pmTotNoRrcConnectReqPsSuccess ⎞ ⎛ pmTotNoRabEstablishSuccess < RAB > ⎞

100 × ⎜⎜ ⎟⎟ × ⎜⎜ ⎟⎟
⎝ pmTotNoRrcConnectReqPs ⎠ ⎝ pmmTotNoRabEstablishAttempt < RAB > ⎠
Where <RAB> = PacketStream or PacketInteractive
Due to the fact that UE may perform cell re-selection during RRC
Connection, it may repeat RRC Connection Request message N300
times which may arrive at different cell, and the fact that WCDMA
RAN does not double count the duplicated RRC Connection
Request message, there is a chance that access success rate for
some cells may show larger than 100% success rate.
LZT 123 8297 R1C © 2006 Ericsson - 57 -

The access success rate of better than 100% happens when the
attempt registered at different cell than where the success
registered. The end result is slightly larger success rate for the cell
that completes the access and a slightly less success rate for the cell
that starts the access.
UE IN IDLE MODE
The Idle mode tasks may be divided in five different processes:
• PLMN selection and reselection
• Cell selection and reselection
• Location area (LA) and routing area (RA) registration
• Paging procedure
• Reading system information
Most of the faults in a network appear after the cell has selected the
PLMN and made a cell selection. However sometimes problems
can occur that are related to the UE idle mode behavior.
Figure 3-3 illustrates the relationship between PLMN selection,

cell selection and reselection and LA and RA registration.
Automatic/Manual
Indication to user
mode selection
PLMN Selection
PLMNs
PLMN selected
available
LR Response
Cell Selection/Reselection
Registration
area changes
Location
registration
Figure 3-3 The relationship between some of the idle mode tasks.
- 58 - © Ericsson 2006 LZT 123 8297 R1C

PLMN SELECTION
PLMN selection is the first step in the registration process that
allows a UE to carry out or receive services from an operator. The
UE normally operates on its home PLMN. However, a Visited
PLMN (VPLMN) may be selected if the UE loses coverage. A UE
successfully registers on a PLMN if it finds a suitable cell to camp
on within the selected PLMN. The UE will then obtain a location
or routing registration acknowledgement in the area of the cell on
which it is camped. The UE displays to the user that this PLMN is
registered.
When a UE does not find a suitable cell in the selected PLMN, it

tries to camp on any other acceptable cell within an allowed
PLMN.
When there is a suitable cell available normal services can be

obtained in the cell. If there is an acceptable cell available only
emergency calls are available.
CELL SELECTION
One of the requirements for a suitable cell is to fulfill cell selection
criteria. The UE bases its evaluation on two quantities: Squal and
Srxlev. The cell selection criteria are fulfilled when:
Squal = Qqualmeas- qQualMin > 0
Srxlev = Qrxlevmeas – qRxLevMin – Pcompensation > 0
Where Pcompensation = max(maxTxPowerul – P;0)
• qQualmin is sent in the broadcast information (SIB 3 for

serving cell and SIB 11 for adjacent cells) and indicates the
minimum required quality value. The UE measures the
received quality, “Qqualmeas”; on the CPICH (CPICH
Ec/No) and calculates Squal. This is only done for
WCDMA cells.
• qRxLevMin is also sent in the system information (SIB 3

for serving cell and in SIB 11 for adjacent cells) and
indicates the minimum required signal strength. The UE
measures the received signal Code Power (CPICH RSCP)
and obtains Srxlev
LZT 123 8297 R1C © 2006 Ericsson - 59 -

• maxTxPowerUl is the maximum transmission power

during random access on the RACH and that value is sent
in the system information (SIB 3).
• P is the UE maximum output power according to its class.
Quantities measured and parameters used are shown in Figure 3-4.
• qQualmin
CPICH • qRxLevMin
• Qqualmeas • maxPowerul
• Qrxlevmeas P-CCPCH
Figure 3-4 Determination of Cell Selection Criteria
The UE shall measure the CPICH Ec/No and the CPICH RSCP of
the serving cell and evaluate the cell selection criterion, S, at least
every DRX cycle. The UE shall filter the Ec/No and RSCP
measurements of the serving cell using at least two measurements.
If both criteria are fulfilled and other requirements for a suitable

cell are fulfilled the UE will camp on the cell. The UE will enter
the state “camped normally” where it performs intra-, inter- and
intersystem radio measurements to evaluate if a neighbouring cell
is better than the serving one.
LA AND RA UPDATE
Location and routing areas are used by the CN for mobility
functionality. A paging message for a CS call to a certain UE is
broadcasted to all cells belonging to the LA in which the UE is
registered. Accordingly, a paging message for a PS connection is
broadcasted to all cells in the RA in which the UE is registered.
- 60 - © Ericsson 2006 LZT 123 8297 R1C

The CN has to keep track of the location of the UE. To make this
possible the UE registers to the CN at certain instances.
Specifically when moving from one LA to another, the UE
performs an LA and/or RA Update (LAU/RAU). If the LAs/RAs
are small, there will be more LAUs/RAUs in the system. On the
other hand, if the LAs/RAs are large the number of paging
messages will increase.
There are three types of LA and RA registration updates:
1. International Mobile Subscriber Identity (IMSI) attach or detach
2. Normal LA and RA updating
3. Periodic LA and RA updating
Periodic registration (LA and RA updating) is used to locate the UE

to avoid unnecessary paging attempts for a UE that has lost
coverage and is not able to inform the CN that it is inactive. A
timer t3212 controls the periodic LA update procedure and gives
the time interval between two consecutive periodic location area
updates. The timer is sent in the system information.
When the UE is in connected mode and t3212 expires no periodic

update is performed. When the UE enters Idle mode again a LA
update is performed, see Figure 3-5
UE moves to UE moves to
UE in idle mode
connected mode idle mode
t3212 t3212
LA Update LA Update LA Update
Figure 3-5 Periodic Registration
A timer, called t3312, which gives the time interval between two
consecutive periodic routing updates, controls the periodic RA
update. The value of the timer is sent by the CN to the UE in the
IMSI attach or in the routing area update message accept (this is
not a radio parameter).
LZT 123 8297 R1C © 2006 Ericsson - 61 -

The intensity of RRC connection establishments is considerably

higher for RBSs placed at the LA/RA border compared to RBSs
placed inside the LA/RA. A border RBS can therefore handle less
traffic than an RBS placed inside the LA, due to the increased
signalling load. Therefore, it is recommended that he LA/RA
borders should be placed in areas with low traffic.
A high number of border RBSs will increase the signalling load in

the RNC for the same number of subscribers. If the LAs/RAs are
small, the number of border RBSs will be large. Therefore, the
LAs/RAs must not be too small.
Different PLMNs and thus different Location/Routing Area

Identification (LAI/RAI) should be used for the GSM and
WCDMA networks. If the same LAI/RAI is used for the GSM and
WCDMA networks, the consequence is heavy paging load in the
WCDMA network arising from the GSM subscribers.
PAGING
Paging is initiated upon request from the CN or triggered in
UTRAN. It is used to notify the UE of different events. In
WCDMA RAN P4 these are:
• UE terminating service request for PS or CS services (CN

initiated). CN initiated paging is applicable to UEs in idle mode.
• UTRAN initiated broadcast to inform UEs when System

Information is modified. UTRAN initiated paging is used
whenever System Information (e.g. information about cell
selection/ reselection, addition/replacement of neighbors, handover
etc.) has been updated.
The paging message has the following characteristics:
• Type of paging message: Paging Type 1 or Paging Type 2
• UE identity used in the message (IMSI, TMSI, P-TMSI)
• The physical radio channels and type of resource required
• The area in which the page will be broadcasted (LA or globally)
The paging record varies in length depending on whether it

includes the UE identity in terms of IMSI, TMSI, or P-TMSI. A
PCH frame can carry one “Paging Type 1” message of 10 ms and
may contain between 3-5 paging records, depending on whether the
paging uses IMSI or TMSI/P-TMSI.
- 62 - © Ericsson 2006 LZT 123 8297 R1C

When the UE mode is Cell_FACH or Cell_DCH common or

dedicated physical channels are already in use and the paging
message “Paging Type 2” will be used.
For paging, the capacities of the FACH and the RACH are assumed
to be enough, but there is a risk of congestion in the PCH due to
heavy paging load. Therefore, the probability of congestion in the
PCH must be calculated in order to dimension the LA/RA.
If the operator wants to check the paging success rate, this should be done
on MSC level. Notice that even if a UE does not response to a paging in a
certain Location Area, a second paging might be sent throughout the whole
MSC area (depending on configuration) and UE can be finally reached.
For this reason the most reliable indicator for paging is the one obtained at
MSC level.
Successful First and Repeated Page attempts of total number of first
attempts, Paging success rate in a MSC
⎛ NPAG1RESUCC + NPAG2RESUCC ⎞
100 × ⎜ ⎟
⎝ NPAG1GLTOT + NPAG1LOTOT ⎠
Paging start in the core network but the paging flow in the RAN
network is only considered.
Total number of pages discarded due to central MP load control for

a RNC pmNoPageDiscardCmpLoadC
Pages request rejection for a cell

Paging intensity per cell in a RNC (if RNC, LA and RA consist of

exact same cells):
pmCnInitPagingToIdleUeLa + pmCnInitPagingToIdle UeRa + pmCnInitPagingToIdle Ue

measurement period × total number of cells in that RNC
LZT 123 8297 R1C © 2006 Ericsson - 63 -

In the Figure 3-6 the dashed arrows and boxes considers the packet
switched paging.
For all counter flow, the following are applied:
RBS counters: <Counter Name> (Green color)
RNC Counters: <Counter Name> (Blue color)
MSC Counters: <COUNTER NAME> (Orange color, capital

letters)
Exceptions, Failures:
Successful Outcomes:
Counter Scope: (Scope) <Counter Name>
- 64 - © Ericsson 2006 LZT 123 8297 R1C

RNC received Paging

message from the CN
Connected Check UE status
(RNC) pmcNoPagingAttemptCnInitDcch +
Idle
RNC Sends to the UE Paging

Yes MP Overload?
Type 2 Message
No
(RNC) pmcNoPagDiscardCmpLoadC +
Paging Area is a Yes

Paging is not sent defined LA?
No
Yes Paging Area is a (RNC) pmCnInitPagingToIdleLA +

defined RA?
(RA) pmcnInitPagingToIdleUeRA + No
(RNC) pmInitPagingToIdleUE +
Yes Paging que full?
(Cell) pmcnInitPagingAttemptUtranRejected + No
Paging is not Sent Paging is Sent
Figure 3-6 The Paging counter flowchart
LZT 123 8297 R1C © 2006 Ericsson - 65 -

SYSTEM INFORMATION
The System Information Block (SIB) messages are sent on BCCH
logical channel, which can be mapped to the BCH for UEs in idle
mode, Cell_PCH and URA_PCH or the FACH transport channel
for UEs in Cell_FACH.
The system information explains for the UE how to behave in the

cell and it carries for example information that the UE needs for
cell reselection.
The system information elements are broadcasted in System
Information Blocks. A SIB groups together system information
elements of the same nature, for example cell selection and
reselection parameters. The SIBs are sent in System Information
messages.
Different system information blocks may have different

characteristics for instance regarding their repetition rate and the
requirements on UEs to re-read the SIBs. The SIBs are organized
as a tree.
A Master Information Block (MIB) gives references to a number of

SIBs in a cell, including scheduling information for those SIBs. In
addition to scheduling information of other SIBs, the MIB contains
only information of supported PLMN types (which can be GSM
and/or ANSI 41) and PLMN identity information. The MIB is
transmitted according to standardized scheduling parameters, so a
UE is always able to find the MIB on the BCCH. The MIB carries
information of when the UE can expect to find the different SIBs.
To inform the UE if a change in System information has occurred,

the MIB also delivers a value tag for each SIB. This is to prevent
unnecessary decoding of same information. The tag is used by the
UE to detect a change in SIB. If the tag is changed, UE needs to re-
read the information. If no change in the value tag, the SIB is
discarded or not read.
To inform UEs in idle mode, Cell_PCH and URA_PCH of a

change in the system information, paging in used. In this case, a
“Paging type 1” message is sent to deliver the IE “BCCH
modification info” to notify the new value tag for the MIB.
WCDMA RAN can also inform of the change in the system

information with a System Information Change Indication message
on the FACH transport channel.
- 66 - © Ericsson 2006 LZT 123 8297 R1C

The table below contains a description of the information that is

carried by the MIB and the SIBs.
SIB SIB SIB SIB SIB SIB

Contents MIB
1 3 5 7 11 12
PLMN Identity X
LA and RA updating X
Cell Selection and Reselection Parameters X X
Power Control on Common Channel X
Paging Parameters X
Measurement Management X X
Cell and common channel configuration X
Timers and counters in Idle mode X
When a suitable cell is found, the UE camps on it in a state defined

as “camped normally”. In this state, the UE monitors paging and
system information, performs radio measurements, and evaluates
cell reselection criteria. If the UE finds a better cell, the cell
reselection process selects that cell. The change of cell may imply a
change of the Radio Access Technology (RAT).
LZT 123 8297 R1C © 2006 Ericsson - 67 -

RANDOM ACCESS
Random Access is the same for every kind of service: CS, PS,
Registrations, Signaling, SMS, etc. The UE is in idle state when it
is sending the RRC Connection Request message. The RNC has
correctly received the request over the Random Access Channel
(RACH). However if the RNC does not receive the RRC
Connection Request message the UE returns in Idle state.
NAttempts =0
NAttempts =+1
NAttemptsi > Yes Random

N300 (=5)? Access
Failure
No
UE sends preambles sequences
No response is sent
and/or received by UE Negative AICH is sent
over AICH
(Cell) pmNegativeMessages +
Positive AICH is sent
(Cell) pmPositiveMessages +
UE does not receive

positive AICH
(Cell) pmFaultyTransportBlocks +
UE receives positive AICH
UE sends message
“RRC Connection Request”
RNC does not receive the

message
RNC receives the message
(Cell) pmTotNoRrcConnectReq +
(Cell) pmTotNoRrcConnectReqCs +
(Cell) pmNoRecRandomAccSuccess +
(Cell) pmTransportBlocks +
Figure 3-7 The Random Access counter flowchart
- 68 - © Ericsson 2006 LZT 123 8297 R1C

There is no statistic counter to directly present that random access

procedure failure behaviour. However, the preamble or AICH
counters can be analyzed in order to determine the probability of
occurring random access procedure failure problem.
If maximum allowed attempts (N300=5) has been reached the

cause of failure is that the RBS has blocked the access (negative
AICH) or preambles sent by the UE are not received or ignored (no
AICH is sent) or UE does not receive the AICH positive for any
reason.
During the RACH procedure, the UE is allowed to make a cell

reselection, so it is possible that a few attempts have to be repeated
because the cell changed. In case of cell reselection or when the
response from the RNC is delayed more than T300 (=1 sec) more
than one RRC Connection Request could be sent to the RNC. Only
the first attempt is counted by pmTotNoRrcConnectReq and
pmTotNoRrcConnectReqCs counters.
In case trouble-shooting drive test is done, from TEMS, the

symptoms of this problem are:
1. UE repeatedly prepares RRC connection request messages in

L3.
2. UE camps onto a cell and does not change cells.
3. However, the UE does not receive RRC connection setup or

RRC connection reject message.
Please note that under random access problem, the UE TX power

does not reach to the maximum allowed UE TX power. This should
be compared when the UE does ramp up the UE TX power to its
maximum allowed TX power. The reason for this can be an UL/DL
unbalance or swapped feeders.
The possible reasons why UL/DL is in imbalance are “too large

CPICH power setting”, “imbalance in UL/DL feeder loss”, “high
UL RSSI noise rise” and “cell down”. The primaryCpichPower
could be set too large or the UL RSSI is too high.
It is also important to verify if there is any mistake in the antenna

system configuration and feeder attenuation settings in the system.
If the preamble and RACH message part are wrongly recognized or

lost, it could also be that the AICH power is not large enough.
The solution is to check if the aichPower is set as default. If

needed, increase aichPower.
LZT 123 8297 R1C © 2006 Ericsson - 69 -

UL OPEN LOOP POWER CONTROL

Power Control is essential for the smooth operation of a WCDMA
system, because all users share the same radio frequency band
using different codes.
There are three types of power control in WCDMA as illustrated in

Figure 3-8.
BLE R:Blo ck E rror Ra te

SIR: S ignal to Inte rfer ence Ratio Uplink
Uplink SIR target outer loop
TPC: Transmit Po wer Control
BLER-Measured
Inner loop
SIR-Target
Downlink TPC modified
Uplink
TPC Uplink SIR-Target
Downlink Uplink SIR error
Downlink SIR target
outer loop
RNC
BLER-Measured Open loop
SIR-Target Starting power
modified
Figure 3-8 WCDMA Power Control
Open Loop Power Control is performed in the uplink and downlink

to calculate a minimum starting power for setting up a connection.
In doing so the interference and power required is minimized.
The suitable settings should fulfill below criteria:
powerOffsetP0 x preambleRetransMax +
constantValueCprach >= predefined preamble threshold, and
n x powerOffsetP0 + powerOffsetPpm >= 0, where n can be

in 0 to preambleRetransMax range
Number/percentage of false detections, which is the case that

preamble is detected but there is no enough energy in message part,
due to noise on the random access channel for a carrier (it could be
due to loss of AICH, wrong recognition of preamble or loss of
RACH message part after the UE sends message out):
pmNoPreambleFalseDetection or
pmNoPreambleFalseDet ection
×100%
pmPositive Messages
- 70 - © Ericsson 2006 LZT 123 8297 R1C

Signal-to-interference ratio of all access attempts above the

preamble threshold (except false detection) on RACH for a carrier:
pmReceivedPreambleSir and Number of samples of
pmReceivedPreambleSir
The solution to the problems is to check if the parameters are set

properly. If needed, increase constantValueCprach or/and
powerOffsetPpm
LZT 123 8297 R1C © 2006 Ericsson - 71 -

RRC CONNECTION SETUP

The RNC has received “RRC Connection Request” message from
the UE and the UE has successfully establish a RRC connection.
The RNC receives both the Radio Link Restore Indication from the
RBS and the RRC Connection Setup Complete from the UE.
RNC receives the message
RRC Connection Request
UE context allocation
Context allocation failure
OK
(Cell) pmNoOfRedirectedEmergencycalls + Emergency Call

Redirection of
Emergency Call
No
(Cell) pmNoRejRrcConnMmpLoadC + Processor Load control (MP)

Access not allowed
OK
(Cell) pmNoReqDeniedAdm + Admission Control

Access not allowed
OK
Load Sharing Multifrequency Load Sharing

Load Sharing
RRC Redirection
No
Channel code allocation

(Cell) pmNoDlChCodeAllocAttemptSf128 +
Code not available
(Cell) pmNoDlChCodeAllocFailureSf128+
OK
(UL BBP) pmSetupFailureSf64 + Radio Link Setup
(DL BBP) pmSetupFailureSf128 + (UL BBP) pmSetupAttemptsSf64 +
RAX or TXB (DL BBP) pmSetupAttemptsSf128 +
Congestion
(Cell) pmNoFailedAfterAdm +
(Cell) pmTotNoUtranRejRrcConnReq+ AAL2 Failure AAL2 Setup

OK
RNC sends the message RNC sends the message

RRC Connection Reject RRC Connection Setup
Figure 3-9 A mobile originating call setup and the different action taken
- 72 - © Ericsson 2006 LZT 123 8297 R1C

EMERGENCY CALLS
The UE always initiates the establishment of an RRC connection
by sending the RRC Connection Request message with an
establishment code (Emergency call, Registration, Originating Call,
IRAT Cell Reselection...). When the redirect of emergency calls to
GSM feature is turned on, the request to establish an RRC
connection shall be rejected for all UEs indicating 'Emergency call'.
The following RNC counters, counts the number of successful

emergency positioning attempts.
pmPositioningReqSuccEsAgps
× 100%
pmPositioningReqAttEsAgps
In P5 Emergency calls can be served and positioned in UMTS if

the operator has confidence in AGPS in UMTS otherwise the call is
handed over to GSM
When the feature is 'on' and in operation the following parameter

settings are needed in order for the call to have the possibility to be
served in UMTS and positioned by UMTS:
ecCnSbhoRequestIgnore = TRUE, ecLocationAttemptUmts =
Yes
For UMTS cells where the operator is confident AGPS is

performing well enough to meet the positioning requirements of
emergency calls set the agpsEnable= True.
Congestion control and admission control will not block

emergency calls.
MODULE MP LOAD
RRC connection rejection rate due to module MP load control for a
cell could be found in the following formula:
pmNoRejRrcConnMpLoad C
×100%
pmTotNoRrcConnectReq - pmNoLoadSh aringRrcConn
Note that RRC connection rejection due to module MP load control

happens before inter-frequency load sharing.
One reason for MP load can be too many periodic registrations
LZT 123 8297 R1C © 2006 Ericsson - 73 -

ADMISSION CONTROL BLOCK

Admission control is together with Congestion control part of the
WCDMA Capacity Management. The setting of parameters
associated with Admission control can have a serious effect on
Network Capacity and revenue generated.
Admission control blocks new incoming calls as well as handover

attempts when the load in the system is high. By doing that, the call
dropping probability is reduced. Admission control is used in both
the uplink and downlink. The admission decision is based on air
interface load, by using measurements of uplink interference,
downlink output power as well as the actual number of users. The
admission functionality is also capable of including priority, for
instance emergency calls, in the admission decision.
In the illustration in Figure 3-10 the last UE is blocked because the

cell load has reached the defined ‘admission limit’.
Admission
limit
Cell Load
RBS
Figure 3-10 WCDMA Capacity Management (Admission Control)
Admission Control blocks due to improper admission threshold

settings. There are nine admission policies to control the blocking.
They are UL ASE, DL ASE, DL TX cell power, spreading factor
usage, code usage, Hw usage, amount of HS users, congestion and
number of users in compressed mode. Understanding of which
cause(s) to trigger blocking is necessary to solve the problem.
- 74 - © Ericsson 2006 LZT 123 8297 R1C

RESOURCE REQUEST
Is admission control YES, then
blocked by congestion block
control?
NO, then
accept NO
Check if the requested + est Check if the requested

# compressed mode RL HW + estimated HW YES, then
> CompModeAdm > ulHwAdm, dlHwAdm block
NO NO
YES, then Check if the requested + Check if the requested +
block estimated code usage estimated # HS users YES, then
> DlCodeAdm > hsdpaUsersAdm block
NO NO
YES, then Check if the requested DL Check if the requested
block SF + estimated Dl SF Sf = 8 DL pwr + estimated pwr
> SfXAdm, sf =16 > pwrAdm YES,
sf = 32 then
NO NO
Check if the requested ASE NO Check if the requested ASE Ul

YES, then dl + estimated ASE dl + estimated ASE Ul YES, then
block > AseDlAdm > AseUlAdm block
Figure 3-11 The Admission control flow
When new resources are needed for a radio connection, (a new

radio link is set up or an existing radio link is modified), the
Admission Control function receives a request for admission. The
request specifies the estimated amount of dedicated monitored
resources that the radio connection needs. This estimation is
compared to the available resources and the configured limits for
admission set by the operator, and a response is sent out to grant or
deny the new radio link access to a cell.
To decide on the requests, the Admission Control function requires

information about the load on the dedicated monitored resources
and the amount of resources needed by the requester.
LZT 123 8297 R1C © 2006 Ericsson - 75 -

Admission Control has different policies regarding the maximum

level of the dedicated monitored resources it rejects or admits radio
links. Admission Control is responsible for dividing the available
resources among the non-guaranteed service class connections, and
for differentiating access to resources between guaranteed and non-
guaranteed service class connections, as well as reserving part of
the dedicated monitored resources for hand over of connections.
Counter Description
pmNoReqDeniedAdm Number of RAB establishment and RRC requests denied due to

AC, both drifting and non-drifting UEs. This counter is
increased when admission is denied for radio resources.
pmNoFailedAfterAdm Number of RRC establishment requests and RAB establishment

requests failed after being admitted, both drifting and non-
drifting UEs. This counter is increased after the admission is
accepted for radio resources issue, but when it is denied due to
a shortage of transport network resources/channel elements
The counter pmNoReqDeniedAdm shows the number of RRC

establishment requests and RAB establishment requests denied for
a cell. Please note that this counter is stepped up for RRC
establishment, RAB establishment or channel up-switching if
admission control triggers the blocking in a cell.
The solution to the admission control blocking problem is to check

if the admission thresholds (i.e. ulHwAdm, hsdpaUsersAdm
maximumTransmissionPower, aseUlAdmOffset,
beMarginAseDl, beMarginAseUl, beMarginDlCode,
compModeAdm, dlCodeAdm) match to the original planned
capacity.
If the thresholds do not match to the original planned capacity, the

admission thresholds have to be corrected. Otherwise, re-do the
radio network dimensioning to increase the system capacity or
activate the inter-frequency load sharing to increase the trucking
efficiency.
- 76 - © Ericsson 2006 LZT 123 8297 R1C

Congestion control blocks

Congestion control is used to resolve overload in both the uplink
and the downlink. As shown in the figure below, congestion due to
radio overload in uplink is detected when the uplink Received Total
Wideband Power (RWTP) exceeds a certain configurable threshold
for a longer time than the hysteresis time. The threshold for
detection of uplink congestion is determined by iFCong + iFOffset
and the hysteresis time is determined by iFHyst.
Congestion Control considers uplink congestion to be resolved

when the uplink RTWP for a particular cell is below iFCong for a
longer time than the hysteresis time (or until the next periodic
event-based measurement report for uplink RTWP arrives
indicating that the resource level is below the threshold).
Figure 3-12 Detection of Uplink Cell Congestion Due to Uplink Received

Total Wideband Power
The current default setting is defined so that guaranteed-hs users

are never released (releaseAseDlGhs=0). The reason for this
strategy is that one HS contributes marginally to the downlink cell
congestion because there is only one A-DCH channel per HSDPA
user in downlink. Acting on the non-guaranteed and guaranteed
service class is, under normal circumstances, sufficient to resolve
the congestion in the cell.
The admission control also controls the blocks due to congestion.

Therefore is it important to look at the congestion counters.
• Number of times congestion control is triggered due to high

DL power for a cell: pmSumOfTimesMeasOlDl
• Number of times congestion control is triggered due to high

UL interference for a cell: pmSumOfTimesMeasOlUl
LZT 123 8297 R1C © 2006 Ericsson - 77 -

• pmNoOfTermHsCong & pmNoOfIurTermHsCong - RNC

counters monitoring no. of HSDPA users released due to
congestion
• The total amount of time (sec) was congested in DL during

a reporting period for a cell: pmTotalTimeDlCellCong
• The total amount of time (sec) was congested in UL during

a reporting period for a cell:pmTotalTimeUlCellCong
Samples of the UL RSSI for a cell-carrier could be found in the

counter pmAverageRssi. By using these samples the formulas for
getting the average DL and UL.
Average DL TX power for a cell-carrier:

102
⎡ ⎛ i ⎞⎤
∑ ⎢⎣ pmTransmittedCarrierPower
i =0
i × ⎜ ⎟⎥
⎝ 2 ⎠⎦
102
∑ pmTransmittedCarrierPower
i =0
i
Average UL RSSI for a cell-carrier:

62
∑ [pmAverageRssi
i =0
i × (0.5 × i − 110.5 )]
62
∑ pmAverageRssi
i =0
i
For averaging RSSI and carrier power, these values must be

checked close to the maximum allowed values. If the average
values are close to these thresholds, it implies the chance of having
congestion/admission block is high. In fact, it will be more
interesting to look at max RSSI and carrier power sampled values.
Still as RL setup is taking very short time to establish, it will be
very hard to say how those max values are related to RL failures.
In TEMS Investigation, this can be found by verifying that the UE

send RRC Connection Request, UTRAN send RRC Connection
Reject with cause = congestion.
- 78 - © Ericsson 2006 LZT 123 8297 R1C

Figure 3-13 TEMS Investigation with high UTRA Carrier RSSI
The UL RSSI can be high due to the following:
– non-traffic interference
– High TX power from a UE that are connected to a

far cell. This can happen due to missing neighbors.
RBS HW
The RBS Hardware Monitor provides Admission Control with the
estimation of the hardware usage in a local cell group, separately
for the uplink and the downlink
The relation among the RBS hardware admission policy

parameters, the downlink resource usage in the relevant local cell
group and the admission request parameters are almost the same as
the uplink resource check as shown below.
LZT 123 8297 R1C © 2006 Ericsson - 79 -

Figure 3-14 The Uplink RBS HW Admission Policy
It is worth noting that the soft congestion mechanism on the

downlink hardware resource will consider the connections in the
related cells on cell group level as possible targets. For example, if
an admission request is blocked on downlink hardware, one
connection in the cells connected to the same hardware group is
possibly targeted with a down-switch (in case there is a valid
candidate).
If there are a lot of admission blocks due to RBS HW the solution

to this is either a parameter change or adding new hardware with
the license keys that are retrieved by contacting Ericsson product
management.
The total amount of RBS hardware that can be used might be

limited by the following capacity keys:
WCDMA RBS key for Capacity UL CXC4010071/4002

WCDMA RBS key for Capacity DL CXC4010071/4003
The keys set a limit on the available amount of Channel Elements

that may be utilized simultaneously in the RBS, separately for
uplink and downlink.
Three parameters, ulHwAdm, dlHwAdm, beMarginUlHw and

beMarginDlHw, are related to the RBS HW resource control.
- 80 - © Ericsson 2006 LZT 123 8297 R1C

HS Users
The HS-DSCH is a shared transport channel. If a very large amount
of users simultaneously are assigned to this channel the throughput
per user can become very low. If that is the case, no user might
experience a sufficient end-to-end quality. Therefore, it can be
beneficial to the operator to be able to limit the number of users
that can be allocated to the HS-DSCH in a cell.
Admission Control blocks new radio link admission requests which

involve the allocation to HS-PDSCH/HS-SCCH when the number
of users assigned to the HS-DSCH in the cell exceeds
hsdpaUsersAdm.
If UL 384 is active, an HSDPA RAB establishment is attempted

first on the 384/HS RAB. If for some reason (admission, failed
path loss check) the packet call cannot be setup on the 384/HS
RAB, an attempt is made on the 64/HS RAB provided that the
hsdpaUsersAdm value is not exceeded.
Note that the HSDPA admission policy is only applied to requests

for new HSDPA connections, which follow the Serving HS-DSCH
Cell Selection during RAB Establishment. Therefore, requests
related to mobility of existing HSDPA connections, which follow
the Serving HS-DSCH Cell Change, are never blocked by the
HSDPA admission policy.
DL TX Power
Three parameters, pwrAdm, beMarginDlPwr and
pwrAdmOffset, are related to downlink transmitted carrier power
and are used by Admission Control to decide which admission
requests to admit or reject.
The operator can limit the total maximum power utilized by R99
connections that is allowed to be transmitted by an RBS in a cell by
setting maximumTransmissionPower. The remaining power can
then be used for transmission of HS-PDSCH/HS-SCCH channels
to HSDPA users
This parameter is used when setting up or reconfiguring a cell;

when maximumTransmissionPower is higher than the maximum
downlink power capability reported by the RBS
maxDlPowerCapability, the latter is automatically taken as limit
of the total maximum power allowed in the cell. This mechanism
simplifies setup and reconfiguration of cells and enables the
UTRAN to handle changes in RBS maximum downlink power
capability in a transparent fashion.
LZT 123 8297 R1C © 2006 Ericsson - 81 -

By changing the pwrAdm setting, the portion of downlink power

reserved for HSDPA connections can be increased or decreased.
The default settings balance a mix of R99 and available power for
HSDPA, providing a minimum of 25% power to HSDPA, except
for those cases when R99 takes part of that power due to mobility
and power variations of users in the cell.
For a cell with predominantly R99 traffic, it is possible to increase

the power admission threshold in order to maximize capacity. An
option is to make use of the complete capability before the
congestion resolve mechanism is activated, which is possible
thanks to the fast congestion control mechanism in the RBS. This is
achieved by setting pwrAdm + pwrAdmOffset + pwrOffset
equal to 99% (so that congestion resolve actions can still be
triggered). The pwrAdm can be set to 84% maintaining
pwrAdmOffset at 10% and pwrOffset at 5%. In order to make
sure that no negative impact is produced by such a change, dropped
calls and soft handover failures should be carefully monitored.
Figure 3-15 The Downlink Transmitted Carrier Power Admission Policy
When admission requests are blocked by Admission Control, the

soft congestion mechanism is activated. This mechanism consists
of down-switching an existing non-guaranteed service class
connection to a lower bit rate in downlink, after blocking a (non-
guaranteed <any>) admission request of a lower rate or a
(guaranteed <any>) request. Soft congestion mechanism allows the
control of the accessibility for guaranteed service class connections
in the system, and the control of the sharing of the available
resources among non-guaranteed service class connections in the
system.
- 82 - © Ericsson 2006 LZT 123 8297 R1C

The default admission threshold for guaranteed service class

connections (pwrAdm) has been set to limit the risk of running
into too frequent downlink cell congestion situations under the
conditions mentioned. Depending on mobility and service mix
situation in the cell (and the specific behavior of the UEs), the
admission limit can be increased or decreased. Note that, when
changing, it might be required to reconsider the settings for the
hand over margin (pwrAdmOffset), the margin for non-guaranteed
service class connections (beMarginPwrAdm) and the cell
congestion detection margin (pwrOffset).
The default hand over margin for the downlink transmitted carrier
power resource (pwrAdmOffset) has been set to have a trade off
between the smallest possible reservation for hand over
connections and the reasonable blocking for hand over
connections. In case of a higher percentage of connections in hand
over in a cell and a high experienced blocking of those connections
(i.e. resulting in connections being dropped), this margin should be
increased.
The margin for non-guaranteed service class connections in a cell

beMarginDlPwr has to be tuned according to the required
reservation of downlink air-interface resources for guaranteed
service class connections in a cell. Note that the setting will
influence the intensity of the soft congestion actions on non-
guaranteed service class connections in the cell.
Samples of the DL TX power for a cell-carrier could be found in

the counter pmTransmittedCarrierPower. This counter is an RBS
PDF counter, this includes the power used for HSDPA as well. If
checking the nonHS users transmitted carrier power the counter
pmTransmittedCarrierPowerNonHs should be used.
How many down-switches due to best effort clean up, which is

triggered by DL TX power and code usage admission policies can
be found in the counter pmNoOfSwDownNgAdm.
LZT 123 8297 R1C © 2006 Ericsson - 83 -

ASE block
The ASE of a single radio link depends on the radio connection
type and is expressed in terms of the equivalent number of speech
radio bearers that generate the same amount of air-interface load.
Using this definition, a radio link that has, for example, an ASE of
three in downlink is expected to generate as much interference in
downlink as three speech radio bearers in the cell.
The default setting for the admission policy for the Air Interface
Speech Equivalents (ASE) in uplink aseUlAdm is based on the
characteristic dimensioning of the system not to be loaded more
than 60% of its pole capacity.
In the downlink, the downlink transmitted carrier power is the main

dedicated monitored resource used to control the air interface load.
aseDlAdm is a complement to the load control when the cell can
support so many users that it is close to the pole capacity, which
can cause instability. Therefore, if the downlink transmitted carrier
power is the limiting resource, aseDlAdm can be set very high, so
it does not interfere with the control strategy used for the downlink
transmitted carrier power.
In uplink, besides uplink Congestion Control, ASE is the only

resource that is controlled to allow admission and modifications.
Therefore, the parameters that regulate the uplink ASE admission
policy need to be set in order to minimize the risk of going into
uplink overload.
Figure 3-16 The Uplink ASE Admission Policy
- 84 - © Ericsson 2006 LZT 123 8297 R1C

For downlink, there is a similar pattern to uplink between the

parameters and the ASE monitor policy.
Counter Description
pmSumOfSampAseUl Total ASE UL, that is sum of all sample values recorded
pmSumOfSampAseDl Total ASE DL, that is sum of all sample values recorded
pmNoOfSampAseUl Number of samples of ASE UL increased at every occasion when

the corresponding Sum counter is increased, sampled every 30
seconds
pmNoOfSampAseDl Number of samples of ASE DL increased at every occasion when

the corresponding Sum counter is increased, sampled every 30s
The formulas for checking the average usage of ASE in the

downlink and uplink for a cell can be found below.
pmSumOfSampAseUl
Average UL ASE for a cell:
pmNoOfSampAseUl
pmSumOfSampAseDl
Average DL ASE for a cell:
pmNoOfSampAseDl
Spreading Factor usage policy

Admission Control controls the spreading factor usage in the
downlink at cell level and the number of radio links in compressed
mode.
Admission Control blocks non-guaranteed service class radio links

depending on the spreading factor usage monitored by the
Histogram Monitor.
LZT 123 8297 R1C © 2006 Ericsson - 85 -

Figure 3-17 The Spreading Factor Admission Policy for Non-guaranteed

Service Class Radio Links
Note that (guaranteed, <any>) access requests are not influenced by

the admission policy, but their contribution to the resource
utilization is considered in the monitor.
Admission Control blocks (guaranteed, <any>) admission requests

demanding spreading factor 16 in downlink (streaming PS16/128
radio connection type) when the usage of this spreading factor
exceeds sf16gAdm. By limiting the amount of streaming PS16/128
users that can share the system resources with other guaranteed
service class radio connection types, it is possible to differentiate
accessibility of system resources between high (streaming
PS16/128) and low consuming radio links within the guaranteed
service class.
Admission Control blocks (guaranteed-hs, <any>) admission

requests demanding spreading factor 4 in uplink (PS384/HS radio
connection type) when the usage of this spreading factor exceeds
sf4AdmUl. In cells where the optional PS384/HS radio connection
type is activated, sf4AdmUl can be reduced if the uplink is
experienced as problematic, for example due to high RTWP or
transport network problems.
To prevent unavailability of the transport resources for guaranteed

service class connections, the spreading factor usage policy could
be defined by setting sf8Adm, sf16Adm, and sf32Adm in a certain
way. Note that this could increase the blocking in the radio
network, while blocking on the transport network resources is
reduced (although that is the reason for blocking).
- 86 - © Ericsson 2006 LZT 123 8297 R1C

The 384/HS RAB is enabled by setting the parameters

allow384HsRab to TRUE and sf4AdmUl to a value higher than
zero. In cells without any R99 load, field tests have shown that up
to four simultaneous UL 384 connections with high activity can be
handled without generating excessive interference.
In reality, assuming that the probability of having as many UL 384

connections with the highest activity at the same time is very low,
sf4AdmUl can be set to a value up to 4, taking into consideration
that:
9 As no UL channel switching is implemented in P4,

allowing many 384/HS users in a cell implies a high
channel element consumption, which reduces the amount of
hardware resources that could be allocated to other services.
9 sf4AdmUl should be low in cells where there are no

separate AAL2 path resources configured for HSDPA traffic
in order to save transport network resources for non-
HSDPA traffic.
9 Uplink interference should be constantly monitored as

increased activity in the uplink can create system instability
and dropped calls.
Note that the aseUlAdm default value needs to be increased so that

four UL 384 users can be accommodated.
Downlink code allocation policy

To reserve codes for users in hand over, there is code blocking for
non-hand over requests, while requests for hand over are not
blocked by the downlink channelization code admission policy. It
should be noted that hand over requests can fail on the allocation of
the downlink code and this is detected when allocating the
downlink code.
The default admission limit dlCodeAdm is set to 80% (reserving

20% of the code tree for new handover legs). This setting is
intended for HSDPA enabled cells and is equivalent to a
dlCodeAdm of 75% when HSDPA is not enabled in the cell. In a
network with a high degree of R99 packet users or cells with both
HSDPA and R99 traffic, this value needs to be increased even
further in order to avoid unnecessary code blocking. Setting
dlCodeAdm to 85% and beMarginDlCode to 5% will maximize
the code tree usage and still allow a margin for new soft handover
legs.
LZT 123 8297 R1C © 2006 Ericsson - 87 -

The operator can configure the number of HS-PDSCH codes

(SF=16) that should be allocated for a HSDPA capable cell by
setting numHsPdschCodes. The maximum number of HS-PDSCH
codes is five. Note that the number of HS-SCCH codes (SF=128) is
fixed to one, since code multiplexing is not supported, that is never
more than one user is transmitting per subframe.
The operator has the possibility to configure and change the

number of HS-PDSCH codes allocated in a cell for HSDPA by
tuning numHsPdschCodes . The default value (5) aims at
maximizing the peak rate of users using the HSDPA feature.
When reducing the number of HS-PDSCH codes

numHsPdschCodes, the codes that are to be released are
transparently de-allocated, without affecting ongoing traffic.
Conversely, in case of an increase, the cell will temporarily be
disabled due to its implicit lock/unlock, leading to the release of all
the ongoing traffic in the cell.
Figure 3-18 The Downlink Channelization Code Admission Policy
Non-guaranteed, non-handover admission requests are blocked

when the resource usage exceeds dlCodeAdm - beMarginDlCode.
These service classes can be Packet Switched data and multirab
speech service
Guaranteed, non-handover and guaranteed-hs, non-handover

admission requests are blocked when the resource usage exceeds
dlCodeAdm. These service classes can be Circuit Switched data,
HSDPA as well as the packet switched streaming service
- 88 - © Ericsson 2006 LZT 123 8297 R1C

The counter shows the number of RRC connection requests and

RAB establishment denied by admission control due to lack of
power, code utilization limit, ASE limit and compressed mode
limit.
pmNoReqDeniedAdm
The blocking probability can be used together with Erlang metric

to measure the cell capacity for a given service. Since a cell serves
a mixed traffic, this measure must be used with respect to the
amount of traffic measured for other services.
When a request is blocked on the downlink channelization code

admission policy, the soft congestion mechanism is triggered.
Code allocation failure for SFn, where n is the spreading factor for
a cell could be found in the following formula (as an example the
SF128 was used):
pmNoDlChCodeAllocFailureSf128
×100%
pmNoDlChCodeAllocAttemptSf128
The solution to this problem is to add more carriers or sectorization

to reduce the code usage of the cell
Compressed mode
The setting for the compressed mode admission policy,
compModeAdm, restricts the number of users in compressed
mode. If the presence of compressed mode connections using SF/2
compressed mode technique is high and the quality of the common
channels in a cell is degrading, it can be desirable to restrict the
number of radio links that are allowed in compressed mode in the
cell
How many users are in compressed mode? Well the average

number of user in compressed mode for a cell:
pmSumCompMode
pmSampesCompMode
LZT 123 8297 R1C © 2006 Ericsson - 89 -

LACK OF TRANSMISSION RESOURCES

In P4, transmission resource is not checked in admission control.
Therefore, there is probability of having blocking due to lack
transmission resources.
The number of setup failures on the downlink baseband pool due to

TXB congestion for a RBS, pmSetupFailuresSf4,
pmSetupFailuresSf8, pmSetupFailuresSf16, pmSetupFailuresSf32,
pmSetupFailuresSf64, pmSetupFailuresSf128,
pmSetupFailuresSf256
Normally, in mobile network, the bottleneck for accessibility

should not be on transmission part, i.e. 100% AAL2 establishment
success rate. However, in WCDMA, requested bandwidth for high
data rate services becomes high and as a result, some cells can
perform badly. AAL2 establishment failure can be observed by:
• Non-zero radio link setup failure rate in RRC establishment

with no admission control blocking, no code allocation
failure, no HW failure
• High number of interactive RAB failure (= low interactive

RAB establishment successful rate) but not much admission
control blocking.
Suggestions to the transmission problems are to add additional E1

(The temporary solution is to set sf8Adm = zero so as to reduce the
critical in E1 bandwidth usage) and if necessary, further study on
GPEH’s admission control internal event to obtain the exact reason
why admission control blocks the setup
LOAD SHARING
Load sharing (see Figure 3-19) enhances the performance of a
Radio Access Network by pooling together resources from
different parts of the entire network. Currently, two load-sharing
features are available in the WCDMA RAN:
• Inter-Frequency Load Sharing
• Directed Retry to GSM
The Inter-Frequency Load Sharing is activated in an RNC by

setting the parameter loadSharingRrcEnabled to TRUE. Load-
sharing neighbors must be defined before any load-sharing action
can take place.
- 90 - © Ericsson 2006 LZT 123 8297 R1C

Directed Retry to GSM is activated in an RNC by setting the flag

loadSharingDirRetryEnabled to TRUE.
Inter-Frequency Load Sharing diverts incoming traffic from a more

loaded cell in one WCDMA carrier to a less loaded one in another
WCDMA carrier. Directed Retry to GSM is a one-way diversion
from WCDMA to GSM. Both features are implemented entirely in
the RNC.
Figure 3-19 Load sharing
Idle state cell-reselection can also balance cell load to some extent.
The 3GPP standard specifies two alternatives for selecting the best
cell for a UE in the idle state: the measured quality (Ec/N0) or the
measured signal strength (RSCP) of the CPICH. In Ericsson
systems, Ec/N0 is used. This indirectly takes into account the cell
load.
The load of a WCDMA cell depends on many factors, such as

downlink power, uplink interference, code utilization, etc. For load-
sharing purpose, only the downlink transmitted carrier power is
considered since that is most often the limiting factor on the
capacity of a cell.
To better reflect the available resource in a cell, cell load is

measured as the ratio between the downlink transmitted carrier
power and the admission limit, as given by the cell parameter
pwrAdm.
For HSDPA cells, only the non-HSDPA part is counted, i.e., the cell
load for load-sharing purpose does not include the power used for
HS-PDSCH and HS-SCCH. The downlink transmitted carrier
power for the non-HSDPA part is measured by the RBS and
periodically reported to the RNC.
LZT 123 8297 R1C © 2006 Ericsson - 91 -

In order to perform the necessary evaluation for making a load

sharing decision, a cell has to be aware of the load of all of its load-
sharing neighbors. Inter-Frequency Load Sharing is performed
during the RRC connection establishment procedure and Directed
Retry to GSM during the RAB establishment procedure.
With Inter-Frequency Load Sharing, the cell load is measured

directly in terms of the actual downlink power. A UE will be
guided to the most suitable cell during the RRC connection
establishment.
The load sharing can be monitored by the counters:

pmNoOfReturningRrcConn, pmNoLoadSharingRrcConn
Load Sharing
RNC sends RRC Connection Reject

message including the Redirection Info IE
that tells the mobile to try to access the
network via the specified frequency
(Cell) pmNoLoadSharingRrcConn +
(Cell) pmTotNoUtranRejRrcConnReq +
The UE reselects a cell in the specified

frequency and tries to access the network
RRC Conn.
The UE Does the UE Setup Failure.
succeeds to return back to UE goes back to
setup RRC conn. the original
No frequency? No idle state
in the new freq?
Yes
Yes
(Cell) pmTotNoRrcConnectReqSuccess + (Cell) pmNoOfReturningRrcConn +

(Cell) pmTotNoRrcConnectReqCsSuc +
Random Access
Load Sharing is not allowed
in this 2nd access attempt
Figure 3-20 The load sharing counter flow
- 92 - © Ericsson 2006 LZT 123 8297 R1C

Ratio between RRC connection returning and redirection due to

load sharing for a cell:
pmNoOfReturningRrcConn
pmNoLoadSharing RrcConn
RRC Connection Redirection

In order to reduce RRC Connection direction problems is to do a
parameter check. There are many problems that can be reduced
from start if this is done.
If there is a too large difference of the pilot power setting between

two carriers, it will cause a higher redirection rate. The parameter
primaryCpichPower should be checked between the carriers.
Reduce the power if the difference is too large.
If there is a too large difference of the RF patterns between two

carriers (e.g. due to big difference in tilt angles between cells) it
will cause a higher rate. The radio coverage should be checked
between the carriers.
Improper inter-frequency cell re-selection parameter setting can

also cause a high rate of RRC Connection directions. The inter-
frequency cell reselection parameters (e.g.
interFreqFddMeasIndicator, qHyst2, qOffset2sn and
sInterSeach) should be checked so that they are set properly. If
not, correct them.
Improper capacity management parameter setting will also cause a

high rate. Check if capacity management parameters (i.e.
maximumTransmissionPower and pwrAdm) are set correctly
because they affect the decision of redirection. If not, correct them.
Other parameters that should be checked are

fachMeasOccaCycLenCoeff, qQualMin, qRxLevMin,
maxTxpowerUl,
Incorrect definition of a target cell candidate will increase the ratio.

If the coverage of target cell candidate collocates to the source cell.
If not, remove this candidate, loadSharingCandidate. Repeaters
can also cause incorrect RRC connection redirection to a carrier,
which is no coverage.
LZT 123 8297 R1C © 2006 Ericsson - 93 -

Directed Retry to GSM

Speech calls with no ongoing packet connections are considered
for Directed Retry during RAB establishment. If the UE supports
GSM handover and the load of the WCDMA cell exceeds a certain
threshold, the WCDMA RAN will request a blind inter-RAT
handover to a pre-configured GSM cell via the core network. The
RAN operator has considerable control over this feature. Both the
load threshold and the fraction of speech calls to be diverted to
GSM are configurable.
The success rate can be monitored by two counters:
pmNoDirRetryAtt gives the total number of Directed Retry

attempts and the pmNoDirRetrySuccess gives the number of
successful attempts.
The failures can be observed by the successful rate of directed retry

to GSM for a cell:
pmNoDirRetrySuccess
×100%
pmNoDirectedRetryAtt
Note that unsuccessful attempts are picked up by the WCDMA

RAN if the call returns to the source cell. The call will then be set
up according to the normal call-setup procedure.
If the GSM cell is congested, another TRU can be added or remove

the GSM redirection candidate. The loadSharingGsmThreshold
can be increased or loadSharingGsmFraction can be reduced so
that not many speech connections are redirected to GSM.
There might be GSM coverage problems due to low coverage or to

that, a repeater is deployed for the WCDMA resource cell. Either
the coverage for the cell should be improved or the GSM
redirection candidate should be removed.
Relative parameter: directedRetryTarget,
Note that RRC connection rejection caused by inter-frequency load

sharing or re-direction of emergency calls to GSM is not
considered as RRC connection setup failure.
- 94 - © Ericsson 2006 LZT 123 8297 R1C

RADIO LINK SETUP

Radio link setup happens when establishing RRC connection or a
RAB during FACH -> DCH, e.g. FACH -> PS + voice or FACH ->
PS + PS streaming. The channel type up-switching during channel
switching , also needs radio link setup procedure.
UE RBS RNC
Power control,
Radio link setup
admission control, etc.
Radio Link Setup Request
Resource allocation
Radio Link Setup Response

AAL2 connection
setup
Start Rx and radio connection
supervision
Figure 3-21 Radio link setup procedures
There is no statistic counter to directly present that radio link setup

failure problem during RAB establishment. What that can be done
is to analyze the admission control and code allocation counters to
determine the probability of occurring such problem.
Radio link synchronization happens during RRC connection

establishment. The radio link synchronizations also takes place
during new RAB establishment, such as channel type up-switching,
for FACH -> DCH, e.g. FACH -> PS + voice or FACH -> PS + PS
streaming
UE RBS RNC
Radio link synchronization Transport channel

synch.
Start Tx
L1 synch.
Radio Link Restore Indication
Figure 3-22 Radio link synchronization procedures
LZT 123 8297 R1C © 2006 Ericsson - 95 -

Radio link synchronization procedure happens both during RRC

connection establishment but also during RAB establishment.
AAL2 failure
AAL2 Setup
(Cell) pmNoFailedAfterAdm +
OK
RNC sends the message

(Cell) pmTotNoUtranRejRrcConnReq RRC Connection Setup
RNC sends the message

RRC Connection Reject No “RRC Connection
Setup Complete”
received
Yes
Call Redirected Redirection of Yes
to GSM Emergency
Calls?
No
Restore Indication
No received from RBS
(Cell)pmNoCellDchDisconnectAbnorm +
Yes
RRC Conn. Setup Failure.
UE goes back to idle state (Cell)pmNoFailedAfterAdm +
(Cell) pmTotNoRrcConnectReqSuccess +
(Cell) pmTotNoRrcConnectReqCsSuc +
Figure 3-23 Radio Link setup counter flow, continued from the Random
Access flow figure Figure 3-7
Loss of RBS Contact

RNC sends “radio link setup request” to RBS; however, the RNC
does not receive any response from RBS and the timer expires.
This problem is classified as “loss of RBS contact”.
The solution to this problem is to check if the configuration of the

transport network is correct. Re-dimension the transmission
bandwidth (if needed).
L1 Synchronization failure
It is very difficult to trouble-shoot the radio link synchronization
failure. With L1 Synchronization failure, the RRC Setup will fail
for the Location Area Update (LAU), as an example.
- 96 - © Ericsson 2006 LZT 123 8297 R1C

The L1 synchronization has to be achieved in both DL and UL. To

achieve this, correct power settings are needed for DlinitSirTarget
and UlInitSirTarget. The synchronization is first achieved in the
DL. The UE will then wait SRBdelay number of frames (1 to 7)
before it sends the RRC Connection Setup Complete message. If
this fails, no RRC Connection Setup Complete is received from the
UE and the RRC Connection is not established.
In TEMS, the L1 synchronization problems can be found when the

UE does not send the RRC Connection Setup Complete message.
However, some other problems may occur at the same time, as the
UE ramps up its transmitting power to the maximum, due to the
increased interference.
The UE ramps up its

power to the
maximum.
Figure 3-24 L1 synchronization problem
There are several methods to handle these L1 synchronization

failure caused due to coverage issues on SRB and/or DCH, to drive
test, check the parameter settings of dlattenuation and
ulattenuation as well as the antenna configuration. The main thin
is to find out if the system is balanced regarding UL and DL cell
coverage.
LZT 123 8297 R1C © 2006 Ericsson - 97 -

Note that if antenna configuration and attenuation settings are

incorrect, the impact should be in RRC establishments for both
signaling and traffic. The parameters cPO and cBackOff can also
be increased in order to obtain larger initial DL DPDCH and UL
DPCCH powers.
The DL SRB / DCH maximum power, i.e. minPwrMax (only for

DL coverage issue) can be increased and the CPICH power can be
reduced in order to get a system that is more balanced.
In TEMS Investigation Radio Link Synchronization, failure can be

visualized by the figure below.
Figure 3-25 Radio Link Synchronization failure
In the AS, there are two SC’s, RF conditions become very good for
one of them and bad for the other, UE TX power is low. It is
assumed that the good radio link is out of synchronization because
the DL BLER is increasing while the RF conditions become better
for one SC. Finally the call drops because high DL BLER.
The initial power setup power parameters ulInitSirTargetSrb,

ulInitSirTargetLow, ulInitSirTargetHigh, dlInitSirTarget,
should be checked.
- 98 - © Ericsson 2006 LZT 123 8297 R1C

S-CCPCH (FACH1) power

Due to lack of S-CCPCH power, the UE cannot receive the RRC
connection setup message.
The following formula should only be used if drive tests have been
performed in order to verify the S-CCPCH power.
Percentage of getting AICH but no RRC connection setup,

excluding cell (re)selection:
No of AICH_ACK - No of RRC connection setup - No of cell (re)selection during RRC establishment

× 100%
No of AICH_ACK
Note that above observations cannot absolutely reflect “not enough

S-CCPCH power” because losing preamble message could affect
the result.
As an example of an AICH problem can be found in TEMS

Investigation.
6 RRC Connection request
Very good RF conditions
Figure 3-26 Radio Link setup failure: AICH problem in TEMS

Investigation
LZT 123 8297 R1C © 2006 Ericsson - 99 -

The UE sends out several RRC Connection request but it does not
receive the RRC Connection setup from the UTRAN. The RF
conditions could be fairly. The UE does not get the AICH. It can be
seen in the Random access reports, in the mode reports window.
One solution to the problem is to increase maxFach1Power.
NAS PROCEDURES
The Signaling Connection is used to carry the Non Access Stratum
(NAS) call setup message between the CN and UE.
The setup of the first Signaling Connection is followed by the

procedure Report of Common ID where a permanent NAS UE
identity is received by the SRNC from the CN. The permanent
NAS UE identity is really the IMSI.
The establishment is initiated by the reception of a RRC message

that contains the NAS message that originally triggered the
Signaling Connection setup.
Most of the faults regarding the NAS procedures are core network
problems and are therefore not discussed further.
CM SERVICE REJECT
During the call setup procedure, the UE receives the CM service
reject message with cause network failure, just after that, the
system sends the RRC Connection release message.
- 100 - © Ericsson 2006 LZT 123 8297 R1C

CM Service reject
with cause:
Network failure
Figure 3-27 NAS failure: CM service reject in TEMS Investigation
This is not an RF problem, is a network problem
RADIO BEARER SETUP

The RAB establishment is done in two parts, the first is the setup of
an Iu bearer and the second is the setup of the Radio Bearer (RB).
The establishment and the mapping onto physical channels for each
of the different supported RABs will be explained below.
In Figure 3-28 the general procedure of establishing a speech, a

CS64 or a streaming 57.6 RAB is shown.
LZT 123 8297 R1C © 2006 Ericsson - 101 -

DPDCH/DPCCH
UE State
SRB Signaling C onnection
Cell_DCH D PD CH/D PCCH
Non Access Stratum call setup
RA B assignment
request 1
Setup new Radio Bearer id= Speech,CS64
or streaming 57.6
D PD CH/D PCCH
UE State 3 N ew Signaling C onnection
SPEECH
Cell_DCH Setup Iu bearer
User plane Radio Bearer 2
(AAL2)
DPDCH/DPCCH
Figure 3-28 Speech, CS 64, Streaming 57.6 RAB establishment
1. A ‘RAB ASSIGNMENT REQUEST’ is received from the CN

indicating the RAB ID to be ‘speech’. The SRNC determines
the new RC configuration (taking into account the existing one)
and check the UE capabilities (to check if the new
configuration can be supported by the UE).
2. The SRNC initiates the setup of an AAL2 connection for the Iu

bearer.
3. The UE is ordered to setup a new Radio Bearer (RB) and

activate the new configuration at the desired Current Frame
Number (CFN). In the SRNC the MAC shall be reconfigured
without waiting for the RLC acknowledge. When finished the
UE acknowledges the successful RB setup and the UE will be
in CELL_DCH state.
The interactive PS RAB can be set up on either a common or a

dedicated channel. The streaming RAB must be setup on dedicated
channel. The steps taken to establish an Interactive PS RAB are
shown in Figure 3-29 below.
- 102 - © Ericsson 2006 LZT 123 8297 R1C

D PD C H /D PC C H
U E S tate
SR B Signalin g C onn ection
C ell_D C H D PD C H /D PC C H
N on A ccess S tratu m call setup
R A B assignm ent
request 1
S etup new R adio B earer id= Interactive
FA C H /D C H
U E S tate 3 N ew Signaling C onnection
C ell_F A C H
U ser plane R adio B earer E xisting A A L 5 Iu
or
b earer is u sed
C ell_D C H R A C H /D C H
2
D ata B u ffers
Figure 3-29 Interactive RAB Establishment
1. A ‘RAB ASSIGNMENT REQUEST’ is received from the CN

indicating the RAB ID to be ‘interactive’. The SRNC
determines the new RC configuration (taking into account the
existing one) and check the UE capabilities (to check if the new
configuration can be supported by the UE).
2. The existing AAL5 signaling Iu bearer is used to carry the user

plane traffic.
3. The UE is ordered by the SRNC to set up a new RB. In the case

of Cell_FACH, the UE will also perform a Cell Update after the
RB is set up.
Data buffers are used for retransmissions and packet data.
LZT 123 8297 R1C © 2006 Ericsson - 103 -

The RRC has been established and the UE sends the Activate PDP
Context Request message to the system. The Radio Bearer Setup
message in the DL is never sent, the network eventually sends, and
Activate PDP Context Reject message with cause “unspecified”.
Act. PDP Cont. Req. Sent RRC Established
Radio Bearer
Setup Message
never sent
PDP Context Activation Failure

Figure 3-30 PDP Context Activation Failure. Cause: Radio Bearer Setup
not sent.
- 104 - © Ericsson 2006 LZT 123 8297 R1C

Context Request message to the system. The Radio Bearer setup
and Radio Bearer Reconfiguration are performed. The Downlink
Direct Transfer message is sent to the UE followed by an Activate
PDP Context Reject message with cause “User authentication
failed”.
Radio Bearer Setup Complete
User authentication
failed
Figure 31: PDP Context Activation Failure. Cause: User Authentication

Failed
UE CELL RESELECTION DURING HANDOVER

Accuracy to reflect the “connection setup failure” issue by call
setup failures could be affected due to handover. Actually, these
equations contain two components: RRC establishment successful
rate and RAB establishment successful rate. For RRC
establishment, UE camps onto one cell only. Oppositely, UE could
be in soft or softer handover during RAB establishment and the
RAB attempt and success counters are just stepped referred to the
best cell in the active set. Thus, if the cell camped for RRC
establishment is not the best cell in active set during RAB
establishment these equations cannot reflect the actual setup
problem for the cell.
LZT 123 8297 R1C © 2006 Ericsson - 105 -

The UE has no time

to HO to the best
server
Attempt to SC122,
but SC267 is the
best server
Figure 3-32 UE Cell reselection during handover
The UE makes a call attempt to a SC that is not the best server and
later it does not have time make the HO because the Ec/No are
very bad. This is a cell reselection problem because the UE should
make the attempt to the best cell.
UE CELL RESELECTION
The RRC connection can fail if the UE does the cell reselection too
often. Possible reason of having always cell reselections is idle
ping-pong, which may be caused due to improper cell reselection
parameter setting and/or pilot pollution
The UE sends only one RRC Connection Request and does not
receive the RRC Connection setup from the UTRAN. Immediately
after this, the UE starts to read SIB. RF conditions are good. It is a
UE problem because the UE does not re-transmit the RRC
Connection Request.
- 106 - © Ericsson 2006 LZT 123 8297 R1C

Only one RRC

Connection Request
Good RF Conditions and the UE reads SIB
Figure 3-33 UE Cell Reselection
Note that the UE may perform cell re-selection during RRC

times which may arrive at different cell, and the fact that WCDMA
RAN does not double count the duplicated RRC Connection
Request message, there is a chance that access success rate for
some cells may show larger than 100% success rate. The access
success rate of better than 100% happens when the attempt
registered at different cell than where the success registered. The
end result is slightly larger success rate for the cell that completes
the access and a slightly less success rate for the cell that starts the
access.
Normally, treSelection will affect UL RSSI performance because if

the UE camps onto a cell, which is not the best cell, the UE will
transmit slight larger UE TX power during RRC establishment and
it will consequently generate more UL RSSI to the adjacent cells.
To solve the reselection problem, the pilot pollution has to be

reduced and re-plan the cell coverage if needed. The cell
reselection parameters (i.e. qQualMin, qRxLevMin,
maxTxpowerUl, qHyst2, qOffset2sn, treSelection and
sIntraSeach) must be checked if they are set properly.
LZT 123 8297 R1C © 2006 Ericsson - 107 -

TEMS INVESTIGATION FINDINGS

Below in the following sections there are several different problems
found with TEMS Investigation in a WCDMA network.
PDP REJECTED
Context Request message to the system. The Radio Bearer setup
and Radio Bearer Reconfiguration are performed. The Downlink
Direct Transfer message is sent to the UE followed by an Activate
PDP Context Reject message with cause “unspecified”.
Radio Bearer Setup Complete
Activation rejected,
unspecified
Figure 3-34 PDP Context Activation Failure. Cause: Radio Bearer setup
then PDP rejected
PPP LINK CONTROL TERMINATED

Context Request message to the system. A Downlink Direct
Transfer message is sent to the UE followed by the Activate PDP
Context Reject one with cause “The PPP link control terminated”.
- 108 - © Ericsson 2006 LZT 123 8297 R1C

Radio Bearer Setup Not Sent
Activate PDP Context Reject

after DL Direct Transfer
Figure 3-35 PDP Context Activation Failure. Cause: PPP Link Control
terminated
LZT 123 8297 R1C © 2006 Ericsson - 109 -

Intentionally Blank
- 110 - © Ericsson 2006 LZT 123 8297 R1C

4 Service Retainability
Objectives

in order to improve the Neighbor handling and the Hanover
Performance

to retainability
LZT 123 8297 R1C © 2006 Ericsson - 111 -

Intentionally Blank
- 112 - © Ericsson 2006 LZT 123 8297 R1C

RETAINIBILITY .................................................................................. 115
RETAINABILITY WORKFLOW.......................................................... 115
WORST CELLS ................................................................................. 116

SPEECH ....................................................................................................... 116
VIDEO ........................................................................................................... 116
PACKET SWITCHED DATA ......................................................................... 117
DROPPED CALLS............................................................................. 117

UL OUT OF SYNCH ..................................................................................... 118
CONGESTION .............................................................................................. 126
WCDMA RAN HANDOVER .......................................................................... 129
SOFT/SOFTER HANDOVER........................................................................ 130
HSDPA MOBILITY ........................................................................................ 146
INTER-RAT HANDOVER.............................................................................. 152
MISSING NEIGHBOUR RELATIONS........................................................... 155
OTHER REASONS ....................................................................................... 156
WNCS (WCDMA NEIGHBOURING CELL SUPPORT) .....................157

LOSS OF ASU COMPLETE OR MEASUREMENT REPORTS.................... 159
INTER-RNC HANDOVER FAILURE............................................................. 161
UE RELATED PROBLEM ............................................................................. 162
LZT 123 8297 R1C © 2006 Ericsson - 113 -

Intentionally Blank
- 114 - © Ericsson 2006 LZT 123 8297 R1C

RETAINIBILITY
This module is done after the accessibility module. Retainability is
defined as the ability of a user to retain its requested service once
connected for the desired duration.
There are a number of factors that influence Retainability

performance after call establishment in the network. These factors
include:
• Handover performance (soft/softer/Iur/IFHO/IRAT) and missing

neighbor cell
• UL/DL imbalance
• Incorrect parameter settings (power, admission, release)
• Congestion
• Radio environment impact (corner effect, fast Ec/No drop, Pilot

pollution etc)
• Node Hardware failure
• E1/T1 Congestion
RETAINABILITY WORKFLOW
Below the Figure 3-2 is showing the Retainability workflow.
At performance monitoring the worst cells regarding retainability is

sorted out.
At performance analysis the worst cells are analyzed in the same

order as shown in the Figure 4-2, the network initiated abnormal
call releases. First the Synchronization performance is analyzed,
then the Congestion control, SHO functions, IRAT Handovers


after the implementation is done. This is to ensure that there has
LZT 123 8297 R1C © 2006 Ericsson - 115 -


Implementation
Other Modules
pmSystemRabRelease<RAB> ReleaseConnOffset
pmNormalRabRelease<RAB> maxTxPowerUl,SirMax,
pmNoSysRelSpeechULSynch MinPwrRl, treselection,
pmNoOfTermSpeechCong timetotrigger1,
pmNoSysRelSpeechSoHo reportingrange1
UL out of Synch
Congestion control,
SHO functions
IFHO functions
IRAT Handovers
Figure 4-1 A The Retainability workflow

implemented changes is done, then the optimizer should continue
to the other modules, in this case the integrity module.
WORST CELLS
In terms of the ranking of the worst performing cell, both the
number of drop calls and the dropped call rate should be
considered. Alternatively, ranking can be done based on the net
contribution of each individual cell to the total dropped call on
RNC level.
Check where worst performing cells are located. If they are in

border area between two RNCs, Iur handover performance should
be monitored.
In order to identify the worst performing cells due to dropped call

the following formulas could be used.
SPEECH
Shows speech call drop rate for originating and terminating calls.
pmNoSystemRab Re leaseSpeech
100 ×
( pmNoNormalRab Re leaseSpeech + pmNoSystemRab Re leaseSpeecch )
VIDEO
Shows video call drop rate for originating and terminating calls.
- 116 - © Ericsson 2006 LZT 123 8297 R1C

pmNoSystemRabReleaseCs64
100 ×
( pmNoNormalRab Re leaseCs 64 + pmNoSystemRabReleaseCs64 )
PACKET SWITCHED DATA

Shows dropped call for Interactive PS calls regardless of DCH or
FACH state including HSDPA calls:
100 ×
(pmNoSystemRabReleasePacket )
( pmNoNormalRab Re leasePacket + pmNoSystemRabReleasePacket )
Shows dropped call for PS 64 streaming calls.
pmNoSystemRab Re leasePacketStream
100 ×
( pmNoNormalRab Re leasePacketStream + pmNoSystemRab Re leasePacketStream )
DROPPED CALLS
There are several known reasons for speech drop that can be
analyzed in order to understand the root causes for drop and find
out how to reduce drop call due to these reasons.
1- Drop due to UL out of sync (Radio Connection supervision)
2- Drop due to congestion (Congestion control)
3- Drop due to soft/softer handover (Soft Handover Functions)
4- Drop due to IRAT Handovers (IRAT Handover Functions)
5- Drop due to other reasons
Abnormal call releases for speech, CS64 and CS 57 calls can be

initiated either by the UE or by the UTRAN (RNC).
For speech, CS64 and CS57 calls the abnormal release leads in any
case to the Signaling Connection Release procedure in the counter
flow charts. The Signaling Connection Release is the release of the
connection of the UE with the CN; it includes the release of all
radio resources (RRC Connection Release).
LZT 123 8297 R1C © 2006 Ericsson - 117 -

In Figure 4-2 the network initiated abnormal call releases are

shown. Any abnormal release due to RNC algorithms (Radio
Connection Supervision, Congestion Control, Soft-Handover
functions, IRAT Handover Functions) or other unrecoverable
failures (signaling failures, detected UE failures, etc) are contained
in this group.
Figure 4-2 Network Initiated abnormal call releases
The “Other Failures Detected” blocks collecting any other

unrecoverable failures, those are not included by the first line
blocks. These failures will not be further investigated in this
document since there are no counters related. Some specific
information about these failures can be obtained by the cause of the
Iu Release Request or the Iu Release Command messages sent in
the Signaling Connection Release or by other specific trace in the
RNC and/or CN.
UL OUT OF SYNCH
Out of synch drops are found through the function Radio
connection supervision.
The aim of this function is to monitor the status of the radio

connection and to initiate the release of signaling connection in
case of radio connection is lost.
Three different supervision algorithms can trigger the condition of

“radio connection lost”:
- 118 - © Ericsson 2006 LZT 123 8297 R1C

• Supervision of radio link synchronization status
• Supervision of RLC protocol (Layer 2 failures)
• Supervision of connections on common channels
The supervision of radio link synchronization status is performed

on dedicated channels only. The supervision of RLC protocol is
performed on all channels (dedicated and common). The
supervision of connection on common channels is performed
(obviously) only on common channel. The RLC supervision works
in parallel with the others.
One of the other reasons for dropped call is drop due to uplink out
of synch. Out of synch is a symptom for other problems such as
lack of DL coverage, lack of UL coverage, high UL interference
and etc in the network.
There is no straightforward approach to identify reasons behind out

of synch problem. However, it is still possible to try the following
methods to find lack of coverage.
Figure 4-3 Radio Link Set Supervision States
Idle state is the default state and entered after a dedicated RLS Release.
Resources for dedicated RLS have not been allocated or configured.
LZT 123 8297 R1C © 2006 Ericsson - 119 -

Initial Synchronization state is entered when the resource for the

dedicated RLS is allocated and configured, but synchronization has
not yet been reached. This state can only be entered from the idle
state
In sync state is entered when the UL synchronization is achieved

from the Initial Synchronization, Out-of-Sync state, or Wait for In-
Sync. When the BER is below the threshold value for a number of
consecutive frames, the RLS is considered re-established. The RBS
resumes regulating the output power according to the Power
Control mode
Wait for In-sync is a state where the criteria for out of sync has
been met. The RBS starts a timer (timerlost) in order to wait for
the synchronization to be re-established. Whenever the RLS
becomes synchronized, this timer is stopped. If the RBS does not
re-establish UL synchronization during the period of time given by
the timer timerlost, the "Out-of-Sync" state is entered and the RLS
Supervision algorithm sends the NBAP message RADIO LINK
FAILURE INDICATION to the SRNC.
Out-of-Sync state is entered when the UL synchronization is lost.

When the pilot BER threshold value has been exceeded for a
number of consecutive frames, the RLS is considered out of sync.
When nOutSyncInd number of consecutive frames are out-of-sync a

timer rlFailureT is started and at expiry the RLS is considered out-of-sync
and Radio Link Failure is reported to the SRNC. When the RLS is out-of-
sync and nInSyncInd number of frames are in-sync, the RLS is
considered in-sync and Radio Link Restore is reported to the SRNC.
The connection is considered lost by the RCS when the last RLS, for the
connection, has been out-of-sync for a time given by the parameter
dchRcLostT. However, for an HSDPA connection, the connection is
considered lost by the RCS when the RLS that contains the Serving HS-
DSCH cell, has been out-of-sync for a time given by the parameter
hsDschRcLostT, the timer dchRcLostT is not used in this case. In both
cases, when the timer expires, the signalling connection is released. The
RNC level parameter hsDschRcLostT can be set to a lower value than
default so that the HSDPA performance does not degrade drastically
before the connection is released. This can be a way of tuning HSDPA
borders (Iur or when entering a non-HSDPA coverage area), where the
HSDPA call is released and re-established on either HSDPA or R99.
The RBS, in order to retain synchronization, generates UL-TPC

bits in a pattern that gradually increases the output power. TPC
received in UL (DL-TPC) are not used
- 120 - © Ericsson 2006 LZT 123 8297 R1C

Shows fraction of drop due to uplink Out of Sync reason.
100 ×
( pmNoSys Re lSpeechULSynch)
( pmNoNormalRab Re leaseSpeech + pmNoSystemRab Re leaseSpeech )
The amount of dropped call due to UL out of synch is depended on

the value of ReleaseConnOffset parameter. If this parameter is set
high, then the uplink RSSI will increase and will impact drop due
to uplink Out of Sync.
There are a number of parameters that impact in- and out of synch
issues. These parameters could be of interest when study out of
synch and its impact. Changing parameters such as nInSyncInd,
nOutSyncInd and rlFailureT might help to recover out of synch
when it lasts for short period of time and it not caused due to lack
of coverage.
In TEMS Investigation, the problem of UL out of Synch can be

found through high UE TX power. In soft handover, the UE
connects to a distant cell in the active set and this distant cell is the
best serving in active set.
CPICH_RSCP
CPICH_Ec/No
Cell A Overshooting cell, e.g. cell
Tim
HO area HO area
UE Tx PWR
Max allowed
UE Tx PWR
Tim
HO area HO area
Drop
Figure 4-4 UE TX Power vs. CPICH Ec/No and RSCP
LZT 123 8297 R1C © 2006 Ericsson - 121 -

The trend of UL performance of the best serving cell is very good,

e.g. CPICH_RSCP is increasing. However, the UE is always
requested to transmit its maximum transmission power.
When all other cells have been released and only that distant cell is
kept in the active set, the connection will drop due to UL out of
synchronization. It should be noted that UTRAN sends
rrcConnectionRelease message with cause = normalEvent to the
UE to release the connection if UL out of synchronization.
This problem is caused due to cell overshooting. The direct

solution is to remove the coverage caused by this overshooting cell
Increasing the RBS search window size could overcome this

problem. However, it is not good solution because overshooting
will cause interference (i.e. lower capacity) and handover sequence
problem.
Dropping the connection implies the RBS really receives not

enough power. Thus, it always sends power up TPC commands.
In the
measurement
report the
timing from the
RBS is quite
high
- 122 - © Ericsson 2006 LZT 123 8297 R1C

Figure 4-5 UL out of synch
Downlink supervision is carried out by a similar supervision

function located in the UE. The control time constant for the Radio
Connection Supervision algorithm must be set longer in WCDMA
RAN than in the UE (cchWaitCuT > t305), to allow the UE to
have time to detect failure and try to restore radio connectivity.
UL Coverage
Check the value of maxTxPowerUl and sirMax parameters.
maxTxPowerUl parameter should be set based on the most used
mobile class type in the network and sirMax parameter should be
set to its maximum value (17.3 dB). These two parameters have
impact on uplink coverage. Low setting of maxTxPowerUl and
sirMax parameters will limit UE to transmit enough power when it
needed to maintain the radio link connection and might cause lack
of uplink coverage in the network.
Note that bad performing UEs in situation when the coverage gets
poor might rapidly increase SIR target and consequently gives
spikes in uplink RSSI. Setting sirMax on maximum value might
contribute to increase of uplink RSSI for this kind of UEs. sirMax
is a RNC level parameter. A very high setting of this parameter
might cause increase in UL RSSI where bad performing UEs
increase rapidly their SIR target to the maximum allowed SIR
target or where UEs get into very poor radio coverage area and
increase their SIR target to compensate lack of coverage (anti
windup function can not control this type of UE behavior).
Out of uplink coverage may be caused not only by low

CPICH_RSCP but also by high UL_RSSI. In TEMS Investigation
the symptoms of poor UL coverage (i.e. CPICH_RSCP < -
100dBm) is that the DL performance could be either good or bad
(i.e. CPICH_Ec/No = any value). The UE always ramps up its
power to maximum from a very low calculated initial UE Tx
power. Due to this UL poor coverage issue, even the UE ramps up
its power to maximum, the network still cannot receive request
message.
LZT 123 8297 R1C © 2006 Ericsson - 123 -

UTRAN sends
rrcConnectionRelease
message with cause =
normalEvent to the UE to
release the connection.
The UE ramps up its

power to max from a very
low calculated initial UE
Tx power. The network
can’t receive request
messages.
Figure 4-6 UL/DL Imbalance
After a while, the UTRAN normally sends the

rrcConnectionRelease message with cause = normalEvent to the
UE to release the connection. One of the timers that are checking
the RL supervision, the rlFailureT, times out.
The UL and DL coverage imbalance can be solved by reducing the

pilot power. Often by turning the pilot power down there will be a
coverage hole and in the end a new site has to be added. Imbalance
will cause Inner loop power control problems to due UE ray
combining inefficiency and UL easy become Out-Of-Synch.
- 124 - © Ericsson 2006 LZT 123 8297 R1C

By using GPEH event

“INTERNAL_MEASUREMENT_HANDLING_ EVALUATION”
it is possible to get number of times event6a is reported. Event6a
shows maximum transmitted power reported from UE based on the
value of ueTxPowerThresh6a parameter in best serving cell. If
ueTxPowerThresh6a parameter is set to 21 and event6a is reported
in GPEH, then there is a risk for end-users to be located in area
with lack of coverage in the concerned cell.
DL Coverage
The following approach might be used to give some indications
about lack of downlink coverage.
By using GPEH events:
“INTERNAL_MEASUREMENT_HANDLING_ EVALUATION”
it is possible to get number of times event2d is reported. Event2d
shows how bad measured pilot Ec/No is in best serving cell.
“INTERNAL_RADIO_QUALITY_MEASUREMENT” it is
possible to get downlink code power per call basis. This power
reporting is not so frequently but it still gives indications on used
code power on downlink. For cases where GPEH trace shows high
code power usage close to max power available on concerned
RAB, it is a good indication of lack of downlink coverage in
recording cells.
If the conclusion is that there is lack of downlink coverage,

maximum allowed downlink code power on relevant RAB should
be increased for concerned cells
UL RSSI
High uplink RSSI will influence uplink radio quality and increase
risk of getting into out of synch problem.
MinPwrRl is a cell level parameter. This parameter impacts uplink

RSSI and should not be set less than –150. Other setting such as –
120 can be tested to see how much uplink RSSI will be reduced. At
the same time total carrier power should be monitored to see
eventual increase in power consumption when changing
minPwrRl parameter. A trade off can be done to see drop call or
uplink RSSI reduction in relation to eventual carrier power increase
for concerned cells.
LZT 123 8297 R1C © 2006 Ericsson - 125 -

For the worst performing cells a number of RBS counters such as

pmAverageRssi, pmTransmittedCarrierPower and pmOutOfSynch
can be activated before changing minPwrRl parameter to monitor
the performance of worst performing cells.
CONGESTION
A reason for dropped call seen through statistic is congestion. If
any portion of drop caused by congestion it will mean that more
HW is needed for RBS based band pool capacity.
Shows fraction of speech drop due to congestion action
100 ×
( pmNoOfTermSpeechCong )
Shows fraction of video call drop due to congestion action
100 ×
( pmNoOfTermCsCong )
( pmNoNormalRab Re leaseCs64 + pmNoSystemRab Re leaseCs64)
Congestion control is used to resolve overload in the uplink and the

downlink. It uses Power and uplink Received Total Wideband
Power (RTWP) measurements. In case of overload, congestion
control reduces bit rates of delay tolerant existing connections or as
a second option, removes existing connections.
The threshold for detection of downlink congestion is determined

by pwrAdm + pwrAdmOffset + pwrOffset and the Hysteresis
time pwrHyst.
Congestion due to radio overload in uplink is detected when the

uplink Received Total Wideband Power (RWTP) exceeds a certain
configurable threshold for a longer time than the Hysteresis time.
The threshold for detection of uplink congestion is determined by
iFCong + iFOffset and the Hysteresis time is determined by
iFHyst.
Congestion Control considers uplink congestion to be resolved

when the uplink RTWP for a particular cell is below iFCong for a
longer time than the Hysteresis time (or until the next periodic
event-based measurement report for uplink RTWP arrives
indicating that the resource level is below the threshold).
- 126 - © Ericsson 2006 LZT 123 8297 R1C

The parameter pwrHyst should cope with short length peaks in the
downlink transmitted carrier power that in general do not lead to
downlink cell congestion situations, so that unnecessary blocking
of the cell and (even worse) unnecessary congestion resolve actions
are avoided.
Field tests have shown that the default setting is acceptable in most
cases. Nevertheless, pwrHyst can be modified depending on the
duration of the peaks in the downlink transmitted carrier power,
which may be influenced by the UE behavior, radio environment
and power control settings.
The detection level for uplink cell congestion is determined by

iFCong + iFOffset and by the Hysteresis time setting iFHyst.
In general, the expected level of uplink Received Total Wideband

Power (RTWP) is formed by the sum of the following components:
• Thermal noise floor (for example, -107.5 dBm)
• RBS noise figure (typically 2 dB with Ericsson ASC/TMA

or 3 dB without ASC/TMA)
• Noise rise due to load (60% loading in uplink corresponds

to 4 dB)
• Compensation for innacuracies in Radio Network

algorithms (around 2 dB)
Detection of uplink cell congestion could be on a level which is

around 2 dB extra noise rise (parameter iFCong).
By default, the uplink cell congestion detection is disabled by

setting iFCong to -49.9 dBm, iFOffset to 0 and iFHyst to 10 ms.
In many networks, UL interference is not the main limitation and
this setting is acceptable in most cases. If there is a high degree of
uplink interference in a cell, it can be relevant to tune these
parameters to resolve excessive cell breathing.
When setting the parameter iFHyst, short duration UL interference

peaks should be disregarded as, in general, they do not lead to
uplink cell congestion. Unnecessary detection of uplink congestion
leads to unnecessary blocking of the cell. Field tests have shown
that there might be special conditions in a cell or specific UE
behaviors that may require this parameter to be tuned.
Another reason for dropped call seen through statistic is

congestion. If any portion of drop caused by congestion it will
mean that more HW is needed for RBS based band pool capacity.
LZT 123 8297 R1C © 2006 Ericsson - 127 -

This can also be monitored by using for instance RBS counters

such as pmSetupFailuresSF128 in downlink and
pmSetupFailuresSF64 in uplink for speech calls to identify
capacity shortage in downlink or uplink based band pool.
Other counters that should be checked if the drop rate due to high
congestion is listed in the table below:
Counter name Function Description

pmNoReqDeniedAdm RRC request and The counter shows the number of RRC
RAB connection requests and RAB
establishment establishment denied by admission
deny control due to lack of power, code
utilization limit, ASE limit and
compressed mode limit.
pmNoOfTermSpeechCong Speech call The counter shows the number of times
termination speech call terminated due to cell
congestion
pmNoOfTermCsCong Cs call The counter shows the number of times

termination CS call (excluding speech) terminated
due to cell congestion
pmTotalTimeDlCellCong DL Cell It shows amount of time in seconds
Congestion during the measurement period that cell
Duration was congested in DL
pmTotalTimeUlCellCong UL Cell It shows amount of time in seconds
Congestion during the measurement period that cell
Duration was congested in UL
PmSumOfTimesMeasO1D1 Magnitude of It shows number of times congestion
High DL Power control is triggered due to high DL
carrier power
pmNoOfSwDownNgCong Down switch The counter shows number of times
from DCH to packet data connection down switches to
common channel common channel initiated by congestion
due to control. If the down switch is not
congestion allowed to common, then the counter
control shows number of packet data system
release due to congestion
pmNoOfSwDownNgAdm Down switch The counter shows number of times
from DCH to packet data connection down switches
DCH due to from DCH 64/384 to DCH 64/128 and
admission DCH 64/128 to DCH 64/64 initiated by
control admission control due to lack of
downlink power or code limit
- 128 - © Ericsson 2006 LZT 123 8297 R1C

WCDMA RAN HANDOVER

There are four types of handover supported in the WCDMA RAN:
• Soft/Softer Handover
• Inter-Frequency Handover
• Inter Radio Access Technology (Inter-RAT) handover
• HS-DSCH Handover
In reality a handover drop cause includes due to same trigger points

missing neighbor/overshooting. The same triggers are used for both
drop reasons.
Figure 4-7 Entities Involved in Reporting, Evaluation, and Execution of

Handover-Related Functions
LZT 123 8297 R1C © 2006 Ericsson - 129 -

SOFT/SOFTER HANDOVER
The soft/softer handover functionality includes decision on how
many cell carriers to connect in soft/softer handover and
functionality for setting up and releasing connections between the
RBS and the UE. Soft/softer handover is supported for dedicated
channels.
RNC
RBS 1 RBS 2
Figure 4-8 Soft Handover
In soft handover the UE is communicating with two or more

sectors on different RBSs as illustrated in Figure 4-8. In softer
handover the UE is communicating with two or more sectors on the
same RBS.
The counter flow for the cell reselection for Inter-frequency handovers are
shown in the
Figure 4-9
- 130 - © Ericsson 2006 LZT 123 8297 R1C

Intrafrequency Measurement Report Evaluation
1a event including 1 b event 1c event including 1d event including

quality measure quality measure and quality measure and
and cell synch info cell synch info cell synch info
Soft/Softer HO
Removal
Not valid cell Not valid cell

and reported and reported
cell exceeds Yes Yes cell exceeds
best cell + Rel. best cell + Rel.
Conn. Offset Conn. Offset
quantity? quantity?
No No
Soft/Softer HO Soft/Softer HO
Addition Replacement
Speech call only Yes

Not a
(Cell) pmNoSysRelSpeechNeighbr + valid cell?
(Cell) pmNoSysRelSpeechSoHo +
No
Abnormal Call
Release Best cell Update
Figure 4-9 The counter flow for soft/softer handover
A valid cell is a cell that is included in the neighbor set.
Soft/Softer HO replacement procedure is made up of both

Soft/Softer HO addition and removal in sequence. Upon successful
Soft/Softer HO replacement the counters
pmNoTimesRlRepInActSet and pmNoTimesRlDelFrActSet are
incremented for the cell that is removed from the AS and
pmNoTimesRlAddToActSet is stepped in the cell that is added.
LZT 123 8297 R1C © 2006 Ericsson - 131 -

The first thing to check is to see if any fraction of drop call is

related to handover. The following formula shows the fraction of
drops due to HO action when a valid or non-valid cell cannot be
added to active set. This also includes drops due to missing
neighbour.
pmNoSysRelSpeechSoHo
100 ×
( pmNoSystemRabReleaseSpeech + pmNoNormalRabReleaseSpeech)
The following formula shows the failure rate for RL

addition/replacement to active set
pmNoTimesCellFailAddToActSet
100 ×
( pmNoTimesCellFailAddToActSet + pmNoTimesRlAddToActSet )
The UE reselects the new cell, if the cell reselection criteria are
fulfilled during the time interval treSelection, see Figure 4-10.
Quality
qHyst(s) Qmeas(n)
R(n)
qoffset(s) R(s)
Qmeas(s)
treSelection time
Cell reselection
Figure 4-10 The cell reselection evaluation process.
The cell reselection criteria are used for intra-frequency, inter-

frequency and inter-RAT cells.
The decision on when measurements on intra-frequencies should

be performed is made by the parameter sIntraSearch in relation to
Squal.
- 132 - © Ericsson 2006 LZT 123 8297 R1C

If Squal > sIntraSearch the UE does not need to perform

intrafrequency measurements.
If Squal ≤ sIntraSearch the UE performs intrafrequency

measurements.
If the sIntraSearch is not sent to the serving cell, the UE

performs intrafrequency measurements.
The UE shall measure CPICH Ec/No and CPICH RSCP at least

every TMeasureFDD for intra-frequency cells. The UE shall filter Ec/No
and RSCP measurements of each measured intra-frequency cell
using at least 2 measurements, which are taken so that the time
difference between the measurements is at least TMeasureFDD/2.The UE
shall evaluate this intra-frequency cell for the treSelection time and
if it is still better than the serving cell the UE shall reselect that cell.
UE Cell reselection
The RRC connection can fail if the UE does the cell reselection too
often. Possible reason of having always cell reselections is idle
ping-pong, which may be caused due to improper cell reselection
parameter setting and/or pilot pollution.
Areas with many equally strong CPICHs, so-called "pilot pollution

areas", should be avoided. Preferably only one dominant CPICH
should exist. UEs in pilot-polluted areas may experience
unreasonable high Active Set update rates and a higher probability
that the Active Set does not at all times contain the most
appropriate cells. With extensive pilot pollution in the system the
signaling load increases. Pilot pollution gives a high average
number of active radio links, which decreases the traffic capacity
and reduces the probability that the UE gets all neighboring cells
included due to the size limited monitored set.
It is recommended to design the system so that the idle mode cell

selection/reselection borders coincide with the connected mode HO
borders.
It is also recommended that the CPICH power setting initially

balances the UL and DL in the handover area. A balanced system in
this context means that the pathloss is equal at the handover
borders for every cell to be included, or are already included in the
Active Set. The handover areas and where the handover decisions
are taken can be changed by changing CPICH power levels for the
cells.
LZT 123 8297 R1C © 2006 Ericsson - 133 -

The UE sends only one RRC Connection Request and does not
receive the RRC Connection setup from the UTRAN. Immediately
after this, the UE starts to read SIB. RF conditions are good. It is a
UE problem because the UE does not re-transmit the RRC
Connection Request.
Note that the UE may perform cell re-selection during RRC

times which may arrive at different cells, and the fact that
WCDMA RAN does not double count the duplicated RRC
Connection Request message, there is a chance that access success
rate for some cells may show larger than 100% success rate. The
access success rate of better than 100% happens when the attempt
registered at a different cell than where the success registered. The
end result is slightly larger success rate for the cell that completes
the access and a slightly less success rate for the cell that starts the
access.
Normally, treSelection will affect UL RSSI performance because if

the UE camps onto a cell, which is not the best cell, the UE will
transmit slight larger UE TX power during RRC establishment and
it will consequently generate more UL RSSI to the adjacent cells.
To solve the reselection problem, the pilot pollution has to be

reduced and re-plan the cell coverage if needed. The cell
reselection parameters (i.e. qQualMin, qRxLevMin,
maxTxpowerUl, qHyst2, qOffset2sn, treSelection and
sIntraSeach) must be checked if they are set properly.
In TEMS Investigation the cell reselection problem can be found in

many ways. As an example the UE has sent out the
rrcConnectionRequest message for access. During the UE is
waiting for rrcConnectionSetup message It detects another better
(i.e. better CPICH_Ec/No) cell and tries to do a cell re-selection. It
happens when the number of rrcConnectionRequest is still less
than (N300 + 1).
When the UE tries to do cell reselection the number of

rrcConnectionRequest finally reaches to maximum (i.e. n300 + 1).
The setting for treSelection can be too short. Optimization is

needed in order to avoid the idle mode pilot pollution.
If the UE does not send out the rrcConnectionRequest after cell re-
selection., it could be an UE problem, which is not RF related.
The table below is showing the rrcConnectionRequest messages

together with the scrambling code and the corresponding EcNo
value of the example below.
- 134 - © Ericsson 2006 LZT 123 8297 R1C

Time Type of message Content
11:26:49.87 rrcConnectionRequest SC=82 CPICH_Ec/No=-4dB
11:26:51.91 rrcConnectionRequest SC=98 CPICH_Ec/No=-8dB
11:26:51.95 rrcConnectionRequest SC=98 CPICH_Ec/No=-8.5dB
Figure 4-11 Cell re-selection was done between SC98 and SC82
LZT 123 8297 R1C © 2006 Ericsson - 135 -

Handover parametes
The recommended setting of maxActiveSet parameter is 3.
Increasing the value leads to an increase in the average number of
active radio links. The difference will be minor in some areas,
whereas in areas with many strong CPICHs, the average number of
active radio links will increase considerably. In UL more active
radio links on average gives a slightly lower transmitted power. In
DL more active radio links gives a lower transmitted power per
link, but the sum of transmitted power on active links might not be
lower.
The number of Active Set updates per minute is dependent on the

radio environment and there is no direct relation to the setting of
the maxActiveSet parameter
Figure 4-12 shows the parameters involved with a handover.
Figure 4-12 Cell re-selection
TimeToTrigger1- and reportingRange1- parameters might be

reviewed and other settings than the default (current) setting might
be used. Note that these parameters are RNC level parameters and
influence the whole RNC. Hence it might not be possible to change
these parameters due to negative impact on other cells that
handover functions well there.
- 136 - © Ericsson 2006 LZT 123 8297 R1C

The size of the soft and softer handover area can be changed by
the reportingRange1a and reportingRange1b parameters. The
recommended parameter values are 3 dB and 5 dB, respectively.
Increasing reportingRange1a or reportingRange1b results in
larger soft/softer handover area, that is, more UEs will be in
soft/softer handover on average. The average number of active
radio links in the network can grow very large when increasing the
value of reportingRange1a and reportingRange1b.
Figure 4-13 Field tests with settings of the reportingRange parameters
Figure 4-13 shows an example from field measurements. The

actual Active Set size has been logged when driving a 10-minute
route through a pilot-polluted area. The same route was driven four
times, each time with different settings of reportingRange1a and
reportingRange1b, but keeping the delta between them constant.
maxActiveSet was set to 3 during all measurements. As seen in the
figure, the distribution of measurement points having different
Active Set sizes change gradually. Using reportingRange1a = 3
[dB] and reportingRange1b = 5 [dB], the average number of cells
in the Active Set is expected to have the following distribution:
60% for AS=1, 30% for AS=2, and 10% for AS=3. The highest
parameter settings cause the UE to be in soft/softer handover in
basically all spots along the route, a situation that is unfavorable
for system capacity.
LZT 123 8297 R1C © 2006 Ericsson - 137 -

The recommended value for hysteresis1c is 1 dB. A higher value

causes a decreased Active Set update rate, that is, a higher CPICH
signal is required from a new cell to replace the weakest cell in
Active Set. What would make the Active Set update rate decrease
is the reduction of event1c, since event1a and event1b are kept
fairly constant. But a higher value of hysteresis1c may cause too
late an addition of new cells in Active Set.
It is important to remember that the measurements used for

handover event evaluation are made on the downlink CPICH. This
means that using different settings for primaryCpichPower
(power assigned to the CPICH) on neighboring cells will create a
more complicated situation. Unnecessary destructive interference
might be the result in the UL, since the UE will not be power
controlled by the weaker cell until it has been added to the Active
Set.
The UE face problems in areas were many pilots have similar

received Ec/No (especially in low RSCP areas). In order to help the
UE, the time to trigger for events e1a, e1b and e1c can be raised.
However, as stated above, the parameters affect the whole RNC
and should be carefully considered. The increase reduces the
number of handover attempts, especially for the undesired flashing
pilots. It can also lead to a higher drop rate with highways in the
area of fast fading.
timeToTrigger1a indicates the time in ms between event detection

and sending of Measurement Report, for event 1a (New candidate
cell for addition in Active Set)
timeToTrigger1b indicates the time in ms between event detection

and sending of Measurement Report, for event 1b (Removal of an
existing cell in Active Set)
timeToTrigger1c indicates the time in ms between event detection

and sending of Measurement Report, for event 1c (A cell outside
Active Set becomes better than a Cell in Active Set)
The change of the timeToTrigger values have been made in order

to avoid ping-pong effect in cell additions and replacements, and
possible call drops.
For example, if there is a call in “Cell A” and the signal of it’s

neighbor “Cell B” becomes stronger for a moment and at the same
time “Cell A” becomes weaker, “Cell B” would be added and “Cell
A” would be removed from the active set. If “Cell A” becomes
strong immediately after removal this could interfere the
connection and can lead to a drop.
- 138 - © Ericsson 2006 LZT 123 8297 R1C

When timeToTrigger1a is increased, the signal of the neighbor

cell has to be strong for a longer time before making the decision to
add it to the active set. This will avoid adding cells that become
strong only for a very short time. If we set timeToTrigger1b
higher than timeToTrigger1a we delay the removal of a cell from
the Active Set to reduce the probability that fading effect will force
the removal of a cell that could become stronger soon after the
removal. This should reduce the probability for the drops
mentioned above to happen. At the same time timeToTrigger1c is
set equal to timeToTrigger1a to replace weaker cells that are being
delayed for removal.
Even with the increase of the timeToTrigger there is still the

possibility that flashing neighbours (far away sites that cannot be
added to the neighbour list and cannot be tilted) are being reported
for addition by the UE.
Whenever the value for one of these cells is higher than the best
cell in the active set by an amount equal or greater than
ReleaseConnOffset, the connection would be released. The
increase of the parameter allows for a greater tolerance on UL
interference for a short time in the system before releasing the call.
Both the change in timeToTrigger and ReleaseConnOffset reduce
the probability for this kind of release to happen. Note a high value
for ReleaseConnOffset will reduce the capacity in the RBS due to
higher interference and affects the HSDPA performance.
ReportingInterval1a is the interval of event-triggered periodical

reporting in case of “cell addition failure” or “cell replacement
failure”. Indicates the interval in sec. of periodical reporting,
triggered by event 1a
ReportingInterval1c is the interval of event-triggered periodical

reporting in case of “cell addition failure” or “cell replacement
failure”. Indicates the interval in sec. of periodical reporting,
triggered by event 1c.
Both of the timers have been shortened to cope with the increase in
the value for the relative timeToTrigger. Since the measurement
Report is being delayed, it is preferred to send the periodic
repetition of the same measurement Report earlier than with the
default settings in the event there is no answer from the RNC.
Having both a longer timeToTrigger and a long ReportingInterval
could lead to excessive delays in the handover and possible drops.
Too short timeToTrigger values will cause mismatch between

neighbor set in the UE and the neighbor set in the RNC.
LZT 123 8297 R1C © 2006 Ericsson - 139 -

Inconsistent neighbor set

When the UE is setup on a dedicated channel, during the RRC
signaling connection establishment, the SRNC sends a
MEASUREMENT CONTROL message, with "setup" indicator to the UE.
This message is the first MEASUREMENT CONTROL message the UE
receives for this particular connection and it contains the list of
cells and the measurement criteria to be used. The list of cells and
the measurement criteria for support of Soft/Softer handover are
also broadcasted in the system information on the BCCH channel,
in SIB11/SIB12. This allows the UE to start Intra frequency
measurement on configured neighbors Intra frequency for the cell
where the RRC connection was setup before receiving the
MEASUREMENT CONTROL message from the SRNC.
In TEMS Investigation can be seen that the active set lists in the
UTRAN and the UE are inconsistent. As a result, the UE might not
connect to the best cell. Then the UE suffers interference from that
cell and finally the connection drops. Alternatively, the UE tries to
add a better cell into active set; but the UTRAN ignores it because
it thinks the cell has been in the active set already.
UE RNC
Measurement Control
Measurement Report
Active Set Update
Active Set Update Complete
Measurement Report
Measurement Control
Figure 4-14 The Measurement reports and ASU complete can vanish in
case of a bad timeToTrigger setting
- 140 - © Ericsson 2006 LZT 123 8297 R1C

UTRAN requests
the UE to do
replacement
handover, i.e.
UE only has two
UTRAN thinks the
active set cells,
UE has 3 AS cells
SC9 and SC1
Figure 4-15 Inconsistent Lists
The possible reason for this case can be that the uplink
performance is poor. As a result, the sent active set update
complete might not be received from the UTRAN; due to this the
inconsistent active set problem could happen. The solution is to
improve the coverage, e.g. tilting, reducing the pilot power so as to
remove the uplink and downlink imbalance issue, etc. It is also
recommended to check the timeToTrigger parameter settings
LZT 123 8297 R1C © 2006 Ericsson - 141 -

UTRAN requests to
remove SC148.
The UE doesn’t
have SC148. UE
replies with active
UE only has two set update failure.
active set cells,
SC35 and SC116
Figure 4-16 Inconsistent Lists between UE and RNC
In the figure above the UE is requested to remove SC 148, in the

Active Set Update (DL-DCCH) even if the UE only have SC35 and
SC 116 in the Active Set. Therefore, the UE replies UTRAN with
active set update failure.
In another case, the UE sends several measurement reports to

propose SC148. However, the UTRAN does not reply the UE.
- 142 - © Ericsson 2006 LZT 123 8297 R1C

UTRAN requests the

UE to remove SC85,
which is much better
than SC77, while the
UE only has one
UE want to remove
cell in active set
SC77
cells SC77
Figure 4-17 Removal of incorrect cell Cause: Inconsistent Lists
In another case, the UE sends a measurement report to propose to

remove a cell, see Figure 4-17 and Figure 4-18. The UTRAN
replies the UE with active set update but it requests the UE to
remove the best serving cell in the active set.
LZT 123 8297 R1C © 2006 Ericsson - 143 -

UTRAN requests the

UE to remove SC85, UE requests to
which is much better remove SC77
than SC77
Figure 4-18 Removal of incorrect cell Cause: Inconsistent Lists
After the handover, the UE is connected to a cell with poor

CPICH_Ec/No. Then the UE sends many measurement reports to
propose to add the better cell back into active set. However, due to
poor downlink performance (i.e. pilot channel failure Ec/No ~ -
16dB), maybe the UE cannot receive the active set update message.
The area is also having many pilots in the area, which could lead to
the problem described above. The first solution to this problem is
to make sure the pilot pollution is reduced to the minimum in the
network.
- 144 - © Ericsson 2006 LZT 123 8297 R1C

Other parameter checks

For IndividualOffset parameter verify if other setting than default
could improve handover performance for worst performing cells.
Keep in mind IndividualOffset is cell based and not cell relation-
based parameter which means changes to IndividualOffset
parameter can move handover border back or forth in relation to all
neighbors and not one specific neighbor. This will limit the usage
of this parameter.
Check the value of InitShoPowerParam parameter. Settings other

than the default can be tested and verified. A lower setting than
zero can reduce UL RRSI due to the fact the new radio link starts
with lower initial power before it has synchronized.
InitShoPowerParam is used in the initial downlink power setting
during soft handover.
Other things that should be checked are the following
1- Check whether the pilot power of worst performing cells and their
neighbors are set equally. More than 1-2 dB difference between pilot
powers of neighbors might impact call drop.
2- Check the value of releaseConnOffset parameter. A low setting will

give more call drop for cases where a reported detected cell is not in
RNC neighbor cell list.
3- Investigate how accurately the DL and UL attenuation parameters are

set.
4- Neighbor cell offset (serving, neighbor) is used to move the border

between cells. qoffset1 and qoffset2 is the offset between the two
cells that is read in the system information of the serving cell. In P4
there are now two separate measurements running to detect bad
quality, one is using Ec/No, and another is using RSCP. Either of
these might trigger, and when one of them does, then the following IF
or GSM measurement is started using the same measurement quantity
that triggered bad quality. In P3 the parameter qualMeasQuantity
could be set by the operator in order to measure either on the Ec/No
or RSCP
LZT 123 8297 R1C © 2006 Ericsson - 145 -

Soft Handover Overhead per RAB

In order to find to large handover areas in the system and to find out the
average number of RL per user the following formula should be used:
pmSum < RAB > RabEstablish

∑ pmSamples < RAB > RabEstablish
UtranCell counters
SHOoverhead = allcells
pmSumRabEstablish
pmSamplesRabEstablish RNC counters
Figure 4-19 Example of different services and their overlapping areas
Theoretically the cell overlapping area of high bitrate services (e.g.

PS128, PS384) should be reduced compared with low bitrate (Ps64
or speech). It depends on network dimensioning (site to site
distance and load).
HSDPA MOBILITY
There is no Admission Control needed for doing HS-DSCH Cell
Change; Admission Control is however needed when HS-DSCH
RAB is established.
When the UE moves between cells which are HSDPA enabled (that
is, when hsdpaCapability = HSDPA_CAPABLE), the HSDPA
connection is maintained by means of the serving HS-DSCH cell
change functionality or, shortly, HS cell change. HS-DSCH Cell
Change can be seen as a handover to a dedicated place in a queue
to a common channel (HS-DSCH) in a new cell. Note however that
HS-DSCH Cell Change can not be performed over Iur.
- 146 - © Ericsson 2006 LZT 123 8297 R1C

HS-DSCH Cell Change evaluation performs the evaluation of a

valid target cell within the current Active Set, if a change of the
best cell or a removal of the Serving HS-DSCH has been triggered
by the A-DCH Soft Handover evaluation. The Cell Change
evaluation is triggered only if the parameter
hsCellChangeAllowed is set to TRUE.
HS-DSCH does not use soft handover as the dedicated channels

(DCH) do. There is a trade-off between optimizing the radio
quality of HS-DSCH (that is, frequent enough cell changes) and
minimizing the impact on throughput at cell change (that is, as few
cell changes as possible).
HS-DSCH Handover event 1d
When the Ue is using HSDPA, the MEASUREMENT CONTROL orders

an extra event that supports Serving HS-DSCH Cell Change (event
1 d HS) to be reported by the UE.
The reason for having a separate event 1d HS is to be able to get

UE reports triggered by only Active Set cells and to be able to use
different Hysteresis and time to trigger parameters to trigger HS-
DSCH Cell Change. It is also possible to use a different quality
criteria than used for the conventional event 1d. The default quality
criteria used for the event 1d HS is the CPICH RSCP. The
parameter hsQualityEstimate indicates whether it is CPICH
Ec/No or CPICH RSCP that should be used for indicating "best
cell" for HS-DSCH Cell Change.
The event 1d HS does not imply any Active Set Update since the
change of the best cells triggered by the event 1d HS can be related
only to a cell already included in the Active Set.
HS-DSCH - IRAT and IFHO
When the Ue is PS Interactive using HSDPA, the MEASUREMENT

CONTROL includes only neighbor cells of type intra-frequency and
no Compressed Mode is triggered, that means that Inter-Frequency
and Inter-RAT Handover are not possible to be performed. When
the UE leaves PS Interactive using HSDPA, a full neighbor list is
used (as well as Compressed Mode).
HS-DSCH Handover
If the Serving HS-DSCH Cell Change has been disabled by
parameter hsCellChangeAllowed (FALSE) the change of the best
cell in the Active Set will not have any effect. On the other hand,
LZT 123 8297 R1C © 2006 Ericsson - 147 -

the removal of the Serving HS-DSCH cell will trigger an RRC

connection release. The call will then be set up on an HSDPA RAB,
if the new cell is HSDPA enabled, but it will take longer than if cell
change was allowed, leading to a certain throughput degradation.
If the best cell is not an HSDPA capable cell and the current HS-
DSCH serving cell needs to be removed from AS (that is, an
HSDPA coverage border), the connection will be released and
automatically re-established by the packet application on R99.
If the best cell is not an intra-RNC cell (that is, when the UE moves
over Iur) and the current HS-DSCH serving cell needs to be
removed from the AS, an RRC connection release with the cause
"directed signaling connection re-establishment" is triggered. With
this cause value, the call will be immediately setup either on
HSDPA or on R99 in the best cell belonging to the new RNC,
depending on if the best cell is HSDPA capable or not. In order to
avoid releases and setups following a ping-pong pattern, the Iur
borders should be carefully defined.
HS-DSCH cell change for a 384/HS connection can only take place
if the target HS-DSCH cell has UL 384 enabled and 384/HS
resources available. If not, the call will be kept until it is released,
probably due to an event 1b or to loss of synchronization.
The Serving HS-DSCH Cell Change can introduce a delay in the

A-DCH Soft and Soft Handover execution in case of a removal of
the Serving HS-DSCH has been triggered. In that case the Active
Set Update evaluation will trigger a Serving HS-DSCH Cell
Change first and then trigger Active Set Update execution.
- 148 - © Ericsson 2006 LZT 123 8297 R1C

INTER-FREQUENCY HANDOVER
Inter-frequency handover allows an ongoing call to be transferred
from one frequency to another in a case where a UE is moving out
of coverage of the source frequency. The feature covers functions
for both inter-frequency handover for UEs on dedicated channel
and for inter-frequency cell re-selection on common channel and in
Idle Mode.
f2
f2
f1 f1
f2
f1
Figure 4-20 WCDMA Handover (Inter Frequency Handover & Cell Re-
selection)
The IRAT or IFHO functionality can be enabled per cell. When bad
connection quality has been triggered, the type of HO to be
attempted is configurable per cell. The parameter hoType can be
set per cell to GsmPreferred, IfPreferred or to None, and a setting
to None means that no IRAT or IFHO can be done from this cell,
and compressed mode shall not be started. If for some reason the
preferred HO type can not be initiated, then the other HO type
might be attempted instead.
IRAT and IFHO are both triggered by coverage. The purpose with
both functions is to save the connection by making a HO to either
GSM or to another WCDMA frequency, when the coverage on the
original WCDMA frequency deteriorates. Instead of dropping, the
connection should preferably continue on another WCDMA
frequency or in GSM.
In order to detect deteriorating coverage, the connection quality

monitoring uses events 2d and 6a to trigger bad coverage in DL or
UL. When either event is triggered, the UE will start new
measurements for either IF or GSM cells, to try to detect a new
candidate cell to make a HO to. This usually also involves starting
compressed mode.
LZT 123 8297 R1C © 2006 Ericsson - 149 -

The time required for the UE to detect a new cell varies between
approximately 2 to 8 seconds, measured from the detection of bad
coverage to detection of the new HO candidate cell. This time
depends on signal-levels, the UE measurement performance and
the length of the neighbor cell lists. In order to make a reliable HO,
instead of dropping the call, the deteriorating coverage must be
detected early enough, and the neighbor cell lists should not be
longer than necessary. It should be noted that the UE measurement
performance might also vary between different manufacturers.
IFHO Neighbour list

The UE can measure on a maximum of 32 IF cells, and on a
maximum of two other frequencies. When a second carrier f2 is
introduced in clusters as co-located cells, the initial IF (f2 to f1)
neighbour list for the f2 cell could be defined by copying the
corresponding f1 neighbour list from the co-located f1 cell, and
adding the co-located f1 cell.
However, if the coverage for the IF cell deteriorates quickly and it

is important that the IFHO can be performed fast, then the IF
neighbor lists should be as short as possible. The time it takes for a
UE to find a candidate IF cell generally increases with longer
neighbor cell lists, and keeping the list short should generally lead
to less time in compressed mode and better retainability
performance.
When a second carrier is deployed as a hotspot cell, two-way

neighbor cell relationships should be defined only between the
under-laying f1 cell and the over-laying f2 cell. One-way neighbor
cell relationships are defined from the f2 cell to all the surrounding
f1 cells. The main benefits with this setup are the elimination of
IFHO from the surrounding f1 cell to the f2 cell, the decreased risk
of CPM starts in the f1 layer, and the shorter neighbor lists. With
one-way definitions, all surrounding f1 cells become blind to the f2
cell.
It should also be noted that the P-CPICH power settings should

initially be set to the same values for the f2 cells as for the co-
located f1 cells. The f2 to f2 neighbor lists for the second carrier
cells could also initially be determined by using the f1 neighbor
lists for the corresponding co-located cells
- 150 - © Ericsson 2006 LZT 123 8297 R1C

IFHO Parameter check

The first step is to locate the WCDMA cells which are coverage
limited and decide if either GSM HO or IFHO should be enabled in
these cells in order to reduce the dropped calls caused by the
coverage limitation. For these cells the GSM and/or the IF
neighbor cell lists should be defined, keeping the lists short if
possible and without defining unnecessary neighbor relations.
The next step is to set parameters for the IRAT and IFHO
functions. The event 2d threshold can be adjusted per cell, and can
be used if an early detection of the coverage problem is necessary
in some cells or locations in order to make a successful HO. For
example, a cell which has locations where the coverage falls
quickly for many users, leading to dropped calls, might need a
higher threshold setting for the 2d event. The thresholds 2f, 2b
(used frequency) and 3a are relative thresholds to the event 2d and
will also be per cell level. The relative parameter values are set on
RNC level.
The purpose with this procedure is to decrease the amount of

coverage generated dropped calls, so that most of these calls
instead can continue in GSM or on another WCDMA frequency,
but without causing too many false triggers or too many users in
compressed mode. Frequent starts and stop of compressed mode
always come with a cost in terms of power and HW resources. The
dropped calls should be monitored during these procedures, and the
total number of drops per cell should be calculated before and after
the GSM or IFHO functionality is enabled
IFHO Handover Speech

Drop due to IFHO failure for speech: Outgoing IFHO failure when
UE failed to return to present active set.
pmFailNonBlindInterFreqHoFailRevertCsSpeech12
100 ×
pmAttNonBlindInterFreqHoCsSpeech12
The following formula might give slightly lower result:
100 ×
⎛ pmSuccNonBlindInterFreqHoCsSpeech12 + pmFailNonBlindInterFreqHoRevertCsSpeech12 + ⎞
⎜⎜ ⎟⎟
⎝ pmFailNonBlindInterFreqHoFailRevertCsSpeech12 ⎠
Drop due to IFHO failure for CS except speech: Outgoing IFHO

failure when UE failed to return to present active set.
LZT 123 8297 R1C © 2006 Ericsson - 151 -

pmFailNonBlindInterFreqHoFailRevertCsConversational
100 ×
pmAttNonBlindInterFreqHoCsConversational
Drop due to IFHO failure for PS less or equal to 64 kbps: Outgoing

IFHO failure when UE failed to return to present active set.
pmFailNonBlindInterFreqHoFailRevertPsInteractiveLess64
100 ×
pmAttNonBlindInterFreqHoPsInteractiveLess64
Drop due to IFHO failure for PS greater than 64 kbps: Outgoing

IFHO failure when UE failed to return to the present active set.
pmFailNonBlindInterFreqHoFailRevertPsInteractiveGreater64
100 ×
pmAttNonBlindInterFreqHoPsInteractiveGreater64
Drop due to IFHO failure for PS streaming and others: Outgoing

IFHO failure when UE failed to return to the present active set.
pmFailNonBlindInterFreqHoFailRevertStreamingOther
100 ×
pmAttNonBlindInterFreqHoStreamingOther
INTER-RAT HANDOVER
The significant difference between handover and Inter-RAT Cell
Change or Cell Reselection is that for handover dedicated
resources must first be allocated in the target cell and then the UE
is ordered to go to the allocated resources. For Inter-RAT Cell
Change or Cell Reselection the UE is ordered (Inter-RAT Cell
Change), or it takes the initiative (Cell Reselection) to go to the
target cell and after arrival to the target cell use common channels,
to inform the system of the Inter-RAT Cell Change and request for
dedicated resources, if needed.
The WCDMA RAN also supports handover to/from GSM for

coverage reasons. In later releases, it will be possible to perform
this Inter Radio Access Technology (Inter-RAT) handover for
capacity or priority reasons, as illustrated in Figure 4-21.
- 152 - © Ericsson 2006 LZT 123 8297 R1C

Handover from GSM to UMTS because of high load or system priority
Handover from UMTS to GSM because of bad coverage
UMTS GSM Network

GSM
Multi RAT terminal
Figure 4-21 WCDMA Handover (Inter RAT Handover)
The IRAT handover and cell reselection functionality enables the

system to move the connection from the UMTS to the GSM system
and vice versa. The most common scenario with the introduction of
UMTS systems would be when moving out of the UMTS coverage
and then transfer the call to GSM system before/without dropping
the connection since GSM initially will have a larger coverage
footprint. IRAT functionality also enables the operator in a “basic”
way to steer traffic between the GSM and the UMTS systems.
The default system behavior is that GSM HO is not supported for

the higher interactive DL rates 384 and 128. These rates will
normally be downswitched to 64 when the coverage deteriorates,
and when the connection has been switched to 64 the GSM HO
functionality will work normally. If an event 2d was triggered
earlier, the GSM measurements will start as soon as the switch to
64 occurs.
The UE can measure on a maximum of 32 GSM cells. There are

reasons to be restrictive when defining GSM neighbors, and it is
recommended to not define GSM neighbors if it is not needed. The
time it takes for a UE to find a candidate GSM cell generally
increases with longer neighbor cell lists, and keeping the list short
should generally lead to less time in compressed mode and better
retainability performance. If the WCDMA coverage falls quickly,
the probability of quickly finding a suitable GSM candidate cell
will increase if there are fewer GSM cells to measure on.
In this section, the equations for Inter Radio Access Technology

(GSM) Handover success rate per service are covered.
LZT 123 8297 R1C © 2006 Ericsson - 153 -

Therefore, it is of importance to set the IRAT parameters for the

GSM and the UMTS systems so that the resulting functionality
meets the intended strategy of the operator for its 2G/3G
subscribers and services.
IRAT Handover Speech

The following metric measures hard handover success rate between
UtranCell and target GSM cell for speech calls. The formula is
considering the GsmRelation.
pmNoSuccessOutIratHoSpeech
100 ×
pmNoAttOutIratHoSpeech
IRAT Handover CS57

UtranCell and target GSM cell for CS streaming calls. The formula
is considering the GsmRelation.
pmNoSuccessOutIratHoCs57
100 ×
pmNoAttOutIratHoCs57
IRAT Handover Multi-RAB

UtranCell and target GSM cell for Multi-RAB calls. The formula is
pmNoSuccessOutIratHoMulti
100 ×
pmNoAttOutIratHoMulti
IRAT Handover Packet Data

The WCDMA to GSM cell change for PS interactive services
normally experience quite long outage times before the session can
be reestablished on the GSM side. There are no normal tuning
activities that can be performed to shorten this time.
The outage time can be divided into 2 parts. The first radio-outage
part depends largely on the UE and consists of the time it takes for
the UE to reselect to the GSM cell and then perform LA and RA
updates. This typically takes 8-10 seconds. The second part is the
Application outage that depends on the application, the protocol
and on the TCP-IP procedures, before the application is running
normally again. For some applications, like FTP download, this
time could in the worst case be around 10 seconds
- 154 - © Ericsson 2006 LZT 123 8297 R1C

The following metric measures cell change failure rate between

UtranCell and target GSM cell for PS calls when the UE
successfully returns to UtranCell. The formula is considering the
GsmRelation.
pmNoOutIratCcReturnOldCh
100 ×
pmNoOutIratCcAtt
MISSING NEIGHBOUR RELATIONS

The amount of dropped call due to missing neighbor is depended
on the value of releaseConnOffset parameter. If this parameter is
set high, the number of drop due to missing neighbor will be low
but the trade of is that the interference level will be increased due
to overshooting.
One of the reasons for dropped call that can be seen through
statistics is drop due to missing neighbor relation. Normally a
missing neighbor is reported to RNC as a detected cell. If the
detected cells are not in RNC neighbor list for a concerned cell and
the reported Ec/No value is greater than the serving cell plus the
value of releaseConnOffset parameter, the call will be released
(drop from end-user point of view) to reduce the interference level
of this area.
Shows fraction of speech drop due to HO action when a valid or

non-valid cell cannot be added to active set. This includes also drop
due to missing neighbor.
100 ×
Shows fraction of speech drop due to missing neighbor reason

when a non-valid cell cannot be added to active set.
pmNoSysRelSpeechNeighbr
100 ×
In order to find missing neighbor relation the GPEH recording

function could be used. The event that is interesting for this case
and provides relevant information is
“INTERNAL_SOHO_DS_MISSING_NEIGHBOUR”. By activation of this
event and collection of enough data (2-3 days), a number of
potential missing cells will be identified. This list needs to be
review to exclude overshooting cells that needs to erased.
LZT 123 8297 R1C © 2006 Ericsson - 155 -

For cells with full neighbor list (32 entries) it is necessary to

monitor the current handover statistics in order to know the usage
of existing neighbor list. Note that Ericsson does not recommend to
put in more than 20 entries in the neighbor list.
New relations found through missing relation analysis can replace

neighbor relations with low usage. In order to do the ranking of cell
usage it is possible to use
“INTERNAL_SOFT_HANDOVER_EXECUTION” event in
GPEH for 2-3 days with efficient load to get enough data.
It is also possible to use cell relation based counters such as

pmRlAddSuccessBestCellSpeech and
pmRlAddAttemptsBestCellSpeech from performance statistic
counters. Cell relation based counters should be activated for
concerned cells and their neighbors to provide information
regarding how often an existing neighbor relation is used.
OTHER REASONS
Drop due to other reasons, could be anything else such as UE
problem, active set update failure (timer expiration), network
malfunctioning, congestion on transport side during handover,
RNC queues (Buffer_1A_1C or Buffer_1B) are full, etc.. This
portion of dropped calls is calculated based on subtraction of
known reasons for drop from the total dropped call.
Dropped calls due to other reasons than uplink out of sync and
missing neighbor can be calculated through using counters. In
reality, there is no known reason behind this part of drop when
looking at counters.
Shows fraction of speech drop due to other reasons than HO action,

UL out of sync and congestion.
100 ×
( pmNoSystemRab Re leaseSpeech − pmNoSys Re lSpeechSoHo − pmNoSys Re lSpeechULSynch − pmNoOfTermSpeechCong )
- 156 - © Ericsson 2006 LZT 123 8297 R1C

Transport Network
The dropped calls due to transport network is not a radio problem,
however it is important to find where that faults are so it could be
solved.
Shows percentage of rejected incoming/outgoing Aal2 connection

establishment requests on transport network.
100 ×
(Y + X )
( pmSuccInConns Re mote + pmSuccOutConns Re mote + Y + X )
Where
X = pmUnSuccOutConnsLocal + pmUnSuccOutConnsRemote
Y = pmUnSuccInConnsLocal + pmUnSuccInConnsRemote
WNCS (WCDMA NEIGHBOURING CELL SUPPORT)

WNCS is a tool included in the RNO product family.
The purpose of WNCS is to evaluate the neighboring cell relations

and to provide an easy and efficient way to keep the neighbor
relations in the WCDMA Radio Network optimized. This means
that support is provided to find missing neighboring cells that
should to be defined as neighbors, and to find currently defined
neighbor relations that can be removed.
WNCS is mainly used for:
9 Trouble shooting: Missing neighboring cell relations can be

detected.
9 Supervision: The neighboring cell relations can be

evaluated continuously.
9 Planning areas with new cells: WNCS can be used to

evaluate new cell relations when new cells are added to the
network.
Only neighbor relations between WCDMA cells using the same

frequency (ARFCN), that is the neighbor relations used for
soft/softer handovers, can be optimized with WNCS.
LZT 123 8297 R1C © 2006 Ericsson - 157 -

It is recommended to include maximum 300 cells belonging to 5

RNCs in one WNCS recording.
The User Equipment (UE) continuously monitors the radio

environment. Not only defined neighbor cells are measured, but
also cells that are undefined neighbors can be detected with the
background scanning process. The UE is configured to evaluate
and send measurement reports to the system only when certain
events occur, such as when the measurement result for a cell fulfills
certain criteria.
This concept is called event-triggered reporting. Events are

collected by the General Performance Event Handling (GPEH)
function in the RNC and sent on to Performance Management
Support (PMS) in the OSS, where they are included in a Result
Output Period (ROP) file. One file is created for each RNC and
Result Output Period.
WNCS schedules recordings of GPEH events via PMS, collects the

files, and processes the events related to the measurements of
surrounding WCDMA cells. It also collects and presents counters
that measure the extent of defined WCDMA neighbor relations
usage. The results are presented in various reports.
- 158 - © Ericsson 2006 LZT 123 8297 R1C


Below in the following sections there are several different problems
found with TEMS Investigation in a WCDMA network.
LOSS OF ASU COMPLETE OR MEASUREMENT REPORTS

UE has sent active set update complete message to the UTRAN.
However, the UTRAN does not reply the UE with measurement
control to update the new monitored set cells list.
The uplink RF
performance is very
bad. UTRAN cannot
receive the
measurement
Figure 4-22 Loss of ASU complete. Possible Cause: DL/UL Imbalance
LZT 123 8297 R1C © 2006 Ericsson - 159 -

The UE sends many measurement reports to request adding a cell;

however, the UTRAN does not reply the measurement report by sending
active set update message.
The uplink RF
performance is very
bad. UTRAN cannot
receive the Figure 4-23 Loss of measurement reports.
measurement
If the uplink RF performance is very bad, e.g., CPICH_RSCP is
low and UE_Tx_PWR is high. Thus, it can be assumed the
UTRAN cannot receive the active set update complete message. If
the serving CPICH_Ec/No is still good, the problem then is the UL
/ DL coverage imbalance. The problem can be solved by reducing
the pilot power and by adding new site.
If the serving CPICH_Ec/No is bad as well, it is poor coverage

issue. The unique solution is to add new site.
If the serving CPICH_Ec/No is good as well as the CPICH_Ec it

can be the timeToTrigger parameter settings. The unique solution is
to change the timers to a different value.
- 160 - © Ericsson 2006 LZT 123 8297 R1C

INTER-RNC HANDOVER FAILURE

In TEMS Investigation, inter-RNC handovers can be monitored as
well as all types of handovers. However, in this case below, the UE
sends many measurement reports to request adding a cell, which is
in the other RNC, into active set. The UTRAN does not reply the
measurement report.
After connection drop, the UE can be connected to that cell. If the

UE then sends measurement reports to request adding the previous
cell, which is located in the first RNC. The UTRAN does not reply
the UE.
Figure 4-24 RC Handover failure. Possible Cause: Network configuration
LZT 123 8297 R1C © 2006 Ericsson - 161 -

The RF conditions for the new cell, SC75 is good however the AS
SC56 is getting worse. Due to the many pilots in the area they
might affect the inter-RNC handover. In this case the handover
failed in both directions due to the fact that the UTRAN did not
reply to the UE requests. Regarding the inter-RNC handover, the
Iur link between the RNC can also be wrongly configured or that
the neighbors are not correctly defined in the different RNC.
UE RELATED PROBLEM
The UE sends a MR to remove the best SC from the AS. After this
SC is removed, the other ones in the AS become very bad in terms
of Ec/No and the UE has no time to add it back to the AS.
The UE sends a MR to
remove SC204,which
is the best server SC.
Figure 4-25 Inconsistent Lists. Possible Cause: DL/UL Imbalance
- 162 - © Ericsson 2006 LZT 123 8297 R1C

In the AS, there are two SC’s, RF conditions become very good for
one of them and bad for the other, and UE Tx power is low. It is
assumed that the good radio link is out of synchronization because
the DL BLER is increasing while the RF conditions become better
for one SC. Finally the call drops because high DL BLER.
DL BLER increases while

SC183 is gets better and
SC308 is gets worse
Figure 4-26 TEMS Investigation DL BLER Increases and the call is

dropped.
LZT 123 8297 R1C © 2006 Ericsson - 163 -

Intentionally Blank
- 164 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
5 Service Integrity
Objectives

in order to improve the BLER and throughput

to integrity
LZT 123 8297 R1C © 2006 Ericsson - 165 -

Intentionally Blank
- 166 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
INTEGRITY ........................................................................................169
INTEGRITY WORKFLOW..................................................................169
WORST CELLS .................................................................................171

FORMULAS .................................................................................................. 171
WCDMA POWER CONTROL ............................................................172

CRC – CYCLIC-REDUNDANCY CHECK ..................................................... 173
DL INNER LOOP .......................................................................................... 174
UL INNER LOOP .......................................................................................... 175
UL OUTER LOOP ......................................................................................... 176
POWER CONTROL ON HSDPA CHANNELS.............................................. 179
BLER PARAMETERS ........................................................................180
PACKET THROUGHPUT...................................................................181
HSDPA ...............................................................................................194
HW AND SW PREPARATIONS.................................................................... 194
OPTIMIZING THE HSDPA............................................................................ 195

HIGH DL BLER - NO RAB SETUP ............................................................... 200
HIGH DL BLER – DROPPED CALL ............................................................. 201
LZT 123 8297 R1C © 2006 Ericsson - 167 -

Intentionally Blank
- 168 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
INTEGRITY
This module is done after the retainability module. Integrity is
defined as the ability of user to retain its requested service at a
certain quality once connected for the desired duration.
The performance is measured by the BLER (BLock Error Rate)

and by throughput. The purpose of Integrity check-up is to track
down excessive BLER problem and analyze them in a WCDMA
network.
INTEGRITY WORKFLOW
Below the Figure 3-2 is showing the Integrity workflow.
At performance monitoring the worst cells regarding integrity is

sorted out.
At performance analysis the worst cells are analyzed to find the

BLER problems and then the throughput of the cells are checked


after the implementation is done. This is to ensure that there has

Implementation
BLER counters and BLER, power, SIR Test the settings Check statistics
Down Switching parameters If not OK, roll back
counters
Throughput
pmFaultyTransportBlocksBcUl
pmTransportBlocksBcUl
pmNoOfSwDownNgCong
PmNoOfSwDownNgAdm
PmDl Traffic volume counters
Figure 5-1 A The Integrity workflow
LZT 123 8297 R1C © 2006 Ericsson - 169 -


implemented changes is done.
Below is the proposed scenario how Integrity service can be

performed.
1. Through performance statistics data (RNC counters) identify

RAB’s that are not performing in line with targets
(blerQualityTargetUl). That means - uplink BLER derived from
counters is higher than UL BLER Target value set by parameter.
Usually this should not be the case.
2. Review radio parameter settings (points below). Perform a

consistency check of the parameter settings and verify settings
against Ericsson default/recommended values.
NOTE: WCDMA technology in Power Control has mechanisms

to keep BLER lower then blerQualityTargetUl/Dl (UeRc
parameter). If this is not the case it can be that parameters related
to RAB’s and Power Control have wrong values. Most of the
mature networks have these values checked several times in the
Consistency check procedures.
- Check RAB parameters on the RNC level

(blerQualityTargetUl and blerQualityTargetDl) (also in
Retainability module)
- Check the values of the Power Mapping parameters,

Maximum Downlink Transmitted Code Power.
- Check UL Outer Power loop parameters (SIRMax, ul SIR

Step). (also in Retainability module)
3. Check if it makes sense to investigate different

blerQualityTarget settings (for example, what is happening
changing target from 1 to 2% for voice)
The performance can be verified after modifying BLER target by
- Integrity counters, on RNC level after combining per RAB
- Counters related to congestion, admission control and number

of simultaneous users
- RBS counters related to carrier, code power and RSSI
- 170 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
Generally, there will be 2 types of finding from these analyses.

Either the findings are related to Cell/RBS/RNC parameter
settings, or they are related to hardware configuration such as
antenna tilt or antenna height etc.
WORST CELLS
Observability of Integrity is very limited, only UL BLER per RAB
on RNC level can be monitored. The system is designed to fight
against BLER deviations from the set BLER targets. The ability to
influence Integrity is somehow very small.
There are two counters on cell level before combining

pmFaultyTransportBlocksBcUl and pmTransportBlocksBcUl.
These counters are measured also during the time when cell is not
the best in the active set. These counters do also contain BLER
information for all RAB’s.
The method for finding worst performing cells is based on top to

down analysis. Initially worst 10-15 performing cells can be
identified based on the Uplink Block Error rate before combining.
pmFaultyTransportBlocksBcUL
100 ×
FORMULAS
Below is described formula that is based on counters after macro
diversity combining in uplink.
The Formula below shows Block Error rate after uplink

combining at RNC level. That means blocks in RNC coming from
different legs in SHO are compared, each radio connection.
pmFaultyTransportBlocksAcUl[UeRc]
100 ×
pmTransportBlocksAcUl[UeRc]
UeRc stands for different RAB’s (UeRc=2, Speech; UeRc=3,

Video Call; UeRc=4, Packet Common Channel; UeRc=5, PS
64/64; UeRc=6, PS64/128, UeRc=7, PS 64/384; UeRc=10
multirab Speech+PS 0 or PS 64/64).
LZT 123 8297 R1C © 2006 Ericsson - 171 -

WCDMA POWER CONTROL

Power Control is essential for the smooth operation of a WCDMA
system, because all users share the same radio frequency band
through the use of different codes.
There are three types of power control in WCDMA as illustrated in

Figure 3-8.
BLE R:Blo ck E rror Ra te

SIR: S ignal to Inte rfer ence Ratio Uplink
Uplink SIR target outer loop
TPC: Transmit Po wer Control
BLER-Measured
Inner loop
SIR-Target
Downlink TPC modified
Uplink
TPC Uplink SIR-Target
Downlink Uplink SIR error
Downlink SIR target
outer loop
RNC
BLER-Measured Open loop
SIR-Target Starting power
modified
Figure 5-2 WCDMA Power Control
Open Loop Power Control is performed in the uplink and downlink

to calculate a minimum starting power for setting up a connection.
In doing so the interference and power required is minimized.
Inner loop Power Control minimizes the power and interference of

ongoing connections by maintaining a minimum Signal to
Interference Ratio (SIR).
The Outer Loop Power Control algorithm is used to maintain the

required Block Error Rate (BLER) for a service by modifying the
SIR target of Inner Loop Power Control.
- 172 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
CRC – CYCLIC-REDUNDANCY CHECK

In the WCDMA Transmitter, the voice channel is passed through a
vocoder, which produces a digital representation of the input
analogue signal. After error protection this is fed into a data
multiplexer where it is multiplexed with synchronization bits and
control/signaling data and user data channels. This combined signal
is passed to the transmit gating device. Finally, filtering and RF
modulation is performed and the signal is passed to an antenna
system.
The Error detection and error protection of the data channels are
performed using Cyclic Redundancy Check (CRC) coding,
Forward Error Correction (FEC) and interleaving.
In all radio systems the air interface will add noise to the signal,
which will produce a distortion in the received signal. This noise
will result in bit errors, that are what left the transmitter as logic 1
could be interpreted as a logic 0 if the level of noise lowers the
amplitude below the threshold for logic 0. The same could be the
case for a transmitted logic 0 being interpreted as logic 1.
Cyclic Redundancy Check (CRC) is used to detect if there are any

uncorrected errors left after error correction.
Transmitte
r
Original Data CRC Original Data Checksum 12 bits
244 bits Generator 1001011010.. 110010110011
RF
Transmission Path
Receiver
Received Data Received Checksum If Checksums do not
1001010010.. 110010110011 match,
there is an error
CRC Re-Generated Checksum

Generator 110010110001
Figure 5-3 CRC Generator
Blocks of data are passed through a CRC generator Figure 5-3,

which will perform a mathematical division on the data producing a
remainder or checksum. This is added to the block of data and
transmitted.
LZT 123 8297 R1C © 2006 Ericsson - 173 -

The same division is performed on the data block in the receiver. If

a different checksum is produced the receiver will know that there
is an error in the block of data (alternatively there is an error in the
received checksum). This knowledge is used to calculate Block
Error Ratio (BLER) used in the outer loop power control.
The longer the checksum, the greater is the accuracy of the process.
In the example the checksum is twelve bits long. Twelve bits of
12
binary information represents 4096 (2 ) different combinations. It
could be imagined that various combinations of errors on the data
and the checksum would produce the same checksum. The longer
the checksum the less likely it is for this to happen.
DL INNER LOOP
During a period of soft handover with downlink Inner Loop Power
Control, starting the radio link at the correct power level
coordinates the power of the radio links. Each RBS in the active set
listen to the same sequence of TPC commands from the UE.
Received TPC commands, however, may be affected by different
errors, due to the different radio propagation conditions
experienced by each of the soft handover links. Consequently, the
transmitted power at different RBSs will start to drift, eventually
leading to uncoordinated links. Power Balancing prevents this
power drift problem by using a modified type of power control
during soft handover.
The UE maintains the QoS by sending Transmit Power Control

(TPC) commands in every slot (i.e., 1500 times per second),
requesting a power adjustment.
The RNC calculates a reference power based on the transmitted

code power measured in each radio link, and periodically sends it
to the RBSs. The RLs belonging to an out-of-sync RLS are
excluded from the calculation of reference power. If all RLSs are
out of sync, the last available reference power is used. The RLs
belonging to RBSs that do not support transmitted code power
measurements are also excluded from the calculation of reference
power. Each RBS involved in soft handover makes synchronized
adjustments of the downlink power of the radio links according to
the received reference powers. These adjustments are
superimposed on the power changes due to downlink Inner Loop
Power Control, and performed regardless of RLS synchronization
status.
- 174 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
UL INNER LOOP
As soon as the RBS starts transmitting the downlink DPCCH, it
begins to regulate the uplink power of the radio link by sending
TPC commands to the UE in each slot. The UE responds by slowly
increasing power until uplink synchronization is reached.
Immediately, the RBS starts estimating the SIR on the DPCCH.
The TPC commands are derived according to the following
scheme:
If estimated SIR >= target SIR, the RBS sends a down command.
If estimated SIR < target SIR, the RBS sends an up command.
Figure 5-4 Uplink Inner Loop Power Control
The UE responds to the command by changing the DPCCH power

by 1 dB in the direction indicated by the command. The ratio
between DPCCH and DPDCH power is determined by gain factors.
In case of soft handover, if TPC commands from all RBSs in the

active set are up commands, UE increases the DPCCH power by 1
dB. Otherwise, if at least one TPC command is a down command,
it decreases the DPCCH power by 1 dB.
LZT 123 8297 R1C © 2006 Ericsson - 175 -

UL OUTER LOOP
There are two alternative algorithms for uplink Outer Loop Power
Control implemented. The parameter ulOuterLoopRegulator
determines whether to use the Constant Step Regulator algorithm
(ulOuterLoopRegulator=CONSTANT STEP) or the Jump
Regulator algorithm (ulOuterLoopRegulator=JUMP). The
interaction between uplink Inner Loop Power Control and uplink
Outer Loop Power Control is shown in Figure 5-5.
Figure 5-5 Uplink Outer Loop Power Control
The two configurable parameters sirMax and sirMin set the limits
of the uplink SIR target, expressed in dB.
- 176 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
The start point of SIR target regulation is determined by the Initial

Uplink SIR Target (ulInitSirTargetLow or ulInitSirTargetHigh)
depending on the Spreading Factor of DPDCH. The Initial Uplink
SIR Target is a configurable parameter defined according to the
minimum Spreading Factor (SF) of the uplink Dedicated Physical
Data Channel (DPDCH): ulInitSirTargetSrb for stand-alone SRB,
ulInitSirTargetLow for RABs having minimum DPDCH SF equal
to or higher than 32 and ulInitSirTargetHigh for RABs having
minimum DPDCH SF equal to 16 or 8.
ulInitSirTargetExtraHigh for RABs having minimum DPDCH
SF equal to or lower than 4, i.e. dedicated (SRB) to dedicated
(384/HS-DSCH) RAB establishment. Note
ulInitSirTargetExtraHigh is not used for uplink initial power
setting but used for uplink outer loop power control
To avoid windup effects on the uplink SIR target, the anti-windup

mechanism prevents changes of the uplink SIR target in one
direction if the uplink Inner Loop Power Control cannot make the
uplink SIR reach the target in the same direction. E.g., if the uplink
SIR is lower than the target by 5 dB as the UE transmits at
maximum power, no further increases of the uplink SIR target are
allowed until the Inner Loop Power Control is back on track.
Constant Step regulator

Whenever the Cyclic Redundancy Check (CRC) indicates that the
reception of a transport block is erroneous, the uplink SIR target is
increased by configurable increment ulSirStep, expressed in dB.
Whenever NBR_OF_CRC_OK consecutive transport blocks are
correctly received, the uplink SIR target is decreased by an equal
step. The number of consecutive correct transport blocks needed to
trigger a decrease of the uplink SIR target depends on the BLER
target.
The SIR target value in the Constant Step Regulator algorithm is

controlled as shown
LZT 123 8297 R1C © 2006 Ericsson - 177 -

Figure 5-6 SIR Target Behaviour According to the Constant Step

Regulator algorithm
Jump regulator
The Jump Regulator increases the uplink SIR target by a
configurable increment ulSirStep, expressed in dB, whenever a
transport block is erroneously received. When a block is correctly
received, the uplink SIR target is decreased by a fraction of
ulSirStep. This fraction, denoted UP_DOWN_STEP_RATIO,
depends on the BLER target.
If several transport blocks are received in one Transmission Time

Interval (TTI), the change in the uplink SIR target will be based on
the accumulated change individually caused by each of the
transport blocks.
To reduce the variations of the uplink SIR target, the change of

uplink SIR target is always scaled by the number of transport
blocks received in the corresponding TTI, as described by the
following general equation:
⎡ X Y⎤
SIRt arg et:new = SIRt arg et + ulSirStep − ⎢ + ⎥
⎣ (Z ∗ UP _ DOWN _ STEP _ RATIO ) Z ⎦
Where:
ulSirStep is the configurable parameter that defines the size of SIR target increment.
Z is the total number of received transport blocks.
X is the number of transport blocks that have a CRC=OK.
Y is the number of transport blocks that have a CRC=NG.
- 178 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
SIR target behaviour according to the Jump Regulator algorithm is

shown in the figure below.
Figure 5-7 SIR Target Behaviour According to the Jump Regulator

algorithm
POWER CONTROL ON HSDPA CHANNELS

The principles and functionality of the power control for the
HSDPA associated dedicated channels are the same as for the
DPCH power control in previous releases. However, there is a new
uplink dedicated control channel, HS-DPCCH, which is used for
feedback information to the hybrid ARQ processes and for channel
quality information
The power of the HS-DPCCH is given as an offset relative to the

DPCCH . The offset has different values depending on if the UE is
in soft handover or not.
Updates of the parameters for CQI and ACK/NACK transmissions

can be done by Physical channel reconfiguration. The update can
be triggered in two different ways:
• Triggered by RNC when the number of Radio Link Sets are

changed
• Triggered by a request from RBS
In a first establishment, the radio bearer setup procedure, the

parameters related to CQI are signaled in "Measurement Feedback
info" which is a part of the "downlink HS-PDCCH information"
message and the parameters related to ACK/NACK are included in
the Uplink DPCH power control info fields. CQI, ACK, NACK are
the power offset factors related to power control. A closed-loop-
like update of the CQI/ACK/NACK Repetition Factors can further
improve the reception quality on the HS-DPCCH.
LZT 123 8297 R1C © 2006 Ericsson - 179 -

The parameters deltaAck1, deltaAck2, deltaNack1, deltaNack2,

deltaCqi1, deltaCqi2, initialCqiRepetitionFactor,
initialAcknackRepetitionFactor, and cqiFeedbackCycle are all
configurable and set per cell. The parameter setting in use is
decided by the HS-DSCH serving cell
The RBS can initiate updates of the CQI Repetition Factor, CQI
Feedback Cycle and ACK/NACK Repetition Factors using the
Radio Link Parameter update procedure.
The parameter updates are initiated by the CQI reception

performance. If the CQI report is regarded as non-reliable this is
logged as a CQI error event in the RBS. Note that if the CQI
Repetition Factor is set to a value higher than one (1) only the soft-
combined result of the CQI report is counted.
BLER PARAMETERS
blerQualityTargetUl - This parameter decides the quality target of
the different RABs in uplink.
blerQualityTargetDl - This parameter decides the quality target of

the different RABs in downlink.
The blerQualityTargetUl/Dl is calculated according to:
blerQualityTargetDl/Ul = 10Log10(BLER quality target)
for example when BLER quality target is 1% (0.01)
blerQualityTargetDl/Ul = 10Log10(0,01)= −20
The purpose of configurable BLER targets is to enable the operator

to trade quality of the connections versus resource usage.
Note: These parameters can be set per TrCh for every radio
connection. Recommended values for these parameters can be
found below.
Default values for parameters blerQualityTarget UL/DL set on TrCH .

RAB Type TrCH Default Value
SRB SRB -20 ( 1% BLER)
Speech 12.2 Speech -20 (1% BLER)
SRB -20 (1% BLER)
Conversational CS data 64 CS64 -25 (0.3% BLER)
SRB -20 (1% BLER)
CS Streaming 57.6 CS57.6 -20 (1% BLER)
- 180 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
SRB -20 (1% BLER)

PS Interactive 64/64 PS64 -20 (1% BLER)
SRB -20 (1% BLER)
SRB -20 (1% BLER)
SRB -20 (1% BLER)
Speech+ PS Interactive 64/64 Speech -20 (1% BLER)
PS64 -20 (1% BLER)
SRB -20 (1% BLER)
Speech+ PS Interactive 0/0 Speech -20 (1% BLER)
PS64 -20 (1% BLER)
SRB -20 (1% BLER)
PS Streaming 16/64 +PS Int PS Streaming -13 (5% BLER)
8/8 PS8/8 -13 (5% BLER)
SRB -20 (1% BLER)
Conversational CS data 64 + CS64 -25 (0,3% BLER)
PS Int 8/8 PS8/8 -20 (1% BLER)
SRB -20 (1% BLER)
PS Interactive 64/HS Int 64 (UL) -20 (1% BLER)
SRB (UL) -20 (1% BLER)
SRB (DL) -30 (0,1% BLER)
PS Interactive 384/HS Int 384 (UL) -20 (1% BLER)
SRB (UL) -20 (1% BLER)
SRB (DL) -30 (0,1% BLER)
PACKET THROUGHPUT
Throughput is defined as the perceived user data rate from the
application layer. This means that the throughput will never reach
the peak rate, since the TCP and IP overhead, and retransmissions,
have to be taken into account. The throughput can be expressed per
session, per bearer or per cell.
It is important when dimensioning to know if these overheads have

been taken into account in the requirement.
Session throughput and THold are illustrated in Figure 5-8 below.
LZT 123 8297 R1C © 2006 Ericsson - 181 -

Figure 5-8 Packet Call showing Session throughput and THold
Throughput is associated with the speed and time the data is

transferred in the system on the radio interface. However a closer
look for the accessibility and the channel switching statistics
should be done when examining the throughput statistics for the
packet data sessions.
Distribution chart of PS Application Downlink Throughput Range
7%
37%
56%
App throughput < 64 kps 64 kps <= App throughput < 128 kbps
128 kps <= App throughput < 384 kbps
Figure 5-9 PS Application Downlink throughput from TEMS Investigation
- 182 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
In TEMS Investigation the Best Server throughput is measured and

reported in a table that shows the application throughput and
RLC/transport channel (low-level) throughput per cell. Please note
that the low-level throughput is measured differently for different
handsets.
The Application (end-to-end) throughput is also measured and

reported in different tables and charts.
Min Average Max
PS Binned Application Throughput Statistics
(kbps) (kbps) (kbps)
Average Application DL 1,0 65,7 367,0
Average Application UL 1,0 7,0 39,0
Median Application DL Throughput for spreading factor = 32 1,0 38,6 122,0
Table 9 PS Binned Application-level Throughput Statistics
Channel Switching
Congestion control is used to resolve overload in both the uplink
and the downlink. It uses Power and RSSI (Received Signal
Strength Indicator) measurements. In case of overload, congestion
control reduces bit rates of delay tolerant existing connections or as
a second option, removes existing connections. When the Cell load
rises due to the increased power requirement of for e.g. the UE that
is moving away from the RBS. When this load reaches a defined
limit the RBS must reduce it by switching non-guaranteed users to
lower rate common channels.
Channel Switching applies only to packet traffic on the interactive

RAB, which has little or no quality of service attributes that apply.
It belongs to the Interactive and Background Quality of Service
classes, which have no guaranteed bit rates and no packet delay
requirements. When sufficient resources are available, the
interactive RAB receives high bit rates but when the system is
heavily loaded and not many resources are available, the bit rates
offered may be low. In a heavily loaded situation, it may not be
given any bandwidth at all, since there are no guarantees on
resource allocation for the RAB.
Channel Switching switches only between transport channels. The

logical channels are not affected. When large amounts of data are
being sent or received, the DCH transport channel with various
rates is available on both the uplink and the downlink. In addition,
the HS-DSCH is available on the downlink and E-DCH is available
on the uplink, both depending on UE and cell capability.
LZT 123 8297 R1C © 2006 Ericsson - 183 -

For small amounts of data, the common transport channels RACH

and FACH are used. In this case, for downlink, a maximum of 32
kbps is shared between all users in a cell.
For no data activity, the interactive RAB is switched to URA state,

where no transport channels are allocated and thus no data
transmission is possible.
Channel switching function works both on a Single RAB and on a

Multi RAB combination.
The Channel Switching function optimizes the resource usage by

dynamically allocating different transport channels to the
Interactive RAB of a UE. It consists of two parts: evaluation and
execution. The evaluation part is responsible for monitoring the
resource and coverage needs of a UE through measurement reports
received from the UE, the RBS, and the RNC. A request to switch
up or down in rates is made to the execution part when a need is
detected. The execution part is responsible for (1) allocating the
needed resources according to UE and cell capability and (2)
executing the Radio Bearer Reconfiguration procedure for making
the switch
The Channel Switching evaluation is based on two criteria: user

activity and coverage condition. User activity is measured in terms
of either channel throughput or RLC buffer load and coverage in
terms of downlink code power.
The Channel Switching Algorithms can be triggered either by the

UE or the RNC, depending on the behavior of the uplink and
downlink, respectively. All of the Channel Switching evaluation
algorithms have event triggered measurements, meaning that
measurement reports are sent only when necessary. This means that
the actual measurements are processed before reporting. The
Channel Switching Algorithms use RLC buffer load, throughput,
and transmitted code power as input to the algorithms.
Not all Channel Switching algorithms are active in every state. An

algorithm corresponding to a certain state is started once the state is
entered successfully and stopped when a new state has been
entered successfully.
The switching is initiated by either the UE or the WCDMA RAN

and is triggered by the Channel Switching Common to Dedicated
Evaluation Algorithm based on measurements made by the
WCDMA RAN or the UE.
The Channel Switching algorithm group consists of the following

sub-algorithms:
- 184 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
• Common to Dedicated Evaluation
• Dedicated to Common Evaluation
• Common to URA Evaluation (in P5)
• URA to Idle Evaluation (in P5)
• Coverage Triggered Downswitch Evaluation
• CELL_DCH to CELL_DCH Upswitch Evaluation
• Throughput based CELL_DCH to CELL_DCH

Downswitch Evaluation (in P5)
• Multi RAB Downswitch Evaluation
• Multi RAB Upswitch Evaluation
There are two states in connected mode: Dedicated state

(Cell_DCH) and common state (Cell_FACH). These are associated
with the transport channel on which the user data is sent. Channel
Switching is activated in connected mode and handles switches
between the different states or to idle mode. The switches between
dedicated and common states are handled by WCDMA RAN
without the involvement of the Core Network. The possible state
transitions are shown in the figure below.
Figure 5-10. WCDMA Channel Switching
LZT 123 8297 R1C © 2006 Ericsson - 185 -

An UE on a common channel can be switched down to idle mode if

it shows no activity during a certain time interval. In this way,
resources are made free and common transport channel
(FACH/RACH) signaling over the Iur interface is avoided. It also
decreases the power consumption of the UE, since the UE does not
have to monitor the FACH for long periods of time. This switching
is initiated by the WCDMA RAN and is triggered by the Channel
Switching Common to Idle Evaluation Algorithm based on
measurements made by the WCDMA RAN. The timer is used to
release UEs that has been inactive too long.
The Dedicated Channel (DCH) is well suited for high bit rate
traffic, since it is reserved for one user and provides closed loop
power control. High user bit rates create a lot of interference and
power control is essential to keep the interference on an acceptable
level.
It is also important to keep the common transport channels free

from everything but control information and small portions of user
data, in order to keep system function execution times sufficiently
low. The use of a common transport channel would negatively
affect the throughput of other users.
Common to Dedicated UpSwitch

RLC Buffer load: The buffer load is defined as the minimum of
the Radio Link Control (RLC) transmission window and the sum of
bytes in the SDU buffers and retransmission buffers of some of the
RLC instances (each interactive RAB connection consists of five
RLC instances). When the RLC buffer load in the uplink exceeds
the threshold value set by the parameter ulRlcBufUpswitch, a
measurement report is sent from the UE. An upswitch request is
issued upon reception of the measurement report. A request is also
issued when the RLC buffer load (in the RNC) in the downlink
exceeds the threshold value set by the parameter
dlRlcBufUpswitch. Channel Switching execution thereafter
performs the upswitch when permission is given from Admission
Control. Only one radio link is set up, since it is the responsibility
of Soft and Softer Handover to add radio links after switching is
complete
- 186 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
When setting dlRlcBufUpswitch it is important to consider how

much of the TCP signalling should be done on common and how
much signalling should be done on DCH. For example, when a UE
is used for web browsing, uplink traffic is started by a short DNS
message. If ulRlcBufUpswitch is set to a value smaller than the
size of the DNS look-up message, an upswitch to DCH will be
issued by the very first signaling from the UE which decreases the
response time. On the other hand, a low setting of this parameter
could make signaling from other applications trigger an upswitch
when the UE is used as a modem for a laptop computer.
Dedicated to Common DownSwitch

Throughput: Uplink throughput is defined as the number of bits
received to the RLC layer from the MAC layer. Downlink
throughput is defined as the number of bits transmitted from the
RLC layer to the MAC layer. The RLC instances to be considered
for the buffer load and throughput measure depends on the UE state
and the algorithm using the measurement. When the throughput on
both the uplink and downlink is below the threshold value set by
the parameter downswitchThreshold, the timer
downswitchTimer starts (when on DCH/DCH) or the timer
hsdschInactivityTimer starts (when on DCH/HS or EUL/HS). If
the throughput increases above a second threshold set by the
parameter downswitchTimerThreshold before the timer expires,
the timer is stopped and no switch is issued. See Figure 5-11
Figure 5-11. The dedicated to common channel switching evaluation
If the downswitchTimer parameter is set to 0, the Dedicated to

Common Evaluation algorithm is turned off, meaning that no down
switches from dedicated to common will occur, irrespective of how
long throughput has been below the threshold.
LZT 123 8297 R1C © 2006 Ericsson - 187 -

Optimization of the down switch from dedicated to common

channels is a direct trade-off between resource utilization and user
throughput. The goal is to achieve a parameter setting that correctly
estimates when transmission for a user has ended in order to
release assigned resources as fast as possible. The behavior of this
algorithm is determined by the setting of the
downswitchThreshold and downswitchTimer parameters.
The downswitchThreshold parameter determine how the radio

access network should behave in the end of a TCP transmission. In
general, when, e.g., a FTP download is over, throughput rapidly
decreases to 0 kbps and then does not increase again until a new
TCP transmission is started. Therefore, the default setting of this
parameter is 0 kbps.
However, the setting of this parameter is strongly dependent on the

characteristics of the TCP traffic. If, for example, a UE is used as a
modem connected to a laptop it can very well be the case that
applications on the laptop creates a low rate background traffic.
The combined TCP traffic caused by e.g. a FTP download and the
background traffic could make it necessary to set a higher value of
downswitchThreshold . This is to avoid that a TCP transmission -
that after transmitting with a throughput close to 384 kbps during
the FTP download goes down to the e.g. 4 kbps created by the
background traffic - holds the resources associated to the 384 rate
unnecessarily long.
The downswitchTimer defines the time a user will stay on DCH

with low throughput before being switched down to FACH. If this
timer is set long, the probability that a user is switched down to
FACH during short periods of inactivity decreases. This improves
the user throughput, but also increases resource utilization and
thereby decreases system capacity. It is therefore not recommended
that this timer is used for generally improving user throughput.
There are however traffic cases that can be improved by a slightly
increased timer setting. For example, FTP transmissions can be
split into several TCP transmissions. If the UE (or the laptop when
the mobiles used as modem) uses this for FTP transmissions the
user perception of the FTP transmission can be improved by a
small increase of this timer. It should however be remembered that
this then is done on the cost of system capacity.
- 188 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
URA Evaluation (P5)

URA Evaluation: The Common to URA Evaluation releases UEs
with no activity in order to free resources. It also decreases the
power consumption of the UE, since the UE does not have to
monitor the FACH for long periods of time. The algorithm is
activated at the entry of the CELL_FACH state. Uplink and
downlink activity is monitored and the algorithm requests a switch
to URA_PCH state if no uplink or downlink activity has been
detected (i.e. no data has been transmitted) during inactivityTimer
seconds. The request is issued to the Channel Switching execution
function, which handles the further processing of the transition to
URA_PCH state.
The URA to Idle Evaluation releases UEs with no activity in order

to free resources. The algorithm is activated at the entry of the
URA_PCH state. The algorithm requests a switch to Idle mode if a
UE has been allocated to URA_PCH state for InactivityTimerPch
minutes. The request is issued to the Signaling Connection
Handling function, which handles the further processing of the
transition to Idle mode. Signaling Connection Handling issues an
Iu release request to the Core Network, which in turn decides
whether the connection should be released.
Coverage Triggered Downswitch

Transmitted Code Power: Transmitted code power is defined as
the downlink power of the pilot bits of the DPCCH field.
The Coverage Triggered Down switch Evaluation algorithm

monitors the code power utilization on the downlink. If the code
power increases so that a switch to a lower rate dedicated channel
on the downlink is required due to coverage reasons, a down switch
request is sent to the Channel Switching Execution function. The
goal is to minimize dropping due to bad link quality.
When downlink transmitted code power increases too close to its

maximum, there is a risk that the link quality cannot be maintained.
In this situation, a user should be switched down to a lower rate to
decrease the needed downlink transmitted code power. The
function will control that no user is using a rate in an area where
there is risk for no coverage of that particular rate. It is therefore
important that the mapping for maximum downlink power is tuned
so that desired coverage is achieved
LZT 123 8297 R1C © 2006 Ericsson - 189 -

The algorithm monitors the downlink transmitted code power of all

legs in the active set and the code power is then filtered by each
RBS in the active set. A down switch request is issued when all
handover legs use a power above the power alarm threshold. The
power alarm threshold is defined by the parameter
downswitchPwrMargin. If the transmitted downlink code power
falls below the power alarm threshold while the timer
coverageTimer runs, the request will be cancelled and no
downswitch is executed.
The actual coverage of each rate is given by the maximum

downlink power per radio link. This maximum downlink power per
radio link is determined through a per-cell definable mapping based
on the maximum rate of the radio link. By adjusting the mapping,
coverage can be increased or decreased. When adjusting the
mapping, some restrictions apply. For the coverage testing before
upswitch, the downlink maximum transmitted code power is the
maximum code power of the current rate. Consequently, the
mapping should not be defined so that the resulting downlink
maximum transmitted code power of a lower rate is higher that the
downlink maximum transmitted code power of a higher rate. If this
is done, the coverage tester functionality could fail and it could
happen that the link quality cannot be maintained after an upswitch
have been granted.
The average amount of transmitted code power is not only

dependent on the used transmission rate and attenuation to the UE,
but also on the blerQualityTarget parameters. By setting these
parameters, average link quality can be traded for decreased
resource consumption (i.e. transmitted code power). It is however
then also important to notice that with decreased average link
quality, user throughput will be decreased. From user throughput
point of view it is therefore proposed that the blerQualityTarget is
kept to a low vale (e.g. 1%).
This evaluation algorithm is started at the entry of the single RAB

states CELL_DCH 64/384 and 64/128 and Multi RAB states
speech + 64/384 , speech + 64/128 and 64/128 + 64/128
- 190 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
Channel Rate Switching

The Dedicated to Dedicated Upswitch Evaluation algorithm
determines whether a switch to a higher rate channel should be
made. The same algorithm applies both for Single RAB and for
Multi RAB. The algorithm monitors the uplink and the downlink
throughput separately. A channel switch request to a higher uplink
rate Radio Bearer (uplink triggered) or to a higher downlink rate
Radio Bearer (downlink triggered) is issued if all of the following
conditions are fulfilled:
• The downlink throughput increases above the threshold

specified by bandwidthMargin or the uplink throughput
increases above the threshold specified by
bandwidthMarginUl.
• For a trigger on the downlink, the transmitted code power

consumption on the current rate is below the power
upswitch threshold for all legs in the active set.
• The maximum bitrate capability for QoS profiling does not

indicate that the current rate is the maximum bitrate for the
user.
• After a throughput based downswitch, the downlink

throughput has fallen below the threshold specified by
dlThroughputAllowUpswitchThreshold or the uplink
throughput has fallen below the threshold specified by
ulThroughputAllowUpswitchThreshold.
The upswitch timer is specified by the parameter upswitchTimer

for a downlink trigger and upswitchTimerUl for an uplink trigger.
The power upswitch threshold is defined from the power alarm

threshold (described below) through the parameter
upswitchPwrMargin and the estimated power increase. The
estimated power increase is based on the relative rate difference
between the current and a higher rate.
If the bandwidthMargin parameter is set to 0 or the

bandwidthMarginUl is set to 0, the Dedicated to Dedicated
Upswitch evaluation is turned off for downlink or uplink
respectively.
If the dlThroughputAllowUpswitchThreshold parameter is set to

0 or the ulThroughputAllowUpswitchThreshold is set to 0, this
condition is not used for downlink or uplink respectively.
LZT 123 8297 R1C © 2006 Ericsson - 191 -

The Dedicated to Dedicated Down switch Evaluation algorithm

determines whether a switch to a lower rate channel should be
made. The same algorithm applies both for Single RAB and for
Multi RAB. The algorithm monitors the uplink and the downlink
throughput separately. A channel switch request to the next lower
uplink rate Radio Bearer (uplink triggered) or to the next lower
downlink rate Radio Bearer (downlink triggered) is issued in the
following situation:
• The downlink throughput decreases below the threshold

specified by dlDownswitchBandwidthMargin or the
uplink throughput decreases below the threshold specified
by ulDownswitchBandwidthMargin .
If the above conditions holds for the duration of a down switch

timer, a down switch request is executed by the Channel Switching
function. The downswitch timer is specified by the parameter
dlThroughputDownswitchTimer for a downlink trigger and
ulThroughputDownswitchTimer for an uplink trigger.
If the dlDownswitchBandwidthMargin parameter is set to 0 or

the ulDownswitchBandwidthMargin parameter is set to 0 the
Dedicated to Dedicated Downswitch evaluation is turned off for
downlink or uplink respectively.
TEMS Investigation and Statistics

In TEMS Investigation the events PS Channel Type Switch
Complete, PS Channel Type Switch Failure, PS RAB Channel Rate
Switch Complete and PS RAB Channel Rate Switch Failure
indicates however the channel switching was successful or not. The
Channel rate switch is done according to a spreading factor change.
pmNoOfSwDownNgCong
The counter shows number of times packet data connection

downswitches from a dedicated channel to a common channel
initiated by congestion control. If the down switch is not allowed to
common, then the counter shows number of packet data system
release due to congestion.
PmNoOfSwDownNgAdm
The counter shows number of times packet data connection

downswitches from DCH 64/384 to DCH 64/128 and DCH 64/128
to DCH 64/64 initiated by admission control due to lack of
downlink power or code limit.
- 192 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
DCH 64/384
RAB Sate
DCH 64/128
DCH 64/64
FACH
Packet RAB establishment actual throughput
Figure 5-12. Channel Switching in TEMS Investigation
To compare the measured throughput (by TEMS Investigation) to

the average throughput at the cell and at the RNC level could be
done by looking at the traffic counters in at RBS and RNC level.
Average throughput per cell and RAB in the DL:
pmDlTrafficVolume < RAB >

Throughput =
⎛ pmSum < RAB > RabEstablish ⎞
⎜⎜ * ROP sec ⎟⎟
⎝ pmSamples < RAB > RabEstablish ⎠
The RAB efficiency can also be checked
Actual Bitrate per RAB

RABEfficiency =
Nominal Bitrate per UeRc =x
The results gives the percentage of bitrate used compared with the
maximum allowed by the RAB. In particular the speech RAB can
be considered as the activity factor of the RAB. However this
formula can not be used for HSDPA traffic.
The throughput for HSDPA is calculated differently from the other

RAB due to the fact that there is a new protocol involved, the
MAC-HS.
However if looking at transmitted bits the average HS cell

throughput can be obtained:
pmSumTransmitted bits * 500

pmNoActivesubFrames + pmNoInactiveRequiredSubFrames
The Average HS Cell throughput:
pmSumAckedBits * 500
pmNoActivesubFrames + pmNoInactiveRequiredSubFrames
LZT 123 8297 R1C © 2006 Ericsson - 193 -

HSDPA
The operators will implement WCDMA High-Speed Downlink
Packet Access to gain more throughput per cell and higher bit rate
per user. HSDPA is useful mainly in good radio channel conditions
(e.g. high C/I, Low speed). On the other hand HSDPA will use
whole remaining power all the time, which means lower C/I.
The HSDPA concept is based on the following features:
9 Shared channel transmission
9 Higher-order modulation
9 Short transmission time interval (TTI)
9 Fast link adaptation
9 Fast scheduling
9 Fast hybrid automatic-repeat-request (ARQ).
The new transport channel type, using multi-code transmission, is

shared dynamically in time and code domain among multiple users.
HS-DSCH is rate controlled, higher bit rates: 2 - 14.2 Mbps.
Encoding rate, number of channelization codes and modulation
type adapted, are based on available power. The adaptation is on 2
ms transmission time interval (TTI), e.g. 500 times/sec. This means
the round trip delay is reduced on the air interface and the Fast
Link Adaptation, Fast Radio Channel-dependent Scheduling and
Fast hybrid ARQ with soft combining are possible.
HW AND SW PREPARATIONS
There are no need for new sites or for extra spectrum/carrier at the
first deployment of HSDPA due to the fact that there are few UE
available.
However the software for the RNC, RXI and RANOS has to be
upgraded as well as the RBS. In the RBS there are also a need for
HW upgrade to new Baseband boards (HS-TXB and HS-RAXB).
New and more efficient transmission solutions are necessary in

order to serve the much higher bit rates. A wide range of ATM
transmission interfaces e.g. E1, E3 & STM-1 as well as
aggregation on Hub RBS and RXI level has to be installed
Transport network efficiency features provided through SW

upgrade.
- 194 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
OPTIMIZING THE HSDPA

Most of the existing WCDMA Networks are tuned/optimised to
handle 60-70% of the downlink load during busy hours. Their
current power parameter setting is for handling that load as well.
Implementing HSDPA the network can most of the time be loaded
100%.
HSDPA feature tuning

A higher-order modulation, 16QAM in complement to QPSK is
used for higher peak bit rates. 16QAM allows for twice the peak
data rate compared to QPSK but it will be more sensitive to
interference. With HSDPA higher system capacity is achieved, 2 - 3
times more. The 16QAM is an optional feature in the Node B that
will be implemented in P5.
Fast Link Adaptation, data rate adapted to radio conditions on 2 ms

time basis, adjusts transmission parameters to match instantaneous
radio channel conditions, i.e. path loss, shadowing, interference
variations and fast multi-path fading. There is no power control as
such at the channels but the adaptation is based upon the CQI,
Channel Quality Indicator.
In order to increase the throughput the more channelization codes

can be dedicated to the HS traffic. However in P4 the codes will
then not be available for R99 traffic.
With Fast Hybrid ARQ will re-transmissions of erroneous packets

processed in the RBS be faster and soft combining of multiple
transmission attempts to improve performance is used in the UE.
With Fast Radio Channel-dependent Scheduling is scheduling of

users on 2 ms time basis. Scheduling implies which UE to transmit
to at a given time instant based on radio channel quality and
targeting fading peaks. In P4 there are only Round Robin and the
Proportional Fair scheduling algorithm available.
Power parameters
HSDPA will take whatever power that is left in RBS after common
channels and dedicated channels has taken their part
The average power utilization in the network will increase with

HSDPA
LZT 123 8297 R1C © 2006 Ericsson - 195 -

Power
Max cell power
HSDPA power
Admission control threshold
DCH power
CCH power
time
Figure 5-13. HSDPA will take whatever power that is left in RBS
Power of the Common Channels, e.g. CPICH and SCH should be

increased and verified. This because with 100% cell load the Pilot
(CPICH) or other common channel should remain their quality in
the cell. The power of non-HSDPA common channels is always set
relatively to the primary common pilot channel power
(primaryCpichPower). These settings are chosen so that they
ensure sufficient quality where the CPICH can be detected. Current
deployed networks show that the default settings are robust and
give good performance, both in terms of accessibility and
retainability. Tuning common channel settings should be done
primarily through modifying primaryCpichPower, hence trading
coverage for capacity
In areas with poor coverage it is possible to increase the success of

the random access procedure by maximizing the number of
transmitted preambles. This is achieved by setting the parameter
powerOffsetP0 to 1 dB, preambleRetransMax to 32, and
maxPreambleCycle to 32. These settings ensure that the UE
transmits the maximum number of preambles before aborting the
attempt, thus ensuring maximum detection probability in the RBS.
Tests have shown that the coverage improvement with this setting
is in the order of 1 - 3 dB.
- 196 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
Changing the powerOffsetP0 to 1 dB lowers the power ramp step

size from 3 dB. This enables the UE to transmit more preambles at
maximum UE power since the terminal aborts the ramping if the
calculated UE power (P_PRACH) is 6 dB above the
maxTxpowerUl. With 1 dB power steps the UE will send 6
preambles at maximum power compared to 2 preambles with a
powerOffsetP0 at 3 dB. The potential drawback here is that the
call set up time is slightly increased, since smaller power increase
steps are taken. There is a trade off between call set up time, delay
when in CELL_FACH state and coverage. Each preamble takes in
the order of 5 ms. With an ideal initial power setting, the added
delay in call set up will be 10 ms in the worst case.
With a smaller power step size, the number of preambles must be

increased to ensure that it is possible to reach the maximum power.
For this reason maxPreambleRetransMax is set to 32.
Max power of the DCH (other RABs) should be increased and

verified. This because with 100% cell load the DCH channel
should remain their quality in the cell border, where they are using
their max power. The uplink (UL) dedicated control channel HS-
DPCCH provides fast feedback of HARQ acknowledgements and
the Channel Quality Indicator (CQI) on the UL. Reliable reception
of the HS-DPCCH is essential for good HSDPA performance.
Power control of HS-DPCCH is given as an offset relative to

DPCCH and there are different values depending on whether or not
the UE is in soft handover. The reason for this is that the HS-
DPCCH terminates in the RBS and is only received in the serving
HS-DSCH cell. This implies that HS-DPCCH might have
performance degradation when it is power controlled by multiple
cells and the serving cell is not the best cell in the UL. Therefore
higher power offset values are used when the UE is in soft
handover and lower offsets otherwise. The drawback with the
higher settings necessary for successful reception of HS-DPCCH is
the higher resource cost (UL interference will increase). Therefore
it is important to set these parameters correctly considering this
trade-off.
The updates of the power offset parameters are triggered by the

RNC when the numbers of Radio Link Sets are changed.
The power offset parameters are grouped into two namely

deltaCqi1, deltaAck1, deltaNack1 and deltaCqi2, deltaAck2,
deltaNack2. The first group is used when the number of Radio
Link Sets (RLS) is equal to one (that is RLS=1) and the second
when it is greater than one (that is RLS>1).
LZT 123 8297 R1C © 2006 Ericsson - 197 -

The power setting of HS-SCCH is fixed. The parameter

hsScchMaxCodePwr determines the power level of HS-SCCH
and is expressed as an offset relative to the PCPICH. The
information element "HS-SCCH power offset" that can be carried
over NBAP shall not be used.
With HS-DSCH there is a new Radio Bearer defined for the A-

DCH corresponding to a 3.4 kbps SRB in the downlink and a 64
kbps bearer in the uplink.
Uplink initial power setting for the Interactive PS RAB 384/HS id

cone with the parameter ulInitSirTargetExtraHigh.
Interference
After implementing HSDPA and having full load system the overall
interference floor will increase and consequently the overall C/I
will be lower. This because the network most probably as a best
had been tuned to handle around 70% of the load but now the load
can go up to 100%.
Increasing a non-power-control-channel, e.g. pilot, means more

power into the neighboring cells and hence higher interference in
them as well. This high interference will cause higher power
consumption per user and therefore lower cell capacity. The only
way then to have lower interference is to retune the network.
To have cells with as less coverage “islands” and as less

overlapping (outside SHO areas) as possible. Then the power is
located in areas where it is used and minimized the power in areas
when it disturbs as interference. This means need of retuning.
High sites generate

interference
outside the planned
coverage area
Tilting antenna is an efficient way of
achieving confined cells
- 198 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
Depending on the operators design and tuning the whole network

needs to be retuned to get better C/I everywhere. This because the
network most probably as a best has been tuned to handle around
70% of the load but now the load can go up to 100%. This should
not be mixed with above where it is based on a user/RAB (or
common channels), when here covers the capacity in the cell.
Handover parameters
HSDPA will not use SHO but hard HO (no macro diversity). This
means in the SHO areas (cell borders) the HSDPA, which is
already sensitive to interference, will be more sensitive and
therefore retuning may be needed to optimize the original SHO
regions more.
After implementing HSDPA high data speed PS radio bearers e.g.

PS384 may not need same coverage requirement as before and
need to be retuned.
HS-DSCH is not power but rate controlled, higher bit rates: 2 -

14.2 Mbps. Encoding rate, number of channelization codes and
modulation type adapted, are based on available power. To have a
higher bit rates more power is needed.
System Load
The DL Load is here measured as the percentage of used DL Power
compared to the available one (including Common and Dedicated
Channels). Two Load Condition Scenarios can be defined:
9 Low Load represents the Off-Peak Hours. It is generally

assumed that the transmitted cell carrier power mostly
includes the DL Common Channel Power.
9 High Load represents the Peak Hours with high transmitted

cell carrier power
By considering the additional interference generated by HSDPA

Traffic from each cell, at both the Ec/Io and DL RSSI.
The traffic load is considered in terms of DL Cell Transmitted

Carrier Power. DL Cell Transmitted Carrier Power is the total DL
transmitted power by a cell and it includes both Common and
Dedicated Channel Power. The data can be obtained from the RBS
counter pmTransmittedCarrierPower.
LZT 123 8297 R1C © 2006 Ericsson - 199 -


Below in the following sections there are several different
problems found with TEMS Investigation in a WCDMA network.
HIGH DL BLER - NO RAB SETUP

In TEMS Investigation the High DL BLER problem can be found.
The last downlink message which the UE gets its ”Call
Proceeding”. After this, the connection drops.
Before the drop, the DL BLER rapidly increases. However, the

CPICH_RSCP and CPICH_Ec/No are good.
There are no other interference cells over the problematic location.
Figure 5-14 Example of high DL BLER and no radio bearer setup
One possible cause could be that the UTRAN failed to prepare the
radio bearer and the UE time expired and then terminated the
connection.
- 200 - © Ericsson 2006 LZT 123 8297 R1C

5 Service Integrity
Another possible cause could be that the UE was faulty and caused
high DL BLER. Then the UE did not receive the RB Setup
message from the UTRAN. Finally, the UE terminated the call
setup.
HIGH DL BLER – DROPPED CALL

In TEMS Investigation the High DL BLER problem can be found.
The connection is dropped after UE sends Radio Bearer Setup
Complete message.
Before the drop, the DL BLER rapidly increases. However, the

CPICH_RSCP and CPICH_Ec/No are good. Typically, UE Tx
power increase high but not all time.
There are no other interference cells over the problematic location,

but in some cases there were many handovers during call setup.
There is no DL
signaling after the
Radio Bearer Setup
Complete message
The UE TX
power is high
Figure 5-15 There is no DL signalling after the Radio Bearer Setup

Complete
LZT 123 8297 R1C © 2006 Ericsson - 201 -

One possible cause could be that the UTRAN failed to synchronize

the radio bearer in UL.
Another possible cause could be that the UE failed to properly

establish the radio bearer and caused high DL BLER
- 202 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
6 UETR and GPEH
Objectives
• Understand which tools that are available for optimizing a

network
• Understand how to setup and retrieve UE Traffic Recording

(UETR)
• Understand how to analyze the UETR files using the TEMS

Investigation RAN analysis
• Understand how to setup General Performance Event

Handling (GPEH) and analyze the GPEH files
LZT 123 8297 R1C © 2006 Ericsson - 203 -

Intentionally Blank
- 204 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
UE TRAFFIC RECORDING (UETR) ..................................................207

UETR RECORDABLE MESSAGES AND MEASUREMENTS...................... 208
ADD A UETR SUBSCRIPTION PROFILE .................................................... 210
RETRIVE THE UETR LOGFILES ................................................................. 214
ANALYZE THE UETR LOGFILES ................................................................ 214
GENERAL PERFORMANCE EVENT HANDLING (GPEH)...............219

INITIATION OF GPEH .................................................................................. 220
GPEH FILES COLLECTION AND STORAGE .............................................. 222
GPEH FILE STRUCTURE ............................................................................ 223
GPEH FILE ANALYSIS USING RED............................................................ 227
GPEH FILE ANALYSIS USING TEMS ......................................................... 232
LZT 123 8297 R1C © 2006 Ericsson - 205 -

Intentionally Blank
- 206 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
UE TRAFFIC RECORDING (UETR)

UETR is a performance recording function in WCDMA RAN. It
allows the operator to record the important events and behaviour on
a selected UE or UEs traveling through a network. Only one UE
may be selected per UETR recording, but one RNC gives the
possibility of running up to 16 UETR simultaneously. If the UE
crosses a RNC border, the UETR needs to be activated for both.
The UEs to be traced are identified by the operator using their
respective IMSI numbers.
The operator can send out a test mobile (in particular after changes
or extensions to the network) to record live traffic to investigate the
performance of the network in a certain area. Event data in the
RNC and measurement data from the RBS and UE, related to the
air interface, are recorded.
This function allows monitoring of specific information sent to and

from the UEs. For example, the operator can check the data used to
make handover decisions and from it identify parameters that need
to be adjusted to achieve improved performance.
The UETR administration is supported by OSS-RC, which

provides capabilities for:
1. Starting a UETR recording for one RNC.
2. Viewing a UETR performance recording.
3. Modifying a UETR performance recording.
4. Activating and deactivating a UETR performance recording.
5. Listing all UETR performance recordings.
6. Starting UETR for multiple RNCs.
7. Viewing performance monitoring filters.
The procedures related to the RANOS operation for UETR will be

described below.
LZT 123 8297 R1C © 2006 Ericsson - 207 -

The output file of UETR uses a proprietary Ericsson binary format

with embedded protocol messages, internal events and
measurements. The protocol messages are represented in the
transfer syntax specified by the protocol standards as they appear
on the RNC interfaces. The internal messages are specified by a
proprietary ASN.1 definition and encoded in a BASIC-PER aligned
variant.
Note the file size for the UETR are limited in the RNC the
parameter to control this is uetrFileSize.
UETR RECORDABLE MESSAGES AND MEASUREMENTS
Recordable messages
The UETR function can be chosen to record one or more of the
messages within one or more of the following protocol groups:
1. NBAP, between RNC and node B (Iub)
2. RANAP, between RNC and core network (Iu)
3. RNSAP, between RNCs (Iur)
4. RRC, between RNC and UE (Uu)
UETR measurements
The following measurements are reported through the RNC
internal event:
1. Transport Channel BER, measured on DCH after radio link

combination (ordered for all DCHs relating to the UE
connections being recorded). Measurement period = 1xTTIs,
reporting period = 5xTTIs. The measurement period is the
frequency with which the measurement is received in band in
the RNC from the RBS. The reporting period is the frequency
with which sequences of values are reported to the RNC PM
recording application internally in the RNC.
2. Transport Channel BLER: uplink DCH (ordered for all DCHs

relating to the UE connections being recorded). Measurement
period = 10s, reported period = 10s.
- 208 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
3. RLC Buffer information, number of discarded DCCH SDUs,

number of discarded DTCH SDUs, number of retransmitted
DCCH PDUs and number of retransmitted DTCH SDUs
(ordered for each downlink logical channel -per DCCH, per
DTCH- associated with the UE being recorded). Report
Period 10 s. This measurement is not reported from the UE,
but is recorded in the RNC per UE. This is reported as an
RNC internal event in the ROP file.
The following two measurements are reported through NBAP

Dedicated Measurement Report. For the user to receive any of
these measurements in the recording ROP file, the measurements
and the NBAP Dedicated Measurement Report message must be
selected.
1. Uplink SIR per radio link set, measured on DPCCH after

radio link combination in the RBS. All values recorded within
a 960 ms period are averaged and reported every 960 ms
(ordered for all RLs relating to the UE connections being
recorded).
2. Transmitted Code Power, measured on the pilot bits of one

channelization code for a DPCH. One average value is
reported every 1000 ms (ordered for all DPCHs relating to the
UE connections being recorded).
The following two measurements are reported through RRC

Measurement Report. For the user to receive any of these
measurements in the recording ROP file, the measurements and the
RRC Measurement Report message must be selected.
1. Transport channel BLER: downlink DCH is reported

periodically every eight s (ordered for all DCHs relating to the
UE connections being recorded).
2. UE transmitted power, reported periodically every second.
LZT 123 8297 R1C © 2006 Ericsson - 209 -

ADD A UETR SUBSCRIPTION PROFILE

The following procedure is used to add a UETR subscription
profile:
1. Log into OSS-RC
2. Run the RANOS Network Explorer
3. Access the Data collection – Subscription profiles window

from the Data collection choice on the Performance menu of
RANOS Explorer. The following window appears:
Figure 6-1. Data Collection – Subscription profiles
4. Click on the Profile in the main drop down menu; then click
Add. A create subscription profile wizard appears. For
example:
- 210 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
Figure 6-2. Selecting the UETR profile
5. Select User equipment traffic recording profile (UETR);

then click Next. The window Enter subscription profile
name and comment pops up as shown below:
Figure 6-3. Entering a profile name and comments
6. Enter a profile name and comment; then click Next. A

window to select the RNC to be included, Step 3 of 6
pops up. For example:
LZT 123 8297 R1C © 2006 Ericsson - 211 -

Figure 6-4. Selecting the involved RNC
7. Select the involved RNCs and then click Next. Select

events for the UETR recording, Step 4 of 6 windows
appears. For example:
Figure 6-5. Selecting the protocols to be measured on
- 212 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
8. Select necessary events and then click Next. The “Enter

IMSI number for the UETR recording”- window pops
up:
Figure 6-6. Step Entering the IMSI number
In order to get the IMSI number for a subscriber in the network

connect to the MSC and type the following command in the
command handler.
Mgtrp:msisdn = <mobile number>
The mobile number should be the full number, including the

country code MCC and the mobile network code MNC
9. Enter the IMSI number of the test UE and then click Next.
The “Select profile schedule wizard dialog”-window
appears.
10. Choose relative profile schedule and enter the duration,

then click on the FINISH button. This is the last wizard step
and the created profile is included in the Data collection –
Subscription profile dialog box.
LZT 123 8297 R1C © 2006 Ericsson - 213 -

RETRIVE THE UETR LOGFILES

On collection, the PMS renames the UETR files according to the
convention below:
A<Date>.<StartTime>-<EndTime>_<ShortNodeId>_<
ShortScannerId>_<IMSI>_uetrfile.bin
The files are stored in the folder:

‘var/opt/ericsson/nms_umts_pms_seg/segment1/Subnetwork=RNC
01/MeContext=RNC01’ for 1 day.
ANALYZE THE UETR LOGFILES

The UETR function traces the behavior of an individual phone by
recording event data produced in the RNC, as well as measurement
data from the RBS and from the phone itself. The phone-originated
data is also a subset of what is found in the TEMS log file,
although in the UETR file it is not tagged with any positioning
information. The remainder of the UETR file data is referred to as
"uplink data" within the TEMS Investigation framework. It should
be noted that UETR files contain no idle mode data, only data from
calls.
The files can be recorded for voice calls only, not when running a
data service. At present, TEMS Investigation is not capable of
reading uplink data from other manufacturers' equipment.
Uplink files can be replayed as-is in TEMS Investigation. They can

however also be merged with the corresponding TEMS log files,
producing output in the form of an augmented log file which can be
replayed in the usual manner. The contents of the uplink file can
thus be viewed concurrently with the downlink data recorded in the
TEMS log file. A further advantage of merging the files is that
geographic positioning can be obtained for the uplink data.
The uplink data is presented as a separate class of information

elements.
Merging the files

The task of the merging algorithm is to time-align – synchronize –
the information in the uplink files with that in the log files. A time
offset can be expected between the clock that governs uplink file
time-stamping (for UETR files, the RNC clock) and the clock in
the PC on which the log files were recorded.
- 214 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
While an uplink file contains (usually) one complete call involving

a specific phone (actually a specific IMSI, i.e. subscriber identity),
a log file can comprise an arbitrary number of calls made by one or
several phones. The typical situation, therefore, is that a log file
corresponds to multiple uplink files, each covering a log file
segment that concerns a single call.
Figure 6-7. One TEMS Log file corresponds to several Uplink files.
For each call in the log file, the merging algorithm extracts a
number of key characteristics: start time, stop time, and
information about handovers (time of occurrence and serving cells
involved). Then, each uplink file is compared to each call in the log
file with respect to these characteristics. The uplink files for which
a reliable match has been found are finally incorporated into the
log file, aligned as indicated by the calculated time offset. The
output is a new log file (extension .log), augmented with the uplink
information, which is represented as being reported by a fictitious
phone "MS5".
The merging algorithm may sometimes fail for certain uplink files;
when this happens, additional information can be provided to align
the uplink files manually.
If the merging algorithm has enough to go on, that is, if all calls in
the files can be readily distinguished from each other by means of
the characteristics considered, the procedure is straightforward.
However, if this is not the case for some uplink file, so that there is
difficulty in finding an obvious best match for it, the procedure will
fail for this file.
Problems will thus arise with sets of similar calls, especially if they
are short and lack distinctive features (namely, handover events).
Fragments of calls, whether in uplink files or log files, are also
more likely to be problematic, because either the start time or stop
time and thus the call duration is unknown.
LZT 123 8297 R1C © 2006 Ericsson - 215 -

Furthermore, the algorithm does not handle day transitions.

Therefore, it cannot correctly process calls beginning before and
ending after midnight, or deal with time offsets that are so large as
to place part of the calls on a different day. In other respects, the
size of the time offset does not affect the performance of the
algorithm.
The following procedure is used to load the UETR files into TEMS
Investigation Data Collection.
1. Open the Export Log file window
2. Under Input files, enter the log file names, or click "Browse
file" and select your files. (If several log files is chosen, the
merge will be done separately for each log file.)
3. Under Directory, specify a directory for the output.
Figure 6-8. Step 1 to 3 of 5
4. In the Format combo box, choose "Log file with uplink data".
Click the Setup button. In the dialog that follows, it is setup
how to perform the merge (Method tab) and what uplink files
to include in it (Uplink files tab).
- 216 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
Figure 6-9. Step 4 of 5
Unless the exact time offset is known beforehand, the merging

should begin by running the algorithm described in the previous
sections. (If the offset is known, the alignment can be carried out
manually).
Mobile to match in log file determines what log file data is

considered when comparing it with the uplink files. If there are
data from several phones in the log file, but uplink files for a single
phone, it is appropriate to disregard the data from the other phones:
this eliminates a source of uncertainty in the matching process and
speeds it up.
Place bounds on uplink file offset can be used if the size of the
offset is fairly known and with this lower and upper bounds can be
entered. This, too, increases the reliability and speed of the
algorithm.
5. Start the merge
The procedure will take some time. When it has completed, a

message ("Export Result") stating success or failure for each uplink
file will be received.
If all uplink files have been successfully matched, the merge is

done. If the algorithm has failed for some files, the Export Result
window should not be closed.
LZT 123 8297 R1C © 2006 Ericsson - 217 -

If no sufficiently reliable match is found for an uplink file, it is not

included in the output log file. There are two possibilities: Either
there is no match – the data in the uplink file simply does not exist
in the log file –, or there is indeed a match to be found, but the
algorithm has problems identifying it.
In the latter case, the algorithm needs more precise information

about the offset. Often several calls in the log file are good matches
and there is a problem figuring out which is the correct one. Now,
the offsets calculated for the successfully aligned uplink files
(which should be nearly identical) should be similar to that of the
remaining files as well.
On the Method tab, check "Place bounds on uplink file offset" and
enter upper and lower bounds based on the values observed in the
Export Result window. The bounds should be tight enough to
ensure that a call in the log file cannot be mistaken for an adjacent
call
If the procedure still fails for some files, they probably do not
correspond to anything in the log file. It might be the case,
however, that some files are corrupt (for instance, they might be
truncated). Even so, you might want of course want to use them.
There may also be a day transition problem. As a last resort,
therefore, the alignment can be assigned by brute force, simply
assuming an offset.
On the Method tab, choose "Assume static offset time" and enter a
value in the box. (The offsets obtained for the successfully aligned
files should still be a good clue.). The remaining files will then be
aligned unconditionally with the log file according to the chosen
offset.
There are limits to the accuracy that can be achieved in time

aligning the uplink files. The accuracy is affected by the following
factors
• The time offset for an uplink file is computed as the average of

the offsets for all characteristic events detected in the call (call
start, call end, handovers, etc.). Therefore, the longer the call, the
more reliable the offset, and vice versa
• Measurement reports in UETR files are not tagged with time-of-

day information, but merely with a counter that is reset after each
handover. This may have the effect that the UETR measurement
reports are imperfectly synchronized with the measurement
reports from the phone
- 218 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
• Older UETR file formats only contain timestamps with a

resolution of 1 s, but in P4 the resolution is 1 ms. This places a
general limit on alignment precision, since a lot of messages may
be written to the log file within one second
Analyzing the files

The merged files can then be analyzed in TEMS Investigation
GENERAL PERFORMANCE EVENT HANDLING (GPEH)

This chapter describes the General Performance Event Handling
(GPEH) function and events for the Radio Network Controller
(RNC) 3810 and RBS 3000.
The GPEH function handles the management and collection of

predefined events in the WCDMA RAN. These events are either
Node-Internal or Inter-Node as listed below:
• RNC-Internal Events
• RBS-Internal Events
• RRC Inter-Node Events
• NBAP Inter-Node Events
• RANAP Inter-Node Events
• RNSAP Inter-Node Events
The Node-internal events are events produced within the RNC or

RBS, due to a specific occasion, for example in an algorithm. The
Inter-node events are protocol messages sent or received from UE,
RBS or RNC.
The term Performance Management Subsystem (PMS) is used to

describe the how the OSS-RC handles the performance
management of the WCDMA RAN. For GPEH, the PMS function
can be divided into three areas:
• Initiation of GPEH
• GPEH files collection and storage
• GPEH files notification
LZT 123 8297 R1C © 2006 Ericsson - 219 -

INITIATION OF GPEH
The PMS system can be used to initiate the GPEH in the RNC and
RBS. This collection is carried out by an entity known as a
‘Performance Monitoring (PMn)’, also sometimes called a
"Scanner".
The RNC provides 24 scanners at node startup, whereas the RBS

provides only one. These pre-defined scanners are all empty. The
Operations Support System Radio and Core (OSS-RC) is used to
specify the contents and activate the scanners. Recording starts at
the beginning of the next 15-minute Result Output Period (ROP)
after activation from OSS-RC. The recorded data from all active
scanners is collected in a common data file per Main Processor
(MP).
The cell filter specifies in which cells in the RNC events shall be
recorded. If an event does not include any cell identifier, it will
match the filter anyway and be reported.
To select GPEH file settings:
1. Launch OSS-RC for a selected RNS
2. Select WCDMA RAN measurements from the dropdown

selection, see figure below.
Figure 6-10. WCDMA RAN measurements – OSS_RC workspace menu
- 220 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
3. Create a performance profile for each selected RNC. Select

WCDMA RAN measurements from the dropdown selection,
The following window appears:
Figure 6-11. Select the General performance profiles
Figure 6-12. Selecting the GPEH events
LZT 123 8297 R1C © 2006 Ericsson - 221 -

4. Selecting the GPEH events are similar to the UETR

configuration; however there are two filter parameters in GPEH
to be selected, Ue_Fraction and Cell. If an event is not related
to a specific UE, the event will match the Ue_Fraction filter
anyway and be reported. The cell filter specifies in which cells
in the RNC events shall be recorded. If an event does not
include any cell identifier, it will match the filter anyway and
be reported.
5. Start the recording
For further information, see General Performance Event Handler

CPI documentation, 23/1551-AXD 105 03/1.
GPEH FILES COLLECTION AND STORAGE

The events are collected in GPEH data files, also called GPEH
ROP files. The events are written to file in the order they appear in
the buffers and are not ordered chronologically. For each 15-minute
ROP period, the following two types of file are generated:
Main File The main file contains administrative information

about the GPEH recording and links to sub files.
Sub file A sub file contains recorded events for all active
scanners.
One main file generated on the O&M MP and one sub file per
Module MP concludes each ROP. Each file has a unique name.
Main file: <Type><Date>.<StartTime>-<EndTime>_gpehfile:2.lnk

Subfile: <Type><Date>.<StartTime>-<EndTime>_GPEH.lnk
Type Always set to "A" - single Network Element

and single recording/granularity period
start_date YYYYMMDD
start_time HHMM
end_time HHMM
Example:
Main File: A20060122.18:00-18:15_gpehfile:2.lnk
Subfile: A20060122.18:00-18:15_GPEH.lnk
Figure 6-13 GPEH File naming convention
- 222 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
In the RNC events are recorded in the GPEH files until the end of
the ROP or until the file has reached its maximum allowed size.
The GPEH Main files are stored the same directory as the statistics
and recording files, until the maximum allowed space in this
directory has been reached, at which point the oldest files will be
deleted.
NOTE: If the OSS-RC cannot read GPEH file storage location

attribute from the node it will assume the files are stored in the
default location specified by the parameters listed below:
• RbsGpehDefaultFileLocation
• RncDefaultFileLocation
The GPEH binary files are collected by PMS from the NEs using
standard ftp/s-ftp services on TCP ports 20/22. Collection starts 5
minutes after each ROP end. This 5-minute delay allows the node
to close the file with the data reported for the relevant ROP.
Once the main files are collected from the node they are renamed
by PMS and stored in a separate subdirectory for each RNC and
RBS. Sub-folders are sorted per Radio Network Subsystem (RNS)
and each RNS subdirectory is further divided into subdirectories
per RNC and RBS. Subfolders names match names of the Sub-
networks, RNSs and nodes defined by the configuration
management application in OSS-RC.
GPEH FILE STRUCTURE

The Main File contains the following records:
• Header Administrative information about the file.

• Recording Scope of the recording.
• Protocol The name and version of the protocol from which
messages can be recorded (RRC, NBAP, RANAP, RNSAP).
• Link A link from the main file to a GPEH sub file on another
MP.
• Footer Administrative information about the time of normal
termination of the ROP file.
• Error Contains the time and cause of an abnormal
termination of a recording. The error record replaces the footer
record if the file is terminated abnormally.
LZT 123 8297 R1C © 2006 Ericsson - 223 -

Along with a footer or error, the sub file contains the numerous
‘Body’ records, explained below:
• Body The body contains event records. The event record

contains details about inter-node events and RNC-internal
events. It is only the sub file that has a body record.
A detailed explanation of the events can be found in the ‘General

Performance Event Handling RBS (61/1551-HRB 105 102/1 Uen)
document in the ‘Operation and Maintenance/Performance
Management’ directory in the RBS library (CXP 901 0811/2 R6A)
and in the RNC library (CXP 901 2011, from R6A).
An example of GPEH RNC-Internal event id 386 is shown in

Figure 6-14 below.
EVENT
Hour: 22 Minute: 45 Second: 00 Millisecond: 677
Event_ID: 386
Name:
INTERNAL_RADIO_QUALITY_MEASUREMENTS_RNH
C_ID_1: 4241
RNC_ID_1: 41
EVENT_TRIGGER: 9
MEASURED_ENTITY: 4
MEASURED_VALUE: 18
Figure 6-14 GPEH RNC-Internal Event Example
The ‘EVENT TRIGGER’ number relates to one of 52 triggers

listed below:
Event Parameter Trigger No.
EVENT_VALUE_BELOW_NEG_UL_SIR_GUARD 0
EVENT_VALUE_ABOVE_POS_UL_SIR_GUARD 1
EVENT_VALUE_BETWEEN_POS_NEG_UL_SIR_GUARD 2
EVENT_VALUE_DL_POWER_INCREASE 3
EVENT_VALUE_DL_POWER_DECREASE 4
EVENT_VALUE_COMMON_MEASUREMENT_REPORT 5
EVENT_VALUE_LOAD_INCREASE 6
EVENT_VALUE_LOAD_DECREASE 7
EVENT_VALUE_EVENT_TRIGGERED_REPORT 8
EVENT_VALUE_PERIODIC_REPORT 9
EVENT_VALUE_REQUEST_FOR_DL_CODES_FOR_NORMAL_MODE 10
EVENT_VALUE_RELEASE_OF_DL_CODES_IN_NORMAL_MODE 11
EVENT_VALUE_ALLOC_FAILED_EXCESS_RATE_REQUEST 12
EVENT_VALUE_ALLOC_FAILED_NO_SUITABLE_CODE_FREE 13
- 224 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
EVENT_VALUE_REQUEST_FOR_DL_CODES_NORM_TREE_COMP_MODE 14
EVENT_VALUE_REQUEST_FOR_DL_CODES_ALT_TREE_COMP_MODE 15
EVENT_VALUE_RELEASE_OF_DL_CODES_IN_COMP_MODE 16
EVENT_VALUE_EVENT_1A 17
EVENT_VALUE_EVENT_1B 18
EVENT_VALUE_EVENT_1C 19
EVENT_VALUE_EVENT_1D 20
EVENT_VALUE_EVENT_2D 21
EVENT_VALUE_EVENT_2F 22
EVENT_VALUE_ADD_CELL_PROPOSAL 23
EVENT_VALUE_REMOVE_CELL_PROPOSAL 24
EVENT_VALUE_REPLACE_CELL_PROPOSAL 25
EVENT_VALUE_UE_LEAVES_DCH_STATE 26
EVENT_VALUE_CELL_UPDATE_RECEIVED 27
EVENT_VALUE_CELL_UPDATE_CONFIRMED_SENT 28
EVENT_VALUE_RCS_CU_TIMER_EXPIRED 29
EVENT_VALUE_RL_SETUP_OR_ADDITION_RESPONSE_RECEIVED 30
EVENT_VALUE_RL_RESTORE_RECEIVED 31
EVENT_VALUE_RL_FAILURE_RECEIVED 32
EVENT_VALUE_RL_DELETION_RESPONSE_RECEIVED 33
EVENT_VALUE_RCS_WAIT_TIMER_EXPIRED 34
EVENT_VALUE_PROPOSED_HO_TO_GSM 35
EVENT_VALUE_PROPOSED_CC_TO_GSM 36
EVENT_VALUE_IU_RELEASE_COMMAND 38
EVENT_VALUE_RAB_ASSIGNMENT_REQUEST 39
EVENT_VALUE_REQ_FOR_NORMAL_UL_SCRAMBLING_CODE 40
EVENT_VALUE_REQ_FOR_REDUCED_UL_SCRAMBLING_CODE 41
EVENT_VALUE_OTHER_TRIGGER 42
EVENT_VALUE_START_IEF_MEASUREMENTS_PROP 45
EVENT_VALUE_STOP_IEF_MEASUREMENTS_PROP 46
EVENT_VALUE_START_GSM_MEASUREMENTS_PROP 47
EVENT_VALUE_STOP_GSM_MEASUREMENTS_PROP 48
EVENT_VALUE_PROPOSED_IFHO 50
EVENT_VALUE_COMPLETED_IFHO_ATTEMPT 51
The ‘MESURED_ENTITY’ number relates to one of the five

entities listed below:
Measured Entity No.

EVENT_VALUE_UL_SIR_ERROR 0
EVENT_VALUE_DL_TX_CODE_POWER 1
EVENT_VALUE_UL_INTERFERENCE 2
EVENT_VALUE_DL_TX_CARRIER_POWER 3
EVENT_VALUE_NON_HS_POWER 4
The ‘MEASURED-VALUE’ is the estimated percentage Downlink

Power in the cell.
The RRC, NBAP, RANAP and RNSAP inter-node events are

sometimes called ‘protocol events’ since they contain the Layer 3
protocol messages as specified by 3rd Generation Partnership
Project (3GPP). Each L3 protocol message is given an ‘Event_id.
LZT 123 8297 R1C © 2006 Ericsson - 225 -

An example of a RBS-Internal Event 257 (gpehRlsSupStartedEv)

is illustrated in Figure 6-15 below.
EVENT
Hour: 20 Minute: 23 Second: 09 Millisecond: 467
Event_ID: 257
Name: gpehRlsSupStartedEv
Number of cells: 1
RNC cell id 1: 4153
RNC cell id 2: 0
RNC cell id 3: 0
RNC cell id 4: 0
Figure 6-15 GPEH RBS-Internal Event Example
In this example Radio Link Set supervision has started on Cell

4153.
- 226 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
GPEH FILE ANALYSIS USING RED

The Recording and Event Data (RED) subsystem also known as the
‘Recording Events Interface’ (REI) provides the following main
functions:
1. RED listens for notifications from PMS.
2. Once notified RED will extract the ROP file and store it in
either the CTR, UETR or GPEH subdirectory of the parent
directory below:
/var/opt/ericsson/nms_umts_red_reg/downloaded.
3. The user can use the WCDMA Recording File Viewer to

convert these binary ROP files to ASCII text files or tab
delimited files.
An example of these functions being performed for a UETR file

collected from RNC01 is illustrated in Figure 6-16 below.
g
/var/opt/ericsson/nms_umts_red_reg/downloaded RED
Notification from PMS
WCDMA
UETR.bin Recording File UETR.txt
Viewer
/var/opt/ericsson/nms_umts_pms_seg/segment1 PMS
RB/SubNetwork=RNC01
S
/MeContext=RNC01 UETR.bin
Figure 6-16 WCDMA Recording File Viewer
LZT 123 8297 R1C © 2006 Ericsson - 227 -

The Recording File Viewer window is launched from the

‘Performance’ menu in the OSS Network Explorer Graphical User
Interface (GUI).
From the ‘Performance’ drop down menu, choose ‘WCDMA

Recording file viewer…’ as illustrated in Figure 6-17 below.
Figure 6-17 Launching WCDMA Recording file viewer
The Recording File Viewer main window is divided into two panes
with a menu bar along the top of the window as illustrated in
Figure 6-18 below.
Menu Bar
Search Criteria
Search Results
- 228 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
Figure 6-18 Recording file viewer graphical user interface
The top pane is used to select the search criteria. The lower pane is
used to display details of files relevant to the selection criteria
specified. The information in some columns will vary depending
on the type of recording that is being represented.
The main Recording File Viewer window asks the user to input a
number of fields to specify what criteria to use when outputting the
recording results.
The fields are:
• Type *: Select the Type of recording result file you wish to

view:
- CTR
- UETR
- GPEH
You must at least select a Type in order to activate the
search (This field is mandatory as indicated by the asterisk).
The period you wish the recording result file to be viewed is

specified with:
• From: start date/time interval for recording files
• To: end date/time interval for recording files
Log entries can be filtered by date by selecting the earliest log

entries with the ‘From’ option and the latest log entries with the
‘To’ option.
The ‘From’ and ‘To’ dates are expressed as year, month and day.
To change these click on the box. This will display the Calendar
Dialog GUI.
To change the year click on the arrows, to change the month click
on the month drop down menu and select the month required.
Finally to change the day click on the required day on the calendar.
Once the required date has been selected click ‘Apply’.
Select the desired time by clicking on it or highlight it by holding

down the left button on the mouse and type in the desired time.
• NE: Specify the NE (Network Element) from which the

recording file is to be retrieved.
Depending on the Type of recording selected one of the following

fields will be enabled:
LZT 123 8297 R1C © 2006 Ericsson - 229 -

• Performance monitoring ID (for CTR and UETR) or

Node Type (for GPEH)
• Source: The Recording Source is also dependent on the

recording type:
- Cell/RDN for CTR
- IMSI for UETR
- Main Processor Number for GPEH
Click ‘Search’ to view a log of result files. If none of the above

fields are filled in then Search will return all files relevant to the
Type specified.
Figure 6-19 below shows all the fields of the Recording File
Viewer Search criteria.
Specify Network Element
Specify ID for UETR and CTR
Specify Node Type for UETR
- Cell/RDN for CTR

- IMSI for UETR
- Main Processor Number for GPEH
Figure 6-19 Recording File Viewer Search Criteria
The ‘File’ menu contains ‘Open…’, ‘Save’, ‘Open Merge’, ‘Save

Merge’ and ‘Properties’ drop down options as illustrated in Figure
6-20 below.
- 230 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
or
Open recording file in predefined editor
Save (download) file to a predefined path
Parse, convert, and merge group of files
Parse, convert, merge, and save to default filename
View properties of a job
Figure 6-20 File drop down menu options
Click ‘Open…’ to open the selected recording file in the

predefined editor.
This can also be achieved by clicking on the icon in the menu
bar.
Click ‘Save’ to save (download) the selected recording file to

predefined path.
This can also be achieved by clicking on the icon in the menu
bar.
Click ‘Open Merge’ to parse and convert into tab delimited format
a group of recording files selected by the user. Merge these files
together into a single file and download this to the editor set as
default.
Click ‘Save Merge’ to parse and convert a group of recording files

selected by the user into tab delimited format. Merge these files
together into a single file and download this to the editor set as
default and save to filename set as default.
Note: Recommended Editor for Merged Files is a spreadsheet

editor.
LZT 123 8297 R1C © 2006 Ericsson - 231 -

GPEH FILE ANALYSIS USING TEMS

TEMS Visualization quickly displays a large volume of data about
calls made on an Ericsson WCDMA network. The enhanced
capabilities in TEMS Visualization will identify quality problems
and congestion by switching between WCDMA and GSMA modes.
The effects of recent network changes and to get a better
understanding of radio network behaviour. The problem spots, root
causes will be identified and the trouble shooting can start.
Following is a list of things that can be done with TEMS

Visualization:
• Mode switch between WCDMA and GSM
• Load multiple Recording Output Periods (ROP) files sets

into one database
• View and compare RF measurements, messages and events

for calls including the flow of handovers for WCDMA
networks
• See the WCDMA network infrastructure of cells on a map,

including serving cells, neighbors, and the flow of a call
among cells
• See the events, radio environment and graphical position of

serving cells
• Identify abnormal events such as drops, blocks and

handover failures
• Identify issues faced by subscribers by analyzing the data
The operations are supported from system version OSS-RC2.2 and

the UMTS Radio Access Network P3 by TEMS Visualization.
- 232 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
Setting up TEMS Visualization for analysis

The workflow for the setup and the analysis can be visualized in
the figure below.
Figure 6-21 Workflow for analysis of the GPEH log files
1. During this first phase the different data files should be

imported through the import wizard in order to create a
database
The cell files are showing cell infrastructure of the tested area and
should be in the format of .cel or .xml.
TEMS Visualization uses the GPEH log files that are created with a
performance recording in the OSS and the log files should have a
.bin or a .bin.gz filename extension. The folders where the GPEH
files are stored will be asked for.
The user can choose to filter some of the calls and/or call messages
by the WCDMA Call filter.
LZT 123 8297 R1C © 2006 Ericsson - 233 -

2. If the user has already created a database, the first step is

skipped by just loading the database.
3. The maps are imported. They can be MapInfo tables (.tab),

MapInfo workspace (.mws) or MapInfo geoset (.gst)
Figure 6-22 TEMS Visualization User interface with all files loaded
The TEMS Visualization analysis

Once a log file has been processed and the data is in a database, all
calls can be selected in order to be analyzed. The calls can be
searched through criteria or calls analyzed for a specific cell.
Figure 6-21 shows the workflow and as shown, there are three
major paths to follow. Normally all the pilot pollution should be
analyzed first, secondly the missing neighbors and last the call
analysis part.
- 234 - © Ericsson 2006 LZT 123 8297 R1C

6 UETR and GPEH
In the call analysis part, the user can either display the data or use
the Analysis tools in TEMS Visualization.
By displaying the data, call messages with the details, RF

measurements, the phone data, cell data, all will be visualized on
the map geographically.
By using the Analysis Tools, the multiple data types can be viewed
as well as comparing different multiple calls data. The user can step
through calls and apply different filters to the data.
The analysis is not further discussed in this course.
Objectives

in order to improve the BLER and throughput

to integrity
LZT 123 8297 R1C © 2006 Ericsson - 235 -

Intentionally Blank
- 236 - © Ericsson 2006 LZT 123 8297 R1C

7 Abbreviations
7 Abbreviations
LZT 123 8297 R1C © 2006 Ericsson - 237 -

Intentionally Blank
- 238 - © Ericsson 2006 LZT 123 8297 R1C

7 Abbreviations
AAL2 ATM Adaptation Layer type 2

ACK Acknowledgement
AICH Acquisition Indicator Channel
ALCAP Access Link Control Application Part
AM Acknowledged Mode
AMR Adaptive MultiRate speech codec
AP Access Preamble
ARQ Automatic Repeat Request
AS Access Stratum
AS Active Set
ASC Access Service Class
ASC Antenna System Controller
ASE Air Interface Speech Equivalents
ATM Asynchronous Transfer Mode
BCCH Broadcast Control Channel
BCH Broadcast Control Channel
BER Bit Error Rate
BH Busy Hour
BLER Block Error Rate
CM Connection Management
CM Configuration Management
CN Core Network
CPCH Common Packet Channel
CPICH Common Pilot Channel
CR Change Request
CRC Cyclic Redundancy Check
CRNC Controlling RNC
CS Circuit Switched
CTCH Common Traffic Channel
CTR Cell Traffic Recording
DCA Dynamic Channel Allocation
DCCH Dedicated Control Channel
DCFE Dedicated Control Functional Entity
DCH Dedicated Channel
DDM Discrete distributed measurements
DL Downlink
DPCCH Dedicated Physical Control Channel
DPCH Dedicated Physical Channel
DRAC Dynamic Resource Allocation Control
DRNC Drift RNC
DRNS Drift RNS
DRX Discontinuous Reception
DSCH Downlink Shared Channel
DTCH Dedicated Traffic Channel
LZT 123 8297 R1C © 2006 Ericsson - 239 -

DTX Discontinuous Transmission

FACH Forward Access Channel
FN Frame Number
FP Frame Protocol
ID Identifier
GP General Processor
GPEH General Performance Event Handling
GSM Global System for Mobile Communication
GUI Graphical User Interface
HO Handover
HW Hard Ware
IE Information element
IFHO Intra Frequency HandOver
IMEI International Mobile Equipment Identity
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IRAT Inter Radio Access Technology
KPI Key Performance Indicators
KSI Key Set Identifier
L1 Layer 1
L2 Layer 2
L3 Layer 3
LA Location Area
MAC Medium Access Control
MAC The Message Authentication Code included in AUTN,
computed using f1
MCC Mobile Country Code
MM Mobility Management
MNC Mobile Network Code
MO Mobile Originating Call
MO Managed Object
MP Main Processor
MR Measurement Report
MS Mobile Station
MSC Mobile services Switching Centre
MT Mobile Terminal
MTC Mobile Terminated Call
NAS Non Access Stratum
NBAP Node B Application Protocol
NE Network Element
OSS-RC Operation Support System – Radio Core
PCCH Paging Control Channel
P-CCPCH Primary Common Control Physical Channel
PCH Paging Channel
PDF Probability Density Function
PDSCH Physical Downlink Shared Channel
- 240 - © Ericsson 2006 LZT 123 8297 R1C

7 Abbreviations
PDU Protocol Data Unit

PICH Paging Indicator Channel
PLMN Public Land Mobile Network
PNFE Paging and Notification Control Functional Entity
PPP
PRACH Physical Random Access Channel
PS Packet Switched
PSCH Physical Synchronisation Channel
PSTN Public Switched Telephone Network
P-TMSI Packet Temporary Mobile Subscriber Identity
QoS Quality of Service
RA Routing Area
RAB Radio Access Bearer
RACH Random Access Channel
RAI Routing Area Identity
RAN Radio Access Network
RANAG Radio Access Network Aggregator
RANAP Radio Access Network Application Part
RB Radio Bearer
RBS Radio Base Station
RFE Routing Functional Entity
RL Radio Link
RLC Radio Link Control
RLS Radio Link Set
RNC Radio Network Controller
RND Radio Netwrok Design
RNS Radio Network Subsystem
RNSAP Radio Network Subsystem Application Part
RNTI Radio Network Temporary Identifier
ROP Recording Output Periods
RRC Radio Resource Control
RSCP Received Signal Code Power
RSSI Received Signal Strength Indicator
SCCP Signalling Connection Control Part
S-CCPCH Secondary Common Control Physical Channel
SCH Synchronization Channel
SDM Statistical Data Mart
SDU Service Data Unit
SF Spreading Factor
SGSN Serving GPRS Support Node
SHCCH Shared Control Channel
SIB System Information Block
SIR Signal to Interference Ratio
SMS Short Message Service
SRNC Serving RNC
SRNS Serving RNS
LZT 123 8297 R1C © 2006 Ericsson - 241 -

TCP TEMS CellPlanner

TEMS Test Moile System
TF Transport Format
TFC Transport Format Combination
TFCI Transport Format Combination Indicator
TFCS Transport Format Combination Set
TFS Transport Format Set
TME Transfer Mode Entity
TM Transparent Mode
TMD Transparent Mode Data
TMSI Temporary Mobile Subscriber Identity
TPC Transmit Power Control
Tr Transparent
TrCH Transport Channel
TTI Transmission Time Interval
Tx Transmission
UARFCN UMTS Absolute Radio Frequency Channel Number
UE User Equipment
UEA UMTS Encryption Algorithm
UETR User Equipment Traffic Recording
UIA UMTS Integrity Algorithm
UL Uplink
UM Unacknowledged Mode
UMD Unacknowledged Mode Data
UMTS Universal Mobile Telecommunication System
UNACK Unacknowledgement
URA UTRAN Registration Area
UTRA UMTS Terrestrial Radio Access
UTRAN UMTS Terrestrial Radio Access Network
VLR Visitor Location Register
WCDMA Wideband Code Division Multiple Access
- 242 - © Ericsson 2006 LZT 123 8297 R1C

0Appendix A: Cell Parameter and Configurations
Appendix A: Cell Parameter and Configurations
LZT 123 8297 R1C © 2006 Ericsson - 243 -

Intentionally Blank
- 244 - © Ericsson 2006 LZT 123 8297 R1C

HW configuration
Cell Geographical Antenna antenna Antenna Feeder Feeder

name height Height gain azimuth Antenna tilt length type ASC Transmission RNC
cell1 10 30 18 300 2 EDT 35 7/8" YES one E1 RNC1
cell2 50 25 18 240 4 MDT 30 7/8" YES one E1 RNC4
cell3 5 25 18 120 2 EDT + 2 MDT 30 7/8" YES one E1 RNC1
cell4 2 25 18 120 0 DT 30 7/8" YES one E1 RNC1
cell5 25 25 18 35 0 DT 30 7/8" NO one E1 RNC4
cell10 25 25 18 0 0 DT 30 7/8" NO one E1 RNC2
LZT 123 8297 R1C © Ericsson 2006 - 245 -

Cell Parameters, neighbouring cells
Cell name Ncell#1 Ncell#2 Ncell#3 Ncell#4 Ncell#5 Ncell#6 Ncell#7 Ncell#8 Ncell#9 Ncell#10 Ncell#11 Ncell#12 Ncell#13 Ncell#14
cell1 cell3 cell2 cell4 cell5 cell6 cell10 cell7 cell15 cell49 cell38 cell50 cell40 cell31
cell2 cell6 cell7 cell8 cell9 cell10 cell4 cell3 cell1
cell3 cell4
cell4 cell1 cell3 cell2 cell15 cell49 cell38 cell50 cell40 cell31
cell7 cell1 cell2 cell3 cell6 cell5 cell9 cell20 cell28 cell41 cell7 cell29 cell21 cell26 cell45
cell8 cell2 cell3 cell21 cell26 cell14 cell22 cell41
cell9 cell5 cell2 cell22 cell7 cell41 cell26
cell10 cell1 cell2 cell46 cell26 cell14 cell22 cell20
- 246 - © Ericsson 2006 LZT 123 8297 R1C

Cell Parameters
primary primary max max Maximum
Cell Cpich Sch secondary Fach1 Fach2 aich pch pich Transmission maxTx qualMeas
name SC Power bchPower Power SchPower Power Power Power Power Power Power PowerUl Quantity
cell1 368 306 -31 -18 -35 18 15 -6 -4 -7 405 24 2
cell2 376 315 -31 -18 -35 18 15 -5 -4 -7 414 24 2
cell3 384 309 -31 -18 -35 18 15 -6 -4 -7 408 24 2
cell4 152 318 -31 -18 -35 18 15 -6 -4 -7 417 24 2
cell5 160 325 -31 -18 -35 18 15 -4 -2 -5 410 24 2
cell6 168 311 -31 -18 -35 18 15 -6 -4 -7 410 24 2
cell7 441 306 -31 -18 -35 18 15 -4 -2 -5 405 24 2
cell8 449 275 -31 -18 -35 18 15 -5 -4 -7 404 24 2
cell9 272 305 -31 -18 -35 18 15 -6 -4 -7 404 24 2
cell10 457 306 -31 -18 -35 18 15 -5 -4 -7 405 24 2
ase comp
Cell qRx sInter sIntra sRat Tre Individual ase ase UlAdm beMargin beMargin Mode
name qHyst1 qHyst2 qQualMin LevMin Search Search Search Selection Offset DlAdm UlAdm Offset AseDl AseUl Adm
cell1 2 2 -18 -115 0 0 -32 1 0 300 200 40 100 20 15
cell2 2 2 -18 -115 0 0 -32 1 0 300 200 40 100 20 15
cell3 2 2 -18 -115 0 0 -32 1 0 300 200 40 100 20 15
cell4 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15
cell5 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15
cell6 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15
cell7 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15
cell8 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15
cell9 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15
cell10 2 2 -18 -115 0 0 -32 1 0 240 160 40 100 20 15
LZT 123 8297 R1C © 2006 Ericsson - 247 -

Pwr max min Constant max power power Aich preamble

Cell dlCode Pwr Adm sf8 sf32 sf16 Pwr Pwr Pwr Pwr release Value Preamble Offset Offset Transmission Retrans
name Adm Adm Offset Adm Adm Adm Max Max Hyst Offset AseDl Cprach Cycle P0 Ppm Timing Max
cell1 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
cell2 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
cell3 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
cell4 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
cell5 70 65 35 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
cell6 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
cell7 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
cell8 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
cell9 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
cell10 70 75 15 2 12 6 48 0 100 5 3 -27 4 3 -4 4 8
Cell sccpchOffset sccpchOffset beMargin beMargin pOffset pOffset usedFreq usedFreq

name spreadingFactor (FACH) (PCH) minPwrRl DlPwr DlCode 1Fach 3Fach Thresh2dEcno Thresh2dRscp
cell1 64 0 20 -150 10 2 0 0 -11 -97
cell2 64 0 20 -150 10 2 0 0 -11 -97
cell3 64 0 20 -150 10 2 0 0 -11 -97
cell4 64 0 20 -150 10 2 0 0 -11 -97
cell5 64 0 20 -150 2 2 0 0 -11 -97
cell6 64 0 20 -150 10 2 0 0 -11 -97
cell7 64 0 20 -95 10 2 0 0 -11 -97
cell8 64 0 20 -150 10 2 0 0 -11 -97
cell9 64 0 20 -150 10 2 0 0 -11 -97
cell10 64 0 20 -150 10 2 0 0 -11 -97
- 248 - © Ericsson 2006 LZT 123 8297 R1C

Appendix B: Formulas for Key Performance Indicators
Appendix B: Formulas for Key Performance

Indicators
LZT 123 8297 R1C © Ericsson 2006 - 249 -

Intentionally Blank
- 250 - © Ericsson 2006 LZT 123 8297 R1C

KEY PERFORMANCE INDICATORS ................................................253
ACCESSIBILITY ................................................................................255
SERVICE SUCCESS SETUP RATE ............................................................ 255
IDLE MODE .................................................................................................. 257
RANDOM ACCESS ...................................................................................... 257
ADMISSION CONTROL ............................................................................... 258
RETAINABILITY ................................................................................260
DROPPED CALL RATE................................................................................ 260
MINUTES PER DROP .................................................................................. 261
HANDOVER FAILURE RATE ....................................................................... 262
IRAT HANDOVER......................................................................................... 264
CONGESTION .............................................................................................. 265
OTHER REASONS ....................................................................................... 265
INTEGRITY ........................................................................................267
BLER............................................................................................................. 267
THROUGHPUT............................................................................................. 267
LZT 123 8297 R1C © 2006 Ericsson - 251 -

Intentionally Blank
- 252 - © Ericsson 2006 LZT 123 8297 R1C

KEY PERFORMANCE INDICATORS

In the sections that follow, UE radio Connection Configuration (UeRc) is
used in various equations. The following table shows the mapping of
UeRc to radio connection configuration.
UeRc Radio Connection Configuration
0 Idle
1 RRC Only
2 Speech (12,2/12,2 kbps)
3 CS data (64/64 kbps)
4 Packet (RACH/FACH)
5 Packet (64/64 kbps)
8 Streaming CS data (57,6/57,6 kbps)
9 Speech (12,2/12,2 kbps) + Interactive Packet (0/0 kbps)
11 RRC (13,6/13,6 kbps)
12 Preconfigured Speech (12,2/12,2 kbps)
13 PS Streaming (16/64 kbps) + Interactive Packet (8/8 kbps)
14 CS Data (64/64 kbps) + Interactive Packet (8/8 kbps)
15 PS Interactive (64/HS kbps)
16 PS Interactive (384/HS kbps)
18 PS Interactive (128/128 kbps)
19 Speech (12,2/12,2 kbps) + Interactive Packet (64/HS kbps)
20 Speech (12,2/12,2 kbps) + Interactive Packet (384/HS kbps)
21 PS Interactive URA-PCH
23 Speech (12,2/12,2 kbps) + PS Streaming (128/16 kbps) + Interactive Packet
(8/8 kbps)
24 Speech (12,2/12,2 kbps) + PS Streaming (16/128 kbps) + Interactive Packet
(8/8 kbps)
25 PS Interactive EUL/HS
26 PS Interactive (64/64 kbps) + Interactive Packet (64/64 kbps)
27 Speech (12,2/12,2 kbps) + PS Interactive (64/64 kbps) + Interactive Packet
(64/64 kbps)
33 Speech AMR (7,95/7,95 kbps)
LZT 123 8297 R1C © 2006 Ericsson - 253 -


39 Interactive Packet (64/128 kbps) + Interactive Packet (64/128 kbps)
- 254 - © Ericsson 2006 LZT 123 8297 R1C

ACCESSIBILITY
Accessibility is defined as the ability of a user to obtain requested service
from the system. In WCDMA RAN, this metric can be measured by
calculating the product of the probability of RRC Connection success and
the probability of RAB establishment success. This metric can be
calculated per cell and per RNC for all supported services. The RNC KPI
is calculated by aggregating all the cell counters to RNC level and then
applying the formula.
The service Success setup rate will give the 1st category KPI. If the rate is
low then the 2nd category KPi should be looked into further
SERVICE SUCCESS SETUP RATE

In this section all formulas are from an Utrancell perspective, if not
otherwise stated.
Speech
⎛ pmTotNoRrcConnectReqCsSucc ⎞ ⎛ pmTotNoRabEstablishSuccessSpeech ⎞
100 × ⎜⎜ ⎟⎟ × ⎜⎜ ⎟⎟
⎝ pmTotNoRrcConnectReqCs ⎠ ⎝ pmmTotNoRabEstablishAttemptSpeech ⎠
where directed-retry is counted as access failure and inter-frequency load

sharing is not considered.
Alternatively, one can exclude directed-retry to GSM from the RAB
establishment attempt, so that it is not counted as access failure on
WCDMA RAN, and use the following equation.
⎛ pmTotNoRrcConnectReqCsSucc ⎞ ⎛ pmTotNoRabEstablishSuccessSpeech ⎞
100 × ⎜⎜ ⎟⎟ × ⎜⎜ ⎟⎟
⎝ pmTotNoRrcConnectReqCs ⎠ ⎝ pmmTotNoRabEstablishAttemptSpeech - pmNoDirRetryAtt ⎠
Circuit-Switched 64
⎛ pmTotNoRrcConnectReqCsSucc ⎞ ⎛ pmTotNoRabEstablishSuccessCS64 ⎞
100 × ⎜⎜ ⎟⎟ × ⎜⎜ ⎟⎟
⎝ pmTotNoRrcConnectReqCs ⎠ ⎝ pmmTotNoRabEstablishAttemptCS64 ⎠
LZT 123 8297 R1C © 2006 Ericsson - 255 -

Circuit-Switched 57
⎛ pmTotNoRrcConnectReqCsSucc ⎞ ⎛ pmTotNoRabEstablishSuccessCS57 ⎞
100 × ⎜⎜ ⎟⎟ × ⎜⎜ ⎟⎟
⎝ pmTotNoRrcConnectReqCs ⎠ ⎝ pmmTotNoRabEstablishAttemptCS57 ⎠
Packet-Switched Data Streaming
⎛ pmTotNoRabEstablishSuccessPacketStream + pmRabEstablishSuccessPacketStream128 ⎞
100 × (Y ) × ⎜⎜ ⎟⎟
⎝ pmTotNoRabEstablishAttemptPacketStream + pmRabEstablishAttemptPacketStream128 ⎠
pmTotNoRrcConnectReqPsSuccess
Where Y =
pmTotNoRrcConnectReqPs
Packet-Switched Data Interactive
⎛ ⎞
100 × (Y ) × ⎜⎜
pmTotNoRabEstablishSuccessInteractive
⎟⎟
⎝ pmTotNoRabEstablishAttemptPacketInteractive + HS1 _ HardHO _ Flow ⎠
Where
pmTotNoRrcConnectReqPsSuccess
Y=
HS1_HardHO_Flow =
⎛ pmNoOutgoingHsHardHoAttempt - pmNoHsHardHoReturnOidSource ⎞
⎜⎜ ⎟⎟
⎝ - pmNoIncomingHsHardHoAttempt - pmNoHsHardHoReturnOldChTarget ⎠
Packet-Switched Data Interactive HS
⎛ pmTotNoRrcConnectReqPsSucc ⎞ ⎛ pmTotNoRabEstablishSuccessPacketInteractiveHs ⎞
100 × ⎜⎜ ⎟⎟ × ⎜⎜ ⎟⎟
⎝ pmTotNoRrcConnectReqPs ⎠ ⎝ pmTotNoRabEstablishAttemptPacket InteractiveHS ⎠
Note that if the HS cell is on a separate frequency then the RRC

contribution to the formula might be small or even zero, depending on
parameter settings.
- 256 - © Ericsson 2006 LZT 123 8297 R1C

IDLE MODE
otherwise stated.
Paging
Successful First and Repeated Page attempts of total number of first
attempts, Paging success rate in a MSC
⎛ NPAG1RESUCC + NPAG2RESUCC ⎞
100 × ⎜ ⎟
⎝ NPAG1GLTOT + NPAG1LOTOT ⎠
Paging intensity per cell in a RNC (if RNC, LA and RA consist of exact
same cells):
pmCnInitPagingToIdle UeLa + pmCnInitPa gingToIdle UeRa + pmCnInitPagingToIdle Ue

measurement period × total number of cells in that RNC
MP Load
RRC connection rejection rate due to module MP load control for a cell
could be found in the following formula:
pmNoRejRrcConnMpLoad C
×100%
pmTotNoRrcConnectReq - pmNoLoadSh aringRrcConn
RANDOM ACCESS
otherwise stated.
Preamble detections
Number/percentage of false detections, which is the case that
preamble is detected but there is no enough energy in message part,
due to noise on the random access channel for a carrier (it could be
due to loss of AICH, wrong recognition of preamble or loss of
RACH message part after the UE sends message out):
pmNoPreambleFalseDetection or
LZT 123 8297 R1C © 2006 Ericsson - 257 -

pmNoPreambleFalseDetection
×100%
pmPositiveMessages
AICH detections
Percentage of getting AICH but no RRC connection setup,
excluding cell (re)selection:
No of AICH_ACK - No of RRC connection setup - No of cell (re)selection during RRC establishment

× 100%
No of AICH_ACK
ADMISSION CONTROL
otherwise stated.
DL transmission carrier power

Average DL TX power for a cell-carrier:
102
⎡ ⎛ i ⎞⎤
∑ ⎢⎣ pmTransmittedCarrierPower
i =0
i × ⎜ ⎟⎥
⎝ 2 ⎠⎦
102
∑ pmTransmittedCarrierPower
i =0
i
UL RSSI
Average UL RSSI for a cell-carrier:
62
∑ [pmAverageRssi
i =0
i × (0.5 × i − 110.5 )]
62
∑ pmAverageRssi
i =0
i
ASE usage
The formulas for checking the average usage of ASE in the
downlink and uplink for a cell can be found below.
pmSumOfSampAseUl
Average UL ASE for a cell:
pmNoOfSampAseUl
- 258 - © Ericsson 2006 LZT 123 8297 R1C

pmSumOfSampAseDl
Average DL ASE for a cell:
pmNoOfSampAseDl
Code allocation
Code allocation failure for SFn, where n is the spreading factor for
a cell could be found in the following formula (as an example the
SF128 was used):
×100%
Compressed mode
How many users are in compressed mode? Well the average
number of user in compressed mode for a cell:
pmSumCompMode
pmSampesCompMode
Loadsharing
In the following equations, RRC connection attempts are not
corrected for redirections due to emergency calls. The counter
pmNoOfRedirectedEmergencyCalls can be used to estimate the
percentage of emergency call redirections on RNC level.
Ratio between RRC connection returning and redirection due to

load sharing for a cell:
pmNoLoadSharing RrcConn
To consider redirections due to inter-frequency load sharing, when

the functionality is enabled, an example of equation is given below.
A correction is then made to eliminate duplicated CS RRC
connection attempts resulting from load sharing redirection orders.
An equivalent formula can be defined to calculate all services.
The failures can be observed by the successful rate of directed retry

to GSM for a cell:
pmNoDirRetrySuccess
×100%
pmNoDirectedRetryAtt
LZT 123 8297 R1C © 2006 Ericsson - 259 -

RETAINABILITY
Retainability is defined as the ability of user to retain its requested service
once connected for the desired duration. This metric can be calculated per
cell and per RNC for all supported services. In the following subsections,
the formula for drop rate is given per UtranCell. The user can calculate the
retainability by subtracting the following numbers from 100%.
The drop rate will give the 1st category KPI. If the rate is low then the 2nd
category KPI should be looked into further.
DROPPED CALL RATE

The dropped calls are for originating and terminating calls.
Speech
pmNoSystemRab Re leaseSpeech
100 ×
( pmNoNormalRab Re leaseSpeech + pmNoSystemRab Re leaseSpeecch)
Circuit-switched 64
100 ×
( pmNoNormalRab Re leaseCs 64 + pmNoSystemRabReleaseCs64 )
Circuit-switched Streaming
pmNoSystemRabReleaseCsStream
100 ×
( pmNoNormalRab Re leaseCsStream + pmNoSystemRabReleaseCsStream )
Packet Switched data Streaming

pmNoSystemRab Re leasePacketStream + pmNoSystemRab Re leasePacketStream128
100 ×
( pmNoNormalRab Re leasePacketStream + pmNoSystemRab Re leasePacketStream + pmNosystemRab Re leasePacketStream128)
Packet Switched data Interactive

The drop rate of PS Interactive from user perspective can be approximated
by the product of Packet-Switched system release rate and the access
failure rate. That is, a user can complete its packet session completely if it
can access the system even though there may be interruption during the
- 260 - © Ericsson 2006 LZT 123 8297 R1C

session. In this approximation, the assumption is that the application

retries once after abnormal release. The Packet-Switched drop rate per
UtranCell for all PS interactive services is given by
Shows dropped call for all types of packet calls, including HSDPA calls.
pmNoSystemRab Re leasePacket
100 ×
( pmNoNormalRab Re leasePacket + pmNoSystemRab Re leasePacket )
MINUTES PER DROP
Speech
Sp _ U _ User
100 × × number of minutes
pmNoSystemRab Re leaseSpeecch
Circuit-switched CS64
Cs 64 _ U _ User
100 × × number of minutes
pmNoSystemRab Re leaseCs64
Circuit-switched Streaming
Cs57 _ U _ User
100 × × No of minutes
pmNoSystemRab Re leaseCsStream
Packet Switched data Streaming

Pstr _ P8 _ U _ User
pmNoSystem Rab Re leasePacke tStream + pmNoSystem Rab Re leasePacke tStream128
Packet Switched data Interactive

PIntDCH _ U _ User + PIntHs _ U _ User + PIntFach _ U _ User
pmNoSystem Rab Re leasePacket
Packet Switched data Interactive HS

PIntHs _ U _ User
pmNoSystem Rab Re leaseHs
LZT 123 8297 R1C © 2006 Ericsson - 261 -

HANDOVER FAILURE RATE

The following formula shows the failure rate for RL
addition/replacement to active set
pmNoTimesCellFailAddToActSet
100 ×
( pmNoTimesCellFailAddToActSet + pmNoTimesRlAddToActSet )
HS Cell Change
The following metric measures the success rate for HS Cell Change
in target cell
pmHsCcSuccess
100 ×
pmHsCcAttempt
OUT of synch
Shows fraction of drop due to uplink Out of Sync reason.
100 ×
( pmNoSys Re lSpeechULSynch)
Missing neighbours
The following formula shows the fraction of drops due to HO
action when a valid or non-valid cell cannot be added to active set.
This also includes drops due to missing neighbour.
100 ×
shows fraction of speech drop due to HO action when a valid or

non-valid cell cannot be added to active set. This includes also drop
due to missing neighbour.
100 ×
Shows fraction of speech drop due to missing neighbour reason

when a non-valid cell cannot be added to active set.
- 262 - © Ericsson 2006 LZT 123 8297 R1C

100 ×
Soft handover overhead

In order to find to large handover areas in the system and to find
out the average number of RL per user the following formula
should be used:
pmSum < RAB > RabEstablish

∑ pmSamples < RAB > RabEstablish
UtranCell counters
SHOoverhead = allcells
pmSumRabEstablish
pmSamplesRabEstablish RNC counters
INTER-FREQUENCY HANDOVER
Speech
Drop due to IFHO failure for speech: Outgoing IFHO failure when
UE failed to return to present active set.
100 ×
The following formula might give slightly lower result:
100 ×
⎛ pmSuccNonBlindInterFreqHoCsSpeech12 + pmFailNonBlindInterFreqHoRevertCsSpeech12 + ⎞
⎜⎜ ⎟⎟
⎝ pmFailNonBlindInterFreqHoFailRevertCsSpeech12 ⎠
CS Services
Drop due to IFHO failure for CS except speech: Outgoing IFHO failure
when UE failed to return to present active set.
pmFailNonBlindInterFreqHoFailRevertCsConversational
100 ×
pmAttNonBlindInterFreqHoCsConversational
LZT 123 8297 R1C © 2006 Ericsson - 263 -

PS Services
Drop due to IFHO failure for PS less or equal to 64 kbps: Outgoing IFHO
failure when UE failed to return to present active set.
pmFailNonBlindInterFreqHoFailRevertPsInteractiveLess64
100 ×
Drop due to IFHO failure for PS greater than 64 kbps: Outgoing IFHO
failure when UE failed to return to the present active set.
pmFailNonBlindInterFreqHoFailRevertPsInteractiveGreater64
100 ×
Drop due to IFHO failure for PS streaming and others: Outgoing IFHO
failure when UE failed to return to the present active set.
100 ×
IRAT HANDOVER
Speech
UtranCell and target GSM cell for speech calls. The formula is considering
the GsmRelation.
pmNoSucces sOutIratHo Speech

100 ×
pmNoAttOut IratHoSpee ch
CS57
UtranCell and target GSM cell for CS streaming calls. The formula is
100 ×
- 264 - © Ericsson 2006 LZT 123 8297 R1C

IRAT Handover Multi-RAB

UtranCell and target GSM cell for Multi-RAB calls. The formula is
100 ×
pmNoAttOut IratHoMulti
IRAT Handover Packet Data

The following metric measures cell change failure rate between UtranCell
and target GSM cell for PS calls when the UE successfully returns to
UtranCell. The formula is considering the GsmRelation.
pmNoOutIra tCcReturnO ldCh

100 ×
pmNoOutIra tCcAtt
CONGESTION
Shows fraction of speech drop due to congestion action
100 ×
( pmNoOfTermSpeechCong )
Shows fraction of video call drop due to congestion action
100 ×
( pmNoOfTermCsCong )
( pmNoNormalRab Re leaseCs64 + pmNoSystemRab Re leaseCs64)
OTHER REASONS
Shows fraction of speech drop due to other reasons than HO action, UL
out of sync and congestion.
100 ×
( pmNoSystemRab Re leaseSpeech − pmNoSys Re lSpeechSoHo − pmNoSys Re lSpeechULSynch − pmNoOfTermSpeechCong )
Transport network
Shows percentage of rejected incoming/outgoing Aal2 connection
establishment requests on transport network.
LZT 123 8297 R1C © 2006 Ericsson - 265 -

100 ×
(Y + X )
( pmSuccInConns Re mote + pmSuccOutConns Re mote + Y + X )
Where
X = pmUnSuccOutConnsLocal + pmUnSuccOutConnsRemote
Y = pmUnSuccInConnsLocal + pmUnSuccInConnsRemote
- 266 - © Ericsson 2006 LZT 123 8297 R1C

INTEGRITY
Integrity is defined as the ability of a user to receive the requested service
at desired quality.
The drop rate will give the 1st category KPI. If the rate is low then the 2nd
category KPI should be looked into further.
BLER
The method for finding worst performing cells is based on top to
down analysis. Initially worst 10-15 performing cells can be
identified based on the Uplink Block Error rate before combining.
pmFaultyTransportBlocksBcUL
100 ×
The Formula below shows Block Error rate after uplink combining
at RNC level. That means blocks in RNC coming from different
legs in SHO are compared, each radio connection.
pmFaultyTransportBlocksAcUl[UeRc]
100 ×
pmTransportBlocksAcUl[UeRc]
UeRc stands for different RAB’s which can be found in the table in
the beginning of this Appendix
THROUGHPUT
Packet-Switched DCH/FACH Interactive average throughput

The following equation measures the Average Throughput for PS
interactive DCH/FACH.
Counters for small packets, pmSentPacketData1 and

pmTotalPacketDurationHs are not included in the formula as there
is a constant one-way delay for each packet affecting latency for
the small packets, which gives a worse measured performance than
user perceived performance, if these counters are used.
(pmSentPacketData2/1000) + pmSentPacketData3 + pmSentPacketData4

8000 ×
pmTotalPacketDuration2 + pmtotalPacketDuration3 + pmTotalPacketDuration4
LZT 123 8297 R1C © 2006 Ericsson - 267 -

The counters in the formula above is from the RNCFuntion.
Packet-Switched Interactive HS average throughput

The following equation measures the Average Throughput for PS
interactive HS. Counters for small packets, pmSentPacketDataHs1,
pmSentPacketDataHs2, pmTotalPacketDurationHs1 and
pmTotalPacketDurationHs2 are not included in the formula as
there is a constant one-way delay for each packet affecting latency
for the small packets, which gives a worse measured performance
than user perceived performance, if these counters are used.
(pmSentPacketDataHs3 + pmSentPacketDataHs4
8000 ×
pmTotalPacketDurationHs3 + pmTotalPacketDurationHs4
Packet-Switched DCH/FACH Interactive Retransmission Rate

The following equation measures the retransmission rate for PS
interactive DCH/FACH.
(pmSentPacketData1/1000) + (pmSentPacketData2/1000) + pmSentPacketData3 + pmSentPacketData4
(pmSentPacketDataIncRetrans1/1000) + (pmSentPacketDataIncRetrans2/1000) + pmSentPacketDataIncRetrans3 + pmSentPacketDataIncRetrans4
Packet-Switched Interactive HS Retransmission Rate

The following equation measures the retransmission rate for PS
interactive HS.
(pmSentPacketDataHs1/1000) + (pmSentPacketDataHs2/1000) + pmSentPacketDataHs3 + pmSentPacketDataHs4
(pmSentPacketDataIncRetransHs1/1000) + (pmSentPacketDataIncRetransHs2/1000) + pmSentPacketDataIncRetransHs3 + pmSentPacketDataIncRetransHs4
RAB throughput excluding HSDPA

Average throughput per cell and RAB in the DL, excluding
HSDPA:
pmDlTrafficVolume < RAB >

Throughput =
⎛ pmSum < RAB > RabEstablish ⎞
⎜⎜ * ROP sec ⎟⎟
⎝ pmSamples < RAB > RabEstablish ⎠
- 268 - © Ericsson 2006 LZT 123 8297 R1C

RAB efficiency excluding HSDPA

The RAB efficiency can also be checked
Actual Bitrate per RAB

RABEfficiency =
Nominal Bitrate per UeRc =x
LZT 123 8297 R1C © 2006 Ericsson - 269 -

Intentionally Blank
- 270 - © Ericsson 2006 LZT 123 8297 R1C

Appendix C: Predefined Statistics Profiles Counters
Appendix C: Predefined Statistics Profiles

Counters
LZT 123 8297 R1C © Ericsson 2006 - 271 -

Intentionally Blank
- 272 - © Ericsson 2006 LZT 123 8297 R1C

SUMMARY .........................................................................................275
LZT 123 8297 R1C © 2006 Ericsson - 273 -

Intentionally Blank
- 274 - © Ericsson 2006 LZT 123 8297 R1C

SUMMARY
There are only two predefined scanners in the RNC. The first, PREDEF.PRIMARY.STATS,
contains only the most important RNC radio network counters. These counters are typically used to
calculate high-level KPIs. The second, PREDEF.SECONDARY.STATS, contains important
counters, typically used for troubleshooting.
Both PRIMARY and SECONDARY scanners are initially active on startup of the RNC
Scanner Performance Counter Name

Management Areas
Primary Admission pmNoOfNonHoReqDeniedCs
Scanner
pmNoOfNonHoReqDeniedInteractive
pmNoOfNonHoReqDeniedPsStreaming
pmNoOfNonHoReqDeniedSpeech
pmNoOfNonHoReqDeniedHs
pmNoOfNonHoReqDeniedEul
pmNoOfNonHoReqDeniedPsStr128
Admission Monitoring -
Cell Availability pmCellDowntimeAuto
pmCellDowntimeMan
pmHsDowntimeMan
pmHsDowntimeAuto
pmEulDowntimeMan
pmEulDowntimeAuto
Cell Update -
Channel Switching pmChSwitchFachIdle
Channel Quality pmFaultyTransportBlocksAcUl
pmTransportBlocksAcUl
Code Control -
Compressed Mode -
Congestion pmTotalTimeDlCellCong
pmTotalTimeUlCellCong
Diversity -
Frame Synchronization -
Handover -
Inter-Frequency pmNoIncomingHsHardHoAttempt
Handover
pmNoOutgoingHsHardHoAttempt
pmNoHsHardHoReturnOldChSource
pmNoHsHardHoReturnOldChTarget
pmNoIncomingEulHardHoAttempt
pmNoEulHardHoReturnOldChSource
LZT 123 8297 R1C © 2006 Ericsson - 275 -

pmNoEulHardHoReturnOldChSource
IRAT Handover, pmNoDirRetryAtt
Outgoing
IRAT Incoming -
IRAT Cell Change, -
Outgoing
IRAT Cell Change, -
Incoming
UE Positioning -
Iu Ranap Handling pmNoIuSigEstablishAttemptCs
pmNoIuSigEstablishSuccessCs
pmNoIuSigEstablishAttemptPs
pmNoIuSigEstablishSuccessPs
Iur Channel Handling -
Iur Channel Error -
Handling
Paging -
Packet Data pmSentPacketData1
pmSentPacketDataInclRetrans1
pmTotalPacketDuration1
pmNoOfPacketCallDuration1
pmSentPacketData2
pmSentPacketData3
pmSentPacketData4
pmSentPacketDataHs1
pmSentPacketDataInclRetransHs1
pmTotalPacketDurationHs1
pmNoOfPacketCallDurationHs1
pmSentPacketDataHs2
pmSentPacketDataHs3
pmSentPacketDataHs4
- 276 - © Ericsson 2006 LZT 123 8297 R1C

pmSamplesActUlRlcTotPacketThp
pmSumActUlRlcTotPacketThp
pmSamplesActDlRlcTotPacketThp
pmSumActDlRlcTotPacketThp
pmSamplesActUlRlcUserPacketThp
pmSumActUlRlcUserPacketThp
pmSamplesActDlRlcUserPacketThp
pmSumActDlRlcUserPacketThp
Payload Traffic -
Processor Supervision -
RAB Handling pmNoNormalRabReleaseCs64
pmNoNormalRabReleaseCsStream
pmNoNormalRabReleasePacket
pmNoNormalRabReleasePacketStream
pmNoNormalRabReleaseSpeech
pmNoRabEstablishAttemptPacketInteractiveEul
pmNoRabEstablishSuccessPacketInteractiveEul
pmRabEstablishEcAttempt
pmRabEstablishEcSuccess
pmNoRabEstablishAttemptCs57
pmNoRabEstablishAttemptCs64
pmNoRabEstablishAttemptPacketInteractive
pmNoRabEstablishAttemptPacketStream
pmNoRabEstablishAttemptSpeech
pmNoRabEstablishSuccessCs57
pmNoRabEstablishSuccessCs64
pmNoRabEstablishSuccessPacketInteractive
pmNoRabEstablishSuccessPacketStream
pmNoRabEstablishSuccessSpeech
pmNoNormalRabReleasePacketUra
pmNoSystemRabReleasePacket
pmNoSystemRabReleasePacketStream
pmNoSystemRabReleaseSpeech
pmNoTpSwitchSp64Speech
pmSamplesBestCs12Establish
pmSamplesCs12RabEstablish
pmSumBestCs12Establish
pmSumCs12RabEstablish
pmNoRabEstablishAttemptPacketInteractiveHs
pmNoRabEstablishSuccessPacketInteractiveHs
pmNoNormalRbReleaseHs
LZT 123 8297 R1C © 2006 Ericsson - 277 -

pmNoSystemRbReleaseHs
pmNoNormalRbReleaseEul
pmNoSystemRbReleaseEul
pmSumBestPsEulRabEstablish
pmSamplesBestPsEulRabEstablish
pmSamplesBestPsHsAdchRabEstablish
pmSumBestPsHsAdchRabEstablish
pmNoRabEstablishSuccessPacketStream128
pmNoRabEstablishAttemptPacketStream128
pmSamplesBestPsStr128Ps8RabEstablish
pmSumBestPsStr128Ps8RabEstablish
PmNoNormalRabReleasePacketStream128
PmNoSystemRabReleasePacketStream128
pmSamplesBestCs57RabEstablish
pmSumBestCs57RabEstablish
pmSamplesBestCs64RabEstablish
pmSumBestCs64RabEstablish
pmSamplesFachPsIntRabEstablish
pmSumFachPsIntRabEstablish
pmSamplesBestDchPsIntRabEstablish
pmSumBestDchPsIntRabEstablish
pmSamplesBestPsStr64Ps8RabEstablish
pmSumBestPsStr64Ps8RabEstablish
pmSamplesPsInteractive
pmSumPsInteractive
pmSumAmr12200RabEstablish
pmSumBestAmr12200RabEstablish
Radio Connection -
Supervision
RLC Handling -
RRC Handling pmNoOfRedirectedEmergencyCalls
pmNoCsStreamDchDiscAbnorm
pmNoCsStreamDchDiscNormal
pmNoLoadSharingRrcConn
pmNoPsStream64Ps8DchDiscAbnorm
pmNoPsStream64Ps8DchDiscNormal
pmTotNoRrcConnectReq
pmTotNoRrcConnectReqCs
pmTotNoRrcConnectReqCsSucc
- 278 - © Ericsson 2006 LZT 123 8297 R1C

pmTotNoRrcConnectReqPsSucc
pmTotNoRrcConnectReqSuccess
Security -
Radio Link Addition -
Counters Not Reporting -
for Drift UEs
Secondary Admission pmNoFailedAfterAdm
Scanner
pmNoOfSwDownNgAdm
pmNoReqDeniedAdm
Admission Monitoring pmNoOfSampAseDl
pmNoOfSampAseUl
pmSumOfSampAseDl
pmSumOfSampAseUl
Cell Availability -
Cell Update pmNoCellUpdAttempt
pmNoCellUpdSuccess
Channel Switching pmChSwitchAttemptFachUra
pmChSwitchSuccFachUra
pmChSwitchAttemptUraFach
pmChSwitchSuccUraFach
pmDownSwitchAttempt
pmDownSwitchSuccess
pmUlUpswitchSuccessMedium
pmUlUpswitchAttemptMedium
pmUpswitchFachHsSuccess
pmUpswitchFachHsAttempt
pmUlUpswitchSuccessLow
pmUlUpswitchAttemptLow
pmUlUpswitchSuccessHigh
pmUlUpswitchAttemptHigh
pmDlUpswitchSuccessHs
pmDlUpswitchAttemptHs
pmDlUpswitchAttemptLow
pmDlUpswitchAttemptMedium
pmDlUpswitchAttemptHigh
pmDlUpswitchSuccessLow
pmDlUpswitchSuccessMedium
pmDlUpswitchSuccessHigh
Channel Quality pmSamplesUlRssi
pmSumUlRssi
pmEulHarqTransmTti10PsInteractive
pmEulHarqTransmTti10Srb
pmEulHarqTransmTti10Failure
Code Control -
LZT 123 8297 R1C © 2006 Ericsson - 279 -

Compressed Mode -
Congestion pmSumOfTimesMeasOlDl
pmSumOfTimesMeasOlUl
Diversity pmNoOfRlForDriftingUesPerDrnc
pmNoOfRlForDriftingUes
pmNoOfRlForNonDriftingUes
Frame Synchronization -
Handover pmNoTimesCellFailAddToActSet
pmNoTimesRlAddToActSet
pmNoTimesRlDelFrActSet
pmNoTimesRlRepInActSet
Inter-Frequency pmNoIncomingHsHardHoSuccess
Handover
pmNoOutgoingHsHardHoSuccess
pmNoOutgoingEulHardHoSuccess
pmNoIncomingEulHardHoSuccess
Inter-Radio Access pmNoDirRetrySuccess
Technology Handover,
Outgoing
Inter-Radio Access -
Technology Handover,
Incoming
Technology Cell Change,
Outgoing
Technology Cell Change,
Incoming
UE Positioning -
Iur Channel Handling -
Iur Channel Error -
Handling
Paging pmUtranInitPagingToUraU
pmCnInitPagingToUraUe
Packet Data pmUlRlcUserPacketThp
pmDlRlcUserPacketThp
Processor Supervision pmSamplesMeasuredLoad
pmSumMeasuredLoad
pmSamplesMeasuredCcSpLoad
pmSumMeasuredCcSpLoad
pmSamplesMeasuredDcSpLoad
pmSumMeasuredDcSpLoad
pmSamplesMeasuredPdrSpLoad
pmSumMeasuredPdrSpLoad
RAB Handling pmSamplesRabUra
pmSumRabUra
pmSamplesPsEulRabEstablish
- 280 - © Ericsson 2006 LZT 123 8297 R1C

pmSumPsEulRabEstablish
pmNoRabEstablishFailureUeCapability
pmNoFailedRabEstAttemptExceedConnLimit
pmNoFailedRabEstAttemptLackDlPwr
pmNoFailedRabEstAttemptLackDlChnlCode
pmNoFailedRabEstAttemptLackDlAse
pmNoFailedRabEstAttemptLackUlAse
pmSamplesCs64Ps8RabEstablish
pmSumCs64Ps8RabEstablish
pmSamplesPsHsAdchRabEstablish
pmSumPsHsAdchRabEstablish
pmSamplesPsStr128Ps8RabEstablish
pmSumPsStr128Ps8RabEstablish
pmInactivityPsStreamIdle
pmSamplesBestCs12PsIntRabEstablish
pmSumBestCs12PsIntRabEstablish
pmSamplesBestCs64PsIntRabEstablis
pmSumBestCs64PsIntRabEstablish
pmNoNormalRabReleaseSpeech
pmNoNormalRabReleasePacket
pmNoNormalRabReleaseCs64
pmNoNormalRabReleaseCsStream
pmNoNormalRabReleasePacketStream
pmNoSystemRabReleaseSpeech
pmNoSystemRabReleasePacket
pmNoSystemRabReleasePacketUra
pmNoSystemRabReleasePacketStream
pmUlUpswitchAttemptEul
pmUlUpswitchSuccessEul
Radio Connection pmNoReleaseCchWaitCuT
Supervision
pmNoReleaseDchRcLostT
pmNoRlcErrors
RLC Handling -
RRC Handling pmNoCellDchDisconnectAbnorm
pmNoCellDchDisconnectNormal
pmNoCellFachDisconnectAbnorm
pmNoCellFachDisconnectNormal
pmNoCs64DchDiscAbnorm
pmNoCs64DchDiscNormal
pmNoOfReturningEmergencyCalls
pmNoPacketDchDiscAbnorm
pmNoPacketDchDiscNormal
LZT 123 8297 R1C © 2006 Ericsson - 281 -

pmNoRejRrcConnMpLoadC
pmNoSpeechDchDiscAbnorm
pmNoSpeechDchDiscNormal
pmNoSysRelSpeechUlSynch
pmTotNoUtranRejRrcConnReq
Security -
HS-DSCH Cell Change pmNoHsCcAttempt
pmNoHsCcSuccess
Ura Update pmNoUraUpdAttempt
pmNoUraUpdSuccess
Not Admission pmNoOfDiscardedNbapMessages
included in
any
predefined
scanner
Admission Monitoring -
Cell Availability -
Cell Update -
Channel Switching pmChSwitchDch128Fach
pmChSwitchDch384Fach
pmChSwitchDch64Fach
pmChSwitchFachDch
pmChSwitchP128P384
pmChSwitchP128P64
pmChSwitchP384P128
pmChSwitchP64P128
pmChSwitchSp0Sp64
pmChSwitchSp64Sp0
pmFailedChSwitch
pmFailedDchChSwitch
pmNoOfSwDownNgHo
pmFailedDchChSwitch
Channel Quality pmFaultyTransportBlocks
pmNoRecRandomAccSuccess
pmTransportBlocks
pmFaultyTransportBlocksBcUl
Code Control pmNoDlChCodeAllocAltCodeCm
pmNoDlChCodeAllocAttemptCm
- 282 - © Ericsson 2006 LZT 123 8297 R1C

Compressed Mode pmCmAttDlHls
pmCmAttDlSf2
pmCmAttUlHls
pmCmAttUlSf2
pmCmStop
pmCmSuccDlHls
pmCmSuccDlSf2
pmCmSuccUlHls
pmCmSuccUlSf2
pmInterFreqMeasCmStart
pmInterFreqMeasCmStop
pmSamplesCompMode
pmSumCompMode
Congestion pmNoOfIurSwDownNgCong
pmNoOfIurTermCsCong
pmNoOfIurTermSpeechCong
pmNoOfSwDownNgCong
pmNoOfTermCsCong
pmNoOfTermSpeechCong
pmNoOfIurTermHsCong
pmNoOfSwDownHsCong
CN Hard Handover pmNoAttOutCnhhoSpeech
pmNoSuccOutCnhhoSpeech
pmNoAttOutCnhhoCsNonSpeech
pmNoSuccOutCnhhoCsNonSpeech
pmNoAttOutCnhhoPsConnRelease
pmNoAttIncCnhhoSpeech
pmNoSuccIncCnhhoSpeech
pmNoAttIncCnhhoCsNonSpeech
pmNoSuccIncCnhhoCsNonSpeech
Diversity pmSamplesUesWith1Rls1RlInActSet
pmSamplesUesWith1Rls2RlInActSet
LZT 123 8297 R1C © 2006 Ericsson - 283 -

pmSumUesWith1Rls1RlInActSet
Frame Synchronization pmNoCchDiscardedDataFramesE
pmNoCchDiscardedDataFramesL
pmNoCchTimingAdjContrFrames
pmNoDchDlTimingAdjContrFrames
pmNoDchUlDataFramesOutsideWindow
pmNoDlDchDiscardedDataFramesE
pmNoDlDchDiscardedDataFramesL
pmNoUlDchDiscardedDataFramesE
pmNoUlDchDiscardedDataFramesL
Handover pmInterFreqMeasNoCmStart
pmInterFreqMeasNoCmStop
pmRlAddAttemptsBestCellCsConvers
pmRlAddAttemptsBestCellPacketHigh
pmRlAddAttemptsBestCellPacketLow
pmRlAddAttemptsBestCellSpeech
pmRlAddAttemptsBestCellStandAlone
pmRlAddAttemptsBestCellStream
pmRlAddSuccessBestCellCsConvers
pmRlAddSuccessBestCellPacketHigh
pmRlAddSuccessBestCellPacketLow
pmRlAddSuccessBestCellSpeech
pmRlAddSuccessBestCellStandAlone
pmRlAddSuccessBestCellStream
pmTotNoSbHo
pmNoSbHoMeasStart
pmNoSuccessSbHo
Inter-Frequency pmAttNonBlindInterFreqHoCsConversational
Handover
pmFailNonBlindInterFreqHoFailRevertCsConversationa
l
pmFailNonBlindInterFreqHoFailRevertPsInteractiveGr
- 284 - © Ericsson 2006 LZT 123 8297 R1C

eater64
pmFailNonBlindInterFreqHoFailRevertPsInteractiveLe
ss64
pmFailNonBlindInterFreqHoRevertCsConversational
pmFailNonBlindInterFreqHoRevertCsSpeech12
pmFailNonBlindInterFreqHoRevertPsInteractiveGreate
r64
pmFailNonBlindInterFreqHoRevertPsInteractiveLess64
pmFailNonBlindInterFreqHoRevertStreamingOther
pmSuccNonBlindInterFreqHoCsConversational
pmSuccNonBlindInterFreqHoCsSpeech12
pmSuccNonBlindInterFreqHoPsInteractiveGreater64
pmSuccNonBlindInterFreqHoPsInteractiveLess64
pmSuccNonBlindInterFreqHoStreamingOther
pmNoTimesIfhoRlAddToActSet
pmNoTimesIfhoCellFailAddToActSet
pmNoRlDeniedAdm
pmEnableHsHhoAttempt
pmEnableHsHhoSuccess
IRAT, Outgoing pmIratHoGsmMeasCmStart
pmIratHoGsmMeasNoCmStart
pmNoAttOutIratHoSpeech
pmNoAttOutIratHoMulti
pmNoAttOutIratHoStandalone
pmNoSuccessOutIratHoSpeech
pmNoSuccessOutIratHoStandalone
pmNoFailOutIratHoSpeechReturnOldChPhyChFail
pmNoFailOutIratHoCs57ReturnOldChPhyChFail
pmNoFailOutIratHoMultiReturnOldChPhyChFail
pmNoFailOutIratHoStandaloneReturnOldChPhyChFail
pmNoFailOutIratHoSpeechReturnOldChNotPhyChFail
pmNoFailOutIratHoCs57ReturnOldChNotPhyChFail
pmNoFailOutIratHoMultiReturnOldChNotPhyChFail
pmNoFailOutIratHoSpeechUeRejection
pmNoFailOutIratHoCs57UeRejection
pmNoFailOutIratHoMultiUeRejection
pmNoFailOutIratHoStandaloneUeRejection
pmNoAttOutSbHoSpeech
pmNoSuccessOutSbHoSpeech
pmNoFailOutSbHoSpeechReturnOldChPhyChFail
pmNoFailOutSbHoSpeechReturnOldChNotPhyChFail
pmNoFailOutSbHoSpeechGsmFailure
LZT 123 8297 R1C © 2006 Ericsson - 285 -

pmNoFailOutSbHoSpeechUeRejection
IRAT, Incoming pmNoInCsIratHoAdmFail
pmNoInCsIratHoAtt
pmNoInCsIratHoSuccess
IRAT Cell Change, pmNoOutIratCcReturnOldCh
Outgoing
pmNoOutIratCcSuccess
pmNoOutIratCcAtt
IRAT Cell Change, pmTotNoRrcConnectAttIratCcOrder
Incoming
pmTotNoRrcConnectAttIratCellResel
pmTotNoRrcConnectFailCongIratCcOrder
pmTotNoRrcConnectFailCongIratCellResel
pmTotNoRrcConnectSuccessIratCcOrder
pmTotNoRrcConnectSuccessIratCellResel
Iu Ranap Handling pmNnsfNriRouted
pmNnsfLoadDistributionRouted
UE Positioning pmPositioningReqAtt
pmPositioningReqAttCellId
pmPositioningReqAttEsCellId
pmPositioningReqSucc
pmPositioningReqSuccCellId
pmPositioningReqSuccCellIdQoSSucc
pmPositioningReqAttAgps
pmPositioningReqSuccAgps
pmPositioningReqSuccAgpsQosSucc
pmPositioningReqUnsuccAgpsAbort
pmPositioningReqReAttCellId
pmPositioningReqReAttSuccCellId
pmPositioningReqAttEsAgps
pmPositioningReqSuccEsAgps
pmPositioningReqSuccEsAgpsQosSucc
pmPositioningReqReAttEsCellId
Iur Channel Handling pmIurCommonEstAttExistTranspBearer
pmIurCommonEstAttNewTranspBearer
pmIurCommonEstSuccExistTranspBearer
pmIurCommonEstSuccNewTranspBearer
pmIurCommonRelease
pmIurTranspBearerRelease
Iur Channel Error pmIurCommonControlFrames
Handling
pmIurCommonControlFramesFaulty
pmIurCommonDlFrames
pmIurCommonDlFramesFaulty
pmIurCommonFachControlFrames
pmIurCommonFachControlFrameTimeout
- 286 - © Ericsson 2006 LZT 123 8297 R1C

pmIurCommonFachDataFrames
pmIurCommonFachDataFramesFaulty
pmIurCommonUlFrames
pmIurCommonUlFramesFaulty
Paging pmCnInitPagingToIdleUeLa
pmCnInitPagingToIdleUe
pmNoPageDiscardCmpLoadC
pmCnInitPagingToIdleUeRa
pmNoPagingType1AttemptUtran
pmNoPagingType1AttemptUtranCs
pmNoPagingType1AttemptUtranPs
pmNoPagingAttemptCnInitDcch
Packet Data pmNoFaultyIpPackets
pmNoRoutedIpBytesDl
pmNoRoutedIpBytesUl
pmNoRoutedIpPacketsDl
pmNoRoutedIpPacketsUl
pmSamplesPacketDataRab
pmSumPacketDataRab
Payload Traffic pmUlTrafficVolumeAmr7950
pmDlTrafficVolumeAmr7950
pmUlTrafficVolumeAmr5900
pmUlTrafficVolumeAmr4750
pmDlDchTrafficVolumeBeforeSplit
pmDlFachTrafficVolume
pmUlDchTrafficVolumeAfterComb
pmUlRachTrafficVolume
pmDlTrafficVolumeCs12
pmDlTrafficVolumePs128
pmDlTrafficVolumePsCommon
pmUlTrafficVolumeCs12
pmUlTrafficVolumePs128
pmUlTrafficVolumePsCommon
pmUlTrafficVolumePsStr128Ps8
pmDlTrafficVolumePsStr128Ps8
LZT 123 8297 R1C © 2006 Ericsson - 287 -

Processor Supervision pmAdmittedRequestsB0

pmAdmittedRequestsB1
pmAdmittedRequestsF0
pmRefusedRequestsB0
pmRefusedRequestsB1
pmRefusedRequestsF0
pmRefusedRequestsF1
pmRefusedRequestsF2
pmRefusedRequestsF3
pmRefusedRequestsF4
RAB Handling pmNoInvalidRabEstablishAttempts
pmNoInvalidRabReleaseAttempts
pmNoRabEstablishAttempts
pmNoRabEstablishSuccess
pmNoRabReleaseAttempts
pmNoRabReleaseSuccess
pmSamplesRabEstablish
pmSumRabEstablish
pmSamplesPs128RabEstablish
pmSamplesPsStr64Ps8RabEstablish
pmSamplesRabFach
pmSamplesRrcOnlyEstablish
pmSumPs128RabEstablish
pmSumPsStr64Ps8RabEstablish
pmSumRabFach
pmSumRrcOnlyEstablish
pmHsToDchAttempt
pmHsToDchSuccess
pmNoRabEstablishAttemptAmrNb
pmNoRabEstablishSuccessAmrNb
- 288 - © Ericsson 2006 LZT 123 8297 R1C

pmNoNormalRabReleaseAmrNb
pmNoSystemRabReleaseAmrNb
pmSamplesAmr12200RabEstablish
pmSamplesBestAmr12200RabEstablish
Radio Connection pmSamplesBestAmr5900RabEstablish
Supervision
RLC Handling pmSamplesBestAmr4750RabEstablish
pmNoDiscardSduDtch
pmNoReceivedSduDcch
pmNoReceivedSduDtch
pmNoRetransPduDcch
pmNoRetransPduDtch
pmNoSentPduDcch
pmNoSentPduDtch
RRC Handling pmTotNoRrcConnectReqSms
pmNoPsStream128Ps8DchDiscNormal
pmNoPsStream128Ps8DchDiscAbnorm
pmNoRrcCsReqDeniedAdm
pmNoRrcPsReqDeniedAdm
pmNoRrcReqDeniedAdm
pmTotNoTermRrcConnectReq
pmTotNoTermRrcConnectReqCs
pmTotNoTermRrcConnectReqPs
Security pmIntegrityFailureRrcMsg
Counters Not Reporting -
for Drift UEs
LZT 123 8297 R1C © 2006 Ericsson - 289 -

Intentionally Blank
- 290 - © Ericsson 2006 LZT 123 8297 R1C

Appendix D: Table of Figures
LZT 123 8297 R1C © 2006 Ericsson - 291 -

Intentionally Blank
- 292 - © Ericsson 2006 LZT 123 8297 R1C

Figure 1-1 Overview of the Radio Network evolution...................................................................... 13

Figure 1-2. The difference between RAN tuning and RAN optimization ......................................... 14
Figure 1-3 UTRAN Observability Model.......................................................................................... 15
Figure 1-4 Network performance Monitoring .................................................................................. 16
Figure 1-5. Measuring Network Quality .......................................................................................... 17
Figure 1-6. WCDMA RAN Architecture ........................................................................................... 18
Figure 1-7. Network Quality of Service (QoS)................................................................................. 19
Figure 1-8 Performance Analyses .................................................................................................. 20
Figure 1-9 Optimization Process..................................................................................................... 21
Figure 1-10. Module process ......................................................................................................... 24
Table 1- Speech Call Drop for RNC................................................................................................ 29
Table 2- Output from unpaired t-test............................................................................................... 30
Figure 2-2. Example of traffic distributed over 10 days................................................................... 38
Figure 2-3. Example of statistics from a PDF counter .................................................................... 40
Table 2-4. Grouping the counters based on their NE Origin (SDM = Statistical Data Mart) ........... 42
Figure 2-5. Statistics profile activation ............................................................................................ 43
Table 2-6. Pre-defined profiles........................................................................................................ 45
Table 2-7. Main differences between user-defined and pre-defined profiles .................................. 45
Figure 2-8. Profiles, Scanners and Counters – RNC example ....................................................... 46
Figure 3-1 A mobile originating call setup and the different action taken ....................................... 55
Figure 3-2 A The Accessibility workflow ......................................................................................... 56
Figure 3-3 The relationship between some of the idle mode tasks................................................. 58
Figure 3-4 Determination of Cell Selection Criteria......................................................................... 60
Figure 3-5 Periodic Registration ..................................................................................................... 61
Figure 3-6 The Paging counter flowchart........................................................................................ 65
Figure 3-7 The Random Access counter flowchart ......................................................................... 68
Figure 3-8 WCDMA Power Control................................................................................................. 70
Figure 3-9 A mobile originating call setup and the different action taken ....................................... 72
Figure 3-10 WCDMA Capacity Management (Admission Control) ................................................. 74
Figure 3-11 The Admission control flow.......................................................................................... 75
Figure 3-12 Detection of Uplink Cell Congestion Due to Uplink Received Total Wideband Power 77
Figure 3-13 TEMS Investigation with high UTRA Carrier RSSI ...................................................... 79
Figure 3-14 The Uplink RBS HW Admission Policy ........................................................................ 80
Figure 3-15 The Downlink Transmitted Carrier Power Admission Policy........................................ 82
The Uplink ASE Admission Policy .................................................................................................. 84
Figure 3-17 The Spreading Factor Admission Policy for Non-guaranteed Service Class Radio Links
................................................................................................................................................. 86
Figure 3-18 The Downlink Channelization Code Admission Policy ................................................ 88
Figure 3-19 Load sharing................................................................................................................ 91
Figure 3-20 The load sharing counter flow ..................................................................................... 92
Radio link setup procedures ........................................................................................................... 95
Radio link synchronization procedures ........................................................................................... 95
Figure 3-23 Radio Link setup counter flow, continued from the Random Access flow figure Figure
3-7............................................................................................................................................ 96
Figure 3-24 L1 synchronization problem......................................................................................... 97
Figure 3-25 Radio Link Synchronization failure .............................................................................. 98
Figure 3-26 Radio Link setup failure: AICH problem in TEMS Investigation................................... 99
Figure 3-27 NAS failure: CM service reject in TEMS Investigation............................................... 101
Figure 3-28 Speech, CS 64, Streaming 57.6 RAB establishment ................................................ 102
Figure 3-29 Interactive RAB Establishment .................................................................................. 103
Figure 3-30 PDP Context Activation Failure. Cause: Radio Bearer Setup not sent. .................... 104
Figure 31: PDP Context Activation Failure. Cause: User Authentication Failed ........................... 105
LZT 123 8297 R1C © 2006 Ericsson - 293 -

Figure 3-32 UE Cell reselection during handover ......................................................................... 106

Figure 3-33 UE Cell Reselection................................................................................................... 107
Figure 3-34 PDP Context Activation Failure. Cause: Radio Bearer setup then PDP rejected...... 108
Figure 3-35 PDP Context Activation Failure. Cause: PPP Link Control terminated...................... 109
Figure 4-1 A The Retainability workflow ....................................................................................... 116
Figure 4-2 Network Initiated abnormal call releases..................................................................... 118
Figure 4-3 Radio Link Set Supervision States .............................................................................. 119
Figure 4-4 UE TX Power vs. CPICH Ec/No and RSCP ................................................................ 121
Figure 4-5 UL out of synch............................................................................................................ 123
Figure 4-6 UL/DL Imbalance......................................................................................................... 124
Figure 4-7 Entities Involved in Reporting, Evaluation, and Execution of Handover-Related
Functions ............................................................................................................................... 129
Figure 4-8 Soft Handover.............................................................................................................. 130
The counter flow for the cell reselection for Inter-frequency handovers are shown in the ............ 130
Figure 4-9 The counter flow for soft/softer handover .................................................................... 131
Figure 4-10 The cell reselection evaluation process..................................................................... 132
Figure 4-11 Cell re-selection was done between SC98 and SC82 ............................................... 135
Figure 4-12 Cell re-selection......................................................................................................... 136
Figure 4-13 Field tests with settings of the reportingRange parameters ...................................... 137
Figure 4-14 The Measurement reports and ASU complete can vanish in case of a bad
timeToTrigger setting............................................................................................................. 140
Figure 4-15 Inconsistent Lists ....................................................................................................... 141
Figure 4-16 Inconsistent Lists between UE and RNC................................................................... 142
Figure 4-17 Removal of incorrect cell Cause: Inconsistent Lists .................................................. 143
Figure 4-18 Removal of incorrect cell Cause: Inconsistent Lists .................................................. 144
Figure 4-19 Example of different services and their overlapping areas ........................................ 146
Figure 4-20 WCDMA Handover (Inter Frequency Handover & Cell Re-selection) ....................... 149
Figure 4-21 WCDMA Handover (Inter RAT Handover)................................................................. 153
Figure 4-22 Loss of ASU complete. Possible Cause: DL/UL Imbalance ...................................... 159
Figure 4-23 Loss of measurement reports.................................................................................... 160
Figure 4-24 RC Handover failure. Possible Cause: Network configuration .................................. 161
Figure 4-25 Inconsistent Lists. Possible Cause: DL/UL Imbalance .............................................. 162
Figure 4-26 TEMS Investigation DL BLER Increases and the call is dropped.............................. 163
Figure 5-1 A The Integrity workflow .............................................................................................. 169
Figure 5-2 WCDMA Power Control............................................................................................... 172
Figure 5-3 CRC Generator............................................................................................................ 173
Figure 5-4 Uplink Inner Loop Power Control................................................................................. 175
Figure 5-5 Uplink Outer Loop Power Control................................................................................ 176
Figure 5-6 SIR Target Behaviour According to the Constant Step Regulator algorithm ............... 178
Figure 5-7 SIR Target Behaviour According to the Jump Regulator algorithm ............................. 179
Figure 5-8 Packet Call showing Session throughput and THold ..................................................... 182
Figure 5-9 PS Application Downlink throughput from TEMS Investigation ................................... 182
Table 9 PS Binned Application-level Throughput Statistics .......................................................... 183
WCDMA Channel Switching ......................................................................................................... 185
The dedicated to common channel switching evaluation .............................................................. 187
Channel Switching in TEMS Investigation .................................................................................... 193
HSDPA will take whatever power that is left in RBS ..................................................................... 196
Figure 5-14 Example of high DL BLER and no radio bearer setup............................................... 200
Figure 5-15 There is no DL signalling after the Radio Bearer Setup Complete ............................ 201
Intentionally Blank......................................................................................................................... 206
Figure 6-1. Data Collection – Subscription profiles....................................................................... 210
Figure 6-2. Selecting the UETR profile ......................................................................................... 211
- 294 - © Ericsson 2006 LZT 123 8297 R1C

Figure 6-3. Entering a profile name and comments...................................................................... 211

Figure 6-4. Selecting the involved RNC........................................................................................ 212
Figure 6-5. Selecting the protocols to be measured on ................................................................ 212
Figure 6-6. Step Entering the IMSI number .................................................................................. 213
One TEMS Log file corresponds to several Uplink files................................................................ 215
Figure 6-8. Step 1 to 3 of 5 ........................................................................................................... 216
Figure 6-9. Step 4 of 5 .................................................................................................................. 217
Figure 6-10. WCDMA RAN measurements – OSS_RC workspace menu ................................... 220
Figure 6-11. Select the General performance profiles .................................................................. 221
Figure 6-12. Selecting the GPEH events ...................................................................................... 221
Figure 6-13 GPEH File naming convention .................................................................................. 222
Figure 6-14 GPEH RNC-Internal Event Example ......................................................................... 224
Figure 6-15 GPEH RBS-Internal Event Example.......................................................................... 226
Figure 6-16 WCDMA Recording File Viewer ................................................................................ 227
Figure 6-17 Launching WCDMA Recording file viewer................................................................. 228
Figure 6-18 Recording file viewer graphical user interface........................................................... 229
Figure 6-19 Recording File Viewer Search Criteria ...................................................................... 230
Figure 6-20 File drop down menu options .................................................................................... 231
Figure 6-21 Workflow for analysis of the GPEH log files .............................................................. 233
Figure 6-22 TEMS Visualization User interface with all files loaded ............................................. 234
LZT 123 8297 R1C © 2006 Ericsson - 295 -

Intentionally Blank
- 296 - © Ericsson 2006 LZT 123 8297 R1C

Appendix E: Index
Appendix E: Index
LZT 123 8297 R1C © 2006 Ericsson - 297 -

Intentionally Blank
- 298 - © Ericsson 2006 LZT 123 8297 R1C

Appendix E: Index
2nd Generation .........................................155 Packet Switching ... 37, 38, 56, 57, 60, 62, 68,
3rd Generation ..........................................155 95, 102, 117, 148, 153, 155, 156, 171, 181,
Adjunct processor or Application platform ..39 182, 183, 192, 198, 199
American National Standards Institute........66 Performance Measurement..... 15, 25, 37, 46,
American Standard Code for Information 208
Interchange ...........................................227 Personal Computer .................................. 214
Application System ....98, 132, 138, 149, 163, Point-to-Point Protocol ............... 53, 108, 109
164 Public Land Mobile Network53, 58, 59, 66, 67
Asynchronous Transfer Mode.............39, 194 Radio Access Bearer... 24, 25, 56, 57, 76, 81,
Circuit Switching ....37, 38, 56, 57, 60, 62, 68, 87, 89, 90, 92, 94, 95, 96, 101, 102, 103,
102, 117, 128, 152, 155, 180, 181 105, 125, 128, 147, 149, 155, 167, 170,
Common Object Request Broker Architecture 171, 177, 180, 183, 184, 185, 186, 190,
................................................................42 191, 192, 193, 198, 199, 200, 225
Connection Management......20, 53, 100, 101 Radio Access Network .. 9, 11, 13, 14, 18, 21,
Core Network ...17, 60, 61, 62, 100, 102, 103, 23, 24, 37, 43, 51, 57, 62, 63, 66, 90, 94,
118 107, 111, 113, 123, 129, 135, 153, 165,
Customer Product Information e ...47, 48, 222 184, 185, 186, 203, 207, 219, 220, 221,
Element Management.................................47 235
File Transfer Protocol........................155, 188 Radio Access Network Application Protocol
Global System for Mobile Communication.25, ...................................... 208, 219, 223, 225
62, 66, 73, 90, 91, 92, 94, 146, 150, 152, Radio Access Network Operation System
153, 154, 155, 156, 225, 232 .............................................. 194, 207, 210
Graphical User Interface, 42, 46, 47, 228, 229 Radio Network Controller .. 18, 24, 26, 27, 29,
Hardware .....23, 47, 48, 79, 80, 90, 126, 128, 37, 41, 43, 44, 45, 46, 47, 48, 49, 50, 57,
152, 167, 194 62, 63, 64, 68, 69, 72, 73, 78, 90, 91, 96,
Identification......................100, 102, 103, 230 113, 116, 117, 118, 120, 124, 137, 139,
Integration Reference Points ......................46 140, 143, 146, 149, 152, 156, 157, 159,
Intelligent Network ............................224, 225 162, 163, 170, 171, 174, 179, 184, 186,
International Mobile Subscriber Identity.....61, 193, 194, 197, 207, 208, 209, 211, 212,
62, 100, 207, 213, 214, 215, 230 214, 219, 220, 221, 222, 223, 224
Internet Protocol................................155, 181 Service Capability 22, 98, 106, 136, 143, 163,
Location Area........58, 60, 61, 62, 63, 67, 155 164
Location Area Identity .................................62 Short Message Service .............................. 68
Main Processor .......53, 63, 73, 220, 222, 223 Software ........................................... 167, 194
Media Access Control ...............102, 187, 193 Synchronous Transfer Mode .................... 194
Mobile Country Code ................................213 Synchronous Transfer Mode 155 Mbit/s .. 194
Mobile Network Code Digits......................213 Temporary Mobile Subscriber Identity........ 62
Mobile Originated......................43, 44, 45, 49 Third Generation Partnership Project. 91, 225
Mobile Services switching Centre .63, 64, 213 Transmission Control Protocol 155, 181, 187,
Network Operator......................................224 188, 223
Operation and Maintenance................47, 222 Universal Mobile Telecommunication System
Operation and Support System18, 25, 37, 39, ........................................ 73, 154, 155, 232
41, 42, 45, 46, 47, 50, 159, 207, 210, 219, Unrestricted Digital Information UE ............ 38
220, 223, 228, 232, 233 UTRAN Registration Area .. 66, 184, 185, 189
Packet Data Protocol ..53, 104, 105, 108, 109
LZT 123 8297 R1C © Ericsson 2006 - 299 -

Wideband Code Division Multiple Access....9, 155, 158, 159, 160, 167, 169, 170, 172,
11, 13, 15, 18, 21, 23, 24, 37, 39, 57, 59, 173, 184, 185, 186, 194, 195, 200, 207,
62, 66, 70, 74, 80, 90, 91, 94, 107, 108, 219, 220, 221, 227, 228, 232, 233
113, 123, 129, 135, 150, 152, 153, 154,
- 300 - © Ericsson 2006 LZT 123 8297 R1C

WCDMA Radio Network Optimization Student Book PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WCDMA Radio Network Optimization Student Book PDF

Uploaded by

Copyright:

Available Formats

WCDMA Radio Access Network Optimization

WCDMA Radio Access Network

LZT 123 8297 R1C © Ericsson 2006 -1-

This book is a training document and contains simplifications.

The contents of this document are subject to revision without

Ericsson assumes no legal responsibility for any error or damage

This document is not intended to replace the technical

This document was produced by Ericsson.

• It is used for training purposes only and may not be copied or

-2- © Ericsson 2006 LZT 123 8297 R1C

1 PERFORMANCE MONITORING OF A WCDMA RADIO

KEY PERFORMANCE INDICATORS ..................................................15

WCDMA RAN OPTIMIZATION WORKFLOW .....................................21

WCDMA RAN OPTIMIZATION MODULE WORKFLOW .....................24

STATISTICAL TEST METHODS..........................................................28

STATISTICAL DATA MART .................................................................50

3 SERVICE ACCESSIBILITY .........................................................51

ACCESSIBILITY WORKFLOW ...........................................................55

LZT 123 8297 R1C © Ericsson 2006 -3-

WORST PERFORMING CELLS ..........................................................56

UE IN IDLE MODE ...............................................................................58

RRC CONNECTION SETUP................................................................72

RADIO BEARER SETUP...................................................................101

TEMS INVESTIGATION FINDINGS...................................................108

4 SERVICE RETAINABILITY .......................................................111

RETAINIBILITY .................................................................................. 115

RETAINABILITY WORKFLOW.......................................................... 115

WORST CELLS ................................................................................. 116

DROPPED CALLS............................................................................. 117

-4- © Ericsson 2006 LZT 123 8297 R1C

UL OUT OF SYNCH ..................................................................................... 118

WNCS (WCDMA NEIGHBOURING CELL SUPPORT) .....................157

TEMS INVESTIGATION FINDINGS...................................................159

5 SERVICE INTEGRITY ...............................................................165

WORST CELLS .................................................................................171

WCDMA POWER CONTROL ............................................................172

BLER PARAMETERS ........................................................................180

TEMS INVESTIGATION FINDINGS...................................................200

LZT 123 8297 R1C © Ericsson 2006 -5-

HIGH DL BLER – DROPPED CALL ............................................................. 201

6 UETR AND GPEH .....................................................................203

UE TRAFFIC RECORDING (UETR) ..................................................207

GENERAL PERFORMANCE EVENT HANDLING (GPEH)...............219

8 APPENDIX A: CELL PARAMETER AND

APPENDIX B: FORMULAS FOR KEY PERFORMANCE

KEY PERFORMANCE INDICATORS ................................................253

-6- © Ericsson 2006 LZT 123 8297 R1C

APPENDIX C: PREDEFINED STATISTICS PROFILES

APPENDIX D: TABLE OF FIGURES.................................................291

LZT 123 8297 R1C © Ericsson 2006 -7-

-8- © Ericsson 2006 LZT 123 8297 R1C

1 Performance Monitoring of a WCDMA Radio

• Explain the difference between RAN Tuning and RAN

• Describe how to monitor the RAN performance

• Describe the definition of Network Quality

• Describe the general optimization process

LZT 123 8297 R1C © 2006 Ericsson -9-

- 10 - © Ericsson 2006 LZT 123 8297 R1C

KEY PERFORMANCE INDICATORS ..................................................15

WCDMA RAN OPTIMIZATION WORKFLOW .....................................21

WCDMA RAN OPTIMIZATION MODULE WORKFLOW .....................24

STATISTICAL TEST METHODS..........................................................28

LZT 123 8297 R1C © 2006 Ericsson - 11 -