RFT - TMO18351 - V3 SG UA08 Ed1

UTRAN
UA08 Radio Fine Tuning

Student Guide
TMO18351_V3-SG Edition 1
COPYRIGHT © ALCATEL-LUCENT @@YEAR. ALL RIGHTS RESERVED.
Passing on and copying of this document, use and communication of its contents not
permitted without written authorization from Alcatel-Lucent
Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Terms of use and legal notices
TERMS OF USE AND LEGAL NOTICE

Switch to notes view!
Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training course
and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These Terms of Use and Legal
Notice, as well as the contents of this training course, may be updated or amended by Alcatel-Lucent from time to time without prior
notice to you. Your use of the Alcatel-Lucent training materials after such update or amendment constitutes your acceptance of and
agreement to said updated or amended Terms of Use and Legal Notice.
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages present. Always
observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to wear conductive jewelry
while working on the products. Equipment referred to or used during this course may be electrostatic sensitive. Please observe correct
anti-static precautions.
PERMISSION TO USE CONTENT

The information, communications, scripts, photos, text, video, graphics, music, sounds, images and other materials provided in this
training course (collectively the "Content"), is intended for the lawful use of employees of Alcatel-Lucent and other authorized
participants in this Alcatel-Lucent training course. You are hereby granted a non-exclusive, non-transferable permission to access and
use the Content solely for your personal training and non-commercial use. This permission may be terminated by Alcatel-Lucent at
any time for any reason or no reason, with or without notice. You must immediately cease use of the Content upon such termination.
COPYRIGHTS AND TRADEMARKS

