588
Copyright © 2012 Alcatel-Lucent. All Rights Reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent

TMO18255_V2.0-SG-UA08-ED1

Embed Size (px)

DESCRIPTION

alc

Citation preview

Page 1: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel-Lucent

Page 2: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

TERMS OF USE AND LEGAL NOTICE

Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training course and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These Terms of Use and Legal Notice, as well as the contents of this training course, may be updated or amended by Alcatel-Lucent from time to time without prior notice to you. Your use of the Alcatel-Lucent training materials after such update or amendment constitutes youracceptance of and agreement to said updated or amended Terms of Use and Legal Notice.

SAFETY WARNING

Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages present. Always observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to wear conductive jewelry while working on the products. Equipment referred to or used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.

PERMISSION TO USE CONTENT

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

COPYRIGHTS AND TRADEMARKS

The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and Alcatel-Lucent’s corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws, including but not limited to, copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights laws (collectively, "IP Rights"). In addition to Alcatel-Lucent’s IP Rights in the Content, in part and in whole, Alcatel-Lucent, and any of the third parties who have licensed and/or contributed to the Content, owns a copyright in the formatting and presentation of the Content.

Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these Terms ofUse and Legal Notice. All other use of Content from this training course, including, but not limited to, modification, publication, transmission, participation in the transfer or sale of, copying, reproduction, republishing, creation of derivative works from, distribution, performance, display, incorporation into another training course or presentation, or in any other way exploiting any of the Content, in whole or in part, for uses other than those expressly permitted herein is strictly prohibited and shall not be made without Alcatel-Lucent’s prior written consent. All characters appearing in this training course are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.

There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the Content. Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners. Alcatel-Lucent does not grant you a license to use any of the foregoing logos, marks, trademarks, slogans andproduct designations in any fashion. Granting of the right to access and use the Content for training purposes does not confer upon you any license under any of Alcatel-Lucent’s or any third party's IP Rights.

