Professional Documents
Culture Documents
Document number: Document issue: Document status: Date: UMT/SYS/DD/0054 08.08/EN Standard 09/Oct/2008 External document
UNCONTROLLED COPY: The master of this document is stored on an electronic database and is write protected; it may be altered only by authorized persons. While copies may be printed, it is not recommended. Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded as uncontrolled copies. ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of AlcatelLucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose the information only to its employees with a need to know, and shall protect the information from disclosure and dissemination to third parties. Except as expressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have received this document in error, please notify the sender and destroy it immediately.
PUBLICATION HISTORY
29/AUG/2007
Issue 07.01 / EN, Preliminary New version for UA06.0 Integration of Intra-frequency event triggered measurement reporting FN in mobility FN.
17/SEP/2007
Issue 07.02 / EN, Preliminary Update after review
21/SEP/2007
Issue 07.03 / EN, Standard Standard edition
22/NOV/2007
Issue 07.04 / EN, Standard Update for compliance with UA06 POR
14/Feb/2008
Issue 08.01 / EN, Preliminary New version for additional UA06.0 features: 32601 34151 34224 34167 34229 34230 34231 34274 IMCTA Enhancements for WPS [USA Market] Immediate HO of Emergency Calls [USA Market] IF/IRAT Measurements Evolution [USA Market] Defense Mechanism for UE not Supporting CM with HSPA Mobility - Inter-freq HO Enhancements [USA Market] Mobility - IRAT Enhancements [USA Market] Mobility - SHO Enhancements [USA Market] Compound neighbour list developments (IFREQ/IRAT)
06/Mar/2008
Issue 08.02 / EN, Preliminary Update after review
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 2/213
31/Mar/2008
Issue 08.04 / EN, Standard Correction of release naming to UA06.0
18/Jul/2008
Issue 08.05 / EN, Draft Addition of Service Type PS Conversational Correction of functionality for features 34151 and 34224 UA06 special handling of 1a, 1b, 2d, 2f hysteresis
01/Aug/2008
Issue 08.06 / EN, Standard Standard edition
01/Oct/2008
Issue 08.07 / EN, Draft Additions for UA06 feature 30744 HSUPA Over Iur [Global Market]
09/Oct/2008
Issue 08.08 / EN, Standard Standard edition
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 3/213
CONTENTS
CONTENTS ............................................................................................................................................. 4 1. INTRODUCTION ........................................................................................................................... 9 1.1. 1.2. 1.3. 1.4. 2. OBJECT ................................................................................................................................... 9 SCOPE OF THIS DOCUMENT....................................................................................................... 9 AUDIENCE FOR THIS DOCUMENT ................................................................................................ 9 DEFINITIONS AND SPECIFICATION PRINCIPLES ........................................................................... 9
RELATED DOCUMENTS ........................................................................................................... 10 2.1. 2.2. APPLICABLE DOCUMENTS ....................................................................................................... 10 REFERENCE DOCUMENTS ....................................................................................................... 11
3.
3.2. 3GPP BASIC PROCEDURES ...................................................................................................... 13 3.2.1 Soft Handover............................................................................................................... 13 3.2.2 Softer handover ............................................................................................................ 13 3.2.3 Hard handover.............................................................................................................. 14 3.2.4 Cell reselection ............................................................................................................. 15 3.2.5 SRNS relocation ........................................................................................................... 15 3.2.6 Radio Link Reconfiguration .......................................................................................... 16 4. MOBILITY CASES ...................................................................................................................... 17 4.1. SOFT HANDOVER INTRA RNC.......................................................................................... 18 4.1.1 Description.................................................................................................................... 18 4.1.2 Applicability................................................................................................................... 19 4.1.3 Parameters ................................................................................................................... 19 4.1.4 Access Network impacts .............................................................................................. 19 4.1.5 Core Network impacts .................................................................................................. 19 4.2. SOFT HANDOVER INTER RNC.......................................................................................... 20 4.2.1 Description.................................................................................................................... 20 4.2.2 Applicability................................................................................................................... 22 4.2.3 Parameters ................................................................................................................... 22 4.2.4 Access Network impacts .............................................................................................. 22 4.2.5 Core Network impacts .................................................................................................. 22 4.3. SOFTER HANDOVER ......................................................................................................... 23 4.3.1 Description.................................................................................................................... 23 4.3.2 Applicability................................................................................................................... 23 4.3.3 Parameters ................................................................................................................... 24 4.3.4 Access Network impacts .............................................................................................. 24 4.3.5 Core Network impacts .................................................................................................. 24 4.4. CELL RESELECTION IN IDLE MODE .............................................................................. 25 4.4.1 Description.................................................................................................................... 25 4.4.2 Applicability................................................................................................................... 25 4.4.3 Algorithm ...................................................................................................................... 25
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 4/213
4.5. CELL RESELECTION IN CELL FACH AND CELL/URA PCH MODE ............................... 31 4.5.1 Description.................................................................................................................... 31 4.5.2 Applicability................................................................................................................... 35 4.5.3 Algorithm ...................................................................................................................... 35 4.5.4 Parameters ................................................................................................................... 35 4.5.5 Access Network impacts .............................................................................................. 37 4.5.6 Core Network impacts .................................................................................................. 38 4.6. 2G TO 3G HANDOVER FOR CS DOMAIN.......................................................................... 39 4.6.1 Description.................................................................................................................... 39 4.6.2 Applicability................................................................................................................... 41 4.6.3 Algorithm ...................................................................................................................... 42 4.6.4 Failure cases ................................................................................................................ 45 4.6.5 Parameters ................................................................................................................... 46 4.6.6 Access Network impacts .............................................................................................. 46 4.6.7 Core Network impacts .................................................................................................. 46 4.7. 4.8. 2G TO 3G HANDOVER FOR PS DOMAIN .......................................................................... 47 2G TO 3G HANDOVER FOR CS + PS DOMAINS............................................................... 48
4.9. 3G TO 2G HANDOVER FOR PS DOMAIN .......................................................................... 48 4.9.1 Description.................................................................................................................... 48 4.9.2 Applicability................................................................................................................... 49 4.9.3 Algorithm ...................................................................................................................... 50 4.9.4 Failure cases ................................................................................................................ 50 4.9.5 Parameters ................................................................................................................... 50 4.9.6 Access Network impacts .............................................................................................. 51 4.9.7 Core Network impacts .................................................................................................. 51 4.10. 3G TO 2G HANDOVER FOR CS DOMAIN.......................................................................... 52 4.10.1 Description.................................................................................................................... 52 4.10.2 Applicability................................................................................................................... 53 4.10.3 Algorithm ...................................................................................................................... 54 4.10.4 Failure cases ................................................................................................................ 54 4.10.5 Parameters ................................................................................................................... 55 4.10.6 Access Network impacts .............................................................................................. 55 4.10.7 Core Network impacts .................................................................................................. 56 4.10.8 Performance Management [USA Market] .................................................................... 56 4.11. 3G TO 2G HANDOVER FOR CS+PS DOMAINS ................................................................ 57 4.11.1 Description.................................................................................................................... 57 4.11.2 Applicability................................................................................................................... 63 4.11.3 Algorithm ...................................................................................................................... 64 4.11.4 Parameters ................................................................................................................... 64 4.11.5 Access Network impacts .............................................................................................. 64 4.11.6 Core Network impacts .................................................................................................. 64 4.12. INTER-FREQUENCY INTER-RNC HANDOVER WITHOUT IUR ....................................... 65 4.12.1 Description.................................................................................................................... 65 4.12.2 Applicability................................................................................................................... 68 4.12.3 Algorithm ...................................................................................................................... 68 4.12.4 Failure cases ................................................................................................................ 68 4.12.5 Parameters ................................................................................................................... 68 4.12.6 Access Network impacts .............................................................................................. 69 4.12.7 Core Network impacts .................................................................................................. 69 4.13. INTRA-FREQUENCY INTER-RNC HANDOVER WITHOUT IUR ....................................... 70 4.13.1 Description.................................................................................................................... 70 4.13.2 Applicability................................................................................................................... 70
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 5/213
4.14. INTER-FREQUENCY INTRA-RNC HANDOVER ................................................................ 73 4.14.1 Description.................................................................................................................... 73 4.14.2 Applicability................................................................................................................... 75 4.14.3 Algorithm ...................................................................................................................... 75 4.14.4 Failure cases ................................................................................................................ 76 4.14.5 Parameters ................................................................................................................... 76 4.14.6 Access Network impacts .............................................................................................. 76 4.14.7 Core Network impacts .................................................................................................. 76 4.14.8 Performance management [USA Market] .................................................................... 76 4.15. INTER-FREQUENCY INTER-RNC HANDOVER W ITH IUR AND MEASUREMENTS............................. 78 4.15.1 Description.................................................................................................................... 78 4.15.2 Applicability................................................................................................................... 82 4.15.3 Algorithm ...................................................................................................................... 82 4.15.4 Failure cases ................................................................................................................ 83 4.15.5 Parameters [USA Market]............................................................................................. 83 4.15.6 Access Network impacts .............................................................................................. 83 4.15.7 Core Network impacts .................................................................................................. 83 4.15.8 Performance management [USA Market] .................................................................... 83 4.16. HSDPA AND HSUPA MOBILITY ......................................................................................... 84 4.16.1 Description.................................................................................................................... 84 4.16.2 Applicability................................................................................................................... 89 4.16.3 Algorithm ...................................................................................................................... 89 4.16.4 Parameters ................................................................................................................... 89 4.16.5 Access Network impacts .............................................................................................. 89 4.16.6 Core Network impacts .................................................................................................. 89 4.17. SRNS RELOCATION UE NOT INVOLVED [GLOBAL MARKET] ....................................... 90 4.17.1 Description.................................................................................................................... 90 4.17.2 Applicability................................................................................................................... 90 4.17.3 Algorithm ...................................................................................................................... 90 4.17.4 Parameters ................................................................................................................... 90 4.17.5 Access Network impacts .............................................................................................. 90 4.17.6 Core Network impacts .................................................................................................. 90 4.18. 3G2G REDIRECTION AT RRC ESTABLISHMENT FOR SPEECH CALLS ........................ 91 4.18.1 Description.................................................................................................................... 91 4.18.2 Applicability................................................................................................................... 91 4.18.3 Algorithm ...................................................................................................................... 92 4.18.4 Parameters ................................................................................................................... 93 4.18.5 Access Network impacts .............................................................................................. 93 4.18.6 Core Network impacts .................................................................................................. 93 4.19. EMERGENCY AND PRIORITY CALLS ............................................................................... 94 4.19.1 Parameters ................................................................................................................... 94 4.19.2 PERFORMANCE MANAGEMENT [USA Market] ........................................................ 95 4.20. INTELLIGENT MULTI CARRIER TRAFFIC ALLOCATION (IMCTA)................................... 97 4.20.1 Description.................................................................................................................... 97 4.20.2 Applicability................................................................................................................. 100 4.20.3 Algorithm .................................................................................................................... 101 4.20.4 Parameters ................................................................................................................. 107 4.20.5 Performance Management ......................................................................................... 112 4.21. MOBILITY IN CELL_PCH AND URA_PCH RRC STATES ................................................ 113 4.21.1 Description.................................................................................................................. 113 4.21.2 Applicability................................................................................................................. 115
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 6/213
4.22. HCS: CELL RESELECTION CONTROL IN A HIERARCHICAL CELL STRUCTURE [GLOBAL MARKET] ............................................................................................................................ 117 4.22.1 Description.................................................................................................................. 117 4.22.2 Applicability................................................................................................................. 118 4.22.3 Algorithm .................................................................................................................... 119 4.22.4 parameters ................................................................................................................. 122 4.22.5 Access Network impacts ............................................................................................ 124 4.22.6 Core Network impacts ................................................................................................ 124 5. COMMON PROCEDURES ....................................................................................................... 125 5.1. PERIODIC MEASUREMENT REPORTING MODE .......................................................... 125
5.2. INTRA-FREQUENCY EVENT TRIGGERED MEASUREMENT REPORTING MODE ...... 125 5.2.1 Description.................................................................................................................. 125 5.2.2 configuration ............................................................................................................... 126 5.2.3 feature interworking .................................................................................................... 128 5.2.4 parameters ................................................................................................................. 129 5.3. ACTIVE SET MANAGEMENT ........................................................................................... 130 5.3.1 Algorithm for periodic reporting mode ........................................................................ 130 5.3.2 Enhanced Algorithm for periodic reporting mode....................................................... 131 5.3.3 Parameters for periodic reporting mode..................................................................... 132 5.3.4 Case of intra-frequency Event-Triggered Reporting mode ........................................ 132 5.3.5 Parameters for Event reporting mode ........................................................................ 141 5.3.6 Performance management......................................................................................... 143 5.3.7 E-DCH active set management.................................................................................. 143 5.4. PRIMARY CELL DETERMINATION.................................................................................. 145 5.4.1 Description.................................................................................................................. 145 5.4.2 Case of intra-frequency Periodic Reporting mode ..................................................... 145 5.4.3 Case of intra-frequency Event-Triggered Reporting mode ........................................ 145 5.4.4 Parameters ................................................................................................................. 147 5.5. LIST OF COMPOUNDING CELLS FOR THE MONITORED SET DEFINITION................................... 149 5.5.1 Description.................................................................................................................. 149 5.5.2 Applicability................................................................................................................. 149 5.5.3 Algorithm .................................................................................................................... 149 5.5.4 Parameters ................................................................................................................. 151 5.5.5 Performance management......................................................................................... 153 5.6. MANAGEMENT OF SYSTEM INFORMATION BLOCKS (SIB) ........................................................ 154 5.6.1 SIB Update ................................................................................................................. 154 5.6.2 SIB Repetition period.................................................................................................. 154 5.7. 5.8. INTRA-FREQ MEASUREMENTS CONFIGURATION VIA SIB11 ..................................... 155 DHO MANAGEMENT ........................................................................................................ 155
5.9. ALARM HANDOVER AND ALARM MEASUREMENTS .................................................... 157 5.9.1 Overview..................................................................................................................... 157 5.9.2 Alarm measurements activation when Intra Frequency measurements are periodic based ........................................................................................................................... 157 5.9.3 Alarm measurements activation when Intra Frequency measurements are event based 160 5.9.4 Parameters ................................................................................................................. 166 5.10. MEASUREMENTS CONFIGURATION FOR INTER-FREQ/INTER-RAT ......................... 168 5.10.1 Measurement reporting .............................................................................................. 168
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 7/213
5.11. INTRA-FREQUENCY MEASUREMENTS......................................................................... 172 5.11.1 Configuration .............................................................................................................. 172 5.11.2 Missing Measurements............................................................................................... 173 5.12. COMPRESSED MODE...................................................................................................... 175 5.12.1 Introduction ................................................................................................................. 175 5.12.2 UE capability............................................................................................................... 175 5.12.3 Method........................................................................................................................ 176 5.12.4 Measurement purpose................................................................................................ 177 5.12.5 Pattern shape ............................................................................................................. 178 5.12.6 slot formats/ frame structure....................................................................................... 179 5.12.7 Procedures & messages ............................................................................................ 179 5.12.8 Impacts on RRM Specific for SF/2 method ................................................................ 183 5.12.9 HLS............................................................................................................................. 185 5.12.10 SRNS Relocation [Global Market] .......................................................................... 192 5.12.11 RNS Inter-release Compatibility Use cases ........................................................... 193 5.12.12 DRNS scenarios ..................................................................................................... 195 5.12.13 Alpha CEM cards impact ........................................................................................ 196 5.12.14 UE impacts.............................................................................................................. 197 5.12.15 Impact on other procedures .................................................................................... 197 5.12.16 Change of Alarm measurement type (Common HLS and SF/2) ............................ 200 5.12.17 Defence mechanism for UE not supporting CM with HSPA ................................... 201 5.12.18 Parameters ............................................................................................................. 202 5.13. 2G TARGET CELL CHOICE RADIO CRITERIA ................................................................ 208 5.13.1 Description.................................................................................................................. 208 5.13.2 Parameters ................................................................................................................. 208 5.14. FDD TARGET CELL CHOICE INTER FREQUENCY RADIO CRITERIA .......................... 209 5.14.1 Description.................................................................................................................. 209 5.14.2 Parameters ................................................................................................................. 209 5.15. NEIGHBOR CELLS FLEXIBLE MANAGEMENT ............................................................... 210 5.15.1 Description.................................................................................................................. 210 5.15.2 Algorithm .................................................................................................................... 210 5.15.3 Parameters ................................................................................................................. 211 6. ABBREVIATIONS AND DEFINITIONS .................................................................................... 211 6.1. 6.2. 6.3. ABBREVIATIONS.............................................................................................................. 211 DEFINITIONS .................................................................................................................... 213 UA06 VALUE MAPPING FOR HYSTERESIS AND W EIGHT USA MARKET ................................. 213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 8/213
1.
1.1.
INTRODUCTION
OBJECT
This document specifies the UMTS mobility procedures for mobiles connected to the network. Intersystem mobility procedures (to and from GSM) are also described in this document. Although this document is focused on UTRAN, it also addresses radio mobility procedure applicable to the Core Network.
How is the document structured? Chapter3 presents definitions and concepts which will be used throughout the document. Chapter4 contains the mobility cases supported in this version of the document Chapter5 contains common procedures used in several mobility cases (such as measurement processing, compressed mode ...)
1.2.
1.3.
1.4.
For the purpose of the present document, the following notations apply: [Global Market] This tagging of a word indicates that the word preceding the tag "[Global Market]" applies only to the Global Market. This tagging of a heading indicates that the heading preceding the tag "[Global Market]" and the section following the heading applies only to the Global Market.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 9/213
[Global Market - ]
[USA Market - ]
Text that is not identified via one of the hereabove tags is common to all markets.
2.
2.1.
RELATED DOCUMENTS
APPLICABLE DOCUMENTS
[A1] [A2] [A3] [A4] [A5] [A6] [A7] 25.413 25.423 25.433 25.331 25.304 44.018 25.133 UTRAN Iu interface RANAP signalling UTRAN Iur interface RNSAP signalling UTRAN Iub interface NBAP signalling Radio Resource Control (RRC) Protocol Specification UE procedures in idle mode and procedures for cell reselection in connected mode Mobile radio interface layer 3 specification; Radio Resource Control (RRC) protocol Requirements for support of radio resource management (FDD)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 10/213
2.2.
REFERENCE DOCUMENTS
[R1] [R2] [R3] [R4] [R5] [R6] [R7] [R8] [R9] UMT/SYS/DD/000031 Traffic Management UMT/SYS/DD/000034 PS Call Management UMT/SYS/DD/013000 Mobility Performance Improvements UMT/SYS/DD/013319 HSDPA System Specification UMT/SYS/DD/013008 Intra-frequency Event Triggered Measurement Reporting Functional Specification UMT/SYS/DD/018827 E-DCH System Specification UMT/SYS/DD/000128 IRM - Intelligent Rab mapping UMT/SYS/DD/18470 NN-20500-028 SRNS Relocation UE not involved Alcatel-Lucent 9300 W-CDMA Product Family Counter Reference Guide - RNC Counters
[R10] UMT/SYS/DD/000086 UTRAN Power Management [R11] UMT/SYS/DD/023088 UE dedicated scenarios [R12] UMT/SYS/DD/023091 Preemption [R13] UMT/SYS/DD/010042 3G-2G Emergency redirection
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 11/213
3.
3.1.
The following figure briefly presents the UMTS network elements which are relevant to mobility features.
Packet data network External Networks GGSN HLR Gn SGSN Gn SGSN Gs MSC/VLR E MSC/VLR PSTN
Node B cells
Node B
Node B
Node B
Node B
Uu
UE
Figure 1: general architecture The protocol stacks which are used in this document are the following: In UTRAN: RANAP: specified in 25.413. RANAP is the Radio Access Network Application Part. This protocol specifies radio network layer signalling procedures between RNCs and CN on the Iu interface. RNSAP: specified in 25.423. RNSAP is the Radio Network Subsystem Application Part. This protocol specifies radio network layer signalling procedures between RNCs in UTRAN on the Iur interface. NBAP: specified in 25.433. NBAP is the NodeB Application Part. This protocol specifies radio network layer signalling procedures between RNC and Node B on the Iub interface. RRC: specified in 25.331. RRC is the Radio Resource Control protocol for the UE-UTRAN radio interface. This protocol terminates in the UE and in the Serving RNC. RRC messages are sent over the Iub and Uu interfaces (and possibly the Iur interface) ALCAP: ALCAP refers to AAL2 Signalling and is specified in ITU-T/Q2630.1. AAL2 is one of the transport layer used in UTRAN, and also between UTRAN and Core Network for CS applications.
In the Core Network: MAP: specified in 29.002. MAP is the Mobile Application Part. This protocol specifies the signalling procedures between the CS Core Network nodes. GTP: specified in 29.060. GTP is the GPRS Tunnelling Protocol. This protocol specifies the signalling procedures between the PS Core Network nodes.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 12/213
3.2.
This chapter intends to clarify the basic mobility procedures which are applicable to UMTS UTRAN/FDD networks, irrespective of the version to which this document applies. The intention is also to set some vocabulary basis that will be used throughout the document. The mobility cases specified in the following sections are all using those basic procedures, i.e.: soft handover hard handover cell reselection (UE controlled mobility) SRNS relocation radio link reconfiguration
Cell 1
Cell 2
Cell 1
Cell 2
Cell 2
Cell 3
UE Call establishment
Figure 2: Soft handover examples Regarding network architecture, the soft handover may be either: intra-NodeB: the cells belong to the same NodeB (In case the NodeB performs recombination between radio links, this case is called softer handover; refer to 3.2.2) inter-NodeB: the cells belong to different NodeB intra-RNC: the NodeB involved in the active set are all controlled by the same RNC (the controlling RNC) inter-RNC: the NodeB involved in the active set are controlled by different RNC (requires Iur) Soft handover only applies to dedicated physical channels and E-DCH. Soft handover cannot be applied to shared or common transport channels (e.g. DSCH, FACH...).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 13/213
UE
Figure 3: softer handover example Soft and softer handover may be combined (i.e. used at the same time for a given mobile)
UE Before
UE After
Figure 4: hard handover example Regarding network architecture, the hard handover may be either: intra-NodeB: the cells belong to the same NodeB inter-NodeB: the cells belong to different NodeB intra-RNC: the NodeB involved are all controlled by the same RNC (the controlling RNC) inter-RNC: the NodeB involved are controlled by different RNC inter-system: between UTRAN and GSM inter-PLMN: the NodeB involved are part of different PLMN Hard handover applies to the following RRC states: CELL_DCH (the mobile is allocated either a dedicated channels (DCH transport channel) or a shared channels (DSCH transport channel)) CELL_FACH (the mobile is using common transport channels), as an option from the network
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 14/213
SGSN
MSC
MSC
SGSN
MSC
MSC
RNC1
RNC2
RNC1
RNC2
SRNS relocation may be used in many cases: incoming intersystem handover (in this case, the source RNC is actually a 2G-BSC) outgoing intersystem handover (in this case, the target RNC is actually a 2G-BSC) UTRAN radio mobility in case Iur is not present, or some Iur needed functions are not supported (this may also happen in case of handover between 2 PLMN) UTRAN radio mobility in case Iur is overloaded SRNS relocation for optimisation of UTRAN Iur routing SRNS relocation for optimisation of UTRAN parameters
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 15/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 16/213
4.
MOBILITY CASES
This chapter describes all the mobility cases applicable for the current version of the document. The complete list of cases is summarized in the table below: Section 4.3 4.1 4.2 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.7 4.7 4.10 4.10 4.6 4.7 4.8 4.10.8 4.4 4.4 4.4 4.5 4.5 4.5
Softer Handover Soft Handover, intra-RNC Soft Handover, inter-RNC Inter-frequency Inter-RNC Handover without Iur (i.e. SRNS UE involved) Intra-frequency Inter-RNC Handover without Iur (i.e. SRNS UE involved) Hard handover inter-frequency, intra-RNC Inter-Frequency Inter-RNC Handover with Iur and measurements HSDPA and HSUPA mobility SRNS Relocation (Ue not involved) 3G2G Redirection at RRC establishment for speech call Emergency and Priority Calls iMCTA Mobility in Cell_PCH and URA_PCH states HCS 3G to 2G handover for PS domain in blind mode 3G to 2G handover for PS domain with measurements 3G to 2G handover for CS domain in blind mode 3G to 2G handover for CS domain with measurements 2G to 3G handover for CS domain 2G to 3G handover for PS domain 2G to 3G handover for CS + PS domain 3G to 2G handover for both PS and CS domains 3G to 2G cell reselection in Idle mode 3G to 3G cell reselection inter-frequency in Idle mode 3G to 3G cell reselection intra-frequency in Idle mode 3G to 2G cell reselection in CELL_FACH mode 3G to 3G cell reselection inter-frequency in CELL_FACH mode 3G to 3G cell reselection intra-frequency in CELL_FACH mode Table 1: list of mobility cases
Since UA05.0, Inter Frequency Hard Handover or Inter System Hard Handover are triggered by the iMCTA function for Alarm, Service or CAC failure reason (refer to 4.20 section). .
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 17/213
4.1.
4.1.1 DESCRIPTION
In this case, the links which are added/withdrawn from the active set are all managed by the SRNC (i.e. the RNC in charge of the RRC connection with the mobile). Radio link recombination is performed at the SRNC level. For further details on this process, please refer to the "DHO management" section in the Common procedures chapter.
Iu SRNC Iub
NodeB 1
NodeB 2
UE
In this case, there is already a macro-diversity link supported by the Serving RNC (NodeB1). A new link from NodeB2 is added:
UE
NodeB 2 RRC/ Measurement Report NBAP/ Radio Link setup req NBAP/ Radio Link setup resp FP/ DL Sync (CFN) FP/ UL Sync (ToA) RRC/ active set update RRC/ active set update complete
Serving RNC
Figure 7: Radio Link addition (1) based on active set evaluation process result, a new branch is added using the NodeB 2. This implies a new radio link to be setup with the NodeB 2, and the associated AAL2 Cid(s) to be allocated. The Node B shall only consider a transport bearer synchronised after it has received at least one DL DATA FRAME on this transport bearer before LTOA (Latest Time of Arrival). (2) once new resources are created, the mobile active set is updated with the new radio link The next dataflow is an example of radio link removal.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 18/213
NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp 2
Figure 8: Radio Link deletion (1) based on active set evaluation process result, the SRNC decides to remove a radio link from the active set. The mobile active set is updated with the new configuration. (2) the link is deleted at the NodeB, and the AAL2 Cid(s) are released. For details on the active set evaluation process, please refer to the [Active Set Evaluation] section in the Common Procedures chapter
4.1.2 APPLICABILITY
The soft handover applies only on dedicated physical resources. In this version, the active set evaluation (i.e. Decision to add/drop links) is based on the same algorithm and parameters (with possibly different values) for PS and CS calls. Therefore, soft & softer handover is a network default behaviour which applies to all PS & CS calls whatever is the user data rate. Soft & softer handover do not apply to HS-DSCH calls. Besides, it is possible to limit the number of soft handover legs being used by setting the relevant parameter to the needed value. For more details, please refer to the [Active Set Evaluation] section in the Common Procedures chapter. If the Active Set Update procedure fails, the call is kept with the previous active set cells.
4.1.3 PARAMETERS
Refer to the [Active Set Evaluation] section in the [Common Procedures] chapter.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 19/213
4.2.
4.2.1 DESCRIPTION
In this case, the links which are added/withdrawn from the active set are not all controlled by the SRNC. In
such a case two RNCs are involved with each a different role:
the SRNC (Serving RNC): which is the RNC in charge of the RRC connection with the mobile the DRNC (Drift RNC): which is the RNC which controls the NodeB having a radio link in the active set. This DRNC acts as a router from the RNC and the UTRAN transport point of view (e.g. in this version there are as many dedicated links on the Iur as radio links which are controlled by the DRNC).
The fact that there is a DRNC in the communication path rather than only one unique SRNC is completely hidden to the mobile and the Core Network. For further details on the Radio link recombination process, please refer to the "DHO management" section in the Common procedures chapter.
Iu
SRNC Iur
DRNC Iub
NodeB 0
NodeB 1
NodeB 2
UE
Figure 9: soft handover over Iur In this case, there is already a macro-diversity link supported by the NodeB0 (controlled by the SRNC) and the NodeB1 (controlled by the Drift RNC). A new link from NodeB2 is added:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 20/213
RNSAP/ Radio Link addition req NBAP/ Radio Link setup req NBAP/ Radio Link setup resp RNSAP/ Radio Link addition resp (Binding Id) New AAL2 connections are setup for both the DCCH and the DTCH AAL2/ ERQ AAL2/ ECF AAL2/ ERQ AAL2/ ECF 1
FP/ DL Sync (CFN) FP/ DL Sync (CFN) FP/ UL Sync (ToA) FP/ UL Sync (ToA) RRC/ active set update RRC/ active set update complete 2
Figure 10: Radio Link addition over Iur (1) Based on active set evaluation result, a new branch is added using the NodeB2. A new radio link is setup with the NodeB 2, the associated AAL2 Cid(s) are allocated on the Iub and Iur. On the Iur, 2 separate Cid are used on the Iur for both DCCH and DTCH. Since there is already a macro-diversity link controlled by the DRNC for that communication, there is no need to build a SCCP connection between the SRNC and the DRNC (this has already been done when the Radio Link towards NodeB 1 has been setup) the SRNC is using the "Radio Link Addition" rather than "Radio Link Setup" RNSAP procedure. In the RADIO LINK ADDITION RESPONSE message, the Drift RNC provides to the SRNC the list of neighbouring cells. This information is used by the SRNC to update the list of cells to be measured by the UE. (2) Once new resources are created, the mobile active set is updated with the new radio link
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 21/213
RNSAP/ Radio Link deletion req NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp RNSAP/ Radio Link deletion resp AAL2/ REL AAL2/ RLC AAL2/ REL AAL2/ RLC SCCP/ Released SCCP/ Release Complete 2
Figure 11: Radio Link deletion over Iur (1) based on active set evaluation result, the SRNC decides to remove a radio link from the active set. The mobile active set is updated with the new configuration. (2) the link is deleted at the NodeB, the Iub AAL2 Cid the 2 Iur AAL2 Cid are released. The SCCP released message is sent if the radio link which is removed is the last one supported by the DRNC for this mobile. For details on the active set evaluation process, please refer to the [Active Set Evaluation] section in the Common procedures chapter
4.2.2 APPLICABILITY
The soft handover inter-RNC requires the presence of an Iur between the involved RNCs. For other applicability considerations, please refer to [Soft Handover intra-RNC].
4.2.3 PARAMETERS
Refer to the [Active Set Evaluation] section in the [Common Procedures] chapter.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 22/213
4.3.
SOFTER HANDOVER
4.3.1 DESCRIPTION
In this case, the links which are added/withdrawn from the active set are all controlled by a NodeB already supporting a radio link towards the mobile, as in the following figure:
Iu
UE
Figure 13: Radio Link addition for softer handover (1) based on active set evaluation result, a new branch is added using the NodeB. There is no new AAL2 Cid to be allocated since the recombination between the 2 radio links is performed at the NodeB. When the Radio Link Addition Response is sent, the NodeB start UL reception and DL transmission on the new radio link. (2) once new resources are created, the mobile active set is updated with the new radio link For further details on the active set evaluation process, please refer to [Active Set Evaluation] section in the Common procedures chapter For further details on the Radio link recombination process, please refer to the [DHO management] section in the Common procedures chapter. A new UA06.0 feature can be activated and enables Node B to support the softer handover with 3 sectors amongst any of the 6 sectors on the same frequency, i.e. without cluster limitation.
4.3.2 APPLICABILITY
Please refer to 4.1
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 23/213
4.3.3 PARAMETERS
Refer to the [Active Set Evaluation] section in the [Common Procedures] chapter. Name is6SectorsNodeb Object/Class RadioAccessService Class3
Definition Flag for 6 sectors softer HO feature activation
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 24/213
4.4.
4.4.1 DESCRIPTION
This paragraph covers the following mobility cases: "3G to 3G cell reselection intra-frequency in Idle mode" which allows a UMTS mobile camping on a 3G cell to reselect a cell using the same technology and frequency "3G to 3G cell reselection inter-frequency in Idle mode", i.e. with 3G cells using different frequencies "3G to 2G cell reselection in Idle mode" which allows a "GSM capable" UMTS mobile to reselect a GSM cell when being in idle mode in the UMTS coverage. only UTRAN/FDD and GSM Radio Access Technologies are known and supported HCS (Hierarchical Cell Structure) in Idle mode is supported (Please refer to section 4.22; present chapter describes behaviour when HCS is not used) High mobility detection is supported
4.4.2 APPLICABILITY
This feature is applicable to any multimode (for the intersystem reselection) mobile or UTRAN/FDD mobile (for the 3G only reselection) being Idle under UMTS coverage.
4.4.3 ALGORITHM
As specified in 25.304, the algorithm for cell reselection defines a criteria for GSM or UTRAN/FDD neighbouring cells tracking and measurement a criteria S to assess GSM and FDD cells eligibility a criteria R for ranking of eligible cells
The same algorithm has been defined in 25.304 for intersystem cell reselection: If Squal > SsearchRAT m, and (Srxlev > SHCS,RATm if SHCS,RATm is signaled) UE need not perform measurements on cells of RAT "m". If Squal <= SsearchRAT m, or (Srxlev <= SHCS,RATm if SHCS,RATm is signaled) perform measurements on cells of RAT "m". If SsearchRAT m, is not sent for serving cell, perform measurements on cells of RAT "m"
The same algorithm has been defined in 25.304 for inter-frequency cell reselection: If Squal > Sintersearch, and MBMS PL has not been indicated, and (Srxlev > SsearchHCS if SsearchHCS is signaled) UE need not perform inter-frequency measurements If Squal > Sintersearch, or (Srxlev <= SsearchHCS if SsearchHCS is signaled) perform inter-frequency measurements
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 25/213
NOTE 1: If HCS is not used and if Slimit,SearchRATm is sent for serving cell, UE shall ignore it. NOTE 2: The presence of SsearchHCS and SHCS,RATm thresholds in system information are used to avoid introducing new parameters to system information and their presence does not imply that HCS is used. The change is that the RxLev (i.e. RSCP) of the serving cell below a RSCP based threshold may also trigger UE measurements (R5 mobiles) and on another frequency or another RAT.
CRITERIA S
25.304 defines the FDD cell selection criteria S as being For FDD cells: Srxlev > 0 AND Squal > 0 For GSM cells: Srxlev > 0 Where: Squal = Qqualmeas Qqualmin Srxlev = Qrxlevmeas - Qrxlevmin - Pcompensation with:
Squal Srxlev Qqualmeas Qrxlevmeas Qqualmin Qrxlevmin Pcompensation UE_TXPWR_MAX_RACH P_MAX Cell Selection quality value (dB) Cell Selection RX level value (dB) Measured cell quality value. The quality of the received signal expressed in CPICH Ec/N0 (dB) Measured cell RX level value. This is received signal, CPICH RSCP for FDD cells (dBm) Minimum required quality level in the cell (dB) Minimum required RX level in the cell (dBm) max(UE_TXPWR_MAX_RACH P_MAX, 0) (dB) Maximum TX power level an UE may use when accessing the cell on RACH (read in system information) (dBm) Maximum RF output power of the UE (dBm)
Any cell (serving and any GSM or UTRAN/FDD neighbouring cells) which fulfill these criteria will be part of the list for ranking.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 26/213
Qoffset1
In all cases, the UE shall reselect the new cell, only if the cell reselection criteria are fulfilled during a time interval Treselection.
Since R5 release (if the following scaling parameters are sent in SIB3), the UE shall apply the scaling rules: Intra frequency cells : If High mobility is detected, Treselection value is multiplied by the speed dependent scaling factor for Treselection value (=speedDependScalingFactorTReselection OAM parameter) which is lower than 1; Inter frequency cells: Treselection value is multiplied by the inter-frequencyScaling factor for treselection value (=interFreqScalingFactorTReselection OAM parameter) which is greater than 1. If the mobile is in High-mobility state it is also multiplied by the speed dependent scaling factor for Treselection value; Inter Rat cells: Treselection value is multiplied by the inter-rat scaling factor for treselection value (=interFreqScalingFactorTReselection OAM parameter) which is greater than 1. If the
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 27/213
The high mobility state doesnt mean the mobile speed is high but the number of reselection is high.
4.4.4 PARAMETERS
This paragraph lists all the parameters needed when HCS is not used and displayed to the operator at the OMC-R. All those parameters are broadcast on the BCCH using either SIB3 for cell reselection parameters related to the serving cell; SIB11 for cell reselection parameters related to neighbouring cells.
3 3 3 3 3
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 28/213
speedDependScalingFacto rTReselection
CellSelectionInfo
interFreqScalingFactorTRe selection
CellSelectionInfo
interRatScalingFactorTRes election
CellSelectionInfo
tCrMax
CellSelectionInfo
nCR
CellSelectionInfo
tCrMaxHyst
CellSelectionInfo
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 29/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 30/213
4.5.
4.5.1 DESCRIPTION
When in CELL_FACH, CELL PCH or URA PCH mode, although the mobile is connected to the network (there exist a RRC connection) the UE mobility is controlled by "cell re-selection rules" as in Idle mode. This paragraph covers the following mobility cases: "3G to 3G cell reselection intra-frequency in CELL_FACH or CELL/URA PCH mode" "3G to 3G cell reselection inter-frequency in CELL_FACH or CELL/URA PCH mode" "3G to 2G cell reselection in CELL_FACH or CELL/URA PCH mode" HCS (Hierarchical Cell Structure) in Fach mode is supported (Please refer to section 4.22; present chapter describes behaviour when HCS is not used)
INTRA-RNC CASE
In this case, the UE is reselecting a new cell being also controlled by the SRNC, as in the figure below (please note that the old and the new cells may also be controlled by the same NodeB).
Iu SRNC Iub
NodeB 1
NodeB 2
FACH 1
FACH 2
UE Before
UE After
Figure 14: Intra-RNC cell re-selection in CELL_FACH The next dataflow is an example of intra-RNC cell re-selection in CELL_FACH.
UE NodeB 1, 2 RRC/ RACH / Cell Update (cause "cell reselection") RRC/ FACH / Cell Update Confirm (RRC state = CELL_FACH, CN Information (PLMN Id, LAI, RAI), c-RNTI) Serving RNC SGSN
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 31/213
Having re-selected the new cell, the UE generates a CELL UPDATE to the SRNC, so that the SRNC keeps the current cell updated for paging. In case the CELL UPDATE CONFIRM message either includes "CN information elements" or "Ciphering mode info" or "Integrity protection mode info" or "New C-RNTI" or "New U-RNTI", a UTRAN MOBILITY INFORMATION CONFIRM message is then answered by the mobile. In Alcatel-Lucent implementation, the CELL UPDATE CONFIRM will always contain a new-CRNTI.
INTER-RNC CASE
In this case, the UE is reselecting a new cell being controlled by an RNC different from the SRNC. As in the figure below, this RNC may possibly depend from another SGSN.
GGSN
SGSN 2
RNC 2
NodeB 2
FACH 1
FACH 2
UE Before After
UE
Figure 16: Inter-RNC cell re-selection in CELL_FACH The next dataflow is an example of inter-RNC cell re-selection in CELL_FACH. In this version, UTRAN does not support common channel over Iur, nor 3G to 3G SRNS Relocation. The complete service re-establishment is therefore divided into 3 parts: The initial RRC access The RAU phase (if needed) The service re-establishment phase
UE
SGSN 1
SGSN 2
Based on the u-RNTI analysis, the new RNC (RNC2) detects that the UE is actually connected to another SRNC. The RNC2 rejects the cell update using the RRC connection release procedure, forcing the mobile to Idle mode. RRC/ RACH / Cell Update (U-RNTI, cause cell reselection) RRC/ FACH / RRC Connection Release (U-RNTI, cause DSCR)
Figure 17: Initial RRC access, first steps when the Drift RNC2 is Alcatel-Lucent
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 32/213
UE
SGSN 1
SGSN 2
RRC/ RACH / Cell Update (U-RNTI, cause cell reselection) RRC message received from UE containing U-RNTI ID as addressing information. The procedure is used by the drift RNC2 to forward to the Serving RNC1 the RRC Cell Update message received on the RACH. RNSAP/ UPLINK SIGNALLING TRANSFER INDICATION / Cell Update is forwarded to the SRNC The SRNC received the cell update and starts an RRC connection release procedure, forcing the mobile to idle mode. The Serving RNC1 uses the Downlink Signalling Transfer procedure to request from the non Alcatel-Lucent Drift RNC2 the transfer of a RRC Connection Release message on the FACH. This procedure is in response to the received Uplink Signalling Transfer procedure. RNSAP/ DOWNLINK SIGNALLING TRANSFER REQUEST / RRC Connection Release (U-RNTI, cause directed signaling connection re-establishment) RRC/ FACH / RRC Connection Release (U-RNTI, cause U-RNTI, cause directed signaling connection re-establishment)
Figure 18: Initial RRC access, first steps when the Drift RNC2 is not Alcatel-Lucent
UE RNC 1 RNC 2 SGSN 1 SGSN 2
When it enters Idle mode, the UE requests for a RAU, which will be followed by a "service request" (follow-on request pending) used for re-establishing UTRAN resources corresponding to the PS services which were supported by RNC 1. RRC/ RACH / RRC Connection Request (cause re-establishment ) RRC/ FACH / RRC Connection Setup (DCCH, U-RNTI, RRC state = CELL_FACH) RRC/ RACH / RRC Connection Setup Complete RRC/ RACH / Initial Direct Transfer (Routing Area Update Request, Follow-on request pending, PS domain) SCCP/ Connection Request (Initial UE msg (Routing Area Update Request)) SCCP/ Connection Confirm
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 33/213
The active PDP context(s) are retrieved from the old to the new SGSN, and security procedures are activated by the new SGSN. GTP/ SGSN ctx request RANAP/ SRNS ctx request RANAP/ SRNS ctx response GTP/ SGSN ctx response GTP/ SGSN ctx ack GMM/ Authentication and Ciphering Request GMM/ Authentication and Ciphering Response
RANAP/ Security Mode Command (UIAx, UEAy) RRC/ Security Mode Command RRC/ Security Mode Complete RANAP/ Security Mode Complete Once security is in place, the GGSN and the HLR are updated with the new UE status and location The connection with the old RNC is eventually released once the RAU procedure is completed in the new SGSN. RANAP/ Iu release command RANAP/ Iu release complete GMM/ Routing Area Update Accept (P_TMSI) GMM/ Routing Area Update Complete
UE
RNC 1
RNC 2
SGSN 1
SGSN 2
GMM/ Service Request (Data) The SGSN requests the UTRAN for RAB allocation, corresponding to the active PDP context being re-activated by the UE. In this example, the new RAB is setup in CELL_FACH state. RANAP/ RAB Assignment Request In the target RNC, the new RAB is setup in CELL_FACH state, as for a PS call establishment. Further on, based on Always-On algorithm and user traffic volume, the mobile is possibly moved to the CELL_FACH state. RRC/ FACH / RB Setup (DTCH, RRC state) RRC/ RACH / RB Setup Complete RANAP/ RAB Assignment Response GMM/ Service Accept
3G TO 2G CASE
This mobility case is similar to the inter-RNC mobility case: at some point, the mobile in PS active mode will reselect a GSM cell the mobile will perform a RA update in its new GSM cell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 34/213
2G TO 3G CASE
From the UTRAN point of view, this case is equivalent to a Routing Area Update procedure followed by a PS call setup (possibly linked together using the follow-on request facility in the GMM RAU procedure).
4.5.2 APPLICABILITY
This feature is applicable to any multimode (for the intersystem reselection) mobile or UTRAN/FDD mobile (for the 3G only reselection) being in CELL_FACH mode under UMTS coverage.
4.5.3 ALGORITHM
Please refer to [Cell Reselection In Idle Mode].
4.5.4 PARAMETERS
In connected mode (CELL-FACH, CELL-PCH and URA-PCH), specific reselection parameters when HCS is not used can be sent using: SIB4 for cell reselection parameters related to the serving cell if feature broadcast of SIB4 is enabled SIB12 for cell reselection parameters related to the neighboring cells if feature broadcast of SIB12 is enabled Following activation parameters are used: Name Object/Class
FDDCell Class3
SIB4enable
SIB12enable
FDDCell Class3
isDynamicSibAlgoWithSBAllowed
RadioAccessService Class3
Definition When set to TRUE, indicates that the SIB4 feature is activated. In this case, the parameter isDynamicSibAlgoWithSbAllowed has to be set to true. YES: SIB4 is sent NO: SIB4 is not sent When set to TRUE, indicates that the SIB12 feature is activated. In this case, the parameter isDynamicSibAlgoWithSbAllowed has to be set to true. YES: SIB12 is sent NO: SIB12 is not sent This parameter activates/deactivates the use of SB block in the dynamic SIB scheduling algorithm used to broadcast SIB on the Air interface. It has to be set to true in order to broadcast SIB4 and SIB12.
The list of parameters for SIB4/12 is the same as for SIB3/11 but they are described in dedicated objects. If SIB4/SIB12 are not broadcasted, parameters of SIB3/SIB11 are used instead.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 35/213
sIntraSearch
4 4 4 4
qHyst1 qHyst1Fach qHyst1PCH qHyst2 qHyst2Fach qHyst2Pch tReselection tReselectionFach tReselectionPch sibMaxAllowedUlTxPower OnRach sSearchHcs
4 4 4 4 4 4 4 4 4 4 4
sHcsRatGsm
CellSelectionInfoC onnectedMode
speedDependScalingFacto rTReselection
CellSelectionInfoC onnectedMode
interFreqScalingFactorT
CellSelectionInfoC onnectedMode
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 36/213
CellSelectionInfoC onnectedMode
nCR tCrMaxHyst
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 37/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 38/213
4.6.
4.6.1 DESCRIPTION
DATAFLOW
In this case the mobile connected to the CS domain is moved from a 2G cell to a 3G cell.
Anchor MSC
2G-MSC
3G-MSC
SRNC
NodeB
UE Before After
UE
Figure 22: 2G to 3G handover for CS The next dataflow is an example of inter-MSC 2G to 3G CS handover.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 39/213
BSSMAP/ Handover Required (Source RNC to target RNC transparent information) MAP/ Prepare Handover (Handover Request) SCCP/ Connection Request SCCP/ Connection Confirm RANAP/ Relocation request (Source RNC to target RNC transparent information) NBAP/ Radio Link Setup Request NBAP/ Radio Link Setup Response AAL2/ ERQ AAL2/ ECF RANAP/ Relocation request Ack (Handover to UTRAN command) MAP/ Prepare Handover ack (Handover Request Ack) BSSMAP/ Handover command (Handover to UTRAN command) RR/ Intersystem to UTRAN Handover command (Handover to UTRAN command) RRC/ Handover to UTRAN complete RRC/ Security Mode Command (Integrity Protection) RRC/ Security Mode complete RRC/ UTRAN Mobility Information (PS domain NAS Information (Routing Area Id)) RRC/ UTRAN Mobility Information Confirm RANAP/ Relocation Detect MAP/ Process Access Signalling (HO detect) RANAP/ Relocation Complete MAP/ Send End Signal BSSMAP/ Clear command GSM resource release BSSMAP/ Clear complete 3 2
Follow up procedures after successful handover from GSM to UMTS: Security Update RRC measurement setup UE capability enquiry Mobility Update [USA Market - In case of Default Configuration: Radio Link- and Bearer Configuration to ALU standard]
Figure 23: 2G to 3G handover for CS dataflow (1) Handover preparation phase. When the handover decision is made, the serving BSC sends a handover required towards the 2G-MSC and containing the target RNC ID (this IE allows the source MSC to route the message to the correct 3G-MSC/RNC). The request is forwarded to the target 3G RNC which allocates resources to support the call. The request sent from the source BSC identifies only one cell in one RNC. There is no list of possible target.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 40/213
4.6.2 APPLICABILITY
Depends on BSC algorithm.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 41/213
4.6.3 ALGORITHM
RELOCATION REQUEST MESSAGE STRUCTURE
As the RELOCATION REQUEST message is specified in 2 different specifications (24.413 for the RANAP part, 25.331 for RRC specific IE), this paragraph presents a simplified view of the structure of the message: RELOCATION REQUEST (25.413 9.1.10) source RNC to target RNC transparent container (25.413 9.2.1.28) RRC information to target RNC (25.331 14.12.1) Handover to UTRAN Info (25.331 14.12.4.1) UE Radio Access capability (25.331 10.3.3.42) Security capability (25.331 10.3.3.37) Ciphering algorithm capability Integrity protection algorithm capability Pre-defined configuration status information (25.331 14.13.2.3) UE security information (25.331 14.13.2.2) START-CS Inter-RAT UE radio access capability (25.331 10.3.8.7) Mobile Station classmark 2 Mobile Station classmark 3 nb of Iu instances (=1) Relocation type (= UE involved) target cell Id cell load information group (1) RAB to be setup List Integrity protection information Encryption information Note (1): this element is optional and treated if feature uRRM step 2 is activated.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 42/213
CIPHERING
The necessary information is passed from the source BSS to the target RNC using the HANDOVER REQUIRED / RELOCATION REQUEST messages so that there is no break in the ciphering: Mobile supported ciphering algorithm are provided to the mobile in the RRC container START-CS (used to initialise the 20 MSBs of all hyper frame numbers: MAC-d HFN, RLC UM HFN, RLC AM HFN, RRC HFN) is provided in the RRC container CK (UMTS ciphering Key) is provided by the 3G-MSC in the RELOCATION REQUEST (Encryption information IE), resulting from the conversion of Kc (GSM ciphering key) by the 3G-MSC. Ciphering is started by the mobile immediately after receiving the HANDOVER TO UTRAN COMMAND message.
INTEGRITY
Integrity is started by the RNC immediately after receiving the HANDOVER TO UTRAN COMPLETE RRC message. The necessary information is passed from the source BSS to the target RNC using the HANDOVER REQUIRED / RELOCATION REQUEST messages so that there is no break in the ciphering: Mobile supported integrity algorithm are provided to the mobile in the RRC container START-CS (used to initialise the 20 MSBs of all hyper frame numbers: MAC-d HFN, RLC UM HFN, RLC AM HFN, RRC HFN) is provided in the RRC container IK (UMTS Integrity Key) is provided by the 3G-MSC in the Relocation Request (Integrity protection information IE), resulting from the conversion of Kc (GSM ciphering key) by the 3G-MSC.
UE
NodeB
RNC
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 43/213
After successful completion of the GSM to UMTS handover, indicated by receipt of the HANDOVER TO UTRAN COMPLETE message, the RNC reconfigures the radio bearer to the normal, optimized configuration. Within this reconfiguration the RLC parameters should be reconfigured, too. The RLC reconfiguration is part of feature 33598. As of the time of writing of this document it is not yet decided if the RLC reconfiguration will be available. If it is available then it advisable to enable it (parameter isRlcAMReconfigurationAllowed and isUER99RlcAmReconfigurationAllowed). If it is not available then either the use of default configurations should be disabled (parameter isGsmIratHoDefaultConfigurationUsed) or the call will have sub-optimal RLC parameter settings.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 44/213
Handover preparation phase (as in normal successful case) RANAP/ Relocation request Ack (Handover to UTRAN command) MAP/ Prepare Handover ack (Handover Request Ack) BSSMAP/ Handover command (Handover to UTRAN command) RR/ Intersystem to UTRAN Handover command (Handover to UTRAN command) The UE returns on the old channel RR/ Handover Failure BSSMAP/ Handover failure MAP/ Abort Cancellation of on-going HO procedure 1
RANAP/ Iu Release Command NBAP/ Radio Link Deletion Request NBAP/ Radio Link Deletion Response AAL2/ REL AAL2/ RLC RANAP/ Iu Release Complete 2
Figure 24: 2G to 3G handover for CS failure case (1) As the mobile returns to the old channel, a handover failure message is sent to the 2G_MSC, leading to a cancellation of the handover procedure on the MAP interface. (2) As a consequence, the target RNC receives an Iu release command message from its MSC, requesting all the resources which have been allocated during the handover preparation phase to be released.
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 45/213
UE
NodeB
RNC
3G-MSC/VLR
2G-MSC/VLR
BSS
BSSMAP/ Handover Required (Source RNC to target RNC transparent information) MAP/ Prepare Handover (Handover Request) RANAP/ Relocation request (Source RNC to target RNC transparent information) No resource in RNS RANAP/ Relocation failure (No resource available) MAP/ Prepare Handover ack (failure) BSSMAP/ Handover Required reject
4.6.5 PARAMETERS
The parameters are: Name is2GTo3GCSHandoverAllowedWithinRnc Object/Class
InterFreqMeasConf Class3
RadioAccessService Class3
Definition This parameter indicates whether the 2G To 3G CS Handover is allowed within the RNC YES: incoming relocation request from 2G are processed NO: incoming relocation request from 2G are rejected This parameter enables/disables the use of default configurations for inter RAT handover from GSM to UMTS.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 46/213
4.7.
In this case the mobile connected to the network in GPRS mode is moved from a 2G cell to a 3G-PS cell.
GGSN
2G-SGSN
3G-SGSN
RNC
NodeB 2
UE Before After
UE
Figure 26: 2G to 3G handover for PS In GPRS, the mobility decision is taken by the UE. The GPRS mobility is done via a Routing Area Update procedure. Once PDP context transferred from old to new SGSN, the 3G SGSN requests for a RAB establishment as for a call establishment. The next dataflow is an example of inter-SGSN 2G to 3G handover.
UE
BTS
Serving BSC
Target RNC
3G-SGSN
2G-SGSN
GMM/ RA update request GTP/ SGSN ctx request RANAP/ RAB assignment request RANAP/ RAB assignment response GTP/ SGSN ctx ack GTP/ SGSN ctx response
PDP context update with GGSN Update GPRS location with HLR
GMM/ RA update accept GMM/ RA update complete
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 47/213
4.8.
In this case the mobile connected to both CS and PS domains, and is moved from a 3G cell to a 2G cell. CS and PS parts are managed independently. The CS part is managed as described in 4.6 and the PS part as in 4.7.
4.9.
4.9.1 DESCRIPTION
In this case the mobile connected to the network in PS mode is moved from a 3G cell to a 2G-GPRS cell.
GGSN
3G-SGSN
2G-SGSN
BSC
BTS 2
UE Before After
UE
Figure 28: 3G to 2G handover for PS The next dataflow is an example of inter-SGSN 3G to 2G handover. In this version, the mobile is using dedicated resources for PS services in 3G network. Therefore, the handover decision is taken by the SRNC (as if it were a CS call). Meanwhile, as opposed to CS handover, the connection and resource allocation in the target system are performed on UE request.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 48/213
RRC/ Measurement Report RRC/ Cell change order from UTRAN (BSIC, BCCH ARFCN) 2G access and GPRS resource allocation GMM/ RA update request GTP/ SGSN ctx request RANAP/ SRNS ctx request RANAP/ SRNS ctx response 2 GTP/ SGSN ctx response GTP/ SGSN ctx ack GMM/ RA update response 1
RANAP/ Iu release command NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp 3
Figure 29: 3G to 2G handover for PS dataflow (1) Based on measurements, the serving RNC decides to hand the mobile over a 2G cell. Following the mobile access on the 2G cells, resources are allocated in the target BSS. The cell change order message contains the target cell BSIC and BCCH ARFCN which are used by the mobile to get the target synchronisation before accessing to the network. (2) The mobile updates its location in the target 2G system using the "RA update" procedure. The PDP contexts which were active in 3G and the N-PDU and GTP-PDU counters are transferred in 2G using GTP and RANAP context transfer procedures. In this version, N-PDU and GTP-PDU will not be transferred by the RNC on the RANAP protocol. (3) Although not supported by UTRAN in this version, data forwarding may be asked by the source SGSN. Even if no data is forwarded, the old SRNC shall not complete the resource release phase until TDATAfwd (data forwarding timer). In this version, TDATAfwd is equal to 0 sec.
4.9.2 APPLICABILITY
In this version, the mobile is using either dedicated or shared resources for PS services in 3G network. Since the quality of service offered to subscribers will be better in UMTS as compared to what GPRS can offer, the PS subscribers will be kept in 3G as much as possible, and will only be handed to 2G in case of UTRAN coverage holes, or when leaving a UTRAN coverage spot. The decision to launch this mobility procedure is taken by the iMCTA function (refer to section 4.20)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 49/213
4.9.3 ALGORITHM
HO DECISION PROCESS
Please refer to section 4.20.
MEASUREMENTS CONFIGURATION
Please refer to section 4.20.
UE
Serving NodeB
Serving RNC
Target BSC
2G-SGSN
3G-SGSN
RRC/ Cell change order from UTRAN (BSIC, BCCH ARFCN) The HO fails on the target system RRC/ Cell change order from UTRAN failure
Another handover will be tried as in the normal process, i.e. possibly next time the handover criteria is evaluated and using "target cell choice" algorithm as specified. No handover will be tried towards the 2nd best cell.
4.9.5 PARAMETERS
The parameters are: Name Object/Class
RadioAccessService Class3
activationHoGsmPsAllowed
Definition This parameter indicates if the PS handover toward a GSM cell is allowed.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 50/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 51/213
Anchor MSC
3G-MSC
2G-MSC
Relay MSC
BSC
BTS
UE Before After
UE
Figure 31: 3G to 2G handover for CS The next dataflow is an example of inter-MSC 3G to 2G CS handover.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 52/213
RRC/ Measurement Report RANAP/ Relocation Required (CM2, CM3, old BSS to new BSS information) MAP/ Prepare Handover (Handover Request) BSSMAP/ Handover Request (CM2, CM3, old BSS to new BSS information) BSS resource allocation BSSMAP/ Handover Request Ack (handover command) RANAP/ Relocation Command (handover command) MAP/ Prepare Handover Ack (Handover Request Ack) 1
RRC/ Handover from UTRAN Command (handover command (cell description)) RR/ Handover Access RR/ Physical Information (Timing Advance) RR/ Handover Complete 2
MAP/ Process Access Signalling (HO detect) BSSMAP/ Handover Detect BSSMAP/ Handover Complete MAP/ Send End Signal RANAP/ Iu release command NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp AAL2/ REL AAL2/ RLC RANAP/ Iu release complete 3
Figure 32: 3G to 2G handover for CS dataflow (1) Handover preparation phase. When the handover decision is made, the serving RNC activates the relocation procedure towards the 3G-MSC. The request is forwarded to the target 2G BSS which allocates resources to support the call. The RELOCATION REQUIRED message contains the UE GSM capability (ClassMark 2 and 3). The "old BSS to new BSS" information element contains the UE capability, which is transferred to the target BSS, in case the mobile is handed over 3G again. It also contains the cell load information group element if feature uRRM step 2 is activated. (2) Handover execution phase. The HANDOVER COMMAND message from the GSM RR layer is sent from the target 2G to the UE via the MSC nodes and the serving RNC. This message contains the target cell description (i.e. BSIC and BCCH ARFCN), which will allow the mobile to synchronize to the cell when the handover is made in blind mode. The handover is performed when the UE is successfully connected to the 2G system. (3) Old resource release phase. Old radio link(s) and associated AAL2 Cid(s) are released.
4.10.2 APPLICABILITY
In this version, 3G to 2G handover for CS calls which have reached the call established state is a rescue type of mobility, triggered on radio alarm criterion. CS subscribers may be handed to 2G in case of UTRAN coverage holes, or when leaving a UTRAN coverage spot. In addition to providing this alarm-based 3G-2G handover for established calls, the 3G infrastructure may also redirect calls in the following use cases:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 53/213
4.10.3 ALGORITHM
HO DECISION PROCESS
Please refer to section 4.20.
MEASUREMENTS CONFIGURATION
Please refer to section 4.20.
UE
Serving NodeB
Serving RNC
Target BSC
2G-MSC
3G-MSC
RRC/ Handover from UTRAN command (BSIC, BCCH ARFCN) The HO fails on the target system RRC/ handover from UTRAN failure
Another handover will be tried as in the normal process, i.e. possibly next time the handover criteria is evaluated and using "target cell choice" algorithm as specified. No handover will be tried towards the 2nd best cell.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 54/213
RRC/ Measurement Report RANAP/ Relocation Required (CM2, CM3, old BSS to new BSS information) MAP/ Prepare Handover (Handover Request) BSSMAP/ Handover request (CM2, CM3, old BSS to new BSS information) BSSMAP/ Handover Failure (cause) MAP/ Prepare Handover ack (Handover failure) RANAP/ Relocation preparation failure (cause)
Figure 34: 3G to 2G handover for CS - failure case [USA Market - If allowed by parameter isGsmIratHoToNextBestCellAllowed, if the UE had reported further eligible GSM target cells in a measurement report and if the criteria for handover are still fulfilled then the RNC retries relocation preparation for the next best GSM cell. The attempts are repeated until either The relocation preparation has failed for the last eligible GSM cell A follow-up measurement report contains both, eligible GSM and inter-frequency target cells. In this case the RNC tries the handover to the strongest inter-frequency target. The criteria for handover are no longer fulfilled, e.g. an event 2F indicates the end of the alarm condition.] Another handover will be tried as in the normal process, i.e. possibly next time the handover criteria are evaluated and using "target cell choice" algorithm as specified.
4.10.5 PARAMETERS
The parameters are: Name Object/Class
RadioAccessService Class3 RadioAccessService Class3 RadioAccessService Class3
Definition This parameter indicates if the CS handover toward a GSM cell is allowed. This parameter controls sending of cell load information IE in handover messages to 2G This parameter enables/disables the IRAT handover to the next best GSM cell if handover is not possible to the first cell, e.g. due to overload.
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 55/213
On the GSM Access side: Some impacts on the A interface (new UE Capability IE in the Handover Request) Only impact is a new counter on 3G to 2G (based on the source cell " Cell identification discriminator" contained by the Handover Request)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 56/213
GGSN
BSC
BTS
UE Before After
UE
Figure 35: 3G to 2G handover for CS+PS Several classes of mobile have been defined in the GPRS specifications: class C: the mobile is attached to either GPRS or GSM services. Alternate use only. This case is not further considered in this document. class B: the mobile is attached to both GPRS and GSM services, but the mobile can only operate one set of services at a time class A: the mobile is attached to both GPRS and GSM services, and can support simultaneous traffic DTM (Dual Transfer Mode): DTM is a subset of class A mode of operation. In this mode, GSM CS and PS resource allocation are coordinated in BSC/PCU in order to simplify mobile implementation. Class A or DTM The real successful case (i.e. PS and CS services are both active in the new cell) assumes that the mobile is either GPRS Class A or DTM (Dual Transfer Mode or simple Class A) capable the new cell can offer GPRS service Regarding the CS domain, the CS service is handed over the target GSM cell exactly as in the "3G to 2G handover for CS" case, i.e.: a relocation is required by the serving RNC new resources corresponding to the CS RAB are allocated in the target system and the mobile is explicitly handed over the target resources (this is performed through the "Handover from UTRAN" RRC procedure) Regarding the PS domain, the PS service is handed over the target GSM cell in the same way as the "3G to 2G handover for PS" case, i.e.: the mobile is requested by the SRNC to change cell (this is done implicitly through the "Handover from UTRAN" RRC procedure)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 57/213
Class B In this case, the CS service is handed over to GSM and the PS service cannot be maintained. Since the mobile will not detach nor deactivate the PDP context which were active in the source 3G-SGSN, the PDP context will remain active in the 3G-SGSN. Remark: In this version, the source RNC will not take into account the mobile GPRS capability in the handover decision algorithm.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 58/213
RANAP/ Relocation Required (CM2, CM3, old BSS to new BSS information) MAP/ Prepare Handover (Handover Request) BSSMAP/ Handover request (CM2, CM3, old BSS to new BSS information) BSS resource allocation BSSMAP/ Handover request Ack (handover command) RANAP/ Relocation command (handover command) MAP/ Prepare Handover ack (Handover Request) 1
RRC/ Handover from UTRAN command (handover command (cell description)) 2 RR/ Handover Access MAP/ Process Access Signal (HO detect) MAP/ Send End Signal BSSMAP/ Handover Detect BSSMAP/ Handover Complete
3G-SGSN
2G-SGSN
GTP/ SGSN ctx request RANAP/ SRNS ctx request RANAP/ SRNS ctx response 3 GTP/ SGSN ctx response GTP/ SGSN ctx ack GMM/ RA update response
3G-MSC/VLR RANAP/ Iu release command TRelocResourceRe leasePs3Gto2Gtim er (set to 20 sec) Resources Release NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp AAL2/ REL AAL2/ RLC
3G-SGSN
4+5
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 59/213
4+5
UE
3G MSC/VLR
3G SGSN
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 60/213
UE
3G MSC/VLR
3G SGSN
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 61/213
RANAP/ Relocation Required (CM2, CM3, old BSS to new BSS information) MAP/ Prepare Handover (Handover Request)
Iu release timer RRC/ Handover from UTRAN command (handover command (cell description))
3G-SGSN RANAP/ Iu release request RANAP/ Iu release request RANAP/ Iu release command RANAP/ Iu release command NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp AAL2/ REL AAL2/ RLC RANAP/ Iu release complete RANAP/ Iu release complete 3
Figure 37: 3G to 2G handover for CS+PS - failure case The following dataflow illustrates the 2nd case: Phase 1 and 2 (handover preparation and execution) are performed as in the successful case. Following successful CS handover the Core Network commands a release of the Iu. This release is not processed until the "Iu release timer" elapses. In which case, both Iu-CS and PS connections (and associated UTRAN resources) are released.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 62/213
RANAP/ Relocation Required (CM2, CM3, old BSS to new BSS information) MAP/ Prepare Handover (Handover Request)
NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp AAL2/ REL AAL2/ RLC RANAP/ Iu release complete RANAP/ Iu release complete
Figure 38: 3G to 2G handover for CS+PS - failure case HO failure case The possible failure cases are the following: The synchronisation on the new CS channel fails. In that case, the mobile returns on the old channel using the Handover from UTRAN failure message and the relocation is cancelled by the source RNC, as in the CS only case. The handover for the CS service is successfully performed, but the PS registration fails (reject from the new SGSN, or because GPRS is not supported by target cell ...). In this case, nothing specific is done. The CS service goes on, whereas the PS service has failed. From a source UTRAN point of view, this case is identical to the Class B mobile handover case. Due to the time needed to resynchronise the CS service, it is not expected the PS service can be resumed in the new cell before the CS service.
Handover/call setup race condition If a 3G to 2G handover decision is made while a PS call is active and a CS call is being setup, nothing is done until the CS RAB is established. Once the CS RAB is setup, and if the handover conditions are still valid, a 3G to 2G PS+CS handover is tried. If a 3G to 2G handover decision is made while a CS call is active and a PS call is being setup, nothing is done until the PS RAB is established. Once the PS RAB is setup, and if the handover conditions are still valid, a 3G to 2G PS+CS handover is tried.
4.11.2 APPLICABILITY
See 4.10.2 [3G To 2G Handover for CS Domain] section APPLICABILITY
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 63/213
4.11.3 ALGORITHM
HO DECISION PROCESS
Please refer to section 5.9.
MEASUREMENTS CONFIGURATION
Please refer to section 4.20.
4.11.4 PARAMETERS
Refer to: Section 4.20. Section 5.13. Note: In the CS+PS case a handover to a 2G cell is only performed if both activationHoGsmCsAllowed and activationHoGsmPsAllowed parameters are set to "YES"
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 64/213
MSC Iu SRNC
MSC
RNC Iub
NodeB 0
NodeB 1
NodeB 2
f1
UE
Figure 39: inter-frequency inter-RNC handover As described in the following flow diagram, inter-frequency inter-RNC hard handover makes use of the Relocation procedure (UE involved), as the UTRAN RRC connection anchor point is moved from one RNC to another. The global process is divided into two phases: The relocation preparation in which all the needed resources are allocated in the target RNC and NodeB The relocation execution in which the mobile is handed over the new resource Relocation preparation
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 65/213
Based on the inter-PLMN handover criteria, a request for relocation is issue by the serving RNC. When accepted, this request triggers resource allocation within the target RNC: A radio link is allocated in the target NodeB An AAL2 circuits are allocated on Iub and Iu interfaces
RANAP/ Relocation required (RB parameters, Number of Iu instances) SCCP/ Connection Request SCCP/ Connection Confirm RANAP/ Relocation request (RB parameters, Number of Iu instances, RAB parameters) On reception of Relocation Request, the target RNC allocates UTRAN resources corresponding to the requested RABs NBAP/ Radio Link setup req NBAP/ Radio Link setup resp AAL2/ ERQ AAL2/ ECF RANAP/ Relocation request ack ( Radio Bearer Reconfiguration)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 66/213
During the relocation execution phase, a new RNTI is allocated to the mobile, integrity (and possibly) ciphering are activated. This is all done through the Radio Bearer Reconfiguration RRC procedure. RANAP/ Relocation command (Radio Bearer Reconfiguration) RRC/ Radio Bearer reconfiguration (RB to reconfigure, Physical channel configuration)
RRC/ Radio Bearer reconfiguration complete RANAP/ Relocation detect RANAP/ Relocation complete Old measurement Ids are released, and new measurements are setup by the new SRNC. RRC/ Measurement Control (id1, Release) RRC/ Measurement Control (id2, Release) RRC/ Measurement Control (id1, Setup) RRC/ Measurement Control (id2, Setup) Once the mobile is successfully established on the target resource, the anchor MSC triggers a release of all UTRAN resources used under the old serving RNC RANAP/ Iu release command NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp AAL2/ REL AAL2/ RLC RANAP/ Iu release complete SCCP/ Released SCCP/ Release Complete
Figure 41: inter-frequency inter-RNC handover - relocation execution Remarks: From the RELOCATION REQUEST messages received, the Alcatel-Lucent target RNC tries to identify the Radio Bearer configuration which is the closest to the requested configuration. In case there is no matching configuration (i.e. there is no configuration in the target RNC that matches the number and type of radio bearer in the existing configuration managed by the serving RNC) then the relocation is failed and a RELOCATION FAILURE is sent back to the Core Network. Regarding measurement configuration, the Alcatel-Lucent target RNC deletes every measurement configured previously in the source RNC once relocation is successfully performed. All the needed measurements are then setup.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 67/213
4.12.2 APPLICABILITY
In this version, outgoing inter-frequency handover inter-RNC is triggered upon iMCTA decision (refer to section 4.20). The feature is applicable for calls on DCH, HS-DSCH or E-DCH, with check of global activation parameters isHsdpaHHOwithMeasAllowed and isEdchHHOwithMeasAllowed. This algorithm is applicable to PS, CS and CS+PS connections.
4.12.3 ALGORITHM
HO DECISION PROCESS
Please refer to section 4.20.
MEASUREMENTS CONFIGURATION
Please refer to section 4.20.
4.12.5 PARAMETERS
Name Object/Class
RadioAccessService Class3
is3Gto3GWithoutIurAllowedForPS
is3Gto3GWithoutIurAllowedForCS
RadioAccessService Class3
Definition YES: incoming or out-going interfrequency alarm handover is allowed for PS domain RAB NO: incoming or out-going interfrequency alarm handover is not allowed YES: incoming or out-going interfrequency alarm handover is allowed for CS domain RAB NO: incoming or out-going interfrequency alarm handover is not allowed
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 68/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 69/213
4.13.2 APPLICABILITY
The feature is applicable for calls on DCH, HS-DSCH or E-DCH, with check of global activation parameters isHsdpaHHOwithMeasAllowed and isEdchHHOwithMeasAllowed. It is applicable to all RABs combinations. It is applicable in full-event mode only. The application of this feature should be limited to the situations where there is no Iur between 2 RNCs and is not recommended as a general mobility mechanism.
4.13.3 ALGORITHM
IUR INTERFACE STATUS
The Iur interface can be unavailable for following reasons: The interface is not provisioned at system start up The Iur interface status is not operational as notified to the Fault manager and to the user applications. This status is checked only when receiving measurement reports and its change does not affect measurement configuration.
MEASUREMENT CONFIGURATION
In order to separate SHO from HHO conditions, a new intra-frequency measurement is introduced. It configures event1A with measId = 14 and contains all isolated cells (cells in the monitored set that are controlled by another RNC and have no Iur interface provisioned with the serving RNC). It is configured with specific parameters (refer to 4.13.4). CIO is used. If needed, it is configured at the same time as other events 1x with measId = 1.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 70/213
4.13.4 PARAMETERS
Name isIntraFreqInterRncHhoOnIurLinkDownAllo wed
isIntraFreqInterRncHHOAllowed
minimumCpichEcNoValueForHHO
Definition Indicates if the intra-frequency inter-RNC HHO is allowed if Iur Link is down indicates if the intra-frequency inter-RNC HHO feature is enabled or disabled CPICH Ec/No threshold for intrafrequency cell eligibility in HHO case
CPICH Rscp threshold for intrafrequency cell eligibility in HHO case Amount of periodical reporting when triggered by intraFreqinterRnc Event in Full Event Mode
minimumCpichRscpValueForHHO
amountRep
repInterval
Interval between 2 similar reports for amount reporting mgmt of intraFreq-interRnc Event in Full Event Mode
maxNbReportedCells
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 71/213
timeToTrigger
hysteresis
cpichEcNoReportingRange
Period during which the condition of the intraFreq-interRnc Event must be satisfied before sending a measurement report in Full Event Mode Hysteresis to configure for the triggering condition of intraFreqinterRnc Event in Full Event Mode. It is related to the conditions for the change of Primary Radio Link For UA06 refer to section 6.3. Reporting Range to configure for the triggering condition of the intraFreq-interRnc Event in Full Event Mode
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 72/213
RNC
f1 f2
In this case, the RNC control cells from different frequencies (f1 and f2); f1 and f2 cells may be either 2 sectors of the same NodeB, or belong to different NodeB. The 2 frequency layers overlap and the subscribers may camp on either of the 2 layers depending on cell selection and re-selection rules and parameters. Once connected, the subscribers remain on same frequency. However, as UE are moving out of the smallest frequency spot (f1 as in the picture above), an alarm hard handover towards the other frequency is triggered by the SRNC. Similarly, an inter-frequency intra-RNC hard handover may also be performed from f2 to f1 in case of lack of f2 coverage, e.g. as in an outdoor to indoor mobility case.
UE
NodeB 1 RRC/ Measurement Report NBAP/ Radio Link Setup req NBAP/ Radio Link Setup resp
Serving RNC
1 FP/ DL Sync (CFN) FP/ UL Sync (ToA) RRC/ Radio Bearer Reconfiguration RRC/ Radio Bearer Reconfiguration complete NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp 2 NodeB 0 NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 73/213
SRNC
DRNC
f1 f2
UE
Drift RNC
Serving RNC
RNSAP/ Radio Link Addition req NBAP/ Radio Link setup req NBAP/ Radio Link setup resp RNSAP/ Radio Link Addition resp (Binding Id)
AlCAP Iur Transport Bearer Setup 1 AlCAP Iub Transport Bearer Setup
FP/ DL Sync (CFN) FP/ DL Sync (CFN) FP/ UL Sync (ToA) FP/ UL Sync (ToA) RRC/ Radio Bearer Reconfiguration RRC/ Radio Bearer Reconfiguration Complete 2
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 74/213
NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp
Figure 45: Hard Handover inter-frequency intra-RNC dataflow over the Iur
In step (1) a new radio link is set up over Iur on the new target Drift NodeB, using another frequency. In step (2) the Radio Bearer is reconfigured. In step (3) the old radio links (there may be more than one, depending on the current active set) are deleted. The radio link belonging to the previous primary cell is to be deleted over Iur as depicted in figure above. In the figure above, Drift NodeB 0 and Drift NodeB 1 may be the same network node.
4.14.2 APPLICABILITY
In this version, inter-frequency hard handover intra-RNC is triggered upon iMCTA decision (refer to section 4.20).
This algorithm is applicable to PS, CS and CS+PS connections. The RNSAP RL Addition procedure does not permit to reconfigure the DCH part of the call. This procedure is used in case we establish a radio link on a drift RNC (over Iur) while we have already one or more radio-links established on this D-RNC. The following restriction applies: If the handover implies the transition HSxPA->DCH for layer capabilities or target resource shortage reasons, the handover is not processed by the S-RNC. [USA Market - Intra DRNC handover is performed from DCH to DCH. HSxPA calls need to be reconfigured to DCH before the handover.]
4.14.3 ALGORITHM
HO DECISION PROCESS
Please refer to section 4.20.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 75/213
MEASUREMENTS CONFIGURATION
Please refer to section 4.20.
4.14.5 PARAMETERS
[USA Market - Intra DRNC handover will be enabled/disabled by the parameter defined in section 4.15.5.] There is no new parameter associated to the intra-RNC case exclusively. The Radio criteria algorithm for inter-frequency intra-RNC handover uses the same parameters with the same values as in the inter-RNC case.
HHO.AttOutInterFreq / HHO.AttOutInterFreq.NeighbRnc Total number of attempted outgoing inter-frequency hard handovers HHO.AttOutInterFreq.RSCP / HHO.AttOutInterFreq.RSCP.NeighbRnc Attempted outgoing inter-frequency hard handovers due to insufficient RSCP quality of the used frequency HHO.AttOutInterFreq.EcNo / HHO.AttOutInterFreq.EcNo.NeighbRnc Attempted outgoing inter-frequency hard handovers due to insufficient Ec/No quality of the used frequency HHO.SuccOutInterFreq / HHO.SuccOutInterFreq.NeighbRnc Total number of successful outgoing inter-frequency hard handovers HHO.SuccOutInterFreq.RSCP / HHO.SuccOutInterFreq.RSCP.NeighbRnc Successful outgoing inter-frequency hard handovers due to insufficient RSCP quality of the used frequency
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 76/213
The counters are of cumulative type. They are defined as two sets one set on per FDDCell basis (the Primary RL of the UE is on this FDDCell) and one set on per neighboring RNC basis (the Primary RL of the UE is on this Neighboring RNC): In context of intra RNC handover the counters on per FDDCell basis will be pegged if the handover is performed within the SRNC the counters on per neighboring RNC basis will be pegged if the handover is performed within a neighboring RNC in DRNC role.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 77/213
4.15.1 DESCRIPTION
GENERAL
The purpose of this mobility case is to allow user mobility between cells of different frequencies (f1and f2) being controlled by different RNCs connected to an Iur. Depending on the allocation of the source cell on f1 (primary cell of the current active set) and the target cell on f2 the inter-frequency inter RNC hard handover is to be performed
from SRNC to DRNC [USA Market] from DRNC to DRNC [USA Market] from DRNC to SRNC
as detailed below.
SRNC
DRNC f1 f2
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 78/213
RNSAP/ Radio Link Setup req NBAP/ Radio Link setup req NBAP/ Radio Link setup resp RNSAP/ Radio Link Setup resp (Binding Id)
AlCAP Iur Transport Bearer Setup 1 AlCAP Iub Transport Bearer Setup
FP/ DL Sync (CFN) FP/ DL Sync (CFN) FP/ UL Sync (ToA) FP/ UL Sync (ToA) RRC/ Radio Bearer Reconfiguration RRC/ Radio Bearer Reconfiguration Complete 2
UE
NodeB0
Serving RNC
NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp 3 AlCAP Iub Transport Bearer Release
Figure 47: Hard Handover inter-frequency inter-RNC data flow from SRNC to DRNC
In step (1) a new radio link is set up over Iur on the new target Drift NodeB, using another frequency. In step (2) the Radio Bearer is reconfigured. In step (3) the old radio links (there may be more than one, depending on the current active set) are deleted. The radio link belonging to the previous primary cell is to be deleted directly over Iub without Iur being involved as depicted in figure above.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 79/213
SRNC DRNC
DRNC f1 f2
UE
Drift RNC
Serving RNC
RNSAP/ Radio Link Setup req NBAP/ Radio Link setup req NBAP/ Radio Link setup resp RNSAP/ Radio Link Setup resp (Binding Id)
AlCAP Iur Transport Bearer Setup 1 AlCAP Iub Transport Bearer Setup
FP/ DL Sync (CFN) FP/ DL Sync (CFN) FP/ UL Sync (ToA) FP/ UL Sync (ToA) RRC/ Radio Bearer Reconfiguration RRC/ Radio Bearer Reconfiguration Complete 2
UE
Drift NodeB0
Drift RNC
Serving RNC
NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp
Figure 49: Hard Handover inter-frequency inter-RNC data flow from DRNC to DRNC
In step (1) a new radio link is set up over Iur on the new target Drift NodeB, using another frequency.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 80/213
SRNC
DRNC f1 f2
UE
NodeB 1 RRC/ Measurement Report NBAP/ Radio Link Setup req NBAP/ Radio Link Setup resp
Serving RNC
FP/ DL Sync (CFN) FP/ UL Sync (ToA) RRC/ Radio Bearer Reconfiguration RRC/ Radio Bearer Reconfiguration complete 2
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 81/213
NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp
Figure 51: Hard Handover inter-frequency inter-RNC data flow from DRNC to SRNC
In step (1) a new radio link is set up on the new target NodeB, using another frequency. This radio link is to be setup directly over Iub without Iur being involved. In step (2) the Radio Bearer is reconfigured. In step (3) the old radio links (there may be more than one, depending on the current active set) are deleted. The radio link belonging to the previous primary cell is to be deleted over Iur as depicted in figure above.
4.15.2 APPLICABILITY
In this version, inter-frequency hard handover inter-RNC is triggered upon iMCTA decision (refer to section 4.20). This algorithm is applicable to PS, CS and CS+PS connections. [USA Market - The RNSAP RL Setup procedure is used in case a radio link is established on a DRNC (over Iur) while there is no other radio link established yet on this DRNC for this context (in contrast to intra DRNC handover where RNSAP RL Addition is used, see section 4.14.2). The handover over Iur is only done for DCH. If the call is HSxPA then it will be reconfigured to DCH /DCH before the handover.]
4.15.3 ALGORITHM
HO DECISION PROCESS
Please refer to section 4.20.
MEASUREMENTS CONFIGURATION
Please refer to section 4.20.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 82/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 83/213
4.16.1 DESCRIPTION
DEPLOYMENT SCENARIOS
Two deployment scenarios are foreseen for the introduction of HSDPA/HSUPA on existing networks: HSPDA/HSUPA on a dedicated layer or on an existing layer. Note: to deploy HSUPA in a cell, it is necessary that HSDPA is also configured in this cell. This is because any radio-bearer mapped on E-DCH in uplink will necessary be mapped on HS-DSCH in downlink. However, HSDPA may be deployed in a cell without deploying HSUPA.
It is even possible to have a three-layer deployment scenario: o one reserved for R99 o one with HSDPA, used for HSDPA but with or without HSUPA o one with HSDPA and HSUPA and used for HSDPA+HUSPA The advantage of this scenario is that there is no impact on the layer that is already deployed. Traffic segmentation can be ensured by two means: o either at RAB assignment (iMCTA feature), based on the HSDPA/HSUPA capability of the mobile and on traffic class of the RAB, or on other iMCTA trigger o or at RRC connection establishment (Traffic Segmentation feature: see [R4]), based on the release of the mobile (<R5 or >=R5) and possibly on the traffic class indicated in the establishment cause.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 84/213
Mobility between the two layers when the mobile is in an HSDPA and/or HSUPA call is handled as any other R99 call (see [Inter-frequency mobility] paragraph in this section).
If HSDPA (resp. HSUPA) is not deployed everywhere in the layer then an automatic channel type switching between DCH and HS-DSCH (resp. E-DCH) is performed when the UE enters in or leaves an HSDPA (resp. HSUPA) cell (more information are provided in [MOBILITY OF HS-DSCH] paragraph in this section). Full details are available in [R4] and [R6]. .
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 85/213
INTRA-FREQUENCY MOBILITY
Mobility of associated DCH
Soft and softer handover are handled normally on the associated DCHs and the Active Set evaluation and primary cell selection are managed as described by sections 5.3 and 5.4.
Mobility of HS-DSCH
As specified by the 3GPP standards, HS-DSCH(s) is (are) established in only one cell so is never in soft handover. In Alcatel-Lucent implementation, HS-DSCH(s) is (are) established on the primary cell (good radio conditions and not changing too often). Each time the primary cell changes, the HS-DSCH RL is deleted on the former primary and re-established under the new primary, using a synchronous reconfiguration. If the new primary cell does not support HSDPA then the RB is reconfigured to DCH. Moreover anytime an HSDPA-capable mobile (currently operating in DCH mode) enters an HSDPA primary cell it is reconfigured to HSDPA (for radio bearers that can be served on HSDPA).
Mobility of E-DCH
As specified by the 3GPP standards, there is only one serving E-DCH radio-link and it is established in the same cell that the HS-DSCH radio-link. The mobility of the E-DCH serving link is based on the same principals than the HS-DSCH one. In case of primary cell change, the E-DCH serving link and the HS-DSCH link are moved at the same time (one procedure). If the new primary cell does not support HSUPA then the RB is reconfigured to DCH in UL (it is maintained on HS-DSCH in DL if the cell supports HSDPA). On the opposite, it is reconfigured to E-DCH if the mobile comes back to HSUPA coverage. From UA06.0 release, macro-diversity of E-DCH (having non-serving E-DCH radio-links) is supported by Alcatel-Lucent (refer to 5.3.7).
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 86/213
COMPRESSED MODE
Compressed Mode will be activated in Uplink and Downlink to perform inter-frequency and inter-RAT measurements if needed by the UE. For an HSDPA call, the Mac-hs scheduler will not schedule a UE if a gap falls into the timeslot because the UE would not be able to receive and decode the data. It will also not be scheduled if the answer (Ack/Nack) falls during a gap for the same reasons. For an HSUPA call, the Mac-e scheduler will also take into account compressed mode gaps.
INTER-FREQUENCY MOBILITY
Inter-frequency handover is supported for HSDPA calls and HSUPA calls as for any R99 call. And this may trigger either an intra-RNC handover (with or without Iur) or an inter-RNC handover (over Iur [USA Market] or with relocation procedure). The handover protocol to be performed and possible HSxPA to DCH and DCH to HSxPA reconfigurations depend on the allocation of the target cell. In case of the target cell being controlled by the SRNC, i.e. intra-RNC handover within the SRNC or inter RNC handover towards the SRNC, the PS RB will be kept (or established) on HS-DSCH (resp. E-DCH) if the target cell supports HSDPA (resp. E-DCH). If it is not the case, there are reconfigured (or kept) to DCH in downlink (resp. uplink) In case of the target cell being controlled by a DRNC, i.e. intra-RNC handover within a DRNC or inter-RNC handover towards a DRNC the inter-frequency handover may be performed over Iur [USA Market] or with relocation procedure depending on either or both features being enabled as depicted in figure below. [USA Market - Inter-frequency handover over Iur will be done with preference if enabled towards the DRNC to control the target cell. If performed over Iur then only DCH to DCH handover is supported and HSxPA calls need to be reconfigured to DCH before the handover. Reconfiguration back to HSxPA will be done on the new frequency after successful handover or on the old frequency after unsuccessful handover as described for intra frequency mobility above.]
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 87/213
IFHHO
Yes SRNC
No HSxPA Target cell on SRNC and HSxPA ? No (on DRNC or does not support HSxPA) HSxPA to DCH Reconfiguration
Yes DCH
successful ?
No HSxPA
successful ? Yes
No old freq. IFHHO with SRNS Relocation (HSxPA or DCH) Yes Target cell on DRNC and Reloc.enabled ? No
Yes
successful ?
No
In case of inter frequency handover over Iur being disabled or being unsuccessful with return to old frequency [USA Market], this triggers a relocation. If the target cell supports HSDPA (resp. HSUPA) and the source RNC has indicated that the UE supports HSDPA in the Rel5 extensions (resp. HSUPA in Rel6 extensions) of the UE capabilities put in the container then the PS I/B radio-bearers are mapped directly on HS-DSCH in downlink (resp. E-DCH in uplink). If no information about the HSDPA (resp. HSUPA) capabilities of the mobile has been provided by the source RNC then the PS radio-bearers are first mapped on DCH in downlink (resp. DCH in uplink). If the HSDPA or HSUPA capability is lacking then a UE capability enquiry is triggered. If it happens that the UE is HSDPA (resp. HSUPA) capable then the PB radio-bearers are reconfigured to HS-DSCH in downlink if the primary cell is HSDPA (resp. E-DCH in uplink if the primary cell is HSUPA).
INTER-SYSTEM MOBILITY
3G to 2G handover
3G to 2G handover is supported for HSDPA/HSUPA calls. The handover is triggered on the same conditions as for non-HSDPA calls (see section 4.20).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 88/213
4.16.2 APPLICABILITY
See [R4]. See [R6].
4.16.3 ALGORITHM
See [R4]. See [R6].
4.16.4 PARAMETERS
See [R4]. See [R6]. Mobility parameters can be tuned by mobility service type.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 89/213
4.17.2 APPLICABILITY
See [R8].
4.17.3 ALGORITHM
See [R8].
4.17.4 PARAMETERS
See [R8].
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 90/213
4.18. 3G2G REDIRECTION AT RRC ESTABLISHMENT FOR SPEECH CALLS 4.18.1 DESCRIPTION
The Redirection during the Rab Assignment processing is covered by the iMCTA function (refer also to 4.20). There are 2 general points in the speech call setup request where the call could fail as a result of UTRAN related resource contention: o RACH Access: The RACH channel has a fixed (shared) bandwidth, and contention will occur if the number of UEs attempting to access the 3G network exceeds a given threshold. Under extreme conditions the amount of UL interference generated by the UEs may significantly reduce the number of UEs which are able to access the UTRAN. Users may experience delays in accessing the network due to collisions on the RACH channel. The UE will re-attempt the call setup (multiple times with increasing power each time), but if the RACH access failure persists, the call will fail. Call failures associated with RACH access are outside of the scope of this feature capability. o SRB Assignment: The SRB is established as a result of the first Access Stratum (AS) message being received by the RNC, and is used to allow the UE and CN to exchange subsequent Non Access Stratum (NAS) messages to allow the call to progress. RRC Redirection is triggered by failures at this point in the call progression.
4.18.2 APPLICABILITY
The redirection applies to calls with RRC Establishment cause equal to MO Conversational or Emergency. o The RNC is unaware of the UE capabilities at RRC Connection Request time. Therefore, the RNC will attempt an RRC Redirection irrespective of whether the UE supports the Redirection IE in the RRC reject message, or whether the UE supports GSM. The resultant behaviour is not defined in the standards; however, the end result is that the ability to redirect the call to 2G may not function in these cases. o RRC Redirection does not apply to any mobile terminated call scenario. This is due to the fact that the anchor 3G-MSC has already been established prior to the RRC Connection Request, and is not able to be modified. The call would fail at the CN if a RRC Redirection is attempted. Therefore, RRC Redirection is not triggered for this scenario. o RRC Redirection will not be triggered by the RNC if the UE already has an established RRC connection. This could be the case in the following scenarios: o A PS call is established prior to invocation of the speech call attempt, and is in either the active state or AO Step 1 state. o The UE did not release the RRC connection after the initial Location Update. This could possibly be the case where the call is invoked very early after the UE is powered up. The UE may choose to set the follow-on request indicator during the Location Update Request, if it has a subsequent request pending. There may be other cases where the UE will request the network to keep the RRC Connection established. o RRC will redirect all MO Conversational calls to 2G upon admission failure (irrespective of service type and domain). This includes: o Non-speech calls such as Video telephony, which will arrive, and fail, on the 2G network. However, these calls have already failed to establish on the 3G network. GSM may either simply fail the call or attempt to redirect the Video telephony back to 3G. o Conversational calls on the PS domain. This is not currently the case, but they may be present in the future. This is merely a consequence of the fact that the RRC establishment cause is not able to uniquely identify a CS speech at this early stage of the call progression. If the neighbouring 2G cells (measurement based or blind) are not provisioned at the OMC-R, RRC Redirection will not be triggered in the RNC, even if RRC Redirection is enabled for that cell. However,
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 91/213
4.18.3 ALGORITHM
The flow for RRC Redirection is shown in Figure 52.
UE
Node B
RNC
The RRC Connection Request message initiated by the UE RRC/RACH (RRC connection Request (cause: MO Conv or Emergency)) contains the establishment cause.
2
If admission fails, and the UTRAN is enabled to redirect speech calls to 2G, a RRC Connection Reject is sent to the UE with redirection info included. RRC/ FACH (RRC Connection Reject (Wait Time, Redirection info: GSM))
Step 1: The UE requests the initial signalling as a normal conversational call setup request. While in this example the setup relates to a speech call setup, the same RRC cause value would be used for a Video Telephony call setup request. There is also a separate cause value for an emergency call request, which could also trigger RRC Redirection. This step is preceded by the location registration (not shown here). Step 2: The RNC will execute normal (i.e. existing) RRC Connection Admission mechanism, which consist of the following functions: Cell CAC: The UL interference (conveyed in the RSSI) is checked to ensure it does not exceed a provisioned UL interference level threshold; RNC Overload: The RRC connection request may be denied based on the current RNC Overload level CAC; Maximum UE Contexts: The RNC checks that the maximum number of concurrent UE contexts will not be exceeded. SRB CAC: The RNC will check that the resources required to support the SRB are available. The required resources are dependant on whether the setup is via Cell_FACH or Cell_DCH, and is as follows: o Cell_DCH: Radio Resources (OVSF codes, DL Power) NodeB CEM AAL2 CAC: In this case there are several existing possible exhaust scenarios, such as Iub bandwidth exhaust (or Iur in the case of a DRNC scenario), CID exhaust, PID failure, and PathGroup failure. However, the most likely failure scenario is Iub bandwidth exhaust, due to the throughput constraint of this physical connection. This is a calculated capacity, based on the sum total of all RBs currently assigned to that resource (partitioned into DS and NDS traffic, as of UA04.1). Internal RNC U-Plane resources (e.g. PSFP) o Cell_FACH: Number of contexts on the FACH channel Internal RNC U-Plane resources (e.g. PSFP)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 92/213
4.18.4 PARAMETERS
Name is3Gto2gConversationalCallRedirectOnRrcEstabFailAllowed Object/Class
RadioAccessService Class3
blindHoGsmNeighbourTargetCgi timeReject
WaitTime3GTo2GRedirectFailure
FDDCell Class 3
Definition This parameter enables the RRC Speech Redirection feature link to a GSMCell instance Wait time used when the redirection is due to RNC overload Wait time used when the redirection concerns an emergency call
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 93/213
RRC Redirection On receipt of RRC Connection Request message from the mobile station with cause emergency, if the feature is activated and a 2G neighbouring cell is provisioned on the current cell, then the UTRAN responds with an RRC Connection Reject message containing the Redirection info IE with Inter RAT info set to GSM.
The mobile station performs inter-system cell reselection and re-originates the emergency call on the 2G network. Existing GSM emergency call procedures and positioning technology are then used to provide location information. Activation of emergency call redirect is configurable on a per cell/sector basis. Refer to 4.18 for redirection procedure. Refer to [R1] and [R13] for more details on specific emergency redirection.
[USA Market - Immediate Inter-RAT Handover Radio access bearer resources are assigned in UMTS to allow for fast call establishment. Depending on parameter immediateHOofEmergencyCalls after successful call establishment the emergency call is handed over to GSM as soon as possible taking into account the cell configuration and UE capabilities. The UE performs GSM measurements and if a suitable GSM target cell is found within time interSystemHOe911Timer then the handover is initiated. Location reporting requests from the MSC are queued during this time and discarded in case of successful handover. The core network will then repeat the location reporting request to the GSM network. In case no suitable GSM target cell is found or in case of handover failure the emergency call is continued in UMTS and the location reporting request is processed.]
[USA Market - Special handling may apply also to priority calls. An example is the Wireless Priority Service (WPS) in the US, which defines redirection to the GSM system of WPS calls which originate from a UMTS subscriber, or NS/EP calls which terminate to a UMTS subscriber, if radio resource congestion occurs on the UTRAN. On RAB Assignment the MSC indicates that the call is a priority call. If UTRAN is congested, then the UTRAN initiates directed retry to GSM (see section 4.20 for a description of the CAC based handover algorithm). The directed retry for WPS calls can be enabled on RNC basis.] [USA Market - In case of inter-RAT handover attempts for emergency or priority calls the RNC does not retry handover to the next best cell in case of relocation preparation failure see section 4.10.4.]
4.19.1 PARAMETERS
Name immediateHOofEmergencyC alls [USA Market] Object/Class FDDCell / NeighbouringRNC Class 3 Definition Indicates whether emergency calls should be handed over to GSM using immediate InterSystem Handover after RAB establishment or kept in UMTS. Following options are available: - disabled - inter system handover for all emergency calls - inter system handover for emergency calls of non-GPS UEs The RNC level parameter RadioAccessService::isImmediateHOofEmerge ncyCallsAllowed must be enabled for
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 94/213
RadioAccessService Class 3
RadioAccessService Class 3
isImmediateHOofEmergency CallsAllowed [USA Market] isWpsDirectedRetryAllowed [USA Market] wpsTRelocPrep [USA Market]
RadioAccessService Class 3
RAB.AttEstabCSV.EC This PM counts the number of RAB Assignment Requests for Emergency Calls. This PM is only applicable for Emergency Calls. RAB.SuccEstabCSV.EC This PM counts the number of Successful RAB Establishments for Emergency Calls. This PM is only applicable for Emergency Calls. VS.IRATHO.ECIHO.AttHO This PM counts the number of Emergency calls for that an Immediate Inter-System Handover is attempted. Only applicable for the context of "Emergency Call Immediate Inter-System Handover". VS.IRATHO.ECIHO.AttRelocPrep The number of attempted relocation preparations for Emergency Call Immediate Inter-System Handover (ECIHO). Only applicable for the context of "Emergency Call Immediate Inter-System Handover".
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 95/213
RAB.AttEstabCSV.WPS RAB Assignment Requests for Wireless Priority Service (WPS) calls. Number of RAB Assignment Requests for Wireless Priority Service (WPS) calls. This measurement is pegged only if WPS handling is enabled in the RNC. Applicable in the context of WPS calls, only. VS.3g2gOutHoFailure Number of failed outgoing CS IRAT Handovers from 3G to 2G VS.IRATHO.WPS.AttDirectedRetry Attempted CAC failure initiated Directed Retries of Wireless Priority Service (WPS) calls. Number of attempted CAC failure initiated Directed Retries of Wireless Priority Service (WPS) calls. Applicable in the context of Directed Retry for WPS calls, only. VS.IRATHO.AttRelocPrepOutCS.WPS Attempted CS IRAT relocation preparations of CAC failure initiated Directed Retries of Wireless Priority Service (WPS) calls. Applicable in the context of Directed Retry for WPS calls, only. VS.IRATHO.WPS.AttHO Attempted CS IRAT handovers of CAC failure initiated Directed Retries of Wireless Priority Service (WPS) calls. Description: Applicable in the context of Directed Retry for WPS calls, only. VS.IRATHO.WPS.SuccDirectedRetry Successful CAC failure initiated CS IRAT Directed Retries of Wireless Priority Service (WPS) calls. Applicable in the context of Directed Retry for WPS calls, only. VS.IRATHO.WPS.CancelHO Cancelled WPS CS IRAT Directed Retry attempts. The number of WPS calls for that the Directed Retry is cancelled by normal call release after the RAB Assignment was received and before the Directed Retry is initiated by a relocation preparation procedure. Applicable for the context of WPS call Directed Retry, only. VS.IRATHO.WPS.CancelRelocPrep Cancelled WPS CS IRAT Directed Retry Relocation Preparations. The number of WPS calls for that the Directed Retry is cancelled by normal call release during ongoing relocation preparation procedure. Applicable for the context of WPS call Directed Retry, only.
The counters are of cumulative type. They are defined as two sets, one set on per FDDCell basis (the Primary RL of the UE is on this FDDCell) and one set on per neighboring RNC basis (the Primary RL of the UE is on this Neighboring RNC).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 96/213
2G
R99
R5
FDD2 HSDPA/HSUPA
R5
R5
R5
R5 FDD1 HSDPA/HSUPA
4.20.1 DESCRIPTION
IMCTA function allocates traffic across available carriers. For a given call, the carrier is selected by the RNC according to the Operator strategy through iMCTA configuration parameters (including Priority
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 97/213
iMCTA triggers
The main reasons to invoke the iMCTA function are: Alarm condition is hit; A CAC reason: a CAC failure occurs during the processing of a Rab Assignment sent by the CN. A fallback to another Carrier may be done; A user service reason: A successful Rab establishment/modification/release, a Always On upsize or an IU Release Command is done but the mobile may be moved to a better Carrier; A mobility service reason: A successful Intra Freq mobility is done but mobile may be moved to a better Carrier. The User and mobility Service triggers dont apply if the primary cell is managed through Iur. The Alarm and CAC triggers apply even if the primary cell is managed through Iur.
iMCTA trigger : Alarm HO reason The Alarm criterion for Inter Frequency and the Inter Rat Handover is described in section 5.9.
iMCTA trigger : User Service CAC reason A CAC failure triggers iMCTA function if the failure occurs during the processing of a Rab Assignment message coming from the CN. The purpose is to find another Carrier (which may have a different PLMN) on which a target cell is eligible to support the call (established in signalling or traffic). The list of CAC failure causes which may induce iMCTA triggering is: From Cell: no radio resource available From NodeB: Radio Link Reconfiguration Failure From IUB, IUR, IU: Transport Resource allocation failure From RNC Uplane : Resource allocation failure From C-RNC: User Plane Dedicated Bearer allocation failure.
When a CAC failure occurs during a Rab Assignment towards HSxPA, a HSxPA to DCH fallback may be attempted. If the fallback faces up a CAC failure or may not apply, iMCTA may be called. iMCTA doesnt apply to IRM table reject cases.
iMCTA trigger : User Service reason The triggers which invoke the iMCTA function are: Rab Assignment sent by the CN which induces the establishment of a Traffic Rab, a Rab release or a modification of the established Traffic type. The iMCTA is invoked if the final state of the call is: one or several Traffic Rab are established; Incoming Relocation with one or several Traffic Rab; After a mobile performs a successful Always On upsize from Cell_FACH or URA/Cell_PCH to Cell_DCH; Iu Release Command due to a Core network or a RNC (after sending an IU Release Request) decision when applying to a Multi Service call.
The triggers are valid if the originating cell is eligible regarding its load. This trigger belongs to Service triggers. When the purpose of the iMCTA is to redirect the call according to the Service and mobiles capabilities the load condition of the originating cell, i.e. using origin cell load colour threshold different from green, has not to be used if we want no limitation of the redirection application. iMCTA applies in case of Rab Assignment procedure inducing a successful fallback on DCH when no HSDSCH resource is available.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 98/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 99/213
4.20.2 APPLICABILITY
The iMCTA function only applies to calls in Cell DCH, E-DCH and HS-DSCH connected mode. Calls in Cell Fach (signaling or traffic), Cell PCH or URA PCH connected mode are not managed. iMCTA works with up to six UMTS carriers1, plus a 2G layer (whatever the frequencies). The function may be activated according to four modes: Alarm only: Alarm trigger applies Alarm and CAC: Alarm and User CAC Service triggers apply Alarm and Service: Alarm and Service triggers apply All: All iMCTA triggers apply
Iur management
The Service trigger doesnt apply if the primary cell is managed through Iur. The Alarm and CAC triggers apply even if the primary cell is managed through Iur. As per 3GPP [A7] UEs are required to support the own carrier and two additional FDD carriers. Thus, within a region no more than 3 UMTS carriers should be used.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
1
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 100/213
4.20.3 ALGORITHM
MAIN FUNCTIONAL STEPS
If one of the triggers is valid for the primary cell, the function may process the following functional steps to identify a target cell on another Carrier: 1. Checking of the iMCTA feature activation parameters ; 2. Identification of the Service Type and RAB to be set; 3. Selection of the iMCTA Carrier priority table; 4. Selection of the candidate Carriers; 5. Selection of the candidate Cells for UE measurements; 6. Configuration of the Compressed mode and of the UE measurements; 7. Cell selection upon Measurement Report; 8. iMCTA HHO processing or iMCTA exit . If no target cell is found after iMCTA algorithm processing or no measurement received or the HHO failed, the RNC has to wait the next iMCTA trigger iteration for a new call redirection attempt. For an alarm HHO trigger, when no Inter Freq/Inter Rat measurement can be requested to the mobile (compressed mode not allowed for the Service), no eligible target cell is found in the reported measurements, a iMCTA blind HHO may be attempt to the 2G twin cell (if configured).
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 101/213
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 102/213
4.
5.
The following steps are processed to select a cell among the measured 2G neighbour cells: 1. The cells which fulfill the Radio criteria are selected, i.e. their Rxlev verify 2G HHO condition; 2. Then the neighbour cells not fulfilling the 2G cell color load criteria are filtered (see [iMCTA cell load criteria] section); 3. Then if several 2G cells are eligible, the cell with the highest radio level is selected (Ec/No). [USA Market - If FDD and 2G neighbour cells are eligible then the FDD target is selected.] [USA Market - If 2G is selected as target and the relocation preparation to the selected target cell fails, e.g. due to load conditions in the GSM cell, then the RNC may re-evaluate the measurement report for the next best 2G neighbour cell and - if found any - re-attempt handover to this 2G cell. This re-attempt can be controlled with parameter isGsmIratHoToNextBestCellAllowed.]
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 103/213
IMCTA EXIT
The exit may occur if: No target neighbour cell was found before the guard timer elapses (in some use case the timer was re-armed) and no blind HHO 3G/2G may be processed; The mobile is no more in connected mode (cell DCH, E-DCH and HS-DSCH). The transition depends on the iMCTA trigger type. If Inter Frequency/Inter Rat measurements were requested to the mobile, they are released. According to the trigger, the actions are: Service and Alarm trigger: the waiting procedures may be processed; CAC trigger : After CAC failure during a Rab Assignment/ Release/ Modification, the following actions are processed: If resources were partially allocated for the requested Rab they are released; A Rab Assignment Response Failure message is returned by the S-RNC to the CN with the Rab failed; The waiting procedures may be processed.
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 104/213
When a FDD cell belongs to a D-RNC but is not in the S-RNC neighbor cells provisioning, the iMCTA target Cell color threshold has a Red default color.
When a neighbour 2G cell is given by a D-RNC and cannot be found in the S-RNC provisioning, the iMCTA target Cell color threshold has a Red default color. Two colors are supported: green/red. At the cell configuration, the cell iMCTA color is green by default. For cells managed by a D-RNC, the cell iMCTA color is also green by default.
uRRM step 1:
A GSM target cell has a red color if a handover towards this cell has been rejected for load reasons in the previous x (3g2GInhibTimer parameter value configurable). Otherwise the cell color is green.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 105/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 106/213
4.20.4 PARAMETERS
IMCTA OPTIONS
Name serviceHoRanapEnable Object/Class RadioAccessService Class 3
ServiceForTrafficSegm entationPriority Class3 RadioAccessService Class 3 RadioAccessService Class 3
mode
FDDCell Class 3
hsxpaSegmentationEnable
FDDCell Class3
mobilityServiceForHsxpaEn able
FDDCell Class3
mobilityServiceForNonHsxp aEnable
FDDCell Class3
originatingCellColourThres hold
FDDCell Class 3
mode
NeighbouringRNC Class 3
targetCellColourThreshold
FDDCell Class 3
Definition If set to True, the Service Handover IE (if present) will be taken into account by the RNC whatever the iMCTA triggers. If set to True, the service segmentation will have a higher priority than load balancing in iMCTA algorithm (option Service Segmentation activated uRRM step 2 feature: if set to True, the cell load information IE (if present) will be taken into account by the RNC to set GSM cell color. If uRRM step 2 not activated: when a HO3G2G is rejected, this timer is armed for the requested target 2G cell. This cell will not be selected by the RNC until the timer elapses. If the timer has a 0 value, the timer is not armed and the cell is not filtered. Four modes allowed. If set to AlarmOnly, the feature only applies when the trigger is an Alarm HHO condition. If set to AlarmAndCac the feature applies for Alarm and CAC reasons. If set to AlarmAndService the feature applies for Alarm and Service reasons. If set to All, all iMCTA triggers apply. If set to True the iMCTA function shall not try to allocate non-HSxPA capable mobiles on a cell supporting HSxPA and HSxPA capable mobiles on a cell not supporting HSxPA. If set to false the segmentation doesnt occurs. This option doesnt apply in case of iMCTA Alarm/CAC failure triggering. This parameter is read when a HSDPA/HSUPA capable mobile has moved through an Intra Freq Intra RNC SHO procedure. If set to False, iMCTA is not triggered after the SHO. If set to True, iMCTA function may apply. This parameter is read when a non HSDPA/HSUPA capable mobile has moved through an Intra Freq Intra RNC SHO procedure. If set to False, iMCTA is not triggered after the SHO. If set to True, iMCTA function may apply. An iMCTA applies to the originating cell if its relevant cell colors are upper (worse) than this threshold. For example, if the threshold is yellow, the iMCTA applies if at least one relevant originating cell color is red. This color is taken into account when the iMCTA triggers are different from Alarm and CAC. Two modes allowed. If set to AlarmOnly (default mode), the feature only applies when the trigger is an Alarm HHO condition. If set to AlarmAndCac the feature is activated for Alarm and CAC triggers. A neighboring cell is eligible as target for iMCTA if all relevant cell colors are lower (better) than this threshold. For example, if the threshold is yellow,
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 107/213
userServiceSigToTrafficOnly Enable
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 108/213
CacPriorityTableConfClass
RadioAccessService Class3
ServicePriorityGeneralTableConfClass
RadioAccessService Class3
ServicePriorityTableForHsdpaConfClass
RadioAccessService Class 3
ServicePriorityTableForHsupaConfClass
RadioAccessService Class 3
Definition This table gives for 2G and 3G access a priority value per service type. This table is used when an iMCTA Alarm trigger is processed. This table gives for 2G and 3G access a priority value per service type. This table is used when an iMCTA CAC trigger is processed. This table gives for each Fdd and 2G carriers a priority value per service type. This table is used when an iMCTA service trigger is processed and one of the following tables may not be used (i.e. the UE is not HSXPA or the tables are not present). This table gives for each Fdd and 2G carriers a priority value per service type. This table is used when an iMCTA service trigger is processed for a HSDPA capable mobile. This table gives for each Fdd and 2G
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 109/213
ServiceSegmentationPriorityClass
RadioAccessServi ce Class3
FDDCell Class 3 FDDCell Class 3 FDDCell Class 3 FDDCell Class 3 FDDCell Class 3 NeighbouringRNC Class 3 NeighbouringRNC Class 3
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 110/213
Name
Object/Class
Definition
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 111/213
[USA Market - The following counters have been modified or added in UA06.0:
VS.CmActivationSuccess Number of successful Compressed Mode activations Screenings: - GSM - InterFrequency - GSMAndInterFrequency VS.CmActivationFailure Number of failed Compressed Mode activations Screenings: - GSM - InterFrequency - GSMAndInterFrequency
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 112/213
URA update
Note: if SIB2 is not broadcasted in a cell then a mobile in URA_PCH that has reselected this cell will perform a URA_UPDATE (change of URA), allowing the RNC to move the UE to Cell_PCH RRC state.
UE
URA UPDATE (u-rnti)
UTRAN
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 113/213
The following specifies the Alcatel-Lucent UTRAN behaviour on reception of a cell update or URA update for a mobile in URA_PCH or Cell_PCH RRC state, based on the cause indicated by the UE in the message.
Cell reselection On reception of the Cell update message from a mobile in Cell_PCH state, the RNC increments the counter of number of Cell reselections. If this counter reaches a configurable threshold, the RNC shall send the mobile to URA_PCH (if the operator has activated URA_PCH). Else, the RNC shall resend the mobile to Cell_PCH.
In case the cell is part of new LA/RA, then a LA/RA update is performed on Cell_FACH.
Periodic cell update On reception of the Cell Update message, the RNC updates the UE location and resends the mobile to Cell_PCH. It is used as supervision mechanism: the call is released in case of periodical update lack..
Re-entered service area On reception of the Cell Update message, the RNC updates the UE location and sends the mobile to URA_PCH or Cell_PCH according to what was the previous state of the mobile and has been configured by the operator for the cell.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 114/213
URA reselection On reception of the URA update message, the RNC shall resend the mobile to URA_PCH with a new URA (the one at the head of the list defined for this cell). or If the current cell is not part of any URA, the RNC shall send the mobile to Cell_PCH (given it is allowed on the network) or Idle (if Cell_PCH is not allowed).
The RNC doesnt check if the cell is part of new LA/RA: no LA/RA update procedure is performed on Cell_FACH.
Periodic URA update Nothing to do except resend the mobile to URA_PCH state keeping the same URA. It is used as supervision mechanism: the call is released in case of periodical update lack.
Unknown u-RNTI In case the UE sends a Cell Update or URA update message with an unknown u-RNTI, the RNC shall: If the u-RNTI belongs to another RNS, it shall send an RRC Connection Release message (directed signalling connection re-establishment cause): see [Iur management] in a previous paragraph; If the u-RNTI belongs to this RNS, it shall send an RRC Connection Release to the UE. Multiple URA_update or Cell_Update The RNC may receive several URA_update or Cell_Update in case the UE did not receive the confirmation message from the RNC (eg: it has reselected another cell). In this case, the RNC shall act as for the first one received (but may assign a different URA if the cell reselected is different).
4.21.2 APPLICABILITY
This feature is applicable when the call enters in Cell/URA PCH state.
4.21.3 ALGORITHM
The cell selection/re-selection evaluation process (see [A5]) in Cell_PCH or URA_PCH RRC state for Intra Freq, Inter Frequency or Inter rat mobility management is the same as for CELL-FACH RRC state. Please refer to section 4.5.4.
4.21.4 PARAMETERS
The activation of using CELL/URA PCH RRC state is described in [R3]. The mobility configuration is made through the following parameter:
Object/Class
FDDCell Class3
Definition at least one identity is needed if URA_PCH is used (a UE moving to URA_PCH is assigned the first one in the list . If the list is not provided, the mobile shall be moved to Cell_PCH (if enabled) or idle (else).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 115/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 116/213
4.22. HCS: CELL RESELECTION CONTROL IN A HIERARCHICAL CELL STRUCTURE [Global Market] 4.22.1 DESCRIPTION
The Hierarchical Cell Structure feature enables the cell reselection control procedure in a Multi Layer network. HCS algorithm is based on the classical principles of the re-selection algorithm of the UE in Idle/connected mode as defined in the sections 4.4 and 4.5 but with additional algorithms handled by the HCS and applicable to the new concept of the UE fast moving also called high mobility. This feature allows the operator to prioritize cell layers for mobiles in idle mode, Cell_Fach, and URA/Cell_PCH connected modes. The cell reselection algorithms could be also applicable to the UE speed so that fast moving UEs can be placed in large cells to avoid excessive cell reselections (i.e. macro cells/ mobility layer). In addition it allows a better radio plan management and handles the UTRAN resources with better efficiency improving the UTRAN capacity (i.e. micro cells/capacity layer), improving higher data rate services in small areas, handling others services as in private systems, and so decrease the total system cost. Also to be considered the Hierarchical Cell Structure provides the architecture of a multi-layered cellular network where subscribers are handed over from the macro to the micro or to the pico cell layer depending on the current network capacity and the needs of the subscriber. It means the cell plan has several levels. For example fast moving terminals could be redirected to macro cell layer (i.e. mobility layer), rather low moving terminals to micro/pico cell layer (i.e. capacity layer).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 117/213
Macro cell
Fk
Micro cells
Fm
Pico cells
Fn
The 3GPP has introduced with the cell re-selection algorithm for Hierarchical Cell Structure the concept of the high mobility detection (UE fast moving) which may be used without HCS feature activation. As the traffic user demands on the network should vary in time and in space, local traffic peaks are likely to occur and so required micro cells are needed to complement the macro cells. Now with fast UE, large number of handoff between these cells may occur. Typically High mobility detection is useful in such cases, and shall avoid too much undesirable handoffs which can produce call drops. It shall also offer to reduce negative radio effect when one fast moving UE is connected to a distant macro cell, and enters a micro cell, then the unwanted radiation of the high power transmission UE may generate some interferences at the micro cell NodeB, which is tuned to lower transmission terminals. It may appear in particular radio conditions (UE at the edge of radio cells), to trigger the high mobility detection even if its not a real fast moving UE case.
4.22.2 APPLICABILITY
The HCS applies to the following mobility cases: "3G to 3G cell reselection intra-frequency in Idle/Fach mode" which allows a UMTS mobile camping on a 3G cell to reselect a cell using the same technology and frequency according to a priority level between the serving cell and its neighbouring "3G to 3G cell reselection inter-frequency in Idle/Fach mode", according to a priority level between the serving cell and its neighbouring "3G to 2G cell reselection in Idle/Fach mode" which allows a "GSM capable" UMTS mobile to reselect a GSM cell when being in idle mode in the UMTS coverage according to a priority level between the serving cell and its neighbouring, only UTRAN/FDD and GSM Radio Access Technologies are known and supported
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 118/213
The HCS algorithm is based on the classical principles of the re-selection algorithm of the UE in Idle/connected mode, but for R5 UE some new concepts are introduced based on the priority set to a cell for a given set of cell (Serving cell and neighbouring cells) and the high mobility detection. The new specific parameters for HCS cell re-selection procedure are controlled by the RNC. The broadcasting of these new parameters implies coding/scheduling modification for SIB3/SIB11 broadcasted on the BCCH channel in idle mode, and for SIB4/SIB12 in FACH or PCH mode if enabled.
4.22.3 ALGORITHM
As specified in [A5], the UE algorithm for cell reselection applied to HCS still defines a criteria for UTRAN/FDD or GSM neighbouring cells tracking and measurement a criteria S to assess FDD and GSM cells eligibility a criteria H for HCS using a quality level threshold to prioritise cells for the ranking a criteria R for ranking of eligible cells The cell re-selection algorithm defined for HCS takes into account: Classical re-selection parameters: o Quality measured/value derived from the CPICH Ec/No or CPICH RSCP, o UE measurement for intra/inter frequency, o UE measurement for inter RAT, o Time reselection duration according to the corresponding UE state (URA/Cell PCH or Cell-FACH), o 3GPP defined thresholds level (Qhyst1s , Qoffset1s,n,), o Cell Ranking criteria R, New parameters/concepts for HCS re-selection: o Priority levels for serving and neighbouring cells (0 to 7) as : o HCS_PRIOs : Defines the HCS priority level for serving cell, o HCS_PRIOn : Defines the HCS priority level for neighbouring cells, o HCS re-selection criterion and HCS thresholds as : Qhcs : Quality threshold level for applying hierarchical cell reselection, Hs/ Hn: Quality threshold criterion for applying hierarchical cell reselection, H criterion used for neighbour cells selection for the ranking Additional HCS parameters (including temporary offset) for HCS criterion H and cell-ranking criterion R,
o o o
High mobility detection (UE fast Moving), UE measurement for intra/inter frequency used for high mobility state detection, UE measurement for inter RAT used for high mobility state detection,
From an algorithmic point of view the main differences with the classical reselection procedure are on the measurement rules and on the ranking algorithm.
o o o
HCS cell-reselection procedure is based on UE measurements and the measurements rules, The new concept of high mobility detection procedure could be applied to the HCS measurement rules if configured, in order to detect a high mobility state. When HCS is used SsearchHCS specifies the threshold for Srxlev below which Intra-frequency and inter-frequency measurements of the neighbouring cell are performed.
Note: When HCS is not used the SsearchHCS applies also, in that case it specifies the threshold for Srxlev below which ranking for inter-frequency of the neighbouring cell of the serving cell is performed (see section 4.4 ).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 119/213
Main steps
Step 1: The UE measurement rules described in [A5] apply: the list of measured cells depends on HCS priority level and the UE high-mobility state. The list may be a sub-list of all provisioned neighbour cells sent in the SIB11message. Step 2: The S and H criterion apply on the measured cells to identify cells candidates for the neighbour cells ranking criterion R. The S criterion is described in the section 4.4. The quality threshold level criterion H for HCS, involving a prioritized ranking to the candidate cells, is defined as:
Measured cell quality value. The quality of the received signal expressed in CPICH Ec/N0 (dB) Quality threshold levels for applying HCS algorithmic. Constant value Time Offset
If at least one measured neighbor cell verifies H 0 the criterion S applies according to the high mobility state:
If high mobility state is not active, the criterion S apply on measured cells with the highest HCS_PRIO with H 0 (use case: favour transition from mobility layer to capacity layer with the assumption of mapping mobility layer with one lowest priority ); If high mobility state is active, the criterion S apply on measured cells with : o If (HCS_PRIOn < HCS_PRIOs), the highest HCS_PRIOn priority level which verify H 0: the neighbor layers with the closest priority of the serving layer is selected (use case: UE leaves a serving layer coverage towards a layer with a lower and closest priority); o If (HCS_PRIOn HCS_PRIOs), neighbour cells with the lowest HCS_PRIOn priority level which verify H 0: the neighbor layers with the closest or the same priority as the serving layer is selected (use case: UE sees new cell layers with an upper closest or equal priority);
If no cell verifies H 0 the criterion S and R are used as if HCS was not used (see S criterion of section 4.4).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 120/213
The best ranking cell is the cell with the highest R value. As explained in the section 4.4 the ranking is based on CPICH RSCP quality and a second ranking may occur when quality measurement is Ec/No. The selected cell has to fulfill the Access restriction rules see [A5].
Hn formula: TO applies when the neighbour cell HCS priority is different from the serving cell HCS priority : the objective is to give a mean to disadvantage some neighbour cells before ranking when they belong to a layer with a priority different than the serving layer priority (use case: ping pong between cells of different priorities). Rn formula: TO applies when the neighbour cell HCS priority is equal to the serving cell HCS priority: the objective is to give a mean to disadvantage some neighbour cells ranking which belong to the same layer or to layers with equal priority: the ranking value will be decreased during TO. (use case: ping pong between cells of same priorities). TEMP_OFFSET n applies an offset to the R and H criteria for the duration of PENALTY_TIMEn after a timer Tn has started for that neighbouring cell.
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 121/213
Fdd Cell: If quality measurement used is CPICH Ec/No, Qoffsets,n = Qoffset2s,n . If quality measurement used is CPICH RSCP, Qoffsets,n = Qoffset1s,n. 2G Cell: Qoffsets,n = Qoffset1s,n.
4.22.4 PARAMETERS
AT UTRAN/FDD CELL LEVEL
The isHscUsed parameter allows the activation/deactivation of the HCS procedure. The tCrMax allows the activation/deactivation of the High mobility detection.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 122/213
3 4
sSearchHcs
3 4
sHcsRatGsm
3 4
speedDependScalingFacto rTReselection
3 4
CellSelectionInfo CellSelectionInfoCo nnectedMode CellSelectionInfo CellSelectionInfoCo nnectedMode CellSelectionInfo CellSelectionInfoCo nnectedMode CellSelectionInfo CellSelectionInfoCo nnectedMode CellSelectionInfo CellSelectionInfoCo nnectedMode CellSelectionInfo CellSelectionInfoCo nnectedMode CellSelectionInfo CellSelectionInfoCo nnectedMode CellSelectionInfo CellSelectionInfoCo nnectedMode CellSelectionInfo CellSelectionInfoCo nnectedMode
3 4 3 4 3 4
nCR
3 4
tCrMaxHyst
3 4
hcsPrio
3 4
qHcs sLimitSearchRat
3 4 3 4
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 123/213
penaltyTime
temporaryOffset2
11 12
penaltyTime
temporaryOffset1
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 124/213
5.
5.1.
COMMON PROCEDURES
PERIODIC MEASUREMENT REPORTING MODE
One possible reporting mode is the periodic reporting mode. This section indicates in which order the various processes are performed in the RNC when receiving a periodic Measurement Report message from the mobile (e.g. each 500 msec). 1. 2. 3. 4. alarm handover criteria evaluation (inter-system, intra-frequency inter-RNC or inter-frequency handover criteria evaluation based on current primary cell) active set evaluation process primary cell determination process measurement configuration update (either modification of intra-frequency monitored set, or intersystem measurements)
This reporting mode is not recommended in this version (but is still available for trace purpose).
5.2.
5.2.1 DESCRIPTION
Another reporting mode is the intra-frequency event triggered reporting mode. This mode is strongly recommended. The use of event triggered reporting has a direct impact on the following mechanisms: primary cell determination (refer to 5.4) active set management (refer to 5.3) alarm measurement criteria (refer to 5.9) inter-frequency blind handover (refer to 5.2.3) Radio Link colour determination (refer to 5.2.3) The target cell choice for alarm handover is not impacted by the event triggered reporting mode. The basic principle of event handling is that the event semantic is taken into account in the implementation, e.g. event 1A reception leads to radio link addition, while event 1B involves a RL deletion. If not specified otherwise, Measured results reported by the UE on other cells than the one having triggered the event are not used in mobility handling algorithms e.g. measured results reported in event 1A shall not lead to RL deletion in the current active set. The main reason for is about Time To Trigger. Making a decision at the RNC side until Time To Trigger has elapsed at the UE side may lead to unstable situations (ping-pong ). The main principle of intra-frequency event triggered is to
Rely on intra frequency events for management of intra-frequency mobility: configuration of events (1A, 1B, 1C, 1D, 1E, 1F, 2D and 2F) 1A 1B 1C 1D 2D 2F to add a cell in the active set (1) to remove a cell in the active set (1) to replace a cell in the active set (1) to replace the primary cell in the active set (1) to enter the alarm condition and possibly start inter-freq or inter-RAT measurements (2) to leave the alarm condition and possibly stop inter-freq or inter-RAT measurements (2)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 125/213
Also configure events (1E and 1F) if the feature SHO enhancement (release UA04.1) is enabled (on a per user service basis) 1E 1F to add a radio link (1) to remove a radio link (1)
Note: The release information above is added in order to distinguish between this feature (refer to [R5]) and the later SHO enhancements [USA Market].
Also configure, when the alarm condition is fulfilled, inter-frequency or inter-RAT measurements in periodic mode Also configure event (1J) used for E-DCH active set management if parameter isRrcEdchEvent1JAllowed is set to TRUE (refer to [R6] for details). 1J a radio link that is DCH active set but not in the E-DCH active set becomes stronger than one radio link that is in the E-DCH active set
(1) Measurement result is Ec/N0 (2) Measurement results are Ec/N0 and RSCP
5.2.2 CONFIGURATION
The event-triggered mode is chosen if this reporting mode is allowed in the FDD Primary Cell (O&M Fdd Cell parameter isEventTriggeredMeasAllowed) where the UE is established and if the preferred eventtriggered mode is FULL-EVENT at the RNC level. During all the life of a call, this choice of the reporting mode is computed at each transition to CELL DCH (CELL_FACH or xxx_PCH or Idle to CELL_DCH whether the call is handled over DCH or HSDPA). And when the mode Full-Event is selected at the establishment in CELL_DCH, there is no mechanism to switch the mode during this phase of the call in CELL_DCH. If event-triggered is configured in the cell where the UE transits to CELL_DCH, the RNC chooses this measurement reporting mode after the transition to CELL_DCH. If the event-triggered reporting is configured, all SHO related events are configured, plus events required for Alarm Measurement criteria. If the call is setup on CELL_FACH or if an Always-On takes place, the events are configured once the RB is setup or reconfigured in CELL_DCH state. If the call is setup on CELL_DCH, the events are configured once the Signalling Radio Bearer is setup. According to [R3] Event 1A may be configured in SIB11 A MEASUREMENT CONTROL will be sent after the transition to CELL_DCH to configure 1A (the 1A configured by SIB11 is overridden) to 1J events. The intra-frequency cell list will be updated by the first MEASUREMENT CONTROL sent after the transition to CELL_DCH i.e. the entire cell list is sent to the UE (by removing all the cells and giving the new list) to ensure that the cell list in the UE and the RNC are exactly the same.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 126/213
SUMMARY
According to [A7], the UE shall be able to support in parallel per category up to Ecat reporting criteria as defined in following table:
All the events needed in UA06.0 Alcatel-Lucent implementation are listed in the table below.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 127/213
Algorithm
Primary Cell Active Set Mgt Absolute Thresholds Alarm Meas. Criteria
Intrafrequency CPICH Ec/No 1 (1D) 4 (1A, 1B, 1C, 1J) 2 (1E, 1F)
0
Interfrequency2
InterRAT
0 0 0 0
1 (4A) 1 (1A)
The inter-frequency events are used for inter-frequency handover as well as for inter-RAT handover
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 128/213
EVENT 1B, 1F
If received during the SRLR window, all 1B and 1F are processed in UA05. [USA Market If the parameter isOne1bStorageAllowed is set to TRUE then only the last received event 1B will be stored for UEs later than R99 because those UEs are capable to repeat event 1B as well.] If received during the SHO blocking window (i.e. during the NBAP procedure execution), 1B and 1F are treated by the RNC at the end of a Blocking Phase. [USA Market Event 1B from a UE later than R99 will be processed after any event 1A or 1C stored in parallel if the parameter isOne1bStorageAllowed is set to TRUE.]
EVENT 1D
The last 1D event received during the SRLR window, is treated by the RNC. Active Set processing during the blocking phase: Take into account all received event 1F (if one RL is remaining at least). Take into account all received event 1B (if one RL is remaining at least). Take into account the last received event 1A or 1C (if there is enough room in Active Set at least for 1A). Take into account the last received event 1E (if there is enough room in Active Set at least). Take into account the last received event 1J (if there is enough room in Active Set at least). Take into account the last received event 1D. If the triggering cell is in the Monitored Set (possible for UE not in R5), a RL Addition can be performed with this cell. The actions of RL Addition/Deletion have to be decided to keep a not empty Active Set and to respect the Maximum number of RL in it.
EVENTS 2D, 2F
These events are processed when received since they correspond to arm and stop timer. The Hard HO treatment has priority on Soft HO, which has priority on alarm measurements activation.
5.2.4 PARAMETERS
Name Object/Class
FDDCell Class3
isEventTriggeredMeasAllowed
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 129/213
5.3.
The Active Set is managed differently according to the reporting mode (periodic or intra-frequency event triggered). The Active Set is supported over Iur.
The algorithm is the following : 1. 2. Find the cell with the highest CPICH Ec/No. Lets call it cell(0) with Ec/No(0) Compare (Ec/No(0) Ec/No(i)) to drop_threshold for cells in the current active set - Keep as eligible in the active set those which Ec/No(0)-Ec/No(i) < drop_threshold - Cells to be dropped = the others - If all the cells of the current active set are non eligible, keep at least the best one Compare (Ec/No(0) Ec/No(i)) to add_threshold for cells not in the current active set - Put as eligible those which Ec/No(0)-Ec/No(i) < add_threshold Rank all the eligible cells - Keep the max_legs first cells in the active set - but insuring that at least one cell from the current active set is in the list
3. 4.
All the parameters used in the algorithm above are attached to the current primary cell.
CPICH Ec/No
add_threshold drop_threshold Cell in current active set Cell not in current active set
Measurement periods
Figure 56: algorithm for active set management
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 130/213
ShoLinkAdditionCpichEcNoThreshold
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 131/213
This algorithm can be completely or partially de-activated. Please check the [parameter] section for further details. Moreover this enhanced SHO management algorithm enables the use of CIO (cell individual offset) parameter in the evaluation of active set update and primary cell determination algorithm.
Name
Object/Class
SoftHoConf Class3 SoftHoConf Class3 SoftHoConf Class3 SoftHoConf Class3 SoftHoConf Class3 SoftHoConf Class3 SoftHoConf Class3
Definition threshold to withdraw a cell from the active set, referred to as drop_threshold in the section above threshold to add a cell in the active set, referred to as add_threshold in the section above maximum number of legs in macrodiversity (from 1 to 6), referred to as max_legs in the section above Absolute threshold for radio link deletion Absolute threshold for radio link addition If enabled, the absolute threshold for radio link deletion is applied If enabled, the absolute threshold for radio link addition is applied
When the current primary cell pertains to the DRNC and as far as neither the class of cell nor the cell parameters (which are proprietary) are not reported over the Iur, the set of parameters which will be used for the algorithm will be a default set defined per Neighbour RNC. Cell Individual Offset CIO will be used in the AS evaluation algorithm only when at least one of the ShoLinkXxxAbsoluteThresholdEnable flag is True.
If W is set to 0, event 1A allows the same behavior as with current algorithm. This works the same way for event 1B:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 132/213
Reporting event 1A
Reporting event 1C
Time
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 133/213
In order to trigger a report, the triggering condition has to be valid for a period of time named time to trigger. This parameter is configurable for each event (the values sent to the UE are defined by the parameters timeToTrigger1A, timeToTrigger1B, timeToTrigger1C). The recommended value for timeToTrigger1B will be greater than that for timeToTrigger1C. This may result in the scenario shown in figure below. Event 1C triggered by a non-active cell may be sent earlier than event 1B even if the trigger condition for event 1B started to apply before. However the non-active cell to appear as a candidate for replacement is too weak and should not be added to the active set.
Pilot strength
Strongest active set cell Reporting Range for e1a 2nd active set cell Reporting Range for e1b Time-to-Trigger e1b Non-active cell Time-to-Trigger e1c
Problem: e1c is sent earlier than e1b, but the non-active cell is too weak and should not be added to the active set. The 2nd active set cell should be just removed from the active set.
Time
[USA Market - the algorithm was enhanced such that replacement of an active set cell by a non-active cell reported in Event 1C depends on a threshold thr_replace as defined in formula below:
A non-active cell will only be added if its reported CPICH_Ec/N0 plus the Cell Individual Offset is greater than thr_replace:
Otherwise the non-active cell will not be added and only the weak active set cell will be removed as if Event 1B would have been received.] The RRC protocol allows configuring the event 1A trigger by either Monitored Set cells or Detected Set cells or both Monitored and Detected Set cells. The following events need to be configured:
Event id 1A
Triggering condition Monitored set cells or Monitored and Detected set cells
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 134/213
The RRC protocol allows configuring periodic reporting of event 1A, 1C and 1B (only from Release 5) as long as the reporting criteria are still valid.
10 LogMOld + CIOOld T1 f H1 f / 2,
H1e and H1f refer to as hysteresis parameters. They can is set to the value of hysteresis1E and hysteresis1F. T1e and T1f refer to as absolute thresholds. CIOOld and CIONew refer to as Cell Individual Offset. MNew refers to as CPICH Ec/No or CPICH RSCP measurement made by the mobile.
The following picture illustrates event 1E and 1F reporting, in case CIO and H parameters are set to 0. In this figure, the P-CPICH 3 will trigger an event 1E and P-CPICH 1 will trigger an event 1F.
Measurement quantity
P CPICH 1 P CPICH 2
Absolute threshold of 1E event Absolute threshold of 1F event
P CPICH 3
Reporting event 1E Reporting event 1F
Time
Reporting quantity
Event id
Triggering condition
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 135/213
CPICH Ec/No
1F
Please note that CIO is a configurable parameter defined against the primary cell for each of its neighbour cell.
ALGORITHM
In case of intra-frequency Event-Triggered Reporting mode, the RNC behaviour is as follows:
If either 1A or 1E (if configured) event is received for a cell of the monitored set, the corresponding radio link is (possibly) added to the active set. In case of several Monitored Set to Add, only the best ordered in the IE Event Results of the Measurement Report is added. The reception of an event 1A or 1E is received for a detected cell will generate a trace and the cell which trigs the event will not be added in the active set unless special conditions for event 1A [USA Market] do apply. [USA Market - If the parameter isDetectedSetCellsAllowed is set to TRUE and the parameter detectedSetCellAddition is set to TRUE or AUTOMATIC then Detected Set cells reported in event 1A will be added to the active set in the following scenario: If the combined intra frequency Cell Info List exceeds its maximum size then cells with lower ranking priority need to be cut off from the list (refer to 5.5.3) which in consequence does no more represent the complete neighborhood of the active set. The cells having been cut off may reappear as Detected Set cells reported by the UE and will then no longer be ignored but be added to the active set.] If either 1B or 1F (if configured) event is received for a cell of the active set, the corresponding radio link is removed from the active set If 1C event is received, the RNC will replace the cell in the Active Set indicated in the measurement report with the cell triggering this event. If several Active Set cells are included in the Event Results and are worse than the Monitored Set cell to add, the RNC deletes them: so the RNC can resize the Active Set [USA Market - Detected Set cells will be added to the active set under the same conditions as described for event 1A above. However a non-active cell (i.e. Monitored Set cell or possibly Detected Set cell) will not be added to the active set if it is too weak as described for enhanced event 1C handling above. In this case event 1C will be acted upon as if event 1B would have been received i.e. only a radio link removal will result.]
In this version, the RNC will not have a special handling to avoid a potential ping-pong generated by RNC actions (i.e. RL addition/deletion) triggered by The reception of one event based on absolute thresholds (1E/1F) followed by the reception of one event based on relative thresholds (1A/1B). Typical example of this scenario could be the addition of a new RL triggered by 1E followed immediately by the deletion of this RL triggered by 1B of the same cell. Or The reception of one event based on relative thresholds (1A/1B) followed by the reception of one event based on absolute thresholds (1E/1F). Typical example could be the addition of a new RL due to 1A followed immediately by deletion of the same RL due to 1F reception. If the Primary cell needs to be removed due to event 1B or 1C reception then the RNC will first determine the new Primary cell (the best cell of the remaining active set) and in case of a HSPA call perform the serving cell change before executing the active set update (see also section 5.4). Note: If event 1F identifies the Primary cell to be removed then the event is ignored. As in SHO enhancement specification for release UA04.1, the radio link addition/deletion absolute criteria makes use of CIO parameter defined in the RNC database (Cell Individual Offset). Therefore: If the SHO enhancement feature (release UA04.1) is active, the CIO will be sent to the UE through the Measurement Control message. In this case, CIO will be applied by the UE on events
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 136/213
Note: The release information above is added in order to distinguish between this feature (refer to [R5])and the later SHO enhancements [USA Market]. As specified in [R10], the initial power of the Radio Link to be added not only depends from CPICH Ec/No measurement of the new cell, but also on the measurements reported for the other cells in the active set. This is still the case when event-triggered measurement reports are used. The measured results included in the Measurement Report are configured to be reported on Active Set cells and Monitored Set cells and on Detected Set cells (if configured via the parameter isDetectedSetCellsAllowed). If Detected Set cells are reported the RNC will trace this as specified in 5.3.6. The reception of an event during a procedure in progress may induce the storage of the event in order to solve the issues: refer to 5.2.3
CONFIGURATION
As only one intra-frequency measurement quantity is actually required (CPICH Ec/No), all intra-frequency events and measurements can be configured in a single message. As in [A4], some events reporting are not repeated. In order to limit the risk of loosing an event on the radio interface because of bad transmission conditions, all intra-frequency event reports are configured in RLC Acknowledged Mode. The overall structure of the intra-frequency MEASUREMENT CONTROL message is as follows. Up to 8 events can be configured in a single message.
10.2.17 Meas. Control Common part (reporting type) 10.3.7.36 Intra-freq measurements Common part (meas quantities) 10.3.7.39 Intra-freq meas rep criteria Event 1A Event 1B
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 137/213
In all the tables below: not needed means the IE is not part of the message, as it is not needed by 3GPP 25.331 specifications not used means the IE is optional and not used in this implementation.
1A EVENT CONFIGURATION
Information Element/Group name Parameters required for each event >Intra-frequency event identity >Triggering condition 1 >Triggering condition 2 >Reporting Range Constant >Cells forbidden to affect Reporting range >W Need OP MP CVclause 0 CVclause 6 CVclause 2 CVclause 1 CVclause 2 Parameter Value 1a Not needed Monitored Set Cells or Monitored and Detected Set cells Use cpichEcNoReportingRange1A parameter Not used If isExtendedSrbDcch3dot4k = False: 0 If isExtendedSrbDcch3dot4k = True: Upper two Bits of hysteresis1A parameter with following mapping: 00 = 0.0 01 = 0.3 10 = 0.6 11 = 1.0 If isExtendedSrbDcch3dot4k = False: Use hysteresis1A parameter If isExtendedSrbDcch3dot4k = True: Lower two Bits of hysteresis1A parameter with following mapping: 00 = 0dB 01 = 1dB 10 = 2dB 11 = 3dB Not needed Use value (maxActiveSetSize-1) Not needed Use timeToTrigger1A parameter Use amountRep1A parameter Use repInterval1A parameter Use maxNbReportedCells1A parameter
>Hysteresis
MP
>Threshold used frequency >Reporting deactivation threshold >Replacement activation threshold >Time to trigger >Amount of reporting >Reporting interval >Reporting cell status
Remark: The Reporting deactivation threshold IE indicates the maximum number of cells allowed in the active set in order for event 1a to occur, so that if the active set is limited by the maxActiveSetSize parameter, the value of this IE shall be set to (maxActiveSetSize-1). The purpose of this IE is to avoid the UE to report event 1A if the active set size limit is reached. [Global Market: Parameter isExtendedSrbDcch3dot4k should be set to False] [USA Market: If parameter isExtendedSrbDcch3dot4k is set to True the WNMS parameter hysteresis1A has different semantics on the user interface (range 0dB to 7.5dB) and within the RNC. The RNC interprets two Bits of the value as hysteresis and the other two Bits as weight. For the parameter mapping refer to section 6.3. Note that the parameter isExtendedSrbDcch3dot4k was spare in UA06 and reused for this purpose; the parameter name does not reflect the actual semantics.]
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 138/213
1B EVENT CONFIGURATION
Information Element/Group name Parameters required for each event >Intra-frequency event identity >Triggering condition 1 >Triggering condition 2 >Reporting Range Constant >Cells forbidden to affect Reporting range >W Need OP MP CVclause 0 CVclause 6 CVclause 2 CVclause 1 CVclause 2 Parameter Value 1b Active Set Cells Not needed Use cpichEcNoReportingRange1B parameter Not used If isExtendedSrbDcch3dot4k = False: 0 If isExtendedSrbDcch3dot4k = True: Upper two Bits of hysteresis1B parameter with following mapping: 00 = 0.0 01 = 0.3 10 = 0.6 11 = 1.0 If isExtendedSrbDcch3dot4k = False: Use hysteresis1B parameter If isExtendedSrbDcch3dot4k = True: Lower two Bits of hysteresis1B parameter with following mapping: 00 = 0dB 01 = 1dB 10 = 2dB 11 = 3dB Not needed Not needed Not needed Use timeToTrigger1B parameter Not needed Not needed Use maxNbReportedCells1B parameter Use amountOfRep1B and repInterval1B parameters
>Hysteresis
MP
>Threshold used frequency >Reporting deactivation threshold >Replacement activation threshold >Time to trigger >Amount of reporting >Reporting interval >Reporting cell status >Periodical reporting information-1b
Remark: As a 3GPP R5 improvement, a periodical reporting IE has been added for event 1B. This change is made on a backward compatible way, meaning that this IE, when present, will be decoded by R5 and above UE, and ignored by R99 UEs. This IE is part of Alcatel-Lucent implementation and is sent each time event 1B is configured. [Global Market: Parameter isExtendedSrbDcch3dot4k should be set to False] [USA Market: If parameter isExtendedSrbDcch3dot4k is set to True the WNMS parameter hysteresis1B has different semantics on the user interface (range 0dB to 7.5dB) and within the RNC. The RNC interprets two Bits of the value as hysteresis and the other two Bits as weight. For the parameter mapping refer to section 6.3. Note that the parameter isExtendedSrbDcch3dot4k was spare in UA06 and reused for this purpose; the parameter name does not reflect the actual semantics.]
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 139/213
1C EVENT CONFIGURATION
Information Element/Group name Parameters required for each event >Intra-frequency event identity >Triggering condition 1 >Triggering condition 2 >Reporting Range Constant >Cells forbidden to affect Reporting range >W >Hysteresis >Threshold used frequency >Reporting deactivation threshold >Replacement activation threshold >Time to trigger >Amount of reporting >Reporting interval >Reporting cell status Need OP MP CVclause 0 CVclause 6 CVclause 2 CVclause 1 CVclause 2 MP CV-clause 3 CVclause 4 CV-clause 5 MP CVclause 7 CVclause 7 OP Parameter Value 1c Not needed Not needed Not needed Not used Not needed Use hysteresis1C parameter Not needed Not needed Use maxActiveSetSize parameter Use timeToTrigger1C parameter Use amountOfRep1C parameter Use repInterval1C parameter Use maxNbReportedCells1C parameter
Remark: The Replacement activation threshold indicates the minimum number of cells allowed in the active set in order for event 1C to occur. The purpose of this IE is to avoid the UE to report event 1C if the active set size limit is not reached.
1E EVENT CONFIGURATION
Information Element/Group name Parameters required for each event >Intra-frequency event identity >Triggering condition 1 >Triggering condition 2 >Reporting Range Constant >Cells forbidden to affect Reporting range >W >Hysteresis >Threshold used frequency >Reporting deactivation threshold >Replacement activation threshold >Time to trigger >Amount of reporting >Reporting interval >Reporting cell status Need OP MP CVclause 0 CVclause 6 CVclause 2 CVclause 1 CVclause 2 MP CV-clause 3 CVclause 4 CV-clause 5 MP CVclause 7 CVclause 7 OP Parameter Value 1e Not needed Monitored Set Cells or Monitored and Detected Set Cells Not needed Not used Not needed Use hysteresis1E parameter. Use cpichEcNoThresholdUsedFreq1E Not needed Not needed Use timeToTrigger1E parameter Not needed Not needed Use maxNbReportedCells1E parameter
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 140/213
1F EVENT CONFIGURATION
Information Element/Group name Parameters required for each event >Intra-frequency event identity >Triggering condition 1 >Triggering condition 2 >Reporting Range Constant >Cells forbidden to affect Reporting range >W >Hysteresis >Threshold used frequency >Reporting deactivation threshold >Replacement activation threshold >Time to trigger >Amount of reporting >Reporting interval >Reporting cell status Need OP MP CVclause 0 CVclause 6 CVclause 2 CVclause 1 CVclause 2 MP CV-clause 3 CVclause 4 CV-clause 5 MP CVclause 7 CVclause 7 OP Parameter Value 1f Active Set Cells Not needed Not needed Not used Not needed Use hysteresis1F parameter. Use cpichEcNoThresholdUsedFreq1F Not needed Not needed Use timeToTrigger1F parameter Not needed Not needed Use maxNbReportedCells1F parameter
Object/Class
RadioAccessService Class3 FDDCell Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3
hysteresis1A
timeToTrigger1A
MeasurementConfClass Class3 MeasurementConfClass Class3 MeasurementConfClass Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3
hysteresis1B
timeToTrigger1B
Definition Allows tracking of detected cells Allows addition of detected set cells to the active set. Relative CPICH Ec/No threshold for SHO Radio Link Addition. CPICH Ec/No hysteresis for link addition in Active Set For UA06 refer to section 6.3. Period of time during which the event condition has to be satisfied before sending event 1A Amount of periodical reporting for event 1A Interval of periodical reporting for event 1A Maximum allowed number of cells to report with event 1A Relative CPICH Ec/No threshold for SHO Radio Link Deletion. CPICH Ec/No hysteresis for link deletion in Active Set For UA06 refer to section 6.3. Period of time during which the event condition has to be satisfied before sending event 1B
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 141/213
MeasurementConfClass Class3 MeasurementConfClass Class3 MeasurementConfClass Class3 UsHoConf Class3 UsHoConf Class3
MeasurementConfClass Class3 MeasurementConfClass Class3 MeasurementConfClass Class3 Radio Access Service Class 3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3
hysteresis1E
timeToTrigger1E
maxNbReportedCells1E cpichEcNoThresholdUsedFreq1E
MeasurementConfClass Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3
isEvent1FUsed
hysteresis1F
timeToTrigger1F
maxNbReportedCells1F cpichEcNoThresholdUsedFreq1F
Allows storage of only the latest received event 1B while another procedure is in progress Amount of periodical reporting for event 1B Interval of periodical reporting for event 1B Maximum allowed number of cells to report with event 1B CPICH Ec/No hysteresis for cell replacement in Active Set Period of time during which the event condition has to be satisfied before sending event 1C Amount of periodical reporting for event 1C Interval of periodical reporting for event 1C Maximum allowed number of cells to report with event 1C Allows to prevent weak nonactive radio links from being added to the active set If enabled, the absolute threshold for radio link addition is applied CPICH Ec/No hysteresis for absolute threshold link addition in Active Set Period of time during which the event condition has to be satisfied before sending event 1E Maximum allowed number of cells to report with event 1E Absolute CPICH Ec/No threshold for SHO Radio Link Addition. If enabled, the absolute threshold for radio link deletion is applied CPICH Ec/No hysteresis for absolute threshold link deletion in Active Set Period of time during which the event condition has to be satisfied before sending event 1F Maximum allowed number of cells to report with event 1F Absolute CPICH Ec/No threshold for SHO Radio Link Deletion.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 142/213
TRACES
If the MIB flag RadioAccessService.isDetectedSetCellsAllowed is TRUE, the RNC requests the UE: to trigger the following events on Detected Cells also : o event 1A, where triggering Cells are both Detected Set Cells and Monitored Set Cells, o event 1E, where triggering Cells are both Detected Set Cells and Monitored Set Cells, To report the measurement of the Detected Cells in the Measured Result part of these events. If a Detected Cell is reported by the UE, the related counter will be incremented and a Call Failure Trace will be triggered based on a filtering mechanism to avoid overload in both RNC and OMC due to too many Call Failure Traces. This filtering mechanism allows to have at most one Call Failure Trace in a given period (e.g. 15 seconds static value cpTimerFileringCallFailureTrace -), for a set of calls. For the Call Failure Trace, the intra-frequency part of the RRC Measurement Report message and the scrambling code of the Detected Cell are traced.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 143/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 144/213
5.4.
5.4.1 DESCRIPTION
The primary cell is a sort of reference cell for the UE. It is used for monitored cells set determination and also as a pointer to mobility parameters, i.e. parameters with a cell granularity which are to be used for a mobile are those corresponding to its primary cell.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 145/213
The following picture illustrates event 1D reporting, in case CIO parameters are set to 0, cell (1) being the current primary. Event 1D is reported once cell (2) measurement quantity exceeds cell (1) by H1d/2.
Reporting event 1D
Time
ALGORITHM
The primary cell determination will be based on event 1D reception. Based on the reception of this event, the RNC stores the new primary, and applies the current process used in case of change of primary cell. The 1D event can be triggered by a cell in the Active Set for R5/R6 UEs or in the Monitored Set for R99/R4 UEs. Since the events 1A, 1C are also configured (see section 5.3) it is assumed that the new primary cell is already in the Active Set when an 1D event is triggered as explained in the following. This will be typically ensured if the time to trigger of 1D is greater or equal than the time to trigger of events 1A or 1C. It should be noted that a monitored set cell that needs to be included in the active set will trigger first an 1A event if its CPICH Ec/No is lower than the best cell in the Active set but entering in its reporting range or 1C event if the Active Set is full and this cell is better than the worse in the Active Set. An event 1D will typically be triggered by a cell better than the best in the active set. Therefore due to the triggering conditions definition of these events and if the time to trigger of 1D is greater or equal than 1A and 1C typically the 1D will be triggered by a cell in the active set. When CIO is used it may happen that 1A event is not triggered but 1D event is triggered. If the event 1D is triggered by a monitored cell, the RL will be added in the Active Set if not full. If the Active Set is full, then the event1D will provide the replacement of the worse cell in the Active Set.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 146/213
CONFIGURATION
Refer to 5.3.4 / configuration for common part of Measurement Control message. 1D event configuration
Information Element/Group name Parameters required for each event >Intra-frequency event identity >Triggering condition 1 >Triggering condition 2 >Reporting Range Constant >Cells forbidden to affect Reporting range >W >Hysteresis >Threshold used frequency >Reporting deactivation threshold >Replacement activation threshold >Time to trigger >Amount of reporting >Reporting interval >Reporting cell status >Use CIO
Need OP MP CVclause 0 CVclause 6 CVclause 2 CVclause 1 CVclause 2 MP CV-clause 3 CVclause 4 CV-clause 5 MP CVclause 7 CVclause 7 OP CVclause 10
Parameter Value 1d Not needed Not needed Not needed Not used Not needed Use hysteresis1D parameter. Not needed Not needed Not needed Use timeToTrigger1D parameter Not needed Not needed Use maxNbReportedCells1D parameter Use useCIO1D parameter
5.4.4 PARAMETERS
The parameters are:
Name
Object/Class
UsHoConf Class3
rrcIntraFreqMeasurementDropPrimaryRlDelta
useCIOfor1D
MeasurementConfClass Class3
Definition hysteresis for primary cell modification, referred to as DropPriRL in the section above. This flag indicates if CIO parameter has to be taken into account in 1D triggering condition
CPICH Ec/No hysteresis primary cell determination Period of time during which the event condition has to be satisfied before sending event 1D. Maximum allowed number of cells to report with event 1D
hysteresis1D
timeToTrigger1D
maxNbReportedCells1D
MeasurementConfClass Class3
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 147/213
When the current primary cell pertains to the DRNC and as far as neither the class of cell nor the cell parameters (which are proprietary) are not reported over the Iur, the set of parameters which will be used for the algorithm will be a default set defined per Neighbour RNC.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 148/213
5.5.
5.5.1 DESCRIPTION
The object of the section is the introduction of dynamic compounding cell lists in connected mode. This section is based on the feature called UMTS composite neighbour list. Compounding list functionality is the capability for the RNC: o To dynamically create the neighbour list a UE will monitor, when in dedicated mode, depending on the radio neighbourhood of this UE, this neighbourhood being either defined by the active set, or by measurements. o To send, through RRC Measurement Control message, this compound list to UE A new algorithm (type 1) to compute the compound neighbour cell list has been introduced for intrafrequency, inter-frequency and inter-RAT neighbour cells. In the latter cases only those cells which are supported by the UE according to its capabilities will be considered for addition to the compound neighbour list.
5.5.2 APPLICABILITY
The feature is efficient if the intra frequency -, inter frequency or inter RAT neighbour of each Fdd cell is optimized. In this case there will be enough space in the Measurement Control message to add neighbour cells of active cells other than those of the primary cell. It applies for calls in cell-DCH state only.
5.5.3 ALGORITHM
The best cell is the cell with the best CPICH Ec/No. If feature compounding list is not activated: The monitored set is the neighbouring list of the primary cell. If feature compounding list is activated: Three different algorithms (PRL, Type1 and Type2) are available for intra frequency neighbour cells and two different algorithms (PRL and Type1) are available for inter frequency - or inter RAT neighbour cells. The algorithm will be selected according to the value of primary cell parameter typeOfCompoundingNeighbourListIntraFreq typeOfCompoundingNeighbourListInterFreq typeOfCompoundingNeighbourListInterRAT respectively:
Type PRL: The monitored set is the neighbouring list of the primary cell. The behavior is the same as if feature compounding list is not activated.
Type 1: Compound neighbour list is build from all active set cells. The neighbors are selected into the compound list based on (given in order of significance)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 149/213
The RNC selects the first N cells from the prioritized neighbour list of the primary cell (N stands for parameter numOfPrimaryCellNeighbourIntraFreq, numOfPrimaryCellNeighbourInterFreq or numOfPrimaryCellNeighbourInterRAT respectively) It adds cells with the highest number of occurrences of the cell in the neighbor lists of the active set cells If some neighbour cells have the same occurrence, it selects the cell with the highest measured quality of the active set cell In case of same quality, it selects cells with higher priority of neighbour cell (parameter neighbourCellPrio or sorting order for DRNC) If the maximum number of allowed cells in the compound neighbor list (parameter maxCompoundingListSizeIntraFreq, maxCompoundingListSizeInterFreq or maxCompoundingListSizeInterRAT respectively) is exceeded then the lower priority cells are discarded.
Type 2 (only applicable for intra frequency neighbour cells): The monitored set is built as the union of o The primary cell plus its static neighbour list for dedicated mode o Either the best cells of the active set and their static neighbour list for dedicated mode, when the connection is engaged in soft or softer HO, until: the last leg and its static neighborhood list for dedicated mode has been added, or the list reaches maxSizeCompoundingList cells.
Or the N first (bests) measured cells and their static neighbour list for dedicated mode, when the connection is not engaged in soft or softer HO. Until: the new monitored cell set goes up to maxNbOfMonitoredCellForNonShoCompoundList cells , or the list reaches maxSizeCompoundingList cells; or until the last measured cell.
The compound intra frequency neighbour cell list shall be computed when
state transition to Cell_DCH, successful hard handover, change of primary cell or active set update
has occurred. The compound inter frequency neighbour cell list shall be computed when
a new RRC Measurement Control message for inter-frequency measurements (measurement type 2)
has to be sent to UE. The compound inter RAT neighbour cell list shall be computed when
a new RRC Measurement Control message for inter-RAT measurements (measurement type 3)
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 150/213
5.5.4 PARAMETERS
Name maxCompoundingListSizeIntraFreq maxCompoundingListSizeInterFreq maxCompoundingListSizeInterRAT isCompoundingCellListActivated typeOfCompoundingNeighbourListIntraFreq Object/Class
RadioAccessService Class3 RadioAccessService Class3 RadioAccessService Class3 RadioAccessService Class3 FDDCell Class 3
Definition Maximum number of cells in the intra-freq compounded list Maximum number of cells in the inter-freq compound list Maximum number of cells in the inter-RAT compound list
Used to activate or inhibit the compounded list feature
Used to determine the algorithm for intra-frequency neighbor list creation for dedicated measurements. Possible values are PRL, Type1, Type2 Used to determine the algorithm for intra-frequency neighbor list creation for dedicated measurements. Used when primary cell is on DRNC. Possible values are PRL, Type1, Type2 Used to determine the algorithm for inter-frequency neighbor list creation for dedicated measurements. Possible values are PRL, Type1 Used to determine the algorithm for inter-frequency neighbor list creation for dedicated measurements. Used when primary cell is on DRNC. Possible values are PRL, Type1 Used to determine the algorithm for inter RAT neighbor list creation for dedicated measurements. Possible values are PRL, Type1 Used to determine the algorithm for inter-RAT neighbor list creation for dedicated measurements. Used when primary cell is on
typeOfCompoundingNeighbourListIntraFreq
NeighbouringRNC Class 3
typeOfCompoundingNeighbourListInterFreq
FDDCell Class 3
typeOfCompoundingNeighbourListInterFreq
NeighbouringRNC Class 3
typeOfCompoundingNeighbourListInterRAT
FDDCell Class 3
typeOfCompoundingNeighbourListInterRAT
NeighbouringRNC Class 3
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 151/213
numOfPrimaryCellNeighbourIntraFreq
FDDCell Class 3
numOfPrimaryCellNeighbourIntraFreq
NeighbouringRNC Class 3
numOfPrimaryCellNeighbourInterFreq
FDDCell Class 3
numOfPrimaryCellNeighbourInterFreq
NeighbouringRNC Class 3
numOfPrimaryCellNeighbourInterRAT
FDDCell Class 3
numOfPrimaryCellNeighbourInterRAT
NeighbouringRNC Class 3
umtsFddNeighbouringCellList[].neighbourCellPrio gsmNeighbouringCellList[].neighbourCellPrio
FDDCell
Class 3
FDDCell Class 3
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 152/213
VS.MeasurementControlCellListSize Size of the compound intra frequency neighbor list VS.ExceededAggregateCellListSizeIntraFreq Amount by which the maximum intra-frequency neighbor list size is exceeded. VS.AggregateCellListAmbiguousCellIntraFreq The aggregate intra-frequency neighbor list contains an ambiguous cell. VS.MeasCtrlCellListSizeInterFreq Size of the compound inter-frequency neighbor list VS.ExcdAggrCellListSizeInterFreq Amount by which the maximum inter-frequency neighbor list size is exceeded VS.AggrCellListAmbigCellInterFreq The aggregate inter-frequency neighbor list contains an ambiguous cell. VS.MeasCtrlCellListSizeInterRAT Size of the compound inter-RAT neighbor list VS.ExcdAggrCellListSizeInterRAT Amount by which the maximum inter-RAT neighbor list size is exceeded VS.AggrCellListAmbigCellInterRAT The aggregate inter-RAT neighbor list contains an ambiguous cell
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 153/213
5.6.
SIB4Enable,
SIB12Enable
and
Limitation of the number of MIB segments. It shall not exceed one segment. Use of a SB1 block when all scheduling information cannot be coded in one MIB segment: the SIB scheduling information (whatever the SIB) which cannot be encoded in MIB are encoding in SB1. MIB block has a repetition period set to 8 and a position set to 0 ; SIB1 and SIB7 blocks have the same repetition period set to 16 and a start position set to 2; SIB3 and SIB4 shall have the same RP0 repetition period between 32 and 128; SIB2, SIB5, SIB6, SIB11 and SIB12 shall have the same RP1 repetition period between 32 and 256. The SB1 repetition period is set to the lowest repetition period of SIB(s) (RP0 or RP1) which may be addressed by SB1.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 154/213
5.7.
The UTRAN provides UEs in other state than Cell-DCH with the configuration of intra-frequency measurements via the SIB11. This allows the activation of the intra-frequency measurement event 1A for each mobile entering in Cell-DCH state. These UEs acquire intra-frequency configuration contained in SIB11. They can start and report their intra-frequency measurements without waiting any RRC Measurement Control message. For event triggered reporting only event 1A is configured. See reference document [R3] UMT/SYS/DD/013000 Mobility Performance Improvements.
5.8.
DHO MANAGEMENT
This section provides an overview of the management of diversity handover (uplink) in Alcatel-Lucent UTRAN nodes.
MSC/ SGSN Iu Iur SRNC DRNC
UE
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 155/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 156/213
5.9.
5.9.1 OVERVIEW
In this version of the document, alarm handover is a Hard Handover triggered by the iMCTA function when an Radio alarm condition is detected. The others reasons for processing a Hard Handover managed by the iMCTA function are: CAC failure and Service (see section 4.20). It may induce one of the following mobility cases: 3G to 2G handover for PS 3G to 2G handover for CS 3G to 2G handover for CS+PS inter-frequency inter-RNC handover inter-frequency intra-RNC intra-frequency inter-RNC Alarm Measurements refers to either inter-frequency measurements or inter-system GSM measurements. This section deals with Alarm radio condition. The Triggering of the Alarm measurement and the handover is based on the Fast Alarm algorithm.
Radio quality Cr
time
5.9.2 ALARM MEASUREMENTS ACTIVATION WHEN INTRA FREQUENCY MEASUREMENTS ARE PERIODIC BASED
Inter-system and inter-frequency measurements are requested under certain radio conditions.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 157/213
AlarmMeas = (CPICH Ec/No < ThreshEcMeas) or (CPICH RSCP < ThreshRSCPMeas) for the Primary cell.
Then, the following process is applied: If AlarmMeas is valid Increment AlarmMeasCounter by UpStep Else Let AlarmMeasCounter = max (0, AlarmMeasCounter DownStep) Endif If AlarmMeasCounter > AlarmMeasCounterThreshold then Alarm measurements are requested from the mobile The following figure illustrates this process:
Measurement report occasions AlarmMeasCounter AlarmMeasCounterThreshold DownStep UpStep Alarm Meas decision: AlarmMeasCounter > AlarmMeasCounterThreshold
time
3.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 158/213
time
time
This is described in the following figure (the use case concerns Intra Frequency periodic measurements with Inter System additional measurements):
UE PS/CS call setup Serving RNC
RRC/ Measurement report (intrafreq meas) RRC/ Measurement control (intersystem, neigh GSM cells, start CM) RRC/ Measurement report (intrafreq meas, intersystem meas)) ... RRC/ Measurement report (intrafreq meas, intersystem meas)) RRC/ Measurement control (start CM)
Based on intrafrequency measuremenst and depending on mobile capability, the SRNC decides to request intersystem measurements. Compressed Mode is also possibly activated, depending on mobile needs The UE is now able to report both intersystem and intrafrequency measurements. There is one single report for both reported quantities
Later on, the compressed mode activation condition is still valid, and compressed mode is re-activated
As a MEASUREMENT REPORT is received with GSM (resp. inter-frequency) measurements, the Alarm Measurement criteria is checked again. If still valid, a hard handover is triggered towards the chosen target cell. If no neighbouring measurement may be requested to the UE but Inter Rat HHO is allowed (for example: CM not possible, neighbouring cells filtered after applying IMSI criteria) or no suitable Alarm measurement is reported by the mobile within a guard timer period, a blind handover towards the blind GSM cell provisioned for the Primary cell may be performed by the RNC.
Remark 1: The additional check on the Alarm Measurement criteria once a measurement is received is needed, as the radio conditions may change between the measurement activation and the reception of the first measurement report with GSM/inter-frequency measurements. As seen on live networks, the mean period of time between the sending of the MEASUREMENT CONTROL and the reception of the related MEASUREMENT REPORT is around 3s. This is explained by: The current value of Compressed Mode activation time (1,52 s), quite high but necessary to secure the correct reception of the MEASUREMENT REPORT message by the UE
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 159/213
The fact that the mobiles need at least 1,5 s of Compressed Mode for measuring and decoding a first set of neighbouring GSM BSIC.
Remark 2: In case of handover failure, the HO decision counter (InterSystemDetectionCounter) need to be reset in order to avoid a second handover attempt to be made towards the same cell too shortly after the failure.
5.9.3 ALARM MEASUREMENTS ACTIVATION WHEN INTRA FREQUENCY MEASUREMENTS ARE EVENT BASED
DESCRIPTION
A solution based on events 2D and 2F will be used. Although being related to intra-frequency measurements, 2D and 2F are categorized in the inter-frequency event group, which helps to decrease the number of simultaneous intra-frequency events required. Besides, the fact that 2D/2F are only triggered by the Best cell of the active set allows to save unnecessary measurement reports. In [A4], events 2D and 2F are defined as follows:
QUsed TUsed 2 d H 2 d / 2
And
QUsed TUsed 2 f + H 2 f / 2
TUsed2d refers to an absolute threshold. For CPICH Ec/No based event this is set to the value of the parameter cpichEcNoThresholdUsedFreq2D. For CPICH RSCP based event this is set to the value of the parameter cpichRscpThresholdUsedFreq2D. TUsed2f refers to an absolute threshold. For CPICH Ec/No based event, the configuration of this parameter is set to the value of the parameter cpichEcNoThresholdUsedFreq2F which is a hysteresis to cpichEcNoThresholdUsedFreq2D. For CPICH RSCP based event, the configuration of this parameter is set to the value of the parameter cpichRscpThresholdUsedFreq2F which is a hysteresis to cpichRscpThresholdUsedFreq2D. H2d and H2f refer to as hysteresis parameters. They can be set to the value of hysteresis2D and hysteresis2F. (Note: For UA06 refer to section 6.3) Qused refers to as the quality of the currently used frequency. This is defined by:
In order to trigger a report, the triggering condition has to be valid for a period of time named time to trigger. This parameter is configurable for each event (the values sent to the UE are defined by the parameters timeToTrigger2D, timeToTrigger2F).
At the end, the list of configured events for alarm handover activation would be as follows (for 2D and 2F, there is no triggering condition. By default, any of the active set cells may trigger the event):
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 160/213
ALGORITHM
The Alarm criteria may be set by: Event 2D and 2F
Event 2D and 2F are managed the following way: The algorithm used to trigger alarm measurements will be based on the following principles: On reception of 2D event the RNC starts a timer. If the timer elapses until 2F is received, Alarm measurements are configured. If 2F is received while the timer is running, the timer is stopped. Use of event time to trigger parameter, so that the event is only reported once 2D or 2F is valid for a certain period of time.
2D sent 2F 2D
HO decision
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 161/213
The following algorithm will be used: The timer timerAlarmHOEvent2D to confirm alarm handover criteria is started once a 2D event is received for any of the measurement quantity (RSCP or Ec/No). If another subsequent 2D event with another measurement quantity is received, the timer shall continue and the RNC stores that both quantities fulfils their triggering condition The timer timerAlarmHOEvent2D is stopped if a 2F event corresponding to the triggering 2D is received. In case both quantities (RSCP and Ec/N0) have fulfils their triggering condition, the timer is stopped if both 2F corresponding events are received (Ec/N0 and RSCP). A change of primary (event 1D) received while the timer is running has no effect on the algorithm, except the case when the new primary has different thresholds than the previous primary cell in which case the 2D/2F events are modified with the new thresholds Once the timer timerAlarmHOEvent2D elapses, the RNC activates Alarm measurement based on periodical reporting, depending on neighbouring cell configuration. After the timer expiration and alarm measurement is setup, if the alarm criteria becomes invalid (i.e. reception of one 2F event) before the alarm measurement results are received, the alarm handover procedure is cancelled and the alarm measurement results will be ignored when received. If the alarm criteria are again met a new alarm measurement (i.e. based on periodical reporting) will be setup again. The complete decision table for 2D CPICH Ec/No triggering event is described hereafter. Alarm criteria reflects the RNC decision once the timer has elapsed:
Received while timer is running 2F RSCP 2F Ec/No 2D RSCP 2D RSCP ; 2F Ec/No 2D RSCP ; 2F RSCP 2D RSCP ; 2F Ec/No ; 2F RSCP Timer decision table
time
2D received
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 162/213
2D
2D Timer
Hard Handover Failure: If the mobile fails to synchronize to the target resource, a Hard Handover Failure message is sent to the SRNC, indicating the mobile has returned to the old channel. In such a case, in order to avoid too frequent handovers, the Alarm Criteria confirmation timer is started again.
If neighbouring measurement cannot be requested to the UE but Inter Rat HHO is allowed (for example: CM not possible with the current RAB, neighbouring cells filtered after applying IMSI criteria) or no suitable Alarm measurement is reported by the mobile within a guard timer period, a blind handover towards the blind GSM cell provisioned for the Primary cell may be performed by the RNC. When the Alarm HHO fails during preparation [USA Market - for all possible targets see section 4.10.4] or execution phase, the compressed mode pattern is deactivated and the Inter Rat or Inter freq measurements are removed and then: If the alarm criterion is still hit (no event 2F to cancel the event 2D during the HHO), in order to delay a new HHO attempt the Alarm confirmation timer is set with the value max (2D timer+TTT2D, 1800ms). At the timer expiration, measurements configuration and compressed mode activation are sent to the UE; If the alarm criterion is not hit anymore, the procedure ends.
CONFIGURATION
Regarding inter-frequency measurement, three different quantities are actually required: CPICH Ec/No: reported in events 2D, 2F CPICH RSCP: reported in events 2D, 2F So that two MEASUREMENT CONTROL messages are actually needed to configure inter-frequency events. As in [A4] specification, inter-frequency events reporting are not repeated. In order to limit the risk of loosing an event on the radio interface because of bad transmission conditions, all intra-frequency event reports are configured in RLC Acknowledged Mode. The overall structure of the inter-frequency MEASUREMENT CONTROL message is as follows.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 163/213
10.2.17 Meas. Control Common part (reporting type) 10.3.7.16 Inter-freq measurements Common part (meas quantities) 10.3.7.19 Inter-freq meas rep criteria Event 2D Event 2F
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 164/213
2D EVENT CONFIGURATION
Information Element/Group name Parameters required for each event >Inter-frequency event identity >Threshold used frequency >W used frequency Need OP MP CVclause 0 CVclause 2 Parameter Value 2d Use cpichEcNoThreshold2D or cpichRscpThreshold2D parameter If isExtendedSrbDcch3dot4k = False: 0 If isExtendedSrbDcch3dot4k = True: Upper two Bits of hysteresis2D parameter with following mapping: 00 = 0.0 01 = 0.3 10 = 0.6 11 = 1.0 If isExtendedSrbDcch3dot4k = False: Use hysteresis2D parameter If isExtendedSrbDcch3dot4k = True: Lower two Bits of hysteresis2D parameter with following mapping: 00 = 0dB 01 = 1dB 10 = 2dB 11 = 3dB Use timeToTrigger2D parameter Use maxNbReportedCells2D parameter Not needed Not needed Not needed
>Hysteresis
MP
>Time to trigger >Reporting cell status >Parameters required for each non-used frequency >>Threshold non used frequency >>W non-used frequency
MP OP OP CVclause 1 CVclause 1
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 165/213
2F EVENT CONFIGURATION
Information Element/Group name Parameters required for each event >Inter-frequency event identity >Threshold used frequency >W used frequency Need OP MP CVclause 0 CVclause 2 Parameter Value 2f Use cpichEcNoThreshold2F or cpichRscpThreshold2F parameter If isExtendedSrbDcch3dot4k = False: 0 If isExtendedSrbDcch3dot4k = True: Upper two Bits of hysteresis2F parameter with following mapping: 00 = 0.0 01 = 0.3 10 = 0.6 11 = 1.0 If isExtendedSrbDcch3dot4k = False: Use hysteresis2F parameter If isExtendedSrbDcch3dot4k = True: Lower two Bits of hysteresis2F parameter with following mapping: 00 = 0dB 01 = 1dB 10 = 2dB 11 = 3dB Use timeToTrigger2F parameter Use maxNbReportedCells2F parameter Not needed Not needed Not needed
>Hysteresis
MP
>Time to trigger >Reporting cell status >Parameters required for each non-used frequency >>Threshold non used frequency >>W non-used frequency
MP OP OP CVclause 1 CVclause 1
Remark: In order to avoid event ping-pong effect, 2D and 2F need to be triggered by different conditions. This may be achieved through: Specific 2D and 2F thresholds (as in the tables above) Same thresholds, using a hysteresis different than 0. [Global Market: Parameter isExtendedSrbDcch3dot4k should be set to False] [USA Market: If parameter isExtendedSrbDcch3dot4k is set to True the WNMS parameters hysteresis2D and hysteresis2F have different semantics on the user interface (range 0dB to 7.5dB) and within the RNC. The RNC interprets two Bits of the value as hysteresis and the other two Bits as weight. For the parameter mapping refer to section 6.3. Note that the parameter isExtendedSrbDcch3dot4k was spare in UA06 and reused for this purpose; the parameter name does not reflect the actual semantics.]
5.9.4 PARAMETERS
Name timerAlarmHOEvent2D Object/Class UsHoConf Class3
UsHoConf Class3 UsHoConf Class3 MeasurementConfClass Class3
Definition Used for Alarm handover criteria in event-reporting mode. This timer is started on reception of 2D event. hysteresis for event 2D For UA06 refer to section 6.3. Period of time during which the event condition has to be satisfied before sending event 2D Maximum allowed number of cells to report with event 2D
hysteresis2D timeToTrigger2D
maxNbReportedCells2D
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 166/213
maxNbReportedCells2F cpichEcNoThresholdUsedFreq2F
cpichRscpThresholdUsedFreq2F
UsHoConf Class3
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 167/213
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 168/213
...
M3
M4
[USA MARKET]
Following a change of primary link, it may happen that the measurement type changes, i.e. if 3G, 2G or simultaneous 3G and 2G measurements are requested.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 169/213
Name
Object/Class
FastAlarmHardHoConf per UsHoConf Class 3
cpichEcNoThreshold
cpichRscpThreshold
counter
StepDown
StepUp
Definition Threshold on CPICH Ec/N0 used in the decision process of inter system or inter-frequency measurement and hard handover Threshold on CPICH RSCP used in the decision process of inter system or inter-frequency measurement and hard handover The measurement and hard handover decision is taken when decision counter, based on CPICH RSCP or CPICH Ec/N0 criterion, is above this quantity. decision counter is decremented by stepdown when the downlink quality HHO criterion based on CpichRSCP or CpichEc/N0 is not hit decision counter is incremented by stepup when the downlink quality HHO criterion based on CpichRSCP or CpichEc/N0 is hit
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 170/213
OTHER PARAMETERS
The following parameters are used whatever the HHO reason.
Name
Object/Class
InterFreqMeasConf Class3 RRCMeasurement Class3 RRCMeasurement Class3 RadioAccessService Class3 RadioAccessService Class 3
measurementGuardTimerFdd
RadioAccessService Class 3
Definition Filter coefficient for inter-frequency Layer 3 filtering in the UE Filter coefficient for GSM RSSI Layer 3 filtering in the UE Filter coefficient for intra-frequency Layer 3 filtering in the UE This parameter indicates whether the RNC is allowed to trigger a blind rescue handover towards a GSM cell. When the RNC waits for UE measurements this timer is used as a guard timer (compressed mode may activated or not depending on UE capabilities). At the timer expiration a blind HHO towards a 2G cell may be processed. Its value is set to encompass the compressed mode duration : >=TCmodeStart + TCmodeDuration + 1000 ms. When the RNC waits for UE measurements this timer is used as a guard timer (compressed mode may activated or not depending on UE capabilities). At the timer expiration a blind HHO towards a 2G cell may be processed. Its value is set to encompass the compressed mode duration : >=TCmodeStart + TCmodeDuration + 1000 ms.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 171/213
MEASUREMENT REPORTING
Periodic or Full Event reporting may be used in this version for the intra-frequency measurements. For periodic measurement the reporting period is 500milliseconds or more.
As specified in [A4], different measurements quantities must use separate "measurement identities". Nevertheless, as the [A4] allows, they will be reported in the same Measurement Report message in order to keep the uplink signalling at the lowest level.
REPORTING QUANTITIES
The SRNC requests the following quantities to be reported by the mobiles: Cell Synchronization information which provides the difference between SFN of the reported cell and CFN as observed by the UE. This quantity is used by the SRNC in order to calculate Frame Offset and Chip offset Iub/Iur parameters which position transmission/reception time of the new cell to be added. CPICH Ec/No: the received energy per chip divided by the power density in the band. CPICH RSCP: is the received power on one code measured on the Primary CPICH. UE Transmitted Power: is the output measured power, averaged by the UE over one timeslot at level 1 Other reporting quantities are also supported by UTRAN and are also requested to the UE for tracing purposes: SFN SFN observed time difference "type 2": the relative timing difference between cell j and cell i measured on the primary CPICH; Quality measurements.
REPORTED CELLS
The 3GPP TS25.331 allows the UTRAN to configure the cells to be reported in the following way: reporting of x best cells from the active set or all the active set reporting of y best cells of the monitored set reporting of z detected cells i.e. cells measured by the UE but neither in the active set, nor in the monitored set. In this release, the UE is requested to report measurements on: the whole active set cells the 6 best monitored set cells the 3 detected cells are reported (in Full Event mode only)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 172/213
The active set is known by the UE through the ACTIVE SET UPDATE message which requests the UE to update its active set. The monitored set is defined in section 5.15 and is provided to the UE through a MEASUREMENT CONTROL message when it changes. For more details on the primary cell determination, please refer to the active set determination algorithm (Section 5.3). Note: If Detected Set cells are reported the RNC will trace this as specified in [R5]. Based on traces the neighbouring provisioning may be modified.
FILTERING
As specified in 25.331, L3 filtering is applied in the UE for the following measurements: CPICH Ec/No CPICH RSCP UE transmitted power The filtering algorithm is as follow:
Fn = (1 a ) Fn1 + a M n
with: Fn is the updated filtered measurement result Fn-1 is the old filtered measurement result. In order to initialise the averaging filter, F0 is set to M1 when the first measurement result from the physical layer measurement is received Mn is the latest received measurement result from physical layer measurements. a = 1/2(k/2), where k is the parameter received in the IE "Filter coefficient" in the Measurement Control message and in SIB11/SIB12 (if used). If k is set to 0 that will mean no layer 3 filtering. A specific value of k is provided for each of the measurement quantities, as an operator parameter. No additional filtering is applied by the SRNC.
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 173/213
Name
Object/Class
MissingMeasurement Class3
maxAllowedNumber
missedEcNoMeasurementPenalty missedRscpMeasurementPenalty
Definition Maximum number of allowed missing measurements in the message RRC Measurement Report for a cell of the monitored set. Penalty coefficient which is subtracted to the last received CPICH Ec/N0 measurement to replace a missing one. Penalty coefficient which is subtracted to the last received CPICH RSCP measurement to replace a missing one.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 174/213
5.12.2 UE CAPABILITY
The real need for compressed mode is indicated by the mobile in the UE Radio Access Capability information element, provided in the RRC CONNECTION SETUP COMPLETE message. This information element is sent on network request ("GSM capability required" indication in the RRC Connection Setup message sent from the network).
UE Node B RRC/ RACH (RRC connection Request) NBAP/ Radio Link Setup Request NBAP/ Radio Link Setup response RRC/ FACH (RRC Connection Setup (GSM capability required)) RRC/ RRC Connection Setup Complete (UE Radio Access Capability) The UE radio access capability is not reported by the UE unless it is requested by the RNC. RNC
...
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 175/213
The UE Radio Access capability information is used by the network to configure and activate compressed mode in 3 possible ways: for the uplink only for the downlink only for both In the paragraph on "procedures & messages", and as specified in 3GPP documents, it is explained that compressed mode configuration is done very early in the call process, and that compressed mode is only activated when needed.
Regarding compressed mode for GSM, in order not to configure compressed mode in every case, a set of flags indicating the frequency band of the GSM neighbouring cells will be defined and used in the RNC to determine whether or not compressed mode is needed, and for which direction. The list of flags is the following: GSM450present GSM480present GSM850present GSM900Ppresent GSM900Epresent GSM900Rpresent GSM1800present GSM1900present
Each flag indicates that there exists at least a GSM cell of the corresponding frequency band in the access network (i.e. not only being part of the GSM neighbouring lists seen by the RNC) to which handover from a 3G cell is supported by the network. Therefore, if compressed mode is needed by the mobile for that frequency band it will be configured accordingly and possibly activated by the network if the measurement request concerns at least a neighbour cell of that band.
5.12.3 METHOD
There exist 3 methods for compressed mode: Puncturing: transmission gaps are created by performing additional puncturing or fewer repetitions in rate matching compared to normal mode so that the bit rate resulting from the rate matching can be accommodated within the transmitted slots. This is a DL only method. Higher Layer Scheduling: transmission gaps are created by restricting the TFC in the TFCS. This implies that the transport channel can cope with some transmission delay. Therefore this method is not applicable to conversational services. This method is applicable to both UL and DL. SF reduction: the spreading factor of the compressed radio frames is divided by two, allowing the same number of bits to be sent in a smaller amount of time. This method is applicable to both UL and DL. NOTE: puncturing method removed from 3GPP since R5, Compressed mode will be using the following method: 1) SF/2 reduction method 2) Higher Layer Scheduling (HLS) method SF reduction and HLS methods can be configured in the UL or DL, or possibly both, for GSM or FDD inter-frequency measurements. The use of the SF/2 reduction method has an impact on the Scrambling and OVSF code used. This is further detailed in the chapter about "impacts on RRM" (see 5.12.8).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 176/213
TG pattern 1
TG pattern 2 Transmission
Transmission gap 1
Transmission gap 2
Transmission gap 1
gap 2
GSM MEASUREMENTS
Regarding GSM measurements, there may be up to 3 pattern sequences needed, depending on the "measurement purpose": RSSI measurements Initial BSIC identification BSIC re-confirmation In order to illustrate how the 3 measurements types are performed in the mobile, the following figure presents an overall view of compressed mode processes for GSM in the mobile, as specified in 25.133. The mobile is provided with GSM neighbouring cell list, contained in the Measurement Control RRC message. The "RSSI measurement process" can be seen as a sort of endless loop, intending to identify the 8 strongest cells. The "Initial BSIC identification process" intends to identify the BSIC in the list. Once being successfully identified, the BSIC is given to the re-confirmation process. The "BSIC re-confirmation process" can be seen as a sort of endless loop, intending to re-confirm identified BSIC, and maintain timing information with the identified cells.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 177/213
Measurement Control
(BSIC, BCCH ARFCN) GSM neigh.cells RSSI measurement process 8 strongest cells
Measurement Report
identification failed
re-confirmation failed
x frames
y frames
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 178/213
Once RSSI measurements are performed, the mobile should normally attempt to identified the 8 strongest RSSI, using the relevant pattern sequence. Once BSIC have been identified and reported to the network, the network may possibly make a handover decision toward a GSM target. Please refer to the chapter on [parameters] for the pattern parameters supported in this version.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 179/213
NBAP/ Compressed Mode Command (active pattern, starting CFN) RRC/ Measurement Control (active pattern, starting CFN)
NBAP/ Compressed Mode Command (active pattern, starting CFN) RRC/ Measurement Control (active pattern, starting CFN)
10.2.33 RB Setup 10.3.6.24 Downlink information common for all radio links 10.3.6.33 DPCH compressed mode info
TGPSI TGPS Status Flag TGCFN TGMP TGPRC TGSN
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 180/213
10.3.6.27 Downlink information for each radio link 10.3.6.21 Downlink DPCH info for each RL
Scrambling code change
9.2.1.42 Radio Link Reconfiguration Prepare 9.2.2.14A DL code information 9.2.2.53B Transmission Gap Pattern Sequence Code Information
Scrambling code change
9.2.2.57 UL DPCCH Slot Format 9.2.2.10 DL DPCH Slot Format 9.2.2.53A Transmission Gap Pattern Sequence Information
TGPSI TGSN
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 181/213
CM activation
Presence M Range
0.. <maxTGPS>
IE/Group Name CM Configuration Change CFN Transmission Gap Pattern Sequence Status >TGPSI Identifier >TGPRC >TGCFN
M M M
CFN
CM deactivation
Presence M Range Type and reference CFN
[Global Market - The measurements are not activated in parallel. Each GAP sequence is activated sequentially at a specified TGCFN time per measurement purpose. It means the 3 GAP pattern are not running at the same duration period.]
9.1.60 Compressed Mode Command 9.2.2.A Active Pattern Sequence Information Same structure as above.
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 182/213
9.1.3.1 Radio Link Setup Request or 9.1.6 Radio Link Addition Request 9.2.2.A Active Pattern Sequence Information
TGPSI TGCFN TGPRC
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 183/213
Scrambling code = SC
LEFT case
SF-1
SF/2
SF-1
SF/2
Scrambling code = SC
RIGHT case
SF-1
SF/2
SF-1
SF/2
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 184/213
5.12.9 HLS
[USA Market: HLS method is supported in uplink, only. I.e. dependent on the uplink bearer combination SF/2 or HLS can be used. In downlink SF/2 method is available, only.]
This chapter describes the Compressed Mode by HLS over dedicated physical channel. The gain of the HLS CM method is Does not require additional resources: o No additional power is requested for transmission at same level of protection of the user bit o No additional OVSF resources allows removal of the interference impact created by the SF/2 and thus allows increase of the overall cell capacity allows the support of RB with SF=4 obviously, avoids SF change and any new requirements for channelisation code usage DL HLS is less stringent in CEM processing capacity requirement than SF/2 Such method can be configured as the following ones: compressed mode is used when needed for GSM or FDD inter-frequency measurements [Global Market - compressed mode cannot be used for GSM and FDD measurements simultaneously] compressed mode by SF/2 reduction may be used for all kind of CS or PS services, compressed mode by SF/2 reduction method is possible for both UL and DL whenever GSM or FDD inter-frequency measurements is used, compressed mode by HLS is used for UL/DL PS I/B mono/multi services over DCH, compressed mode by HLS is used for UL/DL multiplexed PS I/B services over DCH, compressed mode by HLS is also used for certain multiplexed PS I/B + CS services see below. compressed mode method by HLS or SF/2 can be used in mixed CM method UL/DL (ex. UL HLS and DL SF/2) whatever the measurement purpose is.
HLS ASSUMPTIONS
In most of the cases, only one method (either HLS or SF reduction) may be active at a time For some specific configurations SF reduction may apply in DL whereas HLS applies in UL Compressed mode (SF/2 or HLS) is active in Cell-DCH mode only, Compressed mode (SF/2) is active with HSDPA, CMode method only applies to the DCH part of a call and not to HS-DSCH, as a consequence the associated DCH (ie SRB only) uses SF/2 for any such configuration, Compressed mode (SF/2) is active with HSUPA CMode method only applies to the DCH part of a call and not to the E-DCH part, Standalone SRB configuration: o Design choice: HLS is not applied to Standalone SRB configurations in order to keep the SRB capacity Mono-service handling: o HLS is not supported for any CS only call o HLS is not supported for PS Streaming only call o HLS is not supported for CSD64 only call o HLS is supported in both UL & DL for PS I/B x/y only call over DCH, with x/y > 8 kbps o If PS I/B only traffic is carried by DCH/HS-DSCH channel then only the SF/2 method is supported in DL whereas the HLS method is supported in UL Multi-service handling: o HLS is supported in UL/DL for multi-service calls involving a CS call: SRB + CS Speech + PS I/B x/y over DCH with x/y > 8 Kbps, Only the PS I/B TF(s)/TFC(s) are restricted during transmission with gap, o HLS is not supported for multi-service calls involving a PS Streaming session excepted if that RB combination gets a SF equal to 4 and the GBR is guaranteed, o HLS is not supported in UL for multi-service calls involving a CSD call excepted if that RB combination gets a SF equal to 4, o HLS is supported for multiplexed PS I/B x/y calls with x/y > 8 Kbps,
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 185/213
NBAP/RNSAP RL SETUP Request (RBs + CM parameters) // CM configuration provisioning // + start CM at TGCFN time NBAP/RNSAP RL RECONFIGURATION PREPARE (RBs + CM parameters) // CM configuration provisioning NBAP/RNSAP RL RECONFIGURATION COMMIT () NBAP/RNSAP COMPRESSED MODE COMMAND ()
// CM configuration provisioning // + start CM at TGCFN or CFN time // start CM at TGCFN or CFN time // stop CM configuration change // CFN time // configuration + Start/Stop CM // at TGCFN time for each // TGPSI
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 186/213
RB configuration change => CM method switching: RNC detects the CM method change CM Method Switching:
Determination of the deactivation time (CFN) for old CM method, CM deactivation command to RNC MAC-d CM deactivation command to the NodeB /UE
NBAP/ Compressed Mode Command (Stop CM at CFN: CM configuration change CFN time) RRC/ Measurement Control (Stop CM at CFN: CM configuration change CFN time )
NBAP/ Radio Link Reconfiguration Prepare (DTCH config, New CM configuration/method) NBAP/ Radio Link Reconfiguration Response
NBAP/ Radio Link Reconfiguration commit (CM activation at new CFN: TGCFN time) RRC/ RB Reconfiguration (DTCH config, for FDD, New CM configuration/method, CM activation at new CFN: TGCFN time ) RRC/ RB Reconfiguration complete (DTCH config, for FDD) RANAP/ RAB Assignment Response
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 187/213
RB configuration change => CM method switching: RNC detects the CM method change CM was not activated
NBAP/ Radio Link Reconfiguration Prepare (DTCH config, New CM configuration/method) NBAP/ Radio Link Reconfiguration Response NBAP/ Radio Link Reconfiguration commit ( no Pattern active) RRC/ RB Reconfiguration (DTCH config, for FDD, New CM configuration/method, no pattern active ) RRC/ RB Reconfiguration complete (DTCH config, for FDD) RANAP/ RAB Assignment Response
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 188/213
2.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 189/213
SRB
SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB SRB
Traffic1
PS I/B 64 PS I/B 32 CS NB AMR PS I/B 128 PS I/B 64 Mux CS NB AMR PS I/B 384 PS I/B 128 Mux CS NB AMR CS NB AMR CS NB AMR CS NB AMR CSD 64 CSD 64 CSD 64 CS WB AMR CS WB AMR CS WB AMR CS WB AMR CS WB AMR CS WB AMR PS STR 16 PS STR 32 PS STR 64 PS STR 64 PS STR 128 PS STR 128 PS STR 128 CS NB 12.2 CS NB 12.2 CS NB 12.2 CSD 64 with 3 subflows CSD 64 with 3 subflows CSD 64 with 3 subflows PS 2 I/B 32 Mux PS 2 I/B 384 Mux CS NB AMR CS NB AMR PS 3 I/B 32 Mux PS 3 I/B 64 Mux PS 3 I/B 128 Mux PS 3 I/B 384 Mux
Traffic2
Traffic3
isHlsCmMethod Preferred
Yes Yes
PS I/B 64
PS I/B 64 Mux
PS I/B 128 Mux PS I/B 32 PS I/B 128 PS I/B 384 PS I/B 128 PS I/B 384 PS I/B 128 mux I/B 64 I/B 32 I/B 128 I/B 384 I/B 64 MUX I/B 128 MUX I/B 384 I/B 384 I/B 128 I/B 384 I/B 64 I/B 128 I/B 384 PS STR 16 PS STR 32 PS STR 32 PS I/B 128 PS I/B 384 PS I/B 128 Mux PS I/B 384 PS I/B 128 PS I/B 384
Yes Yes Yes Yes (SF4*) Yes Yes Yes (SF4*) Yes Yes Yes Yes Yes Yes Yes (SF4*) Yes (SF4*) Yes (SF4*) Yes (SF4*) Yes (SF4*) Yes (SF 4) Yes (SF4*) Yes (SF4*) Yes (SF4*) Yes (SF4*) Yes (SF4*) Yes (SF4*) Yes (SF4*) Yes Yes (SF4*)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 190/213
For the DL: Following table gives the Dl AsConfs for which the default value of class 3
isHlsCmMethodPreferred parameter in MIB is YES
SRB
SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB 3.4 SRB SRB 3.4 SRB 3.4 SRB SRB SRB
Traffic1
PS I/B 64 PS I/B 128 PS I/B 384 CS NB AMR PS I/B 16 PS I/B 32 PS I/B 256 CS NB AMR CS NB AMR PS I/B 64 Mux CS NB AMR PS I/B 128 Mux PS I/B 384 Mux CS NB AMR CS NB AMR CS NB AMR CSD 64 CS WB AMR CS WB AMR CS WB AMR CS WB AMR CS WB AMR CS WB AMR CS WB AMR CS WB AMR CSD 64 with 3 subflows CSD 64 CSD 64 with 3 subflows PS 3 I/B 64 Mux PS 3 I/B 128 Mux CS NB AMR
Traffic2
Traffic3
isHlsCmMethod Preferred
Yes Yes Yes
PS I/B 64
PS I/B 128 Mux PS I/B 384 Mux PS I/B 32 PS I/B 128 PS I/B 64 PS I/B 128 PS I/B 32 PS I/B 384 PS I/B 64Mux PS I/B 128 Mux PS I/B 384 Mux PS I/B 384 Mux PS I/B 128 PS I/B 128 Mux PS I/B 128 Mux
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes (SF4*)
PS 3 I/B 64 Mux
Yes
(SF4*): When a RB combination gets a SF=4 then RNC has the possibilities: o To apply the HLS method even through for PS streaming traffic, o To downgrade the granted rate of that RB combination with a greater SF
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 191/213
5.12.10
- Incoming SRNS relocation with HLS compressed mode activated from a non Alcatel-Lucent SRNC: For an incoming SRNS relocation the DRNC shall apply the following:
If the the CM configuration checking indicates different CM configurations (CM configuration of the relocation container not the same than the one on DRNC), then: 1. The Target RNC shall stop the current CM at the UE/NodeB side for any active TGPS at the CM configuartion CFN time, 2. The target RNC is configured with its MIB compressed mode configuration/CM prefered method, There is no dynamical compressed mode configuration, since it may generate call drops, 3. The target DRNC shall start its CM at the new CFN time on the UE/NodeB side when the Alarm HHO criteria is met
See hereafter the call flow for that use case. Note: Sending the RRC measurement Ctrl to deactivate the initial compressed mode ensure a correct deactivation on UE side , in order to reduce some undecoded radio frame.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 192/213
SRNS reloc criteria reached All radio links belong to the DRN CM was activated before SRNS RANAP/ Relocation Request
SRNC relocation ends RANAP/ Relocation Request ACK Target RNC CM deactivation: Stop previous CM Methodif active for any active TGPS NBAP/ Compressed Mode Command (Stop previous CM at CM Configuration change CFN) RRC/ Measurement Control (Stop previous CM at CFN= CM Configuration change CFN)
NBAP/ Radio Link Reconfiguration Prepare ((DTCH config, CM config for GSM, CM config for FDD)
NBAP/ Radio Link Reconfiguration Response NBAP/ Radio Link Reconfiguration commit (no CM activation: no TGPS status)
RRC/ RB Reconfiguration (DTCH config, CM config for GSM, CM config for FDD, no CM activation) ) RRC/ RB Reconfiguration Complete() Criteria is reached => CM activation: Selection of the CM method Determination of the activation time (CFN) If HLS selected in DL CM activation command to RNC MAC-d
NodeB compares the new CFN of DL FP DCH frames to TGCFN to trigger CM activation NBAP/ Compressed Mode Command (active pattern, starting TGCFN) RRC/ Measurement Control (active pattern, starting CFN= TGCFN)
5.12.11
The DRNC does not perform any check regarding CM activation and the CM Configuration/method since the DRNC does only relay the CM method/configuration to the NodeB(s), But the SRNC shall apply a filtering based on the IsHlsCmAllowedOnDRNC parameter value to match the supported CM method supported on the DRNC side (SF/2 or HLS).
1) When SRNC facing an oldest DRNC version and if the CM method in use is SF/2:
- The SRNC does not need to apply any particular action on its Iur interface, follow on of the SF/2 CM method/configuration with the same TGPS to the DRNC
2) When SRNC facing an oldest DRNC version and if the CM method in use is HLS:
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 193/213
o o
At this stage the SRNC shall distinguish for the RL failure case the cause error. The RNC shall interpret for such reported Iur RL failure cause CM not supported as an indication that any CM method can be supported for the current RB combination on that DRNC,
- Receiving the RNSAP RL failure the SRNC shall not attempt to retry a RNSAP RL Setup/reconfiguration.
Without CM activation: 3) When SRNC facing an oldest DRNC version and if the CM method to be used is SF/2: - No additional action, follow on of the CM method/configuration with the same TGPS, to the DRNC 4) When SRNC facing an oldest DRNC version and if the CM method in used is HLS: - Same case as 2) but without CM deactivation, See hereafter the call flow for that use case.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 194/213
Radio links addition/reconf to the DRNS: HLSCMAllowedOnDRNC = False CM was activated before on SRNS
SRNS filtering on HLSCMAllowedOnDRNC: If HLS not supported on DRNS => CM method switching:
RNC detects the CM method change CM was activated SF/2 method selected NBAP/ Compressed Mode Command (Stop CM at CFN= CM configuration change CFN time) RRC/ Measurement Control (Stop CM at CFN:= CM configuration change CFN time )
SF/2 method selected on V6 NodeB Determination of the activation time: New TGCFN
NBAP/ Radio Link Reconfiguration Prepare (DTCH config, New CM config./method,) NBAP/ Radio Link Reconfiguration Ready () NBAP/ Radio Link Reconfiguration Commit (CM configuration activation at TGCFN time ())
RRC/ RB Reconfiguration (DTCH config, for FDD, New CM configuration/method, CM activation at new CFN= TGCFN time ) RRC/RB Reconfiguration complete (DTCH config, for FDD) RNSAP/ Radio Link Setup Request (DTCH config, New CM config./method, TGCFN time )
SF/2 method selected on oldest NodeB version Transmission of the activation time: New TGCFN CM activation command to the Node B/UE
NBAP/ Radio Link Setup Request (DTCH config, New CM config./method, TGCFN time) NBAP/ Radio Link Setup Response () RNSAP/ Radio Link Setup Response ()
5.12.12
DRNS SCENARIOS
The DRNC does not perform any check regarding HLS activation and the AsConf. Similarly, the DRNC does not perform any check regarding the activation of different CM methods in UL & DL.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 195/213
2.
5.12.13
-
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 196/213
5.12.14
UE IMPACTS
Independently of the different characteristic to assign to the UE for a SF/2 or HLS compressed mode method use and according the cell profile to be measured by the UE the 3GPP rules shall be supported on the UE side (refer TS 25.133). If a R5/R6 UE is not capable to support CM activation while HSDPA/HSUPA a fallback to DCH is triggered (see [R4] and [R6]).
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 197/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 198/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 199/213
The compressed mode is stopped immediately The measurement criteria is evaluated If the Alarm Measurement Criteria is still valid, measurements (either inter-freq or inter-system) are activated, depending on the Alarm Measurement Type
Inter-system CM
...
Trigger change. Detection of crossover from GSM to inter-frequency measurements Measurement Type is now set to "inter-freq" Current compressed mode pattern is stopped A new CM scheme is started
Inter-system CM is active. Change of trigger with crossover from GSM to inter-frequency target
RRC/ Measurement Control (2G pattern=inactive, TGPS reconf CFN, Fdd pattern=active, inter-frequency starting TGCFN)
NBAP/ Compressed Mode Command (CM Configuration Change CFN, inter-frequency starting TGCFN)
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 200/213
The subsequent RRC MEASUREMENT CONTROL messages provide the mobile with a list of inter-frequency cells to be monitored a TGPS reconfiguration CFN, at which all pattern sequences shall be de-activated. This IE has the same value as the CM Configuration Change CFN of the NBAP message below. a starting CFN for the inter-frequency pattern sequence The NBAP COMPRESSED MODE COMMAND contains a CM Configuration Change CFN, indicating the CFN at which the NodeB shall de-activate all the on-going pattern sequences. This message also contains a starting CFN for the inter-frequency pattern sequence. The procedure is applicable independently of the CM method.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 201/213
5.12.18 PARAMETERS
This chapter lists all the configuration parameters for Compressed mode, most of them being part of 25.331
DYNAMIC PARAMETERS
These parameters are not accessed by the operator. The following set of parameter is present for each pattern, being active or not.
TGPS Status Flag TGCFN active, inactive Integer (0..255) current status of the Transmission Gap Pattern Sequence Connection Frame Number of the first frame of the first pattern within the Transmission Gap Pattern Sequence. Defines whether only DL, only UL, or combined UL/DL compressed mode is used. The value of this parameter depends on the UE classmark.
UL/DL mode
O&M PARAMETERS
This list contains the parameters which are used to configure the CM function. For the parameters displayed at the OMC-R level, it is always possible to change the value. If this should occur, there is no guarantee regarding Alcatel-Lucent UTRAN performances, or interoperability with mobiles. Parameters at the RNC level Most of the parameters listed below are defined at the RNC level.
GENERAL PARAMETERS
Name Definition
YES: there exist GSM neighbouring cells of that frequency band in the access network NO: otherwise YES: there exist GSM neighbouring cells of that frequency band in the access network NO: otherwise YES: there exist GSM neighbouring cells of that frequency band in the access network NO: otherwise YES: there exist GSM neighbouring cells of that frequency band in the access network NO: otherwise YES: there exist GSM neighbouring cells of that frequency band in the access network NO: otherwise YES: there exist GSM neighbouring cells of that frequency band in the access network NO: otherwise
Granularity
RadioAccessService Class 3 RadioAccessService Class 3 RadioAccessService Class 3 RadioAccessService Class 3 RadioAccessService Class 3 RadioAccessService Class 3
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 202/213
Name
Object/Class
DlUserService Managed Object. Class 3 DlUserService Managed Object. Class 3
RadioAccessService Class 3
NeighbouringRNC
Managed Object. Class 3 DlUserService and UlUserService Managed Object. Class 3
Definition Indicates if compressed mode for GSM is allowed for this DL UserService. Indicates if the Compressed Mode for inter-frequency is allowed for this DL UserService. Indicates if compressed mode by HLS is allowed or not. Indicates if HLS is the preferred method of compression for generating uplink compressed mode gaps Indicates if HLS is the preferred method of compression for generating downlink compressed mode gaps Indicates if a ALU-DRNC is HLS method capable,
If this parameter is set to TRUE than the RNC is allowed to use simultaneous compressed mode for inter-frequency and inter-RAT measurements for this service. Simultaneous inter-frequency and inter-RAT measurements are not possible for certain RAB combinations due the enhanced compressed mode requirements. If simultaneous compressed mode is requested but not possible then the RNC uses single compressed mode as per parameter is3GHandoverPreferred. Engineering guideline: TRUE for all RAB combinations with - isHlsCmMethodPreferred=No, or - isHlsCmMethodPreferred=Yes if throughput reduction by simultaneous CM pattern is acceptable. Otherwise: FALSE
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 203/213
PATTERN PARAMETERS
A certain number of pattern sequences can be defined in Alcatel-Lucent UTRAN. For each of the pattern, the available parameters are described in the table below. Those parameters are defined at the cell level.
Name TGMP Range FDD measurement, GSM RSSI measurement, GSM Initial BSIC identification, GSM BSIC re-confirmation Integer (1..511, Infinity) Definition Transmission Gap pattern sequence Measurement Purpose.
TGPRC
TGSN
Integer (0..14)
TGL1
Integer(1..14)
TGL2 TGD
N Identify abort
Integer(1..128)
T Reconfirm abort
Integer(1..20)
The number of transmission gap patterns within the Transmission Gap Pattern Sequence. Transmission Gap Starting Slot Number The slot number of the first transmission gap slot within the TGCFN. The length of the first Transmission Gap within the transmission gap pattern expressed in number of slots The length of the second Transmission Gap within the transmission gap pattern Transmission gap distance indicates the number of slots between starting slots of two consecutive transmission gaps within a transmission gap pattern The duration of transmission gap pattern 1 expressed in number of frames The duration of transmission gap pattern 2 expressed in number of frames used as: TGCFN = (CFNx+TGCFN offset) mod 256 expressed in number of frames Indicates the maximum number of repeats of patterns that the UE shall use to attempt to decode the unknown BSIC of the GSM cell in the initial BSIC identification procedure Indicates the maximum time allowed for the re-confirmation of the BSIC of one GSM cell in the BSIC re-confirmation procedure. The time is given in steps of 0.5 seconds.
GSM measurement specific configuration [Global Market]: The following table provides preferred sets of parameters which will be used in this version:
Pattern purpose TGPRC TGSN TGL1 TGL2 TGD TGPL1 TGPL2 TGCFNoffset N_IDENTIFY_ABORT T_RECONFIRM_ABORT
GSM RSSI Measurements 8 8 14 undefined undefined 6 undefined 0 not applicable not applicable
GSM Initial BSIC Identification 3x26=78 8 14 undefined undefined 6 undefined 8x6=48 26 not applicable
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 204/213
FDD inter-frequency measurement specific configuration [Global Market]: The following table provides preferred sets of parameters which will be used in this version:
Pattern purpose TGPRC TGSN TGL1 TGL2 TGD TGPL1 TGPL2 TGCFNoffset
Remarks on pattern parameters for inter-frequency: the pattern allows at least a compressed mode-free 40ms window for intra-frequency neighbouring cell SFN decoding (the BCH has a TTI of 20ms). Therefore, the impact of compressed mode on intrafrequency measurements is very limited
Simultaneous GSM and FDD inter-frequency measurements [USA Market]: The following table provides preferred sets of parameters which will be used in this version:
Pattern purpose TGPRC TGSN TGL1 TGL2 TGD TGPL1 TGPL2 TGCFNoffset N_IDENTIFY_ABORT T_RECONFIRM_ABORT
GSM RSSI Measurements 8 8 14 undefined undefined 6 undefined 0 not applicable not applicable
GSM Initial BSIC Identification 3x26=78 8 14 undefined undefined 6 undefined 8x6=48 26 not applicable
Remarks on pattern parameters for simultaneous GSM and inter-frequency measurements: In case of simultaneous measurements two CM gaps occur within each Transmission Gap Pattern (TGP), the GSM RSSI or BSIC Identification gap and the FDD measurement gap. These two gaps are spread by applying the TGCFNoffset=3 for FDD measurements.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 205/213
ITP
mode 0, mode 1
DeltaSIR1
DeltaSIRafter1
DeltaSIR2
DeltaSIRafter2
The following table provides preferred sets of parameters which will be used in this version:
RPP ITP DeltaSIR1 DeltaSIRafter1 DeltaSIR2 DeltaSIRafter2 mode 0 mode 0 Not needed Not needed Not needed Not needed
STATIC PARAMETERS
This set of parameter is static, and not displayed at the OMC-R level. These parameters are defined at the RNC level.
Name Downlink compressed mode method Uplink compressed mode method Downlink frame type Scrambling code change Range puncturing, SF/2, higher layer scheduling SF/2, higher layer scheduling A, B code change, no code change Definition Method for generating downlink compressed mode gap Method for generating uplink compressed mode gap See 25.212, 4.4.2 Indicates whether the alternative scrambling code is used for compressed mode method 'SF/2'
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 206/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 207/213
Measurement equalization
This process consists in adding an offset to the reported measurements, as in the following formula: equalized measurement = reported measurement + Neighbouring Cell Offset The Neighbouring Cell Offset parameter is configured at the OMC-R for each GSM neighbouring cell. In the Iur case, this parameter is provided by the DRNC as the Radio Link is added. In case no valid value is provided by the DRNC, the Alcatel-Lucent SRNC uses 0 as a default value.
Measurement filtering
Following the measurement equalization, the following condition is evaluated. When not fulfilled, the corresponding cell is considered as not eligible. The following criteria are evaluated on the measurements reported by the mobile (i.e. not equalized) GSM Carrier RSSI > minimumGsmRssiValueForHHO
5.13.2 PARAMETERS
Name Object/Class
RadioAccessService Class3 GsmNeighbouringCell Class3
minimumGsmRssiValueForHO gsmCellIndivOffset
Definition Threshold on GSM carrier RSSI for inter-system target cell eligibility Offset used for "target cell equalization"
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 208/213
5.14. FDD TARGET CELL CHOICE INTER FREQUENCY RADIO CRITERIA 5.14.1 DESCRIPTION
At each measurement period the mobile reports the measured cells even if all neighbor cells are not measured. By selecting the first cell reported by the mobile which fulfills the IMCTA criteria (the selected cell may not be the best cell on a given Carrier), the compressed mode duration is limited. On reception of inter-frequency measurement report, if a decision for handover is made, the RNC applies a 3-step process for the choice of the target cell: Measurement equalization Measurement filtering Target cell identification
Measurement equalization
This process consists in adding an offset to the reported measurements, as in the following formula: equalized measurement = reported measurement + Neighbouring Cell Offset The Neighbouring Cell Offset parameter is configured at the OMC-R for each FDD neighbouring cell. In the Iur case, this parameter is provided by the DRNC as the Radio Link is added. In case no valid value is provided by the DRNC, the Alcatel-Lucent SRNC uses 0 as a default value.
Measurement filtering
Following the measurement equalization, the following condition is evaluated. When not fulfilled, the corresponding cell is considered as not eligible. The following criteria are evaluated on the measurements reported by the mobile (i.e. not equalized) CPICH Ec/No > minimumCpichEcNoValueForHHO and CPICH RSCP > minimumCpichRscpValueForHHO
5.14.2 PARAMETERS
Name Object/Class
UMTSFddNeighbouringCell Class3 DlUserService Class3 DlUserService Class3
Definition Offset used for "target cell equalization" CPICH Ec/No threshold for interfrequency cell eligibility CPICH RSCP threshold for interfrequency cell eligibility
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 209/213
5.15.2 ALGORITHM
If SIB11AndDCHNeighbouringFddCellAlgo parameter is set to classic, the Fdd neighbour selection is done by the RNC and the number max of UMTS Fdd neighbor cells to be put in SIB11 is limited to the first 16 Intra Freq and the first 15/16 inter Freq cells. For the Measurement Control message building, all Fdd neighbour cells (intra freq/inter freq) are put in the message. For inter Rat neighbor cells the selection depends on the sib11OrDchUsage parameter value. If SIB11AndDCHNeighbouringFddCellAlgo parameter is set to manual, the neighbor number flexibility (i.e. any combination of intra-freq, inter-freq and inter-RAT neighbor cells allowed in SIB11 within a global limitation of 47/48 [Global Market] or 96 [USA Market] neighbor cells) applies (all neighbor cells may be selected by the operator). Each neighbor cell will be selected according to sib11OrDchUsage parameter value. The SIB11 neighboring filling based on flagged cells is processed in the following order: Intra Frequency cells, Inter frequency cells and Inter Rat cells. The selection ends when all requested cells are encoded or the encoding fails or the number max of neighbor cells is achieved.
Note: The System block information 11 is limited to 16 segments. The RRC description ([A4]) defined a message format which may exceed the 16 segments when too many IE are set. The Alcatel-Lucent RNC controls the size of the SIB11 message during the ASN1 encoding of the data provisioned at OAM level. An Alarm is sent by the RNC to the OMC-R. Note: SIB12 follows same rules as SIB11 to select cells and set parameters in the message
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 210/213
5.15.3 PARAMETERS
Name Sib11OrDchUsage Object/Class gsmNeighbouringCellList Definition Enum (sib11AndDch,sib11Usage,dchUsage) Indicates if the cell has to be put in SIB11 and/or the Measurement Control messages. Enum (sib11AndDch,sib11Usage,dchUsage) Indicates if the cell has to be put in SIB11 and/or the Measurement Control messages. This neighbour Fdd cell parameter is valid if SIB11NeighbouringFddCellAlgo parameter is equal to manual. Enum (classic, manual) classic: The first 16 UMTS Fdd neighbour cells in the Fdd neighbor list (Intra Freq or Inter Freq) are selected for SIB11 manual: The UMTS Fdd neighbour cells in the Fdd neighbor list (Intra Freq or Inter Freq) are selected for SIB11 and/or Measurement Control according to Sib11OrDchUsage value.
Sib11OrDchUsage
UMTSFddNeighbouringCell
SIB11AndDCHNeighbouringFddCellAlgo
FDDCell Class 3
6.
6.1.
ALCAP AO ARFCN ATM BCCH BSIC BTS CAC CAS CFN CIO CM CN CPICH CRNC CS CSD DCCH DCH DRNC DHO
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 211/213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 212/213
6.2.
DEFINITIONS
Empty chapter.
6.3.
Hysteresis (1a, 1b, 2d, 2f) WNMS value: 0dB ASN.1 value: 0 ASN.1 value (bitmap): 0000 UA06 meaning RRC value - Hyst RRC value - W
0,5dB 1 0001
1dB 2 0010
1,5dB 3 0011
2dB 4 0100
2,5dB 5 0101
3dB 6 0110
3,5dB 7 0111
4dB 8 1000
4,5dB 9 1001
5dB 10 1010
5,5dB 11 1011
6dB 12 1100
6,5dB 13 1101
7dB 14 1110
7,5dB 15 1111
WNMS Hysteresis parameter is shared between Hysteresis (lower 2 Bits) and W (upper 2 Bits) 0dB 1dB 2dB 3dB 0dB 1dB 2dB 3dB 0dB 1dB 2dB 0,0 0,0 0,0 0,0 0,3 0,3 0,3 0,3 0,6 0,6 0,6
3dB 0,6
0dB 1,0
1dB 1,0
2dB 1,0
3dB 1,0
Notes: The value mapping was introduced when late during UA06 development it was detected that the weight parameter is not available as operator modifiable parameter and it was no longer possible to add it as separate parameter. As activation flag for the hysteresis/weight split the spare parameter isExtendedSrbDcch3dot4k is used. The parameter name does not reflect the actual semantics It is assumed that the restricted value ranges for hysteresis and weight are acceptable. In a later release the hysteresis parameter will again have full value range and a separate weight parameter will be introduced. Name Object/Class
RadioAccessService Class 3
isExtendedSrbDcch3dot4k
END OF DOCUMENT
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/SYS/DD/0054
08.08/EN
Standard
09/Oct/2008
Page 213/213