Handover Control

WCDMA RAN RRM Handover Control

DN03471612

Issue 10FApproval Date 2010-11-16

Confidential

2 DN03471612Issue 10F


Id:0900d8058087c8a8Confidential

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2010. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit Von diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal, Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-satzes.

DN03471612 3



Table of contentsThis document has 347 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1 Handover control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.1 Handover types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2 Neighbor cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3 Hierarchical cell structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4 Features related to handover control . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.4.1 IMSI-Based handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.4.2 Load- and service-based IF/IS handover. . . . . . . . . . . . . . . . . . . . . . . . 211.4.3 HSDPA (high speed downlink packet access). . . . . . . . . . . . . . . . . . . . 221.4.4 HSDPA inter-frequency handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.4.5 Inter-frequency handover over Iur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.4.6 The HSPA inter-RNC cell change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.4.7 HSUPA (high speed uplink packet access) . . . . . . . . . . . . . . . . . . . . . . 241.4.8 Soft handover based on detected set reporting . . . . . . . . . . . . . . . . . . . 251.4.9 Inter-system handover cancellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.4.10 UTRAN - GAN interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.4.11 Directed retry of an AMR call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.4.12 HSPA capability based handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.4.13 Power balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.4.14 Multi-Operator core network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.4.15 Support for I-HSPA sharing and Iur mobility enhancements . . . . . . . . . 281.4.16 Support for F-DPCH and SRB's on HSPA. . . . . . . . . . . . . . . . . . . . . . . 291.4.17 Forced Hard Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.4.18 Support for HSPA over Iur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.4.19 Dual Cell HSDPA 42 Mbps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.4.20 Support for Multiple input Multiple output (MIMO) . . . . . . . . . . . . . . . . . 311.4.21 LTE interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.4.22 Blind inter-frequency handover in RAB setup phase . . . . . . . . . . . . . . . 31

2 Types of handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.1 Introduction to soft handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2 Introduction to intra-frequency hard handover . . . . . . . . . . . . . . . . . . . . 332.3 Introduction to inter-frequency handover . . . . . . . . . . . . . . . . . . . . . . . . 342.4 Introduction to inter-system handover . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5 Introduction to IMSI-based handover. . . . . . . . . . . . . . . . . . . . . . . . . . . 362.5.1 Purpose of IMSI-based handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.5.2 Functional restrictions on IMSI-based handover . . . . . . . . . . . . . . . . . . 392.6 Introduction to load- and service-based IF/IS handover . . . . . . . . . . . . 392.7 Introduction to directed retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3 Compressed mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1 Halving the spreading factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2 Higher layer scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3 Synchronization of compressed mode gaps . . . . . . . . . . . . . . . . . . . . . 483.4 Compressed mode for HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 DN03471612



3.5 Restrictions because of cell capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4 Macro diversity combining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5 WCDMA frequency bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6 Directed RRC connection setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7 Directed RRC connection setup for HSDPA layer . . . . . . . . . . . . . . . . . 687.1 Decision of layer change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707.2 HSDPA load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.3 Layer selection examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.4 Fractional Dedicated Physical Channel . . . . . . . . . . . . . . . . . . . . . . . . . 747.5 Dual Cell HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.6 Interaction with directed RRC connection setup . . . . . . . . . . . . . . . . . . . 76

8 HSPA layering for UEs in common channels . . . . . . . . . . . . . . . . . . . . . 778.1 Decision of layer change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.2 HSDPA load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

9 Power balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829.1 Activation of power balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859.2 Deactivation of power balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879.3 The DL power control request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879.4 Usage of the power balancing adjustment Type in the BTS and the DRNC

889.5 Updating the reference transmission power during the soft handover . . 889.6 Sending the new reference transmission power to the BTS . . . . . . . . . . 899.7 Power balancing algorithm in the BTS . . . . . . . . . . . . . . . . . . . . . . . . . . 909.8 Reliability check for DL TPC commands during soft handover. . . . . . . . 92

10 Functionality of intra-frequency handover. . . . . . . . . . . . . . . . . . . . . . . . 9410.1 Functionality of soft handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9410.1.1 Reporting event 1A for adding cells to the active set . . . . . . . . . . . . . . . 9510.1.2 Reporting event 1B for deleting cells from the active set . . . . . . . . . . . . 9610.1.3 Reporting event 1C for replacing cells in the active set . . . . . . . . . . . . . 9710.1.4 Event-triggered periodic intra-frequency measurement reporting. . . . . . 9910.1.5 Time-to-trigger mechanism for modifying measurement reporting behav-

iour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10010.1.6 Identification of an intra-frequency cell . . . . . . . . . . . . . . . . . . . . . . . . . 10110.1.7 Soft handover based on detected set reporting . . . . . . . . . . . . . . . . . . 10210.1.8 Cell individual offsets for modifying measurement reporting behaviour 10310.1.9 Mechanism for forbidding a cell to affect the reporting range . . . . . . . . 10410.1.10 Reporting events 6F and 6G for deleting cells from the active set . . . . 10510.1.11 Function in abnormal conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10510.2 Functionality of intra-frequency hard handover. . . . . . . . . . . . . . . . . . . 10810.2.1 Time interval between hard handover attempts . . . . . . . . . . . . . . . . . . 109

11 Functionality of inter-frequency handover. . . . . . . . . . . . . . . . . . . . . . . 11011.1 Coverage reason inter-frequency handover . . . . . . . . . . . . . . . . . . . . . 11011.1.1 Inter-frequency handover because of uplink DCH quality. . . . . . . . . . . 11111.1.2 Inter-frequency handover because of UE transmission power . . . . . . . 111

DN03471612 5



11.1.3 Inter-frequency handover because of CPICH RSCP. . . . . . . . . . . . . . 11311.1.4 Handover decision procedure for coverage reason inter-frequency han-

dover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11411.2 Quality reason inter-frequency handover. . . . . . . . . . . . . . . . . . . . . . . 11411.2.1 Inter-frequency handover because of downlink DPCH power . . . . . . . 11511.2.2 Inter-frequency handover because of CPICH Ec/No . . . . . . . . . . . . . . 11611.2.3 Handover decision procedure for quality reason inter-frequency handover

11711.3 HSDPA inter-frequency handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11811.4 Interactions between handover causes . . . . . . . . . . . . . . . . . . . . . . . . 12111.5 Interaction with handover to GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12111.6 Interaction with handover to GAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12211.7 Control parameters of inter-frequency handover . . . . . . . . . . . . . . . . . 12211.8 Measurement procedure for inter-frequency handover . . . . . . . . . . . . 12311.9 Function in abnormal conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

12 Functionality of inter-frequency handover over Iur. . . . . . . . . . . . . . . . 12612.1 Neighbor cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12612.2 Handover control parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12712.3 Inter-Frequency measurement and handover decision during anchoring .

12812.4 Bit rate of NRT DCHs during anchoring. . . . . . . . . . . . . . . . . . . . . . . . 13012.5 Inter-Frequency handover from SRNC to DRNC over Iur without existing

RL in the target DRNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13012.6 Inter-frequency handover from the SRNC to the DRNC over Iur with an ex-

isting RL in the target DRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13312.7 Inter-Frequency handover during anchoring with an existing RL in the tar-

get DRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13612.8 Inter-Frequency handover during anchoring with no existing RL in target

DRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13912.9 Inter-Frequency handover from anchoring back to SRNC. . . . . . . . . . 141

13 Functionality of inter-system handover . . . . . . . . . . . . . . . . . . . . . . . . 14413.1 Coverage reason inter-system handover. . . . . . . . . . . . . . . . . . . . . . . 14513.1.1 Inter-System handover because of uplink DCH quality . . . . . . . . . . . . 14513.1.2 Inter-System handover because of UE transmission power . . . . . . . . 14613.1.3 Inter-System handover because of CPICH RSCP. . . . . . . . . . . . . . . . 14813.1.4 Inter-System handover because of downlink DPCH power . . . . . . . . . 14913.1.5 Inter-System handover because of CPICH Ec/No . . . . . . . . . . . . . . . . 15013.1.6 Inter-System handover because of failed RAB setup . . . . . . . . . . . . . 15113.1.7 Handover decision procedure for inter-system handover . . . . . . . . . . 15213.2 Interactions between handover causes . . . . . . . . . . . . . . . . . . . . . . . . 15313.3 Interaction with inter-frequency handover . . . . . . . . . . . . . . . . . . . . . . 15313.4 Interaction with handover to GAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15413.5 Measurement control parameters of inter-system handover . . . . . . . . 15413.6 Measurement procedure for inter-system handover . . . . . . . . . . . . . . 15513.7 BSIC identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15613.8 Inter-System handover cancellation. . . . . . . . . . . . . . . . . . . . . . . . . . . 15713.9 Function in abnormal conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

6 DN03471612



14 Functionality of forced hard handover. . . . . . . . . . . . . . . . . . . . . . . . . . 16314.1 CPICH power ramp-down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16314.2 BTS type and version verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16314.3 Start of forced handover procedure for remaining UE . . . . . . . . . . . . . 16314.4 Ongoing handovers when gradual power ramp-down is completed . . . 16314.5 Measurements of serving cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16414.6 Handover type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16414.7 Inter-frequency measurement for inter-frequency handover. . . . . . . . . 16514.8 Determining forced inter-frequency handover target cells . . . . . . . . . . 16514.9 Reporting forced inter-frequency hard handover . . . . . . . . . . . . . . . . . 16614.10 Reporting forced inter-system hard handover. . . . . . . . . . . . . . . . . . . . 166

15 Functionality of inter-system handover during anchoring . . . . . . . . . . . 16715.1 Reporting of the inter-RAT neighbour cell information from the DRNC to the

SRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16715.2 Handover control parameter sets during anchoring . . . . . . . . . . . . . . . 16715.3 Inter-RAT measurements and handover decision during anchoring. . . 168

16 Functionality of IMSI-based handover . . . . . . . . . . . . . . . . . . . . . . . . . 16916.1 Configuration of IMSI-based handover . . . . . . . . . . . . . . . . . . . . . . . . . 16916.2 IMSI-based intra-frequency handover. . . . . . . . . . . . . . . . . . . . . . . . . . 17016.3 IMSI-based inter-frequency handover. . . . . . . . . . . . . . . . . . . . . . . . . . 17116.4 IMSI-based inter-system handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

17 Functionality of immediate IMSI-based handover. . . . . . . . . . . . . . . . . 17217.1 Immediate IMSI-based inter-frequency handover. . . . . . . . . . . . . . . . . 17217.2 Immediate IMSI-based inter-system handover . . . . . . . . . . . . . . . . . . . 173

18 Functionality of load-based and service-based IF/IS handover . . . . . . 17418.1 Load-based handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17418.1.1 Total interference load of the cell exceeds a predefined threshold. . . . 17418.1.2 Rejection rate of PS NRT traffic capacity requests exceeds a predefined

threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17718.1.3 Downlink spreading codes are lacking in the cell . . . . . . . . . . . . . . . . . 17818.1.4 HW or logical resources are limited in the cell . . . . . . . . . . . . . . . . . . . 17818.1.5 Processing of measurement results indicating load . . . . . . . . . . . . . . . 17918.1.6 Number of UEs simultaneously in the load-based handover procedure18218.1.7 Selection of RRC connections for the load-based handover procedure18218.2 Service-based handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18418.2.1 Number of RRC connections simultaneously in the service-based han-

dover procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18418.2.2 Selecting RRC connections for the service-based handover procedure . .

18418.2.3 Defining the target for the service-based handover . . . . . . . . . . . . . . . 18518.3 Service priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18518.3.1 Iu interface service priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18518.3.2 RNC-based service priority handover profile table . . . . . . . . . . . . . . . . 18618.3.3 Combined service priority list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18718.3.4 Multi services in case of service-based and load-based handovers. . . 18918.3.5 Availability of the target WCDMA layers and GSM system. . . . . . . . . . 190

DN03471612 7



18.4 Load of the target cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19118.4.1 Common load measurement over Iur . . . . . . . . . . . . . . . . . . . . . . . . . 19118.4.2 Load of the target WCDMA cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19118.4.3 Load of the target GSM/GPRS cell . . . . . . . . . . . . . . . . . . . . . . . . . . . 19218.4.4 Congested target WCDMA or GSM cell. . . . . . . . . . . . . . . . . . . . . . . . 19218.5 Interaction with HSPA capability based handover . . . . . . . . . . . . . . . . 19218.6 Inter-frequency and inter-RAT measurement procedures . . . . . . . . . . 19318.6.1 Selecting the service and load-based inter-frequency handover method .

19318.6.2 Selecting the service and load-based inter-RAT handover method. . . 19318.6.3 Measurement parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19418.6.4 Inter-frequency and inter-RAT neighbor cell lists. . . . . . . . . . . . . . . . . 19418.6.5 Number of UEs in compressed mode . . . . . . . . . . . . . . . . . . . . . . . . . 19518.7 Handover decision procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19518.7.1 Load- and service-based inter-frequency handover . . . . . . . . . . . . . . 19518.7.2 Load- and service-based inter-RAT handover . . . . . . . . . . . . . . . . . . . 19618.8 Handover signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19718.8.1 Load- and service-based inter-frequency handover . . . . . . . . . . . . . . 19718.8.2 Load- and service-based inter-RAT handover and cell change. . . . . . 19718.8.3 Service downgrading and upgrading because of inter-RAT handover 19718.8.4 Restriction on repetitive load- and service-based handover attempts . 197

19 Functionality of HSPA capability based handover . . . . . . . . . . . . . . . . 19919.1 Periodic HSPA capability based handover . . . . . . . . . . . . . . . . . . . . . 20019.2 Event triggered HSPA capability based handover. . . . . . . . . . . . . . . . 20119.3 Inter-Frequency measurement procedures . . . . . . . . . . . . . . . . . . . . . 20219.4 Inter-Frequency neighbor cell lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20219.5 Handover decision algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20319.6 Execution of HSPA capability based handover . . . . . . . . . . . . . . . . . . 20319.6.1 Handover to an I-HSPA cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20419.6.2 Handover to a WCDMA cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20419.7 Abnormal conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

20 Functionality of Dual Cell HSDPA capability based handover . . . . . . . 20520.1 Periodic Dual Cell HSDPA capability based handover . . . . . . . . . . . . 20520.2 Event trigerred Dual Cell HSDPA capability based handover . . . . . . . 20720.3 Measurement procedures and execution of Dual Cell HSDPA capability

based handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20720.4 Handover decision algorithm of Dual Cell HSDPA capability based han-

dover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

21 Functionality of MIMO capability based handover . . . . . . . . . . . . . . . . 20921.1 Periodic MIMO capability based handover . . . . . . . . . . . . . . . . . . . . . 21021.2 Event trigerred MIMO capability based handover . . . . . . . . . . . . . . . . 21121.3 Measurement procedures and execution of MIMO capability based han-

dover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

22 Functionality of LTE interworking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

23 Functionality of Blind inter-frequency handover in RAB setup phase . 21523.1 Source cell measurements for blind HO in RAB setup . . . . . . . . . . . . 215

8 DN03471612



23.2 RNC decision algorithm for blind handover in RAB setup . . . . . . . . . . 21523.3 Multi RAB cases in blind handover in RAB setup phase . . . . . . . . . . . 21723.4 Decision for blind handover in RAB setup phase based on capability, ser-

vice, load and low/high RSCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21723.4.1 Preference score calculation in decision making . . . . . . . . . . . . . . . . . 21723.4.2 Correct parameter choice from preferred layer definitions . . . . . . . . . . 21823.5 Functionality of the blind inter-frequency handover in RAB setup phase in-

terworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

24 Delay in block resource procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22024.1 Handover procedures in CPICH power ramp-down in block resource nor-

mal priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22024.2 Handover re-attempt during CPICH power ramp-down in block resource

normal priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22024.3 Reporting forced handover in block resource request . . . . . . . . . . . . . 221

25 UTRAN - GAN interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22225.1 UE capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22225.2 GAN-Specific handover trigger event 3A . . . . . . . . . . . . . . . . . . . . . . . 22225.3 GAN handover decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22325.3.1 Identification of the GAN target cell . . . . . . . . . . . . . . . . . . . . . . . . . . . 22325.3.2 Handover from UTRAN to GAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22425.3.3 Unsuccessful handover attempt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22525.3.4 Handover from GAN to UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

26 Description of SRNS relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

27 Soft handover signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

28 Intra-Frequency hard handover signalling . . . . . . . . . . . . . . . . . . . . . . 234

29 Serving RNC relocation signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

30 Compressed mode preparation signaling . . . . . . . . . . . . . . . . . . . . . . . 237

31 Inter-Frequency handover signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

32 Inter-System handover signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

33 Handover control restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

34 Features per release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

35 Management data for handover control . . . . . . . . . . . . . . . . . . . . . . . . 25335.1 Alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25335.1.1 RAN1266: Soft handover based on detected set reporting . . . . . . . . . 25335.2 Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25435.2.1 RAN1.024: Soft handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25635.2.2 RAN1.5010: Inter-frequency handover . . . . . . . . . . . . . . . . . . . . . . . . . 25835.2.3 RAN2.0105: Inter-RNC intra-frequency hard handover . . . . . . . . . . . . 27735.2.4 RAN1.5009: WCDMA - GSM inter-system handover . . . . . . . . . . . . . . 27835.2.5 RAN1.5008: GSM - WCDMA inter-system handover . . . . . . . . . . . . . . 28935.2.6 RAN1183: UTRAN - GAN interworking. . . . . . . . . . . . . . . . . . . . . . . . . 28935.2.7 RAN2.0060: IMSI based handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28935.2.8 RAN140: Load and service based IS/IF handover . . . . . . . . . . . . . . . . 290

DN03471612 9



35.2.9 RAN1275: Inter-system handover cancellation . . . . . . . . . . . . . . . . . . 30335.2.10 RAN1191: Detected set reporting and measurements . . . . . . . . . . . . 30435.2.11 RAN1515: HSPA inter-RNC cell change . . . . . . . . . . . . . . . . . . . . . . . 30435.2.12 RAN1276: HSDPA inter-frequency handover . . . . . . . . . . . . . . . . . . . 30535.2.13 RAN1596: HSPA capability based handover. . . . . . . . . . . . . . . . . . . . 30635.2.14 RAN1011: HSPA layering for UEs in common channels . . . . . . . . . . . 30735.2.15 RAN146: Power Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30735.2.16 RAN955: Power Saving Mode for BTS . . . . . . . . . . . . . . . . . . . . . . . . 30835.2.17 RAN1201: Support for Fractional DPCH . . . . . . . . . . . . . . . . . . . . . . . 30935.2.18 RAN1231: Support for HSPA over Iur . . . . . . . . . . . . . . . . . . . . . . . . . 30935.2.19 RAN2047: LTE interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31035.2.20 RAN1758: Multiple BSIC Identification . . . . . . . . . . . . . . . . . . . . . . . . 31035.2.21 RAN2289: Blind IFHO in RAB Setup Phase . . . . . . . . . . . . . . . . . . . . 31035.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31235.3.1 RAN2.0079: Directed RRC connection setup . . . . . . . . . . . . . . . . . . . 31235.3.2 RAN1266: Soft handover based on detected set reporting . . . . . . . . . 31235.3.3 RAN1.024: Soft handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31335.3.4 RAN1.5009: WCDMA - GSM inter-system handover . . . . . . . . . . . . . 31735.3.5 RAN1183: UTRAN - GAN interworking . . . . . . . . . . . . . . . . . . . . . . . . 32135.3.6 RAN2.0060: IMSI based handover . . . . . . . . . . . . . . . . . . . . . . . . . . . 32135.3.7 RAN140: Load and service based IS/IF handover. . . . . . . . . . . . . . . . 32335.3.8 RAN1275: Inter-system handover cancellation . . . . . . . . . . . . . . . . . . 32735.3.9 RAN1191: Detected set reporting and measurements . . . . . . . . . . . . 32735.3.10 RAN1515: HSPA inter-RNC cell change . . . . . . . . . . . . . . . . . . . . . . . 32835.3.11 RAN1276: HSDPA inter-frequency handover . . . . . . . . . . . . . . . . . . . 32835.3.12 RAN1596: HSPA Capability based Handover . . . . . . . . . . . . . . . . . . . 32935.3.13 RAN146: Power Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32935.3.14 RAN1824: Inter-frequency Handover over Iur . . . . . . . . . . . . . . . . . . . 33035.3.15 RAN966: Multi-Operator Core Network . . . . . . . . . . . . . . . . . . . . . . . . 33035.3.16 RAN1.029: Packet scheduler algorithm . . . . . . . . . . . . . . . . . . . . . . . . 33035.3.17 RAN1011: HSPA layering for UEs in common channels . . . . . . . . . . . 33235.3.18 Handover control basic functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 33235.3.19 HSDPA basic functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33335.3.20 RAN 964: Directed RRC Connection Setup for HSDPA Layer . . . . . . 33335.3.21 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements. .

33435.3.22 RAN955: Power Saving Mode for BTS . . . . . . . . . . . . . . . . . . . . . . . . 33635.3.23 RAN1201: Support for Fractional DPCH . . . . . . . . . . . . . . . . . . . . . . . 33735.3.24 RAN1231: Support for HSPA over Iur . . . . . . . . . . . . . . . . . . . . . . . . . 34035.3.25 RAN1642: MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34035.3.26 RAN1906: Dual-Cell HSDPA 42 Mbps . . . . . . . . . . . . . . . . . . . . . . . . 34035.3.27 RAN1758: Multiple BSIC Identification . . . . . . . . . . . . . . . . . . . . . . . . 34135.3.28 RAN2289: Blind IFHO in RAB Setup Phase . . . . . . . . . . . . . . . . . . . . 341

Related information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

10 DN03471612



List of figuresFigure 1 IMSI definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 2 Load of the source cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Figure 3 UTRAN - GAN interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figure 4 Power drifting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 5 IMSI definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figure 6 IMSI-based handover in geographical sharing concept . . . . . . . . . . . . . 37Figure 7 IMSI-based handover in common shared RAN concept. . . . . . . . . . . . . 38Figure 8 IMSI-based handover in mobile virtual network operator concept . . . . . 39Figure 9 Load of the source cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Figure 10 Example of transmission gaps created with compressed mode . . . . . . . 43Figure 11 Halving the spreading factor (single frame method) . . . . . . . . . . . . . . . . 45Figure 12 Higher layer scheduling (double frame method) . . . . . . . . . . . . . . . . . . . 46Figure 13 Selection of the higher layer scheduling mode . . . . . . . . . . . . . . . . . . . . 47Figure 14 Macro diversity combining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figure 15 Handover scenario: branch addition rejected . . . . . . . . . . . . . . . . . . . . . 56Figure 16 Definition of uplink DCH own-cell load threshold LDRRC . . . . . . . . . . . . . 64Figure 17 Principle of directed RRC connection setup . . . . . . . . . . . . . . . . . . . . . . 67Figure 18 Principles of directed RRC connection setup for HSDPA layer . . . . . . . 68Figure 19 Signaling of directed RRC connection setup for HSDPA layer . . . . . . . . 69Figure 20 Calculation of HSDPA power per user . . . . . . . . . . . . . . . . . . . . . . . . . . 71Figure 21 Calculation of NRT HSDPA cell weight per user . . . . . . . . . . . . . . . . . . 72Figure 22 Example of layer selection in RRC connection setup phase in non-HSDPA

layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figure 23 Example of layer selection in RRC connection setup phase in HSDPA layer

74Figure 24 signaling of HSPA layering for UEs in common channels . . . . . . . . . . . 78Figure 25 Power drifting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Figure 26 Functional split of the power balancing functionality. . . . . . . . . . . . . . . . 83Figure 27 Ideal power control without power balancing . . . . . . . . . . . . . . . . . . . . . 83Figure 28 Real situation with misinterpreted PC commands . . . . . . . . . . . . . . . . . 84Figure 29 Power balancing in work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Figure 30 Message sequence chart for power balancing . . . . . . . . . . . . . . . . . . . . 86Figure 31 Updating of the power balancing reference power for three soft handover

branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Figure 32 Power balancing algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Figure 33 Formula for calculating the UE measurement report on event 1A . . . . . 95Figure 34 Formula for calculating the UE measurement report on event 1B . . . . . 96Figure 35 Formula for calculating the UE measurement report on event 1C . . . . . 97Figure 36 A cell that is not in the active set becomes better than a cell in a full active

set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Figure 37 Formula for calculating the UE measurement report on event 1C . . . . . 99Figure 38 Periodic reporting triggered by event 1A. . . . . . . . . . . . . . . . . . . . . . . . 100Figure 39 Time-to-trigger limits the number of measurement reports . . . . . . . . . . 101Figure 40 A positive offset is applied to cell 3 before event evaluation in the UE. 103Figure 41 Cell 3 is forbidden to affect the reporting range . . . . . . . . . . . . . . . . . . 105Figure 42 Conditions for inter-frequency handover because of coverage reasons. . .

DN03471612 11



114Figure 43 Measured downlink code power calculation. . . . . . . . . . . . . . . . . . . . . 115Figure 44 Measurement results of the inter-frequency neighboring cell calculation. .

117Figure 45 Measuring procedure for inter-frequency handover. . . . . . . . . . . . . . . 124Figure 46 Time interval calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Figure 47 Inter-Frequency handover from SRNC to DRNC over Iur, no existing RL in

target DRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Figure 48 Inter-Frequency handover from SRNC to DRNC over Iur with an existing

RL in the target DRNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Figure 49 Inter-frequency handover during anchoring with an existing RL in the target

DRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Figure 50 Inter-Frequency handover during anchoring with no existing RL in the tar-

get DRNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Figure 51 Inter-Frequency handover from anchoring back to the SRNC. . . . . . . 142Figure 52 Measuring procedure for inter-system handover . . . . . . . . . . . . . . . . . 156Figure 53 Handover decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Figure 54 An example of selecting the authorised network list . . . . . . . . . . . . . . 169Figure 55 Definition of uplink DCH own cell load threshold LLHO . . . . . . . . . . . . . 174Figure 56 Calculation of LHOratioPtx in case of there is no HSDPA users in the cell.

176Figure 57 Calculation of LHOratioPtx in case of there is no HSDPA users in the cell.

176Figure 58 Calculation of LHOratioPtx in case there is at least one HSDPA user in the

cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Figure 59 LHOratioPtx condition for triggering load based handover procedure. 177Figure 60 Measurement procedure for all four load triggers . . . . . . . . . . . . . . . . 180Figure 61 Inter-RAT handover from E-UTRAN to UTRAN. . . . . . . . . . . . . . . . . . 213Figure 62 Inter-RAT handover from UTRAN to GAN. . . . . . . . . . . . . . . . . . . . . . 224Figure 63 Inter-RAT handover from GAN to UTRAN. . . . . . . . . . . . . . . . . . . . . . 226Figure 64 Branch addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Figure 65 Branch deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Figure 66 Branch replacement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Figure 67 Intra-Frequency hard handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Figure 68 SRNC relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Figure 69 Compressed mode preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Figure 70 Intra-RNC inter-frequency handover because of UE transmission power

(continued in the next picture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Figure 71 Intra-RNC inter-frequency handover because of UE transmission power

(continued from the previous picture) . . . . . . . . . . . . . . . . . . . . . . . . . 240Figure 72 MSC controlled inter-RNC inter-frequency handover because of CPICH

EcNo (quality reason), source RNC (continued in the next picture) . . 241Figure 73 MSC controlled inter-RNC inter-frequency handover because of CPICH

EcNo (quality reason), source RNC (continued from the previous picture)242

Figure 74 SGSN controlled inter-RNC inter-frequency handover because of UE transmission power (coverage reason), source RNC (continued in the next picture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Figure 75 SGSN controlled inter-RNC inter-frequency handover because of UE

12 DN03471612



transmission power (coverage reason), source RNC (continued from the previous picture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Figure 76 Inter-System handover from WCDMA to GSM (continued in the next pic-ture). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Figure 77 Inter-System handover from WCDMA to GSM (continued from the previous picture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Figure 78 Inter-System cell change from WCDMA to GSM/GPRS (continued in the next picture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Figure 79 Inter-System cell change from WCDMA to GSM/GPRS (continued from the previous picture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Figure 80 Inter-System handover from WCDMA to GSM with CS and PS multi servic-es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Figure 81 Inter-System hard handover from GSM to WCDMA . . . . . . . . . . . . . . . 250

DN03471612 13



List of tablesTable 1 Handover types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Table 2 Handover types according to shifts between the BTSs and RNCs . . . . 18Table 3 Use of load- and service-based handovers according to the service type

42Table 4 UTRA absolute radio frequency channel numbers defined by 3GPP . . 59Table 5 Allowed channel numbers of US WCDMA 1900 in band II . . . . . . . . . . 60Table 6 UARFCN definition (general) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Table 7 UARFCN definition (additional channels) . . . . . . . . . . . . . . . . . . . . . . . 61Table 8 Triggers of DRRC and checkings in the target cell . . . . . . . . . . . . . . . . 66Table 9 Variables for measurement report on event 1A . . . . . . . . . . . . . . . . . . 95Table 10 Variables for measurement report on event 1B . . . . . . . . . . . . . . . . . . 96Table 11 Variables for measurement report on event 1C . . . . . . . . . . . . . . . . . . 98Table 12 Criteria for enabling the RRC connection release . . . . . . . . . . . . . . . . 107Table 13 Measurement result criteria for intra-frequency hard handover . . . . . 109Table 14 Variables for inter-frequency handover . . . . . . . . . . . . . . . . . . . . . . . . 115Table 15 Variables for inter-system handover . . . . . . . . . . . . . . . . . . . . . . . . . . 149Table 16 Variables for inter-system handover cancellation . . . . . . . . . . . . . . . . 159Table 17 RNC-based service priority handover profile table . . . . . . . . . . . . . . . 186Table 18 Combination of service priority information . . . . . . . . . . . . . . . . . . . . . 188Table 19 Counters for soft handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Table 20 Service level measurements for inter-frequency handovers . . . . . . . . 258Table 21 Traffic measurements for inter-frequency handovers . . . . . . . . . . . . . 259Table 22 Intra system hard handover measurements for inter-frequency handovers

259Table 23 L3 relocation signaling measurements for inter-frequency handovers 269Table 24 Inter-RNC intra-frequency hard handover counters . . . . . . . . . . . . . . 277Table 25 Service level measurements for WCDMA - GSM inter-system handovers

278Table 26 Traffic measurements for WCDMA - GSM inter-system handovers . . 278Table 27 RRC signaling measurements for WCDMA - GSM inter-system handovers

280Table 28 L3 Relocation signaling measurements for WCDMA - GSM inter-system

handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Table 29 Inter system hard handover measurements for WCDMA - GSM inter-sys-

tem handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Table 30 GSM - WCDMA Inter-system handover counters . . . . . . . . . . . . . . . . 289Table 31 UTRAN - GAN interworking counters . . . . . . . . . . . . . . . . . . . . . . . . . 289Table 32 IMSI based handover counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Table 33 L3 signaling at Iur measurements for load and service Based IS/IF

handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290Table 34 RRC signaling measurements for load and service based IS/IF handovers

291Table 35 Intra system hard handover measurements for load and service based

IS/IF handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Table 36 Inter system hard handover measurements for load and service based

IS/IF handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Table 37 Inter-system handover cancellation . . . . . . . . . . . . . . . . . . . . . . . . . . 303

14 DN03471612



Table 38 RAN1191: Detected set reporting and measurements . . . . . . . . . . . . 304Table 39 HSPA inter-RNC cell change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Table 40 HSDPA inter-frequency handover measurement counters . . . . . . . . . 305Table 41 HSPA capability based handover counters . . . . . . . . . . . . . . . . . . . . . 306Table 42 HSPA layering for UEs in common channels counters . . . . . . . . . . . . 307Table 43 RAN146: Power Balancing counters . . . . . . . . . . . . . . . . . . . . . . . . . . 307Table 44 RAN955: Power Saving Mode for BTS counters . . . . . . . . . . . . . . . . . 308Table 45 RAN1201: Support for Fractional DPCH counters . . . . . . . . . . . . . . . . 309Table 46 RAN1231: Support for HSPA over Iur . . . . . . . . . . . . . . . . . . . . . . . . . 309Table 47 RAN2047: LTE interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310Table 48 RAN1758: Multiple BSIC Identification . . . . . . . . . . . . . . . . . . . . . . . . 310Table 49 RAN2289: Blind IFHO in RAB Setup Phase . . . . . . . . . . . . . . . . . . . . 310Table 50 RAN2.0079: Directed RRC connection setup . . . . . . . . . . . . . . . . . . . 312Table 51 RAN1266: Soft handover based on detected set reporting . . . . . . . . . 312Table 52 RAN1.024: Soft handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313Table 53 RAN1.5009: WCDMA - GSM inter-system handover . . . . . . . . . . . . . 317Table 54 RAN1.5009: WCDMA - GSM inter-system handover AND RAN1180: Wire-

less Priority Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Table 55 RAN1183: UTRAN - GAN interworking . . . . . . . . . . . . . . . . . . . . . . . . 321Table 56 RAN2.0060: IMSI based handover . . . . . . . . . . . . . . . . . . . . . . . . . . . 321Table 57 RAN140: Load and service based IS/IF handover . . . . . . . . . . . . . . . . 323Table 58 RAN1275: Inter-system handover cancellation . . . . . . . . . . . . . . . . . . 327Table 59 RAN928: Directed Retry AND Inter-system Handover Cancellation . . 327Table 60 RAN1191: Detected set reporting and measurements . . . . . . . . . . . . 327Table 61 RAN1515: HSPA inter-RNC cell change . . . . . . . . . . . . . . . . . . . . . . . 328Table 62 RAN1276: HSDPA inter-frequency handover . . . . . . . . . . . . . . . . . . . 328Table 63 RAN1596: HSPA Capability based handover . . . . . . . . . . . . . . . . . . . 329Table 64 RAN146: Power Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329Table 65 RAN1824: Inter-frequency Handover over Iur . . . . . . . . . . . . . . . . . . . 330Table 66 RAN966: Multi-Operator Core Network . . . . . . . . . . . . . . . . . . . . . . . . 330Table 67 RAN1.029: Packet scheduler algorithm parameters . . . . . . . . . . . . . . 331Table 68 RAN1011: HSPA layering for UEs in common channels . . . . . . . . . . . 332Table 69 Handover control basic functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 332Table 70 HSDPA basic functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333Table 71 RAN 964: Directed RRC Connection Setup for HSDPA Layer . . . . . . 333Table 72 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements . .

334Table 73 RAN955: Power Saving Mode for BTS . . . . . . . . . . . . . . . . . . . . . . . . 336Table 74 RAN1201: Support for Fractional DPCH . . . . . . . . . . . . . . . . . . . . . . . 337Table 75 RAN1231: Support for HSPA over Iur . . . . . . . . . . . . . . . . . . . . . . . . . 340Table 76 RAN1642: MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340Table 77 RAN1906: Dual-Cell HSDPA 42 Mbps . . . . . . . . . . . . . . . . . . . . . . . . 340Table 78 RAN1758: Multiple BSIC Identification . . . . . . . . . . . . . . . . . . . . . . . . 341Table 79 RAN2289: Blind IFHO in RAB Setup Phase . . . . . . . . . . . . . . . . . . . . 341

DN03471612 15

WCDMA RAN RRM Handover Control Summary of changes

Id:0900d8058081a68bConfidential

Summary of changes Changes between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.

Please note that our issue numbering system is changing. For more information, see Guide to WCDMA RAN Documentation.

Changes between issues 10E (2010/11/15, RU20) and 10F (2011/01/31 RU20)

Soft handover based on detected set reporting (10.1.7)

– Information on increase Uu interface signaling due to detected set reporting added.

Functionality of inter-frequency handover (11)

– Parameter names have been corrected.

Functionality of load-based and service-based IF/IS handover (18)

– Information on the service-based handover for the HSDPA-capable UE has been added.

Changes between issues 10D (2010/09/21, RU20) and 10E (2010/11/15 RU20)Functionality of inter-frequency handover (11)

• Parameter names have been corrected.

Changes between issues 10C (2010/03/31, RU20) and 10D (2010/09/21 RU20)Handover control (1)

• Information on Blind Inter-Frequency Handover in RAB setup phase has beenad-ded.

Functionality of intra-frequency handover (10)

• Calculation of measurement result for reporting event 1C has been updated.

Functionality of Blind inter-frequency handover in RAB setup phase (23)

• New section.

Management data for handover control (35)

• Parameters for RAN2289: Blind IFHO in RAB Setup Phase has been added.

16 DN03471612


Id:0900d8058081a68bConfidential

Summary of changes

DN03471612 17

WCDMA RAN RRM Handover Control Handover control

Id:0900d805807db96bConfidential

1 Handover controlThe purpose of handover control is to manage the mobility aspect of a Radio Resource Control (RRC) connection. This means keeping track of the user equipment (UE) as it moves around in the network, and ensuring that its connections are uninterrupted and meet the negotiated Quality of Service (QoS) requirements.

Besides supporting the mobility of the UE, handovers play a key role in maintaining high capacity in the network. Since the capacity of a Wideband Code Division Multiple Access (WCDMA) network is directly proportional to the level of interference in the network, it is crucial to regulate the transmission power of all transmitting elements in the network. Each transmission adds to the interference in the network. The required transmission power, in turn, depends on the bit rate, the interference and the distance between the UE and the WCDMA Base Station (BTS).In order to keep the power of its signal constant, the UE must raise its transmission power as it moves further away from the WCDMA BTS. To minimise transmission powers, and consequently interference, the UE should at all times be connected to the strongest cell. In this way, handover control is directly related to power control, which is the algorithm that keeps transmission powers in check. Handover control and power control, in turn, are both part of radio resource management.

1.1 Handover typesRadio access network (RAN) supports intra-frequency, inter-frequency and inter-system handover procedures. In an intra-frequency handover the UE shifts between cells using the same carrier frequency. Inter-frequency handovers differ from this in that the cells use different carrier frequencies. Inter-system handover means that the cells use different radio access technologies (RAT), and consequently different frequencies, too. A handover between a GSM cell and a WCDMA cell is, for example, a typical inter-system handover.

Intra-frequency soft and hard handovers and inter-frequency handovers are general features in the RAN, whereas inter-system handover is an optional feature.

Table Handover types below summarizes the different handover types.

There is a fundamental difference between the intra-frequency handovers and the other handover types; the intra-frequency handovers are indispensable as they allow the UE to move around, whereas the other types of handover provide added coverage.

Handovers are divided into soft and hard handovers. In soft handovers, the UE is simultaneously connected to more than one WCDMA BTS via so called radio links. All WCDMA BTS use the same carrier frequency. In soft handover, the UE is not discon-nected at all - instead it simply drops one out of two or more radio links, while the other radio links remain active. The inter-frequency and inter-system handovers are always

Handover type Soft Hard Evaluated byCompressed mode needed

General feature

Intra-frequency Yes Yes Mobile No Yes

Inter-frequency No Yes Network Yes Yes

Inter-system No Yes Network Yes No

Table 1 Handover types

18 DN03471612



Handover control

hard handovers. Hard handovers cause a very short disconnection of real-time bearers (for example speech connections fall into this category), as the UE switches to another frequency or between GSM and WCDMA cells.

Table Handover types according to shifts between the BTSs and RNCs below illustrates the relationships between intra- and inter-BTS and RNC handovers in different handover types.

1.2 Neighbor cellsWhen the UE is in connected mode, the RNC follows it on cell level. Once it knows in which cell the UE is located, the RNC checks information about all the neighboring cells and transmits the data back to the UE. The RNC updates continuously the neighbor cell lists in order to reflect the changing neighborhood of a moving mobile station in con-nected mode.

Neighbor cell definitionsThe neighboring cells are defined on a cell-by-cell basis, that is, each cell can have its own set of neighboring cells. A neighbor cell definition includes, for example, information about the radio access technology, carrier frequency, and scrambling codes of the neighbor cell. Neighboring cell definitions are stored in the RNW configuration database.

By relaying information about neighbor cells to the UE, the RNC is effectively telling it what to look for, and the RNC knows what the available options are if the load in the serving cell increases too much. Neighbor cell definitions also speed up cell re-selection procedures, as the UE does not have to decode the scrambling codes of other cells.

The UE monitors three separate cell categories:

• active set cells:Radio links are established between active set cells and the UE. All cells in the active set send user information. The cells in the active set are partici-pating in soft handover and they are included in the intra-frequency cell list of the UE.

• monitored set cells: Cells included in the intra-frequency, inter-frequency and inter-system cell lists of the UE and monitored according to these lists. The intra-fre-quency cells in the monitored set are not participating in soft handovers.

• detected set cells: The cells in the detected set have been detected by the UE outside the intra-frequency cell list of the UE.

Neighbor cell parameters are defined on a neighboring cell-by-cell basis for each handover type (intra-, inter-frequency and inter-system) separately by attaching a spec-

Handover type Intra-BTS Inter-BTS Intra-RNC Inter-RNC

Softer handover x

Soft handover x x x

Hard handovers

• Intra-frequency handover

x

• Inter-frequency handover

x x x x

Table 2 Handover types according to shifts between the BTSs and RNCs

DN03471612 19



ified parameter set to a specified neighbor cell. The parameter set defines the handover path from the serving cell to the neighbor cell in question.

The maximum number of neighboring cells that can be signalled to the UE is:

• 32 intra-frequency cells including the active set, and in the system Information messages (SIB11, SIB12 and SIB18) serving cell + 31 neighboring cells

• 32 inter-frequency neighbors • 32 inter-RAT (GSM) neighbors

For more information on the increase of the maximum number of intra-frequency neighbor cell definitions because of soft handover based on detected set reporting see section below.

Neighbor cell list generation during soft handoverThe RNC generates a new intra-frequency neighbor cell list after every active set update procedure. The RNC transmits the new intra-frequency neighbor cell list to the user equipment if the new list differs from the intra-frequency neighbor cell list that is currently used by the user equipment. The RNC does not modify inter-frequency or GSM neighbor cell lists after the active set update procedure because of the limited running time of these periodic measurements.

Without the Soft Handover Based on Detected Set Reporting feature, the UE considers only active and monitored set cells that are included in the intra-frequency cell list of the UE for event evaluation and reporting. If the neighbor cell lists of two or more active set cells, which are participating in soft handover, are different, the RNC combines the lists into one common neighbor cell list which is transmitted to the user equipment. The com-bination of intra-frequency neighbor cell lists is carried out in the following steps 1, 2, 3 and 4. The combination procedure for the inter-frequency and GSM neighbor cell lists consists of the steps 2, 3 and 4 below.

1. active set cellsFirst the RNC selects the active set cells into the neighbor cell list.

2. neighbor cells which are common to three active set cellsDuring the second step of neighbor cell list combination the RNC selects those neighbor cells which are common to all three active set cells. If the total number of relevant neighbor cells exceeds the maximum number of 32 after the second step, the RNC removes in random order those surplus cells from the combined neighbor cell list which are selected during the second step.

3. neighbor cells which are common to two active set cellsDuring the third step of neighbor cell list combination the RNC selects those neighbor cells which are common to two active set cells. If the total number of relevant neighbor cells exceeds the maximum number of 32 after the third step, the RNC removes in random order those surplus cells from the combined neighbor cell list which are selected during the third step.

4. neighbor cells which are defined for only one active set cellDuring the fourth step of neighbor cell list combination the RNC selects those neighbor cells which are defined for only one active set cell. If the total number of relevant neighbor cells exceeds the maximum number of 32 after the fourth step, the RNC removes those surplus neighbors from the combined neighbor cell list which are selected during the fourth step, starting from the neighbors of the weakest (CPICH Ec/No) active set cell.

20 DN03471612



Handover control

For more information on the increase of the maximum number of intra-frequency neighbor cell definitions because of detected set reporting see section below.

Detected set reportingDetected set reporting is based on a 3GPP feature that allows the UE to measure and report any intra-frequency cell that is outside the intra-frequency cell list of the UE. This capability removes the limitation on the length of the intra-frequency cell list.

Detected set reporting makes it possible to increase the maximum number of intra-fre-quency neighbor cell definitions significantly so that the RNC can always include all potential target cells in the active set:

• The maximum number of intra-frequency neighbor cells per WCDMA cell increases from 31 to 63 with detected set reporting.

• The total number of intra-frequency neighbor cells during soft handover is up to 126 or 189 cells, as the RNC integrates the intra-frequency neighbor cell definitions of up to three active set cells.

With detected set reporting, the number of call drops is reduced for example in demand-ing radio environments like dense urban areas. If a dominant neighbor is missing from the intra-frequency cell list of the UE, serious UL interference is caused to the surround-ing cells and the call can eventually drop because of poor EbNo.

Without detected set reporting, the probability of missing dominant neighbors is even greater during the soft handover. If the active set cells have more than 30 (29 in case of 3 branch soft handover) different intra-frequency neighbor cells in all, some of the neigh-bors will be excluded from the list which is transmitted to the UE because the RNC has to combine the intra-frequency neighbor cells of the active set cells into one 32 cell list (including the active set cells).

1.3 Hierarchical cell structureFrom the network operator's point of view, it does not make sense to offer the same amount of capacity everywhere. Instead, the capacity should be concentrated to those places where users commonly require it. Nokia Siemens Networks offers solutions that allow operators to tune the capacity to the local needs by creating hierarchical cell struc-tures (HCSs). By creating microcells inside macrocells - and even picocells inside micro-cells - operators can offer both great coverage and high capacity where it is most needed.

Different layers use different frequencies, but it is also possible to use different frequen-cies on the same layer, in order to boost the capacity. The end result can be a very complex hierarchy involving several layers and frequencies.

In addition, GSM cells, which offer additional capacity, also have to be taken into account. This setup, with multiple frequencies and radio access technologies, compli-cates things for handover control. Regarding radio network optimization, all radio resources should be at the disposal of radio resource management; consequently, handover control must allow the UE to move between all types of cells.

DN03471612 21



1.4 Features related to handover control

1.4.1 IMSI-Based handover The purpose of the IMSI-Based Handover feature is to enable a mobile subscriber visiting another network to hand over only to cells which belong to specified (home or authorised) PLMNs. The input for the selective handover control is the PLMN identifier that is included in the IMSI of the subscriber.

The PLMN identifier, which consists of Mobile Country Code (MCC) and Mobile Network Code (MNC) is included in the IMSI of the subscriber as shown in figure IMSI definition below.

Figure 1 IMSI definition

The IMSI-Based Handover feature can be enabled separately for intra-frequency, inter-frequency and inter-system handovers. When the feature is enabled, the RNC makes the neighbor cell lists for the inter-frequency and inter-system (GSM) measurements on a subscriber-by-subscriber basis according to the PLMN identifier that is included in the IMSI of the subscriber, and performs the corresponding handover selectively to the neighboring cell which either belongs to the home PLMN of the subscriber or to a PLMN which is defined in the authorised network list.

When the feature is enabled for intra-frequency handovers, the RNC adds a new cell to the active set only if the PLMN identifier of the cell (that has triggered reporting event 1A or 1C) is included in the list of authorised networks, it has the same PLMN identifier as the subscriber, or it has the same PLMN identifier as an existing active set cell.

When the Multi-Operator Core Network (MOCN) feature is enabled in the RNC, the IMSI-Based Handover feature is always enabled too.

For more information on IMSI based handover see Functionality of IMSI-based han-dover.

1.4.2 Load- and service-based IF/IS handoverLoad- and Service-Based IF/IS Handover is an optional feature.

Load- and service-based handovers take care of load sharing and service differentiation inside the WCDMA system as well as between the WCDMA and GSM/GPRS systems. Both load and service are taken into account simultaneously, but the measured load defines the way of operation.

The load indicators that can be measured are:

• UL/DL interference

IMSI = MCC + MNC + MSIN

PLMN id

IMSIMCCMNCMSINPLMN

International Mobile Subscriber IndetityMobile Country CodeMobile Network CodeMobile Subscriber Identification NumberPublic Land Mobile Network

22 DN03471612



Handover control

• NRT traffic delay • DL spreading code availability • HW/logical resource usage

Figure Load of the source cell below clarifies the dependency.

Figure 2 Load of the source cell

This feature also enables the operator to set different handover profiles for the service classes. The service classes are split according to the traffic classes specified for the RABs, separating the speech and data services from the CS and PS domains. The RNC-based handover profile defines the preferred system or WCDMA hierarchical cell layer (GSM, WCDMA macro, WCDMA micro, none). By default, only the RT services are handed over, because the NRT dedicated traffic channel (DCH) allocations are expected to be too short for these kinds of handover procedures. However, the operator may enable handovers also for the NRT services in case of longer DCH allocations.

For information on load- and service-based handovers, see Functionality of load-based and service-based IF/IS handover.

1.4.3 HSDPA (high speed downlink packet access)HSDPA-specific mobility control includes the features Serving HS-DSCH Cell Change and SHO of the Associated DCH. HSPA inter-RNC mobility is provided by the HSPA inter-RNC cell change feature.

HS-PDSCH allocation for a given UE belongs to only one of the radio links assigned to the UE: the serving HS-DSCH radio link. The cell associated with the serving HS-DSCH radio link is defined as the serving HS-DSCH cell. A serving HS-DSCH cell change facil-itates the transfer of the serving HS-DSCH radio link’s role from one radio link belonging to the source HS-DSCH cell to a radio link belonging to the target HS-DSCH cell.

The serving HS-DSCH cell change is based on the intra-frequency CPICHEc/No mea-surements reported periodically by the UE and dedicated UL SIRerror measurements reported periodically by the BTS.

For more information on HSDPA-related mobility control, see Section HSDPA mobility handling in "WCDMA RAN RRM HSDPA".

DN03471612 23



For more information on directed RRC connection setup for the HSDPA layer, see Section Directed RRC connection setup for HSDPA layer.

1.4.4 HSDPA inter-frequency handoverBased on inter-frequency handover (IFHO) triggers, the RNC orders compressed mode on HSDPA so that inter-frequency measurements can be performed on HSDPA without channel type switching to DCH. Thus, high HSDPA throughput can be experienced during compressed mode and the total handover execution time is reduced up to 1.5 s.

The following changes in the channel type are supported during HSDPA inter-frequency handover:

• DCH/HSDPA to DCH/HSDPA • DCH/HSDPA to HSUPA/HSDPA • DCH/HSDPA to DCH/DCH • DCH/DCH to DCH/HSDPA • DCH/DCH to HSUPA/HSDPA

Inter-frequency handover is triggered because of coverage and quality reasons, but also IMSI based handover and HSPA capability based handover can be initiated. The RNC selects the target cell according to the measurement results and performs inter-fre-quency handover along with HSDPA serving cell change. The target cell can be an intra- or inter-RNC cell depending on the defined neighboring cells.

This feature enables also inter-frequency handover directly to HSUPA/HSDPA, even if the handover is started from DCH. If the HSDPA allocation is not possible in the target cell, handover is performed to DCH. Channel type switching to DCH or FACH may be performed during compressed mode, for example if the active set is updated or inactivity is detected.

1.4.5 Inter-frequency handover over IurMobility between RNCs in UTRAN connected mode can be carried out either by the SRNS relocation (RANAP) procedure or by the anchoring method.

The SRNS relocation procedure takes place after the last active set cell (radio link) con-trolled by the SRNC is removed from the active set and all remaining radio links (active set cells) of the RRC connection are controlled by the DRNC.

If the DRNC or the CN does not support the SRNS relocation procedure, the SRNC must continue as a controlling node (anchoring point) for the RRC connection via Iur interface and DRNS. The user plane traffic between the DRNS and the CN is transferred via Iur interface and the SRNC. Full UTRAN connected mode mobility during anchoring requires the support of intra- and inter-frequency handovers over Iur.

Handovers supported by RNC:

• Intra-frequency (soft and softer) handover over Iur • Inter-frequency handover over Iur for DCHs • HSPA handover over Iur

Basic functions for inter-frequency handover over Iur are:

1. The DRNC informs the SRNC on the inter-frequency neigbour cells, in addition to the intra-frequency neighbor cells, that have been defined for the active set cell(s) controlled by the DRNC.

24 DN03471612



Handover control

2. The SRNC takes into account the inter-frequency neighbor cell information, which has been received from the DRNC, in the inter-frequency measurement and handover decision procedures.

3. BTS and cell level handover control parameters are specified to be used during the anchoring for the active set cells controlled by the DRNC and for the neighboring cells defined on the DRNC side.

4. Compressed mode is supported during anchoring.5. Inter-frequency handover signaling procedures are supported over Iur.6. Before the last active set cell controlled by the SRNC is removed from the active set

and anchoring starts, the bit rate of NRT DCHs is downgraded to UL: 64/ DL: 64 kbit/s. The same downgrade takes place also during the inter-frequency handover from the SRNC to the DRNC over the Iur interface.

1.4.6 The HSPA inter-RNC cell changeThe HSPA Inter-RNC Cell Change feature improves the end user performance by main-taining the high data rates of HSPA services during intra-frequency inter-RNC mobility. Capacity gain is achieved at the cells of the RNC border area when HSPA instead of DCH can be utilized. In the case of CS AMR speech multi-service, direct switch to DCH is applied in order to guarantee strict quality and delay requirements for the speech.

When intra-frequency measurements indicate that the strongest cell in the active set is located under the DRNC, HSPA intra-frequency inter-RNC cell change is initiated. Oper-ators can specify individual thresholds to trigger inter-RNC cell change by management parameters.

HSPA intra-frequency inter-RNC cell change utilizes UE involved SRNS relocation, that is, the UE is reconfigured according to the resources of the target RNC during SRNS relocation.

Target RNC allocates resources on best effort basis, that is, even though HSPA is pri-marily allocated, also DCH/DCH can be established when HSPA is not available. Source RNC deletes old configuration after successful SRNS relocation. HSPA serving cell change (serving HS-DSCH/E-DCH cell change) is combined with inter-RNC cell change.

HSPA data flow is established over Iur-interface and HSPA resources are reserved and allocated under DRNC in conjunction of the SRNS relocation. Associated DCH (signal-ing link) and uplink DCH return channel can be set up over Iur-interface, whereas HS-DSCH and E-DCH cannot be established. HSPA Inter-RNC cell change is supported also when Iur-interface is disabled, congested or not existing.

For more information on HSPA inter-RNC cell change, see HSDPA mobility handling in "WCDMA RAN RRM HSDPA"

1.4.7 HSUPA (high speed uplink packet access)For information on HSUPA, see Architecture of Radio Resource Management of HSUPA in "WCDMA RAN RRM HSUPA".

DN03471612 25



1.4.8 Soft handover based on detected set reportingDetected set reporting is based on a 3GPP feature that allows the UE to measure and report any intra-frequency cell which is outside the intra-frequency cell list of the UE. This capability removes the limitation on the length of the intra-frequency cell list.

Detected set reporting makes it possible to increase the maximum number of intra-fre-quency neighbor cell definitions significantly so that the RNC can always include all potential target cells in the active set:

• The maximum number of intra-frequency neighbor cells per WCDMA cell increases from 31 to 63 with detected set reporting.

• The total number of intra-frequency neighbor cells during soft handover is up to 126 or 189 cells, as the RNC integrates the intra-frequency neighbor cell definitions of up to three active set cells.

With detected set reporting, the number of call drops is reduced for example in demand-ing radio environments like dense urban areas. If a dominant neighbor is missing from the intra-frequency cell list of the UE, serious UL interference is caused to the surround-ing cells and the call can eventually be dropped because of poor EbNo.

Without detected set reporting, the probability of missing dominant neighbors is even greater during the soft handover. If the active set cells have more than 30 (29 in case of 3 branch soft handover) different intra-frequency neighbor cells in all, some of the neigh-bors will be excluded from the list which is transmitted to the UE because the RNC has to combine the intra-frequency neighbor cells of the active set cells into one 32 cell list (including the active set cells).

The RNC does not support soft handover based on detected set reporting during anchoring.

1.4.9 Inter-system handover cancellationInter-System measurements may be started in the UE because of radio coverage and connection quality reasons. When the inter-system measurements are completed, the target cell is selected. The inter-system measurement phase takes a few seconds and during that time the conditions in the WCDMA layer may change. With this feature unnecessary quality and coverage reason inter-system handovers can be cancelled in the UE thus retaining the call in current WCDMA network.

If one of the following situation occurs during the inter-system measurements, the RNC stops the handover and compressed mode measurements:

• Intra-frequency measurements performed by the UE in parallel to the inter-system measurements indicate that the conditions have improved in the WCDMA layer so that defined cancellation thresholds are exceeded.

• UE internal measurements or RL quality measurements indicate that the radio con-ditions have improved.

• The active set is updated because of cell addition or cell replacement.

1.4.10 UTRAN - GAN interworkingThe UTRAN - GAN Interworking feature enables inter-RAT handovers between UTRAN and GAN networks for CS voice calls. The inter-RAT handover is supported on both directions, that is from UTRAN to GAN and from GAN to UTRAN. Idle mode mobility is invisible to UTRAN.

26 DN03471612



Handover control

The RNC sets up the inter-RAT measurement event 3A as a GAN-specific handover trigger for UEs which support the handover to GAN. Each WCDMA cell can have one GAN neighbor cell. The GAN neighbor cell is defined in the RNW database object ADJG which is also used for GSM neighbor cell definitions. The parameter ADJG - ADJGType indicates whether the inter-system neighbor cell is a GSM cell or a GAN cell. The neighbor cell is a GAN cell when the value of the parameter ADJG- ADJGType is "GAN cell". Compressed mode is not needed as UEs that support WLAN radio access are capable of simultaneous access to both WLAN and UTRAN.

UEs in GAN preferred mode send event 3A after successful registration to the GAN cell. UTRAN as preferred mode is not supported. Based on the received event 3A measure-ment report, the RNC performs the inter-RAT handover to the GAN network. The signal-ing procedure of the inter-RAT handover from UTRAN to GAN is identical to the signaling procedure of the inter-RAT handover from UTRAN to GSM.

Figure 3 UTRAN - GAN interworking

1.4.11 Directed retry of an AMR callThe Directed Retry feature triggers an inter-system handover to GSM for AMR and AMR-WB calls if the source cell is congested. The directed retry is performed for single AMR and AMR-WB RAB services.

The directed retry takes place during the AMR RAB setup. If the setup of the RAB fails with the cause value "Directed Retry", the RNC indicates the allocation attempt to GSM by sending a RAB ASSIGNMENT RESPONSE message with the RAB ID included. Afterward, the RNC begins the relocation by sending the RELOCATION REQUIRED message to the core network including the cause value "Directed Retry" and the Cell Global ID to indicate the target cell.

A blind handover is performed as inter RAT measurements are not started for the con-nection in question prior to the handover. Target cell for the handover is a GSM cells with the Inter-system adjacency identifier (ADJGId) parameter value set to '0'. The call is rejected if there is no GSM cell with the ADJGId parameter value set to '0'.

The Inter-System Handover feature is a prerequisite for using the Directed Retry feature in an individual cell. The Directed Retry feature needs to be activated by an RNC level license key before it can be enabled in an individual cell by the Usage of Directed Retry of AMR call Inter-system Handover (AMRDirReCell) parameter.

GSM

UMTS

Handover

WLAN

BSC TCSM

RNC MGW

GANC

Core Network

MSC

IP AccessNetwork

DN03471612 27



1.4.12 HSPA capability based handoverThe HSPA Capability Based Handover feature provides a mechanism to periodically hand over all HSPA-capable UE's from non HSDPA/HSUPA WCDMA cells to neighbor cells providing HSPA support. The target cell can be a WCDMA cell served by an RNC or an I-HSPA cell served by the I-HSPA system. HSPA-capable UE's in HSDPA/HSUPA WCDMA cells are handed over to I-HSPA cells by an event triggered mechanism.

This feature improves the utilization of available network resources for providing seamless services for the end-user. HSDPA/HSPA capable UE's benefit from this feature as they are able to use the HSPA services more efficiently.

The HSPA capability based handover is started periodically in all non-HSDPA/HSUPA WCDMA cells where the feature is enabled. The mechanism is based on the service based handover principle. If an HSPA capable UE with a suitable RAB combination on DCH is found in a cell where the HSPA Capability Based Handover feature is enabled, the UE is handed over to the target inter-frequency WCDMA or I-HSPA cell.

If a UE in an HSPA cell uses HSDPA/HSPA services, DL (HS-DSCH) and UL (DCH/E-DCH) inactivity triggers event based HSPA capability based handover. The target cell can only be an I-HSPA cell.

The periodic and event-triggered HSPA capability based handover is separately enabled in the cell level by setting the HSPACapaHO parameter value. Also HSCapabil-ityHOPeriod parameter is used to to enable or disable the periodical triggering of the HSPA capability based handover.

In the event of an intra-RNC HSPA capability based handover, an inter-frequency hard handover is performed.

An inter-RNC HSPA capability based handover or a handover from 3G UMTS to I-HSPA is a combination of an inter-frequency hard handover and SRNS relocation. For a suc-cessful HSPA capability based handover to an I-HSPA cell, the target I-HSPA adapter must support SRNC relocation.

1.4.13 Power balancingThe need for power balancing arises from detection errors in the decoding of the power control commands (TPC) during soft handover. Power drifting occurs and needs to be taken into account in the downlink power control mechanism during a soft handover.

Figure 4 Power drifting

In the event of a soft handover, the UE sends the same power control command value to all base stations involved in the handover and each BTS detects the value on its own.

transmission ofpower control command

Detection ofpower control

command

Adjustmentof downlink

power


command


power

28 DN03471612



Handover control

Because of detection errors, the power control commands are decoded differently at dif-ferent base stations. The DL transmission power of radio links at different base stations starts to drift apart and the power values received at the UE are unbalanced. As a result, one of the BTS can start suffering from a capacity lost in downlink direction.

The power balancing algorithm controlled by the RNC works together with the DL fast closed loop power control in the BTS as long as the soft handover situation takes. It peri-odically compares the transmitted code power of a radio link to a reference transmission power and a slow power correction is made accordingly. The DL transmission power of all radio links is forced to be balanced in a controlled manner and no capacity lost occurs because of power drifting problems.

1.4.14 Multi-Operator core networkThe Multi-Operator Core Network (MOCN) feature is a 3GPP solution for RAN sharing that enables several CN operators to be connected to the same RNC and to share all RAN resources of this RNC.

The PLMN identities of available CN operators are broadcast to the UEs in the system information messages. Starting with Rel. 6, UEs can choose the PLMN to which the RNC is supposed to start the signaling connection. The chosen PLMN is signalled to the RNC in the initial messaging. Based on the selected PLMN, the signaling connection is routed directly to the appropriate CN. The Multi-Operator Core Network feature is not visible for end users; they see their own network logo in the terminal.

For Rel. 5 and older UEs, the RNC selects the CN as these UEs are not able to choose the PLMN. The RNC has a re-routing functionality which is used in case the initial selec-tion is not the correct one. The re-routing is triggered by the CN redirection indication. The RNC forwards the initial UE message to another CN until it finds a CN that can serve the UE.

With the Multi-Operator Core Network feature, the RAN and cells are shared among the operators while in the Multi-Operator RAN feature, the RAN is shared but each operator has its own cells. For more information on the Multi-Operator RAN feature see Shared RAN functional area description.

The Multi-Operator Core Network feature can be combined with the Flexible Iu feature and/or the Multi-Operator RAN feature.

1.4.15 Support for I-HSPA sharing and Iur mobility enhancementsSupport for I-HSPA Sharing and Iur Mobility Enhancements feature shares NodeB resources between WCDMA and I-HSPA.

Support for I-HSPA Sharing and Iur Mobility Enhancements solution makes it possible to install one card to existing NodeB and take HSPA traffic directly out from base station. NodeB supports all services within following functional split: RNC supports CS and CS+PS multi-RAB services, while I-HSPA Adapter (card inside NodeB) supports PS Rel99 and HSPA service. The feature shares automatically all resources of NodeB.

Support for I-HSPA Sharing and Iur Mobility Enhancements feature is based on idea where serving RNC functionality is switched between RNC and I-HSPA adapter based on the services the user wants. Iu-CS services are supported in RNC. Once the CS call trigger is received in I-HSPA adapter, it sends a Relocation Request to RNC. Upon the successful relocation completion in RNC, the call continues to proceed in anchoring mode.

DN03471612 29



When CS call is released, a relocation is triggered back to I-HSPA adapter.

Support for I-HSPA Sharing and Iur Mobility Enhancements feature enables full con-nected mode mobility between RNC and I-HSPA cells thus improving the end user expe-rience by avoiding hard handovers. Iur interface is configured between the RNC and the I-HSPA adapter to support both intra-frequency and inter-frequency handover over Iur.

Support for I-HSPA Sharing and Iur Mobility Enhancements feature provides following enhancements to anchoring scenarios and DRNC in general:

1. Support Inter-System Handover to a GSM cell during anchoring2. Support NRT DCH scheduling over Iur. Bitrate modification is supported during

anchoring.3. Congestion Control in DRNC: PBS, Preemption, RT over NRT, RT over RT,

Overload Control, are triggered by DRNC during overload/congestion situations4. Power Balancing and DyLo are supported during anchoring5. LCS is supported during anchoring6. UTRAN-GAN handover is supported during anchoring

With the above enhancements there is a very little difference in the service experienced by the UE during anchoring and non-anchoring scenarios, thus improving the end user experience during anchoring.

1.4.16 Support for F-DPCH and SRB's on HSPAFractional DPCH shares the DL dedicated code channel carrying L1 signaling (TPC bits) of HSDPA users. DL L1 signaling of up to 10 HSDPA users are time multiplexed on the same SF256 DL code channel and L1 control overhead is reduced. By sharing the SF256 channel with F-DPCH, the number of HS-PDSCH codes (and DPCH codes) can be increased. Fractional DPCH is used only for Rel. 7 and later UE. WCDMA RAN supports the Rel. 7 version of F-DPCH.

F-DPCH is only supported for SRBs on HSPA. In this case HSUPA uses either 2 ms or 10 ms TTI. Switching between mapping of SRBs on DCH and HSPA is supported. Rel. 7 improves F-DPCH gains in soft handover when compared to Rel. 6 F-DPCH, by allowing more SHO users to be multiplexed to the same SF256 code channel. HSDPA average cell throughput is increased thanks to improved spreading code efficiency and reduced L1 control overhead in case of high number of HSDPA users.

1.4.17 Forced Hard HandoverDuring the Cell Deletion procedure, the CPICH power is ramped down in the cell to be deleted. The Cell Deletion procedure is used in the following functions:

• cell locking • cell deletion from RNC radio network database • Power Saving Mode for BTS feature

After the CPICH power ramp-down has been completed in the cell, forced handover is triggered for all UEs that are still remaining in this cell. The decision criteria and proce-dures for Cell Deletion in Power Saving Mode for BTS are presented in the WCDMA RAN RRM Admission Control.

30 DN03471612



Handover control

1.4.18 Support for HSPA over IurThe HSPA over Iur feature improves the end-user performance by maintaining the con-tinuous high data rate HSPA service during inter-RNC mobility. Capacity gain is achieved in RNC border cells when the serving cell changes and HSPA instead of DCH services can be used.

When the UE's intra-frequency measurements indicate that the strongest cell in the active set is under the DRNC, HSDPA and HSUPA serving cell change over Iur is per-formed. After the serving cell change, HSDPA (HS-DSCH MAC-d flow) and HSUPA (E-DCH MAC-d flow) data is transmitted over Iur-interface.

HSPA over Iur feature enables the following functionalities:

• The SRNC sets up HS-DSCH and E-DCH radio links by Iur interface. • The SRNC performs serving cell change (SCC) from SRNC cell to DRNC cell. • The SRNC performs serving cell change (SCC) from DRNC cell to DRNC cell inside

one RNC and between two different RNCs. • The SRNC performs serving cell change (SCC) from DRNC cell to SRNC cell. • The DRNC accepts radio links over the Iur interface that contain HS-DSCH and E-

DCH MAC-d flow information.

When the last active set cell in the SRNC is deleted, "UE not involved" SRNS relocation is triggered while HSPA service is in use. Also "UE involved" SRNS relocation is sup-ported if Iur-interface is congested.

HSPA over Iur feature also supports HSDPA inter-frequency handover over Iur while HS-DSCH MAC-d flow is setup over Iur-interface. Inter-frequency handover over Iur feature is a pre-requisite for the HSDPA inter-frequency handover over Iur.

1.4.19 Dual Cell HSDPA 42 MbpsDual Cell HSDPA (DC HSDPA) uses two adjacent WCDMA carriers to transmit data to a single UE. This allows doubling the data rate for the terminal. Together with 64QAM, peak bit rate is 42 Mbps.

UE sends the Channel Quality Indicator (CQI) information and L1 acknowledgements (HARQ) for both carriers on the common HIgh Speed Dedicated Physical Control Channel (HS-DPCCH). It the result, the differences in fading conditions between carriers are taken into consideration by the BTS scheduler to improve the spectral effi-ciency of the system.

Dual Cell HSDPA is supported with NRT services only. Streaming RAB can exist but it must be mapped to DCH 0/0 kbps when Dual Cell HSDPA is configured. If RT services are needed, dynamic switching between Dual Cell HSDPA and Single Cell HSDPA mode is done. Dual Cell HSDPA is allocated always when possible, instead of Single Cell HSDPA. Dual Cell HSDPA requires F-DPCH, HSDPA 15 codes, HSDPA 14 Mbps per user and flexible RLC features. Use of 64QAM is supported but not required.

In dual carrier mode, the mobility procedures are based on the carrier frequency of the primary serving HS-DSCH cell.

Dual Cell HSDPA provides:

• double peak rate for users, • higher average throughput because of statistical multiplexing, • better coverage because of frequency diversity.

DN03471612 31



Dual Cell HSDPA feature affects the following functionalities in Handover Control area:

• functionalities of Directed RRC connection setup and Directed RRC connection setup for HSDPA layer,

• HSDPA layering for UEs in common channels, • functionalities of DC HSDPA Capability Based Handover.

1.4.20 Support for Multiple input Multiple output (MIMO)MIMO 2x2 enables 28 Mbps peak HSDPA data rate with 16 QAM. MIMO increases single user peak data rate, overall cell capacity and average cell throughput.

MIMO 2x2 assumes a double transmit antenna array (D-TxAA) at the BTS and two receive antennas at the UE with the single or dual stream DL transmission. In the latter case, the operation of two parallel data streams doubles the HSDPA peak data rate, so the theoretical maximum data rate with 16QAM is 28 Mbps in 3GPP Rel-7. HSDPA terminal categories 15, 16, 17 and 18 supporting 2x2 MIMO with 16QAM are introduced. Terminal categories 19 and 20 from Rel-8 are supported with 16QAM only.

The UE signals MIMO capability to the RNC during RRC connection setup procedure. The RNC configures the MIMO mode to MIMO capable UE with RRC signaling. If the MIMO capable UE is not configured in MIMO mode, it operates as a regular non-MIMO UE.

MIMO affects the following functionalities in Handover Control area:

• HSDPA layering for UEs in common channels, • functionalities of MIMO Capability Based Handover.

1.4.21 LTE interworkingLTE Interworking (LTEIW) functionality enables cell reselection from 3G to LTE and provides support for packet switched inter-system handover (PS ISHO) from LTE to 3G.

LTE interworking functionality enables the LTE cell reselection when UE is in idle mode, which prevents UEs in idle mode from running out of LTE coverage. An operator can set cell based camping priority for LTE capable UEs. Therefore the UE can, on the opera-tor’s preference, select to camp on LTE once coverage is available.

WCDMA, LTE and GSM can be prioritized with eight distinct absolute priorities, different Radio Access Technologies (RATs) having always different priorities. In idle, URA_PCH and Cell_PCH states, UE camped in WCDMA periodically measures all higher priority RATs. Also lower priority RATs are measured when WCDMA quality criteria falls below a threshold.

LTE system supports inter-RAT handover to UTRAN because of quality and coverage reasons for packet switched calls. In the same method as a part of LTE Interworking functionality UTRAN must handle the incoming PS ISHO from LTE . Upon receiving the Relocation Request from packet switched core network, target RNC allocates the resources for incoming RAB's and upon successful resource allocation sends Reloca-tion Request Acknowledge to core network.

1.4.22 Blind inter-frequency handover in RAB setup phaseBlind inter-frequency handover is done in the following RAB setup phases:

• First RAB setup is done to the UE

32 DN03471612



Handover control

• AMR RAB setup is done for the UE when it already has a Non-Real-Time RAB(s).

Blind handover is done to other layer when needed. A blind handover quality criterion is the source cell RSCP measurement from RACH. For Rel-6 and newer UE, the quality criteria can be also target cell RSCP measurement.

In blind inter-frequency handover the most suitable layer is selected for the UE based on the following information:

• Prefered layerPreferred layer is defined based on UE capability and the service UE is using. The operator can define preferred frequency layers for different UE capability and service combinations.

• Band capabilityThe frequency band can be preferred for UEs which support that frequency band.

• Low/High RSCP valueWhen UE reports low RSCP value in RACH measurement, the lower frequency band can be preferred. When UE reports high RSCP value in RACH measurement, the higher frequency band can be preferred. This makes it possible to use higher frequency band to bring capacity and lower frequency band to bring coverage. This is valid for blind handover in RAB setup and for layering in state transition to Cell_DCH state.

DN03471612 33

WCDMA RAN RRM Handover Control Types of handovers

Id:0900d80580749ba3Confidential

2 Types of handovers

2.1 Introduction to soft handoverSoft handover means that the UE is connected to more than one WCDMA BTS at the same time (this is why it is also called a "macro diversity handover"). When in connected mode, the UE continuously measures serving and neighboring WCDMA BTSs (cells indicated by the RNC) on the current carrier frequency. The UE compares the measure-ment results with handover thresholds, which have been provided by the Radio Network Controller (RNC). When a measurement yields a value that exceeds a given threshold, the UE sends a measurement report to the RNC. Soft handover is a Mobile Evaluated Handover (MEHO).The main decision algorithm of soft handover is located in the RNC. Based on the mea-surement report received from the UE, the RNC orders the UE to add or remove cells from its active set, that is, the set of cells participating in the soft handover.

The types of intra-frequency handover for both real-time (RT) and non-real-time (NRT) radio access bearers (RABs) are:

• softer handover between cells (having different coverage areas) within one WCDMA BTS

• soft handover between WCDMA BTSs within one RNC (intra-RNC soft handover) • soft handover between WCDMA BTSs controlled by different RNCs (inter-RNC soft

handover).

In the WCDMA system, the vast majority of handovers are intra-frequency handovers. Different types of intra-frequency handovers can take place simultaneously. For example, the RAN is able to perform soft (intra-RNC as well as inter-RNC) and softer handovers at the same time. The benefits of soft and softer handover are the following:

• a seamless handover without a disconnection of the RAB • fast closed-loop power control optimisation (the UE is always linked with the stron-

gest cell) • a sufficient reception level for maintaining communications by combining reception

signals (macrodiversity) from multiple cells when the UE moves to cell boundary areas and cannot obtain a sufficient reception from a single cell

• the macrodiversity gain achieved by combining the reception signal in the WCDMA BTS (softer handover) and in the RNC (soft handover), improves the uplink signal quality and decreases the required transmission power of the UE

Soft and softer handover consume radio access capacity because the UE is occupying more than one radio link connection in the Uu interface. However, the added capacity gained from interference reduction is bigger and hence the system capacity is actually increased when soft and softer handovers are used.

2.2 Introduction to intra-frequency hard handoverIntra-frequency hard handover is a general feature in the RAN. Intra-frequency hard handover causes only a short disconnection of a real-time radio access bearer. As for non-real-time bearers, there is no disconnection at all as packet scheduling momentarily halts the transmission of data. Intra-frequency hard handover is required, for example, to ensure handover path between WCDMA BTSs controlled by different RNCs when

34 DN03471612



Types of handovers

inter-RNC soft handover is not available (because of congestion at the Iur interface, for example).

Intra-frequency hard handover decisions made by the RNC are based on the intra-fre-quency measurement results which are usually applied to the soft handover procedure. Thus the intra-frequency hard handover is a mobile evaluated handover (MEHO).

2.3 Introduction to inter-frequency handoverInter-frequency handover is a general feature in the RAN. Inter-frequency handovers are needed to support mobility between carrier frequencies in the network. Inter-fre-quency handovers are always hard handovers, that is, they cause a short disconnection of RT RABs.

Handover control in RAN supports the following types of inter-frequency handover:

• intra-BTS hard handover • intra-RNC hard handover • inter-RNC (-MSC) hard handover.

Inter-frequency handover is a network-evaluated handover (NEHO). The decision algo-rithm of inter-frequency handover is located in the RNC. The RNC makes the handover decision on the basis of periodical inter-frequency measurement reports received from the UE and relevant control parameters. The RNC orders the UE to start the periodical reporting of inter-frequency measurement results only when an inter-frequency handover is needed. The measurement object information (cells and frequencies) for the inter-frequency measurement is determined by the RNC. Because the UE is not expected to receive from the two different frequencies at the same time, compressed mode must be used at the L1 of the radio interface while the UE makes the required inter-frequency measurements.

After the hard handover decision, the RNC allocates radio resources from the target cell, establishes a new radio link for the connection between the UE and the target cell, and orders the UE to make an inter-frequency handover to the target cell.

2.4 Introduction to inter-system handoverThis feature is a part of application software.

Handover control of the RAN supports inter-system handovers, from WCDMA to GSM and from GSM to WCDMA. Inter-system handover is required so that the coverage areas of GSM and WCDMA can complement each other. When the coverage areas of WCDMA and GSM are overlapping each other, an inter-system handover can be used to control the load and/or services between the systems. Inter-system handover is a hard handover, which means that an inter-system handover causes a short disconnec-tion of an RT RAB.

Inter-system handover is a network-evaluated handover (NEHO). The decision algo-rithm of the inter-system handover and network initiated cell reselection is located in the RNC. The RNC makes the decision on the basis of periodical inter-system measure-ment reports received from the UE and relevant control parameters. The RNC orders the UE to start the periodical reporting of inter-system measurement results only when an inter-system handover or cell reselection is needed. The measurement object infor-mation for the inter-system measurement is determined by the RNC.

DN03471612 35



When an RAB is handed over from one system to another, both the core network and the target RNC (or BSC) are responsible for adapting the Quality of Service (QoS) parameters of the RAB according to the target (GSM or WCDMA) system.

For inter-system handovers to be possible, the UE has to support compressed mode. The UE must also support both WCDMA and GSM RATs before an inter-system handover is possible.

WCDMA to GSMThe decision algorithm of the inter-system handover from WCDMA to GSM is located in the RNC. The RNC recognizes the possibility of inter-system handover based on the configuration of the radio network (neighbor cell definitions and relevant control param-eters).

If an inter-system handover from WCDMA to GSM is required, the RNC initiates an inter-system relocation procedure in order to allocate radio resources from the GSM system. If the resource allocation is successful in the GSM system, the RNC orders the mobile station to make an inter-system handover to the GSM system.

If an inter-system handover (network-initiated cell reselection) from WCDMA to general packet radio service (GPRS) is required, the RNC sends a cell change command to the UE, and the UE is responsible for continuing the already existing PS connection via GPRS RAN.

GSM to WCDMAThe decision algorithm of the inter-system handover from GSM to WCDMA is located in the GSM base station controller (BSC). Thus the GSM Base Station Subsystem (BSS) must support the inter-system handover before the handover from GSM to WCDMA is possible.

After the handover decision, the BSC initiates an inter-system relocation procedure in order to allocate radio resources from the target RNC. If the resource allocation is suc-cessful in the target RNC, the BSC orders the mobile station to make an inter-system handover to the WCDMA system.

Inter-System handover cancellationInter-System measurements may be started in the UE because of radio coverage and connection quality reasons. When the inter-system measurements are completed, the target cell is selected. The inter-system measurement phase takes a few seconds and during that time the conditions in the WCDMA layer may change. Unnecessary quality and coverage reason inter-system handovers can be cancelled in the UE thus retaining the call in the current WCDMA network.

If one of the following situations occurs during the inter-system measurements, the RNC stops the handover and compressed mode measurements:

• Intra-frequency measurements performed by the UE in parallel to the inter-system measurements indicate that the conditions have improved in the WCDMA layer so that defined cancellation thresholds are exceeded.

• UE internal measurements or RL quality measurements indicate that the radio con-ditions have improved.

• The active set is updated because of cell addition or cell replacement.

36 DN03471612



Types of handovers

2.5 Introduction to IMSI-based handoverThis feature is a part of application software.

When the Multi-Operator Core Network (MOCN) feature is enabled in the RNC, the IMSI-Based Handover feature is always enabled too.

The purpose of the IMSI-based handover feature is to enable a mobile subscriber visiting another network to hand over only to cells which belong to specified (home or authorised) PLMNs. The input for the selective handover control is the PLMN identifier that is included in the IMSI of the subscriber.

The PLMN identifier, which consists of Mobile Country Code (MCC) and Mobile Network Code (MNC) is included in the IMSI of the subscriber as shown in figure IMSI definition below.

Figure 5 IMSI definition

The IMSI-based handover feature can be enabled separately for intra-frequency, inter-frequency and inter-system handovers. When the feature is enabled, the RNC makes the neighbor cell lists for the inter-frequency and inter-system (GSM) measurements on a subscriber-by-subscriber basis according to the PLMN identifier that is included in the IMSI of the subscriber, and performs the corresponding handover selectively to the neighboring cell which either belongs to the home PLMN of the subscriber or to a PLMN which is defined in the authorised network list.

When the feature is enabled for intra-frequency handovers, the RNC adds a new cell to the active set only if the PLMN identifier of the cell (that has triggered reporting event 1A or 1C) is included in the list of authorised networks, it has the same PLMN identifier as the subscriber or it has the same PLMN identifier as an existing active set cell.

A list of authorised networks contains a maximum of six PLMN identifiers (MCC + MNC) that are considered equal to the home PLMN of a subscriber. The radio network database contains ten separate authorised network lists. The RNC is able to link up to 128 specified home PLMN identifiers with the specified authorised network lists.

2.5.1 Purpose of IMSI-based handoverIMSI-based handover benefits from roaming-based network provisioning and some RAN-sharing concepts by enabling directed handover from the shared WCDMA network to the home network of the subscriber or to the authorised WCDMA or GSM network, when coverage becomes available. The IMSI-based handover can be used in different cases:

• geographical sharing • common shared RAN with gateway core

IMSI = MCC + MNC + MSIN

PLMN id

IMSIMCCMNCMSINPLMN

International Mobile Subscriber IndetityMobile Country CodeMobile Network CodeMobile Subscriber Identification NumberPublic Land Mobile Network

DN03471612 37



• Mobile Virtual Network Operator (MVNO)

IMSI-based handover and geographical sharingFigure IMSI-based handover in geographical sharing concept below shows the function of IMSI-based handover in the geographical sharing concept. In geographical sharing, operators cover separate areas and share networks via national roaming. However, there are areas where both operators provide coverage (for example big city areas). The IMSI-based handover feature directs the subscriber to the subscriber’s home WCDMA network when coverage becomes available. When the WCDMA coverage ends, the subscriber is handed over to the subscriber’s home GSM network.

Figure 6 IMSI-based handover in geographical sharing concept

IMSI-based handover and common shared RANFigure IMSI-based handover in common shared RAN concept below shows the function of IMSI-based handover in the common shared RAN (with gateway core) concept, where operators build common radio access and core networks in the shared area. When a subscriber moves from the shared area to the area where both operators have their own coverage available, the subscriber is handed over to the subscribers home WCDMA network. When the WCDMA coverage ends, the subscribers are handed over to their home GSM networks.

GSM GSM GSM GSM GSM GSM GSM

WCDMA WCDMA WCDMA WCDMA

WCDMA WCDMAWCDMA WCDMA

GSM GSM GSM GSM GSM GSM GSM

Based on IMSI,operator B user ishanded over to its

own WCDMA networkwhen coverage

becomes available

Based on IMSI,operator A user ishanded over to its


becomes available

Based on IMSI,users are handed

over to their own GSMnetworks when

WCDMA coverage ends

Based on IMSI, loadand service-based inter-system HOs to their own

GSM network inshared area

Operator A GSM cell

Operator A own WCDMA cell

Operator A controlled sharedWCDMA cell

Operator A user path

Operator B GSM cell

Operator B own WCDMA cell

Operator B controlled sharedWCDMA cell

Operator B user path

38 DN03471612



Types of handovers

Figure 7 IMSI-based handover in common shared RAN concept

IMSI-based handover and mobile virtual network operatorFigure IMSI-based handover in mobile virtual network operator concept below shows the function of IMSI-based handover in the mobile virtual network operator concept, where operators have their own GSM networks and one operator is operating as a virtual operator in other operator’s WCDMA network. The IMSI-based handover feature enables load and service-based inter-system handovers to the subscriber’s home GSM network from the virtual mobile network. When the WCDMA coverage ends, subscribers are handed over to their home GSM networks.

GSM GSM GSM GSM GSM

GSM GSM GSM GSM GSM

Based on IMSI,operator B user ishanded over to its


becomes available

Based on IMSI,operator A user ishanded over to its


becomes available



WCDMA coverage ends



Operator A GSM cell

Operator A own WCDMA cell


Common shared WCDMA cell

Operator B GSM cell

Operator B own WCDMA cell


WCDMA

WCDMA

WCDMA WCDMA WCDMA

DN03471612 39



Figure 8 IMSI-based handover in mobile virtual network operator concept

2.5.2 Functional restrictions on IMSI-based handoverWhen the IMSI based handover feature is used in the geographical sharing concept or in the common shared RAN (with gateway core) concept, the shared area must have a PLMN identifier of its own. Otherwise it may be impossible to control a subscriber’s mobility.

The RNC identifier (RncId) uniquely identifies an RNC within the UTRAN. The RNC identifier together with the PLMN identifier is used to globally identify the RNC. When the IMSI-based handover feature is enabled in the RNC, it is possible to define (in addition to the primary PLMN identifier that is a part of the CN domain identifier) second-ary PLMN identifiers under the RNC. The secondary PLMN identifiers are assigned to shared network areas where the subscribers of the partner operator can have access. The RNC identifier must be unique within the primary and secondary PLMNs.

2.6 Introduction to load- and service-based IF/IS handoverLoad- and Service-based IF/IS Handover is an optional feature.

Load- and service-based handovers take care of load sharing and service differentiation inside the WCDMA system as well as between the WCDMA and GSM/GPRS systems. Both load and service are taken into account simultaneously, but the measured load defines the way of operation.

GSM GSM GSM

GSM GSM GSM



WCDMA coverage ends



Operator A GSM cell


Operator A controlled WCDMA cell

Operator B GSM cell


WCDMA WCDMA

40 DN03471612



Types of handovers

Figure Load of the source cell below clarifies the dependency.

The load indicators that can be measured are UL/DL interference, NRT traffic delay, DL spreading code availability, and HW/logical resource usage.

Figure 9 Load of the source cell

This feature also enables the operator to set different handover profiles for the service classes. The service classes are split according to the traffic classes specified for the RABs, separating the speech and data services from the CS and PS domains. The RNC-based handover profile defines the preferred system or WCDMA hierarchical cell layer (GSM, WCDMA macro, WCDMA micro, none). By default, only the RT services are handed over, because the NRT dedicated traffic channel (DCH) allocations are expected to be too short for these kinds of handover procedures. However, the operator may enable handovers also for the NRT services in case of longer DCH allocations.

The list below shows an example of service priority definitions. For each service, the operator sets a preferred system/layer.

• conversational CS speech -> GSM • conversational CS transparent data -> WCDMA, macro • conversational PS speech -> WCDMA, macro • conversational PS RT data -> WCDMA, micro • streaming CS non-transparent data -> WCDMA, macro • streaming PS RT data -> WCDMA, micro • interactive PS NRT data -> WCDMA, micro

The handover profile is followed in both load-based and service-based handover deci-sions unless the core network provides a Service Priority information element (IE) on RAB setup. This, for example, overrides the handover profile if the handover decision for the UE in question is made between the WCDMA and GSM systems.

BenefitsLoad- and service-based handovers are powerful enhancements for the RAN handover functionality: load balancing provides more capacity, hardware investments are used better, and there is less blocking in the network. It allows effective traffic sharing

Load of the source cell (WCDMA)

Load based handoversaccording to service priorities

only service handovers

Perc

enta

ge

com

pare

dto

the

targ

ete

dlo

ad

100%

80%

0%

Operator only needsto set this load threshold

DN03471612 41



between the GSM and WCDMA networks and their layers. It is also possible to do service-prioritised handovers to support different services on cell level. When CS calls are handed over to an existing GSM network, it is possible to prioritise coverage deploy-ment to urban areas first (where the market demand is high), and use the existing GSM layer in rural areas.

With this feature, the operator can shift investments to the future, or with GSM, even prevent the need for capacity enhancement investments.

Load-based handoverLoad-based inter-frequency and inter-RAT handovers are used to balance the load between different WCDMA carriers/cells and between WCDMA and GSM/GPRS systems and by that way fully use the trunking gain. The bigger the channel pool, the better the efficiency of the channel usage. The advantages of a bigger channel pool come up especially if high bit rate channels are used. If load-based handovers are not possible for some reason, normal load control actions take place.

If the load of a specified WCDMA cell exceeds a predefined threshold(s), the RNC starts to hand over certain UEs to other WCDMA cells working in another frequency or to the GSM system. First, the RNC selects the UEs to be handed over. The preferred target RAT or hierarchical WCDMA layer for each selected UE is determined by combining the Iu interface service priority information and the RNC-based service priority information. Next, the RNC starts the inter-frequency and inter-RAT measurements for the selected UEs with normal or modified neighbor cell lists. Finally, the selected UEs are handed over – if possible, according to the measurement results – to the WCDMA cells and/or to the GSM/GPRS cells which are most suitable.

Iu interface service priority information provides guidelines for the target system. However, the final decision is made by UTRAN.

Note that load-based handover is partly also a service-based handover, because the service that the UE is using and both RAB-based and RNC-based service priorities are inputs for the procedure.

Load-based inter-frequency and inter-RAT HO/NCCR can be performed also for the UEs using a packet-scheduled non-real time service.

Service-based handoverService-based handovers are used to move UEs using certain services to the GSM/GPRS system or to another WCDMA hierarchical cell layer. The RNC performs periodical checks in the cell (irrespectively of the load level of the cell) to see if there are any UEs in connected mode whose service priority information received from the Iu interface indicates that “Handover to GSM should be performed”, or whose RNC-based service priority handover profile table indicates that the given UE using a certain service prefers the GSM/GPRS system or another WCDMA hierarchical cell layer. Those UEs are candidates for the service-based handover procedure, and an attempt is made to hand them over one by one to the GSM/GPRS system or to another WCDMA hierarchi-cal cell layer.

Control of load- and service-based handoversThe use of load- and/or service-based handovers can be defined with RNC configura-tion parameters (RNC) separately for different service types.

See an example in the following table:

42 DN03471612



Types of handovers

The used service type is predefined, and for each of the eight service types, one of the following alternatives can be defined:

• Load & Service HO • Load HO • Service HO • None (neither Service HO nor Load HO is used)

g In case of a multiservice, all services must support service-based or load-based handover before they are possible.

2.7 Introduction to directed retryThe Usage of Directed Retry of AMR call Inter-system Handover (AMRDirReCell) FMCG parameter enables and disables the feature in a specific cell. The parameter can be set to enabled only if Inter-system handover feature is in use.

The Directed Retry feature makes an inter-system handover to GSM system if the con-gestion is met in source cell of RAN. It is done for AMR and AMR-WB calls. If a connec-tion includes other RABs in addition to the AMR RAB, no directed retry is made.

The directed retry takes place when the AMR RAB is set up. The RNC indicates an attempt to GSM by sending RAB ASSIGNMENT RESPONSE message with a RAB ID included in the list of RABs failed to set up and a cause value of "Directed Retry". Then the RNC begins a relocation by sending the RELOCATION REQUIRED message to the Core Network with the cause value "Directed Retry" and Cell Global ID to indicate the target cell.

The handover is blind, that is, no inter-RAT measurements are performed for the con-nection in question prior to the handover. The target cell is the GSM cell whose Inter-system adjacency identifier (ADJGId) parameter has value zero. If there is not a GSM cell whose ADJGid parameter has value zero, then the call is rejected.

Service type used by the UE Handover type used

Conversational, Circuit-switched speech For example, Load & Service HO

Conversational, Circuit-switched transpar-ent data

For example, Load & Service HO

Conversational, Packet-switched speech For example, Load HO

Conversational, Packet-switched real time data

For example, Load HO

Streaming, Circuit-switched non-transpar-ent data

For example, Service HO

Streaming, Packet-switched real-time data For example, Service HO

Interactive, Packet-switched non-real time data

For example, None

Background, Packet-switched non-real time data

For example, None

Table 3 Use of load- and service-based handovers according to the service type

DN03471612 43

WCDMA RAN RRM Handover Control Compressed mode

Id:0900d80580749b8dConfidential

3 Compressed modeCompressed mode is a radio path feature that enables the User Equipment (UE) to maintain the current connection on a certain frequency while performing measurements on another frequency. This allows the UE to monitor neighboring cells on another fre-quency (FDD) or RAT, typically GSM. Compressed mode means that transmission and reception are halted for a short time - a few milliseconds - to perform a measurement on another frequency or RAT. The required reception/transmission gap is produced without any loss of DCH user data by compressing the data transmission in the time domain.

The following methods are used to compress the data transmission:

• Halving the spreading factorThis temporarily doubles the physical channel data rate in the radio channel. The same amount of data can be sent in half the time it would normally take. Halving the spreading factor does not affect the DCH user data rate.

• Higher layer schedulingHigher layer scheduling temporarily reduces the DCH user data rate in the radio channel by restricting the high bit rate transport format combinations (TFCs).

The reception/transmission gap always has seven slots. A gap can be placed within one frame or within two consecutive frames depending on the compressed mode method. The figure below shows an example of transmission gaps created with the compressed mode:

Figure 10 Example of transmission gaps created with compressed mode

The UE informs the RNC whether or not it requires compressed mode to perform inter-frequency or inter-RAT (GSM) measurements. Compressed mode is activated sepa-rately for the uplink and downlink directions according to the measurement capabilities of the UE. The type of receiver that the UE is equipped with determines the need for downlink compressed mode. A UE equipped with a single receiver requires downlink compressed mode to perform inter-frequency and GSM measurements, whereas a UE equipped with a dual receiver can perform the measurements in question without downlink compressed mode. The need for uplink compressed mode depends on

UE

WCDMA BTS

Single framegap

Double framegap

Normal frame Normal frame

4 slots 7 slots

11 slots

CM frame

4 slots 7 slots

12 slots7 slots

CM frame CM frame

Normal frame(15 slots)

Normal frame

4 slots 4 slots

CM frame

44 DN03471612



Compressed mode

whether transmission on the currently used uplink radio frequency can interfere with downlink measurements on the monitored frequency.

For compressed mode to be possible, it has to be enabled in the RNC; this is indicated by the RNP parameter Compressed mode master switch (CMmasterSwitch). Further-more, the capabilities of the UE as well as the frequency to be monitored also play a role.

When the feature is enabled, the RNC can activate compressed mode for the purpose of inter-frequency or GSM measurements. Note that, for most UEs, inter-frequency and inter-RAT (GSM) handovers are only possible if compressed mode is used.

The method that is employed to compress the data depends on the service as follows:

• Halving the spreading factor is used for circuit-switched services, conversational packet-switched data services, streaming packet-switched data services and multi services related to them.

• Higher layer scheduling is used for interactive and background packet-switched data services and multi services where all the connections are interactive or back-ground packet-switched data services.

These rules have the following exceptions:

1. Higher layer scheduling is used in both uplink and downlink direction for multi services with AMR + NRT DCH 256/384 kbit/s service combinations in uplink direc-tion. For these uplink service combinations SF=4 is used and this SF does not allow halving the spreading factor. The transmission gap pattern is selected with a process similar to the one for NRT PS data service combinations. If AMR + NRT DCH 8, 16 or 32 kbit/s service combinations are used in the downlink, the halving the spreading factor method is used in downlink instead of higher layer scheduling.

2. If compressed mode is triggered in a situation when minimum uplink SF=4 and RT PS DCH is configured for the RRC connection, all NRT DCHs are released and immediately after that halving the spreading factor method is used in both uplink and downlink.

The same compressed mode method is used for uplink and downlink radio channels according to the measurement capabilities of the UE. The compressed mode pattern sequence is the same for all measurement purposes (be it FDD, GSM carrier RSSI or GSM initial BSIC identification).

3.1 Halving the spreading factorHalving the spreading factor is used for circuit-switched services, conversational packet-switched data services, streaming packet-switched data services and multiservices. Halving the spreading factor does not affect the DCH user data rate, but it does increase the transmission power of the compressed frames by 3 dB. The transmission power of the compressed frames is increased to keep the quality (BER /BLER ) constant despite the reduced processing gain.

A single frame method is used to halve the spreading factor. The transmission gap is seven slots long. As the name of the method implies, the spreading factor (SF) used for the compressed frames is only half of that used for normal frames. For example, if the connection would normally use SF 128, then SF 64 will be used for compressed frames. The original spreading code is used for the normal frames between the compressed frames. The following figure shows an example of transmission gaps created by halving the spreading factor.

DN03471612 45



Figure 11 Halving the spreading factor (single frame method)

The Gap position single frame (GapPositionSingleFrame) RNP parameter controls the position of the transmission gap within the compressed frame. The parameter deter-mines the starting slot of the transmission gap within the compressed frame.

Using the single frame method, a transmission gap pattern contains one compressed frame and at least one normal frame. The total number of frames within the transmission gap pattern is controlled with the RNP parameters listed below. In case of multiservice, the RNC selects the shortest transmission gap pattern length from the applicable parameters.

• Transmission gap pattern length in case of single frame: AMR service and IF mea-surement (TGPLsingleframeAMRinterFreg) parameter defines the length of the transmission gap pattern for inter-frequency measurements in case of com-pressed mode with single frame gap and UE using AMR service.

• Transmission gap pattern length in case of single frame: CS service and IF mea-surement (TGPLsingleframeCSinterFreq) parameter defines the length of the transmission gap pattern for inter-frequency measurements in case of compressed mode with single frame gap and UE using circuit-switched data service.

• Transmission gap pattern length in case of single frame: RT PS service and IF mea-surement (TGPLsingleframeRTPSinterFreq) parameter defines the length of the transmission gap pattern for inter-frequency measurements in case of com-pressed mode with single frame gap and UE using real-time packet-switched data service.

• Transmission gap pattern length in case of single frame: AMR service and GSM measurement (TGPLsingleframeAMRgsm) parameter defines the length of the transmission gap pattern for GSM measurements in case of compressed mode with single frame gap and UE using AMR service.

• Transmission gap pattern length in case of single frame: CS service and GSM mea-surement (TGPLsingleframeCSgsm) parameter defines the length of the trans-mission gap pattern for GSM measurement in case of compressed mode with single frame gap and UE using circuit-switched data service.

• Transmission gap pattern length in case of single frame: RT PS service and GSM measurement (TGPLsingleframeRTPSgsm) parameter defines the length of the transmission gap pattern for GSM measurement in case of compressed mode with single frame gap and UE using real-time packet-switched data service.

Note: If there are NBxxx's with CHC48 plug in unit configuration connected to the RNC, then configured values of the all TGPL* parameters are equal.

If the downlink spreading code to be used for the compressed frames is unavailable (already allocated), an alternative scrambling code can be used. The use of alternative scrambling code makes it possible to allocate the required spreading code from another, free spreading code tree. The disadvantage of using this approach is that the downlink orthogonality suffers from the use of an alternative scrambling code and this may increase the downlink transmission power level on the carrier in question. The Com-

Gaps

CM on

SF/2Original SF

CM off

46 DN03471612



Compressed mode

pressed Mode: Alternative scrambling code (AltScramblingCodeCM) RNP parameter determines whether the use of an alternative scrambling code is allowed. If the use of an alternative scrambling code is not allowed and the spreading code to be used for the compressed frame is not available, the RNC is not able to start the inter-frequency or GSM measurements.

3.2 Higher layer schedulingHigher layer scheduling is used for interactive and background packet-switched data services. It produces the required transmission gaps for inter-frequency and GSM mea-surements by reducing the DCH user data rate in the radio channel. Higher layer sched-uling reduces the DCH user data rate by restricting high bit rate transport format combinations (TFC). Because the maximum number of bits delivered to the physical layer during compressed radio frames is known, a transmission gap can be generated. Higher layer scheduling does not modify the maximum user bit rate of individual DCHs. The following figure shows an example of transmission gaps created with higher layer scheduling:

Figure 12 Higher layer scheduling (double frame method)

Higher layer scheduling can use both single and double frame method; the transmission gap is seven slots long in both cases. The Higher Layer Scheduling mode selection (HLSModeSelection) RNP parameter determines which of these two compressed mode methods is used.

Note that even if the use of the single frame method is allowed, it may not be possible to construct a suitable transport format combination set (TFCS) ; in such a case the RNC can use the double frame method. The following figure describes the selection proce-dure when the single frame method is allowed:

Gaps

CM on Certain TFCs are not allowed to use CM off

10 ms

P

t

DN03471612 47



Figure 13 Selection of the higher layer scheduling mode

One transmission gap pattern consists of one compressed frame and at least one normal frame when the single frame method is used. When the double frame method is used, one transmission gap pattern consists of two compressed frames and at least one normal frame. The total number of frames within the transmission gap pattern is con-trolled with the following RNP parameters:

• Transmission gap pattern length in case of single frame: NRT PS service and IF measurement (TGPLsingleframeNRTPSinterFreq) parameter defines the

Current TFS(s)allows *) doubleframe method?

Possibleto add non-zero

TF(s) to TFS(s) so thatsingle frame method

is possible *)

Possible toadd non-zero TF(s)

to TFS(s) so that double framemethod ispossible *)

Single frame ispossible if non-zero

TF(s) in TFS(s)are not allowed

to use

Double frame method

HLS mode selection

Single frame method

Double frame method

Single frame method

TrCH reconfigurationand single frame method

TrCH reconfigurationand double frame method

Current TFS(s)allows *)

single framemethod?

No

No

No

No

No

Yes

Yes

Yes

Yes

Yes

*) Gap is possible to obtain without restricting

highest allowed TF to zero

Note: RNP parameter HLSModeSelection defineswhether HLS 1/2 is allowed to be used

48 DN03471612



Compressed mode

length of the transmission gap pattern for WCDMA inter-frequency measurements in case of compressed mode with single frame gap and UE using non-real-time packet-switched data service.

• Transmission gap pattern length in case of double frame: NRT PS service and IF measurement (TGPLdoubleframeNRTPSinterFreq) parameter defines the length of the transmission gap pattern for WCDMA inter-frequency measurements in case of compressed mode with double frame gap and UE using non-real-time packet-switched data service.

• Transmission gap pattern length in case of single frame: NRT PS service and GSM measurement (TGPLsingleframeNRTPSgsm) parameter defines the length of the transmission gap pattern for GSM inter-RAT measurements in case of compressed mode with single frame gap and UE using non-real-time packet-switched data service.

• Transmission gap pattern length in case of double frame: NRT PS service and GSM measurement (TGPLdoubleframeNRTPSgsm) parameter defines the length of the transmission gap pattern for GSM inter-RAT measurements in case of compressed mode with double frame gap and UE using non-real-time packet-switched data service.


When the single frame method is used, the position of the transmission gap within the compressed frame is controlled with the Gap position single frame (GapPositionSingleFrame)RNP parameter. The parameter determines the starting slot of the transmission gap within the compressed frame. When the double frame method is used, the number of the transmission gap-starting slot is always eleven.

3.3 Synchronization of compressed mode gaps Both UE and BTS have to be aware of the timing of transmission gaps. Furthermore, transmission gaps have to be in the same time slot in uplink and downlink direction if both directions are compressed. However, uplink and downlink gaps do not overlap totally. There is a shift of 1024 chips between the uplink and the downlink gap. Non-over-lapping parts are in the beginning and in the end of the gap, which means that the effec-tive gap length is about 2048 chips shorter.

The synchronization of gapped frames is handled by the Transmission Gap Connection Frame Number (TGCFN). TGCFN is declared as integer with values from 0 to 255. Duration of one frame is 10 ms, thus one CFN cycle takes 2.56 seconds. The Connec-tion Frame Number (CFN) is calculated from the System Frame Number (SFN) and the frame offset which is measured by the UE for each cell participating in the soft handover.

If the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled, current CFN maintained by the Frame Protocol entity in SRNC is used during anchoring,

The TGCFN for the initial activation of compressed mode refers to future CFNs and can be adjusted by the offset parameter Offset for activation time (ActivationTimeOffset) and the quantity TRRC. These parameters define how many ms (frames) is the time delay to start compressed mode or some other action:

TGCFN = (CFN + MIN(ActivationTimeOffset + TRRC, 2200)/10) mod 256

For more information on TRRC see Section Activation time for synchronized radio bearer procedures in "WCDMA RAN RRM Admission Control".

DN03471612 49



For example the CFN counter has the value 100 and the CFN offset parameters’ sum is 1000 ms at the time the start of compressed mode is decided. Compressed mode starts in the radio path when the CFN counter reaches 200 and the TGCFN parameter indi-cates 200. When a soft handover link for the UE is added, the existing link(s) in the UE context have a particular Transmission Gap Pattern Sequence active and the Transmis-sion Gap Pattern Sequence (TGPS) needs to be synchronized. The RNC sets the Transmission Gap Connection Frame Number (TGCFN) so that the Transmission Gap Pattern Sequence is started at the same time as in the existing radio links of the active set.

At first the number of frames is determined for which compressed mode has lasted in this RRC connection at the time when compressed mode for the new soft handover link is planned to be started. The RNC starts compressed mode one frame before the current CFN, that is the passed CFN value ((CFNcurrent -1 + 256) mod 256). The CFN is not sufficient to evaluate the duration of compressed mode, because compressed mode can take several CFN cycles. RRM requests the SFN from the frame protocol and cal-culates the CFN by using the SFN and the Frame Offset. The SFN has values between 0 and 4095. Therefore one SFN cycle takes 40.96 seconds. It is assumed that com-pressed mode does not take more than one SFN cycle.

One of the cells in the active set is selected as a reference cell for the duration of com-pressed mode even if the active set is updated such that the reference cell does not belong to the active set anymore. The RNC stores the frame offset of this reference cell to be able to calculate the current CFN of this individual RRC connection.

If the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled, any of the currently active cells under the SRNC can be used as reference cell during anchoring as there are no active set cells under the SRNC during anchoring.

Finally the Transmission Gap Connection Frame Number (TGCFN) for the new soft handover radio link is determined.

When compressed mode changes from HSDPA compressed mode to DCH compressed mode or vice versa, data for the reconfiguration procedure and for starting the new transmission gap pattern are set so that they all point to the next frame after the last frame of the old transmission gap pattern.

3.4 Compressed mode for HSDPAHSDPA compressed mode can be activated for an UE if all of the following conditions are true:

• The HSDPA Inter-Frequency Handover feature is enabled for the RNC. • HSDPA mobility is enabled with RNC configuration parameter HSDPAMobility. • DCH compressed mode is enabled with the RNC-wide configuration parameter

CMmasterSwitch. • HSDPA compressed mode in the serving cell is enabled.

Handover control checks whether these conditions are true when HSDPA compressed mode is started for the first time in an UE after coming to CELL_DCH state. The result of this check remains effective for the UE as long as it stays in CELL_DCH state despite of possible changes in licence or parameters. For example if the state information of the licence 'HSDPA inter-frequency handover' changes from 'on' to 'off' or 'config' while HSDPA compressed mode is already established for an individual UE, compressed mode is not deactivated immediately but based on the next normal deactivation. HSDPA

50 DN03471612



Compressed mode

compressed mode will remain available for that UE as long as it stays in CELL_DCH state.

When HSDPA is configured in the UE, compressed mode is configured depending on UE measurement capability requirements. The RNC selects the compressed mode method for the DPCH as described below. The method selection algorithm cannot be controlled by any parameter:

• downlink compressed mode method • Halving the spreading factor method is used for the DPCH when HS-DSCH is

configured. The same method applies regardless of whether AMR services exist or not.

• uplink compressed mode method • Higher layer scheduling compressed mode method is used when HS-

DSCH/DCH (DL/UL) is configured, the total sum bit rate of all uplink NRT DCHs is greater than 128 kbps with or without AMR, and no RT PS DCH is configured.

• Halving the spreading factor method is used when HS-DSCH/DCH is config-ured, the total sum bit rate of all uplink NRT DCHs is less than or equal to 128 kbps with or without AMR, and no RT PS DCH is configured.

• If compressed mode is triggered in a situation when minimum uplink SF=4 and RT PS DCH is configured for the RRC connection, all NRT DCHs are released and immediately after that halving the spreading factor method is used in both uplink and downlink.

• Otherwise, halving the spreading factor method is used when HS-DSCH/DCH is configured.

Compressed mode pattern for HSDPA equal in principle with the ones that are used for DCH.

The following HSDPA specific parameters need to be specified:

• TGPL for HSDPA and IF measurement (TGPLHSDPAInterFreq) parameter defines the length of the transmission gap pattern for WCDMA inter-frequency mea-surement in case of HSDPA compressed mode with single frame gap.

• TGPL for AMR and HSDPA and IF measurement (TGPLAMRHSDPAInterFreq) parameter defines the length of the transmission gap pattern for WCDMA inter-fre-quency measurement in case of AMR and HSDPA compressed mode with single frame gap.

• A single frame method is used in HSDPA compressed mode. Gap position single frame (GapPositionSingleFrame) parameter determines the starting slot number of the transmission gap inside a frame in case of single frame compressed mode.

• Recovery Period Power in UL Compressed Mode (UpLinkRecoveryPeriodPowerMode) parameter defines the mode of the uplink power control algorithm and the uplink power step size after each transmission gap (within the compressed frames) during the recovery period. The recovery period length is the minimum value of the transmission gap length and 7 slots.

• Initial transmit power in uplink compressed mode (UpLinkInitialTransmitPowerMode) The uplink DPCCH power for the first slot after the transmission gap is calculated by using the latest transmitted uplink DPCCH power value and Δ PILOT. This parameter determines whether the TPC command sent in response to the last pilot bits transmitted prior to the transmission gap is applied to uplink DPCCH power calculation.

DN03471612 51



• Alternative scrambling code can be used for DPCH only. Compressed Mode: Alter-native scrambling code (AltScramblingCodeCM) parameter defines whether the alternative scrambling code is allowed to be used in case of compressed mode method halving the spreading factor.


While compressed mode is active, HSDPA (HS-DSCH/DCH) can be allocated, released or reconfigured as follows:

• Allocation can be triggered based on capacity requests or because of channel type switch criteria.

• Release or reconfiguration as DCH/DCH x/x kbps configuration is allowed because of any reason.

During the allocation, release or reconfiguration, compressed mode is modified based on corresponding DCH compressed mode parameters. Compressed mode is stopped if the release of the HSDPA results in an RRC connection ends with an SRB only, that is DCH/DCH 0/0 kbps configuration. The DCH uplink channel of an HS-DSCH/DCH con-figuration can be reconfigured while HSPA compressed mode is active. Inter-frequency handover measurements itself continue without changes when compressed mode changes from HSDPA compressed mode to DCH compressed mode or vice versa.

HSPA (HS-DSCH/E-DCH) is not allocated while compressed mode is active. PS RABs can be reconfigured during HSDPA compressed mode and the reconfiguration of SPI because of PS RAB reconfiguration is supported.

3.5 Restrictions because of cell capacityCompressed mode has an effect on the cell capacity, coverage and quality because both the UE and the BTS tend to increase their transmission power for compressed frames. To keep this problem in check, it is possible to limit the number of UEs in com-pressed mode on a cell-by-cell basis:

• critical HO reasons:The MaxNumberUECmHO RNP parameter determines the maximum number of UEs that can be in compressed mode at the same time within the cell because of quality, coverage, directed emergency call or immediate IMSI based handover reasons

• best effort HO reasons:The MaxNumberUECmSLHO RNP parameter determines the maximum number of UEs that can be in compressed mode at the same time within the cell because of service or load based handover reasons.

If the number of UEs in compressed mode has already reached the allowed maximum, the RNC does not activate compressed mode even if it is needed. As concerns soft han-dover, the number of UEs in compressed mode must be below the maximum limit in all cells participating in soft handover before the RNC can activate compressed mode. Once compressed mode has been activated, to secure the mobility of the UEs, it is possible to add a new cell (soft handover branch) into the active set even though the number of UEs in compressed mode in the cell in question should exceed the maximum.

Compressed mode measurements because of load reasons have a higher priority than measurements because of service reasons. Also, quality and coverage reason han-dovers can steal capacity from this amount of UEs in compressed mode if needed.

52 DN03471612



Compressed mode

Note that in the event of compressed mode because of directed emergency call based handover, the value of the RNP parameter Maximum number of UEs in CM because of critical HO measurement (MaxNumberUECmHO) can be exceeded. However, the UEs in compressed mode are calculated in the Number of UEs in compressed mode simul-taneously in one cell.

For an individual cell, the maximum number of UEs with HS-DSCH/DCH allocated that are simultaneously in compressed mode is limited with the RNP parameters MaxNumberUEHSPACmHO and MaxNumberUEHSPACmNCHO. Former one is for critical handover reasons and latter one for non-critical handover reasons. Critical handover reasons can use capacity from non-critical ones if needed. New UEs do not enter to HSDPA compressed mode while the threshold is exceeded. Furthermore, UEs are not reconfigured from HSPA to HSDPA configuration or from HSPA/HSDPA to DCH config-uration if the start of compressed mode is required.

If a UE is in HSDPA compressed mode and a new soft handover branch is to be added, the maximum number of UEs in HSDPA compressed mode in a cell is temporarily allowed to be exceeded. However, all UEs in an individual cell that are in compressed mode are counted to the number of UEs in the corresponding compressed mode counter. The thresholds are checked once when compressed mode starts. The thresh-olds are not re-checked when DCH compressed mode is reconfigured as HSDPA com-pressed mode or vice versa.

The interference load of a cell is not taken into account for the decision on starting DCH or HSDPA compressed mode.

g The measurement capability IE of certain UEs can indicate that the CM is not needed, that is, the UEs have dual-receiver capability.

DN03471612 53

WCDMA RAN RRM Handover Control Macro diversity combining

Id:0900d8058074527bConfidential

4 Macro diversity combiningKeeping the UE connected to more than one BTS at one and the same time is a waste of system capacity since one connection is in principle enough. However, through a process called Macro Diversity Combining (MDC), the Radio Network Controller (RNC) is able to combine the signals that it receives from the UE through different BTSs. Inversely, the RNC can replicate the downlink signal and send it to the UE over more than one BTS.

Because the system has the ability to combine a number of uplink data streams in the RNC, the UE can use less transmission power, which reduces interference and, conse-quently, increases capacity. This reduction of interference outweighs the capacity wasted by maintaining several radio links for the UE. MDC is the best way to enhance the subjective quality of a call in Wideband Code Division Multiple Access (WCDMA), as the UE is not allowed to simply increase its transmission power.

Unless a piece of transmitting equipment is equipped with a smart antenna system or some functional equivalent, the signals from it propagate omnidirectionally. Typically the radio signal has bounced off various obstacles in the radio path a number of times before it reaches the receiver. As a result the receiver is bombarded, over a very short time span, with a number of components of the same signal, called multipath compo-nents. These multipath components were all transmitted at the same instant, but trav-elled along different paths (of varying length) before reaching the receiver.

Multipath propagation may be beneficial or harmful, as the multipath components inter-fere with each other; sometimes the result is a strengthened signal, sometimes an atten-uated one. Graphically, the resultant, received signal contains a number of noticeable spikes. Because of the high frequencies and consequent short wavelengths used in WCDMA Radio Access Network (RAN), even the slightest displacement of the UE has a great effect on how the multipath components interfere with each other. Because of this, the signal often experiences so-called fast fading, that is, it is rapidly attenuated only to bounce back an instant later.

To be able to process the signal under these circumstances, the network has to be capable of tracking the fast fading profile of the signal and adjusting the transmission power to compensate. Also, it is a great advantage if the same signal can be picked up by a number of receivers, as this increases the likelihood of a continuous, even quality. In WCDMA RAN, this is exactly what is done with a process known as macro diversity combining.

At face value, multipath propagation, and the consequent unreliable signal strength, would seem to be a big problem. However, with the help of advanced digital signal pro-cessing WCDMA RAN takes what logically seems like a major obstacle and turns it into an advantage. Because it knows the scrambling code, the WCDMA receiver can separate the multipath components over a brief period of time, and compare the com-ponents to each other. The only requirement is that the components are offset by at least one chip when received.

Since the chip rate is fixed at 3.84Mchips/second in WCDMA RAN, the length of one chip is always 78 meters (speed of light / chip rate). So, provided that the radio path of one multipath component - or branch - is 78 m or more longer than that of another mul-tipath component, the receiver can distinguish the two components as separate signals.

Before the UE transmits any data it has to be split into transport blocks (TB), each of which receives cyclic redundancy check (CRC) error coding. The transport blocks, in turn, become part of a frame, the size of which depends on the interleaving length used.

54 DN03471612



Macro diversity combining

Each frame is tagged with a connection frame number (CFN). In Figure 14 Macro diver-sity combining, three BTSs receive the signal sent by the UE. Each of these BTSs sep-arately estimates the quality of the signal that it has received; the WCDMA checks the CRC for each transport block and determines whether the data in the transport block is reliable or not. Next it makes a quality estimate (QE) for the whole frame, based on the BER of the transport channel.

If more than one transport block passes the CRC check, the one belonging to the frame with the highest quality estimate is selected. If two transport blocks prove to be equally good one of them is selected randomly. If none of the transport blocks is OK, the one with the lowest BER is selected. Thus, it is possible, on a transport block-by-transport block basis, to select the best signal.

In the macro diversity point in the following figure, for example, the signal from the UE is collected from three base stations and two RNCs. Thus, the Serving Radio Network Controller (SRNC) receives Iub and Iur Dedicated Traffic Channel (DCH) data streams coming from different BTSs and combines them. After the SRNC there is only one uplink DCH data stream. Similarly, the DCH data stream is split towards the BTSs in the down-link; the signal is transmitted to the UE from three base stations. The UE performs macro diversity combining on the downlink DCH data streams.

Because of the high frequency used, WCDMA signals vary constantly. If the UE was allowed to connect only to one BTS at a time the quality of the signal would fluctuate constantly. Because the UE can be, and typically is, connected to two or more BTSs, there is a much greater chance that at least one of the BTS receives a signal of adequate quality at any one time. Likewise, in the downlink direction, the UE can choose the best of a number of signals. In the uplink and downlink direction alike the choice typically varies many times per second.

DN03471612 55

WCDMA RAN RRM Handover Control Macro diversity combining


Figure 14 Macro diversity combining

Thanks to macro diversity combining, less transmission power can be used, both in the uplink and the downlink. This is directly related to the inherent fluctuating signal strength, which makes the signal equally likely to be strong or weak. Since the signal is received by two or more BTSs, the same signal travels along different paths yielding completely different signal strengths from one BTS to the next.

Consider the scenario exemplified by Figure 15 Handover scenario: branch addition rejected: At time T1 the UE is connected to BTS10, BTS11 and BTS14. The UE proceeds to a new location and at T2 finds itself within range of BTS5, BTS2 and BTS1, of which BTS5 is temporarily overloaded. The strength of the pilot signals from BTS5, BTS2 and BTS1, as measured by the UE, indicates that BTS5 provides the best signal. The UE relays the measurement results to the RNC which initiates a branch addition request (for BTS5). Because of the heavy load in the cell admission control rejects the request and the RRC connection of the UE is dropped.

CFN=3QE=5

TB CRC = NOK

TB CRC = OK

TB CRC = NOK

TB CRC = OK

BTS1

CFN=3QE=4

TB CRC = NOK

TB CRC = OK

TB CRC = NOK

TB CRC = NOK

BTS2

CFN=3QE=4

TB CRC = NOK

TB CRC = NOK

TB CRC = OK

TB CRC = NOK

BTS3

ActiveSet

BTS1

BTS2

BTS3

RNC

RNC

Macro DiversityPoint

CoreNetwork

56 DN03471612




The reason for this is that, if the UE had been allowed to connect to BTS5, it could have decreased its transmission power and consequently the amount of interference produced by it. Likewise, if the UE were allowed to connect to the second-best candi-dates, BTS1 and BTS2 in this case, BTS1 and BTS2 would have to transmit with unnec-essarily high power levels. Lastly, the abnormally high transmission powers used in such a situation would further deteriorate the situation in cell BTS5. For this reason the UE possibly never be connected to the second-best BTS.

Figure 15 Handover scenario: branch addition rejected

Dropping an RRC connection because of momentary overload is a drastic solution and is, because of the design of radio resource management, a rare event in WCDMA RAN. An RRC connection is dropped only once all other possibilities have been exhausted. The number of possibilities at the network's disposal depends largely on the quality requirements of the service in question and on the network configuration at the particular place where the UE is located. One solution is to hand the connection over to another carrier frequency or radio access technology (for example GSM).

Optimum cell selection, together with fast closed loop power control, guarantees that the network elements use the lowest possible transmission power at all times, thus reducing the amount of interference in the network. This in turn impacts on the quality, capacity and coverage that the network can offer.

For a more technical description of the macro diversity combining, see Section Signal processing in RNC.

BTS1 BTS2

BTS5 BTS6 BTS7

BTS9 BTS10 BTS11

BTS13 BTS14

Active set:BTS1, 2 - branch to BTS5 rejected

Active set:BTS10, 11 and 14

DN03471612 57

WCDMA RAN RRM Handover Control WCDMA frequency bands

Id:0900d80580745100Confidential

5 WCDMA frequency bandsThe supported FDD frequency bands are WCDMA 2100 (RF band I), WCDMA 1900 (RF band II), WCDMA 1800 (RF band III), WCDMA 1700/2100 (RF band IV), WCDMA 850 (RF band V), WCDMA 800 (RF band VI), WCDMA 2600 (RF band VII), WCDMA 900 (RF band VIII), and WCDMA 1700 (RF band IX), Extended WCDMA 1700/2100 (RF band X), WCDMA 1500 (RF band XI), WCDMA 730 (RF band XII), WCDMA 750(RF band XIII), and WCDMA 760 (RF band XIV). All fourteen frequency bands support the same features.

The RF band I for WCDMA 2100 is the following:

• Uplink: 1920 MHz – 1980 MHz, UARFCN 9612 – 9888 • Downlink: 2110 MHz – 2170 MHz, UARFCN 10562 – 10838 • Duplex distance: 190 MHz

The RF band II for WCDMA 1900 is the following:

• Uplink: 1850 MHz – 1910 MHz, UARFCN 9262 – 9538 and additional channels 12, 37, 62, 87, 112, 137, 162, 187, 212, 237, 262, 287

• Downlink: 1930 MHz – 1990 MHz, UARFCN 9662 – 9938 and additional channels 412, 437, 462, 487, 512, 537, 562, 587, 612, 637, 662, 687

• Duplex distance: 80 MHz.

The RF band III for WCDMA 1800 is the following:


The RF band IV for WCDMA 1700/2100 is the following:

• Uplink: 1710 MHz – 1755 MHz, UARFCN 1312 – 1513 and additional channels 1662, 1687, 1712, 1737, 1762, 1787, 1812, 1837, 1862

• Downlink: 2110 MHz – 2155 MHz, UARFCN 1537 – 1738 and additional channels 1887, 1912, 1937, 1962, 1987, 2012, 2037, 2062, 2087

• Duplex distance: 400 MHz

The RF band V for WCDMA 850 is the following:

• Uplink: 824 MHz - 849 MHz, UARFCN 4132 - 4233 and additional channels 782, 787, 807, 812, 837, 862

• Downlink: 869 MHz - 894 MHz, UARFCN 4357 - 4458 and additional channels 1007, 1012, 1032, 1037, 1062, 1087

• Duplex distance: 45 MHz.

The RF band VI for WCDMA 800 is the following:

• Uplink: 830 MHz - 840 MHz, UARFCN 4162 - 4188 and additional channels 812, 837.

• Downlink: 875 MHz - 885 MHz, UARFCN 4387 - 4413 and additional channels 1037, 1062.

• Duplex distance 45 MHz.

The RF band VII for WCDMA 2600 is the following:

• Uplink: 2500 MHz - 2570 MHz, UARFCN 2012 - 2338 and additional channels 2362, 2387, 2412, 2437, 2462, 2487, 2512, 2537, 2562, 2587, 2612, 2637, 2662, 2687.

58 DN03471612



WCDMA frequency bands

• Downlink: 2620 MHz - 2690 MHz, UARFCN 2237 - 2563 and additional channels 2587, 2612, 2637, 2662, 2687, 2712, 2737, 2762, 2787, 2812, 2837, 2862, 2887, 2912.


The RF band VIII for WCDMA 900 is the following:


The RF band IX for WCDMA 1700 is the following:

• Uplink: 1749.9 MHz – 1784.9 MHz, UARFCN 8762 – 8912 • Downlink: 1844.9 MHz – 1879.9 MHz, UARFCN 9237 – 9387 • Duplex distance: 95 MHz

The RF band X for Extended WCDMA 1700/2100 is the following:

• Uplink: 1710 MHz – 1770 MHz, UARFCN 2887 – 3163 and additional channels 3187, 3212, 3237, 3262, 3287, 3312, 3337, 3362, 3387, 3412, 3437, 3462.

• Downlink: 2110 MHz – 2170 MHz, UARFCN 3112 – 3388 and additional channels 3412, 3437, 3462, 3487, 3512, 3537, 3562, 3587, 3612, 3637, 3662, 3687.

• Duplex distance: 400MHz

The RF band XI for WCDMA 1500 is the following:

• Uplink: 1427.9 MHz – 1452.9 MHz, UARFCN 3487 – 3587. • Downlink: 1475.9 MHz – 1500.9 MHz, UARFCN 3712 – 3812. • Duplex distance: 48MHz

The RF band XII for WCDMA 730 is the following:

• Uplink: 698 MHz – 716 MHz, UARFCN 3612 – 3678 and additional channels 3702, 3707, 3732, 3737, 3762, 3767.

• Downlink: 728 MHz – 746 MHz, UARFCN 3837 – 3903 and additional channels 3927, 3932, 3957, 3962, 3987, 3992.


The RF band XIII for WCDMA 750 is the following:

• Uplink: 777 MHz – 787 MHz, UARFCN 3792 – 3818 and additional channels 3842, 3867.

• Downlink: 746 MHz – 756 MHz, UARFCN 4017 – 4043 and additional channels 4067, 4092.


The RF band XIV for WCDMA 760 is the following:

• Uplink: 788 MHz – 798 MHz, UARFCN 3892 – 3918 and additional channels 3942, 3967.

• Downlink: 758 MHz – 768 MHz, UARFCN 4117 – 4143 and additional channels 4167, 4192.


The normal channel raster is 200 kHz, which means that in bands I, III, VIII, IX, and XI the center frequency must be an integer multiple of 200 kHz. In bands II, IV, V, VI, VII, X, XII, XIII, and XIV, the normal channel raster can be used, but also additional centre frequencies are specified and the centre frequencies for these channels are shifted 100

DN03471612 59



kHz in relation to the normal raster. Table UTRA absolute radio frequency channel numbers defined by 3GPP below introduces the channel numbering space according to the centre frequency of the carriers in bands I, II, III, IV, V, VI, VII, VIII, IX, X, XI, XII, XIII, and XIV. These channel numbers are defined by 3GPP. The allowed channel numbers in US WCDMA 1900, band II, are a subset of these see UARFCN parameter description in WCDMA Radio Network Configuration Parameters.

Table Allowed channel numbers of US WCDMA 1900 in band II below introduces the allowed channel numbers in each frequency block of US WCDMA 1900 in frequency band II.

Frequency band Uplink UE transmit, BTS receive

Downlink UE receive, BTS transmit

RF band I 9612 to 9888 10562 to 10838

RF band II 9262 to 9538 and additional channels 12, 37, 62, 87, 112, 137, 162, 187, 212, 237, 262, 287

9662 to 9938 and additional channels 412, 437, 462, 487, 512, 537, 562, 587, 612, 637, 662, 687

RF band III 937 to 1288 1162 to 1513

RF band IV 1312 to 1513 and additional channels 1662, 1687, 1712, 1737, 1762, 1787, 1812, 1837, 1862

1537 to 1738 and additional channels 1887, 1912, 1937, 1962, 1987, 2012, 2037, 2062, 2087

RF band V 4132 to 4233 and additional channels782, 787, 807, 812, 837, 862

4357 to 4458 and additional channels1007, 1012, 1032, 1037, 1062, 1087

RF band VI 4162 to 4188 and additional channels 812, 837

4387 to 4413 and additional channels 1037, 1062

RF ban VII 2012 to 2338 and additional channels 2362, 2387, 2412, 2437, 2462, 2487, 2512, 2537, 2562, 2587, 2612, 2637, 2662, 2687

2237 to 2563 and additional channels 2587, 2612, 2637, 2662, 2687, 2712, 2737, 2762, 2787, 2812, 2837, 2862, 2887, 2912

RF band VIII 2712 to 2863 2937 to 3088

RF band IX 8762 to 8912 9237 to 9387

RF band X 2887 to 3163 and additional channels 3187, 3212, 3237, 3262, 3287, 3312, 3337, 3362, 3387, 3412, 3437, 3462

3112 to 3388 and additional channels 3412, 3437, 3462, 3487, 3512, 3537, 3562, 3587, 3612, 3637, 3662, 3687

RF band XI 3487 to 3587 3712 to 3812

RF band XII 3612 to 3678 and additional channels 3702, 3707, 3732, 3737, 3762, 3767

3837 to 3903 and additional channels 3927, 3932, 3957, 3962, 3987, 3992

RF band XIII 3792 to 3818 and additional channels 3842, 3867


RF band XIV 3892 to 3918 and additional channels 3942, 3967


Table 4 UTRA absolute radio frequency channel numbers defined by 3GPP

60 DN03471612




The UARFCN parameter defines the downlink channel number and the carrier fre-quency of the serving cell, and the AdjiUARFCN parameter defines the downlink channel number and the carrier frequency of the inter-frequency neighbor cell.

The relation between the UARFCN and the corresponding carrier frequency [MHz] in the RF bands I, II, III, IV, V, VI, VII, VIII, IX, X, XI, XII, XIII, XIV is defined in the following way:

Uplink: NU = 5 * (FUL – FUL_Offset), for the carrier frequency range FUL_low ≤ FUL ≤ FUL_high

Downlink: ND = 5 * (FDL – FDL_Offset), for the carrier frequency range FDL_low ≤ FDL ≤ FDL_high

For each operating band, FUL_Offset, FUL_low, FUL_high, FDL_Offset, FDL_low, and FDL_high are defined in Table UARFCN definition (general) below for the normal 200 kHz channel raster. For the additional UARFCN, FUL_Offset, FDL_Offset and the specific FUL and FDL are defined in Table 7 UARFCN definition (additional channels) .

Uplink Downlink

Block

Frequency Allowed channel numbers

Frequency Allowed channel numbers

A 1850 - 1865 9263 - 9312, 12, 37, 62 1930 - 1945 9663 - 9712, 412, 437, 462

B 1870 - 1885 9363 - 9412, 112, 137, 162

1950 - 1965 9763 - 9812, 512, 537, 562

C 1895 - 1910 9488 - 9537, 237, 262, 287

1975 - 1990 9888 - 9937, 637, 662, 687

D 1865 - 1870 87 1945 - 1950 487

E 1885 - 1890 187 1965 - 1970 587

F 1890 - 1895 212 1970 - 1975 612

Table 5 Allowed channel numbers of US WCDMA 1900 in band II

Band

UPLINK (UL)UE transmit, Node B receive

DOWNLINK (DL)UE receive, Node B transmit

UARFCN formula offset FUL_Offset [MHz]

Carrier frequency (FUL) range [MHz]

UARFCN formula offset FDL_Offset [MHz]

Carrier frequency (FDL) range [MHz]

FUL_low FUL_high FDL_low FDL_high

I 0 1922.4 1977.6 0 2112.4 2167.6

II 0 1852.4 1907.6 0 1932.4 1987.6

III 1525 1712.4 1782.6 1575 1807.4 1877.6

IV 1450 1712.4 1752.6 1805 2112.4 2152.6

V 0 826.4 846.6 0 871.4 891.6

VI 0 832.4 837.4 0 877.4 882.6

VII 2100 2502.4 2567.6 2175 2622.4 2687.6

Table 6 UARFCN definition (general)

DN03471612 61



VIII 340 882.4 912.6 340 927.4 957.6

IX 0 1752.4 1782.4 0 1847.4 1877.4

X 1135 1712.4 1767.6 1490 2112.4 2167.6

XI 733 1430.4 1450.4 736 1478.4 1498.4

XII -22 700.4 713.6 -37 730.4 743.6

XIII 21 779.4 784.6 -55 748.4 753.6

XIV 12 790.4 795.6 -63 760.4 765.6

Band UPLINK (UL)UE transmit, Node B receive



Carrier frequency [MHz] (FUL) UARFCN formula offset FDL_Offset [MHz]

Carrier frequency [MHz] (FDL)

II 1850.1 1852.5, 1857.5, 1862.5, 1867.5, 1872.5, 1877.5, 1882.5, 1887.5, 1892.5, 1897.5, 1902.5, 1907.5

1850.1 1932.5, 1937.5, 1942.5, 1947.5, 1952.5, 1957.5, 1962.5, 1967.5, 1972.5, 1977.5, 1982.5, 1987.5

IV 1380.1 1712.5, 1717.5, 1722.5, 1727.5, 1732.5, 1737.5, 1742.5, 1747.5, 1752.5

1735.1 2112.5, 2117.5, 2122.5, 2127.5, 2132.5, 2137.5, 2142.5, 2147.5, 2152.5

V 670.1 826.5, 827.5, 831.5, 832.5, 837.5, 842.5

670.1 871.5, 872.5, 876.5, 877.5, 882.5, 887.5

VI 670.1 832.5, 837.5 670.1 877.5, 882.5

VII 2030.1 2502.5, 2507.5, 2512.5, 2517.5, 2522.5, 2527.5, 2532.5, 2537.5, 2542.5, 2547.5, 2552.5, 2557.5, 2562.5, 2567.5

2105.. 2622.5, 2627.5, 2632.5, 2637.5, 2642.5, 2647.5, 2652.5, 2657.5, 2662.5, 2667.5, 2672.5, 2677.5, 2682,5, 2687.5

X 1075.1 1712.5, 1717.5, 1722.5, 1727.5, 1732.5, 1737.5, 1742.5, 1747.5, 1752.5, 1757.5, 1762.5, 1767.5

1430.1 2112.5, 2117.5, 2122.5, 2127.5, 2132.5, 2137.5, 2142.5, 2147.5, 2152.5, 2157.5, 2162.5, 2167.5

XII -39.9 700.5, 701.5, 706.5, 707.5, 712.5, 713.5

-54.9 730.5, 731.5, 736.5, 737.5, 742.5, 743.5

XIII 11.1 779.5, 784.5 -64.9 748.5, 753.5

Table 7 UARFCN definition (additional channels)

Band

UPLINK (UL)UE transmit, Node B receive



Carrier frequency (FUL) range [MHz]

UARFCN formula offset FDL_Offset [MHz]

Carrier frequency (FDL) range [MHz]

FUL_low FUL_high FDL_low FDL_high

Table 6 UARFCN definition (general) (Cont.)

62 DN03471612




The RNC derives the uplink carrier frequency from the downlink carrier frequency and the duplex distance. The duplex distance is 190 MHz in frequency band I, 80 MHz in fre-quency band II, 95 MHz in frequency band III, 400 MHz in frequency band IV, 45 MHz in frequency band V, 45 MHz in frequency band VI, 120 MHz in frequency band VII, 45 MHz in frequency band VIII, 95 MHz in frequency band IX, 400 MHz in frequency band X, 48 MHz in frequency band XI, 30 MHz in frequency band XII, 31 MHz in frequency band XIII and 30 MHz in frequency band XIV.

The RNC supports inter-frequency handovers between all WCDMA FDD frequency bands. Inter-system handovers between any WCDMA FDD frequency band and GSM/EDGE band/network are supported.

The RNC requests information from the UE about the WCDMA FDD frequency bands and the GSM frequency bands which the UE supports.

The RNC checks that the UE supports the FDD frequency band, which is used in an inter-frequency neighbor cell before it can select the cell into the neighbor cell list which is transmitted to the UE for inter-frequency measurements. Similarly, the RNC checks that the UE supports the GSM frequency band, which is used in a GSM neighbor cell before it can select the cell into the neighbor cell list which is transmitted to the UE for inter-system measurements.

XIV 2.1 790.5, 795.5 -72.9 760.5, 765.5

Band UPLINK (UL)UE transmit, Node B receive



Carrier frequency [MHz] (FUL) UARFCN formula offset FDL_Offset [MHz]

Carrier frequency [MHz] (FDL)

Table 7 UARFCN definition (additional channels) (Cont.)

DN03471612 63

WCDMA RAN RRM Handover Control Directed RRC connection setup

Id:0900d80580749b8fConfidential

6 Directed RRC connection setupDirected RRC connection setup is a general feature in the RAN. Directed RRC connec-tion setup provides an efficient way to balance load between two (or more) carrier fre-quencies within one base station. The RNC balances the load by establishing the RRC connection on the carrier frequency (cell) which has less load.

The prerequisite for the directed RRC connection setup procedure is that the cells involved belong to the same sector of the base station. The Sector Identifier (SectorID) parameter uniquely identifies the sector of the base station a cell belongs to. Two (or more) cells can belong to the same sector if they have equal coverage areas. The coverage areas can be considered as equal if the cells have identical values for the fol-lowing parameters (the RNC is not able to check whether the antenna beams of the cells are directed equally):

• Transmission power of the primary CPICH channel (PtxPrimaryCPICH ) • Offset of the P-CPICH and reference service powers (CPICHtoRefRABoffset) • PLMN code (MCC + MNC)

Cell sectors are considered to be identical if one of the following condition is true:

• The PLMN list of the target cell contains at least all PLMN identities which are defined in the PLMN list of the source cell.

• One PLMN identity in the PLMN list of the target cell is equal to the Common PLMN Id.

The PLMN list is specified as the exclusive sum of the PLMN identities defined in the Common PLMN Id and Multiple PLMN List. The order of the PLMN identities in the lists is not taken into account. The PLMN list may include only one PLMN identity.

The Common PLMN Id is composed of CommonMCC, CommonMNC, and Common-MNCLength parameters.

The Multiple PLMN List is composed of the operator’s PLMNids which are defined in IuOperator parameter structure.

For a description of the parameters, see WCDMA Radio Network Configuration Param-eters.

The UE initiates the RRC connection setup procedure in the cell on which it camped in idle mode (that is, source cell). The RNC can direct the RRC connection setup request to another (target) cell within the same sector if the target cell has less load than the source cell. The decision procedure is controlled with the following parameters:

• Prx Offset for DRRC (DRRCprxOffset) parameter determines the threshold level which the total received wideband interference power (uplink load) in the source cell must exceed before the RNC may direct the RRC connection setup to another cell within the sector.

• Ptx Offset for DRRC (DRRCptxOffset) parameter determines the threshold level which the total transmitted power (downlink load) in the source cell must exceed before the RNC can direct the RRC connection setup to another cell within the sector.

• Prx Margin for DRRC (DRRCprxMargin) parameter determines the margin by which the uplink load of the source cell must exceed the uplink load of the target cell before the RNC can direct the RRC connection setup to the target cell.

64 DN03471612



Directed RRC connection setup

• Ptx Margin for DRRC (DRRCptxMargin) parameter determines the margin by which the downlink load of the source cell must exceed the downlink load of the target cell before the RNC can direct the RRC connection setup to the target cell.

In addition to the received wideband interference, the uplink load is also measured in the DCH throughput domain. RNC maintains in each cell the Uplink DCH own cell load factor LDCH,CELL of the DCH users; how to produce the value of the LDCH,CELL see Section Estimations for the received throughput and interference in "WCDMA RAN RRM Admis-sion Control". The value of the load factor in the target cell(n) is denoted with LDCH,CELL (n).

A particular uplink DCH own- cell load threshold LDRRC is defined in the throughput domain for the needs of the DRRC with the equation

Figure 16 Definition of uplink DCH own-cell load threshold LDRRC

Quantity Ptarget+DRRC is the linear value of the sum of the dB-values of the PrxTarget and DRRCprxOffset management parameters. Uplink own cell DCH threshold LDRCC(n) is defined with the similar equation in the target cell(n).

LminDCH is the planned minimum uplink DCH own cell load factor; its value is defined with Section Interference margin for the minimum UL DCH load (PrxLoadMarginDCH) man-agement parameter. For more information, see the Estimations for the received through-put and interference in "WCDMA RAN RRM Admission Control". The CRNC is allowed to allocate the uplink DCH resources up to this throughput limit without considering the received wideband interference. LminDCH(n) denotes the value of the threshold in the target cell(n).

If there are PS streaming or CS voice users on HSUPA in the cell, the load factor LDCH,CELL of the UL conditions is replaced by the load factor LCELL:

LCELL = LDCH,CELL + LncEDCH,CELL + LstrEDCH,CELL

LDCH,CELL is the own cell load factor of the DCH users, for more information see WCDMA RAN RRM Admission Control.

The two quantities LncEDCH,CELL(t) and LstrEDCH,CELL(t) are introduced in WCDMA RAN RRM HSUPA.

If there is PS streaming or CS voice users on HSDPA in the cell, Directed RRC connec-tion setup is performed in DL direction if one of the following conditions is true:

1. CurrentCellPtxnonHSPA > PtxTargetPSMax + DRRCptxOffset2. CurrentCellPtxnonHSPA + PtxNCHSDPA > PtxTargetTotMax + DRRCptxOffset3. CurrentCellPtxnonHSPA + PtxNCHSDPA + PtxSCHSDPA > Pmax + DRRCptxOff-

set

where:

• CurrentCellPtxnonHSPA(t) is the sample of the averaged non-HSPA transmission power (measurement).

• PtxTargetPSMax is the maximum allowed value for dynamically adjusted PtxTar-getPS threshold (RNP parameter).

• PtxTargetTotMax is the maximum allowed value for dynamically adjusted PtxTar-getTot threshold, for more details see WCDMA RAN RRM HSDPA.

LDRRC = MAX 0, MIN 1-1

Ptarget + DRRC

, LminDCH

DN03471612 65



• PtxNCHSDPA is the sample of power used by CS voice RBs mapped to HSDPA, for more details see WCDMA RAN RRM HSDPA.

• PtxSCHSDPA is the sample of power used by PS streaming RBs mapped to HSDPA, for more details see WCDMA RAN RRM HSDPA.

• Pmax is the maximum tx power of the cell. • DRRCptxOffset is a power offset (RNP parameter).

If DRRC has been triggered, PS streaming or CS voice users are on HSPA in the new cell and all of the following conditions are true, the other cell belonging to the same sector is selected for DRRC:

1. CurrentCellPtxnonHSPA – PtxTargetPSMax > CellPtxnonHSPA(n) – PtxTargetPS-Max(n) - DRRCptxOffset

2. CurrentCellPtxnonHSPA + CurrentCellPtxNCHSDPA - PtxTargetTotMax > CellPtx-nonHSPA(n) + PtxNCHSDPA(n) – PtxTargetTotMax(n) - DRRCptxOffset

3. CurrentCellPtxnonHSPA + CurrentCellPtxNCHSDPA + CurrentCellPtxSCHSDPA - PtxCellMax > CellPtxnonHSPA(n) + CellPtxNCHSDPA(n) + CellPtxSCHSDPA(n) – PtxCellMax(n) - DRRCptxOffset

The RNC uses also a planned maximum uplink DCH own cell load factor LmaxDCH in its uplink DCH resource allocation. The value of the load factor LDCH,CELL does not exceed the value of LmaxDCH. Interference margin for the maximum UL DCH load (PrxLoadMar-ginMaxDCH) management parameter defines the value of defines the value of LmaxDCH . For more information, see Section Estimations for the received throughput and inter-ference in "WCDMA RAN RRM Admission Control". The value of the threshold in the target cell(n) is denoted with LmaxDCH(n)

When either the uplink load or the downlink load in the source cell exceeds the relevant threshold level, as defined by the following equations, the RNC examines the difference in loading between the source cell and the target cell (or cells):

(1) SourceCellPrxTotal > PrxTarget + DRRCprxOffset AND LDCH,CELL > LDRRC

(2) SourceCellPtxTotal > PtxTarget + DRRCptxOffset

(3) LDCH,CELL > LmaxDCH · lin(DRRCprxOffset)

Quantity lin(DRRCprxOffset) is the value of the DRRCprxOffset parameter in the linear notation.

The RNC examines the differences in loading between the source cell and the target cell(n) by means of the following conditions:

(A) [SourceCellPrxTotal - PrxTarget > TargetCellPrxTotal(n) - PrxTarget(n) - DRRCprx-Margin(n)] OR [LDCH,CELL(n) < LDRRC(n)]

(B) SourceCellPtxTotal - PtxTarget > TargetCellPtxTotal(n) - PtxTarget(n) - DRRCptx-Margin(n)

(C) LDCH,CELL/LmaxDCH > LDCH,CELL(n) / LmaxDCH(n)·lin(DRRCprxMargin(n))

(D) [(TargetCellPrxTotal(n) < PrxTarget(n) + DRRCprxOffset(n)) OR (LDCH,CELL (n) ≤ LDRRC(n))] AND [LDCH,CELL(n) < LmaxDCH(n)·lin(DRRCprxMargin(n))]

(E) TargetCellPtxTotal(n) < PtxTarget(n) + DRRCptxOffset(n)

The measurement results in the equations are defined as follows:

• SourceCellPrxTotal is the total received wideband interference power in the source cell.

• SourceCellPtxTotal is the total transmitted power in the source cell.

66 DN03471612




• TargetCellPrxTotal(n) is the total received wideband interference power in the target cell(n).

• TargetCellPtxTotal(n) is the total transmitted power in the target cell(n).

Quantity lin(DRRCptxMargin) is the value of the DRRCptxMargin parameter in the linear notation.

Cell(n), which belongs to the same sector as the source cell, can be taken as the target cell of the DRRC attempt, if the equations (A), (B), (C), (D), and (E) are satisfied as described in the table below. Column CHECK IN TARGET CELL(n) of the table shows what must be checked. Checkings are done depending on the triggers conditions (1) , (2), and (3). Target cell check aims at preventing the source cell become the new target cell of the target cell(n) in DRRC.

TRUE means that the condition is true, FALSE means that the condition is not true, '-' means that the condition is not applicable.

If the target cell(n) passes the checkings, the RRC connection is established in the target cell(n) if the admission decision is successful in it. If none of the cells which belong to the same sector as the current cell satisfy the needed equations (A), (B), (C), (D) and (E) or the admission decision does not succeed in the target cell, RNC does the admis-sion decision in the source cell.

If there are HSDPA RT load in the cell, then new services can be rejected by several load targets. To get a picture of the cell load all those conditions must be checked.

When the HSUPA configuration has been set up in a cell as specified in WCDMA RAN RRM HSUPA, average PrxNonEDPCH value and PrxTargetPSMax, which is the maximum allowed value for dynamically adjusted Prx_target_PS threshold, is used instead of PrxTotal and PrxTarget in the load-based handover and Directed RRC connection setup algorithms. Production of PrxNonEDPCH and maximum threshold PrxTar-getPSMax are defined in WCDMA RAN RRM HSUPA.

Note that in the case of the dynamic sharing of the received interference between the HSPA and DCH users, if there is at least one E-DCH MAC-d flow established in the cell at issue, the non-E-DCH interference power PrxNonEDCH value is used in the cell instead of total received interference power PrxTotaI in the interference based deci-sions. Furthermore, the maximum value of the dynamic target threshold for uplink DCH packet scheduling, defined by the operator adjustable PrxTargetPSMax management

THRESHOLD EXCEEDED IN CURRENT CELL

CHECK IN TARGET CEL(n)

>UL thresh-old (1)

>DL thresh-old (2)

> load factor overload threshold (3)

>UL margin (A)

>DL margin (B)

>load factor margin (C)

<UL thresh-old (D)

<DL thresh-old (E)

TRUE FALSE FALSE TRUE - - - TRUE

FALSE FALSE TRUE - - TRUE TRUE TRUE

FALSE TRUE FALSE - TRUE - TRUE -

TRUE TRUE TRUE/FALSE TRUE TRUE - - -

FALSE TRUE TRUE - TRUE TRUE TRUE -

TRUE FALSE TRUE TRUE - TRUE - TRUE

Table 8 Triggers of DRRC and checkings in the target cell

DN03471612 67



parameter, is used as the interference threshold instead of the PrxTarget. For more information, see WCDMA RAN RRM HSUPA.

Note that in the case of HSDPA Dynamic Resource Allocation, if there is at least one HS-DSCH MAC-d flow allocated in the cell, non-HSPA transmitted power (Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmission) is used instead of total transmitted power. The maximum value of the dynamic target threshold for the downlink DCH packet scheduling, defined by the operator adjustable PtxTargetPSMax parameter, is used instead of PtxTarget. In the case of HSDPA Static Resource Allocation PtxTargetHSDPA and PtxOffsetHSDPA target levels are used instead of PtxTarget and PtxOffset.

If loading in the source cell do not exceed the relevant thresholds, or the difference in loading between the source cell and the target cell (or cells) is not sufficient, the RNC continues the RRC connection setup procedure in the source cell.

Figure 17 Principle of directed RRC connection setup

For more information, see Section Call setup and release in "WCDMA RAN call setup and release" and Section Radio resource management functions in "WCDMA RAN RRM Packet Scheduler".

UTRANUE

Cell1_load > Cell2_load + load_threshold===> Directed RRC connection setup

Frequency 1

Frequency 2

RRC CONNECTION REQUEST

RRC CONNECTION SETUP

RRC CONNECTION SETUP COMPLETE

68 DN03471612


Id:0900d805807e5d31Confidential

Directed RRC connection setup for HSDPA layer

7 Directed RRC connection setup for HSDPA layerDirected RRC connection setup for HSDPA layer feature is meant for multilayer networks where High Speed Downlink Packet Access (HSDPA) is supported in some layer(s) (carrier frequency). The primary target of this feature is to direct HSDPA capable UEs to the cell that supports HSDPA. On the other hand, non-HSDPA UE is removed from HSDPA layer(s). If several HSDPA capable layers exist, the HSDPA load balanc-ing between these layers is used.

Figure 18 Principles of directed RRC connection setup for HSDPA layer

The signaling flow is identical to the Directed RRC connection setup feature and it is pre-sented in Figure 19 Signaling of directed RRC connection setup for HSDPA layer. Like-wise, the prerequisite for the directed RRC connection setup for HSDPA layer is that the cells involved belong to the same sector of the base station. The SectorID parameter uniquely identifies the sector of the base station a cell belongs to. Two cells can belong to the same sector if they have equal coverage areas. The coverage areas can be con-sidered as equal if the cells have identical values for the following parameters (The RNC is not able to check whether the antenna beams of the cells are directed equally.):








f2, HSDPA + Rel'99

f1, Rel'99

Rel'99 and Rel-4 UEand Rel-6 or newer

non-HSDPA capable UE

Rel-5 UEand Rel-6 or newerHSDPA capable UE

abc def

mnojklghi

pqrs tuv wxyz

+

abc def

mnojklghi

pqrs tuv wxyz

+

DN03471612 69

WCDMA RAN RRM Handover Control Directed RRC connection setup for HSDPA layer


Figure 19 Signaling of directed RRC connection setup for HSDPA layer

The UE initiates the RRC connection setup procedure in the cell on which it camped in idle mode (that is, source cell). When UE initiates the RRC connection setup it indicates 3GPP release (that is, Rel-4, Rel-5, Rel-6,...) it supports (access stratum release indica-tor IE ) and Rel-6 UE indicates if it supports HSDPA and HSUPA (UE capability indica-tion IE). According to that information RNC directs the UE to the other (layer) cell within the same sector if needed. If the UE is already on the right layer, the RRC connection is established in the current cell.

The usage of the Directed RRC connection setup for HSDPA layer feature is controlled with the DirectedRRCForHSDPAEnabled parameter.

Basic functionalityThe DirectedRRCForHSDPALayerEnhanc parameter defines whether or not improvements done with HSDPA layering for UEs in common channels feature are acti-vated. If the parameter is disabled, the Directed RRC connection setup for HSDPA layer works as follows:

• 3GPP release 5 or newer UE is directed from non-HSDPA supporting cell to the cell which supports HSDPA (controlled by the management parameter HSDPA enabled).

• 3GPP release 99 or release 4 UE is directed from HSDPA supporting cell to the cell which does not support HSDPA.

The load of the target cell is not taken into account. The Directed RRC connection setup for HSDPA layer cannot be used simultaneously in the cell with the Directed RRC con-nection setup feature. The Directed RRC connection setup would move also potential HSDPA users away from HSDPA supporting cell.

When the Directed RRC connection setup for HSDPA layer is used, the maximum number of cells (layers) in one sector of the base station that can be configured, is two. If three-layer network is used one of the DCH layers (not supporting HSDPA) has to have different Sector Identifier in base station than in layers (DCH layer and HSDPA layer) where the Directed RRC connection setup for HSDPA layer is supported.

UTRANUE

Directed RRC connection setup forHSDPA layer

Frequency 1

Frequency 2

RRC CONNECTION REQUEST

RRC CONNECTION SETUP

RRC CONNECTION SETUP COMPLETE

70 DN03471612




Fractional DPCH capable UEs can be directed to an HSDPA layer if a conversational service is indicated in the RRC connection request. This layer selection is controlled separately with the DRRCForHSDPALayerServices parameter.

Enhanced functionality The DirectedRRCForHSDPALayerEnhanc parameter defines whether or not improvements done with HSDPA layering for UEs in common channels feature are acti-vated. If the DirectedRRCForHSDPALayerEnhanc parameter is enabled, the Directed RRC connection setup for HSDPA layer works as described in the following sections.

7.1 Decision of layer changeIf the RNC decides, it needs a layer change, it is based on the following information:

• 3GPP release that UE supports (Rel-4, Rel-5, Rel-6,…) (access stratum release indicator IE )

• HSDPA and HSUPA capability of the UE (UE capability indication IE). Only Rel-6 and newer UEs indicate this.

• The service UE is going to use based on the establishment cause (Establishment cause IE).

• The services are defined with the DRRCForHSDPALayerServices parameter. (These are directed to HSDPA layer.)

• HSDPA and HSUPA capability of the source cell and the cells in the same sector under same BTS.

• Multi cell support Information Element (IE), which indicates to network the DC HSDPA capability of Rel. 8 and onwards UEs (absence of this IE indicates that the UE does not support DC HSDPA.

Note that layer changes are not done for emergency calls.

Non HSDPA UEThe UE is interpreted as non-HSDPA capable if it is Release 99 capable (no release indicated in access stratum release indicator IE) or Release 4 capable. In the case of release 6 or newer UE, it is interpreted to be non-HSDPA capable if it does not indicate HSDPA capability.

These non-HSDPA capable UEs are directed away from the HSDPA capable cell if DirectedRRCForHSDPAEnabled parameter is enabled in the cell, the non-HSDPA capable cell is in the same sector and the load of the target cell is not too big; target cell load shall satisfy the conditions 1 and 2 introduced in Section Directed RRC connection setup. The idea is not to direct the UE to the layer in which the load is so big that it can trigger the Directed RRC connection setup to the source cell.

HSDPA capable UEThe UE is interpreted as HSDPA capable if it is Release 6 capable or newer and it indi-cates HSDPA capability. Also UE indicating Release 5 capability is interpreted to be HSDPA capable.

These HSDPA capable UEs are directed from the non-HSDPA capable cell to the HSDPA capable cell if DirectedRRCForHSDPAEnabled is enabled in the source cell, establishment cause indicated by the UE is activated with DRRCForHSDPALayerServices parameter, the HSDPA capable cell is in the same

DN03471612 71



sector and the HSDPA load of the target cell is not too big (the maximum number of HS-DSCH users reached). If several candidates exist the HSDPA load balancing is applied as described in the next section.

These HSDPA capable UEs can be directed from HSDPA capable cell to other HSDPA capable cell for load balancing reasons if DirectedRRCForHSDPAEnabled is enabled in source cell, establishment cause indicated by the UE is activated with DRRCForHSDPALayerServices parameter, HSDPA capable cell is in same sector and the HSDPA load of the target cell is suitable (see next chapter). HSDPA load bal-ancing is described in next section.

HSUPA capable UEUE is interpreted as HSUPA capable if it is Release 6 capable or newer and it indicates HSDPA and HSUPA capability.

HSUPA capable UE is also HSDPA capable and the decision goes as for HSDPA capable UE with the following exception. HSUPA capable UE is directed to the HSUPA capable cell if it is possible. The HSUPA capable UE is not directed away from the HSUPA capable cell.

7.2 HSDPA load balancingHSDPA load balancing is used when there are two or more layers that support the HSDPA. The idea is to ensure efficient usage of the HSDPA resources. When there are only a few users, it is more efficient to have them in the same layer. That is why there is a threshold parameter called HSDPALayerLoadShareThreshold. This defines the number of UEs after which the load balancing starts. Below this threshold the UEs are directed to the same layer. Above this threshold the UEs are directed so that the avail-able HSDPA power per user is as equal as possible between different layers.

HSDPA UEs can be directed to the same layer by the CellWeightForHSDPALayering parameter. A relatively higher value in one cell compared to other cells in the same sector directs more HSDPA UEs to that cell. This can be used if, for example, cell1 in frequency f1 has 5 HSDPA codes available and cell2 in frequency f2 has 15 HSDPA codes available (both are in the same sector). If the weight value specified for cell2 is higher than the one for cell1, more HSDPA users are directed to cell2 and use HSDPA codes more efficiently. When the number of UEs in every cell in the sector is under the threshold HSDPALayerLoadShareThreshold, the cell is chosen which CellWeightForHSDPALayering parameter has the highest value. If those are equal, the cell which has most of the UEs is selected.

When the number of UEs in every cell in the sector is above the HSDPALayerLoadShareThreshold threshold, the cell which provides the best HSDPA power per user is selected. HSDPA power per user is calculated using the fol-lowing equation.

Figure 20 Calculation of HSDPA power per user

PNRTHSDPA [W] is the transmission power that can be used or is used by NRT HSDPA users. For more information see "WCDMA RAN RRM HSDPA". CellWeightForHSDPA-Layering is the weight value for the cell as described above. NumberOfNRTHSDPAus-ers is the prevailing number of HSDPA NRT users in the cell, excluding HSPA users which L2 has indicated inactive, for more information see "WCDMA RAN RRM HSDPA".

HSDPApowerPerUser =(P

NRTHSDPA)*CellWeightForHSDPALayering

NumberOfHSDPAusers + 1

72 DN03471612




HSDPApowerPerUser (watts/user) is calculated to every candidate cell. The cell which has the highest value, that is the users get potentially the highest throughput in this cell, is selected.

If it is not suitable to use the available HSDPA power to select the cell, it can be disabled by the DisablePowerInHSDPALayeringDecision parameter. If the usage of power is disabled, users are distributed between the cells in some ratio by the following equa-tion.

Figure 21 Calculation of NRT HSDPA cell weight per user

HSDPAcellWeightPerUser is calculated to every candidate cell and the cell which has the highest value is selected.

Note also that, if the maximum number of HSPDA users is reached in a cell, that cell is not selected. The maximum number of HSDPA users is the maximum allowed number of HSDPA users per cell according to RNC licencing or the MaxNumberHSDPAUsers RNP parameter. The MaxNumberHSDPAUsers is the prevailing number of HSDPA users in the cell.

In addition, a cell is not selected if the maximum allowed number of HS-DSCH MAC-d flows in the cell is reached. The maximum allowed number of HS-DSCH MAC-d flows is specified by the MaxNumberHSDSCHMACdFlows parameter.

7.3 Layer selection examplesThe following examples illustrate layer selection.

Example 1: UE establishing RRC connection in non-HSDPA capable layer.

HSDPAcellWeightPerUser =CellWeightForHSDPALayering

NumberOfHSDPAusers + 1

DN03471612 73



Figure 22 Example of layer selection in RRC connection setup phase in non-HSDPA layer

The layer selection algorithm goes in the following steps. When the layer can be selected in any of the steps 1 – 4, the other steps are ignored.

1. according to UE HSDPA capability against cells HSDPA capability (f1) • UE A -> current layer (f1) is selected • UEs B and C -> check f2 and f3 2

2. according to service against parameterization • UEs B and C if

Establishment cause IE ≠ DRRCForHSDPALayerServices (parameter) -> current layer (f1) is selected

• UEs B and C ifEstablishment cause IE = DRRCForHSDPALayerServices (parameter) -> check f2 & f3

3. according to UE HSPA capability against cells HSPA capability (f2 and f3) • UE B -> check f2 and f3 • UE C -> f3 is selected

4. better available HSDPA throughput • UE B: f2 or f3 is selected

Example 2: UE establishing RRC connection in HSDPA capable layer.

UE reporting Rel-6HSDPA & HSUPA capability

UE reporting Rel5 orRel-6 & HSDPA capability

Any other UE

C

B

A

f3, HSDPA&HSUPA

f2, HSDPA

f1, R'99

74 DN03471612




Figure 23 Example of layer selection in RRC connection setup phase in HSDPA layer

The layer selection algorithm goes in the following steps. When the layer can be selected in any of the steps 1 – 4, the other steps are ignored.

1. according to UE HSDPA capability against cells HSDPA capability (f2/f3) • UE A -> f1 is selected • UEs B and C -> check f2 and f3

2. according to service against parameterisation • UEs B and C if

Establishment cause IE ≠ DRRCForHSDPALayerServices (parameter) -> current layer (f2/f3) is selected

• UEs B and C if Establishment cause IE = DRRCForHSDPALayerServices (parameter) -> check f2 & f3

3. according to UE HSPA capability against cells HSPA capability (f2 and f3) • UE B -> check f2 and f3 • UE C -> f3 is selected

4. better available HSDPA throughput • UE B: f2 or f3 is selected

7.4 Fractional Dedicated Physical ChannelHSPA support is prerequisite for Fractional Dedicated Physical Channel (F-DPCH) and CPC. However, the network can be configured so that there are two HSPA layers and only other one supports F-DPCH. Whenever there is selection between two HSPA layers, for the F-DPCH capable UE the one which supports F-DPCH is selected.

UE reporting Rel-6HSDPA & HSUPA capability

UE reporting Rel5 orRel-6 & HSDPA capability

Any other UE

C

B

A

f3, HSDPA&HSUPA

f2, HSDPA

f1, R'99

DN03471612 75



First HSPA-capable cells are selected. After that, selection is primarily based on F-DPCH capability and secondarily load.

In RRC connection setup phase Rel.7 F-DPCH capable UE is detected based on Support for Enhanced F-DPCH is True.

Target cell is F-DPCH capable if value of cell specific radio network planning parameter FDPCHEnabled is defined as enabled.

If DirectedRRCForHSDPALayerEnhanc parameter is disabled, RNC does not take nto account F-DPCH capability in decision making. If DirectedRRCForHSDPALayerEnhanc parameter is enabled, the F-DPCH capability is taken into account as defined below.

First HSUPA capable cells are selected according to the algorithm above. After that selection of the cell is performed as follows:

• If among HSDPA and HSUPA capable candidates only one F-DPCH capable can-didate exists, it is selected and it is not checked if maximum number of HSUPA users is reached for that cell.

• If among HSDPA and HSUPA capable candidates several F-DPCH capable candi-dates exist, it is checked if maximum number of HSUPA users is reached in any of the candidate cells. If yes it is left out from candidate list if there is still F-DPCH capable cell after that. Otherwise the selection is done like described above but in the case when equations: Figure 20 Calculation of HSDPA power per user or Figure 21 Calculation of NRT HSDPA cell weight per user gives equal HSDPA throughput per user the cell which has less HSUPA users is selected.

• If any F-DPCH capable cell among HSPA capable cells cannot be selected because of the maximum number of HSDPA users or the maximum number of HS-DSCH MAC-d flows is reached, the non-F-DPCH capable cell is selected if the UE is not currently in F-DPCH capable cell. If the UE is currently in an F-DPCH capable cell it is not moved away from that cell.

7.5 Dual Cell HSDPAIf DirectedRRCForHSDPALayerEnhanc parameter value is “Disabled”, then the RNC does not take DC HSDPA into account in the decision of Directed connection setup for HSDPA layer. If DirectedRRCForHSDPALayerEnhanc parameter value is “Enabled”, then the RNC does take DC HSDPA into account in the decision of Directed connection setup for HSDPA layer.

In RRC connection setup phase Rel-8 DC HSDPA capable UE is detected based on Multi Cell support IE. DC HSDPA is supported by the UE, when the value of the Multi Cell support IE is “True”.

A cell can act as a primary serving HS-DSCH cell when the DC HSDPA and HSUPA features are enabled in the cell with the DCellHSDPAEnabled and HSUPAEnabled parameters respectively, the BTS has indicated that it supports DC HSDPA and HSUPA in the cell, and there is another cell in the sector that can act as secondary serving HS-DSCH cell (the DC HSDPA is enabled in the cell) for the DC HSDPA capable UE and the BTS has indicated that it supports DC HSDPA in the cell.

First the RNC selects the HSUPA capable cell (or cells). If the UE supports DC HSDPA and there are two or more HSUPA capable cells in the sector, the RNC selects the target cell according to the following priority order:

76 DN03471612




1. DC HSDPA and F-DPCH (if the UE supports F-DPCH) capable cells which have not reached the maximum number of HSUPA users

2. DC HSDPA and HSUPA capable cells which have not reached the maximum number of HSUPA users

3. F-DPCH (if the UE supports F-DPCH) capable cells which have not reached the maximum number of HSUPA users

4. HSUPA capable cells which have not reached the maximum number of HSUPA users

If there are several possible target cells, the load balancing between the target cells is based on the Figure 20 Calculation of HSDPA power per user and Figure 21 Calculation of NRT HSDPA cell weight per user. In the case when Figure 20 Calculation of HSDPA power per user and Figure 21 Calculation of NRT HSDPA cell weight per user gives equal HSDPA throughput per user, the cell which has less HSUPA users is selected.

If any HSUPA capable cell cannot be selected because the number of HSDPA users or the number of HS-DSCH MAC-d flows has reached the maximum, non-HSUPA capable cell is selected.

7.6 Interaction with directed RRC connection setupWhen the Directed RRC connection setup is enabled (handle with DirectedRRCEnabled parameter) simultaneously with Directed RRC connection setup for the HSDPA layer feature (handle with DirectedRRCForHSDPAEnabled parameter), the decision making goes in the following order.

• First the decision of Directed RRC connection setup for the HSDPA layer is done. If the layer is decided to change, the UE is directed to new layer. If the layer is decided not to change, the decision making for the Directed RRC connection setup can be done.

• If the UE is interpreted as HSDPA capable in the HSDPA capable cell and it requests interactive or background service, the Directed RRC connection setup feature does not move the UE to the non-HSDPA capable cell.

• If the UE is interpreted as HSDPA capable in the non-HSDPA capable cell and the load in source cell is big enough to trigger the Directed RRC connection setup feature, the HSDPA capable target cell is selected if possible.

DN03471612 77

WCDMA RAN RRM Handover Control HSPA layering for UEs in common channels

Id:0900d805807ea1eaConfidential

8 HSPA layering for UEs in common channelsHSPA layering for UEs in common channels feature is meant for multi layer networks where high speed downlink packet access (HSDPA) is supported in some layer(s) (carrier frequency). The primary target of this feature is to direct the HSDPA UE to the cell that supports HSDPA. On the other hand non-HSDPA UE is removed from HSDPA layer(s). If several HSDPA capable layers exist, the HSDPA load balancing between these layers is used. This feature is intended to be used together with the Directed RRC connection setup for the HSDPA feature as they complement each others.

The layer change in HSPA layering for UEs in common channels is done inside the sector belonging to the same base station just like for the Directed RRC connection setup for the HSDPA layer. From this follows the same prerequisite that the cells involved must have same sector identifier (defined with the SectorID parameter). Two cells can belong to the same sector if they have equal coverage areas. The coverage areas can be considered as equal if the cells have identical values for the following parameters (The RNC is not able to check whether or not the antenna beams of the cells are directed equally.):








78 DN03471612



HSPA layering for UEs in common channels

Figure 24 signaling of HSPA layering for UEs in common channels

If UE is F-DPCH capable and there is F-DPCH capable target cell F-DPCH capability is taken into account in decision making as defined for Directed RRC connection setup from non-HSDPA layer to HSDPA layer in F-DPCH functionality. Note that DirectedRRCForHSDPALayerEnhanc parameter is not used in state transition. In state transition HSDPALayeringCommonChEnabled parameter is used. In state tran-sition from CELL_FACH to CELL_DCH Rel-7 F-DPCH capable UE is known beforehand based on previous UE capability indication in RRC information element "Support For Enhanced F-DPCH". Information element is received in RRC: RRC Connection Request message.

HSPA layering for UEs in common channel feature directs the UE to another layer in state transition from Cell_FACH to Cell_DCH, if it is needed. The HSDPA capable UE is directed to the HSDPA layer and the non-HSDPA capable UE is directed away from the HSDPA layer. If UE is directed to another layer the new frequency is indicated in Fre-quency info IE in the Radio Bearer Reconfiguration message to it.

UE RNCBTS

UE is in CELL_FACH or CELL_PCH state

UE is in CELL_DCH state

RRC:Measurement Report

RRC:Radio Bearer Reconfiguration

(Frequency Info)

RRC: Radio BearerReconfiguration Complete

UL capacity need isdetected by MAC

(AND/OR)

Frequency layer / cell selectionand capacity allocation

DL capacity need is detectedby MAC or RAB Assignment

Request from CS core

UE moves to CELL_DCH stateand to new frequency

RLC parameters needto be changed

NBAP Radio Link Setup procedure

DN03471612 79



The usage of HSPA layering for UEs in common channels feature is controlled with the HSDPALayeringCommonChEnabled management parameter.

Layer change is allowed for the used services with the ServBtwnHSDPALayers RNP parameter.

8.1 Decision of layer changeThe RNC decides if layer change is needed based on the following information:

• HSDPA and HSUPA capability of the UE • RAB type which is going to be established (CS/PS) • services (CS/PS) defined with ServicesToHSDPALayer parameter (These are

directed to HSDPA layer.) • HSDPA and HSUPA capability of the source cell and the cells in the same sector

under the same BTS

Note that layer changes are not done for emergency calls.

The Non HSDPA UE The Non-HSDPA capable UEs are directed away from the HSDPA capable cell if HSDPALayeringCommonChEnabled is enabled in the cell, the non-HSDPA capable cell is in the same sector and the load of the target cell is not too big. The idea is not to direct the UE to a layer in which the load is so big that it can trigger the Directed RRC connection setup to the source cell.

The HSDPA capable UE The HSDPA capable UEs are directed from the non-HSDPA capable cell to the HSDPA capable cell if HSDPALayeringCommonChEnabled is enabled in the source cell, oper-ation is allowed for RAB type (CS/PS) defined with ServicesToHSDPALayer param-eter, the HSDPA capable cell is in the same sector and the HSDPA load of the target cell is not too big (the maximum number of HS-DSCH users is reached). If several can-didates exists the HSDPA load balancing is applied as described in the following section.

The HSDPA capable UEs can be directed from the HSDPA capable cell to another HSDPA capable cell for load balancing reasons if HSDPALayeringCommonChEnabled is enabled in the source cell, the UE is requesting interactive or background service, the HSDPA capable cell is in the same sector and the HSDPA load of the target cell is suitable (see the next section). For more information on HSDPA load balancing, see Section HSDPA load balancing.

The HSUPA capable UE The HSUPA capable UE is also HSDPA capable and the decision goes as for the HSDPA capable UE with the following exception. The HSUPA capable UE is directed to the HSUPA capable cell if it is possible. The HSUPA capable UE is not directed away from the HSUPA capable cell.

F-DPCH capable UEIf UE is F-DPCH capable and there is F-DPCH capable target cell F-DPCH capability is taken into account in decision making as defined for Directed RRC connection setup between HSDPA layers in F-DPCH functionality. Note that DirectedRRCForHSDPALayerEnhanc parameter is not used in state transition. In

80 DN03471612



HSPA layering for UEs in common channels

state transition HSDPALayeringCommonChEnabled parameter is used. In state tran-sition from CELL_FACH to CELL_DCH Rel-7 F-DPCH capable UE is known beforehand based on previous UE capability indication in RRC information element "Support For Enhanced F-DPCH". The information element is received in RRC: RRC Connection Request message.

MIMO capable UEHSPA layering for UEs in common channels feature transfers MIMO capable UE from the non-HSPA/HSDPA layer to the MIMO HSPA layer.

MIMO capability of the cell is detected based on the following parameters:

• WCEL-MMOEnabled parameter is “Enabled” • MIMO capability received from the BTS is MIMO capable.

MIMO capability of the UE is detected based on the UE category. UE of the categories: 15-18 (REL. 7) and 19-20 (REL. 8) support MIMO.

If among HSPA capable cells (HSDPA and HSUPA enabled in the cell) only one MIMO capable cell exists, it is selected if the maximum number of HSDPA users or the maximum number of HS-DSCH MAC-d flows is not reached for that cell. Otherwise MIMO cell is not chosen.

If any MIMO capable cell among HSPA capable cells cannot be selected because of the maximum number of HSDPA users or the maximum number of HS-DSCH MAC-d flows is reached for that cell, the non-MIMO capable cell is selected.

If among HSPA capable cells several MIMO capable cells exist, the layer selection between MIMO capable cells is performed according to the existing principles in HSPA layering for UEs in common channels feature.

RNW-parameter ServicesToHSDPALayer is used for decision making for MIMO UE.

The RNW-parameter ServBtwnHSDPALayers is used for decision making when MIMO capable UE is moved to MIMO layer.

DC HSDPA capable UEDC HSDPA capability of the Release 8 and onwards UE is indicated during RRC con-nection setup phase, by the Multi cell support IE. Absence of this IE indicates DC HSDPA incapability of the UE. Dual Cell HSDPA is enabled in the cell by the DCEllHSDPAEnabled parameter. The Dual Cell HSDPA cell can act as a primary serving HS-DSCH cell when the following criteria are fulfiled:

• DC HSDPA and HSUPA are enabled in that cell, this is done by the DCellHSDPAEnabled and HSUPAEnabled parameters respectively

• the BTS has indicated that it supports DC HSDPA and HSUPA in the cell • there is another cell in the sector which can act as a secondary serving HS-DSCH

cell (the DC HSDPA feature is enabled in the cell) for the DC HSDPA capable UE and the BTS has indicated that it supports DC HSDPA in the cell.

First the RNC selects the HSUPA capable cell (or cells) for the state transition from Cell_FACH to Cell_DCH as described in Section Directed RRC connection setup for HSDPA layer. If the UE supports DC HSDPA and there are two (or more) HSUPA capable cells in the sector, the RNC selects the target cell according to the following priority order:

1. DC HSDPA and F-DPCH (if the UE supports F-DPCH) capable cells which have not reached the maximum number of HSUPA users

DN03471612 81



2. DC HSDPA and HSUPA capable cells which have not reached the maximum number of HSUPA users

3. F-DPCH (if the UE supports F-DPCH) capable cells which have not reached the maximum number of HSUPA users

4. HSUPA capable cells which have not reached the maximum number of HSUPA users

If there are several possible target cells, the load balancing between the target cells is based on the Figure 20 Calculation of HSDPA power per user and Figure 21 Calculation of NRT HSDPA cell weight per user as described in Section Directed RRC connection setup for HSDPA layer. In the case when Figure 20 Calculation of HSDPA power per user and Figure 21 Calculation of NRT HSDPA cell weight per user gives equal HSDPA throughput per user, the cell which has less HSUPA users is selected.

If any HSUPA capable cell cannot be selected because the number of HSDPA users or the number of HS-DSCH MAC-d flows has reached the maximum, non-HSUPA capable cell is selected as described in Section Directed RRC connection setup for HSDPA layer.

8.2 HSDPA load balancingHSDPA load balancing is identical for HSPA layering for UEs in common channels and the Directed RRC connection setup for HSDPA layer features. For more information see description under the Directed RRC connection setup for HSDPA layer.

82 DN03471612



Power balancing

9 Power balancingPower drifting needs to be taken into account in the downlink power control mechanism during a soft handover.

Figure 25 Power drifting

The basic operation of the DL fast closed loop power control is as follows:

• The UE measures the received SIR of the downlink dedicated physical channel every transmitter power control cycle. Each transmitter power control cycle takes 0.667 ms (1500 Hz) which is same time as one slot period. The measured SIR value is compared to a SIR target value in each slot time.

• When the measured SIR value is higher than the SIR target value, the transmitter power control command (TPC) is set to "0" and when the measured SIR value is lower than the SIR target value, the TPC command is set to "1".

• The UE inserts the value of the TPC command to the next slot of the uplink DPCCH.

The WCDMA BTS either decreases or increases the transmission power of the dedi-cated physical channel based on the received TPC value. The adjustment is done for every slot, that is each 0.667 ms, 1500 Hz.

In the event of a soft handover, the UE sends the same power control command value to all BTSs involved in the handover and each BTS detects the value on its own. Because of detection errors, the power control commands might be decoded incorrectly some of the base stations and the power level is increased instead of decreased or vice versa. As a result, the DL transmission power of radio links at different base stations starts to drift apart and the power values received at the UE are unbalanced.

The power balancing algorithm controlled by the RNC works together with the DL fast closed loop power control in the BTS as long as the soft handover situation lasts. Power balancing is located in the handover control functional unit and the measurement messages for power balancing are terminated in the handover control. The figure Func-tional split of the power balancing functionality shows the functional split of the power balancing function.

transmission ofpower control command


command


power


command


power

DN03471612 83

WCDMA RAN RRM Handover Control Power balancing


Figure 26 Functional split of the power balancing functionality

The figure Ideal power control without power balancing shows the ideal power control situation where power balancing is not needed as no DL fast closed loop power control commands are misinterpreted. The cell power is in balance. This ideal situation is not possible in real radio networks.

Figure 27 Ideal power control without power balancing

The figure Real situation with misinterpreted PC commands shows how the cell power becomes unbalanced because of misinterpreted DL fast closed loop power control commands in real radio networks. If too many misinterpreted DL fast closed loop power control commands occur in a soft handover situation, the DL transmission power of one radio link may rise up while the transmission power of another radio link goes down.

IurDRNC SRNC

L3

Iub

BS #1 BS #2 BS #3

Iub L3 L3

HC/PB/Init parameters+ Pref update

DL fast closedloop PC / PBalgorithm

from BS's to RNC: Averaged DL power

from RNC to BS's: Initial parameters,reference transmission power



Cell2

Cell1

Power

Time

Actual Power P(k)

Diff Power

84 DN03471612



Power balancing

Figure 28 Real situation with misinterpreted PC commands

In figure Power balancing in work, power balancing is in use and misinterpreted DL fast closed loop power control commands do not occur in the shown adjustment period. The cell power is close to the reference power. The figure shows a situation where the UE is not moving and the DL transmitted powers are set almost to the same level. It is assumed that the CPICH powers are equal.

Figure 29 Power balancing in work

The power balancing algorithm works independently of the inner and outer loop power control mechanisms. Each adjustment period, power balancing tries to correct the DL transmission powers to the level of the reference power that was defined in the SRNC before the current adjustment period.

The reference power is common to all base stations. Each time new measurement data is received from the base stations, it is calculated in the SRNC as follows:

• Select the highest of the averaged DL transmission powers.

Cell2

Cell1

Power

TimeActualPower P(k)

Misinterpretation

The power of cell1 is now - 1dB from correct level

Diff Power

Cell2

Cell1

Power

Time

ActualPower P(k)

In this example, the Diff power of cell1 is - 3 dB and

Diff Power

Adjustment period starts

Reference powercalculated by the RNC

Pref = PDL average(s)

- PCPICH(s)

- Pref_substract

Adjustment Period Adjustment Period

Power corrections

the Diff power of cell2 is + 2 dB

DN03471612 85



• Subtract the highest of the averaged DL transmission powers by the internal Pref-Subtract value.

This system is not aware of any individual misinterpreted DL fast closed loop power control command but it assumes that these commands are misinterpreted. The balanc-ing algorithm causes under and over estimations of the current transmitted power but the DL fast closed loop power control adjusts those “mistakes” immediately. The result is a destabilized power control and the attempt to drive DL transmission powers of radio links on different base stations to the same level.

If a radio link is in compressed mode, UL fast closed loop power control commands can get lost. When compressed mode ends, such situations are corrected immediately by fast closed loop power control and there is no need for power balancing to correct this error.

9.1 Activation of power balancingPower balancing feature is enabled by the PowerBalancing parameter.

If the UE is in a soft handover and the power balancing feature is activated, the DL fast closed loop power control of all branches of the connection are informed to operate with the power balancing algorithm. If the UE is in a soft handover during anchoring, the Power Balancing feature and the Support for I-HSPA Sharing and Iur Mobility Enhance-ments feature need to be enabled.

If the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled in the SRNC when SHO is ‘On’ during anchoring and the PB feature is switched ‘On’ in SRNC, then PB can be activated if not active previously.

The RNC transmits the power balancing information in the NBAP: DL POWER CONTROL REQUEST message. The figure Message sequence chart for power balanc-ing shows the power balancing setup. The same message is used to modify power bal-ancing.

86 DN03471612



Power balancing

Figure 30 Message sequence chart for power balancing

Power balancing adjustments in the BTS are started at the first slot of a frame with CFN modulo the value of the Adjustment Period IE equals to 0. It is repeated each adjustment period and is restarted at the first slot of a frame with CFN=0 until a new NBAP: DL POWER CONTROL REQUEST message is received or the radio link is deleted.

In the event of a branch addition for the current call, the RNC sends the new power bal-ancing parameters to every branch by the NBAP: DL POWER CONTROL REQUEST message. This keeps BTS reports in synchronization. Power balancing uses the same mechanism for the period of out of synchronization in uplink and downlink direction.

When the RNC sends the NBAP: DL POWER CONTROL REQUEST message to the BTS during the power balancing activation, the RNC starts a reporting period timer for the first NBAP: DEDICATED MEASUREMENT REPORT messages. This timer is used to ensure that at least one measurement report is received from each branch. The RNC waits for dedicated measurement reports from all branches for the time specified by the timer. The value of the power balancing reporting period timer is:

25 x Max. Reporting Period of all RLs in SHO

The Max. Reporting Period of all RLs in SHO is derived from one or more of the following measurement reporting period parameters:

• DedicatedMeasReportPeriod (for AMR service type) • DediMeasRepPeriodCSdata (for CS data service type) • DediMeasRepPeriodPSdata (for PS data service type)

The timer is stopped if measurement reports are received from all branches during the power balancing reporting period timer.

When the BTS receives an NBAP: DEDICATED MEASUREMENT INITIATION REQUEST message, it starts periodic dedicated measurements according to the Report Characteristics IE in the NBAP message. The measurements are averaged.

DL Power Control Request, including PB parameters



SRNCBS 2DRNCBS 1

Link setup

Link addition

Start of the PB procedure

PB algorithmstarts to operate

PB algorithmstarts to operate

DN03471612 87



Power Balancing is not used when F-DPCH is allocated for the UE, seeWCDMA RAN RRM HSUPA .

9.2 Deactivation of power balancingPower balancing is deactivated in the event of:

• The UE is not in a soft handover situation any longer. • Dedicated measurement reports were not received from all the branches within the

time specified by the power balancing reporting period timer. • Dedicated measurement fails for any of the active set branches. • The last radio link of the SRNC is deleted as power balancing is not supported in the

SRNC anchoring if the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is disabled in SRNC. Power balancing is activated again if the anchoring sit-uation is over or the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled.

• When power balancing is disabled by the PowerBalancing parameter. The parameter value is checked every time the NBAP: DEDICATED MEASUREMENT REPORT message is received, the active set is changed, or the SRNC is reallo-cated.

To deactivate power balancing, the RNC informs all remaining active set branches by an NBAP: DL POWER CONTROL REQUEST message with the Power Adjustment Type IE set to "None".

9.3 The DL power control requestWhen a new radio link is added to an existing radio link set and power balancing is switched on, the Serving RNC sends a DL POWER CONTROL REQUEST message with the DL Power Balancing Information IE to the BTS or the Drift RNC .

The DL Power Balancing Information IE contains the following information:

• Power Adjustment TypeThe Power Adjustment Type IE is set to common.

• DL Reference PowerThis IE contains last calculated reference power. It is present if the Power Adjust-ment Type IE is set to “Common”.

• Inner Loop DL PC Status • Max Adjustment Step RNP parameter • Adjustment Period RNP parameter • Adjustment Ratio RNP parameter

A Nokia Siemens Networks SRNC uses always the power adjustment type "Common". The power adjustment type "Individual" is not used to activate power balancing. The DL Reference Power Information IE is not filled as it is only present when the Power Adjust-ment Type IE is set to “Individual”.

The DL reference power is calculated during the power balancing startup by the follow-ing equation:

Pref = Pinit – Pref_subtract

where

Pref is the new reference power in dBs

88 DN03471612



Power balancing

Pinit is the RL initial power of the soft handover branch which has the highest initial DL Tx power

Pref_subtract is a subtract parameter in dBs

During anchoring when the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled in the SRNC, since all the radio links in the active set belong to the DRNC, the highest DL Tx Pwr as received in the RNSAP: DEDICATED MEASURE-MENT REPORT is used for Pinit in the above equation. Atleast one measurement report from all the RLs (newly added SHO RL is excluded) in the active set are available before PB can be activated during anchoring because of SHO branch addition.

If measurement reports for all cells are not available during anchoring, then upon receiv-ing the RNSAP: DEDICATED MEASUREMENT REPORT of last active set cell, thereby resulting in a situation where reports are available for all RLs in the active set and if PB is switched ‘On’ in SRNC, then Serving RNC sends DL Power Control Request message to Drifting RNC(s) to activate PB in DRNC(s) with the DL Reference Pwr.

During normal operation when new dedicated measurement reports are available from some of the branches, Pref is calculated and set to use.

When a DL reference power update is needed, the Serving RNC sends the value of the new reference power by the DL Reference Power IE in the DL POWER CONTROL REQUEST message to the BTS or the DRNC.

9.4 Usage of the power balancing adjustment Type in the BTS and the DRNCThe BTS and the DRNC can receive the Power Adjustment Type IE in a RADIO LINK SETUP or DL POWER CONTROL REQUEST message. If the value of the Power Adjustment Type IE is “Common”, the BTS or DRNS reacts as follows:

• The BTS sets the power balancing adjustment type of the Node B Communication Context to “Common”.

• The DRNC sets the UE context to “Common”.

As long as the power balancing adjustment type is set to “Common”, the BTS or DRNS adjusts the power for all existing and future radio links of the Node B Communication Context or UE context and uses a common DL reference power level.

If the value of the Power Adjustment Type IE is “Individual”, the power balancing adjust-ment type of the Node B Communication Context or the UE context is set to “Individual”. The WBTS uses the Common mode also in this case and the power adjustment is per-formed by using the common DL reference power for all radio links which are addressed in the message. The used common DL reference power is an averaged value of the received DL reference power values received in the DL Reference Power IE of the DL POWER CONTROL REQUEST message.

9.5 Updating the reference transmission power during the soft handoverThe reference power is updated periodically because it is beneficial to keep the refer-ence transmission power close to the average needed DL transmission power in the DL.

The reference transmission power is updated by the RNC according to the average DL transmitted code power. The reporting range of the transmitted code power is from –10,

DN03471612 89



…, 46 dBm. The average DL transmitted code power is received from each soft handover branch of a BTS in the NBAP: DEDICATED MEASUREMENT REPORT message.

The new value of the reference power is defined if all of the following conditions are true:

• At least one NBAP: DEDICATED MEASUREMENT REPORT message has been received for each branch.

• New reports arrive for some of the branches.

The update of the reference power depends on the longest measurement period of all branches. The reference power can be updated once in each of this longest measure-ment period.

The new reference power is defined by choosing the highest of the averaged DL trans-mitted code powers and then subtracting this by an RNC internal PrefSubtract value that is set to approximately 2 dB.

Power balancing is not deactivated if the measurement reports were not received from all of the branches. The reference transmission power value per cell is specified relative to the primary CPICH power (range is –35, …, +15 dB).

Pref is calculated as follows:

Pref = PDLaverage(s) – PCPICH (s) – Pref_subtract

where

s indicates the cell with the highest average DL transmission power

Pref is the new reference power in dBs

PDLaverage(s) is average DL transmission power in dBms

PCPICH (s) is a primary CPICH power in dBms

Pref_subtract is a subtract value in dBs.

When the transmitted code power is measured during compressed mode, all slots are included in the measurement, that is the slots in the transmission gap are included in the measurement. Therefore, there is no need to take compressed mode into account while defining the reference power. As the measurements are filtered in the BTS, it may happen that measurement reports for different branches are available only in periods of 10 * Reporting period.

9.6 Sending the new reference transmission power to the BTSThe new value of the reference power Pref is sent to the BTS as soon as a specified threshold is reached. The RNC stores the latest Pref value which was sent to the BTS. Each time Pref is calculated, the RNC compares the latest and the stored value.

The new Pref is sent to the BTS when the following condition is true:

I Latest_value – New_value I >= Min_Pref_change

The Min_Pref_change parameter defines the threshold for the difference between the latest and the new value of the reference power. If this threshold is reached, the new reference power is sent to the BTS. The default value for Min_Pref_change is 3 dB.

The new reference power Pref is transmitted to the base stations in the DL Reference Power IE of the NBAP: DL POWER CONTROL REQUEST message. The figure below shows the message sequence chart for the reference transmission power updating pro-cedure. The same reference power is sent to all branches.

90 DN03471612



Power balancing

Figure 31 Updating of the power balancing reference power for three soft handover branches

9.7 Power balancing algorithm in the BTSFigure 32 Power balancing algorithm shows the implementation of the power balancing algorithm in the BTS. For more information see 3GPP TS 25.214 specification.

DL Power Control Request

Dedicated Measurement Report

RNCBS #3BS #2BS #1

Calculation of thenew reference powerfor soft handover branches

Averaging of the DL transmission powers



Updating Pref whenthreshold is exceeded



DN03471612 91



Figure 32 Power balancing algorithm

The terms in the algorithm are specified as follows:

• adjustment period: Adjustment period in frames, see 3GPP TS 25.433. • t: Adjustment period length in power control cycles. • Power_corr: Current power correction within an adjustment period in dBs (internal

term). The adjustment within one adjustment period depends on the Max Adjust-ment Step and the DL TX power range set by the CRNC.

• Sum of Pbal: Power correction over an adjustment period, that is the power differ-ence of a branch compared to the reference power in dBs (TS 25.433).

• Sum of Pbal_max: Maximum allowed power correction during an adjustment period in dBs (internal term).

• Pinit: Code power for the last slot of the previous adjustment period, see 3GPP TS 25.433 in dBms. If the last slot of the previous adjustment period is within a trans-mission gap because of compressed mode, Pinit is set to the code power value of the slot just before the transmission gap.

• PP-CPICH: Power used on the primary CPICH in dBms, see 3GPP TS 25.433.

Is Power_corr = 0 ?Yes

Start

Is h = 0?

No

No

Yes

n = Adjustment_period (frames)t = n * 15 (power control cycles)

DL_Reference_power = Pref

+ PP-CPICH

Pbal

= (1 - Adjustment_ratio / 100) * (DL_Reference_power - Pinit

)

Pbal_max

= (1dB / Max_adjustment_step) * t

Power_corr = sign Pbal

* min abs ( Pbal

), Pbal_max

I = t / absolute (Power_corr)

h = ceil (l)

Pbal

(k) = sign (Power_corr) * 1 dB

h = tP(k) = P(k-1) + P

tcp(k) + P

bal(k)

i.e. power control command will be performed

Pbal

(k) = 0Wait one power control cycle (0.667 ms)

t = t - 1h = h - 1

Is t = 0?NoYes

92 DN03471612



Power balancing

• Max_adjustmet_step: Defines the time period in terms of number of slots in which the accumulated power adjustment is a maximum of 1dB, see 3GPP TS 25.433.

• h: Indicates the interval in power control cycles according to which corrections are made during an adjustment period.

• k: Identifies the power control cycle. • Pref: DL reference power in dBs relative to the primary CPICH power calculated by

the RNC based on the averaged transmission power values sent by the BTSs during earlier adjustment periods, see 3GPP TS 25.433.

• DL_Reference_power: Current DL reference power in dBms, see 3GPP TS 25.433. • Adjustment_ratio: Weighting coefficient for the power balancing correction, see

3GPP TS 25.433. • P(k): Is a new calculated downlink power value in dBs, see 3GPP TS 25.214. • P(k-1): Is a current downlink power value in dBs, see 3GPP TS 25.214. • PTPC(k): Is the k :th power adjustment in the DL fast closed loop power control, see

3GPP TS 25.214. • Pbal(k): Power balancing value in dBs which will be corrected after each h power

control cycles, see 3GPP TS 25.214. Pbal(k) is set to 1dB.

After estimating the k : th TPC command, the BTS adjusts the current downlink power P(k-1) in dBs to a new power P(k) in dBs according to the following equation:

P(k) = P(k-1) + PTPC(k) + Pbal(k)

where PTPC(k) in dBs is the k : th power adjustment in the DL fast closed loop power control and Pbal(k) (in dBs) is a correction for balancing radio link powers towards a common reference power.

In each slot during compressed mode except during downlink transmission gaps, the BTS estimates the k : th TPC command and adjusts the current downlink power P(k-1) in dBs to a new power P(k) in dBs according to following equation:

P(k) = P(k – 1) + PTPC(k) + PSIR(k) + Pbal(k)

where PTPC(k) in dBs is the k : th power adjustment in the DL fast closed loop power control, PSIR(k) in dBs is the k - th power adjustment because of the downlink target SIR variation, and Pbal(k) in dB is a correction according to the downlink power control pro-cedure for balancing radio link powers towards a common reference power. Pbal(k) in dBs can be 1 dB, -1 dB or 0 dB depending on the state of the algorithm.

9.8 Reliability check for DL TPC commands during soft handover When different radio links are unbalanced in uplink direction during a soft handover, the DL TPC commands are detected as unreliable by a BTS with weak uplink signal. Oth-erwise, the downlink transmission power from a BTS with weak uplink signal would vary in a broad range. Because the UE summarizes the power from the different branches, all BTS would adapt the variations of the power from the weak BTS. The result would be a large variation in the downlink power in all branches.

Therefore, the BTS checks the reliability of the received DL TPC commands before adjusting the DL transmission power. If the command is unreliable, the transmission power is kept constant. In addition to decoding the soft DL TPC commands into three values Up, Down, and Zero a small bias is added to the detection. As a result of the bias, the DL transmission power of the BTS with weak uplink should on average transmit with

DN03471612 93



a lower power than a BTS with sufficient uplink. The bias in the DL TPC commands work as a trivial power-balancing algorithm decreasing the problems when there is an unbal-ance between uplink and downlink.

94 DN03471612


Id:0900d8058083cbebConfidential

Functionality of intra-frequency handover

10 Functionality of intra-frequency handoverIntra-frequency handovers can be soft or hard handovers. The vast majority of intra-fre-quency handovers in the Wideband Code Division Multiple Access (WCDMA) radio access network are soft handovers. The following sections describe the algorithms involved in intra-frequency soft and hard handover. For the signaling procedures involved, see Sections Soft handover signaling and Intra-frequency hard handover sig-naling.

10.1 Functionality of soft handoverThe handover decision algorithm of the Radio Network Controller (RNC) for intra-fre-quency handover is based on the event-triggered measurement reports. When in active mode, the 3G User Equipment (UE) continuously measures the Common Pilot Channel (CPICH) of the serving and neighboring cells (indicated by the RNC) on the current carrier frequency. The measurement quantity is CPICH Ec/No (received energy per chip divided by the power density in the band, that is, CPICH RSCP/UTRA Carrier RSSI). The UE compares the measurement results with handover thresholds, which have been provided by the RNC, and sends a measurement report to the RNC when the handover thresholds are fulfilled. Filtering of CPICH Ec/No measurements is controlled with the RNP parameter EcNoFilterCoefficient.

Based on the measurement report, the RNC orders the UE to add, replace or remove cells from its active set, that is the set of cells participating in soft handover. The RNC limits the number of cells participating in soft handover. The maximum size of the active set is three cells. When detected set reporting is enabled in one or more active set cells, handover control takes into account the detected set reporting quantities for soft handover decisions.

The handover decision algorithm of the RNC is fairly straightforward for soft (and softer) handover: the algorithm accepts practically everything the UE suggests according to the measurement reporting events.

The handover control of the RNC contains the following measurement reporting events and mechanisms for modifying measurement reporting behaviour:

• reporting event 1A for adding cells to the active set • reporting event 1B for deleting cells from the active set • reporting event 1C for replacing cells in the active set • event-triggered periodic intra-frequency measurement reporting • time-to-trigger mechanism for modifying measurement reporting behaviour • cell individual offsets for modifying measurement reporting behaviour • mechanism for forbidding a cell to affect the reporting range • reporting events 6F and 6G for deleting cells from the active set

When the channel type is DCH, the intra-frequency measurements are controlled by the intra-frequency measurement control (FMCS) parameters of the best (according to CPICH Ec/No) active set cell controlled by the serving RNC. The handover control of the RNC reselects the best active set cell after each active set update procedure. The handover control of the RNC updates the intra-frequency measurement control param ters to the UE if the FMCS parameter set changes along with the best active set cell. In addition, the handover control of the RNC updates the intra-frequency measurement

DN03471612 95

WCDMA RAN RRM Handover Control Functionality of intra-frequency handover


control parameters to the UE if the FMCS parameter set changes when the service type (RT/NRT) or the channel type (DCH/HSDPA) changes during the RRC connection.

When the channel type is HSDPA/HSPA, the intra-frequency measurements are con-trolled by the intra-frequency measurement control (FMCS) parameters of the serving HS-DSCH cell. The handover control updates the intra-frequency measurement control parameters to the UE if the FMCS parameter set changes along with the serving cell change.

g The admission control of the RNC may overrule the handover algorithm decision because of capacity reasons. For more information, see Sections Radio resource man-agement functions and Function in abnormal conditions.

10.1.1 Reporting event 1A for adding cells to the active setReporting event 1A is controlled with the following parameters:

• Active Set Weighting Coefficient (ActiveSetWeightingCoefficient) • Addition Time (AdditionTime) • Addition Window (AdditionWindow). • CPICH Ec/No Offset (AdjsEcNoOffset) • Maximum Active Set Size (MaxActiveSetSize)


Reporting event 1A is used for adding cells in the active set. The UE sends the event 1A-triggered measurement report when a cell enters the reporting range as defined by the following formula:

Figure 33 Formula for calculating the UE measurement report on event 1A

The variables in the formula are defined as follows:

Variable Description

MNew Measurement result of the cell entering the reporting range

Mi Measurement result of a cell in the active set, not forbidden to affect the reporting range

NA Number of cells not forbidden to affect the reporting range in the current active set

MBest Measurement result of the strongest cell in the active set, not forbidden to affect the reporting range and not taking into account any cell individual offset

W Active Set Weighting Coefficient (Active-SetWeightingCoefficient) parameter sent from the RNC to the UE

Table 9 Variables for measurement report on event 1A

96 DN03471612




A time-to-trigger mechanism can be used to modify the measurement reporting behav-iour of event 1A. If the time-to-trigger mechanism is used, the cell must continuously stay within the reporting range for a given period of time before the UE can send the event 1A-triggered measurement report to the RNC. The length of this period is controlled by the RNP parameter Addition Time (AdditionTime).

Measurement event 1A can be triggered by monitored set cells and detected set cells. Detected set cells are only taken into account if detected set reporting is enabled in one or more of the active set cells.

10.1.2 Reporting event 1B for deleting cells from the active setReporting event 1B is controlled with the following parameters:

• Active Set Weighting Coefficient (ActiveSetWeightingCoefficient) • Drop Time (DropTime) • Drop Window (DropWindow) • CPICH Ec/No Offset (AdjsEcNoOffset)


Reporting event 1B is used for deleting cells in the active set. The UE sends the event 1B-triggered measurement report when a cell leaves the reporting range as defined by the following formula:

Figure 34 Formula for calculating the UE measurement report on event 1B

The variables in the formula are defined as follows:

R Addition Window (AdditionWindow) parameter sent from the RNC to the UE

H1a Hysteresis, which is zero for event 1A

CIOnew CPICH Ec/No Offset (AdjsEcNoOffset) parameter of the neighbor cell entering the reporting range


Table 9 Variables for measurement report on event 1A (Cont.)


MOld Measurement result of the cell leaving the reporting range

Mi Measurement result of a cell in the active set, not forbidden to affect the reporting range

NA Number of cells not forbidden to affect the reporting range in the current active set

Table 10 Variables for measurement report on event 1B

DN03471612 97



A time-to-trigger mechanism can be used to modify the measurement reporting behav-iour of event 1B. If the time-to-trigger mechanism is used, the cell must continuously stay outside the reporting range for a given period of time before the UE can send the event 1B-triggered measurement report to the RNC. The length of this period is controlled by theDrop Time (DropTime) RNP parameter.

g The RNC does not remove a cell from the active set if it is the only cell in the active set which has uplink physical layer synchronization.

10.1.3 Reporting event 1C for replacing cells in the active setReporting event 1C is controlled with the following parameters:

• Maximum Active Set Size (MaxActiveSetSize) • Replacement Time (ReplacementTime) • Replacement Window (ReplacementWindow). • CPICH Ec/No Offset (AdjsEcNoOffset)


Reporting event 1C is used for replacing cells in the active set. The UE sends the event 1C-triggered measurement report when the number of cells in the active set is equal to the Maximum Active Set Size (MaxActiveSetSize) parameter and a cell that is not included in the active set becomes better than a cell in the active set as defined by the following formula:

Figure 35 Formula for calculating the UE measurement report on event 1C

MBest Measurement result of the strongest cell in the active set, not forbidden to affect the reporting range and not taking into account any cell individual offset.

W Active Set Weighting Coefficient (Active-SetWeightingCoefficient) parameter sent from RNC to UE

R Drop Window (DropWindow) parameter sent from RNC to UE

H1b Hysteresis, which is zero for the event 1B

CIOnew CPICH Ec/No Offset (AdjsEcNoOffset) parameter of the neighbor cell entering the reporting range


Table 10 Variables for measurement report on event 1B (Cont.)

10 logMNew CIONew 10 logMlnAS CIO ASlnHlc2

--------+ +⋅≥+⋅

98 DN03471612




The RNC does not add the monitored/detected cell (that has triggered the reporting event 1C) into the active set if the monitored/detected cell and the active set cells are controlled by the same WCDMA BTS.

In the following figure, cells 1, 2 and 3 are in the active set, but cell 4 is not (yet) in the active set.

Figure 36 A cell that is not in the active set becomes better than a cell in a full active set

A time-to-trigger mechanism can be used to modify the measurement reporting behav-iour of event 1C. If the time-to-trigger mechanism is used, the cell must continuously stay within the triggering condition for a given period of time before the UE can send the event 1C-triggered measurement report to the RNC. The length of this period is con-trolled by the Replacement Time (ReplacementTime)RNP parameter.


MNew Measurement result of the cell not included in the active set

MInAS Measurement result of the cell in the active set which has the lowest measurement result in the active set

MBest Measurement result of the strongest cell in the active set, not forbidden to affect the reporting range

H1c Replacement window parameter sent from the RNC to the UE

CIONew CPICH Ec/No Offset (AdjsEcNoOffset) parameter of the cell not included in the active set

CIOinAS CPICH Ec/No Offset (AdjsEcNoOffset) parameter of the cell in the active set

R1b FMCS DropWindow parameter sent from RNC to UE

Table 11 Variables for measurement report on event 1C

MeasurementquantityCPICH Ec/No CELL 1

CELL 2

CELL 3

CELL 4

Replacement Window

Reportingevent 1C

Time

DN03471612 99



The cell (not included in the active set) leaves the triggering condition if it again becomes worse than the cells in the active set as defined by the following formula:

Figure 37 Formula for calculating the UE measurement report on event 1C

The RNC might add the monitored/detected cell (that has triggered the reporting event 1C) into the active set and remove the active set cell whose combined measurement result and cell individual offset (MInAS+CIOInAS) is the lowest if the monitored/detected cell satisfies the following equation:

If the monitored/detected cell does not satisfy the preceding equation, the RNC checks whether some cell (or cells) are to be removed from the active set. The RNC removes all those active set cells from the active set which does not satisfy the following condi-tion:

Measurement event 1C can be triggered by monitored set cells and detected set cells. Detected set cells are only taken into account if detected set reporting is enabled in one or more of the active set cells.

g The RNC does not replace a cell in the active set if it is the only cell in the active set which has uplink physical layer synchronization.

10.1.4 Event-triggered periodic intra-frequency measurement reportingThe reporting period is controlled with the following parameters:

• Addition Reporting Interval (AdditionReportingInterval) • Replacement Reporting Interval (ReplacementReportingInterval) • Drop Reporting Interval (DropReportingInterval)


When a cell enters the reporting range and triggers event 1A, 1B or 1C, the UE transmits a MEASUREMENT REPORT message to the RNC to update the active set.

The UE reverts to periodical measurement reporting if the RNC does not update the active set after the transmission of the measurement report. The RNC can be unable to add the cell to the active set because of capacity shortage, for example. If the reported cell is not added to or removed from the active set, the UE continues reporting by changing to periodical measurement reporting. This is illustrated in Figure Periodic reporting triggered by event 1A below.

During periodical reporting, the UE transmits measurement report messages to the RAN at pre-defined intervals. The reports include information on the active, monitored and detected (if applicable) cells in the reporting range.

10 logMNew CIONew 10 logM ASln CIOlnASHlc2

--------–+⋅<+⋅

MNew CIONew MBest R1b–>+

MlnAS CIOlnAS MBest R1b–≤+

100 DN03471612




Figure 38 Periodic reporting triggered by event 1A

Event-triggered periodic measurement reporting is terminated either when there are no more active, monitored or detected (if applicable) cell(s) within the reporting range or when the RNC has updated the active set so that it includes the optimal cells.

10.1.5 Time-to-trigger mechanism for modifying measurement reporting behaviourThe value of the time-to-trigger is controlled separately for each event with the following parameters:

• Addition Time (AdditionTime) • Drop Time (DropTime) • Replacement Time (ReplacementTime)


A time-to-trigger parameter can be connected with reporting events 1A, 1B and 1C.

When the time-to-trigger mechanism is applied, the report is triggered only after the con-ditions for the event have existed for the specified time. In the following example, cell 3 enters the reporting range (event 1A), but it is not reported until it has been within the range for the time indicated by the Addition Time (AdditionTime) parameter.

Time

MeasurementquantityCPICH Ec/No

AdditionWindow

CELL 1

CELL 2

CELL 3

Reportingterminated

Event-triggeredreport

Periodicreport

Periodic

report

DN03471612 101



Figure 39 Time-to-trigger limits the number of measurement reports

10.1.6 Identification of an intra-frequency cellHandover control identifies an intra-frequency cell which is reported in the RRC: MEA-SUREMENT REPORT message by comparing the scrambling code of the Primary CPICH of the reported cell with:

1. the primary CPICH scrambling code of the cells included in the combined intra-fre-quency cell list

2. the primary CPICH scrambling code of those intra-frequency neighbor cells of the active set cells that have been left out from the full combined intra-frequency cell list

3. the primary CPICH scrambling code of additional intra-frequency neighbor cells of the active set cells

When detected set reporting based soft handover is enabled in one or more active set cells, handover control proceeds step-by-step in the identification process from the 1st step to the 3rd step until it identifies the reported cell. Handover control does not execute the steps 2 and 3 if detected set reporting or the detected set reporting based soft handover is disabled in all active set cells.

The reported intra-frequency cell can be an active, monitored or detected set cell:

1. an active set cell included in the combined intra-frequency cell list2. a monitored set cell included in the combined intra-frequency cell list3. an intra-frequency neighbor cell defined in the RNW database object ADJS which

has been left out from the full combined intra-frequency cell list4. an additional intra-frequency neighbor cell which is defined in the RNW database

object ADJD and not included in the intra-frequency cell list

If the scrambling code of the Primary CPICH of the reported cell matches with more than one relevant intra-frequency neighbor cells, handover control associates the reported neighbor cell to the active set cell with the higher CPICH Ec/No measurement result. If the scrambling code of the Primary CPICH of the reported cell does not match with any relevant intra-frequency cell, the reported intra-frequency cell remains an unidentified cell.


CELL 1

CELL 2

CELL 3

Reportingrange

Reportingevent 1A

Time

Time-to-trigger

102 DN03471612




10.1.7 Soft handover based on detected set reportingDetected set reporting is based on a 3GPP feature that allows the UE to measure and report any intra-frequency cell which is outside the intra-frequency cell list of the UE. This capability removes the limitation on the length of the intra-frequency cell list. In addition to the active and monitored set cells that are included in the intra-frequency cell list of the UE, the UE can include any detected intra-frequency cell in the event evalu-ation and reporting:

• The UE sends an event 1A/1C triggered measurement report to the RNC when a cell, that is not included in the intra-frequency cell list of the UE, enters the reporting range.

• The Primary CPICH scrambling code identifies the detected set cell that has trig-gered the event 1A/1C measurement report.

The RNC adds the detected set cell into the active set if it is possible to identify the detected set cell, that is the primary CPICH scrambling code of the detected set cell equals to the primary CPICH scrambling code of an intra-frequency neighbor cell. The RNC is not able to identify the detected set cell during anchoring. Detected set reporting is available for all supported bearer services.

The Soft Handover based on Detected Set Reporting feature needs to be enabled on RNC level. For more information on license management see License Management Principles.

When the feature is enabled on RNC level, it can be activated and deactivated on a cell-by-cell basis by modifying the value of the FMCS parameter DSRepBasedSHO.

Handover control activates the detected set reporting for an RRC connection if the Soft Handover Based on Detected Set Reporting feature is enabled on RNC level and either of the following conditions is true:

• Detected set reporting is enabled in one or more active set cells by the FMCS parameter DSRepBasedSHO (value of the parameter is 1). Detected set reporting without soft handover is used to collect statistics on the missing intra-frequency neighbor cell definitions.

• Detected set reporting based soft handover is enabled in one or more active set cells by the FMCS parameter DSRepBasedSHO (value of the parameter is 2).

Note that the E-DCH active set does not affect the procedure. Detected set reporting might increase signaling on Uu interface because an UE reverts to periodical measure-ment reporting if detected set reporting based soft handover is not enabled or if the RNC cannot add the detected cell to the active set because of the missing neighbor cell def-inition. Increased signaling on Uu interface may cause slight degradation of quality. If a dominant neighbor cannot be added to the active set, serious UL interference is caused to the surrounding cells and the call can eventually drop because of poor EbNo.

In the handover decision process, handover control handles detected set cells accord-ing to the value of the FMCS parameter DSRepBasedSHO:

• Detected set cells are excluded from the decision when the value of FMCS param-eter DSRepBasedSHO is 0 (DSR is not allowed) or 1 (DSR is enabled but SHO to detected cell is not allowed).

• Detected cells are taken into account in addition to the active and monitored set cells when the value of FMCS parameter DSRepBasedSHO is 2 (DSR based SHO is enabled). This applies to detected cells which are defined in the ADJS object but are left out from the full combined intra-frequency cell list.

DN03471612 103



• Unknown reported cells are excluded from the handover decision process.

If a detected set cell is added to the active set as a result of the handover decision pro-cedure, handover control adds this new active set cell (ex-detected set cell) and its neighboring cells into the combined intra-frequency cell list which is sent to the UE in the RRC: MEASUREMENT CONTROL message.

If an inter-RNC soft/softer handover is not possible, the handover control initiates an inter-RNC intra-frequency hard handover to the detected set cell as soon as the mea-surement results of the detected set cell satisfy the required conditions.

10.1.8 Cell individual offsets for modifying measurement reporting behav-iourIndividual offsets can be controlled with the CPICH Ec/No Offset (IntraFreqNcellEcNoOffset) parameter.

For a description of the parameter, see WCDMA Radio Network Configuration Param-eters.

The individual offset mechanism can be used to change the reporting of an individual cell, and as a result, to move the cell border. For each cell that is monitored, an offset value can be defined which the UE adds to the measurement result (CPICH Ec/No) of the neighbor cell before it compares the Ec/No value with the reporting criteria. The offset can be either positive or negative.

In the following example, an offset is added to the measurement result of cell 3, and the dotted curve is used in evaluating if an event occurs. Measurement reports from the UE to the RNC are therefore triggered when the cell including the corresponding offset (the dotted curve) leaves and enters the reporting range.

When positive offset is used, as in the following example, the UE sends measurement reports as if the cell (CPICH) is offset x dB better than what it really is. Therefore, cell 3 is included in the active set earlier than should have been the case without the positive offset. The cell in question can reside in an area where it often becomes good very quickly (because of street corners, for instance).

Figure 40 A positive offset is applied to cell 3 before event evaluation in the UE

The cell individual offset can be seen as a tool to move the cell border. It is important to note that the offset is added before triggering events, i.e. the offset is added by the UE before evaluating if a measurement report should be sent as opposed to offsets that are

MeasurementquantityCPICH Ec/No CELL 1

CELL 2

CELL 3

Reportingrange

Offset forCELL 3

Reportingevent 1B

Reportingevent 1A

Time

104 DN03471612




applied in the network and used for the actual handover evaluation. Note that the UE does not include the cell individual offset in the measurement result which is reported to the RNC.

During soft/softer handover, the handover control of the RNC sets the cell individual offsets, which are transmitted to the mobile station, as follows:

1. The handover control sets the cell individual offsets for the intra-frequency neighbor cells of the best (according to CPICH Ec/No) active set cell. Note that an intrafre-quency neighbor cell of the best active set cell can be itself an active set cell.

2. The handover control sets the cell individual offsets for those intra-frequency neighbor cells of the second best active set cell which are not neighbor cells of the best active set cell. Note that an intra-frequency neighbor cell of the second best active set cell can be itself an active set cell.

3. The handover control sets the cell individual offsets for those intra-frequency neighbor cells of the third best active set cell which are not neighbor cells of the best or second best active set cell. Note that an intra-frequency neighbor cell of the third best active set cell can be itself an active set cell.

The handover control of the RNC updates the cell individual offsets to the UE, if needed, after each active set update procedure.

10.1.9 Mechanism for forbidding a cell to affect the reporting rangeThe mechanism for forbidding cells to affect the reporting range is controlled with the following parameter:

• Disable Effect on Reporting Range (AdjsDERR) indicates whether or not the neighbor cell is forbidden to affect the reporting range (addition/drop window) calcu-lation, if it belongs to the active set.

For a description of the parameter, see WCDMA Radio Network Configuration Param-eters.

The Addition Window (AdditionWindow) and Drop Window (DropWindow) parame-ters affect reporting events 1A and 1B. The reporting ranges of events 1A and 1B are relative to the measurement results of those cells in the active set which are not forbid-den to affect the reporting range.

In the following figure, cell 3 is forbidden to affect the reporting range, for example, because it is very unstable in a specific area.

DN03471612 105



Figure 41 Cell 3 is forbidden to affect the reporting range

g The UE ignores the mechanism if all cells in the active set are forbidden to affect the reporting range.

10.1.10 Reporting events 6F and 6G for deleting cells from the active setUE Rx-Tx time difference measurement is controlled with the following parameters:

• Upper Rx-Tx Time Difference Threshold (UpperRxTxTimeDiff) determines the upper threshold which is used by the UE to trigger the reporting event 6F because of UE Rx-Tx time difference.

• Lower Rx-Tx Time Difference Threshold (LowerRxTxTimeDiff) determines the lower threshold which is used by the UE to trigger the reporting event 6G because of UE Rx-Tx time difference.


When the UE Rx-Tx time difference for a cell included in the active set becomes larger than the threshold defined by the parameter Upper Rx-Tx Time Difference Threshold (UpperRxTxTimeDiff), the UE sends an event 6F-triggered measurement report message to the RNC and the RNC deletes the cell from the active set. Similarly, the RNC deletes the cell from the active set if the UE sends an event 6G-triggered measure-ment report message to the RNC when the UE Rx-Tx time difference for the cell has become smaller than the threshold defined by the Lower Rx-Tx Time Difference Thresh-old (LowerRxTxTimeDiff)parameter.

10.1.11 Function in abnormal conditionsThis section describes the functioning of the RNC in case of an unsuccessful soft handover and radio link failure. In abnormal conditions, the RNC can release the RRC connection or order the UE to move to CELL_FACH state to avoid excessive uplink interference. If the conditions for the RRC connection release and the intra-frequency hard handover are met simultaneously, the hard handover has the higher priority.

RRC connection release because of unsuccessful soft handoverWhen an intra-frequency neighbor cell enters the reporting range and triggers either event 1A (cell addition) or event 1C (cell replacement), the UE transmits a measurement


CELL 1

CELL 2

CELL 3

Reportingrange Reporting

range

Time

106 DN03471612




report to the RNC to add the neighbor cell to the active set. If the soft handover branch addition is unsuccessful, the RNC may release the RRC connection or order the UE to move to CELL_FACH state. This is to avoid excessive uplink interference because of non-optimum fast closed loop power control as the UE is not linked to the strongest cell any more when the requested handover branch is clearly the strongest branch or would become the strongest branch. The RRC connection release and state transition to CELL_FACH because of unsuccessful branch addition procedure are performed according to the following rules:

• emergency calls: The RNC does not release emergency call in any case. • AMR + NRT PS multi services: The RNC releases the NRT DCH and retries the

branch addition for the AMR service immediately after the NRT DCH is mapped to DCH/DCH 0/0 kbit/s. If there are several NRT DCHs, the RNC releases one NRT DCH and retries the branch addition for the AMR service and the remaining NRT PS data services. If the retry is unsuccessful, the RNC aborts the ongoing branch addition procedure. The RNC can start another branch addition immediately after the reception of the next event 1A/1C triggered measurement report.

• NRT PS data services: The RNC may order the UE to move to CELL_FACH state when the requested handover branch is clearly the strongest branch. The EnableRRCRelease parameter of the intra-frequency handover path indicates whether the state transition to CELL_FACH state is allowed because of non-optimum fast closed loop power control. In case of RT/NRT multi services, the RNC uses the HOPS parameter set which is defined for real time (RT) radio bearers.

• CS AMR or data services and AMR + RT PS data multi services: the RNC may release the RRC connection when the requested handover branch is clearly the strongest branch. The EnableRRCRelease parameter of the intra-frequency handover path indicates whether the RRC connection release (excluding emer-gency calls) is allowed because of non-optimum fast closed loop power control.

The parameters related to handling of RRC connection release because of an unsuc-cessful soft handover are:

• CPICH Ec/No Averaging Window (EcNoAveragingWindow) determines the number of event triggered periodic intra-frequency measurement reports from which the RNC calculates the averaged CPICH Ec/No values.

• Enable RRC Connection Release (EnableRRCRelease) determines whether RRC connection release (excluding emergency calls) is allowed in situations when soft handover branch addition (or replacement) fails.

• Release Margin for Average Ec/No (ReleaseMarginAverageEcNo) determines the maximum allowed difference between the averaged CPICH Ec/No of the neighbor cell and the averaged CPICH Ec/No of the best cell in the active set in sit-uations when the RNC is not able to perform a soft handover between these cells. If the difference between the averaged CPICH Ec/No values exceeds the value of the parameter, the RNC releases the RRC connection or orders the UE to move to CELL_FACH state (in case of streaming and NRT PS data services) in order to avoid excessive uplink interference because of non-optimum fast closed loop power control.

• Release Margin for Peak Ec/No (ReleaseMarginPeakEcNo) determines the maximum allowed difference between the CPICH Ec/No of the neighbor cell and the CPICH Ec/No of the best cell in the active set in situations when the RNC is not able to perform a soft handover between these cells. If the difference between CPICH Ec/No values exceeds the value of the parameter, the RNC releases the RRC con-

DN03471612 107



nection or orders the UE to move to CELL_FACH state (in case of streaming and NRT PS data services) in order to avoid excessive uplink interference because of non-optimum fast closed loop power control.


The UE proceeds to the periodic measurement reporting if the RNC cannot add the requested cell into the active set. If the forced RRC connection release or state transition to CELL_FACH is allowed, the RNC makes the decision on the release or state transi-tion to CELL_FACH on the basis of the CPICH Ec/No of the best cell in the active set, the CPICH Ec/No of the requested neighbor cell and the Release Margin for Average Ec/No and Release Margin for Peak Ec/No control parameters.

The RRC connection release or state transition to CELL_FACH is required when the measurement results of the requested neighbor cell satisfies one of the following equa-tions:

AveEcNoDownlink + ReleaseMarginforAveEc/No (n) < AveEcNoNcell (n)

or

EcNoDownlink + ReleaseMarginforPeakEc/No (n) < EcNoNcell (n)


The RNC calculates the averaged values from a specified number of periodic intra-fre-quency measurement reports. Averaging is controlled with the CPICH Ec/No Averaging Window (EcNoAveragingWindow) parameter.

Radio link failureWhen a radio link in the active set loses uplink physical layer synchronization, the RNC deletes the radio link (cell) from the active set if the uplink physical layer remains out of synchronization for a period of time which is specified by an internal constant. After the radio link deletion procedure, the UE can start sending reporting event 1A to the RNC to return the cell back to the active set.

If all radio links in the active set lose uplink synchronization, the RNC initiates either an RRC Connection Re-establishment or an RRC Connection Release procedure. For more information, see WCDMA RAN packet data transfer states.

Restart of intra-frequency CPICH Ec/No measurement without detected set reporting If the handover control receives an RRC: MEASUREMENT CONTROL FAILURE message from the UE upon the request to report detected set cells, the handover control


AveEcNoDownlink averaged CPICH Ec/No of the best cell in the active set

AveEcNoNcell(n) averaged CPICH Ec/No of the neighboring cell

EcNoDownlink CPICH Ec/No of the best cell in the active set

EcNoNcell(n) CPICH Ec/No of the neighboring cell

Table 12 Criteria for enabling the RRC connection release

108 DN03471612




restarts the intra-frequency CPICH Ec/No measurement without the detected set report-ing.

10.2 Functionality of intra-frequency hard handoverIntra-frequency hard handover is required to ensure handover between cells controlled by different RNCs in situations when an inter-RNC soft handover is not possible, for example, because of Iur congestion. Furthermore, the Enable Inter-RNC Soft Handover (EnableInterRNCsho) RNP parameter determines whether the inter-RNC handover from the serving cell to a specified neighbor cell is performed as a soft handover or as a hard handover. Exceptions with regards to the HSPA inter-RNC cell change have been described in HSDPA mobility handling in in "WCDMA RAN RRM HSDPA".

The intra-frequency hard handover is controlled with the following RNP parameters:

• Enable Inter-RNC Soft Handover (EnableInterRNCsho) determines whether or not the neighbor cell can participate in a soft handover if it is controlled by an RNC other than the local RNC.

• CPICH Ec/No Averaging Window (EcNoAveragingWindow) determines the number of event-triggered periodic intra-frequency measurement reports from which the RNC calculates the averaged CPICH Ec/No values.

• HHO Margin for Average Ec/No (HHOMarginAverageEcNo) determines the maximum allowed difference between the averaged CPICH Ec/No of the neighbor-ing cell and the averaged CPICH Ec/No of the best active cell in situations when an inter-RNC soft handover is not possible between these cells.

• HHO Margin for Peak Ec/No (HHOMarginPeakEcNo) determines the maximum allowed difference between the CPICH Ec/No of the neighbor cell and the CPICH Ec/No of the best active cell in situations when an inter-RNC soft handover is not possible between these cells.


The RNC makes the intra-frequency hard handover decision on the basis of event-trig-gered periodic intra-frequency measurement reports, which are usually applied to soft handover, and the above-mentioned control parameters. The UE proceeds to the periodic measurement reporting if the RNC cannot add the requested cell into the active set.

The handover decision is based on the downlink Ec/No of the best cell in the active set, downlink Ec/No of the neighbor cell and handover margins which are used as a thresh-old to prevent repetitive hard handovers between cells. The measurement results of the neighbor cell must satisfy one of the following two equations before the intra-frequency hard handover is possible:

AveEcNoDownlink + HHOMarginForAverageEcNo (n) < AveEcNoNcell (n)

or

EcNoDownlink + HHOMarginForPeakEcNo (n) < EcNoNcell (n)


DN03471612 109



The RNC calculates the averaged Ec/No values from a specified number of periodical intra-frequency measurement reports. Averaging is controlled with the CPICH Ec/No Averaging Window (EcNoAveragingWindow). The maximum allowed difference between the averaged or peak CPICH power level of the neighboring cell (n) and that of the best active set cell is defined with a parameter in situations when the RNC cannot perform an inter-RNC soft handover between these cells. If the difference in the averaged or peak Ec/No values exceeds the value of the relevant parameter, the RNC performs an intra-frequency hard handover to avoid excessive uplink interference because of fast closed loop power control that is no longer optimal.

10.2.1 Time interval between hard handover attemptsThe RNC does not set any limit for the minimum interval between the inter-RNC intra-frequency hard handovers. However, to prevent repetitive unsuccessful inter-RNC intra-frequency hard handover attempts to the same target cell, the RNC determines a time interval during which an intra-frequency hard handover to the cell in question is not allowed. The length of the interval is fixed 2 seconds for emergency calls. Otherwise the length of the interval depends on the number of unsuccessful hard handover attempts related to the same target cell during the same RRC connection. This interval increases 2 seconds per unsuccessful hard handover attempt (to the same target cell during the same RRC connection), up to the maximum of 10 seconds. The RNC determines the interval in the following way:

TIME_INTERVAL = min (10 seconds, NUMBER_OF HHO_FAILS * 2 seconds)


AveEcNoDownlink Averaged downlink Ec/No of the best cell in the active set

AveEcNoNcell(n) Averaged downlink Ec/No of the neighbor cell (n)

EcNoDownlink Downlink Ec/No of the best cell in the active set

EcNoNcell(n) Downlink Ec/No of the neighbor cell

Table 13 Measurement result criteria for intra-frequency hard handover

110 DN03471612


Id:0900d8058081a650Confidential

Functionality of inter-frequency handover

11 Functionality of inter-frequency handoverThe RNC makes the decision on the need for Inter-Frequency Handover (IFHO). When an inter-frequency handover is needed, the radio network controller (RNC) orders the user equipment (UE) to start the periodic reporting of inter-frequency measurement results. The RNC recognises the following inter-frequency handover causes:

• inter-frequency handover because of Uplink Dedicated Traffic Channel (DCH) quality

• inter-frequency handover because of UE transmission power • inter-frequency handover because of Downlink Dedicated Physical Channel

(DPCH) power • inter-frequency handover because of Common Pilot Channel (CPICH) RSCP • inter-frequency handover because of CPICH Ec/No • immediate IMSI-based handover (for more information, see Section Functionality of

immediate IMSI-based handover) • load-based handover (for more information, see Section Functionality of load-based

and service-based IF/IS handover) • service-based handover (for more information, see Section Functionality of load-

based and service-based IF/IS handover)

The RNC does not start inter-frequency measurements or handover when only a signal-ing Radio Bearer (SRB) is allocated for the RRC connection.

The RNC makes the handover decision on the basis of periodic inter-frequency mea-surement reports received from the UE and relevant control parameters. The measure-ment reporting criteria and the object information (cells and frequencies) for the inter-frequency measurement are determined by the RNC.

Unless the UE is equipped with dual receivers it can only be tuned to one frequency at a time. Therefore, compressed mode must be used at the physical layer of the radio interface to allow the UE to make the required inter-frequency measurements while maintaining its existing connection.

Once the RNC has decided to attempt an inter-frequency handover, the RNC allocates radio resources from the target cell, establishes a new radio link for the connection between the UE and the target cell, and orders the UE to make an inter-frequency handover to the target cell.

g The admission control of the RNC can overrule the handover algorithm decision because of capacity reasons. For more information, see Section Radio resource man-agement functions in WCDMA RAN RRM packet scheduler.

11.1 Coverage reason inter-frequency handoverThe RNC supports the following inter-frequency handovers because of coverage reasons for both real time (RT) and non-real time (NRT) radio bearers:

• inter-frequency handover because of Uplink DCH quality • inter-frequency handover because of UE transmission power • inter-frequency handover because of CPICH RSCP • Immediate IMSI-based handover (for more information, see Section Functionality of

immediate IMSI-based handover).

DN03471612 111

WCDMA RAN RRM Handover Control Functionality of inter-frequency handover


11.1.1 Inter-frequency handover because of uplink DCH qualityThe quality deterioration report from the uplink outer loop power control can be used to trigger off inter-frequency handover if the serving cell (or cells participating in soft han-dover) has inter-frequency neighbor cells. The uplink outer loop power control sends the quality deterioration report to the handover control if the uplink quality stays constantly worse than the BER/BLER target although the uplink SIR target has reached the maximum value (the UE has reached either its maximum Tx power capability or the maximum allowed transmission power level on the DPCH).

The reporting criteria of the quality deterioration report is controlled with the following RNP parameters. For a description of the parameters, see WCDMA Radio Network Configuration Parameters:

• Quality deterioration report from UL OLPC controller (EnableULQualDetRep) parameter indicates whether or not the uplink outer loop PC can send a quality dete-rioration report to the handover control in situations when the quality stays worse than the BER/BLER target despite of the maximum uplink SIR target.

• UL quality deterioration reporting threshold (ULQualDetRepThreshold) parame-ter determines the period during which the quality must constantly stay worse than the BER/BLER target (despite of the maximum uplink SIR target) before the uplink outer loop PC can send a quality deterioration report.

The uplink OLPC repeats the quality deterioration reports to the handover control peri-odically until the uplink SIR target decreases below the maximum value.

The IFHO caused by UL DCH Quality (IFHOcauseUplinkQuality) RNP parameter indicates whether or not an inter-frequency handover caused by Uplink DCH quality is enabled. In case of RT data connection (CS or PS), also the maximum allocated user bitrate on the uplink DPCH must be lower than or equal to the bitrate threshold which is controlled with the Maximum Allowed UL User Bitrate in HHO (HHoMaxAllowedBitrateUL) RNP parameter, before the RNC can start the inter-fre-quency measurement because of Uplink DCH quality. This limitation in uplink bitrate is not applied for NRT services. When the inter-frequency handover/measurement is enabled, the RNC starts the inter-frequency measurement. For more information, see Section Measurement procedure for inter-frequency handover.

The RNC makes the handover decision on the basis of periodic inter-frequency mea-surement reports received from the UE and relevant control parameters. For more infor-mation, see Section Handover decision procedure for coverage reason inter-frequency handover.

11.1.2 Inter-frequency handover because of UE transmission powerIf the serving cell (or cells participating in soft handover) has inter-frequency neighbor cells, an event-triggered UE transmission power measurement report can be used to trigger off inter-frequency handover when the transmission power of the UE approaches either its maximum RF output power capability or the maximum transmission power level the UE can use on the DPCH.

The IFHO caused by UE TX Power (IFHOcauseTxPwrUL) RNP parameter indicates whether an inter-frequency handover to GSM caused by UE transmission power is enabled or not. In addition, the maximum allocated user bitrate on the uplink DPCH must be lower than or equal to the bitrate threshold which is controlled with theMaximum Allowed UL User Bitrate in HHO (HHoMaxAllowedBitrateUL) RNP parameter,

112 DN03471612




before the RNC can start the inter-frequency measurement because of UE transmission power. When the inter-frequency handover/measurement is enabled, the RNC starts a UE-internal measurement to monitor the UE transmission power level. The measure-ment reporting criteria for the UE transmission power measurement is controlled with the following RNP parameters:

• UE TX Power Filter Coefficient (InterFreqUETxPwrFilterCoeff) parameter controls the higher layer filtering (averaging) of the physical layer transmission power measurements in the UE. The physical layer measurement period for the UE transmission power is one slot.

• UE TX Power Threshold for AMR (InterFreqUETxPwrThrAMR) determines the UE transmission power threshold for a circuit-switched voice connection.

• UE TX Power Threshold for CS (InterFreqUETxPwrThrCS) determines the UE transmission power threshold for a circuit-switched data connection.

• UE TX Power Threshold for NRT PS (InterFreqUETxPwrThrNrtPS) determines the UE transmission power threshold for a non-real time packet-switched data con-nection.

• UE TX Power Threshold for RT PS (InterFreqUETxPwrThrRtPS) determines the UE transmission power threshold for a real-time packet-switched data connection.

• UE TX Power Time Hysteresis (InterFreqUETxPwrTimeHyst) determines the time-to-trigger, that is the time period between the detection of the following mea-surement events and the sending of the measurement report: • Event 6A: The UE transmission power must stay above the transmission power

threshold for this time period before the inter-frequency handover is triggered. • Event 6B: The UE transmission power must stay below the transmission power

threshold before the UE calls off the handover cause.

Note that the UE transmission power is not used as a handover cause for a service type if the value of the corresponding UE transmission power threshold parameter is ‘not used’. The power thresholds are relative to the maximum transmission power level a UE can use on the DPCH in the cell (or the maximum RF output power capability of the UE in WCDMA, whichever is lower). In case of multi service, the RNC selects the parame-ters in the following order: 1st priority AMR, 2nd priority CS data, 3rd priority RT PS data and 4th priority NRT PS. For the description of the parameters, see WCDMA Radio Network Configuration Parameters.

If the UE transmission power becomes greater than the reporting threshold (event 6), the UE sends the measurement report (event 6A) to the RNC, and the RNC starts the inter-frequency measurement as described in Section Measurement procedure for inter-frequency handover.

The RNC makes the handover decision on the basis of periodical inter-frequency mea-surement reports received from the UE and relevant control parameters, as described in Section Handover decision procedure for coverage reason inter-frequency handover.

If the UE transmission power measurement is used to trigger inter-frequency measure-ment, the time-to-trigger is controlled with the InterFreqUETxPwrTimeHyst param-eter. If the UE transmission power measurement is used to trigger inter-RAT measurement, the time-to-trigger is controlled with the GsmUETxPwrTimeHyst param-eter. If both inter-frequency handover and inter-system handover to GSM are enabled, the RNC selects the greater parameter value for the Time-To-Trigger IE.

g The RNC does not break off ongoing inter-frequency measurement even if the transmis-sion power of the UE decreases below the reporting threshold (event 6B) during the

DN03471612 113



measurement and the UE sends the corresponding measurement report (event 6B) to the RNC.

11.1.3 Inter-frequency handover because of CPICH RSCPReceived Signal Code Power (RSCP) measurement result on the Primary CPICH can be used to trigger off inter-frequency handover if the serving cell (or cells participating in soft handover) has inter-frequency neighbor cells.

The IFHO caused by CPICH RSCP (IFHOcauseCPICHrscp) RNP parameter indicates whether an inter-frequency handover caused by low measured absolute CPICH RSCP is enabled or not. When the inter-frequency handover is enabled, the RNC sets up an intra-frequency measurement to monitor the absolute CPICH RSCP value. The mea-surement reporting criteria for the intra-frequency CPICH RSCP measurement is con-trolled with the following RNP parameters:

• CPICH RSCP HHO Threshold (HHoRscpThreshold) parameter determines the absolute CPICH RSCP threshold which is used by the UE to trigger the reporting event 1F.parameter

• CPICH RSCP HHO Time Hysteresis (HHoRscpTimeHysteresis) determines the time period during which the CPICH RSCP of the active set cell must stay worse than the threshold HHoRscpThreshold before the UE can trigger the reporting event 1F.

• CPICH RSCP HHO Cancellation (HHoRscpCancel) parameter determines the absolute CPICH RSCP threshold which is used by the UE to trigger the reporting event 1E.

• CPICH RSCP HHO Cancellation Time (HHoRscpCancelTime) parameter deter-mines the time period during which the CPICH RSCP of the active set cell must stay better than the threshold HHoRscpCancel before the UE can trigger the reporting event 1E.

• CPICH RSCP HHO Filter Coefficient (HHoRscpFilterCoefficient) parameter controls the higher layer filtering (averaging) of physical layer CPICH RSCP mea-surements before the event evaluation and measurement reporting is performed by the UE. The UE physical layer measurement period for intra-frequency CPICH RSCP measurement is 200 ms.

If the CPICH RSCP measurement result of an active set cell becomes worse than or equal to the absolute threshold/parameter HHoRscpThreshold, the UE sends an event 1F-triggered measurement report to the RNC. The UE cancels event 1F by sending an event 1E-triggered measurement report to the RNC if the CPICH RSCP measurement result of the active set cell increases again and becomes better than or equal to the threshold HHoRscpCancel. If the CPICH RSCP measurement result of all active set cells has become worse than the reporting threshold HHoRscpThreshold (event 1F is valid for all active set cells simultaneously), the RNC starts the inter-frequency measure-ment as described in Section Measurement procedure for inter-frequency handover.

The RNC makes the handover decision on the basis of periodic inter-frequency mea-surement reports received from the UE and relevant control parameters, as described in Section Handover decision procedure for coverage reason inter-frequency handover.

g The RNC does not break off ongoing inter-frequency measurement even if the measured CPICH RSCP of one or more active set cells increases again above the

114 DN03471612




reporting threshold HHoRscpCancel and the UE sends the corresponding event 1E trig-gered intra-frequency measurement report to the RNC.

11.1.4 Handover decision procedure for coverage reason inter-frequency handoverAn inter-frequency handover because of coverage reasons is possible when the signal of the best neighbor cell meets the conditions in the following equations:

Figure 42 Conditions for inter-frequency handover because of coverage reasons.

In the above equations, AVE_RSCP_NCELL(n) and AVE_EcNo_NCELL (n) are the averaged CPICH Ec/No and RSCP values of the best (according to CPICH Ec/No) neighbor cell (n). AVE_CPICH_RSCP is the averaged CPICH RSCP of the best (according to pathloss) active set cell.

The Minimum CPICH Ec/No for IFHO (AdjiMinEcNo) RNP parameter determines the minimum required CPICH Ec/No (dB) level in the best neighbor cell (n). The RNP parameter Pathloss Margin for IFHO (AdjiPlossMargin) determines the margin (dB) by which the propagation loss of the best active set cell must exceed the propagation loss of the best neighbor cell (n) before the inter-frequency handover is possible.

CPICH_POWER indicates the transmission power of the Primary CPICH of the best active set cell. CPICH_POWER_NCELL (n) indicates the downlink transmission power of the Primary CPICH of the best neighbor cell (n).

The neighbor Cell Search Period (InterFreqNcellSearchPeriod) RNP parameter determines the period starting from inter-frequency measurement setup during which an inter-frequency handover is not possible. After the period has expired, the RNC evalu-ates the radio link properties of the best neighbor cell after every inter-frequency mea-surement report. The RNC performs the inter-frequency handover to a best neighbor (target) cell as soon as the best neighbor cell meets the required radio link properties.

Regarding averaging values, the RNC calculates them directly from the measured dB and dBm values, linear averaging is not used in this case. The sliding averaging window is controlled with the Measurement Averaging Window (InterFreqMeasAveWindow) RNP parameter. The RNC starts averaging already from the first measurement sample, that is, the RNC calculates the averaged values from those measurement samples which are available until the number of samples is adequate to calculate averaged values over the whole averaging window.

11.2 Quality reason inter-frequency handoverThe RNC supports the following quality reason inter-frequency handovers for both real time (RT) and non-real time (NRT) radio bearers:

• inter-frequency handover because of Downlink DPCH power • inter-frequency handover because of CPICH Ec/No

AVE_EcNo_NCELL(n) AdjiMinEcNo(n)

CPICH_POWER AVE_CPICH RSCP CPICH_POWER_NCELL(n)AVE_RSCP_NCELL(n)

–AdjiPlossMargin(n)+

>–

>

DN03471612 115



11.2.1 Inter-frequency handover because of downlink DPCH powerThe BTS measures and averages the downlink code power of each radio link separately and reports the averaged measurement results to the controlling RNC at regular inter-vals with a 3GPP NBAP: DEDICATED MEASUREMENT REPORT. The BTS measures the downlink code power from the pilot bits of the dedicated physical control channel (DPCCH). In case of an inter-RNC soft handover, the drifting RNC forwards the mea-surement results to the serving RNC in the RNSAP: DEDICATED MEASUREMENT REPORT message.

In 3GPP NBAP the Reporting Period is controlled with the Dedicated Measurement Reporting Period (DediMeasReportPeriod), Dedicated Measurement Reporting Period CS data (DediMeasRepPeriodCSdata), Dedicated Measurement Reporting Period PS data (DediMeasRepPeriodPSdata)RNP parameters. All of these mea-surement reports can trigger off inter-frequency handover when the downlink transmis-sion power of the radio link approaches its maximum allowed power level.

The IFHO caused by DL DPCH TX Power (IFHOcauseTxPwrDL) RNP parameter determines whether an inter-frequency handover caused by high downlink DPCH power level is enabled or not. In addition, the maximum allocated user bit rate on the downlink DPCH must be lower than or equal to the bitrate threshold defined by the Maximum Allowed DL User Bitrate in HHO (HhoMaxAllowedBitrateDL)RNP parameter, before the RNC can start the inter-frequency measurement and handover because of Downlink DPCH power.

When the handover to GSM is enabled, the RNC starts the inter-frequency measure-ment procedure (as described in Section Measurement procedure for inter-frequency handover) if the measured downlink code power of a single radio link meets the condi-tion in the following equation:

Figure 43 Measured downlink code power calculation.

The variables in the formula are defined in the Table 14 Variables for inter-frequency handover.


DL_CODE_PWR indicates the measured downlink code power

PowerOffsetDLdpcchPilot a constant that defines the power offset for the pilot fields of the DPCCH, expressed as a relative value with respect to the DPDCH power

CPICH_POWER indicates the transmission power of the primary CPICH of an active set cell

MAX_DL_DPCH_TXPWR indicates the maximum transmission power level of the DPDCH symbols a base station can use on the DPCH, expressed as a relative value (dB) with respect to the primary CPICH power (dBm).

Table 14 Variables for inter-frequency handover

DL_CODE_PWR PowerOffsetDLdpcchPilot CPICH_POWERMAX_DL_DPCH_TXPWR DL_DPCH_TXPWR_THRESHOLD

++

≥–

116 DN03471612




The RNC makes the handover decision on the basis of periodic inter-frequency mea-surement reports received from the UE and relevant control parameters, as described in Section Handover decision procedure for quality reason inter-frequency handover.

11.2.2 Inter-frequency handover because of CPICH Ec/NoThe IFHO caused by CPICH Ec/No (IFHOcauseCPICHEcNo) RNP parameter indicates whether an inter-frequency handover caused by low measured absolute CPICH Ec/No is enabled or not. When the inter-frequency handover is enabled, the RNC sets up an intra-frequency measurement to monitor the absolute CPICH Ec/No value. The mea-surement reporting criteria for the intra-frequency CPICH Ec/No measurement is con-trolled by the following parameters:

DL_DPCH_TXPWR_THRESHOLD Is controlled with the following inter-fre-quency measurement control parameters, depending on the service type:

• DL DPCH TX Power Threshold for RT PS (InterFreqDLTxPwrThrRtPS) determines the downlink DPCH trans-mission power threshold for a real-time packet-switched data connection.

• DL DPCH TX Power Threshold for NRT PS (InterFreqDLTxPwrThrN-rtPS) determines the downlink DPCH transmission power threshold for a non-real time packet-switched data connection.

• DL DPCH TX Power Threshold for CS (InterFreqDLTxPwrThrCS) deter-mines the downlink DPCH transmis-sion power threshold for a circuit-switched data connection.

• DL DPCH TX Power Threshold for AMR (InterFreqDLTxPwrThrAMR) determines the downlink DPCH trans-mission power threshold for a circuit-switched voice connection.

The downlink DPCH transmission power thresholds are relative (dB) to the allocated maximum transmission power of the DPCH.

In case of a multiservice, the RNC selects the lowest threshold value for the calcula-tion (for example, when the alternative threshold values are -1dB and -3dB, the RNC selects the -3dB threshold value). Downlink transmission power is not to be used as a handover cause for a service type if the value of the corresponding threshold parameter is 'not used'.


Table 14 Variables for inter-frequency handover (Cont.)

DN03471612 117



• CPICH Ec/No HHO Threshold (HHoEcNoThreshold) determines the absolute CPICH Ec/No threshold which is used by the UE to trigger the reporting event 1F.

• CPICH Ec/No HHO Time Hysteresis (HHoEcNoTimeHysteresis) parameter determines the time period during which the CPICH Ec/No of the active set cell must stay worse than the threshold HHoEcNoThreshold before the UE can trigger the reporting event 1F.

• CPICH Ec/No HHO Cancellation (HHoEcNoCancel) parameter determines the absolute CPICH Ec/No threshold which is used by the UE to trigger the reporting event 1E.

• CPICH Ec/No HHO Cancellation Time (HHoEcNoCancelTime) parameter deter-mines the time period during which the CPICH Ec/No of the active set cell must stay better than the threshold HHoEcNoCancel before the UE can trigger the reporting event 1E.

• CPICH Ec/No Filter Coefficient (EcNoFilterCoefficient) parameter controls the higher layer filtering (averaging) of physical layer CPICH Ec/No measurements before the event evaluation and measurement reporting is performed by the UE. The UE physical layer measurement period for intra-frequency CPICH Ec/No measure-ments is 200 ms.

If the CPICH Ec/No measurement result of an active set cell becomes worse than or equal to the absolute threshold (HHoEcNoThreshold parameter), the UE sends the event 1F-triggered measurement report to the RNC. The UE cancels event 1F by sending an event 1E-triggered measurement report to the RNC if the CPICH Ec/No measurement result of the active set cell increases again and becomes better than or equal to the threshold HHoEcNoCancel parameter. If the CPICH Ec/No measurement result of all active set cells has become worse than the reporting threshold - HHoEcNoThreshold parameter (event 1F is valid for all active set cells simultane-ously), the RNC starts the inter-frequency measurement as described in Section Mea-surement procedure for inter-frequency handover.

The RNC makes the handover decision on the basis of periodic inter-frequency mea-surement reports received from the UE and relevant control parameters, as described in Section Handover decision procedure for quality reason inter-frequency handover.

g The RNC does not break off ongoing inter-frequency measurement even if the measured CPICH Ec/No of one or more active set cells increases again above the reporting threshold HHoEcNoCancel and the UE sends the corresponding event 1E trig-gered intra-frequency measurement report to the RNC.

11.2.3 Handover decision procedure for quality reason inter-frequency handoverThe measurement results of the inter-frequency neighboring cell must satisfy the follow-ing equations before the inter-frequency handover or cell change to GSM/GPRS is pos-sible:

Figure 44 Measurement results of the inter-frequency neighboring cell calculation.

AVE_RSCP_NCELL(n) AdjiMinRSCP(n) max 0,AdjiTxPwrDPCH(n) P_MAX–( )

AVE_EcNo_NCELL(n) AVE_CPICHEcNo AdjiEcNoMargin(n)+>

+>

118 DN03471612




In the equations above, AVE_RSCP_NCELL(n) and AVE_EcNo_NCELL are the averaged CPICH Ec/No RSCP values of the best (according to CPICH Ec/No) neigh-boring cell (n).

AVE_CPICH_EcNo is the averaged CPICH Ec/No of the best active set cell.

The Minimum CPICH RSCP for IFHO (AdjiMinRSCP)(n) parameter determines the minimum required CPICH RSCP (dBm) level in the best neighboring cell (n).

The CPICH Ec/No Margin for IFHO (AdjiEcNoMargin) (n) parameter determines the margin (dB) by which the CPICH Ec/No of the best neighboring cell (n) must exceed the CPICH Ec/No of the best active set cell before the inter-frequency handover is possible. The neighbor cell parameter AdjiTxPwrDPCH(n) indicates the maximum transmission power level (dBm) a UE can use on the DPCH. P_MAX indicates the maximum RF output power capability of the UE (dBm).

The neighbor Cell Search Period (InterFreqNcellSearchPeriod) parameter deter-mines the period starting from inter-frequency measurement setup during which an inter-frequency handover is not possible. After the period has expired, the RNC evalu-ates the radio link properties of the best neighbor cell after every inter-frequency mea-surement report. The RNC performs the inter-frequency handover to a best neighboring (target) cell as soon as the best neighboring cell meets the required radio link properties.

Regarding averaging values, the RNC calculates them directly from the measured dB and dBm values, linear averaging is not used in this case. The sliding averaging window is controlled with the Measurement Averaging Window (interFreqMeasAveWindow)parameter. The RNC starts averaging already from the first measurement sample, that is, the RNC calculates the averaged values from those measurement samples which are available until the number of samples is adequate to calculate averaged values over the whole averaging window.

11.3 HSDPA inter-frequency handoverHSDPA inter-frequency handover introduces compressed mode and inter-frequency measurement capability for connections which simultaneously utilise HSDPA. In addi-tion, direct HSPA allocation in the target cell is provided. HSDPA inter-frequency handover can be triggered because of quality, coverage, HSPA capability and immedi-ate IMSI based handover reasons and is available for all supported HSPA services and service combinations.

Based on inter-frequency handover (IFHO) triggers, compressed mode is started directly while HSDPA is configured. If HSPA is allocated, channel type switching to a suitable HSDPA configuration is needed. Therefore, the total handover execution time decreases for HSDPA services but remains the same for HSPA services.

HSDPA compressed mode can be activated for an UE if all of the following conditions are true:

• The HSDPA Inter-Frequency Handover feature is enabled for the RNC. • HSDPA mobility is enabled with the HSDPAMobility configuration parameter. • DCH compressed mode is enabled with the RNC-wide configuration parameter

CMmasterSwitch. • In case of inter-frequency handover over Iur, HSDPA compressed mode is enabled

by the VBTS (Virtual BTS object) parameter BTSSupportForHSPACM.

DN03471612 119



For more information on compressed mode for HSDPA see Section Compressed mode.

In the event of an intra-RNC inter-frequency, inter-RNC inter-frequency, and inter-RNC intra-frequency hard handover, HSPA can be allocated for the UE without checking whether the HSDPA Inter-Frequency Handover feature is enabled in the target cell.

During HSDPA compressed mode, HSDPA serving cell change can be triggered only to a target cell which supports HSDPA compressed mode. If such target cell cannot be found and the current serving cell cannot be kept, channel type switching to DCH is per-formed and compressed mode is reconfigured to DCH compressed mode. In both cases the inter-frequency handover measurement itself continues without changes.

Coverage and quality based HSDPA inter-frequency handoversIf the HSDPA Inter-Frequency Handover feature is enabled, quality and coverage based HSDPA inter-frequency handovers are performed as follows:

• If HS-DSCH/DCH with or without AMR is allocated, compressed mode and inter-fre-quency measurement is started directly without transport channel modification.

• If HS-DSCH/E-DCH with or without AMR is allocated, uplink transport channel mod-ification to HS-DSCH/DCH configuration is performed first and after that com-pressed mode and inter-frequency measurement are started immediately.

Target cells for an HSPA inter-frequency handover can be intra-BTS, inter-BTS intra-RNC, or inter-BTS inter-RNC cells. HS-DSCH/E-DCH configurations are reconfigured to HS-DSCH/DCH independent of the need for compressed mode to perform the measure-ments. During uplink transport channel modification to HS-DSCH/DCH configuration, DCH(s) are allocated with initial bit rate. If this reconfiguration does not succeed, the radio bearer(s) are mapped to DCH/DCH 0/0 kbps and a handover attempt is started immediately for AMR services. When only a signaling radio bearer (SRB) is allocated for the RRC connection, new allocation and handover trigger are awaited. Penalty timer based on the HsdschGuardTimerHO parameter is started when radio bearer(s) are mapped to DCH/DCH 0/0 kbps in order to restrict immediate HS-DSCH re-allocation attempts. If HSDPA inter-frequency handover is not activated, HSPA services are reconfigured to DCH/DCH services and after that compressed mode is started immedi-ately for AMR services. When only a signaling radio bearer (SRB) is allocated for the RRC connection, a new allocation and handover trigger is awaited.

Intra-frequency serving RNC relocation is not performed while compressed mode is active. Compressed mode is stopped in downlink direction and afterward relocation is performed. It is then up to the target RNC to start compressed mode again. It is suitable to stop compressed mode before the relocation since the target RNC needs to start measuring from the beginning if it is still needed. The uplink DCH, however, can be in compressed mode during intra-frequency serving RNC relocation.

For more information on inter-frequency measurement control parameters (FMCI) and inter-frequency handover path parameters (HOPI) see WCDMA RAN RRM HSDPA and WCDMA RAN RRM HSUPA.

Failed HSDPA inter-frequency handoverAfter a failed HSDPA inter-frequency handover, the RNC continues with an inter-system handover attempt in the event of:

• The RAB based Service Handover IE does not deny inter-system handover with value “Handover to GSM is not to be performed” in any of the UE's RABs.

120 DN03471612




• Quality, coverage, or immediate IMSI based inter-system handover is allowed and triggered.

Channel type switching to a DCH/DCH configuration is performed first and after that an inter-system handover attempt is started immediately. If this reconfiguration does not succeed, the radio bearer(s) are mapped to DCH/DCH 0/0 kbps and a handover attempt is started immediately for AMR services. When only a signaling radio bearer (SRB) is allocated for the RRC connection, a new allocation and handover trigger is awaited. Penalty timer based on parameter HsdschGuardTimerHO is started when radio bearer(s) are mapped to DCH/DCH 0/0 kbps in order to restrict immediate HS-DSCH re-allocation attempts.

If the inter-system handover is not performed, the UE remains in the current cell and RNP parameter InterFreqMinMeasInterval is set. A new or active pending handover trigger is needed for further handover actions. Channel type switching to an HSPA configuration, that is DL:HS-DSCH and UL:E-DCH, is forbidden as long as there is at least one active inter-system handover cause. After all inter-system handover causes are canceled, channel type switching to HSPA configuration is possible again.

If the inter-system handover attempt was unsuccessful, the UE remains in the current cell and RNP parameter(s) InterFreqMinMeasInterval and/or GsmMinMeasInter-val are set. A new or active pending handover trigger is needed for further handover actions. Channel type switching to HSPA/HSDPA configuration, that is DL:HS-DSCH and UL:E-DCH or UL:DCH, is forbidden as long as there is at least one active inter-system handover cause. After all inter-system handover causes are canceled, channel type switching to HSPA/HSDPA configuration is possible again.

If there is at least one inter-frequency handover cause and at least one inter-system handover cause active simultaneously, handover control applies that one from the previous two rules which is applicable for the preferred handover target system.

If the HSDPA inter-frequency handover feature is disabled and any inter-frequency or inter-system handover cause is active, channel type switching to HSPA/HSDPA config-uration, that is DL:HS-DSCH and UL:E-DCH or UL:DCH, is forbidden. After all handover causes are canceled, channel type switching to HSPA/HSDPA configuration is possible again.

Number of parallel reporting criteria Inter-Frequency measurements for HSDPA require an additional intra-frequency mea-surement to compare the inter-frequency handover decision. In the event of an HSDPA inter-frequency handover situation with all possible handover causes available, intra-fre-quency measurement event 1F for CPICH EcNo is removed before the additional intra-frequency measurement is added. If the measurements do not trigger the handover and the UE stays in the serving cell(s), the additional intra-frequency measurement is removed and after that measurement event 1F for CPICH EcNo is reconfigured.

HSPA capability based handoverIf HSDPA inter-frequency handover is enabled, HSPA capability based inter-frequency handover is performed as follows:

• HS-DSCH/DCH is allocated: Compressed mode and measurement are started directly based on current event based triggering (inactivity) without transport channel modification.

• HS-DSCH/E-DCH is allocated: The uplink transport channel is modified to HS-DSCH/DCH configuration first based on the current event based trigger (inactivity)

DN03471612 121



and after that compressed mode and measurement are started immediately. DCH(s) are allocated with minimum bit rate. If the reconfiguration is not successful, the RB(s) are mapped to DCH/DCH 0/0 kbps (SRB only) and new allocation and handover trigger are awaited. The penalty timer based on the HsdschGuardTimerHO parameter is started when RB(s) are mapped to DCH/DCH 0/0 kbps in order to restrict immediate HS-DSCH re-allocation attempts.

Reconfiguration from HS-DSCH/E-DCH to HS-DSCH/DCH configuration is performed independent of the decision on the start of compressed mode. If HSDPA inter-frequency handover is not enabled, the handover is based on periodic triggering when DCH/DCH is allocated and on event based triggering (inactivity) when HS-DSCH/E-DCH or HS-DSCH/DCH is allocated. In event based triggering HS-DSCH/E-DCH or HS-DSCH/DCH is first reconfigured as pure DCH configuration and after that compressed mode is started immediately.

Target cells for HSPA capability based inter-frequency handover can be intra-BTS, inter-BTS intra-RNC, inter-BTS inter-RNC, or I-HSPA cells.

11.4 Interactions between handover causesThe handover cause, which has triggered first has the highest priority. That is, the RNC does not stop or modify ongoing inter-frequency measurement and handover decision procedures if another handover cause is triggered during the handover procedures. If two or more inter-frequency handover causes are triggered simultaneously, the RNC selects the cause, which has the highest priority. The priority order is the following:

1. immediate IMSI-based inter-frequency handoverImmediate IMSI-based inter-frequency handover has higher priority than the other inter-frequency handover causes (for more information, see Section Functionality of immediate IMSI-based handover).

2. quality and coverage reason inter-frequency handoversThe RNC supports the following quality and coverage reason inter-frequency han-dovers (the handover causes are not presented in any particular order): • inter-frequency handover because of Uplink DCH quality • inter-frequency handover because of UE Tx power • inter-frequency handover because of Downlink DPCH power • inter-frequency handover because of CPICH RSCP • inter-frequency handover because of CPICH Ec/No

3. load-based inter-frequency handoverFor more information, see Section Functionality of load-based and service-based IF/IS handover.

4. service-based inter-frequency handoverFor more information, see Section Functionality of load-based and service-based IF/IS handover.

11.5 Interaction with handover to GSMIf the serving cell (or cells participating in soft handover) has neighbor cells both on another carrier frequency and on another RAT (GSM), the RNC determines the priorities between inter-frequency and inter-system handovers on the basis of Service Handover IE value. The RNC receives the Service Handover IE from the core network in the RAB ASSIGNMENT REQUEST or RELOCATION REQUEST (RANAP) message. If the RNC

122 DN03471612




does not receive the Service Handover IE from the core network, inter-frequency handover has priority over inter-system handover to GSM as a default value.

• Should be handed over to GSM:Inter-system handover takes precedence over inter-frequency handover. In this case the RNC does not start inter-frequency measurements until the inter-system measurements have been completed, that is, when no neighbor GSM cell is good enough for the quality and/or coverage reason handover.

• Should not be handed over to GSM:Inter-frequency handover takes precedence over inter-system handover. In this case the RNC does not start the inter-system measurements until the inter-fre-quency measurements have been completed, that is, when no neighboring cell is good enough for the quality and/or coverage reason inter-frequency handover.

• Shall not be handed over to GSM:In this case, the RNC does not start inter-system measurements or handover to GSM even if no neighbor cell is good enough for the quality and/or coverage reason inter-frequency handover. This means that the RNC does not initiate handover to GSM for the UE unless the RABs with this indication have first been released with the normal release procedures.

In the event of directed emergency call inter-system handover, the RRC connection is handed over to GSM even if the Service Handover IE has the value Should not be handed over to GSM or Shall not be handed over to GSM for one radio access bearer of the RRC connection. The RNC initiates the handover to GSM for the RRC connection despite the radio access bearers with this indication. If the RNC does not receive the Service Handover IE from the core network for a directed emergency call inter-system handover, the handover to GSM has a higher priority than the inter-frequency handover.

If WPS is enabled, a WPS call is handed over to GSM during the RAB setup even if the Service Handover IE has the value Should not be handed over to GSM or Shall not be handed over to GSM for an AMR radio access bearer of the RRC connection. This is valid for the RAB setup phase only. The WPS feature does not support multi-RABs.

If directed retry of AMR calls is enabled, an AMR call is handed over during the RAB setup to GSM even if the Service Handover IE has the value Should not be handed over to GSM or Shall not be handed over to GSM for the AMR RAB of the RRC connection. This is valid for the RAB setup phase only. The Directed Retry feature does not support multi-RABs.

11.6 Interaction with handover to GAN Inter-RAT handover to GAN has a higher priority than inter-frequency handover. An event 3A triggered measurement report initiates inter-RAT handover to GAN also during inter-frequency measurements.

11.7 Control parameters of inter-frequency handoverThe different inter-frequency handover causes are enabled separately for each handover cause (for example, inter-frequency handover because of UE Tx power). The relevant radio network configuration parameters belong to the inter-frequency measure-ment control parameters which are defined separately for each cell by attaching a spec-ified measurement control parameter set (or sets) to a specified cell. The radio network

DN03471612 123



database is to have 100 separate measurement control parameter sets for inter-fre-quency measurements.

All cells in the RAN can use the same set of inter-frequency measurement control parameters or the cells might have a tailored set of measurement control parameters for real time (RT) and for non-real time (NRT) radio bearers. Measurement parameters are controlled on a set-by-set basis by means of the O&M, by using the local user interface in the RNC site or the network management system (NMS).

The handover control of the RNC enables an inter-frequency handover cause when the handover cause in question is enabled in the inter-frequency measurement control (FMCI) parameters of an active set cell which has also inter-frequency neighbor cells. If the active set consists of more than one cell then all possible causes, which are enabled in at least one cell, are considered. The CPICH Ec/No and RSCP thresholds related to the inter-frequency handover causes are determined by the intra-frequency license measurement control (FMCS) parameters of the active set cell which is the strongest cell according to the CPICH Ec/No measurement results reported by the UE.

When the channel type is DCH, the inter-frequency measurement and handover are controlled by the inter-frequency measurement control (FMCI) parameters of the best (according to CPICH Ec/No) active set cell (controlled by the SRNC) which has the handover cause in question enabled and which has inter-frequency neighbor cells. The handover control re-selects the controlling FMCI parameter set after each active set update procedure. In addition, the controlling FMCI parameter set can change if the service type (RT/NRT) or the channel type (DCH/HSDPA) changes during the RRC con ection. Note that the handover control does not modify onqoing periodical inter-fre-quency measurement if the controlling FMCI parameter set changes during the mea-surement.

When the channel type is HSDPA, the inter-frequency measurement and handover are controlled by the inter-frequency measurement control (FMCI) parameters of the serving HS-DSCH cell. The handover control re-selects the FMCI parameter set after the serving cell change. Note that, the handover control does not modify ongoing periodical inter-frequency measurement if the FMCI parameter set changes during the measure ent.

11.8 Measurement procedure for inter-frequency handoverThe measurement procedure, the scenario of which is presented in Figure 45 Measuring procedure for inter-frequency handover, is controlled by a number of parameters set during the radio network planning. These parameters are:

1. Measurement Reporting Interval (InterFreqMeasRepInterval)This parameter determines the measurement reporting interval for periodical inter-frequency measurements.

2. Neighbor Cell Search Period (InterFreqNcellSearchPeriod)This parameter determines the number of periodic inter-frequency measurement reports, starting from the first report after the measurement setup, during which an inter-frequency handover is not allowed. This period allows the UE to find and report all potential neighboring cells before the handover decision.

3. Maximum Measurement Period (InterFreqMaxMeasPeriod)This parameter determines the maximum number of periodic measurement reports during an inter-frequency measurement (that is, the maximum allowed duration of the inter-frequency measurement). If the RNC is not able to execute the inter-fre-

124 DN03471612




quency handover, it stops the inter-frequency measurement after the UE has sent a predefined number of measurement reports to the RNC.

4. Minimum Measurement Interval (InterFreqMinMeasInterval)This parameter determines the minimum interval between an unsuccessful inter-fre-quency measurement or handover procedure and the beginning of the following inter-frequency measurement procedure related to the same RRC connection. Repetitive inter-frequency measurements are disabled when the value is zero.

5. Minimum Interval Between Handovers (InterFreqMinHoInterval)This parameter determines the minimum interval between a successful inter-fre-quency handover and the following inter-frequency handover attempt related to the same RRC connection. Repetitive inter-frequency handovers are disabled when the value of the parameter is zero.

Figure 45 Measuring procedure for inter-frequency handover

The RNC measures one frequency at a time. If there are more than one frequency to be measured, the RNC selects a subset of inter-frequency neighbor cells (having the same UTRA RF channel number) which are measured first. The measurement order is con-trolled with the following RNP parameters defined for each neighbor cell:

• Ncell Priority for Quality IFHO (AdjiPriorityQuality) determines the measure-ment order in case of a quality reason inter-frequency handover.

• Ncell Priority for Coverage IFHO (AdjiPriorityCoverage) determines the mea-surement order in case of a coverage reason inter-frequency handover.

If the measurement results of the first measured frequency indicate that an inter-fre-quency handover can be done, the RNC starts the handover attempt immediately (the RNC does not measure remaining frequencies and corresponding cells any more). If none of the neighboring cells was good enough according to the first inter-frequency measurement, the RNC can directly repeat the measurement and decision procedures for the remaining subsets of inter-frequency neighboring cells until all frequencies and neighboring cells are measured, or a target cell for the inter-frequency handover is found. The maximum measurement period which is allowed for each carrier frequency is controlled by the InterFreqMaxMeasPeriod parameter.

Frequency 3

Frequency 2

Frequency 1

HO

3

4

Time2

14

4

5

DN03471612 125



11.9 Function in abnormal conditionsIf an attempted handover to a target frequency fails, the RNC successively extends the interval during which another attempt to hand the same RRC connection over to the same target frequency is disallowed. The duration of the interval depends on the number of previous handover failures. The RNC determines the interval in the following way:

Figure 46 Time interval calculation.

TIME_INTERVAL = ( 1 + NUMBER_OF IFHO_FAILS ) * InterFreqMinMeasInterval

The Minimum Measurement Interval (InterFreqMinMeasInterval) parameter determines the minimum interval between an unsuccessful inter-frequency measure-ment (or handover attempt) procedure and the following inter-frequency measurement procedure related to the same RRC connection.

TIME_INTERVAL 1 NUMBER_OF_IFHO_FAILS+( ) InterFreqMinMeasInterval•=

126 DN03471612


Id:0900d80580749b97Confidential

Functionality of inter-frequency handover over Iur

12 Functionality of inter-frequency handover over IurMobility between RNCs in UTRAN connected mode can be carried out by the anchoring method. The SRNC continues as a controlling node (anchoring point) for the RRC con-nection via Iur interface and DRNS. The user plane traffic between the DRNS and the CN is transferred via Iur interface and the SRNC. Anchoring is used when the DRNC or the CN does not support the SRNS relocation procedure.

Full UTRAN connected mode mobility during anchoring requires the support of intra- and inter-frequency handovers over Iur. The RNC supports intra-frequency (soft and softer) handover over Iur and inter-frequency handover over Iur for DCHs.

When the feature is enabled the following functions are available:

• The network operator can configure FMCI and HOPI parameter sets which are used for the inter-frequency handover control during anchoring.

• The DRNC reports the inter-frequency neighbor cell information to the SRNC. • The SRNC/DRNC support compressed mode for inter-frequency measurements

during anchoring. • The SRNC/DRNC support inter-frequency handover signaling over Iur interface. • The SRNC downgrades the bit rate of NRT DCHs to UL: 64/ DL: 64 kbit/s before

anchoring if DCH Scheduling over Iur is disabled in SRNC. • If the inter-frequency measurement reports indicate that the best cell for inter-fre-

quency hard handover is an I-BTS cell, and the current RAB combination of the UE is not supported target I-BTS (IBTSRabCombSupport parameter) then SRNC will triggers inter-frequency handover over Iur, if the I-BTS Sharing feature is also enabled in the RNC.

12.1 Neighbor cell informationIf the cell where the radio link was established in the DRNC has inter-frequency neighbor cells, the DRNC reports the inter-frequency neighbor cells in addition to the intra-fre-quency neighbor cells to the SRNC. The information is sent via Iur interface within the neighboring UMTS Cell Information IE of the RNSAP: RADIO LINK SETUP RESPONSE or RNSAP: RADIO LINK ADDITION RESPONSE messages. Furthermore, the RNSAP: RADIO LINK SETUP FAILURE and RNSAP: RADIO LINK ADDITION FAILURE messages include the neigbour cell information for any successful radio link.

The neighboring UMTS Cell Information IE contains the following information for each FDD intra-frequency and inter-frequency neighbor cell:

• RNC ID of the controlling RNC • CN PS domain identifier • CN CS domain identifier • cell ID • UL UARFCN • DL UARFCN • primary scrambling code • primary CPICH power • cell individual offset • Tx diversity indicator

DN03471612 127

WCDMA RAN RRM Handover Control Functionality of inter-frequency handover over Iur


• DPC mode change support indicator

The SRNC takes into account the inter-frequency neighbor cell information which has been received from the DRNC in the inter-frequency measurement and handover decision procedures.

12.2 Handover control parametersThis section provides information on the parameter setting during anchoring when the Inter-frequency Handover over Iur feature is enabled and when the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled in the SRNC. The SRNC uses RNC level handover control parameters during anchoring for the active set cells controlled by the DRNC and for the neighboring cells defined on the DRNC side. If the Inter-frequency Handover over Iur feature is enabled and the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is disabled in the SRNC, the following parameters are applicable:

• The AnchorFmcsIdentifier and AnchorHopsIdentifier RNC parameters define the FMCS and HOPS parameter sets which are used during anchoring for the intra-frequency handover control. The same FMCS/HOPS parameter set is used for both real time (RT) and non-real time (NRT) radio bearers. If the parameter sets for anchoring have not been defined, handover control uses the default values of the FMCS and/or HOPS parameters during anchoring.

• The AnchorFmciIdentifier and AnchorHopiIdentifier RNC parameters define the FMCI and HOPI parameter sets which are used during anchoring for the inter-frequency handover control. The same FMCI/HOPI parameter set is used for both real time (RT) and non-real time (NRT) radio bearers. If the parameter sets for anchoring have not been defined, handover control uses the default values of the FMCI and/or HOPI parameters during anchoring.

If the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled in the SRNC, then the handover control of the SRNC uses FMCS, FMCI, HOPS and HOPI parameter sets (database objects) of the reference cell object (VCEL object) for the intra- and inter-frequency handover control during anchoring.

Handover control of the SRNC uses the default values of the following WBTS parame-ters for the initiation of dedicated (transmitted code power) measurement in a DRNC during anchoring if the Inter-frequency Handover over Iur feature is enabled and the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is disabled in the SRNC :

• DedicatedMeasReportPeriod

• DediMeasRepPeriodCSdata • DediMeasRepPeriodPSdata

• MeasFiltCoeff

Handover control of SRNC uses the following VBTS parameters to configure the Dedi-cated Measurements in the DRNC during anchoring if the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled:

• DedicatedMeasReportPeriod • DediMeasRepPeriodCSdata

• DediMeasRepPeriodPSdata

• MeasFiltCoeff

128 DN03471612




Handover control of the SRNC does not modify ongoing transmitted code power (dedi-cated) measurements which have been started in a DRNC before anchoring. Handover control of the SRNC does not start dedicated measurement in a DRNC during anchoring if the Inter-frequency Handover over Iur feature and the Support for I-HSPA Sharing and Iur Mobility Enhancements feature are disabled.

12.3 Inter-Frequency measurement and handover decision during anchoringDuring anchoring, the SRNC supports the inter-frequency measurements and the handover decision procedures for the following handover causes both for RT and NRT radio bearers (including multi services) :

• inter-frequency handover because of uplink DCH qualityIf inter-frequency handover because of 'Uplink DCH quality' is enabled by the FMCI - IFHOcauseUplinkQuality parameter, the SRNC starts inter-frequency mea-surement during anchoring when it receives a quality deterioration report from the UL outer loop power control.The bit rate of the NRT DCHs must be lower than or equal to UL: 64/ DL: 64 kbit/s before an inter-frequency handover because of 'Uplink DCH quality' is possible during anchoring if DCH Scheduling Over Iur is disabled in the SRNC ( that is the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is disabled in the SRNC or the RNC parameter DCHScheOverIur is set to ‘1’ (Not Supported)). The WCEL parameter HHoMaxAllowedBitrateUL is not used during anchoring.

• inter-frequency handover because of UE Tx powerIf inter-frequency handover because of 'UE Tx power' is enabled by the FMCI parameter - IFHOcauseTxPwrUL, the SRNC continues UE transmitted power mea-surement during anchoring. The SRNC starts inter-frequency measurement when it receives an event 6A triggered measurement report from the UE.The bit rate of NRT DCHs must be lower than or equal toUL 64/ DL: 64 kbit/s before an inter-frequency handover because of 'UE Tx power' is possible during anchoring if DCH Scheduling Over Iur is disabled in the SRNC ( that is the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is disabled in the SRNC or the RNC parameter DCHScheOverIur is set to ‘1’ (Not Supported)). The WCEL parameter HHoMaxAllowedBitrateUL is not used during anchoring.

• inter-frequency handover because of downlink DPCH powerIf inter-frequency handover because of 'Downlink DPCH power' is enabled by the IFHOcauseTxPwrDL parameter, the SRNC continues the dedicated transmitted code power measurement in the DRNC(s) during anchoring. The SRNC starts the inter-frequency measurement if the measured downlink code power of a single radio link reaches the threshold.The bit rate of the NRT DCHs must be lower than or equal to 64/64 kbit/s before an inter-frequency handover because of 'Downlink DPCH power' is possible during anchoring if DCH Scheduling Over Iur is disabled in the SRNC ( that is the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is disabled in the SRNC or the RNC parameter DCHScheOverIur is set to ‘1’ (Not Supported)). The WCEL parameter HHoMaxAllowedBitrateUL is not used during anchoring.

• inter-frequency handover because of CPICH RSCPIf inter-frequency handover because of 'CPICH RSCP' is enabled by the IFHOcauseCPICHrscp parameter, the SRNC continues event triggered CPICH RSCP measurement in the UE during anchoring. When the measured CPICH RSCP

DN03471612 129



value of an active set cell becomes worse than the absolute threshold/parameter HHoRscpThreshold, the UE sends an event 1F triggered intra-frequency mea-surement report to the RNC.The SRNC starts inter-frequency measurement if the measured CPICH RSCP value of all active set cells has become worse than the reporting threshold.

• inter-frequency handover because of CPICH Ec/NoIf inter-frequency handover because of 'CPICH Ec/No' is enabled by the IFHOcauseCPICHEcNo parameter, the SRNC continues the event triggered CPICH Ec/No measurement in the UE during anchoring. When the measured CPICH Ec/No value of an active set cell becomes worse than the absolute thresh-old/parameter HHoEcNoThreshold, the UE sends an event 1F triggered intra-fre-quency measurement report to the RNC.The SRNC starts inter-frequency measurement if the measured CPICH Ec/No value of all active set cells has become worse than the reporting threshold.

• IMSI based handover (including Immediate IMSI based handover)When IMSI based handover is enabled by the IMSIbasedIFHO parameter, the SRNC compares both the PLMN identifier of the subscriber and the relevant list of authorised PLMNs with the PLMN identifiers of the neighboring cells in order to find the possible home or authorised PLMN cells for the inter-frequency measurement. The SRNC starts inter-frequency measurement during anchoring because of imme-diate IMSI based handover when the following conditions are fulfilled: • Immediate IMSI based handover is enabled by the IMSIbasedIFHO parameter.

The handover is enabled when the value of the parameter is "2". • IMSI based intra-frequency handover is enabled by the IMSIbasedSHO param-

eter. • The active set cell(s) has (have) one or more inter-frequency neighbor cells

whose PLMN identifier equals either the PLMN identifier of the subscriber or a PLMN identifier in the authorised network list.

• The PLMN identifier of a monitored cell that has triggered the reporting event 1A or 1C does not fulfill the requirement of home/authorised/active set PLMNs and the SRNC cannot add the monitored cell into the active set.

If DCH Scheduling Over Iur is disabled (that is the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is disabled in the SRNC or the RNC parameter DCHScheOverIur is set to 1 (not supported)), the maximum allocated user bitrate on the uplink/downlink DPCH does not affect the inter-frequency handover decision during anchoring as the SRNC downgrades the bit rate of NRT DCHs to 64/64 kbit/s wherever it is possible before anchoring starts. Therefore, the WCEL parameters HHoMaxAl-lowedBitrateDL and HHoMaxAllowedBitrateUL are not used during anchoring if DCH Scheduling Over Iur is disabled. If it was not possible for the SRNC to downgrade the bit rate of NRT DCHs to 64/64 kbit/s before anchoring, the SRNC discards the following handover causes from the inter-frequency measurement and handover decision proce-dure:

• inter-frequency handover because of UE Tx power • inter-frequency handover because of downlink DPCH power

The SRNC does not trigger load based inter-frequency handover and service or HSPA capability based inter-frequency handover during anchoring.

If DCH Scheduling Over Iur is enabled during anchoring ( that is the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled and the RNC parameter DCHScheOverIur is set to 0 (supported)), then VCEL parameters

130 DN03471612




HHoMaxAllowedBitrateDL and HHoMaxAllowedBitrateUL limit the maximum allocated user bitrate on the uplink/downlink DPCH because the SRNC does not down-grade the bitrate of NRT DCHs down to 64/64 kbit/s before anchoring

12.4 Bit rate of NRT DCHs during anchoringThe maximum bit rate of NRT DCHs is UL: 64/ DL: 64 kbit/s during anchoring if DCH Scheduling Over Iur is disabled in the SRNC ( that is the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is disabled in the SRNC or the RNC parameter DCHScheOverIur is set to ‘1’ (Not Supported)),. The SRNC downgrades higher bit rates to UL: 64/ DL: 64 kbit/s before the last active set cell controlled by the SRNC is removed from the active set and anchoring starts.

If the last active set cell controlled by the SRNC is removed from the active set during compressed mode, the SRNC continues the compressed mode measurements and omits the downgrade of high bit rate NRT DCHs.

The SRNC downgrades higher bit rates to UL: 64/ DL: 64 kbit/s also during the inter-frequency handover from the SRNC to the DRNC over Iur interface if the UE does not have any existing radio link in the target DRNC. When the UE has an existing radio link in the target DRNC, the downgrade takes place just before the inter-frequency han-dover.

The SRNC does not upgrade the bit rate of an NRT DCH if it is lower than 64/64 kbit/s before anchoring.

If DCH Scheduling Over Iur is enabled in the SRNC ( that is the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is enabled in the SRNC and the RNC parameter DCHScheOverIur is set to ‘0’ (Supported)), then SRNC does not down-grade the NRT DCH bitrate to 64/64 kbit/s before anchoring. All the NRT DCH bit rates supported in non-anchoring scenarios are supported over Iur during anchoring as well. SRNC is able to modify (upgrade/downgrade) the bitrate of the NRT DCH during anchor-ing in the form of radio link reconfiguration requests over Iur.

If DCH Scheduling Over Iur is disabled in the SRNC ( that is the Support for I-HSPA Sharing and Iur Mobility Enhancements feature is disabled in the SRNC or the RNC parameter DCHScheOverIur is set to ‘1’ (Not Supported)) the SRNC does not modify the bit rate of NRT DCHs during anchoring until all NRT DCHs are inactive and the state transition from CELL_DCH to CELL_FACH state can be done, or streaming PS data or conversational CS data service is established. When streaming PS data or conversa-tional CS data service is established during anchoring, the SRNC downgrades the bit rate of high priority NRT DCH to UL: 8/ DL: 8 kbit/s and releases the other possible NRT DCHs. In multi RAB configurations with a CS voice call, the SRNC maintains the bit rate of NRT DCHs until the CS voice call is released and all NRT DCHs are inactive.

12.5 Inter-Frequency handover from SRNC to DRNC over Iur without existing RL in the target DRNCWhen the need for an inter-frequency handover arises and the target cell is under another RNC, the SRNC initiates inter-frequency handover over Iur if the CN or the DRNC does not support the SRNS relocation procedure. If both the CN and the DRNC support SRNS relocation, the SRNC initiates the UE involved SRNS relocation proce-dure instead of the inter-frequency handover over Iur.

DN03471612 131



If Support for I-HSPA Sharing and Iur Mobility Enhancements feature and Inter-Fre-quency Handover Over Iur feature is enabled in SRNC then SRNC shall initiate the inter-frequency handover over Iur instead of SRNS relocation if the current RAB combination of the UE is not among the RAB combinations supported by the target I-BTS (Iur con-nection exists between the target I-BTS and SRNC) as indicated by the RNC level parameter IBTSRabCombSupport.

Figure Inter-Frequency handover from SRNC to DRNC over Iur, no existing RL in target DRNC describes the signaling procedure of the inter-frequency handover from the SRNC to the DRNC 2 over Iur interface when there was an inter-RNC soft handover between the SRNC and the DRNC 1 prior to the inter-frequency handover and the UE does not have any existing radio link in the target DRNC 2.

Figure 47 Inter-Frequency handover from SRNC to DRNC over Iur, no existing RL in target DRNC

5. RNSAP: RADIO LINK SETUP RESPONSE

7. RRC: PHYSICAL CHANNEL RECONFIGURATION

2. NBAP: RADIO LINK SETUP REQUEST

8. NBAP: RADIO LINK FAILURE INDICATION


4. ALCAP Iub DATA TRANSPORT BEARER SETUP

DRNC 2Target

Target BTSin DRNC 2

UESource BTSin DRNC 1

DRNC 1Source

SRNCSource

1. RNSAP: RADIO LINK SETUP REQUEST

3. NBAP: RADIO LINK SETUP RESPONSE

6. ALCAP Iur TRANSPORT BEARER SETUP

Source BTSin SRNC

10. RNSAP: RADIO LINK FAILURE INDICATION

11. NBAP: RADIO LINK RESTORE INDICATION

12. RNSAP: RADIO LINK RESTORE INDICATION

13. RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE

14. NBAP: RADIO LINK DELETION REQUEST

15. RNSAP: RADIO LINK DELETION REQUEST


17. NBAP: RADIO LINK DELETION RESPONSE

18. ALCAP Iub DATA TRANSPORT BEARER RELEASE



21. RNSAP: RADIO LINK DELETION RESPONSE

22. ALCAP Iur TRANSPORT BEARER RELEASE

132 DN03471612




1. The SRNC sends the RNSAP: RADIO LINK SETUP REQUEST message to the target DRNC 2. The maximum bit rate of the NRT DCHs to be established is UL: 64/ DL: 64 kbit/s if DCH Scheduling over Iur is disabled. The value of the First RLS Indi-cator IE is 'first RLS'.

2. The DRNC 2 allocates the RNTI, the radio resources for the RRC connection, and the radio link. Afterward it sends the NBAP: RADIO LINK SETUP REQUEST message to the target BTS.

3. The target BTS allocates resources, starts PHY reception, and responds with the NBAP: RADIO LINK SETUP RESPONSE message.

4. The DRNC 2 initiates the setup of the Iub data transport bearer using the ALCAP protocol. This request contains the AAL2 binding identity to bind the Iub data trans-port bearer to the DCH. The request for setup of the Iub data transport bearer is acknowledged by the target BTS.

5. When the DRNC 2 has completed the preparation phase, it sends an RNSAP: RADIO LINK SETUP RESPONSE message to the SRNC.

6. The SRNC initiates the setup of the Iur data transport bearer using the ALCAP pro-tocol. This request contains the AAL2 binding identity to bind the Iur data transport bearer to the DCH. The request for setup of the Iur data transport bearer is acknowl-edged by the DRNC 2.

7. The SRNC sends an RRC: PHYSICAL CHANNEL RECONFIGURATION message to the UE. If downgrade of a high bit rate NRT DCHs is required, an RRC: RADIO BEARER RECONFIGURATION message is sent.

8. When the UE switches from the old radio link to the new radio link, the source BTS that is controlled by the SRNC detects a failure on its radio link and sends an NBAP: RADIO LINK FAILURE INDICATION message to the SRNC.

9. When the UE switches from the old radio link to the new radio link, the source BTS that is controlled by the DRNC 1 detects a failure on its radio link and sends an NBAP: RADIO LINK FAILURE INDICATION message to the DRNC 1. This message exists only when there was an inter-RNC soft handover between SRNC and DRNC 1.

10. The DRNC 1 sends an RNSAP: RADIO LINK FAILURE INDICATION message to the SRNC. This message does only exist if there was an inter-RNC soft handover between SRNC and DRNC 1.

11. The target BTS achieves uplink sync on the Uu interface and notifies the DRNC 2 with an NBAP: RADIO LINK RESTORE INDICATION message.

12. The DRNC 2 sends an RNSAP: RADIO LINK RESTORE INDICATION message to notify the SRNC that the uplink sync has been achieved on the Uu interface.

13. When the RRC connection is established to the DRNC 2 and necessary radio resources have been allocated, the UE sends an RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE or RADIO BEARER RECONFIGURATION COMPLETE message to the SRNC.

14. The SRNC sends an NBAP: RADIO LINK DELETION REQUEST message to the source BTS that is controlled by the SRNC.

15. The SRNC sends an RNSAP: RADIO LINK DELETION REQUEST message to the DRNC 1. This message does only exist if there was an inter-RNC soft handover between SRNC and DRNC 1 prior to the inter-frequency handover.

16. The DRNC 1 sends an NBAP: RADIO LINK DELETION REQUEST message to the source BTS controlled by the DRNC 1. This message does only exist if there was

DN03471612 133



an inter-RNC soft handover between SRNC and DRNC 1 prior to the inter-frequency handover.

17. The source BTS controlled by the SRNC releases the radio resources. Successful outcome is reported to the SRNC in the NBAP: RADIO LINK DELETION RESPONSE message.

18. The SRNC releases the Iub data transport bearer using ALCAP protocol.19. The source BTS controlled by the DRNC 1 releases the radio resources. Successful

outcome is reported to the DRNC 1 in an NBAP: RADIO LINK DELETION RESPONSE message. This message does only exist if there was an inter-RNC soft handover between SRNC and DRNC 1 prior to the inter-frequency handover.

20. The DRNC 1 releases the Iub data transport bearer using ALCAP protocol. This task does only exist if there was an inter-RNC soft handover between SRNC and DRNC 1 prior to the inter-frequency handover.

21. When the DRNC 1 has completed the release, it sends an RNSAP: RADIO LINK DELETION RESPONSE message to the SRNC. This message does only exist if there was an inter-RNC soft handover between SRNC and DRNC 1 prior to the inter-frequency handover.

22. The SRNC releases the Iur data transport bearer using ALCAP protocol. This task does only exist if there was an inter-RNC soft handover between SRNC and DRNC 1 prior to the inter-frequency handover.

12.6 Inter-frequency handover from the SRNC to the DRNC over Iur with an existing RL in the target DRNCWhen the need for an inter-frequency handover arises and the target cell is under another RNC, the SRNC initiates inter-frequency handover over Iur if the CN or the DRNC does not support the SRNS relocation procedure. If both the CN and the DRNC support SRNS relocation, the SRNC initiates the UE involved SRNS relocation proce-dure instead of the inter-frequency handover over Iur.

If Support for I-HSPA Sharing and Iur Mobility Enhancements feature and Inter-Fre-quency Handover Over Iur feature is enabled in the SRNC, then SRNC shall initiate the inter-frequency handover over Iur instead of SRNS relocation if the current RAB combi-nation of the UE is not among the RAB combinations supported by the target I-BTS (Iur connection exists between the target I-BTS and SRNC) as indicated by the RNC level parameter IBTSRabCombSupport.

Figure Inter-Frequency handover from SRNC to DRNC over Iur with an existing RL in the target DRNC shows the signaling procedure of the inter-frequency handover from the SRNC to the DRNC over Iur interface when there was an inter-RNC soft handover between the SRNC and the DRNC prior to the inter-frequency handover.

134 DN03471612




Figure 48 Inter-Frequency handover from SRNC to DRNC over Iur with an existing RL in the target DRNC

1. The SRNC downgrades high bit rate NRT DCHs to UL: 64/ DL: 64 kbit/s before the RNSAP radio link addition procedure takes place if DCH scheduling over Iur is dis-abled.

2. The SRNC sends an RNSAP: RADIO LINK ADDITION REQUEST message to the DRNC. The Diversity Control Field IE is set to "Must not".

3. The DRNC allocates the radio resources for the RRC connection and the radio link, and sends an NBAP: RADIO LINK SETUP REQUEST message to the target BTS.



2. RNSAP: RADIO LINK ADDITION REQUEST




Target BTSin DRNC

UESource BTS

in DRNCDRNC SRNC



Source BTSin SRNC














1. Downgrade of high bit rate NRT DCHs down to 64/64 kbps

6. RNSAP: RADIO LINK ADDITION RESPONSE

DN03471612 135



4. The target BTS allocates resources, starts PHY reception, and responds with an e NBAP: RADIO LINK SETUP RESPONSE message to the DRNC.

5. The DRNC initiates the setup of the Iub data transport bearer using ALCAP protocol. This request contains the AAL2 binding identity to bind the Iub data transport bearer to the DCH. The request for the setup of the Iub data transport bearer is acknowl-edged by the target BTS.

6. When the DRNC has completed the preparation phase, it sends an RNSAP: RADIO LINK ADDITION RESPONSE message to the SRNC. The DRNC indicates with the Diversity Indication in the RL Information Response IE that no combining is done. In this case the DRNC includes in the DCH Information Response IE both the Trans-port Layer Address IE and the Binding ID IE for the transport bearer to be estab-lished for each DCH of the radio link.

7. The SRNC initiates setup of Iur data transport bearer using ALCAP protocol. This request contains the AAL2 binding identity to bind the Iur data transport bearer to the DCH. The request to set up the Iur data transport bearer is acknowledged by the DRNC.

8. The SRNC sends an RRC: PHYSICAL CHANNEL RECONFIGURATION message to the UE.

9. When the UE switches from the old radio link to the new radio link, the source BTS controlled by the SRNC detects a failure on its radio link and sends an NBAP: RADIO LINK FAILURE INDICATION message to the SRNC.

10. When the UE switches from the old radio link to the new radio link, the source BTS controlled by the DRNC detects a failure on its radio link and sends an NBAP: RADIO LINK FAILURE INDICATION message to the DRNC.

11. The DRNC sends an RNSAP: RADIO LINK FAILURE INDICATION message to the SRNC.

12. The target BTS achieves uplink sync on the Uu interface and notifies the DRNC with an NBAP: RADIO LINK RESTORE INDICATION message.

13. The DRNC sends an RNSAP: RADIO LINK RESTORE INDICATION message to notify the SRNC that uplink sync has been achieved on the Uu interface.

14. When the RRC connection is established with the DRNC and necessary radio resources have been allocated, the UE sends an RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the SRNC.

15. The SRNC sends an NBAP: RADIO LINK DELETION REQUEST message to the source BTS controlled by the SRNC.

16. The SRNC sends an RNSAP: RADIO LINK DELETION REQUEST message to the DRNC.

17. The DRNC sends an NBAP: RADIO LINK DELETION REQUEST message to the source BTS controlled by the DRNC.

18. The source BTS controlled by the SRNC releases the radio resources. Successful outcome is reported to the SRNC in an NBAP: RADIO LINK DELETION RESPONSE message.

19. The SRNC releases the Iub data transport bearer using ALCAP protocol.20. The source BTS controlled by the DRNC releases the radio resources. Successful

outcome is reported to the DRNC in an NBAP: RADIO LINK DELETION RESPONSE message.

21. The DRNC releases the Iub data transport bearer using ALCAP protocol.22. When the DRNC has completed the release, it sends an RNSAP: RADIO LINK

DELETION RESPONSE message to the SRNC.

136 DN03471612




23. The SRNC releases the Iur data transport bearer using ALCAP protocol.

12.7 Inter-Frequency handover during anchoring with an existing RL in the target DRNCWhen the need for an inter-frequency handover arises and the target cell is under another RNC, the SRNC initiates inter-frequency handover over Iur if the CN or the DRNC does not support the SRNS relocation procedure. If both the CN and the DRNC support SRNS relocation, the SRNC initiates the UE involved SRNS relocation proce-dure instead of the inter-frequency handover over Iur.


Figure Inter-Frequency handover during anchoring with an existing RL in the target DRNC shows the signaling procedure of the inter-frequency handover during anchoring when the UE has an existing radio link in the DRNC 1 which controls the target BTS prior to the inter-frequency handover.

DN03471612 137



Figure 49 Inter-frequency handover during anchoring with an existing RL in the target DRNC

1. The SRNC sends an e RNSAP: RADIO LINK ADDITION REQUEST message to the DRNC 1. The Diversity Control Field IE is set to "Must not".

2. The DRNC 1 allocates the radio resources for the RRC connection and the radio link, and sends an NBAP: RADIO LINK SETUP REQUEST message to the target BTS.

5. RNSAP: RADIO LINK ADDITION RESPONSE






DRNC 2Target BTSin DRNC 1

UESource BTSin DRNC 2

DRNC 1 SRNC

1. RNSAP: RADIO LINK ADDITION REQUEST



Source BTSin DRNC 1


















138 DN03471612




3. The target BTS allocates resources, starts PHY reception, and responds with an NBAP: RADIO LINK SETUP RESPONSE message to the DRNC 1.

4. The DRNC 1 initiates the setup of Iub data transport bearer using ALCAP protocol. This request contains the AAL2 binding identity to bind the Iub data transport bearer to the DCH. The request to set up the Iub data transport bearer is acknowledged by the target BTS.

5. When the DRNC 1 has completed the preparation phase, it sends an RNSAP: RADIO LINK ADDITION RESPONSE message to the SRNC. The DRNC 1 indicates with the Diversity Indication in the RL Information Response IE that no combining is done. In this case the DRNC 1 includes in the DCH Information Response IE both the Transport Layer Address IE and the Binding ID IE for the transport bearer to be established for each DCH of the radio link.

6. The SRNC initiates setup of the Iur data transport bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iur data transport bearer to the DCH. The request to set up the Iur data transport bearer is acknowledged by the DRNC 1.


8. When the UE switches from the old radio link to the new radio link, the source BTS controlled by the DRNC 1 detects a failure on its radio links and sends an NBAP: RADIO LINK FAILURE INDICATION message to the DRNC 1.

9. The DRNC 1 sends an RNSAP: RADIO LINK FAILURE INDICATION message to the SRNC.

10. When the UE switches from the old radio link to the new radio link, the source BTS controlled by the DRNC 2 detects a failure on its radio link and sends an NBAP: RADIO LINK FAILURE INDICATION message to the DRNC 2. This message does only exist if there was a radio link in the DRNC 2 prior to the inter-frequency han-dover.

11. The DRNC 2 sends an RNSAP: RADIO LINK FAILURE INDICATION message to the SRNC. This message does only exist if there was a radio link in the DRNC 2 prior to the inter-frequency handover.

12. The target BTS achieves uplink sync on the Uu interface and notifies the DRNC 1 with an NBAP: RADIO LINK RESTORE INDICATION message.

13. The DRNC 1 sends an RNSAP: RADIO LINK RESTORE INDICATION message to notify the SRNC that uplink sync has been achieved on the Uu interface.

14. When the RRC connection is established with the DRNC 1 and necessary radio resources have been allocated, the UE sends an RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the SRNC.

15. The SRNC sends an RNSAP: RADIO LINK DELETION REQUEST message to the DRNC 1 in order to remove the old radio link.

16. The DRNC 1 sends an NBAP: RADIO LINK DELETION REQUEST message to the source BTS controlled by the DRNC 1.

17. The SRNC sends an RNSAP: RADIO LINK DELETION REQUEST message to the DRNC 2 in order to remove the old radio link. This message does only exist if there was a radio link in the DRNC 2 prior to the inter-frequency handover.

18. The DRNC 2 sends an NBAP: RADIO LINK DELETION REQUEST message to the source BTS. This message does only exist if there was a radio link in the DRNC 2 prior to the inter-frequency handover.

DN03471612 139



19. The source BTS controlled by the DRNC 1 releases the radio resources. Successful outcome is reported to the DRNC 1 in an NBAP: RADIO LINK DELETION RESPONSE message.

20. The DRNC 1 releases the Iub data transport bearer of the old radio link by using ALCAP protocol.

21. The source BTS controlled by the DRNC 2 releases the radio resources. Successful outcome is reported to the DRNC 2 in an NBAP: RADIO LINK DELETION RESPONSE message. This message does only exist if there was a radio link in the DRNC 2 prior to the inter-frequency handover.

22. The DRNC 2 releases the Iub data transport bearer of the old radio link by using ALCAP protocol. This task does only exist if there was a radio link in the DRNC 2 prior to the inter-frequency handover.

23. When the DRNC 1 has completed the release of the old radio link, it sends an RNSAP: RADIO LINK DELETION RESPONSE message to the SRNC.

24. The SRNC releases the Iur data transport bearer of the old radio link controlled by the DRNC 1 by using ALCAP protocol.

25. When the DRNC 2 has completed the release of the old radio link, it sends an RNSAP: RADIO LINK DELETION RESPONSE message to the SRNC. This message does only exist if there was a radio link in the DRNC 2 prior to the inter-frequency handover.

26. The SRNC releases the Iur data transport bearer of the old radio link controlled by the DRNC 2 by using ALCAP protocol. This message does only exist if there was a radio link in the DRNC 2 prior to the inter-frequency handover.

12.8 Inter-Frequency handover during anchoring with no existing RL in target DRNCWhen the need for an inter-frequency handover arises and the target cell is under another RNC, the SRNC initiates inter-frequency handover over Iur if the CN or the DRNC does not support the SRNS relocation procedure. If both the CN and the DRNC support SRNS relocation, the SRNC initiates the UE involved SRNS relocation proce-dure instead of the inter-frequency handover over Iur.


Figure Inter-Frequency handover during anchoring with no existing RL in the target DRNC describes the signaling procedure of the inter-frequency handover during anchoring when the UE does not have any existing radio link in the DRNC 2 which controls the target BTS.

140 DN03471612




Figure 50 Inter-Frequency handover during anchoring with no existing RL in the target DRNC

1. The SRNC sends an RNSAP: RADIO LINK SETUP REQUEST message to the target DRNC 2. The value of the First RLS Indicator IE is 'first RLS'.

2. The DRNC 2 allocates the RNTI, the radio resources for the RRC connection and the radio link, and sends the NBAP: RADIO LINK SETUP REQUEST message to the target BTS.

3. The target BTS allocates resources, starts PHY reception, and responds with an NBAP: RADIO LINK SETUP RESPONSE message to the DRNC 2.

4. The DRNC 2 initiates the setup of Iub data transport bearer using the ALCAP proto-col. This request contains the AAL2 binding identity to bind the Iub data transport bearer to the DCH. The request to set up the Iub data transport bearer is acknowl-edged by the target BTS.

5. When the DRNC 2 has completed the preparation phase, it sends an RNSAP: RADIO LINK SETUP RESPONSE message to the SRNC.



1. RNSAP: RADIO LINK SETUP REQUEST



Source BTSin DRNC 1

UETarget BTSin DRNC 2

DRNC 2Target

SRNC



DRNC 1Source











5. RNSAP: RADIO LINK SETUP RESPONSE

DN03471612 141



6. The SRNC initiates the setup of the Iur data transport bearer using ALCAP protocol. This request contains the AAL2 binding identity to bind the Iur data transport bearer to the DCH. The request to set up the Iur data transport bearer is acknowledged by the DRNC 2.


8. When the UE switches from the old radio link to the new radio link, the source BTS controlled by the DRNC 1 detects a failure on its radio link and sends an NBAP: RADIO LINK FAILURE INDICATION message to the DRNC 1.

9. The DRNC 1 sends an RNSAP: RADIO LINK FAILURE INDICATION message to the SRNC.

10. The target BTS achieves uplink sync on the Uu interface and notifies the DRNC 2 with an NBAP: RADIO LINK RESTORE INDIATION message.

11. The DRNC 2 sends an RNSAP: RADIO LINK RESTORE INDICATION message to notify the SRNC that uplink sync has been achieved on the Uu interface.

12. When the RRC connection to the DRNC 2 is established and necessary radio resources have been allocated, the UE sends an RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the SRNC.

13. The SRNC sends an RNSAP: RADIO LINK DELETION REQUEST message to the DRNC 1 in order to remove the old radio link.

14. The DRNC 1 sends an NBAP: RADIO LINK DELETION REQUEST message to the source BTS.

15. The source BTS controlled by the DRNC 1 releases the radio resources. Successful outcome is reported to the DRNC 1 in an NBAP: RADIO LINK DELETION RESPONSE message.

16. The DRNC 1 releases the Iub data transport bearer of the old radio link by using ALCAP protocol.

17. When the DRNC 1 has completed the release of the old radio link, it sends an RNSAP: RADIO LINK DELETION RESPONSE message to the SRNC.

18. The SRNC releases the Iur data transport bearer of the old radio link by using ALCAP protocol. This request contains the AAL2 binding identity to bind the Iur data transport bearer to the DCH. The request to release the Iur data transport bearer is acknowledged by the DRNC 1.

12.9 Inter-Frequency handover from anchoring back to SRNCThe figure below shows the signaling procedure of the inter-frequency handover from anchoring back to the SRNC.

142 DN03471612




Figure 51 Inter-Frequency handover from anchoring back to the SRNC

1. The SRNC allocates the radio resources for the RRC connection and the radio link, and sends an NBAP: RADIO LINK SETUP REQUEST message to the target BTS. The value of the First RLS Indicator IE is set to 'first RLS'.

2. The target BTS allocates resources, starts PHY reception, and responds with an NBAP: RADIO LINK SETUP RESPONSE message to the SRNC.

3. The SRNC initiates setup of Iub data transport bearer using ALCAP protocol. This request contains the AAL2 binding identity to bind the Iub data transport bearer to the DCH. The request to set up the Iub data transport bearer is acknowledged by the target BTS.


5. When the UE switches from the old radio link to the new radio link , the source BTS controlled by the DRNC detects a failure on its radio link and sends an NBAP: RADIO LINK FAILURE INDICATION message to the DRNC.

6. The DRNC sends an RNSAP: RADIO LINK FAILURE INDICATION message to the SRNC.

7. The target BTS achieves uplink sync on the Uu interface and notifies the SRNC with an NBAP: RADIO LINK RESTORE INDICATION message.






Source BTSin DRNC

UETarget BTS

in SRNCDRNC SRNC










DN03471612 143



8. When the RRC connection is established on the frequency and necessary radio resources have been allocated, the UE sends an RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the SRNC.

9. The SRNC sends an RNSAP: RADIO LINK DELETION REQUEST message to the DRNC in order to remove the old radio link.

10. The DRNC sends an NBAP: RADIO LINK DELETION REQUEST message to the source BTS.

11. The source BTS releases the radio resources. Successful outcome is reported to the DRNC in an NBAP: RADIO LINK DELETION RESPONSE message.

12. The DRNC releases the Iub data transport bearer of the old radio link by using ALCAP protocol.

13. When the DRNC has completed the release, it sends an RNSAP: RADIO LINK DELETION RESPONSE message to the SRNC.

14. The SRNC releases the Iur data transport bearer of the old radio link by using the ALCAP protocol. This request contains the AAL2 binding identity to bind the Iur data transport bearer to the DCH. The request to release the Iur data transport bearer is acknowledged by the DRNC.

144 DN03471612



Functionality of inter-system handover

13 Functionality of inter-system handoverThis feature is a part of application software.

Inter-System Handovers (ISHOs) allow WCDMA and GSM networks to complement each other in terms of quality, capacity and coverage. The User Equipment (UE) must support both WCDMA and GSM radio access technologies before an inter-system handover is possible. The RNC supports inter-system handovers for circuit-switched voice services both from WCDMA to GSM and from GSM to WCDMA.

Inter-system handover of packet-switched services between WCDMA and GSM/GPRS is based on the cell reselection procedure. The RNC supports network-initiated cell reselection from WCDMA to GSM/GPRS in CELL_DCH state of connected mode. In CELL_PCH and URA_PCH states of connected mode, the cell reselection is initiated by the UE. The RNC does not support cell reselection from WCDMA to GSM/GPRS in CELL_FACH state of connected mode (however, a UE equipped with a dual receiver can perform the cell reselection also in CELL_FACH state). The RNC sees the cell rese-lection from GSM/GPRS to WCDMA as an Radio Resource Control (RRC) connection establishment, and the UE-initiated cell reselection from WCDMA to GSM/GPRS as an Iu connection release.

The RNC does not start inter-system handover or cell reselection to GSM when only a signaling radio bearer (SRB) is allocated for the RRC connection.

Inter-system handover and cell reselection are enabled separately for each service type by means of the following parameters. For the description of the parameters, see WCDMA Radio Network Configuration Parameters:

• Handover of AMR Service to GSM (GsmHandoverAMR) determines whether an inter-system handover to GSM is allowed for circuit-switched voice services.

• Handover of RT PS Service to GSM (GsmHandoverRtPS) determines whether an inter-system handover (cell change) to GSM/GPRS is allowed for real-time packet-switched data services in CELL_DCH state of connected mode.

• Handover of NRT PS Service to GSM (GsmHandoverNrtPS) determines whether an inter-system handover (cell change) to GSM/GPRS is allowed for non-real time packet switched data services in CELL_DCH state of connected mode.

The RNC makes the decision on the need for inter-system handover. When an inter-system handover (or cell reselection) to GSM is needed, the RNC orders the UE to start the periodic reporting of inter-system measurement results. The RNC recognises the fol-lowing inter-system handover causes:

• inter-system handover because of uplink Dedicated Traffic Channel (DCH) quality • inter-system handover because of UE transmission power • inter-system handover because of downlink Dedicated Physical Channel (DPCH)

power • inter-system handover because of Common Pilot Channel (CPICH) RSCP • inter-system handover because of CPICH Ec/No • immediate IMSI-based handover (for more information, see Section Functionality of

immediate IMSI-based handover) • load-based handover (for more information, see Section Functionality of load-

based and service-based IF/IS handover) • service-based handover (for more information, see Section Functionality of load-

based and service-based IF/IS handover)

DN03471612 145

WCDMA RAN RRM Handover Control Functionality of inter-system handover


The RNC makes the handover decision on the basis of periodic inter-system measure-ment reports received from the UE and relevant control parameters. The measurement reporting criteria and the object information (cells and frequencies) for the inter-system measurement are determined by the RNC.

Unless the UE is equipped with dual receivers, it can only be tuned to one frequency at a time. Therefore, compressed mode must be used at the physical layer of the radio interface to allow the UE to make the required inter-system (GSM) measurements while maintaining its existing connection.

Once the RNC has decided to attempt an inter-system handover from WCDMA to GSM, it initiates an inter-system relocation procedure in order to allocate radio resources from the target GSM BSS. If the resource allocation is successful, the RNC orders the mobile station to make an inter-system handover from UMTS Terrestrial Radio Access Network (UTRAN) to GSM. In the event of a network-initiated cell reselection from WCDMA to GSM/GPRS, the RNC sends a cell change command to the UE which then transfers the existing packet-switched connection to the target GSM/GPRS network.

When inter-system handover cancellation is enabled, the RNC can stop ongoing inter-system (GSM) measurement. If the radio conditions in the current WCDMA layer improve during the inter-system measurement phase, a coverage based handover or network initiated cell reselection attempt can be cancelled.

The decision algorithm of the inter-system handover from GSM to WCDMA is located in the GSM Base Station Controller (BSC). After the handover decision, the BSC initiates an inter-system relocation procedure in order to allocate radio resources from the target RNC. If the resource allocation is successful in the target RNC, the BSC orders the UE to make an inter-system handover to the WCDMA radio access network. When a radio access bearer is handed over from one radio access technology to another, the core network is responsible for adapting the Quality of Service (QoS) parameters of the radio access bearer according to the new (GSM/GPRS or WCDMA) radio access network.

13.1 Coverage reason inter-system handoverThe RNC supports the following coverage reason inter-system handovers (and cell reselections) to GSM for both real-time (RT) and Non-Real Time (NRT) radio bearers:

• inter-system handover because of uplink DCH quality • inter-system handover because of UE transmission power • inter-system handover because of CPICH RSCP • inter-system handover because of downlink DPCH power • inter-system handover because of CPICH Ec/No • Immediate IMSI-based handover (for more information, see Section Functionality of

immediate IMSI-based handover)

g In the inter-system handover context, the last two handovers on the above list (inter-system handover because of downlink DPCH power and inter-system handover because of CPICH Ec/No) are regarded as coverage reason handovers.

13.1.1 Inter-System handover because of uplink DCH qualityThe quality deterioration report from the uplink outer loop power control can be used to trigger off inter-system handover to GSM if the serving cell (or cells participating in soft handover) has GSM neighbor cells. The uplink outer loop power control sends the

146 DN03471612




quality deterioration report to the handover control, if the uplink quality stays constantly worse than the Bit Error Ratio (BER)/Block Error Ratio (BLER) target although the uplink Signal-to-Interference Ratio (SIR) target has reached the maximum value (the UE has reached either its maximum Tx power capability or the maximum allowed transmission power level on the DPCH).

The reporting criteria of the quality deterioration report is controlled with the following Radio Network Planning (RNP) parameters:

• Quality deterioration report from UL OLPC controller (EnableULQualDetRep) indi-cates whether the uplink outer loop PC can send a quality deterioration report to the handover control in situations when the quality stays worse than the BER/BLER target despite of the maximum uplink SIR target.

• UL quality deterioration reporting threshold (ULQualDetRepThreshold ) deter-mines the period during which the quality must constantly stay worse than the BER/BLER target (despite of the maximum uplink SIR target) before the uplink outer loop PC may send a quality deterioration report.

For a description of the parameters, see WCDMA Radio Network Configuration Param-eters which can be found in the Reference category of this documentation library.

The uplink outer loop PC repeats the quality deterioration reports to the handover control periodically until the uplink SIR target decreases below the maximum value.

Handover control does not interrupt an ongoing inter-system (GSM) measurement pro-cedure even if the uplink outer loop PC stops sending the quality deterioration reports.

The GSM HO caused by UL DCH Quality (GSMcauseUplinkQuality) parameter indi-cates whether an inter-system handover to GSM caused by Uplink DCH quality is enabled. In case of RT data connection (Circuit Switched (CS) or Packet Switched (PS)), also the maximum allocated user bitrate on the uplink DPCH must be lower than or equal to the bitrate threshold which is controlled with the parameter Maximum Allowed UL User Bitrate in HHO (HHoMaxAllowedBitrateUL), before the RNC may start the measurement because of uplink DCH quality. This limitation in uplink bitrate is not applied for NRT services. When the inter-system handover/measurement is enabled, the RNC starts the inter-system (GSM) measurement as described in Section Measure-ment procedure for inter-system handover.

The RNC makes the handover decision on the basis of the periodical inter-system mea-surement reports received from the UE and relevant control parameter as described in Section Handover decision procedure for inter-system handover.

13.1.2 Inter-System handover because of UE transmission powerIf the serving cell (or cells participating in soft handover) has GSM neighbor cells, event triggered UE transmission power measurement report can be used to trigger off handover to GSM when the transmission power of the UE approaches either its maximum RF output power capability or the maximum transmission power level the UE can use on the DPCH.

The GSM HO caused by UE TX Power (GSMcauseTxPwrUL) RNP parameter indicates whether an inter-system handover to GSM caused by the UE transmission power is enabled. In addition, the maximum allocated user bitrate on the uplink DPCH must be lower than or equal to the bitrate threshold which is controlled with the RNP parameter Maximum Allowed UL User Bitrate in HHO (HHoMaxAllowedBitrateUL), before the RNC may start the inter-system (GSM) measurement because of UE transmission

DN03471612 147



power. When the inter-system handover/measurement is enabled, the RNC starts the UE internal measurement in order to monitor the UE transmission power level. The mea-surement reporting criteria for the UE transmission power measurement is controlled with the following RNP parameters:

• UE TX Power Filter Coefficient (GsmUETxPwrFilterCoeff) controls the higher layer filtering (averaging) of the physical layer transmission power measurements in the UE. The physical layer measurement period for the UE transmission power is one slot.

• UE TX Power Threshold for AMR (GsmUETxPwrThrAMR) determines the UE trans-mission power threshold for a circuit-switched voice connection.

• UE TX Power Threshold for CS (GsmUETxPwrThrCS) determines the UE transmis-sion power threshold for a circuit-switched data connection.

• UE TX Power Threshold for NRT PS (GsmUETxPwrThrNrtPS) determines the UE transmission power threshold for a non-real time packet-switched data connection.

• UE TX Power Threshold for RT PS (GsmUETxPwrThrRtPS) determines the UE transmission power threshold for a real-time packet-switched data connection.

• UE TX Power Time Hysteresis (GsmUETxPwrTimeHyst) determines the time-to-trigger, that is the time period between the detection of the following measurement events and the sending of the measurement report: • Event 6A: The UE transmission power must stay above the transmission power

threshold for this time period before the inter-system handover is triggered. • Event 6B: The UE transmission power must stay below the transmission power

threshold before the UE calls off the handover cause.

Note that the UE transmission power is not used as a handover cause for a service type if the value of the corresponding UE transmission power threshold parameter is 'not used'. The power thresholds are relative to the maximum transmission power level a UE can use on the DPCH in the cell (or the maximum RF output power capability of the UE in WCDMA, whichever is lower). In case of multiservice, the RNC selects the parame-ters in the following order: 1st priority AMR, 2nd priority CS data, 3rd priority RT PS data and 4th priority NRT PS. For the description of the parameters, see WCDMA Radio Network Configuration Parameters.

If the UE transmission power becomes greater than the reporting threshold (event 6A), the UE sends the measurement report (event 6A) to the RNC, and the RNC starts the inter-system (GSM) measurement as described in Section Measurement procedure for inter-system handover.

The RNC makes the handover decision on the basis of the periodical inter-system mea-surement reports received from the UE and relevant control parameters as described in Section Handover decision procedure for inter-system handover.

If the UE transmission power measurement is used to trigger inter-frequency measure-ment, the time-to-trigger is controlled with the InterFreqUETxPwrTimeHyst param-eter. If the UE transmission power measurement is used to trigger inter-RAT measurement, the time-to-trigger is controlled with the GsmUETxPwrTimeHyst param-eter. If both inter-frequency handover and inter-system handover to GSM are enabled, the RNC selects the greater parameter value for the Time-To-Trigger IE.

g ISHOCancellation and ISHOClcauseTxPwrUL parameters indicate whether the RNC can stop an ongoing inter-RAT (GSM) measurement caused by high UE Tx power. The measurement is cancelled if the UE Tx power decreases again below the reporting

148 DN03471612




threshold and the user equipment sends the corresponding measurement report event 6B to the RNC.

13.1.3 Inter-System handover because of CPICH RSCPReceived Signal Code Power (RSCP) measurement result on the Primary CPICH can be used to trigger off inter-system handover to GSM if the serving cell (or cells partici-pating in soft handover) has GSM neighbor cells.

The GSM HO caused by CPICH RSCP (GSMcauseCPICHrscp) RNP parameter indi-cates whether an inter-system handover to GSM caused by low measured absolute CPICH RSCP is enabled. When the inter-system handover is enabled, the RNC sets up an intra-frequency measurement in order to monitor the absolute CPICH RSCP value. The measurement reporting criteria for the intra-frequency CPICH RSCP measurement is controlled with the following RNP parameters:

• CPICH RSCP HHO Threshold (HHoRscpThreshold) determines the absolute CPICH RSCP threshold which is used by the UE to trigger reporting event 1F.

• CPICH RSCP HHO Time Hysteresis (HHoRscpTimeHysteresis) determines the time period during which the CPICH RSCP of the active set cell must stay worse than the threshold HHoRscpThreshold before the UE can trigger reporting event 1F.

• CPICH RSCP HHO Cancellation (HHoRscpCancel) determines the absolute CPICH RSCP threshold which is used by the UE to trigger reporting event 1E.

• CPICH RSCP HHO Cancellation Time (HHoRscpCancelTime) determines the time period during which the CPICH RSCP of the active set cell must stay better than the threshold HHoRscpCancel before the UE can trigger the reporting event 1E.

• CPICH RSCP HHO Filter Coefficient (HHoRscpFilterCoefficient) controls the higher layer filtering (averaging) of physical layer CPICH RSCP measurements before the event evaluation and measurement reporting is performed by the UE. The UE physical layer measurement period for intra-frequency CPICH RSCP measure-ment is 200 ms.

If the CPICH RSCP measurement result of an active set cell becomes worse than or equal to the absolute threshold/parameter HHoRscpThreshold, the UE sends an event 1F-triggered measurement report to the RNC. The UE cancels event 1F by sending an event 1E-triggered measurement report to the RNC if the CPICH RSCP measurement result of the active set cell increases again and becomes better than or equal to the threshold HHoRscpCancel. If the CPICH RSCP measurement result of all active set cells has become worse than the reporting threshold HHoRscpThreshold (event 1F is valid for all active set cells simultaneously), the RNC starts the inter-system (GSM) mea-surement as described in Section Measurement procedure for inter-system handover.

The RNC makes the handover decision on the basis of the periodical inter-system mea-surement reports received from the UE and relevant control parameters , see Section Handover decision procedure for inter-system handover.

g ISHOCancellation and ISHOClcauseCPICHrscp RNP parameters indicate whether the RNC can stop the ongoing inter-RAT(GSM) measurement caused by low CPICH RSCP.

The measurement is cancelled if the measured CPICH RSCP of one or more active set cells increases again above the reporting threshold HHoRscpCancel and the UE sends the corresponding event 1E triggered intra-frequency measurement report to the RNC.

DN03471612 149



13.1.4 Inter-System handover because of downlink DPCH powerThe Base Station (BTS) measures and averages the downlink code power of each radio link separately and reports the averaged measurement results to the controlling RNC at regular intervals with a 3GPP NBAP: DEDICATED MEASUREMENT REPORT. The base station measures the downlink code power from the pilot bits of the dedicated physical control channel (DPCCH). In case of an inter-RNC soft handover, the drifting RNC forwards the measurement results to the serving RNC in the RNSAP: DEDICATED MEASUREMENT REPORT message. In 3GPP NBAP, the Reporting Period is con-trolled with the Dedicated Measurement Reporting Period (DediMeasReportPeriod), Dedicated Measurement Reporting Period CS data (DediMeasRepPeriodCSdata), Dedicated Measurement Reporting Period PS data (DediMeasRepPeriodPSdata) RNP parameters. All of these measurement reports can trigger off inter-system handover to GSM when the downlink transmission power of the radio link approaches its maximum allowed power level.

The GSM HO caused by DL DPCH TX Power (GSMcauseTxPwrDL) RNP parameter determines whether an inter-system handover to GSM caused by high downlink DPCH power level is enabled. In addition, the maximum allocated user bitrate on the downlink DPCH must be lower than or equal to the bitrate threshold defined by the Maximum Allowed DL User Bitrate in HHO (HhoMaxAllowedBitrateDL) RNP parameter, before the RNC may start the inter-system measurement and handover because of downlink DPCH power.

When the handover to GSM is enabled, the RNC starts the inter-system measurement procedure (see Section Measurement procedure for inter-system handover) if the measured downlink code power of a single radio link satisfies the following equation:

DL_CODE_PWR - PowerOffsetDLdpcchPilot >= CPICH_POWER + MAX_DL_DPCH_TXPWR + DL_DPCH_TXPWR_THRESHOLD

The variables in the formula are defined in the following table.



PowerOffsetDLdpcchPilot is a constant that defines the power offset for the pilot fields of the DPCCH, expressed as a relative value with respect to the DPDCH power


MAX_DL_DPCH_TXPWR indicates the maximum transmission power level of the DPDCH symbols a base station can use on the DPCH, expressed as a relative value (dB) with respect to the primary CPICH power (dBm)

Table 15 Variables for inter-system handover

150 DN03471612




ISHOCancellation and ISHOClcauseTxPwrDL parameters indicate whether the RNC can stop an ongoing inter-RAT(GSM) measurement caused by high measured DL DPCH Tx Pwr. The measurement is cancelled if the DL DPCH Tx Pwr decreases below the threshold as indicated by an NBAP/RNSAP: Dedicated Measurement Report.

The RNC makes the handover decision on the basis of periodic inter-system measure-ment reports received from the UE and relevant control parameters, see Section Handover decision procedure for inter-system handover.

13.1.5 Inter-System handover because of CPICH Ec/NoCPICH Ec/No measurement result (received energy per chip divided by the power density in the band, that is, CPICH RSCP/UTRA Carrier RSSI) can be used to trigger off inter-system handover to GSM if the serving cell (or cells participating in soft han-dover) has GSM neighbor cells.

DL_DPCH_TXPWR_THRESHOLD is controlled with the following inter-system measurement control parameters, depending on the service type:

• DL DPCH TX Power Threshold for RT PS (GsmDLTxPwrThrRtPS ) deter-mines the downlink DPCH transmis-sion power threshold for a real time packet-switched data connection

• DL DPCH TX Power Threshold for NRT PS (GsmDLTxPwrThrNrtPS) determines the downlink DPCH trans-mission power threshold for a non-real time packet switched data connection

• DL DPCH TX Power Threshold for CS (GsmDLTxPwrThrCS) determines the downlink DPCH transmission power threshold for a circuit-switched data connection

• DL DPCH TX Power Threshold for AMR (GsmDLTxPwrThrAMR) deter-mines the downlink DPCH transmis-sion power threshold for a circuit-switched voice connection


In case of a multiservice, the RNC selects the lowest threshold value for the calcula-tion (e.g. when the alternative threshold values are -1dB and -3dB, the RNC selects the -3dB threshold value). Downlink trans-mission power shall not be used as a handover cause for a service type if the value of the corresponding threshold parameter is 'not used'.


Table 15 Variables for inter-system handover (Cont.)

DN03471612 151



The GSM HO caused by CPICH Ec/No (GSMcauseCPICHEcNo) RNP parameter indi-cates whether an inter-system handover to GSM caused by low measured absolute CPICH Ec/No is enabled. When the inter-system handover is enabled, the RNC sets up an intra-frequency measurement in order to monitor the absolute CPICH Ec/No value. The measurement reporting criteria for the intra-frequency CPICH Ec/No measurement is controlled with the following RNP parameters:

• CPICH Ec/No HHO Threshold (HHoEcNoThreshold) determines the absolute CPICH Ec/No threshold which is used by the UE to trigger reporting event 1F.

• CPICH Ec/No HHO Time Hysteresis (HHoEcNoTimeHysteresis) determines the time period during which the CPICH Ec/No of the active set cell must stay worse than the threshold HHoEcNoThreshold before the UE can trigger reporting event 1F.

• CPICH Ec/No HHO Cancellation (HHoEcNoCancel) determines the absolute CPICH Ec/No threshold which is used by the UE to trigger reporting event 1E.

• CPICH Ec/No HHO Cancellation Time (HHoEcNoCancelTime) determines the time period during which the CPICH Ec/No of the active set cell must stay better than the threshold HHoEcNoCancel before the UE can trigger reporting event 1E.

• CPICH Ec/No Filter Coefficient (EcNoFilterCoefficient) controls the higher layer filtering (averaging) of physical layer CPICH Ec/No measurements before the event evaluation and measurement reporting is performed by the UE. The UE physical layer measurement period for intra-frequency CPICH Ec/No measure-ments is 200 ms.

If the CPICH Ec/No measurement result of an active set cell becomes worse than or equal to the absolute threshold/parameter HHoEcNoThreshold, the UE sends an event 1F-triggered measurement report to the RNC. The UE cancels event 1F by sending an event 1E-triggered measurement report to the RNC if the CPICH Ec/No measurement result of the active set cell increases again and becomes better than or equal to the threshold HHoEcNoCancel. If the CPICH Ec/No measurement result of all active set cells has become worse than the reporting threshold HHoEcNoThreshold (event 1F is valid for all active set cells simultaneously), the RNC starts the inter-system (GSM) measurement, see Section Measurement procedure for inter-system handover.

The RNC makes the handover decision on the basis of periodic inter-system measure-ment reports received from the UE and relevant control parameters, see Section Handover decision procedure for inter-system handover.

g ISHOCancellation and ISHOClcauseCPICHEcNo RNP parameters indicate whether the RNC can stop ongoing inter-RAT(GSM) measurements caused by low CPICH Ec/No.

The measurement is cancelled if the measured CPICH Ec/No of one or more active set cells increases again above the reporting threshold HHoEcNoCancel and the UE sends the corresponding event 1E triggered intra-frequency measurement report to the RNC.

13.1.6 Inter-System handover because of failed RAB setupThe Directed Retry feature triggers an inter-system handover to GSM for AMR and AMR-WB calls if the source cell is congested. The directed retry is performed for single AMR and AMR-WB RAB services.

The Directed Retry feature is enabled on cell level by the Usage of Directed Retry of AMR call Inter-system Handover (AMRDirReCell) parameter. The Inter-System Handover feature is a mandatory prerequisite for the Directed Retry feature.

152 DN03471612




Directed retry of an AMR call is performed during the RAB setup phase. If the RAB setup fails, an RAB ASSIGNMENT RESPONSE message followed by the relocation proce-dure triggers the directed retry.

The RAB setup fails if the RAB does not get the required resources because of one of the following reasons:

• Any of the RAN resources is congested. • RT-over-NRT and RT-over-RT mechanisms cannot provide resources for the RAB

in question.

This feature supports single AMR and single AMR-WB services via CS core network. The directed retry of an AMR call is a blind handover as GSM measurements are not performed.

The target cell is the neighbor GSM cell in the neighbor GSM cell list which Inter-system adjacency identifier (ADJGId) parameter has the value '0'. In the event of a soft han-dover, the target cell is selected from the neighbor GSM cell list of the best WCDMA active cell. The best WCDMA active cell is the cell that has the highest EC/No value for the pilot signal P-CPICH.

The AMR call is rejected if there is no GSM cell in the neighbor GSM cell list with the ADJGid parameter value set to "0".

13.1.7 Handover decision procedure for inter-system handoverThe measurement results of the GSM neighbor cell must satisfy the following equation before the inter-system handover or cell change to GSM/GPRS is possible:

AVE_RXLEV_NCELL(n) > AdjgRxLevMinHO (n) + max( 0, AdjgTxPwrMaxTCH (n) - P_MAX )

In the equation above, AVE_RXLEV_NCELL(n) is the averaged GSM carrier RSSI value of the GSM neighbor cell (n). The RNC calculates the averaged value directly from the measured dBm values, linear averaging is not used in this case. The sliding averag-ing window is controlled with the Measurement Averaging Window (GsmMeasAveWindow) parameter. The RNC starts averaging already from the first measurement sample, that is, the RNC calculates the averaged values from those mea-surement samples, which are available until the number of samples is adequate to cal-culate averaged values over the whole averaging window.

The Minimum RX Level for Coverage (AdjgRxLevMinHO) RNP parameter determines the minimum required RSSI (dBm) level which the averaged RSSI value of the GSM neighbor cell (n) must exceed before the inter-RAT handover is possible. The neighbor cell parameter Maximum MS TX Power on TCH (AdjgTxPwrMaxTCH) indicates the maximum transmission power (dBm) a UE may use in the GSM neighbor cell (n). P_MAX indicates the maximum RF output power capability of the UE (dBm) in GSM.

The GSM neighbor Cell Search Period (GsmNcellSearchPeriod) RNP parameter determines the period, starting from the measurement setup, during which a handover to GSM is not possible. This period allows the UE to find and report all potential GSM cells before the handover decision. After the search period has expired, the RNC eval-uates the radio link properties of the best GSM neighbor cells after every measurement report. The RNC initiates a handover attempt to the best GSM neighbor (target) cell as soon as the best GSM neighbor cell satisfies the required radio link properties.

If there are several GSM cells which satisfy the required radio link properties at the same time, the RNC ranks the potential GSM cells according to the priority levels and selects

DN03471612 153



the highest ranked GSM cell to be the target cell. The priority order is controlled with the Ncell Priority for Coverage HO (AdjgPriorityCoverage) RNP parameter which is defined for each GSM neighbor cell. The crucial principle is that high-priority cells are considered better than low-priority cells, that is, a cell is ranked higher than another cell if it has a higher priority level even though its signal strength condition is worse; signal strength conditions have effect only between cells which have the same priority level.

13.2 Interactions between handover causesThe handover cause, which has triggered first has the highest priority. That is, the RNC does not stop or modify ongoing inter-system (GSM) measurement and handover decision procedures if another handover cause is triggered during the handover proce-dures.

If two or more inter-system (GSM) handover causes are triggered simultaneously, the RNC selects the cause, which has the highest priority. The priority order is the following:

1. immediate IMSI-based inter-system handoverImmediate IMSI-based inter-system handover has higher priority than the other inter-system handover causes (for more information, see Section Functionality of immediate IMSI-based handover).

2. quality and coverage reason inter-system handoversThe RNC supports the following quality and coverage reason inter-system han-dovers to GSM (the handover causes are not presented in any particular order): • inter-system handover to GSM/GPRS because of uplink DCH quality • inter-system handover to GSM/GPRS because of UE Tx power • inter-system handover to GSM/GPRS because of downlink DPCH power • inter-system handover to GSM/GPRS because of CPICH RSCP • inter-system handover to GSM/GPRS because of CPICH Ec/No

3. load-based inter-frequency handoverFor more information, see Section Functionality of load-based and service-based IF/IS handover.

4. service-based inter-frequency handover For more information, see Section Functionality of load-based and service-based IF/IS handover.

13.3 Interaction with inter-frequency handoverIf the serving cell (or cells participating in soft handover) has neighbor cells both on another carrier frequency and on another radio access technology (GSM), the RNC determines the priorities between inter-frequency and -system handovers on the basis of Service Handover IE value. The RNC receives the Service Handover IE from the core network in the RAB ASSIGNMENT REQUEST or RELOCATION REQUEST (RANAP) message. If the RNC does not receive the Service Handover IE from the core network, inter-frequency handover has priority over inter-system handover to GSM as a default value.

• Should be handed over to GSM:Handover to GSM has priority over the inter-frequency handover. In this case the RNC shall not start inter-frequency measurements until the inter- system (GSM) measurements are completed, that is, when no neighboring GSM cell is good enough for the quality and/or coverage reason handover.

154 DN03471612




• Should not be handed over to GSM:Inter-frequency handover has priority over the handover to GSM. In this case the RNC shall not start the GSM measurements until the inter- frequency measure-ments are completed, that is, when no neighboring cell is good enough for the quality and/or coverage reason inter-frequency handover.

• Shall not be handed over to GSM:Inter-frequency handover has priority over the handover to GSM. In this case the RNC shall not start GSM measurements or handover to GSM even if no neighboring cell is good enough for the quality and/or coverage reason inter-frequency han-dover. This means that the RNC does not initiate handover to GSM for the UE unless the RABs with this indication have first been released with the normal release pro-cedures.

In the event of a directed emergency call inter-system handover, an RRC connection is handed over to GSM even if the Service Handover IE has the value Should not be handed over to GSM or Shall not be handed over to GSM for one RAB of the RRC con-nection. The RNC initiates a handover to GSM for the RRC connection despite the RABs with this indication. If the RNC does not receive the Service Handover IE from the core network for a directed emergency call inter-system handover, the handover to GSM has a higher priority than the inter-frequency handover.

If WPS is enabled, a WPS call is handed over to GSM during the RAB setup even if the Service Handover IE has the value Should not be handed over to GSM or Shall not be handed over to GSM for an AMR radio access bearer of the RRC connection. This is valid for the RAB setup phase only. The WPS feature does not support multi-RABs.

If directed retry of AMR calls is enabled, an AMR call is handed over during the RAB setup to GSM even if the Service Handover IE has the value Should not be handed over to GSM or Shall not be handed over to GSM for the AMR RAB of the RRC connection. This is valid for the RAB setup phase only. The Directed Retry feature does not support multi-RABs.

13.4 Interaction with handover to GAN Inter-RAT handover to GSM has a higher priority than the inter-RAT handover to GAN. The RNC releases the measurement event 3A before it starts the periodical inter-RAT measurement for inter-RAT handover to GSM. If the RRC connection remains in WCDMA, the RNC restarts the inter-RAT measurement event 3A after the periodical GSM measurement is completed.

13.5 Measurement control parameters of inter-system handoverThe different inter-system handover causes are enabled separately on each handover cause (for example, inter-RAT handover to GSM because of UE Tx power). The relevant radio network configuration parameters belong to the inter-system measurement control parameters which are defined separately for each cell by attaching a specified measure-ment control parameter set (or sets) to a specified cell. The radio network database has 100 separate measurement parameter sets for inter-RAT (GSM) measurements.

All cells in the RAN can use the same set of inter-RAT measurement parameters or the cells might have a tailored set of measurement control parameters for real time (RT) and for non-real time (NRT) radio bearers. Measurement parameters are controlled on a set

DN03471612 155



by set basis by means of the O&M, by using the local user interface in the RNC site or the network management system (NMS).

The handover control of the RNC enables an inter-system (GSM) handover cause when the handover cause in question is enabled in the inter-system (GSM) measurement control (FMCG) parameters of an active set cell which has also GSM neighbor cells.

If the active set consists of more than one cell then all possible causes, which are enabled in at least one cell, are considered. The CPICH Ec/No and RSCP thresholds related to the inter-system handover causes are determined by the intra-frequency mea-surement control (FMCS) parameters of the active set cell which is the strongest cell according to the CPICH Ec/No measurement results reported by the UE.

When the channel type is DCH, the inter-system (GSM) measurement and handover are controlled by the inter-system (GSM) measurement control (FMCG) parameters of the best (according to CPICH Ec/No) active set cell (controlled by the SRNC) which has the handover cause in question enabled and which has GSM neighbor cells. The handover control re-selects the controlling FMCG parameter set after each active set update pro-cedure. In addition, the controlling FMCG parameter set can change if the service type (RT/NRT) or the channel type (DCH/HSDPA) changes during the RRC connection. However, the handover control does not modify onqoing periodical GSM measurement if the controlling FMCG parameter set changes during the measurement.

When the channel type is HSDPA, the inter-system (GSM) handover causes and triggers are controlled by the inter-system measurement control (FMCG) parameters of the serving HS-DSCH cell. The handover control re-selects the controlling FMCG parameter set after the serving cell change.

13.6 Measurement procedure for inter-system handoverThe measurement procedure, the scenario of which is presented in Figure Measuring procedure, is controlled by a number of parameters set during radio network planning. These parameters are:

1. Measurement Reporting Interval (GsmMeasRepInterval) determines the mea-surement reporting interval for periodical inter-system (GSM) measurements.

2. GSM neighbor Cell Search Period (GsmNcellSearchPeriod) determines the number of periodical inter-system (GSM) measurement reports, starting from the first report after the measurement setup, during which a handover to GSM is not possible. This period allows the UE to find and report all potential GSM neighbor cells before the handover decision.

3. Maximum Measurement Period (GsmMaxMeasPeriod) defines the maximum allowed duration of the measurement by means of the maximum number of period-ical inter-system (GSM) measurement reports during the measurement. If the RNC is not able to execute the handover to GSM, it shall stop the GSM measurement after the UE has sent the predefined number of measurement reports to the RNC.

4. Minimum Measurement Interval (GsmMinMeasInterval) determines the minimum interval between an unsuccessful inter-system (GSM) measurement or handover procedure and the following GSM measurement procedure related to the same RRC connection. Repetitive GSM measurements are disabled when the value of the parameter is zero.

156 DN03471612




Figure 52 Measuring procedure for inter-system handover5. Minimum Interval Between HOs (GsmMinHoInterval) determines the minimum

interval between a successful inter-system handover from GSM to UTRAN and the following inter-system handover attempt back to GSM related to the same RRC con-nection. A return handover back to GSM is disabled when the value of the parameter is zero.

13.7 BSIC identificationWhen an inter-system (GSM) measurement is initially started, the measurement quantity is GSM Carrier RSSI. The RNC selects the highest ranked GSM neighbor cell which meets the required radio link properties, to be the target cell. After the target cell selection, the RNC repeats the inter-system measurement for the target GSM carrier and request the BSIC identification before the execution of inter-system handover to GSM.

In the case of CS data/voice services, the RNC always requests the BSIC identification of the target cell before the execution of the inter-system handover so that the mobile station can synchronize to the GSM cell before the handover execution, and also to verify the identification if two or more neighboring GSM cells have the same BCCH fre-quency. In the case of PS data (RT or NRT) services, the RNC does not verify the BSIC of the target cell before the execution of the inter-system cell change to GSM/GPRS unless two or more neighboring GSM cells have the same BCCH frequency.

The functionality for BSIC identification is further extended by the feature RAN1758: Multiple BSIC identification. The extension offers the possibility to select up to three highest ranked GSM cells and to identify the BSIC of the selected GSM cells. In case of multiple BSIC identification, the RNC does the identification for for all services.

A MaxBSICIdentTime timer is used to allow the UE to identify the BSIC of all selected GSM cells before the handover decision. When the MaxBSICIdentTime timer expires, the RNC triggers an inter-RAT Relocation to the highest prioity candidate (whose BSIC has been identified) even if the UE has not reported the BSIC of all candidate cells. The RNC triggers an inter-RAT Relocation to the highest prioity candidate before the timer MaxBSICIdentTime expires if the UE has reported the BSIC of all candidate cells.

If the UE has not reported the BSIC of any candidate cell untill the MaxBSICIdentTimee timer expires, the RNC continues the GSM measurement until the UE has sent the maximum number of measurement reports (GsmMaxMeasPeriod) to the RNC. If the UE reports the BSIC of one (or more) GSM cell after the MaxBSICIdentTime timer has expired (but before the UE has sent the maximum number of measurement reports to

GSM frequency

Frequency 1

HO

3

4 4

Time2

1

554

DN03471612 157



the RNC), the RNC triggers an inter-RAT Relocation to the highest prioity candidate (whose BSIC has been identified) immediately.

If the relocation on Iu, respectively the handover procedure on Uu fails, the RNC selects the next cell and follows the procedure again. Because of the restriction of three cells, two further attemps can be performed.

13.8 Inter-System handover cancellation Inter-system measurements and thereby the inter-system handover / network initiated cell reselection for PS services in the UE can be cancelled when the radio conditions in the current WCDMA layer improve during the inter-system measurement phase. This function enables the call to be retained in the current WCDMA network. Thus the end-users are benefited as the inter-system handover is always a hard handover which causes the users to experience a small disconnection in their call. Typically about one-fourth of the inter-system handovers can be interrupted. The individual figure depends on radio network planning and the traffic conditions.

Inter-System Handover Cancellation is supported during anchoring if the inter-system measurements have been previously started during anchoring by the Support for I-HSPA Sharing and Iur Mobility Enhancements feature.

The RNC can cancel the inter-system handover by deactivating compressed mode and instructing the UE to cancel the ongoing inter-system measurements for the following quality and/or coverage based trigger conditions:

• UE transmission power • start: Measurement event 6A • stop: Measurement event 6B

• Received Signal Code Power (RSCP) or CPICH Ec/No measurement result for a primary CPICH (active set cell) • start: Measurement event 1E • stop: Measurement event 1F

• Downlink DPCH power • start: DL DPCH Tx Pw increasing beyond the maximum threshold • stop: DL DPCH Tx Pw falls below the maximum threshold

In addition, inter-system measurements are cancelled because of active set update in the UE because of cell addition/replacement.

Inter-System measurement cancellation is performed in the UE only if the measurement reports for the cancellation events are received before the last inter-system measure-ment report that starts the inter-system handover (RANAP) signaling procedure. If the cancellation triggers are received after the handover decision has taken place, they are ignored and the handover process continues.

Inter-System measurements are related to one individual quality or coverage related handover criteria even if more than one trigger for inter-system measurements because of quality and/or coverage reasons are received simultaneously. Inter-System measure-ment cancellation, however, is only performed if it is ensured that none of the quality and coverage based inter-system handover causes still persist for the corresponding UE.

If for example event 1F and event 6A triggered measurement reports are received by the RNC for a corresponding UE, inter-system measurements are only stopped if the corresponding cancellation events 1E and 6B are both received.

158 DN03471612




If IMSI based inter-system handover is enabled in an active set cell, the RNC selects only those GSM neighbor cells into the inter-system neighbor cell list whose PLMN iden-tifiers are either included in the relevant WANE list or which have the same PLMN iden-tifier as the subscriber. Inter-System measurement cancellation is performed in the same manner as that of the other quality and coverage reasons inter-system handover scenarios. For more information on IMSI based handover see Functionality of IMSI-based handover.

Inter-System handover cancellation is available for all the CS and PS services for which quality and coverage based inter-system handover is supported. The cancellation mechanism applies to emergency calls during inter-system measurements because of quality and coverage reasons.

Cancellation of inter-system handover because of event 1EThe RNC stops inter-system measurements when event 1E occurs for at least one cell of the active set. Event 1E can be configured for the following measurements on the Primary CPICH:

• CPICH RSCP: received signal code power (RSCP) • CPICH Ec/No: received energy per chip divided by the power density in the band,

that is CPICH RSCP/UTRA Carrier RSSI

The parameters ISHOClcauseCPICHEcNo and/or ISHOClcauseCPICHrscp indicate whether inter-system measurement cancellation in the UE is enabled or not for situa-tions when a primary CPICH (active set cell) increases beyond the absolute threshold (Event 1E).

Inter-System handover cancellation because of measurement event 1E can be per-formed only when all of the following conditions are met:

• The Inter-System Handover Cancellation feature is enabled by the ISHOCancellation parameter.

• The ISHOClcauseCPICHEcNo or ISHOClcauseCPICHrscp parameter has been set to ‘enabled’ for one or more cells in the active set.

• The number of inter-system cancellations that have been performed for the corre-sponding UE with the current active set is less than the value specified for the MaxNumISHOClPerAS parameter.

• Inter-System measurements were started in the UE because of event 1F (for CPICH Ec/No or CPICH RSCP) triggered measurement report.

• Event 1E triggered measurement report was received during inter-system measure-ment phase.

For information on the cancellation procedure see Inter-System measurement cancella-tion procedure with CM.

Cancellation of inter-system handover because of event 6BThe ISHO Cancellation caused by UE TX Power (ISHOClcauseTxPwrUL) RNP param-eter indicates whether an inter-system handover cancellation caused by the UE trans-mission power (measurement event 6B) is enabled or not.

Inter-System handover cancellation because of measurement event 6B can be per-formed only when all of the following conditions are met:


DN03471612 159



• The ISHOClcauseTxPwrUL parameter has been set to ‘enabled’ for one or more cells in the active set.


• Inter-System measurements were started in the UE because of measurement event 6A, that is the UE transmission power increases beyond the threshold.

• The event 6B triggered measurement report was received during the inter-system measurement phase.


Cancellation of inter-system handover because of downlink DPCH powerWhen the downlink DPCH transmission power decreases below the threshold as indi-cated by the corresponding NBAP/RNSAP dedicated measurement report, the RNC stops the inter-system measurements in the UE. The ISHO Cancellation caused by DL DPCH TX Power (ISHOClcauseTxPwrDL) RNP parameter indicates whether an inter-system handover cancellation caused by a low measured downlink DPCH transmission power level is enabled or not.

Inter-System handover cancellation because of downlink DPCH power can be per-formed only when all of the following conditions are met:


• Tthe ISHOClcauseTxPwrDL parameter has been set to ‘enabled’ for the cell(s) for which the NBAP/RNSAP:DEDICATED MEASUREMENT REPORT was received.

• The number of inter-system measurement cancellations that have been performed for the corresponding UE with the current active set must be less than the value of MaxNumISHOClPerAS.

• Inter-System measurements were started in the UE because the downlink DPCH power increased beyond a threshold as indicated by the NBAP/RNSAP:DEDI-CATED MEASUREMENT REPORT.

• The NBAP/RNSAP:DEDICATED MEASUREMENT REPORT which indicates that the downlink DPCH transmission power decreases below the threshold was received during the inter-system measurement. Inter-System handover cancellation can be performed only if an individual NBAP/RNSAP report has been received indi-cating that the DL DPCH Pwr has now decreased below the threshold for all the radio links an NBAP/RNSAP: Dedicated Measurement Report was received before indicating that the DL DPCH Tx Pwr had increased above the threshold.

• The downlink code power of a single radio link satisfies the following equation:

DL_CODE_PWR - PowerOffsetDLdpcchPilot < CPICH_POWER + MAX_DL_DPCH_TXPWR + DL_DPCH_TXPWR_THRESHOLD + DL_DPCH_TXPWR_CANCEL_OFFSET



Table 16 Variables for inter-system handover cancellation

160 DN03471612




PowerOffsetDLdpcchPilot is a constant that defines the power offset for the pilot fields of the DPCCH, expressed as a relative value with respect to the DPDCH power


MAX_DL_DPCH_TXPWR indicates the maximum transmission power level of the DPDCH symbols a base station can use on the DPCH, expressed as a relative value (dB) with respect to the primary CPICH power (dBm)

DL_DPCH_TXPWR_THRESHOLD is controlled with the following inter-system measurement control parameters, depending on the service type:

• DL DPCH TX Power Threshold for RT PS (GsmDLTxPwrThrRtPS ) deter-mines the downlink DPCH transmis-sion power threshold for a real time packet-switched data connection.

• DL DPCH TX Power Threshold for NRT PS (GsmDLTxPwrThrNrtPS) determines the downlink DPCH trans-mission power threshold for a non-real time packet switched data connection.

• DL DPCH TX Power Threshold for CS (GsmDLTxPwrThrCS) determines the downlink DPCH transmission power threshold for a circuit-switched data connection.

• DL DPCH TX Power Threshold for AMR (GsmDLTxPwrThrAMR) deter-mines the downlink DPCH transmis-sion power threshold for a circuit-switched voice connection.


In case of a multiservice, the RNC selects the lowest threshold value for the calcula-tion (e.g. when the alternative threshold values are -1dB and -3dB, the RNC selects the -3dB threshold value). Downlink trans-mission power shall not be used as a handover cause for a service type if the value of the corresponding threshold parameter is 'not used'.


Table 16 Variables for inter-system handover cancellation (Cont.)

DN03471612 161




Cancellation of inter-system handover because of active set updateAn active set update during the inter-system handover procedure can be triggered by:

• Intra-Frequency measurement event 1A when a primary CPICH enters the reporting range. Upon successful resource allocation in the target cell, the RNC adds the cor-responding cell to the active set of the UE.

• Intra-Frequency measurement event 1C when the number of cells in the active set is equal to the Maximum Active Set Size (MaxActiveSetSize) parameter and a cell that is not included in the active set becomes better than a cell in the active set. If the resources are successfully reserved in the corresponding monitored cell, this cell replaces the cell in the active set.

Inter-System handover cancellation because of active set update can be performed only when all of the following conditions are met:


• Either the ISHOClcauseCPICHEcNo or the ISHOClcauseCPICHrscp parameter has been set to ‘enabled’ for one or more cells in the active set depending on which of the handover causes (CPICH Ec/No or CPICH RSCP) started inter-system handover measurements in the UE.


• Inter-System measurements were started in the UE due event 1F (CPICH Ec/No) or event 1F (CPICH RSCP).

• The active set in the UE was updated because of event 1A or event 1C during the inter-system measurement.

Upon completion of the active set update because of event 1A or event 1C, the CPICH EcNo/CPICH RSCP measurement results of the cell that is new in the active set is compared against the threshold for measurement event 1E (CPICH Ec/No) or event 1E (CPICH RSCP). The active set update causes inter-system handover cancellation in the UE if the CPICH Ec/No or the CPICH RSCP of this cell is found to be greater than or equal to the threshold for event 1E.


DL_DPCH_TXPWR_CANCEL_OFFSET is a constant that is used to reduce the DL_DPCH_TXPWR_THRESHOLD by a fixed value so that the measured code power of the radio link is compared with a slightly lower threshold (2 to 3db lesser)

It is controlled by the DLDPCHTxPwrClOff-set inter-system measurement cancella-tion parameter.


Table 16 Variables for inter-system handover cancellation (Cont.)

162 DN03471612




Inter-System measurement cancellation procedure with CMInter-System measurements are cancelled in two steps:

1. In the BTS, compressed mode is deactivated by sending an NBAP:COMPRESSED MODE COMMAND message. The command deactivates all ongoing transmission gap pattern sequences. If the transport channel parameters have been modified by compressed mode, the NBAP:RADIO LINK RECONFIGURATION procedure is per-formed to deactivate compressed mode.

2. In the UE, compressed mode is deactivated and inter-system measurements are cancelled. The cancellation is initiated for the corresponding UE by sending an RRC:MEASUREMENT CONTROL REQUEST message. If the transport channel parameters have been modified by compressed mode, the RRC:TRANSPORT CHANNEL RECONFIGURATION procedure is triggered.

While the cancellation procedure is ongoing, new trigger for inter-system handover because of quality and coverage reasons can be received. These measurement results are stored and the cancellation process continues. When the measurement interval expires and the trigger conditions are still valid, compressed mode is started. For more details on deactivation of compressed mode see Section Compressed mode.

Inter-System measurement cancellation procedure without CMInter-System measurements configured in the corresponding UE are cancelled by sending an RRC:MEASUREMENT CONTROL REQUEST message.

13.9 Function in abnormal conditionsIf an attempted inter-system handover to GSM fails, the RNC determines an extra time interval during which an inter-system handover to the target cell of the unsuccessful hard handover attempt is not allowed. The duration of the time interval depends on the number of inter-system hard handover failures related to the same GSM cell during the same RRC connection. The RNC determines the time interval in the following way:

TIME_INTERVAL = ( 1 + NUMBER_OF ISHO_FAILS ) * GsmMinMeasInterval

The Minimum Measurement Interval (GsmMinMeasInterval) RNP parameter deter-mines the minimum interval between an unsuccessful inter-system measurement (or handover attempt) procedure and the following inter-system (GSM) measurement pro-cedure related to the same RRC connection.

DN03471612 163

WCDMA RAN RRM Handover Control Functionality of forced hard handover

Id:0900d805807f4d21Confidential

14 Functionality of forced hard handover

14.1 CPICH power ramp-downDuring the Cell Deletion procedure, the CPICH power is ramped down in a cell to be deleted. After the CPICH power ramp-down has been completed, forced handover is triggered for all remaining UE in a cell. The RNC estimates the time needed for gradual CPICH power ramp-down in BTS. The estimated time is based on ShutdownWindow parameter, sent to BTS by RNC before Cell Setup through private NBAP message. The time is measured from the sending of Cell Deletion message to BTS.

The handover procedures related to CPICH power ramp-down are defined in branch deletion, in inter-frequency handover and in inter-system handover. When the handover or branch deletion attempt fails and the gradual CPICH power ramp-down is not fin-ished, the unsuccessful handover is managed, as defined for handover procedures related to CPICH power ramp-down. If the time for CPICH power ramp-down has elapsed when the handover or branch deletion attempt fails, a forced handover proce-dure starts if the UE is still remaining in the cell to be deleted.

14.2 BTS type and version verificationThe Flexi BTS and Ultra BTS with software release WBTS6.0 onwards supports 10-seconds delay in Cell Deletion procedure and block resource request with normal prior-ity. The delay takes place after CPICH power ramp-down and before removing chan-nels. The 10-seconds time is dedicated for forced inter-frequency or inter-system handover for UE still remaining in the cell. The 10-seconds delay takes place in all Cell Deletion procedures and in block resource request with normal priority

If the BTS type and version are not correct, the 10-second delay is not applied in cell deletion procedure and in block resource request procedure after CPICH power ramp-down, and the forced handover procedure is not applied after CPICH power ramp down.

14.3 Start of forced handover procedure for remaining UEIf there is a remaining UE, in a cell to be deleted (Cell Deletion procedure) after the BTS CPICH power ramp-down is completed, the RNC waits one second and then attempts to make a forced IFHO/ISHO to all these UEs, also to the UE in soft handover. All the parameters controlling the number of users in compressed mode can be bypassed. The forced IFHO/ISHO for remaining UE takes place in all Cell Deletion procedures, not only in RAN955: Power Saving Mode for the BTS feature.The forced IFHO/ISHO for remain-ing UEs takes place also in block resource request with normal priority.

14.4 Ongoing handovers when gradual power ramp-down is completedIf there are ongoing handover attempts (handover signaling or inter-frequency measure-ment) at the time when the gradual CPICH power ramp-down ends, (time is estimated by the RNC), these handovers are completed. If the handover attempt was unsuccess-ful, a forced handover is attempted to the remaining UE. A new measurement is starting immediately. The InterFreqMinMeasInterval parameter is not applied in this case.

164 DN03471612



Functionality of forced hard handover

14.5 Measurements of serving cellMeasurements of the serving cell are not needed because the forced handover is attempted to all remaining UEs in cell to be deleted. If the UE reports serving cell mea-surements, they are not taken into account. No measurement reporting changes are made to UEs.

14.6 Handover typeFor cell shutdown because of Power Saving Mode, the forced handover is attempted first as IFHO according to 3G neighbor cells and AdjiPriorityCoverage parame-ters. If no suitable cell for IFHO is found from one 3G inter-frequency or if IFHO proce-dure fails, then an IFHO to another frequency is attempted and a new inter-frequency measurement is made. If IFHO fails (no candidate or failed HO) with all inter-frequen-cies, then ISHO is attempted. If ISHO fails, no new handover is attempted. In PWSM forced handover, the priorities and recommendations from core network are not used. In ISHO, GSMHandoverAMR, GSMHandoverCS, GSMHandoverRtPS, and GSMHan-doverNrtPS parameters are not used.

Note that during the handover attempts, the 10 seconds time window in BTS might have exceeded and the channels are removed and cell is deleted in BTS. This causes the call drop.

For block resource request with normal priority, the priorized handover type is defined with IntelligentSDPrioHO parameter. With IntelligentSDPrioHO parameter value IFHO , the handover type determination is defined above. With IntelligentSDPrioHO parameter value “ISHO”, first the inter-system handover is attempted. If inter-system handover fails, the inter-frequency handover is attempted as defined in the following figure.

DN03471612 165

WCDMA RAN RRM Handover Control Functionality of forced hard handover


Figure 53 Handover decision

14.7 Inter-frequency measurement for inter-frequency handoverThe inter-frequency measurement is started for all UEs in the cell to be deleted. The fre-quency is determined according to the active non-handled inter-frequency neighbor cell with the highest AdjiPriorityCoverage parameter value.

The Inter-frequency handover is executed immediately when a neighbor cell fulfilling the handover criteria is found. Maximum time for the inter-frequency measurement is 5 seconds.

14.8 Determining forced inter-frequency handover target cellsBased on inter-frequency measurement (maximum duration is 5 seconds), the inter-fre-quency neighbor cell for inter-frequency handover target cell is selected according to fol-lowing criteria. Power Saving Mode cell group is not taken into use in forced inter-frequency handover in cell shutdown because of Power Saving Mode, and not in forced inter-frequency handover because of the block resource request with normal priority.

START

Select not handledinter-frequency acc. toAdjPriorityCoverage

All 3G interfrequencies

are handled?

Yes

No

Performinter-frequencymeasurement

(max 5 sec. Period)

Target cellfor IFHOis found?

Perform IFHOto selected cell

SuccessfulIFHO

Perform ISHOprocedure

STOP

STOP

No

No Yes

Yes

166 DN03471612



Functionality of forced hard handover

Before the inter-frequency handover is possible, the measurement results of the best neighboring cell must satisfy the following equations:

AVE_RSCP_NCELL (n) > AdjiMinRSCP (n) + max( 0, AdjiTxPwrDPCH (n) - P_MAX )

AVE_EcNo_NCELL (n) > AdjiMinEcNo (n)

14.9 Reporting forced inter-frequency hard handoverThe RNC provides new counters for measurement of the number of inter frequency hard handovers because of Cell Deletion procedure. The Cell Deletion can be caused for example by user WCEL administrative state change to “locked”, cell is deleted or that power saving mode is applied to cell.

The counters are updated for the WBTS/CELL object. The measurement type is M1008 Intra System Handover. RNC provides the following counters:

• Number of inter-frequency handover attempts forced by Cell Deletion for NRT • Number of inter-frequency handover attempts forced by Cell Deletion for RT • Number of inter-frequency handover successes forced by Cell Deletion for NRT • Number of inter-frequency handover successes forced by Cell Deletion for RT

14.10 Reporting forced inter-system hard handoverThe RNC provides new counters for measurement of the number of inter system hard handovers because of cell deletion procedure. The cell deletion can be caused for example from user WCEL administrative state change to “locked”, cell is deleted or that power saving mode is applied to cell.

The mesurement type is M1010 Inter-system handover. RNC provides the following counters:

• Number of inter-system handover attempts forced by Cell Deletion for NRT • Number of inter-system handover attempts forced by Cell Deletion for RT • Number of inter-system handover successes forced by Cell Deletion for NRT • Number of inter-system handover successes forced by Cell Deletion for RT

DN03471612 167

WCDMA RAN RRM Handover Control Functionality of inter-system handover during anchor-ing

Id:0900d80580708dbdConfidential

15 Functionality of inter-system handover during anchoringInter-System Handover (ISHO) during anchoring is enabled in the SRNC when the Support for I-HSPA Sharing and Iur Mobility Enhancement feature is enabled in the SRNC and the RNC parameter ISHOInIurMobility is set to '1'.

Inter-System Handover (ISHO) during anchoring is enabled in the DRNC when the Support for I-HSPA Sharing and Iur Mobility Enhancement feature is enabled in the DRNC.

When the feature is enabled both in the SRNC and in the DRNC:

• The network operator can configure specified FMCG and HOPG parameter sets which are used for the inter-system handover control during anchoring.

• The SRNC supports compressed mode for inter-system measurements during anchoring.

• The SRNC supports inter-system handover during anchoring. • The DRNC reports the inter-RAT neighbour cell information to the SRNC. • The DRNC supports compressed mode for inter-system measurement during

anchoring.

15.1 Reporting of the inter-RAT neighbour cell information from the DRNC to the SRNC If the cell where the radio link was established in the DRNC has GSM neighbour cells, the DRNC reports the GSM neighbour cells to the SRNC. The information is sent via Iur interface within the Neighbouring GSM Cell Information IE of the RNSAP: RADIO LINK SETUP RESPONSE or RNSAP: RADIO LINK ADDITION RESPONSE messages. Also the RNSAP: RADIO LINK SETUP FAILURE and RNSAP: RADIO LINK ADDITION FAILURE messages include the neighbour cell information for any successful radio link.

The Neighbouring GSM Cell Information IE contains the following information for each GSM neighbour cell:

• CGI • BSCI • Band Indicator • BCCH ARFCN

The DRNC does not include any optional IEs in the Neighbouring GSM Cell Information IE.

The SRNC takes into account the GSM neighbour cell information, which has been received from the DRNC, in the inter-system measurement and handover decision pro-cedures.

15.2 Handover control parameter sets during anchoringUse of the FMCG and HOPG parameter sets of the reference cell during anchoringThe handover control of the SRNC uses the FMCG and HOPG parameter sets (data-base objects) of the reference cell object (VCEL Object) for the inter-system handover control during anchoring. The FMCG and HOPG parameter sets are selected by the

168 DN03471612


Id:0900d80580708dbdConfidential

Functionality of inter-system handover during anchor-ing

VCEL RtFmcgIdentifier/NrtFmcgIdentifier and RtHopgIdentifier/NrtHopgIdentifier parameters. Different FMCG/HOPG parameter sets are used for Real Time (RT) and Non-Real Time (NRT) radio bearers.

In non-anchoring cases, when handover is done to a GSM neighbour cell which has no ADJG definition in the ADJG list of the SRNC, the RtHopgIdentifier/NrtHopgIdentifier parameters of the VCEL object are used. If the selected HOPG database object does not exist in the database, the handover control use the default values of the HOPG parameters .

Cell specific parameters used during anchoringThe handover control of the SRNC uses cell specific parameters of the reference cell object (VCEL object) during anchoring because all the active set cells are managed by DRNC and there is no cell specific information of these cells available in the SRNC. Anchoring takes place because of RNC-RNC anchoring (when the DRNC or CN does not support SRNS relocation) or anchoring because of I-BTS sharing.

BTS specific parameters to be used during anchoringHandover control of the SRNC uses VBTS parameters during anchoring to configure the dedicated measurements in the DRNC.

Note that the handover control of the SRNC does not modify ongoing transmitted code power (dedicated) measurements which have been started in a DRNC before anchor-ing.

15.3 Inter-RAT measurements and handover decision during anchoringThe SRNC supports the following inter-RAT (GSM) handover causes for both real time and non-real time radio bearers during anchoring:

• inter-RAT handover (or cell reselection) to GSM because of Uplink DCH quality • inter-RAT handover (or cell reselection) to GSM because of the UE Tx power • inter-RAT handover (or cell reselection) to GSM because of Downlink DPCH power • inter-RAT handover (or cell reselection) to GSM because of CPICH RSCP • inter-RAT handover (or cell reselection) to GSM because of CPICH Ec/No • IMSI based inter-system handover (including Immediate IMSI based handover) • directed emergency call inter-system handover

Handover decision algorithmThe handover decision algorithm for the inter-RAT handover to GSM during anchoring is based on the mechanism for inter-system handover in non-anchoring situations, see section Handover decision procedure for inter-system handover.

InterRatNcellTxPwrMaxTCH parameter indicates the maximum Tx power level (dBm) an UE may use in the GSM neighbour cell(n). Since this information is not received over Iur as a part of the GSM neighbour cell info, handover control uses the default value of this parameter.

DN03471612 169

WCDMA RAN RRM Handover Control Functionality of IMSI-based handover


16 Functionality of IMSI-based handover

16.1 Configuration of IMSI-based handoverWCDMA subscriber group (WSG)WCDMA subscriber group (WSG) refers to all subscribers of one operator, which are identified with the same PLMN identifier that is included in the IMSI of the subscribers. Up to 128 different WCDMA subscriber groups can be defined.

The WCDMA subscriber group links the home PLMN of the subscriber with specified authorised networks (PLMNs). The RNC is able to associate the maximum of 128 spec-ified home PLMNs with specified authorised networks. The WSG parameters are composed of the following parameters:

• Subscriber Group Identifier (SubscriberGroupId) identifies a subscriber group uniquely within the RNC.

• Subscriber Home PLMN (HomePLMN) contains the identifier of the home PLMN of a subscriber.

• Identifier of the Authorised Network (WSGAuthorisedNetworkId) identifies a group of authorised PLMNs which are considered equal to the home PLMN of a sub-scriber.


An example of selecting the authorised network identifier is illustrated in Figure An example of selecting the authorised network list below. The PLMN identifier of the sub-scriber is 123 45.

Figure 54 An example of selecting the authorised network list

All PLMNs are authorised for a subscriber when the value of the Identifier of the Autho-rised Network (WSGAuthorisedNetworkId) parameter is zero. If the home PLMN of a subscriber does not belong to a subscriber group, the RNC uses a default authorised network. The identifier of the default authorised network is determined by the Identifier of the Default Authorised Network (DefaultAuthorisedNetworkId) parameter.

WCDMA authorised networks (WANE)WCDMA Authorised Networks (WANE) refers to a group of PLMNs that are considered equal to the home PLMN of a subscriber. This means that a subscriber has the same access rights to all PLMNs which belong to the WANE. One WANE list contains a

WSGId

HomePLMN WSGAuthorisedNetwork

1

2

3

126

127

128

123 12

123 34

123 45

1

0

2

PLMN 123 45Authorised

network Id 2

170 DN03471612



Functionality of IMSI-based handover

maximum of six PLMN identifiers. Up to 10 different WANE lists can be defined. The WANE parameters are composed of the following parameters:

• Authorised Network Identifier (AuthorisedNetworkId) identifies a group of PLMNs that are considered equal to the home PLMN of a subscriber.

• List of authorised Networks (AuthorisedNetworkList) determines the PLMN identifi-ers which are considered equal to the home PLMN of the subscriber.

• Authorised Network PLMN (AuthorisedNetworkPLMN) determines a PLMN identi-fier which is considered equal to the home PLMN of the subscriber.

• Technology Used in Authorised Network (Technology) determines the radio network technology (WCDMA, GSM, or both) which is related to the PLMN of an authorised network.Note that when the Technology parameter has the value 'GSM', the subscriber is only allowed to make handovers to GSM cells including the corresponding PLMN identifier. If the parameter value is 'WCDMA', handovers can only be made to WCDMA cells including the corresponding PLMN identifier. If the parameter value is 'GSM and WCDMA', the subscriber is allowed to make handovers to all cells (both GSM and WCDMA) containing the corresponding PLMN identifier.

Inter-PLMN handover within RNCWhen the IMSI-based handover feature is enabled in the RNC, the RNC is able to perform intra-RNC handovers between cells which belong to different PLMNs.

When the IMSI-based handover feature is enabled in the RNC, it is possible to define (in addition to the primary PLMN identifier that is a part of the CN domain identifier) sec-ondary PLMN identifiers under the RNC. The secondary PLMN identifiers are assigned to shared network areas where the subscribers of the partner operator can have access. The maximum number of secondary PLMN identifiers is three. Thus the PLMN a cell belongs to, can be selected from four alternative (1 primary and 3 secondary) PLMNs if the IMSI-based handover feature is enabled in the RNC.

The List of shared area PLMNs (SharedAreaPLMNlist) parameter determines the PLMN identifiers of the shared network to which the subscribers of the partner operator can have access.

When the Multi-Operator Core Network feature is enabled in the RNC, the IMSI Based Handover feature is available, too.

16.2 IMSI-based intra-frequency handoverThe IMSI Based SHO (IMSIbasedSHO) measurement control parameter indicates whether the IMSI-based intra-frequency handover is enabled in the cell.

The IMSI-based handover feature does not affect the intra-frequency measurement pro-cedure. That is, the RNC makes the neighbor cell lists for the intra-frequency measure-ment regardless of the PLMN identifiers of the neighboring cells.

When the IMSI-based intra-frequency handover is enabled in an active set cell, the RNC adds a new cell to the active set only if the PLMN identifier of the cell, which has trig-gered reporting event 1A or 1C, is included in the relevant WANE list, or it must have the same PLMN identifier as the subscriber or an active set cell. For more information, see Section Configuration of IMSI-based handover.

Similarly, in case of an inter-RNC intra-frequency hard handover, the PLMN identifier of the target cell must be included in the relevant WANE list, or it must have the same

DN03471612 171

WCDMA RAN RRM Handover Control Functionality of IMSI-based handover


PLMN identifier as the subscriber or an active set cell before the RNC can perform the intra-frequency hard handover to the target cell.

If the neighbor cell does not fulfil any of the preceding PLMN requirements and the neighbor cell is clearly the strongest intra-frequency cell, the RNC can release the RRC connection to avoid excessive uplink interference because of non-optimum fast closed loop power control (that is, the UE is not linked with the strongest cell anymore). For more information, see Section Functionality of intra-frequency handover.

When detected set reporting based soft handover is enabled in one or more active set cells, a detected set cell can be added to the active set in addition to the monitored set cells if it fulfils the preceding PLMN requirements. The detected cell needs to be defined in the ADJS or ADJD database objects of the active set cells. For more information see Section Handover control.

16.3 IMSI-based inter-frequency handoverThe IMSI Based IFHO (IMSIbasedIFHO) measurement control parameter indicates whether the IMSI-based inter-frequency handover is enabled in the cell.

When the IMSI-based inter-frequency handover is enabled in an active set cell, the RNC selects only those neighboring cells into the inter-frequency neighbor cell list whose PLMN identifier is either included in the relevant WANE list or which have the same PLMN identifier as the subscriber. The procedure is the same for all inter-frequency handover causes. For more information, see Section Configuration of IMSI-based han-dover.

16.4 IMSI-based inter-system handoverThe IMSI Based GSM HO (IMSIbasedGsmHo)measurement control parameter indi-cates whether the IMSI based inter-system handover to GSM is enabled in the cell or not.

When the IMSI based inter-system handover is enabled in an active set cell, the RNC selects only those GSM neighbor cells into the inter-system neighbor cell list whose PLMN identifier is either included in the relevant WANE list or which have the same PLMN identifier as the subscriber. The procedure is the same for all inter-system handover causes. For more information, see Section Configuration of IMSI-based han-dover.

172 DN03471612



Functionality of immediate IMSI-based handover

17 Functionality of immediate IMSI-based handover

17.1 Immediate IMSI-based inter-frequency handoverImmediate IMSI based inter-frequency handover is controlled with the following param-eters (for a description of the parameters, see WCDMA Radio Network Configuration Parameters):

• IMSI Based SHO (IMSIbasedSHO) indicates whether the IMSI-based intra-fre-quency handover is enabled in the cell or not.

• IMSI Based IFHO (IMSIbasedIFHO) indicates whether the immediate IMSI-based inter-frequency handover is enabled in the cell or not.

• Minimum CPICH Ec/No for IFHO (AdjiMinEcNo) determines the minimum required CPICH Ec/No (dB) level in the best inter-frequency neighbor cell.

• Minimum CPICH RSCP for IFHO (AdjiMinRscp) determines the minimum required CPICH RSCP (dBm) level in the best inter-frequency neighbor cell (n).

• Maximum UE TX Power on DPCH (AdjiTxPwrDPCH) indicates the maximum trans-mission power level (dBm) an UE can use on the DPCH in the neighboring cell.

When both the IMSI-based intra-frequency handover and the immediate IMSI-based inter-frequency handover are enabled in an active set cell, the RNC initiates an imme-diate IMSI-based handover procedure if the RNC cannot add a cell into the active set because the PLMN identifier of the cell does not fulfil the requirement of home/autho-rised/active set PLMNs. For more information, see IMSI-based intra-frequency handover in Functionality of IMSI-based handover.

When the detected set reporting based soft handover is enabled in one or more active set cells, also a detected set cell can trigger immediate IMSI based handover (in addition to the monitored set cells) if the detected cell is defined in the ADJS or ADJD database objects of the active set cells.

The RNC selects only those neighboring cells into the inter-frequency neighbor cell list whose PLMN identifier is either included in the relevant WANE list or which have the same PLMN identifier as the subscriber. The RNC performs the inter-frequency mea-surement as described in Measurement procedure for inter-frequency handover in Functionality of inter-frequency handover.

The measurement results of the best inter-frequency neighbor cell must satisfy the fol-lowing equations before the immediate IMSI-based inter-frequency handover is possi-ble:

AVE_EcNo_NCELL (n) > AdjiMinEcNo (n)

AVE_RSCP_NCELL (n) > AdjiMinRscp (n) + max( 0, AdjiTxPwrDPCH (n) – P_MAX )

In the equations above, AVE_EcNo_NCELL (n) and AVE_RSCP_NCELL(n) are the averaged CPICH Ec/No and RSCP values of the best (according to CPICH Ec/No) inter-frequency neighbor cell (n). P_MAX indicates the maximum RF output power capability of the UE (dBm) in WCDMA.

The neighbor Cell Search Period (InterFreqNcellSearchPeriod) parameter determines the period starting from inter-frequency measurement setup during which an inter-fre-quency handover is not possible. After the period has expired, the RNC evaluates the radio link properties of the best neighbor cell after every inter-frequency measurement

DN03471612 173

WCDMA RAN RRM Handover Control Functionality of immediate IMSI-based handover


report. The RNC performs the immediate IMSI-based inter-frequency handover to a best neighbor (target) cell as soon as the best neighbor cell meets the required radio link properties.

Regarding averaging values, the RNC calculates them directly from the measured dB and dBm values, linear averaging is not used in this case. The sliding averaging window is controlled with the parameter Measurement Averaging Window (Inter-FreqMeasAveWindow). The RNC starts averaging already from the first measurement sample, that is, the RNC calculates the averaged values from those measurement samples which are available until the number of samples is adequate to calculate averaged values over the whole averaging window.

If HSDPA inter-frequency handover is activated, immediate IMSI based HSPA inter-fre-quency handover is performed as described in Section Functionality of inter-frequency handover.

17.2 Immediate IMSI-based inter-system handoverImmediate IMSI-based inter-system handover is controlled with the following parame-ters (for a description of the parameters, see WCDMA Radio Network Configuration Parameters):

• IMSI Based SHO (IMSIbasedSHO) indicates whether the IMSI based intra-fre-quency handover is enabled in the cell or not.

• IMSI Based GSM HO (IMSIbasedGsmHo) indicates whether the immediate IMSI based inter-system handover to GSM is enabled in the cell or not.

When both the IMSI-based intra-frequency handover and the immediate IMSI-based inter-system handover are enabled in an active set cell, the RNC initiates an immediate IMSI-based handover procedure if the RNC cannot add a cell into the active set because the PLMN identifier of the cell does not fulfil the requirement of home/authorised/active set PLMNs. For more information, see section IMSI-based intra-frequency handover in Functionality of IMSI-based handover.

When the detected set reporting based soft handover is enabled in one or more active set cells, also a detected set cell can trigger immediate IMSI based handover (in addition to the monitored set cells) if the detected cell is defined in the ADJS or ADJD database objects of the active set cells. The RNC selects only those GSM cells into the neighbor cell list whose PLMN identifier is either included in the relevant WANE list or which have the same PLMN identifier as the subscriber. The RNC performs the inter-system (GSM) measurement as described in Measurement procedure in Functionality of inter-system handover.

The RNC makes the handover decision on the basis of periodic inter-system measure-ment reports received from the UE and relevant control parameters, as described in Handover decision procedure in Functionality of inter-system handover.

174 DN03471612


Id:0900d8058083cbf1Confidential

Functionality of load-based and service-based IF/IS handover

18 Functionality of load-based and service-based IF/IS handover

18.1 Load-based handoverThe RNC checks load-based handover triggers periodically in each cell. Checking is performed every time when new interference information is received from the BTS or a cell.

The following reasons can trigger a load-based handover procedure in a cell:

• The total interference load of the cell exceeds a predefined threshold. • PS NRT traffic capacity request rejection rate exceeds a predefined threshold. • Downlink spreading codes are lacking in the cell. • HW or logical resources are limited in the cell.

If one of the preceding reasons is fulfilled, the cell is in a load-based handover state. Note that a load-based handover state in the cell does not stop service-based han-dovers.

18.1.1 Total interference load of the cell exceeds a predefined thresholdThresholds for the interference load are defined with the following RNP (WCEL) param-eters:

• LHOPwrOffsetUL

• LHOPwrOffsetDL

These parameters define power offset in dB compared to target power (for example Prx-Target (UL) and PtxTarget (DL)).

The CRNC observes the interference load of the cell in the following way. Target for the interference load of the cell is defined with the PtxTarget RNP parameter. Target of the total received interference power is defined with the PrxTarget RNP parameter.

In addition to the received wide band interference, the uplink load is also measured in the DCH throughput domain. The RNC maintains in each cell the Uplink DCH own cell load factor LDCH,CELL of the DCH users; the WCDMA RAN RRM Admission Control describes in detail how the value of the LDCH,CELL is produced. A particular uplink DCH own cell load threshold LLHO is defined in the throughput domain for the needs of the load-based handover with the following equation:

Figure 55 Definition of uplink DCH own cell load threshold LLHO

Quantity Ptarget+LHO is the linear value of the sum of the dB-values of the PrxTarget and LHOPwrOffsetUL management parameters.

LminDCH is the planned minimum uplink DCH own cell load factor; its value is defined with the Interference margin for the minimum UL DCH load (PrxLoadMarginDCH) manage-ment parameter. For more information, see Section Estimations for the received throughput and interference in "WCDMA RAN RRM Admission Control". The CRNC is

LLHO = MAX 0, MIN 1-1

Ptarget + LHO

, LminDCH

DN03471612 175

WCDMA RAN RRM Handover Control Functionality of load-based and service-based IF/IShandover


allowed to allocate the uplink DCH resources up to this throughput limit without consid-ering the received wideband interference.

The RNC also uses a planned maximum uplink DCH own cell load factor LmaxDCH in its uplink DCH resource allocation. The value of the load factor LDCH,CELL does not exceed the value of LmaxDCH. The value of LmaxDCH is defined with the Interference margin for the maximum UL DCH load (PrxLoadMarginMaxDCH) management parameter. For more information, see Section Estimations for the received throughput and interference in "WCDMA RAN RRM Admission Control".

HSDPA not activated in the cellIf HSDPA is not activated in a cell and one of the two following conditions is true, the load-based handover state begins in the cell.

(1) (PrxTotal > PrxTarget + LHOPwrOffsetUL) AND (LDCH,CELL > LLHO)

OR LDCH,CELL > LmaxDCH ·lin(LHOPwrOffsetUL)

(2) PtxTotal > PtxTarget + LHOPwrOffsetDL

Quantity lin(LHOPwrOffsetUL) is the value of the LHOPwrOffsetUL parameter in the linear notation.

Condition (1) enables the uplink load-based handover decision in the throughput domain and the decision remains interference based, when the uplink DCH allocations are done as interference based. The load-based part of it states that the cell have enough uplink DCH traffic, in another case, the load-based handover state is not set though the adjacent cell interference or interference spikes were experienced in the cell. When the minimum uplink throughput threshold has been exceeded, the traffic is transferred from the spiking cell. Load-based handover state is also entered if the noise level was over-estimated and the uplink DCH load is observed to approach the throughput- based overload threshold.

Note that if the PrxTotal of the cell is higher than PrxTarget + PrxOffset and LDCH,CELL is bigger than LminDCH or PtxTotal of the cell is higher than PtxTarget ,the activation of the compressed mode is denied, which means that the handover measurements with CM are not possible.

HSUPA users in the cellNote that in the case of the dynamic sharing of the received interference between the HSPA and DCH users, if there is at least one E-DCH MAC-d flow established in the cell at issue, the non-E-DCH interference power PrxNonEDCH value is used in the cell instead of the total received interference power PrxTotaI in the interference based deci-sions. Furthermore, the maximum value of the dynamic target threshold for uplink DCH packet scheduling, defined by the operator adjustablePrxTargetPSMax management parameter, is used as the interference threshold instead of the PrxTarget. For more information, see WCDMA RAN RRM HSUPA.

The load of HSUPA RT services is taken into account when load based handover state triggering is checked for uplink reasons.

UL interference triggers load based handover state in a cell.

Every time when power measurement is received from the BTS, RNC calculates LHOra-

tioPrx, which is load ratio of received interference power compared to defined threshold value.

176 DN03471612




LHOratioPrx is calculated with the following equations:

PrxNonEDHST(t) is the sample of the averaged estimated received wide band power of the cell, excluding the interference of the ST E-DCH traffic. PrxTargetPSMax is the maximum allowed value for the dynamic target PrxTargetPS of the UL NRT DCH scheduling. In this expression, PrxTargetPSMax is expressed as an absolute value (dBm). LCELL(t) is the own cell load factor of the bearers causing the interference PrxNonEDCHST(t) in the cell. Its value is achieved from the following equation:

LDCH,CELL is the own cell load factor of the DCH users, for more information see in "WCDMA RAN RRM Admission Control".

LmaxDCH is the maximum UL load threshold for the TrCH allocation, for more information see in "WCDMA RAN RRM Admission Control".

Note that if value of LHOratioPrx is bigger than 1, it indicates the load based handover state.

HSDPA activated to the cellIf HSDPA is activated in a cell then the load-based handover state for downlink is set like described below.

Every time when new interference information is received from the BTS, RNC calculates LHOratioPtx, which is load ratio of transmitted interference power compared to defined threshold value. If no MAC-d flows were allocated in the cell (no HSDPA users) the LHOratioPtx is calculated as defined in the equation below.

Figure 56 Calculation of LHOratioPtx in case of there is no HSDPA users in the cell.

If at least one MAC-d flow was allocated in the cell (HSDPA used), but HSDPA dynamic resource allocation is not in use, then the LHOratioPtx is calculated as defined in the fol-lowing equation.

Figure 57 Calculation of LHOratioPtx in case of there is no HSDPA users in the cell.

If the HSDPA dynamic resource allocation is in use and there is at least one HSDPA user in the cell, the LHOratioPtx is calculated as defined in the following equations (used LHOratioPtx is the biggest value of values LHOratioPtx1, LHOratioPtx2 and LHOratioPtx3).

LHOratioPrx1(t)10PrxONedchst(t) PrxTargetPSMax(t) LHOpwrOffsetUL––

10------------------------------------------------------------------------------------------------------------------------------------------------------

LCELL t( )⎩⎪⎨⎪⎧

=

LHOratioPrx2 t( )LCELL t( )

LmaxDCH 10LHOpwrOffsetUL/10•-------------------------------------------------------------------------------=

LHOratioPrx t( ) MAX LHOrat ioPrx1 t( ) LHOratioPrx2 t( ) ],[=

LCELL t( ) LDCH CELL, t( ) LncEDCH, CELL t( ) LstrEDCH, CELL t( )+ +=

LHOratioPtx(t) =PtxTotal(t)

PtxTarget(t) + LHOpwrOffsetDL

LHOratioPtx(t) =PtxnonHSPA(t)

PtxTargetHSDPA(t) + LHOpwrOffsetDL

DN03471612 177



Figure 58 Calculation of LHOratioPtx in case there is at least one HSDPA user in the cell.

Downlink load ratio values (LHOratioPtx) are arithmetically averaged over LHO window. If equation below is true downlink interference triggers load based handover procedure.

Figure 59 LHOratioPtx condition for triggering load based handover procedure.

PtxTotal(t) is the sample of the averaged total transmission power when HSDPA power is not allocated.PtxTotal(t) value is produced as specified in the WCDMA RAN RRM Admission Control. PtxTarget(t) is target transmission power for DCH scheduling.

PtxNonHSPA(t) is the sample of the averaged non HSPA transmission power when HSDPA power is allocated. PtxNonHSPA(t) value is produced as specified in the WCDMA RAN RRM HSDPA.

PtxTargetHSDPA(t) is target transmission power for DCH scheduling when HSDPA dynamic resource allocation is not in use and there are HSDPA users in the cellpower is allocated.

LHOpwrOffsetDL is power offset in dB compared to target power PtxTarget and PtxTar-getHSDPA.

PtxTargetPSMax is the maximum allowed value for dynamically adjusted PtxTargetPS threshold

PtxTargetPS is dynamic target transmission power for DCH scheduling when HSDPA dynamic resource allocation is in use and there are HSDPA users in the cell. PtxTar-getHSDPA is replaced with the PtxTargetPSMax in the case of dynamic power alloca-tion in equation: Figure 56 Calculation of LHOratioPtx in case of there is no HSDPA users in the cell.

18.1.2 Rejection rate of PS NRT traffic capacity requests exceeds a pre-defined thresholdIf the rejection rate of PS NRT traffic capacity request in a cell exceeds a predefined threshold, in either downlink or uplink direction, load-based handover actions take place in the cell.

The of PS NRT traffic capacity request rejection rate is defined in the following way:

CapaReqRejRateUL = RejectedRequestsCellUL / (AllCapacityRequestsCellUL + LHONRTTrafficBaseLoad)

CapaReqRejRateDL = RejectedRequestsCellDL / (AllCapacityRequestsCellDL + LHONRTTrafficBaseLoad)

LHOratioPtx(t) = MAX(LHOratioPtx1(t),LHOratioPtx2(t),LHOratioPtx3(t))

LHOratioPtx1(t) =PtxnonHSPA(t)

PtxTargetPSMax(t) + LHOpwrOffsetDL

LHOratioPtx2(t) =PtxnonHSPA(t) + PtxNC

HSDPA

PtxTargetTotMax(t) + LHOpwrOffsetDL

LHOratioPtx3(t) =PtxnonHSPA(t) + PtxNC

HSDPA +PtxSC

HSDPA

Pmax + LHOpwrOffsetDL

LHOratioPtx(1) + LHOratioPtx(2) + ... + LHOratioPtx(n)

n> 1

178 DN03471612




Those PS NRT traffic capacity requests that cannot be satisfied are divided by the sum of all PS NRT traffic capacity requests and NRT traffic base load in this cell in both uplink and downlink directions.

The NRT traffic base load is defined with the LHONRTTrafficBaseLoad (WCEL) RNP parameter. It is used to prevent the measurement from being too sensitive when there is minor actual NRT traffic with low success ratio in the cell.

The following RNP (WCEL) parameters define threshold points in uplink and downlink directions:

• LHOCapaReqRejRateUL

• LHOCapaReqRejRateDL

The following equations are used to evaluate the situation:

CapaReqRejRateUL > LHOCapaReqRejRateUL

CapaReqRejRateDL > LHOCapaReqRejRateDL

If one of the previous equations is true, load-based handover actions take place in this cell.

18.1.3 Downlink spreading codes are lacking in the cellSometimes the interference load of the cell is not the limiting factor, but rather the lack of downlink spreading codes. The following equation defines the measurement for the lack of downlink spreading codes:

ReservationRateSC(SF=128) = ReservedSC / NumbAvailableSC * 100

The equation defines the percentage of reserved spreading codes divided by all possible spreading codes in the spreading code tree in the level SF = 128.

ReservedSC contains only the minimum number of HS-PDSCH codes defined by the lowest value in the HSPDSCHCodeSet management parameter. If the number of allo-cated HS-PDSCH codes is greater than the minimum value, those HS-PDSCH codes exceeding the minimum value are not considered as reserved ones in terms of spread-ing code load.

The following RNP (WCEL) parameter defines the threshold for the reservation situation of the downlink spreading codes. The range is from 0 % to 100 %.

• LHOResRateSC

The following equation is used to evaluate the situation:

ReservationRateSC > LHOResRateSC

If the inequality is true, load-based handover actions take place in this cell.

18.1.4 HW or logical resources are limited in the cellThere are no exact meters for investigating the HW or logical resource reservation rate of the cell. The HW or logical resource reservation rate can be detected only when con-gestion is faced.

A load-based handover state is triggered because of HW or logical resource congestion in the cell when a quotient of the number of samples indicating cell-specific hard blocking and all samples added with the base load during the measurement period exceeds the threshold. This threshold is defined with the LHOHardBlockingRatioRNP parameter. Hard-blocking base load is defined with the

DN03471612 179



LHOHardBlockingBaseLoadRNP parameter. Hard blocking occurs when a DCH setup attempt faces congestion of the BTS or Iub AAL2 transmission capacity. ‘All samples’ is defined to be the number of successful and unsuccessful BTS or Iub AAL2 transmission capacity hunts in the DCH setup attempts.

The following equation is used to evaluate the situation:

NumberOfSamplesHardBlocking / (AllSamplesHWhuntDuringMeasPeriod + LHOHardBlockingBaseLoad) * 100 % > LHOHardBlockingRatio

18.1.5 Processing of measurement results indicating loadA load situation in the WCDMA cell can vary a lot even during a short period of time. That is why both the starting and stopping of the load-based handover state in the cell is based on averaged measurement results. It is practical to have the averaging period of starting (LHOWinSizeON*) longer than the averaging period of stopping (LHOWinSizeOFF*).

When the value of the LHOWinSizeON* parameter is higher than the value of the LHOWinSizeOFF* parameter, load-based handover procedures are started if the averaged load in both starting and stopping window rises above the load threshold and stays there for the requested hysteresis time. Load-based handover procedures are stopped if the averaged load within the stopping window goes below the load threshold.

When the value of the LHOWinSizeON* parameter is lower than the value of the LHOWinSizeOFF* parameter, load-based handover procedures are started if the averaged load in the starting window rises above the load threshold and stays there for the requested hysteresis time. Load-based handover procedures are stopped if the averaged load in both starting and stopping window goes below the load threshold.

One load reason is enough to trigger the load-based handover state in the cell. All the load reasons must be OFF until the load-based handover state is stopped.

In all cases, the averaging window has to be full until the calculation is completed. If the averaging window for starting load-based handovers is defined as 0, the corresponding load trigger is not used in the cell.

The following figure illustrates the principles of the measurement procedure and the trig-gering of the load-based handover. The same procedure is used with all four load trig-gers.

180 DN03471612




Figure 60 Measurement procedure for all four load triggers

Interference load of the cellArithmetical averaging is used. The same averaging period specified in seconds is used for both uplink and downlink directions.

Measurement averaging periods are defined with the following RNP (WCEL) parame-ters:

• LHOWinSizeONInterference [seconds] • LHOWinSizeOFFInterference [seconds]

Every common measurement reporting period, power values are sampled and mea-surement windows are moved. Reporting periods are defined for each applicable mea-surement type by the following management parameters:

• RRIndPeriod defines in the WBTS cell the moving period for the averaging windows of the measurements related to the estimated received interference power PrxTotal and the estimated transmitted carrier power PtxTotal.

• PrxTotalReportPeriod defines the moving period for the averaging window of the estimated received interference power PrxTotal measurement in the NB/RSxxx cell.

• PtxTotalReportPeriod defines the moving period for the averaging window of the estimated transmitted carrier power PtxTotal measurement in the NB/RSxxx cell.

Management parameter NBAPCommMode defines the BTS type the cell belongs to.

Load-based handovers are started if the averaged load rises above the requested threshold and stays there for the requested hysteresis time. Hysteresis time for the inter-ference load measurement is defined with the following RNP (WCEL) parameter:

• LHOHystTimeInterference [seconds]

Load based HOs arestarted if load risesabove the thresholdand stays there forthe hysteresis time

Load basedHO state

triggers ONLoad based HO state

"ON" indication shall bebroadcasted in this point

1. Sliding window toaverage measurementsamples when startingload based HO state

2. Hysteresistime

3. Sliding window toaverage measurementsamples when stopping

load based HO state

Load HOs

Activation of new loadbased HOs stopped

Load based HO state"OFF" indication shall bebroadcasted in this point

Load basedHO state

triggers OFF

4. Timer which delaysbroadcasting of load

based HO state "OFF"indication

1. 2.

3.

1.3.

3.

1.

4.t

DN03471612 181



The delay in the removal of the load-based handover state from the cell is controlled with the following RNP (WCEL) parameter:

• LHODelayOFFInterference [seconds]

The measurement window is moved every common measurement reporting period for each applicable measurement type. Reporting periods are defined in WCDMA RAN RRM Admission Control.

PS NRT traffic capacity request rejection rate in the cellArithmetical averaging is used. The same period is used for both uplink and downlink directions.

Measurement periods are defined with the following RNP (WCEL) parameters:

• LHOWinSizeONCapaReqRejRate [seconds] • LHOWinSizeOFFCapaReqRejRate [seconds]

Load-based handovers are started if the averaged load rises above the requested threshold and stays there for the requested hysteresis time.

Hysteresis time for the NRT load measurement is defined with the following RNP (WCEL) parameter:

• LHOHystTimeCapaReqRejRate [seconds]

The delay in the remove of the load-based handover state from the over cell is controlled with the following RNP (WCEL) parameter:

• LHODelayOFFCapaReqRejRate [seconds]

The number of capacity requests counter is updated during the measurement window when a resource is allocated for the capacity request or when the capacity request is rejected because of any reason. The measurement window is moved once a second.

Lack of downlink spreading codes in the cellThe RNC checks the load situation in the cell every time when a spreading code reser-vation rate is calculated.

The following RNP parameters (WCEL) define the period over which the DL SC reser-vation rates are averaged arithmetically:

• LHOWinSizeONResRateSC [seconds] • LHOWinSizeOFFResRateSC [seconds]


Hysteresis time for the DL SC reservation rate measurement is defined with the follow-ing RNP (WCEL) parameter:

• LHOHystTimeResRateSC [seconds]


• LHODelayOFFResRateSC [seconds]

The measurement window is moved every time new interference information is received from the BTS (RRI period).

Lack of HW or logical resources in the cellMeasurement periods are defined with the following RNP (WCEL) parameters:

182 DN03471612




• LHOWinSizeONHardBlocking [seconds] • LHOWinSizeOFFHardBlocking [seconds]


Hysteresis time for the hard-blocking measurement is defined with the following RNP (WCEL) parameter:

• LHOHystTimeHardBlocking [seconds]


• LHODelayOFFHardBlocking [seconds]

Both counters number of all attempts and number of unsuccessful attempts are updated when the corresponding hunting attempt is successfully or unsuccessfully terminated. The measurement window is moved once a second.

18.1.6 Number of UEs simultaneously in the load-based handover proce-dureThe following RNP (WCEL) parameters define the maximum number of UEs that are simultaneously in a load-based handover procedure in the cell:

• LHONumbUEInterFreq • LHONumbUEInterRAT

The load-based handover feature is not in use in the cell if the parameter is defined as zero.

The aim is that when the load-based handover state is on in the cell, the RNC selects as many UEs as possible to the procedure until the load-based handover state is over. That is, when the load-based handover procedure of one UE ends, a new UE is selected to the procedure.

18.1.7 Selection of RRC connections for the load-based handover proce-dureThe following criteria are used to select UEs for the load-based handover procedure. The criteria are presented in order of priority.

Note that if the predefined number of UEs can be selected during the first five steps of the following procedure, the last steps (6…8) are not checked.

At the beginning, all the RRC connections in the cell which can perform a load-based handover according to the service type are candidates for the load-based handover pro-cedure.

1. RRC connections whose SRNC is the RNC where the load-based handover was triggered.Those RRC connections are not selected whose SRNC is other than the RNC where the load-based handover has triggered. That is because RRC signaling terminates in the SRNC and there is no way to transmit load-based handover commands from the DRNC to SRNC through the Iur interface.

DN03471612 183



2. RRC connections which are not performing inter-frequency or inter-RAT handover measurements.If an RRC connection is already performing inter-frequency or inter-RAT handover measurements, it means that the handover procedure is ongoing because of some other handover reason.

3. RRC connections whose repetitive handover or network-controlled cell reselection procedures are not restricted.

4. RRC connection using a pure NRT service is accepted only if its DCH allocation has lasted over a certain period of time.The period is defined with the LHOMinNrtDchAllocTime (RNC) RNC configura-tion parameter. Note that DCH allocation can take a long time.

5. RRC connections which are not in the preferred RAT or hierarchical WCDMA layer and RRC connections which are in preferred hierarchical WCDMA layer but at least one equal target is available.The RNC investigates which RRC connections are not in the preferred RAT or hier-archical WCDMA layer, checks if the selected target is available, and selects those as candidates for the load-based handover procedure. Also RRC connections which are in preferred hierarchical WCDMA layer but at least one equal target is available are selected as candidates for the load-based handover procedure.In the first phase, only first priority cases are selected as candidates for the load-based handover procedure. If there are not enough RRC connections available for the procedure in the first phase, the second phase takes place and second priority cases are selected as candidates for the load-based handover procedure. Finally, if there are not enough RRC connections that can be selected in the first and second phases, the third phase takes place.If no RRC connection can be selected even after the third phase, no handover pro-cedures are performed and, finally, overload control of the RNC performs its actions if needed.

6. RRC connections which cause the highest load in the cell.The selection of RRC connections depends on the load trigger which has triggered: • If DL interference load has triggered, RRC connections with the highest

downlink power are selected. • If UL interference load has triggered, RRC connections with the smallest

minimum UL spreading factor are selected. • If DL NRT capacity request rejection rate has triggered, RRC connections with

the highest downlink power are selected. • If UL NRT capacity request rejection rate has triggered, RRC connections with

the smallest minimum UL spreading factor are selected. • If DL spreading code capacity has triggered, RRC connections with the smallest

minimum DL spreading factor are selected. • If HW or logical resource capacity of the cell has triggered, the RRC connections

with the smallest minimum UL and DL spreading factor are selected.7. RRC connections which do not require a compressed mode to perform inter-fre-

quency or inter-RAT measurements (the relevant measurement type depends on the type of the load-based handover).

8. Finally, the RNC selects the required number of RRC connections in free order from the group of RRC connections which are selected during the previous steps.

184 DN03471612




18.2 Service-based handoverFor the HSDPA-capable UE in HSDPA cell, the service-based handover is effective as follows:

1. Service-based handover will not happen when HSDPA MAC-d flow is allocated.2. Service-based handover will not happen when PS NRT DCH 0 kbps and PS stream-

ing DCH 0 kbps are allocated.3. Service-based handover will not happen when standalone PS NRT 0/0 is allocated.4. Service-based handover can happen when CS call is allocated.5. Service-based handover can happen when CS+PS 0/0 multi-RAB is allocated.

18.2.1 Number of RRC connections simultaneously in the service-based handover procedureService-based handover actions are started in a certain cell periodically. The following RNP parameters (WCEL) define the duration of the period:

• ServHOPeriodInterFreq • ServHOPeriodInterRAT

The service-based handover feature is not in use in the cell if the parameter is defined as zero.

Each time a service-based handover is started in the cell, a certain number of RRC con-nections is selected in the procedure, if possible. The number of selected RRC connec-tions is defined with the following RNP parameters (WCEL):

• ServHONumbUEInterFreq

• ServHONumbUEInterRAT

18.2.2 Selecting RRC connections for the service-based handover proce-dureThe following criteria are used to select RRC connections for the service-based handover procedure. The criteria are listed in order of priority. Note that if the predefined number of RRC connections can be selected during the first five steps of the following procedure, the last steps (6-7) are not checked.

At the beginning, all the RRC connections in the cell which can perform a service-based handover according to the service type are candidates for the service-based handover procedure.

1. RRC connections whose SRNC is the RNC where the service-based handover has triggered.Those RRC connections are not selected whose SRNC is other than the RNC where the cell-based service handover has triggered. That is because RRC signaling ter-minates in the SRNC and there is no way to transmit service-based handover commands from the DRNC to the SRNC through the Iur interface.

2. RRC connections which do not perform inter-frequency or inter-RAT handover mea-surements.If the RRC connection already performs inter-frequency or inter-RAT handover mea-surements, it means that the handover procedure is ongoing because of some other handover reason.

DN03471612 185



3. RRC connections whose repetitive handover or network-controlled cell re-selection procedures are not restricted.

4. RRC connections that are in the CELL_DCH state.Service-based handovers are performed only for those RRC connections that are in the CELL_DCH state.

5. RRC connections that are not in the preferred RAT or hierarchical WCDMA layer according to the combined service priority list (see Table Combination of service priority information in Section Combined service priority list).The RNC investigates which RRC connections are not in the preferred RAT or hier-archical WCDMA layer, checks if the selected target is available, and selects those as candidates for the service-based handover procedure. Only those RRC connections which are in category 1 of this list can be included in the service-based handover procedure.

6. RRC connections which do not require the compressed mode to perform inter-fre-quency or inter-RAT measurements (the relevant measurement type depends on the type of the service-based handover).

7. Finally, the RNC selects the predefined number of RRC connections in free order from the group of RRC connections that have been selected as described in steps 1-6.

If no RRC connection can be selected, service-based handovers are not performed and the next connection is selected after the timer expires.

18.2.3 Defining the target for the service-based handoverThe preferred RAT or preferred hierarchical WCDMA layer of each RRC connection in the service-based handover is determined according to combined service priority infor-mation (see Table 18 Combination of service priority information Section Combined service priority list).

If the UE is not in the preferred RAT or hierarchical WCDMA layer and the preferred RAT or hierarchical WCDMA layer is available, the UE is selected into the set of possible can-didates for the service-based handover procedure. Only those RRC connections that are in category 1 of the above list are included in the service-based handover procedure.

18.3 Service priority

18.3.1 Iu interface service priorityIu interface service priority information defines the target system for service- and load-based handovers.

The Service Handover IE received from the Iu interface through RANAP signaling provides the following alternatives:

1. Handover to GSM should be performed.2. Handover to GSM should not be performed.3. Handover to GSM shall not be performed.

The Iu interface service priority information is used to produce a combined service priority list.

186 DN03471612




g The Iu interface service priority information is RAB-based and optional. An RNC-based service priority handover profile table is used to complement it if needed, or instead of it, if it is not available.

18.3.2 RNC-based service priority handover profile tableFor each of the eight service types the UE uses, the following alternatives can be defined by using RNC configuration parameters:

• GSM • WCDMA • WCDMA macro cell • WCDMA micro cell • Not defined (WCDMA or GSM)

Different WCDMA layers are handled according to the following rules:

• WCDMA macro cell means HCS priorities from 0 to 3. • WCDMA micro cell means HCS priorities from 4 to 7. • HCS priority 0 is the highest priority for a service type that prefers macro cells. • HCS priority 7 is the highest priority for a service type that prefers micro cells. • WCDMA macro cell or WCDMA micro cell definition defines the direction in the hier-

archical WCDMA layer structure which the service type used by the UE prefers. • The main principle is that an attempt is made to hand over a certain service type to

the cell/layer which has the highest available priority for it.

The HCS priority of the serving cell is determined by the HCS_PRIO (WCEL) RNP parameter, and the HCS priority of an inter-frequency neighbor cell is determined by the AdjiHCSpriority (HOPI) parameter.

g Iu interface service priority information has a higher priority than the RNC-based table below. If RAB-based Iu interface service priority information is not available, only the information in this table is used. In addition, this table defines the preferred layer inside the WCDMA system, and that information is used to complement the Iu interface service priority information.

Service type used by the UE Preferred RAT or WCDMA layer

Conversational, Circuit-switched speech GSMConversational

Circuit-switched transparent data GSMConversational

Packet-switched speech WCDMA Conversational

Packet-switched real-time data WCDMA Streaming

Circuit-switched non-transparent data WCDMA macro layer Streaming

Packet-switched real-time data WCDMA macro layer Interactive

Packet-switched non-real time data WCDMA micro layer Background

Packet-switched non-real time data Not defined

Table 17 RNC-based service priority handover profile table

DN03471612 187



18.3.3 Combined service priority listThe RNC produces a combined service priority list based on the Iu interface service priority information and the RNC-based service priority handover profile table.

If the UE is not in the preferred RAT or hierarchical WCDMA layer, and the preferred RAT or hierarchical WCDMA layer is available, the UE is selected into the set of possible candidates for the service-based handover procedure.

If the UE is not in preferred RAT or hierarchical WCDMA layer and preferred RAT or hier-archical WCDMA layer is available or if the UE is in preferred hierarchical WCDMA layer but at least one other equal preferred hierarchical WCDMA layer is available, the UE is selected into the set of possible candidates for the load-based handover procedure.

The serving WCDMA layer is 'WCDMA micro' or 'WCDMA macro' if all set active cells are such. Otherwise, the serving layer is 'WCDMA'.

Table 18 Combination of service priority information below defines the combined service priority list which is used in service and load-based handovers. The Service Handover IE and the service priority handover profile table are not used alone but rather as combined service priority information. The combined service priority list defines the pre-ferred target RAT or hierarchical WCDMA layer for each phase according to the service that the UE uses.

The following abbreviations are used in Table Combination of service priority informa-tion:

1. Indicates the target for RAB in both service-based and load-based handover procedures in the first phase.

2. Indicates the target for RAB in a load-based handover procedure if there are not enough UEs in the cell in the first phase (second phase).

3. Indicates the target for RAB in a load-based handover procedure if there are not enough UEs in the cell in the first and second phases (third phase).

WCDMA WCDMA alone means that the preferred WCDMA layer is not defined and, because of load reasons, the RRC connection can be handed over to any WCDMA layer.

Because of load reasons, an attempt is made to hand over one RRC connection only to one target (GSM, WCDMA, WCDMA micro, or WCDMA macro).

Definitions in the following table cannot be controlled with RNP parameters.

188 DN03471612




Iu interface service priority information

RNC-based service priority information

Combined service priority list

Handover to GSM should be per-formed

GSM 1. GSM

2. GSM

3. WCDMA

WCDMA 1. GSM

2. GSM

3. WCDMA

WCDMA macro 1. GSM

2. WCDMA macro layer

3. WCDMA

WCDMA micro 1. GSM

2. WCDMA micro layer

3. WCDMA

Not defined 1. GSM

2. GSM

3. WCDMA

Handover to GSM should not be performed

GSM 2. WCDMA

3. GSM

WCDMA 2. WCDMA

3. GSM

WCDMA macro 1. WCDMA macro layer

2. WCDMA

3. GSM

WCDMA micro 1. WCDMA micro layer

2. WCDMA

3. GSM

Not defined 2. WCDMA

3. GSM

Table 18 Combination of service priority information

DN03471612 189



18.3.4 Multi services in case of service-based and load-based handoversService-based or load-based handovers are not performed for those multi service con-nections where combined service priority lists between RABs have contradictions. Table 18 Combination of service priority information in Section Combined service priority list defines RAB-based combined service priority lists.

A contradiction exists if all RABs of the multi service connection do not have the same preferred RAT or hierarchical WCDMA layer. A pure WCDMA definition means that both WCDMA micro and WCDMA macro layers are suitable. A contradiction exists also if the preferred RAT and hierarchical WCDMA layer inside the WCDMA system are not defined for a certain service in a certain phase (see Table 18 Combination of service priority information). This can happen only in the first phase.

In the first phase, it is easy to check if a contradiction exists. In the second and third phases, it is possible that the preferred RAT and hierarchical WCDMA layers of RABs are in a different priority order. In these cases, the WCDMA system is selected assuming

Handover to GSM shall not be per-formed

GSM 2. WCDMA

3. WCDMA

WCDMA 2. WCDMA

3. WCDMA


2. WCDMA

3. WCDMA


2. WCDMA

3. WCDMA


3. WCDMA

Iu interface service priority infor-mation not available

GSM 1. GSM

2. GSM

3. WCDMA

WCDMA 2. WCDMA

3. GSM


2. WCDMA

3. GSM


2. WCDMA

3. GSM


3. GSM

Iu interface service priority information

RNC-based service priority information

Combined service priority list

Table 18 Combination of service priority information (Cont.)

190 DN03471612




that WCDMA is defined as the preferred target for all RABs in that phase or earlier phase(s).

Example: In the third phase:

RAB1 has definitions 1. GSM, 2. GSM, 3. WCDMA, and

RAB2 has definitions 2. WCDMA, 3. GSM,

which means that the WCDMA system is selected if it is available.

Note that this same RRC connection cannot be selected in the first or second phase because a contradiction exists in those phases.

Example: In the third phase:

RAB1 has definitions 1. GSM, 2. GSM, 3. WCDMA, and

RAB2 has definitions 1. WCDMA micro layer, 2. WCDMA, 3. GSM,

which means that WCDMA micro layer is selected if it is available.

Note that this same RRC connection cannot be selected in the first or second phase because a contradiction exists in those phases.

NRT RAB can be a part of the multi service.

A pure PS multi service RRC connection is allowed to hand over to the GSM/GPRS system because of a service-based or load-based handover reason. However, a CS/PS multi service RRC connection is not handed over to the GSM/GPRS system because of a service-based or load-based handover reason.

18.3.5 Availability of the target WCDMA layers and GSM systemThe RNC investigates the availability of the target WCDMA layers and GSM system in the neighbor cell list of the UE, which is selected in the service and load-based handover procedure. Note that the neighbor cell list consists of a combination of all neighbor cells of active set cells.

The RNC checks if the inter-frequency neighbor cell list has any definitions. If one or more of the other layer cells in the neighbor cell list are marked as blocked cells in the SLHO procedure, the AdjiHandlingBlockedCellSLHO (ADJI) RNP parameter defines whether that layer is used as a target layer or not. If any suitable target WCDMA layer is found, the WCDMA system is available for the service-based and load-based inter-frequency procedure.

A WCDMA inter-frequency layer can be considered as a 'micro' layer if all the cells according to the neighbor cell list defined in the layer are defined as 'micro' cells. Simi-larly, a WCDMA inter-frequency layer can be considered as a 'macro' layer if all the cells according to the neighbor cell list defined in the layer are defined as 'macro' cells. If so, a WCDMA 'micro' or 'macro' layer is available for the service/based and load-based inter-frequency procedure.

The RNC checks if the GSM inter-system neighbor cell list has any definitions which the penalty time (AdjgPenaltyTimeNCHO) is not running. If it does, the GSM system is available for the service and load-based inter-RAT procedure.

If a selected WCDMA target layer or GSM system is not available for a specific UE, the service-based or load-based handover procedure of that UE is stopped.

DN03471612 191



18.4 Load of the target cells

18.4.1 Common load measurement over IurThe SRNC initiates common load measurements over Iur to certain DRNC's cells for the service and load-based handover. The reason for the measurement is to prevent service and load-based handover attempts to cells that are already loaded.

Before common load measurement over Iur can be initiated, the Load and Service Based IS/IF Handover feature has to be enabled.

The AdjiComLoadMeasDRNCCellNCHO (ADJI) RNP parameter controls the common load measurement of an inter-frequency neighbor cell that is controlled by the DRNC. The measurement is controlled over Iur by using RNSAP signaling. If the common load measurement is activated, the RNC configuration parameters and rules listed below define the measurement.

The used measurement is event-based. The report characteristics used are 'Event A' (load is over threshold) and 'Event B' (load is below threshold).

The following RNC configuration parameters (RNC) define common load measurement over Iur for the service and load-based handover to indicate a high load in the target cell:

• Measurement threshold is common for both events. It is defined with the NCHOThrComLoadMeasDRNCCell (RNC) RNC configuration parameter. The range of the parameter is from 0 to 100.

• Measurement hysteresis is common for both events. It is defined with the NCHOHystComLoadMeasDRNCCell (RNC) RNC configuration parameter.

• Measurement filter coefficient is defined with the NCHOFiltercoeffComLoadMeasDRNCCell (RNC) RNC configuration parame-ter.

If 'Event A' is detected, the service and load-based handover attempts are not performed to this cell, that is, the cell is blocked from the SLHO procedure. 'Event B' cancels 'Event A'.

Whether or not the cell controlled by the DRNC, whose common load measurement is not activated or whose activation has not been successful, is blocked in the service and load-based handover procedure, is defined with the SLHOHandlingOfCellLoadMeasNotAct RNC configuration parameter. Whether or not the loaded/blocked neighbor cell blocks the whole frequency layer from the set of possible service and load-based handover targets is defined with the AdjiHandlingBlockedCellSLHO (ADJI) RNP parameter.

18.4.2 Load of the target WCDMA cellThe RNC checks the load of the target WCDMA cell before a service-based or load-based inter-frequency handover. That is done in one of two ways:either by checking the load-based handover state status information, which is received from the target cell as a broadcast sent inside the RNC, or by checking the status of the event-triggered common load measurement (if available) of the neighbor cells controlled by the DRNC.

The RNC also checks whether the SLHO penalty time of that cell is running or not. The AdjiPenaltyTimeNCHO RNP parameter defines the penalty time.

The SLHOHandlingOfCellLoadMeasNotAct RNC configuration parameter defines whether or not the cell (controlled by the SRNC or DRNC) that does not have active load

192 DN03471612




measurement is interpreted as a blocked cell in the SLHO procedure. Service- and load-based handovers are not performed to the cell that is blocked in the SLHO procedure.

Whether or not the cell that is blocked in the SLHO procedure blocks the whole fre-quency layer from the set of possible service and load-based handover targets is defined with the AdjiHandlingBlockedCellSLHO (ADJI) RNP parameter.

The load on the target WCDMA cells is checked when the availability of the target WCDMA layer is investigated, the neighbor cell list is built up, and it is checked whether the cells blocked in the service and load-based handover procedure are outside the soft handover range of the selected best-target cell or not.

Note that the load-based handover state information of the cells controlled by the drifting RNCs is not available.

18.4.3 Load of the target GSM/GPRS cellThe exact load of the target GSM/GPRS cell is not checked by the source RNC in case of a service or load -based inter-RAT handover. The target BSC checks its own load sit-uation and rejects the handover if necessary.

The source RNC checks whether the SLHO penalty time (AdjgPenaltyTimeNCHO) of that cell is running or not. That is done when the availability of the target system is checked and the neighbor cell list is built up.

18.4.4 Congested target WCDMA or GSM cellIf a handover of any type (quality, coverage, and so on) to the GSM system is started and the target GSM cell is selected based on measurements, but the relocation to the GSM system is unsuccessful and the 'RANAP: Relocation Preparation Failure' IE is received from the core network, service and load-based handovers and network-con-trolled cell reselections to this target cell are not performed during a certain period. The period is defined with the AdjgPenaltyTimeNCHO (HOPG) RNP parameter. When the timer expires, service- and load-based handovers and network-controlled cell reselec-tions to the target cell are possible again. This penalty time is not set if an unsuccessful network-controlled cell reselection happens or if resources from the target cell are reserved successfully but after that the radio phase fails.

The RNC sets a similar penalty time to WCDMA inter-frequency cells. The penalty is set if a handover of any type (quality, coverage, and so on) fails to reserve resources from the target cell. This penalty time is not set if an unsuccessful network-controlled cell reselection happens or if resources from the target cell are reserved successfully but after that the radio phase fails. The penalty time is defined with the AdjiPenaltyTimeNCHO (HOPI) RNP parameter.

18.5 Interaction with HSPA capability based handoverAn ideal candidate for an HSPA capability based handover is an HSDPA or HSDPA and HSUPA capable UE with a suitable RAB combination that is located in a non-HSPA source cell.

HSPA capability based handover is performed instead of load based or service based handover for such UEs if all of the following conditions are true:

• HSPA capability based handover is enabled for the corresponding cell.

DN03471612 193



• The UE has a suitable RAB combination with DCH >0/0 kbps allocated. The capa-bility of the RAB combination is indicated by the value of the HSCAHORabCombSupport parameter.

• At least for one of the inter-frequency neighbor cells of this cell the value of the AdjiNCHOHSPASupport parameter set to value “1”.

If HSPA capability based handover is not enabled in any of the neighbor cells, load based or service based handover is performed for the HSPA capable UE.

18.6 Inter-frequency and inter-RAT measurement proceduresService- and load-based inter-frequency and inter-RAT handover measurements are similar to the ones used in coverage and quality-based handovers. For more informa-tion, see Sections Functionality of inter-frequency handover and Functionality of inter-system handover.

18.6.1 Selecting the service and load-based inter-frequency handover methodService and load-based inter-frequency handovers are performed only for RRC connec-tions that are in the CELL_DCH state.

In case of an RT connection or RT/NRT multi service connection, normal inter-frequency measurements are performed.

In case of a NRT connection, normal inter-frequency measurements are performed by using the compressed mode or dual-receiver function, or a handover procedure is not performed at all. Whether the inter-frequency measurements of the NRT connection using the compressed mode are allowed to be performed or not, is controlled with the RNP parameter SLHOCmAllowedNRT (RNC) RNP parameter. UE capability defines whether inter-frequency measurements using the dual-receiver function are possible or not.

In the inter-frequency handover (CS domain service, CS/PS domain service, or PS domain service in the CELL_DCH state), resources from the target cell are always reserved before the handover command is sent to the UE. An inter-frequency handover is performed in the CELL_DCH state based on the measurements.

18.6.2 Selecting the service and load-based inter-RAT handover methodService-based and load-based inter-system handovers and network-controlled cell reselections are performed only for RRC connections that are in the CELL_DCH state.

In case of a RT connection or a RT/NRT multi service connection, normal inter-RAT measurements are performed.

In case of a NRT connection, normal inter-RAT measurements are performed by using the compressed mode or dual-receiver function, or a network-controlled cell reselection procedure is not performed at all. Whether the inter-RAT measurements of the NRT con-nection using the compressed mode are allowed to be performed or not, is controlled with the SLHOCmAllowedNRT (RNC)RNP parameter. UE capability defines whether the inter-RAT measurements using the dual-receiver function are possible or not.

194 DN03471612




In the inter-RAT handover (CS or CS/PS domain service), resources from the target cell are always reserved before the handover command to the UE is sent. Inter-RAT handover is performed in the CELL_DCH state based on the measurements.

g In the inter-RAT network-controlled cell reselection (PS domain service), resources from the target are not reserved beforehand. The inter-RAT network-controlled cell reselec-tion is performed in the CELL_DCH state based on the measurements.

18.6.3 Measurement parametersThe measurement parameters of the service- and load-based handover are similar to the ones used in coverage- and quality-based handovers. (See also Sections Measure-ment procedure for inter-frequency handover and Measurement procedure for inter-system handover.) However, the following is an exception.

The InterFreqMinHoInterval and GsmMinHoInterval RNP parameters are used also in case of service- and load-based handovers. However, if the previous handover reason is known to be service- or load-based handover, the InterFreqMinSLHOInterval (FMCI) and GsmMinSLHOInterval (FMCG) RNP parameters are used. This allows a timer to be set longer and prevents repetitive han-dovers between cells during one RRC connection.

InterFreqMinSLHOInterval defines the minimum interval between a successful service- or load-based inter-frequency handover and the following service- or load-based inter-frequency handover attempt during the same RRC connection. Repetitive service- and load-based inter-frequency handovers are disabled when the value of the parameter is zero.

GsmMinSLHOInterval defines the minimum interval between a successful service- or load-based inter-RAT handover from GSM to UTRAN and the following service-based or load-based inter-RAT handover attempt back to GSM during the same RRC connec-tion. The return of the service- or load-based handover back to GSM is disabled when the value of the parameter is zero.

g If the RAB-based 'RANAP: Service Handover' IE is reconfigured after a relocation by the core network, the timer related to the RNP parameter GsmMinSLHOInterval is reset (if it is running).

18.6.4 Inter-frequency and inter-RAT neighbor cell listsWhen the target of the service- or load-based handover is GSM/GPRS, the used inter-RAT neighbor cell list is the same as in a coverage- or quality-reason handover, but cells that are blocked in the SLHO procedure are reduced.

When the target of the service- or load-based handover is WCDMA macro cell, those layer(s) are selected from the normal inter-frequency neighbor cell list which are not blocked in the SLHO procedure and where all the cells have the definition 'HCS = 0 … 3'. The cells of the found layer(s) form the neighbor cell list used in measurements.

When the target of the service- or load-based handover is WCDMA micro cell, those layer(s) are selected from the normal inter-frequency neighbor cell list which are not blocked in the SLHO procedure and where all cells have the definition 'HCS = 4 … 7'. The cells of the found layer(s) form the neighbor cell list used in measurements.

DN03471612 195



When the target of the service- and load-based handover is WCDMA, the inter-fre-quency neighbor cell list is the same as in a handover because of coverage or quality reasons, but the frequency layers that are blocked in the SLHO procedure are reduced.

If there is more than one frequency to be measured, the RNC selects a subset of inter-frequency neighbor cells (with the same UTRA RF channel number) which are measured first. The measurement order is controlled with the AdjiPrioritySLHO (HOPI) RNP parameter which is defined for each inter-frequency neighbor cell. If the RNC cannot define the measurement order by using the parameters, it measures the least-loaded frequencies first. The load is evaluated in each frequency by calculating the quotient of the number of neighbor cells blocked in the SLHO procedure and all the neighbor cells. The frequency with the smallest result is the least loaded one. If this is not possible to solve, the RNC measures frequencies in random order.

18.6.5 Number of UEs in compressed modeFor more information on the number of UEs that can be simultaneously in compressed mode in one cell because of service or load-based handover procedures see Com-pressed mode.

g The measurement capability IE of certain UEs can indicate that the CM is not needed, that is, the UEs have dual-receiver capability.

18.7 Handover decision procedure

18.7.1 Load- and service-based inter-frequency handoverThe measurement results of the best neighbor cell must satisfy the following equations before the service- and load-based inter-frequency handover is possible:

AVE_RSCP_NCELL(n) > AdjiMinRscpNCHO(n) + max(0, AdjiTxPwrDPCH(n) – P_max)

AVE_EcNo_NCELL(n) > AdjiMinEcNoNCHO(n)

where AVE_RSCP_NCELL(n) and AVE_EcNo_NCELL(n) are the averaged CPICH RSCP and EcNo values of the best (according to CPICH EcNo) neighbor cell (n). The RNC calculates the average values directly from the measured dB and dBm values, so linear averaging is not used in this case. The sliding averaging window is controlled with the InterFreqMeasAveragingWindow RNP parameter. The RNC starts the averag-ing already from the first measurement sample, that is, the RNC calculates the averaged values from those measurement samples which are available until the number of mea-surement samples is adequate to calculate the averaged values over the whole averag-ing window.

The AdjiMinRscpNCHO(n) (HOPI) RNP parameter determines the minimum required CPICH RSCP value in dBm of the best neighbor cell. The AdjiMinEcNoNCHO(n) (HOPI) RNP parameter determines the minimum required CPICH EcNo value in dB of the best neighbor cell. The AdjiTxPwrDPCH(n) neighbor cell parameter indicates the maximum Tx power in dBm an UE can use on the DPCH. P_max indicates the maximum RF output power capability of the UE in dBm in WCDMA.

The InterFreqCellSearchPeriod RNP parameter determines the period starting from inter-frequency measurement setup during which an inter-frequency handover is not possible. After the time period has expired, the RNC evaluates the radio link prop-

196 DN03471612




erties of the current best neighbor cell after every inter-frequency measurement report. The RNC performs the inter-frequency handover to a best neighbor (target) cell as soon as the best neighbor cell meets the required radio link properties (see the equations at the beginning of this section). However, the handover decision cannot be performed before the UE has reported the EcNo result of all the cells which are blocked in the service- and load-based handover procedure.

The RNC checks if the cells which are blocked in the service- and load-based handover procedure are outside the soft handover range of the selected best target cell. The fol-lowing equation has to be true until a service- and load-based handover to the best neighbor cell is possible:

AveEcNoNcell(target) – AdjiEcNoOffsetNCHO(target) > AveEcNoNcell(blocked)

AveEcNoNcell(target) and AveEcNoNcell(blocked) are the averaged EcNo values of the selected best target cell and a blocked cell correspondingly. The AdjiEcNoOffsetNCHO(target) (ADJI) RNP parameter defines the offset for the procedure to ensure that the UE does not perform an immediate soft handover to a blocked cell in the new frequency layer.

18.7.2 Load- and service-based inter-RAT handoverThe measurement results of the GSM neighbor cell must satisfy the following equation before the service- and load-based inter-RAT handover or cell change from WCDMA to GSM/GPRS is possible:

AVE_RXLEV_Ncell(n) > AdjgMinRxLevNCHO(n) + max(0, AdjgTxPwrMaxTCH(n) – P_Max)

where AVE_RXLEV_Ncell(n) is the averaged GSM carrier RSSI value of the GSM neighbor cell (n). The RNC calculates the averaged values directly from the measured dBm values, so linear averaging is not used in this case. The sliding averaging window is controlled with the GSMMeasAveWindow parameter. The RNC starts the averaging already from the first measurement sample, that is, the RNC calculates the averaged values from those measurement samples which are available until the number of mea-surement samples is adequate to calculate values over the whole averaging window.

The AdjgMinRxLevNCHO(n) (HOPG) parameter determines the minimum required GSM carrier RSSI level in dBm which the averaged RSSI value of the neighbor cell (n) must exceed before the service- and load-based inter-system handover is possible. The AdjgTxPwrMaxTCH(n) neighbor cell parameter indicates the maximum Tx power level in dBm an UE can use in the GSM neighbor cell (n). P_Max indicates the maximum RF output power capability in dBm of the UE in GSM.

The GsmNcellSearchPeriod RNP parameter determines the period starting from inter-RAT measurement setup during which an inter-RAT handover to GSM is not pos-sible. After the GSM neighbor cell search period has expired, the RNC evaluates the radio link properties of the best neighbor GSM cells after every inter-RAT measurement report. The RNC performs the inter-RAT handover to the best GSM neighbor (target) cell as soon as the best GSM neighbor cell meets the required radio link properties (see the equation at the beginning of this section).

If there are several neighbor GSM cells which meet the required radio link properties at the same time, the RNC ranks the potential target cells according to the priority levels and select the highest-ranked GSM neighbor cell to be the target cell. The priority order is controlled with the AdjgPrioritySLHO (HOPG) RNP parameter which is defined for

DN03471612 197



each GSM neighbor cell. The crucial principle is that high-priority cells are considered better than low-priority cells, that is, a cell is ranked higher than another cell if it has a higher priority level even though its signal strength condition was worse. Signal strength conditions have effect only between cells which have the same priority level.

In the case of CS data and voice services, the RNC always verifies the BSIC of the target cell before the execution of the inter-RAT handover to GSM so that the mobile station can synchronize to the GSM cell before the handover execution, and to verify the iden-tification if two or more neighbor GSM cells have the same BCCH Frequency. In the case of PS data (RT or NRT) services, the RNC does not verify the BSIC of the target cell before the execution of the inter-RAT cell change to GSM/GPRS unless two or more neighbor GSM cells have the same BCCH Frequency.

18.8 Handover signaling

18.8.1 Load- and service-based inter-frequency handoverThe signaling procedure of an inter-frequency handover is described in Section Inter-fre-quency handover signaling.

When the relocation takes place, the source RNC sets the following RANAP cause values to the RANAP: Relocation Required message:

• Resource Optimisation Relocation if the reason for the handover is service-based • Relocation desirable for radio reasons if the reason for the handover is load-based

18.8.2 Load- and service-based inter-RAT handover and cell changeThe signaling procedure of an inter-RAT (GSM) handover is described in Section Inter-system handover signaling.

When the relocation takes place, the source RNC sets the following RANAP cause values to the RANAP: Relocation Required message:

• Resource Optimisation Relocation if the reason for the handover reason is service-based

• Relocation desirable for radio reasons if the reason for the handover is load-based

18.8.3 Service downgrading and upgrading because of inter-RAT handoverNon-transparent CS data connections can be downgraded in an inter-RAT handover from WCDMA to GSM and also upgraded back in an inter-RAT handover from GSM to WCDMA. These negotiations are done by the core network, RAN and BSS via the Iu and A interfaces based on QoS parameters. Same procedures are used than in qual-ity/service-based inter-system handovers.

g Transparent CS data connections cannot be downgraded.

18.8.4 Restriction on repetitive load- and service-based handover attemptsRepetitive load-based or service-based handover (or network-controlled cell reselec-tion) attempts of a RRC connection are restricted. If the load-based or service-based

198 DN03471612




HO/NCCR attempt is unsuccessful, the next load- or service-based HO/NCCR attempt is possible after a certain period. The period is hard-coded and defined to be 30 (after the first attempt), 60 (after the second attempt), 120, 120, 120, …seconds.

DN03471612 199

WCDMA RAN RRM Handover Control Functionality of HSPA capability based handover


19 Functionality of HSPA capability based handoverThe HSPA Capability Based Handover feature provides a mechanism to periodically hand over HSPA-capable UEs using DCH services from all WCDMA cells to neighbor cells providing HSPA support. The target cell can be a WCDMA cell served by an RNC or an I-HSPA cell served by the I-HSPA system. HSPA-capable UEs in HSDPA/HSPA WCDMA cells using HS(D)PA services are handed over to WCDMA interfrequency neighbour cells providing HSPA support or I-HSPA cells by an event triggered mecha-nism.

HSPA capability based handover is initiated as follows:

• periodically in all WCDMA cells, • event triggered in HSDPA/HSPA capable source cells.

g Activation of the HSPA capability handover changes when MIMO capabilty based handover and Dual Cell HSDPA capability handover are introduced. If the HSPA capa-bility handover was enabled in the cell with earlier software release, operator must activate the feature by using HSPACapaHO parameter.

HSPA capability based handover is enabled/disabled with the HSPACapaHO parame-ter. The parameter can have four values:

• “0” - HSPA capability based handover is disabled in the cell • “1” - Periodical triggering is enabled and event based triggering is disabled in the cell • “2” - Periodical triggering is disabled and event based triggering is enabled in the cell • “3” - Periodical triggering and event based triggering are enabled in the cell.

The following steps are needed to enable periodic and event based HSDPA capability handover types:

• Periodic HSPA capability based handover:1. The HSPACapaHO paramater is set to value “1” or “3”.2. The AdjiNCHOHSPASupport parameter is set to value “1” for at least one of

the neighboring inter-frequency cells of the source cell(s).3. The HSCapabilityHOPeriod and HSCapabilityHONumbUE parameters

are set to a value other than “0”. The value of the HSCapabilityHOPeriod parameter is always checked before the periodic HSPA capability based handover is triggered.

• Event triggered HSPA capability based handover:1. The HSPACapaHO paramater is set to value “2” or “3”.2. The AdjiNCHOHSPASupport parameter must be set to “1” for at least one of the

neighboring inter-frequency cells of the source cell(s).

The following parameter settings are used to disable HSPA capability based handovers:

• Periodic HSPA capability based handover: • The HSPACapaHO parameter must be set to value “0” • The HSCapabilityHOPeriod parameter must be set to value: “0” or “Dis-

abled”.

200 DN03471612



Functionality of HSPA capability based handover

• The HSCapabilityHONumbUE and/or AdjiNCHOHSPASupport parameters are set to value: “0”.If the HSCapabilityHONumbUE parameter has the value “0”, no UE can be selected for an individual handover period. If the AdjiNCHOHSPASupport parameter value is set to “0” for all adjacent inter-frequency neighbor cells, there is no inter-frequency neighbor cell that supports HSPA capability based han-dover.

• Event triggered HSPA capability based handover: • The HSPACapaHO parameter must be set to value “0” or “1” • HSPA capability based handover is not performed if the

AdjiNCHOHSPASupport parameter is set to value “0”, because there is no inter-frequency neighbor cell that supports HSPA capability based handover to the corresponding cell.

The Source RNC does not check the load of the target cell before the HSPA capability based handover procedure. The target I-HSPA adaptor or the RNC checks its own load situation and rejects the handover if necessary.

When the availability of the target system is checked and the neighbor cell list is build up, the Source RNC checks whether the penalty time Penalty Time for WCDMA Cell in NCHO (AdjiPenaltyTimeNCHO) is running in the cell. For more information see Section Inter-Frequency neighbor cell lists.

The operator can decide on the RAB combinations that are supported for the HSPA capability based handover by setting the RAB Combinations Supported by HSCAHO (HSCAHORabCombSupport) RNC parameter appropriately.

Note that it is possible to enable HSPA capability based handover for plain CS voice (AMR service) with the HSCAHORabCombSupport RNP parameter.

19.1 Periodic HSPA capability based handover HSPA capability based handover can be started for all WCDMA cells irrespective of their HSDPA capability, to hand over those UEs that currently use DCH services to neighbor cells providing HSPA support. The target cell can be a WCDMA cell served by an RNC or an I-HSPA cell served by the I-HSPA system.

The HSPA Capability Based Handover Period (HSCapabilityHOPeriod) parameter defines the duration of the period:

• A time period other than '0' is specified for those WCDMA cells which have at least one HSDPA/HSPA neighbor cell with the ADJI HSPA Cell for Non Critical Handover (AdjiNCHOHSPASupport) parameter set to value “1”.

• Otherwise, the time period is set to '0' to disable periodic HSPA capability based handover.

Each time a HSPA capability based handover is started in the cell, a pre-defined number of UEs can be handed over. The number of UEs is specified by the HSPA Capability Based Handover Max Number of UE (HSCapabilityHONumbUE) parameter.

If compressed mode is needed, the maximum number of UEs in compressed mode is limited by the MaxNumberUEcmSLHO parameter. Dual receiver UEs do not require com-pressed mode or require it only in UL direction.

Candidate UEs for the periodic HSPA capability based handover are selected according to the following conditions:

DN03471612 201



• The SRNC for the RRC connection is the RNC where the HSPA capability based handover has been triggered.

• The RRC connection is in CELL_DCH state. • The UE is either HSDPA capable or HSDPA/HSPA capable. • The traffic class of the RAB is within the range specified by the RAB Combinations

Supported by HSCAHO (HSCAHORabCombSupport) parameter. • A DCH with a bit rate other than 0/0 kbps is allocated for the corresponding PS NRT

RAB. • Inter-frequency or inter-system measurements are not performed for the RRC con-

nection. • The penalty time for retry is not running for the RRC connection.

RRC connections selected according to these criteria are prioritized in the following order:

1. RRC connections which do not require compressed mode in this particular handover2. RRC connections where the selected target can be measured without compressed

mode3. RRC connections selected freely from the set of candidate RRC connections

If the HSPA capability based handover cannot be performed, the UE is re-selected in the next time period. Repetitive HSPA capability based handover attempts of an individ-ual RRC connection are restricted. The next attempt is possible after a hard coded period and defined to be 30 (after 1st attempt), 60 (after 2nd attempt), 120, 120, 120, … seconds.

19.2 Event triggered HSPA capability based handoverIf HSPA capability based handover is enabled in the serving cell and a UE uses HSDPA/HSPA services, HS-DSCH inactivity is awaited before the RNC triggers HSPA capability based handover to an I-HSPA cell or an interfrequency WCDMA HSDPA/HSPA cell.

HS-DSCH inactivity is detected based on the downlink throughput and the number of PDUs in the RLC transmission windows. Upon detection of low utilisation/throughput of the DL HS-DSCH MAC-d flow and if the corresponding the UL NRT DCH/E-DCH release is possible then event triggered HSPA Capability Based Handover is triggered instead of releasing the HS-DSCH and/or UL DCH/E-DCH channels when event trig-gered HSPA Capability Based Handover is enabled in the corresponding cell.

The first step of the HSPA capability based handover procedure depends on the HSDPA/HSPA services:

• For UEs using HSDPA services, compressed mode is started to measure the inter-frequency neighbors.

• For UEs using HSPA services, the channel type is switched from HS-DSCH/E-DCH to HS-DSCH/DCH.

If HSDPA inter-frequency handover is disabled, the channel type is switched from HS-DSCH/DCH or HS-DSCH/E-DCH to DCH/DCH and compressed mode is started on DCH. For the new DCH channel, the initial bit rate is allocated during the channel type switching.

If HSPA capability based handover is not enabled in the source cell, the HS-DSCH and the corresponding UL DCH/E-DCH for the UE are released.

202 DN03471612




The target cell for an event triggered HSPA capability based handover can be an I-HSPA cell or WCDMA interfrequency HSDPA/HSPA capable neighbour cell. The handover can be only performed if a suitable I-HSPA or RNC neighbor cell is found. Oth-erwise, the handover for the corresponding UE is stopped

If a hard handover failure occurs during the event triggered HSPA capability based han-dover, the UE is retained in CELL_DCH state and will be a candidate for a periodic HSPA capability based handover attempt.

19.3 Inter-Frequency measurement proceduresThe inter-frequency measurement procedure is controlled with the following RNP parameters:

• Measurement Reporting Interval (InterFreqMeasRepInterval) • neighbor Cell Search Period (InterFreqNcellSearchPeriod) • Maximum Measurement Period (InterFreqMaxMeasPeriod) • Minimum Measurement Interval (InterFreqMinMeasInterval) • Minimum Interval Between IFHOs (InterFreqMinHoInterval)

These parameters control the HSPA capability based handover similar to the service and load based inter-frequency measurement procedures.

19.4 Inter-Frequency neighbor cell listsThe RNC investigates the availability of target WCDMA layers or a target I-HSPA system from the neighbor cell list which is selected in the HSPA capability based handover procedure.

The RNC sets a penalty time to the neighbor inter-frequency cells if a handover of any type (quality, coverage, …) fails in reserving resources from the target cell. The penalty time is specified by the Penalty Time for WCDMA Cell in NCHO (AdjiPenaltyTimeNCHO) parameter. The penalty time is not set if resources from the target cell are successfully reserved but the handover procedure fails during the radio phase.

The RNC identifies entries in the inter-frequency neighbor cell list for which the penalty time is not running. For such entries, the target I-HSPA system or the target WCDMA layer is available.

If a UE specific penalty time is running, the selected target system is not available and the HSPA capability based handover procedure of that UE is stopped.

When the neighbor cell list is created for HSPA capability based handovers, the HSPA support is taken into account if handover control removes surplus neighbor cells exceeding the maximum number of 32. At first, cells are selected within each step that have the ADJI HSPA Cell for Non Critical Handover (AdjiNCHOHSPASupport) param-eter set to '0' and these cells are removed in random order. If the maximum number of 32 is still exceeded, HSPA surplus cells are selected during the step and removed in random order. For more information on neighbor cells see Section neighbor cells.

The inter-frequency measurement procedure measures one frequency at a time. If there is more than one carrier frequency to be measured, the RNC selects a subset of inter-frequency neighbor cells to be measured first. The measurement order is controlled by the neighbor Cell Priority for HSPA Capability Based Handover (AdjiPriorityHSCAHO) parameter.

DN03471612 203



19.5 Handover decision algorithm For HSPA capability based handover, the same handover decision algorithm is used as for service and load based inter-frequency handover.

The best cell in the active set must satisfy the following conditions:

• The ADJI parameter ADJI HSPA Cell for Non Critical Handover (AdjiNCHOHSPASupport) is set to value “1”.

• The HSPA capability based handover penalty time Penalty Time for WCDMA Cell in NCHO (AdjiPenaltyTimeNCHO) is not running.

• For event triggered HSPA capability based handover, the target cell must be an I-HSPA capable cell. The target cell is I-HSPA capable if the RNC id of this cell is not stored in the Iur list.

An I-HSPA adapter is always identified by the RNC id. During the handover, the network element type of the target node is identified by the Iur list. If the RNC id of the target node does not match with any of the RNC ids in the Iur list of the source RNC, the network element is an I-HSPA adapter. As there is no Iur connection between the RNC and the I-HSPA adapter and no neigbhouring information is stored in the Iur list, UE involved SRNS relocation is performed to the target I-HSPA adapter.

With I-HSPA Sharing feature, Iur connection is added between the RNC and the I-HSPA Adapter and the number of Iur Items has been extended to 300. Adapter ID of the neigh-boring ADA must be stored in the Iur list of the RNC.

Hence, if I-HSPA Sharing feature is enabled in SRNC, the target RNC type is considered to be an I-HSPA Adapter only if the RNC id of the Adapter is stored in the Iur List and the target network element type is I-HSPA ADA.

If the RNC-id of the target node does not match with any of the RNC-ids in the IUR List, then Handover Control shall try to check if RNC-id matches with the Adapter id in the VBTS - ControllerIdList of the VBTS parameters stored in RNW Configuration database. If it does, the target node is considered to be an I-HSPA Adapter.

When relocation must be done to the I-HSPA Adapter, it must be checked if the neigh-boring ADA supports this relocation. The parameter NrncRelocationSupport in the Iur item indicates if the neighboring RNC/ADA supports relocation or not.

Inter-frequency handover cannot be done over Iur to an I-HSPA Adapter because of HSPA Capability Based Handover if the target I-HSPA Adapter does not support relo-cation. Inter-frequency handover cannot be done over Iur either if the current RAB com-bination of the UE is not supported by the target I-HSPA Adapter as indicated by the RNC level parameter IBTSRabCombSupport since HSPA Over Iur is not supported in RU10.

Handover Control assumes that the target I-HSPA Adapter always supports relocation in case the RNC-id of the target adapter matches with the Adapter Id stored in ControllerIdList of the VBTS parameters.

Note that HSPA Capability Based Handover is not supported/triggered during anchor-ing.

19.6 Execution of HSPA capability based handover The target cell for an HSPA capability based handover can be either an I-HSPA cell or a WCDMA cell. The inter-frequency handover procedure depends on the target cell type.

204 DN03471612




19.6.1 Handover to an I-HSPA cellThe HSPA capability based handover is a combination of inter-frequency hard handover and SRNS relocation if there is Iur interface between the I-HSPA adaptor and SRNC. If there is no Iur interface between the RNC and target I-HSPA Adaptor, combined UE involved SRNS relocation and HHO are done before the UE is completely under the target I-HSPA Adaptor.

If I-HSPA Sharing feature is enabled, Iur interface is added between the RNC and the I-HSPA Adapter and the number of Iur Items has been extended to 300. Adapter ID of the neighboring ADA will be stored in the Iur list of the RNC.

Hence, inter-frequency HHO combined UE not involved SRNC relocation is performed if there exists Iur interface between the I-HSPA Adapater and SRNC.

It is assumed that the target I-HSPA adapter always supports SRNS relocation. When relocation takes place, the source RNC sets the RANAP cause values in the RANAP: RELOCATION REQUIRED message to 'Resource Optimisation Relocation'.

19.6.2 Handover to a WCDMA cellThe handover decision algorithm depends on the selected target cell:

• Inter-frequency hard handover is performed to intra-RNC target cells. • SRNS relocation is performed to inter-RNC target cells. The type of relocation is "UE

involved in relocation of SRNS".

19.7 Abnormal conditionsHSPA capability based handover to an I-HSPA cell or an inter-RNC cell is only possible if the following conditions are true:

• Relocation is supported by the target RNC (in the inter-RNC case). • The Iu-PS core network supports relocation.

If the target RNC or the Iu-PS core network does not support relocation, the HSPA capa-bility based handover is stopped for the UE and the PS call is retained in the WCDMA network.

Before the inter-frequency measurement for an inter-RNC handover is started, the Iur list is checked for the relocation type supported by the neighboring RNC. If relocation is not support, HSPA capability based handover is not continued for that UE.

If the UE is unable to perform the physical channel reconfiguration and responds with an RRC: PHYSICAL CHANNEL RECONFIGURATION FAILURE message, a penalty time for the retry is set.

When an event triggered HSPA capability based handover is unsuccessful and the UE is retained in CELL_DCH state, the penalty time for the retry is set as for periodic HSPA capability based handovers.

DN03471612 205

WCDMA RAN RRM Handover Control Functionality of Dual Cell HSDPA capability based han-dover


20 Functionality of Dual Cell HSDPA capability based handoverDual Cell HSDPA capability handover (DCCAHO) transfers Dual Cell HSDPA (DC HSDPA) capable UEs to Dual Cell HSDPA cells that can act as a primary serving HS-DSCH cell (DC HSDPA and HSUPA are enabled in the cell, with the DCellHSDPAEnabled and HSUPAEnabled parameters). Dual Cell HSDPA capability handover does not transfer a Dual Cell capable UE if it is already in the Dual Cell HSDPA cell that can act as a primary serving HS-DSCH cell.

Dual Cell HSDPA capability based handover is applied only if NRT RAB(s) are esta-bished for the Dual Cell HSDPA capable UE. Dual Cell HSDPA capability based handover is not applicable if RT or CS RAB is estabilished for the UE.

Dual Cell HSDPA capability handover is based on the existing Functionality of HSPA capability based, for more details see Section Functionality of HSPA capability based handover. Dual Cell HSDPA capability based handover uses both periodical and event triggering of the HSPA capability based handover . Dual Cell HSDPA capability based handover is based on the same license, and can be enabled simultaneously with HSPA capability based handover in the cell.

Dual Cell HSDPA capability based handover is controlled with the DCellHSDPACapaHO parameter. The parameter can have four values:

• “0” - Dual Cell HSDPA is disabled in the cell • “1” - periodical triggering is enabled (event triggering is disabled) in the cell • “2” - event triggering is enabled (periodical triggering is disabled) in the cell • “3” - periodical and event triggering are enabled in the cell

If Dual Cell HSDPA capability based handover is enabled simultaneously in the same cell with HSPA capability based handover, then the Dual Cell HSDPA capability based handover is preferred in case of the Dual Cell HSDPA capable UE. If the Dual Cell HSDPA capable UE is not suitable for Dual Cell HSDPA capability based handover pro-cedure, then HSPA capability based handover is capable of transferring also Dual Cell HSDPA capable UE in accordance with HSPA capability based handover principles.

If Dual Cell HSDPA capability based handover is enabled simultaneously with MIMO capability based handover (MIMOCAHO) as described in Section Functionality of MIMO capability based handover, the preference between Dual Cell HSDPA capability based handover and MIMO capability based handover is defined with the DCellVsMIMOPreference parameter.

20.1 Periodic Dual Cell HSDPA capability based handoverPeriodic Dual Cell HSDPA capability based handover (DCCAHO) is enabled if the fol-lowing criterias are fullfilled:

• DCellHSDPACapaHO parameter must have a value “1 - Periodical triggering enabled” or “3 - Both triggers enabled”

• HSCapabilityHOPeriod parameter must have a value greater that “0” • HSCapabilityHONumbUE paramater must have a value greater than “0”.

Periodic Dual Cell HSDPA capability based handover can be enabled for all WCDMA cells irrespective of their HSDPA/HSUPA capability. The periodical Dual Cell HSDPA capability based handover is based on the existing HSPA capability based handover

206 DN03471612



Functionality of Dual Cell HSDPA capability based han-dover

(HSCAHO), for more details see Section Functionality of HSPA capability based han-dover. The periodic Dual Cell HSDPA capability based handover, can be started also if DL HS-DSCH and UL E-DCH/DCH is allocated to the UE.

When the periodic Dual Cell HSDPA capability based handover is enabled in the cell (the DCellHSDPACapaHO parameter has a value “1” or “3”), the RRC connections of the Dual Cell HSDPA capable UEs must fullfill the following criterias, in order to start the periodic Dual Cell HSDPA capability based handover procedure:

• RRC connections whose SRNC is the RNC where the Dual Cell HSDPA capability based handover is triggerred

• RRC connections that are in CELL_DCH state • the UE is Dual Cell HSDPA capable • one of the active cells has an inter-frequency neighbor cell that has a

AdjiNCHOHSPASupport parameter set to value “1” (HSPA Support), and if the neighbor cell is controlled by the SRNC, it can act as primary serving HS-DSCH cell (Dual Cell HSDPA and HSUPA are enabled in the cell, with the DCellHSDPAEnabled and HSUPAEnabled)

• RRC connections that are not performing the inter-frequency or inter-system mea-surements

• RRC connections whose penalty time for retry is running, must not be selected

If more than one RRC connection meets the these conditions for the periodic Dual Cell HSDPA capability based handover, the RNC prefers the RRC connection (UE) that do not require compressed mode in this particular handover.

For the Dual Cell HSDPA capable UE the Dual Cell HSDPA capability based handover is preferred to HSPA capability based handover. Dual Cell HSDPA capable UE can be chosen as a candidate for the periodical HSPA capability based handover if the period-ical Dual Cell HSDPA capability based handover cannot be used or if the Dual Cell HSDPA capable UE does not fullfill the Dual Cell HSDPA capability based handover cri-terias, as above. Criterias for the periodical HSPA capability based handover are verified according to the HSPA capability based handover criterias, for more details see section Periodic HSPA capability based handover in Functionality of HSPA capability based handover. Dual Cell HSDPA capable UE is treated as any HSDPA/HSUPA capable UE in case of the periodic HSPA capability based handover (Dual Cell HSDPA capable UE is not preferred to Dual Cell HSDPA non-capable UE in case of the periodic HSPA capability based handover).

The HSCapabilityHONumbUE parameter defines the number of UEs to be chosen for each period. The parameter limits the total number of UEs to be chosen for each period because of all different capability based handovers: Dual Cell HSDPA capability based handover, MIMO capability based handover and HSPA capability based handover. If the number of suitable UEs exceeds the value of the HSCapabilityHONumbUE parameter, the RNC selects UEs first for the periodical MIMO capability based handover and Dual Cell HSDPA capability based handover according to the priority order defined by the DCellVsMIMOPreference parameter, and last for the periodical HSPA capability based handover until the maximum number of UEs to be chosen is reached.

DN03471612 207

WCDMA RAN RRM Handover Control Functionality of Dual Cell HSDPA capability based han-dover


20.2 Event trigerred Dual Cell HSDPA capability based handoverTo enable the event triggered Dual Cell HSDPA capability based handover the DCellHSDPACapaHO parameter needs to be set to value “2 - Event triggerring enabled“ or “3 - Both triggers enabled”.

Event triggered Dual Cell HSDPA capability based handover is enabled only for UEs that support Dual Cell HSDPA and are using HSDPA or HSPA services. The UEs support for Dual Cell HSDPA is defined in the UE radio access capabilities. The support information is received in the Multi cell support IE, in the RRC Connection request message.

When the event triggered Dual Cell HSDPA capability based handover is enabled in an active set cell and at least one active set cell has an inter-frequency neighbor cell with AdjiNCHOHSPASupport parameter set to value “1” (HSPA Support), the RNC triggers the Dual Cell HSDPA capability based handover for the Dual Cell HSDPA capable UE after detecting the the HS-DSCH inactivity. If the inter-frequency neighbor cell is con-trolled by the SRNC, then the inter-frequency cell must also be able to act as primary serving HS-DSCH cell (DCellHSDPAEnabled and HSUPAEnabled parameters are set to value “1”) before Dual Cell HSDPA capability based handover can be triggered. The HS-DSCH inactivity is detected similiar to the HSPA capability based handover, see section Event triggered HSPA capability based handover in Functionality of HSPA capability based handover. Event triggered Dual Cell HSDPA capability based handover has a higher priority than the event triggered HSPA capability based handover.

For Dual Cell HSDPA capable UEs, the Dual Cell HSDPA capability based handover is more preferred than HSPA capability based handover. Dual Cell HSDPA capable UE can be chosen as a candidate for for the event triggerred HSPA capability based handover if the event triggered Dual Cell HSDPA capability based handover is not appli-cable to the UE. For more details on conditions for the event triggerred HSPA capability based handover see section Event triggered HSPA capability based handover in Func-tionality of HSPA capability based handover. In case of the event triggerred HSPA capa-bility based handover Dual Cell HSDPA capable UEs are treated equally with HSDPA/HSPA UEs (Dual Cell HSDPA capable UE will not be preferred to non-capable Dual Cell HSDPA UE in case of event triggered HSPA capability based handover).

If Dual Cell HSDPA capability based handover and MIMO capability based handover are both enabled in the cell, the DCellVsMIMOPreference parameter defines the prefer-ence between Dual Cell HSDPA capability based handover and MIMO capability based handover. The DCellVsMIMOPreference parameter also defines if Dual Cell HSDPA capability based handover or MIMO capability based handover is primarily applied if the UE supports both Dual Cell HSDPA and MIMO and both Dual Cell HSDPA capability based handover and MIMO capability based handover are enabled in the cell.

20.3 Measurement procedures and execution of Dual Cell HSDPA capability based handoverAfter the Dual Cell HSDPA capability based handover is triggered (either periodic or event triggerred), the RNC initiates channel type switch from HS-DSCH/E-DCH to HS-DSCH/DCH (if needed) and starts inter-frequency measurements in compressed mode. If the HSDPA inter-frequency handover is disabled, the channel type is switched to

208 DN03471612



Functionality of Dual Cell HSDPA capability based han-dover

DCH/DCH and inter-frequency measurements are initiated on DCH. Initial bitrate must be allocated to the new DCH during the channel type switch.

The measurement procedures and execution of the Dual Cell HSDPA capability based handover follows the measurement procedures and execution of the HSPA capability based handover. For more information see sections: Inter-Frequency measurement pro-cedures and Execution of HSPA capability based handover in Functionality of HSPA capability based handover.

The RNC measures one frequency at a time. If there are more than one frequency to be measured, the RNC selects a subset of inter-frequency neighbor cells (having the same UTRA radio frequency channel number) which are measured first. The measurement order is controlled with the AdjiPriorityDCellCAHO parameter defined for each neighbor cell.

20.4 Handover decision algorithm of Dual Cell HSDPA capabil-ity based handoverThe handover decision algorithm that is used for the DC HSDPA capability based handover is the same as that of load and service-based inter-frequency handover, for more information see section Handover decision procedure in Functionality of load-based and servicebased IF/IS handover. The best inter-frequency cell (target cell) must also satisfy the following conditions before the DC HSDPA capability based handover is possible:

• the AdjiNCHOHSPASupport parameter of the target cell must have the value ”HSPASupport”,

• no penalty time is running for the target cell.

Note that the DCellHSDPAEnabled parameter is not checked after the best cell (target cell) has been chosen.

DN03471612 209

WCDMA RAN RRM Handover Control Functionality of MIMO capability based handover


21 Functionality of MIMO capability based handoverMIMO capability based handover (MIMOCAHO) transfers the MIMO capable UEs to the MIMO cell, when the MIMO capable UE is not in the MIMO cell. MIMO capability based handover is applied only if NRT RAB (or RABs) are established for the MIMO capable UE. MIMO capability based handover is not applicable if RT or CS RAB is established for the UE.

MIMO capability based handover is based on the existing Functionality of HSPA capa-bility based, for more details see Section Functionality of HSPA capability based han-dover. MIMO capability based handover uses both periodical and event triggering of the HSPA capability based handover . MIMO capability based handover is based on the same license, and can be enabled simultaneously with HSPA capability based handover in the cell.

MIMO capability based handover is controlled with the MIMOHSDPACapaHO parameter. The parameter can have four values:

• “0” - MIMO capability based handover is disabled in the cell • “1” - periodical triggering is enabled (event triggering is disabled) in the cell • “2” - event triggering is enabled (periodical triggering is disabled) in the cell • “3” - periodical and event triggering are enabled in the cell

If MIMO capability based handover is enabled simultaneously in the same cell with HSPA capability based handover, then the MIMO capability based handover is preferred in case of the MIMO capable UE. If the MIMO capable UE is not suitable for MIMO capa-bility based handover procedure, then HSPA capability based handover is capable of transferring also MIMO capable UE in accordance with HSPA capability based handover principles.

If MIMO capability based handover is enabled simultaneously with Dual Cell HSDPA capability based handover (DCCAHO) as described in Section Functionalities of Dual Cell HSDPA capability based handover, the preference between MIMO capability based handover and Dual-Cell HSDPA capability based handover is defined with the DCellVsMIMOPreference parameter.

MIMO capability based handover requires that the AdjiNCHOHSPASupport parameter is set to “HSPASupport” value in at least one on the inter-frequency neighbor cell in order to start inter-frequency measurements. The order of the carrier frequencies to be measured is defined by setting the value of the AdjiPriorityMIMOCAHO parameter. Because of the MIMO capability based handover, RNC measures only such a frequency layer where at least one MIMO capable inter-frequency neighbor cell can be found for any active cell set. The frequency layer can be measured because of the HSPA capa-bility based handover even if there is no MIMO capable cell in the frequency layer. MIMOEnabled parameter is used to define MIMO capability of a frequency layer. In case of inter-RNC handover, only AdjiNCHOHSPASupport parameter indicates if the inter-frequency measurements can be started and DRNC call can be a candidate for MIMO capability based handover.

Handover decision algorithm used for MIMO capability based handover is the same as that of load-based and service-based IF/IS handover, see section Handover decision procedure in Functionality of load-based and service-based IF/IS handover. Before the

210 DN03471612



Functionality of MIMO capability based handover

MIMO capability based handover is possible, the best inter-frequency cell (which is the target cell) must also meet the following criterias:

• AdjiNCHOHSPASupport parameter of the target cell must have the “HSPASup-port” value

• no penalty time is running for the target cell (AdjiPenaltyTimeNCHO).

Note that the MIMOEnabled parameter is not checked after the best cell (target cell) has been found.

21.1 Periodic MIMO capability based handoverPeriodic MIMO capability based handover (MIMOCAHO) is enabled if the following cri-terias are fullfilled:

• MIMOHSDPACapaHO parameter must have a value “1 - Periodical triggering enabled” or “3 - Both triggers enabled”

• HSCapabilityHOPeriod parameter must have a value greater than “0” • HSCapabilityHONumbUE paramater must have a value greater than “0”.

Periodic MIMO capability based handover can be enabled for all WCDMA cells irrespec-tive of their HSDPA/HSUPA capability. The periodical MIMO capability based handover is based on the existing HSPA capability based handover (HSCAHO), for more details see Section Functionality of HSPA capability based handover. The periodic MIMO capa-bility based handover, can be started also if DL HS-DSCH and UL E-DCH/DCH is allo-cated to the UE.

When the periodic MIMO capability based handover is enabled in the cell (the MIMOHSDPACapaHO parameter has a value “1”), the RRC connections of the MIMO capable UEs must fullfill the following criterias, in order to start the periodic MIMO capa-bility based handover procedure:

• RRC connections whose SRNC is the RNC where the MIMO capability based handover is triggerred

• RRC connections that are in CELL_DCH state • RRC connections that are not performing the inter-frequency or inter-system mea-

surements • RRC connections whose penalty time for retry is running, must not be selected • one of the active cells has an inter-frequency neighbor cell that has a

AdjiNCHOHSPASupport parameter set to value “1” (HSPA Support), and if the neighbor cell is controlled by the SRNC, it can act as MIMO cell (MIMOEnabled parameter is set to value “1”)

If more than one RRC connection meets the these conditions for the periodic MIMO capability based handover, the RNC prefers the RRC connection (UE) that do not require compressed mode in this particular handover.

For the MIMO capable UE the MIMO capability based handover is preferred to HSPA capability based handover. MIMO capable UE can be chosen as a candidate for the periodical HSPA capability based handover if the periodical MIMO capability based handover cannot be used or if the MIMO capable UE does not fullfill the MIMO capability based handover criterias, as above. Criterias for the periodical HSPA capability based handover are verified according to the HSPA capability based handover criterias, for more details see section Periodic HSPA capability based handover in Functionality of HSPA capability based handover. MIMO capable UE is treated as any HSDPA/HSUPA

DN03471612 211

WCDMA RAN RRM Handover Control Functionality of MIMO capability based handover


capable UE in case of the periodic HSPA capability based handover (MIMO capable UE is not preferred to MIMO non-capable UE in case of the periodic HSPA capability based handover).

If MIMO capability based handover and Dual-Cell HSDPA capability based handover are both enabled in the cell, the DCellVsMIMOPreference parameter defines the preference between MIMO capability based handover and Dual-Cell HSDPA capability based handover. The DCellVsMIMOPreference parameter also defines if MIMO capability based handover or Dual-Cell HSDPA capability based handover is primarily applied if the UE supports both MIMO and DC-HSDPA and both MIMO capability based handover and Dual-Cell HSDPA capability based handover are enabled in the cell.

MIMO capability based handover uses the HSCapabilityHONumberUE parameter to define the number of UEs to be chosen for each period. HSCapabilityHONumberUE parameter also limits the total number of UEs to be chosen for each period because of all different capability based handovers: HSDPA capability based handover, Dual-Cell HSDPA capability based handover and MIMO capability based handover.

21.2 Event trigerred MIMO capability based handoverTo enable the event triggered MIMO capability based handover the MIMOHSDPACapaHO parameter needs to be set to value “2 - Event triggerring enabled“ or “3 - Both triggers enabled”.

Event triggered MIMO capability based handover is enabled only if the source cell is HSDPA/HSUPA capable (HS-DSCH is allocated to the UE).

When MIMO capability based handover is enabled in the cell, by the MIMOHSDPACapaHO parameter, RNC triggers MIMO capability based handover for the MIMO capable UE after the HS-DSCH inactivity is detected. The HS-DSCH inactivity is detected similiar to the HSPA capability based handover, see section Event triggered HSPA capability based handover in Functionality of HSPA capability based handover. Event triggered MIMO capability based handover has a higher priority than the event triggered HSPA capability based handover.

For MIMO capable UEs, the MIMO capability based handover is more preferred than HSPA capability based handover. MIMO capable UE can be chosen as a candidate for for the event triggerred HSPA capability based handover if the event triggered MIMO capability based handover is not applicable to the UE. For more details on conditions for the event triggerred HSPA capability based handover see section Event triggered HSPA capability based handover in Functionality of HSPA capability based handover. In case of the event triggerred HSPA capability based handover MIMO capable UEs are treated equally with HSDPA/HSPA UEs (MIMO capable UE is not preferred to non-capable MIMO UE in case of event triggered HSPA capability based handover).

If MIMO capability based handover and Dual-Cell HSDPA capability based handover are both enabled in the cell, the DCellVsMIMOPreference parameter defines the preference between MIMO capability based handover and Dual-Cell HSDPA capability based handover. The DCellVsMIMOPreference parameter also defines if MIMO capability based handover or Dual-Cell HSDPA capability based handover is primarily applied if the UE supports both MIMO and DC-HSDPA and both MIMO capability based handover and Dual-Cell HSDPA capability based handover are enabled in the cell.

212 DN03471612



Functionality of MIMO capability based handover

21.3 Measurement procedures and execution of MIMO capabil-ity based handoverAfter the MIMO capability based handover is enabled (either periodic or event trig-gerred), the RNC initiates channel type switch from HS-DSCH/E-DCH to HS-DSCH/DCH and initiates inter-frequency measurements in compressed mode. If the HSDPA inter-frequency handover is disabled, the channel type is switched to DCH/DCH and inter-frequency measurements are initiated on DCH. Initial bitrate must be allocated to the new DCH during the channel type switch.

The measurement procedures and execution of the MIMO capability based handover follows the measurement procedures and execution of the HSPA capability based handover for more information see sections: Inter-Frequency measurement procedures and Execution of HSPA capability based handover in Functionality of HSPA capability based handover.

DN03471612 213

WCDMA RAN RRM Handover Control Functionality of LTE interworking

Id:0900d80580715cb5Confidential

22 Functionality of LTE interworkingLTE Interworking (LTEIW) functionality enables cell reselection from 3G to LTE and provides support for packet switched inter-system handover (PS ISHO) from LTE to 3G.

The following figure describes signaling procedure of the inter-RAT handover from E-UTRAN to UTRAN from the point of view of the RNC.

Figure 61 Inter-RAT handover from E-UTRAN to UTRAN

1. The RNC receives the RANAP:RELOCATION REQUEST from the packet switched core network (PS-CN). The message starts the resource allocation in the RNC for the inter-system handover.

2. If UE History Information information element is not included in the RANAP:RELO-CATION REQUEST, or does not indicate E-UTRAN as the last visited cell or LTE interworking feature is not active in the cell or license is in state OFF/Config then relocation is rejected. LTE System always includes the UE UTRAN capabilities infor-

214 DN03471612


Id:0900d80580715cb5Confidential

Functionality of LTE interworking

mation in UE radio access capability information element in the Source to Target RNC Transparent Container during handover from LTE to UMTS.RRC will rejects the RANAP:RELOCATION REQUEST from LTE system if the UE UTRAN capabili-ties are not received in the Source to Target RNC Transparent Container with the failure cause: "Relocation Failure in Target CN/RNC or Target System".

3. The cell specific admission control does the power estimation and admission decision for the RBs.

4. The RNC allocates the RNTI, the radio resources for RBs and the radio link, and sends the NBAP:RADIO LINK SETUP to the Node B.

5. The Node B allocates resources, starts PHY channel reception, and responds with the NBAP: RADIO LINK SETUP RESPONSE

6. The RNC builds an RRC: HANDOVER TO UTRAN COMMAND providing informa-tion on the allocated resources and sends it to the PS-CN through the RANAP: RELOCATION REQUEST AKCNOWLEDGE. . Note: Complete specification is always used in case of ISHO from LTE.

7. The RNC achieves uplink synchronization on the Uu interface.8. The RNC confirms the detection of the handover to the PS-CN by sending the

RANAP:RELOCATION DETECT. The PS-CN may at this point switch the user plane to the RNC.

9. Once the RRC connection is established with the UTRAN, the UE sends the RRC: HANDOVER TO UTRAN COMPLETE to the RNC.

10. The target RNC sends the RANAP:RELOCATION COMPLETE to the PS-CN. If the user plane has not been switched in step 7, the PS-CN switches the user plane to the target RNC.

11. The integrity protection was received in a RANAP:RELOCATION REQUEST message, the target RNC sends the RRC:SECURITY MODE COMMAND to the UE in order to configure the integrity protection parameters. Alternatively, PS-CN might activate an integrity protection procedure by sending a RANAP:SECURITY MODE COMMAND message to the target RNC

12. The UE confirms the configuration of integrity protection by sending the RRC:SECU-RITY MODE COMPLETE to the target RNC.

13. The RNC allocates a new U-RNTI and specifies the timer- and constants values to be used by the UE in connected mode by sending the RRC:UTRAN MOBILITY INFORMATION to the UE.

14. The UE confirms the new UTRAN mobility information by sending the RRC:UTRAN MOBILITY INFORMATION CONFIRM to the RNC.

15. The RNC starts the intra-frequency measurement by sending the RRC:MEASURE-MENT CONTROL to the UE.

DN03471612 215

WCDMA RAN RRM Handover Control Functionality of Blind inter-frequency handover in RABsetup phase

Id:0900d805807ea1deConfidential

23 Functionality of Blind inter-frequency handover in RAB setup phaseIntra frequency RACH measurements quantity needs to be changed from EcNo to RSCP in the cells where blind inter-frequency handover is activated, because of the fact that RSCP is a more accurate indicator for UE position in the cell. If UE is near the cell edge, blind handover is to be avoided.

Inter frequency measurements can be added to RACH measurements. It makes it possible to use target cell measurement instead of totally blind inter-frequency han-dover.

In blind handover, for each source cell, possible target cells needs to defined. Only one target cell per frequency is allowed to be configured. Target cells are defined with ADJI-BlindHOTargetCell parameter. Target cell needs to be within the same RNC as source cell (which means that inter-RNC blind handover is not supported).

23.1 Source cell measurements for blind HO in RAB setupThe following source cell measurement results are available for blind handover:

• UE measures and reports RSCP value from current cell and best neighbor cell to RNC in RRC Connection Request and Cell Update messages. These are called RACH measurement results.

g The RSCP must be selected as intra-frequency measurement quantity with RACHIntraFreqMesQuant parameter.

• If soft handover branch is added in Cell_DCH state UE reports RSCP values to RNC in event 1A or 1C.

• If SRBs are mapped to HSPA, the periodic RSCP reporting is activated. Periodic measurement report is available at this point.

The latest available measurement report containing RSCP value of source cell is used for blind handover.

Source cell for blind handover in RAB setup phase is the cell which has reported the highest RSCP value in the latest measurement report.

If the UE is in Cell_FACH state or in Cell_DCH state without soft handover and there is no measurement results from current cell, the source cell measurement cannot be used and blind handover or layering in state transition cannot be done. Target cell measure-ment results cannot be used in this case because it is sure that those are not valid either.

23.2 RNC decision algorithm for blind handover in RAB setupRNC makes the decision for blind handover in RAB setup if MBLBRABSetupEnabled parameter triggers multi-band load balancing in RAB setup phase. RNC makes the decision of blind handover in RAB setup phase in the following steps:

1. First, the RNC checks possible target cells. Possible target cells can be found with two complementary methods: • Blind handover done based on source cell measurements

Source cell measurements that is used and the source cell are described in 23.1 Source cell measurements for blind HO in RAB setup. For source cell,

216 DN03471612



Functionality of Blind inter-frequency handover in RAB setup phase

possible blind handover target cells are defined with BlindHOTargetCell parameter. It is possible to define only one target cell per frequency.

g Inter-RNC neighbor cell cannot be defined as target cell

• Blind handover done based on target cell measurementsA cell is chosen as a possible target cell for blind handover if that cell was included in inter-frequency measurement results on RACH measurement (eventhough blind handover to that cell is not enabled with BlindHOTargetCell parameter) and is from the same RNC as the source cell.

g The cell, which is in the frequency band that UE does not support, cannot be selected as a target cell.

2. Afterwards, the RNC measures the preference score of possible target cells selected in the first phase and the source cell (a cell having the highest RSCP/EcNo value in RACH measurement). The preference score of cells is calculated as described in 23.1 Source cell measurements for blind HO in RAB setup. Suitable cells are those which have a value greater than zero in any of the following: PrefLayerWeight, BandWeight or RSCPWeight. The decision is made accord-ing to the following principles: • If preference score of the current layer is equal or greater than preference score

of the other best layer, then the blind handover is not executed. • If there is a layer having greater preference score than current layer preference

score and the target cell is possible on that layer, the blind handover is done to that cell. The selected cell is the cell of the greatest preference score. If there are several equally preferred target layers, the selection is done in non-fixed order (the same layer is not always selected in similiar situation).

3. Afterwards, RNC checks the quality criteria before blind handover can be done. This is done in all other cases, with an exception when the target cell has greater prefer-ence score than source cell because of RSCPWeight.

In those cases the quality check is not done. There are two methods to check the quality if the blind handover can be done to target cell. If any cell satisfies quality criteria, the blind handover can be performed.

• If the following equation is true, the blind handover can be done

where: • Source_cell_RSCP is RSCP measurement value from the source cell described

in 23.1 Source cell measurements for blind HO in RAB setup. • BlindHORSCPThr is a value of BlindHORSCPThr parameter from the source

cell to the target cell where the blind handover is enabled with BlindHOTargetCell parameter.

• AdjiCPICHTxPwr is a value of AdjiCPICHTxPwr parameter from the source cell to the target cell where the blind handover is enabled with BlindHOTargetCell parameter.

• PtxPrimaryCPICH is a value of PtxPrimaryCPICH parameter in the source cell.

Source_Cell_RSCP BlindHORSCPThr AdjiCPICHTxPwr PtxPrimaryCPICH–( )–≥

DN03471612 217



• If target cell was included to inter-frequency measurement results on RACH mea-surement, the blind handover can be performed. It is also validated that the target cell and the source cell have the same RNC id, MCC and MNC.

If the cell with the greatest preference score did not satisfy quality the criteria, other cells with greater preference score than current cell are to be checked.

If the target cell measurement is available from target frequency, the target cell is the cell which UE has reported from that frequency in inter-frequency measurements.

If the target cell measurement is not available from target frequency but the quality criteria from source cells allows the blind handover, the target cell is the one defined with BlindHOTargetCell parameter in the source cell.

23.3 Multi RAB cases in blind handover in RAB setup phaseFrequency layer/band and node B change will be possible in multi RAB case only when UE has an NRT RAB(s) and UE is in the following states:

• Cell_FACH state when AMR RAB assignment request comes from the core network and MBLBRABSetupMultiRB parameter enabled blind handover for multi RAB from Cell_FACH state (value 1 or 3).

• Cell_DCH state when AMR RAB assignment request comes from the core network and MBLBRABSetupMultiRB parameter enabled blind handover for multi RAB from Cell_DCH state (value 2 or 3).

Otherwise, layer/band and node B change is possible only when the first RAB is setup.

In the case, when NRT RAB is inactive and extended timer in Cell_DCH state is set, the DCH0/0 is allocated for NRT RAB in target cell.

Blind handover is only allowed when source cell is under SRNC.

Source RNC validates if penalty time for non-critical handover (AdjiPenaltyTimeNCHO paramater) of that cell is running. If penalty time is running RNC executes blind handover in RAB setup to that cell.

23.4 Decision for blind handover in RAB setup phase based on capability, service, load and low/high RSCP

23.4.1 Preference score calculation in decision makingThe decision making is based on preference score calculated to every available fre-quency. Preference score is calculated with the following formula.

PrefLayerWeight value is set based on preferred layer definitions. Preferred layers for UE capability & service combination are checked by PFL-PrefLayer... parameters. In 23.4.2 Correct parameter choice from preferred layer definitions it is defined how the correct parameter is chosen. If the frequency layer is preferred for the UE, PrefLayerWeight parameter is set to value taken from LaySelWeightPrefLayer parameter. If the frequency layer is not preferred for the UE, PrefLayerWeight is set to value 0.

BandWeight value is set based on a preferred band definition. The preferred band is defined with PreferBandForLayering parameter. If there is any band defined as

Preference_score PrefLayerWeight BandWeight RSCPWeight+ +=

218 DN03471612



Functionality of Blind inter-frequency handover in RAB setup phase

preferred, for the frequencies in that band, BandWeight is set to value taken from LaySelWeightBand parameter. For other frequencies BandWeight is set to value 0.

RSCPWeight value is defined based on RSCP below/above definitions. RSCP above the threshold is used to transfer UE with high RSCP value to higher frequency band. If the source cell RSCP of UE is at minimum equal to value in BlindHORSCPThrAbove parameter, for the frequencies in higher band RSCPWeight is set to value taken from LaySelWeightRSCP parameter. RSCP below the threshold is used to transfer UE with low RSCP value to lower frequency band. If the source cell RSCP of UE is at maximum equal to value in BlindHORSCPThrBelow parameter, for the frequencies in lower band RSCPWeight is set to value taken from LaySelWeightRSCP parameter. For other fre-quencies RSCPWeight is set to value 0.

g By default RSCP above (BlindHORSCPThrAbove parameter) and RSCP below (BlindHORSCPThrBelow parameter) are not applied.

If there are 3 frequency bands, the middle band is interpreted to be the same as the highest or lowest band. The middle band is associated with higher or the lower band depending on which one is the nearest.

Frequency layers, which are the frequency band not supported by UE, will get prefer-ence score equal to 0, and cannot be selected as target frequencies.

23.4.2 Correct parameter choice from preferred layer definitionsUE capability and service combination defines the correct parameter. First, possible parameters are selected based on UE capability. After that, from previously selected parameters, a correct parameter is selected based on the service that is currently used by the UE. If preferred layer is not defined for that parameter, the selection of correct parameter is repeated with the next highest capability that UE supports. Procedure is repeated as long as correct parameter is found. If no correct parameter can be found the decision is to stay in the current layer.

Based on UE capability the highest priority capability defines which parameters can be used, and capabilities have the following priority order:

1. CS voice over HSPA (PrefLayerCSHSNRT, PrefLayerCSHSStr, PrefLayerCSHSAMR and PrefLayerCSHSAMR&NRT parameters)

2. DC-HSDPA+MIMO (PrefLayerDCMINRT, PrefLayerDCMIStr, PrefLayerDCMIAMR and PrefLayerDCMIAMR&NRT parameters)

3. DC-HSDPA if DCellVsMIMOPreference parameter has value “DC-HSDPA” oth-erwise MIMO (PrefLayerDCHSDNRT, PrefLayerDCHSDStr, PrefLayerDCHSDAMR or PrefLayerDCHSDAMR&NRT parameters)

4. MIMO if DCellVsMIMOPreference parameter has value “MIMO” otherwise DC-HSDPA (PrefLayerMIMONRT, PrefLayerMIMOStr, PrefLayerMIMOAMR and PrefLayerMIMOAMR&NRT parameters)

5. HSDPA 64QAM (PrefLayer64QAMNRT, PrefLayer64QAMStr, PrefLayer64QAMAMR and PrefLayer64QAMAMR&NRT parameters)

6. F-DPCH (PrefLayerFDPCHNRT, PrefLayerFDPCHStr, PrefLayerFDPCHAMR and PrefLayerFDPCHAMR&NRT parameters)

7. HSPA (PrefLayerHSPANRT, PrefLayerHSPAStr, PrefLayerHSPAAMR and PrefLayerHSPAAMR&NRT parameters)

DN03471612 219



8. HSDPA (PrefLayerHSDPANRT, PrefLayerHSDPAStr, PrefLayerHSDPAAMR and PrefLayerHSDPAAMR&NRT parameters)

9. R99 (PrefLayerR99NRT, PrefLayerR99Str, PrefLayerR99AMR and PrefLayerR99AMR&NRT)

Services are selected according to the following principles:

1. NRT: Following RAB combinations: • 1, 2 or 3 PS NRT RAB(s)

2. Streaming: Following RAB combinations: • PS streaming • PS streaming with 1, 2 or 3 PS NRT RAB(s)

3. AMR: Following RAB combinations: • Circuit switched AMR RAB • Circuit switched RAB other than AMR

4. AMR and NRT: Following RAB combinations: • Circuit switched AMR RAB with 1, 2 or 3 PS NRT RAB(s) • Circuit switched AMR RAB with PS streaming • Circuit switched AMR RAB with PS streaming, and with 1, 2or 3 PS NRT RAB(s) • Circuit switched RAB other than AMR with 1, 2 or 3 PS NRT RAB(s) • Circuit switched RAB other than AMR with PS streaming • Circuit switched RAB other than AMR with PS streaming, and with 1, 2or 3 PS

NRT RAB(s)

g Allocated transport type does not effect decision. Decision is done only based on capa-bility and service. Transport channel selection is performed independently of layer selection.

23.5 Functionality of the blind inter-frequency handover in RAB setup phase interworking • Directed RRC connection setup

When the blind handover in RAB setup phase is enabled in the cell (MBLBARBSetupEnabled parameter), the Directed RRC connection setup can be done in the following cases: • For R99 capable UEs only to cell where HSDPA is not enabled • For establishment cause “conversational call” only if HSDPA is not enabled for

current cell (where RRC connection setup request came) and for target cell. • Directed RRC connection setup for HSDPA layer

When the blind handover in RAB setup is enabled in the cell (MBLBARBSetupEnabled parameter), the Directed RRC connection setup for HSDPA layer functionality is not applied in the cell. The conclusion from decision making is always not to change the layer.

• Common Channel SetupLayer changes cannot be done when call setup is done within common channels. Layer change is possible only when direct resource allocation is applied during common channel setup. The same is valid when HS_FACH is used.

• Direct Resource AllocationMulti-band load balancing is supported with Direct Resource Allocation.

220 DN03471612


Id:0900d80580713d1eConfidential

Delay in block resource procedure

24 Delay in block resource procedureWhen the BTS sends a block request with normal priority to the RNC, besides the existing functionality, a 10-seconds delay after shutdown timer is applied. After 10-seconds delay the management of the block resource normal priority continues. The delay is considered in managing the block resource request procedure in RNC.

The 10-seconds delay is applied with Flexi BTS and Ultra BTS with software release WBTS6.0 onwards. If the BTS supports the delay, the RNC also applies the 10-seconds delay. If not, the RNC does not use the delay in management of block resource request with normal priority procedure.

Management of 10-seconds delay and forced handovers for remaining UEs in cell with block resource normal priority is generic functionality applied in all block resource request with normal priority cases.

24.1 Handover procedures in CPICH power ramp-down in block resource normal priorityDuring the delay in block resource procedure the following procedures are handled:

• Branch deletion using 1B report • Handover need detection • Inter-frequency measurements and inter-system measurements • Target cell determination for IFHO/ISHO • Handover signaling • Management of failed handover

There are two exceptions in handovers because of CPICH power ramp-down:

• Exception related to management of failed handover • Exception related to IFHO/ISHO priority in block resource normal priority

If the CPICH power ramp-down is made according to block resource normal priority, the priorized handover type is defined by IntelligentSDPrioHO parameter. With IntelligentSDPrioHO parameter value “ISHO”, inter-system handover is attempted prior to inter-system handover and contrariwise with IntelligentSDPrioHO param-eter value IFHO inter-frequency handover is attempted prior to inter-system handover.

24.2 Handover re-attempt during CPICH power ramp-down in block resource normal priorityFail management (branch deletion, IFHO/ISHO) is made, as in current implementation, with one exception. When the handover or branch deletion attempt fails and the gradual CPICH power ramp-down is not finished, the unsuccessful handover is managed.

If the time for CPICH power ramp-down has elapsed when the handover or branch deletion attempt fails, a forced IFHO/ISHO procedure starts if the UE is still remaining in the cell with block resource normal priority.

DN03471612 221

WCDMA RAN RRM Handover Control Delay in block resource procedure

Id:0900d80580713d1eConfidential

24.3 Reporting forced handover in block resource requestReporting forced inter-frequency handoverThe RNC provides new counters for measuring the number of inter-frequency han-dovers because of block resource request with normal priority procedure.

The counters are updated for the WBTS/CELL object. The measurement type is M1008 Intra-system Handover. The RNC provides the following counters:

• Number of inter-frequency handover attempts for NRT forced by block resource normal priority

• Number of inter-frequency handover attempts for RT forced by block resource normal priority

• Number of inter-frequency handover successes for NRT forced by block resource normal priority

• Number of inter-frequency handover successes for RT forced by block resource normal priority

Reporting forced inter-system handoverThe RNC provides new counters for measuring the number of inter-system handovers because of block resource request with normal priority procedure.

The counters are updated for the WBTS/CELL object. The measurement type is M1010 Inter-system Handover. The RNC provides the following counters:

• Number of inter-system handover attempts for NRT forced by block resource normal priority

• Number of inter-system handover attempts for RT forced by block resource normal priority

• Number of inter-system handover successes for NRT forced by block resource normal priority

• Number of inter-system handover successes for RT forced by block resource normal priority

222 DN03471612



UTRAN - GAN interworking

25 UTRAN - GAN interworkingThe UTRAN - GAN Interworking feature enables inter-RAT handovers between UTRAN and GAN networks for CS voice calls. The inter-RAT handover is supported on both directions, that is from UTRAN to GAN and from GAN to UTRAN. Idle mode mobility is invisible to UTRAN.

The UTRAN - GAN Interworking feature is enabled by specifying the GAN specific ARFCN and BSIC (NCC + BCC) with the following RNC parameters:

• GAN ARFCN (GANetwARFCN) • GAN NCC (GANetwNCC) • GAN BCC (GANetwBCC)

25.1 UE capabilityWhen the UE supports handover to GAN, it includes the optional Support of Handover to GAN IE in the UE Multi-Mode/Multi-RAT Capability IE that is an element of the UE Radio Access Capability IE. Based on the information included in the UE Radio Access Capability IE sent by the UE, the RNC knows whether or not the UE supports handover to GAN.

The UE sends the UE Radio Access Capability IE to the RNC in the RRC: CONNEC-TION SETUP COMPLETE and UE CAPABILITY INFORMATION messages. In addi-tion, the UE Radio Access Capability IE is included in the RRC: INTER RAT HANDOVER INFO WITH INTER RAT CAPABILITIES and RRC: SRNS RELOCATION INFO messages which are exchanged between network nodes within the transparent RRC information containers during inter-RAT handover and SRNS relocation proce-dures respectively.

The Support of Handover to GAN IE is described in the Rel.6 version of 3GPP TS 25.331 in a release independent manner such that a GAN capable UE with a Rel.99 implementation of UTRAN is capable of signaling support for GAN.

25.2 GAN-Specific handover trigger event 3AThe RNC uses inter-RAT measurement event 3A as GAN-specific handover trigger. If a UE supports handover to GAN, the RNC sets up the inter-RAT measurement 3A for CS voice services.

A GAN specific ARFCN + BSIC combination common to all GAN cells identifies the GAN cells in the inter-RAT neighbor cell list for event 3A. As a UE that supports WLAN radio access is capable of simultaneous access to both WLAN and UTRAN, there is no need for compressed mode.

The RNC does not include the GAN neighbor cell in the inter-RAT cell info list of SIB11, SIB11bis, SIB12, or SIB18.

The RNC does not set up the inter-RAT measurement 3A for PS + CS multi-RAB com-binations. If the RNC has already started the inter-RAT measurement 3A for CS voice services, it stops the measurement as soon as a PS RAB is established. The RNC restarts inter-RAT measurement 3A after release of the PS RAB if CS voice becomes the only service.

The RNC uses the event 3A triggered inter-RAT measurement report solely for trigger-ing inter-RAT handover to GAN. The UE sends the measurement report to the RNC in

DN03471612 223

WCDMA RAN RRM Handover Control UTRAN - GAN interworking


the RRC: MEASUREMENT REPORT message whenever it has successfully registered on a GANC.

25.3 GAN handover decisionWhen the UE is in GAN preferred mode, the UE sends the event 3A triggered measure-ment report to the RNC after successful registration to the GAN cell. Based on the received event 3A measurement report, the RNC initiates an inter-RAT handover to the GAN neighbor cell. Each WCDMA cell can have only one GAN neighbor cell. The parameter ADJG - ADJGType indicates whether the inter-system neighbor cell is a GSM cell or a GAN cell. The neighbor cell is a GAN cell when the value of the parameter ADJG- ADJGType is "GAN cell".

25.3.1 Identification of the GAN target cellEach WCDMA cell can have only one GAN neighbor cell. The GAN neighbor cell is defined in the same RNW database object ADJG which is used for GSM neighbor cell definitions. The parameter ADJG - ADJGType indicates whether the inter-system neighbor cell is a GSM cell or a GAN cell. The neighbor cell is a GAN cell when the value of the parameter ADJG - ADJGType is "GAN cell".

If the UTRAN - GAN Interworking feature and the I-HSPA Sharing and Iur Mobility Enhancements feature are both enabled in the DRNC, the DRNC can report any GAN neighbor cell to the SRNC in the RNSAP: RADIO LINK SETUP/ADDITION RESPONSE message over the Iur interface. The DRNC sends the GAN neighbor cell information as a part of the neighboring GSM Cell Information IE.

As the ADJG parameters of the GAN neighbor cell do not contain valid BCCH AFRCN or BSIC (NCC + BCC) data, the DRNC fills the BCCH AFRCN and BSIC (NCC + BCC) IEs in the GAN neighbor cell information with the following RNC parameters:

• GANetwARFCN indicates the ARFCN of the GAN neighbor cell. • GANetwNCC indicates the NCC of the GAN neighbor cell. • GANetwBCC indicates the BCC of the GAN neighbor cell.

If the UTRAN - GAN Interworking feature and the Support for I-HSPA Sharing and Iur Mobility Enhancements feature are both enabled in the SRNC, the SRNC identifies the GAN neighbor cell among the GSM neighbor cells received from the DRNC. In this purpose the SRNC compares the BCCH, AFRCN and BSIC of the neighbor cells with the GAN specific ARFCN and BSIC (that is, the preceding RNC parameters: GANetwARFCN, GANetwNCC, GANetwBCC).

If an active set cell has an inter-RAT (GAN) neighbor cell whose ADJG - ADJGType parameter has the value "GAN cell" or the SRNC has identified a GAN cell within the neighbor cell information received from the DRNC, handover control starts an inter-RAT handover attempt to the GAN neighbor cell immediately after the reception of the mea-surement report 3A. The RNC uses the RANAP relocation procedure to carry out the inter-RAT handover to GAN.

If the GAN neighbor cells of two or more active set cells, which are participating in a soft handover, are different, the RNC selects the GAN neighbor cell of the active set cell with the higher CPICH Ec/No measurement result. If no active set cell has GAN neighbor cell, an inter-RAT handover to GAN is not possible and the RNC rejects the received event 3A measurement report.

224 DN03471612




25.3.2 Handover from UTRAN to GANFigure 62 Inter-RAT handover from UTRAN to GAN shows the signaling procedure of the Inter-RAT handover from UTRAN to GAN from the RNC's point of view.

Figure 62 Inter-RAT handover from UTRAN to GAN

From RNC point of view, the signaling procedure and the failure cases of the inter-RAT handover from UTRAN to GAN are identical to the signaling procedure of the inter-RAT handover from UTRAN to GSM:

1. The UE sends the RRC: MEASUREMENT REPORT (event 3A) message to the RNC.

2. The RNC starts the preparation phase of the relocation procedure by sending an RANAP: RELOCATION REQUIRED message to the core network.

3. The core network sends a BSSAP: HANDOVER REQUEST message to the target GANC in order to request resources for the handover.

4. The target GANC acknowledges the handover request message by sending a BSSAP: HANDOVER REQUEST ACKNOWLEDGE message to the core network.

5. The core network completes the relocation preparation by sending an RANAP: RELOCATION COMMAND message to the RNC.

6. The RNC initiates the handover to GAN by sending an RRC: HANDOVER FROM UTRAN COMMAND message to the UE. To keep the audio interruption short, the

1. Uu: Measurement Report

2. Relocation Required

3. Handover Request

4. Handover Request Acknowledge

5. Relocation Command

6. Uu: Handover from UTRAN command

7. GA-CSR HANDOVER ACCESS

CNRNCGANCUE

GAN Registered

8. RTP stream setup

9. GA-CSR HANDOVER COMPLETE

10. Handover Detect

11. Voice traffic

12. Handover Complete

14. Iu Release Complete

13. Iu Release Command

DN03471612 225



UE keeps its UTRAN audio path until the GA-CSR HANDOVER COMPLETE message is sent to the GANC and the handover is completed.

7. The UE accesses the GANC using the GA-CSR HANDOVER ACCESS message.8. The GANC sets up the bearer path with the UE. 9. The UE transmits the GA-CSR HANDOVER COMPLETE message to indicate the

completion of the handover procedure from its perspective. It switches the user from the UTRAN user plane to the GAN user plane.

10. The GANC indicates that it has detected the UE by sending a BSSAP: HANDOVER DETECT message to the core network. The core network can optionally now switch the user plane from the source RNC to the target GANC.

11. Bi-directional voice traffic is now flowing between the UE and the CN via the GANC.12. The target GANC indicates that the handover is completed by sending a BSSAP:

HANDOVER COMPLETE message to the core network. The core network switches the user plane from the source RNC to the target GAN if it has not been switched in step 10.

13. Finally, the core network tears down the connection to the source RNC by sending the RANAP: IU RELEASE COMMAND message.

14. The source RNC confirms the release of UTRAN resources allocated for this call by sending the RANAP: IU RELEASE COMPLETE message to the core network.

25.3.3 Unsuccessful handover attemptThe core network sends a RANAP: RELOCATION PREPARATION FAILURE message to the RNC in the event of:

• The core network or the target system, that is the GAN, is not able to accept the han-dover.

• A failure occurs during the relocation preparation procedure in the core network. • The core network decides to discontinue the handover to GAN.

The UE reverts back to the UTRA configuration and transmits an RRC: HANDOVER FROM UTRAN FAILURE message to the RNC if the UE does not succeed in establish-ing the connection to the target radio access technology GAN.

If the relocation preparation procedure or the UTRAN (RRC) procedure fails, the handover control of the RNC terminates the inter-RAT handover attempt to GAN that was triggered by the current event 3A report. The handover control can start another handover attempt to GAN immediately after the reception of the next event 3A triggered measurement report. There is no minimum interval specified between an unsuccessful handover attempt and the following inter-RAT handover attempt to GAN.

25.3.4 Handover from GAN to UTRANFigure 63 Inter-RAT handover from GAN to UTRAN shows the signaling procedure of the Inter-RAT handover from GAN to UTRAN from the RNC's point of view.

226 DN03471612




Figure 63 Inter-RAT handover from GAN to UTRAN

From RNC point of view, the signaling procedure and the failure cases of the inter-RAT handover from GAN to UTRAN are identical to the signaling procedure of the inter-RAT handover from GSM to UTRAN:

1. The GANC may send a GA-CSR UPLINK QUALITY INDICATION message if there is a problem with the uplink quality for the ongoing call.

2. The UE sends the GA-CSR HANDOVER INFORMATION message to the Serving GANC in order to trigger the inter-RAT handover from GAN.

3. The serving GANC starts the handover preparation by sending a BSSAP: HANDOVER REQUIRED message to the core network.

4. The core network starts the inter-RAT handover procedure towards the target RNC identified by the serving GANC. The core network sends the RANAP: RELOCATION REQUEST message to the target RNC in order to allocate the necessary radio resources.

5. The target RNC assembles information on the allocated UTRAN resources in an RRC: HANDOVER TO UTRAN COMMAND message that is sent to the core network by an RANAP: RELOCATION REQUEST ACKNOWLEDGE message.

6. The core network sends a BSSAP: HANDOVER COMMAND message to the source GANC that contains the RRC: HANDOVER TO UTRAN COMMAND message.

1. GA-CSR UPLINK QUALITY INDICATION

2. GA-CSR HANDOVER INFORMATION

3. Handover Required

4. Relocation Request

6. Handover Command

5. Relocation Request Ack

CNRNCGANCUE

Ongoing GAN connection

7. GA-CSR HANDOVER COMMAND

8. Uu: UL Synchronisation

9. Relocation Detect

11. Uu: Handover to UTRAN Complete

12. Reolocation Complete

10. Voice

14. Clear Command

13. Voice traffic

15. GA-CSR RELEASE16. Cleare Complete

17. GA-CSR RELEASE COMPLETE

18. GA-CSR RELEASE COMPLETE

DN03471612 227



7. The Serving GANC transmits a GA-CSR HANDOVER COMMAND message to the UE that includes the details on the target resource allocation sent by the RNC.

8. The target RNC achieves uplink synchronization on the Uu interface.9. The target RNC confirms the detection of the handover to the core network by

sending an RANAP: RELOCATION DETECT message.10. The core network may now switch the user plane to the target RNC.11. The UE sends an RRC: HANDOVER TO UTRAN COMPLETE message to the RNC.12. The RNC sends an RANAP: RELOCATION COMPLETE message to the core

network. The core network switches the user plane to the target RNC if it has not been switched in step 10.

13. Bi-directional voice traffic is now flowing between the UE and the core network via the UTRAN.

14. The core network sends a BSSAP: CLEAR COMMAND message to the serving GANC in order to release all resources allocated to the UE.

15. The Serving GANC commands the UE to release resources by sending a GA-CSR RELEASE message.

16. The serving GANC sends a BSSAP: CLEAR COMPLETE message to the core network to confirm the release of the resources.

17. The UE confirms the release of the resources by sending the GA-CSR RELEASE COMPLETE message to the Serving GANC.

18. The UE may finally send a GA-CSR DEREGISTER message to de-register from the serving GANC.

228 DN03471612



Description of SRNS relocation

26 Description of SRNS relocationThe SRNS relocation is used for moving the SRNC functionality from one RNC to another RNC closer to the User Equipment (UE) if the UE moves during the communi-cation. Both the radio access network (RAN) and the core network are involved.

This section handles the SRNS relocation procedures while there are dedicated channel resources, that is, radio link(s) allocated for the UE and the handover control algorithm of the serving RNC is controlling the mobility procedures of the RRC connection. Only SRNS relocation procedures in CELL_DCH state are handled here, that is, from a data forwarding point of view. Mobility management during the other RRC states (Cell_FACH, Cell_PCH or URA_PCH) is based on cell reselections performed by the UE and Cell/URA Update procedures. When a Cell/URA Update is received through the Iur interface from the neighboring RNC (DRNC), the RRC entity of the SRNC initiates a SRNS relocation procedure for packet-switched non-real time service (if SRNS relo-cation is supported by the peer elements).

Each RNC is able to control hundreds of BTSs. The vast majority of handovers in the WCDMA domain occurs inside one RNC area, that is, between cells controlled by one RNC, and this way causes no SRNS relocation. On the other hand, in addition to normal intra-WCDMA SRNS relocations, inter-system handovers between WCDMA and GSM can occur.

For detailed information about different handover procedures, see Sections Functional-ity of intra-frequency handover, Functionality of inter-frequency handover, Functionality of inter-system handover and Functionality of inter-frequency handover over Iur in WCDMA RAN RRM Handover Control.

Handovers and SRNS relocationThe main purpose of handovers is to maintain the traffic connection between the UE and the RNC when the UE is moving from the coverage area (cell) of one BTS to that of another BTS. The reason for the handover is that the signal of the new BTS becomes better. Besides pure mobility management concerns, handovers are performed for capacity reasons, that is, to minimise interference.

Regarding the UEs mobility it is really the handovers that count. The SRNS relocation procedures can be seen as a subset for handover procedures: there are handovers without SRNS relocation but no SRNS relocations without handovers.

Since an RNC can have hundreds of BTSs in its area, SRNS relocations are much more infrequent than handovers. On the other hand, a handover is always performed before or during an SRNS relocation. It should be noted, however, that unnecessary reloca-tions can be avoided through smart radio network planning and optimization.

Some evident benefits of SRNS relocation

• Radio resource optimisation is done in the RNC that has the best inputs for the algo-rithms (for example handover decision).

• Transmission route is always optimised - every RNC does not have to be configured as a neighbor RNC for other RNCs.

• Iur interface is not critical: congestion or failure situations do not affect UE mobility since handovers can be done without Iur interface (hard handover)

• Iur interface dimensioning is easier. • Lost calls can be avoided.

DN03471612 229

WCDMA RAN RRM Handover Control Description of SRNS relocation


• Excessive traffic load in hot spot RNCs (for example railway stations, airports and subway stations) can be avoided.

230 DN03471612


Id:0900d8058067f3f2Confidential

Soft handover signaling

27 Soft handover signalingSoft handovers can be intra-RNC or inter-RNC handovers. In other words, soft han-dovers occur between WCDMA BTSs controlled by one RNC or two RNCs. Softer han-dovers occur between cells within one WCDMA BTS. All different types of soft and softer handover have procedures for branch adding, deleting and replacement. In the follow-ing, the procedures are described as they occur in inter-RNC soft handover. In other words, a radio link is set up or added through a WCDMA BTS controlled by another than the serving RNC.

The UE sends the measurement report to the RNC only when it is necessary to add, replace or remove cells from its active set (cells participating in soft handover). The UE sends the measurement report to the RNC in the measurement report message. If the RNC is not able to add the requested cell into the active set, for example, because of capacity reasons, the UE must temporarily proceed to event-triggered periodic mea-surement reporting until the requested cell is either added into the active set or branch addition is not required anymore.

Branch additionThe RNC starts a branch addition procedure if the intra-frequency measurement event 1A is triggered. Branch addition refers to the procedure where the UE adds a new cell to its active set of cells. The UE initiates the branch addition procedure by sending a measurement report message to the RNC on the dedicated control channel (DCCH). One branch addition procedure can simultaneously start several radio link setup and addition procedures, depending on the number of event results in the measurement report.

DN03471612 231

WCDMA RAN RRM Handover Control Soft handover signaling


Figure 64 Branch addition

One radio link setup or addition procedure is required per each WCDMA BTS. For example, if all candidate cells are controlled by different WCDMA BTSs, the number of radio link setup or addition procedures equals the number of measurement event results. The number of radio link setup or addition procedures is one if all candidate cells are controlled by the same WCDMA BTS.

The alternative types of the radio link setup (or addition) procedures are the following:

• Intra-RNC radio link setupThe common NBAP procedure is used when the UE does not have an existing com-munication context in the target BTS.

• Intra-RNC radio link additionThe dedicated NBAP procedure is used when the UE already has an existing com-munication context in the target BTS.

• Inter-RNC radio link setupThe RNSAP procedure is used when the UE does not have any existing diversity handover branches in the drifting RNC.

• Inter-RNC radio link additionThe RNSAP procedure is used when the UE already has one or more existing diver-sity handover branches in the drifting RNC.

One radio link setup or addition procedure can simultaneously set several radio links up. In case of an intra-RNC soft or softer handover, the number of radio links equals the number of candidate cells in a particular WCDMA BTS. In case of an inter-RNC soft han-

ServingRNC

UEDriftingRNC

BTS

RNSAP: RADIO LINK ADDITION REQUEST

BTS-SRNC Data Transport Bearer Sync.

Decision toset up new RL

NBAP: RADIO LINK SETUP REQUEST

NBAP: RADIO LINK SETUP RESPONSE

Start RX

Start TX

RRC: ACTIVE SET UPDATE

(Radio Link Addition)

RRC: ACTIVE SET UPDATE COMPLETE

AAL2 Setup

RNSAP: RADIO LINK ADDITION RESPONSE

232 DN03471612




dover, the number of radio links equals the number of candidate cells in a particular drifting RNC.

The controlling RNC (CRNC) allocates the downlink power, decides on the downlink admission, and allocates the downlink channelisation code (or codes) for the new radio link (or links). It also allocates the identifier of the CRNC communication context. The CRNC communication context contains information on radio links that have been allo-cated from one specified WCDMA BTS for one specified UE. The identifier of the CRNC communication context is unique within one WCDMA BTS.

The RNC sends an active set update message to the UE, which acknowledges receiving the message to the RNC after the radio link or links have been set up.

Branch deletionThe RNC starts a branch deletion procedure if the intra-frequency measurement event 1B is triggered. Branch deletion refers to the procedure where the UE deletes a cell from its active set of cells through which it has an active radio connection. Like branch addi-tion, branch deletion is started by the UE by sending the measurement report message to the RNC on the dedicated control channel (DCCH).

Figure 65 Branch deletion

One branch deletion procedure can simultaneously delete several radio links, depend-ing on the number of event results in the measurement report. In case of an intra-RNC soft or softer handover, one radio link deletion procedure is required per each WCDMA BTS. If all radio links to be deleted are controlled by separate base stations, the number of radio link deletion procedures equals the number of measurement event results. The number of radio link deletion procedures is one if all radio links to be deleted are con-trolled by the same WCDMA BTS.

ServingRNC

UEDriftingRNC

RRC: ACTIVE SET UPDATE

BTS

(Radio Link Deletion)


RNSAP: RADIO LINK DELETION REQUEST

NBAP: RADIO LINK DELETION REQUEST

NBAP: RADIO LINK DELETION RESPONSE

Decision to deleteold RL

Stop RX and TX

AAL2 Release

RNSAP: RADIO LINK DELETION RESPONSE

DN03471612 233

WCDMA RAN RRM Handover Control Soft handover signaling


The RNC sends an active set update message to the UE which acknowledges receiving the message to the RNC. After that, the RNC deletes the radio link or links.

Branch replacementThe RNC starts a branch replacement procedure if the intra-frequency measurement event 1C indicates that a cell is better than an active cell in a full active set. One branch replacement procedure can simultaneously start several radio link setup, addition and deletion procedures, depending on the number of event results in the measurement report. In case of an intra-RNC soft or softer handover, one radio link setup, addition or deletion procedure is required per each WCDMA BTS. For the alternative radio link setup or addition procedures, see the section Branch addition above.

Figure 66 Branch replacement

ServingRNC

UEDriftingRNC

BTSServing RNC

BTSDrifting RNC

NBAP: RADIO LINK SETUP REQUEST


RNSAP: RADIO LINK ADDITION REQUEST

BTS-SRNC Data Transport Bearer Sync.

RRC: ACTIVE SET UPDATE COMMAND

(Radio Link Addition & Deletion)


NBAP: RADIO LINK DELETION

NBAP: RADIO LINK DELETION RESPONSE

Decision to set upnew RL and

release old RL

RNSAP: RADIO LINK ADDITION RESPONSE

Start RX

Start TX

Stop RX and TX

AAL2 Setup

AAL2 Release

234 DN03471612


Id:0900d80580708dc5Confidential

Intra-Frequency hard handover signalling

28 Intra-Frequency hard handover signallingIntra-Frequency hard handover is required to ensure a handover between cells con-trolled by different radio network controllers (RNCs) when an inter-RNC soft handover is not possible, for example, because of Iur congestion. In addition, the Enable Inter-RNC Soft Handover (EnableInterRNCsho) parameter of the intra-frequency handover path defines whether intra-frequency handover from the serving cell to a specified neighbour cell is performed as soft or hard. For more information, see section Function-ality of intra-frequency hard handover.

Intra-Frequency hard handover is non-synchronized hard handover. Non-synchronized intra-frequency hard handover means that the UE replaces all radio links (cells) in the active set with a new radio link (target cell) along with the change in the uplink transmis-sion timing and the confusion message (CFN) according to the system frame number (SFN) of the target cell.

The radio access network application part (RANAP) signalling procedure used is Serving RNC relocation. In this case, the 3G UE is involved in the Serving RNC reloca-tion procedure which makes the procedure a hard handover from the point of view of the UE and the RAN.

The target RNC sets up a radio link on the target cell of the intra-frequency handover. If the radio link setup procedure is successful, the target RNC prepares a hard handover message ('Physical channel reconfiguration', 'Radio bearer establishment', 'Radio bearer reconfiguration', 'Radio bearer release' or 'Transport channel reconfiguration') and sends the content of the RRC message to the source RNC through the CN. The source RNC sends the appropriate RRC (for example, PHYSICAL CHANNEL RECON-FIGURATION) message to the UE, after which the UE stops transmitting and receiving on the old radio links and starts on the new radio link.

It is also possible that there is no RNSAP signalling interface between the source RNC and the target RNC. In that case a RNSAP:RELOCATION COMMIT message is not sent from the source RNC to the target RNC, and a RANAP:RELOCATION DETECTION message is triggered when the target RNC receives a NBAP:SYNCHRONIZATION INDICATION message.

Intra-Frequency inter-RNC hard handovers can be controlled by the mobile services switchinc centre (MSC), the serving GPRS support node (SGSN) or both CNs. The following figure illustrates the MSC-controlled intra-frequency hard handover.

DN03471612 235

WCDMA RAN RRM Handover Control Intra-Frequency hard handover signalling


Figure 67 Intra-Frequency hard handover

CS CNUERNC

TargetRNC

SourceBTS

TargetBTS

Source

NBAP: RADIO LINK SETUP


RRC:MEASUREMENT REPORT

RANAP:RELOCATION REQUIRED

RANAP:RELOCATION REQUEST

AAL2 Setup

AAL2 Setup

RANAP:RELOCATION REQUEST ACKNOWLEDGED

RANAP:RELOCATION COMMAND

AAL2 Release

AAL2 Release

RRC:PHYSICAL CHANNEL RECONFIGURATION

RNSAP:RELOCATION COMMIT

RANAP:RELOCATION DETECTION

NBAP:SYNCHRONIZATION INDICATION

RRC:PHYSICAL CHANNEL RECONFIGURATION COMPLETE

RANAP:RELOCATION COMPLETE

RANAP:IU RELEASE COMMAND

RANAP:IU RELEASE COMPLETE

NBAP:RADIO LINK DELETION

NBAP:RADIO LINK DELETION RESPONSE

RNC switch

L1 synchronisation

236 DN03471612



Serving RNC relocation signaling

29 Serving RNC relocation signalingAs the UE is moving, it may need to take the drifting RNC as the new serving RNC, if there are no more connections needed through the serving RNC. The serving RNC relo-cation procedure is started after the last cell under the SRNC has been deleted from the UE's active set. The serving RNC functionality of a specific RRC connection is relocated from one RNC to another without changing the radio resources or even without interrupt-ing the user data flow.

The following example illustrates the SGSN-controlled serving RNC relocation.

Figure 68 SRNC relocation

GTP Tunnel Setup



HC makes relocationdecision

UE SRNC DRNC PS CN



RANAP:RELOCATION REQUEST ACKNOWLEDGED


RNSAP:SRNC RELOCATION COMMIT


RRC:UTRAN MOBILITY

RRC:UTRAN MOBILITY COMPLETE


Release of GTP tunnels

DN03471612 237

WCDMA RAN RRM Handover Control Compressed mode preparation signaling


30 Compressed mode preparation signalingIn practice signaling in compressed mode is a similar procedure in all handover types.

The following figure illustrates the preparation of compressed mode.

Figure 69 Compressed mode preparation

RNCBTS 1BTS 2UE

Compressed mode preparation procedures

NBAP: RADIOLINK RECONFIGURATIONPREPARE

NBAP: RADIOLINK RECONFIGURATIONREADY

NBAP: RADIOLINK RECONFIGURATIONCOMMIT

RRC: TRANSPORT CHANNEL RECONFIGURATION COMPLETE

RRC: TRANSPORT CHANNEL RECONFIGURATION

238 DN03471612



Inter-Frequency handover signaling

31 Inter-Frequency handover signalingInter-Frequency handovers can be intra-RNC or inter-RNC handovers. Inter-RNC han-dovers can be controlled by the MSC, the SGSN or both CNs.

Inter-Frequency hard handover is non-synchronized hard handover because the UE cannot measure the SFN timing of the target cell before the execution of the handover. The purpose of the non-synchronized inter-frequency hard handover procedure is to replace all radio links (cells) in the active set with a new radio link (target cell) by changing the carrier frequency, the uplink transmission timing and the CFN in the UE according to the SFN of the target cell.

Intra-RNC inter-frequency handoverIn intra-RNC inter-frequency handover, the handover procedure is performed alone by the serving RNC. The serving RNC sets up a radio link on the target cell of the inter-frequency handover. If the radio link setup is successful, the serving RNC prepares a hard handover message ('Physical channel reconfiguration', 'Radio bearer establish-ment', 'Radio bearer reconfiguration', 'Radio bearer release' or 'Transport channel reconfiguration') and sends the RRC message to the UE. The hard handover message contains the information element Timing Indication. The value of the Timing Indication IE is set to 'Initialise' to initiate a non-synchronized hard handover.

The following example illustrates the intra-RNC inter-frequency handover.

DN03471612 239

WCDMA RAN RRM Handover Control Inter-Frequency handover signaling


Figure 70 Intra-RNC inter-frequency handover because of UE transmission power (continued in the next picture)

RNCBTS 1BTS 2UE

1. Activation of the feature.

An inter-frequencyhandover cause byUE Tx power is enabled.

RRC:MEASUREMENT CONTROL (Setup UE Tx power meas)

Reporting event6A is triggered

RRC:MEASUREMENT REPORT (UE Tx power, event 6A)

RRC:MEASUREMENT CONTROL (setup additional intra-freq meas)

NBAP:COMPRESSED MODE COMMAND(CFN, TGPSI)

RRC:MEASUREMENT CONTROL (setup inter-freq,CFN,TGPSI, include additional measurement results)

RRC:MEASUREMENT REPORT (inter-frequency + additional intra-frequency measurement results)

* * *


2. Compressed mode preparation procedures.

3. Activation of compressed mode and inter-frequency measurement.

4. Periodical inter-frequency measurement reporting.

Inter-frequency handoverdecision due to coveragereason; UE Tx power.

5. Inter-frequency intra-RNC handover signalling

Decision to activate inter-frequency measurement.RNC determines CMpattern.

240 DN03471612




Figure 71 Intra-RNC inter-frequency handover because of UE transmission power (continued from the previous picture)

Inter-RNC inter-frequency handoverThe target RNC sets up a radio link on the target cell of the inter-frequency handover. If the radio link setup procedure is successful, the target RNC prepares a hard handover message ('Physical channel reconfiguration', 'Radio bearer establishment', 'Radio bearer reconfiguration', 'Radio bearer release' or 'Transport channel reconfiguration') and sends the content of the RRC message to the source RNC through the CN. The hard handover message contains the Timing Indication information element. The value of the IE Timing Indication is ‘Initialise’ which indicates non-synchronized hard han-dover.

The source RNC sends the appropriate RRC (for example, PHYSICAL CHANNEL RECONFIGURATION) message to the UE, after which the UE stops transmitting and receiving on the old radio links and starts on the new radio link.

The following example illustrates the MSC controlled inter-frequency handover.

RNCBTS 1BTS 2UE

NBAP:RADIOLINK SETUP

NBAP:RADIOLINK SETUP RESPONSE


6. Release of old resources.

L1 Sync

NBAP:SYNCRONIZATION INDICATION

RRC:PHYSICAL CHANNEL RECONF COMPLETE

NBAP:RADIO LINK DELETION REQUEST

NBAP:RADIOLINK DELETION RESPONSE

AAL2 release

DN03471612 241



Figure 72 MSC controlled inter-RNC inter-frequency handover because of CPICH EcNo (quality reason), source RNC (continued in the next picture)

MSCRNCBTS 1UE

1. Activation of the event 1E & 1F in the UE

RRC:MEASUREMENT CONTROL (setup CPICH EcNo events 1E and 1F)

RRC:MEASUREMENT REPORT (CPICH EcNo, event 1F, cell 1)

Decision to activate inter-frequency measurements.Determination of CM pattern.

An inter-frequency handovercause by CPICH EcNo isenabled.

RRC:MEASUREMENT CONTROL ( set additional intra-freq meas)

NBAP:COMPRESSED MODE COMMAND (CFN, TGPSI)

RRC:MEASUREMENT CONTROL (inter-freq, CFN, TGPSI, include additional measurement results)


Inter-frequency handoverdecision due to quality reason;CPICH EcNo

Reporting event 1F triggersfor active set cell 1.

Reporting event 1F triggersfor active set cell 2.

2. Compressed mode preparation procedures.

3. Activation of compressed more and starting of inter-frequency measurement.

4. Periodical inter-frequency measurement reporting and handover decision.

RRC:MEASUREMENT REPORT (CPICH EcNo, event 1F, cell 2)


242 DN03471612




Figure 73 MSC controlled inter-RNC inter-frequency handover because of CPICH EcNo (quality reason), source RNC (continued from the previous picture)

The following example illustrates the SGSN controlled inter-frequency handover.

5. Inter-frequency inter-RNC handover signalling.









AAL2 release

MSCRNCBTS 1UE

DN03471612 243



Figure 74 SGSN controlled inter-RNC inter-frequency handover because of UE transmission power (coverage reason), source RNC (continued in the next picture)

UE Target RNC SGSN


RRC:MEASUREMENT CONTROL (setup UE Tx Power measurement)



2. Compressed mode preparation procedures, TGPSI.

4. Periodical inter-frequency measurement reporting and handover decision.




RRC:TRANSPORT CHANNEL RECONFIGURATION

RNSAP:RELOCATION COMMIT

RRC:MEASUREMENT CONTROL ( setup additional measurement)

COMPRESSED MODE COMMAND (CFN, TGPSI)

RRC:MEASUREMENT CONTROL (inter-freq, CFN, TGPSI, include additional measurement results)

An inter-frequency handovercause by UE Tx power is enabled.

BTS RNC

Decision to activate inter-frequency measurement. RNCdetermines CM pattern.

3. Activation of compressed mode and inter-frequency measurement.

5. Handover signalling

244 DN03471612




Figure 75 SGSN controlled inter-RNC inter-frequency handover because of UE transmission power (coverage reason), source RNC (continued from the previous picture)

Downlink NRT data forwarding from source RNC totarget RNC via Forwarding GTP tunnel




NBAP:RADIOLINK DELETION RESPONSE

AAL2 release

UE Target RNC SGSNBTS RNC


DN03471612 245

WCDMA RAN RRM Handover Control Inter-System handover signaling

Id:0900d8058067f3e8Confidential

32 Inter-System handover signalingThe inter-system handovers can be performed either from WCDMA to GSM system or from GSM to WCDMA system.

The following example illustrates the inter-system handover from WCDMA to GSM.

Figure 76 Inter-System handover from WCDMA to GSM (continued in the next picture)


RRC:MEASUREMENT CONTROL (setup UE Tx power meas)


UE RNCBTS 1 MSC


An inter-system handover causeby UE Tx power is enabled.

Decision to activate inter-systemmeasurement. RNC determinesCM pattern.

2. Compressed mode preparation procedures (TPGSI).

3. Activation of compressed mode and inter-system measurement.

NBAP:COMPRESSED MODE COMMAND (CFN, TGPSI)

RRC:MEASUREMENT CONTROL (GSM RSSI, CFN, TGPSI)

RRC:MEASUREMENT REPORT (GSM RSSI, BCCH ARFCN)

RRC.MEASUREMENT REPORT (GSM RSSI, BCCH ARFCN)

Handover decision,BSIC verification required.

NBAP:COMPRESSED MODE COMMAND (CFN TGPSI)

RRC:MEASUREMENT CONTROL (BSIC,CFN,TGPSI)

RRC:MEASUREMENT REPORT (GSM RSSI, GSM cell index)

5. Inter-system handover signalling

4. Periodic inter-system measurement reporting, BSIC verification and handover decision.

246 DN03471612



Inter-System handover signaling

Figure 77 Inter-System handover from WCDMA to GSM (continued from the previous picture)

The following example illustrates the cell change from WCDMA to GSM/GPRS.

UE MSCRNCBTS 1

1. Activation of the feature

2. Compressed mode preparation procedures (TPGSI)

3. Activation of compressed mode and inter-system measurement

4. Periodic inter-system measurement reporting,BSIC verification and handover decision


RCC:MEASUREMENT CONTROL

(setup UE Tx Power)

RCC:MEASUREMENT REPORT

(UE Tx power, event 6A)


(GSM RSSI, CFN, TGPSI)

RCC:MEASUREMENT REPORT(GSM RSSI, BCCH ARFCN)

NBAP:COMPRESSED MODECOMMAND (CFN, TGPSI)


Decision to activate inter-systemmeasurement. RNC

determines CM pattern


Handover decision,BSIC verification required



(BSICI, CFN, TGPSI)



(GSM RSSI, GSM cell index)

Periodical GSM RSSImeasurement reporting

DN03471612 247



Figure 78 Inter-System cell change from WCDMA to GSM/GPRS (continued in the next picture)

UE SGSNRNCBTS 1

1. Activation of the feature

2. Compressed mode preparation procedures

3. Activation of compressed mode and inter-system measurement

4. Periodic inter-system measurement reporting and handover decision



(setup UE Tx Power)


(UE Tx power, event 6A)


(GSM RSSI, CFN, TGPSI)




Decision to activate inter-systemmeasurement. RNC

determines OM pattern


Periodical GSMRSSI measurement

reporting

Handover decision,BSIC verification not needed.

248 DN03471612




Figure 79 Inter-System cell change from WCDMA to GSM/GPRS (continued from the previous picture)

The following example illustrates the inter-system handover from WCDMA to GSM with CS and PS multi services.

RRC:CELL CHANGE ORDER FROM UTRAN

RANAP:SRNC CONTEXT REQUEST

RANAP: SRNC CONTEXT RESPONSE

RANAP:SRNC DATA FORWARDING COMMAND

Downlink NRT data is returned from sourceRNC back to 2G/3G SGSN via ForwardingGTP tunnel






AAL2 release

SGSNRNCBTS 1UE

DN03471612 249



Figure 80 Inter-System handover from WCDMA to GSM with CS and PS multi services

The following example illustrates the inter-system hard handover from GSM to WCDMA.

SGSNRNCBTS 1UE MSC



RRC:HANDOVER FROM UTRAN COMMAND


RANAPIU RELEASE COMPLETE

RANAP:SRNC CONTEXT REQUEST

RANAP:SRNC CONTEXT RESPONSE

RANAP:SRNC DATA FORWARDING COMMAND

Downlink NRT data is returned from source RNCback to 2G/3G SGSN via Forwarding GTP tunnel





AAL2 release

5. Handover signalling, two CNs

Inter-system handover decision.BSIC verification required.


250 DN03471612




Figure 81 Inter-System hard handover from GSM to WCDMA

MSCRNCBTS 1UE

1. Resource reservation.

NBAP:RADIO LINK SETUP REQUEST


NBAP:RADIO LINK SETUP RESPONSE

AAL2 setup

AAL2 setup

RANAP:RELOCATION REQUEST ACK

L1 Sync

NBAP:SYNCRONIZATION INDICATION


RRC:HANDOVER TO UTRAN COMPLETE


2. Handover signalling

DN03471612 251

WCDMA RAN RRM Handover Control Handover control restrictions


33 Handover control restrictionsHandover control does not support inter-system handovers during anchoring.

The Support for I-HSPA Sharing and Iur Mobility Enhancements feature introduces support for inter-system handover to GSM during anchoring.

For the whole topic summary, see Section Handover control.

252 DN03471612


Id:0900d80580679f11Confidential

Features per release

34 Features per releaseFor an overview of features related to radio resource management see Features per release in WCDMA RAN Radio Resource Management Overview. The features are arranged according to the release in which they were introduced. Note that a feature may belong to more than one functional area.

DN03471612 253

WCDMA RAN RRM Handover Control Management data for handover control

Id:0900d805807e6378Confidential

35 Management data for handover control

35.1 AlarmsActive faults in the system can affect different quality indicators indirectly. Please keep in mind that all faults in the system indicated by alarms should be analyzed. An alarm that indicates that a WBTS, WCEL or RNC functional unit is instable/unavailable can affect indirectly admission control functionality.

For alarm descriptions, see Alarms and BTS Faults in the Nokia Siemens Networks WCDMA RAN System Documentation sets.

All RAN alarms are categorised so that each alarm has an alarm number belonging to one of the following categories:

Alarms triggered by the RNC:

• 1-999 Notices • 1000-1999 Disturbances • 2000-3999 Failure Printouts (*,**,*** alarms)

Alarms triggered by Base Station and RNC:

• 7000-7999 Base Station Alarms • 7401-7699 Base Station Alarms triggered by Base Stations • 7700-7799 Base Station Alarms triggered by RNC

35.1.1 RAN1266: Soft handover based on detected set reportingHandover control sets an RNC-specific alarm if the primary CPICH scrambling code of the cell reported by an intra-frequency measurement matches with more than one intra-frequency neighbor cell. The alarm indicates that at least two cells, which are close to each other, have the same primary CPICH scrambling code specified by the PriScrCode parameter of the WCEL object. The intra-frequency neighbor cells are defined in the ADJS and/or ADJD database objects of the current active set cells.

This alarm indicates that the soft handover success rate may decrease in the RNC. There is only one instance of this alarm active at any time in the RNC. The alarm is sent to NetAct by default. This alarm is not cancelled automatically by the system.

Handover control sets a cell-specific alarm if the primary CPICH scrambling code of the reported cell matches with more than one intra-frequency neighbor cell. The alarm indi-cates that the primary CPICH scrambling code of the cell is duplicated in another cell, and the cells are so close to each other that the possibility of wrong identification and resulting soft handover failure is increased.

The primary CPICH scrambling code of the cell is specified by the PriScrCode parame-ter of the WCEL objet. and the intra-frequency neighbor cells are defined in the ADJS and/or ADJD database objects of the current active set cells.

Alarm name: Conflicting scrambling codes

Alarm number: 3484

254 DN03471612



Management data for handover control

The alarm is set for the cells whose primary CPICH scrambling code equals to the primary CPICH scrambling code of the reported cell. The alarm is cancelled automati-cally after the primary scrambling code of the cell has been modified.

g The alarm is set for the WCDMA cell that is defined as an intra-frequency neighbor in the ADJS and/or ADJD database objects. The alarm is not set for an active set cell or adjacency.

This alarm indicates that the soft handover success rate may decrease in the RNC. The alarm is cell-specific and its indication has been prevented to NetAct by default. Alarm indication preventions can be altered with MML command AFC.

35.2 CountersThis section lists the counters per feature. For more information on the soft and hard handover measurement, see RNC counters - RNW part.

There are no counters related to the following features:

• RAN2.0079: Directed RRC connection setup • RAN1266: Soft handover based on detected set reporting

Please see counters for RAN1191: Detected set reporting and measurements. • RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements • RAN1642: MIMO 2x2 • RAN1906: Dual-cell HSDPA 42 Mbps

Handover statistics in the radio access network (RAN) include the following measure-ment types:

• Soft handover measurement • Intra-System handover (intra- and inter-frequency hard handover) measurement • Inter-System handover measurement

Soft handover measurementSoft handover measurement collects statistics on the cell level and on the network level. Statistics are compiled in the following counters reserved for each traffic type (RT and NRT) and for each cell:

• One...three cells in the active set • Softer handover duration on the SRNC side • Softer handover duration on the DRNC side • Inter-RNC soft handover duration on the SRNC side • Inter-RNC soft handover duration on the DRNC side • Cell addition request • Cell deletion request • Cell replacement request • Cell addition failure • Cell replacement failure • Successful active set updates

Alarm name: Scrambling code conflict

Alarm number: 3485

DN03471612 255



• Unsuccessful active set updates • High UE Rx-Tx time difference • Low UE Rx-Tx time difference

Hard handover measurementHard handover measurement collects statistics on the intra- and inter-frequency hard handover procedure. Statistics are compiled in counters reserved for each traffic type (RT and NRT) and for each cell.

Common hard handover failure counters are:

• UTRAN cannot execute HHO • UE cannot execute HHO • Compressed mode is not possible.

Intra-frequency hard handover counters are:

• Cell addition failure because of SHO incapability • Cell replacement failure because of SHO incapability • HHO attempts caused by SHO incapability • Immediate HHO attempts caused by SHO incapability • Successful hard handovers caused by SHO incapability • Unsuccessful hard handovers caused by SHO incapability • RRC connection drops during HHO caused by SHO incapability.

Inter-frequency hard handover counters per each handover cause are:

• No inter-frequency neighbor cell is good enough for the handover • Inter-frequency handover attempts • Successful inter-frequency hard handovers • Unsuccessful inter-frequency hard handovers • RRC connection drops during inter-frequency hard handover

Measuring the number of HSPA capability based inter-frequency handovers:

• HSCAHO triggered IFHO measurement start attempts • HSCAHO triggered IFHO measurement start failures • Times when no cell good enough was found for HSCAHO • Intra-RNC HSCAHO IFHO attempts • Inter-RNC/I-HSPA HSCAHO IFHO attempts • Successful Intra-RNC HSCAHO IFHOs • Successful Inter-RNC/I-HSPA HSCAHO IFHOs • Failed Intra-RNC HSCAHO IFHOs due to UTRAN • Failed Inter-RNC/I-HSPA HSCAHO IFHOs due to UTRAN • Failed Intra-RNC HSCAHO IFHOs due to UE negative response • Failed Inter-RNC/I-HSPA HSCAHO IFHOs due to UE negative response • Failed Intra-RNC HSCAHO IFHOs due to UE is lost • Failed Inter-RNC/I-HSPA HSCAHO IFHOs due to UE is lost

Hard handover measurement includes statistics also for:

• IMSI-based handover • Load and Service based handover.

256 DN03471612




Inter-System handover measurementInter-system (GSM) handover measurement collects statistics of the performance of the handover from WCDMA to GSM and from WCDMA to GAN. Statisctics are compiled in the following counters reserved for each traffic type (RT and NRT) and for each cell:

Common inter-system handover failure counters:

• GSM BSS cannot execute the inter-system handover • UE cannot execute the inter-system handover • Compressed mode is not possible.

Inter-system handover counters per each handover cause:

• No GSM neighbor cell is good enough for the handover • Inter-system (GSM) handover attempts • Successful inter-system hard handovers • Unsuccessful inter-system hard handovers • RRC connection drops during inter-system hard handover.

Inter-System handover counters to measure the number of inter-system handover can-cellations:

• Number of inter-system HHO measurements cancelled due to CPICH EcNo • Number of inter-system HHO measurements cancelled due to CPICH RSCP • Number of inter-system HHO measurements cancelled due to UE Tx Pwr • Number of inter-system HHO measurements cancelled due to DL DPCH Pwr • Number of inter-system HHO measurements cancelled due to active set update

caused by cell addition • Number of inter-system HHO measurements cancelled due to active set update

caused by cell replacement

Inter-RAT handover counters for handover to GAN:

• Number of inter-RAT handover attempts to GAN • Number of successful inter-RAT handovers to GAN • Number of unsuccessful inter-RAT handovers to GAN • Number of RRC connection drops during inter-RAT handover to GAN

Inter-System Handover measurement includes statistics also for:

• IMSI-based handover • Load and Service based handover • Wireless Priority Service call

For the whole topic summary, see Section Handover control.

35.2.1 RAN1.024: Soft handovers

PI ID Name Abbreviation

M1007C0 ONE CELL IN THE ACTIVE SET FOR RT (SRNC)

ONE_CELL_IN_ACT_SET_FOR_RT

M1007C1 TWO CELLS IN THE ACTIVE SET FOR RT (SRNC)

TWO_CELLS_IN_ACT_SET_FOR_RT

Table 19 Counters for soft handovers

DN03471612 257



M1007C2 THREE CELLS IN THE ACTIVE SET FOR RT (SRNC)

THREE_CELLS_IN_ACT_SET_RT

M1007C3 FOUR CELLS IN THE ACTIVE SET FOR RT (SRNC)

FOUR_CELLS_IN_ACT_SET_FOR_RT

M1007C4 FIVE CELLS IN THE ACTIVE SET FOR RT (SRNC)

FIVE_CELLS_IN_ACT_SET_FOR_RT

M1007C5 SIX CELLS IN THE ACTIVE SET FOR RT (SRNC)

SIX_CELLS_IN_ACT_SET_FOR_RT

M1007C6 SOFTER HANDOVER DURATION ON THE SRNC SIDE FOR RT TRAFFIC

SOFTER_HO_DUR_ON_SRNC_FOR_RT

M1007C7 SOFTER HANDOVER DURATION ON THE DRNC SIDE FOR RT/NRT TRAFFIC

SOFTER_HO_DUR_ON_DRNC_FOR_RT

M1007C8 INTER-RNC SOFT HO DURATION ON THE SRNC SIDE FOR RT TRAFFIC

SOFT_HO_DUR_ON_SRNC_FOR_RT

M1007C9 INTER-RNC SOFT HO DURATION ON THE DRNC SIDE FOR RT/NRT TRAFFIC

SOFT_HO_DUR_ON_DRNC_FOR_RT

M1007C10 CELL ADDITION REQUEST ON SHO FOR RT TRAFFIC

CELL_ADD_REQ_ON_SHO_FOR_RT

M1007C11 CELL DELETION REQUEST ON SHO FOR RT TRAFFIC

CELL_DEL_REQ_ON_SHO_FOR_RT

M1007C12 CELL REPLACEMENT REQUEST ON SHO FOR RT TRAFFIC

CELL_REPL_REQ_ON_SHO_FOR_RT

M1007C13 CELL ADDITION FAILURE ON SHO FOR RT TRAFFIC

CELL_ADD_FAIL_ON_SHO_FOR_RT

M1007C14 CELL REPLACEMENT FAILURE ON SHO FOR RT TRAFFIC

CELL_REPL_FAIL_ON_SHO_FOR_RT

M1007C15 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT TRAFFIC

SUCC_UPDATES_ON_SHO_FOR_RT

M1007C16 UNSUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT TRAFFIC

UNSUCC_UPDATES_ON_SHO_FOR_RT

M1007C17 HIGH UE RX-TX TIME DIFFERENCE FORRT

HIGH_UE_RX_TX_TIME_DIF_RT

M1007C18 LOW UE RX-TX TIME DIFFERENCE FOR RT

LOW_UE_RX_TX_TIME_DIF_FOR_RT

M1007C19 ONE CELL IN THE ACTIVE SET FOR NRT (SRNC)

ONE_CELL_IN_ACT_SET_FOR_NRT

M1007C20 TWO CELLS IN THE ACTIVE SET FOR NRT (SRNC)

TWO_CELLS_IN_ACT_SET_FOR_NRT

M1007C21 THREE CELLS IN THE ACTIVE SET FOR NRT (SRNC)

THREE_CELLS_IN_ACT_SET_NRT

M1007C22 FOUR CELLS IN THE ACTIVE SET FOR NRT (SRNC)

FOUR_CELLS_IN_ACT_SET_NRT


Table 19 Counters for soft handovers (Cont.)

258 DN03471612




35.2.2 RAN1.5010: Inter-frequency handover

M1007C23 FIVE CELLS IN THE ACTIVE SET FOR NRT (SRNC)

FIVE_CELLS_IN_ACT_SET_NRT

M1007C24 SIX CELLS IN THE ACTIVE SET FOR NRT (SRNC)

SIX_CELLS_IN_ACT_SET_FOR_NRT

M1007C25 SOFTER HANDOVER DURATION ON THE SRNC SIDE FOR NRT TRAFFIC

SOFTER_HO_DUR_ON_SRNC_NRT

M1007C26 INTER-RNC SOFT HO DURATION ON THE SRNC SIDE FOR NRT TRAFFIC

SOFT_HO_DUR_ON_SRNC_FOR_NRT

M1007C27 CELL ADDITION REQUEST ON SHO FOR NRT TRAFFIC

CELL_ADD_REQ_ON_SHO_FOR_NRT

M1007C28 CELL DELETION REQUEST ON SHO FOR NRT TRAFFIC

CELL_DEL_REQ_ON_SHO_FOR_NRT

M1007C29 CELL REPLACEMENT REQUEST ON SHO FOR NRT TRAFFIC

CELL_REPL_REQ_ON_SHO_FOR_NRT

M1007C30 CELL ADDITION FAILURE ON SHO FOR NRT TRAFFIC

CELL_ADD_FAIL_ON_SHO_FOR_NRT

M1007C31 CELL REPLACEMENT FAILURE ON SHO FOR NRT TRAFFIC

CELL_REPL_FAIL_ON_SHO_NRT

M1007C32 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR NRT TRAFFIC

SUCC_UPDATES_ON_SHO_FOR_NRT

M1007C33 UNSUCCESSFUL ACTIVE SET UPDATES ON SHO FOR NRT TRAFFIC

UNSUCC_UPDATES_ON_SHO_NRT

M1007C34 HIGH UE RX-TX TIME DIFFERENCE FOR NRT

HIGH_UE_RX_TX_TIME_DIF_NRT

M1007C35 LOW UE RX-TX TIME DIFFERENCE FOR NRT

LOW_UE_RX_TX_TIME_DIF_NRT

M1007C36 CELL DELETION FAILURE ON SHO FOR RT TRAFFIC

CELL_DEL_FAIL_ON_SHO_FOR_RT

M1007C37 CELL DELETION FAILURE ON SHO FOR NRT TRAFFIC

CELL_DEL_FAIL_ON_SHO_FOR_NRT


Table 19 Counters for soft handovers (Cont.)


M1001C217 NUMBER OF INT RNC INTER FREQ HHO ATTEMPTS

INTER_FREQ_HHO_ATTS

M1001C218 NUMBER OF UNSUCCESSFUL INT RNC INTER FREQ HHO ATTEMPTS

INTER_FREQ_HHO_FAILS

M1001C800 RRC ACTIVE REL DUE TO INTER-FREQ HHO

RRC_CONN_ACT_REL_HHO

Table 20 Service level measurements for inter-frequency handovers

DN03471612 259




M1002C355 REQ FOR COM MODE UL TO INT FREQ HHO IN SRNC

REQ_CMOD_UL_IF_HHO_SRNC

M1002C356 REQ FOR COM MODE DL TO INT FREQ HHO IN SRNC

REQ_CMOD_DL_IF_HHO_SRNC

M1002C357 REQ FOR COM MODE UL TO INT SYST HHO IN SRNC

REQ_COM_UL_INT_SYS_HHO_SRNC

M1002C358 REQ FOR COM MODE DL TO INT SYST HHO IN SRNC

REQ_COM_DL_INT_SYS_HHO_SRNC

M1002C359 REQ FOR COM MODE UL REJECT TO INT FREQ HHO IN SRNC

REQ_COM_UL_REJ_FRE_HHO_SRNC

M1002C360 REQ FOR COM MODE DL REJECT TO INT FREQ HHO IN SRNC

REQ_COM_DL_REJ_FRE_HHO_SRNC

M1002C361 REQ FOR COM MODE UL REJECT TO INT SYST HHO IN SRNC

REQ_COM_UL_REJ_SYS_HHO_SRNC

M1002C362 REQ FOR COM MODE DL REJECT TO INT SYST HHO IN SRNC

REQ_COM_DL_REJ_SYS_HHO_SRNC

M1002C625 REJECTED HSDPA IFHO COM-PRESSED MODE

REJ_CM_HSDPA_IFHO

Table 21 Traffic measurements for inter-frequency handovers


M1008C0 UTRAN IS NOT ABLE TO EXECUTE INTRA SYSTEM HHO FOR RT

UTRAN_NOT_ABLE_EXEC_HHO_RT

M1008C1 UE IS NOT ABLE TO EXECUTE INTRA SYSTEM HHO FOR RT

UE_NOT_ABLE_EXEC_HHO_RT

M1008C2 CELL ADDITION FAILURE DUE TO SHO INCAPABILITY FOR RT

CELL_ADD_FAIL_SHO_INCAP_RT

M1008C3 CELL REPLACEMENT FAILURE DUE TO SHO INCAPABILITY FOR RT

CELL_REPL_FAIL_SHO_INCAP_RT

M1008C4 RT HHO ATTEMPTS DUE TO SHO INCAPABILITY AND AVE ECNO

HHO_ATT_CAUSED_SHO_INCAP_RT

M1008C5 RT HHO ATTEMPTS DUE TO SHO INCAPABILITY AND PEAK ECNO

IMMED_HHO_CSD_SHO_INCAP_RT

M1008C6 SUCCESSFUL HARD HANDOVERS CAUSED BY SHO INCAPABILITY FOR RT

SUCC_HHO_CAUSED_SHO_INCAP_RT

M1008C7 UNSUCCESSFUL HARD HANDOVERS CAUSED BY SHO INCAPABILITY FOR RT

UNSUCC_HHO_CSD_SHO_INCAP_RT

M1008C8 RRC CONNECTION DROPS DURING HHO CAUSED BY SHO INCAPABILITY FOR RT

CONN_DROPS_HHO_CSD_INCAP_RT

Table 22 Intra system hard handover measurements for inter-frequency handovers

260 DN03471612




M1008C9 UTRAN IS NOT ABLE TO EXECUTE INTRA SYSTEM HHO FOR NRT

UTRAN_NOT_ABLE_EXEC_HHO_NRT

M1008C10 UE IS NOT ABLE TO EXECUTE INTRA SYSTEM HHO FOR NRT

UE_NOT_ABLE_EXEC_HHO_NRT

M1008C11 CELL ADDITION FAILURE DUE TO SHO IN CAPABILITY FOR NRT

CELL_ADD_FAIL_SHO_INCAP_NRT

M1008C12 CELL REPLACEMENT FAILURE DUE TO SHO INCAPABILITY FOR NRT

CELL_REPL_FAIL_SHO_INCAP_NRT

M1008C13 NRT HHO ATTEMPTS DUE TO SHO INCAPABILITY AND AVE ECNO

HHO_ATT_CAUSED_SHO_INCAP_NRT

M1008C14 NRT HHO ATTEMPTS DUE TO SHO INCAPABILITY AND PEAK ECNO

IMMED_HHO_CSD_SHO_INCAP_NRT

M1008C15 SUCCESSFUL HARD HANDOVERS CAUSED BY SHO INCAPABILITY FOR NRT

SUCC_HHO_SHO_INCAP_NRT

M1008C16 UNSUCCESSFUL HARD HANDOVERS CAUSED BY SHO INCAPABILITY FOR NRT

UNSUCC_HHO_CSD_SHO_INCAP_NRT

M1008C17 RRC CONNECTION DROPS DURING HHO CAUSED BY SHO INCAPABILITY FOR NRT

CONN_DROPS_HHO_CSD_INCAP_NRT

M1008C18 INTER FREQ COMPR MODE START NOT POSSIBLE FOR RT

IF_COM_MOD_STA_NOT_POS_RT

M1008C19 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO UL DCH QUAL FOR RT

IF_HHO_W_CMOD_UL_DCH_Q_RT

M1008C20 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO UE TRX PWR FOR RT

IF_HHO_W_CMOD_UE_TX_PWR_RT

M1008C21 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO DL DPCH PWR FOR RT

IF_HHO_W_CMOD_DL_DPCH_RT

M1008C22 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO CPICH RSCP FOR RT

IF_HHO_W_CMOD_RSCP_RT

M1008C23 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO CPICH ECNO FOR RT

IF_HHO_W_CMOD_CPICH_ECNO_RT

M1008C24 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO UL DCH QUAL FOR RT

IF_HHO_WO_CMOD_UL_DCH_Q_RT

M1008C25 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO UE TRX PWR FOR RT

IF_HHO_WO_CMOD_UE_TRX_RT


Table 22 Intra system hard handover measurements for inter-frequency handovers (Cont.)

DN03471612 261



M1008C26 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO DL DPCH PWR FOR RT

IF_HHO_WO_CMOD_DL_DPCH_RT

M1008C27 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO CPICH RSCP FOR RT

IF_HHO_WO_CMOD_RSCP_RT

M1008C28 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO CPICH ECNO FOR RT

IF_HHO_WO_CMOD_CPICH_ECNO_RT

M1008C29 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO UL DCH QUAL FOR RT

IF_HHO_NO_CELL_UL_DCH_Q_RT

M1008C30 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO UE TRX PWR FOR RT

IF_HHO_NO_CELL_UE_TRX_PWR_RT

M1008C31 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO DL DPCH PWR FOR RT

IF_HHO_NO_CELL_DL_DPCH_RT

M1008C32 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO CPICH RSCP FOR RT

IF_HHO_NO_CELL_CPICH_RCSP_RT

M1008C33 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO CPICH ECNO FOR RT

IF_HHO_NO_CELL_CPICH_ECNO_RT

M1008C34 INTER FREQ HO ATTEMPTS CAUSED BY UL DCH QUAL FOR RT

IF_HHO_ATT_UL_DCH_Q_RT

M1008C35 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY UL DCH QUAL FOR RT

SUCC_IF_HHO_UL_DCH_Q_RT

M1008C36 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY UL DCH QUAL FOR RT

UNSUCC_IF_HHO_UL_DCH_Q_RT

M1008C37 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY UL DCH QUAL FOR RT

CON_DRPS_HHO_UL_DCH_Q_RT

M1008C38 INTER FREQ HO ATTEMPTS CAUSED BY UE TRX PWR FOR RT

IF_HHO_ATT_UE_TRX_PWR_RT

M1008C39 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY UE TRX PWR FOR RT

SUCC_IF_HHO_UE_TRX_PWR_RT

M1008C40 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY UE TRX PWR FOR RT

UNSUCC_IF_HHO_UE_TRX_PWR_RT

M1008C41 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY UE TRX PWR FOR RT

CON_DRPS_IF_HHO_UE_TRX_RT



262 DN03471612




M1008C42 INTER FREQ HO ATTEMPTS CAUSED BY DL DPCH PWR FOR RT

IF_HHO_ATT_DL_DPCH_PWR_RT

M1008C43 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY DL DPCH PWR FOR RT

SUCC_IF_HHO_DL_DPCH_PWR_RT

M1008C44 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY DL DPCH PWR FOR RT

UNSUCC_IF_HHO_DL_DPCH_PWR_RT

M1008C45 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY DL DPCH PWR FOR RT

CON_DRPS_IF_HHO_DL_DPCH_RT

M1008C46 INTER FREQ HO ATTEMPTS CAUSED BY CPICH RSCP FOR RT

IF_HHO_ATT_CPICH_RSCP_RT

M1008C47 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY CPICH RSCP FOR RT

SUCC_IF_HHO_CPICH_RSCP_RT

M1008C48 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY CPICH RSCP FOR RT

UNSUCC_IF_HHO_CPICH_RSCP_RT

M1008C49 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY CPICH RSCP FOR RT

CON_DRPS_IF_HHO_RSCP_RT

M1008C50 INTER FREQ HO ATTEMPTS CAUSED BY CPICH ECNO FOR RT

IF_HHO_ATT_CPICH_ECNO_RT

M1008C51 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY CPICH ECNO FOR RT

SUCC_IF_HHO_CPICH_ECNO_RT

M1008C52 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY CPICH ECNO FOR RT

UNSUCC_IF_HHO_CPICH_ECNO_RT

M1008C53 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY CPICH ECNO FOR RT

CON_DRPS_IF_HHO_ECNO_RT

M1008C54 INTRA RNC INTRA BTS INTER FREQ HO ATTEMPTS FOR RT

INTRA_INTRA_HHO_ATT_RT

M1008C55 SUCCESSFUL INTRA RNC INTRA BTS INTER FREQ HO FOR RT

SUCC_INTRA_INTRA_HHO_ATT_RT

M1008C56 UNSUCCESSFUL INTRA RNC INTRA BTS INTER FREQ HO FOR RT

USUC_INTRA_INTRA_HHO_ATT_RT

M1008C57 RRC CONN DROPS DURING INTRA RNC INTRA BTS INTER FREQ HO FOR RT

CONN_DRPS_HHO_INTRA_INTRA_RT

M1008C58 INTRA RNC INTER BTS INTER FREQ HO ATTEMPTS FOR RT

INTRA_INTER_HHO_ATT_RT

M1008C59 SUCCESSFUL INTRA RNC INTER BTS INTER FREQ HO FOR RT

SUCC_INTRA_INTER_HHO_ATT_RT



DN03471612 263



M1008C60 UNSUCCESSFUL INTRA RNC INTER BTS INTER FREQ HO FOR RT

USUC_INTRA_INTER_HHO_ATT_RT

M1008C61 RRC CONN DROPS DURING INTRA RNC INTER BTS INTER FREQ HO FOR RT

CONN_DRPS_HHO_INTRA_INTER_RT

M1008C62 INTER RNC INTER FREQ HO ATTEMPTS FOR RT

INTER_HHO_ATT_RT

M1008C63 SUCCESSFUL INTER RNC INTER FREQ HO FOR RT

SUCC_INTER_HHO_ATT_RT

M1008C64 UNSUCCESSFUL INTER RNC INTER FREQ HO FOR RT

USUC_INTER_HHO_ATT_RT

M1008C65 RRC CONN DROPS DURING INTER RNC INTER FREQ HO FOR RT

CONN_DRPS_HHO_INTER_RT

M1008C66 INTER FREQ COMPR MODE START NOT POSSIBLE FOR NRT

IF_COM_MOD_STA_NOT_POS_NRT

M1008C67 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO UL DCH QUAL FOR NRT

IF_HHO_W_CMOD_UL_DCH_Q_NRT

M1008C68 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO UE TRX PWR FOR NRT

IF_HHO_W_CMOD_UE_TX_PWR_NRT

M1008C69 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO DL DPCH PWR FOR NRT

IF_HHO_W_CMOD_DL_DPCH_NRT

M1008C70 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO CPICH RSCP FOR NRT

IF_HHO_W_CMOD_CPICH_RSCP_NRT

M1008C71 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO CPICH ECNO FOR NRT

IF_HHO_W_CMOD_CPICH_ECNO_NRT

M1008C72 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO UL DCH QUAL FOR NRT

IF_HHO_WO_CMOD_UL_DCH_Q_NRT

M1008C73 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO UE TRX PWR FOR NRT

IF_HHO_WO_CMOD_UE_TX_NRT

M1008C74 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO DL DPCH PWR FOR NRT

IF_HHO_WO_CMOD_DL_CPCH_NRT

M1008C75 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO CPICH RSCP FOR NRT

IF_HHO_WO_CMOD_RSCP_NRT

M1008C76 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO CPICH ECNO FOR NRT

IF_HHO_WO_CMOD_ECNO_NRT



264 DN03471612




M1008C77 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO UL DCH QUAL FOR NRT

IF_HHO_NO_CELL_UL_DCH_Q_NRT

M1008C78 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO UE TRX PWR FOR NRT

IF_HHO_NO_CELL_UE_TX_PWR_NRT

M1008C79 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO DL DPCH PWR FOR NRT

IF_HHO_NO_CELL_DL_DCPCH_NRT

M1008C80 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO CPICH RSCP FOR NRT

IF_HHO_NOCELL_CPICH_RSCP_NRT

M1008C81 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO CPICH ECNO FOR NRT

IF_HHO_NOCELL_CPICH_ECNO_NRT

M1008C82 INTER FREQ HO ATTEMPTS CAUSED BY UL DCH QUAL FOR NRT

IF_HHO_ATT_UL_DCH_Q_NRT

M1008C83 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY UL DCH QUAL FOR NRT

SUCC_IF_HHO_UL_DCH_Q_NRT

M1008C84 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY UL DCH QUAL FOR NRT

UNSUCC_IF_HHO_UL_DCH_Q_NRT

M1008C85 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY UL DCH QUAL FOR NRT

CON_DRPS_IF_HHO_UL_DCH_Q_NRT

M1008C86 INTER FREQ HO ATTEMPTS CAUSED BY UE TRX PWR FOR NRT

IF_HHO_ATT_UE_TRX_PWR_NRT

M1008C87 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY UE TRX PWR FOR NRT

SUCC_IF_HHO_UE_TRX_PWR_NRT

M1008C88 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY UE TRX PWR FOR NRT

UNSUCC_IF_HHO_UE_TRX_PWR_NRT

M1008C89 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY UE TRX PWR FOR NRT

CON_DRPS_IF_HHO_UE_PWR_NRT

M1008C90 INTER FREQ HO ATTEMPTS CAUSED BY DL DPCH PWR FOR NRT

IF_HHO_ATT_DL_DPCH_PWR_NRT

M1008C91 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY DL DPCH PWR FOR NRT

SUCC_IF_HHO_DL_DPCH_PWR_NRT

M1008C92 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY DL DPCH PWR FOR NRT

UNSUC_IF_HHO_DL_DPCH_PWR_NRT



DN03471612 265



M1008C93 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY DL DPCH PWR FOR NRT

CON_DRPS_IF_HHO_DL_DPCH_NRT

M1008C94 INTER FREQ HO ATTEMPTS CAUSED BY CPICH RSCP FOR NRT

IF_HHO_ATT_CPICH_RSCP_NRT

M1008C95 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY CPICH RSCP FOR NRT

SUCC_IF_HHO_CPICH_RSCP_NRT

M1008C96 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY CPICH RSCP FOR NRT

UNSUCC_IF_HHO_CPICH_RSCP_NRT

M1008C97 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY CPICH RSCP FOR NRT

CON_DRPS_IF_HHO_RSCP_NRT

M1008C98 INTER FREQ HO ATTEMPTS CAUSED BY CPICH ECNO FOR NRT

IF_HHO_ATT_CPICH_ECNO_NRT

M1008C99 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY CPICH ECNO FOR NRT

SUCC_IF_HHO_CPICH_ECNO_NRT

M1008C100 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY CPICH ECNO FOR NRT

UNSUCC_IF_HHO_CPICH_ECNO_NRT

M1008C101 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY CPICH ECNO FOR NRT

CON_DRPS_IF_HHO_ECNO_NRT

M1008C102 INTRA RNC INTRA BTS INTER FREQ HO ATTEMPTS FOR NRT

INTRA_INTRA_HHO_ATT_NRT

M1008C103 SUCCESSFUL INTRA RNC INTRA BTS INTER FREQ HO FOR NRT

SUCC_INTRA_INTRA_HHO_ATT_NRT

M1008C104 UNSUCCESSFUL INTRA RNC INTRA BTS INTER FREQ HO FOR NRT

USUC_INTRA_INTRA_HHO_ATT_NRT

M1008C105 RRC CONN DROPS DURING INTRA RNC INTRA BTS INTER FREQ HO FOR NRT

CON_DRPS_HHO_INTRA_INTRA_NRT

M1008C106 INTRA RNC INTER BTS INTER FREQ HO ATTEMPTS FOR NRT

INTRA_INTER_HHO_ATT_NRT

M1008C107 SUCCESSFUL INTRA RNC INTER BTS INTER FREQ HO FOR NRT

SUCC_INTRA_INTER_HHO_ATT_NRT

M1008C108 UNSUCCESSFUL INTRA RNC INTER BTS INTER FREQ HO FOR NRT

USUC_INTRA_INTER_HHO_ATT_NRT

M1008C109 RRC CONN DROPS DURING INTRA RNC INTER BTS INTER FREQ HO FOR NRT

CON_DRPS_HHO_INTRA_INTER_NRT

M1008C110 INTER RNC INTER FREQ HO ATTEMPTS FOR NRT

INTER_HHO_ATT_NRT



266 DN03471612




M1008C111 SUCCESSFUL INTER RNC INTER FREQ HO FOR NRT

SUCC_INTER_HHO_ATT_NRT

M1008C112 UNSUCCESSFUL INTER RNC INTER FREQ HO FOR NRT

USUC_INTER_HHO_ATT_NRT

M1008C113 RRC CONN DROPS DURING INTER RNC INTER FREQ HO FOR NRT

CON_DRPS_HHO_INTER_NRT

M1008C114 NUMBER OF REJECTED SRNS RELO-CATIONS

NBR_REJ_RELOC

M1008C119 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO IMSI FOR RT

IF_HHO_W_CMOD_IM_IMS_RT

M1008C120 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO IMSI FOR RT

IF_HHO_WO_CMOD_IM_IMS_RT

M1008C121 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO IMSI FOR RT

IF_HHO_NO_CELL_IM_IMS_RT

M1008C126 INTER FREQ HO DECISIONS AFTER COMP MODE MEAS DUE TO IMSI FOR NRT

IF_HHO_W_CMOD_IM_IMS_NRT

M1008C127 INTER FREQ HO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO IMSI FOR NRT

IF_HHO_WO_CMOD_IM_IMS_NRT

M1008C128 NOT STARTED INTER FREQ HHO BEC OF NO CELL GOOD ENOUGH DUE TO IMSI FOR NRT

IF_HHO_NO_CELL_IM_IMS_NRT

M1008C129 LOAD BASED IFHO MEAS WITH COM MOD DUE TO PRXTOTAL FOR RT

IF_HHO_W_CM_LB_PRX_TOT_RT

M1008C130 LOAD BASED IFHO MEAS WITH COM MOD DUE TO PTXTOTAL FOR RT

IF_HHO_W_CM_LB_PTX_TOT_RT

M1008C131 LOAD BASED IFHO MEAS WITH COM MOD DUE TO RESERVATION RATE SC FOR RT

IF_HHO_W_CM_LB_RSVR_SC_RT

M1008C132 LOAD BASED IFHO MEAS WITH COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR RT

IF_HHO_W_CM_LB_RES_LIM_RT

M1008C133 SERVICE BASED IFHO MEAS WITH COM MOD FOR RT

IF_HHO_W_CM_SB_RT

M1008C134 LOAD BASED IFHO MEAS WITH COM MOD DUE TO PRXTOTAL FOR NRT

IF_HHO_W_CM_LB_PRX_TOT_NRT

M1008C135 LOAD BASED IFHO MEAS WITH COM MOD DUE TO PTXTOTAL FOR NRT

IF_HHO_W_CM_LB_PTX_TOT_NRT

M1008C136 LOAD BASED IFHO MEAS WITH COM MOD DUE TO CAPA REJECTION UL FOR NRT

IF_HHO_W_CM_LB_CAPA_UL_NRT



DN03471612 267



M1008C137 LOAD BASED IFHO MEAS WITH COM MOD DUE TO CAPA REJECTION DL FOR NRT

IF_HHO_W_CM_LB_CAPA_DL_NRT

M1008C138 LOAD BASED IFHO MEAS WITH COM MOD DUE TO RESERVATION RATE SC FOR NRT

IF_HHO_W_CM_LB_RSVR_SC_NRT

M1008C139 LOAD BASED IFHO MEAS WITH COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IF_HHO_W_CM_LB_RES_LIM_NRT

M1008C140 SERVICE BASED IFHO MEAS WITH COM MOD FOR NRT

IF_HHO_W_CM_SB_NRT

M1008C141 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO PRXTOTAL FOR RT

IF_HHO_WO_CM_LB_PRX_TOT_RT

M1008C142 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO PTXTOTAL FOR RT

IF_HHO_WO_CM_LB_PTX_TOT_RT

M1008C143 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO RESERVATION RATE SC FOR RT

IF_HHO_WO_CM_LB_RSVR_SC_RT

M1008C144 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR RT

IF_HHO_WO_CM_LB_RES_LIM_RT

M1008C145 SERVICE BASED IFHO MEAS WITHOUT COM MOD FOR RT

IF_HHO_WO_CM_SB_RT

M1008C146 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO PRXTOTAL FOR NRT

IF_HHO_WO_CM_LB_PRX_TOT_NRT

M1008C147 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO PTXTOTAL FOR NRT

IF_HHO_WO_CM_LB_PTX_TOT_NRT

M1008C148 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION UL FOR NRT

IF_HHO_WO_CM_LB_CAPA_UL_NRT

M1008C149 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION DL FOR NRT

IF_HHO_WO_CM_LB_CAPA_DL_NRT

M1008C150 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO RESERVATION RATE SC FOR NRT

IF_HHO_WO_CM_LB_RSVR_SC_NRT

M1008C151 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IF_HHO_WO_CM_LB_RES_LIM_NRT

M1008C152 SERVICE BASED IFHO MEAS WITHOUT COM MOD FOR NRT

IF_HHO_WO_CM_SB_NRT

M1008C153 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO PRXTOTAL FOR RT

IF_HHO_NOCELL_LB_PRX_TOT_RT



268 DN03471612




M1008C154 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO PTXTOTAL FOR RT

IF_HHO_NOCELL_LB_PTX_TOT_RT

M1008C155 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO TO RESERVATION RATE SC FOR RT

IF_HHO_NOCELL_LB_RSVR_SC_RT

M1008C156 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO HW OR LOGICAL RESOURCE LIMIT FOR RT

IF_HHO_NOCELL_LB_RES_LIM_RT

M1008C157 NOT STARTED SERVICE BASED IFHO BECAUSE NO CELL GOOD ENOUGH FOR RT

IF_HHO_NOCELL_SB_RT

M1008C158 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO PRXTOTAL FOR NRT

IF_HHO_NOCELL_LB_PRX_TOT_NRT

M1008C159 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO PTXTOTAL FOR NRT

IF_HHO_NOCELL_LB_PTX_TOT_NRT

M1008C160 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION UL FOR NRT

IF_HHO_NOCELL_LB_CAPA_UL_NRT

M1008C161 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION DL FOR NRT

IF_HHO_NOCELL_LB_CAPA_DL_NRT

M1008C162 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO RESERVATION RATE SC FOR NRT

IF_HHO_NOCELL_LB_RSVR_SC_NRT

M1008C163 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO HW OR LOGICAL RESOURCE LIMIT FOR NRT

IF_HHO_NOCELL_LB_RES_LIM_NRT

M1008C164 NOT STARTED SERVICE BASED IFHO BECAUSE NO CELL GOOD ENOUGH FOR NRT

IF_HHO_NOCELL_SB_NRT

M1008C225 LOAD BASED IFHO MEAS WITH COM MOD DUE TO CAPA REJECTION UL FOR RT

IF_HHO_W_CM_LB_CAPA_UL_RT

M1008C226 LOAD BASED IFHO MEAS WITH COM MOD DUE TO CAPA REJECTION DL FOR RT

IF_HHO_W_CM_LB_CAPA_DL_RT

M1008C227 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION UL FOR RT

IF_HHO_WO_CM_LB_CAPA_UL_RT



DN03471612 269



M1008C228 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION DL FOR RT

IF_HHO_WO_CM_LB_CAPA_DL_RT

M1008C229 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION UL FOR RT

IF_HHO_NOCELL_LB_CAPA_UL_RT

M1008C230 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION DL FOR RT

IF_HHO_NOCELL_LB_CAPA_DL_RT




M1009C116 INTER RNC HHO COMMIT IN SOURCE RNC

INTER_RNC_HHO_SOURCE_RNC

M1009C117 INTER RNC HHO COMMIT IN TARGET RNC

INTER_RNC_HHO_TARGET_RNC

M1009C118 INTER RNC HHO OUT PREP REQ CONTR BY MSC

INTER_RNC_HHO_REQ_CONTR_MSC

M1009C119 INTER RNC HHO OUT PREP REQ CONTR BY SGSN

INTER_RNC_HHO_REQ_CONTR_SGSN

M1009C120 INTER RNC HHO OUT PREP REQ CONTR BY 2CN

INTER_RNC_HHO_OUT_REQ_2CN

M1009C121 INTER RNC HHO OUT PREP SUCC CONTR BY MSC

INTER_RNC_HHO_SUCC_MSC

M1009C122 INTER RNC HHO OUT PREP SUCC CONTR BY SGSN

INTER_RNC_HHO_PREP_SUCC_SGSN

M1009C123 INTER RNC HHO OUT PREP SUCC CONTR BY 2CN

INTER_RNC_HHO_SUCC_2CN

M1009C124 INTER RNC HHO OUT PREP UNSUCC CONTR BY MSC DUE TO RN LAYER CAUSE

INT_RNC_HHO_OUTUS_MSC_RNL

M1009C125 INTER RNC HHO OUT PREP UNSUCC CONTR BY MSC DUE TO TR LAYER CAUSE

INT_RNC_HHO_OUTUS_MSC_TRL

M1009C126 INTER RNC HHO OUT PREP UNSUCC CONTR BY MSC DUE TO NAS CAUSE

INT_RNC_HHO_OUTUS_MSC_NAS

M1009C127 INTER RNC HHO OUT PREP UNSUCC CONTR BY MSC DUE TO PROT CAUSE

INT_RNC_HHO_OUTUS_MSC_PROT

M1009C128 INTER RNC HHO OUT PREP UNSUCC CONTR BY MSC DUE TO MISC CAUSE

INT_RNC_HHO_OUTUS_MSC_MISC

M1009C129 INTER RNC HHO OUT PREP UNSUCC CONTR BY MSC DUE TO NON STAN CAUSE

INT_RNC_HHO_OUTUS_MSC_NST

Table 23 L3 relocation signaling measurements for inter-frequency handovers

270 DN03471612




M1009C130 INTER RNC HHO OUT PREP UNSUCC CONTR BY SGSN DUE TO RN LAYER CAUSE

INT_RNC_HHO_OUTUS_SGSN_RNL

M1009C131 INTER RNC HHO OUT PREP UNSUCC CONTR BY SGSN DUE TO TR LAYER CAUSE

INT_RNC_HHO_OUTUS_SGSN_TRL

M1009C132 INTER RNC HHO OUT PREP UNSUCC CONTR BY SGSN DUE TO NAS CAUSE

INT_RNC_HHO_OUTUS_SGSN_NAS

M1009C133 INTER RNC HHO OUT PREP UNSUCC CONTR BY SGSN DUE TO PROT CAUSE

INT_RNC_HHO_OUTUS_SGSN_PROT

M1009C134 INTER RNC HHO OUT PREP UNSUCC CONTR BY SGSN DUE TO MISC CAUSE

INT_RNC_HHO_OUTUS_SGSN_MISC

M1009C135 INTER RNC HHO OUT PREP UNSUCC CONTR BY SGSN DUE TO NON STAN CAUSE

INT_RNC_HHO_OUTUS_SGSN_NST

M1009C136 INTER RNC HHO OUT PREP UNSUCC CONTR BY 2CN DUE TO RN LAYER CAUSE

INT_RNC_HHO_OUTUS_2CN_RNL

M1009C137 INTER RNC HHO OUT PREP UNSUCC CONTR BY 2CN DUE TO TR LAYER CAUSE

INT_RNC_HHO_OUTUS_2CN_TRL

M1009C138 INTER RNC HHO OUT PREP UNSUCC CONTR BY 2CN DUE TO NAS CAUSE

INT_RNC_HHO_OUTUS_2CN_NAS

M1009C139 INTER RNC HHO OUT PREP UNSUCC CONTR BY 2CN DUE TO PROT CAUSE

INT_RNC_HHO_OUTUS_2CN_PROT

M1009C140 INTER RNC HHO OUT PREP UNSUCC CONTR BY 2CN DUE TO MISC CAUSE

INT_RNC_HHO_OUTUS_2CN_MISC

M1009C141 INTER RNC HHO OUT PREP UNSUCC CONTR BY 2CN DUE TO NON STAN CAUSE

INT_RNC_HHO_OUTUS_2CN_NST

M1009C142 INTER RNC HHO IN PREP REQ CONTR BY MSC

INTER_RNC_HHO_IN_REQ_MSC

M1009C143 INTER RNC HHO IN PREP REQ CONTR BY SGSN

INTER_RNC_HHO_REQ_SGSN

M1009C144 INTER RNC HHO IN PREP REQ CONTR BY 2CN

INTER_RNC_HHO_REQ_2CN

M1009C145 INTER RNC HHO IN PREP SUCC CONTR BY MSC

INTER_RNC_HHO_IN_SUCC_MSC

M1009C146 INTER RNC HHO IN PREP SUCC CONTR BY SGSN

INTER_RNC_HHO_IN_SUCC_SGSN

M1009C147 INTER RNC HHO IN PREP SUCC CONTR BY 2CN

INTER_RNC_HHO_IN_SUCC_2CN


Table 23 L3 relocation signaling measurements for inter-frequency handovers (Cont.)

DN03471612 271



M1009C148 INTER RNC HHO IN PREP UNSUCC CONTR BY MSC DUE TO RN LAYER CAUSE

INT_RNC_HHO_INUS_MSC_RNL

M1009C149 INTER RNC HHO IN PREP UNSUCC CONTR BY MSC DUE TO TR LAYER CAUSE

INT_RNC_HHO_INUS_MSC_TRL

M1009C150 INTER RNC HHO IN PREP UNSUCC CONTR BY MSC DUE TO NAS CAUSE

INT_RNC_HHO_INUS_MSC_NAS

M1009C151 INTER RNC HHO IN PREP UNSUCC CONTR BY MSC DUE TO PROT CAUSE

INT_RNC_HHO_INUS_MSC_PROT

M1009C152 INTER RNC HHO IN PREP UNSUCC CONTR BY MSC DUE TO MISC CAUSE

INT_RNC_HHO_INUS_MSC_MISC

M1009C153 INTER RNC HHO IN PREP UNSUCC CONTR BY MSC DUE TO NON STAN CAUSE

INT_RNC_HHO_INUS_MSC_NST

M1009C154 INTER RNC HHO IN PREP UNSUCC CONTR BY SGSN DUE TO RN LAYER CAUSE

INT_RNC_HHO_INUS_SGSN_RNL

M1009C155 INTER RNC HHO IN PREP UNSUCC CONTR BY SGSN DUE TO TR LAYER CAUSE

INT_RNC_HHO_INUS_SGSN_TRL

M1009C156 INTER RNC HHO IN PREP UNSUCC CONTR BY SGSN DUE TO NAS CAUSE

INT_RNC_HHO_INUS_SGSN_NAS

M1009C157 INTER RNC HHO IN PREP UNSUCC CONTR BY SGSN DUE TO PROT CAUSE

INT_RNC_HHO_INUS_SGSN_PROT

M1009C158 INTER RNC HHO IN PREP UNSUCC CONTR BY SGSN DUE TO MISC CAUSE

INT_RNC_HHO_INUS_SGSN_MISC

M1009C159 INTER RNC HHO IN PREP UNSUCC CONTR BY SGSN DUE TO NON STAN CAUSE

INT_RNC_HHO_INUS_SGSN_NST

M1009C160 INTER RNC HHO IN PREP UNSUCC CONTR BY 2CN DUE TO RN LAYER CAUSE

INT_RNC_HHO_INUS_2CN_RNL

M1009C161 INTER RNC HHO IN PREP UNSUCC CONTR BY 2CN DUE TO TR LAYER CAUSE

INT_RNC_HHO_INUS_2CN_TRL

M1009C162 INTER RNC HHO IN PREP UNSUCC CONTR BY 2CN DUE TO NAS CAUSE

INT_RNC_HHO_INUS_2CN_NAS

M1009C163 INTER RNC HHO IN PREP UNSUCC CONTR BY 2CN DUE TO PROT CAUSE

INT_RNC_HHO_INUS_2CN_PROT

M1009C164 INTER RNC HHO IN PREP UNSUCC CONTR BY 2CN DUE TO MISC CAUSE

INT_RNC_HHO_INUS_2CN_MISC



272 DN03471612




M1009C165 INTER RNC HHO IN PREP UNSUCC CONTR BY 2CN DUE TO NON STAN CAUSE

INT_RNC_HHO_INUS_2CN_NST

M1009C166 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO RN LAYER CAUSE

INT_HHO_CANC_MSC_RNL

M1009C167 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO RELOC OVE TIM EXP

INT_HHO_CANC_MSC_OVE_TIME

M1009C168 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO RELOC PREP TIM EXP

INT_HHO_CANC_MSC_PRP_TIME

M1009C169 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO TR CAUSE

INT_HHO_CANC_MSC_TRL

M1009C170 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO NAS CAUSE

INT_HHO_CANC_MSC_NAS

M1009C171 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO PROT CAUSE

INT_HHO_CANC_MSC_PROT

M1009C172 INTER RNC HHO OUT CANCEL CONTR BYMSC DUE TO MISC CAUSE

INT_HHO_CANC_MSC_MISC

M1009C173 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO NON STAN CAUSE

INT_HHO_CANC_MSC_NONST

M1009C174 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO RN LAYER CAUSE

INT_HHO_CANC_SGSN_RNL

M1009C175 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO RELOC OVE TIM EXP

INT_HHO_CANC_SGSN_OVE_TIME

M1009C176 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO RELOC PREP TIM EXP

INT_HHO_CANC_SGSN_PRP_TIME

M1009C177 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO TR CAUSE

INT_HHO_CANC_SGSN_TRL

M1009C178 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO NAS CAUSE

INT_HHO_CANC_SGSN_NAS

M1009C179 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO PROT CAUSE

INT_HHO_CANC_SGSN_PROT

M1009C180 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO MISC CAUSE

INT_HHO_CANC_SGSN_MISC

M1009C181 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO NON STAN CAUSE

INT_HHO_CANC_SGSN_NONST



DN03471612 273



M1009C182 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO RN LAYER CAUSE

INT_HHO_CANC_2CN_RNL

M1009C183 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO RELOC OVE TIM EXP

INT_HHO_CANC_2CN_OVE_TIME

M1009C184 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO RELOC PREP TIM EXP

INT_HHO_CANC_2CN_PRP_TIME

M1009C185 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO TR CAUSE

INT_HHO_CANC_2CN_TRL

M1009C186 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO NAS CAUSE

INT_HHO_CANC_2CN_NAS

M1009C187 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO PROT CAUSE

INT_HHO_CANC_2CN_PROT

M1009C188 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO MISC CAUSE

INT_HHO_CANC_2CN_MISC

M1009C189 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO NON STAN CAUSE

INT_HHO_CANC_2CN_NONST

M1009C190 INTER HHO DETECT IN TARGET RNC CONTR BY MSC

INTER_HHO_DET_RNC_MSC

M1009C191 INTER HHO DET IN TARGET RNC CONTR BY SGSN

INTER_HHO_DET_IN_RNC_SGSN

M1009C192 INTER HHO DETECT IN TARGET RNC CONTR BY 2CN

INTER_HHO_DET_IN_RNC_2CN

M1009C193 INTER HHO COMPL IN TARGET RNC CONTR BY MSC

INTER_HHO_COMPL_IN_RNC_MSC

M1009C194 INTER HHO COMPL IN TARGET RNC CONTR BY SGSN

INTER_HHO_COMPL_IN_RNC_SGSN

M1009C195 INTER HHO COMPL IN TARGET RNC CONTR BY 2CN

INTER_HHO_COMPL_IN_RNC_2CN

M1009C196 INTER HHO IU REL OUT CONTR BY MSC DUE TO RN LAYER CAUSE

HHO_IU_REL_OUT_MSC_RNL

M1009C197 INTER HHO IU REL OUT CONTR BY MSC DUE TO TR CAUSE

HHO_IU_REL_OUT_MSC_TRL

M1009C198 INTER HHO IU REL OUT CONTR BY MSC DUE TO NAS CAUSE

HHO_IU_REL_OUT_MSC_NAS

M1009C199 INTER HHO IU REL OUT CONTR BY MSC DUE TO PROT CAUSE

HHO_IU_REL_OUT_MSC_PROT

M1009C200 INTER HHO IU REL OUT CONTR BY MSC DUE TO MISC CAUSE

HHO_IU_REL_OUT_MSC_MISC

M1009C201 INTER HHO IU REL OUT CONTR BY MSC DUE TO NON STAN CAUSE

HHO_IU_REL_OUT_MSC_NONST



274 DN03471612




M1009C202 INTER HHO IU REL OUT CONTR BY SGSN DUE TO RN LAYER CAUSE

HHO_IU_REL_OUT_SGSN_RNL

M1009C203 INTER HHO IU REL OUT CONTR BY SGSN DUE TO TR CAUSE

HHO_IU_REL_OUT_SGSN_TRL

M1009C204 INTER HHO IU REL OUT CONTR BY SGSN DUE TO NAS CAUSE

HHO_IU_REL_OUT_SGSN_NAS

M1009C205 INTER HHO IU REL OUT CONTR BY SGSN DUE TO PROT CAUSE

HHO_IU_REL_OUT_SGSN_PROT

M1009C206 INTER HHO IU REL OUT CONTR BY SGSN DUE TO MISC CAUSE

HHO_IU_REL_OUT_SGSN_MISC

M1009C207 INTER HHO IU REL OUT CONTR BY SGSN DUE TO NON STAN CAUSE

HHO_IU_REL_OUT_SGSN_NONST

M1009C208 INTER HHO IU REL OUT CONTR BY 2CN DUE TO RN LAYER CAUSE

HHO_IU_REL_OUT_2CN_RNL

M1009C209 INTER HHO IU REL OUT CONTR BY 2CN DUE TO TR CAUSE

HHO_IU_REL_OUT_2CN_TRL

M1009C210 INTER HHO IU REL OUT CONTR BY 2CN DUE TO NAS CAUSE

HHO_IU_REL_OUT_2CN_NAS

M1009C211 INTER HHO IU REL OUT CONTR BY 2CN DUE TO PROT CAUSE

HHO_IU_REL_OUT_2CN_PROT

M1009C212 INTER HHO IU REL OUT CONTR BY 2CN DUE TO MISC CAUSE

HHO_IU_REL_OUT_2CN_MISC

M1009C213 INTER HHO IU REL OUT CONTR BY 2CN DUE TO NON STAN CAUSE

HHO_IU_REL_OUT_2CN_NONST

M1009C214 INTER HHO IU REL IN CONTR BY MSC DUE TO RN LAYER CAUSE

HHO_IU_REL_IN_MSC_RNL

M1009C215 INTER HHO IU REL IN CONTR BY MSC DUE TO TR CAUSE

HHO_IU_REL_IN_MSC_TRL

M1009C216 INTER HHO IU REL IN CONTR BY MSC DUE TO NAS CAUSE

HHO_IU_REL_IN_MSC_NAS

M1009C217 INTER HHO IU REL IN CONTR BY MSC DUE TO PROT CAUSE

HHO_IU_REL_IN_MSC_PROT

M1009C218 INTER HHO IU REL IN CONTR BY MSC DUE TO MISC CAUSE

HHO_IU_REL_IN_MSC_MISC

M1009C219 INTER HHO IU REL IN CONTR BY MSC DUE TO NON STAN CAUSE

HHO_IU_REL_IN_MSC_NONST

M1009C220 INTER HHO IU REL IN CONTR BY SGSN DUE TO RN LAYER CAUSE

HHO_IU_REL_IN_SGSN_RNL

M1009C221 INTER HHO IU REL IN CONTR BY SGSN DUE TO TR CAUSE

HHO_IU_REL_IN_SGSN_TRL

M1009C222 INTER HHO IU REL IN CONTR BY SGSN DUE TO NAS CAUSE

HHO_IU_REL_IN_SGSN_NAS

M1009C223 INTER HHO IU REL IN CONTR BY SGSN DUE TO PROT CAUSE

HHO_IU_REL_IN_SGSN_PROT



DN03471612 275



M1009C224 INTER HHO IU REL IN CONTR BY SGSN DUE TO MISC CAUSE

HHO_IU_REL_IN_SGSN_MISC

M1009C225 INTER HHO IU REL IN CONTR BY SGSN DUE TO NON STAN CAUSE

HHO_IU_REL_IN_SGSN_NONST

M1009C226 INTER HHO IU REL IN CONTR BY 2CN DUE TO RN LAYER CAUSE

HHO_IU_REL_IN_2CN_RNL

M1009C227 INTER HHO IU REL IN CONTR BY 2CN DUE TO TR CAUSE

HHO_IU_REL_IN_2CN_TRL

M1009C228 INTER HHO IU REL IN CONTR BY 2CN DUE TO NAS CAUSE

HHO_IU_REL_IN_2CN_NAS

M1009C229 INTER HHO IU REL IN CONTR BY 2CN DUE TO PROT CAUSE

HHO_IU_REL_IN_2CN_PROT

M1009C230 INTER HHO IU REL IN CONTR BY 2CN DUE TO MISC CAUSE

HHO_IU_REL_IN_2CN_MISC

M1009C231 INTER HHO IU REL IN CONTR BY 2CN DUE TO NON STAN CAUSE

HHO_IU_REL_IN_2CN_NONST

M1009C233 FORW SRNS CON OUT FORW_SRNS_CON_OUT

M1009C234 FORW SRNS CON IN FORW_SRNS_CON_IN

M1009C235 INTER SYST HHO OUT PREP REQ CONTR BY MSC

IS_HHO_OUT_PREP_REQ

M1009C236 INTER SYST HHO OUT PREP SUCC CONTR BY MSC

IS_HHO_OUT_PREP_SUCC

M1009C237 INTER SYST HHO OUT PREP UNSUCC CONTR BY MSC DUE TO RN LAYER CAUSE

IS_HHO_OUT_PREP_UNSUCC_RNL

M1009C238 INTER SYST HHO PREP UNSUCC CONTR BY MSC DUE TO TR CAUSE

IS_HHO_OUT_PREP_UNSUCC_TRL

M1009C239 INTER SYST HHO OUT PREP UNSUCC CONTR BY MSC DUE TO NAS CAUSE

IS_HHO_OUT_PREP_UNSUCC_NAS

M1009C240 INTER SYST HHO PREP UNSUCC CONTR BY MSC DUE TO PROT CAUSE

IS_HHO_OUT_PREP_UNSUCC_PROT

M1009C241 INTER SYST HHO PREP UNSUCC CONTR BY MSC DUE TO MISC CAUSE

IS_HHO_OUT_PREP_UNSUCC_MISC

M1009C242 INTER SYST HHO PREP UNSUCC CONTR BY MSC DUE TO NON STAN CAUSE

IS_HHO_OUT_PREP_UNSUCC_NONST

M1009C243 INTER SYST HHO IN PREP REQ CONTR BY MSC

IS_HHO_IN_PREP_REQ

M1009C244 INTER SYST HHO IN PREP SUCC CONTR BY MSC

IS_HHO_IN_PREP_SUCC

M1009C245 INTER SYST HHO IN PREP UNSUCC CONTR BY MSC DUE TO RN LAYER CAUSE

IS_HHO_IN_PREP_UNSUCC_RNL



276 DN03471612




M1009C246 INTER SYST HHO IN PREP UNSUCC CONTR BY MSC DUE TO TR CAUSE

IS_HHO_IN_PREP_UNSUCC_TRL

M1009C247 INTER SYST HHO IN PREP UNSUCC CONTR BY MSC DUE TO NAS CAUSE

IS_HHO_IN_PREP_UNSUCC_NAS

M1009C248 INTER SYST HHO IN PREP UNSUCC CONTR BY MSC DUE TO PROT CAUSE

IS_HHO_IN_PREP_UNSUCC_PROT

M1009C249 INTER SYST HHO IN PREP UNSUCC CONTR BY MSC DUE TO MISC CAUSE

IS_HHO_IN_PREP_UNSUCC_MISC

M1009C250 INTER SYST HHO IN PREP UNSUCC CONTR BY MSC DUE TO NON STAN CAUSE

IS_HHO_IN_PREP_UNSUCC_NONST

M1009C251 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO RN LAYER CAUSE

IS_HHO_OUT_CANC_RNL

M1009C252 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO RELOC OVE TIM EXP

IS_HHO_OUT_CANC_OVE_TIME

M1009C253 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO RELOC PREP TIMEXP

IS_HHO_OUT_CANC_PRP_TIME

M1009C254 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO TR CAUSE

IS_HHO_OUT_CANC_TRL

M1009C255 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO NAS CAUSE

IS_HHO_OUT_CANC_NAS

M1009C256 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO PROT CAUSE

IS_HHO_OUT_CANC_PROT

M1009C257 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO MISC CAUSE

IS_HHO_OUT_CANC_MISC

M1009C258 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO NON STAN CAUSE

IS_HHO_OUT_CANC_NONST

M1009C259 INTER SYST COMPL IN TARGET RNC CONTR BY MSC

IS_COMPL_TARGET_RNC

M1009C260 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO RN LAYER CAUSE

IS_HHO_IU_REL_OUT_MSC_RNL

M1009C261 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO TR CAUSE

IS_HHO_IU_REL_OUT_MSC_TRL

M1009C262 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO NAS CAUSE

IS_HHO_IU_REL_OUT_MSC_NAS

M1009C263 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO PROT CAUSE

IS_HHO_IU_REL_OUT_MSC_PROT

M1009C264 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO MISC CAUSE

IS_HHO_IU_REL_OUT_MSC_MISC



DN03471612 277



35.2.3 RAN2.0105: Inter-RNC intra-frequency hard handover

M1009C265 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO NON STAN CAUSE

IS_HHO_IU_REL_OUT_MSC_NONST

M1009C266 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO RN LAYER CAUSE

IS_HHO_IU_REL_IN_MSC_RNL

M1009C267 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO TR CAUSE

IS_HHO_IU_REL_IN_MSC_TRL

M1009C268 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO NAS CAUSE

IS_HHO_IU_REL_IN_MSC_NAS

M1009C269 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO PROT CAUSE

IS_HHO_IU_REL_IN_MSC_PROT

M1009C270 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO MISC CAUSE

IS_HHO_IU_REL_IN_MSC_MISC

M1009C271 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO NON STAN CAUSE

IS_HHO_IU_REL_IN_MSC_NONST

M1009C272 STA FORW DATA IN SOURCE RNC ON IU

STA_FORW_DATA_SRC_RNC_IU

M1009C273 SRNS CON REQ IN SRNS_CON_REQ_IN

M1009C274 SRNS CON RES OUT SRNS_CON_RES_OUT

M1009C275 SRNS DATA FRW COM IN SRNS_DATA_FRW_COM_IN




M1008C2 CELL ADDITION FAILURE DUE TO SHO INCAPABILITY FOR RT

CELL_ADD_FAIL_SHO_INCAP_RT

M1008C3 CELL REPLACEMENT FAILURE DUE TO SHO INCAPABILITY FOR RT

CELL_REPL_FAIL_SHO_INCAP_RT

M1008C4 RT HHO ATTEMPTS DUE TO SHO INCAPABILITY AND AVE ECNO

HHO_ATT_CAUSED_SHO_INCAP_RT

M1008C5 RT HHO ATTEMPTS DUE TO SHO INCAPABILITY AND PEAK ECNO

IMMED_HHO_CSD_SHO_INCAP_RT

M1008C6 SUCCESSFUL HARD HANDOVERS CAUSED BY SHO INCAPABILITY FOR RT

SUCC_HHO_CAUSED_SHO_INCAP_RT

M1008C7 UNSUCCESSFUL HARD HANDOVERS CAUSED BY SHO INCAPABILITY FOR RT

UNSUCC_HHO_CSD_SHO_INCAP_RT

M1008C8 RRC CONNECTION DROPS DURING HHO CAUSED BY SHO INCAPABILITY FOR RT

CONN_DROPS_HHO_CSD_INCAP_RT

M1008C11 CELL ADDITION FAILURE DUE TO SHO IN CAPABILITY FOR NRT

CELL_ADD_FAIL_SHO_INCAP_NRT

Table 24 Inter-RNC intra-frequency hard handover counters

278 DN03471612




35.2.4 RAN1.5009: WCDMA - GSM inter-system handover

M1008C12 CELL REPLACEMENT FAILURE DUE TO SHO INCAPABILITY FOR NRT

CELL_REPL_FAIL_SHO_INCAP_NRT

M1008C13 NRT HHO ATTEMPTS DUE TO SHO INCAPABILITY AND AVE ECNO

HHO_ATT_CAUSED_SHO_INCAP_NRT

M1008C14 NRT HHO ATTEMPTS DUE TO SHO INCAPABILITY AND PEAK ECNO

IMMED_HHO_CSD_SHO_INCAP_NRT

M1008C15 SUCCESSFUL HARD HANDOVERS CAUSED BY SHO INCAPABILITY FOR NRT

SUCC_HHO_SHO_INCAP_NRT

M1008C16 UNSUCCESSFUL HARD HANDOVERS CAUSED BY SHO INCAPABILITY FOR NRT

UNSUCC_HHO_CSD_SHO_INCAP_NRT

M1008C17 RRC CONNECTION DROPS DURING HHO CAUSED BY SHO INCAPABILITY FOR NRT

CONN_DROPS_HHO_CSD_INCAP_NRT


Table 24 Inter-RNC intra-frequency hard handover counters (Cont.)


M1001C803 RRC ACTIVE REL DUE TO ISHO RRC_CONN_ACT_REL_ISHO

Table 25 Service level measurements for WCDMA - GSM inter-system handovers


M1002C355 REQ FOR COM MODE UL TO INT FREQ HHO IN SRNC

REQ_CMOD_UL_IF_HHO_SRNC

M1002C356 REQ FOR COM MODE DL TO INT FREQ HHO IN SRNC

REQ_CMOD_DL_IF_HHO_SRNC

M1002C357 REQ FOR COM MODE UL TO INT SYST HHO IN SRNC

REQ_COM_UL_INT_SYS_HHO_SRNC

M1002C358 REQ FOR COM MODE DL TO INT SYST HHO IN SRNC

REQ_COM_DL_INT_SYS_HHO_SRNC

M1002C359 REQ FOR COM MODE UL REJECT TO INT FREQ HHO IN SRNC

REQ_COM_UL_REJ_FRE_HHO_SRNC

M1002C360 REQ FOR COM MODE DL REJECT TO INT FREQ HHO IN SRNC

REQ_COM_DL_REJ_FRE_HHO_SRNC

M1002C361 REQ FOR COM MODE UL REJECT TO INT SYST HHO IN SRNC

REQ_COM_UL_REJ_SYS_HHO_SRNC

M1002C362 REQ FOR COM MODE DL REJECT TO INT SYST HHO IN SRNC

REQ_COM_DL_REJ_SYS_HHO_SRNC

M1002C363 ALLO FOR COM MODE UL TO INT FREQ HHO IN SRNC

ALLO_COM_UL_FRE_HHO_SRNC

Table 26 Traffic measurements for WCDMA - GSM inter-system handovers

DN03471612 279



M1002C364 ALLO FOR COM MODE DL TO INT FREQ HHO IN SRNC

ALLO_COM_DL_FRE_HHO_SRNC

M1002C365 ALLO DURA FOR COM MODE UL TO INT FREQ HHO IN SRNC

ALLO_DUR_COM_UL_FRE_HHO_SRNC

M1002C366 ALLO DURA FOR COM MODE DL TO INT FREQ HHO IN SRNC

ALLO_DUR_COM_DL_FRE_HHO_SRNC

M1002C367 ALLO FOR COM MODE UL TO INT SYS HHO IN SRNC

ALLO_COM_UL_SYS_HHO_SRNC

M1002C368 ALLO FOR COM MODE DL TO INT SYS HHO IN SRNC

ALLO_COM_DL_SYS_HHO_SRNC

M1002C369 ALLO DURA FOR COM MODE UL TO INT SYS HHO IN SRNC

ALLO_DUR_COM_UL_SYS_HHO_SRNC

M1002C370 ALLO DURA FOR COM MODE DL TO INT SYS HHO IN SRNC

ALLO_DUR_COM_DL_SYS_HHO_SRNC

M1002C377 REQ FOR COM MODE UL IN DRNC REQ_CMOD_UL_DRNC

M1002C378 REQ FOR COM MODE DL IN DRNC REQ_CMOD_DL_DRNC

M1002C379 REQ FOR COM MODE UL REJECT IN DRNC

REQ_CMOD_UL_REJ_DRNC

M1002C380 REQ FOR COM MODE DL REJECT IN DRNC

REQ_CMOD_DL_REJ_DRNC

M1002C381 ALLO FOR COM MODE UL IN DRNC ALLO_CMOD_UL_DRNC

M1002C382 ALLO FOR COM MODE DL IN DRNC ALLO_CMOD_DL_DRNC

M1002C383 ALLO DURA FOR COM MODE UL IN DRNC

ALLO_DURA_CMOD_UL_DRNC

M1002C384 ALLO DURA FOR COM MODE DL IN DRNC

ALLO_DURA_CMOD_DL_DRNC

M1002C433 ALLO FOR COM MODE UL USING SF/2 METHOD IN SRNC

ALLO_COM_UL_SF2_SRNC

M1002C434 ALLO FOR COM MODE DL USING SF/2 METHOD IN SRNC

ALLO_COM_DL_SF2_SRNC

M1002C435 ALLO FOR COM MODE UL USING HLS METHOD IN SRNC

ALLO_COM_UL_HLS_SRNC

M1002C436 ALLO FOR COM MODE DL USING HLS METHOD IN SRNC

ALLO_COM_DL_HLS_SRNC

M1002C437 ALLO DURA FOR COM MODE UL USING SF/2 METHOD IN SRNC

ALLO_DUR_COM_UL_SF2_SRNC

M1002C438 ALLO DURA FOR COM MODE DL USING SF/2 METHOD IN SRNC

ALLO_DUR_COM_DL_SF2_SRNC

M1002C439 ALLO DURA FOR COM MODE UL USING HLS METHOD IN SRNC

ALLO_DUR_COM_UL_HLS_SRNC

M1002C440 ALLO DURA FOR COM MODE DL USING HLS METHOD IN SRNC

ALLO_DUR_COM_DL_HLS_SRNC


Table 26 Traffic measurements for WCDMA - GSM inter-system handovers (Cont.)

280 DN03471612




M1002C441 ALLO FOR COM MODE UL USING SF/2 METHOD IN DRNC

ALLO_COM_UL_SF2_DRNC

M1002C442 ALLO FOR COM MODE DL USING SF/2 METHOD IN DRNC

ALLO_COM_DL_SF2_DRNC

M1002C443 ALLO FOR COM MODE UL USING HLS METHOD IN DRNC

ALLO_COM_UL_HLS_DRNC

M1002C444 ALLO FOR COM MODE DL USING HLS METHOD IN DRNC

ALLO_COM_DL_HLS_DRNC

M1002C445 ALLO FOR COM MODE DL USING PUNCTURING METHOD IN DRNC

ALLO_COM_DL_PUNCT_DRNC

M1002C446 ALLO DURA FOR COM MODE UL USING SF/2 METHOD IN DRNC

ALLO_DUR_COM_UL_SF2_DRNC

M1002C447 ALLO DURA FOR COM MODE DL USING SF/2 METHOD IN DRNC

ALLO_DUR_COM_DL_SF2_DRNC

M1002C448 ALLO DURA FOR COM MODE UL USING HLS METHOD IN DRNC

ALLO_DUR_COM_UL_HLS_DRNC

M1002C449 ALLO DURA FOR COM MODE DL USING HLS METHOD IN DRNC

ALLO_DUR_COM_DL_HLS_DRNC

M1002C450 ALLO DURA FOR COM MODE DL USING PUNCTURING METHOD IN DRNC

ALLO_DUR_COM_DL_PUNCT_DRNC

M1002C623 ALLOCATION FOR HSDPA IFHO COM-PRESSED MODE

ALLO_CM_HSDPA_IFHO

M1002C624 ALLOCATION DURATION FOR HSDPA IFHO COMPRESSED MODE

ALLO_DURA_CM_HSDPA_IFHO


REJ_CM_HSDPA_IFHO


Table 26 Traffic measurements for WCDMA - GSM inter-system handovers (Cont.)


M1006C61 INTER RAT HO FROM UTRAN INTER_RAT_HO_UTRAN

M1006C62 INTER RAT HO FROM UTRAN FAIL INTER_RAT_HO_UTRAN_FAIL

M1006C63 HO FROM UTRAN COM HO_UTRAN_COM

M1006C64 HO FROM UTRAN COM FAIL HO_UTRAN_COM_FAIL

Table 27 RRC signaling measurements for WCDMA - GSM inter-system handovers


M1009C272 STA FORW DATA IN SOURCE RNC ON IU

STA_FORW_DATA_SRC_RNC_IU

M1009C273 SRNS CON REQ IN SRNS_CON_REQ_IN

Table 28 L3 Relocation signaling measurements for WCDMA - GSM inter-system handovers

DN03471612 281



M1009C274 SRNS CON RES OUT SRNS_CON_RES_OUT

M1009C275 SRNS DATA FRW COM IN SRNS_DATA_FRW_COM_IN


Table 28 L3 Relocation signaling measurements for WCDMA - GSM inter-system handovers (Cont.)


M1010C0 UTRAN IS NOT ABLE TO EXECUTE INTER-SYSTEM HHO FOR RT

UTRAN_NOT_ABLE_EXEC_ISHHO_RT

M1010C1 UE IS NOT ABLE TO EXECUTE INTER-SYSTEM HHO FOR RT

UE_NOT_ABLE_EXEC_ISHHO_RT

M1010C2 INTER SYSTEM COMPR MODE START NOT POSSIBLE FOR RT

IS_COM_MOD_STA_NOT_POS_RT

M1010C3 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO UL DCH QUAL FOR RT

IS_HHO_W_CMOD_UL_DCH_Q_RT

M1010C4 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO UE TX PWR FOR RT

IS_HHO_W_CMOD_UE_TX_PWR_RT

M1010C5 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO DL DPCH FOR RT

IS_HHO_W_CMOD_DL_DPCH_RT

M1010C6 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO CPICH RSCP FOR RT

IS_HHO_W_CMOD_CPICH_RSCP_RT

M1010C7 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO CPICH ECNO FOR RT

IS_HHO_W_CMOD_CPICH_ECNO_RT

M1010C8 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO UL DCH QUAL FOR RT

IS_HHO_WO_CMOD_UL_DCH_Q_RT

M1010C9 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO UE TX PWR FOR RT

IS_HHO_WO_CMOD_UE_TX_PWR_RT

M1010C10 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO DL DPCH FOR RT

IS_HHO_WO_CMOD_DL_DPCH_RT

M1010C11 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO CPICH RSCP FOR RT

IS_HHO_WO_CMOD_RSCP_RT

M1010C12 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO CPICH ECNO FOR RT

IS_HHO_WO_CMOD_CPICH_ECNO_RT

M1010C13 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO UL DCH QUAL FOR RT

IS_HHO_NO_CELL_UL_DCH_Q_RT

Table 29 Inter system hard handover measurements for WCDMA - GSM inter-system handovers

282 DN03471612




M1010C14 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO UE TRX PWR FOR RT

IS_HHO_NO_CELL_UE_TRX_PWR_RT

M1010C15 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO DL DPCH FOR RT

IS_HHO_NO_CELL_DL_DPCH_RT

M1010C16 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO CPICH RSCP FOR RT

IS_HHO_NO_CELL_CPICH_RSCP_RT

M1010C17 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO CPICH ECNO FOR RT

IS_HHO_NO_CELL_CPICH_ECNO_RT

M1010C18 INTER SYSTEM HO ATTEMPTS CAUSED BY UL DCH QUAL FOR RT

IS_HHO_ATT_UL_DCH_Q_RT

M1010C19 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY UL DCH QUAL FOR RT

SUCC_IS_HHO_UL_DCH_Q_RT

M1010C20 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY UL DCH QUAL FOR RT

UNSUCC_IS_HHO_UL_DCH_Q_RT

M1010C21 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY UL DCH QUAL FOR RT

CON_DRPS_IS_HHO_UL_DCH_Q_RT

M1010C22 INTER SYSTEM HO ATTEMPTS CAUSED BY UE TRX PWR FOR RT

IS_HHO_ATT_UE_TRX_PWR_RT

M1010C23 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY UE TRX PWR FOR RT

SUCC_IS_HHO_UE_TRX_PWR_RT

M1010C24 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY UE TRX PWR FOR RT

UNSUCC_IS_HHO_UE_TRX_PWR_RT

M1010C25 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY UE TRX PWR FOR RT

CON_DRPS_IS_HHO_UE_PWR_RT

M1010C26 INTER SYSTEM HO ATTEMPTS CAUSED BY DL DPCH PWR FOR RT

IS_HHO_ATT_DPCH_PWR_RT

M1010C27 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY DL DPCH PWR FOR RT

SUCC_IS_HHO_DL_DPCH_PWR_RT

M1010C28 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY DL DPCH PWR FOR RT

UNSUCC_IS_HHO_DL_DPCH_PWR_RT

M1010C29 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY DL DPCH PWR FOR RT

CON_DRPS_IS_HHO_DL_DPCH_RT

M1010C30 INTER SYSTEM HO ATTEMPTS CAUSED BY CPICH RSCP FOR RT

IS_HHO_ATT_CPICH_RSCP_RT


Table 29 Inter system hard handover measurements for WCDMA - GSM inter-system handovers (Cont.)

DN03471612 283



M1010C31 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY CPICH RSCP FOR RT

SUCC_IS_HHO_CPICH_RSCP_RT

M1010C32 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY CPICH RSCP FOR RT

UNSUCC_IS_HHO_CPICH_RSCP_RT

M1010C33 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY CPICH RSCP FOR RT

CON_DRPS_IS_HHO_RSCP_RT

M1010C34 INTER SYSTEM HO ATTEMPTS CAUSED BY CPICH ECNO FOR RT

IS_HHO_ATT_CPICH_ECNO_RT

M1010C35 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY CPICH ECNO FOR RT

SUCC_IS_HHO_CPICH_ECNO_RT

M1010C36 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY CPICH ECNO FOR RT

UNSUCC_IS_HHO_CPICH_ECNO_RT

M1010C37 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY CPICH ECNO FOR RT

CON_DRPS_IS_HHO_ECNO_RT

M1010C38 UTRAN IS NOT ABLE TO EXECUTE INTER-SYSTEM HHO FOR NRT

UTRAN_NOT_ABLE_EXC_ISHHO_NRT

M1010C39 UE IS NOT ABLE TO EXECUTE INTER-SYSTEM HHO FOR NRT

UE_NOT_ABLE_EXEC_ISHHO_NRT

M1010C40 INTER SYSTEM COMPR MODE START NOT POSSIBLE FOR NRT

IS_COM_MOD_STA_NOT_POS_NRT

M1010C41 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO UL DCH QUAL FOR NRT

IS_HHO_W_CMOD_UL_DCH_Q_NRT

M1010C42 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO UE TX PWR FOR NRT

IS_HHO_W_CMOD_UE_TX_PWR_NRT

M1010C43 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO DL DPCH FOR NRT

IS_HHO_W_CMOD_DL_DPCH_NRT

M1010C44 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO CPICH RSCP FOR NRT

IS_HHO_W_CMOD_CPICH_RSCP_NRT

M1010C45 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO CPICH ECNO FOR NRT

IS_HHO_W_CMOD_CPICH_ECNO_NRT

M1010C46 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO UL DCH QUAL FOR NRT

IS_HHO_WO_CMOD_UL_DCH_Q_NRT

M1010C47 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO UE TX PWR FOR NRT

IS_HHO_WO_CMOD_UE_TX_NRT



284 DN03471612




M1010C48 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO DL DPCH FOR NRT

IS_HHO_WO_CMOD_DL_DPCH_NRT

M1010C49 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO CPICH RSCP FOR NRT

IS_HHO_WO_CMOD_RSCP_NRT

M1010C50 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO CPICH ECNO FOR NRT

IS_HHO_WOCMOD_CPICH_ECNO_NRT

M1010C51 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO UL DCH QUAL FOR NRT

IS_HHO_NO_CELL_UL_DCH_Q_NRT

M1010C52 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO UE TX PWR FOR NRT

IS_HHO_NO_CELL_UE_TX_PWR_NRT

M1010C53 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO DL DPCH FOR NRT

IS_HHO_NO_CELL_DL_DPCH_NRT

M1010C54 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO CPICH RSCP FOR NRT

IS_HHO_NOCELL_CPICH_RSCP_NRT

M1010C55 NBR OF NOT STA INTER-SYSTEM HHO BEC OF NO CELL GOOD ENOUGH DUE TO CPICH ECNO FOR NRT

IS_HHO_NOCELL_CPICH_ECNO_NRT

M1010C56 INTER SYSTEM HO ATTEMPTS CAUSED BY UL DCH QUAL FOR NRT

IS_HHO_ATT_UL_DCH_Q_NRT

M1010C57 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY UL DCH QUAL FOR NRT

SUCC_IS_HHO_UL_DCH_Q_NRT

M1010C58 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY UL DCH QUAL FOR NRT

UNSUCC_IS_HHO_UL_DCH_Q_NRT

M1010C59 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY UL DCH QUAL FOR NRT

CON_DRPS_IS_HHO_UL_DCH_Q_NRT

M1010C60 INTER SYSTEM HO ATTEMPTS CAUSED BY UE TRX PWR FOR NRT

IS_HHO_ATT_UE_TRX_PWR_NRT

M1010C61 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY UE TRX PWR FOR NRT

SUCC_IS_HHO_UE_TRX_PWR_NRT

M1010C62 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY UE TRX PWR FOR NRT

UNSUC_IS_HHO_UE_TRX_PWR_NRT

M1010C63 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY UE TRX PWR FOR NRT

CON_DRPS_IS_HHO_TRX_PWR_NRT



DN03471612 285



M1010C64 INTER SYSTEM HO ATTEMPTS CAUSED BY DL DPCH PWR FOR NRT

IS_HHO_ATT_DL_DPCH_PWR_NRT

M1010C65 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY DL DPCH PWR FOR NRT

SUCC_IS_HHO_DL_DPCH_PWR_NRT

M1010C66 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY DL DPCH PWR FOR NRT

UNSUC_IS_HHO_DL_DPCH_PWR_NRT

M1010C67 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY DL DPCH PWR FOR NRT

CON_DRPS_IS_HHO_DL_DPCH_NRT

M1010C68 INTER SYSTEM HO ATTEMPTS CAUSED BY CPICH RSCP FOR NRT

IS_HHO_ATT_CPICH_RSCP_NRT

M1010C69 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY CPICH RSCP FOR NRT

SUCC_IS_HHO_CPICH_RSCP_NRT

M1010C70 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY CPICH RSCP FOR NRT

UNSUCC_IS_HHO_CPICH_RSCP_NRT

M1010C71 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY CPICH RSCP FOR NRT

CON_DRPS_IS_HHO_RSCP_NRT

M1010C72 INTER SYSTEM HO ATTEMPTS CAUSED BY CPICH ECNO FOR NRT

IS_HHO_ATT_CPICH_ECNO_NRT

M1010C73 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY CPICH ECNO FOR NRT

SUCC_IS_HHO_CPICH_ECNO_NRT

M1010C74 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY CPICH ECNO FOR NRT

UNSUCC_IS_HHO_CPICH_ECNO_NRT

M1010C75 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY CPICH ECNO FOR NRT

CON_DRPS_IS_HHO_ECNO_NRT

M1010C80 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE TO IMSI FOR RT

IS_HHO_W_CMOD_IM_IMS_RT

M1010C81 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO IMSI FOR RT

IS_HHO_WO_CMOD_IM_IMS_RT

M1010C82 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO IMSI FOR RT

IS_HHO_NO_CELL_IM_IMS_RT

M1010C87 NBR OF STARTED INTER SYST HHO MEAS WITH COM MOD DUE IMSI FOR NRT

IS_HHO_W_CMOD_IM_IMS_NRT



286 DN03471612




M1010C88 NBR OF STARTED INTER SYST HHO MEAS WITHOUT COM MOD DUE TO IMSI FOR NRT

IS_HHO_WO_CMOD_IM_IMS_NRT

M1010C89 NBR OF NOT STA INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO IMSI FOR NRT

IS_HHO_NO_CELL_IM_IMS_NRT

M1010C94 ISHO DECISIONS AFTER COMP MODE MEAS DUE TO EMERGENCY CALL

IS_HHO_W_CMOD_EMERG_CALL

M1010C95 ISHO DECISIONS AFTER MEAS WITHOUT COMP MODE DUE TO EMERGENCY CALL

IS_HHO_WO_CMOD_EMERG_CALL

M1010C96 NOT STARTED INTER SYST HHO BEC OF NO CELL GOOD ENOUGH DUE TO EMERGENCY CALL

IS_HHO_NO_CELL_EMERG_CALL

M1010C101 LOAD BASED ISHO MEAS WITH COM MOD DUE TO PRXTOTAL FOR RT

IS_HHO_W_CM_LB_PRX_TOT_RT

M1010C102 LOAD BASED ISHO MEAS WITH COM MOD DUE TO PTXTOTAL FOR RT

IS_HHO_W_CM_LB_PTX_TOT_RT

M1010C103 LOAD BASED ISHO MEAS WITH COM MOD DUE TO RESERVATION RATE SC FOR RT

IS_HHO_W_CM_LB_RSVR_SC_RT

M1010C104 LOAD BASED ISHO MEAS WITH COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR RT

IS_HHO_W_CM_LB_RES_LIM_RT

M1010C105 SERVICE BASED ISHO MEAS WITH COM MOD FOR RT

IS_HHO_W_CM_SB_RT

M1010C106 LOAD BASED ISHO MEAS WITH COM MOD DUE TO PRXTOTAL FOR NRT

IS_HHO_W_CM_LB_PRX_TOT_NRT

M1010C107 LOAD BASED ISHO MEAS WITH COM MOD DUE TO PTXTOTAL FOR NRT

IS_HHO_W_CM_LB_PTX_TOT_NRT

M1010C108 LOAD BASED ISHO MEAS WITH COM MOD DUE TO CAPA REJECTION UL FOR NRT

IS_HHO_W_CM_LB_CAPA_UL_NRT

M1010C109 LOAD BASED ISHO MEAS WITH COM MOD DUE TO CAPA REJECTION DL FOR NRT

IS_HHO_W_CM_LB_CAPA_DL_NRT

M1010C110 LOAD BASED ISHO MEAS WITH COM MOD DUE TO RESERVATION RATE SC FOR NRT

IS_HHO_W_CM_LB_RSVR_SC_NRT

M1010C111 LOAD BASED ISHO MEAS WITH COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IS_HHO_W_CM_LB_RES_LIM_NRT

M1010C112 SERVICE BASED ISHO MEAS WITH COM MOD FOR NRT

IS_HHO_W_CM_SB_NRT



DN03471612 287



M1010C113 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO PRXTOTAL FOR RT

IS_HHO_WO_CM_LB_PRX_TOT_RT

M1010C114 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO PTXTOTAL FOR RT

IS_HHO_WO_CM_LB_PTX_TOT_RT

M1010C115 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO RESERVATION RATE SC FOR RT

IS_HHO_WO_CM_LB_RSVR_SC_RT

M1010C116 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR RT

IS_HHO_WO_CM_LB_RES_LIM_RT

M1010C117 SERVICE BASED ISHO MEAS WITHOUT COM MOD FOR RT

IS_HHO_WO_CM_SB_RT

M1010C118 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO PRXTOTAL FOR NRT

IS_HHO_WO_CM_LB_PRX_TOT_NRT

M1010C119 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO PTXTOTAL FOR NRT

IS_HHO_WO_CM_LB_PTX_TOT_NRT

M1010C120 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION UL FOR NRT

IS_HHO_WO_CM_LB_CAPA_UL_NRT

M1010C121 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION DL FOR NRT

IS_HHO_WO_CM_LB_CAPA_DL_NRT

M1010C122 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO RESERVATION RATE SC FOR NRT

IS_HHO_WO_CM_LB_RSVR_SC_NRT

M1010C123 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IS_HHO_WO_CM_LB_RES_LIM_NRT

M1010C124 SERVICE BASED ISHO MEAS WITHOUT COM MOD FOR NRT

IS_HHO_WO_CM_SB_NRT

M1010C125 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO PRXTOTAL FOR RT

IS_HHO_NOCELL_LB_PRX_TOT_RT

M1010C126 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO PTXTOTAL FOR RT

IS_HHO_NOCELL_LB_PTX_TOT_RT

M1010C127 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO TO RESERVATION RATE SC FOR RT

IS_HHO_NOCELL_LB_RSVR_SC_RT

M1010C128 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO HW OR LOGICAL RESOURCE LIMIT FOR RT

IS_HHO_NOCELL_LB_RES_LIM_RT



288 DN03471612




M1010C129 NOT STARTED SERVICE BASED ISHO BECAUSE NO CELL GOOD ENOUGH FOR RT

IS_HHO_NOCELL_SB_RT

M1010C130 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO PRXTOTAL FOR NRT

IS_HHO_NOCELL_LB_PRX_TOT_NRT

M1010C131 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO PTXTOTAL FOR NRT

IS_HHO_NOCELL_LB_PTX_TOT_NRT

M1010C132 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION UL FOR NRT

IS_HHO_NOCELL_LB_CAPA_UL_NRT

M1010C133 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION DL FOR NRT

IS_HHO_NOCELL_LB_CAPA_DL_NRT

M1010C134 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO TO RESERVATION RATE SC FOR NRT

IS_HHO_NOCELL_LB_RSVR_SC_NRT

M1010C135 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO HW OR LOGICAL RESOURCE LIMIT FOR NRT

IS_HHO_NOCELL_LB_RES_LIM_NRT

M1010C136 NOT STARTED SERVICE BASED ISHO BECAUSE NO CELL GOOD ENOUGH FOR NRT

IS_HHO_NOCELL_SB_NRT

M1010C189 LOAD BASED ISHO MEAS WITH COM MOD DUE TO CAPA REJECTION UL FOR RT

IS_HHO_W_CM_LB_CAPA_UL_RT

M1010C190 LOAD BASED ISHO MEAS WITH COM MOD DUE TO CAPA REJECTION DL FOR RT

IS_HHO_W_CM_LB_CAPA_DL_RT

M1010C191 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION UL FOR RT

IS_HHO_WO_CM_LB_CAPA_UL_RT

M1010C192 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION DL FOR RT

IS_HHO_WO_CM_LB_CAPA_DL_RT

M1010C193 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION UL FOR RT

IS_HHO_NOCELL_LB_CAPA_UL_RT

M1010C194 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION DL FOR RT

IS_HHO_NOCELL_LB_CAPA_DL_RT



DN03471612 289



35.2.5 RAN1.5008: GSM - WCDMA inter-system handover

35.2.6 RAN1183: UTRAN - GAN interworking

35.2.7 RAN2.0060: IMSI based handover


M1006C65 RRC HO TO UTRAN COMP RRC_HO_UTRAN_COMP

Table 30 GSM - WCDMA Inter-system handover counters


M1010C219 ATTEMPTED GAN HANDOVERS FOR AMR RT

ATT_GANHO_AMR_RT

M1010C220 SUCCESSFUL GAN HANDOVERS FOR AMR RT

SUCC_GANHO_AMR_RT

M1010C221 UNSUCCESSFUL GAN HANDOVERS FOR AMR RT

UNSUCC_GANHO_AMR_RT

M1010C222 CONNECTION DROPS DURING GAN HANDOVER FOR AMR RT

CON_DRPS_GANHO_AMR_RT

M1001C641 UE SUPPORT FOR GANHO UE_SUPPORT_GANHO

M1001C643 RRC ACTIVE REL DUE TO GANHO RRC_CONN_ACT_REL_GANHO

Table 31 UTRAN - GAN interworking counters


M1008C115 INTER FREQ HO ATTEMPTS CAUSED BY IMSI FOR RT

IF_HHO_ATT_IM_IMS_RT

M1008C116 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY IMSI FOR RT

SUCC_IF_HHO_IM_IMS_RT

M1008C117 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY IMSI FOR RT

UNSUCC_IF_HHO_IM_IMS_RT

M1008C118 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY IMSI FOR RT

CON_DRPS_IF_HHO_IM_IMS_RT

M1008C122 INTER FREQ HO ATTEMPTS CAUSED BY IMSI FOR NRT

IF_HHO_ATT_IM_IMS_NRT

M1008C123 SUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY IMSI FOR NRT

SUCC_IF_HHO_IM_IMS_NRT

M1008C124 UNSUCCESSFUL INTER FREQ HAN-DOVERS CAUSED BY IMSI FOR NRT

UNSUCC_IF_HHO_IM_IMS_NRT

M1008C125 RRC CONNECTION DROPS DURING INTER FREQ HO CAUSED BY IMSI FOR NRT

CON_DRPS_IF_HHO_IM_IMS_NRT

Table 32 IMSI based handover counters

290 DN03471612




35.2.8 RAN140: Load and service based IS/IF handover

M1010C76 INTER SYSTEM HO ATTEMPTS CAUSED BY IMSI FOR RT

IS_HHO_ATT_IM_IMS_RT

M1010C77 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY IMSI FOR RT

SUCC_IS_HHO_IM_IMS_RT

M1010C78 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY IMSI FOR RT

UNSUCC_IS_HHO_IM_IMS_RT

M1010C79 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY IMSI FOR RT

CON_DRPS_IS_HHO_IM_IMS_RT

M1010C83 INTER SYSTEM HO ATTEMPTS CAUSED BY IMSI FOR NRT

IS_HHO_ATT_IM_IMS_NRT

M1010C84 SUCCESSFUL INTER SYSTEM HAN-DOVERS CAUSED BY IMSI FOR NRT

SUCC_IS_HHO_IM_IMS_NRT

M1010C85 UNSUCCESSFUL INTER SYSTEM HANDOVERS CAUSED BY IMSI FOR NRT

UNSUCC_IS_HHO_IM_IMS_NRT

M1010C86 RRC CONNECTION DROPS DURING INTER SYST HO CAUSED BY IMSI FOR NRT

CON_DRPS_IS_HHO_IM_IMS_NRT


Table 32 IMSI based handover counters (Cont.)


M1003C49 SIGN CONN REL BY CN SUCCESS DUE TO NCCR

SIGN_CONN_REL_BY_CN_DUE_NCCR

M1004C113 COMMON MEAS INIT REQUEST IUR ON SRNC

COMMON_MEAS_INI_REQ_IUR_SRNC

M1004C114 COMMON MEAS INIT REQUEST IUR ON DRNC

COMMON_MEAS_INI_REQ_IUR_DRNC

M1004C115 COMMON MEAS INIT RESPONSE IUR ON SRNC

COMMON_MEAS_INI_RES_IUR_SRNC

M1004C116 COMMON MEAS INIT RESPONSE IUR ON DRNC

COMMON_MEAS_INI_RES_IUR_DRNC

M1004C117 COMMON MEAS INIT FAILURES OVER IUR ON SRNC DUE RN LAYER

COMM_MEAS_INI_FAIL_SRNC_RNL

M1004C118 COMMON MEAS INIT FAILURES OVER IUR ON SRNC DUE TR LAYER

COMM_MEAS_INI_FAIL_SRNC_TRL

M1004C119 COMMON MEAS INIT FAILURES OVER IUR ON SRNC DUE PROT

COMM_MEAS_INI_FAIL_SRNC_PROT

M1004C120 COMMON MEAS INIT FAILURES OVER IUR ON SRNC DUE MISC

COMM_MEAS_INI_FAIL_SRNC_MISC

Table 33 L3 signaling at Iur measurements for load and service Based IS/IF handovers

DN03471612 291



M1004C121 COMMON MEAS INIT FAILURES OVER IUR ON DRNC DUE RN LAYER

COMM_MEAS_INI_FAIL_DRNC_RNL

M1004C122 COMMON MEAS INIT FAILURES OVER IUR ON DRNC DUE TR LAYER

COMM_MEAS_INI_FAIL_DRNC_TRL

M1004C123 COMMON MEAS INIT FAILURES OVER IUR ON DRNC DUE PROT

COMM_MEAS_INI_FAIL_DRNC_PROT

M1004C124 COMMON MEAS INIT FAILURES OVER IUR ON DRNC DUE MISC

COMM_MEAS_INI_FAIL_DRNC_MISC

M1004C125 COMMON MEAS REPORTS OVER IUR ON SRNC

COMM_MEAS_REPORT_IUR_SRNC

M1004C126 COMMON MEAS REPORTS OVER IUR ON DRNC

COMM_MEAS_REPORT_IUR_DRNC

M1004C127 COMMON MEAS TERMINATIONS OVER IUR ON SRNC

COMM_MEAS_TERM_IUR_SRNC

M1004C128 COMMON MEAS TERMINATIONS OVER IUR ON DRNC

COMM_MEAS_TERM_IUR_DRNC

M1004C129 COMMON MEAS FAILURE INDICA-TION OVER IUR ON SRNC DUE RN LAYER

COMM_MEAS_FAIL_IND_SRNC_RNL

M1004C130 COMMON MEAS FAILURE INDICA-TION OVER IUR ON SRNC DUE TR LAYER

COMM_MEAS_FAIL_IND_SRNC_TRL

M1004C131 COMMON MEAS FAILURE INDICA-TION OVER IUR ON SRNC DUE PROT

COMM_MEAS_FAIL_IND_SRNC_PROT

M1004C132 COMMON MEAS FAILURE INDICA-TION OVER IUR ON SRNC DUE MISC

COMM_MEAS_FAIL_IND_SRNC_MISC

M1004C133 COMMON MEAS FAILURE INDICA-TION OVER IUR ON DRNC DUE RN LAYER

COMM_MEAS_FAIL_IND_DRNC_RNL

M1004C134 COMMON MEAS FAILURE INDICA-TION OVER IUR ON DRNC DUE TR LAYER

COMM_MEAS_FAIL_IND_DRNC_TRL

M1004C135 COMMON MEAS FAILURE INDICA-TION OVER IUR ON DRNC DUE PROT

COMM_MEAS_FAIL_IND_DRNC_PROT

M1004C136 COMMON MEAS FAILURE INDICA-TION OVER IUR ON DRNC DUE MISC

COMM_MEAS_FAIL_IND_DRNC_MISC


Table 33 L3 signaling at Iur measurements for load and service Based IS/IF handovers (Cont.)


M1006C106 CELL UPDATE ATTEMPT DUE TO NCCR

CELL_UPDATE_ATT_DUE_NCCR

M1006C107 CELL UPDATE SUCCESS DUE TO NCCR

CELL_UPDATE_SUCC_DUE_NCCR

Table 34 RRC signaling measurements for load and service based IS/IF handovers

292 DN03471612




M1006C108 INTER RAT HO FROM UTRAN ATTEMPT DUE TO NCCR

INTER_RAT_HO_UT_ATT_DUE_NCCR


Table 34 RRC signaling measurements for load and service based IS/IF handovers (Cont.)


M1008C129 LOAD BASED IFHO MEAS WITH COM MOD DUE TO PRXTOTAL FOR RT

IF_HHO_W_CM_LB_PRX_TOT_RT

M1008C130 LOAD BASED IFHO MEAS WITH COM MOD DUE TO PTXTOTAL FOR RT

IF_HHO_W_CM_LB_PTX_TOT_RT

M1008C131 LOAD BASED IFHO MEAS WITH COM MOD DUE TO RESERVATION RATE SC FOR RT

IF_HHO_W_CM_LB_RSVR_SC_RT

M1008C132 LOAD BASED IFHO MEAS WITH COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR RT

IF_HHO_W_CM_LB_RES_LIM_RT

M1008C133 SERVICE BASED IFHO MEAS WITH COM MOD FOR RT

IF_HHO_W_CM_SB_RT

M1008C134 LOAD BASED IFHO MEAS WITH COM MOD DUE TO PRXTOTAL FOR NRT

IF_HHO_W_CM_LB_PRX_TOT_NRT

M1008C135 LOAD BASED IFHO MEAS WITH COM MOD DUE TO PTXTOTAL FOR NRT

IF_HHO_W_CM_LB_PTX_TOT_NRT

M1008C136 LOAD BASED IFHO MEAS WITH COM MOD DUE TO CAPA REJECTION UL FOR NRT

IF_HHO_W_CM_LB_CAPA_UL_NRT

M1008C137 LOAD BASED IFHO MEAS WITH COM MOD DUE TO CAPA REJECTION DL FOR NRT

IF_HHO_W_CM_LB_CAPA_DL_NRT

M1008C138 LOAD BASED IFHO MEAS WITH COM MOD DUE TO RESERVATION RATE SC FOR NRT

IF_HHO_W_CM_LB_RSVR_SC_NRT

M1008C139 LOAD BASED IFHO MEAS WITH COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IF_HHO_W_CM_LB_RES_LIM_NRT

M1008C140 SERVICE BASED IFHO MEAS WITH COM MOD FOR NRT

IF_HHO_W_CM_SB_NRT

M1008C141 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO PRXTOTAL FOR RT

IF_HHO_WO_CM_LB_PRX_TOT_RT

M1008C142 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO PTXTOTAL FOR RT

IF_HHO_WO_CM_LB_PTX_TOT_RT

M1008C143 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO RESERVATION RATE SC FOR RT

IF_HHO_WO_CM_LB_RSVR_SC_RT

Table 35 Intra system hard handover measurements for load and service based IS/IF handovers

DN03471612 293



M1008C144 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR RT

IF_HHO_WO_CM_LB_RES_LIM_RT

M1008C145 SERVICE BASED IFHO MEAS WITHOUT COM MOD FOR RT

IF_HHO_WO_CM_SB_RT

M1008C146 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO PRXTOTAL FOR NRT

IF_HHO_WO_CM_LB_PRX_TOT_NRT

M1008C147 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO PTXTOTAL FOR NRT

IF_HHO_WO_CM_LB_PTX_TOT_NRT

M1008C148 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION UL FOR NRT

IF_HHO_WO_CM_LB_CAPA_UL_NRT

M1008C149 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION DL FOR NRT

IF_HHO_WO_CM_LB_CAPA_DL_NRT

M1008C150 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO RESERVATION RATE SC FOR NRT

IF_HHO_WO_CM_LB_RSVR_SC_NRT

M1008C151 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IF_HHO_WO_CM_LB_RES_LIM_NRT

M1008C152 SERVICE BASED IFHO MEAS WITHOUT COM MOD FOR NRT

IF_HHO_WO_CM_SB_NRT

M1008C153 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO PRXTOTAL FOR RT

IF_HHO_NOCELL_LB_PRX_TOT_RT

M1008C154 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO PTXTOTAL FOR RT

IF_HHO_NOCELL_LB_PTX_TOT_RT

M1008C155 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO TO RESERVATION RATE SC FOR RT

IF_HHO_NOCELL_LB_RSVR_SC_RT

M1008C156 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO HW OR LOGICAL RESOURCE LIMIT FOR RT

IF_HHO_NOCELL_LB_RES_LIM_RT

M1008C157 NOT STARTED SERVICE BASED IFHO BECAUSE NO CELL GOOD ENOUGH FOR RT

IF_HHO_NOCELL_SB_RT

M1008C158 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO PRXTOTAL FOR NRT

IF_HHO_NOCELL_LB_PRX_TOT_NRT

M1008C159 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO PTXTOTAL FOR NRT

IF_HHO_NOCELL_LB_PTX_TOT_NRT


Table 35 Intra system hard handover measurements for load and service based IS/IF handovers (Cont.)

294 DN03471612




M1008C160 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION UL FOR NRT

IF_HHO_NOCELL_LB_CAPA_UL_NRT

M1008C161 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION DL FOR NRT

IF_HHO_NOCELL_LB_CAPA_DL_NRT

M1008C162 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO RESERVATION RATE SC FOR NRT

IF_HHO_NOCELL_LB_RSVR_SC_NRT

M1008C163 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO HW OR LOGICAL RESOURCE LIMIT FOR NRT

IF_HHO_NOCELL_LB_RES_LIM_NRT

M1008C164 NOT STARTED SERVICE BASED IFHO BECAUSE NO CELL GOOD ENOUGH FOR NRT

IF_HHO_NOCELL_SB_NRT

M1008C165 LOAD BASED IFHO ATTEMPTS CAUSED BY PRXTOTAL FOR RT

IF_HHO_ATT_LB_PRX_TOT_RT

M1008C166 LOAD BASED IFHO ATTEMPTS CAUSED BY PTXTOTAL FOR RT

IF_HHO_ATT_LB_PTX_TOT_RT

M1008C167 LOAD BASED IFHO ATTEMPTS CAUSED BY RESERVATION RATE SC FOR RT

IF_HHO_ATT_LB_RSVR_SC_RT

M1008C168 LOAD BASED IFHO ATTEMPTS CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR RT

IF_HHO_ATT_LB_RES_LIM_RT

M1008C169 SERVICE BASED IFHO ATTEMPTS FOR RT

IF_HHO_ATT_SB_RT

M1008C170 LOAD BASED IFHO ATTEMPTS CAUSED BY PRXTOTAL FOR NRT

IF_HHO_ATT_LB_PRX_TOT_NRT

M1008C171 LOAD BASED IFHO ATTEMPTS CAUSED BY PTXTOTAL FOR NRT

IF_HHO_ATT_LB_PTX_TOT_NRT

M1008C172 LOAD BASED IFHO ATTEMPTS CAUSED BY CAPA REJECTION UL FOR NRT

IF_HHO_ATT_LB_CAPA_UL_NRT

M1008C173 LOAD BASED IFHO ATTEMPTS CAUSED BY CAPA REJECTION DL FOR NRT

IF_HHO_ATT_LB_CAPA_DL_NRT

M1008C174 LOAD BASED IFHO ATTEMPTS CAUSED BY RESERVATION RATE SC FOR NRT

IF_HHO_ATT_LB_RSVR_SC_NRT

M1008C175 LOAD BASED IFHO ATTEMPTS CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IF_HHO_ATT_LB_RES_LIM_NRT



DN03471612 295



M1008C176 SERVICE BASED IFHO ATTEMPTS FOR NRT

IF_HHO_ATT_SB_NRT

M1008C177 SUCCESSFUL LOAD BASED IFHO CAUSED BY PRXTOTAL FOR RT

SUCC_IF_HHO_LB_PRX_TOT_RT

M1008C178 SUCCESSFUL LOAD BASED IFHO CAUSED BY PTXTOTAL FOR RT

SUCC_IF_HHO_LB_PTX_TOT_RT

M1008C179 SUCCESSFUL IFHO CAUSED BY RES-ERVATION RATE SC FOR RT

SUCC_IF_HHO_LB_RSVR_SC_RT

M1008C180 SUCCESSFUL IFHO CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR RT

SUCC_IF_HHO_LB_RES_LIM_RT

M1008C181 SUCCESSFUL SERVICE BASED IFHO FOR RT

SUCC_IF_HHO_SB_RT

M1008C182 SUCCESSFUL LOAD BASED IFHO CAUSED BY PRXTOTAL FOR NRT

SUCC_IF_HHO_LB_PRX_TOT_NRT

M1008C183 SUCCESSFUL LOAD BASED IFHO CAUSED BY PTXTOTAL FOR NRT

SUCC_IF_HHO_LB_PTX_TOT_NRT

M1008C184 SUCCESSFUL IFHO CAUSED BY CAPA REJECTION UL FOR NRT

SUCC_IF_HHO_LB_CAPA_UL_NRT

M1008C185 SUCCESSFUL IFHO CAUSED BY CAPA REJECTION DL FOR NRT

SUCC_IF_HHO_LB_CAPA_DL_NRT

M1008C186 SUCCESSFUL IFHO CAUSED BY RES-ERVATION RATE SC FOR NRT

SUCC_IF_HHO_LB_RSVR_SC_NRT

M1008C187 SUCCESSFUL IFHO CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR NRT

SUCC_IF_HHO_LB_RES_LIM_NRT

M1008C188 SUCCESSFUL SERVICE BASED IFHO FOR NRT

SUCC_IF_HHO_SB_NRT

M1008C189 UNSUCCESSFUL LOAD BASED IFHO CAUSED BY PRXTOTAL FOR RT

UNSUCC_IF_HHO_LB_PRX_TOT_RT

M1008C190 UNSUCCESSFUL LOAD BASED IFHO CAUSED BY PTXTOTAL FOR RT

UNSUCC_IF_HHO_LB_PTX_TOT_RT

M1008C191 UNSUCCESSFUL IFHO CAUSED BY RESERVATION RATE SC FOR RT

UNSUCC_IF_HHO_LB_RSVR_SC_RT

M1008C192 UNSUCCESSFUL IFHO CAUSED BY HW OR LOGICAL RESOURCE LIMITA-TION FOR RT

UNSUCC_IF_HHO_LB_RES_LIM_RT

M1008C193 UNSUCCESSFUL SERVICE BASED IFHO FOR RT

UNSUCC_IF_HHO_SB_RT

M1008C194 UNSUCCESSFUL LOAD BASED IFHO CAUSED BY PRXTOTAL FOR NRT

UNSUCC_IF_HHO_LB_PRX_TOT_NRT

M1008C195 UNSUCCESSFUL LOAD BASED IFHO CAUSED BY PTXTOTAL FOR NRT

UNSUCC_IF_HHO_LB_PTX_TOT_NRT

M1008C196 UNSUCCESSFUL IFHO CAUSED BY CAPA REJECTION UL FOR NRT

UNSUCC_IF_HHO_LB_CAPA_UL_NRT



296 DN03471612




M1008C197 UNSUCCESSFUL IFHO CAUSED BY CAPA REJECTION DL FOR NRT

UNSUCC_IF_HHO_LB_CAPA_DL_NRT

M1008C198 UNSUCCESSFUL IFHO CAUSED BY RESERVATION RATE SC FOR NRT

UNSUCC_IF_HHO_LB_RSVR_SC_NRT

M1008C199 UNSUCCESSFUL IFHO CAUSED BY HW OR LOGICAL RESOURCE LIMITA-TION FOR NRT

UNSUCC_IF_HHO_LB_RES_LIM_NRT

M1008C200 UNSUCCESSFUL SERVICE BASED IFHO FOR NRT

UNSUCC_IF_HHO_SB_NRT

M1008C201 RRC CONNECTION DROPS DURING LOAD BASED IFHO CAUSED BY PRXTOTAL FOR RT

CONDR_IF_HHO_LB_PRX_TOT_RT

M1008C202 RRC CONNECTION DROPS DURING LOAD BASED IFHO CAUSED BY PTXTOTAL FOR RT

CONDR_IF_HHO_LB_PTX_TOT_RT

M1008C203 RRC CONNECTION DROPS DURING IFHO CAUSED BY RESERVATION RATE SC FOR RT

CONDR_IF_HHO_LB_RSVR_SC_RT

M1008C204 RRC CONNECTION DROPS DURING IFHO CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR RT

CONDR_IF_HHO_LB_RES_LIM_RT

M1008C205 RRC CONNECTION DROPS DURING SERVICE BASED IFHO FOR RT

CONDR_IF_HHO_SB_RT

M1008C206 RRC CONNECTION DROPS DURING LOAD BASED IFHO CAUSED BY PRXTOTAL FOR NRT

CONDR_IF_HHO_LB_PRX_TOT_NRT

M1008C207 RRC CONNECTION DROPS DURING LOAD BASED IFHO CAUSED BY PTXTOTAL FOR NRT

CONDR_IF_HHO_LB_PTX_TOT_NRT

M1008C208 RRC CONNECTION DROPS IFHO CAUSED BY CAPA REJECTION UL FOR NRT

CONDR_IF_HHO_LB_CAPA_UL_NRT

M1008C209 RRC CONNECTION DROPS IFHO CAUSED BY CAPA REJECTION DL FOR NRT

CONDR_IF_HHO_LB_CAPA_DL_NRT

M1008C210 RRC CONNECTION DROPS DURING IFHO CAUSED BY RESERVATION RATE SC FOR NRT

CONDR_IF_HHO_LB_RSVR_SC_NRT

M1008C211 RRC CONNECTION DROPS DURING IFHO CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR NRT

CONDR_IF_HHO_LB_RES_LIM_NRT

M1008C212 RRC CONNECTION DROPS DURING SERVICE BASED IFHO FOR NRT

CONDR_IF_HHO_SB_NRT

M1008C225 LOAD BASED IFHO MEAS WITH COM MOD DUE TO CAPA REJECTION UL FOR RT

IF_HHO_W_CM_LB_CAPA_UL_RT



DN03471612 297



M1008C226 LOAD BASED IFHO MEAS WITH COM MOD DUE TO CAPA REJECTION DL FOR RT

IF_HHO_W_CM_LB_CAPA_DL_RT

M1008C227 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION UL FOR RT

IF_HHO_WO_CM_LB_CAPA_UL_RT

M1008C228 LOAD BASED IFHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION DL FOR RT

IF_HHO_WO_CM_LB_CAPA_DL_RT

M1008C229 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION UL FOR RT

IF_HHO_NOCELL_LB_CAPA_UL_RT

M1008C230 NOT STARTED LOAD BASED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION DL FOR RT

IF_HHO_NOCELL_LB_CAPA_DL_RT

M1008C231 LOAD BASED IFHO ATTEMPTS CAUSED BY CAPA REJECTION UL FOR RT

IF_HHO_ATT_LB_CAPA_UL_RT

M1008C232 LOAD BASED IFHO ATTEMPTS CAUSED BY CAPA REJECTION DL FOR RT

IF_HHO_ATT_LB_CAPA_DL_RT

M1008C233 SUCCESSFUL IFHO CAUSED BY CAPA REJECTION UL FOR RT

SUCC_IF_HHO_LB_CAPA_UL_RT

M1008C234 SUCCESSFUL IFHO CAUSED BY CAPA REJECTION DL FOR RT

SUCC_IF_HHO_LB_CAPA_DL_RT

M1008C235 UNSUCCESSFUL IFHO CAUSED BY CAPA REJECTION UL FOR RT

UNSUCC_IF_HHO_LB_CAPA_UL_RT

M1008C236 UNSUCCESSFUL IFHO CAUSED BY CAPA REJECTION DL FOR RT

UNSUCC_IF_HHO_LB_CAPA_DL_RT

M1008C237 RRC CONNECTION DROPS IFHO CAUSED BY CAPA REJECTION UL FOR RT

CONDR_IF_HHO_LB_CAPA_UL_RT

M1008C238 RRC CONNECTION DROPS IFHO CAUSED BY CAPA REJECTION DL FOR RT

CONDR_IF_HHO_LB_CAPA_DL_RT




M1010C101 LOAD BASED ISHO MEAS WITH COM MOD DUE TO PRXTOTAL FOR RT

IS_HHO_W_CM_LB_PRX_TOT_RT

M1010C102 LOAD BASED ISHO MEAS WITH COM MOD DUE TO PTXTOTAL FOR RT

IS_HHO_W_CM_LB_PTX_TOT_RT

M1010C103 LOAD BASED ISHO MEAS WITH COM MOD DUE TO RESERVATION RATE SC FOR RT

IS_HHO_W_CM_LB_RSVR_SC_RT

Table 36 Inter system hard handover measurements for load and service based IS/IF handovers

298 DN03471612




M1010C104 LOAD BASED ISHO MEAS WITH COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR RT

IS_HHO_W_CM_LB_RES_LIM_RT

M1010C105 SERVICE BASED ISHO MEAS WITH COM MOD FOR RT

IS_HHO_W_CM_SB_RT

M1010C106 LOAD BASED ISHO MEAS WITH COM MOD DUE TO PRXTOTAL FOR NRT

IS_HHO_W_CM_LB_PRX_TOT_NRT

M1010C107 LOAD BASED ISHO MEAS WITH COM MOD DUE TO PTXTOTAL FOR NRT

IS_HHO_W_CM_LB_PTX_TOT_NRT

M1010C108 LOAD BASED ISHO MEAS WITH COM MOD DUE TO CAPA REJECTION UL FOR NRT

IS_HHO_W_CM_LB_CAPA_UL_NRT

M1010C109 LOAD BASED ISHO MEAS WITH COM MOD DUE TO CAPA REJECTION DL FOR NRT

IS_HHO_W_CM_LB_CAPA_DL_NRT

M1010C110 LOAD BASED ISHO MEAS WITH COM MOD DUE TO RESERVATION RATE SC FOR NRT

IS_HHO_W_CM_LB_RSVR_SC_NRT

M1010C111 LOAD BASED ISHO MEAS WITH COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IS_HHO_W_CM_LB_RES_LIM_NRT

M1010C112 SERVICE BASED ISHO MEAS WITH COM MOD FOR NRT

IS_HHO_W_CM_SB_NRT

M1010C113 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO PRXTOTAL FOR RT

IS_HHO_WO_CM_LB_PRX_TOT_RT

M1010C114 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO PTXTOTAL FOR RT

IS_HHO_WO_CM_LB_PTX_TOT_RT

M1010C115 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO RESERVATION RATE SC FOR RT

IS_HHO_WO_CM_LB_RSVR_SC_RT

M1010C116 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR RT

IS_HHO_WO_CM_LB_RES_LIM_RT

M1010C117 SERVICE BASED ISHO MEAS WITHOUT COM MOD FOR RT

IS_HHO_WO_CM_SB_RT

M1010C118 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO PRXTOTAL FOR NRT

IS_HHO_WO_CM_LB_PRX_TOT_NRT

M1010C119 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO PTXTOTAL FOR NRT

IS_HHO_WO_CM_LB_PTX_TOT_NRT

M1010C120 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION UL FOR NRT

IS_HHO_WO_CM_LB_CAPA_UL_NRT


Table 36 Inter system hard handover measurements for load and service based IS/IF handovers (Cont.)

DN03471612 299



M1010C121 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION DL FOR NRT

IS_HHO_WO_CM_LB_CAPA_DL_NRT

M1010C122 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO RESERVATION RATE SC FOR NRT

IS_HHO_WO_CM_LB_RSVR_SC_NRT

M1010C123 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IS_HHO_WO_CM_LB_RES_LIM_NRT

M1010C124 SERVICE BASED ISHO MEAS WITHOUT COM MOD FOR NRT

IS_HHO_WO_CM_SB_NRT

M1010C125 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO PRXTOTAL FOR RT

IS_HHO_NOCELL_LB_PRX_TOT_RT

M1010C126 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO PTXTOTAL FOR RT

IS_HHO_NOCELL_LB_PTX_TOT_RT

M1010C127 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO TO RESERVATION RATE SC FOR RT

IS_HHO_NOCELL_LB_RSVR_SC_RT

M1010C128 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO HW OR LOGICAL RESOURCE LIMIT FOR RT

IS_HHO_NOCELL_LB_RES_LIM_RT

M1010C129 NOT STARTED SERVICE BASED ISHO BECAUSE NO CELL GOOD ENOUGH FOR RT

IS_HHO_NOCELL_SB_RT

M1010C130 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO PRXTOTAL FOR NRT

IS_HHO_NOCELL_LB_PRX_TOT_NRT

M1010C131 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO PTXTOTAL FOR NRT

IS_HHO_NOCELL_LB_PTX_TOT_NRT

M1010C132 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION UL FOR NRT

IS_HHO_NOCELL_LB_CAPA_UL_NRT

M1010C133 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION DL FOR NRT

IS_HHO_NOCELL_LB_CAPA_DL_NRT

M1010C134 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO TO RESERVATION RATE SC FOR NRT

IS_HHO_NOCELL_LB_RSVR_SC_NRT



300 DN03471612




M1010C135 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO HW OR LOGICAL RESOURCE LIMIT FOR NRT

IS_HHO_NOCELL_LB_RES_LIM_NRT

M1010C136 NOT STARTED SERVICE BASED ISHO BECAUSE NO CELL GOOD ENOUGH FOR NRT

IS_HHO_NOCELL_SB_NRT

M1010C137 LOAD BASED ISHO ATTEMPTS CAUSED BY PRXTOTAL FOR RT

IS_HHO_ATT_LB_PRX_TOT_RT

M1010C138 LOAD BASED ISHO ATTEMPTS CAUSED BY PTXTOTAL FOR RT

IS_HHO_ATT_LB_PTX_TOT_RT

M1010C139 LOAD BASED ISHO ATTEMPTS CAUSED BY RESERVATION RATE SC FOR RT

IS_HHO_ATT_LB_RSVR_SC_RT

M1010C140 LOAD BASED ISHO ATTEMPTS CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR RT

IS_HHO_ATT_LB_RES_LIM_RT

M1010C141 SERVICE BASED ISHO ATTEMPTS FOR RT

IS_HHO_ATT_SB_RT

M1010C142 LOAD BASED ISHO ATTEMPTS CAUSED BY PRXTOTAL FOR NRT

IS_HHO_ATT_LB_PRX_TOT_NRT

M1010C143 LOAD BASED ISHO ATTEMPTS CAUSED BY PTXTOTAL FOR NRT

IS_HHO_ATT_LB_PTX_TOT_NRT

M1010C144 LOAD BASED ISHO ATTEMPTS CAUSED BY CAPA REJECTION UL FOR NRT

IS_HHO_ATT_LB_CAPA_UL_NRT

M1010C145 LOAD BASED ISHO ATTEMPTS CAUSED BY CAPA REJECTION DL FOR NRT

IS_HHO_ATT_LB_CAPA_DL_NRT

M1010C146 LOAD BASED ISHO ATTEMPTS CAUSED BY RESERVATION RATE SC FOR NRT

IS_HHO_ATT_LB_RSVR_SC_NRT

M1010C147 LOAD BASED ISHO ATTEMPTS CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR NRT

IS_HHO_ATT_LB_RES_LIM_NRT

M1010C148 SERVICE BASED ISHO ATTEMPTS FOR NRT

IS_HHO_ATT_SB_NRT

M1010C149 SUCCESSFUL LOAD BASED ISHO CAUSED BY PRXTOTAL FOR RT

SUCC_IS_HHO_LB_PRX_TOT_RT

M1010C150 SUCCESSFUL LOAD BASED ISHO CAUSED BY PTXTOTAL FOR RT

SUCC_IS_HHO_LB_PTX_TOT_RT

M1010C151 SUCCESSFUL ISHO CAUSED BY RES-ERVATION RATE SC FOR RT

SUCC_IS_HHO_LB_RSVR_SC_RT

M1010C152 SUCCESSFUL ISHO CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR RT

SUCC_IS_HHO_LB_RES_LIM_RT



DN03471612 301



M1010C153 SUCCESSFUL SERVICE BASED ISHO FOR RT

SUCC_IS_HHO_SB_RT

M1010C154 SUCCESSFUL LOAD BASED ISHO CAUSED BY PRXTOTAL FOR NRT

SUCC_IS_HHO_LB_PRX_TOT_NRT

M1010C155 SUCCESSFUL LOAD BASED ISHO CAUSED BY PTXTOTAL FOR NRT

SUCC_IS_HHO_LB_PTX_TOT_NRT

M1010C156 SUCCESSFUL ISHO CAUSED BY CAPA REJECTION UL FOR NRT

SUCC_IS_HHO_LB_CAPA_UL_NRT

M1010C157 SUCCESSFUL ISHO CAUSED BY CAPA REJECTION DL FOR NRT

SUCC_IS_HHO_LB_CAPA_DL_NRT

M1010C158 SUCCESSFUL ISHO CAUSED BY RES-ERVATION RATE SC FOR NRT

SUCC_IS_HHO_LB_RSVR_SC_NRT

M1010C159 SUCCESSFUL ISHO CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR NRT

SUCC_IS_HHO_LB_RES_LIM_NRT

M1010C160 SUCCESSFUL SERVICE BASED ISHO FOR NRT

SUCC_IS_HHO_SB_NRT

M1010C161 UNSUCCESSFUL LOAD BASED ISHO CAUSED BY PRXTOTAL FOR RT

UNSUCC_IS_HHO_LB_PRX_TOT_RT

M1010C162 UNSUCCESSFUL LOAD BASED ISHO CAUSED BY PTXTOTAL FOR RT

UNSUCC_IS_HHO_LB_PTX_TOT_RT

M1010C163 UNSUCCESSFUL ISHO CAUSED BY RESERVATION RATE SC FOR RT

UNSUCC_IS_HHO_LB_RSVR_SC_RT

M1010C164 UNSUCCESSFUL ISHO CAUSED BY HW OR LOGICAL RESOURCE LIMITA-TION FOR RT

UNSUCC_IS_HHO_LB_RES_LIM_RT

M1010C165 UNSUCCESSFUL SERVICE BASED ISHO FOR RT

UNSUCC_IS_HHO_SB_RT

M1010C166 UNSUCCESSFUL LOAD BASED ISHO CAUSED BY PRXTOTAL FOR NRT

UNSUCC_IS_HHO_LB_PRX_TOT_NRT

M1010C167 UNSUCCESSFUL LOAD BASED ISHO CAUSED BY PTXTOTAL FOR NRT

UNSUCC_IS_HHO_LB_PTX_TOT_NRT

M1010C168 UNSUCCESSFUL ISHO CAUSED BY CAPA REJECTION UL FOR NRT

UNSUCC_IS_HHO_LB_CAPA_UL_NRT

M1010C169 UNSUCCESSFUL ISHO CAUSED BY CAPA REJECTION DL FOR NRT

UNSUCC_IS_HHO_LB_CAPA_DL_NRT

M1010C170 UNSUCCESSFUL ISHO CAUSED BY RESERVATION RATE SC FOR NRT

UNSUCC_IS_HHO_LB_RSVR_SC_NRT

M1010C171 UNSUCCESSFUL ISHO CAUSED BY HW OR LOGICAL RESOURCE LIMITA-TION FOR NRT

UNSUCC_IS_HHO_LB_RES_LIM_NRT

M1010C172 UNSUCCESSFUL SERVICE BASED ISHO FOR NRT

UNSUCC_IS_HHO_SB_NRT



302 DN03471612




M1010C173 RRC CONNECTION DROPS DURING LOAD BASED ISHO CAUSED BY PRXTOTAL FOR RT

CONDR_IS_HHO_LB_PRX_TOT_RT

M1010C174 RRC CONNECTION DROPS DURING LOAD BASED ISHO CAUSED BY PTXTOTAL FOR RT

CONDR_IS_HHO_LB_PTX_TOT_RT

M1010C175 RRC CONNECTION DROPS DURING ISHO CAUSED BY RESERVATION RATE SC FOR RT

CONDR_IS_HHO_LB_RSVR_SC_RT

M1010C176 RRC CONNECTION DROPS DURING ISHO CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR RT

CONDR_IS_HHO_LB_RES_LIM_RT

M1010C177 RRC CONNECTION DROPS DURING SERVICE BASED ISHO FOR RT

CONDR_IS_HHO_SB_RT

M1010C178 RRC CONNECTION DROPS DURING LOAD BASED ISHO CAUSED BY PRXTOTAL FOR NRT

CONDR_IS_HHO_LB_PRX_TOT_NRT

M1010C179 RRC CONNECTION DROPS DURING LOAD BASED ISHO CAUSED BY PTXTOTAL FOR NRT

CONDR_IS_HHO_LB_PTX_TOT_NRT

M1010C180 RRC CONNECTION DROPS ISHO CAUSED BY CAPA REJECTION UL FOR NRT

CONDR_IS_HHO_LB_CAPA_UL_NRT

M1010C181 RRC CONNECTION DROPS ISHO CAUSED BY CAPA REJECTION DL FOR NRT

CONDR_IS_HHO_LB_CAPA_DL_NRT

M1010C182 RRC CONNECTION DROPS DURING ISHO CAUSED BY RESERVATION RATE SC FOR NRT

CONDR_IS_HHO_LB_RSVR_SC_NRT

M1010C183 RRC CONNECTION DROPS DURING ISHO CAUSED BY HW OR LOGICAL RESOURCE LIMITATION FOR NRT

CONDR_IS_HHO_LB_RES_LIM_NRT

M1010C184 RRC CONNECTION DROPS DURING SERVICE BASED ISHO FOR NRT

CONDR_IS_HHO_SB_NRT

M1010C189 LOAD BASED ISHO MEAS WITH COM MOD DUE TO CAPA REJECTION UL FOR RT

IS_HHO_W_CM_LB_CAPA_UL_RT

M1010C190 LOAD BASED ISHO MEAS WITH COM MOD DUE TO CAPA REJECTION DL FOR RT

IS_HHO_W_CM_LB_CAPA_DL_RT

M1010C191 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION UL FOR RT

IS_HHO_WO_CM_LB_CAPA_UL_RT

M1010C192 LOAD BASED ISHO MEAS WITHOUT COM MOD DUE TO CAPA REJECTION DL FOR RT

IS_HHO_WO_CM_LB_CAPA_DL_RT



DN03471612 303



35.2.9 RAN1275: Inter-system handover cancellation

M1010C193 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION UL FOR RT

IS_HHO_NOCELL_LB_CAPA_UL_RT

M1010C194 NOT STARTED LOAD BASED ISHO BECAUSE NO CELL GOOD ENOUGH DUE TO CAPA REJECTION DL FOR RT

IS_HHO_NOCELL_LB_CAPA_DL_RT

M1010C195 LOAD BASED ISHO ATTEMPTS CAUSED BY CAPA REJECTION UL FOR RT

IS_HHO_ATT_LB_CAPA_UL_RT

M1010C196 LOAD BASED ISHO ATTEMPTS CAUSED BY CAPA REJECTION DL FOR RT

IS_HHO_ATT_LB_CAPA_DL_RT

M1010C197 SUCCESSFUL ISHO CAUSED BY CAPA REJECTION UL FOR RT

SUCC_IS_HHO_LB_CAPA_UL_RT

M1010C198 SUCCESSFUL ISHO CAUSED BY CAPA REJECTION DL FOR RT

SUCC_IS_HHO_LB_CAPA_DL_RT

M1010C199 UNSUCCESSFUL ISHO CAUSED BY CAPA REJECTION UL FOR RT

UNSUCC_IS_HHO_LB_CAPA_UL_RT

M1010C200 UNSUCCESSFUL ISHO CAUSED BY CAPA REJECTION DL FOR RT

UNSUCC_IS_HHO_LB_CAPA_DL_RT

M1010C201 RRC CONNECTION DROPS ISHO CAUSED BY CAPA REJECTION UL FOR RT

CONDR_IS_HHO_LB_CAPA_UL_RT

M1010C202 RRC CONNECTION DROPS ISHO CAUSED BY CAPA REJECTION DL FOR RT

CONDR_IS_HHO_LB_CAPA_DL_RT




M1010C203 ISHO CANCEL DUE TO CPICH ECNO FOR RT

CANC_ISHO_CPICH_ECNO_RT

M1010C204 ISHO CANCEL DUE TO CPICH RSCP FOR RT

CANC_ISHO_CPICH_RSCP_RT

M1010C205 ISHO CANCEL DUE TO UE TX POWER FOR RT

CANC_ISHO_TX_PWR_RT

M1010C206 ISHO CANCEL DUE TO DL DPCH POWER FOR RT

CANC_ISHO_DL_DPCH_RT

M1010C207 ISHO CANCEL DUE TO CELL ADDITION FOR RT

CANC_ISHO_ADD_RT

M1010C208 ISHO CANCEL DUE TO CELL REPLACEMENT FOR RT

CANC_ISHO_REPL_RT

Table 37 Inter-system handover cancellation

304 DN03471612




35.2.10 RAN1191: Detected set reporting and measurements

35.2.11 RAN1515: HSPA inter-RNC cell change

M1010C209 ISHO CANCEL DUE TO CPICH ECNO FOR NRT

CANC_ISHO_CPICH_ECNO_NRT

M1010C210 ISHO CANCEL DUE TO CPICH RSCP FOR NRT

CANC_ISHO_CPICH_RSCP_NRT

M1010C211 ISHO CANCEL DUE TO UE TX POWER FOR NRT

CANC_ISHO_TX_PWR_NRT

M1010C212 ISHO CANCEL DUE TO DL DPCH POWERFOR NRT

CANC_ISHO_DL_DPCH_NRT

M1010C213 ISHO CANCEL DUE TO CELL ADDITION FOR NRT

CANC_ISHO_ADD_NRT

M1010C214 ISHO CANCEL DUE TO CELL REPLACEMENT FOR NRT

CANC_ISHO_REPL_NRT


Table 37 Inter-system handover cancellation (Cont.)


M1006C169 PRACH DELAY RANGE PARAMETER VALUE

PRACH_DELAY_RANGE_VALUE

M1013C4 CPICH ECNO SHO SUM CPICH_ECNO_SHO_SUM

M1013C5 CPICH ECNO SHO DENOM CPICH_ECNO_SHO_DENOM

M1013C6 CPICH RSCP SHO SUM CPICH_RSCP_SHO_SUM

M1013C7 CPICH RSCP SHO DENOM CPICH_RSCP_SHO_DENOM

M1028C0 CPICH ECNO DETECTED CELL SUM CPICH_ECNO_DET_SUM

M1028C1 CPICH ECNO DETECTED CELL DENOM

CPICH_ECNO_DET_DENOM

M1028C2 CPICH RSCP DETECTED CELL SUM CPICH_RSCP_DET_SUM

M1028C3 CPICH RSCP DETECTED CELL DENOM

CPICH_RSCP_DET_DENOM

Table 38 RAN1191: Detected set reporting and measurements


M1002C545 HS-DSCH ALLO FOR INTER RNC HHO INTERACTIVE

ALLO_HS_INTER_RNC_HHO_INT

M1002C546 HS-DSCH ALLO FOR INTER RNC HHO BACKGROUND

ALLO_HS_INTER_RNC_HHO_BGR

M1002C547 HS-DSCH SETUP FAIL FOR INTER RNC HHO INTERACTIVE

STP_F_HS_INTER_RNC_HHO_INT

Table 39 HSPA inter-RNC cell change

DN03471612 305



35.2.12 RAN1276: HSDPA inter-frequency handover

M1002C548 HS-DSCH SETUP FAIL FOR INTER RNC HHO BACKGROUND

STP_F_HS_INTER_RNC_HHO_BGR

M1002C549 E-DCH ALLO FOR INTER RNC HHO INTERACTIVE

ALLO_ED_INTER_RNC_HHO_INT

M1002C550 E-DCH ALLO FOR INTER RNC HHO BACKGROUND

ALLO_ED_INTER_RNC_HHO_BGR

M1002C551 E-DCH SETUP FAIL FOR INTER RNC HHO INTERACTIVE

STP_F_ED_INTER_RNC_HHO_INT

M1002C552 E-DCH SETUP FAIL FOR INTER RNC HHO BACKGROUND

STP_F_ED_INTER_RNC_HHO_BGR

M1008C243 INTER RNC HHO ATTEMPTS DUE TO HSPA SCC

INTER_RNC_HHO_ATT_HSPA_SCC

M1008C244 SUCCESSFUL INTER RNC HHO DUE TO HSPA SCC

INTER_RNC_HHO_SUCC_HSPA_SCC

M1008C245 UNSUCCESSFUL INTER RNC HHO CAUSED BY HSPA SCC

UNSUCC_INTER_RNC_HHO_SCC

M1008C246 CONNECTION DROPS DURING INTER RNC HHO CAUSED BY HSPA SCC

INTER_RNC_HHO_DROP_SCC

M1022C78 HS-DSCH/E-DCH ALLO AFTER HS-DSCH/E-DCH HHO REQ

HS_E_REQ_HS_E_ALLO_HHO

M1022C79 HS-DSCH/DCH ALLO AFTER HS-DSCH/E-DCH HHO REQ

HS_E_REQ_HS_D_ALLO_HHO

M1022C80 HS-DSCH/DCH ALLO AFTER HS-DSCH/DCH HHO REQ

HS_D_REQ_HS_D_ALLO_HHO

M1022C81 DCH/DCH ALLO AFTER HS-DSCH/E-DCH HHO REQ

HS_E_REQ_D_D_ALLO_HHO

M1022C82 DCH/DCH ALLO AFTER HS-DSCH/DCH HHO REQ

HS_D_REQ_D_D_ALLO_HHO


Table 39 HSPA inter-RNC cell change (Cont.)


M1002C623 ALLOCATION FOR HSDPA IFHO COM-PRESSED MODE

ALLO_CM_HSDPA_IFHO

M1002C624 ALLOCATION DURATION FOR HSDPA IFHO COMPRESSED MODE

ALLO_DURA_CM_HSDPA_IFHO


REJ_CM_HSDPA_IFHO

M1008C247 HSPA IFHO MEAS START ATTEMPTS ATT_HSPA_IFHO_MEAS

M1008C248 HSPA IFHO MEAS START FAILURES FAIL_HSPA_IFHO_MEAS

M1008C249 NOT STARTED HSPA IFHO BECAUSE NO CELL GOOD ENOUGH

NOT_START_HSPA_IFHO_NO_CELL

Table 40 HSDPA inter-frequency handover measurement counters

306 DN03471612




35.2.13 RAN1596: HSPA capability based handover

M1008C250 HSPA INTRA-RNC IFHO ATTEMPTS ATT_HSPA_INTRA_IFHO

M1008C251 HSPA INTER-RNC IFHO ATTEMPTS ATT_HSPA_INTER_IFHO

M1008C252 SUCCESSFUL HSPA INTRA-RNC IFHO TO REL99

SUCC_HSPA_INTRA_IFHO_REL99

M1008C253 SUCCESSFUL HSPA INTRA-RNC IFHO TO HSDPA

SUCC_HSPA_INTRA_IFHO_HSDPA

M1008C254 SUCCESSFUL HSPA INTRA-RNC IFHO TO HSUPA

SUCC_HSPA_INTRA_IFHO_HSUPA

M1008C255 SUCCESSFUL HSPA INTER-RNC IFHO SUCC_HSPA_INTER_IFHO

M1008C256 FAILED HSPA INTRA-RNC IFHO DUE TO UTRAN

FAIL_HSPA_INTRA_IFHO_UTRAN

M1008C257 FAILED HSPA INTER-RNC IFHO DUE TO UTRAN

FAIL_HSPA_INTER_IFHO_UTRAN

M1008C258 FAILED HSPA INTRA-RNC IFHO DUE TO UE NACK

FAIL_HSPA_INTRA_IFHO_UE_NACK

M1008C259 FAILED HSPA INTER-RNC IFHO DUE TO UE NACK

FAIL_HSPA_INTER_IFHO_UE_NACK

M1008C260 FAILED HSPA INTRA-RNC IFHO DUE TO UE LOST

FAIL_HSPA_INTRA_IFHO_UE_LOST

M1008C261 FAILED HSPA INTER-RNC IFHO DUE TO UE LOST

FAIL_HSPA_INTER_IFHO_UE_LOST


Table 40 HSDPA inter-frequency handover measurement counters (Cont.)


M1008C262 IFHO MEAS START ATTEMPTS DUE TO HSPA CAPA

ATT_HCAP_IFHO_MEAS

M1008C263 IFHO MEAS START FAILURES DUE TO HSPA CAPA

FAIL_HCAP_IFHO_MEAS

M1008C264 NOT STARTED IFHO BECAUSE NO CELL GOOD ENOUGH DUE TO HSPA CAPA

NOT_START_HCAP_IFHO_NO_CELL

M1008C265 INTRA-RNC IFHO ATTEMPTS DUE TO HSPA CAPA

ATT_HCAP_INTRA_IFHO

M1008C266 INTER-RNC IFHO ATTEMPTS DUE TO HSPA CAPA

ATT_HCAP_INTER_IFHO

M1008C267 SUCCESSFUL INTRA-RNC IFHO DUE TO HSPA CAPA

SUCC_HCAP_INTRA_IFHO

M1008C268 SUCCESSFUL INTER-RNC IFHO DUE TO HSPA CAPA

SUCC_HCAP_INTER_IFHO

M1008C269 FAILED HSPA CAPA TRIGGERED INTRA-RNC IFHO DUE TO UTRAN

FAIL_HCAP_INTRA_IFHO_UTRAN

Table 41 HSPA capability based handover counters

DN03471612 307



35.2.14 RAN1011: HSPA layering for UEs in common channels

35.2.15 RAN146: Power Balancing

M1008C270 FAILED HSPA CAPA TRIGGERED INTER-RNC IFHO DUE TO UTRAN

FAIL_HCAP_INTER_IFHO_UTRAN

M1008C271 FAILED HSPA CAPA TRIGGERED INTRA-RNC IFHO DUE TO UE NACK

FAIL_HCAP_INTRA_IFHO_UE_NACK

M1008C272 FAILED HSPA CAPA TRIGGERED INTER-RNC IFHO DUE TO UE NACK

FAIL_HCAP_INTER_IFHO_UE_NACK

M1008C273 FAILED HSPA CAPA TRIGGERED INTRA-RNC IFHO DUE TO UE LOST

FAIL_HCAP_INTRA_IFHO_UE_LOST

M1008C274 FAILED HSPA CAPA TRIGGERED INTER-RNC IFHO DUE TO UE LOST

FAIL_HCAP_INTER_IFHO_UE_LOST


Table 41 HSPA capability based handover counters (Cont.)


M1002C509 DCH ALLO FOR SIG LINK FROM NON-HSPA TO HSPA LAYER

DCH_ALLO_NON_HSPA_TO_HSPA

M1002C510 DCH ALLO FOR SIG LINK FROM HSPA TO NON-HSPA LAYER

DCH_ALLO_HSPA_TO_NON_HSPA

M1002C511 DCH ALLO FOR SIG LINK FROM HSPA TO HSPA LAYER

DCH_ALLO_HSPA_TO_HSPA

M1002C512 FACH TO DCH FROM NON-HSPA TO HSPA LAYER

FACH_DCH_NON_HSPA_TO_HSPA

M1002C513 FACH TO DCH FROM HSPA TO NON-HSPA LAYER

FACH_DCH_HSPA_TO_NON_HSPA

M1002C514 FACH TO DCH FROM HSPA TO HSPA LAYER

FACH_DCH_HSPA_TO_HSPA

Table 42 HSPA layering for UEs in common channels counters


M1004C108 ALL IUR DL POWER CONTROL MESSAGES IN SRNC

DL_PWR_CTRL_IUR_ALL_SRNC

M1004C109 IUR DL POWER CONTROL MESSAGES FOR POWER UPDATE IN SRNC

DL_PWR_CTRL_IUR_PWR_UPD_SRNC

M1004C110 ALL IUR DL POWER CONTROL MESSAGES IN DRNC

DL_PWR_CTRL_IUR_ALL_DRNC

M1004C111 IUR DL POWER CONTROL MESSAGES FOR POWER UPDATE IN DRNC

DL_PWR_CTRL_IUR_PWR_UPD_DRNC

Table 43 RAN146: Power Balancing counters

308 DN03471612




35.2.16 RAN955: Power Saving Mode for BTS

M1005C148 DEDICATED MEASUREMENT REPORT

DEDIC_MEAS_REPORT

M1005C149 ALL IUB DL POWER CONTROL MESSAGES IN SRNC

DL_PWR_CTRL_IUB_ALL_SRNC

M1005C150 ALL IUB DL POWER CONTROL MESSAGES IN DRNC

DL_PWR_CTRL_IUB_ALL_DRNC

M1005C151 IUB DL POWER CONTROL MESSAGES FOR POWER UPDATE IN SRNC

DL_PWR_CTRL_IUB_PWR_UPD_SRNC

M1005C152 IUB DL POWER CONTROL MESSAGES FOR POWER UPDATE IN DRNC

DL_PWR_CTRL_IUB_PWR_UPD_DRNC


Table 43 RAN146: Power Balancing counters (Cont.)


M1000C377 WCELL POWER SAVING MODE ACTI-VATIONS

WCELL_POWER_SAVING_MODE_ACT

M1000C378 AVAILABILITY WCELL IN POWER SAVING MODE

AVAIL_WCELL_IN_POWER_SAVING

M1008C286 INTER FREQ HO ATTEMPTS FORCED BY CELL SHUTDOWN FOR NRT

ATT_IFHO_CELL_SHUTDOWN_NRT

M1008C287 INTER FREQ HO ATTEMPTS FORCED BY CELL SHUTDOWN FOR RT

ATT_IFHO_CELL_SHUTDOWN_RT

M1008C288 SUCCESSFUL INTER FREQ HO FORCED BY CELL SHUTDOWN FOR NRT

SUCC_IFHO_CELL_SHUTDOWN_NRT

M1008C289 SUCCESSFUL INTER FREQ HO FORCED BY CELL SHUTDOWN FOR RT

SUCC_IFHO_CELL_SHUTDOWN_RT

M1010C225 INTER SYSTEM HO ATTEMPTS FORCED BY CELL SHUTDOWN FOR NRT

ATT_ISHO_CELL_SHUTDOWN_NRT

M1010C226 INTER SYSTEM HO ATTEMPTS FORCED BY CELL SHUTDOWN FOR RT

ATT_ISHO_CELL_SHUTDOWN_RT

M1010C227 SUCCESSFUL INTER SYSTEM HO FORCED BY CELL SHUTDOWN FOR NRT

SUCC_ISHO_CELL_SHUTDOWN_NRT

M1010C228 SUCCESSFUL INTER SYSTEM HO FORCED BY CELL SHUTDOWN FOR RT

SUCC_ISHO_CELL_SHUTDOWN_RT

Table 44 RAN955: Power Saving Mode for BTS counters

DN03471612 309



35.2.17 RAN1201: Support for Fractional DPCH

35.2.18 RAN1231: Support for HSPA over Iur


M1002C664 E-DCH ALLO FOR SRB IN SRNC ALLO_EDCH_SRB_SRNC

M1002C665 E-DCH ALLO FOR SRB IN DRNC ALLO_EDCH_SRB_DRNC

M1002C666 HS-DSCH ALLO FOR SRB IN SRNC ALLO_HS_DSCH_SRB_SRNC

M1002C667 HS-DSCH ALLO FOR SRB IN DRNC ALLO_HS_DSCH_SRB_DRNC

Table 45 RAN1201: Support for Fractional DPCH counters


M1002C630 HS-DSCH ATTEMPTS IN DRNC ATT_HS_DSCH_DRNC

M1002C631 HS-DSCH ALLOCATIONS IN DRNC ALLO_HS_DSCH_DRNC

M1002C632 HS-DSCH ALLOCATION DURATION IN DRNC

ALLO_DUR_HS_DSCH_DRNC

M1002C633 E-DCH ATTEMPTS IN DRNC ATT_EDCH_DRNC

M1002C634 E-DCH ALLOCATIONS IN DRNC ALLO_EDCH_DRNC

M1002C635 E-DCH ALLOCATION DURATION IN DRNC

ALLO_DUR_EDCH_DRNC

M1004C169 TRANSFERRED DATA FOR NRT HSDPA RETURN CHANNEL FROM DRNC

NRT_HSDPA_UL_DATA_FROM_DRNC

M1004C170 TRANSFERRED DATA FOR RT HSDPA RETURN CHANNEL FROM DRNC

RT_HSDPA_UL_DATA_FROM_DRNC

M1004C171 TRANSFERRED HS-DSCH DATA FOR CS VOICE TO DRNC

AMR_HS_DSCH_DATA_TO_DRNC

M1004C172 TRANSFERRED E-DCH DATA FOR CS VOICE FROM DRNC

AMR_EDCH_DATA_FROM_DRNC

M1004C173 HS-DSCH MAC-D FLOW ALLOCATION ATTEMPTS OVER IUR ON SRNC

ATT_HSDSCH_OVER_IUR_ON_SRNC

M1004C174 HS-DSCH MAC-D FLOW ALLOCATION SUCCESS OVER IUR ON SRNC

SUCC_HSDSCH_OVER_IUR_ON_SRNC

M1008C275 HS-DSCH INTER RNC SERVING CELL CHANGES SUCCESSFUL

SCC_INTER_RNC_SUCCESS

M1008C276 HS-DSCH INTER RNC SERVING CELL CHANGE FAILURES

SCC_INTER_RNC_FAIL

M1008C277 E-DCH INTER RNC SERVING CELL CHANGES SUCCESSFUL

EDCH_SCC_INTER_RNC_SUCCESS

M1008C278 E-DCH INTER RNC SERVING CELL CHANGE FAILURES

EDCH_SCC_INTER_RNC_FAIL

Table 46 RAN1231: Support for HSPA over Iur

310 DN03471612




35.2.19 RAN2047: LTE interworking

35.2.20 RAN1758: Multiple BSIC Identification

35.2.21 RAN2289: Blind IFHO in RAB Setup Phase


M1009C286 LTE CS HHO IN PREP FAIL DUE TO RNL

LTE_CS_IN_PREP_FAIL_RNL

Table 47 RAN2047: LTE interworking


M1010C229 INTER SYSTEM HO ATTEMPTS FOR 2ND BEST CELL FOR RT

IS_HHO_ATT_2ND_BEST_CELL_RT

M1010C230 INTER SYSTEM HO ATTEMPTS FOR 3RD BEST CELL FOR RT

IS_HHO_ATT_3RD_BEST_CELL_NRT

M1010C231 INTER SYSTEM HO ATTEMPTS FOR 2ND BEST CELL FOR NRT

IS_HHO_ATT_2ND_BEST_CELL_RT

M1010C232 INTER SYSTEM HO ATTEMPTS FOR 3RD BEST CELL FOR NRT

IS_HHO_ATT_3RD_BEST_CELL_NRT

Table 48 RAN1758: Multiple BSIC Identification


M1006C324 RB SETUP ATTEMPT WITH BLIND HO ATT_RB_SETUP_BLIND_HO

M1006C325 RB SETUP SUCCESSFUL WITH BLIND HO

SUCC_RB_SETUP_BLIND_HO

M1006C326 RB SETUP FAIL BLIND HO DUE TO UE NACK WITHOUT MEAS

FAIL_RB_BLHO_UENACK_WO_MEAS

M1006C327 RB SETUP FAIL BLIND HO DUE TO UE NACK WITH MEAS

FAIL_RB_BLHO_UENACK_W_MEAS

M1006C328 RB SETUP FAIL BLIND HO DUE TO UE LOST WITHOUT MEAS

FAIL_RB_BLHO_UELOST_WO_MEAS

M1006C329 RB SETUP FAIL BLIND HO DUE TO UE LOST WITH MEAS

FAIL_RB_BLHO_UELOST_W_MEAS

M1006C240 ATTEMPTED INTER-BTS LAYER CHANGES IN PCH/FACH TO DCH

ATT_INT_BTS_PCH_FACH_TO_DCH

M1006C241 SUCCESSFUL INTER-BTS LAYER CHANGES IN PCH/FACH TO DCH

SUCC_INT_BTS_PCH_FACH_TO_DCH

M1006C242 FAILED INTER-BTS LAYER CHANGES IN PCH/FACH TO DCH

FAIL_INT_BTS_PCH_FACH_TO_DCH

M1008C296 MBLB IFHO ATTEMPTS WITH UE BAND CAPA

ATT_MBLB_IFHO_UE_BAND_CAPA

Table 49 RAN2289: Blind IFHO in RAB Setup Phase

DN03471612 311



M1008C297 MBLB IFHO ATTEMPTS WITH SERVICE AND UE FEATURE CAPA

ATT_MBLB_IFHO_SERVICE_UE_CAP

M1008C298 MBLB IFHO ATTEMPTS WITH RSCP ATT_MBLB_IFHO_RSCP

M1008C299 MBLB IFHO ATTEMPTS WITH LOAD ATT_MBLB_IFHO_LOAD

M1008C300 SUCCESSFUL MBLB IFHO SUCC_MBLB_IFHO

M1008C301 FAILED MBLB IFHO DUE TO UTRAN FAIL_MBLB_IFHO_UTRAN

M1008C302 FAILED MBLB IFHO DUE TO UE NACK FAIL_MBLB_IFHO_UE_NACK

M1008C303 FAILED MBLB IFHO DUE TO UE LOST FAIL_MBLB_IFHO_UE_LOST

M1033C0 RRC CPICH ECNO CLASS 0 RRC_CPICH_ECNO_CLASS_0










M1033C10 RRC CPICH RSCP CLASS 0 RRC_CPICH_RSCP_CLASS_0


















Table 49 RAN2289: Blind IFHO in RAB Setup Phase (Cont.)

312 DN03471612




35.3 ParametersThere are no parameters related to:

• RAN1.5008 GSM - WCDMA inter-system handover • RAN1011: HSPA layering for UEs in common channels • RAN1.5008 GSM - WCDMA inter-system handover • RAN2.0105: Inter-RNC intra-frequency hard handover • RAN2067: LTE interworking

35.3.1 RAN2.0079: Directed RRC connection setup

35.3.2 RAN1266: Soft handover based on detected set reporting

Parameter name Abbreviated name Modifiable / system-defined

Object

Prx Margin for DRRC DRRCprxMargin On-Line WCEL

Prx Offset for DRRC DRRCprxOffset On-Line WCEL

Ptx Margin for DRRC DRRCptxMargin On-Line WCEL

Ptx Offset for DRRC DRRCptxOffset On-Line WCEL

RRC connection setup Retrans-mission Timer1

RRCconnRepTimer1 On-Line WCEL

Table 50 RAN2.0079: Directed RRC connection setup


Object

Change origin ADJDChangeOrigin Not modifiable ADJD

Identifier of additional intra-frequency adjacency

ADJDId Not modifiable ADJD

Cell Identifier AdjdCI On-Line ADJD

Primary CPICH power AdjdCPICHTxPwr On-Line ADJD

Disable Effect on Report-ing Range

AdjdDERR On-Line ADJD

HSDPA HOPS identifier AdjdHSDPAHopsId On-Line ADJD

Location Area Code AdjdLAC On-Line ADJD

Mobile Country Code AdjdMCC On-Line ADJD

Mobile Network Code AdjdMNC On-Line ADJD

Mobile Network Code Length

AdjdMNCLength On-Line ADJD

NRT HOPS Identifier AdjdNRTHopsId On-Line ADJD

Routing Area Code AdjdRAC On-Line ADJD

RNC Identifier AdjdRNCId On-Line ADJD

Table 51 RAN1266: Soft handover based on detected set reporting

DN03471612 313



35.3.3 RAN1.024: Soft handoversTable RAN1.024: Soft handovers includes parameters for RAN1.5010: Inter-frequency handover.

RT HOPS Identifier AdjdRTHopsId On-Line ADJD

HSDPA HOPS identifier for AMR multi-service

AdjdRTWithHSDPAHop-sId

On-Line ADJD

Primary Scrambling Code AdjdScrCode On-Line ADJD

Tx Diversity Indicator AdjdTxDiv On-Line ADJD

Detected Set Reporting Based SHO

DSRepBasedSHO On-Line FMCS


Object

Table 51 RAN1266: Soft handover based on detected set reporting (Cont.)


Object

Cell Identifier AdjiCI On-Line ADJI

UTRA Absolute Radio Frequency Channel Number

UARFCN Not modifiable WCEL

UTRA Absolute Radio Frequency Channel Number

AdjiUARFCN On-Line ADJI

Primary CPICH power AdjiCPICHTxPwr On-Line ADJI

Location Area Code AdjiLAC On-Line ADJI

Mobile Country Code AdjiMCC On-Line ADJI

Mobile Network Code AdjiMNC On-Line ADJI

Routing Area Code AdjiRAC On-Line ADJI

RNC Identifier AdjiRNCid On-Line ADJI

Primary Scrambling Code AdjiScrCode On-Line ADJI

Tx Diversity Indicator AdjiTxDiv On-Line ADJI

Maximum UE TX Power on DPCH

AdjiTxPwrDPCH On-Line ADJI

NRT HOPI Identifier NrtHopiIdentifier On-Line ADJI

RT HOPI Identifier RtHopiIdentifier On-Line ADJI

Cell Identifier AdjsCI On-Line ADJS

Primary CPICH power AdjsCPICHTxPwr On-Line ADJS

Disable Effect on Report-ing Range

AdjsDERR On-Line ADJS

CPICH Ec/No Offset AdjsEcNoOffset On-Line ADJS

Table 52 RAN1.024: Soft handovers

314 DN03471612




Location Area Code AdjsLAC On-Line ADJS

Mobile Country Code AdjsMCC On-Line ADJS

Mobile Network Code AdjsMNC On-Line ADJS

Routing Area Code AdjsRAC On-Line ADJS

RNC Identifier AdjsRNCid On-Line ADJS

Primary Scrambling Code AdjsScrCode On-Line ADJS

Tx Diversity Indicator AdjsTxDiv On-Line ADJS

Maximum UE TX Power on RACH

AdjsTxPwrRACH On-Line ADJS

NRT HOPS Identifier NrtHopsIdentifier On-Line ADJS

RT HOPS Identifier RtHopsIdentifier On-Line ADJS

FMCI identifier FMCIId Not modifiable FMCI

IFHO caused by CPICH Ec/No

IFHOcauseCPICHEcNo On-Line FMCI

IFHO caused by CPICH RSCP

IFHOcauseCPICHrscp On-Line FMCI

IFHO caused by DL DPCH TX Power

IFHOcauseTxPwrDL On-Line FMCI

IFHO caused by UE TX Power

IFHOcauseTxPwrUL On-Line FMCI

IFHO caused by UL DCH Quality

IFHOcauseUplinkQuality On-Line FMCI

DL DPCH TX Power Threshold for AMR

InterFreqDLTxPwrTh-rAMR

On-Line FMCI

DL DPCH TX Power Threshold for CS

InterFreqDLTxPwrThrCS On-Line FMCI

DL DPCH TX Power Threshold for NRT PS

InterFreqDLTxPwrThrN-rtPS

On-Line FMCI

DL DPCH TX Power Threshold for RT PS

InterFreqDLTxP-wrThrRtPS

On-Line FMCI

Maximum Measurement Period

InterFreqMaxMeasPeriod On-Line FMCI

Measurement Averaging Window

InterFreqMeasAveWin-dow

On-Line FMCI

Measurement Reporting Interval

InterFreqMeasRepInter-val

On-Line FMCI

Minimum Interval Between HOs

InterFreqMinHoInterval On-Line FMCI

Minimum Measurement Interval

InterFreqMinMeasInterval On-Line FMCI


Object

Table 52 RAN1.024: Soft handovers (Cont.)

DN03471612 315



neighbor Cell Search Period

InterFreqNcellSearchPe-riod

On-Line FMCI

UE TX Power Filter Coef-ficient

InterFreqUETxPwrFilter-Coeff

On-Line FMCI

UE TX Power Threshold for AMR

InterFreqUETxPwrTh-rAMR

On-Line FMCI

UE TX Power Threshold for CS

InterFreqUETxPwrThrCS On-Line FMCI

UE TX Power Threshold for NRT PS

InterFreqUETxPwrThrN-rtPS

On-Line FMCI

UE TX Power Threshold for RT PS

InterFreqUETxP-wrThrRtPS

On-Line FMCI

UE TX Power Time Hys-teresis

InterFreqUETxPwrTime-Hyst

On-Line FMCI

FMCS identifier FMCSId Not modifiable FMCS

Active Set Weighting Coefficient

ActiveSetWeightingCoef-ficient

On-Line FMCS

Addition Reporting Interval

AdditionReportingInterval On-Line FMCS

Addition Time AdditionTime On-Line FMCS

Addition Window AdditionWindow On-Line FMCS

Drop Time DropTime On-Line FMCS

Drop Window DropWindow On-Line FMCS

CPICH Ec/No Filter Coef-ficient

EcNoFilterCoefficient On-Line FMCS

CPICH Ec/No HHO Can-cellation

HHoEcNoCancel On-Line FMCS

CPICH Ec/No HHO Can-cellation Time

HHoEcNoCancelTime On-Line FMCS

CPICH Ec/No HHO Threshold

HHoEcNoThreshold On-Line FMCS

CPICH Ec/No HHO Time Hysteresis

HHoEcNoTimeHysteresis On-Line FMCS

CPICH RSCP HHO Can-cellation

HHoRscpCancel On-Line FMCS

CPICH RSCP HHO Can-cellation Time

HHoRscpCancelTime On-Line FMCS

CPICH RSCP HHO Filter Coefficient

HHoRscpFilterCoefficient On-Line FMCS

CPICH RSCP HHO Threshold

HHoRscpThreshold On-Line FMCS


Object


316 DN03471612




CPICH RSCP HHO Time Hysteresis

HHoRscpTimeHysteresis On-Line FMCS

Maximum Active Set Size MaxActiveSetSize On-Line FMCS

Replacement Reporting Interval

ReplacementReport-ingInterval

On-Line FMCS

Replacement Time ReplacementTime On-Line FMCS

Replacement Window ReplacementWindow On-Line FMCS

CPICH Ec/No Margin for IFHO

AdjiEcNoMargin On-Line HOPI

Minimum CPICH Ec/No for IFHO

AdjiMinEcNo On-Line HOPI

Minimum CPICH RSCP for IFHO

AdjiMinRSCP On-Line HOPI

Pathloss Margin for IFHO AdjiPlossMargin On-Line HOPI

Ncell Priority for Coverage IFHO

AdjiPriorityCoverage On-Line HOPI

Ncell Priority for Quality IFHO

AdjiPriorityQuality On-Line HOPI

CPICH Ec/No Averaging Window

EcNoAveragingWindow On-Line HOPS

Enable Inter-RNC Soft Handover

EnableInterRNCsho On-Line HOPS

Enable RRC Connection Release

EnableRRCRelease On-Line HOPS

HHO Margin for Average Ec/No

HHOMarginAvera-geEcNo

On-Line HOPS

HHO Margin for Peak Ec/No

HHOMarginPeakEcNo On-Line HOPS

Release Margin for Average Ec/No

ReleaseMarginAvera-geEcNo

On-Line HOPS

Release Margin for Peak Ec/No

ReleaseMarginPeakE-cNo

On-Line HOPS

Lower Rx-Tx Time Differ-ence Threshold

LowerRxTxTimeDiff On-Line RNC

Upper Rx-Tx Time Differ-ence Threshold

UpperRxTxTimeDiff On-Line RNC

Prx Margin for DRRC DRRCprxMargin On-Line WCEL

Prx Offset for DRRC DRRCprxOffset On-Line WCEL

Ptx Margin for DRRC DRRCptxMargin On-Line WCEL

Ptx Offset for DRRC DRRCptxOffset On-Line WCEL

Maximum allowed DL user bit rate in HHO

HHoMaxAllowedBitrat-eDL

On-Line WCEL


Object


DN03471612 317



35.3.4 RAN1.5009: WCDMA - GSM inter-system handover

Maximum allowed UL user bit rate in HHO

HHoMaxAllowedBitra-teUL

On-Line WCEL

Maximum number of UEs in CM due to critical HO measurement

MaxNumberUECmHO On-Line WCEL

NRT FMCI Identifier NrtFmciIdentifier On-Line WCEL

NRT FMCS Identifier NrtFmcsIdentifier On-Line WCEL

RT FMCI Identifier RtFmciIdentifier On-Line WCEL

RT FMCS Identifier RtFmcsIdentifier On-Line WCEL

Sector Identifier SectorID On-Line WCEL

Compressed mode master switch

CMmasterSwitch On-Line RNC

Target for received power PrxTarget On-Line WCEL

Transmission power of the primary CPICH channel

PtxPrimaryCPICH On-Line WCEL

Transmission power of the primary CCPCH channel

PtxPrimaryCCPCH On-Line WCEL

Target for transmitted power

PtxTarget On-Line WCEL

Target for transmitted non-HSDPA power

PtxTargetHSDPA On-Line WCEL


Object



Object

Maximum UE TX Power on RACH

AdjgTxPwrMaxRACH On-Line ADJG

Maximum UE TX Power on TCH

AdjgTxPwrMaxTCH On-Line ADJG

NRT HOPG Identifier NrtHopgIdentifier On-Line ADJG

RT HOPG Identifier RtHopgIdentifier On-Line ADJG

FMCG identifier FMCGId Not modifiable FMCG

GSM HO caused by CPICH Ec/No

GSMcauseCPICHEcNo On-Line FMCG

GSM HO caused by CPICH RSCP

GSMcauseCPICHrscp On-Line FMCG

Table 53 RAN1.5009: WCDMA - GSM inter-system handover

318 DN03471612




GSM HO caused by DL DPCH TX Power

GSMcauseTxPwrDL On-Line FMCG

GSM HO caused by UE TX Power

GSMcauseTxPwrUL On-Line FMCG

GSM HO caused by UL DCH Quality

GSMcauseUplinkQuality On-Line FMCG

DL DPCH TX Power Threshold for AMR

GsmDLTxPwrThrAMR On-Line FMCG

DL DPCH TX Power Threshold for CS

GsmDLTxPwrThrCS On-Line FMCG

DL DPCH TX Power Threshold for NRT PS

GsmDLTxPwrThrNrtPS On-Line FMCG

DL DPCH TX Power Threshold for RT PS

GsmDLTxPwrThrRtPS On-Line FMCG

Maximum Measurement Period

GsmMaxMeasPeriod On-Line FMCG

Measurement Averaging Window

GsmMeasAveWindow On-Line FMCG

Measurement Reporting Interval

GsmMeasRepInterval On-Line FMCG

Minimum Interval Between HOs

GsmMinHoInterval On-Line FMCG

Minimum Measurement Interval

GsmMinMeasInterval On-Line FMCG

GSM neighbor Cell Search Period

GsmNcellSearchPeriod On-Line FMCG

UE TX Power Filter Coef-ficient

GsmUETxPwrFilterCoeff On-Line FMCG

UE TX Power Threshold for AMR

GsmUETxPwrThrAMR On-Line FMCG

UE TX Power Threshold for CS

GsmUETxPwrThrCS On-Line FMCG

UE TX Power Threshold for NRT PS

GsmUETxPwrThrNrtPS On-Line FMCG

UE TX Power Threshold for RT PS

GsmUETxPwrThrRtPS On-Line FMCG

UE TX Power Time Hys-teresis

GsmUETxPwrTimeHyst On-Line FMCG

Quality deterioration report from UL OLPC con-troller

EnableULQualDetRep On-Line RNC

UL quality deterioration reporting threshold

ULQualDetRepThreshold On-Line RNC


Object

Table 53 RAN1.5009: WCDMA - GSM inter-system handover (Cont.)

DN03471612 319



Cell Re-selection HCS Priority

AdjgHCSpriority On-Line HOPG

Cell Re-selection HCS Threshold

AdjgHCSthreshold On-Line HOPG

Cell Re-selection Penalty Time

AdjgPenaltyTime On-Line HOPG

Ncell Priority for Coverage HO

AdjgPriorityCoverage On-Line HOPG

Cell Re-selection Quality Offset 1

AdjgQoffset1 On-Line HOPG

Cell Re-selection Minimum RX Level

AdjgQrxlevMin On-Line HOPG

Minimum RX Level for Coverage HO

AdjgRxLevMinHO On-Line HOPG

Cell Re-selection Tempo-rary Offset 1

AdjgTempOffset1 On-Line HOPG

HOPG Identifier HOPGId Not modifiable HOPG

Handover of AMR Service to GSM

GsmHandoverAMR On-Line RNC

Handover of CS Service to GSM

GsmHandoverCS Not modifiable RNC

Handover of NRT PS Service to GSM

GsmHandoverNrtPS On-Line RNC

Handover of RT PS Service to GSM

GsmHandoverRtPS On-Line RNC

NRT FMCG Identifier NrtFmcgIdentifier On-Line WCEL

RT FMCG Identifier RtFmcgIdentifier On-Line WCEL

Inter-system adjacency identifier

ADJGId Not modifiable ADJG

Base Station Colour Code AdjgBCC On-Line ADJG

BCCH ARFCN AdjgBCCH On-Line ADJG

Band Indicator AdjgBandIndicator Not modifiable ADJG

Cell Identifier AdjgCI On-Line ADJG

Location Area Code AdjgLAC On-Line ADJG

Mobile Country Code AdjgMCC On-Line ADJG

Mobile Network Code AdjgMNC On-Line ADJG


AdjgMNCLength On-Line ADJG

Network Colour Code AdjgNCC On-Line ADJG


AdjiQoffset1 On-Line HOPI


Object


320 DN03471612





AdjiQoffset2 On-Line HOPI

Cell Re-selection Minimum Quality

AdjiQqualMin On-Line HOPI


AdjiQrxlevMin On-Line HOPI


AdjiTempOffset1 On-Line HOPI


AdjiTempOffset2 On-Line HOPI

Cell Re-selection HCS Priority

AdjsHCSpriority On-Line HOPS

Cell Re-selection HCS Threshold

AdjsHCSthreshold On-Line HOPS

Cell Re-selection Penalty Time

AdjsPenaltyTime On-Line HOPS


AdjsQoffset1 On-Line HOPS


AdjsQoffset2 On-Line HOPS

Cell Re-selection Minimum Quality

AdjsQqualMin On-Line HOPS


AdjsQrxlevMin On-Line HOPS


AdjsTempOffset1 On-Line HOPS


AdjsTempOffset2 On-Line HOPS


Object



Object

Restricting overloaded WPS calls

WPSCallRestriction On-Line RNC

Usage of the Wireless Priority Service

WireLessPriorityService On-Line RNC

Offset for received Wireless Priority Service power

PrxOffsetWPS On-Line WCEL

Offset for transmitted Wireless Priority Service power

PtxOffsetWPS On-Line WCEL

Table 54 RAN1.5009: WCDMA - GSM inter-system handover AND RAN1180: Wireless Priority Service

DN03471612 321



35.3.5 RAN1183: UTRAN - GAN interworking

35.3.6 RAN2.0060: IMSI based handover


Object

Inter-system adjacency identifier

ADJGId Not modifiable ADJG

Base Station Colour Code AdjgBCC On-Line ADJG

BCCH ARFCN AdjgBCCH On-Line ADJG

Band Indicator AdjgBandIndicator Not modifiable ADJG

Cell Identifier AdjgCI On-Line ADJG

Location Area Code AdjgLAC On-Line ADJG

Mobile Country Code AdjgMCC On-Line ADJG

Mobile Network Code AdjgMNC On-Line ADJG


AdjgMNCLength On-Line ADJG

Network Colour Code AdjgNCC On-Line ADJG

Include in System Infor-mation

AdjgSIB On-Line ADJG

Inter-system neighbor Cell Type

ADJGType Not modifiable ADJG

GAN ARFCN GANetwARFCN On-Line RNC

GAN BCC GANetwBCC On-Line RNC

GAN NCC GANetwNCC On-Line RNC

Table 55 RAN1183: UTRAN - GAN interworking


Object

IMSI Based IFHO IMSIbasedIFHO On-Line FMCI

IMSI Based SHO IMSIbasedSHO On-Line FMCS

List of shared area PLMNs

SharedAreaPLMNlist On-Line IUCS

Shared area PLMN identity

SharedAreaPLMNid On-Line IUCS

Shared area Mobile Country Code

SharedAreaMCC On-Line IUCS

Shared area Mobile Network Code

SharedAreaMNC On-Line IUCS

Shared area Mobile Network Code Length

SharedAreaMNClength On-Line IUCS

Table 56 RAN2.0060: IMSI based handover

322 DN03471612




List of shared area PLMNs

SharedAreaPLMNlist On-Line IUPS

Shared area PLMN identity

SharedAreaPLMNid On-Line IUPS

Shared area Mobile Country Code

SharedAreaMCC On-Line IUPS

Shared area Mobile Network Code

SharedAreaMNC On-Line IUPS

Shared area Mobile Network Code Length

SharedAreaMNClength On-Line IUPS

Identifier of the Default Authorised Network

DefaultAuthorisedNet-workId

On-Line RNC

Authorised Network Iden-tifier

AuthorisedNetworkId Not modifiable WANE

List of authorised Networks

AuthorisedNetworkList On-Line WANE

Authorised Network PLMN

AuthorisedNetworkPLMN On-Line WANE

Authorised Network Mobile Country Code

AuthorisedNetworkMCC On-Line WANE

Authorised Network Mobile Network Code

AuthorisedNetworkMNC On-Line WANE

Authorised Network Mobile Network Code Length

AuthorisedNetworkMNC-length

On-Line WANE

Technology used in the Authorised Network

Technology On-Line WANE

WANE Name WANEName On-Line WANE

GSM Roaming allowed GSMRoaming On-Line WSG

Subscriber Home PLMN HomePLMN On-Line WSG

Home PLMN Mobile Country Code

HomePlmnMCC On-Line WSG

Home PLMN Mobile Network Code

HomePlmnMNC On-Line WSG

Home PLMN Mobile Network Code Length

HomePlmnMNCLength On-Line WSG

Name of the subscriber home PLMN

OperatorName On-Line WSG

Subscriber Group Identi-fier

SubscriberGroupId Not modifiable WSG

Identifier of the Autho-rised Network

WSGAuthorisedNet-workId

On-Line WSG

IMSI Based GSM HO IMSIbasedGsmHo On-Line FMCG


Object

Table 56 RAN2.0060: IMSI based handover (Cont.)

DN03471612 323



35.3.7 RAN140: Load and service based IS/IF handover


Object

NCHO activity of common load measurement DRNC cell

AdjiComLoadMeas-DRNCCellNCHO

On-Line ADJI

CPICH EcNo offset for the non-critical HO procedure

AdjiEcNoOffsetNCHO On-Line ADJI

Handling of blocked IF neighbor cell in SLHO procedure

AdjiHandlingBlocked-CellSLHO

On-Line ADJI

Minimum interval between repetitive inter-RAT SLHOs

GsmMinSLHOInterval On-Line FMCG

Minimum interval between repetitive IF SLHOs

InterFreqMinSLHOInter-val

On-Line FMCI

Minimum RX level for non-critical HO

AdjgMinRxLevNCHO On-Line HOPG

Penalty time for GSM cell in non-critical HO

AdjgPenaltyTimeNCHO On-Line HOPG

neighbor cell priority for SLHO

AdjgPrioritySLHO On-Line HOPG

Minimum CPICH Ec/No for non-critical IFHO

AdjiMinEcNoNCHO On-Line HOPI

Minimum CPICH RSCP for non-critical IFHO

AdjiMinRscpNCHO On-Line HOPI

Penalty time for WCDMA cell in non-critical HO

AdjiPenaltyTimeNCHO On-Line HOPI

neighbor cell priority for service and load IFHO

AdjiPrioritySLHO On-Line HOPI

Load handover minimum NRT DCH allocation time

LHOMinNrtDchAllocTime On-Line RNC

NCHO filter coefficient common load meas DRNC cell

NCHOFilterCoeffCom-LoadMeasDRNCCell

On-Line RNC

NCHO hysteresis common load measure-ment DRNC cell

NCHOHystComLoad-MeasDRNCCell

On-Line RNC

NCHO threshold common load measurement DRNC cell

NCHOThrComLoad-MeasDRNCCell

On-Line RNC

RANAP cause to indicate load handover

RANAPCauseLoadHO On-Line RNC

RANAP cause 1 to indicate load handover

RANAPCause1LoadHO On-Line RNC

Table 57 RAN140: Load and service based IS/IF handover

324 DN03471612








RANAP cause to indicate service handover

RANAPCauseServHO On-Line RNC

RANAP cause 1 to indicate service handover

RANAPCause1ServHO On-Line RNC





CM allowed for NRT con-nection in SLHO

SLHOCmAllowedNRT On-Line RNC

SLHO handling of cell load measurement is not active

SLHOHandlingOfCell-LoadMeasNotAct

On-Line RNC

Service profile for back-ground PS NRT data in SLHO

SLHOProfileBackground-PSNRTData

On-Line RNC

Service profile for conver-sational CS speech in SLHO

SLHOProfileConvC-SSpeech

On-Line RNC

Service profile for conver-sational CS T data in SLHO

SLHOProfileConvCST-Data

On-Line RNC

Service profile for conver-sational PS RT data in SLHO

SLHOProfileConvPSRT-Data

On-Line RNC

Service profile for conver-sational PS speech in SLHO

SLHOProfile-ConvPSSpeech

On-Line RNC

Service profile for interac-tive PS NRT data in SLHO

SLHOProfileInteractive-PSNRTData

On-Line RNC

Service profile for stream-ing CS NT data in SLHO

SLHOProfileStreamC-SNTData

On-Line RNC

Service profile for stream-ing PS RT data in SLHO

SLHOPro-fileStreamPSRTData

On-Line RNC

Use of SLHO for back-ground PS NRT data

SLHOUseBackground-PSNRTData

On-Line RNC

Use of SLHO for conver-sational CS speech

SLHOUseConvC-SSpeech

On-Line RNC


Object

Table 57 RAN140: Load and service based IS/IF handover (Cont.)

DN03471612 325



Use of SLHO for conver-sational CS transparent data

SLHOUseConvCSTData On-Line RNC

Use of SLHO for conver-sational PS RT data

SLHOUseConvPSRT-Data

On-Line RNC

Use of SLHO for conver-sational PS speech

SLHOUseC-onvPSSpeech

On-Line RNC

Use of SLHO for interac-tive PS NRT data

SLHOUseInteractive-PSNRTData

On-Line RNC

Use of SLHO for stream-ing CS non-transparent data

SLHOUseStreamCSNT-Data

On-Line RNC

Use of SLHO for stream-ing PS RT data

SLHOUseStreamPSRT-Data

On-Line RNC

Load HO DL NRT capacity request rejection rate

LHOCapaReqRejRateDL On-Line WCEL

Load HO UL NRT capacity request rejection rate

LHOCapaReqRejRateUL On-Line WCEL

Delay to broadcast NRT load based HO state over

LHODelayOFFCapaR-eqRejRate

On-Line WCEL

Delay to broadcast hard blocking load based HO state over

LHODelayOFFHard-Blocking

On-Line WCEL

Delay to broadcast inter-ference load based HO state over

LHODelayOFFInterfer-ence

On-Line WCEL

Delay to broadcast DL SC load based HO state over

LHODelayOFFRes-RateSC

On-Line WCEL

Load HO hard blocking base load

LHOHardBlockingBaseL-oad

On-Line WCEL

Load HO hard blocking ratio

LHOHardBlockingRatio On-Line WCEL

Hysteresis for NRT load measurement of LHO

LHOHystTimeCapaR-eqRejRate

On-Line WCEL

Hysteresis for hard blocking measurement of LHO

LHOHystTimeHardBlock-ing

On-Line WCEL

Hysteresis for interfer-ence measurement of LHO

LHOHystTimeInterfer-ence

On-Line WCEL

Hysteresis for DL SC measurement of LHO

LHOHystTimeRes-RateSC

On-Line WCEL


Object


326 DN03471612




Load HO NRT traffic base load

LHONRTTrafficBaseLoad On-Line WCEL

Number of UEs in inter-frequency load HO

LHONumbUEInterFreq On-Line WCEL

Number of UEs in inter-RAT load HO

LHONumbUEInterRAT On-Line WCEL

Load HO DL power offset LHOPwrOffsetDL On-Line WCEL

Load HO UL power offset LHOPwrOffsetUL On-Line WCEL

Load HO reservation rate of DL spreading codes

LHOResRateSC On-Line WCEL

Window size for NRT load measurement to stop LHOs

LHOWinSizeOFFCapaR-eqRejRate

On-Line WCEL

Window size for hard blocking measurement to stop LHOs

LHOWinSizeOFFHard-Blocking

On-Line WCEL

Window size for interfer-ence measurement to stop LHOs

LHOWinSizeOFFInterfer-ence

On-Line WCEL

Window size for DL SC reservation rate measure-ment to stop LHOs

LHOWinSizeOFFRes-RateSC

On-Line WCEL

Window size for NRT load measurement to start LHOs

LHOWinSizeONCapaR-eqRejRate

On-Line WCEL

Window size for hard blocking measurement to start LHOs

LHOWinSizeONHard-Blocking

On-Line WCEL

Window size for interfer-ence measurement to start LHOs

LHOWinSizeONInterfer-ence

On-Line WCEL

Window size for DL SC reservation rate measure-ment to start LHOs

LHOWinSizeONRes-RateSC

On-Line WCEL

Maximum number of UEs in CM due to SLHO mea-surement

MaxNumberUECmSLHO On-Line WCEL

Number of inter-fre-quency service HOs

ServHONumbUEInter-Freq

On-Line WCEL

Number of inter-RAT service HOs

ServHONumbUEInter-RAT

On-Line WCEL

Period to start inter-fre-quency service HOs

ServHOPeriodInterFreq On-Line WCEL

Period to start inter-RAT service HOs

ServHOPeriodInterRAT On-Line WCEL


Object


DN03471612 327



35.3.8 RAN1275: Inter-system handover cancellation

35.3.9 RAN1191: Detected set reporting and measurements

Maximum number of UEs in CM due to critical HO measurement

MaxNumberUECmHO On-Line WCEL


Object



Object

DL DPCH Transmission Power Cancellation Offset

DLDPCHTxPwrClOffset On-Line FMCG

ISHO Cancellation caused by CPICH Ec/No

ISHOCl-causeCPICHEcNo

On-Line FMCG

ISHO Cancellation caused by CPICH RSCP

ISHOClcauseCPICHrscp On-Line FMCG

ISHO Cancellation caused by DL DPCH TX Power

ISHOClcauseTxPwrDL On-Line FMCG

ISHO Cancellation caused by UE TX Power

ISHOClcauseTxPwrUL On-Line FMCG

Inter-System Handover Cancellation

ISHOCancellation On-Line RNC

Max Number of ISHO Cancellations Per Active Set for a U

MaxNumISHOClPerAS On-Line RNC

Table 58 RAN1275: Inter-system handover cancellation


Object

Usage of Directed Retry of AMR call Inter-system Handov

AMRDirReCell On-Line FMCG

Table 59 RAN928: Directed Retry AND Inter-system Handover Cancellation


Object

Detected Set Reporting Based SHO

DSRepBasedSHO On-Line FMCS

Table 60 RAN1191: Detected set reporting and measurements

328 DN03471612




35.3.10 RAN1515: HSPA inter-RNC cell change

35.3.11 RAN1276: HSDPA inter-frequency handover


Object

SIRerror threshold for the serving HS-DSCH cell

HSDPASIRErrorServCell On-Line RNC

CPICH Ec/No window for serving HS-DSCH cell selection

HSDPAServCellWindow On-Line RNC

DRNC Ec/No offset for HSPA Inter-RNC Cell Change

HSPADRNCEcNoOffset On-Line RNC

SIR error offset for HSPA Inter-RNC Cell Change

HSPADRNCSIRErrorOff-set

On-Line RNC

HSPA Inter-RNC Mobility HSPAInterRNCMobility On-Line RNC

Table 61 RAN1515: HSPA inter-RNC cell change


Object

ADJI HSPA Cell for Non Critical Handover

AdjiNCHOHSPASupport On-Line ADJI



neighbor Cell Prority for HSPA Capability Based HO

AdjiPriorityHSCAHO On-Line HOPI

RAB Combinations Sup-ported by HSCAHO

HSCAHORabCombSup-port

On-Line RNC

TGPL for AMR and HSDPA and IF measure-ment

TGPLAMRHSDPAInter-Freq

On-Line RNC

TGPL for HSDPA and IF measurement

TGPLHSDPAInterFreq On-Line RNC

BTS support for HSPA CM

BTSSupportForHSPACM On-Line WBTS

HSPA Capability Based Handover Max Number of UE

HSCapabilityHONumbUE On-Line WCEL

HSPA Capability Based Handover Period

HSCapabilityHOPeriod On-Line WCEL



Table 62 RAN1276: HSDPA inter-frequency handover

DN03471612 329



35.3.12 RAN1596: HSPA Capability based Handover

35.3.13 RAN146: Power Balancing

Max number of UEs in HSDPA CM due to critical HO

MaxNumberUEHSPAC-mHO

On-Line WCEL

Max number of UEs in HSDPA CM due to NCHO

MaxNumberUEHSPAC-mNCHO

On-Line WCEL


Object

Table 62 RAN1276: HSDPA inter-frequency handover (Cont.)


Object

HSPA Capability Based Handover

HSPACapaHO On-Line WCEL

ADJI HSPA Cell for Non Critical Handover

AdjiNCHOHSPASupport On-Line ADJI



Neighbor Cell Prority for HSPA Capability Based HO

AdjiPriorityHSCAHO On-Line HOPI

RAB Combinations Sup-ported by HSCAHO

HSCAHORabCombSup-port

On-Line RNC

HSPA Capability Based Handover Max Number of UE

HSCapabilityHONumbUE On-Line WCEL

HSPA Capability Based Handover Period

HSCapabilityHOPeriod On-Line WCEL



Table 63 RAN1596: HSPA Capability based handover


Object

Adjustment period time AdjustmentPeriod On-Line RNC

Adjustment ratio AdjustmentRatio On-Line RNC

Maximum adjustment step

MaxAdjustmentStep On-Line RNC

Table 64 RAN146: Power Balancing

330 DN03471612




35.3.14 RAN1824: Inter-frequency Handover over Iur

35.3.15 RAN966: Multi-Operator Core Network

35.3.16 RAN1.029: Packet scheduler algorithmTable RAN1.029: Packet scheduler algorithm parameters shows RAN1.029: Packet scheduler algorithm parameters used in the context of handover control. For an overview of all parameters related to RAN1.029: Packet scheduler algorithm see Packet Scheduler FAD.

Trigger for sending the updated reference power to BTSs

MinPrefChange On-Line RNC

Power Balancing on/off PowerBalancing On-Line RNC

Reference power subtrac-tion parameter

PrefSubtract On-Line RNC


Object

Table 64 RAN146: Power Balancing (Cont.)


Object

Anchor FMCI Identifier AnchorFmciIdentifier On-Line RNC

Anchor FMCS Identifier AnchorFmcsIdentifier On-Line RNC

Anchor Hopi Identifier AnchorHopiIdentifier On-Line RNC

Anchor Hops Identifier AnchorHopsIdentifier On-Line RNC

Table 65 RAN1824: Inter-frequency Handover over Iur


Object

Multi-Operator Core Network enabled

MOCNenabled On-line RNC

Common MCC CommonMCC On-line RNC

Common MNC CommonMNC On-line RNC

Common MNC Length CommonMNCLength On-line RNC

Iu Operator information IuOperator On-line RNC

MIB PLMN Identity Included

MIBPLMNIdIncluded On-line RNC

Multiple PLMN List Included

Multiple PLMN List Included

Requires object locking WCEL

Table 66 RAN966: Multi-Operator Core Network

DN03471612 331




Object

Higher Layer Scheduling mode selection

HLSModeSelection On-Line RNC

Gap position single frame GapPositionSingleFrame On-Line RNC

Transmision gap pattern length in case of double frame: NRT PS service and GSM measurement

TGPLdoubleframeN-RTPSgsm

On-Line RNC

Transmision gap pattern length in case of double frame: NRT PS service and IF measurement

TGPLdoubleframeN-RTPSinterFreq

On-Line RNC

Transmision gap pattern length in case of single frame: AMR service and GSM measurement

TGPLsingleframeAM-Rgsm

On-Line RNC

Transmision gap pattern length in case of single frame: AMR service and IF measurement

TGPLsingleframeAM-RinterFreq

On-Line RNC

Transmision gap pattern length in case of single frame: CS service and GSM measurement

TGPLsingleframeCSgsm On-Line RNC

Transmision gap pattern length in case of single frame: CS service and IF measurement

TGPLsingleframeCSin-terFreq

On-Line RNC

Transmision gap pattern length in case of single frame: NRT PS service and GSM measurement

TGPLsingleframeN-RTPSgsm

On-Line RNC

Transmision gap pattern length in case of single frame: NRT PS service and IF measurement

TGPLsingleframeN-RTPSinterFreq

On-Line RNC

Transmision gap pattern length in case of single frame: RT PS service and GSM measurement

TGPLsingle-frameRTPSgsm

On-Line RNC

Transmision gap pattern length in case of single frame: RT PS service and IF measurement

TGPLsingle-frameRTPSinterFreq

On-Line RNC

Compressed Mode: Alter-native scrambling code

AltScramblingCodeCM On-Line WCEL

Offset for transmitted power

PtxOffset On-Line WCEL

Table 67 RAN1.029: Packet scheduler algorithm parameters

332 DN03471612




35.3.17 RAN1011: HSPA layering for UEs in common channels

35.3.18 Handover control basic functionality

Offset for received power PrxOffset On-Line WCEL


Object

Table 67 RAN1.029: Packet scheduler algorithm parameters (Cont.)


Object

Services for DRRC con-nection setup for HSDPA layer

DRRCForHSDPALay-erServices

On-Line RNC

DRRC connection setup for HSDPA layer enhancements

DirectedRRCForHSDPA-LayerEnhanc

On-Line RNC

Disable power in decision making for HSDPA layering

DisablePowerInHSDPA-LayeringDecision

On-Line RNC

HSDPA layers load sharing threshold

HSDPALayerLoadShare-Threshold

On-Line RNC

Services to HSDPA layer in state transition

ServicesToHSDPALayer On-Line RNC

Services between HSDPA layers

ServBtwnHSDPALayers On-Line RNC

Cell weight for HSDPA layering

CellWeightForHSDPA-Layering

On-Line WCEL

HSDPA layering for UEs in common channels enabled

HSDPALayeringCom-monChEnabled

On-Line WCEL

Table 68 RAN1011: HSPA layering for UEs in common channels


Object

Dedicated Measurement Reporting Period

DedicatedMeasReport-Period

Requires object locking WBTS

Dedicated Measurement Reporting Period CS data

DediMeasRepPeriodCS-data


Dedicated Measurement Reporting Period PS data

DediMeasRepPeriodPS-data


Measurement filter coeffi-cient

MeasFiltCoeff On-Line WBTS

Table 69 Handover control basic functionality

DN03471612 333



35.3.19 HSDPA basic functionalityTable HSDPA basic functionality shows HSDPA parameters related to handover control. For information on all parameters related to HSDPA see RRM of HSDPA FAD.

35.3.20 RAN 964: Directed RRC Connection Setup for HSDPA Layer

NBAP Communication Mode

NBAPCommMode Not modifiable WBTS

Use of HCS UseOfHCS On-Line WCEL

Directed RRC connection setup enabled

DirectedRRCEnabled On-Line WCEL

Drop Reporting Interval DropReportingInterval On-Line FMCS


Object

Table 69 Handover control basic functionality (Cont.)


Object

Maximum number of HSDPA users

MaxNumberHSDPAUs-ers

On-Line WCEL

Table 70 HSDPA basic functionality


Object

Directed RRC connection setup enabled

DirectedRRCEnabled On-Line WCEL

Services for DRRC con-nection setup for HSDPA layer

DRRCForHSDPALay-erServices

On-Line RNC

DRRC connection setup for HSDPA layer enhancements

DirectedRRCForHSDPA-LayerEnhanc

On-Line RNC

Disable power in decision making for HSDPA layering

DisablePowerInHSDPA-LayeringDecision

On-Line RNC

HSDPA layers load sharing threshold

HSDPALayerLoadShare-Threshold

On-Line RNC

Cell weight for HSDPA layering

CellWeightForHSDPA-Layering

On-Line WCEL

Directed RRC connection setup for HSDPA layer enabled

DirectedRRCForHSDPA-LayerEnabled

On-Line WCEL

Table 71 RAN 964: Directed RRC Connection Setup for HSDPA Layer

334 DN03471612




35.3.21 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhance-ments


Object

IBTS Sharing IBTSSharing On-Line IUR

Type of the neighboring RNW Element

neighboringRNWElement On-Line IUR

RNSAP Congestion And Preemption

RNSAPCongAndPre-emption

On-Line IUR

DCH Scheduling Over Iur DCHScheOverIur On-Line RNC

RAB Combinations Sup-ported by IBTS

IBTSRabCombSupport On-Line RNC

ISHO In Iur Mobility ISHOInIurMobility On-Line RNC

Priority handling over Iur-interface

IurPriority On-Line RNC

List of neighboring IBTS and SRNC Identifiers

ControllerIdList On-Line VBTS

neighboring IBTS Identi-fier and Its SRNC Identi-fier

ControllerIdPair On-Line VBTS

I-HSPA Adapter Identifier IHSPAadapterId On-Line VBTS

Serving RNC Identifier ServingRNCId On-Line VBTS

Dedicated Measurement Reporting Period CS data

DediMeasRepPeriodCS-data

On-Line VBTS

Dedicated Measurement Reporting Period PS data

DediMeasRepPeriodPS-data

On-Line VBTS

Dedicated Measurement Reporting Period

DedicatedMeasReport-Period

On-Line VBTS

Measurement filter coeffi-cient

MeasFiltCoeff On-Line VBTS

Change Origin VBTSChangeOrigin Not modifiable VBTS

Time Stamp VBTSTimeStamp Not modifiable VBTS

Time Stamp day VBTSDay Not modifiable VBTS

Time Stamp hours VBTSHours Not modifiable VBTS

Time Stamp hundredths of seconds

VBTSHundredths Not modifiable VBTS

Time Stamp minutes VBTSMinutes Not modifiable VBTS

Time Stamp month VBTSMonth Not modifiable VBTS

Time stamp seconds VBTSSeconds Not modifiable VBTS

Time Stamp year VBTSYear Not modifiable VBTS

Configured CS AMR mode sets

CSAMRModeSET On-Line VCEL

Table 72 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements

DN03471612 335



Configured CS WAMR mode sets

CSAMRModeSETWB On-Line VCEL

Eb/No parameter set identifier

EbNoSetIdentifier On-Line VCEL

Maximum allowed DL user bit rate in HHO

HHoMaxAllowedBitrat-eDL

On-Line VCEL

Maximum allowed UL user bit rate in HHO

HHoMaxAllowedBitra-teUL

On-Line VCEL

Initial bit rate in downlink InitialBitRateDL On-Line VCEL

Initial bit rate in uplink InitialBitRateUL On-Line VCEL

Location area code LAC On-Line VCEL

Maximum downlink bit rate for PS domain NRT data

MaxBitRateDLPSNRT On-Line VCEL

Maximum uplink bit rate for PS domain NRT data

MaxBitRateULPSNRT On-Line VCEL

Minimum allowed bit rate in downlink

MinAllowedBitRateDL On-Line VCEL

Minimum allowed bit rate in uplink

MinAllowedBitRateUL On-Line VCEL

NRT FMCG Identifier NrtFmcgIdentifier On-Line VCEL

NRT FMCI Identifier NrtFmciIdentifier On-Line VCEL

NRT FMCS Identifier NrtFmcsIdentifier On-Line VCEL

NRT HOPG Identifier NrtHopgIdentifier On-Line VCEL

NRT HOPI Identifier NrtHopiIdentifier On-Line VCEL

NRT HOPS Identifier NrtHopsIdentifier On-Line VCEL

Routing Area Code RAC On-Line VCEL

Usage of Relocation Commit procedure in inter RNC HHO

RelocComm_in_InterRNC_HHO

On-Line VCEL

RT FMCG Identifier RtFmcgIdentifier On-Line VCEL

RT FMCI Identifier RtFmciIdentifier On-Line VCEL

RT FMCS Identifier RtFmcsIdentifier On-Line VCEL

RT HOPG Identifier RtHopgIdentifier On-Line VCEL

RT HOPI Identifier RtHopiIdentifier On-Line VCEL

RT HOPS Identifier RtHopsIdentifier On-Line VCEL

Rx Diversity Indicator RxDivIndicator On-Line VCEL

Change Origin VCELChangeOrigin Not modifiable VCEL

Time Stamp VCELTimeStamp Not modifiable VCEL


Object

Table 72 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements (Cont.)

336 DN03471612




35.3.22 RAN955: Power Saving Mode for BTS

Time Stamp day VCELDay Not modifiable VCEL

Time Stamp hours VCELHours Not modifiable VCEL

Time Stamp hundredths of seconds

VCELHundredths Not modifiable VCEL

Time Stamp minutes VCELMinutes Not modifiable VCEL

Time Stamp month VCELMonth Not modifiable VCEL

Time Stamp seconds VCELSeconds Not modifiable VCEL

Time Stamp year VCELYear Not modifiable VCEL


Object

Table 72 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements (Cont.)

Parameter name Abbreviated nameModifiable / system-

defined Object

Cell shutdown allowed with drifting UE PWSMDriftAllowed On-Line RNC

Duration of low traffic for cell shutdown PWSMDuration On-Line RNC

Time limit for traffic to activate a shutdown cell

PWSMExceededTraf-ficDur On-Line RNC

The PWSM usage in BTS PWSMInUse On-Line WBTS

PWSM Shutdown Time Begin Hour for remaining cell

PWSMRemCellSDBegin-Hour On-Line WBTS

PWSM Shutdown Time Begin Minute for remain-ing cell

PWSMRemCellSDBegin-Min On-Line WBTS

PWSM Shutdown Time End Hour for remaining cell

PWSMRemCellSDEnd-Hour On-Line WBTS

PWSM Shutdown Time End Minute for remaining cell

PWSMRemCellSDEnd-Min On-Line WBTS

Hour when the cell shutdown window starts

PWSMShutdownBegin-Hour On-Line WBTS

Minute when the cell shutdown window starts

PWSMShutdownBegin-Min On-Line WBTS

Hour when the cell shutdown window ends

PWSMShutdownEnd-Hour On-Line WBTS

Minute when the cell shutdown window ends PWSMShutdownEndMin On-Line WBTS

Weekday for shutdown PWSMWeekday On-Line WBTS

Table 73 RAN955: Power Saving Mode for BTS

DN03471612 337



35.3.23 RAN1201: Support for Fractional DPCH

Limit for NRT HSDPAsPWSMAVLimitNRTHS-DPA On-Line WCEL

RT DCH power limit for activation PWSMAVLimitRTDCH On-Line WCEL

Limit for RT HSDPAs PWSMAVLimitRTHSDPA On-Line WCEL

NRT HSDPA power per user limit

PWSMAVPwrNRTHS-DPA On-Line WCEL

RT HSDPA power limit for activation PWSMAVPwrRTHSDPA On-Line WCEL

The PWSM cell group of a cell. PWSMCellGroup On-Line WCEL

Power limit for virtual AC PWSMEXPwrLimit On-Line WCEL

User limit for virtual AC PWSMEXUsrLimit On-Line WCEL

NRT DCH limit for shutdown PWSMSDLimitNRTDCH On-Line WCEL

Limit for NRT HSDPAsPWSMSDLimitNRTHS-DPA On-Line WCEL

RT DCH limit for shutdown PWSMSDLimitRTDCH On-Line WCEL

Limit for RT HSDPAs PWSMSDLimitRTHSDPA On-Line WCEL

NRT HSDPA power per user margin

PWSMSDPwrNRTHS-DPA On-Line WCEL

RT DCH Power limit for shutdown PWSMSDPwrRTDCH On-Line WCEL

RT HSDPA power limit for shutdown PWSMSDPwrRTHSDPA On-Line WCEL

The shutdown order of cells in one PWSM cell group PWSMShutdownOrder On-Line WCEL

Shutdown of a remaining cell PWSMShutdownRemCell On-Line WCEL


defined Object

Table 73 RAN955: Power Saving Mode for BTS (Cont.)


defined Object

AM RLC configuration for SRB on HSPA AMRLCSRBHSPA On-Line RNC

AM RLC round trip time for SRB on HSPA

AMRLCRespTimeSRBH-SPA On-Line RNC

Table 74 RAN1201: Support for Fractional DPCH

338 DN03471612




AM RLC MaxDAT trans-missions for SRB on HSPA

AMRLCSRBHSPAMax-DAT On-Line RNC

AM RLC status period max for SRB on HSPA

AMRLCSRBHSPAPeri-odMax On-Line RNC

AM RLC status period min for SRB on HSPA

AMRLCSRBHSPAPeri-odMin On-Line RNC

AM RLC period Poll_PDU for SRB on HSPA

AMRLCSRBHSPA-PollPDU On-Line RNC

AM RLC period Poll_SDU for SRB on HSPA

AMRLCSRBHSPA-PollSDU On-Line RNC

AM RLC period Poll_Window for SRB on HSPA

AMRLCSRBHSPAPoll-Window On-Line RNC

AM RLC status report triggers for SRB on HSPA

AMRLCSRBHSPATrig-gers On-Line RNC

Offset for activation time of SRBs on HSPA ATOSRBsOnHSPA On-Line RNC

Activity factor for SRB on HSDPA bearer AfSRBOnHSDPA On-Line RNC

CPICH EcNo for SRB on HSPA CPICHECNOSRBHSPA On-Line RNC

CPICH RSCP Threshold for SRBs on HSDPA

CPICHRSCPThreSRBHSDPA On-Line RNC

HSDPA Discard Timer for the CS voice service DiscardTimerHSCSVoice On-Line RNC

E-DCH maximum # of HARQ retransmissions for 10 ms SRB EDCHMaxHarqReTxSRB On-Line RNC

Minimum interval between F-DPCH alloca-tions FDPCHAllocMinInterval On-Line RNC

F-DPCH and SRBs on HSPA per TC

FDPCHAndSRBOnHS-PATC On-Line RNC

CPICH Ec/No window for SRBs on HS-DSCH cell selection HSDPASRBWindow On-Line RNC

HSPA for priority conver-sational call enabled HSPAForPriEnabled On-Line RNC

Max buffer time of the HS CS voice in RNC E-TTI 10 ms MaxCSDelayRNCETTI10 On-Line RNC

Max buffer time of the HS CS voice in RNC E-TTI 2 ms MaxCSDelayRNCETTI2 On-Line RNC


defined Object

Table 74 RAN1201: Support for Fractional DPCH (Cont.)

DN03471612 339



Max buffer time of the HS CS voice in UE MaxCSDelayUE On-Line RNC

E-DCH max number of retransmissions CS voice E-TTI 10

MaxEHARQReTxCSAMR10 On-Line RNC

E-DCH max number of retransmissions CS voice E-TTI 2

MaxEHARQReTxCSAMR2 On-Line RNC

Maximum Set of E-DPDCHs for CS voice E-TTI 10

MaxSetOfEDPDCHCSAMR10 On-Line RNC

Maximum Set of E-DPDCHs for CS voice E-TTI 2

MaxSetOfEDPDCHCSAMR2 On-Line RNC

HARQ power offset for E-DCH MAC-d flow of CS voice

PowerOffsetEHAR-QVoice On-Line RNC

Priority for SRBs on HSPA PriForSRBsOnHSPA On-Line RNC

HSDPA re-ordering release timer T1 for the CS voice T1HSCSVoice On-Line RNC

Carrier to interference ratio for F-DPCH CIRForFDPCH On-Line WCEL

F-DPCH code change enabled

FDPCHCodeChangeEn-abled On-Line WCEL

F-DPCH enabled FDPCHEnabled On-Line WCEL

F-DPCH setup FDPCHSetup On-Line WCEL

F-DPCH maximum trans-mission power PtxFDPCHMax On-Line WCEL

F-DPCH minimum trans-mission power PtxFDPCHMin On-Line WCEL

The power offset of F-DPCH for SHO PtxOffsetFDPCHSHO On-Line WCEL

Maximum value for dynamic total tx power PtxTargetTotMax On-Line WCEL

Minimum value for dynamic total tx power PtxTargetTotMin On-Line WCEL

TPC command error rate target TPCCommandERTarget On-Line WCEL

Max nbr of conv users per reserved HS-SCCH code UsersPerHSSCCHCode On-Line WCEL


defined Object


340 DN03471612




35.3.24 RAN1231: Support for HSPA over Iur

35.3.25 RAN1642: MIMO

35.3.26 RAN1906: Dual-Cell HSDPA 42 Mbps

Eb/N0 planned for the E-DCH MAC-d flow of CS voice EbNoEDCHCSAMR On-Line WRAB


defined Object


Name AbbreviationModifiable / system-

defined Object

Anchor FMCI Identifier AnchorFmciIdentifier On-Line RNC

Anchor FMCS Identifier AnchorFmcsIdentifier On-Line RNC

Anchor Hopi Identifier AnchorHopiIdentifier On-Line RNC

Anchor Hops Identifier AnchorHopsIdentifier On-Line RNC

Table 75 RAN1231: Support for HSPA over Iur


defined Object

MIMO Enabled MIMOEnabled Requires object locking WCEL

MIMO HSDPA Capability Handover MIMOHSDPACapaHO On-Line WCEL

Table 76 RAN1642: MIMO


defined Object

DC HSDPA Capability HO DCellHSDPACapaHO WCEL

DC HSDPA Enabled DCellHSDPAEnabled WCEL

DC HSDPA FMCS Identi-fier DCellHSDPAFmcsId WCEL

Max number HSDPA users per MAChs/ehs scheduler MaxNumbHSDPAUsersS

WCEL creation and modi-fication WCEL

Max number HSDSCH MACd flows per MAChs/ehs scheduler

MaxNumbHSD-SCHMACdFS


Limit for DC HSDPA users in activation PWSMAVLimitDCHSDPA


Table 77 RAN1906: Dual-Cell HSDPA 42 Mbps

DN03471612 341



35.3.27 RAN1758: Multiple BSIC Identification

35.3.28 RAN2289: Blind IFHO in RAB Setup Phase

Limit for DC HSDPA users in shutdown

PWSMSDLimitDCHS-DPA


Neighbour cell priority for DC HSDPA Capa Based HO

AdjiPriorityDCellCAHO On-line HOPI

Dual Cell versus MIMO preference

DCellVsMIMOPreference On-line RNC


defined Object

Table 77 RAN1906: Dual-Cell HSDPA 42 Mbps (Cont.)


defined Object

Maximum BSIC Identifica-tion Time MaxBSICIdentTime On-line FMCG

Multiple BSIC Identifica-tion

Multiple BSIC Identifica-tion On-line RNC

Table 78 RAN1758: Multiple BSIC Identification


definedObject

MBLBRABSetupEnabled MBLB in RAB Setup Enabled

On-line WCEL

MBLBStateTransEnabled MBLB in State Transition Enabled

On-line WCEL

MBLBInactivityEnabled MBLB in Inactivity Enabled

On-line WCEL

MBLBMobilityEnabled MBLB in Mobility Enabled On-line WCEL

BlindHOIntraBTSQCheck Blind HO Intra BTS Quality Check

On-line BTS

MBLBMobilityOffset MBLB due to Mobility EcNo Offset

On-line FMCI

MBLBMobilityRABComb MBLB due to Mobility RAB Combinations

On-line FMCI

LaySelWeightLoad Layer Selection Weight of Load

On-line PFL

LaySelLowLoadPref Layer Selection Low Load Preferred

On-line PFL

PrefLayerFastMovUECS Preferred Layer for fast moving UE CS

On-line PFL

Table 79 RAN2289: Blind IFHO in RAB Setup Phase

342 DN03471612




PrefLayerFastMovUEPS Preferred Layer for fast moving UE PS

On-line PFL

PrefLayerDCMINRT Preferred Layer for DC&MIMO NRT

On-line PFL

PrefLayerDCMIStr Preferred Layer for DC&MIMO Streaming

On-line PFL

PrefLayerDCMIAMR Preferred Layer for DC&MIMO AMR

On-line PFL

PrefLayerDCMIAMRNRT Preferred Layer for DC&MIMO AMR and NRT

On-line PFL

BlindHOTargetCell Blind HO target cell On-line ADJI

MBLBRABSetupMulti-RAB

MBLB in RAB Setup for Multi RAB

On-line WCEL

BlindHORSCPThr Blind HO RSCP threshold On-line HOPI

BlindHORSCPThrAbove Blind HO RSCP threshold above

On-line PFL

BlindHORSCPThrBelow Blind HO RSCP threshold below

On-line PFL

BlindHORSCPThrTarget Blind HO RSCP threshold for target cell

On-line PFL

BlindHOEcNoThrTarget Blind HO EcNo threshold for target cell

On-line PFL

RACHIntra-FreqMesQuant

RACH Intra Frequency Measurement Quantity

On-line WCEL

RACHInter-FreqMesQuant

RACH Inter Frequency Measurement Quantity

On-line WCEL

CPICHRSCPSRB-MapRRC

CPICH RSCP thr for SRB mapping in RRC setup

On-line WCEL

CUCRSCPThreshold CPICH RSCP Threshold Value For CUC Usage

On-line WCEL

LaySelWeightPrefLayer Layer Selection Weight of Preferred Layer

On-line PFL

LaySelWeightBand Layer Selection Weight of Band

On-line PFL

LaySelWeightRSCP Layer Selection Weight of RSCP

On-line PFL

PreferBandForLayering Preferred Band for Layering

On-line RNC

PFLIdentifier PFL Identifier On-line PFL

PrefLayerR99NRT Preferred Layer for R99 NRT

On-line PFL

PrefLayerR99Str Preferred Layer for R99 Streaming

On-line PFL


definedObject


DN03471612 343



PrefLayerR99AMR Preferred Layer for R99 AMR

On-line PFL

PrefLayerR99AMRNRT Preferred Layer for R99 AMR and NRT

On-line PFL

PrefLayerHSDPANRT Preferred Layer for HSDPA NRT

On-line PFL

PrefLayerHSDPAStr Preferred Layer for HSDPA Streaming

On-line PFL

PrefLayerHSDPAAMR Preferred Layer for HSDPA AMR

On-line PFL

PrefLayerHSD-PAAMRNRT

Preferred Layer for HSDPA AMR and NRT

On-line PFL

PrefLayerHSPANRT Preferred Layer for HSPA NRT

On-line PFL

PrefLayerHSPAStr Preferred Layer for HSPA Streaming

On-line PFL

PrefLayerHSPAAMR Preferred Layer for HSPA AMR

On-line PFL

PrefLayerHSPAAMRNRT Preferred Layer for HSPA AMR and NRT

On-line PFL

PrefLayerFDPCHNRT Preferred Layer for F-DPCH NRT

On-line PFL

PrefLayerFDPCHStr Preferred Layer for F-DPCH Streaming

On-line PFL

PrefLayerFDPCHAMR Preferred Layer for F-DPCH AMR

On-line PFL

PrefLayerFDP-CHAMRNRT

Preferred Layer for F-DPCH AMR and NRT

On-line PFL

PrefLayer64QAMNRT Preferred Layer for 64QAM NRT

On-line PFL

PrefLayer64QAMStr Preferred Layer for 64QAM Streaming

On-line PFL

PrefLayer64QAMAMR Preferred Layer for 64QAM AMR

On-line PFL

PrefLayer64QAMAMRNRT

Preferred Layer for 64QAM AMR and NRT

On-line PFL

PrefLayerMIMONRT Preferred Layer for MIMO NRT

On-line PFL

PrefLayerMIMOStr Preferred Layer for MIMO Streaming

On-line PFL

PrefLayerMIMOAMR Preferred Layer for MIMO AMR

On-line PFL


definedObject


344 DN03471612




PrefLayerMIMOAMRNRT Preferred Layer for MIMO AMR and NRT

On-line PFL

PrefLayerDCHSDNRT Preferred Layer for DC-HSDPA NRT

On-line PFL

PrefLayerDCHSDStr Preferred Layer for DC-HSDPA Streaming

On-line PFL

PrefLayerDCHSDAMR Preferred Layer for DC-HSDPA AMR

On-line PFL

PrefLayerDCHS-DAMRNRT

Preferred Layer for DC-HSDPA AMR and NRT

On-line PFL

PrefLayerCSHSNRT Preferred Layer for CS voice HSPA NRT

On-line PFL

PrefLayerCSHSStr Preferred Layer for CS voice HSPA Streaming

On-line PFL

PrefLayerCSHSAMR Preferred Layer for CS voice HSPA AMR

On-line PFL

PrefLayerCSHSAMRNRT Preferred Layer for CS voice HSPA AMR and NRT

On-line PFL

HSLoadStateHSUOffset HSPA load state HSUPA power offset

On-line WCEL

HSLoadStateHSUBR-Limit

HSPA load state E-DCH bit rate limit

On-line WCEL

HSLoadStateHSDOffset HSPA load state HSDPA power offset

On-line WCEL

HSLoadStateHSDBR-Limit

HSPA load state HSDPA bit rate limit

On-line WCEL

DLLoadStateTTT DL loaded state time to trigger

On-line WCEL

HSLoadStateHSUResThr HSPA Load State HSUPA Resource Threshold

On-line WCEL


definedObject


DN03471612 345

WCDMA RAN RRM Handover Control Related information

Id:Confidential

Related informationHandover control

DescriptionsTypes of handovers

Compressed mode



WCDMA radio resource management

Power control

Types of handovers

DescriptionsFunctionality of intra-frequency handover





Compressed mode

DescriptionsHandover control

Compressed mode preparation signaling

Radio resource management functions





Types of handovers



Inter-frequency handover signaling



346 DN03471612


Id:Confidential

Related information

Types of handovers



Types of handover



Types of handover



Types of handovers


Intra-Frequency hard handover signalling


Types of handovers


Serving RNC relocation signaling


Types of handovers

Description of SRNS relocation

Compressed mode preparation signaling


Compressed mode



Types of handovers


DN03471612 347

WCDMA RAN RRM Handover Control Related information

Id:Confidential



Types of handovers


Handover Control

Documents

Transcript of Handover Control