DISCLAIMER

ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM, DAMAGE, OR ANY SPECIAL, EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND (INCLUDING WITHOUT LIMITATION LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT LIABILITY OR OTHERWISE, THAT ARISES OUT OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE CONTENT OR THE TRAINING COURSES BY YOU, OR (B) ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS, DIRECTORS, AGENTS OR EMPLOYEES IN CONNECTION WITH THE CONTENT OR THE TRAINING COURSES (INCLUDING, WITHOUT LIMITATION, THE USE OF OR INABILITY TO USE ANY COMPONENT OF THE CONTENT OR TRAINING BY YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITIES AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITY MAY NOT APPLY TO YOU.

GOVERNING LAW

These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is governed by the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of Use and Legal Notice, or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute or a court of competent jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision that reflects the intent of the original provision as closely as possible. All other provisions of these Terms of Use and Legal Notice shall remain in full force and effect. You may not assign these Terms of Use or any permission granted hereunder without Alcatel-Lucent’s priorwritten consent. Nothing herein shall be deemed an employment agreement or an offer of employment or an alteration in any way of a user’s terms of employment with or within Alcatel-Lucent.

Copyright © 2011 Alcatel-Lucent. All Rights Reserved

Page 3: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

Welcome to UTRAN

UA08 9300 W-CDMA R99 Algorithms Description

1. W-CDMA R99 Algorithms Description

1. UTRAN Parameters and Objects

2. UTRAN Configuration

3. Services

4. Measurements

5. Call Admission

6. Power Management

7. Call Management

8. Mobility in Reselection

9. Mobility in SHO

10. Inter-Carrier Mobility in HHO

11. Inter-Carrier Mobility at RRC Connection

12. Abbreviations and Acronyms

Page 4: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.

UTRAN

UA08 9300 W-CDMA R99 Algorithms Description

Upon completion of this course, 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

� describe the main measurement purposes and use

� describe Compressed Mode principles, implementation, configuration, and impacts on other UTRAN features

� describe the mobility in Idle and the associated parameters: Cell Selection, Cell reselection

� describe the call establishment and the associated parameters: RAB Matching, IRM RAB to RB Mapping, CAC, CELL_FACH admission

� describe the packet data management principles: Always On, Rb Rate Adaptation, iRM Scheduling, iRM Preemption and associated parameters

� describe power management and control with the associated parameters

� describe Handover types and purpose: SHO, Alarm Handovers, iMCTA algorithm

Your feedback is appreciated!

Please feel free to Email your comments to:

[email protected]

Please include the following training reference in your email:

TMO18255_V2.0-SG Edition 1

Thank you!

Page 5: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Section 1 · Module 1 · Page 1

Page 6: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Section 1 · Module 1 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 7: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Section 1 · Module 1 · Page 3

Page 8: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Section 1 · Module 1 · Page 4

This page is left blank intentionally

Page 9: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Section 1 · Module 1 · Page 5

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 112 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

Page 10: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Section 1 · Module 1 · Page 6

This page is left blank intentionally

Page 11: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Section 1 · Module 1 · Page 7

Page 12: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

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 the 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 pieces of 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, etc.

Section 1 · Module 1 · Page 8

Page 13: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

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. The 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.

�Etc.

The UTRAN CIQ template highlights for each parameter the domain it belongs to (Design, IP, ATM, etc.).

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 9

Page 14: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

For the UMTS Access Network, Wireless-Network Management System provides two complementary sets of configuration tools:

�An off-line configuration tool to support network engineering.

�An on-line configuration tool to support network operations.

These two toolkits fully inter-work and provide a consistent user environment for the engineering and operations staff.

�Off-line configuration is designed to support efficient bulk configuration of the UTRAN by the engineering staff. Users can import, modify and export data, both from the UMTS access network and from 3rd 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, etc.

Section 1 · Module 1 · Page 10

Page 15: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

S = Snapshot & D = Delta

At any time during the network building steps, the datafiller can export part of his work towards other platforms.

The following Configuration Management (CM) files can be exported:

�Snapshots

�Work orders

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 11

Page 16: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Section 1 · Module 1 · Page 12

Page 17: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

The RAN model is split into two parts:

�Hardware Equipment: this part groups all elements (parameters) that define the equipment (BTS) and the Passport module (Pmod). It is the physical part of that model.

� Logical Configuration: this other part groups all elements that define 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 create a link between the Hardware Equipment (physical part) and the Logical 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 13

Page 18: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

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 14

Page 19: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

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 characteristic: they are contained in the Access OAM database.

Section 1 · Module 1 · Page 15

Page 20: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

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 the customer, either due to design or to activate optional features

�Expert_tuning:

Parameters which can be modified by the 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 the customer, without specific support from Alcatel-Lucent

This table gives an overview of the number of parameters in UA07:

Count of Object User

Domain Class Customer Manufacturer Grand Total

BTS 0 87 44 131

2 2 2

3 310 3 313

BTS Total 399 47 446

RNC 0 177 16 193

2 97 97

3 1918 8 1926

RNC Total 2192 24 2216

Grand Total 2591 71 2662

Section 1 · Module 1 · Page 16

Page 21: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Class0: value set at object creation. Parameters require a build to be implemented 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:

MO Name MO Attribute Name Class

PowerPartConfClass CallAdmissionRatio 3-a1

HSDPACellClass maximumNumberOfUsers 3-a2

Section 1 · Module 1 · Page 17

Page 22: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

The object activation class defines the object behavior with respect to the “create online” and “delete online” operations.

�Not Allowed: the object cannot 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 18

Page 23: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

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 apply 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 then corresponds to a predefined set of parameters (see example next page).

Section 1 · Module 1 · Page 19

Page 24: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

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 20

Page 25: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.1 Edition 1

Section 1 · Module 1 · Page 21

Page 26: TMO18255_V2.0-SG-UA08-ED1
Page 27: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 1

Page 28: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 29: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 3

Page 30: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 4

This page is left blank intentionally

Page 31: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 5

Page

1 RNC configuration 71.1 Identification & capacity 82 Node B configuration 92.1 FDDCell identifiers 102.2 Channel numbers 112.3 Scrambling codes 122.4 Automatic carrier switch off 132.4.1 Switch off description 142.4.2 Switch on description 152.4.3 RAN model 162.5 Node B capacity licensing 173 Neighboring cell configuration 193.1 FDDCell, RemoteFDDCell, GSMCell 203.1.1 Corresponding RAN model 213.2 UMTSFddNeighbouringCell 223.3 GsmNeighbouringCell 233.4 UmtsNeighbouringRelation 243.4.1 Example 253.5 SIB11/DCH neighboring lists 26

Page 32: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 6

This page is left blank intentionally

Page 33: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 7

Page 34: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

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 BTSs and cells depends on two major factors:

�The number of TMUs (hardware configuration)

�The software configuration.

The cnodeCapacity parameter is no longer supported from UA06.

From UA06, the service group to which a given Node B is allocated can be specified by the operator (serviceGroupId parameter of the NodeB object).

It is also possible to know on which TMU an RNC has set a given service group. Thus with these facilities, it is now possible to modify the affectation of one Node B from a given service group to another one (and consequently from a PMC-TMU to another one). This possibility may be interesting in order to better balance the load between the PMC-TMU if needed. Nevertheless, it has to be noticed that the re-affectation of one Node B from a Service Group to another one implies a loss of service on this Node B.

The number of service groups of an RNC is specified by the numberOfServiceGroups parameter of the RNC object.

The serviceGroupId parameter of the 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.

Service group id refers to a given TMU board and that numberOfServicesGroup = total number of TMU boards.

Section 1 · Module 2 · Page 8

Page 35: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 9

Page 36: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

The standardization of the Iub interface has driven 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 into 28 bits, found under the FDDCell and BTSCell objects. It is recommended to have a unique localCellId in 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 into 12 bits, defined under the RNC object and also the cellId, coded into 16 bits, defined under the FDDCell object.

Section 1 · Module 2 · Page 10

Page 37: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

The frequency of a carrier is defined:

� in uplink by the ulFrequencyNumber parameter.

� in downlink by the dlFrequencyNumber parameter.

Both parameters correspond to the UTRA Absolute Radio Frequency Channel Number (UARFCN) 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 1 · Module 2 · Page 11

Page 38: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

A UE is surrounded by Base Transceiver Stations (BTSs), 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 channel codes. 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 enables 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 is set with the primaryScramblingCode parameter of the FDDCell object. The range of the P-SC must be between 0 and 511. On the Iub interface, the system will convert this value (defined as i) using the following formula: P-SC = 16*i.

When Secondary SCq are not in use, the aichScramblingCode and the sccpchDlScramblingCode must be set to 0. The 0 value will define the AICH Scrambling Code = the Primary SC and the S-CCPCH Scrambling Code = the Primary SC.

Section 1 · Module 2 · Page 12

Page 39: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

ACSO: Automatic Carrier Switch Off

The automatic carrier shutdown in case of low traffic is supported:

� on STSR X+Y Node B where a sector is served by two MCPAs or two TRDUs.

� on STSR X+Y configurations with 2 RRHs per sector where a sector is served by 2 MCPAs.

The automatic switch off configurations allowed are STSR 1+1, STSR 2+1 and STSR 2+2.

The automatic carrier shutdown in case of power supply alarm is supported on STSR x+y with AC supply.

The procedure used to unload the cells of a carrier to be shut down is the same as the one used by the Node B Soft Shutdown feature available from UA06.

The automatic reconfiguration of the remaining carrier for HSDPA support is in restriction.

This means that if R99 is configured on F1 & HSxPA on F2 on a STSR1+1 configuration, when F2 will be shut down, the customer will lose the HSxPA coverage.

Section 1 · Module 2 · Page 13

Page 40: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Feature benefits:

�ACSO in case of low traffic allows saving energy during off-peak hours: when all the cells relating to a particular Power Amplifier of a Node B are switched off, then the Node B will switch off the Power Amplifier (the Power Amplifier is in “standby mode” : the radio power module is switched off, while the digital unit remains alive).

�ACSO in case of AC mains failures allows saving battery energy in degraded conditions: when the Node B PA loses AC mains power, backup battery takes over and the node B informs the RNC that this event occurred. The RNC starts to switch off all the cells relating to that PA. Once all the cells are switched off, the Node B will switch off the PA.

Section 1 · Module 2 · Page 14

Page 41: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 15

Page 42: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 16

Page 43: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

This feature provides the technical base for ‘Pay-as-you-grow’ commercial schemes. With a licensing scheme in place, the operator can order HW with a reduced capacity and subsequently purchase licenses for additional capacity.

Node B capacity licenses are per OMC; the operator can distribute capacity between controlled BTSs via licensing parameters.

The following Node B capacity aspects are managed in UA06 via this feature: CEM R99 capacity, CEM HSDPA capacity, CEM HSUPA capacity, xTRM capacity, RRH capacity, PA power and RRH power.

Additional capacity license is OMC wide and can be distributed between the controlled BTSs (intra-OMC). There is no exchange of licenses between OMCs.

License file: it is a file describing the total capacity (temporary or permanent) allocated for all BTSs of a given OMC. This file is protected by a digital signature.

HW Capacities: The customer can purchase HW and capacities independently.

Section 1 · Module 2 · Page 17

Page 44: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

additionalRadioPerSectorCapacityLicensing controls the number of additional radios that can be configured on each sector.

The existing UA06 parameter (rrhCarrierCapacityLicensing) represents from UA07 the number of tokens to allow the configuration of the second carriers of RRH and TRDU and supplementary carriers (3rd and 4th) if all second carriers have been configured.

The new parameter (rrhTrduThirdCarrierCapacityLicensing) defines the number of supplementary 3rd or supplementary (4rth) Rx carriers allowed for the pool of RRHs and TRDUs.

If the 2nd carrier capacity licensing is infinite, the 3rd carrier capacity licensing becomes obsolete and all 2nd and supplementary carriers will be configured following the pseudo parameter rrhNumberFrequency.

[xCEM][eCEM] The maximal capacity can be further controlled (limited) by the parameter hsdpaMaxThroughputXcem.

For xCEM and eCEM, the processing resources can be configured accordingly with the license agreement via edchMaxThroughputXcem and edchMaxThroughputEcem which indicates the maximum throughput in kbps that can be used for E-DCH traffic (MAC-e layer).

Section 1 · Module 2 · Page 18

Page 45: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 19

Page 46: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Adjacency between cells (also called Neighboring relation between cells) represents a couple of cells (A and 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 the 3G Target cell is controlled by the same RNC as the CRNC of the Serving cell.

� 3G->3G adjacencies where the 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 CRNC of the Serving cell.

� 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 2G Target cell in the CRNC of the Serving cell.

Section 1 · Module 2 · Page 20

Page 47: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

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 1 · Module 2 · Page 21

Page 48: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

In this example, two 3G->3G adjacencies are defined:

� B->A where both serving cell B and target cell A are controlled by the same RNC1.

� B->C where serving cell B is controlled by RNC1 and target cell C is controlled by RNC2.

B->A adjacency:

FDDcellB and FDDCellA objects being defined under RNC1, the B->A adjacency is configured by creating underFDDCellB 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 configuredin 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 userLabelparameter value set to C.

Section 1 · Module 2 · Page 22

Page 49: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

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 parametervalue set to E.

Section 1 · Module 2 · Page 23

Page 50: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

In the 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 parameters cannot 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 1 · Module 2 · Page 24

Page 51: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

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, theconfiguration shall be done in two steps:

1. by creating under RNC1 a UmtsNeighbouringRelation object instance having its userLabel parameter setto Outdoor->Outdoor (for instance).

2. by setting for UMTSFddNeighbouringCellB child object of FDDCellA its umtsNeighRelationId parametervalue set to Outdoor->Outdoor.

A->C adjacency:

A->C Cell Reselection parameters shall be set to the Outdoor->Indoor type of reselection. Therefore, theconfiguration shall be done in two steps:

1. by creating under RNC1 a UmtsNeighbouringRelation object instance having its userLabel parameter setto Outdoor->Indoor (for instance).

2. by setting for UMTSFddNeighbouringCellC child object of FDDCellA its umtsNeighRelationId parametervalue set to Outdoor->Indoor.

Section 1 · Module 2 · Page 25

Page 52: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Neighboring:

� DCH: max 96 (32 intra-freq + 32 inter-freq + 32 GSM)

� Idle, PCH, FACH: max (intra-freq+inter-freq+GSM)

� Max 96 if isEnhancedSib11Allowed = True

� Max 48 if isEnhancedSib11Allowed = False

� isSib11MeasReportingAllowed:

� True: the UE will use intra-freq neighboring in SIB11/SIB12 in DCH state (in addition to idle, PCH, FACH) until it receives the list in an RRC measurement control message.

� False: when the UE enters the DCH state, it must wait for the RRC measurement control message to get the measurement list.

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: the RNC reads sib11OrDchUsage to compute the neighboring lists

� automatic: the 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 1 · Module 2 · Page 26

Page 53: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.2 Edition 1

Section 1 · Module 2 · Page 27

Page 54: TMO18255_V2.0-SG-UA08-ED1
Page 55: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 1

Page 56: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 57: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 3

Page 58: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 4

This page is left blank intentionally

Page 59: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 5

Page

1 Radio bearers 71.1 Signaling Radio Bearers (SRBs) 81.2 Conversational radio bearers 91.3 Streaming radio bearers 101.4 Interactive/background radio bearers 112 Services 132.1 Mono and multi-RAB services - examples 142.1.1 DCH 162.1.2 HSxPA 173 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

Page 60: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 6

This page is left blank intentionally

Page 61: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 7

Page 62: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

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 UA07. Thus, the flag isSrb5Allowed must be set to false.

Section 1 · Module 3 · Page 8

Page 63: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

The standard voice call consists of two narrowband (300-3400 Hz) sound channels, one in each direction, and that operate independently.

�CS_AMR_NB stands for AMR Narrow Band RB for which AMR NB voice codecs used allow 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 from UA07.1.2.

Section 1 · Module 3 · Page 9

Page 64: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

PS_xxx_STR RB >= 256 kbps are provided for High Quality streaming services which require a higher bandwidth.

Section 1 · Module 3 · Page 10

Page 65: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

PS_xx_IB_MUX RB corresponds to a UE having simultaneously several PS RABs established.

There might be several situations during which UTRAN is required to manage 2 simultaneous PSInteractive/Background RABs for a given user identified by a single RRC connection:

�A user activates a primary PDP context and a secondary PDP context in order to open bearers with differentqualities of service towards a given Access Point Name (APN).

�A user activates two primary PDP contexts, each of them corresponding to a different APN.

In case of 2 PS RAB configuration, the 2 RLC flows are multiplexed at MAC layer into a single Mac-d flow.

Example:

UA08: new RAB combinations:

This feature introduces the new RAB combinations:

� 3 PS I/B RABs handling over HSUPA/HSDPA (E-DCH/HS-DSCH)

� 3 PS I/B over HSDPA (one streaming RAB + 2 PS I/B)

� 3 PS I/B Mux over DCH

� UL 384+384 Mux (the existing support is only 128+128 Mux for UL)

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 1 · Module 3 · Page 11

Page 66: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 12

Page 67: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 13

Page 68: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Before UA07, CS AMR NB versions were NB1: [12.2, 7.95, 5.9, 4.75] and NB2: [10.2, 6.7, 5.9, 4.75]

From UA07 onwards, CS NB2 becomes [12.2, 7.4, 5.9, 4.75]

Section 1 · Module 3 · Page 14

Page 69: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 15

Page 70: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

UA08: new RAB combinations:

This feature introduces the new RAB combinations:

� 3 PS I/B RABs handling over HSUPA/HSDPA (E-DCH/HS-DSCH)

� 3 PS I/B over HSDPA (one streaming RAB + 2 PS I/B)

� 3 PS I/B Mux over DCH

� UL 384+384 Mux (the existing support is only 128+128 Mux for UL)

Additionally, multi-service configurations are supported with:

� CS Voice AMR NB (UL/DL 12.2 kbps or 12.2/7.95/5.9/4.75 kbps or 12.2/7.4/5.9/4.75 kbps, with VAD/DTX)

� CS Voice AMR WB (12.65/8.85/6.6 kbps with VAD/DTX)

Section 1 · Module 3 · Page 16

Page 71: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

PS Streaming on HSDPA

UL: 16, 32, 64, 128

DL: Max Bit Rate depending on UE Category & GBR

Section 1 · Module 3 · Page 17

Page 72: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 18

Page 73: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 19

Page 74: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

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 the Iu User Plane Frame protocol V1 (see 3GPP TS 25.415). Other configurations required Iu UP FP V2.

Section 1 · Module 3 · Page 20

Page 75: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

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 that are most sensitive to errors. Any error in these bits would result in a corrupted speech frame which would need error correction for proper decoding. It is the only class protected by a CRC.

�Classes B and C contain bits for which increasing error rates gradually reduce the speech quality. However, the decoding of an erroneous frame can be done without significantly degrading the quality.

Section 1 · Module 3 · Page 21

Page 76: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

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 (3.85k 15.85k 12.65k 8.85k and 6.6k). The other modes are used for other services (e.g., for MMS).

SUPPORTED AMR WIDE BAND CONFIGURATIONS

From UA05.1, only TS 26.103 AMR-WB configuration #0 (Active Codec Set (ACS) 12.65 8.85 & 6.60) is supported. The 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 1 · Module 3 · Page 22

Page 77: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

The new CS NB2 configuration (12.2, 7.4, 5.9, 4.75) is supported as a replacement of (10.2, 6.7, 5.9, 4.75) kbps.

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 setup. 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 the TFO/TrFO scenario when the distant UE changes its bit rate (also when the 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 power is closed to the maximum. In this case, the UE can reduce its AMR rate.

Section 1 · Module 3 · Page 23

Page 78: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 24

Page 79: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

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 set up

�Authorized TFC subset list to be used in UL.

SRB 5 is set up 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.

Starting from UA07, 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 UA05.0, the initial AMR codec used at call setup was fixed and equal to the maximum rate allowed among the ones of the Multi-mode configuration used.

In UA05.1, the initial AMR codec used at call setup could be chosen by the operator thanks to the two following parameters:

� isMaxDlAmrRateConfiguredAllowed is the activation flag for control of the maximum downlink rate for AMR Narrowband calls based on provisioned cell parameters.

�maxDlAmrRateConfigured is the maximum downlink rate for Narrowband AMR calls in the cell.

isCsRabModificationForSpeechAllowed is the activation flag for CS RAB modification between AMR NB and AMR WB configuration.

Currently, SRB#5 is not used since it is not supported by all UEs.

Section 1 · Module 3 · Page 25

Page 80: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.3 Edition 1

Section 1 · Module 3 · Page 26

Page 81: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 1

Page 82: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 83: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 3

Page 84: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 4

This page is left blank intentionally

Page 85: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 5

Page

1 UMTS measurement principles 71.1 Reported measurements 81.2 Measurements elaboration 91.3 Measurements activation 102 Main measurements 112.1 Cell sets 122.2 Power measurements 132.3 Signal to Interference Ratio (SIR) 142.4 Path loss 152.5 QE and CRCI 163 NBAP measurement procedures 173.1 NBAP measurement initiation 183.2 NBAP measurement reports 193.3 Call Trace (CT) 203.4 Event triggered reports 213.5 Example: event A 224 RRC measurement procedures 234.1 RRC measurement initiation 244.2 Intra-frequency measurements reporting – periodical mode 254.3 RRC measurements on RACH 264.4 Fast measurements at call establishment 275 Event triggered reporting of RRC measurements 285.1 Intra-frequency measurements reporting – event mode 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 336 In-Band measurement procedures 346.1 RACH & DCH FP measurements 357 Compressed mode 367.1 CM scope & methods 377.2 Need for compressed mode 387.3 High-level scheduling method 397.4 HLS activation 407.5 CM pattern sequences 417.6 Pattern sequence configuration 427.7 FDD Inter-Freq CM pattern 437.8 GSM Inter-RAT CM pattern 44

Page 86: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 6

This page is left blank intentionally

Page 87: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 7

Page 88: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 also provides measurement 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.

From UA05, the Node B only removes the contribution of HSDPA channels (it does 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.

Path loss (Inter System Measurements): this measurement figures in the reporting message in the UMTS specifications but does not correspond to any measurement defined in the GSM specifications.

This measurement is not managed by the RNC.

Section 1 · Module 4 · Page 8

Page 89: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 to the shortest reporting period, i.e. the Node B or UE cannot be required to report a measurement to the RNC in a shorter time period.

Before reporting to the RNC, the Node B or UE Layer 3 performs a filtering operation averaging several measurements and allowing them to create measurement 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 Node B 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 Node B to the serving RNC.

Section 1 · Module 4 · Page 9

Page 90: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Each FDDCell and NeighbouringRNC must have a pointer to one of the Measurement Configuration Classes stored under the RNC they depend upon.

The isEventTriggeredMeasAllowed parameter controls the activation of Full Event Triggered RRC measurement reports per FDDcell.

The isInterFreqMeasActivationtAllowed parameter controls the activation of inter-frequency RRC measurement reports whether Inter-FDD or Inter-RAT neighboring cells are to be measured.

�The IsInterfreqCmodeActivationAllowed parameter controls the activation of the compressed mode for inter-FDD neighboring cell measurements.

�The isGsmCmodeActivationAllowed parameter controls the activation of the compressed mode for inter-RAT neighboring cell measurements.

When set to true, the UeInternalMeasurementQuantity parameter allows one to choose which measurement type is selected among the three available types: ueTransmittedPower, utraCarrierRssi, ueRxTxTimeDiff.

Note: UeIntMeas is an optional object.

Section 1 · Module 4 · Page 10

Page 91: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 11

Page 92: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

There are 3 different ways to classify the cells that may be involved in handover procedures:

�The cells belonging to the Active Set are the cells involved in the soft handover and that are communicating with the UE.

�The 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.

�The 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 cells of the detected set have to be taken into account for RRC Intra-Frequency measurement management for the calls established in Event-Triggered Reporting Mode.

Section 1 · Module 4 · Page 12

Page 93: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 1 · Module 4 · Page 13

Page 94: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 algorithms.

SIR Error

�A 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 are triggered to the RNC (RRC).

Section 1 · Module 4 · Page 14

Page 95: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

The path loss is calculated by the UE and by the RNC using the following formula: Path Loss = Primary CPICH Tx Power - P-CPICH_RSCP

The RNC does not ask the UE to send the path loss, because the RNC can calculate it directly.

The path loss calculated by the RNC is used for inter-frequency handover criteria evaluation.

The path loss calculated by the UE is used to define the initial PRACH power.

Section 1 · Module 4 · Page 15

Page 96: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

CRC INDICATOR

�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 (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 Node B 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, then the Node B calculates the BER of the transport channel measured on DPDCH per TTI (if no DPDCH is sent, then the Node B will use DPCCH BER).

� non-selected, then the Node B calculates the BER of the physical channel measured on DPCCH per TTI.

� 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) frames. 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 1 · Module 4 · Page 16

Page 97: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 17

Page 98: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 1 · Module 4 · Page 18

Page 99: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 commonRepType parameter [on demand, periodic, event-triggered].

The quantity measured is defined by the measQuantity parameter.

The periodicity is given in the Report_Periodicit yIE of the measurement request message.

The periodicity is given in the Report_Periodicity IE of the measurement request message and corresponds to the 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 measurements.

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 stop upon reception of COMMON MEASUREMENT TERMINATION REQUESTs sent by the CRNC if any.

Section 1 · Module 4 · Page 19

Page 100: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 an 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 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 1 · Module 4 · Page 20

Page 101: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

The 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 purposes of iRM Scheduling, the RNC configures the Node B with one Event A and two Events B:

� Event A indicates 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 indicates that the radio conditions have become good enough to attempt an upgrading towards the original requested RB.

� Event B2 indicates 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 1 · Module 4 · Page 21

Page 102: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

In order to be able to perform IRM Scheduling downgrade, the RNC configures the 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 pcpichPower (FDDCell) and maxDlTxPowerPerOls (DlUsPowerConf) parameters.

�Measurement Hysteresis: timeToTrigger.

So Event A is reported when the transmitted code power is above the TxCP absolute threshold during at least the time to trigger.

Section 1 · Module 4 · Page 22

Page 103: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 23

Page 104: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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, etc.).

�measurement type indicates one of the different types of measurement: inter-frequency, intra-frequency, etc.

�measurement object indicates the object on which the measurement shall be performed.

�measurement quantity indicates the quantity to be measured (RSCP, SIR, etc.).

�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 the acknowledged or unacknowledged RLC mode.

Section 1 · Module 4 · Page 24

Page 105: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 RepMode parameter indicates that the UE shall report measurements on cells of the active set and intrafrequency monitored set cells. This STATIC parameter is set to ACTIVE_SET_AND_MONITORED_ON_FREQ.

The maxCellsRepType parameter indicates the number of measured cells belonging to the monitored set. This STATIC parameter is set to 6.

Section 1 · Module 4 · Page 25

Page 106: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Measurements reported in the RACH message are used by power allocation and RAB assignment algorithms.

The measQuantity static parameter determines the type of reported measurements. Only the value CPICH_Ec/No is supported by the measQuantity static parameter.

The sib11IntraFreqMeasurementNbrOfCellOnRACH parameter 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 neighbors.

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 reasons, sib11IntraFreqMeasurementNbrOfCellOnRACH is set to the “currentCell” value in USA customer templates.

Section 1 · Module 4 · Page 26

Page 107: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 the 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 measurements.

If the reporting mode is “Periodic”, the UE keeps on sending reports at the defined period until 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 that there is no misalignment between the UE and the Network.

The 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 reception of the RRC Measurement Control message.

If isSib11MeasReportingAllowed is set to True, the serving cell has to be present in the neighboring intra freq cells list present in SIB11, thereby reducing the maximum number of neighbor cells by 1.

If isSib11MeasReportingAllowed is set to False, SIB11 and SIB12 do not include these IEs and the UE must wait for the first RRC Measurement Control to measure neighboring cells when entering Cell_DCH.

Section 1 · Module 4 · Page 27

Page 108: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 28

Page 109: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 1 · Module 4 · Page 29

Page 110: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 1 · Module 4 · Page 30

Page 111: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

In ALU UTRAN:

�RRC inter-frequency measurements on aused frequency are event-triggered (2D and 2F).

�RRC inter-frequency measurements on a 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 1 · Module 4 · Page 31

Page 112: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 1 · Module 4 · Page 32

Page 113: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Event 1A is triggered when a new P-CPICH enters the reporting range.

Event 1A is used to add an 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 efficiently monitor its network and optimize its neighboring plan, it is possible totrigger this event 1A based on both Detected Set and Monitored Set.

� In order to achieve this, the isDetectedSetCellsAllowed parameter shall be set to True.

� From UA07 onwards, the decision if the cells from Detected Set are used in the mobility algorithms depends on the detectedSetCellAddition flag.

Section 1 · Module 4 · Page 33

Page 114: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 34

Page 115: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 1 · Module 4 · Page 35

Page 116: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 36

Page 117: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

The 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.

The 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 GSMor 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 the normal mode.

Section 1 · Module 4 · Page 37

Page 118: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 the 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 the 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 the 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 the Compressed Mode is needed by the mobile for that frequency band, it will be configured accordingly and possibly activated by the network.

Section 1 · Module 4 · Page 38

Page 119: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 the OVSF code needs to be changed. The new one is the parent code of the code used for non-compressed radio frames.

In downlink, the scrambling code management is done through the alternate scrambling code method. This method consists in 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 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 UA06, only SF/2 method was supported, whatever RAB, and CM method was uniquely defined using the dlCModeMethod and ulCModeMethod parameters under the CModePatternSeqInfo object.

In UA06, 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 the isHlsCmMethodPreferred parameter defined per DlUserService and UlUserService.

Parameters defined under CmodePatternSeqInfo are no longer used. However, they are still present in the RAN Model and will be removed in the coming releases.

Section 1 · Module 4 · Page 39

Page 120: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

In UA06.0 implementation, HLS is limited to only certain combinations:

� PS I/B (mono or MUX) > 8 kbps

� CS speech + (PS I/B > 16 kbps)

� CSD64 + (PS I/B > 64 kbps)

� (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)

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, the RNC checks isHlsCmMethodPreferred with respect to the method(s) supported in UA06.0 by this UserService

� Hardcoded in the RNC for each UserService (SF2, HLS, SF2ANDHLS or N/A)

Section 1 · Module 4 · Page 40

Page 121: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

The 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: the number of times the Transmission Gap Pattern is repeated within the Transmission Gap Pattern Sequence.

Section 1 · Module 4 · Page 41

Page 122: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

A certain number of pattern sequences can be defined in the 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 1 · Module 4 · Page 42

Page 123: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 measurement processes that can be seen as a sort of endless loop, intending to identify the best neighboring cells.

Measurement results are sent to the RNC with periodical measurement reports.

Section 1 · Module 4 · Page 43

Page 124: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

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 toidentify the BSICs of the required number of cells. As a consequence, it is better to choose the compressedmode patterns for this operation first and then build the patterns for GSM RSSI measurements around thispattern.

That’s the reason why:

� a transmission gap shorter that 14 has been chosen in order to allow good performance on BSICidentification.

� 8 patterns of 6x10ms have been allocated to RSSI measurements since the measurement period for theGSM 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 bereported in the worst case (e.g. when it takes up to nIdentifyAbort to identify each cell).

Section 1 · Module 4 · Page 44

Page 125: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.4 Edition 1

Section 1 · Module 4 · Page 45

Page 126: TMO18255_V2.0-SG-UA08-ED1
Page 127: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 1

Page 128: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 129: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 3

Page 130: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 4

This page is left blank intentionally

Page 131: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 5

Page

1 Paging 71.1 Paging DRX cycle 81.2 Paging repetition 92 Access preambles & acknowledgment 102.1 Preambles transmission 112.2 Acknowledgement transmission 122.3 Preambles retransmission parameters 133 RRC connection establishment 143.1 RRC connection setup 153.2 UL interference CAC on RACH 163.3 RRC connection rejection 173.4 RRC speech redirection 183.5 FACH power control as the type of DL traffic 223.5.1 FACH power adjustment 233.5.2 RRC connection setup repetition 244 RAB matching principles 254.1 RAB request vs. UserServices configuration 264.2 Matching main steps 275 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 336 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 target RB selection algorithm 476.12 UL radio load estimation without RSEPS 486.12.1 Self-learning of RTWPref 496.12.2 Calculation in Node B 506.12.3 Calculation in RNC 516.13 UL load estimation with RSEPS: calculation in RNC 526.14 UL IRM on cell color 536.15 UL cell color calculation 546.16 iRM target UL RB rate determination 556.17 UL iRM radio load parameters 566.18 UL iRM CEM load parameters 576.19 UL iRM table parameters 586.20 Exercise: iRM UL 596.21 iRM CAC for PS streaming RAB 627 iRM CAC: admission control & resource reservation 637.1 UL radio load token for high data rate 647.2 Transport resource reservation – Equivalent Bit Rate (EBR) 667.3 DL reserved power computation 677.4 DL power admission criteria 687.5 DL power self tuning 69

Page 132: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 6

Page

7.5.1 Example 707.6 OVSF codes reservation & admission 718 CELL_FACH admission control 728.1 CELL_FACH admission control 73

Page 133: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 7

Page 134: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 the Core Network domain.

The value of k is controlled in the Alcatel-Lucent’s solution by two parameters, one by the 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 1 · Module 5 · Page 8

Page 135: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

In areas 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 losses, the UTRAN can repeat the paging request so as to increasethe 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 times 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).

New UA07.1.2:

When searching for the next free Paging Occasion (PO) for a paging type 1, the RNC shall consider only POs within the timegiven by the new parameter tpageVal. If no free PO is found within this time then the RNC shall discard the paging.

The RNC timer tpageVal should be aligned with the core network (MSC and SGSN) paging repetition timers.

Notes:

A PO is considered as free if the paging message has room left to add the new paging.

If the feature paging repetition is enabled and a PO contains RNC repeated pagings then these are removed if required toadd the 'fresh' paging. This is existing UA05.0 functionality from feature 24075.

If paging repetition is enabled then the RNC shall schedule repeated paging only within time tpageVal.

If the value of parameter tpageVal is changed then the RNC shall keep already scheduled pagings unchanged. The newvalue applies for new pagings only.

Section 1 · Module 5 · Page 9

Page 136: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 10

Page 137: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 preambleThreshold parameter 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 rachSubChannels parameter 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 1 · Module 5 · Page 11

Page 138: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 1 · Module 5 · Page 12

Page 139: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 1 · Module 5 · Page 13

Page 140: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 14

Page 141: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 1 · Module 5 · Page 15

Page 142: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 maxULInterferenceLevelparameter.

� 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 1 · Module 5 · Page 16

Page 143: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 waitTimeOnRrcConnectionRejection parameter is in seconds and the value 0 indicates that the repetition is not allowed.

Notes:

�SRB CAC: The RNC will check that the resources required to support the SRB (e.g. power and codes) are available.

�Max UE contexts: The RNC checks that the maximum number of concurrent UE contexts will not be exceeded

Section 1 · Module 5 · Page 17

Page 144: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 1 · Module 5 · Page 18

Page 145: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

From UA07 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.

Note: Green < Yellow< Red < Black

Section 1 · Module 5 · Page 19

Page 146: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

The RRC Connection Request initiated by the UE contains the establishment cause.

The other conditions that must be fulfilled are explained in the next slide.

If the call is eligible to the 3G-2G redirection criterion, an RRC Connection Reject is sent to the UE with redirection info included and may include the GSM target cell info list IE.

The RNC always sends the GSM target cell Info List whatever UE release (R99, R5, R6, R7).

Section 1 · Module 5 · Page 20

Page 147: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

For R5 & R99 Mobiles, no differentiation in the RRC Connection IE between video & voice thus: risk to move video calls in 2G is to be considered.

Upon receiving the RRC Connection Reject message from UTRAN, the UE will process the GSM cell selection process using or not the GSM target cell info and will attempt an 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 1 · Module 5 · Page 21

Page 148: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

The feature differentiates the power level used for FACH channel depending on whether data or signaling is transmitted.

From UA07, 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 signaling 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 Signaling Radio Bearer data or Traffic Radio Bearer data (new option from UA07).

isFACHpowerdifferentForSRBtraffic allows one 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 1 · Module 5 · Page 22

Page 149: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 the RRC Connection Setup message. For other messages, the 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 levels (isFachPowerAdjustmentActivated).

If the quality measurements of either Ec/No (by default) or RSCP is below the threshold, the FACH power adjustment will be performed.

fachPowerAdjustmentCpichEcNoThreshold represents the absolute thresholds of PCPICH quality measurements which activate the feature. If Ec/No is below the threshold, the FACH power adjustment will be performed.

Section 1 · Module 5 · Page 23

Page 150: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 the RRC Connection Setup Complete message from the UE has not been received within the duration of T351 timer.

The retransmission of the RRC Connection Setup message based on a quicker timer T351 than T300 reduces the call setup duration. By reducing the need for 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, that is; CPICH EC/No < fachPowerAdjustmentCpichEcNoThreshold + deltaCpichEcNoUsedQuickRepeat. 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.

T352 is the Alcatel-Lucent Timer to control the release of UE call context by the RNC.

Section 1 · Module 5 · Page 24

Page 151: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 25

Page 152: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 the RNC, using the RAB matching algorithm.

Section 1 · Module 5 · Page 26

Page 153: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 an 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 1 · Module 5 · Page 27

Page 154: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 28

Page 155: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 enableRabNegotiation flag 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 negotiating 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 enableRabNegotiation activation flag 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 1 · Module 5 · Page 29

Page 156: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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

o {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 1 · Module 5 · Page 30

Page 157: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

The following table shows an example of the Streaming Radio Bearer Table.

Note: Streaming over EDCH is an optional feature/service supported from release UA07.1.2.

Section 1 · Module 5 · Page 31

Page 158: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

From all Radio Bearers defined in the RNC, the RNC selects the Radio Bearers (DlRbSetConf and UlRbSetConf) having the following properties:

� It is eligible to RbSet Matching (EnabledForRabMatching parameter)

�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 1 · Module 5 · Page 32

Page 159: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 UA07.1.2

Section 1 · Module 5 · Page 33

Page 160: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 34

Page 161: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 next slides).

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 is 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 the "Initial Rate Capping during RB reconfiguration" feature:

isOamCappingOfDataAllowed = False isOamCappingOfDataAllowed = True

Max UL RB bit rate = maxUlEstablishmentRbRate maxUlRateRabEstablishDchAndDch

Max DL RB bit rate = maxDlEstablishmentRbRate maxDlRateRabEstablishDchAndDch

Section 1 · Module 5 · Page 35

Page 162: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 respectively represent 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.

�Olympic Service Level (OLS) is either Gold or Silver or Bronze according 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 1 · Module 5 · Page 36

Page 163: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 the 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 1 · Module 5 · Page 37

Page 164: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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.

�Node B color is derived from an Iub bandwidth occupancy and CEM processing load.

So, 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 deactivatesthe Computation of Downlink Iub load color and its aggregation in the global cell color.

bwPoolCellColor controls whether Iub downlink usage will be included in the 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 the iRM CAC algorithm. Therefore if CEM load criterion is not to be used in iRM CAC although CEM load is being computed for iMCTA feature, then:

� The isCEMColourCalculationEnabled parameter has to be set to TRUE

� The isCEMModelValidForDlColour parameter has to be set to FALSE

� In this case, the CEM Color used in iRM CAC will be equal to the dlCEMColourDefaultValue parameter value.

Section 1 · Module 5 · Page 38

Page 165: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 Node B 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 1 · Module 5 · Page 39

Page 166: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 1 · Module 5 · Page 40

Page 167: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

The RAB to RB mapping function consists in 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 chooses 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 1 · Module 5 · Page 41

Page 168: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 42

Page 169: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 43

Page 170: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 44

Page 171: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 45

Page 172: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 46

Page 173: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 terms of offered QoS and NodeB/Cell available resources.

This minimizes blocking and call drops.

Section 1 · Module 5 · Page 47

Page 174: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

The way to control the Uplink traffic QoS is to maintain the UL load under a 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 site conditions. It is therefore varying in time.

Due to these constraints, UL load cannot be controlled based on direct UL RTWP measurements => Needs for enhanced estimation.

Therefore in order to improve the accuracy of the R99 UL CAC algorithm, the Node B 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 Node B in the Common Measurement Report should be the RTWP expressed in dBm, the Node B adds a fixed reference value equal to –106.1dBm to the actual RoT.

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.

RSEPS: Received Scheduled E-DCH Power Share

When the RSEPS measurements are deactivated, the BTS reports only the RTWP measurements.

If we activate the RSEPS measurements, the RNC configures NBAP common measurements to report periodically:

�Total_RTWP

�Reference_RTWP

Section 1 · Module 5 · Page 48

Page 175: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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.

The feature Self learning of RTWP ref is used in the two cases: UL Radio Load Estimation Without RSEPS & UL Radio Load Estimation With RSEPS.

Section 1 · Module 5 · Page 49

Page 176: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

The non E-DCH load is obtained by substracting 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 1 · Module 5 · Page 50

Page 177: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 Measurements.

Section 1 · Module 5 · Page 51

Page 178: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

When the RSEPS measurements are activated:

� The RNC configures NBAP common measurements to periodically report:

� Total RTWP

� Reference RTWP

� The RNC configures Received Scheduled Edch Power Share (RSEPS) measurements to report the Edch power ratio.

WARNING: if RSEPS are activated, the #303 UL_RSSI counter gives the actual total RTWP whereas in UA05 it corresponded to “-106.1dBm + RoT_non_Edch”.

Section 1 · Module 5 · Page 52

Page 179: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 the CEM load criterion is not to be used in iRM CAC although CEM load is being computed for iMCTA feature, then:

�The isCEMColourCalculationEnabled parameter has to be set to TRUE .

�The 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 1 · Module 5 · Page 53

Page 180: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 1 · Module 5 · Page 54

Page 181: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 55

Page 182: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 56

Page 183: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 57

Page 184: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 58

Page 185: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 59

Page 186: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 60

Page 187: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 61

Page 188: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Alcate-Lucent implements PS streaming Radio Bearers (RBs) since UA04.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 was introduced in UA04.2 and PS256kbps was introduced in UA05.

Since high bit rate RBs 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 1 · Module 5 · Page 62

Page 189: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 63

Page 190: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

The costs associated to each UlUserService have been evaluated using UL RSSI measurement and depend on the data rate or spreading factor SF:

� In order to control the admission for the high data rate (upon SF 8) and not the “low” data rate and to guarantee the old network capacity for these services, the cost of the “low” data rate (SF greater than 8) is set to zero.

� For high data rate bearer (SF ≤ 8), the cost depends on the throughput and on the SF.

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 the ulCostForUlTokenCac parameter.

�At each allocation, release or reconfiguration of a UL resource, the UL load is incremented, decremented or adjusted in function of the source and target UL RAB costs.

�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 UL RB Rate Adaptation feature if possible (see Packet Data Management section).

Section 1 · Module 5 · Page 64

Page 191: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Node B hardware resources are usually properly dimensioned to process the achievable cell rate. However, there are some scenarios where the bottleneck is not the Node B 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 an 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 and 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 1 · Module 5 · Page 65

Page 192: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Each Radio Bearer has a cost called Equivalent Bit Rate (EBR) which represents the amount of bandwidth to reserve for the bearer, to guarantee acceptable QoS (delays, errors, etc.).

When the RNC performs resource reservation, it simultaneously covers resource allocation and admission control (check if necessary resources are available).

First step of resource allocation aims at picking up an AAL2 connection and a CID according to the load balancing and cid selection methods chosen.

A call admission control at ATM level is then performed by the RNC in order to prevent admission of AAL2 connections in excess of the available transport bandwidth.

This CAC applies to all AAL2 based interfaces: Iub, Iur and IuCs.

Each time a new CID needs to be allocated, the AAL2 link CAC checks, according to the CAC method configured (cacmethod parameter), whether the cost of the call (EBR) to be allocated fits in the remaining available bandwidth. If it doesn’t fit, the CID cannot be allocated.

AAL2 CAC can be performed at different level:

• Aal2 interface (cacmethod parameter put to Aal2If) : AAL2 CAC is performed based upon the available bandwidth of all AAL2 VCCs of a given interface.

• QoS (cacmethod parameter put to QoS): AAL2 CAC is performed based upon the available bandwidth of groups of Vcc sharing the same quality of service . This method only applies to Iub and Iur, as there is only one quality of service used on IuCS UP Vcc

• Vcc (cacmethod parameter put to path): Introduced in UA05.0. In this case, AAL2 CAC is performed based upon the available bandwidth of a given Vcc, so that the path cannot be overbooked.

Section 1 · Module 5 · Page 66

Page 193: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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.

As the names indicate:

� the object Class2CellReconfParams contains Class 2 parameters.

� the object Class3CellReconfParams contains Class 3 parameters.

On 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 sends the Cell Reconfiguration procedure.

On 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 1 · Module 5 · Page 67

Page 194: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 1 · Module 5 · Page 68

Page 195: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 1 · Module 5 · Page 69

Page 196: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 1 · Module 5 · Page 70

Page 197: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 Dynamic DL Code Tree Management feature was introduced in UA05 in order to avoid R99 code blocking.

Section 1 · Module 5 · Page 71

Page 198: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 72

Page 199: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

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 tokens 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 1 · Module 5 · Page 73

Page 200: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.5 Edition 1

Section 1 · Module 5 · Page 74

Page 201: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 1

Page 202: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 203: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 3

Page 204: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 4

This page is left blank intentionally

Page 205: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 5

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 122 PRACH Power Control 132.1 PRACH open loop 143 UL DPCCH Open Loop Power Control 153.1 DPCCH open loop power control 163.2 UL gain factors 174 Outer loop power control 184.1 SIR target management 194.2 Partial SIR target update 204.3 OLPC based on Quality Estimator: QE 214.4 Accelerated SIR target convergence based on QE 235 UL inner loop power control 245.1 DPCCH inner loop power control 255.2 UL inner loop power control 265.3 UL power control algorithms 275.4 UL inner loop algorithm 1 285.5 UL inner loop algorithm 2 (no SHO case) 295.6 UL inner loop algorithm 2 (SHO case) 306 DL traffic channel power 316.1 Initial DL traffic channel power 326.2 DL DPCCH / DPDCH power offsets 336.3 DL power offset 2 as a function of the AS size 347 DL outer loop power control 357.1 DL outer loop power control 368 DL inner loop power control 378.1 DL inner loop algorithm 388.2 Power balancing 398.3 Rate reduction algorithm 409 Radio link control 419.1 UL dedicated channel synchronization 429.2 UL radio link failure – detected by UTRAN 439.3 DL radio link failure – detected by UE 449.4 DL RLC unrecoverable error – detected by UTRAN 459.5 UL RLC unrecoverable error – detected by UE 469.6 RRC connection re-establishment parameters 479.7 UL Radio Link Failure – RRC Connection Re-established 489.8 UL RLC unrecoverable error – RRC con. re-established 499.9 RRC connection re-establishment - summary 50

Page 206: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 6

This page is left blank intentionally

Page 207: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 7

Page 208: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 an MCPA board. If maxPowerAmplification is set to the fullMode value then Max PA Power value depends on the HW type of the MCPA board. For instance, it is equal to 46.5 dBm for a 45-W MCPA and to 47.8 dBm for a 60-W MCPA?.

As the names indicate:

� the class2CellReconfParams object contains Class 2 parameters.

� the class3CellReconfParams object contains Class 3 parameters.

On RNC side, depending on the value of the isCellReconfSupported parameter (NodeB), the RNC knows if the Node B supports the Cell Reconfiguration procedure or not:

� If it does not, the Class 2 parameters are applied.

� If the Node B supports the Cell reconfiguration, the RNC takes the Class 3 parameters. When they are changed online, the RNC sends the Cell Reconfiguration procedure.

On 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 1 · Module 6 · Page 8

Page 209: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

�Computation of losses is not the same, depending on:

� externalAttenuationMainDl and externalAttenuationDivDl parameters 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 (output of the cabinet) and this point are equal to the datafilled value of externalAttenuationXXXDl.

Section 1 · Module 6 · Page 9

Page 210: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 1 · Module 6 · Page 10

Page 211: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 maxTxPower and 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) be 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.

From UA05, when evaluating the power used by common channels, the RNC considers a certain activity factor ActivityFactorCcch by which is multiplied the amount of power used by common channels as calculated prior to UA05. It better reflects the actual common channel usage when calculating the Power Load Color of a cell and the total power available for R’99 and HSDPA GBR traffic Ptraffic.

Section 1 · Module 6 · Page 11

Page 212: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 last two 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 an RRC connection is set up 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 maxAllowedUlTxPower parameter and this parameter shall be re-transmitted to the UE.

Section 1 · Module 6 · Page 12

Page 213: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 13

Page 214: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 SIB 5 and SIB7 and on CPICH RSCP measured by the UE. “power ramping step” is a UTRAN parameter sent to the UE over SIB 5.

�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 the message for PRACH CTFC0.

powerOffsetPpM1 is the power offset between the last transmitted preamble and the control part of the message for PRACH CTFC1.

Section 1 · Module 6 · Page 14

Page 215: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 15

Page 216: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 1 · Module 6 · Page 16

Page 217: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

The above figure 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 an 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 1 · Module 6 · Page 17

Page 218: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 18

Page 219: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

The initial SIR target is sent by the RNC to the Node B through the initialSirTarget parameter. This parameter is instantiated per RAB. Consequently, once the RNC has matched an 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 1 · Module 6 · Page 19

Page 220: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 UA07.1, a new parameter (enablePeriodicSirTargetUpdate) was introduced to enable or disable the periodic sending of Sir target when computed Sir Target is equal to the last value. This occurs when there is no traffic or at the Sir target boundaries.

Section 1 · Module 6 · Page 20

Page 221: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

The most important change is that the Bit Error Rate (Quality Estimator - QE) is taken into account.

This algorithm takes place only if the QE is bad.

Section 1 · Module 6 · Page 21

Page 222: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

From UA07 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 Node B 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 Node B in DCH FP UL frames. The 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 DCHs

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.

N is the number of transport blocks in the TTI.

Nerr is the number of erroneous blocks in the TTI.

Section 1 · Module 6 · Page 22

Page 223: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

The accelerated SIR Target convergence mechanism is based on a 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 1 · Module 6 · Page 23

Page 224: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 24

Page 225: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

The Uplink Power Control is controlled by the Node B which orders Power Control Commands (increase or decrease) through TPC bits in DL DPCCH channels.

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 1 · Module 6 · Page 25

Page 226: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 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 1 · Module 6 · Page 26

Page 227: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 the 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 1 · Module 6 · Page 27

Page 228: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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. This TPC_cmd is equal to 1 only if all TPC received from other Node Bs are equal to 1, otherwise, TPC_cmd is equal to -1.

Then, after deriving a unique TPC_cmd, the UE implements a power change based on the ulTpcStepSizeparameter of the UlInnerLoopConf object.

Section 1 · Module 6 · Page 28

Page 229: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 TSs).

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 TSs 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 1 · Module 6 · Page 29

Page 230: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 follows:

� 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 1 · Module 6 · Page 30

Page 231: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 31

Page 232: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

When a traffic (dedicated) channel is set up, 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 (DlUsPowerConf object). Both parameters actually provide 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 also 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 1 · Module 6 · Page 32

Page 233: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 po3ForPilotBits parameters 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 TFCs in the TFCS.

Section 1 · Module 6 · Page 33

Page 234: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 RLs involved in the call.

�The initial PO2 is provided to the Node B 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 signaling of TPC PO updates.

Section 1 · Module 6 · Page 34

Page 235: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 35

Page 236: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 1 · Module 6 · Page 36

Page 237: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 37

Page 238: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 1 · Module 6 · Page 38

Page 239: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

The objective of the 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 1 · Module 6 · Page 39

Page 240: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 the 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 1 · Module 6 · Page 40

Page 241: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 41

Page 242: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

The uplink radio link sets are monitored by the Node B, to trigger radio link failure/restore procedures. Once the radio linksets 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 Node B 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 1 · Module 6 · Page 42

Page 243: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 1 · Module 6 · Page 43

Page 244: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 1 · Module 6 · Page 44

Page 245: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 45

Page 246: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 46

Page 247: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 a 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 the UE).