The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and Alcatel-Lucent’s
corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws, including but not limited to,
copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights laws (collectively, "IP Rights"). In
addition to Alcatel-Lucent’s IP Rights in the Content, in part and in whole, Alcatel-Lucent, and any of the third parties who have
licensed and/or contributed to the Content, owns a copyright in the formatting and presentation of the Content.
Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these Terms of Use
and Legal Notice. All other use of Content from this training course, including, but not limited to, modification, publication, transmission,
participation in the transfer or sale of, copying, reproduction, republishing, creation of derivative works from, distribution, performance,
display, incorporation into another training course or presentation, or in any other way exploiting any of the Content, in whole or in
part, for
2 uses other than those expressly permitted herein is strictly prohibited and shall not be made without Alcatel-Lucent’s prior
written@@PRODUCT
consent. All characters appearing in this training course are fictitious. Any resemblance to real persons, living or dead, is purely
COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.
coincidental.
@@COURSENAME
There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the Content. Alcatel,
Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other trademarks are the property of their
respective owners. Alcatel-Lucent does not grant you a license to use any of the foregoing logos, marks, trademarks, slogans and
product designations in any fashion. Granting of the right to access and use the Content for training purposes does not confer upon
you any license under any of Alcatel-Lucent’s or any third party's IP Rights.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM, DAMAGE, OR ANY SPECIAL,
EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND (INCLUDING WITHOUT LIMITATION
LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT LIABILITY OR OTHERWISE, THAT ARISES OUT
OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE CONTENT OR THE TRAINING COURSES BY YOU, OR (B)
ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS, DIRECTORS, AGENTS OR EMPLOYEES IN CONNECTION WITH THE
CONTENT OR THE TRAINING COURSES (INCLUDING, WITHOUT LIMITATION, THE USE OF OR INABILITY TO USE ANY COMPONENT
OF THE CONTENT OR TRAINING BY YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH EXCLUSION OF WARRANTIES OR
LIMITATION OF LIABILITIES AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITY MAY NOT APPLY
TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is governed by
the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of Use and Legal Notice,
or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute or a court of competent
jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision that reflects the intent of the
original provision as closely as possible. All other provisions of these Terms of Use and Legal Notice shall remain in full force and
effect. You may not assign these Terms of Use or any permission granted hereunder without Alcatel-Lucent’s prior written
consent. Nothing herein shall be deemed an employment agreement or an offer of employment or an alteration in any way of a user’s
terms of employment with or within Alcatel-Lucent.
Copyright © 2011 Alcatel-Lucent. All Rights Reserved

Course outline
Welcome to UTRAN
1. Introduction 4. Topic/Section is Positioned Here
to 3G Radio Fine Tuning
1. Radio
UA08 Concepts
FineofTuning
Radio Fine Tuning
5. Topic/Section is Positioned Here
2. Main UTRAN Algorithms Having an Impact on the QoS
1. 2. Tuning key
Introduction to 3GUTRAN
Radio Fine algorithms
Tuning 6. Topic/Section is Positioned Here
1. Concepts of Radio Fine Tuning
1. Tune RRC Connection Establishment
2. Main UTRAN Algorithms Having an Impact on the QoS
7. Topic/Section is Positioned Here
2. Tune Soft Handover
2. Tuning key UTRAN algorithms
3. Tune 3G-2G Hard Handover
1. Tune RRC Connection Establishment
4. Tune Cell Reselection
2. Tune Soft Handover
5. Tune Radio Link Management
3. Tune 3G-2G Hard Handover
6. Tune
4. TuneRadio Resource Management
Cell Reselection
7. Optimal Settings
5. Tune Radio for HSPA
Link Management
3. Abbreviations and Acronyms
6. Tune Radio Resource Management
1. Abbreviations
7. Optimal Settingsand Acronyms
for HSPA
3 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

@@PRODUCT
@@COURSENAME

Course objectives
UTRAN
 Upon completion of this course, you should be able to:
UA08 Radio Fine

Locate the Tuning
Radio Fine Tuning activities
 List the main causes of QoS degradation and common solutions
 Identify the
Upon completion main
of this algorithms
course, impacting
you should be ableQoS
to:
 Identify the QoS indicators sensitive to fine tuning algorithms
 Describe the call flow of the RRC connection and the Paging procedures
 Identify
 Locate the Radio theFine
algorithms and parameters that can be tuned & QoS indicators impacted
Tuning activities
Explain
 Listthe the objectives
main causes of the SHO
of QoS degradation and algorithm
common solutions
 Present the principles of an SHO procedure
 Identify the main algorithms impacting QoS
 Describe the algorithms and parameters that can be tuned to improve performance & QoS
 Identify the QoS indicators
indicators impactedsensitive to fine tuning algorithms
 Explain
 Describe theflow
the call objectives
of the RRCofconnection
the HHO and algorithm
the Paging procedures
 Present
 Identify the principles
the algorithms of the HHO
and parameters for be
that can Alarm
tunedreason
& QoS procedure
indicators impacted
 Describe the algorithms and
 Explain the objectives of the SHO algorithm
parameters that can be tuned to improve the performance of
the HHO for Alarm reason procedure & QoS indicators impacted
 Present the principles
 Explain of an SHOofprocedure
the objectives the Cell Reselection algorithm
 Present
 Describe the principles
the algorithms of the 3Gthat
and parameters to can
2G beand 2G to improve
tuned 3G Cell performance
Reselection&procedure
QoS indicators impacted
 Describe
 Explain the algorithms
the objectives of the HHOand parameters that can be tuned to improve the performance of
algorithm
 Presentthethe Cell Reselection
principles of the procedure
HHO for Alarm & QoS
reasonindicators
procedureimpacted
 Explain the objectives of the Radio Link Management algorithms
 Describe the algorithms and parameters that can be tuned to improve the performance of the HHO for Alarm reason
 Present the principles of the Radio Link Management procedures
procedure & QoS indicators impacted
 Describe the algorithms and parameters that can be tuned to improve the performance of
 Explain
4
thethe
@@PRODUCT
objectives
Radio Link of the Cellprocedures
Control Reselection algorithm
& QoS indicators impacted
 Explain the objectives

of the 3Gof to the Radio Resource Management algorithms
@@COURSENAME
 Present the principles 2G and 2G to 3G Cell Reselection procedure
 Describe the algorithms and parameters that can be tuned to improve the performance of the Cell Reselection procedure
& QoS indicators impacted
 Explain the objectives of the Radio Link Management algorithms
 Present the principles of the Radio Link Management procedures
 Describe the algorithms and parameters that can be tuned to improve the performance of the Radio Link Control
procedures & QoS indicators impacted
 Explain the objectives of the Radio Resource Management algorithms
 Present the principles of the Radio Resource Management algorithms
 Describe the algorithms and parameters that can be tuned to improve the performance of the different Radio Resource
Management algorithms & QoS indicators impacted
 Describe the key parameters used to enhance HSDPA performance
 Describe the E-DCH key parameters to be tuned to get the nominal performance
 Explain the E2E communication aspects impacting the HSPA optimal throughput
Your feedback is appreciated!

Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the following training reference in your email:

Thank you!

Section 1
Do not delete this graphic elements in here:
Introduction to 3G Radio Fine

Tuning
Module 1
Concepts of Radio Fine Tuning
TMO18351_V3-SG-UA08-Ed1 Module 1.1 Edition 1
UTRAN
All Rights Reserved © Alcatel-Lucent @@YEAR

Section 1 · Module 1 · Page 1
Blank page
1·1·2 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Introduction to 3G Radio Fine Tuning · Concepts of Radio Fine Tuning
UTRAN · UA08 Radio Fine Tuning
This page is left blank intentionally
Document History
Edition Date Author Remarks
01 YYYY-MM-DD Last name, first name First edition

Module objectives
Upon completion of this module, you should be able to:
 Locate the Radio Fine Tuning activities in the Network Life Cycle
 List the main causes of a QoS degradation
 Identify some common solutions to a QoS degradation


Module objectives [cont.]


Table of contents
Switch to notes view! Page
1 Radio fine tuning in network life cycle 7

1.1 Network life cycle 8
1.2 Network deployment 9
1.3 Pre-launch optimization 10
1.3.1 Cluster optimization 12
1.3.1.1 3G + voice 13
1.3.1.2 3G-2G + other services 15
1.3.2 Network optimization 17
1.4 Network acceptance 18
1.4.1 Key Performance Indicators (KPI) 19
1.5 Pre-launch optimization methodology 20
1.5.1 Coverage analysis 21
1.5.2 Quality analysis 22
1.5.3 Dominance 23
1.5.4 Neighbor list (3G-3G; 3G-2G; 3G-LTE) 24
1.5.5 Drop calls/ call setup failures 25
1.6 Post-launch network optimization 26
2 Main reasons for UTRAN QoS degradation 27
2.1 The causes of QoS degradation 28
3 Main solutions to solve UTRAN QoS degradation 29
3.1 Propose a solution to solve the QoS problem 30
3.2
1·1·5
Discover the solution of a QoS degradation 31
4 Exercise
Introduction
to 3G Radio Fine Tuning · Concepts of Radio Fine Tuning 32
4.1 Discover the consequences of a bad configuration 33
4.2 Lesson from the field 34

Table of contents [cont.]


1 Radio fine tuning in network life cycle


1.1 Network life cycle
Network Network Network Pre-launch Network

Design Planning Deployment Optimization Acceptance
Densification
Supervision
Network
Network
Network
Optimization
Radio Fine Tuning

Network Design: Initial Network Design aims at building the Bill of Quantities (BoQ) of the network. BoQ is the list
and number of the Network Elements necessary to match the Operator Requirements in terms of Coverage, Quality
and Traffic capacity of the network. Key Performance Indicators (KPIs) are agreed between supplier and operator at
this stage.
Network Planning: aims at defining the location and configuration of the radio sites:
 Site geographical location
 Number of sectors
 Number of cells per sector
 Number of frequencies per cell
 Antenna system configuration:
 Antenna location (macro, micro or indoor site)
 Antenna type
 Antenna azimuth
 Antenna tilt (electrical or mechanical)
 Tower Mounted Amplifier (TMA) or not
 Tx diversity or not
 2 Rx or 4 Rx diversity
 Node B max output power:
 TEU board type (MP, HP, LP)
 Number of TEUs
 Node B traffic capacity (number of BB boards)
 Number and traffic capacity of RNCs, MSCs, SGSNs, GGSNs, etc.
 Type and dimensioning of transport interfaces
1.2 Network deployment
Radio site installation: Design Planning Deployment Optimization Acceptance
 Shelter or room
 Node-B
Densifica
Supervisi
Network
Network
tion
on
 Antenna system
 Transmission to RNC
Network
Radio site validation: Optimization
 Drive Test procedure:

 Scanner + Mobile locked in 3G
 AMR service only
 In-car measurements
 Optimization tasks:
 Validate Softer HO for each sector
 No cross sector
 Reliability of site identifiers applied at OMC (LAC, RAC, SC, etc.)
 Site report
 A site report embedded to the commissioning report is provided

Before a site is put into commercial operation, some verification procedures and measurements have to be carried
out:
 Call test on all cells of the site
 Verification of the Scrambling codes of the cells
 Softer HO check
 Visual verification of azimuth and tilt direction
Exclusion criteria for radio coverage: CPICH RSCP < -98 dBm

1.3 Pre-launch optimization

Densifica
Supervisi
Network
Network
tion
on
Network
Optimization
Why is Pre-launch Optimization so important in a 3G network?

 WCDMA is a frequency reuse 1 technique
 Reducing the interference directly leads to optimized coverage and capacity
 Network design installation errors may lead to more interference
 Wrong parameter settings (e.g. wrong neighbor declaration) may lead to more
interference
1 · 1 · 10 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Pre-launch in a 3G network is much more important than in 2G where imperfections of design (best servers
distribution) can be masked by a frequency planning. In 3G, reuse 1 is the standard.

1.3 Pre-launch optimization [cont.]
Cluster optimization Design Planning Deployment Optimization Acceptance
 Remove weak coverage spots

 Declare missing neighbors
Densifica
Supervisi
Network
Network
tion
on
Network
Optimization
CLUSTER
RING
Network optimization:
 Optimize a group of clusters covering a certain region (city)
 Focusing on the inter-cluster areas

Cluster optimization: it can start as soon as the network elements and their transmission equipment installation
have been completed on a defined geographical zone of the network.
Network optimization: it can start after the complete network installation. If the network is big, the Network
Optimization can be split it into groups of clusters.
The main reasons for splitting into clusters and network optimization:
 Limit the number of sites to be considered for first optimization
 Easy split of tasks between different teams
 Start optimization in smaller areas before all sites in the network are up and running

1.3.1 Cluster optimization
Network
Optimization unit = cluster Deployment
 A cluster is a group of sites located inside a polygon

 The clusters are defined according to site priority
Optimization phases = 3G + Voice, 3G-2G + others


1.3.1.1 3G + voice
Network
Drive test procedure for 3G + voice Deployment
 Scanner + Mobiles Originating calls:

 AMR services: locked in 3G long calls
 Mobile originating calls
 The drive test roads should be defined in advance based on RNP study
 In-car measurements
CORE
RING


1.3.1.1 3G + voice [cont.]
Network
Analysis Deployment
 3G layer
 Quality & RF coverage
 SHO area
 Validation of the drive test roads
 Verification of the exclusion area
Typical problems
 Weak coverage
 Missing neighbor
Corrective tasks performed

 Antenna tilt
 Antenna azimuth
 Neighbor declaration

Coverage: CPICH RSCP measurement

Quality: CPICH Ec/Io measurement

1.3.1.2 3G-2G + other services
Network
Drive test procedure for optimization Deployment
 Scanner
 Mobiles:
 Voice Mobile Originating Call: Unlock 3G, short call (90’’, 30’’)
 Video Mobile to Mobile: locked in 3G, short calls (90’’, 15’’). The terminating mobile
stays under good radio conditions
 PS DL XXX, locked in 3G (384 Kbps => 4 Mo transferred, 128 kbps => 2 Mo)
 In-car measurements
CORE
RING


1.3.1.2 3G-2G + other services [cont.]
Network
Analysis Deployment
 Interference
 Quality & RF coverage
 SHO & HHO area
 Drop and Establishment Failures
Typical problems
 Dominance problem / Pilot pollution
 Weak coverage
 Missing neighbor
Corrective tasks performed

 Antenna tilt
 Antenna azimuth
 Neighbor declaration

Coverage: CPICH RSCP measurement

Quality: CPICH Ec/I0 measurement

1.3.2 Network optimization
Network
Network optimization with radio load Deployment
 Same activities as in cluster optimization but network (city)

wide, to ensure the homogeneous quality of the network
 Optimize a group of clusters covering a certain region (city)
 Focus done in the inter-cluster areas
 Test bearers that were not tested during cluster
optimization
 Radio Simulated load:
 OCNS in DL (60%)
 UE Tx Power attenuation in UL (3 dB)
To check the UMTS inter-working with GSM in order to improve the

QoS:
 in idle mode: 3G-to-2G cell reselection
 in dedicated mode: 3G-to-2G handover

Lessons learnt from customer roll-out:

 Network optimization without load could be removed
 Radio problems already seen during cluster optimization or network optimization with load  time saving
 Most constraining service tested: CS64
 AMR service to test mobility to 2G

1.4 Network acceptance

The contract is based
on commitments,
Densifica
Supervisi
Network
Network
defined in order to
tion
on
ensure the required
radio quality of service. Network
Optimization
The commitments are based at city level and they enable to get a Go
decision for:
 Commercial opening
 Payment triggering

After completion of network optimization, then Network Acceptance will be performed:

 It is performed with operator’s radio engineers
 It enables to check the radio optimization performed by Alcatel-Lucent
 It acts as a green light to open services to customers
The acceptance procedure may be divided into several steps:

 Radio Acceptance
 System Acceptance
 Inter-RAT Acceptance
Lessons learnt from customer roll-out for Acceptance:

 The acceptance services can be Voice, Video and PS DL
=> Radio acceptance
 The other services /applications can be tested under good radio conditions (fixed points or under 2/3 Node Bs)
in several parts of the network.
=> System acceptance

1.4 Network acceptance
1.4.1 Key Performance Indicators (KPI)
Network
Define a set of KPIs with corresponding thresholds Acceptance
Common approach between Customer and Alcatel-Lucent
End-user
quality for
voice
Commitment by Alcatel-Lucent on
KPIs in a turnkey deployment Call set-up
Quality of CS success rate
Call drop rate Handover
& PS call
success rate

KPIs are measured at each Acceptance phase:

 Mobile KPI (such as voice CDR in 3G-locked) during Radio Acceptance
 Static KPI (such as PING) during System Acceptance
 Inter-RAT KPI (such as voice CDR in 3G-2G) during Inter-RAT Acceptance
Define the right KPI:

 Call setup success rate: ratio of successful call setup over attempted call setup
 Handover success rate: ratio of successful handovers over attempted handovers
 Call drop rate: number of calls which are prematurely terminated over the total number of calls
 Quality of CS & PS call: block error rate on transport channel blocks depending on the radio bearer
 End-user quality for voice: Mean Opinion Score (MOS) combining perception and comfort
 End-user quality for applications over IP: throughput, response time, jitter and Packet Loss Rate for streaming application
Typical KPIs:
 AMR 12.2: long voice calls
 Number of call drops per hour, BLER
 Visio CS64: 2-minute calls
 Call success rate (number of calls maintained during 2 min/call attempts), BLER
 Packet background 64/384kbit/s
 Call success rate (number of calls maintained until the end of transfer/call attempts), FTP throughput, BLER
 Accessibility: short successive AMR & PS calls
 Call setup success rate

1.5 Pre-launch optimization methodology
Network
Which measurement is analyzed? Acceptance
Which actions are undertaken to optimize the following problems?
 Coverage
 Quality
 Dominance
 Neighbor List
 Drop Calls / Establishment Failures

Focus on drive test traces: mobile + scanner

1.5.1 Coverage analysis
Network
Acceptance
Definition
 The CPICH RSCP (Received Signal Code Power) provides indication of the availability
of DL Pilot Channel and coverage to meet services requirements
Consequence
 A minimum RSCP level is required to
maintain and/or establish a call and a
specific service
 It is very important to understand the
coverage limitations and expectations
Optimization
 Change tilt, azimuth and modify CPICH
Power or even add a new site in order
to change the RSCP level allocation
 Doing so, each individual sector should
be dominant only on its pre-defined
area
Planning
 The most important pre-optimization action is the planning of the RSCP Power level over
the Network, per individual sector.


1.5.2 Quality analysis
Network
Acceptance
Definition
 The network radio quality indicator is the CPICH Ec/Io. This indicator provides a clear
vision of the level of interference created by other cells over the most likely server, in a
certain area
Consequence
 If a certain CPICH Ec/Io is not met, the
UE will not be able to communicate
with the BS, not being able to establish
a call and possibly dropping it if
already connected
 A bad CPICH Ec/Io will correspond to a
bad UE Ec/No which is used to
evaluate and execute HO events and
Active Set updates, indispensable to
maintain a connection
Optimization
 The optimization actions applied are
the same as for the coverage


1.5.3 Dominance
Network
Acceptance
Definition
 Problems of dominance are described as being areas where there is the presence of 4 or
more SCs with equivalent CPICH Ec/Io, in a 5 dB window
Consequence
 These areas are usually associated with
low CPICH Ec/Io, high number of
HOs, high number of cell
reselections, high probability of
drop calls
 If the number of serving cells exceeds
the AS size then some of them act as
interferers and the problem is called
Pilot Pollution (or CPICH pollution)
Optimization
 Create a single sector dominance,
removing the less expected sectors by
modifying tilt or azimuth, and
improving the most likely server RSCP
in that location


1.5.4 Neighbor list (3G-3G; 3G-2G; 3G-LTE)
Network
Acceptance
Definition
 Handovers are performed based on quality and level measurements of serving
and neighbor cells:
 Ec/Io for SHO and inter-FDD HHO
 Ec/Io and RSCP for inter-RAT HHO
Consequence
 The UE does not check cells that are not declared in the neighboring list
even if it is the best cell
 A cell not declared as a neighbor but providing strong signal level creates
unwanted noise and deteriorates the quality
Optimization
 Compares both scanner and mobile maps (CPICH Ec/Io and RSCP)
 If the correct cell is not used in HO, the mobile will be degraded with
respect to scanner


1.5.5 Drop calls/ call setup failures
Network
Acceptance
Definition
 Those events are a reaction of the UE or the RNC to a certain problem.
 A drop can be due to a RADIO, UTRAN or CN problem (SYSTEM)
Consequence
 If the call drop is RADIO then
try to characterize it as one of
the problems seen previously:
 Coverage
 Quality
 Dominance
 Neighbor list
 If the call drop is SYSTEM then
try to characterize it with some
Iub/Iu trace analyses
Optimization
 For a RADIO drop: seen in the previous slide
 For a SYSTEM drop: correct the faulty hardware or software component


1.6 Post-launch network optimization

Network traffic allows one to use
Densifica
Supervisi
Network
Network
OMC-R QoS statistics for
tion
on
optimization
Some QoS problems which were not Network
Optimization
observed during Pre-launch
optimization can be found
Post-launch optimization aims at:
 Solving QoS degradations occuring during network
life
 Equipment failure
 Traffic increase
 Improving QoS by changing:
 radio parameter value from their default setting: Radio Fine Tuning
 antenna system configuration (height, tilt, azimuth): Design Fine Tuning

Pre-launch optimization is based on drive tests. Therefore, some QoS problems have not yet been detected when
Post-launch optimization takes place after commercial launch and traffic ramp up.
Radio Fine Tuning (RFT) is just one way of optimization for the Radio Network Optimizer.
RFT is used in order to optimize values of some key parameters whose current setting does not match the signal
propagation or traffic characteristics in a certain area.
It can also be used when other better solutions cannot be implemented in a short time frame.

2 Main reasons for UTRAN QoS
degradation


2 Main reasons for UTRAN QoS degradation
2.1 The causes of QoS degradation
List the main causes characterizing the possible QoS degradations that are
due to the UTRAN sub-system.

Don’t think about too detailed causes of degradation.

If you think about many causes (more than 6), try to group them by categories.
Duration = 5 min

3 Main solutions to solve UTRAN QoS
degradation


3 Main solutions to solve UTRAN QoS degradation
3.1 Propose a solution to solve the QoS problem
Very easy when implementation is not in line with RNP specifications

 Align the network configuration with RNP specifications
Quite easy for equipment failure

 Replace the faulty hardware component
 Perform an O&M action to restore the correct software behavior
Not so easy when the problem has been characterized as a

coverage, interference or congestion problem
 Analysis of the problem has to be done by the RNO team
with the help of O&M and RNP teams to decide for the best
solution (cost, outage, short/medium/long-term solution)


3 Main solutions to solve a UTRAN QoS degradation
3.2 Discover the solution of a QoS degradation
For the cause of QoS degradation identified before, tag in the proposed list
the possible solutions to the problem.
Add one Add one
Change Decrease Decrease
more more
Solution Add site Add TMA CPICH SHO UL CAC
CEM FDD
Tx Power overhead threshold
board freq.
QoS pb
Coverage 
Interference 
Congestion 
Harden Delay
Ease HHO Increase cell Radio Modify Remove
Go for
Solution to 2G SHO reselecti Link antenna external
HP MCPA
neighbors overhead on to the Failure setting interferer
QoS pb 3G cell triggering
Coverage
Interference
Congestion

A coverage problem as considered in the table is a permanent UTRAN coverage problem and cannot be due to the
cell breathing effect.
Duration = 10 min

4 Exercise


4 Exercise
4.1 Discover the consequences of a bad configuration
Discover the consequence(s) of each of the following bad configuration

cases.
 2G cell CI mismatch between UTRAN and BSS


 2G cell CI mismatch between UTRAN and CN


 3G cell LAC mismatch between UTRAN and CN




Duration = 5 min

4 Exercise
4.2 Lesson from the field
Equipment failure or bad configuration problems are often

not detected as such (no alarm or warning message at
the OMC-R)
but they are rather seen as a coverage, interference or
congestion problem through UTRAN QoS indicators.


End of module
Concepts of Radio Fine Tuning


Section 1
Introduction to 3G Radio Fine

Tuning
Module 2
Main UTRAN Algorithms Having an Impact on the QoS
UTRAN

Blank page

Introduction to 3G Radio Fine Tuning · Main UTRAN Algorithms Having an Impact on the QoS
Document History

Module objectives
 Identify the main algorithms which have an impact in the UTRAN QoS
 Find, from a given list of QoS indicators, the ones that are sensitive to the fine
tuning of some of these UTRAN algorithms




Table of contents
1 What are these radio algorithms? 7

1.1 List 8
2 What are the QoS indicators impacted? 9
2.1 Discover QoS indicators related to these algorithms 10




1 What are these radio algorithms?


1 What are these algorithms?
1.1 List
Radio Resource Control Connection Establishment (RRC)
Soft Handover (SHO)
Hard Handover 3G  2G (HHO)
Cell Reselection 3G  2G (CRS)
Radio Link Management (RLM)
Radio Resource Management (RRM)


2 What are the QoS indicators impacted?


2 What are the QoS indicators impacted?
2.1 Discover QoS indicators related to these algorithms
For each of the radio algorithms listed below, find which QoS indicators
listed in the comments page will be affected by a radio fine tuning action?
 RRC
 SHO
 HHO
 CRS
 RLM
 RRM

Duration = 10 min
QoS indicator
Cell addition success rate Nb of cell addition per call
Call drop rate Nb of cell deletion per call
Call setup success rate per service Nb of CM activation per call
Cell update success rate Nb of CM activation per HHO request
Cell update with cause “radio link failure” Nb of HHO request per call
CELL-DCH to CELL-FACH success rate PS Call drop rate
CELL-FACH to CELL-DCH success rate Ratio of AMR calls ended in 2G
CM activation time ratio Ratio of calls started in 3G
(1)
CM activation to deactivation ratio Ratio of users having more than one cell in their AS
SCCPCH load RLC retransmission rate
HHO success rate RLC throughput
Inter-RAT RRC connection ratio RRC connection success rate
Inter-RAT RRC connection success rate Mean Sector Per User
(1)
or Ratio of users in Soft or Softer HO

End of module
Main UTRAN Algorithms Having an Impact on the QoS


Section 2
Tuning key UTRAN algorithms
Module 1
Tune RRC Connection Establishment
UTRAN

Blank page

Tuning key UTRAN algorithms · Tune RRC Connection Establishment
Document History

Module objectives
 Describe the call flow of the RRC connection and the paging procedures
 Explain the algorithms and parameters that can be tune to improve the
performance of these procedures
 Find which QoS indicators can be impacted by this tuning
 Give an example of such a tuning




Table of contents
1 RRC Connection Establishment procedure 7

1.1 Signaling message flow 8
1.2 RRC Connection Setup Repetition by RNC 9
1.3 FACH Power Adjustment and Quick Repeat 10
1.3.1 FACH Power Adjustment setting 11
1.3.2 Quick Repeat setting 12
1.4 Interactions between timers 13
2 Paging procedure 14
2.1 Signaling message flow 15
2.2 Paging Repetition 16
3 Which key parameters to tune? 17
3.1 Estimate the impact of a parameter change 18
4 Which QoS indicators to monitor? 19
4.1 Estimate the impact on QoS indicators 20
5 Example of RRC tuning 21
5.1 Parameter setting 22
5.2 Efficiency of RRC Connection versus radio conditions 23
5.3 Evolution of First RRC Connection Performance 24
5.4 Evolution of RRC Conn. Success & Call Setup Performance 25
5.5 Evolution of RRC Failure Performance 26
5.6 Evolution of Quick Repeat Performance on 1st RRC Setup 27
5.7
2·1·5
Evolution of Quick Repeat Performance on 2nd RRC Setup 28
6 Example
Tuning of· Tune
key UTRAN algorithms paging tuning
RRC Connection Establishment 29
6.1 Parameter setting 30
6.2 Evolution of MSC Paging Performance (first and global) 31
6.3 Evolution of MSC Paging Performance (repetition) 32
6.4 Evolution of UTRAN Paging Records sent (volume) 33
6.5 Evolution of UTRAN Paging Records cancelled (volume) 34
6.6 Evolution of S-CCPCH load 35
6.7 Evolution of Call Setup Success Rate 36



1 RRC Connection Establishment
procedure


1 RRC Connection Establishment procedure
1.1 Signaling message flow
UE Node B SRNC
RRC Connection Request
Sent on?
Radio Link Setup
Request
Radio Link Setup
Response
RRC Connection Setup
Received on?
RRC Connection Setup Complete
Sent on?

Find on which logical / transport / physical Channels the UE receives and sends these messages.

1.2 RRC Connection Setup Repetition by RNC
UE SRNC t351
n351
RRC Connection Request t352
?
1st RRC Connection Setup
? ?
2nd RRC Connection Setup

1st repetition of RRC Connection Setup
?

? repetition of RRC Connection Setup
?
RRC Connection Request

UE retries
isDisableRrcConnSetupRepeatOfiMCRA

T351 is the timer to control the retransmission of the RRC_Connection_Setup.

T352 is the Alcatel-Lucent timer to control the release of UE call context by the RNC.
N351 is the maximum number of retransmissions of RRC Connection Setup at expiry of T351. (When N351=2, the
number of transmissions of this message is 3).
Parameter isDisableRrcConnSetupRepeatOfiMCRA allows one to activate/deactivate the use of t351/n351

repetitions in case an RRC Redirection is decided.
The retransmission of the RRC Connection Setup message based on a quicker timer T351 than T300 will reduce
the call setup duration figures.
By reducing the need of the UE to submit another RRC Connection Request message as a result of the expiry of
timer T300, this feature will also have a positive impact on the RACH capacity.

1.3 FACH Power Adjustment and Quick Repeat
fachPowerAdjustmentCpichEcNoThreshold + deltaCpichEcNoUsedQuickRepeat
fachPowerAdjustmentCpichEcNoThreshold
CPICH_EcNo
No FACH Power Adjustment FACH PA
No Quick Repeat QR
isFachPowerAdjustmentEnabled isQuickPepeatAllowed
(CallAccessPerformanceConf) (CallAccessPerformanceConf)
isFachPowerAdjustmentActivated isQuickPepeatActivated
(FDDCell) (FDDCell)

FACH Power Adjustment and Quick Repeat are key features to secure the establishment of the RRC Connection.

1.3.1 FACH Power Adjustment setting
UE SRNC isFachPowerAdjustmentEnabled
isFachPowerAdjustmentActivated
1st RRC Connection Setup isFachpowerDifferentForSrbTraffic

T351
fachTransmitPowerLevelStep
FACHpower
maxFachPowerRelativeToPcpich
pcpichPower initialFachPowerAdjustment
third RRC
Connection
sccpchPowerRelativeToPcpich second RRC
first RRC Setup
Connection
all other Connection Setup
P-CPICH Setup
FACH
messages

isFachpowerDifferentForSrbTraffic allows one to enable/disable the use of the configured fixed power offset
based on whether the Radio Bearer is Signaling or Traffic. If isFachPowerDifferentForSrbTraffic is TRUE, regardless
of whether isFachPowerAdjustmentActivated (flag to activate FACH power adjustment) is turned on or off, the
configured FACH power offset values based for SRB or TRB are used.
FACH Power as a Function of Type of DL Traffic

The feature differentiates the power level used for FACH channel depending on whether data or signaling is
transmitted. A Boolean switch allows one to choose between the two alternative approaches.
It is possible for the operator to choose one of the following options:
 Power ramping for RRC Connection Setup message based on UE feedback and fixed (same) power for the rest
of signaling and traffic on FACH (UA05 implementation).
 Configurable fixed (different) power level based on whether the FACH frame contains Signaling Radio Bearer
data or Traffic Radio Bearer data.

1.3.2 Quick Repeat setting
isQuickPepeatAllowed
isQuickPepeatActivated
UE RNC-IN RNC-CN
RRC Connection Setup (UM)

RRC Connection Setup
T351
numberOfQuickRepeat
Same power level for all repeated messages


1.4 Interactions between timers
Assume: T351=700 ms, N351=2, nbOfQuickRepeat=3; find the minimum values:

T300 > ___ ms?
T352 > ___ ms?

T300 > 2*RTT + T_proc_rnc + N351*T351 + numberOfQuickRepeat *30 = 300 + 40 + 2*700

+ 3 * 30 = 1830 ms
T352 > N351*T351 + numberOfQuickRepeat *30 + T_mobile = 2*700 + 90 + 800 = 2290 ms

2 Paging procedure


2 Paging procedure
2.1 Signaling message flow
RANAP Paging Type1 (UEid)

RNC 1
Core Network
Iub
4 PI value: 0->1
Paging 2
message 3
PI
..
.
PI Min ( csDrxCynLngCoef , psDrxCynLngCoef )
PI
PI
S-CCPCH PICH
In Idle mode or in Cell_PCH or URA PCH state


2 Paging procedure
2.2 Paging Repetition
RNC MSC
RANAP CS Paging (UEx)

RRC Paging Type 1 (UEx, other UEs) T3113
Initial transmission
RRC Paging Type 1 (UEx, other UEs)
1st retransmission
RRC Paging Type 1 (other UEs)
UEx paging preempted
RRC Paging Type 1 (other UEs) due to PCH overload (e.g.
high paging offered load)

nth retransmission
last retransmission
RANAP Paging (UEx)
nrOfPagingRepetition

There are several reasons for a given UE to miss a paging type 1 message
 Temporary bad radio conditions: the paging message is lost.
 High mobility. If the UE moves from cell A towards cell B, leaves cell A before its paging occasion but reaches
cell B after its paging occasion (the paging occasion of a given UE is different in each cell), then the mobile will
miss the paging message. For these two cases, the Paging Repetition feature may improve the paging
response.

3 Which key parameters to tune?


3.1 Estimate the impact of a parameter change
For each of the RRC Connection or Paging parameter changes below, find
which of the impacts proposed should be observed.
RRC/Paging parameter change impact

pcpichPower
sccpchPowerRelativeToPcpich
fachPowerAdjustmentCpichEcNoThreshold
deltaCpichEcNoUsedQuickRepeat
initialFachPowerAdjustment
fachTransmitPowerLevelStep
numberOfQuickRepeat
nrOfPagingRepetition

Use the following list of impacts:

1. Secure RRC Connection Setup
2. Jeopardize RRC Connection Setup
3. Increase SCCPCH load
4. Decrease SCCPCH load
5. Improve Paging
6. Degrade Paging
Duration = 10 min

4 Which QoS indicators to monitor?


4 Which QoS indicators to monitor ?
4.1 Estimate the impact on QoS indicators
For each of the RRC Connection or Paging algorithm changes below, find
which of the QoS indicators proposed should be impacted and in which way
or or or
QoS indicator First RRC Avg Nb RRC First RRC C Nb of Paging

MO CSSR MT CSSR
SHO behavior Conn. SR Repetitions Setup w QR Cancelled
Speed-up FACH PA
Delay QR
Increase number
of Quick Repetitions
Increase number
of Paging repetition

Use the following list of QoS indicators:

 First RRC Conn. SR = First RRC Connection Success Rate
 MO CSSR = Mobile Originating Call Setup Success Rate
 MT CSSR = Mobile Terminating Call Setup Success Rate
 AvgNb RRC Repetitions = Average Number of RRC Connection Request repetitions per First RRC
Connection Request
 First RRC C Setup wQR = Number of First RRC Connection Setup message sent using Quick Repeat
 Nb of Paging Cancelled = Number of Paging messages scheduled but cancelled before being sent to the UE
Duration = 10 min

5 Example of RRC tuning


5.1 Parameter setting
Fach Power Adjustment Initial Set 1

isFachPowerAdjustmentEnabled true true
isFachPowerAdjustmentEnabled true true
fachPowerAdjustmentCpichEcNoThreshold -12 -8
fachPowerAdjustmentCpichRscpThreshold -115 -115
maxFachPowerRelativeToPcpich 4 4
InitialFachPowerAdjustment 2 3
FachTransmitPowerLevelStep 1 2
Quick Repeat Initial Set 1
isQuickRepeatAllowed true true
isQuickRepeatAllowed true true
numberOfQuickRepeat 3 3
deltaCpichEcNoUsedQuickRepeat -2 -5
deltaCpichRscpUsedQuickRepeat 0 0
n351 1 1
t351 (ms) 700 700
t300 1700 1700
t352 2000 2000

4 parameters are tuned.

5.2 Efficiency of RRC Connection versus radio conditions
RRC Connection Success Rate = f (CPICH_EcNo)

100,0% 100,0%
FACH PA not triggered FACH PA triggered
95,0% 90,0%
80,0%
90,0%
70,0%
85,0%
60,0%
80,0%
50,0%
75,0%
40,0%
70,0%
30,0%
65,0%
20,0%
60,0% 10,0%
55,0% 0,0%
-10.5
-12.0
-13.5
-17.0
-17.5
-10.0
-11.0
-11.5
-12.5
-13.0
-14.0
-14.5
-16.5
-18.0
-15.0
-8.0
-8.5
-9.0
-9.5
-15.5
-16.0
-3.5
-4.0
-5.0
-5.5
-6.5
-7.0
-7.5
-3.0
-4.5
-6.0
RRC CSR Initial RRC CSR Set 1 CPDF Initial CPDF Set 1

RRC Connection establishment improves in bad radio conditions.

5.3 Evolution of First RRC Connection Performance
First RRC Connection

800000 99,50%
700000 99,00%
98,50%
600000
98,00%
500000
97,50%
400000
97,00%
300000
96,50%
200000
96,00%
100000
95,50%
0 95,00%
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
1 -0 8
Fe 8
Fe 8
Fe 8
08
- ja 8
- ja 8
Fe 8
08
Fe 8
Fe 8
Fe 8
08
1 9 v -0
2 0 v -0
2 1 v -0
2 2 v -0
2 3 v -0
2 4 v -0
2 5 v -0
2 7 v -0
2 9 v -0
3 0 v -0
3 1 v -0
0
26 v-0
28 v-0
0
b
b
b
b
nv
n
Fe
Fe
Fe
- ja
9
2
10
11
12
13
18
First RRC Connection Request%50_RRC015_CR First RRC Connection Request%Cs%50_RRC015_CR

First RRC Connection Request%Ps%50_RRC015_CR First RRC Connection Success Rate%50_RRC013_CR
First RRC Connection Success Rate%Cs%50_RRC013_CR First RRC Connection Success Rate%Ps%50_RRC013_CR
First RRC Connection Success Rate%Registration%50_RRC013_CR


5.4 Evolution of RRC Conn. Success & Call Setup Performance
RRC Connection &
CSSR 100,00%
700000
99,00%
600000
98,00%
500000
97,00%
400000
96,00%
300000
95,00%
200000
94,00%
100000 93,00%
0 92,00%
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
- ja 8
1 -0 8
- ja 8
- ja 8
- ja 8
Fe 8
Fe 8
Fe 8
08
Fe 8
08
Fe 8
Fe 8
Fe 8
08
1 9 v -0
2 0 v -0
2 2 v -0
2 4 v -0
2 5 v -0
2 6 v -0
2 7 v -0
2 8 v -0
3 0 v -0
3 1 v -0
21 v-0
23 v-0
29 v-0
0
0
11 b 0
12 b 0
13 b 0
b
b
b
b
nv
n
Fe
Fe
Fe
- ja
8
2
9
10
18
RRC Connection Requests%50_RRC002_CR RRC Connection Requests%Cs%50_RRC002_CR

RRC Connection Requests%Ps%50_RRC002_CR RRC Connection Success Rate%Cs%50_RRC003_CR
RRC Connection Success Rate%InterRAT%50_RRC003_CR RRC Connection Success Rate%Ps%50_RRC003_CR
RRC Connection Success Rate%Registration%50_RRC003_CR Call Setup Success Rate%Cs%50_CSSR005_R
Call Setup Success Rate%Ps%50_CSSR005_R


5.5 Evolution of RRC Failure Performance
Failure Performance
5,00% 30000
4,50%
25000
4,00%
3,50%
20000
3,00%
2,50% 15000
2,00%
10000
1,50%
1,00%
5000
0,50%
0,00% 0
08
08
08
08
08
08
-j a 8
-j a 8
-ja 8
-ja 8
-j a 8
-j a 8
-ja 8
-j a 8
08
08
-ja 8
-j a 8
-j a 8
-ja 8
-j a 8
08
08
19 v-0
-0
-0
-0
-0
-0
-0
-0
-0
-0
-0
-0
-0
-0
b
b
b
b
b
nv
nv
nv
nv
nv
nv
nv
nv
nv
nv
nv
nv
nv
Fe
Fe
Fe
Fe
Fe
Fe
Fe
Fe
n
Fe
Fe
ja
9
6
8
-
11
12
10
13
18
20
23
25
26
27
30
31
21
22
24
28
29
RRC.TotalRRCConnectionReject RRC Connection Failure Ratio%50_RRC018_CR

Radio Bearer Setup Failure Rate%50_RB012_R Average number of RRC repetitions%50_RRC011_CR
RRC Conn Failure Distribution%DLPowerResources%50_RRC017_CR


5.6 Evolution of Quick Repeat Performance on 1st RRC Setup
RRC Con Setup Initial with or without Quick repeat

10,0%
700000
9,0%
600000
8,0%
500000 7,0%
6,0%
400000
5,0%
300000 4,0%
3,0%
200000
2,0%
100000
1,0%
0 0,0%
-ja 08
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
1 -08
2 08
6 08
7 08
8 08
9 08
Fe 8
Fe 8
12 b 0 8
13 b 0 8
08
20 - 0
21 v-0
22 v-0
23 v-0
24 v-0
25 v-0
26 v-0
27 v-0
28 v- 0
29 v- 0
3 0 v- 0
31 v-0
10 b 0
11 b 0
-
nv
nv
nv
b
n
Fe
Fe
Fe
Fe
Fe
Fe
n
Fe
Fe
-ja
18
19
VS.RrcConnectionSetup.InitialWithoutQuickRepeat VS.RrcConnectionSetup.InitialWithQuickRepeat Ratio RrcConnectionSetup.Initial w/w

Ratio of RRC connection setup with Quick Repeat at first RRC connection setup message has increased since Quick
Repeat is triggered earlier (at higher CPICH_EcNo).

5.7 Evolution of Quick Repeat Performance on 2nd RRC Setup
RRC Con Setup First Repetion with or without Quick repeat

60000 40,0%
35,0%
50000
30,0%
40000
25,0%
30000 20,0%
15,0%
20000
10,0%
10000
5,0%
0 0,0%
-ja 08
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
-ja 8
Fe 8
2 08
6 08
7 08
8 08
9 08
Fe 8
Fe 8
12 08
Fe 8
08
20 v-0
21 v-0
22 v-0
23 v-0
24 v-0
25 v-0
26 v-0
27 v-0
28 v-0
29 v-0
30 v-0
31 v-0
-0
10 b 0
11 b 0
13 b 0
-
nv
nv
b
n
Fe
Fe
Fe
Fe
Fe
Fe
-ja
1
18
19
VS.RrcConnectionSetup.FirstRepetitionWithoutQuickRepeat VS.RrcConnectionSetup.FirstRepetitionWithQuickRepeat
Ratio RrcConnectionSetup.FirstRepetition w/w

Ratio of RRC connection setup with Quick Repeat at 2nd RRC connection setup message has increased since Quick
Repeat is triggered earlier and also because of the better effiency of the 1st RRC connection setup message.

6 Example of paging tuning


6.1 Parameter setting
Paging Repetition Initial Set 1 Set 2

isPagingRepetitionAllowed false true true
nbOfPagingRepetition 3 2 1
csDrxCynLngCoef 7 7 7
psDrxCynLngCoef 7 7 7

Paging repetition is activated then 1 parameter is tuned.

6.2 Evolution of MSC Paging Performance (first and global)
Volume and Efficiency of MSC Paging Type 1 (global and first )
1st Pg 2nd Pg

First paging from CN is more efficient when UTRAN Paging repetition is activated.
Global CN Paging efficiency is also improved

6.3 Evolution of MSC Paging Performance (repetition)
Volume and Efficiency of MSC Paging Type 1 (repetition)
1st Pg 2nd Pg

The decrease of the Global CN Paging efficiency is due to the introduction of the UTRAN Paging repetition.

6.4 Evolution of UTRAN Paging Records sent (volume)

The number UTRAN Paging messages to UE increases when the UTRAN paging repetition is activated.

6.5 Evolution of UTRAN Paging Records cancelled (volume)


6.6 Evolution of S-CCPCH load

S-CCPCH carries PCH and FACH blocks. The activation of UTRAN paging repetition increases the proportion of PCH
blocks transmitted on S-CCPCH channels.

6.7 Evolution of Call Setup Success Rate

Is the Call Setup Success Rate indicator sensitive to the activation of the UTRAN Paging repetition?

Module summary
RRC Connection Establishment TUNING
Activate and speed up FACH Power Adjustment algorithm to improve decoding of RRC
Connection Setup message by UE in poor DL radio conditions
Activate Quick Repeat algorithm to improve decoding of RRC connection setup message
by UE in very poor DL radio conditions
Paging TUNING
Activate UTRAN Paging Repetition algorithm to improve the decoding of paging


End of module
Tune RRC Connection Establishment


Section 2
Module 2
Tune Soft Handover
UTRAN

Blank page

Tuning key UTRAN algorithms · Tune Soft Handover
Document History

Module objectives
 Explain the objectives of the Soft Handover algorithm in a UMTS network

 Present the principles of a Soft handover procedure
 Describe the algorithms and parameters that can be tuned to improve the
performance of the different Soft Handover procedures




Table of contents
1 Objectives of Soft Handover algorithms 7

1.1 Objectives 8
1.2 How is this carried out? 9
1.3 Macro-diversity challenge 10
2 Principles of SHO procedures 11
2.1 SHO in 5 steps 12
2.2 Example = Event 1a 13
3.1 Event 1a, 1b 15
3.1.1 Event 1a parameter description 16
3.1.2 Event 1a parameter tuning 17
3.1.3 Event 1b parameter description 18
3.1.4 Event 1b parameter tuning 19
3.2 Event 1c 20
3.2.1 Event 1c parameter description and tuning 21
3.3 Cell Individual Offset in Events 1a, 1b, 1c 22
3.4 Event 1d 23
3.5 Intra-Frequency Filter Coefficient for UE measurements 24
3.6 Estimate the impact of an SHO parameter change 25
5 Examples of Soft Handover tuning
2·2·5
28
5.1 Event
Tuning key 1a vs
UTRAN algorithms Event
· Tune 1b tuning
Soft Handover 29
5.1.1 Parameter setting 30
5.1.2 QoS evolution 31
5.2 ReportingRange, Hysteresis, TimeToTrigger tuning 33
5.2.2 Lesson 35
5.3 Intra-Frequency Filter Coefficient tuning 36
5.3.2 Lesson 38
5.4 Event 1d tuning 39
5.4.1 Parameter setting 40
5.4.2 QoS evolution: HSDPA mobility efficiency 41
5.4.3 QoS evolution: HSDPA throughput 44
5.4.4 QoS evolution: HSDPA call drop 48
5.4.5 QoS evolution: HSDPA CQI 49



1 Objectives of Soft Handover algorithms


1.1 Objectives
Decrease DL interference
reducing the Node-B transmitting power
Decrease UL interference
avoiding near-far effect
reducing the UE transmitting power
Increase Speech Quality

removing speech interruption during cell change
But this has a cost!
More UTRAN resources in use

 BB resources, ALCAP bandwidth, DHT resources
More signaling load

 for Active Set / Monitored Set management
 for SHO procedure

In GSM, soft handover does not exist because the 2 frequencies involved in the handover are always different (GSM
is not a CDMA but an FDMA/TDMA technology) while in the same time the MS is mono receiver.
GSM handovers are then only hard handovers leading to a speech interruption, therefore to a speech degradation.
In a hard handover, the MS is entering the best serving area of a cell before being requested by the network to
handover to that cell. The delay introduced between the moment a neighbor cell becomes better than the serving
cell and the moment the handover takes place is implemented in order to be sure the neighbor cell is really the new
best one. To avoid that, shortly after the handover, a new one is carried out to send back the MS to the cell it was
coming from (ping-pong).
When connecting to the new frequency channel, the MS transmits at full power to maximize the probability of a
handover success. There is no risk of UL interference since we use different frequencies in close cells.
In UMTS, UEs use the same frequency when moving from a serving to a neighbor cell (CDMA technology).
Therefore, hard handovers cannot be used in this case: if the connection to the neighbor cell was delayed until the
new cell is some dB better than the serving one, it would mean that the UE would transmit at higher power level to
maintain the connection on the serving cell thus interfering the UE connected to that neighbor.

1.2 How is this carried out?
Definition of a UE in SHO:
 a UE having more than 1 dedicated Radio Link with the UTRAN
Macro-diversity
 DL radio recombining by the Rake Receiver of the UE
 UL radio recombining by the Rake Receiver of the Node B (in Softer HO)
 UL frame selection by the RNC (in Soft HO only)
Gain in signal decoding


Gain in signal quality (Eb/N0meas) RL1

Gain in signal power (Tx power ) RL2

Gain in interference reduction

The UE being connected to more than 1 Radio Link, the UTRAN DL Tx Power used can be split between several cells
so different TEU boards. Therefore, the DL power load is distributed between more cells, which can reduce the risk
of DL congestion for some of them.
Beyond this DL power load sharing, the macro-diversity gain in DL signal quality makes it possible to decrease the
total DL power used for this UE thus to decrease the DL interference induced.
Similarly in UL, the macro-diversity gain in signal quality makes it possible to decrease the total UL power used by
the UE, thereby decreasing the DL interference induced. Moreover, in the UL case, the macro-diversity gain makes it
possible to reduce the consumption of the battery of the UE.

1.3 Macro-diversity challenge
Signal recombining is possible if some criteria are fulfilled

 The RLs involved in the SHO are “synchronized”
 for power control and for MRC
 “Equal” power levels on the RL
 “Equal” quality on the CPICH, for channel estimation
 Availability of Rake fingers and performance of the Rake algorithm
As a direct consequence to these criteria:

 Any RL that is detected to be out of synchronization is removed to preserve the
Active Set or even the cell capacity (threshold on signal delay between RLs)
 Triggering conditions for SHO must ensure adequate introduction of new RLs in
the Active Set (threshold on signal amplitude between RLs)
 Power control in SHO must ensure harmonized contributions of each cell to the
Active Set (Power Balancing to avoid power drift between DL RLs)
 Active Set size must be limited in terms of number of RLs and in terms of
power range

Pilot bits are fixed bits known by the receiver

 Pilot bits of DPCCH in uplink
 P-CPICH in downlink
Pilot bits are used by the receiver
 toestimate the radio channel between the transmitter and the receiver to find the best received paths and
estimate their delays and amplitudes
 Incase of soft(er) handover and/or several antennas in the receiver, principle is the same, but paths are
searched over all reception antennas, and for all cells
Path searcher:
 estimation of delays i,
 estimation of amplitudes âi
Energy(t)
â2 â3
â1 Adaptive threshold
Time (t)
1 2 3
Received Delay De-spreading Integration on

âi
signal i + de-scrambling pilot bits

2 Principles of SHO procedures


2.1 SHO in 5 steps
SHO mechanism can be sub-divided into:
1
measurements
2
configuration RNC
intra-frequency 4
measurements
event report
3 5
event detection ! SHO command

1. Measurements Configuration:
The SRNC configures the intra-frequency measurements in the UE, which are signaled through either system
information messages (SIB11) or dedicated measurement control messages (via RRC connection):
• Configuration of events 1a, 1b, 1c, 6f or 6g
• List of monitored cells
2. Intra-frequency Measurements:
The UE continuously measures the CPICH Ec/No of the active cells and of the monitored cells.
3. Event Detection:
The UE continuously assesses the conditions of SHO Events on monitored cells (1a, 1c) and on active cells (1b, 6f,
6g).
4. Event Report:
As soon as the conditions of an Event are fulfilled, the UE reports this Event to the RNC in the form of a message.
5. SHO Command:
Upon reception of an Event report, the SRNC decides or not to perform an Active Set Update. It establishes new
radio links and/or deletes existing ones. The Active Set Update is notified to the UE, which acknowledges its
reception.
Note: CPICH Ec/Io (quality) measurement and reporting is Alcatel-Lucent‘s choice. The measurements and reported
values are made on the current cell as well as a maximum number of neighboring cells. Another quantity could
be the CPICH RSCP (level or path loss).

2.2 Example = Event 1a
Event 1a = The addition of a new Radio Link when the quality of the signal measured
on a monitored cell compared to quality of the signal measured on the best active cell
fulfills some conditions (see § 4.3)
1. Measurement Configuration
 Active Set = {cell1}
 Monitored Set = {cell2}
2. Intra-frequency Measurements
cell1
 CPICH Ec/I0 cell1
 CPICH Ec/I0 cell2
3. Event 1a Detection cell2

 Cell2 good enough for a new RL
cell3
4. Event 1a Report
Radio Link
5. SHO Command
 Active Set Update = {cell1, cell2} No Radio Link




3.1 Event 1a, 1b
Event 1a: a monitored cell is good enough to enter the AS

Event 1b: an active cell is not good enough to remain in the AS
CPICH Ec/I0
Best Active Cell 1
R1b+H1b/2
R1a-
H1a/2 cell3
Active Cell 2
cell1
cell2
Monitored
Cell 3
Event 1a = Event 1b =
add cell 3 remove cell 2 Time

Event 1a: condition to add a cell into the Active Set (AS)
 monitored cell: cell in the Monitored Set candidate for entering the AS
 best active cell: best quality cell of the AS
CPICH  Ec / I 0 monitored cell  CIO monitored cell  CPICH  Ec / I 0 best active cell  ( R1a  H 1a 2 )
Event 1b: condition to remove a cell from the Active Set

 worst active cell: worst quality cell of the AS
 best active cell: best quality cell of the AS
CPICH  Ec / I 0 worst active cell  CIO worst active cell  CPICH  Ec / I 0 best active cell  ( R1b  H 1b 2 )
In fact, Quality of the monitored cell or the worst active cell should be compared to the quality of the whole Active
Set computed as:
 N A, j 
CPICH  Ec / I 0 ActiveSet  W x  10  Log   M i , FDDused   (1  W x )  10  LogM
 Best , FDDused
 i 1 
Mbest,j is the quality measured on the strongest cell in the active set of carrier FDDused
Mi,j is the measurement of a cell in the active set of carrier FDDused
NA,j is the number of cells in the active set of carrier FDDused
Wx is a coefficient configurable per event
Range: 0 to 2 (step 0.1), default: 0 (2d_cm,2d_em, 2f, 3a)
But W=0 is used as a default value

3.1 Event 1a, 1b
3.1.1 Event 1a parameter description
CPICH Ec/I0
Best Active cell
Monitored cell
R1a- H1a/2 good enough
to enter the AS
Monitored cell
Time
during T1a
Event 1a report
Detection of event 1A
 The CPICH Ec/Io of some monitored cells enters the reporting range of the Active Set during
timeToTrigger1A.
 The maximum Active Set size is not reached (maxActiveSetSize parameter).
RRC signaling
 MEASUREMENT REPORT, with the list of candidate cells to add to Active Set.
 Reiteration of MEASUREMENT REPORT for event 1a every repInterval1A, if the condition is still fulfilled
AND the maximum amountRep1A has not been reached.

3.1 Event 1a, 1b
3.1.2 Event 1a parameter tuning
R1a: tuned to find a compromise between efficiency of macro-diversity gain

and consumption of radio resources
 H1a and T1a: tuned to find a compromise between reduction of ping-pong
and avoidance of call drop at street-corner
CPICH Ec/I0
Best Active cell
R1a
R1a+ H1a/2
R1a- H1a/2 Monitored cell
H1a
Time
< T1a = T1a Event 1a report
Event 1a conditions
A monitored cell starts being candidate to be added to the AS if
CPICH  Ec / I 0 monitored cell  CIO monitored cell  CPICH  Ec / I 0 best active cell  ( R1a  H 1a 2 )
A monitored cell stops being candidate to be added to the AS if

CPICH  Ec / I 0 monitored cell  CIO monitored cell  CPICH  Ec / I 0 best active cell  ( R1a  H 1 a 2 )
cpichEcNoReportingRange1A shall be set in accordance with rake recombining and macro-diversity gain.
 Indeed, the macro-diversity can bring gain in overlap areas, where single link may become insufficient. But
since radio resources are redundant in macro-diversity, this should be limited to optimize radio resources.
 As a rule of thumb, W-CDMA networks should be designed with overlap areas representing 20% to 30% of
the coverage area. Then, the value should permit the setting of hysteresis1A and
cpichEcNoReportingRange1B.
Standard values are 3,5 dB or 4,5 dB.
hysteresis1A is optional. By definition, it should provide some stability to the Active Set by introducing a stability
margin on the Event 1a criterion. A further parameter that provides stability on Event 1a is the timeToTrigger1A,
see below. Large values are not possible, since we shall keep
R1b - H1b/2>R1a+H1a/2.
Standard values are 2 dB (i.e. 1 dB for H1a/2) and 1 dB.
timeToTrigger1A shall be short, in order to avoid “corner effect” situations.
Standard values are 100 ms and 200 ms. We prefer to avoid 0 ms.

3.1 Event 1a, 1b
3.1.3 Event 1b parameter description
CPICH Ec/I0
Best Active cell
Active cell
not good enough R1b+ H1b/2
to remain in the AS
Active cell
Time
during T1b
Event 1b report

Detection of Event 1b
 CPICH Ec/Io of some of the active cells leaves the reporting range of the Active Set during
timeToTrigger1B.
RRC signaling
 Measurement Report, with the list of candidate cells to remove from the active set.
 The report is not necessarily repeated if the RNC does not send an ‘Active Set update’ message. In
accordance to 3GPP, Event 1b is not repeated by the UE on Layer 3, whereas Events 1a and 1c can be
repeated. Nevertheless, MEASUREMENT REPORT carrying Event 1b is protected by RLC acknowledgement
and when necessary, RLC repetitions.

3.1 Event 1a, 1b
3.1.4 Event 1b parameter tuning
 R1b: tuned to find a compromise between efficiency of macro-diversity

gain and consumption of radio resources
 H1b and T1b: tuned to stabilize the Active Set and limit ping-pong between
1a and 1b
CPICH Ec/I0
Best Active cell
R1b
R1b+
H1b/2
R1b-
H1b/2
H1b
Monitored cell
Time
< T1b = T1b Event 1b report
Event 1b conditions
An active cell starts being candidate to be removed from the AS if
CPICH  Ec / I 0 worst active cell  CIO worst active cell  CPICH  Ec / I 0 best active cell  ( R1b  H 1b 2 )
An active cell stops being candidate to be removed from the AS if

CPICH  Ec / I 0 worst active cell  CIO worst active cell  CPICH  Ec / I 0 best active cell  ( R1b  H 1b 2 )
cpichEcNoReportingRange1B shall be in accordance with rake recombining and macro-diversity gain, as for
cpichEcNoReportingRange1A. Then, the value should permit the setting of hysteresis1B and
cpichEcNoReportingRange1A. Standard values are 6,5 dB and 7,5 dB.
hysteresis1B is optional. By definition, it should provide some stability to the Active Set by introducing a stability
margin on the Event 1b criterion. A further parameter that provides stability on Event 1b is the
Event1b.TimeToTrigger, see below. Large values are not possible, since we shall keep R1b-1b/2>R1a+H1a/2.
Standard value is 1 dB.
TimeToTrigger1B shall be quite long, in comparison with timeToTrigger1A and timeToTrigger1C, to stabilize
the Active Set and limit ping-pong.
Standard values are 640 ms and 1280 ms.

3.2 Event 1c
If the active set has reached a defined size

 Event 1c: a monitored cell is good enough to enter in the AS and replace
the worst active cell, which is removed
CPICH Ec/I0
Worst Active cell 2
cell3
cell1
H1c/2
cell2
Monitored
cell 3
Event 1c = replace cell 1 by cell 2
Time
Event 1c: condition to replace a cell in the Active Set

 monitored cell: cell in the Monitored Set candidate for entering the AS
 worst active cell: worst quality cell of the AS
CPICH  Ec / I 0 monitored cell  CIO monitored cell  CPICH  Ec / I 0 worst active cell  CIO worst active cell  ( H 1c 2 )
Event 1c conditions
A monitored cell starts being candidate to replace the worst quality cell of the AS if
CPICH  Ec / I 0 monitored cell  CIO monitored cell  CPICH  Ec / I 0 worst active cell  CIO worst active cell  ( H 1c 2 )
A monitored cell stops being candidate to enter the AS if

CPICH  Ec / I 0 monitored cell  CIO monitored cell  CPICH  Ec / I 0 worst active cell  CIO worst active cell  ( H 1c 2 )

3.2 Event 1c
3.2.1 Event 1c parameter description and tuning
Max Active Set Size: tuned to find a compromise between efficiency of

macro-diversity gain and consumption of radio resources
H1c and T1c: tuned like 1a to find a compromise between reduction of ping-
SHO Parameters
pong and avoidance of call drop at street-corner
CPICH Ec/I0
Worst Active cell

Monitored cell
H1c
Time
< T1c = T1c Event 1c report

hysteresis1C shall be equal or lower than cpichEcNoReportingRange1A, since there is the same issue on
“corner effect” situations. Standard value is 7,5 dB, resulting in 3,75 dB for H1c/2, being lower than RR1a-H1a/2
(i.e. 4 dB).
timeToTrigger1C shall be comparable to timeToTrigger1A, since there is the same issue on “corner effect”
situations.
Detection of Event 1C:

If the Active Set has reached a certain size (e.g. contains 3 or more active cells) and the CPICH Ec/Io of a
monitored cell becomes better than the worst active cell during Event1c.TimeToTrigger
RRC signaling
MEASUREMENT REPORT Event 1c containing the candidate cells to add to the active set and the candidate cells to
remove from it. (Repetition of MR for Event 1c like for the MR for Event 1a).

3.3 Cell Individual Offset in Events 1a, 1b, 1c
Tuning of Event parameters (R1x, T1x, H1x) cannot be done at Cell level
Solution: use the neighbouringCellOffset cell parameter {-10,10}
step=0.5dB which is defined per couple of cells (serving, target)
Example for Event 1a: CIOcell2>0  Speed-up Event 1a triggering

R1a - H1a/2
Add cell 2
CIOcell2
neighbouringCellOffset
Add cell 2 (UMTSNeighbouringRelation)
best active cell 1 monitored cell 2

CPICH  Ec / I 0 monitored cell  CIO monitored cell  CPICH  Ec / I 0 best active cell  ( R1a  H 1 a 2 )
neighbouringCellOffset can be >0 or <0

 By applying a positive CIO, the UE sends Measurement Reports, as if the primary CPICH is offset x dB
better than what it really is.
 By applying a negative CIO, the UE limits the reporting and the corresponding cell may be, at least
temporarily, excluded from the active set or as a target cell for handover.
The neighbouringCelloffset can be seen as a tool to move the cell border. It is important to note that the offset
is added before triggering events, i.e. the offset is added by the UE before evaluating if a measurement report
should be sent as opposed to offsets that are applied in the network and used for the actual handover evaluation.

3.4 Event 1d
H1d and T1d: tuned to find a compromise between reduction of ping-pong

and avoidance of maintaining too long the HS-DSCH radio bearer on a cell
which is not the best cell anymore
CPICH Ec/I0
Current
Primary Cell
H1d
Second Best
AS Cell
Time
< T1d = T1d Event 1d report

Event 1C is triggered when a new P-CPICH becomes better than an active P-CPICH.
Event 1C is used to replace an RL based on relative criteria when the Active Set is full.
The variables in the formula are defined as follows:

 MNew is the measurement result of the cell not included in the active set.
 CIONew is the individual cell offset for the cell becoming better than the cell in the active set if an individual cell
offset is stored for that cell. Otherwise, it is equal to 0.
 MInAS is the measurement result of the cell in the active set with the lowest measurement result.
 CIOInAS is the individual cell offset for the cell in the active set that is becoming worse than the new cell.
 H1c is the hysteresis parameter for the event 1c.
Note: The above drawing shows an example assuming that the maximum AS size is set to 2 and that all the CIOs
are set to 0 dB.

3.5 Intra-Frequency Filter Coefficient for UE measurements
The UE performs periodical intra-frequency measurements of active and

monitored cells rrcIntraFreqMeasurementFilterCoeff
 raw measurements period = 200 ms (RRCMeasurement)
The UE performs a recursive averaging of these measurements

 forgetting factor = 1/2(k/2) with k= rrcIntraFreqMeasurementFilterCoeff
Example 1 2 3 4 5 6 7 8 9 10
0
Raw CPICH Ec/I0
-2
CPICH Ec/I0
-4 CPICH Ec/I0 averaged

with k=2
-6
CPICH Ec/I0 averaged
-8 with k=4
-10 CPICH Ec/I0 averaged

with k=8
-12
UE measurements

Within the UE, the measurement should be performed every 200 ms. The measurement result is filtered to smooth
variations as in 3GPP TS25.331.
FN = (1-a) FN-1 + a MN
 FN is the updated filtered measurement result
 FN-1 is the old filtered measurement result
 MN is the latest received measurement result from physical layer measurements
 a = 1/2k/2, where k is the parameter rrcIntraFreqMeasurementFilterCoeff received in the IE
"Filter coefficient".
To deduce the average time associated with the Filter Coefficient,
Tavg = 200 ms / 1/2k/2
In MEASUREMENT REPORT triggered by events 1a, 1b, and 1c, CPICH Ec/Io is reported for all the active cells and
for the monitored cells that are fulfilling the conditions for the triggering event.
The table below contains the values of the UE measurements displayed as an example in the chart above:
Raw measurements (every 200ms) 1 2 3 4 5 6 7 8 9
Raw CPICH Ec/I0 -11,0 -11,0 -11,0 -5,0 -5,0 -5,0 -5,0 -5,0 -5,0
CPICH Ec/I0 averaged with k=2 -11,0 -11,0 -11,0 -8,0 -6,5 -5,8 -5,4 -5,2 -5,1

3.6 Estimate the impact of an SHO parameter change
For each of the SHO parameter changes below, find which of the impacts
proposed should be observed.
SHO parameter change impact

cpichEcNoReportingRange1A
hysteresis1B
timeToTrigger1C
cpichEcNoReportingRange1B
hysteresis1D
timeToTrigger1B
neighbouringCellOffset
rrcIntraFreqMeasurementFilterCoeff


1. delay cell addition
2. delay cell replacement
3. delay cell deletion
4. delay Primary cell change
5. speed-up cell addition
6. speed-up cell replacement
7. speed-up cell deletion
8. speed-up Primary cell change
Duration = 10 min



For each of the SHO behavior changes below, find which of the QoS
indicators proposed should be impacted and in which way or
QoS indicator Mean Sector AS Upd per ASU Success RL Addition RL Deletion Nb of
SHO behavior Per User sec per RL Rate Efficiency Efficiency Event1x
delay cell addition
delay cell deletion
speed-up cell replacement
increase risk of ping-pong

between cell addition and
deletion
Delay Primary cell change


 Mean Sector Per User = Average number of RLs per user (average number of cells in the AS per user)
 AS Upd per sec per RL = Average number of Active Set Update messages sent to a UE per second
 ASU Success Rate = Active Set Update success rate
 RL Addition Efficiency = Active Set Update Success Rate for Event1A reason only
 RL Deletion Efficiency = Active Set Update Success Rate for Event1A reason only
 Nb of Event1x = Number of Measurement Report messages received from a UE relating to the Event1x (1
indicator per Event type: 1A, 1B, 1C)
Duration = 10 min



5.1 Event 1a vs Event 1b tuning
What is the problem of the following setting?

SHO parameter Event 1a Event 1b
Reporting Range 6 6
Hysteresis 2 2
Time To Trigger 200 1280
 Ping-pong between Branch addition and branch deletion since

 a monitored cell is added to the AS when
CPICH Ec/I0(monitored cell) – CPICH Ec/I0(best active cell)  - 6.9 dB
 an active cell is removed from the AS when
CPICH Ec/I0(active cell) – CPICH Ec/I0(best active cell)  - 5.1 dB
Modify SHO parameters to fulfill the rule

R1b – H1b/2 > R1a + H1a/2


5.1 Event1a vs Event1b tuning
5.1.1 Parameter setting
Modification
SHO parameter Event 1a Event 1a Event 1b Event 1b

Old new Old new
Reporting Range 6 3 6 6
Hysteresis 2 0 2 0
Time To Trigger 200 200 1280 240
Expected impacts: Delay branch addition, speed-up branch deletion

 improvement of radio quality on active cells
 decrease of radio resource usage
See QoS evolution next page


5.1.2 QoS evolution
SHO - branch addition vs Call Setup

140000 10.0
120000 old new 9.0

8.0
100000 7.0
Less branch addition

80000 6.0
5.0 SHO request
60000 4.0
Less users in SHO

40000 3.0 sho / setup
2.0
20000
1.0
0 0.0
01/02/2005
02/02/2005
03/02/2005
04/02/2005
05/02/2005
06/02/2005
07/02/2005
08/02/2005
09/02/2005
10/02/2005
11/02/2005
12/02/2005
13/02/2005
SHO - branch deletion vs Call Setup
70000 5.0
60000 old new 4.5

4.0
Slight decrease of
50000 3.5
40000 3.0
2.5
SHO request
30000
branch deletion
2.0
20000 1.5 sho / setup
1.0
10000
0.5
0 0.0
01/02/2005
02/02/2005
03/02/2005
04/02/2005
05/02/2005
06/02/2005
07/02/2005
08/02/2005
09/02/2005
10/02/2005
11/02/2005
12/02/2005
13/02/2005

Decrease in Branch addition means that there are now less resources in use due to SHO.
Decrease in SHO/call_setup rate means there are now less users in SHO.
Slight decrease in branch deletion whereas the Event 1b has been fasten means that there are now less useless
branch additions than before.

5.1.2 QoS evolution [cont.]
User RL RNC
600 85%
500
old new 80%
> 1RL
75% 1 RL
Less radio links per

400
70%
300 % 1 RL
65%
200
100
60%
55%
user
0 50%
01/02/2005
02/02/2005
03/02/2005
04/02/2005
05/02/2005
06/02/2005
07/02/2005
08/02/2005
09/02/2005
10/02/2005
11/02/2005
12/02/2005
13/02/2005
Trans RL User
500 90%
450 old new 88%
400 86%
350 84% > 1 NodeB
Less transmission
300 82% 1 NodeB
250 80%
% 1 NodeB
links per user

200 78%
150 76%
100 74%
50 72%
0 70%
01/02/2005
02/02/2005
03/02/2005
04/02/2005
05/02/2005
06/02/2005
07/02/2005
08/02/2005
09/02/2005
10/02/2005
11/02/2005
12/02/2005
13/02/2005
but…check Call_drop_rate and SHO_rate values

% of users having 1 RL compared to all users in DCH means that there are less radio resources in use due to SHO.
% of users in DCH with 1 Node-B means that there are less Iub/Iur transmission resources in use due to SHO.

5.2 ReportingRange, Hysteresis, TimeToTrigger tuning
Find the expected impacts of each SHO parameter set implementation.

Find the expected QoS indicator evolution.
SHO
SHO 0 SHO1 SHO2 SHO3
cpichEcNoReportingRange1A 3 3 4 4
Event1a.Hysteresis 0 0 0 2
cpichEcNoReportingRange1B 6 6 6 6
Event1b.Hysteresis 0 0 0 0
hysteresis1C 3 3 3 3
timeToTrigger1A 200 120 120 120

timeToTrigger1B 320 640 640 640
timeToTrigger1C 200 120 120 120
Intrafreq.FilterCoefficient 4 4 4 4


5.2.1 QoS evolution
Verify your expectations.
RNO KPI SHO 0 SHO 1 SHO 2 SHO 3

AMR 91678 86936 92969 82403
CS64 1742 1407 1821 1554
PS 15455 13193 14333 14096
% AMR Drop 0,64% 0,51% 0,52% 0,63%
% CS System drop 1,80% 1,54% 1,71% 1,55%
% PS System drop 17,31% 17,78% 16,34% 15,38%
% SHO 21,1% 22,4% 26,2% 24,5%
#SHO req/call 3,91 3,97 5,04 4,11
#SHO del/call 2,91 2,84 3,77 2,90


5.2.2 Lesson
Guessing the effects of a fine tuning is not so obvious

SHO0SHO1 SHO1SHO2 SHO1SHO3
% SHO
% drop
Optimized setting of SHO parameters is not easy to find

 Several different combinations of parameter values can give similar results
The idea is to find a compromise between:

 % of users in SHO high enough to avoid call_drop (> 20%)
 % of users in SHO low enough to avoid congestion (< 40%)


5.3 Intra-Frequency Filter Coefficient tuning
IntraFreq.FilterCoef changed from 4 to 3

 Averaging process of UE measurements is more reactive
Expected impacts on SHO behavior

 Speed-up branch addition and deletion
+ Avoid call drop (especially at street-corner)
– Increase radio and transmission resource consumption (risk of congestion)
Expected impacts on QoS indicators

 SHO_req/call (branch addition per call) 
 SHO_del/call (branch deletion per call) 
 % SHO 
 % drop 


5.3.1 QoS evolution
Results on QoS indicators

 SHO_req/call (branch addition per call)  as expected
 SHO_del/call (branch deletion per call)  as expected
 % SHO  not as expected: because SHO_req/SHO_del (more ping-pong)
 % drop  not as expected: because % SHO 
IntraFreq.FilterCoef ---> 4 3
AMR 72454 69127 Conclusion:
CS64 1169 1091
+ Street-corner effect is reduced
PS 14315 12928 + Risk of congestion is reduced
% AMR Drop 0,99% 0,97%
– AMR Call drop has not decreased
% CS System drop 1,46% 1,44% – PS Call drop has increased
% PS System drop 13,11% 13,65% – Signaling load has increased
% SHO 24,3% 22,3%
#SHO req/call 4,57 5,16
#SHO del/call 3,32 3,83


5.3.2 Lesson
Too soft filtering should be avoided

 Fast decrease of radio signal strength at street-corner leads to a call drop
0
M e a s u re m e n t re p o rt s e n d w ith
-5 a c c e p ta b le E c /Io filte re d b u t th e
In s ta n ta n e o u s v a lu e s s h o w u s
th a t is to o la te in te rm o f re a l
ra d io c o n d itio n
-1 0
F ilte r C o e ffic e n t b e n e fit in
c a s e o f fa d in g h o le .
-1 5
-2 0
-2 5
-3 0
1 13 25 37 49 61 73 85 97 109 121 133 145 157 169 181 193 205 217 229 241 253 265 277 289 301 313 325 337 349 361 373 385 397 409 421 433 445
E c/Io in s ta n ta n e o u s E c/Io filte re d U E re p o rte d

IntraFreq.FilterCoef is used to smooth rapid variations of radio signal in order to avoid unnecessary SHO on
fading holes:
UE measurements (no filtering)
Filter Coefficient = 5
Filter Coefficient = 11
-3
-3.5
-4
-4.5
-5
-5.5
-6
-6.5
-7
-7.5
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 113 120 127 134 141 148 155 162 169 176 183 190 197 204 211 218 225 232 239 246 253 260
EC/N0 instantaneous EC/N0 with FC5 EC/N0 with FC11

5.4 Event 1d tuning
Objective: find an optimized Event1d parameter setting to achieve the best

compromise between
 HSDPA mobility efficiency

 HSDPA throughput
 HSDPA call drop
Primary Cell Change leads to an HSDPA transfer interruption since HSDPA

is a non-SHO technique
 HSDPA throughput and HSDPA call drop can occur
If Primary Cell is not the best of the Active Set, the HS-DSCH radio link is
not the best
 HSDPA througput and call drop can also occur


5.4 Event 1d tuning
5.4.1 Parameter setting
Set 0 Set 1 Set 2 Set 3 Set 4 Set 5
Parameter 04/11/08 12/11/08 24/11/08 02/12/08 08/12/08
Hysterisis1d 4 6 6 4 4 6
Timetotrigger1d 640 640 1280 1280 320 320


5.4 Event 1d tuning
5.4.2 QoS evolution: HSDPA mobility efficiency

Mobility is lower if theEvent1D trigger is delayed.

5.4 Event 1d tuning
5.4.2 QoS evolution: HSDPA mobility efficiency [cont.]

Set2 and Set3 values are too large since Event1D vs Mobility HSDPA/HSDPA is less than 1.

5.4 Event 1d tuning
5.4.2 QoS evolution: HSDPA mobility efficiency [cont.]

Set3 and Set4 show good stability of HSDPA Intra-freq mobility performance.

5.4 Event 1d tuning
5.4.3 QoS evolution: HSDPA throughput

Set3, Set4 and Set5 show a slight degradation of the NACK ratio.

5.4 Event 1d tuning
5.4.3 QoS evolution: HSDPA throughput [cont.]

The magnitude of the Retransmission Rate variations are different according to the Set but the average is not so
different.

5.4 Event 1d tuning

The highest HSDPA throughput values are observed with Set1.

5.4 Event 1d tuning

The lowest HSDPA Call Drop Rate values are observed with Set1.

5.4 Event 1d tuning
5.4.4 QoS evolution: HSDPA call drop

The lowest HSDPA Call Drop Rate values are observed with Set1.

5.4 Event 1d tuning
5.4.5 QoS evolution: HSDPA CQI


5 Tune Soft Handover
Summary
SHO TUNING
Soft handover has been intensively optimized on 3G commercial networks
with statistical analysis, but with parameter settings at the RNC level.
Following situations are encountered, in which SHO optimization brings

substantial improvements:
 Corner effect
 Radio resurgences
 Interaction with configuration of compressed mode

Corner effect: the serving cell is dropping dramatically, while a monitored cell is suddenly at good level and good
CPICH Ec/Io
Radio resurgences: a monitored cell is suddenly received with good level and good CPICH Ec/Io
Interaction with configuration of compressed mode: multiple Active Set modifications are managed in the
same moment, as configuration for compressed mode

Summary – UE measurements tuning
Intra-Frequency Filter Coefficient

Ensure a trade-off between:
 too fast reporting on rapid changing radio conditions where RL addition or
deletion wants to be avoided (fading holes, pilot pollution or shadowing )
 too slow reporting on rapid changing radio conditions where RL addition or
deletion wants to be secured (corner effect)
Improvements with low value (2) were observed in conditions where the
serving cell is dropping dramatically, while a monitored cell is suddenly at
good level (so-called “corner effect”).

With a low rrcIntraFreqMeasurementFilterCoeff, the algorithms based on measurements, such as the Soft
Handover, will become more reactive.
This increased reactivity should help avoiding critical 3G cases, where the Ec/Io suddenly decreases and the DL
radio synchronization is then lost.
Such situations often occur on field and are characterized at the Drive Test with lot of RRC MEASUREMENT REPORT
without any RRC ACTIVE SET UPDATE received by the UE.
But, the high reactivity may cause the triggering of unneeded Soft Handover, when the serving signal is faded.

Summary – SHO Events triggering tuning
Reporting Range 1a, Reporting Range 1b

Ensure a good efficiency of rake recombining and macro-diversity gain
Time To Trigger 1a
shall be short enough, in order to avoid “corner effect” situations. Recommended
values are 100 ms and 200 ms. We preferred to avoid 0 ms.
shall not be too short, in order to trigger unnecessary Event1a on deep but short signal
variations.
Hysteresis 1a
Allow one to limit the risk of unnecessary Event1a in case TimeToTrigger1a
cannot be increased enough
Time To Trigger 1b
Shall be quite long, in comparison with TimeToTrigger1a, to stabilize the
Active Set and limit ping-pong between Event1a and Event1b.
Recommended values are 640 ms and 1280 ms.


End of module
Tune Soft Handover


Section 2
Module 3
Tune 3G-2G Hard Handover
UTRAN

Blank page

Tuning key UTRAN algorithms · Tune 3G-2G Hard Handover
Document History

Module objectives
 Explain the objectives of the Hard Handover algorithm in a UMTS network

 Present the principles of a Hard handover for Alarm reason procedure
performance of the Hard Handover for Alarm reason procedure




Table of contents
1 Objectives of inter-RAT HHO algorithms 7

1.1 Objectives 8
1.2 Strategy 9
2 Intelligent Multi-Carrier Traffic Allocation 10
2.1 iMCTA enhanced 11
3 Principles of inter-RAT HHO procedures 14
3.1 Introduction 15
3.2 Inter-RAT HHO for Alarm reason 16
4 Which key HHO parameters to tune? 17
4.1 HHO activation and blind HO parameters 18
4.2 Event 2d parameters and GSM eligibility criteria 19
4.3 Event 2f parameters 20
4.4 Estimate the impact of a 3G2G HHO parameter change 21
6 Examples of inter-RAT HHO tuning 24
6.1 Inter-RAT HHO tuning 25
6.2 Default: Set1 tuning 26
6.3 Verify your expectations – Default to Set1 tuning 27
6.3.1 Set1 to Set2 tuning 28
6.3.2 Verify your expectations – Set1 to Set2 tuning 29
6.3.3
2·3·5
Set2 to Set3 tuning 30
6.3.4 Verify
Tuning key UTRAN your
algorithms · Tune expectations – Set2 to Set3 tuning
3G-2G Hard Handover 31
6.3.5 Conclusion on Set1, Set2, Set3 tuning / Default 32
6.3.6 Inter-RAT HHO and CM tuning – Lesson 33



1 Objectives of inter-RAT HHO
algorithms


1 Objectives of inter-RAT HHO algorithms
1.1 Objectives
The objective is two fold:
 To provide service continuity

 2G acts as a rescue layer when 3G layer coverage or quality becomes
too bad
 Quality and Emergency handovers
 To optimize the radio resources of the PLMN

 favor data calls on 3G layer
 favor voice calls on 2G layer
 Service handovers

Due to the higher frequency band used in UTRAN FDD compared to GSM, the cell ranges are smaller in 3G than in
2G. Therefore, at the beginning of 3G roll-out and even if each 2G site is upgraded to 3G, the 3G coverage is not
good enough (especially in suburban and rural areas).
When the 3G service penetration is not sufficient, operators’ strategy is now to make the best use of their 3G
equipments by forcing combined 3G/2G users to camp and stay on the 3G layer as long as Quality of Service
remains good.

1 Objectives of Inter-RAT HHO algorithms
1.2 Strategy
3G to 2G transitions may happen all over the network

 In the 3G border areas, e.g. at the limit of suburban areas
 In deep-indoor areas, when 2G in-building coverage is not yet 3G
 In 3G coverage holes, e.g. in case of site delay
Common strategy is to keep 3G subscribers on 3G layer
 To promote 3G services
 To limit impact on 2G networks (CN and RAN)
S02M03 1
3G
AMR call set-up 3G Coverage
HO
2 3G2G
3 2G3G 4
3G2G cell reselection 2G Coverage
AMR call end
S02M04

Using Alcatel-Lucent BSS B8, 2G to 3G handover was not possible. Therefore, in case of 3G to 2G handover, the call
ended in 2G before forcing the UE to reselect the 3G layer.
Using Alcatel-Lucent BSS B9 and onwards, 2G to 3G handover is possible. Therefore, in case of 3G to 2G handover,
the call can be transferred back to 3G. However, a good parameter setting should ensure that the Quality of Service
is degraded by ping-pong handovers between 3G and 2G layers.

2 Intelligent Multi-Carrier Traffic
Allocation


2 Intelligent Multi-Carrier Traffic Allocation
2.1 iMCTA enhanced
iMCTA Triggering
iMCTA validity checking (checking activation
parameters, identifying Service Type & RAB)
iMCTA Algorithm NEW: support of AO upsize trigger for Service &
CAC
iMCTA validity checking NEW: ability to use HSPA load criteria instead of
DCH Load criteria
iMCTA configuration retrieval
Blind HO processing
iMCTA configuration retrieval to select the right
Blind HHO execution iMCTA Priority table
NEW: Priority list processing for AO upsize trigger
Neighboring cells NEW: Support of 12 FDD carriers for Alarm, CAC
searching and filtering and Service priority tables
Configuration of CM &
of UE measurements NEW: Decision for Blind HO if applicable cell
retrieved – no measurements configured
Measurement report processing NEW: iMCTA Alarm or CAC fallback if Blind HO
fails
iMCTA HHO execution or exit


2.1 iMCTA enhanced [cont.]
NEW: Neighboring cell searching & filtering
iMCTA Triggering for
Radio Access Selection for “Blind HO”;
NEW: HSPA load criteria instead of DCH
iMCTA Algorithm Load Criteria & load color BLACK
iMCTA validity checking
iMCTA configuration retrieval Neighboring cell searching & filtering for Radio
Access Selection for “Meas based HO”;
Blind HO processing NEW: HSPA load criteria instead of DCH Load
Criteria & load color BLACK;
Blind HHO execution NEW: limitation to 2 FDD carriers for IFREQ
radio measurement
Neighboring cells Pre-check for IFREQ measurements to avoid
searching and filtering triggering measurements for FDD overloaded
Access layers
Configuration of CM &
of UE measurements
Measurement report processing Configuration of CM & of the UE measurements

to provide Node B and UE with complete
measurement info (CM & neighboring cell list
corresponding to selected RAT);


2.1 iMCTA enhanced [cont.]
iMCTA Triggering
iMCTA Algorithm
iMCTA validity checking
iMCTA configuration retrieval

Blind HO processing
Blind HHO execution Measurement report processing to process all

RRC Measurement Reports sent by the UE
Neighboring cells NEW: synchronization to wait for favored carrier
searching and filtering (FDD or GSM) MEAS report;
NEW: new configuration for EcNo & RSCP Target
Configuration of CM & Cell Threshold
of UE measurements
Measurement report processing

iMCTA HHO processing or iMCTA exit
NEW: iMCTA Alarm or CAC fallback if
Measurement based HO fails


3 Principles of inter-RAT HHO procedures


3 Principles of inter-RAT HHO procedures
3.1 Introduction
The following 3G to 2G handover types are supported:
 3G to 2G handover for CS/PS domain in blind mode.

 3G to 2G handover for CS/PS domain with measurements (with or without
Compressed Mode).
Handover Preparation phase is based on HHO triggered by iMCTA


3 Principles of Inter-RAT HHO procedures
3.2 Inter-RAT HHO for Alarm reason
UE UTRAN
Call establishment
Meas. Control (id=11) Handover Preparation:

CPICH_EcNo (2d,2f)1 Based on HHO triggered by iMCTA
Meas. Control (id=12) UTRAN configures UE measurements and
UE CPICH_RSCP (2d,2f)1 conditions for Alarm HHO (event 2d,2f)1
measurements2
UE triggers event 2d if QUALITY on
Meas. Report (2d,CPICH_EcNo)4 current 3G cell is becoming bad3
Meas. Control (id=3) 

Inter-RAT (2G neigh.,CM)5 UTRAN starts inter-RAT measurements5
Meas. report (id=3) 

2G neigh (GSM RSSI,BSIC)6 UE reports measurement on 2G neighbors6
HO from UTRAN command7 

UTRAN triggers a 3G-2G HHO

The call flow above is valid for an Alarm HHO. Service Handovers follow a different procedure.
1. Measurements and Events Configuration:
The SRNC configures some intra-freq measurements in the UE, which are signaled through a dedicated Measurement Control message (via RRC
connection):
 Start monitoring events 2d and 2f for CPICH_EcNo and CPICH_RSCP
 List of monitored cells
2. Intra-freq Measurements for Inter-freq or Inter-RAT HHO:
The UE continuously measures the CPICH Ec/No or the CPICH RSCP of the active cells and of the monitored cells.
3. Event Detection:
The UE continuously assesses the conditions of HHO Events on active cells (2d, 2f).
4. Event Report:
As soon as the conditions of an Event 2d are fulfilled, the UE reports this Event to the RNC in the form of a Measurement Report message.
5. Inter-RAT Periodical Measurements Configuration:
The SRNC configures inter-RATq measurements in the UE, which are signaled through a dedicated Measurement Control message (via RRC
connection):
 Quantities measured:
 GSM RSSI (BCCH RxLevel)
 BSIC
 List of 2g neighboring cells
6. Inter-RAT Measurements:
The UE measures the BCCH RxLevel of the 2G neighboring cells and decodes the BSIC of the best received ones.
7. HHO Command:
Upon reception of an Event report, the SRNC decides or not to perform an inter-RAT HHO:
 The SRNC sends a Relocation Required message to the MSC controlling the target GSM cell.
 The MSC proceeds with the preparation of the incoming handover in the target BSS then it sends a Relocation Command message to
SRNC. The Relocation Command contains a Layer 3 information IE which is the Handover Command message that has been built up by
the target BSC to be sent to the UE.
 The SRNC sends a Handover from UTRAN command to the UE which will proceed with the handover to the target channel.

4 Which key HHO parameters to tune?


4.1 HHO activation and blind HO parameters
RNC
RadioAccessService
HHO Activation Parameters Blind HO Parameters

activationHoGsmCsAllowed isBlindHoRescueAllowed
activationHoGsmPsAllowed isBlindHoGsmAllowed
isInterFreqMeasActivationAllowed blindHoGsmNeighbourTargetCgi
isGsmIratHoToNextBestCellAllowed

activationHoGsmCsAllowed indicates if the handover CS toward GSM is allowed.

activationHoGsmPsAllowed indicates if the handover PS toward GSM/GPRS is allowed.
isGsmIratHoToNextBestCellAllowed enables/disables the IRAT handover to the next best GSM cell if handover
is not possible to the first cell due to overload.
isBlindHoRescueAllowed indicates if blind handover for iMCTA Alarm is allowed for this RNC.
isBlindHoGsmAllowed indicates, if true, that the blind handover towards GSM is allowed for iMCTA Alarm when
the Primary Cell belongs to a Drift RNC.
The target GSM cell to use in case of blind handover is indicated by the parameter
blindHoGsmNeighbourTargetCgi.

4 Which key HHO parameters to tune ?
4.2 Event 2d parameters and GSM eligibility criteria
Qmeas (CPICH EcNo,RSCP)  cpichxxxxThresholdUsedFreq2D - hysteresis2D / 2

Qmeas (3G cell3) RNC
during timeToTrigger2D
T2d
H2d BSC
TTT2d t
Node B
GSM RSSI (2G cell2) UTRAN
cell3
GSM cell2
BTS
T2Gcell
GSM cell1
t
GSM carrier RSSI (2Gcell) > minimumGsmRssiValueForHO

xxxx = EcNo if Qmeas = CPICH_EcNo

xxxx = Rscp if Qmeas = CPICH_RSCP

4.3 Event 2f parameters
Event 2f: Qmeas (CPICH EcNo,RSCP)  cpichxxxxThresholdUsedFreq2f + hysteresis2f/2
Qmeas
Event2d
Event2d
Event2f
entering 2f reporting range
2f absolute threshold
leaving 2f reporting range
leaving 2d reporting range

2d absolute threshold
entering 2d reporting range
Best Cell
Event 2d: Qmeas (CPICH EcNo,RSCP)  cpichxxxxThresholdUsedFreq2D -hysteresis2D/2

xxxx = EcNo if Qmeas = CPICH_EcNo

xxxx = Rscp if Qmeas = CPICH_RSCP

4.4 Estimate the impact of a 3G2G HHO parameter change
For each of the inter-RAT HHO parameter change below, find which of the
impacts proposed should be observed
HHO parameter change impact

cpichEcNoThresholdUsedFreq2D
hysteresis2f
timeToTrigger2D
cpichRscpThresholdUsedFreq2f
hysteresis2d
timeToTrigger2f
minimumGsmRssiValueForHO
rrcGsmMeasurementFilterCoefficient


1. delay Alarm HHO 3G2G for CPICH_EcNo reason
2. delay Alarm HHO 3G2G for CPICH_RSCP reason
3. speed-up Alarm HHO 3G2G for CPICH_EcNo reason
4. speed-up Alarm HHO 3G2G for CPICH_RSCP reason
5. increase the rate of Alarm HHO 3G2G per call for CPICH_EcNo reason
6. increase the rate of Alarm HHO 3G2G per call for CPICH_RSCP reason
7. decrease the rate of Alarm HHO 3G2G per call for CPICH_EcNo reason
8. decrease the rate of Alarm HHO 3G2G per call for CPICH_RSCP reason
Duration = 10 min



5 Which QoS indicators to monitor
For each of the inter-RAT HHO behavior changes below, find which of the
QoS indicators proposed should be impacted and in which way
or or or depends
QoS indicator HHO CM Activation HHO per CM Activation

Call Drop Rate HHO per Call
HHO behavior Success Rate per Call CM Activation Per Hour
delay Alarm HHO 3G  2G

for CPICH_EcNo reason
speed-up Alarm HHO 3G  2G

for CPICH_RSCP reason


 HHO/call = Number of HHO requests 3G to 2G per call
 HHO Success Rate = HHO 3G to 2G success rate
 CM Activation per Call = Number of CM activations per call
 HHO per CM Activation = Rate of CM activation leading to HHO 3G->2G execution
 CM Activation per Hour = Number of CM activations per hour of traffic calls
Duration = 10 min

6 Examples of inter-RAT HHO tuning


6.1 Inter-RAT HHO tuning
What are the expected impacts of each HHO parameter set change?
What is the expected evolution of the QoS indicators?
Default Set 1 Set 2 Set 3

criterion Ec/No Ec/No Ec/No Ec/No
cpichEcNoThresholdUsedFreq2F -8 -8 -10 -9
cpichEcNoThresholdUsedFreq2D -10 -10 -12 -11
timeToTrigger2D 0 640ms 640ms 640ms
timeToTrigger2F 240ms 640ms 640ms 640ms
rrcGsmMeasurementFilterCoefficient 5 2 2 2


6.2 Default: Set1 tuning
Expected impacts on HHO and CM behavior

 timeToTrigger2D= 0  640 ms
 Delay CM activation
o Reduce time spent in CM  improve network quality  reduce the risk of call drop
o Increase the risk of activating CM at too bad quality level  increase the risk of call drop
 rrcGsmMeasurementFilterCoefficient = 5  2
 Increase accuracy of GSM RSSI measurement of neighboring 2G cells
o Reduce the risk of performing HHO not to the best 2G neighbor  reduce the risk of drop (corner
effect)
 Increase the sensitivity to fading
o Increase the risk of performing HHO to a transient best 2G neighbor  increase the risk of call
drop

 CM Activation per Call , CM Activation per Hour 
 HHO per Call  , HHO Success Rate  , Call Drop Rate 

CM procedures interact with SHO because Measurement Control messages for Compress Mode Activation (Event
2D) or Deactivation (Event 2F) are managed at the same time as Active Set Update messages.
Therefore increasing the ratio of CM commands per call is a risk of call drop increase.

6.3 Verify your expectations – Default to Set1 tuning
 Stable HHO success rate

100%
90%
 expectation:  80%
 result:  (around 92%)

70%
60%
 Less CM activation per AMR call

50%
40%
 expectation:  30%
 result:  (-20%) 20%

10%
 A little bit more HHO per call

0%
6/2 6/3 6/4 6/5 6/6 6/7 6/8 6/9 6/10 6/11 6/12 6/13
 expectation:  HHO 3G2G success rate ratio HHO request per AMR call
 result:  (+2%)
ratio CM activation per call ratio HHO success per AMR call
5,0% 50000
4,5% 45000
4,0% 40000
 Better call drop 3,5% 35000
 expectation:  3,0%
2,5%
30000
25000
 result:  2,0% 20000
-14% in relative
1,5% 15000

1,0% 10000
0,5% 5000
0,0% 0
6/2 6/3 6/4 6/5 6/6 6/7 6/8 6/9 6/10 6/11 6/12 6/13
AMR calls % AMR Drop


6.3.1 Set1 to Set2 tuning

 cpichEcNoThresholdUsedFreq2D = -8  -10 dB
 cpichEcNoThresholdUsedFreq2F = -10  -12 dB
 Delay CM activation
o Reduce time spent in CM  improve network quality  reduce the risk of call drop
o Increase the risk of activating CM at too bad quality level  increase the risk of performing HHO
at too bad quality level  increase the risk of HHO failure  increase the risk of call drop
 Keep same hysteresis as Set1 between Event 2d and Event 2f (2 dB)

 CM Activation per Call , CM Activation per Hour 
 HHO per Call , HHO Success Rate , Call Drop Rate 


6.3.2 Verify your expectations – Set1 to Set2 tuning
100%
 Stable HHO success rate 90%
80%
 expectation:  70%
60%
 result:  (around 92%) 50%
40%
30%
 Less CM activation per AMR 20%
10%
call 0%
05
05
05
05
05
05
05
05
05
05
05
05
05
05
 expectation: 
20
20
20
20
20
20
20
20
20
20
20
20
20
20
2/
3/
4/
5/
6/
7/
8/
9/
0/
1/
2/
3/
4/
5/
/0
/0
/0
/0
/0
/0
/0
/0
/1
/1
/1
/1
/1
/1
 result:  (-50% in
06
06
06
06
06
06
06
06
06
06
06
06
06
06
relative) HHO 3G2G success rate ratio HHO request per AMR call
 Less HHO per call ratio CM activation per call ratio HHO success per AMR call
 expectation: 
5.0% 50000
 result:  (-3%) 4.5% 45000
4.0% 40000
3.5% 35000
3.0% 30000
 Slight degradation of call

2.5% 25000
2.0% 20000
drop 1.5%
1.0%
15000
10000
 expectation:  0.5%
0.0%
5000
0
 result: 
05
05
05
05
05
05
05
05
05
05
05
05
05
05
20
20
20
20
20
20
20
20
20
20
20
20
20
20
2/
3/
4/
5/
6/
7/
8/
9/
0/
1/
2/
3/
4/
5/
/0
/0
/0
/0
/0
/0
/0
/0
/1
/1
/1
/1
/1
/1
06
06
06
06
06
06
06
06
06
06
06
06
06
06
AMR calls % AMR Drop



 cpichEcNoThresholdUsedFreq2D = -10  -9 dB
 cpichEcNoThresholdUsedFreq2F = -12  -11 dB
 Set CM activation behavior between Set1 and Set2
o Moderated time spent in CM  acceptable network quality  acceptable call drop rate
o Moderated risk of activating CM at too bad quality level  HHO triggering at acceptable quality
level  acceptable HHO failure  acceptable call drop rate
 Keep same hysteresis as Set1 and Set2 between Event 2d and Event 2f (2 dB)

 Set2 < CM Activation per Call < Set1, Set2 < CM Activation per Hour < Set1
 Set2 < HHO per Call < Set1, HHO Success Rate 
 Call Drop Rate  < Set1 and Set2


Set1 Set2 Set3

 Stable HHO success rate 100%
90%
16%
14%
 expectation:  80%
70%
12%
 result:  (around 92%) 60% 10%

50% 8%
40% 6%
 More CM activation per 30%
20%
4%
AMR call 10%
0%
2%
0%
 expectation:
06 3/2 5
06 4/2 5
06 5/2 5
06 6/2 5
06 7/2 5
06 8/2 5
06 9/2 5
06 0/2 5
06 1/2 5
06 2/2 5
06 3/2 5
06 4/2 5
06 5/2 5
06 6/2 5
06 7/2 5
06 8/2 5
06 9/2 5
06 0/2 5
06 1/2 5
2/ 5
05
Set2<Set3<Set1
/0 00
/0 00
/0 00
/0 00
/0 00
/0 00
/0 00
/1 00
/1 00
/1 00
/1 00
/1 00
/1 00
/1 00
/1 00
/1 00
/1 00
/2 00
/2 00
/2 00
20
06 2/2
/0
 result: Set2<Set3<Set1
06
HHO 3G2G success rate ratio HHO request per AMR call
 More HHO per call ratio CM activation per call ratio HHO success per AMR call
 expectation: Set1 Set2 Set3
Set2<Set3<Set1 5,00%
4,50%
25000
 result: Set2<Set3<Set1
4,00% 20000
3,50%
3,00% 15000
 Better call drop

2,50%
2,00% 10000
1,50%
 expectation: 1,00%
0,50%
5000
 CDRSet3 < CDRSet1 < CDRSet2 0,00% 0
 result:
/0 05
/0 05
/1 05
/1 05
/1 05
/1 05
05
/0 05
/0 05
/0 05
/0 05
/0 05
/1 05
/1 05
/1 05
/1 05
/1 05
/1 05
/2 05
/2 05
/2 05
06 /20
06 /20
06 /20
06 /20
06 /20
06 /20
20
06 /20
06 /20
06 2 0
06 /20
06 /20
06 2 0
06 /20
06 2 0
06 /20
06 /20
06 2 0
06 /20
06 /20
06 /20
2/
6/
1/
4/
8/
4
7
2
1
CDRSet1 < CDRSet3 < CDRSet2
/0
06
AMR req % AMR Drop


6.3.5 Conclusion on Set1, Set2, Set3 tuning / Default
Set1 improves system performances without impact on QoS

 Less CM activation per call (but still high: 50%)
 Call drop rate improvement
Set2 improves system performances but with slight impact on QoS

 Less CM activation per call: (25%)
 Slight Call drop degradation
 It seems that CM activation at Ec/No= –12 dB leads to more HHO failures (and call
drops)
 The UE may not have enough time to activate CM and perform 2G measurements
especially when radio conditions are degraded quickly
Set3 is a trade-off between call drop improvement and CM efficiency

degradation
 Less call drops (System CDR=1.6% vs 1.8% with Default Set)
 Less CM activation per call: 35% instead of 60% with Default Set


6.3.6 Inter-RAT HHO and CM tuning – Lesson
Guessing the effects of a fine tuning is not so obvious
Optimized setting of HHO to 2G and CM parameters is not easy to find

 Several different combinations of parameter values can give similar results
The idea is to find a compromise between

 HHO to 2G triggered not too early to avoid performing unnecessary HHO which could fail
to 2G and lead to a call drop
 HHO to 2G triggered not too late to be performed in good radio conditions and avoid
call_drop
 CM activation not too early to avoid spending too long time in CM

 CM activation not too late to be able to perform the HHO in good radio conditions


Summary - Tune 3g-2G Hard Handover
EVENT 2D AND EVENT 2F: TTT TUNING
timeToTrigger2D
CM activation: set to 1280 ms to avoid CM activation in case of fast fading holes
timeToTrigger2F
set to 1280 ms to have the same decision time than for Event 2D


Summary - Tune 3g-2G Hard Handover [cont.]
EVENT 2D AND EVENT 2F : THRESHOLD TUNING
Any Service with HSDPA

 delay the CM activation cpichEcNoThresholdUsedFreq2D -14 dB
due to low RSCP as 2G does not cpichRscpThresholdUsedFreq2D -110 dBm
provide equivalent bit rates cpichEcNoThresholdUsedFreq2F -13 dB
cpichRscpThresholdUsedFreq2F -108 dBm
Any Service without HSDPA but with High Bit Rate (> 128 kbps)
 inhibit the CM activation since other cpichEcNoThresholdUsedFreq2D -24 dB
algorithms like iRM Scheduling Downgrade cpichRscpThresholdUsedFreq2D -114 dBm
should be triggered before HHO to GSM cpichEcNoThresholdUsedFreq2F 0 dB
Any Service without HSDPA and without High Bit Rate

 speed-up the CM activation since
these services can be supported in GSM
with a similar quality as in UMTS cpichEcNoThresholdUsedFreq2D -14 dB
cpichRscpThresholdUsedFreq2D -105 dBm
cpichEcNoThresholdUsedFreq2F -13 dB


End of module
Tune 3G-2G Hard Handover


Section 2
Module 4
Tune Cell Reselection
UTRAN

Blank page

Tuning key UTRAN algorithms · Tune Cell Reselection
Document History

Module objectives
 Explain the objectives of the Cell Reselection algorithm in a UMTS network

 Present the principles of the 3G to 2G and 2G to 3G Cell Reselection procedure
performance of the Cell Reselection procedure




Table of contents
1 Objectives of cell reselection algorithms (single UMTS layer) 7

1.1 Objectives 8
1.2 Strategy 9
2 Principles of cell reselection procedures (single UMTS layer) 10
2.1 3G to 3G cell reselection – intra-freq measurements 11
2.2 3G to 3G cell reselection – criteria 12
2.3 3G to 2G cell reselection – inter-RAT measurements 13
2.5 2G to 3G cell reselection – inter-RAT measurements 15
3.1 Estimate the impact of a CRS parameter change 18
3.2 Configuration of measurement on FACH 20
5 Examples of 3G to 2G cell reselection tuning (single UMTS layer) 23
5.1 Inter-RAT CRS parameters tuning 24
5.1.1 Set1 25
5.1.4 Verify your expectations – Set1 to Set3 tuning 32
5.1.5
2·4·5
Conclusion about Set2, Set3 tuning / Set1 34



1 Objectives of cell reselection
algorithms (single UMTS layer)


1 Objectives of cell reselection algorithms (single UMTS layer)
1.1 Objectives
3G to 3G reselection to optimize UTRAN quality and resources

 The UE has to camp on the best cell
 in IDLE state for RRC Connection and RAB establishment
 in CELL_FACH state for maintaining a good E2E QoS of PS RAB
3G to 2G reselection to provide service continuity for the user

 The UE has to reselect a 2G cell if a sufficient quality cannot be maintained on
the 3G layer
 UE Controlled Cell Reselection only
2G to 3G reselection to use 3G resources whenever possible

 The UE has to reselect a 3G cell if a sufficient quality can be provided on the
3G layer
 UE Controlled Cell Reselection
 Network Controlled Cell Reselection (CCO: Cell Change Order)
TUNING to limit UE unavailability and network signaling load

Location Area are usually different on 3G and 2G layers so that Location Area Update procedures are performed at
each cell reselection between 3G and 2G.
The UE is not reachable during the 3G-2G reselection procedure.
Network signaling may be largely increased if there are too many reselection procedures (which would then imply
some over-dimensioning of the UTRAN/CN network).

1 Objectives of cell Rreselection algorithms (single UMTS layer)
1.2 Strategy
Current strategy to favor the 3G layer and use 2G as

recovery
 keeping the UE as long as possible in the 3G layer
 trigger a reselection to 2G only when coverage/quality in 3G is not good
enough
 Once in the 2G network, trigger a reselection to 3G as soon as 3G
coverage/quality becomes good enough
The key point for tuning is:

 to avoid keeping a UE in 3G with bad radio conditions
 while also avoiding too many ping-pong between 3G and 2G layers


2 Principles of cell reselection procedures
(single UMTS layer)


2 Principles of cell reselection procedures (single UMTS layer)
2.1 3G to 3G cell reselection – intra-freq measurements
The UE is in IDLE or CELL_FACH/CELL_PCH/URA_PCH state

The UE is performing intra-freq measurements, looking for a better cell
 Criteria= the quality on the current cell is not strong enough
 Quality(CPICH Ec/N0) on serving cell  Qqualmin + sIntraSearch
CPICH_EcNo
No
Nomeasurements
measurements
-8 dB
sIntraSearch 8 dB Intra-freq measurements
Qqualmin -16 dB

Cell reselection is performed by the UE in idle or CELL_FACH mode, based on system information broadcast in 3G and 2G networks.
In IDLE mode:
 the UE shall measure the CPICH Ec/Io and CPICH RSCP level of the serving cell and evaluate the cell selection criterion S for the serving
cell at least every DRX cycle. The UE shall filter the CPICH Ec/Io and CPICH RSCP measurements of the serving cell using at least 2
measurements, which are taken so that the time difference between the measurements is at least TmeasureFDD/2 (see table below).
DRX cycle (coded DRX cycle length Nserv [number of DRX TmeasureFDD [s] (number of
value) [s] cycles] DRX cycles)
3 0.08 4 0.64 (8 DRX cycles)
4 0.16 4 0.64 (4)
5 0.32 4 1.28 (4)
6 0.64 4 1.28 (2)
7 1.28 2 1.28 (1)
8 2.56 2 2.56 (1)
9 5.12 1 5.12 (1)
 If the UE has evaluated in Nserv consecutive DRX cycles that the serving cell does not fulfill the cell selection criterion S, the UE shall
initiate the measurements of all neighbor cells.
For instance:
 DRX cycle = 0.64 s.
 Every 0.64 s, criterion S for the serving cell is checked. If criterion S is not true in 4 consecutive DRX cycles, then the UE shall start
measurements of neighbor cells.
 To check criterion S, filtered value of CPICH RSCP and Ec/Io are computed from at least 2 layer-1 measurements separated by at
least 0.64 s (=1.28/2).
In CELL_FACH mode, the periodicity of measurements is 200 ms.

2.2 3G to 3G cell reselection – criteria
3G  3G reselection criteria
 Qmeasn – Qoffsets,n > Qmeass + Qhysts during tReselection
 Qmeass: averaged measured CPICH Ec/No or CPICH RSCP of the serving 3G cell
 Qmeasn: averaged measured CPICH Ec/No or CPICH RSCP of the neighbor 3G cell
 Qhysts: anti ping-pong parameter  Qoffsetsn : for adjacency tuning
= qHyst1 if Qmeas=CPICH RSCP = qOffset1sn if qualMeas=CPICH_RSCP
= qHyst2 if Qmeas=CPICH Ec/N0 = qOffset2sn if qualMeas=CPICH_EcNo
Cell A reselected
Cell B reselected
Example with Qhyst,B
Qoffsetsn=0 dB
Qhyst,A
3G Cell A 3G Cell B

qHysts1
Hysteresis is added to CPICH RSCP of the serving cell during cell selection/reselection. It is used to avoid ping-pong effect.
Alcatel-Lucent recommended value is 2 dB, which corresponds to 4 dB hysteresis as illustrated in the figure:
Selected cell
Cell 2
Cell 1
CPICH_RSCP_cell2 - CPICH_RSCP_cell1
-Qhysts1 Qhysts1
Total hysteresis
This parameter is used for all types of cell reselection (intra frequency, inter frequency and inter RAT). The Qoffset_sn
parameter can be adjusted per adjacency to “adapt” the quality hysteresis Qhyts1 on a specific adjacency.
Qhysts2
Hysteresis is added to CPICH Ec/No of the serving cell during cell selection/reselection. It is used to avoid ping-pong effect. This
parameter is broadcast only if the cell selection/reselection quality measurement is set to CPICH Ec/No. Alcatel-Lucent
recommended value is 2 dB, which corresponds to 4 dB hysteresis.
This parameter is used for intra- and inter-frequency cell reselection. Qoffset_sn2 can be adjusted per adjacency to “adapt” the
quality hysteresis Qhyts2 on a specific adjacency.
Treselection
The Treselection default value is 1 s.
2.3 3G to 2G cell reselection – inter-RAT measurements
The UE is in IDLE or CELL_FACH state.

The UE is also performing inter-RAT measurements, looking for a better
cell
 Criteria= the quality on the current cell is not strong enough
 Quality(CPICH Ec/N0) on serving cell  Qqualmin + sSearchRatGsm
Qqualmeas (CPICH Ec/N0)
No
Nomeasurements
measurements
-8 dB
Intra-freq measurements
-14 dB
sSearchRatGsm 2 dB Intra-freq+Inter-RAT measurements
Qqualmin -16 dB

In IDLE mode, the periodicity of measurements depends on the DRX Cycle parameter.
 Default setting: k=7 therefore TmeasGSM = 6,4 s
In CELL_FACH mode, the periodicity of measurements is 480 ms.

3G to 2G reselection criteria
 Qmeasn – Qoffsets,n > Qmeass + Qhysts during tReselection
 Qmeass: averaged measured CPICH RSCP of the serving 3G cell
 Qmeasn: averaged measured BCCH RSSI of the neighbor 2G cell
 Qhysts: anti ping-pong parameter  Qoffsetsn: for adjacency tuning
 = qHyst1 (CellSelectionInfo)  = qOffset1sn (GSMNeighbouringCell)
Cell B reselected
Qhyst,A Qoffsetsn(A,B)
3G Cell A 2G Cell B

qOffset1sn(GSMNeighbouringCell)
This offset is defined per adjacency and subtracted from the GSM carrier RSSI of each GSM neighboring cell. The
recommended value is +50 dB (maximum value) to reduce the inter-system reselection signaling and to keep the
UE under 3G coverage while the S criterion is fulfilled.

2.5 2G to 3G cell reselection – inter-RAT measurements
The UE is in GPRS IDLE, STAND-BY or READY state

The UE is performing Inter-RAT measurements, looking for a better cell
 Criteria= depends on the Qsearch_I parameter value and can be
 never
 always
 if the serving BCCH RxLevel is strong enough
 if the serving BCCH RxLevel is not strong enough
BCCH RxLevel Example
Inter-RAT measurements
No measurements
Qsearch_I -70 dBm
No measurements

Qsearch_I is sent in system information SI 2ter or SI 2quater depending on the BSS constructor.
 In Alcatel-Lucent BSS, Qsearch is broadcast in SI2ter on BCCH.
 The default UE value if Qsearch_I is not sent in system information is 15 (never).
In GPRS STAND-BY or READY state, if PBCCH is activated and the UE is PBCCH capable, the UE monitors Packet
System Information (PSI) broadcast on the PBCCH and decides to perform inter-RAT measurements according to
the Qsearch_P parameter, whose definition and usage is similar to Qsearch_I.
Qsearch_I and Qsearch_P coding values
0 = -98 dBm
1 = -94 dBm
2 = -90 dBm
3 = -86 dBm
4 = -82 dBm
5 = -78 dBm
6 = -74 dBm
below
7  (always)
8 = -78 dBm
9 = -74 dBm
10 = -70 dBm
11 = -66 dBm
12 = -62 dBm
13 = -58 dBm
above
14 = -54 dBm
15  (never)

2G to 3G reselection criteria
 CPICH_EcNo(n) > FDD_Qmin
 Quality on 3G neighbor cell is good enough
 CPICH_RSCP(n) > RLA_C(s or n’) + FDD_Qoffset
 Level on the 3G neighbor cell is high enough compared to the 2G serving cell and to
any 2G neighbors
RxLevel
CPICH Ec/N0
2G No3Gmeasurements
possible
RLA_C
FDD_Qmin -12 dB
FDD_Qoffset CPICH RSCP
2G  3G impossible
time
5s
2G  3G reselection
FDD_Qmin
FDD_Qmin is sent in system information SI 2ter or SI 2quater depending on the BSS constructor.
FDD_Qmin is sent in system information Packet SI 3 quarter or Packet Measurement Order or Packet Cell Change
Order messages.
In Alcatel-Lucent BSS, it is broadcast in SI2ter on BCCH and in PSI 3quater on PBCCH if there is a PBCCH allocated
in the serving cell.
The default UE value if FDD_Qmin is not sent in system information is 7 (-12 dB).
FDD_Qoffset and FDD_GPRS_Qoffset are offset applied to the Received Level Average before checking the cell
reselection criterion when the UE monitors BCCH or PBCCH.
FDD_Qmin is sent in system information SI 2ter or SI 2quater depending on the BSS constructor.
In Alcatel-Lucent BSS, it’s broadcast in SI2ter on BCCH (FDD_Qoffset) and in PSI 3quater on PBCCH
(FDD_GPRS_Qoffset) if there is a PBCCH allocated in the serving cell. 0   (always select a cell if acceptable)
1 = -28 dB
2 = -24 dB
FDD_Qmin coding values FDD_Qoffset coding values 3 = -20 dB
0 = -20 dB 4 = -16 dB
5 = -12 dB
1 = -6 dB
6 = -8 dB
2 = -18 dB 7 = -4 dB
3 = -8 dB 8 = 0 dB
4 = -16 dB 9 = 4 dB
5 = -10 dB 10 = 8 dB
6 = -14 dB 11 = 12 dB
12 = 16 dB
7 = -12 dB
13 = 20 dB
14 = 24 dB
15 = 28 dB


3.1 Estimate the impact of a CRS parameter change
For each of the CRS parameter changes below and next page, find which
of the impacts proposed should be observed.
qOffset2sn
tReselection
sSearchRatGsm
-90
Qsearch_I
-94
Qhyst1
sIntraSearch


1. delay 3G  3G CRS
2. speed-up 3G  3G CRS
Duration = 10 min

3.1 Estimate the impact of a CRS parameter change [cont.]
For each of the CRS parameter changes below, find which of the impacts
FDD_Qoffset
qOffset1sn(UMTSFddNeighbouringCell)
FDD_Qmin
qOffset1sn(GSMNeighbouringCell)
Qhyst2
-70
Qsearch_I
-74



3.2 Configuration of measurement on FACH
The UE in CELL_FACH is requested to measure inter-frequency or
inter-RAT cells every M_REP radio frames where M_REP = 2k
k is a tunable parameter, k [1,12] step=1, = fachMeasOccasionCoef
Measurement occasions
 Example if k=3
N TTI*M_REP= 8 frames N TTI= 1 frame
During FACH measurement occasion:

 The UE can perform inter-RAT/inter-frequency measurements
 The RNC doesn’t take into account these periods and can send data to the UE
 The UE could not receive FACH TB when performing inter-RAT measurements
 UEs not taking into-account SsearchRAT are more impacted
What would be the impact of modifying fachMeasOccasionCoef?

Would you increase or decrease it?

In the CELL_FACH state, the measurement period for the GSM carrier RSSI measurement is 480 ms. (3GPP 25.133).
This measurement period is inherited from GSM.
At least 3 received signal level measurement samples (at layer 1) are required per RSSI value, over the
measurement period of 480 ms.
A UE supporting GSM measurements using measurement occasions shall meet the minimum number of GSM carrier
RSSI measurements specified in the table below.
Length of measurement occasion Number of GSM carrier RSSI samples in each
(NTTI frames) measurement occasion, NGSM carrier RSSI.
1 16
2 32
4 64
8 128



4 Which QoS indicators to monitor
For each of the CRS behavior changes below, find which of the QoS
QoS indicator
Call started in Inter-RAT Inter-RAT
CSSR in 3G
3G RRC CSR RRC C ratio
CRS behavior
delay 3G  3G CRS
delay 3G  2G CRS
delay 2G  3G CRS


 CSSR in 3G = Call Setup Success Rate in 3G (MO and MT included)
 Call started in 3G = Ratio of calls that have started in 3G compared to all calls (2G+3G)
 Inter-RAT RRC CSR = RRC Connection Success Rate for Inter-RAT (2G3G) cell reselection procedures
 Inter-RAT RRC C ratio = Ratio of Inter-RAT RRC (2G3G) connection compared to all kinds of RRC
Connections
Duration = 20 min

5 Examples of 3G to 2G cell reselection
tuning (single UMTS layer)


5 Examples of 3G to 2G cell reselection tuning (single UMTS layer)
5.1 Inter-RAT CRS parameters tuning
What is the expected impact of each CRS parameter set change?

What is the expected evolution of the QoS indicators?
3G  2G reselection
Parameter Set 1 Set 2 Set 3
qQualMin -16 -16 -16
qRxlevMin -109 -113 -115
sIntraSearch 10 10 10
sSearchRatGsm 0 2 2
tReselection 1 1 1
qHyst1 2 2 2
qHyst2 2 2 2
qOffset1sn(UMTS,UMTS) 0 0 0
qOffset2sn(UMTS,UMTS) 0 0 0
qOffset1sn(UMTS,GSM900) -16 50 50
qOffset1sn(UMTS,GSM1800) -10 50 50
FDD_Qmin -12 -8 -10
Qsearch_I Always search Always search Always search
FDD_Qoffset - infinity - infinity - infinity


5.1 Inter-RAT CRS parameter tuning
5.1.1 Set1
Expected CRS behavior with Set1

 sSearchRatGsm = 0 dB
 Quite late triggering of inter-RAT measurements
+ Decrease UE battery consumption
+ Stay longer in 3G, so favor 3G traffic
– Increase the risk of losing coverage, so increase the risk of losing Paging
 qOffset1sn(UMTS,GSM900) = -16 dB
 2G is systematically reselected when quality in 3G is bad
+ Provides security for reselection when quality is getting bad in 3G
– Increase the risk of ping-pong between 3G and 2G , so increase the risk of losing Paging
 FDD_Qmin = -12 dB
 Quite fast reselection to 3G
+ Stay longer in 3G, so favor 3G traffic
 qRxlevMin = -109 dBm

 Quite high threshold for camping in 3G compared to the UE sensitivity (-117 dBm)
+ Increase the probability to setup an RRC Connection successfully when camping in 3G
– Decrease the 3G coverage in favor of 2G, so favor 2G traffic

The 3G layer is selected if coverage (RSCP) is good enough (over -109 dBm).
When in 3G, the UE is kept in 3G until quality (Ec/N0) becomes very bad (equal to the cell selection criteria (–16
dB).
When 3G quality becomes very bad, reselection to 2G is systematic.

5.1 Inter-RAT CRS parameter tuning
Expected CRS behavior with Set2 compared to Set1

Qqualmeas Qqualmeas
3G cell suitable
Stay on 3G cell Reselect 2G cell
FDDQmin= -12 dB 2G  3G
qQualMin= -16 dB SET1
qOffset1sn(UMTS,GSM)= -16 dB (900) / -10 dB (1800)
qRxlevMin= -109dBm Qrxlevmeas Qrxlevmeas 3G = Qrxlevmeas Qrxlevmeas

Qqualmeas 2G
Qqualmeas
FDDQmin= -8 dB 2G  3G
3G cell suitable
qQualMin= -16 dB
SET2
qOffset1sn(UMTS,GSM)= +50 dB
qRxlevMin= -113 dBm Qrxlevmeas Qrxlevmeas 3G = Qrxlevmeas 2G Qrxlevmeas

3G coverage has been favored at cell selection stage thanks to qRxlevMin decrease.
3G coverage has been favored at cell reselection stage thanks to qOffset1sn(UMTS,GSM) increase.
2G to 3G reselection has been delayed thanks to FDD_Qmin increase. It is both decreasing 2G/3G reselection ping-
pong and securing reselection to 3G.

5.1.2 Set1 to Set2 tuning [cont.]

 sSearchRatGsm = 0  2 dB
 Speed-up the triggering of inter-RAT measurements
+ Decrease the risk of losing coverage, so decrease the risk of losing Paging
– Stay less long in 3G / Set1, so increase the risk of losing Paging when reselecting 2G
– Increase UE battery consumption
 qOffset1sn(UMTS,GSM900) = -16  50 dB
 2G is reselected almost only when the UE gets out of 3G coverage (inhibition value)
+ Favor 3G traffic
+ Decrease the probability of a 3G to 2G, so decrease the risk of losing Paging
– Increase the risk of losing coverage, so increase the risk of losing Paging
 FDD_Qmin = -12  -8 dB
 Delay reselection to 3G
+ Decrease the risk of ping-pong between 3G and 2G , so decrease the risk of losing Paging
+ Camp in 3G at better quality, so increase the probability to set up an RRC Conn. successfully
– Stay longer in 2G, so favor 2G traffic
 qRxlevMin = -109  -113 dBm
 Favor cell selection in 3G and reselection to 3G
+ Increase the 3G coverage in unfavor of 2G, so favor 3G traffic
– Decrease the probability to set up an RRC Conn. successfully when camping in 3G



 3G coverage has been favored at cell selection stage thanks to QrxlevMin
decrease
+ Call started in 3G 
– CSSR in 3G 
– Inter-RAT RRC CSR 
 3G coverage has been favored at cell reselection thanks to Qoffset_snGSM
increase, which almost inhibits cell reselection to 2G.
Therefore, the risk of losing a Paging is reduced a lot.
+ Inter-RAT RRC C ratio 
– CSSR in 3G  (when taking Paging into account for MT calls)
 Quality when camping on 3G has been enhanced thanks to FDD_Qmin
increase.
Higher FDD_Qmin reduces the probability of a 2G to 3G reselection and
therefore ping-pong of reselection between 3G and 2G may decrease.
+ CSSR in 3G 
+ Inter-RAT RRC C ratio 
+ Inter-RAT RRC CSR 
– Call started in 3G 



Qqualmeas
FDDQmin= -8dB 2G  3G
3G cell suitable
SET2
qQualMin= -16dB qOffset1sn(UMTS,GSM)= 50dB
Qrxlevmin2= -113dBm Qrxlevmeas Qrxlevmeas 3G = Qrxlevmeas Qrxlevmeas

Qqualmeas 2G
3G cell suitable
FDDQmin= -10 dB
2G  3G
SET3
qQualMin= -16 dB qOffset1sn(UMTS,GSM)= 50 dB
Qrxlevmin3= -115 dBm Qrxlevmeas Qrxlevmeas 3G = Qrxlevmeas Qrxlevmeas

2G
3G coverage has been favored at cell selection stage thanks to one more qRxlevMin decrease.
3G coverage has been favored at cell reselection like with Set2 (Qoffset1sn(UMTSGSM) is unchanged).
2G to 3G reselection has been fastened thanks to FDD_Qmin decrease. Set3 value is in between Set1 and Set2
ones.


 FDD_Qmin = -8  -10 dB
 Speed-up reselection to 3G / Set2
+ Stay less in 2G, so favor 3G traffic
– Decrease the probability to set up an RRC Connection successfully when camping in 3G
 qRxlevMin = -113  -115 dBm
 Favor cell selection in 3G and reselection to 3G
+ Increase the 3G coverage against 2G, so favor 3G traffic
– Decrease the probability to set up an RRC Conn. successfully when camping in 3G



 3G coverage has been favored at cell selection stage thanks to QrxlevMin
decrease
– CSSR in 3G 
 Quality when camping on 3G has been degraded / Set2 due to FDD_Qmin
decrease.
Lower FDD_Qmin increases the probability of a 2G to 3G reselection and
therefore ping-pong of reselection between 3G and 2G may increase.
– CSSR in 3G 
– Inter-RAT RRC C ratio 


 RRC Connection SSR

 expectation:
 due to QrxlevMin 
 result:  (92% to 91%)
 Inter-RAT RRC Cnx SR

 expectation:
 due to FDD_Qmin 
 result:  (97% to
98.3%)
 Ratio of Inter-RAT RRC
Conn.
 expectation:
 due to Qoffset_snGSM 
 result:  (44% to 34%)
 CSSR
 expectation:
Signaling load
improved by 23%
 due to Qoffset_snGSM 
 result:  for all services
The big decrease of the ratio of Inter-RAT RRC Connection shows that the ping-pong of reselection between 2G and
3G has been reduced a lot.
The improvement of CSSR comes mostly for MT calls due to the reduction of Paging loss which is a consequence of
the reduction of 3G to 2G reselections. Indeed, the UE is not reachable during the 3G-2G reselection procedure,
which means Paging is lost.
Indicators:
 Ratio of Inter-RAT RRC Connection gives measurement of the Signaling Load due to cell reselection
between 2G and 3G networks.
 It allows one to monitor the ping-pong of reselection between 3G and 2G.
 Inter-RAT RRC Connection success rate shows the performance of the 3G UTRAN sub-network for providing
access to service to the user after a 2G to 3G reselection.
 RRC Connection success rate shows the performance of the 3G UTRAN sub-network for providing access to
service to the user.
 It allows one to monitor the ability to maintain the UE in 3G with a good quality of access to service.
 Call setup success rate shows the performance of the 3G network for providing the user with services.
 It allows one to monitor the ability to maintain the UE in 3G with a good quality of service.

5.1.4 Verify your expectations – Set1 to Set3 tuning [cont.]
 AMR MOC CSSR

 expectation:
 result: slight 
 AMR MTC CSSR

 expectation:
 due to
Qoffset_snGSM 
 result:  (80% to
98%)
 Ratio of calls started in 3G
 expectation: % calls in 3G
MTC CSSR improved by
 due to Qoffset_snGSM  improved by 40%
and due to QrxlevMin  22.5%
 due to FDD_Qmin 
 result:  (50% to 70%)
The big improvement of MT calls CSSR comes from the reduction of 3G to 2G reselections. Indeed, the UE is not
reachable during the 3G-2G reselection procedure, which means Paging is lost.
Indicators:
 Ratio of calls started in 3G gives a measurement of the distribution of calls between 3G and 2G networks.
 It allows one to monitor the ability of using 3G resources at their maximum.
 MOC (resp. MTC) Call setup success rate shows the performance of the 3G network for providing the user
with services when calling (resp. called).
 It allows one to monitor the ability to maintain the UE in 3G with a good quality of service.

5.1.5 Conclusion about Set2, Set3 tuning / Set1
Limitation of the ping-pong between 3G and 2G layers is key to:

 increase the network accessibility (less loss of Paging)
 reduce the signaling overhead (less Location Update)
Cell selection thresholds depend on 3G coverage versus 2G coverage
 When 3G coverage is very good, it is possible to set very low qQualMin and
qRxlevMin values so as to keep UEs in 3G during short coverage holes in 3G
 When 3G coverage is too weak, it is better to set high qQualMin and
qRxlevMin values, so as to avoid keeping the UE in bad 3G conditions
Statistics from drive tests are recommended to get a reliable user

perception on network accessibility


Summary
Inter-RAT Cell reselection TUNING
Parameter setting is driven by the Operator Strategy in using both 2G and 3G

layers at their best.
Current Strategy is to favor the 3G layer for 3G UE traffic and to use 2G as a

service recovery layer.


Summary [cont.]
qOffset1sn(UMTS,GSM)
 set to 50 dB (max) in order to avoid 3G to 2G reselection
 to favor 3G UE to use 3G resources
 to reduce the risk of losing a Paging
qRxlevMin
 2 or 3 dB over the UE sensitivity (-117 dm for BER=0,001)
 to favor 3G UE to use 3G resources
 but could be increased if 3G coverage is not dense enough
FDD_Qmin
 set to –10dB which is a good compromise
 low enough to favor 3G UE to use 3G resources (easy 3G reselection)
 high enough to avoid degrading the QoS after 3G has been reselected


End of module


Section 2
Module 5
Tune Radio Link Management
UTRAN

Blank page

Tuning key UTRAN algorithms · Tune Radio Link Management
Document History

Module objectives
 Explain the objectives of the Radio Link Management algorithms in a UMTS

network
 Present the principles of the Radio Link Management procedures
performance of the Radio Link Control procedures




Table of contents
1 Objectives of Radio Link Management algorithms 7

1.1 Objectives 8
1.1.1 Radio Link Failure / RLC Unrecoverable Error 9
1.2 RRC Connection Re-establishment 10
2 Principles of Radio Link Management procedures 11
2.1 L1 RL Failure detection in DL – by UE 12
2.2 L1 RL Failure detection in UL – by Node B 13
2.3 L1 RL Restore detection in UL – by Node B 14
2.4 Call drop after a Layer 1 RLF detected by Node B 15
2.5 Recovery after a L1 RLF detected by NodeB or UE 16
2.6 L3 RLC Unrecoverable Error detected by UE 17
2.7 Call drop after a Layer 3 RUE detected by RNC 19
2.8 L1 and L3 RL Failures 20
3.1 Estimate the impact of an RLM parameter change 22
5 Examples of Radio Link Management tuning 25
5.1 nOutSyncInd parameter tuning 26
5.2 maxDat parameters tuning 29




1 Objectives of Radio Link Management
algorithms


1 Objectives of Radio Link Management algorithms
1.1 Objectives
Three main algorithms manage the connection between UE and UTRAN
 Radio Link Failure (RLF) – at Layer 1

 aims at detecting the loss of a radio link between UE and UTRAN
 If the last radio link is lost then the RRC connection is dropped
 RLC Unrecoverable Error (RUE) – at Layer 3

 aims at detecting the loss of a capability to transfer RLC data between UE
and UTRAN
 RRC Connection Re-establishment (RCR)

 aims at re-establishing the connection between UE and UTRAN so as to avoid
call drops

The RLF may be detected either on downlink by the UE or on uplink by the Node B. An RL fails, when the L1
synchronization cannot be maintained, i.e. when the quality of the decoding at physical layer is not sufficient
anymore to handle the TPC command on a reliable way.
In W-CDMA systems, it becomes urgent to cancel an RL that cannot be power-controlled any more, since it may
contribute to the interference and thus, the cell load, either unnecessarily, or even damaging the cell quality.

1.1 Objectives
1.1.1 Radio Link Failure / RLC Unrecoverable Error
A UE-UTRAN connection problem due to bad radio conditions can be detected:

 At layer 1 through RLF, by the Node B for a UL problem or by the UE for DL
 At layer 3 through RUE, by a loss of RLC acknowledgements leading to an RLC
unrecoverable error aon t RNC side for a DL problem and onUE side for UL
DL Radio Link
Synchronization
RNC
UL Radio Link UL RLC error
Synchronization detection
DL RLC error DL Radio Link

detection Synchronization
UL Radio Link
Synchronization

The RNC or UE monitors the capability to send or receive data on the air interface.
Problems can be detected:
 at Layer 1 level thanks to Radio Link monitoring
 at Layer 3 level thanks to RLC block transmission monitoring (RLC AM)

1.1 Objectives
1.2 RRC Connection Re-establishment
RCR is a key algorithm since an RRC Connection Re-establishment

procedure which is not successful triggers a Radio Drop
 The main reasons of non re-establishment are:
 poor radio conditions
 call ended by the user (who has been waiting for too long)
Tuning aims at decreasing the probability that a radio link failure occurs
and that an RRC connection re-establishment fails


2 Principles of Radio Link Management
procedures


2 Principles of Radio Link Management procedures
2.1 L1 RL Failure detection in DL – by UE
Layer 1 in the UE reports “out-of-synch” to higher layer if SIR is too low.

Layer 3 estimates the status of the link and detects an RL failure when
n313 consecutive “out-of-synch” states have been reported and T313 has
expired.
Timer t313 is triggered
t313 expires
To To+10 ms To+20 ms To+30 ms To+nx10 ms
SIRav < -3
- 3dB
dB SIRav < -3
- 3dB
dB
=> Out-of- Synch => Out-of- Synch
SIRav < -3
- 3dB
dB SIRav < -3
- 3dB
dB
=> Out-of- Synch => Out-of- Synch
Radio Link Failure is
notified to RRC
n313

DL RLF detected at L1
(= T313 (UeTimerCstConnectedMode)) is started due to “16 + N313 (= N313
 T313
(UeTimerCstConnectedMode))” consecutive radio frames for which SIR lies below Qout threshold (-3 dB)
 The threshold Qout should correspond to a level of DPCCH quality where no reliable detection of the TPC
commands transmitted on the downlink DPCCH can be made. For example, this can be at a TPC command
error ratio level of 30%.
DL RLF detected at L1
 Detected by the UE
 AnRL fails, when the L1 synchronization cannot be maintained, i.e. when the quality of the decoding at
physical layer is not sufficient anymore to handle the TPC command in a reliable way.
 In
W-CDMA systems, it becomes urgent to cancel an RL that cannot be power-controlled anymore, since it may
contribute to the interference and thus, the cell load, either unnecessarily, or even damaging the cell quality
 If
T313 expires, the UE considers a "Radio link failure": it clears the dedicated physical channel configuration
and performs the specified actions for the ongoing procedures.
 Then, the UE launches a CELL UPDATE procedure using the "radio link failure“ cause, in order to try saving the
call with a re-establishment of the connection to UTRAN.

2.2 L1 RL Failure detection in UL – by Node B
Layer 1 in the Node B reports “out-of-synch” to higher layer

Layer 3 estimates the status of the link and signals a RL failure to RNC when
nOutSyncInd consecutive “out-of-synch” states have been reported and
tRLFailure has expired
Timer tRLFailure is
triggered tRLFailure expires
To To+10 ms To+20 ms To+30 ms To+nx10 ms
SIR av < - 33dB

dB SIR av < - 33dB
dB
=> Out - of- Synch => Out - of - Synch
SIR av < - 33dB

dB SIRav < - 33dB
dB
=> Out - of - Synch => Out - of- Synch
(NBAP) Radio Link Failure
is notified to RNC
nOutSyncInd

UL RLF detected at L1
tRLFailure is started due to “16 + nOutSyncInd” consecutive frames for which SIR lies below SIR_Qout threshold
(-3 dB).
UL RLF detected at L1
 Detected by the Node B
 AnRL fails, when the L1 synchronization cannot be maintained, i.e. when the quality of the decoding at
physical layer is not sufficient anymore to handle the TPC command in a reliable way.
 In
W-CDMA systems, it becomes urgent to cancel an RL that ca not be power-controlled anymore, since it may
contribute to the interference and thus, the cell load, either unnecessarily, or even damaging the cell quality.
 If
tRLFailure expires, the Node B considers a "Radio link failure": it indicates to the SRNC which radio link set is
out-of-sync. When the RL Failure procedure is triggered, the state of the radio link set changes to the out-of-
sync state.
 If
the failed RL was the last RL of the Active Set then the SRNC launches an RRC connection re-establishment
procedure in order to avoid dropping the ongoing calls.

2.3 L1 RL Restore detection in UL – by Node B
Layer 1 in the Node B reports “in-synch” to a higher layer.

Layer 3 estimates the status of the link and stops tRLFailure when
nInSyncInd consecutive “in-synch” states have been reported.
Timer tRLFailure is
triggered tRLFailure is
stopped
To To+10 ms To+20 ms To+30 ms To+nx10 ms To To+10 ms To+mx10 ms
SIRav < -3
- 3dB
dB SIRav < -3
- 3dB
dB
=> Out-of- Synch => Out-of- Synch SIRav >
< -3
- 3dB
dB SIRav >
< -3
- 3dB
dB
=> -of-
In - Synch => -of-
In - Synch
SIRav < -3
- 3dB
dB SIRav < -3d
- 3dB
B SIRav >
< -3
- 3dB
dB
=> Out-of- Synch => Out-of- Synch => In- Synch
nOutSyncInd nInSyncInd

RL restore detected at L1
 tRLFailure is stopped due to “16 + nInsyncInd” consecutive frames for which SIR lies above SIR_Qin
threshold (-3 dB).
 Thethreshold Qin should correspond to a level of DPCCH quality where detection of the TPC commands
transmitted on the downlink DPCCH is significantly more reliable than at Qout. For example, this can be at a TPC
command error ratio level of 20%.

2.4 Call drop after a Layer 1 RLF detected by Node B
isPsRrcReestablishAllowed
isCSRrcReestablishAllowed
UE Node B SRNC
(RadioAccessService)
Radio Link Failure
Detection1
RL Failure Indication2
Radio Link Deletion3
rrcReestPSMaxAllowedTimer
or
rrcReestCSMaxAllowedTimer
Wait for a
CELL (RadioAccessService)
UPDATE
from the UE
At timer expiry
Call Drop counters are pegged4
Iu Release Request4
« radio connection with UE lost »

1: A failure is detected for the RL in the Node B.

2: The Node B sends a Radio Link Failure message to the SRNC.
3: A Radio Link Deletion procedure is performed. If this is the last Radio Link for the UE then the timer
rrcReestPSMaxAllowedTimer or timer rrcReestPSMaxAllowedTimer is started in order to wait for the UE to
send a Cell Update message to re-establish the connection. The timer should be larger than T314 / T315
respectively which is the maximum time after which the UE will release the RAB.
4: On expiry, the RNC initiated Iu release is started towards all involved CN parts and SRNC pegs call drop counters
on expiry of the timer rrcReestPSMaxAllowedTimer or timer rrcReestPSMaxAllowedTimer

2.5 Recovery after a L1 RLF detected by NodeB or UE
UE Node B SRNC
Cell Update (“radio link failure”)1
Radio Link (Deletion and) Setup2
Cell Update Confirm3
Radio Bearer Reconfiguration

Complete4

As soon as the UE has detected a Radio Link Failure, it switches to CELL_FACH and sends a Cell Update message to
UTRAN. UTRAN responds with a Cell Update Confirm message and reconfigures the UE. If the measurement report
is included, the reconfiguration can be based thereon. If the radio conditions don’t allow a reconfiguration, the RRC
connection will be released.
1: The UE signals the Radio Link Failure via a Cell Update message to the SRNC. The timer
rrcReestPSMaxAllowedTimer or timer rrcReestPSMaxAllowedTimer is stopped (if running).
2: The old Radio Link is removed if it was done previously (this is the case when the Radio Link Failure is first
detected in UL by the Node B). A new Radio Link is set up. If necessary, the compressed mode is configured and
possibly activated.
3: The SRNC sends a Cell Update Confirm message to the UE.
4: The UE confirms the successful reconfiguration with a Radio Bearer Reconfiguration Complete message and the
calls already established go on.

2.6 L3 RLC Unrecoverable Error detected by UE
In RLC AM, SDUs are retransmitted if not acknowledged.

UE UTRAN
SN36
pollingTimer started SN37 P=1
SN38
STATUS: SN36 missing
pollingTimer expiry SN65
SN37 P=1
pollingTimer restarted
SN66

RLF detected at L3 layer

 pollingTimer is started when a PDU with the polling bit set is transmitted.
 Ifno STATUS PDU (containing the acknowledgement of all previously sent PDUs) has been received before the
timer pollingTimer expires, the receiver must be polled again, either by transmission of a new PDU, or in a
retransmitted PDU.
 pollingTimer may be stopped by a status PDU carrying the wanted information.

2.6 L3 RLC Unrecoverable Error detected by UE [cont.]
When the transmission of an RLC PDU does not succeed within a certain
time limit, the SDU discard function allows avoiding a buffer overflow
 No discard option: if a PDU has been retransmitted maxDat times, the RLC
reset procedure is started.
UE UTRAN
SN139
pollingTimer expiry
after maxDat
RESET
retransmissions
resetTimer
started
RESET ACK
resetTimer
expiry RESET
After maxNbrOfResetRetrans retransmission of RESET PDU, a Cell

Update with cause “RLC unrecoverable error” is triggered
RLF detected at L3 layer

 RLC Reset procedure
The sender sends the RESET, starts the resetTimer and counts the RESET iteration.
 Upon reception of a RESET, the receiver responds with a RESET ACK.
 If the receiver does not answer, the sender retransmits the RESET upon expiry of resetTimer.
 In case of unsuccessful RESET, the RESET can be reiterated maxNbrOfResetRetrans.
 Algorithm
 An RLC unrecoverable error occurs, when the number of retransmissions for a Reset PDU has
exceeded maxNbrOfResetRetrans, or a protocol error occurs.
 The UE in Cell-DCH or Cell-FACH sends a Cell Update message on CCCH (RB 0) to notify UTRAN of an
unrecoverable error in the RLC entities by setting the cause value to RLC unrecoverable error and
setting the AM_RLC error indication for RB 2, 3 & 4 or RB > 4 to true.
 The recovery algorithm is then similar to the one implemented for RL failure. If the call cannot be
recovered, the call is dropped with an IU RELEASE, cause ‘Radio Connection with UE Lost’.
 At reception of a Cell Update with the IE RLC unrecoverable error set to true, the SRNC
resets the URBs if an unrecoverable error is indicated by the UE on URB. If the UE indicates
an unrecoverable error on the SRBs, the RNC releases the RRC connection.

2.7 Call drop after a Layer 3 RUE detected by RNC
UE Node B SRNC
DL RLC Unrecoverable
Error Detection1
Radio Link Deletion2
rrcReestPSMaxAllowedTimer
or
rrcReestCSMaxAllowedTimer
Wait for a
CELL (RadioAccessService)
UPDATE
from the UE
At timer expiry
Call Drop counters are pegged3
Iu Release Request3
« radio connection with UE lost »

1: A DL RLC Unecoverable Error is detected by the RNC.

2: A Radio Link Deletion procedure is performed. If this is the last Radio Link for the UE then the timer
rrcReestPSMaxAllowedTimer or timer rrcReestPSMaxAllowedTimer is started in order to wait for the UE to
send a Cell Update message to re-establish the connection. The timer should be larger than T314 / T315
respectively which is the maximum time after which the UE will release the RAB.
3: On expiry, the RNC initiated Iu release is started towards all involved CN parts and SRNC peg call drop counters
on expiry of the timer rrcReestPSMaxAllowedTimer or timer rrcReestPSMaxAllowedTimer.

2.8 L1 and L3 RL Failures
When radio conditions becomes too bad, at the same time take place
 An RL Failure and RL Recovery
 An RLC PDU retransmission
SIR < Qout SIR < Qin
(16+ nOutSyncInd) x 10 ms tRLFailure nInSyncInd x 10 ms
good bad
radio radio RL Failure RL Recovery
call drop time
RLC PDU retransmission RLC Reset

if too short,
(maxDat – 1) x pollingTimer RLC reset
occurs before
RL Recovery
(maxNbrOfResetRetrans – 1) x resetTimer




3.1 Estimate the impact of an RLM parameter change
For each of the RL Management parameter changes below and next page,
find which of the impacts proposed should be observed.
n313
tRLFailure
pollingTimer
nOutSyncInd
maxDat


1. increase the number of Radio Link Failure detections
2. decrease the number of Radio Link Failure detections
3. increase the number of RLC unrecoverable error detections
4. decrease the number of RLC unrecoverable error detections
Duration = 10 min



For each of the RL Management behavior changes below, find

which of the QoS indicators proposed should be impacted and in
which way or
RL Management behavior
 the nb of  the nb of RLC
Radio Link Failure Unrecoverable Error
detection detection
QoS indicator
Nb of Last Radio Link Drop
Call Drop Rate PS

Duration = 5 min

5 Examples of Radio Link Management
tuning


5 Examples of Radio Link Management tuning
5.1 nOutSyncInd parameter tuning
Radio synchronization (Inc-sync state) is difficult to keep upon sudden

radio condition changes
 Corner effects
 Open areas with pilot pollution
 Compressed mode activation/deactivation
 of the nOutSyncInd value will reduce the risk of RL Failure detection.

Therefore, we can expect a call drop  if the nOutSyncInd value 


5.1 nOutSyncInd parameter tuning [cont.]
nOutSyncInd value  reduces the risk of RL Failure
This is confirmed by Link-level

simulations in lab
 Due to estimation of SIR,
there can be quite a long time,
during which the Node B does
not detect the RLF: 50% of
the cases are lasting longer
than NOutsyncInd+16 frames.
These charts show the Density Function of the Probability to go to Out-of-sync state as a function of the time.
The higher nOutSyncInd value, the lower the probablility to go Out-of-sync after a defined time.

5.1 nOutSyncInd parameter tuning [cont.]
System and radio call drop rate decrease

 CDR  from 4% to 2.7% when nOutSyncInd  from 20 to 200
nOutSyncInd = 20 nOutSyncInd = 200
25000 6,00%
20000 5,00%
4,00%
15000
3,00%
10000
2,00%
5000 1,00%
0 0,00%
06 4/2 5
5
06 /2 5
5
5
06 /2 5
06 /2 5
5
5
5
06 9/2 5
05
5
06 6/2 5
0/ 5
/1 00
/1 00
/1 00
/1 00
/1 00
/2 00
/2 00
/2 00
/2 00
/2 00
/2 00
/2 00
/1 00
/2 00
/2 00
/2 00
/3 00
20
06 3/2
06 6/2
06 8/2
06 9/2
06 1/2
06 /2
06 7/2
06 /2
06 5/2
06 4/2
06 /2
7
2
3
8
0
5
/1
06
AMR req CS64 req % System drop % AMR Drop

nOutSyncInd increase will also reduce the ping-pong effect in SHO areas with fast variation of radio conditions
that can lead to a call drop (ASU not seen by the UE). (Corner Effect)

5.2 maxDat parameters tuning
maxDat value  reduces the risk of RLC unrecoverable error

  the probability that the RL Failure be recovered after failure
maxDat  from 15 to 35 on January 19th
Call Drop Iu Release CS 10-01-2006 11-01-2006 12-01-2006 13-01-2006 14-01-2006 15-01-2006 16-01-2006 17-01-2006 18-01-2006 19-01-2006
CS 2109 2174 1404 1420 1041 885 1446 1511 1618 1042
% CS 2,02% 2,05% 1,32% 1,30% 1,16% 1,17% 1,40% 1,37% 1,60% 0,99%
CS calls 104336 105997 106188 109501 89611 75582 103286 110388 101082 104999
Call Drop Iu Release CS 20-01-2006 21-01-2006 22-01-2006 23-01-2006 24-01-2006 25-01-2006 26-01-2006 27-01-2006 28-01-2006 29-01-2006
CS 1359 782 663 979 1010 1045 1024 1091 849 828
% CS 1,35% 0,90% 0,88% 1,00% 0,99% 1,00% 0,89% 1,03% 0,92% 0,96%
CS calls 100411 86989 75385 0,89% 101529 104987 115106 106164 92102 85908
CDR  from ~1.3% to 0.9%

 CDR improved by 30%

NOTES:
1. The CDR improvement on january 12th is not due to NOutsyncInd modification.
2. The CDR on january 20th is degraded due to UTRAN system problems.

5.2 maxDat parameters tuning [cont.]
maxDat value  from 15 to 35

Call Drop Iu Release CS
2500 2,50%
2000 2,00%
CS
1500 1,50%
%CS
1000 1,00%
500 0,50%
0 0,00%
10-01-2006
11-01-2006
12-01-2006
13-01-2006
14-01-2006
15-01-2006
16-01-2006
17-01-2006
18-01-2006
19-01-2006
20-01-2006
21-01-2006
22-01-2006
23-01-2006
24-01-2006
25-01-2006
26-01-2006
27-01-2006
28-01-2006
29-01-2006
CDR  from ~1.3% to 0.9%
 CDR improved by 30%

NOTES:
1. The CDR improvement on january 12th is not due to NOutsyncInd modification.
2. The CDR on january 20th is degraded due to UTRAN system problems.
Explanation
 Once radio synchronization is lost, the UE takes around 5 seconds to detect the RL failure
((16+N313) x 10 ms+T313), then it takes around 2 seconds to reselect a cell and perform a Cell Update
procedure.
So it means at least 7 seconds before RL Recovery starts.
 When maxDAT= 15, the UE may retransmit during 3 seconds (maxDAT x pollingTimer = 15 x 200 ms)
and then waits for 1.2 second ((maxNbrOfResetRetrans +1) x resetTimer = (3+1) x 30 0ms) before
resetting RLC.
So it means at least 4.2 seconds before RLC reset.
Therefore, the RL Failure cannot be recovered.
 When maxDAT = 35, the UE may retransmit during 7 seconds (maxDAT x pollingTimer = 35 x 200 ms)
and then waits for 1.2 second ((maxNbrOfResetRetrans +1) x resetTimer = (3+1) x 300 ms) before
resetting RLC.
So it means at least 8.2 seconds before RLC reset.
 Therefore, the RL Failure can be recovered.
 If the UE has a message to transmit in UL, which is of course not always the case, it will manage to
avoid the RLC reset if the first Cell Update is successful.

Summary
Radio Link Management TUNING
Loss of radio synchronization should not trigger an RL Failure too quickly

 nOutSyncInd set to the max value 256
In case of RL Failure, RLC unrecoverable error should not be detected before RL

Recovery can be completed
 maxDat for UL and DL RLC AM set to the value 40


End of module


Section 2
Module 6
Tune Radio Resource Management
UTRAN

Blank page

Tuning key UTRAN algorithms · Tune Radio Resource Management
Document History

Module objectives
 Explain the objectives of the Radio Resource Management algorithms of the

Alcatel-Lucent UTRAN
 Present the principles of the Radio Resource Management algorithms
performance of the different Radio Resource Management algorithms




Table of contents
1 Objectives of radio resource management algorithms 7

1.1 Objectives 8
1.2 RRM algorithms 1 & 2 at R99 PS call admission 9
1.3 RRM algorithm 3 at CS (or R99 PS) call admission 10
1.4 RRM algorithms 4 & 5 during R99 PS I/B call 11
1.5 RRM algorithm 6 during R99 PS Str/I/B call 12
1.6 RRM algorithm 7 during R99 PS I/B call 13
1.7 RRM algorithm 8.x during Calls (CS, PS, R99, HSPA) 14
2 Tune iRM algorithm 15
2.1 Overview 16
2.2 iRM DL load color thresholds 17
2.3 iRM UL load color thresholds 18
2.4 Estimate the impact of an iRM parameter change 19
3 Tune CAC on UL radio load algorithm 21
3.1 iRM UL load color thresholds 22
3.2 Estimate the impact of a UL CAC parameter change 23
4 Tune pre-emption process algorithm 25
4.1 Mono-step / Multi-step pre-emption 26
4.2 Selection of services to be downgraded 27
4.3
2·6·5
Example: downgrading pre-emption in downlink 28
4.4 Estimation
Tuning key of Radio
UTRAN algorithms · Tune resource de-allocation
Resource Management 29
4.4.1 Examples 30
4.5 Estimate the impact of a pre-emption parameter change 31
5 Tune always-on algorithm 33
5.1 AON transitions overview 34
5.2 AON downsize 35
5.2.1 AON downsize step 1: cell_DCH -> cell_FACH 36
5.2.2 AON downsize step 2: cell_FACH -> X_PCH 37
5.2.3 AON downsize step 3: X_PCH -> Idle 38
5.2.4 AON downsize step 3: cell_FACH -> Idle 39
5.3 AON upsize 40
5.3.1 AON upsize step 2: X_PCH -> cell_FACH 41
5.3.2 AON upsize step 1: cell_FACH -> cell_DCH (UL reason) 42
5.3.3 AON upsize step 1: cell_FACH -> cell_DCH (DL reason) 43
5.4 Which key parameters to tune? 44
5.5 Which QoS indicators to monitor? 46
6 Tune RB rate adaptation algorithm 48
6.1 RB rate adaptation overview 49
6.2 Traffic monitoring: UL & DL throughput 50
6.3 Traffic monitoring: UE buffer occupancy 51
6.4 Traffic monitoring: RNC buffer occupancy 52
6.5 RB UL downsize 53
6.6 RB DL downsize 54
6.7 RB UL upsize 55
6.8 RB DL upsize – Step by step 56
6.9 RB DL upsize – multi stage 57
6.10 Estimate the impact of an RB RA parameter change 58
7 Tune iRM scheduling algorithm 60
7.1 iRM scheduling objective 61
7.2 iRM scheduling overview 62
7.3 iRM scheduling downgrade 63

7.3.1 Primary cell in DRNC 64

7.4 iRM scheduling upgrade to nominal RB 65
7.5 iRM scheduling upgrade to intermediate RB 67
7.6 Which key parameters to tune? 69
7.7 Which QoS indicators to monitor? 70
8 Examples of radio resource management tuning 71
8.1 totalRoTMax to increase UL Mac-d HSUPA cell throughput 72
8.2 timerT1 to decrease RB blocking rate 73
8.2.1 RB success rate 74
8.2.2 RadioLinkEstablishedPerCell for PS384 75
8.2.3 RadioLinkEstablishedPerCell for PS128 & PS64 76
8.2.4 kbytes before drop 77
8.2.5 Number of AON downsize and upsize step1 78


1 Objectives of radio resource
management algorithms


1 Objectives of radio resource management algorithms
1.1 Objectives
Optimize the usage of radio resources
 For CS calls:
 maximize the number of CS calls
 minimize the CS call blocking rate
 minimize the CS call drop rate
 For PS calls:
 maximize the number of kilobytes transferred on PS calls
 minimize the PS call blocking rate
 minimize the PS call drop rate
RRM algorithms to be tuned in order to:

find the best compromise between capacity and quality
focus on the most important service(s) according to the operator strategy


1.2 RRM algorithms 1 & 2 at R99 PS call admission
Algorithm 1?
Algorithm 2?

The parameters red2BlackCLCThreshold and black2RedCLCThreshold define the thresholds on code load to
transition from Red to Black and Black to Red. They are only used by IMCRA and IMCTA and will not impact old
features. Indeed, the iRM feature will still use Green/Yellow/Red.

1.3 RRM algorithm 3 at CS (or R99 PS) call admission
DL load (%)
Algorithm 3?
100
UE14 Speech UE14 Speech
UE12 DL64 UE12 DL64
Cell is Red UE11 Speech UE11 Speech
UE9 DL64 UE9 DL64
yellow2red UE8 DL128 UE8 DL128
Cell is Yellow Congestion

UE7 DL128 UE7 DL128
green2yellow UE6 Speech UE6 Speech
Cell is Green
UE2 DL384 UE15 Speech
UE2 DL64
0 UE1 Speech UE1 Speech
time
UE15 wants to set up a CS Speech call


1.4 RRM algorithms 4 & 5 during R99 PS I/B call
Algorithm 4? Algorithm 5?


1.5 RRM algorithm 6 during R99 PS Str/I/B call
Algorithm 6?
Downgrade
Nominal RB
Intermediate RB
Fallback RB Upgrade
DL 384 kbit/s
DL 128 kbit/s
DL 64 kbit/s


1.6 RRM algorithm 7 during R99 PS I/B call
DL load (%)
100
normal2congested UE13 DL64
UE12 Speech
congested2normal UE11 Speech
UE10 Speech UE13 DL64
UE11 Speech
UE8 DL128 Algorithm 7? UE10 Speech
UE9 DL64
UE7 DL128
UE8 DL64
UE6 Speech
UE5 Speech UE7 DL128
UE4 Speech
UE6 Speech
UE3 Speech
UE5 Speech
UE4 Speech
UE2 DL64
Cell changes from Normal Cell changes back

to Congested state to Normal state


1.7 RRM algorithm 8.x during Calls (CS, PS, R99, HSPA)
Lte layer
GSM layer
FDD2 HSPA
HHO Alarm
Mobility Service
FDD1 DCH
CAC Failure (R99)
AO downsize
User Service
CsSpeech CsConversational … CsSpeech + other

F1 1 1 .. 2
F2 2 2 .. 1
GSM 1 PNA .. 3


2 Tune iRM algorithm


2.1 Overview
Thresholds
on DL
resource
usage
Thresholds
on UL
resource
usage


2.2 iRM DL load color thresholds
DL Code Load
yellow2RedCLCThreshold 70 %
red2YellowCLCThreshold
60 %
green2YellowCLCThreshold 50 %
40 % yellow2GreenCLCThreshold
DL Power Load
yellow2RedPLCThreshold 70 %
red2YellowPLCThreshold
60 %
green2YellowPLCThreshold 50 %
40 % yellow2GreenPLCThreshold
DL Iub Load Worst DL Cell Color

yellow2RedDlTLCThreshold 90 %
red2YellowDlTLCThreshold
80 %
green2YellowDlTLCThreshold 70 %
60 % yellow2GreenDlTLCThreshold
DL CEM Load
yellow2RedDlCEMThreshold 90 %
red2YellowDlCEMThreshold
80 %
green2YellowDlCEMThreshold 70 %
60 % yellow2GreenDlCEMThreshold

features. The iRM feature will still use Green/Yellow/Red.

2.3 iRM UL load color thresholds
UL Radio Load
70 %
yellow2RedUlRadioLoadThreshold
red2yYellowUlRadioLoadThreshold
60 %
green2yYellowUlRadioLoadThreshold
50 %
40 % yellow2GreenUlRadioLoadThreshold
Worst UL Cell Color
UL CEM Load
yellow2RedUlCEMThreshold
90 %
80 % red2yYellowUlCEMThreshold
green2yYellowUlCEMThreshold 70 %
60 % yellow2GreenUlCEMThreshold

features. The iRM feature will still use Green/Yellow/Red.

2.4 Estimate the impact of an iRM parameter change
For each of the iRM parameter changes below, find which of the impacts
iRM parameter change impact
yellow2RedCLCThreshold
yellow2GreenPLCThreshold
yellow2RedUlCEMThreshold
green2YellowDlTLCThreshold
yellow2GreenUlRadioLoadThreshold
red2YellowDlCEMThreshold


1.delay G to Y color change
2.speed-up G to Y color change
3.delay Y to R color change
4.speed-up Y to R color change
5.delay R to Y color change
6.speed-up R to Y color change
7.delay Y to G color change
8.speed-up Y to G color change
Precise if it is:
a.DL Code color change
b.DL Power code change
c.DL Iub Load color change
d.DL CEM color change
e.UL Radio Load color change
f.UL CEM color change
Duration = 10 min

For each of the iRM behavior changes below, find which of the QoS
indicators proposed should be impacted and in which way or or
QoS indicator RB blocking % of time RRC conn. % of time cell Avg number
iRM behavior rate cell is red success rate is yellow of CS calls
delay G to Y color change
speed-up Y to G color change
speed-up Y to R color change
speed-up R to Y color change


 RB blocking rate = Percentage of RBs that cannot be set up due to a lack of resources
% of time cell is red = Percentage of time that a cell is in iRM RED color
 RRC conn. Success rate = Percentage of RRC Connections that are successfully set up
% of time cell is yellow = Percentage of time that a cell is in iRM YELLOW color
 Avg number of CS calls = Average number of CS RABs that are simultaneously established
Duration = 10 min

3 Tune CAC on UL radio load algorithm


3.1 iRM UL load color thresholds
UL loadnon E-DCH (%) Max total UL load RTWPref + totalRotMax
E-DCH+non E-DCH 
rtwpMaxCellLoadCacActivation E-DCH E-DCH

E-DCH traffic traffic
= True E-DCH traffic capacity capacity
traffic capacity
capacity rejected
rtwpMaxCellLoadNonEdc accepted accepted

h accepted accepted accepted
Cell is Red UL64 UL64 UL64 UL64

UL64 UL64 UL64 UL64
yellow2red UL128 UL128 UL128 UL128
Cell is Yellow UL128 UL128 UL128 UL128
green2yellow
UL128 UL128 UL128 UL128
Cell is Green
UL128 UL128 UL128 UL128
Speech Speech Speech Speech

time

3.2 Estimate the impact of a UL CAC parameter change
For each of the CAC on UL Radio Load parameter changes below, find
which of the impacts proposed should be observed
UL CAC parameter change impact
rtwpMaxCellLoadNonEdch
totalRotMax


1.delay UL Radio Load CAC failure
2.speed-up UL Radio Load CAC failure
3.increase R99 UL traffic capacity of the cell
4.decrease R99 UL traffic capacity of the cell
5.increase E-DCH UL traffic capacity of the cell
6.decrease E-DCH UL traffic capacity of the cell
7.increase total (R99+E-DCH) UL traffic capacity of the cell
8.decrease total (R99+E-DCH) UL traffic capacity of the cell
Duration = 10 min

For each of the CAC on UL Radio Load behavior changes below, find which
of the QoS indicators proposed should be impacted and in which way or
or or depends
QoS indicator RB blocking % of time RRC conn. Avg number E-DCH cell
UL CAC behavior rate cell is red success rate of CS calls throughput
speed-up UL Radio Load

CAC failure
increase R99 UL traffic
capacity of the cell
increase E-DCH traffic
capacity of the cell


% of time cell is red = Percentage of time that a cell is in iRM RED color
 E-DCH cell throughput
Duration = 10 min

4 Tune pre-emption process algorithm


4.1 Mono-step / Multi-step pre-emption
Choice between RAB Downgrade or RAB Release is only for R99 PS calls
Any other call (CS or HSxPA) leads to a release of the RAB when pre-empted
Mono-Step Multi-Step
preemptionDowngradeReleaseSteps preemptionDowngradeReleaseSteps
(Preemption) (Preemption)
DCH HS-DSCH DCH

E-DCH
Any value
DowngradeOnly ReleaseOnly DowngradeThenRelease
Preempted service Preempted service Preempted service

is downgraded is released is downgraded
next Pre-emption process

In case of a pre-empted DCH PS call, there is a possibility to downgrade the PS call RB bit rate before triggering a
PS call drop if needed.
In order to set the parameter preemptionDowngradeReleaseStep to ReleaseOnly, it is required to have the
parameters preemptionFloorBitRateInDownlink/Uplink defined to <unset>.

4.2 Selection of services to be downgraded
Only valid for Downgrading pre-emption
RadioAccessService
R99 PB RBs selected

Preemption
for downgrading
preemptionFloorBitRateInDownlink
preemptionFloorBitRateInUplink
Filtering on
Target bit rate
PS RB bit rate > preemptionFloorBitRateInXX
R99 PB RBs selected R99 PS RBs selected

Keep the Max bit rate PS RBs
for downgrading for downgrading

The preemptionFloorBitRateInxxxx (xxxx is downlink or uplink) is the RB bit rate over which the DCH PS call
can be selected for being pre-empted. It is also, at the same time, the target RB bit rate to which the pre-empted
DCH PS call is reconfigured.

4.3 Example: downgrading pre-emption in downlink
DL load (%)
Pre-emption
100
UE12 DL64 UE12 DL64
Cell is Red UE11 Speech UE11 Speech
UE9 DL64 UE9 DL64
yellow2red UE8 DL128 UE8 DL128
Cell is Yellow
UE7 DL128 Congestion UE7 DL128
green2yellow UE6 Speech UE6 Speech
Cell is Green
UE2 DL64
time
UE15 wants to set up a CS Speech call


4.4 Estimation of resource de-allocation
DCH Service CAC Failure
Service(s) Preempted so that

Node B / Code / Power Ul (Dl) resource rate to be freed No
UL (DL) CAC Failure > DeallocationThreshold Free resource =
Ul (Dl) Radio rate to be allocated
* Ul (Dl) DeallocationFactor [High]
Yes
Service(s) Preempted so that

Free resource =
Ul (Dl) Radio rate to be allocated
* Ul (Dl) DeallocationFactor [Low]
Preemption
PreemptionDeallocationInfo
preemptionDeallocationFactorInDownlink
[High,Low]
preemptionDeallocationFactorInUplink [High,Low]
preemptionDeallocationThresholdInDownlink
preemptionDeallocationThresholdInUplink

An estimation of the resource needed has to be done in the following CAC failure cases:
 Node B: DCH resource allocation failure
 Code: DCH or HS-DSCH resource allocation failure
 Power: DCH or HS-DSCH resource allocation failure
When the CAC failure occurs at Node B level for HS-DSCH or E-DCH resource allocation, a “one to one” release
action is processed (i.e. a P-Service established on HS-DSCH or E-DCH is released) without taken into account the
resource quantity used.
In order to have a common estimator of all resources to be de-allocated, whatever where the CAC failure occurs,
the estimation of resources needed is based on:
 the current radio bit rates if the CAC failure concerns DCH resources allocation at Node B or RNC sides (power
and code). The resource quantity to be de-allocated in a congested cell is based on the sum of radio estimated
downlink rates needed to establish all P-Services of the call in this cell.
 the fair bit rate if the CAC failure concerns HSDPA resources allocation on RNC side (power and code). The
resource quantity to be de-allocated in a congested cell is based on the sum of fair bit rates needed to establish
all P-Services of the call in this cell. The fair bit rate of a P-Service is calculated by the fair sharing function and
is either the GBR, the MinBR (defined by OAM) if non null or the minHsDschReservationForCac (defined by
OAM).
The resource de-allocation calculation uses a de-allocation factor (defined by OAM) to major the quantity of
resources to be freed. The unit is the kbits/sec. The resource to be freed is defined by the formula:
 ULresource rate to be freed= UL Radio rate to be allocated * UL de-allocation factor
 DL resource rate to be freed= DL Radio rate or fair bit rate to be allocated * DL de-allocation factor
The de-allocation factor depends on the resource quantity to be freed:
 If the resource quantity <= threshold, the de-allocation factor used is the high factor value defined by
OAM.
 If the resource quantity > threshold, the de-allocation factor used is the low factor value defined by
OAM.

4.4 Estimation of resource de-allocation
4.4.1 Examples
Assumptions:
 preemptionDeallocationFactorInDownlink [High,Low] = [200,120] (%)
 preemptionDeallocationThresholdInDownlink = 16 (kbps)
If the pre-emption process is triggered to set up:

 an R99 PS128 Interactive call
 the quantity of DL resources freed corresponds to a bit rate of 1,2*128 kbps = 153,6
kbps
 a CS AMR NB speech call

 the quantity of DL resources freed corresponds to a bit rate of 2*12,2 kbps = 24,4
kbps


4.5 Estimate the impact of a pre-emption parameter change
For each of the Pre-emption Process parameter changes below, find which
Pre-emption Process parameter change impact
preemptionDeallocationFactorInUplink[high]
preemptionDeallocationThresholdInDownlink
preemptionFloorBitRateInUplink
preemptionDeallocationFactorInDownlink[low]
preemptionDeallocationThresholdInUplink


1.Increase the amount of DL resources freed when R99 PS RB pre-emption is triggered
2.Increase the amount of UL resources freed when R99 PS RB pre-emption is triggered
3.Decrease the amount of DL resources freed when R99 PS RB pre-emption is triggered
4.Decrease the amount of UL resources freed when R99 PS RB pre-emption is triggered
5.Increase the number of R99 PS RB downgraded in DL by the pre-emption process
6.Increase the number of R99 PS RB downgraded in UL by the pre-emption process
7.Decrease the number of R99 PS RB downgraded in DL by the pre-emption process
8.Decrease the number of R99 PS RB downgraded in UL by the pre-emption process
Duration = 10 min

For each of the Pre-emption Process behavior changes below, find which of
the QoS indicators proposed should be impacted and in which way or
or
QoS indicator RB blocking RRC conn. Avg number Avg R99 PS Avg HSxPA cell
Pre-emption Process behavior rate success rate of CS calls throughput throughput
Increase the number of R99

PS RB downgrade
Decrease the amount of
resources freed


 Avg R99 PS throughput = Average throughput measured on all the R99 PS RB of a certain bit
 rate
 Avg HSxPA throughput = Average HSDPA or E-DCH throughput measured on all the HSDPA RB or HSUPA
RB
Duration = 10 min

5 Tune always-on algorithm


5.1 AON transitions overview


5.2 AON downsize
pchRrcStates ≠ None
User Traffic T1 T2
Volume
AO step1 AO step2 AO step3
T1
Throughput Threshold
AO Step 1
T1
traffic traffic and signaling

O kbps inactivity inactivity Throughput Threshold
AO Step 2
T1 T1 T2 T3
AO timers
CELL_PCH
CELL_DCH CELL_FACH or PMM-idle
URA_PCH
NOMINAL DCH RB AO FACH RB No Radio Bearer No Radio Bearer
RRC connection No RRC connection

Transition Trigger
 CELL_DCH to CELL_FACH: User low traffic (UL&DL) & Timer
 CELL_DCH to CELL/URA_PCH: User inactivity & Timer or CS call release
 (CS+PS00)
 CELL_DCH/CELL_FACH to CELL/URA_PCH: Trigger of SCRI by UE

 CELL_FACH to CELL_PCH: User inactivity & Timer
 CELL_FACH to URA_PCH: User inactivity & Timer
 CELL_FACH to Idle: User inactivity & Timer
 CELL_PCH to URA_PCH: Number of cell update procedures & Timer
 CELL_PCH to Idle: RRC Signaling inactivity & Timer
 URA_PCH to Idle : RRC Signaling inactivity & Timer
 CELL_PCH to CELL_FACH:
 Traffic resuming
 New service establishment
 Signaling message
 CELL/URA_PCH to CELL_DCH:
 PS Traffic resuming based on TVI (UA08.1)
 CS Call Establishment (UA08.1 or UA7.1.3.6)
 PS MUX traffic resuming
 CELL_FACH to CELL_DCH: User traffic (buffer threshold in UL or DL)

5.2 AON downsize
5.2.1 AON downsize step 1: cell_DCH -> cell_FACH
UL & DL
Traffic Volume
step1AverageWindow
6 kbps step1DlUlThroughputThreshold
timerT1
timerT1ForHsdpa
timerT1ForHsdpaAndEdch
Cell_DCH Cell_FACH
NOMINAL DCH RB AO FACH RB


5.2 AON downsize
5.2.2 AON downsize step 2: cell_FACH -> X_PCH
UL & DL
Traffic Volume pchRrcStates ≠ None
step2AverageWindow
0 kbps step2ThroughputThreshold
UraAndCellPchEnabled / CellPchEnabled fachToCellPchTimer Cell_PCH

UraPchEnabled fachToUraPchTimer URA_PCH
Cell_DCH Cell_FACH
AO FACH RB no dedicated Radio Bearer

NOMINAL DCH RB
RRC connection


5.2 AON downsize
5.2.3 AON downsize step 3: X_PCH -> Idle
UL & DL
Traffic Volume pchRrcStates ≠ None
0 kbps
fachToCellPchTimer cellPchToIdleTimer
Idle
fachToUraPchTimer uraPchToIdleTimer
Cell_FACH Cell_PCH or URA_PCH
no dedicated Radio Bearer no Radio Bearer

AO FACH RB but RRC connection kept no RRC connection

When the UE is in either CELL_PCH or URA_PCH state, no dedicated Radio Bearer is assigned to the user. The DTCH
Logical Channel no longer exists.
Hence there is no need to measure the user traffic activity, as the user is inactive as long as:
• It is not paged by the network. The UE then answers to the Paging type 1 by a Cell Update message (with cause
Answer to paging).
• It performs a cell update (with cause Uplink data transmission) before a timer expires.
The decision is then based on signaling activity monitoring.

5.2 AON downsize
5.2.4 AON downsize step 3: cell_FACH -> Idle
UL & DL
Traffic Volume pchRrcStates = None
step2AverageWindow
0 kbps step2ThroughputThreshold
timerT2
Cell_DCH Cell_FACH Idle
no Radio Bearer
NOMINAL DCH RB AO FACH RB
no RRC context


5.3 AON upsize
UL or DL
Traffic Volume
AO step2 AO step1
Throughput Threshold
AO Step 1
traffic
resuming
O kbps Throughput Threshold
AO Step 2
TTT
AO timers
CELL_PCH
or CELL_FACH CELL_DCH
URA_PCH
no dedicated Radio Bearer AO FACH RB NOMINAL DCH RB
RRC connection


5.3 AON upsize
5.3.1 AON upsize step 2: X_PCH -> cell_FACH

Ast case is when CN CS initiates a call setup, UE being in X_PCH state:
Specific case of PS I/B Mux configuration:

This Multi-RAB configuration is not supported on the FACH yet. Thus, the Always-on Step 1 is skipped for (PS I/B
Mux + SRB) configurations: there is a direct transition from CELL_DCH to CELL_PCH (or URA_PCH) for the downsize
and from CELL_PCH (or URA_PCH) to CELL_DCH for the upsize.
The principle used for the monitoring of the downsize is the following:
If one of the 2 RABs is inactive, nothing is done, i.e. no synchronous Radio Link or Radio Bearer reconfiguration is
triggered.
If the 2 RABs are inactive (i.e. 0 kbps in uplink and downlink during a certain period of time) then the UE is moved
to CELL_PCH or URA_PCH state depending on activation flags. In case X_PCH is not activated, the Iu and the RRC
Connection are released.
It is managed the same way if there is a simultaneous speech call, except that the UE is kept in CELL_DCH but
reconfigured to CS + PS I/B Mux UL 0 kbps / DL 0 kbps. In case X_PCH is not activated, the Iu-PS is released but
the RRC Connection is kept, as well as the Iu-CS connection.
5.3 AON Upsize
5.3.2 AON upsize step 1: cell_FACH -> cell_DCH (UL reason)
UE RLC/MAC
UL Buffer Occupancy Reporting
in the UE Event4a
Report
repThreshold
timeToTrigger pendTimeAfterTrig
AO FACH RB NOMINAL DCH RB
Event4a (UE->RNC)

The Always-on Step 1 upsize procedure is going through the iRM & CAC and is also limited by the parameters
maxUlEstablishmentRbRate and maxDlEstablishmentRbRate.
That’s why the resource allocated to the user at the upsize will not necessarily be the same as the one allocated at
the admission.

5.3 AON Upsize
5.3.3 AON upsize step 1: cell_FACH -> cell_DCH (DL reason)
UE RLC/MAC
DL Buffer Occupancy
in the RNC Upsize
Required
step1DlRlcBoThreshold
step1TimerBetween2Reports
AO FACH RB NOMINAL DCH RB
Internal RNC Event (IN->CN)


5.4 Which key parameters to tune?
For each of the Always-On parameter changes below and next page, find
which of the impacts proposed should be observed.
Always-On parameter change impact
step1AverageWindow
step2AverageWindow
cellPchToIdleTimer
timeToTrigger
timerT2
fachToUraPchTimer
step1DlRlcBoThreshold


1.delay AON Downsize Step 1: Cell_DCH -> Cell_FACH
2.speed-up AON Downsize Step 1: Cell_DCH -> Cell_FACH
3.delay AON Downsize Step 2: Cell_FACH -> X_PCH
4.speed-up AON Downsize Step 2: Cell_FACH -> X_PCH
5.delay AON Downsize Step 3: X_PCH -> Idle
6.speed-up AON Downsize Step 3: X_PCH -> Idle
7.delay AON Downsize Step 3: Cell_FACH -> Idle
8.speed-up AON Downsize Step 3: Cell_FACH -> Idle
9.delay AON Upsize Step 2: X_PCH -> Cell_FACH
10.speed-up AON Upsize Step 2: X_PCH -> Cell_FACH
11.delay AON Upsize Step 1: Cell_FACH -> Cell_DCH (UL reason)
12.speed-up AON Upsize Step 1: Cell_FACH -> Cell_DCH (UL reason)
13.delay AON Upsize Step 1: Cell_FACH -> Cell_DCH (DL reason)
14.speed-up AON Upsize Step 1: Cell_FACH -> Cell_DCH (DL reason)
Duration = 15 min

5.4 Which key parameters to tune? [cont.]
repThreshold
uraPchToIdleTimer
step1DlUlThroughputThreshold
fachToCellPchTimer
timerT1
pendTimeAfterTrig
step1TimerBetween2Reports


1.delay AON Downsize Step 1: Cell_DCH -> Cell_FACH
2.speed-up AON Downsize Step 1: Cell_DCH -> Cell_FACH
3.delay AON Downsize Step 2: Cell_FACH -> X_PCH
4.speed-up AON Downsize Step 2: Cell_FACH -> X_PCH
5.delay AON Downsize Step 3: X_PCH -> Idle
6.speed-up AON Downsize Step 3: X_PCH -> Idle
7.delay AON Downsize Step 3: Cell_FACH -> Idle
8.speed-up AON Downsize Step 3: Cell_FACH -> Idle
9.delay AON Upsize Step 2: X_PCH -> Cell_FACH
10.speed-up AON Upsize Step 2: X_PCH -> Cell_FACH
11.delay AON Upsize Step 1: Cell_FACH -> Cell_DCH (UL reason)
12.speed-up AON Upsize Step 1: Cell_FACH -> Cell_DCH (UL reason)
13.delay AON Upsize Step 1: Cell_FACH -> Cell_DCH (DL reason)
14.speed-up AON Upsize Step 1: Cell_FACH -> Cell_DCH (DL reason)

5.5 Which QoS indicators to monitor?
For each of the Always-On behavior changes below, find which of the QoS
QoS indicator
CELL-DCH  CELL-FACH  CELL-FACH  xPCH  CELL-FACH xPCH
CELL-FACH CELL-DCH xPCH CELL-FACH  IDLE  IDLE
AON behavior
delay AON Downsize Step 1:
Cell_DCH -> Cell_FACH
speed-up AON Downsize Step 2:
Cell_FACH -> X_PCH
X_PCH -> Idle
Cell_FACH -> Idle
delay AON Upsize Step 2:
X_PCH -> Cell_FACH
speed-up AON Upsize Step 1:
Cell_FACH -> Cell_DCH (UL reason)
Cell_FACH -> Cell_DCH (DL reason)


 CELL-DCH  CELL-FACH = Number of State Transitions Cell_DCH to Cell_FACH (AON downsize step 1)
 CELL-FACH  CELL-DCH = Number of State Transitions Cell_FACH to Cell_DCH (AON upsize step 1)
 CELL-FACH  xPCH = Number of State Transitions Cell_FACH to Cell_PCH or URA_PCH (AON downsize step 2)
 xPCH  CELL-FACH = Number of State Transitions Cell_PCH or URA_PCH to Cell_FACH (AON upsize step 2)
 CELL-FACH  IDLE = Number of State Transitions Cell_FACH to Idle (AON downsize step 3 when PCH states are
not used)
 xPCH  IDLE = Number of State Transitions Cell_PCH or URA_PCH to Idle (AON downsize step 3 when PCH
states are used)
Duration = 15 min

5.5 Which QoS indicators to monitor? [cont.]
For each of the Always-On behavior changes below, find which of the QoS
QoS indicator
AON downsize AON upsize PS RB PS call
per call per call blocking rate drop rate
AON behavior
Cell_DCH -> Cell_FACH
Cell_FACH -> X_PCH
X_PCH -> Idle
Cell_FACH -> Idle
X_PCH -> Cell_FACH
speed-up AON Upsize Step 1:
Cell_FACH -> Cell_DCH (UL reason)
Cell_FACH -> Cell_DCH (DL reason)


 AON downsize per call = Number of State Transitions Cell_DCH to Cell_FACH (AON downsize step 1) per PS call
 AON upsize per call = Number of State Transitions Cell_FACH to Cell_DCH (AON upsize step 1) per PS call
 PS RB blocking rate = Percentage of RBs for a PS call that fail to be set up because of a lack of radio resources
 PS call drop rate =Percentage of PS calls that drop (Iu Release Request sent by RNC to CN-PS for an abnormal
reason (different that Normal call release or Traffic inactivity timeout)

6 Tune RB rate adaptation algorithm


6.1 RB rate adaptation overview
Current DCH PS RB (UL/DL) Adapted DCH PS RB (UL/DL)
RB Rate Adaptation (UL/DL)
RB Resizing (UL/DL)
Estimated
Throughput
Traffic Monitoring (UL/DL)
(DL/UL)
32 64 128 384

The mechanism is made up of 2 main functions:

 Traffic Monitoring: periodically estimates the user activity in UL and DL at RLC level.
 RB Resizing Process: determines if the current RB needs to be adapted (independently in UL and DL) based
on traffic monitoring output and triggers bit rate resizing if required.

6.2 Traffic monitoring: UL & DL throughput
Throughput Estimates
raUnitPeriodTime
raUnitPeriodTime
T0 T1 T2 T3 T4
time
Rate[0]=0 Rate[0]=0 Rate[0]=0 Rate[0]=N0/T Rate[0]=N1/T

Rate[1]=0 Rate[1]=0 Rate[1]=N0/T Rate[1]=N1/T Rate[1]=N2/T raNbOfSample
raNbOfSample
Rate[2]=0 Rate[2]=N0/T Rate[2]=N1/T Rate[2]=N2/T Rate[2]=N3/T
1 K 1
1 K 1
R
K
 Rate k  S2   Rate k   R 2
K  1 k 0
k 0
Confidence Level
throughput Estimate
RLC-SDU
throughput
Confidence Interval = 2 ß raModifiedStudentCoef

raModifiedStudentCoef
S
Reliable Throughput Estimate  t ,K   raMaxConfidenceInt
raMaxConfidenceInt
R K


6.3 Traffic monitoring: UE buffer occupancy
Reporting Reporting
UE RLC/MAC Event4a Event4a
UL BO
in the UE
ul4AThreshold
measQtyAverageTime
ul4ATimeToTrigger rcMeasPendingTriggerTime
UL DCH1 RB UL DCH2 RB
Event4a (UE->RNC)


6.4 Traffic monitoring: RNC buffer occupancy
Reporting Reporting
UE RLC/MAC Event Event
DL BO
in the RNC
boThresholdDlDch
boAverageTimeDlDch
boTimeToTriggerDlDch boPendingTriggerTimeDlDch
UL DCH1 RB UL DCH2 RB
Internal RNC Event (IN->CN)


6.5 RB UL downsize
UL Th1 UL Th2
isUlRbRateAdaptationAllowedForThisUlRbSetConf isThisRbRateAdaptationUlRbSetTargetAllowed
RLC-SDU Average UL Throughput

UL384
ulRbRateAdaptationDownsizeThreshold
no downsize
UL128
TDOWNDL384
downsize to UL128
UL64
TDOWNDL128
UL32 downsize to UL64
TDOWNDL64
downsize to UL32 time


6.6 RB DL downsize
UL Th1 UL Th2
isDlRbRateAdaptationAllowedForThisDlRbSetConf isThisRbRateAdaptationDlRbSetTargetAllowed
RLC-SDU Average DL Throughput

DL384
dlRbRateAdaptationDownsizeThreshold
no downsize
DL256
TDOWNDL384
downsize to DL256
DL128
TDOWNDL256
downsize to DL128
DL64
TDOWNDL128
DL32 downsize to DL64
TDOWNDL64
downsize to DL32
time


6.7 RB UL upsize
UL Th1 UL Th2
isThisRbRateAdaptationUlRbSetTargetAllowed isUlRbRateAdaptationAllowedForThisUlRbSetConf
RLC-SDU Average UL Throughput

UL384
ulRbRateAdaptationUpsizeThreshold
no upsize
UL128
upsize of UL128
TUPUL128
UL64
upsize of UL64 TUPUL64
UL32
time


6.8 RB DL upsize – Step by step
dlRbRateAdaptationUpsizeAlgorithm = stepByStepUpsize
DL Th1 DL Th2
isThisRbRateAdaptationDlRbSetTargetAllowed isDlRbRateAdaptationAllowedForThisDlRbSetConf
RLC-SDU Average DL Throughput

UL384
dlRbRateAdaptationUpsizeThreshold
no upsize
UL128
upsize of UL128
TUPUL128
UL64
UL32
time


6.9 RB DL upsize – multi stage
dlRbRateAdaptationUpsizeAlgorithm = multiStageUpsize
DL Th1 DL Th2
isThisRbRateAdaptationDlRbSetTargetAllowed isDlRbRateAdaptationAllowedForThisDlRbSetConf
RLC-SDU Average DL Throughput RLC-

RLC-SDU Buffer Occupancy
UL384
%
no upsize
raSduQueueThreshold
bytes
UL128 raSduQueueThresholdBytes QUP384

upsize of UL128 UL128 QUP256
TUP
QUP128
UL64
upsize of UL64 QUP64
TUPUL64
UL32 QUP32
time


6.10 Estimate the impact of an RB RA parameter change
For each of the RB Rate Adaptation parameter changes below, find which
RB Rate Adaptation parameter change impact
raUnitPeriodTime
raMaxConfidenceInt
true
isThisRbRateAdaptationDlRbSetTargetAllowed
false
true
isUlRbRateAdaptationAllowedForThisUlRbSetConf
false
boThresholdDlDch
raSduQueueThreshold
ul4ATimeToTrigger


1.delay DL RB RA Downsize
2.speed-up DL RB RA Downsize
3.delay UL RB RA Downsize
4.speed-up UL RB RA Downsize
5.delay DL RB RA Upsize Step by Step
6.speed-up DL RB RA Upsize Step by Step
7.delay DL RB RA Upsize Multi-Stage
8.speed-up DL RB RA Upsize Multi-Stage
9.delay UL RB RA Upsize
10.speed-up UL RB RA Upsize
11.enable RB RA DL from a given Radio Bearer
12.disable RB RA DL from a given Radio Bearer
13.enable RB RA UL from a given Radio Bearer
14.disable RB RA UL from a given Radio Bearer
15.enable RB RA DL to a given Radio Bearer
16.disable RB RA DL to a given Radio Bearer
17.enable RB RA UL to a given Radio Bearer
18.disable RB RA UL to a given Radio Bearer
Duration = 10 min

For each of the RB Rate Adaptation behavior changes below, find which of
the QoS indicators proposed should be impacted and in which way or
or or depends.
RB Rate Adaptation behavior
delay speed-up
DL RB RA Downsize UL RB RA Upsize
QoS indicator
RB Blocking Rate
DL BLER PS
UL BLER PS
Average DL Cell Throughput PS
Average UL Cell Throughput PS
Number of RB
ReconfigurationAttempts


 DL BLER PS = Average DL BLER for R99 PS calls
 UL BLER PS = Average UL BLER for R99 PS calls
 Average DL Cell Throughput PS = Average DL throughput for R99 PS calls
 Average UL Cell Throughput PS = Average UL throughput for R99 PS calls
 Number of RB Reconfiguration Attempts = Number of RB reconfigurations attempted by UTRAN with UE
Duration = 10 min

7 Tune iRM scheduling algorithm


7.1 iRM scheduling objective
Downgrade Upgrade
Node B Node B
DL 384 kbps DL 384 kbps

No coverage for PS 384 kbps
No service continuity
DL 64 kbps
Service continuity for PS 64 kbps

The iRM Scheduling feature allows one to ensure the PS service continuity for all PS services while trying to offer the
highest supported bit rate as much as possible. This is done through 2 complementary procedures:
 Thedowngrade ensures the service continuity by reducing the user throughput when the radio conditions are
bad, towards a configurable fallback bit rate which is served on the whole network.
 Theupgrade increases the user throughput (after being first downgraded) when he retrieves good radio
conditions.

7.2 iRM scheduling overview
Adapted RB or iRM RB or highBitRate
SRNC DRNC
Downgrade
Nominal RB
SRNC
Adapted RB or iRM RB
flipFlopUpDowngradeTimer
or Intermediate RB
intermediateRate
DRNC
Fallback RB Upgrade
NodeB
irmSchedDowngradeTxcpMaxBitRate
DL 384 kbit/s
DL 128 kbit/s
DL 64 kbit/s


7.3 iRM scheduling downgrade
Nominal RB
Event A Downgrade
384
downgrade Transmitted Code Power 64

Fallback RB Event A
Report
pcpichPower + maxDlTxPowerPerOls
- threshold_delta
Primary Cell
Event A
Threshold
DlIrmSchedDowngradeTx
timeToTrigger timeToTrigger


7.3 iRM scheduling downgrade
7.3.1 Primary cell in DRNC
384 Downgrade
Transmitted Code Power 64

Event A
Report
Primary Cell
Event A
thresholdTransCodePowerDefinitionParam
Threshold
LowRbA
timeToTrigger timeToTrigger


7.4 iRM scheduling upgrade to nominal RB
iRM
Upgrade
64 384 128
Transmitted Code Power Event B1 Event B2
Report Report
Primary Cell
- highB1ThresholdDelta
Event B2
128 Threshold
+ mediumB2ThresholdDeltaOverHighB1
Event B1
384 Threshold
DlIrmSchedUpgrade
highB1TimeToTrigger Event B1 Timer
highB1TimeToTrigger
+ mediumB2TimeToTriggerOverHighB1 Event B2 Timer


7.4 iRM scheduling upgrade to nominal RB
Upgrade
64 384 128
Transmitted Code Power Event B1 Event B2
Report Report
Primary Cell
Event B2
128 Threshold
+ deltaThresholdTransCodePower
Event B1
thresholdTransCodePower 384 Threshold
MediumRbB2 HighRbB1
timeToTrigger Event B1 Timer
timeToTrigger + deltaTimeToTrigger Event B2 Timer


7.5 iRM scheduling upgrade to intermediate RB
Upgrade
64 128
Transmitted Code Power Event B2
Report
Primary Cell
- highB1ThresholdDelta
Event B2
128 Threshold
+ mediumB2ThresholdDeltaOverHighB1
Event B1
384 Threshold
highB1TimeToTrigger
+ mediumB2TimeToTriggerOverHighB1 Event B2 Timer


7.5 iRM scheduling upgrade to Intermediate RB
Upgrade
64 128
Transmitted Code Power Event B2
Report
Primary Cell
Event B2
128 Threshold
+ deltaThresholdTransCodePower
Event B1
thresholdTransCodePower 384 Threshold
timeToTrigger + deltaTimeToTrigger Event B2 Timer


7.6 Which key parameters to tune?
For each of the iRM Scheduling parameter changes below and next page,
find which of the impacts proposed should be observed.
threshold_delta
timeToTrigger (LowRbA)
highB1TimeToTrigger
mediumB2TimeToTriggerOverHighB1
mediumB2ThresholdDeltaOverHighB1
intermediateRate


1.delay iRM Scheduling Downgrade when Primary cell is under SRNC
2.speed-up iRM Scheduling Downgrade when Primary cell is under SRNC
3.delay iRM Scheduling Upgrade to Nominal RB when Primary cell is under SRNC
4.speed-up iRM Scheduling Upgrade to Nominal RB when Primary cell is under SRNC
5.delay iRM Scheduling Upgrade to Intermediate RB when Primary cell is under SRNC
6.speed-up iRM Scheduling Upgrade to Intermediate RB when Primary cell is under SRNC
7.delay iRM Scheduling Downgrade when Primary cell is under DRNC
8.speed-up iRM Scheduling Downgrade when Primary cell is under DRNC
9.delay iRM Scheduling Upgrade to Nominal RB when Primary cell is under DRNC
10.speed-up iRM Scheduling Upgrade to Nominal RB when Primary cell is under DRNC
11.delay iRM Scheduling Upgrade to Intermediate RB when Primary cell is under DRNC
12.speed-up iRM Scheduling Upgrade to Intermediate RB when Primary cell is under DRNC
Duration = 10 min

7.7 Which QoS indicators to monitor?
For each of the iRM Scheduling behavior changes below, find which of the
QoS indicators proposed should be impacted and in which way or
or
QoS indicator Ratio of iRM S.

iRM Sched. iRM Sched. Upgrade
PS CDR DL BLER UL BLER
Downgrade per call Upgrade per call Intermediate vs
PS PS
iRM Scheduling behavior Nominal
delay iRM Scheduling Downgrade
speed-up iRM Scheduling Upgrade

to Nominal RB
delay iRM Scheduling Upgrade

to Intermediate RB


 PS CDR = PS Call Drop Rate
 DL BLER PS = Average DL BLER for R99 PS calls only
 UL BLER PS = Average UL BLER for R99 PS calls only
 iRM Sched. Downgrade per call = Average number of iRM Scheduling Downgrade procedures triggered per
established PS call (PS RAB)
 iRM Sched. Upgrade per call =
Average number of iRM Scheduling Upgrade procedures (Intermediate or Nominal)
triggered per established PS call (PS RAB)
 Ratio between the number of iRM Scheduling Upgrades to
Ratio of iRM S. Upgrade Intermediate vs Nominal =
Intermediate RB rate and the number of iRM Scheduling Upgrades to Nominal RB rate
Duration = 10 min

8 Examples of radio resource
management tuning


8 Examples of radio resource management tuning
8.1 totalRoTMax to increase UL Mac-d HSUPA cell throughput
# UEs = 2 # UEs = 3
# UEs = 1
totalRoTMax = 8
totalRoTMax = 6
totalRoTMax = 7
totalRoTMax = 8
totalRoTMax = 7
totalRoTMax = 6
totalRoTMax = 7
totalRoTMax = 8
totalRoTMax = 6
totalRotMax = 8 is better in multi-user environment

8 Examples of radio resource management tuning
8.2 timerT1 to decrease RB blocking rate
RB Blocking%
3,00%
2,50%
Temporary solution
for a network of
2,00% low capacity cells
1,50%
RB…
1,00%
T1 = 10s T1 = 5s T1 = 1.5s
0,50%
0,00% timerT1


8.2 TimerT1 to decrease RB blocking rate
8.2.1 RB success rate
10s 5s 1.5s


8.2.2 RadioLinkEstablishedPerCell for PS384
RadioLinksEstablishedPerCellCumulativePS384
80000000
70000000
60000000
50000000
RadioLinksEstablishedPerCellCumulati
40000000 vePS384
30000000
10s 5s 1.5s
20000000
10000000
0
6
7
00
00
00
00
00
00
00
00
00
00
00
/2
/2
/2
/2
/2
/2
2
2
1/
3/
5/
7/
9/
4
11
13
/2
/2
/2
/3
1/
1/
1/
1/
1/
1/
1/
12
12
12
12


8.2.3 RadioLinkEstablishedPerCell for PS128 & PS64
12000000 1000000
900000
10000000
800000
700000
8000000
600000
vePS128
6000000 500000
vePS64
400000
4000000
300000
200000
2000000
10s 5s 1.5s
100000
0 0
6
7
00
00
00
00
00
00
00
00
00
00
00
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
2
1
/1
/1
/1
/1
/0
/0
/0
/0
/0
/0
/0
24
26
28
30
01
03
05
07
09
11
13


31
/1
100
200
300
400
500
600
2 · 6 · 77
01 2/2
/0 00
02 1/2 6
/0 00
03 1/2 7
/0 00
04 1/2 7
/0 00

05 1/2 7
/0 00
06 1/2 7
/0 00
07 1/2 7
/0 00
08 1/2 7
/0 00
T1=10s
09 1/2 7
/0 00
10 1/2 7
/0 00
11 1/2 7

/0 00
12 1/2 7
/0 00
13 1/2 7
/0 00
14 1/2 7
8.2.4 kbytes before drop
/0 00
15 1/2 7
/0 00
16 1/2 7
/0 00
17 1/2 7
/0 00
18 1/2 7
/0 00
19 1/2 7
/0 00
20 1/2 7
/0 00
21 1/2 7
/0 00
22 1/2 7
T1=1.5s on 1 RNC
/0 00
kByte Before Drop
23 1/2 7

/0 00
24 1/2 7
COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED. /0 00
25 1/2 7
/0 00
26 1/2 7

/0 00

27 1/2 7
/0 00
28 1/2 7
/0 00
29 1/2 7
/0 00
30 1/2 7
/0 00
31 1/2 7
/0 00
01 1/2 7
/0 00
02 2/2 7
/0 00
03 2/2 7
/0 00
T1=1.5s on all RNCs
2/ 7
20
07
8.2.5 Number of AON downsize and upsize step1
2.5
Dow nsizing to each PS384 call

1.5
Upsizing to each PS384 call
0.5
10s 5s 1.5s
0
6
7
00
00
00
00
00
00
00
00
00
00
00
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
2
1
/1
/1
/1
/1
/0
/0
/0
/0
/0
/0
/0
24
26
28
30
01
03
05
07
09
11
13


Tune radio resource management
Summary
Radio Resource Management TUNING is key for:
 optimizing the usage of UE and UTRAN radio resources

 reaching the best trade-off between:
 capacity:
o highest cell erlang for CS calls, cell throughput for PS calls
o lowest blocking rate
 Quality:
o lowest CS and PS call drop rates
o minimum throughput per UE


End of module
Tune Radio Resource Management


Section 2
Module 7
Optimal Settings for HSPA
UTRAN

Blank page

Tuning key UTRAN algorithms · Optimal Settings for HSPA
Document History

Module objectives
 Describe the key parameters used to enhance HSDPA performance

 Describe the E-DCH key parameters to be tuned to get the nominal
performance
 Explain the E2E communication aspects impacting the HSPA optimal throughput




Table of contents
1 Optimal throughput for HSDPA 7

1.1 Rationale 8
1.2 HSDPA reference throughput figures 9
1.3 How to perform the initial throughput test 10
1.4 Key E2E parameters to optimize HSDPA throughput 11
1.4.1 Definitions 13
1.4.2 Configuration rule 14
1.4.3 TCP/RLC setting 16
1.4.4 FTP server recommendations 17
1.4.5 Minimum UL RAB requirement 18
1.4.6 CN bandwidth requirements 19
2 Optimal throughput for HSUPA 23
2.1 Rationale 24
2.2 E-DCH reference throughput figures 25
2.3 Key E2E parameters to optimize HSUPA throughput 26
2.3.1 Max UL SIR target 27
2.3.2 Diversity gain 29




1 Optimal throughput for HSDPA


1.1 Rationale
Problems limiting the maximum throughput can be located not only on the
Radio interface but anywhere on the E2E communication path
Multi-skill, multi-domain and multi-vendor teams are necessary for End-to-End (E2E)
throughput troubleshooting.
UTRAN
Core


1.2 HSDPA reference throughput figures
Theoretical maximum HSDPA throughput figures per HSDPA UE Category, at

MAC-hs / MAC-ehs level:
The application layer date rate is approximately 85% of the PHY layer
throughput
These throughput figures are 3GPP theoretical maximum values

(ideal radio conditions).

The throughput figures shown here are 3GPP theoretical maximum values (ideal radio conditions). The typical
throughput levels measured in lab or live environment are often substantially lower, due to non-ideal
radio conditions.

1.3 How to perform the initial throughput test
Do simple FTP download and upload (between an FTP Server and the UE)
with either of the following methods:
 “Filezilla” FTP client
 FTP client embedded in the UE trace logging tool
 DOS command lines
 Measure the throughput using a monitoring tool

Before saying that throughput is under expectations and going through investigation, it is required to perform again
the initial throughput test:
 with a different UE (e.g. different model and/or different vendor)
 witha different method (e.g. DOS command lines instead of FTP client) by running multiple FTP sessions in
parallel.

1.4 Key E2E parameters to optimize HSDPA throughput
Default UTRAN configuration required

HSDPA UE Category
Cat9 Cat10 Cat14 Cat24
UTRAN Release ≥UA6 ≥UA6 ≥UA7.0 ≥UA7.1.2
15 15
15 15 * 2
HS-DSCH codes Fair Sharing Fair Sharing
Fair Sharing recommended Fair Sharing recommended
recommended recommended
64QAM
64QAM
L2 improvements, 64QAM, Dual
HSDPA Modulation 16QAM 16QAM L2 improvements
Cell for HSDPA operation are
and 64QAM are required
required
Avoid PA power saturation: PA power saturation leads to a unstable CQI at 30 impacting the
throughput.
A "backoff power" of -2 dB is yet implemented to avoid this issue by reducing the allocated
HSDPA power
power. maxHspaPowerOffset can also be changed to reduce the available power
(PmaxHsdpa = Phsdpa = Pcell - maxHspaPowerOffset), but it is not likely to be needed, thanks
to implemented “backoff power”.
CEM board requirement xCEM/eCEM xCEM/eCEM xCEM/eCEM xCEM/eCEM
Iub on IP Iub on IP
IUB Requirement 6 E1 8 E1
Iub Flow Control Iub Flow Control
At least 100 Mbps. If CN bandwidth is very limited, a DL shaping mechanism is necessary to
IU Requirement
prevent data losses when DL bursts occurs.

Maximum number of HS-PDSCH codes (15): Fair Sharing enabled (Dyn codes mgt part):
 BTSEquipment /hsdpaCodeTreeManagementActivation = True
 FDDCell / isHsxpaR99ResourcesSharingOnCellAllowed = True
1 SF16 used for ccc including multiple S-CCPCH, HS-SCCH and DL HSUPA codes (for ex: 1 S-CCPCH + 2 HS-SCCH +
1 E-AGCH + 1 E-HICH/E-RGCH)
Hybrid Iub or Native IP Iub (xCcm on NodeB and GIGe on RNC needed): In order to achieve high throughput, ATM
BW (8 E1s) is not sufficient and Hybrid Iub is recommended.
 Correct Hybrid Iub setting:
 RadioAccessService/ HsdpaRncConf /minimumHsdschCreditPerTtiInBytes = 1456
 RadioAccessService/ HsdpaRncConf / maxIubHsDschFrameSize = 1472
 Correct ATM setting:
 RadioAccessService/ HsdpaRncConf /minimumHsdschCreditPerTtiInBytes = 2296
 RadioAccessService/ HsdpaRncConf / maxIubHsDschFrameSize = 1520
 Maximum value for txQueueLimit of Access Node according to the ATM card

1.4 Key E2E parameters to optimize HSDPA throughput [cont.]

HSDPA+ Dual Cell
Hybrid Iub or Native IP Iub Hybrid Iub or Native IP Iub
Hardware / Transport xCcm on NodeB with either FE MDA or GE xCcm/eCEM on NodeB, with GE MDA
MDA. GIGe on RNC GIGe on RNC
RNC Packet server: DCPS or PSFP RNC Packet server: DCPS
DCPS (Dual Core Packet Server) allows one to
Hardware / RNC boards
support higher throughput than PSFP in the
RNC but nevertheless PSFP is enough
"L2 improvements: flexible RLC & MAC-ehs" "L2 improvements: flexible RLC & MAC-ehs"
enabled enabled
Features
"64QAM" enabled "64QAM" enabled
"Dual Cell for HSDPA operation" enabled
Settings UTRAN Licensing feature configured to allow max throughput
Settings Correct Iub congestion management setting Correct Iub congestion management setting
No Maximum Bit Rate (MBR) limitation No Maximum Bit Rate (MBR) limitation
IU Requirement
RLC Windows size 2047 2047

Correct Iub congestion management setting:

If not correctly set, the throughput can fluctuate very strongly and we couldn’t get more than 2 or 3 Mbps max
(some time less than 1M)
RNC/ RNCEquipment / INode / EM / RncIn / Cm / activation =discardAndBackPressure
RNC/ RNCEquipment / INode / EM / RncIn / Cm / bwPoolCellColor =enabled
RNC/ RNCEquipment / INode / EM / RncIn / Cm /bwPoolQosBackPressureThreshold andbwPoolQosDiscardThreshold
No Maximum Bit Rate (MBR) limitation:

Ranap MBR higher than the max throughput and Iu Source Conformance disabled (If Source Conformance is On,
the RNC will limit the HSDPA throughput to min(MBR;maximumTokenGenerationRate))

1.4.1 Definitions
Match each parameter with the correct definition:
Definition
1. TCP Receive Window (Rwin) a) Defines the size of the buffers in the RNC. It
configures the number of incoming SDUs
that RLC can hold in order to wait for
transmission
b) Determines how much data can be

2. Bandwidth-Delay Product (BDP) transferred by the server before ACKs of TCP
segments are received
c) It refers to data link capacity  end-to-end
delay
3. dlRlcQueueSizeForUeCa


1.4.2 Configuration rule
Parameter Entity Configuration rule

TCP RWIN PC RWIN ≥ BDP
UL RAB UTRAN UL RAB ≥ UL TCP ACK Bandwidth
Socket Buffer Size FTP Server Socket Buffer Size ≥ BDP
dlRlcQueueSizeForUeCa RNC RWIN≤ dlRlcQueueSizeForUeCa
HSDPA RLC Timer status RNC PST ≤ (RLC_Twin/MAX_RLC_Thr)-
prohibit (PST) RTT_RLC

The parameter dlRlcQueueSizeForUeCa in DlRbSetConf provides the size of the buffers in the RNC. It configures the
number of incoming SDUs that RLC can hold in order to wait for transmission.
The size of this buffer may influence the application performances: when the buffer is already full, and the RNC still
receives data, these SDUs are deleted.
From UA07, the dlRlcQueueSizeForUeCa defined in RbSetConf/PS_HSDSCH_IB, RbSetConf/PS_HSDSCH_IB_MUX,
RbSetConf/PS_HSDSCH_IB_MUX3,
RbSetConf/PS_HSDSCH_STR are unused.
The parameter dlRlcQueueSizeForUeCaForUeCat in RNC/Radio Access Service/HsdpaRncConf is used instead.
To prevent dlRlcQueueSizeForUeCa queue overflow, RWIN shall be ≤ dlRlcQueueSizeForUeCa value.
prohibitedStatusTimer: Minimum time in ms between STATUS reports.

1.4.2 Configuration rule [cont.]
Example: RWIN 128 480 B
dlRlcQueueSizeForUeCat ≤ Rwin dlRlcQueueSizeForUeCat = Rwin
The throughput is not stable during transfer when RWIN > dlRlcQueueSizeForUeCat.
RLC SDUs lost at RNC and congestion avoidance mechanism started by the FTP server.


1.4.3 TCP/RLC setting
The following requirements are needed to reach the maximum FTP

throughput.
UE Cat.9/10 UE Cat.14 UE Cat. 24

RWIN (TCP window) 146 kB 350 kB 700.8 kB
DlRlcQueueSizeForUeCat 256 RLC SDUs 512 512
prohibitedStatusTimer 30 ms 30 ms 10 ms

TCP/RLC setting:
 RWIN (TCP window) = 146 kB for UE Cat.9/10 or 350 kB for UE Cat.14 or 700.8 kB for UE Cat. 24
 DlRlcQueueSizeForUeCat = 256 RLC SDUs for Cat.9/10 or 512 for Cat.14 and Cat. 24
 prohibitedStatusTimer = 30 ms (reduced to 10 ms for Flexible RLC)
From UA07, the parameter DlRlcQueueSizeForUeCat in RNC/Radio Access Service/HsdpaRncConf is used instead of
the DlRlcQueueSize defined in RbSetConf/PS_HSDSCH_IB,RbSetConf/PS_HSDSCH_IB_MUX,
RbSetConf/PS_HSDSCH_IB_MUX3, RbSetConf/PS_HSDSCH_STR
prohibitedStatusTimer:
 For Cat6, Cat8, Cat10 and generally speaking the UEs using Fixed RLC PDU size:
 DlRlcAckMode/prohibitedStatusTimer to 30 ms.
 For Cat13 to Cat24 using Flexible RLC PDU size:
 DlRlcAckFlexibleMode/prohibitedStatusTimer to 10 ms
 Therotically, all categories of UE are able to operate with Flexible RLC PDUs, provided that they run with
Release 7 or above software. In practice, in the field, the UEs operating with Flexible RLC PDUs are the
high-rate capable UEs (e.g. Cat14 and Cat24).

1.4.4 FTP server recommendations
Socket Buffer Size > RWIN

&
Internal Buffer Size < Socket buffer Size
&
Internal Buffer Size X * MTU
 Socket Buffer Size = 200,000 Bytes (Server configuration) at minimum or

730,000 Bytes for Cat. 24
 Internal Buffer Size = 33 580 (23*MTU)

 TCP Transmit Buffer Size = 500000 bytes
 Congestion Window Size = 500000 bytes

If the FTP server has a limited configuration and could not be changed, high throughput could be achieved by
establishing 2 (or more) FTP sessions in parallel.

1.4.5 Minimum UL RAB requirement
TCP ACK is used to ACK 2 DL TCP segments:

 in steady state, 40 bytes (20 B IP Header + 20 B TCP Header ) is required to
acknowledge 2 * 1420 TCP payload bytes.
Example:
 To reach FTP DL throughput of 6 Mbps, in theory 84.5 kbps (6 000 /(1.42*8))/2
*40*8 bps) is required.
 The tests performed show UL 128 RAB limits the DL Throughput when reaching
