algorithms

UA06 R99 Algorithms Description - Page 1All Rights Reserved © Alcatel-Lucent 2009

All Rights Reserved © Alcatel-Lucent 2009

9300 W-CDMAUA06 R99 Algorithms Description

STUDENT GUIDE

TMO18044 D0 SG DENI3.0Issue 1

All rights reserved © Alcatel-Lucent 2009 Passing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent



UA06 R99 Algorithms Description9300 W-CDMA2

Empty page

Switch to notes view!

This page is left blank intentionally




Terms of Use and Legal Notices

Switch to notes view!1. Safety WarningBoth lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the equipment alone.

The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.

2. Trade MarksAlcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.

All other trademarks, service marks and logos (“Marks”) are the property of their respective holders, including Alcatel-Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.

Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to change without notice.

3. CopyrightThis document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No other use or transmission of all or any part of this document is permitted without Alcatel-Lucent’s written permission, and must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from Alcatel-Lucent.

Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly prohibited.

User obtains no rights in the information or in any product, process, technology or trademark which it includes or describes, and is expressly prohibited from modifying the information or creating derivative works without the express written consent of Alcatel-Lucent.

All rights reserved © Alcatel-Lucent 2009

4. DisclaimerIn no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel-Lucent has been advised of the possibility of such damages.

Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an endorsement, nor a recommendation.

This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely accurate.

Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment and its operation, or contact your nearest Alcatel-Lucent representative for more information.

The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-Lucent disclaims any warranties in connection with the products as used and described in the courses or the related documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties, including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of dealing, usage or trade practice.

Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in nature

5. Governing LawThe products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including, but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these Terms of Use and Legal Notices shall remain in full force and effect.




Blank Page






Course Outline

About This CourseCourse outlineTechnical supportCourse objectives

1. Topic/Section is Positioned HereXxxXxxXxx

2. Topic/Section is Positioned Here






1. UTRAN Parameters Objects

1. Module 1

2. UTRAN Configuration

1. Module 1

3. Services

1. Module 1

4. Measurements

1. Module 1

5. Mobility Idle Mode

1. Module 1

6. Call Admission

1. Module 1

7. Call Management

1. Module 1

8. Power Management

1. Module 1

9. Mobility Connected Mode

1. Module 1

10. Glossary

1. Module 1




Course Outline [cont.]






Course Objectives


Welcome to UA06 R99 Algorithms Description

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

describe the organization of UTRAN parametersevaluate the impact of parameter modificationsdescribe the UTRAN Configuration Management process and toolsdescribe main measurements purpose and usedescribe Compressed Mode principles, implementation, configuration, and impacts on other UTRAN featuresdescribe the mobility in Idle and the associated parameters: Cell Selection, Cell reselectiondescribe the call establishment and the associated parameters: RAB Matching, IRM RAB to RB Mapping, CAC, CELL_FACH admissiondescribe the packet data management principles: Always On, Rb Rate Adaptation, iRM Scheduling, iRM Preemption and associated parametersdescribe power management and control with the associated parameters describe Handover types and purpose: SHO, Alarm Handovers, iMCTA algorithm




Course Objectives [cont.]






About this Student Guide

Switch to notes view!Conventions used in this guide

Where you can get further information

If you want further information you can refer to the following:

Technical Practices for the specific product

Technical support page on the Alcatel website: http://www.alcatel-lucent.com

Note Provides you with additional information about the topic being discussed. Although this information is not required knowledge, you might find it useful or interesting.

Technical Reference (1) 24.348.98 – Points you to the exact section of Alcatel-Lucent Technical Practices where you can find more information on the topic being discussed.

WarningAlerts you to instances where non-compliance could result in equipment damage or personal injury.




About this Student Guide [cont.]






Self-assessment of Objectives

At the end of each section you will be asked to fill this questionnairePlease, return this sheet to the trainer at the end of the training


Instructional objectives Yes (or globally

yes)

No (or globally

no) Comments

1 To be able to XXX

2

Contract number :

Course title :

Client (Company, Center) :

Language : Dates from : to :

Number of trainees : Location :

Surname, First name :

Did you meet the following objectives ?Tick the corresponding box

Please, return this sheet to the trainer at the end of the training




Self-assessment of Objectives [cont.]


Instructional objectives Yes (or Globally

yes)

No (or globally

no) Comments

Thank you for your answers to this questionnaire

Other comments

Section 1 · Pager 1

All Rights Reserved © Alcatel-Lucent 20093JK10045AAAAWBZZA Edition 1

Do not delete this graphic elements in here:


Module 13JK10045AAAAWBZZA Edition 1

Section 1UTRAN Parameters Objects


TMO18044 D0 SG DENI1.0Edition 3




9300 W-CDMA · UA06 R99 Algorithms DescriptionUTRAN Parameters Objects1 · 2

Blank Page


First editionEl Abed, AchrafeCharneau, Jean-Noël

2009-02-2901

RemarksAuthorDateEdition

Document History





Module Objectives

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

Describe the organization of UTRAN parameters

Evaluate the impact of parameter modifications

Describe the UTRAN Configuration Management process and tools





Module Objectives [cont.]






Table of Contents

Switch to notes view! Page

1 UTRAN Configuration Overview 71.1 UTRAN Configuration Process & Tools 81.2 Customer Input Questionnaire 91.3 UTRAN CM Solution Overview 101.4 UTRAN CM XML Files Exchange 11

2 Organization of UTRAN Parameters 122.1 UTRAN Objects Mapping 132.2 UTRAN Parameter Domain 142.3 RAN Parameter Types 152.4 RAN Attribute Activation Classes 162.5 RAN Object Activation Classes 172.6 RRM Subtree 182.7 Configuration Classes Instantiation 19





Table of Contents [cont.]







1 UTRAN Configuration Overview






1.1 UTRAN Configuration Process & Tools

ProvisioningActivities

PlanningActivities

Main ServerConfiguration Data

OA&MActivities

ND

RF

IP

ATM

WPS for Access

This process describes how to configure UTRAN Network Elements (NEs) during a deployment phase. The main steps are the following:

Planning Activities:

Check UTRAN CIQs consistency

Provide neighboring XML files for cell planning

Provide last WPS templates and ATM Profile

Provisioning Activities:

Generate full configuration with WPS

Export XML files from WPS

Operation Administration & Maintenance Activities:

Load configuration data into their respective NEs

Build the database (MIB) of the RNS and make sure all the local information are up-to-date.

Perform real-time adjustments to the initial network configuration.

Note:These steps do not necessarily apply to other contexts, such as introduction of new features, addition of new NEs, network optimization, …






1.2 Customer Input Questionnaire

CIQ

• RRM Parameters• RRM Parameters• RRM Parameters• …

OperatorTeams

• Network Requirements• Deployment Constraints• ...

• Network System Definition• Engineering rules• Addressing rules• ...

EngineeringTeams

(Core, Local)

• IP Parameters

• IP Parameters

• IP Parameters

• ...

• ATM Parameters• ATM Parameters

• ATM Parameters• …

•Net

work D

esign

•Net

work D

esign

•Net

work D

esign

•…

• RF Parameters

• RF Parameters

• …

The Customer Input Questionnaire is a repository where all parameter values and configuration data required for the later datafill of the UTRAN subsystem are stored.

As mentioned in the document header: "The CIQ is used by the Wireless Network Engineering team, Regional Engineering and deployment personnel to better understand the customer requirements”.

Each manager of a Local Engineering team (in relation with the other activity groups) is in charge of filling his own part of the CIQ along with the operator:

Radio Frequency (RF) staff fills RF parameters. RF team can also provide XML files coming from any cell planning tool, such as iPlanner.

IP engineering staff fills the IP addresses .

ATM engineering staff fills the ATM parameters…

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

At WPS level, the UTRAN datafill engineer is in charge of checking the consistency and completeness of the UTRAN CIQs.






1.3 UTRAN CM Solution Overview

Provisioning OA&M

Engineering Tools

XML Files

OpenInterface

BTSC-NodeI-Node

RNC

Main ServerWPS Access

NodeB

Wireless Wireless –– Network Management SystemNetwork Management System

OffOff--lineline OnOn--lineline

XML

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

off-line configuration tool to support network engineering

on-line configuration tool to support network operations

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

Off-line Configuration is designed to support efficient bulk configuration of the UTRAN by engineering staff. Users can import, modify and export data, both from the UMTS access network and from 3 rd party engineering tools (such as iPlanner). Off-line Configuration delivers a seamless network-engineering environment from initial network design through to actual network configuration.

On-line Configuration has been designed to change the configuration of the UTRAN in real-time. Not adapted to bulk configuration, the On-line configuration mainly concerns specific operations, such as extending the network, adding NEs, …






1.4 UTRAN CM XML Files Exchange

Live Network

WPSWPS

Impo

rt/E

xpor

t

S

S

Impo

rt/E

xpor

t

D

D

WPS Import

WPS Export

XML Snapshots

XML WorkordersMain Server

WPSWPS

WNMS Export

WNMS ImportDD

SS

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

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

Snapshot

Work order

According to the option selected, the result of the export will be very different:

Exporting the current state of the network as a snapshot means merging the elementary operations performed by the work orders with the initial snapshot. As WPS says: “the current planning view is the result of the execution of work orders on the initial snapshot”.

Exporting the work order means gathering all the elementary operations performed upon a snapshot into a CM file for further use (other WPS platforms, W-NMS).





2 Organization of UTRAN Parameters






2.1 UTRAN Objects Mapping

Hardware Equipment

RNCEquipment

Logical Configuration

NodeB

FDDCell /0

FDDCell /1 BTSCell /1

BTSCell /0

PP15K -IN

RNC

BTSEquipment

CN IN

The RAN model is split into two parts:

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

Software Configuration: This other part groups all elements that defines the Node B and RNC logical configuration. It is called “logical part” because it defines the software for logical radio sectors and logical RNC nodes.

To perform a link between the Hardware Equipment (physical part) and the Software Configuration (logical part), it is necessary to link several elements from both parts. For example to link the logical sectors to the physical equipment, the user has to attach a BTSCell (physical part) to one FddCell (logical part). This specific operation is called “Mapping”.






2.2 UTRAN Parameter Domain

RAN ModelBased

InterfaceNode

Access Node

NodeB

MIBMIB

PassportBased

W-NMS

Control Node

WiPS

MIBMIB

Two different types of parameters are designed to configure a UMTS Access Network:

Control Node, Node B and RAN parameters

Interface Node, Access Node and Passport parameters

Changing parameter values may impact the behavior of the live network.

For RAN parameters, the impact triggered by a parameter modification is strongly linked with the parameter classes (see next slide).

For Passport parameters, it is not always easy to predict the impact of a parameter modification. Possible consequences are:

nothing

reset of an interface

reset of a module

reset of a node






2.3 RAN Parameter Types

RNC

Static

Non-Static

OMC

Customer

Example:

There are two main kinds of parameters in the Alcatel-Lucent system: static and configuration parameters.The static parameters have the following characteristics:

They have a fixed value and cannot be modified at the Access OAM.They are part of the network element load.A new network element needs to be reloaded and built in order to change their values.They cannot be modified by the customer.

The configuration parameters have the following characteristics:They are contained in the Access OAM database.

The customer parameters (~2000) 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 upgradeCustomer_setting:Parameters which have to be set by customer, either due to design or to activate optional featuresExpert_tuning:Parameters which can be modified by customer, but with a specific support from Alcatel-Lucent, because of the complexity or sensitivity of this parameter with respect to QoS.Customer_tuning:Parameters which can be modified by customer, without specific support from Alcatel-Lucent






2.4 RAN Attribute Activation Classes

Activation classes apply toCustomer and Manufacturer parameters

Class 0

Class 3 (A1, A2, B)

Class 2MIB

MIB build required(most common case)

lock/unlock required

On-line modification allowed

Class0: Value set at object creation. Parameters require a build to be taken into effect on the NEs – large impact on system

Class2: parameters require a lock of the object(or its parent object) in order to change the parameter value- slight impact on system

Class3: the parameter can be changed online without impact on the service. Three sub-classes are derived from Class 3:

Class 3-A1: new value is immediately taken into account.

Class 3-A2: new value is taken into account upon event reception (service establishment, SRLR, LCS, etc.).

Class 3-B: new value is taken into account for next calls.

Customer: the parameter is configurable from the OMC and seen by the operator

Manufacturer: the parameter is configurable from the OMC and only seen by Alcatel-Lucent engineering teams

Example:

3-a2maximumNumberOfUsersHSDPACellClass

3-a1CallAdmissionRatioPowerPartConfClass

ClassMO Attribute NameMO Name






2.5 RAN Object Activation Classes

Not Allowed

Allowed

Allowed With Lock

Allowed With Parent MIB

MIB build required

lock/unlock required

parent modification required

On-line modification allowed

On-line Creation / Deletion behavior

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

Not Allowed:

The object can not be created/deleted online, a build is required.

Allowed With Parent:

The object can be created/deleted online but the operation requires the creation/deletion of the parent.

Allowed With Lock:

The object can be created/deleted online but the operation requires locking the object or one of its ancestors in the containment tree.

Allowed:

The object can be created/deleted online.






2.6 RRM Subtree

ConfigurationClassX

InstanceNInstanceN

Instance...Instance...

Instance2Instance2

Instance1Instance1

ConfigurationClassZ

InstanceNInstanceN


Instance3Instance3

Instance2Instance2

Instance1Instance1

ConfigurationClassY

InstanceN

Instance...

Instance...

Instance3

Instance2

Instance1

ConfigurationClassY

InstanceN

Instance...

Instance...

Instance3

Instance2

Instance1

InstanceNInstanceN



Instance3Instance3

Instance2Instance2

Instance1Instance1

RNC

RadioAccessService

DedicatedConf

Radio Resource Management is an essential piece of the RNC controlling the radio resources allocated to the users.

The RadioAccessService object is the root of the RRM architecture. It includes a set of parameters that applies to the whole Radio Network Subsystem.

Some of the parameters of the RRM tree are stored in libraries composed of Configuration Classes and Configuration Classes Instances.

There are 7 Main Configuration Classes, some of them containing children:

CacConfClass

HoConfClass

MeasurementConfClass

NodeBConfClass

PowerConfClass

PowerPartClass

PowerCtrlConClass

Each of these Configuration Classes can have a maximum of 5 different instances. Each instance corresponds then to a predefined set of parameters (see example next page).






2.7 Configuration Classes Instantiation

NeighbouringRNCcacConfClassId 0

RNC

RadioAccessService

DedicatedConf

MeasurementConfClass PowerCtrlConfClass CacConfClassHoConfClass

NeighbouringRNC

Example

-50.0maxUlInterferenceLevel

384maxUlEstablishmentRbRate

85firstRlOvsfCodeCacThreshold

CacConfClass/ 0

-50.0maxUlInterferenceLevel

384maxUlEstablishmentRbRate

85firstRlOvsfCodeCacThreshold

CacConfClass/ 0

Configuration Classes are involved in Node B, FDDCell and NeighbouringRNC configuration.

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.

These parameters will be taken into account when the Iur are datafilled during WPS sessions.





Module Summary

This lesson covered the following topics:

Organization of UTRAN parameters

The impact of parameter modifications

UTRAN Configuration Management process and tools





Self-assessment on the Objectives

Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this moduleThe form can be found in the first partof this course documentation





End of ModuleModule 1






Section 2UTRAN Configuration






9300 W-CDMA · UA06 R99 Algorithms DescriptionUTRAN Configuration2 · 2

Blank Page



2009-02-2901

•Replacement of cNodeCapacity parameter by numberOfServiceGroups for RNC object•Clarification about cellSize parameter

Charneau, Jean-Noël2009-04-1002


Document History





Module Objectives

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

Describe OAM Shared Objects and associated parameters

Describe RNC configurations and associated parameters

Describe Node B configurations and associated parameters

Describe BTS configurations and associated parameters











Table of Contents


1 OAM Objects Configuration 71.1 Channel Numbers 81.2 OAM Shared Objects 9

2 RNC Configuration 102.1 Identification & Capacity 11

3 Node B Configuration 123.1 FDDCell Identifiers 133.2 Scrambling Codes 143.3 Synchronization 153.4 Neighboring Cells Definition 163.5 RAN Model Evolution: Example 173.6 SIB11/DCH Neighboring Lists 183.7 Configuration Class Instantiation 19

4 BTS Configuration 204.1 BTSCell Identifiers 214.2 Local Cell Groups 224.3 Sectors and Clusters: 6 sectors Softer Handover 234.4 Frequency Groups and TRM Defense Mechanism 244.5 STSR 3 configuration 254.6 STSR 2+X configuration introduction 26

4.6.1 STSR 2+x configurations Dual-Band NodeB 274.7 Antenna Access 284.8 Six RRH per NodeB 29

4.8.1 Six RRH per NodeB: Dual-band Distributed Node B 304.9 Rake Receiver 31

4.9.1 Searcher Window Usage during First RLS: iCEM case 324.9.2 Searcher Window Usage during First RLS: xCEM case 334.9.3 Searcher Window Usage during non-First RLS 34

4.10 Ultra extended cell mode – configuration aspects 354.11 NodeB capacity licensing 36

4.11.1 Parameters involved in capacity limitation 374.11.2 NodeB capacity licensing:RMD objects and parameters 384.11.3 NodeB capacity licensing:Capacity update example 39

Module Summary 40Self-assessment on the Objectives 41End of Module 42












1 OAM Objects Configuration






1.1 Channel Numbers

RNC

ulFrequencyNumber (FDDCell)

Operator (OAM)

dlFrequencyNumber (FDDCell)

FDDCell

NodeBCommonParam

9662-99381930-19909262-95381850-19102

10562-108382110-21709612-98881920-19801 and 3

UARFCNDL (MHz)UARFCNUL (MHz)ITU Region

NodeB

The frequency of a carrier is defined:

in uplink by the ulFrequencyNumber parameter

in downlink by the dlFrequencyNumber parameter

Both parameters correspond to the UARFCN (UTRA Absolute Radio Frequency Channel Number) where: UARFCN = 5 * Frequency (MHz).

UTRAN is designed to operate with the following Tx-Rx frequency separation:

ITU Region 1 & 3; duplex shift = 190 MHz

ITU Region 2; duplex shift = 80 MHz

However, it is possible to have a channel separation which is different from these standard values, due to the channel raster.

The channel raster is 200 kHz, which means that the center frequency must be an integer multiple of 200 kHz.

The nominal channel spacing is 5 MHz, but this can be adjusted to optimize performance in a particular deployment scenario.






1.2 OAM Shared Objects

frequencyBandListmobileCountryCodemobileNetworkCode

type

(Operator)

dlFrequencyListtestFrequency

ulFrequencyList

(NodeBCommonParam)

GSMBandIndicator

(RNCCommonParam)

OAM shared objects have no existence outside the OAM tools (above slide shows how these objects are displayed in WPS for Access). They are particularly useful to ease and secure the parameters setting of RAN nodes and sub-components.

frequencyBandList indicates the frequency band list supported that can be:

umtsBand, umts1900Band, umts1800Band, umts2100-1700Band, umts850Band, umts800Band, umts2600Band, umts900Band, umts1700Band

mobileCountryCode identifies the country in which the PLMN is located. The value of the mobileCountryCode is the same as the three digit MCC contained in the IMSI.

mobileNetworkCode identifies the PLMN in that country. The mobileNetworkCode takes the same value as the two or three digit MNC contained in the IMSI.

type parameter clarifies the access rights assigned to the operator. Without Utran Sharing (nominal case) the standard type is chosen.

dlFrequencyList and ulFrequencyList record the listing of applicable UARFCNs in the network for Downlink and for Uplink.

The testFrequency gives the UTRA Absolute Radio Frequency Channel Number of the Down Link Frequency used by the BTS to detect its RF cabling.

GSMBandIndicator identifies which is the GSM band used in the whole network.





2 RNC Configuration





2 RNC Configuration

2.1 Identification & Capacity

RNC NodeB

rncId (RNC)

RNC

rncId (RNC)

NodeB

NodeB

numberOfServicesGroup (RNC)

NodeB

NodeB

NodeB

NodeB

serviceGroupId (NodeB)

serviceGroupId (Iub)

Iub

Iub

Iub

The different RNCs of the network are simply identified by their rncId under the RNC object.

The capacity of the RNC in terms of number of calls, number of supported BTS and cells depends on two major factors:

The number of TMUs (hardware configuration)

The software configuration

The parameter cnodeCapacity is not anymore supported in UA6.

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

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

The number of service group of a RNC is specified by the parameter numberOfServiceGroups of the RNC object.

The parameter serviceGroupId of Iub object specifies which service group this Iub interface is assigned to. All IubIfs provisioned with the same serviceGroupId will be processed by the same PMC-TMU processor. The serviceGroupId provisioned on this IubIf must match the serviceGroupId configured on the RNC NodeBmanaged object.

hsiddhar

Sticky Note

Number of TMU





3 Node B Configuration






3.1 FDDCell Identifiers

BTSEquipment

Operator (OAM)

FDDCell BTSCell

Logical Objects(3GPP)

Physical Objects(Alcatel-Lucent)

RNC

NodeB

cellId (FDDCell)

rncId (RNC)

“ucid” (FDDCell)

+

=

localCellId (FDDCell)

The standardization of the Iub interface has pushed Alcatel-Lucent to define an object model based on a logical part and a physical part in order to cope with the multi-vendor configurations:

The logical part of the equipment (Node B and RNC) is managed by the OMC-R.

The physical part of the equipment (BTS) is managed by the OMC-B.

The mapping between the two parts is ensured by the localCellId parameter, coded on 28 bits, found under the FDDCell and the BTSCell objects. It is advisable to have a unique localCellId on the whole network for OAM purposes, to prevent problems during neighboring declaration.

In the UTRAN, the different Cells (part of the Node Bs) are identified uniquely by their ucid.

This ucid contains the identifier of the RNC, the rncId, coded on 12 bits, defined under the RNC object and also the cellId, coded on 16 bits, defined under the FDDCell object.






3.2 Scrambling Codes

NodeB

primaryScramblingCode (FDDCell )

aichScramblingCode (RACH)

sccpchDlScramblingCode (SCCPCH)

Scrambling code

Channelization code 1



User 1 signal

User 2 signal

User 3 signal

UE is surrounded by BTSs (Base Transceiver Station), all of which transmit on the same W-CDMA frequency.

It must be able to discriminate between the different cells of different base stations and listen to only one set of code channels. Therefore two types of codes are used:

DL Channelization CodeThe user data are spread synchronously with different channelization codes. The orthogonalityproperties of OVSF enable the UE to recover each of its bits without being disturbed by other user channels.

DL Scrambling CodeScrambling is used for cell identification.

Scrambling Code parameters

The Primary Scrambling Code (P-SC) of each cell it set with the primaryScramblingCode parameter of the FDDCell object. The range of the P-SC must be within 0 to 511. On the Iub interface, the system will convert this value (defined as i) using the following formula: P-SC = 16*i.

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






3.3 Synchronization

F1F1

F1

F2

F2F2

tCell = 0

tCell = 0

tCell = 3

tCell = 3

tCell = 6

tCell = 6

Twin Cells

tCell (FDDCell)NodeB

The synchronization channels (P-SCH) are transmitted in all cells of the same Node B. The synchronization bursts need to be separated in time between the cells of the same Node B on a same carrier.

As defined in the 3GPP recommendations (TS 25.402), tCell is used to skew cells in the same Node B in order to not get colliding SCH bursts (one SCH burst is 1/10th of a slot time).

The tCell parameter avoids to have overlapping P-SCHs in different sectors of a same NodeB. It represents the timing delay relative to BFN used for defining start of SCH, CPICH and DL scrambling code in a cell.

The tCell parameters value (from its respective FDDCell) shall respect the following rules:

The tCell parameter must be different for the cells which have the same frequency.

The tCell parameter must be identical for a cell and its twin cell in case of a STSR-2 configuration.






3.4 Neighboring Cells Definition

RNC/UserLabelrncId

RemoteFDDCell/userLabel“RemoteFDDCell attributes” as:neighbouringFDDCellIdmobileCountryCodemobileNetworkCode

UMTSNeighbour/0

UmtsNeighbouringRelation/userLabel“neighboring attributes”

UA6.0 - UMTSFddNeighbouringCell/userLabelumtsNeighCellId (read only)umtsNeighRelationIdsib11OrDchUsage

NodeB/UserLabel

FDDCell/userLabel“FDDCell attributes” including:cellidmobileCountryCodemobileNetworkCode

Specific change on all the 3G neighbouring in UA6, goal is to rebuild the neighbouring with userLabel as identification:

UMTS objects related to neighboring, use radio identifier parameters as object identifier (model) in order to facilitate their identity especially at GUI.

Then, any regular operation involving modification of FDDCell radio identifiers (re-parenting, cellidmodification …) force to delete and recreate related neighboring objects and may lead to have a high operational impact. This impact could even be increased in future release by normal evolution of neighbouring aspects that would be requiring more and more neighbouring objects.

To avoid this and to simplify operations affecting neighbouring and enhance operational effectiveness, an evolution on UMTS Neighbouring model has been applied in UA06.0: usage of the userLabel of the target FDDCell as identifier to be independent of telecom identifier modification.






3.5 RAN Model Evolution: Example

FDDCell/Cell2“attributes” including:cellidmobileCountryCodemobileNetworkCode

FDDCell/Cell1“attributes” including:cellidmobileCountryCodemobileNetworkCode

RNC1

UMTSNeighbour/0

UMTSFddNeighbouringCell/Cell2umtsNeighCellId (read only)umtsNeighRelationId = indoorsib11OrDchUsage = sib11AndDch

NodeB1

RNC1

RemoteFDDCell/Cell3“attributes” including:neighbouringFDDCellIdmobileCountryCodemobileNetworkCode

UMTSFddNeighbouringCell/Cell3umtsNeighCellId (read only)umtsNeighRelationId = outdoorsib11OrDchUsage = sib11AndDchUMTSFddNeighbouringCell/Cell4

umtsNeighCellId (read only)umtsNeighRelationId = outdoorsib11OrDchUsage = sib11AndDch

Cell1

Cell2

Cell3

Cell4

NodeB1

NodeB2

UmtsNeighbouringRelation/indoor“attributes” including:neighbouringCellOffset = 0 qOffset1sn = 3qOffset2sn = 2…

UmtsNeighbouringRelation/outdoor“attributes” including:neighbouringCellOffset = 3 qOffset1sn = 3qOffset2sn = 3…

RemoteFDDCell/Cell4“attributes” including:neighbouringFDDCellIdmobileCountryCodemobileNetworkCode






3.6 SIB11/DCH Neighboring Lists

Measurement ControlRRC

OR

SI broadcastP-CCPCH

UE

sib11OrDchUsage (UMTSFddNeighboringCell)

sib11OrDchUsage (GSMNeighbouringCell)

NodeB

SIB11+

DCHDCH

SIB11+

DCH

DCH

DCH

DCH

SIB11+

DCH SIB11+

DCH

SIB11+

DCH

DCH

DCH

DCH

SIB11+

DCHDCH

SIB11+

DCH

SIB11+

DCH

SIB11+

DCHDCH

DCH

DCHDCH

DCH

SIB11+

DCH

FDDCell

DCH

SIB11+

DCH

DCH

DCH

SIB11+

DCHDCH

DCH

•sib11AndDch•sib11Usage•dchUsage

sib11AndDchNeighboringFddCellAlgo (FDDCell)

•classic•manual

The maximum number of neighboring cells in cell DCH per FDDCell are:

48 UMTS Fdd Cell neighboring with a maximum of:

32 UMTS intra-frequency neighbors (including serving cell)

32 UMTS inter-frequency neighbors

32 GSM neighbors

The maximum number of neighboring cell (per FDD cell) broadcasted in SIB11 is limited to 48 in total whether they are Intra-freq, Inter-freq or GSM neighbours.

The SIB11 neighboring list shall usually be a subset of the Cell_DCH connected mode neighboring list.

The algorithm used to build SIB11 and RRC Measurement Control, for 3G frequency measurements is set by the value of sib11AndDchNeighbouringFddCellAlgo:

classic (or unset): no distinction between SIB11 and DCH neighboring lists

manual: RNC reads sib11OrDchUsage to compute the neighboring lists

automatic: RNC automatically chooses intra-frequency neighboring cells broadcasted in SIB11 (not supported in this release)

manual algorithm is preferred to declare and control correctly the list of neighboring cells, thus allowing to make differentiation between the configuration of SIB11 neighborhood (i.e. while in idle, PCH and Cell_FACH modes) and Cell_DCH connected mode neighborhood.

The differentiation is set through the SIB11OrDchUsage parameter on each UmtsFddNeighbouringCell and GsmNeighbouringCell.

hsiddhar

Sticky Note

Both reselection and HO

hsiddhar

Sticky Note

for reselection only

hsiddhar

Sticky Note

For HO only






3.7 Configuration Class Instantiation

FDDCellpowerPartId 0

RNC

RadioAccessService

DedicatedConf

MeasurementConfClass PowerCtrlConfClass PowerPartConfClass CacConfClassHoConfClassPowerConfClass

FDDCell

Example

0userSpecificInfo

0minSpeechPowerRatio

85callAdmissionRatio

PowerPartConfClass/ 0

Standard

R99 cellsuserLabel

85callAdmissionRatio

PowerPartConfClass/ 0

Configuration classes have several instances where each instance has its own parameter settings. 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

These parameters are designed to identify which instance of the configuration classes the cell is using.

In the example above, we can see that each instance of PowerPartConfClass includes a set of predefined parameters. Each parameter belonging to the PowerPartConfClass object can take a different value under each instance.





4 BTS Configuration





4 BTS Configuration

4.1 BTSCell Identifiers

localCellId = 1000rdnId = 0

rdnId = 2localCellId = 1002

rdnId = 1localCellId = 1001

localCellGroupId = 0priority = 1

rdnid (BTSCell)

localCellId (BTSCell)

The localCellId parameter is used to uniquely identify the set of radio resources required to support a cell.Alcatel-Lucent recommends that the localCellId remains unique within the UTRAN (range: [0, 268 435 455])

The rdnId identifies the BTS cell within the BTSEquipment.

RdnId allocation:

rdnId = 0 is allocated to the upper north sector

consecutive rdnId are allocated clockwise.





4 BTS Configuration

4.2 Local Cell Groups

localCellgroupId = 1localCellid = 1011

localCellgroupId = 1

localCellid = 1012


localCellid = 1013


localCellid = 1003


localCellid = 1002


localCellid = 1001localCellGroupId (BTSCell)

frequencyBand (BTSEquipment)

testFrequency (BTSEquipment)

F1

F1

F1

F2 F2

F2

STSR-2-6-3

Within a BTSEquipment, a Local Cell Group (LCG) is the set of BTSCells for which Softer HO is possible.

All BTSCells belonging to the same LCG have the same localCellGroupId

In UA5 there can be up to 3 BTSCells in a LCG whereas a maximum of 12 cells per BTS Equipment can be defined.

frequencyBand indicates the frequency band list supported that can be:

umtsBand, umts1900Band, umts1800Band, umts2100-1700Band, umts850Band, umts800Band, umts2600Band, umts900Band, umts1700Band

testFrequency parameter corresponds to the UARFCN (UTRA Absolute Radio Frequency Channel Number of the Down Link Frequency used by the BTS to detect its RF cabling.

The above drawing shows an example of identifier distribution and frequency carrier plans, identified by localCellId and localCellGroupId parameters.





4 BTS Configuration

4.3 Sectors and Clusters: 6 sectors Softer Handover

Sect

orBe

ta

SectorGamma

Sector

Alpha

Sect

orEp

silo

n

SectorDelta

Sector

Dzeta

BTS

Sect

or1

2 FD

Dcel

ls

RemoteSite

Sector 2

2 FDDcells

Sector 32 FDDcells

Sect

orDe

lta2

FDDc

ells

RRH

Sector

Epsilon

2 FDDcells

RRH

SectorDzeta

2 FDDcells

RRH

Sect

or1

2 FD

Dcel

ls

Sect

orAl

pha

2 FD

Dcel

ls

Sector 32 FDDcells

SectorGamma

2 FDDcells

Sector 2

2 FDDcellsSector

Beta

2 FDDcells

BTSlocal site

Cluster #1

Cluster #2

Sect

or1

2 FD

Dcel

ls

RemoteSite

Sector 2

2 FDDcells

Sector 32 FDDcells

Sect

orDe

lta2

FDDc

ells

RRH

Sector

Epsilon

2 FDDcells

RRH

SectorDzeta

2 FDDcells

RRH

Sect

or1

2 FD

Dcel

ls

Sect

orAl

pha

2 FD

Dcel

ls

Sector 32 FDDcells

SectorGamma

2 FDDcells

Sector 2

2 FDDcellsSector

Beta

2 FDDcells

BTSlocal site

Cluster #1

Cluster #2

6 local sectorsin 2 clusters

3 local sectors + 3 remote sectorsin 2 clustersCluster #1

Cluster #2

Softer HO

Softer HO

maxNumberSectorsSofterHo

(BTSEquipment)

Softer HO

max6Sectors

max3Sectors

Soft HO

Softer HOSoft HO

Definition of cluster :

A cluster is the group of sectors (or antenna connections) for which Softer HO is

available.

A cluster can be made of 1 to 3 sectors with 1 to 2 carriers. This gives 1 to 6 cells per cluster.

The NodeB can manage up to 2 clusters.

A cluster can not mix local and remote cells.

For local clusters, the 1st cluster is managed by 1 or 2 dedicated TRM and the 2nd cluster is managed by 1 other dedicated TRM.

The parameter maxNumberSectorsSofterHo indicates if the BTS shall manage softer HO on 3 or 6 sectors:

If max3Sectors, the BTS will manage softer HO on 3 cells max (cells referred by 1 LCG)

If max6Sectors, the BTS will manage softer HO on 6 cells max, (the 6 cells of the 2 LCG referring the sameRF CARRIER)

Softer Handover is allowed under the maximum number of branch (= 3). However these 3 Radio Links can belong to any sectors of any clusters.

If the RNC sends a RL ADDITION for a 4th RL, the BTS rejects the procedure and sends a RL ADDITION FAILURE with the cause (TNL - Combining Resource Not available).





4 BTS Configuration

4.4 Frequency Groups and TRM Defense Mechanism

localCellGroupId 0

frequencyGroupId (localCellGroup) 0

priority (localCellGroup) 1

localCellGroupId 1

frequencyGroupId (localCellGroup) 0

priority (localCellGroup) 2

F1

STSR 2-6-3

TRM-1

Highest priority

F1

F1

F2

F2

F2

TRM-2

localCellGroupId 1

localCellGroupId 1

localCellGroupId 1

localCellGroupId 0

localCellGroupId 0

localCellGroupId 0

Each BTSCell is linked to a frequency group (frequencyGroupId) depending of the LCGs defined in the BTSEquipment and the PA shared or not by different LCGs.

The following rules apply:

If 2 LCG of a same cluster share the same PA (STSR2 or RRH2), they must have the same frequencyGroupId

If 2 LCG of a same cluster have different MCPA (STSR1+1), they must have different frequencyGroupId

frequencyGroupId = 0 is related to PA 1, 3, 5 that are connected to MAIN antenna of BTS

frequencyGroupId = 1 is related to PA 2, 4, 6 that are connected to DIV antenna of BTS

Local Cell Groups belonging to different clusters can have the same or different frequencyGroupId.

Finally one priority level is given to each localCellGroup.

If Loss of TRM1 when priority (F1) > priority (F2):

All BTScells (of both frequencies) are lost and then BTScells for frequency F1 are reconfigured.

If Loss of TRM1 when priority (F1) = priority (F2):

All BTScells (of both frequencies) are lost and then BTScells for frequency F2 are reconfigured.





4 BTS Configuration

4.5 STSR 3 configuration

CCM (0)

xTRM

Network Interface

xTRMi or xCCM

GPSAM

RX f3

Tx f1 f2 f3

sector ‘alpha’

sector ‘beta’

sector ‘gamma

’

RX f1 f2

Tx f1 f2 f3

PA

PA

PA

D

D

D

D

D

D

i or xCEM

i or xCEM

F3F1 F2

adjacent frequencies

i or xCEM

2110 MHz 2170 MHz

5 MHz

or 3 RRHs frequencyGroupId=0

STSR3 is a 3 sectors, 3 carriers configuration; for each sector, the 3 carriers are shared on the same MCPA (local cells)or RRH (remote cells).

F1, F2, F3 must be adjacent





4 BTS Configuration

4.6 STSR 2+X configuration introduction

CCM (0)

xTRM

Network Interface

xTRMi or xCCM

GPSAM

RX f3 f4

Tx f1 f2

sector ‘alpha’

sector ‘beta’

sector ‘gamma

’

RX f1 f2

Tx f3 f4 PA

PA

PA

PA

PA

PA

D

D

D

D

D

D

i or xCEM

i or xCEM

F3 F4 F1 F2

Carriers allocation

i or xCEMLocalCellGroupId= 2

frequencyGroupId=1

LocalCellGroupId=1

frequencyGroupId=0

Pair of adjacent frequencies

STSR2+2 configuration uses one MCPA per sector and one xTRM for F1+F2 (frequency pair 1), and one MCPA per sector and a second xTRM for F3+F4 (frequency pair 2): one MCPA/xTRM chain (frequency pair 1) is connected to Main path and the second MCPA/xTRM chain (frequency pair 2) is connected to Diversity path, thus STSR2+2 uses 6 MCPAs per cabinet. Sub-configuration such as STSR2+1 or STSR1+2 are also supported.F1 and F2 ( resp. F3 and F4 ) must be adjacent.All the frequencies must be in the same band ( 2110-2170 MHz band for UMTS2100 or 1930-1990 MHz band for UMTS1900 ), but carriers ( F2 and F3 ) may be spaced by 4.6MHz minimum or by up to 45MHz maximum.This feature in not intended to provide dual-band configuration capability.

#

12345

STSR1+2 STSR2+1 MP STSR2+1 HP STSR2+2 MP STSR2+2 HP STSR2+2 mixed

12010-1 P1 P2 P2 No No No12020-1 P1 P2 P2 No No No12010-2 P1 P2 P1 P3 P1 P312020-2 P1 P2 P1 P3 P1 P3

78

1011

Description of Restriction/Limitation/ClarificationThis feature is only supported by xTRM for STSR2+2 configuration ( but iTRM+xTRM supported for STSR1+2 )Two carriers on the same MCPA/xTRM chain must be adjacentAssuming F1<F2<F3<F4, F2 and F3 must be separated by at least 4,6 MHzAssuming F1<F2<F3<F4, F2 and F3 spacing must be less than 45 MHzTX diversity cannot be supported in STSR2+2 or STSR2+1

6

STSR2+2/STSR1+2/STSR2+1 configurations are supported on UMTS BTS 120x0 as following

9

This feature leads to NodeB resources “fragmentation”: it requires also to equip the BTS with a minimum of

• 2 iCEM modules, one CEM per per 3 sectorsx2carriers• 2 H-BBU, one H-BBU per 3 sectorsx1carrier• 2 e-BBU, one e-BBU per 3 sectorsx1 carrier

Configuration is supported by iCCM/iCCM-2 onlyThis feature has impacts on CEM pooling, as full CEM pooling is no more possible in 3 or 4 carriers

STSR2+2/STSR1+2/STSR2+1 configurations are limited to 3 sectors maximum ( 12 cells maximum )STSR2+2 BTS cannot support RRH ( 12 cells maximum )





4 BTS Configuration

4.6.1 STSR 2+x configurations Dual-Band NodeB

sector ‘beta’xTRM

sector ‘alpha’

sector ‘gamma’

MCPA

6 RX

3 TX

D

D

D

D

MCPAD

D

D

D

MCPAD

D

D

D

xTRM

sector ‘alpha’

sector ‘gamma’

MCPA

6 RX

3 TX

D

D

MCPAD

D

MCPAD

D

sector ‘beta’

xTRM

sector ‘alpha’

sector ‘gamma’

SCPA

6 RX

3 TX

D

D

SCPAD

D

SCPAD

D

sector ‘beta’

2100MHz

xTRM

sector ‘alpha’

sector ‘gamma’

MCPA

6 RX

3 TX

D

D

MCPAD

D

MCPAD

D

sector ‘beta’

xTRM

sector ‘alpha’

sector ‘gamma’

SCPA

6 RX

3 TX

D

D

D

D

SCPAD

D

D

D

SCPAD

D

D

D

sector ‘beta’

i or xCEM

i or xCEM

i or xCEM

i or xCCM

900MHz

FrequencyBand =

1: Band01-2100

2: Band02-1900

3: Band03-1800

4: Band04-2100-1700

5: Band05-850

6: Band06-800

7: Band07-2600

8: Band08-900

9: Band09-1700

This feature allows supporting dual-band 2100/900 MHz configurations on Macro Node B. It increases the Node B radio capacity by improving outdoor coverage and/or indoor penetration, as it allows to combine into a single Node B cabinet two band-specific HW and then to get dual-band site with minimized foot-print.It also makes possible to smoothly upgrade a 2100MHz site to dual-band 2100/900.This is like an extension of the 6 sectors (3+3) feature, where each cluster of up to 3 sectors is associated to a frequency band. The following configurations are supported:· up to 3 local sectors 2100 + up to 3 local sectors 900· up to 3 local sectors 900 + up to 3 remote sector 2100 on RRH· up to 3 local sectors 1900 + up to 3 local sectors 850Each frequency band supports the features and restrictions as if it were in a mono-band NodeB.Configuration Example1: STSR2/2100 – STSR1/900 Configuration Example2: STSR1+1/900 – RRH222/2100

With A and B in range {0, 1}

BTS CELL

Antenna Connection

LocalCell GroupId

Frequency GroupId

RFCarrier FreqBand

1 1 Band012 2 Band013 3 Band014 4 Band085 5 Band086 6 Band087 1 Band018 2 Band019 3 Band012 A

0 A

1 B

BTS CELL

Antenna Connection

LocalCell GroupId

Frequency GroupId

RFCarrier FreqBand

1 1 Band082 2 Band083 3 Band084 11 Band015 21 Band016 31 Band017 1 Band088 2 Band089 3 Band08

10 11 Band0111 21 Band0112 31 Band01

0 A

1 B

2 (A+1) modulo 2

3 B





4 BTS Configuration

4.7 Antenna Access

Masthead equipment

TMA

TMA

TMA

BTS RF cables(2 per sector)

DD

M1

AntennaAccess localCellGroupBTSCell

BTSEquipment

antennaConnectionList

localCellGroupId

antennaConnection

tmaAccessType

DD

M2

DD

M3

antennaConnection Identifies the physical antenna connection on the DDM of the BTS, One antenna connection is related to a main and a diversity antenna.

antennaConnectionList parameter gathers the identifiers of all the AntennaAccess objects used within a same BTSCell.

In OTSR: 1 AntennaAccess

In STSR with 3 sectors: 3 AntennaAccess

Tower Mounted Amplifier (TMA)

parameter tmaAccessType can take three different values, noTma, tmaUmtsOnly or tmaMix.

In the case where tmaUmtsOnly (non AISG TMA) or tmamix (AISG TMA) is selected, the Access OAM will indicate this information to the TRM and DDM for LNA adjustment.

The impact on the DDM is a LNA gain of:

24.5 dB, if noTma is selected

15.5 dB adjustment gain, if tmaUmtsOnly is selected





4 BTS Configuration

4.8 Six RRH per NodeB

This feature makes possible to support up to six 9341 RRH from one digital Node B (9326 d2U).

The supported configurations are up to 6 sectors (including 4 and 5 sectors), up to 2 carriers.

For a 3+3 sectors configuration, it is possible to have different carriers between the 2 clusters

(e.g. F1 & F2 for first 3 sectors, F2 & F3 for the last 3 sectors).

Mobility between sectors is realized using Soft (2 clusters of 3 sectors) or Softer Hand-Over

mechanisms.

Each fiber link drives only one 9341 RRH, so that one digital Node B can manage up to 6 fibers

and up to 6 RRHs.

FEATURE BENEFITS

Operator is able to deploy 2 tri-sectors RRH sites from one single digital Node B site, bringing

TCO reduction in dense areas: for instance, with only one Node B site, operator is able to

deploy outdoor coverage and simultaneously hot-spot or indoor coverage.

This feature is also an enabler for future dual-band or STSRx+y distributed configurations.

Supported configurations are:

STSR1+1 (or depopulated two or one sector configurations)STSR2+1 (or depopulated two or one sector configurations)

STSR2+2 (or depopulated two or one sector configurations) 6 sectors ( or depopulated 5 or 4 sectors configurations) one carrier 6 sectors ( or depopulated 5 or 4 sectors configurations) two carrier





4 BTS Configuration

4.8.1 Six RRH per NodeB: Dual-band Distributed Node B

Sect

orAl

pha

RRH

Sector

Beta

RRH

SectorGamma

RRHDigital

Node B

1900 MHzsite

Sect

orDe

lta

RRH

Sector

Dzeta

RRH

SectorEpsilon

RRH

6 fibers

850 MHzsite

Digital Node B: d2u v2

RRH: RRH40W

Up to U222-222 @20W/car

Up to U222 (20W/car) + U111 (40W/car)





4 BTS Configuration

4.9 Rake Receiver

TXD(t)

Delay τ0

Delay τ1

C(t-τ0)

+C(t-τ1)

Delay (τ1)

RX

C(t-τn)

Delay (τ0)

Delay (τn)RX

RX

C(t)

τ0

τ1

τn

Spreading &Scrambling

8 fingers

cellSize (BTSCell) •from0to5•from5to10•from10to30

On the BTS side (uplink), the number of fingers handled by the Rake receiver is fixed and equal to 8 fingers.

The number of fingers should be high enough to handle all multipaths (otherwise contributing to the noise) but the more fingers the Rake receiver must track, the more resources are consumed on the CEM. 8 fingers is good compromise.

The search window size conditions the maximum time allowed for a message to be transmitted from the Node B to UE and return. The parameter cellSize is used to give a rough approximation of the search window size for the initial access to the Node B on the new RL established for a Soft Handover.

The larger the cell, the larger the window shall be to get a chance to receive the mobile transmissions (main path and multipaths at the Rake receiver). The cell size should be estimated according to the cell planning (pilot coverage). If some doubt arises, the larger value should be chosen.

Actually, if the value is too low, the Node B may not detect the mobile on the new RL, the SHO may fail and a call drop can occur.

However, if the value is too high, the Node-B could detect the mobile on a radio path that might not be the best (multi-path, interference…) and this could also lead to SHO problems and then a call drop afterwards.





4 BTS Configuration

4.9.1 Searcher Window Usage during First RLS: iCEM case

Propagation Delay estimation from an initial position of the searcher determined by NodeB

Once synchronized, the searcher goes into normal mode with 192 chips window

Extended searcher is initializedbased on Maximum Cell Range (60km) for iCEM

There are two methods of synchronisation between NodeB and UE: synchronisation on RACH and SHO. For the first case, the NodeB is capable of determine the propagation delay for RACH message detection and for the second case there’s no synchronisation procedure and the NodeB will use different cellSize windowsin order to detect the UE signal for SHO.

L1 Synchronisation on RACH - iCEM behaviourThe NodeB is capable of determine the propagation delay and synchronisation with the UE in order to detect the RACH messages. Since the BTS doesn’t know where the mobile is in a precise moment, all the maximum cell range will be scanned (60km) whatever the cellSize parameter value.





4 BTS Configuration

4.9.2 Searcher Window Usage during First RLS: xCEM case

Propagation Delay estimation from an initial position of the searcher determined by NodeB

Once synchronized, the searcher goes into normal modewith 192 chips window

Extended searcher is initializedbased on 5+cellSize parameter value for xCEM

cellSize (BTSCell) •From0to5•from5to10•from10to30

searcher window = 256 chipssearcher window = 384 chipssearcher window = 1024 chips

Standard mode

L1 Synchronisation on RACH - xCEM behaviourThe xCEM uses a more intelligent procedure for synchronisation based on the approximated size of the cellule (cellSize parameter value). So it will search the RACH messages in a range equal to (5 + cellSize) km.

Note 1: The 5km is a minimum value for the cell range.

Note 2: For the cases where OR, RRH or Extended Cabinets are used it is also necessary to add into the current formula 1.5xfiber length.

For example and for the case of an OR utilisation we have to add the parameter repeaterFiberLenght value, that is used to configure the path searcher window size.

This parameter can have the following values: 0, 1, 2 and 3 corresponding respectively

to 92Tchips (no fiber), 284 Tchips (4 km), 400 Tchips (7 km) and 3 = 512 Tchips (10 km).

It’s necessary to be aware that in cases of mixed board types the behaviour is different. It will bedependent on the type of card that supports the D-BBUs which are managing the common channels. If bothiCEM and xCEM support D-BBU, the Node B allocates the common channels dynamically on both cards, but there is no way to force it on one or the other (if the xCEM supports only H-BBU and E-BBU, the RACH behaviour would be the one of iCEM, independently of the cellSize parameter).





4 BTS Configuration

4.9.3 Searcher Window Usage during non-First RLS

No delay estimation (since no synchro between BTS), an initial position of the searcher is determined by NodeB

Once synchronized, the searcher goes into normal modewith 192 chips window

Extended searcher is initializedbased on cellSize parameter value

cellSize (BTSCell) •From0to5•from5to10•from10to30

searcher window = 256 chipssearcher window = 384 chipssearcher window = 1024 chips

Standard mode

L1 Synchronisation on SHOContrarily to the previous case, no delay estimation is executed during the SHO procedure(for the NodeB where the RL will be added).Depending on cellSize value, the nodeB will use different Search Window size to detectmobile signal:� cellSize = from0to5 (Km)⌠ searcher window = 256 chips� cellSize = from5to10 (Km)⌠ searcher window = 384 chips� cellSize = from10to30 (Km)⌠ searcher window = 1024 chips….Once RL detected, the Search Window is reduced to a normal 192 chips value.

A correct setting of the cellSize parameter will allow:• Faster RL detection• Better NodeB resource usage (the larger is the searcher window, the more time willbe needed for RL detection, the more processing will be required)• Better performances (SHO performance)

If cellSize parameter is not used correctly we may encounter some issues for the following cases:Bigger cellSize than normal cell size

Risk of synchronization on wrong signal (interference, multi path, etc)The larger is the window, the more noise is analyzed, and the higher is the probability to have a wrong synchronization (peaks of UL RSSI

Lower cellSize than a normal cell sizeAt SHO establishment, the searcher may not find the UE signal, Risk of SHO failure, and call drop probabilityReduces the accessibility for the xCEM case, as RACH preambles from far UEs will not be properly decoded by the NodeB

Because of the above reasons, it’s important to use correctly the cellSize parameter (e.g. tuned according to RF design information).





4 BTS Configuration

4.10 Ultra extended cell mode – configuration aspects

30 km60 km60 km

Activation and Deactivation through cellSize (BTSCell) setting:

Standard mode (default configuration): 0 .. 30 km

Extended mode: 30.1 .. 90 km

Ultra-extended mode: 90.1 … 150 km

xCEM Only

No Impact on xCEM capacity

0:0-5km, 1:5-10 km, 2:10-30km,

cellSize

3:30-60km, 4: 60-75km, 5:75-90 km

6:90-120 km, 7:120-150 km

BTSCell

•from30to60•from60to75•from75to90•from90to120•from120to150

Ultra-extended cells are cells with a maximum radius of 150km. This feature is only supported on the xCEM. The iCEM and αCEM do not support any extended cell size; i.e. the maximum radius here is 30km.

In order to ensure that the extended and ultra-extended cell-sizes are supported with the best achievable performance, it is necessary to configure the Channel Elements with the cell size in multiple of the search window size. The search window size of the OneChip Channel Element is equal to 7.5km.

CellSize = 0:0-5km, 1:5-10 km (default value), 2:10-30km, 3:30-60km, 4: 60-75km, 5:75-90 km,

6:90-120 km, 7:120-150 km

Depending on the cell configuration, the Channel Elements on the xCEM shall support at least the following number of RACH sub-channels:

12 in extended cell configuration with cell sizes up to 90 km

4 in ultra-extended cell configuration with cell sizes between 90 km and 150 km. This is not a limitation of the CE and there is no requirement to limit the number of RACH sub-channels to 4 if this is not necessary.

As the RACH preamble detector in the xCEM covers a maximum window of 80km, a second detector is required for cell sizes beyond 75km. Thus an xCEM supports a maximum of 3 large cells plus 3 small cells.





4 BTS Configuration

4.11 NodeB capacity licensing

License keys management

R’99 CE capacity

HSDPA capacity

EDCH capacity

OMC

Node B

Node B

Node B

NodeBs capacity controlled via licensing capacity parameters

Node BPer OMC capacity licenses

Node B

i or xCEMxTRMxTRMxTRM

Activation of second carrier

MCPA

PA Power

RRH

RRH power Number of carriers

License keys server

capacity dispatched to the BTS

Spare capacity

Remaining H/W Capacity

S/W allowed Capacity

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

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

The following NodeB capacity aspects are managed in UA06 via this feature: CEM R99 capacity,CEM HSDPA capacity, CEM HSUPA capacity, xTRM capacity, RRH capacity, PA power & RRH power

Additional capacity licence 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: Customer can purchase independently HW and capacities (note that the following table is provided as an example and not as an ALU commitment on the list of purchaseable items or “packs”):

xCEMiCEM64 H/W

iCEM128 H/W

xCEM H/W

+ minimum capacity

+ minimum capacity

+ minimum capacity

R99 capacHSDPA caHSUPA cas of (8 HSUPA connections + 480

iCEM

CEM H/WBlocks of 16CE

s of (8 HSDPA connections + 1.8

iTRM xTRMTRM HW iTRM xTRM (one carrier)

xTRM_CarN/A#of second xTRM carrier activation/NodeB (step:1)

All RRH typesRRH H/W RRH (one carrier) + reduced power

RRH_Carr#of additional RRH carrier activation/NodeB (step:1)

RRH_pow Blocks of 10W at RRH ouput

All PA types

Power (W) Blocks of 15W at PA outputPA H/W PA + reduced power





4 BTS Configuration

4.11.1 Parameters involved in capacity limitation

BTSEquipment

rdnId

edchMaxNumberUserEbbu

hsdpaMaxNumberUserHbbu

hsdpaMaxThroughputHbbu

edchMaxNumberUserXcem

hsdpaMaxNumberUserXcem

hsdpaMaxThroughputXcem

edchMaxThroughputXcem

r99MaxNumberCeXcem

Per BBU of iCEM UA06 parameters

Per xCEM UA06 parameters

Unique value for all iCEM

Unique value for all xCEM

Per BTS Parameter:

• Step : 16 CE

• Limit the number of R99 CE available on the whole BBU

r99MaxNumberCeXcem:

This parameter is intended to be use to activate the xCEM board DCH capability following a commercial agreement Between ALU and the operator, the default value for the r99MaxNumberCeXcem in UA6.0 is 0, meaning no DCH resources available on xCEM.

The applied value for this parameters will depend on Capacity Licensing activation.

Administrator

Typewritten Text

Somtel is 128

Administrator

Typewritten Text

Administrator

Typewritten Text

Administrator

Typewritten Text

somte is 256

Administrator

Typewritten Text

Administrator

Typewritten Text

Administrator

Typewritten Text





4 BTS Configuration

4.11.2 NodeB capacity licensing:RMD objects and parameters

PaResourceRRH

BtsEquipment

Capacity PaResource BTSHsdpaResource HsXpaResourceRemoteRadioHeader

r99NumberCECapacityLicensing

hSDPANumberUserCapacityLicensing

hSDPAThroughputCapacityLicensing

edchNumberUserCapacityLicensing

edchThroughputCapacityLicensing

xtrmCarrierCapacityLicensing

rrhCarrierCapacityLicensing

paPowerCapacityLicensing

maxPowerAmplification*

maxRrhPowerAmplification

hsdpaMaxThroughputHbbu*

hsdpaMaxThroughputXcem*

edchMaxThroughputXcem*

(*) Moved from their original UA5.x parent objects





4 BTS Configuration

4.11.3 NodeB capacity licensing:Capacity update example

OMC-B

TGE : TEE1 : r99NumberCECapacityLicensing = 32TEE2: ...

r99NumberCECapacityLicensing = 64

r99NumberCECapacityLicensing = 32

REPORT (TGE-ACK)

REPORT_ACK

Treatment TEE 2

NodeB

NodeB Auto reset

Capacity Decrease

Only





Module Summary

This lesson covered the following topics:OAM Shared Objects and associated parameters

RNC configurations and associated parameters

Node B configurations and associated parameters

BTS configurations and associated parameters

















Section 3Services






9300 W-CDMA · UA06 R99 Algorithms DescriptionServices3 · 2

Blank Page



2009-02-2901


Document History





Module Objectives


Describe the mono-RAB user services supported

Describe the multi-RAB user services supported

Describe how to configure either mono-rate or multi-rate AMR service











Table of Contents


1 Radio Bearers 71.1 Signaling Radio Bearers 81.2 Conversational Radio Bearers 91.3 Streaming Radio Bearers 101.4 Interactive/Background Radio Bearers 111.4 Interactive/Background Radio Bearers 12

2 Services 132.1 Mono and Multi-RAB Services - Examples 14

2.1.1 DCH 152.1.2 HSxPA 16

3 Multi-Rate AMR 173.1 AMR NB Configurations 183.2 AMR NB TB Definition 193.3 AMR-WB TB Definition 203.4 UL AMR Codec Mode Adaptation 213.5 Multi-Rate AMR Activation – NB and WB 223.6 Multi-Rate AMR call setup 23












1 Radio Bearers





1 Radio Bearers

1.1 Signaling Radio Bearers

Traffic Class RB name TTI Traffic Class RB name TTI

Signalling (DCH) SRB_3_4K_DCH 40 ms Signalling (DCH) SRB_3_4K_DCH 40 ms

Signalling (DCH) SRB_13_6K_DCH 10 ms Signalling (DCH) SRB_13_6K_DCH 10 ms

Signalling (FACH) SRB_CellFACH N.A. Signalling (FACH) SRB_CellFACH N.A.

Signalling (DCH) SRB_5_AMR 40 ms Signalling (DCH) SRB_5_AMR 40 ms

Signalling (DCH) SRB_EDCH 10 ms

RadioAccessService

RNC

DlRbSetConf UlRbSetConf

SRB_CellFACH is used for

Registration (LA/RA/URA/Cell Update)

Detach

Originating Low Priority Signaling (Originating SMS)

Terminating Low Priority Signaling (Terminating SMS)

SRB_3_4K_DCH is used for

Emergency call

SRB_13_6K_DCH is used for any other causes before Traffic RB(s) is (are) setup

Originating/Terminating conversational call

Originating/Terminating streaming call

Originating/Terminating interactive call

Originating/Terminating background call

Call re-establishment

Inter-RAT cell reselection

Inter-RAT cell change order

Originating/Terminating High Priority Signaling

Terminating cause unknown

SRB__EDCH is used for

HSUPA Category 6 UE using a minimum 2xSF2+2xSF4 configuration and if 2ms TTI is used

hsiddhar

Sticky Note

RRC

hsiddhar

Sticky Note

RAB assignment





1 Radio Bearers

1.2 Conversational Radio Bearers


Conversational (Speech) CS_AMR_LR 20 ms Conversational (Speech) CS_AMR_LR 20 ms

Conversational (Speech) CS_AMR_NB 20 ms Conversational (Speech) CS_AMR_NB 20 ms

Conversational (Speech) CS_AMR_WB 20 ms Conversational (Speech) CS_AMR_WB 20 ms

Conversational (CSD) CS_14_4K 40 ms Conversational (CSD) CS_14_4K 40 ms

Conversational (CSD) CS_57_6K 40 ms Conversational (CSD) CS_57_6K 40 ms

Conversational (VT) CS_64K 20 ms Conversational (VT) CS_64K 20 ms

DownLink Radio Bearers UpLink Radio Bearers

RadioAccessService

RNC


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

CS_AMR_NB stands for AMR Narrow Band RB for which AMR NB voice codecs used allows a DL SF of 128 if AMR RAB is not multiplexed with another RAB

CS_AMR_LR stands for AMR Low Rate RB for which AMR LB voice codecs used allow a DL SF of 256 if AMR RAB is not multiplexed with another RAB

CS_14_4K RB corresponds to the CS data service also provided in GSM networks

CS_57_6K RB corresponds to the CS data service also provided in HSCSD GSM networks

CS_64K RB corresponds to the Video Call service not available in GSM networks

CSD= Conversational Data Service

VT=Video Transmission





1 Radio Bearers

1.3 Streaming Radio Bearers

RadioAccessService

RNC



Streaming PS_16K_STR 40 ms Streaming PS_16K_STR 20 ms




Streaming PS_384K_STR 10 ms

Streaming PS_HSDSCH_STR 2ms

DownLink Radio Bearers UpLink Radio Bearers

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

Administrator

Typewritten Text





1 Radio Bearers

1.4 Interactive/Background Radio Bearers

Traffic Class RdnId RB name TTI Traffic Class RdnId RB name TTI

Interactive/Background 34 PS_0K_IB N.A. Interactive/Background 30 PS_0K_IB N.A.

Interactive/Background 35 PS_0K_IB_MUX N.A. Interactive/Background 31 PS_0K_IB_MUX N.A.

Interactive/Background 38 PS_0K_IB_MUX3 N.A. Interactive/Background 38 PS_0K_IB_MUX3 N.A.

Interactive/Background 4 PS_8K_IB 40 ms Interactive/Background 7 PS_8K_IB 40 ms

Interactive/Background 37 PS_8K_IB_MUX 40 ms Interactive/Background 37 PS_8K_IB_MUX 40 ms

Interactive/Background 29 PS_16K_IB 40 ms Interactive/Background 39 PS_8K_IB_MUX3 40 ms




Interactive/Background 39 PS_64K_IB_MUX3 20 ms Interactive/Background 40 PS_32K_IB_MUX3 40 ms



Interactive/Background 40 PS_128K_IB_MUX3 20 ms Interactive/Background 41 PS_64K_IB_MUX3 20 ms

Interactive/Background 10 PS_256K_IB 10 ms


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

In this version, “Multiple PS RAB” is limited to 2 PS RAB only.

3 PS RAB multiple configuration (MUX3) is available for USA Market only

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

A user is activating a primary and a secondary PDP context in order to open bearers with different quality of service towards a given APN (Access Point Name)

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

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

Example:

DPCH SF32

DCH DL 64 SF32

DL 64 DL 64

PDP 1 RAB 1

PDP 2 RAB 2

DL 3,4

DCCH

DCH DL 3,4





1 Radio Bearers

1.4 Interactive/Background Radio Bearers

Traffic Class RdnId RB name TTI Traffic Class RdnId RB name TTI



Interactive/Background 17 PS_HSDCH_IB 2 ms Interactive/Background 42 PS_128K_IB_MUX3 20 ms

Interactive/Background 20 PS_HSDCH_IB_MUX 2 ms Interactive/Background 15 PS_384K_IB 10 ms

Interactive/Background 41 PS_HSDCH_IB_MUX3 2 ms Interactive/Background 37 PS_384K_IB_MUX 10 ms

Interactive/Background 13 TRB_CellFACH N.A. Interactive/Background 43 PS_384K_IB_MUX3 10 ms

Interactive/Background 30 TRB_CellFACH_MUX N.A. Interactive/Background 20 PS_EDCH 10 or 2 ms

Interactive/Background 11 TRB_CellFACH N.A.

Interactive/Background 26 TRB_CellFACH_MUX N.A.






2 Services





2 Services

2.1 Mono and Multi-RAB Services - Examples

User Service SF User ServiceCS_64KxPS_0K_IB_MUXxSRB_3_4K 32 CS_64KxPS_0K_IB_MUXxSRB_3_4K

CS_64KxPS_0K_IBxSRB_3_4K 32 CS_64KxPS_0K_IBxSRB_3_4KCS_64KxPS_16K_IBxSRB_3_4K 16 CS_64KxPS_16K_IBxSRB_3_4K

CS_64KxPS_64K_IB_MUXxSRB_3_4K 16 CS_64KxPS_64K_IB_MUXxSRB_3_4KCS_64KxPS_128K_IB_MUXxSRB_3_4K 8 CS_64KxPS_128K_IB_MUXxSRB_3_4K

CS_AMR_NBxPS_0K_IB_MUXxSRB_3_4K 128 CS_AMR_NBxPS_0K_IB_MUXxSRB_3_4KCS_AMR_NBxPS_0K_IBxSRB_3_4K 128 CS_AMR_NBxPS_0K_IBxSRB_3_4K

CS_AMR_NBxPS_16K_IBxSRB_3_4K 64 CS_AMR_NBxPS_8K_IB_MUXxSRB_3_4KCS_AMR_NBxPS_16K_STRxPS_8K_IB_MUXxSRB_3_4K 64 CS_AMR_NBxPS_16K_IBxSRB_3_4KCS_AMR_NBxPS_64K_STRxPS_8K_IB_MUXxSRB_3_4K 32 CS_AMR_NBxPS_16K_STRxPS_16K_IBxSRB_3_4KCS_AMR_NBxPS_128K_STRxPS_8K_IB_MUXxSRB_3_4K 16 CS_AMR_NBxPS_16K_STRxPS_32K_IBxSRB_3_4K

CS_AMR_NBxPS_384K_STRxPS_8K_IBxSRB_3_4K 4 CS_AMR_NBxPS_16K_STRxPS_64K_IBxSRB_3_4KCS_AMR_NBxPS_384K_STRxPS_HSDSCHxSRB_3_4K 4 CS_AMR_NBxPS_16K_STRxPS_128K_IBxSRB_3_4K

CS_AMR_NBxPS_384K_STRxSRB_3_4K 4 CS_AMR_NBxPS_16K_STRxPS_384K_IBxSRB_3_4KCS_AMR_WBxPS_0K_IB_MUXxSRB_3_4K 128 CS_AMR_NBxPS_32K_IB_MUXxSRB_3_4K

CS_AMR_WBxPS_0K_IBxSRB_3_4K 128 CS_AMR_NBxPS_32K_STRxPS_16K_IBxSRB_3_4KCS_AMR_WBxPS_16K_IBxSRB_3_4K 32 CS_AMR_NBxPS_32K_STRxPS_32K_IBxSRB_3_4K

CS_AMR_WBxPS_384K_STRxPS_8K_IBxSRB_3_4K 8 CS_AMR_NBxPS_32K_STRxPS_64K_IBxSRB_3_4KCS_AMR_WBxPS_384K_STRxPS_HSDSCHxSRB_3_4K 8 CS_AMR_NBxPS_32K_STRxPS_128K_IBxSRB_3_4K

CS_AMR_WBxPS_384K_STRxSRB_3_4K 8 CS_AMR_NBxPS_32K_STRxPS_384K_IBxSRB_3_4KPS_0K_IB_MUXxSRB_3_4K N.A. CS_AMR_NBxPS_64K_STRxPS_8K_IBxSRB_3_4K

PS_0K_IBxSRB_3_4K N.A. CS_AMR_NBxPS_64K_STRxPS_16K_IBxSRB_3_4KPS_16K_IBxSRB_3_4K 128 CS_AMR_NBxPS_64K_STRxPS_32K_IBxSRB_3_4K

PS_16K_STRxPS_0K_IBxSRB_3_4K 64 CS_AMR_NBxPS_64K_STRxPS_64K_IBxSRB_3_4KPS_16K_STRxPS_8K_IB_MUXxSRB_3_4K 64 CS_AMR_NBxPS_64K_STRxPS_64K_IBxSRB_3_4K

PS_64K_STRxPS_0K_IBxSRB_3_4K 32 CS_AMR_NBxPS_64K_STRxPS_EDCHxSRB_3_4KPS_64K_STRxPS_8K_IB_MUXxSRB_3_4K 32 CS_AMR_NBxPS_64K_STRxSRB_3_4K

PS_128K_STRxPS_0K_IBxSRB_3_4K 16 CS_AMR_NBxPS_128K_STRxPS_16K_IBxSRB_3_4KPS_128K_STRxPS_8K_IB_MUXxSRB_3_4K 16 CS_AMR_NBxPS_128K_STRxPS_32K_IBxSRB_3_4K

PS_384K_STRxPS_8K_IBxSRB_3_4K 8 CS_AMR_NBxPS_128K_STRxPS_64K_IBxSRB_3_4K

New DownLink User Services New UpLink User Services

DluserService UluserService





2.1 Mono and Multi-RAB Services

2.1.1 DCH

DCHStand-alone

CS Conversational speech: AMR_LR, AMR_NB, AMR_WB CS Conversational VT: 64/64CS Streaming: 14.4/14.4, 57.6/57.6 PS Streaming DL: 16,32,64,128 UL: 16,64,128,256,384 PS I/B DL: 8,16,32,64,128,256,384 UL: 8,16,32,64,128,384

CombinationCS Conv. Speech + PS I/B DL: 0,8,16,32,64,128,384 UL: 0,8,16,32,64,128,384 CS Conv. VT + PS I/B DL: 0,8,16,32,64,128 UL: 0,8,16,32,64,128,384 (CS Conv. Speech +) PS I/B MUX DL: 0,64,128,384 UL: 0,64,128 CS Conv. VT + PS I/B MUX DL: 0,64 UL: 0,64,128(CS Conv. Speech +) (PS I/B +) PS Streaming:

PS Streaming DL: 16,64,128,256,384 UL: 16,32,64,128PS I/B DL: 8 UL: 8,16,64,128,256,384

hsiddhar

Sticky Note

UL. written wrong





2.1 Mono and Multi-RAB Services

2.1.2 HSxPA

HSxPAStand-alone

PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384PS I/B HSDPA/HSUPA DL: f(HSD UE category) UL: f(HSU UE category, TTI)PS Streaming HSDPA/DCH DL: (HSD UE category, GBR) UL: 16,32,64,128

CombinationCS Conv. Speech + PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384

CS Conv. VT + PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384

(CS Conv. Speech +) PS I/B MUX HSDPA/DCH DL: f(HSD UE category) UL: 64,128 CS Conv. Speech + PS Str. HSDPA/DCH DL: (HSD UE category, GBR) UL: 16,32,64,128(CS Conv. Speech +) (PS I/B HSDPA/DCH+) PS Streaming (HSDPA or DCH/DCH) :

PS Streaming DL: 16,64,128,256,384 or f(HSD UE category, GBR) UL: 16,32,64,128PS I/B HSDPA/DCH DL: f(HSD UE category) UL: 8,16,32,64,128,384

CS Conv. Speech + PS I/B HSD/HSU DL: f(HSD UE category) UL: f(HSU UE category, TTI)

CS Conv. VT + PS I/B HSDPA/HSUPA DL: f(HSD UE category) UL: f(HSU UE category, TTI)

(CS Conv. Speech +) (PS I/B HSDPA/HSUPA+) PS Streaming (HSDPA or DCH/DCH) :PS Streaming DL: 16,64,128,256,384 or f(HSD UE category, GBR) UL: 16,32,64PS I/B HSDPA/HSUPA DL: f(HSD UE category) UL: f(HSU UE category, TTI)





3 Multi-Rate AMR





3 Multi-Rate AMR

3.1 AMR NB Configurations

2 kinds of AMR Radio Bearers CS_AMR_LR : CS AMR Low RateCS_AMR_NB : CS AMR Narrow Band

Only Configurations A, B and D allow speech and coding rate adaptation

mono-rate AMR Configurations

multi-rate AMR Configurations

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. 10,2 6,7 5,9 4,75

E. 12,2

All these configurations can be used together with I/B PS services but B and C which are intended to be used with Spreading Factor 256 in DL, e.g. in capacity limited networks.

Configuration E is intended for legacy purposes. It is the only one which is compatible with Iu User Plane Frame protocol v1 (see 3GPP TS 25.415). Other configurations required Iu UP FP V2.





3 Multi-Rate AMR

3.2 AMR NB TB Definition

Quality only based on Class A bitsprotected by CRC Input for OLPC (SIR target update)

AMR Mode Number of bits per TTI (20

ms)

Class A

bits

Class B

bits

Class C

bits

12.2k 244 81 103 60

10.2k 204 65 99 40

7.95k 159 75 84 0

7.4k (not

used) 148 61 87 0

6.7k 134 58 76 0

5.9k 118 55 63 0

5.15k (not

used) 103 49 54 0

4.95k 95 42 53 0

On the radio interface, one dedicated transport channel is established per class of bits, i.e. DCH A for Class A bits, DCH B for Class B bits and DCH C for Class C bits. Thus, each class can be subject to a different error protection scheme:

Class A contains the bits most sensitive to errors and any error in these bits would result in a corrupted speech frame which needs error correction for proper decoding. It is the only class protected by a CRC.

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





3 Multi-Rate AMR

3.3 AMR-WB TB Definition

5 AMR-WB Codes for Telephony

The wideband AMR codec consists in 9 sources with bit rates of 23.85k, 23.05, 19.85k, 18.25k, 15.85k, 14.25k, 12.65k, 8.85k and 6.6k. Only 5 modes are used and supported for telephony 23.85k 15.85k 12.65k 8.85k and 6.6k other modes being used for other services (e.g. can be used for MMS).

SUPPORTED AMR WIDE BAND CONFIGURATIONS

In UA5.1 only TS 26.103 AMR-WB configuration #0 (Active Codec Set (ACS) 12.65 8.85 & 6.60) is supported. Spreading factor for downlink and uplink is similar to NB-AMR.

For mono services:

Downlink:128

Uplink: 64

At AMR-WB Call Setup, the Max Bit rate is initialized to the Max bit rate which is 12.65





3 Multi-Rate AMR

3.4 UL AMR Codec Mode Adaptation

TFCS12.27.955.94.75

TFCS12.27.955.94.75

TFCS12.27.955.94.75

12.210.27.957.406.705.905.154.75

AMR mode (kbps)

UEoutputpower

-

+

AMR Rate change

For Multi Mode configurations, i.e. A, B and D, the speech rate can change in UL and DL.

DL rate is set according to the rate of the Iu UP Frames received from the CN.

UL rate can change either on decision of the UE according to its TFCS selection function or on request of the CS CN. This latter case can happen when TFO/TrFO is used in Mobile-to-Mobile calls.

AMR Configuration at call set-up

The AMR configuration is selected according to the CS CN request at call set-up. If the CN supports IuUP FP v1 only Configuration E will be used.

If it supports v2 it must indicate one of the A to D configurations.

AMR code mode adaptations occur in both UL and DL for configurations A, B, D for AMR-NB

and for AMR-WB

In DL, the AMR rate adaptation occurs in TFO/TrFO scenario when distant UE changes its bit rate ( also when RNC changes the max DL bit rate ).

In UL, the UE can select a different AMR rate in case of coverage limit. The UE transmitted is closed to the maximum. In this case, the UE can reduce its AMR rate.





3 Multi-Rate AMR

3.5 Multi-Rate AMR Activation – NB and WB

isAmrMultiModeAllowed (RadioAccessService)isAmrMultiModeSetupAllowed (FDDCell)

NOYESenabledPerCell

YESYEScompletelyEnabled

NONOdisabled

FalseTrueisAmrMultiModeSetupAllowed

isAmrMultiModeAllowed

Multi-rate AMR activated in a cell ?

isAmrWbAllowed (RadioAccessService)





3 Multi-Rate AMR

3.6 Multi-Rate AMR call setup

RRC Connection Request

(Originating conversational call)

RRC Connection Setup

RRC Connection Setup Complete

(AS release indicator)

MSC

CM Service Request

(MO call establishment)

Setup

(Speech, Speech Version 3)

RAB Assignment Request

(UP mode version 2)SRB#2 or SRB#5

Class A bits

Class B bits

Class C bits

RNCisCnInitiatedRateControlAllowed

allowedIuUpVersion(CsCoreNetworkAccess)

isSrb5AllowedminUeRelForSrb5Amr

isMaxDlAmrRateConfiguredAllowedisCsRabModificationForSpeechAllowed

(RadioAccessService)

maxDlAmrRateConfigured(FDDCell)

Iu UP Init

(RFCIs)

The AMR configuration can be specified at call setup through the SRB #5 if present.

The SRB #5 contains the following information:

Signaling RB information to setup

Authorized TFC subset list to be used in UL.

SRB 5 is setup if all of the following conditions are met:

isCnInitiatedRateControlAllowed is “ True”

isSrb5Allowed is “True”

Version 2 of Iu UP is selected

At least two speech modes are selected (silent mode excluded)

The UE indicated 3GPP release (UE radio access capability / Access stratum release indicator) is greater than or equal to the provisioned value of minUeRelForSrb5Amr.

In UA5.0, the initial AMR codec used at call setup is fixed and equal to the maximum rate allowed among the ones of the Multi-mode configuration used.

In UA5.1, the initial AMR codec used at call setup can be chosen by the operator thanks to the two parameters below.

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

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

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

Currently the SRB#5 is not used since not all UEs support it.





Module Summary

This lesson covered the following topics:mono-RAB user services supported

multi-RAB user services supported

Configuration of AMR service

















Section 4Measurements






9300 W-CDMA · UA06 R99 Algorithms DescriptionMeasurements4 · 2

Blank Page



2009-02-2901


Document History





Module Objectives


Describe measurements principles

Describe main measurements purpose and use

Describe NBAP measurement process and parameters

Describe RRC measurement process and parameters

Describe In-Band measurement process and parameters











Table of Contents


1 UMTS Measurements Principles 71.1 Reported Measurements 81.2 Measurements Elaboration 91.3 Measurements Activation 10

2 Main Measurements 112.1 Cell Sets 122.2 Power Measurements 132.3 Signal to Interference Ratio 142.4 Path Loss 152.5 QE and CRCI 16

3 NBAP Measurement Procedures 173.1 NBAP Measurements Initiation 183.2 NBAP Measurement Reports 193.3 Call Trace 203.4 Event Triggered Reports 213.5 Example: Event A 22

4 RRC Measurement Procedures 234.1 RRC Measurements Initiation 244.2 Intra-Frequency Reporting 254.3 RRC Measurements on RACH 264.4 Fast Measurements at Call Establishment 27

5 Intra-Frequency Event Triggered Measurement Reporting 285.1 Intra-Frequency Reporting 295.2 Events Description 305.3 Example: event 1A 31

6 In-Band Measurement Procedures 326.1 RACH & DCH FP Measurements 33












1 UMTS Measurements Principles






1.1 Reported Measurements

• Propagation Delay (RACH)• BLER (CRCI)• BER (QE)

• SIR• SIR Error• DL Transmitted Code Power• Round Trip Time

• DL Transmitted Carrier Power• DL Transmitted power of all codes not used for HS-PDSCH,HS-SCCH,E-AGCH,E-RGCH,E-HICH• UL Received Total Wideband Power• Acknowledged PRACH Preamble

UE Internal Measurements• UE Transmitted Power• UE Position (UEbased GPS)

Quality Measurements• Transport Channel BLER• SIR

Traffic Volume Measurements (UL)

Inter System Measurements• GSM Carrier RSSI• Path Loss• BSIC• Observed time difference to GSM Cell

Intra & Inter Frequency Measurements• P-CPICH Ec/No• P-CPICH RSCP• Path Loss• SFN-SFN Observed Time Difference• Cell Synchronization Information (SFN-CFN)• UTRA Carrier RSSI

RRC Measurements

NBAP Measurements

BTS In-Band Measurements

RNC

UE

NodeB

The Node B has to provide two types of measurements: common measurements and dedicated measurements. These measurements are also called NBAP Measurements because they are reported to the RNC using NBAP messages.

Beside the NBAP measurements, the BTS is also providing measurements results that are sent in-band.

The UE has to be capable of performing 7 different measurement types: intra-frequency, inter-frequency, inter-system, traffic volume, quality, UE-internal and UE positioning. These measurements are also called RRC Measurements because they are reported to the RNC using RRC messages.

In UA5.0, the NodeB removes only the contribution of HSDPA channels (it will not remove the E-DCH contribution) to the power measurement. This leads to slightly overestimation of the R99 contribution and impact DCH call admission control. This effect can be attenuated by increasing DCH admission threshold on power for HSUPA cells.






1.2 Measurements Elaboration

ESTIMATING

acquisition time

FILTERING

filter coefficient

REPORTING

reporting periodor

event triggered RNCNodeB

UE

NBAP Measurements

RRC Measurements

FN = (1 - a).FN-1 + a.MN

Physical Layer provides measurements to the upper layers (Layer 3). For each measurement, a basic measurement period is defined, which corresponds to the shortest averaging period and also the shortest reporting period i.e. the NodeB or UE can not be required to report a measurement to the RNC in a shorter time period.

Before reporting to the RNC, the NodeB or UE Layer 3 performs a filtering operation averaging several measurements and allowing to create measurements reports with a period not necessarily equal to the basic measurement period. The filtering parameter a is defined as a = 1/2(k/2), where k is the parameter received in the Measurement Filter Coefficient IE.

The reporting period for each measurement is configured by the RNC when the UE or the NodeB is requested to perform measurements. The minimum reporting period for each measurement is equal to the basic measurement period for this measurement. In general, the reporting period is a multiple of the basic measurement period.

For UTRAN measurements reported in-band, the reporting period is the period at which frames are sent from the NodeB to the serving RNC.






1.3 Measurements Activation

RNC

isInterFreqMeasActivationAllowed(RadioAccessService)

IsInterfreqCModeActivationAllowedisGsmCModeActivationAllowed

(DlUserService)

measurementConfClassId(NeighbouringRNC)

measurementConfId(FDDCell)

ueInternalMeasurementQuantityueInternalMeasurementFilterCoeff

(UEIntMeas)

isEventTriggeredMeasAllowed(FDDCell)

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

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

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

The parameter IsInterfreqCmodeActivationAllowed controls the activation of of compress mode for inter-FDD neighboring cells measurements.

The parameter isGsmCmodeActivationAllowed controls the activation of compress mode for inter-RAT neighboring cells measurements.

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

Note: UeIntMeas is an optional object.





2 Main Measurements





2 Main Measurements

2.1 Cell Sets

Cells belonging to the Active Set

Cell belonging to the Monitored Set

Cell belonging to the Detected Set

isDetectedSetCellsAllowed(RadioAccessService)

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

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

Cells belonging to the Monitored Set, that do not belong to the active set, but that are monitored by the UE depending on the neighboring list sent by the UTRAN.

Cells belonging to the Detected Set, which are detected by the UE, but that are neither in the Active Set nor in the Monitored Set.

isDetectedSetCellsAllowed indicates if the detected set cells have to be taken into account for RRC Intra-Frequency measurement management for the calls established in Event-Triggered Reporting Mode.





2 Main Measurements

2.2 Power Measurements

Ec/No (dB)

-25 -15 -10 0

Power density of CPICH

Power density in the band

GSM Signal

PilotPilot

Received Power on the GSM BCCH carrier

CPICH_Ec/No =

GSM CARRIER RSSI =

CPICH_RSCP =Received Signal

Code Power measured on CPICH OVSF

code

Intra/Inter-FrequencyIntra/Inter-Frequency

Inter-System

CPICH Ec/No

CPICH Ec/No is the received energy per chip divided by the power density in the band, that is, it is identical to the RSCP measured on the CPICH divided by the RSSI. The UE has to perform this measurement on the Primary CPICH and the reference point is the antenna connector of the UE. This measurement is used for cell selection and re-selection and for handover preparation.

CPICH RSCP

CPICH RSCP is the Received Signal Code Power on one channelization code measured on the bits of the Primary CPICH. The reference point is the antenna connector at the UE. Although the measurement of this quantity requires that the Primary CPICH is despread, it should be noted that the RSCP is related to a chip energy and not a bit energy. This measurement is used for cell selection and re-selection and for handover preparation, open loop power control and pathloss calculation.

GSM carrier RSSI

This measurement is the wide-band received measured on a specified GSM BCCH carrier. This measurement is used for GSM handover preparation.





2 Main Measurements

2.3 Signal to Interference Ratio

DPCCH

ServingRNC

SIR =Power ControlSIR Target

SIR_Error = SIRUL outer loop power control

Received Signal Code Power

Interference Signal Code PowerSF x

DPCCH= SIRRSCP

ISCPx

2

SF

DL outer loop power control

– SIR Target

SIR =

Link Q

ualit

y Esti

mation

SIR (Node B measurement)

The Signal to Interference Ratio (SIR) is measured on a dedicated physical control channel (DPCCH) after radio link combination in the Node B. In compressed mode, the SIR should not be measured during the transmission gaps.

SIR is defined as SF*(RSCP/ISCP) where SF is the spreading factor, RSCP is the Received Signal Code Power and ISCP is the Interference Signal Code Power.

This measurement is used in Power Control algorithm.

SIR Error

SIR error is defined as SIR - SIRtarget. SIRtarget is the SIR value for the UL outer loop power control algorithm.

This measurement is used to assess the efficiency of the UL outer loop power control.

SIR (UE measurement)

SIR is defined as (RSCP/ISCP)*SF/2

The reference point for RSCP and ISCP is the antenna connector, but they can only be measured at the output of the de-spreader as they assess either the received power and the non-orthogonal reference received on a particular code. It should be clearly understood that RSCP is though a wideband measurement i.e. at chip level, the narrow band measurement is RSCP * SF/2.

This measurement is used as a quality estimation for the link (for downlink outer loop power control). It is sent periodically, once every power control cycle and event triggered to the RNC (RRC).





2 Main Measurements

2.4 Path Loss

Path Loss = Primary CPICH Tx Power - P-CPICH_RSCP

P-CPICH

FDD Cell

Path Loss

Path Loss

The path loss is defined as Primary CPICH Tx power – P-CPICH RSCP.

This measurement is used to define the initial PRACH power and for inter frequency handover criteria evaluation.





2 Main Measurements

2.5 QE and CRCI

RNC

CRCIndicator

Physical

Channel

• Soft Handover• UL outer loop PC

IE QE Selector:

« selected » Transport Channel BER

« non-selected » Physical Channel BER

OR

Quality Estimate:

Frame Protocols

Transport Channels

blockblock

qeSelector (Static)

Transport Channels

blockblock

DATA CRCtx

CRC INDICATOR

The CRC indicator is attached to the UL frame for each transport block of each transport channel transferred between the NodeB and the RNC. It shows if the transport block has a correct CRC (0=Correct, 1=Not Correct). This measurement is used for frame selection in case of soft handover.

QUALITY ESTIMATE

The quality estimate is reported in band in the UL data frames from the NodeB to the RNC and it is derived from the Transport channel BER or Physical channel BER. If the IE QE-Selector is equal to:

selected » in the DCHs of the DCH FP frame, then the QE is set to the Transport channel BER

non-selected » in the DCHs of the DCH FP frame, then the QE is set to the Physical channel BER.

In case of soft handover, the quality estimate is needed in order to select a transport block when all CRC indications are showing bad (or good) frame. The RNC compares the QE value with the qeThreshold (static parameter) in order to choose the best transport block.

Quality Estimate can also be used to enhance the UL Outer Loop Power Control mechanism.





3 NBAP Measurement Procedures






3.1 NBAP Measurements Initiation

• DL Transmitted Code Power• SIR• RTT• ...

• On Demand• Event-Triggered• Periodic

MeasurementID

MeasurementObject Type

Measurementtype

MeasurementFilter

Coefficient

ReportCharacteristics

Measurement Initiation Request

• Cell• RACH• …

• Common• Dedicated

• DL Transmitted Carrier Power• RTWP

• ...

C-RNC

Node B Common

Dedicated

Depending on the type of measurement, (common or dedicated), measurement requests are initiated by the controlling RNC by sending a COMMON MEASUREMENT INITIATION REQUEST or DEDICATED MEASUREMENT INITIATION REQUEST to the Node B.

The common and dedicated measurement messages both contain the following information elements to define the measurements to be performed:

A measurement id uniquely identifying each measurement.

A measurement object type to indicate the type of object on which the measurement is to be performed, e.g., cell, RACH, time slot, etc.. It can be common or dedicated according to the message. In the case of a dedicated measurement either a radio link is identified on which the measurement has to be performed or the measurement should be performed on all radio links for the Node B.

A measurement type indicates which measurement is to be performed. It is also common (Received total wideband power, transmitted carrier power, Acknowledged PRACH preambles, etc.) or dedicated (SIR, transmitted code power, In-Band (transport channel BER, physical channel BER), etc.).

A measurement filter coefficient gives the parameter for the layer 3 filtering to be performed before the measurement can be reported.

The report characteristics give the criteria for reporting the measurement. The reporting is on demand, periodic or event-triggered.






3.2 NBAP Measurement Reports

Common Measurement ReportscommonMeasurementReportingPeriod

commonMeasurementFilterCoeff(NBAP Measurement)

nbapCommonMeasRtwpReportingPeriodnbapCommonMeasRtwpFilterCoeff

(NbapMeasRtwpParameters) Measurement ID

Report Type Measured Quantity

C-RNCNode B

Common Measurement Termination Request

The reports are sent in the COMMON MEASUREMENT REPORT, on criteria defined by the report characteristics given in the measurement request.

For these Common Measurements, the type of measurement report is defined by the parameter commonRepType [on demand, periodic, event-triggered].

The quantity measured is defined by the parameter measQuantity.

The periodicity is given in the Report_Periodicity IE of the measurement request message.

The periodicity is given in the Report_Periodicity IE of the measurement request message and corresponds to CommonMeasurementReportingPeriod parameter for DL Transmitted Carrier Power and DL Transmitted Carrier Power of All Codes not used for HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH Transmission.

nbapCommonMeasRtwpReportingPeriod is the reporting period to be applied to UL RTWP measurement

CommonMeasurementFilterCoeff is the filtering coefficient to be applied to DL Transmitted Carrier Power and DL Transmitted Carrier Power of All Codes not used for HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH Transmission measurements.

nbapCommonMeasRtwpFilterCoeff is the filtering coefficient to be applied to UL RTWP measurement

The measurements reporting by the Node B stops upon reception of COMMON MEASUREMENT TERMINATION REQUEST sent by the C-RNC if any.






3.3 Call Trace

Measurement Reports

sirRequired sirReportPeridodicity

transmittedCodePowerRequired transmittedCodePowerReportPeridodicity

roundTripTimeRequired roundTripTimeReportPeriodicity

(NbapDedicatedMeasConfigForCallTrace)

C-RNCNode B

Measurement Initiation Request

Dedicated Measurement Termination Request

Common

Dedicated

Common

Dedicated

Common Measurement Termination Request

tcpRequiredtcpReportPeriodicity

rtwpRequired rtwpReportPeridodicity

(NbapCommonMeasConfigForCallTrace)

In the case of Dedicated Measurements, three different types of measurements reports are supported (SIR, DL TRANSMITTED CODE POWER and ROUND-TRIP-TIME). For Call Trace purposes, these three types of reports can be activated separately and can be configured with different periodicities.

The procedure is initiated with a DEDICATED MEASUREMENT INITIATION REQUEST message sent from the RNC to the Node B. This procedure is used by a RNC to request the initiation of measurements on dedicated resources (all UE Radio links managed by FDDCells belonging to this Node B.

Upon reception, the Node B shall initiate the requested measurement according to the parameters given in the request and shall periodically send a DEDICATED MEASUREMENT REPORT.

The procedure is operational as long as the RL is established. The RNC does not send sent a DEDICATED MEASUREMENT TERMINATION REQUEST message. Instead, even though the trace session is deleted, the NBAP dedicated measurement reporting, if initiated, will remain until the radio links associated with the call being traced are deleted or released.

Round trip time (RTT) is defined as: RTT = TRX - TTX, where:TTX = the time of transmission of the beginning of a DL DPCH frame to a UE,TRX = the time of reception of the beginning (the first detected path in time)

of the corresponding UL DPCCH/DPDCH frame from the UE.






3.4 Event Triggered Reports

C-RNC

Node B

Dedicated Measurement Initiation Request (Bx)

Dedicated Measurement Termination Request (Bx)

NBAP Dedicated Report Event Bx

RL Monitoring• Event A• Event B1• Event B2

Primary Cell

iRM Scheduling Downgraded UE

NBAP event triggered report mode is only used in the scope of iRM scheduling downgrade/upgrade procedures with the RNC perspective to retrieve the transmitted code power by the Node B for a particular radio link (user) and to order the radio bearer downsizing/upsizing through iRM scheduling towards the more adapted bit rate to guarantee service continuity.

For the purpose of iRM Scheduling RNC configures the Node B with one Event A and two Events B:

Event A is indicating that the radio conditions have become bad enough to attempt a downgrading to the fallback radio bearer in order to maintain a good radio link quality.

Event B1 is indicating that the radio conditions have become good enough to attempt an upgrading towards the original requested RB.

Event B2 is indicating that the radio conditions have become good enough to consider an upsizing towards a relative lower bit rate than the requested RB to maintain a good radio link quality.






3.5 Example: Event A

Transmitted Code Power

Event AReport

Primary Cellthreshold_delta

(DlIrmSchedDowngradeTxcp)

Event A timeToTrigger Event A timeToTrigger

timeToTrigger

(DlIrmSchedDowngradeTxcp)

Event AThreshold

pcpichPower + maxDlTxPowerPerOls

-

In order to be able to perform IRM Scheduling downgrade, the RNC configures NBAP dedicated measurement by event A report for this UE on the primary cell.

So, each time the primary cell changes, the RNC terminates measurements on the old primary cell and initiates measurements on the new primary cell.

Event A configuration relies on:

Measurement Threshold: the relative transmitted code power threshold given by the parameter threshold_delta is used to compute the absolute TxCP Threshold together with the parameters pcpichPower (FDDCell) and maxDlTxPowerPerOls (DlUsPowerConf).

Measurement Hysteresis: timeToTrigger.

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





4 RRC Measurement Procedures






4.1 RRC Measurements Initiation

Measurement ControlRRC

OR

SI broadcastP-CCPCH

Node BUE

MeasurementID

MeasurementObject

MeasurementType

MeasurementQuantity

• FDDCell• Physical Channel• RB• …

• Ec/No• RSCP• BLER• Traffic Volume• ...

Inter-FrequencyIntra-FrequencyInter-SystemTraffic VolumeQualityUE internal

MeasurementReportingQuantity

MeasurementReportingCriteria

ReportingMode

MeasurementCommand

• Setup • Modify• Release

• Periodical• Event-Triggered

• RLC AM• RLC UM

In CELL_FACH, CELL_PCH or URA_PCH state, the UE is informed of the measurements to perform via the system information broadcast on the P-CCPCH.

When the UE is in CELL_DCH state, UTRAN starts a measurement in the UE by sending the MEASUREMENT CONTROL message, which includes the following information elements to define measurements to perform:

measurement id is a reference number to be used when modifying or releasing measurement.

measurement command indicates the action performed on the measurement (set up a new measurement, modify the characteristics of a measurement, …).

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

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

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

measurement reporting quantity indicates quantities that the UE should report together with the measurement quantity for example, the measurement quantity which triggered the report.

measurement reporting criteria indicates the type of reporting that is, periodical or event-triggered.

reporting mode specifies whether the UE shall transmit the measurement report using acknowledged or unacknowledged RLC mode.






4.2 Intra-Frequency Reporting

Active Set cells+

6 Best Monitored cells

• Cell Synchronization information (SFN-CFN)

• CPICH Ec/No

• CPICH RSCP

• SFN-SFN observed time difference « type2 »

Measurement Report

Measurement Report

rrcIntraFreqMeasurementReportingPeriodrrcIntraFreqMeasurementFilterCoeff

(RRCMeasurement)

MeasurementID


Node B

MeasurementResults

repMode (static)

maxCellsRepType (static)

The MEASUREMENT REPORT message is sent from the UE to the UTRAN and contains the measurement id, the measured results and the measurement event result that was required to be reported.

When the rrcIntraFreqMeasurementReportingPeriod time has elapsed, the UE shall send the computed measurement.

Reporting Quantities

The RNC requests the following quantities to be reported by the mobiles:

“Cell Synchronization information”: provides the difference between SFN of the reported cell and CFN as observed by the UE.

CPICH Ec/No: the received energy per chip divided by the power density in the band.

CPICH RSCP: the received power on one code measured on the Primary CPICH.

Other reporting quantities are also supported by UTRAN and are also requested to the UE for tracing purposes:

SFN – SFN observed time difference "type 2": the relative timing difference between cell j and cell i measured on the primary CPICH.






4.3 RRC Measurements on RACH

RACH

Neighboring Cells

sib11IntraFreqMeasurementNbrOfCellOnRACHsib11IntraFreqMeasurementFilterCoeffOnRACH

(RRCSysInfoMeas)

SIB 11Reported Measurements on RACH

CPICH Ec/No

CPICH RSCP

Path Loss

or

or

measQuantity (static)

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

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

The parameter sib11IntraFreqMeasurementNbrOfCellOnRACH indicates how many cell measurements shall be reported in the RACH message, including the current cell.

Note: 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.






4.4 Fast Measurements at Call Establishment

Measurement Control

SI broadcastP-CCPCH

NodeBUERRC Connection Request

RRC Connection Setup

Measurement Report

isSib11MeasReportingAllowed

(FDDCell)cpichEcNoReportingRange1A

hysteresis1AtimeToTrigger1A

RNC

RadioAccessService

DedicatedConf

HoConfClass

Event1AHoConfInSIB11

This feature allows UTRAN to provide intra-frequency measurements configuration information to UEs which are in Idle Mode or in Cell-FACH. Received within the SIB11, information is used by UEs to activate intra-frequency measurements just after entering the Cell-DCH state, with no need to wait for the first Measurement Control.

If the reporting mode is “Event Triggered”, only Event 1A is configured in the SIB11 and UE sends the first Measurement Report only if the 1A Event has been reached. The rest of the events are configured in the first RRC Measurement Control message. Event1AHoConfInSIB11 dedicated object has been created under HoConfClass so that specific 1A setting can be broadcast in SIB11 for faster measurement.If the reporting mode is “Periodic”, the UE keeps on sending reports at the defined period until the reception of the first RRC Measurement Control.

The first RRC Measurement Control message sent to the UE is of type SETUP instead of MODIFY in order to ensure no misalignment between UE and the Network.

UE starts sending measurements when its state changes:

from Idle mode to Cell-DCH (after the RRC Connection Setup)

from Cell-FACH to Cell-DCH (after the RRC RB Setup)





5 Intra-Frequency Event Triggered Measurement Reporting






5.1 Intra-Frequency Reporting

Active Set cells+

6 Best Monitored cells+

3 Best Detected cells (call trace only)

• CPICH Ec/No

• CPICH RSCP

Measurement Report (EventNX)

MeasurementID


Node B

MeasurementResults


isDetectedSetCellsAllowed(RadioAccessService)

The MEASUREMENT REPORT message is sent from the UE to the UTRAN and contains the measurement id, the measured results and the measurement event result that triggered the report.

Reporting Quantities

The RNC requests the following quantities to be reported by the mobiles:

CPICH Ec/No: the received energy per chip divided by the power density in the band.

CPICH RSCP: the received power on one code measured on the Primary CPICH.

In case or Event Measurements Reported for UE tracing, then up to 3 best detected cells can be reported in some of the Events.






5.2 Events Description

Best Active Set cell CPICH RSCPMeasid12 2F

Estimated quantity of current carrier is better than threshold.Best Active Set cell CPICH Ec/NoMeasid11 2F

Best Active Set cell CPICH RSCPMeasid12 2D

Estimated quantity of current carrier is worse than threshold. Best Active Set cellCPICH Ec/NoMeasid11 2D

Hard Handover Management

The P-CPICH of a cell that is in DCH AS but not in E-DCH AS becomes better than the P-CPICH of a cell that is already in E-DCH AS.

Any of Active SetCPICH Ec/NoMeasid1 1J

An active P-CPICH becomes worse than an absolute threshold. RL deletion based on absolute criteria.

Any of Active SetCPICH Ec/NoMeasid1 1F

A monitored P-CPICH becomes better than an absolute threshold. RL addition based on absolute criteria when Active Set is not full

Any of Monitored Set

CPICH Ec/NoMeasid1 1E

Change of best cell. Primary cell changeAny of measured cell

CPICH Ec/NoMeasid1 1D

A non-Active P-CPICH becomes better than Active P-CPICH. RL replacement based on relative criteria when AS is full


CPICH Ec/NoMeasid1 1C

An active P-CPICH enters a reporting range. RL deletion based on relative criteria

Any of Active SetCPICH Ec/NoMeasid1 1B

A monitored P-CPICH enters a reporting range. RL addition based on relative criteria when Active Set is not full


CPICH Ec/NoMeasid1 1A

Soft Handover Management

Semantics & usageTriggering cellsTriggering quantity

Meas. IdEvent Id

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 intra-frequency reporting measurements. Inter-frequency and inter-RAT measurements reporting are based on periodical reporting.

The use of event triggered reporting has a direct impact on the following mechanisms:

primary cell determination

active set management

alarm measurement criteria

inter-frequency blind handover

radio link color determination






5.3 Example: event 1A

Best Cell

New Cell

CPICH_EC/No

entering reporting range

leaving reporting range

Even

t1A

Even

t1A

Even

t1A

timeToTrigger1A(FullEventHOConfShoMgtEvent1A)

repInterval1A(FullEventRepCritShoMgtEvent1A)

amountRep1A(FullEventRepCritShoMgtEvent1A)

cpichEcNoReportingRange1A (FullEventHOConfShoMgtEvent1A)

)2/(10)1(1010 111

aaBest

N

iiNewNew HRLogMWMLogWCIOLogM

A

m−⋅⋅−+⎟⎟⎠

⎞⎜⎜⎝

⎛⋅⋅≥+⋅ ∑

=

maxNbReportedCells1A(FullEventRepCritShoMgtEvent1A)

hysteresis1A (FullEventHOConfShoMgtEvent1A)

neighbouringCellOffset (UmtsNeighbouringRelation)

wParam (static)

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

Event 1A is used to add a RL based on relative criteria when the Active Set is not full.

The variables in the formula are defined as follows:

MNew is the measurement result of the cell entering the reporting range.

CIONew is the individual cell offset for the cell entering the reporting range if an individual cell offset is stored for that cell. Otherwise it is equal to 0.

Mi is a measurement result of a cell not forbidden to affect reporting range in the active set.

NA is the number of cells not forbidden to affect reporting range in the current active set.

MBest is the measurement result of the cell not forbidden to affect reporting range in the active set with the best measurement result, not taking into account any cell individual offset.

W is a parameter sent from UTRAN to UE.

R1a is the reporting range constant.

H1a is the hysteresis parameter for event 1a.

In order to help the operator to monitor efficiently its network, and optimize its neighboring plan, it is possible to trigger this event 1A based on both Detected Set and Monitored Set. However the cells from Detected Set will not be used in the mobility algorithms.

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





6 In-Band Measurement Procedures





6 In-Band Measurement Procedures

6.1 RACH & DCH FP Measurements

1st Transport Block of 1st DCH

1st Transport Block of 1st DCH Pad.

Last Transport Block of 1st DCH

Last Transport Block of 1st DCH Pad.

1st Transport Block of last DCH

1st Transport Block of last DCH Pad.

Last Transport Block of last DCH

Last Transport Block of last DCH Pad.

QE

CRCI

Pad.CRCI

Spare extension

Payload Checksum (optional)


Header CRC FTCFN

Spare TFI of 1st DCH

Spare TFI of last DCH

1st RACH Transport Block

1st RACH Transport Block Pad.

Last RACH Transport Block

Last RACH Transport Block Pad.

CRCI

Pad.CRCI

Spare extension



Header CRC FTCFN

Spare TFIPropagation Delay

The propagation delay is reported in the RACH data frames transferred from the Node B to the RNC when a successful RACH procedure has happened and the RACH has been sent from the UE to the RNC.

The CRC Indicator is attached to the UL frame for each transport block of each transport channel transferred between the Node B and the RNC. It shows if the transport block has a correct CRC.

The Quality Estimate is reported in band in the UL data frames from the Node B to the RNC. This QE corresponds to either the transport channel BER or the physical channel BER when no transport channel BER is available, that is, there is no data transmitted in the UL thus only DPCCH is transmitted.





Module Summary

This lesson covered the following topics:Measurements principles

Main measurements purpose and use

NBAP measurement process and parameters

RRC measurement process and parameters

In-Band measurement process and parameters

















Section 5Mobility Idle Mode






9300 W-CDMA · UA06 R99 Algorithms DescriptionMobility Idle Mode5 · 2

Blank Page


First EditionEl Abed, AchrafeCharneau, Jean-Noël

2009-02-2901


Document History





Module Objectives


Describe PLMN selection and associated parameters

Describe Cell selection and associated parameters in Idle Mode

Describe Cell reselection and associated parameters in Idle Mode

Case of mobility in Connected Mode in Cell_FACH, Cell_PCH or URA_PCH











Table of Contents


1 Network Selection 71.1 PLMN Selection 8

2 Cell Selection in Idle Mode 92.1 Cell Selection Criteria 102.2 UE Power Compensation 11

3 Cell Reselection in Idle Mode Principles 123.1 General Concept 133.2 Mobility in Idle mode, Cell_FACH, Cell_PCH and URA_PCH 143.3 Idle Mode Neighboring List 153.4 Cell Reselection Eligibility Criteria 163.5 High Mobility Detection 17

4 Cell Reselection in Idle Mode without HCS 184.1 Measurements Rules without HCS 194.2 Level Ranking Criterion without HCS 204.3 Quality Ranking Criterion without HCS 214.4 Cell Ranking Algorithm 224.5 Triggering Algorithm 23

5 Cell Reselection in Idle Mode with HCS 265.1 Principles 275.2 Measurements Rules with HCS in Low Mobility 285.3 HCS Quality Level Threshold Criterion 295.4 Measurements Rules with HCS in High Mobility 305.5 Level and Quality Ranking Criteria with HCS 315.6 HCS Cell Filtering in Low Mobility 325.7 HCS Cell Filtering in High Mobility 335.8 Cell Ranking Algorithm 345.9 Triggering Algorithm 35

6 Cell reselection in non-DCH Connected Mode 386.1 SIB 4 and SIB 12 Broadcast 396.2 Sib3 / Sib 11 Parameters & Objects 406.3 SIB4 Parameters & Objects 416.4 SIB 12 Parameters & Objects – UMTS FDD Neighbor 426.5 SIB 12 Parameters & Objects – GSM Neighbor 43

7 Cell Status and Reservation 517.1 Cell Status and Reservation Process 52

8 Location Registration 538.1 LAC/RAC/SAC 54












1 Network Selection





1 Network Selection

1.1 PLMN Selection

Describe Cell reselection and associated parameters

MCC MNC MSIN

mobileCountryCode (Operator)mobileNetworkCode (Operator)

mobileCountryCode (RNC)mobileNetworkCode (RNC)

mobileCountryCode (CsCoreNetworkAccess)mobileNetworkCode (CsCoreNetworkAccess)

mobileCountryCode (PsCoreNetworkAccess)mobileNetworkCode (PsCoreNetworkAccess)

mobileCountryCode (FDDCell)mobileNetworkCode (FDDCell)

MIB / P-CCPCH

Preferred PLMN List Forbidden PLMN List

The different UMTS networks are identified uniquely in the world by the PLMN identifier composed of:

the Mobile Country Code (MCC)

the Mobile Network Code (MNC)

For one carrier, once the cell search procedure is completed, the UE has found the strongest cell and knows its scrambling code. It is then possible to decode the Primary CCPCH.

The MNC and MCC are part of the system information broadcast on the P-CCPCH (in the Master Information Block or MIB).

The UE then decodes the received PLMN identifiers and determines whether or not the PLMN is permitted according to the lists of preferred and forbidden PLMN (stored in the UE). If the PLMN is permitted and chosen, the cell selection parameters are used by the UE to determine which cell to camp on.





2 Cell Selection in Idle Mode






2.1 Cell Selection Criteria

Srxlev > 0

CPICH_RSCP > qRxLevMin + Pcompensation

P-CPICH

S Criteria

AND

qQualMinqRxLevMin

Squal > 0

CPICH_Ec/No > qQualMin

FDDCCell

FDDCell

CellSelectionInfo

Squal and SRxlev are the two quantities used for cell selection criteria.

If the criteria are fulfilled, the UE moves to the camped normally state where the following tasks will be performed:

Select and monitor the indicated PICH and PCH.

Monitor relevant System Information.

Perform measurements for the cell reselection evaluation procedure.

If the criteria are not fulfilled, the UE will attempt to camp on the strongest cell of any PLMN and enter in the camped on any cell state where it can only obtain limited service (emergency calls). The following tasks will be performed in the camped on any cell state:

Monitor relevant System Information.

Perform measurements for the cell reselection evaluation procedure.

Regularly attempt to find a suitable cell trying all radio access technologies that are supported by the UE. If a suitable cell is found, the cell selection process restarts.






2.2 UE Power Compensation

NodeB

RNC

FDDCell

CellSelectionInfo

RadioAccessService

DedicatedConf

PowerConfClass

Pcompensation=

max (sibMaxAllowedUlTxPowerOnRach – P_MAX, 0)

Srxlev > 0

CPICH_RSCP > qRxLevMin + Pcompensation

+21 dBm4

+24 dBm3

+27 dBm2

+33 dBm1

P_MAXUE Class

qRxLevMinsibMaxAllowedUlTxPowerOnRach

powerConfId

Pcompensation = max (sibmaxAllowedUlTxPowerOnRach – P_MAX, 0). Pcompensation is a compensation factor to penalize the low power mobiles.

sibMaxAllowedUlTxPowerOnRach = maximum transmit power level the UE is allowed to use while accessing the cell on RACH.

P_MAX = maximum output power of the UE according to its power class.

Class 1: P_MAX= 33dBm








3 Cell Reselection in Idle Mode Principles






3.1 General Concept

HM not detectedCell Reselection after tReselectionHigher priority is favored

HM detectedCell Reselection after tReselection * speedDependScalingFactorLower priority is favored

P1

P2 P2 P2

Cop

yrig

ht ?

1996

Nor

ther

n Te

leco

m

P3 P3 P3 P3 P3P3

2 different 3GPP UE algorithmsClassical for mono-layer networkHierarchical Cell Structure (HCS) algorithm

HCS Priority for Serving cell and Neighboring cells are introduced (between 0 and 7)

Both algorithms steps:Define which type of neighboring cells have to be measured (intra-freq, inter-freq, inter-RAT)Check if measured cells are eligible to cell reselectionRank the eligible cells to eventually perform cell reselection

Different behaviors in case:HCS is used / NOT usedHigh-Mobility Detection (HMD) is detected / NOT detected

Cell Reselection without HCS differs from UA4.2 only by the fact that High Mobility Detection is used in reselection triggering timer.

Cell Reselection with HCS was introduced in UA5.






3.2 Mobility in Idle mode, Cell_FACH, Cell_PCH and URA_PCH

Cell SelectionS criterion

Cell Reselection without HCS

Measurements Rules without HCS

Cell Ranking without HCSusing High Mobility Detection

Level + QualityR criteria

Cell Reselection with HCS

Measurements Rules with HCSusing High Mobility Detection

Quality Level Threshold H Criterion

Cell Ranking with HCSusing High Mobility Detection

HCS is usedHCS is not used

Level + QualityR criteria

Cell Filteringusing HCS Priority

Cell Reselection without HCS differs from UA4.2 only by the fact that High Mobility Detection is used in reselection triggering timer.

Cell Reselection with HCS was introduced in UA5.






3.3 Idle Mode Neighboring List

sib11AndDchNeighbouringFddCellAlgo (FDDCell)

sib11OrDchUsage (UMTSFddNeighbouringCell)

(GsmNeighbouringCell)

SIB11 / P-CCPCH

Serving Cell

Max 48 cells

SIB11 Neighboring List

• UMTSFddNeighbouringCell List

• GsmNeighbouringCell List

FDDCell Neighboring List

• intra-frequency FDDCells• inter-frequency FDDCells• GSM Cells

The list of neighboring cells is broadcasted through SYSInfo.

The information and parameters related to the neighboring cells are contained into two subtrees in the Radio Access Network Model:

UMTSNeighbouringFDDCell for FDD intra- and inter-frequency neighbors

GSMNeighbouringCell for GSM neighbors

An algorithm is used to declare and control correctly the list of neighboring cells in order to differentiate between the configuration of idle mode/cell_FACH mode neighbors (sent in SIB11) and cell_DCH connected mode neighbors. The idle mode/cell_FACH mode neighboring list is a subset of the cell_DCH connected mode neighboring list. The differentiation is set through the sib11OrDchUsage parameter on each umtsFddNeighbouringCell. Note that this parameter is only used when sib11NeighboringFddCellAlgo is set to manual.






3.4 Cell Reselection Eligibility Criteria

UMTSFddNeighbouringCell

Srxlev > 0Squal > 0

> > + PcompensationCPICH_Ec/No qQualMin (UMTSFddNeighbouringCell) qRxLevMin(UMTSFddNeighbouringCell)

CPICH_RSCPAND

GSMNeighbouringCell

QRxLeavMeas > qRxLevMin (GSMNeighbouringCell) + Pcompensation

Srxlev > 0Max(MaxAllowedUlTxPower - P_max, 0)

(GSMNeighbour/GsmCell)

Max(MaxAllowedUlTxPower - P_max, 0)(UmtsNeigbouringRelation)

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.






3.5 High Mobility Detection

Nb of Reselection > nCr during tCrMax

UE not in High Mobility state

UE enters High Mobility state

Nb of Reselection <= nCr during tCrMax + tCrMaxHyst

nCr tCrMax

tCrMaxHyst

FDDCell

CellSelectionInfo

CrMgt

High and Low mobility UEs are distinguished thanks to the rate of Cell Reselection.





4 Cell Reselection in Idle Mode without HCS





4 Cell Reselection in Idle mode without HCS

4.1 Measurements Rules without HCS

sIntraSearch sInterSearch

sSearchRatGsm

isHcsUsed = FalsesSearchHcssHcsRatGsm

Intra-frequency No measurement

Intra-frequency Inter-frequency Inter-frequency

Intra-frequency Inter-frequency

GSM Inter-frequency

GSM

Srxlev

sInterSearch sIntraSearch sSearchRatGsm

sSearchHcs

sHcsRatGsm

Squal

FDDCell

CellSelectionInfo

With isHcsUsed set to False:

“Use of HCS” IE broadcasted in SIB11 is set to “Not used”

Cell reselection is processed the same way as before UA5.0

If sIntraSearch is not sent for the serving cell, the UE performs intrafrequency

measurements.

If sInterSearch is not sent for the serving cell, the UE performs interfrequency

measurements.

If sSearchRatGsm is not sent for the serving cell, the UE performs

measurements on GSM cells.

Note: If a negative value is datafilled and sent in SIB3, the UE shall consider the value

to be 0 (see [3GPP_R04]).

Note: IE present in SIB3 is encoded as follows: sHcsRatGsm = (IE * 2) +1






4.2 Level Ranking Criterion without HCS

qHyst1 (CellSelectionInfo)


GSMNeighbouringCell

CPICH_RSCP qOffset1sn (UMTSFddNeighbouringCell)CPICH_RSCPRLs = +

RL criterion for Serving Cell RL criterion for FDD Neighboring Cell

RLn = –

FDDCell

RxLev qOffset1sn (GSMNeighbouringCell)RLn = –

RL criterion for GSM Neighboring Cell

qHyst1 (CellSelectionInfo)qOffset1sn (UmtsNeighbouringRelation)qOffset1sn (GsmNeighbouringCell)

The cell level ranking criterion is used to rank the cells prior to the reselection. When HCS

is not used, the behavior is the same as before UA5.0.

The serving cell and all the neighboring cells being eligible (S criteria) are ranked accordingly to the RL

criteria, as defined below:

RLs = Qmeas,s + Qhysts; for the serving cell

RLn = Qmeas,n - Qoffsets,n; for any GSM or UTRAN/FDD neighboring cells

Where Qmeas is the CPICH_RSCP for the FDD case. For GSM cells, RxLev is used instead of CPICH RSCP in the mapping function.

Where Qhysts is the qHyst1 parameter of the CellSelectionInfo object.

Where Qoffset is the qOffset1sn parameter of the GSMcell object.






4.3 Quality Ranking Criterion without HCS

RQn = –RQs = +CPICH_Ec/No CPICH_Ec/NoqHyst2 (CellSelectionInfo) qOffset2sn (UMTSFddNeighbouringCell)

RQ criterion for Serving Cell RQ criterion for Neighboring Cell

FDDCell UMTSFddNeighbouringCell

qHyst2 (CellSelectionInfo)qOffset2sn (UmtsNeighbouringRelation)

The cell quality ranking criterion is used to rank the cells prior to the reselection. When HCS

is not used, the behavior is the same as before UA5.0.

The serving cell and all the FDD neighboring cells being eligible (S criteria) are ranked accordingly to the RQ

criteria, as defined below:

RQs = Qmeas,s + Qhysts; for the serving cell

RQn = Qmeas,n - Qoffsets,n; for any UTRAN/FDD neighboring cells

Where Qmeas is the CPICH Ec/No measurement.

Where Qhysts is the qHyst2 parameter of the CellSelectionInfo object.

Where Qoffset is the qOffset2sn parameter of the UMTSFddNeighbouringCell object.






4.4 Cell Ranking Algorithm

FDDCell

CPICH_Ec/No CPICH_RSCP

Best cell is a ..?

Best GSMCellis reselected

GSMCell

Best FDDCellafter First Ranking

is reselected

Best FDDCellafter Second Ranking

is reselected

qualMeas = ..?

Eligible CellsFirst Ranking RL

(CPICH_RSCP & RxLev)

Second Ranking RQ

(CPICH_Ec/No)

qualMeas (cellSelectionInfo)

Then the cell reselection process is as follows:

If a GSM cell is ranked as the best cell, then the UE shall perform cell reselection to that GSM cell.

If an FDD cell is ranked as the best cell and the quality measure parameter qualMeas for cell re-selection is set to qualMeasRscp, then UE shall perform cell re-selection to that FDD cell.

If an FDD cell is ranked as the best cell and the quality measure parameter qualMeas for cell re-selection is set to qualMeasEcno, then UE shall perform a second ranking.

Note: that parameter has been introduced in UA5.0 and was previously hard-coded to qualMeasEcno.

hsiddhar

Sticky Note

Cells satisfy the S criteria. Also depend on Measurement rule.






4.5 Triggering Algorithm

UMTSFddNeighbouringCellInter-freq

UMTSFddNeighbouringCellIntra-freq

GSMNeighbouringCell

ServingFDDCell

tReselection (UE not in High Mobility)tReselection x speedDependScalingFactorTReselection (UE in High Mobility)

tReselectionx interRatScalingFactorTReselection(UE not in High Mobility)

tReselection x speedDependScalingFactorTReselectionx interRatScalingFactorTReselection(UE in High Mobility)

tReselection x interFreqScalingFactorTReselection (UE not in High Mobility)tReselection x speedDependScalingFactorTReselection x interFreqScalingFactorTReselection (UE in High Mobility)

speedDependScalingFactorTReselection

(CrMgt)

tReselectioninterFreqScalingFactorTReselection interRatScalingFactorTReselection

(CellSelectionInfo)

Cell reselection triggered if the target cell remains best-ranked during more than tReselection secthe UE has been camping on the current serving cell since at least 1 sec

For R5 UE, tReselection is replaced by

Several scaling factors, introduced by 3GPP R5, can be applied to tReselection:

speedDependScalingFactorTReselection (used with or without HCS usage), between 0 and 1, in order to speed up the reselection when High-Mobility state is detected.

interFreqScalingFactorTReselection between 1 and 4.75, in order to delay the reselection to Inter-frequency neighboring cell.

interRatScalingFactorTReselection between 1 and 4.75, in order to delay the reselection to GSM neighboring cell.

Note: All the parameters related to cell selection/reselection are broadcasted on the BCCH using either:

SIB3 for cell reselection parameters related to the serving cell

SIB11 for cell reselection parameters related to the neighboring cells.





Exercise: Multi-Layer Cell Structure, HCS not used

Neighb.MC

Neighb.MA Neighb.MB

Serv.mc

Macro FDDcells F2

Micro FDDcells F1

Neighb.GC

Neighb.GA Neighb.GBMacro GSMcells

Neighbo.mbNeighbo.ma

20-73Neighboring cell GC

20-80Neighboring cell GB

20-98Neighboring cell GA

100-85-4Neighboring cell MC

100-89-5Neighboring cell MB

100-99-9Neighboring cell MA

00-104-10Neighboring cell mb

00-118-21Neighboring cell ma

44-108-12Serving cell mc

qOffset2sn(dB)

qHyst2(dB)

qOffset1sn(dB)

qHyst1(dB)

CPICH_RSCP / GSM RSSI (dBm)

CPICH_Ec/No (dB)

Cell





Exercise: Multi-Layer Cell Structure, HCS not used [cont.]

AssumptionsUE class 3qualMeas = qualMeasEcnoqQualmin (Serving and Neighboring Cell 3G) = - 16 dBqRxLevMin (Serving and Neighboring Cell 3G) = - 115 dBmqRxLevMin (Neighboring Cell 2G) = - 104 dBmsibMaxAllowedUlTxPowerOnRach = 24 dBmmaxAllowedUlTxPower (Neighboring Cell 3G) = 24 dBmmaxAllowedUlTxPower (Neighboring Cell 2G) = 33 dBm

• sIntraSearch = 8dB• sInterSearch = 6dB• sSearchRatGSM = 4dB• sSearchHcs = 0dB• sHcsRatGsm = 0dB

• isHcsUsed = False

Question: which is the cell reselected by the UE ?





5 Cell Reselection in Idle Mode with HCS






5.1 Principles

hcsPrio (hcsCellparam)hcsPrio (UmtsNeighbouringHcsCellparam)hcsPrio (GsmHcsCellparam)

Each cell is assigned an HCS Priority value between 0 and 70 = lowest priority7 = highest priority

P1

P3

HM not detected Higher priority is favored

HM detected Lower priority is favored

P2 P2

P3 P3 P3

Cop

yrig

ht ?

1996

Nor

ther

n Te

leco

m

HCS priorities are broadcasted in SIB3 for the serving cell and SIB11 for the neighboring cells.

3GPP assumes that a cell with hcsPriority=7 has higher priority than another cell with hcsPriority=0.

Actually, one shall consider HCS priority in conjunction with HMD and opertor’s strategy, as depicted in

When high-mobility state is detected, UE will try to reselect a cell with lower HCS priority

When high-mobility state is NOT detected, UE will try to reselect a cell with higher HCS priority

HCS rules regarding priorities and HMD are presented in the following pages.






5.2 Measurements Rules with HCS in Low Mobility

isHcsUsed (FDDCell) = TrueUE not in High Mobility state


hcsPrion >= hcsPrios


hcsPrion > hcsPrios

All Intra-frequency All Inter-frequency

GSM

hcsPrion >= hcsPrios

No measurement

All GSM

Srxlev

sInterSearch sIntraSearch Squal

sSearchHcs

Srxlev

Squal

sHcsRatGsm

sSearchRatGsm sLimitSearchRat

sLimitSearchRat

(HcsCellParam)

With isHcsUsed set to True:

“Use of HCS” IE broadcasted in SIB11 is set to “Used”

When HCS is used, measurement rules are based on the same thresholds as when HCS is not used (sIntraSearch, sInterSearch, sSearchRatGsm, sSearchHcs and sHcsRatGsm) plus a new parameter sLimitSearchRat wich is broadcasted in SIB3.

When using HCS, the difference in the neighboring measurement rules relies on the filtering of the measured cells based on high-mobility state detection.

When the UE is not in High Mobility state, measurements are triggered on higher priority neighboring cells.






5.3 HCS Quality Level Threshold Criterion

Qmeasn qHcsnHn = –

qHcss

NeighbouringCellhcsPriorityn = hcsPrioritys

NeighbouringCellhcsPriorityn <> hcsPrioritys

Qmeasn qHcsnQmeassHs = –

H criterion for Serving CellH criterion for FDD or GSM Neighboring Cellof same HCS priority as Serving cell

Hn = –

FDDCellhcsPrioritys

H criterion for FDD or GSM Neighboring Cellof different HCS priority than Serving cell

qHcs (hcsCellparam)qHcs (UmtsNeighbouringHcsCellparam)qHcs (GsmHcsCellparam)

HCS introduces a new criterion, so-called Quality Level Threshold H criterion, which is used to determine whether prioritized ranking according to hierarchical cell reselection shall apply.

Qmeass and Qmeasn = CPICH_Ec/N0 or CPICH_RSCP for serving cell and FDD neighboring cells based on qualMeas parameter.

Qmeasn = BCCH_RSSI (or BCCH RxLev) for GSM neighboring cells.

Note: According to 3GPP 25.304 the real formula of Hn for a neighbouring cell of hcspriority different than hcsPriority of the serving cell is Hn = Qmeasn – qHcsn – temporaryOffsetn * W(t) but Alcatel-Lucent recommends not to use temporaryOffsets parameters so temporaryOffsetn is always set to 0.






5.4 Measurements Rules with HCS in High Mobility

UE in High Mobility state


hcsPrion <= hcsPrios

All Intra-frequency All Inter-frequency

GSM

hcsPrion <= hcsPrios

All GSM

Srxlev

sInterSearch sIntraSearch Squal

Srxlev

Squal sSearchRatGsm sLimitSearchRat

sSearchHcs

sHcsRatGsm

When the UE is in High Mobility state, measurements are triggered on lower priority neighboring cells.






5.5 Level and Quality Ranking Criteria with HCS

qHysts

NeighbouringCellhcsPriorityn = hcsPrioritys

NeighbouringCellhcsPriorityn <> hcsPrioritys

QmeassRs = +

R criterion for Serving CellR criterion for FDD or GSM Neighboring Cellof same HCS priority as Serving cell

FDDCellhcsPrioritys

Qmeasn qOffsetsns,nRn = –

R criterion for FDD or GSM Neighboring Cellof different HCS priority than Serving cell

Qmeasn qOffsetsns,nRn = –

Like when HCS is not used, both Level and Quality Ranking criteria can be used depending on the setting of qualMeas parameter.

Note: According to 3GPP 25.304 the real formula of Rn for a neighbouring cell of hcspriority equal to hcsPriority of the serving cell is Rn = Qmeasn – qOffsetsnsn – temporaryOffsetn * W(t) but Alcatel-Lucent recommends not to use temporaryOffsets parameters so temporaryOffsetn is always set to 0.






5.6 HCS Cell Filtering in Low Mobility

UE is in High Mobility

state ?

Eligible Cellsaccording to S criteria

Candidate Cells RankingR criteria

yes

At least one cell has

H criterion >=0 ?

no

Keep all neighboring FDD and GSM cells

of the highest hcsPriority as candidates

among those having H criterion >=0

yes

Keep all neighboring

FDD and GSM cellsas candidates

without ordering them

no

See next page

Once H criterion has been computed for the serving cell and each neighboring cell, UE performs ranking of all cells that fulfill the S criterion among:

When high-mobility state has NOT been detected (the higher priority, the

smaller size),

All measured cells, that have the highest hcsPrio among the cells that fulfill H>=0

All measured cells, not considering hcsPrio levels, if no cell fulfills H>=0

When high-mobility state has been detected (the lower priority, the bigger size),

All measured cells with the highest hcsPrio that fulfil H>=0 and have a lower hcsPrio than serving cell

else:

All measured cells with the lowest hcsPrio that fulfil H>=0 and have a higher or equal hcsPrio than serving cell

else:

All measured cells without considering hcsPrio






5.7 HCS Cell Filtering in High Mobility

Keep all neighboring FDD and GSM cells of the highest hcsPriority as candidates

among those having1. hcsPriorityn < hcsPrioritys

2. H criterion >=0

Candidate Cells RankingR criteria

UE in High Mobility

Keep all neighboring FDD and GSM cells of the lowest hcsPriority as candidates

among those having 1. hcsPriorityn >= hcsPrioritys

2. H criterion >=0

not empty list

Keep all neighboring FDD and GSM cellsas candidates

without ordering them

empty list

not empty list

empty list

Once H criterion has been computed for the serving cell and each neighboring cell, UE performs ranking of all cells that fulfill the S criterion among:

When high-mobility state has NOT been detected (the higher priority, the

smaller size),

All measured cells, that have the highest hcsPrio among the cells that fulfill H>=0

All measured cells, not considering hcsPrio levels, if no cell fulfills H>=0

When high-mobility state has been detected (the lower priority, the bigger size),

All measured cells with the highest hcsPrio that fulfil H>=0 and have a lower hcsPrio than serving cell

else:

All measured cells with the lowest hcsPrio that fulfil H>=0 and have a higher or equal hcsPrio than serving cell

else:

All measured cells without considering hcsPrio






5.8 Cell Ranking Algorithm

FDDCell

CPICH_Ec/No CPICH_RSCP

Best cell is a ..?

Best GSMCellis reselected

GSMCell

Best FDDCellafter First Ranking

is reselected

Best FDDCellafter Second Ranking

is reselected

qualMeas = ..?

First Ranking RL

(CPICH_RSCP & RxLev)

Second Ranking RQ

(CPICH_Ec/No)

Candidate NeighboringFDD and GSM cells for

Cell Reselection

Same Ranking as without HCS

Let’s recall that the cell reselection process is as follows:

If a GSM cell is ranked as the best cell, then the UE shall perform cell reselection to that GSM cell.

If an FDD cell is ranked as the best cell and the quality measure parameter qualMeas for cell re-selection is set to qualMeasRscp, then UE shall perform cell re-selection to that FDD cell.

If an FDD cell is ranked as the best cell and the quality measure parameter qualMeas for cell re-selection is set to qualMeasEcno, then UE shall perform a second ranking.






5.9 Triggering Algorithm

tReselection (CellSelectionInfo)interFreqScalingFactorTReselection (CellSelectionInfo)interRatScalingFactorTReselection (CellSelectionInfo)

UMTSFddNeighbouringCellInter-freq

UMTSFddNeighbouringCellIntra-freq

GSMNeighbouringCell

ServingFDDCell

tReselection (UE not in High Mobility)tReselection x speedDependScalingFactorTReselection (UE in High Mobility)

tReselectionx interRatScalingFactorTReselection(UE not in High Mobility)

tReselection x speedDependScalingFactorTReselectionx interRatScalingFactorTReselection(UE in High Mobility)

tReselection x interFreqScalingFactorTReselection (UE not in High Mobility)tReselection x speedDependScalingFactorTReselection x interFreqScalingFactorTReselection (UE in High Mobility)

speedDependScalingFactorTReselection (CrMgt)

Same triggering as without HCS

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.





Exercise: Multi-Layer Cell Structure, HCS used

Neighb.MC

Neighb.MA Neighb.MB

Serv.mc

Macro FDDcells F2

Micro FDDcells F1

Neighb.GC

Neighb.GA Neighb.GB

Macro GSMcells

Neighbo.mbNeighbo.ma

0

0

0

0

0

qOffset2sn(dB)

0

0

0

1

1

1

2

2

2

hcsPriority

-1000-73Neighboring cell GC

-1000-80Neighboring cell GB

-1000-98Neighboring cell GA

-140-85-4Neighboring cell MC

-140-89-5Neighboring cell MB

-140-99-9Neighboring cell MA

-100-104-10Neighboring cell mb

-100-118-21Neighboring cell ma

-1044-108-12Serving cell mc

qHcs(dB)

qHyst2(dB)

qOffset1sn(dB)

qHyst1(dB)

CPICH_RSCP / GSM RSSI (dBm)

CPICH_Ec/No (dB)

Cell

hcsPriority = 0

hcsPriority = 1

hcsPriority = 2

The Cell Reselection Control feature enables a more flexible cell reselection control from the network in a Hierarchical Cell Structure (HCS).

HCS layers management offers several solutions to manage the traffic demand and its associated noise rise.

For example, traffic may be split between the two or three layers in order to minimize the global noise rise, or it may be split depending on the type of service used.

The later solution is conceivable if the microcell layer deployment aims at offering higher rate services continuously within an area.

As a matter of fact, high data rate services require smaller cell sizes than low data rate services and therefore may be continuously offered within an area only by the use of microcell sites (as illustrated on the above slide).

Moreover, since a microcell layers offer better indoor coverage quality than macro layers, this is well suited to high data rate services, which are more likely to be indoor applications.

hsiddhar

Sticky Note

High Mobility- GC Low Mobility -MB





Exercise: Multi-Layer Cell Structure, HCS used [cont.]

AssumptionsUE class 3qualMeas = qualMeasEcnoqQualmin (Serving and Neighboring Cell 3G) = - 16 dBqRxLevMin (Serving and Neighboring Cell 3G) = - 115 dBmqRxLevMin (Neighboring Cell 2G) = - 104 dBmsibMaxAllowedUlTxPowerOnRach = 24 dBmmaxAllowedUlTxPower (Neighboring Cell 3G) = 24 dBmmaxAllowedUlTxPower (Neighboring Cell 2G) = 33 dBm

• sIntraSearch = 8dB• sInterSearch = 6dB• sSearchRatGSM = 4dB• sSearchHcs = 0dB• sHcsRatGsm = 0dB

isHcsUsed = True• sLimitSearchRat = 4dB• temporaryOffest = parameters not used

Question 1: which is the cell reselected by the UE if in High Mobility ?Question 2: which is the cell reselected by the UE if in Low Mobility ?





6 Cell reselection in non-DCH Connected Mode






6.1 SIB 4 and SIB 12 Broadcast

SIB 4: Serving Cell

re-selection parameters broadcast

isDynamicSibAlgoWithSbAllowed(RadioAccessService)

SIB11+

DCHDCH

SIB11+

DCH

DCH

DCH

DCH

SIB11+

DCH SIB11+

DCH

SIB11+

DCH

DCH

DCH

DCH

SIB11+

DCHDCH

SIB11+

DCH

SIB11+

DCH

SIB11+

DCHDCH

DCH

DCHDCH

DCH

SIB11+

DCH

ServingFDDCell

DCH

SIB11+

DCH

DCH

DCH

SIB11+

DCHDCH

DCH

Cell_FACHCell_PCHURA_PCH

SIB 12: N

eighborin

g Cells

re-selectio

n parameters broadcast

sib4Enable (FDDCell)sib12Enable (FDDCell)

Prior to UA06.0, Cell Selection and Reselection information was only broadcast to UE in SIB3/SIB11whatever mode (Idle, URA_PCH, Cell_PCH and Cell_FACH), SIB3 (resp. SIB11) containing serving cell’s information (resp. neighbouring cell’s)

UA06.0 introduces the support of SIB4/SIB12 in order to have different Cell Selection and Reselection setting between Idle mode and connected modes (Cell_PCH, URA_PCH and Cell_FACH).

Enabling SIB4 and SIB12 has a direct impact on the System Information size since many information(especially neighbouring cell’s) are duplicated.

When all scheduling information can not be coded in one MIB segment, SB1 Scheduling Block (SB) is used tosupport the exceeding segments, as defined per 3GPP. isDynamicSibAlgoWithSbAllowed allows the use of such SB1.

hsiddhar

Sticky Note

SIB3- Re selection parameter of serving cell in idle Mode. SIB11- Re selection parameter of neighboring cell in idle Mode SIB4- Serving cell SIB12- neighboring cell in DCH state.






6.2 Sib3 / Sib 11 Parameters & Objects

UmtsNeighbouring

UmtsNeighbouringRelation

CellSelectionInfo

RNC

NodeB

FddCell

FachMeasOccasionInfo

CrMgt

HcsCellParam

UmtsFddNeighbouringCell

UmtsNeighbouringHcsTemporaryOffsets

UmtsNeighbouringHcsCellParam

New objects

Existing related parameters

cellAccessrestriction

Cell Selection Info (SIB 3 / 4 Mapping):

CellAccessRestrictionConnectedModeCellAccessRestriction

CellSelectionInfoConnectedMode.CellSelectReselectInfoPchFachNo Equivalent

CellSelectionInfoConnectedMode.HcsCellParamCellSelectionInfo.HcsCellParam

CellSelectionInfoConnectedMode.CrMgtCellSelectionInfo.CrMgt

CellSelectionInfoConnectedMode.FachMeasOccasionCellSelectionInfo.FachMeasOccasion

CellSelectionInfoConnectedModeCellSelectionInfo

Connected modeIdle Mode

Root = FddCell






6.3 SIB4 Parameters & Objects

CellSelectionInfoConnectedMode

NodeB

FddCell

New objects


FachMeasOccasionInfo

CrMgt

HcsCellParam

cellSelectReselectInfoPchFach

cellAccessRestrictionConnectedMode

tReselectionqHyst1qHyst2

R’99/R4 UEs

R5/R6 UEs

tReselectionPchtReselectionFach

qHyst1PchqHyst1FachqHyst2PchqHyst2Fach

Attributes for SIB4Attributes for SIB4

qHyst1PchqHyst1Fach

CellSelectReselectInfoPchFach

qHyst2FachqHyst2Pch

tReselectionFachtReselectionPch

CellSelectionInfoConnectedMode

tReselectionsSearchRatGsmsSearchHcssIntraSearchsInterSearchsHcsRatGsmqualMeasqRxLevMinqQualMinqHyst2qHyst1interRatScalingFactorTReselectioninterFreqScalingFactorTReselection

CellAccessRestrictionConnectedMode

tBarredintraFreqCellReselectIndcellReservedForOperatorUsecellReservationExtensionbarredOrNotaccessClassPsBarredaccessClassCsBarredaccessClassBarred

CrMgt

tCrMaxHysttCrMax

speedDependScalingFactorTReselection

nCr

FachMeasOccasion

ratTypeListfachMeasOccasionCoef

HCSCellParams

sLimitSearchRatqHcshcsPrio






6.4 SIB 12 Parameters & Objects – UMTS FDD Neighbor

FddNeighCellSelectionInfoConnectedMode


UmtsNeighbouring

RNC

NodeB

Fddcell

UmtsFddNeighbouringCell

UmtsNeighbouringHcsTemporaryOffsets


New objects


qQualMinqRxlevMinqOffset1sn qOffset2snmaxAllowedUlTxPower

hcsPrioqHcs

Neighbouring Info (SIB 11 / 12 Mapping):

Attributes for SIB12:

UMTSNeighbouringRelation.FddNeighCellSelectionI

nfoConnectedMode.UmtsNeighbouringHcsTempora

ryOffset

UMTSNeighbouringRelation.

UmtsNeighbouringHcsTemporaryOffset


nfoConnectedMode.UmtsNeighbouringHcsCellPara

m

UMTSNeighbouringRelation.



nfoConnectedMode

UMTSNeighbouringRelation

Connected modeIdle Mode (Root = UMTSNeighbouringRelation)


qRxLevMinqQualMinqOffsetMbmsqOffset2snqOffset1snneighbouringCellOffsetmaxAllowedUlTxPower


qRxLevMinqQualMinqOffset2snqOffset1snmaxAllowedUlTxPowercellIndivOffset






6.5 SIB 12 Parameters & Objects – GSM Neighbor

GsmCellSelectionInfoConnMode

GSMCell

GSMNeighbour

RNC

NodeB

Fddcell

GsmNeighbouringCell

GsmHcsTemporaryOffsets

GsmgHcsCellParam

New objects


qRxlevMinqOffset1sn

hcsPrioqHcs

GSMCellCellSelectionInfoCMForGsmCell

maxAllowedUlTxPower


qRxLevMinqQualMinqOffsetMbmsqOffset2snqOffset1snneighbouringCellOffsetmaxAllowedUlTxPower


qRxLevMinqQualMinqOffset2snqOffset1snmaxAllowedUlTxPowercellIndivOffset





Exercise

By Respecting the following strategy fill in tables in next pages with the appropriate values for the Mono, Bi and Tri Layer Topologies:

Assuming qQualMin = -16 dB And event2D for 3G-2G HHO = -14 dB

When UE is in Idle mode, we want it to select the most suitable cell:

Small hysteresis between cells

Fast reactivity

When UE is in Cell_FACH or Cell_PCH state, we prefer it to stay on its current layer (in accordance to InterFreq or InterRAT HHO setting), even if increasing the risk of call drop:

Larger hysteresis to prevent Ping-Pong in cell reselection (intra frequency)

Lower threshold to delay the triggering inter freq or inter system measurements





Exercise1: Mono-Layer Topology

Neighbouring Definition:3G

2G

3G 3G

sSearchRatGsm No 2G reselection until criteria for HHO is reached

Objective

2dB

Connected ModeIdle Mode

Only Sib4 is used

qHyst2 Prevent ping pong between cells on connected mode

Objective

2 dB


Objective is to prevent UE to go in 2G while staying in FACH-PCH State:

Subsidiary Question:

Propose a solution to deactivate the inter-RAT mobility?





Exercise2: Bi-Layer Topology

3G (R99)

2G

3G (HSxPA)

3G (R99)

3G (HSxPA)

3G (R99)

3G (HSxPA)Only Sib4 is used

Same setting for SIB4 on both 3G layer

Objectives are to delay the inter-freq mobility and to prevent the UE to go on 2G while in FACH-PCH State

Give two values for SInterSearch when InterFreq or inter-Rat is preferred in the iMCTAsetting

No 2G reselection, first fallback to interfreq reselection

2 dBsSearchRatGsm

sInterSearch

qHyst2

Will depends on iMCTA Alarm priority setting

Prevent ping pong between cells on connected mode

Objective

6 dB

2 dBConnected ModeIdle Mode





Exercise2: Bi-Layer Topology [cont.]


2 dBsSearchRatGsm

sInterSearch

qHyst2

F1 F2 reselection allowed for load sharing


Objective

6 dB


• F1 & F2 settings

3G (HSDPA)

2G

3G (HSxPA)

3G (HSDPA)

3G (HSxPA)

3G (HSDPA)

3G (HSxPA)

Only Sib4 is used

Objectives are to delay the inter-freq mobility and to prevent the UE to go on 2G while in FACH-PCH State





Exercise3: Tri-Layer Topology

3G (R99)

2G

3G (HSxPA)

3G (R99)

3G (HSxPA)

3G (R99)

3G (R99)

3G (HSxPA)

3G (R99)

3G (R99)

3G (HSxPA)

Because of load sharing between F1 & F3 (R99 cells), the strategy is to allow the UE to select the best cell (intra + inter-frequency F1+F3) in idle mode.

For connected mode (PCH / FACH), the strategy consists in keeping the UE on its current layer, except for R99: with load sharing purpose, it is accepted that the UE goes from F1 to F3 (and F3 to F1), but not on F2

F1

F2

F3





Exercise3: Tri-Layer Topology [cont.]


2 dBsSearchRatGsm

sInterSearch

qHyst2

F1 F3 reselection allowed for load sharing


Objective

6 dB


• F1 & F3 settings

No 2G reselection, first fallback to inter-freq reselection

2 dBsSearchRatGsm

sInterSearch

qHyst2

To delay the inter-freq mobility


Objective

6 dB


•F2 settings





Exercise3: Tri-Layer Topology [cont.]

Purpose of SIB 12 is to disadvantage F2 compared to F1 & F3 for Cell reselectionFor which frequency (or frequencies) SIB12 will should be activated?

Disadvantage F2 compared to F1 & F3

0 dBqOffset2snF2

qOffset2snF1 & F3

Objective

0 dB






7 Cell Status and Reservation





7 Cell Status and Reservation

7.1 Cell Status and Reservation Process

barred

notReservedallowed notAllowed

only UE withAccess Classes 11 / 15

are accepted

reserved

try to selecta cell of another

frequency

if no other cell

all UE Access Classesare accepted

notReservedreserved

other UE

barredOrNot (FDDCell) = ..?

intraFreqCellReselectInd (FDDCell) = ..? cellReservedForOperatorUse (FDDCell) = ..?

cellReservationExtension (FDDCell) = ..?

try to reselectsame cell

wait tBarred (FDDCell)

notBarred

try to selectanother cell of the samefrequency

All UEs are members of one out of ten randomly allocated mobile populations defined as Access Classes 0 to 9. The population number is stored in the SIM. In addition mobiles may be members of one or more out of 5 special categories (Access Classes 11 to 15) also held in the SIM and allocated to specific high priority users as follows (enumeration is not meant as a priority sequence):

Class 15 - PLMN Staff (VIP)

Class 14 - Emergency Services

Class 13 - Public Utilities (for example, water/gas suppliers)

Class 12 - Security Services

Class 11 - For Operator Use

An additional control bit known as "Access Class 10" is also signaled over the air interface to the UE. This indicates whether or not network access for Emergency Calls is allowed for UEs with access classes 0 to 9 or without an IMSI.

Cell status and cell reservations are indicated with the Cell Access Restriction Information Element in the System Information Message (SIB3) by means of four Information Elements:

Cell barred (IE type: "barred" or "not barred")

Cell Reserved for operator use (IE type: "reserved" or "not reserved")

Cell reserved for future extension (IE type: "reserved" or "not reserved")

Intra-frequency cell re-selection indicator (IE type: "allowed" or "not allowed")

The last element (Intra-frequency cell re-selection indicator) is conditioned by the value ”barred“ of the first element (Cell barred)





8 Location Registration





8 Location Registration

8.1 LAC/RAC/SAC

LAC 2

RAC 1

RAC 2

SAC 1

SAC 2

LAC 1

RNClocationAreaCode (FDDCell)routingAreaCode (FDDCell)serviceAreaCode (FDDCell)

Core Network Domains

Sac (FDDCell->CBSResource)

Broadcast Domain

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 thelocationAreaCode parameter of the FDDCell object.

The Location Area Identifier (LAI) = PLMN-id + LAC = MCC + MNC + LAC

Routing Area (RA)The routing area is used by the PS Core Network to determine the UE location in idle mode. A routing area contains a group of cells. Each cell belongs only to one RA.

The routing area is identified by the Routing Area Code (RAC) within the LA. The RAC corresponds to the routingAreaCode parameter of the FDDCell object.

A Routing Area Identifier (RAI) = LAI + RAC = MCC + MNC + LAC + RAC

Core Network Service Area (CN SA)The CN SA is used by the Core Network to determine the UE location in connected mode. A service area contains a group of cells. Each cell belongs only to one CN SA.

The service area is identified by the Service Area Code (SAC) within the LA. The SAC corresponds to the serviceAreaCode parameter of the FDDCell object.

The Service Area Identifier (SAI) = LAI + SAC = MCC + MNC + LAC + SAC.

Broadcast Service Area (BC SA)

The BC SA is used by the Broadcast Center to schedule messages to be broadcast to UEs in the network.

The broadcast (BC) domain requires that BC SA consist of one cell.





Module Summary

This lesson covered the following topics:PLMN selection and associated parameters

Cell selection and associated parameters

Cell reselection and associated parameters

















Section 6Call Admission






9300 W-CDMA · UA06 R99 Algorithms DescriptionCall Admission6 · 2

Blank Page



2009-02-2901

Parameter name correction: maxDlEstablishmentRbRate & maxUlEstablishmentRbRate



Document History





Module Objectives


Describe call establishment and associated parameters

Describe RAB Matching and associated parameters

Describe IRM RAB to RB Mapping and associated parameters

Describe CAC and associated parameters

Describe CELL_FACH admission and associated parameters











Table of Contents


1 Paging 71.1 Paging DRX Cycle 81.2 Paging Repetition 9

2 Access Preambles & Acknowledgment 102.1 Preambles Transmission 112.2 Acknowledgement Transmission 122.3 Preambles Retransmission Parameters 13

3 RRC Connection Establishment 143.1 RRC Connection Setup 153.2 UL Interference CAC on RACH 163.3 QQualMin CAC on RACH 173.4 RRC Connection Rejection 183.5 RRC Speech Redirection 193.6 FACH Power Adjustment 203.7 RRC Connection Setup Repetition 21

4 RAB Matching Principles 224.1 RAB Request vs. UserServices Configuration 234.2 Matching Main Steps 24

5 RAB to RBset Matching & TrCH Type Selection 255.1 Candidate RBset Selection 265.2 Candidate RBset Selection Algorithm: Speech 275.3 Candidate RBset Selection Algorithm : Streaming 285.4 Candidate RBset Selection Algorithm: Interactive/Background 295.5 TrCH Type Selection 30

6 Target RAB Determination 316.1 iRM Selection 326.2 DL IRM Target RB Selection Algorithm 336.3 DL iRM on Radio Link Condition 346.4 DL iRM on Cell Color 356.5 DL Cell Color Calculation 366.6 DL Cell Color/Active Set Color Calculation 376.7 DL Target RB Determination 386.8 DL iRM CEM load parameters 396.9 DL iRM table: example for PS_384K_IB Radio Bearer 406.10 UL iRM Principle 446.11 UL IRM Target RB Selection Algorithm 456.12 UL Radio Load Estimation Without RSEPS: Principles 466.13 UL Load Estimation Without RSEPS : Self-Learning of RTWPref 476.14 UL Load Estimation Without RSEPS: Calculation in NodeB 486.15 UL Load Estimation Without RSEPS : Calculation in RNC 496.16 UL Load Estimation With RSEPS : Calculation in RNC 506.17 UL IRM on Cell Color 516.18 UL Cell Color Calculation 526.19 iRM Target UL RB Rate determination 536.20 UL iRM Radio load parameters 546.21 UL iRM CEM load parameters 556.22 UL iRM table parameters 566.23 UL CAC Principle: non E-DCH Radio Bearer 576.24 iRM CAC for PS Streaming RAB 61

7 Resource Reservation & Admission Control 627.1 UL Radio Load Control 637.2 Transport Resource Reservation 647.3 AAL2 Call Admission Control 657.4 IRM and AAL2 CAC Replay at RB Upgrade or AON Upsize 667.5 DL Reserved Power Computation 67







7.6 DL Power Admission Criteria 687.7 DL Power Self Tuning: Principle 697.8 DL Power Self Tuning: Example 707.9 OVSF Codes Reservation & Admission 71

8 CELL_FACH Admission Control 728.1 CELL_FACH Admission Control 73





1 Paging





1 Paging

1.1 Paging DRX Cycle

Paging for Packet callPaging for Circuit call

DRX

Slot #0 Slot #1 PICH Slot #14

UE

Node B

FDDCell

psDrxCynLngCoef

csDrxCynLngCoef

Slot #0 Slot #1 Slot #14Slot #0 Slot #1 Slot #14

Slot #0 Slot #1 Slot #14Slot #0 Slot #1 Slot #14

Slot #0 Slot #1 PICH Slot #14

When camping normally on a cell, the UE monitors regularly the paging channel. In order to save some energy, a discontinuous reception mode (DRX) is used.

The DRX cycle is defined as the individual time interval between monitoring Paging Occasion for a specific UE. The UE needs only to monitor one Page Indicator (PI) in one Paging Occasion per DRX cycle.

The DRX cycle length is defined as MAX(2k, PBP), where:

PBP is the Paging Block Periodicity and has the fixed value of 1 in UMTS-FDD.

k is an integer and can be specific by Core Network domain.

The value of k is controlled in Alcatel-Lucent’s solution by two parameters, one by Core Network Domain: csDrxCynLngCoef and psDrxCynLngCoef.

Since the UE may be attached to two different domains simultaneously, both DRX cycle length values are calculated and stored in the UE from the values read in the SIB 1 (NAS system information, idle and connected mode timers and counters). Then the UE should keep only the shortest of both values as the DRX cycle length it will use.





1 Paging

1.2 Paging Repetition

RNC

RRC Paging Type 1 (UEx, other UEs)


RRC Paging Type 1 (other UEs)

RRC Paging Type 1 (other UEs)


CoreNetwork

RANAP Paging (UEx)

UEx paging preempteddue to PCH overload (e.g.high paging offered load)

nrOfPagingRepetition


1st retransmission

Initial transmission

nth retransmission

last retransmission

FDDCellSCCPCHPCH

In area of poor radio coverage, it can happen that UE miss paging request what translates into the subscriber missing terminating calls. In order to cope with radio transmission loss, the UTRAN can repeat the paging request so as to increase the probability for the UE to hear it.

Paging repetition is applicable to mobile in idle, CELL_PCH or URA_PCH states.

Alcatel-Lucent implements two algorithms:

Paging Record priority: When several paging records have to be sent at the same paging occasion, the records are sent in the same RRC PAGING message. Nevertheless, if the number of records exceeds the message size (i.e. more than 8 records), then the following priority will apply:

Priority 1: fresh paging record for packet or circuit services (i.e. no difference between the two domains). A fresh paging record is a record which has not been previously sent.

Priority 2: repeated paging record for packet or circuit services (no difference between the two domains).

Limitation of repetitions: nrOfPagingRepetition is the number of time a paging record is repeated. This is a customer configurable parameter.

nrOfPagingRepetition parameter: indicates the number of retransmissions of the paging by UTRAN. Specific value 0 means that the paging will not be repeated (only the “fresh” paging is sent).





2 Access Preambles & Acknowledgment






2.1 Preambles Transmission

PRACHPRACH

prachScramblingCodeprachScramblingCodePreamble

rachsubChannel2

preambleThreshold Preambledetection

RACH preambleThreshold Preambledetection

RACH preambleThreshold Preambledetection

Interference level

RACHno

detection33

Preamble PartWait for Ack ...

Preamble Part

preambleSignature11

Wait for Ack ...Wait for Ack ...

aichTransmissionTiming

55

Ack.

4

Ack.Ack.

4

Message partMessage part

66

AS 0 AS 1 AS 2 AS15AS 0 AS 1 AS 2 AS15

PRACH

FDDCellRACHdetection

UE PRACH use is composed of two parts: the preamble part and the message part. Before transmitting the message part of the preamble, the UE waits for an acknowledgement from the network (on the AICH), confirming that the network has detected the UE.The transmission of the preamble part consists of the repetition of a preamble composed of a 16-chip signature repeated 256 times for a total of 4096 chips.Basically, the UE is assigned one of the 16 possible preambles signature and transmits it at increasing power until it gets a response from the network. The parameter preambleSignature of the RACH object, defines the set of allowed signatures of the PRACH preamble part.The parameter preambleThreshold is defined as the threshold (in dB) over the interference level used for preamble detection in the CEM card.The parameter rachSubChannels defines the set of access slots on which the mobiles are authorized to transmit their access on the PRACH. It defines a sub-set of the total set of uplink access slots.The aichTransmissionTiming parameter of the RACH object defines the timing relation between PRACH and AICH channels.The scrambling code of the PRACH preamble part is defined by the prachScramblingCode parameter of the RACH object.






2.2 Acknowledgement Transmission

PreamblePreamble

Preamble PRACH

aichTransmissionTiming = 0

Transmission of AICH may only start at the beginning of a DL ASTransmission of UL RACH preambles and RACH message parts may only start at the beginning of an UL AS

PRACH

AICH3 TS

3 AS 3 AS

Downlink

AICH

Uplink

PRACH

aichTransmissionTiming = 1

Downlink

AICH

Uplink

PRACH

Preamble

AICH

4 AS 4 AS

5 TS

RACH

The aichTransmissionTiming parameter of the RACH object defines the timing relation between PRACH and AICH channels.

For example when aichTransmissionTiming is set to 1:

The minimum inter-preamble distance tp-p,min = 20480 chips (4 access slots)

The preamble-to-AI distance tpa = 12800 chips (5 time slots)

The preamble-to-message distance tp-m = 20480 chips (4 access slots)

hsiddhar

Sticky Note

1AS=1.5Timeslot 1 Frame= 10 ms 1frame= 2 Time slots 1 slot= .667 micro sec






2.3 Preambles Retransmission Parameters

PREAMBLE #1

PREAMBLE #2

PREAMBLE #N

NB01min (RachTxParameters)

NB01max (RachTxParameters)

Acc

ess

Cycl

e #1

Acc

ess

Cycl

e #2

preambleRetransMax (RACH)

Mmax (RachTxParameters)

PREAMBLE #1

PREAMBLE #N

When a negative answer is received by the UE from the network after a given period, the UE re-sends a preamble at a higher transmission power, so that the Node B can detect it better among the other information received. This “ramping up” process is thus characterized by:

Periodicity of the preamble retransmission: 3GPP (cf. 25.321) has defined two parameters: NB01minand 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 preambleRetransMaxand 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.





3 RRC Connection Establishment






3.1 RRC Connection Setup

RRC Connection Request (Cause)

RNC

RB = ???

DlUserService UlUserService UlRbSetConfDlRbSetConf ServiceInit

RadioAccessService

UserServices

Node B

When the UE attempt to establish an RRC Connection is accepted, the corresponding Signaling Radio Bearers can be supported on two different RRC states and with two different throughputs:

CELL_FACH

CELL_DCH

The parameters which allow selection of the RRC state to support the Signaling Radio Bearers are UlUserviceId for the UL direction, and DlUserserviceId for the DL direction.

The selection of the SRB xxServiceId to accommodate the RRC connection is distinguished by RRC establishment Cause (UserServices instance):

IMSI Detach, Registration, Originating Low Priority Signaling, Originating Low Priority Signaling: SRB_CellFACH

Emergency Call: SRB_3_4K_DCH

Others (normal Originating and Terminating calls): SRB_13_6K_DCH






3.2 UL Interference CAC on RACH

Interference level

Eb/No required

Received Power

UL RTWP

RNC

NBAP Common measurement report

(RTWP)

P-RACH

RTWP < Maximum UL Interference Level

Yes No

Call is accepted Call is rejected

cacConfId (FDDCell) maxUlInterferenceLevel (CacConfClass)

The overall interference level received in a cell is measured with the UL RTWP measurement (Received Total Wideband Power measured at the Node B and forwarded to the RNC).

On RACH reception, before the allocation of the standalone signaling radio bearer, and during the resource reservation phase, the RNC compares the measured RTWP with a fixed value, the 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”.

hsiddhar

Sticky Note

Received total wide band power. For normal case: its value ranges from -102 to -105






3.3 QQualMin CAC on RACH

CPICH Ec/No

Yes No


RNC


Measurement results on RACH IE(CPICH_Ec/No)

P-CPICH

qQualMin

CPICH_Ec/No >= qQualMin

qQualMin (CellSelectionInfo)

P-RACH

rejectBelowQQualMinEnable (ServiceInit)

At reception of RACH message, the RNC checks the CPICH_Ec/No measurement reported by the UE.

If the value is below the qQualMin value defined on the cell, the RNC rejects the RRC Connection Request.






3.4 RRC Connection Rejection


RRC Connection Rejected (cause)


RNC rejects the UE requests

waitTime parameter before UE re-attempt

RNC

RNC Overload

timeReject

(Overload)

CPICH_Ec/No < qQualMin

waitTimeRejectQQualMin

(ServiceInit)

RTWP >= Maximum UL Interference Level

waitTimeOnRrcConnectionRejection

(ServiceInit)

SRB CAC

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”






3.5 RRC Speech Redirection


RRC Connection Rejected (cause)

Redirection IE (Inter-RAT info = GSM)

is3Gto2GConversationalCallRedirectOnRrcEstabFailAllowed (RadioAccessService)

is3Gto2GRedirectForEmergencyAllowed (FDDCell)

RNC

UL Interference CAC Rejection RNC Overload SRB CAC Rejection

IFRRC Establishment Cause = MO Conversational ANDis3Gto2GConversationalCallRedirectOnRrcEstabFailAllowed = TRUEORRRC Establishment Cause = Emergency ANDis3Gto2GRedirectForEmergencyAllowed = TRUE

AND2G neighbor configured

THENinclude Redirection IE in RRC Connection Rejection message

QQualMinCAC Rejection

WaitTime3GTo2GRedirectFailure(FDDCell)

Upon reception of the RRC Connection Request message, the RNC executes the usual RRC Connection Admission Controls.

If failure occurs for SRB assignment, the RNC verifies that some pre-conditions for redirection to GSM are fulfilled.

Then the RRC Connection Reject message contains the Redirection IE with Inter-RAT info set to “GSM”. Note that the RNC is unaware of the UE capabilities at RRC Connection Request time. Therefore, the RNC attempts an RRC Redirection independently of whether the UE supports GSM or the Redirection IE. If the UE supports GSM and the Redirection IE, it will perform inter-system cell reselection and will re-originate the speech call on the 2G network.

All types of MO Conversational calls are redirected to 2G upon admission failure independently of the service type or domain. This includes non-speech calls such as Video Telephony. This is a consequence of the fact that the RRC establishment cause is not able to uniquely identify a CS speech at this early stage of the call progression.

Redirection is not triggered if the UE already has an established RRC connection prior to invoking the MO call request (for example when a PS call is already established).






3.6 FACH Power Adjustment

isFachPowerAdjustmentEnabled (CallAccessPerformanceConf)

isFachPowerAdjustmentActivated (FDDCell)

Feature Activation maxFachPowerRelativeToPcpich (FACH)

initialFachPowerAdjustment

fachTransmitPowerLevelStep

fachPowerAdjustmentCpichEcNoThreshold

fachPowerAdjustmentCpichRscpThreshold

Feature Parameters (FachPowerAdjustmentParams)

second RRC Connection

Setup

third RRC Connection

Setupfirst RRC Connection

SetupP-CPICH all other FACH

messages

Maximum FACHpower

sccpchPowerRelativeToPcpich (SCCPCH)

It is proposed to adjust the FACH power while sending the RRC Connection Setup message based on the CPICH Ec/No measurement received from the RRC Connection Request message. The preferred power setting change is only applied to the FACH frames which carry RRC Connection Setup message. For other messages, RNC should set the power setting level to the nominal value.

Once the FACH power adjustment is required for the first RRC Connection Setup, at every next subsequent repetitions (that is, T351 expiration), the FACH power is further stepped up.

The feature is activated both at the RNC (isFachPowerAdjustmentEnabled) and FddCell level (isFachPowerAdjustmentActivated).

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






3.7 RRC Connection Setup Repetition

UE RNC-IN RNC-CN

RRC Connection Request (TM) (CPICH Ec/No)

RRC Connection SetupRRC Connection Setup (UM)

RRC Connection Setup Complete (AM)

RRC Connection Setup (UM) RRC Connection Setup



t351

t351

t351 / n351 Based Repetition

t351n351

(CallAccessPerformanceConf)

Quick Repeat (CallAccessPerformanceConf)

isQuickPepeatActivated (FDDCell)

isQuickPepeatAllowednumberOfQuickRepeat

deltaCpichEcNoUsedQuickRepeatdeltaCpichRscpUsedQuickRepeat

The RRC Connection Setup message is sent over CCCH/FACH in RLC UM mode. Without its retransmission, the message could be lost over the air due to bad RF conditions. The objective of this feature is to provide the RRC Connection Setup message retransmission functionality if RRC Connection Setup Complete message from the UE has not been received within the duration of T351 timer.

The retransmission of RRC Connection Setup message based on a quicker timer T351 than T300 reduces the call setup duration. By reducing the need of the UE to submit another RRC Connection Request message as a result of the expiry of timer T300, this feature has a positive impact to the RACH capacity.

This feature provides quick repetition functionality of the RRC Connection Setup message without waiting for the acknowledgement from the UE (RRC Connection Setup Complete message).

The quick repetition of the RRC Connection Setup is activated based on the P-CPICH Ec/No measurement received from the RRC Connection Request message reported by the UE. If quality measurements are below a certain threshold, the likelihood of high BLER on the FACH channel is increased, thus reducing the probability of RRC Connection Setup being successfully received by the UE, since it is sent on RLC UM. In order to increase the probability of successful RRC Connection Setup transmission, the message is quick-repeated, that is to say, without waiting for an acknowledgement.





4 RAB Matching Principles






4.1 RAB Request vs. UserServices Configuration

Service RequestRNC Core Network

Service Request

RAB Assignment RequestRB = ???

DlUserService UlUserService UlRbSetConfDlRbSetConf ServiceInit

RadioAccessService

UserServices

Several Access Stratum configurations are supported.

They are split between downlink and uplink and may be dissymmetric.

At the RNC, each access stratum configuration is identified by an access stratum configuration Identifier or UserServiceId. This identifier characterizes a set of radio bearers that are linked through a common radio configuration, including therefore a signaling radio bearer (SRB) and a set of traffic Radio Bearers (RBs).

The objective of the RAB matching algorithm is to translate the RAB parameters specified in the RAB ASSIGNMENT REQUEST received from the Core Network into a pre-defined RAB supported in the RNC.

The requested RAB is matched to the closest RAB provisioned in RNC, using the RAB matching algorithm.






4.2 Matching Main Steps

UE Capability Establishment CauseRequested RAB

Candidate RBSet Selection

UE Capability Check

TrCH Type Selection

IRM Selection (DL)

RBSet List Construction

UserServices Matching

UE Capability Check

Target UserServices

RAB to RBset Matching

RBset to UserServices Matching

Reference UserServices

IRM Selection (UL)

RAB Matching is done at call establishment. For soft handover, only resource reservation and Call Access Control are performed.

The above diagram describes the main steps of the RAB Matching algorithm used.

Step 1: RAB to RBset Matching:

UL & DL RBs are selected according to the RAB Request and stored in a RB set.

this RB list is filtered according to UE capabilities.

Step 2: Transport Channel Type Selection:

DCH or HDSCH in DL, DCH or E-DCH in UL is selected according to the UE and cell capabilities

Step 3: iRM RAB to RB Mapping (DL only):

a DL Target RB is elected among all the selected RBs of the RBset.

Step 4: RBset to User Services Matching:

Target User Services are extracted and explicitly defined from the RBsets.

Reference User Services are extracted and explicitly defined from the RBsets.





5 RAB to RBset Matching & TrCH Type Selection





5 RAB to RBset Matching

5.1 Candidate RBset Selection

UL Candidate RBsetDL Candidate RBset

Core Network


• Maximum Bit Rate• Guaranteed Bit Rate• UMTS Traffic Class• A/R Priority Level• ...

enabledForRABMatching (DlRbSetConf)

enabledForRABMatching (UlRbSetConf)

RNC

UlRbSetConfDlRbSetConf

RadioAccessService

Candidate RBset Selection

DL Reference RB UL Reference RB

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.






5.2 Candidate RBset Selection Algorithm: Speech



Bit Rate (RbSetConf)=

Maximum Bit Rate (RAB Assignment Request )

Bit Rate (RbSetConf)≥

Guaranteed Bit Rate (RAB Assignment Request)


TC =Conversational

Source=Speech

UL Candidate RbSetDL Candidate RbSet

If AMR Multi Mode Allowed

CS_AMR_WB:{12.65k, 8.85k, 6.6k}

CS_AMR_NB:{12.2k, 7.95k, 5.9k, 4.75k}{10.2k, 6.7k, 5.9k, 4.75k}

CS_AMR_LR:{5.9k, 4.75k}{4.75k}

The allocation of bearer for voice call depends if the multi-mode AMR is activated at RNC level:

If Traffic Class = Conversational and Source = Speech (Speech case)

Bit Rate (RbSetConf) = MaxBitRate (rabParam)

Bit Rate (RbSetConf) ≥ Guaranteed Bit Rate (rabParam)

The RNC shall determine the speech bearer according to the AMR activated modes:

CS_AMR_WB: • CS_AMR_NB: • CS_AMR_LR

{12.65k, 8.85k, 6.6k} o {12.2k, 7.95k, 5.9k, 4.75k} o {5.9k, 4.75k}

{12.2k, 7.95k, 5.9k, 4.75k} o {10.2k, 6.7k, 5.9k, 4.75k} o {4.75k}

The following table shows an example of the CS Radio Bearer Table:






5.3 Candidate RBset Selection Algorithm : Streaming




UL Candidate RbSetDL Candidate RbSet

PS_16K_STR

PS_64K_STR

PS_128K_STR

PS_256K_STR

PS_384K_STR

PS_HSDSCH_STR

Traffic Class=

Streaming

Bit Rate (RbSetConf)≥

Guaranteed Bit Rate (RAB Assignment Request)

PS_16K_STR

PS_32K_STR

PS_64K_STR

PS_128K_STR

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






5.4 Candidate RBset Selection Algorithm: Interactive/Background



Traffic Class=

Interactive/Background

Bit Rate (RbSetConf)≤

Maximum Bit Rate (RAB Assignment Request)


UL Candidate RbSet

DL Candidate RbSet

Example

• CS MaxBitRate = 12.2k• PS MaxBitRate = 384k• CS Speech + PS I/B• A/R Priority Level = 2• ...

Candidate RBset SelectionDL Candidate RbSet

• PS 384K (Ref.)• PS 256K •PS 128K• PS 64K• PS 32K• PS 16K• PS 8K• CS 12.2k (Ref.)

UL Candidate RbSet

• PS 128K• PS 64K• PS 32K• PS 16K• PS 8K•CS 12.2k (Ref.)

UE Capability Check

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

It is eligible to RbSet Matching (Parameter EnabledForRabMatching)

The Traffic Class corresponds to the requested Traffic Class and:

If Traffic Class = Conversational and Source = Speech (Speech case)

Bit Rate (RbSetConf) = MaxBitRate (rabParam)


If Traffic Class = Streaming


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.






5.5 TrCH Type Selection

Based on UE Category, not based on Core network infoCell

UER’99 R5 R6

Conv. DCH Conv. DCH Conv. DCH

STR DCH STR DCH STR DCH

I/B DCH I/B DCH I/B DCH


STR DCH STR HS-DSCHDCH

STR HS-DSCHDCH

I/B DCH I/B HS-DSCHDCH I/B HS-DSCH

DCH


STR DCH STR HS-DSCHDCH STR HS-DSCH

DCH

I/B DCH I/B HS-DSCHDCH

I/B HS-DSCHE-DCH

R’99

R5

R6

This step aims to perform the transport choice decision:

DCH,

HSxPA,

FACH.

The decision is taken according to several rules:

CS RAB is always established on a DCH Channel;

For a R5 UE (HSDPA capable), the downlink PS I/B RB is preferred on HSDPA;

For a R5 or R6 UE (HSDPA & HSUPA capable), the downlink PS Streaming RB is preferred on HSDPA if streaming on HSDPA is activated;

For a R6 UE (HSDPA & HSUPA capable), the downlink PS I/B RB is preferred on HSDPA, and the uplink PS I/B RB is preferred on HSUPA.





6 Target RAB Determination






6.1 iRM Selection

RAB to RBset Matching (UL/DL)

DL iRM

RBset to UserServices Matching (UL/DL)

Resource Reservation&

Admission Control

Reference UL bit rate

iRM Target UL RB bit rate

Target RAB (DL/UL)

Reference DL bit rate

iRM Target DL RB bit rate

UL iRM

UL bit rate limitationIf maxUlEstablishmentRbRate > Target UL RB bit rateThen Initial UL RB bit rate = Target UL RB bit rateElse Initial UL RB bit rate = maxUlEstablishmentRbRate

DL bit rate limitationIf maxDlEstablishmentRbRate > Target DL RB bit rateThen Initial DL RB bit rate = Target DL RB bit rateElse Initial DL RB bit rate = maxDlEstablishmentRbRate

iRM Tables

Requested RAB

isUlRbRateAdaptationAllowed(RadioAccessService)

maxUlEstablishmentRbRate(CacConfClass)

isDlRbRateAdaptationAllowed(RadioAccessService)

maxDlEstablishmentRbRate(CacConfClass)

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 deternimationBesides:RB adaptation based on traffic is a feature introducing PS I/B RB bit rate downsizing/upsizing based on user estimated average throughput.

DL and UL rate adaptation are performed independently.In UL and/or DL an initial RB Rate Adaptation can be performed at RAB establishment to admit a user at a configurable low bit rate.

Consequently the allocated UL PS RB bit rate and/or UL PS RB bit rate is limited at RAB Establishment, even if the user is requesting more. Once the RAB established, it may be possible to upsize the RB to UL PS 384 kbps if needed thanks to RB Adaptation.

The parameter maxUlEstablishmentRbRate (resp. maxDlEstablishmentRbRate) specifies the maximum UL rate (resp. 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 (resp. isDlRbRateAdaptationAllowed) of RadioAccessService object is set to True.

(*)The downlink iRM is based on the evaluation of:The Radio Link of the primary cell, based on CPICH Ec/N0 and CPICH RSCP reported in the RRC Measurements that indicates the radio conditions. This condition determines a maximum available bitrate to guaranty a certain quality.The cell load, based on the Downlink OVSF code tree and/or the downlink power used versus the available power.The nodeB load, based on the Iub bandwidth, and the remaining downlink CEM processing capacity The uplink iRM is based on the evaluation of:The uplink radio load, based on RSSI at antenna levelThe nodeB load, based on the remaining uplink CEM processing capacity






6.2 DL IRM Target RB Selection Algorithm

DL Cell Color

Code LoadPower LoadIub LoadCEM Load

Radio Link Color

DL RL Quality

Olympic Service Level

DL Candidate RbSet

(Ref.)

DL Candidate RbSet

(Ref.)

(Target)

BronzeBronze

GoldGoldSilverSilver

DL IRM Tables

4

3

2

1

5

This step is applied only in the downlink.

The DL iRM Target RB selection algorithm is based on:

UE radio conditions based on CPICH Ec/No and CPICH RSCP reported in the RRC Measurements that indicates the radio conditions.

The two colors Green and Red represent respectively good radio conditions and bad radio conditions.

cell load through cell color computation from the downlink OVSF code tree occupancy, the downlink power used versus the available power, the Iub load and the CEM processing load (D-BBU load).

The three colors (green, yellow and red) are distinguished, green color meaning that the cell is not loaded, and red color indicating a loaded cell.

OLS (Olympic Service Level is either Gold or Silver or Bronze arrording to the Allocation/Retention Priority IE provided in the RAB ASSIGNMENT REQUEST message).

Once computed, the target downlink radio bearer is flagged as Target Radio Bearer.






6.3 DL iRM on Radio Link Condition

Bad RL Condition

Good RL Condition

Then

isIrmOnRlConditionAllowed(RadioAccessService)

Yes

Else

irmDlPowerThreshold (IrmOnRlConditionParameters)- CPICH_Ec/No < If

irmDlcoverageThreshold (IrmOnRlConditionParameters)CPICH_RSCP >

And

No?

dlRbSetConfId(IrmOnRlConditionParameters)

cacConfId (FDDCell) cacConfId (FDDCell)

Good RL Condition

fallbackRbRate (DlRbSetConf)

iRM Target RB selection shall be limited to fallBackRbRate in case of bad UE radio conditions in order to reduce RLC re-transmissions and guarantee a minimum level of throughput.

Radio Link conditions are assessed from RRC measurements reported by UE.

Link color calculation is based on the following algorithm:

if (-CPICH Ec/N0 primary < IRMDlPowerThreshold) and (CPICH RSCP > IRMDlCoverageThreshold)

then link color = GREEN

else link color = RED

DL iRM Target RB bit rate shall be limited to fallBackRbRate if radio link color is RED, otherwise no limitation is requested.

Note:

During transition from cell FACH state to Cell DCH state, CPICH RSCP is not reported by the UE, therefore:

the coverage criterion (IrmDlCoverageThreshold) is ignored.

the Radio link color evaluation is then based only on CPICH Ec/No measurements as reported on the last RACH message.






6.4 DL iRM on Cell Color

Specific CE capacity Credit calculation andCE consumption laws

for xCEM

Code Color Power Color

FDDCell Color

DL IRM Tables

Yes

No? FDDCell Color = GreenisIrmOnCellColourAllowed(RadioAccessService)

isDlIubTransportLoadColourCalculationEnabled(RadioAccessService)

cellColor (IubTransportFlowControl)

?

DL Cell Color

YesNoIub Color = Green

NodeB Color

Iub Color CEM Color

isCEMColourCalculationEnabled(RadioAccessService) ?

Yes

NoCEM Color = Green

RAB allocation management is based on FDDcell color and NodeB color.

FDDCell color is derived from a load calculation based on OVSF tree and DL power occupancy.

NodeB color is derived from a Iub bandwidth occupancy and CEM processing load

Hence it provides means for a better management of cell resources.

At each allocation/release/reconfiguration of resources, the RNC calculates current:

code color based on OVSF code tree occupancy load

power color based on DL cell power usage

Iub color based on VCC allocated on Iub

CEM load based on credits usage

Then a composite Cell color is derived which is an input to iRM table.

CEM load is not only used in iRM CAC algorithm. Therefore if CEM load criteria is not to be used in iRM CAC although CEM load is being computed for iMCTA feature, then:

isCEMColourCalculationEnabled parameter has to be set to TRUE

isCEMModelValidForDlColour parameter has to be set to FALSE

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






6.5 DL Cell Color Calculation

green2YellowCLCThreshold(IrmOnCellColourParameters)

yellow2RedCLCThreshold(IrmOnCellColourParameters)

yellow2GreenCLCThreshold(IrmOnCellColourParameters)

red2YellowCLCThreshold(IrmOnCellColourParameters)

70 %

60 %50 %

40 %

green2YellowPLCThreshold(IrmOnCellColourParameters)

yellow2RedPLCThreshold(IrmOnCellColourParameters)

yellow2GreenPLCThreshold(IrmOnCellColourParameters)

red2YellowPLCThreshold(IrmOnCellColourParameters)

70 %

60 %50 %

40 %

green2YellowDlCEMThreshold(DlIrmCEMParameters)

yellow2RedDlCEMThreshold(DlIrmCEMParameters)

yellow2GreenDlCEMThreshold(DlIrmCEMParameters)

red2YellowDlCEMThreshold(DlIrmCEMParameters)

90 %

80 %70 %

60 %

Power Load

CEM Load

Worst DL Cell Color

green2YellowDlTLCThreshold(IrmIubTransportLoadParameters)

yellow2RedDlTLCThreshold(IrmIubTransportLoadParameters)

yellow2GreenDlTLCThreshold(IrmIubTransportLoadParameters)

red2YellowDlTLCThreshold(IrmIubTransportLoadParameters)

90 %

80 %70 %

60 %

Iub Load

Code Load

NOTE: The values provided here for the different Power load, Code load, Iub load and CEM load are just examples. They are neither Alcatel-Lucent default values nor recommended values as those ones are driven by the configuration of NodeB and cell and by the operator strategy as a trade-off between capacity (number of simultaneous users) and quality (throughput for PS service).

Indeed:

Code load thresholds setting is driven by the code capacity of the cell for DCH traffic which depends on the number of S-CCPCH channels configured, on the fact that the cell might also carry HSDPA traffic, and in that case on the Dynamic Code Tree Management feature activation.

Power load thresholds setting is driven by the power capacity of the cell for DCH traffic which depends on the usage of OCNS, and on the power reserved for HSDPA.

Iub load thresholds setting is driven by the Iub bandwidth capacity of the BTS which depends on the number of E1 links equipped, the IMA activation and the CAC method used.

CEM load thresholds setting is driven by the CEM capacity of the BTS which depends on the type and number of CEM boards equipped, on the number of Local Cell Group configured and on the DBBU Frequency Pooling activation (dbbuPoolMode parameter).

CEM color in DL is calculated by the iRM mechanism comparing the DL CEM load estimation (expressed in percent) with the different CEM DL load thresholds configured at OAM

Once computed, the CEM color is applied to all the cells of a BTS, cells belonging to the same Local Cell Group.






6.6 DL Cell Color/Active Set Color Calculation

Code Color

Power Color

Worst

Cell 1

Cell N

Worst

Active Set Color

Red

Green Yellow

+ =+ =+ =

Worst

Cell Color

Red

Green Yellow

Cell Color

Red

Green Yellow

Worst

Iub Color

Cell load color calculation

This block allows code, power and Iub occupancy to be taken into account in the calculation of cell color.

The cell load color is calculated as follows:

cell load color = Worst (radio load color, iub load color)

radio load color = Worst (code load color, power load color)

Active set cell load color calculation

When the call is in soft handover, the color taken into account is the active set color defined as the worst color between the colors of the cells present in the active set. The active set load color is calculated as follows:

active set color = Worst (cell(i) color, i Є [1..N])

where cell(i) is the cell of the active set and N is the active set size.






6.7 DL Target RB Determination

Radio Link Color

BronzeBronze


+

PSCore

SRNC

RAB Assignment Request Reference RB Bit Rate

iRMRbRate

DL Cell Color

OLS

fallBackRbRate MIN Target RB Bit Rate

Traffic classDL Maximum Bit RateAllocation/Retention Priority Level

The RAB to RB mapping function consists of defining the target RB Set that will replace the Reference RB.

For each triplet {DlRbSetConf, OLS, CellColor} an iRMRbRate parameter is defined in a DL iRM Table:

DL iRM RB Selection is choosing as Target RB bit rate the minimum between

Reference RB bit rate deduced from CN requirements

Eventual fallBackRbRate is UE in bad radio conditions

iRMRbRate given by DL iRM Tables

64128384Bronze

64128384Silver

64128384Gold

Cell Colour = Red

Cell Colour = Yellow

Cell Colour = Green

DlIrmTable

OLS

64128384Bronze

64128384Silver

64128384Gold

Cell Colour = Red


Cell Colour = 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






6.8 DL iRM CEM load parameters

defaultDlIrmCellColour

isCEMColourCalculationEnabled

iRMRbRate

green2YellowDlCEMThresholdyellow2RedDlCEMThresholdred2YellowDlCEMThreshold

yellow2GreenDlCEMThreshold

RNC

NodeB RadioAccessService

DedicatedConf DlIrmTableConfClass

IrmRbRateList

IrmRbRateEntry

1..15

3

3

DlIrmCEMParameters

nodeBConfClassId

1..15

isCEMModelValidForDlColourdlCEMColourDefaultValue

NodeBConfClass

dlIrmTableConfClassId

fallBackRbRate

DlRbSetConf

NeighbouringRnc






6.9 DL iRM table: example for PS_384K_IB Radio Bearer

PS_256K_IB

PS_ 256K_STR

PS_128k_IB

PS_128K_STR

PS_128k_IB_MUX

PS_384K_IB_MUX

PS_384K_IBDlRbSetConfDlRbSetConf

IrmRbRateEntry IrmRbRateList Instance

Instance iRMRbRate

0 OLS = Gold 384

1 OLS = Silver 384 /0 Cell Color = Green

2 OLS = Bronze 384

0 OLS = Gold 128

1 OLS = Silver 128 /1 Cell Color = Yellow

2 OLS = Bronze 128

0 OLS = Gold 64

1 OLS = Silver 64 /2 Cell Color = Red

2 OLS = Bronze 64





Exercise : iRM DL

AssumptionshsdpaActivation (FDDCell) = FalseenabledForRabMatching (any DlRbSetConf) = TrueisIrmOnRlConditionAllowed (RadioAccessService) = TrueirmDlPowerThreshold (IrmOnRlConditionParameters) = 15dBirmDlCoverageThreshold (IrmOnRlConditionParameters) = -100dBmfallBackRbRate (PS_384K_IB) = 64kbpsisIrmOnCellColourAllowed (RadioAccessService) = Truegreen2YellowCLCThreshold (RadioAccessService) = 70%yellow2GreenCLCThreshold (RadioAccessService) = 60%yellow2RedCLCThreshold (RadioAccessService) = 90%red2YellowCLCThreshold (RadioAccessService) = 80%green2YellowPLCThreshold (RadioAccessService) = 60%yellow2GreenPLCThreshold (RadioAccessService) = 50%yellow2RedPCLCThreshold (RadioAccessService) = 80%red2YellowPCLCThreshold (RadioAccessService) = 70%isDlIubTransportLoadColourCalculationAllowed (RadioAccessService) = Truegreen2YellowDlTLCThreshold (RadioAccessService) = 70%yellow2GreenDlTLCThreshold (RadioAccessService) = 60%yellow2RedDlTLCThreshold (RadioAccessService) = 90%red2YellowDlTLCThreshold (RadioAccessService) = 80%





Exercise : iRM DL [cont.]

AssumptionsisCEMColourCalculationAllowed (RadioAccessService) = TrueisCEMModelValidForDlColour (nodeBConfClass) = Truegreen2YellowDlCEMThreshold (RadioAccessService) = 80%yellow2GreenDlCEMThreshold (RadioAccessService) = 80%yellow2RedDlCEMThreshold (RadioAccessService) = 90%red2YellowDlCEMThreshold (RadioAccessService) = 90%

64128384Bronze

64128384Silver

64128384Gold

Cell Colour = Red


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_IBDlRbSetConfDlRbSetConf





Exercise : iRM DL [cont.]

Question: Find the iRM Target DL RB Rate ?

NodeB

PSCore

SRNC

RAB Assignment RequestTraffic class = BackgroundDL Maximum Bit Rate = 2048000UL Maximum Bit Rate = 128000Allocation/Retention Priority Level = 1

Radio Link

Iub

R5 UE CPICH_EcNo = -5dBCPICH_RSCP = -89dBm

Code load = 60%Power load = 50%Iub load = 60%CEM load = 85%






6.10 UL iRM Principle

UL load (%) UL RSSI

Cell is Green

Cell is Yellow

Cell is Red

Speech

UL384

Speech

UL384

UL384

UL128

Speech

UL384

UL384

UL128

Speech

UL384

UL384

UL128

UL64

…

green2yellow

yellow2red

UL64

time

UL iRM goal is to provide a good trade-off between the cell capacity and the QoS in uplink. This is achieved through the choice of PS UL RB Bit Rate according to uplink cell load.

When UL cell load is low, the UTRAN allocates radio resources to the user in order to provide the best QoS, means the best uplink throughput.

When UL cell load increases, the UTRAN reduces the allocated radio resources of PS RB established for new users. The goal is to avoid blocking in UL.






6.11 UL IRM Target RB Selection Algorithm

CEM Load

Olympic Service Level

UL Candidate RbSet

(Ref.)

UL Candidate RbSet

(Ref.)

(Target)

BronzeBronze


UL IRM Tables

4

2

1

5

Radio Load

UL Radio Load3

Worst UL Cell Color

The aim of UL iRM CAC is to provide the operator means to manage efficiently I/B and streaming RABs on R99 resources as a function of:

traffic conditions (through radio load color evaluated by the RNC thanks to Noise Rise estimated by the NodeB and reported to the RNC)

CEM load (through CEM color)

OLS (Olympic Service Level is either Gold or Silver or Bronze arrording to the Allocation/Retention Priority IE provided in the RAB ASSIGNMENT REQUEST message).

Further reconfiguration can be triggered either by DL related events or by the UL RAB adapt feature.

This feature provides the operator with the best trade-off in term of offered QoS and NodeB/Cell available resources.

This minimizes blocking and call drops.






6.12 UL Radio Load Estimation Without RSEPS: Principles

Thermal Noise

CS12.2

CS12.2

PS64

CS64

NodeB NF

E-DCH load

Max allowed UL load

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

2

4

6

8

10

12

14

16

18

20

UL load (%)

Noise Rise vs. UL load

Acceptable Max load

RTWPnon E-DCH

RTWPref

RoTnon E-DCH

NodeB CRNC

Common Measurement ReportRTWP= -106.1 + RoTnon E-DCH

Noi

se R

ise

(dB)

= R

oT

RoTmax

RoTnon E-DCH (dB) = RTWP + 106.1

UL Radio Load (%) = 1 – 10-(RoTnon E-DCH

/10)

isNbapCommonMeasRsepsAllowed (NodeB) = False

isRtwpAdjustmentForRnc (BTSEquipment) = True

The way to control the Uplink traffic QoS is to maintain the UL load under fixed level.

The current absolute UL RTWP (i.e. Received Total Wideband Power) as defined in the 3GPP cannot be measured with enough accuracy (+/- 4 dB). Indeed it depends on the temperature and the site conditions. It is therefore varying in time.

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

Therefore in order to improve the accuracy of the R99 UL CAC algorithm, the NodeB provides the RNC with the Rise over the varying Thermal noise (RoT) corresponding to the Noise Rise induced by the UL R99 traffic.

As the measurement provided by the NodeB in the Common Measurement Report should be the RTWP expressed in dBm, the NodeB adds to the actual RoT a fixed reference value equal to –106.1dBm.

The UL load should be monitored in order not to overload the system. It should be kept lower than a fixed threshold to keep the system stable.

The UL load estimation is required for correct E-DCH scheduling and efficient UL iRM CAC.

The thermal noise should be well estimated in order to compute the UL load.






6.13 UL Load Estimation Without RSEPS : Self-Learning of RTWPref

No? RTWPref = -106.1 dBmisRtwpReferenceSelfLearning(BTSEquipment)

rtwpReference(BTSCell)

Yes

RTWPref,0 = -106.1dBmRTWP when no traffic

++ +

++++

+ + + +

++++++

++++++

+++

+++++

++++

++++++

+++ + + + ++ + +

+++

++

++++

++

++

++++ +++

+++ ++++++ ++

++++ +++++

++

++++

Day n-1

RTWPref,n-1 RTWPref,n = -105.4 dBm

Day n Day n+1time

-105.4dBm

The RTWP reference value (called RTWPref) should correspond to the minimum value of RTWP values received in the cell when there are no connections in the Node B.

During the learning time (24hours), the Node B keeps the RTWPcur values measured (filtered by L3 filtering- param sent by the RNC) if no traffic in the Node B.

Please note that the first learning cycle is faster than 24 hours.






6.14 UL Load Estimation Without RSEPS: Calculation in NodeB

E-DCH load

No?isUplinkRadioLoadEnabled(RadioAccessService)

Yes

Thermal Noise

CS12.2

CS12.2

PS64

CS64

NodeB NF

RTWPnon E-DCH

RTWPref

RoTnon E-DCH

RTWPcur

Radio Load Color = Green

RTWPnon E-DCH = RTWPcur – RTWPE-DCH

RoTnon E-DCH = RTWPnon E-DCH - RTWPref

RTWPE-DCH

The non E-DCH load is obtained by subtracting this computed E-DCH load from the total RTWP.

For each E-DCH connection the SIR will be estimated in function of the SIR on UL DPCCH and the gain factors. These SIR are cumulated and then the contribution of E-DCH to the current total RTWP is estimated.

Note that the E-DCH traffic that belongs to other cells is included in the non E-DCH RTWP measurement.

The total RTWPcur is the average between the two RX diversity branches if any.






6.15 UL Load Estimation Without RSEPS : Calculation in RNC

Common Measurement Initiation Request

CRNC

NodeB Measurement Type = RTWPReporting Mode = Periodic

Report Periodicity = nbapCommonMeasRtwpReportingPeriodFilter Coefficient = nbapCommonMeasRtwpFilterCoeff

Common Measurement Reportn-1

nbapCommonMeasRtwpReportingPeriod(NbapMeasRtwpParameters)

nbapCommonMeasRtwpFilterCoeff(NbapMeasRtwpParameters)

RTWP = -106.1 + RoTnon E-DCH, n-1

nbapCommonMeasRtwpReportingPeriod

No?isNbapCommonMeasRtwpAllowed(NodeB) Radio Load Color = Green

UL Radio Load = 1 – 10-(RoTnon E-DCH

/10)

UL Radio Loadn-1

Common Measurement Reportn UL Radio Loadn

The activation of UL RTWP measurement is not linked to the UL Load feature.

NBAP Common Measurements are activated at cell setup whatever the value of the parameter isNbapCommonMeasRtwpAllowed.

There is no way to put measurement off. Therefore, there is no need to lock / unlock any cell to activate NBAP Common Measurement.






6.16 UL Load Estimation With RSEPS : Calculation in RNC

With this measurement : no more need to adjust the RTWP Measurement at BTS to report the Non-Edch RoT

The RNC computes the Non-Edch load for iRM UL load

UL Radio Load (%) = Non_Edch_UL_load = Total_UL_Load - RSEPS[ratio]

Where:

Total_UL_Load (%) = 1 - 10^( - Total_RoT / 10)

Total_RoT [dB] = Total RTWP[dBm] – Reference RTWP[dBm]

isNbapCommonMeasRsepsAllowed (NodeB) = True

Common Measurement Reports (Total RTWP, Reference RTWP)

C-RNCCommon Measurement Initiation Request (Total RTWP, Reference RTWP)

Common Measurement Initiation Request (Received Scheduled Edch Power Share)

Common Measurement Reports (EDCH power ratio)

When the RSEPS measurements are activated

The RNC configures NBAP common measurements to report periodically

Total RTWP

Reference RTWP

The RNC configures RSEPS (Received Scheduled Edch Power Share) measurements

To report the Edch power ratio

WARNING: if RSEPS are activated the #303 UL_RSSI counter is giving the total RTWP whereas in UA5 it is corresponding to “-106.1dBm + RoT_non_Edch”.






6.17 UL IRM on Cell Color

UL IRM Tables

Radio Load Color

CEM Color

Yes

No

?

Cell Color = Green

isUlIrmOnCellColourAllowed(RadioAccessService)

UL Cell Color

CEM Color = Green

isUplinkRadioLoadEnabled(RadioAccessService)

isNbapCommonMeasRtwpAllowed(NodeB)

isUlRadioLoadColourEnabled(NodeBConfClass)

Radio Load Color = Green

?Yes

No

isCEMColourCalculationEnabled(RadioAccessService)

Yes ?

Yes

No

As any other, the CEM load criteria can be used or not thanks to the isCEMColourCalculationEnabledparameter.

But CEM load is not only used in iRM CAC algorithm. Therefore if CEM load criteria is not to be used in iRMCAC although CEM load is being computed for iMCTA feature, then:

isCEMColourCalculationEnabled parameter has to be set to TRUE

isCEMModelValidForUlColour parameter has to be set to FALSE

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

hsiddhar

Sticky Note

It is False in MP






6.18 UL Cell Color Calculation

green2yYellowUlRadioLoadThreshold(UlIrmRadioLoadParameters)

yellow2RedUlRadioLoadThreshold(UlIrmRadioLoadParameters)

yellow2GreenUlRadioLoadThreshold(UlIrmRadioLoadParameters)

red2yYellowUlRadioLoadThreshold(UlIrmRadioLoadParameters)

70 %

60 %50 %

40 %

green2yYellowUlCEMThreshold(UlIrmCEMParameters)

yellow2RedUlCEMThreshold(UlIrmCEMParameters)

yellow2GreenUlCEMThreshold(UlIrmCEMParameters)

red2yYellowUlCEMThreshold(UlIrmCEMParameters)

90 %

80 %70 %

60 %

CEM Load

Worst

Radio Load

UL Cell Color

CEM color in UL is calculated by the iRM mechanism comparing the UL CEM load estimation (expressed in percent) with the different CEM UL load thresholds configured at OAMOnce 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).






6.19 iRM Target UL RB Rate determination

BronzeBronze


+

PSCore

SRNC

RAB Assignment Request Reference RB Bit Rate

iRMRbRate

Cell Color

OLS

MIN Target RB Bit Rate

Traffic classUL Maximum Bit RateAllocation/Retention Priority Level






6.20 UL iRM Radio load parameters

RNC

nodeBConfClassId

1..15

isUllRadioLoadColourEnabled

rtwpReference

isUplinkRadioLoadEnabled

nbapCommonMeasRtwpReportingPeriodnbapCommonMeasRtwpFilterCoeff

1..15

green2yellowUlRadioLoadThresholdyellow2redUlRadioLoadThresholdred2yellowUlRadioLoadThreshold

yellow2greenUlRadioLoadThreshold

localCellId

1..15

NbapMeasRtwpFilterCoeff

MeasurementConfClassNodeBConfClassCacConfClass

UlIrmRadioLoadParameters

BTSCell

RadioAccessService

DedicatedConf

isRtwpReferenceSelfLearningisRtwpAdjustmentForRnc

BTSEquipmentisNbapCommonMeasRtwpAllowedisNbapCommonMeasRsepsAllowed

NodeB

localCellId

FDDCell

cacConfClassId

defaultUlIrmCellColour

NeighbouringRnc






6.21 UL iRM CEM load parameters

isCEMColourCalculationEnabled

green2YellowUlCEMThresholdyellow2RedUlCEMThresholdred2YellowUlCEMThreshold

yellow2GreenUlCEMThreshold

RNC

NodeB

RadioAccessService

DedicatedConf

UlIrmCEMParameters

nodeBConfClassId

1..15

isCEMModelValidForUlColourulCEMColourDefaultValue

NodeBConfClass






6.22 UL iRM table parameters

RNC

RadioAccessService

iRMRbRate

UlIrmTableConfClass

IrmRbRateList

IrmRbRateEntry

1..15

3

3

ulIrmTableConfClassId UlRbSetConf

ExampleUlRbSetConfId = PS_384K_IB

IrmRbRateEntry IrmRbRateList Instance

Instance iRMRbRate

0 OLS = Gold 384

1 OLS = Silver 384 /0 Cell Color = Green

2 OLS = Bronze 384

0 OLS = Gold 128

1 OLS = Silver 128 /1 Cell Color = Yellow

2 OLS = Bronze 128

0 OLS = Gold 64

1 OLS = Silver 64 /2 Cell Color = Red

2 OLS = Bronze 64






6.23 UL CAC Principle: non E-DCH Radio Bearer

UL loadnon E-DCH (%)

Cell is Green

Cell is Yellow

Cell is Red

UL128

Speech

UL128

UL128

UL128

UL64

green2yellow

yellow2red

UL64

time

rtwpMaxCellLoadNonEdch(BTSCell)

UL128

Speech

UL128

UL128

UL128

UL64

UL64

accepted

UL128

Speech

UL128

UL128

UL128

UL64

UL64

accepted

accepted

UL128

Speech

UL128

UL128

UL128

UL64

UL64

accepted

accepted

rejected

rtwpMaxCellLoadCacActivation(BTSCell)

NodeB hardware resources are usually properly dimensioned to process the achievable cell rate however there are some scenarios where the bottleneck is not the NodeB available resources but the UL radio interference radio induced by the traffic.

In this latter case admitting new calls or reconfiguring some of the ongoing calls with higher rates will create too much Multi Access Interference (MAI) and consequently decrease the Radio Links quality and Cell Breathing.

It is better in this case to reject such a RL establishment.

The improvement of the CAC is achieved by taking into account the current UL Load, if it has reached a certain value no new RL is admitted.

Two thresholds are defined:

Max RTWP for total UL traffic (R99+E-DCH): totalRotMax

Max RTWP for non E-DCH traffic only used for R99 CAC: rtwpMaxCellLoadNonEdch

The Node B performs a very basic CAC without considering the cost of the link to be established/reconfigured/released.

It compares the current UL load for non E-DCH calls to the rtwpMaxCellLoadNonEdch configurable threshold parameter.

In case this UL load is lower or equal, it is admitted, otherwise it is rejected.

The non E-DCH UL load CAC threshold is configured in %.

As non E-DCH traffic is lower or equal to the total UL traffic (R99+E-DCH), the non E-DCH maxload should be lower or equal to the total max load the following parameter rule should be fulfilled:

rtwpMaxCellLoadNonEdch <= 1 – 1/10(totalRotMax/10)

rtwpMaxCellLoadCacActivation is used to activate the UL CAC on non-EDCH traffic at BTS based on the RTWP.

rtwpMaxCellLoadNonEdch is used only if rtwpMaxCellLoadCacActivation is set to TRUE.





Exercise : iRM UL

AssumptionsedchActivation (FDDCell) = FalseenabledForRabMatching (any UlRbSetConf) = TrueisUlIrmOnCellColourAllowed (RadioAccessService) = TrueisUplinkRadioLoadEnabled (RadioAccessService) = TrueisUllRadioLoadColourEnabled (NodeBClonClass) = Truegreen2YellowUlRadioLoadThreshold (RadioAccessService) = 40%yellow2GreenUlRadioLoadThreshold (RadioAccessService) = 40%yellow2RedUlRadioLoadThreshold (RadioAccessService) = 45%red2YellowUlRadioLoadThreshold (RadioAccessService) = 45%isNbapCommonMeasRtwpAllowed (RadioAccessService) = TrueisRtwpReferenceSelfLearning (BTSEquipment) = TruertwpReference (BTSCell) = -106.1dBmisCEMColourCalculationAllowed (RadioAccessService) = TrueisCEMModelValidForUlColour (nodeBConfClass) = Truegreen2YellowUlCEMThreshold (RadioAccessService) = 80%yellow2GreenUlCEMThreshold (RadioAccessService) = 80%yellow2RedUlCEMThreshold (RadioAccessService) = 90%red2YellowUlCEMThreshold (RadioAccessService) = 90%





Exercise : iRM UL [cont.]

Assumptions

64128384Bronze

64128384Silver

64128384Gold

Cell Colour = Red


Cell Colour = Green

UlIrmTable

OLS

PS_128K_STR

PS_128k_IB

PS_128k_IB_MUX

PS_256K_IB

PS_384K_IB_MUX

PS_384K_IBUlRbSetConfUlRbSetConf





Exercise : iRM UL [cont.]

NodeB

PSCore

SRNC

RAB Assignment RequestTraffic class = BackgroundDL Maximum Bit Rate = 2048000UL Maximum Bit Rate = 384000Allocation/Retention Priority Level = 1

UL Radio Load

Iub

Question: Find the iRM Target UL RB Rate ?

R6 UECEM load = 65%

Com

mon

Mea

sure

men

t Re

port

RTW

P=

-103

.7dB

m

hsiddhar

Sticky Note

128kpps






6.24 iRM CAC for PS Streaming RAB

PS Streaming RAB request

iRM

Candidate RB selection

MIB

PS Streaming RB

OLS RL colour

Cell colour

(MBR, GBR)

GBR < RB bit rate < MBR

Target RB bit rate < GBR ?

RB bit rate >= GBR

CAC

Yes

No

PS_16K_STRPS_64K_STR

PS_128K_STR

PS_256K_STRDlRbSetConfDlRbSetConf

Alcate-Lucent implements PS streaming Radio Bearers (RB) since UA4.1. Support of Streaming RB allows operators to differentiate streaming traffic from best effort traffic (i.e. Interactive and Background traffic) at the transport level (e.g. Iub) or at RRM level, therefore providing streaming service of a superior quality compared to when I/B RB are used.

When speaking about streaming quality, another important parameter is the rate at which the streaming content has been encoded. For example, it is generally acknowledged that high quality video streaming on mobile device requires data rate of around 100kbps, and potentially more. As a matter of fact, high quality streaming content requires to introduce higher streaming RB bit rate such as 128 kbps or even 256 kbps. PS128kbps has been introduced in UA4.2 and PS256kbps is introduced in UA5.

Since high bit rate RB are radio resources consuming, enhanced RRM is required to optimize radio resources usage.

iRM CAC: same as for PS I/B RAB except that the allocated RB must be of a Bit Rate greater or equal to the Guaranteed Bit Rate required by the SGSN for the PS Streaming RAB





7 Resource Reservation & Admission Control






7.1 UL Radio Load Control

isUlTokenCacAtRncAllowed (RadioAccessService)

ulCostForUlTokenCac (UlUserService)

Established RLsUL Cost

New RLUL Cost

RNC

UL Cost < UL Capacity Threshold

Yes No


PS 384 UEI

PS 128 UEJ

PS 128 UEK

PS 128 UEK

UL Cost(FDDCell)

ulCapacityThresholdForUlTokenCac(FDDCell)

Uplink radio admission control for high data rate calls has been introduced together with the UL PS384 RAB in order to enable an uplink call admission control mechanism and thus avoid UL congestion.

Lab tests show that in ideal radio conditions three PS I/B 384 generate a noise rise higher than 3 dB (corresponding to 50% of UL Load). Beyond 75% load the system is no longer stable and it could lead to significant neighboring cell interference, cell coverage reduction and mobiles dropping calls.

The solution is to define a cost per UL RAB and a total UL capacity threshold. This cost can be tuned per UL PS RB bit rate thanks to ulCostForUlTokenCac parameter.

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

This UL capacity pool is compared to a configurable threshold: if below this target, the call is accepted, otherwise it is refused.

If a high bit rate UL PS RB is limited at RAB establishment because of this feature, it can be upgraded thanks to ULRB Rate Adaptation feature if possible (see Packet Data Management section).






7.2 Transport Resource Reservation

Radio Bearer

Radio Bearer

Iub Bearer

Iub Bearer

Iur

Bear

er

Iu-CS Bearer

Iu-PS Bearer

iubIurTransportQosId

(DL/ULRbSetConf -> CacTransportInfoList)

iuTransportQosId

(DL/ULRbSetConf -> CacTransportInfoList)

dscp

DscpPerOlympicService/2



DscpTrafficClass/3

DscpTrafficClass/2

DscpTrafficClass/1

RNC

Ps/CSCoreNetworkAccess

DscpTrafficClass/0DS Traffic (Speech, VT, SRB)Streaming Traffic (on DCH or HSDPA)NDS Traffic (PS I/B) on DCHNDS Traffic (PS I/B) on HSDPA

Transport resources reservation consists of selecting the QoS identifier corresponding to the requested radio bearer. The QoS identifier is configured at the Access OAM according to the traffic class of the radio bearer.

Based on the QoS identifier required for the radio bearer requested, the RNC will request and reserve a CID (Channel IDentifier) that is, a transport channel on the Iub, Iur, Iu-CS.

Transport channels on Iu-PS are reserved according to the DSCP. The DSCP (DiffServ Code Point) is deduced from the traffic class and the allocation/retention level (OLS for the interactive and background RABs). The RNC is mapping each DiffServ class on one ATM quality of service over the Iu-PS (namely CBR, VBR-rt, VBR-nrt, UBR).

From UA6.0, an additional QoS is introduced to permit the introduction of guaranteed bit rate traffic flowson HSDPA. The new mapping is:

QoS 0 carries Delay Sensitive traffic (speech, VT, SRB, etc)

QoS 1 carries the streaming traffic, mapped on DCH or HSDPA

QoS 2 carries the PS I/B traffic mapped on DCH traffic

QoS 3 carries the PS I/B traffic mapped on HSDPA

The determination of Iub load for iRM is done for the DL direction, thanks to real time observation of trafficat the ATM layer. The traffic measured is averaged on a window of 10s.






7.3 AAL2 Call Admission Control

aal2IfQoS0

QoS1

SHARED

ACR(QoS1) x qoS1BWReservation (aal2If)

CacMethod (aal2If)

ACR(QoS0) x qoS0BWReservation (aal2If)

qos aal2If

ACR(aal2If)

QoS0

QoS1

aal2If

path

ACR(aal2If)

QoS0

QoS1

Path/0

Path/n

Path/1

Path/m

loadBalancingMethod (aal2If)

pc

link

CacMethod (aal2If)none

CAC disabled

AAL2 CAC ensures that the admission of new calls does not cause traffic to exceed the provisioned ATM bandwidth in either UL or DL. AAL2 CAC can be done per aal2If or per QoS according to the CacMethodchosen.

Each RB has a cost called Equivalent Bit Rate that represents the bandwidth to be reserved. Available bandwidth (called Available Cell Rate) is estimated by the RNC based on the ATM Traffic Descriptors (PCR, SCR).

ACR(QoS) = Sum(ECR GCAC) on all AAL2 VCCs for the given QoS

for CBR (Iub and Iur DS UP VCCs and IuCS UP) : ECR GCAC = PCR

for VBR (Iub and Iur NDS UP VCCs): ECR GCAC = 2 x PCR x SCR / (PCR + SCR)

ACR(aal2If) =Sum(ACR(QoS)) on all QoS in use on the aal2If.

The new connection is accepted when:

If CACMethod=aal2If:

EBR(new connection on aal2If) + EBR(current connections on aal2If) ≤ ACR(aal2If)

If CACMethod=QoS (example of new DS connection):

If EBR(current NDS) < qos1BwReservation x ACR(NDS)

EBR(new DS) + EBR(current DS) < ACR(DS) + (1-qos1BwReservation)ACR(NDS)

Else:

EBR(new DS) + EBR(current DS) + EBR(current NDS) < ACR(DS) + ACR(NDS)

If CACMethod=path:

EBR(new connection on path) + EBR(current connections on path) ≤ ACR(path)

The loadBalancingMethod parameter configured on an UTRAN aal2 interface, determines the choice of a path for a CID seizure.

loadBalancingMethod = link: the CID is seized on the less loaded active Path within an aal2If

loadBalancingMethod = pc: the CID is seized on a Path assigned to the less loaded PMC-PC






7.4 IRM and AAL2 CAC Replay at RB Upgrade or AON Upsize

DCH FACH DCH

EBR(384 kbps)

EBR(128 kbps)

EBR(8 kbps)

AA

L2 C

AC

EBR

RAB

RAN

AP

MBR

384 kbps

8 kbps

384 kbps

AON Downsize AON Upsize

1. iRM Downgrade(cell color is yellow)

2. AAL2 CAC on DCH at AON Upsize CAC on FACH at

AON Downsize

EBR of a given call can be updated when the TRB is reconfigured during the call, typically as the result of multi-service, always-on, iRM scheduling and power pre-emption scenarios. This is done through the Aal2 bearer negotiation function.

This implies that during upgrade scenarios, the function must re-apply link and PC CAC to the EBR of the target RB configuration and reject if the new requested bandwidth fails the CAC criteria. This function is enabled through the use of isAal2BearerRenegotiationAllowed






7.5 DL Reserved Power Computation

Algorithm Selection

Pres = Pmax - algo1DeltaTargetPower

Pres = Pini + algo2DeltaTargetPower

Pini = pcpichPower + initialDlEcnoTarget – CPICH_Ec/No

dlAlgoSelector (PowerConfClass)

FDDCell

powerConfId (FDDCell)

algo1

algo2

maxDlTxPowerPerOlsalgo1DeltaTargetPower algo2DeltaTargetPower

initialDlEcnoTarget

Pmax = pcpichPower + maxDlTxPowerPerOls

pcpichPower (FDDCell)

PowerConfClass

DlUsPowerConf

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.






7.6 DL Power Admission Criteria

P traffic

P traffic admission

callAdmissionRatio (PowerPartConfClass)maxTxPower (FDDCell)

Call Rejected

No

Pres is allocated

Pres

Pused

Yes

Pres + Pused <= Ptraffic_admission

Traffic Power(SHO reserved)

Traffic Power

(Dedicated Channels)

Overhead Power

(CCC+OCNS+HSDPA+E-DCH)

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






7.7 DL Power Self Tuning: Principle

isBtsPowerSelfTuningActivated (PowerConfClass)

Case 1Power consumption

underestimated at the RNC

Case 2Power consumption

overestimated at the RNC

Allocated Power(Pused from RNC)

Measured Power(Pused from NodeB)

New allocatedpower

powerMargin(PowerConfClass)

Allocated Power

Measured PowerNew allocated

power

overEstimate(PowerConfClass)

Tuning of RNC power pool occupancyThe 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).






7.8 DL Power Self Tuning: Example

Power_Margin

OverEstimate

CommonMeasurmentReportingPeriod (NBAP)

Power Allocated is underestimated :

ADD Power_Margin

Power Allocated is overestimated by more

than OverEstimateUPDATE with Pmeas

Power Allocated is overestimated by less

than OverEstimateNO CHANGE

DL Power used reported by NodeB

DL Power used as seen by RNC

Power consumption underestimated at the RNC: In this case it is proposed to update the allocated power (power consumed as seen by the RNC) based on the measured power (as measured by the Node B) plus a powerMargin.

Power consumption overestimated at the RNC: The power consumption is confirmed as overestimated if the difference between the measured and allocated is above an overEstimate threshold. In that case, the new allocated power (power consumed as seen by the RNC) is made equal to the measured power (as reported by the Node B).






7.9 OVSF Codes Reservation & Admission

Alcatel -Lucent

S -CCPCHC 64,1

Alcatel -Lucent

PICHC 256,3

Alcatel -LucentAICHC 256,2

3GPPP-CCPCHC 256,1

3GPPP-CPICHC 256,0

SourceChannelOVSF Code

Alcatel-LucentS -CCPCHC 64,1

Alcatel-LucentPICHC 256,3

Alcatel-LucentAICHC 256,2

3GPPP-CCPCHC 256,1

3GPPP-CPICHC 256,0

SourceChannelOVSF Code

SF4

SF8

SF16

SF32

SF64

SF128

SF256

CommonChannels

OVSF Codes Allocation

Spreading Factor (SIB 5)

Code Number (SIB 5)

Channelization Code (SIB 5)

Channelization Code (SIB 5)

In this OVSF tree, some codes are reserved:

codes for common control channels

codes for OCNS

a sub-tree is allocated to the Node B for HSDPA usage.

The rest of the OVSF tree is used by calls handled over R99 resources.

For each allocation, the OVSF tree will be run from up to down (filling the gaps when any), which avoids to block too many branches.

If a free code is found, the resource is granted to the call and the OVSF code CAC is successful, otherwise the call is rejected and the CAC on OVSF code is declared failed.

The new feature Dynamic DL Code Tree Management has been introduced in UA5 in order to avoid R99 code blocking.





8 CELL_FACH Admission Control





8 CELL_FACH Admission Control

8.1 CELL_FACH Admission Control

IDLE

CELL_DCH CELL_FACHSRB + RB

CELL_DCH CELL_FACHSRB ONLY


Cell Update

Cell Update

AO Downsize

AO Upsize

RAB Assignment

CELL_FACH Admission Events

Buck

et O

ccup

ancy

CELL_FACHAdmission Control

MaxNumberOfUsersPerMacC(CacOnFachParam)

trbEstThreshold(CacOnFachParam)

Each cell can only accept a limited number of simultaneous UEs in the CELL_FACH state:

Each mobile on CELL_FACH is allocated a token.

Each time a CELL_FACH admission is tried in a given cell, the current number of used token is compared to a specific threshold. If below the threshold, the admission is successful and a token is allocated.

There are 2 thresholds used according to the reason for CELL_FACH admission. In the Alcatel-Lucent implementation, they are defined as:

MaxNumberofUsersPerMacC (signaling dealing with Cell_FACH state as RRC Connection Request, Cell Update – with at least one SRB allocated-)

is used to limit the number of simultaneous user connections being supported by a given Mac-C instance

trbEstThreshold (transition from Cell_DCH state to Cell_FACH due to Always-On feature)

defines the maximum number of users that can have TRB configuration in CELL_FACH

These parameters are set at the OAM in order to give a higher precedence to a new incoming call (RRC connection request) than to a mobile already in call and aiming to transition from Cell_DCH to Cell_FACH.





Module Summary

This lesson covered the following topics:Call establishment and associated parameters

RAB Matching and associated parameters

IRM RAB to RB Mapping and associated parameters

CAC and associated parameters

CELL_FACH admission and associated parameters

















Section 7Call Management






9300 W-CDMA · UA06 R99 Algorithms DescriptionCall Management7 · 2

Blank Page



2009-02-2901

RB bit rate > preemptionFloorBitRateInXX and not RB bit rate >= preemptionFloorBitRateInXX



Document History





Module Objectives


Describe Call Management principles

Describe Always On and associated parameters

Describe RB Rate Adaptation and associated parameters

Describe iRM Scheduling and associated parameters

Describe iRM Preemption and associated parameters

Describe Preemption Process for DCH ad HSDPA/HSUPA

Describe AMR Rate Change during the call











Table of Contents


1 Call Management Overview 71.1 Call Management Mechanisms 8

2 Always On 92.1 Always On Downsize Principles 102.2 Always On Upsize Principles 112.3 Always On Downsize Parameters 122.4 AO Upsize UL Parameters 132.5 AO Upsize DL Parameters 142.6 RRC States 152.7 URA_PCH Transitions if CELL_PCH is used 162.8 URA_PCH Transitions if CELL_PCH is not used 172.9 CELL_PCH Transitions 182.10 URA Update in URA_PCH state 192.11 Cell Update in CELL_PCH state 202.12 Cell Update in CELL_FACH state 212.13 PCH States configuration 222.14 AO Step 2 and AO Step 3 Timers 232.15 Definition of isAlwaysOnAllowed (xxRbSetConf) 242.16 Mono-Service PS/Multi-RAB PS I/B R99 (R99 PS Mux) 262.17 Multi-Service CS+PS 272.18 Recovery actions CELL_FACH admission failure 282.19 URA (UTRAN Registration Area) 292.20 User Services Parameters 30

3 RB Rate Adaptation 333.1 RB Rate Adaptation Principles 343.2 Traffic Monitoring Principles 353.3 DL Downsizing 363.4 UL Downsizing 373.5 DL Multi-Stage Upsizing 383.6 UL Step by Step Upsizing 39

4 iRM Scheduling 404.1 iRM Scheduling Principles 414.2 Event A for iRM Scheduling Downgrade 424.3 Events B1 and B2 for iRM Scheduling Upgrade 434.4 iRM Scheduling Upgrade 444.5 PS Streaming RAB: iRM Scheduling 454.6 iRM Scheduling Parameters for Downgrade 464.7 iRM Scheduling Parameters for Upgrade 47

5 iRM Preemption 485.1 iRM Preemption Algorithm 495.2 iRM Preemption: Downgraded DL RB 505.3 Cell Color / Active Set Color Calculation 515.4 iRM Preemption Behavior 525.5 Interaction with iRM RAB to RB Mapping 53

6 Preemption Process for DCH and HSDPA/HSUPA 546.1 Concepts 556.2 Eligible Procedures 566.3 Eligible CAC Failure Cases 576.4 Internal or External CAC failures 586.5 Eligible Transport Channel 596.6 Eligible Services 606.7 Selection of service to be pre-empted 616.8 Mono-Step / Multi-Step Pre-emption 626.9 Selection of service to be downgraded 636.10 Estimation of Resource De-allocation 64







6.11 Queuing of RAB Assignment Request 656.12 Feature dependencies 666.13 Feature Interactions 67

7 AMR Rate Change during the Call 707.1 General Principles 717.2 Iub DS load criteria 737.3 UL Cell load criteria 747.4 DL Power load criteria 757.5 DL Tx CP criteria 767.6 Parameters Settings 77





1 Call Management Overview





1 Call Management Overview

1.1 Call Management Mechanisms

Dedicated Channel

Dedicated Channel

Dedicated Channel

UMTS R99

Background

PSInteractive

PSStreaming

Streaming

Conversational

Always OnDomainService Class RB RateAdaptation

PSBackground

PSInteractive

PSStreaming

CSStreaming

CSConversational

iRMPreemption

iRMSchedulingAlways OnDomainService Class Preemption AMR Rate

Change

Call Management is a set of reactive mechanisms performed during the call to satisfy four objectives:

Increase capacity of the system by taking advantage of user traffic burstiness: Always On mechanism adapts the resources allocated to users according to their activity (two steps mechanism depending on whether there is low traffic or no traffic at all).

Increase capacity of the system by taking advantage of user traffic burstiness: RB Rate Adaptation saves more capacity by matching dynamically the RB bit rate as closely as possible to the real user traffic. It allows adaptation of the bandwidth for services requiring more than the Always-On downsized RB but less than the current RB.

Improve retainability of the calls: iRM Scheduling adapts the resources to the radio conditions fluctuation. iRM Scheduling downgrading secures the call by reducing the amount of downlink power required in degraded radio conditions, whereas iRM Scheduling upgrading enhances subscriber experienced quality by providing a higher throughput when radio conditions improve.

Increase capacity at the expense of call retainability: iRM Preemption allows the bit rate of low priority users to be reduced or even to be pre-empted in order to increase the admission success rate of CS calls or high priority users in congested situations. It is performed when all other preventive congestion mechanisms are insufficient to free resources quickly enough to maintain sufficient accessibility to the network.

Increase capacity or QoS at the expense of throughput or call retainability: Preemtion process for DCH and HSDPA/HSUPA allows some high priority calls to be established at the expense of PS call throughput degradation or at the expense of forcing lower priority PS or CS calls to be dropped

Increase capacity at the expense of voice quality: AMR rate Change during the call allows to force AMR rate downgrade when some radio resource become scarce in the cell

Most of these Call Management features operate only on UMTS PS I/B RABs since no Guaranteed Bit Rate is defined for such traffic classes. However, iRM Scheduling is also available for PS Streaming services so as toavoid call drops when UE moves in poor radio quality areas. Preemtion process applies to any types of call wherease AMR rate change applies to Multi-Mode AMR calls only.





2 Always On





2 Always On

2.1 Always On Downsize Principles

CELL_FACH

Throughput ThresholdThroughput ThresholdAO Step 1AO Step 1

User Traffic Volume

T1

AO timers

T1 T2

T1 T2

T1

PMM-idle

NOMINAL DCH RB No Radio Bearer


T1

CELL_DCH

AO FACH RB

RRC Context

trafficinactivity

CELL_PCHor

URA_PCH

T3

traffic and signalinginactivity

isAlwaysOnAllowed (AlwaysOnConf)isAlwaysOnAllowed (DlUserService)isAlwaysOnAllowed (UlUserService)

No Radio Bearer

No RRC Connection

O kbpsO kbps

AO step1 AO step2 AO step3

Dedicated radio resources are not optimal to support packet services with sporadic traffic. In order to find the best trade-off between efficient resource usage and subscriber comfort, the Always On concept developed is composed of three steps.

After a first period of low activity (T1), the bearer is reconfigured to a predefined downsized bearer configuration, which consumes less radio resources.

If traffic activity is detected, the bearer is upgraded back to its initial configuration (or to a degraded one if network congestion is meanwhile detected).

If no traffic activity is detected during a second period of time (T2), then the radio bearer is released but the RRC connection remains as well as the Iu Connection in order to speed up the needed radio bearer setup in case or user traffic resumption.

If neither traffic nor signaling activity is observed during a third period of time (T3) then the RRC and Iuconnection 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)





2 Always On

2.2 Always On Upsize Principles

CELL_FACH


User Traffic Volume

AO timers

TTT

NOMINAL DCH RBNo Radio Bearer


CELL_DCH

AO FACH RB

RRC Context

O kbpsO kbps

AO step2

CELL_PCHor

URA_PCH

AO step2

trafficresuming

In Cell_PCH or URA_PCH states, although the connection is no more active, the mobile keeps its PDP context active.

Therefore, a traffic resume is done either:

By the mobile, which re-establishes a connection to the network

Or by the network by paging the mobile, which would have the effect of creating a new connection. The dataflow is the same as the mobile initiated resume except for the paging phase.

In Cell_FACH state, the RNC assess the user data throughput and decides to perform an AO upsize to DCH radio bearer if the high user throughput is detected.





2 Always On

2.3 Always On Downsize Parameters

step2ThroughputThreshold (AoOnFachParam)

T2 timer depends on RRC states usage

T2

step2AverageWindow (AoOnFachParam)

T1

step1DlUlThroughputThreshold (AoOnFachParam)

timerT1 (AlwaysOnTimer)

step1AverageWindow (AoOnFachParam)

Ul & DL Traffic Volume

NOMINAL DCH RB AO FACH RB No Radio

step1TimerBetween2Reports (AoOnFachParam)

The AO downsize step1 condition is based on DL and UL traffic volume monitoring on non-sliding time windows. The downsize criterion is met if:

(TBsize x NbTB) / Step1AverageWindow < Step1DlUlThresholdThroughput during at least TimerT1.

With:

NbTB: Number of Transport Blocks transferred during the time window

TBsize: size of a L1 Transport Block (in bits)

AO Downsize is performed when UL and DL criteria are met.

The AO downsize step2 decision is based on DL and UL traffic volume monitoring on non-sliding time windows. The release criterion is met if:

(TBsize x NbTB) / Step2AverageWindow < Step2ThresholdThroughput

at least during TimerT2 seconds

The UE may keep or not its RRC connection or not depending on the usage of the Cell_PCH/URA_PCH states or not.





2 Always On

2.4 AO Upsize UL Parameters

Reporting event4a

Upsize

repThreshold (AoOnFachParam)

UE RLC/MAC Buffer OccupancyReporting

event4a

timeToTrigger (AoOnFachParam) pendTimeAfterTrig (AoOnFachParam)

Report

NOMINAL DCH RBAO FACH RB

AO Upsize is performed when UL or DL criteria are met.

As the upsize conditions are applied as the mobile is using common UL and DL resources (RACH/FACH) these conditions cannot be based on observed user traffic. The principle is that these conditions will be based on RLC buffer occupancy, reflecting the state of congestion of the transport channel (see following two slides).

The UL upsize condition relies on event triggered UE traffic volume measurement on RACH Transport Channel, based on event 4A.

As the sum of Buffer Occupancies of RBs multiplexed onto the RACH exceeds a certain threshold (RepThreshold), the mobile performs an event triggered reporting.

On reception of this event, the SRNC considers the UL upsize condition as fulfilled.

The pendTimeAfterTrig timer is started in the UE when a measurement report has been triggered by a given event. The UE is then forbidden to send new measurement reports triggered by the same event during this time period. Instead the UE waits until the timer has expired.

The timeToTrigger timer is started in the UE when the Transport Channel Traffic Volume triggers the event. If the TCTV crosses the threshold before the timer expires, the timer is stopped. If the timer expires then a report is triggered.





2 Always On

2.5 AO Upsize DL Parameters

step1DlRlcBoThreshold (AoOnFachParam)

Upsize

UpsizeRequired

RLC/MAC Buffer Occupancy per UE

step1TimerBetween2Reports ((OnFachParam)

NOMINAL DCH RBAO FACH RB

The DL upsize condition relies on the same kind of mechanism. As the sum of Buffer Occupancies of RBsmultiplexed 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.





2 Always On

2.6 RRC States

UTRA RRC Connected Mode

CELL_DCH

Nominal RB

CELL_FACH

Fallback RB

Release RRCConnection

Release RRCConnection

Establish RRCConnection

Establish RRCConnection

RRC Idle ModeUser inactivity

User activity

URA_PCH

No RB

CELL_PCH

No RB

“Sleeping” states(No data

transmission)

New statesSupported by

Always On

Cell update load

T1

T2

T3

T3

As explained in TS 25.331 "The RRC states within UTRA RRC Connected Mode reflect the level of UE connection and which transport channels that can be used by the UE."

When the RNC receives a RAB assignment request, the corresponding Radio Bearer is by default allocated in CELL_DCH.

Then, later on during the call, a UE can be moved between CELL_DCH and CELL_FACH based on user activity (i.e. user traffic volume monitoring), that can be controlled by the operator thanks to inactivity timers.

Since CELL_FACH makes use of RACH and FACH, which are common transport channels (shared between all the users of the cell), CELL_FACH is only suited to non real-time data services (i.e. Interactive or Background) and can even be used to transmit small amounts of user data. However, it cannot be used for real-time traffic, such as voice or video telephony, which are always supported in CELL_DCH.

Always-On is the Alcatel-Lucent PS call management feature responsible for choosing the best radio resources according to the amount of traffic the subscriber has to transmit.

From UA5.0, Always-On mechanism supports these two RRC states: URA_PCH and CELL_PCH.

PCH sates (i.e. CELL_PCH and URA_PCH) are useful for data subscribers who can fallback to one of these states when they are completely inactive:

Since no cell resources are allocated to UE in these states, i.e. no dedicated physical channel is allocated to the UE, they have no impact on the cell capacity.

Nevertheless, subscribers benefit from a quicker re-establishment time compared to when in Idle mode and the UE battery consumption is low, i.e. equivalent to when the UE is in Idle mode.





2 Always On

2.7 URA_PCH Transitions if CELL_PCH is used


CELL_DCH

Data to transmit

RRC Idle Mode

CELL_FACH

Inactive user from URA_PCH(T3=uraPchToIdleTimer)

nbOfCellUpdatesFromCellPchToUraPchCELL UPDATE

pchRrcStates (RadioAccessService)

= UraAndCellPchEnabledCELL_PCHURA_PCH

When CELL_PCH is used, the transitions between URA_PCH and the other states are the following:

Transition from CELL_PCH to URA_PCH:

When in CELL_PCH, the transition to URA_PCH occurs when the user has performed a minimum number of CELL UPDATE procedures. Therefore this transition is based on the Cell Update signaling load and not on the user traffic activity. Hence, this transition is not directly related to AO.

nbOfCellUpdatesFromCellPchToUraPch is used to control the transition from CELL_PCH to URA_PCH state in case the both are activated. It represents the thresholds value for the number of cell update procedures (with cause “Cell reselection”) initiated by the UE in CELL_PCH state (for a maximum duration of CellPCHtoIdleTimer) for the RNC to trigger a state change to URA_PCH for this UE.

Transition from URA_PCH to CELL_FACH:

In case some data need to be transmitted, the UE is transferred to CELL_FACH:

In uplink, access is performed by RACH,

In downlink, UTRAN sends a paging request message (PAGING TYPE1).

Transition from URA_PCH to idle through CELL_FACH:

Once in URA_PCH, if the subscriber is completely inactive, i.e. no traffic during a certain period (URAPCHToIdleTimer), then the UE is further moved to Idle mode.

Transition to CELL_FACH is required to perform the RRC signaling connection release





2 Always On

2.8 URA_PCH Transitions if CELL_PCH is not used

CELL_DCH

URA_PCH


Data to transmit

RRC Idle Mode

CELL_FACH

Inactive user from URA_PCH(T3=uraPchToIdleTimer)

Inactive user(T2= fachToUraPchTimer)


= UraPchEnabled

When CELL_PCH is not used, the transitions between URA_PCH and the other states are the following:

Transition from CELL_FACH to URA_PCH:

When in CELL_FACH, the amount of user traffic is monitored in both uplink and downlink directions.

When there is no traffic during a certain period of time (FACHToURAPCHTimer) and CELL_PCH is not enabled, the UE is moved to URA_PCH.

The transition criteria are the same than those used for transition to idle mode, i.e. traffic volume measurement on DTCH in both uplink and downlink directions.

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,


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





2 Always On

2.9 CELL_PCH Transitions

nbOfCellUpdatesFromCellPchToUraPchCELL UPDATE

CELL_DCH

CELL_PCH


URA_PCH

RRC Idle Mode

CELL_FACH

Inactive user from CELL_FACH

(T2=fachToCellPchTimer)

Data to transmit

Inactive user from CELL_PCH(T3=CellPchToldleTimer)


= UraAndCellPchEnabled

The transitions between CELL_PCH and the other states are the following:

Transition from CELL_FACH to CELL_PCH:

When in CELL_FACH, the amount of user traffic is monitored in both uplink and downlink directions.

When there is no traffic during a certain period of time (FACHToCellPCHTimer), the UE is moved to CELL_PCH.

The transition criteria are the same than those used for transition to idle mode, i.e. traffic volume measurement on DTCH in both uplink and downlink directions.

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.


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.





2 Always On

2.10 URA Update in URA_PCH state


URA_PCH

CELL_FACH

Cell Reselection

No data to transmit

URA Update

NewURA

Admission controlAlthough no cell resources are allocated to a UE in URA_PCH, the RNC has to maintain the RRC and Iuconnections, to keep a UE context as well as to process the URA Update procedure.

Therefore the RNC controls the maximum number of simultaneous UE in URA_PCH and once the limit is reached a UE is moved to Idle mode instead.

Mobility

In URA_PCH state the location of a UE is known at UTRAN Registration Area (URA) level.

A URA is an area covered by a number of cell(s), which is only known by the UTRAN.

The UE performs a Cell Reselection and upon selecting a new UTRA cell belonging to a URA that does not match the URA used by the UE, the UE moves to CELL_FACH state and initiates a URA Update towards the network.

After the URA Update procedure has been performed, the UE state is changed back to URA_PCH if neither the UE nor the network has any more data to transmit.





2 Always On

2.11 Cell Update in CELL_PCH state


CELL_PCH

CELL_FACH

Cell Reselection

Cell UpdateNo data

to transmit

NewCELL

Admission controlAlthough no cell resources are allocated to a UE in CELL_PCH, the RNC has to maintain the RRC and Iuconnections, to keep a UE context as well as to process the Cell Update procedure.

Therefore the RNC controls the maximum number of simultaneous UE in CELL_PCH and once the limit is reached a UE is moved to Idle mode instead.

Mobility

In CELL_PCH state the location of a UE is known at UTRA cell level.

The UE performs Cell Reselection and upon selecting a new UTRA cell, it moves to CELL_FACH state and initiates a Cell Update procedure in the new cell.

After the Cell Update procedure has been performed, the UE state is changed back to CELL_PCH if neither the UE nor the network has any more data to transmit.

Mobility over IurIf 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.





2 Always On

2.12 Cell Update in CELL_FACH state


CELL_FACH

Cell UpdateNo data

to transmit

NewCELL

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





2 Always On

2.13 PCH States configuration

pchRrcStates = none

CELL_DCH CELL_FACH

pchRrcStates = UraAndCellPchEnabled

CELL_DCH

URA_PCH

CELL_FACH

CELL_PCH

pchRrcStates = CellPchEnabled

CELL_DCH CELL_FACH

CELL_PCH

pchRrcStates = UraPchEnabled

CELL_DCH

URA_PCH

CELL_FACH

4 AO Downsized configurations can be used thanks to pchRRcstates parameter:

CELL_FACH only

CELL_FACH or CELL_PCH

CELL_FACH or URA_PCH

CELL_FACH or CELL_PCH or URA_PCH





2 Always On

2.14 AO Step 2 and AO Step 3 Timers

URA_PCH

CELL_PCH

IdleStep 3 (T3)

cellPchToIdleTimer

UraPchToIdleTimer

CELL_FACH

fachToCellPchTimer

fachToUraPchTimer

AO Step 2 (T2)

nbOfCellUpdatesFromCellPchToUraPch

URA_PCH activated (only)URA_PCH & CELL _PCH activatedCELL _PCH activated

(pchRrcStates = {uraPchEnabled)(pchRrcStates = {uraPchAndCellPchEnabled})(pchRrcStates = {cellPchEnabled, uraPchAndCellPchEnabled})

(Counter of Cell Update procedures)

URA_PCH activated (pchRrcStates = {uraPchEnabled, uraPchAndCellPchEnabled})

(Inactive user)

(Inactive user)

(No signaling traffic : Paging, Cell Update)

(No signaling traffic : Paging, Cell Update)

AO Downsize are split into:

A0 Downsize Step 1:

from CELL_DCH to CELL_FACH

A0 Downsize Step 2:

from CELL_FACH to CELL_PCH if CELL_PCH state is used

from CELL_FACH to URA_PCH if URA_PCH state is used and CELL_PCH state is not used

A0 Downsize Step 3:

from CELL_DCH to PMM-idle if AO is enabled but Downsized mode is not used

from CELL_FACH to PMM-idle if PCH states are not used

from CELL_PCH to PMM-idle if CELL_PCH state is used

from URA_PCH to PMM-idle if URA_PCH state is used





2 Always On

2.15 Definition of isAlwaysOnAllowed (xxRbSetConf)

isAlwaysOnAllowed (DlRbSetConf)isAlwaysOnAllowed (UlRbSetConf)

neither RB downsizenor RB release

based on user inactivity

= disabled

RB downsizethen RB release


= degraded2AlwaysOnOnly

AO Step 1 (+ Step2) + Step 3

no RB downsizebut RB release


= releaseOnly

AO Step 3





Exercise : Mono-Service PS/Mono-RAB PS I/B R99

R99 PS I/BCELL_DCH PMM-idle

timerT1CELL_FACH

timerT2

AO Step1 AO Step3

isAlwaysOnAllowed = ? pchRrcStates = ?

R99 PS I/BCELL_DCH PMM-idle

timerT2

AO Step3


R99 PS I/BCELL_DCH PMM-idleCELL_FACH

timerT1

AO Step1

fachToUraPchTimer

AO Step2


AO Step3URA_PCHuraPchToIdleTimer

hsiddhar

Sticky Note

degraded2AlwaysonOnly. None

hsiddhar

Sticky Note

releaseOnly None

hsiddhar

Sticky Note

degraded2AlwaysonOnly. URAAndCellPCHEnabled





2 Always On

2.16 Mono-Service PS/Multi-RAB PS I/B R99 (R99 PS Mux)

isAlwaysOnAllowed (DlRbSetConf) = releaseOnlyisAlwaysOnAllowed (UlRbSetConf) = releaseOnly

AO Step 1 not allowed for Multi RAB configuration

R99 PS I/B MUXCELL_DCH PMM-idle

timerT2

AO Step3

PchRrcStates = none

R99 PS I/B MUXCELL_DCH PMM-idle

timerT2

AO Step2

PchRrcStates = UraAndCellPchEnabled

AO Step3CELL_PCH

URA_PCH

cellPchToIdleTimer

uraPchToIdleTimer

AO Step3

Multiple PS RAB is limited to 2 PS RAB only.

There may be situations during which the UTRAN is required to manage 2 simultaneous PS Interactive/Background RAB for a given user identified by a single RRC connection:

A user is activating a primary and a secondary PDP context in order to open bearers with different quality of service towards a given APN (Access Point Name) or packet network.

A user is activating two primary PDP contexts, each of them corresponding to a different APN

Both of these I/B RABs are multiplexed onto a single DCH. The set of supported rates are:

UL: 64, 128

DL: 64, 128, 384

If 2 PS RAB are active simultaneously, the AO Step 1 downsize to Cell_FACH can not be performed.

The AO adaptation is delayed until traffic is null and then the AO Step 2 to PCH states or AO Step 3 to Idle is carried out depending on the usage of PCH states.





2 Always On

2.17 Multi-Service CS+PS

Mono RAB PS I/B R99isAlwaysOnAllowed (PS RAB) = degraded2AlwaysOnOnly pchRrcStates ≠ none

isAlwaysOnAllowed (PS RAB) = releaseOnly

Multi RAB PS I/B R99

pchRrcStates = any value

CS + R99 PS I/B MUXCELL_DCH PMM-idle

timerT2

AO Step3

PS I/B(CELL_DCH

Down Inactivity

Up

CS+PS I/B(CELL_DCH

Inactivity

PS traffic resuming

CS RABsetup

CS RAB release

CELL_FACH

CS + PS I/B8/8(Cell_DCH)

CS + PS I/B 0/0 (CELL_DCH)

CELL_PCH or

URA_PCH

Down

Up

PS traffic resuming

Inactivity

Inactivity

PMM-idle

CS+PS I/B 0/0(+PS I/B 0/0) for Always-On on multi-RAB

UA5.0 / UA5.1: when a user has a RAB CS + PS I/B calls established, the RNC manages

user inactivity in the following way :

Always-on Step 1 (low activity) : reconfiguration to CS + PS I/B 8/8

Always-on Step 2 (inactivity) : the PS RAB is released – CS + PS I/B 8/8 -> CS

UA6.0: new step for CS+PS

Always-on Step 1 : unchanged

Always-on Step 2 : reconfiguration to CS + PS I/B 0/0

1. allows a quicker re-establishment in case PS traffic resumes.

2. CS + PS I/B + PS I/B combinations are handled the same way with a reconfiguration to CS + PS I/B 0/0

3. + PS I/B 0/0.

4. The RNC monitors the traffic on the PS RB(s) and can trigger an upsizing while the CS call is active.

As part of this evolution:

5. when a UE is in URA_PCH or CELL_PCH and the RNC receives a request to establish a CS RAB, the

6. user is allocated a CS + PS I/B 0/0 RB or CS + PS I/B 0/0 + PS I/B 0/0 depending on the number of PS

7. RAB established. This is more efficient from a resources usage point of view than CS + PS I/B 8/8 or

8. CS + PS I/B 64/64 + PS I/B 64/64, which are allocated with the current implementation.

9. When the CS call is released and if the PS traffic is still 0/0, then the UE is moved back to URA_PCH

10. or CELL_PCH.

Establishment Cause & Traffic Volume Indicator (TVI) in CELL UPDATE message

On transition from CELL_PCH or URA_PCH, choice between CELL_FACH or CELL_DCH based on TVI and Establishment Cause

hsiddhar

Sticky Note

Timer T1

hsiddhar

Sticky Note

TImerT1

hsiddhar

Sticky Note

FachtocellPCHtimer

hsiddhar

Sticky Note

FachtocellPCHtimer

hsiddhar

Sticky Note

FachtoUraPCHtimer

hsiddhar

Sticky Note

CellPCHtoIdleTImer





2 Always On

2.18 Recovery actions CELL_FACH admission failure

PS I/B(CELL_DCH

DCH, HS -DSCH or E -DCH )

CELL_FACH

AO downsize Failure

Buck

et O

ccup

ancy

CELL_FACHAdmission Control

MaxNumberOfUsersPerMacC(CacOnFachParam)

trbEstThreshold(CacOnFachParam)

UE is kept in in CELL_DCH until CAC FACH succeeds

Recovery actions on CELL_DCH to CELL_FACH admission failure:

When the CAC FACH fails at DCH to FACH AO downsize transition, the UE is kept in in CELL_DCH until CAC FACH succeeds (at downsize retry) or conditions for transition to CELL_FACH are not fulfilled anymore.





2 Always On

2.19 URA (UTRAN Registration Area)

Up to 8 URA per cellMandatory for URA_PCH state activation

URA list broadcast in SIB2

URA1 cell

URA2 cell

URA3 cell

URA1URA2

URA3URA1

FDDCell

uraIdentityList

URA Identity is 16 bits string.

URA can overlap to avoid ping-pong at the border of several URA.

URA overlapping at the border of two RNC not supported.

Note: SIB2 implementation is independent of URA_PCH flag. If UraIdentityList under FDDCELL is not empty, SIB2 will be broadcast in this cell, not taking into account whether URA_PCH is enabled at RNC level RNC.





2 Always On

2.20 User Services Parameters RNC

DlRbSetConf UlRbSetConfDlUserService UlUserService AlwaysOnConf

AlwaysOnTimer

isAlwaysOnAllowed isAlwaysOnAllowed

disabled degraded2AlwaysOnOnly

releaseOnly

true false

alwaysOnUlRbSetDchId

alwaysOnDlRbSetDchId

alwaysOnUlRbSetFachId

alwaysOnDlRbSetFachId

timerT1, timerT1ForHsdpa, timerT1ForHsdpaAndEDch

timerT2, timerT2ForHsdpa, timerT2ForHsdpaAndEDch

fachToCellPchTimer, cellPchToIdleTimer

fachToUraPchTimer, uraPchToIdleTimer

The Radio Bearers used for the downsized state are provided in the AlwaysOnConf object, including the type of downsize (Cell_DCH or Cell_FACH).

The list of user services that are eligible to Always On is given through the parameter isAlwaysOnAllowed in DlUserService and UlUserService objects.

The parameter isAlwaysOnAllowed in DlRbSetConf and UlRbSetConf objects determines the behavior of each Radio Bearer when the always on downsize is triggered. It can take the following values:

degraded2AlwaysOnOnly means that the downsize is allowed and the target radio bearers are determined by the parameters of the AlwaysOnConf object.

releaseOnly means that there is no intermediate downsize for this Radio Bearer. The Radio Bearer is released when the release conditions are met.

Disabled means that the Always On feature is disabled for this Radio Bearer.





Exercise 1/2

AssumptionsUE is R99isAlwaysOnAllowed (alwaysOnConf) = TruealwaysOnUlRbSetDchId (alwaysOnConf) = PS_8KalwaysOnDlRbSetDchId (alwaysOnConf) = PS_8KisAlwaysOnAllowed (PS_128K_IBxSRB_3_4K) = TrueisAlwaysOnAllowed (CS_64KxPS_128K_IBxSRB_3_4K) = TrueisAlwaysOnAllowed (PS_128K_IB) = degraded2AlwaysOnOnlyisAlwaysOnAllowed (CS_64K) = disabledtimerT1 (AlwaysOnTimer) = 15stimerT2 (AlwaysOnTimer) = 20stimerT2ForMultiRab (AlwaysOnTimer) = 20sPchRrcStates (RadioAccessService) = UraAndCellPchEnablednbOfCellUpdatesFromCellPchToUraPch (RadioAccessService) = 3fachToCellPchTimer (AlwaysOnTimer) = 20sfachToUraPchTimer(AlwaysOnTimer) = 20scellPchToIdleTimer (AlwaysOnTimer) = 60mnuraPchToIdleTimer (AlwaysOnTimer) = 60mn





Exercise 2/2

Question: Find the RRC State changes ?

PS I/B 128K

0kbps

128kbps

64kbps

5s

CS 64/64





3 RB Rate Adaptation






3.1 RB Rate Adaptation PrinciplesRequested RAB

RAB to RBset Matching (UL/DL)

DL iRM

RBset to UserServices Matching (UL/DL)

CAC

Reference UL bit rate

Target RB (DL/UL)

Reference DL bit rate

128128 38438464643232

RB Resizing (UL/DL)

isUlRbRateAdaptationAllowed(RadioAccessService )

isDlRbRateAdaptationAllowed(RadioAccessService )

rbRateAdaptationPinPongTimer(RadioAccessService )

maxUlEstablishmentRbRate(CacConfClass)

Current RB (DL/UL)

Traffic Monitoring (UL/DL)

EstimatedThroughput

(DL/UL)Adapted RB

(DL/UL)

RB Rate Adaptation (UL/DL)

iRM Target UL RB bit rate iRM Target DL RB bit rate

UL iRM

UL bit rate limitation DL bit rate limitation

maxDlEstablishmentRbRate(CacConfClass)

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.

DownsizingRNC targets the bit rate as closely as possible to the estimated throughput.

UpsizingUplink: RNC targets the bit rate immediately above the current bit rate (step-by-step upsize).Downlink: RNC targets any rate (multi-stages upsize), based on user throughput and RLC buffer occupancy. The targeted RB bit rate should never exceed the Reference RB bit rate.

DL and UL rate adaptation are performed independently.

In UL (resp. DL), the parameter maxUlEstablishmentRbRate (resp. maxDlEstablishmentRbRate) specifies the maximum UL (resp. DL) rate at call admission. This parameter is significant when isUlRbRateAdaptationAllowed (resp. isDlRbRateAdaptationAllowed) of RadioAccessService object is set to True.

In DL, user is initially admitted at a bit rate determined by RAB Matching and iRM.






3.2 Traffic Monitoring Principles

βδ ≤KtKR

S,

[ ]∑−

=

=1

0

1 K

kkRate

KR [ ]( )∑

−

=

−−

=1

0

22

11 K

kRkRate

KS

time

Rate[0]=0Rate[1]=0Rate[2]=0

T0

Rate[0]=0Rate[1]=0Rate[2]=N0/T

T1

Rate[0]=0Rate[1]=N0/TRate[2]=N1/T

T2

Rate[0]=N0/TRate[1]=N1/TRate[2]=N2/T

T3

Rate[0]=N1/TRate[1]=N2/TRate[2]=N3/T

T4

Throughput Estimates

raUnitPeriodTimeraNbOfSample

(DlRbRaTrafficMonitoring)

raUnitPeriodTimeraNbOfSample

(UlRbRaTrafficMonitoring)

raMaxConfidenceIntraModifiedStudentCoef

(DlRbRaTrafficMonitoring)

raMaxConfidenceIntraModifiedStudentCoef

(UlRbRaTrafficMonitoring)Reliable Throughput Estimate

Confidence Level

RLC-SDUthroughput

Confidence Interval = 2b

throughput Estimate

The traffic monitoring function consists of calculating the average throughput over a time window and estimating the confidence level of the observed throughput.

The algorithm used is the same in DL and in UL. The average throughput is estimated at RLC level excluding retransmissions and acknowledgements.

The algorithm first computes periodically the user throughput over a period of time T (raUnitPeriodOfTime) as Rate =N/T where N is the number of RLC-SDU bits transmitted for the first time during T.

Traffic estimates are then based on a sliding window of size K (raNumberOfSample).

The estimation of the average throughput R and of the throughput variance S is derived over the last K samples Rate[k], where each value R[k] corresponding to a throughput value calculated during a period of time T (see above slide formulas corresponding to an example with K = 3).

The estimated throughput is supposed to follow a Student-t distribution with K degrees of freedom. The throughput estimate is considered reliable if the probability of the real throughput being out of the interval of confidence is smaller than a determined threshold (see above slide formulas).

When the throughput estimate is considered reliable, the RB rate adaptation resizing process is triggered, otherwise no action is taken.






3.3 DL Downsizing

no downsizeno downsize

downsize to DL32downsize to DL32



DL384

DL128

DL64

DL32

time

TDOWN256

TDOWN128

TDOWN64

isDlRbRateAdaptationAllowedForThisDlUserService(DlUserService)

isDlRbRateAdaptationAllowedForThisDlRbSetConfisThisRbRateAdaptationDlRbSetTargetAllowed

dlRbRateAdaptationDownsizeThreshold

(DlRbSetConf)

DL384DL384 DL256DL256 DL128DL128 DL64DL64 DL32DL32

DL iRM

Reference RB

MIN (Adapted RB, IRM RB)

Allocated RB

TDOWN384


DL256

RLC-SDU Average Throughput

The RB Rate Adaptation process can downsize a RB from the current RB rate down to any smaller RB (all transitions towards a smaller RB are possible except to PS 8k, which is not eligible as target).

Based on Traffic Monitoring, the RNC takes the decision to downsize when the following criteria, which are periodically checked, are verified:

The observed average throughput is lower than a defined threshold (dlRbRateAdaptationDownsizeThreshold),

The confidence level of the estimated average throughput is good enough to consider the observation as reliable.

The RB adaptation process can downsize a RB from the current RB rate down to any RB with lower bit rate but the allocated RB is always constrained by the iRM table selection.






3.4 UL Downsizing

UL384UL384 UL128UL128 UL64UL64 UL32UL32

no downsizeno downsize

downsize to UL32downsize to UL32



UL384

UL128

UL64

UL32


time

TDOWN384

TDOWN128

TDOWN64

isUlRbRateAdaptationAllowedForThisUlUserService(UlUserService)

isUlRbRateAdaptationAllowedForThisUlRbSetConfisThisRbRateAdaptationUlRbSetTargetAllowed

ulRbRateAdaptationDownsizeThreshold

(UlRbSetConf)

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.






3.5 DL Multi-Stage Upsizing

no upsizeno upsize

upsize of DL32upsize of DL32



time

TUP128

TUP64

TUP32

DL384

DL128

DL64

DL32

DL256upsize of DL256upsize of DL256

DL384DL384 DL256DL256 DL128DL128 DL64DL64 DL32DL32

DL iRM

Reference RB

Allocated RB

isDlRbRateAdaptationAllowedForThisDlUserService(DlUserService)

isDlRbRateAdaptationAllowedForThisDlRbSetConf

isThisRbRateAdaptationDlRbSetTargetAllowed

dlRbRateAdaptationUpsizeThreshold

raSduQueueThreshold

raSduQueueThresholdBytes

(DlRbSetConf)

Current RB

MAX [ MIN (Adapted RB, IRM RB), Current RB ]


RLCRLC--SDUSDUBuffer Buffer occupancyoccupancy

QUP128

QUP384QUP256

QUP64

bytesbytes %%

dlRbRateAdaptationUpsizeAlgorithm(RadioAccessService)

Multi-stages Upsize avoids successive reconfigurations intermediate bit rates in order to reach directly the most suitable RB rate.

The RB adaptation process can upsize a RB from the current RB rate up to any RB with higher bit rate but the allocated RB is always lower than or equal to the Reference RB and is constrained by the iRM table selection.

Based on Traffic Monitoring, the RNC takes the decision to upsize according to the following criteria, which are periodically checked:

The observed average throughput is higher than a threshold (dlRbRateAdaptationUpsizeThreshold)

The confidence level of the estimated average throughput is good enough to consider the observation reliable.

RLC-SDU buffer occupancy (in %) is higher than a threshold (raSduQueueThreshold)

If the Multi-Step DL Upsize algorithm is activated (dlRbRateAdaptationUpsizeAlgorithm = multiStageUpsize and not stepByStepUpsize)then the RNC selects the target RB according to the DL RLC-SDU buffer occupancy. It compares the current value of the RLC buffer occupancy (in bytes) to a threshold in order to find the highest RB for which the following condition is met:

RLC-SDU Buffer Occupancy (in bytes) ≥ raSduQueueThresholdBytes

If no RB higher than the current RB meets this condition, the upsize is not performed, it means that little data is waiting for transmission.






3.6 UL Step by Step Upsizing

UL384UL384 UL128UL128 UL64UL64 UL32UL32 UL8UL8

isUlRbRateAdaptationAllowedForThisUlUserService(UlUserService)

isUlRbRateAdaptationAllowedForThisUlRbSetConf(UlRbSetConf)

isThisRbRateAdaptationUlRbSetTargetAllowed(UlRbSetConf)

ulRbRateAdaptationUpsizeThreshold(UlRbSetConf)

no upsizeno upsize

upsize of UL32upsize of UL32



UL384

UL128

UL64

UL32

time

TUP128

TUP64

TUP32


A step-by-step upsize scheme applies for the UL RB Rate Adaptation.

It means that the only possible transitions are from the current RB to a target RB which is the very next RB in terms of bit rate. In this case, the RNC selects the bit rate immediately above the current one, since the Traffic Monitoring can only indicate that current bit rate is not big enough.

There is no forecast on the future traffic based on the UE RLC buffer occupancy (and consequently multi-stage upsize is not possible).

Based on Traffic Monitoring, the RNC takes the decision to upsize when the following criteria, which are periodically checked, are verified:

The observed average throughput is lower than some defined thresholds,

The confidence level of the estimated average throughput is good enough to consider the observation as reliable.

The allocated UL bit rate can never exceed the Reference RB bit rate.





4 iRM Scheduling





4 iRM Scheduling

4.1 iRM Scheduling Principles

Nominal RBNominal RB

Fallback RBFallback RB

Intermediate RB

Downgrade

Upgrade

flipFlopUpDowngradeTimer


isIrmSchedDowngradeTxcpAllowedisIrmSchedulingUpgradeAllowed


irmSchedDowngradeTxcpMaxBitRate

(RadioAccessService)NodeB

DL 384 kbit/s

DL 128 kbit/s

DL 64 kbit/s

The iRM Scheduling mechanism is based on two sequential procedures triggered to adapt user throughput when he goes alternately through good and bad radio conditions:

iRM Scheduling Downgrade reduces bit rate when radio conditions are getting bad.

iRM Scheduling Upgrade increases bit rate when radio conditions are getting better.

iRM Scheduling Downgrade is based on Transmit Code Power: trigger is based on a measurement done by the Node B. The dedicated measurement is performed on the primary cell and concerns the Downlink Transmitted Code Power.

The trigger based on TxCP dedicated measurement can be applied if the primary cell is handled by the serving RNC or on a DRNC since iRM Scheduling on TxCP is supported over Iur from UA5 release.

irmSchedDowngradeTxcpMaxBitRate is the parameter specifying the fallback RB bit rate in case of iRMScheduling downgrade.

flipFlopUpDowngradeTimer parameter allows to avoid pin-pong phenomena between RB upgrade and downgrade.

iRM Scheduling/ RB rate adaptation dependency:

In case if RB rate adaptation is enabled for the service, after iRM scheduling downgrade, the service is flagged as ineligible for rate adaptation upsize. When an event B is reported, the iRM scheduling upgrade is triggered, so the service come back eligible for RB rate adaptation upsize. Hence bit rate upsize will not be performed immediately by iRM scheduling but rather with RB rate adaptation algorithm if necessary.





4 iRM Scheduling

4.2 Event A for iRM Scheduling Downgrade

isIrmSchedDowngradeTxcpAllowed (DlUsPowerConf)

isTransCodePowerIrmSchedulingDowngradeAllowedFromThisDlUserService (DlUserService)

Transmitted Code Power

Event AReport

Primary Cellthreshold_delta(DlIrmSchedDowngradeTxcp)

Event A timeToTrigger Event A timeToTrigger

timeToTrigger (DlIrmSchedDowngradeTxcp)

Event AThreshold

64

384 Downgrade

pcpichPower + maxDlTxPower

-

For iRM Scheduling Downgrade based on TxCP, the detection of degradation in radio conditions relies on the monitoring of the DL Transmitted Code Power (TxCP). The TxCP trigger is based on NBAP Dedicated Measurement (type Event A) performed by the Node B handling the primary cell.

When the transmitted code power (TxCP) rises above a threshold (TxCP threshold) during the hysteresis time (timeToTrigger), a Dedicated Measurement Report is sent by the Node B to the RNC (Event A).

Event A configuration relies on:

Measurement Threshold: the relative transmitted code power threshold given by the parameter threshold_data is used to compute the absolute TxCP Threshold together with the parameters pcpichPower(FDDCell) and maxDlTxPower (DlUsPowerConf)

Measurement Hysteresis: timeToTrigger





4 iRM Scheduling

4.3 Events B1 and B2 for iRM Scheduling Upgrade

Event B2 Timer

Transmitted Code Power Event B1Report

Primary Cell

Event B1 Timer

Event B2Report

highB1ThresholdDelta(DlIrmSchedulingUpgrade)

128

384

64 384 128Upgrade

Event B2Threshold

Event B1Threshold

highB1TimeToTrigger (DlIrmSchedulingUpgrade)

mediumB2TimeToTriggerOverHighB1 (DlIrmSchedulingUpgrade)

mediumB2ThresholdDeltaOverHighB1(DlIrmSchedulingUpgrade)

pcpichPower + maxDlTxPower

-

isIrmSchedulingUpgradeAllowedFromThisUS (DlUsPowerConf, DlUserService)

isIrmSchedulingUpgradeAllowedToThisUS (DlUsPowerConf, DlUserService)

When a UE is using the RB assigned by IRM Scheduling downgrade, the RNC configures two types of NBAP dedicated measurement by event B report for this UE on the primary cell.

So each time the primary cell changes, the RNC terminates measurements on the old primary cell and initiates measurements on the new primary cell.

Event B1 configuration relies on:

Measurement Threshold: the relative transmitted code power threshold given by the parameter highB1ThresholdDelta is used to compute the absolute TxCP Threshold together with the parameters pcpichPower (FDDCell) and maxDlTxPower (DlUsPowerConf)

Measurement Hysteresis: given by the parameter highB1TimeToTrigger

Event B2 configuration relies on:

Measurement Threshold: relative transmitted code power threshold given by highB1ThresholdDelta + mediumB2ThresholdDeltaOverHighB1 together with the parameters pcpichPower (FDDCell) and maxDlTxPower

Measurement Hysteresis: given by highB1TimeToTrigger + mediumB2TimeToTriggerOverHighB1





4 iRM Scheduling

4.4 iRM Scheduling Upgrade

Granted RB

Event Bx

ProcessingEvent Bx

Cell color

RL Condition

Min

iRM tables

iRM RB

Power RB

Requested RB

OLS

Any user becomes eligible for iRM Scheduling upgrade as soon as it experiences an iRM Scheduling downgrade. This means that after the RB reconfiguration bringing about the downgrade, the RNC configures and activates the NBAP dedicated measurement report on the primary cell, so as to track the transmitted code power (see section 4).

On reception of the NBAP Dedicated Measurement Report, the SRNC executes the RAB matching function taking into account that the Power RB (H or I), corresponding to the event reported (B1 or B2), will be the highest rate able to be allocated to this mobile.

On reception of the NBAP Dedicated Measurement report, the RNC proceeds to the Synchronous Radio Link Reconfiguration (SRLR) if the Granted RB is different from the current one. Is so the anti ping-pong timer flipFlopUpDowngradeTimer is started.

This timer should allow slow ping-pong phenomena between upgrading and downgrading if observed. At its expiry, a NBAP dedicated measurement can be initiated if in the meantime an iRM scheduling downgrade has been performed for the mobile.





4 iRM Scheduling

4.5 PS Streaming RAB: iRM Scheduling

Nominal RBNominal RB

Fallback RBFallback RB

NodeB

DL 384 kbit/s

DL 128 kbit/s

DL 64 kbit/s

Intermediate RB

Upgrade

xxx_PS_128K_STR_yyyxxx_PS_256K_STR_yyyxxx_PS_384K_STR_yyy

DlUserServiceDlUserService

isIrmSchedDowngradeTxcpAllowed (DlUsPowerConf)

isIrmSchedulingUpgradeAllowedFromThisUS (DlUsPowerConf)

isIrmSchedulingUpgradeAllowedFromThisUS (DlUsPowerConf)

Since high bit rate RB are radio resources consuming, enhanced RRM is required to optimize radio resources usage.

iRM Scheduling Downgrade

Downgrading - similar to I/B but RNC selects the fallback bit rate that is equal or immediately above the GBR

Upgrading - similar to I/B but but RNC selects the fallback bit rate that is equal or immediately above the GBR

Always On and RB Rate Adaptation are not applicable to PS streaming RAB





4 iRM Scheduling

4.6 iRM Scheduling Parameters for Downgrade

Iur

Thresholddefined:

• as absolutevalue in dBm

• at RNC / DlUserServicelevel

SRNC

Thresholddefined:

• as relative value (to Pmax) in dB

• at Cluster (PowerConfClass) / DlUserServicelevel

FDDCell

thresholdDelta timeToTrigger

irmSchedDowngradeTxcpMaxBitRate RadioAccessService

RNC

DlUserService

1..30

IrmSchedulingDowngradeTransCodePower

1..1

LowRbA

1..1

1..1

DedicatedConf

1..*

PowerConfClass

DlUsPowerConf

1..15

1..40

DlIrmSchedDowngradeTxcp

thresholdTransCodePowerDefinitionParam timeToTrigger

Used when primary cell is on a drift RNC Used when primary cell is on the serving RNC





4 iRM Scheduling

4.7 iRM Scheduling Parameters for Upgrade

Iur

Thresholddefined:

• as absolutevalue in dBm

• at RNC / DlUserServicelevel

SRNC

Thresholddefined:

• as relative value (to Pmax) in dB

• at Cluster (PowerConfClass) / DlUserServicelevel

RadioAccessService

RNC

DlUserService

0..1

1..30

1..1

MediumRbB2 HighRbB1

1..1

1..1

DedicatedConf

1..*

PowerConfClass

DlUsPowerConf

1..15

1..40

DlIrmSchedUpgrade

highB1ThresholdDelta highB1TimeToTrigger mediumB2ThresholdDeltaOverHighB1 mediumB2TimeToTriggerOverHighB1

highBitRate thresholdTransCodePower timeToTrigger

intermediateRate deltaThresholdTransCodePower deltaTimeToTrigger

FDDCell

Used when primary cell is on a drift RNC Used when primary cell is on the serving RNC

deltaThresholdTransCodePower and mediumB2ThresholdDeltaOverHighB1 are defined relatively to high bit rate threshold (respectively thresholdTransCodePower and highB1ThresholdDelta)

IrmSchedulingUpgrade





5 iRM Preemption





5 iRM Preemption

5.1 iRM Preemption Algorithm

Cell Color

22

11 Current DL RB Downgraded DL RB

33

SilverSilver

IRM Tables44

BronzeBronze

GoldGold

isIrmPreemptionAllowed


isIrmPreemptionAllowedForGoldUsersisIrmPreemptionAllowedForSilverUsers

isIrmPreemptionAllowedForBronzeUsers

(irmPreemption)

Code LoadPower LoadIub LoadCEM Load

A/R Priority Level

The purpose of iRM Preemption is to keep some resources available when the cell becomes loaded. iRMPreemption is a reactive process performed when all other preventive congestion solutions are not sufficient to free OVSF codes and power resources quickly enough to maintain sufficient accessibility to the network.

The preemption procedure is applicable to specific users having PS Interactive/Background connection in CELL_DCH according to their OLS level.

However, no specific feature is dedicated to the radio bearer upsizing for preempted users. But they may retrieve the initial requested radio bearer after any reconfiguration (CS release, CS establishment when a PS connection on-going, iRM scheduling upgrade, AO upsizing…) except the AO downsize and iRM scheduling downgrade procedures.

Thus iRM Preemption completes the existing congestion prevention iRM RAB to RB Mapping feature by implementing a reactive congestion management at the cell level.

Note: IRM pre-emption feature activation requires that parameters isIrmOnRlconditionAllowed and isIrmOnCellColourAllowed set to TRUE.





5 iRM Preemption

5.2 iRM Preemption: Downgraded DL RB

Radio Link Color

BronzeBronze


+ iRMRbRate

DL Cell Color

OLS

fallBackRbRate MINiRM Preemption

Downgraded RB Bit Rate

The target Radio Bearers for iRM Preemption are defined using:

the iRM Tables: iRMRbRate as a function of (DlRbSetConf, OLS)

fallBackRbRate as a function of DlRbSetConf

They correspond to the Radio Bearers UE would have received if UE were admitted as the Radio Link Condition was Bad and the Cell Color was Red.

Therefore users eligible to iRM preemption are users whose current DL Bit Rate is higher than the one defined for bad radio conditions and loaded cells.

As iRM tables are constructed making use of A/R Priority, iRM Preemption offers the possibility to preempt users according to their OLS level.





5 iRM Preemption

5.3 Cell Color / Active Set Color Calculation

Code Color

Power Color

WorstWorst

Cell 1

Cell N

WorstWorst

Active Set Color

Cell Color

Cell Color

WorstWorst

Iub Color

+

=

WorstWorst

Black

White

Black

White

Black

White

normal2congestedPLCThresholdcongested2normalPLCThresholdnormal2congestedCLCThresholdcongested2normalCLCThreshold

normal2congestedDlCEMThresholdcongested2normalDlCEMThreshold

(IrmPreemptionCacParams)

normal2CongestedDlTLCThresholdcongested2NormalDlTLCThreshold

(IrmPreemptionIubTransportLoadParameters)

The transition from a normal to a congested state is computed when one of the following thresholds is crossed:

normal2CongestedCLCThreshold (for codes)

normal2CongestedPLCThreshol (for power)

normal2CongestedDlCEMThreshol (for CEM load)

normal2CongestedDlTLCThreshold (for Iub)

In order to avoid any ping pong effect between the congested and normal states, due to strong variations in the radio resources allocation, the hysteresis cycle relies on additional thresholds characterizing the congested to normal transition through the parameters:

congested2NormalCLCThreshold (for codes)

congested2NormalPLCThreshold (for power)

congested2NormalDlCEMThreshol (for CEM load)

normal2CongestedDlTLCThreshold (for Iub)

In the case of soft handover, the active set color is derived from the color of each cell.





5 iRM Preemption

5.4 iRM Preemption Behavior

irmPreemptionColorCheckingTimer (IrmPreemption)

PS I/B Connection

UE 1

UE 2

UE N

time

Preemption Starts

Color Check Checking Timer

AS Color

Black

White

Preemption Stops

As soon as a downlink PS I/B radio bearer is allocated to a UE, the iRM preemption timer assigned to each eligible mobile is armed. At each UE timer expiration, the cell preemption color is checked, and if the cell is congested, the eligible user is preempted if the following condition based on the bit rate comparison is fulfilled:

If

current DL RB bit rate > iRM preemption downgraded RB bit rate

Then

preemption is processed and the downgrade is performed





5 iRM Preemption

5.5 Interaction with iRM RAB to RB Mapping

Radio Color

Iub Color

Cell Color

WorstWorst

Black

White

Preemption Color

Radio Color

Iub Color

Cell Color

Worst

iRM Color

Red

Green Yellow

The iRM Preemption cell color determination algorithm is similar to the one already implemented for the iRM RAB to RB Mapping feature based on the cell color evaluation.

However, it implies some specific thresholds relating to the calculation of the code load, power load, CEM load and Iub load.

Consequently it has an independent mechanism from the one used for iRM CAC.

The addition of the new colors (Black and White) is for preemption purposes only.

It has no effect on iRM RAB to RB Mapping process applied at call admission or on RB reconfiguration.





6 Preemption Process for DCH and HSDPA/HSUPA






6.1 Concepts

Preemption

NodeB UL radio resources not available

RNC DL power resources not available

RNC DL code resources not available

NodeB resources not available

NodeB DL radio resources not available

RNC

CAC

Failure

NodeB

CAC

Failure

PS Background

PS Interactive

Signaling PS Interactive

PS Streaming

CS Streaming

Video telephony

Speech

Emergency Call

PreemptionCapability

PreemptionVulnerability

Priority (*)Inter-Frequency intra-RNC Radio Link setup (IMCTA CAC, iMCTA Alarm)

Radio Link AdditionAlways-on Upsize

RRC connectionrequest

RAB Assignment

Queuing not allowed

Queuing allowed

R99

HSUPAHSDPA

(*) + OLS at user level

1 Step / 2 Steps

Incoming relocation does not trigger preemption in the target RNC

RNC

isPreemptionAllowedisPreemptionAllowedForHsdpaisPreemptionAllowedForEdch

isCellPreemptionCodePowerCacFailureAllowedisCellPreemptionNbapCacFailureAllowed

FDDCellisCellPreemptionAllowed

Eligible procedures

Eligible Services

Eligible CAC Failures

UA6.0: Introduction of new Pre-emption feature (33322)

Reactive mechanism (trigger is CAC failure)

Independent from the iRM

Applicable to DCH as well as HS-DSCH & E-DCH transport channels

Dl & UL

Applicable to all services

The UA6.0 Pre-emption is triggered by a CAC failure, meaning that no resource are available to accept the incoming call. It may be :

DL Power

DL OVSF Codes

CEM (UL & DL)

Transport (restriction in UA06.0: Iub/Iur cac failure not elligible)

The CAC failure may happen at Call Establishment or during mobility procedure.

The system will then try to free some resources by downgrading (PS only) or releasing lower priority services to be able to accept the incoming user.

The preemption shall only be a reactive mechanism that aims at allocating the preempted resources to the service that triggered the preemption.

The preemption is performed in best effort mode : the resources freed by the Preemption will not be necessarily allocated to the user that triggered the preemption






6.2 Eligible Procedures

RadioAccessService

Preemption

PreemptionCapabilityProcedureInfo

preemptionCapabilityForAlwaysOnToDch

preemptionCapabilityForAlwaysOnToHsDsch

preemptionCapabilityForAlwaysOnToEdch

Pre-emptionon CAC Failure

Procedure

Inter-Frequency intra-RNC Radio Link setup (HHO)

Radio Link Addition (SHO)

Always-on Upsize

RRC connection request

RAB Assignment

ON / OFF

ON

preemptionCapabilityForMobility

preemptionCapabilityForRrcEstabCause……OtherThanEmergencyCall

When a CAC failure occurs during one of the following procedures, the procedure goes on either by processing a failure case or is queued (see below the comment for each procedure).

Simultaneously, a pre-emption action may be launched in order to free resources in each congested cell.

The freed resource might be used by the call that triggered the Pre-emption or not as part of the best effort algorithm implemented.

Note 1: an incoming relocation in the target RNC shall not trigger pre-emption, Queuing is forbidden for relocation.

Note 2: an iMCTA upon service reason shall not trigger pre-emption in source cell nor target cell






6.3 Eligible CAC Failure Cases

NodeB UL radio resources not available

RNC DL power resources not available

RNC DL code resources not available

NodeB resources not available

NodeB DL radio resources not available

RNC

CAC

Failure

NodeB

CAC

Failure

RNC

isCellPreemptionCodePowerCacFailureAllowed

NodeB

FDDCell

isCellPreemptionNbapCacFailureAllowed

The S-RNC may decide to launch preemption in a cell when it faces up a CAC failure during the followingresource allocation procedures:

o NBAP procedures: NBAP Radio Link setup failure, NBAP Radio Link addition failure, NBAP SynchronizedRadio Link Reconfiguration failure, NBAP Radio Link Reconfiguration failure using one of the following NBAP failure cause: “DL radio resources not available”, “UL radio resources not available” and “Node B Resources Unavailable”

o Internal DL power allocation

o Internal DL channelization code allocation

These resource allocation procedures concern DCH, E-DCH or HS-DSCH resources allocation.

Others functions as HSxPA fallback or iMCTA may also solve the CAC failure situation depending on the trigger eligibility and the feature activation. The order of the procedures is the following:1-HSxPA fallback 2-iMCTA 3-preemption.

The resources allocation requests done through RNSAP procedures are not eligible to preemption.

An ALU D-RNC will never launch a pre-emption process. Iub and Iur resources allocation failures don’t call the pre-emption function.

Note: The NBAP failure cause « Node B Resources Unavailable » identifies a resource allocation failurewithout indication of the direction which may be downlink, uplink or downlink & uplink.






6.4 Internal or External CAC failures

With the introduction of the Fair-sharing feature,Internal resources (RNC) are shared between DCH & HSDPA(DL Power & OVSF Codes)External resources (NodeB) are dedicated to each transport type (UL & DL)(CEM processing)

When a CAC failure occurs, the selection of the users to be pre-empted dependson the failure cause:

UL DCH / DL DCH Node B DL radio resourcesnot available

UL DCH / DL DCH

UL E-DCH / DL HS-DSCH DL OVSF Codes CAC failure UL XXX / DL YYY (*)

UL E-DCH / DL HS-DSCH Node B radio resources not available

UL E-DCH / DL HS-DSCH

(*) XXX stands for DCH or E-DCH, YYY stands for DCH or HS-DSCH






6.5 Eligible Transport Channel

RNC

isPreemptionAllowedForEdch

RadioAccessService

PreemptionAllowedInfo

isPreemptionAllowedForHsdpa

Pre-emptionCAC Failure on

DCH ON

HS-DSCH ON / OFF

E-DCH ON / OFF

isPreemptionAllowedForHsdpa : Parameter to activate/deactivate preemption process when a CAC failure occurs during a HSDPA allocation (i.e. HS-DSCH resources)

isPreemptionAllowedForEdch : Parameter to activate/deactivate preemption process when a CAC failure occurs during a HSUPA allocation (i.e. E-DCH resources)






6.6 Eligible Services

Each service can be preempted and/or can preempt according to the following attributes:Priority level : allows to classify services to decide which service is allowed to pre-empt which service

Pre-emption capability : defines if the incoming service may trigger the pre-emption

Pre-emption vulnerability : defines if the service may be pre-empted

RNCCN RAB Assignment Request

Allocation/Retention priority IE

Pre-emption CapabilityPre-emption Vulnerability

RadioAccessService

PreemptionpreemptionMode

PreemptionPcPvServiceClass/Emergency

PreemptionFrequency/FDDx0..5

PreemptionPcPvServiceClass/SpeechPreemptionPcPvServiceClass/VideoTelephony

PreemptionPcPvServiceClass/PS Streaming

PreemptionOmcrPcPvInfopreemptionCapability

preemptionVulnerability

OR

PreemptionServiceInfo

preemptionPriorityOfService

Y

Y

N

Y

Y

N

N

N

N

Preemption Vulnerability(PV)

N

N

Y *

Y

Y

Y

Y

Y

Y

Preemption Capability(PC)

7PS Interactive

8PS Backgroung

6Signalling PS Interactive

5PS Streaming

4CS Streaming

3Video Telephony

2VoIP**

1Speech

0Emergency

P-Service PriorityServices

Y

Y

N

Y

Y

N

N

N

N

Preemption Vulnerability(PV)

N

N

Y *

Y

Y

Y

Y

Y

Y

Preemption Capability(PC)

7PS Interactive

8PS Backgroung

6Signalling PS Interactive

5PS Streaming

4CS Streaming

3Video Telephony

2VoIP**

1Speech

0Emergency

P-Service PriorityServices






6.7 Selection of service to be pre-empted

Applicability :The congested cells of the active set used by the call waiting for resourcesThe target cell selected by the SRNC or by the other RAT when a call has to be established

Services preempted may belong to ongoing multi-services

for same service priority and same OLS, the expected gain in term of radio bit rate is used as the third criteria

Incomingservice

1st Service filtering

(PV, Priority)

Services

Preemptableservices list

(1st)

CAC Failure

2nd Service filtering

(CAC Failure)

Conditions :- Service has to bevulnerable to preemption- Priority ≤ Priority (Incomingservice)

Conditions :- CAC Failure is Node B : Transport Type = Transport Type (Incomingservice)*- CAC Failure is RNC (Code, Power) : all services using HS-DSCH & DL DCH to be preempted

Preemptableservices list

(2nd)

User filtering

(OLS)

Conditions :- Service = Service (Incoming) : OLS < OLS (Incoming)

- Service ≠ Service (Incoming) : OLS ≤ OLS (Incoming)

Bronze

Silver

Gold

P-Priorityn

Bronze

Silver

Gold

P-Priorityn-1

Bronze

Silver

Gold

P-Priorityk

Priority- +

Silver

P-Priorityk

Incomingservice

In each congested cell, a search of P-Services to be pre-empted carrying a traffic channel is processed by applying a downgrade or/and a release. The preemption criteria for each P-Service are taken into account.

The preemption process ends when the expected resource quantity to be de-allocated is achieved or when there is no P-Service to pre-empt anymore.

The selection induces the following steps:

The RNC selects all P-Services which are vulnerable (P-Preemption Vulnerability equal to “pre-emptable”) with a P-Service priority lower or equal to the P-Service requesting the pre-emption

According to the CAC failure cause the P-services which don’t allow the de-allocation of the resource requested are filtered.

When the CAC failure cause is for NodeB reason, a specific filtering applies:

The P-Service candidate to be pre-empted is filtered if it has not the same transport type as the service requested.

When the CAC failure cause is for code or power reason, all P-Services using HSDSCH or DL DCH resources are candidate to be-pre-empted.

Then the RNC

only keeps the users with an OLS lower or equal to the OLS of the user requesting the pre-emption if they are using different P-Service(s)

only keeps the users with an OLS strictly lower than the OLS of the user requesting the pre-emption if if they are using the same Pservice(s)






6.8 Mono-Step / Multi-Step Pre-emption

Choice only for PS Interactive or Background or Streaming (if target rate >= GBR)Any other service leads to a release of the Service when preempted

Mono-Step Multi-Step

preemptionDowngradeReleaseSteps(Preemption)

DowngradeThenRelease

DCH

preemptionDowngradeReleaseSteps(Preemption)

Preempted serviceis downgraded

DowngradeOnly

DCH

ReleaseOnly

HS-DSCHE-DCH

Preempted serviceis downgraded

Preempted serviceis released

next Pre-emption process

Any value

Then the RNC starts to preempt the user with the lowest OLS within the lowest service priority by applying first a rate downgrading action if eligible.

When there are no more users of the lowest OLS, the RNC goes on with upper OLS.

Then when there is no more user to downgrade, a second step of pre-emption using a release (if allowed for the service) may apply to the users not already selected for downgrading (lowest OLS first) and to the users ineligible to the downgrading (see note 1).

When there are no more users in this Service priority, the RNC goes on with the upper Service.

Note 1: There is no selection order between downgraded users and users ineligible to downgrading. A user is ineligible for downgrading due to the Service (example: speech), the GBR, the transport type. When pre-emption is processed for a given CAC failure, a service eligible for “downgrading then release”may only be either downgraded or released: When it is downgraded, it will be candidate to the release at the next pre-emption function call.

Note 2: For a given priority and a given OLS, a downgrading or a release applies by the highest expected gain in term of radio bit rate. So the pre-emption order is Service, OLS and then radio bit rate gain whatever the CAC failure reason.

Note 3: A release action may apply to the following Services:

Services which are never eligible to rate downgrading: CS Speech, CSD, CS streaming, PS Conversational

• Services which may be eligible to release according to an OAM parameter: PS streaming, PS Interactive, PS Background

A service established on HS-DSCH may only be released.

A service established on E-DCH may only be released.






6.9 Selection of service to be downgraded

Only valid for Downgrading pre-emption

RadioAccessService

PreemptionpreemptionFloorBitRateInDownlink

preemptionFloorBitRateInUplink

RBs selectedfor downgrading



Filtering on Target bit rate

RB bit rate > preemptionFloorBitRateInXX

Keep the Max bit rate RBs

An uplink target rate and/or a downlink target rate are set by OAM for each service per OLS.

The RB and the requested target rates are given by the pre-emption function to the Rab matching functionwhich selects the bearers with the nearest and lower or equal rate to the target rate.

When the Rab matching selects a service configuration with a sum of rate higher than the previous service configuration, the call is not modified (this use case may apply when the call has others services which are upgraded by the Rab matching function).

For a given priority and a given OLS, a downgrading or a release applies by the highest expected gain in term of radio bit rate. So the pre-emption order is Service, OLS and then radio bit rate gain whatever the CAC failure reason.






6.10 Estimation of Resource De-allocation

DCH Service CAC Failure

Preemption

PreemptionDeallocationInfopreemptionDeallocationFactorInDownlink [High,Low]

preemptionDeallocationFactorInUplink [High,Low]

preemptionDeallocationThresholdInDownlinkpreemptionDeallocationThresholdInUplink

Service(s) Preempted so that

Free resource = Ul (Dl) Radio rate to be allocated

* Ul (Dl) DeallocationFactor [High]

Node B / Code / PowerUL (DL) CAC Failure

Ul (Dl) resource rate to be freed> DeallocationThreshold

Service(s) Preempted so that

Free resource = Ul (Dl) Radio rate to be allocated

* Ul (Dl) DeallocationFactor [Low]

Yes

No

An estimation of the resource needed has to be done in the following CAC failure cases:

NodeB: DCH resource allocation failure

Code: DCH or HS-DSCH resource allocation failure

Power: DCH or HS-DSCH resource allocation failure

When the CAC failure occurs at NodeB level for HS-DSCH or E-DCH resource allocation, a “one to one”release action is processed (i.e. a P-Service established on HS-DSCH or E-DCH is released) without taken into account the resource quantity used.

In order to have a common estimator of all resources to be de-allocated, whatever where the CAC failure occurs, the estimation of resources needed is based on:

the current radio bit rates if the CAC failure concerns DCH resources allocation at NodeB or RNC sides (power and code). The resource quantity to be de-allocated in a congested cell is based on the sum of radio estimated downlink rates needed to establish all P-Services of the call in this cell.

the fair bit rate if the CAC failure concerns HSDPA resources allocation at RNC side (power and code). The resource quantity to be de-allocated in a congested cell is based on the sum of fair bit rates needed to establish all P-Services of the call in this cell. The fair bit rate of a P-Service is calculated by the fair sharing function and is either the GBR, the MinBR (defined by OAM) if non null or the minHsDschReservationForCac (defined by OAM).

The resource de-allocation calculation uses a de-allocation factor (defined by OAM) to major the quantity of resources to be freed. The unit is the kbits/sec. The resource to be freed is defined by the formula:

Ul resource rate to be freed= Ul Radio rate to be allocated * Ul de-allocationfactor

Dl resource rate to be freed= Dl Radio rate or fair bit rate to be allocated * Dl deallocation factor

The de-allocation factor depends on the resource quantity to be freed:

If the resource quantity <= threshold, the de-allocation factor used is the high factor value defined by OAM

If the resource quantity > threshold, the de-allocation factor used is the low factor value defined by OAM






6.11 Queuing of RAB Assignment Request

Best effort approachRAB Assignment

Preemption

resource allocation request

max number of retries

preemptionQueuingReallocationRetryMaxNumber

(PreemptionQueuingReallocation)

preemptionQueuingReallocationTimer

(PreemptionQueuingReallocation)

Cell Pre-emption state Normal state

preemptionQueuingAllowedIE(Preemption)

preemptionQueuingReallocationPriority = 0 or 1(PreemptionServiceInfo)

PriorityReallocation RegularReallocation

Per P-Servic

e

retry timer

If no more queued calls

0

1

The queuing is done at RNC level.

The queuing is allowed for RAB Assignement procedure only.

When the queuing decision is taken, an allocation retry timer is set and the resource allocation request is retried when the timer elapses (end of congestion is not used as trigger):

The pre-empted resources might be not re-allocated to the particular service that triggered the preemption.

The preempted resources may be allocated to a service having the same or higher priority and the same or higher

OLS compared with the service that triggered the preemption.

The RAB matching or/and the IRM table procedures have to be processed at each resource allocation request (re-)attempt in order to set the target Asconf (UL and DL) to be served.

The resource allocation request is retried until resource is available or max number of retries is reached.

As the RANAP RAB Assignment is constrained at the Core Network level by the timer TRabAssig , the following relationship has to be checked:

preemptionQueuingReallocationTimer * preemptionQueuingReallocationRetryMaxNumber < TRabAssig

Moreover, an attribute preemptionQueuingReallocationPriority is defined for each PService.

The possible values are:

• Priority reallocation

• Regular reallocation

As soon as the pre-emption is triggered on a given cell and a RAB Assignment Request is queued, the cell goes from “Normal state” to “Cell pre-emption state” and a resource allocation filtering is performed in order to restrict the allocation in the congested cell.






6.12 Feature dependencies

Fair sharing of resources

33694

GBR on HSDPA

29804

Preemption

33322Upon CAC Failure

Shared resources (R99 & HSDPA) : OVSF Codes & DL Power

Dedicated resources : CEM (Node B)

Common Call Admission Control between HSDPA and R99 usersfor OVSF Codes and DL Power

Min QoS ensured for HSDPA users (PS Streaming & PS I/B)

MinBR & GBR transmitted (optionally) to the Node B

MAC-hs scheduler to ensure the QoS of HSDPA users (MinBR & GBR)

Power consumption Node B feedback to RNC (needed for fair-sharing)

Fair-sharing is mandatory for Pre-emption

The Fair sharing feature (FRS 33694) activation is mandatory before the activation of the Pre-emption feature.






6.13 Feature Interactions

iMCTA CAC & Alarm

29415

HSxPA to DCH fallback

32602

Preemption

33322

Will be triggered first for HSxPA incoming users.

Depending on CAC failure, fallbacks 1 step / 2 steps may betried :

• DL HSDPA / UL R99• DL DCH / UL DCH

If HSxPA to DCH fallback is activated, iMCTA CAC will not betriggered upon HSxPA CAC failure.

A incoming HSxPA user will first go through the HSxPA to DCH fallback algorithm. On R99 failure, iMCTA CAC will be triggered

Preemption will be called as last chance, after HSxPA to DCH fallback and iMCTA (according to applicability of each

algorithm)

This feature is exclusive with Fair-sharing when the CAC failure is Internal (shared

resource)

Rescue mechanisms on CAC failures

The UA4.1 & the UA6.0 Pre-emption may run in parallel. There is no interaction between the 2 mechanisms.

Other mechanisms may be used (if they are activated), before invoking Pre-emption, to solve a CAC failure situation. They are, in order:

HSxPA to DCH fallback(HSxPA-to-DCH fallback is not allowed, when CAC occurs for shared resources (DL OVSF codes or DL power)).

iMCTA





Exercise1: RAB Assignment Queuing and Pre-emption

Scenario:Preamption setting:

preemptionQueuingReallocationTimer = 1500, preemptionQueuingReallocationRetryMaxNumber = 2At T1 the incoming service S1 with priority P1 fails to allocate resources on the cell C

The preemption is triggeredAt T2 the incoming service S2 with priority P2 higher than P1 asks for resources on cell CAt T4 the incoming service S3 with priority P3 > P1 ask for resources on cell CAt T1:

What happen at T1?What is the highest cell C preemption priority level ?

Same questions for T2, T3, T4, T5 and T6 (T3-T1 = T5-T3 = T6-T4 = 1,5s)

Cell C Queuing State ?

Enough resources areavailable for S1 or S2

T2 T3 T4T1 T6

Enough resources areAvailable for S1 or S3

(S1, P1) (S2, P2) (S3, P3)

Time

P? P? P? P?

T5





Exercise2: Estimation of Resource De-allocation

AssumptionspreemptionDeallocationFactorInDownlink [High,Low] = [200,120] (unit=%)preemptionDeallocationThresholdInDownlink = 16 (kbps)

Question: Estimates (in kbps) the quantity of DL resource to be de-allocated in

order to servea PS Streaming call at 128 kbps downlink bit rate ?a CS AMR speech call at 12,2 kbps bit rate ?





7 AMR Rate Change during the Call





DL Tx CP


7.1 General Principles

UL Cell Load

RNC

Maintain the speech call in UMTS (i.e. avoid redirection to 2G layer) even at the expense of the PS call

DSIub

DL Power Load

Max AMR RateRedirection

Differentiation per subscriber OLS

Greatest number of CS speech calls/cell with the

constraint of limitedresources

IsAmrRateControlDuringTheCallAllowed(RadioAccessService)

isAmrRateControlOnULCellLoadAllowed

isAmrRateControlOnDlPowerLoadAllowed

isAmrRateControlOnIubDsLoadAllowed

(RadioAccessService)(DlUserService)

Iub DS Load

Principle

Up to release UA04.2 the bearer service support for AMR was restricted to monomode AMR, i.e. bearer service support for AMR 12.2 and support of silent mode (aka SCR (VAD/DTX)) with use of version 1 of Iu UP.

The features 18717 “AMR-NB multi-mode support” and 30229 “Iu UP SMpSDU V2” provide the bearer service support with use of version 2 of Iu UP for a number of narrowband AMR speech service and the support of a number of functions to allow core network Transcoder / Tandem Free mode of Operation (TrFO/TFO) speech calls.

Multimode AMR support offers:

Downlink capacity gain in term OVSF code resource. SF 256 can be used for AMR Low Rate configuration.

Downlink capacity gain in term of radio resource. The required signal to interference ratio depends on the required throughput. Therefore a lower AMR throughput will require less power.

UL coverage gain. The required transmitted power will be reduced for lower AMR rate.

AMR Rate Control

In UA5.0, RNC does not initiate Iu rate control towards the CN except in relocation scenarios.

If Iu UP used is version 2, RNC may receive Iu rate control from the CN in case of TrFO/TFO. When that happens, RNC triggers an RRC TFC control indicating the new max allowed rate in the uplink.

SRB2 is used to carry the RRC TFC control message.






7.1.1 General Principles [cont.]

The DL AMR rate is based on the observed amount of DL power consumption and is selected according the following rule:

•DL Requested MBR ≥ rate > DL Requested GBR

Rule: Eligible DL AMR Rates

The UL/DL AMR rate is based on the observed Iub DS load, in addition of the above rule, the following one is fulfilled:

•UL Requested MBR ≥ rate > UL Requested GBR

Rule: Eligible UL/DL AMR Rates


RNC

DL:

•Any rate control done

•Max Bit Rate = 12.2 kbps

UL:

•Rate control on UL cell load

•Max Bit Rate is selectedUL Cell Color

Max AMR Rate

Call Establishment

During the Call

RNC

RRC TFC ControlCN

Iu UP rate Control

delayBetweenAmrRateControls(RadioAccessService)

During the call, no Radio Bearer adaptation based on cell load (power, code) is performed. The allocated RB (speech part) is kept unchanged. During the call, the RNC will only control the AMR rate. The principle is the following:

At the establishment, once the UE is eligible for AMR rate control, the RNC will performs:

In downlink, any rate control done. The maximum rate 12,2Kbps is given at establishment.

In uplink, a rate control is performed on the UL Cell Load criteria which give the maximum rate at call establishment.

During the call, driven by rate control triggers, the RNC adjusts AMR rates by initiating RRC TFC control on uplink and Iu UP rate control on downlink.

Procedure description:

Depending on the outcome of the IUB load table, the RNC initiates

DL Rate control: Iu UP Rate Control frame sent to core network

UL rate control: RRC TFC control message sent to UE

Whenever applicable, the rate is decreased step by step, this means that several Iu UP rate control / RRC TFC control messages may be successively sent.






7.2 Iub DS load criteria

I u b D S t r a n s p o r t

C o l o u r

O L S M a x A M R r a t e

G o l d e . g . 1 2 . 2G R E E N S i l v e r e . g . 1 2 . 2

B r o n z e e . g . 7 . 9 5G o l d e . g . 1 2 . 2

Y E L L O W S i l v e r e . g . 7 . 9 5B r o n z e e . g . 5 . 9

G o l d e . g . 5 . 9R E D S i l v e r e . g . 4 . 7 5

B r o n z e e . g . 4 . 7 5

The Max AMR rate = min (output of the iRM table, max requested AMR rate) This value is used to identify the Iub transport equivalent bit rate (EBR), which will be used as input of the Iub CAC.

Rule : Determination of the Max AMR rate on Iub

RNC

DS

Iub

Max AMR Rate

Symetric service: DL load estimation only

Table is played• After any mobility event, to help determine the new max UL/DL rate• In static state, determine possible UL/DL rate change by checking the Active Set Iub DS DL load color every configurable period.

Iub DS Load

A specific iRM table is introduced to determine the max allowed AMR rate based on the OLS and the Iub DS DL load color of the Active Set.

The Iub DS load is only calculated for the DL assuming that in most of the cases the traffic over Iub DS is rather symmetric or asymmetric services with higher rate in the DL.

In order to avoid any ping pong effects due to the application of different criteria, the downlink rate upgrade is not triggered based on Iub DS load colour change. Only the trigger of TxCP measurement report is used to upgrade the rate of an AMR call.






7.3 UL Cell load criteria

A specific UL iRM table is introduced to determine the max allowed AMR rate based on the OLS and the UL cell load color of the cells in the active set. This table is played as follow:

Output

UL rate control: RRC TFC control message sent to UE

U L c e l l l o a d C o l o r



B r o n z e e . g . 7 . 9 5G o l d e . g . 1 2 . 2



B r o n z e e . g . 4 . 7 5

In static state, determine possible UL rate change by checking the UL cell load color of the Active Set every configurable period (Cf. parameter delayBetweenAmrRateControls)

At admission to help determine the max initial UL rate based on the UL cell load color of the cells of the Active Set

After every primary cell update, to help determine the new max UL rate based on the UL cell load color of the cells of the Active Set

Multi-service: The AMR rate control based on radio criteria (UL Cell Load) does not apply for multi-service

Restriction:

The cell load color is calculated as follows:

UL cell load color = max (UL radio load color, UL

CEM load color)

•· With green < yellow < red

The UL Cell Loaddoes not take into account the load

generated by the E-DCH traffic.






7.4 DL Power load criteria

A specific DL iRM table is introduced to determine the max allowed AMR rate based on the OLS and the DL power load color of the cells of the active set. This table is played per individual call:

Output

DL Rate control: Iu UP Rate Control frame sent to core network

In static state, determine possible DL rate change by checking the DL power load color of the Active Set every configurable period (Cf. parameter delayBetweenAmrRateControls)

After every primary cell update, to help determine the new max DL rate based on the DL power load color of the cells of the active set

T o t a l D L T x P o w e r l o a d

C o l o r



B r o n z e e . g . 7 . 9 5G o l d e . g . 1 2 . 2



B r o n z e e . g . 4 . 7 5

Multi-service : The RNC initiated AMR rate control based on radio criteria (Total DL Tx Power load) does not apply if PS RAB(s) mapped on DCH (whereas it applies if PS RAB(s) mapped on HSDPA)

Restriction for Multi-servciewith PS on DCH:

The DL Total TxPower does not

include the power of the PA used by

HSDPA






7.5 DL Tx CP criteria

The dedicated measurement is initiated on the primary cell at call establishment or whenever there is a change of

the primary cell

Dedicated measurements initiation

Thresholds Rules for Downlink TxCP criteria

maxDlTxPower = maxDlTxPowerPerOls[CurrentOls].maxDlTxPower

RateDecThreshold = pcpichPower + maxDlTxPower ? dlAmrRateDecreaseTxcpTrigger.thresholdDeltaRateIncThreshold = pcpichPower + maxDlTxPower ? dlAmrRateIncreaseTxcpTrigger.thresholdDeltaWheredlAmrRateDecreaseTxcpTrigger.thresholdDelta ? dlAmrRateIncreaseTxcpTrigger.ThresholdDelta

Time To Trigger value determination for Downlink TxCP criteria

RateDecTTT = dlAmrRateDecreaseTxcpTrigger.timeToTrigger

RateIncTTT = dlAmrRateIncreaseTxcpTrigger.timeToTrigger

t

DL Tx Code Power

DL TX Max Power

DL TX Min Power

Rate Dec Th

Rate Inc Th

1. Crossing of the Threshold triggers DL Rate

Change Request after a TimeToTrigger

2. Rate Change↓12.2 → 5.9

3. Crossing of the Threshold triggers DL Rate Change Request

4. Rate Change ↑5.9 → 12.2

Rate Change on DL Tx Code PowerEvent triggered (A/B)

NBAP Event A

NBAP Event B

Iu UP Rate Control (new Max DL rate) to

the Core Network

Iu UP Rate Control (new Max DL rate) to

the Core Network

RateDecTTT

RateIncTTT

DL Tx CP

At establishment of a speech bearer eligible to rate control, the RNC configures NBAP dedicated measurement reporting on the primary cell in order to track the DL Transmitted Code Power.

Thus, the ALCATEL-LUCENT RNC can detect deterioration or improvement of radio conditions through NBAP dedicated measurements on the transmitted code power.

DL Tx CP criteria: Dedicated measurements configuration

In order to detect a rate decrease / increase condition, the RNC configures dedicated measurement reporting with the following characteristics.

Measurement quantity = transmitted code power (Radio Link)

Reporting mode = event triggered

Event = A / B

Threshold1 = RateDecThreshold

Threshold2 = RateIncThreshold

Time to trigger = RateDecTTT / RateIncTTT. This time to trigger indicates the time during which the threshold condition should be fulfilled before the UE sends the event to the RNC.






7.6 Parameters Settings

Activation of the UL Cell Load criteriaThe AMR rate control based on uplink cell load criteria can be activated at the RNC level

and per DlUserService. To activate it, the parameter isAmrRateControlOnULCellLoadAllowed should be set to TRUE.

RNC

RadioAccessService

DLUserService UlIrmTableCellLoadConfClass

IrmAmrRateList

IrmAmrRatePerOls

isAmrRateControlOnUlCellLoadAllowed

irmAmrRate4_75k, 5_15k, 5_9k, 6_7k, 7_4k, 7_95k,

10_2k, 12_2k

delayBetweenAmrRateControls

isAmrRateControlOnUlCellLoadAllowed






7.6.1 Parameters Settings [cont.]

Activation of the DL Power Load criteriaThe AMR rate control based on DL Power Load criteria can be activated at the RNC level

and per DlUserService. To activate it, the parameter isAmrRateControlOnDlPowerLoadAllowed should be set to TRUE.

RNC

RadioAccessService

DLUserService DlIrmTablePowerLoadConfClass

IrmAmrRateList

IrmAmrRatePerOls



10_2k, 12_2k









Activation of the Iub DS Load criteriaThe AMR rate control based on Iub DS Load criteria can be activated at the RNC level and

per DlUserService. To activate it, the parameter isAmrRateControlOnIubDsLoadAllowedshould be set to TRUE.

RNC

RadioAccessService

DLUserService DlIrmTableIubDsLoadConfClass

IrmAmrRateList

IrmAmrRatePerOls



10_2k, 12_2k









Activation of the Downlink Tx CP criteria

Threshold = pcpichPower + maxDlTxPowerPerOls[].maxDlTxPower – thresholdDelta

RNC

RadioAccessService

DLUserService DedicatedConf

PowerConfClass

DlUsPowerConf

DlAmrRateDecreaseAbsoluteTxcpTrigger

DlAmrRateIncreaseAbsoluteTxcpTrigger

Threshold

timeToTrigger

Threshold

timeToTrigger

DlAmrRateDecreaseTxcpTrigger

DlAmrRateIncreaseTxcpTrigger

thresholdDelta

timeToTrigger


maxDlTxPowerPerOls

thresholdDelta

timeToTrigger





Module Summary

This lesson covered the following topics:Packet data management principles

Always On and associated parameters

RB Rate Adaptation and associated parameters

iRM Scheduling and associated parameters

iRM Preemption and associated parameters

Preemption and associated parameters













All Rights Reserved © Alcatel-Lucent 20093JK10052AAAAWBZZA Edition 1.1




Section 8Power Management






9300 W-CDMA · UA06 R99 Algorithms DescriptionPower Management8 · 2

Blank Page


Parameter initialUlSirtarget changed to initialSirtarget



2009-02-2901


Document History





Module Objectives


Describe power management static configuration

Describe PRACH Power Control and associated parameters

Describe UL Power Control and associated parameters

Describe DL Power Control and associated parameters

Describe Radio Link Control and associated parameters











Table of Contents


1 Power Management Static Settings 71.1 Downlink Power Settings 81.2 Cables Losses without TMA 91.3 Cables Losses with TMA 101.4 Common Channel Power Settings 111.5 Dedicated Channel Power Settings 12

2 PRACH Power Control 132.1 PRACH Open Loop 14

3 UL DPCCH Open Loop Power Control 153.1 DPCCH Open Loop Power Control 163.2 UL Gain Factors 173.3 UL DPCCH / DPDCH Power Ratio 183.4 UL Rate Matching Attributes 19

4 Outer Loop Power Control 204.1 SIR Target Management 214.2 Partial SIR Target Update 22

5 UL Inner Loop Power Control 235.1 DPCCH Inner Loop Power Control 245.2 UL Inner Loop Power Control 255.3 UL Power Control Algorithms 265.4 UL Inner Loop Algorithm 1 275.5 UL Inner Loop Algorithm 2 (no SHO case) 285.6 UL Inner Loop Algorithm 2 (SHO case) 29

6 DL Traffic Channel Power 306.1 Initial DL Traffic Channel Power 316.2 DL DPCCH / DPDCH Power Offsets 32

7 DL Outer Loop Power Control 337.1 DL Outer Loop Power Control 34

8 DL Inner Loop Power Control 358.1 DL Inner Loop Algorithm 368.2 Power Balancing 378.3 Rate Reduction Algorithm 38

9 Radio Link Control 399.1 UL Dedicated Channel Synchronization 409.2 UL Radio Link Failure – detected by UTRAN 419.3 DL Radio Link Failure – detected by UE 429.4 DL RLC Unrecoverable Error – detected by UTRAN 439.5 UL RLC Unrecoverable Error – detected by UE 449.6 RRC Connection re-establishment Parameters 459.7 UL Radio Link Failure – RRC Connection Re-established 469.8 UL RLC Unrecoverable Error – RRC Connectn Re-established 479.9 RRC Connection re-establishment - Summary 48












1 Power Management Static Settings






1.1 Downlink Power Settings

F1

F2

paRatio (BtsCell)

paRatio (BtsCell)

maximumPowerAmplification (BtsCell / PaResource)

Cell Setup

MaxTxPower (Cell) = MIN ( , MaxDlPowerCapability)maxTxPower

maxTxPower (FDDCell->Class2CellReconfParams / FDDCell->Class3CellReconfParams )

maximumPowerAmplification (BtsCell)MaxDlPowerCapability = paRatio (BtsCell)x - Global Losses

F3

paRatio (BtsCell)

At cell setup, the RNC calculates the max Tx Power, which is the maximum power that will be used to configure the cell:

Max Tx Power (FDDCell) = min (Max Tx Power Required, Max DL Power capability)

At the Node B level, the power is owned by Power Amplifiers which can be shared by multiple cells.

In Alcatel-Lucent configurations, cells on the same sector but on different carriers may share or not the same Power Amplifier. This capability should allow optimization of the use of the PA. The sharing of power between different cells associated with the same PA is static. A configuration parameter at the OMC-B (called PA_Ratio) allows sharing of a PA power between 2 cells. From an RNC perspective, the sharing is transparent.

maximumPowerAmplification can take one of the following values:for BTSCell object = {reducedMode, fullMode}for PaResource object = {fullMode, max30W , max45W , max60W , max85W}

As the names indicate:- the object class2CellReconfParams contains Class 2 parameters- the object class3CellReconfParams contains Class 3 parametersAt the RNC side: Depending on the value of the parameter isCellReconfSupported (NodeB), the RNC knows if the NodeB supports the Cell Reconfiguration procedure or not.

If it does not, the Class 2 parameters are applied.If the NodeB supports the Cell reconfiguration, the RNC takes the Class 3 parameters. When they are changed online, the RNC send the Cell Reconfiguration procedure

At the OMC side:If isCellReconfSupported is False, then the OMC maintains Class 2 and Class 3 parameters aligned : every

change on Class 3 parameters implies an update of Class 2 parameters and then a Cell lock/unlock.If isCellReconfSupported is True, the Class 3 parameters are no more linked to Class 2 parameters and

may be changed on-line (without Cell lock/unlock)






1.2 Cables Losses without TMA

externalAttenuationXXXDl = 0

MCPA Tx Splitter DDM

BTS

Reference point

Global Losses = Internal Losses

externalAttenuationXXXDl ≠ 0


BTS

Reference point

Global Losses = Internal Losses + externalAttenuationXXXDl

externalAttenuationMainDl (AntennaAccess)

externalAttenuationDivDl (AntennaAccess)

tmaAccessType (AntennaAccess)

Computation of losses is not the same, depending on:

parameters externalAttenuationMainDl and externalAttenuationDivDl of the AntennaAccessobject

TMA configuration

Cable Losses without TMA.

If externalAttenuationXXXDl = 0, the transmission power reference point is defined at the antenna connector of the BTS. In this case the Global Losses refer only to internal cabling losses (typical value = 0.8 dB) and DDM insertion losses (typical value = 0.5 dB).

For OTSR configurations additional losses must be taken into account:

Tx Splitter insertion losses (typical value = 0.3 dB)

Additional cabling between Tx Splitter and DDM (typical value = 0.3 dB)

If externalAttenuationXXXDl ≠ 0, the transmission power reference point is defined at the antenna connector after the RF feeder (antenna side).

In this case, the reference point is the point so that losses between the BTS feeder connector (out put of the cabinet) and this point are equal to the datafilled value of externalAttenuationXXXDl.






1.3 Cables Losses with TMA

externalAttenuationMainDl (AntennaAccess)

externalAttenuationDivDl (AntennaAccess)

tmaAccessType (AntennaAccess)

externalAttenuationXXXDl ≠ 0


BTS

Reference point

Global Losses = Internal Losses + externalAttenuationXXXDl+ TMA Insertion Losses +Jumper Losses

TMA

externalAttenuationXXXDl = 0


BTS

Reference point

Global Losses = Internal Losses+ Feeder Losses+ TMA Insertion Losses +Jumper Losses

TMA

When a TMA is specified (tmaAccessType = tmaUmtsOnly or tmaMix), the transmission power reference point moves to the antenna port of the TMA. Additional losses are taken into account:

TMA insertion losses are equal to 0.3 dB in the transmission path

jumper losses are set to 2*0.6 dB (0.6 dB for each jumper)

If externalAttenuationXXXDl is set to 0, the feeder losses are equal to 2 dB. Otherwise the feeder losses are equal to the datafilled value of externalAttenuationXXXDl .






1.4 Common Channel Power Settings

Traffic Power (SHO

reserved)

Traffic Power

Overhead Power

(Common Channels)

PCHpichPowerRelativeToPcpichPICH

RACHaichPowerRelativeToPcpichAICH

SCCPCHsccpchPowerRelativeToPcpichS-CCPCH

FDDCell*bchPowerRelativeToPcpichP-CCPCH

FDDCell*sschPowerRelativeToPcpichS-SCH

FDDCell*pschPowerRelativeToPcpichP-SCH

FDDCell*pcpichPowerPCPICH

ObjectparameterChannel

Node B

FDDCell* ⇔ FDDCell-> Class2CellReconfParamsor

FDDCell-> Class2CellReconfParams

In the slide, the Pilot power, that is, the P-CPICH power is defined by the pcpichPower parameter of the FDDCell object as an absolute value in dBm, referenced at the BTS antenna connector.

All the other common channel powers are given relative to the P-CPICH level.

Because of the check in the BTS (CCM) at call setup, this relationship must be true for maxTxPowerand PcpichPower: PcpichPower > MaxTxPower - 15 dB.

A sensor at the output of the MCPA allows measurement of the effective output power of the amplifier. The range of sensitivity of this sensor is [25 dBm..46.5 dBm]. So as to be sure to detect power, it is recommended that the Pcpich Power (at PA Output) is higher than the minimum sensibility of this sensor).

PcpichPower > 25 dBm-total_losses_between_PA_output_and_reference_point

P-CPICH power is recommended to be set at:

35 dBm in case of one channel

the half (32 dBm) if two carriers are supported by the same PA

At the RNC side:Depending on the value of the parameter isCellReconfSupported (NodeB), the RNC knows if the NodeBsupports the Cell Reconfiguration procedure or not.

If it does not, the Class 2 parameters are applied.If the NodeB supports the Cell reconfiguration, the RNC takes the Class 3 parameters. When they are changed online, the RNC send the Cell Reconfiguration procedure

At the OMC side:If isCellReconfSupported is False, then the OMC maintains Class 2 and Class 3 parameters aligned : every

change on Class 3 parameters implies an update of Class 2 parameters and then a Cell lock/unlock.If isCellReconfSupported is True, the Class 3 parameters are no more linked to Class 2 parameters and

may be changed on-line (without Cell lock/unlock)






1.5 Dedicated Channel Power Settings

DedicatedConf

RadioAccessService

PowerConfClass

DlUsPowerConf UlUsPowerConf

maxTxPower (FDDCell*)

powerConfId (FDDCell)

minDlTxPower (DlUsPowerConf)

maxDlTxPowerPerOls (DlUsPowerConf)max UE Tx Power (UE Power Class)

FACHmaxAllowedUlTxPower (UlUsPowerConf)

, Max UE Tx Power)Max UL Tx Power = MIN( maxAllowedUlTxPower (UlUsPowerConf)

Part of the Dedicated Channels power management relies on static settings.

This is for example the case in downlink for the maximum power per carrier and the upper and lower bounds of the traffic channel. It is important to note that these two last parameters are not necessarily the same for all UEs communicating in the cell, as different values are used depending on the radio bearer.

Static settings are also used to define the maximum allowed transmission power in UL per User Service. It represents the total maximum output transmission power allowed for the UE and depends on the type of service required. The information will be transmitted on the FACH, mapped on the S-CCPCH, to the UE in the RADIO BEARER SETUP message of the RRC protocol.

Consequently, whenever a radio bearer is set up or reconfigured, when a transport or a physical channel is reconfigured, when a RRC connection is setup or re-established, when the active set is updated or when a handover is performed from GSM to UTRAN, a new value may be decided by the RNC (Control Node) for the parameter maxAllowedUlTxPower and this parameter shall be re-transmitted to the UE.





2 PRACH Power Control





constantValue (RACH)SIB 5SIB 5

2 PRACH Power Control

2.1 PRACH Open Loop

NACK NACK NACK ACK

Message part

PRACHControl part

PRACHData part

Pini

Pini = + RTWP + - P-CPICH_RSCP

powerOffsetPO(RACH)

sibMaxAllowedUlTxPowerOnRach (PowerConfClass)

Preamble part

betaC

(RACHSignalledGainFactors)

betaD

pcpichPower(FDDCell*)

AICH

powerOffsetPpm(powerOffsetPpMx)SIB 5SIB 5

SIB 5SIB 5

SIB 5SIB 5

SIB 5SIB 5

SIB 5SIB 5

SIB 7

The PRACH consists of:

A preamble part which is sent by the UE and repeated until either an Acquisition Indicator (ackor nack) is received over AICH or the preamble retransmission counter reaches its max value (parameter provided by the network). The first preamble is transmitted with a power of “Preamble initial power”. Each consecutive preamble is transmitted with a power equal to the previous one plus a ‘power ramping step”. “Preamble initial power “is calculated by the UE based on parameters sent on SIB5 and SIB7 and on CPICH RSCP measured by the UE. “power ramping step” is a UTRAN parameter sent to the UE over SIB5.

A message part which is sent after an acknowledged Acquisition indicator. This message part is composed of a control part and a data part. The power of the control part is equal to the power of the last preamble sent plus Pp-m which is a UTRAN parameter sent over SIB5. The power of the data part is derived from the power of the control part through (βc,βd) parameters per TFC also sent by the UTRAN over SIB5. βd/βc defines the relative power between the control part and the data part.

Notes

RTWP: corrective term evaluating the average interference level on UL. In the Alcatel-Lucent implementation, this is not a parameter. It corresponds to the UL RTWP measured by the Node B. It is broadcast in SIB 7.

constantValue: corrective term to compensate for shadowing effects. It is broadcast in SIB 5.

powerOffsetPpM0 is the power offset between the last transmitted preamble and the control part of 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.





3 UL DPCCH Open Loop Power Control






3.1 DPCCH Open Loop Power Control

Pini (UL DPCCH) = – P-CPICH_RSCPdpcchPowerOffset (UlInnerLoopConf)

UL DPCCH Tx at Pini

S-CCPCH or FACH

“Uplink power control info” IEDedicatedConf

RadioAccessService

PowerCtrlConfClass

UlInnerLoopConf

dpcchPowerOffset

When establishing the first DPCCH, the initial power used by the UE to start the UL DPCCH transmission is:

DPCCH_Initial_power = dpcchPowerOffset – CPICH RSCP

It is provided by the RNC to the UE via RRC signaling (FACH / S-CCPCH), in the “Uplink power control info” IE or in the “Uplink power control info short” IE.

These IEs are included (one or the other) in the RRC messages of the radio bearer setup, reconfiguration and release, transport channel and physical channel reconfiguration, RRC connection setup and re-establishment and in the handover to UTRAN command.






3.2 UL Gain Factors

I

Q

OVSF1 bd

UL DPDCH

OVSF256,0 bc

UL DPCCH

ModulationUE

Scrambling code

The figure above illustrates the principle of the uplink spreading of DPDCH and DPCCH. The first step, the NRZ modulation, consists in associating a real signal to each bit of these channels. The binary value “0” is mapped to the real value +1 and the binary value “1” is mapped to the real value -1. Then, each channel is spread by an OVSF code. As it was mentioned before, channelization codes are only used to spread the information in uplink (not for channel multiplexing) because synchronization between UEs is too complex to achieve.

The channelization code used for DPCCH is always Cch,256,0 (all ones).

If only one DPDCH is used, it is spread by code Cch,SF,k , where k is linked to SF by k=SF/4. When more than one DPDCH is used, they will all have a SF equal to 4.

After channelization, the spread signals are weighted by a gain factor (βc for DPCCH and βd for DPDCH). These gain factors are quantized into 4 bits, giving values between 0 and 1. There is at least one of the values βc and βd that is equal to 1. These gain factors may vary for each TFC, and are either signaled or computed.

Then, the streams of chips are summed up giving a multilevel signal. After this addition, the real-valued chips on the I and Q branches are summed up and treated like a complex-valued stream of chips. This stream is scrambled by a complex-valued scrambling code. For DPDCH and DPCCH, a unique scrambling code of 38,400 chips (corresponding to one radio frame) is used. That code can be either of long or short type.

Finally, the complex chips are I and Q multiplexed and sent over the air interface. The result of all this is a BPSK modulation, which gives us 1 bit per symbol.






3.3 UL DPCCH / DPDCH Power Ratio

CSDTCH12_2Kx4SRBDCCH3_4K2PSDTCH64Kx4SRBDCCH3_4KCSDTCH12_2Kx2PSDTCH64Kx4SRBDCCH3_4K

PSDTCH64Kx4SRBDCCH3_4KPSDTCH384Kx4SRBDCCH3_4KStandaloneSRBDCCH3_4K...



refTfcId

betaC

betaDrefTfcId

betaC

betaDrefTfcId

betaC

betaDTFC 0

UlUserServiceRNCSignalledGainFactor

ComputedGainFactorRNC

refTfcId

refTfcId

betaC

betaD

TFC 1

TFCS #2

Signaled Mode

Computed Mode

refTfcId

betaC (SignalledGainFactor)

betaD (SignalledGainFactor)

refTfcId (SignalledGainFactor)

betaC (ComputedGainFactor)

betaD (ComputedGainFactor)

refTfcId (ComputedGainFactor)

CSDTCH64Kx4SRBDCCH3_4K

UlUserService


For a given Access Stratum configuration, corresponding to one precise UlUserService object instance, some TFCs have their betaC and betaD values defined through betaC and betaD parameters respectively, whereas some other TFCs use reference TFCs to deduce their own betaC and betaDvalues.

In order to give a reference identity to a TFC, to declare it as a possible reference TFC for other TFCs, an optional parameter named refTfcId (SignalledGainFactor object) is used.

Once the reference TFCs are declared, some other TFCs of the TFCS (under the same UlUserServiceinstance) can be provisioned as computedGainFactors instances (mode “computed” chosen at the OAM in the RNC MIB).

For each of them, there is a pointer on a reference TFC in order to indicate from which betaC and betaD values the TFC shall compute its own betaC and betaD values:

This pointer to a reference TFC corresponds to refTfcId parameter in the computedGainFactorobject.

This parameter corresponds to the identity of a reference TFC set through refTfcId parameter in SignalledGainFactor object.






3.4 UL Rate Matching Attributes

SRBDCCH3_4KCSDTCH12_2K

PSDTCH64KPSDTCH128KPSDTCH384K2PSDTCH64K...

UlRbSetConf

SRBDCCH3_4KCSDTCH12_2K


S-RNC UlRateMatchingAttributeList

D-RNC

ulRateMatchingAttributeList

DynamicParameterPerDCH

iurMinRateMatchingAttributeiurMaxRateMatchingAttribute

CSDTCH64K

UlRbSetConf

CSDTCH64K

Rate matching is done to adapt the bit rate so that after transport channel multiplexing, the bit rate is adapted to the capability of the underlying physical channel.

Rate matching consists of repeating or puncturing bits in the radio frame. Each Transport Channel is assigned a rate matching attribute by higher layers. This attribute is used to calculate the number of bits to be repeated or punctured.

Rate matching attribute (part of the transport format) is used to control the relative rate matching between different transport channels multiplexed together onto the same physical resource. By adjusting this attribute the quality of different services can be fine tuned to reach an equal or near-equal symbol power level requirement.

In UL, rate matching may vary on a frame-to-frame basis to fill up the physical channel. The Uplink rate matching attribute is strongly related to DPDCH/DPCCH power difference and therefore to the appropriate behavior of UL power control and resulting UL Quality of Service.

Note: A check is done by the Drift RNC when receiving a RNSAP Radio Link Setup message regarding the value of the uplink rate matching attribute, so that the value belongs to a specific range, given by the two attributes iurMinRateMatchingAttribute and iurMaxRateMatchingAttribute.





4 Outer Loop Power Control





4 UL Outer Loop Power Control

4.1 SIR Target Management

CSDTCH12_2K




initialSirTarget (UlUsPowerConf)

blerTarget(BlerQualityList)

New SIR Target

(NBAP)

CRCI

RNC

PartialOLPC

UlUserService


UlRbSetConf

CSDTCH64K

SRBDCCH3_4K

blerTarget(BlerQualityList)

CRCI

PartialOLPC

OLPCMaster

SIR TargetUpdate

referenceUlRbSetConfId(ReferenceUlRbSetList)

isUlOuterPCActivated (UlOuterLoopPowerCtrl)

The initial SIR target is sent by the RNC to the Node B through initialSirTarget parameter. This parameter is instantiated per RAB. Consequently, once the RNC has matched a RB onto the RAB requested by the Core Network, it points to the initial SIR target value corresponding to this RB in the initialSirTarget parameter. This value is transmitted to the Node B using NBAP signaling at each RADIO LINK SETUP or reconfiguration.

For each UlUserService, the list of radio bearers (UlRbSetConf) used in the multiple reference OLPC is given through the referenceUlRbSetConfId parameter.

The outer loop power control algorithm takes into account all transport channels. For each transport channel a separate outer loop machine is run. Each outer loop machine updates its partial SIR target according to its transport channel quality target (UlBlerTarget) as soon as it receives at least one transport block CRC. The partial SIR target is then sent to the outer loop power control master.

The OLPC master determines the new SIR target as:

The maximum partial SIR target if at least one OLPC machine increases its partial SIR target

The minimum partial SIR target if all OLPC machines reduce their partial SIR target

Whenever the new SIR target is different from the old one, it is sent to the Node B.





4 UL Outer Loop Power Control

4.2 Partial SIR Target Update

minSirTarget (UlUsPowerConf)

maxSirTarget (UlUsPowerConf)

SIR Target

TTI

transmitTimeInterval (static)

If CRCI bad

SIR Target

If CRCI good

SIR Target

ulUpSirStep

ulUpdatePeriod (UlOuterLoopPowerCtrl)Update Period = Max [TTI of ReferenceUlRbSetList] x

ulUpSirStep (DynamicParameterPerDch)blerTarget (BlerQualityList)

ulUpSirStep

1BlerTarget

- 1

updateThreshold (DynamicParameterPerDch)Triggered Update if SIR Variation ≥

The RNC computes actualized partial SIR targets every TTI. The TTI value in milliseconds is given by the transmitTimeInterval static parameter relative to the TrCHs used as references for the outer loop power control. The reference TrCHs depends on the service type.

Each outer loop machine updates its partial UL SIR target according to its transport channel UL quality target (BlerTarget) as soon as it receives at least one transport block CRC. An update from each OLPC machine to the OLPC master is sent every update period or if the SIR target variation exceeds an upper limit (updateThreshold).

The update period is defined by ulUpdatePeriod, and is provided in a number of TTIs.

Whenever the new SIR target is different from the old one, it is sent to the Node B.

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.





5 UL Inner Loop Power Control






5.1 DPCCH Inner Loop Power Control

DL DPCCH Tx Power Commands

New UL DPCCH Tx power

Data1PLTPC

TFCI Data2 PL

The Uplink Power Control is controlled by the NodeB which orders Power Control Command (increase or decrease) through TPC bit in DL DPCCH channel.

The UE then applies the PC command at the next UL DPCCH transmission.

DPDCH power is then adapted thanks to gain factors as seen previously.






5.2 UL Inner Loop Power Control

Rake

SIRestimate

SIRTarget

> or <TPC0 or 1

Pilot

TPC

DPCCH

• Down Command: if SIRestimate > SIRtarget then TPC = 0

• Up Command:if SIRestimate < SIRtarget then TPC = 1

The uplink inner loop power control algorithm is located in the Node B physical layer. It is a fast procedure (up to 1500 Hz power change rate) used to derive power control commands (to be applied by the UE) from the SIR target (set by the RNC) and UL measurements.

The Node B estimates the instantaneous SIR on the pilot bits received on the UL DPCCH and compares it to the SIR target signaled by the RNC. In case the instantaneous SIR is lower (respectively higher) than the target SIR, an up (respectively down) command is sent to the UE in the downlink DPCCH TPC field of each DPCCH radio time slot:

up command: TPC = 1

down command: TPC = 0

In every slot, there is either an up or a down power control command: this process does not provide good stability of the transmission power.

TPC commands are computed in each Node B independently from the others, so if the UE is in Soft Handover with several Node Bs, the TPC commands received from the different Node Bs may be conflicting. In the case of a softer handover, the unique Node B involved sends the same TPC command on all the radio links of the same radio link set.






5.3 UL Power Control Algorithms

Soft handoverpossibly different TPC commands

Softer handover

identical TPC commands

for the radio link set

2 RLs

Node B 1 1 RL

SIR target

SIR targetTPC2

TPC1

In case of soft HO(i.e. TPC1 ¹ TPC2)

UE combines TPCsaccording to the selected

algorithm

algo1 algo2

One TPC_cmd

powerCtrlAlgo (UlInnerLoopConf)

TPC2 RNCNode B 2

In the case of soft handover (where TPC commands come from different Node Bs), the UE has to combine different TPCs in order to derive one single internal TPC_cmd (internal power control command applied to adjust the UL transmission power).

There are 2 standardized algorithms (named: algorithm 1 and algorithm 2 in the 3GPP Specifications) for the UE to process TPC commands.

The choice between these two algorithms is under the control of the RNC 1000, and is managed through powerCtrlAlgo parameter (manufacturer parameter).

It is UE specific in the sense that a specific message is sent to each UE in order to indicate which algorithm to use, but Alcatel-Lucent sets the same value for all cells managed by an RNC.






5.4 UL Inner Loop Algorithm 1

Algorithm allows the UE to derive a single TPC_cmd per slot

1DL DPCCH TCP field 1 0 0

Algo1 output +1 +1 -1 -1

x ulTpcStepSize

1DL DPCCH TCP3 field 0 0 0

Algo1 output +1 +1 -1 -1

x ulTpcStepSize



UE Tx output power UE Tx output power

ulTpcStepSize (UlInnerLoopConf)

Algo 1: PC rate = 1500 Hz (T=666 µs)

•no soft HO: UE derives a TPC_cmdfrom the TPC command received for each slot

•soft HO: UE has to combine TPCsfrom different radio link sets and deduces a single TPC_cmd

•TPC_cmd = -1, +1

Soft HandOver

powerCtrlAlgo = algo1

This algorithm is well adapted for average speed UEs in urban or suburban environments. The principle of algorithm 1 is that the UE adjusts its DPCCH transmission power every slot (frequency = 1500 Hz), according to TPC_cmd (internal power control command applied to adjust the UE transmission power) derived from the TPC commands received from all Node Bs involved in the communication.

We can distinguish three cases of TPC_cmd generation:

No macrodiversity: the UE receives a single TPC command in each slot (on the single radio link established for the communication), from which it derives a TPC_cmd as follows:

if TPC command = 0, then TPC_cmd = -1

if TPC command = 1, then TPC_cmd = 1

Softer handover: in this case, the UE is aware (from TPC combination index parameter transmitted through RRC protocol) that it will receive identical TPC commands in the downlink. The UE is then able to combine these commands into a single TPC command, for example (UE implementation is proprietary) using maximum ratio combining with all TPC commands received in order to optimize the TPC command decoding.

Soft handover: in this case, the TPC commands may be different. This case may even involve a softer handover (from which a single TPC is derived, using for example MRC). The UE has first to use soft decision in order to decode the different TPC commands transmitted. Then it has to combine them in order to deduce a single TPC_cmd value.

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






5.5 UL Inner Loop Algorithm 2 (no SHO case)

1DL DPCCH TCP field 1 1 1

Algo2 output +1

UE Tx output power

1 0 0 0 0 0 1 1 0 0 0

-1 0

x ulTpcStepSize

5 radio slots

No Macrodiversity

Algo 2: PC rate = 300 Hz (T=3,333 ms)

•no soft HO: UE derives a TPC_cmdfrom the TPC command received on a 5 slot-cycle basis

•soft HO: UE has to combine TPCsfrom different radio link sets

•TPC_cmd = -1, 0, +1

Algorithm allows the UE to derive a single TPC_cmd

every 5 slots

powerCtrlAlgo = algo2

ulTpcStepSize (UlInnerLoopConf)

This algorithm is adapted to high or low speed environments (typically: dense urban or rural). With this algorithm, the UE concatenates N TPC commands received on consecutive radio slots to derive a TPC_cmd to be applied after the Nth slot. N can be different according to the handover situation, but it does always divide 15 (the combining window of the TPC commands does not extend outside the frame boundary). Allowing a decision every N = 5 radio slots instead of every slot, algorithm 2 is a way of emulating step sizes smaller than 1 dB (typically: 0.2 dB or 0.4 dB, corresponding to the step sizes of 1 and 2 dB respectively, but applied every 5 TS).

Note: In the TPC combination algorithm 2, the TPC_cmd is either 1, –1 or 0.

Algorithm 2 works in the following way:

No macrodiversity: the UE concatenates commands received from 5 consecutive TS to derive a TPC_cmd value:

For the first 4 slots of a set, TPC_cmd = 0

For the fifth slot of a set, the UE uses hard decisions on each of the 5 received TPC commands as follows:

· if all 5 hard decisions within a set are 1, then TPC_cmd = 1

· if all 5 hard decisions within a set are 0, then TPC_cmd = -1

· otherwise, TPC_cmd = 0

Softer handover: similarly to what happens for algorithm 1, for each slot, the UE soft-combines the TPC commands known to be the same (received from the same Node B).






5.6 UL Inner Loop Algorithm 2 (SHO case)

1DL DPCCH TCPN FIELD 1 1 1

Algo2 output

+1

UE Tx ouput power

1 0 0 0 0 0 0 0 0 0 0

-1 -1


+1

1 1 1 1 1 0 1 1 1 1 1

0 +1

1 1 1 0

0

1 0 0 0 0 0 1 0 1 0 1

-1 0

DL DPCCH TCP2 field

Sum of TPCN

> 0.5 < - 0.5 Otherwise

+ 1 - 1 0

x ulTpcStepSize

Soft handover: the derivation of the TPC_cmd from the TPC commands of the different radio links is done in the following way:

First, the UE determines 1 temporary TPC command called TPC_tempi for each of the N sets of 5 TPC commands. It is done as follow:

If all 5 hard decisions within a set = 1, TPC_tempi = 1.

If all 5 hard decisions within a set = 0, TPC_tempi = -1.

Otherwise, TPC_tempi = 0

Then the UE derives the combined TPC_cmd for the 5th slot as a function of all the N TPC_tempi:

TPC_cmd = 1 if (Sum of TPC_tempi)/N > 0.5

TPC_cmd = -1 if (Sum of TPC_tempi)/N < -0.5

Otherwise TPC_cmd = 0

Finally, after deriving a unique TPC_cmd, the UE implements a power change:

Uplink Power Change = TPC_cmd x ulTpcStepSize.





6 DL Traffic Channel Power





maxDlTxPowerPerOls (DlUsPowerConf)

6 DL Traffic Channels Power

6.1 Initial DL Traffic Channel Power

First Radio Link

SHO Leg Addition

minDlTxPower (DlUsPowerConf)

Pinitial= + - P-CPICH_Ec /NopcpichPower (FDDCell*) initialDlEcNoTarget(DlUsPowerConf)

Pinitial = + - P-CPICH_Ec /No EquivalentpcpichPower (FDDCell) initialDlEcNoTarget(DlUsPowerConf)

cell = N

P-CPICH_Ec /No Equivalent = P-CPICH_Ec /No (cell)

cell =1

Scell = N

P-CPICH_Ec /No Equivalent = P-CPICH_Ec /No (cell)

cell =1∑

isShoLegInitialPowerAlgoEnabled (RadioAccessService)

When a traffic (dedicated) channel is setup, it is done at a certain downlink power called Pini defined by the following equation:

Pini = pcpichPower + initialDlEcnoTarget – CPICH_Ec/No

Where pcpichPower is the downlink P-CPICH power, initialDlEcnoTarget depends on the service allocated to the UE (access stratum configuration) and CPICH_EC/N0 is the EC/N0 of the Pilot received by the UE.

The Pini is used in the Call Admission Control downlink power reservation algorithm.

The downlink transmission power is limited by an upper and lower limit for each radio link. This limitation is set through the maxDlTxPower and minDlTxPower parameters (DlUsPowerConf object). Both parameters provide actually a value for each access stratum configuration, so they correspond to a set of values rather than to a single value. The value (in dB) of these parameters is provided with respect to P-CPICH power defined by the pcpichPower parameter.

For SHO Leg Addition, the initial power is calculated once for all the new links to be added. Pinidepends not only on the CPICH Ec/No of the selected cell to be added, but on all the CPICH Ec/No of the cells of the old active set.

An equivalent CPICH Ec/N0 is calculated:

⎟⎟⎠

⎞⎜⎜⎝

⎛∗= ∑

=

N

i

celliNEcCPICH

equivdBNEcCPICH

1

10)(0/

100/_ log10)(





6 DL Traffic Channels Power

6.2 DL DPCCH / DPDCH Power Offsets

Data1Pilot TPC TFCI

PinitialPO3 PO1

PO2

po3ForPilotBits (DlUserService)

DL DPDCH Radio Frame

po2ForTpcBits (DlUserService)

po1ForTfciBits (DlUserService)

The RNC can also configure static downlink physical channel parameters in the Node B. In the downlink it is possible to give power offsets to the pilot, TPC and TFCI fields of the DPCCH relative to the DPDCH.

They are given at radio link setup in the Power Offset information IE:

PO1: TFCI bits

PO2: TPC bits

PO3: pilot bits

In the Alcatel-Lucent implementation, the power offsets used to determine the transmission power of the TFCI, TPC, and PILOT bits are defined by the po1ForTfciBits, po2ForTpcBits and 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 TFC in the TFCS.





7 DL Outer Loop Power Control





7 DL Outer Loop Power Control

7.1 DL Outer Loop Power Control

Initial Quality target

DL Outer Loop Control IE

Outer LoopPower Control

SRB

TRB

TPC

TX

RB Setup

BLERtarget increase not allowedor

BLERtarget increase allowed

inner looppower control

QualityMeasurements

RNC

isDlReferenceTransportChannelAllowed(DlRbSetConf)

blerTarget(DlBlerQualityList)

CSDTCH12_2K


DlRbSetConf

CSDTCH64K

SRBDCCH3_4KisDlReferenceTransportChannelAllowed

blerTarget



DlUserService


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.





8 DL Inner Loop Power Control






8.1 DL Inner Loop Algorithm

TPC_cmd x

Node BTPC = 0 / 1 UL DPCCH

PL TPCTFCI

TPC

TPC_ cmd

DL power change

New BTS output powerapplied to DPDCH

DL Power Change =

TPC =1=> TPC_ cmd = +1TPC =0 => TPC_ cmd = -1

ΔPTPC + ΔPBalancing

SPBAL

UE Algo

SHO

BLER est

dlTpcStepSize (DlInnerLoopConf)

BLER target

DL TX_PWR optimizationis UE constructor dependent

(not necessarilybased on SIR measurements)

The DL inner loop power control algorithm is a fast procedure (1500 Hz) used to optimize DL transmission power by sending power control commands to the Node B in the TPC field of UL DPCCH time slots.

At each TPC (Transmit Power Command = 0 or 1) field decoded (on UL DPCCH), the BTS estimates the TPC_cmd (TPC command = -1 or 1) based on TPC and Limited_Power_Increase values, and implements a DL power change as shown in the above slide.

As the Limited_Power_Increase functionality is not implemented, TPC_cmd values are directly deduced from TPC values as following:

TPC = 0 => TPC_cmd = -1

TPC = 1 => TPC_cmd = 1

So TPC_cmd never has the value 0 (either decrease or increase command for the transmission power), as with combination algorithm 2 for UL power control.

The downlink power adjustment (increment or decrement according to the power control command) step size is tuned through the dlTpcStepSize parameter. This parameter is transmitted by the RNC to the Node Bs using the TPC_DL_Step_Size IE contained in the RADIO LINK SETUP REQUEST message (NBAP). It cannot be reconfigured during the connection. 3GPP TS allowed values are: 0.5 dB, 1 dB (mandatory), 1.5 dB and 2 dB. Alcatel-Lucent implementation proposes only the two mandatory values: 0.5 dB and 1 dB.






8.2 Power Balancing

P1 P2

Power per Leg

RL Additiontime

P1

P2

isPowerBalancingAllowed (RadioAccessService)

powerBalancingRequired (DlUserService)

dlReferencePower(DlUserService)

maxAdjustmentStep (PowerBalancingAdjustmentParameters)

adjustmentPeriod (PowerBalancingAdjustmentParameters)

adjustmentRatio (PowerBalancingAdjustmentParameters)

Radio Frame

∑PBAL = (1 - R) x (PREF + PP-CPICH – PINIT)

PREF

ΔPBalancing

The objective of downlink power balancing function is to equalize powers on the different radio links, eliminating power drifting effects.

This function is triggered by the SRNC, which provides balancing parameters to the Node Bs and executed by the Node Bs.

The power balancing function brings a corrective factor Pbal which is added to the power as calculated by the DL inner loop power control.

This Pbal is such that

SPbal = (1 – R).(Pref + Ppcpich – Pini)

where:

SPbal is the sum of these corrective factors over an adjustment period corresponding to a number of frames

Pbal = 0 or -0.5 or 0.5 dB (in first implementation)

R is the adjustment ratio

Pref is the value of the DL Reference Power

Ppcpich is the power used on the primary CPICH

Pinit is the power of the last slot of the previous adjustment period

Instead of specifying which maximum correction should be applied to one slot, a period is specified, as a number of time slots, where the accumulated power adjustment should not be greater than 1 dB.

The above slide shows an example with SPbal = - 4 dB, adjustment period = 2 Radio Frames, max adjustment step = 5 Time Slots.






8.3 Rate Reduction Algorithm

UL DPCCH

dpcMode (DlInnerLoopConf)

1 0 1 0 0 1

1500 TPC commands / s

DPC_Mode = 0 (single Tpc)

500 TPC commands / s

1 1 1 0 0 0

DPC_Mode = 1 (tpcTripletInSoft)

RRC signaling (from RNC)

PL TPCTFCIPL TPCTFCI

The RNC may activate a rate reduction algorithm. If rate reduction algorithm is applied, then the UE issues one new command every 3 slots and repeats it over 3 slots, so the DL inner loop TPC commands frequency is divided by 3 (1500 Hz down to 500 Hz).

This algorithm is controlled by the dpcMode parameter (DlInnerLoopConf object), which is signaled to the UE in the Downlink DPCH Power Control Information IE using RRC signaling:

If dpcMode = singleTpc (0 on ASN1 interface), then the UE sends a specific TPC command in each DPCCH time slot (starts in the first available slot).

If dpcMode = tpcTripletInSoft (1 on ASN1 interface), then the UE repeats the same TPC commandover 3 successive DPCCH time slots.

On reception of TPC field in the UL DPCCH, the Node B processes the command depending on the DPC_MODE and calculates PTPC(k):

DPC_MODE = 0 => at each slot:

PTPC(k) = TPCDLStepSize if TPC = up

PTPC(k) = -TPCDLStepSize if TPC = down

DPC_MODE = 1 => each 3 slots:

PTPC(k) = TPCDLStepSize if 3 last TPCs are up

PTPC(k) = -TPCDLStepSize if 3 last TPCs are down





9 Radio Link Control






9.1 UL Dedicated Channel Synchronization

SIRAV < -3dB => OutSyncInd

SIRAV > -3dB => InSyncInd

nInSyncInd (FDDCell*)nOutSyncInd (FDDCell*) tRlFailure (FDDCell*)

RL RestoreRL Failure

Sync OK Sync KO

INIT

nInSyncInd (FDDCell*)



nOutSyncInd (FDDCell*)

tRlFailure (FDDCell*)

rlRestoreTimerShoRlRestoreTimer


N313 T313 T315

The uplink radio link sets are monitored by the Node B, to trigger radio link failure/restore procedures. Once the radio link sets have been established, they will be in the in-sync or out-of-sync states.

When the radio link set is in the in-sync state, after receiving nOutSynchInd consecutive out-of-sync indications, the Node B shall:

start timer tRlFailure;

upon receiving nInSynchInd successive "in sync" indications from Layer1:

Stop and reset timer tRlFailure;

if tRlFailure expires:

The Node B shall trigger the RL Failure procedure and indicates which radio link set is out-of-sync. When the RL Failure procedure is triggered, the state of the radio link set will change to the out-of-sync state.

The RNC receiving a Radio Link Failure Indication message from the NodeB will trigger the call release (call drop radio in this case) if no radio link remains in "in sync" state.

When the radio link set is in the out-of-sync state, after receiving nInSynchInd successive in-sync indications Node B shall trigger the RL Restore procedure and indicate which radio link set has re-established synchronization. When the RL Restore procedure is triggered, the state of the radio link set will change to the in-sync state.

Similar Radio Link Control is implemented in DL in the UE thanks to UeTimerCstConnectedMode object parameters:

N315 UE constant is analog to nInSynchInd

N313 UE constant is analog to nOutSynchInd

T313 UE timer is analog to tRlFailure

Activation Rules:

(nOutSyncInd * 10) + tRLFailure < (N313 * 10) + T313 + PA off

T315 > rrcReestPSMaxAllowedTimer






9.2 UL Radio Link Failure – detected by UTRAN

Node B RNC CN

Radio Link Failure Indication

Radio Link Deletion Resp

Iu Release Request“Radio cnx with UE lost”

Iu Release CommandRadio Link

Deletion Req

UE

UL synchronization failure on last RL

Iu Release Complete

bad SIR

nOutSyncInd

tRlFailure

expiry false

isPsRrcReestablishAllowedisCSRrcReestablishAllowed


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






9.3 DL Radio Link Failure – detected by UE

Node B RNC CN

Cell Update(radio link failure)


Iu Release Request“Radio cnx with UE lost”


Deletion Req

UE

DL synchronization failure on last RL

Iu Release Complete

bad SIR

N313

T313

expiry

false

T313N313

(UeTimerCstConnectedMode)

T314(UeTimerCstConnectedMode)

T314



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.






9.4 DL RLC Unrecoverable Error – detected by UTRAN

Node B RNC CN


Iu Release Request“DL RLC Error SRB/TRB”


Deletion Req

UE

Maximum number of RLC re-transmission reached

Iu Release Complete

maxDat

maxNbrOfResetRetrans

same RLC blocknot decoded

XX

timerPoll

RLC Resetnot decodedX

X

resetTimer

Maximum number of RLC Reset re-transmission reached

false

timerPollPeriodmaxDat

resetTimermaxNbrOfResetRetrans

(DlRlcAckMode)(UlRlcAckMode)








9.5 UL RLC Unrecoverable Error – detected by UE

Node B RNC CN

Iu Release Request“UL RLC Error SRB/TRB”

Iu Release CommandRadio Link Deletion

UE


Iu Release Complete

same RLC block not decoded

XX

RLC Resetnot decoded


false

Cell Update(rlc unrecoverable error)



XX






9.6 RRC Connection re-establishment Parameters

isPsRrcReestablishAllowed = True

isCSRrcReestablishAllowed = True

Yes No

RRC connectionRe-establishment

Call is dropped

RNC

(failure Cause, CPICH_Ec/No)

P-CPICH

CPICH Ec/No

rrcReestablishPSThresholdrrcReestablishCSThreshold


CPICH_Ec/No >= rrcReestablishPSThreshold

Cell Update

Cell Update

Last RL lost detection

rrcReestPSMaxAllowedTimerrrcReestCSMaxAllowedTimer


rrcReestablishPSThreshold (resp. rrcReestablishCSThreshold) is the CPICH_EcNo threshold above which an RRC Connection Re-establishment for a CS (resp. PS) call can take place at the reception of the Cell Update message coming from the UE.

rrcReestPSMaxAllowedTimer (resp. rrcReestCSMaxAllowedTimer) is the timer started by the RNC when it detects an UL Radio link Failure or a DL RLC Unrecoverable error on a CS (resp. PS) call. Afterwards, either the RNC stops this timer if it receives a Cell Update message from the UE or it triggers a call drop if this timer expires (no cell update received from UE).





Cell Update Confirm


9.7 UL Radio Link Failure – RRC Connection Re-established

Node B RNC CN

Radio Link Failure IndicationRadio Link Deletion

UE

UL synchronization failure on last RL

tRlFailure

expiry

true

Cell Update (radio link failure)

Radio Link Setupstopped

RB Reconfiguration Complete



rrcReestPSMaxAllowedTimerrrcReestCSMaxAllowedTimer


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.

uecallspare3 is the parameter used to activate or de-activate the RRC Connection Re-establishment feature. It is a parameter that was unused in UA5.0 that has been chosen.






9.8 UL RLC Unrecoverable Error – RRC Connectn Re-established

Node B RNC CNUE


same RLC block not decodedon PS TRB X

X

RLC Resetnot decoded

XX


Cell Update(rlc unrecoverable error

on PS TRB)

Cell Update Confirm

RB Reconfiguration Complete

Radio Link Deletion

Radio Link Setup

true



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.






9.9 RRC Connection re-establishment - Summary

In case of Radio Link Failure

In case of RLC Unrecoverable Error

Call Type

DCCH (SRB) DTCH(TRB) DCCH (SRB) DTCH(TRB)

PS Only (DCH) Re-establish Re-establish Drop Call Re-establish

CS Only Drop Call N/A Drop Call N/A

PS + CS (DCH) Drop Call Drop PS Drop Call Re-establish

PS Only (FACH) Re-establish Re-establish Drop Call Re-establish

RNC RLC UE RLC

Call Type

PS Only (DCH)

CS Only

PS + CS (DCH)

PS Only (FACH)

RNC RLF UE RLF

Re-establish Re-establish








Module Summary

This lesson covered the following topics: Power management static configuration

PRACH Power Control and associated parameters

UL Power Control and associated parameters

DL Power Control and associated parameters

Radio Link Control and associated parameters

















Section 9Mobility Connected Mode


TMO18044 D0 SG DENI1.0 Edition 3




9300 W-CDMA · UA06 R99 Algorithms DescriptionMobility Connected Mode9 · 2

Blank Page



2009-02-2901


Document History





Module Objectives


Describe Handover types and purpose

Describe Soft Handovers and associated parameters

Describe Intra-Freq Hard Handovers and associated parameters

Describe Inter-Freq and Inter-RAT Hard Handovers (iMCTA algorithm) and associated parameters

Describe Compress Mode algorithm and parameters











Table of Contents


1 Mobility Requirements 71.1 Soft Handover Types 81.2 Hard Handover Types 91.3 Periodic vs. Full Event Triggered Reporting 101.4 Periodical Reports Processing 111.5 Intra-Freq CNL Management 121.6 CNL: typeOfCompoundingNeighbourListIntraFreq 13

2 Active Set Management (Soft HO) 172.1 Absolute and Relative Criteria for SHO 182.2 Drop Criteria (Periodical Mode) 192.3 Add Criteria (Periodical Mode) 202.4 Event 1A 212.5 Event 1B 222.6 Event 1C 232.7 Event 1E 242.8 Event 1F 25

3 Primary Cell Change 263.1 Primary Cell Election: Periodical Mode 273.2 Primary Cell Change: Event 1D 283.3 Service Based Intra-Freq Mobility : RAN Model 29

4 Intra-Freq Hard HO 304.1 Intra-Freq Inter-RNC Mobility w/o Iur : HHO Activation 314.2 RRC Measurement Control Configuration 324.3 HHO Detection after MeasId1: Iur link is down 334.4 HHO Detection after MeasId16: Iur link is not provisioned 344.5 RAN Model 35

5 SRNS Relocation (UE not Involved) 365.1 Principle 375.2 Example: Call Flow PS 385.3 Parameters 39

6 Intelligent Multi-Carrier Traffic Allocation 406.1 Principle 416.2 iMCTA Triggers 426.3 Generic iMCTA Algorithm 436.4 iMCTA Triggering 446.5 iMCTA Alarm Triggering: Periodical Mode 456.6 iMCTA Alarm Triggering: Full Event Trigger 466.7 iMCTA Validity Checking: Primary Cell Is Under S-RNC 476.8 iMCTA Validity Checking: Primary Cell Is Under D-RNS 486.9 iMCTA Validity Checking: Specific to User Service Trigger 496.10 iMCTA Validity Checking: Specific to Mobility Service Trigger 506.11 iMCTA Validity Checking: Specific to All Service Triggers 516.12 iMCTA Configuration Retrieval: Alarm Priority Table 526.13 iMCTA Configuration Retrieval: CAC Priority Table 536.14 iMCTA Configuration Retrieval: Service Priority Tables 546.15 iMCTA Configuration Retrieval: Service HO Options 556.16 iMCTA: Inter-Freq & Inter-RAT CNL Computation (Type1) 576.17 Type 1 CNL Computation: Inter-FREQ Example 586.18 Type 1 CNL Computation: Inter-RAT Example 596.19 Neighboring Cells Searching and Filtering: Generic 606.20 Neighboring Cells Searching and Filtering: Specific 616.21 RAT Selection 626.22 Measurement Configuration 63

6.22.1 CM Scope & Methods 646.22.2 Need for Compressed Mode 65







6.22.3 High-Level Scheduling Method 666.22.4 HLS Activation 676.22.5 CM Pattern Sequences 686.22.6 Pattern Sequence Configuration 696.22.7 FDD Inter-Freq CM Pattern 706.22.8 GSM Inter-RAT CM Pattern 71

6.23 Measurement Report Processing (MRP) 726.23.1 iMCTA Alarm/CAC – Inter-Freq Case 73

6.23.1.1 Inter-Freq Case – FDD Eligible Cells 746.23.1.2 Inter-Freq Case - Filtering on HSxPA Capabilities 75

6.23.2 iMCTA Alarm or CAC – Inter-RAT Case 766.23.2.1 Inter-RAT Case - GSM Eligible Cells 776.23.2.2 Inter-RAT Case – 2G Cell Load Management 786.23.2.3 Inter-RAT Case – Handover Call Flow 80

6.23.3 iMCTA Service – Inter-Freq Case 816.23.3.1 Inter-Freq Case – Filtering on HSxPA Capabilities 826.23.3.2 Inter-Freq Case – Filtering on Load Criteria 83

6.23.4 iMCTA Service – Inter-RAT Case 846.24 HHO Decision 85

6.24.1 CM Deactivation / Reactivation 866.25 Inter-FREQ & Inter-RAT CNL - UA6 RAN Model 876.26 Service Based Inter-Freq/Inter-RAT Mobility - RAN Model 88

7 Inter-FDD/Inter-RAT HHO 937.1 3G-2G HHO 947.2 3G-2G CS Handover Success - Counters 957.3 3G->3G Intra-RNC Inter-freq HHO 967.4 3G->3G Inter-RNC Inter-freq HHO 977.5 3G-3G CS/PS HHO – InterRNC 98





1 Mobility Requirements






1.1 Soft Handover Types

FDDcell FDDcell FDDcell

Inter-RNC SHO

Core Network

Node B Node B

RNC RNC

FDDcell FDDcell FDDcell

Node B

Intra-RNC SHOIntra-NodeB SHO

(Softer)

Soft Handover (SHO) applies only to dedicated physical channels and refers to the case where more than one cell has a link established with a UE. In this mode the UE is connected to a set of cells known as the Active Set, where it benefits from macro diversity.

Softer Handover is a special case of SHO where the cells communicating with the UE belong to the same Node B, thus it can only be performed intra-RNC. The particularity of the softer handover comes from the fact that the radio links coming from different cells of the Node B are combined together at the Node B level before being sent back to the RNC.

In the Intra-RNC SHO case, the cells involved in the soft handover procedure belong to different Node Bs that are connected to the same Serving RNC (that is, the RNC in charge of the RRC connection with the mobile). Radio Link recombination is performed at the S-RNC level.

In the Inter-RNC SHO case, the cells of the active set are not all controlled by the S-RNC. This is where the notion of Drift and Serving RNC comes into play:

S-RNC is in charge of the RRC connection with the mobile.

D-RNC controls the Node B that does not belong to the S-RNC and for which a radio link needs to be established with the mobile.

An Iur link between S-RNC and D-RNC is required to perform inter-RNC SHO.

From S-RNC and UTRAN transport perspective D-RNC acts as a router.

From UE and Core Network perspectives, the presence of D-RNC is transparent, that is, soft handover occurs as usual.






1.2 Hard Handover Types

FDDcell

3G to 2G HHO

Core Network

Node B Node B

RNC RNC

FDDcell

Node B

Intra-RNC HHOFDDcell FDDcellFDDcell

FDDcell

GSMcell

2G to 3G HHO

Inter-RNC HHO

Hard Handover gathers a set of handover procedures where all the old radio links are abandoned before the new radio links are established (break before make).

Hard handovers are needed as soon as the UE needs to leave its serving UMTS carrier. It could be:

When the Iur interface is not present and the UE is moving from one RNC to another.

When moving to another UMTS carrier (inter / intra-RNC or inter / intra-PLMN): this case is defined as the inter-frequency HHO.

When moving to another technology (GSM, GPRS): this case is defined as the inter-RAT HHO.






1.3 Periodic vs. Full Event Triggered Reporting


RRC Measurement Control(Intra-frequency, Periodical Reporting)RNC

FALSE

RNC

RRC Measurement Control(Ec/No, 1A, 1B, 1C, 1D, 1E, 1F)

RRC Measurement Control(Ec/No, 2D, 2F)

RRC Measurement Control(RSCP, 2D, 2F)

TRUE

Starting UA4.2, the mobility of a given UE is managed either in Periodical Mode or Full Event Triggered Mode.

The choice between these two modes is done by RNC when the UE establishes a communication in CELL_DCH state and is kept unchanged as long as the UE remains in CELL_DCH state. There is no switch between Periodical Mode and Full Event Mode in CELL_DCH state, even when the Primary Radio Link is changed.

In the event-triggered reporting mode, the type of the triggered event becomes the main indication to compute the Mobility decisions. The semantic of the received event indicates which decision has to be taken. In this mode, the RNC provides to the UE, in the RRC Measurement Control, the means to compute the criteria to manage the Mobility. The RNC has to perform the related action indicated by the received event.

The parameter isEventTriggeredMeasAllowed controls the activation of the Full Event Triggered feature on a per cell basis. The reporting mode for the call is the one configured on the cell where the call is established, and is not changed during the call duration (on CELL_DCH).






1.4 Periodical Reports Processing

Active Set cells+

6 Best Monitored Set cells+

3 Best Detected Cells

RRC Measurement Report

RRC Measurement ReportRNC

- 1 - Alarm Hard Handover criteria evaluation (Primary Cell)• Inter-Frequency Hard Handover (3G to 3G)• Inter-System Hard Handover (3g to 2G)

- 2 - Active Set update

- 3 - Primary Cell election

The above slide indicates in which order the various procedures are performed in the RNC when receiving a RRC Measurement Report message from the mobile.

In this release, Alarm Hard Handover refers to the following mobility cases:

3G to 2G handover for CS

3G to 2G handover for PS

3G to 2G handover for CS+PS

3G to 3G inter-frequency inter-RNC handover

3G to 3G inter-frequency intra-RNC handover






1.5 Intra-Freq CNL Management

A1NA2

NA1

A3NA2

A2NA1NA3

NA1NA2

NA1

NA2NA3

NA1NA3

NA3

NA2NA3

NA2

NA3

Primary Cell Monitored SetMonitored Set

Prl Type1 or Type2

isCompoundingCellListActivated (RadioAccessService)

typeOfCompoundingNeighbourListIntraFreq

(FDDCell and NeighbouringRNC)

Two different CNL alogrithms are now supported in UA06.0 that can be enabled/disabled using typeOfCompoundingNeighbourListIntraFreq parameter

newly introduced and defined under NeighbouringRnc and FDDCell objects:

Prl stands for primary radio link and aims at disabling CNL at FDD cell level; the neighbouring list only consists in the primary cell’s neighbourhood.

Type2 is the initial CNL algorithm introduced in UA4.1; the neighbouring list classicaly consists inconcatenating Primary cell’s neighbourhood then the

best second leg’s … until maxCompoundingListSizeIntraFreq is reached.

Type1 is the newly introduced algorithm which aims at building intrafrequency neighbouring list basedon priorities and occurrence.






1.6 CNL: typeOfCompoundingNeighbourListIntraFreq

Entire Active Set Cells+

Primary Cell static neighboring for DCH mode+

AS first best leg static neighboring for DCH mode+

AS second best leg static neighboring for DCH mode+...

SHO Neighboring List

Primary Cell static neighboring for DCH mode+

first best monitored cell and its static neighboring for DCH mode+

second best monitored cell and its static neighboring for DCH mode+...

non-SHO Neighboring List

Primary Cell ChangeOR

Active Set Modification OR

SHO to non-SHO TransitionOR

Dedicated Connection Initiation

Type2

Basing the monitored set on the compound neighbor list rather than on the primary cell neighbors increases the number of cells in the monitored set, thus it is important to have way to limit the size of the neighbor list, and ensure that the monitored set comprises the best cells.

To achieve this, the algorithm consists in scanning the cells from the active set in decreasing order of CPICHEc/N0 and adding their neighbors to the monitored set, until the number of cells in the list reaches the maximum size allowed.

A cell is not added in the compounding list if it is already included in this list, so as not to have several instance of the same cell in the list.

If maxNbOfMonitoredCellForNonShoCompoundList is set to zero, the compound list is only composed of the primary cell and its neighborhood.






1.6 CNL: typeOfCompoundingNeighbourListIntraFreq [cont.]

“Sponsoring” Cells = ASETneighbourCellPrio = [0...62]

(UMTSFddNeighbouringCell)

Priority Level

For each sponsoring cell, build a neighbouring list orderedby neighbourCellPrioBuild the final intra-frequency neighbouring list as follows:

1. Add the sponsoring cells2. Select the numOfPrimaryCellNeighbourIntraFreq first

cells from Primary Cell's neighbouring list• Defined under RadioAccessService

3. Then perform the selection by number of occurrence• In case of conflict, select:

• the one whose sponsoring cell has the highest Ec/No

• then the one with highest neighbourCellPrio4. Until maxCompoundingListSizeIntraFreq is reached

Intra-Freq Neighboring List compounding Algorithm

Primary Cell ChangeOR

Active Set Modification OR

SHO to non-SHO TransitionOR

Dedicated Connection Initiation

A1NA2

NA1

A3NA2

A2NA1NA3

NA1NA2

NA1

NA2NA3

NA1NA3

NA3

NA2NA3

NA2

NA3

Type1

Type1 is the newly algorithm introduced in UA06.0 and is mainly based on:• neighbourCellPrio, between 0 and 62, defining for each FDD Cell a hierarchy within its neighbourhood (0 is the highest priority, 62 the lowest); note that two UMTSFddNeighbouringCell can NOT have the same neighbourCellPrio.• “sponsoring cells” which are the cells from the ASET• occurrence of each neighbouring cell within the sponsoring cells’ neighbourhood.For each sponsoring cell, RNC builds a neighbouring cell list ordered by neighbourCellPrio. Then it builds thefinal intra-frequency neighbouring list by:• adding the sponsoring cells• selecting the numOfPrimaryCellNeighbourIntraFreq first neighbouring cells from Primary Cell's neighbouring list• and then performing the selection by number of occurrenceIn case of conflict, RNC selects:• the neighbouring cell whose sponsoring cell has the highest CPICH Ec/No, then the one with the highest neighbourCellPrio until maxCompoundingListSizeIntraFreq is reached.

Iur caseIn case a cell from the active set belongs to a Drift RNC, the Serving RNC may learn its intra-frequency neighbourhood using the information present in RNSAPRadioLinkSetup/AdditionResponse message.When type1 is selected, RNC automatically assigns neighbourCellPrio by order of presence in the RNSAPmessage (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 20data filled neighbours, then only 16 neighbours will be sent to the UE.






1.6 CNL: typeOfCompoundingNeighbourListIntraFreq [cont.]

RNC

RadioAccessServiceNeighbouringRnc

NodeB

FDDCell

isCompoundingCellListActivated {True, False}

maxCompoundingListSizeIntraFreq [16..32]

typeOfCompoundingNeighbourListIntraFreq {prl, type1, type2}

numOfPrimaryCellNeighbourIntraFreq [0..32]


neighbourCellPrio [0..62]

typeOfCompoundingNeighbourListIntraFreq {prl, type1, type2}

numOfPrimaryCellNeighbourIntraFreq [0..32]






Exercise

Cell27

Cell24

Cell25

Cell26

Cell23

Cell22

Cell21

Cell53

Cell52

Cell4

Cell3

Cell51

Cell1

Cell2

Cell13

Cell14

Cell11

Cell12

Cell17

Cell18

Cell19

Cell51

Cell16

Cell15

Cell4

Cell3

Cell2

Cell1

maxCompoundingListSizeIntraFreq = 26

Cell34

Cell33

Cell32

Cell31

Cell53

Cell52

Cell55

Cell54

Cell39

Cell38

Cell37

Cell36

Cell35

Cell4

Cell2

Cell1

Cell54

Cell55

Cell41

Cell42

Cell43

Cell44

Cell49

Cell48

Cell47

Cell46

Cell45

Cell3

Cell2

Cell1

Cell11

Cell12

Cell1

Cell31

Cell32

Cell33

Cell21

Cell22

Cell23

Cell52

Cell53

Cell24

Cell25

Cell26

Cell27

Cell51

Cell19

Cell18

Cell17

Cell16

Cell15

Cell14

Cell13

Cell4

Cell3

Cell2

Cell3 Cell4

Type2

Primary Cell'sneighbourhood

Cell2'sneighbourhood

Sponsoring cells 1 to 4 are ordered by EcNoCell1 > Cell2 > Cell3 > Cell4

Cell1 is assumed to be the Primary Cell

Type1

Cells from ASET

Cell3'sneighbourhood

Build the list of cells for Intra-FreqMeasurements

in Cell_DCH

numOfPrimaryCellNeighbourIntraFreq = 4

type1 is the newly algorithm introduced in UA06.0 and is mainly based on:

neighbourCellPrio, between 0 and 62, defining for each FDD Cell a hierarchy within its neighbourhood(0 is the highest priority, 62 the lowest); note that two UMTSFddNeighbouringCell can NOT have the same neighbourCellPrio.

“sponsoring cells” which are the cells from the ASET

occurrence of each neighbouring cell within the sponsoring cells’ neighbourhood.

For each sponsoring cell, RNC builds a neighbouring cell list ordered by neighbourCellPrio. Then it builds the final intra-frequency neighbouring list by:

adding the sponsoring cells

selecting the numOfPrimaryCellNeighbourIntraFreq first neighbouring cells from Primary Cell's neighbouring list

and then performing the selection by number of occurrence

In case of conflict, RNC selects:

the neighbouring cell whose sponsoring cell has the highest CPICH Ec/No, then the one with the highest neighbourCellPrio until maxCompoundingListSizeIntraFreq is reached.





2 Active Set Management (Soft HO)





2 Active Set Management

2.1 Absolute and Relative Criteria for SHO

Drop Delta

Add Delta

DropRelativeCriterion

AddRelativeCriterion

Best Cell

AddAbsoluteThreshold

Add Absolute Criterion

DropAbsoluteThresholdDrop Absolute Criterion

P-CPICH Ec/No

No Action

The active set update algorithm applies to all soft handover cases. Its purpose is to ensure that the strongest cells in the UE environment will be part of its active set.

The algorithm is based on relative comparison between the best cell and each cell CPICH EC/N0 of the reported set.

Since UA04.1, the Active Set Update algorithm offers the possibility of using absolute thresholds for link addition and link deletion criteria, providing additional tools to reducing call drop rates and improve the capacity of the network from the perspective of radio power, code and RNC and Node B processing cost.

Note that absolute thresholds are optional and can be deactivated through parameters. Once activated, the criteria for RL Addition/RL Deletion would be a logical OR between the relative and absolute criteria.

Cell Individual Offsets have also been supported since UA04.1. CIO is added to the measurements received from the mobile before SHO conditions are evaluated, that is, Ec/No(i) + CellIndividualOffset(i) is compared to the add or drop threshold (relative or absolute).

Note: Cell individual offset is taken into account by the RNC only if at least one of the flag enabling absolute thresholds (add or drop) is set to true.






2.2 Drop Criteria (Periodical Mode)

IFEc/No(i) + Cell Individual Offset(i) ≤ Ec/No(best) – Drop DeltaANDEc/No(i) + Cell Individual Offset(i) < Add Absolute Threshold (if Add Absolute Criterion enabled)

OREc/No(i) + Cell Individual Offset(i) ≤ Drop Absolute Threshold (if Drop Absolute Criterion enabled)

THENDrop Cell(i) from Active Set

ELSEKeep Cell(i) in Active Set

Keep Cell in Active Set

Drop Cell from Active Set

neighbouringCellOffset (UMTSNeighbouringRelation)

legDroppingDelta (SoftHoConf)

shoLinkAdditionAbsoluteThresholdEnable (SoftHoConf)

shoLinkAdditionCpichEcNoThreshold (ShoLinkAdditionParams)

shoLinkDeletionAbsoluteThresholdEnable (SoftHoConf)

shoLinkDeletionCpichEcNoThreshold (ShoLinkDeletionParams)

Drop Delta Add Absolute Threshold

Drop Absolute Threshold

RNC first identifies which is the best cell, that is, the cell with the highest CPICH EC/N0 of the reported set (active set + monitored set).

Then for the cells belonging to the active set, RNC applies the drop criteria:

Cells not matching drop criteria are kept in the active set until the maximum number of cells in the active set is reached.

Cells matching one of drop conditions are removed from the active set.

The drop criteria depend on the activation of the absolute add or drop thresholds.

If none of the cells of the current active set are eligible, the RNC keeps at least the best cell even if it does not meet the criteria to be eligible.

The RNC identifies then the remaining cells (non-eligible cells) as cells to be removed from the active set. This information will be transmitted in the active set update message.

When both relative and absolute criteria are used for the SHO Algorithm, it may happen that the relative and absolute criteria trigger contradictory decisions for the same cell.

In order to avoid such a situation, it is necessary to add a supplementary check in order not to delete a radio link which satisfies the link relative deletion threshold but is above the link absolute addition threshold.






2.3 Add Criteria (Periodical Mode)

IFEc/No(i) + Cell Individual Offset(i) ≥ Ec/No(best) - Add DeltaANDEc/No(i) + Cell Individual Offset(i) > Drop Absolute Threshold (if Drop Absolute Criterion enabled)

OREc/No(i) + Cell Individual Offset(i) ≥ Add Absolute Threshold (if Add Absolute Criterion enabled)

THENAdd Cell(i) in Active Set

ELSEKeep Cell(i) in Monitored Set

neighbouringCellOffset (UMTSFddNeighbouringCell)

legAdditionDelta (SoftHoConf)

shoLinkAdditionAbsoluteThresholdEnable (SoftHoConf)

shoLinkAdditionCpichEcNoThreshold (ShoLinkAdditionParams)

shoLinkDeletionAbsoluteThresholdEnable (SoftHoConf)

shoLinkDeletionCpichEcNoThreshold (ShoLinkDeletionParams)

maxActiveSetSize (UsHoConf)

Add Cell in Active Set

Add Delta

Add Absolute ThresholdKeep Cell in Monitored Set

Drop Absolute Threshold

The RNC first identifies which is the best cell, that is, the cell with the highest CPICH EC/N0 of the reported set (active set + monitored set).

Then for the cells belonging to the monitored set, RNC applies the add criteria:

Cells matching one of add delta & add absolute criteria are added in the active set until the maximum Active Set size is reached.

Cells not matching any add criteria are ignored.

The addition criteria depend on the activation of the absolute add or drop thresholds.

When both relative and absolute criteria are used for the SHO Algorithm, it may happen that the relative and absolute criteria trigger contradictory decisions for the same cell.

In order to avoid such a situation, it is necessary to add a supplementary check in order not to add a radio link which satisfies the link relative addition threshold but is below the link absolute deletion threshold.






2.4 Event 1A

Best Cell

New Cell

CPICH_EC/No



Even

t1A

Even

t1A

Even

t1A

timeToTrigger1A(FullEventHOConfShoMgtEvent1A)

repInterval1A(FullEventRepCritShoMgtEvent1A)

amountRep1A(FullEventRepCritShoMgtEvent1A)

)2/(10)1(1010 111

aaBest

N

iiNewNew HRLogMWMLogWCIOLogM

A

m−⋅⋅−+⎟⎟⎠

⎞⎜⎜⎝

⎛⋅⋅≥+⋅ ∑

=

maxNbReportedCells1A(FullEventRepCritShoMgtEvent1A)

wParam (static)cpichEcNoReportingRange1A

hysteresis1A(FullEventHOConfShoMgtEvent1A)



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

Event 1A is used to add a RL based on relative criteria when the Active Set is not full.


MNew is the measurement result of the cell entering the reporting range.






R1a is the reporting range constant.

H1a is the hysteresis parameter for event 1a.

In order to help the operator to monitor efficiently its network, and optimize its neighboring plan, it is possible to trigger this event 1A based on both Detected Set and Monitored Set. However the cells from Detected Set will not be used in the mobility algorithms.







2.5 Event 1B

Best Cell

Old Cell

CPICH_EC/No



Even

t1B

Even

t1B

timeToTrigger1B(FullEventHOConfShoMgtEvent1B)

repInterval1B(FullEventRepCritShoMgtEvent1B)

amountRep1B(FullEventRepCritShoMgtEvent1B)

cpichEcNoReportingRange1Bhysteresis1B

(FullEventHOConfShoMgtEvent1B)

Even

t1B

Even

t1B

maxNbReportedCells1B(FullEventRepCritShoMgtEvent1B)

)2/(10)1(1010 111

bbBest

N

iiOldOld HRLogMWMLogWCIOLogM

A

±−⋅⋅−+⎟⎟⎠

⎞⎜⎜⎝

⎛⋅⋅≤+⋅ ∑

=

wParam (static)


Event 1B is triggered when an active P-CPICH leaves the reporting range.

Event 1B is used to delete a RL based on relative criteria.


MOld is the measurement result of the cell leaving the reporting range.






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.






2.6 Event 1C

AS Cell

InAS Cell

CPICH_EC/No



Even

t1C

Even

t1C

timeToTrigger1C(FullEventHOConfShoMgtEvent1C)

repInterval1C(FullEventRepCritShoMgtEvent1C)

amountRep1C(FullEventRepCritShoMgtEvent1C)

hysteresis1C (FullEventHOConfShoMgtEvent1C)

Even

t1C

Even

t1C

maxNbReportedCells1C(FullEventRepCritShoMgtEvent1C)

New Cell

)2/ 1010 1cInASInASNewNew HCIOLogMCIOLogM ±+≥+



Event 1C is triggered when a new P-CPICH becomes better than an active P-CPICH.

Event 1C is used to replace a RL based on relative criteria when the Active Set is full.


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 theCIOs are set to 0 dB.






2.7 Event 1E

AS Cell

New Cell

CPICH_EC/No



Even

t1E

timeToTrigger1E (FullEventHOConfShoMgtEvent1E)

absolute threshold

maxNbReportedCells1E(FullEventRepCritShoMgtEvent1E)

2/10 11 eeNewNew HTCIOLogM ±≥+


cpichEcNoReportingRange1Ehysteresis1E

(FullEventHOConfShoMgtEvent1E)


Event 1E is triggered when a new P-CPICH becomes better than an absolute threshold.

Event 1E is used to add a RL based on absolute criteria when the Active Set is not full.


MNew is the measurement result of a cell that becomes better than an absolute threshold.

CIONew is the individual cell offset for the cell becoming better than the absolute threshold. Otherwise it is equal to 0.

T1e is an absolute threshold.

H1e is the hysteresis parameter for the event 1e.

In order to help the operator to monitor efficiently its network, and optimize its neighboring plan, it is possible to trigger this event 1E based on both Detected Set and Monitored Set. However the cells from Detected Set will not be used in the mobility algorithms.


hsiddhar

Sticky Note

cpichEcNoThresholUsedFreq1E Change as given wrong in doc






2.8 Event 1F

AS Cell

Old Cell

CPICH_EC/No



Even

t1F

timeToTrigger1F (FullEventHOConfShoMgtEvent1F)

absolute threshold

maxNbReportedCells1F(FullEventRepCritShoMgtEvent1F)

2/10 11 ffOldOld HTCIOLogM ±≤+


cpichEcNoReportingRange1Fhysteresis1F

(FullEventHOConfShoMgtEvent1F)

Event 1F is triggered when an active P-CPICH becomes worse than an absolute threshold.

Event 1F is used to delete a RL based on absolute criteria.


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.

hsiddhar

Sticky Note

cpichEcNoThresholUsedFreq1F Change as given wrong in doc





3 Primary Cell Change






3.1 Primary Cell Election: Periodical Mode

IFCell(i) was in previous Active SetANDCell(i) is in new Active SetANDEc/No(i) – Drop Primary Delta ≥ Ec/No(Primary Cell)

THENCell(i) is candidate for Primary Cell Election


IFEc/No(i) is the highest of all candidate cells

THENCell(i) is the new Primary Cell


primaryRlDelta (SoftHoConf)

Candidate Cells Selection

Primary Cell Election

New Active Set

Cell 1Cell 2Cell 3Cell 4

Candidate Cells

Cell 1

Cell 3

Candidate Cells

Cell 1

Cell 3

Cell 3

Primary

Cell

The primary cell selection algorithm applies to all soft handover cases. The primary cell is used for monitored set determination, but also as a pointer to mobility parameters. The primary cell selection algorithm is performed each time a MEASUREMENT REPORT is received by the S-RNC.

To be selected as candidate cell, the following conditions must be true:

Cell was present in the previous active set.

Cell is eligible to be in the new active set (Reference: soft handover algorithm).

Cell has the strongest CPICH_Ec/N0 of the MEASUREMENT_REPORT.

The previous primary cell is compared with the candidate cell for primary minus a threshold definedPrimaryRlDelta. 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.






3.2 Primary Cell Change: Event 1D

Best Cell

CPICH_EC/No



Even

t1D

timeToTrigger1D(FullEventHOConfShoMgtEvent1D)

hysteresis1D (FullEventHOConfShoMgtEvent1D)


maxNbReportedCells1DuseCIOfor1D

(FullEventRepCritShoMgtEvent1D)

NotBest Cell

)2/1010 1dBestBestNotBestNotBest HCIOLogMCIOLogM ±+⋅≥+⋅

The primary cell determination is based on event 1D reception. Based on the reception of this event, the RNC stores the new primary, and applies the current process used in case of change of primary cell.

Since events 1A and 1C are also configured it is assumed that the new primary cell is already in the Active Set when a 1D event is triggered. Typically, this will be ensured if the time to trigger 1D is greater or equal than the time to trigger events 1A or 1C. It should be noted that a monitored set cell that needs to be included in the active set will trigger first a 1A event if its CPICH Ec/No is lower than the best cell in the Active set but entering in its reporting range, or a 1C event if the Active Set is full and this cell is better than the worst in the Active Set.

A 1D event will typically be triggered by a cell better than the best in the active set. Therefore due to the triggering conditions defined for these events, if the time to trigger a 1D event is greater than or equal to that for a 1A and 1C event, the 1D will typically be triggered by a cell in the active set.

If the event 1D is triggered by a monitored cell, the RL will be added in the Active Set if not full.

If the Active Set is full and the 1D event is triggered by a monitored set cell, then the new best cell will be added in the active set, replacing the worst active set cell.

A new primary cell will be defined if the current primary cell is removed due to reception of RL deletion events.






3.3 Service Based Intra-Freq Mobility : RAN Model

RadioAccessService

DedicatedConf

HoConfClass [0..30]

UsHoConf [0..21]

SoftHoConf

FullEventHoConfShoMgt

FullEventHoConfShoMgtEvent1…

Event1AHoConfInSIB11

FDDCell

MeasConfClass [0..14]

cpichEcNoReportingRange1AtimeToTrigger1A

hysteresis1AmaxActiveSetSize

legDroppingDelta legAdditionDeltaprimaryRlDelta

DlUserService

NeighbouringRNC

isEvent1EUsedisEvent1FUsed

hysteresis1Chysteresis1Dhysteresis1Ahysteresis1Bhysteresis1Ehysteresis1F

maxActiveSetSize

timeToTrigger1AtimeToTrigger1BtimeToTrigger1CtimeToTrigger1DtimeToTrigger1EtimeToTrigger1F

cpichEcNoReportingRange1AcpichEcNoReportingRange1BcpichEcNoReportingRange1EcpichEcNoReportingRange1F

ShoLinkAdditionParams shoLinkAdditionCpichEcNoThreshold

ShoLinkDeletionParams shoLinkDeletionCpichEcNoThreshold

mobilityServiceType





4 Intra-Freq Hard HO






4.1 Intra-Freq Inter-RNC Mobility w/o Iur : HHO Activation

Measurement Report

MeasurementID


MeasurementResults

Measurement Id 1:

Cell A, B & C are candidates to SHO (specified in the new IE)

1A, 1B, 1C, 1D, 1E and 1F (dedicated to SHO)

Cell A, B & C could be candidates to HHO in case IUR link is down Measurement Id 16:

Cell D is candidate to HHO (specified in the new IE)

Event 1A is the only event provisioned as SHO can NOT be performed without IUR

SRNC

RNC1

RNC2

Cell AF1

Cell BF1

Cell CF1

Cell DF1

isIntraFreqInterRncHHOAllowedisIntraFreqInterRncHhoOnIurLinkDownAllowed isEventTriggeredMeasAllowed

Measurement Control (new IE: Cells for measurements )

Intra-frequency Inter-RNC mobility without IUR may occur in the following situations:

Two different operators (PLMN) using the same frequency in the same area

National roaming agreements are needed

In a single PLMN, no IUR provisioned between 2 RNC

E.g. due to IOT reasons between 2 different RNC manufacturers

In a single PLMN, IUR interface is provisioned but is not in an enabled state

Need to handle Intra-frequency Inter-RNC HHO

FRS 21302 was initially implemented in UA4.3K timeframe

FRS 33422 was duplicated for UA5.0

Code was implemented but commercially not supported

Not applicable to HSxPA calls

FRS 33814 has been created for UA6.0

Feature is fully supported

Also applicable to HSxPA calls






4.2 RRC Measurement Control Configuration

No influence of isIntraFreqInterRncHHOIurLinkDownAllowedThis flag is only used at RRC Measurement Report (MR) processing (cf. next slide)

E1A triggering conditions depend on MeasIdDetected set and monitored set for MeasId1Only Monitored Set for MeasId16

Specific E1A parameters for MeasId16

Measurement Identity = MeasId16,New intra-frequency cells is empty as already present in MeasId1Cells for measurements = {HHO candidate list}

Measurement Identity = MeasId1, New intra-frequency cells= {SHO candidate list + HHO candidate list}Cells for measurements = {SHO candidate list}

isIntraFreqInterRncHHOAllowed= TRUE

Not sent by RNCMeasurement Identity = MeasId1, New intra-frequency cells = {SHO candidate list}

isIntraFreqInterRncHHOAllowed= FALSE

RRC Measurement Controlfor MeasId2

RRC Measurement Controlfor MeasId1






4.3 HHO Detection after MeasId1: Iur link is down

RNC

RadioAccessService

UmtsNeighbouring

isIntraFreqInterRncHHOAllowed = TRUEisIntraFreqInterRncHhoOnIurLinkDownAllowed = TRUE

isHsdpaHhoWithMeasAllowedisEdchHhoWithMeasAllowed


neighbouringCellOffset

DlUserService

IntraFreqTargetCellParams

minimumCpichEcNoValueForHHOminimumCpichRscpValueForHHO

Case of MeasId1 (e1a) leading to HHO detection

Cells 1 2 3 4

cpichEcNoReportingRange1A – hysteresis1A / 2

This best cell meets the criteria for RL addition SHO but IUR isdown HHO is triggered

Links from ASET

Measured links (SHO candidates)

Measured links (HHO candidates)

minimumCpichEcNoValueForHHO

MR for MeasId1 (Event 1A)

UE reports MeasId1(E1A) in case SHO RL addition conditions are met

Triggering cells may belong to SRNC or DRNC when IUR is provisioned

Several conditions must be fulfilled for SRNC to detect HHO

The triggering cell belongs to DRNC but SRNC detects an IUR outage

The following flags are set to True

isIntraFreqInterRncHHOAllowed

isIntraFreqInterRncHhoOnIurLinkDownAllowed

isHsdpaHhoWithMeasAllowed for HSDPA calls

isEdchHhoWithMeasAllowed for E-DCH calls

The triggering cell i is reported better than the best one in the ASET

EcNoi + CIOi > EcNobest_ASET + CIObest_ASET

The triggering cell i respects the following condition:

(EcNoi >= minimumCpichEcNoValueForHHO) AND (Rscpi >= minimumCpichRscpValueForHHO)Beware to confusion with minimumCpichEcNo/RscpValueForHO dealing with IFREQ HHO

In case several cells fulfill these 2 conditions, HHO is triggered towards the cell with highestEcNo + CIO






4.4 HHO Detection after MeasId16: Iur link is not provisioned

minimumCpichEcNoValueForHHO

Cells 1 2 3 4

cpichEcNoReportingRange – hysteresis / 2

This best cell can NOT be added into the ASET as IUR is not provisioned HHO is triggered

Case of MeasId16 leading to HHO detection

Links from ASET

Measured links (SHO candidates)

Measured links (HHO candidates)

RNC

RadioAccessService

UmtsNeighbouring

isIntraFreqInterRncHHOAllowed = TRUEisHsdpaHhoWithMeasAllowedisEdchHhoWithMeasAllowed



DlUserService



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 callsisEdchHhoWithMeasAllowed 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 highestEcNo + CIO






4.5 RAN Model

DedicatedConf

RadioAccessService

RNC

FddCell HoConfClass

UsHoConf

FullEventHoConfHhoMgt


FullEventRepCritHhoMgt

FullEventRepCritEvent1AWithoutIur

DlUserService


FullEventHOConfHhoMgtEvent1AWithoutIur

amountRepmaxNbReportedCells

repInterval

isIntraFreqInterRncHHOAllowedisIntraFreqInterRncHhoOnIurLinkDownAllowed

isHsdpaHhoWithMeasAllowedisEdchHhoWithMeasAllowed


isEventTriggeredMeasAllowed

cpichEcNoReportingRangehysteresis

timeToTrigger





5 SRNS Relocation (UE not Involved)






5.1 Principle

PS

After the SRNS relocation andlocation registration: data path is optimised

Before the SRNS relocation andlocation registration: soft handover has been

done via the Iur interface

LA2, RA2LA2, RA2

HLRHLR GGSNGGSN

NewSGSN

OldSGSN

OldSGSN

NewSGSNOld

MSCOld MSC

SourceSRNC

TargetRNC

TargetSRNC

SourceRNC

UE UE

LA1, RA1LA1, RA1

New MSC

New MSC

CS

The SRNS Relocation procedure is used to move the RAN to CN connection point at the RNC from the source SRNC to the target RNC. As a result of this procedure:

The Iu links are relocated from the Source RNC (S-RNC) to the Target RNC (T-RNC)

The target RNC becomes the SRNC.

The source RNC is released from the call.

The figure shows a PS domain SRNS relocation example where the S-SRNC and T-SRNC are connected to different SGSNs (i.e. inter-SGSN Relocation).

Before the SRNS Relocation procedure, the UE is registered in the old SGSN. The source RNC is acting as the serving RNC (SRNC).

After the SRNS Relocation procedure the target RNC is acting as the serving RNC.

The SRNS Relocation (UE not involved) is triggered when there are no links in the active set on the Source RNC and all remaining links in the active set are on a single DRNC.

The SRNS relocation procedure implemented in Alcatel-Lucent UA5 UTRAN release is called Iur-based SRNS relocation to differentiate it from the other variants of SRNS relocation defined by 3GPP 23.009.

The key benefits associated with Iur-SRNS relocation are as follows:

Reduction in the delay associated with the routing of the user plane flow via the Iur interface.

Capacity gain at RNC and Iur interface due to saving of Iur transmission resources

QoS improvement: better RRM, less inter-RNC HHO






5.2 Example: Call Flow PS

UESourceRNC

Target RNC

OldSGSN

NewSGSN GGSN

1. Decision to perform SRNS Reloc

2. Relocation Required3. Forward Relocation Request

4a. Relocation request

4c. Relocation Request Ack

5. Forward Relocation Response

6. Relocation Command

7. Relocation Commit8. Relocation Detect

9a. RAN Mobility Information

9b. RAN Mobility Info Confirm 10. Relocation Complete

13a. Update Pdp context Req

13b. Update Pdp context Resp.

11a. Forward Reloc Complete

11b. Forward Reloc Complete Ack12a. Iu Release Command

12b. Iu Release Complete

14. Routing Area Update (If RAI changes)

NodeB

4b. Iub SyncRelocationPreparation

RelocationExecution

The SRNS Relocation procedure is used to move the RAN to CN connection point at the RNC from the source SRNC to the target RNC. As a result of this procedure:

The Iu links are relocated from the Source RNC (S-RNC) to the Target RNC (T-RNC)

The target RNC becomes the SRNC.

The source RNC is released from the call.

The figure shows a PS domain SRNS relocation example where the S-SRNC and T-SRNC are connected to different SGSNs (i.e. inter-SGSN Relocation).

Before the SRNS Relocation procedure, the UE is registered in the old SGSN. The source RNC is acting as the serving RNC (SRNC).

After the SRNS Relocation procedure the target RNC is acting as the serving RNC.

The SRNS Relocation (UE not involved) is triggered when there are no links in the active set on the Source RNC and all remaining links in the active set are on a single DRNC.

The SRNS relocation procedure implemented in Alcatel-Lucent UA5 UTRAN release is called Iur-based SRNS relocation to differentiate it from the other variants of SRNS relocation defined by 3GPP 23.009.

The key benefits associated with Iur-SRNS relocation are as follows:

Reduction in the delay associated with the routing of the user plane flow via the Iur interface.

Capacity gain at RNC and Iur interface due to saving of Iur transmission resources

QoS improvement: better RRM, less inter-RNC HHO






5.3 Parameters

is3Gto3GWithIurAllowed

timeToTrigger3Gto3GWithIur

RNC

RadioAccessService

NeighbouringRNC

isOutgoing3Gto3GWithIurAllowedForCsConversationalisOutgoing3Gto3GWithIurAllowedForCsCsStreamingisOutgoing3Gto3GWithIurAllowedForCsPsInteractiveisOutgoing3Gto3GWithIurAllowedForCsPsBackground

isIncoming3Gto3GWithIurAllowedForCsConversationalisIncoming3Gto3GWithIurAllowedForCsStreamingisIncoming3Gto3GWithIurAllowedForPsInteractiveisIncoming3Gto3GWithIurAllowedForPsBackground





6 Intelligent Multi-Carrier Traffic Allocation






6.1 Principle

....32GSM

....23F2

....11F1

CsSpeech+Other

…CsConversationalCsSpeechLoss of coverage

CAC failureService type (HSDPA)

Load balancing

Why iMCTA ?

R99

HSDPAHSDPA

GSM

HSDPA HSDPA HSDPA

R99

R99

R99

R99

R99

R99

GSM GSM GSM

GSM GSM GSM GSM

R99

HHO AlarmUser Service CAC Failure

Cop

yrig

ht ?

1996

Nor

ther

n Te

leco

m

Copyright ?1996 N

orthern Telecom

R99

3G F1

3G F2

2G

R99Mobility Service

The objective of the intelligent Multi-Carrier Allocation feature (iMCTA) is to optimize the trafficdistribution both between layers and cells. The iMCTA function is managed by the RNC.

To increase the network capacity, operators may deploy multi layer configurations with several layers structures: Multi layers with equal coverage, hot spots, micro cells, hierarchical cells structure.

iMCTA works with up to four UMTS carriers, plus a 2G layer (whatever the frequencies). The FDD carriers should be on the same frequency band (1900, or 850).

The traffic distribution strategy may be based on:

load balancing

service partitioning

UE speed (not used in UA5)

carrier redirection preferences

mobility

The introduction of HSDPA/HSUPA will be also progressive with hot spots and there is a need to redirect HSDPA/HSUPA capable mobile (R5, R6) towards HSDPA/HSUPA cells.

iMCTA allows to:

Improve network capacity by

Allocating radio resources preferably onto a certain layer according to:

Service Type

UE capability (R99, R5, R6)

Balancing load between cells of the different overlapping layers

Redirecting a UE to a unloaded cell on a CAC failure occurring in a serving cell

Improve network quality by avoiding call drop in case of loss of coverage on a certain layer

In UA5 a UE having an HSDPA RAB in an HSxPA capable cell will perform a HHO on iMCTA alarm using measurements thanks to CM activation.

hsiddhar

Sticky Note

Actually the UE capabilty






6.2 iMCTA Triggers

iMCTA Alarm GSM

R99 R99

PS call establishment

HSxPAA

A

1. Alarms

2. CAC Failure

iMCTA CAC CR99

GSM

HSxPA

CS call

CAC failure at PS call establishment

C

3. Service Partitioning

4. Change of Service

GSM

R99

HSDPA

R5 UE - CS call

PS call establishmentPS call release

S

SiMCTA User Service S

iMCTA Mobility Service M R5 UE - PS call

GSM

R99 R99

HSxPA

M

Primary cell change

iMCTA (intelligent Multi-Carrier Traffic Allocation) algorithm manages HHO handovers which may be triggered for several reasons:

save the call in case of loss of coverage: iMCTA triggered on HHO Alarm (case 1)

manage to establish a RAB that has experienced a CAC failure: iMCTA triggered on CAC Failure (case 2)

optimize throughput by redirecting CS and PS calls to a prefered layer

In case of a user service establishment or modification: iMCTA triggered on User Service (case 3)

In case of Primary Cell change: iMCTA triggered on Mobility Service (case 4)

For any iMCTA trigger cause a load balancing can be applied in order to improve the overall network quality and capacity:

For iMTCA triggers on User Service or Mobility Service:

Serving cell load can be checked to enable or disable the user redirection

Target cell load can be checked to favor less loaded eligible cells

For iMTCA triggers on HHO alarm or CAC Failure:

Serving cell load is not checked

Target cell load can be checked to favor less loaded eligible cells

The iMCTA function only applies to call in connected mode (Cell DCH, E-DCH and HS-DSCH).

Call in Cell Fach (signaling or traffic), Cell PCH or URA PCH are not managed.






6.3 Generic iMCTA Algorithm

iMCTA Triggering

iMCTA Algorithm

iMCTA Configuration RetrievalService HO option

RAT Selection

Measurement Report Processing

Measurement Configuration

iMCTA Validity Checking

Neighboring cells Searching and Filtering

HHO Decision

iMCTA is composed of 7 different functions that are processed sequentially:1.Invoking iMCTA upon 4 call triggering events:

HHO Alarm triggerCAC failure triggerUser Service triggerMobility Service trigger

2.iMCTA validity checking to decide whether iMCTA must be processed or not3.iMCTA configuration retrieval to select the right Priority table (priority is a key parameter for iMCTA and is defined per carrier and per service type)4.Neighbouring cell searching and filtering to select and filter all inter-frequency and GSM neighboring cells5.Radio Access Selection (FDD or GSM) based on neighboring cell and priority tables to select a Radio Access Technology (RAT) to measure6.Measurement configuration to provide NodeB and UE with complete measurement information (Compressed Mode and neighboring cell list corresponding to the selected RAT)7.Measurement report processing to process all RRC Measurement Report messages sent by UE; after this step, HHO can possibly be triggered by RNC.






6.4 iMCTA Triggering

iMCTA Servicetriggering

Mobility Service on

User Service on

iMCTA algorithm

iMCTA Alarmtriggering

HHO Alarm on

- Quality too bad

- Level too low

iMCTA CACtriggering

CAC Failure on

- RAB assignment procedure (RAB to setup or modify)

- RAB assignment procedure (RAB to delete, in that case iMCTA CAC is processed for the remaining RAB(s))

- Iu release procedure (in that case iMCTA CAC is processed for the remaining RAB(s) of the other CN domain.

Primary Cell change

- RAB assignment procedure (RAB to setup or modify)

- RAB assignment procedure (RAB to delete if it is not the last RAB)

- Iu release procedure (if a RAB is still present for the other CN domain)

- Relocation Request procedure (if at least one RAB exists)

- Always-On upsize

There are 3 types of iMCTA invocations:HHO Alarm trigger

iMCTA is called on any HHO Alarm measurement whether Periodic Mode or Full Event Triggered Mode is used

CAC failure triggerit covers all causes of CAC:

From Cell: no radio resource availableFrom Iub, Iur: Radio Link Reconfiguration FailureFrom Iub, Iur, Iu: Transport Bearer failureFrom S-RNC: user plane resource allocation failure

iMCTA CAC is an enhancement of UA4.2 “3G to 2G CN-involved directed retry” feature as 2G HHO can now be triggered with measurements (only Blind HO in UA4.2).

Service triggeriMCTA Service aims at redirecting UE to a more appropriate layer (either UMTS or GSM) in order to improve:

the quality of service provided to this user (e.g. by redirecting an HSUPA-capable UE to an HSUPA-capable cell)the usage of UTRAN resources (e.g. by redirecting a UE from a “Red” cell to a “Green” one)

iMCTA Service is invoked after RNC has sent RANAP Rab Assignment Response or Iu Release Complete to CN, i.e. after RAB is established or released. Therefore, call establishment KPIs are not impacted by iMCTA Service.






6.5 iMCTA Alarm Triggering: Periodical Mode

cpichEcNoThreshold cpichRscpThreshold

counter stepUp

stepDown

(FastAlarmHardHoConf)

IFP-CPICH_EcNo(primary) < cpichEcNoThresholdORP-CPICH_RSCP(primary) < cpichRscpThreshold

THENAlarm Handover Counter is incremented by stepUpIF

Alarm Handover Counter > counterTHEN

• iMCTA algorithm is triggeredELSE

Alarm Handover Counter = Max ( 0; Alarm Handover Counter – stepDown)

Primary Cell Ec/No

HHO AlarmCM and Measurements

iMCTA triggered

Fast Alarm Handover feature offers the possibility of combining both measurements and alarm handover criteria.

The Alarm measurements are activated once a criterion is fulfilled.

Then iMCTA algorithm is triggered. It is this algorithm which is responsible for performing the global HHO procedure (inter-FDD or inter-RAT).

The iMCTA algorithm is fully described in the next chapter.

The trigger criteria are based on the same principle as alarm criteria, using CPICH Ec/N0 and RSCP thresholds associated with a counter mechanism.






6.6 iMCTA Alarm Triggering: Full Event Trigger

timeToTrigger2D (FullEventRepCritHhoMgtEvent2D)maxNbReportedCells2D (FullEventRepCritHhoMgtEvent2D)

timeToTrigger2F (FullEventRepCritHhoMgtEvent2F)maxNbReportedCells2F (FullEventRepCritHhoMgtEvent2F)

Best Cell

CPICH_EC/NoCPICH_RSCP

leaving 2D reporting rangeentering 2D reporting range

Even

t2D

cpichEcNoThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)cpichRscpThresholdUsedFreq2D (FullEventHOConfHhoMgtEvent2D)hysteresis2D (FullEventHOConfHhoMgtEvent2D)cpichEcNoThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)hysteresis2F (FullEventHOConfHhoMgtEvent2D)cpichRscpThresholdUsedFreq2F (FullEventHOConfHhoMgtEvent2F)

2D absolute threshold

2/22 ddUsedUsed HTQ m≤ 2/22 ffUsedUsed HTQ ±≤

timerAlarmHoEvent2D(FullEventHOConfHhoMgt)

2F absolute thresholdleaving 2F reporting rangeentering 2F reporting range

Even

t2F

Even

t2D

Alarm Measurement Criteria

Alarm Measurement Timer

NOT HIT HIT

The RNC uses the following algorithm:

The timer timerAlarmHOEvent to confirm alarm handover criteria is started once a 2D event is received for any of the measurement quantity (RSCP or Ec/No).

If another subsequent 2D event with another measurement quantity is received, the timer shall continue and the RNC records the fact that that both quantities fulfill their triggering condition.

The timer timerAlarmHOEvent is stopped if a 2F event corresponding to the triggering 2D is received. In case both quantities (RSCP and Ec/N0) have fulfils their triggering condition, the timer is stopped if both 2F corresponding events are received (Ec/N0 and RSCP).

A change of primary (event 1D) received while the timer is running has no effect on the algorithm, except when the new primary has different thresholds than the previous primary cell, in which case the 2D/2F events are modified with the new thresholds.

Once the timer timerAlarmHOEvent elapses, the RNC triggers the iMCTA algorithm described in the next chapter.






6.7 iMCTA Validity Checking: Primary Cell Is Under S-RNC

SRNC DRNC

MS

Primary

AS

CN

EnabledEnabledDisabledEnabledAlarmAndService

EnabledEnabledEnabledEnabledAll

DisabledDisabledEnabledEnabledAlarmAndCAC

DisabledDisabledDisabledEnabledAlarmOnly

Alarm CAC User Service

Mobility Service

mode(Primary Cell)

mode

SRNC

NodeB

PrimaryFDDCell

FddIntelligentMultiCarrierTrafficAllocation

iMCTA

iMCTA Algorithm


RAT Selection





iMCTA Algorithm


RAT Selection





Once iMCTA trigger has been identified, Validity Checking aims at determining whether this specific iMCTAtrigger is enabled on the Primary cell, through mode parameter that can have 4 different values:

AlarmOnly to have only iMCTA Alarm enabled

AlarmAndCac to have iMCTA Alarm and iMCTA CAC enabled

AlarmAndService to have iMCTA Alarm and iMCTA Service enabled

All to have all iMCTA triggers enabled

mode parameter must be set at primary cell level, i.e.:

at FDD cell level when primary cell’s C-RNC is the Serving RNC, through FddIntelligentMultiCarrierTrafficAllocation object (so-called FddImcta)

at Neighbouring RNC level when primary cell’s C-RNC is a Drift RNC, through NeighbouringRncIntelligentMultiCarrierTrafficAllocation object (so-called NeighbouringRncFddImcta)






6.8 iMCTA Validity Checking: Primary Cell Is Under D-RNS

SRNC DRNC

MS

AS

Primary

CN

AlarmAndService

All

DisabledDisabledEnabledEnabledAlarmAndCAC

DisabledDisabledDisabledEnabledAlarmOnly

Alarm CAC User Service

Mobility Service

mode(Neighbour RNC)

mode

SRNC

NeighbouringRNCDRNC

NeighbouringRNCIntelligentMultiCarrierTrafficAllocation

NodeB

PrimaryFDDCell

neighbouringRncId

iMCTA

iMCTA Service can only be processed when the Primary cell is located on Serving RNC.

Therefore, iMCTA Service can only be activated on FddImcta object.

mode must be never be set to AlarmAndService or All on NeighbouringRncImcta object.






6.9 iMCTA Validity Checking: Specific to User Service Trigger

Enabled

Disabled

RelocationSRB+TRB->SRB+TRB

Enabled

Disabled

RAB assignmentRAB modification

RAB ReleaseSRB+TRB->SRB+TRB

EnabledEnabledFalse

DisabledEnabledTrue

1st RAB assignment

SRB->SRB+TRB

AO UpsizeSRB+TRB->SRB+TRB

userServiceSigToTrafficOnlyEnable

(Pimary Cell)

iMCTA User Service on

userServiceSigToTrafficOnlyEnable

SRNC

NodeB

PrimaryFDDCell

FddImcta

When userServiceSigToTrafficOnlyEnable parameter is set to True, iMCTA User Service is only processed consecutively to the establishment of the very first RAB, i.e. after transition from standalone SRB (DCH 3.4 or 13.6 kbps) to SRB+TRB (either CS or PS).

Therefore, this parameter allows to limit the number of iMCTA User Service occurrence.






6.10 iMCTA Validity Checking: Specific to Mobility Service Trigger

DisabledFalse

EnabledTrue

iMCTAMobility Service

mobilityServiceForHsxpaEnable(Pimary Cell)

HSxPA capable UE

mobilityServiceForHsxpaEnable

mobilityServiceForNonHsxpaEnable

SRNC

NodeB

PrimaryFDDCell

FddImcta

DisabledFalse

EnabledTrue

iMCTAMobility Service

mobilityServiceForNonHsxpaEnable(Pimary Cell)

non-HSxPA capable UE

When userServiceSigToTrafficOnlyEnable parameter is set to True, iMCTA User Service is only processed consecutively to the establishment of the very first RAB, i.e. after transition from standalone SRB (DCH 3.4 or 13.6 kbps) to SRB+TRB (either CS or PS).

Therefore, this parameter allows to limit the number of iMCTA User Service occurrence.






6.11 iMCTA Validity Checking: Specific to All Service Triggers

ServiceForTrafficSegmentationPriority

Code Color

Power Color

Iub Color

CEM Color

Worst DL Cell Color

Radio Load Color

CEM Color

Worst UL Cell Color

Worst < originatingCellColourThreshold

Yes

iMCTA Configuration Retrieval

iMCTA algorithm is stopped

PRIMARY CELL LOAD ELIGIBILITY

No

isServiceSegmentationTopPriorityAND

Primary cell NOT fully compatible

Yes

No

isServiceSegmentationTopPriority

Imcta ServiceSegmentationPriorityClass

FDDCell

serviceSegmentationPriorityTableId

originatingCellColourThreshold

FDDImcta

The cell load information is needed for iMCTA to state whether the Primary cell is eligible or not to iMCTAService.

Comparing Primary cell iMCTA colour with originatingCellColourThreshold is systematically performed byiMCTA Service, for load balancing purpose but also for traffic segmentation (which is based on UE andNodeB HSxPA capabilities).

If operator’s priority is to perform traffic segmentation rather than load balancing, originatingCellColourThreshold must be set to Green so as to systematically go further in the algorithm, whatever Primary cell load.

Hence, in UA5, it was impossible to have Load Balancing and Service Segmentation fully coexisting becausethe former needs to have HHO only triggered when the cell is loaded whereas the latter needs to have HHOtriggered whatever cell load.

In UA06.0, such limitation is removed thanks to the introduction of isServiceSegmentationTopPriority, a new flag defined per serviceType, which allows to bypass originatingCellColourThreshold during 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






6.12 iMCTA Configuration Retrieval: Alarm Priority Table

priority priority priority

P2

P1

PsStreaming

P2

P1

PsIb

P2

P1

CsSpeechPlusOther

P2PNAP12G

P1P2P2FDD

CsSpeech

CsConversational

CsStreaming

Alarm priority Table

Service Type

Access Type

RNC

RadioAccessService

Imcta

AlarmPriorityTableConfClass

Access/2G Access/FDD

Service/CsSpeech Service/PsIb Service/CsSpeech

NodeB

PrimaryFDDCell

FddImcta alarmPriorityTableConfClassId

Primary Cell under S-RNC

iMCTA Algorithm


RAT Selection





iMCTA Algorithm


RAT Selection





Once it has been checked that the invoked iMCTA trigger is enabled for the Primary cell, iMCTAConfiguration Retrieval aims at selecting the Priority Table to be used.

Priority Table is an important concept in iMCTA which must be associated with ServiceType (ST) and Priority.

Each DlUserService is associated to a type of the service among the 7 possible values: CsSpeech,CsConversational, CsStreaming, PsStreaming, PsIb, CsSpeechPlusOther, None.

The following rule applies for Multi-Service DlUserService:

· CS speech + any PS: CsSpeechPlusOther· CSD conversational + any PS I/B: PsIb (this allows HSxPA capable mobiles to have

HSxPA throughput)

· Any PS streaming + any PS I/B: PsIb (this allows to prevent abusive inter-frequency HHO after PS streaming establishment as PS I/B is likely to be established first to support signaling dedicated to Streaming applications)

· SRB only or SRB+TRB on FACH: None

An iMCTA Priority table defines for a specific iMCTA Trigger (Alarm, CAC or Service) and for each ST a priority level to be applied on the different FDD and GSM neighbouring cells.

When iMCTA Alarm is triggered, the algorithm retrieves the AlarmPriorityTable that is pointed either by FddImcta or NeighbouringRncImcta object, depending on the Primary cell location.






6.13 iMCTA Configuration Retrieval: CAC Priority Table

priority priority priority

P2

P1

PsStreaming

P2

P1

PsIb

P2

P1

CsSpeechPlusOther

P2PNAP12G

P1P2P2FDD

CsSpeech

CsConversational

CsStreaming

CAC priority Table

Service Type

Access Type

RadioAccessService

Imcta

CacPriorityTableConfClass

Access/2G Access/FDD

Service/CsSpeech Service/PsIb Service/CsSpeech

cacPriorityTableConfClassId

NeighbouringRNC

NeighbouringRNCImcta

RNC

Primary Cell under D-RNC

Since iMCTA CAC has been triggered, the algorithm retrieves the CacPriorityTable that is pointed either byFddImcta or NeighbouringRncImcta object, depending on the Primary cell location.

As for iMCTA Alarm, GSM and FDD access types must have different priority in order algorithm to decide which Access to measure.






6.14 iMCTA Configuration Retrieval: Service Priority Tables

priority

P2P3P3P3PNAP12G

P1

P1

PsStreaming

P1

P2

PsIb

P1

P1

CsSpeechPlusOther

P2P2P2FDD1

P1P1P3FDD2

CsSpeech

CsConversational

CsStreaming

Service priority Table

RadioAccessService

Imcta

ServicePriorityGeneralTableConfClass

Service/CsSpeech

FddImcta servicePriorityGeneralTableConfClassId

servicePriorityTableForHsdpaConfClassId ServicePriorityTableForHsdpaConfClass

ServicePriorityTableForHsupaConfClass

Frequency /FDD2Frequency/2G Frequency /FDD1 Frequency /FDD3 Frequency /FDD4

servicePriorityTableForHsupaConfClassId

priority

Service/PsIb

Since iMCTA Service can only been triggered when Primary cell is located on Serving RNC, the algorithm can retrieve up to 3 Priority tables that are pointed by FddImcta object:

ServicePriorityGeneralTable

ServicePriorityTableForHsdpa (optional object)

ServicePriorityTableForHsupa (optional object)

The selection of the right Service Priority Table is based on UE’s HSxPA-capabilities sent in the RRC Connection Setup Complete message.

If UE is HSUPA-capable ServicePriorityTableForHsupa is retrieved if present

Otherwise ServicePriorityTableForHsdpa if present

Otherwise ServicePriorityGeneralTable

If UE is HSDPA-capable ServicePriorityTableForHsdpa is retrieved if present

Otherwise ServicePriorityGeneralTable

If UE is not HSDPA-capable nor HSUPA-capable ServicePriorityGeneralTable is retrieved

Unlike iMCTA Alarm and iMCTA CAC, each Service Priority Table (HSUPA, HSDPA or General) is composed of up to 5 frequencies

As for iMCTA Alarm and iMCTA CAC, for each ST, there must not be any common priority between one FDD frequency and one GSM frequency.

Up to 6 FDD frequencies can be provisioned, for instance 4 UMTS 2100 and 2 UMTS 900.






6.15 iMCTA Configuration Retrieval: Service HO Options

P22G

P1FDD1

P3FDD2

CsSpeech

Service priority Table if Service Type = Cs Speech and Service Handover = should


Service Handover IE

should GSM priority = P0

shall not GSM priority = PNA

should not GSM priority = P6iMCTA Service

GSM priority = unchangediMCTA Alarm or CACRadioAccessService

Imcta

RNC

serviceHoRanapIeEnable

P0

isChangeGsmIratHoCriterionAllowed

Service Handover option allows CS and PS Core Networks to inform UTRAN that GSM is preferred for this service, through the optional serviceHO Information Element (IE) which is present in RANAP RAB Assignment Request message.

Based on the 3 different values that ServiceHo IE can have (if present), iMCTA algorithm may dynamically change the GSM priority in the Priority table:

IE = should: GSM priority is overwritten with P0, i.e. GSM becomes the most preferred target Access

IE = should not: GSM priority is overwritten with P6, i.e. GSM becomes the less preferred target Access

IE = shall not: GSM priority is overwritten with PNA, i.e. GSM is no more eligible to target Access.

The processing of this optional IE is not systematic and can be enabled/disabled through serviceHoRanapIeEnable parameter.

“should not” is never taken into account when iMCTA Alarm or iMCTA CAC are triggered.






6.15 iMCTA Configuration Retrieval: Service HO Options [cont.]


Service Handover IE

should should

should not

RadioAccessService

Imcta

RNC

serviceHoRanapIeEnable

isChangeGsmIratHoCriterionAllowed

isChangeGsmIratHoCriterionAllowedAND

CS+PS call

The Service Handover option can be used for load distribution by preferring the GSM layer for CS calls using the "should" option. GSM can provide similar service for CS calls as UMTS and therefore it might be a good idea to handover CS call to a less loaded GSM system. If, however, the UE has a simultaneous PS call then the UE should be kept in UMTS to allow for simultaneous CS and PS calls, which is not supported in GSM by most GSM networks and UEs.

The MSC, which is responsible for setting the Service Handover option for CS calls, has no information whether the UE has a single CS call or the CS call is combined with a PS session. If the MSC sets the "should" option and UTRAN prefers the GSM layer then a simultaneous PS call gets suspended in case of handover to GSM. Alcatel-Lucent UTRAN has implemented the option to make the Service Handover decision dependent on the availability of a PS call. If parameter isChangeGsmIratHoCriterionAllowed is set to True, the UE has a CS call with Service Handover set to "should" and the UE has a simultaneous PS call then UTRAN internally changes the Service Handover option from "should" to "should not". With this the call is preferably kept in UMTS. Alarm handover to GSM is still possible.






6.16 iMCTA: Inter-Freq & Inter-RAT CNL Computation (Type1)iMCTA Algorithm


RAT Selection





iMCTA Algorithm


RAT Selection





typeOfCompoundingNeighbourListInterFreqtypeOfCompoundingNeighbourListInterRat

Type1

New RRC MC message for inter-freq/Inter-Rat meas. OR

Primary Cell Change*OR

Active Set Update*

(*) While ongoing inter-freq measurements

For each sponsoring cell, build a neighbouring list ordered by neighbourCellPrioBuild the final inter-frequency (or Inter-Rat) neighbouring list as follows:

1. Add the sponsoring cells2. Select the N first cells (with N stand for numOfPrimaryCellNeighbourInterFreq

(or numOfPrimaryCellNeighbourInterRAT)) from Primary Cell's neighbouring list3. Then perform the selection by number of occurrence

1. In case of conflict, select:1. the one whose sponsoring cell has the highest Ec/No2. then the one with highest neighbourCellPrio

4. Build the Compound Neighbour Lits until (maxCompoundingListSizeInterFreq(or maxCompoundingListSizeInterRAT)) is reached.

UA5:In UA5 release, the implementation for inter-frequency neighbour lists and inter-RAT neighbour list was based on the neighbour list of the primary cell, only. Compounding neighbour list is support for Intra-frequency cells.UA6:With this feature introduced, the operator is able to select, with the parameterstypeOfCompoundingNeighbourListInterFreq and typeOfCompoundingNeighbourListInterRat, the compounding neighbour list algorithm for interFreq and interRAT neighbouring cells.Feature principlesThe ALU RNC will compute Inter-Freq neighbour list in case of:

A new RRC Measurement Control message needs to be sent to the UE for inter-frequency measurements.On change of the primary cell or on active set update while an inter-frequency measurement is ongoing.

The ALU RNC will compute Inter-RAT neighbour list in case of:A new RRC Measurement Control message needs to be sent to the UE for inter-RAT measurements.The Compounding Neighbour List algorithm considers:

Occurrence of a cell within all neighbourhoodsMeasured quality of the sponsoring active set cellPriority defined per neighbouring cell






6.17 Type 1 CNL Computation: Inter-FREQ Example

Cell13

Cell14

Cell11

Cell12

Cell17

Cell18

Cell19

Cell51

Cell16

Cell15

Cell27

Cell24

Cell25

Cell26

Cell23

Cell22

Cell21

Cell53

Cell52

Cell51 Cell34

Cell33

Cell32

Cell31

Cell53

Cell52

Cell55

Cell54

Cell39

Cell38

Cell37

Cell36

Cell35

Cell54

Cell55

Cell41

Cell42

Cell43

Cell44

Cell49

Cell48

Cell47

Cell46

Cell45

Common numberof occurrence

Cell1 Cell2 Cell3 Cell4

Cell27

Cell32

Cell31

Cell26

Cell23

Cell24

Cell17

Cell18

Cell19

Cell15

Cell16

Cell54

Cell55

Cell52

Cell53

Cell51

Cell11

Cell12

Cell13

Cell14

Cell25

Cell22

Cell21

Type1

numOfPrimaryCellNeighbourInterFreq

Neighbouring cells with highest occurrence

maxCompoundingListSizeInterFreq



Neighbouring cells with lower occurrence






6.18 Type 1 CNL Computation: Inter-RAT Example

Cell13

Cell14

Cell11

Cell12

Cell17

Cell18

Cell19

Cell51

Cell16

Cell15

Cell27

Cell24

Cell25

Cell26

Cell23

Cell22

Cell21

Cell53

Cell52

Cell51 Cell34

Cell33

Cell32

Cell31

Cell53

Cell52

Cell55

Cell54

Cell39

Cell38

Cell37

Cell36

Cell35

Cell54

Cell55

Cell41

Cell42

Cell43

Cell44

Cell49

Cell48

Cell47

Cell46

Cell45

Common numberof occurrence

Cell1 Cell2 Cell3 Cell4

Cell27

Cell32

Cell31

Cell26

Cell23

Cell24

Cell17

Cell18

Cell19

Cell15

Cell16

Cell54

Cell55

Cell52

Cell53

Cell51

Cell11

Cell12

Cell13

Cell14

Cell25

Cell22

Cell21

numOfPrimaryCellNeighbourInterRAT

Neighbouring cells with highest occurrence

maxCompoundingListSizeInterRAT



Neighbouring cells with lower occurrence

Type1






6.19 Neighboring Cells Searching and Filtering: GenericiMCTA Algorithm


RAT Selection





iMCTA Algorithm


RAT Selection





CompoundedNeighboring

List

Remove neighboring cells

of Access or Frequency marked as PNA

In Priority Table


of GSM bands not supported

by UE


Inter-RAT and Inter-Freq If CM disable for this DlUserService

and UE is mono-receiver

RadioAccessService

DlUserService

isGsmCModeActivationAllowed

isInterFreqCModeActivationAllowed

GenericFiltering

Once the Priority table has been retrieved for the selected Service Type, Neighbouring Cell Searching and Filtering aims at filtering the inter-frequency and inter-RAT neighbourhood so as to eventually keep the cells:

Belonging to an authorized PLMN

Compatible with the retrieved Priority Table

i.e. neighbouring cells whose Access is PNA are removed

Compatible with GSM bands supported by UE

Compatible with Compressed Mode capabilities:

UE’s capabilities sent in RRC Connection Setup Complete message

CM activation flags per DlUserService

isGsmCModeActivationAllowed Indicates if compressed mode for GSM is allowed for this DlUserService

isInterFreqCModeActivationAllowed must be set to True for all DlUserServices

isInterFreqCModeActivationAllowed Indicates if compressed mode for inter-frequency is allowed for thisDlUserService

isGsmCModeActivationAllowed must be set to True for all DlUserServices except for the RABs that are not supported in GSM, i.e. CSD64.

With such setting, selecting UMTS or GSM as target Access is only based on iMCTA Priority tables.






6.20 Neighboring Cells Searching and Filtering: Specific


List

GenericFiltering

iMCTA Alarm


List

GenericFiltering

Removeneighboring cells

of D-RNC

iMCTA CAC


List

GenericFiltering

Removeneighboring cellsof lower Prioritythan Primary Cell

iMCTA Service

As per 3GPP, neither the relocation procedure nor the RNSAP RL addition procedure supports the Transport Channel addition/deletion. Therefore, for iMCTA CAC, every neighbouring cell belonging to another RNC are removed.

For iMCTA Service, unlike iMCTA Alarm and iMCTA CAC, the neighbouring cells whose priority is worse than the Primary cell’s are removed.






6.21 RAT SelectioniMCTA Algorithm


RAT Selection





iMCTA Algorithm


RAT Selection




Neighboring cells Searching and FilteringCompounded

Neighboring List

Keepneighboring cells

of same RATas highest Priority

neighboring cell RAT

FDD Cell Fa P2FDD Cell Fb P2FDD Cell Fc P2GSM Cell Ga P1GSM Cell Gb P1

GSM Cell Ga P1GSM Cell Gb P1

iMCTA Alarm

RAT selectedIs 2G

Example 1

FDD1 Cell Fa P1FDD1 Cell Fb P1FDD2 Cell Fc P2FDD3 Cell Fd P1GSM Cell Ga P3GSM Cell Gb P3

FDD1 Cell Fa P1FDD1 Cell Fb P1FDD2 Cell Fc P2FDD3 Cell Fd P1

iMCTA Service

RAT selectedIs 3G

Example 2

Once the neighbourhood has been filtered, this function aims at determining the target Access by simply considering the cell with the highest Priority.

It shows how important is the rules stating that:

GSM and UMTS priority parameters must be different for iMTCA Alarm and iMCTA CAC

there must not be any common priority parameter value between one FDD frequency and one GSM frequency for iMCTA Service

In case the neighbouring cell list is empty:

2G Blind HO is performed if provisioned for iMCTA Alarm (call drop avoidance)

2G Blind HO is NOT performed even if provisioned for iMCTA CAC and iMCTA Service






6.22 Measurement ConfigurationiMCTA Algorithm


RAT Selection





iMCTA Algorithm


RAT Selection





RRC Measurement Control

CM activation+

NodeB UE

Neighboring Cells

eitherInter-RAT

orInter-Freq

Once target Radio Access has been selected, Measurement Configuration setup Inter-frequency or GSM measurements at NodeB and UE sides, by respectively sending NBAP Compressed Mode Command and RRC Measurement Control messages.

In UA5, like in UA4.2, the alarm measurement results are reported in periodic mode.

The only difference is that:

In periodic mode : Inter-Freq/Inter-RAT are declared as additional measurements reported in the same RRC measurement reports than Intra-Frequency

In event mode: new measurements are configured to report Inter-Frequency/Inter-RAT measurements (Intra-Frequency measurement are not impacted and still reported in event-triggered mode)

The UE is requested to report up to 6 neighboring cells amongst the monitored set.

The monitored set is defined as the set of FDD inter-frequency or GSM neighbors of the primary cell provided to the UE through the MEASUREMENT CONTROL message.





6.22 Measuremebnt Configuration

6.22.1 CM Scope & Methods

Inter-frequency measurementsInter-RAT measurements

Transmission Gap Length = 3, 4, 7, 10, 14 TS

pow

er

time

idle

TGL

frame N-1 frame N+1

pow

er

time

idle

TGL

frame N-1 frame N+2idle

frame boundary

ulCModeMethod (CmodePatternSeqInfo)dlCModeMethod (CmodePatternSeqInfo)

Single-Frame Mode

Double-Frame Mode

Compressed Mode consists of the creation of regularly spaced short gaps (less than one 10 ms radio frame) in transmission in the uplink or downlink, or possibly both at the same time, and/or reception without altering the data to be exchanged on the radio interface.

Compressed Mode is mandatory in downlink and optional in uplink. It can only be achieved on dedicated channels. The Transmission Gap Length is 3, 4, 5, 7, 10 or 14 slots.

Three methods are proposed in the standard: Spreading Factor Reduction, Puncturing and Higher Layer Scheduling.

Only the Spreading Factor Reduction method is implemented for both UL and DL (when needed) for either GSM or FDD inter-frequency measurements.

Thus, only the value cmodeDlMethodSfDiv2 is allowed for DlCmodeMethod and UlCmodeMethodTwo methods can be used for time transmission reduction:

The SF can be reduced by 2 to permit the transmission of the information bits in the remaining time slots of the compressed frame. In that case, the scrambling code could be different from normal mode.






6.22.2 Need for Compressed Mode

• Dual receiver UE?• Mono Receiver UE?• GSM compatible UE?

UMTS

UMTS

GSM

GSM450Present (RadioAccessService)GSM480Present (RadioAccessService)GSM850Present (RadioAccessService)GSM900PPresent (RadioAccessService)GSM900EPresent (RadioAccessService)GSM900RPresent (RadioAccessService)GSM1800Present (RadioAccessService)GSM1900Present (RadioAccessService)

UE Capability

isInterFreqMeasActivationAllowed


isInterFreqCModeActivationAllowedisGsmCModeActivationAllowed:

(DlUserService)

The real need for Compressed Mode is provided by the UE itself. Following a network request through the UE Capability required indicator in the RRC Connection Setup message, the UE indicates in the UE Radio Access Capability IE (Measurement Capability sub-IE, provided in the RRC Connection Setup Complete message) if Compressed Mode is needed in either UL or DL for the FDD and GSM bands.

The network configure and activate the Compressed Mode in 3 possible modes:

Uplink only

Downlink only

Uplink and Downlink

Therefore, regarding CM for GSM, in order not to configure compressed mode in every case, a set of flags indicating the frequency bands of the FDD and GSM neighboring cells will be defined and used in the RNC to determine whether or not Compressed Mode is needed.

Each flag indicates that there exists at least a GSM cell of the corresponding frequency band in the access network (that is, not only being part of the GSM neighboring lists seen by the RNC) to which handovers from a 3G cell are supported by the network. Therefore, if Compressed Mode is needed by the mobile for that frequency band, it will be configured accordingly and possibly activated by the network.






6.22.3 High-Level Scheduling Method

starting CFN TGL

Dl(ul)CModeMethod (CModePatternSeqInfo)

CmodeDl(Ul)MethodSfdiv2

isHlsCmMethodPreferred (D/UlUserService)

?False

True

RLC

MAC

Physical Layer

Subset of allowedTFCs are used incompressed frame

The Spreading Factor Reduction method consists of the creation of gaps in transmission / reception and granting twice the bandwidth for compressed frames in order to compensate for the loss of bandwidth in not transmitted frames. This method applies for both uplink and downlink with fixed or flexible position mapping but it requires that the spreading factor be strictly greater than 4.

The SF is reduced by a factor two for as many slots as used for gaps and the transmitted power of these slots is increased. Thus OVSF code need to be changed, the new one is the parent code of the code used for non-compressed radio frames.

In the downlink, the scrambling code management is done through the alternate scrambling code method. This method consists of applying the new channelization code with SF/2 to the compressed frames, while applying one of the two available alternate scrambling codes (left or right alternative) depending on the original OVSF.

The figure above gives an example of how this method applies.

In the uplink, the compressed mode method by spreading factor reduction is identical to the spreading factor reduction used in the downlink but with some exceptions.

HLS introduced from 3GPP R99

Data rate is reduced from higher layers (i.e. MAC) by means of TFC restriction in the TFCS

SF and scrambling code remain unchanged

No additional power transmission to keep the same level of protection of the user bit

Applicable either in UL only, DL only, or both UL/DL

Prior to UA6, only SF/2 method was supported, whatever RAB, and CM method was uniquely defined usingdlCModeMethod and ulCModeMethod parameters under CModePatternSeqInfo object.

In UA6, HLS has been introduced and is supported for some specific UL and/or DL User Services. Therefore, the previous parameters are not used anymore and are replaced by isHlsCmMethodPreferred parameter defined per DlUserService and UlUserService.

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






6.22.4 HLS Activation

RadioAccessService

dlCModeMethod [not used; replaced by DlUserService.isHlsCmMethodPreferred]

ulCModeMethod [not used; replaced by UlUserService.isHlsCmMethodPreferred]

dlFrameType [not used; hard-coded with typeA for HLS and typeB for SF/2]

DlUserService

NeighbouringRnc

Parameter not used anymore but still present in RAN Model

RNC

UlUserService

CmodePatternSeqInfo

isHlsCModeAllowed isHlsCmAllowedOnDrnc

isHlsCmMethodPreferred

isHlsCmMethodPreferred

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

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

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

- (PS str > 64kbps) + (PS I/B > 32kbps) With or without CS speech

-Any other PS combination over DCH with SF=4

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

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

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

CSD64 + (PS I/B > 64kbps)

(PS str > 64kbps) + (PS I/B > 32kbps) with or without CS speech

Any other PS combination over DCH with SF=4

SF/2 method is used for the remaining User Services, mostly:

Standalone SRB, CS speech, CSD, PS streaming (with or without CS speech)

All RAB combinations over HSDPA or E-DCH (for which HLS is in restriction)

This restriction should be removed in UA7

Patterns are the same for SF/2 and HLS methods

CM method is determined at each RAB addition, deletion or reconfiguration

Sent to UE and NodeB at CM configuration

NBAP RlSetup/Reconf and RRC RadioBearerSetup/Reconf/Release

Based on RNC and NeighbouringRnc activation flags

isHlsCModeAllowed under RadioAccessService

isHlsCmAllowedOnDrnc under NeighbouringRnc

Reconfiguration to SF/2 when not supported/allowed on DRNC

Based on operator's strategy

isHlsCmMethodPreferred defined per DlUserService and UlUserService

When selecting a CM method, RNC checks isHlsCmMethodPreferred with respect to the method(s) supported in UA06.0 by this UserService

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






6.22.5 CM Pattern Sequences

Sub-pattern 1 Sub-pattern 2 Sub-pattern 1 Sub-pattern 2 Sub-pattern 1 Sub-pattern 2

#1 #2 #TGPRC#TGCFN

Gap1 Gap2 Gap1 Gap2

tgsn

tgl1 tgl2 tgl1 tgl2

tgd tgd

tgpl1 tgpl2

tgprc (CModePatternSeqInfo)tgcfnOffset (CModePatternSeqInfo)

Compressed Mode is controlled by the UTRAN: it is configured by the RNC on a per UE basis in the form of Compressed Mode Transmission Gap Pattern Sequences. A CM pattern sequence may be composed of up to two sub-patterns and is dedicated to one specific measurement purpose.Each pattern is described by the parameters listed below, those parameters being defined at the cell level:

TGL1 and TGL2: length of transmission gaps 1 and 2 expressed as a number of slots. Possible values are 3, 4, 5, 7, 10 and 14. TGL2 is an optional parameter and if a value is not given by the upper layers, then by default TGL2 = TGL1,

TGSN: the first gap occurs TGSN slots after the beginning of the pattern,

TGD: the two gaps are separated by a distance of TGD slots,

TGPL1 and TGPL2: length of pattern 1 and 2 expressed in radio frames,

TGCFN: CM start expressed in CFN as CFNx + TgcfnOffset) mod[256],

TGPRC: number of times the Transmission Gap Pattern is repeated within the Transmission Gap Pattern Sequence.






6.22.6 Pattern Sequence Configuration

A pattern sequence is defined for each type of measurement

CmodePatternSeqInfoisPatternAllowed = TrueTgmp = 2 TgcfnOffset = 0Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 8Tgsn = 8

CmodePatternSeqInfo/0isPatternAllowed = TrueTgmp = 2 TgcfnOffset = 0Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 8Tgsn = 8

CmodePatternSeqInfo [1]isPatternAllowed = TrueTgmp = 3 TgcfnOffset = 48Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 78Tgsn = 8nIdentifyAbort = 26

CmodePatternSeqInfo/1isPatternAllowed = TrueTgmp = 3 TgcfnOffset = 48Tgd = 0Tgl1 = 14Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 78Tgsn = 8nIdentifyAbort = 26

CmodePatternSeqInfo [2]

isPatternAllowed = TrueTgmp = 1 TgcfnOffset = 0Tgd = 0Tgl1 = 10Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 50Tgsn = 10

CmodePatternSeqInfoCmodePatternSeqInfo/2

isPatternAllowed = TrueTgmp = 1 TgcfnOffset = 0Tgd = 0Tgl1 = 10Tgl2 = 0Tgpl1 = 6Tgpl2 = N/ATgprc = 50Tgsn = 10

GSM RSSI measurement

BSIC identification

FDD measurements

RadioAccessService

A certain number of pattern sequences can be defined in UTRAN configuration, each of them being associated with a specific measurement purpose.

The pattern sequence is defined by a set of parameters (transmission GAP and CM patterns parameters), that are grouped into the CModePatternSeqInfo object:

Instance 0 of CmodePatternSeqInfo corresponds to a Compressed Mode measurement purpose GSM RSSI Measurements.

Instance 1 of CmodePatternSeqInfo corresponds to a Compressed Mode measurement purpose GSM Initial BSIC Identification.

Instance 2 of CmodePatternSeqInfo corresponds to a Compressed Mode measurement purpose FDD Inter-Frequency Measurement.






6.22.7 FDD Inter-Freq CM Pattern

6 Frames (60 ms)

50 Patterns (3000 ms)

10 Time Slots 70 Time Slots

Gap = 10 Time SlotsCFN + 0

For FDD inter-frequency measurement, a single pattern of 6 frames repeated 50 times is used, leading to a basic compressed mode measurement period of 3 s.

The UE is provided with the FDD neighboring cell list, when receiving the RRC Measurement Controlmessage. Using this list, the UE starts the CPICH_RSCP and CPICH_Ec/No measurements process that can be seen as a sort of endless loop, intending to identify the best neighboring cells.

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






6.22.8 GSM Inter-RAT CM Pattern

6 Frames (60 ms)

8 Patterns (480 ms)

8 Time Slots 68Time SlotsGap = 14 Time Slots

CFN + 0

CFN + 48

78 Patterns (4680 ms)

RSSI BSIC

In the case of GSM initial BSIC identification, the UE is to take the results of the most recent set of GSM RSSI samples and attempt to identify the BSICs of the 8 strongest cells, proceeding in single strength order.

It has to be noted that the time required for a measurement report is essentially dictated by the time required to identify the BSICs of the required number of cells. As a consequence, it is better to choose the compressed mode patterns for this operation first and then build the patterns for GSM RSSI measurements around this pattern.

That’s the reason why:

a transmission gap shorter that 14 has been chosen in order to allow good performance on BSIC identification

8 patterns of 6x10ms have been allocated to RSSI measurements since the measurement period for the GSM carrier RSSI measurement is 480 ms in the CELL_DCH state (as stated in [3GPP_R01])

3x26 patterns have been allocated to initial BSIC identification in order to allow a minimum of 3 cells to be reported in the worst case (e.g. when it takes up to nIdentifyAbort to identify each cell).






6.23 Measurement Report Processing (MRP)

Measurement Report

Measurement Report

NodeBUE

• GSM Carrier RSSI

• Observed time difference to GSMCell

• Verified BSIC

• CPICH Ec/No

• CPICH RSCP

MeasurementID


MeasurementResults

6 Best Monitored Set cells

either Inter-RAT

or Inter-Freq

6 Best Monitored cells

maxCellsRepType (static)

interFreqFilterCoeff

rrcIntraFreqMeasurementReportingPeriodrrcGsmMeasurementFilterCoeff


InterFreqMeasConf

RRCMeasurement

iMCTA Algorithm


RAT Selection





iMCTA Algorithm


RAT Selection










6.23.1 iMCTA Alarm/CAC – Inter-Freq Case


FDD Eligible Cells

For each FDD carrierkeep the cell with highest

CPICH_Ec/No + CIO

Keep cellswith lowest load

Filtering on HSxPA capabilities

for iMCTA Alarm or CAC

Keep the cell with highest

CPICH_Ec/No + CIO

FDDCell


iMCTA Algorithm


RAT Selection





iMCTA Algorithm


RAT Selection





FDD Eligible Cells filtering is explained later on in the document.

Filtering on HSxPA capabilities for iMCTA Alarm or CAC is explained later on in the document.

FDD Cell Load must be understood here as Worst Combined DL and UL Cell Colours

All reported neighboring cells whose load is the lowest, among all cells remaining in the list after Filtering on HSxPA capabilities, must be kept; all the others are removed.

This is applicable whatever Priority of the neighboring cell.

For instance, if some reported cells have their Cell Colour= GREEN and others = YELLOW, then only the cells of GREEN Cell Colour are kept, YELLOW ones are removed.

Note: an FDD cell belonging to a neighboring RNC is considered as RED as Serving RNC is not able to determine its load color.






6.23.1.1 Inter-Freq Case – FDD Eligible Cells

FDD2 Neighboring Cell

FDD1 Primary Cell

FDD1 Neighboring Cell

CPICH_Ec/No > minimumCpichEcNoValueForHO

AND

CPICH_RSCP > minimumCpichRscpValueForHO

RadioAccessService

DlUserService

minimumCpichEcNoValueForHO

minimumCpichRscpValueForHO

FDD Eligible Cells

To be eligible to HHO, a FDD neighboring cell must be reported better than 2 thresholds, one for CPICHEc/No, another for CPICH RSCP.






6.23.1.2 Inter-Freq Case - Filtering on HSxPA Capabilities


HSUPA cellsonly

HSxPAUE ?

someHSUPAcells ?

someHSDPAcells ?

HSDPA cells

only

R99

cells

Yes Yes

No

Yes

NoNo

Filtering on UE and reported cells HSxPA capabilities aims at optimizing UTRAN radio resources since onlyHSxPA capable mobiles are able to use HSxPA radio resources.

Don’t forget that for iMCTA Alarm or iMCTA CAC Priority is the same between the different FDD carriers.

As an example, if UE is HSUPA capable, RNC will keep:

the HSUPA-capable cells if present,

otherwise, the HSDPA-capable cells if present

· otherwise all cells.

This filtering can be seen as a “best-effort” filtering.

HSxPA UE stands for HSUPA or HSDPA UE, i.e. R6 or R5 UE






6.23.2 iMCTA Alarm or CAC – Inter-RAT Case

gsmCellIndivOffset

GSM Eligible Cells

Check 2G cell color

Keep the cellwith highest GSM_RSSI + CIO

among lowest load cells

FDDCell

GsmNeighbouringCell

RadioAccessService

Imcta

inhibitTimer3g2ginhibitTimer3g2gLoad

2G Cell XColour

GSM Eligible Cells filtering is explained later on in the document.

GSM Cell Load must be understood here as a mean to inhibit a HHO to a GSM cell to which a previously attempted HHO has failed in the last inhibitTimer3g2g seconds.

A GSM target cell will have a RED Cell Colour if a handover towards this cell has been rejected for load reasons in the previous inhibitTimer3g2g seconds.

otherwise the Cell Colour is GREEN.

The 2G cell load detection is based on the receipt of the RANAP Relocation Preparation Failure message with a cause IE value equal to “Relocation failure in target CN/RNC or target system”.






6.23.2.1 Inter-RAT Case - GSM Eligible Cells

GSM Neighboring Cell

FDD1 Primary Cell

GSM Neighboring Cell

GSM Carrier RSSI > minimumGsmRssiValueForHO

RadioAccessService

minimumGsmRssiValueForHO

GSM Eligible Cells

To be eligible to HHO, a GSM neighboring cell (BCCH Rxlev) must be reported better than a threshold.






6.23.2.2 Inter-RAT Case – 2G Cell Load Management

RNCBSC

CN

is2GCellLoadInformationManagementAllowedisCellLoadInformationSendingAllowed

Cop

yrig

ht ?

1996

Nor

ther

n Te

leco

m

Loaded 2G cellUnloaded 2G cell

GSM

UMTS

FalseTrue

Cell Load Information

Dl(Ul) capacity ClassDl(Ul) load valueDl(Ul) RT load valueDl(Ul) NRT load value

2G Cell Load Info 3G Cell Load Info

Dl(Ul) capacity class CapacityClass

DL(UL) Cell Color

Dl(Ul)GreenLoadValueDl(Ul)YellowLoadValue

Dl(Ul)RedLoadValue

gsmDl(Ul)AvailableCapacityThresholdToRedColor

Dl(Ul) GSM cell available capacity = Dl(Ul) cell capacity class

x (100- Dl(Ul) load value/100)

inhibitTimer3g2gLoad

inhibitTimer3g2g

timeiMCTAService

MR MR

HHO to 2G cell

X

HHO reject from 2G

2G Cell XColour

MR

HHO to 2G cell

X

Dl(Ul) load valuecheck

The aim of this feature is to make better 2G Target cell selection during an inter-system handover procedure, thanks to a better knowledge of the 2G cell load, which are provided by the 2G BSC.

Moreover, the RNC takes the opportunity to provide, during an inter-system handover procedure, the 3G cell load information to the 2G BSC so as to allow it to improve, him too, the 3G Target cell selection. The 3G cell load information are sent in the following RANAP messages:

Relocation required / old BSS to new BSS information

Relocation request ack / new BSS to old BSS information

Relocation failure / new BSS to old BSS information

During inter-system handover procedures, the feature must ensure the following functions when the feature is activated:

Compute the UTRAN cell load information and send it to the BSC

When the GSM cell load information is provided by the BSC, compute the GSM cell load color based on this received cell load information

If the 2G network supports the feature Unified RRM Step 2, the GSM cell load information is received by the RNC in the following messages:

Relocation request / source RNC to target RNCRelocation command / inter system information transparent containerRelocation preparation failure / inter system information transparent container






6.23.2.2 Inter-RAT Case – 2G Cell Load Management [cont.]

2G Cell Load

If the parameter is2GCellLoadInformationManagementAllowed is set to TRUE, the RNC translate the GSMcell load information in a GSM cell load color thanks to the specific thresholds. The RNC shall translate thecell load information element in a value that can be used by the iMCTA algorithm.

The cell load information is:

Cell Capacity Class

o Corresponds to the planned maximum load of the cell. It is a value between 1 and 100 (%) that characterizes the cell with regards to other cells

Load value

o Corresponds to the cell load relative to the planned maximum load above. It is a valuebetween 0 and 100 (%).

RT load value

o Corresponds to the part of the load generated by real time traffic. It is a value between 0 and 100(%). Other values mean “no information”.

NRT load information value

o Gives the cell load situation regarding non real time traffic. It is a value between 0 and 3.Other values mean “no information”.






6.23.2.3 Inter-RAT Case – Handover Call Flow

The aim of this feature is to make better 2G Target cell selection during an inter-system handover procedure, thanks to a better knowledge of the 2G cell load, which are provided by the 2G BSC.

Moreover, the RNC takes the opportunity to provide, during an inter-system handover procedure, the 3G cell load information to the 2G BSC so as to allow it to improve, him too, the 3G Target cell selection. The 3G cell load information are sent in the following RANAP messages:

Relocation required / old BSS to new BSS information

Relocation request ack / new BSS to old BSS information

Relocation failure / new BSS to old BSS information

During inter-system handover procedures, the feature must ensure the following functions when the feature is activated:

Compute the UTRAN cell load information and send it to the BSC

When the GSM cell load information is provided by the BSC, compute the GSM cell load color based on this received cell load information

If the 2G network supports the feature Unified RRM Step 2, the GSM cell load information is received by the RNC in the following messages:

Relocation request / source RNC to target RNC

Relocation command / inter system information transparent container

Relocation preparation failure / inter system information transparent container






6.23.3 iMCTA Service – Inter-Freq Case

FDD Eligible Cells

For each FDD carrierkeep the cell with highest

CPICH_Ec/No + CIO

Filtering on HSxPA capabilitiesfor iMCTA Service

Keep the cellwith highest CPICH_Ec/No + CIO

among lowest load cellsamong highest priority cell

RadioAccessService

FddImcta

hsxpaSegmentationEnable

= True

Filtering onload criteria

FDD Eligible Cells filtering is the same as for iMCTA Alarm or CAC.

Filtering on HSxPA capabilities for iMCTA Service is explained later on in the document.

Filtering on load criteria is explained later on in the document.






6.23.3.1 Inter-Freq Case – Filtering on HSxPA Capabilities


HSxPA cellsonly

HSxPAUE ?

R99 cellsonly

Yes

No

hsxpaSegmentationEnable

Unlike iMCTA Alarm and iMCTA CAC, a new filtering is introduced based on hsxpaSegmentationEnableparameter.

When this parameter is set to True, the algorithm removes all reported cells that are not compatible with UE’s HSxPA capabilities (sent on RRC Connection Setup Complete message):

If UE is NOT HSxPA-capable, all HSxPA-capable cells are removed (either HSDPA or HSUPA)

If UE is HSxPA-capable (either HSDPA or HSUPA), all non HSxPA-capable cells are removed






6.23.3.2 Inter-Freq Case – Filtering on Load Criteria

YES

Target cell is kept

NO

YES

YES

NO i.e. same priority

NO

YES

YES

NO

NO i.e. NOT compatible

YES

NO

Target Cell load Green or ≤ targetCellColourThreshold


Source cell NOT fully compatible

target cell fully or partially compatible

target cell priority better than source cell

YES

target cell’s load smaller than source cell's loadOR

target cell's load =Green


Source cell NOT fully compatible

Target cell is removed

Candidate Target Cells

FDDCell

umtsNeighbouringImcta

targetCellColourThreshold

umtsFddNeighbouringCell

The idea of iMCTA Service is to improve quality of service or to optimize resource usage.

Therefore, all reported neighboring cells whose load is worse than targetCellColourThreshold must be removed. This is applicable whatever Priority of the neighboring cell.

For instance, if targetCellColourThreshold= YELLOW and one DCH color of the neighboring cell is RED, this cell is removed from the candidate list to HHO.

Note: a FDD cell belonging to a neighboring RNC is considered as RED as Serving RNC is not able to determine its load color.

Comparing reported neighbouring cell’s iMCTA colour with targetCellColourThreshold is systematically performed by iMCTA Service, for load balancing purpose but also for traffic segmentation (which is based on UE and NodeB HSxPA capabilities).

If operator’s top priority is to perform traffic segmentation rather than load balancing, targetCellColourThreshold must be set to RED so as to systematically go further in the algorithm, whatever neighbouring cell load.

If isServiceSegmentationTopPriority=True AND originating cell is NOT fully compatible with UE capabilities, remove cells that are NOT compatible with UE capabilities

Fully and partially compatible cells are kept

Flag defined per serviceType

If priority is equal to primary cell,

If cell load is GREEN or better than Primary cell load, keep the cell

Otherwise remove the cell except when

isServiceSegmentationTopPriority=True AND originating cell is NOT fully compatible with UE capabilities

Don’t forget that for that neighbouring cell whose priority is worse than Primary cell’s one have been removed at “Neighbouring Cell Searching and Filtering” stage.






6.23.4 iMCTA Service – Inter-RAT Case

targetCellColourThreshold

GSM Eligible Cells

Keep cells with load <= targetCellColourThreshold

Keep the cellwith highest GSM_RSSI + CIO

among lowest load cells

RNC

GSMCell

2G Cell XColour

inhibitTimer3g2g

GSMNeighbour

GsmImcta

GSM Eligible Cells filtering is the same as for iMCTA Alarm or CAC.

GSM Cell Load must be understood here as a mean to inhibit a HHO to a GSM cell to which a previously attempted HHO has failed in the last inhibitTimer3g2g seconds.

A GSM target cell will have a RED Cell Colour if a handover towards this cell has been rejected for load reasons in the previous inhibitTimer3g2g seconds.

otherwise the Cell Colour is GREEN.

The 2G cell load detection is based on the receipt of the RANAP Relocation Preparation Failure message with a cause IE value equal to “Relocation failure in target CN/RNC or target system”.






6.24 HHO Decision

measurementGuardTimerFdd

measurementGuardTimer2g

time

measurementGuardTimer

iMCTAAlarm

MR MR MR

no candidate cell

2G Blind HHO if provisioned

CM reactivation if Event 2F not received


time


iMCTACAC

MR MR MR

no candidate cell




time


iMCTAService

MR MR MR

no candidate cellmeasurementGuardTimer

RAB Assignment Failure



UE remains on initial FDD carrier Imcta

HHO Decision is taken by the RNC according to the Measurement Reported on neighboring cells

HHO triggered can be Inter-RAT normal or blind, Inter-Freq Intra-RNC or Inter-RNC

The period during which iMCTA Alarm waits for neighbouring reported cells is bounded by 2 different guard timers, so-called measurementGuardTimerFdd and measurementGuardTimer2g, depending on the selected target Access type.

At guard timer expiration, if no neighboring cell is candidate for HHO (no reported cell has been reported or the reported cells have been discarded):

For iMCTA Alarm:

RNC triggers 2G Blind HO if provisioned

otherwise Compressed Mode is reactivated if Event 2F has not been received (iMTCA Alarm only)

For iMCTA CAC

RAB can not be established and RNC sends RANAP RAB Assignment Response (RAB failed list) to CN

For iMCTA Service

UE remains on the initial frequency

measurementGuardTimerFdd and measurementGuardTimer2g replace UA4.2 previous CM timers (gsmCmodeReactivationTimer, fddCmodeReactivationTimer) and HHO timers (blindHhoGsmTimer, blindHhoFddTimer)





6.24 HHO Descision

6.24.1 CM Deactivation / Reactivation

cModeDeltaCfn (CModeConfiguration)

CM period

Duration of pattern sequence If required according to alarm measurements

Measurement criteria is still valid

CFN

CM activation time

Inter-System or inter-Frequency measurements are required

cModeShoDeltaCfn (CModeConfiguration)

or

if

measurementGuardTimer2gmeasurementGuardTimerFdd

(Imcta)

If inter-system/frequency measurement criteria are fulfilled, then the following is applied:Inter-system/frequency measurements are requested from the UE using a RRC Measurement Controlmessage.Compressed Mode is possibly activated using the Measurement Control message, based on UE needs, as indicated in the mobile Classmark. if compressed mode needs to be reactivated, a Compressed Mode Command message is sent to the UE.

cModeDeltaCfn indicates the delay to add to the CFN to determine the activation time of the compressed mode. It allows synchronization of UE and BTS Compressed Mode start.There is no criterion for CM de-activation (CM scheme with a finite length pattern). Meanwhile, CM needs to be re-activated if the inter-system/frequency measurement criteria are still valid. In order to prevent CM from being active forever, the parameters measurementGuardTimer2g andmeasurementGuardTimerFdd are set to a value which shall be greater than the pattern sequence length.

Interaction between CM and SHO: cModeShoDeltaCfn indicates the delay to add to the CFN in order to determine the reception time of the NBAP RL Setup Request at Node B level while the compressed mode is active. It is given in connection frame number of 10 ms.






6.25 Inter-FREQ & Inter-RAT CNL - UA6 RAN Model

RadioAccessService

NeighbouringRNC

RNC

numOfPrimaryCellNeighbourInterFreqnumOfPrimaryCellNeighbourInterRat


NodeB

FDDCell

GsmNeighbouringCell UMTSFddNeighbouringCell

neighbourCellPrio neighbourCellPrio

maxCompoundingListSizeInterFreq [16..32]maxCompoundingListSizeInterRAT [16..32]


numOfPrimaryCellNeighbourInterFreqnumOfPrimaryCellNeighbourInterRat






6.26 Service Based Inter-Freq/Inter-RAT Mobility - RAN Model

RadioAccessService

DedicatedConf

HoConfClass [0..30]

UsHoConf [0..21]

FastAlarmHardHoConf

FullEventHoConfHhoMgt

FullEventHoConfHhoMgtEvent2D

FDDCell MeasConfClass [0..14]

DlUserServiceNeighbouringRNC

mobilityServiceType

timerAlarmHoEvent2D

FullEventHoConfHhoMgtEvent2F

timeToTrigger2Fhysteresis2F

cpichEcNoThresholdUsedFreq2FcpichRscpThresholdUsedFreq2F

timeToTrigger2Dhysteresis2D

cpichEcNoThresholdUsedFreq2DcpichRscpThresholdUsedFreq2D

cpichEcNoThreshold cpichRscpThreshold

counter stepUp

stepDown





Exercise 1: Redirection on HHO Alarm (iMCTA)

Objective: to save the call in case of loss of coverage

Redirect preferably any CS calls to GSM layer if service supported on 2G

Redirect preferably any PS calls to 3G layer

Allow also redirection to 2G/3G layer to avoid call drop

Forbid redirection to GSM if service not supported on 2G

Question: Fill up the Alarm Priority Table below

3G FDD23G FDD1

2GGSM GSM GSM GSM GSM GSM

R99

HSDPA

R99

HSDPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99 R99 R99 R99

PsStreaming

PsIb

CsSpeechPlusOther

2G

FDD

CsSpeech

CsConversational

CsStreaming

Alarm priority Table

Service Type

Access Type





Exercise 2: Redirection on CAC

Objective: to set up the call when RAB establishment fails on 3GEstablish preferably any CS or PS call on 3GAllow also establishment attempt on GSM if service supported on 2GForbid establishment attempt on GSM if service not supported on 2G

Question: Fill up the CAC Priority Table below

3G FDD23G FDD1


R99

HSDPA

R99

HSDPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99 R99 R99 R99

PsStreaming

PsIb

CsSpeechPlusOther

2G

FDD

CsSpeech

CsConversational

CsStreaming

CAC priority Table

Service Type

Access Type





Exercise 3: Redirection after User Service Setup

Objective: Objective: split UE traffic according to their capabilitiesRedirect R99 capable UE calls to R99 layerForbid redirection of R99 capable UE calls to HSxPA layerRedirect R5/R6 UE calls to HSxPA layer for PsIb and CsSpeechPlusOtherService Types onlyRedirect R5/R6 UE calls to R99 layer for all Service Types except PsIb and CsSpeechPlusOtherForbid redirection to GSM

Question: Fill up the Service Priority General Table and the Service Priority For HSDPA Table next page

assume that Service Priority General For HSUPA Table is not configured

3G FDD23G FDD1


R99

HSDPA

R99

HSDPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99 R99 R99 R99





Exercise 3: Redirection after User Service Setup [cont.]

3G FDD23G FDD1


R99

HSDPA

R99

HSDPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99 R99 R99 R99

2G

PsStreaming

PsIb

CsSpeechPlusOther

FDD1

FDD2

CsSpeech

CsConversational

CsStreaming

Service priority General Table

2G

PsStreaming

PsIb

CsSpeechPlusOther

FDD1

FDD2

CsSpeech

CsConversational

CsStreaming

Service priority For HSDPA Table





7 Inter-FDD/Inter-RAT HHO






7.1 3G-2G HHO

SRNC GSM/GPRS BSS

BCCH

Core Network

1 3

FDD Cell GSM Cell

Handover From UTRAN Commandor

Cell Change Order2

activationHoGsmCsAllowedactivationHoGsmPsAllowed

isInterFreqMeasActivationAllowed


isGsmCmodeActivationAllowed

(DlUserService)isPatternAllowed

(CmodePatternSeqInfo)

Thanks to Compress Mode a UE can performed a HHO to 2G with measurements.

CM for 2G neighboring cells measurements is activated when UE is having a CS RAB or a PS RAB on 3G if:

isInterFreqMeasActivationAllowed = True

isGsmCmodeActivationAllowed = True

isPatternAllowed = True

Inter-system HHO can occur following iMCTA Alarm, CAC or Service triggering.

The selection between FDD and 2G Access is part of iMCTA algorithm, mostly based on UE capabilities,priority tables and available neighbouring cells

3G to 2G HHO is possible for a UE:

having a CS service if activationHoGsmCsAllowed must be set to True

having a PS service if activationHoGsmPsAllowed must be set to True






7.2 3G-2G CS Handover Success - Counters

UE Node B RNC CN

Handover from UTRAN Command

BSS

Relocation Command

RL Deletion Reqt

RL Deletion Respe

Relocation Required

Physical information

Measurement Report

Handover Access

Handover CompleteIu Release Command“successful 3G to 2G

relocation”

Iu Release CompleteReleased

…. preparation

execution

VS.3gto2gHoDetectionFromFddcell #164: This measurement provides the number of RRM decisions for a 3G TO 2G handover performed by a RNC, screened by reference cell from which the UEs have left the 3G Network, when these cells are controlled by the considered RNC. This measurement considers both CS and PS handovers.Screening: 0 --> Rescue CS 2 --> Service1 --> Rescue PS 3 --> No resource available (CAC failure)

VS.3gto2gOutHoSuccess #167: This measurement provides the number of successful 3G to 2G outgoing Handovers. It is incremented at the reception of an Iu_Release_Command with cause « Successful 3G to 2G Relocation »Screening: • Sub-Counter #0 : rescue CS • Sub-Counter #1 : rescue PS• Sub-Counter #2 : service CS • Sub-Counter #3 : Service PS• Sub-Counter #4 : No resource available CS (CAC failure) • Sub-Counter #5 : No resource available PS (CAC failure)

VS.IuReleaseCommandCs - #505: This measurement provides the total number of Iu Release Command CS received by the RNC. It is incremented at the reception of an Iu_Release_Command for some cause values.Screening: per Iu Release Command cause0 : Normal end of communication (3GPP RANAP cause 83)2 : UTRAN generated reason (3GPP RANAP cause 15 or Iu_Release_Request sent by RNC)3 : Other cause (all other 3GPP RANAP causes)4 : Relocation Cancelled (3GPP RANAP cause 10)5 : O&M Intervention (3GPP RANAP cause 113)6 : Unspecified Failure (3GPP RANAP cause 115)7 : User Inactivity (3GPP RANAP cause 16)8 : No Remaining RAB (3GPP RANAP cause 31)9 : Successful 3G/3G relocation (3GPP RANAP cause 11)

IRATHO.SuccOutCS - #505 [1]Sub-Counter #1 : Successful relocation






7.3 3G->3G Intra-RNC Inter-freq HHO

SRNC

1P-CPICH

is3Gto3GWithoutIurAllowedforCS is3Gto3GWithoutIurAllowedforPS


FDD Cell F1 FDD Cell F2

Radio Bearer Reconfiguration2

isIrmCacForInterFreqIntraRncEnable


3

Global 3G->3G Inter-frequency HHO are controlled by parameters is3Gto3GWithoutIurAllowedforCS and is3Gto3GWithoutIurAllowedforPS even though naming is not explicit.

isIrmCacForInterFreqIntraRncEnable: allows to play iRM CAC tables on the Target FDD cell before executing HHO (only applicable for Intra-RNC HHO).






7.4 3G->3G Inter-RNC Inter-freq HHO

is3Gto3GWithoutIurAllowedforCS is3Gto3GWithoutIurAllowedforPS


SRNC Target RNC

P-CPICH

Core Network

13

FDD Cell F1 FDD Cell F2

Radio Bearer Reconfiguration2

Inter-RNC HHO are processed in the same way whether there is Iur or not, i.e. through a SNRS Relocationprocedure.






7.5 3G-3G CS/PS HHO – InterRNC

UE Node B RNC 1 CN RNC 2

Relocation Command

Relocation Required

Measurement Report

Relocation Request

Relocation Request Ack

Radio Bearer Reconfiguration

Radio Bearer Reconfiguration Complete

Relocation Detect

Relocation Complete

Iu Release Command

RL Deln Reqt

RL Deln Respe

Iu Release Complete

VS.IuRelocationCompletes - #569Number of relocation completes at Iu interfaceA set of subcounters screened on: Per type of relocation and CN domain

Sub-Counter #0 : 3G-3G CSSub-Counter #1 : 3G-3G PSSub-Counter #2 : 2G-3G CS

#557 VS.IuRelocationCommandsSame screenings as for #556

VS.IuRelocationRequests - #535Number of relocation request at Iu interfaceA set of subcounters screened on: Per type of relocation and CN Domain

Sub-Counter #0 : CS 3G-3G RelocationSub-Counter #1 : PS 3G-3G RelocationSub-Counter #2 : CS 2G-3G RelocationSub-Counter #3 : CS 3G-3G Relocation, UE not involvedSub-Counter #4 : PS 3G-3G Relocation, UE not involved





Module Summary

This lesson covered the following topics:Handover types and purpose

Soft Handovers and associated parameters

Intra-Freq Hard Handovers

Inter-Freq and Inter-RAT Hard Handovers (iMCTA algorithm) and associated parameters

Compress Mode algorithm and parameters













All Rights Reserved © Alcatel-Lucent 20093JK10054AAAAZZZZA Edition 1



Module 13JK10054AAAAZZZZA Edition 1

Section 10Glossary


TMO18044 Edition 3




9300 W-CDMA · UA06 R99 Algorithms DescriptionGlossary10 · 2

Blank Page



2009-02-2901


Document History





Abbreviations and Acronyms

Switch to notes view!# 16-QAM 16 – Quadrature Amplitude Modulation 1xEV-DO 1x EVolution Data Only 1xEV-DV 1x EVolution Data and Voice 1xRTT 1 times 1.25MHz Radio Transmission Technology 3GPP 3rd Generation Partnership Project 3xEV-DV 3x Evolution Data and Voice A AAL2 ATM Adaptation Layer type 2 AAL5 ATM Adaptation Layer type 5 ACK ACKnowledgment AICH Acquisition Indicator CHannel AM Acknowledged Mode AMC Adaptive Modulation and Coding AMD Acknowledged Mode Data AMR Adaptive Multi-Rate ARQ Automatic Repeat Query AS Access Stratum ASC Access Service Class ATM Asynchronous Transfer Mode B BCCH Broadcast Control CHannel BCH Broadcast CHannel BER Bit Error Rate BFN NodeB Frame Number BLER BLock Error Rate BMC Broadcast Multicast Control BPSK Binary Phase Shift Keying BTS Base Transceiver Station C CAC Call Admission Control CC Chase Combining CCCH Common Control CHannel CCP Communication Control Port CCPCH Common Control Physical CHannel CCTrCH Coded Composite Transport CHannel CDMA Code Division Multiple Access CEM Channel Element Module CFN Connection Frame Number CID Channel IDentifier CK Ciphering Key CM Compressed Mode CmCH-PI Common transport CHannel Priority Indicator (SPI) CP NodeB Control Port CP Control Plane CPCH Common Packet CHannel CPICH Common PIlot CHannel CQI Channel Quality Indicator CRC Cyclic Redundancy Check C-RNC Controlling-Radio Network Controller C-RNTI Cell-Radio Network Temporary Identity CS Circuit Switch CTCH Common Traffic CHannel

D DCCH Dedicated Control CHannel DCH Dedicated CHannel DL Downlink DPCCH Dedicated Physical Control CHannel DPCH Dedicated Physical CHannel DPDCH Dedicated Physical Data CHannel D-RNC Drift-Radio Network Controller DS Delay Sensitive DS-CDMA Direct Sequence-Code Division Multiple Access DSCH Downlink Shared CHannel DTCH Dedicated Traffic CHannel DTX Discontinuous Transmission E E1 Standard European PCM link (2.048 Mbps) EDGE Enhanced Data for Global Evolution EGPRS EDGE GPRS F FACH Forward Access CHannel FBI FeedBack Information FDD Frequency Division Duplex FDMA Frequency Division Multiple Access FIFO First In First Out FP Frame Protocol G GMM Global Mobility Management GPRS General Packet Radio Service GSM Global System for Mobile communications GTP GPRS Tunneling Protocol H H-ARQ Hybrid ARQ HFN Hyper Frame Number HO HandOver H-RNTI HS-DSCH Radio Network Temporary Identifier HSDPA High Speed Downlink Packet Access HS-DPCCH High Speed Dedicated Physical Control CHannel HS-DSCH High Speed Downlink Shared CHannel HS-PDSCH High Speed Physical Downlink Shared CHannel HS-SCCH High Speed Shared Control CHannel





Abbreviations and Acronyms [cont.]

Switch to notes view!I IE Information Element IK Integrity Key IMA Inverse Multiplexing ATM IMEI International Mobile Equipment Identity IMSI International Mobile Subscriber Identity IMT-2000 International Mobile Telecommunication for year 2000 IP Internet Protocol IR Incremental Redundancy Iu Interconnection point between RNC and 3G Core Network Iub Interface between Node B and RNC Iur Interface between two RNCs K Kbps Kilobit per second kHz kiloHertz KPI Key Performance Indicator Ksps Kilo symbol per second L L1 Layer 1 (Physical Layer) L2 Layer 2 (Data Link Layer) L3 Layer 3 (Network Layer) LA Location Area LAC Location Area Code LAI Location Area Identity LAN Local Area Network LSB Least Significant Bit M MAC Medium Access Control Mbps Megabit per second MCC Mobile Country Code MCPA Multi Carrier Power Amplifier Mcps Megachip per second MHz MegaHertz MIR Mix Incremental Redundancy MM Mobility Management MNC Mobile Network Code MOC Managed Object Class MOI Managed Object Instance MOS Mean Opinion Score MSB Most Significant Bit N NACK Negative ACKnowledgement NAS Non Access Stratum NBAP Node B Application Part NDI New Data Indicator NDS Non-Delay Sensitive Node B Logical node responsible for radio Tx/Rx to/from UE NRZ Non Return to Zero O

OAM Operation Administration and Maintenance OVSF Orthogonal Variable Spreading Factor P PA Power Amplifier PCCH Paging Control CHannel P-CCPCH Primary-Common Control Physical CHannel PCH Paging CHannel PCM Pulse Code Modulation PCPCH Physical Common Control CHannel PDP Packet Data Protocol PDU Protocol Data Unit PI Paging Indicator PI Priority Indicator PICH Paging Indicator CHannel PIR Partial Incremental Redundancy PLMN Public Land Mobile Network PMM Packet Mobility Management PN Pseudo Noise PQ Priority Queue PRACH Physical Random Access CHannel PS Packet Switch P-SCH Primary-Synchronization CHannel PSK Phase Shift Keying Q QId Queue Identity QoS Quality of Service QPSK Quadrature Phase Shift Keying R R4 Release 4 R5 Release 5 R6 Release 6 RA Routing Area RAB Radio Access Bearer RAC Routing Area Code RACH Random Access CHannel RAN Radio Access Network RANAP Radio Access Network Application Part RB Radio Bearer RF Radio Frequency RL Radio Link RLC Radio Link Control RM Rate Matching RNC Radio Network Controller RNS Radio network subsystem





Abbreviations and Acronyms [cont.]

Switch to notes view!RNSAP Radio Network Subsystem Application Part RNTI Radio Network Temporary Identity RRC Radio Resource Control RRM Radio Resource Management RTT Radio Transmission Technology RV Redundancy Version RX Receiver / Reception S SA Service Area SAP Service Access Point SAW Stop And Wait S-CCPCH Secondary-Common Control Physical CHannel SCH Synchronization CHannel SCR Sustainable Cell Rate SDU Service Data Unit SF Spreading Factor SFN System Frame Number SHO Soft HandOver SIM Subscriber Identity Module SIR Signal to Interference Ratio SM Session Management SNR Signal to Noise Ratio SPI Scheduling Priority Indicator (CmCH- PI) SRLR Synchronous Radio Link Reconfiguration S-RNC Serving-Radio Network Controller S-SCH Secondary-Synchronization CHannel STTD Space Time Transmit Diversity T TAF That's All Folks! TB Transport Block TBS Transport Block Size TCP Transmission Control Protocol TDD Time Division Duplex TDM Time Division Multiplexing TDMA Time Division Multiple Access TF Transport Format TFC Transport Format Combination TFCI Transport Format Combination Indicator TFI Transport Format Indicator TFO Tandem Free Operation TFRC Transport Format and Resource Combination TFRI Transport Format and Resource Indicator TFS Transport Format Set TPC Transmit Power Control TrCH Transport CHannel TrFO Transcoder Free Operation TS Time Slot TTI Transmission Time Interval TX Transmitter / Transmission U

UARFCN UMTS Absolute Radio Frequency Channel Number UDP User Datagram Protocol UE User Equipment UM Unacknowledged Mode UMTS Universal Mobile Telecommunication System UP User Plane URA UTRAN Registration Area U-RNTI UTRAN-Radio Network Temporary Identity UTRAN Universal Terrestrial Radio Access Network Uu the radio interface between UTRAN and UE V VCC Virtual Channel Connection VoIP Voice over IP W W-CDMA Wideband-CDMA






@@COURSENAME - Page 1All Rights Reserved © Alcatel-Lucent @@YEAR

All Rights Reserved © Alcatel-Lucent @@YEAR

@@COURSENAME@@PRODUCT1

Last But One Page



@@COURSENAME - Page 2All Rights Reserved © Alcatel-Lucent @@YEAR

All rights reserved © Alcatel-Lucent @@YEARPassing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent

algorithms

Documents

rights reserved

p3 p2 p1

left blank

ecnobestaset

ink colo radio

sdu buffer

cem boards

neighbouringfddcellid