Section 1 · Module 6 · Page 47

Page 248: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 1 · Module 6 · Page 48

Page 249: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

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 1 · Module 6 · Page 49

Page 250: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 50

Page 251: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.6 Edition 1

Section 1 · Module 6 · Page 51

Page 252: TMO18255_V2.0-SG-UA08-ED1
Page 253: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 1

Page 254: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 255: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 3

Page 256: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 4

This page is left blank intentionally

Page 257: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 5

Page

1 Call management overview 71.1 Call management mechanisms 82 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 Direct transition from Cell/URA_PCH to DCH 212.8.5 URA update in URA_PCH state 262.8.6 Cell update in CELL_PCH state 272.8.7 Cell update in CELL_FACH state 282.8.8 Cell reselection during Cell_Fach to Cell_DCH 292.9 PCH states configuration 302.10 AO step 2 and AO step 3 timers 312.11 Definition of isAlwaysOnAllowed (xxRbSetConf) 322.12 Exercise: find the parameter values 332.13 Mono-service PS/multi-RAB PS I/B R99 (R99 PS Mux) 342.14 Multi-service CS+PS 352.15 Recovery actions CELL_FACH admission failure 362.16 UTRAN Registration Area (URA) 372.17 User services parameters 382.18 Exercise: find the RRC states transitions 393 RB rate adaptation 413.1 RB rate adaptation principles 423.2 Traffic monitoring: UL & DL throughput 433.3 DL downsizing 443.4 UL downsizing 453.5 DL multi-stage upsizing 463.6 UL step by step upsizing 473.7 UL upsizing based on UE Buffer Occupancy 483.7.1 Event4A processing without UE Tx power info 493.7.2 Event4A processing with UE Tx power info 503.8 DL upsizing based on RNC Buffer Occupancy 513.8.1 Internal RNC event processing 523.9 Ping-pong timers 533.10 Measurement configuration 543.11 RAN model 553.12 Exercise 564 iRM scheduling 574.1 iRM scheduling principles 584.2 Event A for iRM scheduling downgrade 594.3 Events B1 and B2 for iRM scheduling upgrade 604.4 iRM scheduling upgrade 614.5 PS streaming RAB: iRM scheduling 624.6 iRM scheduling parameters for downgrade 634.7 iRM scheduling parameters for upgrade 644.8 Special case: switching between video & voice 654.8.1 Triggering VT downgrade 66

Page 258: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 6

Page

4.8.2 Triggering speech upgrade 674.8.3 RAN parameters 684.8.4 RAN parameters – neighboring RNC 694.8.5 Activation parameters 705 iRM preemption 715.1 iRM preemption algorithm 725.2 Cell color/active set color calculation 735.3 iRM preemption: UE to preempt? 745.4 iRM preemption behavior 756 Preemption process for DCH and HSDPA/HSUPA 766.1 Concepts 776.2 Eligible procedures 786.3 Eligible CAC failure cases 796.4 Internal or external CAC failures 806.5 Eligible transport channel 816.6 Eligible services 826.7 Selection of service to be pre-empted 836.8 mono-step / multi-step pre-emption 846.9 Selection of service to be downgraded 856.10 Estimation of resource de-allocation 866.11 Queuing of RAB assignment request 876.12 Exercise 1: RAB assignt queuing and pre-emption 886.13 Exercise 2: estimation of resource de-allocation 897 AMR rate change during the call 907.1 General principles 917.2 Iub DS load criteria 937.3 UL cell load criteria 947.4 DL power load criteria 957.5 DL Tx CP criteria 967.6 Parameters settings 978 PS CN requested RAB modification 1018.1 PS CN requested RAB modification 1028.2 RAB modification in a non-iur scenario with SRLR 1038.3 RAB modification in a non-iur scenario without SRLR 105

Page 259: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 7

Page 260: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Call Management is a set of reactive mechanisms performed during the call in order to improve the system capacity, by adapting the resources used by the users to different situation (traffic activity, real traffic, RF conditions, etc.):

�Always On: Downsize and upsize of user resources are performed depending on user traffic activity in DL & UL (two-step mechanism depending on whether there is low traffic or no traffic at all).

�RB Rate Adaptation: Downsize and upsize of user resources are performed depending on user real time traffic and buffer occupancy in DL & UL.

� iRM Scheduling: Downsize and upsize of user resources are performed depending on user radio conditions in DL.

� iRM Preemption: Downsize of user resources are performed depending on cell load and user priority in DL.

�Preemption: Downsize of user resources are performed depending on CAC failure and call priority in DL & UL. If downsize is not enough to free resources, some calls can be release (low priority users).

