handover

LTE Radio Access, Rel. RL40, Operating Documentation, Issue 03

Handover

DN0943971

Issue 04A Approval Date 2013-01-31

Confidential

Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their compo-nents.

If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Siemens Networks for any additional information.

2 DN0943971

Handover

Id:0900d805809ad2ecConfidential

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

DN0943971 3

Handover


Table of contentsThis document has 75 pages.

Summary of Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1 Introduction to the Handover Functional Area . . . . . . . . . . . . . . . . . . . . 11

2 Features Related to Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1 Overview of the Parts of this Document. . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Architecture of the Handover Functional Area . . . . . . . . . . . . . . . . . . . . 16

4 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1 Functional Overview - Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.1 Measurements and Measurement Reports . . . . . . . . . . . . . . . . . . . . . . 184.1.2 Handover Target and Mode Selection . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2.1 Enhanced Handover Mode and Target selection. . . . . . . . . . . . . . . . . . 204.1.3 LTE neighbor cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 LTE53: Intra and Inter eNodeB handover via X2 Interface . . . . . . . . . . 224.2.1 General procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.1.1 Inter-eNodeB handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.1.2 Intra-eNodeB handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.2 Target cell list handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 LTE761: Advanced target cell selection and handover retry for intra-fre-

quency handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.1 Advanced Target Cell Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 LTE423: RRC Connection Release with Redirect . . . . . . . . . . . . . . . . . 294.5 LTE54: Intra-LTE Handover via S1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5.1 Functional Overview/Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5.2 Handover trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5.3 Handover Mode selection for S1 based handover. . . . . . . . . . . . . . . . . 304.5.4 Handover over S1 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.4.1 Handover decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.4.2 Handover preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.4.3 Handover execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.4.4 Handover completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5.5 Data forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5.5.1 Support of indirect data forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5.5.2 Resource Allocation at Target eNB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5.6 Performance Counters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.6 LTE55: Inter-frequency Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.6.1 Functional Overview/Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.6.2 Inter-frequency Handover Variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.6.2.1 RSRP for A3 event (Better Cell HO) . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.6.2.2 RSRQ for A3 event (Better Cell HO) . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6.2.3 RSRP for A5 event (Coverage HO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.6.2.4 Th2a for deactivation of A3 and A5 events . . . . . . . . . . . . . . . . . . . . . . 364.6.3 Handover trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.6.4 Performance counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 DN0943971

Handover


4.7 LTE56: Inter RAT Handover to WCDMA . . . . . . . . . . . . . . . . . . . . . . . . 384.7.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.7.1.1 Handover from LTE to WCDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.7.1.2 Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.7.1.3 Connection Mobility Control: Handover (CMC-HO) . . . . . . . . . . . . . . . . 404.7.1.4 Capacity, performance and overload control . . . . . . . . . . . . . . . . . . . . . 424.7.1.5 Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.8 LTE442: Network Assisted Cell Change to GSM . . . . . . . . . . . . . . . . . . 444.8.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.8.1.1 eNACC to GSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.8.1.2 Connection Mobility Control: Handover (CMC-HO) . . . . . . . . . . . . . . . . 464.8.1.3 Capacity, performance and overload control . . . . . . . . . . . . . . . . . . . . . 474.8.1.4 Configuration Management for eNACC . . . . . . . . . . . . . . . . . . . . . . . . . 484.8.1.5 User scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.9 LTE490: Subscriber profile based mobility . . . . . . . . . . . . . . . . . . . . . . . 504.9.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.9.1.1 Handling of LTE490 reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.9.1.2 Licensing of SPID Selective Neighbor Cell lists . . . . . . . . . . . . . . . . . . . 514.9.1.3 Impact on measurement configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 514.9.1.4 Mobility Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.9.1.5 User scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.10 LTE562: CSFB to UTRAN or GSM via redirect . . . . . . . . . . . . . . . . . . . 564.10.1 Functional overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.10.2 Selection of target RAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.11 LTE735: RRC Connection Re-establishment . . . . . . . . . . . . . . . . . . . . . 584.11.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.11.1.1 RRC Connection Re-Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.12 LTE971: Intra-LTE mobility offsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.12.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.12.1.1 Functional overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.12.1.2 Connection Mobility Control: Handover (CMC-HO) . . . . . . . . . . . . . . . . 614.13 LTE736: CS Fallback to UTRAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.13.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.13.1.1 CSFB to UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.14 LTE872: SRVCC to WCDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.14.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.15 LTE873: SRVCC to GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.15.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.16 LTE984: GSM redirect with system information . . . . . . . . . . . . . . . . . . . 674.16.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.16.1.1 CSFB to GSM with system information. . . . . . . . . . . . . . . . . . . . . . . . . . 674.17 LTE1073: Measurement based redirect to UTRAN . . . . . . . . . . . . . . . . 694.17.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.18 LTE1387: Intra eNodeB inter-frequency load balancing . . . . . . . . . . . . . 71

5 Parameters for the Handover Functional Area . . . . . . . . . . . . . . . . . . . . 725.1 Links to Management data ordered by releases. . . . . . . . . . . . . . . . . . . 725.1.1 Management data for RL09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

DN0943971 5

Handover


5.1.2 Management data for RL10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.1.3 Management data for RL20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.1.4 Management data for RL30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.1.5 Management data for RL40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2 LTE423: Parameters for RRC Connection Release with Redirect. . . . . 74

6 DN0943971

Handover


List of figuresFigure 1 Architecture of LTE and inter-RAT handovers . . . . . . . . . . . . . . . . . . . . 16Figure 2 Functional units of a handover procedure. . . . . . . . . . . . . . . . . . . . . . . . 17Figure 3 Message flow for an inter-eNodeB handover . . . . . . . . . . . . . . . . . . . . . 25Figure 4 Message sequence and time delay during CSFB redirection . . . . . . . . . 56

DN0943971 7

Handover


List of tablesTable 1 Features related to handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Table 2 Selected content of the “MeasResults” IE . . . . . . . . . . . . . . . . . . . . . . . 19Table 3 Th1 and Th2 InterFreq are thresholds set by O&M . . . . . . . . . . . . . . . 35Table 4 Th2a InterFreq threshold set by O&M . . . . . . . . . . . . . . . . . . . . . . . . . . 36Table 5 Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Table 6 Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Table 7 Parameters for RRC connection release with redirect . . . . . . . . . . . . . 74

8 DN0943971

Handover

Id:0900d8058099d703Confidential

Summary of Changes

Summary of Changes

Changes between issues 04 (2011-12-16, RL40) and 04A (2013-01-31)

Features Related to Handover (2)

• LTE736: CS fallback to UTRAN added • LTE984: GSM redirect with system information added • LTE1073: Measurement based redirect to UTRAN added • LTE1387: Intra eNodeB inter-frequency load balancing

Functional Overview - Handover (4.1)

• Operator configuration hints added • new MOCs for RL40 in LTE neighbor cell information added • CS-Fallback Mode and Target selection added

LTE736: CS Fallback to UTRAN (4.13)

• chapter LTE736: CS Fallback to UTRAN added

LTE984: GSM redirect with system information (4.16)

• chapter LTE984: GSM redirect with system information added

LTE1073: Measurement based redirect to UTRAN (4.17)

• chapter LTE1073: Measurement based redirect to UTRAN added

LTE1387: Intra eNodeB inter-frequency load balancing (4.18)

• Chapter Lte1387: Intra eNodeB inter-frequency load balancing added

Management data for RL40 (5.1.5)

• chapter for RL40 Management data added

Changes between issues 03 (2011-06-17, RL30) and 04 (2011-12-16, RL40)Editorial changes

Changes between issues 02 (2010-12-10, RL20) and 03 (2011-06-17, RL30)Features Related to Handover (2)

• LTE56: Inter RAT Handover to WCDMA added • LTE442: Network Assisted Cell Change to GSM added • LTE490: Subscriber profile based mobility added • LTE735: RRC Connection Re-establishment added • LTE971: Intra-LTE mobility offsets added • LTE562: CSFB to UTRAN or GSM via redirect added

Functional Overview - Handover (4.1)

• chapter Handover Target and Mode Selection added • chapter LTE neighbor cell information added

LTE56: Inter RAT Handover to WCDMA (4.7)

• chapter LTE56: Inter RAT Handover to WCDMA added

LTE442: Network Assisted Cell Change to GSM (4.8)

DN0943971 9

Handover Summary of Changes


• chapter LTE442: Network Assisted Cell Change to GSM added

LTE490: Subscriber profile based mobility (4.9)

• chapter LTE490: Subscriber profile based mobility added

LTE735: RRC Connection Re-establishment (4.11)

• chapter LTE735: RRC Connection Re-establishment added

LTE971: Intra-LTE mobility offsets (4.12)

• chapter LTE971: Intra-LTE mobility offsets added

Parameters for RL09 (5.1.1)

• chapter for RL09 parameter added







Changes between issues 01A (2010-02-28, RL10) and 02 (2010-12-10, RL20)

• RL20 content addedLTE54: Intra-LTE Handover via S1

• RL20 content addedLTE55: Inter-frequency Handover

10 DN0943971

Handover


Summary of Changes

DN0943971 11

Handover Introduction to the Handover Functional Area

Id:0900d8058095132dConfidential

1 Introduction to the Handover Functional AreaA handover means the change of a radio connection between the network and a UE which already is in connected mode (idle mode mobility is covered by cell selection and reselection). During the handover procedure running services are maintained: a call is not interrupted and for intra LTE handover no datas are lost.

Handovers in LTE are network controlled and UE assisted. With the exception of eNACC, resources are prepared in the target cell before the UE is commanded to move to the target cell. The goal of the handover procedure is to allocate the same resources for the UE in the target cell after the handover as those used prior to the handover. From the UE's point of view, a handover is always “hard”, meaning that a connection exists to only one cell at a time.

Generally, many handover scenarios are supported – at least in future releases –, for example intra-LTE, inter-RAT (for example LTE and UMTS, RAT: radio access technol-ogy). The basic handover type is an intra-LTE handover which is mainly controlled between two eNBs connected via X2 interface (inter-eNB handover). With LTE54: Intra-LTE Handover via S1, scenarios via S1-interface are introduced. In opposite to X2-based handover (LTE53: Intra and inter eNB handover via X2 interface) S1-based handover is routed via the Core Network and therefore provides the possibility to the core to change the serving MME and/or the serving S-GW. The eNB also supports inter-frequency handover in which handover decision is based on RSRP or RSRQ (DL mea-surement). Triggers can be "coverage HO" and "better cell HO". Typically the UE requires measurement gaps for doing inter-frequency measurements, depending on the UE capability. Handover to WCDMA and Network assisted cell change to GSM is possible with the introduction of RL30.

Handovers are based on several reasons:

• Quality: Handovers due to quality are typically initiated as a result of a UE measure-ment report indicating that the UE can communicate with a neighbour cell with a better channel quality than that of the current serving cell.

• Coverage: Handovers due to coverage are also initiated as a result of a UE mea-surement report indicating that the serving cell becomes worse than an absolute threshold.

12 DN0943971

Handover

Id:0900d8058096827eConfidential

Features Related to Handover

2 Features Related to HandoverTable 1 shows all features related to the handover functional area per release.

Feature Related documents Release

LTE53: Intra and inter eNodeB handover via X2 interface

FAD: Handover RL09

LTE761: Advanced target cell selection and handover retry for intra frequency handover

FAD: Handover RL10

LTE423: RRC connection release with redirect. FAD: Handover RL10

LTE22: Emergency Call Handling LTE22: Emergency Call Handling is decribed in the FAD: Call Handling and Bearer management

RL20

LTE54: Intra-LTE Handover via S1 LTE54: Intra-LTE Handover via S1 feature description

RL20

LTE55: Inter-frequency Handover LTE55: Inter-frequency Handover feature descrip-tion

RL20

LTE562: CSFB to UTRAN or GSM via redirect LTE562: CSFB to UTRAN or GSM via redirect feature description

RL20

LTE56: Inter RAT Handover to WCDMA LTE56: Inter RAT Handover to WCDMA feature description

RL30

LTE442: Network Assisted Cell Change to GSM

LTE442: Network Assisted Cell Change to GSM feature description

RL30

LTE490: Subscriber profile based mobility LTE490: Subscriber profile based mobility feature description

RL30

LTE735: RRC Connection Re-establishment LTE735: RRC Connection Re-establishment feature description

RL30

LTE971: Intra-LTE mobility offsets LTE971: Intra-LTE mobility offsets feature description

RL30

LTE736: CS fallback to UTRAN LTE736: CS fallback to UTRAN feature descrip-tion

RL40

LTE872: SRVCC to WCDMA LTE872: SRVCC to WCDMA feature description RL40

LTE873: SRVCC to GSM LTE873: SRVCC to GSM feature description RL40

LTE984: GSM redirect with system information LTE984: GSM redirect with system information feature description

RL40

LTE1073: Measurement based redirect to UTRAN

LTE1073: Measurement based redirect to UTRAN feature description

RL40

LTE1387: Intra eNodeB inter-frequency load balancing

LTE1387: Intra eNodeB inter-frequency load bal-ancing feature description

RL40

Table 1 Features related to handover

DN0943971 13

Handover Features Related to Handover


2.1 Overview of the Parts of this DocumentMeasurements and measurement reportsThe UE continuously performs measurements of downlink reference signals in the current cell and – depending on configurations and conditions – in neighbour cells. Mea-surement reports from the UE are the basis for handovers due to better cell or coverage. The dispatch of a measurement report is triggered by standardized events including configurable thresholds.

Intra and inter eNodeB handover with X2The inter-eNodeB handover is the basic type of a handover within LTE. Intra-eNodeB handover is just a specification of the inter-eNodeB handover.

Handovers in LTE are network controlled and UE assisted. Resources are prepared in the target cell before the UE is commanded to move to the target cell. Data packets whose reception could not be acknowledged before the handover procedure are retransmitted.

Target cell list handlingThe target cell list is a sorted list of potential target cells for the handover. The eNodeB begins with the first entry of the list indicating the highest priority. With “Advanced target cell selection” , the serving eNodeB checks for all handover variants that the highest priority cell is not contained in a blacklist. If the target cell is in a blacklist the eNodeB proceeds to the next target cell of the list.

If an frequency handover attempt fails, a handover retry is performed: The eNodeB retries a handover with the next target cell of the list (including the checks according to “Advanced target cell selection”).

Handover via S1With S1-based handover a UE can be handed over from one LTE cell to another LTE cell (of another eNodeB) without the usage of an X2 interface. X2 interface between Source and Target eNodeB may be not existing, not operable or its use for handover may be forbidden by O&M. In opposite to X2-based handover (LTE53) S1-based handover is routed via the Core Network and therefore provides the possibility to the Core to change the serving MME and/or the serving S-GW.

Inter-frequency HandovereNB supports inter-frequency handover in which handover decision is based on RSRPor RSRQ (DLmeasurement). Triggers can be "coverage HO" and "Better Cell HO". Typically UE requires measurement gaps for doing inter-frequency measure-ments, depending on the UE capability. UE performance measurements are done while data transmission between UE an source eNB still continues. Therefore KPIs like U-plane break duration or C-plane break duration do not depend on these UE performance measurements and the system performance of inter-frequency HO is expected to be the same as for intra-frequency HO.

CSFB to UTRAN or GSM via redirectThe CSFB (Circuit-Switched Fallback) function allows for a service based redirection from LTE to UTRAN or to GERAN during the call setups. Both mobile originated and mobile terminated call setup are supported.

14 DN0943971

Handover


Features Related to Handover

This feature is used to keep CS (Circuit Switched) service voice continuity in the initial phase of LTE implementation, which does not support CS services. As a consequence of this feature, the UE leaves an LTE network and is handled by RAT (Radio Access Technology) capable of CS service.

Inter RAT Handover to WCDMAThe feature allows a service continuity of data services with minimal interruption time when changing from a LTE cell to a WCDMA cell. The functionality is only applicable to multimode devices supporting both LTE and WCDMA at the according frequency band and the according feature support.

Network Assisted Cell Change to GSMThe feature allows for a service continuity of data services when changing from an LTE cell to a GSM cell. NACC is only applicable to NACC capable multimode devices sup-porting both LTE and GSM at the according frequency band. The UE capabilites are provided to the eNB by the feature group indicator.

Subscriber profile based mobilityThe feature allows for subscriber profile ID based traffic steering. A typical use case is national roaming where the SPID provided by the MME is used to identify own subscrib-ers and national roaming subscribers. Another use case would be Multi-operator core Network (MOCN) where each operator can define its own target frequency layer.

RRC Connection Re-establishmentRRC Connection Re-establishment is supported as preferred resolution for temporary Radio link failure or due to physical link failure during handover execution. The Connec-tion Re-establishment procedure is initiated by the UE in RRC connected in case of:

• Radio link failure detection due to for example • Handover failure (T304 expiry) • Integrity check failure indication from lower layers • RRC connection reconfiguration failure

Intra-LTE mobility offsetsWith this feature Offset setting for intra LTE mobility is introduced and the operator is able to optimize the intra LTE mobility by applying different offsets to different target cells. The already existing configurable handover events A3 (better cell) and A5 (cover-age) are extended with the frequency specific offsets and the Cell Individual Offsets (CIOs) for the serving carrier and all other neighbour carriers measurement objects.

CS fallback to UTRANPS handover-based CS fallback from LTE to UTRAN (WCDMA) for mobile-originated and mobile-terminated call setup is supported. The target cell selection is based on fast measurement solicitation.

SRVCC to WCDMASingle radio voice call continuity (SRVCC) to WCDMA is a license-based feature that introduces a handover (HO) variant from LTE to WCDMA allowing continuity for voice calls. A voice call (including emergency session) in LTE, voice over IP (VoIP) using a QoS class indicator (QCI) 1 bearer, might be transferred towards a call in the circuit switched (CS) domain of UMTS if SRVCC is supported towards the target cell and if core network (CN) and the user equipment (UE) support this feature too.

DN0943971 15

Handover Features Related to Handover


SRVCC to GSMSingle radio voice call continuity (SRVCC) to GSM provides mechanism to handover (HO) user equipments (UEs), which have a QoS class indicator (QCI)-1 bearer, voice over IP (VoIP), activated to GSM. The voice bearer which is the subject to handover is served via the circuit switched (CS)-Domain on GERAN side.

GSM redirect with system informationThe CS fallback with redirect to GSM as well as the regular redirect to GSM is enhanced by system information.

Measurement based redirect to UTRANThis feature provides an extended packet-switched mobility function for UEs supporting IRAT measurements but no PS handover.

LTE1073: Measurement based redirect to UTRAN provides the means to send an UE to WCDMA by UE Context Release with Redirect after the UE has performed measurements on WCDMA. Measurement concepts and configuration for handover to WCDMA are reused.

Intra eNodeB inter-frequency load balancingThis feature LTE1387: Intra eNodeB inter-frequency load balancing provides means to move load (in terms of air interface usage) to cells of another frequency/band within the same eNodeB.

16 DN0943971

Handover

Id:0900d805809abce2Confidential

Architecture of the Handover Functional Area

3 Architecture of the Handover Functional AreaFigure 1 shows how LTE handovers are embedded in an overall mobility concept includ-ing interworking with different RATs (radio access technologies). Generally, intra-LTE handovers are mainly handled between two eNodeBs (via X2 or S1 interface), and the serving eNodeB acts as a mobility anchor which means that this eNodeB takes care that no data is lost during handover. The mobility anchor for interworking with other 3GPP technologies such as GSM and UMTS, is the S-GW, while the mobility anchor for seamless mobility to non-3GPP networks such as WiMAX is the P-GW.

Figure 1 Architecture of LTE and inter-RAT handovers

Figure 2 shows major functional units of a handover procedure. Measurements and target cell list handling apply not only to intra-LTE handovers but also to inter-RAT han-dovers.

DN0943971 17

Handover Architecture of the Handover Functional Area

Id:0900d805809abce2Confidential

Figure 2 Functional units of a handover procedure

18 DN0943971

Handover

Id:0900d805809ad334Confidential

Functional Description

4 Functional Description

4.1 Functional Overview - Handover

4.1.1 Measurements and Measurement ReportsThe UE assists the eNB regarding Handover by sending measurement reports. In case of verifying radio conditions due to the UE mobility (for example when the UE moves from one LTE cell to another or because of limited LTE coverage) measurement reports may initiate handover. The type of measurements to be done by the UE and the details of reporting them to the eNB can be configured (measurement configuration and report configuration), and the eNB informs the UE about the configurations via the RRC CONNECTION RECONFIGURATION message.

MeasurementsThe measurement configuration sent by the eNB to the UE includes thresholds control-ling the UEs measurement activities. The UE continuously monitors the RSRP (refer-ence signal received power) of the current (serving) cell, further measurements depend on the relation of the RSRP value of the serving cell to the thresholds TH1 and TH2:

• If the RSRP value exceeds the upper threshold TH1, no measurements of neighbor cell signals are performed.

• If the RSRP value is between the upper threshold TH1 and the lower threshold TH2, RSRP measurements of LTE neigbour cell signals belonging to the same frequency band are performed (currently, TH2 = 0).

• If the RSRP value is below the threshold TH1(also referred to as S-measure in the standard of the measurement configuration), RSRP measurements of LTE neighbor cell signals belonging to the same frequency layer are performed.

• If the RSRP value is below the lower threshold TH2, measurements of neighbor cell signals belonging to other RATs are performed.

Measurement reportsIn order to limit the amount of signaling, the UE only sends measurement reports (MEASUREMENT REPORT messages) to the eNB when certain conditions (events) are met by the UEs measurements. The following events are defined in the standard:

• Event A1: The serving cell becomes better than an absolute threshold. • Event A2: The serving cell becomes worse than an absolute threshold. • Event A3: An LTE neighbor cell becomes better than an offset relative to the serving

cell. • Event A4: An LTE neighbor cell becomes better than an absolute threshold. • Event A5: The serving cell becomes worse than an absolute threshold and an LTE

neighbor cell becomes better than another absolute threshold. • Event B1: A non-LTE neighbor cell becomes better than an absolute threshold. • Event B2: The serving cell becomes worse than an absolute threshold and a non-

LTE neighbor cell becomes better than another absolute threshold.

The events A1 to A5 are related to intra-LTE handovers, the events B1 and B2 are related to inter-RAT handovers. A1 is useful for restricting UE measurements to the

DN0943971 19

Handover Functional Description


serving cell only, A3 is connected with better cell handover, A5 with coverage handover. The events correspond with the types of measurements the UE performs.

Currently, the events A1, A2, A3, A5 and B2 are supported.

The measurement reports contain a list of target cells for handover. The target cells are listed in order of decreasing value of the reporting quantity, i.e. the best cell is reported first. As a consequence of the definition of the events, the target cell list cannot be empty. Handover conditions due to A5 get a higher priority than handovers due to A3.

One MEASUREMENT REPORT message contains one “MeasResults” IE (information element) which includes measurement results of one single measurement, i.e. mea-surements are not combined for reporting purposes. The “MeasResults” IE contains a “MeasResultListEUTRA” IE if potential LTE target cells are available; “MeasResults” includes the following content:

Configuration hints for the operatorThe UE is capable of monitoring, using gaps of three FDD UTRA carriers. In addition to this requirements, the UE is capable of monitoring using gaps a total of at least 7 carrier frequency layers comprising of any defined combination of E-UTRA FDD, E-UTRA TDD, UTRA FDD, UTRA TDD, GSM (one GSM layer corresponds to 32 carriers), cdma2000 1x and HRPD layers.

If the operator has configred more than these number of layers in Mobility Profiles, it can not be guaranteed that the UE really measures all of theme.

4.1.2 Handover Target and Mode SelectionSeveral types of handover procedures can be applied in LTE depending on the selected HO target cell. To select the applicable procedure it needs to be considered whether:

• target cell is an LTE cell or a cell of another RAT (for example UTRAN, GERAN,...) • target cell is served by own eNB or another LTE eNB • X2 connection to Target eNB exists

Handover Target selection is executed in two steps. The first step gives the trigger that a HO shall be executed, defines the urgency of the HO and identifies a prioritized list of

IE Subordinate IE Comment

measResultServCell rsrpResult

rsrqResult

MeasResultListEUTRA-> measResultNeighCells

physCellId (1)

cgi-Info not used

measResult contains:

rsrpResult

rsrqResult

physCellId (2)

...

Table 2 Selected content of the “MeasResults” IE

20 DN0943971

Handover


Functional Description

HO target cells. This is based on measurement reports from the UE but does not consider network internal aspects as for example X2 connectivity or the possibility to perform data forwarding. In the second step, the final HO target decision and, if needed, the retry of HO with another cell after HO preparation failure is performed. Furthermore a new handover preparation is not initiated before a former HO preparation has been finalized (successfully or unsuccessfully).

4.1.2.1 Enhanced Handover Mode and Target selection Depending on the output from RRM Handover Algorithm, the eNB selects the target cell for handover or eNACC and derives the appropriate handover mode from the selected target cell.

Possible HO/eNACC Modes are:

• Intra eNB HO • Intra LTE inter eNB HO via X2 • Intra LTE inter eNB HO via S1 • HO to WCDMA • eNACC to GSM

Handover to WCDMA (UTRAN)All cells in the Target Cell list are checked according to the conditions listed below and are deleted from the Target Cell list if one of the conditions is met. An WCDMA cell is deleted from the TCL if at least one of the conditions listed below are met:

• The Serving PLMN of the UE is not on the list of PLMNs which are supported in the target cell. If a HO Restriction List is available and this list contains “Equivalent PLMNs”, this means that neither the Serving PLMN nor one of the Equivalent PLMNs is contained in the list of PLMNs that are supported in the target cell.

• The Target cell is blacklisted by Operator. • The combination of PLMN-Identity and LAC of the target cell is on the Handover

Restriction List provided by the MME. • Handover Restriction list contains the IE “Forbidden inter RATs” which is set to

“ALL”, “WCDMA”, “GSM and WCDMA” or “CDMA2000 and WCDMA”.

After the Target Cell has been finally selected as a WCDMA cell, the Handover to WCDMA is executed. For WCDMA cells in the target cell list, eNB derives WCDMA Target Cell ID (including RNC ID) from O&M configuration.

Handover to GSM (GERAN)All cells in the Target Cell list are checked according to the conditions listed below and are deleted from the Target Cell list if one of the conditions is met. An GSM cell is deleted from the TCL list if at least one of the conditions listed below are met:

• The Target cell is blacklisted by the Operator. • The Operator has not selected the Target cell for eNACC, for example parameter

eNACC in GeranNeighbourCell is set to 'Not Supported'. • The combination of PLMN-Identity and LAC of the target cell is contained in the

Handover Restriction List provided by MME (or during a previous incoming HO). • Handover Restriction list contains the IE “Forbidden inter RATs” which is set to “ALL”

or “GERAN” or “GERAN and UTRAN”.

DN0943971 21

Handover Functional Description


The Handover mode selection algorithm is extended to take eNACC to GSM into account if the Target Cell is a GSM cell, eNACC to GSM is executed.

CS-Fallback Mode and Target selectionDepending on feature activation, output from RRM Handover Algorithm and UE Capa-bilities, the eNB decides which type of CS Fallback will be used. Possible modes are:

• CS Fallback with PS HO to UTRAN • CS Fallback with redirection to GERAN or UTRAN

4.1.3 LTE neighbor cell informationNeighbor cell information and neighbor cell relations are stored by eNB in managed objects. Cells served by eNB are represented by managed object LNCEL. The relation to neighbor cells for LNCEL are stored in the new introduced object LNREL, where one LNREL represents the neighbor relation of LNCEL to one NbCell.

Compared to RL20 there was a remodelling of LTE neighbor cell information:

• Managed object LNREL is introduced • Managed object LNADJG for providing GSM cell information is introduced • Managed object LNADLP is removed • Managed objects LNADJ and LNADJL are persistently stored by eNB • IP-address used for X2-link establishment are stored in LNADJ

Compared to RL30 new MOCs are introduced:

• Managed object LNRELW is introduced • Managed object LNRELG is introduced

22 DN0943971

Handover

Id:0900d805809ad3feConfidential

4.2 LTE53: Intra and Inter eNodeB handover via X2 Interface

4.2.1 General procedure

4.2.1.1 Inter-eNodeB handoverThe following procedure is performed in case of an inter-eNodeB handover (see Figure 3).

1. The source eNodeB makes the decision to handover the UE to the target eNodeB based on the MEASUREMENT REPORT of the UE and RRM information.

2. The source eNodeB issues a HANDOVER REQUEST message via the X2 interface to the target eNodeB which passes necessary information to prepare the handover at the target side. This message includes signalling references, transport layer addresses and tunnel endpoint identifiers to enable the target eNodeB to communi-cate with the source eNodeB and the EPC nodes, as well as QoS information for the UE's bearers and RRM information.

3. Admission Control is performed by the target eNodeB dependent on the received radio bearer QoS information and S1 connectivity to increase the likelihood of a suc-cessful handover. If the resources can be granted by the target eNodeB, it config-ures the required resources according to the received UE context information, and reserves a C-RNTI (cell radio network temporary identifier) and a dedicated preamble for the UE. One or more U-plane tunnels may also be established between the source and the target eNodeB in order to support data forwarding of downlink PDCP SDUs (PDCP: packet data convergence protocol, SDU: service data unit) that have not been acknowledged by the UE, and optionally any uplink PDCP SDUs which have been received out of order at the source eNodeB. It should be noted that not all bearers are subject to data forwarding (e.g. realtime bearers) and that this is dependent on the bearer's QoS profile.

4. The target eNodeB prepares the handover regarding layer 1 and layer 2 and sends a HANDOVER REQUEST ACKNOWLEDGE message via X2 to the source eNodeB. The HANDOVER REQUEST ACKNOWLEDGE message includes a trans-parent container to be sent to the UE later as part of the CONNECTION RECON-FIGURATION message. The container includes the new C-RNTI and the value of the dedicated preamble to be used by the UE to synchronise with the target cell as well as other parameters required by the UE. The HANDOVER REQUEST ACKNOWLEDGE message also contains transport network layer information for the forwarding tunnels, if necessary, and completes the setup of the X2 signalling con-nection with the source eNodeB.

5. The source eNodeB sends a CONNECTION RECONFIGURATION message towards the UE, which includes the transparent container (of the previous step) received from the target eNodeB. The source eNodeB performs the necessary integrity protection and ciphering of the message. Once this message has been sent the source eNodeB begins implementing a means to minimize data loss.

6. The SN STATUS TRANSFER message is sent from the source to the target eNodeB. Thereby PDCP layer information is transferred to ensure uplink and downlink PDCP SN continuity for every bearer that requires PDCP status preserva-tion. For each bearer this message contains: • The downlink SN the target eNodeB should assign to the first SDU which does

not have a SN yet.

DN0943971 23

Handover


• The SN of the next uplink SDU the target eNB should send to the S-GW. • Optionally, a status report created by the source eNodeB for the UE's uplink data

which includes a list of the SNs that the UE needs to retransmit in the target cell, if there are any such SDUs.

7. Some time after sending the CONNECTION RECONFIGURATION message to the UE (and possibly before sending the SN STATUS TRANSFER message to the target eNodeB), the source eNodeB begins forwarding user data in the form of PDCP SDUs using the resources set up previously and continues as long as packets are received at the source eNB from the EPC. All SDUs which have already been allocated a SN are forwarded with their SN, otherwise SDUs are forwarded without a SN.

8. When the UE receives the CONNECTION RECONFIGURATION message with the necessary parameters (i.e. new C-RNTI, dedicated preamble, target cell ID etc.) it is commanded by the source eNodeB to perform the handover immediately to the target cell. The UE then performs the non-contention based random access proce-dure. The dedicated preamble which the UE has received is used during the random access procedure.

9. The random access response conveys timing alignment information and initial uplink grant for handover.

10. When the UE has successfully accessed the target cell, it sends the CONNECTION RECONFIGURATION COMPLETE message (containing its new C-RNTI) to the target eNodeB to indicate that the handover procedure is completed for the UE. Once the target eNodeB has verified the C-RNTI it can begin sending downlink data forwarded from the source eNodeB to the UE, and the UE can begin sending uplink data to the target eNodeB.

11. Using the “Source Measurement Configuration” information element given to the target eNodeB by the source eNodeB in the HANDOVER REQUEST message, the target eNodeB decides if a new “Measurement Configuration” needs to be sent to the UE. If a new “Measurement Configuration” is to be sent to the UE, it is sent in a separate CONNECTION RECONFIGURATION message.

12. The target eNodeB sends a PATH SWITCH REQUEST message to the MME to inform it that the UE has been handed over to another eNodeB. Included in this message is information required by the EPC nodes to enable downlink data and C-plane messages to be sent to the target eNodeB (i.e. the target eNodeB's signalling reference, transport layer addresses and TEID(s) for each of the UE's bearers).

13. The MME sends a USER PLANE UPDATE REQUEST message to the S-GW, which includes the target eNodeB's TEID(s) received before to enable the user data path to be switched from the source to the target eNodeB.

14. The S-GW switches the downlink data path to the target eNodeB. Before the S-GW can release any U-plane/TNL resources towards the source eNodeB, it sends one or more “end marker” packet(s) to the source eNodeB as an indication that the downlink data path has been switched. It should be noted that the “end marker” packets do not contain user data, and are forwarded transparently by the source eNodeB to the target eNodeB to help it decide when the last forwarded packet was received.

15. The S-GW sends a USER PLANE UPDATE RESPONSE message to the MME to confirm that it has switched the downlink data path.

16. The MME confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACK message.

24 DN0943971

Handover


17. By sending a UE CONTEXT RELEASE message, the target eNodeB informs the source eNodeB of the success of the handover and triggers the release of resources. It should be noted that the target eNodeB does not release its data for-warding tunnels from the source eNodeB until it has received an “end marker” packet indicating that all forwarded SDUs have been received.

18. Upon reception of the UE CONTEXT RELEASE message, the source eNodeB may forward any remaining PDCP SDUs before it releases the radio and C-plane related resources associated to the UE context.

Buffering and forwarding data via source eNode during handoverDuring the handover procedure, the source eNodeB buffers downlink and uplink PDCP SDUs which arrive from the S-GW or from the UE. The PDCP SDUs shall be forwarded as follows:

• PDCP SDUs with a (already assigned) PDCP SN below the value which was reported by the X2AP: SN STATUS TRANSFER message are accompanied by their PDCP SN (these SDUs have already been sent to the RLC layer and may have already been sent to the UE partially). These SDUs are forwarded first and in order of their PDCP SN.

• PDCP SDUs with a (intended) PDCP SN equal or beyond the value which was reported by the internal X2AP: SN STATUS TRANSFER message are not accom-panied by a PDCP SN (these SDUs have not been processed by the PDCP layer, so they do not have a SN). These SDUs are forwarded in order of their arrival on the source cell S1 GTP-U interface or from the UE.

• Due to DL RLC retransmission there might exist gaps in downlink PDCP SDUs. For example, if the PDCP SDUs 1 and 3 have not been successfully delivered to the UE, then the PDCP SDUs 1, 2, 3, ... are forwarded to the target eNodeB.

In case of uplink data forwarding, the RLC layer sends to the PDCP layer also the com-pletely received uplink RLC SDUs (PDCP PDUs) which are not delivered to the PDCP layer, because some RLC PDUs, sent earlier, are not yet received and a reordering timer in the RLC layer for that missing PDU is still running. This means that there exists PDCP PDUs in the RLC buffer but they have not been sent to the PDCP layer, because of the RLC reordering function. Therefore the RLC layer provides to the PDCP layer the last correctly received RLC SDU (PDCP PDU) and the list of missing RLC SDUs (PDCP PDUs). All PDCP PDUs which were indicated by the RLC layer are forwarded to the target eNodeB via uplink forwarding tunnel.

The source eNodeB keeps the copies from original user and data of signalling radio bearer SRB2 (and also incoming S1 GTP-U data) in its own data buffers until the handover is accomplished and resources are released or the handover fails.

DN0943971 25

Handover


Figure 3 Message flow for an inter-eNodeB handover

Time control and exception handlingSeveral timers are used to supervise the duration of the steps of the handover proce-dure:

• After sending a HANDOVER REQUEST message via the X2 interface to the target eNodeB, the source eNodeB sets the guard timer “TX2 RELOC Prep” to supervise the time period before receiving the HANDOVER REQUEST ACKNOWLEDGE answer from the target eNodeB. If this timer expires before the answer arrives, the handover procedure is stopped (beginning with the X2AP: HANDOVER CANCEL message to the target eNodeB).In case of handover cancelling, the source eNodeB starts the “Handover Cancel Latency Timer” when sending the X2AP: HANDOVER CANCEL message.

26 DN0943971

Handover


• The source eNodeB starts the internal “TX2 RELOC Overall” timer after having received the HANDOVER REQUEST ACKNOWLEDGE message from the target eNodeB. This timer supervises the time period until receiption of the the X2AP: RELEASE RESOURCE message from the target eNodeB after a successful han-dover. “TX2 RELOC Overall” is the sum of T304, T311, T301 and a configurable security offset. If the timer “TX2 RELOC Overall” expires, the handover procedure is cancelled.

• The target eNodeB starts the “TX2 RELOC Exec” timer after sending the HANDOVER REQUEST ACKNOWLEDGE message to the source eNodeB. This timer is used to supervise the duration time until reception of the RRC: RRC CON-NECTION RECONFIGURATION COMPLETE message from the UE.

• The timer “TDATA Fwd S1” is started in the source eNodeB when the X2AP: RELEASE RESOURCE message is received from target eNodeB. It is used to define a time period for forwarding all user data and all GTP-U “end marker” packets.When the timer “TDATA Fwd S1” expires, all U-plane user context resources are released including temporary GTP-U data forwarding tunnels between the source eNodeB and the target eNodeB. Also, all C-plane user context resources are released including the eNodeB’s internal connection for X2 message transfer.

• The timer “TX2 RELOC Comp” is started in the target eNodeB when the S1AP: PATH SWITCH REQUEST message is sent to the MME and it is typically stopped when the S1AP: PATH SWITCH REQUEST ACKNOWLEDGE message is received in return. When the timer expires, the eNodeB initiated context release procedure is started.

• The timer “TDATA Fwd X2” is started in the target eNodeB when the S1AP: PATH SWITCH REQUEST ACKNOWLEDGE message is received. If the timer expires, the eNodeB closes its user data tunnels at X2.

4.2.1.2 Intra-eNodeB handoverHandovers between cells of an eNodeB can be seen as a variant of the inter-eNodeB handover without CN node relocation where the handover is performed completely within the eNodeB, and does not involve signalling to EPC nodes at any point during the procedure. The following procedure is performed in case of an inter-eNodeB handover.

1. The eNodeB makes the decision to handover the UE to another cell which belongs to the same eNodeB based on the MEASUREMENT REPORT of the UE and RRM information.

2. Admission Control is performed in the target cell and if the resources can be granted the radio bearers are configured. Additional resources are also configured to allow the UE to access the new cell, which includes allocating the UE a new C-RNTI and a dedicated preamble. At this point, any downlink user data for the UE is buffered until the handover has been completed.

3. The eNodeB sends a CONNECTION RECONFIGURATION message towards the UE with the necessary parameters (i.e. new C-RNTI and dedicated preamble) to allow the UE to connect to the new cell.

4. The UE immediately detaches from the source cell and synchronizes with the target cell using the non-contention based random access procedure.

5. The random access response conveys timing alignment information and initial uplink grant for handover.

DN0943971 27

Handover


6. When the UE has successfully accessed the target cell, it sends the CONNECTION RECONFIGURATION COMPLETE message to the eNodeB to indicate that the handover procedure is completed for the UE. The eNodeB can then begin sending downlink user data towards the UE, and the UE can begin sending uplink user data to the eNodeB.

7. The eNodeB releases the UE's resources in the source cell.

Intra-eNodeB handovers include all cases where the eNodeB-internal system modules (e.g. FSM, flexi system module) or processing units change or do not change. Buffering of data within the eNodeB and forwarding to the target system unit is provided similar to inter-eNodeB handovers.

4.2.2 Target cell list handlingHaving decided that a handover is to be executed, the eNodeB selects the most appro-priate target cell from the target cell list. Dependent on the output from the RRM handover algorithm, the eNodeB derives the handover mode from the selected target cell.

In special cases, the eNodeB processes the target cell list received by the UE, e.g. excluding inhibited cells and performs a re-sorting of the list if necessary (the sorting of TCL might be obsolete as it is done yet by the UE).

28 DN0943971

Handover

Id:0900d805808e4174Confidential

4.3 LTE761: Advanced target cell selection and handover retry for intra-frequency handover

4.3.1 Advanced Target Cell HandlingThe eNodeB prepares the target cell list received from the UE by excluding cells which are not suitable and performing a re-sorting of the list if necessary. If a handover attempt with the best suited of the remaining target cells fails, the next best entry of the prepared target cell list is selected and the handover is retried with this new target cell.

Advanced target cell selection and handover retry increase the handover success rate.

The list of conditions depends on whether the feature LTE54 is supported. Cells are removed from the target cell list for the following reasons:

• The cell is unknown to the source eNB, for example it was not possible to allocate the ECGI

• Neither the UEs Serving PLMN-ID nor one of the Equivalent PLMNs listed in the Handover Restriction List is supported in the target cell

• The target cell is an inter eNB target cell and is blacklisted by Operatorer. ). In the scope of this check the target cell is only considered as blacklisted when child parameter "Blacklisted Topologies" has value "all".

