W-cdma Ua07 r99 Algo - Tmo18255d0sgdeni1.0
-
Upload
erlinda-melicado -
Category
Documents
-
view
76 -
download
7
description
Transcript of W-cdma Ua07 r99 Algo - Tmo18255d0sgdeni1.0
TMO18255 UA07 R99 Algorithms Description - Page 1All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMATMO18255 UA07 R99 Algorithms
Description
STUDENT GUIDE
TMO18255 Issue D0 SG DEN I1.0
All rights reserved © Alcatel-Lucent @@YEAR Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
TMO18255 UA07 R99 Algorithms Description - Page 2All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
2
Empty page
Switch to notes view!
This page is left blank intentionally
TMO18255 UA07 R99 Algorithms Description - Page 3All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
3
Terms of Use and Legal Notices
Switch to notes view!1. Safety Warning
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to
wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the
equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (“Marks”) are the property of their respective holders, including Alcatel-
Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucent’s written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
written consent of Alcatel-Lucent.
All rights reserved © Alcatel-Lucent @@YEAR
4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including
lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel-
Lucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an
endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The
information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some
cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely
accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment
and its operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-
Lucent disclaims any warranties in connection with the products as used and described in the courses or the related
documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,
including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of
dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed
internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in
nature
5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are
governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal
Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,
but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a
valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these
Terms of Use and Legal Notices shall remain in full force and effect.
TMO18255 UA07 R99 Algorithms Description - Page 4All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
4
Blank Page
Switch to notes view!
This page is left blank intentionally
TMO18255 UA07 R99 Algorithms Description - Page 5All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
5
Course Outline
About This CourseCourse outline
Technical support
Course objectives
1. Topic/Section is Positioned HereXxx
Xxx
Xxx
2. Topic/Section is Positioned Here
3. Topic/Section is Positioned Here
4. Topic/Section is Positioned Here
5. Topic/Section is Positioned Here
6. Topic/Section is Positioned Here
7. Topic/Section is Positioned Here
Section 1. UTRAN Parameters Objects
Module 1. TMO18255 D0 SG DEN I1.0
Section 2. UTRAN Configuration
Module 1. TMO18255 D0 SG DEN I1.0
Section 3. Services
Module 1. TMO18255 D0 SG DEN I1.0
Section 4. Measurements
Module 1. TMO18255 D0 SG DEN I1.0
Section 5. Call Admission
Module 1. TMO18255 D0 SG DEN I1.0
Section 6. Power Management
Module 1. TMO18255 D0 SG DEN I1.0
Section 7. Call Management
Module 1. TMO18255 D0 SG DEN I1.0
Section 8. Mobility in Reselection
Module 1. TMO18255 D0 SG DEN I1.0
Section 9. Mobility in SHO
Module 1. TMO18255 D0 SG DEN I1.0
Section 10. Inter carrier Mobility in HHO
Module 1. TMO18255 D0 SG DEN I1.0
Section 11. Inter carrier Mobility at RRC connection
Module 1. TMO18255 D0 SG DEN I1.0
Section 12. Glossary
Module 1. TMO18255 D0 SG DEN I1.0
TMO18255 UA07 R99 Algorithms Description - Page 6All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
6
Course Outline [cont.]
Switch to notes view!
This page is left blank intentionally
TMO18255 UA07 R99 Algorithms Description - Page 7All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
7
Course Objectives
Switch to notes view!
Welcome to TMO18255 UA07 R99 Algorithms Description
Upon completion of this course, you should be able to:
� Describe the R99 Radio Algorithms implemented in the ALU UTRAN and the attached
parameters
TMO18255 UA07 R99 Algorithms Description - Page 8All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
8
Course Objectives [cont.]
Switch to notes view!
This page is left blank intentionally
TMO18255 UA07 R99 Algorithms Description - Page 9All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
9
About this Student Guide
� Switch to notes view!Conventions used in this guide
Where you can get further information
If you want further information you can refer to the following:
� Technical Practices for the specific product
� Technical support page on the Alcatel website: http://www.alcatel-lucent.com
Note
Provides you with additional information about the topic being discussed.
Although this information is not required knowledge, you might find it useful
or interesting.
Technical Reference (1) 24.348.98 – Points you to the exact section of Alcatel-Lucent Technical
Practices where you can find more information on the topic being discussed.
WarningAlerts you to instances where non-compliance could result in equipment
damage or personal injury.
TMO18255 UA07 R99 Algorithms Description - Page 10All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
10
About this Student Guide [cont.]
� Switch to notes view!
This page is left blank intentionally
TMO18255 UA07 R99 Algorithms Description - Page 11All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
11
Self-assessment of Objectives
� At the end of each section you will be asked to fill this questionnaire
� Please, return this sheet to the trainer at the end of the training
Switch to notes view!
Instructional objectives Yes (or globally yes)
No (or globally no)
Comments
1 To be able to XXX
2
Contract number :
Course title :
Client (Company, Center) :
Language : Dates from : to :
Number of trainees : Location :
Surname, First name :
Did you meet the following objectives ?
Tick the corresponding box
Please, return this sheet to the trainer at the end of the training
����
TMO18255 UA07 R99 Algorithms Description - Page 12All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 UA07 R99 Algorithms Description9300 WCDMA
12
Self-assessment of Objectives [cont.]
Switch to notes view!
Instructional objectives Yes (or Globally yes)
No (or globally no)
Comments
Thank you for your answers to this questionnaire
Other comments
����
Section 1 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
1�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 1UTRAN Parameters Objects
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 1 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 2
Blank Page
This page is left blank intentionally
number of parameters updated for UA7Chatila, RayanRyser, Sigrid
2010-04-1501
RemarksAuthorDateEdition
Document History
Section 1 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to :
� Describe the organization of UTRAN parameters
� Evaluate the impact of parameter modifications
� Describe the UTRAN Configuration Management process and tools
Section 1 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 1 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 5
Table of Contents
Switch to notes view!Page
1 UTRAN Configuration Overview 71.1 UTRAN Configuration Process & Tools 81.2 Customer Input Questionnaire 91.3 UTRAN CM Solution Overview 101.4 UTRAN CM XML Files Exchange 11
2 Organization of UTRAN Parameters 122.1 UTRAN Objects Mapping 132.2 UTRAN Parameter Domain 142.3 RAN Parameter Types 152.4 RAN Attribute Activation Classes 172.5 RAN Object Activation Classes 182.6 RRM Subtree 192.7 Configuration Classes Instantiation 20
Section 1 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 6
Table of Contents [cont.]
Switch to notes view!
This page is left blank intentionally
Section 1 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 7
1 UTRAN Configuration Overview
Section 1 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 8
1 UTRAN Configuration Overview
1.1 UTRAN Configuration Process & Tools
ProvisioningActivities
PlanningActivities
Main Server
Configuration Data
OA&MActivities
ND
RF
IP
ATM
WPS for Access
This process describes how to configure UTRAN Network Elements (NEs) during a deployment phase. The
main steps are the following:
� Planning Activities:
� Check UTRAN CIQs consistency
� Provide neighboring XML files for cell planning
� Provide last WPS templates and ATM Profile
� Provisioning Activities:
� Generate full configuration with WPS
� Export XML files from WPS
� Operation Administration & Maintenance Activities:
� Load configuration data into their respective NEs
� Build the database (MIB) of the RNS and make sure all the local information are up-to-date.
� Perform real-time adjustments to the initial network configuration.
Note:
These steps do not necessarily apply to other contexts, such as introduction of new features, addition of
new NEs, network optimization, …
Section 1 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 9
1 UTRAN Configuration Overview
1.2 Customer Input Questionnaire
CIQ
• RRM Parameters
• RRM Parameters
• RRM Parameters
• …
Operator
Teams
• Network Requirements
• Deployment Constraints
• ...
• Network System Definition
• Engineering rules
• Addressing rules
• ...
Engineering
Teams(Core, Local)
• IP Para
meter
s
• IP Para
meter
s
• IP Para
meter
s
• ...
• ATM Parameters
• ATM Parameters
• ATM Parameters
• …
•Network Design
•Network Design
•Network Design
•…
• RF Par
amete
rs
• RF Par
amete
rs
• …
The Customer Input Questionnaire is a repository where all parameter values and configuration data
required for the later datafill of the UTRAN subsystem are stored.
As mentioned in the document header: "The CIQ is used by the Wireless Network Engineering team,
Regional Engineering and deployment personnel to better understand the customer requirements”.
Each manager of a Local Engineering team (in relation with the other activity groups) is in charge of filling
his own part of the CIQ along with the operator:
� Radio Frequency (RF) staff fills RF parameters. RF team can also provide XML files coming from any cell
planning tool, such as iPlanner.
� IP engineering staff fills the IP addresses .
� ATM engineering staff fills the ATM parameters…
The UTRAN CIQ template highlights for each parameter to which domain it belongs (Design, IP, ATM…).
At WPS level, the UTRAN datafill engineer is in charge of checking the consistency and completeness of the
UTRAN CIQs.
Section 1 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 10
1 UTRAN Configuration Overview
1.3 UTRAN CM Solution Overview
Provisioning OA&M
Engineering Tools
XML Files
OpenInterface
BTSC-NodeI-Node
RNC
Main ServerWPS Access
NodeB
Wireless Wireless –– Network Management SystemNetwork Management System
OffOff --lineline OnOn--lineline
XM
L
For the UMTS Access Network, Wireless-Network Management System provides two complementary sets of
configuration tools:
� off-line configuration tool to support network engineering
� on-line configuration tool to support network operations
These two toolkits fully inter-work and provide a consistent user environment for engineering and
operations staff.
� Off-line Configuration is designed to support efficient bulk configuration of the UTRAN by engineering
staff. Users can import, modify and export data, both from the UMTS access network and from 3 rd
party engineering tools (such as iPlanner). Off-line Configuration delivers a seamless network-
engineering environment from initial network design through to actual network configuration.
� On-line Configuration has been designed to change the configuration of the UTRAN in real-time. Not
adapted to bulk configuration, the On-line configuration mainly concerns specific operations, such as
extending the network, adding NEs, …
Section 1 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 11
1 UTRAN Configuration Overview
1.4 UTRAN CM XML Files Exchange
Live Network
WPSWPS
Import/Export
S
S
Import/Export
D
D
WPS Import
WPS Export
XML Snapshots
XML WorkordersMain Server
WPSWPS
WNMS Export
WNMS ImportDD
SS
At any time during the network building steps, the datafiller can export part of his work towards other
platforms.
The following CM (Configuration Management) files can be exported:
� Snapshot
� Work order
According to the option selected, the result of the export will be very different:
� Exporting the current state of the network as a snapshot means merging the elementary operations
performed by the work orders with the initial snapshot. As WPS says: “the current planning view is the
result of the execution of work orders on the initial snapshot”.
� Exporting the work order means gathering all the elementary operations performed upon a snapshot
into a CM file for further use (other WPS platforms, W-NMS).
Section 1 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 12
2 Organization of UTRAN Parameters
Section 1 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 13
2 Organization of UTRAN Parameters
2.1 UTRAN Objects Mapping
Hardware Equipment
RNCEquipment
Logical Configuration
NodeB
FDDCell /0
FDDCell /1 BTSCell /1
BTSCell /0
PP15K -IN
RNC
BTSEquipment
CN IN
The RAN model is split into two parts:
� Hardware Equipment: This part groups all elements (parameters) that defines the equipment (BTS) and
the Passport module (Pmod). It is the physical part of that model.
� Software Configuration: This other part groups all elements that defines the Node B and RNC logical
configuration. It is called “logical part” because it defines the software for logical radio sectors and
logical RNC nodes.
To perform a link between the Hardware Equipment (physical part) and the Software Configuration (logical
part), it is necessary to link several elements from both parts. For example to link the logical sectors to
the physical equipment, the user has to attach a BTSCell (physical part) to one FddCell (logical part). This
specific operation is called “Mapping”.
Section 1 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 14
2 Organization of UTRAN Parameters
2.2 UTRAN Parameter Domain
RAN ModelBased
InterfaceNode
Access Node
NodeB
MIBMIB
PassportBased
W-NMS
Control Node
WiPS
MIBMIB
Two different types of parameters are designed to configure a UMTS Access Network:
� Control Node, Node B and RAN parameters
� Interface Node, Access Node and Passport parameters
Changing parameter values may impact the behavior of the live network.
For RAN parameters, the impact triggered by a parameter modification is strongly linked with the
parameter classes (see next slide).
For Passport parameters, it is not always easy to predict the impact of a parameter modification. Possible
consequences are:
� nothing
� reset of an interface
� reset of a module
� reset of a node
Section 1 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 15
2 Organization of UTRAN Parameters
2.3 RAN Parameter Types
RNC
Static
Non-Static
OMC
Customer
Example:
There are two main kinds of parameters in the Alcatel-Lucent system: static and configuration parameters.
The static parameters have the following characteristics:
� They have a fixed value and cannot be modified at the Access OAM.
� They are part of the network element load.
� A new network element needs to be reloaded and built in order to change their values.
� They cannot be modified by the customer.
The configuration parameters have the following characteristics:
� They are contained in the Access OAM database.
Section 1 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 16
2 Organization of UTRAN Parameters
2.3 RAN Parameter Types [cont.]
The customer parameters have been reviewed and tagged with the following rules:
System_restricted:
Parameters which should not be modified in live networks. Proposal also to align the settings for these
parameters on WNE templates at upgrade
Customer_setting:
Parameters which have to be set by customer, either due to design or to activate optional features
Expert_tuning:
Parameters which can be modified by customer, but with a specific support from Alcatel-Lucent, because
of the complexity or sensitivity of this parameter with respect to QoS.
Customer_tuning:
Parameters which can be modified by customer, without specific support from Alcatel-Lucent
This table gives an overview of the number of parameters in UA7:
2662712591Grand Total
2216242192RNC Total
1926819183
97972
193161770RNC
44647399BTS Total
31333103
222
13144870BTS
Grand TotalManufacturerCustomerClassDomain
UserCount of Object
Section 1 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 17
2 Organization of UTRAN Parameters
2.4 RAN Attribute Activation Classes
Activation classes apply toCustomer and Manufacturer parameters
Class 0
Class 3 (A1, A2, B)
Class 2
MIB
MIB build required
(most common case)
lock/unlock required
On-line modification allowed
Class0: Value set at object creation. Parameters require a build to be taken into effect on the NEs – large
impact on system
Class2: parameters require a lock of the object(or its parent object) in order to change the parameter
value- slight impact on system
Class3: the parameter can be changed online without impact on the service. Three sub-classes are derived
from Class 3:
� Class 3-A1: new value is immediately taken into account.
� Class 3-A2: new value is taken into account upon event reception (service establishment, SRLR, LCS,
etc.).
� Class 3-B: new value is taken into account for next calls.
Customer: the parameter is configurable from the OMC and seen by the operator
Manufacturer: the parameter is configurable from the OMC and only seen by Alcatel-Lucent engineering
teams
Example:
3-a2maximumNumberOfUsersHSDPACellClass
3-a1CallAdmissionRatioPowerPartConfClass
ClassMO Attribute NameMO Name
Section 1 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 18
2 Organization of UTRAN Parameters
2.5 RAN Object Activation Classes
Not Allowed
Allowed
Allowed With Lock
Allowed With Parent MIB
MIB build required
lock/unlock required
parent modification required
On-line modification allowed
On-line Creation / Deletion behavior
The object activation class defines the object behavior with respect to the “create online” and “delete
online” operations.
Not Allowed:
The object can not be created/deleted online, a build is required.
Allowed With Parent:
The object can be created/deleted online but the operation requires the creation/deletion of the parent.
Allowed With Lock:
The object can be created/deleted online but the operation requires locking the object or one of its
ancestors in the containment tree.
Allowed:
The object can be created/deleted online.
Section 1 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 19
2 Organization of UTRAN Parameters
2.6 RRM Subtree
ConfigurationClassX
InstanceNInstanceN
Instance...Instance...
Instance2Instance2
Instance1Instance1
ConfigurationClassZ
InstanceNInstanceN
Instance...Instance...
Instance3Instance3
Instance2Instance2
Instance1Instance1
ConfigurationClassY
InstanceN
Instance...
Instance...
Instance3
Instance2
Instance1
ConfigurationClassY
InstanceN
Instance...
Instance...
Instance3
Instance2
Instance1
InstanceNInstanceN
Instance...Instance...
Instance...Instance...
Instance3Instance3
Instance2Instance2
Instance1Instance1
RNC
RadioAccessService
DedicatedConf
Radio Resource Management is an essential piece of the RNC controlling the radio resources allocated to
the users.
The RadioAccessService object is the root of the RRM architecture. It includes a set of parameters that
applies to the whole Radio Network Subsystem.
Some of the parameters of the RRM tree are stored in libraries composed of Configuration Classes and
Configuration Classes Instances.
There are 7 Main Configuration Classes, some of them containing children:
� CacConfClass
� HoConfClass
� MeasurementConfClass
� NodeBConfClass
� PowerConfClass
� PowerPartClass
� PowerCtrlConClass
Each of these Configuration Classes can have a maximum of 5 different instances. Each instance
corresponds then to a predefined set of parameters (see example next page).
Section 1 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 20
2 Organization of UTRAN Parameters
2.7 Configuration Classes Instantiation
FDDCellcacConfId 0
Example
-50.0maxUlInterferenceLevel
384maxUlEstablishmentRbRate
85firstRlOvsfCodeCacThreshold
CacConfClass/ 0
-50.0maxUlInterferenceLevel
64maxUlEstablishmentRbRate
384maxDlEstablishmentRbRate
CacConfClass / 0
RNC
RadioAccessService
DedicatedConf
MeasurementConfClass PowerCtrlConfClass PowerPartConfClass CacConfClassHoConfClassPowerConfClass
FDDCell
Configuration Classes are involved in Node B, FDDCell and NeighbouringRNC configuration.
Once all the configuration classes are defined, each FDDcell belonging to the RNC has pointers defined by
the following parameters:
� powerConfId
� powerPartId
� powerCtrlConfId
� hoConfId
� cacConfId
� measurementConfId
In the example above, we can see that each instance of CacConfClass includes a set of predefined
parameters.
Each parameter belonging to the CacConfClass object can take a different value under each instance.
For example, the maxUlInterferenceLevel can take values from -112 dBm to -50 dBm according to the
selected instance.
Section 1 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 21
Module Summary
� This lesson covered the following topics:
� Organization of UTRAN parameters
� The impact of parameter modifications
� UTRAN Configuration Management process and tools
Section 1 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 22
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 1 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Parameters Objects �
1 � 1 � 23
End of Module
Section 2 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
2�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 2UTRAN Configuration
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 2 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 2
Blank Page
This page is left blank intentionally
Max. number of neighbors updated (UA7)Clarifications on RAN model Objects relating to Neighbouring RelationshipsRemoval of parameters relating to BTS Radio Configuration (localCellGroupId, frequencyGroupId, tCell, cellSize, etc…)
Chatila, RayanRyser, SigridCharneau, Jean-Noel
2010-04-1501
RemarksAuthorDateEdition
Document History
Section 2 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Describe RNC configuration and associated parameters
� Describe Node B configuration and associated parameters
� Describe Neighbooring Cell configuration and associated parameters
Section 2 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 2 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 5
Table of Contents
Switch to notes view!Page
1 RNC Configuration 71.1 Identification & Capacity 8
2 Node B Configuration 92.1 FDDCell Identifiers 102.2 Channel Numbers 112.3 Scrambling Codes 12
3 Neighbouring Cell Configuration 133.1 FDDCell, RemoteFDDCell, GSMCell 143.1.1 Corresponding RAN Model 15
3.2 UMTSFddNeighbouringCell 163.3 GsmNeighbouringCell 173.4 UmtsNeighbouringRelation 183.4.1 Example 19
3.5 SIB11/DCH Neighboring Lists 20
Section 2 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 6
Table of Contents [cont.]
Switch to notes view!
This page is left blank intentionally
Section 2 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 7
1 RNC Configuration
Section 2 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 8
1 RNC Configuration
1.1 Identification & Capacity
RNC NodeB
rncId (RNC)
RNC
rncId (RNC)
NodeB
NodeB
numberOfServicesGroup (RNC)
NodeB
NodeB
NodeB
NodeB
serviceGroupId (NodeB)
serviceGroupId (Iub)
Iub
Iub
Iub
The different RNCs of the network are simply identified by their rncId under the RNC object.
The capacity of the RNC in terms of number of calls, number of supported BTS and cells depends on two
major factors:
� The number of TMUs (hardware configuration)
� The software configuration
The parameter cnodeCapacity is not anymore supported in UA6.
From UA06, the service group to which a given NodeB is allocated can be specified by the operator
(parameter serviceGroupId of NodeB object).
It is also possible to know on which TMU a RNC has set a given service group. Thus with these facilities, it is
now possible to modify the affectation of one NodeB from a given service group to another one (and thus
by consequence from a PMC-TMU to another one). This possibility may be interesting in order to better
balance the load between the PMCTMU if needed. It has to be nevertheless noted that the re-affectation
of one NodeB from a Service Group to another one, implies a loss of service on this NodeB.
The number of service group of a RNC is specified by the parameter numberOfServiceGroups of the RNC object.
The parameter serviceGroupId of Iub object specifies which service group this Iub interface is assigned to. All IubIfs provisioned with the same serviceGroupId will be processed by the same PMC-TMU processor.
The serviceGroupId provisioned on this IubIf must match the serviceGroupId configured on the RNC NodeB
managed object.
Section 2 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 9
2 Node B Configuration
Section 2 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 10
2 Node B Configuration
2.1 FDDCell Identifiers
BTSEquipment
Operator (OAM)
FDDCell BTSCell
Logical Objects(3GPP)
Physical Objects(Alcatel-Lucent)
RNC
NodeB
cellId (FDDCell)
rncId (RNC)
“ucid” (FDDCell)
+
=
localCellId (FDDCell)
The standardization of the Iub interface has pushed Alcatel-Lucent to define an object model based on a
logical part and a physical part in order to cope with the multi-vendor configurations:
� The logical part of the equipment (Node B and RNC) is managed by the OMC-R.
� The physical part of the equipment (BTS) is managed by the OMC-B.
The mapping between the two parts is ensured by the localCellId parameter, coded on 28 bits, found under
the FDDCell and the BTSCell objects. It is advisable to have a unique localCellId on the whole network for
OAM purposes, to prevent problems during neighboring declaration.
In the UTRAN, the different Cells (part of the Node Bs) are identified uniquely by their ucid.
This ucid contains the identifier of the RNC, the rncId, coded on 12 bits, defined under the RNC object and
also the cellId, coded on 16 bits, defined under the FDDCell object.
Section 2 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 11
2 Node B Configuration
2.2 Channel Numbers
ulFrequencyNumber (FDDCell)
Operator (OAM)
dlFrequencyNumber (FDDCell)
FDDCell
9662-99381930-19909262-95381850-19102
10562-108382110-21709612-98881920-19801 and 3
UARFCNDL (MHz)UARFCNUL (MHz)ITU Region
NodeBRNC
The frequency of a carrier is defined:
� in uplink by the ulFrequencyNumber parameter
� in downlink by the dlFrequencyNumber parameter
Both parameters correspond to the UARFCN (UTRA Absolute Radio Frequency Channel Number) where:
UARFCN = 5 * Frequency (MHz).
UTRAN is designed to operate with the following Tx-Rx frequency separation:
� ITU Region 1 & 3; duplex shift = 190 MHz
� ITU Region 2; duplex shift = 80 MHz
However, it is possible to have a channel separation which is different from these standard values, due to
the channel raster.
The channel raster is 200 kHz, which means that the center frequency must be an integer multiple of 200
kHz.
The nominal channel spacing is 5 MHz, but this can be adjusted to optimize performance in a particular
deployment scenario.
Section 2 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 12
2 Node B Configuration
2.3 Scrambling Codes
NodeB
primaryScramblingCode (FDDCell )
aichScramblingCode (RACH)
sccpchDlScramblingCode (SCCPCH)
Scrambling code
Channelization code 1
Channelization code 2
Channelization code 3
User 1 signal
User 2 signal
User 3 signal
UE is surrounded by BTSs (Base Transceiver Station), all of which transmit on the same W-CDMA frequency.
It must be able to discriminate between the different cells of different base stations and listen to only one
set of code channels. Therefore two types of codes are used:
� DL Channelization Code
The user data are spread synchronously with different channelization codes. The orthogonality
properties of OVSF enable the UE to recover each of its bits without being disturbed by other user
channels.
� DL Scrambling Code
Scrambling is used for cell identification.
Scrambling Code parameters
The Primary Scrambling Code (P-SC) of each cell it set with the primaryScramblingCode parameter of the
FDDCell object. The range of the P-SC must be within 0 to 511. On the Iub interface, the system will
convert this value (defined as i) using the following formula: P-SC = 16*i.
When Secondary SC are not in use, the aichScramblingCode and the sccpchDlScramblingCode must be set to
0. The 0 value will be defining the AICH Scrambling Code = the Primary SC and the S-CCPCH Scrambling
Code = the Primary SC.
Section 2 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 13
3 Neighbouring Cell Configuration
Section 2 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 14
3 Neighbouring Cell Configuration
3.1 FDDCell, RemoteFDDCell, GSMCell
GSMCellE
FDDCellA
FDDCellB
FDDCellC
FDDCellD
GSMCellF
RNC1 RNC2
controls controls
BSC
C must C must bebe declareddeclared as as RemoteFDDCellRemoteFDDCell in RNC1in RNC1
E must be declared as GSMCell in RNC1
F must be declared as GSMCell in RNC2
B must B must bebe declareddeclared as as RemoteFDDCellRemoteFDDCell in RNC2in RNC2
Adjacency between cells (also called Neighbouring relation between cells) represents a couple of cells (A,B)
relation where Cell Reselection and/or Soft Handover procedures can be performed from one cell A
called Source cell or Serving cell towards another cell B called Target Cell.
An Adjacency is therefore a directional relation between two cells and should rather be noted (A->B).
Adjacencies managed by an RNC can be of 3 kinds:
� 3G->3G adjacencies where 3G Target cell is controlled by the same RNC as the CRNC of the Serving cell
� 3G->3G adjacencies where 3G Target cell is controlled by another RNC than the CRNC of the Serving cell
� In this case a new RemoteFDDCell object must created in the RNC object tree of the CRNC of the
Serving cell. This RemoteFDDCell object shall represent the Target 3G cell in the Serving cell CRNC.
� 3G->2G adjacencies
� In this case a new GSMCell object must created in the RNC object tree of the CRNC of the Serving cell.
This GSMCell object shall represent the Target 2G cell in the Serving cell CRNC.
Section 2 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 15
3.1 FDDCell, RemoteFDDCell, GSMCell
3.1.1 Corresponding RAN Model
RNC/1
NodeB/x
FDDCell/A FDDCell/B
UmtsNeighbouring/0
RemoteFDDCell/C
GSMNeighbour/0
GSMCell/E
All RemoteFDDCell objects of an RNC are grouped under the UmtsNeighbouring child object of this RNC.
All GSMCell objects of an RNC are grouped under the GSMNeighbour child object of this RNC.
Section 2 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 16
3 Neighbouring Cell Configuration
3.2 UMTSFddNeighbouringCell
FDDCellA
FDDCellB
FDDCellC
RNC1 RNC2
RNC/1
NodeB/x
FDDCell / A FDDCell/B
UmtsNeighbouring/0
RemoteFDDCell / C
UMTSFddNeighbouringCell / CUMTSFddNeighbouringCell / A
Same Identifier betweenAdjacency and 3G Target Cell
In this example, two 3G->3G adjacencies are defined:
� B->A where both serving cell B and target cell B are controlled by the same RNC1
� B->C where serving cell B is controlled by RNC1 and target cell B is controlled by RNC2
B->A adjacency:
FDDcellB and FDDCellA objects being defined under RNC1, the B->A adjacency is configured by creating
under FDDCellB a child object UMTSFddNeighbouringCell instance having its userLabel parameter value
set to A.
B->C adjacency:
FDDcellB object being defined under RNC1 and FDDCellC object under RNC2, the B->C adjacency is
configured in two steps:
1. by creating under RNC1 a RemoteFDDCell object instance having its userLabel parameter set to C
2. by creating under FDDCellB a child object UMTSFddNeighbouringCell instance having its userLabel
parameter value set to C
Section 2 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 17
GSMCell / E
3 Neighbouring Cell Configuration
3.3 GsmNeighbouringCell
FDDCellA
FDDCellB
RNC1
RNC/1
NodeB/x
FDDCell/B
GSMNeighbour/0
GsmNeighbouringCell / E
Same Identifier betweenAdjacency and 2G Target Cell
GSMCellE
In this example, a 3G->2G adjacency is defined: B->E.
B->E adjacency:
FDDcellB object being defined under RNC1, the B->E adjacency is configured in two steps:
1.by creating under RNC1 a GSMCell object instance having its userLabel parameter set to E
2.by creating under FDDCellB a child object GsmNeighbouringCell instance having its userLabel parameter
value set to E
Section 2 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 18
IndoorCell
IndoorCell
3 Neighbouring Cell Configuration
3.4 UmtsNeighbouringRelation
OutdoorCell
OutdoorCell
RNC1
RNC/1
UmtsNeighbouring/0
UmtsNeighbouringRelation/outdoor->outdoor
Object Class forAdjacency based
Cell Selection and SHOParameters
UmtsNeighbouringRelation/outdoor->indoor
UmtsNeighbouringRelation/indoor->outdoor
IndoorCell
UmtsNeighbouringRelation/indoor->indoor
In UMTS network, some radio parameters used for Cell Reselection and Soft Handover procedures are
defined at Adjacency level. In order to limit the size of the Parameter Database in the RNC these
parameter can not be set per 3G->3G adjacency object (UMTSFddNeighbouringCell) but per Object Class
object called UMTSNeighbouringRelation as one don’t expect to have very different values from one
adjacency to another. Values usually differ according to the network design, morphostructure and traffic
mix in a certain network area.
Section 2 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 19
3.4 UmtsNeighbouringRelation
3.4.1 Example
RNC/1
UmtsNeighbouring/0
UmtsNeighbouringRelation/outdoor->outdoor
UmtsNeighbouringRelation/outdoor->indoor
OutdoorFDDCell
A
OutdoorFDDCell
B
RNC1
IndoorCell C
NodeB/x
FDDCell/A
UMTSFddNeighbouringCell / B
umtsNeighRelationId= UmtsNeighbouringRelation/outdoor->outdoor
UMTSFddNeighbouringCell / C
umtsNeighRelationId= UmtsNeighbouringRelation/outdoor->indoor
In this example, two 3G->3G adjacencies are defined:
� A->B where both serving cell A and target cell B are outdoor cells
� A->C where serving cell A is an outdoor cell and target cell C is an indoor one
A->B adjacency:
A->B Cell Reselection parameters shall be set to the Outdoor->Outdoor type of reselection. Therefore the
configuration shall be done in two steps:
1. by creating under RNC1 a UmtsNeighbouringRelation object instance having its userLabel parameter set
to Outdoor->Outdoor (for instance)
2. by setting for UMTSFddNeighbouringCellB child object of FDDCellA its umtsNeighRelationId parameter
value set to Outdoor->Outdoor
A->C adjacency:
A->C Cell Reselection parameters shall be set to the Outdoor->Indoor type of reselection. Therefore the
configuration shall be done in two steps:
1. by creating under RNC1 a UmtsNeighbouringRelation object instance having its userLabel parameter set
to Outdoor->Indoor (for instance)
2. by setting for UMTSFddNeighbouringCellC child object of FDDCellA its umtsNeighRelationId parameter
value set to Outdoor->Indoor
Section 2 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 20
3 Neighbouring Cell Configuration
3.5 SIB11/DCH Neighboring Lists
Measurement ControlRRC
OR
SI broadcastP-CCPCH
UE
sib11OrDchUsage (UMTSFddNeighboringCell)
sib11OrDchUsage (GSMNeighbouringCell)
NodeB
SIB11+
DCHDCH
SIB11+
DCH
DCH
DCH
DCH
SIB11+
DCH SIB11+
DCH
SIB11+
DCH
DCH
DCH
DCH
SIB11+
DCHDCH
SIB11+
DCH
SIB11+
DCH
SIB11+
DCHDCH
DCH
DCHDCH
DCH
SIB11+
DCH
FDDCell
DCH
SIB11+
DCH
DCH
DCH
SIB11+
DCHDCH
DCH
•sib11AndDch•sib11Usage•dchUsage
sib11AndDchNeighboringFddCellAlgo (FDDCell)
•classic•manual
isSib11MeasReportingAllowedisEnhancedSib11Allowed
(FDDCell)
For Global Market in UA7.0, the maximum number of neighbouring cells in Cell DCH connected mode per FDD cell is:
� 48 UMTS FDD neighbouring cells with a maximum of:
� 32 UMTS intra-frequency neighbours (including serving cell),
� 32 UMTS inter-frequency neighbours,
� 32 GSM neighbours
For Global Market in UA7.1 and for US Market, the maximum number of neighbouring cells in Cell DCH connected mode per FDD cell is:
� 64 UMTS FDD neighbouring cells with a maximum of:
� 32 UMTS intra-frequency neighbours (including serving cell),
� 32 UMTS inter-frequency neighbours,
� 32 GSM neighbours
The only condition to be fulfilled by UMTS and GSM neighbouring cells for Idle, Cell PCH, URA PCH and Cell FACH states (i.e. when broadcast in SIB11 and also in SIB12 from UA06.0) is:
� Intra + Inter + GSM <= 48 (strictly lower than 48 in SIB11/SIB12 when isSib11MeasReportingAllowed is set to True)
If isEnhancedSib11Allowed is set to TRUE then the number of neighbouring cells is enhanced as follows:
� Intra + Inter + GSM <= 96 (up to 32 intra-frequency neighbours including serving cell, up to 32 inter-frequency neighbours and up to 32 GSM neighbours).
Note that there is a limit of 63 UMTS FDD Neighbouring cells which can be created under the serving cell. If flag isSib11MeasReportingAllowed is set to TRUE the limit is unchanged to 31 intrafrequency cells (w/o serving cell), 32 interfrequency cells, and up to 32 GSM Cells,
If isEnhancedSib11Allowed is set to FALSE, the SIB11 neighboring list shall usually be a subset of the Cell_DCH connected mode neighboring list.
The algorithm used to build SIB11 and RRC Measurement Control, for 3G frequency measurements is set by the value of sib11AndDchNeighbouringFddCellAlgo:
� classic (or unset): no distinction between SIB11 and DCH neighboring lists
� manual: RNC reads sib11OrDchUsage to compute the neighboring lists
� automatic: RNC automatically chooses intra-frequency neighboring cells broadcasted in SIB11 (not supported in this release)
� manual algorithm is preferred to declare and control correctly the list of neighboring cells, thus allowing to make differentiation between the configuration of SIB11 neighborhood (i.e. while in idle, PCH and Cell_FACH modes) and Cell_DCH connected mode neighborhood.
� The differentiation is set through the SIB11OrDchUsage parameter on each UmtsFddNeighbouringCell and GsmNeighbouringCell.
Section 2 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 21
Module Summary
� This lesson covered the following topics:
� RNC configuration and associated parameters
� Node B configuration and associated parameters
� Neighbouring Cell configuration and associated parameters
Section 2 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 22
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 2 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionUTRAN Configuration �
2 � 1 � 23
End of Module
Section 3 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
3�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 3Services
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 3 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 2
Blank Page
This page is left blank intentionally
UA7: new radio bearers, update AMR NB config.
Chatila, RayanRyser, Sigrid
2010-04-1502
RemarksAuthorDateEdition
Document History
Section 3 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Describe the mono-RAB user services supported
� Describe the multi-RAB user services supported
� Describe how to configure either mono-rate or multi-rate AMR service
Section 3 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 3 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 5
Table of Contents
Switch to notes view!Page
1 Radio Bearers 71.1 Signaling Radio Bearers 81.2 Conversational Radio Bearers 91.3 Streaming Radio Bearers 101.4 Interactive/Background Radio Bearers 11
2 Services 132.1 Mono and Multi-RAB Services - Examples 142.1.1 DCH 162.1.2 HSxPA 17
3 Multi-Rate AMR 193.1 AMR NB Configurations 203.2 AMR NB TB Definition 213.3 AMR-WB TB Definition 223.4 UL AMR Codec Mode Adaptation 233.5 Multi-Rate AMR Activation – NB and WB 243.6 Multi-Rate AMR call setup 25
Section 3 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 6
Table of Contents [cont.]
Switch to notes view!
This page is left blank intentionally
Section 3 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 7
1 Radio Bearers
Section 3 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 8
1 Radio Bearers
1.1 Signaling Radio Bearers
Traffic Class RB name TTI Traffic Class RB name TTI
Signalling (DCH) SRB_3_4K_DCH 40 ms Signalling (DCH) SRB_3_4K_DCH 40 ms
Signalling (DCH) SRB_13_6K_DCH 10 ms Signalling (DCH) SRB_13_6K_DCH 10 ms
Signalling (FACH) SRB_CellFACH N.A. Signalling (FACH) SRB_CellFACH N.A.
Signalling (DCH) SRB_5_AMR 40 ms Signalling (DCH) SRB_5_AMR 40 ms
Signalling (DCH) SRB_EDCH 10 ms
RadioAccessService
RNC
DlRbSetConf UlRbSetConf
SRB_CellFACH is used for
� Registration (LA/RA/URA/Cell Update)
� Detach
� Originating Low Priority Signaling (Originating SMS)
� Terminating Low Priority Signaling (Terminating SMS)
SRB_3_4K_DCH is used for
� Emergency call
SRB_13_6K_DCH is used for any other causes before Traffic RB(s) is (are) setup
� Originating/Terminating conversational call
� Originating/Terminating streaming call
� Originating/Terminating interactive call
� Originating/Terminating background call
� Call re-establishment
� Inter-RAT cell reselection
� Inter-RAT cell change order
� Originating/Terminating High Priority Signaling
� Terminating cause unknown
SRB__EDCH is used for
� HSUPA Category 6 UE using a minimum 2xSF2+2xSF4 configuration and if 2ms TTI is used
The SRB #5 for AMR rate control (SRB_5_AMR) is not supported in UA7. Thus, the flag isSrb5Allowed must be
set to false
Section 3 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 9
1 Radio Bearers
1.2 Conversational Radio Bearers
Traffic Class RB name TTI Traffic Class RB name TTI
Conversational (Speech) CS_AMR_LR 20 ms Conversational (Speech) CS_AMR_LR 20 ms
Conversational (Speech) CS_AMR_NB 20 ms Conversational (Speech) CS_AMR_NB 20 ms
Conversational (Speech) CS_AMR_WB 20 ms Conversational (Speech) CS_AMR_WB 20 ms
Conversational (CSD) CS_14_4K 40 ms Conversational (CSD) CS_14_4K 40 ms
Conversational (CSD) CS_57_6K 40 ms Conversational (CSD) CS_57_6K 40 ms
Conversational (VT) CS_64K 20 ms Conversational (VT) CS_64K 20 ms
Conversational (Scudif) CS_64K_Scudif 20 ms Conversational (Scudif) CS_64K_Scudif 20 ms
DownLink Radio Bearers UpLink Radio Bearers
RadioAccessService
RNC
DlRbSetConf UlRbSetConf
The standard voice call consists of two narrow-band (300-3400 Hz) sound channels, one in each direction,
and these operate independently.
� CS_AMR_NB stands for AMR Narrow Band RB for which AMR NB voice codecs used allows a DL SF of 128 if
AMR RAB is not multiplexed with another RAB
� CS_AMR_LR stands for AMR Low Rate RB for which AMR LB voice codecs used allow a DL SF of 256 if AMR
RAB is not multiplexed with another RAB
CS_14_4K RB corresponds to the CS data service also provided in GSM networks
CS_57_6K RB corresponds to the CS data service also provided in HSCSD GSM networks
CS_64K RB corresponds to the Video Call service not available in GSM networks
CSD= Conversational Data Service
VT=Video Transmission
Note: CS_64K_Scudif RB “Switching between Video and Speech” is optionally supported starting UA7.1.2
Section 3 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 10
1 Radio Bearers
1.3 Streaming Radio Bearers
RadioAccessService
RNC
DlRbSetConf UlRbSetConf
Traffic Class RB name TTI Traffic Class RB name TTI
Streaming PS_16K_STR 40 ms Streaming PS_16K_STR 20 ms
Streaming PS_64K_STR 40 ms Streaming PS_32K_STR 20 ms
Streaming PS_128K_STR 20 ms Streaming PS_64K_STR 40 ms
Streaming PS_256K_STR 20 ms Streaming PS_128K_STR 20 ms
Streaming PS_384K_STR 10 ms Streaming PS_EDCH_STR2 ms or 10
Streaming PS_HSDSCH_STR 2ms
DownLink Radio Bearers UpLink Radio Bearers
PS_xxx_STR RB >= 256 kbps are provided for High Quality streaming services which require a higher
bandwidth
Streaming over EDCH is an optional feature/service supported starting release UA7.1.2
Section 3 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 11
1 Radio Bearers
1.4 Interactive/Background Radio Bearers
Traffic Class RdnId RB name TTI Traffic Class RdnId RB name TTI
Interactive/Background 34 PS_0K_IB N.A. Interactive/Background 30 PS_0K_IB N.A.
Interactive/Background 35 PS_0K_IB_MUX N.A. Interactive/Background 31 PS_0K_IB_MUX N.A.
Interactive/Background 38 PS_0K_IB_MUX3 N.A. Interactive/Background 38 PS_0K_IB_MUX3 N.A.
Interactive/Background 4 PS_8K_IB 40 ms Interactive/Background 7 PS_8K_IB 40 ms
Interactive/Background 37 PS_8K_IB_MUX 40 ms Interactive/Background 37 PS_8K_IB_MUX 40 ms
Interactive/Background 29 PS_16K_IB 40 ms Interactive/Background 39 PS_8K_IB_MUX3 40 ms
Interactive/Background 9 PS_32K_IB 40 ms Interactive/Background 28 PS_16K_IB 40 ms
Interactive/Background 3 PS_64K_IB 20 ms Interactive/Background 3 PS_32K_IB 40 ms
Interactive/Background 16 PS_64K_IB_MUX 20 ms Interactive/Background 36 PS_32K_IB_MUX 40 ms
Interactive/Background 39 PS_64K_IB_MUX3 20 ms Interactive/Background 40 PS_32K_IB_MUX3 40 ms
Interactive/Background 6 PS_128K_IB 20 ms Interactive/Background 0 PS_64K_IB 40 ms
Interactive/Background 23 PS_128K_IB_MUX 20 ms Interactive/Background 14 PS_64K_IB_MUX 20 ms
Interactive/Background 40 PS_128K_IB_MUX3 20 ms Interactive/Background 41 PS_64K_IB_MUX3 20 ms
Interactive/Background 10 PS_256K_IB 10 ms
DlRbSetConf UlRbSetConf
PS_xx_IB_MUX RB corresponds to a UE having simultaneously several PS RABs established.
� In this version, “Multiple PS RAB” is limited to 2 PS RAB only.
� 3 PS RAB multiple configuration (MUX3) is available for USA Market only
There might be several situations during which UTRAN is required to manage 2 simultaneous PS
Interactive/Background RAB for a given user identified by a single RRC connection:
� A user is activating a primary and a secondary PDP context in order to open bearers with different
quality of service towards a given APN (Access Point Name)
� A user is activating two primary PDP contexts, each of them corresponding to a different APN.
In case of 2 PS RABs configuration, the 2 RLC flows are multiplexed at MAC layer into a single Mac-d flow
� Example:
DPCH SF32
DCH DL 64 SF32
DL 64 DL 64
PDP 1 RAB 1
PDP 2 RAB 2
DL 3,4
DCCH
DCH DL 3,4
Section 3 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 12
1 Radio Bearers
1.4 Interactive/Background Radio Bearers [cont.]
Traffic Class RdnId RB name TTI Traffic Class RdnId RB name TTI
Interactive/Background 7 PS_384K_IB 10 ms Interactive/Background 8 PS_128K_IB 20 ms
Interactive/Background 24 PS_384K_IB_MUX 10 ms Interactive/Background 17 PS_128K_IB_MUX 20 ms
Interactive/Background 17 PS_HSDCH_IB 2 ms Interactive/Background 42 PS_128K_IB_MUX3 20 ms
Interactive/Background 20 PS_HSDCH_IB_MUX 2 ms Interactive/Background 15 PS_384K_IB 10 ms
Interactive/Background 41 PS_HSDCH_IB_MUX3 2 ms Interactive/Background 37 PS_384K_IB_MUX 10 ms
Interactive/Background 13 TRB_CellFACH N.A. Interactive/Background 43 PS_384K_IB_MUX3 10 ms
Interactive/Background 30 TRB_CellFACH_MUX N.A. Interactive/Background 20 PS_EDCH10 or 2 ms
Interactive/Background 11 TRB_CellFACH N.A.
Interactive/Background 26 TRB_CellFACH_MUX N.A.
DlRbSetConf UlRbSetConf
Section 3 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 13
2 Services
Section 3 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 14
2 Services
2.1 Mono and Multi-RAB Services - Examples
16CS_AMR_NBxPS_32K_IB_MUXxSRB_3_4K
4CS_AMR_NBxPS_16K_STRxPS_384K_IBxSRB_3_4K
8CS_AMR_NBxPS_16K_STRxPS_128K_IBxSRB_3_4K
8CS_AMR_NBxPS_16K_STRxPS_64K_IBxSRB_3_4K
16CS_AMR_NBxPS_16K_STRxPS_32K_IBxSRB_3_4K
16CS_AMR_NBxPS_16K_STRxPS_16K_IBxSRB_3_4K
16CS_AMR_NBxPS_16K_STRxPS_8K_IBxSRB_3_4K
16CS_AMR_NBxPS_16K_IBxSRB_3_4K
32CS_AMR_NBxPS_8K_IB_MUXxSRB_3_4K
64CS_AMR_NBxPS_0K_IBxSRB_3_4K
64CS_AMR_NBxPS_0K_IB_MUXxSRB_3_4K
128CS_AMR_LRxPS_EDCH_IBxSRB_3_4K
64CS_AMR_LRxPS_8K_IBxSRB_3_4K
128CS_AMR_LRxPS_0K_IBxSRB_3_4K
4CS_64KxPS_128K_IB_MUXxSRB_3_4K
8CS_64KxPS_64K_IB_MUXxSRB_3_4K
16CS_64KxPS_16K_IBxSRB_3_4K
16CS_64KxPS_0K_IBxSRB_3_4K
16CS_64KxPS_0K_IB_MUXxSRB_3_4K
SFUser Service
32CS_AMR_WBxPS_8K_IB_MUXxSRB_3_4K
4CS_AMR_NBxPS_384K_IBxSRB_3_4K
4CS_AMR_NBxPS_128K_STRxPS_64K_IB_MUXxSRB_3_4K
8CS_AMR_NBxPS_128K_STRxPS_32K_IBxSRB_3_4K
8CS_AMR_NBxPS_128K_STRxPS_16K_IBxSRB_3_4K
16CS_AMR_NBxPS_128K_IBxSRB_3_4K
16CS_AMR_NBxPS_64K_STRxSRB_3_4K
16CS_AMR_NBxPS_64K_STRxPS_EDCHxSRB_3_4K
32CS_AMR_NBxPS_64K_STRxPS_64K_IBxSRB_3_4K
32CS_AMR_NBxPS_64K_STRxPS_32K_IBxSRB_3_4K
8CS_AMR_NBxPS_64K_STRxPS_16K_IBxSRB_3_4K
16CS_AMR_NBxPS_64K_STRxPS_8K_IBxSRB_3_4K
16CS_AMR_NBxPS_64K_IBxSRB_3_4K
4CS_AMR_NBxPS_32K_STRxPS_384K_IBxSRB_3_4K
4CS_AMR_NBxPS_32K_STRxPS_128K_IBxSRB_3_4K
8CS_AMR_NBxPS_32K_STRxPS_64K_IBxSRB_3_4K
16CS_AMR_NBxPS_32K_STRxPS_32K_IBxSRB_3_4K
16CS_AMR_NBxPS_32K_STRxPS_16K_IBxSRB_3_4K
SFUser Service
UlUserService
Up to UA7 CS NB AMR versions were NB1: [12.2, 7.95, 5.9, 4.75] and NB2: [10.2, 6.7, 5.9, 4.75]
From UA7 onwards CS NB2 becomes [12.2, 7.4, 5.9, 4.75]
Section 3 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 15
2 Services
2.1 Mono and Multi-RAB Services – Examples [cont.]
8CS_AMR_NBxPS_384K_STRxSRB_3_4K
8CS_AMR_NBxPS_384K_STRxPS_HSDSCHxSRB_3_4K
8CS_AMR_NBxPS_384K_STRxPS_8K_IBxSRB_3_4K
8CS_AMR_NBxPS_384K_IBxSRB_3_4K
16CS_AMR_NBxPS_128K_STRxPS_8K_IB_MUXxSRB_3_4K
32CS_AMR_NBxPS_64K_STRxPS_8K_IB_MUXxSRB_3_4K
64CS_AMR_NBxPS_16K_STRxPS_8K_IB_MUXxSRB_3_4K
64CS_AMR_NBxPS_16K_IBxSRB_3_4K
64CS_AMR_NBxPS_8K_IB_MUXxSRB_3_4K
128CS_AMR_NBxPS_0K_IBxSRB_3_4K
128CS_AMR_NBxPS_0K_IB_MUXxSRB_3_4K
128CS_AMR_LRxPS_HSDSCHxSRB_3_4K
128CS_AMR_LRxPS_8K_IBxSRB_3_4K
256CS_AMR_LRxPS_0K_IBxSRB_3_4K
8CS_64KxPS_128K_IB_MUXxSRB_3_4K
16CS_64KxPS_64K_IB_MUXxSRB_3_4K
16CS_64KxPS_16K_IBxSRB_3_4K
32CS_64KxPS_0K_IBxSRB_3_4K
32CS_64KxPS_0K_IB_MUXxSRB_3_4K
SFUser Service
128CS_AMR_WBxPS_0K_IB_MUXxSRB_3_4K
128CS_AMR_WBxPS_0K_IBxSRB_3_4K
8PS_384K_STRxPS_8K_IBxSRB_3_4K
16PS_128K_STRxPS_8K_IB_MUXxSRB_3_4K
16PS_128K_STRxPS_0K_IBxSRB_3_4K
32PS_64K_STRxPS_8K_IB_MUXxSRB_3_4K
32PS_64K_STRxPS_0K_IBxSRB_3_4K
64PS_16K_STRxPS_8K_IB_MUXxSRB_3_4K
64PS_16K_STRxPS_0K_IBxSRB_3_4K
128PS_16K_IBxSRB_3_4K
128PS_8K_IB_MUXxSRB_3_4K
N.A.PS_0K_IBxSRB_3_4K
N.A.PS_0K_IB_MUXxSRB_3_4K
8CS_AMR_WBxPS_384K_STRxSRB_3_4K
8CS_AMR_WBxPS_384K_STRxPS_HSDSCHxSRB_3_4K
8CS_AMR_WBxPS_384K_STRxPS_8K_IBxSRB_3_4K
8CS_AMR_WBxPS_384K_IBxSRB_3_4K
32CS_AMR_WBxPS_16K_IBxSRB_3_4K
64CS_AMR_WBxPS_8K_IB_MUXxSRB_3_4K
SFUser Service
DlUserService
Section 3 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 16
2.1 Mono and Multi-RAB Services
2.1.1 DCH
DCH
Stand-alone
CS Conversational speech: AMR_LR, AMR_NB, AMR_WB
CS Conversational VT: 64/64
CS Streaming: 14.4/14.4, 57.6/57.6
PS Streaming DL: 16,32,64,128 UL: 16,64,128,256,384
PS I/B DL: 8,16,32,64,128,256,384 UL: 8,16,32,64,128,384
Combination
CS Conv. Speech + PS I/B DL: 0,8,16,32,64,128,384 UL: 0,8,16,32,64,128,384
CS Conv. VT + PS I/B DL: 0,8,16,32,64,128 UL: 0,8,16,32,64,128,384
(CS Conv. Speech +) PS I/B MUX DL: 0,64,128,384 UL: 0,64,128
CS Conv. VT + PS I/B MUX DL: 0,64 UL: 0,64,128
(CS Conv. Speech +) (PS I/B +) PS Streaming:
PS Streaming DL: 16,64,128,256,384 UL: 16,32,64,128
PS I/B DL: 8 UL: 8,16,64,128,256,384
Section 3 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 17
2.1 Mono and Multi-RAB Services
2.1.2 HSxPA
DL: f(HSD UE category)
UL: f(HSU UE category, TTI, GBR (only for xCEM))
DL: (HSD UE category, GBR)
UL: 16,32,64,128
DL: f(HSD UE category)
UL: f(HSU UE category, TTI)
DL: f(HSD UE category)
UL: 8,16,32,64,128,384
PS I/B HSDPA/DCH
PS I/B HSDPA/HSUPA
PS Streaming HSDPA/DCH
PS Streaming HSUPA
Stand-Alone
HSxPA
Section 3 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 18
2.1 Mono and Multi-RAB Services
2.1.2 HSxPA [cont.]
DL: f(HSD UE category (only for xCEM))
UL: f(HSU UE category, TTI)
DL: f(HSD UE category, GBR)
UL: f(HSU UE category, TTI, GBR (only for xCEM))
PS Streaming:
DL: 16,64,128,256,384 or f(HSD UE category, GBR)
UL: 16,32,64, E-DCH (f(HSU UE category, TTI,
GBR (only for xCEM)))
PS I/B:
DL: f(HSD UE category) UL: f(HSU UE category, TTI)
PS Streaming:
DL: 16,64,128,256,384 or f(HSD UE category, GBR)
UL: 16,32,64,128
PS I/B: DL: f(HSD UE category) UL: 8,16,32,64,128,384
DL: (HSD UE category, GBR) UL: 16,32,64,128
DL: f(HSD UE category) UL: 64,128
DL: f(HSD UE category) UL: f(HSU UE category, TTI)
DL: f(HSD UE category) UL: 8,16,32,64,128,384
DL: f(HSD UE category) UL: f(HSU UE category, TTI)
DL: f(HSD UE category) UL: 8,16,32,64,128,384 CS Conv. Speech + PS I/B HSDPA/DCH
CS Conv. Speech + PS I/B HSD/HSU
CS Conv. VT + PS I/B HSDPA/DCH
CS Conv. VT + PS I/B HSDPA/HSUPA
(CS Conv. Speech +) PS I/B MUX HSDPA/DCH
CS Conv. Speech + PS Streaming HSDPA/DCH
(CS Conv. Speech +) (PS I/B HSDPA/DCH +)
PS Streaming (HSDPA or DCH/DCH)
(CS Conv. Speech +) (PS I/B HSDPA/HSUPA +)
PS Streaming (HSDPA or DCH/DCH)
(CS Conv. Speech +) PS I/B MUX HSxPA
CS Conv. Speech + PS Streaming HSxPA
Combination
Section 3 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 19
3 Multi-Rate AMR
Section 3 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 20
3 Multi-Rate AMR
3.1 AMR NB Configurations
� 2 kinds of AMR Radio Bearers
� CS_AMR_LR : CS AMR Low Rate
� CS_AMR_NB : CS AMR Narrow Band
� Only Configurations A, B and D allow speech and coding rate adaptation
mono-rate AMR Configurations
multi-rate AMR Configurations
12864Uplink Spreading Factor
256128Downlink Spreading Factor
4.754.75k4.75k
5.9k5.9k
7.4k7.95k4.75k
5.9k
12.2k
12.2k12.2k
Supported Bit Rate
CBEDAConfiguration
AMR Low RateAMR Narrow Band
The Multi-rate AMR feature consists of the introduction of a certain number of Multi Mode configurations of
the AMR for the speech service:
� A. 12,2 7,95 5,9 4,75
� B. 5,9 4,75
� C. 4,75
� D. 12,2 7,4 5,9 4,75
� E. 12,2
All these configurations can be used together with I/B PS services but B and C which are intended to be
used with Spreading Factor 256 in DL, e.g. in capacity limited networks.
Configuration E is intended for legacy purposes. It is the only one which is compatible with Iu User Plane
Frame protocol v1 (see 3GPP TS 25.415). Other configurations required Iu UP FP V2.
Section 3 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 21
3 Multi-Rate AMR
3.2 AMR NB TB Definition
� Quality only based on Class A bits� protected by CRC
� Input for OLPC (SIR target update)
AMR Mode Number of bits per TTI (20
ms)
Class A
bits
Class B
bits
Class C
bits
12.2k 244 81 103 60
10.2k 204 65 99 40
7.95k 159 75 84 0
7.4k (not
used) 148 61 87 0
6.7k 134 58 76 0
5.9k 118 55 63 0
5.15k (not
used) 103 49 54 0
4.95k 95 42 53 0
On the radio interface, one dedicated transport channel is established per class of bits, i.e. DCH A for Class
A bits, DCH B for Class B bits and DCH C for Class C bits. Thus, each class can be subject to a different
error protection scheme:
� Class A contains the bits most sensitive to errors and any error in these bits would result in a corrupted
speech frame which needs error correction for proper decoding. It is the only class protected by a CRC.
� Classes B and C contain bits where increasing error rates gradually reduce the speech quality, but the
decoding of an erroneous frame can be done without significantly degrading the quality.
Section 3 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 22
3 Multi-Rate AMR
3.3 AMR-WB TB Definition
� 5 AMR-WB Codes for Telephony
The wideband AMR codec consists in 9 sources with bit rates of 23.85k, 23.05, 19.85k, 18.25k, 15.85k,
14.25k, 12.65k, 8.85k and 6.6k. Only 5 modes are used and supported for telephony 23.85k 15.85k
12.65k 8.85k and 6.6k other modes being used for other services (e.g. can be used for MMS).
SUPPORTED AMR WIDE BAND CONFIGURATIONS
In UA5.1 only TS 26.103 AMR-WB configuration #0 (Active Codec Set (ACS) 12.65 8.85 & 6.60) is supported.
Spreading factor for downlink and uplink is similar to NB-AMR.
For mono services:
� Downlink:128
� Uplink: 64
At AMR-WB Call Setup, the Max Bit rate is initialized to the Max bit rate which is 12.65
Section 3 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 23
3 Multi-Rate AMR
3.4 UL AMR Codec Mode Adaptation
TFCS12.27.955.94.75
TFCS12.27.955.94.75
TFCS12.27.955.94.75
12.210.27.95
7.40
6.70
5.905.154.75
AMR mode (kbps)
UEoutputpower
-
+
AMR Rate change
� For Multi Mode configurations, i.e. A, B and D, the speech rate can change in UL and DL.
� DL rate is set according to the rate of the Iu UP Frames received from the CN.
� UL rate can change either on decision of the UE according to its TFCS selection function or on request
of the CS CN. This latter case can happen when TFO/TrFO is used in Mobile-to-Mobile calls.
AMR Configuration at call set-up
� The AMR configuration is selected according to the CS CN request at call set-up. If the CN supports Iu
UP FP v1 only Configuration E will be used.
� If it supports v2 it must indicate one of the A to D configurations.
AMR code mode adaptations occur in both UL and DL for configurations A, B, D for AMR-NB
and for AMR-WB
� In DL, the AMR rate adaptation occurs in TFO/TrFO scenario when distant UE changes its bit rate ( also
when RNC changes the max DL bit rate ).
� In UL, the UE can select a different AMR rate in case of coverage limit. The UE transmitted is closed to
the maximum. In this case, the UE can reduce its AMR rate.
Section 3 � Module 1 � Page 24
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 24
3 Multi-Rate AMR
3.5 Multi-Rate AMR Activation – NB and WB
isAmrMultiModeAllowed (RadioAccessService)
isAmrMultiModeSetupAllowed (FDDCell)
NOYESenabledPerCell
YESYEScompletelyEnabled
NONOdisabled
FalseTrueisAmrMultiModeSetupAllowed
isAmrMultiModeAllowed
Multi-rate AMR activated in a cell ?
isAmrWbAllowed (RadioAccessService)
Section 3 � Module 1 � Page 25
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 25
3 Multi-Rate AMR
3.6 Multi-Rate AMR call setup
RRC Connection Request
(Originating conversational call)
RRC Connection Setup
RRC Connection Setup Complete
(AS release indicator)
MSC
CM Service Request
(MO call establishment)
Setup
(Speech, Speech Version 3)
RAB Assignment Request
(UP mode version 2)SRB#2
Class A bits
Class B bits
Class C bits
RNCisCnInitiatedRateControlAllowed
allowedIuUpVersion(CsCoreNetworkAccess)
isSrb5AllowedminUeRelForSrb5Amr
isMaxDlAmrRateConfiguredAllowedisCsRabModificationForSpeechAllowed
(RadioAccessService)
maxDlAmrRateConfigured(FDDCell)
Iu UP Init
(RFCIs)
The AMR configuration can be specified at call setup through the SRB #5 if present.
The SRB #5 contains the following information:
� Signaling RB information to setup
� Authorized TFC subset list to be used in UL.
SRB 5 is setup if all of the following conditions are met:
� isCnInitiatedRateControlAllowed is “ True”
� isSrb5Allowed is “True”
� Version 2 of Iu UP is selected
� At least two speech modes are selected (silent mode excluded)
� The UE indicated 3GPP release (UE radio access capability / Access stratum release indicator) is greater
than or equal to the provisioned value of minUeRelForSrb5Amr.
Up to now (UA7) SRB#5 is not supported by ALU UTRAN, therefore isSrb5Allowed must be set to “False” and
SRB#2 is used to transfer AMR adaptation signaling instead of SRB#5.
In UA5.0, the initial AMR codec used at call setup is fixed and equal to the maximum rate allowed among
the ones of the Multi-mode configuration used.
In UA5.1, the initial AMR codec used at call setup can be chosen by the operator thanks to the two
parameters below.
� isMaxDlAmrRateConfiguredAllowed is the activation flag for control of maximum downlink rate for AMR
Narrowband calls based on provisioned cell parameter.
� maxDlAmrRateConfigured is the maximum downlink rate for AMR Narrowband calls in the cell.
isCsRabModificationForSpeechAllowed is the activation flag for CS RAB modification between AMR NB and
AMR WB configuration.
Currently the SRB#5 is not used since not all UEs support it.
Section 3 � Module 1 � Page 26
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 26
Module Summary
� This lesson covered the following topics:
� OAM Shared Objects and associated parameters
� RNC configurations and associated parameters
� Node B configurations and associated parameters
� BTS configurations and associated parameters
Section 3 � Module 1 � Page 27
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 27
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 3 � Module 1 � Page 28
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionServices �
3 � 1 � 28
End of Module
Section 4 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
4�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 4Measurements
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 4 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 2
Blank Page
This page is left blank intentionally
UA7: event 1A updated (Soft HO enhancements) Addition of Events 6A, 6B and 4A
Chatila, RayanRyser, SigridCharneau, Jean-Noel
2010-04-1501
RemarksAuthorDateEdition
Document History
Section 4 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Describe measurements principles
� Describe main measurements purpose and use
� Describe NBAP measurement process and parameters
� Describe RRC measurement process and parameters
� Describe In-Band measurement process and parameters
Section 4 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 4 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 5
Table of Contents
Switch to notes view!Page
1 UMTS Measurements Principles 71.1 Reported Measurements 81.2 Measurements Elaboration 91.3 Measurements Activation 10
2 Main Measurements 112.1 Cell Sets 122.2 Power Measurements 132.3 Signal to Interference Ratio 142.4 Path Loss 152.5 QE and CRCI 16
3 NBAP Measurement Procedures 173.1 NBAP Measurements Initiation 183.2 NBAP Measurement Reports 193.3 Call Trace 203.4 Event Triggered Reports 213.5 Example: Event A 22
4 RRC Measurement Procedures 234.1 RRC Measurements Initiation 244.2 Intra-Frequency Reporting 254.3 RRC Measurements on RACH 264.4 Fast Measurements at Call Establishment 27
5 Event triggered reporting of RRC measurements 285.1 Intra-Frequency measurements Reporting 295.2 Events for Active Set Management 305.3 Events for Hard Handover Management 315.4 Events for Always-On and RB Rate Adaptation 325.5 Example: event 1A 33
6 In-Band Measurement Procedures 346.1 RACH & DCH FP Measurements 35
Section 4 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 6
Table of Contents [cont.]
Switch to notes view!
This page is left blank intentionally
Section 4 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 7
1 UMTS Measurements Principles
Section 4 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 8
1 UMTS Measurements Principles
1.1 Reported Measurements
• Propagation Delay (RACH)• BLER (CRCI)• BER (QE)
• SIR• SIR Error• DL Transmitted Code Power• Round Trip Time
• DL Transmitted Carrier Power• DL Transmitted power of all codes not used for HS-PDSCH,HS-SCCH,E-AGCH,E-RGCH,E-HICH• UL Received Total Wideband Power• Acknowledged PRACH Preamble
UE Internal Measurements• UE Transmitted Power• UE Position (UEbased GPS)
Quality Measurements• Transport Channel BLER• SIR
Traffic Volume Measurements (UL)
Inter System Measurements• GSM Carrier RSSI• Path Loss• BSIC• Observed time difference to GSM Cell
Intra & Inter Frequency Measurements• P-CPICH Ec/No• P-CPICH RSCP• Path Loss• SFN-SFN Observed Time Difference• Cell Synchronization Information (SFN-CFN)• UTRA Carrier RSSI
RRC Measurements
NBAP Measurements
BTS In-Band Measurements
RNC
UE
NodeB
The Node B has to provide two types of measurements: common measurements and dedicated
measurements. These measurements are also called NBAP Measurements because they are reported to
the RNC using NBAP messages.
Beside the NBAP measurements, the BTS is also providing measurements results that are sent in-band.
The UE has to be capable of performing 7 different measurement types: intra-frequency, inter-frequency,
inter-system, traffic volume, quality, UE-internal and UE positioning. These measurements are also called
RRC Measurements because they are reported to the RNC using RRC messages.
In UA5.0, the NodeB removes only the contribution of HSDPA channels (it will not remove the E-DCH
contribution) to the power measurement. This leads to slightly overestimation of the R99 contribution
and impact DCH call admission control. This effect can be attenuated by increasing DCH admission
threshold on power for HSUPA cells.
Section 4 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 9
1 UMTS Measurements Principles
1.2 Measurements Elaboration
ESTIMATING
acquisition time
FILTERING
filter coefficient
REPORTING
reporting period
or
event triggered RNC
NodeB
UE
NBAP Measurements
RRC Measurements
FN = (1 - a).FN-1 + a.MN
Physical Layer provides measurements to the upper layers (Layer 3). For each measurement, a basic
measurement period is defined, which corresponds to the shortest averaging period and also the shortest
reporting period i.e. the NodeB or UE can not be required to report a measurement to the RNC in a
shorter time period.
Before reporting to the RNC, the NodeB or UE Layer 3 performs a filtering operation averaging several
measurements and allowing to create measurements reports with a period not necessarily equal to the
basic measurement period. The filtering parameter a is defined as a = 1/2k/2, where k is the parameter
received in the Measurement Filter Coefficient IE.
The reporting period for each measurement is configured by the RNC when the UE or the NodeB is
requested to perform measurements. The minimum reporting period for each measurement is equal to
the basic measurement period for this measurement. In general, the reporting period is a multiple of the
basic measurement period.
For UTRAN measurements reported in-band, the reporting period is the period at which frames are sent
from the NodeB to the serving RNC.
Section 4 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 10
1 UMTS Measurements Principles
1.3 Measurements Activation
RNC
isInterFreqMeasActivationAllowed(RadioAccessService)
IsInterfreqCModeActivationAllowedisGsmCModeActivationAllowed
(DlUserService)
measurementConfClassId(NeighbouringRNC)
measurementConfId(FDDCell)
ueInternalMeasurementQuantityueInternalMeasurementFilterCoeff
(UEIntMeas)
isEventTriggeredMeasAllowed(FDDCell)
Each FDDCell and NeighbouringRNC must have a pointer to one of the Measurement Configuration Classes
stored under the RNC they depend upon.
The parameter isEventTriggeredMeasAllowed controls the activation of Full Event Triggered RRC
measurement reports per FDDcell.
The parameter isInterFreqMeasActivationtAllowed controls the activation of inter-frequency RRC
measurement reports whether Inter-FDD or Inter-RAT neighbouring cells are to be measured.
� The parameter IsInterfreqCmodeActivationAllowed controls the activation of of compress mode for
inter-FDD neighboring cells measurements.
� The parameter isGsmCmodeActivationAllowed controls the activation of compress mode for inter-RAT
neighboring cells measurements.
When set to true, the parameter UeInternalMeasurementQuantity allows to choose which measurement
type is selected among the three available types: ueTransmittedPower, utraCarrierRssi, ueRxTxTimeDiff.
Note: UeIntMeas is an optional object.
Section 4 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 11
2 Main Measurements
Section 4 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 12
2 Main Measurements
2.1 Cell Sets
Cells belonging to the Active Set
Cell belonging to the Monitored Set
Cell belonging to the Detected Set
isDetectedSetCellsAllowed(RadioAccessService)
There are 3 different ways to classify the cells that may be involved in handover procedures:
� Cells belonging to the Active Set are the cells involved in the soft handover and that are communicating
with the UE.
� Cells belonging to the Monitored Set, that do not belong to the active set, but that are monitored by
the UE depending on the neighboring list sent by the UTRAN.
� Cells belonging to the Detected Set, which are detected by the UE, but that are neither in the Active
Set nor in the Monitored Set.
isDetectedSetCellsAllowed indicates if the detected set cells have to be taken into account for RRC Intra-
Frequency measurement management for the calls established in Event-Triggered Reporting Mode.
Section 4 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 13
2 Main Measurements
2.2 Power Measurements
Ec/No (dB)
-25 -15 -10 0
Power density of CPICH
Power density in the band
GSM Signal
Pilot
Pilot
Received Power on the GSM BCCH carrier
CPICH_Ec/No =
GSM CARRIER RSSI =
CPICH_RSCP =
Received Signal Code Power measured on CPICH OVSF
code
Intra/Inter-FrequencyIntra/Inter-Frequency
Inter-System
CPICH Ec/No
� CPICH Ec/No is the received energy per chip divided by the power density in the band, that is, it is
identical to the RSCP measured on the CPICH divided by the RSSI. The UE has to perform this
measurement on the Primary CPICH and the reference point is the antenna connector of the UE. This
measurement is used for cell selection and re-selection and for handover preparation.
CPICH RSCP
� CPICH RSCP is the Received Signal Code Power on one channelization code measured on the bits of the
Primary CPICH. The reference point is the antenna connector at the UE. Although the measurement of
this quantity requires that the Primary CPICH is despread, it should be noted that the RSCP is related to
a chip energy and not a bit energy. This measurement is used for cell selection and re-selection and for
handover preparation, open loop power control and pathloss calculation.
GSM carrier RSSI
� This measurement is the wide-band received measured on a specified GSM BCCH carrier. This
measurement is used for GSM handover preparation.
Section 4 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 14
2 Main Measurements
2.3 Signal to Interference Ratio
DPCCH
ServingRNC
SIR =Power ControlSIR Target
SIR_Error = SIRUL outer loop power control
Received Signal Code Power
Interference Signal Code PowerSF x
DPCCH= SIR
RSCP
ISCPx
2
SF
DL outer loop power control
– SIR Target
SIR = Link Quality Estim
ation
SIR (Node B measurement)
� The Signal to Interference Ratio (SIR) is measured on a dedicated physical control channel (DPCCH)
after radio link combination in the Node B. In compressed mode, the SIR should not be measured during
the transmission gaps.
� SIR is defined as SF*(RSCP/ISCP) where SF is the spreading factor, RSCP is the Received Signal Code
Power and ISCP is the Interference Signal Code Power.
� This measurement is used in Power Control algorithm.
SIR Error
� SIR error is defined as SIR - SIRtarget. SIRtarget is the SIR value for the UL outer loop power control
algorithm.
� This measurement is used to assess the efficiency of the UL outer loop power control.
SIR (UE measurement)
� SIR is defined as (RSCP/ISCP)*SF/2
� The reference point for RSCP and ISCP is the antenna connector, but they can only be measured at the
output of the de-spreader as they assess either the received power and the non-orthogonal reference
received on a particular code. It should be clearly understood that RSCP is though a wideband
measurement i.e. at chip level, the narrow band measurement is RSCP * SF/2.
� This measurement is used as a quality estimation for the link (for downlink outer loop power control). It
is sent periodically, once every power control cycle and event triggered to the RNC (RRC).
Section 4 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 15
2 Main Measurements
2.4 Path Loss
Path Loss = Primary CPICH Tx Power - P-CPICH_RSCP
P-CPICH
FDD Cell
Path Loss
Path Loss
The path loss is defined as Primary CPICH Tx power – P-CPICH RSCP.
This measurement is used to define the initial PRACH power and for inter frequency handover criteria
evaluation.
Section 4 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 16
2 Main Measurements
2.5 QE and CRCI
RNC
CRCIndicator
Physical
Channel
• Soft Handover• UL outer loop PC
IE QE Selector:
« selected » Transport Channel BER
« non-selected » Physical Channel BER
OR
Quality Estimate:
Frame Protocols
Transport Channels
blockblock
qeSelector (Static)
Transport Channels
blockblock
DATA CRCtx
CRC INDICATOR
� The CRC indicator is attached to the UL frame for each transport block of each transport channel
transferred between the NodeB and the RNC. It shows if the transport block has a correct CRC
(0=Correct, 1=Not Correct). This measurement is used for frame selection in case of soft handover.
QUALITY ESTIMATE
� The quality estimate is reported in band in the UL data frames from the NodeB to the RNC and it is
derived from the Transport channel BER or Physical channel BER. If the IE QE-Selector is equal to:
� selected » in the DCHs of the DCH FP frame, then the QE is set to the Transport channel BER
� non-selected » in the DCHs of the DCH FP frame, then the QE is set to the Physical channel BER.
� In case of soft handover, the quality estimate is needed in order to select a transport block when all
CRC indications are showing bad (or good) frame. The RNC compares the QE value with the qeThreshold
(static parameter) in order to choose the best transport block.
� Quality Estimate can also be used to enhance the UL Outer Loop Power Control mechanism.
Section 4 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 17
3 NBAP Measurement Procedures
Section 4 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 18
3 NBAP Measurement Procedures
3.1 NBAP Measurements Initiation
• DL Transmitted Code Power
• SIR
• RTT
• ...
• On Demand
• Event-Triggered
• Periodic
MeasurementID
MeasurementObject Type
Measurementtype
MeasurementFilter
Coefficient
ReportCharacteristics
Measurement Initiation Request
• Cell• RACH• …
• Common
• Dedicated
• DL Transmitted Carrier Power
• RTWP
• ...
C-RNC
Node B Common
Dedicated
Depending on the type of measurement, (common or dedicated), measurement requests are initiated by
the controlling RNC by sending a COMMON MEASUREMENT INITIATION REQUEST or DEDICATED
MEASUREMENT INITIATION REQUEST to the Node B.
The common and dedicated measurement messages both contain the following information elements to
define the measurements to be performed:
� A measurement id uniquely identifying each measurement.
� A measurement object type to indicate the type of object on which the measurement is to be
performed, e.g., cell, RACH, time slot, etc.. It can be common or dedicated according to the message.
In the case of a dedicated measurement either a radio link is identified on which the measurement has
to be performed or the measurement should be performed on all radio links for the Node B.
� A measurement type indicates which measurement is to be performed. It is also common (Received
total wideband power, transmitted carrier power, Acknowledged PRACH preambles, etc.) or dedicated
(SIR, transmitted code power, In-Band (transport channel BER, physical channel BER), etc.).
� A measurement filter coefficient gives the parameter for the layer 3 filtering to be performed before
the measurement can be reported.
� The report characteristics give the criteria for reporting the measurement. The reporting is on demand,
periodic or event-triggered.
Section 4 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 19
3 NBAP Measurement Procedures
3.2 NBAP Measurement Reports
Common Measurement Reports
commonMeasurementReportingPeriodcommonMeasurementFilterCoeff
(NBAP Measurement)
nbapCommonMeasRtwpReportingPeriodnbapCommonMeasRtwpFilterCoeff
(NbapMeasRtwpParameters) Measurement ID
Report Type
Measured Quantity
C-RNCNode B
Common Measurement Termination Request
The reports are sent in the COMMON MEASUREMENT REPORT, on criteria defined by the report
characteristics given in the measurement request.
For these Common Measurements, the type of measurement report is defined by the parameter
commonRepType [on demand, periodic, event-triggered].
The quantity measured is defined by the parameter measQuantity.
The periodicity is given in the Report_Periodicity IE of the measurement request message.
The periodicity is given in the Report_Periodicity IE of the measurement request message and corresponds
to CommonMeasurementReportingPeriod parameter for DL Transmitted Carrier Power and DL Transmitted
Carrier Power of All Codes not used for HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH Transmission.
� nbapCommonMeasRtwpReportingPeriod is the reporting period to be applied to UL RTWP measurement
CommonMeasurementFilterCoeff is the filtering coefficient to be applied to DL Transmitted Carrier Power
and DL Transmitted Carrier Power of All Codes not used for HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-
HICH Transmission measurements.
� nbapCommonMeasRtwpFilterCoeff is the filtering coefficient to be applied to UL RTWP measurement
The measurements reporting by the Node B stops upon reception of COMMON MEASUREMENT TERMINATION
REQUEST sent by the C-RNC if any.
Section 4 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 20
3 NBAP Measurement Procedures
3.3 Call Trace
Measurement Reports
sirRequiredsirReportPeridodicity
transmittedCodePowerRequiredtransmittedCodePowerReportPeridodicity
roundTripTimeRequiredroundTripTimeReportPeriodicity
(NbapDedicatedMeasConfigForCallTrace)
C-RNCNode B
Measurement Initiation Request
Dedicated Measurement Termination Request
Common
Dedicated
Common
Dedicated
Common Measurement Termination Request
tcpRequiredtcpReportPeriodicity
rtwpRequiredrtwpReportPeridodicity
(NbapCommonMeasConfigForCallTrace)
In the case of Dedicated Measurements, three different types of measurements reports are supported (SIR,
DL TRANSMITTED CODE POWER and ROUND-TRIP-TIME). For Call Trace purposes, these three types of
reports can be activated separately and can be configured with different periodicities.
The procedure is initiated with a DEDICATED MEASUREMENT INITIATION REQUEST message sent from the RNC
to the Node B. This procedure is used by a RNC to request the initiation of measurements on dedicated
resources (all UE Radio links managed by FDDCells belonging to this Node B.
Upon reception, the Node B shall initiate the requested measurement according to the parameters given in
the request and shall periodically send a DEDICATED MEASUREMENT REPORT.
The procedure is operational as long as the RL is established. The RNC does not send sent a DEDICATED
MEASUREMENT TERMINATION REQUEST message. Instead, even though the trace session is deleted, the
NBAP dedicated measurement reporting, if initiated, will remain until the radio links associated with the
call being traced are deleted or released.
� Round trip time (RTT) is defined as: RTT = TRX - TTX, where:
TTX = the time of transmission of the beginning of a DL DPCH frame to a UE,
TRX = the time of reception of the beginning (the first detected path in time)
of the corresponding UL DPCCH/DPDCH frame from the UE.
Section 4 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 21
3 NBAP Measurement Procedures
3.4 Event Triggered Reports
C-RNC
Node B
Dedicated Measurement Initiation Request (Bx)
Dedicated Measurement Termination Request (Bx)
NBAP Dedicated Report Event Bx
RL Monitoring
• Event A
• Event B1
• Event B2
Primary Cell
iRM Scheduling Downgraded UE
NBAP event triggered report mode is only used in the scope of iRM scheduling downgrade/upgrade
procedures with the RNC perspective to retrieve the transmitted code power by the Node B for a particular
radio link (user) and to order the radio bearer downsizing/upsizing through iRM scheduling towards the
more adapted bit rate to guarantee service continuity.
For the purpose of iRM Scheduling RNC configures the Node B with one Event A and two Events B:
� Event A is indicating that the radio conditions have become bad enough to attempt a downgrading to
the fallback radio bearer in order to maintain a good radio link quality.
� Event B1 is indicating that the radio conditions have become good enough to attempt an upgrading
towards the original requested RB.
� Event B2 is indicating that the radio conditions have become good enough to consider an upsizing
towards a relative lower bit rate than the requested RB to maintain a good radio link quality.
Section 4 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 22
3 NBAP Measurement Procedures
3.5 Example: Event A
Transmitted Code Power
Event AReport
Primary CellthresholdDelta
(DlIrmSchedDowngradeTxcp)
Event A timeToTrigger Event A timeToTrigger
timeToTrigger
(DlIrmSchedDowngradeTxcp)
Event AThreshold
pcpichPower + maxDlTxPowerPerOls
-
In order to be able to perform IRM Scheduling downgrade, the RNC configures NBAP dedicated measurement
by event A report for this UE on the primary cell.
So, each time the primary cell changes, the RNC terminates measurements on the old primary cell and
initiates measurements on the new primary cell.
Event A configuration relies on:
� Measurement Threshold: the relative transmitted code power threshold given by the parameter
threshold_delta is used to compute the absolute TxCP Threshold together with the parameters
pcpichPower (FDDCell) and maxDlTxPowerPerOls (DlUsPowerConf).
� Measurement Hysteresis: timeToTrigger.
So Event A is reported when the transmitted code power is above TxCP absolute threshold during at least
the time to trigger.
Section 4 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 23
4 RRC Measurement Procedures
Section 4 � Module 1 � Page 24
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 24
4 RRC Measurement Procedures
4.1 RRC Measurements Initiation
Measurement ControlRRC
OR
SI broadcastP-CCPCH
Node BUE
MeasurementID
MeasurementObject
MeasurementType
MeasurementQuantity
• FDDCell• Physical Channel• RB• …
• Ec/No• RSCP• BLER• Traffic Volume• ...
Inter-FrequencyIntra-FrequencyInter-SystemTraffic VolumeQualityUE internal
MeasurementReportingQuantity
MeasurementReportingCriteria
ReportingMode
MeasurementCommand
• Setup • Modify• Release
• Periodical• Event-Triggered
• RLC AM• RLC UM
In CELL_FACH, CELL_PCH or URA_PCH state, the UE is informed of the measurements to perform via the
system information broadcast on the P-CCPCH.
When the UE is in CELL_DCH state, UTRAN starts a measurement in the UE by sending the MEASUREMENT
CONTROL message, which includes the following information elements to define measurements to
perform:
� measurement id is a reference number to be used when modifying or releasing measurement.
� measurement command indicates the action performed on the measurement (set up a new
measurement, modify the characteristics of a measurement, …).
� measurement type indicates one of the different types of measurement: inter-frequency, intra-
frequency, ….
� measurement object indicates the object on which the measurement shall be performed.
� measurement quantity indicates the quantity to be measured (RSCP, SIR, ...),
� measurement reporting quantity indicates quantities that the UE should report together with the
measurement quantity for example, the measurement quantity which triggered the report.
� measurement reporting criteria indicates the type of reporting that is, periodical or event-triggered.
� reporting mode specifies whether the UE shall transmit the measurement report using acknowledged or
unacknowledged RLC mode.
Section 4 � Module 1 � Page 25
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 25
4 RRC Measurement Procedures
4.2 Intra-Frequency Reporting
Active Set cells+
6 Best Monitored cells
• Cell Synchronization information (SFN-CFN)
• CPICH Ec/No
• CPICH RSCP
• SFN-SFN observed time difference « type2 »
Measurement Report
Measurement Report
rrcIntraFreqMeasurementReportingPeriodrrcIntraFreqMeasurementFilterCoeff
(RRCMeasurement)
MeasurementID
MeasurementReportingQuantity
Node B
MeasurementResults
repMode (static)
maxCellsRepType (static)
The MEASUREMENT REPORT message is sent from the UE to the UTRAN and contains the measurement id,
the measured results and the measurement event result that was required to be reported.
When the rrcIntraFreqMeasurementReportingPeriod time has elapsed, the UE shall send the computed
measurement.
Reporting Quantities
� The RNC requests the following quantities to be reported by the mobiles:
� “Cell Synchronization information”: provides the difference between SFN of the reported cell and
CFN as observed by the UE.
� CPICH Ec/No: the received energy per chip divided by the power density in the band.
� CPICH RSCP: the received power on one code measured on the Primary CPICH.
� Other reporting quantities are also supported by UTRAN and are also requested to the UE for tracing
purposes:
� SFN – SFN observed time difference "type 2": the relative timing difference between cell j and cell i
measured on the primary CPICH.
The parameter RepMode indicates that UE shall report measurements on active set cells and intrafrequencymonitored set cells. This STATIC parameter is set to ACTIVE_SET_AND_MONITORED_ON_FREQ.
The parameter maxCellsRepType indicates the number of measured cells belonging to the monitored set. This STATIC parameter is set to 6.
Section 4 � Module 1 � Page 26
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 26
4 RRC Measurement Procedures
4.3 RRC Measurements on RACH
RACH
Neighboring Cells
sib11IntraFreqMeasurementNbrOfCellOnRACHsib11IntraFreqMeasurementFilterCoeffOnRACH
(RRCSysInfoMeas)
SIB 11
Reported Measurements on RACH
CPICH Ec/No
CPICH RSCP
Path Loss
or
or
measQuantity (static)
Measurements reported in RACH message are used by power allocation and RAB assignment algorithms.
The static parameter measQuantity determines the type of reported measurements. Only the value
CPICH_Ec/No is supported for static measQuantity parameter.
The parameter sib11IntraFreqMeasurementNbrOfCellOnRACH indicates how many cell measurements shall
be reported in the RACH message, including the current cell; for instance the current cell plus the best 4
measured neighbours.
The number of reported cells on RACH is used by the compound neighbor list feature to create the
neighboring list for the first Measurement Control Message.
As specified by 3GPP 25.212, no filtering shall be performed for the measurements reported in RACH.
Note: For parity reason, Sib11IntraFreqMeasurementNbrOfCellOnRACH is set to “currentCell” value in USA
customer template.
Section 4 � Module 1 � Page 27
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 27
4 RRC Measurement Procedures
4.4 Fast Measurements at Call Establishment
Measurement Control
SI broadcastP-CCPCH
NodeBUERRC Connection Request
RRC Connection Setup
Measurement Report
isSib11MeasReportingAllowed
(FDDCell)
cpichEcNoReportingRange1Ahysteresis1A
timeToTrigger1AmaxActiveSetSize
RNC
RadioAccessService
DedicatedConf
HoConfClass
Event1AHoConfInSIB11
This feature allows UTRAN to provide intra-frequency measurements configuration information to UEs which
are in Idle Mode or in Cell-FACH. Received within the SIB11, information is used by UEs to activate intra-
frequency measurements just after entering the Cell-DCH state, with no need to wait for the first
Measurement Control.
If the reporting mode is “Event Triggered”, only Event 1A is configured in the SIB11 and UE sends the first
Measurement Report only if the 1A Event has been reached. The rest of the events are configured in the
first RRC Measurement Control message. Event1AHoConfInSIB11 dedicated object has been created under HoConfClass so that specific 1A setting can be broadcast in SIB11 for faster measurement.
If the reporting mode is “Periodic”, the UE keeps on sending reports at the defined period until the
reception of the first RRC Measurement Control.
The first RRC Measurement Control message sent to the UE is of type SETUP instead of MODIFY in order to
ensure no misalignment between UE and the Network.
UE starts sending measurements when its state changes:
� from Idle mode to Cell-DCH (after the RRC Connection Setup)
� from Cell-FACH to Cell-DCH (after the RRC RB Setup)
If isSib11MeasReportingAllowed is set to True, SIB11 (but also SIB12 if Sib12Enable is set to True) will include the 3GPP TS 25.331 “Intra-Frequency Measurement Quantity” and “Reporting information for
state CELL_DCH” Information Elements (IEs) which allow the UE to configure the intra-frequency
measurement reporting mode until the reception of the RRC Measurement Control message.
If isSib11MeasReportingAllowed is set to True,the serving cell has to be present in the neighbouring intrafreq cells list present in SIB11, reducing therefore the maximum number of neighbour cells by 1.
If isSib11MeasReportingAllowed is set to False, SIB11 and SIB12 does not include these IEs and UE mustwait for the first RRC Measurement Control to measure neighbouring cells when entering Cell_DCH.
Section 4 � Module 1 � Page 28
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 28
5 Event triggered reporting of RRC measurements
Section 4 � Module 1 � Page 29
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 29
5 Event triggered reporting of RRC measurements
5.1 Intra-Frequency measurements Reporting
Active Set cells+
6 Best Monitored cells+
3 Best Detected cells (call trace only)
• CPICH Ec/No
• CPICH RSCP
Measurement Report (EventNX)
MeasurementID
MeasurementReportingQuantity
Node B
MeasurementResults
isEventTriggeredMeasAllowed(FDDCell)
isDetectedSetCellsAllowed(RadioAccessService)
The MEASUREMENT REPORT message is sent from the UE to the UTRAN and contains the measurement id,
the measured results and the measurement event result that triggered the report.
Reporting Quantities
� The RNC requests the following quantities to be reported by the mobiles:
� CPICH Ec/No: the received energy per chip divided by the power density in the band.
� CPICH RSCP: the received power on one code measured on the Primary CPICH.
� In case or Event Measurements Reported for UE tracing, then up to 3 best detected cells can be
reported in some of the Events.
Section 4 � Module 1 � Page 30
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 30
5 Event triggered reporting of RRC measurements
5.2 Events for Active Set Management
The P-CPICH of a cell that is in DCH AS but not in E-DCH AS becomes better than the P-CPICH of a cell that is already in E-DCH AS
Any of Active SetCPICH Ec/NoMeasid1 1J
An active P-CPICH becomes worse than an absolute threshold.
RL deletion based on absolute criteria
Any of Active SetCPICH Ec/NoMeasid1 1F
A monitored P-CPICH becomes better than an absolute threshold.
RL addition based on absolute criteria when Active Set is not full
Any of Monitored Set
CPICH Ec/NoMeasid1 1E
Change of best cell. Primary cell changeAny of measured cell
CPICH Ec/NoMeasid1 1D
A non-Active P-CPICH becomes better than Active P-CPICH.
RL replacement based on relative criteria when AS is full
Any of Monitored Set
CPICH Ec/NoMeasid1 1C
An active P-CPICH enters a reporting range.
RL deletion based on relative criteria
Any of Active SetCPICH Ec/NoMeasid1 1B
A monitored P-CPICH enters a reporting range.
RL addition based on relative criteria when Active Set is not full
Any of Monitored Set
CPICH Ec/NoMeasid1 1A
Soft Handover Management
Semantics & usageTriggering cellsTriggering quantity
Meas. IdEvent Id
Events 1x are RRC intra-frequency measurements
3GPP specifications define 2 RRC measurements reporting modes; periodical reporting and event-triggered
reporting. For the event triggered reporting mode, RRC standards define a set of events for each type of
measurement:
� Events 1X are defined for intra-frequency measurements
� Events 2X are defined for inter-frequency measurements
� Events 3X are defined for inter-RAT measurements
� Etc.
Event-triggered reporting is used in Alcatel-Lucent UTRAN for RRC intra-frequency reporting measurements.
The use of event triggered reporting for intra-freq measurements has a direct impact on the following
mechanisms:
� primary cell determination
� active set management
� radio link color determination
Section 4 � Module 1 � Page 31
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 31
5 Event triggered reporting of RRC measurements
5.3 Events for Hard Handover Management
Estimated UE Tx power becomes less than an absolute thresholdN.A.UE Tx PowerMeasid156B
Estimated UE Tx power becomes larger than an absolute thresholdN.A.UE Tx PowerMeasid156A
Best Active Set cell CPICH RSCPMeasid12 2F
Estimated P-CPICH quality of current carrier is better than threshold
Estimated P-CPICH level of current carrier is better than threshold
Best Active Set cell CPICH Ec/NoMeasid11 2F
Best Active Set cell CPICH RSCPMeasid12 2D
Estimated P-CPICH quality of current carrier is worse than threshold
Estimated P-CPICH level of current carrier is worse than threshold
Best Active Set cellCPICH Ec/NoMeasid11 2D
Hard Handover Management
Semantics & usageTriggering cellsTriggering quantity
Meas. IdEvent Id
Events 2x are RRC inter-frequency measurementsEvents 6x are RRC UE internal measurements
In ALU UTRAN:
� RRC inter-frequency measurements on used frequency are event-triggered (2D and 2F)
� RRC inter-frequency measurements on non-used frequency are periodical
� RRC inter-RAT measurements are periodical
� RRC UE internal measurements are event-triggered (6A and 6B)
The use of event triggered reporting for inter-freq measurements on used frequency and UE internal
measurements has a direct impact on the following mechanisms:
� alarm measurement criteria (Compressed Mode and Hard handover triggering)
� inter-frequency or inter-RAT blind handover
Section 4 � Module 1 � Page 32
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 32
5 Event triggered reporting of RRC measurements
5.4 Events for Always-On and RB Rate Adaptation
TrCh Traffic Volume becomes larger than an absolute thresholdN.A.UE RLC Buffer Occupancy
Measid74A
Hard Handover Management
Semantics & usageTriggering cellsTriggering quantity
Meas. IdEvent Id
Events 4x are RRC Traffic Volume measurements
In ALU UTRAN:
� RRC UE Traffic Volume measurement is event-triggered (4A)
The use of event triggered reporting for UE Traffic Volume measurements has a direct impact on the
following mechanisms:
� Always-On upsize from FACH to DCH
� RB Rate Adaptation upsize from a given DCH bit rate to a higher one
Section 4 � Module 1 � Page 33
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 33
5 Event triggered reporting of RRC measurements
5.5 Example: event 1A
Best Cell
New Cell
CPICH_EC/No
entering reporting range
leaving reporting range
Event1A
Event1A
Event1A
timeToTrigger1A(FullEventHOConfShoMgtEvent1A)
repInterval1A(FullEventRepCritShoMgtEvent1A)
amountRep1A(FullEventRepCritShoMgtEvent1A)
cpichEcNoReportingRange1A (FullEventHOConfShoMgtEvent1A)
)2/(10)1(1010 111
aaBest
N
iiNewNew HRLogMWMLogWCIOLogM
A
m−⋅⋅−+
⋅⋅≥+⋅ ∑
=
maxNbReportedCells1A(FullEventRepCritShoMgtEvent1A)
hysteresis1A (FullEventHOConfShoMgtEvent1A)
neighbouringCellOffset (UmtsNeighbouringRelation)
wParam (static)
Event 1A is triggered when a new P-CPICH enters the reporting range.
Event 1A is used to add a RL based on relative criteria when the Active Set is not full.
The variables in the formula are defined as follows:
� MNew is the measurement result of the cell entering the reporting range.
� CIONew is the individual cell offset for the cell entering the reporting range if an individual cell offset
is stored for that cell. Otherwise it is equal to 0.
� Mi is a measurement result of a cell not forbidden to affect reporting range in the active set.
� NA is the number of cells not forbidden to affect reporting range in the current active set.
� MBest is the measurement result of the cell not forbidden to affect reporting range in the active set
with the best measurement result, not taking into account any cell individual offset.
� W is a parameter sent from UTRAN to UE.
� R1a is the reporting range constant.
� H1a is the hysteresis parameter for event 1a.
By default event 1A is triggered by cells belonging to the monitored set.
In order to help the operator to monitor efficiently its network, and optimize its neighboring plan, it is
possible to trigger this event 1A based on both Detected Set and Monitored Set.
� In order to achieve this, the parameter isDetectedSetCellsAllowed shall be set to True.
� From UA7 onwards the decision if the cells from Detected Set are used in the mobility algorithms
depends on the flag detectedSetCellAddition.
Section 4 � Module 1 � Page 34
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 34
6 In-Band Measurement Procedures
Section 4 � Module 1 � Page 35
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 35
6 In-Band Measurement Procedures
6.1 RACH & DCH FP Measurements
1st Transport Block of 1st DCH
1st Transport Block of 1st DCH Pad.
Last Transport Block of 1st DCH
Last Transport Block of 1st DCH Pad.
1st Transport Block of last DCH
1st Transport Block of last DCH Pad.
Last Transport Block of last DCH
Last Transport Block of last DCH Pad.
QE
CRCI
Pad.CRCI
Spare extension
Payload Checksum (optional)
Payload Checksum (optional)
Header CRC FT
CFN
Spare TFI of 1st DCH
Spare TFI of last DCH
1st RACH Transport Block
1st RACH Transport Block Pad.
Last RACH Transport Block
Last RACH Transport Block Pad.
CRCI
Pad.CRCI
Spare extension
Payload Checksum (optional)
Payload Checksum (optional)
Header CRC FT
CFN
Spare TFI
Propagation Delay
The propagation delay is reported in the RACH data frames transferred from the Node B to the RNC when a
successful RACH procedure has happened and the RACH has been sent from the UE to the RNC.
The CRC Indicator is attached to the UL frame for each transport block of each transport channel
transferred between the Node B and the RNC. It shows if the transport block has a correct CRC.
The Quality Estimate is reported in band in the UL data frames from the Node B to the RNC. This QE
corresponds to either the transport channel BER or the physical channel BER when no transport channel
BER is available, that is, there is no data transmitted in the UL thus only DPCCH is transmitted.
Section 4 � Module 1 � Page 36
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 36
Module Summary
� This lesson covered the following topics:
� Measurements principles
� Main measurements purpose and use
� NBAP measurement process and parameters
� RRC measurement process and parameters
� In-Band measurement process and parameters
Section 4 � Module 1 � Page 37
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 37
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 4 � Module 1 � Page 38
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMeasurements �
4 � 1 � 38
End of Module
Section 5 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
5�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 5Call Admission
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 5 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 2
Blank Page
This page is left blank intentionally
Update for UA7:• QQualMin CAC on RACH updated• RRC 3G-2G redirection based on cell load• Initial Rate Capping• FACH Power Control as the type of DL traffic
Chatila, RayanRyser, SigridCharneau, Jean-Noel
2010-04-1501
RemarksAuthorDateEdition
Document History
Section 5 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Describe call establishment and associated parameters
� Describe RAB Matching and associated parameters
� Describe IRM RAB to RB Mapping and associated parameters
� Describe CAC and associated parameters
� Describe CELL_FACH admission and associated parameters
Section 5 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 5 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 5
Table of Contents
Switch to notes view!Page
1 Paging 71.1 Paging DRX Cycle 81.2 Paging Repetition 9
2 Access Preambles & Acknowledgment 102.1 Preambles Transmission 112.2 Acknowledgement Transmission 122.3 Preambles Retransmission Parameters 13
3 RRC Connection Establishment 143.1 RRC Connection Setup 153.2 UL Interference CAC on RACH 163.3 3G-2G Redirection based on cell load 173.4 RRC Connection Rejection 183.5 RRC Speech Redirection 193.5.1 RRC Speech Redirection based on cell load 203.5.1.1 Conditions 21
3.6 FACH Power Control as the type of DL traffic 223.6.1 FACH Power Adjustment 233.6.2 RRC Connection Setup Repetition 24
4 RAB Matching Principles 254.1 RAB Request vs. UserServices Configuration 264.2 Matching Main Steps 27
5 RAB to RBset Matching & TrCH Type Selection 285.1 Candidate RBset Selection 295.2 Candidate RBset Selection Algorithm: Speech 305.3 Candidate RBset Selection Algorithm : Streaming 315.4 Candidate RBset Selection Algorithm: Interact./Backgr. 325.5 TrCH Type Selection 33
6 iRM CAC : Target RAB Determination 346.1 iRM Selection 356.2 DL IRM Target RB Selection Algorithm 366.3 DL iRM on Radio Link Condition 376.4 DL iRM on Cell Color 386.5 DL Cell Color Calculation 396.6 DL Cell Color/Active Set Color Calculation 406.7 DL Target RB Determination 416.8 DL iRM CEM load parameters 426.9 DL iRM table: example for PS_384K_IB Radio Bearer 436.10 DL iRM : Exercise 446.11 UL iRM Principle 476.12 UL IRM Target RB Selection Algorithm 486.13 UL Radio Load Estimation Without RSEPS 496.13.1 Self-Learning of RTWPref 506.13.2 Calculation in NodeB 516.13.3 Calculation in RNC 52
6.14 UL Load Estimation With RSEPS : Calculation in RNC 536.15 UL IRM on Cell Color 546.16 UL Cell Color Calculation 556.17 iRM Target UL RB Rate determination 566.18 UL iRM Radio load parameters 576.19 UL iRM CEM load parameters 586.20 UL iRM table parameters 596.21 UL CAC Principle: non E-DCH Radio Bearer 606.22 Exercise : iRM UL 616.23 iRM CAC for PS Streaming RAB 64
7 iRM CAC : Admission Control & Resource Reservation 65
Section 5 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 6
Table of Contents [cont.]
Switch to notes view!Page
7.1 UL Radio Load Control 667.2 Transport Resource Reservation 677.3 AAL2 Call Admission Control 687.4 IRM and AAL2 CAC Replay at RB Upgrade or AON Upsize 697.5 DL Reserved Power Computation 707.6 DL Power Admission Criteria 717.7 DL Power Self Tuning 727.7.1 Example 73
7.8 OVSF Codes Reservation & Admission 748 CELL_FACH Admission Control 758.1 CELL_FACH Admission Control 76
Section 5 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 7
1 Paging
Section 5 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 8
1 Paging
1.1 Paging DRX Cycle
Paging for Packet callPaging for Circuit call
DRX
Slot #0 Slot #1 PICH Slot #14
UE
Node B
FDDCell
psDrxCynLngCoef
csDrxCynLngCoef
Slot #0 Slot #1 Slot #14
Slot #0 Slot #1 Slot #14
Slot #0 Slot #1 Slot #14
Slot #0 Slot #1 Slot #14
Slot #0 Slot #1 PICH Slot #14
When camping normally on a cell, the UE monitors regularly the paging channel. In order to save some
energy, a discontinuous reception mode (DRX) is used.
The DRX cycle is defined as the individual time interval between monitoring Paging Occasion for a specific
UE. The UE needs only to monitor one Page Indicator (PI) in one Paging Occasion per DRX cycle.
The DRX cycle length is defined as MAX(2k, PBP), where:
� PBP is the Paging Block Periodicity and has the fixed value of 1 in UMTS-FDD.
� k is an integer and can be specific by Core Network domain.
The value of k is controlled in Alcatel-Lucent’s solution by two parameters, one by Core Network Domain:
csDrxCynLngCoef and psDrxCynLngCoef.
Since the UE may be attached to two different domains simultaneously, both DRX cycle length values are
calculated and stored in the UE from the values read in the SIB 1 (NAS system information, idle and
connected mode timers and counters). Then the UE should keep only the shortest of both values as the
DRX cycle length it will use.
Section 5 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 9
1 Paging
1.2 Paging Repetition
RNC
RRC Paging Type 1 (UEx, other UEs)
RRC Paging Type 1 (UEx, other UEs)
RRC Paging Type 1 (other UEs)
RRC Paging Type 1 (other UEs)
RRC Paging Type 1 (UEx, other UEs)
CoreNetwork
RANAP Paging (UEx)
UEx paging preempteddue to PCH overload (e.g.high paging offered load)
nrOfPagingRepetition
RRC Paging Type 1 (UEx, other UEs)
1st retransmission
Initial transmission
nth retransmission
last retransmission
FDDCellSCCPCHPCH
isPagingRepetitionAllowed
(RNC)
In area of poor radio coverage, it can happen that UE miss paging request what translates into the
subscriber missing terminating calls. In order to cope with radio transmission loss, the UTRAN can repeat
the paging request so as to increase the probability for the UE to hear it.
Paging repetition is applicable to mobile in idle, CELL_PCH or URA_PCH states.
Alcatel-Lucent implements two algorithms:
� Paging Record priority: When several paging records have to be sent at the same paging occasion, the
records are sent in the same RRC PAGING message. Nevertheless, if the number of records exceeds the
message size (i.e. more than 8 records), then the following priority will apply:
� Priority 1: fresh paging record for packet or circuit services (i.e. no difference between the two
domains). A fresh paging record is a record which has not been previously sent.
� Priority 2: repeated paging record for packet or circuit services (no difference between the two
domains).
� Limitation of repetitions: nrOfPagingRepetition is the number of time a paging record is repeated. This
is a customer configurable parameter.
nrOfPagingRepetition parameter: indicates the number of retransmissions of the paging by UTRAN. Specific
value 0 means that the paging will not be repeated (only the “fresh” paging is sent).
Section 5 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 10
2 Access Preambles & Acknowledgment
Section 5 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 11
2 Access Preambles & Acknowledgment
2.1 Preambles Transmission
PRACHPRACH
prachScramblingCodeprachScramblingCodePreamble
rachsubChannel2
preambleThreshold Preambledetection
RACH preambleThreshold Preambledetection
RACH preambleThreshold Preambledetection
Interference level
RACHno
detection
33
Preamble PartWait for Ack ...
Preamble Part
preambleSignature11
Wait for Ack ...Wait for Ack ...
aichTransmissionTiming
55
Ack.
4
Ack.Ack.
4
Message partMessage part
66
AS 0 AS 1 AS 2 AS15AS 0 AS 1 AS 2 AS15
PRACH
FDDCellRACHdetection
UE PRACH use is composed of two parts: the preamble part and the message part. Before transmitting the message part of the preamble, the UE waits for an acknowledgement from the network (on the AICH), confirming that the network has detected the UE.
The transmission of the preamble part consists of the repetition of a preamble composed of a 16-chip signature repeated 256 times for a total of 4096 chips.
Basically, the UE is assigned one of the 16 possible preambles signature and transmits it at increasing power until it gets a response from the network. The parameter preambleSignature of the RACH object, defines the set of allowed signatures of the PRACH preamble part.
The parameter preambleThreshold is defined as the threshold (in dB) over the interference level used for
preamble detection in the CEM card. (The real value in dB of the preamble threshold is given by the
formula: -36+0.5*preambleThreshold.)
The parameter rachSubChannels defines the set of access slots on which the mobiles are authorized to transmit their access on the PRACH. It defines a sub-set of the total set of uplink access slots.
The aichTransmissionTiming parameter of the RACH object defines the timing relation between PRACH and AICH channels.
The scrambling code of the PRACH preamble part is defined by the prachScramblingCode parameter of the RACH object.
Note: The RACH preambleSignature is limited to 1 signature for iCEM128. The allowed signature will be
0000000000000001 or 1000000000000000 or 0000000100000000…
Section 5 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 12
2 Access Preambles & Acknowledgment
2.2 Acknowledgement Transmission
PreamblePreamble
Preamble PRACH
aichTransmissionTiming = 0
Transmission of AICH may only start at the beginning of a DL AS
Transmission of UL RACH preambles and RACH message parts may only start at the beginning of an UL AS
PRACH
AICH3 TS
3 AS 3 AS
Downlink
AICH
Uplink
PRACH
aichTransmissionTiming = 1
Downlink
AICH
Uplink
PRACH
Preamble
AICH
4 AS 4 AS
5 TS
RACH
The aichTransmissionTiming parameter of the RACH object defines the timing relation between PRACH and
AICH channels.
For example when aichTransmissionTiming is set to 1:
� The minimum inter-preamble distance tp-p,min = 20480 chips (4 access slots)
� The preamble-to-AI distance tpa = 12800 chips (5 time slots)
� The preamble-to-message distance tp-m = 20480 chips (4 access slots)
Note: only aichTransmissionTiming = 1 is supported for iBTS (Global Market) and aichTransmissionTiming= 0 is supported for OneBTS (US Market).
Section 5 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 13
2 Access Preambles & Acknowledgment
2.3 Preambles Retransmission Parameters
PREAMBLE #1
PREAMBLE #2
PREAMBLE #N
NB01min (RachTxParameters)
NB01max (RachTxParameters)
Access Cycle #1
Access Cycle #2
preambleRetransMax (RACH)
Mmax (RachTxParameters)
PREAMBLE #1
PREAMBLE #N
When a negative answer is received by the UE from the network after a given period, the UE re-sends a
preamble at a higher transmission power, so that the Node B can detect it better among the other
information received. This “ramping up” process is thus characterized by:
� Periodicity of the preamble retransmission: 3GPP (cf. 25.321) has defined two parameters: NB01min
and NB01max, setting respectively the lower and the upper bounds of the retransmission periodicity
(unit is expressed in tens of ms).
� Maximum number of preambles transmitted: this limitation is defined through preambleRetransMax and
Mmax parameters.
� preambleRetransMax gives the maximum number of PRACH time slots allowed within an access cycle.
� Mmax gives the maximum number of access cycles. An access cycle is defined by a number of radio
frames on which the PRACH access (and therefore a preamble ramping cycle) is allowed on specific
slot numbers.
The ramping process stops when the number of preambles transmitted has reached the maximum allowed
number of PRACH retransmissions, either within an access cycle, or when the maximum number of access
cycles is reached.
Section 5 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 14
3 RRC Connection Establishment
Section 5 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 15
3 RRC Connection Establishment
3.1 RRC Connection Setup
RRC Con
nection
Request
(Cause)
RNC
RB = ???
DlUserService UlUserService UlRbSetConfDlRbSetConf ServiceInit
RadioAccessService
UserServices
Node B
When the UE attempt to establish an RRC Connection is accepted, the corresponding Signaling Radio
Bearers can be supported on two different RRC states and with two different throughputs:
� CELL_FACH
� CELL_DCH
The parameters which allow selection of the RRC state to support the Signaling Radio Bearers are
UlUserviceId for the UL direction, and DlUserserviceId for the DL direction.
The selection of the SRB xxServiceId to accommodate the RRC connection is distinguished by RRC
establishment Cause (UserServices instance):
� IMSI Detach, Registration, Originating Low Priority Signaling, Originating Low Priority Signaling:
SRB_CellFACH
� Emergency Call: SRB_3_4K_DCH
� Others (normal Originating and Terminating calls): SRB_13_6K_DCH
Section 5 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 16
3 RRC Connection Establishment
3.2 UL Interference CAC on RACH
Interference level
Eb/No required
Received Power
UL RTWP
RNC
NBAP Common measurement report
(RTWP)
P-RACH
RTWP < Maximum UL Interference Level
Yes No
Call is accepted Call is rejected
cacConfId (FDDCell) maxUlInterferenceLevel (CacConfClass)
The overall interference level received in a cell is measured with the UL RTWP measurement (Received
Total Wideband Power measured at the Node B and forwarded to the RNC).
On RACH reception, before the allocation of the standalone signaling radio bearer, and during the resource
reservation phase, the RNC compares the measured RTWP with a fixed value, the
maxULInterferenceLevel parameter.
� If the RTWP is below this threshold, the criterion is met.
� If the RTWP is over the threshold the call is rejected.
The RTWP is measured by the Node B and sent towards the RNC by sending a “NBAP common measurement
report”.
Section 5 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 17
3 RRC Connection Establishment
3.3 3G-2G Redirection based on cell load
2G
FDD
Speech Call
is3G2GRedirectOnCellLoadAllowed
(FDDCell)
Code Color
Power Color
Iub Color
CEM Color
Worst DL Cell Color
UL RTWP Load Color
CEM Color
Worst UL Cell Color
Worst
is3G2GRedirectOnCellLoadAllowedForEmergency
(RadioAccessService)
FDD Originating Cell Load
From UA7 onwards this feature enables 3G/2G RRC redirection of CS Speech calls when the cell load on the
originating UMTS cell reaches a configurable threshold.
Calls are rejected and redirected to GSM.
Mobile then selects a GSM cell based on previously measured neighbouring cell list and retries a call
establishment.
This mechanism allows offloading 3G traffic to 2G before reaching CAC failure.
Compared to Load based Handover, this procedure does not consume any 3G resources.
Section 5 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 18
3 RRC Connection Establishment
3.4 RRC Connection Rejection
RRC Connection Request
RRC Connection Rejected (cause)
RRC Connection Request
RNC rejects the UE requests
waitTime parameter before UE re-attempt
RNC
timeReject
(Overload)
waitTimeOnRrcConnectionRejection
(ServiceInit)
waitTime3Gto2GRedirectFailure
(FDDCell)
SRB CACUL RTWP >=
Maximum UL Interference LevelRNC
OverloadCell load >=
Cell Load Threshold
If RRC connection fails, the UE will re-attempt a 3G call establishment up to N300 times. However, the UE
is required to wait (at least) a predetermined time before the subsequent attempt on the 3G network.
This wait time is sent by the RNC to the UE in the Wait Time IE in the RRC Connection Reject message.
Subsequent call attempts may or may not be redirected to the 2G network, depending on whether the
initial cause for RRC Redirection still persists on the 3G UTRAN.
The Wait Time parameter will be set to the value associated with one of the following parameters:
� timeReject. If the admission failure which causes the redirection is “RNC overload”
� waitTimeOnRrcConnectionRejection. If the admission failure which causes the redirection is
“congestion”
� waitTime3Gto2GRedirectFailure. In the case of a “3G-2G Emergency Redirection” or “3G-2G
Redirection based on cell load”
The parameter waitTimeOnRrcConnectionRejection is in seconds and the value 0 indicates that therepetition is not allowed.
Section 5 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 19
3 RRC Connection Establishment
3.5 RRC Speech Redirection
RRC Connection Request
RRC Connection Rejected (cause)
Redirection IE (Inter-RAT info = GSM)
is3Gto2GConversationalCallRedirectOnRrcEstabFailAllowed (RadioAccessService)
is3Gto2GRedirectForEmergencyAllowed (FDDCell)
RNC
UL Interference CAC Rejection
RNC Overload SRB CAC Rejection
IF
RRC Establishment Cause = MO Conversational AND
is3Gto2GConversationalCallRedirectOnRrcEstabFailAllowed = TRUE
OR
RRC Establishment Cause = Emergency AND
is3Gto2GRedirectForEmergencyAllowed = TRUE
AND
2G neighbor configured
THEN
include Redirection IE in RRC Connection Rejection message
WaitTime3GTo2GRedirectFailure(FDDCell)
Upon reception of the RRC Connection Request message, the RNC executes the usual RRC Connection
Admission Controls.
If failure occurs for SRB assignment, the RNC verifies that some pre-conditions for redirection to GSM are
fulfilled.
� Then the RRC Connection Reject message contains the Redirection IE with Inter-RAT info set to “GSM”.
Note that the RNC is unaware of the UE capabilities at RRC Connection Request time. Therefore, the
RNC attempts an RRC Redirection independently of whether the UE supports GSM or the Redirection IE.
If the UE supports GSM and the Redirection IE, it will perform inter-system cell reselection and will re-
originate the speech call on the 2G network.
All types of MO Conversational calls are redirected to 2G upon admission failure independently of the
service type or domain. This includes non-speech calls such as Video Telephony. This is a consequence of
the fact that the RRC establishment cause is not able to uniquely identify a CS speech at this early stage
of the call progression.
Redirection is not triggered if the UE already has an established RRC connection prior to invoking the MO
call request (for example when a PS call is already established).
Section 5 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 20
3.5 RRC Speech Redirection
3.5.1 RRC Speech Redirection based on cell load
RRC/RACH (RRC Connection Request)
RRC/FACH (RRC Connection Reject)
Wait time
Inter-RAT info=“GSM”
GSM Target cell info list (1 to 32 Cells)
BCCH ARFCN
Band Indicator
Rejection Cause: ‘congestion’
RNC
isGsmTargetInfoListIeAllowed (RadioAccessService / ServiceInit)
WaitTime3GTo2GRedirectFailure(FDDCell)
IF
RRC Establishment Cause = MO Conversational AND
is3G2GRedirectOnCellLoadAllowed = TRUE
OR
RRC Establishment Cause = Emergency AND
is3G2GRedirectOnCellLoadAllowedForEmergency = TRUE
AND
other conditions are fulfilled
THEN
include Redirection IE in RRC Connection Rejection
message
The RRC Connection Request initiated by the UE contains the establishment cause.
The other conditions that must be fulfilled are explained on the next slide.
If the call is eligible to to the 3G2G redrection criterion a RRC Connection Reject is sent to the UE with
redirection info included which may include the GSM target cell info list IE.
The RNC always send the GSM target cell Info List whatever UE release (R99, R5, R6, R7)
Section 5 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 21
3.5.1 RRC Speech Redirection based on cell load
3.5.1.1 Conditions
Yes
First RRC Connection Request (1st RACH)
AND
( Call Type IE = CS Speech (R6 UE)
or
is3g2gRedirectOnCellLoadAllowedForR99andR5 = True (up to R5 UE) )
AND
Establishment Cause = Originating Conversational or Emergency Call
is3G2GRedirectOnCellLoadAllowed
= True ?
Neighboring GSM Cell Defined ?
Originating Cell Load Color equal or
worse than
redirection3G2GOnCellLoadThreshold ?
Yes
Yes
is3g2gRedirectOnCellLoadAllowedForR99andR5
3G-2G RedirectionTriggered
Yes
redirection3G2GOnCellLoadThreshold
is3g2gRedirectOnCellLoadAllowedForR99andR5
(FDDCell)
is3G2GRedirectOnCellLoadAllowed
redirection3G2GOnCellLoadThreshold
For R5 & R99 Mobiles, no differentiation in the RRC Connection IE between video & voice thus: risk to move video call on 2G is to be considered.
Upon receiving the RRC Connection Reject messagefrom UTRAN, the UE will process GSM cell selection
process using or not the GSM target cell info and will attempt a RACH on 2G if it finds an eligible GSM
target cell.
If no GSM cell fulfills the selection criteria, the UE will re-attempt a new RACH towards the UTRAN after
the “wait time” timer (waitTime3Gto2GRedirectFailure) has elapsed. The UE may camp on the same Fdd cell or another Fdd cell (the cell reselection process may change the Fdd cell).
When the re-attempt occurs in the same FDDCell within a certain period of time (RrcCnxRepeatTime),
the RNC doesn’t redirect the call to the 2g and attempts to establish the call on the FDDCell thanks to a
mechanism (already used for all features dealing with RRC Redirection) at cell level which registers the
UE identity before launching the 3G2G redirection. If the re-attempt occurs after the timer elapses or in
a different FDDCell, the RACH is managed as a first RRC establishment request.
2G load is not taken into account to take the decision to trigger the redirection.
Section 5 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 22
3 RRC Connection Establishment
3.6 FACH Power Control as the type of DL traffic
UE in Cell_FACH
RLC/MAC blocks (DATA)
PWR
FACH
RLC/MAC blocks (SIGNALING)
PWR
FACH
FACH / S-C
CPCHRLC/
MAC block
s (DATA)
FACH / S-C
CPCHRLC/
MAC block
s (SIGNALI
NG)
isFachPowerDifferentForSrbtraffic
(RadioAccessService)= True
fachSrbPowerOffset(FACH)
fachTrbPowerOffset(FACH)
The feature differentiates the power level used for FACH channel depending on whether data or signalling
is transmitted.
From UA7 a Boolean switch allows choosing between the two alternative approaches.
It is possible for 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 signalling and traffic on FACH (UA05 onwards mechanism called FACH Power Adjustment and Quick
Repeat).
• Configurable fixed (different) power level based on whether the FACH frame contains Signalling Radio
Bearer data or Traffic Radio Bearer data (new option from UA7)
isFACHpowerdifferentForSRBtraffic allows to enable/disable the use of the configured fixed power offset based on whether the Radio Bearer is Signalling 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 fachSrbPowerOffset or TRB fachTrbPowerOffset are used.
Section 5 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 23
3.6 FACH Power Control as the type of DL traffic
3.6.1 FACH Power Adjustment
isFachPowerAdjustmentEnabled (CallAccessPerformanceConf)
isFachPowerAdjustmentActivated (FDDCell)
Feature Activation maxFachPowerRelativeToPcpich (FACH)
initialFachPowerAdjustment
fachTransmitPowerLevelStep
fachPowerAdjustmentCpichEcNoThreshold
fachPowerAdjustmentCpichRscpThreshold
Feature Parameters (FachPowerAdjustmentParams)
second RRC Connection
Setup
third RRC Connection
Setupfirst RRC Connection
SetupP-CPICH all other FACH
messages
Maximum FACHpower
sccpchPowerRelativeToPcpich (SCCPCH)
isFachPowerDifferentForSrbtraffic = False
It is proposed to adjust the FACH power while sending the RRC Connection Setup message based on the
CPICH Ec/No measurement received from the RRC Connection Request message. The preferred power
setting change is only applied to the FACH frames which carry RRC Connection Setup message. For other
messages, RNC should set the power setting level to the nominal value.
Once the FACH power adjustment is required for the first RRC Connection Setup, at every next subsequent
repetitions (that is, T351 expiration), the FACH power is further stepped up.
The feature is activated both at the RNC (isFachPowerAdjustmentEnabled) and FddCell level
(isFachPowerAdjustmentActivated).
If the quality measurements of either Ec/No (by default) or RSCP is below the threshold, the FACH power
adjustment will be performed.
Note: the parameter fachPowerAdjustmentCpichRscpThreshold (FachPowerAdjustmentParams Object) is not used by the RNC, since RSCP measurements are not reported in RACH messages
Section 5 � Module 1 � Page 24
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 24
3.6 FACH Power Control as the type of DL traffic
3.6.2 RRC Connection Setup Repetition
UE RNC-IN RNC-CN
RRC Connection Request (TM) (CPICH Ec/No)
RRC Connection SetupRRC Connection Setup (UM)
RRC Connection Setup Complete (AM)
RRC Connection Setup (UM) RRC Connection Setup
RRC Connection Setup (UM) RRC Connection Setup
RRC Connection Setup (UM) RRC Connection Setup
t351
t351
Control of RRC Connection Complete
t351n351
t352
(CallAccessPerformanceConf)
Quick Repeat (CallAccessPerformanceConf)
isQuickPepeatActivated (FDDCell)
isQuickPepeatAllowednumberOfQuickRepeat
deltaCpichEcNoUsedQuickRepeatdeltaCpichRscpUsedQuickRepeat
t300
t352
Control of RRC Connection Setup
t300
(UeTimerCstIdleMode)
The RRC Connection Setup message is sent over CCCH/FACH in RLC UM mode. Without its retransmission,
the message could be lost over the air due to bad RF conditions. The objective of this feature is to
provide the RRC Connection Setup message retransmission functionality if RRC Connection Setup
Complete message from the UE has not been received within the duration of T351 timer.
The retransmission of RRC Connection Setup message based on a quicker timer T351 than T300 reduces the
call setup duration. 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 has a positive impact to the RACH capacity.
This feature provides quick repetition functionality of the RRC Connection Setup message without waiting
for the acknowledgement from the UE (RRC Connection Setup Complete message).
The quick repetition of the RRC Connection Setup is activated based on the P-CPICH Ec/No measurement
received from the RRC Connection Request message reported by the UE. If quality measurements are
below a certain threshold, the likelihood of high BLER on the FACH channel is increased, thus reducing
the probability of RRC Connection Setup being successfully received by the UE, since it is sent on RLC UM.
In order to increase the probability of successful RRC Connection Setup transmission, the message is
quick-repeated, that is to say, without waiting for an acknowledgement.
Note: the parameter deltaCpichRscpUsedQuickRepeat (CallAccessPerformanceConf Object) is not used by the RNC, since RSCP measurements are not reported in RACH messages
Section 5 � Module 1 � Page 25
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 25
4 RAB Matching Principles
Section 5 � Module 1 � Page 26
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 26
4 RAB Matching Principles
4.1 RAB Request vs. UserServices Configuration
Service
Request
RNC Core NetworkService Request
RAB Assignment RequestRB = ???
DlUserService UlUserService UlRbSetConfDlRbSetConf ServiceInit
RadioAccessService
UserServices
Several Access Stratum configurations are supported.
They are split between downlink and uplink and may be dissymmetric.
At the RNC, each access stratum configuration is identified by an access stratum configuration Identifier or
UserServiceId. This identifier characterizes a set of radio bearers that are linked through a common radio
configuration, including therefore a signaling radio bearer (SRB) and a set of traffic Radio Bearers (RBs).
The objective of the RAB matching algorithm is to translate the RAB parameters specified in the RAB
ASSIGNMENT REQUEST received from the Core Network into a pre-defined RAB supported in the RNC.
The requested RAB is matched to the closest RAB provisioned in RNC, using the RAB matching algorithm.
Section 5 � Module 1 � Page 27
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 27
4 RAB Matching Principles
4.2 Matching Main Steps
UE Capability Establishment CauseRequested RAB
Candidate RBSet Selection
UE Capability Check
TrCH Type Selection
IRM Selection (DL)
RBSet List Construction
UserServices Matching
UE Capability Check
Target UserServices
RAB to RBset Matching
RBset to UserServices Matching
Reference UserServices
IRM Selection (UL)
RAB Matching is done at call establishment. For soft handover, only resource reservation and Call Access
Control are performed.
The above diagram describes the main steps of the RAB Matching algorithm used.
Step 1: RAB to RBset Matching:
� UL & DL RBs are selected according to the RAB Request and stored in a RB set.
� this RB list is filtered according to UE capabilities.
Step 2: Transport Channel Type Selection:
� DCH or HDSCH in DL, DCH or E-DCH in UL is selected according to the UE and cell capabilities
Step 3: iRM RAB to RB Mapping (DL only):
� a DL Target RB is elected among all the selected RBs of the RBset.
Step 4: RBset to User Services Matching:
� Target User Services are extracted and explicitly defined from the RBsets.
� Reference User Services are extracted and explicitly defined from the RBsets.
Section 5 � Module 1 � Page 28
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 28
5 RAB to RBset Matching & TrCH Type Selection
Section 5 � Module 1 � Page 29
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 29
5 RAB to RBset Matching
5.1 Candidate RBset Selection
UL Candidate RBsetDL Candidate RBset
Core Network
RAB Assignment Request
• Maximum Bit Rate• Guaranteed Bit Rate• UMTS Traffic Class• A/R Priority Level• ...
enabledForRABMatching (DlRbSetConf)
enabledForRABMatching (UlRbSetConf)
RNC
UlRbSetConfDlRbSetConf
RadioAccessService
Candidate RBset Selection
DL Reference RB UL Reference RB
enableRabNegotiation
(RadioAccessService)
The Purpose of this algorithm is to get as output a radio bearer table containing all the acceptable Radio
Bearers (DL Candidate RBset and UL Candidate RBset), among which one is marked as the Reference RB in
Ul & DL. These RBsets also include the RBs to be used for Always On and iRM Scheduling (when
applicable).
From all Radio Bearers defined in the RNC, the RNC selects the Radio Bearers (DlRbSetConf and
UlRbSetConf) having the following properties:
� It is eligible for RbSet Matching (enabledForRabMatching).
� The Traffic Class corresponds to the requested Traffic Class.
� The Bit Rate is compliant with the RBset selection criteria (see next slide).
For PS Calls, the rule is to sort all eligible radio bearers in decreasing bit rate order, and to select the
reference radio bearer as being the first element in the top of the list.
Other radio bearers are kept as fallback radio bearers.
From UA06.0 RAB negotiation may be supported at establishment time. If the flag enableRabNegotiation is set to True, the presence of the Alternative RAB Parameter Values IE is checked in the RANAP RAB
ASSIGNMENT [3GPP_R18] or RELOCATION REQUEST message and if present with either Alternative MBR or
Alternative GBR then negotiation the Maximum Bit Rate or Guaranteed Bit Rate (Streaming class)
respectively is allowed.
RAB matching and call admission is performed as normal and if the requested rate is not achievable a lower
data rate may be selected. This is applicable to both Interactive/Background and Streaming RABs.
Note: The activation flag enableRabNegotiation shall be set to True only if the SGSNs in the CN support the RAB negotiation facility with the Unspecified Type of Alternative Bit Rate.
Section 5 � Module 1 � Page 30
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 30
5 RAB to RBset Matching
5.2 Candidate RBset Selection Algorithm: Speech
RAB Assignment Request
• Maximum Bit Rate• Guaranteed Bit Rate• UMTS Traffic Class• A/R Priority Level• ...
Bit Rate (RbSetConf)=
Maximum Bit Rate (RAB Assignment Request )
Bit Rate (RbSetConf)≥
Guaranteed Bit Rate (RAB Assignment Request)
Candidate RBset Selection
TC =Conversational
Source=Speech
UL Candidate RbSetDL Candidate RbSet
If AMR Multi Mode Allowed
CS_AMR_WB:{12.65k, 8.85k, 6.6k}
CS_AMR_NB:{12.2k, 7.95k, 5.9k, 4.75k}{12.2k, 7.4k, 5.9k, 4.75k}
CS_AMR_LR:{5.9k, 4.75k}{4.75k}
The allocation of bearer for voice call depends if the multi-mode AMR is activated at RNC level:
If Traffic Class = Conversational and Source = Speech (Speech case)
� Bit Rate (RbSetConf) = MaxBitRate (rabParam)
� Bit Rate (RbSetConf) ≥ Guaranteed Bit Rate (rabParam)
The RNC shall determine the speech bearer according to the AMR activated modes:
� CS_AMR_WB: • CS_AMR_NB: • CS_AMR_LR
� {12.65k, 8.85k, 6.6k} o {12.2k, 7.95k, 5.9k, 4.75k} o {5.9k, 4.75k}
o {12.2k, 7.4k, 5.9k, 4.75k} o {4.75k}
The following table shows an example of the CS Radio Bearer Table:
Section 5 � Module 1 � Page 31
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 31
5 RAB to RBset Matching
5.3 Candidate RBset Selection Algorithm : Streaming
RAB Assignment Request
• Maximum Bit Rate• Guaranteed Bit Rate• UMTS Traffic Class• A/R Priority Level• ...
Candidate RBset Selection
Traffic Class=
Streaming
Bit Rate (RbSetConf)≥
Guaranteed Bit Rate (RAB Assignment Request)
PS_16K_STR
PS_64K_STR
PS_128K_STR
PS_256K_STR
PS_384K_STR
DCH
DL Candidate RbSet
PS_HSDSCH_STR
HSDPA
PS_16K_STR
PS_32K_STR
PS_64K_STR
PS_128K_STR
DCH
UL Candidate RbSet
PS_EDCH_STR
HSDPA
The following table shows an example of the Streaming Radio Bearer Table
Note: Streaming over EDCH is an optional feature/service supported starting release UA7.1.2
Section 5 � Module 1 � Page 32
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 32
5 RAB to RBset Matching
5.4 Candidate RBset Selection Algorithm: Interact./Backgr.
RAB Assignment Request
• Maximum Bit Rate• Guaranteed Bit Rate• UMTS Traffic Class• A/R Priority Level• ...
Traffic Class=
Interactive/Background
Bit Rate (RbSetConf)≤
Maximum Bit Rate (RAB Assignment Request)
Candidate RBset Selection
UL Candidate RbSet
DL Candidate RbSet
Example
• CS MaxBitRate = 12.2k• PS MaxBitRate DL = 2048K• PS MaxBitRate UL = 384K• CS Speech + PS I/B• A/R Priority Level = 2• ...
Candidate RBset SelectionDL Candidate RbSet
PS 384K (Ref.)PS 256K PS 128KPS 64KPS 32KPS 16KPS 8KCS 12.2k (Ref.)
UL Candidate RbSet
PS 384K PS 128K (Ref.)PS 64KPS 32KPS 16KPS 8KCS 12.2k (Ref.)
UE Capability Check*
* If isUeCapabilitiesInRabMatchingAllowed = True
(RadioAccessService)
DCH
DCH
From all Radio Bearers defined in the RNC, the RNC selected the Radio Bearers (DlRbSetConf and
UlRbSetConf) having the following properties:
� It is eligible to RbSet Matching (Parameter EnabledForRabMatching)
� The Traffic Class corresponds to the requested Traffic Class and:
� If Traffic Class = Conversational and Source = Speech (Speech case)
� Bit Rate (RbSetConf) = MaxBitRate (rabParam)
� Bit Rate (RbSetConf) ≥ Guaranteed Bit Rate (rabParam)
� If Traffic Class = Streaming
� Bit Rate (RbSetConf) ≥ Guaranteed Bit Rate (rabParam)
� If Traffic Class = Interactive or Background
� Bit Rate (RbSetConf) ≤ MaxBitRate (rabParam)
The Candidate RBset Selection produces two Radio Bearers lists (one list for UL and one list for DL) that are
further filtered according to UE capability.
Section 5 � Module 1 � Page 33
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 33
5 RAB to RBset Matching
5.5 TrCH Type Selection
� Based on UE Category, not based on Core network info
Cell
UER’99 R5 R6
Conv. DCH Conv. DCH Conv. DCH
STR DCH STR DCH STR DCH
I/B DCH I/B DCH I/B DCH
Conv. DCH Conv. DCH Conv. DCH
STR DCH STRHS-DSCH
DCHSTR
HS-DSCH
DCH
I/B DCH I/BHS-DSCH
DCHI/B
HS-DSCH
DCH
Conv. DCH Conv. DCH Conv. DCH
STR DCH STRHS-DSCH
DCHSTR
HS-DSCH
E-DCH
I/B DCH I/BHS-DSCH
DCHI/B
HS-DSCH
E-DCH
R’99
R5
R6
This step aims to perform the transport choice decision:
� DCH,
� HSxPA,
� FACH.
The decision is taken according to several rules:
� CS RAB is always established on a DCH Channel;
� For a R5 or R6 UE (HSDPA capable), the downlink PS I/B RB is preferred on HSDPA;
� the downlink PS Streaming RB is preferred on HSDPA if streaming on HSDPA is activated;
� For a R6 UE (HSUPA capable), the uplink PS I/B RB is preferred on HSUPA;
� the uplink PS Streaming RB is preferred on HSUPA if streaming on HSUPA is activated;
Note: Streaming over EDCH is an optional feature/service supported starting release UA7.1.2
Section 5 � Module 1 � Page 34
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 34
6 iRM CAC : Target RAB Determination
Section 5 � Module 1 � Page 35
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 35
6 iRM CAC : Target RAB Determination
6.1 iRM Selection
RAB to RBset Matching (UL/DL)
DL iRM
RBset to UserServices Matching (UL/DL)
Resource Reservation&
Admission Control
Reference UL bit rate
iRM Target UL RB bit rate
Target RAB (DL/UL)
Reference DL bit rate
iRM Target DL RB bit rate
UL iRM
UL bit rate limitation
If Max UL RB bit rate > Target UL RB bit rate
Then Initial UL RB bit rate = Target UL RB bit rate
Else Initial UL RB bit rate = Max UL RB bit rate
DL bit rate limitation
If Max DL RB bit rate > Target DL RB bit rate
Then Initial DL RB bit rate = Target DL RB bit rate
Else Initial DL RB bit rate = Max DL RB bit rate
iRM Tables
Requested RAB
isUlRbRateAdaptationAllowed(RadioAccessService)
maxUlEstablishmentRbRate(CacConfClass)
isOamCappingOfDataAllowed(RadioAccessService)
maxUlRateRabEstablishDchAndDch (DchRateCapping)
isDlRbRateAdaptationAllowed(RadioAccessService)
maxDlEstablishmentRbRate(CacConfClass)
isOamCappingOfDataAllowed(RadioAccessService)
maxUlRateRabEstablishDchAndDch(DchRateCapping)
According to the cell load (DL and UL) and radio conditions of the UE (DL only), from a Reference RB bit
rate deduced from CN QoS requirements, the RNC will determine, in UL and in DL, a Target RB bit rate in
order to avoid congestion in the cell.
� iRM UL and iRM DL Tables are used for Target RB determination according to some criteria (see slides
after)
Besides, RB adaptation based on traffic is a feature introducing PS I/B RB bit rate downsizing/upsizing
based on user estimated average throughput.
� DL and UL rate adaptation are performed independently.
In UL and/or DL an initial RB Rate Adaptation can be performed at RAB establishment to admit a user at a
configurable low bit rate.
� Consequently the allocated UL PS RB bit rate and/or UL PS RB bit rate is limited at RAB
Establishment, even if the user is requesting more.
� Once the RAB established, it may be possible to upsize the RB to UL PS 384 kbps if needed thanks to
RB Adaptation.
� "Max UL RB bit rate" ("Max DL RB bit rate") specifies the maximum UL rate (DL rate), which may be
allocated at service establishment time (RANAP RAB Assignment Request) or after relocation (RANAP
Relocation Request).
� This parameter is significant when isUlRbRateAdaptationAllowed = True
(isDlRbRateAdaptationAllowed = True).
� It depends on the activation of feature "Initial Rate Capping during RB reconfiguration":
maxDlRateRabEstablishDchAndDchmaxDlEstablishmentRbRateMax DL RB bit rate =
Max UL RB bit rate = maxUlRateRabEstablishDchAndDchmaxUlEstablishmentRbRate
isOamCappingOfDataAllowed = TrueisOamCappingOfDataAllowed = False
Section 5 � Module 1 � Page 36
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 36
6 iRM CAC : Target RAB Determination
6.2 DL IRM Target RB Selection Algorithm
DL Cell Color
Code LoadPower Load
Iub LoadCEM Load
Radio Link Col
or
DL RL Quality
Olympic Service Level
DL Candidate RbSet
(Ref.)
DL Candidate RbSet
(Ref.)
(Target)
BronzeBronze
GoldGold
SilverSilver
DL IRM Tables
4
3
2
1
5
This step is applied only in the downlink.
The DL iRM Target RB selection algorithm is based on:
� UE radio conditions based on CPICH Ec/No and CPICH RSCP reported in the RRC Measurements that
indicates the radio conditions.
� The two colors Green and Red represent respectively good radio conditions and bad radio conditions.
� cell load through cell color computation from the downlink OVSF code tree occupancy, the downlink
power used versus the available power, the Iub load and the CEM processing load (D-BBU load).
� The three colors (green, yellow and red) are distinguished, green color meaning that the cell is not
loaded, and red color indicating a loaded cell.
� OLS (Olympic Service Level is either Gold or Silver or Bronze arrording to the Allocation/Retention
Priority IE provided in the RAB ASSIGNMENT REQUEST message).
Once computed, the target downlink radio bearer is flagged as Target Radio Bearer.
Section 5 � Module 1 � Page 37
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 37
6 iRM CAC : Target RAB Determination
6.3 DL iRM on Radio Link Condition
Bad RL Condition
Good RL Condition
Then
isIrmOnRlConditionAllowed(RadioAccessService)
Yes
Else
irmDlPowerThreshold (IrmOnRlConditionParameters)- CPICH_Ec/No <
If
irmDlCoverageThreshold (IrmOnRlConditionParameters)CPICH_RSCP >
And
No
?
dlRbSetConfId
(IrmOnRlConditionParameters)
cacConfId (FDDCell) cacConfId (FDDCell)
Good RL Condition
fallbackRbRate (DlRbSetConf)
iRM Target RB selection shall be limited to fallBackRbRate in case of bad UE radio conditions in order to
reduce RLC re-transmissions and guarantee a minimum level of throughput.
Radio Link conditions are assessed from RRC measurements reported by UE.
Link color calculation is based on the following algorithm:
� if (-CPICH Ec/N0 primary < IRMDlPowerThreshold) and (CPICH RSCP > IRMDlCoverageThreshold)
� then link color = GREEN
� else link color = RED
DL iRM Target RB bit rate shall be limited to fallBackRbRate if radio link color is RED, otherwise no
limitation is requested.
Note:
During transition from cell FACH state to Cell DCH state, CPICH RSCP is not reported by the UE, therefore:
� the coverage criterion (IrmDlCoverageThreshold) is ignored.
� the Radio link color evaluation is then based only on CPICH Ec/No measurements as reported on the last
RACH message.
Section 5 � Module 1 � Page 38
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 38
6 iRM CAC : Target RAB Determination
6.4 DL iRM on Cell Color
Specific CE capacity
Credit calculation andCE consumption laws
for xCEM
Code Color Power Color
FDDCell Color
DL IRM Tables
Yes
No? FDDCell Color = GreenisIrmOnCellColourAllowed
(RadioAccessService)
isDlIubTransportLoadColourCalculationEnabled(RadioAccessService)
bwPoolcellColor (EM/RncIn/Cm)iRMIubLoadQoS (IrmIubTransportLoadParameters)
?
DL Cell Color
YesNoIub Color = Green
NodeB Color
Iub Color CEM Color
isCEMColourCalculationEnabled(RadioAccessService) ?
Yes
NoCEM Color = Green
RAB allocation management is based on FDDcell color and NodeB color.
� FDDCell color is derived from a load calculation based on OVSF tree and DL power occupancy.
� NodeB color is derived from a Iub bandwidth occupancy and CEM processing load
Hence it provides means for a better management of cell resources.
At each allocation/release/reconfiguration of resources, the RNC calculates current:
� code color based on OVSF code tree occupancy load
� power color based on DL cell power usage
� Iub color based on VCC allocated on Iub
� CEM load based on credits usage
Then a composite Cell color is derived which is an input to iRM table.
� isDlIubTransportLoadColourCalculationEnabled activates or deactivates Computation of Downlink Iubload color and its aggregation in the global cell color.
� bwPoolCellColor controls whether Iub downlink usage will be included in cell color.
� iRMIubLoadQoS is a Bitmap of QoS to be taken in account for the iRM Iub Transport Load computation.
Bit i corresponds to QoS i. Value 1: QoS to be taken in account; Value 0: QoS not to be taken in account.
CEM load is not only used in iRM CAC algorithm. Therefore if CEM load criteria is not to be used in iRM CAC
although CEM load is being computed for iMCTA feature, then:
� isCEMColourCalculationEnabled parameter has to be set to TRUE
� isCEMModelValidForDlColour parameter has to be set to FALSE
� In this case the CEM Color used in iRM CAC will be equal to dlCEMColourDefaultValue parameter
value.
Section 5 � Module 1 � Page 39
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 39
6 iRM CAC : Target RAB Determination
6.5 DL Cell Color Calculation
green2YellowCLCThreshold(IrmOnCellColourParameters)
yellow2RedCLCThreshold(IrmOnCellColourParameters)
yellow2GreenCLCThreshold(IrmOnCellColourParameters)
red2YellowCLCThreshold(IrmOnCellColourParameters)
70 %
60 %
50 %
40 %
green2YellowPLCThreshold(IrmOnCellColourParameters)
yellow2RedPLCThreshold(IrmOnCellColourParameters)
yellow2GreenPLCThreshold(IrmOnCellColourParameters)
red2YellowPLCThreshold(IrmOnCellColourParameters)
70 %
60 %
50 %
40 %
green2YellowDlCEMThreshold(DlIrmCEMParameters)
yellow2RedDlCEMThreshold(DlIrmCEMParameters)
yellow2GreenDlCEMThreshold(DlIrmCEMParameters)
red2YellowDlCEMThreshold(DlIrmCEMParameters)
90 %
80 %
70 %
60 %
Power Load
CEM Load
Worst DL Cell Color
green2YellowDlTLCThreshold(IrmIubTransportLoadParameters)
yellow2RedDlTLCThreshold(IrmIubTransportLoadParameters)
yellow2GreenDlTLCThreshold(IrmIubTransportLoadParameters)
red2YellowDlTLCThreshold(IrmIubTransportLoadParameters)
90 %
80 %
70 %
60 %
Iub Load
Code Load
NOTE: The values provided here for the different Power load, Code load, Iub load and CEM load are just
examples. They are neither Alcatel-Lucent default values nor recommended values as those ones are
driven by the configuration of NodeB and cell and by the operator strategy as a trade-off between
capacity (number of simultaneous users) and quality (throughput for PS service).
Indeed:
� Code load thresholds setting is driven by the code capacity of the cell for DCH traffic which depends on
the number of S-CCPCH channels configured, on the fact that the cell might also carry HSDPA traffic,
and in that case on the Dynamic Code Tree Management feature activation.
� Power load thresholds setting is driven by the power capacity of the cell for DCH traffic which depends
on the usage of OCNS, and on the power reserved for HSDPA.
� Iub load thresholds setting is driven by the Iub bandwidth capacity of the BTS which depends on the
number of E1 links equipped, the IMA activation and the CAC method used.
� CEM load thresholds setting is driven by the CEM capacity of the BTS which depends on the type and
number of CEM boards equipped, on the number of Local Cell Group configured and on the DBBU
Frequency Pooling activation (dbbuPoolMode parameter).
CEM color in DL is calculated by the iRM mechanism comparing the DL CEM load estimation (expressed in
percent) with the different CEM DL load thresholds configured at OAM
Once computed, the CEM color is applied to all the cells of a BTS, cells belonging to the same Local Cell
Group.
Section 5 � Module 1 � Page 40
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 40
6 iRM CAC : Target RAB Determination
6.6 DL Cell Color/Active Set Color Calculation
Code Color
Power Color
Worst
Cell 1
Cell N
Worst
Active Set Color
Red
Green Yellow
+ =+ =+ =
Worst
Cell Color
Red
Green Yellow
Cell Color
Red
Green Yellow
Worst
Iub Color
Cell load color calculation
� This block allows code, power and Iub occupancy to be taken into account in the calculation of cell
color.
� The cell load color is calculated as follows:
� cell load color = Worst (radio load color, iub load color)
� radio load color = Worst (code load color, power load color)
Active set cell load color calculation
� When the call is in soft handover, the color taken into account is the active set color defined as the
worst color between the colors of the cells present in the active set. The active set load color is
calculated as follows:
� active set color = Worst (cell(i) color, i Є [1..N])
� where cell(i) is the cell of the active set and N is the active set size.
Section 5 � Module 1 � Page 41
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 41
6 iRM CAC : Target RAB Determination
6.7 DL Target RB Determination
Radio Link Col
or
BronzeBronze
GoldGold
SilverSilver
+
PSCore
SRNC
RAB Assignment Request Reference RB Bit Rate
iRMRbRate
DL Cell Color
OLS
fallBackRbRate MIN Target RB Bit Rate
Traffic classDL Maximum Bit RateAllocation/Retention Priority Level
The RAB to RB mapping function consists of defining the target RB Set that will replace the Reference RB.
For each triplet {DlRbSetConf, OLS, CellColor} an iRMRbRate parameter is defined in a DL iRM Table:
DL iRM RB Selection is choosing as Target RB bit rate the minimum between
� Reference RB bit rate deduced from CN requirements
� Eventual fallBackRbRate is UE in bad radio conditions
� iRMRbRate given by DL iRM Tables
64128384Bronze
64128384Silver
64128384Gold
Cell Colour = Red
Cell Colour
= Yellow
Cell Colour
= Green
DlIrmTable
OLS
64128384Bronze
64128384Silver
64128384Gold
Cell Colour = Red
Cell Colour
= Yellow
Cell Colour
= Green
DlIrmTable
OLS
PS_256K_IB
PS_ 256K_STR
PS_128k_IB
PS_128K_STR
PS_128k_IB_MUX
PS_384K_IB_MUX
PS_384K_IB
DlRbSetConfDlRbSetConf
PS_256K_IB
PS_ 256K_STR
PS_128k_IB
PS_128K_STR
PS_128k_IB_MUX
PS_384K_IB_MUX
PS_384K_IB
DlRbSetConfDlRbSetConf
Section 5 � Module 1 � Page 42
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 42
6 iRM CAC : Target RAB Determination
6.8 DL iRM CEM load parameters
defaultDlIrmCellColour
isCEMColourCalculationEnabled
iRMRbRate
green2YellowDlCEMThresholdyellow2RedDlCEMThresholdred2YellowDlCEMThreshold
yellow2GreenDlCEMThreshold
RNC
NodeB RadioAccessService
DedicatedConf DlIrmTableConfClass
IrmRbRateList
IrmRbRateEntry
1..15
3
3
DlIrmCEMParameters
nodeBConfClassId
1..15
isCEMModelValidForDlColourdlCEMColourDefaultValue
NodeBConfClass
dlIrmTableConfClassId
fallBackRbRate
DlRbSetConf
NeighbouringRnc
Section 5 � Module 1 � Page 43
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 43
6 iRM CAC : Target RAB Determination
6.9 DL iRM table: example for PS_384K_IB Radio Bearer
PS_256K_IB
PS_ 256K_STR
PS_128k_IB
PS_128K_STR
PS_128k_IB_MUX
PS_384K_IB_MUX
PS_384K_IB
DlRbSetConfDlRbSetConf
IrmRbRateEntry IrmRbRateList Instance
Instance iRMRbRate
0 OLS = Gold 384
1 OLS = Silver 384 /0 Cell Color = Green
2 OLS = Bronze 384
0 OLS = Gold 128
1 OLS = Silver 128 /1 Cell Color = Yellow
2 OLS = Bronze 128
0 OLS = Gold 64
1 OLS = Silver 64 /2 Cell Color = Red
2 OLS = Bronze 64
Section 5 � Module 1 � Page 44
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 44
6 iRM CAC : Target RAB Determination
6.10 DL iRM : Exercise
� Assumptions� hsdpaActivation (FDDCell) = False
� enabledForRabMatching (any DlRbSetConf) = True
� isIrmOnRlConditionAllowed (RadioAccessService) = True
� irmDlPowerThreshold (IrmOnRlConditionParameters) = 15dB
� irmDlCoverageThreshold (IrmOnRlConditionParameters) = -100dBm
� fallBackRbRate (PS_384K_IB) = 64kbps
� isIrmOnCellColourAllowed (RadioAccessService) = True
� green2YellowCLCThreshold (RadioAccessService) = 70%
� yellow2GreenCLCThreshold (RadioAccessService) = 60%
� yellow2RedCLCThreshold (RadioAccessService) = 90%
� red2YellowCLCThreshold (RadioAccessService) = 80%
� green2YellowPLCThreshold (RadioAccessService) = 60%
� yellow2GreenPLCThreshold (RadioAccessService) = 50%
� yellow2RedPCLCThreshold (RadioAccessService) = 80%
� red2YellowPCLCThreshold (RadioAccessService) = 70%
� isDlIubTransportLoadColourCalculationAllowed (RadioAccessService) = True
� green2YellowDlTLCThreshold (RadioAccessService) = 70%
� yellow2GreenDlTLCThreshold (RadioAccessService) = 60%
� yellow2RedDlTLCThreshold (RadioAccessService) = 90%
� red2YellowDlTLCThreshold (RadioAccessService) = 80%
Section 5 � Module 1 � Page 45
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 45
6 iRM CAC : Target RAB Determination
6.10 DL iRM : Exercise [cont.]
� Assumptions
� isCEMColourCalculationAllowed (RadioAccessService) = True
� isCEMModelValidForDlColour (nodeBConfClass) = True
� green2YellowDlCEMThreshold (RadioAccessService) = 80%
� yellow2GreenDlCEMThreshold (RadioAccessService) = 80%
� yellow2RedDlCEMThreshold (RadioAccessService) = 90%
� red2YellowDlCEMThreshold (RadioAccessService) = 90%
64128384Bronze
64128384Silver
64128384Gold
Cell Colour
= Red
Cell Colour
= Yellow
Cell Colour
= Green
DlIrmTable
OLS
PS_256K_IB
PS_ 256K_STR
PS_128k_IB
PS_128K_STR
PS_128k_IB_MUX
PS_384K_IB_MUX
PS_384K_IB
DlRbSetConfDlRbSetConf
Section 5 � Module 1 � Page 46
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 46
6 iRM CAC : Target RAB Determination
6.10 DL iRM : Exercise [cont.]
� Question: Find the iRM Target DL RB Rate ?
NodeB
PSCore
SRNC
RAB Assignment Request
Traffic class = BackgroundDL Maximum Bit Rate = 2048000UL Maximum Bit Rate = 128000Allocation/Retention Priority Level = 1
Radio L
ink
Iub
R5 UE CPICH_EcNo = -5dBCPICH_RSCP = -89dBm
Code load = 60%Power load = 50%Iub load = 60%CEM load = 85%
Section 5 � Module 1 � Page 47
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 47
6 iRM CAC : Target RAB Determination
6.11 UL iRM Principle
UL load (%) ���� UL RSSI
Cell is Green
Cell is Yellow
Cell is Red
Speech
UL384
Speech
UL384
UL384
UL128
Speech
UL384
UL384
UL128
Speech
UL384
UL384
UL128
UL64
…
green2yellow
yellow2red
UL64
time
UL iRM goal is to provide a good trade-off between the cell capacity and the QoS in uplink. This is achieved
through the choice of PS UL RB Bit Rate according to uplink cell load.
� When UL cell load is low, the UTRAN allocates radio resources to the user in order to provide the best
QoS, means the best uplink throughput.
� When UL cell load increases, the UTRAN reduces the allocated radio resources of PS RB established for
new users. The goal is to avoid blocking in UL.
Section 5 � Module 1 � Page 48
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 48
6 iRM CAC : Target RAB Determination
6.12 UL IRM Target RB Selection Algorithm
CEM Load
Olympic Service Level
UL Candidate RbSet
(Ref.)
UL Candidate RbSet
(Ref.)
(Target)
BronzeBronze
GoldGold
SilverSilver
UL IRM Tables
4
2
1
5
Radio Load
UL Radio Load3
Worst UL Cell Color
The aim of UL iRM CAC is to provide the operator means to manage efficiently I/B and streaming RABs on
R99 resources as a function of:
� traffic conditions (through radio load color evaluated by the RNC thanks to Noise Rise estimated by the
NodeB and reported to the RNC)
� CEM load (through CEM color)
� OLS (Olympic Service Level is either Gold or Silver or Bronze arrording to the Allocation/Retention
Priority IE provided in the RAB ASSIGNMENT REQUEST message).
Further reconfiguration can be triggered either by DL related events or by the UL RAB adapt feature.
This feature provides the operator with the best trade-off in term of offered QoS and NodeB/Cell available
resources.
This minimizes blocking and call drops.
Section 5 � Module 1 � Page 49
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 49
6 iRM CAC : Target RAB Determination
6.13 UL Radio Load Estimation Without RSEPS
Thermal Noise
CS12.2
CS12.2
PS64
CS64
NodeB NF
E-DCH load
Max allowed UL load
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10
2
4
6
8
10
12
14
16
18
20
UL load (%)
Noise Rise vs. UL load
Acceptable Max load
RTWPnon E-DCH
RTWPref
RoTnon E-DCH
NodeB CRNC
Common Measurement ReportRTWP= -106.1 + RoTnon E-DCH
Noise Rise (dB) = RoT
RoTmax
RoTnon E-DCH (dB) = RTWP + 106.1
UL Radio Load (%) = 1 – 10-(RoTnon E-DCH/10)
isNbapCommonMeasRsepsAllowed (NodeB) = False
isRtwpAdjustmentForRnc (BTSEquipment) = True
The way to control the Uplink traffic QoS is to maintain the UL load under fixed level.
The current absolute UL RTWP (i.e. Received Total Wideband Power) as defined in the 3GPP cannot be
measured with enough accuracy (+/- 4 dB). Indeed it depends on the temperature and the site conditions.
It is therefore varying in time.
� Due to these constraints UL load cannot be controlled based on direct UL RTWP measurement => Needs
for enhanced estimation.
� Therefore in order to improve the accuracy of the R99 UL CAC algorithm, the NodeB provides the RNC
with the Rise over the varying Thermal noise (RoT) corresponding to the Noise Rise induced by the UL
R99 traffic.
� As the measurement provided by the NodeB in the Common Measurement Report should be the RTWP
expressed in dBm, the NodeB adds to the actual RoT a fixed reference value equal to –106.1dBm.
The UL load should be monitored in order not to overload the system. It should be kept lower than a fixed
threshold to keep the system stable.
The UL load estimation is required for correct E-DCH scheduling and efficient UL iRM CAC.
The thermal noise should be well estimated in order to compute the UL load.
Section 5 � Module 1 � Page 50
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 50
6.13 UL Radio Load Estimation Without RSEPS
6.13.1 Self-Learning of RTWPref
No? RTWPref = -106.1 dBm
isRtwpReferenceSelfLearning
(BTSEquipment)
rtwpReference
(BTSCell)
Yes
RTWPref,0 = -106.1dBm
RTWP when no traffic
+
++
++++
+ + ++
++++++
++++++
+++
+++++
++++
++++++
+++
+ + + ++ + ++
++
+
+++
++
+
+++
++++ +++
+++ ++++++ ++
++++ +++++
++
++
++
Day n-1
RTWPref,n-1 RTWPref,n = -105.4 dBm
Day n Day n+1
time
-105.4dBm
The RTWP reference value (called RTWPref) should correspond to the minimum value of RTWP values
received in the cell when there are no connections in the Node B.
� During the learning time (24hours), the Node B keeps the RTWPcur values measured (filtered by L3
filtering- param sent by the RNC) if no traffic in the Node B.
� Please note that the first learning cycle is faster than 24 hours.
Section 5 � Module 1 � Page 51
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 51
6.13 UL Radio Load Estimation Without RSEPS
6.13.2 Calculation in NodeB
RTWPnon E-DCH = RTWPcur – RTWPE-DCH
RoTnon E-DCH = RTWPnon E-DCH - RTWPref
E-DCH load
Thermal Noise
CS12.2
CS12.2
PS64
CS64
NodeB NF
RTWPnon E-DCH
RTWPref
RoTnon E-DCH
RTWPcur
RTWPE-DCH
The non E-DCH load is obtained by subtracting this computed E-DCH load from the total RTWP.
� For each E-DCH connection the SIR will be estimated in function of the SIR on UL DPCCH and the gain
factors. These SIR are cumulated and then the contribution of E-DCH to the current total RTWP is
estimated.
� Note that the E-DCH traffic that belongs to other cells is included in the non E-DCH RTWP
measurement.
The total RTWPcur is the average between the two RX diversity branches if any.
Section 5 � Module 1 � Page 52
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 52
6.13 UL Radio Load Estimation Without RSEPS
6.13.3 Calculation in RNC
Common Measurement Initiation Request
CRNC
NodeB Measurement Type = RTWPReporting Mode = Periodic
Report Periodicity = nbapCommonMeasRtwpReportingPeriodFilter Coefficient = nbapCommonMeasRtwpFilterCoeff
Common Measurement Reportn-1
nbapCommonMeasRtwpReportingPeriod(NbapMeasRtwpParameters)
nbapCommonMeasRtwpFilterCoeff(NbapMeasRtwpParameters)
RTWP = -106.1 + RoTnon E-DCH, n-1
nbapCommonMeasRtwpReportingPeriod
No? Radio Load Color = Green
UL Radio Load = 1 – 10-(RoTnon E-DCH/10)
UL Radio Loadn-1
Common Measurement ReportnUL Radio Loadn
isUplinkRadioLoadEnabled(RadioAccessService)
isUlRadioLoadColourEnabled(NodeBConfClass)
The activation of UL RTWP measurement is not linked to the UL Load feature.
� NBAP Common Measurements are activated at cell setup
� There is no way to put measurement off. Therefore, there is no need to lock / unlock any cell to
activate NBAP Common Measurement.
Section 5 � Module 1 � Page 53
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 53
6 iRM CAC : Target RAB Determination
6.14 UL Load Estimation With RSEPS : Calculation in RNC
With this measurement : no more need to adjust the RTWP Measurement at BTS to report the Non-Edch RoT
The RNC computes the Non-Edch load for iRM UL load
UL Radio Load (%) = Non_Edch_UL_load = Total_UL_Load - RSEPS[ratio]
Where:
Total_UL_Load (%) = 1 - 10^( - Total_RoT / 10)
Total_RoT [dB] = Total RTWP[dBm] – Reference RTWP[dBm]
isNbapCommonMeasRsepsAllowed (NodeB) = True
Common Measurement Reports (Total RTWP, Reference RTWP)
C-RNCCommon Measurement Initiation Request (Total RTWP, Reference RTWP)
Common Measurement Initiation Request (Received Scheduled Edch Power Share)
Common Measurement Reports (EDCH power ratio)
When the RSEPS measurements are activated
� The RNC configures NBAP common measurements to report periodically
� Total RTWP
� Reference RTWP
� The RNC configures RSEPS (Received Scheduled Edch Power Share) measurements
� To report the Edch power ratio
WARNING: if RSEPS are activated the #303 UL_RSSI counter is giving the actual total RTWP whereas in UA5 it
is corresponding to “-106.1dBm + RoT_non_Edch”.
Section 5 � Module 1 � Page 54
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 54
6 iRM CAC : Target RAB Determination
6.15 UL IRM on Cell Color
UL IRM Tables
Radio Load Color
CEM Color
Yes
No
?
Cell Color = Green
isUlIrmOnCellColourAllowed(RadioAccessService)
UL Cell Color
CEM Color = Green
isUplinkRadioLoadEnabled(RadioAccessService)
isUlRadioLoadColourEnabled(NodeBConfClass)
Radio Load Color = Green
?Yes
No
isCEMColourCalculationEnabled(RadioAccessService)
Yes?
Yes
No
As any other, the CEM load criteria can be used or not thanks to the isCEMColourCalculationEnabled
parameter.
But CEM load is not only used in iRM CAC algorithm. Therefore if CEM load criteria is not to be used in iRM
CAC although CEM load is being computed for iMCTA feature, then:
� isCEMColourCalculationEnabled parameter has to be set to TRUE
� isCEMModelValidForUlColour parameter has to be set to FALSE
� In this case the CEM Color used in iRM CAC will be equal to ulCEMColourDefaultValue parameter value.
Section 5 � Module 1 � Page 55
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 55
6 iRM CAC : Target RAB Determination
6.16 UL Cell Color Calculation
green2yYellowUlRadioLoadThreshold(UlIrmRadioLoadParameters)
yellow2RedUlRadioLoadThreshold(UlIrmRadioLoadParameters)
yellow2GreenUlRadioLoadThreshold(UlIrmRadioLoadParameters)
red2yYellowUlRadioLoadThreshold(UlIrmRadioLoadParameters)
70 %
60 %
50 %
40 %
green2yYellowUlCEMThreshold(UlIrmCEMParameters)
yellow2RedUlCEMThreshold(UlIrmCEMParameters)
yellow2GreenUlCEMThreshold(UlIrmCEMParameters)
red2yYellowUlCEMThreshold(UlIrmCEMParameters)
90 %
80 %
70 %
60 %
CEM Load
Worst
Radio Load
UL Cell Color
CEM color in UL is calculated by the iRM mechanism comparing the UL CEM load estimation (expressed in percent) with the different CEM UL load thresholds configured at OAM
Once computed, the CEM color is applied to all the cells of a BTS, cells belonging to the same Local Cell Group.
NOTE: The values provided here for the different Radio load and CEM load are just examples. They are neither Alcatel-Lucent default values nor recommended values as those ones are driven by the configuration of NodeB and cell and by the operator strategy as a trade-off between capacity (number of simultaneous users) and quality (throughput for PS service).Indeed:
� Radio load thresholds setting is driven by the code capacity of the cell for DCH traffic which depends on the fact that the cell might also carry HSUPA traffic. Attention should be paid to the fact that yellow2RedUlRadioLoadThreshold should be lower or equal to the UL CAC threshold rtwpMaxCellLoadNonEdch.
� CEM load thresholds setting is driven by the CEM capacity of the BTS which depends on the type and number of CEM boards equipped, on the number of Local Cell Group configured and on the DBBU Frequency Pooling activation (dbbuPoolMode parameter).
Section 5 � Module 1 � Page 56
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 56
6 iRM CAC : Target RAB Determination
6.17 iRM Target UL RB Rate determination
BronzeBronze
GoldGold
SilverSilver
+
PSCore
SRNC
RAB Assignment Request Reference RB Bit Rate
iRMRbRate
Cell Color
OLS
MIN Target RB Bit Rate
Traffic classUL Maximum Bit RateAllocation/Retention Priority Level
Section 5 � Module 1 � Page 57
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 57
6 iRM CAC : Target RAB Determination
6.18 UL iRM Radio load parameters
RNC
nodeBConfClassId
1..15
isUllRadioLoadColourEnabled
rtwpReference
isUplinkRadioLoadEnabled
nbapCommonMeasRtwpReportingPeriodnbapCommonMeasRtwpFilterCoeff
1..15
green2yellowUlRadioLoadThresholdyellow2redUlRadioLoadThresholdred2yellowUlRadioLoadThreshold
yellow2greenUlRadioLoadThreshold
localCellId
1..15
NbapMeasRtwpParameters
MeasurementConfClassNodeBConfClassCacConfClass
UlIrmRadioLoadParameters
BTSCell
RadioAccessService
DedicatedConf
isRtwpReferenceSelfLearningisRtwpAdjustmentForRnc
BTSEquipment
isNbapCommonMeasRsepsAllowed
NodeB
localCellId
FDDCell
cacConfClassId
defaultUlIrmCellColour
NeighbouringRnc
Section 5 � Module 1 � Page 58
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 58
6 iRM CAC : Target RAB Determination
6.19 UL iRM CEM load parameters
isCEMColourCalculationEnabled
green2YellowUlCEMThresholdyellow2RedUlCEMThresholdred2YellowUlCEMThreshold
yellow2GreenUlCEMThreshold
RNC
NodeB
RadioAccessService
DedicatedConf
UlIrmCEMParameters
nodeBConfClassId
1..15
isCEMModelValidForUlColourulCEMColourDefaultValue
NodeBConfClass
Section 5 � Module 1 � Page 59
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 59
6 iRM CAC : Target RAB Determination
6.20 UL iRM table parameters
RNC
RadioAccessService
iRMRbRate
UlIrmTableConfClass
IrmRbRateList
IrmRbRateEntry
1..15
3
3
ulIrmTableConfClassId UlRbSetConf
ExampleUlRbSetConfId = PS_384K_IB
IrmRbRateEntry IrmRbRateList Instance
Instance iRMRbRate
0 OLS = Gold 384
1 OLS = Silver 384 /0 Cell Color = Green
2 OLS = Bronze 384
0 OLS = Gold 128
1 OLS = Silver 128 /1 Cell Color = Yellow
2 OLS = Bronze 128
0 OLS = Gold 64
1 OLS = Silver 64 /2 Cell Color = Red
2 OLS = Bronze 64
Section 5 � Module 1 � Page 60
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 60
6 iRM CAC : Target RAB Determination
6.21 UL CAC Principle: non E-DCH Radio Bearer
UL loadnon E-DCH (%)
Cell is Green
Cell is Yellow
Cell is Red
UL128
Speech
UL128
UL128
UL128
UL64
green2yellow
yellow2red
UL64
time
rtwpMaxCellLoadNonEdch(BTSCell)
UL128
Speech
UL128
UL128
UL128
UL64
UL64
accepted
UL128
Speech
UL128
UL128
UL128
UL64
UL64
accepted
accepted
UL128
Speech
UL128
UL128
UL128
UL64
UL64
accepted
accepted
rejected
rtwpMaxCellLoadCacActivation(BTSCell)
NodeB hardware resources are usually properly dimensioned to process the achievable cell rate however
there are some scenarios where the bottleneck is not the NodeB available resources but the UL radio
interference radio induced by the traffic.
� In this latter case admitting new calls or reconfiguring some of the ongoing calls with higher rates will
create too much Multi Access Interference (MAI) and consequently decrease the Radio Links quality and
Cell Breathing.
� It is better in this case to reject such a RL establishment.
The improvement of the CAC is achieved by taking into account the current UL Load, if it has reached a
certain value no new RL is admitted.
Two thresholds are defined:
� Max RTWP for total UL traffic (R99+E-DCH): totalRotMax
� Max RTWP for non E-DCH traffic only used for R99 CAC: rtwpMaxCellLoadNonEdch
The Node B performs a very basic CAC without considering the cost of the link to be
established/reconfigured/released.
� It compares the current UL load for non E-DCH calls to the rtwpMaxCellLoadNonEdch configurable
threshold parameter.
� In case this UL load is lower or equal, it is admitted, otherwise it is rejected.
� The non E-DCH UL load CAC threshold is configured in %.
As non E-DCH traffic is lower or equal to the total UL traffic (R99+E-DCH), the non E-DCH maxload should be
lower or equal to the total max load the following parameter rule should be fulfilled:
rtwpMaxCellLoadNonEdch <= 1 – 1/10(totalRotMax/10)
rtwpMaxCellLoadCacActivation is used to activate the UL CAC on non-EDCH traffic at BTS based on the
RTWP.
� rtwpMaxCellLoadNonEdch is used only if rtwpMaxCellLoadCacActivation is set to TRUE.
Section 5 � Module 1 � Page 61
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 61
6 iRM CAC : Target RAB Determination
6.22 Exercise : iRM UL
� Assumptions� edchActivation (FDDCell) = False
� enabledForRabMatching (any UlRbSetConf) = True
� isUlIrmOnCellColourAllowed (RadioAccessService) = True
� isUplinkRadioLoadEnabled (RadioAccessService) = True
� isUllRadioLoadColourEnabled (NodeBClonClass) = True
� green2YellowUlRadioLoadThreshold (RadioAccessService) = 40%
� yellow2GreenUlRadioLoadThreshold (RadioAccessService) = 40%
� yellow2RedUlRadioLoadThreshold (RadioAccessService) = 45%
� red2YellowUlRadioLoadThreshold (RadioAccessService) = 45%
� isNbapCommonMeasRtwpAllowed (RadioAccessService) = True
� isRtwpReferenceSelfLearning (BTSEquipment) = True
� rtwpReference (BTSCell) = -106.1dBm
� isCEMColourCalculationAllowed (RadioAccessService) = True
� isCEMModelValidForUlColour (nodeBConfClass) = True
� green2YellowUlCEMThreshold (RadioAccessService) = 80%
� yellow2GreenUlCEMThreshold (RadioAccessService) = 80%
� yellow2RedUlCEMThreshold (RadioAccessService) = 90%
� red2YellowUlCEMThreshold (RadioAccessService) = 90%
Section 5 � Module 1 � Page 62
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 62
6 iRM CAC : Target RAB Determination
6.22 Exercise : iRM UL [cont.]
� Assumptions
64128384Bronze
64128384Silver
64128384Gold
Cell Colour
= Red
Cell Colour
= Yellow
Cell Colour
= Green
UlIrmTable
OLS
PS_128K_STR
PS_128k_IB
PS_128k_IB_MUX
PS_256K_IB
PS_384K_IB_MUX
PS_384K_IB
UlRbSetConfUlRbSetConf
Section 5 � Module 1 � Page 63
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 63
6 iRM CAC : Target RAB Determination
6.22 Exercise : iRM UL [cont.]
NodeB
PSCore
SRNC
RAB Assignment Request
Traffic class = BackgroundDL Maximum Bit Rate = 2048000UL Maximum Bit Rate = 384000Allocation/Retention Priority Level = 1
UL Radio
Load
Iub
� Question: Find the iRM Target UL RB Rate ?
R6 UECEM load = 65%
Common Measurement Report
RTWP=-103.7dBm
Section 5 � Module 1 � Page 64
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 64
6 iRM CAC : Target RAB Determination
6.23 iRM CAC for PS Streaming RAB
PS Streaming RAB request
iRM
Candidate RB selection
MIB
PS Streaming RB
OLS RL colour
Cell colour
(MBR, GBR)
GBR < RB bit rate < MBR
Target RB bit rate < GBR ?
RB bit rate >= GBR
CAC
Yes
No
PS_16K_STR
PS_64K_STR
PS_128K_STR
PS_256K_STR
DlRbSetConfDlRbSetConf
� Alcate-Lucent implements PS streaming Radio Bearers (RB) since UA4.1. Support of Streaming RB allows
operators to differentiate streaming traffic from best effort traffic (i.e. Interactive and Background
traffic) at the transport level (e.g. Iub) or at RRM level, therefore providing streaming service of a
superior quality compared to when I/B RB are used.
� When speaking about streaming quality, another important parameter is the rate at which the
streaming content has been encoded. For example, it is generally acknowledged that high quality video
streaming on mobile device requires data rate of around 100kbps, and potentially more. As a matter of
fact, high quality streaming content requires to introduce higher streaming RB bit rate such as 128 kbps
or even 256 kbps. PS128kbps has been introduced in UA4.2 and PS256kbps is introduced in UA5.
� Since high bit rate RB are radio resources consuming, enhanced RRM is required to optimize radio
resources usage.
� iRM CAC: same as for PS I/B RAB except that the allocated RB must be of a Bit Rate greater or equal
to the Guaranteed Bit Rate required by the SGSN for the PS Streaming RAB
Section 5 � Module 1 � Page 65
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 65
7 iRM CAC : Admission Control & Resource Reservation
Section 5 � Module 1 � Page 66
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 66
7 iRM CAC : Admission Control & Resource Reservation
7.1 UL Radio Load Control
isUlTokenCacAtRncAllowed (RadioAccessService)
ulCostForUlTokenCac (UlUserService)
Established RLsUL Cost
New RLUL Cost
RNC
UL Cost < UL Capacity Threshold
Yes No
Call is accepted Call is rejected
PS 384 UEI
PS 128 UEJ
PS 128 UEK
PS 128 UEK
UL Cost
(FDDCell)
ulCapacityThresholdForUlTokenCac(FDDCell)
Up to UA4.2, there was no admission control and no iRM mechanisms for the UL part (only CEM resource
allocated by the Node B was taking into account the UL resource usage).
With the introduction of the UL PS I/B 384 kbps in UA4.2, it appeared essential to introduce a CAC for the
UL to avoid UL congestion.
From UA5.0, the UL iRM allows to have a more intelligent admission mechanism, starting to downgrade
users at admission before reaching the congestion and the blocking.
The uplink radio admission control for high data rate calls has been introduced together with the UL PS384
RAB in order to enable an uplink call admission control mechanism and thus avoid UL congestion.
� Lab tests show that in ideal radio conditions three PS I/B 384 generate a noise rise higher than 3 dB
(corresponding to 50% of UL Load). Beyond 75% load the system is no longer stable and it could lead to
significant neighboring cell interference, cell coverage reduction and mobiles dropping calls.
The solution is to define a cost per UL RAB and a total UL capacity threshold. This cost can be tuned per UL
PS RB bit rate thanks to ulCostForUlTokenCac parameter.
� At each allocation, release or reconfiguration of an UL resource, the UL load is incremented,
decremented or adjusted in function of the source and target UL RAB cost.
� This UL capacity pool is compared to a configurable threshold: if below this target, the call is accepted,
otherwise it is refused.
If a high bit rate UL PS RB is limited at RAB establishment because of this feature, it can be upgraded
thanks to ULRB Rate Adaptation feature if possible (see Packet Data Management section).
Section 5 � Module 1 � Page 67
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 67
7 iRM CAC : Admission Control & Resource Reservation
7.2 Transport Resource Reservation
Radio Bearer
Radio Bearer
Iub Bearer
Iub Bearer
Iur Bearer
Iu-CS Bearer
Iu-PS Bearer
iubIurTransportQosId
(DL/ULRbSetConf -> CacTransportInfoList)
iuTransportQosId
(DL/ULRbSetConf -> CacTransportInfoList)
dscp
DscpPerOlympicService/2
DscpPerOlympicService/1
DscpPerOlympicService/0
DscpTrafficClass/3
DscpTrafficClass/2
DscpTrafficClass/1
RNC
Ps/CSCoreNetworkAccess
DscpTrafficClass/0DS Traffic (Speech, VT, SRB)Streaming Traffic (on DCH or HSDPA)NDS Traffic (PS I/B) on DCHNDS Traffic (PS I/B) on HSDPA
Transport resources reservation consists of selecting the QoS identifier corresponding to the requested
radio bearer. The QoS identifier is configured at the Access OAM according to the traffic class of the radio
bearer.
Based on the QoS identifier required for the radio bearer requested, the RNC will request and reserve a CID
(Channel IDentifier) that is, a transport channel on the Iub, Iur, Iu-CS.
Transport channels on Iu-PS are reserved according to the DSCP. The DSCP (DiffServ Code Point) is deduced
from the traffic class and the allocation/retention level (OLS for the interactive and background RABs).
The RNC is mapping each DiffServ class on one ATM quality of service over the Iu-PS (namely CBR, VBR-rt,
VBR-nrt, UBR).
From UA6.0, an additional QoS is introduced to permit the introduction of guaranteed bit rate traffic flows
on HSDPA. The new mapping is:
� QoS 0 carries Delay Sensitive traffic (speech, VT, SRB, etc)
� QoS 1 carries the streaming traffic, mapped on DCH or HSDPA
� QoS 2 carries the PS I/B traffic mapped on DCH traffic
� QoS 3 carries the PS I/B traffic mapped on HSDPA
The determination of Iub load for iRM is done for the DL direction, thanks to real time observation of traffic
at the ATM layer. The traffic measured is averaged on a window of 10s.
Section 5 � Module 1 � Page 68
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 68
7 iRM CAC : Admission Control & Resource Reservation
7.3 AAL2 Call Admission Control
aal2IfQoS0
QoS1
SHARED
ACR(QoS1) x qoS1BWReservation (aal2If)
cacMethod (Aal2If or Ipif)
ACR(QoS0) x qoS0BWReservation (aal2If)
qos aal2If
ACR(aal2If)
QoS0
QoS1
aal2If
path
ACR(aal2If)
QoS0
QoS1
Path/0
Path/n
Path/1
Path/m
loadBalancingMethod (Aal2If)
pc
link
cacMethod (Aal2If or Ipif)none
CAC disabled
AAL2 CAC ensures that the admission of new calls does not cause traffic to exceed the provisioned ATM
bandwidth in either UL or DL. AAL2 CAC can be done per aal2If or per QoS according to the CacMethod
chosen.
Each RB has a cost called Equivalent Bit Rate that represents the bandwidth to be reserved. Available
bandwidth (called Available Cell Rate) is estimated by the RNC based on the ATM Traffic Descriptors
(PCR, SCR).
ACR(QoS) = Sum(ECR GCAC) on all AAL2 VCCs for the given QoS
� for CBR (Iub and Iur DS UP VCCs and IuCS UP) : ECR GCAC = PCR
� for VBR (Iub and Iur NDS UP VCCs): ECR GCAC = 2 x PCR x SCR / (PCR + SCR)
ACR(aal2If) =Sum(ACR(QoS)) on all QoS in use on the aal2If.
The new connection is accepted when:
If CACMethod=aal2If:
� EBR(new connection on aal2If) + EBR(current connections on aal2If) ≤ ACR(aal2If)
If CACMethod=QoS (example of new DS connection):
� If EBR(current NDS) < qos1BwReservation x ACR(NDS)
� EBR(new DS) + EBR(current DS) < ACR(DS) + (1-qos1BwReservation)ACR(NDS)
Else:
� EBR(new DS) + EBR(current DS) + EBR(current NDS) < ACR(DS) + ACR(NDS)
If CACMethod=path:
� EBR(new connection on path) + EBR(current connections on path) ≤ ACR(path)
The loadBalancingMethod parameter configured on an UTRAN aal2 interface, determines the choice of a
path for a CID seizure.
� loadBalancingMethod = link: the CID is seized on the less loaded active Path within an aal2If
� loadBalancingMethod = pc: the CID is seized on a Path assigned to the less loaded PMC-PC
Section 5 � Module 1 � Page 69
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 69
7 iRM CAC : Admission Control & Resource Reservation
7.4 IRM and AAL2 CAC Replay at RB Upgrade or AON Upsize
DCH FACH DCH
EBR(384 kbps)
EBR(128 kbps)
EBR(8 kbps)
AAL2 CAC EBR
RAB RANAP MBR
384 kbps
8 kbps
384 kbps
AON Downsize AON Upsize
1. iRM Downgrade(cell color is yellow)
2. AAL2 CAC on DCH at AON Upsize CAC on FACH at
AON Downsize
EBR of a given call can be updated when the TRB is reconfigured during the call, typically as the result of
multi-service, always-on, iRM scheduling and power pre-emption scenarios. This is done through the Aal2
bearer negotiation function.
This implies that during upgrade scenarios, the function must re-apply link and PC CAC to the EBR of the
target RB configuration and reject if the new requested bandwidth fails the CAC criteria. This function is
enabled through the use of isAal2BearerRenegotiationAllowed
Section 5 � Module 1 � Page 70
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 70
7 iRM CAC : Admission Control & Resource Reservation
7.5 DL Reserved Power Computation
Algorithm Selection
Pres = Pmax - algo1DeltaTargetPower
Pres = Pini + algo2DeltaTargetPower
Pini = pcpichPower + initialDlEcnoTarget – CPICH_Ec/No
dlAlgoSelector (PowerConfClass)
FDDCell
powerConfId (FDDCell)
algo1
algo2
maxDlTxPowerPerOlsalgo1DeltaTargetPower algo2DeltaTargetPower
initialDlEcnoTarget
Pmax = pcpichPower + maxDlTxPowerPerOls
pcpichPower (FDDCell*)
PowerConfClass
DlUsPowerConf
FDDCell* ⇔ FDDCell-> Class2CellReconfParamsor FDDCell-> Class3CellReconfParams
After the RAB Matching and RAB Mapping algorithms have been processed, the RNC estimates the necessary
power to initially support the call.
This power estimation (Pres) corresponds to the power that will be reserved by the RNC if the admission
criterion is passed.
Pres is calculated differently depending on which algorithm is used to perform the downlink power
allocation:
� algorithm 1: Pres = pcpichPower + maxDlTxPowerPerOls - algo1DeltaTargetPower
� algorithm 2: Pres = Pini + algo2DeltaTargetPower
Where:
Pini = pcpichPower + initialDlEcnoTarget – CPICH_EC/NO
The choice between these two algorithms is done through the dlAlgoSelector parameter of the
PowerConfClass object:
� With the dlAlgoSelector, the operator can decide which algorithm will be used in the different power
control configuration classes.
� Each FDD cell points to a specific PowerConfClass, identified by powerConfId.
Section 5 � Module 1 � Page 71
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 71
7 iRM CAC : Admission Control & Resource Reservation
7.6 DL Power Admission Criteria
P traffic
P traffic admission
callAdmissionRatio (PowerPartConfClass)maxTxPower (FDDCell*)
Call Rejected
No
Pres is allocated
Pres
Pused
Yes
Pres + Pused <= Ptraffic_admission
Traffic Power(SHO reserved)
Traffic Power
(Dedicated Channels)
Overhead Power
(CCC+OCNS+HSDPA+E-DCH)
FDDCell* ⇔ FDDCell-> Class2CellReconfParamsor FDDCell-> Class3CellReconfParams
Power consumption levelabove which
new calls are blocked
Once the downlink power Pres is assessed for the call, some admission criteria are checked by the RNC.
The admission criterion is the following:
� Primary link admission (call establishment): Pres + Pused ≤ Ptraffic admission
� Soft handover link addition: Pres + Pused ≤ Ptraffic
Note: Pused is the sum of the Pres of all calls being actually supported.
If this criterion is fulfilled, the power Pres is reserved by the RNC. Otherwise, the call is rejected.
From UA5 release (E-DCH introduction):
� Ptraffic = PMaxCell - PCCC * ActivityFactorCch - POCNS - Pedch - PminHsdpa
� Where
� PMaxCell is the maximum total allowed DL power in the cell
� PCCC is the total power allocated for all Common Control Channels in the cell
� ActivityFactorCch is hard coded to 66%
� POCNS is the optional power allocated to OCNS if needed (can be pre-empted for R99 traffic).
OCNS=Orthogonal Code Noise Simulator
� Pedch is the power reserved for DL transmission of E-AGCH and E-RGCH/E-HICH channels (can be pre-
empted for R99 traffic)
� PminHsdpa is the power reserved for a minimum HSDPA traffic in the cell
Section 5 � Module 1 � Page 72
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 72
7 iRM CAC : Admission Control & Resource Reservation
7.7 DL Power Self Tuning
isBtsPowerSelfTuningActivated
(PowerConfClass)
Case 1Power consumption
underestimated at the RNC
Case 2Power consumption
overestimated at the RNC
Allocated Power(Pused at RNC)
Measured Power(Pused at NodeB)
New Allocated Power(new Pused at RNC)
powerMargin(PowerConfClass)
Allocated Power
Measured Power
overEstimate(PowerConfClass)
NodeBRNC NodeBRNC
New Allocated Power(new Pused at RNC)
Tuning of RNC power pool occupancy
The parameter isBtsPowerSelfTuningActivated indicates if the power pool self-tuning must be performed or
not.
If self-tuning is allowed 2 cases must be considered:
� Power consumption underestimated at the RNC: In this case it is proposed to update the allocated
power (power consumed as seen by the RNC) based on the measured power (as measured by the Node
B) plus a powerMargin.
� Power consumption overestimated at the RNC: The power consumption is confirmed as overestimated if
the difference between the measured and allocated is above an overEstimate threshold. In that case,
the new allocated power (power consumed as seen by the RNC) is made equal to the measured power
(as reported by the Node B).
Section 5 � Module 1 � Page 73
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 73
7.7 DL Power Self Tuning
7.7.1 Example
Power_Margin
OverEstimate
CommonMeasurmentReportingPeriod (NBAP)
Power Allocated is underestimated :
ADD Power_Margin
Power Allocated is overestimated by more
than OverEstimateUPDATE with Pmeas
Power Allocated is overestimated by less
than OverEstimateNO CHANGE
DL Power used reported by NodeB
DL Power used as seen by RNC
Power consumption underestimated at the RNC: In this case it is proposed to update the allocated power
(power consumed as seen by the RNC) based on the measured power (as measured by the Node B) plus a
powerMargin.
Power consumption overestimated at the RNC: The power consumption is confirmed as overestimated if the
difference between the measured and allocated is above an overEstimate threshold. In that case, the
new allocated power (power consumed as seen by the RNC) is made equal to the measured power (as
reported by the Node B).
Section 5 � Module 1 � Page 74
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 74
7 iRM CAC : Admission Control & Resource Reservation
7.8 OVSF Codes Reservation & Admission
Alcatel -
LucentS -CCPCHC
64,1
Alcatel -
LucentPICHC
256,3
Alcatel -
LucentAICHC
256,2
3GPPP-CCPCHC256,1
3GPPP-CPICHC256,0
SourceChannelOVSF Code
Alcatel-LucentS -CCPCHC
64,1
Alcatel-LucentPICHC
256,3
Alcatel-LucentAICHC
256,2
3GPPP-CCPCHC256,1
3GPPP-CPICHC256,0
SourceChannelOVSF Code
SF4
SF8
SF16
SF32
SF64
SF128
SF256
CommonChannels
OVSF Codes Allocation
Spreading Factor (SIB 5)
Code Number (SIB 5)
Channelization Code (SIB 5)
Channelization Code (SIB 5)
In this OVSF tree, some codes are reserved:
� codes for common control channels
� codes for OCNS
� a sub-tree is allocated to the Node B for HSDPA usage.
The rest of the OVSF tree is used by calls handled over R99 resources.
For each allocation, the OVSF tree will be run from up to down (filling the gaps when any), which avoids to
block too many branches.
If a free code is found, the resource is granted to the call and the OVSF code CAC is successful, otherwise
the call is rejected and the CAC on OVSF code is declared failed.
The new feature Dynamic DL Code Tree Management has been introduced in UA5 in order to avoid R99 code
blocking.
Section 5 � Module 1 � Page 75
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 75
8 CELL_FACH Admission Control
Section 5 � Module 1 � Page 76
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 76
8 CELL_FACH Admission Control
8.1 CELL_FACH Admission Control
IDLE
CELL_DCH CELL_FACHSRB + RB
CELL_DCH CELL_FACHSRB ONLY
RRC Connection Request
Cell Update
Cell Update
AO Downsize
AO Upsize
RAB Assignment
CELL_FACH Admission Events
Bucket Occupancy
CELL_FACHAdmission Control
maxNumberOfUserPerMacC
(CacOnFachParam)
trbEstThreshold
(CacOnFachParam)
Each cell can only accept a limited number of simultaneous UEs in the CELL_FACH state:
� Each mobile on CELL_FACH is allocated a token.
� Each time a CELL_FACH admission is tried in a given cell, the current number of used token is compared
to a specific threshold. If below the threshold, the admission is successful and a token is allocated.
There are 2 thresholds used according to the reason for CELL_FACH admission. In the Alcatel-Lucent
implementation, they are defined as:
� MaxNumberofUsersPerMacC (signaling dealing with Cell_FACH state as RRC Connection Request, Cell
Update – with at least one SRB allocated-)
� is used to limit the number of simultaneous user connections being supported by a given Mac-C
instance
� trbEstThreshold (transition from Cell_DCH state to Cell_FACH due to Always-On feature)
� defines the maximum number of users that can have TRB configuration in CELL_FACH
These parameters are set at the OAM in order to give a higher precedence to a new incoming call (RRC
connection request) than to a mobile already in call and aiming to transition from Cell_DCH to Cell_FACH.
Section 5 � Module 1 � Page 77
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 77
Module Summary
� This lesson covered the following topics:
� Call establishment and associated parameters
� RAB Matching and associated parameters
� IRM RAB to RB Mapping and associated parameters
� CAC and associated parameters
� CELL_FACH admission and associated parameters
Section 5 � Module 1 � Page 78
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 78
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 5 � Module 1 � Page 79
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Admission �
5 � 1 � 79
End of Module
Section 6 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
6�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 6Power Management
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 6 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 2
Blank Page
This page is left blank intentionally
OLPC Enhancements in UA7Chatila, RyanRyser, SigridCharneau, Jean-Noel
2010-04-1501
RemarksAuthorDateEdition
Document History
Section 6 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Describe power management static configuration
� Describe PRACH Power Control and associated parameters
� Describe UL Power Control and associated parameters
� Describe DL Power Control and associated parameters
� Describe Radio Link Control and associated parameters
Section 6 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 6 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 5
Table of Contents
Switch to notes view!Page
1 Power Management Static Settings 71.1 Downlink Power Settings 81.2 Cables Losses without TMA 91.3 Cables Losses with TMA 101.4 Common Channel Power Settings 111.5 Dedicated Channel Power Settings 12
2 PRACH Power Control 132.1 PRACH Open Loop 14
3 UL DPCCH Open Loop Power Control 153.1 DPCCH Open Loop Power Control 163.2 UL Gain Factors 173.3 UL DPCCH / DPDCH Power Ratio 183.4 UL Rate Matching Attributes 19
4 Outer Loop Power Control 204.1 SIR Target Management 214.2 Partial SIR Target Update 224.3 OLPC Based on Quality Estimator: QE 234.4 Accelerated SIR Target convergence based on QE 24
5 UL Inner Loop Power Control 255.1 DPCCH Inner Loop Power Control 265.2 UL Inner Loop Power Control 275.3 UL Power Control Algorithms 285.4 UL Inner Loop Algorithm 1 295.5 UL Inner Loop Algorithm 2 (no SHO case) 305.6 UL Inner Loop Algorithm 2 (SHO case) 31
6 DL Traffic Channel Power 326.1 Initial DL Traffic Channel Power 336.2 DL DPCCH / DPDCH Power Offsets 346.3 DL Power Offset 2 as a Function of the AS size 35
7 DL Outer Loop Power Control 367.1 DL Outer Loop Power Control 37
8 DL Inner Loop Power Control 388.1 DL Inner Loop Algorithm 398.2 Power Balancing 408.3 Rate Reduction Algorithm 41
9 Radio Link Control 429.1 UL Dedicated Channel Synchronization 439.2 UL Radio Link Failure – detected by UTRAN 449.3 DL Radio Link Failure – detected by UE 459.4 DL RLC Unrecoverable Error – detected by UTRAN 469.5 UL RLC Unrecoverable Error – detected by UE 479.6 RRC Connection re-establishment Parameters 489.7 UL Radio Link Failure – RRC Connection Re-established 499.8 UL RLC Unrecoverable Error – RRC Con. Re-established 509.9 RRC Connection re-establishment - Summary 51
Section 6 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 6
Table of Contents [cont.]
Switch to notes view!
This page is left blank intentionally
Section 6 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 7
1 Power Management Static Settings
Section 6 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 8
1 Power Management Static Settings
1.1 Downlink Power Settings
F1
F2
paRatio (BTSCell)
paRatio (BTSCell)
maxPowerAmplification (PaResource)
Cell Setup
MaxTxPower (Cell) = MIN ( , MaxDlPowerCapability)maxTxPower
maxTxPower (FDDCell->Class2CellReconfParams / FDDCell->Class3CellReconfParams )
maxPowerAmplificationMaxDlPowerCapability = Max PA Power( MCPA HW Type , paRatio) x - Global Losses
F3
paRatio (BTSCell)
At cell setup, the RNC calculates the max Tx Power, which is the maximum power that will be used to
configure the cell:
� Max Tx Power (FDDCell) = min (Max Tx Power Required, Max DL Power capability)
At the Node B level, the power is owned by Power Amplifiers which can be shared by multiple cells.
In Alcatel-Lucent configurations, cells on the same sector but on different carriers may share or not the
same Power Amplifier. This capability should allow optimization of the use of the PA. The sharing of
power between different cells associated with the same PA is static.
A configuration parameter at the OMC-B (called PA_Ratio) allows sharing of a PA power between 2 cells.
From an RNC perspective, the sharing is transparent.
Possible values of maxPowerAmplification are = {fullMode, max30W , max45W , max60W , max85W}
The Max PA Power, in dBm unit, represents the maximum output power of a MCPA board. If maxPowerAmplification is set to fullMode value then Max PA Power value depends of the HW type of the MCPA board. For instance it is equal to 46.5dBm for a MCPA 45W and to 47.8dBm for a MCPA 60W?
As the names indicate:
- the object class2CellReconfParams contains Class 2 parameters
- the object class3CellReconfParams contains Class 3 parameters
At the RNC side: Depending on the value of the parameter isCellReconfSupported (NodeB), the RNC knows if the NodeB supports the Cell Reconfiguration procedure or not.
� If it does not, the Class 2 parameters are applied.
� If the NodeB supports the Cell reconfiguration, the RNC takes the Class 3 parameters. When they are changed online, the RNC send the Cell Reconfiguration procedure
At the OMC side:
� If isCellReconfSupported is False, then the OMC maintains Class 2 and Class 3 parameters aligned : every change on Class 3 parameters implies an update of Class 2 parameters and then a Cell lock/unlock.
� If isCellReconfSupported is True, the Class 3 parameters are no more linked to Class 2 parameters and may be changed on-line (without Cell lock/unlock)
Section 6 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 9
1 Power Management Static Settings
1.2 Cables Losses without TMA
externalAttenuationXXXDl = 0
MCPA Tx Splitter DDM
BTS
Reference point
Global Losses = Internal Losses
externalAttenuationXXXDl ≠≠≠≠ 0
MCPA Tx Splitter DDM
BTS
Reference point
Global Losses = Internal Losses + externalAttenuationXXXDl
externalAttenuationMainDl (AntennaAccess)
externalAttenuationDivDl (AntennaAccess)
tmaAccessType (AntennaAccess)
� Computation of losses is not the same, depending on:
� parameters externalAttenuationMainDl and externalAttenuationDivDl of the AntennaAccess object
� TMA configuration
� Cable Losses without TMA.
� If externalAttenuationXXXDl = 0, the transmission power reference point is defined at the antenna connector of the BTS. In this case the Global Losses refer only to internal cabling losses (typical value =
0.8 dB) and DDM insertion losses (typical value = 0.5 dB).
� For OTSR configurations additional losses must be taken into account:
� Tx Splitter insertion losses (typical value = 0.3 dB)
� Additional cabling between Tx Splitter and DDM (typical value = 0.3 dB)
� If externalAttenuationXXXDl ≠ 0, the transmission power reference point is defined at the antenna connector after the RF feeder (antenna side).
� In this case, the reference point is the point so that losses between the BTS feeder connector (out put
of the cabinet) and this point are equal to the datafilled value of externalAttenuationXXXDl.
Section 6 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 10
1 Power Management Static Settings
1.3 Cables Losses with TMA
externalAttenuationMainDl (AntennaAccess)
externalAttenuationDivDl (AntennaAccess)
tmaAccessType (AntennaAccess)
externalAttenuationXXXDl ≠≠≠≠ 0
MCPA Tx Splitter DDM
BTS
Reference point
Global Losses = Internal Losses + externalAttenuationXXXDl+ TMA Insertion Losses +Jumper Losses
TMA
externalAttenuationXXXDl = 0
MCPA Tx Splitter DDM
BTS
Reference point
Global Losses = Internal Losses+ Feeder Losses+ TMA Insertion Losses +Jumper Losses
TMA
� When a TMA is specified (tmaAccessType = tmaUmtsOnly or tmaMix), the transmission power reference point moves to the antenna port of the TMA. Additional losses are taken into account:
� TMA insertion losses are equal to 0.3 dB in the transmission path
� jumper losses are set to 2*0.6 dB (0.6 dB for each jumper)
� If externalAttenuationXXXDl is set to 0, the feeder losses are equal to 2 dB. Otherwise the feeder losses are equal to the datafilled value of externalAttenuationXXXDl .
Section 6 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 11
1 Power Management Static Settings
1.4 Common Channel Power Settings
Traffic Power (SHO
reserved)
Traffic Power
Overhead Power
(Common Channels)
PCHpichPowerRelativeToPcpichPICH
RACHaichPowerRelativeToPcpichAICH
SCCPCHsccpchPowerRelativeToPcpichS-CCPCH
FDDCell*bchPowerRelativeToPcpichP-CCPCH
FDDCell*sschPowerRelativeToPcpichS-SCH
FDDCell*pschPowerRelativeToPcpichP-SCH
FDDCell*pcpichPowerPCPICH
ObjectparameterChannel
Node B
FDDCell* ⇔ FDDCell-> Class2CellReconfParamsor
FDDCell-> Class3CellReconfParams
� In the slide, the Pilot power, that is, the P-CPICH power is defined by the pcpichPower parameter of the FDDCell object as an absolute value in dBm, referenced at the BTS antenna connector.
� All the other common channel powers are given relative to the P-CPICH level.
� Because of the check in the BTS (CCM) at call setup, this relationship must be true for maxTxPowerand PcpichPower: PcpichPower > MaxTxPower - 15 dB.
� A sensor at the output of the MCPA allows measurement of the effective output power of the amplifier.
The range of sensitivity of this sensor is [25 dBm..46.5 dBm]. So as to be sure to detect power, it is
recommended that the Pcpich Power (at PA Output) is higher than the minimum sensibility of this
sensor).
� PcpichPower > 25 dBm-total_losses_between_PA_output_and_reference_point
� P-CPICH power is recommended to be set at:
� 35 dBm in case of one channel
� the half (32 dBm) if two carriers are supported by the same PA
At the RNC side:
Depending on the value of the parameter isCellReconfSupported (NodeB), the RNC knows if the NodeBsupports the Cell Reconfiguration procedure or not.
� If it does not, the Class 2 parameters are applied.
� If the NodeB supports the Cell reconfiguration, the RNC takes the Class 3 parameters. When they are changed online, the RNC send the Cell Reconfiguration procedure
At the OMC side:
� If isCellReconfSupported is False, then the OMC maintains Class 2 and Class 3 parameters aligned : every change on Class 3 parameters implies an update of Class 2 parameters and then a Cell lock/unlock.
� If isCellReconfSupported is True, the Class 3 parameters are no more linked to Class 2 parameters and may be changed on-line (without Cell lock/unlock)
Section 6 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 12
1 Power Management Static Settings
1.5 Dedicated Channel Power Settings
DedicatedConf
RadioAccessService
PowerConfClass
DlUsPowerConf UlUsPowerConf
maxTxPower (FDDCell*)
powerConfId (FDDCell)
minDlTxPower (DlUsPowerConf)
maxDlTxPowerPerOls (DlUsPowerConf)max UE Tx Power (UE Power Class)
FACH
maxAllo
wedUlT
xPower
(UlUsPo
werCon
f)
, Max UE Tx Power)Max UL Tx Power = MIN( maxAllowedUlTxPower (UlUsPowerConf)
� Part of the Dedicated Channels power management relies on static settings.
� This is for example the case in downlink for the maximum power per carrier and the upper and lower
bounds of the traffic channel. It is important to note that these two last parameters are not necessarily
the same for all UEs communicating in the cell, as different values are used depending on the radio
bearer.
� Static settings are also used to define the maximum allowed transmission power in UL per User Service.
It represents the total maximum output transmission power allowed for the UE and depends on the type
of service required. The information will be transmitted on the FACH, mapped on the S-CCPCH, to the
UE in the RADIO BEARER SETUP message of the RRC protocol.
� Consequently, whenever a radio bearer is set up or reconfigured, when a transport or a physical
channel is reconfigured, when a RRC connection is setup or re-established, when the active set is
updated or when a handover is performed from GSM to UTRAN, a new value may be decided by the RNC
(Control Node) for the parameter maxAllowedUlTxPower and this parameter shall be re-transmitted to the UE.
Section 6 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 13
2 PRACH Power Control
Section 6 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 14
constantValue (RACH)
SIB 5SIB 5
2 PRACH Power Control
2.1 PRACH Open Loop
NACK NACK NACK ACK
Message part
PRACHControl part
PRACHData part
Pini
Pini = + RTWP + - P-CPICH_RSCP
powerOffsetPO(RACH)
sibMaxAllowedUlTxPowerOnRach (PowerConfClass)
Preamble part
betaC
(RACHSignalledGainFactors)
betaD
pcpichPower(FDDCell*)
AICH
powerOffsetPpmx(RACH)
SIB 5SIB 5
SIB 5SIB 5
SIB 5SIB 5
SIB 5SIB 5
SIB 5SIB 5
SIB 7
� The PRACH consists of:
� A preamble part which is sent by the UE and repeated until either an Acquisition Indicator (ack or
nack) is received over AICH or the preamble retransmission counter reaches its max value (parameter
provided by the network). The first preamble is transmitted with a power of “Preamble initial
power”. Each consecutive preamble is transmitted with a power equal to the previous one plus a
‘power ramping step”. “Preamble initial power “is calculated by the UE based on parameters sent on
SIB5 and SIB7 and on CPICH RSCP measured by the UE. “power ramping step” is a UTRAN parameter
sent to the UE over SIB5.
� A message part which is sent after an acknowledged Acquisition indicator. This message part is
composed of a control part and a data part. The power of the control part is equal to the power of
the last preamble sent plus Pp-m which is a UTRAN parameter sent over SIB5. The power of the data
part is derived from the power of the control part through (βc,βd) parameters per TFC also sent by
the UTRAN over SIB5. βd/βc defines the relative power between the control part and the data part.
Notes
� RTWP: corrective term evaluating the average interference level on UL. In the Alcatel-Lucent
implementation, this is not a parameter. It corresponds to the UL RTWP measured by the Node B. It is
broadcast in SIB 7.
� constantValue: corrective term to compensate for shadowing effects. It is broadcast in SIB 5.
� powerOffsetPpM0 is the power offset between the last transmitted preamble and the control part of themessage for PRACH CTFC0.
� powerOffsetPpM1 is the power offset between the last transmitted preamble and the control part of themessage for PRACH CTFC1.
Section 6 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 15
3 UL DPCCH Open Loop Power Control
Section 6 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 16
3 UL DPCCH Open Loop Power Control
3.1 DPCCH Open Loop Power Control
Pini (UL DPCCH) = – P-CPICH_RSCPdpcchPowerOffset (UlInnerLoopConf)
UL DPCCH Tx at Pini
S-CCPCH or FACH
“Uplink power control info” IEDedicatedConf
RadioAccessService
PowerCtrlConfClass
UlInnerLoopConf
dpcchPowerOffset
� When establishing the first DPCCH, the initial power used by the UE to start the UL DPCCH transmission
is:
� DPCCH_Initial_power = dpcchPowerOffset – CPICH RSCP
� It is provided by the RNC to the UE via RRC signaling (FACH / S-CCPCH), in the “Uplink power control
info” IE or in the “Uplink power control info short” IE.
� These IEs are included (one or the other) in the RRC messages of the radio bearer setup,
reconfiguration and release, transport channel and physical channel reconfiguration, RRC connection
setup and re-establishment and in the handover to UTRAN command.
Section 6 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 17
3 UL DPCCH Open Loop Power Control
3.2 UL Gain Factors
I
Q
OVSF1 bd
UL DPDCH
OVSF256,0 bc
UL DPCCH
ModulationUE
Scrambling code
� The figure above illustrates the principle of the uplink spreading of DPDCH and DPCCH. The first step,
the NRZ modulation, consists in associating a real signal to each bit of these channels. The binary value
“0” is mapped to the real value +1 and the binary value “1” is mapped to the real value -1. Then, each
channel is spread by an OVSF code. As it was mentioned before, channelization codes are only used to
spread the information in uplink (not for channel multiplexing) because synchronization between UEs is
too complex to achieve.
� The channelization code used for DPCCH is always Cch,256,0 (all ones).
� If only one DPDCH is used, it is spread by code Cch,SF,k , where k is linked to SF by k=SF/4. When
more than one DPDCH is used, they will all have a SF equal to 4.
� After channelization, the spread signals are weighted by a gain factor (βc for DPCCH and βd for DPDCH). These gain factors are quantized into 4 bits, giving values between 0 and 1. There is at least one of the
values βc and βd that is equal to 1. These gain factors may vary for each TFC, and are either signaled or computed.
� Then, the streams of chips are summed up giving a multilevel signal. After this addition, the real-
valued chips on the I and Q branches are summed up and treated like a complex-valued stream of chips.
This stream is scrambled by a complex-valued scrambling code. For DPDCH and DPCCH, a unique
scrambling code of 38,400 chips (corresponding to one radio frame) is used. That code can be either of
long or short type.
� Finally, the complex chips are I and Q multiplexed and sent over the air interface. The result of all this
is a BPSK modulation, which gives us 1 bit per symbol.
Section 6 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 18
3 UL DPCCH Open Loop Power Control
3.3 UL DPCCH / DPDCH Power Ratio
CSDTCH12_2Kx4SRBDCCH3_4K2PSDTCH64Kx4SRBDCCH3_4KCSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K
PSDTCH64Kx4SRBDCCH3_4KPSDTCH384Kx4SRBDCCH3_4KStandaloneSRBDCCH3_4K...
CSDTCH12_2Kx4SRBDCCH3_4K2PSDTCH64Kx4SRBDCCH3_4KCSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K
PSDTCH64Kx4SRBDCCH3_4KPSDTCH384Kx4SRBDCCH3_4KStandaloneSRBDCCH3_4K...
refTfcId
betaC
betaDrefTfcId
betaC
betaDrefTfcId
betaC
betaDTFC 0
UlUserServiceRNC
SignalledGainFactor
ComputedGainFactor
RNC
refTfcId
refTfcId
betaC
betaD
TFC 1
TFCS #2
Signaled Mode
Computed Mode
refTfcId
betaC (SignalledGainFactor)
betaD (SignalledGainFactor)
refTfcId (SignalledGainFactor)
betaC (ComputedGainFactor)
betaD (ComputedGainFactor)
refTfcId (ComputedGainFactor)
CSDTCH64Kx4SRBDCCH3_4K
UlUserService
CSDTCH64Kx4SRBDCCH3_4K
� For a given Access Stratum configuration, corresponding to one precise UlUserService object instance,
some TFCs have their betaC and betaD values defined through betaC and betaD parameters respectively, whereas some other TFCs use reference TFCs to deduce their own betaC and betaD
values.
� In order to give a reference identity to a TFC, to declare it as a possible reference TFC for other TFCs,
an optional parameter named refTfcId (SignalledGainFactor object) is used.
� Once the reference TFCs are declared, some other TFCs of the TFCS (under the same UlUserService
instance) can be provisioned as computedGainFactors instances (mode “computed” chosen at the OAM
in the RNC MIB).
� For each of them, there is a pointer on a reference TFC in order to indicate from which betaC and
betaD values the TFC shall compute its own betaC and betaD values:
� This pointer to a reference TFC corresponds to refTfcId parameter in the computedGainFactor object.
� This parameter corresponds to the identity of a reference TFC set through refTfcId parameter in SignalledGainFactor object.
Section 6 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 19
3 UL DPCCH Open Loop Power Control
3.4 UL Rate Matching Attributes
SRBDCCH3_4KCSDTCH12_2K
PSDTCH64KPSDTCH128KPSDTCH384K2PSDTCH64K...
UlRbSetConf
SRBDCCH3_4KCSDTCH12_2K
PSDTCH64KPSDTCH128KPSDTCH384K2PSDTCH64K...
S-RNC
D-RNC
ulRateMatchingAttributeEntry
(UlRateMatchingAttributeList)
iurMinRateMatchingAttributeiurMaxRateMatchingAttribute
(DynamicParameterPerDch)
CSDTCH64K
UlRbSetConf
CSDTCH64K
� Rate matching is done to adapt the bit rate so that after transport channel multiplexing, the bit rate is
adapted to the capability of the underlying physical channel.
� Rate matching consists of repeating or puncturing bits in the radio frame. Each Transport Channel is
assigned a rate matching attribute by higher layers. This attribute is used to calculate the number of
bits to be repeated or punctured.
� Rate matching attribute (part of the transport format) is used to control the relative rate matching
between different transport channels multiplexed together onto the same physical resource. By
adjusting this attribute the quality of different services can be fine tuned to reach an equal or near-
equal symbol power level requirement.
� In UL, rate matching may vary on a frame-to-frame basis to fill up the physical channel. The Uplink rate
matching attribute is strongly related to DPDCH/DPCCH power difference and therefore to the
appropriate behavior of UL power control and resulting UL Quality of Service.
Note: A check is done by the Drift RNC when receiving a RNSAP Radio Link Setup message regarding the value of the uplink rate matching attribute, so that the value belongs to a specific range, given by the
two attributes iurMinRateMatchingAttribute and iurMaxRateMatchingAttribute.
Section 6 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 20
4 Outer Loop Power Control
Section 6 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 21
4 UL Outer Loop Power Control
4.1 SIR Target Management
CSDTCH12_2K
PSDTCH64KPSDTCH128KPSDTCH384K2PSDTCH64K...
CSDTCH12_2Kx4SRBDCCH3_4K2PSDTCH64Kx4SRBDCCH3_4KCSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K
PSDTCH64Kx4SRBDCCH3_4KPSDTCH384Kx4SRBDCCH3_4KStandaloneSRBDCCH3_4K...
initialSirTarget (UlUsPowerConf)
blerTarget(BlerQualityList)
New SIR Target
(NBAP)
CRCI
RNC
PartialOLPC
UlUserService
CSDTCH64Kx4SRBDCCH3_4K
UlRbSetConf
CSDTCH64K
SRBDCCH3_4K
blerTarget(BlerQualityList)
CRCI
PartialOLPC
OLPCMaster
SIR TargetUpdate
referenceUlRbSetConfId(ReferenceUlRbSetList)
isUlOuterPCActivated (UlOuterLoopPowerCtrl)
� The initial SIR target is sent by the RNC to the Node B through initialSirTarget parameter. This parameter is instantiated per RAB. Consequently, once the RNC has matched a RB onto the RAB
requested by the Core Network, it points to the initial SIR target value corresponding to this RB in the
initialSirTarget parameter. This value is transmitted to the Node B using NBAP signaling at each RADIO
LINK SETUP or reconfiguration.
� For each UlUserService, the list of radio bearers (UlRbSetConf) used in the multiple reference OLPC is given through the referenceUlRbSetConfId parameter.
� The outer loop power control algorithm takes into account all transport channels. For each transport
channel a separate outer loop machine is run. Each outer loop machine updates its partial SIR target
according to its transport channel quality target (UlBlerTarget) as soon as it receives at least one transport block CRC. The partial SIR target is then sent to the outer loop power control master.
� The OLPC master determines the new SIR target as:
� The maximum partial SIR target if at least one OLPC machine increases its partial SIR target
� The minimum partial SIR target if all OLPC machines reduce their partial SIR target
� Whenever the new SIR target is different from the old one, it is sent to the Node B.
Section 6 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 22
4 UL Outer Loop Power Control
4.2 Partial SIR Target Update
minSirTarget (UlUsPowerConf)
maxSirTarget (UlUsPowerConf)
SIR Target
TTI
transmitTimeInterval (static)
If CRCI bad
SIR Target
If CRCI good
SIR Target
ulUpSirStep
ulUpdatePeriod (UlOuterLoopPowerCtrl)Update Period = Max [TTI of ReferenceUlRbSetList] x
ulUpSirStep (UlRbSetConf / DynamicParameterPerDch)blerTarget (BlerQualityList)
ulUpSirStep
1
BlerTarget- 1
updateThreshold (DynamicParameterPerDch)Triggered Update if SIR Variation ≥
� The RNC computes actualized partial SIR targets every TTI. The TTI value in milliseconds is given by the
transmitTimeInterval static parameter relative to the TrCHs used as references for the outer loop power control. The reference TrCHs depends on the service type.
� Each outer loop machine updates its partial UL SIR target according to its transport channel UL quality
target (BlerTarget) as soon as it receives at least one transport block CRC. An update from each OLPC machine to the OLPC master is sent every update period or if the SIR target variation exceeds an upper
limit (updateThreshold).
� The update period is defined by ulUpdatePeriod, and is provided in a number of TTIs.
� When updating the SIR target at the Node B, the RNC sends on the user plane a specific control frame,
called Outer Loop Power Control, to the Node B. Consequently, for a given DPCCH, the period between
two uplink SIR target updates cannot be shorter than the shortest TTI of the DL associated transport
channels.
In UA7.1 a new parameter enablePeriodicSirTargetUpdate is introduced to enable or disable the periodicsending of Sir target when computed Sir Target is equal to last value. This occurs when there is no traffic
or at the Sir target boundaries.
Section 6 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 23
4 UL Outer Loop Power Control
4.3 OLPC Based on Quality Estimator: QE
•SIR target
Quality Estimate
•CRC error
QEThresholdForUlOlpc
1 1
2 1
1
Partial_UL_SIR_Target += [Nerr*UL_UPSTEP] – [( N – Nerr)*UL_DOWNSTEP]
QE ≤ QeThresholdForUlOLPC
2
Partial_UL_SIR_Target += [Nerr*UL_UPSTEP]
QE > QeThresholdForUlOLPC
1
When QeThresholdis reached
only the bad samplesare considered in OLPC computation
ulUpSirStep
1
BlerTarget- 1
qeThresholdForUlOlpculUpSirStep
DynamicParameterPerDch
BlerQualityList
blerTarget
UlRbSetConf
From UA7 onwards an option is provided to also use the QE information to calculate the UL SIR target value.
3GPP defines 2 kinds of Quality Estimates which can be provided by the NodeB to the RNC:
� QE vs TrCh BER is specified in 3GPP 25.133
� QE vs PhCh BER is specified in 3GPP 25.133
Quality Estimate is provided by the NodeB in DCH FP UL frames. Type of QE depends on qeSelector IE in
NBAP Radio Link Setup/Reconfiguration messages:
� qeSelector = 'Selected' means QE = transport channel BER.
� qeSelector = ‘Non-Selected’ means QE = physical channel BER
In ALU UTRAN, QeSelector is set by the RNC as follows:
� non-selected: AMR 2nd DCH subflow and AMR 3rd DCH subflow
� selected: all other DCH
Advantages: - QE is more accurate in average- Provides a QE threshold above which we prevent the Sir to decrease even if CRC passed
Potential drawbacks: - QE can be very variant instantaneously making difficult to set a unique threshold for a given service- If behavior xCEM vs iCEM is different � different settings
Section 6 � Module 1 � Page 24
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 24
4 UL Outer Loop Power Control
4.4 Accelerated SIR Target convergence based on QE
QE
CRC error
SirTarget
AcceleratedSirDownCountThreshold
Nerr >0 or QE ≥ acceleratedSirDownQeThreshold
2
GoodFrameCount = 01
11 1
Nerr=0 and QE < acceleratedSirDownQeThreshold GoodFrameCount ++
IF GoodFrameCount > acceleratedSirDownCountThreshold
THEN
Partial_Ul_Sir_Target -= acceleratedSirDownStep
2
AcceleratedSirDownQEThreshold
Max Sir Target
Min Sir Target
Initial Sir Target
acceleratedSirDownQeThresholdacceleratedSirDownCountThreshold
AcceleratedSirDownStep
DynamicParameterPerDch
UlRbSetConf
� The accelerated SIR Target convergence mechanism is based on consecutive number of “good” frames and is used to enable faster convergence when a certain number of consecutive “good” frames are received.
� This mechanism is applicable at call setup/reconfiguration and during the call.
� This mechanism aims to complement the existing Validity Condition algorithm also called Initial Convergence algorithm which applies at call setup only. When one mechanism is active, the other is not.
Advantages:
- Faster convergence in good radio conditions
- Reduced UL power, increased capacity
Potential drawbacks:
- Underestimation of Sir can lead to BLER and SIR spikes and ping-pong in OLPC adjusments
Section 6 � Module 1 � Page 25
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 25
5 UL Inner Loop Power Control
Section 6 � Module 1 � Page 26
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 26
5 UL Inner Loop Power Control
5.1 DPCCH Inner Loop Power Control
DL DPCCH Tx Power Commands
New UL DPCCH Tx power
Data1PLTPC
TFCI
Data2 PL
� The Uplink Power Control is controlled by the NodeB which orders Power Control Command (increase or
decrease) through TPC bit in DL DPCCH channel.
� The UE then applies the PC command at the next UL DPCCH transmission.
� DPDCH power is then adapted thanks to gain factors as seen previously.
Section 6 � Module 1 � Page 27
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 27
5 UL Inner Loop Power Control
5.2 UL Inner Loop Power Control
Rake
SIRestimate
SIRTarget
> or <TPC0 or 1
Pilot
TPC
DPCCH
• Down Command:
if SIRestimate > SIRtarget then TPC = 0
• Up Command:
if SIRestimate < SIRtarget then TPC = 1
� The uplink inner loop power control algorithm is located in the Node B physical layer. It is a fast
procedure (up to 1500 Hz power change rate) used to derive power control commands (to be applied by
the UE) from the SIR target (set by the RNC) and UL measurements.
� The Node B estimates the instantaneous SIR on the pilot bits received on the UL DPCCH and compares it
to the SIR target signaled by the RNC. In case the instantaneous SIR is lower (respectively higher) than
the target SIR, an up (respectively down) command is sent to the UE in the downlink DPCCH TPC field of
each DPCCH radio time slot:
up command: TPC = 1
down command: TPC = 0
� In every slot, there is either an up or a down power control command: this process does not provide
good stability of the transmission power.
� TPC commands are computed in each Node B independently from the others, so if the UE is in Soft
Handover with several Node Bs, the TPC commands received from the different Node Bs may be
conflicting. In the case of a softer handover, the unique Node B involved sends the same TPC command
on all the radio links of the same radio link set.
Section 6 � Module 1 � Page 28
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 28
5 UL Inner Loop Power Control
5.3 UL Power Control Algorithms
Soft handover
possibly different TPC commands
Softer handover
identical TPC commands
for the radio link set
2 RLs
Node B 1
1 RL
SIR target
SIR target
TPC2
TPC1
In case of soft HO(i.e. TPC1 ¹ TPC2)
UE combines TPCsaccording to the selected
algorithm
algo1 algo2
One TPC_cmd
powerCtrlAlgo (UlInnerLoopConf)
TPC2 RNCNode B 2
� In the case of soft handover (where TPC commands come from different Node Bs), the UE has to
combine different TPCs in order to derive one single internal TPC_cmd (internal power control
command applied to adjust the UL transmission power).
� There are 2 standardized algorithms (named: algorithm 1 and algorithm 2 in the 3GPP Specifications)
for the UE to process TPC commands.
� The choice between these two algorithms is under the control of the RNC 1000, and is managed through
powerCtrlAlgo parameter (manufacturer parameter).
� It is UE specific in the sense that a specific message is sent to each UE in order to indicate which
algorithm to use, but Alcatel-Lucent sets the same value for all cells managed by an RNC.
Section 6 � Module 1 � Page 29
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 29
5 UL Inner Loop Power Control
5.4 UL Inner Loop Algorithm 1
Algorithm allows the UE to derive a single TPC_cmd per slot
1DL DPCCH TCP field 1 0 0
Algo1 output +1 +1 -1 -1
x ulTpcStepSize
1DL DPCCH TCP3 field 0 0 0
Algo1 output +1 +1 -1 -1
x ulTpcStepSize
1DL DPCCH TCP2 field 1 0 0
1DL DPCCH TCP1 field 1 1 0
UE Tx output power UE Tx output power
ulTpcStepSize (UlInnerLoopConf)
Algo 1: PC rate = 1500 Hz (T=666 µs)
•no soft HO: UE derives a TPC_cmd
from the TPC command received for
each slot
•soft HO: UE has to combine TPCsfrom different radio link sets and
deduces a single TPC_cmd
•TPC_cmd = -1, +1
Soft HandOver
powerCtrlAlgo = algo1
� This algorithm is well adapted for average speed UEs in urban or suburban environments. The principle
of algorithm 1 is that the UE adjusts its DPCCH transmission power every slot (frequency = 1500 Hz),
according to TPC_cmd (internal power control command applied to adjust the UE transmission power)
derived from the TPC commands received from all Node Bs involved in the communication.
� We can distinguish three cases of TPC_cmd generation:
� No macrodiversity: the UE receives a single TPC command in each slot (on the single radio link
established for the communication), from which it derives a TPC_cmd as follows:
� if TPC command = 0, then TPC_cmd = -1
� if TPC command = 1, then TPC_cmd = 1
� Softer handover: in this case, the UE is aware (from TPC combination index parameter transmitted
through RRC protocol) that it will receive identical TPC commands in the downlink. The UE is then
able to combine these commands into a single TPC command, for example (UE implementation is
proprietary) using maximum ratio combining with all TPC commands received in order to optimize the
TPC command decoding.
� Soft handover: in this case, the TPC commands may be different. This case may even involve a softer
handover (from which a single TPC is derived, using for example MRC). The UE has first to use soft
decision in order to decode the different TPC commands transmitted. Then it has to combine them in
order to deduce a single TPC_cmd value.
� Then, after deriving a unique TPC_cmd, the UE implements a power change based on the
ulTpcStepSize parameter of the UlInnerLoopConf object.
Section 6 � Module 1 � Page 30
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 30
5 UL Inner Loop Power Control
5.5 UL Inner Loop Algorithm 2 (no SHO case)
1DL DPCCH TCP field 1 1 1
Algo2 output +1
UE Tx output power
1 0 0 0 0 0 1 1 0 0 0
-1 0
x ulTpcStepSize
5 radio slots
No Macrodiversity
Algo 2: PC rate = 300 Hz (T=3,333 ms)
•no soft HO: UE derives a TPC_cmdfrom the TPC command received on a
5 slot-cycle basis
•soft HO: UE has to combine TPCs
from different radio link sets
•TPC_cmd = -1, 0, +1
Algorithm allows the UE to derive a single TPC_cmd
every 5 slots
powerCtrlAlgo = algo2
ulTpcStepSize (UlInnerLoopConf)
� This algorithm is adapted to high or low speed environments (typically: dense urban or rural). With this
algorithm, the UE concatenates N TPC commands received on consecutive radio slots to derive a
TPC_cmd to be applied after the Nth slot. N can be different according to the handover situation, but it
does always divide 15 (the combining window of the TPC commands does not extend outside the frame
boundary). Allowing a decision every N = 5 radio slots instead of every slot, algorithm 2 is a way of
emulating step sizes smaller than 1 dB (typically: 0.2 dB or 0.4 dB, corresponding to the step sizes of 1
and 2 dB respectively, but applied every 5 TS).
� Note: In the TPC combination algorithm 2, the TPC_cmd is either 1, –1 or 0.
� Algorithm 2 works in the following way:
� No macrodiversity: the UE concatenates commands received from 5 consecutive TS to derive a
TPC_cmd value:
� For the first 4 slots of a set, TPC_cmd = 0
� For the fifth slot of a set, the UE uses hard decisions on each of the 5 received TPC commands as
follows:
� if all 5 hard decisions within a set are 1, then TPC_cmd = 1
� if all 5 hard decisions within a set are 0, then TPC_cmd = -1
� otherwise, TPC_cmd = 0
� Softer handover: similarly to what happens for algorithm 1, for each slot, the UE soft-combines the
TPC commands known to be the same (received from the same Node B).
Section 6 � Module 1 � Page 31
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 31
5 UL Inner Loop Power Control
5.6 UL Inner Loop Algorithm 2 (SHO case)
1DL DPCCH TCPN FIELD 1 1 1
Algo2 output
+1
UE Tx ouput power
1 0 0 0 0 0 0 0 0 0 0
-1 -1
1DL DPCCH TCP1 field 1 1 1
+1
1 1 1 1 1 0 1 1 1 1 1
0 +1
1 1 1 0
0
1 0 0 0 0 0 1 0 1 0 1
-1 0
DL DPCCH TCP2 field
Sum of TPCN
> 0.5 < - 0.5 Otherwise
+ 1 - 1 0
x ulTpcStepSize
� Soft handover: the derivation of the TPC_cmd from the TPC commands of the different radio links is
done in the following way:
� First, the UE determines 1 temporary TPC command called TPC_tempi for each of the N sets of 5 TPC
commands. It is done as follow:
� If all 5 hard decisions within a set = 1, TPC_tempi = 1.
� If all 5 hard decisions within a set = 0, TPC_tempi = -1.
� Otherwise, TPC_tempi = 0
� Then the UE derives the combined TPC_cmd for the 5th slot as a function of all the N TPC_tempi:
� TPC_cmd = 1 if (Sum of TPC_tempi)/N > 0.5
� TPC_cmd = -1 if (Sum of TPC_tempi)/N < -0.5
� Otherwise TPC_cmd = 0
� Finally, after deriving a unique TPC_cmd, the UE implements a power change:
� Uplink Power Change = TPC_cmd x ulTpcStepSize.
Section 6 � Module 1 � Page 32
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 32
6 DL Traffic Channel Power
Section 6 � Module 1 � Page 33
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 33
maxDlTxPowerPerOls (DlUsPowerConf)
6 DL Traffic Channels Power
6.1 Initial DL Traffic Channel Power
First Radio Link
SHO Leg Addition
minDlTxPower (DlUsPowerConf)
Pinitial= pcpichPower (FDDCell*) + - P-CPICH_Ec /NoinitialDlEcNoTarget(DlUsPowerConf)
Pinitial= + - P-CPICH_Ec /No EquivalentinitialDlEcNoTarget(DlUsPowerConf)
cell = N
P-CPICH_Ec /No Equivalent = P-CPICH_Ec /No (cell)
cell =1
Scell = N
P-CPICH_Ec /No Equivalent = P-CPICH_Ec /No (cell)
cell =1
∑
isShoLegInitialPowerAlgoEnabled (RadioAccessService)
pcpichPower (FDDCell*)
� When a traffic (dedicated) channel is setup, it is done at a certain downlink power called Pini defined
by the following equation:
� Pini = pcpichPower + initialDlEcnoTarget – CPICH_Ec/No
� Where pcpichPower is the downlink P-CPICH power, initialDlEcnoTarget depends on the service
allocated to the UE (access stratum configuration) and CPICH_EC/N0 is the EC/N0 of the Pilot received
by the UE.
� The Pini is used in the Call Admission Control downlink power reservation algorithm.
� The downlink transmission power is limited by an upper and lower limit for each radio link. This
limitation is set through the maxDlTxPowerPerOls and minDlTxPower parameters (DlUsPowerConfobject). Both parameters provide actually a value for each access stratum configuration, so they
correspond to a set of values rather than to a single value. The value (in dB) of these parameters is
provided with respect to P-CPICH power defined by the pcpichPower parameter.
� For SHO Leg Addition, the initial power is calculated once for all the new links to be added. Pini
depends not only on the CPICH Ec/No of the selected cell to be added, but on all the CPICH Ec/No of
the cells of the old active set.
� An equivalent CPICH Ec/N0 is calculated:
∗= ∑=
N
i
celliNEcCPICH
equivdBNEcCPICH
1
10)(0/
100/_ log10)(
Section 6 � Module 1 � Page 34
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 34
6 DL Traffic Channels Power
6.2 DL DPCCH / DPDCH Power Offsets
Data1Pilot TPC TFCI
PinitialPO3 PO1
PO2
po3ForPilotBits (DlUserService)
DL DPDCH Radio Frame
po2ForTpcBits (DlUserService)
po1ForTfciBits (DlUserService)
� The RNC can also configure static downlink physical channel parameters in the Node B. In the downlink
it is possible to give power offsets to the pilot, TPC and TFCI fields of the DPCCH relative to the DPDCH.
� They are given at radio link setup in the Power Offset information IE:
� PO1: TFCI bits
� PO2: TPC bits
� PO3: pilot bits
� In the Alcatel-Lucent implementation, the power offsets used to determine the transmission power of
the TFCI, TPC, and PILOT bits are defined by the po1ForTfciBits, po2ForTpcBits and po3ForPilotBitsparameters respectively.
� These parameters of the DlUserService object are transmitted in the Power_Offset_Information IE of
the RADIO LINK SETUP, ADDITION or RECONFIGURATION (NBAP signaling). They are identical for all TFC
in the TFCS.
Section 6 � Module 1 � Page 35
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 35
6 DL Traffic Channels Power
6.3 DL Power Offset 2 as a Function of the AS size
isDynamicPO2Enabled(DlUserService)
Nb of RL Power Offset 2
1 po2ForOneRlSet
2 po2ForTwoRlSet
3 or more po2ForThreeRlSetOrMore
� The DL Power Control Management provides an option to dynamically configure different PO2 values
depending on the number of radio link sets (RLS) involved in the call.
� The PO2 value is variable depending on the number of RL involved in the call.
� The initial PO2 is provided to the NodeB in NBAP messages.
� Then, at each new RL Setup/Addition/Deletion, the RNC shall support the transmission of the RADIO
INTERACE PARAMETER UPDATE message over the Iub and Iur user plane interfaces, as per TS 25.427,
for the signalling of TPC PO updates.
Section 6 � Module 1 � Page 36
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 36
7 DL Outer Loop Power Control
Section 6 � Module 1 � Page 37
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 37
7 DL Outer Loop Power Control
7.1 DL Outer Loop Power Control
Initial Quality target
DL Outer Loop Control IE
Outer LoopPower Control
SR
B
TR
B
TPC
TX
RB Setup
BLERtarget increase not allowedor
BLERtarget increase allowed
inner looppower control
QualityMeasurements
RNC
isDlReferenceTransportChannelAllowed(DlRbSetConf)
blerTarget(DlBlerQualityList)
CSDTCH12_2K
PSDTCH64KPSDTCH128KPSDTCH384K2PSDTCH64K...
DlRbSetConf
CSDTCH64K
SRBDCCH3_4KisDlReferenceTransportChannelAllowed
blerTarget
CSDTCH12_2Kx4SRBDCCH3_4K2PSDTCH64Kx4SRBDCCH3_4KCSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K
PSDTCH64Kx4SRBDCCH3_4KPSDTCH384Kx4SRBDCCH3_4KStandaloneSRBDCCH3_4K...
DlUserService
CSDTCH64Kx4SRBDCCH3_4K
� The DL outer loop power control algorithm is mobile-manufacturer specific, and DL power control outer
loop is not necessarily based on SIR (as UL outer loop is). The only information signaled to the UE by the
RNC is a quality target for each radio bearer, expressed as a BLER. This quality target is sent to the UE
through RRC signaling (DL Outer Loop Control procedure) for each transport channel of the connection.
This quality target information is mandatory for handover to UTRAN, radio bearer setup and transport
channel reconfiguration messages. It is optional for radio bearer reconfiguration and release, RRC
connection setup, and re-establishment messages.
� The DL outer loop power control algorithm is located in the UE, but the RNC may further use the
downlink Outer Loop control procedure to control the DL outer loop algorithm in the UE. To prevent the
UE from increasing its DL BLER target value above its current value (the initial one, transmitted by the
RNC via RRC signaling), the RNC sets the “Downlink Outer Loop Control” IE to “increase not allowed”.
This allows reducing the impact of the UE proprietary outer loop algorithm on the system.
� isDlReferenceTransportChannelAllowed indicates that the first Transport Channel of the RbSetConf is allowed to be used as an Outer Loop Power Control Reference Transport Channel.
� BlerTarget is used if isDlReferenceTransportChannelAllowed is TRUE. BlerTarget is the BLER DL quality target which must be met during Outer Loop Power Control. It is the Log10 of the BLER.
Section 6 � Module 1 � Page 38
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 38
8 DL Inner Loop Power Control
Section 6 � Module 1 � Page 39
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 39
8 DL Inner Loop Power Control
8.1 DL Inner Loop Algorithm
TPC_ cmd x
Node BTPC = 0 / 1 UL DPCCH
PL TPCTFCI
TPC
TPC_ cmd
DL power change
New BTS output powerapplied to DPDCH
DL Power Change =
TPC =1=> TPC_ cmd = +1
TPC =0 => TPC_ cmd = -1
∆PTPC + ∆PBalancing
SPBAL
UE Algo
SHO
BLER est
dlTpcStepSize (DlInnerLoopConf)
BLER target
DL TX_PWR optimizationis UE constructor dependent
(not necessarilybased on SIR measurements)
� The DL inner loop power control algorithm is a fast procedure (1500 Hz) used to optimize DL
transmission power by sending power control commands to the Node B in the TPC field of UL DPCCH
time slots.
� At each TPC (Transmit Power Command = 0 or 1) field decoded (on UL DPCCH), the BTS estimates the
TPC_cmd (TPC command = -1 or 1) based on TPC and Limited_Power_Increase values, and implements a
DL power change as shown in the above slide.
� As the Limited_Power_Increase functionality is not implemented, TPC_cmd values are directly deduced
from TPC values as following:
� TPC = 0 => TPC_cmd = -1
� TPC = 1 => TPC_cmd = 1
� So TPC_cmd never has the value 0 (either decrease or increase command for the transmission power),
as with combination algorithm 2 for UL power control.
� The downlink power adjustment (increment or decrement according to the power control command)
step size is tuned through the dlTpcStepSize parameter. This parameter is transmitted by the RNC to the Node Bs using the TPC_DL_Step_Size IE contained in the RADIO LINK SETUP REQUEST message
(NBAP). It cannot be reconfigured during the connection. 3GPP TS allowed values are: 0.5 dB, 1 dB
(mandatory), 1.5 dB and 2 dB. Alcatel-Lucent implementation proposes only the two mandatory values:
0.5 dB and 1 dB.
Section 6 � Module 1 � Page 40
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 40
8 DL Inner Loop Power Control
8.2 Power Balancing
P1 P2
Power per Leg
RL Additiontime
P1
P2
isPowerBalancingAllowed (RadioAccessService)
powerBalancingRequired (DlUserService)
dlReferencePower(DlUserService)
maxAdjustmentStep (PowerBalancingAdjustmentParameters)
adjustmentPeriod (PowerBalancingAdjustmentParameters)
adjustmentRatio (PowerBalancingAdjustmentParameters)
Radio Frame
∑PBAL = (1 - R) x (PREF + PP-CPICH – PINIT)
PREF
∆PBalancing
� The objective of downlink power balancing function is to equalize powers on the different radio links,
eliminating power drifting effects.
� This function is triggered by the SRNC, which provides balancing parameters to the Node Bs and
executed by the Node Bs.
� The power balancing function brings a corrective factor Pbal which is added to the power as calculated
by the DL inner loop power control.
� This Pbal is such that
� SPbal = (1 – R).(Pref + Ppcpich – Pini)
� where:
� SPbal is the sum of these corrective factors over an adjustment period corresponding to a number of
frames
� Pbal = 0 or -0.5 or 0.5 dB (in first implementation)
� R is the adjustment ratio
� Pref is the value of the DL Reference Power
� Ppcpich is the power used on the primary CPICH
� Pinit is the power of the last slot of the previous adjustment period
� Instead of specifying which maximum correction should be applied to one slot, a period is specified, as
a number of time slots, where the accumulated power adjustment should not be greater than 1 dB.
� The above slide shows an example with SPbal = - 4 dB, adjustment period = 2 Radio Frames, max
adjustment step = 5 Time Slots.
Section 6 � Module 1 � Page 41
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 41
8 DL Inner Loop Power Control
8.3 Rate Reduction Algorithm
UL DPCCH
dpcMode (DlInnerLoopConf)
1 0 1 0 0 1
1500 TPC commands / s
DPC_Mode = 0 (single Tpc)
500 TPC commands / s
1 1 1 0 0 0
DPC_Mode = 1 (tpcTripletInSoft)
RRC signaling (from RNC)
PL TPCTFCIPL TPCTFCI
� The RNC may activate a rate reduction algorithm. If rate reduction algorithm is applied, then the UE
issues one new command every 3 slots and repeats it over 3 slots, so the DL inner loop TPC commands
frequency is divided by 3 (1500 Hz down to 500 Hz).
� This algorithm is controlled by the dpcMode parameter (DlInnerLoopConf object), which is signaled to the UE in the Downlink DPCH Power Control Information IE using RRC signaling:
� If dpcMode = singleTpc (0 on ASN1 interface), then the UE sends a specific TPC command in each
DPCCH time slot (starts in the first available slot).
� If dpcMode = tpcTripletInSoft (1 on ASN1 interface), then the UE repeats the same TPC command over
3 successive DPCCH time slots.
� On reception of TPC field in the UL DPCCH, the Node B processes the command depending on the
DPC_MODE and calculates PTPC(k):
� DPC_MODE = 0 => at each slot:
� PTPC(k) = TPCDLStepSize if TPC = up
� PTPC(k) = -TPCDLStepSize if TPC = down
� DPC_MODE = 1 => each 3 slots:
� PTPC(k) = TPCDLStepSize if 3 last TPCs are up
� PTPC(k) = -TPCDLStepSize if 3 last TPCs are down
Section 6 � Module 1 � Page 42
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 42
9 Radio Link Control
Section 6 � Module 1 � Page 43
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 43
9 Radio Link Control
9.1 UL Dedicated Channel Synchronization
SIRAV < -3dB => OutSyncInd
SIRAV > -3dB => InSyncInd
nInSyncInd (FDDCell*)nOutSyncInd (FDDCell*) tRlFailure (FDDCell*)
RL RestoreRL Failure
Sync OK Sync KO
INIT
nInSyncInd (FDDCell*)
nInSyncInd (FDDCell*)
nInSyncInd (FDDCell*)
nOutSyncInd (FDDCell*)
tRlFailure (FDDCell*)
rlRestoreTimerShoRlRestoreTimer
(RadioAccessService)
N313 T313 T315
FDDCell* ⇔FDDCell->Class2CellReconfParams->SynchronisationConfiguration
orFDDCell->Class2CellReconfParams->SynchronisationConfiguration
The uplink radio link sets are monitored by the Node B, to trigger radio link failure/restore procedures.
Once the radio link sets have been established, they will be in the in-sync or out-of-sync states.
When the radio link set is in the in-sync state, after receiving nOutSynchInd consecutive out-of-sync indications, the Node B shall:
� start timer tRlFailure;
� upon receiving nInSynchInd successive "in sync" indications from Layer1:
� Stop and reset timer tRlFailure;
� if tRlFailure expires:
� The Node B shall trigger the RL Failure procedure and indicates which radio link set is out-of-sync.
When the RL Failure procedure is triggered, the state of the radio link set will change to the out-of-
sync state.
� The RNC receiving a Radio Link Failure Indication message from the NodeB will trigger the call release
(call drop radio in this case) if no radio link remains in "in sync" state.
When the radio link set is in the out-of-sync state, after receiving nInSynchInd successive in-sync indications
Node B shall trigger the RL Restore procedure and indicate which radio link set has re-established
synchronization. When the RL Restore procedure is triggered, the state of the radio link set will change to
the in-sync state.
Similar Radio Link Control is implemented in DL in the UE thanks to UeTimerCstConnectedMode object parameters:
� n315 UE constant is analog to nInSynchInd
� n313 UE constant is analog to nOutSynchInd
� t313 UE timer is analog to tRlFailure
Activation Rules:
� (nOutSyncInd * 10) + tRLFailure < (n313 * 10) + t313 + PA off
� t315 > rrcReestPSMaxAllowedTimer
Section 6 � Module 1 � Page 44
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 44
9 Radio Link Control
9.2 UL Radio Link Failure – detected by UTRAN
Node B RNC CN
Radio Link Failure Indication
Radio Link
Deletion Resp
Iu Release Request“Radio cnx with UE lost”
Iu Release CommandRadio Link
Deletion Req
UE
UL synchronization failure on last RL
Iu Release Complete
bad SIR
nOutSyncInd
tRlFailure
expiryfalse
isPsRrcReestablishAllowedisCSRrcReestablishAllowed
(RadioAccessService)
A call drop is triggered as soon as the loss of the last RL is detected by the RNC.
isPsRrcReestablishAllowed (resp. isCSRrcReestablishAllowed) is the parameter used to activate or de-activate the RRC Connection Re-establishment feature for CS (resp. PS).
Section 6 � Module 1 � Page 45
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 45
9 Radio Link Control
9.3 DL Radio Link Failure – detected by UE
Node B RNC CN
Cell Update(radio link failure)
Radio Link
Deletion Resp
Iu Release Request“Radio cnx with UE lost”
Iu Release CommandRadio Link
Deletion Req
UE
DL synchronization failure on last RL
Iu Release Complete
bad SIR
N313
T313
expiry
false
t313n313
(UeTimerCstConnectedMode)
t314(UeTimerCstConnectedMode)
T314
isPsRrcReestablishAllowedisCSRrcReestablishAllowed
(RadioAccessService)
� A call drop is triggered as soon as the loss of the last RL is detected by the RNC.
Note : t314 must be set equal to a non-zero value so that the UE performs a Cell Update procedure.
Section 6 � Module 1 � Page 46
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 46
9 Radio Link Control
9.4 DL RLC Unrecoverable Error – detected by UTRAN
Node B RNC CN
Radio Link
Deletion Resp
Iu Release Request“DL RLC Error SRB/TRB”
Iu Release CommandRadio Link
Deletion Req
UE
Maximum number of RLC re-transmission reached
Iu Release Complete
maxDat
maxNbrOfResetRetrans
same RLC blocknot decoded
X
X
timerPoll
RLC Resetnot decoded
X
X
resetTimer
Maximum number of RLC Reset
re-transmission reached
false
timerPollPeriodmaxDat
resetTimermaxNbrOfResetRetrans
(DlRlcAckMode)(UlRlcAckMode)
isPsRrcReestablishAllowedisCSRrcReestablishAllowed
(RadioAccessService)
Section 6 � Module 1 � Page 47
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 47
9 Radio Link Control
9.5 UL RLC Unrecoverable Error – detected by UE
Node B RNC CN
Iu Release Request“UL RLC Error SRB/TRB”
Iu Release Command
Radio Link
Deletion
UE
Maximum number of RLC re-transmission reached
Iu Release Complete
same RLC block not decoded
X
X
RLC Resetnot decoded
Maximum number of RLC Reset re-transmission reached
false
Cell Update(rlc unrecoverable error)
isPsRrcReestablishAllowedisCSRrcReestablishAllowed
(RadioAccessService)
X
X
Section 6 � Module 1 � Page 48
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 48
9 Radio Link Control
9.6 RRC Connection re-establishment Parameters
isPsRrcReestablishAllowed = True
isCSRrcReestablishAllowed = True
Yes No
RRC connectionRe-establishment
Call is dropped
RNC
(failure Cause, CPICH_Ec/No)
P-CPIC
H
CPICH Ec/No
rrcReestablishPSThresholdrrcReestablishCSThreshold
(RadioAccessService)
CPICH_Ec/No >= rrcReestablishPSThreshold
Cell Upd
ate
Cell Update
Last RL lost detection
rrcReestPSMaxAllowedTimerrrcReestCSMaxAllowedTimer
(RadioAccessService)
rrcReestablishPSThreshold (resp. rrcReestablishCSThreshold) is the CPICH_EcNo threshold above which an RRC Connection Re-establishment for a CS (resp. PS) call can take place at the reception of the Cell
Update message coming from the UE.
rrcReestPSMaxAllowedTimer (resp. rrcReestCSMaxAllowedTimer) is the timer started by the RNC when it detects an UL Radio link Failure or a DL RLC Unrecoverable error on a CS (resp. PS) call.
Afterwards, either the RNC stops this timer if it receives a Cell Update message from the UE or it triggers
a call drop if this timer expires (no cell update received from UE).
Section 6 � Module 1 � Page 49
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 49
Cell Update Confirm
9 Radio Link Control
9.7 UL Radio Link Failure – RRC Connection Re-established
Node B RNC CN
Radio Link Failure Indication
Radio Link Deletion
UE
UL synchronization failure on last RL
tRlFailure
expiry
true
Cell Update (radio link failure)
Radio Link Setupstopped
RB Reconfiguration Complete
isPsRrcReestablishAllowedisCSRrcReestablishAllowed
(RadioAccessService)
rrcReestPSMaxAllowedTimerrrcReestCSMaxAllowedTimer
(RadioAccessService)
� A similar scenario can occur in case the UE detects a DL Radio Link Failure: the RNC receives a Cell
Update from the UE without expecting it.
Section 6 � Module 1 � Page 50
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 50
9 Radio Link Control
9.8 UL RLC Unrecoverable Error – RRC Con. Re-established
Node B RNC CNUE
Maximum number of RLC
re-transmission reached
same RLC block not decodedon PS TRB X
X
RLC Resetnot decoded
X
XMaximum number of RLC Reset
re-transmission reached
Cell Update(rlc unrecoverable error
on PS TRB)
Cell Update Confirm
RB Reconfiguration Complete
Radio Link Deletion
Radio Link Setup
true
isPsRrcReestablishAllowedisCSRrcReestablishAllowed
(RadioAccessService)
� This scenario applies only for (CS+PS) calls case because there is no TRB established in RLC ACK mode
for CS calls but TM mode is used. For CS call case, the RLC unrecoverable error can occur on SRB only,
leading to a call drop.
Section 6 � Module 1 � Page 51
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 51
9 Radio Link Control
9.9 RRC Connection re-establishment - Summary
In case of Radio Link Failure
In case of RLC Unrecoverable Error
Call Type
DCCH (SRB) DTCH(TRB) DCCH (SRB) DTCH(TRB)
PS Only (DCH) Re-establish Re-establish Drop Call Re-establish
CS Only Drop Call N/A Drop Call N/A
PS + CS (DCH) Drop Call Drop PS Drop Call Re-establish
PS Only (FACH) Re-establish Re-establish Drop Call Re-establish
RNC RLC UE RLC
Call Type
PS Only (DCH)
CS Only
PS + CS (DCH)
PS Only (FACH)
RNC RLF UE RLF
Re-establish Re-establish
Re-establish Re-establish
Re-establish Re-establish
Re-establish Re-establish
Section 6 � Module 1 � Page 52
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 52
Module Summary
This lesson covered the following topics:
� Power management static configuration
� PRACH Power Control and associated parameters
� UL Power Control and associated parameters
� DL Power Control and associated parameters
� Radio Link Control and associated parameters
Section 6 � Module 1 � Page 53
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 53
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 6 � Module 1 � Page 54
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionPower Management �
6 � 1 � 54
End of Module
Section 7 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
7�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 7Call Management
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 7 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 2
Blank Page
This page is left blank intentionally
Update due to new UA7 features:• FACH to DCH or PCH states enhancements• One shot Ec/No report• Initial Rate Capping during RB reconfig.• RB Rate Adaptation enhancements• PS CN requested RAB modification
Chatila, RayanRyser, SigridCharneau, Jean-Noel
2009-04-1501
RemarksAuthorDateEdition
Document History
Section 7 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Describe Call Management principles
� Describe Always On and associated parameters
� Describe RB Rate Adaptation and associated parameters
� Describe iRM Scheduling and associated parameters
� Describe iRM Preemption and associated parameters
� Describe Preemption Process for DCH ad HSDPA/HSUPA
� Describe AMR Rate Change during the call
� Describe PS Core Network requested RAB modification
Section 7 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 7 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 5
Table of Contents
Switch to notes view!Page
1 Call Management Overview 71.1 Call Management Mechanisms 8
2 Always On 92.1 Always On Downsize Principles 102.2 Always On Upsize Principles 112.3 Always On Downsize Parameters 122.4 AO Upsize UL Parameters (FACH to DCH) 132.5 AO Upsize DL Parameters (FACH to DCH) 142.6 AO Upsize Cell_Fach to Cell_DCH Transition 152.7 One Shot Ec/No Report 162.8 RRC states transitions 172.8.1 URA_PCH Transitions if CELL_PCH is used 182.8.2 URA_PCH Transitions if CELL_PCH is not used 192.8.3 CELL_PCH Transitions 202.8.4 URA Update in URA_PCH state 212.8.5 Cell Update in CELL_PCH state 222.8.6 Cell Update in CELL_FACH state 232.8.7 Cell Reselection during Cell_Fach to Cell_DCH 24
2.9 PCH States configuration 252.10 AO Step 2 and AO Step 3 Timers 262.11 Definition of isAlwaysOnAllowed (xxRbSetConf) 272.12 Exercise : Find the parameter values 282.13 Mono-Service PS/Multi-RAB PS I/B R99 (R99 PS Mux) 292.14 Multi-Service CS+PS 302.15 Recovery actions CELL_FACH admission failure 312.16 URA (UTRAN Registration Area) 322.17 User Services Parameters 332.18 Exercise : Find the RRC states transitions 34
3 RB Rate Adaptation 363.1 RB Rate Adaptation Principles 373.2 Traffic Monitoring : UL & DL Throughput 383.3 DL Downsizing 393.4 UL Downsizing 403.5 DL Multi-Stage Upsizing 413.6 UL Step by Step Upsizing 423.7 UL upsizing based on UE Buffer Occupancy 433.7.1 Event4A Processing without UE Tx Power info 443.7.2 Event4A Processing with UE Tx Power info 45
3.8 DL upsizing based on RNC Buffer Occupancy 463.8.1 Internal RNC Event Processing 47
3.9 Ping Pong Timers 483.10 Measurement Configuration 493.11 RAN Model 503.12 Exercice 51
4 iRM Scheduling 524.1 iRM Scheduling Principles 534.2 Event A for iRM Scheduling Downgrade 544.3 Events B1 and B2 for iRM Scheduling Upgrade 554.4 iRM Scheduling Upgrade 564.5 PS Streaming RAB: iRM Scheduling 574.6 iRM Scheduling Parameters for Downgrade 584.7 iRM Scheduling Parameters for Upgrade 59
5 iRM Preemption 605.1 iRM Preemption Algorithm 615.2 iRM Preemption: Downgraded DL RB 62
Section 7 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 6
Table of Contents [cont.]
Switch to notes view!Page
5.3 Cell Color / Active Set Color Calculation 635.4 iRM Preemption Behavior 645.5 Interaction with iRM RAB to RB Mapping 65
6 Preemption Process for DCH and HSDPA/HSUPA 666.1 Concepts 676.2 Eligible Procedures 686.3 Eligible CAC Failure Cases 696.4 Internal or External CAC failures 706.5 Eligible Transport Channel 716.6 Eligible Services 726.7 Selection of service to be pre-empted 736.8 Mono-Step / Multi-Step Pre-emption 746.9 Selection of service to be downgraded 756.10 Estimation of Resource De-allocation 766.11 Queuing of RAB Assignment Request 776.12 Feature dependencies 786.13 Feature Interactions 796.14 Exercise1: RAB Assignt Queuing and Pre-emption 806.15 Exercise2: Estimation of Resource De-allocation 81
7 AMR Rate Change during the Call 827.1 General Principles 837.2 Iub DS load criteria 857.3 UL Cell load criteria 867.4 DL Power load criteria 877.5 DL Tx CP criteria 887.6 Parameters Settings 89
8 PS CN Requested RAB Modification 938.1 PS CN Requested RAB Modification 948.2 RAB Modification in a Non-Iur Scenario with SRLR 958.3 RAB Modification in a Non-Iur Scenario without SRLR 97
Section 7 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 7
1 Call Management Overview
Section 7 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 8
1 Call Management Overview
1.1 Call Management Mechanisms
Dedicated Channel
Dedicated Channel
Dedicated Channel
UMTS R9
9
����
��������Background
��������PSInteractive
����PSStreaming
��������Streaming
��������Conversational
Always OnDomainService Class
����
����
����
����
����
RB RateAdaptation
������������PSBackground
������������PSInteractive
��������PSStreaming
������������CSStreaming
������������CSConversational
iRMPreemption
iRMSchedulingAlways OnDomainService Class Preemption
����
����
����
����
����
AMR RateChange
Call Management is a set of reactive mechanisms performed during the call to satisfy four objectives:
� Increase capacity of the system by taking advantage of user traffic burstiness: Always On mechanism
adapts the resources allocated to users according to their activity (two steps mechanism depending on
whether there is low traffic or no traffic at all).
� Increase capacity of the system by taking advantage of user traffic burstiness: RB Rate Adaptation saves
more capacity by matching dynamically the RB bit rate as closely as possible to the real user traffic. It
allows adaptation of the bandwidth for services requiring more than the Always-On downsized RB but
less than the current RB.
� Improve retainability of the calls: iRM Scheduling adapts the resources to the radio conditions
fluctuation. iRM Scheduling downgrading secures the call by reducing the amount of downlink power
required in degraded radio conditions, whereas iRM Scheduling upgrading enhances subscriber
experienced quality by providing a higher throughput when radio conditions improve.
� Increase capacity at the expense of call retainability: iRM Preemption allows the bit rate of low priority
users to be reduced or even to be pre-empted in order to increase the admission success rate of CS calls
or high priority users in congested situations. It is performed when all other preventive congestion
mechanisms are insufficient to free resources quickly enough to maintain sufficient accessibility to the
network.
� Increase capacity or QoS at the expense of throughput or call retainability: Preemtion process for DCH
and HSDPA/HSUPA allows some high priority calls to be established at the expense of PS call throughput
degradation or at the expense of forcing lower priority PS or CS calls to be dropped
� Increase capacity at the expense of voice quality: AMR rate Change during the call allows to force AMR
rate downgrade when some radio resource become scarce in the cell
Most of these Call Management features operate only on UMTS PS I/B RABs since no Guaranteed Bit Rate is
defined for such traffic classes. However, iRM Scheduling is also available for PS Streaming services so as
to avoid call drops when UE moves in poor radio quality areas. Preemtion process applies to any types of
call wherease AMR rate change applies to Multi-Mode AMR calls only.
Section 7 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 9
2 Always On
Section 7 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 10
2 Always On
2.1 Always On Downsize Principles
CELL_FACH
Throughput ThresholdThroughput ThresholdAO Step 1AO Step 1
User Traffic Volume
T1
AO timers
T1 T2
T1 T2
T1
PMM-idle
NOMINAL DCH RB No Radio Bearer
Throughput ThresholdThroughput ThresholdAO Step 2AO Step 2
T1
CELL_DCH
AO FACH RB
RRC Context
trafficinactivity
CELL_PCHor
URA_PCH
T3
traffic and signalinginactivity
isAlwaysOnAllowed (AlwaysOnConf)isAlwaysOnAllowed (DlUserService)isAlwaysOnAllowed (UlUserService)
No Radio Bearer
No RRC Connection
O kbpsO kbps
AO step1 AO step2 AO step3
Dedicated radio resources are not optimal to support packet services with sporadic traffic. In order to find
the best trade-off between efficient resource usage and subscriber comfort, the Always On concept
developed is composed of three steps.
After a first period of low activity (T1), the bearer is reconfigured to a predefined downsized bearer
configuration, which consumes less radio resources.
If traffic activity is detected, the bearer is upgraded back to its initial configuration (or to a degraded one
if network congestion is meanwhile detected).
If no traffic activity is detected during a second period of time (T2), then the radio bearer is released but
the RRC connection remains as well as the Iu Connection in order to speed up the needed radio bearer
setup in case or user traffic resumption.
If neither traffic nor signaling activity is observed during a third period of time (T3) then the RRC and Iu
connection are released but the following context info remains between UE and Network:
� the PDP context at the SGSN
� the PPP (or IP) link between UE and ISP
� the SGSN-GGSN tunnel
� When downsize criteria is met, the Always-On downsized RB (FACH) is determined at the OAM, thanks
to the following parameters:
� DL downsized RB: alwaysOnDlRbSetFachId (AlwaysOnConf object)
� UL downsized RB: alwaysOnUlRbSetFachId (AlwaysOnConf object)
Section 7 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 11
2 Always On
2.2 Always On Upsize Principles
CELL_FACH
Throughput ThresholdThroughput ThresholdAO Step 1AO Step 1
User Traffic Volume
AO timers
TTT
NOMINAL DCH RBNo Radio Bearer
Throughput ThresholdThroughput ThresholdAO Step 2AO Step 2
CELL_DCH
AO FACH RB
RRC Context
O kbpsO kbps
AO step2
CELL_PCHor
URA_PCH
AO step2
trafficresuming
In Cell_PCH or URA_PCH states, although the connection is no more active, the mobile keeps its PDP
context active.
� Therefore, a traffic resume is done either:
� By the mobile, which re-establishes a connection to the network
� Or by the network by paging the mobile, which would have the effect of creating a new connection.
The dataflow is the same as the mobile initiated resume except for the paging phase.
In Cell_FACH state, the RNC assess the user data throughput and decides to perform an AO upsize to DCH
radio bearer if the high user throughput is detected.
Section 7 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 12
2 Always On
2.3 Always On Downsize Parameters
step2ThroughputThreshold (AoOnFachParam)
T2 timer depends on RRC states usage
T2
step2AverageWindow (AoOnFachParam)
T1
step1DlUlThroughputThreshold (AoOnFachParam)
timerT1 (AlwaysOnTimer)
step1AverageWindow (AoOnFachParam)
Ul & DL Traffic Volume
NOMINAL DCH RB AO FACH RB No Radio Bearer
step1TimerBetween2Reports (AoOnFachParam)
The AO downsize step1 condition is based on DL and UL traffic volume monitoring on non-sliding time
windows. The downsize criterion is met if:
� (TBsize x NbTB) / Step1AverageWindow < Step1DlUlThresholdThroughput
during at least TimerT1.
With:
� NbTB: Number of Transport Blocks transferred during the time window
� TBsize: size of a L1 Transport Block (in bits)
AO Downsize is performed when UL and DL criteria are met.
The AO downsize step2 decision is based on DL and UL traffic volume monitoring on non-sliding time
windows. The release criterion is met if:
� (TBsize x NbTB) / Step2AverageWindow < Step2ThresholdThroughput
� at least during TimerT2 seconds
The UE may keep or not its RRC connection or not depending on the usage of the Cell_PCH/URA_PCH states
or not.
Section 7 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 13
2 Always On
2.4 AO Upsize UL Parameters (FACH to DCH)
Reporting event4a
Upsize
repThreshold (AoOnFachParam)
UE RLC/MAC Buffer Occupancy
Reporting event4a
timeToTrigger (AoOnFachParam) pendTimeAfterTrig (AoOnFachParam)
Report
NOMINAL DCH RBAO FACH RB
AO Upsize is performed when UL or DL criteria are met.
As the upsize conditions are applied as the mobile is using common UL and DL resources (RACH/FACH) these
conditions cannot be based on observed user traffic. The principle is that these conditions will be based
on RLC buffer occupancy, reflecting the state of congestion of the transport channel (see following two
slides).
The UL upsize condition relies on event triggered UE traffic volume measurement on RACH Transport
Channel, based on event 4A.
� As the sum of Buffer Occupancies of RBs multiplexed onto the RACH exceeds a certain threshold
(RepThreshold), the mobile performs an event triggered reporting.
� On reception of this event, the SRNC considers the UL upsize condition as fulfilled.
� The pendTimeAfterTrig timer is started in the UE when a measurement report has been triggered by a
given event. The UE is then forbidden to send new measurement reports triggered by the same event
during this time period. Instead the UE waits until the timer has expired.
� The timeToTrigger timer is started in the UE when the Transport Channel Traffic Volume triggers the
event. If the TCTV crosses the threshold before the timer expires, the timer is stopped. If the timer
expires then a report is triggered.
Section 7 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 14
2 Always On
2.5 AO Upsize DL Parameters (FACH to DCH)
step1DlRlcBoThreshold (AoOnFachParam)
Upsize
UpsizeRequired
RLC/MAC Buffer Occupancy per UE
step1TimerBetween2Reports ((OnFachParam)
NOMINAL DCH RBAO FACH RB
The DL upsize condition relies on the same kind of mechanism. As the sum of Buffer Occupancies of RBs
multiplexed onto the FACH exceeds a certain threshold for a given UE, the SRNC considered the DL upsize
condition as fulfilled.
The parameter Step1TimerBetween2Reports is used to avoid sending unnecessary “upsize required” event
reports during the execution of the upsize procedure. This parameter sets the minimum time between
the emissions of two events "upsize required" by the RNC-IN.
Section 7 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 15
2 Always On
2.6 AO Upsize Cell_Fach to Cell_DCH Transition
RB Reconfiguration
RNC
CELL_DCH
Nominal RB
CELL_FACH
Fallback RB
RB Reconfiguration
reconfigTimeFachDch(FachRetransmissions)
RB Reconfiguration x N
reconfigRetriesFachDch(FachRetransmissions)
RB Reconfiguration Complete
isOamCappingOfDataAllowed(RadioAccessService)
maxDlRateTransitionToDchDlTriggerDchAndDch maxDlRateTransitionToDchUlTriggerDchAndDch maxUlRateTransitionToDchDlTriggerDchAndDch maxUlRateTransitionToDchUlTriggerDchAndDch
(DchRateCapping)
maxDlEstablishmentRbRatemaxUlEstablishmentRbRate
(CacConfClass)
= True
= False
From UA7 onwards the AO success rate during the Cell-Fach to DCH can be improved by repeating the
message RB Reconfiguration:
� reconfigTimeFachDch: defines the timer for retransmission of reconfiguration messages in Cell FACH due to response message timeout for Cell_FACH to Cell_DCH transition
� reconfigRetriesFachDch: defines the maximum number of reconfiguration message retries to transmit for Cell FACH to Cell_DCH transition
The data rates allocated in the AO upsize procedure is limited:
� If the flag isOamCappingOfDataAllowed is set to False then the parameters maxUlEstablishmentRbRate and maxDlEstablishmentRbRate limit the data rates.
� If the flag is set to True another set of parameters is used, depending on the procedure where the
trigger comes from and on the link that triggers the transition (DL or UL).
These rate limitation is applied only on a DCH transport channel for initial state and can be modified later
by other algorithms like RRA.
Section 7 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 16
2 Always On
2.7 One Shot Ec/No Report
isSib11IntraFreqOneShotAllowedisIntraFreqOneShotDchAllowedsoftHoAddThresholdOneShot
(RadioAccessService)
SIB11
with O
ne Sho
t meas
urement
confi
g.
Serving
Cell
RRC/BCH (SIB11 with One Shot Meas. setting)
RRC/FACH (Radio Bearer Reconfigutation: Cell_DCH)
RNC
RRC/DCH (Radio Bearer Reconfigutation Complete)
RRC/DCH (Measurement Report Cells (up to 3 best))
intraFreqOneShotFilterCoefficient
(MeasurementConfClass)
isSib11IntraFreqOneShotAllowedPerCell
(FDDCell)
Cell_FACH
RRC/RACH (Event4A)
Cell_DCH
isSib11MeasReportingAllowed
(FDDCell)
The objective of this UA7 feature is to improve the mobility management of the UE once it arrives to DCH
state for Idle state - RRC Establishment, FACH to DCH Transition and PCH to DCH Transition. The focus is
on FACH to DCH transition.
From UA7 onwards, if isSib11IntraFreqOneShotAllowed is set to true, then the info to be included on SIB 11 is the OneShot periodic measurement, this info replaces the normal 1a,b,c events by the Intra-
Frequency One Shot measurement.
Once the UE has this information thru SIB11 it can send Measurement report in a very early stage (before
call management is ready to process it), in this case the event will be stored and processed as soon as
possible by Call management.
On reception of a One-Shot report following a transition from Cell_FACH to Cell_DCH the RNC will update
the iRM RL color based on CPICH Ec/N0 measurements and determine whether to trigger SHO on the
neighbour cells based on a configurable threshold softHoAddThresholdOneShot.
For UEs that do not support the measurement configuration via the SIB11, the RNC can send a RRC
Measurement Control message with following settings; periodic, the Reporting Quantity EC/Io with
Amount of Reporting set to 1. This is done if isIntraFreqOneShotDchAllowed parameter is set to True.
The One shot Ec/Io report has the same meas. Id as the inter-RAT (id=03), this is not problematic since the
intrafrequency one shot report has an amount of reporting =1, and it will be sent in an early stage of the
call when normally there is no 2D event configured.
Once the 2D event is triggered, another Measurement control will be sent with same id but will overwritten
the intrafrequency settings of “one shot” with new inter-RAT IE.
isSib11IntraFreqOneShotDchAllowed is an RNC flag, this flag is supposed per FDDcell from UA7.1 and corresponds to the parameter isSib11IntraFreqOneShotDchAllowedPerCell.
In UA7.0 a workaround was defined later in order to allow the activation of One shot per cell. The
Parameter reserved0.FddCell is used to allow cell level control of this feature.
Note: The OneShot Measurement is only valid for Cell Reselection without HCS.
Section 7 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 17
2 Always On
2.8 RRC states transitions
UTRA RRC Connected Mode
CELL_DCH
Nominal RB
CELL_FACH
Fallback RB
Release RRCConnection
Release RRCConnection
Establish RRCConnection
Establish RRCConnection
RRC Idle ModeUser inactivity
User activity
URA_PCH
No RB
CELL_PCH
No RB
“Sleeping” states(No data
transmission)
New statesSupported byAlways On
Cell update load
T1
T2
T3
T3
As explained in TS 25.331 "The RRC states within UTRA RRC Connected Mode reflect the level of UE
connection and which transport channels that can be used by the UE."
� When the RNC receives a RAB assignment request, the corresponding Radio Bearer is by default
allocated in CELL_DCH.
� Then, later on during the call, a UE can be moved between CELL_DCH and CELL_FACH based on user
activity (i.e. user traffic volume monitoring), that can be controlled by the operator thanks to inactivity
timers.
Since CELL_FACH makes use of RACH and FACH, which are common transport channels (shared between all
the users of the cell), CELL_FACH is only suited to non real-time data services (i.e. Interactive or
Background) and can even be used to transmit small amounts of user data. However, it cannot be used for
real-time traffic, such as voice or video telephony, which are always supported in CELL_DCH.
Always-On is the Alcatel-Lucent PS call management feature responsible for choosing the best radio
resources according to the amount of traffic the subscriber has to transmit.
From UA5.0, Always-On mechanism supports these two RRC states: URA_PCH and CELL_PCH.
PCH sates (i.e. CELL_PCH and URA_PCH) are useful for data subscribers who can fallback to one of these
states when they are completely inactive:
� Since no cell resources are allocated to UE in these states, i.e. no dedicated physical channel is
allocated to the UE, they have no impact on the cell capacity.
� Nevertheless, subscribers benefit from a quicker re-establishment time compared to when in Idle mode
and the UE battery consumption is low, i.e. equivalent to when the UE is in Idle mode.
Section 7 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 18
2.8 RRC states transitions
2.8.1 URA_PCH Transitions if CELL_PCH is used
UTRA RRC Connected Mode
CELL_DCH
Data to transmit
RRC Idle Mode
CELL_FACH
Inactive user from URA_PCH(T3=uraPchToIdleTimer)
nbOfCellUpdatesFromCellPchToUraPchCELL UPDATE
pchRrcStates (RadioAccessService)
= UraAndCellPchEnabledCELL_PCHURA_PCH
When CELL_PCH is used, the transitions between URA_PCH and the other states are the following:
� Transition from CELL_PCH to URA_PCH:
� When in CELL_PCH, the transition to URA_PCH occurs when the user has performed a minimum
number of CELL UPDATE procedures. Therefore this transition is based on the Cell Update signaling
load and not on the user traffic activity. Hence, this transition is not directly related to AO.
� nbOfCellUpdatesFromCellPchToUraPch is used to control the transition from CELL_PCH to URA_PCH state in case the both are activated. It represents the thresholds value for the number of cell update
procedures (with cause “Cell reselection”) initiated by the UE in CELL_PCH state (for a maximum
duration of CellPCHtoIdleTimer) for the RNC to trigger a state change to URA_PCH for this UE.
� Transition from URA_PCH to CELL_FACH:
� In case some data need to be transmitted, the UE is transferred to CELL_FACH:
� In uplink, access is performed by RACH,
� In downlink, UTRAN sends a paging request message (PAGING TYPE1).
� Transition from URA_PCH to idle through CELL_FACH:
� Once in URA_PCH, if the subscriber is completely inactive, i.e. no traffic during a certain period
(URAPCHToIdleTimer), then the UE is further moved to Idle mode.
� Transition to CELL_FACH is required to perform the RRC signaling connection release
Section 7 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 19
2.8 RRC states transitions
2.8.2 URA_PCH Transitions if CELL_PCH is not used
CELL_DCH
URA_PCH
UTRA RRC Connected Mode
Data to transmit
RRC Idle Mode
CELL_FACH
Inactive user from URA_PCH(T3=uraPchToIdleTimer)
Inactive user
(T2= fachToUraPchTimer)
pchRrcStates (RadioAccessService)
= UraPchEnabled
When CELL_PCH is not used, the transitions between URA_PCH and the other states are the following:
Transition from CELL_FACH to URA_PCH:
� When in CELL_FACH, the amount of user traffic is monitored in both uplink and downlink directions.
� When there is no traffic during a certain period of time (FACHToURAPCHTimer) and CELL_PCH is not enabled, the UE is moved to URA_PCH.
� The transition criteria are the same than those used for transition to idle mode, i.e. traffic volume
measurement on DTCH in both uplink and downlink directions.
� Similar to the transition from Cell_FACH to DCH the AO success rate can be improved from UA7 onwards
by repeating the message RB Reconfiguration:
� reconfigRetriesFachPch: defines the maximum number of retransmissions of RB Reconfiguration message due to response message timeout
� reconfigTimeFachPch: defines the timer for retransmission of the RB Reconfiguration messages
Transition from URA_PCH to CELL_FACH:
� In case some data need to be transmitted, the UE is transferred to CELL_FACH:
� In uplink, access is performed by RACH,
� In downlink, UTRAN sends a paging request message (PAGING TYPE1).
Transition from URA_PCH to idle through CELL_FACH:
� Once in URA_PCH, if the subscriber is completely inactive, i.e. no traffic during a certain period
(URAPCHToIdleTimer), then the UE is further moved to Idle mode.
� Transition to CELL_FACH is required to perform the RRC signaling connection release
Section 7 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 20
2.8 RRC states transitions
2.8.3 CELL_PCH Transitions
nbOfCellUpdatesFromCellPchToUraPchCELL UPDATE
CELL_DCH
CELL_PCH
UTRA RRC Connected Mode
URA_PCH
RRC Idle Mode
CELL_FACH
Inactive user from CELL_FACH
(T2=fachToCellPchTimer)
Data to transmit
Inactive user from CELL_PCH(T3=CellPchToldleTimer)
pchRrcStates (RadioAccessService)
= UraAndCellPchEnabled
The transitions between CELL_PCH and the other states are the following:
Transition from CELL_FACH to CELL_PCH:
� When in CELL_FACH, the amount of user traffic is monitored in both uplink and downlink directions.
� When there is no traffic during a certain period of time (FACHToCellPCHTimer), the UE is moved to CELL_PCH.
� The transition criteria are the same than those used for transition to idle mode, i.e. traffic volume
measurement on DTCH in both uplink and downlink directions.
� Like for the transition from CELL_FACH to URA_PCH the AO success rate can be improved from UA7
onwards by repeating the message RB Reconfiguration using parameters reconfigRetriesFachPch and reconfigTimeFachPch.
Transition from CELL_PCH to URA_PCH through CELL_FACH (if URA_PCH state is used):
� Once a UE is in CELL_PCH, and if URA_PCH is enabled, the RNC increments a counter that counts the
number of cell updates.
� When the number of cell updates has exceeded a certain limit
(NumberOfCellUpdatesFromCellPchToUraPch) the RNC moves the UE from CELL_PCH to URA_PCH.
� Transition to CELL_FACH is required to perform the transition signaling.
Transition from CELL_PCH to CELL_FACH: In case some data need to be transmitted, the UE is transferred
to CELL_FACH:
� In uplink, access is performed by RACH.
� In downlink, UTRAN sends a paging request message (PAGING TYPE1).
Transition from CELL_PCH to Idle mode, through CELL_FACH:
� Once in CELL_PCH, if the subscriber is completely inactive, i.e. no traffic during a certain period
(CellPchToIdleTimer), then the UE is further moved to Idle mode.
� Transition to CELL_FACH is required to perform the release signaling.
Section 7 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 21
2.8 RRC states transitions
2.8.4 URA Update in URA_PCH state
UTRA RRC Connected Mode
URA_PCH
CELL_FACH
Cell Reselection
No data to transmit
URA Update
NewURA
Admission control
Although no cell resources are allocated to a UE in URA_PCH, the RNC has to maintain the RRC and Iu
connections, to keep a UE context as well as to process the URA Update procedure.
Therefore the RNC controls the maximum number of simultaneous UE in URA_PCH and once the limit is
reached a UE is moved to Idle mode instead.
Mobility
In URA_PCH state the location of a UE is known at UTRAN Registration Area (URA) level.
A URA is an area covered by a number of cell(s), which is only known by the UTRAN.
The UE performs a Cell Reselection and upon selecting a new UTRA cell belonging to a URA that does not
match the URA used by the UE, the UE moves to CELL_FACH state and initiates a URA Update towards the
network.
After the URA Update procedure has been performed, the UE state is changed back to URA_PCH if neither
the UE nor the network has any more data to transmit.
Section 7 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 22
2.8 RRC states transitions
2.8.5 Cell Update in CELL_PCH state
UTRA RRC Connected Mode
CELL_PCH
CELL_FACH
Cell Reselection
Cell UpdateNo data
to transmit
NewCELL
Admission control
Although no cell resources are allocated to a UE in CELL_PCH, the RNC has to maintain the RRC and Iu
connections, to keep a UE context as well as to process the Cell Update procedure.
Therefore the RNC controls the maximum number of simultaneous UE in CELL_PCH and once the limit is
reached a UE is moved to Idle mode instead.
Mobility
In CELL_PCH state the location of a UE is known at UTRA cell level.
The UE performs Cell Reselection and upon selecting a new UTRA cell, it moves to CELL_FACH state and
initiates a Cell Update procedure in the new cell.
After the Cell Update procedure has been performed, the UE state is changed back to CELL_PCH if neither
the UE nor the network has any more data to transmit.
Mobility over Iur
If as a result of the Cell Reselection process, a UE initiates a CELL UPDATE message in a cell being
controlled by an RNC (CRNC) different from the SRNC, then an Alcatel-Lucent CRNC releases the RRC
connection, i.e. RRC CONNECTION RELEASE is sent with cause Directed Signaling Connection Re-
establishment. The UE will then re-establish the RRC connection under the new RNC, what should be
transparent to the subscriber since it was inactive.
The same procedure applies if an Alcatel-lucent SRNC receives a Cell Update message from a UE that has
re-selected a cell controlled by another RNC vendor.
Section 7 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 23
2.8 RRC states transitions
2.8.6 Cell Update in CELL_FACH state
UTRA RRC Connected Mode
CELL_FACH
Cell UpdateNo data
to transmit
NewCELL
Mobility
In CELL_FACH state the location of a UE is known at cell level.
The UE performs Cell Reselection and upon selecting a new cell, it initiates a Cell Update procedure in the
new cell and stays in Cell_FACH state.
Mobility over Iur
If as a result of the Cell Reselection process, a UE initiates a CELL UPDATE message in a cell being
controlled by an RNC (CRNC) different from the SRNC, then an Alcatel-Lucent CRNC releases the RRC
connection, i.e. RRC CONNECTION RELEASE is sent with cause Directed Signaling Connection Re-
establishment. The UE will then re-establish the RRC connection under the new RNC, what should be
transparent to the subscriber since it was inactive.
The same procedure applies if an Alcatel-lucent SRNC receives a Cell Update message from a UE that has
re-selected a cell controlled by another RNC vendor.
Section 7 � Module 1 � Page 24
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 24
2.8 RRC states transitions
2.8.7 Cell Reselection during Cell_Fach to Cell_DCH
UE OLD Node B SRNC
Upsize request FACH > DCH
Radio Bearer Reconfiguration
Radio Bearer Reconfiguration failure (Over RACH on new cell)
Roll back previous reconfiguration
resource reservation
Radio Link Setup Request
Radio Link Setup Response
NEW Node B
RRC Cell Update
RRC Cell Update Confirm
RRC UTRAN Mobility Confirm
Radio Link Deletion Request
Radio Link Deletion Response
Restart on New NB fach to DCH reconfig
RL Setup Request
RL Setup Response
Radio Bearer Reconfiguration
Radio Bearer Reconfiguration complete
L2 ACK received ?
isFachToDchEnhancementAllowed(RadioAccessService)
From UA7 onwards isFachToDchEnhancementAllowed determines whether handling of cell reselection during FACH to DCH transition is supported.
This scenario occurs during a transition of a PS RAB from Cell_FACH to Cell_DCH where the RNC has
submitted an RRC RB Setup or RRC RB Reconfiguration message to the UE and an RRC Cell Update
message (Cell update cause = “cell reselection“ or “re-entered service area“) interrupts the transition.
To successfully transition the UE to Cell_DCH on the newly selected cell the RNC will roll back the
operations on the old cell and attempt anew the transition to Cell_DCH on the new cell.
If the Cell_FACH to Cell_DCH transition is initiated on a cell with poor radio conditions, and at a certain
time the UE is no more reachable, and it manages to reach back to the network thru a Cell-Update
message with cause “cell reselection” or “re-entered service area”, the RNC will:
� Give Cell update message priority over the ongoing Reconfiguration from FACH to DCH.
� Cancel any changes ongoing for resources to previous cell
� Continue with the transition from FACH to DCH on the new cell using the same triggering information on
the initial attempt.
This procedure is only attempted once, if the cell update fails, then all resources on new and old cell are
released
Section 7 � Module 1 � Page 25
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 25
2 Always On
2.9 PCH States configuration
pchRrcStates = none
CELL_DCH CELL_FACH
pchRrcStates = UraAndCellPchEnabled
CELL_DCH
URA_PCH
CELL_FACH
CELL_PCH
pchRrcStates = CellPchEnabled
CELL_DCH CELL_FACH
CELL_PCH
pchRrcStates = UraPchEnabled
CELL_DCH
URA_PCH
CELL_FACH
4 AO Downsized configurations can be used thanks to pchRRcstates parameter:
CELL_FACH only
CELL_FACH or CELL_PCH
CELL_FACH or URA_PCH
CELL_FACH or CELL_PCH or URA_PCH
Section 7 � Module 1 � Page 26
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 26
2 Always On
2.10 AO Step 2 and AO Step 3 Timers
URA_PCH
CELL_PCH
IdleStep 3 (T3)
cellPchToIdleTimer
UraPchToIdleTimer
CELL_FACH
fachToCellPchTimer
fachToUraPchTimer
AO Step 2 (T2)
nbOfCellUpdatesFromCellPchToUraPch
URA_PCH activated (only)
URA_PCH & CELL _PCH activated
CELL _PCH activated
(pchRrcStates = {uraPchEnabled)
(pchRrcStates = {uraPchAndCellPchEnabled})
(pchRrcStates = {cellPchEnabled, uraPchAndCellPchEnabled})
(Counter of Cell Update procedures)
URA_PCH activated (pchRrcStates = {uraPchEnabled, uraPchAndCellPchEnabled})
(Inactive user)
(Inactive user)
(No signaling traffic : Paging, Cell Update)
(No signaling traffic : Paging, Cell Update)
AO Downsize are split into:
A0 Downsize Step 1:
� from CELL_DCH to CELL_FACH
A0 Downsize Step 2:
� from CELL_FACH to CELL_PCH if CELL_PCH state is used
� from CELL_FACH to URA_PCH if URA_PCH state is used and CELL_PCH state is not used
A0 Downsize Step 3:
� from CELL_DCH to PMM-idle if AO is enabled but Downsized mode is not used
� from CELL_FACH to PMM-idle if PCH states are not used
� from CELL_PCH to PMM-idle if CELL_PCH state is used
� from URA_PCH to PMM-idle if URA_PCH state is used
Section 7 � Module 1 � Page 27
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 27
2 Always On
2.11 Definition of isAlwaysOnAllowed (xxRbSetConf)
isAlwaysOnAllowed (DlRbSetConf)
isAlwaysOnAllowed (UlRbSetConf)
neither RB downsizenor RB release
based on user inactivity
= disabled
RB downsizethen RB release
based on user inactivity
= degraded2AlwaysOnOnly
AO Step 1 (+ Step2) + Step 3
no RB downsizebut RB release
based on user inactivity
= releaseOnly
AO Step 3
Section 7 � Module 1 � Page 28
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 28
2 Always On
2.12 Exercise : Find the parameter values
R99 PS I/BCELL_DCH
PMM-idletimerT1
CELL_FACHtimerT2
AO Step1 AO Step3
isAlwaysOnAllowed = ? pchRrcStates = ?
R99 PS I/BCELL_DCH
PMM-idletimerT2
AO Step3
isAlwaysOnAllowed = ? pchRrcStates = ?
R99 PS I/BCELL_DCH
PMM-idleCELL_FACHtimerT1
AO Step1
fachToUraPchTimer
AO Step2
isAlwaysOnAllowed = ? pchRrcStates = ?
AO Step3URA_PCH
uraPchToIdleTimer
Section 7 � Module 1 � Page 29
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 29
2 Always On
2.13 Mono-Service PS/Multi-RAB PS I/B R99 (R99 PS Mux)
isAlwaysOnAllowed (DlRbSetConf) = releaseOnly
isAlwaysOnAllowed (UlRbSetConf) = releaseOnly
� AO Step 1 not allowed for Multi RAB configuration
R99 PS I/B MUXCELL_DCH
PMM-idletimerT2
AO Step3
PchRrcStates = none
R99 PS I/B MUXCELL_DCH
PMM-idletimerT2
AO Step2
PchRrcStates = UraAndCellPchEnabled
AO Step3CELL_PCH
URA_PCH
cellPchToIdleTimer
uraPchToIdleTimer
AO Step3
Multiple PS RAB is limited to 2 PS RAB only.
There may be situations during which the UTRAN is required to manage 2 simultaneous PS
Interactive/Background RAB for a given user identified by a single RRC connection:
� A user is activating a primary and a secondary PDP context in order to open bearers with different
quality of service towards a given APN (Access Point Name) or packet network.
� A user is activating two primary PDP contexts, each of them corresponding to a different APN
Both of these I/B RABs are multiplexed onto a single DCH. The set of supported rates are:
� UL: 64, 128
� DL: 64, 128, 384
If 2 PS RAB are active simultaneously, the AO Step 1 downsize to Cell_FACH can not be performed.
The AO adaptation is delayed until traffic is null and then the AO Step 2 to PCH states or AO Step 3 to Idle
is carried out depending on the usage of PCH states.
Section 7 � Module 1 � Page 30
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 30
2 Always On
2.14 Multi-Service CS+PS
� Mono RAB PS I/B R99isAlwaysOnAllowed (PS RAB) = degraded2AlwaysOnOnly pchRrcStates ≠≠≠≠ none
isAlwaysOnAllowed (PS RAB) = releaseOnly
� Multi RAB PS I/B R99
pchRrcStates = any value
CS + R99 PS I/B MUXCELL_DCH
PMM-idletimerT2
AO Step3
PS I/B
(CELL_DCH
Down Inactivity
Up
CS+PS I/B
(CELL_DCHInactivity
PS traffic resuming
CS RABsetup
CS RAB release
CELL_FACH
CS + PS I/B8/8(Cell_DCH)
CS + PS I/B 0/0 (CELL_DCH)
CELL_PCH or
URA_PCH
Down
Up
PS traffic resuming
Inactivity
Inactivity
PMM-idle
CS+PS I/B 0/0(+PS I/B 0/0) for Always-On on multi-RAB
� UA5.0 / UA5.1: when a user has a RAB CS + PS I/B calls established, the RNC manages
user inactivity in the following way :
� Always-on Step 1 (low activity) : reconfiguration to CS + PS I/B 8/8
� Always-on Step 2 (inactivity) : the PS RAB is released – CS + PS I/B 8/8 -> CS
� UA6.0: new step for CS+PS
� Always-on Step 1 : unchanged
� Always-on Step 2 : reconfiguration to CS + PS I/B 0/0
1. allows a quicker re-establishment in case PS traffic resumes.
2. CS + PS I/B + PS I/B combinations are handled the same way with a reconfiguration to CS + PS I/B 0/0
3. + PS I/B 0/0.
4. The RNC monitors the traffic on the PS RB(s) and can trigger an upsizing while the CS call is active.
� As part of this evolution:
5. when a UE is in URA_PCH or CELL_PCH and the RNC receives a request to establish a CS RAB, the
6. user is allocated a CS + PS I/B 0/0 RB or CS + PS I/B 0/0 + PS I/B 0/0 depending on the number of PS
7. RAB established. This is more efficient from a resources usage point of view than CS + PS I/B 8/8 or
8. CS + PS I/B 64/64 + PS I/B 64/64, which are allocated with the current implementation.
9. When the CS call is released and if the PS traffic is still 0/0, then the UE is moved back to URA_PCH
10. or CELL_PCH.
Establishment Cause & Traffic Volume Indicator (TVI) in CELL UPDATE message
� On transition from CELL_PCH or URA_PCH, choice between CELL_FACH or CELL_DCH based on TVI
and Establishment Cause
Section 7 � Module 1 � Page 31
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 31
2 Always On
2.15 Recovery actions CELL_FACH admission failure
PS I/B(CELL_DCH
DCH, HS -DSCH or E -DCH )
CELL_FACH
AO downsize Failure
Bucket Occupancy
CELL_FACHAdmission Control
MaxNumberOfUserPerMacC
(CacOnFachParam)
trbEstThreshold
(CacOnFachParam)
UE is kept in in CELL_DCH until CAC FACH succeeds
Recovery actions on CELL_DCH to CELL_FACH admission failure:
When the CAC FACH fails at DCH to FACH AO downsize transition, the UE is kept in in CELL_DCH until CAC FACH succeeds (at downsize retry) or conditions for transition to CELL_FACH are not fulfilled anymore.
Section 7 � Module 1 � Page 32
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 32
2 Always On
2.16 URA (UTRAN Registration Area)
� Up to 8 URA per cell
� Mandatory for URA_PCH state activation
� URA list broadcast in SIB2
URA1 cell
URA2 cell
URA3 cell
URA1
URA2
URA3
URA1
FDDCell
uraIdentityList
URA Identity is 16 bits string.
URA can overlap to avoid ping-pong at the border of several URA.
URA overlapping at the border of two RNC not supported.
Note: SIB2 implementation is independent of URA_PCH flag. If UraIdentityList under FDDCELL is not empty, SIB2 will be broadcast in this cell, not taking into account whether URA_PCH is enabled at RNC level RNC.
Section 7 � Module 1 � Page 33
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 33
2 Always On
2.17 User Services Parameters
RNC
DlRbSetConf UlRbSetConfDlUserService UlUserService AlwaysOnConf
AlwaysOnTimer
isAlwaysOnAllowed isAlwaysOnAllowed
disabled ����degraded2AlwaysOnOnly ����
releaseOnly ����
true ����false ����
alwaysOnUlRbSetDchId
alwaysOnDlRbSetDchId
alwaysOnUlRbSetFachId
alwaysOnDlRbSetFachId
timerT1, timerT1ForHsdpa, timerT1ForHsdpaAndEDch
timerT2, timerT2ForHsdpa, timerT2ForHsdpaAndEDch
fachToCellPchTimer , cellPchToIdleTimer
fachToUraPchTimer, uraPchToIdleTimer
The Radio Bearers used for the downsized state are provided in the AlwaysOnConf object, including the
type of downsize (Cell_DCH or Cell_FACH).
The list of user services that are eligible to Always On is given through the parameter isAlwaysOnAllowed in
DlUserService and UlUserService objects.
The parameter isAlwaysOnAllowed in DlRbSetConf and UlRbSetConf objects determines the behavior of
each Radio Bearer when the always on downsize is triggered. It can take the following values:
� degraded2AlwaysOnOnly means that the downsize is allowed and the target radio bearers are
determined by the parameters of the AlwaysOnConf object.
� releaseOnly means that there is no intermediate downsize for this Radio Bearer. The Radio Bearer is
released when the release conditions are met.
� Disabled means that the Always On feature is disabled for this Radio Bearer.
Section 7 � Module 1 � Page 34
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 34
2 Always On
2.18 Exercise : Find the RRC states transitions
� Assumptions� UE is R99� isAlwaysOnAllowed (alwaysOnConf) = True
� alwaysOnUlRbSetDchId (alwaysOnConf) = PS_8K� alwaysOnDlRbSetDchId (alwaysOnConf) = PS_8K� isAlwaysOnAllowed (PS_128K_IBxSRB_3_4K) = True� isAlwaysOnAllowed (CS_64KxPS_128K_IBxSRB_3_4K) = True� isAlwaysOnAllowed (PS_128K_IB) = degraded2AlwaysOnOnly� isAlwaysOnAllowed (CS_64K) = disabled� timerT1 (AlwaysOnTimer) = 15s� timerT2 (AlwaysOnTimer) = 20s� timerT2ForMultiRab (AlwaysOnTimer) = 20s� PchRrcStates (RadioAccessService) = UraAndCellPchEnabled� nbOfCellUpdatesFromCellPchToUraPch (RadioAccessService) = 3� fachToCellPchTimer (AlwaysOnTimer) = 20s� fachToUraPchTimer(AlwaysOnTimer) = 20s� cellPchToIdleTimer (AlwaysOnTimer) = 60mn
� uraPchToIdleTimer (AlwaysOnTimer) = 60mn
Section 7 � Module 1 � Page 35
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 35
2 Always On
2.18 Exercise : Find the RRC states transitions [cont.]
� Question: Find the RRC State changes ?
PS I/B 128K
0kbps
128kbps
64kbps
5s
CS 64/64
Section 7 � Module 1 � Page 36
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 36
3 RB Rate Adaptation
Section 7 � Module 1 � Page 37
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 37
isUlRbRateAdaptationAllowedisDlRbRateAdaptationAllowed
(RadioAccessService)
3 RB Rate Adaptation
3.1 RB Rate Adaptation Principles
128128 38438464643232
RB Resizing (UL/DL)
Traffic Monitoring (UL/DL)
Estimated
Throughput
(DL/UL)
RB Rate Adaptation (UL/DL)
Current DCH PS RB (UL/DL) Adapted DCH PS RB (UL/DL)
The mechanism is made of 2 main functions:
• Traffic Monitoring : estimates periodically 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.
RB Rate Adaptation is applicable to UL and DL Interactive and Background PS. It introduces RB rate
downsizing/upsizing based on user estimated average throughput.
RNC monitors DL and UL traffic and determines if the current RB bit rate needs to be downsized or upsized
to accurately match the actual traffic.
� Downsizing
RNC targets the bit rate as closely as possible to the estimated throughput.
� Upsizing
Uplink: RNC targets the bit rate immediately above the current bit rate (step-by-step upsize).
Downlink: RNC targets any rate (multi-stages upsize), based on user throughput and RLC buffer
occupancy. The targeted RB bit rate should never exceed the Reference RB bit rate.
DL and UL rate adaptation are performed independently.
Section 7 � Module 1 � Page 38
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 38
3 RB Rate Adaptation
3.2 Traffic Monitoring : UL & DL Throughput
ββββδδδδ ≤≤≤≤KtKR
S,
[[[[ ]]]]∑∑∑∑−−−−
========
1
0
1 K
k
kRateK
R [[[[ ]]]](((( ))))∑∑∑∑−−−−
====−−−−
−−−−====
1
0
22
11 K
k
RkRateK
S
time
Rate[0]=0Rate[1]=0Rate[2]=0
T0
Rate[0]=0Rate[1]=0Rate[2]=N0/T
T1
Rate[0]=0Rate[1]=N0/TRate[2]=N1/T
T2
Rate[0]=N0/TRate[1]=N1/TRate[2]=N2/T
T3
Rate[0]=N1/TRate[1]=N2/TRate[2]=N3/T
T4
Throughput Estimates
raUnitPeriodTimeraNbOfSample
(DlRbRaTrafficMonitoring)
raUnitPeriodTimeraNbOfSample
(UlRbRaTrafficMonitoring)
raMaxConfidenceIntraModifiedStudentCoef
(DlRbRaTrafficMonitoring)
raMaxConfidenceIntraModifiedStudentCoef
(UlRbRaTrafficMonitoring)����Reliable Throughput Estimate
Confidence Level
RLC-SDUthroughput
Confidence Interval = 2b
throughput Estimate
The traffic monitoring function consists of calculating the average throughput over a time window and
estimating the confidence level of the observed throughput.
The algorithm used is the same in DL and in UL. The average throughput is estimated at RLC level excluding
retransmissions and acknowledgements.
The algorithm first computes periodically the user throughput over a period of time T (raUnitPeriodOfTime)
as Rate =N/T where N is the number of RLC-SDU bits transmitted for the first time during T.
Traffic estimates are then based on a sliding window of size K (raNumberOfSample).
The estimation of the average throughput R and of the throughput variance S is derived over the last K
samples Rate[k], where each value R[k] corresponding to a throughput value calculated during a period of
time T (see above slide formulas corresponding to an example with K = 3).
The estimated throughput is supposed to follow a Student-t distribution with K degrees of freedom. The
throughput estimate is considered reliable if the probability of the real throughput being out of the
interval of confidence is smaller than a determined threshold (see above slide formulas).
When the throughput estimate is considered reliable, the RB rate adaptation resizing process is triggered,
otherwise no action is taken.
Section 7 � Module 1 � Page 39
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 39
3 RB Rate Adaptation
3.3 DL Downsizing
no downsizeno downsize
downsize to DL32downsize to DL32
downsize to DL128downsize to DL128
downsize to DL64downsize to DL64
DL384
DL128
DL64
DL32
time
TDOWNDL256
TDOWNDL128
TDOWNDL64
isDlRbRateAdaptationAllowedForThisDlUserService
(DlUserService)
isDlRbRateAdaptationAllowedForThisDlRbSetConf
isThisRbRateAdaptationDlRbSetTargetAlloweddlRbRateAdaptationDownsizeThreshold
(DlRbSetConf)
DL384DL384 DL256DL256 DL128DL128 DL64DL64 DL32DL32
DL iRM
Reference RB
MIN (Adapted RB, IRM RB)
Allocated RB
TDOWNDL384
downsize to DL256downsize to DL256
DL256
RLC-SDU Average Throughput
The RB Rate Adaptation process can downsize a RB from the current RB rate down to any smaller RB (all
transitions towards a smaller RB are possible except to PS 8k, which is not eligible as target).
Based on Traffic Monitoring, the RNC takes the decision to downsize when the following criteria, which are
periodically checked, are verified:
� The observed average throughput is lower than a defined threshold
(dlRbRateAdaptationDownsizeThreshold),
� The confidence level of the estimated average throughput is good enough to consider the observation
as reliable.
The RB adaptation process can downsize a RB from the current RB rate down to any RB with lower bit rate
but the allocated RB is always constrained by the iRM table selection.
Section 7 � Module 1 � Page 40
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 40
3 RB Rate Adaptation
3.4 UL Downsizing
no downsizeno downsize
downsize to UL32downsize to UL32
downsize to UL128downsize to UL128
downsize to UL64downsize to UL64
UL384
UL128
UL64
UL32
RLC-SDU Average Throughput
time
TDOWN384
TDOWN128
TDOWN64
isUlRbRateAdaptationAllowedForThisUlUserService
(UlUserService)
isUlRbRateAdaptationAllowedForThisUlRbSetConf
isThisRbRateAdaptationUlRbSetTargetAllowedulRbRateAdaptationDownsizeThreshold
(UlRbSetConf)
UL384UL384 UL128UL128 UL64UL64 UL32UL32
The RB adaptation process can downsize a Radio Bearer from the current RB rate down to any smaller rate
(all transitions towards smaller RB are possible except to PS 8 kbps).
Based on Traffic Monitoring, the RNC takes the decision to downsize when the following criteria, which are
periodically checked, are verified:
� the observed average throughput is lower than a defined threshold
(ulRbRateAdaptationDownsizeThreshold),
� the confidence level of the estimated average throughput is good enough to regard the observation as
reliable.
Same criteria and mechanisms as for DL RB Rate Adaptation downsizing apply.
Section 7 � Module 1 � Page 41
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 41
3 RB Rate Adaptation
3.5 DL Multi-Stage Upsizing
no upsizeno upsize
upsize of DL32upsize of DL32
upsize of DL128upsize of DL128
upsize of DL64upsize of DL64
time
TUP128
TUP64
TUP32
DL384
DL128
DL64
DL32
DL256upsize of DL256upsize of DL256
DL384DL384 DL256DL256 DL128DL128 DL64DL64 DL32DL32
DL iRM
Reference RB
Allocated RB
isDlRbRateAdaptationAllowedForThisDlUserService(DlUserService)
isDlRbRateAdaptationAllowedForThisDlRbSetConfisThisRbRateAdaptationDlRbSetTargetAllowed
dlRbRateAdaptationUpsizeThreshold(DlRbSetConf)
raSduQueueThreshold
raSduQueueThresholdBytes
(DlRbSetConf/DlRbRaTrafficMonitoring)
Current RB
MAX [ MIN (Adapted RB, IRM RB), Current RB ]
RLC-SDU Average Throughput
RLCRLC--SDUSDU
Buffer Buffer occupancyoccupancy
QUP128
QUP384
QUP256
QUP64
bytesbytes %%
dlRbRateAdaptationUpsizeAlgorithm(RadioAccessService)
DL8DL8
Multi-stages Upsize avoids successive reconfigurations intermediate bit rates in order to reach directly the
most suitable RB rate.
The RB adaptation process can upsize a RB from the current RB rate up to any RB with higher bit rate but
the allocated RB is always lower than or equal to the Reference RB and is constrained by the iRM table
selection.
Based on Traffic Monitoring, the RNC takes the decision to upsize according to the following criteria, which
are periodically checked:
� The observed average throughput is higher than a threshold (dlRbRateAdaptationUpsizeThreshold)
� The confidence level of the estimated average throughput is good enough to consider the observation
reliable.
� RLC-SDU buffer occupancy (in %) is higher than a threshold (raSduQueueThreshold)
If the Multi-Step DL Upsize algorithm is activated
(dlRbRateAdaptationUpsizeAlgorithm = multiStageUpsize and not stepByStepUpsize)
then the RNC selects the target RB according to the DL RLC-SDU buffer occupancy. It compares the
current value of the RLC buffer occupancy (in bytes) to a threshold in order to find the highest RB for
which the following condition is met:
� RLC-SDU Buffer Occupancy (in bytes) ≥ raSduQueueThresholdBytes
If no RB higher than the current RB meets this condition, the upsize is not performed, it means that little
data is waiting for transmission.
Section 7 � Module 1 � Page 42
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 42
3 RB Rate Adaptation
3.6 UL Step by Step Upsizing
UL384UL384 UL128UL128 UL64UL64 UL32UL32 UL8UL8
isUlRbRateAdaptationAllowedForThisUlUserService(UlUserService)
isUlRbRateAdaptationAllowedForThisUlRbSetConf
isThisRbRateAdaptationUlRbSetTargetAllowed
ulRbRateAdaptationUpsizeThreshold
(UlRbSetConf)
no upsizeno upsize
upsize of UL32upsize of UL32
upsize of UL128upsize of UL128
upsize of UL64upsize of UL64
UL384
UL128
UL64
UL32
time
TUP128
TUP64
TUP32
RLC-SDU Average Throughput
A step-by-step upsize scheme applies for the UL RB Rate Adaptation.
It means that the only possible transitions are from the current RB to a target RB which is the very next RB
in terms of bit rate. In this case, the RNC selects the bit rate immediately above the current one, since
the Traffic Monitoring can only indicate that current bit rate is not big enough.
There is no forecast on the future traffic based on the UE RLC buffer occupancy (and consequently multi-
stage upsize is not possible).
Based on Traffic Monitoring, the RNC takes the decision to upsize when the following criteria, which are
periodically checked, are verified:
� The observed average throughput is lower than some defined thresholds,
� The confidence level of the estimated average throughput is good enough to consider the observation
as reliable.
The allocated UL bit rate can never exceed the Reference RB bit rate.
Section 7 � Module 1 � Page 43
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 43
3 RB Rate Adaptation
3.7 UL upsizing based on UE Buffer Occupancy
Event4a (UE->RNC)
UE RLC/MAC UL BO
in the UE
ReportingEvent4a
UL DCH2 RBUL DCH1 RB
ul4AThreshold(UlRbRaTrafficMonitoring)
rcMeasPendingTriggerTime(DchUlBoTrafVolMeas)
ul4ATimeToTrigger(UlRbRaTrafficMonitoring)
measQtyAverageTime(DchUlBoTrafVolMeas)
ReportingEvent4a
isBOTriggerForRbAdaptationAllowed(RadioAccessService)
From UA7 onwards UL upsizing based on UL throughput is enhanced by a mechnism based on UE Buffer
Occupancy :
Measurement is set up on the UE to monitor the RLC buffer occupancy (BO). The Transmit power of the
UE
is also monitored as an additional measurement if enabled (isUeTxPowerOn4AAllowed=true).
The BO is monitored thru an average over measQtyAverageTime; as soon it goes above a given threshold
(ul4AThreshold) during a given period of time (ul4ATimeToTrigger), an Event4A is sent to the RNC.
Upon reception of a 4A Measurement Report from the UE, the RNC determines the selected data rate as
a function of the iRM algorithm, OAM maximum Step size ul4AMaxRateStep and the UE Tx power headroom described in the following two slides.
Further reports are inhibited for a pending time to trigger rcMeasPendingTriggerTime
The advantage of this type of measurement is a quicker reaction of RNC to resource allocation needs
compared to decision based on throughput variation but we may face some excessive usage of
resources due to upsize to the highest RB.
Section 7 � Module 1 � Page 44
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 44
Allocated UL RB
3.7 UL upsizing based on UE Buffer Occupancy
3.7.1 Event4A Processing without UE Tx Power info
isUeTxPowerOn4AAllowed
(RadioAccessService)= False
MIN (Adapted RB, IRM RB)
UL iRM
Reference RB
MAX (ul4AMaxRateStep, current RB)
ul4AMaxRateStep
(UlRbRaTrafficMonitoring)
RNC
MR 4A (UE Tx Power IE)
Buffer
Current UL RB
If the usage of UE Tx power is not enabled (isUEtxPowerOn4AAllowed Set to false), then the Upsize
procedure will target a RB based only on the threshold ul4AMaxRateStep
This RB reconfiguration will be limited by the iRM table and reference RB rate.
Section 7 � Module 1 � Page 45
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 45
3.7 UL upsizing based on UE Buffer Occupancy
3.7.2 Event4A Processing with UE Tx Power info
isUeTxPowerOn4AAllowed
(RadioAccessService)= True
RNC
MR 4A (UE Tx Power IE)
Buffer
Current UL RB
Allocated UL RB PowerOffsetMax = MIN (PMAXUE, maxAllowedUlTxPower)
- current UE Tx Power
Headroom(dB) = PowerOffsetMax- UEtxPoweroffsetFromMax4A
Rate_TxHeadroom = Current_Rate x 10 Headroom(dB) / 10
rounded to the nearest lower RB
MIN (Rate_TxHeadroom, ul4AMaxRateStep, IRM RB)
current UL RB rate < ul4AMaxRateStep ?
UEtxPoweroffsetFromMax4A
(MeasurementConfClass)
1
2
3
4
The aim of this algorithm is to assure that once the UETxPower is equal or greater than the
UEtxPoweroffsetFromMax4A, then Rate_TxHeadroom will be equal or smaller than Current_Rate, which
means No upsize will be taken.
If isUEtxPowerOn4AAllowed is set to true then after receiving the Ue MR, the RNC will:
� Determine the Current_Rate and the Max_UL_rate from ul4AMaxRateStep
� Calculate PowerOffsetMax = min((UlUsPowerConf:maxAllowedUlTxPower, UEmax) - UE Transmitted Power (taken from MR IE).
� Calculate the Headroom(dB) = PowerOffsetMax - UEtxPoweroffsetFromMax4A
� Rate_TxHeadroom= [Current_Rate * 10^(Headroom (dB)/10) rounded down to the nearest supported rate]
� Selected_Rate = Min (Rate_TxHeadroom, ul4AMaxRateStep)
Once this algorithm is finished, and if Headroom is Positive, a UL Upsize RB Reconfiguration
Section 7 � Module 1 � Page 46
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 46
3 RB Rate Adaptation
3.8 DL upsizing based on RNC Buffer Occupancy
Internal RNC Event (IN->CN)
UE RLC/MAC DL BO
in the RNC
ReportingEvent
DL DCH2 RBDL DCH1 RB
boThresholdDlDch(DchDlBoTrafVolMeas)
boPendingTriggerTimeDlDch(DchDlBoTrafVolMeas)
boTimeToTriggerDlDch(DchDlBoTrafVolMeas)
boAverageTimeDlDch(DchDlBoTrafVolMeas)
ReportingEvent
isBOTriggerForRbAdaptationAllowed(RadioAccessService)
From UA7 onwards DL upsizing based on DL throughput is enhanced by a mechnism based on RNC Buffer
Occupancy :
This DL buffer measurement is performed using an average over boAverageTimeDlDch. Set the
boThresholdDlDch to 0 disables the Algorithm in DL.
The reconfiguration will be on a step by step upsize, so if the Current_DL_Rate is PS64, the uspize will
trigger a RB reconfiguration to DL PS 128 if allowed by OAM settings
Section 7 � Module 1 � Page 47
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 47
Allocated DL RB
3.8 DL upsizing based on RNC Buffer Occupancy
3.8.1 Internal RNC Event Processing
MIN (Adapted RB, IRM RB)
DL iRM
Reference RB
Next to current RB
RNC
Buffer
Current DL RB
The Buffer Occupancy (BO) measurements allow the upsize of RB on a step by step procedure for DL.
The activation flags of throughput RB rate adaptation don’t need to be enabled, as this mechanism is
independent of previously described throughput mechanism.
Once the BO fulfils the threshold defined, the RB reconfiguration is triggered towards the next PS I/B Radio
Bearer available and as long as the iRM Table and Reference RB are respected.
Section 7 � Module 1 � Page 48
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 48
3 RB Rate Adaptation
3.9 Ping Pong Timers
rbRateAdaptationPingPongTimer
UeTrafficVolumeInhibitTimer
Reconf Due to BO
MR BO
Reconf(Throughput)
Reconf Due to throughput
MR BO
Reconf(Throughput)
MR BO
ueTrafficVolumeInhibitTimer
(RadioAccessService)
rbRateAdaptationPingPongTimer
(RadioAccessService)
In DL as in UL, there is the same anti ping-pong mechanism in order to avoid continuous RB reconfigurations
in case of abnormal traffic conditions.
The timer UETrafficVolumeInhibitTimer, will be set after last RB reconfiguration, and another RB Reconfiguration can only take place after this timer expiry. This timer is not considered in case RB
Reconfigurations triggered by other causes.
Important:
Up to UA7 rbRateAdaptationPingPongTimer was triggered whenever a RRA mechanism occurred (Buffer or Traffic related).
From UA7 onwards this timer will still be triggered on any RRA but will not prevent the BO mechanisms,
introduced in UA7, from taking place. Only UeTrafficVolumeInhibitTimer, which is triggered only by a BO event, will be verified before processing any additional BO event for RRA.
Section 7 � Module 1 � Page 49
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 49
3 RB Rate Adaptation
3.10 Measurement Configuration
The UL/4A TVM ( Traffic Volume Measurement) is setup /releasedthrough a Measurement Control Message sent from the RNC to the UE if :The UL/4A TVM ( Traffic Volume Measurement) is setup /releasedthrough a Measurement Control Message sent from the RNC to the UE if :
UE has DCH in Uplink and the RB in use is not the Max assigned by the RNC
& the UE has no 4A already setupUE has DCH in Uplink and the RB in use is not the Max assigned by the RNC
& the UE has no 4A already setup
UE has DCH in Uplink and the RB in use is the Max assigned by the RNC
and the UE has 4A already setup OR E-DCH in UplinkUE has DCH in Uplink and the RB in use is the Max assigned by the RNC
and the UE has 4A already setup OR E-DCH in Uplink
The DL TVM ( Traffic Volume Measurement) is setup /releasedthrough an internal measurement control if :
The DL TVM ( Traffic Volume Measurement) is setup /releasedthrough an internal measurement control if :
UE has DCH in Downlink & the DL Rate is not the Max assigned by the CN
& PS I/B RAB present & boThresholdDlDch is non zeroUE has DCH in Downlink & the DL Rate is not the Max assigned by the CN
& PS I/B RAB present & boThresholdDlDch is non zero
DL Rate reaches the maximum bit rate assigned by the CNDL Rate reaches the maximum bit rate assigned by the CN
From UA7 onwards activation of the flag isMpdpRbAdaptationAllowed allows the RRA to be executed over multi-RAB PS (multiple PDP).
The measurement procedure of aggregate RABs is the following:
� For DL Buffer occupancy in case of multiple PS I/B RABs, the RNC will monitor the total DL Buffer,
which means the sum of all I/B RLC entities at transport level.
� For UL 4A Traffic Volume triggers on DCH, the configured 4A measurement is used for all MAC-d
multiplexed RABs.
� For the data rate measurements from the throughput measurements are also performed for UL and DL
on MAC-d multiplexed traffic over the transport Channel (DCH)
� The new combinations supported now by the RRA are:
� 2 I/B DCH/DCH (+CS)
� 2 I/B DCH/HSDPA (+CS)
� 1 I/B DCH/HSDPA + 1 Streaming DCH/HSDPA (+CS)
� 1 I/B DCH/HSDPA + 1 Streaming DCH/DCH (+CS)
Section 7 � Module 1 � Page 50
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 50
3 RB Rate Adaptation
3.11 RAN Model
UlRbSetConf
•isBOTriggerForRbAdaptationAllowed
•isUEtxPowerOn4AAllowed
•ueTrafficVolumeInhibitTimer
Dedicatedconf/MeasurementConfClass
•ueTxPowerOffsetFromMax4A
•boHoldoffTimeInitialDlFachDch
•ul4AMaxRateStep
•ul4AThreshold
•ul4ATimeToTrigger
UlRbRaTrafficMonitoring
•boAverageTimeDlDch
•boPendingTriggerTimeDlDch
•boThresholdDlDch
•boTimeToTriggerDlDch
DlRbRaTrafficMonitoring
DchDlBoTrafVolMeas
DlRbSetConf
DchUlBoTrafVolMeas
•measQtyAverageTime
•measQtyQty
•rcMeasPendingTriggerTime
RAS
Section 7 � Module 1 � Page 51
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 51
3 RB Rate Adaptation
3.12 Exercice
isUeTxPowerOn4AAllowed (RadioAccessService)
= True
Assuming The following:
Current_Rate=64kbpsUE power class=3 (24dBm) AllowedUlTxPower = 24dBmul4AMaxRateStep(RBsetconf64)=384 UEtxPoweroffsetFromMax4A=3dB
Calculate the next bit rate for the following current UE Tx Power reported value:
• 14.1dB:
• 22.1dB:
Section 7 � Module 1 � Page 52
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 52
4 iRM Scheduling
Section 7 � Module 1 � Page 53
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 53
4 iRM Scheduling
4.1 iRM Scheduling Principles
Nominal RBNominal RB
Fallback RBFallback RB
Intermediate RB
Downgrade
Upgrade
flipFlopUpDowngradeTimer
(RadioAccessService)
isIrmSchedDowngradeTxcpAllowed
isIrmSchedulingUpgradeAllowed
isIrmSchedulingOverIurAllowed
(RadioAccessService)
irmSchedDowngradeTxcpMaxBitRate
(RadioAccessService)NodeB
DL 384 kbit/s
DL 128 kbit/s
DL 64 kbit/s
The iRM Scheduling mechanism is based on two sequential procedures triggered to adapt user throughput
when he goes alternately through good and bad radio conditions:
� iRM Scheduling Downgrade reduces bit rate when radio conditions are getting bad.
� iRM Scheduling Upgrade increases bit rate when radio conditions are getting better.
iRM Scheduling Downgrade is based on Transmit Code Power: trigger is based on a measurement done by
the Node B. The dedicated measurement is performed on the primary cell and concerns the Downlink
Transmitted Code Power.
The trigger based on TxCP dedicated measurement can be applied if the primary cell is handled by the
serving RNC or on a DRNC since iRM Scheduling on TxCP is supported over Iur from UA5 release.
irmSchedDowngradeTxcpMaxBitRate is the parameter specifying the fallback RB bit rate in case of iRMScheduling downgrade.
flipFlopUpDowngradeTimer parameter allows to avoid pin-pong phenomena between RB upgrade and downgrade.
iRM Scheduling/ RB rate adaptation dependency:
� In case if RB rate adaptation is enabled for the service, after iRM scheduling downgrade, the service is
flagged as ineligible for rate adaptation upsize. When an event B is reported, the iRM scheduling
upgrade is triggered, so the service come back eligible for RB rate adaptation upsize. Hence bit rate
upsize will not be performed immediately by iRM scheduling but rather with RB rate adaptation
algorithm if necessary.
isIrmSchedulingOverIurAllowed parameter has to be set to true on both SRNC and DRNC for the support of iRM Scheduling over Iur to be effective.
Moreover, the global activation flags for both SRNC and DRNC) on RadioAccessService object have to be set to True : isIrmSchedDowngradeTxcpAllowed and isIrmSchedulingUpgradeAllowed.
Section 7 � Module 1 � Page 54
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 54
4 iRM Scheduling
4.2 Event A for iRM Scheduling Downgrade
isIrmSchedDowngradeTxcpAllowed (DlUsPowerConf)
isTransCodePowerIrmSchedulingDowngradeAllowedFromThisDlUserService (DlUserService)
Transmitted Code Power
Event AReport
Primary CellthresholDdelta(DlIrmSchedDowngradeTxcp)
Event A timeToTrigger Event A timeToTrigger
timeToTrigger (DlIrmSchedDowngradeTxcp)
Event AThreshold
64
384 Downgrade
pcpichPower + maxDlTxPower
-
For iRM Scheduling Downgrade based on TxCP, the detection of degradation in radio conditions relies on
the monitoring of the DL Transmitted Code Power (TxCP). The TxCP trigger is based on NBAP Dedicated
Measurement (type Event A) performed by the Node B handling the primary cell.
When the transmitted code power (TxCP) rises above a threshold (TxCP threshold) during the hysteresis
time (timeToTrigger), a Dedicated Measurement Report is sent by the Node B to the RNC (Event A).
Event A configuration relies on:
Measurement Threshold: the relative transmitted code power threshold given by the parameter
threshold_data is used to compute the absolute TxCP Threshold together with the parameters
pcpichPower (FDDCell) and maxDlTxPower (DlUsPowerConf)
Measurement Hysteresis: timeToTrigger
Section 7 � Module 1 � Page 55
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 55
4 iRM Scheduling
4.3 Events B1 and B2 for iRM Scheduling Upgrade
Event B2 Timer
Transmitted Code Power Event B1Report
Primary Cell
Event B1 Timer
Event B2Report
highB1ThresholdDelta(DlIrmSchedulingUpgrade)
128
384
64 384 128Upgrade
Event B2Threshold
Event B1Threshold
highB1TimeToTrigger (DlIrmSchedulingUpgrade)
mediumB2TimeToTriggerOverHighB1 (DlIrmSchedulingUpgrade)
mediumB2ThresholdDeltaOverHighB1(DlIrmSchedulingUpgrade)
pcpichPower + maxDlTxPower
-
isIrmSchedulingUpgradeAllowedToThisUS
(DlUsPowerConf, DlUserService)
When a UE is using the RB assigned by IRM Scheduling downgrade, the RNC configures two types of NBAP
dedicated measurement by event B report for this UE on the primary cell.
So each time the primary cell changes, the RNC terminates measurements on the old primary cell and
initiates measurements on the new primary cell.
Event B1 configuration relies on:
Measurement Threshold: the relative transmitted code power threshold given by the parameter
highB1ThresholdDelta is used to compute the absolute TxCP Threshold together with the parameters
pcpichPower (FDDCell) and maxDlTxPower (DlUsPowerConf)
Measurement Hysteresis: given by the parameter highB1TimeToTrigger
Event B2 configuration relies on:
Measurement Threshold: relative transmitted code power threshold given by highB1ThresholdDelta +
mediumB2ThresholdDeltaOverHighB1 together with the parameters pcpichPower (FDDCell) and
maxDlTxPower
Measurement Hysteresis: given by highB1TimeToTrigger + mediumB2TimeToTriggerOverHighB1
Section 7 � Module 1 � Page 56
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 56
4 iRM Scheduling
4.4 iRM Scheduling Upgrade
Granted RB
Event Bx
ProcessingEvent Bx
Cell color
RL Condition
Min
iRM tables
iRM RB
Power RB
Requested RB
OLS
Any user becomes eligible for iRM Scheduling upgrade as soon as it experiences an iRM Scheduling
downgrade. This means that after the RB reconfiguration bringing about the downgrade, the RNC
configures and activates the NBAP dedicated measurement report on the primary cell, so as to track the
transmitted code power (see section 4).
On reception of the NBAP Dedicated Measurement Report, the SRNC executes the RAB matching function
taking into account that the Power RB (H or I), corresponding to the event reported (B1 or B2), will be the
highest rate able to be allocated to this mobile.
On reception of the NBAP Dedicated Measurement report, the RNC proceeds to the Synchronous Radio Link
Reconfiguration (SRLR) if the Granted RB is different from the current one. Is so the anti ping-pong timer
flipFlopUpDowngradeTimer is started.
This timer should allow slow ping-pong phenomena between upgrading and downgrading if observed. At its
expiry, a NBAP dedicated measurement can be initiated if in the meantime an iRM scheduling downgrade
has been performed for the mobile.
Section 7 � Module 1 � Page 57
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 57
4 iRM Scheduling
4.5 PS Streaming RAB: iRM Scheduling
Nominal RBNominal RB
Fallback RBFallback RB
NodeB
DL 384 kbit/s
DL 128 kbit/s
DL 64 kbit/s
Intermediate RB
Upgrade
xxx_PS_128K_STR_yyy
xxx_PS_256K_STR_yyy
xxx_PS_384K_STR_yyy
DlUserServiceDlUserService
isIrmSchedDowngradeTxcpAllowed(DlUsPowerConf)
isTransCodePowerIrmSchedulingDowngradeAllowedFromThisDlUserService(DlUserService)
Since high bit rate RB are radio resources consuming, enhanced RRM is required to optimize radio resources
usage.
� iRM Scheduling Downgrade
� Downgrading - similar to I/B but RNC selects the fallback bit rate that is equal or immediately above
the GBR
� Upgrading - similar to I/B but but RNC selects the fallback bit rate that is equal or immediately above
the GBR
Always On and RB Rate Adaptation are not applicable to PS streaming RAB
Section 7 � Module 1 � Page 58
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 58
4 iRM Scheduling
4.6 iRM Scheduling Parameters for Downgrade
Iur
Thresholddefined:
• as absolutevalue in dBm
• at RNC / DlUserServicelevel
SRNC
Thresholddefined:
• as relative value (to Pmax) in dB
• at Cluster (PowerConfClass) / DlUserServicelevel
FDDCell
thresholdDelta timeToTrigger
irmSchedDowngradeTxcpMaxBitRate RadioAccessService
RNC
DlUserService
1..30
IrmSchedulingDowngradeTransCodePower
1..1
LowRbA
1..1
1..1
DedicatedConf
1..*
PowerConfClass
DlUsPowerConf
1..15
1..40
DlIrmSchedDowngradeTxcp
thresholdTransCodePowerDefinitionParam timeToTrigger
Used when primary cell is on a drift RNC Used when primary cell is on the serving RNC
Section 7 � Module 1 � Page 59
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 59
4 iRM Scheduling
4.7 iRM Scheduling Parameters for Upgrade
Iur
Thresholddefined:
• as absolutevalue in dBm
• at RNC / DlUserServicelevel
SRNC
Thresholddefined:
• as relative value (to Pmax) in dB
• at Cluster (PowerConfClass) / DlUserServicelevel
RadioAccessService
RNC
DlUserService
0..1
1..30
1..1
MediumRbB2 HighRbB1
1..1
1..1
DedicatedConf
1..*
PowerConfClass
DlUsPowerConf
1..15
1..40
DlIrmSchedUpgrade
highB1ThresholdDelta highB1TimeToTrigger mediumB2ThresholdDeltaOverHighB1 mediumB2TimeToTriggerOverHighB1
highBitRate thresholdTransCodePower timeToTrigger
intermediateRate deltaThresholdTransCodePower deltaTimeToTrigger
FDDCell
Used when primary cell is on a drift RNC Used when primary cell is on the serving RNC
deltaThresholdTransCodePower and mediumB2ThresholdDeltaOverHighB1 are defined relatively to high bit rate threshold (respectively thresholdTransCodePower and highB1ThresholdDelta )
IrmSchedulingUpgrade
Section 7 � Module 1 � Page 60
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 60
5 iRM Preemption
Section 7 � Module 1 � Page 61
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 61
5 iRM Preemption
5.1 iRM Preemption Algorithm
Cell Color
22
11 Current DL RB Downgraded DL RB
33
SilverSilver
IRM Tables44
BronzeBronze
GoldGold
isIrmPreemptionAllowed
(RadioAccessService)
isIrmPreemptionAllowedForGoldUsers
isIrmPreemptionAllowedForSilverUsers
isIrmPreemptionAllowedForBronzeUsers
(irmPreemption)
Code Load
Power LoadIub Load
CEM Load
A/R Priority Level
The purpose of iRM Preemption is to keep some resources available when the cell becomes loaded. iRM
Preemption is a reactive process performed when all other preventive congestion solutions are not
sufficient to free OVSF codes and power resources quickly enough to maintain sufficient accessibility to
the network.
The preemption procedure is applicable to specific users having PS Interactive/Background connection in
CELL_DCH according to their OLS level.
However, no specific feature is dedicated to the radio bearer upsizing for preempted users. But they may
retrieve the initial requested radio bearer after any reconfiguration (CS release, CS establishment when a
PS connection on-going, iRM scheduling upgrade, AO upsizing…) except the AO downsize and iRM
scheduling downgrade procedures.
Thus iRM Preemption completes the existing congestion prevention iRM RAB to RB Mapping feature by
implementing a reactive congestion management at the cell level.
Note: IRM pre-emption feature activation requires that parameters isIrmOnRlconditionAllowed and
isIrmOnCellColourAllowed set to TRUE.
Section 7 � Module 1 � Page 62
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 62
5 iRM Preemption
5.2 iRM Preemption: Downgraded DL RB
Radio Link Col
or
BronzeBronze
GoldGold
SilverSilver
+ iRMRbRate
DL Cell Color
OLS
fallBackRbRate MIN
iRM PreemptionDowngraded RB Bit Rate
The target Radio Bearers for iRM Preemption are defined using:
� the iRM Tables: iRMRbRate as a function of (DlRbSetConf, OLS)
� fallBackRbRate as a function of DlRbSetConf
They correspond to the Radio Bearers UE would have received if UE were admitted as the Radio Link
Condition was Bad and the Cell Color was Red.
Therefore users eligible to iRM preemption are users whose current DL Bit Rate is higher than the one
defined for bad radio conditions and loaded cells.
As iRM tables are constructed making use of A/R Priority, iRM Preemption offers the possibility to preempt
users according to their OLS level.
Section 7 � Module 1 � Page 63
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 63
5 iRM Preemption
5.3 Cell Color / Active Set Color Calculation
Code Color
Power Color
WorstWorst
Cell 1
Cell N
WorstWorst
Active Set Color
Cell Color
Cell Color
WorstWorst
Iub Color
+
=
WorstWorst
Black
White
Black
White
Black
White
normal2congestedPLCThresholdcongested2normalPLCThresholdnormal2congestedCLCThresholdcongested2normalCLCThreshold
normal2congestedDlCEMThresholdcongested2normalDlCEMThreshold
(IrmPreemptionCacParams)
normal2CongestedDlTLCThresholdcongested2NormalDlTLCThreshold
(IrmPreemptionIubTransportLoadParameters)
The transition from a normal to a congested state is computed when one of the following thresholds is
crossed:
� normal2CongestedCLCThreshold (for codes)
� normal2CongestedPLCThreshol (for power)
� normal2CongestedDlCEMThreshol (for CEM load)
� normal2CongestedDlTLCThreshold (for Iub)
In order to avoid any ping pong effect between the congested and normal states, due to strong variations in
the radio resources allocation, the hysteresis cycle relies on additional thresholds characterizing the
congested to normal transition through the parameters:
� congested2NormalCLCThreshold (for codes)
� congested2NormalPLCThreshold (for power)
� congested2NormalDlCEMThreshol (for CEM load)
� normal2CongestedDlTLCThreshold (for Iub)
In the case of soft handover, the active set color is derived from the color of each cell.
Section 7 � Module 1 � Page 64
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 64
5 iRM Preemption
5.4 iRM Preemption Behavior
irmPreemptionColorCheckingTimer (IrmPreemption)
PS I/B Connection
UE 1
UE 2
UE N
time
Preemption Starts
Color Check Checking Timer
AS Color
Black
White
Preemption Stops
As soon as a downlink PS I/B radio bearer is allocated to a UE, the iRM preemption timer assigned to each
eligible mobile is armed. At each UE timer expiration, the cell preemption color is checked, and if the
cell is congested, the eligible user is preempted if the following condition based on the bit rate
comparison is fulfilled:
If
� current DL RB bit rate > iRM preemption downgraded RB bit rate
Then
� preemption is processed and the downgrade is performed
Section 7 � Module 1 � Page 65
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 65
5 iRM Preemption
5.5 Interaction with iRM RAB to RB Mapping
Radio Color
Iub Color
Cell Color
WorstWorst
Black
White
Preemption Color
Radio Color
Iub Color
Cell Color
Worst
iRM Color
Red
Green Yellow
The iRM Preemption cell color determination algorithm is similar to the one already implemented for the
iRM RAB to RB Mapping feature based on the cell color evaluation.
However, it implies some specific thresholds relating to the calculation of the code load, power load, CEM
load and Iub load.
Consequently it has an independent mechanism from the one used for iRM CAC.
The addition of the new colors (Black and White) is for preemption purposes only.
It has no effect on iRM RAB to RB Mapping process applied at call admission or on RB reconfiguration.
Section 7 � Module 1 � Page 66
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 66
6 Preemption Process for DCH and HSDPA/HSUPA
Section 7 � Module 1 � Page 67
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 67
6 Preemption Process for DCH and HSDPA/HSUPA
6.1 Concepts
Preemption
NodeB UL radio resources not
available
RNC DL power resources not
available
RNC DL code resources not
available
NodeB resources not available
NodeB DL radio resources not
available
RNC
CAC
Failure
NodeB
CAC
Failure
PS Background
PS Interactive
Signaling PS
Interactive
PS Streaming
CS Streaming
Video telephony
Speech
Emergency Call
���� Preemption
Capability
���� Preemption
Vulnerability
���� Priority (*)Inter-Frequency
intra-RNC Radio Link
setup (IMCTA CAC,
iMCTA Alarm)
Radio Link Addition
Always-on Upsize
RRC connection
request
RAB Assignment
Queuing not
allowed
Queuing
allowed
R99
HSUPAHSDPA
(*) + OLS at user level
1 Step / 2 Steps
Incoming relocation does not trigger
preemption in the target RNC
RNC/RAS
FDDCell
isCellPreemptionAllowed
Eligible procedures
Eligible Services
Eligible CAC Failures
PreemptionAllowedInfo
isPreemptionAllowed
UA6.0: Introduction of new Pre-emption feature (33322)
� Reactive mechanism (trigger is CAC failure)
� Independent from the iRM
� Applicable to DCH as well as HS-DSCH & E-DCH transport channels
� Dl & UL
� Applicable to all services
The UA6.0 Pre-emption is triggered by a CAC failure, meaning that no resource are available to accept the
incoming call. It may be :
� DL Power
� DL OVSF Codes
� CEM (UL & DL)
� Transport (restriction in UA06.0: Iub/Iur cac failure not elligible)
The CAC failure may happen at Call Establishment or during mobility procedure.
The system will then try to free some resources by downgrading (PS only) or releasing lower priority
services to be able to accept the incoming user.
The preemption shall only be a reactive mechanism that aims at allocating the preempted resources to the
service that triggered the preemption.
The preemption is performed in best effort mode : the resources freed by the Preemption will not be
necessarily allocated to the user that triggered the preemption
Section 7 � Module 1 � Page 68
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 68
6 Preemption Process for DCH and HSDPA/HSUPA
6.2 Eligible Procedures
RadioAccessService
Preemption
PreemptionCapabilityProcedureInfo
preemptionCapabilityForAlwaysOnToDch
preemptionCapabilityForAlwaysOnToHsDsch
preemptionCapabilityForAlwaysOnToEdch
Pre-emption
on CAC FailureProcedure
Inter-Frequency intra-RNC
Radio Link setup (HHO)
Radio Link Addition (SHO)
Always-on Upsize
RRC connection request
RAB Assignment
ON / OFF
ON
preemptionCapabilityForMobility
preemptionCapabilityForRrcEstabCause……OtherThanEmergencyCall
� When a CAC failure occurs during one of the following procedures, the procedure goes on either by
processing a failure case or is queued (see below the comment for each procedure).
� Simultaneously, a pre-emption action may be launched in order to free resources in each congested
cell.
� The freed resource might be used by the call that triggered the Pre-emption or not as part of the best
effort algorithm implemented.
Note 1: an incoming relocation in the target RNC shall not trigger pre-emption, Queuing is forbidden for
relocation.
Note 2: an iMCTA upon service reason shall not trigger pre-emption in source cell nor target cell
Section 7 � Module 1 � Page 69
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 69
6 Preemption Process for DCH and HSDPA/HSUPA
6.3 Eligible CAC Failure Cases
NodeB UL radio resources not
available
RNC DL power resources not
available
RNC DL code resources not
available
NodeB resources not available
NodeB DL radio resources not
available
RNC
CAC
Failure
NodeB
CAC
Failure
RNC
isCellPreemptionCodePowerCacFailureAllowed
NodeB
FDDCell
isCellPreemptionNbapCacFailureAllowed
The S-RNC may decide to launch preemption in a cell when it faces up a CAC failure during the followingresource allocation procedures:
o NBAP procedures: NBAP Radio Link setup failure, NBAP Radio Link addition failure, NBAP SynchronizedRadio Link Reconfiguration failure, NBAP Radio Link Reconfiguration failure using one of the followingNBAP failure cause: “DL radio resources not available”, “UL radio resources not available” and “Node B Resources Unavailable”
o Internal DL power allocation
o Internal DL channelization code allocation
These resource allocation procedures concern DCH, E-DCH or HS-DSCH resources allocation.
Others functions as HSxPA fallback or iMCTA may also solve the CAC failure situation depending on the trigger eligibility and the feature activation. The order of the procedures is the following:1-HSxPA fallback 2-iMCTA 3-preemption.
The resources allocation requests done through RNSAP procedures are not eligible to preemption.
An ALU D-RNC will never launch a pre-emption process.
Iub and Iur resources allocation failures don’t call the pre-emption function.
Note: The NBAP failure cause « Node B Resources Unavailable » identifies a resource allocation failurewithout indication of the direction which may be downlink, uplink or downlink & uplink.
Section 7 � Module 1 � Page 70
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 70
6 Preemption Process for DCH and HSDPA/HSUPA
6.4 Internal or External CAC failures
� With the introduction of the Fair-sharing feature,� Internal resources (RNC) are shared between DCH & HSDPA
(DL Power & OVSF Codes)
� External resources (NodeB) are dedicated to each transport type (UL & DL)
(CEM processing)
� When a CAC failure occurs, the selection of the users to be pre-empted dependson the failure cause:
UL DCH / DL DCHNode B DL radio resources
not availableUL DCH / DL DCH
UL E-DCH / DL HS-DSCH DL OVSF Codes CAC failure UL XXX / DL YYY (*)
UL E-DCH / DL HS-DSCHNode B radio resources not
availableUL E-DCH / DL HS-DSCH
�
�
�
(*) XXX stands for DCH or E-DCH, YYY stands for DCH or HS-DSCH
Section 7 � Module 1 � Page 71
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 71
6 Preemption Process for DCH and HSDPA/HSUPA
6.5 Eligible Transport Channel
RNC
isPreemptionAllowedForEdch
RadioAccessService
PreemptionAllowedInfo
isPreemptionAllowedForHsdpa
Pre-emptionCAC Failure on
DCH ON
HS-DSCH ON / OFF
E-DCH ON / OFF
isPreemptionAllowedForHsdpa : Parameter to activate/deactivate preemption process when a CAC failure occurs during a HSDPA allocation (i.e. HS-DSCH resources)
isPreemptionAllowedForEdch : Parameter to activate/deactivate preemption process when a CAC failure occurs during a HSUPA allocation (i.e. E-DCH resources)
Section 7 � Module 1 � Page 72
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 72
6 Preemption Process for DCH and HSDPA/HSUPA
6.6 Eligible Services
Each service can be preempted and/or can preempt according to the following attributes:
� Priority level : allows to classify services to decide which service is allowed to pre-empt which service
� Pre-emption capability : defines if the incoming service may trigger the pre-emption
� Pre-emption vulnerability : defines if the service may be pre-empted
RNCCN RAB Assignment Request
Allocation/Retention priority IE
Pre-emption CapabilityPre-emption Vulnerability
RadioAccessService
Preemption
preemptionMode
PreemptionPcPvServiceClass/Emergency
PreemptionFrequency/FDDx
0..5
PreemptionPcPvServiceClass/Speech
PreemptionPcPvServiceClass/VideoTelephony
PreemptionPcPvServiceClass/PS Streaming
PreemptionOmcrPcPvInfo
preemptionCapability
preemptionVulnerability
OR
PreemptionServiceInfo
preemptionPriorityOfService
Y
Y
N
Y
Y
N
N
N
N
Preemption Vulnerability(PV)
N
N
Y *
Y
Y
Y
Y
Y
Y
Preemption Capability(PC)
7PS Interactive
8PS Backgroung
6Signalling PS Interactive
5PS Streaming
4CS Streaming
3Video Telephony
2VoIP**
1Speech
0Emergency
P-Service PriorityServices
Y
Y
N
Y
Y
N
N
N
N
Preemption Vulnerability(PV)
N
N
Y *
Y
Y
Y
Y
Y
Y
Preemption Capability(PC)
7PS Interactive
8PS Backgroung
6Signalling PS Interactive
5PS Streaming
4CS Streaming
3Video Telephony
2VoIP**
1Speech
0Emergency
P-Service PriorityServices
Section 7 � Module 1 � Page 73
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 73
6 Preemption Process for DCH and HSDPA/HSUPA
6.7 Selection of service to be pre-empted
Applicability :� The congested cells of the active set used by the call waiting for
resources� The target cell selected by the SRNC or by the other RAT when a
call has to be establishedServices preempted may belong to ongoing multi-services
for same service priority and same OLS, the expected gain in term of radio bit rate is used as the third criteria
Incomingservice
1st Service filtering
(PV, Priority)
Services
Preemptableservices list
(1st)
CAC Failure
2nd Service filtering
(CAC Failure)
Conditions :
- Service has to bevulnerable to preemption
- Priority ≤≤≤≤ Priority (Incomingservice)
Conditions :
- CAC Failure is Node B : Transport Type = Transport Type (Incomingservice)*
- CAC Failure is RNC (Code, Power) : all services using HS-DSCH & DL DCH to be preempted
Preemptableservices list
(2nd)
User filtering
(OLS)
Conditions :
- Service = Service (Incoming) : OLS < OLS (Incoming)
- Service ≠≠≠≠ Service (Incoming) : OLS ≤≤≤≤ OLS (Incoming)
Bronze
Silver
Gold
P-Priorityn
Bronze
Silver
Gold
P-Priorityn-1
Bronze
Silver
Gold
P-Priorityk
Priority- +
Silver
P-Priorityk
Incomingservice
In each congested cell, a search of P-Services to be pre-empted carrying a traffic channel is processed by
applying a downgrade or/and a release. The preemption criteria for each P-Service are taken into
account.
The preemption process ends when the expected resource quantity to be de-allocated is achieved or when
there is no P-Service to pre-empt anymore.
The selection induces the following steps:
� The RNC selects all P-Services which are vulnerable (P-Preemption Vulnerability equal to “pre-
emptable”) with a P-Service priority lower or equal to the P-Service requesting the pre-emption
� According to the CAC failure cause the P-services which don’t allow the de-allocation of the resource
requested are filtered.
� When the CAC failure cause is for NodeB reason, a specific filtering applies:
� The P-Service candidate to be pre-empted is filtered if it has not the same transport type as the
service requested.
� When the CAC failure cause is for code or power reason, all P-Services using HSDSCH or DL DCH
resources are candidate to be-pre-empted.
� Then the RNC
� only keeps the users with an OLS lower or equal to the OLS of the user requesting the pre-emption if
they are using different P-Service(s)
� only keeps the users with an OLS strictly lower than the OLS of the user requesting the pre-emption if
if they are using the same Pservice(s)
Section 7 � Module 1 � Page 74
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 74
6 Preemption Process for DCH and HSDPA/HSUPA
6.8 Mono-Step / Multi-Step Pre-emption
� Choice only for PS Interactive or Background or Streaming (if target rate >= GBR)
� Any other service leads to a release of the Service when preempted
Mono-Step Multi-Step
preemptionDowngradeReleaseSteps(Preemption)
DowngradeThenRelease
DCH
preemptionDowngradeReleaseSteps(Preemption)
Preempted serviceis downgraded
DowngradeOnly
DCH
ReleaseOnly
HS-DSCHE-DCH
Preempted serviceis downgraded
Preempted serviceis released
next Pre-emption process
Any value
� Then the RNC starts to preempt the user with the lowest OLS within the lowest service priority by
applying first a rate downgrading action if eligible.
� When there are no more users of the lowest OLS, the RNC goes on with upper OLS.
� Then when there is no more user to downgrade, a second step of pre-emption using a release (if allowed
for the service) may apply to the users not already selected for downgrading (lowest OLS first) and to the
users ineligible to the downgrading (see note 1).
� When there are no more users in this Service priority, the RNC goes on with the upper Service.
Note 1: There is no selection order between downgraded users and users ineligible to downgrading.
A user is ineligible for downgrading due to the Service (example: speech), the GBR, the transport type.
When pre-emption is processed for a given CAC failure, a service eligible for “downgrading then release”
may only be either downgraded or released: When it is downgraded, it will be candidate to the release at
the next pre-emption function call.
Note 2: For a given priority and a given OLS, a downgrading or a release applies by the highest expected
gain in term of radio bit rate. So the pre-emption order is Service, OLS and then radio bit rate gain
whatever the CAC failure reason.
Note 3: A release action may apply to the following Services:
� Services which are never eligible to rate downgrading:
CS Speech, CSD, CS streaming, PS Conversational
� • Services which may be eligible to release according to an OAM parameter:
PS streaming, PS Interactive, PS Background
A service established on HS-DSCH may only be released.
A service established on E-DCH may only be released.
Section 7 � Module 1 � Page 75
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 75
6 Preemption Process for DCH and HSDPA/HSUPA
6.9 Selection of service to be downgraded
� Only valid for Downgrading pre-emption
RadioAccessService
Preemption
preemptionFloorBitRateInDownlink
preemptionFloorBitRateInUplink
RBs selectedfor downgrading
RBs selectedfor downgrading
RBs selectedfor downgrading
Filtering on Target bit rate
RB bit rate > preemptionFloorBitRateInXX
Keep the Max bit rate RBs
An uplink target rate and/or a downlink target rate are set by OAM for each service per OLS.
The RB and the requested target rates are given by the pre-emption function to the Rab matching function
which selects the bearers with the nearest and lower or equal rate to the target rate.
When the Rab matching selects a service configuration with a sum of rate higher than the previous service
configuration, the call is not modified (this use case may apply when the call has others services which
are upgraded by the Rab matching function).
For a given priority and a given OLS, a downgrading or a release applies by the highest expected gain in
term of radio bit rate. So the pre-emption order is Service, OLS and then radio bit rate gain whatever the
CAC failure reason.
Section 7 � Module 1 � Page 76
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 76
6 Preemption Process for DCH and HSDPA/HSUPA
6.10 Estimation of Resource De-allocation
� DCH Service CAC Failure
Preemption
PreemptionDeallocationInfo
preemptionDeallocationFactorInDownlink [High,Low]preemptionDeallocationFactorInUplink [High,Low]
preemptionDeallocationThresholdInDownlinkpreemptionDeallocationThresholdInUplink
Service(s) Preempted so that
Free resource = Ul (Dl) Radio rate to be allocated
* Ul (Dl) DeallocationFactor [High]
Node B / Code / PowerUL (DL) CAC Failure
Ul (Dl) resource rate to be freed> DeallocationThreshold
Service(s) Preempted so that
Free resource = Ul (Dl) Radio rate to be allocated
* Ul (Dl) DeallocationFactor [Low]
Yes
No
An estimation of the resource needed has to be done in the following CAC failure cases:
� NodeB: 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 NodeB 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 NodeB 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 at 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:
� Ul resource rate to be freed= Ul Radio rate to be allocated * Ul de-allocationfactor
� Dl resource rate to be freed= Dl Radio rate or fair bit rate to be allocated * Dl deallocation 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
Section 7 � Module 1 � Page 77
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 77
6 Preemption Process for DCH and HSDPA/HSUPA
6.11 Queuing of RAB Assignment Request
Best effort approachRAB Assignment
Preemption
resource allocation request
max number of retries
preemptionQueuingReallocationRetryMaxNumber
(PreemptionQueuingReallocation)
preemptionQueuingReallocationTimer
(PreemptionQueuingReallocation)
Cell Pre-emption state Normal state
preemptionQueuingAllowedIE(Preemption)
preemptionQueuingReallocationPriority = 0 or 1(PreemptionServiceInfo)
PriorityReallocation RegularReallocation
Per P-Service
retry timer
If no more queued calls
0
1
The queuing is done at RNC level.
The queuing is allowed for RAB Assignement procedure only.
When the queuing decision is taken, an allocation retry timer is set and the resource allocation request is
retried when the timer elapses (end of congestion is not used as trigger):
� The pre-empted resources might be not re-allocated to the particular service that triggered the preemption.
� The preempted resources may be allocated to a service having the same or higher priority and the same or higher
OLS compared with the service that triggered the preemption.
The RAB matching or/and the IRM table procedures have to be processed at each resource allocation
request (re-)attempt in order to set the target Asconf (UL and DL) to be served.
The resource allocation request is retried until resource is available or max number of retries is reached.
As the RANAP RAB Assignment is constrained at the Core Network level by the timer TRabAssig , the
following relationship has to be checked:
preemptionQueuingReallocationTimer * preemptionQueuingReallocationRetryMaxNumber < TRabAssig
Moreover, an attribute preemptionQueuingReallocationPriority is defined for each PService.
The possible values are:
• Priority reallocation
• Regular reallocation
As soon as the pre-emption is triggered on a given cell and a RAB Assignment Request is queued, the cell
goes from “Normal state” to “Cell pre-emption state” and a resource allocation filtering is performed in
order to restrict the allocation in the congested cell.
Section 7 � Module 1 � Page 78
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 78
6 Preemption Process for DCH and HSDPA/HSUPA
6.12 Feature dependencies
Fair sharing of resources
33694
GBR on HSDPA
29804
Preemption
33322Upon CAC Failure
Shared resources (R99 & HSDPA) : OVSF Codes & DL Power
Dedicated resources : CEM (Node B)
Common Call Admission Control between HSDPA and R99 usersfor OVSF Codes and DL Power
Min QoS ensured for HSDPA users (PS Streaming & PS I/B)
MinBR & GBR transmitted (optionally) to the Node B
MAC-hs scheduler to ensure the QoS of HSDPA users (MinBR & GBR)
Power consumption Node B feedback to RNC (needed for fair-sharing)
Fair-sharing is mandatory for Pre-emption
The Fair sharing feature (FRS 33694) activation is mandatory before the activation of the Pre-emption
feature.
Section 7 � Module 1 � Page 79
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 79
6 Preemption Process for DCH and HSDPA/HSUPA
6.13 Feature Interactions
iMCTA CAC & Alarm
29415
HSxPA to DCH fallback
32602
Preemption
33322
Will be triggered first for HSxPA incoming users.
Depending on CAC failure, fallbacks 1 step / 2 steps may betried :
• DL HSDPA / UL R99
• DL DCH / UL DCH
If HSxPA to DCH fallback is activated, iMCTA CAC will not betriggered upon HSxPA CAC failure.
A incoming HSxPA user will first go through the HSxPA to DCH fallback algorithm. On R99 failure, iMCTA CAC will be triggered
Preemption will be called as last chance, after HSxPA to DCH fallback and iMCTA (according to applicability of each
algorithm)
This feature is exclusive with Fair-sharing when the CAC failure is Internal (shared
resource)
Rescue mechanisms on CAC failures
The UA4.1 & the UA6.0 Pre-emption may run in parallel. There is no interaction between the 2 mechanisms.
Other mechanisms may be used (if they are activated), before invoking Pre-emption, to solve a CAC failure
situation. They are, in order:
� HSxPA to DCH fallback(HSxPA-to-DCH fallback is not allowed, when CAC occurs for shared resources (DL
OVSF codes or DL power)).
� iMCTA
Section 7 � Module 1 � Page 80
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 80
6 Preemption Process for DCH and HSDPA/HSUPA
6.14 Exercise1: RAB Assignt Queuing and Pre-emption
Scenario:� Preamption setting:
� preemptionQueuingReallocationTimer = 1500, preempti onQueuingReallocationRetryMaxNumber = 2� At T1 the incoming service S1 with priority P1 fails to allocate resources on the cell C
� The preemption is triggered
� At T2 the incoming service S2 with priority P2 higher than P1 asks for resources on cell C
� At T4 the incoming service S3 with priority P3 > P1 ask for resources on cell C
� At T1:
� What happen at T1?
� What is the highest cell C preemption priority level ?
� Same questions for T2, T3, T4, T5 and T6 (T3-T1 = T5-T3 = T6-T4 = 1,5s)
Cell C Queuing State ?
Enough resources areavailable for S1 or S2
T2 T3 T4T1 T6
Enough resources areAvailable for S1 or S3
(S1, P1) (S2, P2) (S3, P3)
Time
P? P? P? P?
T5
Section 7 � Module 1 � Page 81
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 81
6 Preemption Process for DCH and HSDPA/HSUPA
6.15 Exercise2: Estimation of Resource De-allocation
� AssumptionspreemptionDeallocationFactorInDownlink [High,Low] = [200,120] (unit=%)
preemptionDeallocationThresholdInDownlink = 16 (kbps)
� Question: Estimates (in kbps) the quantity of DL resource to be de-allocated in order to serve
� a PS Streaming call at 128 kbps downlink bit rate ?
� a CS AMR speech call at 12,2 kbps bit rate ?
Section 7 � Module 1 � Page 82
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 82
7 AMR Rate Change during the Call
Section 7 � Module 1 � Page 83
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 83
DL Tx CP
7 AMR Rate Change during the Call
7.1 General Principles
UL Cell Load
RNC
Maintain the speech call in UMTS (i.e. avoid redirection to 2G
layer) even at the expense of the PS call
DSIub
DL Power Load
Max AMR RateRedirection
Differentiation per subscriber OLS
Greatest number of CS
speech calls/cell with the
constraint of limited
resources
IsAmrRateControlDuringTheCallAllowed(RadioAccessService)
isAmrRateControlOnULCellLoadAllowed
isAmrRateControlOnDlPowerLoadAllowed
isAmrRateControlOnIubDsLoadAllowed
(RadioAccessService)(DlUserService)
Iub DS Load
Principle
Up to release UA04.2 the bearer service support for AMR was restricted to monomode AMR, i.e. bearer
service support for AMR 12.2 and support of silent mode (aka SCR (VAD/DTX)) with use of version 1 of Iu
UP.
The features 18717 “AMR-NB multi-mode support” and 30229 “Iu UP SMpSDU V2” provide the bearer service
support with use of version 2 of Iu UP for a number of narrowband AMR speech service and the support of
a number of functions to allow core network Transcoder / Tandem Free mode of Operation (TrFO/TFO)
speech calls.
Multimode AMR support offers:
� Downlink capacity gain in term OVSF code resource. SF 256 can be used for AMR Low Rate
configuration.
� Downlink capacity gain in term of radio resource. The required signal to interference ratio depends on
the required throughput. Therefore a lower AMR throughput will require less power.
� UL coverage gain. The required transmitted power will be reduced for lower AMR rate.
AMR Rate Control
In UA5.0, RNC does not initiate Iu rate control towards the CN except in relocation scenarios.
If Iu UP used is version 2, RNC may receive Iu rate control from the CN in case of TrFO/TFO. When that
happens, RNC triggers an RRC TFC control indicating the new max allowed rate in the uplink.
SRB2 is used to carry the RRC TFC control message.
Section 7 � Module 1 � Page 84
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 84
7 AMR Rate Change during the Call
7.1 General Principles [cont.]
The DL AMR rate is based on the observed amount of DL power consumption and is selected according the following rule:
•DL Requested MBR ≥ rate > DL Requested GBR
Rule: Eligible DL AMR Rates
The UL/DL AMR rate is based on the observed Iub DS load, in addition of the above rule, the following one is fulfilled:
•UL Requested MBR ≥ rate > UL Requested GBR
Rule: Eligible UL/DL AMR Rates
RAB Assignment Request
RNC
DL:
•Any rate control done
•Max Bit Rate = 12.2 kbps
UL:
•Rate control on UL cell load
•Max Bit Rate is selectedUL Cell Color
Max AMR Rate
Call Establishment
During the Call
RNC
RRC TFC ControlCN
Iu UP rate Control
delayBetweenAmrRateControls(RadioAccessService)
During the call, no Radio Bearer adaptation based on cell load (power, code) is performed. The allocated
RB (speech part) is kept unchanged. During the call, the RNC will only control the AMR rate. The principle
is the following:
� At the establishment, once the UE is eligible for AMR rate control, the RNC will performs:
� In downlink, any rate control done. The maximum rate 12,2Kbps is given at establishment.
� In uplink, a rate control is performed on the UL Cell Load criteria which give the maximum rate at
call establishment.
� During the call, driven by rate control triggers, the RNC adjusts AMR rates by initiating RRC TFC control
on uplink and Iu UP rate control on downlink.
Procedure description:
Depending on the outcome of the IUB load table, the RNC initiates
� DL Rate control: Iu UP Rate Control frame sent to core network
� UL rate control: RRC TFC control message sent to UE
� Whenever applicable, the rate is decreased step by step, this means that several Iu UP rate control /
RRC TFC control messages may be successively sent.
Section 7 � Module 1 � Page 85
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 85
7 AMR Rate Change during the Call
7.2 Iub DS load criteria
I u b D S
t r a n s p o r t
C o l o u r
O L S M a x A M R r a t e
G o l d e . g . 1 2 . 2
G R E E N S i l v e r e . g . 1 2 . 2
B r o n z e e . g . 7 . 9 5
G o l d e . g . 1 2 . 2
Y E L L O W S i l v e r e . g . 7 . 9 5
B r o n z e e . g . 5 . 9
G o l d e . g . 5 . 9
R E D S i l v e r e . g . 4 . 7 5
B r o n z e e . g . 4 . 7 5
The Max AMR rate = min (output of the iRM table, max requested AMR rate)
This value is used to identify the Iub transport equivalent bit
rate (EBR), which will be used as input of the Iub CAC.
Rule : Determination of the Max AMR rate on Iub
RNC
DS
Iub
Max AMR Rate
Symetric service: DL load estimation only
Table is played
• After any mobility event, to help determine the new max UL/DL rate
• In static state, determine possible UL/DL rate change by checking the Active Set Iub DS DL load color every configurable period.
Iub DS Load
A specific iRM table is introduced to determine the max allowed AMR rate based on the OLS and the Iub DS
DL load color of the Active Set.
The Iub DS load is only calculated for the DL assuming that in most of the cases the traffic over Iub DS is
rather symmetric or asymmetric services with higher rate in the DL.
In order to avoid any ping pong effects due to the application of different criteria, the downlink rate
upgrade is not triggered based on Iub DS load colour change. Only the trigger of TxCP measurement
report is used to upgrade the rate of an AMR call.
Section 7 � Module 1 � Page 86
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 86
7 AMR Rate Change during the Call
7.3 UL Cell load criteria
� A specific UL iRM table is introduced to determine the max allowed AMR rate based on the OLS and the UL cell load color of the cells in the active set. This table is played as follow:
Output
UL rate control: RRC TFC control message sent to UE
U L c e l l l o a d
C o l o r
O L S M a x A M R r a t e
G o l d e . g . 1 2 . 2
G R E E N S i l v e r e . g . 1 2 . 2
B r o n z e e . g . 7 . 9 5
G o l d e . g . 1 2 . 2
Y E L L O W S i l v e r e . g . 7 . 9 5
B r o n z e e . g . 5 . 9
G o l d e . g . 5 . 9
R E D S i l v e r e . g . 4 . 7 5
B r o n z e e . g . 4 . 7 5
In static state, determine possible UL rate change by checking the UL cell load color of the Active Set every configurable period (Cf. parameter delayBetweenAmrRateControls)
At admission to help determine the max initial UL rate based on the UL cell load color of the cells of the Active Set
After every primary cell update, to help determine the new max UL rate based on the UL cell load color of the cells of the Active Set
Multi-service: The AMR rate control based on radio criteria (UL Cell Load) does not apply for multi-service
Restriction:
The cell load color is calculated as follows:
UL cell load color = max (UL radio load color, UL
CEM load color)
•� With green < yellow < red
The UL Cell Loaddoes not take into account the load
generated by the E-DCH traffic.
Section 7 � Module 1 � Page 87
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 87
7 AMR Rate Change during the Call
7.4 DL Power load criteria
� A specific DL iRM table is introduced to determine the max allowed AMR rate based on the OLS and the DL power load color of the cells of the active set. This table is played per individual call:
Output
DL Rate control: Iu UP Rate Control frame sent to core network
In static state, determine possible DL rate change by checking the DL power load color of the Active Set every configurable period (Cf. parameter delayBetweenAmrRateControls)
After every primary cell update, to help determine the new max DL rate based on the DL power load color of the cells of the active set
T o t a l D L T x
P o w e r l o a d
C o l o r
O L S M a x A M R r a t e
G o l d e . g . 1 2 . 2
G R E E N S i l v e r e . g . 1 2 . 2
B r o n z e e . g . 7 . 9 5
G o l d e . g . 1 2 . 2
Y E L L O W S i l v e r e . g . 7 . 9 5
B r o n z e e . g . 5 . 9
G o l d e . g . 5 . 9
R E D S i l v e r e . g . 4 . 7 5
B r o n z e e . g . 4 . 7 5
Multi-service : The RNC initiated AMR rate control based on radio criteria (Total DL Tx Power load) does not apply if PS RAB(s) mapped on DCH (whereas it applies if PS RAB(s) mapped on HSDPA)
Restriction for Multi-servciewith PS on DCH:
The DL Total TxPower does not include the power of the PA used by
HSDPA
Section 7 � Module 1 � Page 88
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 88
7 AMR Rate Change during the Call
7.5 DL Tx CP criteria
The dedicated measurement is initiated on the primary cell at call establishment or whenever there is a change of
the primary cell
Dedicated measurements initiation
Thresholds Rules for Downlink TxCP criteria
maxDlTxPower = maxDlTxPowerPerOls[CurrentOls].maxDlTxPower
RateDecThreshold = pcpichPower + maxDlTxPower – dlAmrRateDecreaseTxcpTrigger.thresholdDelta
RateIncThreshold = pcpichPower + maxDlTxPower – dlAmrRateIncreaseTxcpTrigger.thresholdDelta
Where
dlAmrRateDecreaseTxcpTrigger.thresholdDelta ? dlAmrRateIncreaseTxcpTrigger.ThresholdDelta
Time To Trigger value determination for Downlink TxCP criteria
RateDecTTT = dlAmrRateDecreaseTxcpTrigger.timeToTrigger
RateIncTTT = dlAmrRateIncreaseTxcpTrigger.timeToTrigger
t
DL Tx Code Power
DL TX Max Power
DL TX Min Power
Rate Dec Th
Rate Inc Th
1. Crossing of the Threshold triggers DL Rate
Change Request after a TimeToTrigger
2. Rate Change↓
12.2 → 5.9
3. Crossing of the Threshold triggers DL Rate Change Request
4. Rate Change ↑
5.9 → 12.2
Rate Change on DL Tx Code Power
Event triggered (A/B)
NBAP Event A
NBAP Event B
Iu UP Rate Control (new Max DL rate) to the Core Network
Iu UP Rate Control (new Max DL rate) to the Core Network
RateDecTTT
RateIncTTT
DL Tx CP
At establishment of a speech bearer eligible to rate control, the RNC configures NBAP dedicated
measurement reporting on the primary cell in order to track the DL Transmitted Code Power.
Thus, the ALCATEL-LUCENT RNC can detect deterioration or improvement of radio conditions through NBAP
dedicated measurements on the transmitted code power.
DL Tx CP criteria: Dedicated measurements configuration
In order to detect a rate decrease / increase condition, the RNC configures dedicated measurement
reporting with the following characteristics.
� Measurement quantity = transmitted code power (Radio Link)
� Reporting mode = event triggered
� Event = A / B
� Threshold1 = RateDecThreshold
� Threshold2 = RateIncThreshold
� Time to trigger = RateDecTTT / RateIncTTT. This time to trigger indicates the time during which the
threshold condition should be fulfilled before the UE sends the event to the RNC.
Section 7 � Module 1 � Page 89
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 89
7 AMR Rate Change during the Call
7.6 Parameters Settings
Activation of the UL Cell Load criteria
The AMR rate control based on uplink cell load criteria can be activated at the RNC level and per DlUserService. To activate it, the parameter isAmrRateControlOnULCellLoadAllowed should be set to TRUE.
RNC
RadioAccessService
DLUserService UlIrmTableCellLoadConfClass
IrmAmrRateList
IrmAmrRatePerOls
isAmrRateControlOnUlCellLoadAllowed
irmAmrRate4_75k, 5_15k, 5_9k, 6_7k, 7_4k, 7_95k,
10_2k, 12_2k
delayBetweenAmrRateControls
isAmrRateControlOnUlCellLoadAllowed
Section 7 � Module 1 � Page 90
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 90
7 AMR Rate Change during the Call
7.6 Parameters Settings [cont.]
Activation of the DL Power Load criteria
The AMR rate control based on DL Power Load criteria can be activated at the RNC level and per DlUserService. To activate it, the parameter isAmrRateControlOnDlPowerLoadAllowed should be set to TRUE.
RNC
RadioAccessService
DLUserService DlIrmTablePowerLoadConfClass
IrmAmrRateList
IrmAmrRatePerOls
isAmrRateControlOnDlPowerLoadAllowed
irmAmrRate4_75k, 5_15k, 5_9k, 6_7k, 7_4k, 7_95k,
10_2k, 12_2k
delayBetweenAmrRateControls
isAmrRateControlOnDlPowerLoadAllowed
Section 7 � Module 1 � Page 91
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 91
7 AMR Rate Change during the Call
7.6 Parameters Settings [cont.]
Activation of the Iub DS Load criteria
The AMR rate control based on Iub DS Load criteria can be activated at the RNC level and per DlUserService. To activate it, the parameter isAmrRateControlOnIubDsLoadAllowedshould be set to TRUE.
RNC
RadioAccessService
DLUserService DlIrmTableIubDsLoadConfClass
IrmAmrRateList
IrmAmrRatePerOls
isAmrRateControlOnIubDsLoadAllowed
irmAmrRate4_75k, 5_15k, 5_9k, 6_7k, 7_4k, 7_95k,
10_2k, 12_2k
delayBetweenAmrRateControls
isAmrRateControlOnIubDsLoadAllowed
Section 7 � Module 1 � Page 92
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 92
7 AMR Rate Change during the Call
7.6 Parameters Settings [cont.]
Activation of the Downlink Tx CP criteria
Threshold = pcpichPower + maxDlTxPowerPerOls[].maxDlTxPower – thresholdDelta
RNC
RadioAccessService
DLUserService DedicatedConf
PowerConfClass
DlUsPowerConf
DlAmrRateDecreaseAbsoluteTxcpTrigger
DlAmrRateIncreaseAbsoluteTxcpTrigger
Threshold
timeToTrigger
Threshold
timeToTrigger
DlAmrRateDecreaseTxcpTrigger
DlAmrRateIncreaseTxcpTrigger
thresholdDelta
timeToTrigger
delayBetweenAmrRateControls
maxDlTxPowerPerOls
thresholdDelta
timeToTrigger
Section 7 � Module 1 � Page 93
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 93
8 PS CN Requested RAB Modification
Section 7 � Module 1 � Page 94
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 94
8 PS CN Requested RAB Modification
8.1 PS CN Requested RAB Modification
What ?• Change of the RAB parameters that were initially negotiated for one or several PDP
contextsHow ?• CN sends a RAB Assignment Request message to the RNC indicating one or several
RAB parameters to modify
RNC and Node B support the modification of the following QoS parameters:
• Traffic Class (TC) – Interactive to/from Background
• Maximum Bit Rate (MBR)
• Allocation/Retention Priority (ARP)
• Traffic Handling Priority (THP)
• Signalling Indicator (SI)
isPsRabModificationFullFeatureAllowedisPsRabModificationAllowed
(RadioAccessService)
Modification of the following QoS parameters is not supported:
• Guaranteed Bit Rate (GBR)
• Transfer Delay (TD)
• Transport Layer Information (TLI)
• Traffic Class (TC) – Streaming to/from Interactive or Background
Following changes in Traffic Class are supported:
� (CS) + PS Interactive to/from (CS) + PS Background
� (CS) + PS Interactive + PS Interactive to/from (CS) + PS Interactive + PS Background
� (CS) + PS Interactive + PS Background to/from (CS) + PS Interactive + PS Interactive
� (CS) + PS Interactive + PS Background to/from (CS) + PS Background + PS Background
Streaming traffic class can’t be changed but in a RAB combination that includes a streaming RAB, the I/B part can be modified:
� (CS) + PS Streaming + PS Interactive to/from (CS) + PS Streaming + PS Background
Traffic Class change may lead to AsConf change, thus a SRLR procedure and it may result in change of OLS, HSDPA SPI, E-DCH SPI, MLP and minBR
When the Core Network changes the Traffic Class, a new scheduling priority (SPI) is deduced by the RNC and is provided to the HSDPA and HSUPA schedulers
isPsRabModificationFullFeatureAllowed: RAB modification (full feature) activation flag which allows parameters TC, MBR, ARP, THP and SI of a Ps Streaming or Ps I/B RAB to be modified
This UA7 feature is the extension of UA6 feature PM31039 – PS CN RAB Modification, available in the Korean
market. The parameter isPsRabModificationAllowed was introduced with the UA6 feature, and must be set accordingly, so that the UA7 feature operates as expected.
Section 7 � Module 1 � Page 95
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 95
8 PS CN Requested RAB Modification
8.2 RAB Modification in a Non-Iur Scenario with SRLR
Step 1
� The SGSN sends RAB Assignment Request for RAB Id (ID1)
� If the RAB Id exists, this will be considered as an attempt to invoke RAB Modification
� Otherwise it is an initial RAB Assignment
� Qos 2 is the new QoS information, and may include changes in one or more of the parameters supported for modification
� RAB Matching is executed, irrespectively of the value of the new RAB parameters, which is required because the Granted RB may be different from the Reference RB, possibly as a result of the cell colour change
RANAP RAB Assignment Request (ID1, QoS2)
UE SRNC CN
NBAP Radio Link Reconfiguration Prepare
NBAP Radio Link Reconfiguration Ready
Establishment of Replacement AAL2 Bearers
(only applicable with ATM transport and bearers mapped on DCH)
ERQ
ECF
NBAP Radio Link Reconfiguration Commit
RRC Radio Bearer Reconfiguration
RRC Radio Bearer Reconfiguration Complete
Release of Initial AAL2 Bearers
(only applicable with ATM transport and bearers mapped on DCH)
REL
RLC
Establishment of RAB (ID1, QoS1) and associated RBs on SRNC and Node B
DCH-FP RL DL/UL Synchronization
RANAP RAB Assignment Response (ID1)
Node B
MBR change may apply to UL and DL for Interactive, Background and Streaming RABs
For PS I/B RAB (in mono or multi-service):
� A SRLR will occur if the new Granted bit rate, after RAB Matching, is different from the current bit rate
(for R99 bearers)
� In case of HS-DSCH and E-DCH, there will be no SRLR
For PS Streaming RAB (in mono or multi-service):
� In all cases, a SRLR will occur if the new Granted bit rate is different from the current bit rate
For a MBR modification, the new value is taken into account to limit the user throughput in the RNC if the
source conformance mechanism is enabled (a reduced MBR can be applied in uplink and/or downlink to a
user generating a very high data volume leading to an unfair resource usage)
Section 7 � Module 1 � Page 96
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 96
Step 5
� Release of old Q.AAL2 connection, when Transport Bearer Replacement is used
Establishment of Replacement AAL2 Bearers
(only applicable with ATM transport and bearers mapped on DCH)
8 PS CN Requested RAB Modification
8.2 RAB Modification in a Non-Iur Scenario with SRLR [cont.]
RANAP RAB Assignment Request (ID1, QoS2)
RANAP RAB Assignment Response (ID1)
Step 2
� NBAP Radio link reconfiguration preparation procedure
Step 3
� Transport Bearer Replacement is used, when the RAB is mapped to a DCH (it won’t be used when mapped to HSDPA)
� In the latter case, the RNC will still update the CAC parameters (EBR) and the congestion control parameters (minBrForHsdpa)
Step 4
� Normal sequence associated with the completion of a SRLR
Step 6
� RAB Assignment Response is sent to CN
SRNC CN
NBAP Radio Link Reconfiguration Prepare
NBAP Radio Link Reconfiguration Ready
ERQ
ECF
NBAP Radio Link Reconfiguration Commit
RRC Radio Bearer Reconfiguration
RRC Radio Bearer Reconfiguration Complete
Release of Initial AAL2 Bearers
(only applicable with ATM transport and bearers mapped on DCH)
REL
RLC
Establishment of RAB (ID1, QoS1) and associated RBs on SRNC and Node B
DCH-FP RL DL/UL Synchronization
UE Node B isTrspBearerReplacementAllowedOnSrnc4Dch
(RadioAccessService)
An ARP or THP modification may result in change of OLS, HSDPA SPI, E-DCH SPI, MLP and minBR
For RABs mapped on DCH, a SRLR will occur if the new Granted bit rate is different from the current bit
rate
For RABs mapped on HS-DSCH or E-DCH, whenever a SPI occurs, the Node B must be notified of the new SPI
value (the UE is notified for E-DCH).
If isPsRabModificationFullFeatureAllowed = TRUE, then isPsRabModificationAllowed = TRUE.
If isPsRabModificationAllowed = TRUE, then isTrspBearerReplacementAllowedOnSrnc4Dch = TRUE (transport bearer replacement is mandatory at serving side to support RAB Modification).
Section 7 � Module 1 � Page 97
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 97
8 PS CN Requested RAB Modification
8.3 RAB Modification in a Non-Iur Scenario without SRLR
As a basic rule, no SRLR is triggered when the output of RAB Matchingprocedure does not result in DCHs to modify, HS-DSCH Mac-d flows to modifyor E-DCH Mac-d flows to modify
RANAP RAB Assignment Request (ID1, QoS2)
UE Node B SRNC CN
Establishment of RAB (ID1, QoS1) and associated RBs on SRNC and Node B
RAB Matching Output: “No AsConf change”
RANAP RAB Assignment Response (ID1)
Section 7 � Module 1 � Page 98
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 98
Module Summary
� This lesson covered the following topics:
� Packet data management principles
� Always On and associated parameters
� RB Rate Adaptation and associated parameters
� iRM Scheduling and associated parameters
� iRM Preemption and associated parameters
� Preemption and associated parameters
� PS Core Network requested RAB modification
Section 7 � Module 1 � Page 99
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 99
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 7 � Module 1 � Page 100
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionCall Management �
7 � 1 � 100
End of Module
Section 8 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
8�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 8Mobility in Reselection
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 8 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 2
Blank Page
This page is left blank intentionally
Max. number of neighbors updated (UA7)Improvements on RAN model extracts for cell reselection in non-DCH connected mode
Chatila, RayanRyser, SigridCharneau, Jean-Noel
2010-04-1501
RemarksAuthorDateEdition
Document History
Section 8 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Describe PLMN selection and associated parameters
� Describe Cell selection and associated parameters in Idle Mode
� Describe Cell reselection and associated parameters in Idle Mode
� Case of mobility in Connected Mode in Cell_FACH, Cell_PCH or URA_PCH
Section 8 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 8 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 5
Table of Contents
Switch to notes view!Page
1 Network Selection 71.1 PLMN Selection 8
2 Cell Selection in Idle Mode 92.1 Cell Selection Criteria 102.2 UE Power Compensation 11
3 Cell Reselection in Idle Mode Principles 123.1 General Concept 133.2 Mobility in Idle mode, Cell_FACH, Cell_PCH and URA_PCH 143.3 Idle Mode Neighboring List 153.4 Cell Reselection Eligibility Criteria 163.5 High Mobility Detection 17
4 Cell Reselection in Idle Mode without HCS 184.1 Measurements Rules without HCS 194.2 Level Ranking Criterion without HCS 204.3 Quality Ranking Criterion without HCS 214.4 Cell Ranking Algorithm 224.5 Triggering Algorithm 234.6 Exercise: Multi-Layer Cell Structure, HCS not used 24
5 Cell Reselection in Idle Mode with HCS 265.1 Principles 275.2 Measurements Rules with HCS in Low Mobility 285.3 HCS Quality Level Threshold Criterion 295.4 Measurements Rules with HCS in High Mobility 305.5 Level and Quality Ranking Criteria with HCS 315.6 HCS Cell Filtering in Low Mobility 325.7 HCS Cell Filtering in High Mobility 335.8 Cell Ranking Algorithm 345.9 Triggering Algorithm 355.10 Exercise: Multi-Layer Cell Structure, HCS used 36
6 Cell reselection in non-DCH Connected Mode 386.1 SIB 4 and SIB 12 Broadcast 396.2 SIB3 & SIB11 Parameters & Objects 406.3 SIB4 Parameters & Objects 416.4 SIB12 Parameters & Objects – UMTS FDD Neighbour 426.5 SIB11 & SIB12 Parameters & Objects – GSM Neighbour 436.6 Exercises 446.6.1 Exercise1: Mono-Layer Topology 456.6.2 Exercise2: Bi-Layer Topology 466.6.3 Exercise3: Tri-Layer Topology 48
7 Cell Status and Reservation 517.1 Cell Status and Reservation Process 52
8 Location Registration 538.1 LAC/RAC/SAC 54
Section 8 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 6
Table of Contents [cont.]
Switch to notes view!
This page is left blank intentionally
Section 8 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 7
1 Network Selection
Section 8 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 8
1 Network Selection
1.1 PLMN Selection
� Describe Cell reselection and associated parameters
MCC MNC MSIN
mobileCountryCode (RNC/Plmn)
mobileNetworkCode (RNC/Plmn)
mobileCountryCode (CsCoreNetworkAccess)
mobileNetworkCode (CsCoreNetworkAccess)
mobileCountryCode (PsCoreNetworkAccess)
mobileNetworkCode (PsCoreNetworkAccess)
mobileCountryCode (FDDCell)
mobileNetworkCode (FDDCell)
MIB / P
-CCPCH
Preferred PLMN List Forbidden PLMN List
The different UMTS networks are identified uniquely in the world by the PLMN identifier composed of:
� the Mobile Country Code (MCC)
� the Mobile Network Code (MNC)
For one carrier, once the cell search procedure is completed, the UE has found the strongest cell and
knows its scrambling code. It is then possible to decode the Primary CCPCH.
The MNC and MCC are part of the system information broadcast on the P-CCPCH (in the Master Information
Block or MIB).
The UE then decodes the received PLMN identifiers and determines whether or not the PLMN is permitted
according to the lists of preferred and forbidden PLMN (stored in the UE).
If the PLMN is permitted and chosen, the cell selection parameters are used by the UE to determine which
cell to camp on.
Section 8 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 9
2 Cell Selection in Idle Mode
Section 8 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 10
2 Cell Selection in Idle Mode
2.1 Cell Selection Criteria
Srxlev > 0
����
CPICH_RSCP > qRxLevMin + Pcompensation
P-CPIC
H
S Criteria
AND
qQualMin
qRxLevMin
Squal > 0
����
CPICH_Ec/No > qQualMin
FDDCCe
ll
FDDCell
CellSelectionInfo
Squal and SRxlev are the two quantities used for cell selection criteria.
If the criteria are fulfilled, the UE moves to the camped normally state where the following tasks will be
performed:
� Select and monitor the indicated PICH and PCH.
� Monitor relevant System Information.
� Perform measurements for the cell reselection evaluation procedure.
If the criteria are not fulfilled, the UE will attempt to camp on the strongest cell of any PLMN and enter in
the camped on any cell state where it can only obtain limited service (emergency calls). The following
tasks will be performed in the camped on any cell state:
� Monitor relevant System Information.
� Perform measurements for the cell reselection evaluation procedure.
� Regularly attempt to find a suitable cell trying all radio access technologies that are supported by the
UE. If a suitable cell is found, the cell selection process restarts.
The above parameters are broadcast in SIB3.
Section 8 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 11
2 Cell Selection in Idle Mode
2.2 UE Power Compensation
NodeB
RNC
FDDCell
CellSelectionInfo
RadioAccessService
DedicatedConf
PowerConfClass
Pcompensation=
max (sibMaxAllowedUlTxPowerOnRach – P_MAX, 0)
Srxlev > 0
����
CPICH_RSCP > qRxLevMin + Pcompensation
+21 dBm4
+24 dBm3
+27 dBm2
+33 dBm1
P_MAXUE Class
qRxLevMinsibMaxAllowedUlTxPowerOnRach
powerConfId
Pcompensation = max (sibmaxAllowedUlTxPowerOnRach – P_MAX, 0).
Pcompensation is a compensation factor to penalize the low power mobiles.
� sibMaxAllowedUlTxPowerOnRach = maximum transmit power level the UE is allowed to use while accessing the cell on RACH.
� P_MAX = maximum output power of the UE according to its power class.
� Class 1: P_MAX= 33dBm
� Class 2: P_MAX= 27dBm
� Class 3: P_MAX= 24dBm
� Class 4: P_MAX= 21dBm
Section 8 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 12
3 Cell Reselection in Idle Mode Principles
Section 8 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 13
3 Cell Reselection in Idle Mode Principles
3.1 General Concept
HM not detectedCell Reselection after tReselection
Higher priority is favored
HM detectedCell Reselection after tReselection * speedDependScalingFactor
Lower priority is favored
P1
P2 P2 P2
P3 P3 P3 P3 P3P3
� 2 different 3GPP UE algorithms
� Classical for mono-layer network
� Hierarchical Cell Structure (HCS) algorithm
� HCS Priority for Serving cell and Neighboring cells are introduced (between 0 and 7)
� Both algorithms steps:
� Define which type of neighboring cells have to be measured (intra-freq, inter-freq, inter-RAT)
� Check if measured cells are eligible to cell reselection
� Rank the eligible cells to eventually perform cell reselection
� Different behaviors in case:� HCS is used / NOT used
� High-Mobility Detection (HMD) is detected / NOT detected
Cell Reselection without HCS differs from UA4.2 only by the fact that High Mobility Detection is used in
reselection triggering timer.
Cell Reselection with HCS was introduced in UA5.
Section 8 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 14
3 Cell Reselection in Idle Mode Principles
3.2 Mobility in Idle mode, Cell_FACH, Cell_PCH and URA_PCH
Cell SelectionS criterion
Cell Reselection without HCS
Measurements Rules without HCS
Cell Ranking without HCSusing High Mobility Detection
Level + QualityR criteria
Cell Reselection with HCS
Measurements Rules with HCS
using High Mobility Detection
Quality Level Threshold H Criterion
Cell Ranking with HCSusing High Mobility Detection
HCS is usedHCS is not used
Level + QualityR criteria
Cell Filteringusing HCS Priority
Cell Reselection without HCS differs from UA4.2 only by the fact that High Mobility Detection is used in
reselection triggering timer.
Cell Reselection with HCS was introduced in UA5.
Section 8 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 15
3 Cell Reselection in Idle Mode Principles
3.3 Idle Mode Neighboring List
sib11AndDchNeighbouringFddCellAlgo
(FDDCell)
sib11OrDchUsage
(UMTSFddNeighbouringCell)
(GsmNeighbouringCell)
SIB11 /
P-CCPC
H
Serving
Cell
Max 96 cells
SIB11 Neighboring List
• UMTSFddNeighbouringCell List
• GsmNeighbouringCell List
FDDCell Neighboring List
• intra-frequency FDDCells
• inter-frequency FDDCells
• GSM Cells
The list of neighboring cells is broadcasted through SYSInfo.
The information and parameters related to the neighboring cells are contained into two subtrees in the
Radio Access Network Model:
� UMTSNeighbouringFDDCell for FDD intra- and inter-frequency neighbors
� GSMNeighbouringCell for GSM neighbors
An algorithm is used to declare and control correctly the list of neighboring cells in order to differentiate
between the configuration of idle mode/cell_FACH mode neighbors (sent in SIB11) and cell_DCH connected
mode neighbors. The idle mode/cell_FACH mode neighboring list is a subset of the cell_DCH connected
mode neighboring list. The differentiation is set through the sib11OrDchUsage parameter on each umtsFddNeighbouringCell. Note that this parameter is only used when sib11NeighboringFddCellAlgo is set to manual.
It is recommended to set sib11OrDchUsage to sib11AndDch for less than 96 neighbouring cells (either GSM or FDD) if UA7 feature 34291 “support of 64 UMTS neighbours” is activated (via isEnhancedSib11Allowed). Else, it should be limited to 48 neighbouring cells.
sib11OrDchUsage must be set to dchUsage for the other remaining neighbouring cells.
HCS usage: HCS requires its related information elements to be added to sib-11 thus leading to a shrinkage of the space available for neighbor data. When the cell flag isHcsUsed is set to TRUE this feature can roughly support up to 87 cells (serving cell + 31 FDD neighbouring Intra + 32 FDD neighbouring Inter + 23 I-RAT neighbouring cells) in the SIB11.
Section 8 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 16
3 Cell Reselection in Idle Mode Principles
3.4 Cell Reselection Eligibility Criteria
UMTSFddNeighbouringCell
Srxlev > 0Squal > 0
> > + PcompensationCPICH_Ec/No qQualMin (UmtsNeighbouringRelation) qRxLevMin(UmtsNeighbouringRelation)
CPICH_RSCPAND
GSMNeighbouringCell
QRxLeavMeas > qRxLevMin (GsmNeighbouringCell) + Pcompensation
Srxlev > 0
Max(MaxAllowedUlTxPower - P_max, 0)
(GSMCell)
Max(MaxAllowedUlTxPower - P_max, 0)
(UmtsNeighbouringRelation)
Once the criteria for GSM or UTRAN/FDD neighboring cells tracking and measurements based on
CPICH_Ec/No are applied, a criteria S is applied on the measured GSM or FDD neighboring cells to assess
their eligibility to cell reselection.
To be eligible, the intra and inter-frequency FDD cells must fulfill criteria very similar to what is used for
Cell Selection. But this time these relationships shall be verified on the neighbor cell, this means the
measurements are made on this neighbor cell, and the parameters are those defined in the neighboring
relationship.
To be eligible, the inter-system GSM cells must fulfill criteria shown in the above slide. Any cell (serving
and any GSM or UTRAN/FDD neighboring cell), which fulfills these criteria, will be part of the list of cells
for ranking.
Section 8 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 17
3 Cell Reselection in Idle Mode Principles
3.5 High Mobility Detection
Nb of Reselection > nCrduring tCrMax
UE not in High Mobility state
UE enters High Mobility state
Nb of Reselection <= nCrduring tCrMax + tCrMaxHyst
nCr
tCrMax
tCrMaxHyst
FDDCell
CellSelectionInfo
CrMgt
High and Low mobility UEs are distinguished thanks to the rate of Cell Reselection.
Section 8 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 18
4 Cell Reselection in Idle Mode without HCS
Section 8 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 19
4 Cell Reselection in Idle mode without HCS
4.1 Measurements Rules without HCS
sIntraSearch
sInterSearch
sSearchRatGsm
isHcsUsed = FalsesSearchHcs
sHcsRatGsm
Intra-frequency No measurement
Intra-frequency Inter-frequency Inter-frequency
Intra-frequency Inter-frequency
GSM Inter-frequency
GSM
Srxlev
sInterSearch sIntraSearch sSearchRatGsm
sSearchHcs
sHcsRatGsm
Squal
FDDCell
CellSelectionInfo
With isHcsUsed set to False:
� “Use of HCS” IE broadcasted in SIB11 is set to “Not used”
� Cell reselection is processed the same way as before UA5.0
If sIntraSearch is not sent for the serving cell, the UE performs intrafrequency
measurements.
If sInterSearch is not sent for the serving cell, the UE performs interfrequency
measurements.
If sSearchRatGsm is not sent for the serving cell, the UE performs
measurements on GSM cells.
Note: If a negative value is datafilled and sent in SIB3, the UE shall consider the value
to be 0 (see [3GPP_R04]).
Note: IE present in SIB3 is encoded as follows: sHcsRatGsm = (IE * 2) +1
Section 8 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 20
4 Cell Reselection in Idle mode without HCS
4.2 Level Ranking Criterion without HCS
qHyst1 (CellSelectionInfo)
UMTSFddNeighbouringCell
GSMNeighbouringCell
CPICH_RSCP qOffset1sn (UmtsNeighbouringRelation)CPICH_RSCPRLs = +
RL criterion for Serving Cell RL criterion for FDD Neighboring Cell
RLn = –
FDDCell
RxLev qOffset1sn (GsmNeighbouringCell)RLn = –
RL criterion for GSM Neighboring Cell
qHyst1 (CellSelectionInfo)
qOffset1sn (UmtsNeighbouringRelation)
qOffset1sn (GsmNeighbouringCell)
The cell level ranking criterion is used to rank the cells prior to the reselection. When HCS
is not used, the behavior is the same as before UA5.0.
The serving cell and all the neighboring cells being eligible (S criteria) are ranked accordingly to the RL
criteria, as defined below:
� RLs = Qmeas,s + Qhysts; for the serving cell
� RLn = Qmeas,n - Qoffsets,n; for any GSM or UTRAN/FDD neighboring cells
Where Qmeas is the CPICH_RSCP for the FDD case. For GSM cells, RxLev is used instead of CPICH RSCP
in the mapping function.
Where Qhysts is the qHyst1 parameter of the CellSelectionInfo object.
Where Qoffset is the qOffset1sn parameter of the GSMcell object.
Section 8 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 21
4 Cell Reselection in Idle mode without HCS
4.3 Quality Ranking Criterion without HCS
RQn = –RQs = +CPICH_Ec/No CPICH_Ec/NoqHyst2 (CellSelectionInfo) qOffset2sn (UmtsNeighbouringRelation)
RQ criterion for Serving Cell RQ criterion for Neighboring Cell
FDDCell UMTSFddNeighbouringCell
qHyst2 (CellSelectionInfo)
qOffset2sn (UmtsNeighbouringRelation)
The cell quality ranking criterion is used to rank the cells prior to the reselection. When HCS
is not used, the behavior is the same as before UA5.0.
The serving cell and all the FDD neighboring cells being eligible (S criteria) are ranked accordingly to the RQ
criteria, as defined below:
� RQs = Qmeas,s + Qhysts; for the serving cell
� RQn = Qmeas,n - Qoffsets,n; for any UTRAN/FDD neighboring cells
Where Qmeas is the CPICH Ec/No measurement.
Where Qhysts is the qHyst2 parameter of the CellSelectionInfo object.
Where Qoffset is the qOffset2sn parameter of the UMTSFddNeighbouringCell object.
Section 8 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 22
4 Cell Reselection in Idle mode without HCS
4.4 Cell Ranking Algorithm
FDDCell
CPICH_Ec/No CPICH_RSCP
Best cell is a ..?
Best GSMCellis reselected
GSMCell
Best FDDCellafter First Ranking
is reselected
Best FDDCell
after Second Rankingis reselected
qualMeas = ..?
Eligible CellsFirst Ranking RL
(CPICH_RSCP & RxLev)
Second Ranking RQ
(CPICH_Ec/No)
qualMeas (CellSelectionInfo)
Then the cell reselection process is as follows:
� If a GSM cell is ranked as the best cell, then the UE shall perform cell reselection to that GSM cell.
� If an FDD cell is ranked as the best cell and the quality measure parameter qualMeas for cell re-selection is set to qualMeasRscp, then UE shall perform cell re-selection to that FDD cell.
� If an FDD cell is ranked as the best cell and the quality measure parameter qualMeas for cell re-selection is set to qualMeasEcno, then UE shall perform a second ranking.
Note: that parameter has been introduced in UA5.0 and was previously hard-coded to qualMeasEcno.
Section 8 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 23
4 Cell Reselection in Idle mode without HCS
4.5 Triggering Algorithm
UMTSFddNeighbouringCellInter-freq
UMTSFddNeighbouringCellIntra-freq
GSMNeighbouringCell
ServingFDDCell
tReselection (UE not in High Mobility)tReselection x speedDependScalingFactorTReselection (UE in High Mobility)
tReselectionx interRatScalingFactorTReselection(UE not in High Mobility)
tReselectionx speedDependScalingFactorTReselectionx interRatScalingFactorTReselection(UE in High Mobility)
tReselection x interFreqScalingFactorTReselection (UE not in High Mobility)tReselection x speedDependScalingFactorTReselection x interFreqScalingFactorTReselection (UE in High Mobility)
speedDependScalingFactorTReselection
(CrMgt)
tReselectioninterFreqScalingFactorTReselectioninterRatScalingFactorTReselection
(CellSelectionInfo)
� Cell reselection triggered if
� the target cell remains best-ranked during more than tReselection sec
� the UE has been camping on the current serving cell since at least 1 sec
� For R5 UE, tReselection is replaced by
Several scaling factors, introduced by 3GPP R5, can be applied to tReselection:
� speedDependScalingFactorTReselection (used with or without HCS usage), between 0 and 1, in order to speed up the reselection when High-Mobility state is detected.
� interFreqScalingFactorTReselection between 1 and 4.75, in order to delay the reselection to Inter-frequency neighboring cell.
� interRatScalingFactorTReselection between 1 and 4.75, in order to delay the reselection to GSM neighboring cell.
Note: All the parameters related to cell selection/reselection are broadcasted on the BCCH using either:
� SIB3 for cell reselection parameters related to the serving cell
� SIB11 for cell reselection parameters related to the neighboring cells.
Section 8 � Module 1 � Page 24
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 24
4 Cell Reselection in Idle mode without HCS
4.6 Exercise: Multi-Layer Cell Structure, HCS not used
Neighb.MC
Neighb.MA Neighb.MB
Serv.mc
Macro FDDcells F2
Micro FDDcells F1
Neighb.GC
Neighb.GA Neighb.GBMacro GSMcells
Neighbo.mbNeighbo.ma
20-73Neighboring cell GC
20-80Neighboring cell GB
20-98Neighboring cell GA
100-85-4Neighboring cell MC
100-89-5Neighboring cell MB
100-99-9Neighboring cell MA
00-104-10Neighboring cell mb
00-118-21Neighboring cell ma
44-108-12Serving cell mc
qOffset2sn(dB)
qHyst2(dB)
qOffset1sn(dB)
qHyst1(dB)
CPICH_RSCP / GSM RSSI (dBm)
CPICH_Ec/No (dB)
Cell
Section 8 � Module 1 � Page 25
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 25
4 Cell Reselection in Idle mode without HCS
4.6 Exercise: Multi-Layer Cell Structure, HCS not used [cont.]
� Assumptions� UE class 3
� qualMeas = qualMeasEcno
� qQualmin (Serving and Neighboring Cell 3G) = - 16 dB
� qRxLevMin (Serving and Neighboring Cell 3G) = - 115 dBm
� qRxLevMin (Neighboring Cell 2G) = - 104 dBm
� sibMaxAllowedUlTxPowerOnRach = 24 dBm
� maxAllowedUlTxPower (Neighboring Cell 3G) = 24 dBm
� maxAllowedUlTxPower (Neighboring Cell 2G) = 33 dBm• sIntraSearch = 8dB• sInterSearch = 6dB• sSearchRatGSM = 4dB
• sSearchHcs = 0dB• sHcsRatGsm = 0dB
• isHcsUsed = False
� Question: which is the cell reselected by the UE ?
Section 8 � Module 1 � Page 26
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 26
5 Cell Reselection in Idle Mode with HCS
Section 8 � Module 1 � Page 27
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 27
5 Cell Reselection in Idle Mode with HCS
5.1 Principles
hcsPrio (HcsCellParam)
hcsPrio (UmtsNeighbouringHcsCellParam)
hcsPrio (GsmHcsCellParam)
� Each cell is assigned an HCS Priority value between 0 and 7
0 = lowest priority
7 = highest priority
P1
P3
HM not detected Higher priority is favored
HM detected Lower priority is favored
P2 P2
P3 P3 P3
Co
py
righ
t ©
19
96
Nor
ther
n T
elec
om
HCS priorities are broadcasted in SIB3 for the serving cell and SIB11 for the neighboring cells.
3GPP assumes that a cell with hcsPriority=7 has higher priority than another cell with hcsPriority=0.
Actually, one shall consider HCS priority in conjunction with HMD and opertor’s strategy, as depicted in
� When high-mobility state is detected, UE will try to reselect a cell with lower HCS priority
� When high-mobility state is NOT detected, UE will try to reselect a cell with higher HCS priority
HCS rules regarding priorities and HMD are presented in the following pages.
Section 8 � Module 1 � Page 28
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 28
5 Cell Reselection in Idle Mode with HCS
5.2 Measurements Rules with HCS in Low Mobility
isHcsUsed (FDDCell) = True� UE not in High Mobility state
Intra-frequency Inter-frequency
hcsPrion >= hcsPrios
Intra-frequency Inter-frequency
hcsPrion > hcsPrios
All Intra-frequency All Inter-frequency
GSM
hcsPrion >= hcsPrios
No measurement
All GSM
Srxlev
sInterSearch sIntraSearch Squal
sSearchHcs
Srxlev
Squal
sHcsRatGsm
sSearchRatGsm sLimitSearchRat
sLimitSearchRat
(HcsCellParam)
With isHcsUsed set to True:
� “Use of HCS” IE broadcasted in SIB11 is set to “Used”
When HCS is used, measurement rules are based on the same thresholds as when HCS is not used
(sIntraSearch, sInterSearch, sSearchRatGsm, sSearchHcs and sHcsRatGsm) plus a new parameter sLimitSearchRat wich is broadcasted in SIB3.
When using HCS, the difference in the neighboring measurement rules relies on the filtering of the
measured cells based on high-mobility state detection.
When the UE is not in High Mobility state, measurements are triggered on higher priority neighboring cells.
Section 8 � Module 1 � Page 29
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 29
5 Cell Reselection in Idle Mode with HCS
5.3 HCS Quality Level Threshold Criterion
Qmeasn qHcsnHn = –
qHcss
NeighbouringCellhcsPriorityn = hcsPrioritys
NeighbouringCellhcsPriorityn <> hcsPrioritys
Qmeasn qHcsnQmeassHs = –
H criterion for Serving CellH criterion for FDD or GSM Neighboring Cellof same HCS priority as Serving cell
Hn = –
FDDCellhcsPrioritys
H criterion for FDD or GSM Neighboring Cellof different HCS priority than Serving cell
qHcs (HcsCellParam)
qHcs (UmtsNeighbouringHcsCellParam)
qHcs (GsmHcsCellParam)
HCS introduces a new criterion, so-called Quality Level Threshold H criterion, which is used to determine
whether prioritized ranking according to hierarchical cell reselection shall apply.
Qmeass and Qmeasn = CPICH_Ec/N0 or CPICH_RSCP for serving cell and FDD neighboring cells based on
qualMeas parameter.
Qmeasn = BCCH_RSSI (or BCCH RxLev) for GSM neighboring cells.
Note: According to 3GPP 25.304 the real formula of Hn for a neighbouring cell of hcspriority different than hcsPriority of the serving cell is Hn = Qmeasn – qHcsn – temporaryOffsetn * W(t) but Alcatel-Lucent recommends not to use temporaryOffsets parameters so temporaryOffsetn is always set to 0.
Section 8 � Module 1 � Page 30
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 30
5 Cell Reselection in Idle Mode with HCS
5.4 Measurements Rules with HCS in High Mobility
� UE in High Mobility state
Intra-frequency Inter-frequency
hcsPrion <= hcsPrios
All Intra-frequency All Inter-frequency
GSM
hcsPrion <= hcsPrios
All GSM
Srxlev
sInterSearch sIntraSearch Squal
Srxlev
Squal sSearchRatGsm sLimitSearchRat
sSearchHcs
sHcsRatGsm
When the UE is in High Mobility state, measurements are triggered on lower priority neighboring cells.
Section 8 � Module 1 � Page 31
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 31
5 Cell Reselection in Idle Mode with HCS
5.5 Level and Quality Ranking Criteria with HCS
qHysts
NeighbouringCellhcsPriorityn = hcsPrioritys
NeighbouringCellhcsPriorityn <> hcsPrioritys
QmeassRs = +
R criterion for Serving Cell
R criterion for FDD or GSM Neighboring Cellof same HCS priority as Serving cell
FDDCellhcsPrioritys
Qmeasn qOffsetsns,nRn = –
R criterion for FDD or GSM Neighboring Cellof different HCS priority than Serving cell
Qmeasn qOffsetsns,nRn = –
Like when HCS is not used, both Level and Quality Ranking criteria can be used depending on the setting of
qualMeas parameter.
Note: According to 3GPP 25.304 the real formula of Rn for a neighbouring cell of hcspriority equal to hcsPriority of the serving cell is Rn = Qmeasn – qOffsetsnsn – temporaryOffsetn * W(t) but Alcatel-Lucent recommends not to use temporaryOffsets parameters so temporaryOffsetn is always set to 0.
Section 8 � Module 1 � Page 32
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 32
5 Cell Reselection in Idle Mode with HCS
5.6 HCS Cell Filtering in Low Mobility
UE is in High Mobility
state ?
Eligible Cellsaccording to S criteria
Candidate Cells Ranking
R criteria
yes
At least one cell has
H criterion >=0 ?
no
Keep all neighboring FDD and GSM cells
of the highest hcsPriorityas candidates
among those having H criterion >=0
yes
Keep all neighboring
FDD and GSM cells
as candidates without ordering them
no
See next page
Once H criterion has been computed for the serving cell and each neighboring cell, UE performs ranking of
all cells that fulfill the S criterion among:
When high-mobility state has NOT been detected (the higher priority, the
smaller size),
� All measured cells, that have the highest hcsPrio among the cells that fulfill H>=0
� All measured cells, not considering hcsPrio levels, if no cell fulfills H>=0
When high-mobility state has been detected (the lower priority, the bigger size),
� All measured cells with the highest hcsPrio that fulfil H>=0 and have a lower hcsPrio than serving cell
else:
� All measured cells with the lowest hcsPrio that fulfil H>=0 and have a higher or equal hcsPrio than serving cell
else:
� All measured cells without considering hcsPrio
Section 8 � Module 1 � Page 33
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 33
5 Cell Reselection in Idle Mode with HCS
5.7 HCS Cell Filtering in High Mobility
Keep all neighboring FDD and GSM cells of the highest hcsPriority as candidates
among those having1. hcsPriorityn < hcsPrioritys
2. H criterion >=0
Candidate Cells Ranking
R criteria
UE in High Mobility
Keep all neighboring FDD and GSM cells of the lowest hcsPriority as candidates
among those having 1. hcsPriorityn >= hcsPrioritys
2. H criterion >=0
not empty list
Keep all neighboring FDD and GSM cells
as candidates without ordering them
empty list
not empty list
empty list
Once H criterion has been computed for the serving cell and each neighboring cell, UE performs ranking of
all cells that fulfill the S criterion among:
When high-mobility state has NOT been detected (the higher priority, the
smaller size),
� All measured cells, that have the highest hcsPrio among the cells that fulfill H>=0
� All measured cells, not considering hcsPrio levels, if no cell fulfills H>=0
When high-mobility state has been detected (the lower priority, the bigger size),
� All measured cells with the highest hcsPrio that fulfil H>=0 and have a lower hcsPrio than serving cell
else:
� All measured cells with the lowest hcsPrio that fulfil H>=0 and have a higher or equal hcsPrio than serving cell
else:
� All measured cells without considering hcsPrio
Section 8 � Module 1 � Page 34
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 34
5 Cell Reselection in Idle Mode with HCS
5.8 Cell Ranking Algorithm
FDDCell
CPICH_Ec/No CPICH_RSCP
Best cell is a ..?
Best GSMCellis reselected
GSMCell
Best FDDCell
after First Rankingis reselected
Best FDDCell
after Second Rankingis reselected
qualMeas = ..?
First Ranking RL
(CPICH_RSCP & RxLev)
Second Ranking RQ
(CPICH_Ec/No)
Candidate NeighboringFDD and GSM cells for
Cell Reselection
Same Ranking as without HCS
Let’s recall that the cell reselection process is as follows:
� If a GSM cell is ranked as the best cell, then the UE shall perform cell reselection to that GSM cell.
� If an FDD cell is ranked as the best cell and the quality measure parameter qualMeas for cell re-selection is set to qualMeasRscp, then UE shall perform cell re-selection to that FDD cell.
� If an FDD cell is ranked as the best cell and the quality measure parameter qualMeas for cell re-selection is set to qualMeasEcno, then UE shall perform a second ranking.
Section 8 � Module 1 � Page 35
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 35
5 Cell Reselection in Idle Mode with HCS
5.9 Triggering Algorithm
UMTSFddNeighbouringCellInter-freq
UMTSFddNeighbouringCellIntra-freq
GSMNeighbouringCell
ServingFDDCell
tReselection (UE not in High Mobility)tReselection x speedDependScalingFactorTReselection (UE in High Mobility)
tReselectionx interRatScalingFactorTReselection(UE not in High Mobility)
tReselectionx speedDependScalingFactorTReselectionx interRatScalingFactorTReselection(UE in High Mobility)
tReselection x interFreqScalingFactorTReselection (UE not in High Mobility)tReselection x speedDependScalingFactorTReselection x interFreqScalingFactorTReselection (UE in High Mobility)
Same triggering as without HCS
speedDependScalingFactorTReselection
(CrMgt)
tReselectioninterFreqScalingFactorTReselectioninterRatScalingFactorTReselection
(CellSelectionInfo)
Several scaling factors, introduced by 3GPP R5, can be applied to tReselection:
� speedDependScalingFactorTReselection (used with or without HCS usage), between 0 and 1, in order to speed up the reselection when High-Mobility state is detected.
� interFreqScalingFactorTReselection between 1 and 4.75, in order to delay the reselection to Inter-frequency neighboring cell.
� interRatScalingFactorTReselection between 1 and 4.75, in order to delay the reselection to GSM neighboring cell.
Note: All the parameters related to cell selection/reselection are broadcasted on the BCCH using either:
� SIB3 for cell reselection parameters related to the serving cell
� SIB11 for cell reselection parameters related to the neighboring cells.
Section 8 � Module 1 � Page 36
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 36
5 Cell Reselection in Idle Mode with HCS
5.10 Exercise: Multi-Layer Cell Structure, HCS used
Neighb.MC
Neighb.MA Neighb.MB
Serv.mc
Macro FDDcells F2
Micro FDDcells F1
Neighb.GC
Neighb.GA Neighb.GB
Macro GSMcells
Neighbo.mbNeighbo.ma
0
0
0
0
0
qOffset2sn(dB)
0
0
0
1
1
1
2
2
2
hcsPriority
-1000-73Neighboring cell GC
-1000-80Neighboring cell GB
-1000-98Neighboring cell GA
-140-85-4Neighboring cell MC
-140-89-5Neighboring cell MB
-140-99-9Neighboring cell MA
-100-104-10Neighboring cell mb
-100-118-21Neighboring cell ma
-1044-108-12Serving cell mc
qHcs(dB)
qHyst2(dB)
qOffset1sn(dB)
qHyst1(dB)
CPICH_RSCP / GSM RSSI (dBm)
CPICH_Ec/No (dB)
Cell
hcsPriority = 0
hcsPriority = 1
hcsPriority = 2
The Cell Reselection Control feature enables a more flexible cell reselection control from the network in a
Hierarchical Cell Structure (HCS).
HCS layers management offers several solutions to manage the traffic demand and its associated noise rise.
For example, traffic may be split between the two or three layers in order to minimize the global noise
rise, or it may be split depending on the type of service used.
The later solution is conceivable if the microcell layer deployment aims at offering higher rate services
continuously within an area.
As a matter of fact, high data rate services require smaller cell sizes than low data rate services and
therefore may be continuously offered within an area only by the use of microcell sites (as illustrated on
the above slide).
Moreover, since a microcell layers offer better indoor coverage quality than macro layers, this is well suited
to high data rate services, which are more likely to be indoor applications.
Section 8 � Module 1 � Page 37
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 37
5 Cell Reselection in Idle Mode with HCS
5.10 Exercise: Multi-Layer Cell Structure, HCS used [cont.]
� Assumptions� UE class 3
� qualMeas = qualMeasEcno
� qQualmin (Serving and Neighboring Cell 3G) = - 16 dB
� qRxLevMin (Serving and Neighboring Cell 3G) = - 115 dBm
� qRxLevMin (Neighboring Cell 2G) = - 104 dBm
� sibMaxAllowedUlTxPowerOnRach = 24 dBm
� maxAllowedUlTxPower (Neighboring Cell 3G) = 24 dBm
� maxAllowedUlTxPower (Neighboring Cell 2G) = 33 dBm• sIntraSearch = 8dB• sInterSearch = 6dB• sSearchRatGSM = 4dB
• sSearchHcs = 0dB• sHcsRatGsm = 0dB
� isHcsUsed = True• sLimitSearchRat = 4dB• temporaryOffest = parameters not used
� Question 1: which is the cell reselected by the UE if in High Mobility ?
� Question 2: which is the cell reselected by the UE if in Low Mobility ?
Section 8 � Module 1 � Page 38
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 38
6 Cell reselection in non-DCH Connected Mode
Section 8 � Module 1 � Page 39
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 39
6 Cell reselection in non-DCH Connected Mode
6.1 SIB 4 and SIB 12 Broadcast
SIB 4: Se
rving Ce
ll
re-selection p
arame
ters b
roadcast
isDynamicSibAlgoWithSbAllowed(RadioAccessService)
SIB11+
DCHDCH
SIB11+
DCH
DCH
DCH
DCH
SIB11+
DCH SIB11+
DCH
SIB11+
DCH
DCH
DCH
DCH
SIB11+
DCHDCH
SIB11+
DCH
SIB11+
DCH
SIB11+
DCHDCH
DCH
DCHDCH
DCH
SIB11+
DCH
ServingFDDCell
DCH
SIB11+
DCH
DCH
DCH
SIB11+
DCHDCH
DCH
Cell_FACHCell_PCHURA_PCH
SIB 12
: Neig
hboring
Cells
re-se
lection p
aram
eters broadcast
sib4Enable (FDDCell)sib12Enable (FDDCell)
Prior to UA06.0, Cell Selection and Reselection information was only broadcast to UE in SIB3/SIB11
whatever mode (Idle, URA_PCH, Cell_PCH and Cell_FACH), SIB3 (resp. SIB11) containing serving cell’s
information (resp. neighbouring cell’s)
UA06.0 introduces the support of SIB4/SIB12 in order to have different Cell Selection and Reselection
setting between Idle mode and connected modes (Cell_PCH, URA_PCH and Cell_FACH).
Enabling SIB4 and SIB12 has a direct impact on the System Information size since many information
(especially neighbouring cell’s) are duplicated.
When all scheduling information can not be coded in one MIB segment, SB1 Scheduling Block (SB) is used to
support the exceeding segments, as defined per 3GPP. isDynamicSibAlgoWithSbAllowed allows the use of such SB1.
Section 8 � Module 1 � Page 40
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 40
6 Cell reselection in non-DCH Connected Mode
6.2 SIB3 & SIB11 Parameters & Objects
UmtsNeighbouring
UmtsNeighbouringRelation
RNC
NodeB
FddCell
CrMgt
HcsCellParam
UmtsFddNeighbouringCell
UmtsNeighbouringHcsCellParam
CellSelectionInfo
tReselectionqualMeas
qHyst1qHyst2
qQualMinqRxLevMin
sIntraSearchsInterSearch
sSearchRatGsm
qOffset1snqOffset2snqQualMin
qRxLevMinneighbouringCellOffset
hcsPrio
qHcs
hcsPrio
qHcs
sLimitSearchRat
Cell Selection Info (SIB 3 / 4 Mapping):
CellAccessRestrictionConnectedModeCellAccessRestriction
CellSelectionInfoConnectedMode.CellSelectReselectInfoPchFachNo Equivalent
CellSelectionInfoConnectedMode.HcsCellParamCellSelectionInfo.HcsCellParam
CellSelectionInfoConnectedMode.CrMgtCellSelectionInfo.CrMgt
CellSelectionInfoConnectedMode.FachMeasOccasionCellSelectionInfo.FachMeasOccasion
CellSelectionInfoConnectedMode�CellSelectionInfo
Connected mode
Idle Mode
Root = FddCell
Section 8 � Module 1 � Page 41
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 41
6 Cell reselection in non-DCH Connected Mode
6.3 SIB4 Parameters & Objects
NodeB
FddCell
CrMgt
HcsCellParam
cellSelectReselectInfoPchFach
cellAccessRestrictionConnectedMode
R’99/R4 UEs
R5/R6 UEs
CellSelectionInfoConnectedMode
tReselectionqualMeas
qHyst1qHyst2
qQualMinqRxLevMin
sIntraSearchsInterSearch
sSearchRatGsm
tReselectionqHyst1qHyst2
hcsPrio
qHcs
sLimitSearchRat
tReselectionPchtReselectionFach
qHyst1PchqHyst1FachqHyst2PchqHyst2Fach
Attributes for SIB4Attributes for SIB4
qHyst1Pch
qHyst1Fach
CellSelectReselectInfoPchFach
qHyst2Fach
qHyst2Pch
tReselectionFach
tReselectionPch
CellSelectionInfoConnectedMode
tReselection
sSearchRatGsm
sSearchHcs
sIntraSearch
sInterSearch
sHcsRatGsm
qualMeas
qRxLevMin
qQualMin
qHyst2
qHyst1
interRatScalingFactorTReselection
interFreqScalingFactorTReselection
CellAccessRestrictionConnectedMode
tBarred
intraFreqCellReselectInd
cellReservedForOperatorUse
cellReservationExtension
barredOrNot
accessClassPsBarred
accessClassCsBarred
accessClassBarred
CrMgt
tCrMaxHyst
tCrMax
speedDependScalingFactorTResele
ction
nCr
FachMeasOccasion
ratTypeList
fachMeasOccasionCoef
HCSCellParams
sLimitSearchRat
qHcs
hcsPrio
Section 8 � Module 1 � Page 42
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 42
6 Cell reselection in non-DCH Connected Mode
6.4 SIB12 Parameters & Objects – UMTS FDD Neighbour
FddNeighCellSelectionInfoConnectedMode
UmtsNeighbouringRelation
UmtsNeighbouring
RNC
NodeB
Fddcell
UmtsFddNeighbouringCell
UmtsNeighbouringHcsCellParam
qOffset1snqOffset2snqQualMin
qRxLevMincellIndivOffset
hcsPrio
qHcs
Neighbouring Info (SIB 11 / 12 Mapping):
Attributes for SIB12:
UMTSNeighbouringRelation.FddNeighCellSelectionI
nfoConnectedMode.UmtsNeighbouringHcsTempora
ryOffset
UMTSNeighbouringRelation.
UmtsNeighbouringHcsTemporaryOffset
UMTSNeighbouringRelation.FddNeighCellSelectionI
nfoConnectedMode.UmtsNeighbouringHcsCellPara
m
UMTSNeighbouringRelation.
UmtsNeighbouringHcsCellParam
UMTSNeighbouringRelation.FddNeighCellSelectionI
nfoConnectedMode
�
UMTSNeighbouringRelation
Connected modeIdle Mode (Root = UMTSNeighbouringRelation)
UMTSNeighbouringRelation
qRxLevMin
qQualMin
qOffsetMbms
qOffset2sn
qOffset1sn
neighbouringCellOffset
maxAllowedUlTxPower
FddNeighCellSelectionInfoConnectedMode
qRxLevMin
qQualMin
qOffset2sn
qOffset1sn
maxAllowedUlTxPower
cellIndivOffset
Section 8 � Module 1 � Page 43
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 43
6 Cell reselection in non-DCH Connected Mode
6.5 SIB11 & SIB12 Parameters & Objects – GSM Neighbour
GsmCellSelectionInfoConnMode
GSMCell
GSMNeighbour
RNC
NodeB
Fddcell
GsmNeighbouringCell
GsmgHcsCellParam hcsPrio
qHcs
qRxlevMin
qOffset1sn
gsmCellindivOffset
qRxlevMin
qOffset1sn
gsmCellindivOffset
UMTSNeighbouringRelation
qRxLevMin
qQualMin
qOffsetMbms
qOffset2sn
qOffset1sn
neighbouringCellOffset
maxAllowedUlTxPower
FddNeighCellSelectionInfoConnectedMode
qRxLevMin
qQualMin
qOffset2sn
qOffset1sn
maxAllowedUlTxPower
cellIndivOffset
Section 8 � Module 1 � Page 44
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 44
6 Cell reselection in non-DCH Connected Mode
6.6 Exercises
� By Respecting the following strategy fill in tables in next pages with the
appropriate values for the Mono, Bi and Tri Layer Topologies:
� Assuming qQualMin = -16 dB And event2D for 3G-2G HHO = -14 dB
�When UE is in Idle mode, we want it to select the most suitable cell:
� Small hysteresis between cells
� Fast reactivity
�When UE is in Cell_FACH or Cell_PCH state, we prefer it to stay on its current
layer (in accordance to InterFreq or InterRAT HHO setting), even if increasing
the risk of call drop:
� Larger hysteresis to prevent Ping-Pong in cell reselection (intra frequency)
� Lower threshold to delay the triggering inter freq or inter system measurements
Section 8 � Module 1 � Page 45
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 45
6.6 Exercises
6.6.1 Exercise1: Mono-Layer Topology
� Neighbouring Definition:
3G
2G
3G 3G
sSearchRatGsmNo 2G reselection until criteria
for HHO is reached
Objective
2dB
Connected ModeIdle Mode
Only Sib4 is used
qHyst2Prevent ping pong between cells on connected mode
Objective
2 dB
Connected ModeIdle Mode
Objective is to prevent UE to go in 2G while staying in FACH-PCH State:
Subsidiary Question:
Propose a solution to deactivate the inter-RAT mobility?
Section 8 � Module 1 � Page 46
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 46
6.6 Exercises
6.6.2 Exercise2: Bi-Layer Topology
3G (R99)
2G
3G (HSxPA)
3G (R99)
3G (HSxPA)
3G (R99)
3G (HSxPA)Only Sib4 is used
Same setting for SIB4 on both 3G layer
Objectives are to delay the inter-freq mobility and to prevent the UE to go on 2G while in FACH-PCH State
Give two values for SInterSearch when InterFreq or inter-Rat is preferred in the iMCTAsetting
No 2G reselection, first fallback to interfreq reselection
2 dBsSearchRatGsm
sInterSearch
qHyst2
Will depends on iMCTA Alarm priority setting
Prevent ping pong between cells on connected mode
Objective
6 dB
2 dBConnected ModeIdle Mode
Section 8 � Module 1 � Page 47
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 47
6.6 Exercises
6.6.2 Exercise2: Bi-Layer Topology [cont.]
No 2G reselection, first fallback to interfreq reselection
2 dBsSearchRatGsm
sInterSearch
qHyst2
F1 F2 reselection allowed for load sharing
Prevent ping pong between cells on connected mode
Objective
6 dB
2 dB
Connected ModeIdle Mode
• F1 & F2 settings
3G (HSDPA)
2G
3G (HSxPA)
3G (HSDPA)
3G (HSxPA)
3G (HSDPA)
3G (HSxPA)
Only Sib4 is used
Objectives are to delay the inter-freq mobility and to prevent the UE to go on 2G while in FACH-PCH State
Section 8 � Module 1 � Page 48
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 48
6.6 Exercises
6.6.3 Exercise3: Tri-Layer Topology
3G (R99)
2G
3G (HSxPA)
3G (R99)
3G (HSxPA)
3G (R99)
3G (R99)
3G (HSxPA)
3G (R99)
3G (R99)
3G (HSxPA)
Because of load sharing between F1 & F3 (R99 cells), the strategy is to allow the UE to select the best cell (intra + inter-frequency F1+F3) in idle mode.
For connected mode (PCH / FACH), the strategy consists in keeping the UE on its current layer, except for R99: with load sharing purpose, it is accepted that the UE goes from F1 to F3 (and F3 to F1), but not on F2
F1
F2
F3
Section 8 � Module 1 � Page 49
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 49
6.6 Exercises
6.6.3 Exercise3: Tri-Layer Topology [cont.]
No 2G reselection, first fallback to interfreq reselection
2 dBsSearchRatGsm
sInterSearch
qHyst2
F1 F3 reselection allowed for load sharing
Prevent ping pong between cells on connected mode
Objective
6 dB
2 dB
Connected ModeIdle Mode
• F1 & F3 settings
No 2G reselection, first fallback to inter-freq reselection
2 dBsSearchRatGsm
sInterSearch
qHyst2
To delay the inter-freq mobility
Prevent ping pong between cells on connected mode
Objective
6 dB
2 dBConnected ModeIdle Mode
•F2 settings
Section 8 � Module 1 � Page 50
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 50
6.6 Exercises
6.6.3 Exercise3: Tri-Layer Topology [cont.]
� Purpose of SIB 12 is to disadvantage F2 compared to F1 & F3 for Cell reselection
� For which frequency (or frequencies) SIB12 will should be activated?
Disadvantage F2 compared to F1 & F3
0 dBqOffset2sn
F2
qOffset2sn
F1 & F3
Objective
0 dB
Connected ModeIdle Mode
Section 8 � Module 1 � Page 51
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 51
7 Cell Status and Reservation
Section 8 � Module 1 � Page 52
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 52
7 Cell Status and Reservation
7.1 Cell Status and Reservation Process
barred
notReservedallowed notAllowed
only UE withAccess Classes 11 / 15
are accepted
reserved
try to selecta cell of anotherfrequency
if no other cell
all UE Access Classesare accepted
notReservedreserved
other UE
barredOrNot (FDDCell) = ..?
intraFreqCellReselectInd (FDDCell) = ..? cellReservedForOperatorUse (FDDCell) = ..?
cellReservationExtension (FDDCell) = ..?
try to reselectsame cell
wait tBarred (FDDCell)
notBarred
try to selectanother cell of the samefrequency
All UEs are members of one out of ten randomly allocated mobile populations defined as Access Classes 0 to
9. The population number is stored in the SIM. In addition mobiles may be members of one or more out of 5
special categories (Access Classes 11 to 15) also held in the SIM and allocated to specific high priority users
as follows (enumeration is not meant as a priority sequence):
� Class 15 - PLMN Staff (VIP)
� Class 14 - Emergency Services
� Class 13 - Public Utilities (for example, water/gas suppliers)
� Class 12 - Security Services
� Class 11 - For Operator Use
An additional control bit known as "Access Class 10" is also signaled over the air interface to the UE. This
indicates whether or not network access for Emergency Calls is allowed for UEs with access classes 0 to 9 or
without an IMSI.
Cell status and cell reservations are indicated with the Cell Access Restriction Information Element in the
System Information Message (SIB3) by means of four Information Elements:
� Cell barred (IE type: "barred" or "not barred")
� Cell Reserved for operator use (IE type: "reserved" or "not reserved")
� Cell reserved for future extension (IE type: "reserved" or "not reserved")
� Intra-frequency cell re-selection indicator (IE type: "allowed" or "not allowed")
The last element (Intra-frequency cell re-selection indicator) is conditioned by the value ”barred“ of the
first element (Cell barred)
Section 8 � Module 1 � Page 53
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 53
8 Location Registration
Section 8 � Module 1 � Page 54
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 54
8 Location Registration
8.1 LAC/RAC/SAC
LAC 2
RAC 1
RAC 2
SAC 1
SAC 2
LAC 1
RNClocationAreaCode (FDDCell)
routingAreaCode (FDDCell)
serviceAreaCode (FDDCell)
Core Network Domains
Sac (FDDCell/CBSResource)
Broadcast Domain
locUpdatePeriod (RadioAccessService)
Location Area (LA)
The location area is used by the Core Network CS domain to determine the UE location in idle mode. A location area contains a group of cells. Each cell belongs only to one LA.
The location area is identified in the PLMN by the Location Area Code (LAC), which corresponds to the locationAreaCode parameter of the FDDCell object.
The Location Area Identifier (LAI) = PLMN-id + LAC = MCC + MNC + LAC
Routing Area (RA)
The routing area is used by the PS Core Network to determine the UE location in idle mode. A routing area contains a group of cells. Each cell belongs only to one RA.
The routing area is identified by the Routing Area Code (RAC) within the LA. The RAC corresponds to the routingAreaCode parameter of the FDDCell object.
A Routing Area Identifier (RAI) = LAI + RAC = MCC + MNC + LAC + RAC
Core Network Service Area (CN SA)
The CN SA is used by the Core Network to determine the UE location in connected mode. A service area contains a group of cells. Each cell belongs only to one CN SA.
The service area is identified by the Service Area Code (SAC) within the LA. The SAC corresponds to the serviceAreaCode parameter of the FDDCell object.
The Service Area Identifier (SAI) = LAI + SAC = MCC + MNC + LAC + SAC.
Broadcast Service Area (BC SA)
The BC SA is used by the Broadcast Center to schedule messages to be broadcast to UEs in the network.
The broadcast (BC) domain requires that BC SA consist of one cell.
locUpdatePeriod is Alcatel-Lucent name for 3GPP T3212 parameter.
It is also possible to configure a periodic Routing Area Update. This is possible through the 3GPP parameter T3312. This parameter can be modified at SGSN Level.
Section 8 � Module 1 � Page 55
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 55
Module Summary
� This lesson covered the following topics:
� PLMN selection and associated parameters
� Cell selection and associated parameters
� Cell reselection and associated parameters
Section 8 � Module 1 � Page 56
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 56
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 8 � Module 1 � Page 57
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in Reselection �
8 � 1 � 57
End of Module
Section 9 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
9�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 9Mobility in SHO
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 9 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 2
Blank Page
This page is left blank intentionally
Max. number of neighbors updated (UA7)Improvements on RAN model extracts for cell reselection in non-DCH connected mode
Chatila, RayanRyser, SigridCharneau, Jean-Noel
2010-04-1501
RemarksAuthorDateEdition
Document History
Section 9 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Describe Soft Handover types and purpose
� Describe Soft Handovers and associated parameters
� Describe Intra-Freq Hard Handovers and associated parameters
Section 9 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 9 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 5
Table of Contents
Switch to notes view!Page
1 SHO Mobility Requirements 71.1 Soft Handover Types 81.2 Periodic vs. Full Event Triggered Reporting 91.3 Periodical Reports Processing 101.4 Intra-Freq CNL Management 111.4.1 CNL Computation Type2 121.4.2 CNL Computation Type1 131.4.3 CNL Computation - RAN Model 14
1.5 Exercise 152 Active Set Management (Soft HO) 162.1 Absolute and Relative Criteria for SHO 172.2 Drop Criteria (Periodical Mode) 182.3 Add Criteria (Periodical Mode) 192.4 Event 1A 202.5 Detected Set Cells Addition to Active Set 212.6 Event 1B 222.7 Event 1C 232.8 Event 1E 252.9 Event 1F 262.10 SHO Blocking Phase 272.10.1 Events Storage 28
3 Primary Cell Change 293.1 Primary Cell Election: Periodical Mode 303.2 Primary Cell Change: Event 1D 313.3 Service Based Intra-Freq Mobility : RAN Model 32
4 Intra-Freq Hard HO 334.1 Intra-Freq Inter-RNC Mobility w/o Iur : HHO Activation 344.2 RRC Measurement Control Configuration 354.3 HHO Detection after MeasId1: Iur link is down 364.4 HHO Detection after MeasId16: Iur link is not provisioned 374.5 RAN Model 38
5 SRNS Relocation (UE not Involved) 395.1 Principle 405.2 Example: Call Flow PS 415.3 Parameters 42
Section 9 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 6
Table of Contents [cont.]
Switch to notes view!
This page is left blank intentionally
Section 9 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 7
1 SHO Mobility Requirements
Section 9 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 8
1 SHO Mobility Requirements
1.1 Soft Handover Types
FDDcell FDDcell FDDcell
Inter-RNC SHO
Core Network
Node B Node B
RNC RNC
FDDcell FDDcell FDDcell
Node B
Intra-RNC SHOIntra-NodeB SHO
(Softer)
Soft Handover (SHO) applies only to dedicated physical channels and refers to the case where more than
one cell has a link established with a UE. In this mode the UE is connected to a set of cells known as the
Active Set, where it benefits from macro diversity.
Softer Handover is a special case of SHO where the cells communicating with the UE belong to the same
Node B, thus it can only be performed intra-RNC. The particularity of the softer handover comes from the
fact that the radio links coming from different cells of the Node B are combined together at the Node B
level before being sent back to the RNC.
In the Intra-RNC SHO case, the cells involved in the soft handover procedure belong to different Node Bs
that are connected to the same Serving RNC (that is, the RNC in charge of the RRC connection with the
mobile). Radio Link recombination is performed at the S-RNC level.
In the Inter-RNC SHO case, the cells of the active set are not all controlled by the S-RNC. This is where the
notion of Drift and Serving RNC comes into play:
� S-RNC is in charge of the RRC connection with the mobile.
� D-RNC controls the Node B that does not belong to the S-RNC and for which a radio link needs to be
established with the mobile.
� An Iur link between S-RNC and D-RNC is required to perform inter-RNC SHO.
� From S-RNC and UTRAN transport perspective D-RNC acts as a router.
� From UE and Core Network perspectives, the presence of D-RNC is transparent, that is, soft handover
occurs as usual.
Section 9 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 9
1 SHO Mobility Requirements
1.2 Periodic vs. Full Event Triggered Reporting
isEventTriggeredMeasAllowed(FDDCell)
RRC Measurement Control
(Intra-frequency, Periodical Reporting)RNC
FALSE
RNC
RRC Measurement Control
(Ec/No, 1A, 1B, 1C, 1D, 1E, 1F)
RRC Measurement Control
(Ec/No, 2D, 2F)
RRC Measurement Control
(RSCP, 2D, 2F)TRUE
Measurement Control
(UETxPower 6A,6B)
Starting UA4.2, the mobility of a given UE is managed either in Periodical Mode or Full Event Triggered
Mode.
The choice between these two modes is done by RNC when the UE establishes a communication in
CELL_DCH state and is kept unchanged as long as the UE remains in CELL_DCH state. There is no switch
between Periodical Mode and Full Event Mode in CELL_DCH state, even when the Primary Radio Link is
changed.
In the event-triggered reporting mode, the type of the triggered event becomes the main indication to
compute the Mobility decisions. The semantic of the received event indicates which decision has to be
taken. In this mode, the RNC provides to the UE, in the RRC Measurement Control, the means to compute
the criteria to manage the Mobility. The RNC has to perform the related action indicated by the received
event.
The parameter isEventTriggeredMeasAllowed controls the activation of the Full Event Triggered feature on
a per cell basis. The reporting mode for the call is the one configured on the cell where the call is
established, and is not changed during the call duration (on CELL_DCH).
Warning: Not ALL UE support E6A and E6B: MeasControl Failure cause: „unsupported measurement“ shall besent by the UE but the call is kept
Section 9 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 10
1 SHO Mobility Requirements
1.3 Periodical Reports Processing
Active Set cells+
6 Best Monitored Set cells+
3 Best Detected Cells
RRC Measurement Report
RRC Measurement ReportRNC
- 1 - Alarm Hard Handover criteria evaluation (Primary Cell)• Inter-Frequency Hard Handover (3G to 3G)• Inter-System Hard Handover (3g to 2G)
- 2 - Active Set update
- 3 - Primary Cell election
The above slide indicates in which order the various procedures are performed in the RNC when receiving a
RRC Measurement Report message from the mobile.
In this release, Alarm Hard Handover refers to the following mobility cases:
� 3G to 2G handover for CS
� 3G to 2G handover for PS
� 3G to 2G handover for CS+PS
� 3G to 3G inter-frequency inter-RNC handover
� 3G to 3G inter-frequency intra-RNC handover
Section 9 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 11
1 SHO Mobility Requirements
1.4 Intra-Freq CNL Management
A1NA2
NA1
A3NA2
A2NA1NA3
NA1NA2
NA1
NA2NA3
NA1NA3
NA3
NA2NA3
NA2
NA3
Primary Cell Monitored SetMonitored Set
Prl Type1 or Type2
isCompoundingCellListActivated (RadioAccessService)
typeOfCompoundingNeighbourListIntraFreq
(FDDCell and NeighbouringRNC)
Two different CNL alogrithms are now supported in UA06.0 that can be enabled/disabled using
typeOfCompoundingNeighbourListIntraFreq parameter
newly introduced and defined under NeighbouringRnc and FDDCell objects:
� Prl stands for primary radio link and aims at disabling CNL at FDD cell level; the neighbouring list onlyconsists in the primary cell’s neighbourhood.
� Type2 is the initial CNL algorithm introduced in UA4.1; the neighbouring list classicaly consists in
concatenating Primary cell’s neighbourhood then the
best second leg’s … until maxCompoundingListSizeIntraFreq is reached.
� Type1 is the newly introduced algorithm which aims at building intrafrequency neighbouring list based
on priorities and occurrence.
Section 9 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 12
1.4 Intra-Freq CNL Management
1.4.1 CNL Computation Type2
Entire Active Set Cells+
Primary Cell static neighboring for DCH mode+
AS first best leg static neighboring for DCH mode+
AS second best leg static neighboring for DCH mode+...
SHO Neighboring List
Primary Cell static neighboring for DCH mode+
first best monitored cell and its static neighboring for DCH mode+
second best monitored cell and its static neighboring for DCH mode+...
non-SHO Neighboring List
Primary Cell Change
OR
Active Set Modification
OR
SHO to non-SHO Transition
OR
Dedicated Connection Initiation
isCompoundingCellListActivated
(RadioAccessService)= Type2
Basing the monitored set on the compound neighbor list rather than on the primary cell neighbors increases
the number of cells in the monitored set, thus it is important to have way to limit the size of the neighbor
list, and ensure that the monitored set comprises the best cells.
To achieve this, the algorithm consists in scanning the cells from the active set in decreasing order of CPICH
Ec/N0 and adding their neighbors to the monitored set, until the number of cells in the list reaches the
maximum size allowed.
A cell is not added in the compounding list if it is already included in this list, so as not to have several
instance of the same cell in the list.
If maxNbOfMonitoredCellForNonShoCompoundList is set to zero, the compound list is only composed of the
primary cell and its neighborhood.
Section 9 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 13
1.4 Intra-Freq CNL Management
1.4.2 CNL Computation Type1
“Sponsoring” Cells = ASET
neighbourCellPrio = [0...62]
(UMTSFddNeighbouringCell)
Priority Level
� For each sponsoring cell, build a neighbouring list orderedby neighbourCellPrio
� Build the final intra-frequency neighbouring list as follows:
1. Add the sponsoring cells
2. Select the numOfPrimaryCellNeighbourIntraFreq first cells from Primary Cell's neighbouring list
• Defined under RadioAccessService
3. Then perform the selection by number of occurrence
• In case of conflict, select:
• the one whose sponsoring cell has the highestEc/No
• then the one with highest neighbourCellPrio
4. Until maxCompoundingListSizeIntraFreq is reached
Intra-Freq Neighboring List compounding Algorithm
Primary Cell Change
OR
Active Set Modification
OR
SHO to non-SHO Transition
OR
Dedicated Connection Initiation
A1NA2
NA1
A3NA2
A2NA1NA3
NA1NA2
NA1
NA2NA3
NA1NA3
NA3
NA2NA3
NA2
NA3
isCompoundingCellListActivated
(RadioAccessService)= Type1
Type1 is the newly algorithm introduced in UA06.0 and is mainly based on:
• neighbourCellPrio, between 0 and 62, defining for each FDD Cell a hierarchy within its neighbourhood (0 is the highest priority, 62 the lowest); note that two UMTSFddNeighbouringCell can NOT have the sameneighbourCellPrio.
• “sponsoring cells” which are the cells from the ASET
• occurrence of each neighbouring cell within the sponsoring cells’ neighbourhood.
For each sponsoring cell, RNC builds a neighbouring cell list ordered by neighbourCellPrio. Then it buildsthe final intra-frequency neighbouring list by:
• adding the sponsoring cells
• selecting the numOfPrimaryCellNeighbourIntraFreq first neighbouring cells from Primary Cell'sneighbouring list
• and then performing the selection by number of occurrence
In case of conflict, RNC selects:
• the neighbouring cell whose sponsoring cell has the highest CPICH Ec/No, then the one with the highestneighbourCellPrio until maxCompoundingListSizeIntraFreq is reached.
Iur case
� In case a cell from the active set belongs to a Drift RNC, the Serving RNC may learn its intra-frequencyneighbourhood using the information present in RNSAP RadioLinkSetup/AdditionResponse message.
� When type1 is selected, RNC automatically assigns neighbourCellPrio by order of presence in theRNSAP message (starting from 0).
It is recommended to set maxCompoundingListSizeIntraFreq to 32 to ensure that at least all cells of theprimary cell are sent. If maxCompoundingListSizeIntraFreq is 16 (for example) and the primary cell has 20 data filled neighbours, then only 16 neighbours will be sent to the UE.
If the flag detectedSetCellAddition is set to ENABLED or AUTOMATIC, then parametermaxCompoundingListSizeIntraFreq MUST be set to any value less than 32. (31 is recommended).
Section 9 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 14
1.4 Intra-Freq CNL Management
1.4.3 CNL Computation - RAN Model
RNC
RadioAccessService
NeighbouringRnc
NodeB
FDDCell
isCompoundingCellListActivated {True, False}
maxCompoundingListSizeIntraFreq [16..32]
typeOfCompoundingNeighbourListIntraFreq {prl, type1, type2}
numOfPrimaryCellNeighbourIntraFreq [0..32]
UMTSFddNeighbouringCell
neighbourCellPrio [0..62]
typeOfCompoundingNeighbourListIntraFreq {prl, type1, type2}
numOfPrimaryCellNeighbourIntraFreq [0..32]
Section 9 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 15
1 SHO Mobility Requirements
1.5 Exercise
Cell27
Cell24
Cell25
Cell26
Cell23
Cell22
Cell21
Cell53
Cell52
Cell4
Cell3
Cell51
Cell1
Cell2
Cell13
Cell14
Cell11
Cell12
Cell17
Cell18
Cell19
Cell51
Cell16
Cell15
Cell4
Cell3
Cell2
Cell1
maxCompoundingListSizeIntraFreq = 26
Cell34
Cell33
Cell32
Cell31
Cell53
Cell52
Cell55
Cell54
Cell39
Cell38
Cell37
Cell36
Cell35
Cell4
Cell2
Cell1
Cell54
Cell55
Cell41
Cell42
Cell43
Cell44
Cell49
Cell48
Cell47
Cell46
Cell45
Cell3
Cell2
Cell1
Cell11
Cell12
Cell1
Cell31
Cell32
Cell33
Cell21
Cell22
Cell23
Cell52
Cell53
Cell24
Cell25
Cell26
Cell27
Cell51
Cell19
Cell18
Cell17
Cell16
Cell15
Cell14
Cell13
Cell4
Cell3
Cell2
Cell3 Cell4
Type2
Primary Cell'sneighbourhood
Cell2'sneighbourhood
Sponsoring cells 1 to 4 are ordered by EcNoCell1 > Cell2 > Cell3 > Cell4
Cell1 is assumed to be the Primary Cell
Type1
Cells from ASET
Cell3'sneighbourhood
Build the list of cells for Intra-FreqMeasurementsin Cell_DCH
numOfPrimaryCellNeighbourIntraFreq = 4
type1 is the newly algorithm introduced in UA06.0 and is mainly based on:
� neighbourCellPrio, between 0 and 62, defining for each FDD Cell a hierarchy within its neighbourhood(0 is the highest priority, 62 the lowest); note that two UMTSFddNeighbouringCell can NOT have thesame neighbourCellPrio.
� “sponsoring cells” which are the cells from the ASET
� occurrence of each neighbouring cell within the sponsoring cells’ neighbourhood.
For each sponsoring cell, RNC builds a neighbouring cell list ordered by neighbourCellPrio. Then it buildsthe final intra-frequency neighbouring list by:
� adding the sponsoring cells
� selecting the numOfPrimaryCellNeighbourIntraFreq first neighbouring cells from Primary Cell's
neighbouring list
� and then performing the selection by number of occurrence
In case of conflict, RNC selects:
� the neighbouring cell whose sponsoring cell has the highest CPICH Ec/No, then the one with the highest
neighbourCellPrio until maxCompoundingListSizeIntraFreq is reached.
Section 9 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 16
2 Active Set Management (Soft HO)
Section 9 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 17
2 Active Set Management
2.1 Absolute and Relative Criteria for SHO
Drop Delta
Add Delta
DropRelativeCriterion
AddRelativeCriterion
Best Cell
AddAbsoluteThreshold
Add Absolute Criterion
DropAbsoluteThresholdDrop Absolute Criterion
P-CPICH Ec/No
No Action
The active set update algorithm applies to all soft handover cases. Its purpose is to ensure that the
strongest cells in the UE environment will be part of its active set.
The algorithm is based on relative comparison between the best cell and each cell CPICH EC/N0 of the
reported set.
Since UA04.1, the Active Set Update algorithm offers the possibility of using absolute thresholds for link
addition and link deletion criteria, providing additional tools to reducing call drop rates and improve the
capacity of the network from the perspective of radio power, code and RNC and Node B processing cost.
Note that absolute thresholds are optional and can be deactivated through parameters. Once activated, the
criteria for RL Addition/RL Deletion would be a logical OR between the relative and absolute criteria.
Cell Individual Offsets have also been supported since UA04.1. CIO is added to the measurements received
from the mobile before SHO conditions are evaluated, that is, Ec/No(i) + CellIndividualOffset(i) is
compared to the add or drop threshold (relative or absolute).
Note: Cell individual offset is taken into account by the RNC only if at least one of the flag enabling absolute thresholds (add or drop) is set to true.
Section 9 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 18
2 Active Set Management
2.2 Drop Criteria (Periodical Mode)
IF
Ec/No(i) + Cell Individual Offset(i) ≤ Ec/No(best) – Drop Delta
AND
Ec/No(i) + Cell Individual Offset(i) < Add Absolute Threshold (if Add Absolute Criterion enabled)
OR
Ec/No(i) + Cell Individual Offset(i) ≤ Drop Absolute Threshold (if Drop Absolute Criterion enabled)
THEN
Drop Cell(i) from Active Set
ELSE
Keep Cell(i) in Active Set
Keep Cell in Active Set
Drop Cell from Active Set
neighbouringCellOffset (UMTSNeighbouringRelation)
legDroppingDelta (SoftHoConf)
shoLinkAdditionAbsoluteThresholdEnable (SoftHoConf)
shoLinkAdditionCpichEcNoThreshold (ShoLinkAdditionParams)
shoLinkDeletionAbsoluteThresholdEnable (SoftHoConf)
shoLinkDeletionCpichEcNoThreshold (ShoLinkDeletionParams)
Drop DeltaAdd Absolute Threshold
Drop Absolute Threshold
RNC first identifies which is the best cell, that is, the cell with the highest CPICH EC/N0 of the reported set
(active set + monitored set).
Then for the cells belonging to the active set, RNC applies the drop criteria:
� Cells not matching drop criteria are kept in the active set until the maximum number of cells in the
active set is reached.
� Cells matching one of drop conditions are removed from the active set.
The drop criteria depend on the activation of the absolute add or drop thresholds.
If none of the cells of the current active set are eligible, the RNC keeps at least the best cell even if it does
not meet the criteria to be eligible.
The RNC identifies then the remaining cells (non-eligible cells) as cells to be removed from the active set.
This information will be transmitted in the active set update message.
When both relative and absolute criteria are used for the SHO Algorithm, it may happen that the relative
and absolute criteria trigger contradictory decisions for the same cell.
In order to avoid such a situation, it is necessary to add a supplementary check in order not to delete a
radio link which satisfies the link relative deletion threshold but is above the link absolute addition
threshold.
Section 9 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 19
2 Active Set Management
2.3 Add Criteria (Periodical Mode)
IF
Ec/No(i) + Cell Individual Offset(i) ≥ Ec/No(best) - Add Delta
AND
Ec/No(i) + Cell Individual Offset(i) > Drop Absolute Threshold (if Drop Absolute Criterion enabled)
OR
Ec/No(i) + Cell Individual Offset(i) ≥ Add Absolute Threshold (if Add Absolute Criterion enabled)
THEN
Add Cell(i) in Active Set
ELSE
Keep Cell(i) in Monitored Set
neighbouringCellOffset (UMTSFddNeighbouringCell)
legAdditionDelta (SoftHoConf)
shoLinkAdditionAbsoluteThresholdEnable (SoftHoConf)
shoLinkAdditionCpichEcNoThreshold (ShoLinkAdditionParams)
shoLinkDeletionAbsoluteThresholdEnable (SoftHoConf)
shoLinkDeletionCpichEcNoThreshold (ShoLinkDeletionParams)
maxActiveSetSize (UsHoConf)
Add Cell in Active Set
Add Delta
Add Absolute Threshold
Keep Cell in
Monitored Set
Drop Absolute Threshold
The RNC first identifies which is the best cell, that is, the cell with the highest CPICH EC/N0 of the
reported set (active set + monitored set).
Then for the cells belonging to the monitored set, RNC applies the add criteria:
� Cells matching one of add delta & add absolute criteria are added in the active set until the maximum
Active Set size is reached.
� Cells not matching any add criteria are ignored.
The addition criteria depend on the activation of the absolute add or drop thresholds.
When both relative and absolute criteria are used for the SHO Algorithm, it may happen that the relative
and absolute criteria trigger contradictory decisions for the same cell.
In order to avoid such a situation, it is necessary to add a supplementary check in order not to add a radio
link which satisfies the link relative addition threshold but is below the link absolute deletion threshold.
Section 9 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 20
2 Active Set Management
2.4 Event 1A
Best Cell
New Cell
CPICH_EC/No
entering reporting range
leaving reporting range
Event1
A
Event1
A
Event1
A
timeToTrigger1A(FullEventHOConfShoMgtEvent1A)
repInterval1A(FullEventRepCritShoMgtEvent1A)
amountRep1A(FullEventRepCritShoMgtEvent1A)
)2/(10)1(1010 111
aaBest
N
iiNewNew HRLogMWMLogWCIOLogM
A
m−⋅⋅−+
⋅⋅≥+⋅ ∑
=
maxNbReportedCells1A(FullEventRepCritShoMgtEvent1A)
wParam (static)cpichEcNoReportingRange1A
hysteresis1A(FullEventHOConfShoMgtEvent1A)
neighbouringCellOffset (UMTSNeighbouringRelation)
maxActiveSetSize (UsHoConf)
Event 1A is triggered when a new P-CPICH enters the reporting range.
Event 1A is used to add a RL based on relative criteria when the Active Set is not full.
The variables in the formula are defined as follows:
� MNew is the measurement result of the cell entering the reporting range.
� CIONew is the individual cell offset for the cell entering the reporting range if an individual cell offset is
stored for that cell. Otherwise it is equal to 0.
� Mi is a measurement result of a cell not forbidden to affect reporting range in the active set.
� NA is the number of cells not forbidden to affect reporting range in the current active set.
� MBest is the measurement result of the cell not forbidden to affect reporting range in the active set with
the best measurement result, not taking into account any cell individual offset.
� W is a parameter sent from UTRAN to UE.
� R1a is the reporting range constant.
� H1a is the hysteresis parameter for event 1a.
By default event 1A is triggered by cells belonging to the monitored set.
In order to help the operator to monitor efficiently its network, and optimize its neighboring plan, it is
possible to trigger this event 1A based on both Detected Set and Monitored Set.
� In order to achieve this, the parameter isDetectedSetCellsAllowed shall be set to True.
� From UA7 onwards the decision if the cells from Detected Set are used in the mobility algorithms
depends on the flag detectedSetCellAddition (see next slide).
Section 9 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 21
Cell xxx is computed in new Compounding List
2 Active Set Management
2.5 Detected Set Cells Addition to Active Set
RRC Measurement Control
Cutoff List
Cell xxx
New Active SetNew Monitored Set
RRC Measurement Report 1A (Monitored Cell)
RRC Measurement Control
IntraFrequency MeasReporting Criteria = Detected set cells and monitored set cells
RRC Measurement Report 1A (Detected Cell xxx)
Compounding Cell List Algo
TYPE 1
Event 1A TriggeringCondition =
detectedSetAndMonitoredSetCellsOR
monitoredSetCells
OAM CONFIGURATION
RNC
isDetectedSetCellsAllowed (RadioAccessService)
= Enabled OR(Automatic AND Cutoff List <> Ø)
detectedSetCellAddition (FddCell)
typeOfCompoundingNeighbourListIntraFreq(FDDCell and NeighbouringRNC)
= True
= TYPE 1
= Automatic AND Cutoff List = ØdetectedSetCellAddition (FddCell)
From UA7 onwards, if the flag detectedSetCellAddition is set to ENABLED or AUTOMATIC then the cells from the Detected Set can be added to the Active Set.
� If the combined intra frequency Cell Info List exceeds its maximum list size
maxCompoundingListSizeIntraFreq then cells with lower ranking priority need to be cut off from the
list which in consequence does no more represent the complete neighbourhood of the active set.
� The cells having been cut off may reappear as detected set cells reported by the UE and will be re-
identified by the RNC. Those cells will no longer be ignored but be eligible to be added to the active
set.
� This is applicable when compounding algorithm Type1 is activated. Type2 does not support detected set
cell addition in the active set.
� Compounding Neighbouring List algo (typeOfCompoundingNeighbourListIntraFreq) must be set to “Type1”
� maxCompoundingListSizeIntraFreq MUST be set to any value strictly less than 32.
If the flag detectedSetCellAddition is set to DISABLED the cells from Detected Set will not be used in the mobility algorithms.
Section 9 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 22
2 Active Set Management
2.6 Event 1B
Best Cell
Old Cell
CPICH_EC/No
leaving reporting range
entering reporting range
Event1
B
Event1
B
timeToTrigger1B(FullEventHOConfShoMgtEvent1B)
repInterval1B(FullEventRepCritShoMgtEvent1B)
amountRep1B(FullEventRepCritShoMgtEvent1B)
cpichEcNoReportingRange1Bhysteresis1B
(FullEventHOConfShoMgtEvent1B)
Event1
B
Event1
B
maxNbReportedCells1B(FullEventRepCritShoMgtEvent1B)
)2/(10)1(1010 111
bbBest
N
iiOldOld HRLogMWMLogWCIOLogM
A
±−⋅⋅−+
⋅⋅≤+⋅ ∑
=
wParam (static)
neighbouringCellOffset (UMTSNeighbouringRelation)
Event 1B is triggered when an active P-CPICH leaves the reporting range.
Event 1B is used to delete a RL based on relative criteria.
The variables in the formula are defined as follows:
� MOld is the measurement result of the cell leaving the reporting range.
� CIONew is the individual cell offset for the cell entering the reporting range if an individual cell offset is
stored for that cell. Otherwise it is equal to 0.
� Mi is a measurement result of a cell not forbidden to affect reporting range in the active set.
� NA is the number of cells not forbidden to affect reporting range in the current active set.
� MBest is the measurement result of the cell not forbidden to affect reporting range in the active set with
the best measurement result, not taking into account any cell individual offset.
� W is a parameter sent from UTRAN to UE.
� R1b is the reporting range constant.
� H1b is the hysteresis parameter for the event 1b.
Note: The above drawing shows an example assuming that CIO is set to 0 dB.
R99/R4 UEs are not able to use periodical measurement reporting after initial report.
Section 9 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 23
2 Active Set Management
2.7 Event 1C
AS Cell
InAS Cell
CPICH_EC/No
leaving reporting range
entering reporting range
Event1
C
Event1
CtimeToTrigger1C
(FullEventHOConfShoMgtEvent1C)repInterval1C
(FullEventRepCritShoMgtEvent1C)
amountRep1C(FullEventRepCritShoMgtEvent1C)
hysteresis1C (FullEventHOConfShoMgtEvent1C)
Event1
C
Event1
C
maxNbReportedCells1C(FullEventRepCritShoMgtEvent1C)
New Cell
)2/ 1010 1cInASInASNewNew HCIOLogMCIOLogM ±+≥+
neighbouringCellOffset (UMTSNeighbouringRelation)
maxActiveSetSize (UsHoConf)
Event 1C is triggered when a new P-CPICH becomes better than an active P-CPICH.
Event 1C is used to replace a 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.
Section 9 � Module 1 � Page 24
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 24
2 Active Set Management
2.7 Event 1C [cont.]
RNC
Non-active cell is added if :
CPICH_EcNonon-active cell + CIOnon-active cell > CPICH_EcNoPrimaryCell – cpichEcNoReportingRange1B
isEnhanced1cHandlingAllowed (RadioAccessService)
= True
From UA7 onwards, if the flag isEnhanced1cHandlingAllowed is set to TRUE, the RNC will determine if the pilot of any non-active cell to be added to the active set is weaker than the computed minimum signal
strength (= pilot strength of the strongest active set cell - cpichEcNoReportingRange1B)
If it is weaker, the candidate cell will not be added to the active set. A non-active cell will only be added if
the reported CPICH EcNo plus the Cell Individual Offset (CIO) is greater than threshold:
CPICH EcNo(NA_x) + CIO (NA_x) > CPICH EcNo (A1) - R1b
Where:
� A1 = strongest active set cell
� NA_x = non-active cell under consideration
� R1b = cpichEcNoReportingRange1B
Section 9 � Module 1 � Page 25
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 25
2 Active Set Management
2.8 Event 1E
AS Cell
New Cell
CPICH_EC/No
leaving reporting range
entering reporting range
Event1
E
timeToTrigger1E (FullEventHOConfShoMgtEvent1E)
absolute threshold
maxNbReportedCells1E(FullEventRepCritShoMgtEvent1E)
2/10 11 eeNewNew HTCIOLogM ±≥+
neighbouringCellOffset (UMTSNeighbouringRelation)
cpichEcNoReportingRange1Ehysteresis1E
(FullEventHOConfShoMgtEvent1E)
maxActiveSetSize (UsHoConf)
Event 1E is triggered when a new P-CPICH becomes better than an absolute threshold.
Event 1E is used to add a RL based on absolute criteria when the Active Set is not full.
The variables in the formula are defined as follows:
� MNew is the measurement result of a cell that becomes better than an absolute threshold.
� CIONew is the individual cell offset for the cell becoming better than the absolute threshold. Otherwise
it is equal to 0.
� T1e is an absolute threshold.
� H1e is the hysteresis parameter for the event 1e.
In order to help the operator to monitor efficiently its network, and optimize its neighboring plan, it is
possible to trigger this event 1E based on both Detected Set and Monitored Set. However the cells from
Detected Set will not be used in the mobility algorithms.
� In order to achieve this, the parameter isDetectedSetCellsAllowed shall be set to True.
Section 9 � Module 1 � Page 26
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 26
2 Active Set Management
2.9 Event 1F
AS Cell
Old Cell
CPICH_EC/No
leaving reporting range
entering reporting range
Event1
FtimeToTrigger1F (FullEventHOConfShoMgtEvent1F)
absolute threshold
maxNbReportedCells1F(FullEventRepCritShoMgtEvent1F)
2/10 11 ffOldOld HTCIOLogM ±≤+
neighbouringCellOffset (UMTSNeighbouringRelation)
cpichEcNoReportingRange1Fhysteresis1F
(FullEventHOConfShoMgtEvent1F)
Event 1F is triggered when an active P-CPICH becomes worse than an absolute threshold.
Event 1F is used to delete a RL based on absolute criteria.
The variables in the formula are defined as follows:
� MOld is the measurement result of a cell that becomes worse than an absolute threshold.
� CIOOld is the individual cell offset for the cell becoming worse than the absolute threshold. Otherwise it
is equal to 0.
� T1f is an absolute threshold.
� H1f is the hysteresis parameter for the event 1f.
Section 9 � Module 1 � Page 27
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 27
2 Active Set Management
2.10 SHO Blocking Phase
New events
RNC
Ongoing RRC procedure
shoAfterBlockingPhaseEnable
(RadioAccessService)
True False
buffer
stored
event1xevent1y
flushed
A SHO procedure may block other procedures or may be blocked by ongoing procedures.
On the one hand a blocking phase consists in forbidding any procedure until a SHO procedure is completed,
i.e. after RNC receives RRC ActiveSetUpdateComplete from UE.
shoAfterBlockingPhaseEnable parameter allows to activate a mechanism to process events during such
blocking phase :
� When set to True, all the events received during the blocking phase are stored in a stack and processed once on-going procedure is completed, thus preventing abusive call drops in case of unexpected
add/delete.
� When set to False, all these events are discarded, thus inhibiting mobility and degrading performances.
Section 9 � Module 1 � Page 28
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 28
2.10 SHO Blocking Phase
2.10.1 Events Storage
Event1A(cell1)
RNC
Ongoing RRC procedure
shoAfterBlockingPhaseEnable = TrueUE > R99
1B(cell4)1A(cell3)
Event1B(cell2)
Event1A(cell3)
Event1B(cell4)
isOne1bStorageAllowed
(RadioAccessService)
True False
1A(cell3)1B(cell4)1B(cell2)
UE = R99
The RNC process only the last event 1A, 1C, 1D, 1E or 1J received during the blocking phase. Appropriate
action is taken just after the completion of the other procedure. The RNC however processes all events
1F received during the blocking phase.
A specific handling has been provided for event 1B in order to adapt the RNC’s reaction to different UE
behaviour. If several events 1B have been received from the same UE during a blocking phase, the events
related to a continuous trigger condition (received from a UE with release later than R99) or the
successive single samples representing different trigger conditions (received from a R99 UE) will be
repeated by the UE.
In order to avoid any loss of information on radio links to be deleted, RNC should keep the received events
until the other procedure is completed; but queuing of all repeated events may lead to handling of
outdated measured results. They will be reactivated and processed sequentially when the blocking phase
is terminated. If event 1A or 1C was stored in parallel then event 1B will be processed first.
However, in order to enhance the handling of event 1B by keeping only the last event 1B when multiple
events 1B are received in the blocking phase, the handling of event 1B received from a UE later than R99
depends on the flag isOne1bStorageAllowed as follows:
� If the flag isOne1bStorageAllowed is set to TRUE, only the last event 1B received during a blocking phase will be stored. It will be reactivated on completion of the other procedure. Compared to the
behaviour defined above for R99 UEs the processing will be in reverse order such that event 1B will be
processed after event 1A or 1C if stored in parallel.
� If the flag isOne1bStorageAllowed is set to FALSE then the same behaviour as defined above for R99 UEs will apply.
Section 9 � Module 1 � Page 29
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 29
3 Primary Cell Change
Section 9 � Module 1 � Page 30
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 30
3 Primary Cell Change
3.1 Primary Cell Election: Periodical Mode
IF
Cell(i) was in previous Active Set
AND
Cell(i) is in new Active Set
AND
Ec/No(i) – Drop Primary Delta ≥ Ec/No(Primary Cell)
THEN
Cell(i) is candidate for Primary Cell Election
ELSE
Keep Cell(i) in Active Set
IF
Ec/No(i) is the highest of all candidate cells
THEN
Cell(i) is the new Primary Cell
ELSE
Keep Cell(i) in Active Set
primaryRlDelta (SoftHoConf)
Candidate Cells Selection
Primary Cell Election
New Active Set
Cell 1Cell 2Cell 3Cell 4
Candidate Cells
Cell 1
Cell 3
Candidate Cells
Cell 1
Cell 3
Cell 3
Prim
ary
Cell
The primary cell selection algorithm applies to all soft handover cases. The primary cell is used for
monitored set determination, but also as a pointer to mobility parameters. The primary cell selection
algorithm is performed each time a MEASUREMENT REPORT is received by the S-RNC.
To be selected as candidate cell, the following conditions must be true:
� Cell was present in the previous active set.
� Cell is eligible to be in the new active set (Reference: soft handover algorithm).
� Cell has the strongest CPICH_Ec/N0 of the MEASUREMENT_REPORT.
The previous primary cell is compared with the candidate cell for primary minus a threshold defined
PrimaryRlDelta. The CPICH EC/N0 values used are the ones contained in the RRC MEASUREMENT_REPORT.
The Monitored Set should be updated each time the primary cell of active set changes. This is performed
via the RRC_MEASUREMENT_CONTROL message (with the measurement command set to modify) sent to
the UE with the cells to add and remove from the previous monitored set to form the new one.
The monitored set update usually follows the ACTIVE_SET_UPDATE message, but may also happen without
any ACTIVE_SET_UPDATE, when the active set content does not change, but, inside the active set, a cell
becomes strong enough to replace the primary cell.
Section 9 � Module 1 � Page 31
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 31
3 Primary Cell Change
3.2 Primary Cell Change: Event 1D
Best Cell
CPICH_EC/No
leaving reporting range
entering reporting range
Event1
D
timeToTrigger1D(FullEventHOConfShoMgtEvent1D)
hysteresis1D (FullEventHOConfShoMgtEvent1D)
neighbouringCellOffset (UMTSNeighbouringRelation)
maxNbReportedCells1D
useCIOfor1D
(FullEventRepCritShoMgtEvent1D)
NotBest Cell
)2/1010 1dBestBestNotBestNotBest HCIOLogMCIOLogM ±+⋅≥+⋅
The primary cell determination is based on event 1D reception. Based on the reception of this event, the
RNC stores the new primary, and applies the current process used in case of change of primary cell.
Since events 1A and 1C are also configured it is assumed that the new primary cell is already in the Active
Set when a 1D event is triggered. Typically, this will be ensured if the time to trigger 1D is greater or
equal than the time to trigger events 1A or 1C. It should be noted that a monitored set cell that needs to
be included in the active set will trigger first a 1A event if its CPICH Ec/No is lower than the best cell in
the Active set but entering in its reporting range, or a 1C event if the Active Set is full and this cell is
better than the worst in the Active Set.
A 1D event will typically be triggered by a cell better than the best in the active set. Therefore due to the
triggering conditions defined for these events, if the time to trigger a 1D event is greater than or equal to
that for a 1A and 1C event, the 1D will typically be triggered by a cell in the active set.
If the event 1D is triggered by a monitored cell, the RL will be added in the Active Set if not full.
If the Active Set is full and the 1D event is triggered by a monitored set cell, then the new best cell will be
added in the active set, replacing the worst active set cell.
A new primary cell will be defined if the current primary cell is removed due to reception of RL deletion
events.
Section 9 � Module 1 � Page 32
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 32
3 Primary Cell Change
3.3 Service Based Intra-Freq Mobility : RAN Model
RadioAccessService
DedicatedConf
HoConfClass [0..30]
UsHoConf [0..21]
SoftHoConf
FullEventHoConfShoMgt
FullEventHoConfShoMgtEvent1…
Event1AHoConfInSIB11
FDDCell
MeasConfClass [0..14]
cpichEcNoReportingRange1AtimeToTrigger1A
hysteresis1AmaxActiveSetSize
legDroppingDeltalegAdditionDeltaprimaryRlDelta
DlUserService
NeighbouringRNC
isEvent1EUsedisEvent1FUsed
hysteresis1Chysteresis1Dhysteresis1Ahysteresis1Bhysteresis1Ehysteresis1F
maxActiveSetSize
timeToTrigger1AtimeToTrigger1BtimeToTrigger1CtimeToTrigger1DtimeToTrigger1EtimeToTrigger1F
cpichEcNoReportingRange1AcpichEcNoReportingRange1BcpichEcNoReportingRange1EcpichEcNoReportingRange1F
ShoLinkAdditionParams shoLinkAdditionCpichEcNoThreshold
ShoLinkDeletionParams shoLinkDeletionCpichEcNoThreshold
mobilityServiceType
Section 9 � Module 1 � Page 33
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 33
4 Intra-Freq Hard HO
Section 9 � Module 1 � Page 34
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 34
4 Intra-Freq Hard HO
4.1 Intra-Freq Inter-RNC Mobility w/o Iur : HHO Activation
Measurement Report
MeasurementID
MeasurementReportingQuantity
MeasurementResults
� Measurement Id 1:
� Cell A, B & C are candidates to SHO (specified in the new IE)
� 1A, 1B, 1C, 1D, 1E and 1F (dedicated to SHO)
� Cell A, B & C could be candidates to HHO in case IUR link is down
� Measurement Id 16:
� Cell D is candidate to HHO (specified in the new IE)
� Event 1A is the only event provisioned as SHO can NOT be performed without IUR
SRNC
RNC1
RNC2
Cell AF1
Cell BF1
Cell CF1
Cell DF1
isIntraFreqInterRncHHOAllowedisIntraFreqInterRncHhoOnIurLinkDownAllowed isEventTriggeredMeasAllowed
Measurement Control (new IE: Cells for measurements )
Intra-frequency Inter-RNC mobility without IUR may occur in the following situations:
� Two different operators (PLMN) using the same frequency in the same area
� National roaming agreements are needed
� In a single PLMN, no IUR provisioned between 2 RNC
� E.g. due to IOT reasons between 2 different RNC manufacturers
� In a single PLMN, IUR interface is provisioned but is not in an enabled state
Need to handle Intra-frequency Inter-RNC HHO
FRS 21302 was initially implemented in UA4.3K timeframe
FRS 33422 was duplicated for UA5.0
� Code was implemented but commercially not supported
� Not applicable to HSxPA calls
FRS 33814 has been created for UA6.0
� Feature is fully supported
� Also applicable to HSxPA calls
Section 9 � Module 1 � Page 35
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 35
4 Intra-Freq Hard HO
4.2 RRC Measurement Control Configuration
� No influence of isIntraFreqInterRncHHOIurLinkDownAllowed� This flag is only used at RRC Measurement Report (MR) processing (cf. next slide)
� E1A triggering conditions depend on MeasId� Detected set and monitored set for MeasId1
� Only Monitored Set for MeasId16
� Specific E1A parameters for MeasId16
Measurement Identity = MeasId16,
New intra-frequency cells is empty as already present in MeasId1
Cells for measurements = {HHO candidate list}
Measurement Identity = MeasId1,
New intra-frequency cells= {SHO candidate list + HHO candidate list}
Cells for measurements = {SHO candidate list}
isIntraFreqInterRncHHOAllowed= TRUE
Not sent by RNCMeasurement Identity = MeasId1,
New intra-frequency cells = {SHO candidate list}
isIntraFreqInterRncHHOAllowed= FALSE
RRC Measurement Controlfor MeasId2
RRC Measurement Controlfor MeasId1
Section 9 � Module 1 � Page 36
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 36
4 Intra-Freq Hard HO
4.3 HHO Detection after MeasId1: Iur link is down
RNC
RadioAccessService
UmtsNeighbouring
isIntraFreqInterRncHHOAllowed = TRUEisIntraFreqInterRncHhoOnIurLinkDownAllowed = TRUE
isHsdpaHhoWithMeasAllowedisEdchHhoWithMeasAllowed
UmtsNeighbouringRelation
neighbouringCellOffset
DlUserService
IntraFreqTargetCellParams
minimumCpichEcNoValueForHHOminimumCpichRscpValueForHHO
Case of MeasId1 (e1a) leading to HHO detection
Cells 1 2 3 4
cpichEcNoReportingRange1A – hysteresis1A / 2
This best cell meets the criteria for RL addition SHO but IUR isdown ���� HHO is triggered
Links from ASET
Measured links (SHO candidates)
Measured links (HHO candidates)
minimumCpichEcNoValueForHHO
MR for MeasId1 (Event 1A)
� UE reports MeasId1(E1A) in case SHO RL addition conditions are met
� Triggering cells may belong to SRNC or DRNC when IUR is provisioned
� Several conditions must be fulfilled for SRNC to detect HHO
� The triggering cell belongs to DRNC but SRNC detects an IUR outage
� The following flags are set to True
� isIntraFreqInterRncHHOAllowed
� isIntraFreqInterRncHhoOnIurLinkDownAllowed
� isHsdpaHhoWithMeasAllowed for HSDPA calls
� isEdchHhoWithMeasAllowed for E-DCH calls
� The triggering cell i is reported better than the best one in the ASET
� EcNoi + CIOi > EcNobest_ASET + CIObest_ASET
� The triggering cell i respects the following condition:
� (EcNoi >= minimumCpichEcNoValueForHHO) AND (Rscpi >= minimumCpichRscpValueForHHO)
� Beware to confusion with minimumCpichEcNo/RscpValueForHO dealing with IFREQ HHO
� In case several cells fulfill these 2 conditions, HHO is triggered towards the cell with highest EcNo + CIO
Section 9 � Module 1 � Page 37
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 37
4 Intra-Freq Hard HO
4.4 HHO Detection after MeasId16: Iur link is not provisioned
minimumCpichEcNoValueForHHO
Cells 1 2 3 4
cpichEcNoReportingRange – hysteresis / 2
This best cell can NOT be added into the ASET as IUR is not provisioned ���� HHO is triggered
Case of MeasId16 leading to HHO detection
Links from ASET
Measured links (SHO candidates)
Measured links (HHO candidates)
RNC
RadioAccessService
UmtsNeighbouring
isIntraFreqInterRncHHOAllowed = TRUEisHsdpaHhoWithMeasAllowedisEdchHhoWithMeasAllowed
UmtsNeighbouringRelation
neighbouringCellOffset
DlUserService
IntraFreqTargetCellParams
minimumCpichEcNoValueForHHOminimumCpichRscpValueForHHO
MR for measid16 (Event 1A)
� UE reports measid16(E1A) in case Intra-frequency HHO conditions are met
� Triggering cells must belong to another RNC when IUR is NOT provisioned
� Several conditions must be fulfilled for SRNC to detect HHO
� The triggering cell can NOT be added in the ASET as IUR is NOT provisioned
� The following flags are set to True
� isIntraFreqInterRncHHOAllowed
� isHsdpaHhoWithMeasAllowed for HSDPA calls
� isEdchHhoWithMeasAllowed for E-DCH calls
� The triggering cell i is reported better than the best one in the ASET
� EcNoi + CIOi > EcNobest_ASET + CIObest_ASET
� The triggering cell i respects the following condition:
� (EcNoi >= minimumCpichEcNoValueForHHO) AND (Rscpi >= minimumCpichRscpValueForHHO)
� Beware to confusion with minimumCpichEcNo/RscpValueForHO dealing with IFREQ HHO
� In case several cells fulfill these 2 conditions, HHO is triggered towards the cell with highest EcNo + CIO
Section 9 � Module 1 � Page 38
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 38
4 Intra-Freq Hard HO
4.5 RAN Model
DedicatedConf
RadioAccessService
RNC
FddCell HoConfClass
UsHoConf
FullEventHoConfHhoMgt
MeasurementConfClass
FullEventRepCritHhoMgt
FullEventRepCritEvent1AWithoutIur
DlUserService
IntraFreqTargetCellParams
FullEventHOConfHhoMgtEvent1AWithoutIur
amountRepmaxNbReportedCells
repInterval
isIntraFreqInterRncHHOAllowedisIntraFreqInterRncHhoOnIurLinkDownAllowed
isHsdpaHhoWithMeasAllowedisEdchHhoWithMeasAllowed
minimumCpichEcNoValueForHHOminimumCpichRscpValueForHHO
isEventTriggeredMeasAllowed
cpichEcNoReportingRangehysteresis
timeToTrigger
Section 9 � Module 1 � Page 39
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 39
5 SRNS Relocation (UE not Involved)
Section 9 � Module 1 � Page 40
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 40
5 SRNS Relocation (UE not Involved)
5.1 Principle
PS
After the SRNS relocation andlocation registration: data path is optimised
Before the SRNS relocation andlocation registration: soft handover has been
done via the Iur interface
LA2, RA2LA2, RA2
HLRHLR
GGSNGGSN
NewSGSN
OldSGSN
OldSGSN
NewSGSNOld
MSCOld MSC
SourceSRNC
TargetRNC
TargetSRNC
SourceRNC
UE UE
LA1, RA1LA1, RA1
New MSC
New MSC
CS
The SRNS Relocation procedure is used to move the RAN to CN connection point at the RNC from the source
SRNC to the target RNC. As a result of this procedure:
� The Iu links are relocated from the Source RNC (S-RNC) to the Target RNC (T-RNC)
� The target RNC becomes the SRNC.
� The source RNC is released from the call.
The figure shows a PS domain SRNS relocation example where the S-SRNC and T-SRNC are connected to
different SGSNs (i.e. inter-SGSN Relocation).
� Before the SRNS Relocation procedure, the UE is registered in the old SGSN. The source RNC is acting as
the serving RNC (SRNC).
� After the SRNS Relocation procedure the target RNC is acting as the serving RNC.
� The SRNS Relocation (UE not involved) is triggered when there are no links in the active set on the
Source RNC and all remaining links in the active set are on a single DRNC.
The SRNS relocation procedure implemented in Alcatel-Lucent UA5 UTRAN release is called Iur-based SRNS
relocation to differentiate it from the other variants of SRNS relocation defined by 3GPP 23.009.
The key benefits associated with Iur-SRNS relocation are as follows:
� Reduction in the delay associated with the routing of the user plane flow via the Iur interface.
� Capacity gain at RNC and Iur interface due to saving of Iur transmission resources
� QoS improvement: better RRM, less inter-RNC HHO
Section 9 � Module 1 � Page 41
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 41
5 SRNS Relocation (UE not Involved)
5.2 Example: Call Flow PS
UESourceRNC
Target RNC
OldSGSN
NewSGSN GGSN
1. Decision to perform SRNS Reloc
2. Relocation Required
3. Forward Relocation Request
4a. Relocation request
4c. Relocation Request Ack
5. Forward Relocation Response
6. Relocation Command
7. Relocation Commit
8. Relocation Detect
9a. RAN Mobility Information
9b. RAN Mobility Info Confirm 10. Relocation Complete
13a. Update Pdp context Req
13b. Update Pdp context Resp.
11a. Forward Reloc Complete
11b. Forward Reloc Complete Ack
12a. Iu Release Command
12b. Iu Release Complete
14. Routing Area Update (If RAI changes)
NodeB
4b. Iub SyncRelocationPreparation
RelocationExecution
The SRNS Relocation procedure is used to move the RAN to CN connection point at the RNC from the source
SRNC to the target RNC. As a result of this procedure:
� The Iu links are relocated from the Source RNC (S-RNC) to the Target RNC (T-RNC)
� The target RNC becomes the SRNC.
� The source RNC is released from the call.
The figure shows a PS domain SRNS relocation example where the S-SRNC and T-SRNC are connected to
different SGSNs (i.e. inter-SGSN Relocation).
� Before the SRNS Relocation procedure, the UE is registered in the old SGSN. The source RNC is acting as
the serving RNC (SRNC).
� After the SRNS Relocation procedure the target RNC is acting as the serving RNC.
� The SRNS Relocation (UE not involved) is triggered when there are no links in the active set on the
Source RNC and all remaining links in the active set are on a single DRNC.
The SRNS relocation procedure implemented in Alcatel-Lucent UA5 UTRAN release is called Iur-based SRNS
relocation to differentiate it from the other variants of SRNS relocation defined by 3GPP 23.009.
The key benefits associated with Iur-SRNS relocation are as follows:
� Reduction in the delay associated with the routing of the user plane flow via the Iur interface.
� Capacity gain at RNC and Iur interface due to saving of Iur transmission resources
� QoS improvement: better RRM, less inter-RNC HHO
Section 9 � Module 1 � Page 42
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 42
5 SRNS Relocation (UE not Involved)
5.3 Parameters
is3Gto3GWithIurAllowed
timeToTrigger3Gto3GWithIur
RNC
RadioAccessService
NeighbouringRNC
isOutgoing3Gto3GWithIurAllowedForCsConversationalisOutgoing3Gto3GWithIurAllowedForCsCsStreamingisOutgoing3Gto3GWithIurAllowedForCsPsInteractiveisOutgoing3Gto3GWithIurAllowedForCsPsBackground
isIncoming3Gto3GWithIurAllowedForCsConversationalisIncoming3Gto3GWithIurAllowedForCsStreamingisIncoming3Gto3GWithIurAllowedForPsInteractiveisIncoming3Gto3GWithIurAllowedForPsBackground
Section 9 � Module 1 � Page 43
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 43
Module Summary
� This lesson covered the following topics:
� Soft Handover types and purpose
� Soft Handovers and associated parameters
� Intra-Freq Hard Handovers and associated parameters
Section 9 � Module 1 � Page 44
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 44
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 9 � Module 1 � Page 45
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionMobility in SHO �
9 � 1 � 45
End of Module
Section 10 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
10�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 10Inter carrier Mobility in HHO
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 10 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 2
Blank Page
This page is left blank intentionally
Update due to new UA7 features:• Soft HO enhancements• iMCTA enhancements• Alarm HHO based on UE Tx Power• Inter-Frequency HHO enhancements• InterRAT HHO enhancements
Chatila, RayanRyser, SigridCharneau, Jean-Noel
2010-04-1501
RemarksAuthorDateEdition
Document History
Section 10 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Describe Hard Handover types and purpose
� Describe Inter-Freq and Inter-RAT Hard Handovers (iMCTA algorithm) and associated parameters
� Describe Compress Mode algorithm and parameters
Section 10 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 10 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 5
Table of Contents
Switch to notes view!Page
1 HHO Mobility Requirements 71.1 Hard Handover Types 8
2 Intelligent Multi-Carrier Traffic Allocation 92.1 Principle 102.2 iMCTA Triggers 112.3 Generic iMCTA Algorithm 122.4 iMCTA Triggering 132.4.1 Periodical Mode : HHO based on CPICH EcNo or RSCP 142.4.2 Event Trigger : HHO based on CPICH EcNo or RSCP 152.4.3 Event Trigger : HHO based on UE Tx Power 16
2.5 iMCTA Validity Checking: Primary Cell Is Under S-RNC 172.6 iMCTA Validity Checking: Primary Cell Is Under D-RNS 182.7 iMCTA Validity Checking: Specific to User Service 192.8 iMCTA Validity Checking: Specific to Mobility Service 202.9 iMCTA Validity Checking: Specific to All Service Triggers 212.10 iMCTA Configuration Retrieval: Alarm Priority Table 222.11 iMCTA Configuration Retrieval: CAC Priority Table 232.12 iMCTA Configuration Retrieval: Service Priority Tables 242.13 iMCTA Configuration Retrieval: Service HO Option 252.13.1 Non mono-CS RAB case 26
2.14 iMCTA: Inter-Freq & Inter-RAT CNL Computation (Type1) 272.14.1 Inter-FREQ example 282.14.2 Inter-RAT example 29
2.15 Neighboring Cells Searching and Filtering: Generic 302.16 Neighboring Cells Searching and Filtering: Specific 312.17 RAT Selection 322.17.1 Same Priority for 2G and FDD Layer 33
2.18 Load Based Inter-FDD Layer Filtering 342.19 Measurement Configuration 352.19.1 CM Scope & Methods 362.19.2 Need for Compressed Mode 372.19.3 High-Level Scheduling Method 382.19.4 HLS Activation 392.19.5 CM Pattern Sequences 402.19.6 Pattern Sequence Configuration 412.19.7 FDD Inter-Freq CM Pattern 422.19.8 GSM Inter-RAT CM Pattern 43
2.20 Measurement Report Processing (MRP) 442.20.1 Preferred Layer 452.20.2 iMCTA Alarm or CAC : Inter-Freq case 462.20.2.1 FDD cells Eligibility 472.20.2.2 Load Post-Filtering (Alarm or CAC) 482.20.2.3 Filtering on HSxPA Capabilities (Alarm or CAC) 49
2.20.3 iMCTA Alarm or CAC : Inter-RAT case 502.20.3.1 GSM cells Eligibility 512.20.3.2 2G Cell Load Management 522.20.3.3 Inter-RAT Case – Handover Call Flow 54
2.20.4 iMCTA Service : Inter-Freq case 552.20.4.1 Filtering on HSxPA Capabilities 562.20.4.2 Filtering on Load Criteria 57
2.20.5 iMCTA Service – Inter-RAT Case 582.21 HHO Decision 592.21.1 CM Deactivation / Reactivation 60
2.22 Inter-FREQ & Inter-RAT CNL - RAN Model 612.23 Service Based Inter-Freq/Inter-RAT Mobility - RAN Model 62
Section 10 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 6
Table of Contents [cont.]
Switch to notes view!Page
2.24 iMCTA - RAN Model 632.25 Exercise1: Set iMCTA Alarm Priority Table 642.26 Exercise2: Set iMCTA CAC Priority Table 652.27 Exercise3: Set iMCTA Service Priority Tables 662.28 Exercise4: Find the target cell chosen by iMCTA 68
3 Inter-FDD/Inter-RAT HHO 703.1 3G->2G HHO 713.2 CS 3G->2G HHO Failure: Next Best Cell Attempt 723.3 3G->3G Intra-RNC Inter-freq HHO 733.4 3G->3G Inter-RNC Inter-freq HHO: Iur not used 743.5 3G->3G Inter-RNC Inter-freq HHO: Iur used 75
Section 10 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 7
1 HHO Mobility Requirements
Section 10 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 8
1 HHO Mobility Requirements
1.1 Hard Handover Types
FDDcell
3G to 2G HHO
Core Network
Node B Node B
RNC RNC
FDDcell
Node B
Intra-RNC HHOFDDcell FDDcellFDDcell
FDDcell
GSMcell
2G to 3G HHO
Inter-RNC HHO
Hard Handover gathers a set of handover procedures where all the old radio links are abandoned before the
new radio links are established (break before make).
Hard handovers are needed as soon as the UE needs to leave its serving UMTS carrier. It could be:
� When the Iur interface is not present and the UE is moving from one RNC to another.
� When moving to another UMTS carrier (inter / intra-RNC or inter / intra-PLMN): this case is defined as
the inter-frequency HHO.
� When moving to another technology (GSM, GPRS): this case is defined as the inter-RAT HHO.
Section 10 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 9
2 Intelligent Multi-Carrier Traffic Allocation
Section 10 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 10
2 Intelligent Multi-Carrier Traffic Allocation
2.1 Principle
....32GSM
....23F2
....11F1
CsSpeech+Other
…CsConversationalCsSpeechLoss of coverage
CAC failure
Service type (HSDPA)
Load balancing
Why iMCTA ?
R99
HSDPAHSDPA
GSM
HSDPA HSDPA HSDPA
R99
R99
R99
R99
R99
R99
GSM GSM GSM
GSM GSM GSM GSM
R99
HHO Alarm
User Service CAC FailureR99
3G F1
3G F2
2G
R99
Mobility Service
The objective of the intelligent Multi-Carrier Allocation feature (iMCTA) is to optimize the traffic
distribution both between layers and cells. The iMCTA function is managed by the RNC.
� To increase the network capacity, operators may deploy multi layer configurations with several layers
structures: Multi layers with equal coverage, hot spots, micro cells, hierarchical cells structure.
� iMCTA works with up to four UMTS carriers, plus a 2G layer (whatever the frequencies). The FDD
carriers should be on the same frequency band (1900, or 850).
The traffic distribution strategy may be based on:
� load balancing
� service partitioning
� UE speed (not used in UA5)
� carrier redirection preferences
� mobility
The introduction of HSDPA/HSUPA will be also progressive with hot spots and there is a need to redirect
HSDPA/HSUPA capable mobile (R5, R6) towards HSDPA/HSUPA cells.
iMCTA allows to:
� Improve network capacity by
� Allocating radio resources preferably onto a certain layer according to:
� Service Type
� UE capability (R99, R5, R6)
� Balancing load between cells of the different overlapping layers
� Redirecting a UE to a unloaded cell on a CAC failure occurring in a serving cell
� Improve network quality by avoiding call drop in case of loss of coverage on a certain layer
� In UA5 a UE having an HSDPA RAB in an HSxPA capable cell will perform a HHO on iMCTA alarm using
measurements thanks to CM activation.
Section 10 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 11
2 Intelligent Multi-Carrier Traffic Allocation
2.2 iMCTA Triggers
iMCTA Alarm GSM
R99 R99
PS call establishment
HSxPAA
A
1. Alarms
2. CAC Failure
iMCTA CAC CR99
GSM
HSxPA
CS call
CAC failure at PS call establishment
C
3. Service Partitioning
4. Change of Service
GSM
R99
HSDPA
R5 UE - CS call
PS call establishmentPS call release
S
SiMCTA User Service S
iMCTA Mobility Service MR5 UE - PS call
GSM
R99 R99
HSxPA
M
Primary cell change
iMCTA (intelligent Multi-Carrier Traffic Allocation) algorithm manages HHO handovers which may be
triggered for several reasons:
� save the call in case of loss of coverage: iMCTA triggered on HHO Alarm (case 1)
� manage to establish a RAB that has experienced a CAC failure: iMCTA triggered on CAC Failure (case 2)
� optimize throughput by redirecting CS and PS calls to a prefered layer
� In case of a user service establishment or modification: iMCTA triggered on User Service (case 3)
� In case of Primary Cell change: iMCTA triggered on Mobility Service (case 4)
For any iMCTA trigger cause a load balancing can be applied in order to improve the overall network quality
and capacity:
� For iMTCA triggers on User Service or Mobility Service:
� Serving cell load can be checked to enable or disable the user redirection
� Target cell load can be checked to favor less loaded eligible cells
� For iMTCA triggers on HHO alarm or CAC Failure:
� Serving cell load is not checked
� Target cell load can be checked to favor less loaded eligible cells
The iMCTA function only applies to call in connected mode (Cell DCH, E-DCH and HS-DSCH).
� Call in Cell Fach (signaling or traffic), Cell PCH or URA PCH are not managed.
Section 10 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 12
2 Intelligent Multi-Carrier Traffic Allocation
2.3 Generic iMCTA Algorithm
iMCTA Triggering
iMCTA Algorithm
iMCTA Configuration Retrieval
RAT Selection
Measurement Report Processing
Measurement Configuration
iMCTA Validity Checking
Neighboring cells Searching and Filtering
HHO Decision
Load Based Inter-FDD Layer Filtering
iMCTA is composed of 7 different functions that are processed sequentially:
1. Invoking iMCTA upon 4 call triggering events:
� HHO Alarm trigger
� CAC failure trigger
� User Service trigger
� Mobility Service trigger
2. iMCTA validity checking to decide whether iMCTA must be processed or not
3. iMCTA configuration retrieval to select the right Priority table (priority is a key parameter for iMCTA and is defined per carrier and per service type)
4. Neighbouring cell searching and filtering to select and filter all inter-frequency and GSM neighboring cells
5. Radio Access Selection (FDD or GSM) based on neighboring cell and priority tables to select the Radio Access Technolog(y-ies) (RAT) to measure
6. Load Based Layer Filtering (UA7.1 onwards) on target cells to keep or remove all inter-Freqneighbouring cells of a given FDD layer before selecting the access type for measurement.
7. Measurement configuration to provide NodeB and UE with complete measurement information (Compressed Mode and neighboring cell list corresponding to the selected RAT)
8. Measurement report processing to process all RRC Measurement Report messages sent by UE; after this step, HHO can possibly be triggered by RNC.
Section 10 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 13
2 Intelligent Multi-Carrier Traffic Allocation
2.4 iMCTA Triggering
iMCTA Service
triggering
Mobility Service on
User Service on
iMCTA algorithm
iMCTA Alarm
triggering
HHO Alarm on
- Quality too bad
- Level too low
iMCTA CAC
triggering
CAC Failure on
- RAB assignment procedure (RAB to setup or modify)
- RAB assignment procedure (RAB to delete, in that case iMCTA CAC is processed for the remaining RAB(s))
- Iu release procedure (in that case iMCTA CAC is processed for the remaining RAB(s) of the other CN domain.
Primary Cell change
- RAB assignment procedure (RAB to setup or modify)
- RAB assignment procedure (RAB to delete if it is not the last RAB)
- Iu release procedure (if a RAB is still present for the other CN domain)
- Relocation Request procedure (if at least one RAB exists)
- Always-On upsize
There are 3 types of iMCTA invocations:
HHO Alarm trigger
� iMCTA is called on any HHO Alarm measurement whether Periodic Mode or Full Event Triggered Mode is
used
CAC failure trigger
� it covers all causes of CAC:
� From Cell: no radio resource available
� From Iub, Iur: Radio Link Reconfiguration Failure
� From Iub, Iur, Iu: Transport Bearer failure
� From S-RNC: user plane resource allocation failure
� iMCTA CAC is an enhancement of UA4.2 “3G to 2G CN-involved directed retry” feature as 2G HHO can now be triggered with measurements (only Blind HO in UA4.2).
Service trigger
� iMCTA Service aims at redirecting UE to a more appropriate layer (either UMTS or GSM) in order to improve:
� the quality of service provided to this user (e.g. by redirecting an HSUPA-capable UE to an HSUPA-capable cell)
� the usage of UTRAN resources (e.g. by redirecting a UE from a “Red” cell to a “Green” one)
� iMCTA Service is invoked after RNC has sent RANAP Rab Assignment Response or Iu Release Complete to CN, i.e. after RAB is established or released. Therefore, call establishment KPIs are not impacted by iMCTA Service.
Section 10 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 14
2.4 iMCTA Triggering
2.4.1 Periodical Mode : HHO based on CPICH EcNo or RSCP
cpichEcNoThresholdcpichRscpThreshold
counter stepUp
stepDown
(FastAlarmHardHoConf)
IF
P-CPICH_EcNo(primary) < cpichEcNoThreshold
OR
P-CPICH_RSCP(primary) < cpichRscpThreshold
THEN
Alarm Handover Counter is incremented by stepUp
IF
Alarm Handover Counter > counter
THEN
• iMCTA algorithm is triggered
ELSE
Alarm Handover Counter = Max ( 0; Alarm Handover Counter – stepDown)
Primary Cell Ec/No
HHO AlarmCM and Measurements
iMCTA triggered
Fast Alarm Handover feature offers the possibility of combining both measurements and alarm handover
criteria.
The Alarm measurements are activated once a criterion is fulfilled.
Then iMCTA algorithm is triggered. It is this algorithm which is responsible for performing the global HHO
procedure (inter-FDD or inter-RAT).
The iMCTA algorithm is fully described in the next chapter.
The trigger criteria are based on the same principle as alarm criteria, using CPICH Ec/N0 and RSCP
thresholds associated with a counter mechanism.
Section 10 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 15
2.4 iMCTA Triggering
2.4.2 Event Trigger : HHO based on CPICH EcNo or RSCP
timeToTrigger2D (FullEventRepCritHhoMgtEvent2D)maxNbReportedCells2D (FullEventRepCritHhoMgtEvent2D)
timeToTrigger2F (FullEventRepCritHhoMgtEvent2F)maxNbReportedCells2F (FullEventRepCritHhoMgtEvent2F)
Best Cell
CPICH_EC/NoCPICH_RSCP
leaving 2D reporting rangeentering 2D reporting range
Event2D
cpichEcNoThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)cpichRscpThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)hysteresis2D (FullEventHOConfHhoMgtEvent2D)cpichEcNoThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)hysteresis2F (FullEventHOConfHhoMgtEvent2D)cpichRscpThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)
2D absolute threshold
2/22 ddUsedUsed HTQ m≤ 2/22 ffUsedUsed HTQ ±≤
timerAlarmHoEvent2D(FullEventHOConfHhoMgt)
2F absolute thresholdleaving 2F reporting range
entering 2F reporting range
Event2F
Event2D
Alarm Measurement Criteria
Alarm Measurement Timer
NOT HIT HIT
iMCTA Alarm
The RNC uses the following algorithm:
� The timer timerAlarmHOEvent to confirm alarm handover criteria is started once a 2D event is received
for any of the measurement quantity (RSCP or Ec/No).
� If another subsequent 2D event with another measurement quantity is received, the timer shall
continue and the RNC records the fact that that both quantities fulfill their triggering condition.
� The timer timerAlarmHOEvent is stopped if a 2F event corresponding to the triggering 2D is received. In
case both quantities (RSCP and Ec/N0) have fulfils their triggering condition, the timer is stopped if
both 2F corresponding events are received (Ec/N0 and RSCP).
� A change of primary (event 1D) received while the timer is running has no effect on the algorithm,
except when the new primary has different thresholds than the previous primary cell, in which case the
2D/2F events are modified with the new thresholds.
Once the timer timerAlarmHOEvent elapses, the RNC triggers the iMCTA algorithm described in the next
chapter.
Section 10 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 16
2.4 iMCTA Triggering
2.4.3 Event Trigger : HHO based on UE Tx Power
time
UE TxPower
6A6B
timeToTrigger6B(FulleventHOConfHHOMgtEvent6B)
timeToTrigger6A(FulleventHOConfHHOMgtEvent6A)
ueTxPwrMaxThresholdOffset(FulleventHOConfHHOMgtEvent6A)
ueTxPwrMaxThresholdOffset(FulleventHOConfHHOMgtEvent6B)
isAlarmHHOUeTxPwrAllowed(RadioAccessService)
DL: P-C
PICH E
cNo/RS
CP
Primary Cell
UE Tx
Power
UE Max Tx Power
timerAlarmHoEvent6A(FullEventHOConfHhoMgt)
iMCTA Alarm
Prior to UA7:
� Alarm HHO was triggered by RNC upon reception of event 2D thus only dependent on the DL Radio
quality
UA7.1 onwards:
� UL UE Tx Power can be taken into account to evaluate the radio quality and trigger the Alarm HHO
� Feature is activated by isAlarmHHOUeTxPwrAllowed
� Benefit: avoid dropped calls when UE TX power is insufficient
� When the UE TX Power reported by the UE is above a threshold, an “alarm” Hard Handover (inter-
frequency or inter-system) is triggered in order to rescue the call on another carrier.
The actual Handover then follows the same procedures as for the Ec/No and RSCP triggers. The RNC
will configure an uplink trigger as new Alarm HHO criteria by using the internal measurements Events
6A/6B :
� 6A: The UE Tx power exceeds an absolute threshold
� 6B: The UE Tx power falls below an absolute threshold
• A HHO Alarm uplink criterion is hit when the RNC received an Event 6A AND the alarm confirmation timer
elapses without receipt of Event 6B.
• If, at expiry of the timerAlarmHoEvent6A, no event 6B (indicating that the alarm uplink conditions are
no more met) has been received, the alarm condition is confirmed, and IMCTA Alarm is invoked.
• At the opposite, if an event 6B is received while the timer is still running, the timer is stopped, and the
alarm conditions are invalidated. iMCTA Alarm is not invoked.
Section 10 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 17
2 Intelligent Multi-Carrier Traffic Allocation
2.5 iMCTA Validity Checking: Primary Cell Is Under S-RNC
SRNC DRNC
MS
Primary
AS
CN
EnabledEnabledDisabledEnabledAlarmAndService
EnabledEnabledEnabledEnabledAll
DisabledDisabledEnabledEnabledAlarmAndCAC
DisabledDisabledDisabledEnabledAlarmOnly
Alarm CAC User
Service
Mobility Service
mode
(Primary Cell)mode
SRNC
NodeB
Primary FDDCell
FddIntelligentMultiCarrierTrafficAllocation
iMCTA
Once iMCTA trigger has been identified, Validity Checking aims at determining whether this specific iMCTA
trigger is enabled on the Primary cell, through mode parameter that can have 4 different values:
� AlarmOnly to have only iMCTA Alarm enabled
� AlarmAndCac to have iMCTA Alarm and iMCTA CAC enabled
� AlarmAndService to have iMCTA Alarm and iMCTA Service enabled
� All to have all iMCTA triggers enabled
mode parameter must be set at primary cell level, i.e.:
� at FDD cell level when primary cell’s C-RNC is the Serving RNC, through
FddIntelligentMultiCarrierTrafficAllocation object (so-called FddImcta)
� at Neighbouring RNC level when primary cell’s C-RNC is a Drift RNC, through
NeighbouringRncIntelligentMultiCarrierTrafficAllocation object (so-called NeighbouringRncFddImcta)
Section 10 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 18
2 Intelligent Multi-Carrier Traffic Allocation
2.6 iMCTA Validity Checking: Primary Cell Is Under D-RNS
SRNC DRNC
MS
AS
Primary
CN
AlarmAndService
All
DisabledDisabledEnabledEnabledAlarmAndCAC
DisabledDisabledDisabledEnabledAlarmOnly
Alarm CAC User
Service
Mobility Service
mode
(Neighbour RNC)
mode
SRNC
NeighbouringRNCDRNC
NeighbouringRNCIntelligentMultiCarrierTrafficAllocation
NodeB
Primary FDDCell
neighbouringRncId
iMCTA
iMCTA Service can only be processed when the Primary cell is located on Serving RNC.
� Therefore, iMCTA Service can only be activated on FddImcta object.
� mode must be never be set to AlarmAndService or All on NeighbouringRncImcta object.
Section 10 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 19
2 Intelligent Multi-Carrier Traffic Allocation
2.7 iMCTA Validity Checking: Specific to User Service
Enabled
Disabled
Relocation
SRB+TRB->SRB+TRB
Enabled
Disabled
RAB assignment
RAB modification
RAB Release
SRB+TRB->SRB+TRB
EnabledEnabledFalse
DisabledEnabledTrue
1st RAB assignment
SRB->SRB+TRB
AO Upsize
SRB+TRB->SRB+TRB
userServiceSigToTrafficOnlyEnable
(Pimary Cell)
iMCTA User Service on
userServiceSigToTrafficOnlyEnable
SRNC
NodeB
Primary FDDCell
FddImcta
When userServiceSigToTrafficOnlyEnable parameter is set to True, iMCTA User Service is only processed consecutively to the establishment of the very first RAB, i.e. after transition from standalone SRB (DCH
3.4 or 13.6 kbps) to SRB+TRB (either CS or PS).
� Therefore, this parameter allows to limit the number of iMCTA User Service occurrence.
Section 10 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 20
2 Intelligent Multi-Carrier Traffic Allocation
2.8 iMCTA Validity Checking: Specific to Mobility Service
DisabledFalse
EnabledTrue
iMCTAMobility Service
mobilityServiceForHsxpaEnable
(Pimary Cell)
HSxPA capable UE
mobilityServiceForHsxpaEnable
mobilityServiceForNonHsxpaEnable
SRNC
NodeB
Primary FDDCell
FddImcta
DisabledFalse
EnabledTrue
iMCTAMobility Service
mobilityServiceForNonHsxpaEnable
(Pimary Cell)
non-HSxPA capable UE
When userServiceSigToTrafficOnlyEnable parameter is set to True, iMCTA User Service is only processed consecutively to the establishment of the very first RAB, i.e. after transition from standalone SRB (DCH
3.4 or 13.6 kbps) to SRB+TRB (either CS or PS).
� Therefore, this parameter allows to limit the number of iMCTA User Service occurrence.
Section 10 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 21
2 Intelligent Multi-Carrier Traffic Allocation
2.9 iMCTA Validity Checking: Specific to All Service Triggers
ServiceForTrafficSegmentationPriority
Code Color
Power Color
Iub Color
CEM Color
Worst DL Cell Color
Radio Load Color
CEM Color
Worst UL Cell Color
Worst < originatingCellColourThreshold
Yes
iMCTA Configuration Retrieval
iMCTA algorithm is stopped
PRIMARY CELL LOAD ELIGIBILITY
No
isServiceSegmentationTopPriorityAND
Primary cell NOT fully compatible
Yes
No
isServiceSegmentationTopPriority
Imcta ServiceSegmentationPriorityClass
FDDCellFDDImcta
OriginatingCellColourThresholdConfClass 1…5
OriginatingCellColourThresholdperservice 1…12
originatingCellColourThresholdoriginatingCellColourThreshold
confclassref
The cell load information is needed for iMCTA to state whether the Primary cell is eligible or not to iMCTA
Service.
Comparing Primary cell iMCTA colour with originatingCellColourThreshold is systematically performed by iMCTA Service, for load balancing purpose but also for traffic segmentation (which is based on UE and
NodeB HSxPA capabilities).
� If operator’s priority is to perform traffic segmentation rather than load balancing,
originatingCellColourThreshold must be set to Green so as to systematically go further in the
algorithm, whatever Primary cell load.
Hence, in UA5, it was impossible to have Load Balancing and Service Segmentation fully coexisting because
the former needs to have HHO only triggered when the cell is loaded whereas the latter needs to have
HHO triggered whatever cell load.
In UA06.0, such limitation is removed thanks to the introduction of isServiceSegmentationTopPriority, a new flag defined per serviceType, which allows to bypass originatingCellColourThreshold during iMCTAValidity checking, as presented hereafter.
NAMING CONVENTIONS
� Cell fully compatible with UE capabilities
� HSUPA cell and HSUPA UE
� HSDPA cell and HSDPA UE
� R99 cell and R99 UE
� Cell partially compatible with UE capabilities
� HSUPA (resp. HSDPA) cell and HSDPA (resp. HSUPA) UE
� Cell NOT compatible with UE capabilities
� HSxPA cell and R99 UE
� R99 cell and HSxPA UE
Section 10 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 22
2 Intelligent Multi-Carrier Traffic Allocation
2.10 iMCTA Configuration Retrieval: Alarm Priority Table
priority priority priority
P3P3P3P3P3P3FDD2
P2
P1
PsStreaming
P2
P1
PsIb
P2
P1
CsSpeechPlusOther
P2PNAP12G
P1P2P2FDD1
CsSpeech
CsConversational
CsStreaming
Alarm priority Table
Service Type
Access Type
RNC
RadioAccessService
Imcta
AlarmPriorityTableConfClass
Access/2G Access/FDD1
Service/CsSpeech Service/PsIb Service/CsSpeech
NodeB
Primary FDDCell
FddImctaalarmPriorityTable
ConfClassId
Primary Cell under S-RNC
Access/FDD2
Once it has been checked that the invoked iMCTA trigger is enabled for the Primary cell, iMCTAConfiguration Retrieval aims at selecting the Priority Table to be used.
Priority Table is an important concept in iMCTA which must be associated with ServiceType (ST) and Priority.
� Each DlUserService is associated to a type of the service among the 8 possible values: CsSpeech, CsConversational, CsStreaming, PsStreaming, PsIb, CsSpeechPlusOther, PsConversational, None.
� The following rule applies for Multi-Service DlUserService:
� CS speech + any PS: CsSpeechPlusOther
� CSD conversational + any PS I/B: PsIb (this allows HSxPA capable mobiles to have HSxPAthroughput)
� Any PS streaming + any PS I/B: PsIb (this allows to prevent abusive inter-frequency HHO after PS streaming establishment as PS I/B is likely to be established first to support signaling dedicated to Streaming applications)
� SRB only or SRB+TRB on FACH: None
� An iMCTA Priority table defines for a specific iMCTA Trigger (Alarm, CAC or Service) and for each ST a priority level to be applied on the different FDD and GSM neighbouring cells.
� Prior to UA7 GSM and FDD access types must have different priority for the algorithm to decide which Access to measure.
From UA7 onwards GSM and FDD access types can be set to the same priority. Then simultaneous GSM and FDD measurements are used if neighbours of both access types are applicable. This also requiressetting isSimCMAllowed to TRUE for given UL and DL user Services.
� From UA7 onwards up to 6 FDD Carriers are supported for Alarm and CAC
When iMCTA Alarm is triggered, the algorithm retrieves the AlarmPriorityTable that is pointed either by FddImcta or NeighbouringRncImcta object, depending on the Primary cell location.
From UA7 onwards up to 6 FDD Carriers are supported for Alarm and CAC
Section 10 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 23
2 Intelligent Multi-Carrier Traffic Allocation
2.11 iMCTA Configuration Retrieval: CAC Priority Table
priority priority priority
P3P3P3P3P3P3FDD2
P2
P1
PsStreaming
P2
P1
PsIb
P2
P1
CsSpeechPlusOther
P2PNAP12G
P1P2P2FDD1
CsSpeech
CsConversational
CsStreaming
CAC priority Table
Service Type
Access Type
RadioAccessService
Imcta
CacPriorityTableConfClass
Access/2G Access/FDD1
Service/CsSpeech Service/PsIb Service/CsSpeech
cacPriorityTableConfClassId
NeighbouringRNC
NeighbouringRNCImcta
RNC
Primary Cell under D-RNC
Access/FDD2
Since iMCTA CAC has been triggered, the algorithm retrieves the CacPriorityTable that is pointed either by
FddImcta or NeighbouringRncImcta object, depending on the Primary cell location.
Prior to UA7 GSM and FDD access types must have different priority for the algorithm to decide which Access to measure.
From UA7 onwards GSM and FDD access types can be set to the same priority. Then simultaneous GSM and FDD measurements are used if neighbours of both access types are applicable. This also requires setting
isSimCMAllowed to TRUE for given UL and DL user Services.
From UA7 onwards up to 6 FDD Carriers are supported for Alarm and CAC
Section 10 � Module 1 � Page 24
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 24
2 Intelligent Multi-Carrier Traffic Allocation
2.12 iMCTA Configuration Retrieval: Service Priority Tables
priority
P2P3P3P3PNAP12G
P1
P1
PsStreaming
P1
P2
PsIb
P1
P1
CsSpeechPlusOther
P2P2P2FDD1
P1P1P3FDD2
CsSpeech
CsConversational
CsStreaming
Service priority Table
RadioAccessService
Imcta
ServicePriorityGeneralTableConfClass
Service/CsSpeech
FddImctaservicePriorityGeneral
TableConfClassId
servicePriorityTableForHsdpaConfClassId ServicePriorityTableForHsdpaConfClass
ServicePriorityTableForHsupaConfClass
Frequency /FDD2Frequency/2G Frequency /FDD1 Frequency /FDD3 Frequency /FDD4
servicePriorityTableForHsupaConfClassId
priority
Service/PsIb
Since iMCTA Service can only been triggered when Primary cell is located on Serving RNC, the algorithm can
retrieve up to 3 Priority tables that are pointed by FddImcta object:
� ServicePriorityGeneralTable
� ServicePriorityTableForHsdpa (optional object)
� ServicePriorityTableForHsupa (optional object)
The selection of the right Service Priority Table is based on UE’s HSxPA-capabilities sent in the RRC
Connection Setup Complete message.
� If UE is HSUPA-capable ServicePriorityTableForHsupa is retrieved if present
� Otherwise ServicePriorityTableForHsdpa if present
� Otherwise ServicePriorityGeneralTable
� If UE is HSDPA-capable ServicePriorityTableForHsdpa is retrieved if present
� Otherwise ServicePriorityGeneralTable
� If UE is not HSDPA-capable nor HSUPA-capable ServicePriorityGeneralTable is retrieved
Prior to UA7 for each ST, there must not be any common priority between one FDD frequency and one GSM frequency.
From UA7 onwards GSM and FDD access types can be set to the same priority. Then simultaneous GSM and FDD measurements are used if neighbours of both access types are applicable. This also requires setting
isSimCMAllowed to TRUE for given UL and DL user Services.
From UA6, up to 6 FDD frequencies can be provisioned, for instance 4 UMTS 2100 and 2 UMTS 900.
Section 10 � Module 1 � Page 25
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 25
2 Intelligent Multi-Carrier Traffic Allocation
2.13 iMCTA Configuration Retrieval: Service HO Option
P22G
P1FDD1
P3FDD2
CsSpeech
Service priority Table if Service Type = Cs Speech and Service Handover = should
RNCCN RAB Assignment Request
Service Handover IE
should GSM priority = P0
shall not GSM priority = PNA
should not GSM priority = P6iMCTA Service
GSM priority = unchangediMCTA Alarm or CACRadioAccessService
Imcta
RNC
serviceHoRanapIeEnable
P0
isChangeGsmIratHoCriterionAllowed
Service Handover option allows CS and PS Core Networks to inform UTRAN that GSM is preferred for this
service, through the optional serviceHO Information Element (IE) which is present in RANAP RAB
Assignment Request message.
� Based on the 3 different values that ServiceHo IE can have (if present), iMCTA algorithm may
dynamically change the GSM priority in the Priority table:
� IE = should: GSM priority is overwritten with P0, i.e. GSM becomes the most preferred target Access
� IE = should not: GSM priority is overwritten with P6, i.e. GSM becomes the less preferred target Access
� IE = shall not: GSM priority is overwritten with PNA, i.e. GSM is no more eligible to target Access.
� The processing of this optional IE is not systematic and can be enabled/disabled through
serviceHoRanapIeEnable parameter.
� “should not” is never taken into account when iMCTA Alarm or iMCTA CAC are triggered.
Section 10 � Module 1 � Page 26
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 26
2.13 iMCTA Configuration Retrieval: Service HO Option
2.13.1 Non mono-CS RAB case
RNCCN
should
should→→→→
GSM Prio=P0
should not����
GSM Prio=P6RadioAccessService
Imcta
RNC
serviceHoRanapIeEnable
isChangeGsmIratHoCriterionAllowed
isChangeGsmIratHoCriterionAllowedAND
PS call already establishedOR
A new PS Call request received from SGSNOR
Inactive PS Call (PS0/0) gets active
RAB Assignment Request CSService Handover IE
Yes
No
The Service Handover option can be used for load distribution by preferring the GSM layer for CS calls using
the "should" option. GSM can provide similar service for CS calls as UMTS and therefore it might be a good
idea to handover CS call to a less loaded GSM system. If, however, the UE has a simultaneous PS call then
the UE should be kept in UMTS to allow for simultaneous CS and PS calls, which is not supported in GSM
by most GSM networks and UEs.
The MSC, which is responsible for setting the Service Handover option for CS calls, has no information
whether the UE has a single CS call or the CS call is combined with a PS session. If the MSC sets the
"should" option and UTRAN prefers the GSM layer then a simultaneous PS call gets suspended in case of
handover to GSM. Alcatel-Lucent UTRAN has implemented the option to make the Service Handover
decision dependent on the availability of a PS call. If parameter isChangeGsmIratHoCriterionAllowed is set to True, the UE has a CS call with Service Handover set to "should" and the UE has a simultaneous PS
call then UTRAN internally changes the Service Handover option from "should" to "should not". With this
the call is preferably kept in UMTS. Alarm handover to GSM is still possible.
Section 10 � Module 1 � Page 27
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 27
2 Intelligent Multi-Carrier Traffic Allocation
2.14 iMCTA: Inter-Freq & Inter-RAT CNL Computation (Type1)
typeOfCompoundingNeighbourListInterFreqtypeOfCompoundingNeighbourListInterRat
Type1
New RRC MC message for inter-freq/Inter-Rat meas.
OR
Primary Cell Change*
OR
Active Set Update*
(*) While ongoing inter-freq measurements
� For each sponsoring cell, build a neighbouring list ordered by neighbourCellPrio� Build the final inter-frequency (or Inter-Rat) neighbouring list as follows:
1. Add the sponsoring cells2. Select the N first cells (with N stand for numOfPrimaryCellNeighbourInterFreq
(or numOfPrimaryCellNeighbourInterRAT)) from Primary Cell's neighbouring list
3. Then perform the selection by number of occurrence
1. In case of conflict, select:
1. the one whose sponsoring cell has the highest Ec/No
2. then the one with highest neighbourCellPrio
4. Build the Compound Neighbour Lits until (maxCompoundingListSizeInterFreq(or maxCompoundingListSizeInterRAT)) is reached.
UA5:
In UA5 release, the implementation for inter-frequency neighbour lists and inter-RAT neighbour list was based on the neighbour list of the primary cell, only. Compounding neighbour list is support for Intra-frequency cells.
UA6:
With this feature introduced, the operator is able to select, with the parameters typeOfCompoundingNeighbourListInterFreq and typeOfCompoundingNeighbourListInterRat, the compounding neighbour list algorithm for interFreq and interRAT neighbouring cells.
Feature principles
The ALU RNC will compute Inter-Freq neighbour list in case of:
� A new RRC Measurement Control message needs to be sent to the UE for inter-frequency measurements.
� On change of the primary cell or on active set update while an inter-frequency measurement is ongoing.
The ALU RNC will compute Inter-RAT neighbour list in case of:
� A new RRC Measurement Control message needs to be sent to the UE for inter-RAT measurements.
The Compounding Neighbour List algorithm considers:
� Occurrence of a cell within all neighbourhoods
� Measured quality of the sponsoring active set cell
� Priority defined per neighbouring cell
Section 10 � Module 1 � Page 28
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 28
2.14 iMCTA: Inter-Freq & Inter-RAT CNL Computation (Type1)
2.14.1 Inter-FREQ example
Cell13
Cell14
Cell11
Cell12
Cell17
Cell18
Cell19
Cell51
Cell16
Cell15
Cell27
Cell24
Cell25
Cell26
Cell23
Cell22
Cell21
Cell53
Cell52
Cell51 Cell34
Cell33
Cell32
Cell31
Cell53
Cell52
Cell55
Cell54
Cell39
Cell38
Cell37
Cell36
Cell35
Cell54
Cell55
Cell41
Cell42
Cell43
Cell44
Cell49
Cell48
Cell47
Cell46
Cell45
Common numberof occurrence
Cell1 Cell2 Cell3 Cell4
Cell27
Cell32
Cell31
Cell26
Cell23
Cell24
Cell17
Cell18
Cell19
Cell15
Cell16
Cell54
Cell55
Cell52
Cell53
Cell51
Cell11
Cell12
Cell13
Cell14
Cell25
Cell22
Cell21
Type1
numOfPrimaryCellNeighbourInterFreq
Neighbouring cells with highest occurrence
maxCompoundingListSizeInterFreq
Sponsoring cells 1 to 4 are ordered by EcNoCell1 > Cell2 > Cell3 > Cell4
Cell1 is assumed to be the Primary Cell
Neighbouring cells with lower occurrence
Section 10 � Module 1 � Page 29
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 29
2.14 iMCTA: Inter-Freq & Inter-RAT CNL Computation (Type1)
2.14.2 Inter-RAT example
Cell13
Cell14
Cell11
Cell12
Cell17
Cell18
Cell19
Cell51
Cell16
Cell15
Cell27
Cell24
Cell25
Cell26
Cell23
Cell22
Cell21
Cell53
Cell52
Cell51 Cell34
Cell33
Cell32
Cell31
Cell53
Cell52
Cell55
Cell54
Cell39
Cell38
Cell37
Cell36
Cell35
Cell54
Cell55
Cell41
Cell42
Cell43
Cell44
Cell49
Cell48
Cell47
Cell46
Cell45
Common numberof occurrence
Cell1 Cell2 Cell3 Cell4
Cell27
Cell32
Cell31
Cell26
Cell23
Cell24
Cell17
Cell18
Cell19
Cell15
Cell16
Cell54
Cell55
Cell52
Cell53
Cell51
Cell11
Cell12
Cell13
Cell14
Cell25
Cell22
Cell21
numOfPrimaryCellNeighbourInterRAT
Neighbouring cells with highest occurrence
maxCompoundingListSizeInterRAT
Sponsoring cells 1 to 4 are ordered by EcNoCell1 > Cell2 > Cell3 > Cell4
Cell1 is assumed to be the Primary Cell
Neighbouring cells with lower occurrence
Type1
Section 10 � Module 1 � Page 30
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 30
2 Intelligent Multi-Carrier Traffic Allocation
2.15 Neighboring Cells Searching and Filtering: Generic
CompoundedNeighboring
List
Remove neighboring cells
of Access or Frequency marked as PNAIn Priority Table
Remove neighboring cells of GSM bands not supported
by UE
Remove neighboring cells
Inter-RAT and Inter-Freq If CM disable for this DlUserService
and UE is mono-receiver
RadioAccessService
DlUserService
isGsmCModeActivationAllowed
isInterFreqCModeActivationAllowed
GenericFiltering
Once the Priority table has been retrieved for the selected Service Type, Neighbouring Cell Searching and
Filtering aims at filtering the inter-frequency and inter-RAT neighbourhood so as to eventually keep the
cells:
� Belonging to an authorized PLMN
� Compatible with the retrieved Priority Table
� i.e. neighbouring cells whose Access is PNA are removed
� Compatible with GSM bands supported by UE
� Compatible with Compressed Mode capabilities:
� UE’s capabilities sent in RRC Connection Setup Complete message
� CM activation flags per DlUserService
isGsmCModeActivationAllowed Indicates if compressed mode for GSM is allowed for this DlUserService
� isInterFreqCModeActivationAllowed must be set to True for all DlUserServices
isInterFreqCModeActivationAllowed Indicates if compressed mode for inter-frequency is allowed for this DlUserService
� isGsmCModeActivationAllowed must be set to True for all DlUserServices except for the RABs that are
not supported in GSM, i.e. CSD64.
� With such setting, selecting UMTS or GSM as target Access is only based on iMCTA Priority tables.
Section 10 � Module 1 � Page 31
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 31
2 Intelligent Multi-Carrier Traffic Allocation
2.16 Neighboring Cells Searching and Filtering: Specific
CompoundedNeighboring
List
GenericFiltering
iMCTA Alarm
CompoundedNeighboring
List
GenericFiltering
Removeneighboring cells
of D-RNC
iMCTA CAC
CompoundedNeighboring
List
GenericFiltering
Removeneighboring cellsof lower Prioritythan Primary Cell
iMCTA Service
As per 3GPP, neither the relocation procedure nor the RNSAP RL addition procedure supports the Transport
Channel addition/deletion. Therefore, for iMCTA CAC, every neighbouring cell belonging to another RNC
are removed.
For iMCTA Service, unlike iMCTA Alarm and iMCTA CAC, the neighbouring cells whose priority is worse than the Primary cell’s are removed.
Section 10 � Module 1 � Page 32
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 32
2 Intelligent Multi-Carrier Traffic Allocation
2.17 RAT Selection
CompoundedNeighboring
List
Keepneighboring cells
of same RATas highest Priority neighboring cell RAT
FDD Cell Fa P2FDD Cell Fb P2FDD Cell Fc P2GSM Cell Ga P1GSM Cell Gb P1
GSM Cell Ga P1GSM Cell Gb P1
iMCTA Alarm
RAT selectedIs 2G
Example 1
FDD1 Cell Fa P1FDD1 Cell Fb P1FDD2 Cell Fc P2FDD3 Cell Fd P1GSM Cell Ga P3GSM Cell Gb P3
FDD1 Cell Fa P1FDD1 Cell Fb P1FDD2 Cell Fc P2FDD3 Cell Fd P1
iMCTA Service
RAT selectedIs 3G
Example 2
Prior to UA7:
� Once the neighbourhood has been filtered, this function aims at determining the target Access by
simply considering the cell with the highest Priority.
� It shows how important is the rules stating that:
� GSM and UMTS priority parameters must be different for iMTCA Alarm and iMCTA CAC
� there must not be any common priority parameter value between one FDD frequency and one GSM frequency for iMCTA Service
From UA7 onwards:
� If GSM and FDD access types are set to the same priority then simultaneous GSM and FDD measurements are used if neighbours of both access types are applicable.
� This also requires setting isSimCMAllowed to TRUE for given UL and DL user Services else RNC will usesingle CM pattern based on is3GHandoverPreferred value. RNC will also select a target system based
on this parameter in case combined measurement report from the UE contains cells that are eligible for
HHO from both target layers.
In case the neighbouring cell list is empty:
� 2G Blind HO is performed if provisioned for iMCTA Alarm (call drop avoidance)
� 2G Blind HO is NOT performed even if provisioned for iMCTA CAC and iMCTA Service
Section 10 � Module 1 � Page 33
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 33
2.17 RAT Selection
2.17.1 Same Priority for 2G and FDD Layer
P2P2P2P2P1P2FDD2
P2
P1
PsStreaming
P1
P1
PsIb
P1
P1
CsSpeechPlusOther
P2PNAP12G
P1P2P1FDD1
CsSpeech
CsConversational
CsStreaming
Alarm priority Table
Service Type
Access Type
� Starting UA7 Simultaneous measurements can be activated by RNC thus setting the same priority for 2G and FDD Layers is now allowed
RadioAccessService
UlUserService
isSimCMAllowed
DlUserService
isSimCMAllowed
RNC
By measurement of both target access types the risk of call drop in case of alarm handover is reduced.
Section 10 � Module 1 � Page 34
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 34
2 Intelligent Multi-Carrier Traffic Allocation
2.18 Load Based Inter-FDD Layer Filtering
Code Color
Power Color
Iub Color
CEM Color
Worst DL Cell Color
Radio Load Color
CEM Color
Worst UL Cell Color
Worst
If True for at leastone cell of the layer
Layer removed from the measurement
configuration
Target Cell Load
Layer remains a candidate for measurements
isImctaFDDLayerLoadPreCheckAllowed
(RadioAccessService)= True
isImctaLoadBasedAllowed
(RadioAccessService)
(isImctaLoadBasedAllowed = True AND Color better than ImctaLoadBasedTargetCellColorThreshold)
OR
(isImctaLoadBasedAllowed = False ANDColor better than targetCellColourThreshold)
If False for all cells on the layer
ImctaLoadBasedTargetCellColorThresholdtargetCellColourThreshold
From UA7.1 onwards, a load-based criterion for iMCTA on target cells can be used to choose and filter all
inter-frequency cells before selecting the access type for measurement. This mechanism intends to avoid
triggering measurements for overloaded access layers.
For UA7.1 criterion may be activated/deactivated for all types of iMCTA by using parameter
isImctaFddLayerLoadPreCheckAllowed.
An FDD cell of a given carrier may be removed from the monitored inter frequency cell list only if all FDD
cells of this carrier don’t fulfil the target cell load criteria.
Section 10 � Module 1 � Page 35
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 35
2 Intelligent Multi-Carrier Traffic Allocation
2.19 Measurement Configuration
RRC Measurement Control
CM activation+
NodeB UE
Neighboring Cells
Inter-RATand/or
Inter-Freq
CNL Interfreq FDD’s and CNL Inter Rat Processed and sent to UE
No
FDD & GSM to measure?
Yes
CNL of the RAT with the highest priority will be processed and sent to UE
Once target Radio Access has been selected, Measurement Configuration setup Inter-frequency or GSM
measurements at NodeB and UE sides, by respectively sending NBAP Compressed Mode Command and RRC
Measurement Control messages.
� In UA5, like in UA4.2, the alarm measurement results are reported in periodic mode.
� The only difference is that:
� In periodic mode : Inter-Freq/Inter-RAT are declared as additional measurements reported in the
same RRC measurement reports than Intra-Frequency
� In event mode: new measurements are configured to report Inter-Frequency/Inter-RAT
measurements (Intra-Frequency measurement are not impacted and still reported in event-triggered
mode)
� From UA7 onwards the UE can measure both target access types. Measurements are started together. If
inter-frequency access type has sufficient coverage then the UE usually reports inter-frequency first
because GSM BSIC confirmation takes longer time. The RNC uses the first reported target cell for
handover attempt. Thus, typically inter-frequency target is preferred.
The UE is requested to report up to 6 neighboring cells amongst the monitored set.
� The monitored set is defined as the set of FDD inter-frequency or GSM neighbors of the primary cell
provided to the UE through the MEASUREMENT CONTROL message.
Section 10 � Module 1 � Page 36
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 36
2.19 Measurement Configuration
2.19.1 CM Scope & Methods
Inter-frequency measurements
Inter-RAT measurements
Transmission Gap Length = 3, 4, 7, 10, 14 TS
power
time
idle
TGL
frame N-1 frame N+1
power
time
idle
TGL
frame N-1 frame N+2idle
frame boundary
ulCModeMethod (CmodePatternSeqInfo)dlCModeMethod (CmodePatternSeqInfo)
Single-Frame Mode
Double-Frame Mode
Compressed Mode consists of the creation of regularly spaced short gaps (less than one 10 ms radio frame)
in transmission in the uplink or downlink, or possibly both at the same time, and/or reception without
altering the data to be exchanged on the radio interface.
Compressed Mode is mandatory in downlink and optional in uplink. It can only be achieved on dedicated
channels. The Transmission Gap Length is 3, 4, 5, 7, 10 or 14 slots.
Three methods are proposed in the standard: Spreading Factor Reduction, Puncturing and Higher Layer
Scheduling.
� Only the Spreading Factor Reduction method is implemented for both UL and DL (when needed) for
either GSM or FDD inter-frequency measurements.
� Thus, only the value cmodeDlMethodSfDiv2 is allowed for DlCmodeMethod and UlCmodeMethod Two methods can be used for time transmission reduction:
� The SF can be reduced by 2 to permit the transmission of the information bits in the remaining time
slots of the compressed frame. In that case, the scrambling code could be different from normal
mode.
Section 10 � Module 1 � Page 37
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 37
2.19 Measurement Configuration
2.19.2 Need for Compressed Mode
• Dual receiver UE?• Mono Receiver UE?• GSM compatible UE?
UMTS
UMTS
GSM
GSM450Present (RadioAccessService)
GSM480Present (RadioAccessService)
GSM850Present (RadioAccessService)
GSM900PPresent (RadioAccessService)
GSM900EPresent (RadioAccessService)
GSM900RPresent (RadioAccessService)
GSM1800Present (RadioAccessService)
GSM1900Present (RadioAccessService)
UE Cap
ability
isInterFreqMeasActivationAllowed
(RadioAccessService)
isInterFreqCModeActivationAllowedisGsmCModeActivationAllowed:
(DlUserService)
The real need for Compressed Mode is provided by the UE itself. Following a network request through the
UE Capability required indicator in the RRC Connection Setup message, the UE indicates in the UE Radio
Access Capability IE (Measurement Capability sub-IE, provided in the RRC Connection Setup Complete
message) if Compressed Mode is needed in either UL or DL for the FDD and GSM bands.
The network configure and activate the Compressed Mode in 3 possible modes:
� Uplink only
� Downlink only
� Uplink and Downlink
Therefore, regarding CM for GSM, in order not to configure compressed mode in every case, a set of flags
indicating the frequency bands of the FDD and GSM neighboring cells will be defined and used in the RNC
to determine whether or not Compressed Mode is needed.
Each flag indicates that there exists at least a GSM cell of the corresponding frequency band in the access
network (that is, not only being part of the GSM neighboring lists seen by the RNC) to which handovers
from a 3G cell are supported by the network. Therefore, if Compressed Mode is needed by the mobile for
that frequency band, it will be configured accordingly and possibly activated by the network.
Section 10 � Module 1 � Page 38
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 38
2.19 Measurement Configuration
2.19.3 High-Level Scheduling Method
starting CFN TGL
Dl(ul)CModeMethod (CModePatternSeqInfo)
CmodeDl(Ul)MethodSfdiv2
isHlsCmMethodPreferred (D/UlUserService)
?False
True
RLC
MAC
Physical Layer
Subset of allowedTFCs are used incompressed frame
The Spreading Factor Reduction method consists of the creation of gaps in transmission / reception and
granting twice the bandwidth for compressed frames in order to compensate for the loss of bandwidth in
not transmitted frames. This method applies for both uplink and downlink with fixed or flexible position
mapping but it requires that the spreading factor be strictly greater than 4.
The SF is reduced by a factor two for as many slots as used for gaps and the transmitted power of these
slots is increased. Thus OVSF code need to be changed, the new one is the parent code of the code used
for non-compressed radio frames.
In the downlink, the scrambling code management is done through the alternate scrambling code method.
This method consists of applying the new channelization code with SF/2 to the compressed frames, while
applying one of the two available alternate scrambling codes (left or right alternative) depending on the
original OVSF.
The figure above gives an example of how this method applies.
In the uplink, the compressed mode method by spreading factor reduction is identical to the spreading
factor reduction used in the downlink but with some exceptions.
HLS introduced from 3GPP R99
� Data rate is reduced from higher layers (i.e. MAC) by means of TFC restriction in the TFCS
� SF and scrambling code remain unchanged
� No additional power transmission to keep the same level of protection of the user bit
� Applicable either in UL only, DL only, or both UL/DL
Prior to UA6, only SF/2 method was supported, whatever RAB, and CM method was uniquely defined using
dlCModeMethod and ulCModeMethod parameters under CModePatternSeqInfo object.
In UA6, HLS has been introduced and is supported for some specific UL and/or DL User Services. Therefore,
the previous parameters are not used anymore and are replaced by isHlsCmMethodPreferred parameter defined per DlUserService and UlUserService.
Parameters defined under CmodePatternSeqInfo, are not used anymore. However, they are still present in RAN Model and will be removed in the coming releases.
Section 10 � Module 1 � Page 39
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 39
2.19 Measurement Configuration
2.19.4 HLS Activation
RadioAccessService
dlCModeMethod [not used; replaced by DlUserService.isHlsCmMethodPreferred]
ulCModeMethod [not used; replaced by UlUserService.isHlsCmMethodPreferred]
dlFrameType [not used; hard-coded with typeA for HLS and typeB for SF/2]
DlUserService
NeighbouringRnc
Parameter not used anymorebut still present in RAN Model
RNC
UlUserService
CmodePatternSeqInfo
isHlsCModeAllowed isHlsCmAllowedOnDrnc
isHlsCmMethodPreferred
isHlsCmMethodPreferred
- PS I/B (mono or MUX) > 8kbps
- CS speech + (PS I/B > 16kbps)
- CSD64 + (PS I/B > 64kbps)
- (PS str > 64kbps) + (PS I/B > 32kbps) With or without CS speech
-Any other PS combination over DCH with SF=4
In UA06.0 implementation, HLS is limited to only certain combinations
� PS I/B (mono or MUX) > 8kbps
� CS speech + (PS I/B > 16kbps)
� CSD64 + (PS I/B > 64kbps)
� (PS str > 64kbps) + (PS I/B > 32kbps) with or without CS speech
� Any other PS combination over DCH with SF=4
SF/2 method is used for the remaining User Services, mostly:
� Standalone SRB, CS speech, CSD, PS streaming (with or without CS speech)
All RAB combinations over HSDPA or E-DCH (for which HLS is in restriction)
� This restriction should be removed in UA7
Patterns are the same for SF/2 and HLS methods
CM method is determined at each RAB addition, deletion or reconfiguration
� Sent to UE and NodeB at CM configuration
� NBAP RlSetup/Reconf and RRC RadioBearerSetup/Reconf/Release
� Based on RNC and NeighbouringRnc activation flags
� isHlsCModeAllowed under RadioAccessService
� isHlsCmAllowedOnDrnc under NeighbouringRnc
� Reconfiguration to SF/2 when not supported/allowed on DRNC
� Based on operator's strategy
� isHlsCmMethodPreferred defined per DlUserService and UlUserService
� When selecting a CM method, RNC checks isHlsCmMethodPreferred with respect to the method(s)
supported in UA06.0 by this UserService
� Hardcoded in RNC for each UserService (SF2, HLS, SF2ANDHLS or N/A)
Section 10 � Module 1 � Page 40
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 40
2.19 Measurement Configuration
2.19.5 CM Pattern Sequences
Sub-pattern 1 Sub-pattern 2 Sub-pattern 1 Sub-pattern 2 Sub-pattern 1 Sub-pattern 2
#1 #2 #TGPRC
#TGCFN
Gap1 Gap2 Gap1 Gap2
tgsn
tgl1 tgl2 tgl1 tgl2
tgd tgd
tgpl1 tgpl2
tgprc (CModePatternSeqInfo)tgcfnOffset (CModePatternSeqInfo)
Compressed Mode is controlled by the UTRAN: it is configured by the RNC on a per UE basis in the form of
Compressed Mode Transmission Gap Pattern Sequences. A CM pattern sequence may be composed of up
to two sub-patterns and is dedicated to one specific measurement purpose.
Each pattern is described by the parameters listed below, those parameters being defined at the cell level:
� TGL1 and TGL2: length of transmission gaps 1 and 2 expressed as a number of slots. Possible values are
3, 4, 5, 7, 10 and 14. TGL2 is an optional parameter and if a value is not given by the upper layers,
then by default TGL2 = TGL1,
� TGSN: the first gap occurs TGSN slots after the beginning of the pattern,
� TGD: the two gaps are separated by a distance of TGD slots,
� TGPL1 and TGPL2: length of pattern 1 and 2 expressed in radio frames,
� TGCFN: CM start expressed in CFN as CFNx + TgcfnOffset) mod[256],
� TGPRC: number of times the Transmission Gap Pattern is repeated within the Transmission Gap Pattern
Sequence.
Section 10 � Module 1 � Page 41
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 41
2.19 Measurement Configuration
2.19.6 Pattern Sequence Configuration
A pattern sequence is defined for each type of measurement
CmodePatternSeqInfo
isPatternAllowed = TrueTgmp = 2 TgcfnOffset = 0Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 8Tgsn = 8
CmodePatternSeqInfo/0
isPatternAllowed = TrueTgmp = 2 TgcfnOffset = 0Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 8Tgsn = 8
CmodePatternSeqInfo [1]
isPatternAllowed = TrueTgmp = 3 TgcfnOffset = 48Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 78Tgsn = 8nIdentifyAbort = 26
CmodePatternSeqInfo/1
isPatternAllowed = TrueTgmp = 3 TgcfnOffset = 48Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 78Tgsn = 8nIdentifyAbort = 26
CmodePatternSeqInfo [2]
isPatternAllowed = TrueTgmp = 1 TgcfnOffset = 0Tgd = 0Tgl1 = 10Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 50Tgsn = 10
CmodePatternSeqInfoCmodePatternSeqInfo/2
isPatternAllowed = TrueTgmp = 1 TgcfnOffset = 0Tgd = 0Tgl1 = 10Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 50Tgsn = 10
GSM RSSI measurement
BSIC identification
FDD measurements
RadioAccessService
A certain number of pattern sequences can be defined in UTRAN configuration, each of them being
associated with a specific measurement purpose.
The pattern sequence is defined by a set of parameters (transmission GAP and CM patterns parameters),
that are grouped into the CModePatternSeqInfo object:
� Instance 0 of CmodePatternSeqInfo corresponds to a Compressed Mode measurement purpose GSM RSSI
Measurements.
� Instance 1 of CmodePatternSeqInfo corresponds to a Compressed Mode measurement purpose GSM
Initial BSIC Identification.
� Instance 2 of CmodePatternSeqInfo corresponds to a Compressed Mode measurement purpose FDD
Inter-Frequency Measurement.
Section 10 � Module 1 � Page 42
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 42
2.19 Measurement Configuration
2.19.7 FDD Inter-Freq CM Pattern
6 Frames (60 ms)
50 Patterns (3000 ms)
10 Time Slots 70 Time Slots
Gap = 10 Time SlotsCFN + 0
For FDD inter-frequency measurement, a single pattern of 6 frames repeated 50 times is used, leading to a
basic compressed mode measurement period of 3 s.
The UE is provided with the FDD neighboring cell list, when receiving the RRC Measurement Control
message. Using this list, the UE starts the CPICH_RSCP and CPICH_Ec/No measurements process that can
be seen as a sort of endless loop, intending to identify the best neighboring cells.
Measurements results are sent to the RNC with periodical measurement reports.
Section 10 � Module 1 � Page 43
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 43
2.19 Measurement Configuration
2.19.8 GSM Inter-RAT CM Pattern
6 Frames (60 ms)
8 Patterns (480 ms)
8 Time Slots 68Time SlotsGap = 14 Time Slots
CFN + 0
CFN + 48
78 Patterns (4680 ms)
RSSI BSIC
In the case of GSM initial BSIC identification, the UE is to take the results of the most recent set of GSM
RSSI samples and attempt to identify the BSICs of the 8 strongest cells, proceeding in single strength
order.
It has to be noted that the time required for a measurement report is essentially dictated by the time
required to identify the BSICs of the required number of cells. As a consequence, it is better to choose
the compressed mode patterns for this operation first and then build the patterns for GSM RSSI
measurements around this pattern.
That’s the reason why:
� a transmission gap shorter that 14 has been chosen in order to allow good performance on BSIC
identification
� 8 patterns of 6x10ms have been allocated to RSSI measurements since the measurement period for
the GSM carrier RSSI measurement is 480 ms in the CELL_DCH state (as stated in �[3GPP_R01])
� 3x26 patterns have been allocated to initial BSIC identification in order to allow a minimum of 3 cells
to be reported in the worst case (e.g. when it takes up to nIdentifyAbort to identify each cell).
Section 10 � Module 1 � Page 44
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 44
2 Intelligent Multi-Carrier Traffic Allocation
2.20 Measurement Report Processing (MRP)
Measurement Report
Measurement Report
NodeBUE
• GSM Carrier RSSI
• Observed time difference to GSMCell
• Verified BSIC
• CPICH Ec/No
• CPICH RSCP
MeasurementID
MeasurementReportingQuantity
MeasurementResults
6 Best Monitored Set cells
Inter-RAT and/or
Inter-Freq
6 Best Monitored cells
maxCellsRepType (static)
interFreqFilterCoeff
rrcIntraFreqMeasurementReportingPeriodrrcGsmMeasurementFilterCoeff
MeasurementConfClass
InterFreqMeasConf
RRCMeasurement
Section 10 � Module 1 � Page 45
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 45
2.20 Measurement Report Processing (MRP)
2.20.1 Preferred Layer
FDD And GSMEligible Cells?
is3GHandoverPreferred
(FDDCell)
3G Cells only are kept as
candidates followed by a
filtering then an InterFreq
HHO attempt
TrueYes
GSM Cells only are kept as
candidates followed by a
filtering then a HHO attempt to
GSM
False
No
Compressed mode
measurements will
continue
FDD or GSM
Eligible Cells?
No
FDD Cells
GSM
Cells
If simultaneous compressed mode is requested but not possible then the RNC uses single compressed mode
as per parameter is3GHandoverPreferred.
Hence it specifies whether to perform inter-Frequency (3G) or inter-RAT (2G) measurements in case RAB
combination or NodeB does not support simultaneous CM patterns.
is3GHandoverPreferred = TRUE will also result in choosing FDD cell as target if measurement report contains eligible cells from both 2G and FDD. Consequently more traffic will handover to other FDD
layer(s).
Section 10 � Module 1 � Page 46
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 46
2.20 Measurement Report Processing (MRP)
2.20.2 iMCTA Alarm or CAC : Inter-Freq case
neighbouringCellOffset
FDD cells Eligibility
For each FDD carrier
keep the cell with highest
CPICH_Ec/No + CIO
Filtering on HSxPA capabilities
for iMCTA Alarm or CAC
FDDCell
UMTSNeighbouringRelation
Load Post-Filtering
Best Cell Color Cells
Cells with best
FDD priority
Cells with best EcNo
If no cell is eligible a GSM Cell will be selectedif a suitable GSM Cell isreported
FDD Eligible Cells filtering is explained later on in the document.
Filtering on HSxPA capabilities for iMCTA Alarm or CAC is explained later on in the document.
Load Post-Filtering is available from UA7 onwards; it is explained later on in the document.
Best Cell Color Cells:
FDD Cell Load must be understood here as Worst Combined DL and UL Cell Colours
� All reported neighboring cells whose load is the lowest, among all cells remaining in the list after
Filtering on HSxPA capabilities, must be kept; all the others are removed.
� This is applicable whatever Priority of the neighboring cell.
� For instance, if some reported cells have their Cell Colour= GREEN and others = YELLOW, then only the
cells of GREEN Cell Colour are kept, YELLOW ones are removed.
� Note: an FDD cell belonging to a neighboring RNC is considered as RED as Serving RNC is not able to determine its load color.
Section 10 � Module 1 � Page 47
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 47
2.20.2 iMCTA Alarm or CAC : Inter-Freq case
2.20.2.1 FDD cells Eligibility
FDD2 Neighboring Cell
FDD1 Primary Cell
FDD1 Neighboring Cell
CPICH_Ec/No > minimumCpichEcNoValueForHO
AND
CPICH_RSCP > minimumCpichRscpValueForHO
RadioAccessService
DlUserService
minimumCpichEcNoValueForHO
minimumCpichRscpValueForHO
FDD cells
Eligibility
To be eligible to HHO, a FDD neighboring cell must be reported better than 2 thresholds, one for CPICH
Ec/No, another for CPICH RSCP.
Section 10 � Module 1 � Page 48
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 48
2.20.2 iMCTA Alarm or CAC : Inter-Freq case
2.20.2.2 Load Post-Filtering (Alarm or CAC)
Cell Color Better thenimctaLoadBasedTargetCellColourThreshold
Yes
Cell not eligible
No
Cell kept as candidate
isImctaFDDLayerLoadPreCheckAllowed(RadioAccessService) = True
(Trigger = IuB CAC) AND(IuB colour Target cell > IuB colour Source cell)
(Trigger = CEM CAC) AND(CEM colour Target cell > CEM colour Source cell)
Yes
No
isCEMLoadUseRestrictedAllowed(RadioAccessService) = True
Yes
No
This filtering for iMCTA Alarm and CAC load based is only invoked if isImctaLoadBasedAllowed = TRUE.
In this case, to be eligible to HHO, a FDD neighbouring cell shall have a Cell Load Colour fulfilling the
imctaLoadBasedTargetCellColorThreshold.
For instance, if imctaLoadBasedTargetCellColorThreshold = Yellow and one DCH colour of the
neighbouring cell is Red, this cell is removed from the candidate list to HHO.
An additional criterion applies for iMCTA Alarm and CAC load based: 2G layer should be set with the same
priority value (different from PNA) as the highest FDD priority (activation of simultaneous IFREQ/ IRAT
measurements is mandatory allowing simultaneous FDD and GSM compressed mode). This way it is
guaranteed that at least an inter Rat handover is performed to rescue the call due to coverage loss or
resource shortage when all FDD neighbouring cells are discarded due to overload.
In UA7.1 isImctaLoadBasedAllowed enables the cell load criteria when iMCTA reason is Alarm or CAC
failure.
Section 10 � Module 1 � Page 49
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 49
2.20.2 iMCTA Alarm or CAC : Inter-Freq case
2.20.2.3 Filtering on HSxPA Capabilities (Alarm or CAC)
HSUPA cells
only
someHSUPAcells ?
someHSDPAcells ?
HSDPA cells
only
R99
cells
Yes Yes
No
Yes
NoNo
Filtering on HSxPA capabilities
for iMCTA Alarm or CAC
HSUPAUE ?
HSDPAUE ?
No
Yes
Filtering on UE and reported cells HSxPA capabilities aims at optimizing UTRAN radio resources since only
HSxPA capable mobiles are able to use HSxPA radio resources.
� Don’t forget that for iMCTA Alarm or iMCTA CAC Priority is the same between the different FDD
carriers.
� As an example, if UE is HSUPA capable, RNC will keep:
� the HSUPA-capable cells if present,
� otherwise, the HSDPA-capable cells if present
� otherwise all cells.
This filtering can be seen as a “best-effort” filtering.
HSxPA UE stands for HSUPA or HSDPA UE, i.e. R6 or R5 UE
Section 10 � Module 1 � Page 50
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 50
2.20 Measurement Report Processing (MRP)
2.20.3 iMCTA Alarm or CAC : Inter-RAT case
gsmCellIndivOffset
GSM cellsEligibility
Check 2G cell color
Keep the cell
with highest GSM_RSSI + CIO
among lowest load cells
FDDCell
GsmNeighbouringCell
RadioAccessService
Imcta
inhibitTimer3g2g
inhibitTimer3g2gLoad
2G Cell XColour
GSM Eligible Cells filtering is explained later on in the document.
GSM Cell Load must be understood here as a mean to inhibit a HHO to a GSM cell to which a previously
attempted HHO has failed in the last inhibitTimer3g2g seconds.
� A GSM target cell will have a RED Cell Colour if a handover towards this cell has been rejected for load
reasons in the previous inhibitTimer3g2g seconds.
� otherwise the Cell Colour is GREEN.
� The 2G cell load detection is based on the receipt of the RANAP Relocation Preparation Failure message
with a cause IE value equal to “Relocation failure in target CN/RNC or target system”.
Section 10 � Module 1 � Page 51
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 51
2.20.3 iMCTA Alarm or CAC : Inter-RAT case
2.20.3.1 GSM cells Eligibility
GSM Neighboring Cell
FDD1 Primary Cell
GSM Neighboring Cell
GSM Carrier RSSI > minimumGsmRssiValueForHO
RadioAccessService
minimumGsmRssiValueForHO
GSM cells
Eligibility
To be eligible to HHO, a GSM neighboring cell (BCCH Rxlev) must be reported better than a threshold.
Section 10 � Module 1 � Page 52
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 52
2.20.3 iMCTA Alarm or CAC : Inter-RAT case
2.20.3.2 2G Cell Load Management
RNCBSC
CN
is2GCellLoadInformationManagementAllowedisCellLoadInformationSendingAllowed
Loaded 2G cell
Unloaded 2G cell
GSM
UMTS
False
True
Cell Load Information
Dl(Ul) capacity ClassDl(Ul) load valueDl(Ul) RT load valueDl(Ul) NRT load value
2G Cell Load Info 3G Cell Load Info
Dl(Ul) capacity class CapacityClass
DL(UL) Cell Color
Dl(Ul)GreenLoadValueDl(Ul)YellowLoadValue
Dl(Ul)RedLoadValue
gsmDl(Ul)AvailableCapacityThresholdToRedColor
Dl(Ul) GSM cell available capacity = Dl(Ul) cell capacity class
x (100- Dl(Ul) load value/100)
inhibitTimer3g2gLoad
inhibitTimer3g2g
timeiMCTAService
MR MR
HHO to 2G cell
X
HHO reject from 2G
2G Cell XColour
MR
HHO to 2G cell
X
Dl(Ul) load valuecheck
The aim of this feature is to make better 2G Target cell selection during an inter-system handover
procedure, thanks to a better knowledge of the 2G cell load, which are provided by the 2G BSC.
Moreover, the RNC takes the opportunity to provide, during an inter-system handover procedure, the 3G
cell load information to the 2G BSC so as to allow it to improve, him too, the 3G Target cell selection.
The 3G cell load information are sent in the following RANAP messages:
� Relocation required / old BSS to new BSS information
� Relocation request ack / new BSS to old BSS information
� Relocation failure / new BSS to old BSS information
During inter-system handover procedures, the feature must ensure the following functions when the
feature is activated:
� Compute the UTRAN cell load information and send it to the BSC
� When the GSM cell load information is provided by the BSC, compute the GSM cell load color based on
this received cell load information
If the 2G network supports the feature Unified RRM Step 2, the GSM cell load information is received by
the RNC in the following messages:
� Relocation request / source RNC to target RNC
� Relocation command / inter system information transparent container
� Relocation preparation failure / inter system information transparent container
Section 10 � Module 1 � Page 53
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 53
2.20.3 iMCTA Alarm or CAC : Inter-RAT case
2.20.3.2 2G Cell Load Management [cont.]
2G Cell Load
If the parameter is2GCellLoadInformationManagementAllowed is set to TRUE, the RNC translate the GSM
cell load information in a GSM cell load color thanks to the specific thresholds. The RNC shall translate
the cell load information element in a value that can be used by the iMCTA algorithm.
The cell load information is:
� Cell Capacity Class
� o Corresponds to the planned maximum load of the cell. It is a value between 1 and 100 (%) that
characterizes the cell with regards to other cells
� Load value
� o Corresponds to the cell load relative to the planned maximum load above. It is a value between 0
and 100 (%).
� RT load value
� o Corresponds to the part of the load generated by real time traffic. It is a value between 0 and
100(%). Other values mean “no information”.
� NRT load information value
� o Gives the cell load situation regarding non real time traffic. It is a value between 0 and 3. Other
values mean “no information”.
Section 10 � Module 1 � Page 54
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 54
2.20.3 iMCTA Alarm or CAC : Inter-RAT case
2.20.3.3 Inter-RAT Case – Handover Call Flow
The aim of this feature is to make better 2G Target cell selection during an inter-system handover
procedure, thanks to a better knowledge of the 2G cell load, which are provided by the 2G BSC.
Moreover, the RNC takes the opportunity to provide, during an inter-system handover procedure, the 3G
cell load information to the 2G BSC so as to allow it to improve, him too, the 3G Target cell selection.
The 3G cell load information are sent in the following RANAP messages:
� Relocation required / old BSS to new BSS information
� Relocation request ack / new BSS to old BSS information
� Relocation failure / new BSS to old BSS information
During inter-system handover procedures, the feature must ensure the following functions when the
feature is activated:
� Compute the UTRAN cell load information and send it to the BSC
� When the GSM cell load information is provided by the BSC, compute the GSM cell load color based on
this received cell load information
If the 2G network supports the feature Unified RRM Step 2, the GSM cell load information is received by
the RNC in the following messages:
� Relocation request / source RNC to target RNC
� Relocation command / inter system information transparent container
� Relocation preparation failure / inter system information transparent container
Section 10 � Module 1 � Page 55
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 55
2.20 Measurement Report Processing (MRP)
2.20.4 iMCTA Service : Inter-Freq case
FDD cellsEligibility
For each FDD carrier
keep the cell
with highest
CPICH_Ec/No + CIO
Filtering on
HSxPA capabilities
for iMCTA Service
Keep the cell
with highest CPICH_Ec/No + CIO
among lowest load cells
among highest priority cell
RadioAccessService
FddImcta
hsxpaSegmentationEnable
= True
Filtering on
load criteria
FDD Eligible Cells filtering is the same as for iMCTA Alarm or CAC.
Filtering on HSxPA capabilities for iMCTA Service is explained later on in the document.
Filtering on load criteria is explained later on in the document.
Section 10 � Module 1 � Page 56
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 56
2.20.4 iMCTA Service : Inter-Freq case
2.20.4.1 Filtering on HSxPA Capabilities
HSxPA cells
only
HSxPAUE ?
R99 cells
only
Yes
No
hsxpaSegmentationEnable
Filtering on
HSxPA capabilities
for iMCTA Service
Unlike iMCTA Alarm and iMCTA CAC, a new filtering is introduced based on hsxpaSegmentationEnableparameter.
� When this parameter is set to True, the algorithm removes all reported cells that are not compatible
with UE’s HSxPA capabilities (sent on RRC Connection Setup Complete message):
� If UE is NOT HSxPA-capable, all HSxPA-capable cells are removed (either HSDPA or HSUPA)
� If UE is HSxPA-capable (either HSDPA or HSUPA), all non HSxPA-capable cells are removed
Section 10 � Module 1 � Page 57
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 57
2.20.4 iMCTA Service : Inter-Freq case
2.20.4.2 Filtering on Load Criteria
YES
Target cell is kept
NO
YES
YES
NO i.e. same priority
NO
YES
YES
NO
NO i.e. NOT compatible
YES
NO
Target Cell load Green or ≤ targetCellColourThreshold
isServiceSegmentationTopPriorityAND
Source cell NOT fully compatible
target cell fully or partially compatible
target cell priority better than source cell
YES
target cell’s load smaller than source cell's loadOR
target cell's load =Green
isServiceSegmentationTopPriorityAND
Source cell NOT fully compatible
Target cell is removed
Candidate Target Cells
FDDCell
umtsNeighbouringImcta
targetCellColourThreshold
umtsFddNeighbouringCell
The idea of iMCTA Service is to improve quality of service or to optimize resource usage.
� Therefore, all reported neighboring cells whose load is worse than targetCellColourThreshold must be removed. This is applicable whatever Priority of the neighboring cell.
� For instance, if targetCellColourThreshold= YELLOW and one DCH color of the neighboring cell is RED, this cell is removed from the candidate list to HHO.
Note: a FDD cell belonging to a neighboring RNC is considered as RED as Serving RNC is not able to
determine its load color.
Comparing reported neighbouring cell’s iMCTA colour with targetCellColourThreshold is systematically
performed by iMCTA Service, for load balancing purpose but also for traffic segmentation (which is based
on UE and NodeB HSxPA capabilities).
� If operator’s top priority is to perform traffic segmentation rather than load balancing,
targetCellColourThreshold must be set to RED so as to systematically go further in the algorithm,
whatever neighbouring cell load.
� If isServiceSegmentationTopPriority=True AND originating cell is NOT fully compatible with UE
capabilities, remove cells that are NOT compatible with UE capabilities
� Fully and partially compatible cells are kept
� Flag defined per serviceType
� If priority is equal to primary cell,
� If cell load is GREEN or better than Primary cell load, keep the cell
� Otherwise remove the cell except when
� isServiceSegmentationTopPriority=True AND originating cell is NOT fully compatible with UE
capabilities
� Don’t forget that for that neighbouring cell whose priority is worse than Primary cell’s one have been removed at “Neighbouring Cell Searching and Filtering” stage.
Section 10 � Module 1 � Page 58
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 58
2.20 Measurement Report Processing (MRP)
2.20.5 iMCTA Service – Inter-RAT Case
targetCellColourThreshold
GSM Eligible Cells
Keep cells with
load <= targetCellColourThreshold
Keep the cell
with highest GSM_RSSI + CIO
among lowest load cells
RNC
GSMCell
2G Cell XColour
inhibitTimer3g2g
GSMNeighbour
GsmImcta
GSM Eligible Cells filtering is the same as for iMCTA Alarm or CAC.
GSM Cell Load must be understood here as a mean to inhibit a HHO to a GSM cell to which a previously
attempted HHO has failed in the last inhibitTimer3g2g seconds.
� A GSM target cell will have a RED Cell Colour if a handover towards this cell has been rejected for load
reasons in the previous inhibitTimer3g2g seconds.
� otherwise the Cell Colour is GREEN.
The 2G cell load detection is based on the receipt of the RANAP Relocation Preparation Failure message
with a cause IE value equal to “Relocation failure in target CN/RNC or target system”.
Section 10 � Module 1 � Page 59
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 59
2 Intelligent Multi-Carrier Traffic Allocation
2.21 HHO Decision
measurementGuardTimerFdd
measurementGuardTimer2g
time
measurementGuardTimer
iMCTAAlarm
MR MR MR
no candidate cell
2G Blind HHO if provisioned
CM reactivation if Event 2F not received
measurementGuardTimer
time
measurementGuardTimer
iMCTACAC
MR MR MR
no candidate cell
2G Blind HHO if provisioned
measurementGuardTimer
CM reactivation if Event 2F not received
time
measurementGuardTimer
iMCTAService
MR MR MR
no candidate cellmeasurementGuardTimer
RAB Assignment Failure
2G Blind HHO if provisioned
CM reactivation if Event 2F not received
UE remains on initial FDD carrierImcta
HHO Decision is taken by the RNC according to the Measurement Reported on neighboring cells
� HHO triggered can be Inter-RAT normal or blind, Inter-Freq Intra-RNC or Inter-RNC
The period during which iMCTA Alarm waits for neighbouring reported cells is bounded by 2 different guard
timers, so-called measurementGuardTimerFdd and measurementGuardTimer2g, depending on the selected target Access type.
� At guard timer expiration, if no neighboring cell is candidate for HHO (no reported cell has been
reported or the reported cells have been discarded):
� For iMCTA Alarm:
� RNC triggers 2G Blind HO if provisioned
� otherwise Compressed Mode is reactivated if Event 2F has not been received (iMTCA Alarm only)
� For iMCTA CAC
� RAB can not be established and RNC sends RANAP RAB Assignment Response (RAB failed list) to CN
� For iMCTA Service
� UE remains on the initial frequency
measurementGuardTimerFdd and measurementGuardTimer2g replace UA4.2 previous CM timers
(gsmCmodeReactivationTimer, fddCmodeReactivationTimer) and HHO timers (blindHhoGsmTimer,
blindHhoFddTimer)
Section 10 � Module 1 � Page 60
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 60
2.21 HHO Decision
2.21.1 CM Deactivation / Reactivation
cModeDeltaCfn (CModeConfiguration)
CM period
Duration of pattern sequence If required according to alarm measurements
Measurement criteria is still valid
CFN
CM activation time
Inter-System or inter-Frequency measurements are required
cModeShoDeltaCfn (CModeConfiguration)
or
if
measurementGuardTimer2gmeasurementGuardTimerFdd
(Imcta)
If inter-system/frequency measurement criteria are fulfilled, then the following is applied:
� Inter-system/frequency measurements are requested from the UE using a RRC Measurement Controlmessage.
� Compressed Mode is possibly activated using the Measurement Control message, based on UE needs, as indicated in the mobile Classmark.
� if compressed mode needs to be reactivated, a Compressed Mode Command message is sent to the UE.
cModeDeltaCfn indicates the delay to add to the CFN to determine the activation time of the compressed mode. It allows synchronization of UE and BTS Compressed Mode start.
There is no criterion for CM de-activation (CM scheme with a finite length pattern). Meanwhile, CM needs to be re-activated if the inter-system/frequency measurement criteria are still valid. In order to prevent CM from being active forever, the parameters measurementGuardTimer2g andmeasurementGuardTimerFdd are set to a value which shall be greater than the pattern sequence length.
Interaction between CM and SHO:
� cModeShoDeltaCfn indicates the delay to add to the CFN in order to determine the reception time of the NBAP RL Setup Request at Node B level while the compressed mode is active. It is given in connection frame number of 10 ms.
Section 10 � Module 1 � Page 61
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 61
2 Intelligent Multi-Carrier Traffic Allocation
2.22 Inter-FREQ & Inter-RAT CNL - RAN Model
RadioAccessService
NeighbouringRNC
RNC
numOfPrimaryCellNeighbourInterFreqnumOfPrimaryCellNeighbourInterRat
typeOfCompoundingNeighbourListInterFreqtypeOfCompoundingNeighbourListInterRat
NodeB
FDDCell
GsmNeighbouringCell UMTSFddNeighbouringCell
neighbourCellPrio neighbourCellPrio
maxCompoundingListSizeInterFreq [16..32]maxCompoundingListSizeInterRAT [16..32]
typeOfCompoundingNeighbourListInterFreqtypeOfCompoundingNeighbourListInterRatnumOfPrimaryCellNeighbourInterFreqnumOfPrimaryCellNeighbourInterRat
Section 10 � Module 1 � Page 62
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 62
2 Intelligent Multi-Carrier Traffic Allocation
2.23 Service Based Inter-Freq/Inter-RAT Mobility - RAN Model
RadioAccessService
DedicatedConf
HoConfClass [0..30]
UsHoConf [0..21]
FastAlarmHardHoConf
FullEventHoConfHhoMgt
FullEventHoConfHhoMgtEvent2D
FDDCell MeasConfClass [0..14]
DlUserServiceNeighbouringRNC
mobilityServiceType
timerAlarmHoEvent2D
FullEventHoConfHhoMgtEvent2F
timeToTrigger2Fhysteresis2F
cpichEcNoThresholdUsedFreq2FcpichRscpThresholdUsedFreq2F
timeToTrigger2Dhysteresis2D
cpichEcNoThresholdUsedFreq2DcpichRscpThresholdUsedFreq2D
cpichEcNoThresholdcpichRscpThreshold
counter stepUpstepDown
Section 10 � Module 1 � Page 63
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 63
2 Intelligent Multi-Carrier Traffic Allocation
2.24 iMCTA - RAN Model
Imcta
RadioAccessService
RNC
FddCell
priority
NodeB
FddImcta
AlarmPriorityTableConfClass
Frequency 1..7
Service 1..12
measurementGuardTimer2gmeasurementGuardTimerFddserviceHoRanapIeEnableinhibitTimer3g2g
CACPriorityTableConfClass
ServicePriorityTableConfClass
ServiceSegmentationPriorityClass 1..7
Frequency 1..8
Service 1..12
AccessdlFrequencyNumberulFrequencyNumber
priority
OriginatingCellColourThresholdConfClass 1..5
OriginatingCellColourThresholdPerService 1…12
UmtsFddNeighbouringCell
UmtsNeighbouringImcta
targetCellColourThresholdimctaLoadBasedTargetCellColorThreshold
ServiceForTrafficSegmentationPriority 1..12
originatingCellColourThreshold
modehsxpaSegmentationEnablemobilityServiceForHsxpaEnablemobilityServiceForNonHsxpaEnableuserServiceSigToTrafficOnlyEnableoriginatingCellColourThresholdConf…ClassRef
AccessdlFrequencyNumberulFrequencyNumber
isServiceSegmentationTopPriority
isImctaLoadBasedAllowedisCEMLoadUseRestrictedAllowedisImctaFddLayerLoadPreCheckAllowed
Section 10 � Module 1 � Page 64
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 64
2 Intelligent Multi-Carrier Traffic Allocation
2.25 Exercise1: Set iMCTA Alarm Priority Table
� Objective: to save the call in case of loss of coverage
� Redirect preferably any CS calls to GSM layer if service supported on 2G
� Redirect preferably any PS calls to 3G layer
� Allow also redirection to 2G/3G layer to avoid call drop
� Forbid redirection to GSM if service not supported on 2G
� Question: Fill up the Alarm Priority Table below
3G FDD2
3G FDD1
2G
GSM GSM GSM GSM GSM GSM
R99
HSDPA
R99
HSDPA
R99
HSxPA
R99
HSxPA
R99
HSxPA
R99 R99 R99 R99
PsStreaming
PsIb
CsSpeechPlusOther
2G
FDD
CsSpeech
CsConversational
CsStreaming
Alarm priority Table
Service Type
Access Type
Section 10 � Module 1 � Page 65
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 65
2 Intelligent Multi-Carrier Traffic Allocation
2.26 Exercise2: Set iMCTA CAC Priority Table
� Objective: to set up the call when RAB establishment fails on 3G
� Establish preferably any CS or PS call on 3G
� Allow also establishment attempt on GSM if service supported on 2G
� Forbid establishment attempt on GSM if service not supported on 2G
� Question: Fill up the CAC Priority Table below
3G FDD2
3G FDD1
2G
GSM GSM GSM GSM GSM GSM
R99
HSDPA
R99
HSDPA
R99
HSxPA
R99
HSxPA
R99
HSxPA
R99 R99 R99 R99
PsStreaming
PsIb
CsSpeechPlusOther
2G
FDD
CsSpeech
CsConversational
CsStreaming
CAC priority Table
Service Type
Access Type
Section 10 � Module 1 � Page 66
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 66
2 Intelligent Multi-Carrier Traffic Allocation
2.27 Exercise3: Set iMCTA Service Priority Tables
� Objective: Objective: split UE traffic according to their capabilities
� Redirect R99 capable UE calls to R99 layer
� Forbid redirection of R99 capable UE calls to HSxPA layer
� Redirect R5/R6 UE calls to HSxPA layer for PsIb and CsSpeechPlusOtherService Types only
� Redirect R5/R6 UE calls to R99 layer for all Service Types except PsIb and CsSpeechPlusOther
� Forbid redirection to GSM
� Question: Fill up the Service Priority General Table and the Service Priority For HSDPA Table next page
� assume that Service Priority General For HSUPA Table is not configured
3G FDD2
3G FDD1
2G
GSM GSM GSM GSM GSM GSM
R99
HSDPA
R99
HSDPA
R99
HSxPA
R99
HSxPA
R99
HSxPA
R99 R99 R99 R99
Section 10 � Module 1 � Page 67
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 67
2 Intelligent Multi-Carrier Traffic Allocation
2.27 Exercise3: Set iMCTA Service Priority Tables[cont.]
3G FDD2
3G FDD1
2G
GSM GSM GSM GSM GSM GSM
R99
HSDPA
R99
HSDPA
R99
HSxPA
R99
HSxPA
R99
HSxPA
R99 R99 R99 R99
2G
PsStreaming
PsIb
CsSpeechPlusOther
FDD1
FDD2
CsSpeech
CsConversational
CsStreaming
Service priority General Table
2G
PsStreaming
PsIb
CsSpeechPlusOther
FDD1
FDD2
CsSpeech
CsConversational
CsStreaming
Service priority For HSDPA Table
Section 10 � Module 1 � Page 68
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 68
2 Intelligent Multi-Carrier Traffic Allocation
2.28 Exercise4: Find the target cell chosen by iMCTA
G1-71dBm
A2-16dB
A1-7dB A3
-6dBA4
-14dBA5-4dB
G7-73dBm
G2-70dBm
G4-85dbM
G6-65dBm
G8-77dBm
Alarm triggered
3G F1
2G
B3-6dB
B4-11dB
B5-10dB
B6-5dB
B2-16dB
B1-3dB
C3-6dB
C4-20dB
C5-22dB
C6-3dB
C2-12dB
C1-5dB
3G F2
3G F3
G3-62dBm
G5-55dBm
Section 10 � Module 1 � Page 69
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 69
2 Intelligent Multi-Carrier Traffic Allocation
2.28 Exercise4: Find the target cell chosen by iMCTA [cont.]
P2P2P2P2P1P2FDD2
P3P3P3P2P3P1FDD3
P4
P1
PsStreaming
P4
P1
PsIb
P4
P1
CsSpeechPlusOther
P5PNAP12G
P1P2P3FDD1
CsSpeech
CsConversational
CsStreaming
Alarm priority Table
Service Type
Access Type
mode = allisGsmCModeActivationAllowed = trueisInterFreqCModeActivationAllowed = trueisInterFreqMeasActivationAllowed = trueoriginatingCellColorThreshold = greentargetCellColor = greenimctaLoadBasedCellColorThreshold = greenisServiceSegmentationTopPriority = TruehsxpaSegmentation = False
Supposing the service used is CsSpeech, what would be the target Cell for HHO?Supposing the service used is PsIb, what would be the target Cell for HHO?
isImctaLoadBasedAllowed = TrueisImctaFddLayerLoadPreCheckAllowed = TrueminimumCpichEcNoValueForHO= -7 dB minimumGsmRssiValueForHo= -70dBmis3GHandoverPrefered = TrueisSimCMAllowed = True
Mode: defines what triggers iMCTA (alarm, Alarm&CAC, Alarm&Service, All)
Section 10 � Module 1 � Page 70
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 70
3 Inter-FDD/Inter-RAT HHO
Section 10 � Module 1 � Page 71
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 71
3 Inter-FDD/Inter-RAT HHO
3.1 3G->2G HHO
SRNC GSM/GPRS BSS
BCCH
Core Network
13
FDD Cell GSM Cell
Handover From UTRAN Commandor
Cell Change Order
2
activationHoGsmCsAllowedactivationHoGsmPsAllowed
isInterFreqMeasActivationAllowed
(RadioAccessService)
isGsmCmodeActivationAllowed
(DlUserService)isPatternAllowed
(CmodePatternSeqInfo)
Thanks to Compress Mode a UE can performed a HHO to 2G with measurements.
� CM for 2G neighboring cells measurements is activated when UE is having a CS RAB or a PS RAB on 3G if:
� isInterFreqMeasActivationAllowed = True
� isGsmCmodeActivationAllowed = True
� isPatternAllowed = True
Inter-system HHO can occur following iMCTA Alarm, CAC or Service triggering.
� The selection between FDD and 2G Access is part of iMCTA algorithm, mostly based on UE capabilities,
priority tables and available neighbouring cells
3G to 2G HHO is possible for a UE:
� having a CS service if activationHoGsmCsAllowed must be set to True
� having a PS service if activationHoGsmPsAllowed must be set to True
Section 10 � Module 1 � Page 72
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 72
3 Inter-FDD/Inter-RAT HHO
3.2 CS 3G->2G HHO Failure: Next Best Cell Attempt
Cell 1: Primary CellG1 G3
G2
During iMCTA processing
Measurement
report CM
InterRat Cells
G1,G2,G3
iMCTA Algo ranking: G1,G2
G1 Best candidate � Selected for HHO
Relocation Required G1
Relocation Failure G1: Cause: Lack of radio ressources
1
2
3
4
5
G2 Selected for HHO BSCRNC
isGsmIratHoToNextBestCellAllowed(RadioAccessService)
If the SRNC received a RELOCATION PREPARATION FAILURE message upon a RELOCATION REQUIRED message
for relocation preparation to a GSM target cell with one of the following causes
� No Radio Resources Available in Target cell (or)
� Relocation Target Not Allowed (or)
� Relocation Failure in Target CN/RNC or Target system
then UTRAN can retry relocation preparation to the next best GSM cell if the UE has reported more than
one cell with sufficient received BCCH level.
This mechanism can be enabled via parameter isGsmIratHoToNextBestCellAllowed introduced in UA7.
else SRNC shall maintain the CS call on 3G with no further HHO attempt. A new 3G 2G HHO attempt may be
triggered again at the next 2G measurement report message received from UE.
SRNC shall only trigger another relocation preparation procedure to the next best GSM cell (with lowest cell
load preferably (if available) and highest RSSI), based on latest 2G measurement report, if and only if:
� An alternative GSM target cell exists as per the latest 2G measurement report
� If the UE has sent a combined measurement report for inter-RAT and inter-frequency then the report
contains no suitable inter-frequency target cells
� If eligible neighbors present in report for both inter-RAT and inter-frequency then HHO target layer
selection will be based on is3GHandoverPreferred
� The need for handover is still present, e.g. the alarm condition is still active
Section 10 � Module 1 � Page 73
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 73
3 Inter-FDD/Inter-RAT HHO
3.3 3G->3G Intra-RNC Inter-freq HHO
SRNC
P-CPICH
is3Gto3GWithoutIurAllowedforCS is3Gto3GWithoutIurAllowedforPS
(RadioAccessService)
4
FDD Cell F1 FDD Cell F2
Radio Bearer Reconfiguration1
isIrmCacForInterFreqIntraRncEnable
(RadioAccessService)
3
Radio Bearer Reconfiguration Complete2
Global 3G->3G Inter-frequency HHO are controlled by parameters is3Gto3GWithoutIurAllowedforCS and is3Gto3GWithoutIurAllowedforPS even though naming is not explicit.
isIrmCacForInterFreqIntraRncEnable: allows to play iRM CAC tables on the Target FDD cell before
executing HHO (only applicable for Intra-RNC HHO).
If the Inter-Freq Intra-RNC HHO takes place in a DRNC then the procedure is:
• either a handover over Iur with the neighbouring RNC to be the DRNC which controls both the source and
the target cell
• or a SRNS relocation UE Involved with this DRNC to become the new SRNC
It depends on the flag isInterFreqHandoverOverIurAllowed as follows:
• If the flag isInterFreqHandoverOverIurAllowed is set to TRUE for the DRNC to control both source and target cell then inter-frequency handover over Iur is used.
• If the flag isInterFreqHandoverOverIurAllowed is set to FALSE for the DRNC to control both source and target cell then the handover is performed through SRNS relocation UE Involved.
Section 10 � Module 1 � Page 74
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 74
3 Inter-FDD/Inter-RAT HHO
3.4 3G->3G Inter-RNC Inter-freq HHO: Iur not used
is3Gto3GWithoutIurAllowedforCS is3Gto3GWithoutIurAllowedforPS
(RadioAccessService)
SRNC Target RNC
P-CPICH
FDD Cell F1 FDD Cell F2
Radio Bearer Reconfiguration
5
Relocati
on Requ
ired1
8
isInterFreqHandoverOverIurAllowed
(NeighbouringRNC)= False
CN
Reloc. Req. Ack3Rel
ocation
Command
4
Relocation Request
2
Radio Bearer Reconfiguration Complete
6
7
Prior to UA7 Inter-RNC HHO are processed in the same way whether there is Iur or not, i.e. through a SNRS
Relocation UE involved procedure through the CN.
From UA7, Inter-RNC HHO is processed using the SRNS Relocation UE involved is parameter
isInterFreqHandoverOverIurAllowed is set to False.
Section 10 � Module 1 � Page 75
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 75
3 Inter-FDD/Inter-RAT HHO
3.5 3G->3G Inter-RNC Inter-freq HHO: Iur used
SRNC Target RNC
P-CPICH6
5
FDD Cell F1 FDD Cell F2
RNSAP Radio Link Setup Request1
is3Gto3GWithoutIurAllowedforCS is3Gto3GWithoutIurAllowedforPS
(RadioAccessService)
isInterFreqHandoverOverIurAllowed
(NeighbouringRNC)= True
Radio Bearer Reconfiguration Complete
4
Radio Bearer Reconfiguration
3
RNSAP Radio Link Setup Response2
The radio link to the target cell is to be setup with RNSAP Radio Link Setup or RNSAP Radio Link Additionprocedure depending on the DRNC being new or already existing in the call context. The radio link to the source cell needs to be released with NBAP Radio Link Deletion Procedure.
Section 10 � Module 1 � Page 76
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 76
Module Summary
� This lesson covered the following topics:� Handover types and purpose
� Soft Handovers and associated parameters
� Intra-Freq Hard Handovers
� Inter-Freq and Inter-RAT Hard Handovers (iMCTA algorithm) and associated parameters
� Compress Mode algorithm and parameters
Section 10 � Module 1 � Page 77
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 77
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 10 � Module 1 � Page 78
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility in HHO �
10 � 1 � 78
End of Module
Section 11 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
11�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 11Inter carrier Mobility at RRC
connection
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 11 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 2
Blank Page
This page is left blank intentionally
New module for new UA7 feature: iMCRAChatila, RayanElsner, BernhardCharneau, Jean-Noel
2010-04-1501
RemarksAuthorDateEdition
Document History
Section 11 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 3
Module Objectives
Upon completion of this module, you should be able to:
� Explain the benefits of intelligent Multi Carrier RRC Allocation
� List redirection types
� Explain the term „twin cells“
� Describe the iMCRA capabilities
� Distinguish the different iMCRA algorithm types
� Explain the iMCRA RAN model
Section 11 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 4
Module Objectives [cont.]
This page is left blank intentionally
Section 11 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 5
Table of Contents
Switch to notes view!Page
1 iMCRA overview 71.1 Why intelligent Multi Carrier RRC Allocation? 81.2 Redirection types 91.3 Twin cells definition 10
2 iMCRA capabilities 112.1 UE capabilities and Call type 122.2 Cell capabilities and faType 13
3 iMCRA algorithms 143.1 CapaOnly 153.2 CapaAndEstCause 163.3 PreferredFa 173.4 CAC 18
4 iMCRA RAN model 194.1 iMCRA: RAN Model 20
5 iMCRA exercises 215.1 Exercise 1 225.2 Exercise 2 23
Section 11 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 6
Table of Contents [cont.]
Switch to notes view!
This page is left blank intentionally
Section 11 � Module 1 � Page 7
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 7
1 iMCRA overview
Section 11 � Module 1 � Page 8
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 8
1 iMCRA overview
1.1 Why intelligent Multi Carrier RRC Allocation?
Traffic Segmentation
UE & Cell Capability
RRC CAC Failure
Load balancing
Why iMCRA ?
R99
HSDPAHSDPA HSDPA HSDPA HSDPA
R99
R99
R99
R99
R99
R99
R99R99
3G F1
3G F2
R99
R99
R99
R99
R99
R99
R99
R99
R99R99
3G F3
isRrcRedirectionInterFreq
(RadioAccessService)
To increase the network capacity and optimize HSxPA throughput, operators may deploy multi-layer
configurations with several layers structures:
� Multi-layers based on asymmetric topologies (dedicated layers for HSxPA or Data traffic separated from
dedicated layers for R99 or Conversational traffic),
� Multi-layers based on symmetric topologies (shared layers for HSxPA and R99 traffic),
Several features are used in order to implement different multi-layers strategies for HSxPA, providing inter
carrier mobility:
Idle Mode & Hierarchical Cell Structure (HCS) allows strategies based on UEs camping homogeneously on
different frequencies or favor specific carriers or even prioritizing cell layers for mobiles in idle mode,
Cell_FACH and URA/Cell_PCH connected modes. The HCS cell reselection algorithm also takes into
account UE speed so that fast moving UEs can be placed in large cells to avoid excessive cell reselections.
Intelligent Multi-Carrier RRC Connection Allocation (iMCRA) allows redirecting UE to FDD cells at RRC connection establishment. iMCRA strategies are based on:
� RRC Redirection based on UE Capabilities allowing redirecting UE at RRC connection establishment
based on their release and/or on the establishment cause sent to RNC in RRC Connection Request
message. It also allows redirecting UE to the preferred R99 layer.
� RRC Redirection based on Preferred Frequency allowing redirecting different establishment causes
based on service type to the preferred frequency allocation or allowing redirection to the lowest
loaded frequency based on originating cell load.
� RRC Redirection based on CAC failure allowing redirecting to another frequency upon SRB CAC failure.
Intelligent Multi-Carrier Traffic Allocation (iMCTA) allowing handover UE to another layer when in Cell_DCH connected mode.
Section 11 � Module 1 � Page 9
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 9
1 iMCRA overview
1.2 Redirection types
rrcRedirectionType
(InterFreqHhoFddCell)
capaOnly
based on UE HSPA Capabilities only
Cac
based on RRCCall Admission Failure
preferredFa
based on Frequency Allocation Preferences
capaAndEstCause
based on UE Capabilitiesand Call Type
None
Algorithm Disabled
During RRC Connection Setup procedure the RNC determines the preferred Frequency Allocation (FA) based
on:
� UE capability only (Redirection based on UE HSPA capabilities already available in UA06 plus
segmenting R6+ UEs, plus choice of less loaded target cell);
� UE capability and establishment cause (Redirection based on UE HSPA capabilities and call type
already available in UA06 plus segmenting R6+ UEs, plus choice of less loaded target cell)
� Preferred FA (Select original cell or twin cell with lowest cell load)
Note: FA – Frequency Allocation = Carrier;
Optional FA classification: “Conversational”, “Data” or “Other” layer
OriginatingCellColourThresholdset to either GREEN/YELLOW/RED
� GREEN: Full Load distribution; high number of redirections
� RED: Load distribution only when originating cell gets overloaded
� CAC (Redirection to twin cell with lowest load if CAC failure on originating cell)
� None (Redirection disabled)
Section 11 � Module 1 � Page 10
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 10
1 iMCRA overview
1.3 Twin cells definition
FDD1
FDD2
FDD3
FDD4
FDD5
twinCellList
(InterFreqHhoFddCell)
Up to 5 twin cells can be defined (co-located inter-frequency cell plus cells from other Node B for blind redirection referenced by Cell Id)
NodeB 2
NodeB1
CellId xyz
Section 11 � Module 1 � Page 11
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 11
2 iMCRA capabilities
Section 11 � Module 1 � Page 12
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 12
2 iMCRA capabilities
2.1 UE capabilities and Call type
HSUPAHS-DSCH
+ E-DCH
R6 or higher
HS-DSCHR6 or higherHSDPA
N/AR5
AbsentR6 or higherDCH
N/AR99
UE Capability Deduced
UE Capability Indication
UE Release
UE Capability Combinations
Terminating Streaming
Terminating Background
Terminating Interactive
Originating Streaming
Originating Background
Terminating Conversational Call
Other Causes
Originating Interactive
Originating Conversational Call
Establishment Cause
Other
DATA
Conversational
Call Type
RRC/RACH (RRC Connection Request)
IE: Access Stratum Release (UE Release)
Establishment Cause
RNC
The UE capabilities combinations are based on the Access Stratum Release Indication IE in the RRC
Connection Request message for the identification of the different UE types.
The call type identification is based on the Establishment Cause IE in the RRC Connection Request message
to distinguish the different call types.
Note:
In UA7 the following causes “Originating Subscribed Traffic Call”, “Registration” and “Originating High
Priority Signalling” are mapped to the Data type but they may be removed from the list of Data causes
that could perform a redirection. Indeed, for short and low traffic procedures some operators may prefer
to keep the UE on the originating cell that had been selected by the UE for access.
In UA7 the spare RadioAccessService.reserved2 byte 2 (3 rd byte) is used to handle the configuration referred above. For future releases, Boolean; {True, False} parameter
RadioAccessService.isOrigHighPrioSigAndRegistPreferredDataCall will apply.
Section 11 � Module 1 � Page 13
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 13
2 iMCRA capabilities
2.2 Cell capabilities and faType
hsdpaActivation = True
edchActivation = True
HSUPA CapableHSxPA
hsdpaActivation = True
edchActivation = False
HSDPA CapableHSDPA
hsdpaActivation = False
edchActivation = False
DCH CapableR99
Cell ConfigurationCell Capability Indication
Cell Concept
faType
(InterFreqHhoFddCell)
RRCRedirectionConfClass 0..6
Frequency Allocation 1..6
RadioAccessService
Conversational
Data
Other
For capa and capaAndEstCause iMCRA type :cell capability is determined by
its HSDPA / EDCH activation parameters
For preferredFa type :cell‘s capability is defined by
its faType parameter
Section 11 � Module 1 � Page 14
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 14
3 iMCRA algorithms
Section 11 � Module 1 � Page 15
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 15
3 iMCRA algorithms
3.1 CapaOnly
HSDPA thenDCH Cells
HSUPA CellsHSUPA
HSUPA thenDCH Cells
HSDPA CellsHSDPA
Originating & all twin cells
DCH CellsDCH
Fallback FAsTarget FAUE capability
Select “UE Capability”
compatible Cells among originating and twin cells
If originating cell among candidates and cell color better than threshold,
Setup call in originating cellrrcRedirectOrigCellColorThreshold
(InterFreqHhoFddCell)
Else select cells with lowest
load color (Green<Yellow<Red)
If originating cell among selected ones, Setup call in it. Else select the final target cell with round robin mechanism
(dlFrequencyNumber >
originating one)
isRrcRedirectionInterFreq
rrcRedirectionType = capaOnly
= True
Please note that an optional criterion introduced by UA6 feature 84900 is based on preferred layer to
distinguish the R99 services potentially served on preferred layer from the others. It is only applicable for
configurations using rrcRedirectionType = ‘capaOnly’ or ‘capaAndEstCause’.
In such condition, for all cells with layerPreferredforR99 = TRUE the RNC shall assume HSPA Cell
Capability = DCH. For all cells with layerPreferredforR99 = FALSE the RNC shall assume HSPA Cell
Capability = HSPA.
�When to decide if a RRC connection should be redirected to DCH (R99) layer, function check
layerPreferredforR99 for both cells, in addition to the existing criteria’s. Only when both twin cells are configured as HSPA capable, layerPreferredforR99 is checked. If the current cell does not prefer R99 but the twin cell does, redirect is selected. Otherwise, the current behaviour is unchanged.
�When to decide if a RRC connection should be redirected to HSPA layer, function check
layerPreferredforR99 for both cells, in addition to the existing criteria’s. Only when both twin cells are configured as HSPA capable, layerPreferredforR99 is checked. If the current cell prefers R99 but the twin cell does not, redirect is selected. Otherwise, the current behaviour is unchanged.
This option applies in case HSxPA is deployed on both layers (allowing both layers to carry HSPA traffic and
keeping RRC Traffic Segmentation enabled for R5+ UEs). It is possible to prefer some of the HSPA capable
layers for R99 traffic by using parameter layerPreferredforR99 (it is possible to configure several cells with layerPreferredForR99=TRUE and to configure R99-only cells, layerPreferredForR99 cells and HSPA cells):
� DCH service originated on non-preferred cell will be redirected to the
preferred cell
� HSxPA service originated on preferred cell will be redirected to the nonpreferred cell
This algorithm is enhanced from UA6.0, i.e. RNC is able to find preferred HSxPA cells for DCH traffic in case
using RRC Traffic Segmentation based on UE Capabilities. This enhancement is only applicable if the
originating cell and operational twin cell is enabled for HSDPA (parameter hsdpaActivation).
Section 11 � Module 1 � Page 16
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 16
3 iMCRA algorithms
3.2 CapaAndEstCause
Other
Data
Conversational
Other
Data
Conversational
Other
Data
Conversational
Call type
Originating
DCH
DCH
HSDPA HDSPA
Originating
DCH
HSUPA
Originating
HSUPA
Same as in capaOnly
DCH
DCH
Fallback FAs
Target FAUE capability
Select “UE Capability & Call type” compatible Cells among originating and twin cells
If originating cell among candidates and cell color
better than threshold, Setup call in originating cell
Else select cells with lowest
load color (Green<Yellow<Red)
If originating cell among selected ones, Setup call in it. Else select the final target cell with round robin mechanism
(dlFrequencyNumber >
originating one)
rrcRedirectOrigCellColorThreshold
isRrcRedirectionInterFreq
rrcRedirectionType = capaAndEstCause
= True
Emergency calls are redirected in case of CAC failure, only.
Section 11 � Module 1 � Page 17
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 17
3 iMCRA algorithms
3.3 PreferredFa
Select cells with
faType set to others
Select FAs withfaType set to
Data
Select FAs withfaType set to Conversational
Target FA
FAs of type other; if none FAs of type conversational
Data
Other
FAs of type other; if none FAs of type
DataConversational
Fallback FAsCall Type
If originating cell among candidates & cell color better
than threshold, Setup call in originating cell
Else select cells with lowest load color (Green<Yellow<Red)
If originating cell among selected ones, Setup call in it.
Else select the final target cell with round robin mechanism
(dlFrequencyNumber >
originating one)
Select “preferred FA type” compatible Cells among originating and twin cells
faType
rrcRedirectOrigCellColorThreshold
isRrcRedirectionInterFreq
rrcRedirectionType = preferredFA
= True
Emergency calls are redirected in case of CAC failure, only.
Section 11 � Module 1 � Page 18
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 18
3 iMCRA algorithms
3.4 CAC
If CAC failure occurs, select cells with lowest
cell color (green < yellow < red)
If more than one cell selected, Select the final target cell with round robin mechanism (dlFrequencyNumber>
originating one)
RRC Connection Request
CAC Failure on Originating Cell
RNC
isRrcRedirectionInterFreq
rrcRedirectionType = cac
= True
RRC Redirection can trigger re-try of RRC Connection Allocation procedure when CAC failure occurs.
If CAC occurred during SRB establishment on the originating cell then the RNC considers redirection to a list
of twin cells. Emergency calls are also redirected in case of CAC failure.
iMCRA Interaction with 3G to 2G Redirect for Speech Calls:
If iMCRA is activated with rrcRedirectionType= cac (cares for redirection to another frequency only. Not for redirection to GSM), if CAC occurred during SRB establishment on the originating cell then the RNC
considers redirection to another FDD cell; this is applicable to all establishment causes.
If both iMCRA & 3G/2G Redirect for Speech calls are activated, Originating Conversational call or
Emergency call is redirected by feature 3G/2G Redirect for Speech calls (CAC) to GSM only when the
redirection triggered by iMCRA fails CAC again on target cell selected.
If rcRedirectionType= cAC is not configured and 3G/2G Redirect for Speech calls is activated, RNC decides to redirect to 2G Conversational or Emergency calls upon SRB CAC failure on originating cell.
iMCRA Interaction with 3G to 2G Redirection based on cell load:
If both iMCRA and 3G to 2G Redirection based on cell load are activated, for Originating Conversational call
or Emergency call, when target twin cell(s) are selected by iMCRA RRC Redirection and all the twin cell
loads reach the configurable threshold for 3G/2G redirection, the UE can be redirected to 2G using RRC
Connection Reject message by 3G to 2G Redirection based on cell load.
Section 11 � Module 1 � Page 19
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 19
4 iMCRA RAN model
Section 11 � Module 1 � Page 20
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 20
4 iMCRA RAN model
4.1 iMCRA: RAN Model
RrcRedirectionConfClass 0..6
RadioAccessService
RNC
FddCell
NodeB
InterFreqHhoFddCell
rrcRedirectionConfClassIdrrcRedirectionTypetwinCellListrrcRedirectOrigCellColourThreshold
FrequencyAllocation 1..6
dlFrequencyNumberulFrequencyNumberfaTypefddFrequencyUserLabel
layerPreferredForR99
isRrcRedirectionInterFreq
Section 11 � Module 1 � Page 21
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 21
5 iMCRA exercises
Section 11 � Module 1 � Page 22
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 22
5 iMCRA exercises
5.1 Exercise 1
Value I.
faType FDD3
faType FDD2
faType FDD1
rrcRedirectOrigCellColourThreshold
rrcRedirectionType
isRrcRedirectionInterFreq
Parameter Value III.Value II.
Suggest the parameters’ values for the 3 different configuration strategies:
I. Always perform redirection based on UE type and Establishment causeII. Always perform redirection based on call type onlyIII. Perform redirection based on load only
Section 11 � Module 1 � Page 23
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 23
5 iMCRA exercises
5.2 Exercise 2
FDD1
FDD2
FDD3
FDD4
FDD5
Config 2Config 1
faTypeCell Type
FDD6 Cell F
FDD5 Cell E
FDD4 Cell D
FDD3 Cell C
FDD2 Cell B
FDD1 CellA
rrcRedirectOrigCellColourThreshold
rrcRedirectionType
isRrcRedirectionInterFreq
OtherR99
ConversationalR99
DataR99
OtherHSUPA
DataHSUPA
DataHSUPA
YellowYellow
PreferredFacapaAndEstCause
TrueTrue
FDD6
R5 (HSDPA) UE
MO I/B
Question: For both configuration scenarios determine which is the target cell for the RRC Establishment.
Section 11 � Module 1 � Page 24
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 24
Module Summary
� This lesson covered the following topics:� Benefits of intelligent Multi Carrier RRC Allocation
� Redirection types
� iMCRA capabilities
� iMCRA algorithm types
� iMCRA RAN model
Section 11 � Module 1 � Page 25
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 25
Self-assessment on the Objectives
� Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module
� The form can be found in the first partof this course documentation
Section 11 � Module 1 � Page 26
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionInter carrier Mobility at RRC connection �
11 � 1 � 26
End of Module
Section 12 � Module 1 � Page 1
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
Do not delete this graphic elements in here:
12�1All Rights Reserved © Alcatel-Lucent @@YEAR
Module 1
TMO18255 D0 SG DEN I1.0 Issue 1
Section 12Glossary
9300 WCDMATMO18255 UA07 R99 Algorithms Description
TMO18255 Issue D0 SG DEN I1.0
Section 12 � Module 1 � Page 2
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionGlossary �
12 � 1 � 2
Blank Page
This page is left blank intentionally
First editionLast name, first nameYYYY-MM-DD01
RemarksAuthorDateEdition
Document History
Section 12 � Module 1 � Page 3
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionGlossary �
12 � 1 � 3
Abbreviations and Acronyms
Switch to notes view!# 16-QAM 16 – Quadrature Amplitude Modulation 1xEV-DO 1x EVolution Data Only 1xEV-DV 1x EVolution Data and Voice 1xRTT 1 times 1.25MHz Radio Transmission Technology 3GPP 3rd Generation Partnership Project 3xEV-DV 3x Evolution Data and Voice A AAL2 ATM Adaptation Layer type 2 AAL5 ATM Adaptation Layer type 5 ACK ACKnowledgment AICH Acquisition Indicator CHannel AM Acknowledged Mode AMC Adaptive Modulation and Coding AMD Acknowledged Mode Data AMR Adaptive Multi-Rate ARQ Automatic Repeat Query AS Access Stratum ASC Access Service Class ATM Asynchronous Transfer Mode B BCCH Broadcast Control CHannel BCH Broadcast CHannel BER Bit Error Rate BFN NodeB Frame Number BLER BLock Error Rate BMC Broadcast Multicast Control BPSK Binary Phase Shift Keying BTS Base Transceiver Station C CAC Call Admission Control CC Chase Combining CCCH Common Control CHannel CCP Communication Control Port CCPCH Common Control Physical CHannel CCTrCH Coded Composite Transport CHannel CDMA Code Division Multiple Access CEM Channel Element Module CFN Connection Frame Number CID Channel IDentifier CK Ciphering Key CM Compressed Mode CmCH-PI Common transport CHannel Priority Indicator (SPI) CP NodeB Control Port CP Control Plane CPCH Common Packet CHannel CPICH Common PIlot CHannel CQI Channel Quality Indicator CRC Cyclic Redundancy Check C-RNC Controlling-Radio Network Controller C-RNTI Cell-Radio Network Temporary Identity CS Circuit Switch CTCH Common Traffic CHannel
D DCCH Dedicated Control CHannel DCH Dedicated CHannel DL Downlink DPCCH Dedicated Physical Control CHannel DPCH Dedicated Physical CHannel DPDCH Dedicated Physical Data CHannel D-RNC Drift-Radio Network Controller DS Delay Sensitive DS-CDMA Direct Sequence-Code Division Multiple Access DSCH Downlink Shared CHannel DTCH Dedicated Traffic CHannel DTX Discontinuous Transmission E E1 Standard European PCM link (2.048 Mbps) EDGE Enhanced Data for Global Evolution EGPRS EDGE GPRS F FACH Forward Access CHannel FBI FeedBack Information FDD Frequency Division Duplex FDMA Frequency Division Multiple Access FIFO First In First Out FP Frame Protocol G GMM Global Mobility Management GPRS General Packet Radio Service GSM Global System for Mobile communications GTP GPRS Tunneling Protocol H H-ARQ Hybrid ARQ HFN Hyper Frame Number HO HandOver H-RNTI HS-DSCH Radio Network Temporary Identifier HSDPA High Speed Downlink Packet Access HS-DPCCH High Speed Dedicated Physical Control CHannel HS-DSCH High Speed Downlink Shared CHannel HS-PDSCH High Speed Physical Downlink Shared CHannel HS-SCCH High Speed Shared Control CHannel
Section 12 � Module 1 � Page 4
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionGlossary �
12 � 1 � 4
Abbreviations and Acronyms [cont.]
Switch to notes view!I IE Information Element IK Integrity Key IMA Inverse Multiplexing ATM IMEI International Mobile Equipment Identity IMSI International Mobile Subscriber Identity IMT-2000 International Mobile Telecommunication for year 2000 IP Internet Protocol IR Incremental Redundancy Iu Interconnection point between RNC and 3G Core Network Iub Interface between Node B and RNC Iur Interface between two RNCs K Kbps Kilobit per second kHz kiloHertz KPI Key Performance Indicator Ksps Kilo symbol per second L L1 Layer 1 (Physical Layer) L2 Layer 2 (Data Link Layer) L3 Layer 3 (Network Layer) LA Location Area LAC Location Area Code LAI Location Area Identity LAN Local Area Network LSB Least Significant Bit M MAC Medium Access Control Mbps Megabit per second MCC Mobile Country Code MCPA Multi Carrier Power Amplifier Mcps Megachip per second MHz MegaHertz MIR Mix Incremental Redundancy MM Mobility Management MNC Mobile Network Code MOC Managed Object Class MOI Managed Object Instance MOS Mean Opinion Score MSB Most Significant Bit N NACK Negative ACKnowledgement NAS Non Access Stratum NBAP Node B Application Part NDI New Data Indicator NDS Non-Delay Sensitive Node B Logical node responsible for radio Tx/Rx to/from UE NRZ Non Return to Zero O
OAM Operation Administration and Maintenance OVSF Orthogonal Variable Spreading Factor P PA Power Amplifier PCCH Paging Control CHannel P-CCPCH Primary-Common Control Physical CHannel PCH Paging CHannel PCM Pulse Code Modulation PCPCH Physical Common Control CHannel PDP Packet Data Protocol PDU Protocol Data Unit PI Paging Indicator PI Priority Indicator PICH Paging Indicator CHannel PIR Partial Incremental Redundancy PLMN Public Land Mobile Network PMM Packet Mobility Management PN Pseudo Noise PQ Priority Queue PRACH Physical Random Access CHannel PS Packet Switch P-SCH Primary-Synchronization CHannel PSK Phase Shift Keying Q QId Queue Identity QoS Quality of Service QPSK Quadrature Phase Shift Keying R R4 Release 4 R5 Release 5 R6 Release 6 RA Routing Area RAB Radio Access Bearer RAC Routing Area Code RACH Random Access CHannel RAN Radio Access Network RANAP Radio Access Network Application Part RB Radio Bearer RF Radio Frequency RL Radio Link RLC Radio Link Control RM Rate Matching RNC Radio Network Controller RNS Radio network subsystem
Section 12 � Module 1 � Page 5
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionGlossary �
12 � 1 � 5
Abbreviations and Acronyms [cont.]
Switch to notes view!RNSAP Radio Network Subsystem Application Part RNTI Radio Network Temporary Identity RRC Radio Resource Control RRM Radio Resource Management RTT Radio Transmission Technology RV Redundancy Version RX Receiver / Reception S SA Service Area SAP Service Access Point SAW Stop And Wait S-CCPCH Secondary-Common Control Physical CHannel SCH Synchronization CHannel SCR Sustainable Cell Rate SDU Service Data Unit SF Spreading Factor SFN System Frame Number SHO Soft HandOver SIM Subscriber Identity Module SIR Signal to Interference Ratio SM Session Management SNR Signal to Noise Ratio SPI Scheduling Priority Indicator (CmCH- PI) SRLR Synchronous Radio Link Reconfiguration S-RNC Serving-Radio Network Controller S-SCH Secondary-Synchronization CHannel STTD Space Time Transmit Diversity T TAF That's All Folks! TB Transport Block TBS Transport Block Size TCP Transmission Control Protocol TDD Time Division Duplex TDM Time Division Multiplexing TDMA Time Division Multiple Access TF Transport Format TFC Transport Format Combination TFCI Transport Format Combination Indicator TFI Transport Format Indicator TFO Tandem Free Operation TFRC Transport Format and Resource Combination TFRI Transport Format and Resource Indicator TFS Transport Format Set TPC Transmit Power Control TrCH Transport CHannel TrFO Transcoder Free Operation TS Time Slot TTI Transmission Time Interval TX Transmitter / Transmission U
UARFCN UMTS Absolute Radio Frequency Channel Number UDP User Datagram Protocol UE User Equipment UM Unacknowledged Mode UMTS Universal Mobile Telecommunication System UP User Plane URA UTRAN Registration Area U-RNTI UTRAN-Radio Network Temporary Identity UTRAN Universal Terrestrial Radio Access Network Uu the radio interface between UTRAN and UE V VCC Virtual Channel Connection VoIP Voice over IP W W-CDMA Wideband-CDMA
Section 12 � Module 1 � Page 6
All Rights Reserved © Alcatel-Lucent @@YEAR
TMO18255 D0 SG DEN I1.0 Issue 1
All Rights Reserved © Alcatel-Lucent @@YEAR
9300 WCDMA � TMO18255 UA07 R99 Algorithms DescriptionGlossary �
12 � 1 � 6
End of Module
@@COURSENAME - Page 1All Rights Reserved © Alcatel-Lucent @@YEAR
All Rights Reserved © Alcatel-Lucent @@YEAR
@@COURSENAME@@PRODUCT
1
Last But One Page
Switch to notes view!
This page is left blank intentionally
@@COURSENAME - Page 2All Rights Reserved © Alcatel-Lucent @@YEAR
All rights reserved © Alcatel-Lucent @@YEARPassing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent