UMTS Radio Mobility

Document number: Document issue: Document status: Date: UMT/SYS/DD/0054 11.06/EN Approved_Standard 17/Sep/2010 External document

Copyright 2009 Alcatel-Lucent, All Rights Reserved Printed in France

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.

UMTS Radio Mobility

PUBLICATION HISTORY
17/September/2010 Issue 11.06 / EN, Approved_Standard • Standard edition, no remark received.

03/September/2010 Issue 11.05 / EN, Approved_Preliminary • • Correction on 81204 - Dual cell Hsdpa operation chapter Update after review.

04/May/2010 Issue 11.04 / EN, Draft Minor correction on §1.2. CR DCTPD00265749: describe restriction in case of Relocation UE Not Involved from UA7.1 to UA6.

07/April/2010 Issue 11.03 / EN, Draft Introduction of the following feature: • 81204 - Dual cell Hsdpa operation

23/March/2010 Issue 11.02 / EN, Draft Introduction of the following feature: • 81213 - Load balancing between HSPA carriers

28/January/2010 Issue 11.01 / EN, Draft Introduction of the following features: • • 81436 - Mobility between UMTS and LTE - Cell reselection 104489 - LTE to UMTS HO

04/September/2009 Issue 10.02 / EN, Standard Standard edition after review
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 2/244

UMTS Radio Mobility

03/July/2009 Issue 10.01 / EN, Preliminary New version for UA07.1; Introduction of § previously in Traffic management FN; reorganization of redirection chapters

29/June/2009 Issue 09.05 / EN, Standard Standard Edition

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 3/244

UMTS Radio Mobility

CONTENTS
CONTENTS..............................................................................................................................................4 1. INTRODUCTION ...............................................................................................................................14 1.1. 1.2. 1.3. 1.4. OBJECT ....................................................................................................................................14 SCOPE OF THIS DOCUMENT ........................................................................................................14 AUDIENCE FOR THIS DOCUMENT .................................................................................................15 DEFINITIONS AND SPECIFICATION PRINCIPLES.............................................................................15

2. RELATED DOCUMENTS .................................................................................................................15 2.1. 2.2. APPLICABLE DOCUMENTS ...........................................................................................................15 REFERENCE DOCUMENTS...........................................................................................................16

3. DEFINITIONS & CONCEPTS ...........................................................................................................17 3.1. NETWORK ARCHITECTURE..........................................................................................................17

3.2. 3GPP BASIC PROCEDURES..........................................................................................................18 3.2.1 Soft handover................................................................................................................18 3.2.2 Softer handover ............................................................................................................18 3.2.3 Hard handover ..............................................................................................................19 3.2.4 Cell reselection .............................................................................................................20 3.2.5 SRNS relocation ...........................................................................................................20 3.2.6 Radio Link Reconfiguration...........................................................................................21 4. MOBILITY CASES............................................................................................................................22 4.1. SOFT HANDOVER INTRA RNC .............................................................................................24 4.1.1 Description ....................................................................................................................24 4.1.2 Applicability ...................................................................................................................25 4.1.3 Parameters ...................................................................................................................25 4.1.4 Access Network impacts...............................................................................................25 4.1.5 Core Network impacts ..................................................................................................25 4.2. SOFT HANDOVER INTER RNC .............................................................................................26 4.2.1 Description ....................................................................................................................26 4.2.2 Applicability ...................................................................................................................28 4.2.3 Parameters ...................................................................................................................28 4.2.4 Access Network impacts...............................................................................................28 4.2.5 Core Network impacts ..................................................................................................28 4.3. SOFTER HANDOVER ............................................................................................................29 4.3.1 Description ....................................................................................................................29 4.3.2 Applicability ...................................................................................................................29 4.3.3 Parameters ...................................................................................................................30 4.3.4 Access Network impacts...............................................................................................30 4.3.5 Core Network impacts ..................................................................................................30 4.4. CELL RESELECTION IN “IDLE MODE”..................................................................................30 4.4.1 Description ....................................................................................................................30 4.4.2 Applicability ...................................................................................................................30 4.4.3 Algorithm.......................................................................................................................30
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 4/244

......................2 Neighbouring cells measurement rules when using absolute priority ..3..................55 4...44 4.................1........................................44 4.............51 4........................................ 2G TO 3G HANDOVER FOR PS DOMAIN ....................5.....................................5.........56 4....................................................47 4......5 3G to E-UTRAN case ...6............................................53 4..................7 Core Network impacts .............4.....3........2 Applicability ...........5.....................44 4.................44 4......................3............4 Cell ranking criteria .................................................................................................3.55 2G TO 3G HANDOVER FOR CS + PS DOMAINS ......................1 Dataflow ..............................31 4....................39 4...............51 4....................53 4....2 Relocation Request Rejection .....................5 Parameters .....................3 Algorithm.................................................3 Algorithm...................................56 4..1 HO Decision Process...............47 4........................4 Parameters .....................................6..........................................................3...................................................................................................................................6............55 4............3.....5...............................................2 Applicability ...............................................1 Relocation Request Message structure.......................4..............................................6 Core Network impacts ...............................................33 4...........................5..................................53 4................................................6 Core Network impacts ....................6.......6......................3 At GSM neighbouring cell level ................................................................................................................................................4 Failure cases.....51 4................39 4.........................................6....2 Inter-RNC case ..6....................50 4........9...58 4.................................6.............3 Relocation rejected by target RNC ...................................................6...51 4..................47 4.................... 2G TO 3G HANDOVER FOR CS DOMAIN ...............................3 Algorithm.........................33 4...1 Neighbouring cells measurement rules ................2 Target resource description ..........2 Applicability ...5.............4.34 4...................................................................52 4............3 At GSM neighbouring cell level .1 At UTRAN/FDD cell level..................... 4............................6..............................55 4.......9.1 at UTRAN/FDD cell level ..............9...................................3....................................................52 4.................................................4..........1 Description ....................................................................31 4.............47 4...........................................4........6...............................47 4......................................40 4............39 4.....3.52 4.....................1 Intra-RNC case ........53 4..................4...........................................................32 4........5......................................2 MeasurementS configuration.........................................39 4..............1.6 Access Network impacts.....................39 4................................................................................6 Dual cell hsdpa case.......... 3G TO 2G HANDOVER FOR PS DOMAIN ..................................................................5 Cell ranking criteria when using absolute priority ................................. CELL RESELECTION IN “CELL FACH AND CELL/URA PCH MODE” ..1...............6.......9............4.............................................43 4.1......................3.............5......3..........................................................................................4..............................................................................9.......................3 Target resource allocation in RNC .........................................5 Integrity .................1 Description ............7.............6....................................................................1 Connection Release ............4......47 4.............................................................................................6 Dependencies with GSM ............................3.................................4 CipherinG...4..3...................6....35 4.........................................58 4......7 Use of Default Configuration .......45 4......................................................................................................5.........4................6.................3...3...............................44 4.........................................4...................................3..1...5..............................6..54 4.....................................................4............................................5..................................1....................................56 4......................4......................4.1..................................5........................................................3 Criteria S.......................................................................................4...............58 4.......4.. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.7 Overall cell reselection process when using absolute priority ...............................................................47 4................44 4...............................38 4........6...........5.............39 4.....................................4 2G to 3G case.......2 return on old channel ..................4..............................................3 3G to 2G case.......................6..................4 Parameters ..35 4....6...........9.......................................................................5................................................5 Access Network impacts.8...............................................50 4...............................5 Access Network impacts...............58 Passing on or copying of this document............................................4.4..............2 At UTRAN/FDD neighbouring cell level............................................................4..............6......................1 Description ....................................1....2 At UTRAN/FDD neighbouring cell level..........................................................................................5...........................3....6 Overall cell reselection process..............4........5....06/EN Approved_Standard 17/Sep/2010 Page 5/244 ..............................................................................UMTS Radio Mobility 4.......................................................................33 4...........................................

.3 Target Cell Choice ..1 Description .........................10........................................................59 4...................1 HO Decision Process.......................................10......................................59 4......................................................................12.......................7 Target cell choice...............................76 4..........................................3.11...67 4.....................3..................................................................4 handling Unsuccessful cases .......................................11.......................................................................................13.....................................76 4.............................................................................11..........................................................6 4.3...4...................................................2 Relocation Request Rejection ......................................12................................................................................................3 Successful Class B case ............12...........3..2........................................77 4............77 4......................................................................1 Description ........10.......................1...............11................................4 Parameters ..........12..................................78 4.....................................................................................................3 Target Cell Choice ..............................................74 4.................70 4.......................................................67 4.......................................................................................1 target cell synchronization failure .............10...........................................81 4...................................61 4........12......................11...........................................10.............................70 4..61 4.....81 Passing on or copying of this document.......................1 Description .........12..76 4.....................................59 Access Network impacts..........13.........................................2 Algorithm.............................9........1 Dataflow ..............................5 4.................69 4...................................11...3..10............................3 4...2.............................12.......................................74 4.......................................61 4...............................................11..................9............................................................................................2....................................................1 Relocation rejected by target RNC ...2 MeasurementS configuration..........................................................5 Access Network impacts.............4.......................77 4..65 4...........................5 Access Network impacts.......................................................1..................................................61 4......11....................3 Algorithm....2...................................11.................1 HO Decision process ...................................UMTS Radio Mobility 4........................2....75 4................................................................9..........................................................2 Applicability ...........58 Failure cases.......................................... 3G TO 2G HANDOVER FOR CS+PS DOMAINS.........................................61 4.58 target cell synchronization failure .....1 Description ........................10..........9...........................................2...70 4.......7 CS FALLBACK.........78 4........................................10..........................................13..................10...............61 4.............................................3....................................... use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11........12...........................................13............................................3..2 Relocation Preparation Failure .............................1...............................................................................................................................1......6 Access Network impacts................................................................................................12...................................2 Successful Class A/DTM case ....................................................................................................63 4.........................1 General ..76 4.................................12.......................58 Parameters ...............11....................10.....9.............................................1 Relocation Request Message structure..............6 Core Network impacts ....................5 Integrity ......62 4........................................................3...............................................61 4...........8 Performance Management .......................................................2 Applicability .........2 Applicability ..4......................63 4...........................70 4.....................4 CipherinG.................................... 4G TO 3G RELOCATION FOR PS DOMAIN .......................................................10.............................................................12.....11...................................................................................................................................................70 4..6 Core Network impacts .........70 4..........73 4......................... 3G TO 2G HANDOVER FOR CS DOMAIN ......................................................3 Algorithm.................................1 HO Decision Process............63 4............................3 Failure cases..........................................1...59 4......10......................................................................12........5 Parameters ........................................63 4............12...........................12.........................................7 Core Network impacts .1 General .....12............................13....1 4.....70 4....63 4.......3 Target resource allocation in RNC .......4 Parameters ...............75 4...................11...............4 Failure cases.................10...........................................................................................13.9...................................11..........70 4....................2 MeasurementS configuration.........................6 Dependencies with LTE.....1.............................................................................4 4....3.....................................................70 4............63 4..............................................10................3 Algorithm............................. INTER-FREQUENCY INTER-RNC HANDOVER WITHOUT IUR.......................................................................70 4.....3............................78 4...81 4.......................81 4..................2 MeasurementS configuration.......................59 Core Network impacts .......................62 4............................................73 4........................06/EN Approved_Standard 17/Sep/2010 Page 6/244 ...13...........................................11....................12..

.............................................................81 4.....................87 4..................2 Over the Iur...82 4...........15............................................................................ SRNS RELOCATION – “UE NOT INVOLVED” .....................3........................................................95 4.....................13....................1 Description ......95 4.........6 Core Network impacts .................... REDIRECTION FEATURES FOR TRAFFIC SEGMENTATION ...................................................14......................................UMTS Radio Mobility 4.....................................88 4.............89 4.....................1 reception of measurement report measId 1 ...........93 4........94 4......16...........................3 Algorithm.......................83 4......1.......................................................................................14............................93 4.......................4 From DRNC TO SRNC................................................14......3...............................................................16..............................16.......................17.........................................2 Applicability .................3 choice of target cell.........1 HO decision process.....16...................................81 4...............15............1 HO decision process..........89 4..1 Description .................................14.......................3....................4 Parameters .........87 4.........................16........................................................................84 4.................................2 From SRNC TO DRNC....................................................................................14........................................................................................14...16............90 4..3.............................................................................89 4..........5 Access Network impacts................................................14...............................93 4................................15..1.....................17.........18...................................3 Algorithm................................................14........................16.............8 Performance management .....14.......................88 4................3 Algorithm................................. INTER-FREQUENCY INTRA-RNC HANDOVER.................................................................................................5 Parameters ...............................................2 reception of measurement report measId 16 ......18......................7 Core Network impacts ....................... use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11..................16..................................1 General ................................................................1......................1 Description .....................3 HO decision ..........84 4................................84 4...17.................87 4....................................14............................................82 4..................................................................................87 4....................1 General .....................................94 4........................................94 4...................3.......................6 Access Network impacts.....3 Target Cell Choice .........82 4.......................13.........6 Access Network impacts...............2 Measurements configuration .......................................95 4............................3...14................17.......................................15..........................2 Applicability .95 Passing on or copying of this document................................3 From DRNC TO DRNC................1....17........94 4.87 4....................84 4..............................................................................................................83 4............................15...............94 4......5 Access network impact .....................................................17.............83 4.............16.1 Description..................................................15.................3 Algorithm.....82 4.............................................................15............................................3....................95 4...........................5 Parameters ...4 Failure cases....16............................94 4......................................14......................................................82 4....................3.....................84 4........1.......16............................................92 4.............................8 Performance management ........................3............................93 4......................................................................................................................3........................................................87 4.................................15.............................................2 Measurement configuration .........................................................................4 Failure cases..........3 choice of target cell........................................3...................................................1 REDIRECTION AT CONNECTION SETUP (iMCRA step 1) ...............................................................................................................................1..............................................................16............................16..............82 4..........................1 Description ............ INTRA-FREQUENCY INTER-RNC HANDOVER WITHOUT IUR......................................13.................................................13..88 4..........1...................88 4..6 Access Network impacts.............................................15..83 4........................18...........94 4....................................................1 Iur interface status .....................15....2 Applicability ...................................95 4........................3.......................15.....6 Core network impact.....................15................................85 4....2 Applicability ................................................................................3............................................................................3.........................87 4...................................................................81 4......15..............95 4................82 4....................06/EN Approved_Standard 17/Sep/2010 Page 7/244 ..16........................83 4..........................16..........................................16..........95 4.........................................................................................4 Parameters ......................................13............7 Core Network impacts ..................................................................................................................................17.....................2 Measurements configuration ..............4 Failure cases.......................................15....... INTER-FREQUENCY INTER-RNC HANDOVER WITH IUR AND MEASUREMENTS.5 Parameters .......................................................94 4........................7 Core Network impacts .........................................................

...................................................3 Algorithm..............................................18....18................................ 121 4..................99 4............................2.18................1.......................................3.....3 Redirection Type = Preferred FA......................................... 121 4..........3......................... 121 4.........5 Performance management ...............................................................3..........................................18...18.18....1 Redirection Type = UE capability only.......................................1...........1........3......... INTELLIGENT MULTI CARRIER TRAFFIC ALLOCATION (IMCTA) ................................1.......................................5 Redirection Type = None........................................3 Algorithm........................................................................................................................1.............3 Algorithm.............................3. 122 4.......4 Parameters ..................99 4.... 115 4...............18...............................................4........97 4.....5 PRIORITY BETWEEN RRC REDIRECTION FEATURES .............................................................1.................................................................... 115 4......................................................................1...........................5 IuR Aspects .......................................4 Redirection Type = CAC.2 Redirection Type = UE capability and establishment cause ...............................97 4................. 108 4.3.......................................2................1...........................18.................................................................................3............................................................................................................................................1............................................19.........4 3G2G REDIRECTION BASED ON CELL LOAD..................18......................98 4........... 104 4.....................................1.............................18...........2 Hard Handover .............1 Description....6 Access Network impacts..................................4..........................5...2.............1.........................18.........................4 SRB Aspects.......3................19............................19...................................................... 125 4........1 Description ...3....1....4 Compressed Mode .......................19...................4 HSPA Load .......................2 Interaction with follow-on / Subscribed Traffic Class:......19.....................................................18.................................19......3..................18........................................18...........1..............3..........................2........................... 103 4..........7 Core Network impacts ........3 Emergency calls: ...... 119 4......2...........06/EN Approved_Standard 17/Sep/2010 Page 8/244 .......................................................................18......................2 Aplicability .3........ 115 4.......6 Messaging ............................2 3G2G REDIRECTION AT RRC ESTABLISHMENT FOR SPEECH CALLS.....................................97 4................................ 119 4...3 SRNS Relocation......................................................19..............1 description......................................................................................... 126 4...2 Apllicability ......................................................................................................................................18.4 Parameters ......... 109 4.1 Description.........5.................. DUAL CELL HSDPA OPERATION .......................19............................19......................................................... 128 4..............2........... 108 4.3.....................................................3..................97 4...3 Uplink Aspects .......... 108 4........................ 127 4.2 Primary Link Change ..18............................. 127 4......................................................... 127 4.....99 4..........2 Algorithm......................19...19.....................18.......................................................................................18.................2...................4....19...........18......18....................19...... 125 4.......................................................1....19........................5 Performance management .......................3 EMERGENCY AND PRIORITY CALLS.. 111 4........................18...........................................2...... 125 4........3.......... 129 Passing on or copying of this document...............................................................3 Algorithm......19...1..........................18................................................................3..........................1......... 122 4.......................19..2..........................3 Algorithm....5 Parameters ............................................. 119 4.......................19.............. 111 4.....................1...........................1 Description.............................3.18................3.................. 128 4.........4 Parameters ................................. 122 4.......... 118 4.........................................................................19............ 116 4............ 102 4.4............ 104 4............... 122 4... 104 4.......................4 Parameters ...20.......3............. 128 4...........4......................3....................... 114 4........................................1 Interaction with Cell_FACH: ......... 111 4...3...............1........................18.......................... 120 4....................5 Performance management ..................18.............................2 Applicability.........2..........2 HHO from DC to SC/R99.................................19.....................18...........3..............................19........................1 Active Set Update............1...............18....................................3.. 104 4...................... 110 4...................................................18............................18.................3....................2...............1 Description....18.........18........................................3.........................................................1......2 Applicability.. 128 4.............4 failure cases:....1 Soft Handover.............................. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11..........................................UMTS Radio Mobility 4.......................... 125 4..... 126 4... 120 4........1 UE Involved .........................18...............................18...................................................... 113 4.20.... 111 4...........18...............................................................................1 HHO from R99/SC/DC to DC .....................................................2 UE Not Involved....5 Initial Power on Redirection..2 Applicability......... 119 4.................................3...........................................18................... 128 4.................................

................................ 152 Passing on or copying of this document..........4 Neighbour Cells Selection for Measurement Reporting .............3.....................20.....................................20..1 iMCTA triggers...................20.. 148 4................... 147 4...............................8.......................................4 iMCTA load based HO developments [USA Market]...................2 iMCTA Feature activation ...............6........4. 139 4................1.................................1 Intra-frequency mobility ................2 Crossover between iMCTA triggers or with others procedures................................2 Iur management.. 133 4.........5 Performance Management .....1.8..1... 137 4......20..1 iMCTA trigger = SERVICE .4..............3........................ 133 4...2 IMCTA Exit...............................................1 Deployment scenarios .........................2 Redirection at connection setup .............. 152 4...7..........3 [USA Market] target FDD cell Load iMCTA load based HO criteria (used for CAC and Alarm): .... 145 4. 147 4..2 IMCTA trigger is CAC FAilure........21...............21....................................20.................... 134 4..........20...... 139 4......... 149 4...........2 iMCTA trigger = CAC FAILURE ................... 150 4........................................ 146 4..................3......................................... 138 4.......................1.........5 IMCTA Service Segmentation Priority Table definition .......... 136 4............21......................21........6.......................... 147 4...... 146 4......8......... 149 4..20...............20......... 143 4..... HSDPA AND HSUPA MOBILITY .....3..........20.......................2................5 Target 2G Cell eligibility.....1 Service Segmentation Option Definition...8...............................3.... 131 4..20..........UMTS Radio Mobility 4........................ 148 4.................................................................3 Neighbour Carriers Selection ....................................................................2..............2.3.............. 131 4.. 147 4....... 135 4...............2 Applicability ... 129 4....2..................................................4.... 140 4.4..........3...............2 HSDPA on existing layer ...............20.................1....8...................20.................21..........................2. 134 4............................................. 131 4.............................21...................1 HSPDA on dedicated layer....06/EN Approved_Standard 17/Sep/2010 Page 9/244 ......3 2G Inter RAT management ................................ 131 4......2 Originating Fdd Cell eligibility ... 141 4.........4........... 141 4...........3 iMCTA Service Priority Table definition.................20......................................20.............................. 144 4............................................ 144 4.......20.................................................1.....3......................................1....................................7 iMCTA Hard handover processing or iMCTA exit . 150 4.3..................................3 iMCTA trigger = ALARM .................... 139 4...................1.1 IMCTA HHO processing ................4..............21....1 cell load indicators ............................2 iMCTA Alarm and CAC Priority Tables definition ........3......20........21................. 148 4...............2 Service Handover Option Definition ...................................... 137 4..1 Description .................2.....1.............. 140 4...................................................20..........................4.20...................................... use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.........20..............................................................2............ 134 4....4 iMCTA Service Type definition ..........2.......20....2..........20......3...............3......2.....................2 iMCTA trigger = CAC FAILURE ............2 Applicability .4 Inter-system mobility.......... 136 4......................................8 iMCTA Cell load criteria .....3.. 132 4................... 135 4......................................20...3.....................................3.................2.4...................6 IMCTA Service for Traffic Segmentation Priority definition ...3.......................................20..................... 146 4................................................. 144 4..........20...1........1.......2.......2.......................20...2....................2....................4 Target Fdd Cell eligibility (used for Service).....21....3...........1 iMCTA Options ................4.........................................................3 Algorithm................................................................................2..........7.....................1........................1 Management in Cell HSxPA .........................................................4 Parameters ......................20............................20.4...........................6 Target Cell Selection upon Measurement Report ..20............................. 132 4..........................1 iMCTA trigger = SERVICE .20..3......21... 148 4.........2 compressed mode .......................................20...............................................................20..............................................................21...........................8.6 Target 2G Cell color definition ........... 133 4....................................................20...................................20...3 Inter-frequency mobility .20..20.................... 138 4................................................ 132 4..............20..........1 Main functional steps ................................................1..3 HSDPA Traffic Segmentation option definition.....1.................20...6..........5 Compressed mode and measurement configuration .......................................................................... 141 4......20..................................3 IMCTA trigger is Alarm ...........3.........2 iMCTA Priority Tables.............................3 HSDPA and HSUPA call mobility procedures ......................................... 134 4.......20.......20....3....1 IMCTA trigger is Service..............20...........................21.......................................... 140 4.....................................................................3....2.............3........................................20................................. 139 4................3........................................20..............2....1 iMCTA Priority Table definition: General aspects........1....20............ 134 4..................................20...............................1............ 133 4.......3..............3 iMCTA trigger = ALARM ..............................................................................................................3........2....................4..... 149 4.......3......................20.........................

..........................................................................................................................22.........................23................................................................................................................. 167 5.......6 Algorithm...................................4... COMMON PROCEDURES ................23......................... 176 5.................................................................................................................................................. 152 4......3 1C event configuration....5 4...........1 Description ................. 177 5.....................4.............................2...............2 Inter RNC Case ......................................................3...............................................4 1E event configuration...................... MOBILITY IN CELL_PCH AND URA_PCH RRC STATES .............................................. 163 4.1 Radio Link color ..................... 164 5......................UMTS Radio Mobility 4........4 Events 2D............2.....................................22........................ 6A.........................5 Access Network impacts....23.....................................3................................. 169 5..........2..............................3..............................2..............2.....................1 At UTRAN/FDD cell level.......2 Applicability ...........2...4............. 153 4......1 Description of event-triggered reporting measurements based on relative thresholds .................................................................................4..........................2.................... 165 5...... 156 4.................................2.....................................21................. 161 4........................6 Core Network impacts ....................................................3 Parameters for periodic reporting mode ..............4............................................2 Enhanced Algorithm for periodic reporting mode .............................. 178 5.................................4 Parameters ........4.. 166 5........................22........ 178 Passing on or copying of this document..................................................22........1 Cell Reselection Criteria when HCS is used . 1E.............. 152 Parameters .....2 Applicability ............... HCS: CELL RESELECTION CONTROL IN A HIERARCHICAL CELL STRUCTURE [GLOBAL MARKET]......23..............................................................................................................................4..3 4...... 170 5......3...22..... 1J .. 168 5.......... 167 5.............3....................23................................3 Event 1D .............3.........................1 Event 1A.............. 161 4.... use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.............. 173 5..........3......................................................1 Description ....................................3 feature interworking .........................................................................................21.........................................3...............................4......................................21... 166 5.............................2.....................................1 Description .........................................................2.................................. 163 5....... 155 4............3........................................................... 157 4.......................3............................4..........................................................................3................................................................... 1F .............23.3 Algorithm......... 155 4.... 159 4................................................................................................... 158 4................................. 168 5................. 152 Access Network impacts......................................................1 1A event configuration.................... 171 5......................................4 4............................................................................3.......................4.3............3....2 configuration .........................................3....... 164 5.... 168 5..........................................3.....23...................... 171 5......2 At UTRAN/FDD neighbouring cell level.....................................................2.......................... 176 5................. 163 4...............22.................. 163 4.........2 Event 1B...................................................................... 155 4.............4...4..........................2... 167 5.................................. 152 Core Network impacts ....... 161 4......... 153 4......3 Algorithm..................................... 164 5......4..................................................................1................................................4...................21..23.23..........2. 168 5........... 168 5...................................5 Access Network impacts......................................................2 Measurement Control Failure ...........................2................................ 164 5............... PERIODIC MEASUREMENT REPORTING MODE........................................... 168 5................................................. 174 5..............................................3......4 Parameters ...................................................................................................3..............6 Core Network Impacts ....22...........................2....23.............................................3 At GSM neighbouring cell level ......................2 SRLR blind window.2.......................... 166 5...2...........................4 Parameters ..............2 Description of event-triggered reporting measurements based on Absolute thresholds .............1 Common ID procedure handling...........................................3 Algorithm....................4 Configuration ..........................3............ 168 5....................................1 Algorithm for periodic reporting mode................ 155 4.................... 2F.................3.....4...2 1B event configuration..............2.......................................... 1C.. INTRA-FREQUENCY EVENT TRIGGERED MEASUREMENT REPORTING MODE .......3..................................................23........................................................2..............................................................4 Case of intra-frequency Event-Triggered Reporting mode.....3 Summary ...23.....06/EN Approved_Standard 17/Sep/2010 Page 10/244 .................. 6B ................................................................................................2.. 156 4.......... ACTIVE SET MANAGEMENT.. 156 4.2............

.................................................................................... 189 5.............4 6B event configuration... 181 5.........................06/EN Approved_Standard 17/Sep/2010 Page 11/244 ... 191 5.............................. 201 6.........4.............3...........................3 Configuration ..............1....................2 Other Parameters ............................................ 182 5....1 2D event configuration........................2...........................2 Case of intra-frequency Periodic Reporting mode......2 Alarm measurement activation with periodic Intra Frequency measurements................................. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.............1 Configuration..............................................2 Applicability ..........1 Activation/Deactivation ................. 187 5..............................1........................2 Algorithm................2 Measurement reporting................. 208 6...........................1.................... 185 5............................. 196 6............. 182 5........................................................... 202 6..7.3 Configuration for inter-system measurements....................... 189 5....6................................ 179 5...... PRIMARY CELL DETERMINATION ............................4............................................... 200 6.................... ALARM MEASUREMENT ACTIVATION WITH EVENT BASED INTRA FREQUENCY MEASUREMENTS...............3...............1 Measurement reporting.......................... 208 6................6..........5 Parameters for Event reporting mode...............................................................................................................................6 Parameters for Measurement .......................................5.............3.3.......................................3 Case of intra-frequency Event-Triggered Reporting mode................................................................. 205 6.......5................5...1........4..........4.............6 Performance management .........1 Description .........................6....................5 Change of Measurement Type ... 185 5.............................................................3...............................................................................1..... 204 6... 204 6.............................................. 189 5........ 185 5.............................................................3............1................... 5.........5 Performance management .................................1.1 1D event configuration....3................3 6A event configuration................................................. 206 6.............................................................................................................................. 183 5............... 179 5...............3............................2.........................2......... 207 6..........................3..................................................................................2 2F event configuration .......................2..................1.........9....1 Description.......................... 205 6...... 195 6.1. 181 5................8...............................3......... 184 5......5.....5 1F event configuration ............................UMTS Radio Mobility 5.................... 192 5.................3................4 Reported cells..........................................................1 Description ..............................1 SIB Update.................3..............................................6....6................................................................2 SIB Repetition period.....2 Parameters .............3................... 207 6....................2................ 186 5.......................................................................................6......................................................................1....3. 206 6........1...................................................................................................................4.........3 Reporting quantities................................ 201 6.......................................................... 192 5...............................................................................................................................3........................ 204 6.........6.........................................1................ MEASUREMENTS CONFIGURATION FOR INTER-FREQ/2G INTER-RAT .........................2.......................... 182 5................4........................ 183 5................................1 Counters ..................................................................... 195 6...............................................1........................................................3........9...........................................3............................9......5. 191 DHO MANAGEMENT............................ 204 6............................................................................ INTRA-FREQUENCY MEASUREMENTS ..........................................................4..1.7 E-DCH active set management ......................4.............................................4 Parameters ........... 207 6..............................5........... ALARM HANDOVER AND ALARM MEASUREMENTS .3...... 202 6...2.....................1.................................... 203 6......................................................................3 Configuration .. 193 6............ 184 5....4.................................. 208 Passing on or copying of this document............. 190 5...........4............... LIST OF COMPOUNDING CELLS FOR THE MONITORED SET DEFINITION .......................... 182 5...............4 Parameters ..............................1 Description................4 Configuration for inter-frequency measurements ........2...................... INTRA-FREQ MEASUREMENTS CONFIGURATION VIA SIB11 ..............2....1.........................2 Algorithm...............3.............................................1 Measurement activation parameters .......................................................4..1....................................................1 Overview ......................................... 184 5.............. 185 5................3 Algorithm. 181 5....................................................................................1................................................. 207 6... MANAGEMENT OF SYSTEM INFORMATION BLOCKS (SIB)........................1..................................2 Traces ...................................2 Reported cells ...............3.......................3.........

............................... 239 6.....................................2 Parameters ....................... 240 Passing on or copying of this document.4..............18 Parameters .............4................. COMPRESSED MODE ..........4....4 Static parameters ........................................ 213 6....................4................................... 213 6..........4........................................................................................4.........2 Parameters .......................4...4.........2..10 SRNS Relocation ...................................................1 GSM measurements........................................ 238 6........................... 233 6...... 216 6..................9............................................. 210 6................................. 239 6.............. 216 6.................4........5 control performed by the ALCATEL-LUCENT RNC .....13 Alpha CEM cards impact ....14 UE impacts.................................5 Pattern shape.......................4.................5........................ 226 6.....................................2 Missing Measurements........4 Measurement purpose............................................................................ NEIGHBOR CELLS FLEXIBLE MANAGEMENT .............2 O&M parameters .............4...................................................... use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.... 234 6....... 209 6........................................................................18.............2 FDD inter-frequency measurements ..................................................7...........4.........................................6....4.............................7......................7.15...........................2 HLS GAP PATTERN configuration............... 214 6.2 intra-RNC/inter-NodeB soft handover.....................4..................................2 UE capability ....7..................................................................................................................... 231 6....................5....... 213 6..........................7..................9..............7 Procedures & messages.......................... 237 6....................6 slot formats/ frame structure ... 220 6.1 Introduction ........................................................................18..........................................................2.......1 HLS assumptionS ...... 210 6.....4............3 Power control parameters . 214 6................. 2G TARGET CELL CHOICE RADIO CRITERIA ....................4.. 215 6.................15...............................18......................................... 212 6..............................................4..............4................................................. 217 6................. 234 6..............................................................4.........4................ 235 6.......................4..9 RNSAP/Compressed Mode Command message .......................................................................................4....................................................8..........2 FDD inter-frequency measurements ..2 RRC/RB Setup message .......3............4........06/EN Approved_Standard 17/Sep/2010 Page 12/244 ................ 217 6.................18................2............................ 217 6................................. FDD TARGET CELL CHOICE INTER FREQUENCY RADIO CRITERIA .....................................1 intra-NodeB soft handover..............4.......4................................. 224 6..........................................15............................................4........................................................4 CM method selection rules: .....2...............................................................7.........4.4.................4.........................4...............................7.............9. 230 6............... 214 6......4.......7.... 219 6........5.......... 239 6....................8 Impacts on RRM Specific for SF/2 method ............... 230 6...4..................................................... 220 6............................................ 240 6........4...............................5 Filtering ..........................................9..................10 RNSAP/Radio link reconfiguration COMMIT message ...........15 Impact on other procedures.......................................................3 Switching between Compressed Mode methods .....1 Data flow.................. 234 6..........................1................................................1 GSM measurements...........1 Code tree management .............................9 HLS ..................... 212 6.............4........6....................................5................................................... 238 6. 216 6.......4........................................................................3 Method ............................. 214 6.................. 221 6....................................5.....................................7......................................4.2........................................................... 210 6...6 NBAP/Compressed Mode Command message ....7 NBAP/Radio link reconfiguration COMMIT message................................................... 238 6.................... 218 6.18...............................1 Dynamic parameters.....................7.............8 RNSAP/Radio Link Setup/addition Request message ........11 RNS Inter-release Compatibility Use cases ..................4.........................18......1 General parameters...............................................................................2 Pattern parameters.....4....3 inter-RNC soft handover .......................................... 230 6.............................5 NBAP/Radio Link Reconfiguration Prepare message ..4......7..............................6......................4.................3................................................................................4.....1 Description ..............4............ 229 6..................... 223 6.. 236 6......17 Defence mechanism for UE not supporting CM with HSPA.....18.......4 RRC/Measurement Control message.................................. 218 6.. 211 6.............UMTS Radio Mobility 6................. 228 6....................3 RRC/RB Reconfiguration message .....4.................4.........................................4.........4............................12 DRNS scenarios .................4..... 218 6................................................................4... 234 6.......................................4......... 209 6.... 230 6.......16 Change of Alarm measurement type (Common HLS and SF/2) ..................................................1 Description .......................................................................................... 232 6....4....................................................... 218 6......................................

.................................................................................... 240 Algorithm......................................7... 242 7.........7.......................................UMTS Radio Mobility 6........................................................................... ABBREVIATIONS . 243 Passing on or copying of this document...................... use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.........1 6..... 242 DEFINITIONS ... ABBREVIATIONS AND DEFINITIONS.7.................................................. 241 7...................... 7...............3 Description .........06/EN Approved_Standard 17/Sep/2010 Page 13/244 .....................................................................2 6....................................................................................................1................... 240 Parameters .......2..............................................................................................

.2 of Alcatel-Lucent UTRAN. 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.2 features covered by this document are: • • • • 81436 Mobility between UMTS and LTE .1 features covered by this document are: • • • • • • 34437 iMCTA developments in UA07 (complete) 78333 Globalization of feature 34224 IF/IRAT measurement evolution 78327 Globalization of feature 34291 support of 64 UMTS neighbours (with limitation due to HCS) 33331 Alarm HHO based on UE Tx power 34476 SRNS HO (UE not involved) – support on oneBTS 34480 3G/2G RRC redirection based on cell load The new UA07. 1. The new UA07. Intersystem mobility procedures (to and from GSM) are also described in this document. How is the document structured? Chapter3 presents definitions and concepts which will be used throughout the document.2.06/EN Approved_Standard 17/Sep/2010 Page 14/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.Cell reselection 104489 LTE to UMTS HO 81213 . Although this document is focused on UTRAN.1. compressed mode .) 1. INTRODUCTION OBJECT This document specifies the UMTS mobility procedures for mobiles connected to the network. SCOPE OF THIS DOCUMENT This document applies to UA07..UMTS Radio Mobility 1.Load balancing between HSPA carriers 81204 Dual Cell HSDPA operation Passing on or copying of this document. it also addresses radio mobility procedure applicable to the Core Network.

[R15] and [R16] documents. For the purpose of the present document. The definition of “Global Market” and “USA Market” are: Global Market: customers other than those part of the following market. This tagging of a word indicates that the word preceding the tag "[USA Market]" applies only to the USA Market. This tagging indicates that the enclosed text following the "[USA Market .423 25. 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. [USA Market] [Global Market .…] Text that is not identified via one of the hereabove tags is common to all markets.06/EN Approved_Standard 17/Sep/2010 Page 15/244 . 2.4. Multiple sequential paragraphs applying only to Global Market are enclosed separately to enable insertion of USA Market specific (or common) paragraphs between the Global Market specific paragraphs. 1. all performance management information (counters) are described in [R14].…] [USA Market ." applies only to the USA Market.433 UTRAN Iu interface RANAP signalling UTRAN Iur interface RNSAP signalling UTRAN Iub interface NBAP signalling Passing on or copying of this document. 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. This tagging indicates that the enclosed text following the "[Global Market . AUDIENCE FOR THIS DOCUMENT This is an external document. DEFINITIONS AND SPECIFICATION PRINCIPLES The present document addresses several markets with potentially different behaviours in those markets. This tagging of a heading indicates that the heading preceding the tag "[USA Market]" and the section following the heading applies only to the USA Market. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility 1. RELATED DOCUMENTS APPLICABLE DOCUMENTS [A1] [A2] [A3] 25.1." applies only to the Global Market.3.413 25. 2. Except when specified. USA Market: customers with UTRAN where Alcatel-Lucent 939X Node B (former Lucent Flexent Node B) is deployed. Multiple sequential paragraphs applying only to USA Market are enclosed separately to enable insertion of Global Market specific (or common) paragraphs between the USA Market specific paragraphs.

Volume 2 (BTS) Observation counters . REFERENCE DOCUMENTS [R1] UMT/SYS/DD/000031 Traffic Management [R2] UMT/SYS/DD/000034 PS Call Management [R3] UMT/SYS/DD/013000 Mobility Performance Improvements [R4] UMT/SYS/DD/013319 HSDPA System Specification [R5] UMT/SYS/DD/013008 Intra-frequency Event Triggered Measurement Reporting Functional Specification [R6] UMT/SYS/DD/018827 E-DCH System Specification [R7] UMT/SYS/DD/000128 IRM .Volume 1 (RNC base) Passing on or copying of this document.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 [R14] [R15] [R16] 411-8111-822P1 411-8111-822P2 411-8111-822P3 Observation counters .UMTS Radio Mobility [A4] [A5] [A6] [A7] [A8] [A9] 25. Radio Resource Control (RRC) protocol Requirements for support of radio resource management (FDD) General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access Circuit Switched Fallback in Evolved Packet System 2.018 25.304 44.272 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.Intelligent Rab mapping [R8] UMT/SYS/DD/18470 [R9] NN-20500-028 SRNS Relocation – UE not involved Alcatel-Lucent 9300 W-CDMA Product Family – Counter Reference Guide .331 25.2.133 23. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.Volume 1 (RNC Callp) Observation counters .06/EN Approved_Standard 17/Sep/2010 Page 16/244 .401 23.

AAL2 is one of the transport layer used in UTRAN.1. GTP is the GPRS Tunnelling Protocol. RNSAP is the Radio Network Subsystem Application Part. This protocol specifies the signalling procedures between the PS Core Network nodes. This protocol specifies radio network layer signalling procedures between RNCs and CN on the Iu interface. This protocol terminates in the UE and in the Serving RNC.06/EN Approved_Standard 17/Sep/2010 Page 17/244 .433. This protocol specifies radio network layer signalling procedures between RNC and Node B on the Iub interface.060. RANAP is the Radio Access Network Application Part. This protocol specifies the signalling procedures between the CS Core Network nodes. RRC: specified in 25. NBAP: specified in 25.423.UMTS Radio Mobility 3. 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.002. In the Core Network: MAP: specified in 29. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 3. Packet data network External Networks GGSN HLR Gn SGSN Gn SGSN Gs MSC/VLR E MSC/VLR PSTN Core Network UTRAN RNC Iur Iub RNC Iu 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. This protocol specifies radio network layer signalling procedures between RNCs in UTRAN on the Iur interface. MAP is the Mobile Application Part. and also between UTRAN and Core Network for CS applications. RNSAP: specified in 25. Passing on or copying of this document. RRC is the Radio Resource Control protocol for the UE-UTRAN radio interface.331. GTP: specified in 29.413. DEFINITIONS & CONCEPTS NETWORK ARCHITECTURE The following figure briefly presents the UMTS network elements which are relevant to mobility features. NBAP is the NodeB Application Part.1.

DSCH.).e. the soft handover may be either: • intra-NodeB: the cells belong to the same NodeB (In case the NodeB performs recombination between radio links. The figure below is an example of soft handover.06/EN Approved_Standard 17/Sep/2010 Page 18/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. this case is called softer handover. FACH.2. The intention is also to set some vocabulary basis that will be used throughout the document..e. Soft handover cannot be applied to shared or common transport channels (e.1 SOFT HANDOVER The soft handover is a procedure allowing the mobile to “do it before break it “ i. some PDU may be lost).2. SRNC SRNC DRNC Cell 1 Cell 2 Cell 1 Cell 2 Cell 2 Cell 3 UE Call establishment UE Intra RNC soft handover UE Inter RNC soft handover Figure 2: Soft handover examples Regarding network architecture.2. refer to § 3.g. 3GPP BASIC PROCEDURES This chapter intends to clarify the basic mobility procedures which are applicable to UMTS UTRAN/FDD networks. As a matter of fact.. i.UMTS Radio Mobility 3.2. the mobile is connected to a set of cells known as the “active set” and takes benefit from macro-diversity.: • soft handover • hard handover • cell reselection (UE controlled mobility) • SRNS relocation • radio link reconfiguration 3. irrespective of the version to which this document applies.e. 3.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. the macro-diversity radio links belong to the same NodeB. The mobility cases specified in the following sections are all using those basic procedures.2 SOFTER HANDOVER In the softer handover case. swapping from one cell to another one without call interruption by opposition to hard handover (i. Passing on or copying of this document.

06/EN Approved_Standard 17/Sep/2010 Page 19/244 .e. GSM) • when soft handover is not permitted (due to O&M constraint) The figure below is an example of hard handover. Cell 1 Cell 2 Cell 1 Cell 2 UE Before UE After Figure 4: hard handover example Regarding network architecture.UMTS Radio Mobility NodeB Cell 1 Cell 2 UE Figure 3: softer handover example Soft and softer handover may be combined (i.3 HARD HANDOVER Hard handover is a category of handover procedures where all the old radio links in the UE are abandoned before the new radio links are established (break it before make it).g. soft handover is not possible) • when the UE is handed over another UTRAN carrier • when the UE is handed over another mode (e. as an option from the network Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.g. Hard handover may occur in UTRAN in the following cases: • when using shared channels (DSCH transport channel) or common channels (FACH transport channel) • when the Iur is not present and the UE is changing RNC (i. 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).e. used at the same time for a given mobile) 3. TDD) • when the UE is handed over another technology (e.2.

Besides.e. the source RNC is actually a 2G-BSC) • outgoing intersystem handover (in this case. there is no RRC connection between the UE and the network). there are some cases in which the UE mobility follows the rules of "cell reselection" which apply normally when the UE is in Idle mode. cell reselection may happen between cells: • from the same RNC or NodeB • from different RNC or NodeB • from different PLMN (in case the Core Network is implementing the "equivalent PLMN" feature). Depending on the network topology. the mobile may select a cell from • another frequency • another mode (e.4 CELL RESELECTION Cell reselection algorithms are applied by any mobiles in Idle mode (i. when the mobile is connected to the network (i. 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 1 Reselection from UTRA cell fach towards E-UTRA idle is not allowed Passing on or copying of this document. a RRC connection is present).06/EN Approved_Standard 17/Sep/2010 Page 20/244 . a SRNS relocation may be either intra or inter MSC or SGSN. and depending on the information broadcast by the network.2. GSM.5 SRNS RELOCATION This procedure is used to move the UTRAN anchor point from the serving RNC to another RNC (the UTRAN anchor point is the node in which the mobile-network RRC connection and RLC/MAC radio protocols are terminating).g. the target RNC is actually a 2G-BSC) • UTRAN radio mobility in case Iur is not present. this is true in the following RRC states: • URA_PCH • CELL_PCH • CELL_FACH1 In the cell reselection process. from RNC1 to RNC2: Before HLR SGSN After HLR SGSN SGSN MSC MSC SGSN MSC MSC RRC RLC MAC RRC RNC1 RNC2 RNC1 RNC2 RLC MAC Figure 5: SRNS relocation example SRNS relocation may be used in many cases: • incoming intersystem handover (in this case.g. In particular. TDD) • another system (e.UMTS Radio Mobility 3. The figure below is an example of SRNS relocation.2. 3.e. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. LTE) Regarding network architecture.

UMTS Radio Mobility Depending on the case for which the relocation is used. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2.06/EN Approved_Standard 17/Sep/2010 Page 21/244 . the SRNS relocation implies: • a u-RNTI (UTRAN Radio Network Temporary Identity) re-allocation • a reset of the radio protocol layers 3. Passing on or copying of this document. In any case. there may or may not be a change of the physical channels being used for the communication.6 RADIO LINK RECONFIGURATION Refer to [R1] for details.

17 4.0.21 4.13 4.2 Section 2G to 3G for CS domain IMSI based HO 13448 21091 4. For all data flows in this chapter.8 4.3 4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Service or CAC failure reason (refer to 4.4 4. MOBILITY CASES This chapter describes all the mobility cases applicable for the current version of the document.4 4.3 4. The complete list of cases is summarized in the table below: Section 4. intra-RNC Soft Handover.20 4.12 4. The following table lists the PMId of the mobility features with the release introduction.2 4.4 4.2 Passing on or copying of this document.0 UA03.7 4. 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 4G to 3G relocation 3G to 2G cell reselection in Idle mode 3G to E-UTRAN 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.5 4.16 4.6 5.18 4. Iub/Iur is on ATM so ALCAP is used to allocate Cid.20 section). Inter Frequency Hard Handover or Inter System Hard Handover are triggered by the iMCTA function for Alarm.2 UA06. If Iub/Iur is on IP there is no seperate ALCAP-like message to allocate/release IP transport resources (IP address and UDP ports).e.11 4. SRNS UE involved) Intra-frequency Inter-RNC Handover without Iur (i.10 4.4 4.15 4.21 4.7 4. inter-RNC Inter-frequency Inter-RNC Handover without Iur (i.10 4.UMTS Radio Mobility 4.1 4. Feature title PMId UTRAN release AT&T Global Market UA06.5 4. SRNS UE involved) Hard handover inter-frequency.6 4.23 4.5 Softer Handover Soft Handover.18.06/EN Approved_Standard 17/Sep/2010 Page 22/244 .14 4.7 4.e.0 UA03.

2 NA NA UA06.2 4.18 4.0 UA06.21 4.2 UA03.4 Passing on or copying of this document.0 UA05.0 UA06.3 5.0 NA UA06.0 UA06.0 UA06.21 4.0 UA06.1.0 UA06.06/EN Approved_Standard 17/Sep/2010 Page 23/244 .0 UA06.0 UA07.21 5.0 UA06.1 UA04.20 4.3 6.0 UA05.0 UA06.1 UA07.3 5.0 UA06. R4.1 4.20 5.18.2 UA04.7 4.0 UA06.18.0 UA06.0 UA06.3 4.1 UA07.0 NA UA06.0 UA06.18.0 UA06.20 4.0 UA05.1 UA07.0 UA06.0 UA06.0 UA06.21 4.0 UA06.2 UA04.21 4.3 4.20 4.4 6.1.0 UA04.0 UA06.2 UA04.2 UA04.1 UA04.0 UA06.0 UA05.10 4.18.1 UA03.1 UA07.3 6.1 UA07.0 UA05.0 UA07.9 4.2 UA04.6 4.0 UA06.0 UA06.7 5.0 UA06.0 UA06.0 UA06.0 UA05.0 NA UA07.6 5.18.14 4.16 6.0 UA07.21 5.11 4.0 UA06.7 6.0 UA06.0 UA05.6 4.0 UA06.UMTS Radio Mobility Inter Frequency inter RNC without Iur 3G to 2G HO for PS & CS simultaneously 3G2G Redirection for emergency call Event-Triggered measurements Fast Alarm handover triggering Composite Neighbour List Inter frequency intra RNC handover based on CM 3G/2G Redirection enhancement for 911 calls 3G/2G Redirection for speech call HSDPA step 1 (see note 1) Intra-frequency Event-triggered Measurements Coexistence of Inter-frequency and 2G Inter-Rat measurements HSDPA Alarm mobility HSDPA Intra-frequency mobility Intra-frequency Hard Handover in case of no Iur Intelligent Multi Carrier Traffic Allocation HSDPA HO with measurements E-DCH step 1 SRNS Relocation “UE not involved” Dynamic SIB scheduling HSDPA over Iur Hierarchical Cell Structure (HCS) URA_PCH CELL_PCH E-DCH macro diversity support Broadcast of SIB4 Broadcast of SIB12 Broadcast of SIB19 HSUPA over Iur Intra frequency inter RNC without Iur Compressed Mode by Higher Layer Scheduling (HLS) Immediate handover for emergency call Service Based Mobility parameters enhancement Multi layer developments iMCTA enhancements for WPS Support of 64 UMTS neighbours Soft Handover developments 2G Inter-RAT handover developments Inter-Frequency Handover developments Inter-Frequency/2G Inter-RAT measurements evolution Defence mechanisms for UE not supporting CM with HSPA Compounding Neighbour Cell List developments intra-frequency Compounding Neighbour Cell List developments IFREQ/IRAT Unified RRM step 2 cell load information exchange between 2G and 3G Redirection during RRC connection setup iMCTA load based HO developments (R3.21 4.2 UA03.0 UA07.0 UA07.0 UA05.0 UA06.0 UA06.3 4.0 UA06.0 UA06.4 4.0 UA06.1 34437.0 UA06.0 UA06.23 4.7 6.17 5. R11) iMCTA load based HO developments (R1.0 UA06.1 UA06.0 NA UA06.3 4. R10) iMCTA load based HO developments (R5) Alarm HHO based on UE Tx power 3G/2G RRC redirection based on cell load 17569 21319 25145 21135 25757 21296 19794 32580 13451 27932 27219 27597 27937 27936 21302 29415 29802 23840 18880 (34476) 30675 29817 29816 26673 26675 32076 33819 33820 81436 30744 33814 28035 34151 33546 33665 32601 (78332) 34291 (78327) 34231 (78326) 34230 (78331) 34229 (78487) 34224 (78333) 34167 33693 34274 33326 75069 34437 34437. R9.21 4.0 UA06.2 UA05.1 UA07.18.0 UA07.3 5.9 6.0 UA06.2 UA04.0 UA07.0 UA07.21 4.0 UA07.2 UA04.0 UA06.0 UA07.0 UA07.4 4.0 UA06.20 4.0 UA07.21 4.2 UA04. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2 UA06.0 NA UA07.6 5.18 4.14 4.2 UA04. R2.2 6.1 UA06.14 6.2 33331 34480 UA06.

the links which are added/withdrawn from the active set are all managed by the SRNC (i.1.06/EN Approved_Standard 17/Sep/2010 Page 24/244 .1.1.12 4.2 UA07.1.2 UA07. Note 1: HSDPA step 1 feature contains HSDPA SHO mobility and traffic segmentation functions.1. the RNC in charge of the RRC connection with the mobile).19 For features introduced in only one type of market in a release. the mobile active set is updated with the new radio link Passing on or copying of this document.UMTS Radio Mobility 3G to LTE cell reselection in Idle mode 3G to LTE cell reselection in Cell/URA PCH mode 4G to 3G relocation Load balancing between HSPA carriers Dual Cell HSDPA operation 81436 81436 104489 81213 81204 UA07. This implies a new radio link to be setup with the NodeB 2.1.e. 4. (2) once new resources are created.18 4.2 UA07.1. please refer to the "DHO management" section in the Common procedures chapter.2 4.1. and the associated AAL2 Cid(s) to be allocated.4 4. Radio link recombination is performed at the SRNC level.2 UA07.2 UA07.1.2 UA07.2 UA07.1. 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).1 SOFT HANDOVER INTRA RNC DESCRIPTION In this case. For further details on this process. Iu SRNC Iub NodeB 1 NodeB 2 New radio link to be added UE Figure 6: soft handover overview In this case. 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 1 2 Figure 7: Radio Link addition (1) based on active set evaluation process result. there is already a macro-diversity link supported by the Serving RNC (NodeB1).5 4.1.1. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. a new branch is added using the NodeB 2. the feature Id of the globalization/above parity feature is given into ( ).2 UA07. 4.2 UA07.

3 PARAMETERS Refer to the [Active Set Evaluation] section in the [Common Procedures] chapter.4 • • • ACCESS NETWORK IMPACTS Measurement processing and decision algorithm for active set updating Support of relevant procedures on the Iub interface and RRC protocol. it is possible to limit the number of soft handover legs being used by setting the relevant parameter to the needed value. please refer to the [Active Set Evaluation] section in the Common Procedures chapter.1. If the Active Set Update procedure fails. the active set evaluation (i.1. 4.2 APPLICABILITY The soft handover applies only on dedicated physical resources. please refer to the [Active Set Evaluation] section in the Common Procedures chapter 4. Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.e.5 CORE NETWORK IMPACTS None. Decision to add/drop links) is based on the same algorithm and parameters (with possibly different values) for PS and CS calls. The mobile active set is updated with the new configuration. and the AAL2 Cid(s) are released. UE NodeB Serving RNC RRC/ Measurement Report (event 1B) RRC/ active set update RRC/ active set update complete 1 NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp 2 Figure 8: Radio Link deletion (1) based on active set evaluation process result. For more details. (CN is completely transparent to this procedure). (2) the link is deleted at the NodeB. Support of User plane combining and splitting 4. Soft & softer handover do not apply to HS-DSCH calls. Besides.1.1. In this version.06/EN Approved_Standard 17/Sep/2010 Page 25/244 . For details on the active set evaluation process. 4. the SRNC decides to remove a radio link from the active set. the call is kept with the previous active set cells.UMTS Radio Mobility The next dataflow is an example of radio link removal. Therefore. soft & softer handover is a network default behaviour which applies to all PS & CS calls whatever is the user data rate.

2. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2. 4. in this version there are as many dedicated links on the Iur as radio links which are controlled by the DRNC). For further details on the Radio link recombination process.06/EN Approved_Standard 17/Sep/2010 Page 26/244 .UMTS Radio Mobility 4.g. This DRNC acts as a router from the RNC and the UTRAN transport point of view (e. there is already a macro-diversity link supported by the NodeB0 (controlled by the SRNC) and the NodeB1 (controlled by the Drift RNC). Iu SRNC Iur DRNC Iub NodeB 0 NodeB 1 NodeB 2 New radio link to be added UE Figure 9: soft handover over Iur In this case.1 • • SOFT HANDOVER INTER RNC DESCRIPTION In this case. A new link from NodeB2 is added: Passing on or copying of this document. 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. please refer to the "DHO management" section in the Common procedures chapter. the links which are added/withdrawn from the active set are not all controlled by the SRNC. In such a case two RNC’s 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.

Passing on or copying of this document. 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. the associated AAL2 Cid(s) are allocated on the Iub and Iur. This information is used by the SRNC to update the list of cells to be measured by the UE. a new branch is added using the NodeB2. (2) Once new resources are created. 2 separate Cid are used on the Iur for both DCCH and DTCH. A new radio link is setup with the NodeB 2. the mobile active set is updated with the new radio link The next dataflow is an example of radio link removal.UMTS Radio Mobility UE Drift NodeB2 RRC/ Measurement Report 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) 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.06/EN Approved_Standard 17/Sep/2010 Page 27/244 . In the RADIO LINK ADDITION RESPONSE message. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. On the Iur. the Drift RNC provides to the SRNC the list of neighbouring cells.

2. 4.2. For details on the active set evaluation process.06/EN Approved_Standard 17/Sep/2010 Page 28/244 . The SCCP released message is sent if the radio link which is removed is the last one supported by the DRNC for this mobile. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. (2) the link is deleted at the NodeB. the SRNC decides to remove a radio link from the active set.2 APPLICABILITY The soft handover inter-RNC requires the presence of an Iur between the involved RNCs.2.3 PARAMETERS Refer to the [Active Set Evaluation] section in the [Common Procedures] chapter.5 CORE NETWORK IMPACTS None. please refer to [Soft Handover intra-RNC]. 4. Passing on or copying of this document.2. (CN is completely transparent to this procedure).4 ACCESS NETWORK IMPACTS All impacts which come from the "soft handover intra RNC". For other applicability considerations. The mobile active set is updated with the new configuration.UMTS Radio Mobility UE Drift NodeB RRC/ Measurement Report RRC/ active set update RRC/ active set update complete 1 Drift RNC Serving RNC 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. please refer to the [Active Set Evaluation] section in the Common procedures chapter 4. the Iub AAL2 Cid the 2 Iur AAL2 Cid are released. plus: • support of dedicated channel on Iur and associated RNSAP procedures. 4.

3.1 SOFTER HANDOVER DESCRIPTION In this case. There is no new AAL2 Cid to be allocated since the recombination between the 2 radio links is performed at the NodeB. 4. i. When the Radio Link Addition Response is sent. the links which are added/withdrawn from the active set are all controlled by a NodeB already supporting a radio link towards the mobile. a new branch is added using the NodeB. 4. please refer to the [DHO management] section in the Common procedures chapter. without cluster limitation.3.06/EN Approved_Standard 17/Sep/2010 Page 29/244 .e. please refer to [Active Set Evaluation] section in the Common procedures chapter For further details on the Radio link recombination process. (2) once new resources are created. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.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. the NodeB start UL reception and DL transmission on the new radio link.2 APPLICABILITY Please refer to § 4. the mobile active set is updated with the new radio link For further details on the active set evaluation process.UMTS Radio Mobility 4. as in the following figure: Iu SRNC Iub NodeB New radio link to be added UE Figure 12: softer handover overview The corresponding dataflow is as follows: UE NodeB RRC/ Measurement Report NBAP/ Radio Link Addition req NBAP/ Radio Link Addition resp 1 Serving RNC RRC/ active set update 2 RRC/ active set update complete Figure 13: Radio Link addition for softer handover (1) based on active set evaluation result.3.1 Passing on or copying of this document. A new UA06.

4. Name is6SectorsNodeb Object/Class RadioAccessService Class3 Definition Flag for 6 sectors softer HO feature activation 4. • only UTRAN/FDD. 4.5 CORE NETWORK IMPACTS None. present chapter describes behaviour when HCS is not used) • High mobility detection is supported 4. 4.304.3 PARAMETERS Refer to the [Active Set Evaluation] section in the [Common Procedures] chapter. (CN is completely transparent to this procedure). 4. i.4.UMTS Radio Mobility 4.e.4 • ACCESS NETWORK IMPACTS Support of relevant Iub procedures 4.1 CELL RESELECTION IN “IDLE MODE” 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". there are 2 algorithms defined for cell reselection: algorithm when absolute priority is not used 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 -algorithm when absolute priority is used for cell reselection defines • a prioriy for UTRAN frequency and a priority for a E-UTRAN frequency Passing on or copying of this document.3.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.3.4.3 ALGORITHM As specified in 25. • “3G to LTE cell reselection in Idle mode” which allows a “LTE capable” UMTS mobile to reselect a LTE cell when being in idle mode in the UMTS coverage. LTE Radio Access Technologies and GSM Radio Access Technologies are known and supported • HCS (Hierarchical Cell Structure) in Idle mode is supported (Please refer to section 4.3. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.23. 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.06/EN Approved_Standard 17/Sep/2010 Page 30/244 .4.

UMTS Radio Mobility
• • a criteria S for E-UTRAN neighbouring cells eligibility several criterion for ranking of eligible cells

The UE will process the following cell reselection process: • • inter frequency cell reselection 2G inter rat cell reselection based on the legacy algorithm; LTE inter rat cell reselection based on the new algorithm using absolute priorities

4.4.3.1

NEIGHBOURING CELLS MEASUREMENT RULES

In order to limit the time during which the mobile performs measurements on UTRAN/FDD neighbouring cells, 25.304 specifies the following algorithm for the mobile in Idle mode: • • • If Squal > Sintrasearch, UE need not perform intra-frequency measurements. If Squal <= Sintrasearch, perform intra-frequency measurements. If Sintrasearch, is not sent for serving cell, perform intra-frequency measurements

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 If Squal <= Sintersearch, perform inter-frequency measurements. If Sintersearch, is not sent for serving cell, perform inter-frequency measurements.

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.

4.4.3.2

NEIGHBOURING CELLS MEASUREMENT RULES WHEN USING ABSOLUTE PRIORITY

As specified in 25.304, when the mobile has received absolute priority information for inter-RAT layers, The UE shall perform measurements of inter-RAT layers with a priority higher than the priority of the current serving cell.

For inter-RAT layers with a priority lower than the priority of the current serving cell:
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 31/244

UMTS Radio Mobility
If SrxlevServingCell > Sprioritysearch1 and SqualServingCell > Sprioritysearch2 the UE may choose not to perform measurements of inter-RAT layers of lower priority If SrxlevServingCell <= Sprioritysearch1 or SqualServingCell <= Sprioritysearch2 the UE shall perform measurements of interRAT layers of lower priority

4.4.3.3

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 For E-UTRAN 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 Alcatel·Lucent written authorization

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 32/244

UMTS Radio Mobility

4.4.3.4

CELL RANKING CRITERIA

The following cell re-selection criteria are used for intra-frequency cells, inter-frequency cells if no absolute priority information for any inter-frequency layer is available to the UE, and inter-RAT cells if no absolute priority information for any inter-RAT layer is available to the UE for that RAT. All the neighbouring cells being eligible (S criteria) are ranked accordingly to the R criteria, as defined below: Rs = Qmeas,s + Qhysts ; for the serving cell Rn = Qmeas,n - Qoffsets,n ; for any GSM or UTRAN/FDD neighbouring cell (There is no "Temporary Offset" in the above criteria when HCS is not used). with
Qmeas Quality value. The quality value of the received signal derived from the averaged CPICH Ec/No or CPICH RSCP for FDD cells and from the averaged received signal level for GSM cells. For FDD cells, the measurement that is used to derive the quality value is set by the Cell_selection_and_reselection_quality_measure information element. This specifies the offset between the two cells (Qoffset). It is used for GSM cells and for FDD cells in case the quality measure for cell selection and re-selection is set to CPICH RSCP. This specifies the offset between the two cells (Qoffset). It is used for FDD cells in case the quality measure for cell selection and re-selection is set to CPICH Ec/No. This specifies the hysteresis value (Qhyst). It is used for GSM cells and for FDD cells in case the quality measure for cell selection and re-selection is set to CPICH RSCP. This specifies the hysteresis value (Qhyst). It is used for FDD cells if the quality measure for cell selection and re-selection is set to CPICH Ec/No.

Qoffset1

Qoffset2 Qhyst1 Qhyst2

4.4.3.5

CELL RANKING CRITERIA WHEN USING ABSOLUTE PRIORITY

All the neighbouring cells being eligible (S criteria) are ranked accordingly to the following criteria: Criterion 1: the SrxlevnonServingCell,x of a cell on an evaluated higher absolute priority layer is greater than Threshx,high during a time interval Treselection Criterion 2: SrxlevServingCell < Threshserving,low or SqualServingCell < 0 and the SrxlevnonServingCell,x of a inter-frequency cell on an evaluated equal absolute priority layer is greater than Threshx,low during a time interval Treselection Criterion 3: SrxlevServingCell < Threshserving,low or SqualServingCell < 0 and the SrxlevnonServingCell,x of a cell on an evaluated lower absolute priority layer is greater than Threshx,low during a time interval Treselection

4.4.3.6

OVERALL CELL RESELECTION PROCESS

Among the GSM and FDD cells which verifies the S criteria, the mobile shall perform ranking according to the R criteria specified above. In this first step, the offset Qoffset1s,n is used for Qoffsets,n to calculate Rn, the hysteresis Qhyst1s is used for Qhysts to calculate Rs. Then the following selection process applies: • • • If a GSM cell is ranked as the best cell, then the UE shall perform cell re-selection to that GSM cell. If an FDD cell is ranked as the best cell and the quality measure for cell selection and re-selection is set to CPICH RSCP, the UE shall perform cell re-selection to that FDD cell. If an FDD cell is ranked as the best cell and the quality measure for cell selection and re-selection is set to CPICH Ec/No, the UE shall perform a second ranking of the FDD cells according to the R criteria specified
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 33/244

UMTS Radio Mobility
above, but using the measurement quantity CPICH Ec/No for deriving the Qmeas,n and Qmeas,s and calculating the R values of the FDD cells. The offset Qoffset2s,n is used for Qoffsets,n to calculate Rn, the hysteresis Qhyst2s is used for Qhysts to calculate Rs. Following this second ranking, the UE shall perform cell re-selection to the best ranked FDD cell. 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 mobile is in High-mobility state it is also multiplied by the speed dependent scaling factor for Treselection value. These parameters gives a mean to have shorter Treselection for fast moving UEs and also to have longer Treselection towards inter-frequency or inter-RAT neighbor cells (i.e. operator’s policy is to keep UE cell reselection in the current frequency).

High mobility detection (if HCS not used) If the number of cell reselections during period non-TCRmax exceeds non-NCR, high-mobility has been detected. When the number of cell reselection during time period non-TCrmaxHyst no longer exceeds non-NCR, UE shall: Continue these measurement during non-TCrmaxHyst; If the criteria for entering high mobility is not detected during time period non-TCrmaxHyst: Exit highmobility.

The high mobility state doesn’t mean the mobile speed is high but the number of reselection is high.

4.4.3.7

OVERALL CELL RESELECTION PROCESS WHEN USING ABSOLUTE PRIORITY

Cell reselection to a cell on a higher absolute priority layer than the camped frequency shall be performed if criterion 1 is fulfilled. Cell reselection to an inter-frequency cell on an equal absolute priority layer to the camped frequency shall be performed if criterion 2 is fulfilled. Cell reselection to a cell on a lower absolute priority layer than the camped frequency shall be performed if criterion 3 is fulfilled. If more than one cell meets the above criteria, the UE shall reselect the cell with the highest SrxlevnonServingCell,x among the cells meeting the criteria on the highest absolute priority layer. The UE shall not perform cell reselection until more than 1 second has elapsed since the UE camped on the current serving cell. For UE in RRC connected mode states CELL_PCH or URA_PCH the interval Treselections,PCH applies, if provided in SIB4 , while for UE in RRC connected mode state CELL_FACH the interval Treselections,FACH applies, if provided in SIB4.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 34/244

1). Real (0. All those parameters are broadcast on the BCCH using either • SIB3 for cell reselection parameters related to the serving cell. This threshold is used in the measurement rules for cell re-selection.4. Integer (-32..0) Ec/N0. it specifies the limit for Srxlev in the serving cell below which the UE ranks inter-frequency neighbouring cells of the serving cell.FACH for the inter-frequency case.91 by step of 2). This specifies the scaling (multiplication) factor to be used by the UE for scaling the parameters Treselections or Treselections. 4. In [dBm] As of UA04.75 by step of 0.PCH or Treselections. it specifies the RAT specific threshold in the serving cell used in the inter-RAT measurement rules. This threshold is used in the measurement rules for cell re-selection.25).UMTS Radio Mobility In all the above criteria the values of Treselections.-13 by step of 2) Integer (0. When HCS is used. Real (1....FACH apply for Treselection and are scaled according to the UE mobility state and target RAT 4.PCH or Treselections..4. it specifies the limit for Srxlev in the serving cell below which the UE shall initiate measurements of all neighbouring cells of the serving cell..20 by step of 2) In [dB] Integer (-32.20 by step of 2) In [dB] Integer (-24. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.91 by step of 2).1 AT UTRAN/FDD CELL LEVEL SIB 3&11 3 3 3 3 3 Object CellSelectionInfo CellSelectionInfo CellSelectionInfo CellSelectionInfo CellSelectionInfo CellSelectionInfo description/comment Choice of measurement (CPICH Ec/No or CPICH RSCP) to use as quality measure for Fdd cell.4.25).4. This specifies the scaling (multiplication) factor to be used by the UE in idle mode or RRC connected mode states for the parameters Treselection in case high-mobility state has been detected..06/EN Approved_Standard 17/Sep/2010 Page 35/244 .31) In [s] From -50 to 33 In [dBm] Integer (-105...2 Integer (-58..-25 by step of 2) RSCP.1 by step of 0. • SIB11 for cell reselection parameters related to neighbouring cells. • SIB19 for LTE cell reselection.4 PARAMETERS This paragraph lists all the parameters needed when HCS is not used and displayed to the operator at the OMCR. Treselections.40 by step of 2) In [dB] Integer (0..20 by step of 2) In [dB] Integer (-32.75 by step of 0. When HCS is not used... it specifies the limit for Srxlev in the serving cell below which the UE ranks inter-RAT neighbouring cells of the serving cell.4. Real (1. When HCS is not used.40 by step of 2) In [dB] Integer (0. This specifies the scaling (multiplication) factor to be used by the UE for scaling the Information Element qualMeas sIntraSearch sSearchRatGsm sInterSearch qQualMin qRxLevMin qHyst1 qHyst2 tReselection sibMaxAllowedUlTxPower OnRach sSearchHcs 3 3 3 3 3 CellSelectionInfo CellSelectionInfo CellSelectionInfo PowerConfClass CellSelectionInfo sHcsRatGsm 3 CellSelectionInfo speedDependScalingFacto rTReselection 3 CellSelectionInfo interFreqScalingFactorTRe selection 3 CellSelectionInfo interRatScalingFactorTRes election 3 CellSelectionInfo Passing on or copying of this document. In [dB] Integer (-115. When HCS is used.. Integer (-105.

This specifies the maximum number of cell reselections. This parameter is mapped to non-NCR or NCR IE for SIB3 filling depending of HCS use or not.16). This parameter is mapped to non-TCRmax or TCRmax IE for SIB3 filling depending of HCS use or not. Integer (1. 180. 20. This specifies the additional time period before the UE can exit high-mobility. 240). Enumerated (not used. This parameter is mapped to non-TCrmaxHyst or TCrmaxHyst IE for SIB3 filling depending of HCS use or not. 70). 30. 120. 30. 40.UMTS Radio Mobility parameters Treselections or Treselections.. This specifies the duration for evaluating allowed amount of cell reselection(s). 10. tCrMax 3 CellSelectionInfo nCR 3 CellSelectionInfo tCrMaxHyst 3 CellSelectionInfo Passing on or copying of this document. 60.06/EN Approved_Standard 17/Sep/2010 Page 36/244 .FACH for the inter-RAT case. Enumerated (not used. 60. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 50.PCH or Treselections.

reserved6 (byte2) bit 6 eUtraTargetFrequencyQrx LevMin UA07.1.2: FddCell.1.reserved4(byte1) bit 0-5 utraSPrioritySearch2 UA07.. Measurement bandwidth information used by SIB19 and common for all neighbouring cells on the carrier frequency 19 FDDCell in UA7.2: First instance FddCell.2 CellSelectionInfoWit hPriority in UA8 Integer (0.1..1..1.2 EUtranFrequencyA ndPriorityInfoList in UA8 Enumerated (6.1.reserved5 (byte3) bit 0-5 19 FDDCell in UA7.. Srxlev of the UTRA cell used for neighboring measurement triggering 19 FDDCell in UA7..-44) by step of 2.2: FddCell..reserved6 (byte2) bit 3-5 eUtraTargetFrequencyDete ction UA07.7) by step of 1. RSCP threshold Low of the UTRA cell used by the UE reselection process 19 FDDCell in UA7. Srxlev of the UTRA cell used for neighboring measurement triggering 19 FDDCell in UA7. E-UTRA frequencies to be used in cell reselection procedure 19 FDDCell in UA7.1.1.1.1..2: First instance FddCell.1.reserved5 (byte2) bit 0-2 Second instance FddCell.1.UMTS Radio Mobility utraServingCellPriority UA07. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2: First instance FddCell.2: FddCell.reserved6 (byte0 and 1) measurementBandwidth UA07.1.7).2 CellSelectionInfoWit hPriority in UA8 Integer (0.1.2 CellSelectionInfoWit hPriority in UA8 Integer (0. Absolute priority of the serving Fdd cell 19 FDDCell in UA7.1.1.2 EUtranFrequencyA ndPriorityInfoList in UA8 Byte (0.15.2 EUtranFrequencyA ndPriorityInfoList in UA8 Integer (-140.75.2: First instance FddCell.reserved5 (byte2) bit 3-5 Second instance FddCell.65535).62) by step of 2.1.reserved4(byte2) bit 0-5 utranThreshSLow UA07.2 CellSelectionInfoWit hPriority in UA8 Integer (0. Qrxlevmin (RSRQ) of the E-UTRA cell used for S criteria of the reselection process.2 EUtranFrequencyA ndPriorityInfoList in UA8 Boolean.2 EUtranFrequencyA ndPriorityInfoList in UA8 Integer (0.7).100).reserved6 (byte2) bit 0-2 eUtraTargetFrequencyPrior ity UA07.reserved5 (byte0 and 1) Second instance FddCell.06/EN Approved_Standard 17/Sep/2010 Page 37/244 .2: FddCell.25.2: First instance FddCell.reserved4(byte3) bit 0-5 eUtraTargetDlCarrierFrequ encyArfcn UA07.62) by step of 2. ‘TRUE’ means that the UE may detect the presence of a E-UTRA cell and report to NAS 19 FDDCell in UA7. Priority of a E-UTRA frequency 19 FDDCell in UA7.1.50.reserved4(byte0) bit 0-2 utraSPrioritySearch1 UA07.reserved5 (byte2) bit 6 Second instance FddCell. Passing on or copying of this document.

reserved7 (byte1) bit 0-5 Second instance FddCell. RxLev (RSRP) Threshold Low of the E-UTRA cell used by the UE reselection process FDDCell in UA7.reserved7 (byte3) bit 0-5 19 19 FDDCell in UA7.0) Ec/N0. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility Second instance FddCell.reserved7 (byte0) bit 0-5 Second instance FddCell.06/EN Approved_Standard 17/Sep/2010 Page 38/244 .50) In [dB] Integer(-50.62) by step of 2..2 EUtranFrequencyA ndPriorityInfoList in UA8 Integer (0..reserved7 (byte2) bit 0-5 eUtraTargetFrequencyThre shxHigh UA07..1.-25 by step of 2) RSCP.2: First instance FddCell. RxLev (RSRP) Threshold High of the E-UTRA cell used by the UE reselection process 4. In [dBm] Information Element maxAllowedUlTxPower primaryScramblingCode ulFrequencyNumber dlFrequencyNumber neighbouringCellOffset qOffset1sn qOffset2sn qQualMin qRxLevMin Passing on or copying of this document.10) In [dB] Integer(-50.4.2 EUtranFrequencyA ndPriorityInfoList in UA8 Integer (0. In [dB] Integer (-115.4.511) This parameters equals ( 5 * FreqDL MHz ) This parameters equals ( 5 * FreqDL MHz ) Integer(-10.1..50) In [dB] Integer (-24.1..2: First instance FddCell..2 AT UTRAN/FDD NEIGHBOURING CELL LEVEL SIB 11 11 11 11 11 11 11 11 11 Object UmtsNeighbouringRelation FDDCell (neighbouring) FDDCell (neighbouring) FDDCell (neighbouring) UmtsNeighbouringRelation UmtsNeighbouringRelation UmtsNeighbouringRelation UmtsNeighbouringRelation UmtsNeighbouringRelation description/comment From -50 to 33 In [dBm] Integer(0..62) by step of 2..1.reserved6 (byte3) bit 0-5 eUtraTargetFrequencyThre shxLow UA07.

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" • “3G to E-UTRAN cell reselection in CELL/URA PCH mode” HCS (Hierarchical Cell Structure) in Fach mode is supported (Please refer to section 4..5. 4. CELL PCH or URA PCH mode.4.06/EN Approved_Standard 17/Sep/2010 Page 39/244 . Part of the BSIC bit string(3) Base Station Color Code..5.5. 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.23. the UE is reselecting a new cell being also controlled by the SRNC.6 • CORE NETWORK IMPACTS Support of location registration update from a 3G to a 2G cell. for a PS or CS attached mobile. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.10) In [dB] Integer(-50. CELL RESELECTION IN “CELL FACH AND CELL/URA PCH MODE” DESCRIPTION 4.1023) GSM ARFCN Integer(-10.50) In [dB] Integer (-115.3 AT GSM NEIGHBOURING CELL LEVEL SIB 11 11 11 11 11 11 11 11 Object GSMCell GSMCell GSMCell GSMCell GSMCell GSMCell GsmNeighbouring Cell GsmNeighbouring Cell description/comment From -50 to 33 In [dBm] bit string(3) Network Color Code..5 • ACCESS NETWORK IMPACTS Ability to broadcast the necessary parameters on the radio interface BCCH. Passing on or copying of this document.1 When in CELL_FACH. 4.4.4.-25 by step of 2) In [dBm] Information Element maxAllowedUlTxPower Ncc Bcc GSMbandIndicator bcchFrequency gsmCellIndivOffset qOffset1sn qRxLevMin 4.1. present chapter describes behaviour when HCS is not used) 4. PCS 1900 band used Integer (0.1 INTRA-RNC CASE In this case. Part of the BSIC DCS 1800 band used. as in the figure below (please note that the old and the new cells may also be controlled by the same NodeB)..UMTS Radio Mobility 4.4.

In Alcatel-Lucent implementation. the UE generates a CELL UPDATE to the SRNC. CN Information (PLMN Id. 2 RRC/ RACH / Cell Update (cause "cell reselection") RRC/ FACH / Cell Update Confirm (RRC state = CELL_FACH.2 INTER-RNC CASE In this case. 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".UMTS Radio Mobility 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. c-RNTI) RRC/ RACH / UTRAN Mobility Information Confirm Serving RNC SGSN If the mobile enters a new Location Area or Routing Area: GMM/ RACH / Routing Area Update Request GMM/ RACH / Routing Area Update Accept Figure 15: Intra-RNC cell re-selection in CELL_FACH dataflow Having re-selected the new cell. As in the figure below. this RNC may possibly depend from another SGSN.06/EN Approved_Standard 17/Sep/2010 Page 40/244 . so that the SRNC keeps the current cell updated for paging. RAI). Passing on or copying of this document. a UTRAN MOBILITY INFORMATION CONFIRM message is then answered by the mobile. 4. the CELL UPDATE CONFIRM will always contain a new-CRNTI.1. LAI. the UE is reselecting a new cell being controlled by an RNC different from the SRNC. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.5. UE NodeB 1.

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 Alcatel-Lucent Serving RNC1 Alcatel-Lucent Drift RNC2 SGSN 1 SGSN 2 Based on the u-RNTI analysis. forcing the mobile to Idle mode. cause “DSCR”) Figure 17: Initial RRC access.UMTS Radio Mobility GGSN SGSN 1 Iur RNC 1 Iub NodeB 1 Iub 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. UTRAN does not support common channel over Iur. the new RNC (RNC2) detects that the UE is actually connected to another SRNC. first steps when the Drift RNC2 is Alcatel-Lucent Passing on or copying of this document.06/EN Approved_Standard 17/Sep/2010 Page 41/244 . cause “cell reselection”) RRC/ FACH / RRC Connection Release (U-RNTI. The RNC2 rejects the cell update using the RRC connection release procedure. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. RRC/ RACH / Cell Update (U-RNTI. In this version.

cause “directed signaling connection re-establishment”) Figure 18: Initial RRC access. RRC state = CELL_FACH) RRC/ RACH / RRC Connection Setup Complete RRC/ RACH / Initial Direct Transfer (Routing Area Update Request. RNSAP/ DOWNLINK SIGNALLING TRANSFER REQUEST / RRC Connection Release (U-RNTI. first steps when the Drift RNC2 is not Alcatel-Lucent UE RNC 1 RNC 2 SGSN 1 SGSN 2 When it enters Idle mode.UMTS Radio Mobility Alcatel-Lucent Serving RNC1 NonAlcatel-Lucent Drift RNC2 UE SGSN 1 SGSN 2 RRC/ RACH / Cell Update (U-RNTI. The procedure is used by the drift RNC2 to forward to the Serving RNC1 the RRC Cell Update message received on the RACH.06/EN Approved_Standard 17/Sep/2010 Page 42/244 . RRC/ RACH / RRC Connection Request (cause « re-establishment ») RRC/ FACH / RRC Connection Setup (DCCH. U-RNTI. 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. forcing the mobile to idle mode. 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. the UE requests for a RAU. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. cause “cell reselection”) RRC message received from UE containing U-RNTI ID as addressing information. PS domain) SCCP/ Connection Request (Initial UE msg (Routing Area Update Request)) SCCP/ Connection Confirm Figure 19: Initial RRC access Passing on or copying of this document. Follow-on request pending. cause “U-RNTI. 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. cause “directed signaling connection re-establishment”) RRC/ FACH / RRC Connection Release (U-RNTI.

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. the new RAB is setup in CELL_FACH state. RRC state) RRC/ RACH / RB Setup Complete RANAP/ RAB Assignment Response GMM/ Service Accept Figure 21: The service re-establishment phase 4. RRC/ FACH / RB Setup (DTCH. 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 mobile is possibly moved to the CELL_FACH state. corresponding to the active PDP context being re-activated by the UE.5. as for a PS call establishment. Further on.1. the new RAB is setup in CELL_FACH state.3 3G TO 2G CASE This mobility case is similar to the inter-RNC mobility case: • at some point. RANAP/ Iu release command RANAP/ Iu release complete GMM/ Routing Area Update Accept (P_TMSI) GMM/ Routing Area Update Complete Figure 20: The Routing Area Update phase UE RNC 1 RNC 2 SGSN 1 SGSN 2 GMM/ Service Request (Data) The SGSN requests the UTRAN for RAB allocation. and security procedures are activated by the new SGSN. 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.06/EN Approved_Standard 17/Sep/2010 Page 43/244 . In this example. RANAP/ RAB Assignment Request In the target RNC. based on Always-On algorithm and user traffic volume. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility UE RNC 1 RNC 2 SGSN 1 SGSN 2 The active PDP context(s) are retrieved from the old to the new SGSN.

3 ALGORITHM Please refer to [Cell Reselection In Idle Mode]. If a DC UE attempts call establishment on a cell that is not DC capable. Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the mobile in PS active mode will reselect a E-UTRAN cell • the mobile will perform a Tracking Area Update in its new E-UTRAN cell • this will imply a SGSN context transfer between the old and new SGSN • at the end all user-related resources will be cleared in UTRAN through Iu Release Request from the old SGSN 4.5. 4. Unfortunately. 4. 4. 3GPP has not defined any mechanisms to force cell reselection based on DC capability. 4. Therefore. In the current release neither iMCRA nor iMCTA ensure redirection or handover to a DC capable cell.5.5.1. then Redirection onto another DC layer may be performed during RRC establishment or the call can get handed over to a DC layer after call establishment. In this case. it would be preferable for DC capable UEs to camp on DC capable layers.5 3G TO E-UTRAN CASE This mobility case is similar to the inter-RNC mobility case: • at some point.1. 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 • SIB19 for cell reselection parameters when absolute priority is used if feature “broadcast of SIB19” is enabled Following activation parameters are used: Name Object/Class FDDCell Class3 SIB4enable Definition When set to TRUE. CELL-PCH and URA-PCH).5.4 PARAMETERS In connected mode (CELL-FACH.06/EN Approved_Standard 17/Sep/2010 Page 44/244 . indicates that the SIB4 feature is activated.5.5.1. no specific cell reselection handling or specific SI broadcast is available for DC feature.UMTS Radio Mobility • • this will imply a SGSN context transfer between the old and new SGSN at the end all user-related resources will be cleared in UTRAN through Iu Release Request from the old SGSN 4. 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).6 DUAL CELL HSDPA CASE In multi-layer networks with some layers supporting DC transmission and others not.4 2G TO 3G CASE From the UTRAN point of view.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.

..40 by step of 2) In [dB] Integer (0.. 4. Integer (-32.20 by step of 2) In [dB] Integer (-24.06/EN Approved_Standard 17/Sep/2010 Page 45/244 .0) Ec/N0.40 by step of 2) In [dB] Integer (0.5. indicates that the SIB19 feature is activated. In [dBm] As of UA04..40 by step of 2) In [dB] Integer (0.. If SIB4/SIB12 are not broadcasted. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. SIB12 and SIB19.UMTS Radio Mobility the parameter isDynamicSibAlgoWithSbAllowed has to be set to true. YES: SIB12 is sent NO: SIB12 is not sent When set to TRUE. In [dB] Integer (-115. the parameter isDynamicSibAlgoWithSbAllowed has to be set to true.. parameters of SIB3/SIB11 are used instead.2 Integer (-58.1 AT UTRAN/FDD CELL LEVEL SIB 4&12 Object CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC description/comment Choice of measurement (CPICH Ec/No or CPICH RSCP) to use as quality measure for Fdd cell..40 by step of 2) In [dB] Integer (0. In this case. the parameter isDynamicSibAlgoWithSbAllowed has to be set to true... YES: SIB19 is sent NO: SIB19 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.40 by step of 2) Information Element qualMeas sIntraSearch 4 sSearchRatGsm sInterSearch qQualMin qRxLevMin 4 4 4 4 qHyst1 qHyst1Fach qHyst1PCH qHyst2 qHyst2Fach qHyst2Pch 4 4 4 4 4 4 Passing on or copying of this document. indicates that the SIB12 feature is activated.-13 by step of 2) Integer (0. For qHyst1. In this case.20 by step of 2) In [dB] Integer (-32. SIB12enable FDDCell Class3 SIB19enable FDDCell Class3 isDynamicSibAlgoWithSBAllowed RadioAccessService Class3 The list of parameters for SIB4/12 is the same as for SIB3/11 but they are described in dedicated objects.4. YES: SIB4 is sent NO: SIB4 is not sent When set to TRUE..20 by step of 2) In [dB] Integer (-32.40 by step of 2) In [dB] Integer (0.-25 by step of 2) RSCP... qHyst2 and tReselection it is furthermore possible to configure them differently on FACH and PCH.

4... it specifies the limit for Srxlev in the serving cell below which the UE shall initiate measurements of all neighbouring cells of the serving cell.16). 60.1 by step of 0. Enumerated (not used. tReselection tReselectionFach tReselectionPch sibMaxAllowedUlTxPower OnRach sSearchHcs 4 4 4 4 4 sHcsRatGsm 4 CellSelectionInfoC onnectedMode speedDependScalingFacto rTReselection 4 CellSelectionInfoC onnectedMode interFreqScalingFactorT Reselection interRatScalingFactorTR eselection tCrMax 4 CellSelectionInfoC onnectedMode 4 CellSelectionInfoC onnectedMode 4 CellSelectionInfoC onnectedMode nCR tCrMaxHyst 4 CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode 4 Passing on or copying of this document. 60.31) In [s] Integer (0.25). When HCS is used. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.75 by step of 0.. This specifies the scaling (multiplication) factor to be used by the UE for scaling the parameters Treselections or Treselections. This specifies the additional time period before the UE can exit high-mobility. When HCS is not used. 10. 240). it specifies the RAT specific threshold in the serving cell used in the inter-RAT measurement rules. This specifies the scaling (multiplication) factor to be used by the UE for scaling the parameters Treselections or Treselections.75 by step of 0. Real (1.25).PCH or Treselections.FACH for the inter-frequency case. 50. 20.06/EN Approved_Standard 17/Sep/2010 Page 46/244 .91 by step of 2).. Enumerated (not used. 30.1). This specifies the duration for evaluating allowed amount of cell reselection(s). This specifies the scaling (multiplication) factor to be used by the UE in idle mode or RRC connected mode states for the parameters Treselection in case high-mobility state has been detected. This parameter is mapped to non-TCRmax or TCRmax IE for SIB3 filling depending of HCS use or not. This specifies the maximum number of cell reselections. This threshold is used in the measurement rules for cell re-selection. 30.FACH for the inter-RAT case. When HCS is used. 40.91 by step of 2). This parameter is mapped to non-NCR or NCR IE for SIB3 filling depending of HCS use or not..31) In [s] From -50 to 33 In [dBm] Integer (-105.PCH or Treselections. Integer (-105. Integer (1. it specifies the limit for Srxlev in the serving cell below which the UE ranks inter-frequency neighbouring cells of the serving cell.. Real (0..UMTS Radio Mobility onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode CellSelectionInfoC onnectedMode PowerConfClass CellSelectionInfoC onnectedMode In [dB] Integer (0... it specifies the limit for Srxlev in the serving cell below which the UE ranks inter-RAT neighbouring cells of the serving cell. Real (1. 120. When HCS is not used. 180. This parameter is mapped to non-TCrmaxHyst or TCrmaxHyst IE for SIB3 filling depending of HCS use or not.31) In [s] Integer (0.4. This threshold is used in the measurement rules for cell re-selection. 70).

5. In [dBm] Integer [-20.10) In [dB] Integer(-50.4.5.1023) GSM ARFCN Integer(-10..UMTS Radio Mobility 4.1 4...0) Ec/N0.-25 by step of 2) In [dBm] Information Element maxAllowedUlTxPower Ncc Bcc GSMbandIndicator bcchFrequency gsmCellIndivOffset qOffset1sn qRxLevMin 4.4.6.50) In [dB] Integer (-24. RRC connection reject in case of unknown u-RNTI 4.3 AT GSM NEIGHBOURING CELL LEVEL SIB 12 12 12 12 12 12 12 12 Object GSMCell GSMCell GSMCell GSMCell GSMCell GsmCellSelectionI nfoConnMode GsmCellSelectionI nfoConnMode GsmCellSelectionI nfoConnMode description/comment From -50 to 33 In [dBm] bit string(3) Network Color Code.1 2G TO 3G HANDOVER FOR CS DOMAIN DESCRIPTION DATAFLOW In this case the mobile connected to the CS domain is moved from a 2G cell to a 3G cell.0.06/EN Approved_Standard 17/Sep/2010 Page 47/244 .5.-25 by step of 2) RSCP. for a PS or CS attached mobile..6 • CORE NETWORK IMPACTS Support of location registration update from a 3G to a 2G cell.. In [dB] Integer (-115.6.1.50) In [dB] Integer(-50. Passing on or copying of this document.5.6.. 4.511) This parameters equals ( 5 * FreqDL MHz ) This parameters equals ( 5 * FreqDL MHz ) Integer(-50..5 In [dB] Information Element maxAllowedUlTxPower primaryScramblingCode ulFrequencyNumber dlFrequencyNumber qOffset1sn qOffset2sn qQualMin qRxLevMin cellIndivOffset 4..2 AT UTRAN/FDD NEIGHBOURING CELL LEVEL SIB 12 12 12 12 12 12 12 12 12 Object FddNeighCellSelectionInfoC onnectedMode FDDCell (neighbouring) FDDCell (neighbouring) FDDCell (neighbouring) FddNeighCellSelectionInfoC onnectedMode FddNeighCellSelectionInfoC onnectedMode FddNeighCellSelectionInfoC onnectedMode FddNeighCellSelectionInfoC onnectedMode FddNeighCellSelectionInfoC onnectedMode description/comment From -50 to 33 In [dBm] Integer(0.5 • • ACCESS NETWORK IMPACTS Ability to broadcast the necessary parameters on the radio interface BCCH. Part of the BSIC DCS 1800 band used. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11..50) In [dB] Integer (-115.20. 4. Part of the BSIC bit string(3) Base Station Color Code..0] step:0. PCS 1900 band used Integer (0.

use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Passing on or copying of this document.UMTS Radio Mobility Anchor MSC 2G-MSC 3G-MSC BSC Abis BTS Iub 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.06/EN Approved_Standard 17/Sep/2010 Page 48/244 .

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.UMTS Radio Mobility 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) 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 1 Follow up procedures after successful handover from GSM to UMTS: • Security Update • RRC measurement setup • UE capability enquiry • Mobility Update • In case of Default Configuration: Radio Link. There is no list of possible target. The request sent from the source BSC identifies only one cell in one RNC. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.and Bearer Configuration to ALU standard 4 Figure 23: 2G to 3G handover for CS dataflow (1) Handover preparation phase.06/EN Approved_Standard 17/Sep/2010 Page 49/244 . When the handover decision is made. Passing on or copying of this document.

the default configuration has lower performance than the normally used configuration and a reconfiguration after successful handover is required.and Bearer Configuration to ALU standard (see below) 4. default configurations may also be used. so that the mobile can initiate or resume PS activity.6. which will imply segmentation on the GSM RR interface (i. The impact is RR message segmentation on the GSM side. which pre-defined configurations have been read by the UE – if exists) (2) Handover execution phase. The handover command message contains the target cell resource description. 3. Old radio link(s) in GSM system are released. The SECURITY MODE COMMAND procedure is used to trigger integrity protection in UMTS.2) configuration. There exist 3 possibilities in the 3GPP specifications for describing the target cell resource: 1. These configurations are broadcast on the UTRAN BCCH using SIB 16.06/EN Approved_Standard 17/Sep/2010 Page 50/244 . In order to reduce the size of the message. The handover is performed when the UE is successfully connected to the 3G system. However.1. • Security Update • RRC measurement setup • UE capability enquiry • Mobility Update • In case of Default Configuration: Radio Link. the handover message will have a length estimated to 160 bytes.108 UE conformance testing specification.e. The estimated size for a HANDOVER TO UTRAN RRC message is around 180 bytes in case of a (DCCH + speech 12.e. around 8 segments). • The default configuration 3 for CS Voice 12.UMTS Radio Mobility The "Source RNC to target RNC transparent container" information element which is transferred to the target RNC contains: • the UE capability • the pre-defined configuration status (i. 2. In this version of the document the Alcatel-Lucent RNS either builds the handover message containing: • The explicit target resource description.2 APPLICABILITY Depends on BSC algorithm. pre-defined configurations may be used. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Passing on or copying of this document. The UTRAN MOBILITY INFORMATION procedure is used to provide the UE with PS domain Location Information. 4. These configurations are described in 25.6. The target resource is explicitly described in the "Intersystem to UTRAN Handover command" message. In this case.2 TARGET RESOURCE DESCRIPTION The description of the resource in the target cell is provided by the target RNC to the mobile using the INTERSYSTEM TO UTRAN HANDOVER COMMAND message from the GSM RR layer. and are possibly read by the UE when camping on GSM cell.331 RRC specifications. The HANDOVER TO UTRAN COMMAND RRC message is sent from the target 3G to the UE via the MSC nodes and the serving BSC. (4) Post Handover Procedures. They all are derived from 34. (3) Old resource release phase. For the same reason. The behaviour is configurable by parameter isGsmIratHoDefaultConfigurationUsed.2 With this the segmentation of the handover message at GSM RR can be avoided. and shall be supported by mobiles.

3.3.3 4. a resource may not be available.413 §9.331 §14. Resource shortage can also be caused by exhaustion of the reduced Uplink Scrambling Codes for 2G->3G handover with default configuration.1 ALGORITHM RELOCATION REQUEST MESSAGE STRUCTURE As the RELOCATION REQUEST message is specified in 2 different specifications (24.2.12.413 for the RANAP part.UMTS Radio Mobility 4.28) • RRC information to target RNC (25.e. However.3 TARGET RESOURCE ALLOCATION IN RNC The target resource allocation algorithm in target RNC for incoming calls from 2G takes into account the following limitations from the standard: • Due to the RELOCATION REQUEST message structure.6.3. this IE contains a “SRNS Relocation Info” container 4.331 §10.37) • Ciphering algorithm capability • Integrity protection algorithm capability • Pre-defined configuration status information (25.3.2) • START-CS • Inter-RAT UE radio access capability (25.413 §9.1. this paragraph presents a simplified view of the structure of the message: RELOCATION REQUEST (25. In case of congestion.06/EN Approved_Standard 17/Sep/2010 Page 51/244 .10) • source RNC to target RNC transparent container (25.331 §14.5a) • UE security information (25.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. 4. a RELOCATION REQUEST rejection by the target RNC can happen in the following cases: There is no resource available in target RNS to support the incoming call Based on the “RAB to setup list” contained by the RELOCATION REQUEST message.1) • Handover to UTRAN Info (25.6. the RNC tries to allocate a suitable resource based on CAC algorithm.4.331 §10.331 for RRC specific IE).6. 25. it is deduced by the target RNC by the content of the “RRC information to target RNC” IE.12.4.3. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.42) • Security capability (25.13.1) • UE Radio Access capability (25. This IE may be of 2 types: • In case of handover from another RAT. GSM or UMTS) the message is issued.2 RELOCATION REQUEST REJECTION In this version.1.3.2. which is a mandatory part of the message.3.8.331 §14. The RELOCATION REQUEST has not been issued by a GSM BSS There is no explicit information element in the RELOCATION REQUEST message which indicates from which technology (i.6. there is only one target cell to be considered by the target RNC Passing on or copying of this document.3.331 §10.331 §10. this IE contains a “Handover to UTRAN Info” container • In case of SRNC relocation.3.

the RNC will choose a Radio Bearer configuration among the ones which are supported in this version.3. 3GPP TS 44.3.4 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.UMTS Radio Mobility • Due to limitation of the GSM standard for circuit call.42) • START-CS parameter (this parameter is actually stored on the mobile USIM) Passing on or copying of this document. RLC AM HFN. there will be only one RAB in the “RAB to be setup list” in the RELOCATION REQUEST message Besides. in this version: The resource allocation for incoming relocation from 2G follows the same algorithm as for initial call setup resource allocation.5 INTEGRITY Integrity is started by the RNC immediately after receiving the HANDOVER TO UTRAN COMPLETE RRC message. resulting from the conversion of Kc (GSM ciphering key) by the 3G-MSC. UE NodeB RNC RRC/ Handover to UTRAN complete RRC/ Security Mode Command RRC/ Security Mode Complete 4.6. 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. 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).18 Release 99 (resp. the algorithm for RAB to RB mapping is the same as used for call initiation. In this case. i. 4. 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).e. there is no pool of reserved capacity for incoming relocation from 2G.6.06/EN Approved_Standard 17/Sep/2010 Page 52/244 . resulting from the conversion of Kc (GSM ciphering key) by the 3G-MSC. 4. RLC UM HFN.6 DEPENDENCIES WITH GSM For this procedure to be working correctly.3.6. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.3. it is mandatory the GSM BSS supports the “UTRAN classmark change” as specified in GSM TS 04.3. RLC AM HFN. Ciphering is started by the mobile immediately after receiving the HANDOVER TO UTRAN COMMAND message. RLC UM HFN. Based on RAB parameters requested by the Core Network.018 Release 4 and beyond). as this message contains the following information: • UE Radio Access capability ([A4] §10.

indicated by receipt of the HANDOVER TO UTRAN COMPLETE message. which have to be transferred via the GSM air interface in order to inform the UE about the radio configuration for the UMTS network access. In case of handover however. The handover performance is improved when it is possible to transfer the handover to UTRAN command within a non-segmented GSM air interface message. Segmentation over more than two GSM air interface blocks could have a significantly detrimental impact on handover performance. then either the use of default configurations should be disabled (parameter isGsmIratHoDefaultConfigurationUsed) or the call will have sub-optimal RLC parameter settings.4. too.2 multi rate with 12. the quality of the uplink may be quite poor resulting in a failure to transfer acknowledgements. This implies that it may be impossible to quickly transfer a segmented handover message. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2 multi rate with 12.2 mono rate != 12. subsequent segments can only be transferred after acknowledgement of earlier transmitted segments.6. The UMTS standard allows specifying individually the radio bearer and transporting channels via a large set of parameters. This results in large messages.4 4. Whether the requested RAB can be served by default configuration #3 or not depends on the Iu UP version and the offered AMR codecs in the inter-RAT relocation request as per following table: Iu UP version any any any Iu UP v1 Iu UP v2 Offered AMR codecs in 2G to 3G relocation request mono rate 12.1 FAILURE CASES CONNECTION RELEASE On the network side. optimized configuration.4.06/EN Approved_Standard 17/Sep/2010 Page 53/244 . or the mobile station has re-established the call. In case that segmentation is used. the mobile returns on the old channel it was using in the GSM source cell. Within this reconfiguration the RLC parameters should be reconfigured. then it advisable to enable it (parameter isRlcAMReconfigurationAllowed and isUER99RlcAmReconfigurationAllowed).2 Selected configuration type for handover to UTRAN command default config #3 full config full config default config #3 full config After successful completion of the GSM to UMTS handover. or a HANDOVER FAILURE RRC message is received on the old channels. 4.6. Passing on or copying of this document. If it is not available. if timer T3121 elapses before either the HANDOVER TO UTRAN COMPLETE ([A4] and [A6]) RRC message is received on the UTRAN channel(s).6. the old channels are released if they were dedicated channels and all contexts related to the connections with that mobile station are cleared.2 multi rate without 12.6.UMTS Radio Mobility 4. the RNC reconfigures the radio bearer to the normal.7 USE OF DEFAULT CONFIGURATION The IRAT HO message should be sent within one block in GSM to reduce handover delay and increase handover success rate. 4. The usage of the default reduces the size of the HANDOVER TO UTRAN COMMAND message and thus the GSM HANDOVER COMMAND message. If RLC reconfiguration is available. Default Configuration #3 (see [A4]) is supported for 12.2 kbps CS speech and transmitted in the handover command via core network and GERAN to the UE.2 RETURN ON OLD CHANNEL In case the mobile fails to synchronize or access on the new UTRAN channel.3.

a handover failure message is sent to the 2G_MSC. (2) As a consequence.UMTS Radio Mobility UE NodeB RNC 3G-MSC/VLR 2G-MSC/VLR BSS 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. leading to a cancellation of the handover procedure on the MAP interface. 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 Passing on or copying of this document.3 RELOCATION REJECTED BY TARGET RNC If the relocation preparation phase fails (see possible causes in the related chapter). 4. the target RNC receives an Iu release command message from its MSC. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.4. requesting all the resources which have been allocated during the handover preparation phase to be released.6. a relocation failure is sent from RNC to the 3G-MSC.06/EN Approved_Standard 17/Sep/2010 Page 54/244 .

use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 4. GGSN 2G-SGSN 3G-SGSN BSC Iub BTS 1 Abis RNC NodeB 2 UE Before After UE Figure 26: 2G to 3G handover for PS Passing on or copying of this document.7.6.6 • • • ACCESS NETWORK IMPACTS support for incoming relocation procedures (involving SCCP connections initiated by the CN) ability to format the HANDOVER TO UTRAN message (as defined in the RRC specification) start of security procedure (ciphering & integrity) at the end of the handover execution at RRC level 4.6. This implies not only message conversion.5 PARAMETERS The parameters are: Name is2GTo3GCSHandoverAllowedWithinRnc Object/Class InterFreqMeasConf Class3 isGsmIratHoDefaultConfigurationUsed 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 requests from 2G are rejected This parameter enables/disables the use of default configurations for inter RAT handover from GSM to UMTS. Ciphering and integrity key conversion at the 3G-MSC 4. 2G TO 3G HANDOVER FOR PS DOMAIN In this case the mobile connected to the network in GPRS mode is moved from a 2G cell to a 3G-PS cell.7 • • CORE NETWORK IMPACTS BSSMAP to RANAP message interworking at the 3G-MSC level.UMTS Radio Mobility Figure 25: 2G to 3G handover for CS – failure case 4. but also deriving RAB attributes from the current channel in use in GSM.6.06/EN Approved_Standard 17/Sep/2010 Page 55/244 .

4. and is moved from a 3G cell to a 2G cell. CS and PS parts are managed independently.06/EN Approved_Standard 17/Sep/2010 Page 56/244 .UMTS Radio Mobility In GPRS. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.8. The next dataflow is an example of inter-SGSN 2G to 3G handover. the mobility decision is taken by the UE. UE BTS Serving BSC GMM/ RA update request Target RNC 3G-SGSN 2G-SGSN 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 Figure 27: 2G to 3G handover for PS 4.9.6 and the PS part as in § 4.9. The CS part is managed as described in § 4.1 3G TO 2G HANDOVER FOR PS DOMAIN DESCRIPTION In this case the mobile connected to the network in PS mode is moved from a 3G cell to a 2G-GPRS cell. 4. Once PDP context transferred from old to new SGSN.7. the 3G SGSN requests for a RAB establishment as for a call establishment. The GPRS mobility is done via a Routing Area Update procedure. 2G TO 3G HANDOVER FOR CS + PS DOMAINS In this case the mobile connected to both CS and PS domains. Passing on or copying of this document.

06/EN Approved_Standard 17/Sep/2010 Page 57/244 . as opposed to CS handover. the mobile is using dedicated resources for PS services in 3G network. In this version. the handover decision is taken by the SRNC (as if it were a CS call). 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/ SRNS data forward command RANAP/ Iu release command NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp 3 RANAP/ Iu release complete TDATAfwd Figure 29: 3G to 2G handover for PS dataflow (1) Based on measurements. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. UE Serving NodeB Serving RNC Target BSC 2G-SGSN 3G-SGSN RRC/ Measurement Report RRC/ Cell change order from UTRAN (BSIC. resources are allocated in the target BSS. the serving RNC decides to hand the mobile over a 2G cell. Therefore. Meanwhile. Following the mobile access on the 2G cells. The cell change order message contains the Passing on or copying of this document. the connection and resource allocation in the target system are performed on UE request.UMTS Radio Mobility GGSN 3G-SGSN 2G-SGSN SRNC Iub NodeB 1 Abis 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.

TDATAfwd is equal to 0 sec. In such a case.9. UE Serving NodeB Serving RNC Target BSC 2G-SGSN 3G-SGSN RRC/ Cell change order from UTRAN (BSIC.20. In this version.1 ALGORITHM HO DECISION PROCESS Please refer to section 4.2 MEASUREMENTS CONFIGURATION Please refer to section 4. N-PDU and GTP-PDU will not be transferred by the RNC on the RANAP protocol. the PS subscribers will be kept in 3G as much as possible. Alcatel-Lucent UTRAN allows a possible return on the old channels.06/EN Approved_Standard 17/Sep/2010 Page 58/244 .9. Since the quality of service offered to subscribers will be better in UMTS as compared to what GPRS can offer.9. (3) Although not supported by UTRAN in this version. 4.3 4.4. (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.3 TARGET CELL CHOICE Please refer to section 4. or when leaving a UTRAN coverage spot.1 FAILURE CASES TARGET CELL SYNCHRONIZATION FAILURE If the mobile fails to access and synchronize on the target GSM cell.2 APPLICABILITY In this version. Even if no data is forwarded. In this version. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.19) 4. the mobile sends a CELL CHANGE ORDER FROM UTRAN FAILURE message on the channel that was used in the serving UTRAN cell(s) and re-establish on the resource that were user in 3G. BCCH ARFCN) The HO fails on the target system RRC/ Cell change order from UTRAN failure Figure 30: 3G to 2G handover for PS .4 4. and will only be handed to 2G in case of UTRAN coverage holes.3. 4.9.3. the mobile is using either dedicated or shared resources for PS services in 3G network.9.UMTS Radio Mobility target cell BSIC and BCCH ARFCN which are used by the mobile to get the target synchronisation before accessing to the network. The decision to launch this mobility procedure is taken by the iMCTA function (refer to section 4. 4. 4.9.20.20. the old SRNC shall not complete the resource release phase until TDATAfwd (data forwarding timer).failure case Passing on or copying of this document.9.3. data forwarding may be asked by the source SGSN.

use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.7 • • • CORE NETWORK IMPACTS support of relevant RANAP procedures the 3G PDP QoS parameters need to be translated by the 3G-SGSN into 2G parameters the ciphering key CK needs to be translated into 2G GPRS ciphering key 4. the handover is seen from the BSS as a new GPRS call setup). • the "SRNS context transfer" procedure is not supported by the source RNC (i. Passing on or copying of this document. the messaging is supported but the PDU counters are not transferred).5 PARAMETERS The parameters are: Name Object/Class RadioAccessService Class3 activationHoGsmPsAllowed See also: Section 4. i.9. Restrictions: • data packet forwarding is not supported by the source RNC. 4.e.20.5. since the target RNC doesn't know which GTP-PDU have actually been sent and acknowledged.10. 3G TO 2G HANDOVER FOR CS DOMAIN 4. 4.9. No handover will be tried towards the 2nd best cell.g. 4. As for "packet forwarding".9.06/EN Approved_Standard 17/Sep/2010 Page 59/244 .e. Therefore. Section 6. TCP). the consequence is that some packets may be lost. Definition This parameter indicates if the PS handover toward a GSM cell is allowed.UMTS Radio Mobility Another handover will be tried as in the normal process.6 ACCESS NETWORK IMPACTS On the UTRAN Access side: • UE UTRAN DL measurement activation • support of one GSM neighbouring cells information (including BSIC and ARFCN) • support of relevant Iu RANAP procedures On the GSM Access side: • None (in this case.1 DESCRIPTION In this case the mobile connected to the CS domain is moved from a 3G cell to a 2G cell. End-to-end reliability is supposed to be provided by transport layer (e. possibly next time the handover criteria is evaluated and using "target cell choice" algorithm as specified. some packets will be lost during the handover.10.

UE NodeB RNC 3G-MSC/VLR 2G-MSC/VLR BSS RRC/ Measurement Report RANAP/ Relocation Required (CM2.UMTS Radio Mobility Anchor MSC 3G-MSC 2G-MSC Relay MSC SRNC Iub NodeB Abis 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. the serving RNC activates the relocation procedure towards the 3G-MSC. CM3. CM3. Passing on or copying of this document. old BSS to new BSS information) MAP/ Prepare Handover (Handover Request) BSSMAP/ Handover Request (CM2.06/EN Approved_Standard 17/Sep/2010 Page 60/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. When the handover decision is made. 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. The RELOCATION REQUIRED message contains the UE GSM capability (ClassMark 2 and 3). The request is forwarded to the target 2G BSS which allocates resources to support the call.

20.18.06/EN Approved_Standard 17/Sep/2010 Page 61/244 . which is transferred to the target BSS. or when leaving a UTRAN coverage spot. Old radio link(s) and associated AAL2 Cid(s) are released.10. 4. It also contains the cell load information group element if feature uRRM step 2 is activated.10. the RNC instructs the UE to perform intersystem cell reselection and re-originate the call on the 2G network (refer to 4.2 APPLICABILITY In this version. CS subscribers may be handed to 2G in case of UTRAN coverage holes. it has to send a HANDOVER FROM UTRAN FAILURE message on the channel that was used in the serving UTRAN cell(s).18.20.e.194. which will allow the mobile to synchronize to the cell when the handover is made in blind mode. in case the mobile is handed over 3G again.20. (3) Old resource release phase.10. triggered on radio alarm criterion.20).2 to 4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.10.4 4.10.3. RRC Speech Redirection: If a UE cannot successfully connect to the UTRAN (via RRC connection establishment) or in case of load or of emergency call.UMTS Radio Mobility The "old BSS to new BSS" information element contains the UE capability.4. In addition to providing this alarm-based 3G-2G handover for established calls.4 sections).3 TARGET CELL CHOICE Please refer to section 4.2 MEASUREMENTS CONFIGURATION Please refer to section 4. 4.1 ALGORITHM HO DECISION PROCESS Please refer to section 4.10. the 3G infrastructure may also move calls in the following use cases: iMCTA function decision (refer to section 4.3. BSIC and BCCH ARFCN). 4. 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. 3G to 2G handover for CS calls which have reached the call established state is a rescue type of mobility.3.10. Passing on or copying of this document. The handover is performed when the UE is successfully connected to the 2G system. 4.1 FAILURE CASES TARGET CELL SYNCHRONIZATION FAILURE If the mobile fails to access and synchronize on the target GSM cell.3 4. (2) Handover execution phase. 4. This message contains the target cell description (i.

Another handover will be tried as in the normal process. 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 . BCCH ARFCN) The HO fails on the target system RRC/ handover from UTRAN failure Figure 33: 3G to 2G handover for CS .e.06/EN Approved_Standard 17/Sep/2010 Page 62/244 . • The criteria for handover are no longer fulfilled.4.failure case Another handover will be tried as in the normal process. 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.e. In this case the RNC tries the handover to the strongest inter-frequency target. e. eligible GSM and inter-frequency target cells. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. CM3. i.10.failure case If allowed by parameter isGsmIratHoToNextBestCellAllowed. Passing on or copying of this document. 4. e.5 PARAMETERS The parameters are: Name Object/Class RadioAccessService Class3 activationHoGsmCsAllowed Definition This parameter indicates if the CS handover toward a GSM cell is allowed. CM3.g. The attempts are repeated until either • The relocation preparation has failed for the last eligible GSM cell • A follow-up measurement report contains both.UMTS Radio Mobility UE Serving NodeB Serving RNC Target BSC 2G-MSC 3G-MSC RRC/ Handover from UTRAN command (BSIC. the relocation preparation procedure ends up as follows: UE NodeB RNC 3G-MSC/VLR 2G-MSC/VLR BSS RRC/ Measurement Report RANAP/ Relocation Required (CM2.g.10.2 RELOCATION PREPARATION FAILURE It may happen the Relocation Preparation fails. 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. an event 2F indicates the end of the alarm condition. because the target GSM BSS has no resource left. i. In this case. 4. possibly next time the handover criteria are evaluated and using "target cell choice" algorithm as specified. old BSS to new BSS information) MAP/ Prepare Handover (Handover Request) BSSMAP/ Handover request (CM2.

IRATHO. Section 6. 3G TO 2G HANDOVER FOR CS+PS DOMAINS 4.5. This counter is a complement to counter IRATHO_AttRelocPrepOutCS.AttRelocPrepOutCS. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.6 ACCESS NETWORK IMPACTS On the UTRAN Access side: • support of relevant Iu RANAP procedures • support of relevant RRC procedures 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) 4.g.8 • PERFORMANCE MANAGEMENT IRATHO. but also deriving GSM channel type attributes from the RAB attributes. This implies not only message conversion.10.7 • CORE NETWORK IMPACTS BSSMAP to RANAP message interworking at the 3G-MSC level.11. 4. See also Section 4. The difference between IRATHO_AttRelocPrepOutCS and IRATHO. • 4.AttRelocPrepOutCS.NeighbRnc) Attempted relocation preparations for CS UMTS to GSM handover to the next best GSM cell. IRATHO.06/EN Approved_Standard 17/Sep/2010 Page 63/244 . 4. due to overload.AttRelocPrepOutCS. Passing on or copying of this document. IRATHO_AttRelocPrepOutCS is pegged on all attempted relocation preparations for CS UMTS to GSM handover.SuccRelocPrepOutCS.11.NextBestCell is pegged only if the relocation preparation has failed for one target GSM cell and the RNC retries the handover for the next GSM target cell.UMTS Radio Mobility isCellLoadInformationSendingAllowed isGsmIratHoToNextBestCellAllowed RadioAccessService Class3 RadioAccessService Class3 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.NextBestCell (-.NeighbRnc) Successful relocation preparations for CS UMTS to GSM handover to the next best GSM cell (CS interRAT Handover Attempt) from network point of view.1 4. e.10.1 DESCRIPTION GENERAL In this case the mobile is connected to both CS and PS domains.10. and is moved from a 3G cell to a 2G cell.11.NextBestCell (-.19.NextBestCell represents the actual number of handover attempts without repeated relocation preparation procedures.1.

Class A or DTM The real successful case (i. 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 PS service is handed over the target GSM cell in the same way as the "3G to 2G handover for PS" case.: • the mobile is requested by the SRNC to change cell (this is done implicitly through the "Handover from UTRAN" RRC procedure) • the mobile tries to re-establish the PS service in the target cell Class B In this case. the PDP context will remain active in the 3G-SGSN. Since the mobile will not detach nor deactivate the PDP context which were active in the source 3G-SGSN. Alternate use only.UMTS Radio Mobility GGSN Anchor MSC 3G-SGSN 3G-MSC 2G-MSC 2G-SGSN SRNC Iub NodeB Abis 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. Passing on or copying of this document.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 CS service is handed over the target GSM cell exactly as in the "3G to 2G handover for CS" case. and can support simultaneous traffic • DTM (Dual Transfer Mode): DTM is a subset of class A mode of operation. i.e.e. • class B: the mobile is attached to both GPRS and GSM services. the source RNC will not take into account the mobile GPRS capability in the handover decision algorithm. GSM CS and PS resource allocation are coordinated in BSC/PCU in order to simplify mobile implementation. the CS service is handed over to GSM and the PS service cannot be maintained.06/EN Approved_Standard 17/Sep/2010 Page 64/244 . In this mode. i. This case is not further considered in this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Remark: In this version. 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.

CM3.06/EN Approved_Standard 17/Sep/2010 Page 65/244 . CM3. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility 4. old BSS to new BSS information) MAP/ Prepare Handover (Handover Request) BSSMAP/ Handover request (CM2.2 SUCCESSFUL CLASS A/DTM CASE The next dataflow is an example of successful inter-MSC 3G to 2G CS+PS handover for a class A or DTM capable mobile. UE NodeB RNC 3G-MSC/VLR 2G-MSC/VLR BSS RANAP/ Relocation Required (CM2. 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 2G access and GPRS resource allocation GMM/ RA update request 3G-SGSN 2G-SGSN GTP/ SGSN ctx request RANAP/ SRNS ctx request RANAP/ SRNS ctx response GTP/ SGSN ctx response GTP/ SGSN ctx ack GMM/ RA update response 3 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 RANAP/ Iu release request RANAP/ Iu release command 4+5 RANAP/ Iu release complete Figure 36: 3G to 2G handover for CS+PS dataflow Passing on or copying of this document.11.1.

06/EN Approved_Standard 17/Sep/2010 Page 66/244 . which will be used by the mobile to synchronise on the target cell and decode the (P)BCCH for the PS service re-establishment. the serving RNC activates the relocation procedure towards the 3G-MSC. The handover command is sent from the target 2G to the UE via the MSC nodes and the serving RNC. Eventually. The handover command message contains the cell description (i. AAL2 Cid(s) associated to the CS domain are released. The request is forwarded to the target 2G BSS which allocates resources to support the call. the source SGSN may request the source RNC to forward the PS packets queued in the SRNC using the SRNS DATA FORWARD COMMAND message. The data flow above is only provided as an example. Upon receipt of the IU RELEASE COMMAND (PS): RNC TRelocResourceReleasePs 3Gto2Gtimer (set to 20 sec) 3G MSC/VLR RANAP/ Iu Release Command RANAP/ Iu Release Request RANAP/ Iu Release Command 3G SGSN Release of all CS and PS resources RANAP/ Iu Release Complete parallel 4+5 RANAP/ Iu Release Complete UE 3G MSC/VLR 3G SGSN Upon receipt TRelocResourceReleasePs3Gto2Gtimer expiration: Passing on or copying of this document.e. the RNC behaviour is the same as for the "3G to 2G PS handover" case. the registration is accepted. Upon receipt of the IU RELEASE COMMAND (PS) or RelocResourceReleasePs3Gto2Gtimer expiration. the RNC arms immediately a timer called RelocResourceReleasePs3Gto2Gtimer (optimized at 20 sec) and sends an IU RELEASE REQUEST (PS) message. (2) CS Handover execution phase. target cell BSIC and BCCH). The handover is performed when the UE is successfully connected to the 2G system. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the Iu CS release (4) may be requested before the PS registration (3). • Iu PS resource release. The order of the different phase may be different as compared to a real case. and the PS data transfer is resumed. In this release: upon receipt of message IU RELEASE COMMAND (CS). As for the "3G to 2G handover case". the RNC coordinates release of old CS and PS resources. In that case. When the handover decision is made.UMTS Radio Mobility (1) CS Handover preparation phase. (3) PS service re-establishment: The UE performs a packet access in the 2G new cell. (4) + (5) coordinated release of old CS + PS resources • Old radio links are released • Iu CS resource release. For example.

because of limited UE capability (class B or C). This case is further described in the [unsuccessful case] section. In the CS+PS case. corresponding to the highest value. The following dataflow illustrate the 1st case: Phase 1 and 2 (handover preparation and execution) are performed as in the successful case. The phase (3) “PS service reestablishment” does not occur.11. In any case the RNC releases the CS and PS resources: phase “(4)+ (5) coordinated release of old CS and PS resources”.1. 4.e. or because the target cell cannot accept or support GPRS access) Two timers (one for the PS domain. one for the CS domain) are implemented in the RNC to request a release of UTRAN resources to the relevant CN domain. Passing on or copying of this document.4 HANDLING UNSUCCESSFUL CASES Iu connections timers In order to cover the following case: • the mobile is completely lost (i. In phase 3 and 4. As the RNC sends an IU RELEASE REQUEST to the 3G-SGSN. when the "Iu release" timer elapses.UMTS Radio Mobility RNC TRelocResourceReleasePs 3Gto2Gtimer (set to 20 sec) 3G MSC/VLR RANAP/ Iu Release Command RANAP/ Iu Release Request 3G SGSN 4+5 Release of all CS and PS resources RANAP/ Iu Release Complete UE 3G MSC/VLR 3G SGSN 4.11. the handover has failed and the mobile has not returned to the old channel) • the PS service is lost during HO (e.3 SUCCESSFUL CLASS B CASE In this case the PS service will not be handed over the 2G target cell. only one timer is started.1. the RNC will receive an IU RELEASE COMMAND from the 3G-SGSN or will experience the timeout RelocResourceReleasePs3Gto2Gtimer (set to 20 sec). the source RNC requests for both CS and PS Iu release.g.06/EN Approved_Standard 17/Sep/2010 Page 67/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.

In which case. both Iu-CS and PS connections (and associated UTRAN resources) are released. Following successful CS handover the Core Network commands a release of the Iu.06/EN Approved_Standard 17/Sep/2010 Page 68/244 .UMTS Radio Mobility UE NodeB RNC 3G-MSC/VLR RANAP/ Relocation Required (CM2. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. old BSS to new BSS information) MAP/ Prepare Handover (Handover Request) 1 RANAP/ Relocation command (handover command) MAP/ Prepare Handover ack (Handover Request) 2 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. This release is not processed until the "Iu release timer" elapses. CM3. Passing on or copying of this document.

it is not expected the PS service can be resumed in the new cell before the CS service. 4.2 APPLICABILITY See 4.06/EN Approved_Standard 17/Sep/2010 Page 69/244 .11. The CS service goes on. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. a 3G to 2G PS+CS handover is tried. In that case.10. From a source UTRAN point of view. and if the handover conditions are still valid.2 [3G To 2G Handover for CS Domain] section APPLICABILITY Passing on or copying of this document. whereas the PS service has failed. and if the handover conditions are still valid. CM3. nothing is done until the PS RAB is established. as in the CS only case. Once the CS RAB is setup.. nothing specific is done. • The handover for the CS service is successfully performed.failure case HO failure case The possible failure cases are the following: • The synchronisation on the new CS channel fails. the mobile returns on the old channel using the Handover from UTRAN failure message and the relocation is cancelled by the source RNC. In this case. a 3G to 2G PS+CS handover is tried.. or because GPRS is not supported by target cell .UMTS Radio Mobility UE NodeB RNC 3G-MSC/VLR RANAP/ Relocation Required (CM2. but the PS registration fails (reject from the new SGSN. old BSS to new BSS information) MAP/ Prepare Handover (Handover Request) 1 RANAP/ Relocation command (handover command) Iu release timer MAP/ Prepare Handover ack (Handover Request) 2 RRC/ Handover from UTRAN command (handover command (cell description)) RANAP/ Iu release command 3G-SGSN RANAP/ Iu release request RANAP/ Iu release command 3 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 . nothing is done until the CS RAB is established. 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. Once the PS RAB is setup. If a 3G to 2G handover decision is made while a CS call is active and a PS call is being setup.). this case is identical to the Class B mobile handover case. Due to the time needed to resynchronise the CS service.

UMTS Radio Mobility 4. 4.19. Section 6.1 DESCRIPTION DATAFLOW In this case the mobile connected to the network in PS mode is moved from a 4G eNodeB cell to a 3G cell. as compared to the 3G to 2G PS or CS handover.3 4.5. 4.4 Refer to: PARAMETERS Section 4. Since the Gs interface is not supported.3.11.3.11.5 ACCESS NETWORK IMPACTS On the UTRAN Access side: • UE UTRAN DL measurement activation • support of GSM neighbouring cells information (including BSIC and ARFCN) • support of relevant Iu RANAP procedures • support of relevant RRC procedures On the GSM Access side: • No functional impact • Only impact is a new counter on 3G to 2G 4. 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" 4.11.2 MEASUREMENTS CONFIGURATION Please refer to section 4.11.3 TARGET CELL CHOICE Please refer to section 4.12.06/EN Approved_Standard 17/Sep/2010 Page 70/244 .1 ALGORITHM HO DECISION PROCESS Please refer to section 5.11.11.6 CORE NETWORK IMPACTS No specific impact. It has to be noted that the UE classmark (support of class A or DTM) or the target cell GPRS capability is not taken into account in the decision process.20. the 2 handover procedures are seen as independent.19.12.12. 4. 4G TO 3G RELOCATION FOR PS DOMAIN 4.11. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.1.9.1 4.3. Passing on or copying of this document. 4.

S4 or S5/S8 interfaces. i. The next dataflow is an example of 4G to 3G relocation request. Without direct tunnelling) The PDN GW provides the functions of a GGSN for the SGSN..g. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Passing on or copying of this document.e.06/EN Approved_Standard 17/Sep/2010 Page 71/244 . FTP) Anchor of the IP session Figure 39: 4G to 3G handover (Interworking with pre-Rel. Interworking is provided only with Gn and Gp interfaces but no S3. these Gn/Gp SGSNs provide no functionality that is introduced specifically for the EPS or for interoperation with the EUTRAN. VPN. 8 legacy SGSN.UMTS Radio Mobility GERAN BTS BTS Abis BSC BSC Gb • MME acts like a SGSN • PGW acts like a GGSN • MME & PGW have to support Gn interface (GTPv1-c support) UTRAN SGSN SGSN RNC RNC Pre-Rel 8 Pre Pre-Rel 8 Iu-ps Gn (signaling) Gr NB NB Iub S6a HSS HSS Pre-R8 Interfaces Rx MME MME S1-MME S11 E-UTRAN S1-U S5 S10 Gn (user) PCRF PCRF Gx Application Function SGi eNB eNB Control plane User plane SGW SGW PGW/GGSN PGW/GGSN Data Services (e.

and Bearer Configuration to ALU standard 4 Figure 40: 4G to 3G handover for CS dataflow (1) Handover preparation phase.06/EN Approved_Standard 17/Sep/2010 Page 72/244 . GCSI) to the new SGSN. PDP context contains GGSN Address for User Plane and Passing on or copying of this document.UMTS Radio Mobility UE NodeB RNC SGSN MM E eNB S1 / Handover Required (Source RNC to target RNC transparent information) GTP/ Forward Relocation request (Handover Required) SCCP/ Connection Request SCCP/ Connection Confirm RANAP/ Relocation request (Source RNC to target RNC transparent information) 1 NBAP/ Radio Link Setup Request NBAP/ Radio Link Setup Response AAL2/ ERQ AAL2/ ECF RANAP/ Relocation request Ack (Handover to UTRAN command) GTP/ Forward Relocation response (Handover Request Ack) S1/ Handover command (Handover to UTRAN command) RRC mobility from EUTRAN command (Handover to UTRAN command) RRC/ Handover to UTRAN complete RANAP/ Relocation Detect 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 Complete GTP/ Forward Relocation Complete () GTP/ Forward Relocation Complete Acknowledge () 2 S1 / UE context release command S1 / UE context release complete 3 Follow up procedures after successful handover from E-UTRAN to UMTS: • Security Update • RRC measurement setup • UE capability enquiry • Mobility Update • In case of Default Configuration: Radio Link. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Tunnel Endpoint Identifier Signalling. and the target SGSN. PDP Context. MM Context. RAN Transparent Container. When the handover decision is made. the source eNodeB sends a handover required towards the source MME to request the CN to establish resources in the target RNC. RANAP Cause. The MME sends a Forward Relocation Request message (IMSI. Target Identification.

12.331 §14.331 §10.42c) • START-PS • Inter-RAT UE radio access capability (25. The SECURITY MODE COMMAND procedure is used to trigger integrity protection in UMTS. The Ranap Relocation Request message contains the IE “source RNC to target RNC transparent container” including the RRC container IE “Inter rat handover Info with inter Rat UE capabilities”.42) • Security capability (25.37) • Ciphering algorithm capability • Integrity protection algorithm capability • Pre-defined configuration status information (not used) • UE security information (not used) • UE security information2 (25.8.4.3. The timer Treloc complete is started.1.1) • Handover to UTRAN Info (25.7) • Mobile Station classmark 2 (not used) • Mobile Station classmark 3 (not used) • nb of Iu instances (=1) • Relocation type (= UE involved) • target cell Id • cell load information group (not used) • RAB to be setup List • Integrity protection information Passing on or copying of this document. The handover command message contains the target cell resource description.413 §9.06/EN Approved_Standard 17/Sep/2010 Page 73/244 .12.1.331 §10. (2) Handover execution phase. RAB context). .UMTS Radio Mobility Uplink TEID for Data.12.1) • UE Radio Access capability (25.2.1 ALGORITHM RELOCATION REQUEST MESSAGE STRUCTURE RELOCATION REQUEST (25.3. The timer Treloc complete is stopped by the SGSN. and the IE “Encryption Information”. The UTRAN MOBILITY INFORMATION procedure is used to provide the UE with PS domain Location Information. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. The S1 Handover Command message is sent to the source eNB including the RRC Handover to UTRAN message.331 §14. The target SRNC confirms to the CN that the SRNC relocation has been successful by sending the Ranap Relocation Complete message. Old radio link(s) in LTE system are released.3.3. The HANDOVER TO UTRAN COMMAND RRC message is sent from the target 4G to the UE.413 §9.3. (3) Old resource release phase. This message must also contain the IEs “Integrity Protection Information”.2. The RNC checks and allocates the resources needed in order to become the SRNC (RRC context. SCCP connection is established between the SGSN and the RNC.3.10) • CN Domain Indicator (M): PS Domain. which represent the information used for the ciphering and integrity protection. • source RNC to target RNC transparent container (25. so that the mobile can initiate or resume PS activity.2 4.331 §10. (4) Post Handover Procedures. The successful allocation of resources is confirmed to the CN via the Ranap Relocation Request Acknowledge message. • • • • Security Update RRC measurement setup UE capability enquiry Mobility Update 4.28) • RRC information to target RNC (25. The handover is performed when the UE is successfully connected to the 3G system. The RRC Handover Command message is included in the IE “target RNC to source RNC transparent container”.331 §10. The Source to Target Transparent Container received from eNodeB is indicated as RAN Transparent Container.3.12.

this IE will be not decoded by the RNC if receivei) Global CN-ID (only used when relocation comes from 2G) • • Note 1: The two IE were created in Rel 5/6 to reduce the size of the information reported by the UE on the “GSM air”.06/EN Approved_Standard 17/Sep/2010 Page 74/244 . see Note 1) • UE radio access capability comp2 (not used. • Iu Transport Association (GTP TEID: to be used) • Alternative RAB Parameter Values (not used) • GERAN BSC Container (not set: used only when coming from 2G) • E-UTRAN Service Handover (As UA07. RAB to be setup List • Synchronisation Indicator (Not used. 4. • UE security information2 (START-PS values to be used) • UE radio access capability compressed (not used. a resource may not be available.2.2 RELOCATION REQUEST REJECTION In this version.6. There is a ciphering mismatch with parameter FromEutraRelocationCiphering. In case of congestion.2.1) concerns the following IE: • • CN Domain Indicator: PS Domain. a RELOCATION REQUEST rejection by the target RNC can happen in the following cases: The incoming relocation from E-UTRA is not allowed (isEutraToUtraHhoAllowed=FALSE). So the proposal is to not use them in E-UTRA when asking the UE to report its UTRAN capabilities. However. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2 uses the 3GPP Iu Rel 7. Source RNC To Target RNC Transparent Container.3 TARGET RESOURCE ALLOCATION IN RNC Unlike the 2G 3G relocation.12.1. see Note 1). • In case of failure of the NBAP Radio Link setup (reception of radio link setup failure or no answer) The RELOCATION REQUEST has not been issued by a E-UTRAN There is no explicit information element in the RELOCATION REQUEST message which indicates from which technology (i. only significant for speech) • Data Volume Reporting Indication (not used) • PDP type information (not used) • UP Mode Versions (to be used). There is no resource suitable or available in target RNS to support the incoming call • In case of a RAB or a Rab combination not supported by ALU RNC • Based on the “RAB to setup list” contained by the RELOCATION REQUEST message.e.UMTS Radio Mobility • Encryption information The difference with the CS 2G 3G relocation (4. We don’t guess it will be an issue in E-UTRA.12. GSM or E-UTRAN) the message is issued.3. the RNC tries to allocate a suitable resource based on CAC algorithm. Passing on or copying of this document. it is deduced by the target RNC by checking the two following parameters: • CN Domain indicator IE = PS • The presence of E-UTRA Capability in IE “Inter-RAT UE radio access capability” in “INTER RAT HANDOVER INFO WITH INTER RAT CAPABILITIES” received in the Source RNC To Target RNC Transparent Container Ranap IE 4. several RAB can be received in the the “RAB to be setup list” in the RELOCATION REQUEST message.

there is only one target cell to be considered by the target RNC Besides.e.UMTS Radio Mobility The maximum of PS Rab supported simultaneously is 3 by taken into the following combinations. RLC AM HFN. resulting from the conversion of Kc (LTE ciphering key) by the MME.06/EN Approved_Standard 17/Sep/2010 Page 75/244 . Ciphering is started by the mobile immediately after receiving the HANDOVER TO UTRAN COMMAND message. RLC AM HFN. Based on RAB parameters requested by the Core Network. The necessary information is passed from the source eNb 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-PS (used to initialise the 20 MSBs of all hyper frame numbers: MAC-d HFN. RLC UM HFN.5 INTEGRITY Integrity is started by the RNC immediately after receiving the HANDOVER TO UTRAN COMPLETE RRC message.4 CIPHERING The necessary information is passed from the source eNodeB 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-PS (used to initialise the 20 MSBs of all hyper frame numbers: MAC-d HFN. In this case. there is no pool of reserved capacity for incoming relocation from 4G. i. 4. The Multi PS data Rb combination supported are: • Downlink DCH (PS + PS) / Uplink DCH (PS + PS) • Downlink DCH (PS + PS + PS)/ Uplink DCH (PS + PS + PS) [USA Market] • HS-DSCH (PS + PS) + E-DCH (PS + PS) [Global Market + Korean Market] • HS-DSCH (PS + PS) + Uplink DCH (PS+PS) • HS-DSCH (PS + PS + PS) + Uplink DCH (PS+PS+PS) [USA Market] The PS services type combination may be: • PS streaming + PS I/B signalling + PS I/B • PS I/B signalling + PS I/B • PS I/B + PS I/B • PS streaming + PS I/B • PS I/B + PS I/B + PS I/B The target resource allocation algorithm in target RNC for incoming calls from 4G takes into account the following limitations: • Due to the RELOCATION REQUEST message structure. RRC HFN) is provided in the “RRC container” IK (UMTS Integrity Key) is provided by the MME in the Relocation Request (“Integrity protection information“ IE). resulting from the conversion of KASME (LTE ciphering key) by the MME. the algorithm for RAB to RB mapping is the same as used for call initiation.2. RLC UM HFN. the RNC will choose a Radio Bearer configuration among the ones which are supported in this version.12. RRC HFN) is provided in the “RRC container” CK (UMTS ciphering Key) is provided by the MME in the RELOCATION REQUEST (“Encryption information “ IE). in this version: The resource allocation for incoming relocation from 4G follows the same algorithm as for initial call setup resource allocation. Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 4.12.2.

06/EN Approved_Standard 17/Sep/2010 Page 76/244 . 4.12.6 DEPENDENCIES WITH LTE For this procedure to be working correctly. UE NodeB RNC SGSN MM E eNB S1 / Handover Required (Source RNC to target RNC transparent information) GTP/ Forward Relocation request (Handover Required) SCCP/ Connection Request SCCP/ Connection Confirm RANAP/ Relocation request (Source RNC to target RNC transparent information) RANAP/ Relocation failure GTP/ Forward Relocation failure S1/ Handover preparation failure Figure 41: 4G to 3G handover preparation failure case 4.12.2.3.3 4. it is mandatory the MME supports translation from EPS bearer to PDP contexts supported by SGSN and UTRAN.1 FAILURE CASES RELOCATION REJECTED BY TARGET RNC If the relocation preparation phase fails. a relocation failure is sent from RNC to the SGSN.12.12.4 PARAMETERS The parameters are: Name isEutraToUtraHhoAllowed Object/Class RadioAccessService Class3 Definition This parameter indicates whether the 4G To 3G PS Handover is allowed within the RNC YES: incoming relocation request from 4G are processed Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility UE NodeB RNC RRC/ Handover to UTRAN complete RRC/ Security Mode Command RRC/ Security Mode Complete 4.

5 • • • ACCESS NETWORK IMPACTS support for incoming relocation procedures (involving SCCP connections initiated by the CN) ability to format the HANDOVER TO UTRAN message (as defined in the RRC specification) start of security procedure (ciphering & integrity) at the end of the handover execution at RRC level 4. UE connection release by requesting the UE to access a given Fdd cell (selected in blind mode or with measurements). cipheringDisabledIgnore. cipheringEnabled) FromEutraRelocationCiphering RadioAccessService Class3 4.12. In UA07. it has no way to improve the CS establishment by postponing some procedures.06/EN Approved_Standard 17/Sep/2010 Page 77/244 . A specific Ranap cause is created in Ranap Rel8 “CS fallback triggered”.12.2. MME will map S1AP "CSFB Triggered" to the RANAP "Relocation Triggered. 4.1. 2. As the RNC does not know the relocation cause “CS fallback triggered’.12. 3.UMTS Radio Mobility NO: incoming relocation requests from 4G are rejected This parameter is used to indicate if ciphering is allowed during SRNS relocation from LTE within the RNC. These procedures have no impact on the UTRA. CS FALLBACK An UE camping on E-UTRA may be moved by the eNB by using the following procedures: UE connection release by requesting the UE to select a UTRA network.6 • CORE NETWORK IMPACTS Support of the Gn Interfaces: SGSN–MME and SGSN-P_GW. Enum( cipheringDisabledRejected. as the Iu is based on Rel 7. SRNS relocation from E-UTRA to UTRA followed by a CS Rab Assignment. If the value is cipheringDisabledRejected the ciphering is not allowed and the relocation procedure is rejected If the value is cipheringDisabledIgnore the ciphering is not allowed and the relocation procedure continue normally If the value is cipheringEnabled the ciphering is allowed and the relocation procedure continue normally.7 1. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. The CS fallback data flows are described in [A9]. this cause value should not be received. Passing on or copying of this document.

inter-frequency inter-RNC hard handover makes use of the Relocation procedure (UE involved).13. At some point. e.13. This may be used.06/EN Approved_Standard 17/Sep/2010 Page 78/244 . the SRNC decides to hand the UE over another cell controlled by another RNC and using another frequency (f2). 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. MSC Iu SRNC MSC RNC Iub NodeB 0 NodeB 1 NodeB 2 f1 Target radio link f2 UE Figure 42: inter-frequency inter-RNC handover As described in the following flow diagram. INTER-FREQUENCY INTER-RNC HANDOVER WITHOUT IUR 4.1.g.UMTS Radio Mobility 4.13. controlled by the SRNC.1 4. the mobile is using 2 radio links from NodeB0 and NodeB1. being controlled by different RNC not connected to an Iur. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.1 DESCRIPTION GENERAL The purpose of this mobility case is to allow user mobility between cells of different frequency. in the 2 following cases: • inter-PLMN mobility • intra-PLMN mobility between 2 frequency layers In the example below.

Number of Iu instances) SCCP/ Connection Request SCCP/ Connection Confirm RANAP/ Relocation request (RB parameters. Number of Iu instances. 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) Figure 43: inter-frequency inter-RNC handover . a request for relocation is issue by the serving RNC. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 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.UMTS Radio Mobility UE Serving NodeB Serving RNC Target NodeB Target RNC CS CN node Based on the inter-PLMN handover criteria.06/EN Approved_Standard 17/Sep/2010 Page 79/244 . RAB parameters) On reception of Relocation Request.relocation preparation Passing on or copying of this document. When accepted.

relocation execution Remarks: • From the RELOCATION REQUEST messages received. and new measurements are setup by the new SRNC. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. This is all done through the Radio Bearer Reconfiguration RRC procedure. RANAP/ Relocation command (Radio Bearer Reconfiguration) RRC/ Radio Bearer reconfiguration (RB to reconfigure. Setup) … Once the mobile is successfully established on the target resource. a new RNTI is allocated to the mobile. the Alcatel-Lucent target RNC deletes every measurement configured previously in the source RNC once relocation is successfully performed. • Regarding measurement configuration.e. integrity (and possibly) ciphering are activated. Physical channel configuration) RRC/ Radio Bearer reconfiguration complete RANAP/ Relocation detect RANAP/ Relocation complete Old measurement Ids are released.06/EN Approved_Standard 17/Sep/2010 Page 80/244 . In case there is no matching configuration (i. RRC/ Measurement Control (id1. Release) … RRC/ Measurement Control (id1. All the needed measurements are then setup. Release) RRC/ Measurement Control (id2. Passing on or copying of this document.UMTS Radio Mobility Relocation execution UE Serving NodeB Serving RNC Target NodeB Target RNC CN node During the relocation execution phase. 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 44: inter-frequency inter-RNC handover . 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. the Alcatel-Lucent target RNC tries to identify the Radio Bearer configuration which is the closest to the requested configuration. Setup) RRC/ Measurement Control (id2.

4 FAILURE CASES In case the inter-frequency handover is not successful (e.3. and this cell has to fulfill the process described in section 4. the mobile fails to synchronise on the target cell) there is no second try or other try to a second best eligible cell.13.g.3. 4.19.19. 4. In case of CS+PS handover. the target cell choice decision is based on inter-frequency measurements from the mobile. 4. meaning that a target cell for inter-frequency handover as described in this section has to be a cell reported by the mobile.5 Name PARAMETERS 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 Refer also to Section 4. Passing on or copying of this document. 4. CS and CS+PS connections.3.13.19).13. possibly using compressed mode. There is no support for blind handover. HS-DSCH or E-DCH.13. outgoing inter-frequency handover inter-RNC is triggered upon iMCTA decision (refer to section 4.2 APPLICABILITY In this version. 4.1 ALGORITHM HO DECISION PROCESS Please refer to section 4.13.2 MEASUREMENTS CONFIGURATION Please refer to section 4.13. This algorithm is applicable to PS.06/EN Approved_Standard 17/Sep/2010 Page 81/244 .19.UMTS Radio Mobility 4.3 4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.13. with check of global activation parameters isHsdpaHHOwithMeasAllowed and isEdchHHOwithMeasAllowed. the handover is aborted.19. if the handover fails for one of the domains.3 TARGET CELL CHOICE In this version of the document. The feature is applicable for calls on DCH.

4. It is applicable in full-event mode only.3. HS-DSCH or E-DCH.13.UMTS Radio Mobility Section 6.1 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. where it’s not possible to communicate via Iur between two RNCs controlling cells of the same frequency. for IOT reasons between two RNCs from different manufacturers. Passing on or copying of this document. the procedure is exactly the same as for an inter-freq inter-RNC HHO (refer to § 4.14.3 4.06/EN Approved_Standard 17/Sep/2010 Page 82/244 . e. 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.6 • • • ACCESS NETWORK IMPACTS Support for out-going/incoming relocation to/from 3G for PS.14.1 for detailed description). with check of global activation parameters isHsdpaHHOwithMeasAllowed and isEdchHHOwithMeasAllowed.14. • The Iur interface provisioned between 2 RNCs is not in an operational state. When all the conditions are met.14.g.2 APPLICABILITY The feature is applicable for calls on DCH. 4. Once the intra-frequency inter-RNC HHO condition is met.1 DESCRIPTION This feature introduces the capability to detect the need to hard handover a call from one cell to another cell of the same frequency. This status is checked only when receiving measurement reports and its change does not affect measurement configuration. CS and CS+PS services Support of inter-frequency compressed mode scheme Support for inter-frequency measurements 4. 4. but controlled by a different RNC without Iur. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.14. INTRA-FREQUENCY INTER-RNC HANDOVER WITHOUT IUR 4.g. It is applicable to all RABs combinations. It may be used e. in following situations: • Two different operators (PLMN) are using the same frequency in the same geographical area. the existing outgoing and incoming relocation procedures (UE involved) are invoked to execute the HHO.13.13.7 • CORE NETWORK IMPACTS Support for the relocation procedure in PS and CS domain 4.6. and they have set up national roaming agreements between them • In a single PLMN.

following check is done: If the cell to add has a better Ec/N0 than other cells of the set and its Ec/N0 and RSCP are greater than a minimumCipchEcNoValueForHho and minimumCipchRscpValueForHho respectively. then a HHO with this target cell is decided. if all activation parameters allow it.3.4 PARAMETERS Object/Class RadioAccessService Class3 RadioAccessService Class3 IntraFreqTargetCellP arams (DlUserService) Class 3 IntraFreqTargetCellP arams (DlUserService) Class 3 FullEventRepCritHho MgtEvent1AWithoutI ur (MeasurementConfCl 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 Name isIntraFreqInterRncHhoOnIurLinkDownAllo wed isIntraFreqInterRncHHOAllowed minimumCpichEcNoValueForHHO minimumCpichRscpValueForHHO amountRep Passing on or copying of this document. 4. a SHO cannot occur. In that case.1 HO DECISION RECEPTION OF MEASUREMENT REPORT MEASID 1 On receipt of a measurement report with measId = 1 to add a cell from a neighbouring RNC in the monitored set. 4.2 MEASUREMENT CONFIGURATION In order to separate SHO from HHO conditions. CIO is used. It is configured with specific parameters (refer to § 4. no handover (neither HHO or SHO) is attempted.3. then a HHO with this target cell is decided.06/EN Approved_Standard 17/Sep/2010 Page 83/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. it is configured at the same time as other events 1x with measId = 1.UMTS Radio Mobility 4.14. In that case. and if the Iur interface is disabled.3.14. Otherwise.3 4.14.14. Otherwise.14. no handover (neither HHO or SHO) is attempted. following check is done: If the cell to add has a better Ec/N0 than other cells of the set and its Ec/N0 and RSCP are greater than a minimumCipchEcNoValueForHho and minimumCipchRscpValueForHho respectively.3. 4. a SHO cannot occur.3. a new intra-frequency measurement is introduced. It configures event1A with measId = 16 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). If needed. if all activation parameters allow it.14.3.4).2 RECEPTION OF MEASUREMENT REPORT MEASID 16 On receipt of a measurement report with measId = 16 to add a cell from an isolated neighbouring RNC in the monitored set.

06/EN Approved_Standard 17/Sep/2010 Page 84/244 .6.UMTS Radio Mobility ass) Class 3 FullEventRepCritHho MgtEvent1AWithoutI ur (MeasurementConfCl ass) Class 3 FullEventRepCritHho MgtEvent1AWithoutI ur (MeasurementConfCl ass) Class 3 FullEventHoConfHh oMgtEvent1AWithou tIur (UsHoConf) Class 3 FullEventHoConfHh oMgtEvent1AWithou tIur (UsHoConf) Class 3 repInterval Interval between 2 similar reports for amount reporting mgmt of intraFreq-interRnc Event in Full Event Mode maxNbReportedCells Maximum number of reported cells to configure in Reporting Cell Status for intraFreq-interRnc Event in Full Event Mode timeToTrigger hysteresis cpichEcNoReportingRange FullEventHoConfHh oMgtEvent1AWithou tIur (UsHoConf) Class 3 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. INTER-FREQUENCY INTRA-RNC HANDOVER 4.15.6 CORE NETWORK IMPACT Refer to § 4.1 4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.7.15.14.13.5 ACCESS NETWORK IMPACT Refer to § 4.14.1. 4. RNC f1 f2 Passing on or copying of this document.13.1 DESCRIPTION GENERAL This mobility case applies to Multilayer deployment in a single operator. It is related to the conditions for the change of Primary Radio Link Reporting Range to configure for the triggering condition of the intraFreq-interRnc Event in Full Event Mode 4. 4.15.

an alarm hard handover towards the other frequency is triggered by the SRNC. the Radio Link Addition.UMTS Radio Mobility Figure 45: Hard Handover inter-frequency intra-RNC In this case. Once connected. 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. Similarly.06/EN Approved_Standard 17/Sep/2010 Page 85/244 . using another frequency. an inter-frequency intra-RNC hard handover may also be performed from f2 to f1 in case of lack of f2 coverage. 4. as in an “outdoor to indoor” mobility case.1. NodeB 0 and NodeB 1 may be the same network node. a new radio link is set up on the new target NodeB. as in the figure below. e. as UE are moving out of the smallest frequency spot (f1 as in the picture above). 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 NodeB 0 NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp 2 Figure 46: Hard Handover inter-frequency intra-RNC dataflow In the first step. depending on the current active set) are deleted.2 OVER THE IUR The source and/or target cell may be controlled by another RNC.g. the Radio Bearer is re-configured and the old radio links (there may be more than one. In the figure above. the RNC control cells from different frequencies (f1 and f2). Setup or Deletion is performed over the Iur interface Passing on or copying of this document. f1 and f2 cells may be either 2 sectors of the same NodeB. In the second step. or belong to different NodeB.15. the subscribers remain on same frequency. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. However. SRNC DRNC f1 f2 Figure 47: Hard Handover inter-frequency intra-RNC – over the Iur In such a case.

using another frequency.UMTS Radio Mobility UE Drift NodeB1 RRC/ Measurement Report 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 UE Drift NodeB0 Drift RNC Serving RNC RNSAP/ Radio Link deletion req NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp AlCAP Iub Transport Bearer Release 3 RNSAP/ Radio Link deletion resp AlCAP Iur Transport Bearer Release Figure 48: 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. In the figure above.06/EN Approved_Standard 17/Sep/2010 Page 86/244 . 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. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. In step (3) the old radio links (there may be more than one. In step (2) the Radio Bearer is reconfigured. Passing on or copying of this document. Drift NodeB 0 and Drift NodeB 1 may be the same network node.

15.2 APPLICABILITY In this version. the RNC will process a HHO through Iur after processing a reconfiguration towards DCH in case the call was established in HSPA.3 4.19). The RNSAP RL Addition procedure does not permit to reconfigure the DCH part of the call.5 (isInterFreqHandoverOverIurAllowed).4 FAILURE CASES In case the inter-frequency handover is not successful (e.1 ALGORITHM HO DECISION PROCESS Please refer to section 4.g.15.15. The Radio criteria algorithm for inter-frequency intra-RNC handover uses the same parameters with the same values as in the inter-RNC case. This algorithm is applicable to PS. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.19. 4. However for intra DRNC handover a relocation procedure (refer to section 4.3 CHOICE OF TARGET CELL Please refer to section 4. 4.UMTS Radio Mobility 4. 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. 4.5 PARAMETERS Intra DRNC handover will be enabled/disabled by the parameter defined in section 4.06/EN Approved_Standard 17/Sep/2010 Page 87/244 . Passing on or copying of this document. 4.3. inter-frequency hard handover intra-RNC is triggered upon iMCTA decision (refer to section 4. the mobile fails to synchronise on the target cell) there is no second try or other try to a second best eligible cell.3.15.3. the mobility procedure depends on the parameter isInterFreqHandoverOverIurAllowed: If the parameter isInterFreqHandoverOverIurAllowed is false. There is no new parameter associated to the “intra-RNC case” exclusively.16. CS and CS+PS connections.15.15. the RNC will process a SRNS Relocation "UE involved".13.5 (is3Gto3GWithoutIurAllowedForPS and is3Gto3GWithoutIurAllowedForCS). If the parameter isInterFreqHandoverOverIurAllowed is true.. 4.13) will be initiated towards the same target cell if the relocation is enabled according to section 4. The following restriction applies: In case the target cell is located on a D-RNC.19.2 MEASUREMENTS CONFIGURATION Please refer to section 4.15.19.

RSCP. We use SRNS Relocation “UE involved” instead (refer to § 4. Iur is not used for that type of handover.NeighbRnc Attempted outgoing inter-frequency hard handovers due to insufficient RSCP quality of the used frequency HHO.AttOutInterFreq.6 • • ACCESS NETWORK IMPACTS Support of inter-frequency compressed mode scheme Support for inter-frequency measurements 4. Passing on or copying of this document.SuccOutInterFreq.16.15. 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.06/EN Approved_Standard 17/Sep/2010 Page 88/244 .UMTS Radio Mobility 4.AttOutInterFreq / HHO.15. 4.SuccOutInterFreq.NeighbRnc Successful outgoing inter-frequency hard handovers due to insufficient RSCP quality of the used frequency HHO.NeighbRnc Total number of successful outgoing inter-frequency hard handovers HHO.RSCP / HHO.RSCP.EcNo / HHO.AttOutInterFreq. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 4. INTER-FREQUENCY INTER-RNC HANDOVER WITH IUR AND MEASUREMENTS In release UA05.NeighbRnc Total number of attempted outgoing inter-frequency hard handovers HHO.AttOutInterFreq.SuccOutInterFreq / HHO.SuccOutInterFreq.EcNo.AttOutInterFreq. SRNS Relocation “UE involved “ is still used if handover over Iur is disabled towards the target DRNC or as fallback option in case of the handover attempt over Iur having been unsuccessful.EcNo.7 CORE NETWORK IMPACTS None.13).SuccOutInterFreq.NeighbRnc Successful outgoing inter-frequency hard handovers due to insufficient Ec/No quality of the used frequency • • • • The counters are of cumulative type.EcNo / HHO. (CN is completely transparent to this procedure).RSCP / HHO. Inter-frequency handover over Iur is reintroduced in order to avoid interoperability issues which may occur in case of SRNS Relocation with other vendor’s RNCs.NeighbRnc Attempted outgoing inter-frequency hard handovers due to insufficient Ec/No quality of the used frequency HHO.AttOutInterFreq. – In UA07.15.SuccOutInterFreq.8 PERFORMANCE MANAGEMENT The following counters are defined: • • HHO.

2 FROM SRNC TO DRNC This scenario is characterized by the primary cell on f1 being controlled by the SRNC and the target cell on f2 cell being controlled by a DRNC. 4.UMTS Radio Mobility 4.06/EN Approved_Standard 17/Sep/2010 Page 89/244 .16. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.16. SRNC DRNC f1 f2 Figure 49: Hard Handover inter-frequency inter-RNC – from SRNC to DRNC Passing on or copying of this document.1.1 DESCRIPTION GENERAL The purpose of this mobility case is to allow user mobility between cells of different frequencies (f1 and 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 from DRNC to DRNC from DRNC to SRNC as detailed below.16.1.1 4. If the call is HSxPA then it needs to be reconfigured to DCH before the handover because direct handover from HSxPA to HSxPA is not supported towards a DRNC.

In step (2) the Radio Bearer is reconfigured.1. depending on the current active set) are deleted. In step (3) the old radio links (there may be more than one. 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. using another frequency.UMTS Radio Mobility UE Drift NodeB1 RRC/ Measurement Report 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 NodeB0 Serving RNC NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp 3 AlCAP Iub Transport Bearer Release Figure 50: 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. Passing on or copying of this document. If the call is HSxPA then it needs to be reconfigured to DCH before the handover because direct handover from HSxPA to HSxPA is not supported towards a DRNC.16.3 FROM DRNC TO DRNC This scenario is characterized by the primary cell on f1 being controlled by a DRNC and the target cell on f2 being controlled by another DRNC while the SRNC remains the same.06/EN Approved_Standard 17/Sep/2010 Page 90/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 4.

using another frequency.06/EN Approved_Standard 17/Sep/2010 Page 91/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Passing on or copying of this document.UMTS Radio Mobility SRNC DRNC 1 DRNC 2 f1 f2 Figure 51: Hard Handover inter-frequency inter-RNC – from DRNC to DRNC UE Serving RNC Drift NodeB1 RRC/ Measurement Report Drift RNC 2 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 1 Serving RNC RNSAP/ Radio Link deletion req NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp AlCAP Iub Transport Bearer Release 3 RNSAP/ Radio Link deletion resp AlCAP Iur Transport Bearer Release Figure 52: 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.

UMTS Radio Mobility In step (2) the Radio Bearer is reconfigured.06/EN Approved_Standard 17/Sep/2010 Page 92/244 .16.4 FROM DRNC TO SRNC This scenario is characterized by the primary cell on f1 being controlled by a DRNC and the target cell on f2 cell being controlled by the SRNC. 4. In step (3) the old radio links (there may be more than one. There is no need for HSxPA to DCH reconfiguration. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. SRNC DRNC f1 f2 Figure 53: Hard Handover inter-frequency inter-RNC – from DRNC to SRNC UE NodeB 1 Drift RNC RRC/ Measurement Report NBAP/ Radio Link Setup req Serving RNC NBAP/ Radio Link Setup resp 1 AlCAP Iub Transport Bearer Setup 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. If the call is HSxPA then it can be handed over directly with HSxPA being kept.1. The radio link belonging to the previous primary cell is to be deleted over Iur as depicted in figure above. depending on the current active set) are deleted.

depending on the current active set) are deleted.2 APPLICABILITY In this version. the RNC will process a SRNS Relocation "UE involved". This algorithm is applicable to PS. This radio link is to be setup directly over Iub without Iur being involved. In step (3) the old radio links (there may be more than one.1 ALGORITHM HO DECISION PROCESS Please refer to section 4. In step (2) the Radio Bearer is reconfigured.16.3 4. the RNC will process a HHO through Iur after processing a reconfiguration towards DCH in case the call was established in HSPA (refer to section 4.19. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the mobility procedure depends of the isInterFreqHandoverOverIurAllowed parameter value: If the parameter isInterFreqHandoverOverIurAllowed is false.15.06/EN Approved_Standard 17/Sep/2010 Page 93/244 . whatever the location of the current active set. When the target cell is on D-RNC. If the parameter isInterFreqHandoverOverIurAllowed is true.19.16. 4. 4.16. using another frequency.3.19).UMTS Radio Mobility UE Drift NodeB0 Drift RNC Serving RNC RNSAP/ Radio Link deletion req NBAP/ Radio Link deletion req NBAP/ Radio Link deletion resp AlCAP Iub Transport Bearer Release 3 RNSAP/ Radio Link deletion resp AlCAP Iur Transport Bearer Release Figure 54: 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.2). CS and CS+PS connections.16.2 MEASUREMENTS CONFIGURATION Please refer to section 4. 4.3. Passing on or copying of this document. inter-frequency hard handover inter-RNC is triggered upon iMCTA decision (refer to section 4. The radio link belonging to the previous primary cell is to be deleted over Iur as depicted in figure above.

3.7 CORE NETWORK IMPACTS None. the mobile fails to synchronise on the target cell) there is no second try or other try to a second best eligible cell.8 do apply for the inter RNC scenarios as well. In context of inter RNC handover • the counters on per FDDCell basis will be pegged if the handover is performed from the SRNC to a DRNC • the counters on per neighboring RNC basis will be pegged if the handover is performed from this neighboring RNC in DRNC role to another DRNC or to the SRNC 4. Used for both intra and inter RNC HHO. DESCRIPTION Passing on or copying of this document.8 PERFORMANCE MANAGEMENT The counters listed in section 4.16.19.1 SRNC is sending r7 RRC extensions which are not handled by the UA6 TRNC.g. handover from SRNC to DRNC or handover from DRNC to DRNC) a relocation procedure (refer to section 4.3 CHOICE OF TARGET CELL Please refer to section 4. (CN is completely transparent to this procedure).17.13. 4. The relocation is rejected and the call stays up. 4.5. SRNS RELOCATION – “UE NOT INVOLVED” Warning: SRNS Relocation “UE not involved” can be rejected when UA7. Name isInterFreqHandoverOverIurAllowed 4.5 PARAMETERS Object/Class Neighbouring RNC Definition Indicates if inter-frequency HHO over Iur is allowed.e.16. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.6 • • ACCESS NETWORK IMPACTS Support of inter-frequency compressed mode scheme Support for inter-frequency measurements 4.17. 4.16.16.4 FAILURE CASES In case the inter-frequency handover is not successful (e. 4. However if the target cell is on a DRNC (i.06/EN Approved_Standard 17/Sep/2010 Page 94/244 .16.16.15.1 See [R8].UMTS Radio Mobility 4.13) will be initiated towards the same target cell if enabled according to section 4.

The cell selection/reselection algorithm is not governed by HSDPA availability so it is not possible to guarantee that an HSDPA mobile will select the HSDPA layer (and vice versa a non-HSDPA mobile will select the non-HSDPA layer).17. PARAMETERS 4.17.17.17. The following features may trigger a redirection: • HSPA traffic segmentation (feature 27932) and its evolution redirection during RRC connection setup (75069/81213).1 REDIRECTION AT CONNECTION SETUP (IMCRA STEP 1) DESCRIPTION Mobiles in idle mode will select a layer according to radio conditions.18. Passing on or copying of this document. Before calling redirection features the overload function is processed.UMTS Radio Mobility 4.2 See [R8].18.06/EN Approved_Standard 17/Sep/2010 Page 95/244 . • 3G2G redirection for speech call (feature 13451) • 3G2G redirection for emergency call (feature 25145) • 3G2G redirection based on cell load (feature 34480) • Pre-emption process for DCH and HSDPA/HSUPA (feature 33322) These features are described in following sections.17.6 See [R8].1 4. ACCESS NETWORK IMPACTS 4. REDIRECTION FEATURES FOR TRAFFIC SEGMENTATION A redirection may be triggered upon a RRC Connection Request receipt without attempting to allocate resource on the current Fdd layer.4 See [R8]. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 4.3 See [R8]. ALGORITHM 4.5 See [R8]. If overload criterion is fulfilled (=rach is filtered before attempting CAC) no redirection applies.18. CORE NETWORK IMPACTS 4.1. APPLICABILITY 4.

the call is established normally. RRC state = CELL_DCH. RRC Cnx Request (AS Release Indicator = R5) Figure 55: Example of Redirection at RRC establishment UE Node B – twin cell RRC/ RACH / RRC connection Request (cause) RNC SGSN The RRC Connection Request message is received on cell A (frequency f1) NBAP/ RL Setup Request) NBAP / RL Setup Response The radio-link is setup on the twin cell (f2) of cell A (f1) No resources are allocated on cell A The RRC Connection Setup message contains the signalling bearers (DCCH) definition. RRC state = CELL_FACH. RRC/ RACH / RRC Connection Setup Complete Figure 57: redirection with establishment done in Cell_FACH The dataflow consists in making the mobile request again the RRC connection establishment in the frequency of the twin cell. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Following description explains the RRC traffic segmentation/redirection during RRC connection setup feature. RRC Cnx Setup (redirection -> f2) 2.06/EN Approved_Standard 17/Sep/2010 Page 96/244 . RRC Cnx Setup (redirection -> f1) f2 : HSDPA layer f1 : non-HSDPA layer 1. The RRC connection request is sent again in the new cell. U-RNTI. U-RNTI. the dataflow is the same as without redirection. RRC state = CELL_FACH) RNC SGSN The RRC Connection Request message initiated by the UE contains the establishment cause. Primary CPICH info = f2 cell Frequency info = twin cell frequency) RRC/ RACH / RRC Connection Setup Complete Figure 56: redirection from f1 to f2 with establishment done in Cell_DCH For establishment in Cell_FACH.UMTS Radio Mobility 1. The Primary CPICH info corresponds to the CPICH of the twin cell (frequency f2) The response is received on the twin cell (f2) RRC/ FACH / RRC Connection Setup (DCCH. U-RNTI. Passing on or copying of this document. The UE is redirected to the other layer (f2). RRC Cnx Request (AS Release Indicator = R4 or absent) 2. UE Node B RRC/ RACH / RRC connection Request (cause) RRC/ FACH / RRC Connection Setup (DCCH. frequency info=freq f2) RRC/ RACH / RRC connection Request (cause) RRC/ FACH / RRC Connection Setup (DCCH. On this second request. except that resources are reserved in the twin-cell and that the mobile is redirected thanks to the frequency info IE. normally in the twin cell but not necessarily.

For ‘Originating High Priority Signalling’ cause.UMTS Radio Mobility 4.18.18.e.1. The establishment cause ‘Registration’ will be set up in the originating cell. the HSPA calls are assigned to HSPA “pure” layers whatever their load. then the RNC evaluates the FDDCell parameter layerPreferredForR99 of the originating and all operational twin cells. More information is provided in Annex L of 24. The RRC redirection procedure uses a list of candidate twin cells (if no twin cell is operational then redirection is not triggered). using the cause ‘Registration’.18. no DCH cell. The segmentation is done only at the RRC Connection establishment. using “the follow-on” indicator at the end of the Location Update.2 INTERACTION WITH FOLLOW-ON / SUBSCRIBED TRAFFIC CLASS: The mobile may establish a signalling connection to perform a Location Update prior to the establishment of the RAB. it may be redirected to the right layer by iMCTA when traffic resumes. For all cells with layerPreferredForR99 = TRUE the RNC assumes HSPA Cell Capability = DCH. For example mobiles that are eligible to HSxPA are directed towards the HSxPA layer and the other ones are directed towards the non-HSxPA layer.1.2. 4.1.18. Especially.2 APPLICABILITY Mobiles are redirected to the right layer at RRC connection establishment.2. During the call. If isHspaCellLoadAllowedForImcra = FALSE and if the originating cell as well as all operational cells contained in the twinCellList are either HSDPA or HSUPA capable.3 EMERGENCY CALLS: Emergency calls are usually not redirected and are served on the layer selected by the mobile to limit the probability of call setup failure. Only in case that the RRC establishment fails on the originating cell due to CAC Passing on or copying of this document. Although the UE may use it for PS I/B calls according to what has been provisioned by the operator (QoS in Traffic Class set to ‘Subscribed Traffic Class’). this is useful if R99 carriers get unavailable e. If isHspaCellLoadAllowedForImcra = TRUE then the parameter layerPreferredForR99 has slightly different semantics: • HSPA load balancing towards this layer is allowed when the all HSPA “pure” layers are loaded. The RNC determines the HSPA cell capability as follows: HSPA Cell Capability DCH HSDPA Cell Configuration hsdpaActivation = FALSE hsdpaActivation = TRUE edchActivation = FALSE HSUPA hsdpaActivation = TRUE edchActivation = TRUE Table 2: HSPA Cell Capability For specific network configurations it can be useful to allow several layers to carry HSPA traffic but still to prefer some of the HSPA capable layers for R99 traffic.1 INTERACTION WITH CELL_FACH: If a UE in Always-On on Cell_FACH reselects another layer. the mobile uses the same RRC connection for the Location Update and the RAB establishment.g. • When the HSPA “R99 preferred” layers are loaded. due to automatic carrier switch-off. 4.06/EN Approved_Standard 17/Sep/2010 Page 97/244 . i.2. 4. redirection is performed by iMCTA. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.1. the call will also be set up in the originating cell.008. The segmentation is done by the RNC when a mobile tries to establish an RRC connection. In this case.

The HSDPA load is calculated from DL power and DL code: Dl power load formula: HSPA_dl_power_load = 1 . HSDPA MinBR and HSDPA I/B without MinBR (mib value).4 HSPA LOAD Since UA07. yellow. red.HSPA_dl_power_share HSPA_dl_power_share = dl power resource share available for next HSPA without GBR service = dl_load_power_avail_HSPA_wo_GBR_MinBR[ratio] div (nb_current_HSDPA_I_B_services + 1) With: • • • nb_current_HSDPA_I_B_services: Number of current HSDPA I/B services Dl_load_power_avail_HSPA_wo_GBR_MinBR[ratio] = (max_tx_power_cell – dl_power [R99 + HSDPA GBR]) div max_tx_power_cell dl_power[R99+HSDPA GBR] = Total Transmitted Carrier Power of all codes not used for HSDPA and E-DCH + HS-DSCH required power needed to ensure the GBR power.red2YellowHSPAPwrDlLoadThreshold . For HSDPA load four load colors are supported: green. Note that a code block consists of a number of successive SF16 codes. TotalHsdpaUsedSF16: The minimumnumber of SF16 codes that are allocated in use for HSDPA in one cell calculated based on HSDPA GBR.Black2RedHSPACodesDlLoadThreshold • DL HSPA load = max (HSPA DL Power Color.06/EN Approved_Standard 17/Sep/2010 Page 98/244 . This is an integer value.Black2RedHSPAPwrDlLoadThreshold • HSPA DL Codes Color: Calculated ‘HSPA dl codes Load’ and the color transitions defined by parameters .2 the HSDPA load is considered for HSPA I/B calls by iMCRA load based decisions if enabled via parameter isHspaCellLoadAllowedForImcra.1. black The RNC determines the HSPA downlink load colors from • HSPA DL Power Color: Calculated ‘HSPA dl power Load’ and the color transitions defined by parameters .yellow2RedHSPAPwrDlLoadThreshold .green2YellowHSPAPwrDlLoadThreshold . HSPA DL Codes Color) Passing on or copying of this document. Dl code load formula: HSPA_dl_codes_load = 1 .yellow2GreenHSPAPwrDlLoadThreshold .red2BlackHSPAPwrDlLoadThreshold .yellow2RedHSPACodesDlLoadThreshold .18.2. HSUPA load is not evaluated in current release.TotalHsdpaUsedSF16) / 16 SizeBiggestSf16Pool: Variable introduced by UA06 feature 33694: The number of free codes in the largest SF16 code block.UMTS Radio Mobility failure then the call is redirected to a twin cell if redirection is enabled (parameter rrcRedirectionType has a value unequal to "none" and twin cells are available).red2YellowHSPACodesDlLoadThreshold .1.yellow2GreenHSPACodesDlLoadThreshold . 4.green2YellowHSPACodesDlLoadThreshold . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.red2BlackHSPACodesDlLoadThreshold .HSPA_dl_codes_share HSPA_dl_codes_share = dl code resource share available for next HSPA without GBR service = dl_load_codes_avail_HSPA_wo_GBR_MinBR[ratio] div (nb_current_HSDPA_I_B_services + 1) With: • • • Dl_load_codes_avail_HSPA_wo_GBR_MinBR[ratio] = (SizeBiggestSf16Pool .

UMTS Radio Mobility 4. Note: Power is increased if the load in the target is higher than in the originating cell. 4.06/EN Approved_Standard 17/Sep/2010 Page 99/244 .18. The RNC assumes that all R5 mobiles are HSDPA capable – see table below. Power is not reduced if the load in the target is lower than in the originating cell. the load in the target cell is higher then the usage of more power may be useful to ensure successful call establishment.1.2. If a R99/R4 mobile sends its connection request in the HSDPA layer. using parameter rrcRedirectionType: • UE capability only • UE capability and establishment cause • Preferred FA • CAC • None The selected FA information will be sent to UE through the RRC connection Setup message.1. For R5 mobiles the RRC Connection Request does not clearly identify if the mobile is HSDPA capable or not. knowing that R99/R4 mobiles do not support HSDPA.1 REDIRECTION TYPE = UE CAPABILITY ONLY It is based on the Access Stratum Release Indicator IE present in RRC Connection Request. source and target cell for a redirection are co-located and about the same transmission power is needed in both cells for successful communication between NodeB and UE. UE Release UE capability indication HSPA UE capability (potential or real) Selected Target FA R99/R4 >= R6 R5 >= R6 >= R6 n/a absent n/a HS-DSCH HS-DSCH + E-DCH DCH Preferred target FA is DCH cell HSDPA Preferred target FA is HSDPA cell HSUPA Preferred target FA is HSUPA cell Table 3: UE Capabilities If no twin cell of the selected target FA is available the RNC selects another target FA as per the fallback mechanism defined in Table 4: Passing on or copying of this document. Since UA07.5 INITIAL POWER ON REDIRECTION Typcially.2 the RNC can calculate the expected power needed in the target cell based on the comparision of source and target cell load if isPinitRrcRedirectionAllowed is set to TRUE.1.1. 4.18. it is redirected to the non-HSPDA layer in the RRC Connection Setup message.3 ALGORITHM The operator has the choice between five algorithms for target carrier FA (= Frequency Allocation) selection. however. If a R5 (or later release) mobile sends its connection request in the non-HSDPA layer. it is redirected to the HSDPA layer. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.3.18. If.

If the originating cell color is equal or worse then go to next step. The Call Capability is the same as the UE Capability for this option. 3. Table 4: Target FA Fallback Different iMCRA behaviour applies dependent on whether HSPA load criterion is used or not. 2 nor 3 available Table 5: Applicable Cells Select 4 Select 5 if neither 2 nor 4 available Passing on or copying of this document. from the remaining cells of the twinCellList the target cell is selected with round robin mechanism. or o DL HSPA load > twinCellTargetHspaCellLoadThreshold • A “pure” HSPA cell is loaded if o DL HSPA load > twinCellTargetHspaCellLoadThreshold Note: The uplink load is ignored. If there is neither HSUPA nor HSDPA cell then select DCH cell. 4 nor 5 available Select 1. If there is neither HSDPA nor HSUPA cell then select DCH cell. Search all cells in the twinCellList and originating cell. Select cells which have compatible cell capability with UE capability or the fallback cells if no compatible cell found. If there is no HSUPA cell then select HSDPA cell. 4. 3. If more than one cell is selected then select the cells with lowest cell color (Green < Yellow < Red). Else. Cell Capability DCH Unloaded “R99 preferred” Loaded “R99 preferred” Unloaded “pure” HSPA Loaded “pure” HSPA DCH HSPA (HSDPA or HSUPA) Select 1 if neither 2. 4 nor 5 available Select 2 if 4 not available Select 3 if neither 2. Call Capability # 1 2 3 4 5 With • An “R99 preferred” cell is loaded if o DCH load > twinCellTargetCellColourThreshold. If originating cell is included in the set of selected cells and the originating cell color is better than rrcRedirectOrigCellColourThreshold then the call is established in the originating cell. 2 and 3 Select 4 and 5 if neither 1. 2. If more than one cell is selected: If the originating cell is one of the target cells then the UE should remain in originating cell. RNC selects the target Cell with following procedure if isHspaCellLoadAllowedForImcra = TRUE: 1. RNC selects the target Cell with following procedure if isHspaCellLoadAllowedForImcra = FALSE: 1.06/EN Approved_Standard 17/Sep/2010 Page 100/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Select the applicable cells for redirection from the originating cell and its twin cells as per Table 5.UMTS Radio Mobility Selected Target FA DCH HSDPA HSUPA Fallback if selected target FA is not available If there is no DCH cell then continue with originating and all twin cells (which will select least loaded cell in 2nd and following steps below) If there is no HSDPA cell then select HSUPA cell.

Target Load Criterion for Establishment on Originating Cell Capability DCH DCH load < rrcRedirectOrigCellColourThreshold or streaming call HSPDA DL HSPA load < rrcRedirectOrigHspaCellLoadThreshold and UL DCH load < rrcRedirectOrigCellColourThreshold HSUPA Table 8: Load Criterion for Establishment on Originating Cell 4. If more than one cell is selected then select the cells with lowest cell color as per Table 9. Call Capability HSDPA 1st Choice HSDPA 2nd Choice HSUPA HSUPA HSUPA HSDPA Table 6: Best fit Capability Table 7 defines the target capability dependent on Call and cell capability: Call Capability DCH <any> HSDPA HSDPA HSUPA HSUPA Cell Capability <any> DCH HSDPA HSUPA HSDPA HSUPA HSUPA Table 7: Target Capability HSDPA Target Capability DCH 3. For streaming calls the DCH load criterion and for other calls the load criterion as per Target Capability is applied.06/EN Approved_Standard 17/Sep/2010 Page 101/244 .UMTS Radio Mobility 2. For streaming calls (RRC establishment cause is ‘Originating Streaming Call’ or ‘Terminating Streaming Call’) the DCH load criterion is applied independent of Target Capability. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. If the originating cell is included in the set of selected cells and the originating cell color is better than the originating threshold then the call is established in the originating cell – see Table 8. If the originating cell color is equal or worse then go to next step. If for a HSPA call more than one cell with HSPA capability is selected then select the cells that fit best to the Call capability as per Table 6. The “R99 preferred” configuration is ignored because it was taken into account by step 1 already. Target Capability DCH or streaming call HSPDA HSUPA Load Comparison Select cells with lowest combined UL and DL DCH load 1st step: Select cells with lowest DL HSPA load 2nd step: Select cells with lowest UL DCH load Table 9: Load Comparison Passing on or copying of this document. The originating threshold is dependent on the target capability (note: “R99 preferred” configuration is ignored here).

Background and Streaming traffic classes are mapped on HSDPA. knowing that only Interactive. If more than one cell is selected: If the originating cell is one of the target cells then the UE should remain in originating cell. Passing on or copying of this document. This criterion is optional because this traffic class is not necessarily representative of the services that will be actually used during the life of the RRC connection (a user may start with a service and then establish other services). the preferred FA is chosen using both criteria: HSPA UE capability (potential or real) Call Type by Establishment Cause Call Capability DCH Conversational Data Other Conversational DCH cell Originating cell DCH cell HSDPA cell Originating cell DCH cell HSUPA cell Originating cell HSDPA Data Other Conversational HSUPA Data Other Table 11: UE Capabilities and Establishment Cause If no twin cell of the selected target FA is available the RNC selects another target FA as per the fallback mechanism defined in Table 4.06/EN Approved_Standard 17/Sep/2010 Page 102/244 . Following table gives the call type according to the establishment cause: Call Type Conversational Data RRC Establishment Cause Originating Conversational Call Terminating Conversational Call Originating Interactive Call Originating Background Call Originating Streaming Call Terminating Interactive Call Terminating Background Call Terminating Streaming Call Originating High Priority Signaling Registration Originating Subscribed Traffic Call Other causes Table 10: RRC Establishment Causes Other Then. REDIRECTION TYPE = UE CAPABILITY AND ESTABLISHMENT CAUSE 4.1.as a second criterion for filtering. so Conversational traffic class is redirected to the non-HSDPA layer.18. RNC selects the target Cell with following procedure: 1. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2 It is possible to use the traffic class –derived from the Establishment Cause IE. If the Call Capability has been determined to “Originating Cell” as per Table 11 then the call is established on the originating cell. from the remaining cells of the twinCellList the target cell is selected with round robin mechanism.UMTS Radio Mobility 5. Else.3.

06/EN Approved_Standard 17/Sep/2010 Page 103/244 . 5. The UE capabilities are not taken into account. If more than one cell is selected then select the cells with lowest cell color (Green < Yellow < Red). Call Type Conversational Preferred FA Select FAs with faType set to 'conversational'. If neither 'data' nor 'other' is available select 'conversational' Select every FA given in the referenced RrcRedirectionConfClass Table 12: Preferred FA Data Other If a single FA is selected then the RNC establishes the call in the twin cell of this FA. If no 'conversational' FA is available then select FAs of type 'other'. If more than one FA is selected then select the FAs for which the related twin cell from the twinCellList or the originating cell have lowest cell color (Green < Yellow < Red). Otherwise… 1. Select cells which have compatible cell capability with UE capability and RRC establishment cause or the fallback cells if no compatible cell found.18. If the originating cell color is equal or worse then go to next step. 3. If no 'data' FA is available then select FAs of type 'other'. If the originating cell color is equal or worse then go to next step. 2. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 4. If more than one cell is selected: If the originating cell is one of the target cells then the UE should remain in originating cell. 4. from the remaining cells of the twinCellList the target cell is selected with round robin mechanism. Otherwise… 2.3 REDIRECTION TYPE = PREFERRED FA In case of option "Preferred FA" the RNC selects the target FA based on the Call Type determined from the RRC establishment cause as per Table 10. If neither 'conversational' nor 'other' is available select 'data' Select FAs with faType set to 'data'. The RNC determines the preferred FAs from the assigned RrcRedirectionConfClass and its contained list of FrequencyAllocation's as per Table 12. Otherwise … If isHspaCellLoadAllowedForImcra = TRUE then the RNC follows the procedure for option “UE Capability Only“ from step 3 onwards. Search all cells in the twinCellList and originating cell. Passing on or copying of this document.1.UMTS Radio Mobility Otherwise: If isHspaCellLoadAllowedForImcra = TRUE then the RNC follows the procedure for option “UE Capability Only“ where the Call Capability is determined from Table 11 instead of Table 3. Else.3. If originating cell is included in the set of selected cells and the originating cell color is better than rrcRedirectOrigCellColourThreshold then the call is established in the originating cell. Target FAs for that no cell is defined in the twinCellList are ignored. If the FA of the originating cell is included in the set of selected FAs and the originating cell color is better than rrcRedirectOrigCellColourThreshold then the call is established in the originating cell.

06/EN Approved_Standard 17/Sep/2010 Page 104/244 .UMTS Radio Mobility 3. The call is established on the originating cell if possible. The redirection algorithm is configured on cell basis by parameter rrcRedirectionType rrcRedirectionType InterFreqHhoFddCell Passing on or copying of this document. The UE is redirected to the other layer The UE fails to synchronise on the target layer. This use case is also applicable to mobiles that do not support RRC redirection. from the remaining cells of the twinCellList the target cell is selected with round robin mechanism.1. When receiving this second RRC connection request with the same cause within time T300*N300.1. If more than one cell has lowest cell color: The RNC selects from the remaining cells of the twinCellList the target cell with round robin mechanism.18. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.18. U-RNTI.4 REDIRECTION TYPE = CAC If CAC failure occurred during SRB establishment on the originating cell then the RNC considers redirection to another cell. it will resend an RRC connection request in the same cell (except if it had to perform a cell reselection meanwhile).. For the load comparision the RNC either uses the DCH load if isHspaCellLoadAllowedForImcra = FALSE or otherwise the load criterion as detailed in Table 9. The RNC selects the cells with lowest cell color from the twinCellList. 4.18.18.1. UE Node B RRC/ RACH / RRC connection Request (cause) RRC/ FACH / RRC Connection Setup (DCCH.) RRC/ RACH / RRC connection Request (cause) RRC/ FACH / RRC Connection Setup (DCCH. then the RNC attempts call establishment in the originating cell. The RRC connection request is sent again in the originating cell The RNC does not try to redirect again and proceeds on this cell RRC/ RACH / RRC Connection Setup Complete Figure 58: redirection failure 4. U-RNTI.5 PARAMETERS Redirection during RRC connection setup parameters: Name isRrcRedirectionInterFreq Object/Class RadioAccessService Definition Feature activation flag for interfrequency redirection on RRC connection setup. 4.1. 4.5 REDIRECTION TYPE = NONE No traffic segmentation is performed. Else. If more than one cell/FA has lowest cell color: If the originating cell is one of the target cells then the UE should remain in originating cell.3.4 FAILURE CASES: It may happen that the UE can not synchronise on the new frequency. . ) RNC SGSN The RRC Connection Request message initiated by the UE contains the establishment cause.3.

data. HSPA cell load indicator calculation and broadcasting. It applies during RRC redirection procedure. Especially. When allowed there is a dependency with several sub functions activations: NBAP measurements configuration. Activation/deactivation of the use of the Pinit based on the ratio between Total Transmitted power used on originating cell and target cells.2: RadioAccessService.1. isHspaCellLoadAllowedForImcra UA07. other) Traffic segmentation on RRC establishment can be used to separate R99 and HSPA traffic onto different layers (parameter rrcRedirectionType).06/EN Approved_Standard 17/Sep/2010 Page 105/244 .byte1.3 InterFreqHhoFddCell dlFrequencyNumber ulFrequencyNumber faType layerPreferredForR99 FrequencyAllocation (in RrcRedirectionConfClass MO) FrequencyAllocation (in RrcRedirectionConfClass MO) FrequencyAllocation (in RrcRedirectionConfClass MO) FDDCell Uplink UARFCN FA type (conversational.g.reserved1 (byte2) bit 0 RadioAccessService Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. HSPA services number calculation.reserved5 (byte0. This threshold applies to originating HSPA cell and used by iMCRA as a condition to trigger HSPA cell load balancing: The HSPA cell load has to be higher or equal than this threshold Downlink UARFCN rrcRedirectOrigCellColourThreshold InterFreqHhoFddCell rrcRedirectOrigHspaCellLoadThreshold UA07.UMTS Radio Mobility twinCellList InterFreqHhoFddCell List of up to 5 inter-frequency twin cells (co-located cells referenced by Cell Id) to which interfrequency RRC redirection is considered. this is useful if R99 carriers get unavailable e.1. If the cell color is equal to or above the threshold then RRC redirection to a twin cell is considered. due to automatic carrier switch-off.reserved0 (byte1) bit 2. If the originating cell and one or more twin cells belong to the FA type for RRC redirection as determined by parameter rrcRedirectionType then the call is kept on the originating cell if its cell colour is below the configured rrcRedirectOrigCellColourThreshol d.2: FDDCell. HSPA cell load criteria allowed or not in iMCRA.byte3) RadioAccessService isPinitRrcRedirectionAllowed UA07.1. For specific network configurations it can be useful to allow several layers to carry HSPA traffic but still to prefer some of the HSPA capable layers for R99 traffic.2: RadioAccessService.byte2.

the more capacity is available. This parameter defines the threshold on HSPA Downlink power cell load to transition from green to yellow. The lower the value. This parameter defines the threshold on HSPA Downlink power cell load to transition from red to yellow. the more capacity is available. This parameter defines the threshold on HSPA Downlink power cell load to transition from yellow to green.1. The lower the value.1.6 HspaCellLoadParameters red2YellowHspaPwrDlLoadThreshold UA07. the more capacity is available.e. This parameter defines the threshold on HSPA Downlink power cell load to transition from red to black.6 HspaCellLoadParameters red2BlackHspaPwrDlLoadThreshold UA07.2: FDDCell.. The value indicates the percentage of the cell capacity being occupied. If all HSPA cells are overloaded then R99 preferred cells are considered for HSPA calls. the more capacity is available. The value indicates the percentage of the cell capacity being occupied. not available to a new user. not available to a new user.2: FDDCell.reserved1 (byte2) bit 0. i.06/EN Approved_Standard 17/Sep/2010 Page 106/244 . i. The value indicates the percentage of the cell capacity being occupied.e.e. The lower the value. not available to a new user. This parameter defines the threshold on HSPA Downlink power cell load to transition from yellow to red. The value indicates the percentage of the cell capacity being occupied.e. The lower the value.1.UMTS Radio Mobility twinCellTargetHspaCellLoadthreshold UA07. twinCellTargetCellColourThreshold UA07...e. the more capacity is available.2: FDDCell.6 FDDCell HspaCellLoadParameters yellow2GreenHspaPwrDlLoadThreshold UA07.reserved2 (byte2) bit 0.reserved2 (byte1) bit 0.5 green2YellowHspaPwrDlLoadThreshold UA07.. See also parameter layerPreferredForR99. i.reserved1 (byte3) bit 0.6 HspaCellLoadParameters yellow2RedHspaPwrDlLoadThreshold UA07. not available to a new user. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. i. The value indicates the percentage of the cell capacity being occupied. not available to a new user.2: FDDCell.1.2: FDDCell.1.1. iMCRA considers an R99 preferred FDD twin cell as overloaded if the R99 load is greater than this threshold. The lower the value.reserved1 (byte1) bit 2.2: FDDCell.6 HspaCellLoadParameters Passing on or copying of this document. i.reserved2 (byte0) bit 0..1.reserved1 (byte1) bit 4.2: FDDCell.3 FDDCell iMCRA considers an HSPA cell as overloaded if the HSPA load is greater than this threshold.

The lower the value.reserved3 (byte1) bit 0.. i.6 HspaCellLoadParameters red2YellowHspaCodesDlLoadThreshold UA07.6 HspaCellLoadParameters red2BlackHspaCodesDlLoadThreshold UA07.06/EN Approved_Standard 17/Sep/2010 Page 107/244 .6 HspaCellLoadParameters black2RedHspaCodesDlLoadThreshold UA07. The lower the value. This parameter defines the threshold on HSPA Downlink codes cell load to transition from red to yellow. The lower the value.reserved0 (byte2) bit 0. i. not available to a new user. The lower the value.2: FDDCell. the more capacity is available.1. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. i. The value indicates the percentage of the cell capacity being occupied.reserved3 (byte0) bit 0. the more capacity is available.. not available to a new user. The lower the value..e.1. i. not available to a new user. green2YellowHspaCodesDlLoadThresho ld UA07..2: FDDCell.6 HspaCellLoadParameters yellow2RedHspaCodesDlLoadThreshold UA07.2: FDDCell. not available to a new user.e. The lower the value.6 HspaCellLoadParameters yellow2GreenHspaCodesDlLoadThresho ld UA07.2: FDDCell.1.2: FDDCell. This parameter defines the threshold on HSPA Downlink codes cell load to transition from yellow to green.UMTS Radio Mobility black2RedHspaPwrDlLoadThreshold UA07.1.e. The lower the value.. The value indicates the percentage of the cell capacity being occupied..reserved0 (byte3) bit 0.e. not available to a new user.e. This parameter defines the threshold on HSPA Downlink codes cell load to transition from green to yellow. the more capacity is available. i. This parameter defines the threshold on HSPA Downlink codes cell load to transition from red to black. i. not available to a new user. The value indicates the percentage of the cell capacity being occupied.1. i. This parameter defines the threshold on HSPA Downlink codes cell load to transition from yellow to red. The value indicates the percentage of the cell capacity being occupied. the more capacity is available.2: FDDCell.e. The value indicates the percentage of the cell capacity being occupied. the more capacity is available.1.reserved3 (byte2) bit 0.reserved3 (byte3) bit 0. not available to a new user. This parameter defines the threshold on HSPA Downlink codes cell load to transition from black to red..6 HspaCellLoadParameters Passing on or copying of this document.reserved2 (byte3) bit 0. the more capacity is available.1. The value indicates the percentage of the cell capacity being occupied.6 HspaCellLoadParameters This parameter defines the threshold on HSPA Downlink power cell load to transition from black to red. the more capacity is available.2: FDDCell.e. The value indicates the percentage of the cell capacity being occupied.

06/EN Approved_Standard 17/Sep/2010 Page 108/244 . RRC Redirection will not be triggered in the RNC. or whether the UE supports GSM. o RRC Redirection will not be triggered by the RNC if the UE already has an established RRC connection. 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. If the neighbouring 2G cells (measurement based or blind) are not provisioned at the OMC-R. and is not able to be modified. these calls have already failed to establish on the 3G network. on the 2G network. GSM may either simply fail the call or attempt to redirect the Video telephony back to 3G. The call would fail at the CN if a RRC Redirection is attempted. however. the end result is that the ability to redirect the call to 2G may not function in these cases. the RNC will attempt an RRC Redirection irrespective of whether the UE supports the Redirection IE in the RRC reject message. which will arrive. The UE will re-attempt the call setup (multiple times with increasing power each time). o Conversational calls on the PS domain. 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. Call failures associated with RACH access are outside of the scope of this feature capability. the call will fail. However. even if RRC Redirection is enabled for that cell. and contention will occur if the number of UEs attempting to access the 3G network exceeds a given threshold.19). if it has a subsequent request pending. and is used to allow the UE and CN to exchange subsequent Non Access Stratum (NAS) messages to allow the call to progress.18.18. This includes: o Non-speech calls such as Video telephony. RRC Redirection is triggered by failures at this point in the call progression.2.UMTS Radio Mobility 4. Therefore. o RRC Redirection does not apply to any mobile terminated call scenario. The UE may choose to set the “follow-on request” indicator during the Location Update Request.1 The Redirection during the Rab Assignment processing is covered by the iMCTA function (refer also to § 4. and fail.2 o o APPLICABILITY The redirection applies to calls with RRC Establishment cause equal to MO Conversational or Emergency. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. However. This is due to the fact that the anchor 3G-MSC has already been established prior to the RRC Connection Request. having RRC Redirection enabled for a cell which has no 2G neighbouring cells provisioned is considered a configuration error. This could possibly be the case where the call is invoked very early after the UE is powered up. Therefore. o SRB Assignment: The SRB is established as a result of the first Access Stratum (AS) message being received by the RNC. but if the RACH access failure persists. This could be the case in the following scenarios: o A PS call is established prior to invocation of the speech call attempt. The RNC is unaware of the UE capabilities at RRC Connection Request time. but they may be present in the future. This is not currently the case. o The UE did not release the RRC connection after the initial Location Update. The resultant behaviour is not defined in the standards. and is in either the active state or AO Step 1 state. Users may experience delays in accessing the network due to collisions on the RACH channel.18. RRC Redirection is not triggered for this scenario. 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.2 3G2G REDIRECTION AT RRC ESTABLISHMENT FOR SPEECH CALLS DESCRIPTION 4.2. Passing on or copying of this document. o RRC will redirect all MO Conversational calls to 2G upon admission failure (irrespective of service type and domain). There may be other cases where the UE will request the network to keep the RRC Connection established. 4.

and the UTRAN is enabled to redirect speech calls to 2G.e. RRC/ FACH (RRC Connection Reject (Wait Time.g. Step 2: The RNC will execute normal (i. Maximum UE Contexts: The RNC checks that the maximum number of concurrent UE contexts will not be exceeded. CID exhaust. 1 2 If admission fails. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. This is a calculated capacity. RNC Overload: The RRC connection request may be denied based on the current RNC Overload level CAC. Redirection info: GSM)) Figure 59: RRC Speech Redirection The key steps are as follows: o Step 1: The UE requests the initial signalling as a normal conversational call setup request. DL Power) NodeB CEM AAL2 CAC: In this case there are several existing possible exhaust scenarios. PSFP) If failure occurs on any one of the above RRC admission controls. the IE “GSM target cell info list” may be set for Rel6 UE if allowed (OAM parameter isGsmTargetInfoListAllowed).g.06/EN Approved_Standard 17/Sep/2010 Page 109/244 . 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. The required resources are dependant on whether the setup is via Cell_FACH or Cell_DCH. 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. a RRC Connection Reject is sent to the UE with redirection info included. which could also trigger RRC Redirection. the most likely failure scenario is Iub bandwidth exhaust. and is as follows: o Cell_DCH: Radio Resources (OVSF codes. based on the sum total of all RBs currently assigned to that resource (partitioned into DS and NDS traffic. PID failure. as of UA04.3 ALGORITHM The flow for RRC Redirection is shown in Figure 59: RRC Speech Redirection. o Passing on or copying of this document. The RRC Connection Reject message will contain the Redirection info IE with Inter-RAT info set to “GSM”.UMTS Radio Mobility 4. While in this example the setup relates to a speech call setup. PSFP) o Cell_FACH: Number of contexts on the FACH channel Internal RNC U-Plane resources (e. This step is preceded by the location registration (not shown here). existing) RRC Connection Admission mechanism. The mobile station performs inter-system cell reselection and re-originates the speech call on the 2G network. and PathGroup failure. However. the RNC will execute the RRC Redirection Enabling Criteria. such as Iub bandwidth exhaust (or Iur in the case of a DRNC scenario).18. There is also a separate cause value for an emergency call request. SRB CAC: The RNC will check that the resources required to support the SRB are available.1). the same RRC cause value would be used for a Video Telephony call setup request.2. due to the throughput constraint of this physical connection. Internal RNC U-Plane resources (e. In order to improve the 3G-2G HHO duration.

and this up to N300 times. In the case of a “3G-2G Emergency When the re-attempt occurs in the same Fdd cell within a certain period of time (RrcCnxRepeatTime OAM parameter). This parameter allows using the R6 IE GSM Target Info List in the RRC Connection Reject message. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the RNC doesn’t redirect the call to the 2g and attempts to establish the call on the FDD cell thanks to a mechanism at cell level which registers the UE identity before launching the 3G2G redirection. since the UE performs target GSM cell selection.06/EN Approved_Standard 17/Sep/2010 Page 110/244 .2. If the admission failure which causes the redirection is “RNC overload”. Two values: TRUE/FALSE TRUE: the IE may be used WaitTime3GTo2GRedirectFailure emergencyCallRepeatTime renamed rrcCnxRepeatTime RNC RadioAccessService ServiceInit isGsmTargetInfoListIeAllowed RNC RadioAccessService ServiceInit Passing on or copying of this document. In the case where the 2G cell selection fails. the Rach is managed as a first RRC establishment request. o a static RNC value if the admission failure which causes the redirection is not ” overload”. the UE is required to wait (at least) a predetermined time before the subsequent attempt on the 3G network. o waitTime3Gto2GRedirectFailure.4 PARAMETERS Object/Class RadioAccessService Class3 FDDCell Class3 RadioAccessService Class3 FDDCell Class 3 Name is3Gto2gConversationalCallRedirectOnRrcEs tabFailAllowed blindHoGsmNeighbourTargetCgi timeReject 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 This parameter clarifies the wait Time to provide to the UE in case of failed redirection triggered by the features CS speech call redirection to 2G . the UE will re-attempt a call in 3G. 4. 3G2G redirection for emergency call or 3G2G redirection based on cell load. If the reattempt occurs after the timer elapses or in a different Fdd cell. Definition is updated: This is the maximum time between two Emergency call or CS speech call attempts from the same UE (where the first attempt was already rejected with 2G redirection information present) that can lead to a non redirection to the 2G network (even if the 3G to 2G redirection for emergency calls is allowed). However. The Wait Time parameter will be set to the value associated with one of the following parameters: o timeReject.UMTS Radio Mobility The UE cell selection is not a blind HO.18. This wait time is sent by the RNC to the UE in the Wait Time IE in the RRC Connection Reject message.

• 3G-2G Emergency Redirection For specific needs related to UE positioning.3.and from the RANAP RAB Assignment Request when the IE 'Priority Level' in 'RAB Parameters' – 'Allocation/Retention priority' has the value as configured by parameter RadioAccessService.3 ALGORITHM • Normal Case Under Normal (i.In case the UE has an on-going PS call at the time the emergency call is attempted.] The flow for RRC Redirection is shown in following figure: Passing on or copying of this document.1 EMERGENCY AND PRIORITY CALLS DESCRIPTION For emergency calls in some countries it is required to determine the location of the UE at call establishment. Current UMTS networks and/or UEs may not allow for a determination of the UE location with sufficient accuracy. non-overload) conditions and if no re-direction to GSM is required (see section "3G-2G Emergency Redirection" below).UMTS Radio Mobility when a redirection towards GSM has to be processed.18. In order to take advantage of existing GSM location position solution that satisfies the FCC E911 Phase II requirements.18. emergency calls can be redirected on initial 3G call set-up [USA Market . The redirection is made upon reception of the RRC Connection Request message by the RNC (from the UE). if each of the following conditions is true: • RRC Establishment Cause is Emergency Call • The RRC Redirection feature is enabled on the RNC (on a per-cell basis) • If the mobile current cell has provisioned a 2G neighbouring cell. it may be required by the operator to re-direct the UE initiating an emergency call to the 2G network.18. The call is handled as specified in the "MO call setup" section. UTRAN is aware that the call initiated by the mobile is an emergency call from the RRC establishment cause set to "Emergency call".2 APLLICABILITY Emergency calls are always mobile originated speech calls.emergencyCallPriorityLevel ] 4. 4. in order to utilize a location solution deployed in the operator’s 2G network. 4.3. the percentage of emergency calls processed by the RNC may be reduced.18.e.06/EN Approved_Standard 17/Sep/2010 Page 111/244 . [USA Market . With "Immediate Handover of Emergency Calls" (see [R2] for details) this problem can be avoided by initiating handover to 2G after call establishment. FALSE: the IE shall not be used when a redirection towards GSM has to be processed.3 4.or handed over after 3G call set-up] to the 2G GSM network. no specific treatment is applied by the RNC during call establishment. then the emergency call establishment is not initiated with RRC Connection Request. The effect of overload on emergency calls is provided in [R1]. [USA Market . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.3. When the RNC is in an overload condition. Therefore no RRC Redirection is possible.

there is no possibility to re-direct the call to GSM. an enhancement allows the RNC to accept a repeated RRC Connection Setup for an Emergency call coming from the same mobile within a certain period of time (RrcCnxRepeatTime OAM parameter). A filtering mechanism is also implemented in the RNC to discard Rach repetition within a certain period of time (Static parameter: repeatFilteringTime). which defines redirection to the GSM system of WPS calls which originate from a UMTS subscriber. The core network will then repeat the location reporting request to the GSM network. Redirection info: GSM)) Figure 60: 3G-2G Emergency Redirection The RRC Connection Reject message will contain the Redirection info IE with Inter-RAT info set to “GSM”. Likely the redirection will fail again.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. If the UTRAN is setup to re-direct emergency calls to 2G and if 2G neighbouring cells are available. Refer to [R13] for more details on specific emergency redirection. • [USA Market . RRC/ FACH (RRC Connection Reject ( Wait Time. Location reporting requests from the MSC are queued during this time and discarded in case of successful handover. The directed retry for WPS calls can be enabled on RNC basis.UMTS Radio Mobility UE Node B RNC MSC-CS RRC/ RACH (RRC connection Request (cause: Emergency Call)) The RRC Connection Request message initiated by the UE contains the establishment cause.4.19 for a description of the CAC based handover algorithm). the RNC will try to redirect again this call to the 2G network. the IE “GSM target cell info list” may be set for Rel6 UE if allowed (OAM parameter isGsmTargetInfoListAllowed). The UE performs GSM measurements and if a suitable GSM target cell is found within time interSystemHOe911Timer then the handover is initiated.06/EN Approved_Standard 17/Sep/2010 Page 112/244 . To avoid endless loop preventing the E911 call to be setup. the mobile enters Idle Mode. Passing on or copying of this document. the call is processed as in "MO Call Setup".10. The call setup is considered as unsuccessful and there is no further RRC connection attempts tried by the mobile for this call.] Special handling may apply also to priority calls. If the mobile fails the redirection and if the user re-attempts a new E911 call setup. if radio resource congestion occurs on the UTRAN. In order to improve the 3G-2G HHO duration.2 for redirection procedure. a RRC Connection Reject is sent to the mobile. otherwise. Otherwise. Refer to § 4. as the RRC connection has already been established for the PS session. 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. or NS/EP calls which terminate to a UMTS subscriber. On reception of the RRC Connection Reject message. the mobile shall: Perform GSM cell selection immediately In case of GSM selection failure. if WaitTime is different from 0. and the mobile will again enter idle mode. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. In case there is an on-going PS at the time the emergency call is attempted. even if Redirection to 2G is configured for E911 calls. If UTRAN is congested. the UE shall not re-select a UMTS cell until WaitTime has expired. On RAB Assignment the MSC indicates that the call is a priority call. then the UTRAN initiates directed retry to GSM (see section 4.18. An example is the Wireless Priority Service (WPS) in the US. and as specified in [A4] (RRC specification): If WaitTime equals 0. In case of inter-RAT handover attempts for emergency [USA Market] or priority calls the RNC does not retry handover to the next best cell in case of relocation preparation failure – see section 4.

emergencyCallRepeatTime RNC Definition is updated: renamed rrcCnxRepeatTime RadioAccessService This is the maximum time between two ServiceInit Emergency call or CS speech call attempts from the same UE (where the first attempt was already rejected with 2G redirection information present) that can lead to a non redirection to the 2G network (even if the 3G to 2G redirection for emergency calls is allowed). Following options are available: Class 3 . then the RNC tries the handover for [USA Market] Class 3 the time interSystemHOe911Time.e. the call will be kept in UMTS but may be handed over to GSM at a later time e. [USA Market] isWpsDirectedRetry Imcta If enabled Wireless Priority Service (WPS) calls are directed to Allowed Class 3 GSM if the UMTS cell is in congestion. interSystemHOe911 RadioAccess If a call is an emergency call and an immediate handover to Timer Service GSM should be performed. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. On cell basis wed Class 3 further configuration options are available. immediateHOofEm FDDCell / Indicates whether emergency calls should be handed over to ergencyCalls Neighbouring GSM using immediate Inter-System Handover after RAB [USA Market] RNC establishment or kept in UMTS.inter system handover for all emergency calls .disabled . i. due to coverage reasons. FDDCell Passing on or copying of this document. rvice ServiceInit Two values: TRUE/FALSE TRUE: the IE may be used when a redirection towards GSM has to be processed. An ongoing handover attempt is not aborted.UMTS Radio Mobility 4.06/EN Approved_Standard 17/Sep/2010 Page 113/244 .18. isGsmTargetInfoLis RNC This parameter allows using the R6 IE GSM Target Info List in RadioAccessSe tIeAllowed the RRC Connection Reject message. On expiry of this timer the attempt to revert the emergency call to GSM is aborted. The default value is 1 second. emergencyCallPrio RadioAccess The parameter identifies the 'Priority Level' of Emergency Call rityLevel Service bearer and is used to recognise the Emergency Call on receiving Class 3 RANAP Allocation/Retention Priority communicated by CN to RNC over Iu interface.4 PARAMETERS Object/Class FDDCell Definition Activation flag to enable 3G to 2G redirection for emergency calls Name is3Gto2GRedirectF orEmergencyAllow ed WaitTime3Gto2GR edirectFailure Value for WaitTime IE sent to the mobile in case of re-direction to GSM. FALSE: the IE shall not be used when a redirection towards GSM has to be processed. From 0 to 15 seconds. isImmediateHOofE RadioAccess This parameter enables/disables the 'Immediate Handover of mergencyCallsAllo Service Emergency Calls to GSM' on a per RNC basis.inter system handover for emergency calls of non-GPS UEs The RNC level parameter RadioAccessService::isImmediateHOofEmergencyCallsAllowed must be enabled for immediate inter-system handover of emergency calls.g.3. The call will be handled like a normal call.

Only applicable for the context of "Emergency Call Immediate Inter-System Handover".5 • PERFORMANCE MANAGEMENT [USA Market -The following counters are available for "Immediate Handover of Emergency calls": RAB. VS. 4. Only applicable for the context of "Emergency Call Immediate InterSystem Handover". Only applicable for the context of "Emergency Call Immediate Inter-System Handover".IRATHO. VS. VS.AttRelocPrep The number of attempted relocation preparations for Emergency Call Immediate Inter-System Handover (ECIHO).UMTS Radio Mobility wpsTRelocPrep Imcta Class 3 Length of time the source RNC will await a response from the CN after sending a RELOCATION REQUIRED message to the CN.SuccEstabCSV.IRATHO.18.ECIHO.AttEstabCSV.3g2gOutHoFailure Number of failed outgoing CS IRAT Handovers from 3G to 2G VS.IRATHO.CancelHO The number of Emergency calls for that an Immediate Inter-System Handover is cancelled by normal call release after the RAB has been successfully established and before the handover is initiated by a relocation preparation procedure. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.IRATHO. This PM is only applicable for Emergency Calls. Number of • • Passing on or copying of this document.IRATHO. Number of RAB Assignment Requests for Wireless Priority Service (WPS) calls.ECIHO.ECIHO. VS. This PM is only applicable for Emergency Calls.AttEstabCSV. Applicable in the context of WPS calls.] • • • • • • • The following counters are available for "Wireless Priority Service": • RAB.AttRRCHO The number of attempted handovers for Emergency Call Immediate Inter-System Handover (ECIHO). Only applicable for the context of "Emergency Call Immediate Inter-System Handover".IRATHO.IRATHO.AttHO This PM counts the number of Emergency calls for that an Immediate Inter-System Handover is attempted. VS.SuccHO The number of successful Emergency Call Immediate Inter-System Handovers (ECIHO). VS. RAB.3.EC This PM counts the number of Successful RAB Establishments for Emergency Calls. Only applicable for the context of "Emergency Call Immediate InterSystem Handover".EC This PM counts the number of RAB Assignment Requests for Emergency Calls. only. VS.ECIHO. When a directed retry handover of a WPS call is attempted.WPS RAB Assignment Requests for Wireless Priority Service (WPS) calls. If the timer expires the RNC will abort the Relocation Preparation procedure by initiating the Relocation Cancel procedure. Only applicable for the context of "Emergency Call Immediate Inter-System Handover".WPS.ECIHO.AttDirectedRetry Attempted CAC failure initiated Directed Retries of Wireless Priority Service (WPS) calls. This measurement is pegged only if WPS handling is enabled in the RNC. the call may queue for an idle trunk and/or a radio for up to 180 seconds.06/EN Approved_Standard 17/Sep/2010 Page 114/244 .ECIHO. This specific timer for US priority call service Wireless Priority Service (WPS) has higher values than normal to regard for queuing in the target GSM system of the WPS calls.CancelRelocPrep The number of Emergency calls for that an Immediate Inter-System Handover is cancelled by normal call release after the RAB has been successfully established and before the handover is initiated by a relocation preparation procedure.

only. only. only.06/EN Approved_Standard 17/Sep/2010 Page 115/244 . Passing on or copying of this document.4 4.AttRelocPrepOutCS.18.CancelRelocPrep Cancelled WPS CS IRAT Directed Retry Relocation Preparations.2 APPLICABILITY The service eligible to this feature is identified when the RNC receives a RRC establishment request by using the following RRC Information Element: • RRC Establishment cause IE = “Originating Conversational Call” or ” Emergency call”. The worst load color of the different indicators is taken into account and compared with a threshold (redirection3G2GOnCellLoadThreshold parameter) dedicated to this feature.4.WPS.SuccDirectedRetry Successful CAC failure initiated CS IRAT Directed Retries of Wireless Priority Service (WPS) calls.AttHO Attempted CS IRAT handovers of CAC failure initiated Directed Retries of Wireless Priority Service (WPS) calls. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. only.18. VS. VS.IRATHO. Description: Applicable in the context of Directed Retry for WPS calls. • Downlink power load. The following elementary load indicators are read by the feature to take the decision to move call towards the 2G: • CEM ul and CEM dl load.18.UMTS Radio Mobility attempted CAC failure initiated Directed Retries of Wireless Priority Service (WPS) calls. Applicable for the context of WPS call Directed Retry. Definitions of the load indicator are given in [R7]. 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). only. Applicable in the context of Directed Retry for WPS calls.IRATHO.WPS.WPS. 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.IRATHO. • Iub dl load: the max elementary Iub color among the load color conversational. • • • • The counters are of cumulative type. The number of WPS calls for that the Directed Retry is cancelled by normal call release during ongoing relocation preparation procedure.WPS. VS. • Code load. VS.IRATHO. Applicable in the context of Directed Retry for WPS calls. • Call type IE (Rel6)= “CS speech”.CancelHO Cancelled WPS CS IRAT Directed Retry attempts.WPS Attempted CS IRAT relocation preparations of CAC failure initiated Directed Retries of Wireless Priority Service (WPS) calls. • RTWP load of the ul DCH + non scheduled E-DCH. streaming or I/B DCH is taken into account.1 3G2G REDIRECTION BASED ON CELL LOAD DESCRIPTION This feature enables 3G/2G RRC redirection of CS Speech calls when the cell load on the originating UMTS cell reaches a configurable threshold. only. • VS.4. Applicable for the context of WPS call Directed Retry. They are defined as two sets. Applicable in the context of Directed Retry for WPS calls. 4.IRATHO. 4.

call type IE is not present and a CS speech service or a CS video telephony cannot be differentiated. is above or equal to the cell 3G2G redirection load threshold (redirection3G2GOnCellLoadThreshold OAM parameter) ( • OR The UE version is R6 or above and the Domain indicator = “CS domain” and the Call type IE = “CS speech” and the RRC Establishment cause IE = “Originating Conversational Call”. This IE is mandatory present if the IE "Domain indicator" has the value "CS domain" and the IE “Establishment cause” has the value “Originating Conversational Call” or “Emergency Call”. The interaction with other RRC redirection features is given in 4. It allows differentiating a speech call from a video telephony call. The UE version is up to R5 and the RRC Establishment cause IE = “Originating Conversational Call” and the feature is configured to UE with a release up to R5 (is3G2GRedirectOnCellLoadAllowedForR99AndR5 OAM parameter).18. 4.18. The UE version is R6 or above and the Domain indicator = “CS domain” and the Call type IE = “CS speech” and the RRC Establishment cause IE = “emergency call” and the feature is configured to apply to emergency call (is3G2GRedirectOnCellLoadAllowedForEmergency OAM parameter). It may induce the redirection of a video telephony service. Note 3: A load threshold equal to “green” may be used to redirect all candidate RRC connection request towards the 2G. On RRC Connection Setup request message receipt the criterion to a redirect the call towards 2G is: • AND • AND • AND • AND • The feature is activated on this FDD cell (is3G2GRedirectOnCellLoadAllowed OAM parameter) The Rach is not a repeated Rach The current FDD cell has neighboring GSM cells configured (see Note 1) The 3G2G redirection load color of the cell receiving the RACH or of the twin cell if traffic segmentation applies. Otherwise it is not needed. For UE with a release up to R5. Note 2: 2G load is not taken into account to take the decision to trigger the redirection.5.3 ALGORITHM The flow for RRC Redirection is shown in Figure 61: RRC Redirection. • OR • OR • • ) Note 1: The GSM frequency bands supported by the UE are unknown when processing the RRC Connection Request message (only given in the RRC Connection complete message): this capability cannot be checked by the RNC. The UE version up to R5 and the RRC Establishment cause IE = “Emergency call” and the feature is configured to apply to emergency call and the feature is configured to UE with a release up to R5.4. Passing on or copying of this document.06/EN Approved_Standard 17/Sep/2010 Page 116/244 .UMTS Radio Mobility The call type is a R6 IE. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.

[UA06-UA07 difference]:The feature reuses the EmergencyCallRepeatTime parameter created by the feature 3G/2G redirection enhancement for 911 calls and renames it: “RrcCnxRepeatTime”. If no GSM cell fulfills the selection criteria.2 is checked. the RNC doesn’t redirect the call to the 2g and attempts to establish the call on the FDD cell thanks to a mechanism (already used for all features dealing with RRC Redirection) at cell level which registers the UE identity before launching the 3G2G redirection. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. When the re-attempt occurs in the same Fdd cell within a certain period of time (RrcCnxRepeatTime OAM parameter). If the re-attempt occurs after the timer elapses or in a different Fdd cell.UMTS Radio Mobility 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.06/EN Approved_Standard 17/Sep/2010 Page 117/244 . 1 2 If the call is eligible to to the 3G2G redrection criterion a Rrc Connection Reject is sent to the UE with redirection info included which may include the GSM target cell info list IE RRC/ FACH (RRC Connection Reject (Wait Time. Passing on or copying of this document. Redirection info: GSM)) Figure 61: RRC Redirection On receipt of the RRC connection request.18. the redirection criterion described in 4. The UE may camp on the same Fdd cell or another Fdd cell (the cell reselection process may change the Fdd cell . a filtering mechanism is implemented in the RNC to discard Rach repetition within a certain period of time (Static parameter: repeatFilteringTime). the UE will re-attempt a new RACH towards the UTRAN after the “wait time” timer (UE timer) has elapsed.5). The UE has to wait 10 sec (3GPP static value) before starting a new search among all GSM cells. after applying the priority between all RRC redirection features (see 4. the Rach is managed as a first RRC establishment request. The value setting has to take into account the worst scenario: The UE doesn’t find a suitable cell among the GSM cell list given by the RNC.4.18. the UE will process GSM cell selection process using or not the GSM target cell info and will attempt a Rach on 2G if it finds an eligible GSM target cell. A value around 30 sec is recommended. If it is verified the call is redirected towards the 2G using a RRC Connection Reject message with the following setting: • • • • Initial UE identity (Mandatory IE)= <read from RRC connection request msg> Rejection cause (Mandatory IE)= ‘congestion’ Wait time (Mandatory IE)= waitTime3Gto2GRedirectFailure Redirection to GSM information: o CHOICE Redirection info () • Inter-RAT info • Inter-RAT info = “GSM” • GSM target cell Info List (1 to maxGSMTargetCells=32) Rel 6) o BCCH ARFCN o Band Indicator o BSIC (IE Upon receiving this message. As for feature 3G/2G redirection enhancement for 911 calls.

yellow.06/EN Approved_Standard 17/Sep/2010 Page 118/244 .4.4 New parameters: PARAMETERS Parameter is3G2GRedirectOnCellLoadAllowed MO RNC NodeB FDDCell Class 3-A2 is3G2GRedirectOnCellLoadAllowedForEmergency RNC RadioAccessService 3-A2 is3G2GRedirectOnCellLoadAllowedForR99AndR5 RNC NodeB FDDCell 3-A2 Definition Enables the feature when the Rach concerns a normal or emergency CS speech call . Definition is updated: This is the maximum time between two Emergency call or CS speech call attempts from the same UE (where Passing on or copying of this document.18.2. This parameter allows using the R6 IE GSM Target Info List in the RRC Connection Reject message. Enum (green. the 3G2G redirection feature may apply.UMTS Radio Mobility 4. red) When the cell load color is higher or equal to this threshold. redirection3G2GOnCellLoadThreshold RNC NodeB FDDCell 3-A2 isGsmTargetInfoListIeAllowed RNC RadioAccessService ServiceInit 3-A2 [UA06-UA07 difference]:Parameters modified: Parameter waitTime3Gto2GRedirectFailure MO RNC NodeB FDDCell Class 3-A2 emergencyCallRepeatTime renamed rrcCnxRepeatTime RNC RadioAccessService ServiceInit 3-B Definition Already used by feature 3G/2G redirection for emergency calls. Enables the feature when the Rach conerns a UE with a release strictly below R6. Already used by feature 3G/2G redirection enhancement for 911 calls. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.18. Enables the feature when the Rach concerns an emergency CS speech call. FALSE: the IE shall not be used when a redirection towards GSM has to be processed. Two values: TRUE/FALSE TRUE: the IE may be used when a redirection towards GSM has to be processed.4. The Definition is updated: see 4.

2 ALGORITHM Following table gives the interworking between all the above features: Passing on or copying of this document.5. 4.5.18.FailConnEstab. 4.RRC_ConnectionReAttempt.1 PRIORITY BETWEEN RRC REDIRECTION FEATURES DESCRIPTION The interaction between the different redirection features are described in the following section 4.UMTS Radio Mobility the first attempt was already rejected with 2G redirection information present) that can lead to a non redirection to the 2G network (even if the 3G to 2G redirection for emergency calls is allowed). Counter added: VS. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. See [A14] for more details.4.18.5 PERFORMANCE MANAGEMENT [UA06-UA07 difference]:Counters modified: RRC.18.5 4.06/EN Approved_Standard 17/Sep/2010 Page 119/244 .18.

For consistency.2G neighbours configured 4. From release UA07.25145 is enabled in originating cell. Reference cell for load check including related OA&M parameters and for call establishment 5. RRC attempt after callp filtering mechanism 3.1.UMTS Radio Mobility # RRC attempt emergency first <any> repeated <any> repeated Call Type 1 2 13451 25145 (emergency) (CAC) active <any> <any> <any> <any> <any> <any> <any> <any> <any> inactive inactive inactive inactive inactive inactive inactive inactive inactive inactive <any> <any> <any> <any> <any> <any> <any> <any> <any> <any> enabled enabled 3 34480 (load) <any> <any> <any> <any> <any> <any> <any> <any> <any> 75069 / Reference 81213 Cell <any> originating <any> originating <any> originating disabled originating enabled selected by 75069 disabled originating enabled selected by 75069 disabled originating enabled 4 Cell Load of reference cell <any> below CAC CAC failure below CAC below CAC CAC failure CAC failure below 34480 load CAC ok below 34480 load CAC ok above 34480 load CAC ok above 34480 load CAC ok above 34480 load above 34480 load below 34480 load CAC failure below 34480 load CAC failure CAC failure CAC failure Result Redirect to 2G triggered by 25145 RRC establishment in reference cell Reject RRC establishment or 33322 to trigger pre-emption in reference cell RRC establishment in reference cell RRC establishment in reference cell Reject RRC establishment or 33322 to trigger pre-emption in reference cell Reject RRC establishment RRC establishment in reference cell RRC establishment in reference cell RRC establishment in reference cell RRC establishment in reference cell Redirect to 2G triggered by 34480 Redirect to 2G triggered by 34480 Redirect to 2G triggered by 13451 Redirect to 2G triggered by 13451 Reject RRC establishment or 33322 to trigger pre-emption in reference cell Reject RRC establishment non-CSV non-CSV non-CSV non-CSV CSV CSV CSV CSV CSV CSV CSV CSV CSV CSV first first first first first first first first first first first first first first selected by 75069 disabled disabled originating disabled enabled enabled enabled <any> <any> selected by 75069 disabled originating enabled selected by 75069 disabled originating enabled selected by 75069 disabled disabled disabled originating disabled disabled enabled selected by 75069 Table 13: Feature Interactions Notes: 1. CSV is normal speech or emergency call 2. 4. Feature 25145 is active if .06/EN Approved_Standard 17/Sep/2010 Page 120/244 .2 feature 75069 is enhanced by feature 81213. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. and .7 None.the call attempt is for an emergency call.18. a “red” default color is used for this cell in order to disfavor it: a 3G2G redirection will be launched. and . 4. the feature has to be activated in all Fdd cells of the RNC. CORE NETWORK IMPACTS Passing on or copying of this document.18. Note: If the load of the selected twin cell is not available.6 ACCESS NETWORK IMPACTS Support of admission control and RRC Redirection procedures.

1.19.2 (PLM decision) For Soft Handover / Primary Link Change: please see section 4.06/EN Approved_Standard 17/Sep/2010 Page 121/244 .3. no related functionality available in UA7.PS I/B a 5 1 f + 2 PS I/B + PS I/B + PS I/B 3 .PS I/B + 2 PS I/B SRB + PS I/B b SRB + PS I/B + PS I/B + PS I/B d e h + PS I/B 4 2 . the Dual cell Hsdpa operation shall satisfy the following requirement: DC HSDPA is applicable only to Cell DCH state.3.1.2.1 For Hard Handover: please see section 4.1 DESCRIPTION From mobility perspective.PS I/B g .19.19. DL/UL DCH signalling traffic will be transmitted via anchor carrier. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2 • • • • APLICABILITY In the release UA07.2 PS I/B 6 c .PS I/B SRB + PS I /B + PS I/B Dual Cell Conditions fulfilled Dual Cell Conditions not fulfilled Only dotted arrows are applicable to Trial Sc ope Call is On Single Carrier Call is On Dual Carrier Example of transitions for Dual Cell Hsdpa Operation Passing on or copying of this document.2 SRNS Relocation: please refer to section 4.19.19. the table below summarizes the possible transitions that can be performed. SRB .UMTS Radio Mobility 4. the Dual cell Hsdpa operation has interacted with different procedures as described below: • • • • • For Cell Selection procedure: no impact For Redirection during RRC Establishment: Covered by UA08 feature 89857.3 The interactions inducing some changes on the procedure described above are highlighted in the sub-section: 4.3.19.PS I/B SRB + PS I/B + PS I/B . DC mobility is based on legacy mobility procedures based on the anchor carrier Only PS I/B mapped on EDCH/HSDPA call can be setup on dual cell. DUAL CELL HSDPA OPERATION 4.

06/EN Approved_Standard 17/Sep/2010 Page 122/244 . The RNC includes one instance of the IE "Additional HS Cell Information RL Reconf Prep" in the NBAP message RADIO LINK RECONFIGURATION PREPARE to the new serving NodeB with following sub-IEs: • • • HS-PDSCH RL ID C-ID HS-DSCH FDD Secondary Serving Information The NodeB shall include the IE "Additional HS Cell Information Response" in the NBAP message RADIO LINK RECONFIGURATION READY. Normal HSPA behaviour applies. Note: If non-serving NodeBs are part of the active set then these are already configured at this time.this is existing functionality. are kept without modification.1. Unsuccessful Operation If due to any reason the new serving NodeB is not able to establish the secondary cell requested by the RNC in the RADIO LINK RECONFIGURATION PREPARE message then the NodeB shall completely fail the radio link reconfiguration. Therefore active set updates do not change the DC configuration.1 ALGORITHM SOFT HANDOVER ACTIVE SET UPDATE Active set updates are possible for the anchor carrier. The NodeB shall reply with NBAP message RADIO LINK RECONFIGURATION FAILURE and include the cause value "Multi Cell operation not available". As part of the reconfiguration to HSPA for DC capable UEs the RNC checks DC applicability of the new cell. On receipt of message RADIO LINK RECONFIGURATION FAILURE with cause value "Multi Cell operation not available" the RNC attempts to reconfigure the call to HSPA with SC operation. only. PRIMARY LINK CHANGE 4.1. The RNC includes the IE "Downlink secondary cell info FDD" in the RRC message RADIO BEARER RECONFIGURATION.3. The existing criteria for primary link change.19.2 DC operation has no influence on the decision to perform Primary Link Change (PLC). Passing on or copying of this document.UMTS Radio Mobility 4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. If DC is applicable then the RNC enhances the reconfiguration to HSPA by inclusion of the secondary cell information.19. RNC 9370 handles primary cell change and active set update as separate procedures. DC operation affects the primary cell. For this the RNC appliesthe existing R99 to HSPA reconfiguration procedure. event 1d. E-DCH Active Set o No special handling is needed for DC operation in case of E-DCH active set change.19. e.g. only.3. R99 to HSDPA DC case Successful Operation If for a R99 call the primary link changes then a reconfiguration to HSPA may get triggered .1 4. The RNC considers the reconfiguration to HSPA DC as successful on reception of RRC message RADIO BEARER RECONFIGURATION COMPLETE.19. • • Links over IuR o No special handling is needed for DC operation on active set update over IuR.3 4.3.

Passing on or copying of this document. Thus.and intra-NodeB serving cell change.06/EN Approved_Standard 17/Sep/2010 Page 123/244 . The RNC considers the serving cell change with DC target as successful on reception of RRC message RADIO BEARER RECONFIGURATION COMPLETE Unsuccessful Operation If due to any reason the new serving NodeB is not able to establish the secondary cell requested by the RNC in the RADIO LINK RECONFIGURATION PREPARE message then the NodeB shall completely fail the radio link reconfiguration.this is existing functionality. As part of the serving cell change for DC capable UEs the RNC checks DC applicability of the new cell. The RNC includes the IE "Downlink secondary cell info FDD" in the RRC message RADIO BEARER RECONFIGURATION. Same procedure applies for inter. For this the RNC applies the existing serving cell change procedure. In case of PLC for a SC call and for the new cell DC is applicable then the RNC enhances the serving cell change procedure by inclusion of the secondary cell information: The RNC includes one instance of the IE "Additional HS Cell Information RL Reconf Prep" in the NBAP message RADIO LINK RECONFIGURATION PREPARE to the new serving NodeB with following sub-IEs: • • • HS-PDSCH RL ID C-ID HS-DSCH FDD Secondary Serving Information The NodeB shall include the IE "Additional HS Cell Information Response" in the NBAP message RADIO LINK RECONFIGURATION READY. Note: The RNC does not know if the failure was caused by the DC configuration or any other reason. Note: No special handling is needed for DC because the RADIO LINK RECONFIGURATION CANCEL message which is part of the existing failure handling will remove the DC configuration from the new serving NodeB if the preparation had failed for the old serving NodeB. The NodeB shall reply with NBAP message RADIO LINK RECONFIGURATION FAILURE and include the cause value "Multi Cell operation not available". On receipt of message RADIO LINK RECONFIGURATION FAILURE with cause value "Multi Cell operation not available" the RNC attempts to perform serving cell change with target SC operation.UMTS Radio Mobility Note: No special handling is needed for DC because the RADIO LINK RECONFIGURATION CANCEL message which is part of the existing failure handling will remove the DC configuration from the new serving NodeB if the preparation had failed for a non-serving NodeB. a new RADIO LINK RECONFIGURATION PREPARE with SC HSPA configuration must be sent to the new serving NodeB only. HSDPA SC to DC case Successful Operation In case of PLC for a HSPA call the serving cell is changed from old to new serving cell . this will remove the DC configuration in the NodeB. Notes: In case of inter-NodeB serving cell change the old serving NodeB is already configured at this time. In case of intra-NodeB serving cell change the new serving NodeB is also the old serving NodeB. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. The existing failure handling is the reconfiguration to R99. In case the RNC receives a Radio LINK Reconfiguration failure message the RNC applies the existing failure handling for R99 to HSPA configuration.

this is existing functionality. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. As part of the serving cell change for DC capable UEs the RNC checks DC applicability of the new cell. HSDPA DC to SC case Successful Operation In case of PLC for a HSPA call the serving cell is changed from old to new serving cell . The RNC does not know if the failure was caused by the DC configuration or any other reason. The new serving NodeB shall include the IE "Additional HS Cell Information Response" in the NBAP message RADIO LINK RECONFIGURATION READY. no changes required for DC. The RNC considers the serving cell change with DC target as successful on reception of RRC message RADIO BEARER RECONFIGURATION COMPLETE Unsuccessful Operation The RNC handles unsuccessful PLC from DC to DC cell in the same way as for SC to DC. this will remove the DC configuration in the NodeB.this is existing functionality. In case of PLC for a DC call and for the new cell DC is not applicable then the RNC enhances the serving cell change procedure as follows: Passing on or copying of this document. As part of the serving cell change for DC capable UEs the RNC checks DC applicability of the new cell.UMTS Radio Mobility In case the RNC receives a RADIO BEARER RECONFIGURATION FAILURE message the RNC applies the existing failure handling for serving cell change.06/EN Approved_Standard 17/Sep/2010 Page 124/244 . The existing failure handling is the reconfiguration to R99. The RNC includes the IE "Downlink secondary cell info FDD" in the RRC message RADIO BEARER RECONFIGURATION. In case of PLC for a DC call and for the new cell DC is also applicable then the RNC enhances the serving cell change procedure by inclusion of the secondary cell information: In case of intra-NodeB serving cell change the RNC includes one instance of the IE "Additional HS Cell Information RL Reconf Prep" in the NBAP message RADIO LINK RECONFIGURATION PREPARE to the serving NodeB with following sub-IE: • • • HS-PDSCH RL ID C-ID HS-DSCH FDD Secondary Serving Information In case of inter-NodeB serving cell change the RNC includes one instance of the IE "Additional HS Cell Information RL Reconf Prep" in the NBAP message RADIO LINK RECONFIGURATION PREPARE to the new serving NodeB with following sub-IEs: • • • HS-PDSCH RL ID C-ID HS-DSCH FDD Secondary Serving Information Note: In case of inter-NodeB serving cell change the secondary cell on the old serving NodeB is implicitly removed together with the anchor cell due to inclusion of IE "HS-DSCH MAC-d Flows To Delete". HSDPA DC to DC case Successful Operation In case of PLC for a HSPA call the serving cell is changed from old to new serving cell .

The RNC is able to handle DC mobility procedures with SRB over DCH.3. e.1. The RNC considers the serving cell change with SC target as successful on reception of RRC message RADIO BEARER RECONFIGURATION COMPLETE. The RNC verifies the E-DCH capability of the new primary link as one of the pre-conditions for DC-HSDPA operation.1.06/EN Approved_Standard 17/Sep/2010 Page 125/244 . • PLC to DRNC implies reconfiguration to single cell. The RNC includes in this message the IE "Additional HS Cell Information RL Reconf Prep" dependent on the use case: Use cases: a) PLC with reconfiguration from SC to DC (inter. • PLC from DRNC to SRNC triggers reconfiguration to DC if applicable. the existing functionality applies. only.1.SRB over HSPA". the RNC receives message RADIO LINK RECONFIGURATION FAILURE or RADIO BEARER RECONFIGURATION FAILURE. 4.19.1.3 UPLINK ASPECTS In this release DC-HSDPA is supported with E-DCH in the uplink. Note: It is not required to include IE "HS-DSCH Secondary Serving Remove" in the NBAP message to the old serving NodeB. then the RNC applies the existing failure handling for serving cell change.e.4 SRB ASPECTS In UA07. 4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.19.5 IUR ASPECTS DC operation over Iur is not supported in this release then. HSPDA DC to R99 case The RNC handles a PLC with reconfiguration from DC HSPA to R99 in the same way as for SC HSPA to R99.6 MESSAGING NBAP The RNC uses NBAP message RADIO LINK RECONFIGURATION PREPARE for serving HS DSCH cell change.2 only SRB over DCH is supported. The new serving NodeB is configured as SC with the existing procedure.UMTS Radio Mobility In case of intra-NodeB serving cell change the RNC includes one instance of the IE "Additional HS Cell Information RL Reconf Prep" in the NBAP message RADIO LINK RECONFIGURATION PREPARE to the serving NodeB with following sub-IEs: • • HS-PDSCH RL ID HS-DSCH Secondary Serving Remove Note: No changes are required to existing procedure in case of inter-NodeB serving cell change: The secondary cell on the old serving NodeB is implicitly removed together with the anchor cell due toinclusion of IE "HSDSCH MAC-d Flows To Delete".1.3.19.3. i. SRB over HSPA is planned for UA08 with feature 29810 "Fractional DPCH . 4.g.or intra-NodeB) or R99 to DC NBAP message to the new serving NodeB: One instance of IE "Additional HS Cell Information RL Reconf Prep" with following sub-IEs: Passing on or copying of this document.3. 4. Unsuccessful Operation In case of failure.19.

the RNC omits the IE "Downlink secondary cell info FDD" in the RRC message RADIO BEARER RECONFIGURATION.2 4. In case of serving HS-DSCH cell change with DC disabled in target configuration. call remains on DC NBAP message: One instance of IE "Additional HS Cell Information RL Reconf Prep" with following sub-IEs: • HS-PDSCH RL ID • C-ID • HS-DSCH FDD Secondary Serving Information d) PLC inter-NodeB.2. call remains on DC Same as a) for new serving cell Note: In case of inter-NodeB the secondary cell on the old serving NodeB is implicitly removed together with the anchor cell due to inclusion of IE "HS-DSCH MAC-d Flows To Delete".1 HARD HANDOVER HHO FROM R99/SC/DC TO DC Successful Operation In case of HHO for a DC capable UE the RNC checks DC applicability of the target cell as with respect of dual cell admission control. RRC The RNC uses RRC message RADIO BEARER RECONFIGURATION for serving HS-DSCH cell change.3. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the RNC includes the IE "Downlink secondary cell info FDD" in RRC message RADIO BEARER RECONFIGURATION. For this the target RNC shall enhance the existing HHO procedure: The RNC includes one instance of the IE "Additional HS Cell Information RL Setup" in the NBAP message RADIO LINK SETUP REQUEST to the target NodeB with following sub-IEs: • HS-PDSCH RL ID • C-ID • HS-DSCH FDD Secondary Serving Information The NodeB shall include the IE "Additional HS Cell Information Response" in the NBAP message RADIO LINK SETUP RESPONSE.3.06/EN Approved_Standard 17/Sep/2010 Page 126/244 .UMTS Radio Mobility • • • HS-PDSCH RL ID C-ID HS-DSCH FDD Secondary Serving Information b) PLC intra-NodeB with reconfiguration DC to SC NBAP message to the serving NodeB: One instance of IE "Additional HS Cell Information RL Reconf Prep" with following sub-IEs: • HS-PDSCH RL ID • HS-DSCH Secondary Serving Remove Note: In case of inter-NodeB the secondary cell on the old serving NodeB is implicitly removed together with the anchor cell due to inclusion of IE "HS-DSCH MAC-d Flows To Delete". c) PLC intra-NodeB. In case of serving HS-DSCH cell change with DC enabled in target configuration. If DC is applicable then the RNC applies DC configuration on the target cell. e) PLC with reconfiguration from DC to R99: will behave as the existing reconfiguration messages without any specifics for DC.19. 4. Passing on or copying of this document.19.

In case the RNC receives a RADIO LINK SETUP FAILURE with a failure cause value other than "Multi Cell operation not available" from the target NodeB then the RNC applies the existing failure handling for HHO.3. The existing failure handling includes the deletion of the new radio links on NBAP. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.3. In case the RNC receives a RADIO BEARER RECONFIGURATION FAILURE message the RNC applies the existing failure handling for HHO.e.3. For this the SRNC shall: • • reconfigure DC calls to SC. this will remove the DC configuration in the target NodeB. In case of unsuccessful operation the call either has dropped or continues on the old (DC) configuration without any specific action.3 SRNS RELOCATION This feature does not introduce the R8 transparent container for SRNS Relocation.19. i.2 HHO FROM DC TO SC/R99 The RNC and NodeB shall handle the HHO from DC to SC or DC to R99 in the same way as the existing HHO procedure from SC to SC or SC to R99. Unsuccessful Operation If in the target NodeB the anchor cell establishment would be successful but due to any reason establishment of the secondary cell requested by the RNC in the RADIO LINK SETUP REQUEST message is not possible then the NodeB shall: • completely fail the radio link setup including anchor cell. and • reply on NBAP with message RADIO LINK SETUP FAILURE with failure cause "Multi Cell operation not available". For SRNS Relocation of 3GPP R8 UEs the SRNC shall use the R7 transparent container. for UE capability information o map R8 IEs to R7 IEs where possible o omit R8 specific IEs As part of the existing post SRNS Relocation procedures for both.UMTS Radio Mobility The RNC includes the IE "Downlink secondary cell info FDD" in the RRC message RADIO BEARER RECONFIGURATION. 4.1 UE INVOLVED If for a DC call SRNS Relocation UE involved is triggered then the RNC reconfigures the call to SC prior to the SRNS Relocation. On receipt of message RADIO LINK SETUP FAILURE with cause value "Multi Cell operation not available" the RNC retries the HHO with SC configuration on target cell. to a R7 compliant configuration. Note: Reconfiguration to SC is required because R8 transparent container is not supported. Passing on or copying of this document. 4.19. UE involved and UE not involved the target RNC requests the UE capabilities. 4. Note: The RNC does not know if the failure was caused by the DC configuration or any other reason.2. When the UE capabilities are received and indicate DC capability then the target RNC shall consider a reconfiguration to DC operation on next mobility soft or hard handover as specified in previous section dedicated to the both procedures.3.06/EN Approved_Standard 17/Sep/2010 Page 127/244 .19. Note: In case of successful operation the source active set is deleted and it is not important if the configuration was SC or DC.

Passing on or copying of this document.331 section 8.20. it shall reject this RL Setup with failure cause "Multi Cell operation not supported". There is a need to distribute the traffic between the different layers including 2G (GSM) layers.3. • 4) HSDPA Dual Cell to R99 Cell.HsdpaMobilityUnsuccess Description: Number of unsuccessful HSDPA Dual Cell mobility described by the following screenings: • 1) HSDPA Dual Cell to HSDPA Dual Cell. 4.19. • 5) R99 Cell to HSDPA Dual Cell. • 5) R99 Cell to HSDPA Dual Cell.19. Thus. Carrier redirection preferences and mobility triggers. • 4) HSDPA Dual Cell to R99 Cell.3. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Addition or Reconfiguration with HS-DSCH Secondary Serving Information IE. • 3) HSDPA Single Cell to HSDPA Dual Cell. micro cells Hierarchical cells structure.3 some UEs might not require compressed mode for measurements on adjacent frequencies . • 2) HSDPA Dual Cell to HSDPA Single Cell. • If DRNC receives RNSAP message RL Setup. The NodeB shall apply the same compressed mode algorithm to anchor and supplementary carrier.3. please refers to [R6] for this purpose. The traffic distribution strategy may be based on load balancing. But.06/EN Approved_Standard 17/Sep/2010 Page 128/244 . Reference Cell is new primary cell of call.HsdpaMobilitySuccess Description: Number of successful HSDPA Dual Cell mobility described by the following screenings: • 1) HSDPA Dual Cell to HSDPA Dual Cell. Note: No separate NBAP compressed mode commands are required for the supplementary carrier.19.19.see also 3GPP section 10.1. then the NodeB has to apply the same compressed mode configuration with same timing on the supplementary carrier. the SRNS Relocation "UE not involved" is not directly affected by DC in this release. INTELLIGENT MULTI CARRIER TRAFFIC ALLOCATION (IMCTA) To increase the network capacity.3. Reference Cell is new primary cell of call.4 PARAMETERS No new parameters have been dedicated specially to the mobility aspects. 4. operators may deploy multi layer configurations with several layers structures: Multi layers with equal coverage.5 PERFORMANCE MANAGEMENT The following counters have been added Name: VS. UE speed.4 COMPRESSED MODE As per 3GPP 25. But there are some related aspects that need to be handled as detailed below.2 UE NOT INVOLVED During SRNS Relocation "UE not involved” the call is on single cell because DC is not supported over IuR.4.21 for the UE measurement capability information. the dual cell hsdpa operation feature needs to be activated.UMTS Radio Mobility 4. Service partitioning. When the NodeB for a UE with DC call applies compressed mode to the anchor carrier. 4. • 3) HSDPA Single Cell to HSDPA Dual Cell. Name: VS. Hot spots. 4.3. • 2) HSDPA Dual Cell to HSDPA Single Cell.

It includes the Alarm Handover.20.e. The iMCTA function is managed by the RNC.20. 4. the service type. HSUPA capable or not).UMTS Radio Mobility The introduction of HSDPA/HSUPA will be also progressive with hot spots and there is a need to redirect HSDPA/HSUPA capable mobile towards HSDPA/HSUPA cells. A fallback to another Carrier may be done.1 DESCRIPTION IMCTA function allocates traffic across available carriers. Passing on or copying of this document.06/EN Approved_Standard 17/Sep/2010 Page 129/244 . The iMCTA function covers this network evolution. A CAC reason: a CAC failure occurs during the processing of a Rab Assignment sent by the CN.1. the mobile type (i. HSDPA. the redirection triggers and the cells load. the carrier is selected by the RNC according to the Operator strategy through iMCTA configuration parameters (including Priority tables) which allows to take into account the Handover reason. 2G R99 R5 FDD2 HSDPA/HSUPA R5 FDD1 non HSXPA Figure 62: Service Redirection application R5 FDD2 HSDPA/HSUPA R5 R5 R5 FDD1 HSDPA/HSUPA Figure 63: Load balancing application 4.1 IMCTA TRIGGERS The main reasons to invoke the iMCTA function are: Alarm condition is hit. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. For a given call.

iMCTA may be called. After a mobile performs a successful Always On upsize from Cell_FACH or URA/Cell_PCH to Cell_DCH. It concerns HSDPA and HSUPA non capable mobiles traffic connected in DCH. IUR. 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. iMCTA doesn’t apply to IRM table reject cases. iMCTA trigger: Alarm HO reason The Alarm criterion for Inter Frequency and the Inter Rat Handover is described in section 5. a Always On upsize or an IU Release Command is done but the mobile may be moved to a better Carrier. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility A user service reason: A successful Rab establishment/modification/release. Incoming Relocation with one or several Traffic Rab. 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. 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. The User and mobility Service triggers don’t apply if the primary cell is managed through Iur. 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. iMCTA trigger: Mobility Service reason The triggers which invoke the iMCTA functions are: It concerns HSDPA or HSUPA capable mobiles traffic connected in DCH and/or HS-DSCH and/or EDCH. 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).e. primary cell) is eligible regarding its load level. 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. The iMCTA is invoked if the final state of the call is: one or several Traffic Rab are established. primary cell) is eligible regarding its load. a HSxPA to DCH fallback may be attempted. When a CAC failure occurs during a Rab Assignment towards HSxPA. using origin cell load colour threshold different from green.9. The triggers are valid if the originating cell (i. a Rab release or a modification of the established Traffic type.e. A mobility service reason: A successful Intra Freq mobility is done but mobile may be moved to a better Carrier. The Alarm and CAC triggers apply even if the primary cell is managed through Iur. If the fallback faces up a CAC failure or may not apply. has not to be used if we want no limitation of the redirection application. This trigger belongs to “Service” triggers. The triggers are valid if the originating cell (i.06/EN Approved_Standard 17/Sep/2010 Page 130/244 . Passing on or copying of this document. The trigger is a primary link cell change with the new primary cell configured with mobilityServiceForHsxpaEnable O&M attribute set to True. The trigger is a primary link cell change with the new primary cell configured with mobilityServiceForNonHsxpaEnable O&M attribute set to True. IU: Transport Resource allocation failure From RNC Uplane: Resource allocation failure From C-RNC: User Plane Dedicated Bearer allocation failure. i.e. iMCTA applies in case of Rab Assignment procedure inducing a successful fallback on DCH when no HSDSCH resource is available.

e.20.2.UMTS Radio Mobility If service segmentation is activated.2. If the target access changes. apply in decreasing priority order: • Fallback to DCH • iMCTA • preemption (refer to [R12]) 4. 4. iMCTA may be called (see [R6]). the load of the originating cell is not taken into account.20. plus a 2G layer (whatever the frequencies). In case of CAC failure.2 APPLICABILITY The iMCTA function only applies to calls in Cell DCH. Cell PCH or URA PCH connected mode are not managed. o User or Mobility Service triggers = Primary cell change or Service modification. if applicable.20. a HSxPA to DCH fallback may be attempted. o Priority Rule between iMCTA triggers and others procedures: o Alarm/CAC triggers > Primary cell change or Service modification. 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 4. iMCTA works with up to six UMTS carriers1.06/EN Approved_Standard 17/Sep/2010 Page 131/244 . the Measurement period may be re-started after the expiration (i. The following rules apply: o Priority Rule between iMCTA triggers: Alarm > CAC > User Service > Mobility Service. 1 As per 3GPP [A7] UEs are required to support the own carrier and two additional FDD carriers. Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. If the fallback faces up a CAC failure or may not apply.1. Calls in Cell Fach (signaling or traffic).2 IUR MANAGEMENT Following tables gives the type of procedure executed according to the type of source/target cell and iMCTA trigger. a second iMCTA trigger. The following actions occur: o The last event (iMCTA trigger or Primary cell change or Service modification) may induce an update of the neighbour cells. a Primary link modification or a Service modification may occur. when User service or Mobility service trigger is used. o When the second event has a higher or equal priority than the previous with no target access change. the measurement period is stopped and re-started with the new neighbouring. E-DCH and HS-DSCH connected mode.1 MANAGEMENT IN CELL HSXPA When a CAC failure occurs during a Rab Assignment towards HSxPA.20. 4.2 CROSSOVER BETWEEN IMCTA TRIGGERS OR WITH OTHERS PROCEDURES When the RNC waits for iMCTA measurements for a given trigger. following procedures. no target cell identified) of the current period.

2 IMCTA TRIGGER = CAC FAILURE Target cell S-RNC S-RNC Interfreq intraRNC HHO ok (1)(2) Interfreq interRNC HHO ok (2) D-RNC No HHO (no measurement started)(3) Source cell D-RNC No HHO (no measurement started)(3) (1) CAC failure and R5 mobiles: During intra RNC inter frequency HHO.UMTS Radio Mobility 4.2. This is due to ciphering issue at UE side. when IMCTA CAC is hit and decision is made to launch an inter freq HHO. 3G3G relocation otherwise No HHO (no measurement started ) (1) (1) No service handover from D-RNC because load information not reliable 4.2. The Radio Bearer Release (and also Radio Bearer Setup) message provides this capability from Rel6. CAC failure and directed retry The 3GPP allows Directed Retry via relocation for RAB CS establishment failure use case only towards 2G. 4.3 IMCTA TRIGGER = ALARM Passing on or copying of this document. modifying RLC information has to be processed.2.20. if changing the Transport channel from HSxPA to DCH or vice-versa is needed.2. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. (2) CAC failure and interfreq HHO: Any time Rab Assignment request is processed for a CS Rab setup.20.2.1 IMCTA TRIGGER = SERVICE Target cell S-RNC S-RNC Source cell D-RNC No HHO (no measurement started) (1) Interfreq intraRNC HHO OK D-RNC Interfreq InterRNC HHO ok if feature activated (with fallback to DCH before for HSPA calls). For a Rel5 UE. the procedure Radio Bearer Setup used to add the CS Rab on the new frequency is replaced by two consecutive RRC procedures: • Inter Frequency Radio Bearer Reconf to perform first mobility on the new frequency. A 3G3G relocation is not supported in that case. the FDD target cell shall be managed by the S-RNC.06/EN Approved_Standard 17/Sep/2010 Page 132/244 . • Intra frequency Radio Bearer Setup to add the new CS Rab.2. this shall be done separately with a Radio Bearer Reconfiguration: this R5 CAC failure use case is not supported by iMCTA in this version.20. (3) CAC failure and 3G3G Relocation Upon CAC failure.

2.2.3. If the mobile doesn’t support this state. the HHO ends by processing the failure case (call kept on the FDD access). If the UE doesn’t supports this use case.2. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2. (2) CAC failure and 3G2G Relocation: When a CAC failure occurs during the CS Rab establishment: • When a PS call is already established. So ALU does the best effort policy: HHO is attempted. A 3GPP R2-062614 (release 6 Sept 2006) asks to support a HHO Inter Rat when a PS + CS signalling is established.3 2G INTER RAT MANAGEMENT Following tables gives the type of procedure executed according to the type of RAB established/to establish and the iMCTA trigger.3. 3G3G relocation otherwise Interfreq IntraD-RNC or InterD-RNC HHO ok if feature activated (with fallback to DCH before for HSPA calls).20. This use case is supported in 3GPP Rel 6 (Sept).2 IMCTA TRIGGER = CAC FAILURE RAB established on source cell Signalling Signalling Signalling + CS Signalling + PS RAB to establish CS PS PS CS RAB assignment failure (cause directed retry) + 2G interRAT HHO RAB assignment failure (cause unspecified) + 2G interRAT HHO (Cell Change Order)(1) RAB assignment failure for PS (cause unspecified) + 2G interRAT HHO for CS (1) RAB assignment failure (cause directed retry) + 2G interRAT HHO if supported by UE (2) (1) The 3GPP only allows Directed Retry for RAB CS establishment failure use case.20.1 IMCTA TRIGGER = SERVICE RAB established on source cell CS PS CS + PS 2G interRAT HHO 2G interRAT HHO (cell change order) 2G interRAT HHO (with/without PS reestablishement according to UE class) 4. 4.06/EN Approved_Standard 17/Sep/2010 Page 133/244 .20. iMCTA triggers a Directed Retry towards the 2G. the redirection failed and the mobile stays with the PS established.20.UMTS Radio Mobility Target cell S-RNC S-RNC Source cell D-RNC Interfreq intraRNC HHO ok Interfreq interRNC HHO ok D-RNC Interfreq InterRNC HHO ok if feature activated (with fallback to DCH before for HSPA calls). 4.3.3 IMCTA TRIGGER = ALARM Passing on or copying of this document. 3G3G relocation otherwise 4.

4.20. 5.3.4 IMCTA LOAD BASED HO DEVELOPMENTS [USA MARKET] This feature is introduced in UA07.3 4. 3. If no target cell is found after iMCTA algorithm processing or no measurement received or the HHO failed. a iMCTA blind HHO may be attempt to the 2G twin cell (if configured). 8. when no Inter Freq/Inter Rat measurement can be requested to the mobile (compressed mode not allowed for the Service).3. Selection of the candidate Cells for UE measurements. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility RAB established on source cell CS PS CS + PS 2G interRAT HHO 2G interRAT HHO (cell change order) 2G interRAT HHO (with/without PS reestablishement according to UE class) 4. 4. iMCTA HHO processing or iMCTA exit . o mobilityServiceForHsxpaEnable and mobilityServiceForNonHsxpaEnable O&M attribute value.20. This feature by choosing the most suitable access (GSM or FDD) will decrease the handover failure rate during Handover algorithm. 4. Configuration of the Compressed mode and of the UE measurements. Checking of the iMCTA feature activation parameters . 6. When the trigger is Service: o Originating cell load eligibility (if service segmentation not activated).2. 7. Identification of the Service Type and RAB to be set.20.4). no eligible target cell is found in the reported measurements.2 IMCTA FEATURE ACTIVATION The iMCTA feature activation is based on: mode O&M attribute value (see 4.20. It can be activated through parameter isImctaLoadBasedAllowed The feature iMCTA load based HO developments uses load indicators which are undefined when the originating cell or the target cell are located on a D-RNC. the RNC has to wait the next iMCTA trigger iteration for a new call redirection attempt.3. the function may process the following functional steps to identify a target cell on another Carrier: 1. 4.1 ALGORITHM MAIN FUNCTIONAL STEPS If one of the triggers is valid for the primary cell. Selection of the iMCTA Carrier priority table.20.20.06/EN Approved_Standard 17/Sep/2010 Page 134/244 .1. 2. The risk detection is based on the target FDD cell load estimation but also in case of HHO CAC failure reason on the cause of the CAC failure. For this reason the criteria attached to the feature iMCTA load based HO developments don’t apply to a cell located on a D-RNC. It enhances the iMCTA triggering in order to avoid choosing an inter frequency HHO when a risk of HHO failure exists when the handover reason is alarm or CAC. For an alarm HHO trigger. Cell selection upon Measurement Report. Selection of the candidate Carriers.3 NEIGHBOUR CARRIERS SELECTION iMCTA is triggered for Service reason Passing on or copying of this document.

o For CAC all DRNC cells are filtered if no SRNC cells are to be measured of that carrier.e. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.4. Compressed Mode applicability for the current service and UE capability). The O&M FDD neighbouring provisioning of a cell has to be limited to 2 carriers in order to fulfill the mobile measurements performance requirements defined in [A7] (the 3GPP doesn’t describe the UE behaviour in case of more than 2 neighbour carriers). 2G cells are removed.2. 4. CAC or Service) the compressed mode activation and the measurements activation procedures are the same. All following actions occur whatever the iMCTA trigger: The neighbouring cells fulfilling the IMSI based HO condition and belonging to layers supported by the mobile (UE capabilities checked) are selected and ordered according to the Carriers priorities for the requested Service type (according to the service priority table).5 COMPRESSED MODE AND MEASUREMENT CONFIGURATION Inter Frequency and Inter RAT measurements are configured in periodic Mode. mobility use case). If the carriers list is empty.20. In case of Alarm. Passing on or copying of this document.e.06/EN Approved_Standard 17/Sep/2010 Page 135/244 . For each neighbour cells type (Inter Freq / Intra Freq / 2G). Cells which must not be measured are discarded from the neighbour cells list. iMCTA is triggered for Alarm or CAC reason All carriers (2G or 3G) with a priority not equal to PNA are candidate for iMCTA target cells selection. 4.or for alarm or CAC when a load criteria is requested by the feature iMCTA load based HO developments]): o If all Fdd cells of a given Fdd carrier don’t fulfill the target cell load criteria.UMTS Radio Mobility The Service priority table set by O&M (refer to 4. • If GSM cells have the same priority as the Fdd cells with highest priority. If the target cells list is empty. the iMCTA function is cancelled (step 8 is processed) when the triggering is for CAC or Service reasons.3. all cells are kept. • If highest priority Fdd cells have a priority strictly higher than 2G cells.4 NEIGHBOUR CELLS SELECTION FOR MEASUREMENT REPORTING When the candidate carriers are identified. Fdd cells are removed. The carriers with a priority higher or equal to the current one are candidate for iMCTA target cells selection. the measurement capability is checked (i. the selection of the neighbour cells (see section 5. Section 6.20. Whatever the iMCTA trigger (Alarm. the iMCTA function is cancelled (step 8 is processed). If the iMCTA neighbouring cells list after applying the different filters contains Inter Freq Cells and 2G (GSM) cells: • If GSM cells have strictly the highest priority.4) is read for the service type requested or in progress (i. If activated by parameter “isImctaFddLayerLoadPreCheckAllowed“ (and isImctaLoadBasedAlarmAllowed for alarm) and if the target cell load filtering criteria applies to Fdd cells (for service reason [USA Market .3. Refer to: Section 6.5) is sent to the mobile for measurement.20. an iMCTA blind HHO may occur. the cells are filtered (the Fdd carrier will not be monitored) from the neighbor cell list.

5. according to the mobile capabilities the non HSxPA cells for a HSxPA capable mobile and the HSxPA cells for a non HSxPA UE are removed. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Preference is given to the less loaded cell. i.6 TARGET CELL SELECTION UPON MEASUREMENT REPORT The RRC Measurement Report message due to iMCTA function invoke may be postponed (“blocking phase”) by the RNC and processed at the end of the current procedure when another procedure (SHO. primary cell) load color (except if service segmentation has a higher priority). Cell(s) belonging to the Carrier with the highest priority is kept. Rate modification…) is in progress. The following paragraphs describe the target cell selection for each trigger type.re-attempt handover to this 2G cell.06/EN Approved_Standard 17/Sep/2010 Page 136/244 .5. Then if HSDPA traffic segmentation option (see [Parameters] section) is set to true.6. If a target cell (FDD or 2G) exists after applying the different filtering steps the HHO is processed. CAC. The following steps are processed to select a cell among the measured 2G neighbour cells: 1.20.6. 3. their Rxlev verify 2G HHO condition. 2. Then the FDD cells are filtered according to the following rule: a. it’s the cell with the best Ec/No which verifies FDD HHO condition. Service). the cell is removed. This re-attempt can be controlled with parameter isGsmIratHoToNextBestCellAllowed. If FDD and 2G neighbour cells are eligible then the FDD target is selected if parameter is3GHandoverPreferred is set to TRUE or vice versa. Rab Assignment. An iMCTA criteria re-evaluation/evaluation is done (i. Otherwise the RNC waits next measurement reports until the guard timer elapses.3. the best measured cell which fulfills the Radio criteria is selected. The cells which fulfill the Radio criteria are selected. Then if several FDD cells are eligible. Any Inter freq or Inter RAT measurement due to iMCTA function received after the guard timer elapses is discarded. Preference is given to the cell with the best Radio level (Ec/No). Then the neighbour cells not fulfilling the 2G cell color load criteria are filtered (see [iMCTA cell load criteria] section).4. if the capability of the target cell with respect to HSxPA does not match partially or fully the capability of the UE (refer to § 4.1.20. Section 6.e. 3.1 IMCTA TRIGGER IS SERVICE The following steps are processed to select a cell among the measured FDD neighbour cells: 1.e. If 2G is selected as target and the relocation preparation to the selected target cell fails.if found any . A cell belonging to a Carrier with a priority equal to the originating cell carrier priority shall have a cell load color fulfilling the target cell load color criteria (see [iMCTA cell load criteria] paragraph) and lower than the originating cell (i. 4. 4.g. e.1 for details). due to load conditions in the GSM cell. Then if several 2G cells are eligible. b. For each Carrier. i. 2. the following steps (with decreasing priority) are processed until retaining one cell: a.20. b. Passing on or copying of this document. c. The Radio criteria for target cell selection are the same whatever the trigger (Alarm.3. A cell belonging to a Carrier with a priority upper than the originating cell Carrier priority shall have a cell load color fulfilling the target cell load color criteria (see [iMCTA cell load criteria] section). then the RNC may re-evaluate the measurement report for the next best 2G neighbour cell and . the cell with the highest radio level is selected (Ec/No).UMTS Radio Mobility 4.e. Refer to: Section 6. Then if Service segmentation priority option (see [Parameters] section) is set to true. iMCTA neighbor cells list may be updated) before processing the RRC Measurement Report message: a measured cell is candidate to the iMCTA cell selection criteria if it belongs to the iMCTA neighbor cells list.e.

The cells fulfilling the Radio criteria are selected.6.e.2 IMCTA TRIGGER IS CAC FAILURE The following steps are processed to select a cell among the measured FDD neighbour cells: 1.UMTS Radio Mobility 4. [USA Market . Note 2: A WPS call is not eligible to feature iMCTA load based HO developments. This re-attempt can be controlled with parameter isGsmIratHoToNextBestCellAllowed. preference is given to HSUPA cells then HSDPA cells else if UE is HSDPA capable. i.3.If iMCTA load based HO developments is activated: If no FDD cell is eligible. For each Carrier .e. the cell with the best Ec/No which verifies FDD HHO condition . The following steps are processed to select a cell among the measured neighbour 2G cells: 1.If iMCTA load based HO developments is activated Passing on or copying of this document. Preference is given to the cell with the best radio level (Ec/No). a GSM cell will be selected if a suitable GSM cell is reported by the UE (see previous paragraph and note 1) ] If FDD and 2G neighbour cells are eligible then the FDD target is selected if parameter is3GHandoverPreferred is set to TRUE or vice versa.[USA Market . The less loaded cell is preferred.3.8.the best measured cell which fulfils the Radio criteria is selected. the CEM load color of the target cell has to be strictly better than the CEM load color of the current active set. AND • If the CAC failure reason is due to: o A Iub CAC failure (bandwidth lack or CID lack): the Iub load color (see note 3) of the target cell has to be strictly better than the iub load color of the current active set. the cell with the highest Radio level is selected. b) Preference is given to the less loaded cell.e.] 2. the cell with the best Ec/No which verifies FDD HHO condition. e. .3). due to load conditions in the GSM cell. 2.6. the following steps (with decreasing priority) are processed until retaining one cell: a) If UE is HSUPA capable.20. Then if several FDD cells are eligible. For each Carrier . o A NodeB CAC failure (on one or several cells of the active set): If the CEM load is relevant for the current active set cell and for the target FDD cell.20.If iMCTA load based HO developments is activated • Its load satisfies the target cell Load iMCTA based HO load color criteria (described in section 4. c) d) Preference is given to cell(s) belonging to the carrier with the highest priority. i.[USA Market . preference is given to HSDPA cells.if found any .3.g. Note 3: The Iub load color is the load part attached to the QoS of the services to be established.the best measured cell which fulfils the Radio criteria is selected. then the RNC may re-evaluate the measurement report for the next best 2G neighbour cell and . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. If 2G is selected as target and the relocation preparation to the selected target cell fails. their Rxlev verify 2G HHO condition. i. 3.06/EN Approved_Standard 17/Sep/2010 Page 137/244 .re-attempt handover to this 2G cell.20. Then if several 2G cells are eligible. Note 1: the blind GSM cell is not used by iMCTA when the HHO reason is a CAC failure. 4.3 IMCTA TRIGGER IS ALARM The following steps are processed to select a cell among the measured FDD neighbour cells: 1.

20. the following steps (with decreasing priority) are processed until retaining one cell: a. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.g. A Rab Assignment Response message is returned by the S-RNC to the Core Network.3. 4. The less loaded cell is preferred.] Then if several FDD cells are eligible.e. b.06/EN Approved_Standard 17/Sep/2010 Page 138/244 . If 2G is selected as target and the relocation preparation to the selected target cell fails. Its load satisfies the target cell Load iMCTA based HO load color criteria (described in section 4.8. The cells fulfilling the Radio criteria are selected. o If the Target cell is not managed by the S-RNC (i. a blind GSM cell may be used if configured. o If the Target cell is managed by the S-RNC (i.re-attempt handover to this 2G cell.UMTS Radio Mobility • 2. Inter Freq Intra RNC HHO): The Inter Freq Hard Handover procedure towards the target cell is processed. This re-attempt can be controlled with parameter isGsmIratHoToNextBestCellAllowed. 3. due to load conditions in the GSM cell. i.e. The following steps are processed to select a cell among the measured neighbour 2G cells: 1. Inter Rat): A Rab Assignment failure is returned to the CN with the Rab failed and a “Directed Retry” (CS CN) or “unspecified” (PS CN) cause . Preference is given to cell(s) belonging to the carrier with the highest priority.e.1 IMCTA HARD HANDOVER PROCESSING OR IMCTA EXIT IMCTA HHO PROCESSING When iMCTA function gives a target neighbouring cell to process a Hard Handover (possibly in blind mode if a 2g blind cell is configured and the mobility to the 2G domain is allowed by the Alarm priority table and Service handover option). If no target cell is eligible. d.20. their Rxlev verify 2G HHO condition.If iMCTA load based HO developments is activated: If no FDD cell is eligible a GSM cell will be selected if a suitable GSM cell is reported by the UE (see previous paragraph).7. Then if several 2G cells are eligible. CAC trigger: After a CAC failure during a Rab Assignment/Release/Modification. preference is given to HSUPA cells then HSDPA cells else if UE is HSDPA capable. the transition to the HHO depends on the iMCTA trigger type: Service or Alarm triggers: the HHO mobility procedure occurs and then waiting procedures may be processed. e.3). the following actions are processed: o If resources were partially allocated for the requested Rab they are released. the cell with the highest Radio level is selected. 2. A 3G/2G. c.if found any . Preference is given to the less loaded cell.7 4. [USA Market . If UE is HSUPA capable. Inter Freq RNC HHO): A Rab Assignment failure is returned to the CN with the Rab failed and a “noresource available” cause Passing on or copying of this document.e. o If the Target cell is not managed by the S-RNC (i. Else ] If FDD and 2G neighbour cells are eligible then the FDD target is selected if parameter is3GHandoverPreferred is set to TRUE or vice versa.3. Then waiting procedures may be processed. Preference is given to the cell with the best radio level (Ec/No). then the RNC may re-evaluate the measurement report for the next best 2G neighbour cell and . preference is given to HSDPA cells.20.3.

E-DCH). the following actions are processed: If resources were partially allocated for the requested Rab they are released.20. • Iub downlink load.8 IMCTA CELL LOAD CRITERIA The cell load information is needed by the iMCTA function to filter loaded cells or to give a preference to the less loaded cell. Cell load for the originating cell is not taken into account in case of iMCTA triggered for service reasons when service segmentation has a higher priority than load balancing. they are released.8. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 4. The definition of the load indicators are given in [R7]. the actions are: Service and Alarm trigger: the waiting procedures may be processed.2 ORIGINATING FDD CELL ELIGIBILITY For each Rab established. For cell eligibility.7.3. the originating cell color threshold is configurable per service. The mobile is no more in connected mode (cell DCH). The resource type and the rate to be allocated on a target FDD cell depends on the RNC resource allocation policy (refer to section 4.3. each relevant cell load indicator is checked. 4.2 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 rearmed) and no blind HHO 3G/2G may be processed. 4.3. the elementary load colors depend only on the RABs established or to establish (CAC failure case). The waiting procedures may be processed. • Uplink load (RTWP). If Inter Frequency/Inter Rat measurements were requested to the mobile.20.18).UMTS Radio Mobility For the Hard Handover execution see the section describing the Hard Handover type used.1 CELL LOAD INDICATORS The feature consults the following elementary load indicators: • CEM ul and dl loads. The cell load iMCTA color is built by using metrics linked to DCH and non-scheduled E-DCH resources (and HSDPA ones (power and OVSF codes) if fair sharing feature is activated) occupancy at Cell. The Iub downlink load consulted is the load part attached to the QoS of the services to be established.20. According to the trigger.3. CAC trigger: After CAC failure during a Rab Assignment/ Release/ Modification. The transition depends on the iMCTA trigger type. • Downlink OVSF code load. An originating FDD cell is eligible for iMCTA if one of each relevant cell load colors is higher or equal to the iMCTA originating cell color triggering threshold (parameter originatingCellColourThresholdPerService): Passing on or copying of this document. Whatever the resource used by the call (DCH.8. [UA06-UA07 difference]: With the addition of the feature iMCTA load based HO developments.06/EN Approved_Standard 17/Sep/2010 Page 139/244 .20. a set of cell load elementary colors is read. CEM or Iub levels. • Downlink power load. 4. HS-DSCH. A Rab Assignment Response Failure message is returned by the S-RNC to the CN with the Rab failed.

the target cell load has to be “Green” or “Yellow”. the cell iMCTA color is also green by default.06/EN Approved_Standard 17/Sep/2010 Page 140/244 . Passing on or copying of this document.20. Two colors are supported: green/red. the iMCTA target Cell color threshold has a Red default color.3.3. 4.8. For cells managed by a D-RNC.5 TARGET 2G CELL ELIGIBILITY A 2G target cell is eligible if its color is lower or equal to the iMCTA target cell color triggering threshold (parameter targetCellColourThreshold).3 [USA MARKET] TARGET FDD CELL LOAD IMCTA LOAD BASED HO CRITERIA (USED FOR CAC AND ALARM): The load check can be enabled for iMCTA CAC with parameter isImctaLoadBasedAllowed and for iMCTA alarm with parameters isImctaLoadBasedAllowed and isImctaLoadBasedAlarmAllowed. 4. a set of cell load elementary colors is read. When a neighbour 2G cell is given by a D-RNC and cannot be found in the S-RNC provisioning.4 TARGET FDD CELL ELIGIBILITY (USED FOR SERVICE) For each Rab to establish. If the load check is enabled a FDD cell is eligible by the feature iMCTA cell load based HO if the iMCTA based load HO color of the cell is below or equal to the iMCTA FDD target cell color dedicated to feature iMCTA load based HO developments (parameter imctaLoadBasedTargetCellColorThreshold). the iMCTA target Cell color threshold has a Red default color. 4. For example if the target cell load threshold is equal to “Yellow”.3.8.20.20. A target FDD cell is eligible for iMCTA if each relevant cell load color is lower or equal to the iMCTA target cell color triggering threshold (parameter targetCellColourThreshold): All Cell DL color ≤ iMCTA target cell color threshold AND All Cell UL color ≤ iMCTA target cell color threshold When a FDD cell belongs to a D-RNC but is not in the S-RNC neighbor cells provisioning.UMTS Radio Mobility At least one DL color ≥ iMCTA originating cell color threshold OR At least one UL color ≥ iMCTA originating cell color threshold. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the cell iMCTA color is green by default. At the cell configuration.8.

UMTS Radio Mobility
4.20.3.8.6 TARGET 2G CELL COLOR DEFINITION

The GSM target cell color can be determined two different ways:

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. The 2G cell load detection is based on the receipt of the RANAP Relocation Preparation Failure message with a cause IE value equal to “Relocation failure in target CN/RNC or target system”. The cell color modification trigger occurrence for a GSM cell is linked to the number of HHO 3G2G attempt towards this cell. So the filtering mechanism efficiency may be lower when the trigger occurrence for a GSM cell is low.

uRRM step 2 [Global Market]:
If cell load information present in handover messages from GSM and if cell load management feature is activated, the GSM target cell color is calculated thanks to cell load information. When the 2G cell load information received from the BSC is above the configured congestion threshold, the 2G cell shall be put in Red color for a configurable time or until new cell load information for that cell is received below the congestion threshold (refer to [R7] for more details). Step 1 and step 2 information are exclusive. If cell load information element is present and feature activated, the handover reject cause will not be managed.

4.20.4
4.20.4.1

PARAMETERS
IMCTA OPTIONS
Object/Class RadioAccessService Class 3 ServiceForTrafficSegm entationPriority Class3 RadioAccessService Class 3 RadioAccessService 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 doesn’t occurs. This option doesn’t apply in case of iMCTA

Name serviceHoRanapEnable

IsServiceSegmentationTopPr iority Is2GCellLoadInformationM anagementAllowed [Global Market] InhibitTimer3g2g

mode

FDDCell Class 3

hsxpaSegmentationEnable

FDDCell Class3

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 141/244

UMTS Radio Mobility
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, all relevant target cell colors must be green or yellow. This color is taken into account if iMCTA triggers are different than Alarm or CAC. This parameter may limit iMCTA triggering to the transition signaling to Traffic. If set to TRUE, addition of a new Traffic Rab to a current Traffic Rab, a current Traffic Rab removal, a current RAB modification or an Iu Release command will not trigger iMCTA. Same priority can be configured for inter-frequency and 2G inter-RAT handover. Most UEs need compressed mode for the simultaneous activation of both inter-frequency and inter-RAT measurements. This simultaneous compressed mode may not be possible in certain situations, depending on RAB combination or NodeB capabilities. If simultaneous compressed mode is required but not possible then instead a single target system is measured, only. This parameter specifies whether to perform interfrequency (3G) or inter-RAT (2G) measurements. This parameter enables/disables the IRAT handover to the next best GSM cell if handover is not possible to the first cell due to overload. This parameter enables/disables the change of the Service Handover criterion of CS voice calls for UMTS to GSM handover from 'should' to 'should not' if the UE is involved in an active PS call. Enables the target FDD cell load criteria when iMCTA reason is Alarm or CAC failure. A neighboring FDD cell is eligible as target for feature iMCTA load based HO developments if all relevant cell colors are lower (better) or equal than this threshold. For example, if the threshold is

mobilityServiceForHsxpaEn able

FDDCell Class3

mobilityServiceForNonHsxp aEnable

FDDCell Class3

originatingCellColourThres holdPerService

OriginatingCellColour ThresholdConfClass Class 3

mode

NeighbouringRNC Class 3

targetCellColourThreshold

FDDCell Class 3

userServiceSigToTrafficOnly Enable

FddIntelligentMultiCar rierTrafficAllocation Class 3

is3GHandoverPreferred

FDDCell / NeighbouringRNC Class 3

isGsmIratHoToNextBestCell Allowed isChangeGsmIratHoCriterio nAllowed

RadioAccessService Class 3 RadioAccessService Class 3

isImctaLoadBasedAllowed [USA Market] imctaLoadBasedTargetCell ColorThreshold [USA Market]

RadioAccessService Class 3 UmtsNeighbouringRel ation UmtsNeighbouringInte lligent-

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 142/244

UMTS Radio Mobility
MultiCarrierTrafficAll ocation Class 3 RadioAccessService Class 3 yellow, all relevant target cell colors must be green or yellow. Enables the target FDD carrier filtering based on cells load. A candidate target FDD layer shall be discarded and no measurements shall be activated by iMCTA if none of the candidate neighbour cells on that layer fulfil the cell load criteria. It applies when iMCTA reason is service, but may also apply to iMCTA CAC and Alarm when 34437 load criterion is used. TRUE: Enables the target FDD carrier filtering (this flag is used to control R5 of feature 34437) FALSE: Disables the target FDD carrier filtering Enables the cell load filtering criteria when iMCTA reason is Alarm. As a pre-condition parameter isImctaLoadBasedAllowed must be enabled. The value of parameter isImctaLoadBasedAlarmAllowed is derived from the primary cell if the primary cell is on SRNC. If the primary cell is on DRNC then the value FALSE is assumed.

isImctaFddLayerLoadPreCh eckAllowed

isImctaLoadBasedAlarmAllo wed

FDDCell Class 3

4.20.4.1.1

SERVICE SEGMENTATION OPTION DEFINITION

This option applies only for iMCTA Services triggers (users and mobility). It is meant to allow the operator to define a preference between service segmentation and load balancing. For a given call, if the option is activated via the IsServiceSegmentationTopPriority flag, then the following modifications to the current iMCTA algorithm apply: - The Load of the originating cell is not anymore taken into account to trigger the iMCTA algorithm in the case the UE capability and primary cell HSxPA capability do not match i.e. o UE is “HSDPA capable” and Primary cell is “not HSDPA capable” o UE is “HSUPA capable” and Primary cell is “not HSUPA capable” o UE is “not HSDPA/HSUPA capable” and primary cell is “HSDPA capable” or “HSUPA capable” - When processing the measurement reports in order to select a target cell: o the load of the target cell is only checked with respect to the target cell colour threshold and not with respect to originating cell colour o the target cell can only be selected if the UE/cell capability compatibility is partial or full. The definition of UE/cell capability compatibility is: partial= UE is HSUPA and cell is HSDPA only full=(UE is R99 and cell is R99) OR (UE is HSDPA and cell is HSDPA or HSUPA) OR (UE is HSUPA and cell is HSUPA) false=(UE is R99 and cell is HSDPA or HSUPA) OR (UE is HSDPA or HSUPA and cell is R99) cell HSDPA or HSUPA is based on O&M cell provisioing. − On measurement report after removing target cells using the criteria above plus radio and HSxPA criteria: o If originating and target cell have the same priority o If target cell load criteria is fulfilled o If target cell load is equal or lower than originating cell load o If UE and originating cell don't have full compatibility the target cell is candidate. Otherwise it is discarded.

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 143/244

UMTS Radio Mobility
4.20.4.1.2 SERVICE HANDOVER OPTION DEFINITION

This option applies whatever the iMCTA trigger and is based on the Service Handover IE carried in the RANAP Rab Assignment and Relocation Request messages. [A1] gives the definition of this IE. This option applies to the GSM Carrier. Its priority coming from the iMCTA selected table may be updated according to the Service Handover IE value and the O&M Service Handover option value. If “Service Handover” option is enabled, and this information element is received from the Core network in the RAB assignment request, the following rules shall apply: IF at least one Rab has a Service Handover IE indicates “Shall not”, the algorithm shall act as if the Priority was set to PNA (not applicable) regarding the GSM carrier for all priority tables. ELSE IF at least one Rab has a Service Handover IE which indicates “Should not”, the algorithm shall act as if the Priority was set to P8 (lowest) regarding the GSM carrier for the Service priority table; ELSE IF at least one Rab has a Service Handover IE which indicates “Should”, the algorithm shall act as if the Priority was set to P0 (highest) regarding the GSM carrier for all priority tables. However, the MSC, that sets the Service Handover IE, does not know if the UE has a simultaneous PS call. If the strategy is to keep simultaneous CS+PS calls in UMTS then the parameter isChangeGsmIratHoCriterionAllowed can be set to TRUE. In this case the RNC internally changes the received Service Handover IE from “Should” to “Should not” if the UE has a simultaneous active PS call. The Service handover IE values depend on User subscription. P0 and P8 are RNC internal priority values which are not available at OMC-R level. It allows giving the highest /lowest priority for GSM carrier. The priority rule is the following: P0>P1>P2>P3>P4>P5>P6>P7>P8

4.20.4.1.3

HSDPA TRAFFIC SEGMENTATION OPTION DEFINITION

This option only applies for iMCTA Services triggers and doesn't apply in case of Alarm HHO and CAC failures triggers. The priority tables give a Traffic Allocation strategy at Carrier level. When the Carrier has cells with different capabilities, this option may limit the mobility towards a carrier if the eligible target cell has not the required capability. When this option is set and whatever the established traffic service the RNC has to apply the following requirements when it processes the target cell selection during iMCTA algorithm: shall not try to allocate non-HSDPA/HSUPA capable mobiles (R99) on a cell supporting HSDPA/HSUPA ; shall not try to allocate HSDPA/HSUPA capable mobiles on a cell not supporting HSDPA/HSUPA

4.20.4.2
Name

IMCTA PRIORITY TABLES
Object/Class
RadioAccessService Class3

Definition
This table gives for 2G access and 3G Fdd carrier a priority value per service type. This table is used when an iMCTA Alarm trigger is processed. This table gives for 2G access and 3G Fdd carries 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).

AlarmPriorityTableConfClass

CacPriorityTableConfClass

RadioAccessService Class3

ServicePriorityGeneralTableConfClass

RadioAccessService Class3

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 144/244

4.2.4 iMCTA Service Type Definition. Pointer towards one instance of the ServicePriorityTableForHsupaConfClass tables. CAC and Service). Pointer towards one instance of the CacPriorityTableConfClass tables. This instance was created for upgrade from UA06 to UA07 (for all iMCTA table types) with the introduction of the feature iMCTA Load Based HO developments. the iMCTA Alarm and CAC priority tables have the same format as the iMCTA service priority table. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Pointer towards one instance of the CacPriorityTableConfClass tables. Pointer towards one instance of the ServicePriorityGeneralTableConfClass tables. Pointer towards one instance of the ServicePriorityTableForHsdpaConfClass tables. 4.4. The operator may give different Carrier priorities according to the iMCTA trigger (Alarm.1 IMCTA PRIORITY TABLE DEFINITION: GENERAL ASPECTS When iMCTA is invoked by one of the triggers. This table gives for each Fdd and 2G carriers a priority value per service type. This table gives for each Service if the Service Segmentation has a higher priority than load balancing Pointer towards one instance of the AlarmPriorityTableConfClass tables. It allows: • A better control of the mobility.UMTS Radio Mobility ServicePriorityTableForHsdpaConfClass RadioAccessService Class 3 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.2. Passing on or copying of this document. The priorities per carrier and per service type are defined via O&M. The RNC has to apply the following behavior when selecting candidate target layer(s) for HHO: when the frequency of a neighbour cell is not present in the Alarm or CAC tables. Pointer towards one instance of the AlarmPriorityTableConfClass tables. the priority of each service has to be read from the instance “OtherFDD” of the MO frequency. iMCTA priority table Service type 2 …… FDD1 FDD2 FDD3 FDD4 FDD5 FDD6 2G OtherFDD Service type 1 Pi Pj Pk Pl Pm Pn Po Pp Service type n The list of services is given below in § 4.20. • limiting the number of Fdd Carriers to be measured by the UE: it reduces the UE measurements delay and avoids asking measurements on more than 2 neighboring FDD carriers (3GPP doesn’t require a UE to measure more than to 2 neighboring FDD carriers).06/EN Approved_Standard 17/Sep/2010 Page 145/244 .20. the function has first to select the candidate target Carriers taken into account the UE capabilities and the priority of the different carriers for the request service type. The instance “OtherFDD” is used as default value. This parameter is a pointer to one of the five ServiceSegmentationPriorityClass instances ServicePriorityTableForHsupaConfClass RadioAccessService Class 3 ServiceSegmentationPriorityClass alarmPriorityTableConfClassId cacPriorityTableConfClassId servicePriorityGeneralTableConfClassId servicePriorityTableForHsdpaConfClassId servicePriorityTableForHsupaConfClassId alarmPriorityTableConfClassId cacPriorityTableConfClassId serviceSegmentationPriorityTableRef RadioAccessService Class3 FDDCell Class 3 FDDCell Class 3 FDDCell Class 3 FDDCell Class 3 FDDCell Class 3 NeighbouringRNC Class 3 NeighbouringRNC Class 3 FDDCell (iMCTA) Class3 [UA06-UA07 difference]: With the feature iMCTA load based HO developments. This table is used when an iMCTA service trigger is processed for a HSUPA capable mobile.

For each Service type. FDD carriers priorities could be the same in order to allow load balancing between FDD layers. The operator can configure a specific Service table per UE type: iMCTA HSUPA table (optional table). the table has to be used when the mobile is HSDPA capable. The list of Service types is: Passing on or copying of this document.4. Since UA07.20. P8). It has also to be used in the following cases: o When the mobile is HSDPA capable and the iMCTA HSDPA is not present. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. If present. the carrier shall not be considered for the request service type.3 IMCTA SERVICE PRIORITY TABLE DEFINITION The table allows setting the layer preferences between all 3G layers and the 2G layer when a HHO has to be processed for Service reason. priority value) in Priority tables. with same priority then the neighbours of both systems are measured and handover is executed to the cell reported first by the UE (typically 3G cells because the measurement is much faster than for 2G that requires BSIC verification) and eligible to iMCTA target cell criteria. If the priority is set to PNA (Priority Not Applicable). P1…P7 with P1>P2>…. it is possible to have the PNA value for all layers (FDD and 2G). after applying the different filtering. If present. o When the mobile is HSUPA capable and the iMCTA HSDPA and HSUPA table are not present. allows the priority setting of each FDD frequency (as for iMCTA service priority table). It also my used if the mobile release is HSUPA capable and the iMCTA HSUPA table is not present.4. FDD carriers priorities could be the same in order to allow load balancing between FDD layers. two Radio Access System are selected (Priority <>PNA). the table has to be used when the mobile release is HSUPA capable. P1…P8 with P1>P2>…>P8. The tables allow setting the target Radio Access technology preference between 3G and 2G when a HHO has to be processed for Alarm and CAC reasons. 4. For each Service type. Whatever the result of the procedure which triggers the iMCTA.e.2. 4. they have the same format. The goal is to establish all requested RAB on a better carrier. it is possible to have the PNA value for all Access. The table has to be used for non HSDPA/HSUPA capable mobiles. iMCTA HSDPA table (optional table). For each service type the 2G carrier priority can be equal or different to the FDD carrier priorities. a Fdd frequency or a set of Fdd frequencies or the 2G Radio Access System shall not be considered for the request service type. The different priority values are: PNA.20.4 IMCTA SERVICE TYPE DEFINITION The Service Type is an input to access information (i.0.4.UMTS Radio Mobility 4. iMCTA General table (mandatory table). If the priority is set to PNA. The table only applies to a call with a primary link located on the C-RNC. If. the RNC has to replace the priority value with the lowest priority value (i.e.2 IMCTA ALARM AND CAC PRIORITY TABLES DEFINITION There is one table for Alarm and another one for CAC.06/EN Approved_Standard 17/Sep/2010 Page 146/244 .2. If the originating cell belongs to a Carrier described in the Service priority table with a priority value equal to PNA for the given service type and mobile type.20. The table applies to all mobiles types (HSDPA/HSUPA capable or not) with a primary link located on the CRNC or a D-RNC.2. The different priority values are: PNA.P7. the service type is read by the RNC in its configuration parameters (DlUserService MO) based on the RABs requested by the CN which may be established or not.

HSDPA call stand for a call where there is at least one traffic radio-bearer mapped on HS-DSCH in DL without traffic or signaling radio bearer on E-DCH in UL. Full details are available in § [R4] UMT/SYS/DD/013319 HSDPA System Specification and [R6] UMT/SYS/DD/018827 E-DCH System Specification. a ImctaServiceTypeId is set which allows to access the iMCTA priority tables. independently of the load of the primary cell.20. or PS+PS.UMTS Radio Mobility CS Speech CS Conversational (64/64) CS Streaming PS Streaming PS Interactive/Background CS speech + other service (PS.4. 4. Passing on or copying of this document. The rule is: conversational/speech > streaming > I/B Example: CS 64/64 + PS I/B shall be handled as CS 64/64 which is mapped onto CS conversational service. In the following sections. The operator has not to modify the list without Alcatel-Lucent agreement. HSDPA AND HSUPA MOBILITY This section provides a high level view of the interactions between HSDPA or HSUPA and mobility.4.2. 4.20.. HSUPA call stands for a call where there is at least one radio-bearer mapped on E-DCH in UL (so necessarily mapped on HS-DSCH in DL). use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.5 IMCTA SERVICE SEGMENTATION PRIORITY TABLE DEFINITION This table allows the operator to define per service if service segmentation has a higher priority than load balancing.20. The “none” value is used to set some User Service (signaling…) ineligible to iMCTA.5 PERFORMANCE MANAGEMENT The document [R9] gives the description of the counters. The list of Services is the same as in Service type. The goal is to redirect the call on a cell with a better matching capability when the HSxPA capability of the originating cell and the UE capability do not match. The “highest RB” will be the input to map the Service type. 4.2.) none Multiple service Radio Bearers and Multiple PS Radio Bearers are mapped onto a Service Type according to the following static rule which gives the priority between RB.. Name serviceType Object/Class DlUserService Class 3 Definition For each DlUserService Instance. 4.21.6 IMCTA SERVICE FOR TRAFFIC SEGMENTATION PRIORITY DEFINITION This ServiceForTrafficSegmentationPriority is an input to access information (activation of service segmentation option per service) in Service Segmentation priority tables.06/EN Approved_Standard 17/Sep/2010 Page 147/244 .

The drawback of this scenario is that HSUPA traffic may impact R99 Uplink traffic by generating interferences.21.3). Passing on or copying of this document. If HSDPA (resp.1 HSPDA ON DEDICATED LAYER Different scenarios can be deployed for multi-layers networks: • HSDPA is not deployed everywhere (HSDPA can only be deployed on one frequency). see above). E-DCH) is performed when the UE enters in or leaves an HSDPA (resp.21. HSUPA) is not deployed everywhere in the layer then an automatic channel type switching between DCH and HS-DSCH (resp. it is necessary that HSDPA is also configured in this cell. Layer with HSDPA configured Layer without HSDPA • 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 has already been deployed.21.21.1.2 Even though deploying HSDPA and HSUPA on a separate layer is the preferred option. HSDPA may be deployed in a cell without deploying HSUPA.UMTS Radio Mobility 4.1.1. When all layers support HSDPA and/or HSUPA. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.1 4. one of them may be tagged as “layerPreferredForR99” by configuration. 4. Note: to deploy HSUPA in a cell.1. HSDPA ON EXISTING LAYER 4. This is because any radio-bearer mapped on E-DCH in uplink will necessary be mapped on HS-DSCH in downlink. This HSDPA layer may be deployed either widely or restricted to some hot-spots and is able to manage both R99 and HSDPA/HSUPA UEs.1. Full details are available in [R4] and [R6].06/EN Approved_Standard 17/Sep/2010 Page 148/244 . there is nothing that mandates to do so and HSDPA and HSUPA can be configured on any cell (knowing that HSUPA cannot be activated without HSDPA in the cell. HSUPA) cell (more information are provided in paragraph 4. However.21.1.1 DESCRIPTION DEPLOYMENT SCENARIOS Different deployment scenarios are foreseen for the introduction of HSDPA/HSUPA on existing networks: HSPDA/HSUPA on a dedicated layer or on an existing layer.

19). there is only one serving E-DCH radio-link and it is established in the same cell that the HS-DSCH radio-link. On the opposite. it is reconfigured to E-DCH if the mobile comes back to HSUPA coverage. In case of primary cell change. the HS-DSCH RL is deleted on the former primary and re-established under the new primary.1). Mobility of R99 calls – even in an HSDPA or HSUPA cell – is handled as described in the other sections. Note: in following paragraphs.1.4.3.7).3.21. In Alcatel-Lucent implementation. 4. Mobility of HS-DSCH As specified by the 3GPP standards. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.1. each one described in a specific section: • either at RRC connection establishment (refer to § 4.1.21.06/EN Approved_Standard 17/Sep/2010 Page 149/244 . Each time the primary cell changes. the E-DCH serving link and the HS-DSCH link are moved at the same time (one procedure).2 REDIRECTION AT CONNECTION SETUP Traffic segmentation (HSDPA vs R99) can be ensured by different means. HS-DSCH is established on the primary cell (good radio conditions and not changing too often).1 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. If the new primary cell does not support HSDPA then the RB is reconfigured to DCH.18. 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). • or at RAB assignment (iMCTA feature. based on the HSDPA/HSUPA capability of the mobile and on traffic class of the RAB. PS RABs means: • PS I/B RABs (for HSxPA) • PS streaming RABs (for HSDPA only. 4. The mobility of the E-DCH serving link is based on the same principals than the HS-DSCH one.0 release.3 and 5. HS-DSCH is established in only one cell so is never in soft handover.19). Mobility of E-DCH As specified by the 3GPP standards. 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). • or on other iMCTA trigger (refer to § 4. possibly in parallel with other DCH radio bearers) and HSUPA calls (at least on E-DCH radio-bearer). if streaming on HSDPA feature activated) It does not include Conversational RABs. Passing on or copying of this document.3 HSDPA AND HSUPA CALL MOBILITY PROCEDURES This section is only applicable to HSDPA calls (mobile having at least one HS-DSCH radio-bearer. macro-diversity of E-DCH (having non-serving E-DCH radio-links) is supported by Alcatel-Lucent (refer to § 5.21. From UA06. using a synchronized radio link reconfiguration. § 4.UMTS Radio Mobility 4.

1.e. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.A SRNS relocation (“UE not involved”) may be triggered for an HSxPA call on the Iur as for a R99 call. If the CAC also fails for the fallback.] If E-DCH support over Iur is disabled on DRNC: In case an Alcatel-Lucent RNC receives a RNSAP RL Setup or Addition or Reconfiguration with an E-DCH radio-bearer from the Iur then the procedure is refused. • intra-RNC handover within the SRNC or • inter RNC handover towards the SRNC. i.3. In case of the target cell being controlled by the SRNC. And this may trigger either an intra-RNC handover (with or without Iur) or an inter-RNC handover (over Iur or with relocation procedure).3 INTER-FREQUENCY MOBILITY Inter-frequency handover is supported for HSDPA calls and HSUPA calls as for any R99 call.e. [Global Market: If E-DCH support over Iur is enabled on DRNC then no restrictions apply to the incoming EDCH mobility. the Mac-e scheduler will also take into account compressed mode gaps. the E-DCH radio-bearers is reconfigured to DCH in UL. In case of CAC failure on E-DCH or HS-DSCH. If the CAC also fails for the fallback. [Global Market: If E-DCH support over Iur is enabled on SRNC then no restrictions apply to mobility over Iur.06/EN Approved_Standard 17/Sep/2010 Page 150/244 . then the relocation is refused. and whatever the container content. In case of HS-DSCH CAC failure. When the mobile comes back under the serving RNC and the primary cell supports HSUPA. the RNC policy is the following: • If the HSDPA capability of the UE is given in the RRC transparent container then the RNC will try to map directly PS RABs onto HS-DSCH. it is reconfigured (or kept) to DCH in downlink (resp.3. Otherwise a DCH resource is chosen.21. the CRNC performs a UE capability enquiry procedure and may reconfigure the PS radio-bearers to HS-DSCH (resp. [Global Market: E-DCH is managed over Iur since UA06 (refer to [R6])]. E-DCH) if not already done.] [Global Market . the radio bearer is reconfigured to E-DCH in UL otherwise it remains in DCH. the PS RB will be kept (or established) on HS-DSCH (resp. the RNC will perform a DCH fallback as for a RAB assignment (see [R6]). 4. For an HSDPA call. EDCH).21. For an HSUPA call. Passing on or copying of this document.1. It will also not be scheduled if the answer (Ack/Nack) falls during a gap for the same reasons.] When the Serving RNC triggers a relocation (“UE involved”). • If the E-DCH capability of the UE is given in the RRC transparent container then the RNC will try to map directly PS RABs onto E-DCH/HS-DSCH.UMTS Radio Mobility Mobility over Iur HS-DSCH is managed over Iur.2 COMPRESSED MODE Compressed Mode will be activated in Uplink and Downlink to perform inter-frequency and inter-RAT measurements if needed by the UE. uplink) In case of the target cell being controlled by a DRNC. E-DCH) if the target cell supports HSDPA (resp. the RNC will perform a DCH fallback as for a RAB assignment (refer to [R4]). then the relocation is refused. 4. i. After SRNS relocation. If it is not the case. The handover protocol to be performed and possible HSxPA to DCH and DCH to HSxPA reconfigurations depend on the allocation of the target cell. If E-DCH support over Iur is disabled on SRNC: When the mobile moves so that the primary cell moves under the control of a drift RNC. 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.

HSUPA) and the source RNC has indicated that the UE supports HSDPA in the Rel’5 extensions (resp. IFHHO with SRNS Relocation (HSxPA or DCH) Yes Target cell on DRNC and Reloc.UMTS Radio Mobility • intra-RNC handover within a DRNC or • inter-RNC handover towards a DRNC the inter-frequency handover may be performed over Iur or with relocation procedure depending on either or both features being enabled as depicted in figure below. Inter-frequency handover over Iur will be done with preference if enabled towards the DRNC to control the target cell (refer to §4. IFHHO HSxPA / DCH Handover Yes SRNC Target cell on SRNC ? No DRNC Yes Call on DCH ? Yes DCH Yes HSxPA No HSxPA Target cell on SRNC and HSxPA ? No (on DRNC or does not support HSxPA) HSxPA to DCH Reconfiguration Enabled over Iur ? No IFHHO Procedure (HSxPA or DCH) Yes DCH successful ? No HSxPA successful ? Yes No old freq. Passing on or copying of this document. E-DCH in uplink). HSUPA in Rel’6 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. DCH in uplink).06/EN Approved_Standard 17/Sep/2010 Page 151/244 . this triggers a relocation. If it happens that the UE is HSDPA (resp. A UE capability enquiry is then triggered. If the target cell supports HSDPA (resp. If no information about the HSDPA (resp. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 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. E-DCH in uplink if the primary cell is HSUPA). If performed over Iur then only DCH to DCH handover is supported and HSxPA calls need to be reconfigured to DCH before the handover.enabled ? No Call on new frequency Yes successful ? No Call on old frequency In case of inter frequency handover over Iur being disabled or being unsuccessful with return to old frequency. HSUPA) capable then the PB radio-bearers are reconfigured to HS-DSCH in downlink if the primary cell is HSDPA (resp.16 for Inter-frequency handover over Iur). 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.

leading possibly to the allocation of HS-DSCH (resp. this is seen as a new Mobile Originated PS call from the target RNC (No incoming relocation as the mobile was in GSM/GPRS).21. See [R6]. Mobility parameters can be tuned by mobility service type. ACCESS NETWORK IMPACTS 4. The same rules as the initial admission apply.1.6 See [R4].3 See [R4].21.21. In case of a pure PS call. See [R6]. The handover is triggered on the same conditions as for non-HSDPA calls (see section 4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.21.21. See [R6]. See [R6]. ALGORITHM 4.UMTS Radio Mobility 4.21.3. 2G to 3G handover 2G to 3G handover is supported. CORE NETWORK IMPACTS Passing on or copying of this document. See [R6].19).4 INTER-SYSTEM MOBILITY 3G to 2G handover 3G to 2G handover is supported for HSDPA/HSUPA calls.2 See [R4].4 PARAMETERS See [R4]. 4.06/EN Approved_Standard 17/Sep/2010 Page 152/244 . E-DCH) to the incoming UE.5 See [R4]. 4. APPLICABILITY 4.

the RNC shall select the appropriate one: the one on top of the list.22. the RNC shall assigned (assuming it knows the UE) a new URA to this UE.. allowing the RNC to move the UE to Cell_PCH RRC state. URA reselection process The RNC has to assign one URA identity to the UE when it moves the mobile to URA_PCH.06/EN Approved_Standard 17/Sep/2010 Page 153/244 .8). 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). MOBILITY IN CELL_PCH AND URA_PCH RRC STATES 4. UE URA UPDATE (u-rnti) UTRAN URA UPDATE CONFIRM (u-rnti . When the UE reselects a cell that does not belong to this URA (ie: this URA identity is not present in SIB2). This SIB only contains: the number of URA_identities (1. The RNC modifies this URA identity when an RRC Update occurs with the “change of URA” cause.22. Passing on or copying of this document.1 DESCRIPTION URA update URA update URA update Broadcast of URA identity The management of the URA_PCH needs the SIB2 broadcasting. new URA identity) Figure 64: Assigning a new URA If multiple URAs are defined in the current cell. the UE performs a URA update procedure with URA update cause ‘change of URA’. On reception of the URA update for URA reselection reason.UMTS Radio Mobility 4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the URA (UTRAN Registration Area) identity (ies) of the cell.

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. If this counter reaches a configurable threshold. Alcatel-Lucent RNC will not provide any information on URAs on the Iur (in RL Setup/Addition Response and in Uplink Signalling TransferIndication messages). short enough not to change to Idle mode) 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. If the u-rnti is not known by the RNC (because the RNC tried to contact the UE without success so released the RRC connection). Re-entered service area On reception of the Cell Update message. The same management as for Cell Fach through Iur applies to CELL_PCH and URA_PCH (refer to section 4.5). Note that the release is applicable anytime the RNC receives a message from an unknown u-RNTI. In case the cell is part of new LA/RA. the RNC shall resend the mobile to Cell_PCH.. the RNC increments the counter of number of Cell reselections. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Cell Update and URA update management The update procedures use the following messages: Cell reselection URA reselection Periodic Cell update Periodic URA update Re-entered service area Used in CELL_FACH or CELL_PCH when the UE re-selects a new cell Used in URA_PCH when the UE leaves the URA it was assigned to Used in CELL_FACH or CELL_PCH when T305 expires (periodic cell update timer) Used in URA_PCH when T305 expires (periodic URA update timer) Used in CELL_FACH or CELL_PCH or URA_PCH when the UE reenters service area and timers T307 or T317 or T316 are running (this means that the mobile could not find any suitable cell for a certain period of time. the reconfiguration fails then the RNC shall release the RRC connection (moves UE to Idle). Passing on or copying of this document. Periodic cell update On reception of the Cell Update message. the RNC updates the UE location and resends the mobile to Cell_PCH. Note: Alcatel-Lucent RNC will not support Paging Request over URA from the Iur and will ignore this message. then a LA/RA update is performed on Cell_FACH. In case the UE does not support the RRC state. the RRC procedure used to reconfigure the UE to this state will fail (eg: The RNC will receive a Radio Bearer Reconfiguration Failure message from the mobile). The operator has to take care of it.UMTS Radio Mobility IUR Management ASSUMPTION: IT IS NOT ALLOWED TO SPREAD A URA OVER TWO RNS. Else.06/EN Approved_Standard 17/Sep/2010 Page 154/244 . Cell reselection On reception of the Cell update message from a mobile in Cell_PCH state. If for any reason. based on the cause indicated by the UE in the message. It is used as supervision mechanism: the call is released in case of periodical update lack. There is no functional consequence to this because the interest of these states vs idle is only a faster resume time. the RNC shall send the mobile to URA_PCH (if the operator has activated URA_PCH). IOT Mobile restrictions It is possible that some UEs do not support URA or CELL PCH. the RNC shall send an RRC Connection Release message to the UE.

8]: (0. 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). The RNC doesn’t check if the cell is part of new LA/RA: no LA/RA update procedure is performed on Cell_FACH. “Unknown” u-RNTI In case the UE sends a Cell Update or URA update message with an unknown u-RNTI. The mobility configuration is made through the following parameter: Name URA identity [1. 4.5. If the u-RNTI belongs to this RNS. 4. If the list is not provided. Inter Frequency or Inter rat mobility management is the same as for CELL-FACH RRC state. Periodic URA update Nothing to do except resend the mobile to URA_PCH state keeping the same URA.. 4.5 ACCESS NETWORK IMPACTS Ability to broadcast the configuration parameter on the radio interface.3 ALGORITHM The cell selection/re-selection evaluation process (see [A5]) in Cell_PCH or URA_PCH RRC state for Intra Freq.22.UMTS Radio Mobility URA reselection On reception of the URA update message. Please refer to section § 4.22. the RNC shall act as for the first one received (but may assign a different URA if the cell reselected is different). Passing on or copying of this document.2 APPLICABILITY This feature is applicable when the call enters in Cell/URA PCH state. or If the current cell is not part of any URA. 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).. 4.4.22. the mobile shall be moved to Cell_PCH (if enabled) or idle (else). the RNC shall: If the u-RNTI belongs to another RNS. In this case.4 PARAMETERS The activation of using CELL/URA PCH RRC state is described in [R3]. Management of the Cell/URA update procedures. it shall send an RRC Connection Release message (directed signalling connection re-establishment cause): see [Iur management] in a previous paragraph. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the RNC shall send the mobile to Cell_PCH (given it is allowed on the network) or Idle (if Cell_PCH is not allowed). it shall send an RRC Connection Release to the UE.65535) 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 . It is used as supervision mechanism: the call is released in case of periodical update lack.22.06/EN Approved_Standard 17/Sep/2010 Page 155/244 .

Cell_Fach.UMTS Radio Mobility 4. 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.e. (see [A5]) Passing on or copying of this document.6 No impact. HCS: CELL RESELECTION CONTROL IN A HIERARCHICAL CELL STRUCTURE [GLOBAL MARKET] 4. For example fast moving terminals could be redirected to macro cell layer (i. capacity layer). In addition it allows a better radio plan management and handles the UTRAN resources with better efficiency improving the UTRAN capacity (i. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Note: HCS is not used by the UE for inter-RAT reselection if absolute priority based cell reselection is used for inter-RAT.23. 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.1 DESCRIPTION The Hierarchical Cell Structure feature enables the cell reselection control procedure in a Multi Layer network.06/EN Approved_Standard 17/Sep/2010 Page 156/244 . improving higher data rate services in small areas. It means the cell plan has several levels. CORE NETWORK IMPACTS 4. handling others services as in private systems.e. micro cells/capacity layer).23.22. rather low moving terminals to micro/pico cell layer (i.e. 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.4 and 4. and URA/Cell_PCH connected modes. macro cells/ mobility layer).5 but with additional algorithms handled by the HCS and applicable to the new concept of the UE fast moving also called high mobility. mobility layer). and so decrease the total system cost.e. This feature allows the operator to prioritize cell layers for mobiles in idle mode.

It may appear in particular radio conditions (UE at the edge of radio cells). As the traffic user demands on the network should vary in time and in space. • only UTRAN/FDD and GSM Radio Access Technologies are known and supported Passing on or copying of this document. large number of handoff between these cells may occur. local traffic peaks are likely to occur and so required micro cells are needed to complement the macro cells. 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. to trigger the high mobility detection even if it’s not a real fast moving UE case. It shall also offer to reduce negative radio effect when one fast moving UE is connected to a distant macro cell. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 4. Typically High mobility detection is useful in such cases. which is tuned to lower transmission terminals.23.06/EN Approved_Standard 17/Sep/2010 Page 157/244 . and shall avoid too much undesirable handoffs which can produce call drops. Now with fast UE. and enters a micro cell. then the unwanted radiation of the high power transmission UE may generate some interferences at the micro cell NodeB.UMTS Radio Mobility Macro cell Fk HCS priority level I Micro cells Fm HCS priority level J Pico cells Fn HCS priority level K HCS STRUCTURE PLAN 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.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".

Note: When HCS is not used the SsearchHCS applies also.…). o HCS_PRIOn: Defines the HCS priority level for neighbouring cells. When HCS is used SsearchHCS specifies the threshold for Srxlev below which Intra-frequency and interfrequency measurements of the neighbouring cell are performed. o HCS re-selection criterion and HCS thresholds as: Qhcs: Quality threshold level for applying hierarchical cell reselection. o 3GPP defined thresholds level (Qhyst1s . Qoffset1s. 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. UE measurement for intra/inter frequency used for high mobility state detection. o Cell Ranking criteria R. 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. UE measurement for inter RAT used for high mobility state detection.UMTS Radio Mobility The HCS algorithm is based on the classical principles of the re-selection algorithm of the UE in Idle/connected mode.4 ).n. The new specific parameters for HCS cell re-selection procedure are controlled by the RNC. o UE measurement for inter RAT. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. o UE measurement for intra/inter frequency. o Time reselection duration according to the corresponding UE state (URA/Cell PCH or CellFACH).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.23. and for SIB4/SIB12 in FACH or PCH mode if enabled. o o o High mobility detection (UE fast Moving). o o o HCS cell-reselection procedure is based on UE measurements and the measurements rules. The broadcasting of these new parameters implies coding/scheduling modification for SIB3/SIB11 broadcasted on the BCCH channel in idle mode.06/EN Approved_Standard 17/Sep/2010 Page 158/244 . in order to detect a high mobility state. Hs/ Hn: Quality threshold criterion for applying hierarchical cell reselection. The new concept of high mobility detection procedure could be applied to the HCS measurement rules if configured. 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. 4. Passing on or copying of this document. 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. From an algorithmic point of view the main differences with the classical reselection procedure are on the measurement rules and on the ranking algorithm.

4). o 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.3.Qhcss Hn = Qmeas.n . Constant value Time Offset If at least one measured neighbor cell verifies H ≥ 0 the criterion S applies according to the high mobility state: o If high mobility state is not active.n . The S criterion is described in the section 4.06/EN Approved_Standard 17/Sep/2010 Page 159/244 . The list may be a sub-list of all provisioned neighbour cells sent in the SIB11message. is defined as: Hs = Qmeas.n .n QHCS s . If high mobility state is active. The quality of the received signal expressed in CPICH Ec/N0 (dB) Quality threshold levels for applying HCS algorithmic.Qoffsets.UMTS Radio Mobility 4. involving a prioritized ranking to the candidate cells. Q meas.Qhcsn – TOn * Ln with: Q meas. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.23.s .1 CELL RESELECTION CRITERIA WHEN HCS IS USED If HCS is used in the serving cell. o If (HCS_PRIOn ≥ HCS_PRIOs).s + Qhysts Rn = Qmeas.s . 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. QHCS n Ln TOn Measured cell quality value. Step 2: The S and H criterion apply on the measured cells to identify cells candidates for the neighbour cells ranking criterion R.TOn * (1 – Ln) Passing on or copying of this document. 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). 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). the criterion S apply on measured cells with: o If (HCS_PRIOn < HCS_PRIOs).4. Step 3: The cell ranking with the cell ranking criterion R is applied by the following formula to the cells fulfilling the step 2 conditions: Rs = Qmeas. Cell re-selection criteria apply for intra/inter frequency and inter RAT cells. The quality threshold level criterion H for HCS. 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 ).

As explained in the section 4.n in order to increase the offset and so temporary disadvantage a neighbour cell for the Hn and Rn criterion: it allows avoiding pingpong effect.e. There is one Tn timer per neighbour measured cell. It bounds the temporary offset use.UMTS Radio Mobility The best ranking cell is the cell with the highest R value. Qmeas = quality value of the received signal HCS_PRIOs. TO n = TEMP_OFFSETn * W(PENALTY_TIMEn – Tn) Ln = 0 Ln = 1 Tn = Timer if HCS_PRIOn = HCS_PRIOs if HCS_PRIOn <> HCS_PRIOs . Time Offset (TO) applies in: Hn formula when Ln =1 (i. (use case: ping pong between cells of same priorities). TO n and Ln calculation Extract of [A5].06/EN Approved_Standard 17/Sep/2010 Page 160/244 . 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. HCS_PRIOn. 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. The condition for arming this timer depends on HCS_PRIOn and HCS_PRIOs parameter values: If (HCS_PRIOn <> HCS_PRIOs) the condition is based on the neighbour cell quality measurement without regarding the serving cell quality: If (HCS_PRIOn == HCS_PRIOs) the condition is based on the difference between quality measurements of the serving and the neighbour cell: the purpose is to keep the mobile on the actual layer except if the quality is “well better” on the neighbour layer. = HCS priority level of the cell.4 the ranking is based on CPICH RSCP quality and a second ranking may occur when quality measurement is Ec/No.e. HCS_PRIOn <> HCS_PRIOs ) Rn formula when Ln =0 (i. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. T n timer definition Extract of [A5]. The selected cell has to fulfill the Access restriction rules see [A5]. HCS_PRIOn = HCS_PRIOs) Time Offset parameter applies a temporary offset value which is added to the offset Qoffsets.W(x) = 0 for x < 0 . Passing on or copying of this document. The change of the serving cell doesn’t imply a timer stopping. The Tn timer is stopped when the condition is no longer fulfilled.W(x) = 1 for x >= 0 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).

UE shall: Continue these measurement during TCrmaxHyst.4 4.1 PARAMETERS AT UTRAN/FDD CELL LEVEL The “isHscUsed” parameter allows the activation/deactivation of the HCS procedure. When the number of cell reselection during time period TCrmaxHyst no longer exceeds NCR. If the criteria for entering high mobility is not detected during time period TCrmaxHyst: Exit high-mobility.n = Qoffset2s. If quality measurement used is CPICH RSCP. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. high-mobility has been detected. The “tCrMax” allows the activation/deactivation of the High mobility detection.n = Qoffset1s. Else Stop timer Tn. 4.23.4.n. Passing on or copying of this document.06/EN Approved_Standard 17/Sep/2010 Page 161/244 . Fdd Cell: If quality measurement used is CPICH Ec/No.2 INTER RNC CASE In this version full HCS is applicable for intra RNC case only.3. The high mobility detection may be used if HCS is not used (see section 4. . The high mobility state doesn’t mean the mobile speed is high but the number of reselection is high.s + Qoffsets.If (HCS_PRIOn <> HCS_PRIOs) && (Qmeas. Qoffsets.UMTS Radio Mobility .n) Start Tn.4) 4. Qoffsets.n .23. 2G Cell: Qoffsets.n = Qoffset1s. High mobility detection (if HCS is used) Extract of [A5].n.If (HCS_PRIOn == HCS_PRIOs) && (Qmeas.n > Qmeas. If the number of cell reselections during period TCRmax exceeds NCR.23.n >= Qhcsn) Start Tn.

This specifies the scaling (multiplication) factor to be used by the UE for scaling the parameters Treselections or Treselections.. Integer (0.1 by step of 0.FACH for the inter-frequency case. Real (1. 30. This specifies the scaling (multiplication) factor to be used by the UE for scaling the parameters Treselections or Treselections..25).FACH in case high-mobility state has been detected. Integer (-105. This specifies the quality threshold levels for applying prioritised hierarchical cell re-selection Integer (-32.25). Integer (-105. It specifies the RAT specific threshold (in dB) in the serving UTRA cell above which the UE may choose to not perform any inter-RAT measurements in RAT "m". When HCS is used. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.FACH for the inter-RAT case.75 by step of 0.06/EN Approved_Standard 17/Sep/2010 Page 162/244 . Integer( 0.PCH or Treselections. This specifies the additional time period before the UE can exit high-mobility. 60.7).16). 3 4 sSearchHcs 3 4 sHcsRatGsm 3 4 CellSelectionInfo CellSelectionInfoCo nnectedMode 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 interFreqScalingFactorT Reselection interRatScalingFactorTR eselection tCrMax 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. 60. This specifies the maximum number of cell reselections. This threshold is used in the measurement rules for cell re-selection when HCS is used. 40.75 by step of 0. Enumerated (not used.1). When HCS is not used. 180.91 by step of 2)..20 by step of 2) In [dB].99). This parameter is mapped to non-TCrmaxHyst or TCrmaxHyst IE for SIB3/4 filling depending of HCS use or not.. 70). Real (1. Integer (1. When HCS is not used. This specifies the 2G RAT specific threshold in the serving cell used in the inter-RAT measurement rules. Enumerated (not used. 50. 30.4.. it specifies the limit for Srxlev in the serving cell below which the UE ranks interfrequency neighbouring cells of the serving cell. it specifies the 2G RAT specific threshold in the serving cell used in the inter-RAT measurement rules.UMTS Radio Mobility OAM parameter isHcsUsed sSearchRatGsm SIB Object FDDCell CellSelectionInfo CellSelectionInfoCo nnectedMode CellSelectionInfo CellSelectionInfoCo nnectedMode description/comment This parameter indicates whether HCS is used in the Fdd cell Integer (-32.91 by step of 2). This threshold is used in the measurement rules for cell re-selection. This parameter is mapped to non-TCRmax or TCRmax IE for SIB3/4 filling depending of HCS use or not.. This specifies the scaling (multiplication) factor to be used by the UE in idle mode or RRC connected mode states for the parameters Treselections or Treselections. it specifies the limit for Srxlev in the serving cell below which the UE shall initiate measurements of all neighbouring cells of the serving cell. 20... This specifies the duration for evaluating allowed amount of cell reselection(s).. HCS priority level 0 means lowest priority and HCS priority level 7 means highest priority.20 by step of 2). When HCS is used. 10. it specifies the limit for Srxlev in the serving cell below which the UE ranks inter-RAT neighbouring cells of the serving cell. Real (0. 240).4. This threshold is used in the measurement rules for cell re-selection. This specifies the HCS priority level (0-7) for serving cell .PCH or Treselections..PCH or Treselections. This parameter is mapped to non-NCR or NCR IE for SIB3 filling depending of HCS use or not. 120.

Support of radio parameters setting with high accuracy. Integer(3. 20.3 AT GSM NEIGHBOURING CELL LEVEL SIB 11 12 Object GsmNeighbouringCell GsmCellSelectionInfoC onnMode GsmNeighbouringCell GsmCellSelectionInfoC onnMode GsmNeighbouringCell GsmCellSelectionInfoC onnMode GsmNeighbouringCell GsmCellSelectionInfoC onnMode description/comment Integer (0. It is used for FDD cells in case the quality measure for cell selection and reselection is set to CPICH Ec/No. This specifies the offset applied to the H and R criteria for a neighbouring cell for the duration of PENALTY_TIMEn.2 AT UTRAN/FDD NEIGHBOURING CELL LEVEL SIB 11 12 Object UmtsNeighbouringRelation FddNeighCellSelectionInfoCon nectedMode UmtsNeighbouringRelation FddNeighCellSelectionInfoCon nectedMode UmtsNeighbouringRelation FddNeighCellSelectionInfoCon nectedMode UmtsNeighbouringRelation FddNeighCellSelectionInfoCon nectedMode description/comment Integer (0. 6. 15.6 No impact. 12. This specifies the time duration for which the TEMPORARY_OFFSETn is applied for a neighbouring cell. 6. 15.23.23. This specifies the offset applied to the H and R criteria for a neighbouring cell for the duration of PENALTY_TIMEn.. Integer(2.UMTS Radio Mobility 4. OAM parameter hcsPrio qHcs 11 12 11 12 penaltyTime temporaryOffset1 11 12 temporaryOffset2 11 12 UmtsNeighbouringRelation FddNeighCellSelectionInfoCon nectedMode 4. 21. 60) in sec.99).4. 60) in sec. 9. Integer (3. This specifies the time duration for which the TEMPORARY_OFFSETn is applied for a neighbouring cell. This specifies the HCS priority level (0-7) for the neighbouring cells. 8. OAM parameter hcsPrio qHcs 11 12 11 12 11 12 penaltyTime temporaryOffset1 4. 6.. This specifies the quality threshold levels for applying prioritised hierarchical cell re-selection. This specifies the offset applied to the H and R criteria for a neighbouring cell for the duration of PENALTY_TIMEn. HCS priority level 0 means lowest priority and HCS priority level 7 means highest priority. Support of mobility detection for better efficiency even if not mandatory for HCS processing.. This specifies the HCS priority level (0-7) for the neighbouring cells. 50. HCS priority level 0 means lowest priority and HCS priority level 7 means highest priority. CORE NETWORK IMPACTS Passing on or copying of this document. 30. 12.06/EN Approved_Standard 17/Sep/2010 Page 163/244 . 18. Integer( 0. 10. 12. 4. inf) in dB. 20. 18. 10. 21. 4.5 • • • • ACCESS NETWORK IMPACTS Support of the corresponding system information transmission. 30. Integer(0. It is used in case the quality measure for cell selection and re-selection is set to CPICH RSCP. 3.23.23. ). Support of a hierarchical radio plan. 50. Integer( 0..7). 40. This specifies the quality threshold levels for applying prioritised hierarchical cell re-selection. 10.4.7). 9. Integer(0. inf) in dB. It is used for GSM cells in case the quality measure for cell selection and re-selection is set to CPICH RSCP.99). use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. inf)in dB. 40.

g.9) • inter-frequency blind handover (refer to § 5.06/EN Approved_Standard 17/Sep/2010 Page 164/244 .1. 1E. while event 1B involves a RL deletion.g. The main reason for is about “Time To Trigger”. 3. 4. 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. event 1A reception leads to radio link addition. e.4) • active set management (refer to § 5. 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. 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. 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.1 Another reporting mode is the intra-frequency event triggered reporting mode. 5. INTRA-FREQUENCY EVENT TRIGGERED MEASUREMENT REPORTING MODE DESCRIPTION 5. 5.g.2.3) • Radio Link colour determination (refer to § 5. alarm handover criteria evaluation (inter-system. Making a decision at the RNC side until Time To Trigger has elapsed at the UE side may lead to unstable situations (ping-pong …). If not specified otherwise. 1C. 1D. COMMON PROCEDURES PERIODIC MEASUREMENT REPORTING MODE One possible reporting mode is the periodic reporting mode. 1B. 1. or inter-system measurements…) This reporting mode for intra-frequency measurements is not recommended in this version (but is still available for trace purpose or state transitioning enhancement). This is the ALU UTRAN nominal mode for all features except call trace function. measured results reported in event 1A shall not lead to RL deletion in the current active set. The use of “event triggered” reporting has a direct impact on the following mechanisms: • primary cell determination (refer to § 5.UMTS Radio Mobility 5.2. The basic principle of event handling is that the event semantic is taken into account in the implementation.2.3) The target cell choice for alarm handover is not impacted by the event triggered reporting mode. “Measured results” reported by the UE on other cells than the one having triggered the event are not used in mobility handling algorithms e. 1F. 2. each 500 msec). use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2.3) • alarm measurement criteria (refer to § 5.

2D and 2F are categorized in the ‘inter-frequency” event group.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 event-triggered mode is FULL-EVENT at the RNC level.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. If the call is setup on CELL_FACH or if an Always-On takes place. During all the life of a call. the events are configured once the RB is setup or reconfigured in CELL_DCH state. • Also configure events (1E and 1F) if the feature SHO enhancement (release UA04.UMTS Radio Mobility Note: Although being related to intra-frequency measurements. all SHO related events are configured. According to [R3] • Event 1A may be configured in SIB11 Passing on or copying of this document. plus events required for Alarm Measurement criteria. 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 Also configure events (6A and 6B) if the feature “Alarm HHO based on UE Tx Power” is enabled and the call uses DCH transport for uplink 6A 6B The UE Tx Power becomes larger than an absolute threshold The UE Tx Power becomes less than an absolute threshold (1) Measurement result is Ec/N0 (2) Measurement results are Ec/N0 and RSCP 5. If the call is setup on CELL_DCH. there is no mechanism to switch the mode during this phase of the call in CELL_DCH. the RNC chooses this measurement reporting mode after the transition to CELL_DCH. the events are configured once the Signalling Radio Bearer is setup. If event-triggered is configured in the cell where the UE transits to CELL_DCH. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. If the event-triggered reporting is configured. And when the mode “Full-Event” is selected at the establishment in CELL_DCH. 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). • • Also configure. 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).2.06/EN Approved_Standard 17/Sep/2010 Page 165/244 . which helps to decrease the number of simultaneous intra-frequency events required. when the alarm condition is fulfilled.

5. An update of the monitored set cells (intra-frequency and/or inter-frequency and/or inter-RAT) may be required.2. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the event is not configured again.06/EN Approved_Standard 17/Sep/2010 Page 166/244 . i. • If the UE is Release 5 o if the failure is due to a configuration of inter-frequency/inter-RAT alarm measurements then the RNC takes no action. From that perspective. as in call setup case. if all parameters related to a specific event are unchanged. the UE shall be able to support in parallel per category up to Ecat reporting criteria as defined in following table: Passing on or copying of this document. the possibility to make the relationship between an on-going connection and a paging received by another Core Network domain so that the Paging is sent as a type 2 on DCCH. o For 6A and 6B.1 COMMON ID PROCEDURE HANDLING The Common ID procedure is used in the early phase of the connection setup by the Core Network to provide the RNC with the user IMSI identity.2. In the “National Roaming” context. the RNC will: • if the UE is pre-release 5 (i.e. There is no impact on the measurement configuration. depending on the “IMSI-PLMN access right” table defined at the RNC level. R99. This may lead to a drop call since measurement reporting may be not configured properly and therefore mobility management may not be handled.2 MEASUREMENT CONTROL FAILURE On reception of a MEASUREMENT CONTROL FAILURE from the UE.2. This identity is stored by the RNC in order to allow paging coordination. The intra-frequency cell list will be updated by the first MEASUREMENT CONTROL sent after the transition to CELL_DCH i.e.2.UMTS Radio Mobility 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 user IMSI is also used to restrict the list of neighbouring cells. if SHO and Alarm Measurement parameters are changing after a change of primary cell or a RB reconfiguration. As a principle.2.2. the RNC has to memorize the non support of this measurement avoiding another sending of this configuration at next measurement update • Deactivate the Compressed Mode in the NodeB in case of Measurement Control Failure due to CM activation for an HSxPA call. • 5. R4) the message is ignored.3 SUMMARY According to [A7]. On the other hand. The timeout of the Blind HO timer is normally running and a Blind Handover procedure is triggered at its expiration. 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.e. it may happen that Measurement Control RRC messages are sent to the UE on reception of the Common ID message on the Iu. all events need to be re-configured. 5.

3. RB adaptation …). This process is also applicable to other RRC procedures such as “active set update”.3 5.e. but others like 1D. the radio link colour evaluation is based on the measurement results available in the event reporting and other RRC messages to refresh the RL colour.1 Alcatel-Lucent implementation are listed Appendix 1. the radio link colour evaluation as currently implemented for periodical reporting (see [R7] for details) needs to be updated. a RL Addition can be performed with this cell. some events as 1A. the situation is different. During SRLR processing time. The major drawback of this solution is that in very low mobility scenarios (i. 1E. In event reporting mode. Passing on or copying of this document.331 RRC specifications. virtual active set Inter-RAT UE internal measurements Traffic volume measurements Quality measurements UP measurements Ecat 8 6 4 4 8 2 + (2 per Transport Channel) 2 per Transport Channel 2 Note Only applicable for UE with this capability Only applicable for UE with this capability. 5.3.2. and the active set management process is resumed on the basis of measurements received once the SRLR is complete. all measurement received during this phase are put aside. as critical events may have been received during the SRLR phase. • Take into account the last received event 1E (if there is enough room in Active Set at least). If event reporting mode is configured. All the events needed in UA07. In periodic reporting mode.133 Requirements for reporting criteria per measurement category Measurement category Intra-frequency Inter-frequency Inter-frequency. As from 25. number of event reports is low) the RL colour may not reflect the current status of the RL 5. • Take into account the last received event 1D.2. • Take into account all received event 1B (if one RL is remaining at least) or the last one if isOne1bStorageAllowed is set to TRUE.06/EN Approved_Standard 17/Sep/2010 Page 167/244 . • Take into account the last received event 1J (if there is enough room in Active Set at least). incoming PS on a CS call. Based on the events received during the SRLR time window.2 SRLR BLIND WINDOW Synchronous Radio Link Reconfiguration (SRLR) may be performed at any time during connection lifetime (Always-On. Active Set processing during the blocking phase: • Take into account all received event 1F (if one RL is remaining at least). 1B and 1F cannot. the RNC applies a specific process described below.2.1 FEATURE INTERWORKING RADIO LINK COLOR Once that the event reporting mode is introduced. 1C and 1J can be reported periodically. If the triggering cell is in the Monitored Set (possible for UE not in R5). the RNC is unable to maintain the active set. 1B. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility 25. • Take into account the last received event 1A or 1C (if there is enough room in Active Set at least for 1A).

4 PARAMETERS Object/Class FDDCell Class3 RadioAccessService Class3 Definition Flag which enables the event reporting mode enables/disables the storage of only one event 1B on a per RNC basis Name isEventTriggeredMeasAllowed isOne1bStorageAllowed 5. In case of the change of the DLAsConf. 5. 1C.3. Event 1A and 1C will be processed before event 1B stored in parallel if this event 1B is from a UE later than R99 and the parameter isOne1bStorageAllowed is set to TRUE.2 EVENT 1B.3. 1D. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.3. 5. 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.periodic evaluation: performed at each reception of periodic RRC MEASUREMENT REPORT .2. they are used to take a mobility decision at the end of a Blocking Phase.06/EN Approved_Standard 17/Sep/2010 Page 168/244 .1 ALGORITHM FOR PERIODIC REPORTING MODE The active set evaluation process is characterized by: . 2F. 1C. 5.3. 5. The Active Set is supported over Iur. 6A.2.2. 1F 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. ACTIVE SET MANAGEMENT The Active Set is managed differently according to the reporting mode (periodic or intra-frequency event triggered). is treated by the RNC. 1B and 1F are treated by the RNC at the end of a Blocking Phase.UMTS Radio Mobility 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. 6B These events are processed when received since they correspond to arm and stop timer. the received 1A. 1E.2. 1C.2.2.2. The Hard HO treatment has priority on Soft HO.3 EVENT 1D The last 1D event received during the SRLR window.3. 1E.1 EVENT 1A. which has priority on alarm measurements activation. 1J The RNC processes the last 1A.e.3. 5.decision based on relative criterion: threshold applied on (max CPICH Ec/No – CPICH Ec/No(cell to be evaluated)) Passing on or copying of this document. 5. 1E or 1J event received during the SRLR window.2. so that the corresponding Radio Link is added to the active set just after the completion of the SRLR. Note: RNC does not check cell barring information in active set management.4 EVENTS 2D. 1J events with the old configuration (previous DLAsConf) are available. during the NBAP procedure execution).2. Even if the new configuration is different. If received during the SHO blocking window (i.

Put as eligible those which Ec/No(0)-Ec/No(i) < add_threshold Rank all the eligible cells . working as follows: • If a radio link from the active set satisfies either the relative drop_threshold comparison.Keep the max_legs first cells in the active set . 4. The algorithm is the following: 1. the radio link is added to the active set. if a radio link from the monitored set satisfies either the relative add_threshold comparison. Passing on or copying of this document.If all the cells of the current active set are non eligible.2 ENHANCED ALGORITHM FOR PERIODIC REPORTING MODE The algorithm specified in the section above is based on a relative threshold comparison. 2. an “enhanced SHO management algorithm” is available.Keep as eligible in the active set those which Ec/No(0)-Ec/No(i) < drop_threshold . Let’s 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 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the radio link is removed from the active set.3.but insuring that at least one cell from the current active set is in the list 3. the following points have been identified as important factors to better manage the mobility: • Add a good link to the Active Set as quick as possible • Maintain the quality of the Active Set by preventing weak links to get into the Active Set and dropping them from the Active Set as quick as possible As a consequence. or a comparison with an absolute threshold ShoLinkDeletionCpichEcNoThreshold. CPICH Ec/No Max CPICH Ec/No add_threshold drop_threshold Cell in current active set Cell not in current active set Measurement periods Figure 65: algorithm for active set management 5. keep at least the best one Compare (Ec/No(0) – Ec/No(i)) to add_threshold for cells not in the current active set . • Similarly. All the parameters used in the algorithm above are attached to the current primary cell.Cells to be dropped = the others .06/EN Approved_Standard 17/Sep/2010 Page 169/244 .UMTS Radio Mobility a hysteresis is applied for radio link removal which leads to two thresholds: ADD and DROP thresholds continuity in active set is insured: at least the best cell of the current active set is maintained after new active set evaluation even if it is outside window. Find the cell with the highest CPICH Ec/No. Based on the field observations and CDMA experience. or a comparison with an absolute threshold ShoLinkAdditionCpichEcNoThreshold.

link deletion The second condition is illustrated by the following picture. referred to as drop_threshold in the section above threshold to add a cell in the active set. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Links already in the Active Set Max CPICH Ec/No Measured Links ShoLinkDeletionCpichEcNoThreshold Delta Drop Threshold Radio Link to be deleted Cells 1 2 3 4 5 6 7 Links in the Active Set (final) Figure 66: SHO enhancement . Links already in the Active Set Max CPICH Ec/No Measured Links Delta Add Threshold ShoLinkAdditionCpichEcNoThreshold Link to be added to the Active Set Cells 1 2 3 4 5 6 7 Links in the Active Set (final) Figure 67: SHO enhancement .3. Please check the [parameter] section for further details.UMTS Radio Mobility The first condition is illustrated by the following picture. 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. 5.link addition This algorithm can be completely or partially de-activated.3 PARAMETERS FOR PERIODIC REPORTING MODE The parameters are: Name legDroppingDelta Object/Class SoftHoConf Class3 SoftHoConf Class3 Definition threshold to withdraw a cell from the active set.06/EN Approved_Standard 17/Sep/2010 Page 170/244 . referred to as add_threshold in the section above legAdditionDelta Passing on or copying of this document.

the absolute threshold for radio link deletion is applied If enabled. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Radio Link Deletion) are actually triggered by the reception of event 1A (resp. as with the existing “periodic reporting” mechanism.3. 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. • H1a and H1b refer to as hysteresis parameters. 5. the set of parameters which will be used for the algorithm will be a default set defined per Neighbour RNC.06/EN Approved_Standard 17/Sep/2010 Page 171/244 . based on the following assumptions: The active set is limited to 2 links – for illustration purpose only Passing on or copying of this document. 1B) from the mobile. As in [A4]. For that purpose.1 In event triggered mode. They are configured to the values of cpichEcNoReportingRange1A and cpichEcNoReportingRange1B respectively.3. events 1A and 1B are used. it is critical to put the strongest cells in the active set (among the ones being reported by 1A). event 1A allows the same behavior as with current algorithm.  i =1  In order to trigger a report. event 1C is (A non-active primary CPICH becomes better than an active primary CPICH) needed to ensure the RNC keeps the main radio links in the active set. Cell Individual Offset CIO will be used in the AS evaluation algorithm only when at least one of the ShoLinkXxxAbsoluteThresholdEnable flag is True. referred to as max_legs in the section above Absolute threshold for radio link deletion Absolute threshold for radio link addition If enabled. This parameter is configurable for each event. so that Radio Link Addition (resp.4.UMTS Radio Mobility maxActiveSetSize SoftHoConf Class3 SoftHoConf Class3 SoftHoConf Class3 SoftHoConf Class3 SoftHoConf Class3 ShoLinkDeletionCpichEcNoThreshold ShoLinkAdditionCpichEcNoThreshold ShoLinkDeletionAbsoluteThresholdEnable ShoLinkAdditionAbsoluteThresholdEnable maximum number of legs in macrodiversity (from 1 to 6). the triggering condition has to be valid for a period of time named “time to trigger”.4 CASE OF INTRA-FREQUENCY EVENT-TRIGGERED REPORTING MODE DESCRIPTION OF EVENT-TRIGGERED REPORTING MEASUREMENTS BASED ON RELATIVE THRESHOLDS 5. The following picture illustrates a case where 1C event is needed. This works the same way for event 1B:  NA  10 ⋅ LogM Old + CIOOld ≤ W ⋅ 10 ⋅ Log  ∑Mi   + (1 − W ) ⋅ 10 ⋅ LogM Best − ( R1b + H 1b / 2). • CIONew and CIOOld refer to as Cell Individual Offset. In case of “SHO leg number” limitation or if the Active Set is full. • MBest and MOld refer to as CPICH Ec/No measurements made by the mobile. • R1a and R1b refer to as reporting range parameters. the condition for event 1A reporting is as follows: 10 ⋅ LogM New + CIONew  NA  ≥ W ⋅10 ⋅ Log  ∑ Mi   + (1 − W ) ⋅10 ⋅ LogM Best − ( R1a − H1a / 2)  i =1  If W is set to 0. They can be set to the value of hysteresis1A and hysteresis1B.

as in this case cell 2 remains above R1B. Further on. this cannot be achieved. cell 1 and 2 are part of the active set. as the active set size is limited to 2 radio links only. cell 3 is not added to the active set. cell 3 is added and cell 2 is removed. 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. However the non-active cell to appear as a candidate for replacement is too weak and should not be added to the active set. This may result in the scenario shown in figure below.06/EN Approved_Standard 17/Sep/2010 Page 172/244 . timeToTrigger1B. timeToTrigger1C). H1c refer to as hysteresis parameter. Passing on or copying of this document. W = 0. As in [A1]. so that the active set is based on the strongest cells from the monitored set. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. as 1C is reported. The recommended value for timeToTrigger1B will be greater than that for timeToTrigger1C. It can is set to the value of hysteresis1C. cell 1 being the strongest one. However. Unless 1C is available. As Cell 3 crosses R1A. event 1A is reported. event 1C is triggered by the following condition: 10 ⋅ LogM New + CIONew ≥ 10 ⋅ LogM InAS + CIOInAS + H 1c / 2 • • • CIONew and CIOInAS refer to as Cell Individual Offset. MBest and MInAS refer to as CPICH Ec/No measurements made by the mobile. H1A = H1B = 0 Measurement quantity P CPICH 1 P CPICH 2 R1B R1A P CPICH 3 Reporting event 1A Reporting event 1C Time Figure 68: event 1C use case At the beginning.UMTS Radio Mobility Events 1A and 1B are configures as above (CIO = 0. 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. In order to trigger a report.

2 DESCRIPTION OF EVENT-TRIGGERED REPORTING MEASUREMENTS BASED ON ABSOLUTE THRESHOLDS This will be achieved by using 2 events.06/EN Approved_Standard 17/Sep/2010 Page 173/244 .Reporting Range R1b A non-active cell will only be added if its reported CPICH_Ec/N0 plus the Cell Individual Offset is greater than thr_replace: • Reported CPICH_Ec/N0 + CIO > 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.UMTS Radio Mobility Pilot strength Strongest active set cell Reporting Range for e1a 2 nd 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.3. The following events need to be configured: Reporting quantity CPICH Ec/No Event id 1A Triggering condition Monitored set cells or Monitored and Detected set cells Active set cells Monitored set cells CPICH Ec/No CPICH Ec/No 1B 1C The RRC protocol allows configuring periodic reporting of event 1A. namely 1E and 1F on CPICH Ec/No measurements. Time Figure 69: Enhanced event 1C handling 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: • thr_replace = CPICH_Ec/N0 (strongest active set cell) . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 5.4. 1C and 1B (only from Release 5) as long as the reporting criteria are still valid. The following equations [A1] describe the “triggering condition” for 1E: 10 ⋅ LogM New + CIO New ≥ T1e + H 1e / 2 Passing on or copying of this document. The 2nd active set cell should be just removed from the active set. 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.

timeToTrigger1F). only the best ordered in the IE “Event Results” of the Measurement Report is added. in case CIO and H parameters are set to 0. • • • • H1e and H1f refer to as hysteresis parameters. the RNC behaviour is as follows: If either 1A or 1E (if configured) event is received for a cell of the monitored set. CIOOld and CIONew refer to as Cell Individual Offset. In this figure. The following picture illustrates event 1E and 1F reporting. In case of several Monitored Set to Add. T1e and T1f refer to as absolute thresholds. MNew refers to as CPICH Ec/No or CPICH RSCP measurement made by the mobile. They can is set to the value of hysteresis1E and hysteresis1F.3. the P-CPICH 3 will trigger an event 1E and P-CPICH 1 will trigger an event 1F.06/EN Approved_Standard 17/Sep/2010 Page 174/244 . 5. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility and 1F: 10 ⋅ LogMOld + CIOOld ≤ T1 f − H1 f / 2.3 • ALGORITHM In case of intra-frequency Event-Triggered Reporting mode. 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 Passing on or copying of this document. The RRC protocol allows configuring the event 1E trigger by either Monitored Set cells or Detected Set cells or both Monitored and Detected Set cells. This parameter is configurable for each event (the values sent to the UE are defined by the parameters timeToTrigger1E. the triggering condition has to be valid for a period of time named “time to trigger”. the corresponding radio link is (possibly) added to the active set. The events used to support this feature would be as follows: Reporting quantity CPICH Ec/No Event id 1E Triggering condition All Monitored set cells or Monitored and Detected set cells All active set cells CPICH Ec/No 1F Please note that CIO is a configurable parameter defined against the primary cell for each of its neighbour cell. 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 Figure 70: Events 1E and 1F In order to trigger a report.4.

1. • • If either 1B or 1F (if configured) event is received for a cell of the active set. but also on the measurements reported for the other cells in the active set. 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. the RNC will replace the cell in the Active Set indicated in the measurement report with the cell triggering this event. Note: The release information above is added in order to distinguish between this feature (refer to [R5])and the later SHO enhancements. the radio link addition/deletion absolute criteria makes use of CIO parameter defined in the RNC database (Cell Individual Offset). the CIO will be sent to the UE through the Measurement Control message. Note: If event 1F identifies the Primary cell to be removed then the event is ignored. the RNC will not have a special handling to avoid a potential ping-pong generated by RNC actions (i. CIO will be applied by the UE on events 1E and 1F.6. In this version. This is still the case when event-triggered measurement reports are used. 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). 1C and 1D (for R5 UEs if configured). 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. However a non-active cell (i.1) is active. 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. 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.e.5. In this case event 1C will be acted upon as if event 1B would have been received i.1) is not active.UMTS Radio Mobility added in the active set unless special conditions for event 1A do apply.3) which in consequence does no more represent the complete neighborhood of the active set. Therefore: • If the “SHO enhancement” feature (release UA04. 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. but also on events 1A. Detected Set cells will be added to the active set under the same conditions as described for event 1A above. the RNC deletes them: so the RNC can resize the Active Set.e.4). As in “SHO enhancement” specification for release UA04. the corresponding radio link is removed from the active set If 1C event is received. only a radio link removal will result. 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).3 Passing on or copying of this document. 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. 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). If Detected Set cells are reported the RNC will trace this as specified in § 5.3. the CIO will not be sent to the UE and events 1E and 1F are not configured. If several Active Set cells are included in the “Event Results” and are worse than the Monitored Set cell to add. 1B.2.06/EN Approved_Standard 17/Sep/2010 Page 175/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 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. In this case. 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.e. as in the current “SHO enhancement” implementation • If the “SHO enhancement” feature (release UA04.

In order to limit the risk of loosing an event on the radio interface because of bad transmission conditions.7.4. Up to 8 events can be configured in a single message.UMTS Radio Mobility 5.06/EN Approved_Standard 17/Sep/2010 Page 176/244 . some events reporting are not repeated.3. as it is not needed by 3GPP 25.2.1 1A EVENT CONFIGURATION Need OP MP CV–clause 0 CV–clause 6 CV–clause 2 CV–clause 1 Parameter Value “1a” Not needed “Monitored Set Cells” or “Monitored and Detected Set cells” Use cpichEcNoReportingRange1A parameter Not used 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 Passing on or copying of this document.3.2. Control Common part (reporting type…) §10.4. all intra-frequency events and measurements can be configured in a single message. all intra-frequency event reports are configured in RLC Acknowledged Mode.331 specifications “not used” means the IE is optional and not used in this implementation. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.36 common part: • Intra-frequency measurement quantity: CPICH Ec/No • Intra-frequency reporting quantity: o For active set cells: CPICH Ec/No and CPICH RSCP o For monitored set cells: CPICH Ec/No and CPICH RSCP o For detected set cells: CPICH Ec/No In all the tables below: “not needed” means the IE is not part of the message.3.36 Intra-freq measurements Common part (meas quantities…) §10. §10.3.17 common part: The IE Measurement reporting mode contains the specific information: • Measurement Report Transfer Mode: Acknowledged mode RLC • Reporting Mode: Event trigger In the §10.4 CONFIGURATION As only one intra-frequency measurement quantity is actually required (CPICH Ec/No).7. The overall structure of the intra-frequency MEASUREMENT CONTROL message is as follows.17 Meas. 5.3.4. As in [A4].7.39 Intra-freq meas rep criteria Event 1A Event 1B … Figure 71: intra-frequency Measurement Control message structure In the §10.

and ignored by R99 UEs. the value of this IE shall be set to (maxActiveSetSize-1).3. This IE is part of Alcatel-Lucent implementation and is sent each time event 1B is configured. This change is made on a backward compatible way.06/EN Approved_Standard 17/Sep/2010 Page 177/244 . The purpose of this IE is to avoid the UE to report event 1A if the active set size limit is reached. will be decoded by R5 and above UE.4.UMTS Radio Mobility Information Element/Group name >W >Hysteresis >Threshold used frequency >Reporting deactivation threshold >Replacement activation threshold >Time to trigger >Amount of reporting >Reporting interval >Reporting cell status Need CV–clause 2 MP CV-clause 3 CV–clause 4 CV-clause 5 MP CV–clause 7 CV–clause 7 OP Parameter Value Use weight1A parameter Use hysteresis1A parameter Not needed Use value (maxActiveSetSize-1) Not needed Use timeToTrigger1A parameter Use amountRep1A parameter Use repInterval1A parameter Use maxNbReportedCells1A parameter Remark: The “Reporting deactivation threshold” IE indicates the maximum number of cells allowed in the active set in order for event 1a to occur. when present. 5. meaning that this IE. a periodical reporting IE has been added for event 1B. so that if the active set is limited by the maxActiveSetSize parameter.4.2 1B EVENT CONFIGURATION Need OP MP CV–clause 0 CV–clause 6 CV–clause 2 CV–clause 1 CV–clause 2 MP CV-clause 3 CV–clause 4 CV-clause 5 MP CV–clause 7 CV–clause 7 OP CV–clause 9 Parameter Value “1b” “Active Set Cells” Not needed Use cpichEcNoReportingRange1B parameter Not used Use weight1B parameter Use hysteresis1B parameter Not needed Not needed Not needed Use timeToTrigger1B parameter Not needed Not needed Use maxNbReportedCells1B parameter Use amountOfRep1B and repInterval1B parameters 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 >Periodical reporting information-1b Remark: As a 3GPP R5 improvement. Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.

UMTS Radio Mobility 5. The purpose of this IE is to avoid the UE to report event 1C if the active set size limit is not reached. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.06/EN Approved_Standard 17/Sep/2010 Page 178/244 .4.3.3. Use cpichEcNoThresholdUsedFreq1E Not needed Not needed Use timeToTrigger1E parameter Not needed Not needed Use maxNbReportedCells1E parameter 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 Passing on or copying of this document. 5.4.4.4 1E EVENT CONFIGURATION Need OP MP CV–clause 0 CV–clause 6 CV–clause 2 CV–clause 1 CV–clause 2 MP CV-clause 3 CV–clause 4 CV-clause 5 MP CV–clause 7 CV–clause 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.3 1C EVENT CONFIGURATION Need OP MP CV–clause 0 CV–clause 6 CV–clause 2 CV–clause 1 CV–clause 2 MP CV-clause 3 CV–clause 4 CV-clause 5 MP CV–clause 7 CV–clause 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 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 Remark: The “Replacement activation threshold” indicates the minimum number of cells allowed in the active set in order for event 1C to occur.4.

5 PARAMETERS FOR EVENT REPORTING MODE All event parameters may be provisioned at OAM level except the Reporting Deactivation Threshold which is equal to “ maxActiveSetSize (set by OAM)”. CPICH Ec/No hysteresis for link addition in Active Set weight1A timeToTrigger1A amountRep1A repInterval1A maxNbReportedCells1A cpichEcNoReportingRange1B MeasurementConfClass Class3 MeasurementConfClass Class3 MeasurementConfClass Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 hysteresis1B weight1B defines the weight to configure for the triggering of event 1A in Full Event mode 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. Use cpichEcNoThresholdUsedFreq1F Not needed Not needed Use timeToTrigger1F parameter Not needed Not needed Use maxNbReportedCells1F parameter 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 5. defines the weight to Passing on or copying of this document.5 1F EVENT CONFIGURATION Need OP MP CV–clause 0 CV–clause 6 CV–clause 2 CV–clause 1 CV–clause 2 MP CV-clause 3 CV–clause 4 CV-clause 5 MP CV–clause 7 CV–clause 7 OP Parameter Value “1f” “Active Set Cells” Not needed Not needed Not used Not needed Use hysteresis1F parameter.4.06/EN Approved_Standard 17/Sep/2010 Page 179/244 .4.3. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Relative CPICH Ec/No threshold for SHO Radio Link Addition.UMTS Radio Mobility 5. Name isDetectedSetCellsAllowed detectedSetCellAddition cpichEcNoReportingRange1A Object/Class RadioAccessService Class3 FDDCell Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 hysteresis1A Definition Allows tracking of detected cells Allows addition of detected set cells to the active set.3. CPICH Ec/No hysteresis for link deletion in Active Set .

If enabled.UMTS Radio Mobility configure for the triggering of event 1B in Full Event mode Period of time during which the event condition has to be satisfied before sending event 1B 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.06/EN Approved_Standard 17/Sep/2010 Page 180/244 . 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 timeToTrigger1B UsHoConf Class3 isOne1bStorageAllowed Radio Access Service Class 3 amountRep1B repInterval1B maxNbReportedCells1B hysteresis1C timeToTrigger1C MeasurementConfClass Class3 MeasurementConfClass Class3 MeasurementConfClass Class3 UsHoConf Class3 UsHoConf Class3 amountRep1C repInterval1C maxNbReportedCells1C isEnhanced1cHandlingAllowed MeasurementConfClass Class3 MeasurementConfClass Class3 MeasurementConfClass Class3 Radio Access Service Class 3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 isEvent1EUsed hysteresis1E timeToTrigger1E maxNbReportedCells1E cpichEcNoThresholdUsedFreq1E MeasurementConfClass Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 isEvent1FUsed hysteresis1F timeToTrigger1F maxNbReportedCells1F MeasurementConfClass Class3 Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.

for a set of calls. • Number of Event 1J (triggered by event 1J reception). 5.6 5. Passing on or copying of this document. 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. o event 1E. • Number of Event 6B (triggered by event 6B reception). • Number of Event 1B (triggered by event 1B reception).UMTS Radio Mobility cpichEcNoThresholdUsedFreq1F UsHoConf Class3 Absolute CPICH Ec/No threshold for SHO Radio Link Deletion. If a Detected Cell is reported by the UE. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 15 seconds – static value cpTimerFileringCallFailureTrace -). the RNC requests the UE: • to trigger the following events on Detected Cells also: o event 1A.2 TRACES If the MIB flag RadioAccessService.1 PERFORMANCE MANAGEMENT COUNTERS The following counters are defined: Per FDDCell (the Primary RL of the UE is on this FDDCell). • Number of Event 2D (triggered by event 2D reception). where triggering Cells are both Detected Set Cells and Monitored Set Cells. • Number of Event 1E triggered by a Cell of the Monitored Set (triggered by event 1E reception). • Number of Event 1F (triggered by event 1F reception). • Number of Event 1D (triggered by event 1D reception). • Number of Event 1D (triggered by event 1D reception). All the following counters are of cumulative type: • Number of Event 1A triggered by a Cell of the Monitored Set (triggered by event 1A reception). 5. • Number of Event 1C (triggered by event 1C reception). • Number of Event 6A (triggered by event 6A reception). • Number of Event 6B (triggered by event 6B reception). • Indication of at least one available Call Failure Trace due to a Detected Cell (triggered by reception of event 1A or 1E triggered by a Detected Cell). • Number of Event 2F (triggered by event 2F reception). • Number of Event 2D (triggered by event 2D reception). Per neighboring RNC (The Primary RL of the UE is on this Neighboring RNC). This filtering mechanism allows to have at most one Call Failure Trace in a given period (e. • Number of Event 1F (triggered by event 1F reception).isDetectedSetCellsAllowed is TRUE. • Number of Event 1B (triggered by event 1B reception).06/EN Approved_Standard 17/Sep/2010 Page 181/244 . • To report the measurement of the Detected Cells in the Measured Result part of these events. For the Call Failure Trace. • Number of Event 2F (triggered by event 2F reception). • Number of Event 6A (triggered by event 6A reception).3. the intra-frequency part of the RRC Measurement Report message and the scrambling code of the Detected Cell are traced. • Number of Event 1E triggered by a Cell of the Monitored Set (triggered by event 1E reception). • Number of Event 1C (triggered by event 1C reception).6. All the following counters are of cumulative type: • Number of Event 1A triggered by a Cell of the Monitored Set (triggered by event 1A reception). where triggering Cells are both Detected Set Cells and Monitored Set Cells.6.g.3. • Indication of at least one available Call Failure Trace due to a Detected Cell (triggered by reception of event 1A or 1E triggered by a Detected Cell).3.

5. this cell is added to E-DCH active set (as serving) and the former primary is removed from EDCH active set.2 CASE OF INTRA-FREQUENCY PERIODIC REPORTING MODE The determination of a new primary cell is performed after each “active set evaluation” process. 5.either this candidate cell = current primary cell.UMTS Radio Mobility 5. removed from) the DCH active set are also added. to (resp.3. A new event 1J can be managed: 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.4. The serving link is always the primary cell of the DCH active set. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. On event 1J report. In this case: o if CPICH Ec/No(candidate cell) – CPICH Ec/No(current primary cell) > DropPriRL new primary cell = candidate primary cell o else the new primary cell = current primary cell Passing on or copying of this document.e. It is used for monitored cells set determination and also as a pointer to mobility parameters. If the E-DCH active set is full and a new primary cell is elected which is not in EDCH active set. 5. the E-DCH active set can have up to 4 links that are a subset of DCH active set.7 E-DCH ACTIVE SET MANAGEMENT From UA06.1 PRIMARY CELL DETERMINATION DESCRIPTION The primary cell is a sort of reference cell for the UE. removed from) the E-DCH active set.06/EN Approved_Standard 17/Sep/2010 Page 182/244 . parameters with a cell granularity which are to be used for a mobile are those corresponding to its primary cell. if compatible.4.the cell which was already in the active set (so that its neighbouring is already known even if this cell is located on a DRNC) and which has the best CPICH Ec/No Two cases must be considered: . The algorithm is the following: After the active set evaluation process. All links added to (resp. one link (given in the measurement report) is removed from the E-DCH active set (but kept in the DCH one) and is replaced as non-serving by a link of the DCH active set (also given the measurement report). i.4.or this candidate cell is different from the current primary cell.0. refer to [R6] UMT/SYS/DD/018827 E-DCH System Specification. a candidate cell for new primary cell is selected according to the following condition: . in this case the new primary cell = current primary cell . Note: RNC does not check cell barring information in primary cell determination. For all details on this feature.

cell (1) being the current primary. In this formula. This parameter will be set to the value of hysteresis1D parameter. in case CIO parameters are set to 0.4. In the following the normal case of event 1D is described but the same behaviour applies also in case of event 1B or 1C with primary cell removal. the definition of event 1D has been changed to take into account CIO parameters.3.UMTS Radio Mobility 5.1 The primary cell determination will be usually based on event 1D reception.4). as in the following formula (applicable to CPICH Ec/No measurements): 10 ⋅ LogM NotBest ≥ 10 ⋅ LogM Best + H 1d / 2 In 3GPP R5. In [A4]. MBest and MNotBest refer to as CPICH Ec/No measurements made by the mobile. CIO will only be applied by R5 UEs. a hysteresis can be used. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. The following picture illustrates event 1D reporting.06/EN Approved_Standard 17/Sep/2010 Page 183/244 .3. Event 1D is reported once cell (2) measurement quantity exceeds cell (1) by H1d/2. Note: In addition a primary cell selection can be triggered by event 1B or 1C if the event requests the deletion of the current primary cell (see also section 'Algorithm' in 5.4. either cell dependent (through the Cell Individual Offset parameter) or absolute (through the H1D parameter). • • CIONotBest and CIOBest refer to as Cell Individual Offset. and only if requested by a configuration flag present in event 1D configuration sent in Measurement Control message: 10 ⋅ LogM NotBest + CIO NotBest ≥ 10 ⋅ LogM Best + CIOBest + H 1d / 2 • H1d refers to as hysteresis parameter. Passing on or copying of this document.3 CASE OF INTRA-FREQUENCY EVENT-TRIGGERED REPORTING MODE DESCRIPTION 5. event 1D is triggered on a condition relative to active set or monitored set measurements. Measurement quantity H1d/2 P CPICH 1 P CPICH 2 P CPICH 3 Reporting event 1D Time Figure 72: event 1D As in existing periodic measurement based algorithm.

If “SHO enhancements” (release UA04. 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.4. When CIO is used it may happen that 1A event is not triggered but 1D event is triggered. Note: The release information above is added in order to distinguish between this feature (refer to [R5]) and the later SHO enhancements.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.UMTS Radio Mobility 5. the RL will be added in the Active Set if not full. and applies the current process used in case of change of primary cell. If the event 1D is triggered by a monitored cell.4.3 CONFIGURATION Refer to § 5.3.3. A new primary cell will also be defined if the current primary cell will be removed due to reception of RL deletion events.3. 1C are also configured (see section 5. Since the events 1A. the RNC stores the new primary. Based on the reception of this event.1 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 CV–clause 0 CV–clause 6 CV–clause 2 CV–clause 1 CV–clause 2 MP CV-clause 3 CV–clause 4 CV-clause 5 MP CV–clause 7 CV–clause 7 OP CV–clause 10 Parameter Value “1d” Not needed Not needed Not needed Not used Not needed Use hysteresis1D parameter. 5.06/EN Approved_Standard 17/Sep/2010 Page 184/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.1) is enabled and the useCIOfor1D is set to TRUE then CIO values are configured in the UE if the UE is Release 5.4 / configuration for common part of Measurement Control message. An event 1D will typically be triggered by a cell better than the best in the active set. then the event1D will provide the replacement of the worse cell in the Active Set. 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. Not needed Not needed Not needed Use timeToTrigger1D parameter Not needed Not needed Use maxNbReportedCells1D parameter Use useCIO1D parameter Passing on or copying of this document. 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. 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.3. 5.3. If the Active Set is full.2 ALGORITHM The primary cell determination will be based on event 1D reception.4.

2 APPLICABILITY The feature is efficient if the intra frequency -. this compound list to UE A new algorithm (type 1) to compute the compound neighbour cell list has been introduced for intra-frequency. the set of parameters which will be used for the algorithm will be a default set defined per Neighbour RNC. referred to as DropPriRL in the section above.5. This section is based on the feature called UMTS composite neighbour list. Maximum allowed number of cells to report with event 1D 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. 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. when in dedicated mode. inter-frequency and 2G inter-RAT neighbour cells. Compounding list functionality is the capability for the RNC: o To dynamically create the neighbour list a UE will monitor.4 PARAMETERS The parameters are: Name rrcIntraFreqMeasurementDropPrimaryRlDelta Object/Class UsHoConf Class3 Definition hysteresis for primary cell modification. This flag indicates if CIO parameter has to be taken into account in 1D triggering condition useCIOfor1D MeasurementConfClass Class3 hysteresis1D UsHoConf Class3 UsHoConf Class3 timeToTrigger1D maxNbReportedCells1D MeasurementConfClass Class3 CPICH Ec/No hysteresis primary cell determination Period of time during which the event condition has to be satisfied before sending event 1D. 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. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.5.06/EN Approved_Standard 17/Sep/2010 Page 185/244 .1 The object of the section is the introduction of dynamic compounding cell lists in connected mode.5. o To send. 5. It applies for calls in cell-DCH state only. LIST OF COMPOUNDING CELLS FOR THE MONITORED SET DEFINITION DESCRIPTION 5. inter frequency – or inter RAT neighbour of each Fdd cell is optimized.UMTS Radio Mobility 5. Passing on or copying of this document.4. through RRC Measurement Control message. depending on the “radio” neighbourhood of this UE. this neighbourhood being either defined by the active set. 5. or by measurements.

or the list reaches maxSizeCompoundingList cells.06/EN Approved_Standard 17/Sep/2010 Page 186/244 . • 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. Until: the new monitored cell set goes up to maxNbOfMonitoredCellForNonShoCompoundList cells . The neighbors are selected into the compound list based on (given in order of significance) • • • • • The RNC selects the first N cells from the prioritized neighbour list of the primary cell (N stands for parameter numOfPrimaryCellNeighbourIntraFreq. 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. Passing on or copying of this document. If feature compounding list is not activated: • The monitored set is the neighbouring list of the primary cell. • Type 1: Compound neighbour list is build from all active set cells. 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. maxCompoundingListSizeInterFreq or maxCompoundingListSizeInterRAT respectively) is exceeded then the lower priority cells are discarded.UMTS Radio Mobility 5. 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. it selects the cell with the highest measured quality of the active set cell In case of same quality. or the list reaches maxSizeCompoundingList cells.or inter RAT neighbour cells. 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 .5.3 ALGORITHM The best cell is the cell with the best CPICH Ec/No. when the connection is not engaged in soft or softer HO. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. The behavior is the same as if feature compounding list is not activated. until: the last leg and its static neighborhood list for dedicated mode has been added. o Or the N first (bests) measured cells and their static neighbour list for dedicated mode. when the connection is engaged in soft or softer HO.

5. Used when primary cell is on typeOfCompoundingNeighbourListIntraFreq NeighbouringRNC Class 3 Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.4 PARAMETERS Object/Class RadioAccessService Class3 RadioAccessService Class3 RadioAccessService Class3 RadioAccessService Class3 FDDCell Class 3 Name maxCompoundingListSizeIntraFreq maxCompoundingListSizeInterFreq maxCompoundingListSizeInterRAT 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 2G inter-RAT compound list Used to activate or inhibit the compounded list feature isCompoundingCellListActivated typeOfCompoundingNeighbourListIntraFreq Used to determine the algorithm for intra-frequency neighbor list creation for dedicated measurements. Whatever the neighbor building list method. The compound inter RAT neighbour cell list shall be computed when • a new RRC Measurement Control message for 2G inter-RAT measurements (measurement type 3) has to be sent to UE. The compound inter frequency neighbour cell list shall be computed when • • • change of primary cell or active set update has occurred while inter frequency measurements are ongoing or when a new RRC Measurement Control message for inter-frequency measurements (measurement type 2) has to be sent to UE.5. In case of intra frequency neighbour cells there is a special handling such that no update will be sent to UE if cells have been removed only but no cells have been added. Possible values are PRL. successful hard handover.UMTS Radio Mobility or until the last measured cell. The compound intra frequency neighbour cell list shall be computed when • • • • state transition to Cell_DCH.06/EN Approved_Standard 17/Sep/2010 Page 187/244 . the neighbour list updates only include the cells to be removed and to be added (delta between the previous neighbourhood and the new neighbourhood). Type2 Used to determine the algorithm for intra-frequency neighbor list creation for dedicated measurements. change of primary cell or active set update has occurred. Type1.

Possible values are PRL.06/EN Approved_Standard 17/Sep/2010 Page 188/244 . The minimal number of 2G inter-RAT neighbor cells of the primary cell to be definitely included in the compound neighbor list. The minimal number of intrafrequency neighbor cells of the primary cell on DRNC to be definitely included in the compound neighbor list. Used when primary cell is on DRNC. Type1 Used to determine the algorithm for inter RAT neighbor list creation for dedicated measurements. Type2 Used to determine the algorithm for inter-frequency neighbor list creation for dedicated measurements. The minimal number of interfrequency neighbor cells of the primary cell to be definitely included in the compound neighbor list. Possible values are PRL. Type1 The minimal number of intrafrequency neighbor cells of the primary cell to be definitely included in the compound neighbor list. Possible values are PRL.UMTS Radio Mobility DRNC. Type1. Type1 Used to determine the algorithm for 2G inter-RAT neighbor list creation for dedicated measurements. Possible values are PRL. Used when primary cell is on DRNC. Type1 Used to determine the algorithm for inter-frequency neighbor list creation for dedicated measurements. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Possible values are PRL. The minimal number of interfrequency neighbor cells of the primary cell on DRNC to be definitely included in the compound neighbor list. The minimal number of 2G inter-RAT neighbor cells of typeOfCompoundingNeighbourListInterFreq FDDCell Class 3 typeOfCompoundingNeighbourListInterFreq NeighbouringRNC Class 3 typeOfCompoundingNeighbourListInterRAT FDDCell Class 3 typeOfCompoundingNeighbourListInterRAT NeighbouringRNC Class 3 numOfPrimaryCellNeighbourIntraFreq FDDCell Class 3 numOfPrimaryCellNeighbourIntraFreq NeighbouringRNC Class 3 numOfPrimaryCellNeighbourInterFreq FDDCell Class 3 numOfPrimaryCellNeighbourInterFreq NeighbouringRNC Class 3 numOfPrimaryCellNeighbourInterRAT FDDCell Class 3 numOfPrimaryCellNeighbourInterRAT NeighbouringRNC Class 3 Passing on or copying of this document.

MeasCtrlCellListSizeInterRAT Size of the compound 2G inter-RAT neighbor list VS. If the operator modifies an FDD cell attribute. SIB4. • For the UE in cell FACH state.neighbourCellPrio gsmNeighbouringCellList[].ExcdAggrCellListSizeInterFreq Amount by which the maximum inter-frequency neighbor list size is exceeded VS. SIB3. SIB12 and SIB19 are sent only if parameters SIB4Enable.ExceededAggregateCellListSizeIntraFreq Amount by which the maximum intra-frequency neighbor list size is exceeded. SIB5. VS.6. the UE may read some system information (SIB) broadcasted on the FDD cell. which leads it to update the broadcasted SIB content with an updated value tag • Then the UE’s in idle mode are notified by paging from RNC which forces them to re-acquire the new Sys. they are notified by a SYSTEM INFORMATION CHANGE INDICATION message.MeasCtrlCellListSizeInterFreq Size of the compound inter-frequency neighbor list VS. SIB6.UMTS Radio Mobility the primary cell on DRNC to be definitely included in the compound neighbor list. this updated attribute is broadcasted by a System Information Block (SIB1.6.ExcdAggrCellListSizeInterRAT Amount by which the maximum 2G inter-RAT neighbor list size is exceeded VS. the behaviour is the same than in Idle date (type 1 paging) Note 1: The SIB7 filling is managed by the NodeB. SIB2.4).MeasurementControlCellListSize Size of the compound intra frequency neighbor list VS.06/EN Approved_Standard 17/Sep/2010 Page 189/244 . • For the UE in URA PCH or CELL PCH state. The priority of intra-frequency or inter-frequency neighbour cells The priority of 2G inter-RAT neighbour cells umtsFddNeighbouringCellList[]. SIB19) as follows: • The SRNC sends the content of all SIB to the NodeB (NBAP System Info Update procedure).1 MANAGEMENT OF SYSTEM INFORMATION BLOCKS (SIB) SIB UPDATE During procedures like cell search or cell (re)selection. SIB12Enable.5 PERFORMANCE MANAGEMENT The following counters are defined on FDDCell basis • • • • • • • • • VS. SIB11 or SIB12. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Info. Passing on or copying of this document.AggregateCellListAmbiguousCellIntraFreq The aggregate intra-frequency neighbor list contains an ambiguous cell. SIB19Enable and isDynamicSibAlgoWithSBAllowed are set to TRUE (refer to § 4. Note 2: SIB4.5. 5.AggrCellListAmbigCellInterRAT The aggregate 2G inter-RAT neighbor list contains an ambiguous cell 5. VS.5.AggrCellListAmbigCellInterFreq The aggregate inter-frequency neighbor list contains an ambiguous cell.neighbourCellPrio FDDCell Class 3 FDDCell Class 3 5. VS.

The SB1 repetition period is set to the lowest repetition period of SIB(s) (RP0 or RP1) which may be addressed by SB1. SIB1 and SIB7 blocks have the same repetition period set to 16 and a start position set to 2. 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. The algorithm uses the following constraints: 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. This new algorithm is used if parameter isDynamicSibAlgoWithSBAllowed is set to TRUE.06/EN Approved_Standard 17/Sep/2010 Page 190/244 . parameters isSib19Allowed and sib19Enable are set to TRUE. SIB5.e. SIB6.UMTS Radio Mobility 5.0. MIB block has a repetition period set to 8 and a position set to 0 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. SIB3 and SIB4 shall have the same RP0 repetition period between 32 and 128. In UA06. SIB2. MIB block has a repetition period set to 8 and a position set to 0 . SIB5. a dynamic SIB scheduling algorithm sets the repetition period (IB_SG_REP) and the position (IB_SG_POS) of each SIB according to the number of SIB segments needed [A3]. • • • • • In UA07. the algorithm tries to find the lowest repetition period value for RP0 first then for RP1. 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. SIB11.2. SIB2.2 SIB REPETITION PERIOD In UA05. It uses the following constraints: • Limitation of the number of MIB segments. SIB2. SIB11 and SIB12 shall have the same RP1 repetition period between 32 and 256.1. SIB12 and SIB19 shall have the same RP1 repetition period between 32 and 256. SIB6 and SIB11 shall have a RP1 repetition period between 32 and 256. It shall not exceed one segment. SIB1 and SIB7 blocks have the same repetition period set to 16 and a start position set to 2. SIB6. This new algorithm is used if parameter isDynamicSibAlgoWithSBAllowed is set to TRUE. SIB5. with introduction of SIB4 and SIB12. the dynamic SIB scheduling algorithm is modified. The setting of RP0 has a higher priority than RP1 i. It uses the following constraints: • Limitation of the number of MIB segments. • • • • • Passing on or copying of this document. The SB1 repetition period is set to the lowest repetition period of SIB(s) (RP0 or RP1) which may be addressed by SB1. SIB3 and SIB4 shall have the same RP0 repetition period between 32 and 128.0.6. the dynamic SIB scheduling algorithm is modified. with introduction of SIB19. SIB3 shall have a RP0 repetition period between 32 and 128.

The MRC (Maximum Ratio Combining) algorithm implemented in the BTS makes use of conventional "Rake receiver" techniques.UMTS Radio Mobility 5. Radio Link recombination is not supported at the DRNC. the 2 data streams from NodeB 2 and NodeB 3 are switched to the Iur between the DRNC and the SRNC). This is what is done in NodeB 2 in the figure above. For event triggered reporting only event 1A is configured. i. This allows the activation of the intra-frequency measurement event 1A for each mobile entering in Cell-DCH state.8. if a "Radio Link Addition" is received from the SRNC. requesting the DRNC to perform diversity recombination. the NodeB performs radio link recombination. the request will be rejected by the Alcatel-Lucent DRNC if two different Node Bs are involved under the drift (but accepted if only one Node B).06/EN Approved_Standard 17/Sep/2010 Page 191/244 . the data streams from NodeB 1 and the 2 streams from the Iur in the figure above).e. At the SRNC level: All the Radio Links terminating at the SRNC level are recombined by the SRNC (i. These UEs acquire intra-frequency configuration contained in SIB11. all the different paths (or at least the ones received with the highest energy) are recombined in the rake receiver before channel decoding. See reference document [R3] UMT/SYS/DD/013000 Mobility Performance Improvements.e. 5. It means that. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. DHO MANAGEMENT This section provides an overview of the management of diversity handover (uplink) in Alcatel-Lucent UTRAN nodes. At the DRNC level: The Cid from the Iub interface are only switched to the Iur (in the figure above. In this version.7. MSC/ SGSN Iu Iur SRNC DRNC Iub NodeB 1 NodeB 2 NodeB 3 UE Figure 73: Macro-diversity in uplink At the NodeB level: If several radio links are active for the same UE in a NodeB. or UDP port for IP) for the same transport bearer (DCH. so that there is only one transport connection (AAL2 CID for ATM. INTRA-FREQ MEASUREMENTS CONFIGURATION VIA SIB11 The UTRAN provides UEs in other state than Cell-DCH with the configuration of intra-frequency measurements via the SIB11. They can start and report their intra-frequency measurements without waiting any RRC Measurement Control message. MAC-d flow for HS-DSCH or E-DCH) on the Iub for all combined radio links. Passing on or copying of this document.

This process works as follows: • the payload CRC of the UP frames (if included) is checked. the CRCi will be considered as "not correct" regardless of the value received from the NodeB 5.9. only TB with a "correct" CRCi are kept.1 ALARM HANDOVER AND ALARM MEASUREMENTS OVERVIEW In this version of the document. The others reasons for processing a Hard Handover managed by the iMCTA function are: CAC failure and Service (see section 4.06/EN Approved_Standard 17/Sep/2010 Page 192/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 5.UMTS Radio Mobility The recombination process performed by the SRNC is actually a frame selection process. As soon as the first valid measurement is received from the mobile. Any frames with bad CRC is rejected • in each frame. the Alarm handover is performed. Radio quality Cr Alarm Measurements Reporting phase time Alarm Measurements trigger 1st valid measurement from UE Alarm Handover trigger Figure 74: the fast alarm algorithm Passing on or copying of this document. if the QE is not good enough. This section deals with Alarm radio condition. • in case TB from different stream have a "correct" CRCi. This algorithm allows better reactivity from UTRAN.9. possibly following by Compressed Mode activation. the TB with the best QE if eventually selected • anyway. Others are rejected. and TB CRCI (CRC Indicator) and QE (Quality Estimate) fields received from each data stream. as only one radio criteria is used for both alarm measurement and handover triggering. the Alarm measurements are activated once a criteria Cr is fulfilled. based on the payload CRC. alarm handover is a Hard Handover triggered by the iMCTA function when an Radio alarm condition is detected. It also has a positive impact on network capacity as it limits the time during which Compressed Mode is active. 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”. Fast Alarm algorithm description: As illustrated in the figure below.19). The Triggering of the Alarm measurement and the handover is based on the “Fast Alarm” algorithm.

Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the following criteria is evaluated: AlarmMeas = (CPICH Ec/No < ThreshEcMeas) or (CPICH RSCP < ThreshRSCPMeas) for the Primary cell. and once the primary cell has been updated.UMTS Radio Mobility 5. based on mobile needs. For further details on this procedure. Then. At each reception of RRC MEASUREMENT REPORT (which is periodic). then the following is applied: 1. the following process is applied: If AlarmMeas is valid Increment AlarmMeasCounter by UpStep Else Let AlarmMeasCounter = max (0. please refer to the 6. 2.2 ALARM MEASUREMENT ACTIVATION WITH PERIODIC INTRA FREQUENCY MEASUREMENTS Inter-system and inter-frequency measurements are requested under certain radio conditions.4 chapter on Compressed Mode. a Compressed Mode Command message is sent to the UE 3. AlarmMeasCounter – DownStep) Endif If AlarmMeasCounter > AlarmMeasCounterThreshold then Alarm measurements are requested from the mobile The following figure illustrates this process: Yes Alarm Measurement criteria No Measurement report occasions AlarmMeasCounter AlarmMeasCounterThreshold DownStep UpStep Alarm Meas decision: AlarmMeasCounter > AlarmMeasCounterThreshold time Figure 75: Alarm measurement decision process In case the Alarm Measurement Criteria is valid.9. Inter-system or inter-frequency measurements are requested from the mobile using a Measurement Control message (please refer to the section 6.06/EN Approved_Standard 17/Sep/2010 Page 193/244 . if compressed mode needs to be reactivated .2 for further details). as indicated in the mobile "UE capabilities" Information Element". Compressed Mode is possibly activated using the Measurement Control message.

neigh GSM cells. neighbouring cells filtered after applying IMSI criteria…) or no suitable Alarm measurement is reported by the mobile within a guard timer period.5 s of Compressed Mode for measuring and decoding a first set of neighbouring GSM BSIC. the compressed mode activation condition is still valid. Passing on or copying of this document.... inter-frequency) measurements.. This is explained by: • The current value of Compressed Mode activation time (1. If no neighbouring measurement may be requested to the UE but Inter Rat HHO is allowed (for example: CM not possible. and compressed mode is re-activated Figure 76: measurement activation example (inter-system case) As a MEASUREMENT REPORT is received with GSM (resp. Remark 1: The additional check on the Alarm Measurement criteria once a measurement is received is needed. If still valid. intersystem meas)) . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. the mean period of time between the sending of the MEASUREMENT CONTROL and the reception of the related MEASUREMENT REPORT is around 3s. quite high but necessary to secure the correct reception of the MEASUREMENT REPORT message by the UE • The fact that the mobiles need at least 1. as the radio conditions may change between the measurement activation and the reception of the first measurement report with GSM/inter-frequency measurements. Compressed Mode is also possibly activated. There is one single report for both reported quantities Later on. a hard handover is triggered towards the chosen target cell. RRC/ Measurement report (intrafreq meas. As seen on live networks.52 s). the Alarm Measurement criteria is checked again. a blind handover towards the blind GSM cell provisioned for the Primary cell may be performed by the RNC. intersystem meas)) RRC/ Measurement control (start CM) Based on intrafrequency measuremenst and depending on mobile capability.UMTS Radio Mobility Counter meas hit MR Target cell found Full Periodic Mode Wait for Inter Freq/Inter Rat meas HHO processing 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 control (intrafrequency) .06/EN Approved_Standard 17/Sep/2010 Page 194/244 . depending on mobile needs The UE is now able to report both intersystem and intrafrequency measurements. Intrafrequency measurement configuration done in the call setup phase RRC/ Measurement report (intrafreq meas) RRC/ Measurement control (intersystem. the SRNC decides to request intersystem measurements. start CM) RRC/ Measurement report (intrafreq meas.

In UA07.06/EN Approved_Standard 17/Sep/2010 Page 195/244 . This is defined by: • •  NA  QUsed = W ⋅10 ⋅ Log  ∑ Mi   + (1 − W ) ⋅10 ⋅ LogM Best  i =1  • W is set to 0. For CPICH RSCP based event. For CPICH RSCP based event this is set to the value of the parameter cpichRscpThresholdUsedFreq2D. 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. event 6A and 6B are defined as: • For 6A: the UE Tx power is greater than the value in IE "UE Transmitted Power Tx power threshold" stored for this event (parameter UeTxPwrMaxThresholdOffset) • For 6B: the UE Tx power is less than the value in IE "UE Transmitted Power Tx power threshold" stored for this event (parameter UeTxPwrMaxThresholdOffset) Passing on or copying of this document. ALARM MEASUREMENT ACTIVATION WITH EVENT BASED INTRA FREQUENCY MEASUREMENTS DESCRIPTION 6. the configuration of this parameter is set to the value of the parameter cpichRscpThresholdUsedFreq2F which is a hysteresis to cpichRscpThresholdUsedFreq2D. It is based on event 6A and 6B. Qused refers to as the quality of the currently used frequency.1. For CPICH Ec/No based event this is set to the value of the parameter cpichEcNoThresholdUsedFreq2D. so that QUsedn actually refers to as CPICH Ec/No or CPICH RSCP of the best cell in the active set. a solution based on UeTxPower is also introduced.1. 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. This parameter is configurable for each event (the values sent to the UE are defined by the parameters timeToTrigger2D. 2D and 2F are categorized in the ‘inter-frequency” event group. which helps to decrease the number of simultaneous intra-frequency events required.UMTS Radio Mobility Remark 2: In case of handover failure. TUsed2f refers to an absolute threshold. timeToTrigger2F). In order to trigger a report.1. In [A4]. H2d and H2f refer to as hysteresis parameters.1 A solution based on events 2D and 2F will be used. the configuration of this parameter is set to the value of the parameter cpichEcNoThresholdUsedFreq2F which is a hysteresis to cpichEcNoThresholdUsedFreq2D. They can be set to the value of hysteresis2D and hysteresis2F. the triggering condition has to be valid for a period of time named “time to trigger”. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. depending on 2D and 2F “measurement result” configuration. Although being related to intra-frequency measurements. the fact that 2D/2F are only triggered by the “Best” cell of the active set allows to save un-necessary measurement reports. For CPICH Ec/No based event. 6. Besides. In [A4].

06/EN Approved_Standard 17/Sep/2010 Page 196/244 . any of the active set cells may trigger the event): Reporting quantity CPICH RSCP CPICH RSCP CPICH Ec/No CPICH Ec/No UeTxPwr UeTxPwr Event id 2D 2F 2D 2F 6A 6B 6.UMTS Radio Mobility In order to trigger a report. • Or Event 2D and 2F Event 2D and 2F are managed the following way (events 6A and 6B are managed exactly the same way): The algorithm used to trigger alarm measurements will be based on the following principles: Passing on or copying of this document. mobilityServiceType: this parameter defines the mobility service type that matches with each DlUserService. This parameter is configurable for each event (the values sent to the UE are defined by the parameters timeToTrigger6A. there is no “triggering” condition. By default. (dlUserService ---> mobilityserviceType ---> usHoConf).2 ALGORITHM The Alarm criteria may be set by: • Either event 6A and 6B.1. Time To triggers values are not relevant in this figure At the end. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Figure 77: use of Event per Ul Service. It is used as UsHoConf index id. => it’s the DL rab which is taken into account. NB: The measurements configuration (for 6A and 6B triggers) are defined per mobility service type. the list of configured events for alarm handover activation would be as follows (for 2D and 2F.1. the triggering condition has to be valid for a period of time named “time to trigger”. timeToTrigger6B).

A change of primary (event 1D) or Service type received while the timers are running has no effect on the algorithm. the timer timerAlarmHOEvent2D 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. for event confirmation. Alarm criteria is only considered valid once a certain period of time has elapsed without receiving 2F. Passing on or copying of this document.UMTS Radio Mobility • • On reception of 2D event the RNC starts a timer. event 2D may possibly not be reported. Use of event “time to trigger” parameter. In case both quantities (RSCP and Ec/N0) have fulfils their triggering condition. The timer timerAlarmHOEvent6A to confirm alarm handover criteria is started once a 6A event is received. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. as the condition is evaluated over a long period of time Short “Time To trigger” (around 100 to 300ms) allows much faster detection. the timer is stopped if both 2F corresponding events are received (Ec/N0 and RSCP). Alarm measurements are configured. If 2F is received while the timer is running. except the case when the new primary has different thresholds than the previous primary cell in which case the 2C/2D/6A/6B events are modified with the new thresholds.06/EN Approved_Standard 17/Sep/2010 Page 197/244 . In order to avoid un-necessary activation. the timer is stopped. If another subsequent 2D event with another measurement quantity is received. so that the event is only reported once 2D or 2F is valid for a certain period of time. as observed from the field: In case of long “Time To Trigger”. The criteria conditions 2D/2F for both Ec/N0 and RSCP. a time window solution needs to be implemented at the RNC side. If the timer elapses until 2F is received. CPICH Ec/No 2F 2D Long « Time To Trigger » 2D sent 2F 2D HO decision Short « Time To Trigger » Figure 78: influence of short & long time to trigger The figure above illustrates a cell edge case where the measurement quantity fluctuates around 2D and 2F triggering thresholds. Short “Time To Trigger” values are preferred to ensure better network reactivity under alarm conditions As a consequence. The algorithm is the following: • • • 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). The timer timerAlarmHOEvent6A is stopped if a 6B event corresponding to the triggering 6B is received. and 6A/6B are managed simultaneously.

Alarm criteria Confirmation timer time 2D received Inter-frequency or inter-RAT configured Figure 79: Alarm Measurement activation overview MR 2D Timer elapses 2D Event Trigger Mode 2D Timer Wait for Inter Freq/Inter Rat meas time HHO processing Passing on or copying of this document. When inter Freq or Inter Rat periodical measurements are already activated for a given criteria or the other criteria is set. if all alarm criteria previously set become invalid (i. reception of a 2F and/or 6B events) before the alarm measurement results are received. the RNC activates inter Freq or Inter Rat periodical measurements depending on iMCTA provisioning. After inter Freq or Inter Rat measurements are setup due to one criteria (2D or 6A).UMTS Radio Mobility • • • Once the timer timerAlarmHOEvent2D or timerAlarmHOEvent6A elapses.06/EN Approved_Standard 17/Sep/2010 Page 198/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 2F RSCP Yes Timer decision table The alarm measurement activation is illustrated by the following picture: Radio quality Threshold . “Alarm criteria” reflects the RNC decision once the timer has elapsed: Triggering event 2D Ec/No 2D Ec/No 2D Ec/No 2D Ec/No 2D Ec/No 2D Ec/No 2D Ec/No Received while timer is running Timer stopped? No 2F RSCP No 2F Ec/No Yes 2D RSCP No 2D RSCP . As an example.e. no new measurements are requested to the Ue. If one alarm criteria (2D or 6A) are again met a new alarm measurement (inter Freq or Inter Rat based on periodical reporting) will be setup again. 2F RSCP No 2D RSCP . the alarm handover procedure is cancelled and the alarm measurement results will be ignored when received. the complete decision table for 2D CPICH Ec/No triggering event is described hereafter. 2F Ec/No No 2D RSCP . 2F Ec/No .

In such a case. the Alarm Criteria confirmation timer is started again.06/EN Approved_Standard 17/Sep/2010 Page 199/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. a Hard Handover Failure message is sent to the SRNC.UMTS Radio Mobility Hard Handover Failure: If the mobile fails to synchronize to the target resource. Figure 80: Alarm Measurement 2D criteria hit then 6A UE Pwr 6A Thresh. indicating the mobile has returned to the old channel. in order to avoid too frequent handovers. 6B Thresh TT 6A TT 6B UE Tx Pwr time 6A Received 6A Alarm timer started 6B received 6A Alarm timer stopped Figure 81: Alarm Measurement 6A followed by 6B Passing on or copying of this document.

a blind handover towards the blind GSM cell provisioned for the Primary cell may be performed by the RNC. Control Common part (reporting type…) §10. 2F • CPICH RSCP: reported in events 2D.UMTS Radio Mobility If neighbouring measurement cannot be requested to the UE but Inter Rat HHO is allowed (for example: CM not possible with the current RAB.1. inter-frequency events reporting are not repeated. 6B So that three MEASUREMENT CONTROL messages are actually needed to configure inter-frequency events.7. The overall structure of the inter-frequency MEASUREMENT CONTROL message is as follows.17 Meas. When the Alarm HHO fails during preparation –( . 1800ms). As in [A4] specification. In order to limit the risk of loosing an event on the radio interface because of bad transmission conditions.2.for all possible targets – see section 4. in order to delay a new HHO attempt the Alarm confirmation timer is set with the value max (2D timer+TTT2D. three different quantities are actually required: • CPICH Ec/No: reported in events 2D. §10.17 common part: The IE Measurement reporting mode contains the specific information: • Measurement Report Transfer Mode: Acknowledged mode RLC Passing on or copying of this document.2.1. At the timer expiration.3. 2F • UeTxPower: for events 6A.19 Inter-freq meas rep criteria Event 2D Event 2F … Figure 82: inter-frequency Measurement Control message structure In the §10.10. 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). the procedure ends. neighbouring cells filtered after applying IMSI criteria…) or no suitable Alarm measurement is reported by the mobile within a guard timer period. measurements configuration and compressed mode activation are sent to the UE. • If the alarm criterion is not hit anymore.3 CONFIGURATION Regarding inter-frequency measurement.7. 6.16 Inter-freq measurements Common part (meas quantities…) §10. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. all intra-frequency event reports are configured in RLC Acknowledged Mode.3. The behavior is the same for 6A/6B.06/EN Approved_Standard 17/Sep/2010 Page 200/244 .4) or execution phase.

using a hysteresis different than 0. The overall structure of the UE internal measurements MEASUREMENT CONTROL message is as follows. UE internal measurements event reports are configured in RLC Acknowledged Mode. 2D and 2F need to be triggered by different conditions.3.3.21) o For 2D/2F CPICH Ec/No (if measurement quantity is Ec/No) or CPICH RSCP (if the measurement quantity is RSCP) 6.18) • Intra-frequency measurement quantity: “CPICH Ec/No” or “CPICH RSCP” • Measurement quantity for frequency quality estimate: “CPICH Ec/No” or “CPICH RSCP” • Inter-frequency reporting quantity (§10.06/EN Approved_Standard 17/Sep/2010 Page 201/244 .7.1.3.2 2F EVENT CONFIGURATION Need OP MP CV–clause 0 CV–clause 2 MP MP OP OP CV–clause 1 CV–clause 1 Parameter Value “2f” Use cpichEcNoThreshold2F or cpichRscpThreshold2F parameter Use weight2F parameter Use hysteresis2F parameter Use timeToTrigger2F parameter Use maxNbReportedCells2F parameter Not needed Not needed Not needed Information Element/Group name Parameters required for each event >Inter-frequency event identity >Threshold used frequency >W used frequency >Hysteresis >Time to trigger >Reporting cell status >Parameters required for each non-used frequency >>Threshold non used frequency >>W non-used frequency Remark: In order to avoid event ping-pong effect.1.3.7.16 common part: • Inter-frequency measurement quantity (§10.7.1.3.1. This may be achieved through: • Specific 2D and 2F thresholds (as in the tables above) • Same thresholds.UMTS Radio Mobility • Reporting Mode: Event trigger In the §10.1 2D EVENT CONFIGURATION Need OP MP CV–clause 0 CV–clause 2 MP MP OP OP CV–clause 1 CV–clause 1 Parameter Value “2d” Use cpichEcNoThreshold2D or cpichRscpThreshold2D parameter Use weight2D parameter Use hysteresis2D parameter Use timeToTrigger2D parameter Use maxNbReportedCells2D parameter Not needed Not needed Not needed Information Element/Group name Parameters required for each event >Inter-frequency event identity >Threshold used frequency >W used frequency >Hysteresis >Time to trigger >Reporting cell status >Parameters required for each non-used frequency >>Threshold non used frequency >>W non-used frequency 6. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Passing on or copying of this document.

3. 6A and 6B need to be triggered by different conditions. This may be achieved through Specific 6A and 6B thresholds (as in the tables above) .80 UE internal meas rep criteria Event 6A Event 6B … Figure 83:UE internal Measurement Control message structure 6.For UE transmitted power reporting. Control Common part (reporting type…) §10.2. the UE applies a L3 log filtering algorithm.7.1. Passing on or copying of this document.4 6B EVENT CONFIGURATION Need OP Parameter Value “UE Transmitted Power” Information Element/Group name Measurement quantity Filter coefficient OP MP MP MP MP MP UE Transmitted Power UE Rx-Tx time difference UE internal event identity Time to trigger UE Transmitted Power Tx power threshold 3(already defined for Ue Internal measurement in OAM) True False “6B” Use new timeToTrigger6B parameter Use new UeTxPwrMaxThresholdOffset for 6B parameter Remark: .3.77 UE internal measurements Common part (meas quantities…) §10.1.06/EN Approved_Standard 17/Sep/2010 Page 202/244 .1.17 Meas.7.1.In order to avoid event ping-pong effect.3 6A EVENT CONFIGURATION Need OP Parameter Value “UE Transmitted Power” Information Element/Group name Measurement quantity Filter coefficient OP MP MP MP MP MP UE Transmitted Power UE Rx-Tx time difference UE internal event identity Time to trigger UE Transmitted Power Tx power threshold 3(already defined for Ue Internal measurement in OAM) True False “6A” Use new timeToTrigger6A parameter Use new UeTxPwrMaxThresholdOffset for 6A parameter 6.3.3.UMTS Radio Mobility §10. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.

the HHO criteria is hit.06/EN Approved_Standard 17/Sep/2010 Page 203/244 . Used for Alarm handover criteria in event-reporting mode. When the timer elapses before receiving an event 6B. hysteresis for event 2D defines the weight to configure for the triggering of event 2D in Full Event mode 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 Specific CPICH Ec/No threshold specific to event Specific CPICH RSCP threshold specific to event hysteresis for event 2F .1. This timer is started on reception of 2D event. Timer armed by the RNC Activation when it receives 6A Event. This feature doesn't apply to E-DCH calls.UMTS Radio Mobility 6.2 PARAMETERS Object/Class RadioAccessService Class 3 Definition This parameter controls the activation of the feature "Alarm HHO based on UE Tx Power". use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. defines the weight to configure for the triggering of event 2F in Full Event mode Period of time during which the event condition has to be satisfied before sending event 2F Maximum allowed number of cells to report with event 2F Specific CPICH Ec/No threshold specific to event 2F (used as an hysteresis to the corresponding event 2D parameter) Specific CPICH RSCP threshold specific to event 2F (used an hysteresis to the corresponding event 2D parameter) Delta power to be minus to UlUsPowerConf MaxAllowedUlTxPower for event 6A Delta power to be minus to UlUsPowerConf MaxAllowedUlTxPower Name IsAlarmHHOUeTxPwrAllowed timerAlarmHOEvent2D UsHoConf Class3 timerAlarmHOEvent6A UsHoConf Class3 hysteresis2D Weight2D UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 MeasurementConfClass Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 UsHoConf Class3 MeasurementConfClass Class3 UsHoConf Class3 timeToTrigger2D maxNbReportedCells2D cpichEcNoThresholdUsedFreq2D cpichRscpThresholdUsedFreq2D hysteresis2F Weight2F timeToTrigger2F maxNbReportedCells2F cpichEcNoThresholdUsedFreq2F cpichRscpThresholdUsedFreq2F UsHoConf Class3 UeTxPwrMaxThresholdOffset UeTxPwrMaxThresholdOffset UsHoConf FullEventHOConfHhoMgtEvent6A Class3 UsHoConf FullEventHOConfHhoMgtEvent6B Passing on or copying of this document.

When an update of the neighbour list has to be sent to the UE. When Intra Frequency measurements configuration is event type and only one of both. The reporting period is 500 milliseconds. please refer to the section 5. Inter Frequency and GSM InterSystem measurements are used. the UE is requested to report up to 6 neighbouring cells amongst the monitored set. this might increase the risk of handover failure) L3 filtering is applied in the UE for each measurement. No additional filtering is applied by the SRNC. Inter Frequency or GSM Inter-System measurements are used. The list of neighbour cells to be monitored is given by the iMCTA function. For that purpose. then the Inter Frequency measurement is configured as main measurement in periodic mode and the GSM measurement is configured as additional measurement of the Inter Frequency measurement. When Intra Frequency measurements configuration is event type and both.2. 6.3 CONFIGURATION FOR INTER-SYSTEM MEASUREMENTS The SRNC requests the following quantities to be reported by the mobiles: • GSM Carrier RSSI: Received Signal Strength Indicator on a GSM BCCH carrier • Observed time difference to GSM cell (for observation only) • Verified BSIC (this option is required to avoid the mobile reporting GSM measurement for which the BSIC is not identified.2 REPORTED CELLS In this release. depending on the GSM reuse pattern and the radio condition. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 6. Passing on or copying of this document.2. it only includes the cells to be removed and to be added (delta between the previous neighbouring and the new neighbouring). The monitored set is defined as the set of inter-frequency or GSM neighbours of the primary cell and is provided to the UE through a MEASUREMENT CONTROL message first time the measurement condition is fulfilled and on modification of monitored set. a specific value of “filter coefficient” is provided for RSSI quantity. All the measured quantities will be reported by the mobile in the same measurement report message (Inter frequency/GSM Inter-System are additional measurements) when Intra Frequency measurements configuration is periodic. Otherwise. MEASUREMENTS CONFIGURATION FOR INTER-FREQ/2G INTER-RAT MEASUREMENT REPORTING 6.1 Periodic reporting is used in this version for Inter Frequency/GSM Inter-System measurements.2. then the measurement is configured as main measurement configuration in periodic mode. as a configuration parameter.5).UMTS Radio Mobility Class3 UsHoConf Class3 UsHoConf Class3 for event 6B Time To trigger timer value attached to the event 6A Time To trigger timer value attached to the event 6B timetoTrigger6A timetoTrigger6B 6.4. The 6 cells may be either inter-frequency or GSM inter-system neighbouring cells. as specified in [A4]. For more details on the primary cell determination.2. The neighbor cells are selected among the neighboring cells of the primary cell and/or other active set cells (refer to § 5.06/EN Approved_Standard 17/Sep/2010 Page 204/244 .3. and as described in the section 6.

UMTS Radio Mobility

The inter-RAT cell info indication IE supported by R5 UE is managed by the S-RNC. When the inter-RAT cells list changes (e.g. due to a primary cell change or OAM modification), the SRNC increments the value of this IE present in the RRC Measurement Control message. When receiving inter rat measurements from the UE, the RNC uses the inter-RAT cell info indication IE present in the RRC Measurement Report by associating it with the correct configuration.

6.2.4

CONFIGURATION FOR INTER-FREQUENCY MEASUREMENTS

The SRNC requests the following quantities to be reported by the mobiles: • CPICH Ec/No • CPICH RSCP L3 filtering is applied in the UE for each measurement, as specified in 25.331, and as described in section 6.3. For that purpose, a specific value of “filter coefficient” is provided for RSSI quantity, as a configuration parameter. No additional filtering is applied by the SRNC.

6.2.5

CHANGE OF MEASUREMENT TYPE

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. In this case the ongoing measurement is continued and if the UE reports a valid target cell, then the handover is executed. The new measurement type is taken into account for next iMCTA trigger evaluation.

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 205/244

UMTS Radio Mobility

6.2.6
6.2.6.1

PARAMETERS FOR MEASUREMENT
MEASUREMENT ACTIVATION PARAMETERS

The following parameters are used when the HHO reason is an alarm reason.
Name cpichEcNoThreshold Object/Class FastAlarmHardHoConf per UsHoConf Class 3 FastAlarmHardHoConf per UsHoConf Class 3 FastAlarmHardHoConf per UsHoConf Class 3 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

cpichRscpThreshold

counter

StepDown

fastAlarmHHOTimeFilter per UsHoConf Class 3

StepUp

fastAlarmHHOTimeFilter per UsHoConf Class 3

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 206/244

UMTS Radio Mobility

6.2.6.2

OTHER PARAMETERS

The following parameters are used whatever the HHO reason.
Name interFreqFilterCoeff rrcGsmMeasurementFilterCoefficient rrcIntraFreqMeasurementFilterCoeff isBlindHoRescueAllowed Object/Class InterFreqMeasConf Class3 RRCMeasurement Class3 RRCMeasurement Class3 RadioAccessService Class3 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.

measurementGuardTimer2g

measurementGuardTimerFdd

RadioAccessService Class 3

6.3. 6.3.1
6.3.1.1

INTRA-FREQUENCY MEASUREMENTS CONFIGURATION
ACTIVATION/DEACTIVATION

Intra-frequency measurements are activated for all mobiles at the transition to CELL_DCH RRC state (e.g. call establishment or CELL_FACH to CELL_DCH transition after always on upsize…), through the MEASUREMENT CONTROL message, or via SIB11/SIB12 configuration. Intra-frequency measurements are never deactivated, unless the mobile-network RRC connection is released (e.g. at the end of the call) The events (6A, 6B) are configured if the following conditions are fulfilled: the feature “HHO based on UE Tx power” is activate at OAM level (parameter isAlarmHhoUeTxPwrAllowed); the feature is allowed at OAM level for the Service in progress; if the call only uses DCH transports for uplink. The feature applies for Multi Rab call using DCH transport.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 207/244

UMTS Radio Mobility
When the call leaves this transport type towards E-DCH transport, a SRLR is processed with an update of the measurements: the event 6A and 6B are de-configured. If the RNC receives during the transition an event 6A or 6B, they are discarded except if the HHO criterion was hit before the SRLR. When the call moves again towards DCH Ul transports, a SRLR is processed with an update of the measurements: 6A and 6B are configured if the condition given above allows it.

6.3.1.2

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.

6.3.1.3

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.

6.3.1.4

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

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 208/244

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 ) ⋅ Fn −1 + a ⋅ M n with: • Fn is the updated filtered measurement result • Fn-1 is the old filtered measurement result.3. 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. mobile limitation. too.Based on traces the neighbouring provisioning may be modified. used with a minimal coefficient in computations. N-1) – missedPenalty (there exists one penalty value for each CPICH RSCP and Ec/No reporting quantity) Note: A similar algorithm is applied to inter-frequency and 2G inter-RAT measurements. This process only applies to intra-frequency measurements. The algorithm is as follows: Let’s call (cell. A specific value of k is provided for each of the measurement quantities.UMTS Radio Mobility Note: If Detected Set cells are reported the RNC will trace this as specified in [R5]. 6. When possible and activated. Penalty coefficient which is subtracted to the last received CPICH Ec/N0 missedEcNoMeasurementPenalty MissingMeasurement Class3 Passing on or copying of this document. • a = 1/2(k/2).3. The corresponding parameters are: Name maxAllowedNumber Object/Class MissingMeasurement Class3 Definition Maximum number of allowed missing measurements in the message RRC Measurement Report for a cell of the monitored set. as an operator parameter. the RNC implement a specific process in order to cope with missing measurements for a given cell. If k is set to 0 that will mean no layer 3 filtering.2 MISSING MEASUREMENTS When periodic measurements are reported.g. • else.3).N) the missing measurement: • the counter of consecutive missing measurements for this cell is incremented • if the counter value is above maxAllowedNumber.06/EN Approved_Standard 17/Sep/2010 Page 209/244 .1. where k is the parameter received in the IE "Filter coefficient" in the Measurement Control message and in SIB11/SIB12 (if used).4.331. for cells being part of the active set. The reason for this may be e. No additional filtering is applied by the SRNC. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. In order to initialise the averaging filter.3. This until the measurement is received again. detected cells can be added to the active set (refer to § 5. 6. or radio interface variation which may cause a cell not be reported for some period of time. the measurement for this cell is replaced by a minimal default value. the measurement is substituted by quantity (cell.5 FILTERING As specified in 25.

the mobile indicates if compressed mode is needed in either UL or DL for the following modes: • FDD • GSM450 • GSM480 • GSM850 • GSM900P • GSM900E • GSM900R • GSM1800 • GSM1900 Passing on or copying of this document.06/EN Approved_Standard 17/Sep/2010 Page 210/244 . Penalty coefficient which is subtracted to the last received CPICH RSCP measurement to replace a missing one. missedRscpMeasurementPenalty MissingMeasurement Class3 6. 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. Any transmission interruption time. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. provided in the RRC CONNECTION SETUP COMPLETE message..1 COMPRESSED MODE INTRODUCTION The compressed mode is used to allow a UE in FDD in dedicated mode to make measurements on a UTRA cell (either FDD or TDD) or on another Radio Access Technology (RAT). for short amounts of time (less than one 10 ms radio frame) in a regular manner to allow the mobile to perform the requested measurements.. This information element is sent on network request ("GSM capability required" indication in the RRC Connection Setup message sent from the network). The compressed mode involves interrupting the transmission in the uplink or downlink. without discrimination. may be contained within one radio frame or span the boundary between two radio frames such that the transmission gap does not exceed half of the period of any one radio frame (10 ms).UMTS Radio Mobility measurement to replace a missing one. Figure 84: Retrieving UE capability In the UE Radio Access capability.4. Measurement on a UTRA FDD cell is referred to as inter-frequency measurement and measurement on a UTRA TDD cell or a GSM cells is referred to as intersystem measurement. 6.4. In this version of the document • compressed mode is either used when needed for GSM and/or FDD inter-frequency measurements • compressed mode is used for all kind of CS or PS services.4. 6. called a transmission gap. RNC . or possibly both at the same time.2 UE CAPABILITY The real need for compressed mode is indicated by the mobile in the UE Radio Access Capability information element. as part of the handover preparation. such as GSM.

This method is applicable to both UL and DL. 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. • SF reduction: the spreading factor of the compressed radio frames is divided by two. and for which direction. it is explained that compressed mode configuration is done very early in the call process. 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. in order not to configure compressed mode in every case. and as specified in 3GPP documents. This implies that the transport channel can cope with some transmission delay. Passing on or copying of this document.4. for GSM or FDD inter-frequency measurements. Regarding compressed mode for GSM.4.06/EN Approved_Standard 17/Sep/2010 Page 211/244 . 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. • the mobility between these bands except between band I and band II. allowing the same number of bits to be sent in a smaller amount of time. This is a DL only method. 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. Therefore this method is not applicable to conversational services. The use of the SF/2 reduction method has an impact on the Scrambling and OVSF code used. Therefore. NOTE: puncturing method removed from 3GPP since R5. This method is applicable to both UL and DL.8). This is further detailed in the chapter about "impacts on RRM" (see 6. 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. The UTRAN supports: • all FDD R7 frequency bands except the band IV. 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". • Higher Layer Scheduling: transmission gaps are created by restricting the TFC in the TFCS. 6.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.UMTS Radio Mobility All FDD R7 frequency bands capabilities are used by the RNC. • Inter Rat handover from/towards theses bands. or possibly both.e. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. and that compressed mode is only activated when needed.

the network shall configure as many pattern sequences as measurement quantities to be reported by the mobile. and maintain timing information with the identified cells.1 GSM MEASUREMENTS Regarding GSM measurements. In principle. In case of HSDPA or HSUPA calls. • The "BSIC re-confirmation process" can be seen as a sort of endless loop.133. The defined measurement purposes are applicable whatever the compressed mode method is (SF/2. each pattern sequence is dedicated to a certain measurement quantity. each of them being associated to a measurement purpose. the compressed mode method only applies to the DCH part of the call. Passing on or copying of this document. as specified in 25. A sequence may have a finite or infinite value depending on the TGPRC parameter. • The mobile is provided with GSM neighbouring cell list. The same CM pattern definition is used whatever the method is. intending to identify the 8 strongest cells. 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. contained in the Measurement Control RRC message. HLS). intending to re-confirm identified BSIC. • The "Initial BSIC identification process" intends to identify the BSIC in the list.4. The pattern information are used to generate gaps in the HSDPA and HSUPA part of the call.4. • The "RSSI measurement process" can be seen as a sort of endless loop. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. as in the figure below.4 MEASUREMENT PURPOSE Compressed mode makes use of pattern sequences. so that. #1 TG pattern 1 #2 TG pattern 2 #3 TG pattern 1 #4 TG pattern 2 #5 TG pattern 1 #TGPRC TG pattern 2 TG pattern 1 TG pattern 2 Transmission Transmission gap 1 Transmission gap 2 Transmission gap 1 gap 2 TGSN TGL1 TGD TGPL1 TGL2 TGSN TGL1 TGD TGPL2 TGL2 Figure 85: Compressed Mode pattern sequence overview 6.UMTS Radio Mobility 6. there may be up to 3 pattern sequences needed.06/EN Approved_Standard 17/Sep/2010 Page 212/244 . the BSIC is given to the re-confirmation process.4. Once being successfully identified. A pattern sequence is composed of 2 pre-defined patterns (pattern 1 and pattern 2) being used alternatively. the following figure presents an overall view of compressed mode processes for GSM in the mobile.

4.e. CFN +x BSIC Identification Passing on or copying of this document.2 FDD INTER-FREQUENCY MEASUREMENTS Regarding FDD inter-frequency measurements. the pattern for BSIC identification is only started once the pattern for RSSI is over).4. An example for such a configuration is presented in the figure below: x frames y frames . BCCH ARFCN) GSM neigh..UMTS Radio Mobility Measurement Control (BSIC. only one pattern sequence is needed as there is only one "measurement purpose": • FDD measurement 6.cells RSSI measurement process 8 strongest cells Initial BSIC ID process up to 8 identified cells BSIC re-confirmation process Measurement Report identification failed re-confirmation failed Figure 86: UE process overview for GSM measurements 6.. and are not running in parallel (i..5.: TGPRC=1 to 511). CFN RSSI .06/EN Approved_Standard 17/Sep/2010 Page 213/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.e. Alcatel-Lucent UTRAN implements 2 finite length patterns: • one for GSM RSSI measurements • one for BSIC identification No pattern sequence for "BSIC reconfirmation" will be activated.1 PATTERN SHAPE GSM MEASUREMENTS In this version. for GSM measurements.4.4. The 2 patterns have finite duration (i.5 6..

when the iMCTA function needs measurement for HHO processing for Alarm.4. as in the figure below. e.1 PROCEDURES & MESSAGES DATA FLOW The principle is that compressed mode configuration and activation/de-activation are done in different phases: • configuration is performed at initial DTCH Radio Link setup/addition/reconfiguration (i. a different DPCH slot format is used compared to normal mode. the mobile should normally attempt to identify the 8 strongest RSSI.06/EN Approved_Standard 17/Sep/2010 Page 214/244 .g. 6. Alcatel-Lucent UTRAN implements a finite length pattern. for FDD inter-frequency measurements. using the relevant pattern sequence.2 “Dedicated downlink physical channels”. A reconfiguration of the compressed mode may occur when a CM method change is needed.7 6. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.4. The selection between them is dependent on the used method: DL Slot format B shall be used in frames compressed by SF reduction. due to additional RAB setup or RAB deletion.2 FDD INTER-FREQUENCY MEASUREMENTS In this version. CFN FDD measurement Figure 88: Pattern sequence for FDD measurements Please refer to the chapter on [parameters] for the pattern parameters supported in this version. CAC or Service reason. when the RAB ASSIGNMENT REQUEST message is received from the Core Network).UMTS Radio Mobility Figure 87: Pattern sequences for GSM measurements Once RSSI measurements are performed. DL Slot format A shall be used in frames compressed by HLS.7.3. • activation/deactivation is based on a separate criteria.211 section 5.5. x frames . i. in compressed frames.e.4. Frame structure type A and Type B shall be supported by the UTRAN.e. 6. the network may possibly make a handover decision toward a GSM target. There are two possible compressed slot formats (labeled A & B).. 6. Please refer to the chapter on [parameters] for the pattern parameters supported in this version.4.6 SLOT FORMATS/ FRAME STRUCTURE According to 25.. Same Transmission gap position calculation used for SF/2 and for HLS compressed mode method. Passing on or copying of this document. Once BSIC have been identified and reported to the network.

starting CFN) Figure 89: Compressed Mode activation Note: "The 3GPP indicates the UE behaviour is unknown when the RNC asks to stop a compressed mode pattern when it is not yet started (CFN not passed).33 RB Setup • 10.2 RRC/RB SETUP MESSAGE This message contains the CM configuration. CM config for FDD) NBAP/ Radio Link Reconfiguration Response NBAP/ Radio Link Reconfiguration Commit (no pattern active) RRC/ RB Setup (DTCH config. CM config for GSM. starting CFN) RRC/ Measurement Control (active pattern. which will be possibly be activated by the RNC when the criteria is reached. starting CFN) RRC/ Measurement Control (active pattern." 6.UMTS Radio Mobility UE Node B Initial RRC connection DCCH establishment Initial UE DTAP message RANAP/ RAB Assignment Request NBAP/ Radio Link Reconfiguration Prepare (DTCH config.6. It contains the following information: • 10.33 DPCH compressed mode info TGPSI TGPS Status Flag TGCFN TGMP TGPRC TGSN Passing on or copying of this document. starting CFN) Criteria is reached => CM re-activation NBAP/ Compressed Mode Command (active pattern.7. The RNC follows this rule.6.2.3.06/EN Approved_Standard 17/Sep/2010 Page 215/244 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. CM config for FDD) RRC/ RB Setup Complete RANAP/ RAB Assignment Response Criteria is reached => CM activation RNC MSC-CS NBAP/ Compressed Mode Command (active pattern.24 Downlink information common for all radio links • 10.4.3. CM config for GSM.

7.4.2.4.17 Measurement Control • 10. • 9.57 UL DPCCH Slot Format 9.53A Transmission Gap Pattern Sequence Information TGPSI TGSN Passing on or copying of this document.53B Transmission Gap Pattern Sequence Code Information Scrambling code change • • • 9.1.6.7.14A DL code information • 9.5 NBAP/RADIO LINK RECONFIGURATION PREPARE MESSAGE This message is used by the RNC to configure the compressed mode sequences to be used at the BTS.6. 6.2.10 DL DPCH Slot Format 9.2.3.2.2.7.2.3 RRC/RB RECONFIGURATION MESSAGE This message is used to reconfigure the compressed mode (used to change the method).3.3.42 Radio Link Reconfiguration Prepare • 9.27 Downlink information for each radio link • 10.2.06/EN Approved_Standard 17/Sep/2010 Page 216/244 .2.2. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.2.4.2.6.4 RRC/MEASUREMENT CONTROL MESSAGE This message is used to trigger/stop compressed mode pattern sequences. • 10.34 DPCH compressed mode status info TGPSI TGPS Status Flag TGCFN 6.21 Downlink DPCH info for each RL Scrambling code change 6. The same IEs are used as for initial CM configuration in RB Setup message – see above.UMTS Radio Mobility TGL1 TGL2 TGD TGPL1 TGPL2 RPP ITP UL/DL mode Downlink compressed mode method Uplink compressed mode method Downlink frame type DeltaSIR1 DeltaSIRafter1 DeltaSIR2 DeltaSIRafter2 N Identify abort T Reconfirm abort • 10.2.

<maxTGPS> M M M Type and reference CFN group present (range > 0) IE/Group Name CM Configuration Change CFN Transmission Gap Pattern Sequence Status >TGPSI Identifier >TGPRC >TGCFN CFN • CM deactivation Presence M Range Type and reference CFN IE/Group Name CM Configuration Change CFN 6.1.2.1 Radio Link Setup Request or 9.4.1.1.4.2. • 9. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.e. The main difference with equivalent message used on the Iub interface (NBAP Radio Link Reconfiguration Prepare message) is that the "code information" (i. Aside from this very specific point.6 Radio Link Addition Request • 9.7. 6.A Active Pattern Sequence Information Same structure as § above.7.A Active Pattern Sequence Information • CM activation Presence M Range 0. so that the choice is left to the DRNC.2.2.UMTS Radio Mobility TGL1 TGL2 TGD TGPL1 TGPL2 UL/DL mode Downlink compressed mode method Uplink compressed mode method Downlink frame type DeltaSIR1 DeltaSIRafter1 DeltaSIR2 DeltaSIRafter2 6.7 NBAP/RADIO LINK RECONFIGURATION COMMIT MESSAGE This message is used to trigger/stop compressed mode pattern sequences.2.2. the DRNC applies the same configuration as the SRNC in terms of pattern definition and Power control.60 Compressed Mode Command • 9.8 RNSAP/RADIO LINK SETUP/ADDITION REQUEST MESSAGE This message is used in case of inter-RNC soft handover..1.6 NBAP/COMPRESSED MODE COMMAND MESSAGE This message is used to trigger/stop compressed mode pattern sequences. • 9.4.3. • 9.60 Compressed Mode Command • 9.06/EN Approved_Standard 17/Sep/2010 Page 217/244 .7. whether or not the alternate scrambling is used) is not indicated in the RNSAP.A Active Pattern Sequence Information Passing on or copying of this document.

7. Alcatel-Lucent UTRAN is using the alternate scrambling method. either the 1st or the 2nd alternate is used: • if (n<SF/2).2: • SC+8192 • SC+16384 Depending on the position of the OVSF code Cch.SF. 6. Its format is equivalent to the message used on the Iub. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.4. § 5.7. For DL transmission in uncompressed frames.2.SF/2. 6.4.1.n For DL transmission in compressed frames.9 RNSAP/COMPRESSED MODE COMMAND MESSAGE This message is used to trigger/stop compressed mode pattern sequences. the network is using • scrambling code SC • OVSF code Cch.SF.06/EN Approved_Standard 17/Sep/2010 Page 218/244 . Its format is equivalent to the message used on the Iub.n mod SF/2 Passing on or copying of this document.47A Transmission Gap Pattern Sequence Information TGPSI TGSN TGL1 TGL2 TGD TGPL1 TGPL2 UL/DL mode Downlink compressed mode method Uplink compressed mode method Downlink frame type DeltaSIR1 DeltaSIRafter1 DeltaSIR2 DeltaSIRafter2 6.4. SC+16384 is used In both cases.2.8 6.1 IMPACTS ON RRM SPECIFIC FOR SF/2 METHOD CODE TREE MANAGEMENT The use of the SF reduction method has some impacts on the Scrambling and OVSF code used for the transmission. as specified in 25.2 and 5.8.UMTS Radio Mobility TGPSI TGCFN TGPRC • 9.213. the OVSF code which is used for compressed frames is Cch. which makes use of 2 additional scrambling codes.2.4.10 RNSAP/RADIO LINK RECONFIGURATION COMMIT MESSAGE This message is used to trigger/stop compressed mode pattern sequences. These impacts are described in what follows.n in the code tree. SC+8192 is used • if (n>=SF/2).

compressed mode by HLS is used for UL/DL PS I/B mono/multi services over DCH. 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. compressed mode by HLS is used for UL/DL multiplexed PS I/B services over DCH. compressed mode by SF/2 reduction method is possible for both UL and DL whenever GSM or FDD interfrequency measurements is used. In downlink SF/2 method is available. Passing on or copying of this document. only.4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. only. 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 DCH RB with uplink SF=4 obviously. compressed mode by HLS is also used for certain multiplexed PS I/B + CS services – see below.e. 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 compressed mode by SF/2 reduction may be used for all kind of CS or PS services.UMTS Radio Mobility Scrambling code = SC LEFT case Scrambling code = SC +8192 SF-1 SF/2 0 SF-1 SF/2 0 Scrambling code = SC Scrambling code = SC +16384 RIGHT case SF-1 SF/2 0 SF-1 SF/2 0 Figure 90: Alternate scrambling code usage Due to the fact that alternate scrambling are used: • the code tree allocation algorithm which was defined in earlier product versions is kept unchanged • there is no OVSF code blocking issue due to the use of compressed mode in UTRAN 6. I.9 HLS [USA Market: HLS method is supported in uplink.] This chapter describes the Compressed Mode by HLS over dedicated physical channel. dependent on the uplink bearer combination SF/2 or HLS can be used.06/EN Approved_Standard 17/Sep/2010 Page 219/244 .

1 HLS ASSUMPTIONS In most of the cases. while other require the compressed mode to be activated either in UL or DL only or in both UL and DL. the max ratio of compressed frames is 2/3. same UE capabilities filtering algorithm is applied. the ratio is 1/3 in case of single 2G or 3G measurement and 2/3 in case of simultaneous 2G and 3G measurement. for a DL transmission with TTI = 10ms.9. assuming that the CM pattern configuration is as described in section. 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 When compressed mode is activated. 3GPP baseline is R6 UE capability o Any UE is supposed to support HLS (3GPP mandatory feature for UE) o Some UEs do not require compressed mode to perform their inter-frequency or inter-RAT measurements.g. 6.5. o UE capability analysis performed by the RNC is not impacted by the introduction of the HLS compressed mode. With the current CM pattern. Only the PS I/B TF(s)/TFC(s) are restricted during transmission with gap. Passing on or copying of this document. o HLS can be applied to SRB + PS Streaming + PS I/B provided the streaming GBR while compressed frames is guaranteed. Compressed mode (SF/2) is active with HSDPA. 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.4.06/EN Approved_Standard 17/Sep/2010 Page 220/244 . o Some TF/s on PS RAB only are forbidden for TTIs where transmission with gap is performed o E.4. 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. 6.UMTS Radio Mobility 6. as per [25. refer to §6. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 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.5. as a consequence the associated DCH (ie SRB only) uses SF/2 for any such configuration.4. o HLS is supported for multiplexed PS I/B x/y calls with x/y > 8 Kbps.4. slot format A applies to compressed mode by HLS whereas slot format B applies to compressed mode by SF reduction Transmission over DL DCH shall be optimized while CM by HLS is active: o As per 3GPP spec.2 HLS GAP PATTERN CONFIGURATION Compressed Mode configuration management: o The same CM patterns will be used for both HLS & SF/2 methods. CMode method only applies to the DCH part of a call and not to HS-DSCH.211]. 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. TFS reduction will only apply during 2 or 4 TTIs every 6 TTIs.9. 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.

9. Whenever a CM method change occurs in UL or DL or both the following applies: o While SRLR the previous CM method is deactivated at CFN#1.e. HLS would apply in the UL direction.4. while the SF/2 method would apply in the DL direction. => For the specific case where the PS I/B would be supported by UL DCH / HS-DSCH transport channels. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.UMTS Radio Mobility 6.3 SWITCHING BETWEEN COMPRESSED MODE METHODS The system shall be able to switch to the most appropriate method after a RAB combination modification. Hereafter the impacted RRC/NBAP/RNSAP messages used on the different transition use cases below: o NBAP/RNSAP RL SETUP Request (RBs + CM parameters) // CM configuration provisioning // + start CM at TGCFN time o NBAP/RNSAP RL RECONFIGURATION PREPARE (RBs + CM parameters) // CM configuration provisioning o NBAP/RNSAP RL RECONFIGURATION COMMIT () // + start CM at TGCFN or CFN time o NBAP/RNSAP COMPRESSED MODE COMMAND () // stop CM configuration change // CFN time o RRC RADIO BEARER SETUP (RBs + CM parameters) // at TGCFN time for each // TGPSI // CM configuration provisioning // start CM at TGCFN or CFN time // configuration + Start/Stop CM o RRC RADIO BEARER RECONFIGURATION (RBs + CM parameters) // configuration + Start/Stop CM // at TGCFN time for each TGPSI o RRC MEASUREMENT CONTROL () // for each TGPSI // Start/Stop CM at TGCFN time Passing on or copying of this document. o When SRLR ends the new CM method is configured and activated at the CFN#2 time.06/EN Approved_Standard 17/Sep/2010 Page 221/244 . i.

starting CFN : TGCFN time ) NodeB compares the CFN of DL FP DCH frames to TGCFN to trigger CM activation RNC MSC-CS RANAP/ RAB Assignment Request 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 config for GSM. CM config for FDD) RRC/ RB Setup/reconf/Release Complete RANAP/ RAB Assignment Response 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 NBAP/ Compressed Mode Command (active pattern. for FDD) RANAP/ RAB Assignment Response Passing on or copying of this document. CM config for GSM. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. starting CFN : TGCFN time ) RRC/ Measurement Control (active pattern. for FDD.06/EN Approved_Standard 17/Sep/2010 Page 222/244 . CM activation at new CFN: TGCFN time ) RRC/ RB Reconfiguration complete (DTCH config.UMTS Radio Mobility Switching between Compressed Mode methods use cases Compressed method switching while CM active: See call flow diagram below: UE Node B Initial RRC connection DCCH establishment Initial UE DTAP message RANAP/ RAB Assignment Request NBAP/ Radio Link Reconfiguration Prepare ((DTCH config. New CM configuration/method) NBAP/ Radio Link Reconfiguration Response New CM Method activation: Determination of the activation time (new CFN) CM activation command to RNC MAC-d CM activation command to the Node B/UE NBAP/ Radio Link Reconfiguration commit (CM activation at new CFN: TGCFN time ) RRC/ RB Reconfiguration (DTCH config. 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. CM config for FDD) NBAP/ Radio Link Reconfiguration Response NBAP/ Radio Link Reconfiguration Commit (no pattern active) RRC/ RB Setup/Reconfiguration/Release (DTCH config. New CM configuration/method.

CM config for FDD) RRC/ RB Setup/reconf/Release Complete RANAP/ RAB Assignment Response 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 NBAP/ Compressed Mode Command (active pattern.9. starting CFN : TGCFN time ) NodeB compares the CFN of DL FP DCH frames to TGCFN to trigger CM activation RRC/ Measurement Control (active pattern. RANAP/ RAB Assignment Request RB configuration change => CM method switching: RNC detects the CM method change CM was not activated NBAP/ Radio Link Reconfiguration Prepare (DTCH config.SF/2 is the default CM method applicable to all CS NB/WB + PS streaming RB(s) on DCH Passing on or copying of this document.4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.SF/2 is the default CM method applicable to all PS streaming mono RB on DCH excepted when SF equal 4 C .SF/2 is the default CM method applicable to all CS NB/WB/CSD mono RB on DCH B .UMTS Radio Mobility Compressed method switching while CM not active: See call flow diagram below: UE Node B Initial RRC connection DCCH establishment Initial UE DTAP message RANAP/ RAB Assignment Request NBAP/ Radio Link Reconfiguration Prepare ((DTCH config. CM config for GSM. for FDD) RANAP/ RAB Assignment Response New CM Method activation when HHO criteria will be reached: Determination of the activation time (new CFN) CM activation command to RNC MAC-d CM activation command to the Node B/UE 6. New CM configuration/method. New CM configuration/method) NBAP/ Radio Link Reconfiguration Response NBAP/ Radio Link Reconfiguration commit ( no Pattern active) RRC/ RB Reconfiguration (DTCH config. CM config for GSM.4 • CM METHOD SELECTION RULES: SF/2 selection method rules: A . no pattern active ) RRC/ RB Reconfiguration complete (DTCH config. starting CFN : TGCFN time ) RNC MSC-CS CM ends normally at a finite time. CM config for FDD) NBAP/ Radio Link Reconfiguration Response NBAP/ Radio Link Reconfiguration Commit (no pattern active) RRC/ RB Setup/Reconfiguration/Release (DTCH config. for FDD.06/EN Approved_Standard 17/Sep/2010 Page 223/244 .

SF/2 is the default CM method applicable to all CS NB/WB + PS streaming RB(s) + I/B on DCH E .10 SRNS RELOCATION Interaction with SRNS relocation (UE not involved).HLS is the default CM method applicable to PS I/B x/y + PS Streaming u/p RB over DCH.SF/2 is the default CM method applicable to SRB Standalone combination • HLS selection method rules: A . HLS is the default CM method applicable to multiple CS NB/WB PS I/B x/y + PS Streaming u/p RB over DCH only for x/y >= 64 and (u/p > 64 and u/p <384Kbps). with x/2 & y/2 > 64 Kbps D . with SF = 4.HLS is the default CM method applicable to all CS NB/WB + PS I/B x/y combination on DCH.UMTS Radio Mobility D . o To downgrade the granted rate of that RB combination with a greater SF 6.SRB + CS Streaming u/v + PS I/B x/y o for cases the allocated Ul/DlAsConf supports SRB max rate + u/v + x/y. Passing on or copying of this document.06/EN Approved_Standard 17/Sep/2010 Page 224/244 . with SF = 4.HLS is the default CM method applicable to CS NB/WB PS I/B x/y + PS Streaming u/p RB over DCH. with x/2 & y/2 ≥ SRB max rate + AMR max rate (excepted for CS NB/WB + PS I/B 8/16 Kbps) C . with x/2 & y/2 ≥ SRB max rate + u/v kbps – and x/2 & y/2 ≥ GBR only the TFS for PS I/B are restricted during transmission with gap G .HLS is the default CM method applicable to PS I/B x/y mono/multiplexed RB on DCH. and x/y ≥ GBR F . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. excepted for I/B 8 Kbps B . HLS is the default CM method applicable to multiple PS I/B x/y + PS Streaming u/p RB over DCH only for x/y >= 64 and (u/p > 64 and u/p <384Kbps).SF/2 is the default CM method applicable to multiple PS I/B x/y + PS Streaming u/p RB over DCH excepted for rates with x/y >= 64 and u/p >= 64 Kbps G .SF/2 is the default CM method applicable to all combinations including a RB over HSDPA/HSUPA F . and x/y ≥ GBR E .RB combination SF 4 based: HLS is the default CM method applicable to any RB combination if defined with a SF equal to 4 Note: 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.4.HLS is the default CM method applicable to all CSD 64 + PS I/B x/y mono/multiplexed RB over DCH.

use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.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). There is no dynamical compressed mode configuration. 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.UMTS Radio Mobility . in order to reduce some undecoded radio frame. then: 1.06/EN Approved_Standard 17/Sep/2010 Page 225/244 . Passing on or copying of this document. The Target RNC shall stop the current CM at the UE/NodeB side for any active TGPS at the CM configuration CFN time. since it may generate call drops. The target RNC is configured with its MIB compressed mode configuration/CM prefered method. 2. Note: Sending the RRC measurement Ctrl to deactivate the initial compressed mode ensure a correct deactivation on UE side . 3.

starting TGCFN) RRC/ Measurement Control (active pattern.06/EN Approved_Standard 17/Sep/2010 Page 226/244 .UMTS Radio Mobility UE Node B Target RNC Source RNC Target SGSN Initial RRC connection DCCH establishment 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.The SRNC does not need to apply any particular action on its Iur interface.New parameter required in the NeighbouringRNC MO: IsHlsCmAllowedOnDRNC to be set to false when a SRNC faces a DRNC not supporting the HLS methods otherwise it is set to “true”. CM config for FDD. 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). • UA06. starting CFN= TGCFN) 6. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. 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. 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.0 SRNC facing an oldest DRNC version: . CM config for GSM.4. CM config for GSM.11 RNS INTER-RELEASE COMPATIBILITY USE CASES 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). 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. o While CM activation: 1) When SRNC facing an oldest DRNC version and if the CM method in use is SF/2: .

Same case as 2) but without CM deactivation.CM activation is blocked while call has RB combination with SF=4. follow on of the CM method/configuration with the same TGPS. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. o Without CM activation: 3) When SRNC facing an oldest DRNC version and if the CM method to be used is SF/2: . Inter-freq/inter-RAT HHO cannot be triggered as long as call has RB combination with SF=4. SRNC shall apply a CM method switching from the HLS method to the SF/2 method in UL and/or DL before to transmit any RNSAP RL Setup/reconfiguration message.For any RB combination to be supported on the SRNC/DRNC and the SF of the established combination is not equal to SF4: .For any RB combination to be supported on the SRNC and DRNC and the SF of the current combination is equal to SF4: . refer to the CM method switching procedure described above. HHO is never processed whatever the reason of the handover. Passing on or copying of this document. . See hereafter the call flow for that use case.06/EN Approved_Standard 17/Sep/2010 Page 227/244 .No additional action.In spite of a SF/2 CM method cannot be applied to a RB with an SF4.If IsHlsCmAllowedOnDRNC is equal to “false” then . .UMTS Radio Mobility . If HHO reason was alarm HHO 3G2G may be processed in blind mode (if allowed) at next Alarm condition.SRNC shall apply a CM method switching from the HLS method to the SF/2 method in UL and/or DL before to transmit any RNSAP RL Setup/reconfiguration message. to the DRNC 4) When SRNC facing an oldest DRNC version and if the CM method in used is HLS: . refer to the CM method switching procedure described above.

CM activation at new CFN= TGCFN time ) RRC/RB Reconfiguration complete (DTCH config. TGCFN time) NBAP/ Radio Link Setup Response () RNSAP/ Radio Link Setup Response () • UA0x. Similarly. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.4./method. Passing on or copying of this document. New CM config./method. the DRNC does not perform any check regarding the activation of different CM methods in UL & DL.0 DRNC version: When facing an oldest version on its Iur interface the DRNC just relays the SF/2 CM method/configuration to the NodeB(s).06/EN Approved_Standard 17/Sep/2010 Page 228/244 . for FDD) RNSAP/ Radio Link Setup Request (DTCH config. 6.x SRNC facing an UA06.UMTS Radio Mobility UE Node B Non V6 V6 Node B DRNC SRNC Initial RRC connection DCCH establishment 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. 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.) NBAP/ Radio Link Reconfiguration Ready () NBAP/ Radio Link Reconfiguration Commit (CM configuration activation at TGCFN time ()) RRC/ RB Reconfiguration (DTCH config. nothing specific at this stage. New CM configuration/method. New CM config.12 DRNS SCENARIOS The DRNC does not perform any check regarding HLS activation and the AsConf. for FDD.

If IsHlsCmAllowedOnDRNC is equal to “false” then Same action shall be performed as for the RNS inter release case see §6. It corresponds to an existing use case.4. If the CM is active and CM method in used is SF/2: The SRNC does not need to apply any particular action on its Iur interface. • A RL establishment on a NodeB with alpha CEM cards inside cannot be activated with a HLS CM method. When RL(s) is added on the DRNC. the SRNC configures the CM patterns as usual with the RRC measurement Ctrl message and with the NBAP/RNSAP RL Setup/reconfiguration messages and shall activate the CM when the RNC HHO alarm criteria are reached. the SRNC has configured the CM patterns as usual with the RRC measurement Ctrl message and with the NBAP/RNSAP RL Setup/reconfiguration messages and activated the CM when the RNC HHO alarm criteria are reached. the DRNC relays the CM patterns to the dedicated NodeB.4. this last shall answer by a RNSAP RL Setup/Reconfiguation failure with the cause IE set to “CM not Supported”. The DRNC and the Node B should accept any 3GPP compliant sequence or combination for compressed mode activation/deactivation for supported compressed mode methods. If the CM is active and CM method in used is HLS: . If the HLS method is configured and activated on a node alpha card base. If the SRNC CM configuration is not supported by the DRNC. CM activated in the SRNC. CM not supported on the DRNC side: 1. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. It corresponds to an existing use case. • On reception of the NBAP/RNSAP RL SETUP/RECONFIGURATION FAILURE message the SRNC shall stop the HLS procedure. For these use cases the DRNC does not need to check the CM method (for ALU SRNC/ ALU DRNC only). Passing on or copying of this document. • • ALU SRNC/ not ALU DRNC 1. The SRNC shall not intend to activate any CM on that radio link anymore.11 (CM method switching).UMTS Radio Mobility ALU SRNC/ ALU DRNC: not ALU SRNC/ ALU DRNC (IOT use case) 1. 2. CM on DRNC side is activated at the correct TGCFN time. The TGCFN is the one calculated by the SRNC and shall ensure that the CM activation on DRNC is synchronised with the RL(s) established with the SRNC.06/EN Approved_Standard 17/Sep/2010 Page 229/244 . follow on of the SF/2 CM method with the same TGPS. 6. 2. CM not activated in the SRNC. a NBAP/RNSAP RL SETUP/RECONFIGURATION FAILURE is transmit to the SRNC. 2. No specific action at the RNC/NodeB side. • A NodeB with alpha CEM cards inside will generate a RL SETUP/RECONFIGURATION FAILURE at the compressed mode activation.13 ALPHA CEM CARDS IMPACT • HLS method is not supported on alpha CEM card. No specific action required at the RNC/NodeB side.

code change) NBAP/ Radio Link Addition resp RRC/ active set update RRC/ active set update complete Serving RNC Figure 91: intra-NodeB soft handover during compressed mode 6.15. containing the pattern sequence length.4. TGCFN. a new radio link is added belonging to a new BTS controlled by the Serving RNC.433 §8.15 IMPACT ON OTHER PROCEDURES This paragraph studies the impact of compressed mode on other procedures: • intra-NodeB soft handover • intra-RNC/inter-NodeB soft handover • inter-RNC soft handover 6. The RNC calculates the compressed mode parameters (e. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. since the alternate scrambling method is used The new NodeB has to activate immediately the pattern sequence when receiving the RADIO LINK SETUP REQUEST message as specified in 25. The NodeB has to apply the same compressed mode and pattern parameters as for the other radio links already present in the NodeB for the given UE-network connection. a new radio link is added to existing ones in the NodeB.17.15.4. In case Compressed Mode is already active for the existing UE Radio Links.06/EN Approved_Standard 17/Sep/2010 Page 230/244 .4. 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]).2. TGPRC) such that the patterns are in sync with the other active set cells and UE.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. In case Compressed Mode is already active for the existing UE Radio Links.g. 6. containing the pattern sequences information • "Active Pattern Sequence Information".1 INTRA-NODEB SOFT HANDOVER In this case.133). the Radio Link Setup Request Iub message sent to the NodeB contains the following information: • "Transmission Gap Pattern Sequence Information" IE. Passing on or copying of this document. since the alternate scrambling method is used For the new radio link. since the compressed mode is kept active • "Scrambling Code Change" IE set to "code change".4.UMTS Radio Mobility 6.2. the Radio Link Addition Request message sent to the NodeB contains the following information: • "De-activation Flag" IE set to "maintain active". UE NodeB RRC/ Measurement Report NBAP/ Radio Link Addition req (maintain active.2 INTRA-RNC/INTER-NODEB SOFT HANDOVER In this case. and the starting CFN (TGCFN) • In case of SF/2: "Scrambling Code Change" IE set to "code change".

the RADIO LINK ADDITION RESPONSE message indicates to the SRNC which method is used.4. the RNC calculates the compressed mode parameters (e.UMTS Radio Mobility In case of SF/2: It has to be noted that the 3GPP standard allows the 2 methods "scrambling code change" and "no scrambling code change" to be used simultaneously for radio links belonging to different NodeB. In case Compressed Mode is not active. TGPRC) for the cell on DRNC to be in sync with the ongoing CM pattern. In any case. it can be activated later on in the call. containing the pattern sequences information • "Active Pattern Sequence Information" IE. The choice is left to the Drift RNC. TGCFN. In case of an Alcatel-Lucent Drift RNC.g. Pattern Sequence Info. so that the SRNC can inform the mobile on the scrambling code which is actually used on the new radio link. in the same way as for the Iub interface.15. TGCFN) 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 92: intra-RNC soft handover during compressed mode 6. the "scrambling code change" is applied. using the COMPRESSED MODE COMMAND RNSAP message. the Radio Link Setup Request Iur message sent to the Drift RNC contains the following information: • "Transmission Gap Pattern Sequence Information" IE. In case of SF/2: The "Scrambling code change" method is not specified on the Iur. this is also valid for the inter-RNC soft handover case. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Passing on or copying of this document. UE NodeB RRC/ Measurement Report NBAP/ Radio Link setup req (code change. A fortiori. containing the pattern sequence length.06/EN Approved_Standard 17/Sep/2010 Page 231/244 . a new radio link is added belonging to a new BTS controlled by a Drift RNC. In case Compressed Mode is already active for the existing UE Radio Links.3 INTER-RNC SOFT HANDOVER In this case. as on Iub. as on Iub. and the starting CFN (TGCFN) As in "intra-RNC/inter-NodeB soft handover" case.

The measurement criteria is evaluated If the Alarm Measurement Criteria is still valid.06/EN Approved_Standard 17/Sep/2010 Page 232/244 . In order to avoid compressed mode configuration which Alcatel-Lucent RNS is not able to support. TGCFN. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.19 and 5. TGCFN) NBAP/ Radio Link setup req (Pattern Sequence Info. as explained in section 4. 6. and associated compressed mode sequence depend on the Primary cell neighbouring list and priority setting. This may happen in case the access network is composed of RNC from multiple manufacturers. a rejection means that a RADIO LINK SETUP FAILURE or RADIO LINK ADDITION FAILURE is sent back to the SRNC. (SF/2: code change)) NBAP/ Radio Link setup resp RNSAP/ Radio Link Setup resp (SF/2: code change) AAL2/ ERQ AAL2/ ECF AAL2/ ERQ AAL2/ ECF FP/ DL Sync (CFN) FP/ DL Sync (CFN) FP/ UL Sync (ToA) FP/ UL Sync (ToA) RRC/ active set update (SF/2: code change) RRC/ active set update complete Drift RNC Serving RNC Figure 93: inter-RNC soft handover during compressed mode When an Alcatel-Lucent Drift RNC is receiving a RNSAP RADIO LINK SETUP REQUEST message with compressed mode parameters. depending on the Alarm Measurement Type This is illustrated in the following figure: Passing on or copying of this document. these parameters may not be consistent with the DRNC capability.4. The AlcatelLucent RNC implements a filtering function.UMTS Radio Mobility UE Drift NodeB RRC/ Measurement Report SCCP/ CR SCCP/ CC RNSAP/ Radio Link setup req (Pattern Sequence Info. The filtering function is specified in the chapter on "Parameters". In case the primary cell is changed while compressed mode is running. measurements (either inter-freq or inter-system) are activated.16 CHANGE OF ALARM MEASUREMENT TYPE (COMMON HLS AND SF/2) The Alarm Measurement Type. Based on the output of this function.9. The configuration of the new Primary cell is taken into account for the next measurement setup. In case of change of iMCTA trigger with crossover between inter-RAT and inter-frequency the ongoing measurement is aborted and the new measurement is started as detailed below. the RNC keeps the ongoing measurement active independent of the configuration of the new Primary cell. the RADIO LINK SETUP REQUEST or RADIO LINK ADDITION REQUEST received from the Iur is either accepted or rejected by the Alcatel-Lucent RNC. This behaviour ensures that handover can be executed as fast as possible. In this case. • • • The compressed mode is stopped when the CFN activation is passed.

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 Figure 94: change of CM scheme The following message flow illustrates what happens in case of change of CM scheme. 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. Trigger change. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Passing on or copying of this document.06/EN Approved_Standard 17/Sep/2010 Page 233/244 . This message also contains a starting CFN for the inter-frequency pattern sequence.17 DEFENCE MECHANISM FOR UE NOT SUPPORTING CM WITH HSPA Some non-standards conforming UEs do not support compressed mode in combination with HSDPA or HSUPA.. This IE has the same value as the CM Configuration Change CFN of the NBAP message below. indicating the CFN at which the NodeB shall de-activate all the on-going pattern sequences. UE NodeB Serving RNC Inter-system CM is active. The procedure is applicable independently of the CM method.UMTS Radio Mobility CMperiod Inter-system CM Pattern sequence for inter-freq . TGPS reconf CFN. inter-frequency starting TGCFN) Figure 95: Dataflow on change of CM scheme The initial RRC MEASUREMENT CONTROL message instructs the mobile to stop the GSM measurement. inter-frequency starting TGCFN) NBAP/ Compressed Mode Command (CM Configuration Change CFN. If compressed mode activation for HSxPA fails or the UE indicates in its capability information that it does not compressed mode with HSUPA or for HSUPA calls if CM is disabled at OAM level then a reconfiguration to DCH is performed and compressed mode is activated with the DCH configuration. Fdd pattern=active. Change of trigger with crossover from GSM to inter-frequency target RRC/ Measurement Control (Release GSM measurement) RRC/ Measurement Control (setup inter-frequency measurement) RRC/ Measurement Control (2G pattern=inactive. • a starting CFN for the inter-frequency pattern sequence The NBAP COMPRESSED MODE COMMAND contains a CM Configuration Change CFN. For details refer to [R4] (HSDPA) and [R6] (HSUPA).4.. 6.

4. or interoperability with mobiles.. 6. DL only.18 PARAMETERS This chapter lists all the configuration parameters for Compressed mode.4.18. or combined UL/DL compressed mode is used.2 O&M PARAMETERS This list contains the parameters which are used to configure the CM function.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. being active or not. inactive Integer (0. If this should occur.UMTS Radio Mobility 6. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Defines whether only DL. For the parameters displayed at the OMC-R level.1 GENERAL PARAMETERS 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 Name gsm450Present gsm480Present RadioAccessService Class 3 RadioAccessService Class 3 RadioAccessService Class 3 RadioAccessService Class 3 RadioAccessService Class 3 Gsm850Present Gsm900PPresent Gsm900EPresent Gsm900RPresent Passing on or copying of this document. TGPS Status Flag TGCFN active. The value of this parameter depends on the UE classmark.18. most of them being part of 25. UL/DL mode UL only. Parameters at the RNC level Most of the parameters listed below are defined at the RNC level. The following set of parameter is present for each pattern.4. there is no guarantee regarding Alcatel-Lucent UTRAN performances. UL/DL 6.4.2.18.1 DYNAMIC PARAMETERS These parameters are not accessed by the operator. it is always possible to change the value.331 6.06/EN Approved_Standard 17/Sep/2010 Page 234/244 . only UL.

TGPRC The number of transmission gap patterns within the Transmission Gap Pattern Sequence.2.2 PATTERN PARAMETERS A certain number of pattern sequences can be defined in Alcatel-Lucent UTRAN. GSM RSSI measurement. Class 3 Definition Indicates if compressed mode for GSM is allowed for this DL UserService.isHlsCmMethodPreferred=Yes if throughput reduction by simultaneous CM pattern is acceptable.UMTS Radio Mobility Gsm1800Present Gsm1900Present 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 RadioAccessService Class 3 RadioAccessService Class 3 Name isGsmCModeActivationAllowed isInterFreqCModeActivationAllowed isHlsCModeAllowed isHlsCmMethodPreferred isHlsCmMethodPreferred IsHlsCmAllowedOnDRNC isSimCMAllowed[not supported in this version] Object/Class DlUserService Managed Object. Those parameters are defined at the cell level. ALU uses a double frame CM pattern. or . Class 3 RadioAccessService Class 3 UlUserService Managed Object. For each of the pattern. Name TGMP Range FDD measurement.. Class 3 DlUserService Managed Object. Indicates if compressed mode by HLS is allowed or not.511. 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 simultaneous compressed mode is requested but not possible then the RNC uses single compressed mode as per parameter is3GHandoverPreferred. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. Class 3 NeighbouringRNC Managed Object.18.06/EN Approved_Standard 17/Sep/2010 Page 235/244 . If this parameter is set to TRUE than the RNC is allowed to use simultaneous compressed mode for inter-frequency and 2G inter-RAT measurements for this service.isHlsCmMethodPreferred=No. GSM BSIC re-confirmation Integer (1. Passing on or copying of this document. the available parameters are described in the table below. Class 3 DlUserService and UlUserService Managed Object. Infinity) Definition Transmission Gap pattern sequence Measurement Purpose. Class 3 DlUserService Managed Object. Indicates if the Compressed Mode for interfrequency is allowed for this DL UserService. Otherwise: FALSE 6. Simultaneous inter-frequency and 2G inter-RAT measurements are not possible for certain RAB combinations due the enhanced compressed mode requirements. GSM Initial BSIC identification. Engineering guideline: TRUE for all RAB combinations with .4.

255) N Identify abort Integer(1...144) Integer(0..2.144) Integer (1.4.14) Transmission Gap Starting Slot Number The slot number of the first transmission gap slot within the TGCFN. Passing on or copying of this document.06/EN Approved_Standard 17/Sep/2010 Page 236/244 .269.128) T Reconfirm abort Integer(1.18. TGL1 Integer(1. 6.. The time is given in steps of 0.. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11..20) GSM and/or FDD inter-frequency measurements: 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 FDD Measurements 50 10 10 undefined undefined 6 undefined 3 not applicable 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). Those parameters are defined at the cell level.5 seconds..14) Integer(15. These two gaps are spread by applying the TGCFNoffset=3 for FDD measurements.. the GSM RSSI or BSIC Identification gap and the FDD measurement gap.14) TGL2 TGD Integer (1.UMTS Radio Mobility TGSN Integer (0.3 POWER CONTROL PARAMETERS This set of parameters is linked to power control algorithms used by the BTS when compressed mode is active.. undefined) TGPL1 TGPL2 TGCFNoffset Integer (1. 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.

1) 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 6.212. mode 1 DeltaSIR1 Real(0. Name Downlink compressed mode method Uplink compressed mode method Downlink frame type Scrambling code change Range puncturing.1) DeltaSIR2 Real(0.UMTS Radio Mobility Name RPP Range mode 0.2. Delta in DL SIR target value to be set in the UE during the frame containing the start of the first transmission gap in the transmission gap pattern (without including the effect of the bit-rate increase) Delta in DL SIR target value to be set in the UE one frame after the frame containing the start of the first transmission gap in the transmission gap pattern.3 by step of 0. ITP mode 0.18.4. mode 1 Definition Recovery Period Power control mode during the frame after the transmission gap within the compressed frame.. These parameters are defined at the RNC level. DeltaSIRafter2 = DeltaSIRafter1. and not displayed at the OMC-R level. When omitted.2 Indicates whether the alternative scrambling code is used for compressed mode method 'SF/2' Passing on or copying of this document.06/EN Approved_Standard 17/Sep/2010 Page 237/244 .. Delta in DL SIR target value to be set in the UE during the frame containing the start of the second transmission gap in the transmission gap pattern (without including the effect of the bit-rate increase) When omitted. SF/2. no code change Definition Method for generating downlink compressed mode gap Method for generating uplink compressed mode gap See 25. higher layer scheduling A.1) DeltaSIRafter1 Real(0. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.3 by step of 0. higher layer scheduling SF/2. DeltaSIR2 = DeltaSIR1. B code change. §4..1) DeltaSIRafter2 Real(0.3 by step of 0. Indicates whether normal or compressed Power Control mode is applied Initial Transmit Power is the uplink power control method to be used to compute the initial transmit power after the compressed mode gap. Delta in DL SIR target value to be set in the UE one frame after the frame containing the start of the second transmission gap in the transmission gap pattern.3 by step of 0..4.4 STATIC PARAMETERS This set of parameter is static.

HLS. these parameters will be using the following values: Static parameters per Ul/DlAsConf: Downlink compressed mode method Uplink compressed mode method Downlink frame type Scrambling code change SF/2. Measurement filtering Passing on or copying of this document. 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. 6. 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. no code change 6. SF/2&HLS B. if a decision for handover is made. HLS SF/2. HLS No check No check No check No check No check 6.1 2G TARGET CELL CHOICE RADIO CRITERIA DESCRIPTION At each measurement period the mobile reports the measured cells even if all neighbour cells are not measured.4. the compressed mode duration is limited. HLS. In case no valid value is provided by the DRNC.18. the Alcatel-Lucent SRNC uses 0 as a default value. this parameter is provided by the DRNC as the Radio Link is added.UMTS Radio Mobility In this version.5 CONTROL PERFORMED BY THE ALCATEL-LUCENT RNC The following table specifies the control which is performed by the Alcatel-Lucent RNC on the compressed mode parameters received in the RADIO LINK SETUP REQUEST or RADIO LINK ADDITION REQUEST Iur message.A code change.06/EN Approved_Standard 17/Sep/2010 Page 238/244 .5.2.5. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. SF/2&HLS SF/2. By selecting the first cell reported by the mobile which fulfils the IMCTA criteria (the selected cell may not be the best cell on a given Carrier). Parameter received from Iur TGCFN TGSN TGL1 TGL2 TGD TGPRC TGPL1 TGPL2 Downlink compressed mode method Uplink compressed mode method Downlink frame type DeltaSIR1 DeltaSIRafter1 DeltaSIR2 DeltaSIRafter2 Alcatel-Lucent RNC control No check No check No check No check No check No check No check No check SF/2. On reception of inter-system measurement report. In the Iur case.

UMTS Radio Mobility
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
Target cell identification

The target is chosen by the iMCTA function based on different criteria (radio, load,. refer to § 4.19). if no measurement is valid or if there is no eligible cell in the list reported by the mobile • if a blind target has been defined for the Primary, then a handover is tried towards that cell • else no handover is tried For further details on measurements, please refer to the section 6.2. Note: In intra-freq periodic mode, if a cell was reported in a previous measurement report and is missing in the new report then the 'Missing Measurement' algorithm applies as specified in section 6.3.2.

6.5.2

PARAMETERS
Object/Class RadioAccessService Class3 GsmNeighbouringCell Class3 Definition Threshold on GSM carrier RSSI for inter-system target cell eligibility Offset used for "target cell equalization"

Name minimumGsmRssiValueForHO gsmCellIndivOffset

6.6.

FDD TARGET CELL CHOICE INTER FREQUENCY RADIO CRITERIA DESCRIPTION

6.6.1

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 3step 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 239/244

UMTS Radio Mobility
The following criteria are evaluated on the measurements reported by the mobile (i.e. not equalized) CPICH Ec/No > minimumCpichEcNoValueForHHO and CPICH RSCP > minimumCpichRscpValueForHHO
Target cell identification

The target cell is chosen by the iMCTA function based on different criteria (radio, load, FDD layer priority... refer to § 4.19).

6.6.2

PARAMETERS
Object/Class UMTSFddNeighbouringCell Class3 DlUserService Class3 DlUserService Class3 Definition Offset used for "target cell equalization" CPICH Ec/No threshold for inter-frequency cell eligibility CPICH RSCP threshold for interfrequency cell eligibility

Name neighbouringCellOffset minimumCpichEcNoValueForHO minimumCpichRscpValueForHO

6.7. 6.7.1

NEIGHBOR CELLS FLEXIBLE MANAGEMENT DESCRIPTION

The Alcatel-Lucent UTRAN allow any combination of intra-freq, inter-freq and 2G inter-RAT neighbour cells in SIB11 • If feature “SIB11 enhancements” is activated (parameter isEnhancedSib11Allowed set to False): as long as the total number does not exceed 48 or 47 depending whether Measurement control is activated in SIB11). • If feature “SIB11 enhancements” is not activated (parameter isEnhancedSib11Allowed set to True): up to the maximum of 96 (32 each). . This will improve the call setup success rate and therefore it will increase the quality of the 3G network. At OAM level, for a given Fdd Cell, the operator can flag among all neighbour cells (Intra Frequency/ Inter Frequency/ Inter Rat) the neighbour cells to be put in SIB11 and in the RRC Measurement Control message.

6.7.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 2G inter-RAT neighbor cells allowed in SIB11 within a global limitation of 47/48 or 96 neighbor cells according to isEnhancedSib11Allowed value) 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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 240/244

UMTS Radio Mobility

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. If SIB11 enhancement procedure is allowed and there is ASN-1 encoding errors, RNC shall not update SIB11 with a truncated list of neighbours as per current solution but let NodeB continue to broadcast current SIB11. [Global Market - This especially might be the case if feature HCS has been enabled simultaniously (refer to 4.23, FDDCell::isHcsUsed) which requires that HCS related Information Elements are to be added to SIB11. As this will lead to a shrinkage of the space available for neighbour data, it might not be possible to add data for all neighbours to SIB11.A tradeoff between number of neighbours to be supported for a cell, the number of parameters deviating from defaults and the usage of HCS in order to cope with SIB11limitations imposed by 3GPP shall be found.]

Note: SIB12 follows same rules as SIB11 to select cells and set parameters in the message

6.7.3

PARAMETERS
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. This parameter is used to enable/disable feature "SIB11 enhancements" allowing to add more than 48 neighbour cells to System Information Block type 11

Name Sib11OrDchUsage

Sib11OrDchUsage

UMTSFddNeighbouringCell

SIB11AndDCHNeighbouringFddCellAlgo

FDDCell Class 3

isEnhancedSib11Allowed

FDDCell Class 3

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 241/244

UMTS Radio Mobility

7.
7.1.

ABBREVIATIONS AND DEFINITIONS
ABBREVIATIONS
AAL2 signalling Always On Absolute Radio Frequency Channel Number Asynchronous Transfer Mode Broadcast Control Channel Base transceiver Station Identity Code Base Transceiver Station Call Admission Control Component Administration System Connection Frame Number Cell Individual Offset Compressed Mode Core Network Common Pilot Channel Controlling Radio Network Controller Circuit Switched Circuit Switched Data Dedicated Common Channel Dedicated Channel Drift RNC Diversity Handover Downlink Shared Channel Dedicated Traffic Channel Dual Transfer Mode Enhanced DCH Evolved Packet System Fast Access Channel Frequency Division Duplex General Packet Radio Service GPRS Tunnelling Protocol Hierarchical Cell Structure Hard HandOver Higher Layer Scheduling High Speed Downlink Packet Access High Speed Downlink Shared CHannel High Speed Uplink Packet Access Home Subsciber Server Interactive/Background Inter Frequency Intelligent Multi Carrier RRC Connection Allocation Intelligent Multi Carrier Traffic Allocation Internet Protocol Inter RAT – usually GSM measurements or GSM handover Latest Time Of Arrival Mobile Application Part Mobility Management Entity Mobile Switching Centre Narrow Band Node B Application Part Paging Channel PDN Gateway Packet Switched Radio Access Bearer

ALCAP AO ARFCN ATM BCCH BSIC BTS CAC CAS CFN CIO CM CN CPICH CRNC CS CSD DCCH DCH DRNC DHO DSCH DTCH DTM E-DCH EPS FACH FDD GPRS GTP HCS HHO HLS HSDPA HS-DSCH HSUPA HSS I/B IF iMCRA iMCTA IP IRAT LTOA MAP MME MSC NB NBAP PCH PGW PS RAB

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

UMT/SYS/DD/0054

11.06/EN

Approved_Standard

17/Sep/2010

Page 242/244

27219 34227 30443.06/EN Approved_Standard 17/Sep/2010 Page 243/244 . Full event support and HHO towards CDMA State transitioning enhancements Support of WCDMA to Reporting quantity Periodic: Ec/No&RSCP Event 2D. Feature HHO 3G3G Full Event trigger support Full Event trigger support HHO 3G2G UA06. 2D. 1E.2F Ec/No Event 2D.1D.1C.1E. APPENDIX 1: EVENTS CONFIGURATION Feature ID 17569 27219 27219 xxxxxx 32525 33692 xxxxxx. 3A or (1A Nb Criteria Mobility 1 Mobility 2 Mobility 2 Mobility 1 Call Trace 1 Call Trace Mobility 1 7 Group Category Inter Frequency Inter Frequency Inter Frequency Inter RAT Intra Frequency Intra Frequency Intra Frequency Mobility Mobility 1 2 Intra Frequency Intra Frequency Passing on or copying of this document.0 Call trace enhancement Air Status Measurement SHO.2.UMTS Radio Mobility RACH RAN RAT RANAP RB RL RNC RNS RNSAP RRC RSCP SCCP SF SGSN SGW SHO SIB SRB SRLR SRNC SRNS TDD TGCFN TGPRC TGPS TRB UP URA UTRAN WB Random Access Channel Radio Access Network Radio Access Technology Radio Access Network Application Part Radio Bearer Radio Link Radio Network Controller Radio network subsystem Radio network subsystem Application part Radio Resource Control Received Signal code Power Subsystem Connection Control Protocol Spreading Factor Serving GPRS Support Node Signalling Gateway Soft HandOver System Information Block Signalling Radio Bearer Synchronous Radio Link Reconfiguration Serving RNC Serving Radio network subsystem Time Division Duplex TGPS CFN TGPS Repetition Count Transmission Gap Pattern Sequence Traffic Radio Bearer User Plane UTRAN Registration Area Universal Terrestrial Radio Access Network Wide Band 7.1J) XOR periodic intra freq Ec/No&RSCP Periodic.1F. once(meas ctrl or SIB11): Ec/No Event 1D.1B. DEFINITIONS Empty chapter.2F RSCP Periodic: GSM Carrier RSSI Periodic: CPICH Ec/No&CPICH RSCP Periodic: CPICH Ec/No&CPICH RSCP SIB11 XOR (1A. 1F. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11.

RLC Buffer Payload .0 Call trace enhancement CellId RTT positioning RAB modification State transitioning enhancements Air Status Measurement Assisted GPS Enhancements (step 2) Alarm HHO based on UL Tx power CellId RTT positioning RRM Call Trace 1 1 1 1 1 1 1 1 1 2 1 Traffic Volume UE Internal UE Internal UE Internal UE Internal UE Internal UE Internal UE Positioning UE Positioning UE Internal UE Positioning Periodic: UE Tx Power&Rx-Tx Call Trace Type 1 Periodic: UE Tx Power&UE RxCall Trace Tx Time Difference Periodic. successively: CPICH Ec/No&CPICH RSCP&Pathloss Periodic: DL TrCH BLER Periodic: DL TrCH BLER Periodic: DL TrCH BLER Event 4A .0 call trace enhancements Air Status Measurement UA06. Variance of RLC Buffer Payload for RBs multiplexed onto the same Transport channel Event: 4A (1 per ul DCH) Periodic: UE transmitted power Mobility Monitoring Positioning Positioning 1 1 1 1 Intra Frequency Intra Frequency Intra Frequency Intra Frequency 30223 30250 33692 34212 xxxxxx UA05.once. RLC Buffer Payload . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/SYS/DD/0054 11. once: Tx Type2 Positioning Event 6A: UE transmitted power RRM UE TX power (additional meas of RRM 4A) GPS timing of cell frame Call Trace Periodic: GPS timing of cell Positioning frame Event 6A and 6B: Ue Mobility Transmitted power Periodic.06/EN Approved_Standard 17/Sep/2010 Page 244/244 . Average of RLC Buffer Payload . once: Path Loss Periodic.0 call trace enhancements Air Status Measurement ATT Perf monitoring Always ON Call Trace Call Trace Monitoring RRM 1 1 1 1 Quality Quality Quality Traffic Volume 33565 UA06 Always on devlopment RRM 1 Traffic Volume 34227 30223 30250 33692 32525 24089 34226 34227 33692 27615 33331 24089 State transitioning enhancements UA05.UMTS Radio Mobility 33853 21302 33814 34212 24089 77736 CDMA handover HHO intra Freq inter RNC ATT Perf monitoring CellId RTT positioning Non GPS LBS and 1C) Event: 1A Periodic: CPICH Ec/No&CPICH RSCP Periodic. Variance of RLC Buffer Payload for RBs multiplexed onto the same Transport channel From 0/0 only (Event 4A): . Average of RLC Buffer Payload . once: Rx-Tx Type1 Positioning END OF DOCUMENT  Passing on or copying of this document.

Sign up to vote on this title
UsefulNot useful