~ 5.4 Mbps
 UL throughput high enough to acknowledge the high DL

throughput
 HSUPA with 10-ms TTI (2-ms TTI is not mandatory)
 HSUPA with 10-ms TTI (2-ms TTI is not mandatory)

or UL 384 (if RAB adaptation is disabled) with
minSirTargetHsdpa = 4.7 dB


1.4.6 CN bandwidth requirements
GGSN must be able and configured to support high throughput

Ensure HW and configuration (shaping, etc.) allow a 20 Mbps traffic
SGSN Capability:
Ensure HW and configuration allow a 20 Mbps traffic Shaping /
Policing
Direct tunnel configuration recommended  User Plane is

going from RNC to GGSN (no processing in the SGSN, only
switching)


1.4.6 CN bandwidth requirements [cont.]
DL FTP throughput is not smooth & core dimensioning shall consider high
DL traffic peak generated.
 In steady state, the TCP layer adapts DL traffic thanks to UL TCP ACK flow. When 1 UL
TCP ACK is received, TCP anticipation windows shift of 2*MSS bytes (1420 B) and a
constant data volume in transit in the network is maintained.
 When UL TCP ACK flow stops, FTP stops sending DL data.
 UL TCP ACK bursts generate DL TCP segments burts at FTP server ethernet link speed –