• The target cell is an intra eNodeB target cell and is blacklisted by Operator. In the scope of this check the intra eNodeB target cell is only considered as blacklisted as soon as it is contained in the structure "blacklistHoL" without evaluating child param-eter "Blacklisted Topologies".

• The combination of PLMN-Idendity and TAC of the target cell is contained in the Handover Restriction List provided by MME (or during a previous incoming HO)

• The Target Cell is an intra eNodeB target and the target cell is barred. For example, the 'cellBarred' parameter in SIB1 is set to 'barred'

If the S1 based handover is not activated, a LTE cell is from the TCL list if at least one of the conditions listed below are met:

• The cell is unknown to Source eNodeB, for example it was not possible to allocate the ECGI

• X2 connection to the Target eNodeB is not available / operable • Neither the UEs Serving PLMN-ID nor one of the Equivalent PLMNs listed in the

Handover Restriction List is supported in the target cell. • The check of the S1 Connectivity of the Target eNodeB according to has failed • The target cell is blacklisted by Operator • The combination of PLMN-Idendity and TAC of the target cell is contained in the

Handover Restriction List provided by MME • The Target Cell is an intra eNodeB target and the target cell is barred. E.g. the 'cell-

Barred' parameter in SIB1 is set to 'barred'

Re-sorting is done in case intra-eNodeB handovers have been configured to be priori-tized over inter-eNodeB handovers and has the result that the target cells of the serving eNodeB are on the top of the target cell list (in other cases the sorting of the target cell list might be obsolete as it is already done by the UE).

DN0943971 29

Handover


4.4 LTE423: RRC Connection Release with RedirectThe eNodeB supports RRC Connection Release with redirection to an operator-specifi-able RAT & frequency if the UE risks losing coverage and no handover is possible.

Due to RSRP measurements (event A2), the eNodeB then triggers a RRC connection release with redirect.

The thresholds for this event are operator configurable. The target frequency is also operator configurable. It can belong to eUTRAN, WCDMA, GSM, eHRPD, CDMA/1xRTT.

The UE capabilities are considered for the redirect. The redirect functionality can be enabled/disabled via O&M. Up to six redirection target layers MORED are supported for each profile MOPR.

30 DN0943971

Handover


4.5 LTE54: Intra-LTE Handover via S1

4.5.1 Functional Overview/DetailsThe following S1 based intra-LTE handover scenarios are supported by the Flexi Multi-radio BTS:

• inter-eNB, intra-MME and intra-S-GW • inter-eNB, inter-MME and intra-S-GW • inter-eNB, inter-MME and inter-S-GW

S1 based handover is an alternative handover mechanism to the X2 based handover which is used if X2 interface is not available or cannot be used because Core Network Nodes need to be relocated. Source eNodeB will decide whether a handover is executed via the X2-Interface or via S1-interface. Core Network is not capable of influ-encing this decision. However, the operator can force an S1-based handover by black-listing neighbour-cells for X2-based handover via O&M Configuration. X2-handover mechanisms are reused as much as possible. Especially on the Air interface no differ-ence exists at all. S1 based handover is applicable to the intra frequency handover as well as to the inter frequency handover. For the UE it is even transparent for S1-handover additions whether the handover is inter frequency or intra frequency.

4.5.2 Handover trigger In general, the Handover trigger for all LTE Handover variants (S1,X2 and intra eNB) is the same. The handover is triggered either via LTE intra-frequency measurements or via LTE inter-frequency measurements (if the feature is enabled). The source eNB initiates the S1-handover after receiving a measurement report form the UE by sending a S1AP:HANDOVER REQUIRED message to the MME.

The MME prepares the resources at the target eNB via the S1AP:HANDOVER REQUEST message.

The S1AP: HANDOVER CANCEL message shall be sent by the source eNB to the MME once the source eNB decides to cancel an ongoing S1 handover. Receipt of the S1AP: HANDOVER CANCEL ACKNOWLEDGE indicates that the MME is ready to take part in a new handover procedure. Upon receiving the S1AP: HANDOVER CANCEL ACKNOWLEDGE message at the source eNB, the source eNB shall retry the handover towards another handover target cell.

Handover retries are based on the same logic for S1, X2 and intra eNB handovers.

4.5.3 Handover Mode selection for S1 based handoverWith the new introduced feature LTE54 a HO via S1 is possible now. Dependent on the output from RRM Handover Algorithm, the eNB selects the handover target cell and derive the handover mode from the selected target cell. Possible HO Modes are:

• Intra enB HO • Intra LTE inter eNB HO via X2 • Intra LTE inter eNB HO via S1

Cells can be excluded as candidates for HO target cells for several reasons:

- cells are blacklisted for handover

DN0943971 31

Handover


- cells according to the HO restriction list provided by MME

- barred intra eNB cells

eNodeB checks whether the Target cell is a known LTE Target Cell but no X2 Handover is possible. If this is fulfilled, Inter eNB Handover via S1 is executed. This check is not neccessary for intra eNB Target cells. For intra eNB Target cells always intra eNB handover is applied.X2 handover is considered as impossible if:

• no connection to the Target eNB exists (for example no configuration information for the target cell has been provided by former X2 Setup procedure)

• X2 connection is temporally unavailable • the target cell is listed in the handover blacklist with attribute "Blacklisted Topolo-

gies" set to "onlyX2" • the UE serving PLMN-ID is not supported in the target cell.

4.5.4 Handover over S1 interfaceSuccessful Inter eNB Handovers over the S1 interface are composed of the same four phases as X2- based handover

• Handover decision • Handover preparation • Handover execution • Handover completion

4.5.4.1 Handover decisionHandover decision is made based on evaluation of measurements report within source eNB.

4.5.4.2 Handover preparationSend S1AP: HANDOVER REQUIRED message to source MME. When the decision has been made to handover the UE to another eNodeB via S1 or to another RAT, the source eNB shall send an S1AP: HANDOVER REQUIRED message to source MME over the S1interface.

During the handover preparation phase MME sends an S1AP: HANDOVER REQUEST message to the target eNodeB containing the needed parameters. Upon receiving this message, the target eNB shall initiate the Handover Preparation phase. With the S1AP: HANDOVER COMMAND the preparation phase is finished. The handover execution is initiated by the MME with the S1AP:HANDOVER COMMAND message to the source eNB.

4.5.4.3 Handover execution After reception of the handover command source eNB sends a RRC:RRCConnection-Reconfiguration message to the UE.

This RRC message forces the UE to the new cell. The target eNB sends a S1AP:HAN-DOVER NOTIFY message in case of a successful handover to the MME.

32 DN0943971

Handover


4.5.4.4 Handover completionAfter the RRC CONNECTION RECONFIGURATION COMPLETE message is received in the target eNB, the source eNB releases the radio resource associated with the UE in the source cell after receving S1AP: UE CONTEXT RELEASE COMMAND.

Also the RRM of source cell is informed that the UE has been handed over to another cell.

The switch from source cell to target cell is seamless for S1 data. In particular, it may neither loose nor destroy any GTP-U PDU.

4.5.5 Data forwarding

4.5.5.1 Support of indirect data forwardingeNodeB supports indirect data forwarding of DL data from Source eNodeB to Target eNodeB via the S1-interface

4.5.5.2 Resource Allocation at Target eNBResource allocation at the target eNB involves the following steps:

• configuring S1 bearer(s) at the target eNB and the S-GW • configuring SRBs and DRB(s) for the UE in the target cell • configuring measurements for the UE in the target cell • storing AMBR information • storing UE Capability Information • configuring AS security for the UE • configuring a fast method to allow the UE to synchronise with the target cell • compare source and target cell configurations to generate a delta configuration • generating an RRC: RRC CONNECTION RECONFIGURATION message to be

sent to the UE via the source eNB • configuring S1 bearer(s) at the target eNB for DL data forwarding from the source

eNB

4.5.6 Performance CountersPerformance counters are supported per cell in order to track the performance of the S1 intra-LTE handover via S1, for example: • Number of Inter eNB S1-based Handover preparations • Number of failed Inter eNB S1-based Handover preparations per cause • Number of Inter eNB S1-based Handover attempts • Number of successful Inter eNB S1-based Handover completions • Number of Inter eNB S1-based Handover failures per cause

Performance counters related to neighbor cell related measurement are:

• Number of failed Inter eNB Handover preparations per cause per neighbour cell relationship

• Number of Inter eNB Handover attempts per neighbour cell relationship

DN0943971 33

Handover


• Number of successful Inter eNB Handover completions per neighbour cell relation-ship

• Number of Inter eNB Handover failures per neighbour cell relationship

34 DN0943971

Handover


4.6 LTE55: Inter-frequency Handover

4.6.1 Functional Overview/DetailsThe following inter-frequency handover scenarios are supported by the Flexi Multiradio BTS:

• intra-eNB, inter-frequency band • intra-eNB, intra-frequency band with different center frequency • inter-eNB, inter-frequency band via X2 • inter-eNB, intra-frequency band with different center frequency via X2 • inter-eNB, inter-frequency band via S1 (if enabled) • inter-eNB, intra-frequency band with different center frequency via S1 (if enabled)

4.6.2 Inter-frequency Handover VariantsAs long as RSRP of the serving cell is above s-measure, a UE in RRC_Connected only monitors RSRP of the serving cell. Below s-measure, the UE performs measurements as configured by the eNB. To ensures mobility to neighbour cells in the same frequency band, eNB configures intra-frequency RSRP measurement reporting for neighbour cells in the same frequency band. When the level of the serving cell becomes worse and there is no neighbour cell in the same frequency bandwidth that is received by the UE with proper quality, then inter-frequency measurements are configured in the UE in order to find a proper inter-frequency neighbour cell. eNB supports inter-frequency handover in which the handover decision is based on RSRP and/or RSRQ (DL mea-surement).

Triggers can be "Coverage HO" (A5) and "Better Cell HO" (A3) whereas A3 events are implemented for both, RSRP and RSRQ. Inter-frequency measurements may need Measurement Gaps, depending on the UE capability.

The parameter measQuantInterFreq defines which quantity to use for Event A3 measurements towards this frequency set in QuantityConfigEUTRA. The quantities used to evaluate the triggering condition for the Event A3 is configurable (RSRP, RSRQ or both). The values RSRP and RSRQ correspond to Reference Signal Received Power (RSRP) and Reference Signal Received Quality (RSRQ). This parameter refers to event A3. If set to "both", two A3 events will be configured when measuring this carrier, one per specific measurement quantity.

4.6.2.1 RSRP for A3 event (Better Cell HO)RSRP Definition: portion of energy in a received signal created by the inclusion of a ref-erence pattern. Reference symbol received power can be used to estimate the ability of a receiver to obtain and decode information signals that a carrier signal transports.

The UE measures its neighbor cell environment in a stepwise manner, such that unnec-essary measurements are avoided. The measurement is based on the Reference Symbol Received Power (RSRP) and only if the RSRP value of serving cell falls below certain thresholds additional measurements are activated. In best case if RSRP of serving cell is higher than RSRP-Threshold-1, only the serving cell is measured, and if RSRP of serving cell falls below RSRP-Threshold-1 all intra frequency cells are measured as well. This measurement is easy to provide. s-measure is the 3GPP notation for RSRP-Threshold-1. Nevertheless, the measurement of other frequencies is

DN0943971 35

Handover


difficult to provide and should be avoided if not necessary. Therefore, inter-frequency measurements are activated when RSRP of the serving cell falls below a still lower threshold than RSRP-Threshold-2.

Transitions: When the UE enters RRC_CONNECTED state, the eNB sends a Measure-ment Configuration which includes the value RSRP-Threshold-1, such that the UE autonomously starts/stops intra-frequency measurements when rsrp(serv) falls below/ becomes higher than RSRP-Threshold-1. The activation /deactivation of inter-frequency measurement is triggered by a new Measurement Configuration message that the eNodeB sends to the UE. For this reason in the first step when measurement configu-ration is set up, the MeasConfig contains a trigger that the UE advises when the RSRP(serv) falls below RSRP-Threshold-2. This results in a MeasResult from UE. As a consequence, the eNB sends a new MeasConfig which contains the details about the other frequencies that have to be measured in addition. Additionally, a trigger is added, by which the UE advises when rsrp(serv) becomes better than RSRP-Threshold-2. In this case, when the RSRP becomes better (than RSRP-Threshold-2), then there is no need to continue measuring the inter-frequency and with a new MeasConfig the inter-frequency measurements are deactivated.

For each Measurement Object a separate ReportConfig ‘Better Cell HO RSRP IF’ is used, where the parameter values defined at the same instance as for the related Inter Frequency Measurement Object. The number of ReportConfig's ‘Better Cell HO RSRP IF’ is equal to the number of Inter Frequency Measurement objects. If there exists no Inter Frequency Measurement Object than no ReportConfig '‘Better Cell HO RSRP IF’' is to configure.

4.6.2.2 RSRQ for A3 event (Better Cell HO)RSRQ Definition: signal strength metric that is calculated as a ratio of the reference symbol received power multiplied by the number of physical resource blocks to the received signal strength indicator. While the reference symbol received power is an indi-cator of the wanted signal strength, the reference signal received quality takes also the interference into account due to the inclusion of the received signal strength indicator.

For each Measurement Object a separate ReportConfig ‘Better Cell HO RSRQ IF’ is used, where the parameter values defined at the same instance as for the related Inter Frequency Measurement Object. The number of ReportConfig's ‘Better Cell HO RSRQ IF’ is equal to the number of Inter Frequency Measurement objects.

RSRP of serving cell Measurement activities in UE

rsrp(s) > RSRP-Threshold-1 no measurement except serving cell

RSRP-Threshold-1

> rsrp(s)

> RSRP-Threshold-2

intra-frequency measurement

rsrp(s) < RSRP-Threshold-2 intra-frequency measurement and inter frequency measurements

Table 3 Th1 and Th2 InterFreq are thresholds set by O&M

36 DN0943971

Handover


4.6.2.3 RSRP for A5 event (Coverage HO)For each Measurement Object a separate ReportConfig 'Coverage HO IF' is used, where the parameter values are defined at the same instance as for the related mea-surement object. The number of ReportConfig's is equal to the number of Inter RAT Measurement objects. If there exists no Inter Frequency Measurement Object or UE does not support Event A5, no ReportConfig 'Coverage HO IF' needs to be configured. Supporting of Event A5 is indicated if Bit14 of parameter featureGroupIndicators of 3GPP IE UE-EUTRA-Capabilty is set to 1.

4.6.2.4 Th2a for deactivation of A3 and A5 eventsTh2a is the threshold for RSRP of the serving cell for stopping of Inter-RAT (InterFreq) Measurements. When RSRP of the serving cell becomes better than Th2a, Inter-RAT measurements are deactivated for all A3 and A5 events (RSRP and RSRQ). In order to prevent ping-pong effects it is necessary that the value of Th2a shall be somewhat higher than Th2_InterFreq

4.6.3 Handover triggerThe following measurement events are used for the measurement based inter-fre-quency handover:

• A1 - deactivate inter-frequency measurements • A2 - activate inter-frequency measurements • A3 - inter-frequency measurements “Better Cell HO” for RSRP and RSRQ • A5 - inter-frequency measurements “Coverage HO” for RSRP

The events A1 and A2 are used to control the start and stop of inter-frequency measure-ments on the target cells.

The target cells for the inter-frequency handover can be configured by the operator.

The events A3 or A5 are used to report suitable inter-frequency neighbors. The UE radio access capabilities are considered for the measurement configuration.

The handover thresholds, hysteresis margins and timer constrains for the inter-fre-quency handover are O&M parameters that can be configured by the operator.

The evaluation of measurements reports, the handover preparation, execution, comple-tion and data forwarding is identical to the intra-frequency handover via X2 respectively S1.

4.6.4 Performance countersThe following counters are supported per cell in order to track the performance of the inter-frequency handover, for example:

• Number of Inter-Frequency Handover attempts • Number of Inter-Frequency Handover attempts - measurement gap assisted


rsrp(s) > RSRP-Threshold-2a Inter-RAT (InterFreq) measurement stopped

Table 4 Th2a InterFreq threshold set by O&M

DN0943971 37

Handover


• Number of Inter-Frequency Handover completions • Number of Inter-Frequency Handover completions - measurement gap assisted • Number of Inter-Frequency Handover failures • Number of Inter-Frequency Handover failures - measurement gap assisted

The inter-frequency handover functionality can be enabled / disabled per cell via O&M.

38 DN0943971

Handover


4.7 LTE56: Inter RAT Handover to WCDMA

4.7.1 Functional description

Functional overviewThe LTE to WCDMA handover functionality of the Flexi Multiradio BTS allows a service continuity of data services with minimal interruption time when changing from a LTE cell to a WCDMA cell. The functionality is only applicable to multimode devices supporting both LTE and WCDMA at the according frequency band and the according feature support.

Handover triggerThe handover is a network controlled handover with support of the UE. The following measurement events are used:

• A1 - deactivate IRAT measurements • A2 - activate IRAT measurements • B2 - IRAT measurements

The operator configurable measurement events A2 and A1 are used to start and stop IRAT measurements. The UE capabilities are considered for the IRAT measurements, for example to support measurement gap and support of frequency of target cells. The target cells for the IRAT measurements are operator configurable. Blacklisting of target cells is supported.

The event B2 is used for the IRAT measurements. The measurement configuration as source cell thresholds (RSRP), target cell thresholds (RSCP, EcN0), hysteresis, time to trigger and speed dependent scaling are operator configurable.

Handover preparationThe Flexi Multiradio BTS initiates a handover after receiving a measurement report from the UE by sending a S1AP:HANDOVER REQUIRED message to the MME. The Flexi Multimode BTS takes the first target cell indicated by the UE measurements for the han-dover. The MME responds to this with a S1AP:HANDOVER COMMAND message indi-cating that the resources at the target have been reserved.

Handover executionThe Flexi Multiradio BTS sends after this a RRC:MobilityfromEUTRAcommand message to the UE, which forces to the UE to a WCDMA cell. The Flexi Multimode BTS performs handover retries to other target cells provided by the UE measurements in case of an unsuccessful handover preparation.

Performance counterThe Flexi Multiradio BTS supports Performance counters per cell in order to track the performance.

4.7.1.1 Handover from LTE to WCDMAHandover from LTE to WCDMA passes the service responsibility for a UE from an LTE cell to a WCDMA cell. It is classified as an inter-RAT handover and is also an inter-fre-quency handover. Inter-RAT handovers are Network Controlled, UE assisted backward handovers. Hard handover is performed - during the handover procedure the UE is only connected to one system at one time. The general objective is to be able to offer the UE

DN0943971 39

Handover


the same level service in WCDMA as in LTE.Typical scenarios where this might be needed include:

• Poor LTE coverage

Handover to WCDMA is a Handover via S1. The inter-RAT handover towards WCDMA can be logically split into four phases. These are:

• Handover Initiation • Handover Preparation • Handover Execution • Handover Completion

An inter eNB handover via S1 is always initiated by the source eNB based on the radio network configuration and the measurement results reported by the UE.

If an ongoing S1 handover is stopped for any reason where the UE is to remain in the source cell (for example because Inter RAT UE Capabilities are missing) the following occurs at the source eNB.

• If guard timer TS1RELOCprep is running, stop it • If guard timer TS1RELOCoverall if it is running, stop it • If guard timer TS1RELOCcancel if it is running, stop it

If an ongoing S1 handover is stopped for any reason where the UE is not allowed to continue in the source cell, the source eNB:

• stops the handover • releases S1 signaling connection to the MME • releases Radio Resources in the source cell • releases S1 data connections to the S-GW

4.7.1.2 MeasurementActivating WCDMA MeasurementsA new Measurement Configuration is constructed to activate Inter-RAT Measurements for WCDMA. UE-EUTRA-Capability contains the information if Handover to WCDMA is supported and which bandlists are supported and if measurement gaps are necessary for measurements. WCDMA measurements are only activated if the UE supports HO to WCDMA and there are predefined O&M Inter-RAT frequencies that the UE supports as well and the corresponding enabling flag is set.

Measurement Coordination Measurement Coordination requests for Measurement Control Command message can occur in four different use cases. These are :