�AMR Rate Change: Downsize and upsize of user resources (codec) are performed depending on radio conditions (UL interference & DL power) and Node B resources (Baseband, Iub) in DL & UL.

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. Preemption process applies to any types of call wherease AMR rate change applies to Multi-Mode AMR calls only.

Section 1 · Module 7 · Page 8

Page 261: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 9

Page 262: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 10

Page 263: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

In Cell_PCH or URA_PCH states, although the connection is no more active, the mobile keeps its PDP contextactive.

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. Thedataflow 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 radiobearer if the high user throughput is detected.

Section 1 · Module 7 · Page 11

Page 264: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 12

Page 265: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 13

Page 266: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 14

Page 267: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 isOamCappingOfDataAllowed flag is set to False then the maxUlEstablishmentRbRate and maxDlEstablishmentRbRate parameters 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).

The rate limitation is applied only on a DCH transport channel for initial state and can be modified later by other algorithms like RRA.

Section 1 · Module 7 · Page 15

Page 268: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The objective of this 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 reports 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 neighbor cells based on a configurable threshold softHoAddThresholdOneShot.

For UEs that do not support the measurement configuration via the SIB11, the RNC can send an RRC Measurement Control message with the following settings; periodic, the Reporting Quantity EC/Io with Amount of Reporting set to 1. This is done if the 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 the same id but will overwrite the intrafrequency settings of “one shot” with new inter-RAT IE.

isSib11IntraFreqOneShotDchAllowed is an RNC flag. This flag is supposed per FDDcell from UA07.1 and corresponds to the isSib11IntraFreqOneShotDchAllowedPerCell parameter.

In UA07.0, a workaround was defined later in order to allow the activation of One shot per cell. The reserved0.FddCell parameter is used to allow cell level control of this feature.

Note: The OneShot Measurement is only valid for Cell Reselection without HCS.

Section 1 · Module 7 · Page 16

Page 269: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 UA05.0, the 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 1 · Module 7 · Page 17

Page 270: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 threshold 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 1 · Module 7 · Page 18

Page 271: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 as 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 UA07 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 1 · Module 7 · Page 19

Page 272: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 as 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 reconfigRetriesFachPch and reconfigTimeFachPch parameters.

� 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 1 · Module 7 · Page 20

Page 273: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Without direct transition from Cell/URA_PCH to DCH, direct RRC state transition from URA_PCH or CELL_PCH to CELL_DCH is supported only for multi-RAB call or upon a mobile terminating CS RAB request.

This feature extends the direct transition support to all RAB combinations and to all Always-On upsize triggers.

Section 1 · Module 7 · Page 21

Page 274: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The decision to go directly to CELL_DCH or through CELL_FACH is based on the Establishment Cause and/or the Traffic Volume Indicator (TVI) included in the Cell Update message.

This feature is an enhancement of the AO, base feature RRC & ALWAYS-ON STATES MANAGEMENT. The “ RRC & ALWAYS-ON STATES MANAGEMENT” is in charge of monitoring the radio resources allocated to a UE with regards to the actual traffic activity of the user.

FEATURE BENEFITS

Direct transition from PCH to DCH improves the user perceived latency when traffic resumes from CELL_PCH or URA_PCH. The transition delay versus the two-step transition is reduced from approximately 900 to 550 ms.

A direct transition from PCH to DCH involves a lower number of exchanged signaling messages between the UE and the RNC versus a two-step transition. Thus the signaling load of the RNC control plane can be reduced.

Direct transition can avoid the intermediate step in CELL_FACH and thus reduces the number of users in CELL_FACH state.

Section 1 · Module 7 · Page 22

Page 275: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

In 3GPP 25.331 Rel.5, the Establishment Cause has been added to the CELL UPDATE message. This can be used by the RNC to determine the target RRC state, i. e. in case of Originating Conversational Call, the RNC can move the UE to CELL_DCH directly (in the current solution, the call setup is done on Cell_FACH for PS I/B) and therefore improves the call establishment success rate.

Section 1 · Module 7 · Page 23

Page 276: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

In 3GPP TS 25.331 Rel-6, an optional IE which contains a TVI has been added to the Cell Update message. This IE is set to TRUE when the amount of data in the UE buffer is above a configured threshold, while the absence of this IE means the amount of data is lower. This can be used by the RNC to decide between CELL_DCH or CELL_FACH when traffic resumes on a PS RAB. When the RNC receives a Cell Update message with TVI set to TRUE then it moves the UE to CELL_DCH directly.

The Traffic Volume Indicator is set to TRUE when the criteria for event based traffic volume measurement reporting is fulfilled, while the absence of this IE means the criterion is not fulfilled.

Section 1 · Module 7 · Page 24

Page 277: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The second sub-feature provides configuration capability that permits operators to activate/deactivate the Always On feature for UE having Interactive RAB, with the Signaling Indication (SI) set to ‘signaling’. The operator will also be able to set different AO timers value for PS Interactive Signaling RAB by setting a desired value for the configurable parameter.

In the existing implementation, the Always-On feature is by default disabled if SI=”signaling”. The Signaling Indication is set to “signaling” by the PS Core network to inform the UTRAN that a RAB carries high layer signaling (IMS signaling, VoIP signaling, etc). Hereupon, the Interactive RAB with SI=”signaling” is supposed to carry signaling used by end-party entities to setup/release for example the streaming bearer, the initial thought that allowing AO on such a RAB could introduce latency in the streaming session setup.

However, recent feedbacks from different customers stated that on the other hand keeping all SI=”signaling” RAB in CELL_DCH is a waste of resources. For streaming, it may be pertinent not to trigger transition to CELL_FACH. But for many other IMS based applications or for proprietary applications using the Signaling Indicator, keeping the UE in CELL_DCH would result in an expensive dimensioning for Node B baseband resources (number of CEs, HSPA connections).

The AO timers for PS Interactive Signalling RAB will be set according to the regular AO timer multiplied by "psSigAoTimerCoeff".

Section 1 · Module 7 · Page 25

Page 278: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 UEs 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 1 · Module 7 · Page 26

Page 279: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 UEs 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 1 · Module 7 · Page 27

Page 280: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 28

Page 281: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

From UA07, 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 1 · Module 7 · Page 29

Page 282: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

4 AO Downsized configurations can be used thanks to the pchRRcstates parameter:

�CELL_FACH only

�CELL_FACH or CELL_PCH

�CELL_FACH or URA_PCH

�CELL_FACH or CELL_PCH or URA_PCH

Section 1 · Module 7 · Page 30

Page 283: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 31

Page 284: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The isAlwaysOnAllowed parameter in DlRbSetConf and UlRbSetConf 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 bearer is the one determined by the parameters AlwaysOnDlRbSetDchId / AlwaysOnUlRbSetDchId in case of downsize in cell DCH State or AlwaysOnDlRbSetFachId / AlwaysOnUlRbSetFachId in case of downsize in cell FACH State.

�ReleaseOnly means that there will be no intermediate downsize for this Radio Bearer. The Radio Bearer will be released when the release conditions are fulfilled.

�Disabled means that the always-on feature is disabled for this Radio Bearer.

Section 1 · Module 7 · Page 32

Page 285: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 33

Page 286: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 34

Page 287: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

CS+PS I/B 0/0(+PS I/B 0/0) for Always-On on Mono-RAB

� UA05.0 / UA05.1: when a user has a RAB CS + PS I/B calls established, the RNC managesuser 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 + PS I/B 0/0.

3. The RNC monitors the traffic on the PS RB(s) and can trigger an upsizing while the CS call is active.

o As part of this evolution:

1. when a UE is in URA_PCH or CELL_PCH and the RNC receives a request to establish a CS RAB, the 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 RAB established. This is more efficient from a resources usage point of view than CS + PS I/B 8/8 or CS + PS I/B 64/64 + PS I/B 64/64, which are allocated with the current implementation.

2. When the CS call is released and if the PS traffic is still 0/0, then the UE is moved back to URA_PCH 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 1 · Module 7 · Page 35

Page 288: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 36

Page 289: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

URA Identity is 16 bits string.

URA can overlap to avoid ping-pong at the border of several URAs.

URA overlapping at the border of two RNCs 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.

Section 1 · Module 7 · Page 37

Page 290: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 isAlwaysOnAllowed parameter in DlUserService and UlUserService objects.

The isAlwaysOnAllowed parameter 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 1 · Module 7 · Page 38

Page 291: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 39

Page 292: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 40

Page 293: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 41

Page 294: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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:

�DownsizingThe RNC targets the bit rate as closely as possible to the estimated throughput.

�Upsizing

� Uplink: The RNC targets the bit rate immediately above the current bit rate (step-by-step upsize).

� Downlink: The 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 1 · Module 7 · Page 42

Page 295: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The traffic monitoring function consists in 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 periodically computes 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 1 · Module 7 · Page 43

Page 296: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The RB Rate Adaptation process can downsize an 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 an 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 1 · Module 7 · Page 44

Page 297: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 45

Page 298: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 an 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 1 · Module 7 · Page 46

Page 299: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 higher 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 1 · Module 7 · Page 47

Page 300: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

From UA07 onwards, UL upsizing based on UL throughput is enhanced by a mechanism 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 1 · Module 7 · Page 48

Page 301: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

If the usage of UE Tx power is not enabled (isUEtxPowerOn4AAllowed Set to false), then the Upsize procedure will target an RB based only on the threshold ul4AMaxRateStep.

This RB reconfiguration will be limited by the iRM table and reference RB rate.

Section 1 · Module 7 · Page 49

Page 302: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 is done.

Section 1 · Module 7 · Page 50

Page 303: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

From UA07 onwards, DL upsizing based on DL throughput is enhanced by a mechanism based on RNC Buffer Occupancy.

This DL buffer measurement is performed using an average over boAverageTimeDlDch. Setting 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 an RB reconfiguration to DL PS 128 if allowed by OAM settings.

Section 1 · Module 7 · Page 51

Page 304: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 52

Page 305: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 UETrafficVolumeInhibitTimer timer will be set after the last RB reconfiguration. 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:

Before UA07, rbRateAdaptationPingPongTimer was triggered whenever a RRA mechanism occurred (Buffer or Traffic related).

From UA07 onwards, this timer is still triggered on any RRA but does not prevent the BO mechanisms, introduced in UA07, 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 1 · Module 7 · Page 53

Page 306: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

From UA07 onwards, activation of the isMpdpRbAdaptationAllowed flag allows the RRA to be executed over multi-RAB PSs (multiple PDPs).

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 1 · Module 7 · Page 54

Page 307: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 55

Page 308: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 56

Page 309: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 57

Page 310: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 UA05 release.

irmSchedDowngradeTxcpMaxBitRate is the parameter specifying the fallback RB bit rate in case of iRM Scheduling downgrade.

The flipFlopUpDowngradeTimer parameter allows avoiding ping-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.

The 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 the RadioAccessService object have to be set to True: isIrmSchedDowngradeTxcpAllowed and isIrmSchedulingUpgradeAllowed.

Section 1 · Module 7 · Page 58

Page 311: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 threshold_data parameter is used to compute the absolute TxCP Threshold together with the pcpichPower (FDDCell) and maxDlTxPower (DlUsPowerConf) parameters.

Measurement Hysteresis: timeToTrigger

Section 1 · Module 7 · Page 59

Page 312: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

When a UE uses the RB assigned by IRM Scheduling downgrade, the RNC configures two types of NBAP dedicated measurements 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 1 · Module 7 · Page 60

Page 313: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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. 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 1 · Module 7 · Page 61

Page 314: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Since high bit rate RBs 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 RABs.

Section 1 · Module 7 · Page 62

Page 315: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 63

Page 316: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 64

Page 317: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

New UA07.1.2:

The Service Change and UDI Fallback (SCUDIF) is a function which applies to Unrestricted DigitalInformation / Restricted Digital Information (UDI/RDI) multimedia calls.

It allows users to achieve successful call establishment when end-to-end Circuit Switched (CS) multimedia is notpossible (fallback to speech) or when signalling of the feature is not possible in the network (fallback topreferred service or speech).

Spec Reference 3GTS 23.172

Fallback to Speech

FBtS (which applies to the call setup phase only) allows a user to attempt to set up a VT call, and toautomatically revert to a speech connection:

� 3G VT user to 3G non-VT user

� 3G VT user to user on non-VT network

User Initiated Service Change (UI-SCUDIF)

This is the case where one of 3G users (originator or terminator) manually invokes a change in call type for anin-progress call, from VT to speech or from speech to VT. There are several possible reasons for this call change(e.g. privacy, performance, cost).

In order to invoke this procedure, the UE shall send a MODIFY message containing the BC-IE to change to. ThisBC-IE must be one of those already negotiated at call setup.

Network Initiated Service Change (NI-SCUDIF)

The basic premise of NI-SCUDIF is that under certain conditions the network makes the determination that aservice change from VT to speech (or vice versa) is required, and invokes the signaling required to change thecall type from 64KUDI to speech (or speech to 64KUDI).

When the radio access network detects a lack of sufficient resources to sustain the multimedia RABconfiguration, RNC shall inform the visited MSC by sending a RANAP Modify Request message to the visited MSC.The visited MSC shall then:

� Initiate an In-Call Modification procedure to speech towards the UE it serves using the MODIFY message.

� Invoke the service change procedure towards the remote side.

� Trigger the RAB modification by sending a RANAP RAB Assignment with the RAB requested to be modifiedto the RNC.

Section 1 · Module 7 · Page 65

Page 318: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The TxCP event A measurement threshold for VT downgrade is calculated as below:

Threshold_eventA = pcpichPower_primary_cell + maxDlTxPowerPerOls_Gold_OLS –triggerThresholdDelta

HysteresisTime_eventA = timeToTrigger

The timeToTrigger & triggerThresholdDelta are in the new MOC: serviceChangeTxcpVideoToSpeechForThisUserService

An established VT call is downgraded to a speech call based on:

1. Radio criterion

� Radio criterion is based on an OAM radio threshold value for VT downgrade.

� Radio criterion is based on the event A NodeB TxCP radio measurement for VT.

� The VT-Speech downgrade trigger threshold is intended be set to a value which ensures thetransition to a speech call occurs before the alarm handover to 2G cell is triggered.

2. In case of improper VT-Speech downgrade trigger threshold value, TxCP measurement event A is nottriggered before alarm handover to 2G cell is triggered. The RNC shall initiate a VT downgrade if 2G corenetwork doesn’t support VT service (based on an OAM parameter).

3. In case of other iMCTA reasons triggered handover to 2G cell, the RNC shall initiate a VT downgrade ifthe 2G core network doesn’t support the VT service (based on an OAM parameter).

Section 1 · Module 7 · Page 66

Page 319: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The TxCP event B measurement threshold for VT upgrade is calculated as below:

Threshold_eventB = pcpichPower_primary_cell + maxDlTxPowerPerOls_Gold_OLS –triggerThresholdDelta

HysteresisTime_eventB = timeToTrigger

The timeToTrigger & triggerThresholdDelta are in the new MOC:

serviceChangeTxcpSpeechToVideoForThisUserService

A VT call downgraded to Speech call may be upgraded (back) to a VT call based on:

1. Radio criterion is based on an OAM radio threshold value for VT upgrade.

2. Radio criterion is based on the event B Node B TxCP radio measurement for speech.

3. The Speech-VT upgrade trigger threshold is intended to be set to a value which allows a previousdowngrade (i.e. downgraded from VT to speech) to be upgraded back to VT when the radio conditionsimprove significantly.

Section 1 · Module 7 · Page 67

Page 320: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 68

Page 321: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

These parameters define the TxCP threshold absolute value and TTT SCUDIF Video Telephony to Speech (andvice versa) for cells managed by the neighboring RNC.

Section 1 · Module 7 · Page 69

Page 322: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

These parameters define the TxCP threshold absolute value and TTT SCUDIF Video Telephony to Speech (andvice versa) for cells managed by the neighboring RNC.

Section 1 · Module 7 · Page 70

Page 323: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 71

Page 324: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 iRM Pre-emption has the following characteristics:

� Is a preventive mechanism (does not react on access failures but try to anticipate the congestion to avoid them).

� Is only applicable to DCH and not to HSDPA/E-DCH.

� Is only applicable to DL.

�Consists in downgrading current users if their allocated bit rate is higher than the one they would get in a RED cell with a Radio Link Red (DL).

�Does not provide any upsize mechanism for downgraded users. They may retrieve the initial requested radio bearer after any reconfiguration (CS release, CS establishment when a PS connection is on-going, iRM Scheduling Upgrade, AO Upsize, etc.) except the AO Downsize and iRM Scheduling Downgrade procedures.

� Is an asynchronous process (all users not downgraded at the same time when the cell is congested).

�May be activated/de-activated by OLS.

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.

If current DL RB bit rate > iRM preemption downgraded RB bit rate

Then preemption is processed and the downgrade is performed towards iRM preemption downgraded RB bit rate.

Section 1 · Module 7 · Page 72

Page 325: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 73

Page 326: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 UEs would have received if UEs 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 1 · Module 7 · Page 74

Page 327: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 75

Page 328: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 76

Page 329: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

UA06.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 UA06.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 1 · Module 7 · Page 77

Page 330: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 nor in the source cell nor the target cell.

Section 1 · Module 7 · Page 78

Page 331: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The S-RNC may decide to launch preemption in a cell when it faces up a CAC failure during the following resource allocation procedures:

�NBAP procedures: NBAP Radio Link setup failure, NBAP Radio Link addition failure, NBAP Synchronized Radio Link Reconfiguration failure, NBAP Radio Link Reconfiguration failure using one of the following NBAP failure cause: “DL radio resources not available”, “UL radio resources not available” and “Node B Resources Unavailable”

� Internal DL power allocation

� 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 resource allocation failures don’t call the pre-emption function.

Note: The NBAP failure cause « Node B Resources Unavailable » identifies a resource allocation failure without indication of the direction which may be downlink, uplink or downlink & uplink.

Section 1 · Module 7 · Page 79

Page 332: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 80

Page 333: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

isPreemptionAllowedForHsdpa: Parameter to activate/deactivate the preemption process when a CAC failure occurs during a HSDPA allocation (i.e. HS-DSCH resources)

isPreemptionAllowedForEdch: Parameter to activate/deactivate the preemption process when a CAC failure occurs during a HSUPA allocation (i.e. E-DCH resources)

Section 1 · Module 7 · Page 81

Page 334: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 82

Page 335: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 Node B 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 1 · Module 7 · Page 83

Page 336: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 84

Page 337: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 RABb 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 1 · Module 7 · Page 85

Page 338: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 Node B level for HS-DSCH or E-DCH resource allocation, a “one to one” release action is processed (i.e. a P-Service established on HS-DSCH or E-DCH is released) without taken into account the resource quantity used.

In order to have a common estimator of all resources to be de-allocated, whatever where the CAC failure occurs, the estimation of resources needed is based on:

� the current radio bit rates if the CAC failure concerns DCH resources allocation onNode B or RNC sides (power and code). The resource quantity to be de-allocated in a congested cell is based on the sum of radio estimated downlink rates needed to establish all P-Services of the call in this cell.

� the fair bit rate if the CAC failure concerns HSDPA resources allocation 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 1 · Module 7 · Page 86

Page 339: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

The queuing is done at RNC level.

The queuing is allowed for the 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 not be 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 the 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: for Emergency Call

• Regular reallocation: for all other services

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 1 · Module 7 · Page 87

Page 340: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 88

Page 341: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 89

Page 342: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 90

Page 343: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Principle

Before release UA04.2, the bearer service support for AMR was restricted to mono-mode 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 services 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 terms of OVSF code resource. SF 256 can be used for AMR Low Rate configuration.

�Downlink capacity gain in terms 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 UA05.0, the RNC does not initiate Iu rate control towards the CN except in relocation scenarios.