usually 100 Mbps.


The UL Reordering function of W-CDMA protocols generates UL TCP ACK bursts.

 Reordering occurs in UL at RLC layer for R99, HSDPA & at MAC-eHS layer for HSxPA.
The UL Reordering and UL interruption time is correlated with retransmission time.
 DL data peak volume is RLC or MAC-E retransmission time dependent

 Burst frequency is tied to UL RLC (R99& HSDPA) or MAC-E (HSxPA)- BLER
measured.

For HSxPA, when a MAC-e PDU is lost, 40 ms are necessary to retransmit the lost PDU. And the interruption time
observed at the GI interface is around 50 ms.
For HSDPA with UL R99, RLC RTT is dependent on UL TTI -20 ms or 10 ms UL 64/128 or 384 – and of RLC layer
configuration-TSP -.
Around 100-ms average interuption time shall be considered for a single RLC PDU loss. 100-ms interruption time can
generate up to 75 kB DL bursts sent at 100 Mbps.

Check:
 RANAP Maximum Bit Rate: it must be higher than the expected max throughput
 Iu Source conformance: if Source Conformance is On, the RNC will limit the
HSDPA throughput to min(MBR;maximumTokenGenerationRate)
 or whatever CN feature could intentionally limit the DL throughput.
How to check and modify the SGSN configuration?