1. LTE HO Idle -> ActiveWhen a UE starts a connection, it receives the instruction to measure intra-fre-quency only, that means it receives the Measurement Configuration with the follow-ing MeasId in the AddModifyList. Additionally if the UE supports event A5, that is indicated in the UE-EUTRA-Capabilities, then also measId Id_Trigger_Coverage_HO is included in the AddModifyList.

2. Incoming HandoverThe Handover Request from source eNodeB contains the VarMeasurementConfig-uration, that must be modified properly. That means that only intra-frequency mea-

40 DN0943971

Handover


surement with events A2, A3 and A5 (if supported by UE) and the corresponding thresholds are used. Therefore use in the MeasObjectRemovList all other frequen-cies from the source Configuration.Modify or Add the ReportConfig with event A2, A3 and A5 such that the correct Time-to-Trigger, hysteresis and thresholds are used.

g UE exchanges at inter-frequency HO the objects of serving and target frequency autonomously. Any other MeasObjects remain untouched. MeasGaps are deacti-vated by the UE, inter-frequency and inter-RAT measurements that require MeasGaps are continued when activated in new MeasConfig.

3. Outgoing HandoversProvide the current valid VarMeasurementConfiguration, where the MeasObjects and ReportConfigs are used in the corresponding AddModifyList

4. Changed Radio Conditions ( activate/deactivate Inter-Frequency/Inter-RAT measurements)The changed radio conditions are noticed by the Measurement result received, the constructed MeasConfig that is sent to the UE is described for activation and for deactivation. The AddModifyList and RemoveList is built according to activation thresholds.

Measurement Configuration for Handover to WCDMAFor Handover to WCDMA the following IEs within MeasConfig IE are supported:

• measObjectUTRA • reportConfigInterRAT • measGapConfig

Measured Results Including Handover to WCDMA RequirementsFor Handover to WCDMA requirement the following information elements are sup-ported:

• mobilityMeasResult • measResultListUTRA

4.7.1.3 Connection Mobility Control: Handover (CMC-HO)Support of Inter-RAT HO to WCDMAeNB supports inter RAT HO to WCDMA based on UE measurements. The feature works in parallel to other forms of active mobility.

The handover algorithm handles the UE in RRC_CONNECTED only. The UE in RRC_IDLE decides autonomously about cell reselection. The HO-Algorithm triggers the UE by Measurement Configuration to provide measurements. The measurement con-figuration consists of a list of measurement objects and report configuration. Depending on the RSRP of serving cell (rsrp(s)) different objects are measured:

DN0943971 41

Handover


Note: the last three rows in the foregoing table are interpreted in parallel. That means for rsrp(s) < min(Th2_InterFreq, Th2_WCDMA, Th2_GSM) all measurements inter-fre-quency, WCDMA and GSM are activated.

If RSRP of serving cell is higher than Th1, only the serving cell is measured. If it gets worse and is between Th1 and Th2_XXX, then additionally all other cells on the same frequency band (intra-frequency) are measured.

In addition to the intra-frequency measurements HO-Alg activates inter-frequency mea-surements and/or inter-RAT measurements, if the RSRP of serving cell measure is worse than set threshold Th2_InterFreq, Th2_WCDMA and/or Th2_GSM. Th1, Th2_InterFreq, Th2_WCDMA and Th2_GSM are thresholds set by O&M.

LTE inter frequency measurements are started only if:

• rsrp(s) < Th2_InterFreq • the feature "Inter Frequency HO" is activated and • the UE capabilities indicate that the UE is able to measure at least one of the LTE

frequencies configured by the Operator to be measured and to perform intra LTE Inter Frequency Handover

WCDMA measurements are started only if:

• rsrp(s) < Th2_WCDMA • the feature "HO to WCDMA" is activated and • if the UE capabilities indicate that UE is able to measure at least one of the WCDMA

layers configured by the Operator to be measured and to perform the Handover to WCDMA.

GSM measurements are started only if:

• rsrp(s) < Th2_GSM • the feature "eNACC to GSM" is activated and


rsrp(s) > th1 no measurement except serving cell,

"th1 > rsrp(s) > max( Th2_InterFreq, Th2_WCDMA, Th2_GSM)"

intra-frequency measurement only

rsrp(s) < Th2_InterFreq intra-frequency measurement + LTE inter frequency measure-ments+ potentially inter RAT mea-surements

rsrp(s) < Th2_WCDMA intra-frequency measurement + WCDMA measurement+ poten-tially inter RAT/frequency mea-surements

rsrp(s) < Th2_GSM intra-frequency measurement + GSM measurement+ potentially inter RAT/frequency measure-ments

Table 5 Measurements

42 DN0943971

Handover


• if the UE capabilities indicate that UE is able to measure at least one of the GERAN layers configured by the Operator to be measured and to perform GSM measure-ment reporting event B2 in E_UTRA connected mode

When RSRP of serving cell becomes better than Th2a, then Inter-RAT measurements are de-activated. In order to prevent ping-pong effects, it is necessary that the value of Th2a is somewhat higher than Th2_InterFreq, Th2_WCDMA resp. Th2_GSM.Th1, Th2_InterFreq, Th2_WCDMA and Th2_GSM are thresholds set by O&M.

4.7.1.4 Capacity, performance and overload controlU-plane break during handover from LTE to WCDMA and Inter-RAT handover to WCDMAThe U-plane interruption in DL during handover from LTE to WCDMA and inter-RAT handover from LTE to WCDMA is on average not greater than 150ms. In UL it is on average not greater than 300 ms.

4.7.1.5 Configuration Management

Inter RAT handover to WCDMADue to handover to WCDMA, additional objects are needed to provide information about Inter-RAT objects. Neighbouring information for WCDMA are statically configured by O&M. Therefore, such information is available in newly introduced Object classes LNADJW and LNHOW:

LNADJW for neighbouring WCDMA cell information

LNADJW object represents a WCDMA cell which can be taken into consideration as a neighbouring WCDMA cell by LNCEL when its lnAdjWId parameter is listed on WCMDA Neighbouring Cell Information adjWInf parameter.

LNHOW for measurements and handover to WCDMA related information.

LNHOW is an object that represents a set of HO to WCDMA related parameters, and it is created on LNCEL level per one WCDMA frequency given by utraCarrierFreq param-eter. When an instance of LNADJW is added to adjWInf list in LNCEL, then for such LNCEL instance a corresponding LNHOW instance must exist (or be newly created) with the same value of the utraCarrierFreq parameter.

Cardinality of new objects is as follows:

• LNADJW is 0...32 • LNHOW is 0...16

Cardinality of adjWInf relation:

• up to 32 elements

Both objects are handled in common way as other Object classes in plan file. Therefore creation, modification, and deletion of Object classses LNADJW and LNHOW can be done with plan file operations.

DN0943971 43

Handover


Activation of the featureInter RAT handover to WCDMA is an optional feature in LTE. The operator needs to activate this feature by setting a corresponding flag represented by the parameter actHOtoWcdma to value enabled. This flag is set only once per eNB.

44 DN0943971

Handover


4.8 LTE442: Network Assisted Cell Change to GSM


Functional overviewThe LTE to GSM Network Assisted Cell Change (NACC) functionality of the Flexi Multi-radio BTS allows for a service continuity of data services when changing from an LTE cell to a GSM cell. NACC is only applicable to NACC capable multimode devices sup-porting both LTE and GSM at the according frequency band. The UE capabilites are provided to the eNB by the feature group indicator.

NACC triggerThe NACC is a network controlled functionality with support of the UE. The following measurement events are used:

• A1 - deactivate IRAT measurements • A2 - activate IRAT measurements • B2 - IRAT measurements

The measurement events A2 and A1 are used to start and stop IRAT measurements and can be configured by the operator. The eNB will trigger IRAT measurements only for NACC capable UEs. The UE capabilities are considered as well for the setup of the IRAT measurement configuration, for example support of measurement gap and support of frequency bands. The target frequencies for the GSM measurements can be configured by the operator. The event B2 is used for the IRAT measurements. The mea-surement configuration as source cell thresholds (RSRP), target cell thresholds (RSSI), hysteresis, time to trigger and speed dependent scaling can be configured by the oper-ator. The Flexi Multiradio BTS initiates the NACC after receiving a measurement report form the UE by sending an RRC:MOBILITYFROMEUTRACOMMAND message with cell change order indication to the UE, which forces the UE to a GSM cell.

Performance counterPerformance counters are provided per cell in order to track the NACC performance

Activation / DeacivationThe NACC functionality can be enabled / disabled (Activation of eNACC to GSM) per cell via O&M.

4.8.1.1 eNACC to GSMeNACC procedure is used to send a UE which is currently in RRC Connected state in the Source eNodeB to GSM. Unlike in the handover procedure no resources are prepared in the target system. The UE will enter GSM in RRC Idle mode and start the RRC Connection Setup procedure in GSM. Speeding up this process the UE is provided with the RRC parameters to access the GSM target cell. Optionally GSM System infor-mation is provided as well.

Cell changed order (CCO) CCO to GSM is also supported. The main difference to eNACC is that in this case no GSM System information is provided

DN0943971 45

Handover


eNACC PhasesThe procedure of Network Assisted Cell Change to GSM can be modeled in 3 phases:

• eNACC Decision • eNACC Execution • eNACC Completion

eNACC Decision PhaseeNACC to GSM is triggered when the UE receives poor coverage in LTE cell and no other LTE cell is received with sufficient quality. The feature can be used in parallel to handover to WCDMA or inter-frequency intra LTE handover (intra LTE intra-frequency handover is always active in parallel). All of them are based on the intention to measure the corresponding inter-frequency / inter RAT neighbour cells when the received level of the serving cell falls below a threshold. Different threshold for different RATs provides priorization of RATs. In the first step when the received level of serving cell falls below a threshold, then it advises by MeasResult the eNB. This Measurement Result triggers on eNB side the order to measure in addition GSM neighbor cells. This might include MeasGap if the UE-EUTRA-Capability indicates the necessity. The UE is instructed to report the GSM neighbor cell list when the RSRP of serving cell is below a lower thresh-old and the RSSI of one or more GSM neighbor cell is higher than another (lower) threshold. When the UE finds GSM neighbor cells fulfilling the criteria rsrp(serv) < Threshold_1 and rssi(neighbor) > Threshold_2 it sends a MeasurementResult with GSM target cell list. On the other side, if the rsrp(serv) exceeds the threshold, a new MeasConfig is sent to UE to deactivate GSM measurements. Interaction to Handover to WCDMA: mobility to both technologies can be handled in parallel. The Measurement Result with TCL that comes first determines to which RAT the UE is sent. Using different rsrp threshold when GSM or WCDMA measurements are activated and TimeToTrigger values gives the possibility to introduce priority of RATs.

eNACC Execution PhaseOnce the decision to perform eNACC to GSM has been made in the eNACC Decision phase, it is verified that the identified GSM Target cell is a valid target for an eNACC to GSM. The required RNL parameters are retrieved from the O&M database, and UE is commanded to perform Cell Change towards GSM by RRC message MOBILITY-FROMEUTRACOMMAND. When receiving MOBILITYFROMEUTRACOMMAND, UE disconnects from LTE, enters RRC Idle mode, and starts RRC connection establish-ment procedure in the specified GSM cell. Even though the eNACC to GSM uses the same RRC Message (MOBILITYFROMEUTRACOMMAND) as handover to WCDMA, the handling is completely different. eNACC to GSM is specified as an independent pro-cedure in parallel to HO to WCDMA. The existing functionality for HO to WCDMA remains unchanged.

eNACC Completion PhaseAfter the UE has successfully established RRC Connection Setup within GSM, the UE will perform an Routing Area Update Procedure (RAU) with the Core Network. Core Network will notice that the UE is still registered within the Source eNodeB and the serving MME will initiate a UE Context Release Procedure on S1 towards the Source eNB.

46 DN0943971

Handover


GSM Measurement Configuration and Reporting RequirementsMeasurement configuration and measurement reports for GSM measurements are sup-ported by eNB.

For the feature "eNACC to GSM" the following IEs within MeasurConfig IE are sup-ported:

• measObjectGSM • reportConfigInterRat • measGapConfig

For eNACC to GSM the following information elements are supported:

• mobilityMeasResult • measResultListGSM

4.8.1.2 Connection Mobility Control: Handover (CMC-HO)Support of eNACC to GSMThe eNB supports eNACC to GSM, based on measurements. The feature works in parallel to other forms of active mobility as Handover to WCDMA, intra-LTE handover and Redirect.

HO Algorithm handles the UE in RRC_CONNECTED only.

UE in RRC_IDLE decides autonomously about cell reselection. The HO-Algo triggers the UE by Measurement Configuration to provide measurements. The measurement configuration consists of a list of measurement objects and report configuration. Depending on the RSRP of serving cell (rsrp(s)) different objects are measured.

Note: the last three rows in this table are interpreted in parallel. That means for rsrp(s) < min(Th2_InterFreq, Th2_WCDMA, Th2_GSM) all measurements inter-frequency, WCDMA and GSM are activated. As indicated in the table above, if RSRP of serving cell is higher than Th1 only the serving cell is measured. If it gets worse and is between Th1 and Th2_XXX, then additionally all other cells on the same frequency band (intra-fre-quency) are measured.

RSRP of serving cell measurement activities in UE

rsrp(s) > th1 no measurement except serving cell,

th1 > rsrp(s) > max( Th2_InterFreq, Th2_WCDMA, Th2_GSM)

intra-frequency measurement only

rsrp(s) < Th2_InterFreq intra-frequency measurement + LTE inter frequency measurements+ potentially inter RAT measurements

rsrp(s) < Th2_WCDMA intra-frequency measurement + WCDMA measurement+ potentially inter RAT/fre-quency measurements

rsrp(s) < Th2_GSM intra-frequency measurement + GSM mea-surement+ potentially inter RAT/frequency measurements

Table 6 Measurements

DN0943971 47

Handover


In addition to the intra-frequency measurements, HO-Algorithmus activates inter-fre-quency measurements and/or inter-RAT measurements, if the RSRP of serving cell measure is worse than set threshold Th2_InterFreq, Th2_WCDMA and/or Th2_GSM. Th1, Th2_InterFreq, Th2_WCDMA and Th2_GSM are thresholds set by O&M.LTE inter frequency measurements are started only if:

• rsrp(s) < Th2_InterFreq • the feature "Inter Frequency HO" is activated and • the UE capabilities indicate that the UE is able to measure at least one of the LTE

frequencies configured by the Operator to be measured and to perform intra LTE Inter Frequency Handover

WCDMA measurements are started only if:

• rsrp(s) < Th2_WCDMA • the feature "HO to WCDMA" is activated and • the UE capabilities indicate that UE is able to measure at least one of the WCDMA

layers configured by the Operator to be measured and to perform the Handover to WCDMA.

GSM measurements are started only if:

• RSRP(s) < Th2_GSM • the feature "eNACC to GSM" is activated and • the UE capabilities indicate that the UE is able to measure at least one of the

GERAN layers configured by the Operator to be measured and to perform GSM measurement reporting event B2 in E_UTRA connected mode.

When RSRP of serving cell becomes better than Th2a, then Inter-RAT measurements are de-activated. In order to prevent ping-pong effects, it is necessary that the value of Th2a is somewhat higher than Th2_InterFreq, Th2_WCDMA resp. Th2_GSM.Th1, Th2_InterFreq, Th2_WCDMA and Th2_GSM are thresholds set by O&M.

4.8.1.3 Capacity, performance and overload control

eNACC to GSM PerformanceThe eNACC procedure can be split in three phases, see eNACC Phases: decision phase, execution phase, and completion phase.