If Iu UP used is version 2, the RNC may receive Iu rate control from the CN in case of TrFO/TFO. When that happens, the 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 1 · Module 7 · Page 91

Page 344: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 perform:

� 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 frames sent to the core network.

� UL rate control: RRC TFC control messages sent to the 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 1 · Module 7 · Page 92

Page 345: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 color change. Only the trigger of TxCP measurement report is used to upgrade the rate of an AMR call.

Section 1 · Module 7 · Page 93

Page 346: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 94

Page 347: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 95

Page 348: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 1 · Module 7 · Page 96

Page 349: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 97

Page 350: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 98

Page 351: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 99

Page 352: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 100

Page 353: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 101

Page 354: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

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 an 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 UA07 feature is the extension of the UA06 feature PM31039 – PS CN RAB Modification, available in the Korean market. The isPsRabModificationAllowed parameter was introduced with the UA06 feature, and must be set accordingly, so that the UA07 feature operates as expected.

Section 1 · Module 7 · Page 102

Page 355: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

MBR changes 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, an SRLR will occur if the new Granted bit rate is different from the current bit rate.

For an 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 1 · Module 7 · Page 103

Page 356: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

An ARP or THP modification may result in change of OLS, HSDPA SPI, E-DCH SPI, MLP and minBR.

For RABs mapped on DCH, an 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 an 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 on the serving side to support RAB modification).

Section 1 · Module 7 · Page 104

Page 357: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 105

Page 358: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.7 Edition 1

Section 1 · Module 7 · Page 106

Page 359: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 1

Page 360: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 361: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 3

Page 362: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 4

This page is left blank intentionally

Page 363: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 5

Page

1 Network selection 71.1 PLMN selection 82 Cell selection in idle mode 92.1 Cell selection criteria 102.2 UE power compensation 113 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 174 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 245 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 366 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 neighbor 426.5 SIB11 & SIB12 parameters & objects – GSM neighbor 436.6 Exercises 446.6.1 Exercise 1: mono-layer topology 456.6.2 Exercise 2: bi-layer topology 466.6.3 Exercise 3: tri-layer topology 487 3G to 4G inter-RAT cell reselection 517.1 Support of SIB19 527.2 LTE neighboring definition 547.3 Measurement rules 557.4 LTE neighboring cell criteria 567.5 Priority parameters 587.6 Other parameters 598 Cell status and reservation 608.1 Cell status and reservation process 619 Location registration 629.1 LAC/RAC/SAC 63

Page 364: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 6

Page

Page 365: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 7

Page 366: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 1 · Module 8 · Page 8

Page 367: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 9

Page 368: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 1 · Module 8 · Page 10

Page 369: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 1 · Module 8 · Page 11

Page 370: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 12

Page 371: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Cell Reselection without HCS differs from UA04.2 only by the fact that High Mobility Detection is used in the reselection triggering timer.

Cell Reselection with HCS was introduced in UA05.

Section 1 · Module 8 · Page 13

Page 372: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Cell Reselection without HCS differs from UA04.2 only by the fact that High Mobility Detection is used in the reselection triggering timer.

Cell Reselection with HCS was introduced in UA05.

Section 1 · Module 8 · Page 14

Page 373: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 neighboring cells (either GSM or FDD) if UA07 feature 34291 “support of 64 UMTS neighbors” is activated (via isEnhancedSib11Allowed). Else, it should be limited to 48 neighboring cells.

sib11OrDchUsage must be set to dchUsage for the other remaining neighboring 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 neighboring Intra + 32 FDD neighboring Inter + 23 I-RAT neighboring cells) in the SIB11.

Section 1 · Module 8 · Page 15

Page 374: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 1 · Module 8 · Page 16

Page 375: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

High and low mobility UEs are distinguished thanks to the rate of Cell Reselection.

Section 1 · Module 8 · Page 17

Page 376: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 18

Page 377: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 UA05.0.

If sIntraSearch is not sent for the serving cell, the UE performs intra-frequency measurements.

If sInterSearch is not sent for the serving cell, the UE performs inter-frequency 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 1 · Module 8 · Page 19

Page 378: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 1 · Module 8 · Page 20

Page 379: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 1 · Module 8 · Page 21

Page 380: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 qualMeas quality measure parameter 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 qualMeas quality measure parameter for cell re-selection is set to qualMeasEcno, then UE shall perform a second ranking.

Note: That parameter was introduced in UA5.0 and was previously hard-coded to qualMeasEcno.

Section 1 · Module 8 · Page 22

Page 381: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 1 · Module 8 · Page 23

Page 382: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 24

Page 383: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 25

Page 384: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 26

Page 385: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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, the UE will try to reselect a cell with a lower HCS priority.

�When high-mobility state is NOT detected, the UE will try to reselect a cell with higher HCS priority.

HCS rules regarding priorities and HMD are presented in the following pages.

Section 1 · Module 8 · Page 27

Page 386: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 which 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 1 · Module 8 · Page 28

Page 387: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 neighboring cell of hcspriority which is different from 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 1 · Module 8 · Page 29

Page 388: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

When the UE is in high-mobility state, measurements are triggered on lower priority neighboring cells.

Section 1 · Module 8 · Page 30

Page 389: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Like when HCS is not used, both Level and Quality Ranking criteria can be used depending on the setting of the qualMeas parameter.

Note: According to 3GPP 25.304, the real formula of Rn for a neighboring 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 1 · Module 8 · Page 31

Page 390: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Once the H criterion has been computed for the serving cell and each neighboring cell, the 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 with 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 with a lower hcsPrio than the serving cell

else:

� All measured cells with the lowest hcsPrio that fulfil H>=0 and with a higher or equal hcsPriothan the serving cell

else:

� All measured cells without considering hcsPrio

Section 1 · Module 8 · Page 32

Page 391: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Once the H criterion has been computed for the serving cell and each neighboring cell, the 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 with 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 with a lower hcsPrio than the serving cell

else:

� All measured cells with the lowest hcsPrio that fulfil H>=0 and with a higher or equal hcsPriothan the serving cell

else:

� All measured cells without considering hcsPrio

Section 1 · Module 8 · Page 33

Page 392: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Let’s remind 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 qualMeas quality measure parameter 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 qualMeas quality measure parameter for cell re-selection is set to qualMeasEcno, then UE shall perform a second ranking.

Section 1 · Module 8 · Page 34

Page 393: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 1 · Module 8 · Page 35

Page 394: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 layer 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 1 · Module 8 · Page 36

Page 395: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 37

Page 396: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 38

Page 397: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 information (resp. neighboring cell).

UA06.0 introduced the support of SIB4/SIB12 in order to have different Cell Selection and Reselection setting between Idle 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 about neighboring cells) are duplicated.

When all scheduling information cannot 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 an SB1.

Section 1 · Module 8 · Page 39

Page 398: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Cell Selection Info (SIB 3 / 4 Mapping):

Idle Mode

Root = FddCell

Connected mode

CellSelectionInfo � CellSelectionInfoConnectedMode

CellSelectionInfo.FachMeasOccasion CellSelectionInfoConnectedMode.FachMeasOccasion

CellSelectionInfo.CrMgt CellSelectionInfoConnectedMode.CrMgt

CellSelectionInfo.HcsCellParam CellSelectionInfoConnectedMode.HcsCellParam

No Equivalent CellSelectionInfoConnectedMode.CellSelectReselectInfoPchFach

CellAccessRestriction CellAccessRestrictionConnectedMode

Section 1 · Module 8 · Page 40

Page 399: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

CellSelectReselectInfoPchFach

tReselectionPch

tReselectionFach

qHyst1Pch

qHyst1Fach

qHyst2Pch

qHyst2Fach

CellSelectionInfoConnectedMode

interFreqScalingFactorTReselection

interRatScalingFactorTReselection

qHyst1

qHyst2

qQualMin

qRxLevMin

qualMeas

sHcsRatGsm

sInterSearch

sIntraSearch

sSearchHcs

sSearchRatGsm

tReselection

CellAccessRestrictionConnectedMode

accessClassBarred

accessClassCsBarred

accessClassPsBarred

barredOrNot

cellReservationExtension

cellReservedForOperatorUse

intraFreqCellReselectInd

tBarred

CrMgt

tCrMaxHyst

tCrMax

speedDependScalingFactorTReselection

nCr

FachMeasOccasion

fachMeasOccasionCoef

ratTypeList

HCSCellParams

hcsPrio

qHcs

sLimitSearchRat

Attributes for SIB4

Section 1 · Module 8 · Page 41

Page 400: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Neighboring Info (SIB 11 / 12 Mapping):

Attributes for SIB12:

Idle Mode (Root = UMTSNeighbouringRelation) Connected mode

UMTSNeighbouringRelation

UMTSNeighbouringRelation.FddNeighCellSelectionInfoConnectedMode

UMTSNeighbouringRelation. UmtsNeighbouringHcsCellParam

UMTSNeighbouringRelation.FddNeighCellSelectionInfoConnectedMode.UmtsNeighbouringHcsCellParam

UMTSNeighbouringRelation. UmtsNeighbouringHcsTemporaryOffset

UMTSNeighbouringRelation.FddNeighCellSelectionInfoConnectedMode.UmtsNeighbouringHcsTemporaryOffset

UMTSNeighbouringRelation

maxAllowedUlTxPower

neighbouringCellOffset

qOffset1sn

qOffset2sn

qOffsetMbms

qQualMin

qRxLevMin

FddNeighCellSelectionInfoConnectedMode

cellIndivOffset

maxAllowedUlTxPower

qOffset1sn

qOffset2sn

qQualMin

qRxLevMin

Section 1 · Module 8 · Page 42

Page 401: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

UMTSNeighbouringRelation

maxAllowedUlTxPower

neighbouringCellOffset

qOffset1sn

qOffset2sn

qOffsetMbms

qQualMin

qRxLevMin

FddNeighCellSelectionInfoConnectedMode

cellIndivOffset

maxAllowedUlTxPower

qOffset1sn

qOffset2sn

qQualMin

qRxLevMin

Section 1 · Module 8 · Page 43

Page 402: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 44

Page 403: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Subsidiary Question:

Propose a solution to deactivate the inter-RAT mobility.

Section 1 · Module 8 · Page 45

Page 404: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 46

Page 405: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 47

Page 406: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 48

Page 407: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 49

Page 408: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 50

Page 409: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 51

Page 410: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

In case of cell reselection from UTRA to E-UTRA

The reselection towards E-UTRA is based on information given in SIB19 to get:

� Frequencies priority for all technologies GSM, UTRA and E-UTRA;

� E-UTRA Frequencies in order to be able to detect E-UTRA cells.

In UA08.1, the following enhancements on the 3G-4G cell reselection framework is introduced: Support up to 8 E-UTRA frequency & priority list in SIB19 (changed from 2 to 8).

Section 1 · Module 8 · Page 52

Page 411: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Utran Release UA07.1.2 provides the support of cell reselection from UMTS towards LTE. This applies to LTEcapable UEs in UTRA RRC IDLE, CELL_PCH, URA_PCH modes.

� Cell reselection in Idle mode from UTRA to E-UTRA RRC idle

� Cell reselection in CELL_PCH from UTRA to E-UTRA RRC idle

� Cell reselection in URA-PCH from UTRA to E-UTRA RRC idle

It uses a new inter-RAT cell selection algorithm based upon “priority information”, as introduced by 3GPP in Rel.8.

The priority algorithm allows one to additionally prioritize RAT in order to favor a system technology such as E-UTRAN (Rel. 8 feature).

MS (non E-UTRAN capable) which does not support the “priority” algorithm shall use the legacy algorithm.

The network shall provide priority information if E-UTRA cells or frequencies are included within the neighbor celllist.

The priority information (for E-UTRA and UTRA cells) as well as other parameters are broadcast to the UE in anewly introduced SIB 19. A Rel. 8 UE will be able to detect itself E-UTRA cells but it will read SIB11/12 as usualto identify FDD and GSM cells.

The following restrictions apply to SIB19 in UA08.1:

�The IE Blacklisted cells per freq list is not supported.

�The IE GSM priority info list is not supported.

�The IE UTRAN FDD frequency priority is not supported.

Section 1 · Module 8 · Page 53

Page 412: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

LTE Neighbouring Cells Parameters

There is no explicit configuration of each LTE neighboring cell. The LTE frequency and measurementBandwidthare enough for the UE to detect by itself the E-UTRA cells.

Section 1 · Module 8 · Page 54

Page 413: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

The measurement rules below apply in Idle, URA_PCH, CELL_PCH states. Reselection from Cell_Fach statestowards LTE is not yet supported by 3GPP.

Srxlev and Squal of the serving FDDCell are compared respectively with the parameters utraSearchPriority1and utraSearchPriority2:

� If SrxlevServingCell <= utraSearchPriority1

or

SqualServingCell <= utraSearchPriority2,

the UE shall perform measurements of inter-RAT layers of lower or higher priority.

� If SrxlevServingCell > utraSearchPriority1

and

SqualServingCell > utraSearchPriority2,

the UE may choose not to perform measurements of inter-RAT layers of lower priority, the UE shall searchfor E-UTRA layers of higher priority.

Section 1 · Module 8 · Page 55

Page 414: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

If the priority of the E-UTRAN layer is higher than the current serving cell:

� Cell reselection criterion: Srxlev[nonServingCell,x] of a cell on an evaluated higher absolute prioritylayer is greater than Threshx,high during a time interval Treselection.

In this case the Target LTE Cell is selected regardless of the Rxlev and quality level on the serving FDD cell.

Section 1 · Module 8 · Page 56

Page 415: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

If the priority of the E-UTRAN layer is lower than the current serving cell

� Cell reselection criterion: Srxlev[ServingCell] < Threshserving,low or Squal[ServingCell] < 0and the Srxlev[nonServingCell,x] of a cell on an evaluated lower absolute priority layer is greater thanThreshx,low during a time interval Treselection.

If more than one LTE cell meets the criteria, the UE shall reselect the cell with the highestSrxlevnonServingCell,x among the cells meeting the criteria on the highest absolute priority layer.

Section 1 · Module 8 · Page 57

Page 416: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 58

Page 417: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 59

Page 418: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 60

Page 419: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 1 · Module 8 · Page 61

Page 420: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 62

Page 421: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

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 consists 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 1 · Module 8 · Page 63

Page 422: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.8 Edition 1

Section 1 · Module 8 · Page 64

Page 423: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 1

Page 424: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 425: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 3

Page 426: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 4

This page is left blank intentionally

Page 427: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 5

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 141.5 Exercise 152 Active set management (Soft HO) 162.1 Absolute and relative criteria for SHO (periodical mode) 172.2 Drop criteria (periodical mode) 182.3 Add criteria (periodical mode) 192.4 Relative add RL - event 1A 202.5 Detected set cells addition to active set 212.6 Relative delete RL - event 1B 222.7 Relative replace RL - event 1C 232.8 Event 1C improvement 242.9 Absolute add RL - event 1E 252.10 Absolute delete RL - event 1F 262.11 SHO blocking phase – RNC overload 272.11.1 Event storage 283 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 324 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 385 SRNS relocation (UE not involved) 395.1 Principle 405.2 Parameters 41

Page 428: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 6

This page is left blank intentionally

Page 429: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 7

Page 430: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 notions of Drift and Serving RNC come 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 perspectives, 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 1 · Module 9 · Page 8

Page 431: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

From UA04.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 the 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 the UE, in the RRC Measurement Control, with the means to compute the criteria to manage the Mobility. The RNC has to perform the related action indicated by the received event.

The isEventTriggeredMeasAllowed parameter 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 be sent by the UE but the call is kept

Section 1 · Module 9 · Page 9

Page 432: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 1 · Module 9 · Page 10

Page 433: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Two different CNL alogrithms are supported from UA06.0 that can be enabled/disabled using the typeOfCompoundingNeighbourListIntraFreq parameter defined under the NeighbouringRnc and FDDCell objects:

� Prl stands for primary radio link and aims at disabling CNL at FDD cell level; the neighboring list only consists in the primary cell neighborhood.

� Type2 was the initial CNL algorithm introduced in UA4.1; the neighboring list classicaly consists in concatenating Primary cell neighborhood 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 1 · Module 9 · Page 11

Page 434: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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. So it is important to have a 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 instances 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 1 · Module 9 · Page 12

Page 435: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 neighborhood (0 is the highest priority, 62 the lowest); note that two UMTSFddNeighbouringCell can NOT have the same neighbourCellPrio.

� “cells in active set” which are the cells from the ASET.

� occurrence of each neighboring cell within the sponsoring cell neighborhood.

For each sponsoring cell, the RNC builds a neighboring cell list ordered by neighbourCellPrio. Then it builds the final intra-frequency neighboring list by:

� adding the sponsoring cells.

� selecting the numOfPrimaryCellNeighbourIntraFreq first neighboring cells from Primary Cell neighboring list.

� and then performing the selection by number of occurrences.

In case of conflict, the RNC selects the neighboring cell whose sponsoring cell has the highest CPICH Ec/No, then the one with the highest neighbourCellPrio 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-frequency neighborhood using the information present in the RNSAP RadioLinkSetup/AdditionResponse message.

�When type1 is selected, the RNC automatically assigns neighbourCellPrio by order of presence in the RNSAP message (starting from 0).

It is recommended to set maxCompoundingListSizeIntraFreq to 32 to ensure that at least all cells of the primary cell are sent. If maxCompoundingListSizeIntraFreq is 16 (for example) and the primary cell has 20 data filled neighbors, then only 16 neighbors will be sent to the UE.

If the detectedSetCellAddition flag is set to ENABLED or AUTOMATIC, then the maxCompoundingListSizeIntraFreq parameter MUST be set to any value below 32. (31 is recommended).

Section 1 · Module 9 · Page 13

Page 436: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 14

Page 437: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 neighborhood (0 is the highest priority, 62 the lowest); note that two UMTSFddNeighbouringCell can NOT have the same neighbourCellPrio.

� “cells in active set” which are the cells from the ASET.

� occurrence of each neighboring cell within the sponsoring cell neighborhood.

For each sponsoring cell, the RNC builds a neighboring cell list ordered by neighbourCellPrio. Then it builds the final intra-frequency neighboring list by:

� adding the sponsoring cells.

� selecting the numOfPrimaryCellNeighbourIntraFreq first neighboring cells from Primary Cell neighboring list.

� and then performing the selection by number of occurrences.

In case of conflict, the RNC selects the neighboring cell whose sponsoring cell has the highest CPICH Ec/No, then the one with the highest neighbourCellPrio until maxCompoundingListSizeIntraFreq is reached.

Section 1 · Module 9 · Page 15

Page 438: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 16

Page 439: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 1 · Module 9 · Page 17

Page 440: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 active set, the 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 1 · Module 9 · Page 18

Page 441: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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, the 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 1 · Module 9 · Page 19

Page 442: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Event 1A is triggered when a new P-CPICH enters the reporting range.

Event 1A is used to add an 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 efficiently monitor its network and optimize its neighboring plan, it is possible totrigger this event 1A based on both Detected Set and Monitored Set.

� In order to achieve this, the isDetectedSetCellsAllowed parameter 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 detectedSetCellAddition flag (see next slide).

Section 1 · Module 9 · Page 20

Page 443: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

From UA7 onwards, if the detectedSetCellAddition flag 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 neighburhood 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 Neighboring List algo (typeOfCompoundingNeighbourListIntraFreq) must be set to “Type1”

� maxCompoundingListSizeIntraFreq MUST be set to any value strictly below 32.

If the detectedSetCellAddition flag is set to DISABLED the cells from Detected Set will not be used in the mobility algorithms.

Section 1 · Module 9 · Page 21

Page 444: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Event 1B is triggered when an active P-CPICH leaves the reporting range.

Event 1B is used to delete an 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 1 · Module 9 · Page 22