Rely on SGSN expert...
Workaround in case of suspicious SGSN:
ask SGSN expert to configure direct tunnel between RNC and GGSN
The DL shaping mechanism is necessary for networks with CN

bandwidth very limited to prevent data losses when DL bursts occur.


2 Optimal throughput for HSUPA


2.1 Rationale
The root cause for E-DCH performance issues may be located in various
places in the network: Core, Transport, UTRAN, UE, laptop.
And the troubleshooting can be complex.
Multi-skill, multi-domain and multi-vendor teams are necessary for End-to-End (E2E)
throughput troubleshooting.
UTRAN
Core


2.2 E-DCH reference throughput figures
Theoretical maximum E-DCH throughput figures per HSUPA UE Category,

at MAC-e level (as per 3GPP TS 25.306):
HSUPA 16-QAM modulation is not yet supported in ALU UTRAN current

releases (regarding the UE Category 7)
The application layer date rate is approximately 85% of the PHY layer
throughput

The throughput figures shown here are 3GPP theoretical maximum values (ideal radio conditions). The typical
throughput levels measured in lab or live environment are often substantially lower, due to non-ideal radio
conditions.

2.3 Key E2E parameters to optimize HSUPA throughput

No E-DCH Code limitation See previous slide
No power divergence For iBTS, in case E-DCH is activated on
R’99+HSPA shared carrier, it is recommended
to set totalRotMax to 6 dB in order to avoid
potential impact of high UL radio load on UL
R’99 calls QoS.
In case E-DCH is activated on HSPA dedicated
carrier, it is recommended to set totalRotMax
to 8 dB in order to allow higher maximum E-
DCH cell throughput.
Diversity gain Ensure that both “Main” and “Diversity” Node B