User data are still transmitted via UL and DL during the decision phase. Similarly, user data are transmitted again in both directions in the completion phase. Thus the most important performance indicator is the service gap in the execution phase, for eample the time while the UE is in idle state and there is no user data transfer. The user plane service gap is not longer than 140 ms on average.

NACC success rateAs eNACC KPIs two rates are defined, the success rate and the cancellation rate. The success rate is defined as the ratio of successful completions to attempts. Although it is defined by LTE counters, its performance is dominated by the GSM network coverage and quality. Therefore the achievable values are expected to be approximately equal to the call setup success rate of the target GSM system. The success rate target is 98% or better under load.

48 DN0943971

Handover


4.8.1.4 Configuration Management for eNACCAs a result of eNACC to GSM, additional objects are needed to provide information about Inter-RAT objects for GSM network. Therefore two new Object Classes are intro-duced in object model: LNADJG for neighbouring GSM cell information and LNHOG for measurements and handover to GERAN related information.

LNADJG object represents GSM cell which can be taken into consideration as neigh-bouring GSM cell by LNCEL when its lnAdjGId parameter is listed on GSM Neighbouring Cell Information adjGInf parameter.

LNHOG is an object class which represents a set of eNACC to GSM related parameters, and it is created on LNCEL level. Up to 32 GSM BCCH frequencies (arfcn parameter) can be configured per LNHOG instance. When an instance of LNADJG is added to adjGInf list in LNCEL then for such LNCEL instance corresponding LNHOG instance must exist (or be newly created) with same value of arfcn parameter.

Cardinality of new objects is following:

• LNADJG is 0...32 • LNHOG is 0...6

Cardinality of adjGInf relation

• up to 32 elements

RNL support for eNACC to GSMWith respect to eNACC to GSM feature, RNL supports new GSM related object classes in object model and neighbouring list of GSM target cells in LNCEL.

Neighbouring GSM cellsNeighbouring information for GSM are statically configured by O&M. Therefore, such information is available in newly introduced object classes LNADJG and LNHOG.

Neighbouring GSM cell informationFor eNACC to GSM, operator needs to provide information about neighbouring GSM cells and HO related parameters.

For providing GSM cells information LNADJG object representing known GSM cell was introduced in scope of LNBTS object. LNADJG is created by operator in plan file.

Neighbouring GSM Cells information is provided in LNCEL object in parameter called NeighbouringGSMInformation (abbreviated name adjGInf), which is a list of identifica-tion parameters pointing to LNADJG instance (lnAdjGId naming attribute can be reused for this purpose). Additionally, NeighbouringGSMInformation contain information if neighbouring is blacklisted by the operator or not, and other funcinality related to GSM cell.

Handling of LNADJG and LNHOG objectsBoth objects are handled in common way as other object classes in plan file. Therefore creation, modification, and deletion of Object Classes LNADJG and LNHOG can be done with plan file operations.

DN0943971 49

Handover


4.8.1.5 User scenarios

Activation of eNACC to GSMeNACC to GSM is an optional feature in LTE, which needs to be activated by operator. Using the management tool, the operater can set the parameter acteNACCtoGSM to value true. This flag is set only once per eNB.

For Deactivation the parameter acteNACCtoGSM must set to value false

UE leaves limited LTE Coverage AreaPre-conditionA UE is connected to an LTE cell (in RRC Connected Mode) and has at least one Data Radio Bearer (DRB) established. The UE is configured to perform measurements on its own LTE frequency layer and is moving out of the LTE coverage area.

DescriptionWhen the level of the serving cell becomes worse than a threshold (without the possi-bility to perform handover towards another LTE cell), the UE is configured to measure GSM neighbour cells and report the measurements of the GSM neighbour cells to eNB. When the LTE quality falls below a further threshold, and at least one GSM neighbour cell with sufficient quality has been reported by the UE, the eNB commands the UE to release the RRC connection with LTE and start RRC Connection establishment towards a GSM Cell.

The eNB selects the GSM Cell based on measurements provided by the UE (taking additional configuration data into account, for eample blacklisting) and supports the UE with GSM system information to accelerate RRC Connection Setup within GSM.

50 DN0943971

Handover


4.9 LTE490: Subscriber profile based mobility


Functional overviewThe MME provides the subscriber profile ID to the eNB via the S1AP:InitialContextSetup message. When the eNB receives the SPID from another eNB, this is done via Handover message. The SPID is forwarded during intra LTE handovers either via X2AP:Handover Request or via the S1AP:HandoverCommand message. The SPID itself is mapped to a mobility profile. When SPID value was not received or SPID cannot be mapped to Mobility Profile instance, eNB uses so called "default profile", which can be manually configured by operator in the same way as Mobility Profile or which can use automatically all configurations provided by operator during configuration of separate mobility features. Target frequency layers in mobility profiles can be seen as a filter on the configured neighbour cells represented by LNADJL, LNADJW and LNADJG objects. Redirection configuration, which is part of the profile (MODRED, MORED) is an alterna-tive, typically restricted configuration compared to REDRT configuration, NACC, RRC connection release with redirect or CSFB. Up to eight mobility profiles can be defined per eNB by O&M settings. The eNB will use only the infos which are contained in the SPID related mobility profile (for examplecells belonging to the target frequency layers which are used) for the different mobility scenarios. It is possible to create, modify, and delete Mobility Profiles via plan file. Modifications are possible for O&M data but not for SPIDs which are assigned to UEs. All operations are possible online without affecting service. This means that ongoing calls are not affected and for this measurements will not be re-configured.

Performance counterThe Flexi Multiradio BTS supports Performance counters per cell in order to track per-formance.

4.9.1.1 Handling of LTE490 reconfigurationIf LTE490 feature has already been enabled at eNB and there is a change in LTE490 configuration data, for example add/modify/delete of User Profile(s) and/or add/mod-ify/delete of content in Mapping between User Profiles (MOPR) and SPIDs, the eNB has to update the locally stored LTE490 configuration data. The new configuration becomes applicable for new calls only. The existing calls are not affected, for example UEs which are already configured to measure certain frequencies are not re-configured due to the changes in LTE490 configuration data.

If LTE490 feature has already been enabled at eNB and there is no change in LTE490 configuration data but there is a change in the feature flag status, for example the flag is changed to “disabled”, the eNB stops using the LTE490 configuration data and uses the configuration provided by operator during configuration of separate mobility features for UE measurement configuration. This applies only to new calls, existing calls are not affected.

g • Target frequencies can be configured in advance, even if the frequency is not used by any created neighbor cell.

DN0943971 51

Handover


4.9.1.2 Licensing of SPID Selective Neighbor Cell listsSPID Selective Neighbor Cell lists is an optional feature which is, if enabled, activated for the whole eNB. In order to keep it activated, a license for the eNB is required. The license type is on/off. The license is handled by the management system.

If activated, for mobility features eNB use only those target frequencies that are speci-fied for a given mobility feature in Mobility Profile configured and assigned for SPID related to the handled UE.

If deactivated, the eNB will use all target cells defined for each mobility feature, without any impact from Mobility Profiles.

4.9.1.3 Impact on measurement configurationThe eNB restricts measurement objects from configuration in the UE if the correspond-ing carrier frequency is not assigned in the SPID mobility profile used by the UE. Inter-actions between RRM-CMC and C-Plane for supporting the SPID selective neighbour cell lists are:

• C-Plane indicates to HO Algorithm when feature LTE490 is switched on and informs HO Algorithm about the related SPID value, in order the Measurement Configuration can take the related Mobility Profile Instance (MOPR) into account. Only RATs and frequencies configured by operator in Mobility Profile are set to be measured.

• When SPID mapping is not possible (for example no related instance in MOPR can be found), then Default Mobility Profile (MODPR) shall be taken into account while configuring Measurements. This is done in the following way : • If the autoAdapt flag in MODPR is set to true, then the Measurements are con-

figured as if the feature LTE490 is disabled • If the autoAdapt flag in MODPR is set to false, then RATs and frequencies con-

figured in Default Mobility Profile (MODPR) are to be measured.

4.9.1.4 Mobility Profiles

Management of Mobility ProfilesA Mobility Profile represents a set of O&M configured target frequency layers for enabled LTE Inter-Frequency and Inter-RAT mobility functions like Handover, Network Assisted Cell Change. It can be seen as a filter on the configured neighbor cell informa-tion of an eNB. Furthermore, there is a Mobility Profile specific configuration of target frequencies for UE Redirection, Circuit Switched Fallback and Emergency Calls.

eNB supports management of Mobility Profiles including a default profile via plan file and persistently stores profile information. Any creation, modification, or deletion of Mobility Profile Information is possible online without affecting service.

Mobility profiles are only supported if the feature is enabled.

Mobility Profile InformationMobility Profile Information is stored in instances of the Object classes MOPR and MORED. Up to 8 Mobility Profiles are supported. For each profile MOPR up to six redi-rection target layers MORED are supported.

Each Mobility Profile provides the following information:

52 DN0943971

Handover


• optional Frequency Layer List for LTE Inter Frequency Mobility. The EARFCN value(s) are used to filter for LNHOIF objects which are selected for UE measure-ment configuration.

• optional Frequency Layer List for Packet Switched Handover to WCDMA target cells. The UARFCN values are used to filter for LNHOW objects, which are used for UE measurement configuration.

• optional list of Reference Frequencies for Network Assisted Cell Change to GERAN. Each list element consists of band indicator and ARFCN value. The frequencies and band indicators in the list are used as references to cell specific LNHOG objects. An LNHOG object is selected for UE measurement configuration if a LNHOG frequency matches the reference frequency.

Each of the subordinate MORED instances provides the following information:

• Redirection Priority for Circuit Switched Fallback with Redirection • Redirection Priority for Emergency Call • Redirection Priority for UE Context Release • RAT for Redirection • eUTRA frequency • or UTRA frequency • or GERAN ARFCN values list and GERAN band indicator • or CDMA frequency and CDMA band

If a mobility profile is selected for a UE, the profile specific MORED configuration data applies instead of the cell specific REDRT configuration data. If one or more list fre-quency lists are not provided or if no MORED object is created, the related mobility type is not supported for the profile.

Default Mobility Profile InformationThe default profile applies if no Mobility Profile is assigned to a Subscriber Profile ID (SPID) or if no SPID value is provided for a UE. The default profile is represented by a single MODPR instance. The instance has to be mandatorily created by using the plan file if the feature is activated. The default profile provides the following information:

• Flag for Automatic Adaptation to Frequency Layers of all Neighbor Cells • optional Frequency Layer List for LTE Inter Frequency Mobility • optional Frequency Layer List for Packet Switched Handover to WCDMA target cells • optional list of Reference Frequencies for Network Assisted Cell Change to GERAN.

Each list element consists of band indicator and ARFCN value. The frequencies and band indicators in the list are used as references to cell specific LNHOG objects. An LNHOG object is selected for a UE measurement configuration if a LNHOG fre-quency matches the reference frequency.

If 'Automatic Adaptation' is enabled, the overall neighbor cell configuration which provides the parameters of the MOCs (LNADJ-L/W/G, LNHO-/W/G/IF, REDRT) auto-matically is valid. No further changes are necessary. This also includes objects which are created after enabling. In this case no frequency layer lists need to be configured. If 'Automatic Adaptation' is disabled it is the responsibility of the operator to ensure that any neighbor cell frequency covered by at least one mobility profile including the default profile. Otherwise such neighbor cell would be never considered as a valid handover target cell. Each of the MODRED instances subordinate to MODPR provides the follow-ing information:

DN0943971 53

Handover


• Redirection Priority for Circuit Switched Fallback with Redirection • Redirection Priority for Emergency Call • Redirection Priority for UE Context Release • RAT for Redirection • eUTRA frequency • or UTRA frequency • or GERAN ARFCN values list and GERAN band indicator • or CDMA frequency and CDMA band

If the default profile is selected for a UE, the default profile specific MODRED configu-ration data applies instead of the cell specific REDRT configuration data. Online modifi-cation of the default profile via plan file is supported. If one or more frequency lists are not provided or if no MODRED object is created, the related mobility type is not sup-ported for the default profile. Deletion of the default profile is only accepted if the feature has been deactivated before by setting actSelMobPrf to 'false'. MODRED instance(s) are automatically deleted with the MODPR object

4.9.1.5 User scenarios

Acivation / Deactivation Subscriber profile based mobilityOperator has to enable the feature by setting a corresponding O&M flag on BTS level and creating managed object class (MOC) instance for Default Profile with autoAdapt flag set to ‘true’ or with manual configuration of Default Profile. The operator should provide Mobility Profiles Object class instances and related mapping between config-ured profile and SPID values. With such prepared configuration plan file downloaded to the eNB, LTE490 will be activated in eNB software.

The feature is activated by setting the LNBTS parameter actSelMobPrf to ‘true’.The feature is deactivated by setting the LNBTS parameter actSelMobPrf to ‘false’.

Configuration of Mobility Profiles informationThe pre-condition for this configuration is that the feature LTE490 is enabled and corre-sponding mobility features, planned to be used inside Mobility Profile are enabled (LTE55 Inter-frequency handover; LTE56 Inter RAT handover to WCDMA; LTE442 Network Assisted Cell Change to GSM; LTE562 CSFB to UTRAN or GSM via redirect; LTE423 RRC connection release with redirect; LTE22 Emergency Call handling).

The operator provides a new instance of Mobility Profile MOC configured per LNBTS level. For each used mobility type the operator can specify target frequencies to be used by the eNB. The operator provides mapping of SPID to the configured Mobility Profile instance. Mapping is done on LNCEL level. Multiple SPID values can be specified for one specific Mobility Profile. The configuration must allow to uniquely choose Mobility Profile for a given SPID value. The plan file with above configuration is sent to eNB.

Creation and assignment of new Mobility ProfileThis example shows a user scenario for the creation of a new Mobility Profile.

UEs of operator B are allowed to connect to LTE cells of operator A. Both operators have their own WCDMA networks and operator A wants that UEs of operator B are handed

54 DN0943971

Handover


over or are redirected to the WCDMA network of operator B as far as possible by radio conditions.

• Operator A uses WCDMA frequency layer fa • Operator B uses WCDMA frequency layer fb • MME indicates UEs of operator B with SPID value “s” • UEs of operator A are assigned to the default profile

The procedure describes the configuration activities from the viewpoint of operator A.

Pre-conditions:

• eNB has activated RNW database and is in service • NetAct is in service and DCN connection to eNB is established via OMS • The feature ‘SPID selective Neighbor Cell Lists’ is activated by setting the LNBTS

parameter actSelMobPrf to ‘true’. • WCDMA mobility functionality is activated by setting the according activation flag(s)

to ‘true’.1. actHOtoWcdma for Inter-RAT HO to WCDMA2. actCSFBRedir for Circuit Switched Fallback to WCDMA (optional)3. actEmerCallRedir for Emergency Call handling via redirection (optional)4. actRedirect for UE context release with redirection (optional)

g The mobility profiles and SPID assignments could be already created in advance, for example without feature activation, but the information would be ignored by eNB.

Description:

• Operator edits delta plan file with at least the following content:1. A new MOPR object is created for the WCDMA frequency layer of operator B

(freqLayListPsHoWcdma = fb).2. Handover parameters are configured for the WCDMA frequency layer of

operator B by creating of an LNHOW object for frequency layer fb.3. WCDMA neighbor cell objects (LNADJW) objects are created for ‘visible’

neighbor cells of operator B (uTargetFreq=fb).4. Optional, mobility profile specific WCDMA redirection objects (MORED) may be

created for UE context release with redirection, Circuit Switched Fallback and/or emergency calls (redirRAT=utraFDD, redirFreqUtra=fb).