Page 445: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Event 1C is triggered when a new P-CPICH becomes better than an active P-CPICH.

Event 1C is used to replace an RL based on relative criteria when the Active Set is full.

The variables in the formula are defined as follows:

�MNew is the measurement result of the cell not included in the active set.

�CIONew is the individual cell offset for the cell becoming better than the cell in the active set if an individual cell offset is stored for that cell. Otherwise it is equal to 0.

�MInAS is the measurement result of the cell in the active set with the lowest measurement result.

�CIOInAS is the individual cell offset for the cell in the active set that is becoming worse than the new cell.

�H1c is the hysteresis parameter for the event 1c.

Note: The above drawing shows an example assuming that the maximum AS size is set to 2 and that all the CIOs are set to 0 dB.

Section 1 · Module 9 · Page 23

Page 446: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

From UA7 onwards, if the isEnhanced1cHandlingAllowed flag 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 cell of the active set - 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 1 · Module 9 · Page 24

Page 447: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Event 1E is triggered when a new P-CPICH becomes better than an absolute threshold.

Event 1E is used to add an 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 efficiently monitor its network and optimize its neighboring plan, it is possible totrigger this event 1E based on both Detected Set and Monitored Set. However the cells from the Detected Setwill not be used in the mobility algorithms.

In order to achieve this, the isDetectedSetCellsAllowed parameter shall be set to True.

Section 1 · Module 9 · Page 25

Page 448: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Event 1F is triggered when an active P-CPICH becomes worse than an absolute threshold.

Event 1F is used to delete an 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 1 · Module 9 · Page 26

Page 449: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

An 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 an SHO procedure is completed, i.e. after the RNC receives RRC ActiveSetUpdateComplete from the UE.

The shoAfterBlockingPhaseEnable parameter allows one to activate a mechanism to process events during such a 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 1 · Module 9 · Page 27

Page 450: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

The RNC processes 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. However, the RNC processes all events 1F received during the blocking phase.

A specific handling has been provided for event 1B in order to adapt the RNC reaction to different UE behaviors. 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, the 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 isOne1bStorageAllowed flag as follows:

� If the isOne1bStorageAllowed flag 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 behavior defined above for R99 Ues, the processing will be in reverse order so that event 1B will be processed after event 1A or 1C if stored in parallel (in order to avoid a call drop if event B corresponds to a last RL).

� If the isOne1bStorageAllowed flag is set to FALSE, then the same behavior as defined above for R99 UEs will apply.

Section 1 · Module 9 · Page 28

Page 451: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 29

Page 452: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 1 · Module 9 · Page 30

Page 453: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

The 1D event can be triggered by a cell in the Active Set for R5/R6 UEs or by a cell in the Active Set or in the Monitored Set for R99/R4 UEs.

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 than or equal to 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.

An event 1D 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.

In addition to the event 1D, a new primary cell will be defined if the current primary cell is removed due to reception of RL deletion events.

Event 1D is not repeated by UE and therefore if lost during SRNS relocation it cannot be recovered. It is only another event 1D for a different cell that will fix the issue of wrong primary cell. This is particularly bad for HSDPA calls which follow the primary cell and do support SHO.

Section 1 · Module 9 · Page 31

Page 454: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 32

Page 455: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 33

Page 456: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 RNCs

� E.g. due to IOT reasons between 2 different RNC manufacturers

� In a single PLMN, the 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 UA05.0

�Code was implemented but commercially not supported

�Not applicable to HSxPA calls

FRS 33814 has been created for UA06.0

� Feature is fully supported

�Also applicable to HSxPA calls

Section 1 · Module 9 · Page 34

Page 457: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 35

Page 458: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 1 · Module 9 · Page 36

Page 459: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 1 · Module 9 · Page 37

Page 460: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 38

Page 461: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 39

Page 462: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

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 UA05 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 1 · Module 9 · Page 40

Page 463: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 41

Page 464: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.9 Edition 1

Section 1 · Module 9 · Page 42

Page 465: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 1

Page 466: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 467: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 3

Page 468: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 4

This page is left blank intentionally

Page 469: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 5

Page

1 HHO mobility requirements 71.1 Hard handover types 82 Intelligent Multi-Carrier Traffic Allocation 92.1 Principle 102.2 Strategy 112.3 Generic iMCTA algorithm 122.4 iMCTA triggering 152.5 iMCTA alarm triggering 162.6 iMCTA alarm validity checking 182.7 iMCTA service validity checking 202.8 Cell load criteria on iMCTA 212.9 iMCTA configuration retrieval 232.10 Blind handover 262.11 Neighboring cells searching and filtering 312.12 Measurement configuration 372.13 Measurement report processing 382.14 HHO decision 522.15 iMCTA fallback 532.16 RAN model 542.17 Exercise 1 572.18 Exercise 2 582.19 Exercise 3 592.20 Exercise 4 613 Inter-FDD/inter-RAT HHO 633.1 3G to 2G HHO 643.2 CS 3G to 2G HHO failure: next best cell attempt 653.3 3G to 3G intra-RNC inter-freq HHO 663.4 3G to 3G inter-RNC inter-freq HHO: Iur not used 673.5 3G to 3G inter-RNC inter-freq HHO: Iur used 684 4G to 3G inter-RAT HHO 694.1 LTE/UMTS mobility in UA08 704.2 RAT mobility events 714.3 Partial relocation of RABs 734.4 CS fallback procedure 754.5 RAN model 76

Page 470: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 6

Page

Page 471: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 7

Page 472: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

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 changing RNC.

�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 mode (e.g. TDD).

�When moving to another technology (GSM, GPRS): this case is defined as the inter-RAT HHO.

�When moving to UMTS from another technology (GSM, GPRS, LTE): this case is defined as incoming relocation HHO.

�When Soft Handover is not permitted (due to OAM constraint).

The following hard handover procedures are supported:

� 3G to 2G Hard Handover

� 3G to 3G Inter-frequency Inter-RNC HHO algorithm

� 3G to 3G Inter-frequency Intra-RNC HHO algorithm

� 3G to 3G Intra-frequency Inter-RNC HHO algorithm

� 2G to 3G Hard Handover

� 4G to 3G Hard Handover

Section 1 · Module 10 · Page 8

Page 473: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 9

Page 474: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Intelligent Multi-Carrier Traffic Allocation (iMCTA) allows the handover of a UE to another layer when in Cell_DCH connected mode:

� In case of coverage gap (iMCTA Alarm).

� In case of RAB establishment failure. If call establishment is not possible because Call Admission Control (CAC) fails establishing the traffic RAB (TRB) (iMCTA CAC).

�After Service Type change, Intra-frequency mobility or Always-On upsize based on load condition of source/target cells, call type and UE/Cell capabilities (iMCTA Service).

iMCTA Alarm cannot be disabled as the objective is to save the call in case coverage is being lost. CAC and Service can be enabled/disabled through OMC parameters. The recommended setting is to have iMCTA Alarm and CAC enabled in order to improve Accessibility and Retainability.

Section 1 · Module 10 · Page 10

Page 475: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

The iMCTA 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 preferred 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 andcapacity:

� 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 filter out high loaded cell or 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.

In UA08, 12 FDD carriers + 1 GSM carrier + 2 LTE carriers are supported.

Section 1 · Module 10 · Page 11

Page 476: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

iMCTA is composed of 9 different functions that are processed sequentially:

1. Invoking iMCTA upon 3 call processing events:

� Alarm trigger

� CAC failure trigger

� User or Mobility Service trigger

2. iMCTA validity checking

To decide whether iMCTA must be processed or not (checking activation parameters and identifying the Service Type and RAB to be set); In UA08.1, iMCTA supports a direct DCH transition to another layer after an AO upsize trigger for Service and CAC, introduce the ability to use HSPA load criteria instead of DCH Load Criteria for HSPA calls, and introduce the load color BLACK for DCH.

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); In UA08.1, the priority list processing includes the AO upsize trigger for CAC and Service and the support of 12 FDD carriers for Alarm, CAC and Service priority tables.

4. Blind HO processing

Introduction in UA08.1. If applicable, this function will run prior to the neighboring cell searching and filtering for Radio Access Selection for Measurement based HO; Blind HHO execution (no measurements configured) and iMCTA Alarm or CAC fallback if Blind HO fails or continue with neighboring cell searching and filtering for Radio Access Selection for Measurement based HO if enabled and if not eligible cell retrieved for blind HO.

Section 1 · Module 10 · Page 12

Page 477: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

5. Neighboring cell searching and filtering

For Radio Access Selection (FDD and/or GSM) based on neighboring cell and priority tables to select a Radio Access Technology (RAT); In UA08.1 iMCTA introduces the ability to use HSPA load criteria instead of DCH Load Criteria for HSPA calls, and introduces the load color BLACK for DCH. It also introduces improvements for the limitation to two WCDMA FDD carriers for inter-frequency radio measurement. Ability to pre-check for inter-Frequency measurements to avoid triggering measurements for FDD overloaded access layers is conserved.

6. Configuration of the compressed mode and of the UE measurements

To provide Node B and UE with complete measurement information (Compressed Mode and neighboring cell list corresponding to the selected RAT; simultaneous compressed mode supported).

Section 1 · Module 10 · Page 13

Page 478: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

7. Measurement report processing

To process all RRC Measurement Report messages sent by the UE. In UA07, filter out the loaded cells for Alarm & CAC. In UA08.1, iMCTA introduces a synchronization mechanism to wait for the favored carrier (FDD or GSM) measurement report and new configuration for EcNo and RSCP Target Cell Threshold.

8. iMCTA HHO execution or iMCTA exit

In UA08.1, iMCTA Alarm or CAC fallback if Measurement based HO fails.

Section 1 · Module 10 · Page 14

Page 479: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

There are 3 types of iMCTA invocations:

� HHO Alarm trigger: iMCTA is called on any HHO alarm measurement whether Periodic Mode or Full EventTriggered 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

� Service trigger:

� iMCTA service aims at redirecting the UE to a more appropriate layer (either UMTS or GSM) in orderto improve:

� the quality of service provided to this user (e.g. by redirecting an HSUPA-capable UE to anHSUPA-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 the RNC has sent RANAP Rab Assignment Response or Iu ReleaseComplete to CN, i.e. after RAB is established or released. Therefore, call establishment KPIs are notimpacted by iMCTA Service.

Section 1 · Module 10 · Page 15

Page 480: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

The algorithm used to trigger alarm measurements while in Full Event mode is based on the following principles:

�On reception of an event 2D (alarm condition), the RNC starts the timer timerAlarmHoEvent2D.

� If, at expiry of the timerAlarmHoEvent2D, no event 2F (indicating that the alarm conditions are no more met) has been received, the alarm condition is confirmed, and iMCTA Alarm is invoked.

�At the opposite, if an event 2F is received while the timer is still running, the timer is stopped, and the alarm conditions are invalidated. iMCTA Alarm is not invoked.

Section 1 · Module 10 · Page 16

Page 481: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Prior to UA07, alarm HHO was triggered by the RNC upon reception of event 2D thus only dependent on the DL Radio quality.

UA07.1 onwards:

�UL UE Tx Power can be taken into account to evaluate the radio quality and trigger the Alarm HHO.

�The 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 Alarm HHO 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 1 · Module 10 · Page 17

Page 482: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Once iMCTA trigger has been identified, Validity Checking aims at determining whether this specific iMCTAtrigger is enabled on the Primary cell, through the 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

The mode parameter must be set at primary cell level, i.e.:

� at FDD cell level when primary cell C-RNC is the Serving RNC, through theFddIntelligentMultiCarrierTrafficAllocation object (so-called FddImcta).

� at Neighbouring RNC level when primary cell C-RNC is a Drift RNC, through the NeighbouringRncIntelligentMultiCarrierTrafficAllocation object (so-called NeighbouringRncFddImcta).

Section 1 · Module 10 · Page 18

Page 483: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

iMCTA Service can only be processed when the Primary cell is located on the Serving RNC:

�Therefore, iMCTA Service can only be activated on the FddImcta object.

� mode must be never be set to AlarmAndService or All on the NeighbouringRncImcta object.

Section 1 · Module 10 · Page 19

Page 484: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

When the userServiceSigToTrafficOnlyEnable parameter is set to True, iMCTA User Service is onlyprocessed 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 one to limit the number of iMCTA User Service occurrences.

The mobilityServiceForHsxpaEnable parameter activates/deactivates the triggering of iMCTA Service whenan HSxPA-capable mobile performs Primary cell change.

The mobilityServiceForNonHsxpaEnable parameter activates/deactivates the triggering of iMCTA Service when a non HSxPA-capable mobile performs Primary cell change.

“iMCTA on AO upsize” Enhancement:

This sub-feature adds iMCTA direct DCH transition support on AO upsize, i.e. on state change from URA/Cell_PCH or Cell_FACH to Cell_DCH. In this release, only FDD twin cell targets are considered.

Sub-feature “iMCTA on AO upsize” is enabled if:

� RadioAccessService/isImctaOnAoUpsize = TRUE, AND

� FddIntelligentMultiCarrierTrafficAllocation/isImctaOnAoUpsize = TRUE

iMCTA Service on AO upsize with direct DCH transition applies upon:

� AO upsize from Cell_FACH to Cell_DCH due to traffic reasons.

� AO upsize from URA/Cell_PCH to Cell_DCH due to traffic increase or Cell Update procedure decides to perform an AO upsize from URA/Cell_PCH to Cell_DCH due to new RAB assignments.

Section 1 · Module 10 · Page 20

Page 485: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

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 color with originatingCellColourThreshold is systematically performed byiMCTA Service, for load balancing purposes but also for traffic segmentation (which is based on UE and NodeBHSxPA 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.

Consequently, in UA05, 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 was removed thanks to the introduction of isServiceSegmentationTopPriority, a new flag defined per serviceType, which allows to bypass originatingCellColourThreshold during iMCTA Validity 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 1 · Module 10 · Page 21

Page 486: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Rational: Feature UA07.1.2 81213 Load Balancing Between HSPA Carriers introduced a new HSDPA downlink load criterion in order to manage load balancing of HSPA I/B traffic with or without MinBR (DL HSPA Load = maximum (HSPA DL Power Colour, HSPA DL Codes Colour)); however, in UA07.1.2 it applies to IMCRA only.

“iMCTA to use HSPA load” Enhancement: this sub-feature introduces the HSPA load indicator usage for iMCTA use. In parallel, load threshold parameters used by iMCTA have been enhanced with the new load color “black”.

“iMCTA to use HSPA load” is enabled if:

� RadioAccessService/isImctauseHspaLoad = TRUE

� isHspaCellLoadAllowedForImcra= TRUE & isHsxpaR99ResourcesSharingOnCellAllowed= TRUE

(PM81213);

� Otherwise, iMCTA will use the aggregate DCH load.

In such case:

� HSPA I/B calls will address the HSPA load criterion (DL HSPA Load = maximum (HSPA DL Power Color,

HSPA DL Codes Color)).

� For DCH and HSPA GBR calls, the existing DCH load criterion is used further on.

� For multi RAB calls (CS on DCH and PS on HSPA, or HSPA GBR and HSPA I/B), the RNC shall use the

maximum load color of DCH and HSPA load.

Section 1 · Module 10 · Page 22

Page 487: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Once it has been checked that the invoked iMCTA trigger is enabled for the Primary cell, iMCTA Configuration Retrieval aimsat selecting the Priority Table to be used.

Priority Table is an important concept in iMCTA which must be associated with ServiceType (ST) and Priority.

An iMCTA Priority table defines for a specific iMCTA Trigger (Alarm, CAC or Service) and for each ST a priority level to beapplied on the different FDD and GSM neighboring cells.

When iMCTA Alarm is triggered, the algorithm retrieves the AlarmPriorityTable that is pointed either by FddImcta orNeighbouringRncImcta object, depending on the Primary cell location.

From UA08 onwards, iMCTA Alarm & iMCTA CAC & iMCTA Service priority Tables are extended to contain 12 FDD Frequencies.

Since iMCTA Service can only been triggered when Primary cell is located on the Serving RNC, the algorithm can retrieve upto 3 Priority tables that are pointed by the 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 SetupComplete 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

Unlike as for iMCTA Alarm and CAC, for iMCTA Service typically GSM and FDD access types should have different priority because the Service trigger is not needed to save the call but to assign a better layer. Nevertheless, it is possible to assign the same priority for GSM and FDD if desired.

Section 1 · Module 10 · Page 23

Page 488: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

The originatingCellColourThreshold parameter can be configured per Service Type (ST). iMCTA

Alarm, CAC and Service Priority Tables are extended to contain 12 FDD Frequencies and 12 ConfClass:

�New Object OriginatingCellColourThresholdConfClass 0..11;

�New Object OriginatingCellColourThresholdPerService 0…11;

�Updated Object Frequency 1..14 (FDD1-12; 2G; OtherFDD);

In UA08, AlarmPriorityTable may be composed of 12 FDD frequencies plus one input for 2G.

Section 1 · Module 10 · Page 24

Page 489: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

The Service Handover option allows CS and PS Core Networks to inform UTRAN that GSM is preferred for thisservice, through the optional serviceHO Information Element (IE) which is present in RANAP RAB AssignmentRequest messages:

�Based on the 3 different values that ServiceHo IE can have (if present), the iMCTA algorithm maydynamically change the GSM priority in the Priority table:

� IE = should: GSM priority is overwritten with P0, i.e. GSM becomes the most preferred targetAccess.

� IE = should not: GSM priority is overwritten with P6, i.e. GSM becomes the less preferred targetAccess.

� 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 throughserviceHoRanapIeEnable parameter.

� “should not” is never taken into account when iMCTA Alarm or iMCTA CAC are triggered.

isChangeGsmIratHoCriterionAllowed enables/disables the change of the Service Handover criterion of CS voice calls for UMTS to GSM handover from 'should' to 'should not' if the UE is involved in a simultaneous PS call.

Section 1 · Module 10 · Page 25

Page 490: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

In UA08, iMCTA may apply measurement-based handover, also known as Mobile Assisted HO (MAHO) or Blind HO, also known as Database Assisted HO (DAHO). If no Twin cell is eligible for Blind HO, then iMCTA continues with “Measurement based HO” if enabled.

“Blind HO” applies to:

� AO upsize CAC & Service trigger (Cell/URA_PCH or Cell_FACH to Cell_DCH)

� only Blind HO is enabled for AO upsize trigger, because there is no available measurement.

� for AO upsize trigger, Blind HO is enabled independent of parameters RadioAccessService/ isImctaBlindHo, FddIntelligentMultiCarrierTrafficAllocation/blindHoType, and FddIntelligentMultiCarrierTrafficAllocation/blindHoMode.

� iMCTA Alarm, iMCTA CAC or iMCTA Service depending on configuration for parameter FddIntelligentMultiCarrierTrafficAllocation/blindHoMode (alarm, AlarmCac, AlarmService, cac, cacService, service, all) and only if the following criteria are met:

� Primary cell is on SRNC (if the primary cell is on DRNC then only MAHO is applicable), AND

� RadioAccessService/isImctaBlindHo is true, AND

� FddIntelligentMultiCarrierTrafficAllocation/blindHoType is “allowOnlyBho” or “minLevPrlBho” and primary link level is equal to or above the configured FddIntelligentMultiCarrierTrafficAllocation /minLevPrlBho

Section 1 · Module 10 · Page 26

Page 491: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Blind HO is processed in reference to a specific and parallel Twin cell list as did for RRC Re-direction while Measurement based HO is in reference to the neighboring list.

Note: GSM twin list is new in UA08 whereas FDD twin list already existed in UA07.

Section 1 · Module 10 · Page 27

Page 492: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Process filter based on priority tables: Similar as for neighbor cells a Twin cell is only considered if the frequency is selected via the iMCTA priority table.

Process Load Based Target cell filtering: Since Measurement report processing does not apply for Blind HO, the initial iMCTA phase for neighboring cell searching reuses some Measurement report processing concepts for Twin Cells.

Process Target Twin Cell and RAT Selection: A single FDD Twin cell or GSM cell should be selected for Blind HO.

Section 1 · Module 10 · Page 28

Page 493: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

* Cell fully compatible with UE capabilities

�HSUPA cell and HSUPA UE

�HSDPA or HSUPA cell and HSDPA UE

�R99 cell and R99 UE

* Cell partially compatible with UE capabilities

�HSDPA cell and HSUPA UE

* Cell NOT compatible with UE capabilities

�HSxPA cell and R99 UE

�R99 cell and HSxPA UE

Section 1 · Module 10 · Page 29

Page 494: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

If GSM and FDD Twin cells are applicable then the RNC shall select the RAT based on parameter is3GHandoverPreferred (true selects FDD; false selects GSM);

In iMCTA CAC and iMCTA Alarm and AO upsize CAC trigger conditions, if FDD is applicable and two or more Twin cells are applicable then iMCTA selects the target FDD cell based on the following criteria:

� If UE is HSUPA capable, preference is given to HSUPA cells then HSDPA cells or if UE is HSDPA capable, preference is given to HSDPA cells.

� Preference is given to the least loaded cell (Call type load or DCH load).

� Preference is given to cell (s) belonging to the Carrier with the highest priority.

� Round Robin based on downlink frequency (ARFCN).

In iMCTA Service and AO upsize Service trigger conditions, if FDD is applicable and two or more Twin cells are applicable then iMCTA selects the target FDD cell based on the following criteria:

� Cells belonging to the Carriers with the highest priority are kept.

� Preference is given to the least loaded cell (Call type load or DCH load).

� Round Robin based on downlink frequency (ARFCN).

If GSM is applicable and two or more Twin cells are applicable then iMCTA selects target GSM cell based the following criteria:

� Preference is given to the least loaded cell.

� Round Robin based on downlink frequency (ARFCN).

Decision for Blind HO

Previous steps allow filtering an applicable cell for Blind HO. In such a case, the RNC triggers either 3G2G HHO or Intra-RNC HHO.

If no twin cell is applicable, then iMCTA shall continue with measurement based HO if enabled and neighbors cells are applicable.

If Blind HO fails, the following may apply:

� The RNC triggers “iMCTA fallback” if provisioned (please refer to section 2.8.4.10).

� Call returns to the initial frequency.

Section 1 · Module 10 · Page 30

Page 495: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

If Blind HO does not apply or if no twin cell is eligible for Blind HO, then iMCTA shall continue with the Measurement-based HO process if enabled. Once the Priority table has been retrieved for the selected Service Type, this function aims at filtering the inter-frequency and inter-RAT neighborhood provisioning of the FDD cell so as to eventually keep the cells:

�Belonging to an authorized PLMN

�Compatible with the retrieved Priority Table, i.e. neighboring cells whose Access is PNA are removed

�Compatible with GSM and UMTS bands supported by UE

�Compatible with Compressed Mode capabilities:

� UE capabilities sent in an RRC Connection Setup Complete message

� CM activation flags per DlUserService

isGsmCModeActivationAllowed indicates if the compressed mode for GSM is allowed for this DlUserService.

isInterFreqCModeActivationAllowed indicates if the compressed mode for inter-frequency is allowed for this DlUserService.

Section 1 · Module 10 · Page 31

Page 496: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

As per 3GPP, neither the relocation procedure nor the RNSAP RL addition procedure supports the TransportChannel addition/deletion. Therefore, for iMCTA CAC, every neighboring cell belonging to another RNC areremoved.

For iMCTA Service, unlike iMCTA Alarm and iMCTA CAC, the neighboring cells whose priority is worse than thePrimary cell one are removed.

Section 1 · Module 10 · Page 32

Page 497: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Feature principles

The ALU RNC will compute the Inter-Freq neighbor list if:

� A new RRC Measurement Control message needs to be sent to the UE for inter-frequency measurements.

� the primary cell changes or the active set is updated while an inter-frequency measurement is ongoing.

The ALU RNC will compute the Inter-RAT neighbour list if a new RRC Measurement Control message needs to be sent to the UE for inter-RAT measurements.

The Compounding Neighbor List algorithm considers:

� Occurrence of a cell within all neighborhoods.

� Measured quality of the sponsoring active set cell.

� Priority defined per neighboring cell.

Section 1 · Module 10 · Page 33

Page 498: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 34

Page 499: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 35

Page 500: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Rational:

3GPP 25.133 restricts the maximum number of carriers to be supported simultaneously by the UE to the current carrier plus up to 2 additional FDD carriers, i.e. a total of 3 carriers. The UE behavior is undefined if more than 2 additional FDD carriers are to be measured. Tests with one UE type showed that arbitrarily some carriers were ignored (not necessarily the carriers given first/last). QUALCOMM stated that the first two frequencies are selected. For a deterministic behavior the RNC is required to restrict the number of additional (i.e. inter-frequency) FDD carriers to be measured by a UE to 2.

Enhancement of two IFREQ carriers

To avoid impacting the neighboring relations management, a dynamic approach to determine the two neighbor carriers for an UE is implemented – please note that the interest of such an algorithm is for sites with 4 or more carriers.

If “Measurement based HO” is decided and more than two candidate FDD carriers are still eligible to be target layers, the RNC only choose 2 carriers for UE measurement. The following parameter is used: carrierPreSelectAlgorithm. If carrierPreSelectAlgorithm = disabled, do not care of the number of frequencies sent to the UE in measurement control.

Notes:

�This feature is about inter-frequency (the UE can measure more than 2 cells in IFREQ).

�This feature impacts the “Neighboring cell searching and filtering” part of the iMCTA algorithm.

Section 1 · Module 10 · Page 36

Page 501: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Once target Access has been selected, this function configures Inter-frequency or GSM measurements on Node B and UE sides, by respectively sending the NBAP Compressed Mode Command and RRC Measurement Control messages.

The alarm measurement results are reported in periodic mode.

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).

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 and GSM neighbors of the primary cell and is provided to the UE through a MEASUREMENT CONTROL message first time the alarm measurement condition is fulfilled and on modification of the monitored set.

Section 1 · Module 10 · Page 37

Page 502: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

This function processes the measurements reported by the UE so as to possibly perform HHO. Processing is different for Inter-frequency or GSM measurements. To improve the measurement report processing in UA08.1, a measurement report processing delay is implemented.

In order to minimize algorithm changes, the same behaviour is adopted between periodic and full event modes. 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 as Intra-Frequency (rrcIntraFreqMeasurementReportingPeriod).

� In event mode, new measurements are configured to report Inter-Frequency/Inter-RAT measurements (Intra-Frequency measurements are not impacted and are still reported in event-triggered mode).

In event mode and if both Inter-Frequency and Inter-RAT measurements are used, then the Inter-Frequency measurement is configured as the main measurement in periodic mode and the Inter-RAT measurement is configured as the additional measurement of the Inter-Frequency measurement.

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 and GSM neighbors of the primary cell and is provided to the UE through a MEASUREMENT CONTROL message first time the alarm measurement condition is fulfilled and on modification of the monitored set.

Section 1 · Module 10 · Page 38

Page 503: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Rational: the RNC uses a single 2D threshold for both IFREQ & IRAT measurements and it asks the UE to start measuring both IFREQ & IRAT neighbor cells at the same time. Also, the RNC uses periodic IFREQ & IRAT measurements with a periodicity of 0.5s, meaning UE sends a measurement report every 0.5 seconds. Field observations show that UE reports first cells from the first frequency ranked on Measurement Command and takes about 2-3s for completing the measurement on all the cells in the neighboring list. The measurement reports sent in the mean time contain only partial measurements that may even not include cells from the preferred priority layer.

Report Processing Delay Enhancement: to improve the measurement report processing it is implemented a measurement report processing delay; this implementation is enabled if imcta/measRepDiscardTimerXXX > 0 and only apply if:

�Simultaneous IFREQ and IRAT measurements are needed, or

� the IFREQ measurement list contains cells belonging to multiple carrier frequencies.

In such conditions, measurement reports are processed the following way:

� on expiry of timer imcta/measRepDiscardTimerXXX, or

� if target cell technology is preferred (parameter is3GHandoverPreferred) AND target cell Call Type color is GREEN.

If CM is needed (mono-receiver UE) then CM activation time is additionally taken into account.

The timer measRepDiscardTimer is adjusted for the CM activation time (it starts on start of iMCTA guard timer and is stopped whenever iMCTA guard timer is stopped). measRepDiscardTimer is adjusted the following way:

�UE needs CM for FDD: (CModeConfiguration::cModeDeltaCfn + CModePatternSeqInfo::tgcfnOffset of FDD) * 10

�UE needs CM for GSM: (CModeConfiguration::cModeDeltaCfn + CModePatternSeqInfo::tgcfnOffset of GSM BSIC) * 10

Note: This feature impacts the « Measurement report processing » part of the iMCTA algorithm.

Section 1 · Module 10 · Page 39

Page 504: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

If the simultaneous compressed mode is requested but not possible then the RNC uses the single compressed mode as per parameter is3GHandoverPreferred.

So, it specifies whether to perform inter-Frequency (3G) or inter-RAT (2G) measurements if the RAB combination or the Node B does not support simultaneous CM patterns.

is3GHandoverPreferred = TRUE will also result in choosing an FDD cell as target if the measurement report contains eligible cells from both 2G and FDD. Consequently, more traffic will handover to other FDD layer(s).

Section 1 · Module 10 · Page 40

Page 505: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

FDD Eligible Cells filtering is explained later in the document.

Filtering on HSxPA capabilities for iMCTA Alarm or CAC is explained later in the document.

Load Post-Filtering is available from UA07 onwards; it is explained later in the document.

Best Cell Color Cells

FDD Cell Load must be understood here as Worst Combined DL and UL Cell Colors:

�All reported neighboring cells whose load is the lowest, among all cells remaining in the list after Filtering onHSxPA 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 Color= GREEN and others = YELLOW, then only the cellsof GREEN Cell Color 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 todetermine its load color.

Section 1 · Module 10 · Page 41

Page 506: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

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.

In UA07, the RNC filters target cells for which:

�CPICH EcNo < minimumCpichEcNoValueForHO

�CPICH RSCP < minimumCpichRscpValueForHO

In UA08, as the minimumCpichEcNoValueForHO/minimumCpichRscpValueForHO parameters are defined per service, an enhancement is done in order to add an offset which depends on the neighbor cell. This enhancement allows more flexibility and better tuning of the target cell. With such an implementation, different target FDD carriers may have different eligibility thresholds for HHO.

The RNC then filters target cells for which:

�CPICH EcNo < minimumCpichEcNoValueForHO + UMTSFddNeighbouringCell/ minimumCpichEcNoValueForHoOffset

�Or CPICH RSCP < miniumCpichRscpValueForHO + UMTSFddNeighbouringCell/ minimumCpichRscpValueForHoOffset.

Section 1 · Module 10 · Page 42

Page 507: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

This filtering for iMCTA Alarm and CAC load based is only invoked if isImctaLoadBasedAllowed = TRUE.

In this case, to be eligible to HHO, an FDD neighboring cell shall have a Cell Load Color fulfilling the imctaLoadBasedTargetCellColorThreshold.

For instance, if imctaLoadBasedTargetCellColorThreshold = Yellow and one DCH color of the neighboring cell is Red, this cell is removed from the candidate list to HHO.

An additional criterion applies for iMCTA Alarm and CAC load based: the 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 modes. 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 neighboring cells are discarded due to overload.

In UA07.1, isImctaLoadBasedAllowed enables the cell load criteria when the reason for iMCTA is Alarm or CAC failure.

Section 1 · Module 10 · Page 43

Page 508: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Filtering on UE and reported cells HSxPA capabilities aims at optimizing UTRAN radio resources since only HSxPAcapable 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, theRNC will keep the HSUPA-capable cells if present. Otherwise, theHSDPA-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 1 · Module 10 · Page 44

Page 509: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

GSM Eligible Cells filtering is explained later in the document.

GSM Cell Load must be understood here as a means to inhibit an HHO to a GSM cell to which a previouslyattempted HHO has failed in the last inhibitTimer3g2g seconds.

�A GSM target cell will have a RED Cell Color if a handover towards this cell has been rejected for loadreasons in the previous inhibitTimer3g2g seconds.

�Otherwise the Cell Color is GREEN.

�The 2G cell load detection is based on the receipt of the RANAP Relocation Preparation Failure messagewith a cause IE value equal to “Relocation failure in target CN/RNC or target system”.

Section 1 · Module 10 · Page 45

Page 510: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

To be eligible to HHO, a GSM neighboring cell (BCCH Rxlev) must be reported better than a threshold.

Section 1 · Module 10 · Page 46

Page 511: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

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 is provided by the 2G BSC.

Moreover, the RNC takes the opportunity to provide the 2G BSC, during an inter-system handover procedure,

with the 3G cell load information so as to also allow it to improve the 3G Target cell selection. The 3G cell load

information is 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 1 · Module 10 · Page 47

Page 512: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

FDD Eligible Cells filtering is the same as for iMCTA Alarm or CAC.

Filtering on HSxPA capabilities for iMCTA Service is explained later in the document.

Filtering on load criteria is explained later in the document.

Section 1 · Module 10 · Page 48

Page 513: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Unlike iMCTA Alarm and iMCTA CAC, a new filtering is introduced based on the hsxpaSegmentationEnableparameter.

When this parameter is set to True, the algorithm removes all reported cells that are not compatible with UE’sHSxPA capabilities (sent in the 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 1 · Module 10 · Page 49

Page 514: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

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 beremoved. This is applicable whatever Priority of the neighboring cell.

For instance, if targetCellColourThreshold= YELLOW and one DCH color of the neighboring cell is RED, thiscell is removed from the candidate list to HHO.

Note: an FDD cell belonging to a neighboring RNC is considered as RED as Serving RNC is not able to determineits load color.

Comparing reported neighboring cell’s iMCTA color with targetCellColourThreshold is systematicallyperformed by iMCTA Service, for load balancing purposes but also for traffic segmentation (which is based on UEand NodeB HSxPA capabilities).

� If the 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 neighboring 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 neighboring cells whose priority is worse than the Primary cell one have beenremoved at “Neighbouring Cell Searching and Filtering” stage.

Section 1 · Module 10 · Page 50

Page 515: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

GSM Eligible Cells filtering is the same as for iMCTA Alarm or CAC.

GSM Cell Load must be understood here as a means to inhibit an HHO to a GSM cell to which a previouslyattempted HHO has failed in the last inhibitTimer3g2g seconds:

� A GSM target cell will have a RED Cell Color if a handover towards this cell has been rejected for loadreasons in the previous inhibitTimer3g2g seconds.

� otherwise the Cell Color is GREEN.

The 2G cell load detection is based on receipt of the RANAP Relocation Preparation Failure message with a causeIE value equal to “Relocation failure in target CN/RNC or target system”.

Section 1 · Module 10 · Page 51

Page 516: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

HHO Decision is taken by the RNC according to the Measurement Reported on neighboring cells: HHO triggeredcan be Inter-RAT normal or blind, Inter-Freq Intra-RNC or Inter-RNC.

The period during which iMCTA Alarm waits for neighboring reported cells is bounded by 2 different guardtimers, so-called measurementGuardTimerFdd and measurementGuardTimer2g, depending on theselected target Access type.

�At guard timer expiration, if no neighboring cell is candidate for HHO (no reported cell has been reported orthe 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 Alarmonly).

� For iMCTA CAC

� RAB cannot be established and the RNC sends RANAP RAB Assignment Response (RAB failedlist) to CN.

� For iMCTA Service

� The UE remains on the initial frequency.

measurementGuardTimerFdd and measurementGuardTimer2g replace UA04.2 previous CM timers(gsmCmodeReactivationTimer, fddCmodeReactivationTimer) and HHO timers (blindHhoGsmTimer,blindHhoFddTimer).

Section 1 · Module 10 · Page 52

Page 517: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

If iMCTA Alarm or iMCTA CAC HHO to another FDD frequency or to GSM fails due to any reason (internal SRNC failure, NBAP, RNSAP, RANAP or RRC failure message) and iMCTA Alarm or CAC fallback is enabled via parameter imcta/imctaFallbackHoFailure then the RNC will once re-attempt HHO to another target cell.

The fallback is triggered only once. If the fallback attempt also fails, then no 3rd attempt is done.

The target for a fallback is selected as follows:

� “Measurement based HO”: The 2nd best cell if reported by the UE.

� “Blind HO”: The next Twin cell if configured (2nd best target).

Section 1 · Module 10 · Page 53

Page 518: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 54

Page 519: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 55

Page 520: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 56

Page 521: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 57

Page 522: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 58

Page 523: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 59

Page 524: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 60

Page 525: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 61

Page 526: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Mode: defines what triggers iMCTA (alarm, Alarm&CAC, Alarm&Service, All)

Section 1 · Module 10 · Page 62

Page 527: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 63

Page 528: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Thanks to the Compress Mode, a UE can perform an HHO to 2G with measurements.

CM for 2G neighboring cells measurements is activated when the UE has 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 the iMCTA algorithm, mostly based on UE capabilities, priority tables and available neighboring cells.

3G to 2G HHO is possible for a UE:

� having a CS service if activationHoGsmCsAllowed is set to True.

� having a PS service if activationHoGsmPsAllowed is set to True.

Section 1 · Module 10 · Page 64

Page 529: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

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 the isGsmIratHoToNextBestCellAllowed parameter introduced in UA07.

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 the 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 1 · Module 10 · Page 65

Page 530: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Global 3G->3G Inter-frequency HHOs are controlled by the is3Gto3GWithoutIurAllowedforCS and is3Gto3GWithoutIurAllowedforPS parameters 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 neighboring RNC to be the DRNC which controls both the source and the target cells.

� or a SRNS relocation UE Involved with this DRNC to become the new SRNC.

It depends on the isInterFreqHandoverOverIurAllowed flag as follows:

� f the isInterFreqHandoverOverIurAllowed flag is set to TRUE for the DRNC to control both source and target cells then inter-frequency handover over Iur is used.

� If the isInterFreqHandoverOverIurAllowed flag is set to FALSE for the DRNC to control both source and target cells then the handover is performed through SRNS relocation UE Involved.

Section 1 · Module 10 · Page 66

Page 531: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Prior to UA07, Inter-RNC HHOs 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 UA07, Inter-RNC HHOs are processed using the SRNS Relocation UE involved if the isInterFreqHandoverOverIurAllowed parameter is set to False.

Section 1 · Module 10 · Page 67

Page 532: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

The radio link to the target cell is to be set up with the RNSAP Radio Link Setup or RNSAP Radio Link Addition procedure 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 the NBAP Radio Link Deletion procedure.

Section 1 · Module 10 · Page 68

Page 533: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 69

Page 534: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

This feature provides the following enhancements regarding LTE mobility:

�Support of 3GPP Rel-8 RANAP interface for LTE to UMTS PS handover and PS Handover based CS Fallback.

� Inter-working with 3GPP Rel-8 Core Network.

�Handling 3GPP Rel-8 CS Fallback IE, allowing success rate monitoring of PS Handover based CS Fallback procedure.

�Support of partial relocation in case of LTE to UMTS PS Handover procedure by accepting only a subset of RABs supported on the UMTS layer in the RANAP relocation request procedure (maximum 3 PS RABs).

�Partial relocation isn’t limited to the case where there are more than 3 PS RABs to handover from LTE to UMTS. It is also applicable to 3 or less RABs.

� For UMTS to LTE cell reselection procedure, SIB19 with extended E-UTRAN frequency to 8 frequencies is broadcasted.

Section 1 · Module 10 · Page 70

Page 535: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Feature 104489 LTE to UMTS HHO provides Handover from LTE to UMTS and support the following procedures:

� LTE to UMTS PS HHO: incoming SRNS relocation request triggered for a UE connected in 4G radio network;Inter-RAT Mobility events used to trigger mobility 4G to 3G:

� Event A2: Serving becomes worse than threshold.

� Event B2: Serving becomes worse than threshold1 and inter-RAT neighbor becomes better thanthreshold2.

�CS Fallback from LTE to UMTS: The CS fallback procedure only could be started following the successfulcompletion of PS service relocation.

Section 1 · Module 10 · Page 71

Page 536: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 72

Page 537: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

UTRAN supports maximum 3 PDP contexts in UA08 and E-UTRAN supports till 8 RABs for a given UE.

The Ranap Relocation Request from LTE through the target SGSN may contain more than 3 RABs to be set up. Some RAB combinations/services may not be supported by the RNC. As a result, UA08.1 introduces the capability for the RNC to perform RAB selection to filter out some RABs before performing RAB matching.

Section 1 · Module 10 · Page 73

Page 538: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

conversational RABs included ?

Incoming relocation request for 4G3G:

“RAB to setup list”

partialRelocationFromLTE == true?

No

Yess

RAB Matching algorithm

Continue RAB setup for the successful RABs. Peg counter PS_Rab_Selection

RAB Matching succeessful?

Existing RAB matching algorithm.

No

Yess

Peg counter NT_Iu_relocation_request_failures_ps (537) screening 4Gto3GRejectionDueToRabMatchingFailure (12) Move the last

RAB to “failed RAB list”.

add RABs in “failed RAB list” to the “RABs Failed To Setup List” of the RANAP relocation request ack.

RAB setup succeessful?

No

Yess

Relocation preparation fails. Send RANAP relocation failure.

No

PS conv. RAB supported?

Select 1st (up to) 3 RABs fro m remaining RAB to setup list. Add the rest RABs to the “failed RAB list”.

#RABs >0?

Move all conversational RABs to “failed RAB list”

#streaming RABs > 1?

Yess

No

Keep the 1 st conv. RAB. Move other conv. RABs and all streaming RABs to “failed RAB list”

No

(#RABs ==2 && they are Sig+Conv)? or (#RABs ==1 && it is Conv.)?

No

Yess

Yess

Yess

Filter out RABs wi th GBR > MAX_ACCEPTSANCE_GBR

Keep the 1 st streaming RAB. Move other streaming RABs to “failed RAB list”

Move the remaining RAB(s) to “failed RAB list”. Select the 1 st I/B RAB from the RAB list right before the 1 st RAB matching

No

Section 1 · Module 10 · Page 74

Page 539: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

CS fallback procedure

The CS fallback procedure could only be started following the successful completion of PS service relocation as detailed in previous sections.

Regardless the Circuit Switched Fallback (CSFB) type (e.g. Mobile termination CS fallback or Mobile origination CS fallback), the CSFB procedure is always beginning with an RRC UL INITIAL DIRECT TRANSFER message of the "CN domain identity IE" set to "CS domain“, with the embedded NAS message of IDT set to either “Paging Response” or “Service Request”.

The CS service is then setup in UTRAN with PS service already established.

UA08.1 PM108661 introduces a new RNC timer (TmaxDelayForCsCallEstablishment). The timer starts only for handover with cause set to “CS fallback triggered”, after the Relocation Complete message is sent to the SGSN. The purpose of this timer is to check whether a CS call is successfully established or not after an LTE to UMTS relocation request with cause “CS fallback”.

If a CS establishment request (Initial Direct Transfer - Service Request, or Paging Response, with CS domain) is for an established PS call with a CS fallback, timer TmaxDelayForCsCallEstablishment will be running.

When the Initial Direct Transfer message is received by the RNC, this CS establishment is identified and treated as LTE to UMTS Handover with CS fallback:

�Timer TmaxDelayForCsCallEstablishment is stopped.

�CS establishment is treated as normal CS call setup.

Otherwise, this CS establishment is treated as normal CS call setup.

For LTE to UTRAN handover for CS fallback, handling the subsequent CS establishment after the PS handover completes the whole CS fallback procedure.

Section 1 · Module 10 · Page 75

Page 540: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

New UA08.1 parameters:

� isPartialRelocationFromLteAllowed {boolean TRUE, FALSE} allows accepting only a part of RABs in the RAB list contained in the RANAP relocation request from LTE.

� maxDelayForCsCallEstablishment {Integer [1..300], unit second} is the maximum delay time for a

CS call setup request to be received, after a relocation from 4G is received with cause set to “CS fallback triggered”.

Call Traces: a new CNode snapshot sub-function is added: the Snapshot CNode – Incoming relocation.

Section 1 · Module 10 · Page 76

Page 541: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.10 Edition 1

Section 1 · Module 10 · Page 77

Page 542: TMO18255_V2.0-SG-UA08-ED1
Page 543: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 1

Page 544: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 545: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 3

Page 546: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 4

This page is left blank intentionally

Page 547: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 5

Page

1 iMCRA overview 71.1 Objectives of iMCRA 81.2 iMCRA-step 1 (UA07) 101.3 iMCRA-step 2 (UA08) 111.4 Twin cells definition 122 iMCRA step 1 132.1 Redirection types 142.2 UE capabilities and call type 152.3 Cell capabilities and FaType 162.4 Candidate target cell list selection procedure 172.5 Load balancing procedure 192.6 RRC redirection based on CAC 202.7 iMCRA: RAN model 212.8 Exercise 1 222.9 Exercise 2 233 iMCRA step 2 243.1 Principle 253.2 Call type calculation 263.3 Action list mapping 283.4 Carrier selection list processing 293.5 Load condition calculation 303.6 Target carrier selection 313.7 CAC failure case 343.8 RAN model 353.9 Exercise 36

Page 548: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 6

This page is left blank intentionally

Page 549: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 7

Page 550: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

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 distribute the traffic between the different layers including 2G (GSM, CDMA) and 4G (LTE):

� 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, GSM or LTE cells at RRC connection establishment. iMCRA Step2 provides a powerful programmable RRC redirection action matrix giving great flexibility to operators for a best use of their access carrier’s resources. It provides the capability to process in parallel the RRC Connection Request message or the failure of SRB CAC based on:

� iMCRA Service may be triggered by the RRC Connection Request message, enabling RRC redirection to an FDD cell or the GSM RAT or the LTE RAT based on common or mixed RRC Redirection strategies.

� iMCRA CAC may be triggered by the failure of SRB CAC induced by any CAC failure cause, enabling RRC redirection to an FDD cell or the GSM RAT or the LTE RAT based on common or mixed RRC Redirection strategies.

� Intelligent Multi-Carrier Traffic Allocation (iMCTA) allowing handover UE to another layer when in Cell_DCH connected mode.

Section 1 · Module 11 · Page 8

Page 551: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 9

Page 552: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 10

Page 553: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

When activated, iMCRA step2 replaces the following features (meaning the user can define an action list and a carrier selection list to reproduce the function of those features):

� iMCRA Step 1

� 3G/2G Redirection based on cell load (partially)

� 3G/2G Redirection for speech call

� Load Balancing between HSPA carriers (partially, iMCRA part)

Section 1 · Module 11 · Page 11

Page 554: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

The twin cells are co-located inter-frequency cells plus cells from other Node B for blind redirection referenced by Cell Id.

Cells FDD2, FDD3, FDD4 and FDD5 are twin cells of cell FDD1.

Section 1 · Module 11 · Page 12

Page 555: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 13

Page 556: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

During the 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 cells with lowest load if CAC failure on originating cell)

None (Redirection disabled)

Section 1 · Module 11 · Page 14

Page 557: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

The UE capability 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:

From UA07, 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.

From UA07, 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 1 · Module 11 · Page 15

Page 558: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 16

Page 559: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Please note that an optional criterion introduced by UA06 feature 84900 is based on the preferred layer to distinguish the R99 services potentially served on the preferred layer from the others. It is only applicable for configurations using rrcRedirectionType = ‘capaOnly’ or ‘capaAndEstCause’.

In such conditions, 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 an RRC connection should be redirected to the DCH (R99) layer, the function check layerPreferredforR99 for both cells, in addition to the existing criteria. 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 behavior is unchanged.

�When to decide if an RRC connection should be redirected to HSPA layer, the 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 behavior 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 non-preferred cell.

This algorithm is enhanced from UA6.0, i.e. the 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).

Emergency calls are redirected in case of CAC failure only.

Section 1 · Module 11 · Page 17

Page 560: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 18

Page 561: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Load Balancing is applied for any rrcRedirectionType (capaOnly, capaAndEstCause, preferredFA and cAC) after the Candidate Target Cell List Selection procedure. This procedure will find the best target cell among the candidate target cell list provided by the Candidate Target Cell List Selection phase.

If the originating cell is included in the set of candidate cells and the originating cell color is better than rrcRedirectOrigCellColourThreshold then the call is established in the originating cell (note: not applicable for rrcRedirectionType =cAC).

Otherwise, if two or more cells are selected, the following steps (with decreasing priority) are processed until retaining one cell:

� Preference is given to the less loaded cells.

�The originating cell is selected if it is included in the list. Otherwise, select the twin cell with the round robin algorithm based on frequency number (dlFrequencyNumber > originating one).

Section 1 · Module 11 · Page 19

Page 562: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

RRC Redirection can trigger re-try of the 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, the 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 the RRC Connection Reject message by 3G to 2G Redirection based on cell load.

Section 1 · Module 11 · Page 20

Page 563: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

In UA08.1, the “TwinCellList” parameter moves from the InterfreqHhoFddCell object to the FDDCell

object.

Section 1 · Module 11 · Page 21

Page 564: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 22

Page 565: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 23

Page 566: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 24

Page 567: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 25

iMCRA CALL TYPE CALCULATION

This function calculates the iMCRA call type associated to the RRC establishment cause received in the RRC Connection request message. It can be distinguished between iMCRA basic call types and iMCRA group call types.

The iMCRA group call types cover a set of iMCRA basic call types.

iMCRA CARRIER SELECTION PROCESS

iMCRA has two logical sub-functions: iMCRA Service and iMCRA CAC.

iMCRA Service covers triggers of RRC Connection Request message reception.

iMCRA CAC covers failure of SRB CAC induced by any CAC failure cause.

The operator can assign one iMCRA Action List for iMCRA Service and one iMCRA Action List for iMCRA CAC per FDD cell.

ACTION LIST MAPPING

This function provides a pointer to the iMCRA Carrier Selection List based on the iMCRA call type matching;

i.e. Call Type = HspaGroupCall can point to “HSPA carrier selection list”

i.e. Call Type = DchGroupCall can point to “DCH selection list”

CARRIER SELECTION LIST PROCESSING

The Carrier Selection List consists of load conditions and target carrier process.

It permits user to configure criteria for target carrier selection.

The target carrier can contain an FDD cell or GSM or LTE RAT or it can be empty.

LOAD CONDITION CALCULATION

This function will verify the Load Condition to apply for the associated target carrier list.

TARGET CARRIER LIST PROCESS

This function will select a suitable target carrier for redirection among the list of target carriers fulfilling the load condition.

Page 568: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 26

iMCRA Basic Call type and iMCRA Group Call type calculation can be split to several steps:

�Step1 RRC message derives “RRC cause Types”

�Step2 RRC cause types mapped to Basic call types

�Step3 Basic call types simplify to Group call Types

Group Call Types are listed as follows:

�MO CS Group Call: Mobile originated CS voice call over DCH or HSPA and mobile originated CS conversational calls, if established by a UE < Rel-6.

�CS Group Call: Mobile originated or terminated CS voice or data call over DCH or HSPA and Mobile originated or terminated Conversational Calls if established by a UE < Rel-6.

�DCH Group Call: CS or PS call over DCH.

�HSPA Group Call: CS or PS call over HSPA.

�PS Data Group Call: PS call over DCH or HSPA.

�CS/PS Group Call: CS or PS call over DCH or HSPA.

�All Group Call: CS or PS call over DCH or HSPA or signaling only connections.

Page 569: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 27

Basic Call Types are listed as follows:

� MO CS Voice Call: Mobile originated CS voice call over DCH (UEs > = Rel-6) except UEs which are VoHSPA capable

�MT CS Voice Call: Mobile terminated CS voice call over DCH (UEs > = Rel-6) except UEs which are VoHSPA capable

� MO CS Conversational Call: Mobile originated CS voice or data call over DCH (UEs < Rel-6)

�MT CS Conversational Call: Mobile terminated CS voice or data call over DCH (UEs < Rel-6)

�CS Voice Call: Mobile originated or terminated CS voice call on DCH, if the use of RRC establishment cause is disabled (UEs > = Rel-6)

�CS Data Call: Mobile originated or terminated CS data call on DCH, if the use of RRC establishment cause is disabled (UEs > = Rel-6)

� PS DCH Call: PS data call over DCH

� HSDPA Data Call: PS data call over HSDPA.

� HSxPA Data Call: PS data call over HSPA

� DC Data Call: PS data call over HSPA and dual cell option

� LTE Data Call: PS data call over HSPA and LTE redirection option

� Other Call: Signalling connections (e.g. location registrations). If the operator has disabled the use of the RRC establishment cause by setting isRedirectionBasedOnEstablishmentCause to FALSE, then “Other Call” includes all calls for UEs < Rel-5 and all calls for Rel-5 UEs in CS domain (for all Rel-5 UEs in the PS domain “HSDPA Data Call” is assumed).

Page 570: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 28

This function provides a pointer to the iMCRA Carrier Selection List based on the iMCRA call type matching. The calculated iMCRA call type shall be matched with configured call type in the action list per action (basic call types or group call types).

The first action in the list has the highest priority. Thus basic call types should be configured first before actions for group call types. For the redirection of a certain percentage of calls according to the "Redirect Percentage" field in the action list, the following formula applies: Redirect if (RedirectPercentage + (#call * RedirectPercentage) % 1 >= 1); if the load condition is fulfilled and the call is selected according to the formula, a selected target carrier is selected. Otherwise, the RNC will check the next load condition, if configured.

Maximum 50 Action Lists can be defined. Each Action List may contain maximum 15 actions.

Carrier Selection Algorithm

End

N Call Type in Action List?

Y

Carrier Selection List

Processing

Y Target Carrier empty?

N

N

End of Action List?

Y

Select next Action Lis t entry

Target carrier = originating cell

Output: Target Carrier (FDD cell or RAT)

Target carrier = originating cell

Y

Redirection required according

to percentage figure?

Update redirection percentage figure

N

Page 571: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 29

After matching the calculated iMCRA call type with one redirection action configured in the action list, RRC Redirection Decision shall process its associated "Carrier Selection List”.

The Carrier Selection List contains a load Rule per instance plus an associated list of allowed target carriers (target carrier list). The target carrier list includes FDD carriers or GSM or LTE RAT.

The following figure provides an example to the Carrier Selection List. The following conditions apply:

� The first instance (#1) of the Carrier Selection List has the highest priority and is processed first (the conditions stored in the instances (#1, #2…#y) of the Carrier Selection List are implicitly linked by an “OR” operation = If the load condition does not match or no target carrier has been found, then the next instance of the Carrier Selection List is processed).

� A carrier selection rule can comprise up to four load conditions, which are linked by a logical AND operation, i.e. if all of conditions of a rule are fulfilled, the carrier(s) in the target carrier list are applied.

� Up to 150 Carrier Selection Lists can be defined per RNC (=three in mean per Action List). Each Carrier Selection List can contain up to 20 rules with up to 4 conditions each.

Page 572: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 30

This function will verify the Load Condition to apply for the associated target carrier list. Theload condition in the Carrier Selection List comprises:

� A frequency reference to an FDD frequency (F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, Fo); carrier is a reference to a frequency object defining the carrier (F1 – F12) or it references to the originating carrier (Fo).

� A load type (Single and Combined load type).

� An operator (=, <=, <, >, >=, TRUE); If the "operator" field of the condition is set to TRUE, then the load condition is always true.

� A load value (Green < Yellow< Red < Black).

The RNC supports the following single load types as part of a load condition in the Carrier Selection List: DL POWER Load; DL OVSF Load; DL IUB Load; DL CEM Load; UL CEM Load; UL RX POWER Load; HSDPA Load;

The RNC supports the following combined load types as part of a load condition in the Carrier Selection List: CEM Load = max (DL CEM and UL CEM loads); DL RADIO Load = max (DL POWER and DL OVSF loads); DL DCH Load = max (DL RADIO, DL CEM and DL IUB loads); UL DCH Load = max (UL RX POWER and UL CEM loads); DCH Load = max (DL DCH and UL DCH loads); HSDPA UL DCH Load = max (HSDPA Load and UL DCH Load); HSPA Load = HSDPA load; TOTAL Load = max (DCH and HSPA loads); CALL TYPE Load - DCH or HSDPA load.

Page 573: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 31

Page 574: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 32

If the target carrier list contains two or more applicable FDD cells, the following sorting rules are applied:

1. Less loaded FDD cells shall be ranked highest.

2. Among FDD cells with equal load, the RNC shall rank the origination cell first if it is applicable.

3. Among FDD cells with equal load without originating cell, the RNC shall rank the FDD cells sorted by their dlFrequencyNumber from low to high (round robin).

The load criterion to be used for load comparison depends on the call type, the UE´s HSDPA/HSUPA capability and the FDD cell capability. The following load criteria are fixed coded:

The 2nd and 3rd criteria are only applied, if the previous selection criterion results in multiple cells with the same load. The calculated DCH cell load value is derived from the individual cell loads and their weighted load color

Sort Criterion Call Type belonging to 1st 2nd 3rd Comment

DCH group call type DCH Load Calculated DCH cell load value

HSPA group call type HSPA Load UL DCH Load FDD cell needs to support HSDPA. If cell does not support HSDPA then use DCH load.

Page 575: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 33

In case of configured GSM target carrier, the RNC cannot check the GSM inter-RAT capability of the UE upon RRC connection request. Nevertheless, the UE is redirected to GSM, which is performed by the UE via intra-PLMN cell selection procedure. If the UE does not support the deployed GSM band, it will repeat the RRC connection request.

Page 576: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 34

Each FDD cell refers to two action lists, one is used for iMCRA Service actions and the other is used for iMCRACAC actions.

Each action of an action list references to a Carrier Selection List.

Multiple FDD cells can point the same action list / Multiple actions can reference to the same Carrier Selection List.

Page 577: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 35

Page 578: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 36

Page 579: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 37

Page 580: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.11 Edition 1

Section 1 · Module 11 · Page 38

Page 581: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.12 Edition 1

Section 1 · Module 12 · Page 1

Page 582: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.12 Edition 1

Section 1 · Module 12 · Page 2

This page is left blank intentionally

Document History

Edition Date Author Remarks

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

Page 583: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.12 Edition 1

# 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 1 · Module 12 · Page 3

Page 584: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.12 Edition 1

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 1 · Module 12 · Page 4

Page 585: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.12 Edition 1

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 1 · Module 12 · Page 5

Page 586: TMO18255_V2.0-SG-UA08-ED1

Copyright © 2012 Alcatel-Lucent. All Rights Reserved.TMO18255_V2.0-SG-UA08-Ed1 Module 1.12 Edition 1

Section 1 · Module 12 · Page 6

Page 587: TMO18255_V2.0-SG-UA08-ED1

All Rights Reserved © Alcatel-Lucent @@YEAR

@@COURSENAME - Page 1

Page 588: TMO18255_V2.0-SG-UA08-ED1

All Rights Reserved © Alcatel-Lucent @@YEAR

@@COURSENAME - Page 2

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