antennas are properly configured
Nb E1 required 1 for Ue Cat3- -2 for Cat4/Cat5– 3 for Cat6
The UE trace may degrade the performance


2.3.1 Max UL SIR target
For EDCH, the UL load is the critical resource to manage. It is controlled

through the following UTRAN system parameters:
 Total UL load allowed (totalRotMax)
 SIR target
 E-DPDCH/UL DPCCH power ratio (ed/ c)
The fine tuning of these parameters is a trade-off between stability and

performance.
Power
maxSirTarget
Signal Ec
minSirTarget
Orthogonal signal
Io
Interference


2.3.1 Max UL SIR target [cont.]
Performance: Stability:
by increasing maxSirTarget, a UE is the more the UE uses power, the
allowed to use more power for UL more it adds noise: UL RSSI
DPCCH. increases. Because the UL RSSI
Consequently EDPDCH, which increases, all the other UEs will
power is shifted as well with increase a little bit their power to
respect to the E-DPDCH/UL DPCCH adjust to this new level. The
Power ratio (ed/ c), gets better system converges to a new stable
chance to be decoded without BLER. point. There is a point when the
system becomes unstable. This is
the power divergence issue.


2.3.2 Diversity gain
Ensure that both “Main” and “Diversity” Node B antennas are properly
configured
rxCabling parameter under BTSEquipment > AntennaAccess should be set

to “mainAndDiversityInput” (for all concerned Node Bs and cells)
Both Main and Div antennas should be physically cabled (hardware check at
the base station)
Check for potential imbalance between the UL RTWP level received on the
“Main” and “Diversity” Node B antennas (UL RTWP at Main and Div should be
at a similar level to ensure good E-DCH operation):

Check the current UL RTWP levels at the OAM (only if OAM access is available):
Under WMS, open the Equipment Monitor window for the concerned BTSEquipment object(s) > Dynamic Data
menu > getRadioPowerInfo section >
for each concerned cell, check the values of rtwpMain, rtwpDiv and rtwpCombined metrics.
Observe the UL RTWP level variation through Monitoring (extended PM indicators):

 UULOAD009_CR_MainVsDiv: Difference between minimum RTWP on main and diversity branches
[10*LOG(VS_RadioWBandRxMainPwr_Min)-10*LOG(VS_RadioWBandRxDivPwr_Min)]
 UULOAD009_CR_StabilityMain: RTWP stability for the main branch
[-120 + 10*LOG(VS_RadioWBandRxMainPwr_Min)]
 UULOAD009_CR_StabilityDiv: RTWP stability for the diversity branch
[-120 + 10*LOG(VS_RadioWBandRxDivPwr_Min)]