5. For all affected LNCEL objects the SPID s is assigned to the newly created mobility profile (MOPR) via the parameter moPrMappingList.

g If the default profile is created with autoAdapt set to 'true' it has to be modified, for example the parameter autoAdapt has to be set to 'false' and the default fre-quency layers have to be explicitly configured for frequencies of operator A, i.e. MODPR has to be modified to freqLayListPsHoWcdma = fa and parameters for other RATs and optional redirection targets set to operator A values

• Operator downloads and activates the plan • eNB persistently creates new objects or stores persistently the cell specific SPID

assignment values • eNB informs NetAct and BTS Site Manager about the changed configuration via

notifications. • eNB applies the mobility profile to new UEs

DN0943971 55

Handover


Post-condition:

• The new mobility profile settings are persistently stored in eNB • eNB applies the mobility profile for all new NEs in the cell if MME indicates SPID

value “s”. • The default profile is applied for all UEs with no SPID value or a SPID value different

from value “s”.

56 DN0943971

Handover


4.10 LTE562: CSFB to UTRAN or GSM via redirect

4.10.1 Functional overviewThe CS voice service continuity is implemented through service triggered redirection from LTE to UTRAN or GERAN for multimode device. Both mobile originated and mobile terminated scenarios are supported.

As prerequisite EPC (Evolved Packet Core) must support CS inter-working for mobility management and paging.

Both in the MO (Mobile-Originated) and in the MT (Mobile-Terminated) case, the MME indicates the CS fallback scenario to the eNodeB. Packet based services may be started again after CSFB depending on the capability of the target radio network.

Whenever a CS service for UE is requested, the eNodeB moves the UE to Idle first with an information on which carrier it should try to access the target UTRAN/GERAN cell. The operator can configure priorities for the target frequency bands per cell. The eNodeB selects the highest priority layer supported by the multimode device. Figure 4 Message sequence and time delay during CSFB redirection shows the CSFB redirec-tion process.

Figure 4 Message sequence and time delay during CSFB redirection

DN0943971 57

Handover


The redirection is performed by an: RRC:RRC Connection Release message with a RedirectedCarrierInfo IE. The RedirectedCarrierInfo force the UE to search for any cell first at the highest priority UTRA carrier or within BCCH (Broadcast Control Channel) carrier set for GSM.

The UTRA and GSM cells should broadcast the LTE layer as prioritized RAT (Radio Access Technology). Thus the multimode UE will camp back into the LTE carrier after a CS call is terminated.

4.10.2 Selection of target RATeNodeB evaluates the O&M parameters specifying the redirection target according to the value of csFallBPrio parameter. The special value ‘not used’ means that such a redi-rection target defined in O&M database will not be taken for Release message. eNodeB builds a list of redirection target RAT definitions, starting with lowest values of csFallB-Prio parameter, which has unique values, so this list can be build in an unambiguous way. Target RATs that are not available in UE Capabilities information are excluded from that list.

58 DN0943971

Handover


4.11 LTE735: RRC Connection Re-establishment


Functional overviewThe Flexi Multiradio BTS supports the RRC Connection Re-establishment procedure. The procedure is initiated by the UE in RRC connected in case of:

• Radio link failure detection due to for example • expiry of the timer T310 (timer started after detection of physical layer problem) • random access problem indication from MAC • indication from RLC that the maximum number of retransmissions has been

reached • Handover failure (T304 expiry) • Integrity check failure indication from lower layers • RRC connection reconfiguration failure

The UE sends for the initiation of the procedure an integrity checked RRC:RRConnec-tionReestablishmentRequest message to the eNB. The eNB checks whether it still has a valid UE:

• in a source cell which becomes the serving cell or

• in a prepared target cell which becomes the serving cell

and sends in case of a positive response a RRC:RRCConnectionReestablishment message to the UE for resuming the SRB1 and security. The UE confirms the message with a RRC:RRCConnectionReestablishmentComplete message.The eNB subse-quently re-establishes the SRB2 and DRBs. The following counters are provided in order to track the performance:

• Number of RRC Connection Re-establishment attempts • Number of successful RRC Connection Re-establishment procedures • RRC Connection Re-establishment attempts per cause (Handover Failure) • RRC Connection Re-establishment success per cause (Handover Failure) • RRC Connection Re-establishment attempts per cause (Other Failure) • RRC Connection Re-establishment success per cause (Other Failure)

4.11.1.1 RRC Connection Re-EstablishmentRRC Connection Re-Establishment Procedure (RRC Re-Establishment) can be initi-ated by UE for different reasons during an ongoing intra LTE Handover, inter RAT Handover or eNACC to GSM.In case RRC Re-Establishment was caused by Radio link failure or T304 expiry eNodeB will accept the RRC Re-Establishment if the UE enters the Source cell or an prepared Target Cell.In case the UE tries to enter an unprepared cell or the RRC Re-Establishment was caused by an configuration error the eNodeB will not accept RRC Re-Establishment.

Acceptance of RRC Connection Re-Establishment in the Source cell of an HandoverIn general it can happen during any mobility procedure (for example intra LTE handover, inter RAT handover or eNACC) that UE fails to execute the procedure, performs cell

DN0943971 59

Handover


selection and initiates RRC Re-Establishment procedure towards the Source cell in which the mobility procedure had been started.The general handling in eNodeB follows the list below:

• decide whether the UE shall be allowed to perform RRC Re-Establishment towards the Source cell. This requires that UE can be clearly identified (including intergrity check), UE Context is still available in Source Cell and UE tries to enter the source cell with the original configuration from the source cell.

• the RRC Re-Establishment procedure is executed on the air interface followed by an RRC Connection Reconfiguration procedure to re-establish SRB2 and DRB. The measurment gaps for Inter Rat and Inter-frequency HO have to be re-configured, if they were configured before the re-establishment.

• finally the ongoing mobility procedure is cancelled. This cancellation depends on the type of mobility procedure which is ongoing. It might either be eNodeB internal or might require cancellation procedures towards Target eNodeB via X2 or towards MME

Rejection of RRC Connection Re-Establishment in the Source cell of an HandoverThe RRC Connection Re-Establishment Request by the UE will not always be accept-able by the Source cell. Resons may be:

• reason for RRC Re-Establishment was "reconfiguration failure • UE has already applied configuration for target cell

The general handling in eNodeB follows the list below:

• eNodeB decides to reject the RRC Connection Re-Establishment request and sends the rejection message towards the UE

• eNodeB initates a UE Context Release procedure towards the MME to inform the MME that the UE was send to idle

• depending on the type of mobility procedure eNodeB needs to cancel the ongoing mobility procedure. Especially for X2-handover eNodeB has to inform its peer via X2 signalling the ongoing handover shall be cancelled. In case of S1 based handover procedures no explicit cancellation is needed as the MME does not need an explicit cancellation of the S1-HO in addition to the UE Context Release. For other mobility procedures eNodeB internal actions will be sufficient.

Acceptance of RRC Connection Re-Establishment in the Target cell of an HandoverIn general it can happen during any mobility procedure (for example intra LTE handover, inter RAT handover or eNACC) that UE fails to execute the procedure, performs cell selection and initiates RRC Re-Establishment procedure towards the Target cell which has already been prepared. In the following only the cases where the Target Cell is an LTE Cell are considered.The general handling in eNodeB follows the list below:

• Decide whether the UE shall be allowed to perform RRC Re-Establishment towards the Target cell. This requires that UE can be clearly identified (including intergrity check), UE Context is already prepared in Target Cell .

• the RRC Re-Establishment procedure is executed on the air interface followed by an RRC Connection Reconfiguration procedure to re-establish SRB2 and DRB. The measurment gaps for Inter Rat and Inter-frequency HO have to be re-configured, if they were configured before the re-establishmen.

60 DN0943971

Handover


• finally the ongoing mobility procedure is continued from the point in time at which Target cell would have received RRC Connection Reconfiguration Complete in the same way as if the UE had joined the Target cell be regular handover

Rejection of RRC Connection Re-Establishment in the Target cell of an HandoverThe RRC Connection Re-Establishment Request by the UE will not always be accept-able by the Target cell. Resons may be:

• reason for RRC Re-Establishment was "reconfiguration failure"

The general handling in eNodeB follows the list below:

• eNodeB decides to reject the RRC Connection Re-Establishment request and sends the rejection message towards the UE

• eNodeB initates a UE Context Release procedure towards the MME to inform the MME that the UE was send to idle.

DN0943971 61

Handover


4.12 LTE971: Intra-LTE mobility offsets


4.12.1.1 Functional overviewThis feature extends the already existing configurable handover events A3 (better cell) and A5 (coverage) with the frequency specific offsets and the Cell Individual Offsets (CIOs) for the serving carrier and all other neighbour carriers measurement objects.

For the own serving carrier (Intra) and all other carriers (Inter) the cellsToAddModList (resp. cellsToRemoveList) - further on called the CIO cell list - will be introduced. Each CIO cell list containes a set of up to 32 Physical Cell IDs (PCIs).The Cell Individual Offset (CIOs) of the serving cell with its PCI may also be contained in the cellsToAdd-ModList, where all other neighbour cell PCIs with its CIOs are contained too.

The operator is able to optimize the intra LTE mobility by applying following different offsets to different target cells :

• Cell Individual Offsets (CIOs) for the serving cell and neighbour cells on own serving carrier and on all other carriers

• Additionally carrier frequency specific offsets of own serving (Intra) and neighbour (Inter) carriers are introduced.

The Flexi Multiradio BTS supports offset settings for intra-frequency and inter-frequency handovers. The following offsets are supported:

• Ofn - frequency specific offset of neighbour cells • Ocn - Cell Individual Offsets (CIOs) of neigbour cells • Ofs - frequency specific offset of the serving cell • Ocs - serving Cell Individual Offset

The offsets are applied if the related measurements are configured.The offsets are sent to the UE as part of the measurement configuration. The UE takes the offsets for the measurement triggering into consideration

4.12.1.2 Connection Mobility Control: Handover (CMC-HO)

Support of Intra-Frequency cell individual offsets (CIO cell list) and Intra-Frequency specific offsets • The eNB supports the configuration of Intra-Frequency Cell Individual Offsets (CIO)

in the CIO cell list in the measurement configuration of the serving carriers measure-ment object for the A3 event (Neighbour becomes better than serving) and the A5 event (Coverage).

• The CIO cell list is used to explicitly indicate to the UEs which cells/PCIs to measure with an individual CIO to be applied for measurement events. The CIO cell list is compiled from a parameter in LNCEL for the serving cell and from parameters in LNREL for other neighbour cells

• The eNB supports the configuration of frequency specific offsets in the measure-ment configuration of the serving carriers measurement object (Intra) for the A3 event (Neighbour becomes better than serving).

62 DN0943971

Handover


Support of Inter-Frequency cell individual offsets (CIO cell lists) and Inter-Frequency specific offsets • The eNB supports the configuration of Inter-Frequency Cell Individual Offsets (CIO)

in the CIO cell lists in the measurement configuration of the neighbour carriers mea-surement objects for the A3 event (Neighbour becomes better than serving) and the A5 event (Coverage).

• The CIO cell list is used to explicitly indicate to the UEs which cells/PCIs to measure with an individual CIO to be applied for measurement events. The CIO cell lists of neighbour carriers is compiled from parameters in LNREL for other neighbour cells.

• The eNB supports the configuration of frequency specific offsets in the measure-ment configuration of the neighbour carriers measurement objects for the A3 event (Neighbour becomes better than serving) and the A5 event (Coverage).

DN0943971 63

Handover

Id:0900d8058095135fConfidential

4.13 LTE736: CS Fallback to UTRAN

4.13.1 Functional descriptionThis feature introduces a funcionality for CS Fallback to UTRAN via PS HO. It is assumed that the eNB already supports PS HO to WCDMA and that this feature is acti-vated. Target frequencies for CSFB and PS-HO can be defined independently. Even if a frequency is selected for both applications, whitelisting of target cells within this fre-quency is done separately. Additionally target frequency might be restricted per Sub-scriber Profile ID value with Mobility Profiles configuration. Mobile-originated and mobile-terminated call setup is supported, for both RRC_IDLE and RRC_CONNECTED states. Blind HO is not supported, so the eNB will trigger measurements before CS Fallback to UTRAN. The feature can be switched on/off in the eNB by operator.

4.13.1.1 CSFB to UTRANFrom eNB point of view CS Fallback trigger is received from MME. Depending on feature activation and UE capabilities, the eNB decides which type of CS Fallback will be performed. Also priority of CS Fallback indicator will be taken into account: when it is CS Fallback High Priority then the eNB will handle the call as Emergency Call, otherwise it will be handled as a normal call. With the LTE736: CS fallback to UTRAN feature, the eNB checks if B1 measurements are supported by the UE. If the UE supports B1 event, the eNB starts measurement and additionally supervision timer for B1 will be started, otherwise the eNB triggers CS Fallback with redirection to GERAN or UTRAN depend-ing on the configuration. When the UE provides B1 measurement results before super-vision timer expires, the eNB selects suitable target cell taking into account O&M configuration for CS Fallback to UTRAN with PS HO targets, Mobility Profiles (already taken into account during Measurement Configuration), CS domain in which UE is reg-istered and Handover Restriction List (this will not be done for Emergency Calls) and perform PS HO (as specified in LTE56: Inter RAT Handover to WCDMA for HO to WCDMA) to first cell from Target Cell List (with CSFB Information indication to UE and MME). In case after all applied restrictions Target Call List is empty or B1 supervision timer expired, the eNB triggers CS Fallback with redirection to GERAN or UTRAN. If the UE is not supporting PS HO or if the Operator has prohibitted PS HO, then the eNB performs CS Fallback with redirection based on Measurements Results.

If CS Fallback with PS HO was executed, but Handover Preparation procedure failed, the eNB tries again PS HO with next suitable cell from TCL.

64 DN0943971

Handover

Id:0900d8058096dc88Confidential

4.14 LTE872: SRVCC to WCDMA

4.14.1 Functional descriptionThe goal of this feature is to provide mechanism to HO UEs that have a QCI-1 bearer (VoIP) activated when changing from an LTE cell to a WCDMA cell. The voice bearer, which is the subject of HO, is served via the CS domain on WCDMA side. During HO two different scenarios are possible: SRVCC can be executed with or without PS-HO support depending on the capabilities of evolved packet core (EPC) and target UTRAN. All non-voice services are handed over to the PS domain.

The selection of WCDMA target layers for SRVCC is independent from the WCDMA target layers used for PS-HO to WCDMA.

g The operator has to specify separately the target frequencies for SRVCC and PS-HO. These two sets of frequencies may be disjunctive, partly overlapping or identical. The selection of one of these two sets depends on the presence of an E-RAB with QCI-1 bearer.

If PS-HO is executed together with SRVCC, SRVCC determines the selection of target layers. List of SRVCC to WCDMA Target Layers is calculated:

1. from the UE's Subscriber Profile ID (SPID) and the related managed object class (MOC) MOPR parameter Frequency layer list for SRVCC to WCDMA (freqLayListSrvccWcdma) if SPID is received and known in database, otherwise

2. if Auto adaptation to freq. layers of all neighbour cells (autoAdapt) flag is set to true, all configured WCDMA layers are selected, other-wise

3. from the MOC MODPR parameter Frequency layer list for SRVCC to WCDMA (freqLayListSrvccWcdma)

The functionality is applicable only for SRVCC-capable multimode devices supporting both LTE and WCDMA at the corresponding frequency band. The SRVCC capability of the UE (including FGI bits) and the mobility management entity (MME) are achieved within the context of the Initial Context Setup Procedure (for more detailed information, see 3GPP 36.413). During intra-LTE handover the SRVCC Capability Indicator is for-warded to the target evolved node B (eNB) either via the S1AP:HANDOVER REQUEST message by the MME or via the X2AP:HANDOVER REQUEST message by the source eNB.

If frequencies do not differ in Mobility Profile setting, the handover procedure itself is identical to the LTE to WCDMA HO, that is the same neighbor cells list, measurements and thresholds are used.

The eNB indicates the MME with the S1AP:HANDOVER REQUIRED message that SRVCC should be initiated.

Parameter Activate SRVCC to WCDMA (actSrvccToWcdma) is introduced to activate and deactivate this feature. It is deactivated by default because LTE872: SRVCC to WCDMA is optional. To set actSrvccToWcdma to true Activate support of conversational voice bearer (actConvVoice) and Activate handover from LTE to WCDMA (actHOtoWcdma) also need to be set to true.

If the feature LTE872: SRVCC to WCDMA is activated, LTE1073: Measurement based redirect to UTRAN must not be configured to move all UEs to WCDMA by redirect

DN0943971 65

Handover

Id:0900d8058096dc88Confidential

SRVCC HOWhen the UE runs out of the LTE coverage, eNB activates UE measurements on the WCDMA frequencies configured for SRVCC. To know which WCDMA cells support CS-HO a new, optional parameter SRVCC HO indication (SRVCC HO indication) is introduced. This parameter is stored in the eNB.

g The HO capability is in principle a property of the UTRAN, however, no information is provided by standardized interfaces.

It is also possible to allow/forbid SRVCC and/or PS-HO individually per LTE - WCDMA neighbor relation. To define these Single radio voice call continuity allowed (srvccAllowed) and PS handover allowed (PS handover allowed) parameters are used.

When the UE reports that conditions for HO to WCDMA are met then eNB initiates HO procedure towards WCDMA indicating to the EPC to apply SRVCC with or without PS-HO support. EPC prepares UTRAN for an incoming dual mode HO (in case PS-HO is also needed), whereas the VoIP bearer is converted to an CS-Voice bearer on Iu-CS. The remaining bearers are mapped on Iu-PS. After this preparation the UE is com-manded to handover to UTRAN.

If the UE runs out of the LTE coverage and has at least one emergency VoIP bearer (QCI=1) established then Handover Restriction List provided by MME is ignored.

66 DN0943971

Handover

Id:0900d805808eae51Confidential

4.15 LTE873: SRVCC to GSM

4.15.1 Functional descriptionThe goal of this feature is to provide mechanism to HO UEs that have a QCI-1 bearer (VoIP) activated when changing from an LTE cell to a GERAN cell. The voice bearer, that is the subject to HO, is served via the CS domain on GERAN side. SRVCC is always executed without packet switched (PS)-HO support (it means that established non-voice bearers are not handed over to GSM). Depending on the dual transfer mode (DTM) capabilities of the UE and the target GERAN, two different scenarios are possible: resources can be either re-established via routing area update (RAU) (the operator con-figurable switch) or suspended as long as the UE remains in GERAN.

The selection of GSM target layers for SRVCC is independent from the GSM target layers used for network-assisted cell change (eNACC).

The functionality is only applicable for SRVCC-capable multimode devices supporting both LTE and GSM at the corresponding frequency band. The SRVCC capability of the UE (including FGI bits) and the mobility management entity (MME) are achieved within the context of the Initial Context Setup Procedure (for more detailed information, see 3GPP 36.413). During intra LTE handover the SRVCC Capability Indicator is forwarded to the target evolved node B (eNB) either via the S1AP:HANDOVER REQUEST message by the MME or via the X2AP:HANDOVER REQUEST message by the source eNB.

DN0943971 67

Handover


4.16 LTE984: GSM redirect with system information

4.16.1 Functional descriptionThis feature introduces additional funcionality for CS Fallback with Redirection to GERAN (LTE562: CS Fallback with redirection), Emergency calls handling (LTE22: Emergency Calls handling) and UE Context Release with Redirection (LTE423: RRC Connection Release with Redirect). With this feature the eNB provides System Informa-tion (SI) for GERAN cells inside redirection message. This reduces time needed to access target GERAN cell, in which CS service will be performed, as the UE will not need to read SIBs from air interface to access target cell. The cell selection algorithm in the UE is not influenced by providing the GERAN system information, for example the UE does not prefer GERAN cells for which system information has been provided. The feature can be switched on/off in the eNB by the operator.

4.16.1.1 CSFB to GSM with system informationCS Fallback with redirection to GSM with system information is enhancing current behavior with respect to redirection message (used both for CS Fallback and UE Context Release) when target system is GERAN. New funcionality will allow including in redirection message (RRC: Connection Release) system information of GERAN cells configured for chosen GERAN frequency band, for which support in redirection message is allowed by operator configuration.

By setting the required O&M parameter, the operator can decide for which mobility type GERAN SIBs will be added to redirection message (can be set to CSFB only, UE Context Release only or both). CS Fallback is triggered by MME as specified in LTE562: CS Fallback with redirection, Emergency Calls and handling as specified in LTE22: Emergency Calls handling and RRC Connection Release with redirection as specified in LTE423: RRC Connection Release with Redirect in MOC REDRT. LTE984: GSM redirect with system information uses the same targets as specified in LTE562: CS Fallback with redirection, LTE22: Emergency Calls handling and/or LTE423: RRC Con-nection Release with Redirect in MOC REDRT or in corresponding Mobility/Default profile instance.

Additionally, the operator can specify per GERAN relationship (new MOC LNRELG) if the system information is provided for this GERAN cell in redirection message or not. The system information for GERAN cell can optionally be configured and stored in MOC LNADJG. Furthermore, it is possible that the GERAN system information is not provided by O&M configuration.

The system information in redirection message is provided only if the UE indicated in UE Capabilities, that it is capable of enhanced redirection to GERAN. The eNB also checks RegisteredLAI IE if provided by MME and exclude cells (SIs) not matching RegisteredLAI. It will be excluded on GERAN neighboring cell basis, so if GERAN neigboring cell is not matching RegisteredLAI then SI for this cell will not be added to redirection message. If no SIs are available, then redirection without SIs to chosen GERAN frequency band will be performed. The eNB will additionally allow up to 16 number of SIs included in redirection message. If the operator has specified more System Information to be included, then the eNB will use only 16 values and others will be ignored. The eNB also checks Handover Restriction List, if provided by MME. This check is not necessary in case of emergency calls (LTE22: Emergency Calls handling).

68 DN0943971

Handover


In case forbidden RATs are set to all or include GERAN, then redirection to GERAN will not be possible.

DN0943971 69

Handover


4.17 LTE1073: Measurement based redirect to UTRAN

4.17.1 Functional descriptionThe feature LTE1073: Measurement based redirect to UTRAN is specified as an enhancement to LTE56: Inter RAT Handover to WCDMA. After the trigger to handover to WCDMA is received it is decided whether a classical handover to WCDMA according to LTE56: Inter RAT Handover to WCDMA is applied or a UE Context Release according to LTE1073: Measurement based redirect to UTRAN. The feature LTE1073: Measurement based redirect to UTRAN is activated together with LTE56: Inter RAT Handover to WCDMA. There is no separate activation and/or licensing needed. The feature LTE1073: Measurement based redirect to UTRAN can be used in context with the feature LTE736: CS fallback to UTRAN.

As the feature LTE872: SRVCC to WCDMA and the feature LTE1073: Measurement based redirect to UTRAN may not be applied to the same UE in parallel, the operator must not prohibit PS-HO for all UEs if he has activated SRVCC to WCDMA.

As this feature is an enhancement of LTE56: Inter RAT Handover to WCDMA the main extensions are:

• WCDMA measurements are configured for all UEs which are capable of measuring WCDMA not only for UE which are capable of performing handover to WCDMA.

• When mobility to WCDMA is triggered by UE measurement the eNB decides whether to execute a handover or UE Context Release with redirect considering UE capabilities and Operator configuration.

• Procedure for UE Context Release with redirect is applied by selecting the redirec-tion target from previously received measurements.

Measurement-based redirect to UTRAN is composed of functions available from the features LTE56: Inter RAT Handover to WCDMA and LTE423: RRC Connection Release with Redirect. In the first step of the procedure measurements of WCDMA are performed exactly in the same way as specified for Handover to WCDMA. The complete configuration for WCDMA measurements (including all parameters and the Mobility Pro-files) is reused from LTE56: Inter RAT Handover to WCDMA. Measurements are per-formed commonly for both features. The only extension is the check for UE capabilities. Evaluation of measurement results and target cell selection are then again executed commonly for both features including the consideration of every target cell restriction defined for LTE56: Inter RAT Handover to WCDMA. The trigger to start Handover to WCDMA is now more generally interpreted as a trigger to send the UE to WCDMA. Now the eNB decides whether the UE is sent to WCDMA by handover according to the existing feature LTE56: Inter RAT Handover to WCDMA or by UE Context release. If either UE is not able to perform PS handover or the Operator has prohibited PS handover by O&M configuration, UE Context Release is performed. In the final step of the LTE1073: Measurement based redirect to UTRAN procedure UE Context Release with redirect is executed as already defined for LTE423: RRC Connection Release with Redirect. Differences are that:

• Redirect is triggered by UE measuring the event B2 of the WCDMA target frequency instead of A2 measuring the event on the serving LTE frequency.

• Redirection target is taken from the reported WCDMA frequency of the B2 report instead from a Operator configured parameter.

70 DN0943971

Handover


• The check of the UE capabilities for the redirection target can be skipped as the UE has already measured the target.

With the new parameter Prohibit PS-HO to WCDMA the operator can force all UEs (independent of their capability to perform PS-HO) to go to WCDMA by UE Context Release with Redirect message.

DN0943971 71

Handover

Id:0900d80580968300Confidential

4.18 LTE1387: Intra eNodeB inter-frequency load balancingThis feature LTE1387: Intra eNodeB inter-frequency load balancing provides means to move load (in terms of air interface usage) to cells of another frequency/band within the same eNodeB.

Therefore multi-frequency supporting UEs are handed over to an intra eNB neighbor cell of the other frequency/band.

The following condition must be fulfilled:

• the source cell is in active load balancing state (after the load having exceeded the high load threshold) AND

• at least one of the potential target cells has available capacity AND • the UE reports sufficient RSRP (rererence symbol received power) and RSRQ (ref-

erence signal received quality) for the target cell AND • the parameter fits to this feature, only UEs without QCI 1 bearer are handed over.

72 DN0943971

Handover

Id:0900d8058096836cConfidential

Parameters for the Handover Functional Area

5 Parameters for the Handover Functional Area

5.1 Links to Management data ordered by releases

5.1.1 Management data for RL09The Management data for the RL09 features are described in the relating “Feature Description”, chapter LTE53: Parameters for Inter and Intra eNodeB Handover via X2:

• LTE53: Intra and inter eNodeB Handover via X2 interface: Parameters

5.1.2 Management data for RL10The Management data for the RL10 feature LTE761is described in the relating “Feature Description”, chapter LTE761: Parameters for Advanced Target Cell List Handling:

• LTE761: Advanced target cell selection and handover retry for intra frequency han-dover: Parameters

The parameter for the RL10 feature LTE423 is described in the FAD: Handover:

• LTE423: Parameters for RRC Connection Release with Redirect: Parameters

5.1.3 Management data for RL20The Management data for the RL20 features are described in the relating “Feature Description”, chapter User Interface:

• LTE54: Intra-LTE Handover via S1: User Interface • LTE55: Inter-frequency Handover: User Interface • LTE562:CSFB to UTRAN or GSM via redirect: User Interface

5.1.4 Management data for RL30The Management data for the RL30 features are described in the relating “Feature Description”, chapter Management data:

• LTE56: Inter RAT Handover to WCDMA : Management data • LTE442: Network Assisted Cell Change to GSM: Management data • LTE490: Subscriber profile based mobility: Management data • LTE735: RRC Connection Re-establishment: Management data • LTE971: Intra-LTE mobility offsets: Management data

5.1.5 Management data for RL40The Management data for the RL40 features are described in the relating “Feature Description”, chapter Management data:

• LTE736: CS fallback to UTRAN • LTE872: SRVCC to WCDMA • LTE873: SRVCC to GSM • LTE984: GSM redirect with system information • LTE1073: Measurement based redirect

DN0943971 73

Handover Parameters for the Handover Functional Area

Id:0900d8058096836cConfidential

• LTE1387: Intra eNodeB inter-frequency load balancing

74 DN0943971

Handover

Id:0900d805808e418bConfidential

5.2 LTE423: Parameters for RRC Connection Release with Redirect

Name Short name Object Description Range Default value

Enable UE context release with redirect

actRedirect LNBTS This parameter enables the feature UE context release with redirect.

enabled, disabled

enabled

Threshold Th4 For RSRP

threshold4 LNCEL Threshold for RSRP of intra-fre-quency neighbour cell. If RSRP of the serving value < threshold4 then redirect is triggered. This is an A2 event type

0 ... 97, step 1

Related Hysteresis of Threshold Th4 For RSRP

hysThreshold4

LNCEL Related Hysteresis of Threshold for RSRP of serving cell for redi-rection triggerParameter is used within the entry and leave condi-tion of the A2 triggered reporting condition. The IE value is multi-plied by 2.

0 ...15 dB, step 0.5 dB

Redirection target con-figuration identifier

redrtld REDRT This parameter defines the number of redirection targets specified for the respective cell.

1...2

RAT for redirect redirRat REDRT This parameter selects the RAT in which the UE is redirected.

eutran, geran, utra-FDD, cdma2000-HRPD, cdma2000-1xRTT

eUTRA frequency redirFreqEutra

REDRT This parameter must be config-ured if redirRAT=eutran.

It is used to specify the eUTRA frequency (max. value ref. to 36.331)

0 ... max-EARFCn

GERAN band indicator redirGeran-BandIndica-tor

REDRT Indicator to distinguish the GERAN frequency band in case of ARFCN values associated with either GSM 1800 or GSM 1900 carriers. For ARFCN values not associated with one of those bands, the indicator has no meaning. This parameter must always be configured if redirRAT=geran.

0 (gsm1800), 1 (gsm1900), 2 (notUsed)

2

Table 7 Parameters for RRC connection release with redirect

DN0943971 75

Handover

Id:0900d805808e418bConfidential

List of GERAN ARFCN values

redirGeranA-RFCNValueL

REDRT List of GERAN ARFCN values. This parameter must be config-ured if redirGeranFollowingAR-FCNsSwitch = explicitListofARFCNs

0 ...1023, step 1

65535

UTRA frequency redirFreqUtra

REDRT This parameter must be config-ured if redirRAT = utra-FDD. It is used to specify the UTRA fre-quency.

0 ...16383

CDMA band redirBand-Cdma

REDRT This parameter must be config-ured if reddirRAT = cdma2000-HRPD or reddirRAT= cdma2000-1xRTT. It is used to specify the cdma2000 band-class.

bc0, bc1, bc2,.., bc17

CDMA frequency redirFreqCdma

REDRT This parameter must be config-ured if reddirRAT = cdma2000-HRPD or reddirRAT= cdma2000-1xRTT.

It is used to specify the cdma2000 ARFCN.

0 ... 2047

Name Short name Object Description Range Default value

Table 7 Parameters for RRC connection release with redirect (Cont.)

handover

Documents

operating documentation

software products

product names

product packaging

additional information

environmental services

mentioned hardware

product safetythis p