End of module
Optimal Settings for HSPA


Section 3
Abbreviations and Acronyms
Module 1
UTRAN

Blank page

Abbreviations and Acronyms · Abbreviations and Acronyms
Document History

Abbreviations and acronyms
# FDD Frequency Division Duplex
2G Second Generation FDMA Frequency Division Multiple Access
3G Switch to notes view!
Third Generation FE Fast Ethernet
3GPP Third Generation Project Partnership FTP File Transfer Protocol
A G
ALCAP Access Link Control Application Protocol GE Gigabit Ethernet
AM Acknowledged Mode GGSN Gateway GPRS Support Node
AMR Adaptive Multi-Rate GSM Global System for Mobile communications
AS Active Set
ATM Asynchronous Transfer Mode H
HHO Hard Handover
B HO Handover
BB BroadBand HSDPA High-Speed Downlink Packet Access
BCCH Broadcast Control CHannel HS-DSCH High-Speed Downlink Shared Channel
BDP Bandwidth-Delay Product HSPA High-Speed Packet Access
BLER Block Error Ratio HS-PDSCH High-Speed Physical Downlink Shared
BoQ Bill of Quantities Channel
BSC Base Station Controller HS-SCCH High-Speed Shared Control Channel
BSS Base Station Subsystem HSUPA High-Speed Uplink Packet Access
BW BandWidth
I
C iMCTA intelligent MultiCarrier Traffic Allocation
CAC Connection Admission Control IP Internet Protocol
CCCH Common Control Channel Iu Interface between UTRAN and Core
CCO 3 · 1 · 3Cell Change Order Network
CDMAUTRAN · UA08
Code Radio Division
Fine Tuning Multiple Access Iub Interface between RNC and Node B
CDR Call Drop Rate
CEM Channel Element Module K
CI Cell Identity KPI Key Performance Indicator
CM Configuration Management
CN Core Network L
CPICH Common PIlot CHannel L1 Layer 1
CQI Channel Quality Indicator LAC Location Area Code
CS Circuit Switching LTE Long-Term Evolution
CSSR Call Setup Success Rate
M
D MAC Medium Access Control
DCPS Dual Core Packet Server MAC-e enhanced MAC
DHT Diversity Handover Trunk MAC-hs high-speed MAC
DL Downlink MBR Maximum Bit Rate
DPCCH Dedicated Physical Control Channel MCPA Multi-Carrier Power Amplifier
DRNC Drift RNC MDA Media Device Adaptor
DRX Discontinuous Reception MO Mobile Originating
DTCH Dedicated Traffic Channel MOS Mean Opinion Score
MR Measurement Report
E MS Mobile Station
E2E End-to-End MSC Mobile services Switching Center
E-AGCH Enhanced Access Granted Channel MSS Maximum Segment Size
E-DCH Enhanced DCH MT Mobile Terlminating
E-DPDCH Enhanced Dedicated Physical Data MTU Maximum Transfer Unit
Channel
E-HICH Enhanced HARQ Indicator Channel N
E-RGCH Enhanced Relative Grant Channel NB Narrowband
F
FACH Forward Access Channel

Abbreviations and acronyms [cont.]
O Switch to notes view! SGSN Serving GPRS Support Node

OAM Operation, Administration and SHO Soft Handover
Maintenance SIR Signal-to-Interference Ratio
OCNS Orthogonal Channel Noise Simulator SRB Signaling Radio Bearer
O&M Operation and Maintenance SRNC Serving RNC
OMC Operation and Maintenance Center
OMC-R Operation and Maintenance Center-Radio T
TCP Transport Control Protocol
P TDMA Time Division Multiple Access
PA Power Adjustment TMA Tower Mounted Amplifier
PBCCH Packet Broadcast Control Channel TTI Transmission Timing Interval
PCH Paging Channel TX Transmission
P-CPICH Primary-Common Pilot Channel
PDU Packet Data Unit U
PICH Pilot Channel UE User Equipment
PLMN Public Land Mobile Network UL Uplink
PM Performance Configuration UMTS Universal Mobile Telecommunications
PS Packet Switching System
PSI Packet System Information URB User Radio Bearer
UTRA Universal Terrestrial Radio Access
Q UTRAN Universal Terrestrial Radio Access
QAM Quadrature Amplitude Modulation Network
QoS Quality of Service
QPSK Quadrature Phase Shift Keying W
3·1·4 WCDMA
Wideband Code Division Multiple Access
R UTRAN · UA08 Radio Fine Tuning
RA Routing Area
RAB Radio Access Bearer
RAC Radio Admission control
RAN Radio Access Network
RANAP Radio Access Network Application
Protocol
RAT Radio Access Technology
RB Radio Bearer
RCR RRC Connection Re-establishment
RFT Radio Fine Tuning
RL Radio Link
RLC Radio Link Control
RLF Radio Link Failure
RLM Radio Link Management
RNC Radio Network Controller
RNO Radio Network Optimizer
RNP Radio Network Planning
RRC Radio Resource Control
RRM Radio Resource Management
RSCP Received Signal Code Power
RSSI Received Signal Strength Indication
RTT Round Trip Time
RTWP Received Total Wideband Power
RUE RLC Unrecoverable Error
Rx Reception
S
SC Supervised Configuration
S-CCPCH Secondary – Common Control Physical
Channel
SDU Signaling Data Unit

End of module


Last but one page
Congratulations
You have finished the training
Your feedback is appreciated!

Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the training reference in your email (see cover page)
Thank you!
1 All Rights Reserved © Alcatel-Lucent @@YEAR

@@PRODUCT
@@COURSENAME

@@COURSENAME - Page 1
All rights reserved © Alcatel-Lucent
Passing on and copying of this document, use and communication of its contents
not permitted without written authorization from Alcatel-Lucent

@@COURSENAME - Page 2

RFT - TMO18351 - V3 SG UA08 Ed1

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

RFT - TMO18351 - V3 SG UA08 Ed1

Caricato da

Copyright:

Formati disponibili

UTRAN

UA08 Radio Fine Tuning

COPYRIGHT © ALCATEL-LUCENT @@YEAR. ALL RIGHTS RESERVED.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

TERMS OF USE AND LEGAL NOTICE

PERMISSION TO USE CONTENT

COPYRIGHTS AND TRADEMARKS

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

3 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

UA08 Radio Fine

 Explain the objectives

Your feedback is appreciated!

Please include the following training reference in your email:

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Introduction to 3G Radio Fine

All Rights Reserved © Alcatel-Lucent @@YEAR

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

1·1·2 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

This page is left blank intentionally

Edition Date Author Remarks

01 YYYY-MM-DD Last name, first name First edition

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Upon completion of this module, you should be able to:

1·1·3 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

1·1·4 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

This page is left blank intentionally

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Switch to notes view! Page

1 Radio fine tuning in network life cycle 7

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Switch to notes view!

1·1·6 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

This page is left blank intentionally

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

1·1·7 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Network Network Network Pre-launch Network

Radio Fine Tuning

1·1·8 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Network Network Network Pre-launch Network

Radio site installation: Design Planning Deployment Optimization Acceptance

 Drive Test procedure:

1·1·9 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Network Network Network Pre-launch Network

Why is Pre-launch Optimization so important in a 3G network?

1 · 1 · 10 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Network Network Network Pre-launch Network

Cluster optimization Design Planning Deployment Optimization Acceptance

 Remove weak coverage spots

1 · 1 · 11 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

 A cluster is a group of sites located inside a polygon

Optimization phases = 3G + Voice, 3G-2G + others

1 · 1 · 12 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

 Scanner + Mobiles Originating calls:

1 · 1 · 13 COPYRIGHT © ALCATEL-LUCENT 2012. ALL RIGHTS RESERVED.

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Corrective tasks performed