RNC

Functional Description

Basic Call

Document name/edition Copyright © Nokia Solutions and Networks

Functional Description
BASIC CALL
Copyright © Nokia Solutions and Networks 2019. All rights reserved.
No part of this publication may be copied, distributed, transmitted, transcribed, stored in a retrieval system, or translated
into any human or computer language without the prior written permission of Nokia Solutions and Networks.
The manufacturer has made every effort to ensure that the instructions contained in the documents are adequate and
free of errors and omissions. The manufacturer will, if necessary, explain issues, which may not be covered by the
documents. The manufacturer’s liability for any errors in the documents is limited to the correction of errors and the
aforementioned advisory services.
The documents have been prepared to be used by professional and properly trained personnel, and the customer
assumes full responsibility when using them. The manufacturer welcomes customer comments as part of the process of
continual development and improvement of the documentation in the best way possible from the user’s viewpoint.
Please submit your comments to the nearest Nokia Solutions and Networks sales representative.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 2(447)
Basic Call
CONTENTS
Contents ............................................................................................................................ 3
1. INTRODUCTION ..................................................................................................... 29
1.1 Purpose and scope .......................................................................................... 29
1.2 Concepts and abbreviations ............................................................................. 29
1.3 References ....................................................................................................... 38
2. Functionality description ......................................................................................... 39
2.1 General ............................................................................................................. 39
2.2 Basic Call Functionality .................................................................................... 39
2.2.1 Mobile Originated Call Case ..................................................................... 44
[Link] Mobile Originated Call (Circuit Switched) ............................................. 45
[Link] Mobile Originated Call (Packet Switched) ............................................ 50
2.2.2 Mobile Terminated Call Case ................................................................... 52
[Link] Mobile Terminated Call (Circuit Switched) ............................................ 52
[Link] Mobile Terminated Call (Packet Switched) ........................................... 54
2.2.3 IDLE State Procedures ............................................................................. 55
[Link] Idle Mode Measurements ...................................................................... 55
[Link].1 Handover Measurements ............................................................... 55
[Link] Paging Procedures ................................................................................ 55
[Link].1 RANAP Paging ............................................................................... 56
[Link].2 Idle Mode Paging ............................................................................ 56
[Link].3 Distribution of paging message for UEs in Idle Mode.................... 58
[Link].4 Paging Priorisation ......................................................................... 58
[Link].5 Determination of DRX cycle length for UEs in idle mode .............. 58
[Link].6 Calculation of paging occasion for UEs in idle mode .................... 59
[Link].7 Generation of paging indication ..................................................... 59
[Link].8 Paging Buffer Handling .................................................................. 59
[Link].9 Sending RRC: PAGING TYPE 1 message .................................... 61
[Link].10 Paging Response (Initial Direct) .................................................. 62
[Link].10 UTRA Connected Mode .................................................................. 63
[Link] RRC Connection Procedures ................................................................ 63
[Link].1 RRC Connection Request .............................................................. 64
[Link].2 RRC Connection Setup .................................................................. 66
[Link].3 RRC Connection Setup Complete ................................................. 75
[Link].4 RRC Connection Release .............................................................. 76
[Link].5 RRC Connection Reject ................................................................. 80
[Link].6 RRC Connection Failure due to missing RRC connection setup
complete 81
[Link].7 Faulty protocol error handling during RRC Connection setup
procedure 81
2.2.4 CELL_DCH State Procedures .................................................................. 84
[Link] DCH allocation and in RRC connection setup ...................................... 84
[Link] NAS/Service establishment toward the CS-CN ................................... 86
[Link] Measurement Reporting Procedures .................................................... 87
[Link].1 Start Measurement Reporting ........................................................ 89
[Link].2 Management and mapping of measurement IDs .......................... 90
[Link].3 Prioritization of measurement message over other messages ..... 91
[Link].4 Queuing of Measurement Requests .............................................. 92
[Link].5 Stop Measurement Reporting ........................................................ 92
[Link].6 Modify Measurement Reporting procedures .................................. 93
[Link].7 Failure of Measurement Reporting Cases .................................... 94
[Link].8 No Reception of Measurement Report messages ......................... 95
[Link] Radio Link Procedures .......................................................................... 95

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 3(447)
Basic Call
 [Link].1 Radio Link Setup Request.............................................................. 95
[Link].2 Radio Link Setup Response ........................................................... 95
[Link].3 Radio Link Restore Indication ........................................................ 95
[Link].4 Radio Link Setup Failure ................................................................ 96
[Link].5 Radio Link Reconfiguration Prepare .............................................. 96
[Link].6 Radio Link Reconfiguration Cancel ................................................ 96
[Link].7 Radio Link Reconfiguration Ready ................................................ 96
[Link].8 Radio Link Reconfiguration Commit .............................................. 97
[Link].9 Radio Link Reconfiguration Failure ................................................ 97
[Link].10 Radio Link Deletion Request........................................................ 97
[Link].11 Radio Link Deletion Response ..................................................... 97
[Link] UE – CN Signalling Procedures ............................................................ 98
[Link].1 UE – CN Signalling Connection Setup........................................... 98
[Link].2 Initial Direct Transfer (IDT) ............................................................. 98
[Link].3 Downlink Direct Transfer (DDT) ................................................... 100
[Link].4 Uplink Direct Transfer (UDT) ........................................................ 101
[Link].5 UE – CN Signalling Connection Release ..................................... 101
[Link] RANAP COMMON ID .......................................................................... 104
[Link] Radio Access Bearer Procedures ....................................................... 105
[Link].1 RANAP RAB Assignment Handling ............................................. 106
[Link].2 RRC Radio Bearer Setup ............................................................. 113
[Link].3 Additional RAB Establishment ..................................................... 116
[Link].4 NRT RAB Establishment .............................................................. 117
[Link].5 Radio Bearer Setup Failure .......................................................... 120
[Link].6 RT RAB Establishment ................................................................. 123
[Link].7 Radio Bearer Setup Complete ..................................................... 124
[Link].8 Radio Bearer Release .................................................................. 124
[Link].9 Radio Bearer Release Complete ................................................. 125
[Link] UE Capability Procedures ................................................................... 126
[Link].1 UE Capability Enquiry .................................................................. 126
[Link].2 UE Capability Update ................................................................... 126
[Link] Activation time increase ...................................................................... 127
2.3 Feature Functionality ...................................................................................... 127
2.3.1 Cell level Management for AMR mode sets ........................................... 127
2.3.2 Narrowband AMR Code Set (12.2, 7.95, 5.90, 4.75) (5.90, 4.75) and
Narrowband AMR Codec Set for 2G-3G (12.2, 7.4, 5.90, 4.75) .......................... 128
2.3.3 Wideband AMR Codec Set (12.65, 8.85, 6.6) (WBAMRCS) ................. 129
2.3.4 Wideband and Narrowband AMR RAB Modification .............................. 130
2.3.5 Transport Channel Reconfiguration during DCH Allocation................... 133
2.3.6 Bit Rate Upgrade and Downgrade .......................................................... 134
2.3.7 Transport Format Combination Control .................................................. 135
2.3.8 Emergency Call Redirection to GSM ...................................................... 137
2.3.9 Transcoder and Tandem Free Operation (TrFO and TFO) ................... 137
[Link] RAB Assignment procedure ................................................................ 138
[Link] SRNS Relocation Procedures ............................................................. 139
[Link] IuUP Initialization Procedure ............................................................... 139
[Link] RFCI Value Correction ........................................................................ 140
[Link] Maximum Rate Control Procedure ...................................................... 140
[Link] Additions to support speech codecs for codec matching ................... 140
[Link] Filtering of Frequent IuUP Rate Control Frames ................................ 140
[Link] Immediate Rate Control ...................................................................... 142
[Link] Handling of Rate Control Commands for AMR Uplink ....................... 142
2.3.10 HSDPA Feature Functionality ................................................................. 143
[Link] Introduction ...................................................................................... 143

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 4(447)
Basic Call
 [Link] HSDPA Enhancements ................................................................... 144
[Link] HSDPA Transport and Physical Channels ...................................... 145
[Link] QoS PS streaming class RABs on HSPA ....................................... 145
[Link] 14 Mbps Per User ............................................................................ 146
[Link] HSPA Multi NRT RABs .................................................................... 147
[Link] HSDPA 64QAM ............................................................................... 149
[Link] HSDPA Flexible RLC ....................................................................... 150
[Link].1 Impacts on RRC procedures ...................................................... 150
[Link].2 New and modified IEs in Uu interface ........................................ 151
[Link].3 Effects on Channel Type Switch from DCH to HS-DSCH with
Flexible RLC ................................................................................................... 152
[Link].4 Multi RAB Configuration of UE supporting FRLC ...................... 153
[Link].5 Configuration switch between flexible <> fixed RLC PDU size . 153
[Link] Fractional DPCH .............................................................................. 153
[Link].1 Introduction ................................................................................. 153
[Link].2 Allocation of F-DPCH ................................................................. 154
[Link].3 Multi RAB configuration of the UE supported with SRBs on E-
DCH/HS-DSCH .............................................................................................. 155
[Link].4 E-DCH TTI reconfiguration 2ms <> 10ms ................................. 155
[Link].5 Effect on Channel Type Switch .................................................. 156
[Link].6 Effect on Serving Cell Change ................................................... 156
[Link].7 Combined Active Set Update (ASU) and HSPA Serving Cell
Change (HSCC) procedure ............................................................................ 156
[Link] MIMO 28 Mbps ................................................................................ 157
[Link] MIMO 42 Mbps ................................................................................ 157
[Link] DC-HSDPA 42Mbps ........................................................................ 158
[Link] DC-HSDPA 84 Mbps ....................................................................... 159
[Link] MC-HSDPA ...................................................................................... 160
2.3.11 HSUPA Feature Functionality ................................................................. 162
[Link] Introduction ...................................................................................... 162
[Link] HSUPA Enhancements ................................................................... 163
[Link] HSUPA Transport and Physical Channels ...................................... 163
[Link] HSUPA 5.8 Mbps ............................................................................. 164
[Link] HSUPA 2ms TTI .............................................................................. 165
[Link].1 Multi RAB Configuration of UE supported with HSUPA 2ms TTI
166
[Link].2 E-DCH TTI reconfiguration 2ms <> 10ms ................................. 166
[Link].3 Channel Type Switch between DCH <> E-DCH 2ms TTI ......... 167
[Link] Flexible RLC in UL ........................................................................... 167
[Link].1 Impacts on NBAP and RRC procedures .................................... 168
[Link].2 New and modified IEs in Uu interface ........................................ 169
[Link].3 Flexible RLC uplink PDU size capability of a local cell .............. 170
[Link].4 Flexible RLC uplink PDU size capability of UE .......................... 170
[Link].5 RRC Connection Establishment with flexible RLC uplink PDU size
170
[Link].6 Capacity allocation with flexible RLC uplink PDU size .............. 171
[Link].7 Channel type switch with change from fixed to flexible RLC uplink
PDU size 171
[Link].8 Channel type switch with change from flexible to fixed RLC uplink
PDU size 172
[Link].9 Reconfiguration of E-DCH MAC-d flows from fixed to flexible RLC
uplink PDU size .............................................................................................. 172
[Link].10 Reconfiguration of E-DCH MAC-d flows from flexible to fixed
RLC uplink PDU size ...................................................................................... 173

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 5(447)
Basic Call
 [Link].11 Failure during radio link setup / reconfiguration ....................... 174
2.3.12 Direct Resource Allocation for HSPA ..................................................... 174
[Link] Direct Resource Allocation for HS(D)PA in Cell_DCH state ........... 175
[Link] Direct Resource Allocation for HS(D)PA in Cell_FACH state ......... 177
[Link] Direct resource allocation shall be supported for HSPA and HSDPA
178
[Link] Direct resource allocation for HSDPA shall have
HSDPAInitialBitrateUL for UL-DCH ................................................................... 178
[Link] Direct resource allocation shall not be supported for all the RABs in a
multi-RAB request coming in a single RAB ASSIGNMENT REQUEST ........... 178
[Link] Direct resource allocation for HSPA/HSDPA shall be supported with
HSPA over Iur .................................................................................................... 179
[Link] Direct resource allocation shall not trigger channel type switch ..... 179
[Link] Direct resource allocation during compressed mode ...................... 179
2.3.13 PS service reconfiguration ...................................................................... 179
[Link] RAB Modification Handling in Different RRC State ........................ 181
[Link].1 UE in Cell/URA_PCH State ........................................................ 181
[Link].2 UE in Cell_FACH State .............................................................. 181
[Link].3 UE in Cell_DCH Using DCH Service ......................................... 181
[Link].4 The UE Using DCH/HSDPA Service ......................................... 183
[Link].5 The UE Using HSUPA/HSDPA Service ..................................... 183
[Link] UL Transport layer address ............................................................. 184
[Link].1 Modification of UL Transport layer address is controlled just with
the RAN930 license ........................................................................................ 184
[Link].2 Modification of UL Transport layer address is supported .......... 184
[Link] Collision and Error Handling ............................................................ 185
[Link].1 Collision Cases During RAB Modification .................................. 185
[Link].2 RAB Modification Failure ............................................................ 185
[Link].3 RAB Release During RAB Modification ..................................... 186
[Link].4 Multiple RAB Requests .............................................................. 186
[Link].5 Collision and error cases are handled during modification of UL
Transport layer address ................................................................................. 186
2.3.14 Load Based AMR Codec Mode Selection .............................................. 187
2.3.15 RNSAP Radio Link Congestion Control Procedure ............................... 190
[Link] Radio Link Congestion procedure in DRNC ................................... 190
[Link] Radio Link Congestion procedure in SRNC .................................... 191
[Link] RNSAP Congestion failure .............................................................. 191
2.3.16 RNSAP Radio Link Pre-emption procedure ........................................... 192
[Link] RNSAP Radio Link Pre-emption procedure in DRNC .................... 192
[Link] RNSAP Radio Link Pre-emption procedure in SRNC ..................... 192
2.3.17 Asymmetric AMR over Iur ....................................................................... 193
2.3.18 Common Channel Setup......................................................................... 194
[Link] RRC Connection Procedures on CCH ............................................ 195
[Link].1 RRC Connection Request prefers CCH .................................... 195
[Link].2 RRC Connection Setup to CCH ................................................. 197
[Link].3 RRC Connection Setup Complete on CCH ............................... 201
[Link].4 RRC Connection Release on CCH ............................................ 201
2.3.19 24 kbps paging channel .......................................................................... 201
2.3.20 GTP Error Indication cause value ........................................................... 203
2.3.21 Maximum bit rate negotiation .................................................................. 203
2.3.22 CS Voice over HSPA .............................................................................. 204
[Link] CS Voice RAB setup........................................................................ 205
[Link] CS CN initiated codec modification between AMR and AMR WB in
HSPA configuration ............................................................................................ 207

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 6(447)
Basic Call
 [Link] Rate control during CS Voice call on HSPA ................................... 207
[Link] CS Voice channel type switch (DCH/DCH <-> HSPA) ................... 208
2.3.23 Blind IFHO in RAB Setup Phase (RAN2289) ......................................... 210
[Link] Successful Use Cases ..................................................................... 211
[Link].1 Failure handling .......................................................................... 231
[Link] Interaction with RAN3475 Buffer-free WCDMA-LTE Refarming
feature 237
2.3.24 Paging Optimization in I-HSPA ............................................................... 238
2.3.25 Domain Specific Access Class restriction .............................................. 242
2.3.26 RAN1905 DC-HSUPA ............................................................................. 242
[Link] DC HSUPA signalling figures .......................................................... 244
[Link] 3GPP message modifications ......................................................... 247
[Link].1 NBAP messages ........................................................................ 248
[Link].2 RANAP messages ...................................................................... 248
[Link].3 RRC messages .......................................................................... 248
[Link] Setting up DC-HSUPA ..................................................................... 249
[Link] Multi-RAB handling .......................................................................... 250
[Link] DC-HSUPA removal ........................................................................ 250
[Link] E-DCH Maximum Bitrate handling .................................................. 251
[Link] Radio link failure handling ............................................................... 252
2.3.27 RAN2108, RAN1263, RAN1742 and RAN1743 – BTS nack to
HSDPA/HSUPA/HSPA resource remove ............................................................. 252
[Link] Situations where BTS can reject the removal of E-DCH, HSDPA or
HSPA with Synchronised RL Reconfiguration procedure ................................. 253
[Link] Example operations that may lead to the rejection from BTS ........ 255
[Link] Basic principles for handling the BTS pool change cases .............. 256
[Link] Exceptions and special cases ......................................................... 256
[Link].1 PS RB inactivity (active -> inactive) with CS voice multiRAB in the
case that new activity indication arrives while the RL_Reonf_reattempt_timer
is running. 256
[Link].2 PS RAB/connection release with CS multiRAB in the same call
(CN initiated) ................................................................................................... 256
[Link].3 CS RAB setup with PS multiRAB (feature “CS+PS multiRAB” is
not in use) 257
[Link].4 Last RB release when Standalone SRB remains ...................... 257
[Link].5 PS RAB setup (PS multiRAB not supported on HSPA) and
repeated rejection from BTS .......................................................................... 257
[Link].6 Further handling of the hanging PS RB ..................................... 257
2.3.28 RAN1645 HSUPA 16 QAM ..................................................................... 258
[Link] UE and Cell level support in BTS .................................................... 258
[Link].1 HSUPA 16 QAM Support ........................................................... 258
[Link].2 E-DPCCH power boosting ......................................................... 259
[Link].3 E-DPDCH power interpolation ................................................... 259
[Link] 3GPP message modifications ......................................................... 259
[Link].1 NBAP messages ........................................................................ 259
[Link].2 RRC messages .......................................................................... 259
[Link].3 Local Cell Capability Information from BTS ............................... 260
[Link] Setting up HSUPA 16 QAM ............................................................. 261
[Link] Activation/de-activation handling ..................................................... 263
2.3.29 PS Conversational QoS for HSPA .......................................................... 264
[Link] Impacts on RANAP, RNSAP and NBAP procedures ...................... 265
[Link] RAB combinations with PS Conversational RAB ............................ 266
[Link] Handling of SIP signaling RAB ........................................................ 266
[Link] PS Conversational RAB setup ........................................................ 267

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 7(447)
Basic Call
 [Link] Failure cases during PS Conversational RAB setup ...................... 268
[Link] State changes are not applied during ongoing PS Conversational
RAB 268
[Link] Channel type switches are not applied during ongoing PS
Conversational RAB ........................................................................................... 268
[Link] Interaction with DC-HSDPA, DC-HSUPA, MC-HSDPA and MIMO 269
2.3.30 Robust Header Compression (RoHC) .................................................... 269
[Link] Impacts on RANAP and RRC procedures ...................................... 271
[Link] UE signals the support for RoHC during RRC Connection
Establishment ..................................................................................................... 276
[Link] PS Conversational RAB setup with RoHC ...................................... 276
[Link] PS Conversational RAB setup without RoHC ................................. 277
[Link] Failure cases during PS Conversational RAB setup ...................... 277
2.3.31 Smart LTE Layering (RAN2717), Smart LTE Layering for RU30
(RAN2943) ............................................................................................................ 277
[Link] LTE support is needed from the UE (RAN2717;RAN2943) ............ 281
[Link] Ordering UE to LTE layer by sending RRC:RRC CONNECTION
RELEASE message (RAN2717;RAN2943) ....................................................... 282
[Link] Prevention timer for layer change to LTE (RAN2717;RAN2943) ... 283
[Link] Existence of Pre-redirection info in RRC:RRC CONNECTION
REQUEST message (RAN2717;RAN2943) ...................................................... 283
[Link] Redirection to LTE is not triggered in emergency call cases
(RAN2717;RAN2943) ........................................................................................ 284
[Link] UE’s supported LTE bands capabilities are asked from the UE in
RRC connection setup phase (RAN2717) ......................................................... 285
[Link] The functionalities of the UE’s E-UTRA capability enquiry are
controlled with a PRFILE parameter 002:2136 RU40_MAINT_40 ................. 286
[Link] UE specific RRC acquires the list of LTE bands whose UE capability
is required 287
[Link] UE’s supported LTE bands capabilities are requested from the UE
only for limited set of frequency bands .............................................................. 288
[Link] When E-UTRA capabilities are requested from the UE during RRC
connection setup procedure, the SRBs are normally mapped to E-DCH in UL (in
Cell_FACH or Cell_DCH state) or to DCH using 13.6 kbps bit rate ................. 289
[Link] UE specific RRC crosschecks LTE band list of the DRNC against the
supported LTE band list received from the SRNC/source RAT ........................ 289
[Link] UE specific RRC does not request UE’s E-UTRA capabilities with UE
Capability Enquiry procedure if UL SRB is not mapped to E-DCH ................... 290
[Link] UE specific RRC does not request UE’s E-UTRA capabilities with UE
Capability Enquiry or with RRC Connection Setup in emergency call cases ... 290
[Link] UE’s supported LTE bands capabilities can be asked from the UE in
case of relocation (RAN2717) ............................................................................ 290
[Link] LTE band support is needed from the UE (RAN2717) ................... 292
[Link] Redirection to LTE can be prevented by core network (RAN2717) 292
[Link] RAN2717 and RAN2943 new counters ........................................... 293
2.3.32 Layering in RRC Connection Release (RAN2135) ................................ 293
[Link] RRC indicates to UE frequencies/frequency ranges for layering ... 294
[Link] RRC entity makes the decision of layer change ............................. 295
2.3.33 RAN2778 UE Periodic Measurement Report ......................................... 295
[Link] Activation of the feature in RU40 ..................................................... 296
[Link] Starting of periodic measurements in RU40 ................................... 297
[Link].1 Periodic UE Tx Power measurement in RU40 .......................... 298
[Link] Providing periodic measurements for Megamon usage in RU40 ... 298
[Link] Stopping of periodic measurements in RU40 ................................. 298

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 8(447)
Basic Call
 [Link] Interaction with RCPM and Subscriber Trace features in RU40 .... 299
2.3.34 Queueing and Priorisation of DSP/Transport resource requests ........... 300
2.3.35 RAN2509 Application Aware RAN(SPI promotion/demotion) ................ 301
[Link] Impacts on NBAP and RRC procedures ......................................... 301
2.3.36 Coverage and User Statistics in Traffica ................................................ 301
2.3.37 CS Call Silence Detection ....................................................................... 303
2.3.38 RRC Connection Setup Redirection ....................................................... 304
2.3.39 Measurement Based LTE Layering ........................................................ 306
[Link] LTE support is needed from the UE ................................................ 309
[Link] Compressed mode configuration for LTE neighbour measurement on
BTS/DRNC and UE ............................................................................................ 312
[Link].1 Failure during compressed mode configuration on BTS/DRNC
and UE 314
[Link] LTE neighbour measurement initiation on UE ................................ 315
[Link] LTE neighbour measurement reporting from UE ............................ 316
[Link].1 Failure during LTE neighbour measurement initiation on UE ... 318
[Link] UE redirection to LTE ...................................................................... 318
[Link] Interaction with LTE neighbour measurement and ‘state change
trigger’ to LTE ..................................................................................................... 319
[Link] Interaction with LTE neighbour measurement and ‘CTS trigger’ to
LTE 319
[Link] Interaction with LTE neighbour measurement and ‘CS RAB release
trigger’ to LTE ..................................................................................................... 320
[Link] Interworking with other features ...................................................... 320
[Link].1 Interworking with Fast Dormancy RAN2136 .............................. 320
[Link].2 Interworking with Fast Dormancy Profiling RAN2451 ............... 321
[Link].3 Interworking with CSFB .............................................................. 321
[Link].4 Interworking with Layering in RRC Connection Release RAN2135
323
[Link] RRC connection re-establishment during LTE neighbour
measurement ..................................................................................................... 323
[Link] CS RAB establishment during LTE neighbour measurement ........ 323
[Link] Interworking with Iu release ............................................................. 323
[Link] UE is not redirected to LTE after emergency call ........................... 324
[Link] Interworking with CPC - Continuous Packet Connectivity RAN1644
324
2.3.40 RAN2930 IMSI-based Call Monitoring.................................................... 324
[Link] Control Plane monitoring ................................................................. 325
[Link].1 Monitoring activation .................................................................. 325
[Link].2 Monitoring deactivation .............................................................. 326
[Link].3 Maintaining monitoring status .................................................... 326
2.3.41 RAN2510 In-Bearer Application Optimization ........................................ 327
2.3.42 RAN2496 Minimization of Drive Tests (MDT) ........................................ 328
[Link] Starting of periodic DL BLER measurement ................................... 328
[Link] Stopping of periodic DL BLER measurement ................................. 330
[Link] Interaction with RCPM and Subscriber Trace features................... 330
[Link] Starting of periodic UE Tx Power measurement ............................. 331
[Link] Stopping of periodic UE Tx Power measurement ........................... 333
[Link] UE measurements are not started in case of emergency call ........ 333
[Link] Ongoing UE measurements are stopped if emergency call is setup
334
[Link] Emergency call is identified from RAB parameters of CS call ........ 334
2.3.43 AMR Fault Detection at Userplane ......................................................... 335
2.3.44 RAN2892 WCDMA-LTE Load Balancing ............................................... 337

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 9(447)
Basic Call
 2.3.45 RAN3082 Device detection ..................................................................... 337
[Link] Core may provide IMEI to RNC ....................................................... 338
[Link] UE specific RRC checks if IMEI query is needed due to black- or
whitelisting 342
[Link] IMEI is not asked by UE specific RRC for calls with establishment
cause “Detach” ................................................................................................... 342
[Link] Placement of IMEI query in call signaling depends on the call type
342
[Link] UE specific RRC uses NAS signaling to ask the IMEI from UE ..... 344
[Link] UE specific RRC checks black-/whitelist status based on IMEI ..... 345
[Link] UE black-/whitelist decision depends on feature if IMEI is not known
when decision of black-/whitelisted functionality is made ................................. 345
[Link] IMEI query for Traffica ..................................................................... 345
[Link] Relocation and IMEI ........................................................................ 346
[Link] IMEI query problem handling .......................................................... 348
[Link] Features with black-/whitelisting...................................................... 348
2.3.46 RAN3093 Enhanced MBLB .................................................................... 350
[Link] RAN3093 is controlled by license key and cell level activation
parameters ......................................................................................................... 351
[Link] Blind IFHO in RRC setup indicating CS AMR speech call
establishment ..................................................................................................... 351
[Link].1 Interaction with RAN3475 Buffer-free WCDMA-LTE Refarming
feature 352
[Link].2 UE capability information received in the RR:RRC CONNECTION
REQUEST is used for definition of the preferred layer .................................. 353
[Link].3 Unsuccessful Blind IFHO in RRC connection request phase ... 353
2.3.47 RAN3253 IMSI Based Frequency Based HO......................................... 353
[Link] RAN3253 is controlled by license key and PRFILE parameters .... 354
[Link] The allowed 3G frequencies are configured with the legacy WSG and
WANE parameters ............................................................................................. 355
[Link] The UE specific RRC checks whether the UE is in allowed frequency
layer (cell) 355
[Link] RNC moves the UE away from the forbidden frequency when the first
RAB for the UE in question is being setup ........................................................ 355
[Link].1 UE specific RRC executes blind IFHO after first RANAP:RAB
ASSIGNMENT REQUEST in Cell_DCH state ............................................... 356
[Link].2 UE specific RRC executes blind IFHO after first PS NRT
RANAP:RAB ASSIGNMENT REQUEST in Cell_FACH state when UE is
moved to Cell_DCH state ............................................................................... 356
[Link].3 UE specific RRC executes blind IFHO after first CS RT
RANAP:RAB ASSIGNMENT REQUEST in Cell_FACH state ....................... 357
[Link].4 UE specific RRC executes redirection to GSM if Blind IFHO in
RAB Setup Phase is not possible or it does not succeed ............................. 357
[Link].5 UE specific RRC moves the Rel 5 UE to Cell_DCH state before
redirection to GSM in RAB Setup Phase ....................................................... 358
[Link] The UE specific RRC redirects the UEs to GSM if the layer change to
allowed layer fails or is not possible .................................................................. 359
[Link].1 The UE specific RRC selects the contents of the RRC:RRC
CONNECTION RELEASE for GSM redirection ............................................. 360
[Link].2 The UE specific RRC moves the Rel5 UE to Cell_DCH state
before redirection to GSM .............................................................................. 361
2.3.48 RAN2973 Enhanced IMSI Based Call Monitoring .................................. 361
[Link] Increased frequency of MAC throughput reporting for monitored calls
362

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 10(447)
Basic Call
 2.3.49 RAN3079 Dedicated Priorities ................................................................ 362
[Link] Information sending to UE after Common ID or Direct Transfer
messages received ............................................................................................ 364
[Link] Information sending to UE after Relocation Request message ...... 367
[Link] SPID information sending to UE via RRC message ....................... 369
2.3.50 RAN3110 HSPA Queueing and Resource Rotation with QoS .............. 371
[Link] UE specific RRC handles the victim RAB when NRT-over-NRT is
requested by the UE specific RRM .................................................................... 372
[Link] NRT-over-NRT over Iur ................................................................... 372
[Link].1 NRT-over-NRT triggered in DRNC ............................................ 372
[Link].2 Reception of RNSAP:RADIO LINK PREEMPTION REQUIRED
message in SRNC .......................................................................................... 372
[Link].3 Reception of RNSAP: RADIO LINK CONGESTION INDICATION
message in SRNC .......................................................................................... 373
[Link].4 NRT-over-NRT on the single NRT on HS(D)PA RAB over Iur .. 373
[Link].5 NRT-over-NRT on CS AMR on DCH + one NRT on HS(D)PA
RAB combination over Iur .............................................................................. 374
2.3.51 RAN3342 Predictive IMSI Based HO ..................................................... 374
[Link] RAN3342 is controlled by RNC license key of RAN3253 feature .. 375
[Link] PRFILE Parameter 002:2275 RU50_SPARE_13 is used to control
RAN3342 375
[Link] The allowed 3G frequencies are configured with the legacy WSG and
WANE parameters ............................................................................................. 376
[Link] Direct Resource Allocation is not applied to the UE in forbidden
frequency 376
[Link] UE is moved to allowed frequency after successful RAB Assignment
procedure in Cell_DCH state ............................................................................. 376
[Link] UE specific RRC performs legacy IFHO procedure if triggered by
Handover Control for UE in the forbidden frequency ........................................ 379
[Link] The UE is moved to allowed frequency after the UE is transferred
from CCH state to Cell_DCH state .................................................................... 380
[Link] Failed IFHO procedure .................................................................... 382
[Link] UE specific RRC performs legacy ISHO procedure if IFHO procedure
to move the UE from the forbidden frequency fails ........................................... 382
[Link] Failed ISHO to GSM for CS service or CS+PS multi-service ......... 383
[Link] Failed ISHO to GSM for PS service ................................................ 383
[Link] UE specific RRC handles the case when ISHO to GSM is not
possible or it does not succeed ......................................................................... 383
[Link].1 CS or CS+PS call dropped from forbidden layer ..................... 384
[Link].2 UE with PS only RAB is moved to CCH state ......................... 384
[Link].3 CS or CS + PS call is allowed to continue in forbidden layer .. 384
[Link].4 PS call is allowed to continue in forbidden layer in
Cell/URA_PCH state ...................................................................................... 385
[Link] Capacity request during CM measurements ................................... 385
[Link] RRC connection re-establishment................................................... 385
[Link] UE specific RRC evaluates the need for IFHO/ISHO after Relocation
in DRNC 386
[Link] UE specific RRC determines the Operator Id for the UE ................ 386
[Link] UE specific RRC prevents MBLB triggered Blind IFHO when UE is in
forbidden layer ................................................................................................... 386
2.3.52 RAN3405 Selective Roaming with Shared Area PLMNs ....................... 387
[Link] RAN3405 is controlled by PRFILE parameter ................................ 387
[Link] UE specific RRC checks that the UE is in the allowed cell after cell
resection 387

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 11(447)
Basic Call
 [Link] Feature interaction ........................................................................... 388
[Link].1 Prerequisite features .................................................................. 388
[Link].2 Features which cannot be used simultaneously with RAN3405 388
2.3.53 RAN3292 Idle Paging Repetition ............................................................ 388
[Link] Setting of the idle paging repetition indicator .................................. 389
2.3.54 RAN3431 Optimized CS Call Setup over Iur .......................................... 390
[Link] RAN3431 is controlled by RNC license key of RAN3228 feature .. 391
[Link] RAN3431 is controlled by the PRFILE Parameter and the License in
WCDMA17 release ............................................................................................ 392
[Link] RAN3431 is controlled by the Activation Parameter and the License
in WCDMA18 release ........................................................................................ 392
[Link] SRNC checks whether the Optimized CS Call Setup over Iur is to be
triggered 392
[Link] UE specific RRC initiates Optimized CS Call Setup over Iur
procedure 393
[Link] UE specific RRC ignores PS capacity requests during CS Call Setup
393
[Link] UE specific RRC rejects UE not involved Relocation initiations from
Handover Control during CS Call Setup ............................................................ 394
[Link] UE specific RRC releases the call if CS Call Setup fails ................ 394
[Link] SRNC handles CELL UPDATE via SRNC cell during the Optimized
CS Call Setup over Iur procedure ...................................................................... 394
[Link] UE specific RRC indicates that procedure is ongoing to L2 ........... 395
[Link] DRNC shall Handle the Optimized CS Call Setup over Iur procedure
as specified in legacy feature RAN3228............................................................ 395
2.3.55 RAN3376 Accelerated Voice Setup ........................................................ 395
[Link] Accelerated Voice Setup Signalling ................................................ 397
[Link] Accelerated Voice Setup Functionality Control ............................... 400
[Link] Accelerated Voice Setup CN Handling ........................................... 402
[Link] Accelerated Voice Setup Error Handling......................................... 403
[Link] Accelerated Voice Setup Feature Interworking with other Features
403
2.3.56 RAN3293 KPI Boost trough Refined RRM ............................................. 403
[Link] UE specific RRC ignores UL/DL capacity requests during AMR call
setup 404
[Link] Optimization of Activation time offset according to radio signal quality
404
2.3.57 RAN3401 Flexible QoS Differentiation ................................................... 404
[Link] Feature control ................................................................................. 405
[Link] UE spesific RRC reads the FlexibleQoSPriority from the selected
IUO object 405
[Link] UE specific RRC defines priorities used by QoS prioritization
according to RAB parameters received from RANAP/RNSAP and operator
configurable RNP parameters ........................................................................... 405
[Link].1 Branch addition over Iur ............................................................. 406
[Link].2 Relocation ................................................................................... 406
2.4 Optional functionality ...................................................................................... 406
2.5 Frozen features .............................................................................................. 406
2.6 Workarounds for not fully 3GPP compliant UEs and CNs............................. 406
2.6.1 UE issues ................................................................................................ 406
2.6.2 CN issues ................................................................................................ 414
2.7 Management parameters ............................................................................... 416
2.7.1 RAN930 PS RAB reconfiguration Support ............................................. 416
2.7.2 RAN285 HSPA Multi RABs parameters ................................................. 416

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 12(447)
Basic Call
 2.7.3 RAN1797 SRB mapping in RRC setup based on Establishment Cause
417
2.7.4 RAN1797 SRB DCH bit rate in RRC setup based on Establishment
Cause 418
2.7.5 RAN1797 RRC setup on CCH enabled for R99 UE............................... 419
2.7.6 RAN1797 CPICH Ec/No thr for SRB mapping in RRC setup ................ 420
2.7.7 RAN 1638 Flexible RLC .......................................................................... 420
2.7.8 RAN981 HSUPA 5.8 Mbps and RAN1470 HSUPA 2ms TTI ................. 421
[Link] HSUPA 2MS TTI Enabled ................................................................... 421
[Link] Interfaces: RAC <->RNC, EM <-> RNC, RACApp <-> RACMaximum
total uplink symbol rate ...................................................................................... 422
2.7.9 RAN1201 F-DPCH .................................................................................. 423
2.7.10 Emergency Call Redirect ........................................................................ 425
2.7.11 RAN1202: 24 kbps Paging Channel ....................................................... 425
2.7.12 RAN2051 Paging Optimization ............................................................... 425
[Link] IUCS - PagingOptSupport ............................................................... 425
[Link] IUPS - PagingOptSupport ............................................................... 426
2.7.13 CS enabling Handover ............................................................................ 427
[Link] IADA - CSVoiceServiceSupport ...................................................... 427
[Link] IADA – CSRedirWaitTimer .............................................................. 428
2.7.14 RAN1645 HSUPA 16QAM ...................................................................... 428
[Link] WCEL - HSUPA16QAMAllowed ...................................................... 428
[Link] RNC - ETFCIBoost .......................................................................... 429
[Link] RNC - DeltaT2TP ............................................................................. 430
[Link] RNC - EAGCHTable ........................................................................ 431
[Link] RNC - EDPDCHPowerInterUsage .................................................. 432
2.7.15 RAN2717 Smart LTE layering ................................................................ 433
[Link] WCEL – SmartLTELayeringEnabled ............................................... 433
[Link] RNMOBI - SmartLTELayeringPrevT .............................................. 434
2.7.16 Layering in RRC Connection Release (RAN2135) ................................ 435
2.7.17 WCEL - LayeringRRCRelEnabled .......................................................... 435
[Link] WCEL - LayeringRRCRelTargFreq ................................................. 435
[Link] WCEL-LayeringRRCRelTargFreq-TargFreqLower ......................... 435
[Link] WCEL - LayeringRRCRelTargFreq - TargFreqUpper..................... 436
2.7.18 RAN3093 Enhanced MBLB .................................................................... 436
[Link] WCEL – MBLBEnhancementsEnabled ........................................... 436
2.7.19 RAN3079 Dedicated Priorities ................................................................ 438
[Link] WSP – WSP Identifier (WSPId) ....................................................... 438
[Link] WSP – WCDMA Subscriber Profile related Iu Operator
(WSProfileRelatedIUO) ...................................................................................... 438
[Link] WSP – Subscriber Profile ID (SPID) ............................................... 438
[Link] WSP – WCDMA Subscriber Profile E-UTRA detection
(WSProfileEUTRADetection) ............................................................................. 439
[Link] WSP – Subscriber Profile PLMN Identifier (SubscriberProfilePLMNId)
439
[Link] WDP – WDP Identifier (WDPId) ...................................................... 440
[Link] WDP – Dedicated Priority Level (DedicatedPriorityLevel) .............. 440
[Link] WDP – Radio Access Technology (RadioAccessTechnology)....... 441
[Link] WDP – Absolute Radio Frequency Channel Number (ARFCN) ..... 441
2.7.20 RAN3292 Idle Paging Repetition ............................................................ 442
[Link] RNFC-Idle Page Repetition Enabled (IdlePageRepetitionEnabled) 442
2.8 Hidden parameters ......................................................................................... 442
2.9 Parameters and Timers .................................................................................. 442
3. Implementation Description .................................................................................. 445

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 13(447)
Basic Call
4. Change Description............................................................................................... 445
5. Open Issue ............................................................................................................ 445
6. APPENDICES ....................................................................................................... 445
6.1 Appendix A: UE or Vendor Specific Functionality.......................................... 445
6.1.1 Activation time shall be applied to the RB setup of NRT PS RAB ......... 445
6.1.2 Handling of the UE which are not fully 3GPP compliant ........................ 445
6.1.3 Uplink Traffic Volume measurement TX interruption time after trigger .. 445
6.1.4 RNC instruction UE in RRC state Cell_FACH to prohibit transitions ..... 446
6.1.5 GABFIL .................................................................................................... 446
6.2 Appendix B: AMR CALL time duration ........................................................... 446

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 14(447)
Basic Call
REVISION HISTORY
Version Date Modified Status
0.1 30.05.2006 Abdi-Hakim Yasin draft
0.2 22.08.2006 Abdi-Hakim Yasin Context Review version
0.3 31.08.2006 Abdi-Hakim Yasin Updated Contents after review
0.4 22.09.2006 Abdi-Hakim Yasin Pre-review version
0.5 25.10.2006 Abdi-Hakim Yasin Inspection version
0.6 24.11.2006 Abdi-Hakim Yasn Updated for inspection
0.7 17.01.2007 Abdi-Hakim Yasin Inspection correction added
after email inspection for
approval
1.0 22.01.2007 Abdi-Hakim Yasin Document version upgraded to
1.0 and forwarded to be
approved
2.0 15.02.2007 Abdi-hakim Yasin Following changes been done: -
figure 3 was redrawed, chapter
[Link] last 2 paragraphs
clarified, chapter [Link].1 CS-
CN Case rewritten totally,
Chapter [Link].8 rewritten and
chapter [Link].9 was removed
totally. Subchapter 5.1 removed
from Open issue chapter. Couple
of other minor changes done
also for approval. Document
version updated to 2.0.
2.1 18-10-2007 Tushar Mehra Checked Out from PI
2.2 18-10-2007 Tushar Mehra Added Implementation
Description Part
2.3 30-10-2007 Tushar Mehra Incorporated review comments
Added the HSDPA and HSUPA
introduction parts in Functional
Description
Changed Document Version to
3.0
3.0 31-10-2007 Tushar Mehra Approved Version
3.1 10-12-2007 Abdi-Hakim Yasin Baseline upgrade to RN4.0 level
3.2 14-02-2007 Abdi-Hakim Yasin Corrections from review added
for approval.
4.0 20-10-2008 Leila Luhtajärvi Baseline upgrade to RN5.0 level
Added HSDPA 64 QAM to
HDSPA enhancements.
4.1 05-11-2208 Rahul Sharma Added HSUPA 5.8 Mbps and
HSUPA 2ms TTI to HSUPA
Feature
4.2 28.-11-2008 Fan Jiang- Added Flexible RLC to HSDPA
Manninen enhancements.
4.3 2-12-2008 Ville Kurri Added RAN1797 Signalling
Performance Improvements
feature

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 15(447)
Basic Call
 4.4 8.12.2008 Pekka Anttalainen New I-BTS Sharing (RAN1759)
features added. NRT RAB
handling in anchoring, RNSAP
congestion and pre-emption
procedures.
4.5 5.1.2009 Fan Jiang- Added Flexible RLC relevant
Manninen new and modified IEs and
management parameter.
4.6 19.1.2009 Fan Jiang- Added Flexible RLC relevant
Manninen review comments for IEs feature
activation.
4.7 19.1.2009 Ville Kurri Modifications done after review
to RAN1797 Signalling
Performance Improvements
4.8 20.1.2009 Pekka Anttalainen Review findings corrected.
General and I-BTS Sharing
specific.
4.9 20.01.2009 Jukka Hartikainen Review findings: chapters
descriping MORAB and Flexible
Iu removed
4.10 21.01.2009 Fan Jiang- Correction to parameter table
Manninen add license statement to feature
description
4.11 22.1.2009 Pekka Anttalainen More review corrections.
4.12 22.1.2009 Rahul Sharma Review findings corrected for
HSUPA 2ms TTI and HSUPA
5.8 Mbps feature
4.13 27.1.2009 Pekka Anttalainen EFS CR#0114, RAN930
changes to PS RAB
reconfiguration chapter.
4.14 29.1.2009 Ville Kurri Wording changed to chapter
[Link].1
5.0 30.1.2009 Pekka Anttalainen Approved RN5.0 version.
6.0 20.7.2009 Narender Kumar Updated Implementation
Vivek Bhatia Description part in accordance
to RN5.0 Re-Arch
6.1 04.08.2009 Vivek Bhatia Review Comments Incorporated
6.2 09.09.2009 Jagmohan Patra Added the changes done for the
RAN 981 and RAN 1470
HSUPA 2ms TTI with 5.8 Mbps
feature

6.3 11.09.2009 Ajit Parkash Added the changes done for the
RAN1638 Flexible RLC feature

6.4 15.09.2009 Amit Kumar Added the changes done for the
RAN1201 Fractional-DPCH
feature

6.5 15.09.2009 Ajit Parkash Added the changes done for the
RAN1638 Flexible RLC feature

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 16(447)
Basic Call
 6.6 05.11.2009 Shagun singh LCS related changes removed.

6.7 23.11.2009 Pekka Anttalainen Added 24 kbps Paging channel,

maximum bit rate negotiation
and GTP cause value
6.8 23.11.2009 Pekka Anttalainen New L3 SW architecture
updated to chapter 2
6.9 26.11.2009 Leila Luhtajärvi Added RAN 1642 MIMO feature
6.10 01.12.2009 Jukka Hartikainen Added RAN2192 Asymmetric
AMR over Iur and in Relocation
(CR S1686)
6.11 25.02.2010 Katariina Forsblom Modified basic radio link
procedures for NBAP and
RNSAP part. Moved detail
description to NBAP and
RNSAP procedures FD. Added
reference to NBAP and RNSAP
procedures FD document.
6.12 19.04.2010 Tuula-Mari Rautala Added RAN1689 CS Voice over
HSPA feature.
6.13 23.4.2010 Ville Kurri Figure 64 updated
6.14 26.4.2010 Leila Luhtajärvi Ch.[Link] HSDPA 64 QAM
modified
6.15 27.04.2010 Minna Nevalainen Added RAN 1906 DC-HSDPA
42 feature
6.16 30.04.2010 Jukka Hartikainen Added RAN2289 Blind IFHO in
RAB Setup Phase
6.17 30.04.2010 Jukka Hartikainen Figure numbering corrected
6.18 04.06.2010 Deepak Ramani Updates for ADA3.0
6.19 21.06.2010 Deepak Ramani Incorporated comments from
document review for ADA3.0
6.20 28.06.2010 Leila Luhtajärvi Ch. [Link] MIMO 28 MBps
modified.
6.21 29.06.2010 Tuula-Mari Rautala Ch [Link] modified due to
review comment.
6.22 29.06.2010 Minna Nevalainen Ch [Link] modified due to
review comments
6.23 01.06.2010 Deepak Ramani Removing EFS references from
ADA3.0 updates
6.24 2.7.2010 Pekka Anttalainen Editorial changes
7.0 2.7.2010 Pekka Anttalainen Approved RN5.0EP1/ADA3.0
Version
8.0 2.7.2010 Pekka Anttalainen Copy from RN5.0EP1/ADA3.0
for RN6.0/ADA4.0 version. No
other changes.
8.1 12.8.2010 Pekka Anttalainen DC-HSUPA added.
8.2 27.8.2010 Pekka Anttalainen Updates to DC-HSUPA.
8.3 8.9.2010 Pekka Anttalainen Review comments added.
8.4 14.9.2010 Leila Luhtajärvi RAN 1912 MIMO with HSDPA
64 QAM and RAN 1907
DC_HSDPA with MIMO added.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 17(447)
Basic Call
 8.5 15.9.2010 Tapani Virtanen Flexible RLC UL is added to
chapter 2.3.11 HSUPA Feature
Functionality
8.6 12.10.2010 Tapani Virtanen Review findings updated to
Flexible RLC UL text
8.7 13.10.2010 Sampo From chapters HSDPA Feature
Mantovaara Functionality and HSUPA
Feature Functionality, some
RN50 level NBAP and IUR
descriptions moved to NBAP
and RNSAP Procedures FD.
8.8 15.10.2010 Tapani Virtanen Small corrections to my previous
update
8.9 18.10.2010 Tapani Virtanen NBAP IE related descriptions
are moved to NBAP and
RNSAP Procedures FD
8.10 19.10.2010 Pekka Anttalainen NBAP IE related to DC-HSUPA
descriptions are moved to NBAP
and RNSAP Procedures FD
8.11 27.10.2010 Deepak Tiwari RAN1645 HSUPA 16QAM
added
8.12 29.10.2010 Minna Nevalainen RAN2108, RAN1263, RAN1742
and RAN1743 – BTS nack to
HSDPA/HSUPA/HSPA resource
remove was added into chapter
2.3.28 after Pekka Anttalainen’s
changes and now it was
updated according to review
comments.
8.13 4.11.2010 Deepak Tiwari Review comments incorporated
for RAN1645 HSUPA 16QAM.
8.14 27.12.2010 Rahul Sharma Review comments incorporated
for E-DCH TTI reconfiguration
8.15 5.2.2011 Deepak Tiwari RAN2416 MC-HSPA, DB-
HSPA, PIC support with several
System Modules related
updates
8.16 01.03.2011 Deepak Tiwari Review comments incorporated
for RAN2416
9.0 13.4.2011 P. Anttalainen All track changes accepted.
New table added for new
common release independent
FD.
9.1 19.09.2011 Tapani Virtanen A comment is added about the
usage of Use Special Value of
HE Field IE, see Flexible RLC
feature, chapter [Link].2.
9.2 28.9.2011 Pekka Anttalainen REQ1587 added
9.3 30.9.2011 Pekka Anttalainen AC Task force updates / Faulty
protocol error handling during
RRC Connection setup
procedure added

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 18(447)
Basic Call
 9.4 19.10.2011 Tapani Virtanen Feature descriptions for PS
conversational QoS for HSPA
and RoHC added under chapter
2.3. Also a generic RNSAP
failure case added under
Flexible RLC in UL chapter.
9.5 21.10.2011 Tapani Virtanen Some additions and corrections
to feature description for PS
conversational QoS. Also
additions on chapters 1.2 and
2.2.
9.6 17.11.2011 Tapani Virtanen Update after the review
9.7 24.11.2011 Jukka Hartikainen RAN2717 Smart LTE Layering
added
9.8 29.11.2011 Tapani Virtanen Chapter [Link].2 is updated to
contain RAN2746 changes
9.9 08.12.2011 Tapani Virtanen RAN2746 text is updated with
the exact point when
RACH/FACH mapping is
updated to UE
9.10 13.12.2011 Tapani Virtanen The release of RAN715 and
RAN132 is updated
9.11 22.12.2011 Jukka Hartikainen Review corrections for
RAN2171 Smart LTE Layering
added
9.12 02.01.2012 Tapani Virtanen Update on RAN2746 text
(pronto 101802ESPE02)
9.13 09.01.2012 Jukka Hartikainen RAN2135 Layering in RRC
Connection Release added.
9.14 16.01.2012 Jukka Hartikainen RAN2135 Review corrections
added
9.15 28.02.2012 Jukka Hartikainen Updated according to EFS
CRS2097 (RAN2717)
9.16 28.02.2012 Jukka Hartikainen Updated according to PR
60389ESPE03 (RAN2289)
9.17 02.03.2012 Jukka Hartikainen Updated PR 60389ESPE03
(RAN2289) correction. PRFILE
parameter added
9.18 03.04.2012 Tapani Virtanen RAN2738 added
9.19 16.04.2012 Tapani Virtanen RAN2778 added
9.20 19.04.2012 Tapani Virtanen Small update on RAN2738
9.21 04.05.2012 Tapani Virtanen RAN2738 and RAN2778
updated after the review
9.22 10.05.2012 Tapani Virtanen small updated on RAN2778
9.3 23.05.2012 Jukka Hartikainen PR 60389ESPE03 correction
added for MBLB
9.4 29.05.2012 Jukka Hartikainen EFS CR845 change added to
RAN2717

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 19(447)
Basic Call
 9.5 29.05.2012 Oskari EFS CR#E0841 added to
Ruotsalainen RAN2778
EFS CR#E0841 added to
RAN2778

9.6 19.06.2012 Jukka Hartikainen Updated due to PR110689

9.7 25.6.2012 Tuula-Mari Rautala EFS CR#0324 Queueing and
priorization of DSP resource
request
9.8 02.07.2012 Tapani Virtanen CDSP-C tagged out from RU40
onwards. Relates to CR#0852
Removal of CDSP-C related
algorithms
9.9 22.8.2012 Pekka Anttalainen Added multi-RAB support to
RAN580, EFS CR#715.
9.10 24.8.2012 Jukka Hartikainen Updated according t oEFS
CR#771.
9.11 17.9.2012 Abhishek Jain RAN2509 updates
9.12 16.10.2012 Abhishek Jain RAN2509 Review Comments
Incorporated
9.13 16.10.2012 Aryadipta Dash RAN2591 Update
9.14 29.10.2012 Rahul Sharma RAN2117 update

9.15 30.10.2012 Oskari Updated due to PR

Ruotsalainen 36342ESPE06

9.16 10.11.2012 Rahul Sharma RAN2117 review comments

incorporated
9.17 14.11.2012 Abhishek Jain RAN2509 Review Comments
Incorporated
9.18 14.11.2012 Aryadipta Dash Removed 2591 Changes ,
added to L3 overload FD

9.19 24.11.2012 Rahul Sharma RAN2117 review comments

incorporated

9.20 07.01.2013 Jukka Hartikainen PR 69687ESPE03 clarification

added for RAN2289 failure
handling
9.21 21.01.2013 Jukka hartikainen PR 70003ESPE03 clarification
added for RAN2289 failure
handling

9.22 23.1.2013 Ville Kurri URA area restriction added

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 20(447)
Basic Call
 9.23 28.01.2013 Jukka Hartikainen Clarification of Paging handling
when IDT is received as IMSI
paging response when Paging
message has not been sent by
the RNC

9.24 29.01.2013 Jukka Hartikainen Added RAN2943 Smart LTE

Layering for RU30

9.25 31.01.2013 Jukka Hartikainen Correction to RAN2943

triggering conditions

9.26 04.02.2013 Jukka Hartikainen Correction to ver. 9.21

correction

9.27 12.03.2013 Jukka Hartikainen Addition to RAN2717/RAN2943

according to PR 70646ESPE03:
redirection only for UEs
redirected from LTE.
9.28 26.04.2013 Jukka Hartikainen CR1010 and CR1014 added to
RAN2017
9.29 29.4.2013 Pekka Anttalainen EFS CR#715 added, input from
Pekka Kohonen.

9.30 08.05.2013 Jukka Hartikainen Review corrections to

RAN2717/RAN2943 updated

9.31 21.05.2013 Jukka Hartikainen Second review corrections to

RAN2717/RAN2943 updated

9.32 29.5.2013 Pekka Anttalainen Added RAN2348 Coverage and

User Statistics in Traffica L3
effects
9.33 18.06.2013 Jukka Hartikainen RAN2717/RAN2943 updates
accepted
9.34 09.07.2013 Tuula-Mari Rautala EFS CRE0930 Queueing and
priorization of DSP resource
request updated in RU50
9.35 26.7.2013 Pekka Anttalainen Added chapter “Workarounds
for not fully 3GPP compliant
UEs and CNs”
9.36 20.8.2013 Pekka Anttalainen Review comments of previous
version updated.
9.37 23.08.2013 Tuula-Mari Rautala EFS CRE0930 updates
9.38 23.8.2013 Pekka Anttalainen Track changes removed from
9.36 changes
9.39 04.09.2013 Osmo Timonen Release of the CR#0852
Removal of CDSP-C related
algorithms changed RN7.0
→RN8.0

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 21(447)
Basic Call
 9.40 25.09.2013 Abhishek Jain EFS CR E1017 updates

9.41 15.11.2013 Rahul Sharma Removed the content of

RAN2117 feature from FD ,
RAN2117 content can be get
from sharenet revision number –
v71

9.41 18.11.2013 Rahul Sharma Removed RAN2117 old entry

from feature table
9.42 19.11.2013 Jukka Hartikainen RAN2717/RAN2943:
PR 131992ESPE02: Emergency
call handling expanded to all
SLL triggers and call cases
(RRC connection setup with
emergency call establishment
cause, emergency positioning)
PR NA05483786 Special
handling of emergency calls can
be deactivated
9.43 28.11.2013 Tapani Virtanen RAN147 added
9.44 05.12.2013 Rajat Lal Implementation Description
Section Contents moved to
“Basic Call [Link]”
9.45 19.12.2013 Tapani Virtanen RAN147 updated
9.46 24.12.2013 Aryadipta Dash RAN2211 Multicell HSDPA
changes incorporated in the FD.
9.47 07.01.2014 Tapani Virtanen RAN2980 added
9.48 20.01.2014 CRE0930 excel updated
Tuula-Mari Rautala
9.49 23.01.2014 Tapani Virtanen RAN2980 updated after review

9.50 24.01.2014 Aryadipta Dash RAN2211 updated after review

9.51 30.01.2014 Jukka Hartikainen RAN2930 added. CRE0930

excel updated for CSFB ISHO

9.52 20.02.2014 Tapani Virtanen Mentions about

NBAPCommMode parameter
removed from chapter 2.6
Management Parameters.
Related to CR#E1086
NBAPCommMode Parameter
Removal
9.53 28.2.2014 Tapani Virtanen RAN2980 updated based on
latest EFS updates
9.54 20.03.2014 Jukka Hartikainen Added note to RAN2717 about
the priority order of the LTE
frequencies.
9.55 31.03.2014 Abhishek Jain RAN 2510 updates
9.56 08.04.2014 Tapani Virtanen RAN2980 updated based on
EFS CR E1105 and PR
140531ESPE02

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 22(447)
Basic Call
 9.56 28.03.2014 Rajat Lal Added changes for the feature
RAN2578.
9.57 15.04.2014 Aryadipta Dash Added changes for the feature
RAN1905.
9.58 21.04.2014 Abhishek Jain RAN2510 Review comments
incorporated
9.59 26.04.2014 Aryadipta Dash Separate customer part and
internal part in Ran1905.
9.60 02.05.2014 Aryadipta Dash Added comments from Pekka
for Ran1905.
9.61 12.05.2014 Jukka Hartikainen Updated parameters
SmartLTELayeringEnabled
(RAN2980) and
SmartLTELayeringPrevT (PR
141868ESPE02/
43117ESPE07)
9.62 16.05.2014 Tapani Virtanen EFS CR E1105 addition on
RAN2980 is updated based on
review comments.
Radio Bearer Release
procedure ([Link].8) updated
with a PS CN interoperability
problem (PR NA05622518).
Clarified on chapters [Link].2,
[Link] and [Link].2 that
SRB4 is contained on current
configurations.
9.63 28.05.2014 Minna Nevalainen RAN2496 additions (mostly by
Risto Aalto)
9.64 28.05.2014 Tapani Virtanen Updates on EFS CR E1105
addition, Radio Bearer Release
procedure and SRB4 issue after
review
9.65 02.06.2014 Tapani Virtanen RAN2980 updated based on
EFS CR E1153. EUTRA
Feature Group Indicators IE is
added to UE capability chapter.
A possibility to redirect UE
blindly to LTE due to DCH (0/0)
and lack of LTE measurement
support is added on interaction
chapters with triggers.
A note is added to chapter
[Link].2 that default
configurations are not used
without Fast HSPA Mobility
(RAN2746/2738) in live
networks.
9.66 11.06.2014 Jukka Hartikainen RAN2930 updates approved
9.67 18.08.2014 Minna Nevalainen RAN2496 corrections after
review
9.68 19.06.2014 Tapani Virtanen CR E1153 addition updated
based on comments

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 23(447)
Basic Call
 9.69 04.07.2014 Tapani Virtanen Chapter [Link] updated based
on PR 111632ESPE01
9.70 2.9.2014 Pekka Anttalainen Pronto NA05451586 correciton
added, related to mute calls
9.71 16.9.2014 Tapani Virtanen Nokia Siemens Networks
changed to Nokia Solutions and
Networks on copyright
9.72 04.12.2014 Tapani Virtanen RAN2892 added
9.73 05.12.2014 Sowmya Updates for CR E1181 AMR
Jayananda Fault Detection at Userplane
9.74 07.01.2015 Tapani Virtanen RAN3220 changes updated
9.75 09.01.2015 Tuula-Mari Rautala CRE0930 excel updated
9.76 16.01.2015 Tapani Virtanen CRE1161 added
9.77 27.01.2015 Tapani Virtanen Internal tags added to
RAN3220. RAN2892 updated.
RAN3219 removals made
9.78 23.02.2015 Tapani Virtanen I-BTS Sharing removal related
to RAN3219
9.79 9.3.2015 Pekka Anttalainen EFS CR#1262 SDU parameter
modifications added
9.80 19.3.2015 Minna Nevalainen RAN3082 addition and
RAN2211 moved to internal
9.81 17.04.2015 Jukka Hartikainen RAN3093 added
9.82 22.4.2015 Minna Nevalainen RAN3082 modification
9.83 27.04.2015 Jukka Hartikainen RAN3093 review findings
incorporated
9.84 13.05.2015 Jukka Hartikainen Device Detection part of
RAN2289 updated according to
RAN3093 EFS update
9.85 01.06.2015 Tapani Virtanen EFS CR E2241 added
9.86 10.06.2015 Jukka Hartikainen RAN3253 added
9.87 12.06.2015 Tapani Virtanen E2241 updated
9.88 18.06.2015 Jukka Hartikainen RAN3253 review comments
incorporated
9.89 23.07.2015 Jukka Hartikainen RAN2973 added
9.90 11.09.2015 Jukka Hartikainen PR077901/PR078312
corrections added to RAN3253
9.91 02.10.2015 Jukka Hartikainen CRE1278 added
9.92 06.10.2015 Tapani Virtanen UE workarounds introduced by
PR073182 are added to
RAN2980
9.93 19.10.2015 Jukka Hartikainen PR NA05786422 corrections
added (MBR/EMBR)
9.94 25.11.2015 Jukka Hartikainen CRE1298 added
9.95 27.11.2015 Jukka Hartikainen CRE1298 review findings
incorporated
9.96 30.11.2015 Jukka Hartikainen Older figures’ Layout option
changed to Move with text
9.97 04.12.2015 Jukka Hartikainen CRE1298 clarification: If no LTE
neighbours in RNC then no E-
UTRA capability enquiry
9.98 5.1.2016 Ville Kurri RAN3079 Added and review
comments incorporated

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 24(447)
Basic Call
 9.99 18.02.2016 Jukka Hartikainen RAN3110 Added
9.100 22.02.2016 Tapani Virtanen Addition on Workarounds
chapter: PR093214 F-DPCH
does not work with some rel7
UEs
9.101 25.02.2016 Jukka Hartikainen RAN3110 review findings
incorporated
9.102 26.2.2016 Ville Kurri RAN3079 documentation review
comments incorporated to
feature description
9.103 11.03.2016 Tapani Virtanen PR NA05871096 changes added
relating to PR073182
9.104 16.03.2016 Tapani Virtanen Erroneous SDU Sending part of the
E1316 “RRM optimizations for
better MOS” is added
9.105 23.03.2016 Tapani Virtanen PR073182/ PR NA05871096
description updated. Mention added
also to UE Workaround chapter.
E1316 description transferred to
chapter [Link].1.1 RANAP RAB
Assignment Request
9.106 15.04.2016 Jukka Hartikainen NA05894654 correction added
9.107 10.06.2016 Tapani Virtanen E1316 updated with a note that
valid also during relocation
9.108 03.08.2016 Jukka Hartikainen RAN3342 Predictive IMSI Based
HO added
9.109 09.08.2016 Jukka Hartikainen RAN3342 review comments
incorporated
9.110 11.08.2016 Jukka Hartikainen RAN3405 added
9.111 24.08.2016 Jukka Hartikainen CRE1366 added
9.112 05.09.2016 Jukka Hartikainen RAN3405 review comments
incorporated
9.113 09.09.2016 Jukka Hartikainen CRE1366 review comments
incorporated
9.114 18.10.2016 Jukka Hartikainen CRE1391 added
9.115 22.11.2016 Jukka Hartikainen CRE1393 added
9.116 29.11.2016 Jukka hartikainen CRE1393 review comments
incorporated
9.117 16.12.2016 Jukka Hartikainen M1001C837 added to CRE1393
9.118 05.01.2017 Jukka Hartikainen CRE1381 added
9.119 05.01.2017 Jukka Hartikainen CRE1381 release changed to
WCDMA18
9.120 12.01.2017 Jukka Hartikainen CRE1381 review comments
incorporated
9.121 21.02.2017 Jukka Hartikainen Added releases to CRE1381
9.122 02.03.2017 Jukka Hartikainen Emergency call definitions
replaced by the reference to
Admission Control FD
9.123 26.07.2017 Jukka Hartikainen PR255362 added
9.124 10.08.2017 Jukka Hartikainen RAN3292 added
9.125 07.09.2017 Jukka Hartikainen RAN3431 added
9.126 05.10.2017 Sampo RAN3376 added
Mantovaara

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 25(447)
Basic Call
 9.127 17.10.2017 Sampo RAN3376 review corrections
Mantovaara
9.128 24.11.2017 Sampo RAN3376 interworking with
Mantovaara other features added
9.129 4.12.2017 Osmo Timonen CRE1428 ‘Support for Transport
layer change in RAB modify
procedure’ added
9.130 4.12.2017 Osmo Timonen Minor CRE1428 corrections
9.131 15.12.2017 Osmo Timonen Cause code mentioned in
CRE1428 (UL transport layer
address modification) changed
as ‘Invalid RAB Parameters
Combination’
9.132 29.12.2017 Sampo RNC RLC reset prevention
Mantovaara added ch. [Link].5
9.133 05.01.2018 Jukka Hartikainen Added LAU only case to
CRRE1366
9.134 22.01.2018 Jukka Hartikainen RAN3293 added
9.135 30.01.2018 Sampo CR#E1449 added to RAN3376
Mantovaara feature
9.136 28.02.2018 Jukka Hartikainen Optimized ATO setting added to
RAN3293
9.137 04.05.2018 Jukka Hartikainen RAN3475 added
9.138 15.05.2018 Jukka Hartikainen Removed Track Changes from
RAN3293 and RAN3475
9.139 29.8.2018 Jukka Hartikainen RAN3431: CAS-148690-B0G4
added: Relocation started
immediately after CS call setup
9.140 10.09.2018 Jukka Hartikainen RAN3401 Flexible QoS
Differentiation added
9.141 13.09.2018 Jukka Hartikainen RAN3401 review comments
incorporated
9.142 13.11.2018 Sampo CRE1492 description added to
Mantovaara RAN3376 content
9.143 20.12.2018 Sampo PR CAS-173140-Y7T4 added
Mantovaara
9.144 09.01.2019 Sampo PR CAS-173140-Y7T4 modified
Mantovaara
9.115 18.01.2019 Jukka Hartikainen CRE1507 added

Following table tells RAS release information of features. Features before FD version
9.0 are not necessary marked to the table.

RAN number Feature name RAS release

RAN1905 DC-HSUPA 23Mbps RU50 EP1
REQ1587 MultiRAB relocation towards Ericsson RU20EP1
RNC
FLTYRRCConnPro AC Task force updates / Faulty protocol RU20EP1
error handling during RRC Connection
setup procedure
RAN715 PS Conversational QoS for HSPA RU50
RAN132 Robust Header Compression – RFC3095 RU50

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 26(447)
Basic Call
 RAN2717 Smart LTE Layering RU40
RAN2746 Fast HSPA Mobility RU30 EP1 (Note: on
RU20 EP1 only for
SBM for Shinkansen
bullet train case)
RAN2135 Layering in RRC Connection Release RU40
RAN2738 Fast HSPA Mobility II RU40
RAN2778 UE Periodic Measurement Report RU30 EP2
CRE0930 Queueing and Priorisation of DSP RU20EP1 first
part of E0324 of resource request (part of RAN1803 L2 version?
RAN1803 resource management) RU50 updated version
RAN2509 Application Aware RAN RU40
RAN2943 Smart LTE Layering for RU30 RU30
RAN2348 Coverage and User Statistics in Traffica RU40
RAN2117 RNC2600 co-siting with multicontroller RU40
RNC (mcRNC) Removed the content
of RAN2117 feature
from FD ,
RAN2117 content can
be get from sharenet
revision number – v71
Removed section
2.3.37 of v71
Removal Date – 15
Nov 2013
RAN147 RRC Connection Setup Redirection RU50
RAN2211 Multi cell HSDPA RU60
RAN2980 Measurement Based LTE Layering RU50
RAN2930 IMSI-based Call Monitoring RU50 EP1
RAN2510 RAN2510 In-Bearer Application RU50EP1
Optimization
RAN2578 AMR Codec Set for 2G-3G RU50 EP1
RAN2496 Minimization of Drive Tests (MDT) RU50EP1
RAN2892 WCDMA-LTE Load Balancing WCDMA16
CR E1181 AMR Fault Detection at Userplane WCDMA16,
RN8.1MNT,
mcRNC4.1MNT
RAN3220 Obsolete Legacy Features Freezing in WCDMA16
WCDMA16
E1161 LTE Interworking Enhancement WCDMA16
RAN3219 Obsolete Legacy Feature Removals WCDMA17
E1262 SDU Error Ratio modification WCDMA 16
RAN3082 Device Detection WDCMA16
RAN3093 Enhanced MBLB WCDMA16
E2241 Compressed mode support for SRB with WCDMA16
PS NRT RAB mapped to 0/0
RAN3253 IMSI Based Fequency Based HO RU50EP1
RAN2973 Enhanced IMSI Based Call Monitoring WCDMA16
CRE1278 RAB parameter handling WCDMA17
CRE1298 E-UTRA capability enquiry changes RU50EP1
RAN3079 Dedicated Priorities WCDMA17
RAN3110 HSPA Queueing and Resource Rotation WCDMA17
with QoS

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 27(447)
Basic Call
 E1316 RRM optimizations for better MOS WCDMA16 MNT
RAN3253 IMSI Based Frequency Based HO WCDMA16
RAN3342 Predictive IMSI Based HO WCDMA16
RAN3405 Selective Roaming with Shared Area WCDMA 16
PLMNs
CRE1366 CS call setup time improvements WCDMA16 MNT
CRE1391 Workaround to avoid HSPA setup failure WCDMA16 MNT4
for bad behaving UE
CRE1393 Workaround for UEs which don't send WCDMA16 MNT5
START value after CS call re-
establishment
CRE1381 EARFCN extension WCDMA16 Maint
WCDMA17 Maint
WCDMA18
RAN3292 Idle Paging Repetition WCDMA17 MNT
RAN3431 Optimized CS Call Setup over Iur WCDMA17 MNT
RAN3376 Accelerated Voice Setup WCDMA17 MNT
CRE1428 Support for Transport layer change in WCDMA18 MNT
RAB modify procedure
RAN3293 KPI Boost through Refined RRM WCDMA18 MNT
RAN3475 Buffer-free WCDMA-LTE Refarming WCDMA19
RAN3401 Flexible QoS Differentiation WCDMA19
CRE1492 UE Release Specific Limitation for WCDMA18 MNT
RAN3376 Usage
PR CAS-173140- Buffering of CONNECT added into WCDMA18 4.0
Y7T4 RAN3376 Accelerated Voice Setup
Scenario
CRE1507 Successful counter update failed for PS WCDMA19 MP1
session setup because of UE bug (wrong
UE capability info)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 28(447)
Basic Call
 Introduction

1. INTRODUCTION
1.1 Purpose and scope
This document gives an overview about Basic Call functionality in RNC
and describes how the functionality has been implemented in the RNC.
The document is used as an input for Customer Documentation and
reference documentation in feature specification and testing planning
(functional testing and system testing). Document is a baseline document
and it is updated per a release to cover new functionality and
implementation, which has been developed in the release in question.

This FD also covers ADA3.0 functionality with respect to Basic Call

functionalities.

All RN5.0 functionalities stated in this document are applicable to ADA3.0,

unless stated explicitly otherwise.

The Iub between ADA and BTS is internal to the i-BTS. ADA supports
only IP transport for Iub. All AAL2/ATM related details for Iub in this
document are not applicable for ADA3.0. For details regarding IP
transport over Iub, please refer to [IP transport FD].

All references to ICSU and DMCU are not applicable to ADA3.0. The
equivalent functional units in ADA3.0 are

• GFCP corresponding to ICSU

• USUP (UE Specific functions and services in User Plane) and

CSUP (Cell Specific functions and services in User Plane)
corresponding to DMCU.

Please refer to [Architecture Description for ADA3.0] for further details.

1.2 Concepts and abbreviations

AAL ATM Adaptation Layer
AAL2 ATM Adaptation Layer 2
AC Admission Control
ADA I-HSPA Adapter
ALCAP Access Link Control Application Part
AESA ATM End System Address
AM Acknowledged Mode
AMR Adaptive Multirate Codec
ARQ Automatic Repeat request
ASU Active Set Update
AT Activation Time
BCCH Broadcast Control Channel (logical)
BCH Broadcast Channel (transport)
BER Bit Error Ratio
BLER Block Error Ratio
BTS Base Transceiver Station
CPICH Common Pilot Channel

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 29(447)
Basic Call
 Introduction

C-RNTI Cell RNTI

CRNC Controlling RNC
CS Circuit Switched
CCCH Common Control Channel (logical)
CDMA Code Division Multiple Access
CM Compressed Mode
CSFB CS Fallback
CSeHO CS Service Enabling Handover
CSUP Cell Specific User Plane
DC-HSUPA Dual Cell High Speed Uplink Packet Access
DCH Dedicated Channel (transport)
DCCH Dedicated Control Channel (logical)
DDT Downlink Direct Transfer
DL DownLink
DPCH Dedicated Physical Channel
DRNC Drift DRC
DRA Direct Resource Allocation
DRX Discontinuous Reception
DSAC Domain Specific Access Control
E-DCH Enhanced Dedicated Channel
FACH Forward Access Channel
FACH-c Forward Access Channel entry
FCH Forward Channel
FCCH Forward Control Channel
FD Functional Description (specification document)
F-DPCH Fractional Dedicated Physical Channel
FP Frame Protocol (entity)
FRLC Flexible RLC
GFCP Generic Functionality in Control Plane unit
HC Handover Control
HO Hand Over
HHO Hard HandOver
HSCC HSPA Serving Cell Change
HSDPA High Speed Downlink Packet Access
HSPA High Speed Packet Access
HSUPA High Speed Uplink Packet Access
GPRS General Packet Radio Service
GSM Global System for Mobile communication
GTP GPRS Tunnelling Protocol
IE Information Element
IDNNS Inter-Domain NAS Node Selector
I-HSPA Internet HSPA
IMSI International Mobile Subscriber Identity
IMEI International Mobile Equipment Identity
IP Internet Protocol
Iu Interconnection point between RNC and CN
Iub Interface between RNC and BTS
Iur Logical interface between two RNCs
L1 Layer 1, Physical Layer
L2 Layer 2, Data Link Layer
L3 Layer 3, Network Layer
LA Location Area
LAC Location Area Code
LAI Location Area Identity

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 30(447)
Basic Call
 Introduction

LAU Location Area Update

LCGLocal Cell GroupMAC Medium Access Control
MAC-c/sh Medium Access Control entity for handling common channels
MAC-d Medium Access Control entity for handling dedicated channels
MAC-ehs Enhanced MAC high speed
MAC-e/es MAC entity for handling enhanced dedicated transport channel
(E-DCH); fixed RLC UL PDU size is used
MAC-i/is MAC entity for handling enhanced dedicated transport channel
(E-DCH); flexible/fixed RLC UL PDU size is used
MBMS Multimedia Broadcast and Multicast Service
LC Load Control
MCC Mobile Country code
MGW Multimedia Gateway
M2M Mobile to Mobile
MM Mobility Management
MMS Multimedia Message Service
MNC Mobile Network Code
MOC Mobile Originated Call
MSC Mobile Switch Centre
MSS MSC Server System
MTC Mobile Terminated Call
NAMR Narrowband AMR
NAS Non-Access Stratum
NRT Non-Real-Time
NRI Network Resource Identifier
O&M Operational and Management
OoB Out-of-Box
PCH Paging CHannel (transport)
PCCH Paging Control CHannel(logical)
PDCP Packet Data convergence Protocol
PDP Packet Data Protocol
PDU Packet Data Unit
PhCH Physical Channel
QAM Quadrature Amplitude Modulation
QoS Quality of Service
P-TMSI Packet-TMSI (Temporary Mobile Subscriber Identity)
PVC Permanent Virtual Connection
PRACH Physical RACH
PS Packet Scheduler
RA Routing Area
RAB Radio Access Bearer
RAC Radio Area Code
RACH Random Access Channel
RAN Radio Access Network
RAB Radio Access Bearer
RAT Radio Access Technology
RB Radio Bearer
RCPM Radio Connection Performance Measurement
RFCI RAB subflow Combination Indicator
RL Radio Link
RLC Radio Link Control
RNC Radio Network Controller
RNP Radio Network Planning
RNTI Radio Network Temporary Identifier

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 31(447)
Basic Call
 Introduction

RM Resource Manager
ROHC Robust Header Compression
RRC Radio Resource Control
RRM Radio Resource Management
RRCPRB Radio Resource Control Program Block
RSCP Received Signal Code Power
RT Real-Time
RTCP Real Time Control Protocol
RTP Real Time Protocol
SCCP Signalling Connection Control Part
S-CCPCH Secondary Common Control Physical CHannel
SDU Service Data Unit
SGSN Serving GPRS Support Node
SIB Master Information Block
SFN System Frame Number
SIP Session Initiation Protocol
SMS Short Message Service
S-RNTI SRNC Radio Network Temporary Identifier
SRNS Serving RNC
SRB Signalling Radio Bearer
SPC Signalling Point Code
SSD Source Statistics Descriptor
TEID Terminal End-point Identifier
TFCC Transport Format Combination Control
TFCS Transport Format Combination Set
TFO Tandem Free Operation
TMSI Temporary Mobile Subscriber Identity
TrFO Transcoder Free Operation
TFS Transport Format Set
TrCH Traffic Channel
TRM Transport Resource Manager
TVM Traffic Volume Measurement
UE User Equipment
UE-RRC MCC/CCM/RRC-d counterpart in the UE
UE-RLC RLC counterpart in the UE
UDI Unrestricted Digital Information
UDP User Datagram Protocol
UDT Uplink Direct Transfer
UL Up Link
UM Un-Acknowledged mode
UMTS Universal Mobile Telecommunications System
UP User Plane
URA UTRAN Registration Area
UTRAN UMTS Terrestrial Radio Access Network
U-RNTI UTRAN RNTI
USIM User SIM
USSD Unstructured Supplementary Service Data
USUP UE Specific User Plane
Uu Radio interface between UTRAN and UE
VoIP Voice over IP protocol
WAMR Wideband AMR
WCDMA Wideband Code Division Multiple Access

CCM

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 32(447)
Basic Call
 Introduction

RRC entity (MCC and/ or CCM / RRD-d) is a serving RNC functionality

responsible for the RRC connection specific signalling management and
information (UE Context) management for one UE.

CRNC
There is only one Controlling RNC for a certain BTS. The Controlling RNC
has the overall control of the logical resources of its BTS's. The
Controlling RNC can be SRNC or DRNC for a certain UE.

Ec/No
Ratio of energy per modulating bit to the noise spectral density.

LCG

Local Cell Group refers to grouping of a set of local cells for which BTS
internal resources are pooled together.

NBAP-c
Executes the common NBAP-procedures (e.g. RL Setup) based on the
requests received from the RRC/CCM and executes BTS
configuration/recovery signaling based on O&M.

NBAP-d
Executes the dedicated (UE-specific NBAP-procedures) based on the
requests received from the RRC/CCM.

PCDP
Packet Data Convergence Protocol (PDCP) implements PDCP layer
processing, T-PDU buffering and part or all of GTP layer processing.
PDCP exchanges u-plane data PDUs with RLC via shared memory
buffer.

Primary frequency/layer in DC-HSUPA

Frequency/layer (frequency and layer as synonym in this feature) which
provides the full set of uplink control channels.

RAB
Radio Access Bearer is used for the transfer of user data. One or more
independent and simultaneous UE-CN Radio Access Bearer connections
can exists for each user.

RB
Radio Bearer is the service offered by the Access Stratum between RNC
and UE on the top of layer 2

RRA
RRA-master manage all necessary functionalities in ICSU for BTS and
cells (like NBAP-link creation/removal, cell setup)
It also manage BTS/Cell data and give local “DB” service to other SW
modules.
RRA-CMA hand manage common channels (creation, supervision and
BCCH info) as like RRC-S and RRC-C in old architecture (before RN5.0).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 33(447)
Basic Call
 Introduction

RRB
RRBPRB handle for example RRC connection requests and paging as
like RRC-C in old architecture

RRC entity
RRC entity (MCC and/ or CCM / RRD-d) is a serving RNC functionality
responsible for the RRC connection specific signalling management and
information (UE Context) management for one UE.
Part of RRC functionalities are implemented in RRA and RRB program
blocks.

Radio Link
Is a logical association between a single User Equipment and a single
UTRAN access point. Its physical realisation comprises one or more radio
bearer transmissions. Radio Link is a bi-directional connection between a
terminal and one cell of a base station [Nokia_NBAP].

Secondary frequency/layer in DC-HSUPA

Frequency layer which provides uplink DPCCH, E-DPCCH and E-DPDCH

for this specific UE.

Signalling Connection

Signalling connection is divided into two parts: RRC connection and IU

connection. This implies that the UE may have separate signaling
connections, one to each CN domain (packet and circuit switched).

C-RNTI
C-RNTI (Cell Radio Network Temporary Identity) is used by UE to identify
itself to the controlling RNC in a cell and by controlling RNC to address the
UE in a cell. C-RNTI is allocated by controlling RNC upon UE accessing a
new cell. C-RNTI shall be unique within the accessed cell. Controlling RNC
shall know the D-RNTI associated to the C-RNTI within the same logical
RNC (if any).

IP TRANSPORT

3GPP Release 5 introduces IP transport option as an alternative to ATM

transport due to the layered structure of the UMTS protocol architecture. IP
Based Iu-PS and IP Based Iu-CS has been introducted in RN4.0

Also IP based is transported in all (Iu, Iur and Iub) interfaces used in RNC.

RSCP

Received Signal Code Power. Average power of the received signal after
despreading and combining, if only signal power is received.

S-RNTI
S-RNTI is used by UE to identify itself to the Serving RNC, by SRNC to
address the UE and by DRNC to identify the UE to Serving RNC

U-RNTI

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 34(447)
Basic Call
 Introduction

U-RNTI (UTRAN Radio Network Temporary Identity) - is allocated to an UE

having an RRC connection and identifies the UE within UTRAN and in
signalling messages between UE and UTRAN. U-RNTI is allocated for all
UEs having a RRC connection; it is allocated by the SRNC. U-RNTI is
reallocated always when the SRNC for the RRC connection is changed.

URA
URA (UTRAN Registration Area) – a predefined group of cells, which is
used by the RNC RRC to administer the location of the UE in UTRA RRC
connected mode. URA identifier(s) is/are broadcast on the BCCH. The
UE must make URA update when it enters a cell with a new URA
identifier.

URA_PCH
URA_PCH state is very similar to Cell_PCH state. Basically the difference
is that UE executes URA Update when URA area changes and when
paging is needed to be initiated it is sent to all cells within the URA area.

USERPLANE TRANSPORT ADDRESS

IP transport setup
RNC shall receive UDP port number and IP address of destination node
via RANAP signal RANAP: RAB ASSIGNMENT REQUEST or in relocation
case via RANAP: RELOCATION REQUEST then RNC shall determine the
IP based route that can be used for destination node.

Transport Layer Address

Each AAL2 termination point is assigned with individual AESA address
(ATM end system address). AESA is used by the BTS to select a correct
AAL2 termination point for user plane connections. One AAL2 termination
point can contain several PVCs.

Soft HO Branch
Soft Ho branch corresponds to Iub/Iur DCH data stream of one radio link
or several radios links in case the macrodiversity combining is done
already at the WCDMA BTS.

Tandem Free Operation (TFO)

Tandem Free Operation is the configuration of a connection with two
transcoders that support TFO protocol and whose external coding
schemes are compatible, thus enabling compressed speech to pass
between them. When the TFO protocol is not supported by both
transcoders or the coding schemes are not compatible then normal
“Tandem” operation occurs and PCM encoded speech is passed between
them.

Transcoder Free Operation (TrFO)

A call configuration where no transcoder device is physically present and
hence no control or conversion or other functions associated with it are
activated.

A Cell

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 35(447)
Basic Call
 Introduction

Is identified by a UTRAN Cell identifier (UC-id). The Cell can be created

and removed by administrative procedures (NBAP: Cell Setup and NBAP:
Cell Deletion). When a Local Cell, i.e. equipment in a BTS, is made
available to the CRNC for configuration of a cell, the CRNC can configure
the cell with configuration data, common physical channels and common
transport channels in the BTS (by using NBAP: Cell Setup and NBAP:
Common Transport Channel Setup procedures). Configuration of a cell
over the Iub interface cannot be successful unless the BTS has reported a
Local Cell Id as available to the CRNC.

W-AMR
Wideband AMR, Subset (12.65, 8.85, 6.6) is supported.
N-AMR
Narrowband AMR, Subset (12.2, 7.95, 5.90, 4.75) is supported.

VAHAUS, VALMIS

VAHAUS is a shared memory file library for VALMIS. VALMIS is a UE

hand specific data and parameter file. VAHAUS library belongs to Radio
Resource Utilization Service Block (RRUSEB) and to RNC Control Plane
development area. VAHAUS library and VALMIS shared memory file were
introduced in RN7.0 program to reduce message exchange between UE
specific RRC, HC, UE specific RRM and L3CPRB. Instead a UE hand
specific data file is utilized.

<RAN2930/begin>
<internal/begin>
Monitoring Agents

These are the monitoring data providers at each monitored functional unit
of the RNC.

Centralized Resource Control

Resource Control (RC3) at the RSMU/CFCP.

Decentralized Resource Control

Resource Control (dedicated RC3) at the ICSU/USCP/CSCP.

Centralized Monitoring Entity (CME)

A generic entity that is deployed at the OMU and performs the function of
communicating the monitoring conditions and filters to the data providers
(agents) from each plane.

<internal/end>
<RAN2930/end>
<RAN3082/start>

Blacklist functionality:

Blacklist (exclusive): A certain IMEIs are not allowed to use the feature

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 36(447)
Basic Call
 Introduction

- The ones Blacklisted may not use the functionality even in case having
the capability

- Use case: Operator blocks a certain misbehaving UEs

IMEISV

- The feature functionality will be based on the IMEISV being carried at

the signalling phase (3GPP TS 23.003).

- The IMEISV is composed of the following elements (each element shall

consist of decimal digits only):

- TAC: Type Allocation Code (TAC). Its length is 8 digits;

- SNR: Serial Number (SNR) is an individual serial number uniquely

identifying each equipment within each TAC. Its length is 6 digits;

- SVN: Software Version Number (SVN) identifies the software version

number of the mobile equipment. Its length is 2 digits.

- IMEISV is applied within the MM procedures (NAS signalling). The

RAN3082 and subsequent features utilize the TAC and SVN fields from
the IMEISV.

8 digits 6 digits 2 digits

TAC SNR SVN

IMEISV 16 digits

TÜV SÜD BABT (Organization handling the TAC allocation):

- TÜV SÜD BABT was formed as the British Approvals Board for
Telecommunications (BABT) in 1982 and has since grown to become the
world’s leading telecommunications certification Body. TÜV SÜD BABT
has expanded its services outside of the telecoms industry and now
provides product certification to the marine, consumer, electronics, and
renewable energy sectors.

- TÜV SÜD BABT are contracted by the GSM Association to allocate

IMEIs and administer the GSM Association's IMEI database. This
includes the registration of companies onto the IMEI database and the
allocation of TAC (part of the IMEI) numbers.

Whitelist functionality:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 37(447)
Basic Call
 Introduction

Whitelist (inclusive): A certain IMEIs (TAC+SVN) are allowed to use the

feature

- Only the ones that are Whitelisted are allowed to use the feature if
having the capability

- Use case: Operator allows only certain UEs to use a certain

feature/functionality

<RAN3082/end>

1.3 References
/4/ TS 25.331: Radio Resource Control

/5/ TS 25.413: UTRAN Iu interface RANAP signalling

/6/ TS 25.423: UTRAN Iur interface RNSAP signalling

/7/ TS 25.433: UTRAN Iub interface NBAP signalling

/8/ Admission Control FD

/9/ TS 25415: UTRAN Iu interface user plane protocols

/10/ TS 23.153: Out of band transcoder protocol

/11/ TS 23.053: Tandem Free Operation (TFO)

/12/ Location Services in RNC FD,

/14/ Service Area Broadcast, FD

/15/ Packet Scheduler, FD

/16/ ITU-T Rec. Q.2630.1 AAL Type 2 Signaling Protocol 12/99

/17/ Parameter Dictionary Data Base

/18/ RRC State Transitions for Packet Data FD

/19/ L3 Security FD

/20/ Hard Handover and SRNC Relocation FD

/21/ Resource Supervision and Recovery FD

/29/ User Plane Functionality for RN5.0 FD

/35/ HSDPA RRM in RNC FD
/40/ NBAP and RNSAP Procedures FD

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 38(447)
Basic Call
 Functionality description

/41/ 3GPP TS 26.101 Adaptive Multi-Rate (AMR) speech codec

frame structure

/42/ 3GPP TS 26.201 Adaptive Multi Rate - Wideband (AMR-WB)

speech codec frame structure

/44/ HSUPA RRM in RNC FD

/46/ I-HSPA Rel3.0 System Architecture Document
/47/ Handover Control FD
/51/ Architecture Description for ADA3.0
/52/ IHSPA Resource Management (Control Plane Domain)
Specification
/53/ L3 overload FD
/54/ 3GPP TS 36.331: "Evolved Universal Terrestrial Radio
Access (E-UTRA); Radio Resource Control (RRC); Protocol
Specification"
/55/ RISE database (counter descriptions)
[Link]
[Link]/ContentViewer/RISEViewer
/56/ Basic Call ID : [Link]
[Link]/Overview/D50620842
9 /57/ PDCP FDd
/58/ User Plane FDd

2. FUNCTIONALITY DESCRIPTION
2.1 General
This description of Basic Call includes call set-up and releasing a speech
or data connection between end-user equipment (UE) and the core
network (CN). Basic Call is a high-level name describing the functions
required for Mobile Originated Call (MOC) and Mobile Terminated Call
(MTC) handling within a RNC. Generally speaking, the RNC should
perform number of activities before a call can be connected through.
Those activities are Paging, RRC connection setup, Radio Link Setup, UE
– CN signaling setup and maintaining, Radio Bearer Management, etc.

2.2 Basic Call Functionality

Basic Call or transfer sequence can functionally be divided into separate
phases based on used channel or RRC state, which the call attempt must
pass in order to perform through connection. Phase I: Signaling
connection setup between the RNC and a specific UE. Phase II: Setting
up userplane trasnport between BTS and RNC. Phase III: UE-CN

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 39(447)
Basic Call
 Functionality description

signaling setting up. Phase V: Setting up userplane transport between

RNC and CN. Phase VI: Connection Establishment between UE and CN.

TYPICAL RT CALL PHASES:

DCH

SRB

Idle

Call Call duration Idle time

setup
time

Figure 1: RT Call phases

Generally, calls can be divided into two main groups in respect to RNC
and that depends on whether the call is real time or non real time. In call
setup processing, MOC setup is quicker than MTC case. We could further
be looked into more call type definitions such as:

AMR CALL

AMR Call is a call with RAB/RB QoS parameters (Traffic Class=

Conversational, Source Statistics Descriptor= Speech). For example, the
RRC setup has been done with cause codes: MOC Conversational, MTC
Conversational and Emergency call.

UDI CALL

UDI Call is a call with RAB/RB QoS parameters: Traffic Class=

Conversational, Source Statistics Descriptor= Unknown. For example in
this case, the RRC setup has been done with a cause codes: MOC
Conversational or MTC Conversational

PS CONVERSATIONAL CALL

PS Conversational Call is a PS domain RT call with RAB/RB QoS

parameters (Traffic Class= Conversational, Source Statistics Descriptor
(SSD) = Speech or Unknown). SSD value “Speech” refers to VoIP and
SSD value “Unknown” refers to video or real-time text service.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 40(447)
Basic Call
 Functionality description

STREAMING CALL

Streaming Call is a call with RAB/RB QoS parameters are: Traffic Class=
Streaming. For example in this case, the RRC setup has been done with
a cause codes: MOC Streaming and MTC Steaming.

NRT CALL

NRT Call is a call with RAB/RB QoS parameters are : Traffic Class:
Interactive or Background. For example in this case, the RRC setup has
been done with a cause codes: MOC Interactive, MTC Interactive, MOC
Background or MTC Background. The call setup can be done after the
registration.

In detail description level, we could make deep analysis on the basic call
and see what each call carries in terms of quality control parameters and
other detail arrangements.

In this chapter both MOC and MT basic call procedures messages and,
signaling connection between the user terminal (UE) and CN are
introduced.

<not in ADA3.0/begin>Typical average MO case of AMR call setup time is

2.4 – 2.9 seconds where a typical MTC AMR call setup time is 3.6
seconds<not in ADA3.0/end>

<ADA3.0/begin>
Typical average MO AMR call setup time shall be less than 2.6 seconds
with Standalone DCCHRate 13.6 kbps and shall be less than 3.6 seconds
with Standalone DCCHRate 3.4 kbps.
Typical average MT AMR call setup time shall be less than 1.9 seconds
with Standalone DCCHRate 13.6 kbps and shall be less than 3.4 seconds
with Standalone DCCHRate 3.4 kbps. <ADA3.0/end>

SMS

Mobile Originated, Mobile Terminated and Mobile-to-Mobile SMS transfer.

Message is relayed through SMSC so M2M = MOC + MTC.

Transfer routing is possible via CS core or PS core.

Typical transfer phases:

SRB

Idle

Message
transfer time
Figure 2: MOC and MTC SMS transfer phases

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 41(447)
Basic Call
 Functionality description

HTTP

Download HTTP pages from server

Transfer phases and RRC state transfers:

HSDPA

DCH 384

DCH 64 Idle time 1

FACH
Idle time
2

PCH

Connection time Transfer Think time

duration

Figure 3: example of RRC state transfer

MMS

Mobile originated, Mobile Terminated and Mobile-to-Mobile MMS transfer.

Message is relayed through SMSC so M2M = MOC + MTC.

Typical transfer phases are similar to HTTP.

WAP

WAP page download from server. Most used applications are News, E-
mail and M-commerce (e.g. Vodafone Live!)

Typical transfer phases are similar to HTTP. TCP connection is made to

MMS GW. An HTTP request is used for downloading the objects.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 42(447)
Basic Call
 Functionality description

FTP

Files are downloaded from or uploaded to an external server. Mainly used

for testing purposes. Music downloads; broadcasts etc. may also be
implemented with FTP.

Typical transfer phases are similar to HTTP.

Real-Time (RT) and Non Real-Time (NRT)

The UMTS services/bearers are divided into Real Time (RT) and Non-
Real Time (NRT), each of these having a different quality classes. These
RT and NRT services have also different error ratios, BLER (Bit Loss
Error Ratio), and BER (Bit Error Ratio). Delay sensitivity is from 100 ms to
seconds.

Real-Time services (RT) involve both MOC and MTC speech and data
calls, as well as real time packet switched (PS) data transitions.

Non-real time (NRT) handles only packet switched transitions. Packet

data transfer states in UE modes and states are needed in order to
efficiently manage non-real time (NRT) radio access bearer (RAB) users.
URA_PCH is taken in use in our RNC in RN4.0 onward releases..

UMTS Radio Access Bearers (RABs)

There are introduced four different QoS classes (or traffic classes) for
UMTS bearer service and Radio Access bearer service:

• Conversational class.
• Streaming class.
• Interactive class.
• Background class.
The main distinguishing factor between these classes is how delay
sensitive the traffic is: Conversational class is meant for traffic, which is
very delay sensitive, while Background class is the most delay insensitive
traffic class.
UE Modes and states

The aim of the RNC is to be able to maintain Radio Resource

Management (RRM) and it has RNC-RNC interface (Iur) interface for this
purpose. The RNC has different functions to control this entity which has it
tow main states: Idle and Connected. From UE – Network connection
point of view, the RRC changes is its states from idle to connected state.

For further information regarding to the UE modes and states are

described in more detail “RRC State Transitions for Packet Data FD”
document. Following figure is represented in higher level RAB types.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 43(447)
Basic Call
 Functionality description

RABTypes
Call

CS Call PS Call

Interactive Class Background Class

CS Data Call CS Voice Call PS Data Call
PS Data Call

NRT Data Call

Conversational Class Streaming Class Conversational Class Streaming Class

CS Data Call
CS Data Call PS Data Call PS Data Call

RT Data Call

18 © 2005 Nokia RAN [Link] / 2005-12-15 / MNi

Figure 4: Higher level RAB types.

Non-real time services (NRT) only involve packet switched data calls. For
non-real time services, the radio access bearer is created without
immediately reserving radio resources. The resources are allocated on
demand by using the signaling link between the UE and RNC.

The location of UEs that have NRT and /or RT RABs is known either at
cell level or on URA level, depending on the RRC state that the UE is in.
The location of the UE is only known when it is in UTRA RRC connected
mode.

2.2.1 Mobile Originated Call Case

In this chapter describes how real time bearer (CS Call) is allocated and
handled. The whole process is summarized in a following figure that
depicted in following with brief descriptions of the steps. Next two
subchapters discuss the whole MOC case in more detail.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 44(447)
Basic Call
 Functionality description

UE RNC CN

RRC connection establishment

“ CM Service Request”
message

Authenticatio
n
Ciphering Control Request

Setu
Call
p
proceeding

RAB Setup Request

User B
Call
alerted
connected

FFigure 5: High level MOC case

In summary, setting up a mobile originated call typically involves the

signalling – at the originating end as in show above figure. The
highlighted part represent radio access network specific signaling
functions and it will be this part that we discuss and explore more in detail
in coming chapters. If a mobile user answers an incoming call, the
situation is slightly different.

[Link] Mobile Originated Call (Circuit Switched)

In MOC procedure case, Mobile user or a UE makes a call. In this case,

UE is an idle mode, so an RRC connection establishment is normally
performed directly to the Cell_DCH state as depicted following figure.

Note: RRC connection can be optionally established on common channes

(Cell_FACH). See chapter Common Channel Setup.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 45(447)
Basic Call
 Functionality description

UE BTS RNC MSC

1. RRC: RRC CONNECTION REQUEST

2. NBAP: RADIO LINK SETUP REQUEST

3. NBAP: RADIO LINK SETUP RESPONSE

USER PLANE SETUP

4. RRC: RRC CONNECTION SETUP

L1 synchronization

5. NBAP: RADIO LINK RESTORE INDICATION

6. RRC: RRC CONNECTION SETUP COMPLETE

7. RRC: INITIAL DIRECT TRANSFER

8. RANAP: INITIAL UE MESSAGE

UE – CN signalling

9. RANAP: COMMON ID

10. RANAP: SECURITY MODE COMMON

11. RRC: SECURITY MODE COMMON

12. RRC: SECURITY MODE COMPLETE

13. RANAP: SECURITY MODE COMPLETE

14. RANAP: RAB ASSIGNMENT REQUEST

15. NBAP: RADIO LINK RECONFIGURATION PREPARE

16. NBAP: RADIO LINK RECONFIGURATION READY

USER PLANE SETUP

USER PLANE SETUP

17. NBAP: RADIO LINK RECONFIGURATION COMMIT

18. RRC:RADIO BEARER SETUP

19. RRC: RADIO BEARER SETUP COMPLETE

20. RANAP: RAB ASSIGNMENT RESPONSE

Connection established

Figure 6: Mobile Originated Call (MOC) case

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 46(447)
Basic Call
 Functionality description

Summary of the steps in the figure:

1- RRC CONNECTION REQUEST

UE leaves the idle mode and initiate establishment of an RRC connection

by sending the RRC: RRC CONNECTION REQUEST message over
RACH to the RNC. The message is sent by RRC protocol entity of UE on
logical channel CCCH and contains: Initial UE Identifiers, Establishment
cause value, protocol erro indicatior, UE specific behaviour information,
Initial UE Capability indication, measured results on RACH, etc.

This message is received by RRBPRB. RRC/MCC receives this message

from RRB and RRC/CCM forwards this request to UER/HA3 master
process which handles a HO and Admission control related issue.

2 AND 3 – RADIO LINK SETUP REQUEST / RESPONSE

After RNC reserves a requested resources it requests an allocation of

dedicated radio resources for the signaling from BTS side. NBAP-c entity
of RNC sends NBAP: RADIO LINK SETUP REQUEST message to BTS.
This message includes Cell ID, frequency, Transport Format Sets, uplink
scrambling code, DL channelization code and power control information
required for setting up the Dedicated Control Channel (DCCH). This
message is received by NBAP-c entity of BTS and After BTS sets up
transport layer address AAL2 Address and AAL2 binding identity for the
new DCH then returns to RNC response NBAP: RADIO LINK SETUP
RESPONSE message.

USER PLANE TRANSPORT SETUP

AAL2 Signalling Setup

ALCAP entity of RNC sends a “ ESTABLISH REQUEST” message to

ALCAP entity of the BTS for setting up communication channel using
previously mentioned AAL2 binding and BTS after it reserve the
requested communication channel resource it responses “ ESTABLISH
CONFIRM” message. Now there is AAL2 signalling link between RNC
and BTS. After that FP entities of both RNC and BTS synchronizes both
uplink and downlink connections.

AAL2 signalling setup and release are outside the scope of this
document.

IP based Transport Setup

For IP transport setting up, RNC shall receive UDP port number and IP
address node via RANAP signal RANAP: RAB ASSIGNAMENT
REQUEST or in relocation case via RANAP: RELOCATION REQUEST
message. RNC shall determine the IP based route that can be used for
destination node.

4- RRC CONNECTION SETUP

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 47(447)
Basic Call
 Functionality description

After dedicated control channel has been setup from previous steps,
RRC: RRC CONNECTION SETUP message is sent to UE by
RRC/MCC/RRB over the Forward Access Channel (FACH), dedicated
channel resources are allocated to the UE and the UE is transferred to
the Cell_DCH. This message is received by RRC entity of UE and it
includes the initial UE identifier, the Radio Network Temporary Identity
and other parameters that are related to the dedicated control channel
that has been setup. After that the UE performs a NAS connection
establishment to the CS-CN. After the service negotiation has been
carried out between the UE and CS-CN, the CS-CN sends a RAB
assignment request to the RNC.

5- L1 SYNCHRONIZATION AND RADIO LINK RESTORATION

INDICATION

L1 synchronization between the UE and BTS takes place and after that
the synchronization success between BTS and UE is completed then BTS
notifies the RNC that L1 synchronization has been achieved with D-NBAP
NBAP: RADIO LINK RESTORE INDICATION message

6- RRC CONNECTION SETUP COMPLETE

The UE acknowledges successful setup of the RRC: RRC CONNECTION

REQUEST message by sending a RRC : RRC CONNECTION SETUP
COMPLETE message over the recently established dedicated control
channel to the RNC. The information in the message includes the UE
radio access capability such as the list of supported security algorithms,
etc.

TRANSPARENT MESSAGES

After UE and RNC connection is established, the UE and CN perform

higher layer NAS signalling messages before actual radio access bearer
(RAB) setup. These NAS messages are transparent to the RNC and they
are sent over the Dedicated Control Channel (DCCH) that has been
established earlier.

7- RRC INTIAL DIRECT TRANSFER

The UE sends an RRC: INTIAL DIRECT TRANSFER message to the

RNC. This message carries the initial NAS message, in this case “ CM
Service Request” indicating the destination or CN ID –The CS-CN/PS-CN
that user wishes to place a call or send a data. The RNC shall establish
signaling connection and forward the NAS message of the RRC: INITIAL
DIRECT TRANSFER message to the CN using a RANAP: INITIAL UE
MESSAGE.

8- RANAP INTIAL UE MESSAGE

The initial NAS message is then carried without modification from the
RNC to the CS-CN/PS-CN in the RANAP “Initial UE Message”

When the RNC receives an RRC: INITIAL DIRECT TRANSFER

message, and determines that no signaling connection to the indicated
domain is active, the RNC shall generate the RANAP: INITIAL UE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 48(447)
Basic Call
 Functionality description

MESSAGE message to be transferred to the CN node as determined by

the NAS Node Selection Function – if this function is active, or otherwise
to the default CN node with the following contents (Location Update
Request, CM Service Request, Paging Response, IMSI Attach and IMSI
Detach, etc).

UE – CN SIGNALLING

The authentication and key generation is started in order to secure the

communication channel between EU and CN before it started to be used.

9-RANAP COMMON ID

The CN send a this message, afer it has ensured the identitiy of UE. CN
informs to the RNC permanent NAS UE identity (IMSI).

10- SECURITY MODE COMMAND

The Core Network (CN) starts ciphering control functions by sending

RANAP message “Security Mode Command” to the RNC. RANAP
message include integrity and ciphering in formations then RNC start to
establish DL direction integrity and ciphering functionality by sending RRC
message RRC: SECURITY MODE COMMAND.

12- RRC SECURITY COMMAND COMPLETE

UE then answers back to RRC message RRC: SECURITY MODE

COMMAND COMPLETE to the RNC and UL ciphering is setup. RNC
forward to RANAP message RANAP :SECURITY MODE COMMAND
COMPLETE to the CN.

14- RAB ASSIGNMENT REQUEST

Radio Access Bearer (RAB) is used for the transfer of the user data.
RNC shall support multiple CS RABS core network as result of IP Based
Iu_PS and IP Based Iu_CS functionality. It is always the CN that initiate
the establishment of a Radio Access Bearer by sending RANAP message
RANAP: RAB ASSIGNMENT REQUEST to RNC.

The RNC analyses the radio access bearer service parameters and
checks whether there are enough resources for the requested radio
access bearers. After that, the RNC activates or modifies the physical
uplink and downlink radio channels from the BTS (s) and establish the
transmission channels at the Iub and Iur interfaces according to reserved
radio resources. Then the RNC sends to the BTS the new radio link
parameters on the existing signaling link.

15- RADIO LINK RECONFIGURATION PREPARE

RNC request the BTS to prepare the establishment of the DCH to carry
the RAB using D-NBAP: RADIO LINK CONFIGURATION PREPARE
message. This message includes the list of DCHs to add, UL DPCH
information, DL DPCH information, Transport Format Set (TFS),
Transport Format Combination Set (TFCT) and Power Control Information
to the BTS.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 49(447)
Basic Call
 Functionality description

16- RADIO LINK RECONFIGURATION READY

After that BTS returns a NBAP: RADIO LINK RECONFIGURATION

READY message to the RNC. This message contains RL IDs, DCH
information such as AAL2 address, etc.

AAL2 /IPSIGNALLING SETUP

Detail explanation of AAL2/IP setup and release is left outside this

document.

17- NBAP RADIO LINK RECONFIGURATION COMMIT

RNC defines the activation time of the new configuration and sends
NBAP: RADIO LINK RECONFIGURATION COMMIT message to the BTS
in order BTS to adapt the new configuration for the radio line into use.

18- RADIO BEARER SETUP

The RNC sends the RRC: RADIO BEARER SETUP message to the UE
over an existing dedicated control channel (DCCH). This message
contains parameters related to the dedicated channel that has been set
up for carrying the radio access bearer such as Transport Format Set
(TFS), Transport Format Combination Set (TFCS), and Downlink
Channelization code. T.

19- RADIO BEARER SETUP COMPLETE

The UE returns back the RRC message RRC:RADIO BEARER SETUP

COMPLETE to the RNC over the dedicated control channel. This
message includes RB information, UL TrCH information, DL TrCH
information, PhyCH information, UL radio resources and DL radio
resources.

20- RANAP RAB ASSIGNMENT RESPONSE

The RNC sends the RANAP message RANAP: RAB ASSIGNMENT

RESPONSE message indication to the CN that RAB establishment was
successful.

[Link] Mobile Originated Call (Packet Switched)

Mobile originated call in Packet Switched case is mostly similar to the

Circuit Switched case described above.

Note: RRC connection can be optionally established on common channes

(Cell_FACH). See chapter Common Channel Setup.

The main difference lays establishment of GTP tunnel between RNC and
CN instead of AAL2 as in the case of CS. Other difference is that there is
no direct resource allocation, means no DCH allocation for NRT.

A PS call setup is realized by a RANAP: RAB Assignment procedure.

This procedure is always initiated by CN. Purpose of the procedure is to
establish new RAB connections, or modify and release existing RAB
connections.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 50(447)
Basic Call
 Functionality description

In a role of a CN network element, PS-CN initiates RAB Assignment

procedure by sending RAB Assignment Request message to RNC.

When the PS RAB has been successfully created and UE want to send
something, It haven’t yet been allocated resources, so it first sends
measurement report (TVM) message for capacity allocation. For that
reason, RNC send to RRC: MEASUREMENT CONTROL message to
UE.

RNC sends UL packet data to the GTP tunnel endpoint signalled by PS-
CN in RANAP: RAB ASSIGNMENT REQUEST message, and PS-CN
sends DL packet data to the GTP tunnel endpoint signalled by RNC in
RANAP: RAB ASSIGNEMENT RESPONSE message.

UE BTS RNC SGSN

1. RRC: RRC CONNECTION REQUEST

2. NBAP: RADIO LINK SETUP REQUEST

3. NBAP: RADIO LINK SETUP RESPONSE

User Plane Setup

4. RRC: RRC CONNECTION SETUP

The UE is in CELL_DCH State

L1 sync

5. NBAP: RADIO LINK RESTORE INDICATION

6. RRC: RRC CONNECTION SETUP COMPLETE

7. RRC: INTIAL DIRECT TRANSFER

8. RANAP: INTIAL UE MESSAGE

UE – CN signalling

9. RANAP: COMMON ID

10. RANAP: SECURITY MODE COMMAND

11. RRC: SECURITY MODE COMMON

12. RRC: SECURITY MODE COMPLETE

13. RANAP: SECURITY MODE COMPLETE

14. RANAP:ASSIGNMENT REQUEST

GTP Tunnel Setup

15. RRC:RADIO BEARER SETUP

16. RRC:RADIO BEARER SETUP COMPLETE

17. RANAP:ASSIGNMENT RESPONSE

[Link]: MEASUREMENT CONTROL

Traffic Volume Measurement

Waiting of UL/DL
capacity request is
started in RRC layer

Connection established (CELL_DCH state)

Figure 7: Mobile-originated call (PS)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 51(447)
Basic Call
 Functionality description

2.2.2 Mobile Terminated Call Case

In MTC procedure case, the process is the same as MOC case but
difference is only PAGING procedure. Paging is the procedure by which a
mobile network attempts to locate the UE within its location area before
any other network-initiated procedure can take place. In MTC case, the
called user must be notified about the incoming call, the core network
initiates the paging procedure.

Figure
8: High
UE RNC CN level
MTC
case

Paging Paging

RRC connection establishment

“ Paging Response” message

Authenticatio
n
Ciphering Control Request

Setup
Call
proceeding
RAB Setup Request

Call
confirmed
[Link] Mobile Terminated Call (Circuit Switched)

MTC case is similar to MOC except this time, the CN originate the call
and UE is in receiving end. In this case of mobile terminated call, the
user or UE must be notified about the incoming call and when the UE is in
idle mode it must be paged first before any other network imitated
procedure can take place.

CN initiates the paging procedure by sending a RANAP message

RANAP: PAGING to RNC. RNC checks then whether the UE is engaged
in an ongoing RRC connection and if there is no connection then RNC
broadcasts the paging message “PAGING TYPE 1”.

RNC sends this broadcast paging message over the Paging Channel to
all cells belongs to the paging area. After receiving paging message the
UE responds by sending the RRC message RRC: RRC CONNECTION
REQUEST over the Random Access Channel (RACH) to the RNC. From
this point onwards the transactions performed in a MTC case follows the
same principle as MOC case that are discussed [Link].

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 52(447)
Basic Call
 Functionality description

UE BTS RNC MSC

1. RANAP: PAGING

2. RRC: RRC PAGING TYPE 1

3. RRC: RRC CONNECTION REQUEST

4. NBAP: RADIO LINK SETUP REQUEST

5. NBAP: RADIO LINK SETUP RESPONSE

User plane Setup

6. RRC: RRC CONNECTION SETUP

L1 synchronization

7. NBAP: RADIO LINK RESTORE INDICATION

8. RRC: RRC CONNECTION SETUP COMPLETE

9. RRC: INTIAL DIRECT TRANSFER

10. RANAP: INITIAL UE MESSAGE

UE – CN signalling

11. RANAP: COMMON ID

12. RANAP: SECURITY MODE COMMAND

13. RRC: SECURITY MODE COMMOND

14. RRC: SECURITY MODE COMPLETE

15. RANAP: SECURITY MODE COMPLETE

16. RANAP: RAB ASSIGNMENT REQUEST

17. NBAP: RADIO LINK RECONFIGURATION REPRARE

18. NBAP: RADIO LINK RECONFIGURATION READY

User Plane Setup

User Plane Setup

19. NBAP: RADIO LINK RECONFIGURATION COMMIT

20. RRC: RADIO BEARER SETUP

21. RRC: RADIO BEARER SETUP COMPLETE

22. RANAP: RAB ASSIGNMENT RESPONSE

Connection established

Figure 9:Mobile-terminated call (CS)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 53(447)
Basic Call
 Functionality description

[Link] Mobile Terminated Call (Packet Switched)

UE BTS RNC SGSN

1. RANAP: PAGING

2. RRC: PAGING TYPE 1

3. RRC:RRC CONNECTION REQUEST

4. NBAP: RADIO LINK SETUP REQUEST

5. NBAP: RADIO LINK SETUP RESPONSE

User Plane Setup

6. RRC:RRC CONNECTION SETUP

L1 sync

7. NBAP: RADIO LINK RESTORE INDICATION

8. RRC: CONNECTION SETUP COMPLETE

9. RRC: INTIAL DIRECT TRANSFER

10. RANAP: INITIAL UE MESSAGE

UE – CN signalling

11. RANAP: COMMON ID

12. RANAP: SECURITY MODE COMMAND

13. RRC: SECURITY MODE COMMAND

14. RRC: SECURITY MODE COMPLETE

15. RANAP: SECURITY MODE COMPLETE

16. RANAP: RAB ASSIGNMENT REQUEST

GTP Tunnel Setup

17. RRC: RADIO BEARER SETUP

18. RRC: RADIO BEARER SETUP COMPLETE

19. RANAP: RAB ASSIGNMENT RESPONSE

20. RRC: MEASUREMENT CONTROL (Setup)

Connection established (CELL_DCH state)

Figure 10:Mobile-terminated call (PS)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 54(447)
Basic Call
 Functionality description

2.2.3 IDLE State Procedures

[Link] Idle Mode Measurements

In idle mode, the UE performs neighboring cell measurements based on

information received on the BCCH. For each monitored cell, the BCCH
indicates identification data of the cell. In this mode the UE does not send
any measurements to RAN.

After sending the initial random access message, the UE continues the
handover measurements by using the ‘idle’ mode parameters until an RRC:
MEASUREMENT CONTROL (SETUP) message is received from the
SRNC's RRC signaling entity. This message indicates the parameters to
be used for measurements in connected mode and the handover
measurements are modified after the each active set update; see more in
these from [Hard Handover and SRNC Relocation FD] document.

Monitored cells are grouped in the UE into three mutually exclusive

categories:

1. Cells that belong to the active set. User information is sent from all
these cells and they are simultaneously demodulated and coherently
combined. These cells are involved in soft handover.

2. Cells that are not included in the active set, but are monitored for
handover belong to the monitored set.

3. Cells, which are not included in the active set, and are detected by the
UE without receiving a neighbour list from the RAN, belong to the
detected set.

[Link].1 Handover Measurements

Information related to this functionality is discussed in [Hard Handover

and SRNC Relocation FD document].

[Link] Paging Procedures

The core network is able to determine in which location area or routing

area the subscriber is located. Paging is necessary in order for the CN to
know to which BTS and cell a specific UE is currently linked. In idle mode,
paging is always initiated by the CN. In CS paging, the CN and further the
RNC broadcast paging messages through base stations of the location
area in which the UE is situated. In PS paging, the CN and further the
RNC broadcast paging messages through base stations of the routing
area in which the UE is situated.

The paging of the UE is initiated and scheduled by the RNC. The RNC
packs pages to a L3 paging message and transmits them transparently
over the Iub. Upon receipt of the paging message and if access to the
network is allowed, the addressed UE initiates the RRC connection setup
procedure. On receipt of the RRC: RRC CONNECTION REQUEST
message, RNC uses a Radio link Setup procedure to activate dedicated
uplink and downlink radio channels at BTS.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 55(447)
Basic Call
 Functionality description

<ADA3.0/begin>

In I-HSPA network Paging Optimization feature can be enabled to reduce

the paging signalling load at the CN. For further details on this feature refer
to the section 2.3.21. The Paging optimization feature does not impact the
internal paging handling within an ADA.

<ADA3.0/end>

[Link].1 RANAP Paging

The RNC shall receive paging requests (RANAP: PAGING) from the core
network over the Iu interface The RANAP: PAGING message includes
paged UE identity. The RNC shall distribute paging requests to all cells,
which belong to the paging area, where the UE is currently registered.
Cells of one BTS may belong to different paging areas.

Idle mode UEs shall be paged using the TMSI, P-TMSI or IMSI at the
radio interface.

[Link].2 Idle Mode Paging

In this case, the RNC checks whether the paged UE is engaged in an

ongoing radio resource control (RRC) connection. If there is no
connection, the RNC starts the idle mode paging procedure.

The procedure using the PAGING TYPE 1 message is referred to as

paging procedure in the 3GPP RRC specification.

UE BTS RNC CN

UE has no RRC connection

RANAP: PAGING

RRC: PAGING TYPE 1

RRC connection establishment

Paging response

Figure 11: Paging type 1 message

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 56(447)
Basic Call
 Functionality description

Each RANAP: PAGING message on the Iu interface is related to only one

UE and therefore the RNC shall pack the pages into the relevant radio
interface paging message on PCCH.

If the paged UE is already in connected mode, in CELL_PCH or

URA_PCH state, Paging Type 1 procedure with U-RNTI shall be applied
on [Link] UE is in CELL_DCH or CELL_FACH state when CN sends a
RANAP PAGING message, then RRC: PAGING TYPE 2 message is
used. More information on PAGING TYPE 2 can be referred to [ RRC
State Transitions for Packet Data FD ] .

Note: The URA contains a set of Cells. The URA amount per RNC is
limited. The maximum number of the Paging Areas (RAC+LAC+URA) per
one RNC is 400.

Initialization of idle mode paging

The RNC shall receive paging requests (RANAP: PAGING) from the core
network over the Iu interface. The RNC shall then check whether the
paged UE is engaged in an ongoing RRC connection. If there is no
connection, the RNC shall initiate the idle mode paging procedure. The
RANAP: PAGING message includes paged UE identity. The RNC shall
distribute paging requests to all cells, which belong to the paging area,
where the UE is currently registered. Cells of one BTS may belong to
different paging areas. Idle mode UEs shall be paged using the TMSI or
P-TMSI, in included in the RANAP: PAGING message.

Addition of idle mode pages to PCCH paging message

The RNC shall collect paging requests for the idle UE’s (and for the UE’s
in CELL_PCH or URA_PCH state) and append the pages to RRC:
PAGING TYPE 1 message. This message shall then be transmitted on
the PCCH/PCH using TM RLC. The RRC: PAGING TYPE 1 message can
include CN originating pages for idle mode UE’s and UTRAN originating
pages for connected mode UE’s (including pages originating from another
CN for connected mode UE’s in state CELL_PCH or URA_PCH).

Generation of RRC: PAGING TYPE 1 message

The RNC shall generate RRC: PAGING TYPE 1 message. If the encoded
RRC: PAGING TYPE 1 message does not fill a PCH transport block, the
RRC layer shall add padding. Segmentation of the message to several
PCH transport blocks is not allowed

For CN originated pages, CN is responsible for possible RANAP:

PAGING message repetition.

<RAN3292/beging>

If the feature RAN3292 Idle Paging Repetition has been activated (for CS
or both CS and PS paging), the RNC repeats each Idle Mode RRC:
PAGING TYPE 1 messages two times. This is done also for CN repeated
Idle Paging messages. See chapter 2.3.53 RAN3292 Idle Paging
Repetition.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 57(447)
Basic Call
 Functionality description

<RAN3292/end>

[Link].3 Distribution of paging message for UEs in Idle Mode

For an UE in idle mode, the RNC shall include the idle mode page to
RRC: PAGING TYPE 1. If the 'Paging Area ID' IE is not included in the
RANAP: PAGING message, the whole RNC area shall be used as paging
area if no signalling connection exists for that UE.

[Link].4 Paging Priorisation

Prioritisation will be done for both Idle and Connected mode UE related
paging procedures.

Note
Connected Mode paging procedure is out of the scope of this document. This
procedure is described in to /18/ [RRC State Transitions for Packet Data FD]
functional description.

Priorisation improves throughput of first-time pagings in the network and

to reduce number of unnecessarily repeated pagings. Paging messages
are divided into two priority groups (high and low priority) in L3 and being
scheduled in the L2 (MAC-c) accordingly.

Upon receiving of the paging message from Core Network (CN), RRC
entity determines priority of the message. The first-time paging and
paging messages related to system information update is given high
priority and repetition of an earlier received paging message is set as low
priority.

RRC entity passes the paging message to the cell-specific L2 (MAC-c)

entity. The message includes information of the priority of the paging.
Based on this in L2, the message is placed to the corresponding paging
queue to be scheduled at the appropriate time (MAC-c schedules the
paging messages so that the high priority queue is prioritised over the low
priority queue whenever possible. And the paging messages that could
not be scheduled on time are discarded).

[Link].5 Determination of DRX cycle length for UEs in idle mode

The RNC shall determine the DRX cycle length value for an idle UE
based on the default value of a "CN domain specific DRX cycle length ",
which is retrieved from the radio network database, see [18]. The RNC
shall use the CS or PS specific DRX cycle length, depending on which
CN domain the RANAP: PAGING message is received from.
If the RANAP: PAGING message includes an individually assigned CN
specific DRX cycle length coefficient, the RNC shall use this value to
page the idle mode UE.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 58(447)
Basic Call
 Functionality description

[Link].6 Calculation of paging occasion for UEs in idle mode

The UTRAN shall broadcast CN domain specific DRX cycle length

information in System Information Block type 1. The UE may be attached
to different CN domains with different CN domain specific DRX cycle
lengths. The UE shall store each CN domain specific DRX cycle length for
each CN domain the UE is attached to and use the shortest of those DRX
cycle lengths. Based on this DRX cycle length information, the UE shall
determine the paging occasions in which it shall receive messages on the
PCH. The DRX cycle length shall be 2k frames, where k is an integer.

The Paging Occasions shall be the frames where:

Cell SFN ={IMSI mod (DRX cycle length)} + n * DRX cycle length

Where n = 0, 1, 2… as long as Cell SFN is below its maximum value.

"IMSI (GSM-MAP)" is given as sequence of digits of type Integer (0...9),

IMSI shall in the formula above be interpreted as a decimal integer
number, where the first digit given in the sequence represents the highest
order digit.

If the UE has no IMSI, for instance when making an emergency call

without USIM, the UE uses number IMSI = 0 as default. For IMSI value
IMSI = 0, the DRX cycle length to be applied by the RNC in the formula
above shall be 256.

[Link].7 Generation of paging indication

The Page Indicator within a Paging Occasion that the UE shall read is
calculated by RNC, based on IMSI.

The Page Indicator to be used is calculated by using the following

formula:

PI = DRX Index mod Np

Where DRX Index = IMSI div 8192

"IMSI (GSM-MAP)" is given as sequence of digits of type Integer (0...9),

IMSI shall in the formula above be interpreted as a decimal integer
number, where the first digit given in the sequence represents the highest
order digit.

The number of Page Indicators per frame, Np = (18, 36, 72, 144), is
retrieved from the radio network database.

[Link].8 Paging Buffer Handling

Initial synchronization for paging buffer handling and scheduling

RRC shall create the needed paging buffers and synchronize itself to the
correct paging scheduling cycle during PCH setup/activation procedure.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 59(447)
Basic Call
 Functionality description

RRC shall maintain scheduling synchronization during the lifetime of

PCH.

Paging buffer handling

When buffering a paging message, RRC shall select the proper DRX
cycle length to be used in paging. (Either UTRAN DRX cycle length,
certain CN domain specific DRX cycle length or DRX cycle length
received explicitly in RANAP: PAGING message, see also [18].) RRC
shall calculate the 'Base paging group' of the UE according to the
following formula:

Base paging group = IMSI mod (DRX cycle length)

RRC shall calculate the DRX Index of the UE according to the following
formula:

DRX Index = IMSI div 8192

"IMSI (GSM-MAP)" is given as sequence of digits of type Integer (0...9),

IMSI shall in the formulas above be interpreted as a decimal integer
number, where the first digit given in the sequence represents the highest
order digit. The logical structure of the paging buffer is illustrated in the
figure below. (Pox denotes the Base paging group x.)

P0 P1 P2 P3 P4 P5 P509 P510 P51

1

(true SFN) Next paging group

There are 512 paging buffer places in RRC. Each paging buffer place
shall be capable of storing as many Paging Records as can be delivered
in one PCH transport block. The maximum number of Paging Records
that can be delivered in one PCH transport block depends e.g. on the
PCH transport block size and the length of the Paging Records.

RRC shall find a suitable paging buffer place for the Paging Record in the
paging buffer (i.e. the next possible paging occasion) as follows:

'Next paging group' index (range 0…511, see figure above) shall always
point to the paging group from which the next paging message may be
generated by RRC. (Note that the message must be generated couple of
frames in advance so that MAC is able to schedule the message with the
correct SFN value. The suitable advance depends on the maximum
transfer and processing delays for RNC internal messages.)

Possible paging occasions (i.e. SFN values in which Paging Indicator, PI,
can be sent) for the UE is defined as follows:

Paging occasion = (Base paging group + n * DRX cycle length) mod

512,
where n = 0, 1, 2,…, (512 div DRX cycle length) – 1

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 60(447)
Basic Call
 Functionality description

The (positive) distance from the Base paging group to the Next paging
group (in terms of 'number of paging groups') is

h = Next paging group – Base paging group + 512) mod 512

The next paging occasion occurs when 'n' gets the value k, where

k = (h + DRX cycle length – 1) div DRX cycle length

The nearest paging buffer place (i.e. the nearest paging occasion) in the
paging buffer can then be calculated as follows:

Nearest paging buffer place = (Base paging group + k * DRX cycle

length) mod 512

The Paging Record shall be stored to the nearest paging buffer place
where there is room for that Paging Record. The nearest free paging
buffer place can be calculated as follows:

Nearest free paging buffer place =

(Nearest paging buffer place + m * DRX cycle length) mod 512,

Where m = [0, 1, 2…M] should get the smallest possible integer value
with which free room for the concerned Paging Record can be found.

The following shall apply for the value of 'M':

If (DRX cycle length < Window_size div 2)

M = Window_size div DRX cycle length
else/* DRX cycle length >= Window_size div 2 */
M = min (P, (512 div DRX cycle length) – 1)

Where 'Window_size' and 'P' are configurable parameters, see [14].

The range for Window_size: 100, 200, 300, 400, 500 (frames),
default: 300
The range for P: 1, 2, 3, 4, 5, 6, 7, default: 3

If no room for the Paging Record can be found within the defined range,
the Paging Record shall be deleted by RRC.

[Link].9 Sending RRC: PAGING TYPE 1 message

When it is time for the RRC to generate a paging message from the
paging buffer place indicated by 'Next paging group' index, RRC shall
check if there are any Paging Records in the concerned paging buffer
place. If there are, RRC shall build and send RRC: PAGING TYPE 1
message to MAC (see 14) together with the correct SFN information and
DRX Indexes of all mobile identities in the RRC: PAGING TYPE 1
message. RRC shall also update 'Next paging group' index.

DRX Indexes are used by MAC to calculate correct Paging Indicator

values for the mobile identities in RRC: PAGING TYPE 1 message (see
14).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 61(447)
Basic Call
 Functionality description

[Link].10 Paging Response (Initial Direct)

There is no RRC paging response message. After an RRC connection is

established, the UE sends an appropriate upper layer message to the CN
using the RRC: INTIAL DIRECT TRANSFER message, see [Link].2 Idle
Mode Paging chapter.

When a UE is switched on, a Public Land Mobile Network (PLMN) is

selected and the UE searches for a suitable cell of this PLMN to camp on.
The UE searches for a suitable cell of the chosen PLMN and chooses that
cell to provide available services, and tunes to its control channel. This
choosing is known as "camping on the cell".

The UE will, if necessary, then register its presence, by means of a NAS

registration procedure (Attach), in the registration area of the chosen cell.
If the UE finds a more suitable cell, it reselects onto that cell and camps on
it. If the new cell is in a different registration area, location registration
(LAU/RAU) is performed.

After power on, the UE stays in Idle Mode until it transmits a request to
establish an RRC Connection. In Idle Mode the connection of the UE is
closed on all layers of the UTRAN. In Idle Mode the UE is identified by non-
access stratum (NAS) identities such as IMSI, TMSI and P-TMSI.

In addition, the UTRAN has no own information about the individual Idle
Mode mobiles, and it can only address e.g. all mobiles in a cell or all
mobiles monitoring a paging occasion.

Paging response without previous Paging message

When UE sends Initial Direct Transfer with indication that the message
was sent as a response to IMSI paging and no Paging message has
been sent by the RNC, then depending of the PRFILE parameter
setting either Flexi Iu load sharing is used to choose where the IDT is
sent or IDT is ignored. Default value is that load sharing is inactivated
(IDT is ignored). Load sharing can be configured for CS and PS
domains separately.

PRFILE 0007:269 parameter settings are as follows:

Binary value

00AB 0000 0000 000Y

Meaning of Bits

A is set: Load sharing is activated to PS domain

B is set: Load sharing is activated to CS domain

Y has value 0: Load sharing is inactivated

Load sharing can be set with following commands:

ZWOC:7,269,2001; Load sharing is activated to PS domain

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 62(447)
Basic Call
 Functionality description

ZWOC:7,269,1001; Load sharing is activated to CS domain

ZWOC:7,269,3001; Load sharing is activated to both PS and CS

domains

The RRC connection establishment procedure is described in chapter

[Link]. .

[Link].10 UTRA Connected Mode

Allocation of Radio Network Temporary Identifier (RNTI)

S-RNTI is a numeral RNC specific variable and is used in common channel

signaling to address UE. S-RNTI is allocated for all UEs having a RRC
connection, it is allocated by the Serving RNC and it is unique within the
Serving RNC. S-RNTI is reallocated always when the Serving RNC for the
RRC connection is changed. S-RNTI + SRNC-id = U-RNTI, which identifies
UE in PLMN level

The RRC entity allocates the S-RNTI for the UE e.g. at RRC connection
setup from RM/RC3. RM then allocates a new S-RNTI and returns it to
AC, which forwards it to RRC layer. C-RNTI is allocated by the common
RRC entity during a Cell Update procedure. For further information on
Connected Mode can be referred to [18].

Release of Radio Network Temporary Identifier (RNTI)

The S-RNTI is released when the RRC connection is released. S-RNTI is

also released in source RNC after SRNC relocation or inter-RAT handover.

Maintaining of the location information for each UE on cell level

More information of how location of UE information is handled in different

cell level can be referred to [20] document.

[Link] RRC Connection Procedures

Radio Resource Control (RRC) connection allows a dialog between the UE

and RNC and further dialog between CN and UE (e.g. support of SMS). It
can be used to establish, reconfigure, and release several parallel radio
access bearers that are non-synchronized with each other. Two CNs
connected to the same RNC can use the same RRC connection.

The NAS messages on the radio path are conveyed to/from the UE using
an air interface RRC layer procedures. The RNC does not analyze the
contents of the NAS messages.

In case the RNC is connected to two core networks, paging requests are
forwarded by RNC to the UE via the possibly existing signalling link. This
can happen when a connection to CN1 exists when CN2 (not knowing of
CN1) starts a connection setup (by paging) to the UE.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 63(447)
Basic Call
 Functionality description

The UE uses air interface RRC layer procedures to inform the RNC about
a change in UE capability (classmark).

The initiation of the RRC Connection Establishment procedure can be

triggered by a paging request from the core network or by a request from
the upper layer of the UE. The UE always originates the RRC Connection
Establishment procedure. Before establishing an RRC connection, the UE
is in idle mode. After the RRC connection has been established, the UE is
in connected mode. The network initiates the establishment of the RRC
connection by the paging procedure. A single paging message across the
Iu interface contains information of the area in which the page shall be
broadcast.

The RRC connection setup procedure is completed in the RNC when the
air interface lower layers (L1 and L2) and appropriate Iub connection are
established. After the RRC connection exists, Iu connection is established
by request of UE.

[Link].1 RRC Connection Request

The RNC receives an RRC connection establishment request RRC: RRC

CONNECTION REQUEST on the PRACH/RACH/CCCH. The RNC shall
then perform admission control functionality [8] and initiate the radio link
setup procedure for dedicated channels (Cell_DCH) or either stay on
common channels (Cell_FACH) without initiating yet RL setup. See
chapter 2.3.18 for common channel setup.

In case of Establishment cause value in RRC: RRC CONNECTION

REQUEST message is “Emergency Call”, RRC L3 sends this information
to L2 MAC-c SW for the top priority scheduling of the RRC: RRC
CONNECTION SETUP message.

Detection of BTS generated (not UE generated) duplicates in RRC

If more than one RRC: RRC CONNECTION REQUEST messages are

received from same subscriber within 100 ms the duplicate messages are
ignored by the RRC/RRB. This short duplicate message detection is used
for filtering the RACH duplicates generated in the BTS.

Buffering/discarding of the repeated RRC connection requests received

from the same UE

When the first RRC: RRC CONNECTION REQUEST message is received

from the UE, the RRC entity (RRB) shall store the initial UE identity
information received from the UE, set the maximum buffering time as
N300*T300 and start double reservation buffering for this UE. The first
request message shall be forwarded to the AC/RM as normally.

Further RRC: RRC CONNECTION REQUEST messages received from

this UE are discarded during the buffering and no resource reservation is
initiated. Note however, that the RRC entity shall trigger an immediate
retransmission of the RRC: RRC CONNECTION SETUP message as
described in chapter [Link].2.

The double reservation buffering is continued until:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 64(447)
Basic Call
 Functionality description

• The RRC: RRC CONNECTION SETUP COMPLETE message is

received from the UE.

• The RRC: RRC CONNECTION REJECT message is sent to the UE

without any resources reserved in this cell.

• The Layer3 time supervision T_RRC_Resp_CCH for a receipt of the

RRC: RRC CONNECTION SETUP COMPLETE message from the
UE has expired and the resources reserved in this cell are released.

• The RM indicates the occurrence of cell reselection during the RRC

connection setup procedure and the resources reserved from the
previous cell must be released.

• Or the maximum buffering time defined as N300*T300 is reached.

After this the RRC entity (RRB) shall immediately remove the initial UE
identity of this UE stored in the double reservation buffer.

Discarding of the repeated RRC connection requests received from the

same UE but from the different cell (Phantom call restriction)

In order to handle these situations, the RRC entity (MCC) shall send the
Cell id together with UE identity to the resource manager (RC3) when S-
RNTI for the RRC connection is allocated.

When RNC receives RRC: RRC CONNECTION REQUEST message

from different cell, before RRC: RRC CONNECTION SETUP COMPLETE
is received in previous cell, RNC creates RRC entity (MCC) normally and
sends Cell id together with UE identity to the RC3 and asks RC3 to
allocate S-RNTI for the connection. RC3 notes that same UE has already
RRC connection setup ongoing for a different cell. This causes that RC3
indicates to RRC entity (MCC) of the occurrence of cell reselection during
RRC Connection Setup procedure. RRC entity (MCC) shall release the
resources reserved for the RRC Connection Setup in the previous cell.

Normal proceeding with the (first) RRC: RRC CONNECTION REQUEST

Coming RRC: RRC CONNECTION REQUEST message (RACH)

contains Information from UE about; e.g. call Establishment Cause,
Measured Results On RACH (CPICH Ec/N0) and the access stratum
release Indicator of UE.

RRC connection establishment is normally performed directly to the

Cell_DCH state. RRC connection establishment, HHO and state
transitions are always done with one “target” RL.

The MCC for the UE shall be created immediately after RRC: RRC
CONNECTION REQUEST message is received from the UE and
RRC/RRB has selected the ICSU unit (own unit preferred, otherwise "less
loaded unit"). In case of Establishment cause value in RRC: RRC
CONNECTION REQUEST message is “Emergency Call”, RRC L3 should
send this information to L2 MAC-c SW for the top priority scheduling of
the RRC: RRC CONNECTION SETUP message.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 65(447)
Basic Call
 Functionality description

The RRC entity got also internal measurements results (MAC-c/sh and
BTS) and it delivers all these information to UER/Handover Control and
includes BTS and cell identifiers with in.

MCC is checking of external (EcNo) and internal measurement results

against thresholds defined by RNP parameters;
CPICHEcNoSRBMapRRC 2.7.6, RRCSetupCCHEnabledR99 2.7.5 and
SRBMapRRCSetupEC 2.7.4 (SRBMapRRCSetupEC parameter defines
the Establishment Cause (EC) values which prefer SRB mapping to the
dedicated channels (DCH) in the RRC connection setup procedure).

The RRC/MCC/CCM forwards dedicated channel requirement to

UER/Handover control and cell specific admission control (BRM).

Note: Usage of the Common Channels is handled in chapter 2.3.18.

After that the Handover Control is started and resource manager (RC3)
has given new S-RNTI value for the dedicated channel connection.

The RRM gives resources for dedicated channel (Cell_DCH) based on

information got from UE and RRC and initiates radio link setup procedure.

Version Information in RRC connection request

RRC: RRC CONNECTION REQUEST message contains “the access

stratum release Indicator of UE”. IE tells information on which release
R99, Rel4, Rel5, Rel6 and Rel7 UE is currently using. RNC shall use
messages of the indicated release version (R99/Rel4/ Rel5/Rel6/Rel7)
and use also release information to evaluate UEs capability to serve
some features.

Feature Support information in RRC Connection Request

RRC: RRC CONNECTION REQUEST message contains some IEs

related to support of particular feature like F-DPCH. RRC: RRC
CONNECTION SETUP COMPLETE message has the complete feature
support information.

[Link].2 RRC Connection Setup

After the dedicated control channel has been set up in the radio access
network on the Iub interface, the RNC generate an RRC: RRC
CONNECTION SETUP message is sent to the UE over the FACH. The
message is sent via the logical channel CCCH using UM RLC and start
timers T_RRC_Resp_CCH, RRCconnRepTimer1 and
RRCconnRepTimer2 in order to configure the UE side resources needed
for the establishment of Radio Link and DCH. If Service Area Broadcast is
used in a cell [12], the CCCH is in this case mapped to FACH-c-idle
transport channel according to SIB5 SCCPCH configuration for idle mode.
RRC shall send the information about the used transport channel to MAC.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 66(447)
Basic Call
 Functionality description

Figure 12 illustrates the RRC Connection Establishment procedure. The

UE always initiates RRC connection establishment.

UE BTS RNC

RRC: RRC CONNECTION REQUEST

Radio Link setup

RRC: RRC CONNECTION SETUP

L1 synchronization

RRC: RRC CONNECTION SETUP COMPLETE

Figure 12 RRC connection establishments

The RNC sets up a radio link and acknowledges the connection setup to
the UE. After the UE has synchronized to the BTS, the UE transmits an
acknowledgement to the RNC. Once the UE has established the RRC
connection, it may then send a higher layer message (e.g. a call setup
message).

The UE is identified by using the previously received UE Identity. U-RNTI

allocated by the RM/RC3 is sent to the UE in this message and it will be
used from now on to identify the UE in the common channels.

The RRC: CONNECTION SETUP message is delivered transparently

over the Iub interface.

This message contains Initial UE identifier (e.g. TMSI + LAI), RNTI (Radio
Network Temporary Identity), Frequency, Transport Format Set,
Transport Format Combination Set, Uplink Scrambling code, Downlink
Channelization code, Power Control Information.

The UE is normally transferred directly to Cell_DCH state (see also

common channel setup on chapter [Link]). During RRC connection
setup procedure, dedicated channel resources are allocated to the UE
and the UE is transferred to the Cell_DCH. After that the UE performs a
NAS connection establishment to the PS-CN or CS-CN.

If the Access Stratum Release Indicator IE in the RRC Connection

Request message indicates: for UEs of Rel5 or higher the RNC entity
(MCC) shall use Default Configuration in RRC Connection Setup on DCH.

When Signalling link chosen is slow (3.4 kbps)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 67(447)
Basic Call
 Functionality description

• with R99 UE complete or explicit configuration is used

• with Rel5 or newer UE DefConfg#0 is used
When signaling link chosen is fast (13.6 kbps)
• with R99 UE complete configuration is used
• with Rel 5 UE DefConfg#1 is used
• with Rel 6 or newer UE DefConfg#22 is used

Note: There is no SRB4 (low prioritysignalling) links used, but instead is

used SRB3. And for RRC Connection Setup on DCH, using Default
Configurations, the currently defined DefConfgs provide only mappings for
SRB1..3.

Editor’s Note: When SRB4 is not established, the RRC Connection

Setup procedure is shorter and therefore signalling load is decreased. In
addition some of DMPG/L2 memory is saved. Also SRB4/SMS problems
after ISHO with certain UEs can be avoided, when SRB4 is not
established.

Note: Default configurations are not used without Fast HSPA Mobility
(RAN2746/2738) in live networks. It does not work with all the UEs.

The bitrate of the Signaling Link is decided by Establishment Cause of the

RRC Connection Request message and the RNP parameter
SRBBitRateRRCSetupEC.
<CRE1298/begin>
By default 13.6 kbps SRB DCH is used always if LTE band capabilities
need to be requested from a UE. In those cases
SRBBitRateRRCSetupEC parameter is ignored. LTE band capabilities are
needed if LTE layering features are in use (see chapter [Link]).
<CRE1298/end>

Exception handling:
i) If the UE rejects the RRC Connection Setup that was using default
configuration, then at the following RRC Connection Request the MCC
shall answer with RRC Connection Setup mapping SRBs on DCH using
explicit configuration.
ii) If the previous attempt was done on DCH13.6kbps, then the following
one shall be done with 3.4kbps, keeping the rest of configuration
unchanged, as 13.6kbps DCH can face congestion, but the 3.4kbps one
cannot.
iii) If the UE has caused a pre-emption/RT over NRT (it is done also for
SRBs), then for this UE and in this setup only 3.4kbps shall be tried, as
pre-emption/RT over NRT can be done for SRBs also and it is better to
decrease the SRB bandwidth before releasing/decreasing other
connections.
iv) If the retries as described up to ii) above are rejected as well, the
legacy error handling shall be applied

<RAN2746/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 68(447)
Basic Call
 Functionality description

This feature introduces RRC CONNECTION SETUP message size

optimization, which is achieved by sending Complete Configuration with
single Cell_DCH mapping.
NSN RAN uses currently dual mapping for the Radio Bearers and it
signals both Cell_DCH and Cell_FACH RB Mapping Option to the UE.
Since it is mandatory to provide at least one RB Mapping information for
each RB, signalling the dual mapping of the RB can be delayed until the
RRC Connection Setup procedure has been completed. Because
unnecessary information elements are removed, RRC Connection
Setup message size is reduced from 2 to 1 TB (Transport Block) resulting
faster and more reliable signalling.

Other option for optimising RRC Connection Setup message is to use

Default Configuration. Default configuration uses always single mapping.

If either of above option is activated, RACH/FACH RB mapping

information for SRBs is provided after RRC connection setup procedure
during the first Radio Bearer Setup procedure, but with a separate Radio
Bearer Reconfiguration procedure.

During RRC Connection Setup, either Default or Complete configuration

can be used for a UE

The functionality is controlled by the bits 0-2 of the PRFILE parameter

002:1712 RN50 MAINT 34:
• BIT 0 -> use Default Configuration for rel6 and newer UEs
• BIT 1 -> Use complete configuration for rel5 and older UEs with
single mapping
• BIT 2 -> Use complete configuration for rel6 and newer UEs with
single mapping

Default value:
Default value of this parameter is 0H, i.e. RRC CONNECTION SETUP
message size optimization is not activated and complete configuration
with dual mapping is used for all UEs.

Activation:
-To use Default Configuration for rel6 and newer UEs (and Complete
Configuration with dual mapping for rel5 and older), BIT 0 of PRFILE
parameter need to be changed to 1: (0000 0000 0000 0001). Excludes
BIT 2.

-To use Complete Configuration for rel5 and older UEs with single
mapping (and complete configuration with dual mapping for rel6 and
newer), BIT 1 of PRFILE parameter need to be changed to 1: (0000 0000
0000 0010).

-To use Complete Configuration for rel6 and newer UEs with single
mapping (and complete configuration with dual mapping for rel5 and
older), BIT 2 of PRFILE parameter need to be changed to 1: (0000 0000
0000 0100).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 69(447)
Basic Call
 Functionality description

-To use Default Configuration for rel6 and newer UEs and complete
configuration with single mapping for rel5 and older UEs, BIT 0 and BIT1
of PRFILE parameter need to be changed to 1: (0000 0000 0000 0011).

-To use Complete Configuration for all UEs with single mapping, BIT 1
and BIT 2 of PRFILE parameter need to be changed to 1: (0000 0000
0000 0110).
-After parameter value has been changed, change is activated within 10
minutes.

Deactivation:
-To deactivate this change i.e to use Complete Configuration with dual
mapping for all UEs, BIT 0, BIT1 and BIT 2 need to be changed to values
0 (0000 0000 0000 0000).
-After parameter value has been changed, change is deactivated within
10 minutes.

<RAN2738/begin>

RNC level on-line modifiable parameter RRCConnSetupMsgSize

replaces the RAN2746 PRFILE parameter 002:1712 RN50_MAINT_34
(bits 0-2) as an activation parameter.

UE Specific RRC optimises the RRC CONNECTION SETUP message

size, if:

• the license for Fast HSPA Mobility II is 'On',

• the Fast HSPA Mobility II feature is activated in the cell and

• the parameter RRCConnSetupMsgSize is set as any other valid

value than 'disabled'.

<RAN2738/end>

<RAN2746/end>

UE informs nature of the call to RAN in RRC connection or signaling

connection establishment phase

RRC Establishment Cause IE, which is received from UE, has the following
values of RRC Connection Request message parameters:

Originating Conversational Call

Originating Streaming Call
Originating Interactive Call
Originating Background Call
Originating Subscribed traffic Call
Terminating Conversational Call
Terminating Streaming Call
Terminating Interactive Call
Terminating Background Call
Emergency Call

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 70(447)
Basic Call
 Functionality description

Inter-RAT cell re-selection

Inter-RAT cell change order
Registration
Detach
Originating High Priority Signalling
Originating Low Priority Signalling
Call re-establishment
Terminating High Priority Signalling
Terminating Low Priority Signalling
Terminating-cause unknown

RRC connection or signaling connection establishment initiated with one

of the bolded cause values as an establishment cause shall be able to
trigger the RT over NRT procedure.

Especially, a call is handled as an emergency call in the RRC connection

or signaling connection establishment phase, if the RRC Establishment
Cause IE indicates “emergency call”. Establishment Cause IE is received
from UE in the RRC: RRC Connection Request -message.

Directed RRC connection setup

Directed RRC connection set-up provides an efficient way to balance load
between two (or more) carrier frequencies (cells having equal coverage
areas) within one base station. If either the measured total uplink
interference power (uplink load) or the measured total transmission power
(downlink load) in current cell exceeds a predefined threshold, the RNC
compare the uplink/downlink load of the current cell with uplink/downlink
of the other cell which belong to the same sector in order to find the
carrier frequency with have less load.

The Admission Control of RNC makes a decision on whether to perform

the Directed RRC connection setup procedure on the basis of uplink and
downlink load.

If none of the cells which belong to the same sector as the current cell
satisfy the requirements, the RNC does the admission decision in the
current cell. The RRC connection can be established in the current cell if
the admission decision is successful. If the cell is not in an overload
condition, the request to establish the RRC connection is accepted

RM/RC3 allocates the UTRAN Radio Temporary Identifier (U-RNTI) for

the UE. Also, layer 1 and layer 2 related resources (RLC, MAC, Radio
Link and DCH parameters) are determined for the RRC connection.

<RAN3475/begin>

Directed RRC connection setup to the cell which has the RAN3475
Buffer-free WCDMA-LTE Refarming feature enabled can be restricted
depending on the value of the RNMOBI parameter
BFRFunctionalityControl:

• When Bit0 and Bit1 of the parameter BFRFunctionalityControl are

set to value 0, the RAN3475 Buffer-free WCDMA-LTE Refarming
feature does not restrict Directed RRC connection setup.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 71(447)
Basic Call
 Functionality description

• When Bit0 of the BFRFunctionalityControl is set to value 1 (default

value), the handover control shall prevent the Directed RRC
connection setup.

• If Bit1 of the parameter BFRFunctionalityControl is set to value 1

when Bit0 is set to value 0, whether Directed RRC connection
setup is is allowed or not depends on the value CPICH RSCP
measurement result of the source cell. See Handover Control FD
for details.

<RAN3475/end>

Redirection of RRC connection setup

When current cell where UE was camped in the idle mode and where UE
starts RRC connection establishment is either interference or resource
congested state, RRC connection setup redirection feature is used to
direct the RRC connection to the other WCDMA frequency or even to the
GSM/GPRS system. This is done to prevent call congestion due to
heavily loaded original cell by giving another possibility for the UE.

It is recommended to forbid the inter-frequency RRC connection setup

redirection from the cell when the IMSI based inter-frequency handover is
enabled in the cell. The restriction is needed because the RNC has not
received the IMSI of the subscriber from the CN at the time of RRC
connection setup procedure.

RRC connection setup retransmission procedure in RNC

When timer RRCconnRepTimer1 elapses the RRC: RRC CONNECTION

SETUP message is retransmitted to the UE.

When timer RRCconnRepTimer2 elapses and RRC: RRC CONNECTION

SETUP COMPLETE message is not received from UE, the RRC: RRC
CONNECTION SETUP message is retransmitted to the UE.

The RNC retransmits the RRC: RRC CONNECTION SETUP message

immediately, starts timer RRCconnRepTimer2 (or starts again if running)
and stops RRCconnRepTimer1 (if running), if RRC signaling entity
receives the repeated RRC: CONNECTION REQUEST from UE.

When RRC: RRC CONNECTION SETUP COMPLETE message is

received from UE, the retransmission procedure is terminated and timers
RRCconnRepTimer1 and RRCconnRepTimer2 are stopped.

There are different kinds of statistical measurements and counters to be

used in fine-tuning of the RRC connection setup retransmission
procedure, see [13]. Each cell can be fine-tuned separately, while other
cells are using the default parameterization or not using the
retransmission procedure at all. RRC connection setup retransmission
procedure can be switched off if not proved to be necessary. Setting the
timer values to 0 does this.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 72(447)
Basic Call
 Functionality description

When T300 has value lower than 1000ms, the RRCconnRepTimer1 shall
not be used in the RRC connection setup retransmission procedure
(despite of an initial value of the RRCconnRepTimer1).

<CRE1298/begin>

When UE specific RRC receives the message from UP indicating UL data

on SRB2 or SRB3 (rnc_mac_ul_activity_ind_s) after sending the
RRC:RRC CONNECTION SETUP message to the UE and the relevant
CRE1298 functionality has not been deactivated with PRFILE parameter
002:2136 RU40_MAINT_40 (9th bit), the retransmission procedure is
terminated and timers RRCconnRepTimer1 and RRCconnRepTimer2 are
stopped.

<CRE1298/end>

Frequency layer change during RRC connection establishment

In RRC connection establishment procedure the UE is currently transferred

directly to Cell_DCH state. When RRC connection is requested by UE,
RRC entity/MCC/CCM forwards the request along with the UE capability
information to UER. If RRM decides to allocate the resources from the other
layer than the current one, it forwards the frequency info along with
allocated resources to RRC/CCM. RRC/CCM allocates the dedicated
resources for the signaling link as normally and orders UE to the new
frequency layer by sending the RRC Connection Setup message. RRC
Connection Setup message includes the new frequency info and is sent to
UE via Common RRC entity/RRB. RRC saves the new frequency layer
setup attempt info in order to handle the possible unsuccessful case and
stops the double reservation buffering but not the RRC connection Setup
message retransmission.

RRC/RRB uses the retransmission of the RRC Connection Setup message

as normally, except that an immediate retransmission of a Setup message
when receiving the new Request message shall not be used when the
frequency layer change is executed during the procedure.

RRC Connection Setup message retransmission function uses the timers

RRCConnRepTimer1 and RRCConnRepTimer2 for repetition intervals
(see 13). When RRC/RRB has detected the frequency layer change
attempt, it shall check the following conditional statements to avoid the
collision between new RRC Connection Request message and repeated
RRC Connection Setup message. The RRC shall prevent the repeated
RRC Connection Setup message to be as response to the new RRC
Connection Request message.

RRCConnRepTimer1 and RRCConnRepTimer2 shall be less than T300 –

200 ms.

If RRCConnRepTimer1 is greater than or equal to T300- 200 ms no

retransmission of the RRC Connection Setup message shall be done and
no retransmission timers shall be started. If RRCConnRepTimer1 is less
than T300 -200ms and RRCConnRepTimer2 is greater than or equal to
T300 -200ms only RRCConnRepTimer1 is started. If both timers are less
than T300 – 200 ms, both are started.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 73(447)
Basic Call
 Functionality description

Successful procedure

If UE is able to adapt the new frequency, it sends the RRC Connection

Setup Complete message. MCC shall forward the information of
successful frequency layer change to the RRC/RRB which needs it for
the frequency layer setup attempt information clearance.

Unsuccessful procedure

If UE is not able to adapt the new frequency, instead of sending the

RRC Connection Setup Complete it likely pretty soon sends a new
RRC Connection Request. When/if the UE sends the new RRC
Connection Request message via the same cell, RRC/RRB is now able
to detect it as unsuccessful frequency layer change attempt. RRC/RRB
sends the new request to the new MCC with this failure information.
MCC/CCM shall forward the frequency change attempt failure
information to RRM/UER when requesting the resources. With this
failure information BRM shall avoid allocating the resources from
another frequency layer than the current one. When the new S-RNTI
allocation for the new connection is requested from RC3, it detects that
there is already another MCC for the same connection. RC3 allocates
the S-RNTI for the new connection and sends the connection release
indication to the old MCC.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 74(447)
Basic Call
 Functionality description

MS RRC-c RRC/MCC RC3 RRC/MCC2 BRM

RRC:RRC CONNECTION REQUEST (1st)

Double reservation buffering started

rrc_connection_request_s
rc3_rnti_request_s

S-RNTI allocation

rc3_rnti_request_ack_s

rrc_conn_req_s (UE capability)

Resource allocation
decision from another
frequency layer

rrc_conn_req_ack_s (frequency info)

RL & AAL2 setup

L2 configuration

rrc_connection_setup_s (frequency info)

Double reservation buffering stopped T_RRC_Resp_DCH

Frequency change attempt info saved

RRC:RRC CONNECTION SETUP

RRCConnRepTimer1 started

RRCConnRepTimer2 started

RRCConnRepTimer1 expires

RRC:RRC CONNECTION SETUP

RRCConnRepTimer2 expires (no

indication from MCC received)

RRC:RRC CONNECTION SETUP

nd
RRC:RRC CONNECTION REQUEST (2 )

RRCConnRepTimer2 stopped

Double reservation buffering started

rrc_connection_request_s (freq. change attempt failed)

rc3_rnti_request_s

S-RNTI allocation

rc3_l3_release_s rc3_rnti_request_ack_s

UL_DL_resource_req (UE capability. Failed info)

RRC Conn. Establishment to other
frequency layer interrupted;
resources released Resource allocation
from the frequency
layer that the UE is

resource_req_ack

RL & AAL2 setup

L2 configuration

rrc_connection_setup_s
RRC:RRC CONNECTION SETUP

RRCConnRepTimer1 started

RRCConnRepTimer2 started

RRC:RRC CONNECTION SETUP COMPLETE

rrc_stop_double_res_buff_s (rrc_conn_setup_cmpl_rec)

Double reservation buffering stopped

and frequency attempt info cleared

Figure 13: Frequency layer change with RRC Connection Setup

procedure (Unsuccessful case handling)

[Link].3 RRC Connection Setup Complete

When the RNC receives RRC: RRC CONNECTION SETUP COMPLETE

message, the RNC shall register the UE to RRC connected mode and the
establishment procedure is completed.

The RNC shall use the hyper frame number to initialize the integrity
protection and ciphering algorithms. More information related to integrity
protection and ciphering algorithms can be found [L3 Security FD]

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 75(447)
Basic Call
 Functionality description

The RNC shall store the UE radio access capability information in the
database. The capabilities are stored in the MCC for the duration of the
RRC connection.

RNC shall store the Inter-RAT UE radio access capability information

about GSM system in the database (if received). The capabilities are
stored in the MCC for the duration of the RRC connection. If the capability
information (UE Classmark 2 & 3) is not received, the RNC shall request
the information by using the UE Capability Enquiry procedure.

RNC shall store the MCC+MNC+ LAC/RAC information of the cell where
the RRC connection was set up. LAC is saved for CS connection and
LAC+RAC for the PS connection. The information is stored in the MCC
for the duration of the RRC connection.

[Link].4 RRC Connection Release

The purpose of RRC connection release procedure is to release the RRC

connection including all radio bearers and all signaling radio bearers
between the UE and UTRAN. By doing so, all established signaling
connection will be released.

An RRC connection is released after the UE no longer has a signaling

connection to any CN network. Signalling connection release negotiation
will take place directly between the UE and CN using transparent
messages via UTRAN. The CN will then send RANAP: IU RELEASE
COMMAND indicating that Iu connection and all UTRAN resources
related only to the concerned Iu connection should be released. After the
RANAP: IU RELEASE COMMAND has been sent, the CN shall not send
further RANAP connection oriented messages on this particular
connection, except possible repetition of RANAP:IU RELEASE
COMMAND message.

When the RNC receives the RANAP: IU RELEASE COMMAND message,

RNC starts RRC connection release procedure by sending RRC: RRC
CONNECTION RELEASE message to the UE if the UE no longer has a
signaling connection to any CN node.
< E1161/begin>

When the Out of UTRAN IE is received in RANAP: IU RELEASE

COMMAND message and the IE has the value “cell reselection to
EUTRAN“, it indicates that UE has made a cell reselection to LTE.
Therefore no explicit UE paging/RRC connection release is needed and
UE Specific RRC releases only locally the UE dedicated resources. The
local release is counted as successful release.

<E1161/end>

Then the RNC sends a RANAP: IU RELEASE COMPLETE message to

the CN. The RNC does not need to wait for the release of UTRAN radio
resources to be completed before returning the RANAP: IU RELEASE
COMPLETE message.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 76(447)
Basic Call
 Functionality description

When the UE receives RRC: RRC CONNECTION RELEASE message in

state CELL_DCH, it shall transmit RRC: RRC CONNECTION RELEASE
COMPLETE message using unacknowledged mode RLC on the DCCH to
the UTRAN. The UE shall re-transmit the message N308 times with
intervals of T308 before it releases its radio resources and enters idle
mode.

When the UE receives the RRC: RRC CONNECTION RELEASE

message in state CELL_FACH, it shall:

- if the RRC: RRC CONNECTION RELEASE message was received on

the DCCH, transmit an RRC:RRC CONNECTION RELEASE
COMPLETE message using acknowledged mode RLC on the DCCH
to the UTRAN, release all its radio resources and enter idle mode.

If the RRC: RRC CONNECTION RELEASE message was received

on the CCCH and IE “U-RNTI” is present and has the same value as
the variable U_RNTI, release all its radio resources and enter idle
mode.

UE BTS RNC CN

UE has signalling connetion to one CN

RANAP: IU RELEASE COMMAND

RRC: RRC CONNECTION RELEASE

RANAP: IU RELEASE COMPLETE

RRC: RRC CONNECTION RELEASE COMPLETE

Radio Link deletion procedure

Figure 14: RRC connection release in CELL_DCH state

UE BTS RNC CN

UE has a signalling connection to one CN

RANAP: IU RELEASE COMMAND

RRC: RRC CONNECTION RELEASE

RANAP: IU RELEASE COMPLETE

RRC: RRC CONNECTION RELEASE COMPLETE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 77(447)
Basic Call
 Functionality description

Figure 15: RRC Connection release in CELL_FACH state on the DCCH

UE BTS RNC CN

UE has signalling connection to one CN

RANAP: IU RELEASE COMMAND

RRC: RRC CONNECTION RELEASE

RANAP: IU RELEASE COMPLETE

RRC: RRC CONNECTION RELEASE COMPLETE

Figure 16: RRC Connection release on CCCH

RRC Connection Release on the DCCH mapped to DCH

When the RNC receives the RANAP: IU RELEASE COMMAND message

from the core network, the RNC shall initiate RRC connection release
procedure if the UE has no longer a signaling connection to any CN node.

If the UE is in CELL_DCH state, the RNC requests the UE to release the

RRC connection by sending RRC: RRC CONNECTION RELEASE
message using unacknowledged mode on the DCCH mapped to DCH
and starts a message repetition timer (with duration of 100 ms) and a
response supervision timer T_RRC_Resp_DCH. (See also 15).

RRC Connection Release on the DCCH mapped to FACH

When the RNC receives the RANAP: IU RELEASE COMMAND message

from the core network, the RNC shall initiate RRC connection release
procedure if the UE has no longer a signaling connection to any CN node.

If the UE is in CELL_FACH state, the RNC requests the UE to release the

RRC connection by sending RRC: CONNECTION RELEASE message
using unacknowledged mode on the DCCH mapped to FACH and starts a
message repetition timer (with duration of 100 ms) and a response
supervision timer T_RRC_Resp_CCH. (See also 18.)

The UE acknowledges the release to the RNC with an RRC: RRC

CONNECTION RELEASE COMPLETE message using acknowledged
mode on the DCCH mapped to RACH, releases all its radio resources
and enters idle mode.

The RRC entity of the UE in the RNC can be deleted when the RNC
receives the RRC: RRC CONNECTION RELEASE COMPLETE message
from the UE.

Then the RNC sends a RANAP: IU RELEASE COMPLETE message to

the CN. The RNC does not need to wait for the release of UTRAN radio
resources to be completed before returning the RANAP: IU RELEASE
COMPLETE message.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 78(447)
Basic Call
 Functionality description

The release of an RRC connection releases all remaining bearers, if they

have not been released before.

RRC Connection Release of UE is state CELL_PCH or URA_PCH

If the UE is in state CELL_PCH or URA_PCH, the RNC must first page it

to state CELL_FACH before releasing the RRC connection.

RRC Connection Release on the CCCH (RNC)

When the RNC transmits an RRC: RRC CONNECTION RELEASE

message, the downlink DCCH should be used, if available. If the downlink
DCCH is not available in UTRAN and the UE is in CELL_FACH state, the
downlink CCCH may be used [9]. RRC shall send the information about
the used transport channel to MAC.

The RNC requests the UE to release the RRC connection by sending

RRC: RRC CONNECTION RELEASE message using unacknowledged
mode on the CCCH and starts a message repetition timer (with duration
of 100 ms). The RNC shall retransmit the message
L3Rep_RRC_Conn_Rel times with interval of 100 ms to increase the
probability of proper reception of the message by the UE. The sequence
number for these repeated messages shall be the same. The RNC then
deletes the RRC entity of the UE.

Handling of no response from UE to RRC connection release

Case 1: DCCH mapped to DCH

The primary method to detect the release of the RRC connection on

DCCH mapped to DCH in the network is the RRC: RRC CONNECTION
RELEASE COMPLETE message from the UE.

If the RNC receives no response from the UE to an RRC: RRC

CONNECTION RELEASE message sent on the DCCH mapped to DCH
within the message repetition timer (with duration of 100 ms), the RNC
shall retransmit the message L3Rep_RRC_Conn_Rel times with interval
of 100 ms to increase the probability of proper reception of the message
by the UE. The sequence number for these repeated messages shall be
the same.

If the RRC: RRC CONNECTION RELEASE COMPLETE message is not

received, the release of the signaling link may also be implicitly detected
by the out-of-sync indication (NBAP: RADIO LINK FAILURE INDICATION
message) from the BTS to RNC. If receiving this indication, the RNC
releases L2 and L1 resources on the network side and deletes the UE
specific RRC entity.

If all RRC: RRC CONNECTION RELEASE messages sent by the RNC

are lost by UE, no out-of-sync indication (NBAP: RADIO LINK FAILURE
INDICATION message) is received from the BTS. If “no kind of response”
to RRC: RRC CONNECTION RELEASE messages are received and
T_RRC_Resp_DCH expires, the RNC shall then delete the UE specific
RRC entity.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 79(447)
Basic Call
 Functionality description

Case 1: DCCH mapped to FACH

The primary method to detect the release of the RRC connection on

DCCH mapped to FACH in the network is the RRC: RRC CONNECTION
RELEASE COMPLETE message from the UE.

If the RNC receives no response from the UE to an RRC: RRC

CONNECTION RELEASE message sent on the DCCH mapped to FACH
within the message repetition timer (with duration of 100 ms), the RNC
shall retransmit the message L3Rep_RRC_Conn_Rel times with interval
of 100 ms to increase the probability of proper reception of the message
by the UE. The sequence number for these repeated messages shall be
the same. If T_RRC_Resp_CCH expires and still no response is received,
the RNC shall then delete the UE specific RRC entity (See also 18).

[Link].5 RRC Connection Reject

If admission control rejects an RRC connection request, the RNC shall

generate RRC: RRC CONNECTION REJECT message and transmit it on
the FACH to the UE.

UE BTS RNC

RRC: RRC CONNECTION REQUEST

RRC: RRC CONNECTION REJECT

RR: RRC CONNECTION REQUEST

Figure 17: Rejected RRC connection request and retry

The RNC may e.g. fail in its attempt to set up a radio link due to HW
blocking in BTS or in RNC. The RNC then transmits an RRC: RRC
CONNECTION REJECT message. The UE shall reattempt to establish
the RRC connection according to the ‘Wait time’ information received in
the RRC: RRC CONNECTION REJECT message The UE shall wait for
'wait time' and then retransmit RRC: RRC CONNECTION REQUEST
message.

If RRC: RRC CONNECTION REQUEST is received with cause value

“MBMS reception”, RNC shall send the RRC: RRC CONNECTION
REJECT message with cause value “unspecified”.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 80(447)
Basic Call
 Functionality description

<ADA3.0/begin> RRC connection reject can be sent with Redirection Info

in case of CS enabling handover. Please refer to section Error!
Reference source not found. for further details. <ADA3.0/end>

<RAN147/begin>

When RAN147 RRC Connection Setup Redirection feature is enabled,

RRC connection can be redirected to another 3G frequency or GSM in
case the admission control rejects the RRC connection request or
overload happens on RNC signaling unit. Please refer to chapter “RRC
Connection Setup Redirection” for further details.

<RAN147/end>

[Link].6 RRC Connection Failure due to missing RRC connection setup

complete

After having sent RRC: CONNECTION SETUP message:

- If NBAP: RADIO LINK RESTORE INDICATION message is received

from the BTS but the RNC does not receive RRC: RRC
CONNECTION SETUP COMPLETE message from the UE before the
timer T_RRC_Resp_CCH elapses, the RNC shall start RRC
connection release procedure on the DCH.

<FLTYRRCConnPro/begin>

[Link].7 Faulty protocol error handling during RRC Connection setup procedure

These problems are caused by faulty UEs.

RRC Connection setup on Common Channel

See chapter “RRC Connection Procedures on CCH”.

Problem: UE does not hear the new setup because it is using the
previous configuration in Cell_FACH state.

In RRC connection setup phase, UE transmits the RRC Connection

Request to RNC and begins to decode FACH. RNC tries to setup RRC
Connection to Cell_FACH state by sending RRC CONNECTION SETUP
message to UE with state indicator Cell_FACH. When the RNC waits
RRC CONNECTION SETUP COMPLETE message (before UE has been
decoded/received RRC CONNECTION SETUP message from RNC) from
UE, UE decodes something rubbish from FACH and transmits new RRC
CONNECTION REQUEST message towards RNC with cause protocol
error. Based on that RNC setup radio link to BTS and tries to setup RRC
connection to Cell_DCH state by sending new RRC CONNECTION
SETUP message to UE with state indicator Cell_DCH. However later on
after UE has been decoded something rubbish from FACH, UE receives

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 81(447)
Basic Call
 Functionality description

first RRC CONNECTION SETUP message with state indicator

Cell_FACH and stays on Cell_FACH state and even tries to signal RRC
CONNECTION SETUP COMPLETE message over RACH but is never
handled by RNC because there is no entities to receive it. Later on RNC
release the radio link because of no synchronization.

RRC CONNECTION REQUEST message sent with cause protocol error

before UE has been received RRC CONNECTION SETUP message is
due faulty UE.

This does not cause power spiking problems but effects to KPIs of RRC
Connection Setup.

RRC Connection setup to Cell_DCH state

Problem: UE keeps using radio link which network thinks is released from
this UE.

In RRC connection setup phase, faulty UE transmits the RRC Connection

Request to RNC and begins to decode FACH. RNC tries to setup RRC
Connection to Cell_DCH and setups radio link to BTS and sends after
setup of radio link RRC CONNECTION SETUP message to UE with state
indicator Cell_DCH. When the RNC waits RRC CONNECTION SETUP
COMPLETE message (before faulty UE has decoded/received RRC
CONNECTION SETUP message from RNC) from faulty UE, faulty UE
decodes something rubbish from FACH and transmits new RRC
CONNECTION REQUEST message towards RNC with cause protocol
error. Then RNC deletes the existing radio link, setup new one and starts
RRC connection setup procedure with new spreading code (same time
the previous one getting another UE). However later on after the faulty UE
has been decoded something strange from FACH, faulty UE receives
first/original RRC CONNECTION SETUP message with state indicator
Cell_DCH sent by RNC moves to Cell_DCH state. Now there might be
two UEs using the same spreading code during RRC connection setup
phase, the faulty UE and another UE, and that may cause high power
spiking if/because two UEs listens to the same channel and they follows
the same TPC bits during ramp-up procedure, that is both raise the Trx
powers causing disturbs for each other in the cell and also to
neighbouring cells.

RRC CONNECTION REQUEST message sent with cause protocol error

before UE has been received RRC CONNECTION SETUP message is
due to faulty UE.

This will cause spiking during RRC Connection Setup and effects to KPIs
of RRC Connection Setup.

Implemented workaround for faulty UEs

RNC does not start to process retransmitted RRC Connection Request

with protocol error indication immediately, but waits for RRC Connection

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 82(447)
Basic Call
 Functionality description

Setup Complete for a time specified by PRFILE parameter. If RRC

Connection Setup Complete is received during waiting time, then RRC
Connection Request with protocol error indication is not processed.

In the new implementation, when the RNC receives repeated RRC

connection request from the UE, the RNC does not accept repeated RRC
connection request with cause protocol error if:

-RRC connection setup is not sent to UE or

-RRC connection setup is sent UE less than 50 ms earlier.

When the RNC receives repeated RRC connection request and RRC
connection setup is sent to UE over than 50 ms earlier then if:

-this is first repeated RRC connection request with cause protocol error,
then RNC waits for the time defined by PRFILE (default 1 second) if the
UE sends RRC connection complete.

-RRC connection setup complete is not received during defined waiting

time, then RNC starts to handle the repeated RRC connection request.

-this is second repeated RRC connection request, received during defined

wait time, then RNC starts to handle it.

PRFILE parameter (002:1687, RN50_MAINT_14 1.1-0) defines the time

the RNC delays the handling of repeated RRC connection request
received with cause protocol error. PRFILE parameter can be given the
following values:

- 0000 = 1000 ms (default value)

- 0001 = not used.

- Range from 0010 to 1111 (in decimal 2 to 15), the actual time is PRFILE
parameter value * 100ms.

NSN proposes to use default value for this parameter.

Modifications are implemented in RRB (part of less than 50 ms) and RRC
(part of more than 50 ms).

(There are failure reports PR 77827ESPE02, NA04792219 and PR

77828ESPE02 related to problem.)

<FLTYRRCConnPro/end>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 83(447)
Basic Call
 Functionality description

2.2.4 CELL_DCH State Procedures

Cell_DCH state is characterized by the allocation of a dedicated physical

channel to the UE in uplink and downlink. The Cell_DCH state is entered
from the Idle Mode through the setup of an RRC connection, or by state
transition from the Cell_FACH state (establishment of a dedicated transport
channel).

In the Cell_DCH state number of actions or procedures can be performed

without necessarily triggering any state transition. Most common
procedures in this state are following radio bearer control procedures,
measurement procedures, etc.

In this chapter shall be explained in detail RAB related procedures such as

setup and the release of RT and NRT RB, RAB reconfiguration, Radio link
Setup and Reconfigurations, and also other signaling such UE-CN
signaling setups.

Other procedures that are called and used in CELL_DCH state, will be
handled to next chapter (Features Functionalities) where we handled
following procedures such as DCH downgrade and upgrade, Dynamic link
optimization and Bit rate reduction due to the load reasons.

[Link] DCH allocation and in RRC connection setup

When the PS or CS RT RB is setup, it normally setup to Cell_DCH state. If

UE were in Cell_FACH state when the RAB assignament request is
received the RL is setup first. User plane allocation and state transition
from Cell_FACH to Cell_DCH is made by RRC: Radio bearer setup
procedure. The RRC connection setup and “a service establishment” for
NRT RAB(s) are performed as follows:

• During RRC Connection setup procedure, dedicated channel resources

are allocated to the UE (only a DCH for the signaling link is setup in this
phase). The UE is transferred from Idle Mode to the Cell_DCH state

• The UE performs a NAS connection establishment to the PS-CN. The

RRC entity starts supervision timer ‘RANAPprocInitWait ’ for RAB
Assignment (or Iu Release Command) from PS CN. Common channel
specific TVM(ID=4) measurement shall be configured to the UE..

• After the service negotiation has been carried out between the UE and
PS-CN, the PS- CN sends a RAB assignment request to the RNC. The
RRC entity stops supervision timer ‘RANAPprocInitWait ’. The RRC
entity performs a radio bearer setup with a RRC:Radio Bearer Setup
procedure (DCH for NRT RB(s) is not allocated in this stage).

No RANAP procedure received from the PS-CN

There may be only a NAS signaling sequence (RAU, SMS, etc.)

performed between the UE and the PS-CN. When this sequence
is completed and there is no Iu Release Command received from
the PS-CN, the RRC entity shall – after expiry of the supervision
timer ‘RANAPprocInitWait ’ – check the initial value of timer
‘SignConnActivitySupervision’ and if the transition to

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 84(447)
Basic Call
 Functionality description

Cell/URA_PCH is allowed. If the initial value of timer

‘SignConnActivitySupervision’ is not zero, maintaining of an
inactive signaling connection is allowed.

If the Cell/URA_PCH states cannot be used, the RRC entity shall

request the Iu release from the PS-CN and switch the UE directly
to the Idle Mode if/when the signaling link is inactive. Time
supervision GeneralRANAPTmr is used for supervising the receipt
of Iu Release Command from the [Link] after an expiry of the
‘RANAPprocInitWait’, the transition to Cell/URA_PCH is allowed
and the intial value of ‘SignConnActivitySupervision’ is non-zero,
the RRC entity shall switch the UE to Cell_FACH state (or
Cell/URA_PCH.The ‘SignConnActivitySupervision’ is started
if/when the UE is transferred to PCH states.

Note: When there is a signalling connection towards the CS-CN, state

transfer to Cell_FACH or Cell/URA_PCH can be initiated if there is no
CS AMR bearer.

• The traffic volume measurement parameters (RLC buffer level,

reporting criteria, etc.) are sent to the UE by using an RRC:
Measurement Control procedure. Based on this information the UE is
able to report the need of UL capacity (request the allocation of the
DCH) by sending a RRC: MEASUREMENT REPORT message to the
RNC. This measurement is not for Cell_FACH state. In case of PS NRT
RAB two TVM(s) are sent, one valid in Cell_DCH state and one valid
only in common channels.

• The RRC entity of RNC starts supervision timer

‘UL_DLcapacityReqWait‘ for the capacity request.

• If the capacity request is received from the UE or from the MAC-d of

RNC within the duration specified by the supervision timer
‘UL_DLcapacityReqWait‘, timer ‘UL_DLcapacityReqWait‘ is stopped
and the DCH for NRT RB(s) is allocated. A RRC: Radio Bearer
Reconfiguration procedure and a radio link reconfiguration procedure in
Iub interface (and Iur interface in case of inter-RNC SHO) are
performed.

• If there is no activity in RB(s) within the ‘UL_DLcapacityReqWait‘ and

the inactivity of signaling link is detected (‘SignallingLinkInactivityTimer’
has also expired), state transition from Cell_DCH to Cell_FACH (or
Cell/URA_PCH) is performed.

Note: the traffic volume measurement parameters are not sent in system
information broadcasts in RU20.

The RRC connection setup and the service establishment for RT RAB(s)
different from service establishment for NRT RAB(s) explainened above
from following step:
• After the service negotiation between the UE and the PS-CN is
carried out, the PS-CN sends a RAB assignment request to the
RNC, and the RNC stops the RANAP initiation timer
(RANAPprocInitWait). The RNC performs radio bearer setup for
requested RT service and the DCH or MAC-d flow for RT RB(s) is

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 85(447)
Basic Call
 Functionality description

allocated. The traffic volume measurement parameters only for

common channel (RLC buffer level, reporting criteria, etc.) are
also sent at this point to the UE. This is for Cell_FACH state
reporting.

[Link] NAS/Service establishment toward the CS-CN

When the NAS connection establishment is performed towards the CS-

CN, the RRC entity/MCC shall start an internal timer for supervising the
service establishment phase. The internal timer has a hard coded
value as follows:

RANAPprocInitWaitCS = 45 seconds

Timer is started after the Initial UE message is sent to the RANAP entity
and the “CN identity information” (CS-CN) is received from the RANAP
entity.

Timer is stopped when a RAB Assignment (or any other relevant

RANAP procedure allowing the UE to stay in Cell_DCH state or
Cell_FACH state) or an Iu Release Command is received from the CS-
CN. If the Iu Release Command is received from the CS-CN and there
are also (inactive) PS NRT/RT-RBs, the UE is switched to Cell_FACH
or Cell_PCH state (which is the normal procedure.

If the internal supervision timer expires, and there is no connection to

the PS-CN, the RRC entity shall request Iu release from the CS-CN
and switch the UE to the Idle Mode if/when the signaling link is also
inactive. Time supervision GeneralRANAPTmr is used for supervise
the receipt of Iu Release Command from the CN.

Note. For unrestricted digital information (UDI) calls, the call setup signaling
is longer than for a normal NRT RAB connection, due to the fact that the
UE behaves in a different way. When a UDI call is set-up, the CN orders
the RAB to be set up when the B-subscriber answers the incoming call, and
thus the timer for supervising the service establishment phase must be
longer. This internal 45-seconds timer concerns all signaling connection
establishment, for example, short message (SMS) message routed via the
CS-CN

Note. The timer ‘SignConnActivitySupervision’ is used only for PS-CN

connections – maintaining of the inactive signaling connection towards the
CS-CN is not allowed.

Special handling of NAS connection (USSD) establishment towards

the CS-CN

The duration of USSD service is variable and very different kind

of applications can use the USSD service. RNC does not know
the nature of these services but needs to maintain the signalling
link until CS-CN releases the service. In case of multi-RAB
connection no AMR call release, PS connection release or any

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 86(447)
Basic Call
 Functionality description

other similar procedure shall release the signalling connection if

USSD service is on.

When the NAS connection establishment is performed towards

the CS-CN, the RRC-d shall check the direct transfer messages
sent between UE and CS-CN in order to find out whether the
service establishment is USSD service. USSD service starts with
Registration message (NAS PDU 2nd byte = message type is 3B)
including operation code (12th byte) as ProcessUnstructuredSS-
Request (3B), UnstructuredSS-Request (3C) or UnstructuredSS-
Notify (3D). If USSD service is detected, RRC-d informs this to
RRC entity/MCC. RRC entity/MCC stops the
RANAPprocInitWaitCS timer and starts it again with longer value
as 5 minutes.

RRC-d continues checking the direct transfer messages. No

matter if USSD service is detected or not. If USSD service is
detected, it is also possible that new Registration message
including USSD info (detection is explained in previous chapter)
or Facility message is transferred. Facility message is detected
as NAS PDU 2nd byte is 3A (message type) after USSD service
is started. If either of the messages is detected by RRC-d, it
informs the RRC entity/MCC to restart the
RANAPprocInitWaitCS timer with longer value as 5 minutes.

NAS PDU Registration with operation code as

ProcessUnstructuredSS-Request :

1B 3B 1C 10 A1 0E 02 01 06 02 01 3B 30 06 04 01 0F 04
01 34 7F 01 00

NAS PDU Facility:

1B 3A 10 A1 0E 02 01 06 02 01 3B 30 06 04 01 0F 04 01
34 7F 01 00

Note: Message type is indicated by 6 bits, 7th and 8th bit needs
to be masked away.

[Link] Measurement Reporting Procedures

The UE measurements are grouped into 7 different categories/types. The

possible types of measurements are:

• Intra-frequency measurement: measurements on downlink physical

channels at the same frequency as the active set.

• Inter-frequency measurement: measurements on downlink physical

channels at frequencies that differ from the frequency of the active set.

• Inter-RAT measurement: measurements on downlink physical

channels belonging to another radio access system than UTRAN, that
is, GSM.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 87(447)
Basic Call
 Functionality description

• Traffic volume measurement: measurements on uplink traffic volume.

See Packet Scheduler SFS [25] for more information.

• Quality measurement: Measurements of quality parameters e.g.

downlink transport block error rate.

• UE Internal measurement: Measurements of UE Rx-Tx time

difference and TX power.

• UP measurement: Measurements of UE position.

In this chapter, we shall only discuss about Traffic Volume Measurements

(TVM). During RRC connected state the RNC can set up, modify or release
a measurement the UE by sending a MEASUREMENT CONTROL
message to the UE on the DDCH (see RRC Protocol Specification TS
25.331 [4] for more information). BTS measurement and explained
Handover measurements are outside the scope of this document. See
more information on handover measurement from HHO FD document.

TVM-control in Cell_DCH state

Common channel related TVM is configured to the UE in Cell_DCH state
by using RRC Measurement Control procedure when there is a signaling
connection towards the PS-CN established or UE using PS-service is
relocated to the target-RNC. This measurement is kept ON until the PS-
connection is released.
PS multi-RAB configurations will require separate handling (setup/modify/
release) of TVM of each individual RAB/RB separately during Cell_DCH
state. See more information on TVM from [18] document.
Validity information ‘Cell_DCH’ is used for TVM-control in Cell_DCH state
for each u-plane bearer, and thus there is no need to release the
measurement when switching the UE away from Cell_DCH.
The RB-specific measurement can be automatically “reused” without any
further control signaling to the UE if the stored measurement parameters
(~TVM-threshold) are correct / valid when the UE is switched to Cell_DCH
again. The bearer-specific TVM must – of course – be released if the PS
NRT RB has got the “maximum allowed bit rate” DCH-allocation. For PS
NRT and also PS RT this measurement must be setup after releasing the
current DCH-allocation.
For PS RT which have DCH-allocation no TVM is used in Cell_DCH state.

TVM-control handling in Cell DCH state

The RRC connection is established directly to Cell_DCH state the “initial”

PS NRT-RAB establishment is usually also executed in Cell_DCH state.
The RRC entity (MCC) shall setup TVM (ID=4) measurement immediately
after the RANAP-entity has indicated an establishment of Iu-PS connection
or in another word, that TVM is set after UE has indicated successfully
setup RB. Please note that there is no need to separately release this
measurement even if the Iu-PS connection is released and CS-service
keeps the UE in UTRA RRC Connected Mode.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 88(447)
Basic Call
 Functionality description

When the first PS NRT-RAB and the corresponding RB are setup and there
is 0/0 DCH-allocation, the RRC entity (MCC) shall setup RB-specific TVM
(TVM RB-1) by requesting the dedicated RRC signaling entity (RRC-d) to
start the RRC: Measurement Control procedure. Measurement validity is
set to ‘Cell_DCH’ and the initial TVM-threshold (8bytes) is configured to the
UE. Based on this request RRC-d maps this internal request to the RRC
procedure and is able to forward messages received from the UE to the
client entity (MCC).
For all UEs prior 3GPP REL5 the RRC Transaction ID = 0 shall be used
in the messages and the RRC entity shall send Measurement Control
messages one by one requesting the RLC entity to give “empty buffer”
indication when the previous message has successfully been delivered to
the UE.
When UL/DL capacity request is received and DCH-allocation <>0/0 is
configured, then MCC shall either request RRC-d to release the RB-specific
TVM or to reconfigure it by giving the TrafVolThresholdULHigh (default:
1024Bytes) to the UE. MCC shall store the RB-specific TVM information.
When there is a PS-NRT RAB/RB established or released, the MCC shall
configure or release the RB-specific TVM (TVM RB2, TVM RB3,) as
described above and store/maintain the RB-specific TVM information for
each RB individually.
[Link].1 Start Measurement Reporting

The decision when measurement reporting (for traffic volume

measurements) is started or modified is done by the SRNC's (SRNC)
Packet Scheduler (PS), ref [24]. The Handover measurements is started or
modified by the Serving RNC's (SRNC) Handover Control (HC), ref
[HC_SFS].
RNC's RRC signaling entity sends an RRC: MEASUREMENT CONTROL
(SETUP) message to UE's RRC signaling entity on the DCCH using AM
RLC. With this message the SRNC may request the UE to send reports
either during a predefined time period or until explicitly terminated and it
also defines the cells that must be measured. No Layer3 acknowledgement
is used.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 89(447)
Basic Call
 Functionality description

UE BTS RNC

RRC: MEASUREMENT CONTROL (Setup)

Reporting Criteria met

RRC: MEASUREMENT REPORT

Figure 18: Start Measurement Reporting procedure

The PS request RNC's RRC signaling entity to start the Measurement

Reporting procedure.

[Link].2 Management and mapping of measurement IDs

Management and mapping of measurement IDs describes only a

mechanism for measurement identity mapping used between the radio
interface (RRC signaling) and RNC-internal interfaces (DMX signaling).
Usage of different UE-measurements in different RRC states is described
in the relevant documents. Dedicated RRC signaling entity (RRC-d) shall
allocate the measurement identities used in RRC: Measurement Control
procedure in starting order of the measurements.

The measurement ID 1 is reserved for intra-frequency CPICH Ec/N0

measurements (Idle Mode and Cell_DCH) and the measurement ID 4 is
reserved for traffic volume measurements in all RRC states except
Cell_DCH. ID 4 cannot be utilized for any other type of measurement.

Internal measurement IDs (used inside of the RNC) are mapped to external
measurement IDs (used in RRC signaling) and the dedicated RRC
signaling entity (RRC-d) shall maintain this mapping as long as the
corresponding measurement is active. Based on the stored mapping
information, the received measurement reports (or failure messages) are
forwarded to the client using or requesting this measurement.

In case of SRNC relocation, the active measurements of the UE (and the

actual measurement IDs configured in the UE) are requested from
dedicated RRC signaling entity (RRC-d) and forwarded to the target-RNC.

Management of the measurement IDs is a transparent functionality and

each client of the RRC measurement procedures (HC, PS, LCS, etc.) can
freely allocate and use any number of different measurement IDs and all
numbers from 0 to 0FFFFh are available inside of the RNC. RRC-d entity
must, however, be able to identify/distinguish all different clients requesting
the measurement services.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 90(447)
Basic Call
 Functionality description

[Link].3 Prioritization of measurement message over other messages

Following mechanism is implemented for prioritizing of sending

measurement message over the other messages as defined following,

Message prioritization and buffering in RRC-d

RRC-d takes care of RRC protocol message prioritization and buffering in

case of SRB congestion. All DL RRC messages with Activation Time are
high priority (1) messages (also some other e.g. measurement related
messages are high priority, 1+ or 1). See table below.

RRC-d does not buffer high priority (1+ or 1) DL RRC messages, but sends
them directly to the RNC RLC. RRC-d does not even wait for the "RFU
status" before it sends the next high priority message to the RLC.

RRC-d buffers lower priority (2 etc) DL RRC messages if the signaling link
is congested (i.e. RRC-d has not received "RFU status" from the RLC).
RRC-d sends buffered DL RRC messages to UE via RNC RLC one by one
and RRC-d waits for the "RFU status" before it sends the next buffered
message to the RLC. By this way the RRC-d can prevent the RNC RLC
buffers from filling with the lower priority messages. Thus, the high priority
messages and messages with AT go through faster.

When RRC-d receives "RFU status", it sends the next RRC message with
the highest priority to the RLC. If there are several messages with the same
priority, RRC-d uses FIFO-principle. "RFU status" in this case means that
transmission buffer is empty and therefore the RLC can immediately start
transmission of the next DL RRC message.

Priority Message
1+ MEASUREMENT CONTROL (Release), if ordered by HA3
because of higher priority measurement needed to be started.
1 ACTIVE SET UPDATE,
DL RRC messages with AT,
MEASUREMENT CONTROL (High priority handover
measurements (Setup/Modify/Release)), (Note1)
2 DIRECT TRANSFER (High priority signaling, SRB3),
MEASUREMENT CONTROL (Location measurements,
(Setup/Modify/Release)),
MEASUREMENT CONTROL (Lower priority handover
measurements, (Setup/Modify/Release)), (Note2)
3 DIRECT TRANSFER (Low priority signaling, SRB4)
4 SIGNALING CONNECTION RELEASE (in cases when UE has
connection to both PS and CS CN)
5 MEASUREMENT CONTROL (Traffic Volume Measurement,
(Setup/Modify/Release))
6 RRC CONNECTION RELEASE

Table 1. DL RRC message priorities

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 91(447)
Basic Call
 Functionality description

Note 1:Intra-frequency CPICH EcNo for events 1a, 1b and 1c, periodical
inter-frequency, periodical inter-RAT and additional intra-frequency
measurements.
Note 2: All other handover measurements excluding the high priority
handover measurements.

When e.g. MCC or HA3 sends a measurement setup, release or modify to

RRC-d, it always checks the DL RRC message buffer thru. This is done to
avoid any unnecessary messages to be sent to RLC.

[Link].4 Queuing of Measurement Requests

Queuing of measurement requests is not implemented and it is a

future development item yet. If there are more than allowed amount of
simultaneous measurements requested, the request is immediately
rejected and notification is sent to the client.

There can be only sixteen RRC measurement procedures active

simultaneously and dedicated RRC signaling entity (RRC-d) shall, if
needed, queue the received measurement request as given in the
measurement request received from the client. If there is no maximum
queuing time given in the request, RRC-d shall use queuing time defined
by management parameter RRCmeasQueueTmr.

If the request cannot be served (forwarded to the UE) within

RRCmeasQueueTmr, dedicated RRC signaling entity (RRC-d) shall
remove the request from the queue and send a negative acknowledge to
the client with the failure information “too many active measurements”.

Sending of Measurement Control message

RNC's L3 RRC signaling entity sends an RRC: MEASUREMENT

CONTROL (SETUP) message to UE's L3 RRC signaling entity on the
DCCH using AM RLC. With this message the SRNC may request the UE
to send reports either during a predefined time period or until explicitly
terminated and it also defines the cells that must be measured. No L3
acknowledgement is used.

Reception of Measurement Report message

When reporting criteria is fulfilled, the UE's L3 RRC signaling entity sends
an RRC: MEASUREMENT REPORT message to SRNC's L3 RRC
signaling entity.

Processing of the Measurement Report message

Further processing of the Measurement Report messages is done by HC

and PS.

[Link].5 Stop Measurement Reporting

The decision when measurements are stopped, is done by the Serving

RNC's (SRNC) Handover Control and Packet Scheduler. The HC/PS
request RNC's RRC signaling entity to start the Stop Measurement
Reporting procedure.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 92(447)
Basic Call
 Functionality description

The RNC's RRC signaling entity sends an RRC: MEASUREMENT

CONTROL (RELEASE) message to UE's RRC signaling entity using AM
RLC. With this message the SRNC request the UE to stop certain
measurement. Message contains the identities of the measurements to be
stopped.

UE BTS RNC

RRC: MEASUREMENT REPORT

RRC: MEASUREMENT REPORT

RRC: MEASUREMENT CONTROL (Release)

Figure 19: Stop Measurement Reporting procedure

Parameters for the Release Measurement procedure

The HC and PS provide the information of the measurement to be

stopped.

Sending of Measurement Control (Release) message

The RNC's L3 RRC signaling entity sends an RRC: MEASUREMENT

CONTROL (RELEASE) message to UE's L3 RRC signaling entity using
AM RLC. With this message the SRNC requests the UE to stop certain
measurement. Message contains the identities of the measurements to be
stopped.

[Link].6 Modify Measurement Reporting procedures

The decision when measurements are modified is done by the Serving

RNC's (SRNC) Handover Control or Packet Scheduler. The HC/PS
requests RNC's L3 RRC signaling entity to start the Modify Measurement
Reporting procedure.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 93(447)
Basic Call
 Functionality description

UE BTS RNC

RRC: MEASUREMENT REPORT

RRC: MEASUREMENT REPORT

RRC: MEASUREMENT CONTROL (Modify)

RRC: MEASUREMENT REPORT

Figure 20: Modify Measurement Reporting procedure

Parameters for the Modify Measurement procedure

The HC/PS provides the information of the measurement to be modified.

For parameters, see [15 and 20].

Sending of Measurement Control (modify) message

The RNC's L3 RRC signaling entity sends an RRC: MEASUREMENT

CONTROL (MODIFY) message to UE's L3 RRC signaling entity using AM
RLC. With this message the SRNC request the UE to modify certain
measurement. Message contains the identities of the measurements to be
modified.

[Link].7 Failure of Measurement Reporting Cases

If the RNC instructs the UE to perform a measurement that is not supported

by the UE, the UE shall keep the measurement configuration that was valid
before the RRC: MEASUREMENT CONTROL message was received and
transmit an RRC: MEASUREMENT CONTROL FAILURE message to the
RNC/RRC on the DCCH using AM RLC. The UE uses the cause value
“unsupported measurement”.

Editor's note: the RRC transaction identifier is set in a different value in

RRC: MEASUREMENT CONTROL message depending on which entity,
HC or PS, initializes the measurement procedure.

Reception of Measurement Control Failure

When the RRC entity receives RRC: MEASUREMENT CONTROL

FAILURE message, it forwards it to the HC or PS depending on a value of
RRC transaction identifier IE in the message. The HC/PS makes decision
how to continue.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 94(447)
Basic Call
 Functionality description

[Link].8 No Reception of Measurement Report messages

RNC's RRC entity forwards all RRC: MEASUREMENT REPORT

messages to the HC or PS. If HC/PS doesn't receive these messages, it
makes the decision how to continue.

[Link] Radio Link Procedures

An UE that has RT radio access bearers has always a radio link

connection to the RAN. The RNC determines the radio link parameters
and requests radio link activation in the BTS. During the first radio link
setup the BTS selects the traffic termination point for the UE and sends
Communication Control Port identification of the associated NBAP-d
signalling link to the RNC. Once the traffic termination point has been
selected, it shall provide baseband processing and Iub user plane
termination for that specific UE as long as the UE has radio links to the
BTS. The radio link allocation in the BTS is valid until deallocation is
separately requested by the RNC.

[Link].1 Radio Link Setup Request

Radio Link Setup procedure is used to establish radio link and

simultaneously initiate creation of a new BTS communication context. The
signalling link setup, state transition from CELL_FACH state to
CELL_DCH state, soft HO or hard HO may initiate the NBAP: Radio Link
Setup procedure. This procedure is used to establish one or more radio
links and simultaneously initiate the creation of a new BTS
communication context. The procedure establishes one or more DCHs on
all radio links.

More details about radio link setup request see NBAP and RNSAP
procedures Functional Description document.

[Link].2 Radio Link Setup Response

After the BTS has verified and reserved the requested channel resources,
it requests the BTS's NBAP-c signalling entity to send the NBAP: RADIO
LINK SETUP RESPONSE message to the RNC's NBAP-c signalling
entity.

More details about radio link setup response see NBAP and RNSAP
procedures Functional Description document.

[Link].3 Radio Link Restore Indication

More details about radio link restore indication see NBAP and RNSAP
procedures Functional Description document.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 95(447)
Basic Call
 Functionality description

[Link].4 Radio Link Setup Failure

Radio link setup can fail, for example, because resources are not
available or the controlling RNC communication context is already in use.
If the BTS's resource manager for some reason cannot allocate the
requested channel resources or some BTS internal failure occurs, it shall
send an indication containing the most appropriate cause value to the
BTS's NBAP-c signalling entity. If radio link setup fails, the BTS sends a
failure message to the RNC indicating the cause value. The BTS's L3
Common NBAP signalling entity sends the message to the RNC's L3
Common NBAP signalling entity.

More details about radio link setup failure see NBAP and RNSAP
procedures Functional Description document.

[Link].5 Radio Link Reconfiguration Prepare

The decision when the NBAP Synchronised Radio Link Reconfiguration

Preparation procedure is started is done by the controlling RNC's
Resource Manager (RM), ref. [RM_SFS]. The RM requests the RNC's
NBAP-d signalling entity to start the NBAP Synchronised Radio Link
Reconfiguration Preparation procedure.

More details about radio link reconfiguration prepare see NBAP and
RNSAP procedures Functional Description document.

[Link].6 Radio Link Reconfiguration Cancel

If the BTS's NBAP-d signalling entity does not respond during time
defined by the timer T(BTS_Response), the RNC's NBAP-d signalling
entity forwards this information to the RNC's RM which shall request the
RNC's NBAP-d signalling entity to send the NBAP:RADIO LINK
RECONFIGURATION CANCEL message to the BTS for cancelling the
Prepared Reconfiguration.

More details about radio link reconfiguration cancel see NBAP and
RNSAP procedures Functional Description document.

[Link].7 Radio Link Reconfiguration Ready

After the BTS's resource manager has accepted the requested changes,
it requests the BTS's NBAP-d signalling entity to send the NBAP: RADIO
LINK RECONFIGURATION READY message to the RNC's NBAP-d
signalling entity as an indication of acceptance. After sending the
message, the BTS Communication Context enters into the Prepared
Reconfiguration state.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 96(447)
Basic Call
 Functionality description

More details about radio link reconfiguration ready see NBAP and RNSAP
procedures Functional Description document.

[Link].8 Radio Link Reconfiguration Commit

Sending of NBAP: RADIO LINK RECONFIGURATION COMMIT

After all involved BTSs have accepted the reconfiguration request and the
RNC's TRM has successfully executed the AAL2 Setup procedure (if
needed), the RNC's RM commands the RNC's NBAP-d signalling entity to
send the NBAP: RADIO LINK RECONFIGURATION COMMIT message
to the BTSs. At the same time when RL reconfiguration commit is set to
the BTS, also RRC message with activation time is sent to the UE.

More details about radio link reconfiguration commit see NBAP and
RNSAP procedures Functional Description document.

[Link].9 Radio Link Reconfiguration Failure

If the BTS can not accept the NBAP: RADIO LINK RECONFIGURATION
PREPARE message (e.g. the requested resources cannot be allocated for
some reason or BTS internal failure occurs), it responds with the NBAP:
RADIO LINK RECONFIGURATION FAILURE message.

More details about radio link reconfiguration failure see NBAP and
RNSAP procedures Functional Description document.

[Link].10 Radio Link Deletion Request

The NBAP:Radio Link Deletion procedure is used by the RNC to release

one or several radio links of a NodeB Communication context. This
procedure is triggered by the RNC's HC or RM and in some error cases
also by the RNC's NBAP-d signalling entity.

More details about radio link deletion request see NBAP and RNSAP
procedures Functional Description document.

[Link].11 Radio Link Deletion Response

After the BTS's resource manager has released the defined radio link(s)
identified by NodeB Communication context ID IE, CRNC Communication
context ID IE and RL ID(s), it commands the BTS's NBAP-d signalling
entity to send the NBAP: RADIO LINK DELETION RESPONSE message
to the RNC's NBAP-d signalling entity.

More details about radio link deletion response see NBAP and RNSAP
procedures Functional Description document.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 97(447)
Basic Call
 Functionality description

[Link] UE – CN Signalling Procedures

In order UE to call or send a data to the user is must be or have to set up

a circuit switched or packet switched connections. Before it has complete
connection with core network signaling part between UE and core
networks must be first setup.

Pre-request for these connections is that UE must first be RRC

connection established as explained earlier in topic “RRC connection
setup”. After the RRC connection is established the UE and CN has to
perform higher layer NAS Signalling before actual Radio Access Bearer
(RAB) setup. The NAS or Direct Transfer is transparent to the RNC is
sended over the the Dedicated Control Channel.

[Link].1 UE – CN Signalling Connection Setup

After this signaling and authentication procedures that are explained in

[Security FD document] completed the UE provides (NAS messaging) the
information about the transaction to be setup. For stance, if a normal
speech call, the UE sends the called number to the network. The CN finds
out whether it is possible to route the call and when the location of the
called UE is found out, the original setup is acknowledged with “ Call
Proceeding” NAS message.

Figure 28: Signalling connection setup

[Link].2 Initial Direct Transfer (IDT)

The UE sends an RRC: INTIAL DIRECT TRANSFER message to the

RNC over the Dedicated Control Channel (DCCH) established during
RRC connection setup. This message carries the initial NAS message, in
this case “CM service Request” indicating the destination –The CS-
CN/PS-CN that user wishes to place a call or send a data.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 98(447)
Basic Call
 Functionality description

UE BTS RNC CN

INITIAL DIRECT TRANSFER

RANAP: INITIAL UE MESSAGE

Figure 29: Initial direct transfer – establishment of signaling

connection from UE to CN

The UE will initiate a signaling connection establishment to the CN after

having established an RRC connection. The RNC shall receive an RRC:
INITIAL DIRECT TRANSFER message from the UE. The RNC shall
establish a signaling connection and forward the NAS message of the
RRC: INITIAL DIRECT TRANSFER message to the CN using a RANAP:
INITIAL UE MESSAGE.

INITIAL UE MESSAGE

The initial NAS message is then carried without modification from the
RNC to the CS-CN/PS-CN in the RANAP “Initial UE Message”

When the RNC receives an RRC: INITIAL DIRECT TRANSFER

message, and determines that no signaling connection to the indicated
domain is active, the RNC shall generate the RANAP: INITIAL UE
MESSAGE to be transferred to the CN node as determined by the NAS
Node Selection Function – if this function is active or otherwise to the
default CN node e.g. With the following contents: Location Update
Request, Connection Management Service Request, Paging Response,
IMSI Attach and IMSI Detach.

NOTE: (EFS CR#0771), Before sending RANAP:INITIAL UE

MESSAGEtowards SGSN, the RRC entity shall check the 3GPP
release version of the SGSN. If SGSN’s support is Rel9 or higher, the
RRC entity shall add a new optional IE "Higher bitrates than 16 Mbps
flag" to message. This flag shall be set to value “allowed” if the UE
supports Rel-7 and higher, or to value “not allowed” if the UE
supports up to Rel-6 only.

<ADA3.0/begin> If DSAC feature is enabled and the IDT carries a

Location Area Update (LAU) message, the LAU can be rejected under
some conditions. Please refer to section 2.3.25 for further details.
<ADA3.0/end>

< CRE1366/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 99(447)
Basic Call
 Functionality description

To improve CS service setup time for a call that has been redirected from
LTE when there is a simultaneous PS service registration ongoing, the
following change has been introduced.

When RRC: RRC CONNECTION REQUEST for CS voice call (Domain

indicator = CS Domain) is received and following conditions are fulfilled:

• It is detected with the following legacy ways that the UE has been
moved from LTE

o Non-existence of Pre-redirection info IE in the message

when UE is LTE capable indicates that UE has been
redirected from LTE OR

o Existence of CSFB Indication IE indicates that UE has

been redirected from LTE

• And the functionality is activated with the 8th bit of the PRFILE
parameter 002:2281 RU50_SPARE_19 (8th bit set to ‘1’). The
functionality is deactivated by default.

In that case until the CS voice RAB has been established, when the
message RRC: INITIAL DIRECT TRANSFER for PS CN is received, the
UE specific RRC starts a hardcoded eight seconds timer. The handling of
the message is delayed by the UE specific RRC until the timer expires or
is stopped. The timer is stopped when CS call setup is completed from
RNC point of view or when MSC releases the Iu connection.

If the CS call establishment fails, it is handled in legacy manner as if the

RRC: INITIAL DIRECT TRANSFER for PS CN had not been received, i.e.
RRC connection is released.

If the UE makes only LAU (no CS voice call) and the CS CN releases the
CS Iu connection, the UE specific RRC performs Signaling Connection
Release procedure for CS connection and continues handling the RRC:
INITIAL DIRECT TRANSFER for PS CN.

<CRE1366/end>

[Link].3 Downlink Direct Transfer (DDT)

Routing of downlink CN Control Plane messages:

Upper layer downlink messages received from different core network
nodes in RANAP: DIRECT TRANSFER message are transported over the
air interface using RRC: DOWNLINK DIRECT TRANSFER message.

There is no way to indicate to the CN if a failure to transfer a NAS

message to the UE has occulted. The upper layers take care of message
repetition.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 100(447)
Basic Call
 Functionality description

UE BTS RNC CN

RANAP: DIRECT TRANSFER

RRC: DOWNLINK DIRECT TRANSFER

Figure 30: Downlink Direct Transfer

[Link].4 Uplink Direct Transfer (UDT)

Routing of uplink CN Control Plane messages:

Upper layer uplink messages destined to different core network nodes are
transported over the air interface in RRC: UPLINK DIRECT TRANSFER
message. The uplink direct transfer procedure can be used in CELL_DCH
and CELL_FACH states.

The NAS message in RRC: UPLINK DIRECT TRANSFER message is

directly forwarded to the correct CN domain by using RANAP: DIRECT
TRANSFER message on Iu interface.

UE BTS RNC CN

RRC: INTIAL UPLINK DIRECT TRANSFER

RANAP: DIRECT TRANSFER

Figure 31: Uplink Direct Transfer

[Link].5 UE – CN Signalling Connection Release

Case 1: Signallng connection release from of several core network nodes

The UE may have several ongoing signaling connections to different core

networks. If one network requests the release of the Iu connection with
RANAP: IU RELEASE COMMAND and the RNC detects that there are

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 101(447)
Basic Call
 Functionality description

still other signaling connections using the current RRC connection, the
RRC connection is not released, but the UE is informed with RRC:
SIGNALLING CONNECTION RELEASE message that one of its
signalling connections is released. After having sent the RRC:
SIGNALLING CONNECTION RELEASE message on the DCCH using
AM RLC, the RNC acknowledges the signaling connection release to the
CN with RANAP: IU RELEASE COMPLETE message. The UE-RRC
informs the corresponding UE MM of signaling connection release.

If there are still radio bearers left, which have not been released between
the UE and CN before the signaling connection to that CN is released, the
UE and RNC release the bearers at the same time as the signaling
connection is released. The RNC shall send the RRC: SIGNALLING
CONNECTION RELEASE message only on the DCH

Note: If there are RABs to be released, signaling connection is released

using RRC: RADIO BEARER RELEASE message. UE indicates with
RRC: RRC STATUS message if there are RABs for the indicated CN
domain existing as error response for RRC: SIGNALLING CONNECTION
RELEASE message,

UE BTS RNC CN1 CN2

RANAP: IU RELEASE COMMAND

RRC: SIGNALLING CONNECTION RELEASE

RANAP: IU RELEASE COMPLETE

Figure 32: Release of one of several signaling connections

Case 2: RNC Initiated signalling connection release

In RNC initiated releases, the signaling connection is released to all CN

nodes, to which the UE was connected. The RNC sends RANAP: IU
RELEASE REQUEST message to the CN node(s), to which the UE is
connected. In consequence, each CN node will return a RANAP: IU
RELEASE COMMAND message.

If there is no response from the CN within a predefined time period of

GeneralRANAPTmr of seconds, the RNC will continue with releasing the
resources locally.

Case 3: Signalling connection release caused by RNC internal reason

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 102(447)
Basic Call
 Functionality description

In cases, where the signaling connection release is caused by RNC

internal reasons, the RNC shall wait for all CN nodes to send RANAP: IU
RELEASE COMMAND message before initiating the RRC connection
release procedure on the air interface. After the RRC connection release
procedure has been completed, the RNC sends each CN node RANAP:
IU RELEASE COMPLETE message.

The RNC initiates a signaling connection release e.g. in the following

situations:

RNC/RM or RNC/RANAP detects HW overload

RNC/RM or RNC/RANAP RNC detects equipment failure
NBAP BTS HW detects overload
NBAP BTS detects equipment failure
LC detects air interface overload
HC detects radio link failure
User inactivity
DRNS requires radio link pre-emption

Case 4: Signalling connection release is caused by loss of contact to the

UE

In cases, where the signaling connection release is caused by loss of

contact to the UE, the RNC shall not initiate the RRC connection release
procedure over the air interface. After having received RANAP: IU
RELEASE COMMAND message from a CN node, the RNC sends an
RANAP: IU RELEASE COMPLETE message to that CN node. In this
case, there is no need to wait for RANAP: IU RELEASE COMMAND
message from all CN nodes, before the acknowledgement is sent and the
RRC connection is released.

After the RRC connection release procedure has been completed, the
RNC sends each CN node a RANAP: IU RELEASE COMPLETE
message.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 103(447)
Basic Call
 Functionality description

UE BTS RNC CN1 CN2

RANAP: Iu RELEASE REQUEST

RANAP: Iu RELEASE REQUEST

RANAP: Iu RELEASE COMMAND

RANAP: Iu RELEASE COMMAND

RRC connection release procedure

RANAP: Iu RELEASE COMPLETE

RANAP: Iu RELEASE COMPLETE

Figure 33: RNC initiated signaling connection release to all CN

nodes

Case 5: Signalling connection release indication by UE

The UE may indicate that one of the UE’s signaling connections has been
released. The UE initiates the signaling connection release indication
procedure by transmitting RRC: SIGNALLING CONNECTION RELEASE
INDICATION message on DCCH using AM RLC.

Upon reception of a RRC: SIGNALLING CONNECTION RELEASE

INDICATION message, the RNC requests the release of the signaling
connection from the indicated CN domain by sending RANAP: IU
RELEASE REQUEST message with the cause value “Release due to UE
generated signaling connection release”. The CN may then initiate the
release of the signaling connection, which may in turn initiate the RRC
connection release procedure.

[Link] RANAP COMMON ID

RNC CN

RANAP: COMMON ID

Figure 34: Common ID procedure

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 104(447)
Basic Call
 Functionality description

The purpose of the RANAP common ID procedure is to allow the RNC to

create a reference between the IMSI of a user and the RRC connection of
that user. This is achieved by sending the IMSI of a verified user from the
CN to the RNC. The RNC is then able to check whether there is already
an RRC connection to the UE when another CN starts paging by sending
a RANAP: PAGING message. The RRC connection can be already used
by another CN, and if this is the case, the RNC uses the existing
signalling radio bearer to send the paging message to the UE.

The CN should send a RANAP: COMMON ID message after it has

ensured the identity of UE. The message contains the IMSI of the user.
The COMMON ID message may also include the UESBI-Iu IE. The RNC
associates the permanent identity to the RRC connection of that user and
saves it for the duration of the RRC connection.

The RNC shall store the UESBI-Iu IE when received in the COMMON ID
message.

The common ID procedure is necessary, because the RNC does not

receive the IMSI during the RRC connection establishment procedure.

The common identifier received in the common ID procedure shall be

stored by the RNC in order to determine if further paging of a connected
mode UE should utilize the already existing RRC connection. The
common identifier shall be retained in the RNC until the RRC connection
of the corresponding UE is terminated.

[Link] Radio Access Bearer Procedures

Radio Access Bearer (RAB) is used for the transfer of the user data. One
or more independent and simultaneous UE-CN Radio Access Bearer
connections can exist for each user. The radio access bearer
establishment procedure is initiated when a CN and an UE have
negotiated all parameters, which are needed for radio access bearer
service establishment in the RAN.

An initial condition for the Radio Access Bearer Establishment procedure

is that the UE is in contact with the fixed infrastructure of UMTS with a
RRC connection between the UE and the RNC and with a SCCP
connection between the RNC and the CN.

UMTS Signaling Radio Bearers (SRBs)

The Radio Bearers (RB) available for transmission of RRC messages are

defined as "signaling radio bearers" (SRB). The UE and RNC shall select

the SRBs for RRC messages using RLC-TM, RLC-UM or RLC-AM on the

DCCH and CCCH, according to the following principles:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 105(447)
Basic Call
 Functionality description

• SRB RB0 shall be used for all messages sent on the CCCH (UL: RLC-
TM, DL: RLC-UM).
• SRB RB1 shall be used for all messages sent on the DCCH, when using
RLC unacknowledged mode (RLC-UM).
• SRB RB2 shall be used for all messages sent on the DCCH, when using
RLC acknowledged mode (RLC-AM), except for the RRC messages
carrying higher layer (NAS) signaling.
Note. The RNC normally prefers an AM-RLC for all RRC messages.
• SRB RB3 (high priority signaling bearer) and SRB RB4 (low priority
signaling bearer) shall be used for the RRC messages carrying higher
layer (NAS) signaling and sent on the DCCH in RLC acknowledged
mode (RLC-AM).
For NRT (Non Real Time) services, the radio access bearer can be
established without immediate reservation of radio resources. The radio
resources will be allocated on demand using signaling link between the
UE and the RNC

RT radio bearer

A radio bearer which has specified transfer delay requirement, used for:

- CS voice services
- Conversational (Transparent) CS data servives
- Streaming (Non-transparent) CS data services
- Conversational PS data services
- Streaming PS data services
NRT radio bearer

A radio bearer which has no transfer delay requirement, used for:

- Interactive PS data services

- Background PS data services

[Link].1 RANAP RAB Assignment Handling

A PS call setup is realized by a RANAP RAB Assignment procedure. This

procedure is always initiated by CN. Purpose of the procedure is to
establish new RAB connections, or modify and release existing RAB
connections. In a role of a CN network element, PS-CN initiates RAB
Assignment procedure by sending RAB Assignment Request message to
RNC. From PS call point of view, there are parameters included Transport
Layer Address (PS-CN IP address), Iu Transport Association (GTP TEID
for UL-data).

The RNC analyses the radio access bearer service parameters and
checks whether there are enough resources for the requested radio
access bearers. After that, the RNC activates or modifies the physical
uplink and downlink radio channels from the WCDMA BTS(s) and
establish the transmission channels at the Iub and Iur interfaces
according to reserved radio resources. Then the RNC sends to the UE
the new radio link parameters on the existing signaling link.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 106(447)
Basic Call
 Functionality description

When the UE tells to the RNC that it has applied the new radio link
parameters, the RNC informs the CN and the radio access bearer
establishment is completed.

RT radio bearer

A radio bearer which has specified transfer delay requirement, used for:

- CS voice services
- Conversational (Transparent) CS data servives
- Streaming (Non-transparent) CS data services
- Conversational PS data services
- Streaming PS data services
NRT radio bearer

A radio bearer which has no transfer delay requirement, used for:

- Interactive PS data services

- Background PS data services

[Link].1.1 RANAP RAB Assignment Request

PS-CN case:

When the CN has all necessary information, the CN sends a RANAP:

RAB ASSIGNMENT REQUEST message to the RNC. This message
defines the desired bearer parameters, i.e. QoS and traffic characteristic
to be required/produced by the user of the requested Radio Access
Bearer. These parameters are conveyed to the RRM/AC and the RRM
analyses parameters and make decisions to perform RAB establishment.

RANAP: RAB ASSIGNMENT REQUEST message contains also a binding

ID for each transport network control plane link that is needed towards
CS-CN and Terminal End-point Identifier (TEID) for PS-CN. These
Binding ID’s are returned in corresponding Transport Network control
plane setup messages. TEIDs are used in each GTP packets. Different
RAB parameters in UL/DL. ”AC may allocate different AMR modes for
UL.” Also different bitrates for UL/DL can be for NRT.

CS-CN Case:

In CS case, Message includes various Radio Access Bearer parameters

and transport layer addressing information for establishing the Iu_CS
bearer. RANAP: RAB ASSIGNMENT REQUEST message is then
forwared to RRC. RRC analyzes received RAB parameters to determine
e.g. the service and the bitrates requested for the RAB.

Handling of PDT type information

The RANAP: RAB Assignment Request message from PS-CN contains

also PDP type information element. The RANAP entity conveys this
information to the PDCP entity.

User plane mode

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 107(447)
Basic Call
 Functionality description

CN decides user plane mode according to RAB parameters. RRM, TRM,

RLC/MAC and FP need this information in RNC.

<E1316/begin>
Sending of erroneous speech frames of NB-AMR and WB-AMR calls to
CS CN is controlled by the 9th bit of PRFILE parameter 002:2141
RU40_MAINT_45. Default value is 0.
When the 9th bit is set to 1, L3 configures L2 with transmit_errors_up set
as FALSE for NB-AMR and WB-AMR calls. This prevents L2 from
sending erroneous SDUs to CS CN, regardless of the RAB parameter
‘Delivery of Erroneous SDU’ request received from CS CN.
When the 9th bit is set to 0, L3 configures L2 with transmit_errors_up set
as TRUE for NB-AMR and WB-AMR calls. This causes L2 to send also
erroneous SDUs to CS CN, which is the legacy implementation.

Note: Valid also during incoming relocation.

<E1316/end>

Selection of RAB parameters

The description of the radio access bearer parameters can be either a

complete list or the CN may give some freedom in the selection
(alternative RAB parameter values). Alternative RAB parameter values
are not supported in RU20. They are ignored if received.

Handling of service Handover IE

More information on this issue shall be discussed in [81] document.

Different RAB parameters in Uplink/Downlink directions

The radio access bearer service parameters can be different in uplink and
downlink directions.

Note: Although the CN says, that the RAB is symmetric bidirectional, the
AC may allocate different AMR modes for UL and DL directions. Also
different bit rates for NRT services can be allocated in UL/DL directions

Unidirectional RAB

The RAB can be set unidirectional.

Bidirectional RAB

The RAB can be set bidirectional.

Handling of NAS Synchronization Indicator

The NAS Synchronization Indicator parameter is a transparent parameter

for RAN. The parameter is moved to the UE in RRC: RADIO BEARER
SETUP message as a part of RAB information for setup parameter.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 108(447)
Basic Call
 Functionality description

Handling of GTP and N-PDU sequence numbers

GTP parameters are transferred to the GTP entity and N-PDU parameters
to the PDCP entity.

- DL GTP-PDU sequence number (only when GTP-PDU

sequence number is available in cases of handover from
GPRS to UMTS or when establishing a RAB for an existing
PDP context).

- UL GTP-PDU sequence number (only when GTP-PDU

sequence number is available in cases of handover from
GPRS to UMTS or when establishing a RAB for an existing
PDP context).

• DL N-PDU sequence number (only when N-PDU sequence

number is available in case of handover from GPRS to
UMTS).

- UL N-PDU sequence number (only when N-PDU sequence

number is available in case of handover from GPRS to
UMTS).

Execution time of procedures

The RNC performs preparation of the RL reconfigurations (over Iur and

Iub) and activations in the WCDMA BTS; this includes also the setup of
the user plane over Iub and Iur. The RNC/RRM (in SRNC and DRNC)
analyses the radio access bearer service parameters and checks whether
there are enough resources for the requested radio access bearers. After
that SRNC/RRC decides a suitable execution time, when needed for the
change and includes that to the RRC: RADIO BEARER SETUP message
and as well sends the execution time for the WCDMA BTSs over Iub (and
Iur). Also user plane switching must be made at the same time.

The SRNC then sends a RRC: RADIO BEARER SETUP message to the
mobile station on used transport channel and starts implementation timer
T_RRC_Resp_DCH (or T_RRC_Resp_CCH).

Mapping of RAB ID’s

Radio Bearers 0…4 are reserved for signaling. CN Domain indicator, RAB
id and RB id are transferred to the UE.

After a reception of a RAB Assignment Request message, RNC sets up

all necessary resources for new RAB connection. This resource
reservation procedure is controlled by L3 signalling entity

As you can see, RNC and PS-CN exchanges their GTP endpoint
addressing information during the PS RAB Establishment procedure. This
is illustrated in following figure below. When the PS RAB has been
successfully created, RNC sends UL packet data to the GTP tunnel
endpoint signalled by PS-CN in RAB Assignment Request message, and

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 109(447)
Basic Call
 Functionality description

PS-CN sends DL packet data to the GTP tunnel endpoint signalled by

RNC in RAB Assignment Response message

GTP entity L3 entity SGSN

PS-CN

RAB Assignment Request

GTP entity is
(IP - address, UL - TEID)
associated with IP -
address, thus RNC’s
IP - address gets
Choose
choosen as well.
GTP entity

Allocate GTP tunnel

Allocate
GTP tunnel

DL - TEID

RAB Assignment Response

(IP - Address, DL - TEID)

Figure 35: RAB Assignment Procedure

<REQ1587/begin>

Note that there is a clear bug in Ericsson RNC, but NSN has implemented
workaround from customer request.

RNC workaound for Ericsson RNC problem will be done under PRFILE
(002:1694 RN50_MAINT_18 1.1-0)

NSN implementation :

NSN RAN allocates RB ID and Transport Channel Id for the incoming

RABs in the order they are received from the Core Network. So the first
RAB will always get RB ID 5 and the next one will get 6 and then 7 and so
on…

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 110(447)
Basic Call
 Functionality description

E/// implementation (as seen from the logs):

E/// RAN seems to have assumption that the AMR RB Ids will always be
5, 6 and 7 and PS will have anything greater than 7. Note that RB ID
1,2,3 and 4 are reserved for SRBs in the 3GPP specs, and there is no
conflict of opinion in that one.

If call starts in NSN RAN so that there is PS established first and then
AMR, then NSN SRNC allocates RB ID 5 for PS and 6,7,8 for the AMR
RBs. When relocation is triggered to E/// Target NW, CN rejects the PS
relocation and PS will be dropped as per the workaround implementation
in NSN RAN. Now when next relocation will be tried with only AMR with
RB ID 6, 7 and 8, then E/// Target RNC does not read the RB ID
information provided in the SourceToTargetRNC Container and it
allocates its own RB Ids 5, 6 and 7 for AMR and gives new transport
channel mapping for those RBs.

This causes invalid configuration since RB ID 5 does not exist on UE and

also E/// Target RNC does not provide any mapping for the RB ID 8. So
this results one extra RB configured in the handover message whcih does
not even exist on UE and incorrect mapping for the existing RBs and UE
rejects the handover procedure.

In other direction, if there is NSN RAN in the Target side and it receives
Relocation Request from E/// SRNC, NSN RNC can handle it very
smartly, no matter what configuration is given by the Source RNC. NSN
RNC can handle any RB ID/ Transport channel ID configuration as long
as they are valid according to the specs.

Implemented workaround:

NSN RAN uses hardcoded RB-id values 5, 6 and 7 for AMR call, if
feature activated via PRFILE parameter.

<REQ1587/end>

<PR NA05786422/begin>

Maximum Bit Rate / Extended Maximum Bit Rate handling

The RANAP entity/AC accept RANAP: RAB ASSIGNMENT REQUEST

message with Maximum Bit Rate / Extended Maximum Bit Rate IE
combinations that are not allowed by 25.413 /5/ (and regardless of the
RAB Asymmetry Indicator value).

• The SGSN sends two Maximum Bit Rate IEs and one Extended
Maximum Bit Rate IE. RANAP entity replaces the first Maximum
Bit Rate that has been set to its maximum value (16M) with
Extended Maximum Bit Rate. Example:

MBR EMBR Forwarded values

16M 8M 22M 22M 8M
8M 16M 22M 8M 22M

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 111(447)
Basic Call
 Functionality description

16M 16M 22M 22M 16M

8M 8M 22M 8M 8M

• The SGSN sends two Maximum Bit Rate IEs and two Extended
Maximum Bit Rate IEs. RANAP entity replaces the Maximum Bit
Rate that has been set to its maximum value (16M) with Extended
Maximum Bit Rate. Example:

MBR EMBR Forwarded values

16M 16M 22M 32M 22M 32M
16M 8M 22M 32M 22M 8M
8M 16M 22M 32M 8M 32M

• The SGSN sends one Maximum Bit Rate IE and one Extended
Maximum Bit Rate IE. Example:

Forwarded
MBR EMBR value
16M 22M 22M
8M 22M 8M

<PR NA05786422/end>

[Link].1.2 RANAP RAB Assignment Response (Successful)

When the radio assignment procedure has been successfully

accomplished (Radio Bearer Setup Complete received and all transport
links are successfully established at RAN side), the RAN will return a
RANAP: RAB ASSIGNMENT RESPONSE message to the CN.

<RAN3376/begin>

If RAN3376 Accelerated Voice Setup (phase1) feature functionality

triggers, during CS RAB assignment, RNC sends RANAP: RAB
ASSIGNMENT RESPONSE message to CN simultaneously with sending
of RRC:RADIO BEARER SETUP to [Link] accelerates CS RAB
assignment procedure app. 200ms - 400 ms.

<RAN3376/end>

For NRT (Non Real Time) services, the radio access bearer can be
established without immediate reservation of radio resources, see [4]. The
radio resources will be allocated on demand using signaling link between
the UE and the RNC.

[Link].1.3 RANAP RAB Assignment Response (Failure)

Setting up a radio access bearer can fail, for instance, because the RNC
cannot provide the resources requested. If the requested channel type or
resource (for example channel rate) indicated in the RANAP: RAB

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 112(447)
Basic Call
 Functionality description

ASSIGNMENT REQUEST message is not available in the RAN, a

RANAP: RAB ASSIGNMENT RESPONSE message is sent to the CN.
The message contains the appropriate failure cause (determined by
Admission Control) will be included in the message.

Figure 36: RANAP Assignment Failure

[Link].2 RRC Radio Bearer Setup

The RNC sends the RRC: RADIO BEARER SETUP message to the UE
over an existing dedicated control channel (DCCH). This message
contains parameters related to the dedicated channel that has been set
up for carrying the radio access bearer such as Transport Format Set
(TFS), Transport Format Combination Set (TFCS), and Downlink
Channelization code.

Building of RRC: RADIO BEARER SETUP message

The RRC: RADIO BEARER SETUP message for RT radio access bearer
establishment structure and used IE’s in this message are described in [4]
and [8]. One RRC: RADIO BEARER SETUP message may be used to
setup more than one radio access bearers. This message is transmitted
using AM RLC (AM or UM in RRC specs).

Radio Bearer Setup with state transition from Cell_DCH to Cell_DCH

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 113(447)
Basic Call
 Functionality description

The UE responds by sending an RRC: RADIO BEARER SETUP

COMPLETE message. The response message is sent by using the new
configuration (i.e. via the DCH).

The RRC entity receives RRC: RADIO BEARER SETUP COMPLETE

message as an indication of successful state change. The RRC entity
forwards this information to the MAC-d entity.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 114(447)
Basic Call
 Functionality description

MS BS RNC CN

Signalling link established, MM and CC signalling ...

RANAP:RAB Assignment
Request

If reserved radio resources don't support

required bearer, a new code is needed

Radio link reconfiguration, Time (DCH to DCH)

User plane establishment

User plane establishment

RRC:RB Setup (Time)

RRC:RB Setup Complete()

RANAP:RAB Assignment
Response

CC continues...

Figure 37: Radio Access Bearer Establishment procedure (Cell_DCH

to Cell_DCH)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 115(447)
Basic Call
 Functionality description

Radio Bearer Setup with state transition from Cell_FACH to Cell

FACH

UE BTS RNC SGSN

Signalling link established, MM and SM Signalling ..

RANAP: RAB ASSIGNMENT REQUEST

No NBAP procedure (Cell_FACH to Cell_FACH

RRC: RB SETUP

RRC: RB SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

User plane establishement

RRC:MEASUREMENT CONTROL (setup)

Traffic Volume Measurement

SM continue….

Figure 38: Radio Access Bearer Establishment procedure (Cell_FACH to

Cell_FACH)

Radio Bearers for AMR speech call with UEP

The CS-CN may require establishing one or more RAB sub flow. Each
RAB sub flow requires own Radio Bearer and DCH. These DCHs are
multiplexed to one AAL2 channel in FP layer. Radio Bearer parameters
except TFS (channel coding) are the same for each DCH.

Iu-UserPlane Connection Modification

It is possible to modify Iu-userplane connection of RAB instance without

Radio Bearer modification. There is possibility that for example to Call
Hold and Call Enquiry procedure, Iu-userplane connection is changed
from one MGW to another MGW. For that, the old Iu-userplane
connection is released and new Iu-userplane connection is build.

Note: This was not supported in RU20.

[Link].3 Additional RAB Establishment

The same procedures (e.g. RANAP: RAB Assignment Request, RRC:

Radio Bearer Setup) are used as in first radio access bearer

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 116(447)
Basic Call
 Functionality description

establishment and It’s possible to establish several radio access bearers

with the same radio interface procedure, except terrestrial transmission
channels (AAL2) are established one by one.

For exact information see [18].

UE BTS RNC CN1 CN2

At least one active bearer

RANAP: COMMOND ID UPDATE

RANAP: RAB ASSINGMENT REQUEST

RL reconfiguration procedure

User plane establishment

RRC: RB SETUP

RRC; RB SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

Figure 39: Additional radio access bearer establishment (CELL_DCH

state procedure).

[Link].4 NRT RAB Establishment

For NRT RAB, no radio resources are allocated immediately during

RANAP: RAB Assignment procedure. The radio resources will be
allocated on demand. The RRC: RADIO BEARER SETUP message will
be sent, but no immediately DCH allocation is done.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 117(447)
Basic Call
 Functionality description

UE BTS RNC SGSN

Signalling link established, MM and SM Signalling ..

RANAP: RAB ASSIGNMENT REQUEST

User plane establishment

RRC: RB SETUP

RRC: RB SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

SM continue….

Figure 40: NRT RAB establishment

Establishment of NRT RAB in anchor situation

When all radio links are under other than SRNC, and SRNS relocation is
not possible to perform, the establishment of NRT RABs is possible but
radio resources are not allocated. The RANAP entity sends RANAP: RAB
ASSIGNMENT RESPONSE/setup ok message to the SGSN.

<not in ADA3.0/begin> If Iur Mobility Enhancements feature (RAN1759) is

enabled (see /20/ Hard Handover and SRNC Relocation FD) and
DCHScheOverIur parameter is set “supported”, then also radio resources
can be allocated for NRT RAB in anchoring situation. See more from
chapter “NRT RAB handling in anchoring situation”. <not in ADA3.0/end>

Establishment of RAB in NRT DRNC situation

When all radio links are under other than SRNC, and there are only NRT
RABs, RNC waits for UE state change before SRNS relocation is
triggered (or inhibition timer expires), . If in this situation the RANAP: RAB
ASSIGNMENT REQUEST/SETUP is received, this immediately triggers
SRNS relocation procedure. The RANAP entity rejects RAB
establishment and sends RANAP: RAB ASSIGNMENT
RESPONSE/failure message with cause value “Relocation Triggered (6)”.

Also the RNC may ask PS-CN to release the RAB connections (RANAP:
RAB Release Request), or whole Iu connection (RANAP: Iu Release
Request). An evident reason for the RNC initiated RAB/Iu release is e.g.
due to received GTP: Error Indication, some failure or lack of resources in
the RNC.

PS-CN may decide to release certain RABs, or to release all RABs and the
Iu-PS signalling connection in such a way that the PDP context is still kept

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 118(447)
Basic Call
 Functionality description

active in the UE and in the PS-CN (preservation procedure, see 3GPP TS

23.060).

[Link].4.1 NRT RAB handling in anchoring situation

<not in ADA3.0/begin>

DCH Packet Scheduling is supported over Iur in anchoring situation. NRT

DCH bitrate modification (bitrate allocation, upgrade and downgrade),
priority Based Scheduling, overload control, pre-emption, RT over RT, RT
over NRT, Dynamic link optimisation, activity/inactivity detection and
throughput based optimisation of the PS algorithm shall be possible for
Rel99 DCH (see more about these RRU features from RRU side FD’s: /8/
Admission Control FD and /15/ Packet Scheduler FD).

The features ‘Iur mobility enhancements’, ‘DCH Scheduling’ and ‘ISHO

during anchoring’, can be optionally enabled or disabled in the SRNC
using separate feature enabling parameters IurMobEnh,
DCHScheOverIur and ISHOInIurMobility (see /20/ Hard Handover and
SRNC Relocation FD).

IurMobEnh parameter indicates if DRNC is an I-BTS adapter (see /20/

Hard Handover and SRNC Relocation FD). If DCHScheOverIur (DCH
Scheduling over Iur) parameter is set to value “Supported”, then above
mentioned NRT RAB functionalities are active and can be used.
ISHOInIurMobility (Inter System Handover In Iur Mobility) indicates if inter
system handover is possible in anchoring situation (see /20/ Hard
Handover and SRNC Relocation FD).

<not in ADA3.0/end>

Upon receving a RANAP:RAB Assignment Request for PS NRT RAB

during anchoring (see /15/ Packet Scheduler FD), SRNC performs the
following steps:

• Admit the new NRT RAB without checking the load status in the
active set cells controlled by the DRNC.

• Normal RLC and Transport Channel parameters for the NRT RAB
are allocated.

• NRT DCH with bitrate 0/0 without user plane is allocated.

Normal TVM is started in the UE and in the RNC after the successful
setup of the NRT DCH RB 0/0.

Later based the reports from the UE or L2 in the uplink or downlink

capacity allocation shall take place.

<not in ADA3.0/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 119(447)
Basic Call
 Functionality description

[Link].4.2 DCH/HSPA allocation for NRT RAB in anchoring situation

DCH bit rate downgrading and upgrading and HS-DSCH/E-DCH

allocations in anchoring are supported.

Traffic Volume Measurements (TVM) with normal values are set also in
anchoring situation for all PS RABs. If radio resource must be allocated
due to RRC Measurement Report/TVM from UE or DL data indication
from L2 (IUE/IUG/MAC-d), the resources are normally asked from
RRM/BRM/UER. RRM allocates resources based on supported/activated
features over Iur.

Resources are normally reserved from NRM and normal RNSAP Radio
Link Reconfiguration Prepare is sent to the DRNC (I-BTS).

After DRNC and UE acknowledges (DCH allocation/ upgrade/

downgrade/ HSPA allocation successfully completed), a new RRC
Measurement Control/TVM/Release is sent to the UE if maximum
possible UL bit rate is allocated. Procedures are same like in normal case
without anchoring.

HSPA (HS-DSCH/DCH/E-DCH) can be allocated over Iur if HSPA over

Iur feature is supported and activated. <not in ADA3.0/end>

[Link].4.3 DCH/HSPA deletion for NRT RAB in anchoring situation

No changes to implementation without anchoring. When inactivity <not in

ADA3.0/begin> (utilization in the HSPA case) <not in ADA3.0/end>
indications (UL and DL) expires indicating inactivity for both directions, Iur
resources are normally released. Normal TVM start are set to UE and L2.
If L2 resources are released (based on same principles than
implementation without anchoring), GTP (IUE/IUG) buffering is started, no
changes to current implementation due to anchoring.

If SRNS Relocation is not supported and resources of the last active RAB
is to be released, then RRC Connection Release with cause value
Directed Signalling Connection re-establishment (DSCR) is sent to the UE
(see /20/ Hard Handover and SRNC Relocation FD, see also special case
“only Cell_FACH state relocation supported”).

[Link].4.4 New measurements over Iur due to DCH scheduling or ISHO in anchoring

No new common or dedicated measurements are needed over Iur due to

anchoring functionality.

[Link].5 Radio Bearer Setup Failure

Following failure conditions may occur between the RNC and UE:

− The RNC may not receive a radio interface RRC: RADIO BEARER
SETUP COMPLETE message from the UE in which case the RRC
timer (T_RRC_Resp_DCH/CCH) will expire. In this case a RANAP:
RAB ASSIGNMENT RESPONSE/failure message is returned to the
CN and the RAB establishment procedure is terminated.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 120(447)
Basic Call
 Functionality description

− If the RRC: RADIO BEARER SETUP message instructs the mobile

station to behave the way it does not support (e.g. to use a frequency,
code or QoS that it is not capable of), then the mobile station shall
return a RRC: RADIO BEARER SETUP FAILURE message and the
mobile station shall remain on the current (old) configuration.

− If the RRC: RADIO BEARER SETUP message affects several radio

bearers, the UE may include the identifiers of the radio bearers which
the procedure would have been successful into the RRC: RADIO
BEARER FAILURE message. The RNC doesn’t use this information.

RNC CN

RANAP:RAB Assignment Request

Required bearer
not available

RANAP:Assignment Response(
cause)

CN may send a new RAB Assignment

Request to establish a new bearer or
Iu release Command to release all
reserved resources.

Figure 41: Radio Access Bearer establishment failure at RNC.

In the following figure is presented RAB failure at the UE when UE is

already in CELL_DCH state.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 121(447)
Basic Call
 Functionality description

UE BTS RNC CN1

Signalling link established, MM, and CC signalling...

RANAP: RAB ASSIGNMENT REQUEST

If reserved radio resources don’t support required

bearer, a new code is needed

Radio link reconfiguration procedure

User plane establishment

User plane establishment

RRC: RB SETUP

RRC: RB SETUP FAILURE

RANAP: RAB ASSIGNMENT RESPONSE (cause code)

RAB release procedure

Figure 42: RAB setup failure at UE (CELL_DCH state procedure).

Maintaining of old resources in unsuccessful cases

If the radio channel assignment fails then a RANAP: RAB ASSIGNMENT

RESPONSE/failure message will be returned to the CN, the RAB setup
procedure will terminate, and the associated references concerning the
old dedicated resource(s) are maintained until explicitly released by the
CN.

<RAN3376/begin>

If RAN3376 Accelerated CS RAB assignment procedure is used, RNC

sends RANAP:IU RELEASE REQUEST to CN instead of RANAP: RAB
ASSIGNMENT RESPONSE with failure cause.

<RAN3376/end>

RNC RLC Reset Protection During CS Call Setup

If RRC:RAB ASSIGNMENT RESPONSE or L2 acknowledgement from

UE is delayed for CS call setup, UE specific RRC entity has a functionality
to prevent RNC RLC reset detection triggeriring, see /18/.

Expiration of timer T-RRC_Resp_DCH/CCH

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 122(447)
Basic Call
 Functionality description

If timer T_RRC_Resp_DCH/CCH expires and no any RRC messages

received related to ongoing procedure, the RNC/RRC initiates releasing
of all radio resources reserved for concerning UE. The RANAP sends
RANAP: RAB ASSIGNMENT RESPONSE/FAILURE message to the CN
and the RNC waits for either RANAP: IU RELEASE COMMAND or a new
RANAP: RAB ASSIGNMENT REQUEST from CN..

<RAN3376/begin>

If RAN3376 re-establishment during RB Setup functionality is active, RNC

does local Cell FACH state transition:

- If L3 CFN Offset + 2 seconds passed and UE

specific RRC entity did not received L2
acknowledgement for RRC:RADIO BEARER
SETUP from L2 or RRC:RADIO BEARER SETUP
COMPLETE from UE

- When T_RRC_Resp_DCH/CCH expires

See /18/ for further details for RAN3376 (phase2) re-establishment during
RB Setup RRC State Transitions.

<RAN3376/end>

More information about RRC connection re-establishment can be found

[RRC State Transitions for Packet Data FD] document.

Failure due to transmission

If transmission path establishment fails in any interface, then all reserved

resources (for this RAB) are released, previous configuration is remained
and a RANAP: RAB ASSIGNMENT RESPONSE/FAILURE message is
returned to the CN

Failure due to part of soft HO branches

If some of soft HO branches fails (RL allocation or UP establishment), the

RAB establishment is aborted and also successfully established RLs and
UPs are returned to the same situation that they were before
reconfiguration.

Parts of RAB establishments fail

The RNC report to the CN in one RANAP: RAB ASSIGNMENT

RESPONSE message one or several RABs, which are successfully
established, successfully modified, released, failed to establish or modify
(failed to release only for SRNC relocation).

[Link].6 RT RAB Establishment

The main task of Session Management (SM) in PS side is establishment,

modification and release of PS sessions.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 123(447)
Basic Call
 Functionality description

When MS needs PS service it requests "PDP context activation" from the

SGSN (by "direct transfer" transparently via RNC) and if SGSN accepts the
activation it then starts Iu-PS resource and radio resource reservation by
sending "RAB assignment request" (by RANAP) to the RNC. This
procedure creates a GTP entity (GTP-tunnel on the Iu-PS) and also PDCP
and RLC entities (radio bearer, RB) into the RNC. One MS can have
several GTP-tunnels (and active PDP contexts) at the same time, but one
RAB can have only one GTP-tunnel.

From Iu-PS point of view the main thing the control plane procedures must
take care of is the management of GTP-tunnels over the Iu-PS i.e. to
create, modify, and delete GTP-tunnels between RNC and SGSN. RANAP
on top of SCCP is used in Iu control plane.

PDP context activation is practically a PS session establishment

procedure. The most relevant Iu-PS level additional info in creating (and
modifying) GTP-tunnels are UL/DL IP addresses and UL/DL TEIs and
negotiated QoS (Quality of Service) parameters.

[Link].7 Radio Bearer Setup Complete

After the mobile station has executed required setup/reconfiguration

procedures for the DCH(s) and physical channel(s), it sends a RRC:
RADIO BEARER SETUP COMPLETE message to the RAN by
reconfigured radio link.

The UE returns the RRC: RADIO BEARER SETUP COMPLETE message

to the SRNC over the dedicated control channel (DCCH).

[Link].8 Radio Bearer Release

RT – RB is released in Cell_DCH state by using the RRC: Radio Bearer

Release procedure and Cell_DCH to Cell_FACH transition is executed by
using the RRC: Radio Bearer Reconfiguration procedure when the UE has
acknowledged the RB Release procedure.

The UE responds by sending an RRC: RADIO BEARER RELEASE

COMPLETE message to the RRC entity. It also releases dedicated
resources and moves from Cell_DCH state to Cell_FACH state.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 124(447)
Basic Call
 Functionality description

UE BTS RNC CN

RANAP: RAB ASSIGNMENT REQUEST(Release)

RANAP: RAB ASSIGNMENT RESPONSE

User Plane release

RL Reconfiguration

RRC: RB RELEASE

RRC: RB RELEASE COMPLETE

User Plane release

Figure 43: Radio Bearer Release

Interoperability problem with PS CN during RAB release

If the PS CN starts the PS-RAB release on its userplane before

requesting PS-RAB release from RNC, it leads to a situation that RNC
may detect the user plane release by reception of GTP level Error
Indication message, before it receives the PS-RAB release from PS CN.
Based on received GTP level Error Indication messages from PS CN
RNC unnecessarily initiates PS-RAB release request (RANAP: RAB
RELEASE REQUEST message) towards PS CN even though the PS
RAB release actually was caused by PS CN. This causes negative KPI
effect on RNC, since counters M1001C185 (PS drop due IU) and
M1022C68 (PS drop due Other) are updated.

To overcome this situation RNC has a timer, which tells how long time
GTP level Error Indication messages from PS CN are ignored, before PS-
RAB release request is initiated towards PS CN. This PS RAB Release
Guard Timer is defined by PRFILE parameter (002:2099
RU40_MAINT_03). Default value zero means that guard timer of 1s is
used.

[Link].9 Radio Bearer Release Complete

The RRC entity receives RRC: RADIO BEARER RELEASE COMPLETE

message and it forwards this switching information to the PS and also to
the MAC-d entity.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 125(447)
Basic Call
 Functionality description

[Link] UE Capability Procedures

[Link].1 UE Capability Enquiry

The UE capability enquiry procedure allows the UTRAN to request the UE

to transmit capability information related to any radio access network that
is supported by the UE. Capability information may be enquired e.g. in
case of inter-RAT handover from GSM to UTRAN, see [8]. The RRC: UE
CAPABILITY ENQUIRY message is sent on the DCCH using AM RLC.

UE radio access capability for FDD and Inter-RAT UE radio access

capability are required in the RRC: UE CAPABILITY ENQUIRY message.

If the RNC receives no response from the UE to RRC: UE CAPABILITY

ENQUIRY message within T_RRC_Resp_DCH [17], the RNC shall initiate
releasing of all radio resources reserved for concerning UE and the RNC
waits for RRC connection re-establishment, see [18].

UE BTS RNC

RRC: UE CAPABILITY ENQUIRY

RRC: UE CAPABILITY INFORMATION

RRC: UE CAPABILITY INFORMATION CONFIRM

Figure 44 UE capability enquiry

[Link].2 UE Capability Update

The UE capability update procedure allows the mobile station to indicate

to the network capability information upon request or when a change of
capability information has occurred while in connected mode (e.g. due to
addition of power amplification). The message may be sent on the DCH
or on the RACH.

When the RNC receives RRC: UE CAPABILITY INFORMATION

message on the uplink DCCH using AM RLC, it forwards the information
to the right entities inside the RNC (see [14]), and responds with RRC: UE
CAPABILITY INFORMATION CONFIRM message on the downlink DCCH
using AM RLC.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 126(447)
Basic Call
 Functionality description

UE BTS RNC

RRC: UE CAPABILITY INFORMATION

RRC: UE CAPABILITY INFORMATION CONFIRM

Figure 45: UE capability update

< NA05894654/begin>

[Link] Activation time increase

When activation time (CFN) is used in NBAP and RRC messages, the UE
specific RRC checks the RLC transmission buffer. If there are unsent
PDUs in the buffer, the UE specific RRC increases the calculated
activation time by adding the amount of transmission buffer size * 40 ms
(SRB TTI) to activation time.

< NA05894654/end>

<RAN3293/begin>

Note: RAN3293 does not use optimized activation time offset if there are
more than one unsent PDU in the RLC transmission buffer. Instead the
UE specific RRC increases the calculated unoptimized activation time
legacy way to set the ATO as described above. See chapter [Link]
Optimization of Activation time offset according to radio signal quality.

<RAN3293/end>

2.3 Feature Functionality

2.3.1 Cell level Management for AMR mode sets

A cell level management parameter is introduced to enable operator to

configure different AMR mode sets. If the AMR mode set of the RANAP
resource request message does not conform to any of the configured
AMR mode sets, then the resource request is rejected. Configured AMR
mode sets are applied in the resource allocation for the RAB assignment
request and for the SRNS relocation involved UE in the target RNC. If the
SRNS relocation is UE not involved and any configured AMR mode set is
not possible to use or if the resource request is received in DRNC, the
AMR mode set of the resource request is used as such.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 127(447)
Basic Call
 Functionality description

2.3.2 Narrowband AMR Code Set (12.2, 7.95, 5.90, 4.75) (5.90, 4.75) and
Narrowband AMR Codec Set for 2G-3G (12.2, 7.4, 5.90, 4.75)

The feature AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75)
allows three configured mode sets (12.2), (12.2, 7.95, 5.90, 4.75) and
(5.90, 4.75) to be used for the CS narrow band AMR calls.
<RAN2578/begin> Additionally the feature RAN2578 allows AMR Codec
Set (12.2, 7.4, 5.90, 4.75) to be used for CS narrow band AMR calls. The
feature is controlled through license key.<RAN2578/end> The
management parameter Configured CS AMR mode sets
(CSAMRModeSET) enables operator to define on cell basis, whether
RNC shall choose the AMR modes from one or two or all three of the
configured AMR sets. <RAN2578/begin>RAN2578 adds one more
alternative to AMR sets to be chosen. This set is added because it
enables better interworking with 2G as 7.95 is not in use in 2G but 7.4 is.
CSAMRModeSET is modified so that operator can also configure AMR
Codec Set (12.2, 7.4, 5.90, 4.75) as an option.<RAN2578/end>

The serving RNC allocates in terms of the number of AMR modes, the
largest of the configured AMR mode sets, which fulfills either of the two
conditions:

Modes of the configured AMR mode set are producing the lowest AMR
mode data rates of the resource request received from the MSC server,
or - if this type of configured set does not exist:

Modes of the configured AMR mode set belong to the AMR mode set of
the resource request received from the MSC server and the configured
set has the AMR mode with the highest data rate.

The former type of the configured AMR mode set enables the Maximum
Rate Control on Iu UP, It is applicable with both version 1 and version 2 of
the Iu UP support mode for predefined SDU sizes. The latter type of
configured mode set can be used only with version 1 of the Iu UP support
mode for predefined SDU sizes.

In Iu UP support mode, version 2 enables the Tandem Free Operation

(TFO) and Transcoder Free Operation (TrFO) of the AMR call. Value
‘OFF’ of the management parameter Period for CS AMR RRC TFC
control requests (PeriodULRCAMR) disables the use of the Iu UP support
mode version 2 in RNC In this case, only version 1 is applicable.

If the AMR mode set of the CS-CN resource request does not conform to
any of the configured AMR mode sets, the resource request is rejected.

Equal configured AMR mode sets are used in the UL and DL transfer
directions.

Configured AMR mode sets are applied in the SRNC when the resource
request is for CS AMR RAB assignment and in the target RNC when the
resource request is for SRNS relocation involving UE or inter-RAT hard
handover.

Configured AMR mode sets are not applied if the resource request is
received in DRNC from SRNC; the AMR mode set of the Iur radio link

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 128(447)
Basic Call
 Functionality description

request will be used instead. The target RNC of the SRNS relocation (not
involving the UE) attempts to allocate the configured mode set so that the
AMR modes of the Iur radio link create the lowest modes of the
configured set. If it does not succeed, then the existing AMR modes of the
radio link are used. Therefore, the feature will work properly only if all
RNCs of the RAN are configured with the equal AMR mode sets.

Methods in selection of the AMR codec set is described more accurately

in /8/.

In case there is a UE restriction in size of the transport format

combination set, the allocated configured mode set is reduced. This
allows the UE to continue using the lowest AMR code mode of the set,
unless there is an interactive or background service possible to reduce
instead. This may occur especially with the multi-RAB configurations. The
RNC will use Transport Channel Reconfiguration, Radio Bearer
Reconfiguration or Radio Bearer Setup messages for restricting the TFCS
towards the UE. In addition, towards Iu interface, the DL bit rate of AMR is
restricted with the Iu UP rate control procedure.

The AMR set (5.90, 4.75) enables one to increase the number of speech
users in the RNC. This can be perceived in the air uplink interface, Iub/Iur
transmission and downlink spreading code space.

GSM is able to utilize the multi-mode AMR in its AMR mode based link
adaptation, if the call is a UMTS-GSM call.

The UE can also restrict its maximum AMR bit rate if its transmission
power is approaching the maximum value. If the UE supports this
functionality, this feature will increase the UL coverage of the cell.

This feature can be switched OFF on cell basis in the RNC with the
management parameter Configured CS AMR mode sets
(CSAMRModeSET). If it is OFF, only single mode AMR 12.2 will be used
for the CS speech calls.

<EFS CR#715/start>If a new narrow band AMR RAB assignment is

received from MSS for the modification of the AMR call in progress then
RNC selects the codec set with the same method as in the first
assignment. This means in practice that MSS can modify between the
codec sets (12.2, 7.95, 5.90, 4.75),<RAN2578/begin>(12.2,7.4,5.90,4.75)
<RAN2578/end> and (12.2). MSS can also change the codec type by
sending the new NAS Synchronization Indicator value for it. <EFS
CR#715/end><RAN2578/begin>With support for AMR codec set
(12.2,7.4,5.90,4.75) there are additional possible AMR reconfigurations
which can be triggered by MSS. These reconfigurations are specified in
/8/ Admission Control FD.<RAN2578/end>

2.3.3 Wideband AMR Codec Set (12.65, 8.85, 6.6) (WBAMRCS)

Wideband AMR (WB-AMR) codec modes 12.65, 8.85 and 6.6 kbps are
supported by this feature. WB-AMR provides better speech quality than
narrowband AMR (NB-AMR) and fixed lines (G.711 PCM). Thus the
quality improvement can be met with WB-AMR - WB-AMR call. The RNC
handles the WB-AMR modes similarly to NB-AMR. The codec modes

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 129(447)
Basic Call
 Functionality description

12.65, 8.85 and 6.6 kbps form a set of bit rates (TFS) that is assigned to
every WB-AMR call. The limited TFCS in multi RAB cases, the
functionality of TFO/TrFO and managing the Iu Support Mode are similar
to the features AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75)
<RAN2578/begin> and AMR Codec Set for 2G-3G (12.2, 7.4, 5.90, 4.75)
<RAN2578/end>. Due to call hold functionality in CN the RAB
Reconfiguration procedures on Iu-CS interface is supported. A new call
after placing the WB-AMR call on hold can be a NB-AMR call. That would
lead to the NB-AMR - WB-AMR configuration that may be unwanted by
the CN. The reconfiguration happens between WB-AMR and NB-AMR
and vice versa (RAB reconfiguration is needed for supporting CN). This
reconfiguration is always CN initiated.

A management parameter is used to enable wideband AMR codec set on

cell basis. If the wideband AMR mode set of the RANAP resource request
message does not conform to the configured wideband AMR codec set,
then the resource request is rejected.

Feature supports wideband AMR modes from circuit switched core

network only, packet switched AMR RABs are not included. Configured
wideband AMR codec set is applied in the resource allocation for the RAB
assignment request and for the SRNS relocation with involving UE in the
target RNC. Same method is applied also for the for the SRNS relocation
without involving UE, but if the attempt fails, the AMR codec set of the
relocation request is used in establishing the AMR RAB. If the resource
request is received in DRNC, the AMR mode set of the resource request
is used as such.

The new codec modes can be used with TFO/TrFO as well, when the Iu
UP support mode version 2 is used.

The feature can be switched on and off on RNC basis. If it is off, three
configured AMR mode sets in maximum: {12.2, 7.95, 5.90, 4.75}, {5.9,
4.75} and {12.2} can be used as described in previous chapters (AMR
Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75) and SUPPORT FOR
TFO/TRFO).

2.3.4 Wideband and Narrowband AMR RAB Modification

W-AMR to N-AMR modification

CN initiates the W-AMR to N-AMR modification by sending a RANAP:

RAB ASSIGNMENT REQUEST message to the SRNC with N-AMR RAB
parameters (see AC SFS [8]). The RRM [30] analyses these parameters,
ask for reconfigure radio link [7] (over Iub and Iur, if needed).

Because both N-AMR and W-AMR use the same set of co-ordinate DCHs
(three DCHs), the existing co-ordinated set of DCHs can be modified.
NBAP/RNSAP RADIO LINK RECONFIGURATION PREPARE contains
N-AMR DCH parameters ( and AC FDS [8]). The old DCH identities are
used. Number of radio bearers does not change during N-AMR <-> W-
AMR modifications, so radio bearer reconfiguration message is used
towards the UE.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 130(447)
Basic Call
 Functionality description

The RRC constructs and sends message RRC: RADIO BEARER

RECONFIGURATION to the MS on used transport channel (DCH) using
AM RLC. The RRC starts implementation timer T_RRC_Resp_DCH.
Existing three TrCHs for W-AMR are modified for N-AMR (see AC FD [8]).
The old TrCH-id’s are used.

If MSC sent a NAS Synchronization Indicator in the RAB Assignment

Request/modify message, this Indicator must be sent to the UE in the
same RRC: RADIO BEARER RECONFIGURATION message.

<not in ADA3.0/begin> Note: The same DSP resource handles both W-

AMR and N-AMR calls. <not in ADA3.0/end>

<ADA3.0/begin> Note: The entire Adapter software runs in a single

Cavium Octeon CN5640 processor. <ADA3.0/end>

UE BTS RNC MSC

W-AMR call

Direct Transfers, RAB modification from W-AMR to N-AMR

RAB ASSIGNMENT REQUEST

Existing three WB-

AMR DCHs
modified for NB-
AMR

RADIO LINK RECONFIGURATION PREPARE

RADIO LINK RECONFIGURATION READY

New AAL2 connections towards MSC/MGW/BTS/RNC if required in the TRM SFS

RADIO LINK RECONFIGURATION COMMIT

Three RBs and TrCHs

modified for NB-AMR.
“NAS Synchronisation
Indicator” sent to the UE, if
received from MSC.

RADIO BEARER RECONFIGURATION

RADIO BEARER RECONFIGURATION COMPLETE

RAB ASSIGNMENT RESPONSE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 131(447)
Basic Call
 Functionality description

Figure 46a, Modification from W-AMR to N-AMR

N-AMR to W-AMR modification

CN initiates the N-AMR to W-AMR modification by sending a

RANAP:RAB ASSIGNMENT REQUEST message to the SRNC with W-
AMR RAB parameters (see AC FD [8]). First the W-AMR support
(configuration parameter, see AC FD [8]) is checked. If W-AMR is not
configured into use, the RAB modification is rejected with the RANAP
cause value “RNC unable to establish all RFCs”. The SRNC/RRM [8]
analyses received parameters, ask for reconfigure radio link [7] (over Iub
and Iur, if needed).

Because both N-AMR and W-AMR use the same set of co-coordinated
DCHs (three DCHs), the existing co-ordinated set of DCHs can be
modified. NBAP/RNSAP: RADIO LINK RECONFIGURATION PREPARE
contains W-AMR DCH parameters (see 6 and7] and AC FD [8]). The old
DCH identities are used.

Number of radio bearers doesn’t change during N-AMR <-> W-AMR

modifications, so radio bearer reconfiguration message is used towards
the UE.

The RRC constructs and sends RRC: RADIO BEARER

RECONFIGURATION message to the MS on used transport channel
(DCH) using AM RLC. The RRC starts implementation timer
T_RRC_Resp_DCH. Existing three TrCHs for N-AMR are modified for W-
AMR (see AC FD [8]). The old TrCH-id’s are used.

If MSC sent a NAS Synchronization Indicator in the RAB Assignment

Request/modify message, this Indicator must be sent to the UE in the
Radio Bearer Reconfiguration message.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 132(447)
Basic Call
 Functionality description

UE BTS RNC MSC

N-AMR call

Direct Transfers, RAB modification from N-AMR to W-AMR

RAB ASSIGNMENT REQUEST

Existing three NB-

AMR DCHs
modified for WB-
AMR

RADIO LINK RECONFIGURATION PREPARE

RADIO LINK RECONFIGURATION READY

New AAL2 connections towards MSC/MGW/BTS/RNC if required in the TRM SFS

RADIO LINK RECONFIGURATION COMMIT

Three RBs and TrCHs modified for

WB-AMR.
“NAS Synchronisation Indicator” sent
to the UE, if received from MSC.

RADIO BEARER RECONFIGURATION

RADIO BEARER RECONFIGURATION COMPLETE

RAB ASSIGNMENT RESPONSE

Figure 46b, Modification from N-AMR to W-AMR

2.3.5 Transport Channel Reconfiguration during DCH Allocation

The Handover Control entity can request the RRC entity to switch the DCH
resources to HSDPA/HSPA resources and execute the DCH=>HSDPA soft
pool-switching procedure e.g. for the following reasons, (more information
sees HSDPA RRM or HSUPA RRM SFS):
• Release of CS data RAB or PS RAB initiated while on DCH and
the current Cell and UE is HSDPA or HSPA capable.
• Serving Cell Change to HSDPA or HSPA capable cell, active
set updated with HSDPA or HSPA capable cell or other HO
reason triggered (e.g. IFHO/ISHO measurements did not cause
IFHO/ISHO) while on DCH and UE is also HSDPA or HSPA
capable.
In these cases the RRC entity shall first request the cell-specific PS to
switch the DCH/DCH allocation to the HS-DSCH/DCH or HS-DSCH/E-DCH

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 133(447)
Basic Call
 Functionality description

allocation. After this the IUG is requested to start buffering of DL data and
the dedicated RL resources are requested for HS-DSCH/DCH or HS-
DSCH/E-DCH allocation from BTS. After receiving the RL reconfiguration
ready from BTS the RRC entity requests the user plane L2 resource
creation to HSDPA-soft pool from transport resource manager (TRM).
Activation time which is received from TRM after successful L2 resource
creation and AAL2 connection establishment is included in NBAP:
RADIOLINK RECONFIGURATION COMMIT message is sent to the BTS
and RRC: RADIO BEARER RECONFIGURATION message is sent to the
UE. By activation time the new HS-DSCH/DCH or HS-DSCH/E-DCH
configuration is taken into the use in the Layer 2, BTS and UE
simultaneously.

After there is RRC: RADIO BEARER RECONFIGURATION COMPLETE

message received from the UE, TVM measurements are configured to or
released from the UE and cell-specific PS is informed about the successful
reconfiguration in order to release the old HSDPA or HSPA allocation. TRM
is requested to release the old AAL2 connection and DCH L2 resources
from DCH-soft pool. After that the IUG is requested to stop buffering of DL
data.

If congestion of resources (BTS, TRS or DMCU) is met, HSDPA/HSPA

allocation is canceled from BTS and from Cell specific PS. The RRC entity
configures, if needed, the TVM measurements to the UE and UE stays with
the current DCH x/x allocation.

If PDU size 656 is applicable according to requirement AC1.14 when

switching from DCH to HS-DSCH allocation, it is used instead of 336. MAC-
d PDU size is signaled to the UE and to the BTS (having the serving HS-
DSCH RL) during the reconfiguration. The affected RLC parameters have
to be updated to RNC and UE-RLC. Only one sided RLC re-establishment
(DL) is needed, see AC SFS.

2.3.6 Bit Rate Upgrade and Downgrade

DCH of NRT RB can be released when more capacity needs to be

allocated for an RT RB. Increase of the used bit rate of radio bearer (DCH
upgrade) is needed, for example, when a DCH allocated for a minimum
bit rate is not sufficient for downlink/uplink data to be transferred.

DCH modification or release is done with an RRC: Radio Bearer

Reconfiguration procedure. This is explaining in detail in following.

• DCH bit rate upgrade request when

• lower or equal than initial bit rate DCH is allocated or

• If FlexUpgrUsage parameter is set “On” and if allocated DCH bit

rate is lower than maximum bit rate of the RB.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 134(447)
Basic Call
 Functionality description

2.3.7 Transport Format Combination Control

Transport Format
Combination
DCH DCH

TFC 3

Transport Transport Format

Format C
A
Transport
Format Set
TFC 2
(TFS) Transport Format
Combination Set
(TFCS)

TFC 1

Transport Transport
Format Format
B D
TFC 0

Figure 47: Transport Format Combination Control

The transport format combination control procedure is used to control the

allowed uplink transport format combinations within the transport format
combination set (TFCS). Procedure can be used when PS has detected the
overload situation in uplink or rate control message is received from
MGW/MSC see figure 50.

The original TFCS is taken into use by using the same procedure, when
the overload situation is over.

Sending of Transport Format Combination Control Message (RNC)

When the RRM detects the overload situation on uplink, it can request RRC
entity of RNC to start transport format combination control procedure. The
RRC entity transmits the RRC: TRANSPORT FORMAT COMBINATION
CONTROL message to the UE.

Restrictions for initiating Transport Format Combination Control

procedure (RNC)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 135(447)
Basic Call
 Functionality description

The RRC entity is not allowed to initiate a transport format combination

control procedure, while awaiting the completion of the following
procedures:
• Radio bearer establishment
• Radio bearer release
• Radio bearer reconfiguration
• Transport channel reconfiguration
• Physical channel reconfiguration

To change the sub-set of allowed transport format combinations, the RRM

set the allowed TFCs in the IE "TFC subset".

UE BTS RNC

RRM detects overload

RRC: TRANPORT FORMAT COMBINATION CONTROL

Figure 48: Transport Format Combination Control

To completely remove the previous restrictions of allowed transport format

combinations, the RRM sets the "full transport format combination" in the
IE "TFC subset" and requests the RRC entity to start the Transport Format
Combination Control procedure.

The RRC entity transmits the RRC: TRANSPORT FORMAT

COMBINATION CONTROL message to MS.

Receiving of Transport Format Combination Control Failure message

(RNC)

If the UE does not accept the requested changes it transmits a RRC:

TRANSPORT FORMAT COMBINATION CONTROL FAILURE message
on the DCCH using AM RLC. RRC entity receives this message and
forwards it to the PS.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 136(447)
Basic Call
 Functionality description

UE BTS RNC

RRM detects overload

RRC: TRANPORT FORMAT COMBINATION CONTROL

RRC: TRANSPORT FORMATI COMBINATION CONTROL FAILURE

Figure 49: Transport Format Combination Control Failure

2.3.8 Emergency Call Redirection to GSM

In call setup, when RNC receives RRC: Connection Request from UE

with establishment cause: Emergency call and emergency call redirect
feature is activated, call setup proceeds normally until it RRC asks RNTI
from RC3. RC3 checks from its internal data structure, if it has already
received an emergency call request for the particular initial_UE_id during
the EmergencyCallRedirectTimerRNC. If UE has not made an emergency
call within the time limit, RC3 marks in the internal data structure that it
has received an emergency call for a particular initial_UE_id and informs
that this the emergency call attempt shall be redirected to GSM network
by sending rc3_rnti_request_nack_s with a cause value as
emerg_redirect_c, after this RRC in RNC rejects the connection request
instructing the UE to make an inter-system handover to GSM network and
to proceed in there. If UE has made an emergency call within the time
limit, the RRC connection creation shall proceed as normal emergency
call setup and RC3 shall allocate RNTI for UE and call is setup in
WCDMA NW

2.3.9 Transcoder and Tandem Free Operation (TrFO and TFO)

The Transcoder Free Operation and Tandem Free Operation (shortly

called as TrFO and TFO) are included in 3GPP specifications from Rel-4
onwards [1, 2]. The TrFO/TFO affects the RNC, CS-CN and MGW
network elements. The idea in TrFO is that the transcoding, which is done
in Rel-99 networks in CS-CN, can be avoided when the CN negotiates
Out-of-Band (OoB) the common set of AMR codec modes that are
supported by the both end UEs. When the UEs support the same codecs,
there is no need for transcoding in the CN and therefore the speech
quality is increased.

Although the main reason for avoiding transcoding in mobile-to-mobile

calls has been speech quality, the transmission of compressed
information in the CN, and CN-CN interface of the cellular network also
offers the of bandwidth savings.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 137(447)
Basic Call
 Functionality description

The difference between the TrFO and TFO is that in TrFO the transcoder
is not used in the CN, but in TFO transcoder is used. Also the bandwidth
savings are only achieved with TrFO.

[Link] RAB Assignment procedure

The RAB Assignment Request [4] contains version 2 of the Iu User Plane
as one alternative to enable TrFO functionality in RNC. The RAB
Assignment also contains the AMR codec modes that are negotiated Out-
of-Band by the CN, and supported by the UEs, and are therefore to be
initialized in the User Plane.

The figure 49 illustrates the RAB Assignment procedure.

RNC MSC MGW

1) RANAP: RAB Assignment Request

2) AAL2 Setup (CS RAB)

3) IuUP: INITIALISATION

4) IuUP: INITIALISATION ACK

5) RFCI Value Correction

6) RANAP: RAB Assignment Response

Figure 51: RAB Assignment procedure

1) RNC receives RAB Assignment Request from the CS-CN. The

message contains:

a. All the AMR codec modes that are negotiated Out-of-Band in

the CN. .

b. The IuUP mode versions that are allowed for the Iu User
Plane. In case of TrFO, the version 2 shall be included.

2) RNC Establishes the Transport Bearer for the CS RAB

3) RNC sends IuUP: INITIALISATION control frame to the MGW. The

message contains:

a. The RFCI values for all the AMR codec modes that were
received in RAB Assignment Request

b. All the IuUP mode versions that RNC supports, and proposes
to the used among the mode versions that were included into
RAB Assignment Request

4) MGW sends IuUP: INITIALISATION ACK control frame to the RNC.

The message contains:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 138(447)
Basic Call
 Functionality description

a. The selected IuUP mode version. In case of TrFO, the IuUP

mode version is 2.

5) Depending on the MGW implementation, MGW may initiate the RFCI

Value Correction procedure to change the RFCI values, which were
initially allocated by the RNC. Note, that RNC can receive RFCI Value
Correction also after step 6.

6) After successful IuUP initialization, the RNC sends RAB Assignment

Response to CS-CN.

For more information about Iub and Uu procedures: Radio access bearer
establishment procedure (DSC to DCH).

All subflow combination provided in RAB assignment shall be

initialized for TrFO support

For optimizing a successful TrFO/TFO speech connection, all the Subflow

Combinations determined in the RAB assignment shall be initialized by
the AC/IU-up. Otherwise, if RNC denies this, RAB assignment is rejected
with cause code “RNC unable to establish all RFCs”.

[Link] SRNS Relocation Procedures

The parameters received in RAB Assignment procedure are transferred

from Source RNC to Target RNC in Relocation Procedures [4]. During the
relocation the IuUP will be created in Target RNC in the similar manner as
during the RAB Assignment procedure in Source RNC.

[Link] IuUP Initialization Procedure

When TrFO is supported, the RNC initiates the IuUP with all the codecs
that were included in the RANAP: RAB Assignment Request message.
When CN includes version 1 and 2 in the RAB Assignment, the RNC
allocates the codec modes and if version 2 is enabled by parameter
PeriodULRCAMR , the RNC includes both versions as a preferred
versions in the IuUP Initialization [3]. Therefore RNC delegates the final
decision of the used IuUP version for the MGW. If the RAB Assignment
contains only version 2, the RNC includes only IuUP version 2 as one
preferred version, if TrFO feature is supported.

The IuUP initialization contains also information about the maximum

allowed DL rate. The RNC will use IuUP INITIALISATION frame version 1
(Iu UP Mode Version = 1) if that was included into RAB Assignment
procedure. Therefore the first RFCI contains information about the
maximum allowed DL rate in the first frame only and after that all the rates
are allowed again. On the other hand, if RAB Assignment procedure
contains only Iu UP Mode Version 2, then RNC will use IuUP
INITIALISATION frame version 2. In that case the first RFCI contains
information about the maximum allowed DL rate, which is valid until RNC
sends a Rate Control procedure.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 139(447)
Basic Call
 Functionality description

[Link] RFCI Value Correction

The RNC allocates and stores the RFCI values for each codec and the
same values are included into the IuUP INITIALISATION control frame,
which is sent to MGW. When the other end, e.g. RNC, allocates RFCI
values independently of the first RNC, the allocated RFCI values are likely
different in each end. Therefore the MGW, which is in the middle, can
distinguish the different values and start the RFCI Value Correction
procedure [1] towards the other end, which will replace earlier allocated
RFCI values with new ones.

The RFCI Value Correction is an IuUP INITIALISATION procedure, which

is initiated by the MGW, and therefore the RNC supports the incoming
IuUP INITIALISATION procedure. It is also possible, that when MGW
determines that RFCI values are different, the MGW doesn’t start RFCI
Value Correction. In that case the RNC doesn’t receive the incoming IuUP
INITIALISATION procedure, and MGW will change continuously the RFCI
values in user data frames so that they are valid for each RNC

[Link] Maximum Rate Control Procedure

The RNC controls the UL and DL maximum rate in its cells, and IuUP
Rate Control procedure is used by RNC, when RNC detects that the
maximum allowed DL rate has to be changed, for example in case if the
AMR modes set shall be reduced for UE capability reasons in multiservice
configuration. When RNC sends the IuUP Rate Control frame to the
MGW, the TrFO operation is preferred and therefore MGW does not start
the transcoding, the MGW forwards the message, which finally reaches
the other end. Therefore to support the TrFO, the RNC supports the
incoming IuUP Rate Control frames as well. When the RNC receives
IuUP Rate Control, the RNC will forward immediately that information to
the UE if RNC doesn’t detect overload and no other RRC procedures are
ongoing.

[Link] Additions to support speech codecs for codec matching

Tandem Free Operation has to be possible between 3G<->2G/3G,

meaning that in order to minimize codec mismatch in 3G<->2G calls, the
following speech codecs (TF’s, TFS’s) are admitted by AC.

Multi rates:

UMTS AMR, UMTS_AMR_2 and WB-AMR is possible with TrFO

[Link] Filtering of Frequent IuUP Rate Control Frames

In some certain cases (e.g. in GSM link adaptation), the Rate Control
frames are received frequently. This situation is called as Frequent Rate
Control, and needs special functionality if the overload control of RNC
detects high signaling load. The functionality in RNC is called as ‘Filtering’
and is activated by the PeriodULRCAMR - Management Parameter.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 140(447)
Basic Call
 Functionality description

Parameter is employed in SRNC for the CS AMR call from the

establishment of the RAB in filtering off the UL rate control request
received from the Iu UP, if excessive signaling load is experienced in
RNC. When RNC should send the RRC Transport format combination
control message to UE as an action to the CS AMR UL rate control
request received on the Iu UP, then only the last maximum UL AMR
mode upgrade request received during the interval defined with the
parameter is transferred to the UE in DCCH using the AM RLC.

Every maximum UL AMR mode downgrade request is transferred to the

UE without filtering, unless there is another RRC procedure going on that
prohibits it.

In the Figure 52 is one example scenario of Filtering Frequent IuUP Rate

Control procedures.

UE RNC M GW

1) Rate Control

2) Filtering

3) Rate Control ACK

4) Rate Control

5) Filtering

6) RRC: TFCC

7) Rate Control ACK

Figure 52: Filtering Frequent IuUP Rate Control procedures

1) RNC receives Rate Control frame from MGW

2) RNC detects signaling overload and Rate Control request was to

increase Maximum UL rate

3) RNC doesn’t send increased Maximum UL rate information to UE and

send Rate Control ACK frame to MGW

4) RNC receives new frequent Rate Control frame before the time
defined by PeriodULRCAMR parameter has elapsed

5) RNC filters the Rate Control and this time Rate Control frame was to
reduce Maximum rate or time defined PeriodULRCAMR parameter
elapses

6) RNC sends RRC: TRANSPORT FORMAT CONTROL COMMAND to

UE to reduce Maximum rate

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 141(447)
Basic Call
 Functionality description

7) RNC sends Rate Control ACK frame to MGW

[Link] Immediate Rate Control

The maximum UL rate information is not delivered in the SRNS

Relocation procedures (in RANAP), and therefore is gathered by
Immediate Rate Control [11], which also gives possibility for the Target
RNC to inform its maximum DL rate to the other end. The Immediate Rate
Control is done after the SRNS Relocation and IuUP INITIALISATION,
and is triggered when the Target RNC receives relocation execution
trigger from the UE or from the Iur interface [6]. If the type of relocation of
SRNS is "UE not involved in relocation of SRNS", the relocation execution
trigger is the RNSAP: RELOCATION COMMIT message from the Source
RNC, otherwise the relocation execution trigger is the received RRC
message from UE, or established L1synchronisation between BTS and
UE.

[Link] Handling of Rate Control Commands for AMR Uplink

For TrFO/TFO, IU user plane’s rate control procedure orders RRC to

change UE’s AMR mode to uplink.

RRC: TRANSPORT FORMAT COMBINATION CONTOL (TFCC)

message is used for ordering the UE to use certain AMR mode for uplink
DCH.

RRC uses common TFCC-Um.

Note: Due to pronto “PR NA05451586: Customer Complain for mute and
drop call in mcRNC” a following improvement is done:

The UE specific RRM in the RNC does not initiate TFCC messages
before L3 has indicated that CC level CONNECT ACK message is
transferred or uplink activity for the AMR is detected by UP.

<internal/begin>

Summary of the original problem: Activation of Load Based AMR Codec

Selection may result to mute calls with particular UE models if the TrFO
function is activated at the same time in the network. Muting can occur
when the call is downgraded from codec set (12.2, 7.95, 5.9, 4.75) to
codec set (5.9, 4.75) at the RAB assignment phase.

Description of the fault: Problem is in the timing of the RRC TFCC control
messages. At least some UEs are not able to change from the mode 12.2
to the mode 5.9 if the UE receives the TFCC message before the audio
codec is connected. In MTC call cases UE connects the audio codec at
the moment MOC subscriber answers. It is the moment when the NAS
signal CONNECT is observed. Therefore, in the correction of the problem,
the AMR modification is delayed until the RRC of RNC (MOC or MTC)
discovers the NAS CONNECT ACK message.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 142(447)
Basic Call
 Functionality description

Description of the correction: The UE specific RRM in the RNC does not
initiate TFCC messages before L3 has indicated that CC level CONNECT
ACK message is transferred or uplink activity for the AMR is detected by
UP. Load control in the RNC does not start Load Based AMR downgrade
before CONNECT ACK message is transferred.

<internal/end>

2.3.10 HSDPA Feature Functionality

[Link] Introduction

HSDPA is a scheme that supports a very high capacity shared data

channel in the downlink direction. It encompasses three new channel
types: two control channels and one data channel. In addition, it employs
a new frame structure, a new fast retransmission scheme, and a new
adaptive modulation scheme. Following figure depicts the user plane
protocol architecture for HSDPA

Figure 53: Protocol Architechure for HSDPA

The shared HSDPA data channel (HS-PDSCH) is an upgrade of the

Release 99 - specified Downlink Shared Channel (DSCH). HS-PDSCH is
a shared channel; it is shared between all active HSDPA users in the cell.
This channel is shared in two dimensions: it is both time and code
multiplexed (see Figure below). Each standard 10 ms frame is divided into
2 ms sub-frames in HSDPA. Timeslots are still the same length as in
Release 99; that is 0.67 ms. Thus there are 3 timeslots within one HSDPA
sub-frame. The transmission resources can be re-allocated in each sub-
frame, so the HS-PDSCH is time multiplexed. Furthermore each sub-frame
can further be shared up to 16 users simultaneously because each active
user is allocated at least one spreading code of SF=16.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 143(447)
Basic Call
 Functionality description

Figure 54: Sub-frames structure of HS-PDSCH

In addition to HS-PDSCH, an HSDPA UE will also need new control

channels to support this function. The High Speed Shared Control Channel
(HS-SCCH) is a downlink control channel that gives the UE the fast
changing parameters that are needed for HS-PDSCH reception, and
indicates when there is data on the HS-PDSCH that is addressed to this
UE. In the uplink direction, there is the High Speed Dedicated Physical
Control Channel (HS-DPCCH) that is a low bandwidth channel for sending
back data packet acknowledgements and channel quality information.

[Link] HSDPA Enhancements

HSDPA is a combination of several techniques which all contribute to the

enhanced capabilities of the downlink channel. A Release 5 HSDPA
capable handset will include both Hybrid ARQ (HARQ) and Adaptive
Modulation and Coding (AMC) functionality. Release 6 will further enhance
HSDPA capabilities by introducing Multiple Input Multiple Output (MIMO)
antenna techniques.

HARQ is a link adaptation scheme in which link layer acknowledgements

are used for retransmission decisions in the UTRAN. In Release 99
retransmission functionality is part of the RLC layer. However, this kind of
high-level retransmission scheme is too slow for the high-speed data
transmissions envisaged for HSDPA. With HSDPA the HARQ
retransmission buffers are located closer to the physical layer, specifically
within the new MAC-hs logical entity that is just above the physical layer.

Adaptive Modulation and Coding (or Link Adaptation) means that the
shared channel transport format (i.e., the modulation scheme and the code
rate) depends on the channel quality. This is monitored constantly, and the
transport format used can be dynamically changed in every frame. The
quality information is transmitted to the Node-Bs via the uplink control
channels

3GPP Rel-7 introduces HSDPA 64QAM modulation.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 144(447)
Basic Call
 Functionality description

[Link] HSDPA Transport and Physical Channels

HSDPA involves the interworking of three physical channels: HS-PDSCH,

HS-SCCH, and HS-DPCCH. HS-PDSCH and HS-SCCH are shared
downlink channels, whereas HS-DPCCH is a dedicated uplink channel

The timing of these channels is shown in Figure below. Note that the HS-
SCCH frame and the corresponding HS-PDSCH frame are overlapping by
one timeslot. This is because the UE has to first receive and decode the
HS-SCCH frame before it knows whether the corresponding HS-PDSCH
is addressed to it. The UE identity can be resolved after reception of the
first HS-SCCH timeslot. The data in the said timeslot is masked using a bit
string that is derived from the UE identity. Only the correct UE identity can
decode this timeslot. The first timeslot also indicates the spreading code(s)
used, and the modulation scheme employed, so that the UE can start
receiving the HS-PDSCH if necessary. There is a gap of one timeslot
(0.667 ms) between the end of the first timeslot of the HS-SCCH frame,
and the start of the HS-PDSCH frame

Figure 54: Time-slots for HS-SCCH/HS-PDSCH/HS-PDCCH

<RAN3220/begin>

[Link] QoS PS streaming class RABs on HSPA

<Internal/begin>
Note that RAN1004 Streaming QoS for HSPA feature is frozen. No new
implementation is made for it and it is not needed to be taken into account when
considering feature interworking issues.
<Internal/end>

This feature enables introduction of streaming services with guaranteed

bit rate requirements on HSPA and therefore makes increased revenue
possible thanks to the service differentiation.

This feature brings the support of streaming QoS traffic class RABs on
HSPA.

Streaming class RAB is originated from PS core network. RAN supports

streaming RAB and creates corresponding RB. This feature enables
streaming traffic class radio bearer mapping on DCH/HS-DSCH and E-

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 145(447)
Basic Call
 Functionality description

DCH/HS-DSCH. Non-scheduled transmission (NST) is used in case of

streaming traffic class on E-DCH.

Streaming RABs are prioritized by the RNC. Prioritization is based on

Allocation Retention Priority (ARP) (and streaming traffic class) received
from the core network. The RNC uses this prioritization internally and
gives it to the BTS through Scheduling Priority Indicator (SPI) value.

Guaranteed bit rate (GBR) is supported for streaming traffic class in

HSPA. Admission of a new user can be denied if the guaranteed bit rate
cannot be provided to the user, or if the guaranteed QoS of existing users
would be affected. However, a new streaming user can take resources
from HSPA NRT or from DCH NRT users (RT-over-NRT). GBR is also
used by the scheduler in the BTS. On HS-DSCH PF-RAD scheduler firstly
fulfills the GBR requirements of real time users in the order of SPI.

Uplink direction of Streaming class RT RAB using GBR and mapped to E-

DCH is not congestion controlled in Iub, i.e HSUPA Congestion Control
feature is not applied to NST on E-DCH. Operator can also select if
downlink streaming bearer using RT RAB is HSDPA Congestion
Controlled or not.

This feature includes the multi-RAB support required by streaming traffic

class: 1 RT+ 1 NRT PS RAB. This combination is supported with and
without AMR.

Secondary PDP context is required for streaming traffic class, which need
to be supported also by UE.

This feature makes it also possible to have Nominal Bit Rate (NBR) for
NRT traffic classes. Nominal bit rate can be used as targeted minimum bit
rate, e.g. based on subscription. In the scheduler NBR has higher priority
than best effort but lower priority than GBR of real time users. Operator
can define NBR based on traffic class+THP+ARP. Nominal Bit Rate is
sent to the BTS by using GBR IE. Scheduled transmission (ST) is used in
case of NBR on E-DCH, as normally for NRT. <not in ADA3.0/begin>
Thus uplink direction of NBR traffic is congestion controlled in Iub
according to QoS aware HSUPA congestion control mechanism,
introduced in QoS Aware HSPA Scheduling feature. <not in
ADA3.0/begin>

Handling of state change related issue of this feature[ RAN1004

Streaming QoS for HSPA] is descriped in [ RRC state transitions for
packet data FD] document.

<RAN3220/end>

[Link] 14 Mbps Per User

Feature RAN1258 HSDPA 14 Mbit/s per user shall increase the peak rate
of a single user up to 14 Mbit/s. With this feature, a category 10 UE may
receive data with its maximum bit rate when 15 codes for HSDPA are
allocated in the cell.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 146(447)
Basic Call
 Functionality description

Uplink channel type shall be E-DCH in order to reach the peak rate of
14Mbit/s. UE specific packet scheduler, handover control and cell specific
packet schedulers select the uplink channel type between DCH and E-
DCH. If E-DCH is not possible, then the peak rate is not reached.

Number of available HS-PDSCH codes restricts number of HSDPA users

with peak rate 14 Mbit/s to only a few per cell. <not in ADA3.0/begin> This
feature requires cdsp-dh card <up to RN7.0/beginning>and is not
supported with cdsp-c card <up to RN7.0/end>. <not in ADA3.0/end>
The feature requires RAS06 feature HSDPA 15 codes (RAN852).

[Link] HSPA Multi NRT RABs

Feature: RAN285 HSPA Multi NRT RABs

This functionality enables allocation of up to three simultaneous NRT PS

RABs on HS-DSCH and E-DCH. This means that three simultaneous
PDP contexts can be utilize the HSPA service.

The RAB are multiplexed and demultiplexed in the MAC-hs and MAC-e
entities in the BTS and in the UE. There are separate priority queues for
each RAB in the MAC-hs and MAC-e entities. In DL, the BTS packet
schedules data to the UE from each non-empty queue in turns. In UL, UE
MAC-e multiplexes data from several priority queues into E-DCH. In case
HSUPA is not supported RABs can be mapped to DCH in UL as in
current implementation.

The RABs may be also priorised in the multiplexing based on their

Scheduling Priority Indicatior (SPI) value. The SPE is derived from the
RAB QoS parameters received from the core network. The mapping
between the SPI and RAB QoS parameters is carried out in the RNC
based on operator defined mapping rules.

The basic HSPA/NRT RAB functionalities don’t change due to multi NRT
HSPA RAB Feature.

MAC-d flow allocation from Cell_FACH state

In MAC-d fow allocation phase MAC-d flows are setup one by one. In DL
direction IUG/IUE indicates data for one RB in one message. MAC-d flow
(/DCH) is alloated for that RB. Second possible capacity request from
IUE/IUG is saved by RRC/MCC/CCM and handled after previous
procedure is performed (the same handling as for DCHs only, the newest
request per RB handled). UE can indicate data for many RBs in the
Measurement Report message, but MAC-d flow allocation is done only for
on RB as in current implementation for DCHs.

The MAC-d flow allocation for next RB is done after next capacity request
(from UE).

If there are capacity request received for many RBs during previous
procedure, the capacity is first allocated to the highest priority RB (priority
checking, see /8/ Admission Control FD).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 147(447)
Basic Call
 Functionality description

If UE indicates data for many RBs in the Measurement report /TVM

message, then MAC-d flow is allocated first for the highest priority RB.
RRC/MCC checks priorities based on SPI value (see QoS Aware HSPA
Scheduling EFS). If several RBs are with the same priority, then MAC-d
flow is allocated first in the RB which is the first in RB list in the
Measurement Report/TVM message.

Other (UP) RBs are mapped to DCH0/0 (no transport resources) as in the
current release, and measurement control messages (TVM) are sent as in
the current release.

MAC-d flow allocation from Cell_DCH state

UE and IUG/IUE indicates data RB specificly. In MAC-d flow allocation

phase MAC-d flows are setup one by one. The MAC-d flow allocation for
next RB is done after next capacity request. If a new capacity request is
received from UE or IUG/IUE for other RB during previous capacity
allocation procedure, a new capacity request is saved and handled when
previous procedure is performed (see requirement RNC_EFS_285_122).
No changes to current implementation for DCH.

If resource allocation fails for NRT RB, then resource allocation is tried
again after new capacity request from IUG/IUE or UE.

MAC-d flow Release

Throughput, utilization and (in)activity measurements are RB specific.

When measurements indicates, that MAC-d flow (HS-DSCH/E-DCH, HS-
DSCH/DCH) should be released, then MAC-d flow is released, only one at
the time. RB is configured to RB 0/0 (DCH 0/0), HSPA/DCH is released
from BTS and IUE/IUG buffering is started. Transmission resources are
released.

Last MAC-d flow Release

If the MAC-d flow to be released is the last active MAC-d flow, and there
are no any RT services (with dedicated resources in case of PS
streaming), UE is moved to Cell_FACH state or directly to PCH state

Serving Cell Change

In Serving Cell Change (SCC) phase all resources from new cell are
reserved in one message from RRC to NRM and from BTS. The same
procedures are used as with one NRT HSPA RAB.

Serving Cell Change Failure

If resource reservation/release (NBAP:Radio Link Configuration

Preparation Failure) fails in source or target cell, reconfiguration
procedure to other BTS is cancelled and procedure is end from L3 point of
view (reject to RRU). The same handling (cancel to BTSs) if NRM rejects
transmission setup towards new BTS. If SCC has to be performed, RRU

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 148(447)
Basic Call
 Functionality description

may ask to drop some MAC-d flow(s) to RB 0/0. From L3 point of view
these are normal resource releases without knowing the reason for
resource drop. When some resources are released, HA3 may start SCC
again. Capacity requests (from UE or IUE/IUG) for these dropped RBs are
not handled (ignored by RRM), if MAC-d flow is released due to failed
SCC and a new SCC is coming.

Inter RNC Cell Change (for NRT RABs)

Basic Inter RNC Cell Change functionality for NRT RABs is used for Multi
NRT HSPA RABs. HA3 triggers Inter RNC Cell Change.

Target RNC allocates resources on best effor basis, that is, even though
HSPA is primarily allocated, also DCH/DCH can be allocated when HSPA
is not available. Relocation Request is accepted if at least resources for
signalling radio bearers can be allocated. All (also active in source side)
NRT RABs can swithed to DCM 0/0, if no resources available. For further
information related to inter-RNC HSPA Cell change or normal HHO needs
different handling and could be referred to [20] document.

When RRC/MCC receives the Relocation request message, it checks

which NRT RABs are active (HSPA or DCH resources allocated in source
side) from RRC Container, and request resources from RRM (UER/BRM)
via RRC/CCM for all active RABs. RRM allocates resources according to
supported features and asks RRC/CCM to setup BTS and transmission
resources. If resource reservation fails, failure handling shall be applied as
described in /35/ HSDPA RRM in RNC FD (chapter Unsuccessful HSPA
resource reservation may cause special actions).

[Link] HSDPA 64QAM

Feature 1643 HSDPA 64 QAM increases the HSDPA peak rate up to

21.1 Mbps. HSDPA terminal categories 13, 14, 17 and 18 support 64QAM
modulation. Practical throughput is limited by radio interface condition
(such as signal strength and interference).

To achieve the maximum theoretical throughput of 21.1 Mbps of UE

categories 14 and 18, it would require the use of coding rate close to one,
i.e., it would require error free reception. Targeting to error free reception
reduces the system efficiency and capacity. In all practical conditions the
throughput will be degraded if coding rates close to one are applied, i.e.,
having effectively no error correction.

The quality of radio reception depends on aspects such as received

signal strength, radio channel and interference, transmitter and receiver
imperfections.

The link adaptation algorithm in the Node B selects 64 QAM when the
channel quality is sufficient and the UE is 64 QAM capable. 64 QAM is
optional feature for the UE, and the 64 QAM capability is signaled to RNC
in RRC connection setup.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 149(447)
Basic Call
 Functionality description

The RNC indicates to the UE the usage of 64 QAM in the RRC messages
via the Downlink HS-PDSCH Information IE. In order for the UE to be
eligible for 64 QAM usage, it must support MAC-ehs.

Messages on RRC in which the RNC indicates to the UE the usage of 64

QAM via the Downlink HS-PDSCH Information IE are [RRC]:

CELL UPDATE CONFIRM,

HANDOVER TO UTRAN COMMAND,

PHYSICAL CHANNEL RECONFIGURATION,

RADIO BEARER SETUP/RELEASE/ RECONFIGURATION, and

TRANSPORT CHANNEL RECONFIGURATION.

Depending on the environment and terminal receiver, 64 QAM can

provide from 3 to 15 % higher average HSDPA cell and user throughput.
Further, 64 QAM increases the revenue for the operators by providing
higher HSDPA peak rate for subscription differentiation.

[Link] HSDPA Flexible RLC

The main purpose of feature RAN 1638 Flexible RLC is to enable

achieving of the higher HSDPA peak rates provided by 64 QAM
modulation scheme. By applying flexible RLC PDU size in downlink,
protocol overhad and padding are reduced. Flexible RLC operation
reduces processing needs both in UE and RNC. The reduced RLC
overhead results from the facts that padding is not needed anymore to fill
out the fixed size RLC PDUs and payload size is increased, whereas the
header size remains the same. This feature does not need license.

F-RLC related NBAP and RNSAP procedures which have impacts by the
feature are described in /40/.

[Link].1 Impacts on RRC procedures

UE shall indicate support for flexible RLC via setting Support of MAC-ehs
IE to TRUE in RRC: RRC CONNECTION SETUP message.

RRC procedures which have impacts by the feature are:

• Cell Update

• Radio Bearer Reconfiguration

• Radio Bearer Setup

• RRC Connection Request

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 150(447)
Basic Call
 Functionality description

• RRC Connection Setup

• SRNS Relocation Info

[Link].2 New and modified IEs in Uu interface

The following table describes new or modified IEs in NBAP ,RNSAP and
RRC messages.

RRC messages

Parameter Source Note Description

UE radio access UE New IE A new optional IE MAC-ehs support

capability for each is added to this IE activated.
UE

Added or RRM Modified The IE is modified to enable

reconfigured DL IE for selection between MAC header
TrCH information each DL types (MAC-ehs or MAC-hs)
TrCH expressed as: CHOICE DL MAC
added header type. In case of MAC-ehs,
or the IE Added or reconfigured MAC-
reconfig ehs reordering queue is used,
ured otherwise the IE Added or
reconfigured MAC-D flow identify is
used.

Added or RRM New IE This IE is used in relation to the

reconfigured MAC- for each MAC-ehs reordering queues mapped
ehs reordering MAC- to the HS-DSCH transport channel.
queue ehs
queue

Deleted DL TrCH RRM Modified The IE is modified by adding

information IE for selection between MAC header
each types in HS-DSCH (MAC-ehs or
deleted MAC-hs). In case of MAC-ehs, MAC-
TrCH ehs Queue Id is used, otherwise
MAC-d flow identity is used.

Length indicator RRM New IE The IE used to set size of Length

size Indicator field to be used in DL AMD
PDU header with flexible RLC PDU
size.

MAC-ehs queue Id RRM New IE ID of the MAC-ehs re-ordering queue

for the MAC-d flow mapped to the
RB.

MAC-ehs support UE New IE To indicate if UE supports MAC-ehs

MAC-ehs window UE New IE Defines the number of MAC-ehs

size reordering PDUs that can be kept in
the UE's receive buffers.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 151(447)
Basic Call
 Functionality description

MAC-hs reset UE New IE This existing IE is used to indicate if

indicator the MAC-hs/ehs entity needs to be
reset.

RAB information RRM Modified The IE is modified due to

for setup IE for modification of the IE RB information
each to setup
RAB
setup

RB information to RRM Modified The IE is modified due to

be affected IE for modification of the IE RB Mapping
each RB info

RB information to RRM Modified The IE is modified because RLC Info

reconfigure IE for IE
each RB

RRM Modified The IE is modified because RLC Info

IE for IE
RB information to RAB
setup

RB Mapping info RRM New IE The IE is modified by adding

selection of DL MAC header type
(MAC-ehs or MAC-hs). In case of
MAC-ehs, MAC-ehs Queue ID is
used, otherwise, MAC-d flow idendity
is used.

RLC info RRM Modified The IE is modified by adding

IE selection between fixed and flexible
RLC PDU sizes in DL and setting for
usage of special HE value in AMD
PDU header.

Use special value RRM New IE Indicates whether the special HE

of HE field value is used in the AMD PDU
header. The IE is optional and its
absences implies that the special
value of HE is not used.

When Special value of HE field is

configured for UE, it is not taken
away as long as UE stays under the
same RNC. By doing so RLC
unrecoverable errors caused by
Special value of HE field
deconfiguration can be avoided on
UE side, see CR E0650.

[Link].3 Effects on Channel Type Switch from DCH to HS-DSCH with Flexible
RLC

Channel Type Switch from DCH to HS-DSCH (with FRLC)/E-DCH is

impacted because of Flexible RLC feature. During DCH<->HSPA and
HSDPA<->HSPA switch RLC can change from fixed<->flexible and this

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 152(447)
Basic Call
 Functionality description

requires one sided RLC re-establishement of RLC [Link] HSDPA<-

>HSPA switch if RLC changes between fixed<->flexible then this also
requires MAC-hs reset at UE and reconfiguration of MAC type between
MAC-hs and MAC-ehs because flexible RLC is supported only with MAC-
[Link] this scenario, several new IEs will be sent to Node B and UE.

RRC can configure the Node B to use 64QAM but usage of 64QAM will
be decided by Node B. Impact on RRC procedures are described in
section [Link].1. New and modified RRC IEs are described in section
[Link].2. The new and modified NBAP and RANAP IE’s and procedures
are described in /40/.

[Link].4 Multi RAB Configuration of UE supporting FRLC

With FRLC, the maximum supported multi RAB configuration of UE can

be 3 PS NRT interactive/Background RABs and 1 PS streaming RAB.
FRLC is not supported for CS RAB and SRB.

It is possible to have SRB and CS RAB with fixed RLC configuration and
3 PS NRT interactive/Background RABs and 1 PS streaming RAB with
flexible RLC configuration

[Link].5 Configuration switch between flexible <> fixed RLC PDU size

HA3/UER can trigger switch from flexible to fixed RLC or vice versa due to
channel type switch of uplink between E-DCH<-> DCH switch and during
serving cell change.

If RLC changes from fixed<->flexible during serving cell change(HSPA-

>HSPA) , this requires one sided RLC re-establishment and this also
requires that RB mapping info is changed because DL transport channel
type is now associated with MAC header type i.e. MAC-hs/[Link]
we RLC changes fixed<->flexible during serving cell change ,RRC needs
to perform one sided RLC re-establishment , send RB mapping info and
Added/Reconfigured downlink transport channel information to UE and
also perform MAC-hs reset.

During the reconfiguration, RRC will send some new IEs to NBAP and
[Link] on RRC procedures are described in [Link].1. New and
modified RRC IEs are described in [Link].2. The new and modified
NBAP and RANAP IE’s and procedures are described in /40/.

64 QAM is used only with flexible RLC so when RLC changes between
fixed<->flexible then usage of 64QAM also changes off<->on.

Flexible RLC can be used with/without 64QAM but 64QAM can not be
used without flexible RLC.

[Link] Fractional DPCH

[Link].1 Introduction

Fractional DPCH (F-DPCH) shares the DL dedicated code channel

carrying L1 signaling (TPC bits) of HSDPA users. DL L1 signaling of up
to 10 HSDPA users are time multiplexed on the same SF256 DL code

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 153(447)
Basic Call
 Functionality description

channel and L1 control overhead is reduced. By sharing the SF256

channel with F-DPCH, the number of HS-PDSCH codes (and DPCH
codes) can be increased.

Figure 55: DPCH and FDPCH comparison

F-DPCH can be used only if:

• UE is 3GPP Rel-7 and later and supports enhanced F-DPCH.

• Node-B supports F-DPCH

Rel-7 improves F-DPCH gains in soft handover when compared to Rel-6

F-DPCH, by allowing more SHO users to be multiplexed to the same
SF256 code channel. Rel-6 Ues also support F-DPCH. But RNC/BTS
only supports Rel.7 Enhanced F-DPCH. F-DPCH usage is possible and
applicable only if the signaling and user plane data is carried on HSPA
channels E-DCH (uplink) and HS-PDSCH (downlink). Hence there is
need to map SRBs to HSPA channels.
In this case HSUPA shall use either 2 ms or 10 ms TTI, but standalone
SRB can be on 10ms TTI only.

Switching between of SRBs on DCH and HSPA is supported.

RNC receives UE capability to support FDPCH during RRC Connection

Procedures see [Link]. RNC indicates to the UE the usage of FDPCH in
the following RRC messages:

RRC CONNECTION SETUP,

CELL UPDATE CONFIRM,

HANDOVER TO UTRAN COMMAND,

PHYSICAL CHANNEL RECONFIGURATION,

RADIO BEARER SETUP/RELEASE/ RECONFIGURATION, and

TRANSPORT CHANNEL RECONFIGURATION.

[Link].2 Allocation of F-DPCH

F-DPCH allocation is decided by UE-RRM based on the parameter

FDPCHSetup . F-DPCH can be allocated in following scenario:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 154(447)
Basic Call
 Functionality description

• Immediate F-DPCH allocation: F-DPCH is immediately

allocated after receiving RRC:RRC Connection Request from
the UE. If the UE rejects the RRC:RRC Connection Setup, the
existing RL & AAL2 resources are deleted and the new
resource request without F-DPCH is sent to the UE-RRM and
the new RRC connection setup attempt is done with SRBs on
DCH.
• F-DPCH allocation after RRC Connection Setup Complete: F-
DPCH is allocated immediately after receiving the RRC:RRC
Connection Setup Complete message from the UE indicating
the support for REL7 F-DPCH configuration. Here, RRC
Connection setup will be done in Cell-FACH state initially.
• During HSPA user plane creation for PS RAB: HSPA User
plane creation for PS NRT/RT RAB is modified with new
parameters for F-DPCH. This will be done only when value of
parameter FDPCHSetup=2.

[Link].3 Multi RAB configuration of the UE supported with SRBs on E-DCH/HS-

DSCH

When the F-DPCH feature is activated, the maximum supported multi

RAB configuration with SRBs on HSPA is one RT PS Streaming + 1..3
NRT PS Interactive/Background.
The maximum multi RAB configuration with SRBs on HSPA can be
restricted in following way:
• E-DCH TTI restriction: Configuration is possible with both
HSUPA TTIs (2 ms and 10 ms) if use of the HSUPA 2 ms TTI
is enabled (by the HSUPA2MSTTIEnabled parameter) in all
the active set cells, other wise only E-DCH TTI 10 ms can be
configured.
• Number of NRT RABs: Simultaneously more than one NRT
PS Interactive/Background RABs requires that
HspaMultiNrtRabSupport is enabled all the active set cells,
other wise maximum multi RAB configuration of the UE
supported with SRBs on HSPA is one NRT PS
Interactive/Background RAB.
• RT PS Streaming RAB: SRBs on HSPA can not be
configured if RT PS Streaming RAB is not enabled by the
HSPAQoSEnabled parameter for the all active set cells. Note:
RT PS Streaming RAB is possible to allocate on HSPA if
HSPAQoSEnabled is enabled in the HSPA serving cell

When an additional RAB (e.g. an CS RAB) is configured on DCH in

parallel to a SRB/PS RAB on E-DCH 10/2ms TTI, the SRB shall be
mapped to DCH and PS RAB will be mapped to 10ms TTI if 2ms TTI was
used earlier else PS RAB can be mapped to DCH or can remain on E-
DCH 10ms TTI.

[Link].4 E-DCH TTI reconfiguration 2ms <> 10ms

Please refer to section [Link].2 for further details.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 155(447)
Basic Call
 Functionality description

[Link].5 Effect on Channel Type Switch

The channel type switching shall take place only if the UE is located in a
cell area which supports F-DPCH and vice-versa. Channel type switching
is triggered based on handover or RRM decision.

Channel Type Switch for SRB is also supported in combination with PS

RAB. Following channel type scenarios are possible:

• Full DCH(SRB/PS RAB on DCH) <> HSPA 10ms/2ms

TTI(SRB/PS RAB on HSPA)
• HSUPA 2ms TTI(PS RAB on HSPA, UL SRB on E-DCH with
2ms TTI, DL SRB on DCH) <> HSPA 10ms/2ms TTI(SRB/PS
RAB on HSPA)
• DCH(SRB on DCH, PS RAB on HSxPA) <> HSPA 10ms/2ms
TTI(SRB/PS RAB on HSPA)
• HSPA 10ms(Standalone SRB on HSPA) > DCH(Standalone
SRB on DCH)

[Link].6 Effect on Serving Cell Change

When F-DPCH is active then during Serving Cell Change(SCC), CTS for
PS RAB shall not be performed. When F-DPCH is active then CTS
during SCC is only supported for SRBs. Following are the possible
scenario during SCC:

• HSUPA 2ms TTI(PS RB on HSPA, UL SRB on E-DCH with

2ms TTI, DL SRB on DCH) <> HSPA 10ms/2ms TTI(SRB/PS
RB on HSPA)
• DCH(SRB on DCH, PS RB on HSPA 10ms TTI) <> HSPA
10ms/2ms TTI(SRB/PS RB on HSPA)
• SCC with Standalone SRB on HSPA 10ms TTI
• SCC with SRB and PS RB with no TTI switch.

[Link].7 Combined Active Set Update (ASU) and HSPA Serving Cell Change
(HSCC) procedure

A combined Active Set Update (ASU) and HSPA Serving Cell Change
(HSCC) procedures are supported when SRBs are mapped to HSPA.
When SRBs are mapped to DCH then combined ASU with HSCC is not
supported.

ASU/HSCC procedure is triggered by the handover control (HA3) after

receiving a measurement report from the UE and the UE-RRM makes the
decision whether a classic two-phased (or in some cases three-phased)
scenario or the new combined version will be used. When the latter one
is chosen to be used, the UE-RRM indicates this to the RRC-layer.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 156(447)
Basic Call
 Functionality description

[Link] MIMO 28 Mbps

MIMO enables 28,8 Mbps peak HSDPA data rate with 16QAM and
therefore, it increases the single user peak data rate, overall cell capacity
and average cell throughput.

HSDPA Rel7 terminal categories 15, 16, 17, 18 and Rel8 terminal
categories 19 and 20 are introduced supporting MIMO + 16QAM
configuration .

MIMO capability is signalled by the UE to the RNC during the RRC

Connection Setup procedure. RNC informs the MIMO relevant parameters
to MIMO capable UE via RRC signaling. In case the MIMO capable UE is
not configured in MIMO mode, it will operate as a regular non-MIMO UE.

MIMO is activated in BTS by radio link setup or reconfiguration procedure,

see /40/

The BTS decides MIMO parameters; UE reporting configuration (N/M

ratio), Number of prosesses in HARQ Memory partitioning for MIMO, S-
CPICH channelisation code and precoding weight set restriction.

RNC indicates to the UE the usage of MIMO with MIMO parameters IE in

messages:

CELL UPDATE CONFIRM,

ACTIVE SET UPDATE and

RADIO BEARER SETUP/RELEASE/ RECONFIGURATION

MIMO has to be deactivated when CS or RT PS RAB is added and also

activated again when CS or RT PS RAB is removed. /35/

MIMO is supported with multiRAB PS configuration.

Simultaneous usage of RAN1643 HSDPA 64 QAM and RAN 1642 MIMO

28 Mbps is not possible . The RNC does not configure 64 QAM for the UE
if MIMO is activated.

[Link] MIMO 42 Mbps

/RAN1912/ MIMO 42 Mbps feature allows both MIMO and HSDPA

64QAM to be activated simultaneously for the UE. MIMO 42 Mbps
feature enables MIMO operation with 42 Mbps applying 64QAM
modulation scheme.

HSDPA Rel8 terminal categories 19 and 20 support MIMO with 64QAM.

RNC shall configure MIMO with HSDPA 64 QAM in use for the UE and
BTS in connection with the HS-DSCH MAC-d flow setup for NRT RAB.
MIMO configuration follows the principles specified for MIMO in

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 157(447)
Basic Call
 Functionality description

/RAN1642/. HSDPA 64 QAM configuration follows the principles specified

in /RAN1643/.

[Link] DC-HSDPA 42Mbps

Dual Cell HSDPA in 3GPP Rel8 uses two WCDMA carriers to transmit DL
data for a single UE. Together with 64QAM, peak bit rate is 42 Mbps, with
16QAM it is 28Mbps.

UL transmission takes place on one of the two carriers.

HSDPA Rel8 terminal categories 21, 22, 23 and 24 are introduced for
supporting DC-HSDPA. To get the full benefit of DC-HSDPA (=maximum
possible peak rate) the UE must be either category 23 or 24, because
these categories have the 64QAM support which is needed to reach the
48Mbps.

These new category UEs have the same L2 capabilities as for category
15, 16, 19 and 20 UEs.

DC-HSDPA capability is signalled by the UE to the RNC during the RRC

Connection Setup procedure. RNC informs the DC-HSDPA relevant
parameters to DC-HSDPA capable UE via RRC signaling. In case the
DC-HSDPA capable UE is not configured in DC-HSDPA mode, it will
operate as a regular “non-DC-HSDPA” UE.

For the mapping of SRBs, two options shall be supported:

- SRBs on HSPA, thus with a parallel F-DPCH
- SRBs on DCH, thus using DL DPCCH

DC-HSDPA is supported from 1 up to 3 NRT RABs at the same time.

In more detail, the following restrictions apply (see /35/ for even more
details):
- No DC-HSDPA for CS voice over HSPA
- No DC-HSDPA for Streaming traffic class
- No DC-HSDPA for CS+NRT PS multiRABs
- Switch SC-HSDPA <-> DC-HSDPA due to CS/RT RAB
setup/release, should be done
- No DC-HSDPA for RT PS + NRT PS multiRABs
- DC HSDPA only with MAC-ehs (Flexible RLC all DC-HSDPA
UEs have to support it)

DC-HSDPA can be configured to the UE by including Downlink secondary

cell info FDD IE into one of the following messages (RRC specification
chapter number included):

- 10.2.8 CELL UPDATE CONFIRM

- 10.2.27 RADIO BEARER RECONFIGURATION

- 10.2.33 RADIO BEARER SETUP

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 158(447)
Basic Call
 Functionality description

- 10.2.30 RADIO BEARER RELEASE

And as long as DC-HSDPA is ON, every RRC message that can have
Downlink secondary cell info FDD IE in it, must have the IE present the
RRC message. This is because, when DC-HSDPA is configured to the
UE, the absence of Downlink secondary cell info FDD IE in a RRC
message that can have this IE, signals that the secondary serving cell
shall be removed.

So, DC-HSDPA can be removed from the UE configuration by leaving the

Downlink secondary cell info FDD IE out of the RRC message.

DC-HSDPA SCC (SCC from one DC-HSDPA cell to another DC-HSDPA

cell) can be signalled to the UE with following 2 messages:

- 10.2.1 ACTIVE SET UPDATE (FDD only)

- 10.2.27 RADIO BEARER RECONFIGURATION

DC-HSDPA can be setup in BTS for a specific UE either via NBAP RL

Setup or Synchronised RL Reconfiguration procedure. The DC-HSDPA
parameters are depending of the used procedure either under the
Additional HS Cell Information RL Setup IE or Additional HS Cell
Information RL Reconf Prep IE.

List of NBAP procedures that are used in DC-HSDPA operations in our

system and contain DC-HSDPA specific parameters is described in /40/.

RAN1642 MIMO 28 Mbps and RAN 1906 DC-HSDPA 42 Mbps can not
be used simultaneously for the UE even they can be enabled in the same
cell. The preference between MIMO and DC-HSDPA is defined by the
RNC-DCellVsMIMOPreference parameter.

[Link] DC-HSDPA 84 Mbps

/RAN1907/ DC-HSDPA 84 Mbps feature allows DC-HSDPA, MIMO and

HSDPA 64 QAM to be activated simultaneously for the UE. RAN1907 DC-
HSDPA with MIMO 84 Mbps combines DC-HSDPA, MIMO and 64QAM to
achieve 84 Mbps peak rate in DL. MIMO is active on both carriers of the
Dual Cell. 64QAM modulation can be used when radio conditions allow.
UE reports in total 4 CQI/2 PCI values and 4 ACK/NACK indicators. Two
values are reported on each carrier due to MIMO, and both carriers have
independent reporting to allow joint Dual Cell scheduling to be performed.
MIMO scheduling on both carriers is independent, so MIMO can be on
dual stream mode on one carrier and on single stream mode on other
carrier.

DC-HSDPA with MIMO can be enabled in the cell and configured in use
for the UE without RAN1643 HSDPA 64QAM. In this case the maximum
achievable data rate will be 56 Mbps.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 159(447)
Basic Call
 Functionality description

64QAM must be configured in use in both the primary and secondary DC-
HSDPA cell. If this is not possible, 64QAM shall not be configured in use
with DC-HSDPA and MIMO.

Primarily, MIMO shall be configured in use both in the primary cell and the
secondary cell, if possible. MIMO shall be configured in use in the primary
cell only, if MIMO usage in the secondary cell is not possible.

If MIMO is configured in use in the primary cell but not in the secondary
cell, the maximum achievable data rate will be 63 Mbps (Primary 42 Mbps
+ Secondary 21 Mbps) provided that 64QAM is configured in use. Without
64QAM the maximum achievable data rate will be 42 Mbps (Primary 28
Mbps + Secondary 14 Mbps).

HS-DSCH physical layer category defines the HS-DSCH capability. RNC

receives the value from the UE ( REL-9 HS-DSCH physical layer category
extension 3) and signals the value to the BTS.

HSDPA Rel9 terminal categories 25… 28 support DC-HSDPA with MIMO.

RNC shall configure DC-HSDPA with MIMO in use for the UE and BTS in
connection with the HS-DSCH MAC-d flow setup for NRT RAB. DC-
HSDPA configuration follows the principles specified for DC-HSDPA in
/RAN1906/. MIMO configuration follows the principles specified for MIMO
in /RAN1642/.

<internal/begin>

<RAN2211/begin>

[Link] MC-HSDPA

Multi Cell HSDPA increases the DL peak rate data rate by aggregation in
3 carriers in combination with 64 QAM. Multi Cell HSDPA feature allows
usage of 3 simultaneous HSDPA DL cells in one or two bands for 1 user
without MIMO in any of these carriers. For single user maximum peak
rate up to 63 Mbps is possible when 3 simultaneous DL cells used with 64
QAM in all of them. To use 64 QAM , the primary and all secondary
serving cells shall have 64 QAM. If any of these serving cells do not have
64 QAM , then 64 QAM shall not be used.

MC-HSDPA capability is signalled by the UE to the RNC during the RRC

Connection Setup procedure using Physical channel capability IE. RNC
informs the MC-HSDPA relevant parameters (Additional downlink
secondary cell info list FDD IE) to MC-HSDPA capable UE via RRC
signaling. In case the MC-HSDPA capable UE is not configured in MC-
HSDPA mode, it will operate as a regular “non-MC-HSDPA” UE.

Following RAB combinations are only supported in MC-HSDPA:

- SRBs on HSPA + Max 3 HSPA NRT , thus using F-DPCH
- SRBs on DCH+ Max 3 HSPA NRT, thus using DL DPCCH
- SRBs on HSUPA+ Max 3 HSPA NRT, thus using no
FDPCH but only 2ms TTI.

MC-HSDPA is supported from 1 up to 3 NRT RABs at the same time.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 160(447)
Basic Call
 Functionality description

<Internal/Begin>
For any other RAB combination MC-HSDPA shall not be supported.
<Internal/End>
MC-HSDPA can be configured to the UE by including Additional downlink
secondary cell info list FDD IE into one of the following messages:

o ACTIVE SET UPDATE

o CELL UPDATE CONFIRM

o RADIO BEARER RECONFIGURATION

o RADIO BEARER SETUP

o PHYSICAL CHANNEL RECONFIGURAION

o RRC CONNECTION SETUP

And as long as MC-HSDPA is ON, every RRC message that can have
Additional downlink secondary cell info list FDD IE in it, must have the IE
present the RRC message. This is because, when MC-HSDPA is
configured to the UE, the absence of Additional downlink secondary cell
info list FDD IE in a RRC message that can have this IE, signals that the
secondary serving cell shall be removed.

MC-HSDPA can be removed from the UE configuration by ommiting the

Additional downlink secondary cell info list FDD IE out of the RRC
message.

MC-HSDPA Serving Cell Change (Serving Cell Change from one MC-
HSDPA cell to another MC-HSDPA cell) can be signalled to the UE with
following 2 messages:

o ACTIVE SET UPDATE

o RADIO BEARER RECONFIGURATION

MC-HSDPA can be setup in BTS for a specific UE either via NBAP RL

Setup or Synchronised RL Reconfiguration procedure. The MC-HSDPA
parameters are dependant on the used procedure either under the
Additional HS Cell Information RL Setup IE or Additional HS Cell
Information RL Reconf Prep IE. Maximum 2 secondary HSDPA cells
can be configured towards UE and BTS.

List of NBAP procedures that are used in MC-HSDPA operations in our

system and contain MC-HSDPA specific parameters is described in /40/

<RAN2211/end>

<lnternal/end>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 161(447)
Basic Call
 Functionality description

2.3.11 HSUPA Feature Functionality

[Link] Introduction

The HSUPA feature of the 3GPP WCDMA system is in fact a new uplink
transport channel – E-DCH – that brought some of the same features to
the uplink as the HSDPA with its new transport channel – high-speed
downlink shared channel (HS-DSCH) – provided for the downlink. The E-
DCH transport channel supports fast Node B based scheduling, fast
physical layer HARQ with incremental redundancy and, optionally, a
shorter 2-ms transmission time interval (TTI). Following architecture
depicts the user plane protocol architecture for HSUPA

Figure 57: User plane protocol architecture for HSUPA

Though – unlike HSDPA – HSUPA is not a shared channel, but a dedicated

one, by structure the E-DCH is more like the DCH of Release 99 but with
fast scheduling and HARQ than an uplink HSDPA: that is, each UE has its
own dedicated E-DCH data path to the Node B that is continuous and
independent from the DCHs and E-DCHs of other UEs. The following
figure depicts the general radio interface architecture for user data in case
of HSDPA and HSUPA

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 162(447)
Basic Call
 Functionality description

Figure 58: User data in HSUPA and HSDPA

[Link] HSUPA Enhancements

The basic principle behind HARQ for HSUPA is the same as that for
HSDPA. After each transmitted TTI the Node B indicates to the
transmitting UE whether the packet was received correctly or not. In the
event of incorrect reception the UE will retransmit the packet. The Node
B tries to recover the packet by combining the energy of the
retransmission with previous transmissions until the packet is received
correctly or the maximum number of retransmissions is reached. The
HSUPA HARQ may either use Chase combining where each
retransmission is an exact copy of the initial transmission, or incremental
redundancy where retransmissions contain additional redundancy bits for
the initially transmitted bits.
The main differences between HARQ with HSUPA and HARQ with
HSDPA are that HSUPA HARQ is fully synchronous and, with
incremental redundancy, even transmitted redundancy versions can be
predetermined; it also operates in soft handover.

[Link] HSUPA Transport and Physical Channels

Respectively, new signalling channels are needed (as shown in Figure

below); all the channels (excluding broadcast ones) shown in the figure
are necessary for HSUPA operation.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 163(447)
Basic Call
 Functionality description

Figure 59: New signaling channels needed for HSUPA operation

Uplink transport channel processing for E-DCH is similar to the processing

of the uplink DCH with two exceptions. There can be only one E-DCH
transport channel in the UE as there may be multiple parallel DCHs that
are multiplexed together to a single coded composite transport channel
(CCTrCH) of DCH type. Nevertheless, the MAC layer can multiplex
multiple parallel services to the single E-DCH. The other significant
difference is HARQ support for the E-DCH which is provided in the
transport channel processing chain and is, of course, something totally
new. After transport channel processing, the E-DCH maps to one or
multiple parallel new dedicated physical data channels – E-DPDCHs – for
physical layer transmission. Using E-DPDCH transmissions a
simultaneous and parallel control channel is sent a separate code channel
– E-DPCCH. This E-DPCCH transmits all the necessary information about
the E-DPDCH that is needed in order to know how to receive the data
channel. In the downlink three new physical channels were introduced to
provide HARQ feedback and facilitate uplink scheduling. The E-DCH
HARQ indicator channel (EHICH) sends the HARQ acknowledgement
information back to the UE. The E-RGCH provides relative step-up/down
scheduling commands and the E-AGCH provides an absolute scheduling
value for the UE.

In case RAN1470 HSUPA 2ms TTI feature is enabled, then additional E-

AGCH shall be configured for support of UE’s with E-DCH 2ms TTI, since
E-RGCH cannot be used for users with E-DCH 2ms TTI on the serving
BTS (timing reasons).

[Link] HSUPA 5.8 Mbps

RAN981 HSUPA 5.8 Mbps feature increase uplink E-DCH peak bit rate
for single user up to 5.8 Mbps.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 164(447)
Basic Call
 Functionality description

This feature together with F-DPCH introduced the full HSPA support
(SRBs and RBs mapped on HSPA).

To achieve bit rates up to 5.8 Mbps requires the use of E-DCH 2ms
transmission time interval (TTI) and SRB on HSUPA. HSUPA categories
4,6 and 7 support higher bit rate than 2 Mbps.

HSUPA categories 6 and 7 UE is capable of 5.8 Mbps peak radio

interface bit rate, which is achieved with an E-DCH configuration of 2ms
TTI and four parallel codes. When four codes are transmitted in parallel,
two codes are transmitted with spreading factor two (2xSF2) and two with
spreading factor four (2xSF4). Also intermediate bit rates are supported
with E-DCH 2ms TTI.

RNC receives BTS capability to support 2xSF2+2xSF4 in NBAP: Audit

Response message in E-DCH SF Capability IE.

[Link] HSUPA 2ms TTI

RAN1470 HSUPA 2ms TTI feature enable E-DCH 2ms TTI and lower
latency. Shorter TTI and lower latency improve application level
performance and end user HSUPA experience. HSUPA 2ms TTI is used
for UE categories 2,4,6 and 7.

Shorter TTI improves average latency in air interface by 12 ms for the first
transmission. Faster retransmissions also reduce variance of the RTT.
Immediate data processing in Iub and RNC user plane also shortens the
round trip time.

Use of 2ms TTI requires uplink Signaling Radio Bearers (SRB) are
mapped on E-DCH. SRBs need to map on E-DCH to enables the 2xSF2
+ 2xSF4 physical channel configuration that needed for RAN981 HSUPA
5.8 Mbps feature. When four codes channel are used for E-DCHs, there
is no room for a DPDCH physical Channel where a DCH for SRBs could
be mapped. Thus SRB UL transport channel is always mapped on E-DCH
with HSUPA 2ms TTI.

Non-scheduled transmission (NST) is used for SRBs MAC-d flow, when

SRB are mapped on HSUPA/HSPA. One HARQ process shall be used
for SRB NST. Scheduling Priority Indicator (SPI) is configurable for the
MAC-D Flow on which the SRB is mapped

RNC receives BTS capability to support E-DCH 2ms TTI in NBAP: Audit
Response message in E-DCH TTI2ms Capability IE. RNC indicates to the
UE the usage of E-DCH 2ms TTI and UL E-DCH/DL DCH channel
configuration in the following RRC messages:

CELL UPDATE CONFIRM,

HANDOVER TO UTRAN COMMAND,

PHYSICAL CHANNEL RECONFIGURATION,

RADIO BEARER SETUP/RELEASE/ RECONFIGURATION, and

TRANSPORT CHANNEL RECONFIGURATION.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 165(447)
Basic Call
 Functionality description

[Link].1 Multi RAB Configuration of UE supported with HSUPA 2ms TTI

With HSUPA 2ms TTI, the maximum supported multi RAB configuration
of UE can be 3 NRT PS interactive/Background RABs. The maximum
possible multi RAB configuration with SRBs on HSUPA can be restricted
to one NRT RAB, if HspaMultiRabSupported parameter is not
[Link] an additional RAB (e.g. an CS RAB) is configured on DCH
in parallel to a PS RAB on E-DCH 2ms TTI, the E-DCH TTI shall be
changed to 10 ms and UL SRBs shall be mapped to DCH. Similarly
Streaming PS RABs shall be mapped on E-DCH 10ms TTI.

[Link].2 E-DCH TTI reconfiguration 2ms <> 10ms

RNC/HA3 can trigger TTI reconfiguration from E-DCH 2ms TTI to E-DCH
10ms TTI and vice versa based on RRM decision,

In order to switch the TTI in UE, BTS and RNC simultaneously, RNC shall
trigger a synchronized NBAP: RL Reconfiguration towards BTS and
synchronized RB reconfiguration to UE. In case of HSUPA 2ms TTI, SRB
UL trch channel shall be mapped to E-DCH.

SRB Transport channel: In case RAN1201 F-DPCH feature is disabled

then UL SRB transport channel shall be switch from E-DCH to DCH 3.4
kbps due to TTI reconfiguration from TTI 2ms to TTI 10ms and vice versa.
DL DCH will remain mapped to DCH3.4kbps during TTI reconfiguration.
In case RAN1201 Fractional DPCH feature is enabled then there will be
no transport channel switch for SRB, there will be only E-DCH TTI change
from 2ms<>10ms.

PS RB transport channel mapping will remain unchanged during E-DCH

TTI reconfiguration.

MAC-e reset shall be performed during E-DCH TTI reconfiguration. The

MAC-e buffers have to be flushed during TTI change.

When the switch between 2ms TTI and 10ms TTI takes place the E-
DPDCH power interpolation related amplitude ratios are indicated to UE
in RRC message.

If HSUPA 16QAM is allowed and used in RB, and 2ms TTI is no more
available (switched from 2ms TTI to 10ms TTI), HSUPA 16QAM is no
more allowed and RLC PDU size reconfiguration for NRT PS RBs in all
cells of AS from 656 bits to 336 bits is made (RLC re-establishment 656 -
> 336).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 166(447)
Basic Call
 Functionality description

UE BTS RNC

PS RAB on HSPA, SRBs on E-DCH/DCH, UE is 2ms TTI capable

Measurement Reporting

Trigger for TTI switch

(UE entering or leaving 2ms
area)

•Switch UL SRBs from HSUPA to UL DCH3.4 or

vice versa
•Reset MAc-e/es
•Reconfigure E-DCH FP Congestion Control
•Reconfigure OLPC
•Change:
• TTI
• SF
NBAP/RNSAP/ALCAP: RL Reconfiguration • PO
(synchronized) •E-TFC table, reference E-TFC, …

RB reconfiguration (synchronized)

RB reconfiguration complete (synchronized)

Figure 60 E-DCH TTI Reconfiguration

[Link].3 Channel Type Switch between DCH <> E-DCH 2ms TTI

The channel type switching from DCH (all RBs on DCH) to E-DCH (PS
RAB on HSPA, UL SRB on E-DCH with 2ms TTI, DL SRB on DCH) shall
take place only if the UE is located in a cell area in that E-DCH 2ms TTI
can be supported.

The channel type switching from E-DCH 2ms TTI (all RBs on E-DCH/HS-
DSCH and SRB on UL E-DCH/DL DCH) to DCH and vice versa is
triggered based on handover or RRM decision.

[Link] Flexible RLC in UL

The main purpose of the feature RAN1910 Flexible RLC in UL is to enable

achieving higher HSUPA peak rates. The means for this is reducing UL
RLC overhead by allowing usage of flexible RLC PDU sizes. The reduced
UL RLC overhead results from the fact that padding is not needed
anymore to fill out the fixed size RLC PDUs and payload size is increased,
whereas the header size remains the same. Flexible RLC UL operation
reduces processing needs in UE, BTS and RNC.
The Flexible RLC UL is characterised by following:
• size of uplink RLC PDUs can be significantly larger than in the
fixed RLC UL mode. The size is determined autonomously by the
RLC layer within the limits given by upper layers,
• there is no need to use padding to reach a certain predefined
PDU size,

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 167(447)
Basic Call
 Functionality description

• new MAC entity called MAC-i/is is needed to support Flexible

RLC in UL. MAC-i/is is implemented in RNC and UE, while BTS
needs to implement only MAC-i.

Flexible RLC in UL feature is used, when the following criteria are met in
all cells of Active Set for all RBs and SRBs of the UE mapped on E-DCH:
• The cell is flexible RLC UL capable
• The UE is flexible RLC UL capable
• The Flexible RLC UL is enabled in RNC with FlexULRLCEnabled
parameter for the first RB/SRB
• The criteria for the usage of Flexible RLC DL in a cell are fulfilled
• The cell is handled by SRNC i.e. drifting is not allowed
Otherwise, fixed RLC uplink PDU size/MAC-e/es is used.

The feature is applicable for RBs using AM or UM RLC and mapped on E-

DCH transport channel using MAC-i/-is in CDSP-DH card and for SRBs
using AM or UM RLC and mapped on E-DCH transport channel using
MAC-i/-is in CDSP-DH and <up to RN7.0/beginning> CDSP-C <up to
RN7.0/end> cards. The actual flexible RLC PDU sizes are utilized with
NRT RBs, while SRBs and RT RBs (including CS Voice over HSPA)
utilize the legacy fixed RLC PDU sizes.

The feature is not under license control and it belongs to the RNC Basic
SW (BSW).

Flexible RLC in UL feature is not supported on Iur interface.

[Link].1 Impacts on NBAP and RRC procedures

Flexible RLC in UL feature have impacts on the following NBAP

procedures:

• Audit,

• Resource Status Indication,

• Radio Link Setup and

• Synchronised Radio Link Reconfiguration Preparation.

Flexible RLC in UL feature have impacts on the following RRC

procedures:

• RRC Connection Request,

• RRC Connection Setup,

• RRC Connection Setup Complete,

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 168(447)
Basic Call
 Functionality description

• UE Capability Information,

• Cell Update Confirm,

• Radio Bearer Setup,

• Radio Bearer Reconfiguration and

• SRNS Relocation Info.

[Link].2 New and modified IEs in Uu interface

The usage of MAC-i/is and flexible RLC uplink PDU size is indicated to
UE in the following RRC messages:

▪ RRC CONNECTION SETUP,

▪ CELL UPDATE CONFIRM,

▪ RADIO BEARER SETUP and

▪ RADIO BEARER RECONFIGURATION.

Indication about the use of MAC-i/is is done with a new UL MAC Header
Type IE (enumerated (MAC-i/is)), which is added to Added or Reconfigured
UL TrCH Information IE. If UL MAC Header Type IE is present, MAC-i/is
header type is used, else MAC-e/es header type is used.

Indication about the use of flexible RLC uplink PDU size is done with a new
choice RLC PDU [Link] Size, which is added to RB Mapping Info IE.

Flexible Size:

• Length Indicator Size (7-bit or 15-bit)

• Minimum UL RLC PDU Size (integer 16..12040 by step of 8, units
in bits)
• Largest UL RLC PDU Size (integer 16..12040 by step of 8, units in
bits).

Indication about the use of fixed RLC uplink PDU size is done with the
legacy choice RLC PDU [Link] Size.

Fixed Size:

• RLC PDU Size (integer (16..5000 by step of 8), units in bits).

NOTE: Information about new and modified IEs on Iub interface is

presented in NBAP And RNSAP Procedures FD.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 169(447)
Basic Call
 Functionality description

[Link].3 Flexible RLC uplink PDU size capability of a local cell

Information of the cell’s support for flexible RLC uplink PDU size is
received from BTS in the following messages:
• NBAP: AUDIT RESPONSE,
• NBAP: RESOURCE STATUS INDICATION.

Upon receiving of the messages, O&M finds out and stores information of
the local cell's capability for flexible RLC uplink PDU size into RNW
database object LCEL. The new E-DCH MAC-d PDU Size Capability IE
defines the capability for a cell to support different MAC-d PDU Size
formats, i.e. it indicates cell's support for flexible RLC uplink PDU size. If
this IE is set to "Flexible Size Capable" the cell is "Fixed Size Capable"
and "Flexible Size Capable". If this IE has not been configured or has
been set to "Fixed Size Capable" the cell is only "Fixed Size Capable”.
Local cell is MAC-i capable when it is flexible RLC uplink PDU size
capable.
O&M passes the information about cell's support for flexible RLC uplink
PDU size to RRM, which uses the information for flexible RLC UL usage
determination.
Unless otherwise informed by the BTS, RRM assume that the cell is not
capable for flexible RLC uplink PDU size, i.e. non MAC-i capable.

[Link].4 Flexible RLC uplink PDU size capability of UE

Information of the UE’s support for flexible RLC uplink PDU size is
received from UE either
• directly from UE via RRC messages RRC CONNECTION
REQUEST / RRC CONNECTION SETUP COMPLETE / UE
CAPABILITY INFORMATION or
• from other RNC via the SRNS Relocation Info IE contained in
RANAP: RELOCATION REQUEST message during hard
handover.

Optional Support of MAC-i/is IE is included in above messages. If present

and set as TRUE, Support of MAC-i/is IE indicates that UE supports MAC-
i/is operation.
L3 maintains UE’s support for MAC-i/is during UE’s RRC connection. UE
is flexible RLC uplink PDU size capable when it is MAC-i/is capable.
L3 informs RRM about UE’s capabilities and RRM uses the UE's flexible
RLC uplink PDU size capability for flexible RLC UL usage determination.

[Link].5 RRC Connection Establishment with flexible RLC uplink PDU size

When flexible RLC UL can be applied during RRC connection

establishment, L3 requests E-DCH establishment with FRLC UL
parameter from BTS with NBAP: RADIO LINK SETUP REQUEST
message.
After reception of NBAP: RADIO LINK SETUP RESPONSE message L3
configures L2 and TRM as usual, but with the addition of flexible RLC
uplink PDU size related RLC and MAC parameters.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 170(447)
Basic Call
 Functionality description

L3 then requests E-DCH establishment with FRLC UL parameters from

UE with RRC: RRC CONNECTION SETUP message. Fixed RLC uplink
PDU size is applied for SRBs although MAC-i/is is in use.

[Link].6 Capacity allocation with flexible RLC uplink PDU size

When flexible RLC UL can be applied during MAC-d flow setup/addition,

L3 requests E-DCH establishment with FRLC UL parameters from BTS
• with NBAP: RADIO LINK RECONFIGURATION PREPARE
message for UE in Cell-DCH state or
• with NBAP: RADIO LINK SETUP REQUEST message for UE in
Cell-FACH state.

After reception of NBAP: RADIO LINK SETUP RESPONSE/ RADIO LINK

RECONFIGURATION READY message L3 configures L2 and TRM as
usual, but with the addition of flexible RLC uplink PDU size related RLC
and MAC parameters.

L3 then requests E-DCH establishment with FRLC UL parameters from

UE
• with RRC: RADIO BEARER SETUP message, when UL/DL
capacity request is not in use (=DRA is applied, see Fast Call
Setup on RRC State Transitions For Packet Data FD) or
• with RRC: RADIO BEARER RECONFIGURATION message,
when UL/DL capacity request is in use.

[Link].7 Channel type switch with change from fixed to flexible RLC uplink
PDU size

When flexible RLC UL can be applied during channel type switch from
DCH to E-DCH, L3 requests E-DCH establishment with FRLC UL
parameters (MAC-i/is) from BTS(s) with NBAP: RADIO LINK
RECONFIGURATION PREPARE message(s).
After reception of NBAP: RADIO LINK RECONFIGURATION READY
message(s) L3 configures L2 and TRM as usual, but with the addition of
flexible RLC uplink PDU size related RLC and MAC parameters.

L3 then requests E-DCH establishment with FRLC UL parameters from

UE with RRC: RADIO BEARER RECONFIGURATION message.
The transmitting side of RLC entity of UE is reset during radio bearer
reconfiguration because of change in RLC PDU size. If both transmitting
and receiving side RLC PDU sizes are changing simultaneously, the
whole RLC entity of UE is reset:
•RB Information To Reconfigure [Link] Information To
[Link] [Link] Sided RLC Re-establishment: set as
TRUE to indicate that the transmitting side of RLC entity needs to be
reset. If receiving side of RLC entity needs to be reset
simultaneously, the IE is set as FALSE.

If the RRC: RADIO BEARER RECONFIGURATION message received by

UE causes a change in the RLC PDU size or a change between fixed and

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 171(447)
Basic Call
 Functionality description

flexible RLC PDU size for any RB using AM RLC, UE calculates a new
START value for each CN and includes them in the RRC: RADIO
BEARER RECONFIGURATION COMPLETE message.
After the RRC: RADIO BEARER RECONFIGURATION COMPLETE
message containing new START values is received from UE, L3 sends
the new CN specific START values for L2, which uses them for
ciphering/deciphering re-initialisation for all RB(s) using AM/UM RLC. L3
uses the new CN specific START values for integrity check re-
initialisation.
The handling of received START value is also valid for the CTS case to
opposite direction, see next chapter.

[Link].8 Channel type switch with change from flexible to fixed RLC uplink
PDU size

During channel type switch from E-DCH to DCH, L3 requests DCH

establishment with legacy fixed RLC UL parameters from BTS(s) with
NBAP: RADIO LINK RECONFIGURATION PREPARE message(s) in a
legacy manner.
After reception of NBAP: RADIO LINK RECONFIGURATION READY
message(s) L3 configures L2 and TRM in a legacy manner.

L3 then requests DCH establishment with legacy fixed RLC UL

parameters from UE with RRC: RADIO BEARER RECONFIGURATION
message in a legacy manner. The transmitting side of RLC entity of UE is
reset because of change in RLC PDU size. If both transmitting and
receiving side RLC PDU sizes are changing simultaneously, the whole
RLC entity of UE is reset.

[Link].9 Reconfiguration of E-DCH MAC-d flows from fixed to flexible RLC

uplink PDU size

Based on RRM decision to reconfigure E-DCH MAC-d flow(s) from fixed

(MAC-e/es) to flexible (MAC-i/is) RLC uplink PDU size, L3 requests E-
DCH modification with FRLC UL parameters (MAC-i/is) from BTS(s) with
NBAP: RADIO LINK RECONFIGURATION PREPARE message(s).
MAC entities of BTS(s) are reset during radio link reconfiguration
because of MAC entity reset on UE, see below:
•E-DCH FDD Information To [Link]-e Reset Indicator =
‘MAC-e Reset’

After reception of NBAP: RADIO LINK RECONFIGURATION READY

message(s) L3 configures L2 and TRM as usual, but with the addition of
flexible RLC uplink PDU size related RLC and MAC parameters.

L3 then requests E-DCH modification with FRLC UL parameters from

UE with RRC: RADIO BEARER RECONFIGURATION message.
MAC entity of UE is reset during radio bearer reconfiguration to flush all
HARQ processes on UE. Reason is that after UL MAC header type
reconfigurations between MAC-e/es and MAC-i/is, UE behaviour is
unspecified without a reset:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 172(447)
Basic Call
 Functionality description

•E-DCH [Link]-es/e Reset Indicator: set as TRUE to indicate that

MAC entity needs to be reset
The transmitting side of RLC entity of UE is reset during radio bearer
reconfiguration because of change in RLC PDU size. If both transmitting
and receiving side RLC PDU sizes are changing simultaneously, the
whole RLC entity of UE is reset:
•RB Information To Reconfigure [Link] Information To
[Link] [Link] Sided RLC Re-establishment: set as
TRUE to indicate that the transmitting side of RLC entity needs to be
reset. If receiving side of RLC entity needs to be reset
simultaneously, the IE is set as FALSE.

If the RRC: RADIO BEARER RECONFIGURATION message received by

UE causes a change in the RLC PDU size or a change between fixed and
flexible RLC PDU size for any RB using AM RLC, UE calculates a new
START value for each CN and includes them in the RRC: RADIO
BEARER RECONFIGURATION COMPLETE message.
After the RRC: RADIO BEARER RECONFIGURATION COMPLETE
message containing new START values is received from UE, L3 sends
the new CN specific START values for L2, which uses them for
ciphering/deciphering re-initialisation for all RB(s) using AM/UM RLC. L3
uses the new CN specific START values for integrity check re-
initialisation.
The handling of received START value is also valid for the reconfiguration
case to opposite direction, see next chapter.

[Link].10 Reconfiguration of E-DCH MAC-d flows from flexible to fixed RLC

uplink PDU size

Based on RRM decision to reconfigure E-DCH MAC-d flow(s) from

flexible (MAC-i/is) to fixed (MAC-e/es) RLC uplink PDU size, L3 requests
E-DCH modification with fixed RLC UL parameters (MAC-e/es) from
BTS(s) with NBAP: RADIO LINK RECONFIGURATION PREPARE
message(s).
MAC entities of BTS(s) are reset because of MAC entity reset on UE,
see below:
•E-DCH FDD Information To [Link]-e Reset Indicator =
‘MAC-e Reset’

After reception of NBAP: RADIO LINK RECONFIGURATION READY

message(s) L3 configures L2 and TRM in a legacy manner.

L3 then requests E-DCH modification with fixed RLC UL parameters

from UE with RRC: RADIO BEARER RECONFIGURATION message.
MAC entity of UE is reset to flush all HARQ processes on UE. Reason is
that after UL MAC header type reconfigurations between MAC-e/es and
MAC-i/is, UE behaviour is unspecified without a reset:
•E-DCH [Link]-es/e Reset Indicator: set as TRUE to indicate that
MAC entity needs to be reset
The transmitting side of RLC entity of UE is reset because of change in
RLC PDU size. If both transmitting and receiving side RLC PDU sizes
are changing simultaneously, the whole RLC entity of UE is reset:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 173(447)
Basic Call
 Functionality description

•RB Information To Reconfigure [Link] Information To

[Link] [Link] Sided RLC Re-establishment: set as
TRUE to indicate that the transmitting side of RLC entity needs to be
reset. If receiving side of RLC entity needs to be reset
simultaneously, the IE is set as FALSE.

[Link].11 Failure during radio link setup / reconfiguration

If the establishment / reconfiguration of the requested radio link(s) is

unsuccessful due to lack of support for flexible RLC uplink PDU size in
BTS, BTS rejects the procedure using the NBAP: RADIO LINK SETUP
FAILURE / RADIO LINK RECONFIGURATION FAILURE message with
a new Radio Network Layer cause “E-DCH MAC-d PDU Size Format not
available”.

RRM uses then fixed uplink PDU size on radio link establishment /
reconfiguration re-attempt and considers the cell non-capable to flexible
RLC uplink PDU size for this attempt. Based on RRM’s decision L3 also
reconfigures E-DCH MAC-d flow(s) from flexible to fixed RLC uplink
PDU size on all cells of active set, if needed.

If RNC functioning as DRNC receives either RNSAP: RADIO LINK

SETUP REQUEST, RNSAP: RADIO LINK ADDITION REQUEST or
RNSAP: RADIO LINK RECONFIGURATION PREPARE message with
Flexible RLC UL parameters, DRNC rejects the request with cause
value ‘Requested Configuration Not Supported’.

2.3.12 Direct Resource Allocation for HSPA

RAN1762: Direct Resource Allocation for HSPA

HS(D)PA transport channels are directly allocated in the RAB setup

phase in Cell_DCH and Cell_FACH state. Benefit for the operator is
improved end-user experience.

Using this feature, an operator can select if the direct resource allocation
is made for the new entering PS RABs of interactive and background
traffic classes. It means HS(D)PA transport channels are directly
allocated in the RAB setup phase in Cell_DCH state, as shown in figure
below. Operator can also specifically define whether the direct resource
allocation is applied in Cell_FACH state.

Direct resource allocation for HSPA shall be controlled by the parameter

RABDRAEnabled. Parameter defines whether Direct Resource Allocation
for HSPA is used or not. Parameter also defines whether Direct Resource
Allocation for HSPA is used in Cell_FACH state.

Without this feature, the resource allocation for PS-NRT (non-realtime)

RAB is made in two phases - first, GTP tunnel is created and UE
commanded to start traffic volume measurements. Based on capacity

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 174(447)
Basic Call
 Functionality description

request after RAB setup, the radio bearers are reconfigured. This 2 phase
process means call setup (traffic start) delays to the end user, especially if
the user application is ready to start data transfer immediately after
creating PDP context.

DRA shall be supported with both MIMO and DC-HSDPA features when
all prerequisites are met as explained in the respective sections [Link]
and [Link] .

RRC Connection Setup RRC Connection Setup

GPRS Service Request + Security GPRS Service Request + Security

PDP Context Activation Request PDP Context Activation Request

RAB Assignment Request RAB Assignment Request

Radio Bearer Setup 0/0 ( no UP ) Radio Bearer Setup to HSPA (direct)

Radio Bearer Setup Complete Radio Bearer Setup Complete

RAB Assignment Response RAB Assignment Response

PDP Context Activate Accept PDP Context Activate Accept

TVM start/Measurement Control Measurement Control

Measurement Report ( TVM ) HSPA bearer setup for user plane

RB Reconfiguration to HSPA
TVM start if needed

RB Reconfiguration Complete

HSPA bearer setup for user plane

Figure 73 Direct Resource Allocation to HSPA

[Link] Direct Resource Allocation for HS(D)PA in Cell_DCH state

Direct resource allocation for HSPA/HSDPA shall applied in Cell_DCH

state if RABDRAEnabled parameter is set "Enabled in Cell_DCH" or
"Enabled in Cell_FACH and Cell_DCH". See following signalling diagram
about establishment of the PS NRT RAB with DRA in Cell_DCH.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 175(447)
Basic Call
 Functionality description

UE Node - B RNC CN

Signalling link established and UE in Cell_DCH state

_

RANAP : RAB ASSIGNMENT REQUEST [ for PS HSPA NRT ]

HSPA/HSDPA Admission
decision after check for DRA

NPAB : RADIO LINK RECONFIGURATION PREPARE

NPAB : RADIO LINK RECONFIGURATION READY

L 2 resource allocation and Iub transmission setup

GTP tunnel creation

NPAB : RADIO LINK RECONFIGURATION COMMIT

RRC : RADIO BEARER SETUP [ HS - DSCH + E - DCH ]

RRC : RADIO BEARER SETUP COMPLETE

RANAP : RAB ASSIGNMENT RESPONSE

In case of successful DRA , HSPA / HSDPA connection is established for the user plane

Figure 74 Direct Resource Allocation for HS(D)PA in Cell_DCH state

Cell-specific PS and UE-specific PS shall check that HSPA/HSDPA

allocation is possible before DRA for HSPA/HSDPA is attempted. Please
refer to /35/ and /44/ for further details related to admission decision of
HSPA/HSDPA.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 176(447)
Basic Call
 Functionality description

[Link] Direct Resource Allocation for HS(D)PA in Cell_FACH state

Direct resource allocation for HSPA/HSDPA shall applied in Cell_FACH

state if RABDRAEnabled parameter is set "Enabled in Cell_FACH" or
"Enabled in Cell_FACH and Cell_DCH". See following signalling diagram
about establishment of the PS NRT RAB when UE connection is
established and maintained in common channels. See also section 2.3.18
Common Channel setup. See following signalling diagram about
establishment of the PS NRT RAB with DRA in Cell_FACH.

UE Node - B RNC CN

Signalling link established and UE in Cell _ FACH state after Common Channel setup ( RAN 1797 )

RANAP : RAB ASSIGNMENT REQUEST [ for PS HSPA NRT ]

HSPA/HSDPA Admission
decision after check for DRA

NPAB : RADIO LINK SETUP REQUEST

NPAB : RADIO LINK SETUP RESPONSE

L 2 resource allocation and Iub transmission setup

GTP tunnel creation

R R C : R A D I O B E A R E R S E T U P [H S - D S C H + E - D C H ]

R R C : R A D IO B E A R E R S E T U P C O M P L E T E

RANAP : RAB ASSIGNMENT RESPONSE

In case of successful DRA , HSPA connection is established for the user plane

UE in Cell_DCH
state

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 177(447)
Basic Call
 Functionality description

Figure 75 Direct Resource Allocation for HS(D)PA in Cell_FACH state

Cell-specific PS and UE-specific PS shall check that HSPA/HSDPA

allocation is possible before DRA for HSPA/HSDPA is attempted. Please
refer to /35/ and /44/ for further details related to admission decision of
HSPA/HSDPA.

[Link] Direct resource allocation shall be supported for HSPA and HSDPA

Direct resource allocation shall be supported for HSPA and HSDPA. UE

must be HS-DSCH capable for HSDPA and HSDSCH and EDCH capable
for [Link] and/or HSUPA must be enabled in the cell in order to
apply direct resource allocation for HSPA/HSDPA.

RB shall be mapped to HS-DSCH in DL and E-DCH or DCH in UL if the

direct resource allocation is applied. Direct resource allocation is not
applied if DL RB and UL RB both are mapped to Rel 99 DCH.

In case HS(D)PA allocation is not possible due to BTS, TRS or DSP

congestion, no further attempt shall be made and DCH 0/0 shall be
allocated and TVM started as per existing principles.

GTP and User Plane resources for the RAB shall be created
simultaneously during Direct Resource Allocation.

[Link] Direct resource allocation for HSDPA shall have HSDPAInitialBitrateUL

for UL-DCH

If E-DCH allocation is not possible during direct resource allocation, and

cell specific PS tries for UL-DCH/HS-DSCH configuration, then
HSDPAinitialBitrateUL must be used to give the bitrate for UL-DCH.

This UL-DCH bitrate can be modified by capacity requests from UE

[Link] Direct resource allocation shall not be supported for all the RABs in a
multi-RAB request coming in a single RAB ASSIGNMENT REQUEST

Direct resource allocation for HSPA/HSDPA shall not be supported for all
the RABs in multi-RAB scenarios. Direct resource allocation for HSPA
shall be applied to only the highest priority NRT PS RAB if the multi-RAB
request comes in a single RAB ASSIGNMENT REQUEST and only if
HSPAMultiNRTSupport is enabled.

If RANAP: RAB ASSIGNMENT REQUEST contains RT RAB in addition

to the NRT PS RAB, the direct resource allocation for HSPA shall not be
attempted for NRT PS RAB but DCH 0/0 kbps is allocated and TVM
started.

Direct resource allocation for HSPA/HSDPA is supported for a new

second/third NRT RAB if other RABs exists.

<not in ADA3.0/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 178(447)
Basic Call
 Functionality description

[Link] Direct resource allocation for HSPA/HSDPA shall be supported with

HSPA over Iur

If HSPA over Iur feature is enabled and Direct resource allocation for
HSPA/HSDPA is supported, HS-DSCH in downlink and EDCH or DCH in
uplink shall be allocated over Iur-interface during Rab setup phase. If the
serving cell is choosen to be under DRNC, the direct resource allocation
for HSPA/HSDPA shall be same as per user plane creation handling
specified under /HSPA-o-IUR EFS/.

Direct resource allocation for HSPA shall be supported when there are
radio links controlled by the SRNC and DRNC

<not in ADA3.0/end>

[Link] Direct resource allocation shall not trigger channel type switch

Direct resource allocation for HSPA shall not trigger channel type switch
(CTS) to HSPA/HSDPA. If there is an existing RB mapped to DCH/DCH
or AMR on DCH, direct resource allocation for HSPA/HSDPA shall not be
applied which can trigger CTS, DCH 0/0 is allocated and TVM started as
per existing principles.

If an existing SRB is mapped to DCH/DCH, then SRB CTS, if possible by

existing principles is supported during Direct resource allocation.

As AMR + HSPA/HSDPA is supported, Direct Resource allocation for

HSPA/HSDPA shall be supported with AMR on DCH.

If there is an existing RB mappped to DCH/HS-DSCH, direct resource

allocation for HSPA shall not be applied, HSDPA, if possible, is alloacted.
If there is an existing RB mapped to E-DCH/HS-DSCH, direct resource
allocation for HSPA only shall be applied.

[Link] Direct resource allocation during compressed mode

Direct resource allocation for HSPA/HSDPA shall be applied to new RAB

ASSIGNMENT REQUEST during ongoing HSDPA/HSUPA compressed
mode.

In case of DCH [X/Y] compressed mode ongoing, Direct Resource

Allocation shall not be attempted.

2.3.13 PS service reconfiguration

Feature RAN930: PS RAB Reconfiguration

The SGSN or the UE (via SGSN) can request the RAB modification
procedure if there is a need to modify the characteristics of a RAB
service. To the RAN the reconfiguration is triggered by the CN with a
RANAP: RAB ASSIGNMENT REQUEST message requesting
reconfiguration of the existing RAB.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 179(447)
Basic Call
 Functionality description

The following RAB parameters can be changed for the interactive and
background traffic class RABs:

• Traffic class interactive <−> background

• Maximum bit rate (MBR) for UL and DL
• Traffic Handling Priority (THP) of an interactive RAB
• Allocation and Retention Priority (ARP)
• SDU Error Ratio
• Residual Bit Error Ratio
<CRE1428 update/begin>
• UL Transport layer address
<CRE1428 update/end>

Note: Support of SDU Error Ratio and Residual Error Ratio “modification”
added in EFS CR E1262. RNC does not use these parameters and these
parameters are ignored when received. RNC support also RAB
modification procedure if all received RAB parameters are same than
received earlier.

Modifications on PS real time (PS RT) services are not supported.

The RNC shall adapt different handling of RAB modification request

depending on the state of the UE (UE in URA/Cell_PCH, Cell_FACH or
Cell_DCH), type of request (downgrade/upgrade QoS parameter) and
whether UE is using DCH or HSPA service.

1. The RANAP: RAB ASSIGNMENT REQUEST does not initiate paging

procedure in URA/Cell_PCH state when it requests to modify NRT RAB
parameters. The RNC only stores the RAB parameters, and the new
RAB parameters are taken into use when the state transition is made to
Cell_DCH.

2. When UE is in Cell_FACH state the new RAB parameters are taken

into use when the state transition is made from Cell_FACH to Cell_DCH.

3. When UE has a DCH service and the RAB modification requests to

change the QoS priority parameters (THP, ARP, TC), the new
parameters are taken into use immediately inside RNC, but new
parameters are updated to the UE during next reconfiguration message
due to some other reason (e.g. UE state transition). In case of upgrading
the MBR the new parameter is taken into use when the new admission
decision for RRM resources is done.

4. When UE has a HSPA (HS-DSCH/E-DCH or HS-DSCH/DCH) service

or DCH service and the RAB modification requests downgrading the
maximum bit rate, the new RAB parameters are taken into use
immediately.

<CRE1428 update/begin>
5. When the RAB modification requests UL Transport layer address
modification, it is taken into use immediately.
<CRE1428 update/end>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 180(447)
Basic Call
 Functionality description

The RAB Id identifies the RAB to be modified. There can be multiple RAB
Ids in RANAP: RAB ASSIGNMENT REQUEST message.

If the SGSN requests any other parameter modification the RNC sends
the response back to the SGSN using RANAP: RAB Assignment
Response with cause code”Invalid RAB Parameters Combination”.

New QoS parameters are sent to the BTS (and DRNC) by using NBAP
(RNSAP): RADIO LINK RECONFIGURATION PREPARE message, and
to the UE by using RRC: RADIO BEARER RECONFIGURATION
message.

[Link] RAB Modification Handling in Different RRC State

[Link].1 UE in Cell/URA_PCH State

The RRC checks that modification is possible and stores the new
requested QoS parameters, or rejects the modification.

The Paging procedure is not initiated by RANAP: RAB Assignment

Request when it is requesting modification of PS NRT RAB(s).

The new requested QoS parameters are taken into use when UE
executes state transition from Cell_PCH -> Cell_FACH -> Cell_DCH
state.

[Link].2 UE in Cell_FACH State

The RRC checks that modification is possible and stores the new
requested QoS parameters, or rejects the modification.

The new requested QoS parameters are taken into use when UE
executes state transition from Cell_FACH to Cell_DCH state.

[Link].3 UE in Cell_DCH Using DCH Service

The RRC checks that modification is possible and stores the new
requested QoS parameters, or rejects the modification.

The functionality is also valid in case of anchoring.

Note: When UE is using DCH0/0 the RAB Modification is handled as

presented in previous requirement.

Upgrade Case

The RRC stores the new requested QoS parameters and forward these
to BRM. This includes calculating new Frame Handling Priority (FHP)
parameter and forwarding this to the BRM.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 181(447)
Basic Call
 Functionality description

The new requested MBR parameter checking is done in RRC and if it is

higher than current MBR and UE is already using current max bit rate.
New buffer payload values are send to UE using RRC: MEASUREMENT
CONTROL message.

The new Qos parameters are taken into use immediately when CN has
requested to modify THP, ARP or TC.

When the MBR should be upgraded the capacity request initiates new
RRM resource request in which the new modified MBR parameter is
taken into use. The RRC sends the capacity request to BRM and waits
for the response. After successful response the RRC initiates the RL
Reconfiguration procedure to modify the BTS configuration.

The checking is done if the Transport Layer reconfiguration is needed.

The RRC sends the relevant parameters to the NRM which indicates if
the AAL2/IP modification is needed. If it is needed the DRNC is also
reconfigured. In bit rate changes the DRNC is always updated also.

When needed, the L3 shall send the TC to NRM so the u-plane of the
connection can be reconfigured.

The UE is configured using RRC: RB RECONFIGURATION message

where the LOGICAL CHANNEL PRIORITY parameter is sent.

When UE is using AMR + NRT 0/0 the modification procedure

functionality presented here is valid.

Downgrade Case

The RRC sends the request of new resources to BRM immediately after
checking the upgrade/downgrade of the modification request. After
successful response the RRC initiates the RL Reconfiguration procedure
to modify the BTS configuration.

The checking is done if the Transport Layer reconfiguration is needed.

The RRC sends the relevant parameters to the NRM which indicates if
the AAL2/IP modification is needed. If it is needed the DRNC is also
reconfigured. In bit rate changes the DRNC is always updated also.

When needed, the L3 shall send the TC to NRM so the u-plane of the
connection can be reconfigured.

The UE is configured using RRC: RB RECONFIGURATION message

where the LOGICAL CHANNEL PRIORITY parameter is sent.

The new requested MBR parameter checking is done in RRC and if it is

lower than current MBR and UE is already using current max bit rate.

New buffer payload values are send to UE using RRC: MEASUREMENT

CONTROL message.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 182(447)
Basic Call
 Functionality description

[Link].4 The UE Using DCH/HSDPA Service

The RRC checks that modification is possible and stores the new
requested QoS parameters, or rejects the modification.

This includes calculating new Frame Handling Priority (FHP) parameter

and forwarding this to the BRM.

Also the checking that BTS is supporting the RAB Modification

functionality is done by BRM.

The RRC sends the request of new resources to BRM immediately after
sending RANAP: RAB ASSIGNMENT RESPONSE message to CN. After
successful response the RRC initiates the RL Reconfiguration procedure
to modify the BTS configuration. The RNC includes to the message SPI,
ARP and NBR (GBR) parameters.

The checking is done if the Transport Layer reconfiguration is needed.

The RRC sends the relevant parameters to the NRM which indicates if
the AAL2/IP modification is needed.

When needed, the L3 shall send the TC, DL peak rate (when DL MBR
has changed) to NRM so the u-plane of the connection can be
reconfigured.

The UE is configured using RRC: RB RECONFIGURATION message

where the LOGICAL CHANNEL PRIORITY parameter is sent.

The new requested MBR parameter checking is done in RRC and if it is

lower/higher than current MBR and UE is already using current max bit
rate. New buffer payload values are send to UE using RRC:
MEASUREMENT CONTROL message. Also the peak rate parameter is
sent to L2.

When the E-DCH configuration is applicable (there are resources and HC

requests that) it shall be done as in current implementation. I.e. DCH to
HSPA reconfiguration.

[Link].5 The UE Using HSUPA/HSDPA Service

The RRC checks that modification is possible and stores the new
requested QoS parameters, or rejects the modification.

This includes calculating new Frame Handling Priority (FHP) parameter

and forwarding this to the BRM.

Also the checking that BTS is supporting the RAB Modification

functionality is done by BRM.

The RRC sends the request of new resources to BRM immediately after
sending RANAP: RAB ASSIGNMENT RESPONSE message to CN. After
successful response the RRC initiates the RL Reconfiguration procedure
to modify the BTS configuration. The RNC includes to the message SPI,
MBR, ARP and NBR (GBR) parameters.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 183(447)
Basic Call
 Functionality description

The checking is done if the Transport Layer reconfiguration is needed.

The RRC sends the relevant parameters to the NRM which indicates if
the AAL2/IP modification is needed.

When needed, the L3 shall send the TC, SPI and DL peak rate (when DL
MBR has changed) to NRM so the u-plane of the connection can be
reconfigured.

The UE is configured using RRC: RB RECONFIGURATION message

where the LOGICAL CHANNEL PRIORITY parameter is sent.

The new requested MBR parameter checking is done in RRC and if it is

lower/higher than current MBR and UE is already using current max bit
rate. New buffer payload values are send to UE using RRC:
MEASUREMENT CONTROL message. Also the peak rate parameter is
sent to L2.

When the E-DCH configuration is applicable (there are resources and HC

requests that) it shall be done as in current implementation. ie. DCH to
HSPA reconfiguration.

<CRE1428 update/begin>

[Link] UL Transport layer address

[Link].1 Modification of UL Transport layer address is controlled just with the

RAN930 license

Modification of UL transport layer address is allowed, if RAN930 feature

is activated based just on RAN930 license.

Additional information:
RAN930 has also WBTS/VBTS- NodeBRABReconfigSupport parameter,
but that is only used with HSUPA/HSDPA configuration to indicate if BTS
supports the needed reconfiguration.
In this UL Transport layer address case BTS (or UE) is not reconfigured
at all, so according of the legacy RAN930 principles that parameter is not
used at all.

[Link].2 Modification of UL Transport layer address is supported

If the RAN930 is activated with the RAN930 license, then information

given in UL Transport Layer Address IE and Iu Transport Association IE
of the RANAP: RAB ASSIGNMENT REQUEST message is taken into
use right away when it is received. The received information is given to
transport layer and RANAP:RAB ASSIGNMENT RESPONSE is sent to
the CN.

UL Transport layer address modification does not depend on used

transport channel type (DCH 0/0, DCH, E-DCH) or RRC state
(modification is done also when data is just buffered).

Additional information:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 184(447)
Basic Call
 Functionality description

Ignoring of GTP error indications is not implemented, because of too

complicated implementation and because there is no information that it
would be really needed.
Handling of UL PDUs is not changed (acking, forwarding, duplicating)
during the modification so that implementation would be kept as simple
as possible. Applications are trusted to handle possible data problems
during the modification.
<CRE1428 update/end>

[Link] Collision and Error Handling

[Link].1 Collision Cases During RAB Modification

Capacity Request
If capacity request is received during ongoing RAB Modification
procedure, an ongoing RAB modification procedure (e.g. radio link
reconfiguration procedure) is completed, and capacity request is handled
after that.

Mobility Management Procedure

Mobility management and handling of branches shall remain the same as
with other reconfiguration procedures in functionality without RAB
modification (parallel procedures are not possible).

Compressed Mode Handling

In case of modifications to RAB parameters TC, THP or ARP the RAB
modification procedure is initiated immediately during compressed mode.

DCH bit rate upgrade or modification of bit rate when using HS-DSCH
during HSPA compressed mode 'ON' must be handled without waiting for
compressed mode completion. In the case of DCH upgrade, wait for
capacity requests is required before processing where as bit rate
modification of HS-DSCH shall be handled immediately.

DCH bit rate downgrade during HSPA compressed mode 'ON' must be
handled immediately without waiting for compressed mode completion.

Note: When HSDAP IFHO feature is activated the UL DCH

Reconfigurations are supported.

Serving Cell Change

Serving Cell Change procedure will not be initiated before RAB
reconfiguration is completed (old Iub connections from the Serving Cell
Change are removed) and vice versa.

[Link].2 RAB Modification Failure

Procedures related to RAB Modification may fail because of RNC internal

failure, BTS sends RL Setup/RL Reconfiguration failure, transmission
modification fails, UE send RB Reconfiguration Failure or some
procedure timer expires. In failure cases the RNC shall keep the
requested RAB parameters (new) and try to take those in next upcoming
situation. This is repeated 3 times.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 185(447)
Basic Call
 Functionality description

In case of retry failure 3 times, RRC should try to revert back to old
configuration and in case RRC is unable to revert back to old
configuration then only RRC should initiate transition to FACH.

If there is a new modification request to the same RAB Id it overrides the

previous one.

[Link].3 RAB Release During RAB Modification

When the RAB release request is received for the same RAB Id which
modification is ongoing. The RAB release takes precedence over the
RAB modification procedure.
Note: In the current implementation modification procedure is completed
and after that RAB release procedure is performed.

[Link].4 Multiple RAB Requests

RAB modification requests for the same RAB in succession. (Same

parameter change / different parameter change) Eg; Req 1 : BR upgrade.
Req 2 : TC change.

• When the modification procedure is ongoing. It is handled first

and then the new one will handled as own separate request.
• When the modification is not ongoing. The new modification is
handled as an own separate request and new parameter are
stored in RNC.

Each request is handled sequentially if the requests are received with the
same RAB Id.

<CRE1428 update/begin>

[Link].5 Collision and error cases are handled during modification of UL

Transport layer address

Multiple RAB reconfiguration requests for one RAB are handled one by
one in that order than they are received. However requests for several
RABs can be handled parallel.

Procedures triggered during UL Transport layer address modification are

not needed to be limited during the UL transport layer address
modification.

L3 does not allow modification of IP version (4<->6). If that is asked, then

modification is rejected (it is unsuccessful).

If the UL transport layer address modification is unsuccessful, then the

RANAP: RAB ASSIGNMENT RESPONSE with cause code =” Invalid
RAB Parameters Combination” is sent to the CN.

Additional information:
RRC makes the IP version check.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 186(447)
Basic Call
 Functionality description

The both ends must have the same IP version and RNC side IP version
cannot be modified and so also remote side IP version cannot be
modified (just the address itself).

<CRE1428 update/end>

2.3.14 Load Based AMR Codec Mode Selection

Feature RAN580: Load Based AMR Codec Mode Selection

With load based AMR codec mode selection feature, the AMR codec
mode is selected for incoming and ongoing AMR calls based on the radio
interface load and Iub/Iur load. AMR codec mode set (5.9, 4.75) is
utilized to admit more voice users or reserve more capacity for data
services in a loaded network.

For incoming AMR calls, when load exceeds a predefined overload

threshold, AMR codec mode set (5.9, 4.75) is used, and when load goes
below the underload threshold, the higher AMR codec modes are used.

For ongoing AMR calls, to avoid changing back and forth between codec
modes, a hysteresis is applied. There are two thresholds: higher and
lower. The difference between the higher and the lower thresholds is the
hysteresis. When load exceeds the higher threshold, the lower AMR
codec mode is used and when load goes below the lower threshold, the
higher AMR codec mode can be applied again. For the ongoing calls, the
AMR codec mode change is applied gradually to avoid sudden signalling
peaks caused by the Radio Link Reconfiguration procedures.

Load based AMR codec mode selection feature is used only for narrow
band AMR calls.

Feature can be used for single AMR calls andfor multi-RAB connections.
Multi-RAB support is added with the EFS CR#715.

DRNC supports load based AMR codec mode selection feature

regardless of the feature activation state of the DRNC.

For more information about this feature, please see Admission Control
FD document.

The following figures illustrate load based AMR codec mode upgrading
and downgrading procedures.
<RAN2578_update/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 187(447)
Basic Call
 Functionality description

UE BTS SRNC MSS/MGW

AMR set (5.90, 4.75) in use

Based on load, RNC decides to

do AMR bitrate upgrade

Message to all NBAP and

RNSAP connections

NBAP:Radio Link Reconfiguration prepare

NBAP:Radio Link Reconfiguration Ready

Iub(/Iur) transport modification

RRC:Transport Channel Reconfiguration

NBAP: Radio Link Reconfiguration Commit

Rate Control
To MSS/MGW

IuUP Rate Control

Rate Control ack

RRC:Transport Channel Reconfiguration Complete

AMR set (12.2, 7.95, 5.90, 4.75) or (12.2, 7.4, 5.90, 4.75) is in use

<RAN2578_update/end>
Figure 61 : AMR codec mode upgrading

<RAN2578_update/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 188(447)
Basic Call
 Functionality description

UE BTS SRNC MSS/MGW

AMR set (12.2, 7.95, 5.90, 4.75) or (12.2, 7.4, 5.90, 4.75) is in use

Based on load, RNC decides to

do AMR bitrate downgrade

IuUP Rate Control

Rate Control ack

Message to all NBAP and

RNSAP connections

NBAP:Radio Link Reconfiguration prepare

NBAP:Radio Link Reconfiguration_Ready

Iub(/Iur) transport modification

RRC:Transport Channel Reconfiguration

NBAP: Radio Link Reconfiguration_Commit

RRC:Transport Channel Reconfiguration Complete

AMR set (5.95, 4.75) in use

<RAN2578_update/end>
Figure 62: AMR codec mode downgrading

Note: Due to pronto “PR NA05451586: Customer Complain for mute and
drop call in mcRNC” a following improvement is done:

Load control in the RNC does not start Load Based AMR downgrade
before CC level CONNECT ACK message is transferred.

For the background, see chapter “Handling of Rate Control Commands

for AMR Uplink”.

<not in ADA3.0/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 189(447)
Basic Call
 Functionality description

2.3.15 RNSAP Radio Link Congestion Control Procedure

RNSAP Radio link congestion procedure is a part of Iur Mobility

Enhancements feature (RAN1759).

With Radio Link Congestion Control Procedure DRNC can indicate

resource congestion to the SRNC. Procedure is indication that the rate of
one or more DCHs, corresponding to one or more radio links, is preferred
to be limited in the UL and/or DL.

Radio Link Congestion control procedures are started in the DRNC when
congestion of following resources occur: downlink power, uplink
interference, downlink spreading code, BTS HW (WSP) or Iub
transmission. Both SRNC and DRNC must participate in the congestion
control procedures during anchoring when congestion situation is
detected in the DRNC cells.

Radio link congestion control procedure is triggered by Pre-emption, RT-

over-RT, RT-over-NRT and PBS when the resources congestion of the
above indicated resources is faced in the DRNC and Overload Control in
case of high interference load.

Radio Link Congestion Control Procedure shall also be supported in the

DRNC during inter-RNC SHO scenarios (when there are some active set
cells in the SRNC).

[Link] Radio Link Congestion procedure in DRNC

RRM of DRNC can ask to reduce the UL or DL (or both) DCH bit rate (see
/15/ Packet Scheduler FD). RRM indicates new maximum bit rate to the
RRC. RRC checks the corresponding TF number and indicates it to the
SRNC in the RNSAP RADIO LINK CONGESTION INDICATION message
in the “Allowed Rate Information” IE. If the same bit rate can’t be found
from TFS, the (TF number of) next smaller bit rate is taken to new
maximum bit rate. Also zero bit rate is allowed (TFI 0) as a new maximum
bit rate.

RRM of DRNC also indicates Congestion cause (UTRAN Dynamic

Resources or UTRAN Semistatic Resources, see 25.423, [Link]). This
cause value is sent from DRNC to SRNC.

Implementation alternative: As SRNC always handles RNSAP Congestion

procedure as "UTRAN Semistatic resources", it's not mandatory to
indicate cause value to RRC/MCC.

DRNC sends RNSAP RADIO LINK CONGESTION INDICATION

message to the SRNC. No need to set procedure timer on L3 (there is
already short timer in RRM). There is no dedicated response message,
but RNSAP Radio Link Reconfiguration Prepare/DCH downgrade/delete
is interpreted as a response message.

Acknowledge is sent to the RRM when RNSAP RADIO LINK

RECONFIGURATION PREPARE/ DCH downgrade/delete is received.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 190(447)
Basic Call
 Functionality description

DRNC does not initiate the RNSAP Congestion procedure during

prepared reconfiguration (RNSAP Radio Link Reconfiguration
Prepare/Commit received, CFN not yet expired).

Note: it’s assumed that congestion cause “UTRAN Dynamic Resources”

doesn’t cause radio link reconfiguration procedure, but DRNC can handle
bit rate changes due to any reason like in the current implementation
without RNSAP Congestion procedure.

[Link] Radio Link Congestion procedure in SRNC

Congestion cause “UTRAN Semistatic Resources”:

When DRNC indicates with the RNSAP RADIO LINK CONGESTION

INDICATION message that bit rate of DCH should be downgraded with
congestion cause “UTRAN Semistatic Resources”, the new maximum bit
rate is informed to the RRM. After acknowledge from RRM is received,
then normal DCH downgrade procedure is used. No changes to the
current functionality.

If new maximum bit rate is zero for both direction, then the whole DCH is
deleted.

Traffic volume measurements are handled normally. New UL/DL capacity

request can cause bit rate updating like in the current implementation.

Congestion cause “UTRAN Dynamic Resources”:

SRNC handles this like “UTRAN Semistatic Resources” cause value.

Rationale:

Handling could be like this for "UTRAN Dynamic Resources" cause, but
this is not required/needed to implement:

UL congestion: RRC Transport Channel Combination Control is sent to

the UE

DL congestion: Bit rate downgrading message is sent to the RNC MAC.

Note: Current assumption is that SRNC always handled congestion as

“UTRAN Semistatic Resources”, although “UTRAN Dynamic resources”
would be received. It means that RNSAP, NBAP and RRC reconfiguration
procedures are always performed.

[Link] RNSAP Congestion failure

Radio link reconfiguration procedure due to DRNC congestion is handled

as normal DCH reconfiguration procedure. In all failure situations current
(implementation without congestion procedure) failure handling is valid.
No changes to the current implementation due to congestion failure.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 191(447)
Basic Call
 Functionality description

2.3.16 RNSAP Radio Link Pre-emption procedure

RNSAP Radio link pre-emption procedure is a part of Iur Mobility

Enhancements feature (RAN1759).

With RNSAP RADIO LINK PREEMPTION REQUIRED INDICATION

message DRNC can ask SRNC to release radio link due to some
congestion situation (see /15/ Packet Scheduler FD).

[Link] RNSAP Radio Link Pre-emption procedure in DRNC

RRM of DRNC can ask to release radio link which is allocated from
SRNC. RRC sends RNSAP RADIO LINK PREEMPTION REQUIRED
INDICATION with the appropriate radio link id to the SRNC normally via
IUR.

Note: There is already defined short timer in RRM part. Releasing of UE

resources can take longer than RRM internal timer, but it does not cause
problem, possible extra pre-emption, because RRM may initiate an
another pre-emption before previous one is completed.

[Link] RNSAP Radio Link Pre-emption procedure in SRNC

Basic principle is, that all pre-emption requests from DRNC are accepted
and processing is started immediately. The only exception is that pre-
emption causes release a CS RAB which is “not pre-emptable” (see
3GPP TS 25.413 Pre-emption Vulnerability). In this case the whole pre-
emption request is ignored.

If there are more than one radio links in the current active set, the
required radio link(s) is removed from current active set by using RRC
Active Set Update message. RNSAP/NBAP Radio Link Deletion Request
shall be sent when L2 acknowledge is received from RLC (RFUTOR).

Note: This is line with current implementation. RNC has no time to wait
RRC Active Set Update Complete.

If the whole call must be released (all radio links in the current active set
must be released):

• UE with CS-only service => Iu Release Request is sent to the CS-

CN (cause: RAB Pre-empted (1)) and RRC Connection Release is
sent to the UE at the same time than Iu Release request.
RNSAP/NBAP Radio Link Deletion is sent when first RRC
Connection release repetition timer expires.

Note: CS CN may send some other messages than RANAP Iu

Release Command (e.g. RANAP Direct Transfer). In this case
those other messages must be ignored by RNC.

Note: As NBAP/RNSAP radio links are deleted, RNC can release

all resources after NBAP/RNSAP Radio Link Deletion
response(s) are received. No need to wait RRC Connection
Release Complete.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 192(447)
Basic Call
 Functionality description

• UE with PS-only service => UE is moved to Cell_FACH state.

RNSAP/NBAP Radio Link Deletion Request shall be sent when L2
acknowledge is received from RLC (RFUTOR). Normal
Cell_FACH state handling.

Note: This is also for PS RT services.

• UE with CS/PS multi-service => Iu Release Request is sent to the

CS-CN (cause: RAB pre-empted (1)) and the UE is moved to
Cell_FACH state.

Note: It's possible that UE drops (Cell Update or Radio Link failure
received) after removing a cell from active set. This situation is handled
like in the current implementation without RNSAP Pre-emption procedure.
No changes due to RNSAP Radio Link Pre-Emption procedure.

<not in ADA3.0/end>

2.3.17 Asymmetric AMR over Iur

RAN2192 Asymmetric AMR over Iur and in Relocation

RAN2192 provides support for the use asymmetric AMR codec sets in UL
and DL. Without RAN2192 only the symmetric UL/DL AMR codec sets
are supported. Asymmetric codec sets are supported so that the UL
modes form the subset of the DL modes.

Admission control of the DRNC shall accept those asymmetric AMR and
AMR WB codec sets of the radio link established over the Iur for which

• DL AMR mode set equals to one of the AMR mode sets

configured with the management parameters CSAMRModeSET
and CSAMRModeSETWB in the target cells.

• UL AMR mode set is the subset of the DL AMR mode set.

• Maximum AMR mode of the UL set equals to the maximum AMR

mode of the DL set.

Otherwise the admission control of DRNC shall reject the AMR setup with
the RNSAP cause value ‘Requested Configuration not Supported’

Following figure illustrates the signaling flow of the resource request for
the asymmetric AMR codec set of the AMR call established over the Iur.

Asymmetric AMR over Iur will be supported in NSN RNC only in DRNC
role. This feature will be applicable only when Source RNC is not a NSN
RNC.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 193(447)
Basic Call
 Functionality description

UE Node B1 Node B2 DRNC SRNC

NOTE: This Asymmetric AMR codec sets handling applies also to RL Addition and RL Reconfiguration
procedures.

1. RRC: MEASUREMENT REPORT

HC makes HO
decision

2. RNSAP: RADIO LINK SETUP REQUEST

(asymmetric AMR codec sets)

AC will accept also asymmetric

NB or WB AMR code sets

UE specific AC requests Cell specific AC to

allocate dedicated resources according to
received DL AMR codec set.
Radio link setup request is forwarded to
Node B. Asymmetric AMR codec set is
included in RL Setup.

3. NBAP: RADIO LINK SETUP REQUEST

(asymmetric UL and DL Trasport Format Sets)

4. NBAP: RADIO LINK SETUP RESPONSE

5. RNSAP: RADIO LINK SETUP RESPONSE

UE specific AC requests transport and

UP resources for DCH. NOTE:
Transport gets only maximum bit rate
so there is no change in functionality.
UP is set with asymmetric AMR codec
set.

User Plane setup

6. RRC: ACTIVE SET UPDATE

7. RRC: ACTIVE SET UPDATE COMPLETE

8. NBAP: RADIO LINK RESTORE INDICATION

9. RANSAP: RADIO LINK RESTORE INDICATION

Figure 63 AMR resource request received in DRNC from Iur

2.3.18 Common Channel Setup

This feature optimize RRC Connection and call setup times as well as
execution times of state transitions using RRC Connection Setup on CCH
(Cell_FACH).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 194(447)
Basic Call
 Functionality description

RNC makes "CCH versus DCH/HSPA" decision for the signaling link
according to the signaled Establishment Cause. If CCH is selected, the
UE remains in Cell_FACH state, while allowing a later state transition to
Cell_DCH state, if a RT RB setup is requested afterwards. Thus, DCH
related signalling can be avoided totally, if no RB/RL setup.

And if RB/RL setup is needed later (for establish a RAB), then it can be
done unsynchronized (avoiding idle waiting for the elapse of the
Activation Time). That saves a call proceeding time a lot.

[Link] RRC Connection Procedures on CCH

The same procedures are used as described in RRC connection

procedures chapter [Link] with some modifications related to common
channels usage. These modifications are descriped in following chapters.

[Link].1 RRC Connection Request prefers CCH

Whenever the RNC receives RRC: RRC CONNECTION REQUEST

message on the PRACH/RACH/CCCH, it makes "CCH versus
DCH/HSPA" decision for the signaling link according to the signaled
Establishment Cause and UE release version, taking into account some
internal and external measurements of load and current radio conditions.

<CRE1298/begin>

Exception: When E-UTRA capabilities are requested from the UE

during RRC connection setup:

If the legacy algorithm selects common channels for RRC connection

setup but HS-RACH cannot be used, then the dedicated channels in
setup are selected instead (see chapter [Link]).

<CRE1298/end>

In case of Establishment cause value in RRC: RRC CONNECTION

REQUEST message is “Emergency Call”, RRC L3 sends this information
to L2 MAC-c SW for the top priority scheduling of the RRC: RRC
CONNECTION SETUP message. See chapter [Link].1.

Note: Common channels are not used for emergency calls.

Detection of BTS generated (not UE generated) duplicates in RRC/RRB

The same as previous. See chapter [Link].1.

Buffering/discarding of the repeated RRC connection requests received

from the same UE

The same as previous. See chapter [Link].1.

Proceeding with the (first) RRC connection Request on common channels

If the RRC Connection setup procedure on CCH is selected, the UE

remains in Cell_FACH state for e.g. Establishment Causes in RRC: RRC

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 195(447)
Basic Call
 Functionality description

CONNECTION REQUEST message is not requiring a RB setup

procedure (like e.g. Registration or SMS) usage.

Thus, DCH related signalling can be avoided totally, if no RB setup. And

if/when RB/RL setup is done later (sub-sequent) state transition to
Cell_DCH state (for establish a RAB), then setup can be done with
unsynchronized procedure (without AT).

Coming RRC: RRC CONNECTION REQUEST message (RACH)

contains Information from UE about; e.g. call Establishment Cause,
Measured Results On RACH (CPICH Ec/N0) and the access stratum
release Indicator of UE.

The MCC shall be created immediately after RRC: RRC CONNECTION

REQUEST message is received from the UE and RRC/RRB has selected
the ICSU unit (own unit preferred, otherwise "less loaded unit").

The MCC got also internal measurements results concerning FACH load
(measured by MAC-c/sh) and RACH load (measured by BTS).

After that the Handover Control is started and resource manager has
given new S-RNTI/C-RNTI value for the common channel connection.

The UE specifig Admission control in RRC entity (MCC) is checking of

external (EcNo) and internal (RACH/FACH load) measurement results
against thresholds defined by RNP parameters;
CPICHEcNoSRBMapRRC 2.7.6, RachLoadThresholdCCH,
FachLoadThresholdCCH, PtxThresholdCCH, SRBBitRateRRCSetupEC
2.7.4, SRBMapRRCSetupEC 2.7.3 and RRCSetupCCHEnabledR99
2.7.5. And it makes decision about usage of the common channels.

SRBMapRRCSetupEC parameter defines the Establishment Cause (EC)

values which prefer SRB mapping to the common channels (CCH) in the
RRC connection setup procedure.

<CRE1298/begin>

By default dedicated channels are used always when LTE band

capabilities need to be requested from a UE during RRC connection
setup and SRBs in UL direction cannot be mapped to HS-RACH. In that
case SRBMapRRCSetupEC parameter is ignored.

<CRE1298/end>

Following (bold) causes are preferred as default settings for SRB

mapping on CCH:

Originating conversational call,

Originating streaming call,
Originating interactive call,
Originating background call,
Originating subscribed traffic call,
Terminating conversational call,
Terminating streaming call,
Terminating interactive call,

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 196(447)
Basic Call
 Functionality description

Terminating background call,

*Emergency call, 'always constant value 0'
Inter-RAT cell re-selection,
Inter-RAT cell change order,
Registration,
Detach,
Originating high priority signalling,
Originating low priority signalling,
Call re-establishment,
Terminating high priority signalling,
Terminating low priority signalling,
Terminating cause unknown,
MBMS reception,
MBMS ptp RB request

MCC asks allocation of the new S-RNTI from resource manager (RC3).
After RC3 has given new S-RNTI value for the common channel
connection, MCC asks transport resources.

Note: In case of Establishment cause value is “Emergency Call”, common

channels are NOT used.

[Link].2 RRC Connection Setup to CCH

After acknowledments got from transport resource manager (NRM)

(about SL resources), the MCC (RRB) generate an response to UE and
RRC: RRC CONNECTION SETUP message is sent over the FACH. The
message is sent via the logical channel CCCH using UM RLC and start
timers T_RRC_Resp_CCH, RRCconnRepTimer1 and
RRCconnRepTimer2 in order to configure the UE side resources needed
for the establishment of Radio Link and CCCH.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 197(447)
Basic Call
 Functionality description

Following figure illustrates the RRC Connection Establishment procedure

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 198(447)
Basic Call
 Functionality description

on common channels.
RRC Connection setup on CCH
Summary : If the RNP config for this Est . Cause , load on CCH , UE rel . and signalled
propagation conditions allow setup on CCH , the setup the TVM in RNC and UE and wait for the
outcome of NAS signaling

UE Node -B RNC CN

TM CCCH : RRC Connection Request

[ Establishment Cause , load on CCH , UE rel . and signalled
] RNC allocates the C - RNTI ,
establishes the RRC connection
on RACH / FACH and waits for RRC
Conn . Setup Complete from the UE .

UM CCCH : RRC Connection Setup

- In Rel . 7 no DefConfg on CCH exists , so explicit
[ RRC State Indicator : Cell _ FACH ] configuration is needed
UE in Cell _ FACH state - SRB 4 is established
- UE Capability Required
RRC : Initial UE Message
[1st NAS -message from UE ] RANAP : Initial Direct Transfer

AM DCCH : RRC Connection Setup Complete

RRC Connection established

load supervision of FACH and RACH ongoing

NAS signaling connection ; UE - CN signaling continued ...

RRC Connection Release

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 199(447)
Basic Call
 Functionality description

Figure 64 RRC connection establishments on CCH

Note: The RRC: CONNECTION SETUP message is delivered

transparently over the Iub interface.

This message contains Initial UE identifier (e.g. TMSI + LAI), new U-

RNTI, new C-RNTI, RRC state ‘Cell_FACH’, signalling RB info, Transport
Format Set, Transport Format Combination Set, Uplink Scrambling code,
Downlink Channelization code, Power Control Information.

The MCC shall use the follwing NSN-optimized settings for SRBs set up on CCH:

>>pollingInfo RB1: N/A, RB2-RB3: as below

>>>TimerPoll RB2-RB3: 1000
>>>PollPDU RB2-RB3: n/a
>>>PollSDU RB2-RB3: 1
>>>lastTransmissionPDU-Poll RB2-RB3: FALSE
>>>lastRetransmissionPDU-Poll RB2-RB3: TRUE
>>>PollWindow RB2-RB3: 99
>>segmentationIndication RB1-RB3: N/A
>dl-RLC-Mode RB1: UM, RB2-RB3: AM
>>dl-RLC-PDU-size RB2-RB3: OctetModeRLC-SizeInfoType1: 16
>>inSequenceDelivery RB1: N/A, RB2-RB3: TRUE
>>receivingWindowSize RB1: N/A, RB2-RB3: 64
>>dl-RLC-StatusInfo RB1: N/A, RB2-RB3: as below
>>>timerStatusProhibit RB2-RB3: Not used
>>>missingPDU-Indicator RB2-RB3: TRUE
>>segmentationIndication RB1-RB3: N/A
>>dl-UM-RLC-LI-size 7
rlc-OneSidedReEst FALSE

Only the RACH/FACH related mappings (no dual mapping, DCH/HSPA

related mappings are needed) shall be provided to UE during the RRC
Connection Setup on CCH. Dual mapping (option1: DCH or HSPA,
option2: R/FACH) will be provided later during the subsequent RB setup
if/when UE transferred to Cell_DCH state.

For UEs with Rel7 or lower the RNC entity (MCC) shall provide explicit
configuration (which initiates the radio bearer, transport channel and
physical channel configuration in accordance with the received radio
bearer, transport channel and physical channel information elements) in
subsequent RRC Connection Setup message.

Note: Up to Rel.7 no Default Configurations on CCH are provided by the

3GPP RRC specification TS25.331

Redirection of RRC connection setup

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 200(447)
Basic Call
 Functionality description

RRC Connection Setup on CCH shall not be used for the RRC connection
setup redirection (DRRC) or HSDPA layering for UEs in common
channels (HSUECC). For these (DRRC and HSUECC) the connection
setup is always done using DCH or HSPA.

Editor Note: The RRC spec TS25.331 does not allow to redirect UE to
other frequency, indicate the exact cell and request UE to stay on CCH.

RRC connection setup retransmission procedure in RNC

The same as previous. See chapter [Link].2.

[Link].3 RRC Connection Setup Complete on CCH

The UE transmits an acknowledgement to the RNC with RRC: RRC

CONNECTION SETUP COMPLETE message.

When the RNC receives RRC: RRC CONNECTION SETUP COMPLETE

message, the RNC shall register the UE to RRC connected mode and the
establishment procedure is completed.

In this case UE is kept in Cell_FACH state, waiting a RAB assignment.

Once the UE has established the RRC connection, it may then send a
higher layer NAS messages (e.g. a Security messages).

The RNC shall store the UE radio access capability information in the
database. The capabilities are stored in the MCC for the duration of the
RRC connection.

[Link].4 RRC Connection Release on CCH

The same as previous. See chapter [Link].4

2.3.19 24 kbps paging channel

RAN1202: 24 kbps Paging Channel

The aim of 24 kbps paging channel feature is to enhance the data rate
throughput of the paging channel. Without 24 kbps paging channel
feature bit rate of paging channel is 8 kbps. This feature makes possible
to reduce congestion in RAN when the number of subscribers and call
attempts are increasing.

Bit rate increasing is achieved by using 240 bits transport block size
(instead of 80 bits with 8 kbps PCH) with 10 ms transmission time
interval.

Operator can use the parameter PCH24kbpsEnabled to enable or disable

24 kbps Paging Channel feature. Parameter is effective in Cell level and
can be modified on cell locking.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 201(447)
Basic Call
 Functionality description

• If the value is set to Disabled (0) the Paging channel is configured

with 8 kbps capacity.

• If the value is set to Enabled (1) the Paging channel is configured

with 24 kbps capacity.

With 24 kbps paging channel, paging channel has to be mapped to

separate Secondary Common Control Physical Channel (SCCPCH).

This means that when 24kbps PCH is activated (licensed and enabled)
there must be at least 2 SCCPCHs used in the cell.

The number of SCCPCHs in a cell is defined by cell level

'NbrofSCCPCHs' parameter.

With the activation of 24 kbps paging channel feature, the minimum value
of 'NbrofSCCPCHs' shall be enhanced to 2. Prior to 24 kbps paging
channel, this minimum value was equal to 1.

When 24 Kbps PCH is added, 15 codes for HSDPA or 2ms TTI for
HSUPA cannot be used because there are not enough codes available.
Using 14 codes for HSDPA and 2ms TTI for HSUPA is possible.

Separate SCCPCH for 24kbps PCH

With 24kbps PCH, PCH has to be mapped to separate SCCPCH.

This means that when 24kbps PCH is activated there must be atleast 2
SCCPCHs supported in the cell.

When 24kbps is enabled and SAB is not, the common channels are
mapped the following way

• PCH in a dedicated SCCPCH

• FACH-C, FACH-U in other dedicated SCCPCH

When both 24kbps paging channel and SAB are enabled, the common
channels are mapped the following way

• PCH in a dedicated SCCPCH

• FACH-C/C and FACH-U (SCCPCH-connect) in other dedicated

SCCPCH

• FACH-C/I and FACH-S (SCCPCH-idle) in yet other dedicated

SCCPCH

The number of SCCPCHs in a cell is defined by cell level

'NbrofSCCPCHs' parameter.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 202(447)
Basic Call
 Functionality description

L3/RRA reads which paging channel bit rate is used (parameters

‘PCH24kbpsEnabled’ and ‘NbrofSCCPCHs’). No need to read feature
license by L3 SW.

If 24 kbps is activated, L3 reads set of 24 kpbs related parameters and

use that for PCH channel setup. Otherwise, no changes related to 8 kbps
paging channel.

2.3.20 GTP Error Indication cause value

RAN1840 RRM and Telecom Agreed Corrections and Additions for RU20

(PR 43404ESPE02: RNC uses a wrong cause value when GTP Error
Indication is received.)

3GPP rel7 25.413/23.060 defines the specific cause value for situations
when GTP level error indication is received by RNC. In these cases RNC
initiates RAB Release Request procedure with the cause value "GTP
Resources Unavailable(263)".

When RNC receives a GTP level Error Indication message, RNC sends
RANAP RAB Release Request message with cause value GTP
Resources Unavailable(263).

Rationale : In the older releases an other cause value is used in this

situation. 3GPP rel7 25.413 introduce new cause value for 3GPP Direct
Tunnel feature.

Note that new cause value is "Radio Network Layer Cause Extension"
cause in RANAP specification.

2.3.21 Maximum bit rate negotiation

RAN1840 RRM and Telecom Agreed Corrections and Additions for RU20

(EFS CR#0336 Maximum bit rate negotiation)

When SGSN indicates in the RANAP RAB Assignment Request message

that maximum bit rate (MBR) negotiation is allowed in RAB setup phase,
RNC indicates maximum bit rate 16 Mbit/s for rel6 and older UEs (if
SGSN indicated maximum bit rate over 16 Mbit/s). For rel7 and newer
UEs RNC does not indicate assigned maximum bit rate.

3GPP RANAP specification defines three options for SGSN to indicate

alternative maximum bit rate:

• 1 (Unspecified): SGSN gives freedom to RNC to decide the MBR

(lower) value (if needed).

o For rel6 and older UEs the assigned maximum bit rate is
16 Mbit/s

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 203(447)
Basic Call
 Functionality description

• 2 (Value range): SGSN indicates minimum and maximum MBR,

RNC chooses value from the range (if needed).

o For rel6 and older UEs the assigned maximum bit rate is
16 Mbit/s

o Note: Because maximum bit rate was over 16 Mbit/s,

allowed is always 16 Mbit/s

• 3 (Discrete values): SGSN sends list of alternative MBR values,

expecting RNC to choose one from the list (if needed).

o For rel6 and older UEs the assigned maximum bit rate is
the highest value which is 16 Mbit/s or smaller.

o If 16 Mbit/s or smaller value is not allowed, then RAB

Assignment is rejected (rel6 or older UE) with cause value
“Requested Maximum Bit Rate not Available(20)”.

If maximum bit rate from SGSN is 16 Mbit/s or smaller (for both

directions), then RNC does not indicate any assigned maximum bit rate.

<CRE1278/begin>

Even if the RAB QoS negotiation has been performed earlier after
reception RANAP:RAB ASSIGNMENT REQUEST or
RANAP:RELOCATION REQUEST message, the UE specific RRC/AC
accepts RAB QoS negotiation indication for maximum bit rate again from
the CN for RAB modification of the same RAB Id (even without changes
to previous request).

<CRE1278/end>

<RAN3220/begin>
2.3.22 CS Voice over HSPA

<Internal/begin>
Note that RAN1689 CS Voice Over HSPA feature is frozen. No new
implementation is made for it and it is not needed to be taken into account when
considering feature interworking issues.
<Internal/end>

RAN1689 CS Voice over HSPA.

During RRC connection Setup procedure UE sends the information of CS

voice over HSPA support in RRC: RRC CONNECTION SETUP
COMPLETE message.

UE support CS voice over HSPA, if

- in Rel7 UE-RadioAccessCapability -> PDCP-Capability ->
reservedForFutureUse is set
OR
- in Rel8 UE-RadioAccessCapability -> PDCP-Capability ->
SupportCSVoiceOverHSPA is set.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 204(447)
Basic Call
 Functionality description

The cell supports MAC-ehs if it is indicated in NBAP:Resourse Status

Indication or in NBAP:Audit Responce messages with HS-DSCH MAC-d
PDU Size Capability IE (Flexible Size Capable). This support is needed
from the serving cell.

Flexible RLC (use of MAC-ehs) is enabled in RNC with the RNC level
RNP parameter FRLCEnabled. If Flexible RLC is not enabled, then CS
voice over HSPA can not be activated (to any cell or to virtual cell).

CS voice can be mapped to HSPA only if all RBs and SRBs of the UE in
question are mapped or can be to HSPA channels (full HSPA
configuration).

The following RAB (with speech CS RAB) combinations where SRBs and
all RBs are mapped to E-DCH/HS-DSCH transport channels are
supported:
- Speech CS RAB
- Speech CS RAB + PS streaming PS RAB
- Speech CS RAB + 1...3 Interactive/Background PS RABs
- Speech CS RAB + PS Streaming PS RAB + 1...3 Interactive/Background
PS RABs

<RAN2578/begin>

CS voice over HSPA is not supported for AMR codec mode set (12.2, 7.4,
5.9, 4.75) i.e. NB-AMR CS call applying AMR codec mode set (12.2, 7.4,
5.9, 4.75) uses only DCH.

<RAN2578/end>

[Link] CS Voice RAB setup

When RNC receives the RANAP: RAB ASSIGNMENT REQUEST

message from CS CN requesting CS Voice call, UE either has only SRBs
or also PS connection(s) in use. If SRBs and/or PS RAB(s) resources are
not mapped on HSPA, CS Voice call request triggers the channel type
switch.

If CS CN requests CS voice call when UE is in Cell_FACH or

Cell/URA_PCH state, radio resources are requested only for SRBs and
AMR. The combined state transition, AMR allocation and radio bearer
setup is done by using RRC: RADIO BEARER SETUP procedure along
with the NBAP: RADIO LINK SETUP procedure, see Packet Data
transfers FD.

When CS voice RAB is setup on HSPA SPI used is conversational and

UP mode indicates support for predefined SDU sizes. Both 2 ms and 10
ms TTI are supported depending on RRM resource allocation decisions
and conveyed to BTS, UE, UP and Transport.

Predefined PDU size(s) and subsequent DDI(s) for the RLC PDU size(s)
are determined by RRM are conveyed to UP and UE. Also Max CS delay

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 205(447)
Basic Call
 Functionality description

info is conveyed to UP and UE which uses this information to determine

the maximum buffering time of the voice frames.

CS voice on HSPA uses UM RLC and these parameters are determined

by RRM and conveyed to UM RLC entity in RNC and in UE. No padding
or segmentation/concatenation is configured to be used in UM RLC.
Length indicator is not used but the ‘Extension bit’ is used to indicate that
a UM PDU contains exactly one complete SDU.

UL AMR rate is set to the maximum AMR mode or AMR-WB mode of the
codec set which RRM has selected depending which mode AMR or AMR-
WB CN has requested. IE belongs to the CS-HSPA information IE in RAB
information for setup IE in RRC: RADIO BEARER SETUP message.

Mappings from the AMR and AMR-WB modes to the values of the IE UL
AMR rate are introduced in /41/ and /42/

Ciphering START value exchange in CS over HSPA RAB setup

CS Voice user data transfer needs to be started immediately after RAB

setup. Therefore “old = latest transmitted” START value is used in
ciphering initializing. RRC sends this “latest transmitted START value” to
Transport Resource Manager (NRM) -> L2/user plane.

UE calculates new START value as before and it is received in RRC:

RADIO BEARER SETUP COMPLETE message. RRC saves this START
value as “latest transmitted START value” and it is to be used in next
needed ciphering initialization, e.g. in channel type switch HSPA -> DCH.

CS voice on HSPA service type determination

RRC entity includes CS voice on HSPA UE capability information in user

plane resource reservation request. This information is used in TRM
(NRM) to formulate the “service type” when requesting the user plane
resource for CS voice over HSPA capable UE.

The idea is to make CS voice on HSPA always possible to be used from

DSP resource point of view. This is done by trying to reserve DSP
resources from DSP that supports CS voice over HSPA.

Note:

In case of multi RAB combination there is possibility that same UE’s

SRBs and RBs can be allocated from different DSP/DMPG so the
assumption here is that CS voice RB on HSPA can be on different
DSP/DMPG than same UE’s other HSPA RBs.

CS voice capable UE:

- Resources are asked for CS voice on HSPA RB -> DSP that

supports CS voice on HSPA is must.
- Resources are asked for CS voice on DCH RB -> DSP that supports
CS voice on HSPA is preferred. (Preferred because CS voice on

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 206(447)
Basic Call
 Functionality description

DCH does not need DSP that supports CS voice on HSPA but the
need changes if channel type switch from DCH -> HSPA occures)
- Resources are asked for other RBs -> DSP is selected based on RB
needs.

Failure cases during RAB assignment request (setup) procedure for

AMR RAB

If resource congestion is occurred and no RRM functionality (e.g. RT over

NRT, see more from /35/ and /44/) has been able to get free resources for
CS voice RAB, RANAP: RAB ASSIGNMENT RESPONSE (failure)
message to the core network is sent with cause value as ‘no resources
available’.

If there is no response for RRC: RADIO BEARER SETUP message

received from the UE, RRC entity cancels all the resource reservations
already made and RANAP: RAB ASSIGNMENT RESPONSE (failure)
message to the core network is sent with cause value as ‘failure in the
radio interface procedure’. RRC entity shall start the RRC connection re-
establishment procedure, see /18/.

If UE sends a failure to RB setup message indicating no support for the

requested configuration (either RRC: RADIO BEARER SETUP FAILURE
or RRC: CELL UPDATE with certain cause values), allocated resources
are reconfigured or deleted and only DCH/DCH resources are requested
and configured for this particular UE.

[Link] CS CN initiated codec modification between AMR and AMR WB in HSPA

configuration

CS CN can initiate the codec change from AMR WB to AMR, or vice

versa, by sending the RANAP: RAB ASSIGNMENT REQUEST
(reconfiguration) message. UE is signaled the information of the new
codec with the NAS synchronization indicator IE received from CS CN, IE
is included in the RAB information to reconfigure of the RRC: RADIO
BEARER RECONFIGURATION message. Because Rel-07 version of
RAB information to reconfigure does not include the IE UL AMR rate, the
maximum mode of the allocated AMR codec set shall be signaled to UE
using the RRC TFC control procedure after the completion of the Radio
bearer reconfiguration procedure. In Rel-08 version of RAB information to
reconfigure this is supported.

[Link] Rate control during CS Voice call on HSPA

Rate control with HSPA configuration and UM mode is handled by UL

AMR rate IE which is used to signal the new max UL AMR mode to UE.
Max UL AMR mode is received from RRM and is conveyed to UE by RRC
entity. In the message RRC: TRANSPORT FORMAT COMBINATION
CONTROL ‘Full transport format combination set’ (no data) in
DPCH/PUSH TFCS in uplink IE shall be used.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 207(447)
Basic Call
 Functionality description

[Link] CS Voice channel type switch (DCH/DCH <-> HSPA)

Channel type switches are triggered by RRM/HA and can be made e.g.
when UE with CS voice mapped on DCH moves to a cell supporting CS
voice over HSPA or vice versa.

Channel type switch DCH <-> HSPA is done by RRC: RADIO BEARER
SETUP message.

The “RAB information for setup IE”, used in the RRC: RADIO BEARER
SETUP message, is extended: For the AMR RAB, the new RB(s) (one
UMD RLC RB for HSPA or three TMD RLC RBs for DCH) is/are
established, and the existing RB(s) for the AMR RAB is/are implicitly
released (one UMD RLC RB for HSPA or three TMD RLC RBs for DCH).

UE does the establishing and releasing if the radio access bearer

identified with the IE "RAB identity" in the IE "RAB info" already exists and
it is a CS domain RAB.

Additionally when channel type is switched from DCH/DCH to HSPA also

“PDCP info” (the IE "PDCP PDU header" in IE “PDCP info” is set to the
value "present") is included into the RRC: RADIO BEARER SETUP
message, allowing the configuration of a PDCP entity for a RAB
connected with the CS domain. PDCP entity is also configured to RNC L2.

IUG/IUE is not needed to be buffered when channel type switch is made

for CS voice RAB.

Ciphering initializing during channel type switch

In case channel type switch is made from DCH to HSPA, Radio Bearer
Identity is needed to be sent to UE in RRC: RADIO BEARER SETUP
message. RB id has to be different from the one used for CS over DCH
RAB in order not to compromise security.

The saved latest transmitted START value is used to initialize ciphering of

CS over HSPA radio bearer. RRC sends this “latest transmitted START
value” along with the new RB id to TRM (NRM) -> L2/user plane. New
configuration is taken into a use when procedure activation time elapses.

UE calculates new START value as before and it is received in RRC:

RADIO BEARER SETUP COMPLETE message. RRC saves this START
value as “latest transmitted START value” and it is to be used in next
needed ciphering initialization, e.g in channel type switch procedure from
HSPA to DCH.

In case the channel type switch is made from HSPA to DCH current "2-
stage" ciphering procedure is used as in TM (CS voice RB mapped on
DCH) radio bearer establishment.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 208(447)
Basic Call
 Functionality description

UE SRNC

The latest transmitted START value = The latest received START value =
STARTcs A STARTcs A

RadioBearerSetup
( CS over DCH )
Calculate a new START value =
STARTcs B

Initialise Count-C with Initialise Count-C with

STARTcs A STARTcs A

RadioBearerSetupComplete
( STARTcs B)

Initialise Count-C with Initialise Count-C with

STARTcs B STARTcs B
at ciphering activation time at ciphering activation time

Incrementing_CountC

RadioBearerSetup

Calculate a new START value = ( CS over HSPA )

STARTcs C is greater than or equal to 20
STARTcs C MSBs of the latest Count C value.

Initialise Count- C with Initialise Count- C with

STARTcs B STARTcs B
RadioBearerSetupComplete
( STRATcs C)

Incrementing_CountC

RadioBearerSetup
( CS over DCH )
Calculate a new START value= STARTcs D is greater than or equal to20
STARTcs D MSBs of the latest Count C value.

Initialise Count- C with Initialise Count- C with

STARTcs C STARTcs C

RadioBearerSetupComplete
( STARTcs D)
Initialise Count-C with The initialised Count- C value is Initialise Count-C with
STARTcs D greater than the one used in the STARTcs D
at ciphering activation time previous CS over DCH time. at ciphering activation time

Incrementing_CountC

RadioBearerSetup
( CS over HSPA )
Calculate a new START value = STARTcs E is greater than or equal to 20
STARTcs E MSBs of the latest Count C value.

Initialise Count- C with The initialised Count- C value is Initialise Count- C with
STARTcs D greater than the one used in the STARTcs D
previous CS over HSPA time.
RadioBearerSetupComplete
( STRATcs E)

Incrementing_CountC

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 209(447)
Basic Call
 Functionality description

Figure 66: Ciphering START value initializing during channel type switch DCH <->
HSPA

<RAN3220/end>

<not in ADA3.0/begin>

2.3.23 Blind IFHO in RAB Setup Phase (RAN2289)

<RAN3093/begin>

The Handover Control checks using RAN3082 Device Detection black-

/whitelist control whether Blind IFHO is allowed for the UE in RAB setup
phase. See chapter 2.3.45 about Device Detection feature.
NOTE: If Blind HO in RAB setup phase functionality is either whitelisted or
blacklisted, then:
• If the IMEI information of the UE is not available during CS RAB
setup, then the use of the functionality Blind HO in RAB setup
phase is allowed for the UE in question.
• If the IMEI information of the UE is not available during PS RAB
setup, then the use of the functionality Blind HO in RAB setup
phase is not allowed for the UE in question.
See /47/ for details of HC functionality.

<RAN3093/end>

With RAN2289 activated the RNC supporst the frequency layer/band and
Node B change during radio bearer setup with unsynchronized
procedures.

Multi-Band Load Balancing is done during RAB setup when

first RAB setup is done for the UE or AMR RAB setup is done for the UE
when it already has a NRT RAB(s). Blind HO is done to other layer when
needed. A blind HO quality criterion is source cell RSCP measurement
from RACH. For Rel-6 or newer UE the quality criterion can be also target
cell RSCP measurement.

Multi-Band Load Balancing selects the most suitable layer (highest

preference score) for the UE based on following information when any of
above described event occurs.

• Preferred layer: Preferred layer is defined based on UE capability

and the service UE is using.
• Band capability: The frequency band can be preferred for UEs
which support that frequency band.
• Low/high RSCP value: When UE reports low RSCP value in
RACH measurement the lower frequency band can be preferred.
When UE reports high RSCP value in RACH measurement the
higher frequency band can be preferred

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 210(447)
Basic Call
 Functionality description

• Load: Load includes load balancing and HSPA load state.

When UE is in Cell_DCH and when RAB setup is requested by core

network the way the blind IFHO is done is controlled by PRFILE
parameter 002:1888 RN60_MAINT_12 . If the parameter is OFF, the blind
IFHO and RB setup shall be done simultaneously with RB Setup
procedure (RRC:RADIO BEARER SETUP). If the parameter is ON, blind
IFHO shall be done first by Reconfiguration procedure and after that RB
setup. Functionality can be separately activated for CS and PS service.

Default value is that the IFHO is done first and then RB setup.

[Link] Successful Use Cases

Below are depicted use cases where layer/band and Node B change is
performed during RAB setup.

The figure below illustrates the signalling flow of the successful layer/band
change during NRT RAB setup with DRA active when UE is moved from
Cell_FACH Cell_DCH state.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 211(447)
Basic Call
 Functionality description

UE Node B1 RNC CN

Signalling link established, UE in Cell_FACH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

HSPA NRT RAB is requested with

DRA feature active, i.e RRC
checks that parameter
RABDRAEnabled is in state
“Enabled in Cell_FACH” or
“Enabled in Cell_FACH and
Enabled in Cell_DCH”

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band
change and allocates the
resources .

NBAP: Radio Link Setup

User Plane Setup

User Plane Setup

RRC: RADIO BEARER SETUP

(Frequency info, Cell_DCH)

UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state

Figure 2.3.23-1 Frequency layer/band change during NRT RB setup,

UE is moved from Cell_FACH to Cell_DCH

The signalling flow below is the for two cases:

• NRT RB is being setup while Direct Resource allocation feature
active.
• NRT RB is being setup while Direct Resource allocation feature
inactive.
The figure below illustrates the signalling flow of the successful layer/band
change during NRT RAB setup with or without DRA feature activation
when UE stays in Cell_DCH state.
PRFILE parameter for using Reconfiguration for IFHO is set to OFF.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 212(447)
Basic Call
 Functionality description

UE Node B1 RNC CN

Signalling link established, UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

NRT RAB without DRA active or HSPA

NRT RAB is requested with DRA feature
active, i.e RRC checks whether the state
of the parameter RABDRAEnabled is
“Enabled in Cell_DCH” or “Enabled in
Cell_FACH and Enabled in Cell_DCH”

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band
change and allocates the
resources .

If NRT RAB with DRA active is

requested
NBAP Radio Link Setup procedure(SRB +RB)

User plane setup

If NRT RAB without DRA active is

requested

NBAP Radio Link Setup procedure(SRB)

User Plane Setup

PRFILE parameter does not allow

PS IFHO with Reconfiguration

RRC: RADIO BEARER SETUP

(Frequency info, Cell_DCH)

UE changes the
frequency
NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

If NRT RAB without DRA active was requested

RRC:MEASUREMENT CONTROL (setup)

(Traffic Volume Measurement)

RRC:MEASUREMENT CONTROL (setup)

UE in new
(Traffic frequency
Volume layer/band in CELL_DCH state
Measurement)

NBAP: Radio Link Deletion

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 213(447)
Basic Call
 Functionality description

Figure 2.3.23-2 Frequency layer/band change during NRT RB setup

with or without DRA active, UE stays in Cell_DCH

The figure below illustrates the signalling flow of the successful

Frequency layer/band change during NRT RB setup with or without Direct
Resource Allocation feature active, UE is Cell_DCH state, PRFILE
parameter for using Reconfiguration for IFHO is set to ON

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 214(447)
Basic Call
 Functionality description

UE Node B1 RNC CN

Signalling link established, UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

NRT RAB without DRA active or HSPA

NRT RAB is requested with DRA feature
active, i.e RRC checks whether the state
of the parameter RABDRAEnabled is
“Enabled in Cell_DCH” or “Enabled in
Cell_FACH and Enabled in Cell_DCH”

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band
change and allocates the
resources .

If NRT RAB with DRA active is

requested
NBAP Radio Link Setup procedure(SRB +RB)

User plane setup

If NRT RAB without DRA active is

requested

NBAP Radio Link Setup procedure(SRB)

User Plane Setup

PRFILE parameter allows PS

IFHO with Reconfiguration

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION

(Frequency info)

UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE

RRC: RADIO BEARER SETUP

( Cell_DCH)

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

If NRT RAB without DRA active was requested

RRC:MEASUREMENT CONTROL (setup)

(Traffic Volume Measurement)

UE in new frequency layer/band in CELL_DCH state

NBAP: Radio Link Deletion

Figure 2.3.23-3 Frequency layer/band change during NRT RB setup

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 215(447)
Basic Call
 Functionality description

with or without DRA active, UE stays in Cell_DCH

The figure below illustrates the signalling flow of the successful layer/band
change during RT RB setup when UE stays in Cell_DCH state. PRFILE
parameter for using Reconfiguration for IFHO is set to ON

UE Node B1 RNC CN

Signalling link established, UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

AMR RAB request

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band
change and allocates the
resources .

NBAP Radio Link Setup procedure(SRB +RB)

User plane setup

User Plane Setup

PRFILE parameter allows IFHO

with Reconfiguration

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION

(Frequency info)
UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE

RRC: RADIO BEARER SETUP

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state

NBAP: Radio Link Deletion

Figure 2.3.23-4 Frequency layer/band change during RT RB setup,

UE stays in Cell_DCH state

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 216(447)
Basic Call
 Functionality description

The figure below illustrates the signalling flow of the successful layer/band
change during RT RB setup when UE stays in Cell_DCH state. PRFILE
parameter for using Reconfiguration for IFHO is set to OFF

UE Node B1 RNC CN

Signalling link established, UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

AMR RAB request

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band
change and allocates the
resources .

NBAP Radio Link Setup procedure(SRB +RB)

User plane setup

User Plane Setup

PRFILE parameter does not allow

IFHO with Reconfiguration

RRC: RADIO BEARER SETUP

(Frequency info)

NBAP:SYNCHRONISATION INDICATION
UE changes the
frequency

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state

NBAP: Radio Link Deletion

Figure 2.3.23-5 Frequency layer/band change during RT RB setup,

UE stays in Cell_DCH state

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 217(447)
Basic Call
 Functionality description

The figure below illustrates the signalling flow of the successful layer/band
and Node B change during NRT RAB setup with DRA active case when
UE is in Cell_FACH state.

UE Node B1 Node B2 RNC CN

RRC connection established through Node B1, UE in Cell_FACH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

HSPA NRT RAB is requested with DRA

feature active, i.e RRC checks whether
the state of the parameter
RABDRAEnabled is “Enabled in
Cell_DCH” or “Enabled in Cell_FACH and
Enabled in Cell_DCH”

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change Node B2 and
allocates the resources .
Changed Node B is indicated to L3

NBAP: Radio Link Setup

User Plane Setup

User Plane Setup

RRC: RADIO BEARER SETUP

(Frequency info, Cell_DCH)

UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state under new Node B

Figure 2.3.23-6 Frequency layer/band and Node B change during

NRT RB setup, UE is moved from Cell_FACH to Cell_DCH

The figure below illustrates the signalling flow of the successful layer/band
and Node B change during NRT RB setup with or without DRA setup
when UE stays in Cell_DCH state. PRFILE parameter for using
Reconfiguration for IFHO is set to OFF.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 218(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RNC CN

Signalling link established through Node B1, UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

NRT RAB without DRA active or HSPA

NRT is requested with DRA feature
active, i.e RRC checks whether the state
of the parameter RABDRAEnabled is
“Enabled in Cell_DCH” or “Enabled in
Cell_FACH and Enabled in Cell_DCH”

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to L3

If NRT RAB with DRA active is

requested
NBAP Radio Link Setup procedure

User plane setup

If NRT RAB without DRA active is

requested

NBAP Radio Link Setup procedure(SRB)

User Plane Setup

RRC: RADIO BEARER SETUP

(Frequency info)

UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONS

If NRT RAB without DRA active was requested

RRC:MEASUREMENT CONTROL (setup)
(Traffic Volume Measurement)

UE in new frequency layer/band in CELL_DCH state

NBAP: Radio Link Deletion

Figure 2.3.23-7 Frequency layer/band and Node B change during

NRT RB setup with DRA active, UE stays in Cell_DCH

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 219(447)
Basic Call
 Functionality description

Below is the signaling flow of the case that UE has an existing NRT RAB
and is in Cell_FACH state when AMR RAB Assignment Request is
received. Frequency layer/band and Node B change is performed. NRT
RB is reconfigured.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 220(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RNC CN

RRC Connection through Node B1, Common Channel setup is used

Connection to PS-CN, NRT RAB assignment

UE in Cell_FACH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

AMR RAB request from CS CN

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to
L3. NRT RB is reconfigured to the
new layer/band and Node B

NBAP Radio Link Setup procedure(AMR)

User plane setup

User Plane Setup

RB setup is used to reconfigure NRT

RB and setup RT RB

RRC: RADIO BEARER SETUP

(Frequency info, AMR setup, NRT reconfiguration to DCH 0/0)

UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state

Figure 2.3.23-8 Frequency layer/band and Node B change during RT RAB setup
when UE has NRT RB allocated, UE is moved to Cell_DCH state

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 221(447)
Basic Call
 Functionality description

The figure below illustrates the signalling flow of the successful layer/band and Node B
change during RT RB setup when UE stays in Cell_DCH. PRFILE parameter for using
Reconfiguration for IFHO is set to OFF.

UE Node B1 Node B2 RNC CN

Signalling link established through Node B1, UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)
AMR RAB request

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to L3

NBAP Radio Link Setup procedure

User plane setup

User Plane Setup

PRFILE parameter does not allow

IFHO with Reconfiguration

RRC: RADIO BEARER SETUP

(Frequency info)

UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state

NBAP: Radio Link Deletion

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 222(447)
Basic Call
 Functionality description

Figure 2.3.23-9 Frequency layer/band and Node B change during RT RAB setup
when UE has NRT RB allocated, UE stays in Cell_DCH

The figure below illustrates the signalling flow of the successful layer/band and Node B
change during RT RB setup when UE stays in Cell_DCH. PRFILE parameter for using
Reconfiguration for IFHO is set to ON.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 223(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RNC CN

RRC Connection through Node B1

Connection to PS-CN, NRT RAB assignment

UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

AMR RAB request from CS CN

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to
L3. NRT RB is reconfigured to the
new layer/band and Node B

NBAP Radio Link Setup procedure(NRT+

RT setup)

User plane setup

User Plane Setup

PRFILE parameter allows CS

IFHO with Reconfiguration

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION

(Frequency info)

UE changes the
NBAP:SYNCHRONISATION INDICATION
frequency

RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE

RRC: RADIO BEARER SETUP

NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state

NBAP: Radio Link Deletion

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 224(447)
Basic Call
 Functionality description

Figure 2.3.23-10 Frequency layer/band and Node B change during RT RB setup,

UE stays in Cell_DCH
The figure below illustrates the signalling flow of the case when UE has an existing
NRT RAB and is in Cell_FACH state when AMR RAB Assignment Request is received.
Frequency layer/band and Node B change is performed. NRT RB is reconfigured.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 225(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RNC CN

RRC Connection through Node B1, Common Channel setup is used

Connection to PS-CN, NRT RAB assignment

UE in Cell_FACH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

AMR RAB request from CS CN

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to
L3. NRT RB is reconfigured to the
new layer/band and Node B

NBAP Radio Link Setup procedure(AMR)

User plane setup

User Plane Setup

RB setup is used to reconfigure NRT

RB and setup RT RB

RRC: RADIO BEARER SETUP

(Frequency info, AMR setup, NRT reconfiguration to DCH 0/0)

UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state

Figure 2.3.23-11 Frequency layer/band and Node B change during RT RAB setup
when UE has NRT RB allocated, UE stays in Cell_DCH

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 226(447)
Basic Call
 Functionality description

Below is signaling for of frequency layer/band and Node B change during RT RAB
setup, multi RAB case, UE stays in Cell_DCH. PRFILE parameter for using
Reconfiguration for IFHO is set to ON.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 227(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RNC CN

RRC Connection through Node B1

Connection to PS-CN, NRT RAB assignment

UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

AMR RAB request from CS CN

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to
L3. NRT RB is reconfigured to the
new layer/band and Node B

NBAP Radio Link Setup procedure(NRT+

RT setup)

User plane setup

User Plane Setup

PRFILE parameter allows CS

IFHO with Reconfiguration

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION

(Frequency info)

UE changes the
NBAP:SYNCHRONISATION INDICATION
frequency

RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE

RRC: RADIO BEARER SETUP

NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state

NBAP: Radio Link Deletion

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 228(447)
Basic Call
 Functionality description

Figure 2.3.23-12 Frequency layer/band and Node B change during RT RAB setup
when UE has NRT RB allocated, UE stays in Cell_DCH

Below is signaling for of frequency layer/band and Node B change during RT RAB
setup, multi RAB case, UE stays in Cell_DCH. PRFILE parameter for using
Reconfiguration for IFHO is set to OFF.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 229(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RNC CN

RRC Connection through Node B1

Connection to PS-CN, NRT RAB assignment

UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)

AMR RAB request from CS CN

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to
L3. NRT RB is reconfigured to the
new layer/band and Node B

NBAP Radio Link Setup procedure(NRT+

RT setup)

User plane setup

User Plane Setup

PRFILE parameter does not allow

IFHO with Reconfiguration

RRC: RADIO BEARER SETUP

(Frequency info)
UE changes the
frequency

NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

UE in new frequency layer/band in CELL_DCH state

NBAP: Radio Link Deletion

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 230(447)
Basic Call
 Functionality description

Figure 2.3.23-13 Frequency layer/band and Node B change during RT RAB setup
when UE has NRT RB allocated, UE stays in Cell_DCH

[Link].1 Failure handling

The failure handling is as in ‘normal’ RB setup. The exception is when UE

has not been able to adapt the new frequency and sends an RRC: RB
Setup Failure, RB Setup or RB/TrCh/PhyCh Reconfiguration Failure or
Cell_Update message. If no reply to layer change command is received,
RAB assignment is rejected normally with RAB Assignment Response
with failure cause to CN. See also /18/ for failure handling.
There are two cases for failure handling:
1. layering during state change to Cell_DCH
a. Layering is tried with a RB Setup message
b. Failure message is RB Setup Failure or Cell Update
i. it is possible to retry RB Setup without layer change,
see below
ii. If failure cause value matches with one of the causes
mentioned below, the UE permanently marked (until
RRC connection is released) as incapable of doing
frequency layer change, see below

2. layering without state change (initial state Cell_DCH)

a. Layering is tried with a RB Setup or RB/TrCh/PhyCh
Reconfiguration
b. Failure message is RB Setup Failure, RB/TrCh/PhyCh
Reconfiguration or Cell Update
i. Cell_Update:
1. No retrial of RB setup
ii. RB Setup Failure or RB/TrCh/PhyCh Reconfiguration
Failure
1. RB Setup is tried to old frequency

If the layer change was commanded with Radio Bearer, Traffic Channel or
Physical Channel Reconfiguration message, failure is indicated with
corresponding RB/TrCh/PhyCh Reconfiguration Failure or Cell Update
message, see also /18/.
RRC shall forward the failure information to Cell specific entity along with
the saved RT or NRT capacity request (RAB Assignment Request). With
this information Cell specific entity shall avoid allocating the resources
from another frequency layer than the current one.

Marking the UE permanently as incapable of doing frequency layer

change

If the failure message (RB Setup Failure RB/TrCh/PhyCh

Reconfiguration Failure or Cell_Update) includes one of the following
failure causes and the initial state is not Cell_DCH:
• Configuration Unsupported
• Protocol Error
• Invalid configuration

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 231(447)
Basic Call
 Functionality description

Then the RNC shall mark the UE permanently (until RRC connection
is released) as incapable of doing frequency layer change with RB
Reconfiguration procedure.

Using saved capacity request for RB setup

The saved capacity request (RAB Assignment Request) is usable

only when the Failure message comes as answer to the state
transition command with no major delays. E.g. if UE disappears
during the state transition procedure and returns back in service after
the procedure wait timer is expired in RNC and after completing the
RRC:Cell Update procedure sends the RRC:RB Setup Failure
message, Cell specific entity shall not use the saved capacity
request. The procedure that produced the capacity request is already
completed by failure (e.g. RAB assignment failure) when procedure
wait timer expired. If Cell update is received during the procedure
wait time the saved RT or NRT capacity request shall be used.

The figures below illustrate the signaling flow of the unsuccessful

layer/band and Node B change during NRT RAB setup with or without
DRA when UE is moved from Cell_FACH to Cell_DCH..

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 232(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RRC RRM CN

Signalling link established through Node B1, UE in Cell_FACH state

RANAP: RAB ASSINGMENT REQUEST

RAB assignment request from

CN for NRT RAB with DRA or
NRT RABwithout DRA

UL_DL_resource_req

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to L3

resource_req_ack

If NRT RAB with DRA active is

requested
NBAP Radio Link Setup procedure

User plane setup

If NRT RAB without DRA active is

requested

NBAP Radio Link Setup procedure(SRB)

L2 configuration

User Plane establishment

RRC:RADIO BEARER SETUP

(Frequency info, Cell_DCH)

RRC:RADIO BEARER SETUP FAILURE

Figure 2.3.23-14 Unsuccessful frequency layer/band and Node B change during

NRT RB setup with or without DRA active, UE is moved from Cell_FACH to
Cell_DCH. Part 1

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 233(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RRC RRM CN

NBAP Radio Link Deletion

procedure

UP resources released if DRA

is not activet

Failure cause
checking

UL_DL_resource_req
(UE capability, frequency layer change prohibited)

Resource allocation
decision from the
current frequency
layer.
resource_req_ack

NBAP Radio Link Setup procedure

User plane setup

RRC:RADIO BEARER SETUP

NBAP:SYNCHRONISATION INDICATION

RRC:RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSINGMENT RESPONSE

UE in CELL_DCH state

Figure 2.3.23-15 Unsuccessful frequency layer/band and Node B change during

NRT RB setup, UE is moved from Cell_FACH to Cell_DCH. Part 2

The figure below illustrates the signaling flow of the unsuccessful layer/band and Node
B change during RT RAB setup when UE stays in Cell_DCH state. PRFILE parameter
for using Reconfiguration for IFHO is set to ON.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 234(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RRC RRM CN

Signalling link established through Node B1, UE in Cell_DCH state

RANAP: RAB ASSINGMENT REQUEST

RAB assignment request from

CN for RT

UL_DL_resource_req

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to L3

resource_req_ack

NBAP Radio Link Setup procedure

User plane setup

User Plane establishment

PRFILE parameter allows CS

IFHO with Reconfiguration

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION

(Frequency info)

UE tries to change
the frequency

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION FAILURE

Figure 2.3.23-16 Unsuccessful frequency layer/band and Node B change during

RT RB setup, UE stays in Cell_DCH. PRFILE parameter for using Reconfiguration
for IFHO is set to ON, Part 1

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 235(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RRC RRM CN

NBAP Radio Link Deletion

procedure

UP resources released if DRA

is not activet

Failure cause
checking

UL_DL_resource_req
(UE capability, frequency layer change prohibited)

Resource allocation
decision from the
current frequency
layer.
resource_req_ack

NBAP Radio Link Setup procedure

User plane setup

RRC:RADIO BEARER SETUP

NBAP:SYNCHRONISATION INDICATION

RRC:RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSINGMENT RESPONSE

UE in CELL_DCH state

Figure 2.3.23-17 Unsuccessful frequency layer/band and Node B change during

RT RB setup, UE stays in Cell_DCH. PRFILE parameter for using Reconfiguration
for IFHO is set to ON, Part 2

The figure below illustrates the signaling flow of the unsuccessful layer/band and Node
B change during RT RAB setup when UE stays in Cell_DCH state. PRFILE parameter
for using Reconfiguration for IFHO is set to OFF. This is basically normal RB setup
failure case.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 236(447)
Basic Call
 Functionality description

UE Node B1 Node B2 RNC CN

Signalling link established through Node B1, UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

(params)
AMR RAB request

RRM (e.g. HA3 and BRM) makes

the decision of the layer/band and
Node B change to Node B2 and
allocates the resources .
Changed Node B is indicated to L3

NBAP Radio Link Setup procedure

User plane setup

User Plane Setup

PRFILE parameter does not allow

IFHO with Reconfiguration

RRC: RADIO BEARER SETUP

(Frequency info)

UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: RADIO BEARER SETUP FAILURE

Resources are released

RANAP: RAB ASSIGNMENT RESPONSE

(failure cause)

Figure 2.3.23-18 Unsuccessful frequency layer/band and Node B change during

RT RB setup, UE stays in Cell_DCH. PRFILE parameter for using Reconfiguration
for IFHO is set to OFF

<RAN3475/begin>

[Link] Interaction with RAN3475 Buffer-free WCDMA-LTE Refarming feature

Blind IFHO in RAB Setup Phase to the cell which has the RAN3475 Buffer-free
WCDMA-LTE Refarming feature enabled can be restricted depending on the value of
the RNMOBI parameter BFRFunctionalityControl:
• When Bit0 and Bit1 of the parameter BFRFunctionalityControl are set to value
0, the RAN3475 Buffer-free WCDMA-LTE Refarming feature does not restrict
Blind IFHO in RAB Setup Phase.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 237(447)
Basic Call
 Functionality description

• When Bit0 of the BFRFunctionalityControl is set to value 1 (default value), the

handover control shall prevent the Blind IFHO in RAB Setup Phase.

• When Bit1 of the parameter BFRFunctionalityControl is set to value 1 when Bit0

is set to value 0, whether Blind IFHO in RAB Setup Phase is is allowed or not
depends on the value CPICH RSCP measurement result of the source cell. See
Handover Control FD for details.

<RAN3475/end>

<not in ADA3.0/end>

<ADA3.0/begin>

2.3.24 Paging Optimization in I-HSPA

RAN2051: Paging Optimizations.

This feature is applicable only to ADA.

The goal of the feature is to reduce the RANAP Paging load in the
CN(MSC/SGSN).

In the UMTS network several BTSs are controlled by a single RNC.

Further several such RNCs are served by the MSC and SGSN. In a
typical deployment scenario one LA/RA is served by an RNC. With
the advent of the flat RAN architecture i.e. Integration of the RNC and
BTS functionality in to a single Node (I-BTS), the CN elements
(MSC/SGSN) have to serve many more I-BTSs compared to the RNCs in
the UMTS network.

In the flat RAN architecture , this results in increase of the Paging load in
CN. The Paging Load increase is in multiples of the number of I-BTS
under the LA/RA assuming this LA/RA was covered by single RNC.

This paging load increase will inturn impact the Capacity of the CN
system, as the amount of signaling required with I-HSPA system is more
with this architecture.

The reduction of the Paging load in the CN is achieved by introducing the

concept of the Paging group under one LA/RA. Paging group constitutes
grouping of several I-BTSs. With this a LA/RA is divided in to several
paging groups.

Each Paging Group has one I-BTS configured as Paging Master and
another (different) I-BTS configured as Paging Standby from the
MSC/SGSN [Link] PM & PS is configured with a list of I-
BTS's that form a part of the paging group. The Paging Master and
Paging Standby I-BTSs are connected to all the other I-BTSs part of the
Paging Group through the Iur* interface.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 238(447)
Basic Call
 Functionality description

MT transaction
(CS call, SMS,..)
MSS RAC1: SGSN
LAC1:
I-BTS1, I-BTS2,I-BTS3,… I-BTS100 I-BTS1, I-BTS2,I-BTS3,… I-BTS100

Iu Paging
Paging Group(1)
PG List : I-BTS5,I-BTS2,
I-BTS3,I-BTS4

PM PS
I-BTS1
I-BTS5
PM PM PS
I-BTS(m) I-BTS(…)
Iur* Paging I-BTS6 PS
I-BTS9
Iur* Paging Iur* Paging PGn
PGn
I-BTS2
I-BTS7
I-BTS3 PG1 I-BTS4 I-BTS8 PG2 I-BTS(…) I-BTS(…) I-BTS(100)

RAC1
RAC2 LAC1

PM : Paging Master Location Area : LAC1

PS : Paging Standby PG List : I-BTS1,I-BTS2, Routing Area : RAC1,RAC2
I-BTS3,I-BTS4
PG List : Paging Group List Paging Group : PG1,PG2,PG3

Figure 76: Paging optimization in I-HSPA network

Also, one I-BTS belongs to only one paging group.

The Paging Group information is configured at the CN(MSC/SGSN) along

with the corresponding PM and PS I-BTSs serving the Paging Group.

When MSC/SGSN has to invoke RANAP Paging in the LA/RA, it sends

RANAP:PAGING message only to PM or PS (if PM is down) of all the
paging [Link] receiving the RANAP Paging, the PM/PS I-BTS
distributes the paging message further to all the other I-BTSs part of the
paging group.

In this way the paging load in the CN(MSC/SGSN) is reduced.

In case when both PM & PS of any paging group are down and CN has to
initiate paging procedure in a LA/RA then in such cases CN sends paging
to all the I-BTS's in the paging group whose PM/PS are down and to all
other PM or PS of other groups.

Paging Master/Standby distributes paging messages in paging group by

using existing RNSAP interface between I-BTS's. A new message
RNSAP:IDLE Paging Request is defined to distribute the CN originated
paging message in the paging group over the Iur* interface.

This feature is controlled by a feature specific license. Operator can use

the parameter PagingOptSupport to control the usage of this feature per
Iu interface.

• When the value of this parameter is set to 1(enabled) then for any
RANAP:PAGING message from CN (idle mode paging) on this IU
interface, feature Paging Optimization is used.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 239(447)
Basic Call
 Functionality description

• When the value of this paramater is set to 0(disabled) then for any
RANAP:PAGING message from CN on this IU interface, feature
Paging Optimization is not used.

The Iu feature control paramter is required because in a network it is

possible that there are certain CN elements present without this feature
hence paging optimization cannot be used on those Iu interfaces.

IDLE mode paging distribution in the Paging Group by the

I-BTS
On receipt of the RANAP Paging Message, it is verified whether this MS
is engaged in a RRC Connection with I-BTS. If no RRC Connection for
the MS is found in the I-BTS and Paging Optimzation feature License is
set to ON and parameter PagingOptSupport is set to 1(enabled) for this Iu
interface, then following is done:

• If receiving I-BTS has a paging group configured

(PagingGroupList) and PagingMsgCombEnable is set to false
(0),then invoke paging distribution in the paging group

• If receiving I-BTS does not contain any paging group configuration

(PagingGroupList) then distribute paging in own cells.

If RRC connection for MS is not found in I-BTS and Paging Optimization

feature License is set to ON and parameter PagingOptSupport is set to
0(disabled) for this Iu interface or If Paging Optimization feature license is
set to OFF, then distribute paging message in own cells.

Futher handling of the Paging Message with in a CELL is not changed

due to this feature and is according to section [Link]

A new private RNSAP message IDLE Paging Request is introduced for

distributing the Paging messages to the other I-BTSs in the Paging Group
over the Iur* interface.

If the RRC Connection for the paged UE is found in the I-BTS, then
paging distribution is not invoked and existing connected mode paging
procedure is invoked.

Buffering of RANAP Paging Messages before invoking paging

distribution with in the paging group
To improve the Iur* link utilization and the CPU load, the Paging
Master/Standby I-BTS shall be able to buffer some paging messages
from CN and then combine them into one RNSAP:IDLE Paging Request
message to distribute in the paging group. When several
RANAP:PAGING messages are combined before being distributed in a
paging group the amount of outgoing messages from Paging
Master/Standby would decrease thereby saving the network capacity

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 240(447)
Basic Call
 Functionality description

required to transfer protocol headers. Secondly, with the decrease in rate

of outgoing messages, the CPU utilization also decreases.

The buffering of the RANAP Paging Messages is controlled in the ADA

through the hidden parameter PagingMsgCombEnable flag. The
buffering of the RANAP Paging messages from CN is triggered only when
the rate of paging is above 100 paging/sec and PagingMsgCombEnable
is set to 1(true).

In order to calculate the rate of paging messages from CN a time window

of 5 minutes is used.

The duration of the buffering is controlled through the hidden parameters

PagingMsgBufferTime100 (when rate of paging >=100 and < 200)&
PagingMsgBufferTime200 (when rate of paging >=200). Either
PagingMsgBufferTime100 or PagingMsgBufferTime200 is started based
on the measured paging rate.

Further the number of RANAP Paging messages to be buffered and

combined is controlled through the hidden parameter
MaxNrOfBufferedMsgs.

When the buffered RANAP Paging messages reaches

MaxNrOfBufferedMsgs or if the timer PagingMsgBufferTime100 or
PagingMsgBufferTime200 expires, the buffered RANAP Paging
messages are encoded in a single RNSAP IDLE Paging Request and
distributed to all the I-BTSs part of the configured paging group [Link]
timer PagingMsgBufferTime100 or PagingMsgBufferTime200 is restarted.

The buffering is stopped in the ADA when the rate of the paging reduces
below 100 pagings/sec.

CN originated Paging messages that are to be distributed in the paging

group shall only be buffered. For eg if I-BTS receives a paging message
from CN and it finds that the MS already has an ongoing RRC Connection
with it, then such paging messages would not be buffered.

RNSAP IDLE Paging Request handling at the I-BTS received

over the Iur* interface.
On receiving IDLE PAGING message, the RNSAP entity would check the
current status of License for Paging Optimization feature in its internal
data structures and proceed as follows:

• Case 1. If license is not enabled then ignore the received

message.

• Case 2. If license is enabled then forward all Paging PDU to

RANAP entity handling connectionless services in ADA. The
RANAP entity would then decode the paging message and handle
it as per existing functionality i.e existing paging procedure with
out paging optimization as detained in section [Link]. In case

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 241(447)
Basic Call
 Functionality description

there are multiple number of paging pdu's then RNSAP signalling

entity would break these and forward to RANAP signalling entity.

2.3.25 Domain Specific Access Class restriction

RAN1167: I-HSPA DSAC Restriction for CS Domain

DSAC feature serves to restrict the admission of the Rel6 UEs requesting
for a CS service in a PS only network ( no Iu CS signalling Link). Please
refer to /53/ for details on DSAC. This section will only cover the details
pertaining to the handling of CS service attempt by Rel.5 UEs and below.

When ADA is deployed as PS only networks (ie. where IU-CS Control

plane is not available/disabled), attempts by UE’s (prior to Rel6) to access
CS domain services (perform Location update/ SMS) will not succeed,
and thus PS domain services are also not accessible to UE’s. When UEs
(prior to Rel6) attempt a Location Area Update (LAU), it is rejected by the
I-HSPA RAN in a PS only network(no IuCS signalling link)

If IADA-CSVoiceServiceSupport parameter is set to

‘PS_only_deplyoment’ and DSAC feature license is enabled and UE
sends the LAU with CS-CN, then ADA should reject the LAU with cause
“PLMN NOT ALLOWED (11)” and would initiate RRC connection release
procedure.

<ADA3.0/end>

2.3.26 RAN1905 DC-HSUPA

<RAN1905/begin>

Two adjacent 5 MHz WCDMA carriers are used simultaneously in uplink

for a single UE, increasing both peak and average uplink bit rates.

The feature is part of 3GPP Rel-9. Scheduling grants for UEs are given
independently on both carriers. Combining of the data streams from the
two carriers is done on MAC-is layer in Serving RNC.

3GPP specifications do not allow simultaneous DCH operation and thus

F-DPCH and SRBs on HSPA are required. F-DPCH is not supported over
Iur in RU50 EP1 and thus DC-HSUPA is not supported when one or more
radio links over Iur is configured. DC-HSUPA is defined only with E-DCH
2ms TTI. The same modulation (QPSK or 16QAM) have to used for the
both carriers as defined by 3GPP.

DC-HSUPA in uplink requires DC-HSDPA in downlink.

Only NRT RABs can be mapped on DC-E-DCH. DC-HSUPA is not

supported with RT RABs.

Supporting UEs get maximum 23 Mbps peak bit rates if also RAN1645
HSUPA 16QAM uplink is enabled. Without 16QAM, the maximum peak
rate is 11.5 Mbps. On network level average uplink capacity increases by

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 242(447)
Basic Call
 Functionality description

up to 100% on low loaded networks. Full 100% gain is achieved when

dual cell capable UE is alone in the sector where DC-HSUPA is enabled.
When there are several UEs in the same sector, the gains are directly
depending on the utilization of both sectors.

Maximum total throughput of the all soft handover branches in both

carriers is limited to 46 Mbps.

The distribution of channels between the primary and the secondary

carrier is shown in figure below.

DC-HSUPA physical channel structure

E-DPDCHs
Anchor
carrier
E-DPCCH Of 1 DC-
UL HSUPA
DL - HS-DPCCH
UE
HS-SCCH

HS -HS
PDSCH
- PDSCH DPCCH
E-AGCH
E-RGCH
E-HICH
F-DPCH

E-DPDCHs

E-DPCCH

DL UL
HS-SCCH

HS -PDSCH E-AGCH
DPCCH
E-RGCH
E-HICH secondary
carrier
F-DPCH

Figure 80: Channel Structure of Dual Carrier HSUPA

<Internal/begin>

DC-HSUPA capability is signaled by the UE to the RNC during the RRC Connection
Setup procedure using UE radio access capability IE. BTS indicates its capability to
support DC-HSUPA in the Cell Capability Container of the NBAP:AUDIT RESPONSE
and the NBAP:RESOURCE STATUS INDICATION message.
Following RAB combinations are only supported in MC-HSDPA:
• SRBs on HSPA (2ms)+ Max 3 HSPA NRT , thus using F-DPCH and HSUPA
2ms TTI

DC-HSUPA is supported from 1 up to 3 NRT RABs at the same time. For any other
RAB combination DC-HSUPA is not supported.
DC-HSUPA is configured at the BTS by NBAP:RADIO LINK SETUP REQUEST or
NBAP: RADIO LINK RECONFIGURATION PREPARE. List of NBAP procedures that
are used in DC-HSUPA operations in our system and contain DC-HSUPA specific
parameters is described in /40/NBAP and RNSAP Procedures FD.
DC-HSUPA is configured at the UE by including Uplink secondary cell info FDD IE into
one of the following messages:

• RADIO BEARER SETUP

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 243(447)
Basic Call
 Functionality description

• CELL UPDATE CONFIRM

• RADIO BEARER RELEASE
• RADIO BEARER RECONFIGURE
DC-HSUPA is removed from BTS by NBAP: RADIO LINK RECONFIGURATION
PREPARE where CHOICE removal is selected.
DC-HSUPA is removed from the UE configuration by omitting the Uplink Secondary
Cell Info FDD IE out of the RRC message.

[Link] DC HSUPA signalling figures

The following figure shows an example of DC-HSUPA setting when UE is

in Cell_FACH state when UL (Measurement Report from UE) or DL (RNC
internal message) capacity request is received (legacy functionality).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 244(447)
Basic Call
 Functionality description

UE BTS RNC

UE in (HS-)Cell_FACH state

UL or DL capacity request, criterias

to allocate DC-HSUPA filled.
SRB on HSPA, Flexible RLC UL, 2
MS TTI, DC-HSDPA and DC-
HSUPA to be allocated

Radio Link Setup Request

(DC-HSUPA parameters, DC deactivated)

Radio Link Setup Response

(DC-HSUPA parameters)

Transport setup, IP
or ATM

Radio Bearer Reconfiguration

(DC-HSUPA parameters)

Radio Link Restoration

Radio Bearer Reconfiguration Complete

BTS decides when DC

HSUPA is activated

NBAP: Secondary UL Frequency Update Indication

(Activated)

No actions in RNC
(no SHO branches)
BTS decides when DC
HSUPA is de-activated

NBAP: Secondary UL Frequency Update Indication

(De-Activated)

No actions in RNC
(no SHO branches)

Figure 81, DC-HSUPA setup from Cell_FACH state

The following figure shows an example of DC-HSUPA setting when UE is

in Cell_DCH state (existing NRT RAB mapped to DCH0/0), followed by
setting of second branch to other LCG or BTS and activation of secondary
carrier.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 245(447)
Basic Call
 Functionality description

UE BTS1 BTS2 RNC

UE in Cell_DCH state, NRT RAB mapped to “DCH0/0", SRB mapped on DCH or HSPA

UL or DL capacity request, criterias

to allocate DC-HSUPA filled.
SRB on HSPA, Flexible RLC UL, 2
MS TTI, DC-HSDPA and DC-
HSUPA to be allocated

Radio Link Reconfiguration Prepare

(DC-HSUPA parameters, DC deactivated)

Radio Link Reconfiguration Ready

(DC-HSUPA parameters)

Transport setup, IP or ATM

Radio Link Reconfiguration Commit

Radio Bearer Reconfiguration

(DC-HSUPA parameters)
Radio Bearer Reconfiguration Complete

stop TVM (legacy handling)

New soft handover

branch to BTS2
Measurement Report (HC related)
Radio Link Setup Request

(DC-HSUPA parameters, DC deactivated)

Radio Link Setup Response

(DC-HSUPA parameters)

Active Set Update

(DC-HSUPA parameters)
Active Set Update Confirm

Radio Link Restoration

BTS (serving cell) decides when
DC HSUPA is activated

NBAP: Secondary UL Frequency Update Indication

(Activated)

Indication to other branches.

no other actions in RNC

NBAP: Secondary UL Frequency Report

(Activated)

BTS (serving cell) decides when

DC HSUPA is de-activated

NBAP: Secondary UL Frequency Update Indication

(De-activated)
NBAP: Secondary UL Frequency Report
(De-activated)

Figure 82, DC-HSUPA setup from Cell_DCH state and other branch setup

The following figure shows an example of DC-HSUPA releasing due to RT

RAB setup and then setting again due to RT RAB release. Note that only
one procedure used towards BTS and UE.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 246(447)
Basic Call
 Functionality description

UE BTS RNC

UE in Cell_DCH state, PS NRT RAB mapped to DC-HSUPA

RT RAB setup received from CN. DC

(UL and DL) must be deactivated.

Radio Link Reconfiguration Prepare

(RL on Secondary UL Frequency/Remove, RT setup)

Radio Link Reconfiguration Ready

Transport setup, IP or ATM for RT

Radio Link Reconfiguration Commit

Radio Bearer Setup

(Uplink Secondary Cell Info FDD omitted)

Radio Bearer Setup Complete

RB setup ack to CN.

Later RT RAB release received from CN
Criterias to setup DC filled.

Radio Link Reconfiguration Prepare/RT release/DC UL/DL setup

(DC-HSUPA parameters, DC deactivated)

Radio Link Reconfiguration Ready

(DC-HSUPA parameters)

Radio Bearer Release

(DC-HSUPA parameters)

Radio Link Reconfiguration Commit

Radio Bearer Release Complete

BTS (serving cell) decides when

DC HSUPA is activated

NBAP: Secondary UL Frequency Update Indication

(Activated)

Figure 83, DC-HSUPA release and setup due to RT RAB setup and
release

[Link] 3GPP message modifications

3GPP has modified the following messages due to introduction of DC-

HSUPA feature. More detailed descriptions in chapter below (and in
3GPP rel-9 specifications).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 247(447)
Basic Call
 Functionality description

Note: Chapter numbers before or after message or IE name refers to

3GPP 25.331 (RRC) or 25.433 (NBAP) specifications.

[Link].1 NBAP messages

See /40/NBAP and RNSAP Procedures FD.

[Link].2 RANAP messages

High UL bit rates already supported in RANAP.

[Link].3 RRC messages

New IEs related to second carrier E-DCH added to following messages:

ACTIVE SET UPDATE

•Can be used when UE configuration does not change (except active set
and serving cell)

(PHYSICAL CHANNEL RECONFIGURATION)

•Not used related to DC-HSUPA feature

RADIO BEARER RECONFIGURATION

•Used in all cases (related to DC-HSUPA configuration) except radio

bearer release and radio bearer setup

RADIO BEARER RELEASE

•Used to setup DC-HSUPA when releasing service which denies DC-

HSUPA usage (e.g. RT service)

RADIO BEARER SETUP

•Direct resource allocation and DC-HSUPA deactivation due to RT RAB

setup

RRC CONNECTION REQUEST, no changes, UE capability in RRC

Connection Setup Complete message used.

RRC CONNECTION SETUP COMPLETE

•UE radio access capability (support of DC-HSUPA)

(TRANSPORT CHANNEL RECONFIGURATION)

•Not used related to DC-HSUPA feature

(MEASUREMENT REPORT

•secondary carrier measurments are not used)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 248(447)
Basic Call
 Functionality description

[Link] Setting up DC-HSUPA

When criterias to setup DC-HSUPA are fulfilled (RRM functionality), RNC

sends NBAP RADIO LINK SETUP REQUEST or RADIO LINK
RECONFIGURATION PREPARE message to the BTS to setup DC-
HSUPA. See IEs from /40/NBAP and RNSAP Procedures FD.

Setting the DC-HSUPA to UE shall be made by using following RRC

messages:

radio bearer setup phase (direct resource allocation)

• radio bearer setup

releasing DC-HSUPA preventing RAB

• radio bearer release

DC-HSUPA allocation after cell update (no changes to triggers)

• cell update confirm

all other cases without setup/release RAB

• radio bearer reconfiguration

RRC message parameters:

Uplink secondary cell info FDD ([Link]):

Information Element/Group Need Multi Type and Semantics Version

name reference description
CHOICE Configuration info MP REL-9
>Continue (no data) Uplink REL-9
secondary cell
info
parameters
remain
unchanged.
>New configuration REL-9
>> Secondary serving E-DCH OP Secondary REL-9
cell info serving E-DCH
cell info
[Link]
>>Secondary E-DCH info OP Secondary E- REL-9
common DCH info
common
[Link]
>>Downlink information per OP Downlink REL-9
radio link list on secondary UL information per
frequency radio link list on
secondary UL
frequency
[Link]

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 249(447)
Basic Call
 Functionality description

Choice "Continue" is used (only active set update case) when a new
branch is added without serving cell change. Information from HC (/47/
Handover Control FD).

Choice "New configuration" shall be used in all other cases.

No changes to RRC or NBAP message basic handlings. No new

parameters to RRC response messages.

[Link] Multi-RAB handling

DC-HSUPA is supported from 1 up to 3 NRT RABs at the same time. No

changes to basic Multi NRT RAB handling. When setting up resources for
second (or third) NRT RAB, the same legacy signalling procedures are
used. DC-HSUPA must be allocated to all (active) RABs, if allocated for
one RAB.

Parameters in NBAP RADIO LINK RECONFIGURATION PREPARE

message when allocating DC-HSUPA resources for second or third NRT
RAB:

Choice “Configuration Change” selected.

• Additional E-DCH RL Specific Information To Modify, used if RRM

decides to modify parameters.

o 25.433: Used when an existing E-DCH RL on the

secondary UL frequency is modified.)

o F-DPCH Information, based on RRM decision.

Note: It's possible that no any secondary cell parameters are needed to
modify when setting up second (or third) NRT RAB with redio resources.
In this case "Additional E-DCH Cell Information RL Reconf Prep" is not
sent in the NBAP Radio Link Reconfiguration Prepare message.

[Link] DC-HSUPA removal

DC-HSUPA can be removed (RRM decision) e.g due to RT RAB setup or

adding LCG/BTS without DC-HSUPA support to active set.

Parameters in NBAP RADIO LINK RECONFIGURATION PREPARE

message:

• CHOICE Removal selected.

• No other DC-HSUPA related parameters in this message.

In RT RAB setup phase resources from BTS shall be reserved by using

the same NBAP procedure (both DC-HSUPA removal and resource
allocation for RT RAB are made by using only one NBAP procedure).

The used RRC message shall depend on situation:

• RT RAB setup

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 250(447)
Basic Call
 Functionality description

◼ Radio Bearer Setup is used

• other cases

◼ Radio Bearer reconfiguration is used

DC-HSUPA related parameters in the RRC message to the UE:

- "Uplink Secondary Cell Info FDD" is not included in

the RRC message.

[Link] E-DCH Maximum Bitrate handling

The RNC limits the overall UL bitrate of SHO branches to max 46 Mbps
per RRC connection. The is valid when 16QAM modulation is used for
DC-HSUPA (the overall UL bitrate will never exceed 46 Mbps when
QPSK is used for DC-HSUPA).

The RNC limits the overall UL bitrate of SHO branches by de-activating

the secondary non-serving E-DCH radio links if secondary uplink
frequency is active:

• The RNC de-activates the current secondary non-serving E-DCH

radio links if the (serving) BTS which is controlling the serving E-
DCH RLs has indicated with the NBAP: SECONDARY UL
FREQUENCY UPDATE message that the secondary UL
frequency is active (value of Uu Activation State IE is "Activated").

The RNC returns to the standard activation/de-activation indication

handling after the third soft handover branch has been removed from the
primary/secondary E-DCH active set (or after the branch replacement is
completed in case the maximum size of the active set is two cells).

See more from /47/ Handover Control FD.

Note: Following is implemented, but not used in then current

implementation. Instead secondary carrier of non-serving E-DCH radio
links are de-activated (see above).

When RRM indicates a new E-DCH maximum bit rate(s), it shall be

indicated to the BTS(s) by using synchronized radio link reconfiguration
procedure.

If E-DCH maximum bit rate is the only parameter to be modified (no UE

modification), then RNC shall use activation time "now" by setting the
current CFN to activation time to the Radio Link Reconfiguration Commit
message.

The same activation time shall be used to all LCGs/BTSs.

If modification is needed also to the UE, normal activation time is used.

Note: UL MBR changes are not indicated to UE.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 251(447)
Basic Call
 Functionality description

Rationale : BTS does not support un-synchronized RL reconfiguration

procedure.

[Link] Radio link failure handling

Radio link failure messages from BTS are handled by following way:

• Radio link failure can only occur on primary carrier only-> legacy
handling for both carriers

<Internal/end>

<RAN1905/end>

2.3.27 RAN2108, RAN1263, RAN1742 and RAN1743 – BTS nack to

HSDPA/HSUPA/HSPA resource remove

This contains the following BTS features:

• RAN2108 2RX Rake and Centralized TX Core

• RAN1263 Generic RAKE for HSPA baseband efficiency

• RAN1742 MAC-hs codec split

• RAN1743 Distributed TUP

The RNC effect of these features is the fact that BTS can now reject
HSDPA/HSUPA/HSPA resource removal in certain situations.

General signalling picture of the situation

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 252(447)
Basic Call
 Functionality description

BTS RNC

Operation that causes DCH, MAC-d flow and/or E-DCH

MAC-d flow to be deleted from BTS causing the
remaining resources to be moved to the BTS DCH pool

NBAP: RL RECONFIGURATION PREPARE -

Includes one or more of the following elements:
DCH to del, MAC-d flow to del, E-DCH MAC-d flow to del

BTS can not move the

remaining resources to
BTS DCH pool

NBAP: RL RECONFIGURATION FAILURE RL_Reonf_reattempt_timer

NBAP: RL RECONFIGURATION PREPARE -

Includes one or more of the following elements:
DCH to del, MAC-d flow to del, E-DCH MAC-d flow to del

NBAP: RL RECONFIGURATION READY

If allocation fails again

BTS can not move the

remaining resources to
BTS DCH pool
NBAP: RL RECONFIGURATION FAILURE

New failure handing depending on the case

Figure 79: Handling of RL Reconf Failure in resource removal

[Link] Situations where BTS can reject the removal of E-DCH, HSDPA or HSPA
with Synchronised RL Reconfiguration procedure

Due to BTS DSP resource pool allocation there will be possibility that BTS
will reject removal of resource. This can happen, because the
configuration after the resource removal is such that BTS needs to move
the remaining resource from the current DSP pool (HSPA or HSDPA) to
DCH pool.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 253(447)
Basic Call
 Functionality description

BTS will not reject removal because CE license has been exceeded (the
license is always smaller than the actual HW capability). The BTS
rejection of removal means always that HW resources are not available.

BTS has 15 CEs reserve in each LCG (Local Cell Group) that is not given
to new connections, but used for special purposes for example pool
changes caused by RB release (pool change should be successful
‘always’, if one reconfiguration retry is done by RNC).

The BTS rejection will come without any delay - so BTS will not queue the
removal request.

This is new functionality from RNC point of view, because in past BTS
has never rejected resource removals and now here we define how RNC
(L3 & RRM) will behave in these cases.

In practice the most of actual changes will be in L3 and existing RRM

functionality is used when applicable.

Examples of resources that are in DCH pool when they are the only
resource left in the call:

• pure DCH configuration

• CS voice on HSPA

• SRB only (either on DCH or HSPA or DCH/HSUPA)

In the following picture is described location of RAB combinations with

different transport channel types in CE pools in case of WN7.0 with REL2
HW:

Old HW new HW

DCH pool DCH_hs pool HSPA pool HSDPA pool

Full DCH Full DCH Full HSPA

- E-DCH HS-DSCH parts
- excluding CE optimized case - for SRBs
SRBs DCH + RBs DCH/HS-DSCH
- all DCHs - for all RBs
- also AMR DCH multi RAB SRBs HSUPA + NRT HSPA
- DCH + E-DCH
SRBs HSPA + AMR HSPA
- E-DCH SRBs DCH + RBs HSPA
- CE optimized case - all DCHs + E-DCH
- also AMR DCH multi RAB
Standalone SRBs HSPA
- E-DCH
- CE optimized case

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 254(447)
Basic Call
 Functionality description

Figure 80: Resource pools in BTS rel2 HW

[Link] Example operations that may lead to the rejection from BTS

PS RB inactivity (active -> inactive) with CS voice multiRAB

PS RB release with CS multiRAB (for example PS RB is target for RT-

over-NRT):

• CS voice on HSPA + PS RB(s) on HSPA --> CS voice on HSPA +

PS RB(s) on DCH 0/0

• CS voice on DCH + PS RB(s) on HSPA --> CS voice on DCH +

PS RB(s) on DCH 0/0

Channel type switch HSPA --> DCH or HSPA --> HSDPA:

• With CS multiRAB

• Without CS multirab (covers also MIMO and DC-HSDPA cases)

See [AC FD] for more information about the HSPA --> HSDPA change.

PS RAB release with CS multiRAB (CN initiated):

• CS voice on HSPA + PS RB on HSPA --> CS voice on HSPA

• CS voice on DCH + PS RB on HSPA --> CS voice on DCH

CS RAB setup with PS multiRAB (UE has already PS RAB and CS+PS
multiRAB is not in use):

1) PS RB on HSPA --> CS voice on DCH + PS RB on DCH

2) PS RB on HSPA --> CS voice on DCH + PS RB on HSDPA

3) Covers also MIMO and DC-HSDPA cases

Last RB release:

• SRBs on DCH + RB on HSPA --> SRBs on DCH

• SRBs on HSPA + RB on HSPA --> SRBs on HSPA

This can happen, when standalone SRB can be maintained for the UE.
“Standalone SRB” checking will be done the same way as currently.

PS RAB setup (PS multiRAB not supported on HSPA):

PS RB on HSPA --> PS RB on DCH + PS RB on DCH

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 255(447)
Basic Call
 Functionality description

[Link] Basic principles for handling the BTS pool change cases

- Existing CS RAB will not be released

- Existing RBs of other UEs will not be released

- As previously during the time that BTS response is waited, no other

changes are done to the UE in question are allowed (AS updates,
RAB/RB changes,…)

- CS RAB setup will not be delayed

[Link] Exceptions and special cases

[Link].1 PS RB inactivity (active -> inactive) with CS voice multiRAB in the

case that new activity indication arrives while the RL_Reonf_reattempt_timer is
running.

This can happen for example in following removal cases:

• CS voice on HSPA + PS RB(s) on HSPA --> CS voice on HSPA +

PS RB(s) on DCH 0/0

• CS voice on DCH + PS RB(s) on HSPA --> CS voice on DCH +

PS RB(s) on DCH 0/0

If activity indication is received for PS RAB, the

RL_Reonf_reattempt_timer is taken OFF and the reconfiguration
procedure is cancelled.

[Link].2 PS RAB/connection release with CS multiRAB in the same call (CN

initiated)

This can happen for example in following removal cases:

• CS voice on HSPA + PS RB on HSPA --> CS voice on HSPA

• CS voice on DCH + PS RB on HSPA --> CS voice on DCH

If the repeated removal fails, then L3 shall keep the configuration as it is

both in UE and BTS(es). In the case, there are more than one branch
under different Node b communication contexts, cancel is sent to those
Node b communication contexts that sent positive acknowledgement for
the removal.

There is additional complication here. If configuration can not be changed

(PS RAB/connection released) and as the release has already been
acked towards CN, but in this case release is rejected in radio side (BTS
and never even communicated to the UE) CN can request new PS RAB
setup. Requested PS RAB setup from PS CN during “hanging PS RAB in
BTS & UE” while AMR stays on is rejected.

When AMR/CS voice on HSPA ends also the PS RAB will be released.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 256(447)
Basic Call
 Functionality description

[Link].3 CS RAB setup with PS multiRAB (feature “CS+PS multiRAB” is not in

use)

This can happen for example in case like this:

• PS RB on HSPA --> CS voice on DCH + PS 0/0

RRC shall use “pre-emption” cause code towards RRM that it triggers RT
over NRT, RT over RT or further pre-emption actions as in normal CS
voice congestion case.

Further actions and failure handlings are according to existing RT over

NRT, RT over RT or pre-emption procedure principles.

[Link].4 Last RB release when Standalone SRB remains

This can happen for example in following removal cases:

• SRBs on DCH + RB on HSPA --> SRBs on DCH

• SRBs on HSPA + RB on HSPA --> SRBs on HSPA

If BTS rejects the RL Reconfiguration to remove the last RB, a state

change to Cell_FACH will be executed and the RB is released from the
UE with the state change procedure. So, towards the BTS a RL deletion
will be executed.

[Link].5 PS RAB setup (PS multiRAB not supported on HSPA) and repeated
rejection from BTS

This can happen for example where the original reconfiguration was like
this:

• PS RB on HSPA --> PS RB on DCH + PS RB on DCH

UE will be moved to cell_FACH (RL Deletion signalled to BTS) and when

new capacity request arrives, new DCH setup is attempted with the RB
that triggered the capacity request.

[Link].6 Further handling of the hanging PS RB

In the case there is CTS operation for an UE which has a hanging PS RB,
a re-attempt for the removal of the PS RB can be done in following
manner.

Request the removal of the hanging PS RB from the BTS with NBAP:
RADIO LINK RECONFIGURATION PREPARE and if BTS accepts this,
then reconfigure the PS RB to 0/0 in the UE using RB Setup procedure.

After UE has accepted the CTS along with the PS RB to 0/0 configuration,
RB Release procedure can be run for the 0/0 PS RB.

HHO or Relocation can not be completed with the hanging PS RB, so if

there is a HHO or relocation trigger, it will be rejected with cause value
that indicates hanging PS RB. This will then trigger PS RB release and

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 257(447)
Basic Call
 Functionality description

after it has been completed, HHO or Relocation can be done, if new

request comes.

2.3.28 RAN1645 HSUPA 16 QAM

3GPP Rel-7 introduces 16QAM modulation for HSUPA. HSUPA terminal

category 7 supports 16QAM. 16QAM modulates 4 bits per symbol and
increases the HSUPA peak data rate to 11.5 Mbps. 16QAM is optional
feature for the UE, and the 16QAM capability is signaled to RNC in RRC
Connection Setup Complete.

The maximum theoretical throughput of cat7 terminal is 11.5 Mbps.

Practical throughput achievable with this feature is limited by radio
reception and allowed noise rise:

• Maximum theoretical throughput would require the use of coding

rate close to 1, that is it would require error free reception.
Targeting at error free reception reduces the system efficiency and
capacity. In all practical conditions the throughput will be degraded
if using coding rates close to 1, that is having effectively no error
correction.

• Quality of radio reception depends on aspects such as received

signal strength, radio channel and interference, transmitter and
receiver imperfections.

16QAM increases revenue by providing higher HSUPA peak rate for

subscription differentiation.

The HSUPA 16QAM is not applied in Iur (2ms TTI is not used in Iur). If
SRNC of other vendors requests 2ms TTI (required by HSUPA 16QAM)
the NSN DRNC rejects the request.

The HSUPA 16QAM feature can be used if the features RAN981 HSUPA
5.8 Mbps and RAN1470 HSUPA 2 ms TTI are active in RNC. The RNC
shall verify that these features are in use. Otherwise HSUPA 16QAM shall
not be allowed in RNC.

The RAN1470 HSUPA 2 ms TTI can not be used without CDSP-DH card
in RNC (verified in 2 ms TTI usage criteria). New HW is not required to I-
HSPA and mcRNC.

[Link] UE and Cell level support in BTS

[Link].1 HSUPA 16 QAM Support

The E-DCH category 7 UE supports QPSK and 16QAM /5/. The UE

indication of HSUPA 16QAM support is sent from UE to RNC using RRC:
CONNECTION SETUP COMPLETE message. The RNC shall keep book
of UE indications of HSUPA 16QAM capability on UE basis.

BTS indications of HSUPA 16QAM support on cell basis are sent from
BTS to RNC in Audit Response and Resource Status Indicator messages.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 258(447)
Basic Call
 Functionality description

The RNC shall use the HSUPA 16QAM capability information on cell
basis. The HSUPA 16QAM capability is based on HSUPA 16QAM
Support indication required for HSUPA 16QAM usage.

[Link].2 E-DPCCH power boosting

If the Support for E-DPCCH Power Boosting IE is included to UE radio

access capability IE or in UE radio access capability comp2 IE with value
“TRUE” the RNC shall determine that UE supports E-DPCCH boosting.
Otherwise RNC determines that the UE does not support E-DPCCH
boosting. The RNC shall keep book of UE capability for boosting.

BTS indications of E-DPCCH Power Boosting Capability on cell basis are

sent from BTS to RNC in Audit Response and Resource Status Indicator
messages. The RNC shall keep book and use the E-DPCCH Power
Boosting Capability on cell basis.

[Link].3 E-DPDCH power interpolation

UE indicates the support for E-DPDCH power interpolation by including

“Support for E-DPDCH power interpolation formula” IE to “UE radio
access capability” IE in relevant RRC message. If “Support for E-DPDCH
power interpolation formula” IE is not included then UE does not support
E-DPDCH power interpolation.

BTS is considered to support E-DPDCH power interpolation if BTS is

HSUPA 16QAM capable i.e. if BTS has indicated the support for HSUPA
16QAM.

[Link] 3GPP message modifications

3GPP has modified the following messages due to introduction of HSUPA

16 QAM feature. More detailed descriptions in chapter below (and in
3GPP rel-7 specifications).

[Link].1 NBAP messages

See /40/NBAP and RNSAP Procedures FD.

[Link].2 RRC messages

New IEs are specified /6/ and existing IEs are used to support HSUPA
16QAM within RRC—

1.E-DCH Physical Layer Category Extension IE

1.1in Physical Layer Capability IE
1.1.1in UE Radio Access Capability IE
[Link] in RRC Connection Setup Compete, UE CAPABILITY
INFORMATION and also in SRNS RELOCATION INFO message
[Link] for E-DPCCH Power Boosting IE
2.1in UE radio access capability IE and
2.2in UE radio access capability comp2 IE
[Link] 16QAM settings IE with value for E-AGCH table selection
3.1in UL 16QAM configuration IE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 259(447)
Basic Call
 Functionality description

3.1.1in Active Set Update message

4.E-TFCI table index value
4.1in UL 16QAM configuration IE
4.1.1in Active Set Update message
[Link]-es/e Reset Indicator
5.1in UL 16QAM configuration IE
5.1.1in Active Set Update message
6.E-TFCI table index value
6.1in E-DPDCH info IE
6.2in E-DCH Info IE
[Link] E-TFCI PO value
7.1in E-DPDCH info IE
7.2in E-DCH Info IE
[Link] 16QAM settings IE with value for E-AGCH table selection
8.1in E-DCH Info IE
9.- MAC-es/e Reset Indicator
9.1in E-DCH Info IE
10.E-TFCI Boost Information IE with values for E-TFCI boost and Delta
T2TP
10.1in E-DPCCH Info IE
10.2in E-DCH Info IE
11.E-DPDCH power interpolation value
11.1in E-DPCCH Info IE
11.2in E-DCH Info IE
Note that the E-DPDCH Power Interpolation IE and Reference E-TFCI
Power Offset IE are included as generic functionality (not dependency to
applying HSUPA 16QAM).

E-AGCH table selection information in UL 16QAM settings IE, value

determined according to the parameter EAGCHTable.

Boosting information (ETFCIBoost and Delta T2TP) are included if UE

supports E-DPCCH power boosting and all cells of Active Set are
boosting capable as defined above

E-TFCI boost value defined with parameter ETFCIBoost.

Delta T2TP value defined with parameter DeltaT2TP. If ETFCIBoost is set

to 127 the Delta T2TP IE is not needed, otherwise it is mandatory.

E-TFCI table index value is hard coded for 2ms TTI in RNC indicating the
E-TFCI TB size table 2. Value 2 used in E-TFCI table index IE for HSUPA
16QAM.

In addition to the existing functionality for 16QAM capable bearers a DDI

is configured for UL RLC PDU size of 656 bits.

[Link].3 Local Cell Capability Information from BTS

BTS indications of HSUPA 16QAM support on cell basis are sent from
BTS to RNC in Audit Response and Resource Status Indicator messages.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 260(447)
Basic Call
 Functionality description

The RNC uses the HSUPA 16QAM capability information on cell basis.
The HSUPA 16QAM capability is based on HSUPA 16QAM Support
indication required for HSUPA 16QAM usage.

[Link] Setting up HSUPA 16 QAM

The RNC allows the usage of HSUPA 16QAM in all cells of Active Set if
the following conditions are fulfilled in every cell of Active Set of the UE
mapped on E-DCH:

• HSUPA 16QAM license is available and set ON

• HSUPA 16QAM is enabled in a cell in RNC

• UE is HSUPA 16QAM capable

• Cell of Node B is HSUPA 16QAM capable

• Features required by HSUPA 16QAM are in use

• NRT PS RB is among RBs mapped on E-DCH for the UE

• 2ms TTI is used for radio bearers and 5.8 mbps (2*SF2+2*SF4)
for E-DCH.

• All cells of Active Set are handled by SRNC i.e. drifting is not
allowed

• The UL RLC PDU size of NRT PS RB (NRT interactive or NRT

background) for HSUPA 16QAM is 656

Otherwise the usage of HSUPA 16QAM is not allowed. The connection

can be single or multiRAB.

E-DPCCH power boosting

The RNC indicates the usage of E-DPCCH power boosting to UE and

BTS in all cells of Active Set if the following conditions are fulfilled in every
cell of Active Set of the UE mapped on E-DCH—

• UE supports E-DPCCH power boosting

• Cell of Node B is E-DPCCH power boosting capable

• All cells of Active Set are handled by SRNC i.e. drifting is not
allowed

E-DPDCH power interpolation

The E-DPDCH power interpolation is used in specified HSUPA 2ms and

10ms data rates, when the criteria for E-DPDCH power interpolation
usage are fulfilled. The E-DPDCH power interpolation usage with
specified HSUPA 2ms and 10ms data rates is generic functionality.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 261(447)
Basic Call
 Functionality description

If HSUPA 16QAM is applied the E-DPDCH power interpolation is

considered to be supported and E-DPDCH power interpolation is applied.
Otherwise the support is verified according to following criteria—

• UE has indicated the support for E-DPDCH power interpolation

• BTS is considered to support E-DPDCH power interpolation if BTS

is HSUPA 16QAM capable.

• PRFILE parameter EDPDCHPowerInterUsage is set to value “0”

enabling the usage of E-DPDCH power interpolation. This
parameter is verified for 10msTTI and 2ms TTI QPSK.

• The release of RNC is at least RN6.0, ADA 4.0 or mcRNC1.0.

• The E-DPDCH power interpolation amplitude ratios are defined for

the used maximum allowed symbol rate. For HSUPA 16QAM the
E-DPDCH power interpolation is always used. Please refer to /14/
for more details on related parameters.

• The E-DPDCH power interpolation is used in all cells of E-DCH

Active Set

• If DRNC is present in the E-DCH Active Set list, E-DPDCH power

interpolation shall not be used.

If the usage criteria are fulfilled, the E-DPDCH power interpolation is used
for branches of the EDCH Active Set.

If the criteria are not fulfilled the E-DPDCH power extrapolation /HSUPA
FD/ is used for branches of the EDCH Active Set.

When a change in applying HSUPA 16QAM takes place for E-DCH, i.e.
HSUPA 16QAM is previously applied and after usage criteria verification
HSUPA 16QAM is not applied or vice versa, a MAC reset shall be made
in UE, in BTS and in RNC.

The MAC reset due to change of applying HSUPA 16QAM is indicated to

UE and BTS by setting the MAC-es/e Reset Indicator IE in RRC and
NBAP messages.

RLC one-sided re-establishment in UL shall be done incase only UL RLC

PDU size is to be reconfigured due to applicability of HSUPA 16QAM
feature.

RNC shall inform UE the new UL RLC PDU size in RRC:RADIO BEARER
RECONFIGURATION IEs RB mapping info ->E-DCH->RLC PDU size .
One sided Restablishment is indicated to UE by setting IE RLC info ->
'One sided RLC re-establishment' to TRUE. Also the UL E-DCH info is
sent with new E-DPDCH Info and IE "UL 16QAM settings" is included if
the HSUPA 16QAM is still applicable. After the reconfiguration complete
message is received from UE the Uplink counter synchronisation info ->
START list is sent to L2 via NRM to be used for ciphering and also RRC-
D shall read it to perform integrity check.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 262(447)
Basic Call
 Functionality description

E-DCH Maximum Bitrate is determined and delivered to BTS. The upper

limit of the E-DCH maximum bit rate allows the usage of HSUPA16QAM
11520 kbps.

The MaxTotalUplinkSymbolRate with value "3" corresponds to the

maximum symbol rate 5760 kbps. The maximum symbol rate 5760 kbps
corresponds to the spreading factor set 2*SF2 + 2*SF4 and to maximum
bit rates 5760 kbps with QPSK and to 11520 kbps with 16QAM.

[Link] Activation/de-activation handling

The HSUPA 16QAM criteria shall be verified in following cases:

• During Radio link setup

• When the Active Set is changed

• When 2ms TTI switch to 10 ms TTI takes place

• When user plane is setup for NRT PS RB (NRT interactive or NRT

background).

• When UL Channel switches to E-DCH

When adding a cell to Active Set the reconfiguration of existing RB(s) is

made before including the cell to Active Set. When removing a cell from
Active Set the reconfiguration of remaining RB(s) is made after removing
the cell from Active Set.

If the HSUPA 16QAM has been allowed to NRT PS RB with UL RLC PDU
size 656 and after verification the usage of HSUPA 16QAM is no more
allowed, the RBs are configured to QPSK. Also in case Fixed RLC is in
use in UL, UL RLC PDU size of NRT PS RBs is reconfigured to size 336.
Other RB parameters are determined according to the configuration to be
taken into use.

If the HSUPA 16QAM is allowed, the RB(s) shall be configured so that

HSUPA 16QAM is allowed and UL RLC PDU size of NRT PS RB is 656.
Reconfiguration shall be made to RB(s) if reconfiguration is needed (i.e.
RB(s) has been previously QPSK with UL RLC PDU size 336).

E-DPCCH power boosting

The E-DPCCH power boosting criteria is verified in following cases:

• During Radio link setup

• When the Active Set is changed

• When user plane is setup for NRT PS RB (NRT interactive or NRT

background).

• When UL Channel switches to E-DCH

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 263(447)
Basic Call
 Functionality description

When adding a cell to Active Set the reconfiguration of existing RB(s) is

made before including the cell to Active Set. When removing a cell from
Active Set the reconfiguration of remaining RB(s) is made after removing
the cell from Active Set.

E-DPDCH power interpolation

The usage criteria is verified when the EDCH Active Set update takes place.

2.3.29 PS Conversational QoS for HSPA

<RAN715/begin>

RAN715 PS Conversational QoS for HSPA provides conversational class

services on PS domain. Those include e.g. VoIP calls, video calls (uni
and bidirectional)) and real-time text (hearing and speech impaired). A
conversational traffic class RAB is needed for Real Time Protocol (RTP)
carrying voice or video. Associated Real Time Control Protocol (RTCP)
flow is multiplexed in the same conversational QoS RAB. An interactive
traffic class RAB is needed for the Session Initiation Protocol (SIP), if it
requested by SGSN before conversational traffic class RAB. SIP carries
signalling required for creating, modifying and terminating the call. Both of
these RABs are allocated on HSPA channels at the radio interface. For
the conversational RAB unacknowledged RLC mode (UM RLC) is used.

Conversational traffic class requires that guaranteed bit rate (GBR) is

supported. Admission of a new user can be denied if the guaranteed bit
rate cannot be provided. However, a new conversational user has higher
priority compared to the NRT users. GBR is used in the BTS scheduling.

UEs, which indicate support for enhanced F-DPCH and flexible RLC in
downlink, are supported by this feature. F-DPCH is required for full HSPA
configuration. No indication about support for PS conversational RAB is
received from UE, which means that by default all enhanced F-DPCH and
flexible RLC in downlink capable UEs are assumed to support PS
conversational RAB. Robust header compression (RoHC) support for
RTP/UDP/IP header compression is not mandatory for UE, since operator
has the control to allow PS conversational RAB setup for non RoHC
compliant UEs. When RoHC can be applied (see RAN132 Robust Header
Compression (RoHC)), it is used for RTP/UDP/IP header compression on
PS conversational RB. RTCP packets are not compressed.

The target cell for PS conversational RAB setup must support

conversational service over HSPA. There is a cell level parameter called
PSConvEnabled which is used to enable PS conversational QoS for
HSPA.
Also F-DPCH and CPC must be supported and enabled on the target cell
VoIP does not require CPC, but target cell support is required to limit
testing combinations. CPC capability is not required from UE.

PS conversational RB is not supported on DCH. Admission of a new user

can be denied if HSPA cannot be provided.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 264(447)
Basic Call
 Functionality description

ISHO to GSM is not supported for UE with PS conversational RAB.

SRVCC from WCDMA to WCDMA RAN2566 (change of PS
conversational service to CS conversational service) is not supported by
this feature.

PS conversational RAB modification with RANAP: RAB ASSIGNMENT

REQUEST(reconfiguration) message is not supported. If such a request
is received from SGSN, it is rejected by returning RANAP: RAB
ASSIGNMENT RESPONSE (failure) message with a cause value ‘Invalid
RAB Parameters Combination’.

Internal flow control and congestion control are not applicable for PS
conversational MAC-d flows in DL and UL.

[Link] Impacts on RANAP, RNSAP and NBAP procedures

RANAP

Conversational traffic class is taken into use on PS domain.

Values “speech” and “unknown” on Source Statistics Descriptor (SSD) are
supported for conversational traffic class on PS domain. SSD value
“unknown” refers to video or real-time text service.
PS conversational RAB request is recognized in RNC from TC set as
“conversational” and SSD set as “speech” or “unknown” on the RAB
Parameters IE of RANAP: RAB ASSIGNMENT REQUEST or
RELOCATION REQUEST message.

Values “Symmetric bidirectional”, “Asymmetric unidirectional downlink”,

“Asymmetric unidirectional uplink” and “Asymmetric bidirectional” are
supported for conversational traffic class on PS domain. They are
indicated on RAB Asymmetry Indicator in RAB Parameters IE.
Values “Asymmetric unidirectional downlink” and “Asymmetric
unidirectional uplink” are used for video service.

RNSAP

Branch addition to DRNC is not supported for PS Conversational service.

Requires RAN2221: HSPA+ over Iur.

NBAP

There is no indication from BTS to RNC that BTS SW release supports

PS conversational QoS and that’s why the BTS SW release support has
to be derived indirectly. Derivation is done based on features coming in
the same release (RU40) than PS conversational QoS and if BTS has
indicated to support one of the capabilities listed below, BTS is also
assumed to support PS conversational:

• Multi Cell and MIMO Capability, see DC-HSDPA 84 Mbps in

NBAP and RNSAP Procedures FD

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 265(447)
Basic Call
 Functionality description

• E-DCH MAC-d PDU Size Capability, see HSUPA Flexible RLC in

NBAP and RNSAP Procedures FD

[Link] RAB combinations with PS Conversational RAB

PS conversational RAB is supported only with HSPA transport channels.

All other RABs of the UE need to be mapped on HSPA transport channels
also. SRBs can be mapped on E-DCH/HS-DSCH, E-DCH/DCH or
DCH/DCH (3.4/3.4 kbps). Following new RAB combinations are
supported:
- 1 PS conversational RAB + SRBs
- 1 PS conversational RAB + 1-3 PS NRT RAB (+ SRBs)

If PS conversational RAB establishment is requested by SGSN and UE

has already RT RAB, e.g. CS Voice, the RAB establishment is rejected.
If PS conversational RAB establishment is requested and UE has already
streaming RAB (but no other RT RAB) which can be pre-empted, the pre-
emption is done for streaming RAB and PS conversational RAB is setup.
If RT RAB establishment, e.g. CS Voice, is requested and UE has already
PS conversational RAB, the RAB establishment is rejected if pre-emption
of same user PS conversational RAB is not possible.
If RT RAB establishment is requested for emergency call and UE has
already PS conversational RAB that can be pre-empted, the pre-emption
is done for PS conversational RAB and emergency call is setup as PS
conversational RAB.

If UE is coming under the RNC with Assignment Request or Relocation

Request procedure with any other RAB combination than listed above, but
which includes PS conversational RAB, the request is rejected with cause
value “Invalid RAB Parameters Combination”.

[Link] Handling of SIP signaling RAB

For SIP signaling RAB, which traffic class is interactive and signaling
indicator is set, existing functionality is applied:
- It cannot be released due to RT-over-NRT function if it is active. If it is
inactive it can be released due to RT-over-NRT.
- If SIP signalling RB goes inactive and no PS conversational RB exists,
the normal NRT inactivity handling is applied.

Following new functionality is applied for SIP signaling RAB:

- For MBLB RAN2172 it can be defined which preferred layer definitions
are used for SIP RAB and PS conversational RAB
- NRT-over-NRT actions are applied as specified in RAN1273 HSPA pre-
emption feature to get resources for SIP signaling RAB during congestion
situation. SIP signalling RAB cannot be released due to NRT-over-NRT
functionality.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 266(447)
Basic Call
 Functionality description

[Link] PS Conversational RAB setup

UE in Cell_DCH state
When RNC receives the RANAP: RAB ASSIGNMENT REQUEST
message from SGSN requesting PS conversational call in Cell_DCH
state, UE either has only SRBs or also PS connection(s), e.g. SIP
signaling NRT RAB, in use. If SRBs and/or NRT RB(s) are not mapped
on HSPA, NRT RB(s) (and also SRBs, if possible) are reconfigured to
HSPA during PS conversational RB setup.
When SRBs and possible NRT RB(s) are already on HSPA, HSPA
resources are directly tried for PS conversational RB.

HSPA (HSDPA + E-DCH) is configured in all cases. If GBR is 0 kbps

(which can be the case for one direction of unidirectional connection), it is
normalized to 8 kbps and resources are allocated based on that.
Normalization is done also even though the SGSN indicates that
connection is unidirectional in RAB Asymmetry Indicator IE. This means
that in practice PS conversational bearers are always bi-directional.
RRM defines the parameters for HSPA, e.g. UM RLC mode and RLC
PDU size(s) on HS-DSCH and E-DCH, Discard Timer and peak data rate
on HS-DSCH and maximum number of bits and NST as E-DCH grant type
on E-DCH.
SPI is defined by RRM for PS conversational RB similarly as for CS Voice
over HSPA RB. Both 2 ms and 10 ms E-TTI are supported on E-DCH
depending on RRM resource allocation decisions.

Radio link reconfiguration is done with NBAP: RADIO LINK

RECONFIGURATION PREPARE message.
L2 setup parameters for PS conversational RB contain besides legacy
parameters (e.g. SPI, UM RLC parameters, RLC PDU size(s), E-TTI,
UL/DL GBR, MAC entity type) the Robust Header Compression (RoHC)
parameters for PDCP layer entity, when RoHC can be applied, see 2.3.31
Robust Header Compression (RoHC). L2 queueing priority/queueing time
to be applied for PS conversational RAB is the same used during normal
voice call establishment.
Radio bearer setup is done with RRC: RADIO BEARER SETUP message.
When RoHC can be applied, RoHC parameters for RB are contained, see
2.3.31 Robust Header Compression (RoHC).

UE in Cell_FACH state
If UE has NRT RAB(s) when RAB assignment request for PS
conversational RAB comes from SGSN, UE can be in Cell_FACH state.
SIP signaling RB can be among NRT RAB(s) or not, but it does not affect
on functionality.
When RANAP: RAB ASSIGNMENT REQUEST message requesting PS
conversational call comes from SGSN and UE is in Cell_FACH state,
HSPA allocation is done, radio link is setup with NBAP: RADIO LINK
SETUP message and user plane is allocated. L2 queueing
priority/queueing time to be applied for PS conversational RAB is the
same used during normal voice call establishment.
Combined radio bearer setup and state change to CELL_DCH with RRC:
RADIO BEARER SETUP message is done as defined in RAN1232 Fast
Call Setup, see RRC State Transitions for Packet Data FD.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 267(447)
Basic Call
 Functionality description

[Link] Failure cases during PS Conversational RAB setup

Failure cases already introduced and specified in RAN1689 CS Voice

over HSPA (see CS Voice over HSPA) are valid for PS conversational
RAB except that DCH/DCH configurations are not allocated for UE, which
sends a failure to RB setup message indicating no support for the
requested configuration. A RANAP: RAB ASSIGNMENT RESPONSE
(failure) message is sent to the SGSN with a cause value ‘Failure In The
Radio Interface Procedure’.

If setup of PS conversational RAB fails because of non-active PS

Conversational QoS for HSPA feature, the RAB Assignment Request
procedure fails and a RANAP: RAB ASSIGNMENT RESPONSE (failure)
message is sent to the SGSN with a cause value ‘Requested Traffic Class
Not Available’.

If RAB assignment request is received for a PS conversational RAB,

which GBR is bigger than 128 kbps for UL or DL, it is rejected by returning
RANAP: RAB ASSIGNMENT RESPONSE (failure) message with cause
value “Requested Guaranteed Bit Rate For DL Not Available” for DL case,
cause value “Requested Guaranteed Bit Rate For UL Not Available” for
UL case and cause value “Requested Guaranteed Bit Rate Not Available”
for simultaneous DL and UL case.

If setup of PS Conversational RAB fails because of non-supported RAB

combination, the RAB Assignment Request procedure fails and a RANAP:
RAB ASSIGNMENT RESPONSE (failure) message is sent to the SGSN
with a cause value ‘Invalid RAB Parameters Combination’.

If conditions for establishing PS conversational RAB are not fulfilled (see

AC FD), the RAB Assignment Request procedure fails and a RANAP:
RAB ASSIGNMENT RESPONSE (failure) message is sent to the SGSN
with a cause value ‘No Resource Available’.

[Link] State changes are not applied during ongoing PS Conversational RAB

As long as UE has PS conversational RB allocated the UE stays in

Cell_DCH state (no state transitions are possible due to inactivity).

When PS conversational RB is released and there is still NRT RB for the

UE (it does not affect whether there is SIP signaling NRT RAB or not),
state transition away from Cell_DCH state is possible. Same principles
are applied as currently when AMR connection is released.

[Link] Channel type switches are not applied during ongoing PS Conversational
RAB

As PS conversational RB is supported only with HSPA configuration no

channel type switch away from HSPA configuration is supported for PS
conversational RB and accompanying NRT RB(s). However, channel type

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 268(447)
Basic Call
 Functionality description

switches for SRBs can be done as SRBs are supported on E-DCH/HS-

DSCH, E-DCH/DCH and DCH/DCH channel types.

[Link] Interaction with DC-HSDPA, DC-HSUPA, MC-HSDPA and MIMO

When Signalling Indication flag is set for NRT bearer by SGSN, following
features are not applied for UE in question:
• DC-HSDPA
• DC-HSUPA
• MC-HSDPA
• MIMO

When first RAB is setup for UE, any of those features is not allocated.
When UE has already other RABs and establishment of NRT RAB with
Signalling Indication is requested, reconfiguration is done to single cell
configuration without MIMO. Reconfiguration is done simultaneously with
PS conversational RAB setup with NBAP: Radio Link Reconfiguration and
RRC: Radio Bearer Setup procedures. No reconfiguration to dual cell,
multi cell or MIMO configuration is possible during the life time of NRT
RAB with Signalling Indication.

When PS conversational RAB setup is requested, following

reconfigurations are done simultaneously with PS conversational RAB
setup. Reconfiguration is done simultaneously with PS conversational
RAB setup with NBAP: Radio Link Reconfiguration and RRC: Radio
Bearer Setup procedures:
• DC-HSDPA to SC-HSDPA
• DC-HSUPA to SC-HSUPA
• MC-HSDPA to SC-HSDPA
• MIMO to non-MIMO

No reconfiguration to dual cell, multi cell or MIMO configuration is possible

during the life time of PS conversational RAB.

When PS conversational RAB and NRT RAB with Signalling Indication are
released, it is evaluated if DC-HSDPA, DC-HSUPA, MC-HSDPA and
MIMO can be used.

<RAN715/end>

2.3.30 Robust Header Compression (RoHC)

<RAN132/begin>

RAN132 Robust Header Compression (RoHC) provides RTP/UDP/IP

header compression, which can be used to minimize the IP header size of
the RT PS data services. Significant capacity gain can be achieved in
case of services with relatively small data packets, as in the case of VoIP.
Capacity gain is available at the Iub and radio interface.
Robust Header Compression (RoHC) algorithm specified in IETF
RFC3095 and RFC4815 is designed for compressing the RTP/UDP/IP

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 269(447)
Basic Call
 Functionality description

header in the radio interface. RoHC header compression is located at the

PDCP layer and is executed in the RNC and UE. The header
compression is transparent functionality to the application. No BTS effect
is caused by this feature.
The RTP/UDP/IP header is typically 40 bytes for IPv4 and 60 bytes for
IPv6. RoHC compresses the header typically to tenth of the original
header size. The capacity gain achieved is dependent on the size of the
data packets, and especially with VoIP the gain is significant. For the VoIP
the size of the total payload in the radio interface is decreased almost one
third of the original.

At the first phase RoHC is used only for PS conversational RABs on

HSPA. When RoHC is applied, it is used for RTP/UDP/IP header
compression. RTCP packets are not compressed. RoHC U-, O- and R-
modes are used.
UE signals its support for RoHC during RRC connection establishment in
RRC: RRC CONNECTION SETUP COMPLETE message. Capability is
indicated as Support for RFC 3095 in PDCP capability IE in the UE radio
access capability IE. Capability contains also information whether UE
supports RoHC context relocation or not.
RoHC is applied during PS conversational RAB setup, when ROHC is
supported by UE and RoHC feature is enabled in RNC. RoHC support is
not mandatory for UE, since operator has the control to allow PS
conversational RAB setup for non RoHC compliant UEs. L3 receives the

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 270(447)
Basic Call
 Functionality description

RoHC configuration parameters from RRM and delivers them to L2 and

UE.
Parameters for L2 include the used RoHC profile, the max context id
numbers for UL and DL direction and optionally the PDP Type Information
Extension, if received from SGSN. The PDP Type Information Extension
indicates about the usage of dual IPv4/IPv6 stack option.
Parameters for UE include the used RoHC profile and the max context id
numbers for UL and DL direction and they are the same as indicated to
L2. Configuration is indicated to UE as RFC 3095 algorithm type within
PDCP info IE.

When RoHC is not applied during PS conversational RAB setup, RRM/L3

configure PDCP entity on L2 and UE without RoHC related information
and as a result RTP packets are uncompressed.

During UE not-involved SRNS relocation PDCP ROHC contexts can be

transferred from source RNC to target RNC, if UE supports ROHC context
relocation. ROHC contexts contain the PDCP header (de)compression
status for UL and DL. ROHC contexts are delivered to target RNC as RFC
3095 context info message in RANAP Relocation Information IE in
RNSAP: RELOCATION COMMIT message. ROHC context relocation
provides the means to maintain the maximum achieved header
(de)compression level, since without ROHC context relocation target RNC
and UE has to start ROHC header (de)compression with full IP headers.
UE is informed during SRNS relocation, if ROHC context relocation is
performed between source and target RNC. This way UE can continue
with the current ROHC contexts and use compressed IP headers.
RAN2221 HSPA+ over Iur is a pre-requisite for UE not-involved SRNS
relocation.

There is no own feature license for ROHC, however, PS conversational

QoS for HSPA feature license is needed as the functionality is used only
with PS conversational service.

[Link] Impacts on RANAP and RRC procedures

RANAP

Dual stack option, i.e. IPv4 and IPv6 over the same context/bearer in
UTRAN, is indicated with PDP Type Information Extension IE in RAB
ASSIGNMENT REQUEST and RELOCATION REQUEST message. This
is applicable in the case of dual IP stack UEs that may send IP packets of
both the types on the same PDP context.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 271(447)
Basic Call
 Functionality description

IE/Group Name Presence Range IE type and Semantics description

reference
PDP Type Information
>PDP Type extension M 1 to ENUMERAT PDP Type is defined in [8],
<maxnoofPDPDir ED(IPv4 and and the restrictions on usage
ections> IPv6,…) shall comply with [8].
Usage:
When the IE is repeated then
PDP Type for downlink is
signalled first, followed by PDP
Type for uplink; when the IE is
not repeated, the PDP Type
shall apply to both uplink and
downlink.

Range bound Explanation

maxnoofPDPDirections Number of directions for which PDP Type is signalled separately

RRC

UE RoHC capability is indicated as Support for RFC 3095 in PDCP

capability IE. PDCP capability IE below

Information Element/Group Need Multi Type and Semantics Version

name reference description
Support for lossless SRNS MP Boolean TRUE means
relocation supported
Support for lossless DL RLC CV- Boolean TRUE means REL-5
PDU size change not_iRAT_ supported Default
HoInfo2 value is FALSE
Support for RFC2507 MP Boolean TRUE means
supported
>Max HC context space MP Integer(1024
, 2048, 4096,
8192,
16384, Note 1 REL-5
32768,
65536,
131072)
Support for RFC 3095 CV- Boolean TRUE means REL-4
not_iRAT_ supported
HoInfo
>Maximum number of ROHC MD Integer( 2, 4, Default value is REL-4
context sessions 8, 12, 16, 24, 16.
32, 48, 64,
128, 256,
512, 1024,
16384)
>Reverse decompression depth MD Integer Default value is 0 REL-4
(0..65535) (reverse
decompression is
not supported).
>Support for RFC 3095 context MP Boolean TRUE means REL-5
relocation supported
Support for CS Voice over CV- Enumerated The IE indicates REL-8
HSPA not_iRAT_ (TRUE) the UE’s support
HoInfo3 for CS Voice over
HSPA, if set.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 272(447)
Basic Call
 Functionality description

Information Element/Group Need Multi Type and Semantics Version

name reference description
Note 1: The IE "Max HC context space" values 16384, 32768, 65536 and 131072 are not used in the INTER
RAT HANDOVER INFO message.

RoHC is configured for RB with RFC 3095 algorithm type choice in PDCP
info IE. PDCP info IE below

Information Element/Group Need Multi Type and Semantics Versio

name reference description n
Support for lossless SRNS CV- Boolean TRUE means
relocation or for lossless DL LosslessCr support
RLC PDU size change iteria
Max PDCP SN window size CV- Enumerated(s Maximum PDCP
Lossless n255, sequence number
sn65535) window size. The
handling of
sequence number
when the Max
PDCP SN window
size is 255 is
specified in [23].
PDCP PDU header MP Enumerated Whether a PDCP
(present, PDU header is
absent) existent or not.
Header compression information OP 1 to
<maxPDC
PAlgoTyp
e>
>CHOICE algorithm type MP Note 1
>>RFC 2507 Header
compression
according to IETF
standard RFC
2507
>>>F_MAX_PERIOD MD Integer Largest number of
(1..65535) compressed non-
TCP headers that
may be sent
without sending a
full header.
Default value is
256.
>>>F_MAX_TIME MD Integer Compressed
(1..255) headers may not
be sent more than
F_MAX_TIME
seconds after
sending last full
header. Default
value is 5.
>>>MAX_HEADER MD Integer The largest
(60..65535) header size in
octets that may be
compressed.
Default value is
168.
>>>TCP_SPACE MD Integer Maximum CID
(3..255) value for TCP
connections.
Default value is
15.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 273(447)
Basic Call
 Functionality description

Information Element/Group Need Multi Type and Semantics Versio

name reference description n
>>>NON_TCP_SPACE MD Integer Maximum CID
(3..65535) value for non-TCP
connections.
Default value is
15.
>>>EXPECT_REORDERING MD Enumerated Whether the
(reordering algorithm shall
not expected, reorder PDCP
reordering SDUs or not.
expected) Default value is
"reordering not
expected".
>>RFC 3095 Header REL-4
compression
according to IETF
standard RFC
3095
>>>Profiles MP 1 to Profiles supported REL-4
<maxRO by both
HC- compressor and
Profiles> decompressor in
both UE and
UTRAN. Profile 0
shall always be
supported.
>>>>Profile instance MP Integer(1.. 3) 1 = 0x0001, 2 = REL-4
0x0002, 3 =
0x0003 (see [52])
>>>Uplink OP Indicates the REL-4
necessary
information
elements for
Uplink.
>>>>Max_CID MD Integer (1.. Highest context ID REL-4
16383) number to be
used by the UE
compressor.
Default value is
15.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 274(447)
Basic Call
 Functionality description

Information Element/Group Need Multi Type and Semantics Versio

name reference description n
>>>Downlink OP Indicates the REL-4
necessary
information
elements for
Downlink.
>>>>Max_CID MD Integer (1.. Highest context ID REL-4
16383) number to be
used by the UE
decompressor.
Default value is
15.
>>>>Reverse_Decompression_ MD Integer Determines REL-4
Depth (0..65535) whether reverse
decompression
should be used or
not and the
maximum number
of packets that
can be reverse
decompressed by
the UE
decompressor.
Default value is 0
(reverse
decompression
shall not be used).
Note 1: If several occurrences of the same algorithm type are included in the same IE “header
compression information”, the UE behaviour is unspecified.

PDCP RoHC target mode is used by RNC to limit UE’s RoHC

decompressor to one certain mode, i.e. O-mode or R-mode

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 275(447)
Basic Call
 Functionality description

Information Element/Group Need Multi Type and Semantics Version

name Reference description
Target Mode MP The UE shall only REL-5
Etransit to the signalled
n mode for operation of
u ROHC as decribed in
m[36].
e
r
a
t
e
d
(
O
-
m
o
d
e
,
R
-
m
o
d
e
)

[Link] UE signals the support for RoHC during RRC Connection Establishment

During RRC Connection Setup procedure UE sends information of its

RoHC support in RRC: RRC CONNECTION SETUP COMPLETE
message. Capability is indicated as Support for RFC 3095 in PDCP
capability IE in the UE radio access capability IE. Capability contains also
information whether UE supports RoHC context relocation or not.

[Link] PS Conversational RAB setup with RoHC

RoHC is applied during PS RAB setup, when RoHC is supported by UE,

RoHC feature is enabled in RNC and the PS RAB in question is of PS
Conversational Traffic Class type.
RRC/MCC -> CCM -> NRM configures L2 PDCP-layer header
compression/decompression entities with the information listed below
based on values received from RRM:
• PDCP PDU Header contains the value "present"
• RoHC Profile
o Profile instances: contains profile instance 1. Profile
instance 0 is always supported in UTRAN without
configuration. Profile 0 is used for RTCP/UDP/IP header
compression and profile 1 for RTP/UDP/IP header
compression
• Uplink

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 276(447)
Basic Call
 Functionality description

o Highest context ID number (Max_CID): Indicates highest

context ID number to be used by RNC compressor and
decompressor. Default is 5
• Downlink
o Highest context ID number (Max_CID): Indicates highest
context ID number to be used by RNC compressor and
decompressor. Default is 5
o Reverse_Decompression_Depth: Not supported because
of delay caused by reverse decompression buffering, i.e. is
set as 0 by default
• PDP Type Information Extension: Included, if received in the
RANAP: RAB ASSIGNMENT REQUEST message or in the
RANAP: RELOCATION REQUEST message

RB is setup with RRC: RADIO BEARER SETUP message. RRC/MCC

configures RB with the information listed below based on values received
from RRM:
• PDCP PDU Header within PDCP info IE contains the value
"present",
• RFC 3095 algorithm type within PDCP info IE. RFC 3095
algorithm type contains the same information as configured for L2,
• PDCP RoHC target mode IE when RoHC target mode is enabled,
i.e. parameter ROHCTargetMode is set as 1 or 2. By default RoHC
target mode is not used.

[Link] PS Conversational RAB setup without RoHC

RRC/MCC -> CCM -> NRM configures L2 PDCP-layer header

compression/decompression entities without any RoHC related
information. PDCP PDU Header contains the value "absent".

RB is setup with RRC: RADIO BEARER SETUP message. RRC/MCC

configures RB without any RoHC related information in PDCP Info IE and
PDCP RoHC target mode IE is excluded. PDCP PDU Header contains the
value "absent".

[Link] Failure cases during PS Conversational RAB setup

If conditions for configuring RoHC are not fulfilled and PS conversational

RB is not allowed without RoHC, the RAB Assignment Request procedure
fails and a RANAP: RAB ASSIGNMENT RESPONSE (failure) message is
sent to the SGSN with a cause value ‘Requested Traffic Class Not
Available’.

<RAN132/end>

<RAN2717, RAN2943/begin>

2.3.31 Smart LTE Layering (RAN2717), Smart LTE Layering for RU30 (RAN2943)

This feature allows operators to move LTE supporting UEs in RRC

connected mode to LTE layer based on a particular set of triggers.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 277(447)
Basic Call
 Functionality description

License handling and feature activation:

The features are controlled by RNC license key "Smart LTE Layering"
(feature code: 3903). Type of the license key is on/off license.
RAN2717 and RAN2943 features are enabled/disabled in the cell with
the parameter WCEL-SmartLTELayeringEnabled. The activation
parameter has the following values:

• 0 (disabled)

• 1 (enabled for state change)

• 2 (enabled for state change and channel type switch)

• 3 (enabled for state change and CS RAB release)

• 4 (enabled for all triggers)

The values correspond to the triggering points listed below.

<RAN2943/begin>

RAN2943 is subset of RU40 Smart LTE layering feature (simplified

version of RAN2717 for RU30). The feature allows operators to move LTE
supporting UEs to LTE layer when UE's RRC state changes away from
Cell_DCH state or CS RAB release in case of active PS. The feature is
supported by cRNC only. RAN2943 content is the same as for RU40
RAN2717 Smart LTE Layering, except:

• just two triggers (state change away from Cell_DCH state, CS

RAB release in case of active PS)

• no RSCP check see 7) below

• no nbr of NRT users check, see 8) below

• no checking of traffic classes of RABs, see 9) below

• configuring the feature via NetAct is not supported

<RAN2943/end>

The move can be triggered in the following cases:

• RRC state change away from Cell_DCH state. Triggered by UE

specific RRC entity.

NOTE: When RRC connection re-establishment procedure is

ongoing (timer T314 or T315 or both is/are running), layering to LTE
is not triggered. For more information about RRC connection re-
establishment procedure, see /18/.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 278(447)
Basic Call
 Functionality description

NOTE: Redirection to LTE is not triggered, if there have been any

emergency call related activity during the RRC connection, see
[Link].

<not in RAN2943/begin>

• DL channel type switch from HSDPA to DCH (with bit rate > 0) for
an UE with PS services only. Triggered by UE specific RRM.

<not in RAN2943/end>

• When CS RAB is released in multi RAB case (CS + at least one

active PS RAB) and this trigger is activated with parameter WCEL-
SmartLTELayeringEnabled. If PS RAB is inactive, state transition
trigger away from Cell_DCH is encountered instead.

Moving of the UEs is done by ordering a layer change to LTE (by giving
LTE frequency in RRC connection release). Move is blind, because no
measurements are done in LTE side.

RRC entity, UE specific PS and Handover Control write information about

the conditions for layering decision to UE specific VAHAUS file using
WAXLIB procedures. When layering is triggered, the conditions are
checked from the VALMIS file with WAXLIB procedure.

• UE specific RRC entity does the checking when layering is

triggered by state change away from Cell_DCH or CS RAB is
released from an UE with at least one active PS RAB

• UE specific RRM (UER) does the checking when layering is

triggered by DL channel type switch.

When layer change is triggered, all the following conditions must be

fulfilled, before layer change to LTE is ordered.

• Smart LTE Layering is enabled at least to the main cell

(SmartLTELayeringEnabled parameter, )

o includes also that there must be at least one LTE

neighbour (feature cannot be activated to a cell, if it does
not have at least one LTE neighbour). HC is responsible to
update neighbour cell information to the VAHAUS file.

• Smart LTE Layering license is activated (WAXLIB itself checks this

when WAXLIB aswers the request for LTE layering support
information)

• UE must be capable for configured LTE (FDD/TDD), see [Link].

o This means that:

▪ UE supports E-UTRA FDD or E-UTRA TDD or both

(updated to VALMIS by UE specific RRC) and

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 279(447)
Basic Call
 Functionality description

▪ at least one of the neighbour cells is configured for

the LTE technology (FDD or TDD or both) that is
supported by the UE. HC updates to VALMIS
memory file record information only of the LTE
neighbors supported by the UE.

o LTE capability is received in RRC: RRC CONNECTION

SETUP COMPLETE, RRC: UE CAPABILITY
INFORMATION or in RANAP: RELOCATION REQUEST
message

• Optional check: Only UEs which indicated to be redirected from

LTE to 3G can be redirected to LTE, see [Link]
o existence of Pre-redirection info IE in RRC: RRC
CONNECTION REQUEST message.
o Updated to VAHAUS by UE specific RRC

• RRC connection has been existing long enough before redirection

to LTE is tried to be done, see [Link]

o UE specific RRC starts the timer

• No Iu procedure except Iu Release is ongoing

o Legacy functionality, needs no additional checks.

o In state transfer from Cell_DCH and CTS cases, SRB

activity is already checked. Also if Iu procedure is ongoing
when CS RAB is released (e.g. RAB assignment), layering
won’t be triggered.

• There have not been any emergency call related activity during
the RRC connection, see [Link].

<not in RAN2943/begin>

• The present radio conditions must be good enough (CPICH

RSCP).

o HC updates to VALMIS memory file record whether the

latest reported CPICH RSCP measurement value of the
main cell is equal/higher or lower than the value of the
WCEL-parameter SmartLTELayeringRsCp.

• Number of the NRT users in the main cell exceeds the configured
limit. Without this threshold all LTE capable UEs would be
automatically be transferred to LTE and there would be no load
balancing functionality at all.

• Layer change is allowed for UE’s current RAB configuration i.e.

layering is allowed for the traffic classes of the RABs (configured
to RNP with RNMOBI- SmartLTELayeringServ).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 280(447)
Basic Call
 Functionality description

• When CTS is the cause of the layering trigger, layering is not done
if SRB is active. When SRB status is changed due to inactivity,
UE specific RRC (RRC-d) updates information to VALMIS file.

• Optional check: UE must be capable for used LTE bands, see

chapter [Link]
• Optional check: E-UTRAN Service Handover functionality does not
prevent mobility to LTE, see chapter [Link].

<not in RAN2943/end>

If the all above conditions are fulfilled, then UE is ordered to LTE. For
more information about layering triggering conditions, see /47/.

If the UE has cells from DRNC in the active set, then those are ignored in
Smart LTE Layering feature. Layer change can only be done according of
the main cell under SRNC. This means that if UE is anchored (all cells
under DRNC), then Smart LTE layering is not triggered at all.

[Link] LTE support is needed from the UE (RAN2717;RAN2943)

Redirection to LTE can be ordered just if the UE supports LTE. If this

condition is not fulfilled, then layer change is not done.

UE must also support that kind of LTE (FDD/TDD) that has neighbours in
the cell in question. The type of neighbour LTE can be found out from the
'E-UTRA Absolute Radio Frequency Channel Number' of the neighbour
so that frequency numbers 0…35999 <CR#E1381/begin> and
65536…68485 <CR#E1381/end> are for FDD and frequency numbers
36000…54539 are for TDD.

UE indicates its support of E-UTRA FDD by including IE "Support of E-

UTRA FDD" to the message RRC: RRC CONNECTION SETUP
COMPLETE.

If UE supports E-UTRA TDD it includes IE "Support of E-UTRA TDD".

RRC entity stores UE capability for use in layer change decision.

UE radio access capability IE is also included in RANAP:RELOCATION

REQUEST message in RRC Container.

If UE capability information was not received from the SRNC, target

RNC's RRC entity shall initiate UE Capability Enquiry procedure after
relocation has been completed. 'System specific capability update
requirement list' IE shall include "E-UTRA".

Support of E-UTRA FDD CV- Enumerated Absence of this IE means that REL-8
not_iRAT_ (DoesSuppor the UE does not support E-
HoInfo2 tEUTRAFDD) UTRA FDD

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 281(447)
Basic Call
 Functionality description

Support of E-UTRA TDD CV- Enumerated Absence of this IE means that REL-8
not_iRAT_ (DoesSuppo the UE does not support E-
HoInfo2 rtEUTRATD UTRA TDD
D)

[Link] Ordering UE to LTE layer by sending RRC:RRC CONNECTION RELEASE

message (RAN2717;RAN2943)

RRC entity commands UE layer change to LTE by sending RRC: RRC

CONNECTION RELEASE message to UE. RRC entity includes IE "E-
UTRA Target Info" in the message. UE will attempt to camp on a suitable
cell on one of the frequencies indicated in the IE.

<CR#E1381/begin>

The target EARFNCs 0 – 65535 are included in the DL Carrier frequency

IE in the E-UTRA Target Frequency Info List. If the target EARFCN is
greater than 65535, the EARFCN is included in the EARFCN extension IE
in the corresponding instance of the E-UTRA Target Frequency Info
extension List and the value of the DL Carrier frequency IE is set to
65535.

<CR#E1381/end>
Information Need Multi Type and Version
Element/Group reference
name
E-UTRA Target MP 1 to REL-8
Frequency Info List <maxEUTRAT
argetFreqs>
>DL Carrier MP Integer REL-8
frequency (0..65535)
>Blacklisted cells OP 1 to REL-8
per freq list <maxEUTRAC
ellPerFreq>
>>Physical Cell MP Integer (0..503) REL-8
identity
E-UTRA Target OP 1 to REL-11
Frequency Info <maxEUTRAT
extension List argetFreqs>
>EARFCN OP Integer REL-11
extension (65536..262143)

E-UTRA Target Info

Note: IE ‘Blacklisted cells per freq list’ is not used.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 282(447)
Basic Call
 Functionality description

NOTE: HC can set the LTE frequencies to be given to UE in priority order

for redirection depending on the parameter settings. For details, see /47/
(RAN3088/CRE1118).

<RAN2892/begin>

If redirection to LTE is being initiated, either blindly or based on

measurements, then those LTE cells which are under penalty and belong
to LTE frequency layers selected for redirection to LTE, are signalled as
blacklisted cells to UE. Blacklisted cells are cells to which UE doesn't
attempt to camp-on.
<Internal/begin> UE Specific RRC contains the physical cell identities in
the Blacklisted cells per freq list IE in the E-UTRA Target Info IE based on
information received from Handover Control. <Internal/end> UE Specific
RRC updates the counter M1006C322 RRC CONN REL WITH
BLACKLISTED LTE CELLS after sending the message.

<RAN2892/end>

[Link] Prevention timer for layer change to LTE (RAN2717;RAN2943)

For prevention of ping pong between WCDMA and LTE there is a

parameter SmartLTELayeringPrevT to configure the duration during
which layer change to LTE shall not be triggered. If the feature is
activated in the cell (parameter SmartLTELayeringEnabled is set to
Enabled), then there are two cases when the RRC entity shall read the
parameter and set the timer (value from parameter
SmartLTELayeringPrevT):

• after RRC:RRC CONNECTION SETUP COMPLETE has been

received

• Relocation Request has been received indicating ISHO from LTE

and relocation has been completed, see /20/.

If the value 0 is set for the parameter SmartLTELayeringPrevT, then

RRC entity shall not set the timer for prevention of layer change to LTE.

The value of the SmartLTELayeringPrevT parameter can be changed

online and the new value is taken into use for those cases that happens
after the change.

[Link] Existence of Pre-redirection info in RRC:RRC CONNECTION REQUEST

message (RAN2717;RAN2943)

This check is valid only if the limitation is activated with the PRFILE
parameter 002:1916 RN60_MAINT_41.

Redirection to LTE can be ordered if UE has not sent the “Pre-redirection

info” IE in RRC:RRC CONNECTION REQUEST message. If this condition

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 283(447)
Basic Call
 Functionality description

is not fulfilled, then redirection is not done for the UE in question

(relocation case, UE originally camped to 3G).

The existence status of Pre-redirection info is valid during the lifetime of

RRC connection.
NOTE: the following chapter is not to be included in FAD.
Pre-redirection information that UE did not come from LTE can be set to
be forgotten with the PRFILE parameter 002:1917 RN60_MAINT_42.
This makes it possible to redirect also UEs not coming from LTE to LTE.
There are the following two possibilities:
• Status is forgotten after the predefined time is elapsed (time is
started when RRC connection is setup) (time is set with the
PRFILE parameter 002:1917 RN60_MAINT_42)
• Status is forgotten when the main cell of the UE changes

The UE to be redirected must also indicate LTE capability with LTE

capability in RRC connection setup complete message, see [Link].

The redirection prevention timer ([Link]) prevents redirection also in this

case, if it is running.

Descriptions of PRFILE parameters 002:1916 RN60_MAINT_41 and

002:1917 RN60_MAINT_42 are in /47/.

[Link] Redirection to LTE is not triggered in emergency call cases

(RAN2717;RAN2943)

Redirection is not triggered for a UE in the emergency call cases (unless

deactivated) as long as the RRC connection exists. If the special handling
is deactivated, then emergency call cases are handled in same way as
non emergency call cases in Smart LTE layering functionality.

Emergency call detection methods are listed in Admission Control FD

chapter “Emergency call detection methods”.

Editorial NOTE: Pre-emption by an emergency call is not currently

supported in Japan (29.11.2013).

Deactivation of prevention to redirect UEs with emergency call cases

to LTE (this chapter is not included in the FAD):

It is possible to deactivate the prevention of redirection to LTE for

UEs that have had an emergency call or action related to emergency
call. The deactivation can be done with the PRFILE parameter
002:1916 RN60_MAINT_41 (13th bit) in the following way:

Value (binary format) Action

xxxY xxxx xxxx xxxx Y=0 (default), emergency call cases are not

redirected to LTE

Y=1, also emergency call cases can be

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 284(447)
Basic Call
 Functionality description

redirected to LTE

If the prevention is deactivated with the parameter above (value 1 set

for the 13th bit), then UEs with emergency call cases can be
redirected to LTE.

<not in RAN2943/begin>

[Link] UE’s supported LTE bands capabilities are asked from the UE in RRC
connection setup phase (RAN2717)

UE specific RRC requests UE’s E-UTRAN capabilities in RRC connection

setup phase if the following conditions are satisfied:

• the state of the license of the Smart LTE layering feature is ‘On’

• the UE is indicated to be at least Rel8 UE, “Access stratum

release indicator” IE in

o RRC:RRC CONNECTION REQUEST message or

o “Target RNC to Source RNC Transparent Container” IE in

message RANAP:RELOCATION REQUEST or

o RRC:UE CAPABILITY INFORMATION message

• the LTE band checking functionality is activated with the PRFILE

parameter 002:1916 RN60_MAINT_41 (see /47/).

The capability enquiry is performed by adding ‘E-UTRA’ item to

“Capability update requirement”→”System specific capability update
requirement list” IE in RRC:RRC CONNECTION SETUP message.
System specific capability OP 1 to In this version, a
update requirement list <maxSyst maximum size
emCapab of 4 of the list
ility> shall be applied
and any items
after the 4th item
in the list shall
be ignored.
>System specific capability MP Enumerate Five spare
update requirement d (GSM values needed.
, GERAN Iu REL-5
, E-UTRA) REL-8

This orders UE to send LTE capabilities in RRC CONNECTION

SETUP COMPLETE message, see chapter [Link].

Supported LTE bands are indicated by UE in RRC CONNECTION

SETUP COMPLETE message (when asked with the RRC CONNECTION
SETUP message) with the “Inter-RAT UE radio access capability”→”UE
E-UTRA Capability” IE (defined in /54/):
UE-EUTRA-Capability ::= SEQUENCE {
accessStratumRelease AccessStratumRelease,
ue-Category INTEGER (1..5),
pdcp-Parameters PDCP-Parameters,

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 285(447)
Basic Call
 Functionality description

phyLayerParameters PhyLayerParameters,
rf-Parameters RF-Parameters,
….
}

UE-EUTRA-Capability-v9e0-IEs ::= SEQUENCE {

rf-Parameters-v9e0 RF-Parameters-v9e0
OPTIONAL,
nonCriticalExtension UE-EUTRA-Capability-v9h0-IEs
OPTIONAL
}

RF-Parameters ::= SEQUENCE {

supportedBandListEUTRA SupportedBandListEUTRA
}

SupportedBandListEUTRA ::= SEQUENCE (SIZE (1..maxBands)) OF

SupportedBandEUTRA

SupportedBandListEUTRA-v9e0::= SEQUENCE (SIZE (1..maxBands)) OF

SupportedBandEUTRA-v9e0

SupportedBandEUTRA ::= SEQUENCE {

bandEUTRA FreqBandIndicator,
halfDuplex BOOLEAN
}

SupportedBandEUTRA-v9e0 ::= SEQUENCE {

bandEUTRA-v9e0 FreqBandIndicator-v9e0 OPTIONAL
}

FreqBandIndicator ::= INTEGER (1..64)

FreqBandIndicator-v9e0 ::= INTEGER (65..256)

Baseline for 3GPP TS 36.331 Rel-11 document version is 06/16.

A LTE band is handled as supported, if it is in SupportedBandListEUTRA

<CR#E1381/begin> or in SupportedBandListEUTRA-v9e0.
CR#E1381/end>

<CRE1298/begin>

UE’s E-UTRAN capabilities are enquired if it is not prevented by

• UL SRB mapping, see [Link]

• Emergency call case, see [Link]

[Link] The functionalities of the UE’s E-UTRA capability enquiry are controlled
with a PRFILE parameter 002:2136 RU40_MAINT_40

The PRFILE parameter 002:2136 RU40_MAINT_40 is used to

activate/deactivate following functionalities:
1. The UE’s E-UTRA capabilities are requested only for the limited set
of LTE frequency bands for rel10 and newer UEs. If limited set is
used, RNC request UE’s E-UTRA capabilities only for those LTE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 286(447)
Basic Call
 Functionality description

frequency bands which have been configured for the LTE neighbor
cells in the RNC.
2. When E-UTRA capabilities are requested from the UE during RRC
connection setup procedure, the SRBs are normally either
1. mapped to dedicated channel (DCH) using 13.6 kbps bit rate or
2. mapped to E-DCH in UL (in Cell_FACH or Cell_DCH state)
3. When UP indicates UL data on SRB2/3, the RRC:RRC
CONNECTION SETUP repetitions are stopped
4. If UL SRB is not mapped to E-DCH (in Cell_FACH or Cell_DCH
state), UE’s E-UTRA capabilities are not requested with UE
Capability Enquiry procedure
5. HO to LTE is prevented when UE’s E-UTRA capabilities are not
available

By default all functionalities are activated (parameter value 0000h).

If the 1st bit of the PRFILE parameter is set as 1, the UE’s E-UTRA
capabilities are requested for all UE’s supported LTE bands.

If the 5th bit of the PRFILE parameter is set as 1, the SRB mapping
(CCH/DCH) and bit rate are controlled by the Establishment Cause and
legacy parameters.

If the 9th bit of the PRFILE parameter is set as 1, the RRC:RRC

CONNECTION SETUP repetitions are stopped after reception of the
RRC:RRC CONNECTION SETUP COMPLETE

If the 13th bit of the PRFILE parameter is set as 1, sending RRC:UE

CAPABILITY ENQUIRY with Capability update requirement for E-UTRA is
only allowed regardless of UL SRB mapping.

If the 14th bit of the PRFILE parameter is set as 1, HO to LTE is allowed

when UE’s E-UTRA capabilities are not available.

[Link] UE specific RRC acquires the list of LTE bands whose UE capability is
required

If the relevant CRE1298 functionality is not deactivated with the PRFILE

parameter 002:2136 RU40_MAINT_40 (1st bit), UE specific RRC acquires
the list of LTE bands used by LTE neighbours of cells of the RNC
(compiled by HC) for Rel10 or later UEs when UE LTE band capability
enquiry is triggered in the following cases:
• during RRC connection establishment before sending RRC: RRC
CONNECTION SETUP message
• after relocation procedure has been completed for incoming SRNS
relocation or inter-RAT handover

The LTE band list is not be acquired, if the relevant CRE1298 functionality
(1st bit) is deactivated or UE is older than Rel10. In these cases UE E-
UTRA capabilities are enquired in the legacy way.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 287(447)
Basic Call
 Functionality description

UE’s LTE band capability enquiry may be required by features RAN2717,

RAN2980 or RAN2264.

[Link] UE’s supported LTE bands capabilities are requested from the UE only
for limited set of frequency bands

When UE specific RRC requests the Rel10 or newer UE to provide its

supported LTE band combinations (with either RRC:RRC CONNECTION
SETUP or RRC:UE CAPABILITY ENQUIRY messages) by including ‘E-
UTRA’ item to “Capability update requirement”->”System specific
capability update requirement list” IE, the enquiry is performed for the
limited set of LTE frequency bands.

When UE’s LTE band capability enquiry is triggered and

• UE’s release is Rel10 or later and

• The relevant CRE1298 functionality has not been deactivated with

PRFILE parameter 002:2136 RU40_MAINT_40 (1st bit)

• At least one LTE neighbour has been configured in the RNC (at
least one E-UTRA frequency band has been received from the
HC).

the UE specific RRC includes the acquired LTE band list in “Requested E-
UTRA Frequency band list” IE in “Capability update requirement” IE of the
messages RRC:RRC CONNECTION SETUP or RRC:UE CAPABILITY
ENQUIRY.

If no LTE neightbours have been configured in the RNC, UE’s E-UTRA

capabilities are not enquired.
Information Element/Group Need Multi Type and Semantics Version
name reference description
UE radio access FDD capability MP Boolean TRUE indicates
update requirement update required
UE radio access 3.84 Mcps TDD MP Boolean TRUE indicates Name
capability update requirement update required changed
in REL-4
UE radio access 7.68 Mcps TDD MP Boolean TRUE indicates REL-7
capability update requirement update required
UE radio access 1.28 Mcps TDD MP Boolean TRUE indicates REL-4
capability update requirement update required
System specific capability OP 1 to In this version, a
update requirement list <maxSyste maximum size of
mCapabilit 4 of the list shall
y> be applied and
any items after the
4th item in the list
shall be ignored.
>System specific capability MP Enumerated Five spare values
update requirement (GSM needed.
, GERAN Iu REL-5
, E-UTRA) REL-8
Requested E-UTRA Frequency CV- 1 to 16 REL-10
Band list BCHopt

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 288(447)
Basic Call
 Functionality description

Information Element/Group Need Multi Type and Semantics Version

name reference description
>E-UTRA Frequency band MP Integer As defined in [64]. REL-10
(1..256) The value of 64 is
reserved and shall
not be used

Condition Explanation
BCHopt This IE is not needed when sent in SYSTEM
INFORMATION. Otherwise, the IE is optional

[Link] When E-UTRA capabilities are requested from the UE during RRC
connection setup procedure, the SRBs are normally mapped to E-DCH in UL (in
Cell_FACH or Cell_DCH state) or to DCH using 13.6 kbps bit rate

When UE LTE band capability enquiry is triggered during RRC connection

establishment and the SRB mapping functionality of CRE1298 is not
deactivated with the PRFILE parameter 002:2136 RU40_MAINT_40 (5th
bit), the legacy algorithm is used to select the mapping of SRBs to
common or dedicated channels and the used bit rate, with the following
exceptions:

• If the legacy algorithm selects common channels for RRC

connection setup but HS-RACH cannot be used, then the
dedicated channels in setup are selected instead.

• If the Cell_DCH state is selected for RRC connection setup, then

the legacy algorithm is used to select HSPA or DCH for SRBs. If
DCH/DCH transport is selected for SRB, then 13.6 kbps DCH is
attempted to use for SRBs (regardless of the Establishment
Cause and parameter SRBBitRateRRCSetupEC).

• An exception case: In legacy manner, if congestion prevents the

use of SRB DCH 13.6 kbps, SRB DCH 3.4 kbps is retried.

NOTE: The exceptions may override the settings of parameters

HSFACHRel7ConSetupEC, SRBMapRRCSetupEC and
SRBBitRateRRCSetupEC (see Admission Control FD).

UE’s LTE band capability enquiry may be required by features RAN2717,

RAN2980 or RAN2264

[Link] UE specific RRC crosschecks LTE band list of the DRNC against the
supported LTE band list received from the SRNC/source RAT

If UE radio access capabilities for E-UTRA are received in

RANAP:RELOCATION REQUEST from SRNC/source RAT and the
relevant CRE1298 functionality is not deactivated with the PRFILE
parameter 002:2136 RU40_MAINT_40 (1st bit), the DRNC checks
whether all the bands in the DRNC’s LTE band list are included in
supported “SupportedBandListEUTRA “ IE of “E-UTRA Capability” IE
received from SRNC/source RAT.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 289(447)
Basic Call
 Functionality description

If the received supported E-UTRA band list does not contain all the bands
in DRNC LTE band list, the DRNC requests UE’s E-UTRA capabilities
with UE Capability Enquiry procedure from UE after relocation has been
completed. UE Capability Enquiry procedure is performed if it is not
prevented by

• UL SRB mapping, see Error! Reference source not found.

• Emergency call case, see Error! Reference source not found.

[Link] UE specific RRC does not request UE’s E-UTRA capabilities with UE
Capability Enquiry procedure if UL SRB is not mapped to E-DCH

If UL SRB is not mapped to E-DCH and the relevant CRE1298

functionality has not been deactivated with PRFILE parameter 002:2136
RU40_MAINT_40 (13th bit), the UE specific RRC does not include ‘E-
UTRA’ item in the System specific capability update requirement list of the
RRC:UE CAPABILITY ENQUIRY message.

Note: PRFILE parameter 002:2136 RU40_MAINT_40 (13th bit) overrides

previously specified parameters, e.g. PRFILE parameter 002:1916
RN60_MAINT_41.

[Link] UE specific RRC does not request UE’s E-UTRA capabilities with UE
Capability Enquiry or with RRC Connection Setup in emergency call cases

In emergency call cases and if redirection/handover to LTE in emergency

call cases is not allowed by setting 13th bit of PRFILE parameter 002:1916
RN60_MAINT_41 to 0, UE specific RRC does not request UE’s E-UTRA
capabilities with either RRC:RRC CONNECTION SETUP or RRC:UE
CAPABILITY ENQUIRY messages.

Emergency call detection methods are listed in Admission Control FD

chapter “Emergency call detection methods”.

<CRE1298/end>

[Link] UE’s supported LTE bands capabilities can be asked from the UE in
case of relocation (RAN2717)

In case of relocation, supported LTE bands are indicated by other RAT in

Inter RAT HANDOVER INFO WITH INTER RAT Capabilities message
with the “Inter-RAT UE radio access capability”→”UE E-UTRA Capability”
IE (defined in /54/):
UE-EUTRA-Capability ::= SEQUENCE {
accessStratumRelease AccessStratumRelease,
ue-Category INTEGER (1..5),
pdcp-Parameters PDCP-Parameters,
phyLayerParameters PhyLayerParameters,
rf-Parameters RF-Parameters,
….
}

UE-EUTRA-Capability-v9e0-IEs ::= SEQUENCE {

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 290(447)
Basic Call
 Functionality description

rf-Parameters-v9e0 RF-Parameters-v9e0
OPTIONAL,
nonCriticalExtension UE-EUTRA-Capability-v9h0-IEs
OPTIONAL
}

RF-Parameters ::= SEQUENCE {

supportedBandListEUTRA SupportedBandListEUTRA
}

RF-Parameters-v9e0 ::= SEQUENCE {

supportedBandListEUTRA-v9e0 SupportedBandListEUTRA-v9e0
OPTIONAL
}

SupportedBandListEUTRA ::= SEQUENCE (SIZE (1..maxBands)) OF

SupportedBandEUTRA

SupportedBandListEUTRA-v9e0::= SEQUENCE (SIZE (1..maxBands)) OF

SupportedBandEUTRA-v9e0

SupportedBandEUTRA ::= SEQUENCE {

bandEUTRA FreqBandIndicator,
halfDuplex BOOLEAN
}

SupportedBandEUTRA-v9e0 ::= SEQUENCE {

bandEUTRA-v9e0 FreqBandIndicator-v9e0 OPTIONAL
}

FreqBandIndicator ::= INTEGER (1..64)

FreqBandIndicator-v9e0 ::= INTEGER (65..256)

Baseline for 3GPP TS 36.331 Rel-11 document version is 06/16.

If the supported LTE bands are not received in RRC:INTER RAT

HANDOVER INFO WITH INTER RAT CAPABILITIES/ RRC:SRNS
RELOCATION INFO message inside RRC container inside
RANAP:RELOCATION REQUEST message (“Inter-RAT UE radio access
capability”→”UE E-UTRA Capability” IE), then those are asked after
relocation has been completed with the UE Capability Enquiry procedure
as described in chapter [Link]. ‘E-UTRA’ item is added to “Capability
update requirement”→”System specific capability update requirement list”
IE. Procedure is done if all the same conditions as described in chapter
[Link] are fulfilled. This new inquiry does not replace any legacy
inquiries, but is done in addition of those. The LTE capabilities are then
received with the UE CAPABILITY INFORMATION message inside “UE
system specific capability” IE.

A LTE band is handled as supported, if it is in SupportedBandListEUTRA

<CR#E1381/begin> or in SupportedBandListEUTRA-v9e0.
<CR#E1381/end>

<CRE1298/begin>

Also in case UE’s E-UTRA capabilites are received from SRNC/source

RAT, they may need to be enquired from the UE, see [Link].

UE Capability Enquiry procedure is performed if it is not prevented by

• UL SRB mapping, see Error! Reference source not found.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 291(447)
Basic Call
 Functionality description

• Emergency call case. Emergency call detection methods are listed

in Admission Control FD chapter “Emergency call detection
methods”.

<CRE1298/end>

See also /20/.

[Link] LTE band support is needed from the UE (RAN2717)

If the checking of LTE bands is activated with the PRFILE parameter

002:1916 RN60_MAINT_41 (descriptions of PRFILE parameters are in
/47/), then redirection to LTE can be ordered only if the UE supports LTE
band of at least one LTE neighbor. If this condition is not fulfilled, then
redirection is not done. Also if the supported LTE bands information is not
received, then redirection is not done.

[Link] Redirection to LTE can be prevented by core network (RAN2717)

Core Network can indicate that UE must not be redirected to LTE. The
indication is made with the RAB specific E-UTRAN Service Handover IE
located in RAB ASSIGNMENT REQUEST or in RELOCATION REQUEST
message:

IE/Group Name Presence Range IE type and Semantics description

reference
E-UTRAN Service M ENUMERA
Handover TED
(Handover
to E-
UTRAN
shall not be
performed,
…)

The following subfunctionalities can be controlled with a PRFILE

parameter:

1. Can signaling connections only be redirected to LTE or not

o 3GPP says that signaling connection only are not redirected, if the
E-UTRAN Service Handover functionality is in use, /5/

o Signaling connection only means case when UE with no RAB goes

to Cell_DCH state and redirection is triggered when that UE (still
without any RABs) goes away from Cell_DCH state

2. Must prevention be indicated for all RABs of UE or just one RAB

o 3GPP says that prevention must be indicated for all RABs of the
UE, /5/

3. Must prevention information be remembered after related RAB is

released or not

o 3GPP says that prevention information is not remembered, /5/

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 292(447)
Basic Call
 Functionality description

o If remembered, then UE is not redirected to LTE during the existing

RRC connection, if prevention of redirection is received for any RAB
of that UE (includes also rejected RABs)

The subfunctionalities are controlled with the PRFILE parameter

002:1916 RN60_MAINT_41 as described in /20/.

Rationale:

CN can prevent mobility to LTE for example in cases where user does not
have LTE subscription (but have LTE capable UE).

<not in RAN2943/end>

[Link] RAN2717 and RAN2943 new counters

For more information, see /55/.

PI ID Counter name
M1009C262 RELEASE LTE REDIR DUE TO INACTIVITY
M1009C263 RRC CONN RELEASE LTE REDIR DUE TO
CH TYPE
M1009C264 LTE REDIRECTIONS PREVENTED BY
TIMER
M1009C291 RRC CONN RELEASE LTE REDIR DUE TO
CS CALL

<RAN2717, RAN2943/end>

<RAN2135/begin>

2.3.32 Layering in RRC Connection Release (RAN2135)

In RRC connection release phase RNC triggers Layering in RRC

Connection Release if UE needs to be directed to other layer when RRC
connection is released. Layering is supported from common and
dedicated channels.

Layering decision is based on UE band capability and defined preferred

frequency for UE in idle mode. Service does not effect to decision.

Preferred frequency is defined with cell level parameter which defines the
DL frequency (UARFCN downlink (Nd)). This information is given to UE in
RRC Connection Release message inside Redirection info IE. It is
expected that UE goes to frequency given to it in Redirection info IE after
receiving RRC Connection Release and stays there in idle mode if the
coverage is good enough.

With this feature layering is supported only inside WCDMA. No layering to

GSM or LTE is supported in this feature.

RAN2135 Layering in RRC connection Release is an optional feature

(ASW) and it is controlled by RNC license key. The type of the license key

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 293(447)
Basic Call
 Functionality description

is long term ON/OFF and the name of license key is "Layering in RRC
Connection Release LK".

There is a cell level parameter called LayeringRRCRelEnabled which is

used to enable the feature.

The feature is enabled in the cell when the following conditions are
effective:
• The license of the feature is installed in the RNC and the state of
the feature is 'On'.

• The value of the parameter WCEL-LayeringRRCRelEnabled is set

to 'Enabled'.

[Link] RRC indicates to UE frequencies/frequency ranges for layering

Before sending RRC: RRC CONNECTTION RELEASE, RRC entity

checks whether conditions for moving the UE to another layer are
satisfied, see [Link]. The checking shall be done regardless of the
reason of the release, i.e. normal or some failure case.

If all the conditions for layer change have been fulfilled, the RRC entity indicates to the
UE where BCCH frequencY where UE shall attempt to camp on a cell with indicated
UTRA carrier included in the RRC CONNECTION RELEASE message. RRC entity
shall do this by including IE IE ‘UARFCN downlink (Nd)’in the RRC: RRC
CONNECTTION RELEASE message to UE (see /3GPP 25.331/ [Link] and
[Link]). Involved IEs are:

Relocation info->Frequency info->UARFCN downlink (Nd)

Relocation info:
Information Need Multi Type and Semantics description Version
Element/Group name reference
CHOICE Redirection MP
Information
>Frequency info Frequenc
y info
[Link]

Frequency info:
Information Element/Group Need Multi Type and Semantics description
name reference
CHOICE mode MP
>FDD
>>UARFCN uplink (Nu) OP Integer(0..16 If this IE is not present, the
383) default duplex distance
defined for the operating
frequency band shall be used
[21]
>>UARFCN downlink (Nd) MP Integer(0 .. [21]
16383)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 294(447)
Basic Call
 Functionality description

[Link] RRC entity makes the decision of layer change

In RRC Connection Release phase RRC entity makes decision of layer

change. UE can be in dedicated or common channels. UE is directed to
other FDD UMTS frequency layer if following conditions are met:

• Layering in RRC Connection Release is enabled for the HS-DSCH

serving cell or (if HS-DSCH is not allocated) main cell (best CPICH
EcNo).
• At least one target frequency is defined with WCEL-
LayeringRRCRelTargFreq-TargFreqLower parameters. The
parameter is read from the HS-DSCH serving cell or (if HS-DSCH
is not allocated) main cell (best CPICH EcNo).

RRC entity fills the target frequencies / frequency ranges (up to 8) to IEs
as defined in [Link]. If WCEL-LayeringRRCRelTargFreq-
TargFreqUpper parameter defines the upper limit then frequency range is
used. Otherwise, only one frequency is given (lower). If more than one
frequencies / frequency ranges are defined then RNC fills the consecutive
releases at the cell in round robin order in ICSU level.

WCEL-LayeringRRCRelTargFreq parameters are read from the HS-

DSCH serving cell or (if HS-DSCH is not allocated) main cell (best CPICH
EcNo). The frequencies that UE does not support are left out from list
send to UE.

If all cells in active set are under DRNC the layering is not done. The
layering is done from SRNC only .

If Smart LTE Layering feature (RAN2717) is activated in the same cell, the
decision to direct UE to LTE is done first. If the decision is that UE is not
directed to LTE then the decision defined in this requirement is done.

With this feature layering is supported only inside WCDMA. No layering to

GSM or LTE is supported in this feature.

<RAN2135/end>

<RAN2778/begin>

2.3.33 RAN2778 UE Periodic Measurement Report

<RAN2496/begin>

The RAN2496 Minimization of Drive Tests (MDT) replaces this RAN2778

UE Periodic Measurement Report feature. RAN2496 provides the same
UE measurements as RAN2778, but with added functionality and includes
also measurements done by BTS. See chapter 2.3.42 for more info.

<RAN2496/end>

The RAN2778 UE Periodic Measurement Report feature provides

collection of periodic CPICH EcNo/CPICH RSCP, UE Tx Power and DL

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 295(447)
Basic Call
 Functionality description

BLER UE measurement reports with the Megamon (RNC collector).

Measurement reports can be used by the operators to optimize radio
network.

The UE periodic measurement reports are started for Rel99, HSDPA and
HSPA calls with configurable reporting period. When the feature is
activated in a cell, then all UEs in that cell of the RNC are ordered to
perform measurements if RNC processing load is not too high. Handover
Control starts periodic CPICH EcNo/CPICH RSCP measurements (see
HC FD) and UE Specific RRC/RRC-D starts periodic UE Tx Power and
UE Quality measurements.

Existing measurements which are currently setup for the RNC algorithms
can also be used for this purpose whenever it is possible. The RNC itself
does not analyse or use these measurements for any purpose.

The periodic report of radio measurements gets snapshots of the overall

radio network environment, allowing the operators to:
- supervise periodically UEs with a monitoring solution which is able to
detect decreasing radio quality,
- get reasons of the drops,
- get enhanced troubleshooting capabilities and reduce drive tests.

The RAN2778 UE Periodic Measurement Report feature is implemented

in common software, but targeted only to cRNC product.

[Link] Activation of the feature in RU40

In RU40 the UE Periodic Measurement Report feature is activated if:

• RAN2778 ‘UE Periodic Measurement Report' license state is ‘ON’

in RNC

• Feature is enabled in active set by WCEL parameter

UePeriodicMeasEnabled. Feature is assumed to be enabled if the
active set contains at least one cell where this feature is activated
by WCEL parameter UePeriodicMeasEnabled.

UE Specific RRC/RRC-D reads the WCEL parameter and License when

UE comes to RNC in Cell_DCH state and moves inside the RNC.

UE specific RRC/RRC-D checks the WCEL parameter also when UE

moves to a new cell (makes IFHO, IFHO over IUR or active set update by
adding a new cell to the active set or by removing a cell from the active
set). Depending on the current active set UE specific RRC/RRC-D
activates the RAN2778 measurements (if those are not ongoing already)
if after active set update there is at least one cell in the active set which
has the UE Periodic Measurement Report feature enabled by the WCEL
parameter UePeriodicMeasEnabled. Similarly depending on the current
active set the UE specific RRC/RRC-D deactivates the ongoing RAN2778
measurements if after the active set update there is no cell in active set
having the UE Periodic Measurement Report feature enabled by the
WCEL parameter UePeriodicMeasEnabled.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 296(447)
Basic Call
 Functionality description

Updated due to PR 36342ESPE06: RU40:QX123700:RAN 2778 and CR 841:

RRC and HA3 implementation is not according to the CR841 EFS requirement id
3.1.4.

Reporting Period

In RU40 the reporting interval of periodic measurements can be adjusted

by using RNC parameter UePeriodicMeasInterval.

CPU Load

CPU load threshold is modifiable in the following way:

• Range and step 50..90 %, step 5 %
• Recommended value 70 %

In RU40 the value of the CPU load threshold can be adjusted by using the
RNC parameter UePeriodicMeasCpuLimit. Before activating the RAN2778
measurements for the UE, UE Specific RRC/RRC-D checks the CPU load
of its own unit. The RAN2778 measurements can be activated for the UE
only if the CPU load of the own unit is below the threshold defined by the
RNC parameter UePeriodicMeasCpuLimit.

[Link] Starting of periodic measurements in RU40

In RU40, if the RAN2778 measurements are not already ongoing, when

cell having value ‘enabled’ for WCEL parameter UePeriodicMeasEnabled
is added to UE’s active set, UE Specific RRC/RRC-D checks the CPU
load of its own unit and compares it to the limit defined by the RNC
parameter UePeriodicMeasCpuLimit.

If the average CPU load is below the limit over a period of 1 minute and
the reporting interval contains a valid value, UE Specific RRC/RRC-D
performs following actions:

• if not already started UE Specific RRC/RRC-D starts periodic UE

Tx Power measurement as an additional measurement in UE.
About parameters for additional UE Tx Power measurement, see
“Periodic UE Tx Power measurement”

• if not already started UE Specific RRC/RRC-D starts periodic UE

Quality measurement in UE. UE Specific RRC/RRC-D attaches
UE Tx Power measurement as an additional measurement to UE
Quality measurement by setting the measurement id of the UE Tx
Power measurement to the additional measurement list in the
measurement control of the UE Qualitymeasurement

If the average CPU load is above the limit over a period of 1 minute, UE
Specific RRC/RRC-D does not start periodic measurements relating to
this feature.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 297(447)
Basic Call
 Functionality description

UE Specific RRC/RRC-D ensures that the number of different L3 filters to

be configured to UE does not exceed the maximum of two L3 filters for UE
internal measurement type. This is done by using fixed L3 filtering for
additional UE Tx Power measurement.

If UE Specific RRC/RRC-D receives RRC: Measurement Control Failure

for the started periodical UE Tx Power measurement or periodical UE
Quality measurement then UE Specific RRC/RRC-D does not try to start
the measurement again for the UE as long as it stays in Cell_DCH state.

Updated due to PR 36342ESPE06: RU40:QX123700:RAN 2778 and CR 841:

RRC and HA3 implementation is not according to the CR841 EFS requirement id
3.1.4.

[Link].1 Periodic UE Tx Power measurement in RU40

Additional UE Tx Power measurement is determined in the following way:

• Measurement reporting mode for additional UE Tx Power

measurement is fixed and cannot be controlled by any RNP
parameters

o Transfer Mode is 'Unacknowledged mode RLC'

o Reporting Mode is 'Periodical Reporting Mode'

• Measurement quantity of the UE internal measurement is ‘UE Tx

Power’. The L3 filtering of additional UE Tx Power measurement is
fixed fc19_c and cannot be controlled by any RNP parameters

• Reporting quantity of the UE internal measurement is ‘UE Tx

Power’. The reporting quantity of additional UE Tx Power
measurement is fixed and cannot be controlled by any RNP
parameters

• Report Criteria is ‘No reporting’ because the UE internal

measurement is used as an additional measurement to UE Quality
measurement

[Link] Providing periodic measurements for Megamon usage in RU40

UE Specific RRC/RRC-D packs the received UE Quality measurement

reports including UE Tx Power measurement results to RNC internal
message and forwards them to non-existent process id 0xFF00, so that
the measurement reports are visible in the Emil tool and the Megamon is
able to collect the measurement reports.

[Link] Stopping of periodic measurements in RU40

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 298(447)
Basic Call
 Functionality description

In RU40 if the periodic UE Quality measurement and UE Tx Power

measurement are ongoing due to UE Periodic Measurement Report
purposes only and the UE moves to a new cell (through active set update,
IFHO or IFHO over IUR) and this feature is not activated in the current
active set, UE Specific RRC/RRC-D shall request the UE to stop related
ongoing periodical measurements. Periodic UE Quality measurement and
additional UE Tx Power measurement shall be released if those are
needed only for UE Periodic Measurement Report purposes.

If the active set changes so that none of the active set cells have this
feature activated, the measurements are stopped if those were ongoing
due to UE Periodic Measurement Report purposes only.

If UE Quality measurements are ongoing due to UE Periodic

Measurement Report purposes and those are also needed for
RCPM/Subscriber Trace purposes and later if there is no need to have UE
Quality measurements for UE Periodic Measurement Report purposes
anymore, then UE Quality measurement is not stopped/released because
it is still needed for RCPM/Subscriber Trace purposes. UE Tx-Power
measurement is released by RRC/RRC-D because that is not needed for
RCPM/Subscriber Trace purposes.

After incoming relocation (UE involved/UE not involved) UE Specific

RRC/RRC-D always releases the possibly ongoing additional UE Tx
Power measurement and UE Quality measurement based on the UE
measurement list in the RRC Container after which UE Specific
RRC/RRC-D checks, if condition for starting periodical UE Quality
measurement is met.

[Link] Interaction with RCPM and Subscriber Trace features in RU40

When UE Specific RRC/RRC-D receives UE Quality Measurement

request from RCPM or Subscriber Trace and the UE Quality
measurement is already ongoing due to RAN2778, the measurement can
be kept ongoing without any modifications.

If UE Quality measurements are needed for RCPM/Subscriber Trace

purposes and also for RAN2778 purposes, the measurement is not
released by UE Specific RRC/RRC-D even if it is not anymore needed for
RCPM/Subscriber Trace purposes.

If UE Quality measurements are ongoing due to RAN2778 purposes and

those are also needed for RCPM/Subscriber Trace purposes and later if
there is no need to have UE Quality measurements for RAN2778
purposes anymore then RAN2778 UE Quality measurement is not
stopped/released because it is still needed for RCPM/Subscriber Trace
purposes. UE Tx-Power measurement is released by RRC/RRC-D
because that is not needed for RCPM/Subscriber Trace purposes.

UE Specific RRC/RRC-D does not update M1018 counters, if the UE

Quality measurements are started due to RAN2778 only.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 299(447)
Basic Call
 Functionality description

<RAN2778/end>

<CRE0930/begin>

2.3.34 Queueing and Priorisation of DSP/Transport resource requests

CR E0324 is part of RAN1803 L2 resource management which is not

implemented. Even CR E0324 is not completely implemented but only this
which is now below described and done via another CR E0930
“Adjustment and enhancement of Priority and queueing parameters of L2
resource request”. The base CR E0324 can be found from Sharenet (as
also CR E0930) and rest of it can be implemented in later phase if still
seen relevant. There is e.g. more sophisticated methods of increasing the
priority of re-attempts.

The UP/Transport resource request queuing and priorisation speeds up

the priorised resource request. Formerly NACKs for unsuccesful
UP/Transport resource request, including emergency calls, was returned
back to TRM(NRM) which then performed re-attempt request three times.
The final result (ACK/NACK) from resource manager RM2/3 took
unnecessarily too long for urgent RRC procedures that L3 was controlling.
And as the re-attempted UP/Transport resource request had no higher
priority among other requests and there was no queuing for resource
requests, the re-attempted request had no better possibility to get the
resource than the orginal one.

For an improvement the queuing and prioritisation of UP/transport

resource requests is done in the resource management (RM). UE specific
entity of RNC (MCC or UER, depending on the UE state) defines the
absolute priority of individual UP/Transport resource requests as well as
the allowed queuing time according to the table 2 below. UE specific entity
(MCC) defines queue and priority values of UP/Transport resource
allocation done in Cell_FACH state as UE specific entity (UER) defines
them in Cell_DCH state. Queuing and prioritization is applicable and used
for UP/Transport resource allocations and UP/Transport resource
upgrades. No UP/Transport resource request re-attempting needed
anymore by TRM(NRM)..

EFSCRE0930_09011
[Link]

Table 2: Queueing and Priority of different procedures or transactions

<CRE930/end>

<RAN2509/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 300(447)
Basic Call
 Functionality description

2.3.35 RAN2509 Application Aware RAN(SPI promotion/demotion)

This feature introduces dynamic service or application prioritization for the

HSDPA scheduling. Prioritization can be done between bearers each
carrying multiple services. Feature has enabling parameters for Iub and
Iur. When operator enables Iur enabled parameter all BTS under NSN
DRNC are considered to support this feature.

Core network based DPI provides application detection by marking inner

(user) IP packet with DSCP code points. Initial Scheduling Priority
Indication (SPI) of the radio bearer is demoted or promoted in the RNC
PDCP layer according Deep Packet Inspection (DPI) marking. The fast
reaction time is enabled by transferring priority information from RNC to
BTS scheduler via user plane, by using Common Channel Priority
Indication (CmCH-PI) in Frame Protocol.

Operator can configure the promotion of the initial SPI, demotion of the
initial SPI or not to change the initial SPI actions for certain type of data.

Application Aware RAN feature can be enabled or disabled in the cell via
WCEL-AppAwareRANEnabled [Link] receives the cell level
RAN2509 Application Aware RAN (AAR) capability of BTS in the NBAP
PRIVATE MESSAGE from BTS.

L3/user specific RRC gets activation info (AppAwareRANEnabled) of

feature RAN2509 from User specific RRM/UER. L3/user specific RRC
also gets SPI from User specific RRM/UER as legacy functionality.L3/user
specific RRC then passes this information via TRM/NRM to L2/FP.
TRM/NRM also reads parameters (AppGrpId, DSCP Code, Precedence
and Target SPI) from RNW database when configuring this functionality to
L2/FP which are then used for promotion and demotion functionalty in L2.
Parameters are defined in RRM FD (35/ HSDPA RRM in RNC FD).
[Link] Impacts on NBAP and RRC procedures

RRC

There are no impact to RRC procedure due to Application Aware RAN.

NBAP

See /40/NBAP and RNSAP Procedures FD

<RAN2509/end>

<RAN2348/Begin>

2.3.36 Coverage and User Statistics in Traffica

Here only L3 effects. More about feature, see Traffica FD.

RAN2348 introduces new content for the data that RNC provides for
Traffica. The feature content is divided into three independent parts:

1) New content to RRC/RAB report (new report version)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 301(447)
Basic Call
 Functionality description

- CPICH EcNo of RRC Connection Request in a dedicated field (while

earlier spare field was used)

- PRACH Propagation Delay of RRC Connection Request in a dedicated

field (while earlier spare field was used)

- CPICH RSCP of RRC Connection Request

- TMSI and IMEI of the user

- MCC/MNC of the core network where Iu-connection is established

(needed in MOCN networks)

- UE 3GPP release version

- Information about UE capability, for example HSDPA and HSUPA

category

- ID of the user plane computer unit used for SRB and RAB processing.

- PS RAB uplink and downlink transferred data volume

2) New content to Packet Call failure report (new report version)

- IMEI of the user

- ID of the user plane computer unit used for PS user plane processing.

3) New report type "Cell Users" that indicates the amount of Cell_DCH
users per cell, classified by channel type like SRB, CS voice, R99,
HSDPA, HSUPA

Additionally possibility to hide subscriber identity from IMSI and IMEI is

implemented to address privacy concerns that some customers might
have.

L3 Visibility

UE specific RRC adds IMEI(SV) or IMEI to all RRC/RAB Traffica reports

that are sent in such moment that the information is known by the RNC.
(SV) means that also the software version part of IMEI is included. The
same field in the Traffica report is used regardless of whether the RNC
gets IMEI or IMEI(SV) as those are of equal length.

The UE specific RRC reads IMEI from GMM/MM: IDENTITY RESPONSE

NAS-message that may be sent by the UE to the core network during
connection establishment. It must be noted that the identity request
procedure is not always executed but it depends on the core network
settings. Identity Request / Identity Response procedure is defined in
/TS_24008/.

A new field is added to the Traffica report for IMEI. If IMEI is not known
when sending the report, the field shall be initialized full of FFFF.

<RAN2348/End>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 302(447)
Basic Call
 Functionality description

<CR E1017/Begin>

<internal/begin>

2.3.37 CS Call Silence Detection

Purpose of this functionality is to detect the CS silence calls and help in

log collection in customer network. This functionality introduces changes
at RNC Layer2 so that RNC Layer2 starts to follow activity of the end-
user data stream and generates the indication for RNC Layer3 when CS
call activity changes and silence is detected.

CS call silence detection is optional functionality and it is controlled with

PR File parameter “ru40_maint_08” and if CS call silence detection
functionality is enabled L3 informs L2 when CS silence detection needs to
be started on L2. This functionality is used only for AMR calls and Video
calls are not included in the CS Call Silence detection.

When CS AMR call is setup, L3 checks if CS call silence detection is

enabled with PRFILE. If CS call silence detection is enabled then L3
commands L2 to start silence call detection functionality after AMR call is
setup. L3 sends l2_start_fishing message to RNC_RAB entity in RNC L2
with command CS_SILENCE_DETECT.

During CS AMR call setup, L3 follows NAS signalling after Radio Bearer
Setup Complete. L3 commands L2 to start silence detection after NAS
signal “CONNECT” after AMR call setup.

During UE involved and UE not involved Relocations for CS call , L3

commands L2 to start silence detection after Relocation Complete is sent
to CN if functionality is enabled with PR File parameter.

L3 commands RNC Layer2 to stop silence detection on receiving

“DISCONNECT / RELEASE / HOLD Acknowledge / IU Release command
from CS CN”. On receiving “RETRIEVE Acknowledge”, L3 again
commands L2 to start silence detection.

CS silence detection is not started again by L3 during AMR re-

establishment and during AMR channel type switches (DCH<->HSPA).

When L3 receives “L2_fishing_data_s” from RNC Layer2, L3 does the

HPL logging if silence for CS call is detected based on parameters in
“L2_fishing_data_s”.

When L3 receives “L2_fishing_data_s” from RNC Layer 2, L3 checks the

“fishing_command” from message “L2_fishing_data_s”. If
“fishing_command” is set to “CS_SILENCE_DETECT/1” then L3 checks
the direction from message “L2_fishing_data_s”. If direction is set to
“UL/0”, L3 does the logging that Silence is detected for UL direction. If
direction is set to “DL/1”, L3 does the logging that Silence is detected for
DL direction.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 303(447)
Basic Call
 Functionality description

During SRNC Relocation / Inter RNC HHO / Inter ADA SCC (Role Switch)
/ ISHO, L3 does not do HPL logging at source RNC.

<internal/end>

<CR E1017/End>

<RAN147/Begin>

2.3.38 RRC Connection Setup Redirection

The feature enables a RRC connection redirection to another 3G

frequency or GSM in case the admission control rejects the RRC
connection request. If reason for rejection of RRC connection setup is
something else than admission control decision, the RRC connection is
rejected without the redirection information.

RRM decision about the target system is based on the establishment

cause received in the RRC: RRC CONNECTION REQUEST message
and the WCEL parameter RRCReDirTargetSys. The WCEL parameter
RRCReDirTargetSys defines the primary and secondary target system for
each establishment cause. Choices for target systems are “no
redirection”, “GSM” or “3G”.
The secondary target system is the target system of redirection, if the first
redirection is failed.

<PR255362/begin>

If UE includes the CSFB Indication IE in RRC: RRC CONNECTION

REQUEST and the received establishment cause is other than
“Terminating Conversational Call” or “Emergency Call”, the RRM selects
the target system as if the received establishment cause was “Originating
Conversational Call”.

< PR255362/end>

If the functionality Redirection to GSM due to RNC signaling unit overload

is activated, UE is commanded to GSM without optional GSM Target Cell
Info in case of CPU overload, see RAN147 on L3 Overload FD.

RRC Connection Setup Redirection is an ASW feature, which is

controlled by a RNC license. The license type is on/off.

Please refer to RRM Handover Control FD for further details about target
cell selection, target frequency selection and management parameters.

UE redirection

The Redirection Info sent in the RRC: RRC CONNECTION REJECT

message depends on the target system:

• if the target system is GSM and the UE release is older than rel-6,
the Redirection Info contains a target system. <Internal/Begin> UE
Specific RRC sets Inter-RAT info IE to the value “GSM”.
<Internal/End>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 304(447)
Basic Call
 Functionality description

• if the target system is GSM and the UE release is rel-6 or newer,

the Redirection Info contains a target cell list. <Internal/Begin> UE
Specific RRC sets Inter-RAT info IE to the value “GSM” and adds
the target cell list into GSM Target Cell Info IE. <Internal/End>

• if the target system is 3G, the Redirection Info contains a target

frequency. <Internal/Begin> UE Specific RRC adds the target
frequencies into IEs UARFCN downlink and UARFCN uplink IE in
Frequency info IE.

[Link] Redirection info

Information Need Multi Type and Semantics description Version
Element/Group name reference
CHOICE Redirection MP
Information
>Frequency info Frequenc
y info
[Link]
>Inter-RAT info Inter-RAT
info
[Link]

[Link] Inter-RAT info

Information Element/Group Need Multi Type and Semantics Version
name reference description
Inter-RAT info MP Enumerated
(GSM
, E-UTRA) REL-8
GSM target cell info CV-GSM GSM target REL-6
cell info
10.3.8.4g
E-UTRA target info CV-E- E-UTRA REL-8
UTRA target info
10.3.8.4L

[Link] Frequency info

Information Element/Group Need Multi Type and Semantics description
name reference
CHOICE mode MP
>FDD
>>UARFCN uplink (Nu) OP Integer(0..16 If this IE is not present, the
383) default duplex distance
defined for the operating
frequency band shall be used
[21]
>>UARFCN downlink (Nd) MP Integer(0 .. [21]
16383)
>TDD
>>UARFCN (Nt) MP Integer(0 .. [22]
16383)

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 305(447)
Basic Call
 Functionality description

<Internal/End>

Wait Time in RRC: RRC CONNECTION REJECT message is set

according to legacy functionality, i.e. based on Establishment Cause.

When a RRC: RRC CONNECTION REJECT message is sent with

redirection information Cell Traffic Manager (RRB) updates the counter
M1006C70 RRC CONN REJECT DUE TO RRC CONNECTION SETUP
REDIRECTION.

Resource Control (RC3) keeps up the count of redirections for each UE

by a 20s hardcoded timer, which is set after first redirection. When a RRC
connection setup request returns back to original cell within 20s of earlier
redirection, Resource Control (RC3) informs UE Specific RRC (MCC)
about reception of RRC connection request for same initial UE identity
from same cell and UE Specific RRC (MCC) informs RRM during
resource request for RRC connection. If RRM (HA3) rejects the second
RRC connection request of the same UE based on admission control,
RRM (HA3) commands UE Specific RRC (MCC) to perform UE
redirection to second target, if defined.

If the first redirection is failed and the RRC connection setup request
returns back to the original cell and the return has lasted more than 20
seconds and conditions for redirection are still valid in the original cell,
then the redirection is done to the primary target system. Also if the RRC
connection setup request returns to some other cell than the original cell,
the direction is done to the primary target system regardless of the return
time (whether it is more or less than 20 seconds).

If the first redirection is failed and a secondary target system is not

defined or both the first and the second redirections are failed, the RRC:
RRC CONNECTION REJECT message is sent without redirection
information. When RRC: RRC CONNECTION REJECT message is sent
without redirection information, the number of redirections is reset.

UE Specific RRC updates the counter M1006C305 RRC CONN

REDIRECTION TO GSM FAILED, when a RRC connection setup request
returns back to original cell within 20s of earlier redirection and the first
redirection was towards GSM.

<RAN147/End>

<RAN2980/Begin>

2.3.39 Measurement Based LTE Layering

Measurement Based LTE Layering feature is an extension of Smart LTE

Layering feature (RAN2717). LTE capable UE can be redirected to LTE
system with or without LTE neighbour measurement. If RAN2980 feature
is active, UEs can be redirected to LTE without measurement as specified
in RAN2717 feature, and there is no need to have RAN2717 license
installed separately. Also, UEs can be redirected to LTE system based on
the measurements initiated by the same 3 triggers that of RAN2717 and
with the 4th additional trigger of periodic trigger, which is introduced in

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 306(447)
Basic Call
 Functionality description

RAN2980. Furthermore, RAN2980 also supports redirection of UEs to

LTE system with combination of without measurement and with
measurement, e.g. redirection to LTE system through first 3 triggers
without measurement, and with 4th trigger based on the measurements.
The four triggers which are used to redirect the UEs to LTE system are as
under:

• Trigger 1 (T1): RRC State Change Cell_DCH to CCH: LTE

capable UE is in CELL_DCH, and is being transitioned to other
RRC states (CELL_FACH, CELL_PCH, URA_PCH).

• Trigger 2 (T2) : HSDPA/HSPA to DCH/DCH CTS: Channel type

switch for LTE capable UE from HSDPA to DCH or from HSPA to
DCH.

• Trigger 3 (T3): CS RAB Release: LTE capable UE has CS RAB

and PS RAB(s), and CS RAB is being released.

• Trigger 4 (T4): Periodic trigger: when LTE capable UE enters into

CELL_DCH, having only PS RAB(s), a periodic timer is set. UE
continues its data activity and then, at the expiry of timer, LTE
neighbour measurements are started to redirect UE to LTE, and
periodic timer is set again. If measurements are successful, i.e.,
received measured results lead to decision to redirect UE to LTE,
UE is then redirected to LTE. If the measurement results are
unsuccessful and UE still continues data activity, then at the expiry
of the timer measurements are started again, and periodic timer is
set again. If the measurements are successful, then UE is
redirected to LTE. Otherwise, same procedure is repeated again
and again.

LTE capable UEs, which are redirected to LTE blindly (without

measurement), can face problem in cell reselection, and that can cause
bad experience to end-users. To overcome this problem, and provide
better end-user experience, this feature supports measurement based
redirection to LTE system so that UE reselect a better cell.

LTE capable UEs are checked for their measurement capabilities. There
can be some high end UEs which have dual receiver, and don't require
compressed mode to create gaps to listen to other frequencies. The
compressed mode related information is not sent to such UEs, as these
UEs don't require this information.

On the other hand, majority of UEs would require compressed mode (CM)
to listen to other frequencies (LTE carrier frequencies). In order to receive
LTE carrier frequencies, such UEs require transmission gap length of 10
time slots, which spans to two consecutive radio frames (i.e. double
frame). This feature supports compressed mode in HSPA, i.e. E-DCH/HS-
DSCH with RAN1668 feature. In the absence of RAN1668, feature
supports HSDPA/DCH, and DCH/DCH compressed mode. If there is
HSUPA (E-DCH) in uplink, then it is reconfigured to DCH, before initiating
the compressed mode measurements. In this feature, UE is asked to

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 307(447)
Basic Call
 Functionality description

send the measurement results on periodic measurement basis, i.e., UE

sends the measured results at the interval as specified by the network,
and keeps on sending measured results until network asks UE to stop.

Through this feature, there is also freedom not to have LTE capable UEs
redirected to LTE system, but let the UEs remain in the WCDMA, if
WCDMA network is providing good end-user experience (WCDMA cell is
not highly loaded). On the other hand, when WCDMA cell is in high load,
UEs can be redirected to LTE system. WCDMA cell load checking
functionality can be disabled, i.e. LTE capable UEs meeting the trigger
criteria are redirected to LTE system without checking the cell load.

CSFB indication from UE and CN is used as a precondition for LTE

redirection. CSFB indication is applied for triggers using both blind and
measurement based redirection. The purpose is to prevent non LTE users
being redirected to LTE system. CSFB indication means that UE has
been redirected from LTE to WCDMA for CS call and thus guarantees
that UE and its subscription supports LTE. If the UE is redirected to LTE
without checking the CSFB indication, chances are that there could be no
LTE coverage or the UE has no subscription to LTE. In that case UE
would return to WCDMA and it may take 10-30 seconds to camp on to
WCDMA cell.

CSFB detection functionality can be used with the legacy E-UTRAN

Service Handover IE based solution, because that IE is not available
and/or supported always.

CSFB detection functionality is not dependant on RAB combination

assigned to the UE, i.e. UE can have CS and/or PS RABs.
CSFB detection functionality is controlled by the RNMOBI-CSFBDetection
parameter. See chapter “CSFB indication reception and forwarding during
SRNS relocation” about CSFB indication forwarding.

‘pre-redirection info’ check (from RAN2717) is also used as a precondition

for LTE redirection, because all UEs do not support CSFB Indication IE in
RRC: RRC CONNECTION REQUEST message.

If the both ‘pre-redirection info’ check and the CSFB detection

functionality are activated, then UE is allowed to be redirected to LTE, if at
least one of those conditions is fulfilled. If both are not activated, then just
the activated check matters.

Note: CSFB detection functionality and ‘pre-redirection info’ check are

added via EFS CR E1105.

Allowed services for Measurement Based LTE Layering are checked. The
service check follows the principles introduced by the RAN2717 Smart
LTE Layering feature, i.e. based on indication by RANAP: E-UTRAN
Service Handover IE.

RAN2980 Measurement Based LTE Layering feature is controlled by the

RNC on/off licence.

RAN2067 LTE Interworking (LTE cell reselection) is a pre-requisite for

RAN2980 Measurement Based LTE Layering.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 308(447)
Basic Call
 Functionality description

Please refer to RRM Handover Control FD for further details about

management parameters, preconditions for blind and measurement
based redirection and frequency selection for measurement and
redirection.

[Link] LTE support is needed from the UE

In order to command UE to measure LTE neighbour frequencies, UE must

support the LTE (FDD/TDD) that is used in neighbour LTE cells.
<Internal/Begin> That is checked in the same way as defined in chapter
‘LTE support is needed from the UE’ of RAN2717 Smart LTE Layering.
<Internal/End>

UE must also support measuring LTE neighbour frequencies. UE

indicates the measurement support during RRC connection establishment
in RRC: RRC CONNECTION SETUP COMPLETE message:

▪ <Internal/Begin> If the UE supports E-UTRA , the Multi-

mode/Multi-RAT Capability IE in the UE Radio Access Capability
IE and the Measurement Capability Extension IE in the UE Radio
Access Capability Extension IE indicates the support for E-UTRA
FDD/TDD, the E-UTRA frequency bands which the UE can
measure and the need for compressed mode per each E-UTRA
Frequency band in order to perform measurements on E-UTRA
frequency band in question. UE supporting E-UTRAN
measurements does not include the EUTRA Feature Group
Indicators IE in UE Multi-mode/Multi-RAT Capability IE or it sets
the bit ‘EUTRAN measurements and reporting in connected
mode’ as ‘true’ in there. If the ‘EUTRAN measurements and
reporting in connected mode’ bit is set as ‘false’, then UE does
not support LTE measurements at all, no matter what is
indicated in Measurement Capability Extension IE. Note: EUTRA
Feature Group Indicators IE check is added via EFS CR E1153,
and E-UTRA measurements extension IE and E-UTRA
measurements extension 1 IE are added via EFS CR#E1381.
<Internal/End>

UE multi-mode/multi-RAT capability ([Link])

Information Need Multi Type Semantics Version
Element/Group name and description
Referen
ce

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 309(447)
Basic Call
 Functionality description

Support of E-UTRA CV- Enumera Absence of this IE REL-8

FDD not_iRA ted means that the UE
T_HoInf (DoesSu does not support E-
o2 pportEU UTRA FDD
TRAFDD
)
Support of E-UTRA CV- Enumera Absence of this IE REL-8
TDD not_iRA ted means that the UE
T_HoInf (DoesSu does not support E-
o2 pportEU UTRA TDD
TRATDD
)
EUTRA Feature Group CV- Bit string The definitions of the REL-8
Indicators not_iRA (4) bits are described in
T_HoInf Annex E
o2

EUTRA Feature group indicators (Annex E)

Index of Definition Notes

indicator (description of the supported functionality, if indicator set
(bit to ‘true’)
number)
1 - UTRA CELL_PCH to EUTRA RRC_IDLE cell
(leftmost reselection
bit) - UTRA URA_PCH to EUTRA RRC_IDLE cell
reselection
2 EUTRAN measurements and reporting in connected
mode
3 - UTRA CELL_FACH absolute priority cell reselection for
high priority layers
4 - UTRA CELL_FACH absolute priority cell reselection for
all layers

Measurement capability extension (10.3.3.21a)

Information Need Multi Type and Semantics description Version
Element/Group name reference
E-UTRA measurements CV- 1 to Note 1 REL-8
eutra_su <maxFre
p qBands
EUTRA>
>E-UTRA Frequency MP Integer As defined in [64]. If the REL-8
band (1..64) IE indicates a value of
64, then the E-UTRA
Frequency band for this
instance should be read
from the corresponding
instance of IE "E-UTRA
Frequency band
extension" in the E-
UTRA measurements
extension.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 310(447)
Basic Call
 Functionality description

Information Need Multi Type and Semantics description Version

Element/Group name reference
>Need for compressed MP Boolean TRUE means that the REL-8
mode UE requires DL and UL
compressed mode in
order to perform
measurements on E-
UTRA frequency band
indicated by the IE "E-
UTRA Frequency band"
E-UTRA measurements CV- 1 to Note 1 REL-11
extension extende <maxFre
d_eutra_ qBands
sup EUTRA>
>E-UTRA Frequency MP Integer As defined in [64]. REL-11
band extension (65..256) Note 2
E-UTRA measurements CV- 1 to Note 1 REL-11
extension 1 extende <maxFre
d_meas qBands
_eutra_s EUTRA-
up ext>
>E-UTRA Frequency MP Integer As defined in [64]. The REL-11
band extension 1 (1..256) value of 64 is reserved
and shall not be used.

>Need for compressed MP Boolean TRUE means that the REL-11

mode UE requires DL and UL
compressed mode in
order to perform
measurements on E-
UTRA frequency band
indicated by the IE "E-
UTRA Frequency band
extension 1"
Note 1:Indicates E-UTRA bands supported and the need for compressed mode, E-UTRAN
measurement support may be separately indicated as specified in Annex E.
Note 2:If the corresponding instance of IE "E-UTRA Frequency band" does not indicate the reserved
value of 64, then the UE can signal any valid value of IE "E-UTRA Frequency band extension".

Condition Explanation
eutra_sup At least one of these IEs is mandatory present if the
IE "Support of E-UTRA" has the value TRUE.
Otherwise these fields are not needed in the
message.
extended_eutra_sup At least one of these IEs is mandatory present if the
IE "Support of E-UTRA" has the value TRUE and the
UE supports a E-UTRA frequency band greater than
64. Otherwise these fields are not needed in the
message.
extended_meas_eutra_sup At least one of these IEs is mandatory present if the
IE "Support of E-UTRA" has the value TRUE and the
UE needs to report E-UTRA measurement capability
for more than 16 E-UTRA bands. Otherwise these
fields are not needed in the message.

During RRC connection establishment UE radio access capabilities for E-

UTRA are explicitly requested by UE Specific RRC, when UE is at least
3GPP Rel-8 version. <Internal/Begin> UE’s E-UTRA frequency band
support checking is not behind a PRFILE parameter as defined in chapter
‘LTE band support is needed from the UE’ of RAN2717 Smart LTE
Layering .
Request to UE about E-UTRA radio access capabilities is done in the
same way as defined in chapter ‘UE’s supported LTE bands capabilities

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 311(447)
Basic Call
 Functionality description

are asked from the UE in RRC connection setup phase’ of RAN2717

Smart LTE Layering. <Internal/End>

UE Specific RRC stores the UE radio access capabilities for the duration
of UE RRC connection and forwards them to RRM as well.

[Link] Compressed mode configuration for LTE neighbour measurement on

BTS/DRNC and UE

When any of the four triggers has triggered and the trigger in question is
defined to use measurements, RRM initiates the LTE neighbour
measurement on UE. If CSFB detection is enabled for measurement
based redirection by the RNMOBI-CSFBDetection parameter (value 2),
then measurements can be started for CSFB detected UE, see chapter
“CSFB indication reception and forwarding during SRNS relocation”. If
CSFB detection is not enabled by the RNMOBI-CSFBDetection
parameter, then CSFB indication information has no effect to redirection.
If UE has indicated the need for compressed mode in order to perform
measurement on E-UTRA frequency band, RRM initiates compressed
mode (CM) configuration on BTS/DRNC and UE for LTE neighbour
measurement before initiating the actual LTE neighbour measurement.
On BTS and DRNC CM is applied on all radio links of active set.

UE Specific RRC configures BTS by sending the NBAP: RADIO LINK

RECONFIGURATION PREPARE message with Transmission Gap
Pattern Sequence Information IE. If DRNC cells are included in the UE
active set, DRNC is also configured with corresponding RNSAP message.
<Internal/Begin> New parameters/values for LTE neighbour
measurement are:

•Transmission Gap Pattern Sequence (TGPS) Identifier: value 4

•Transmission Gap Starting Slot Number, TGSN: fixed 10
•The length of the first Transmission Gap within the transmission
gap pattern expressed in number of slots, TGL1: fixed 10
• The duration of transmission gap pattern 1 in frames, TGPL1:
value 5
Other parameters in NBAP/RNSAP configuration messages are not
affected by this feature and they are used in legacy manner.
<Internal/End>

UE Specific RRC configures UE by sending the RRC: PHYSICAL

CHANNEL RECONFIGURATION message with DPCH Compressed
mode Info IE. However, if transport channels are reconfigured, RRC:
TRANSPORT CHANNEL RECONFIGURATION message is used
instead.
<Internal/Begin> New parameters/values for LTE neighbour
measurement are:

• Transmission Gap Pattern Sequence, TGPSI: value 4

• Transmission Gap pattern sequence Measurement Purpose,
TGMP: E-UTRA measurement

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 312(447)
Basic Call
 Functionality description

• Transmission Gap Starting Slot Number, TGSN: fixed 10

• The length of the first Transmission Gap within the transmission
gap pattern expressed in number of slots, TGL1: fixed 10
• The duration of transmission gap pattern 1 in frames, TGPL1:
value 5
Other parameters in RRC configuration messages are not affected by this
feature and they are used in legacy manner.

< PR073182/Begin>

When LTE CM measurements are activated for UE and network starts reconfiguration
procedures during ongoing LTE CM measurements, early release 8 UEs cannot
correctly handle reconfiguration procedures during ongoing LTE CM measurements.
PRFILE parameter 002:2134 RU40_MAINT_38 controls the following workarounds:

1. If a RRC reconfiguration message is sent to the UE during an ongoing LTE

measurements in HSPA call and the reconfiguration message includes DPCH
Compressed Mode Info IE with TGPS-ID and TGCFN only, the UE either crashes or
loses radio connection during or after the completion of the reconfiguration
procedure. HSPA Serving Cell Change procedures and HSPA channel switches are
possible affected scenarios.
• Workaround (WA1): When sending a RRC reconfiguration message to the
UE during ongoing LTE measurements, RNC sends DPCH Compressed
Mode Info IE including the full parameters for compressed mode.
2. If CPC is activated for a UE, UE crashes or loses radio connection when LTE
measurements are started.
• Workaround (WA2): If LTE measurements are to be started in Cell_DCH
state for release 8 HSPA call with CPC activated, RNC first deactivates
CPC before activating LTE measurements. CPC is reactivated in the next
reconfiguration procedure for the affected UE, assuming that LTE
measurements did not result in any redirection to LTE and the criteria for
allocating CPC are still met.
3. When Dual Cell is activated for a UE, RNC reconfigures UE to Single Cell HSDPA
before the activation of LTE measurements. If LTE measurements do not result in
any redirection to LTE, measurements are stopped and UE is immediately switched
back to Dual Cell HSDPA. Some UEs lose radio connection after this switch from
Single Cell to Dual Cell HSDPA.
• Workaround (WA3): If LTE measurements are stopped, RNC initiates a
forced state transition to Cell_FACH for affected Dual Cell capable UEs.
4. There has been seen an additional problem with certain UE model when WA1 was
activated and E-DCH TTI reconfiguration procedure is started during ongoing LTE
measurements. UE loses radio connection or crashes.
• Workaround (WA4): If LTE measurements are to be started, RNC first
reconfigures E-DCH TTI from 2ms to 10ms. Reconfiguration back to 2ms
during the measurement is denied.

Workarounds are controlled separately with the following PRFILE

parameter (002:2134 RU40_MAINT_38) values:

xxxx xxxx xxxx xxx0 all workarounds deactivated

xxxx xxxx xx1x xxx1 WA1 activated
xxxx xxx1 xxxx xxx1 WA2 activated
xxxx xx1x xxxx xxx1 WA3 activated
xx1x xxxx xxxx xxx1 WA4 activated

< NA05871096/Begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 313(447)
Basic Call
 Functionality description

When a LTE measurements are ongoing with E-DCH, then in case of serving cell change (E-
DCH stays in new serving cell), CM parameters are not asked to be reconfigured, if there is no
need to change CM parameters. Other reconfiguration cases and cases without E-DCH are not
affected. The WA1 for sending CM parameters for other cases than SCC is not affected.

The PRFILE parameter 002:2134 RU40_MAINT_38 is used to control use of the CM

parameters:

xxxx xxxx xxxx xxx0 no CM parameters in HSPA SCC, partial in other cases (all WAs
deactivated)
xxxx xxxx x000 xxx1 no CM parameters in HSPA SCC, partial in other cases
xxxx xxxx x010 xxx1 no CM parameters in HSPA SCC, full CM parameters in all other cases

The legacy way to use CM parameters is used also in the SCC case, if the 7th bit of the PRFILE
parameter 002:2134 RU40_MAINT_38 is set.

xxxx xxxx x001 xxx1 no HSPA CM parameters in any cases (undocumented

legacy)
xxxx xxxx x10x xxx1 partial HSPA CM parameters in all cases (legacy)
xxxx xxxx x11x xxx1 full HSPA CM parameters in all cases (legacy)

Partial CM parameters means that CM parameters sent in legacy implementation, i.e. TGPSI,
TGPS Status Flag and TGCFN of active TGPSs, are sent to UE in DPCH Compressed Mode
Info IE in RRC reconfiguration message. TGPS Identifier and TGCFN of active TGPSs are
sent to BTS in Active Pattern Sequence Information IE in NBAP RADIO LINK
RECONFIGURATION COMMIT message.

No CM parameters means that DPCH Compressed Mode Info IE is not sent to UE in RRC
MEASUREMENT CONTROL message and Active Pattern Sequence Information IE is not sent
to BTS in NBAP RADIO LINK RECONFIGURATION COMMIT message.
< NA05871096/End>

< PR073182/End>
<Internal/End>

UE Specific RRC activates CM in BTS/DRNC by sending the

NBAP/RNSAP: RADIO LINK RECONFIGURATION COMMIT message
<Internal/Begin> with Active Pattern Sequence Information IE, which
indicates the TGPS Identifier value 4.

[Link].1 Failure during compressed mode configuration on BTS/DRNC and UE

If BTS/DRNC rejects the CM configuration by sending NBAP/RNSAP:

RADIO LINK RECONFIGURATION FAILURE message with cause value
'Invalid CM settings' or UE rejects the CM configuration by sending RRC:
PHYSICAL/TRANSPORT CHANNEL RECONFIGURATION FAILURE
message, UE Specific RRC forwards the message to RRM. Compressed
mode failure handling in RRM follows the legacy functionality of the
capability based handover, see Handover Control FD.

If RNC as DRNC does not support requested CM configuration, e.g.

because HSUPA CM or 10 slot gap pattern is not supported in DRNC,
RRM in DRNC rejects the CM configuration to UE Specific RRC in DRNC,
which sends RNSAP: RADIO LINK RECONFIGURATION FAILURE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 314(447)
Basic Call
 Functionality description

message with cause value 'Invalid CM settings' to SRNC. UE Specific

RRC in SRNC forwards the message to RRM in SRNC. Compressed
mode failure handling in RRM follows the legacy functionality of the
capability based handover, see Handover Control FD.
<Internal/End>

[Link] LTE neighbour measurement initiation on UE

RRM commands UE Specific RRC to initiate the LTE neighbour

measurement on UE. UE Specific RRC sends RRC: MEASUREMENT
CONTROL message with IEs Measurement Command, Measurement
Reporting Mode, Inter-RAT Measurement and DPCH Compressed Mode
Status Info to UE.
<Internal/Begin> New parameters/values for LTE neighbour
measurement are:

Measurement reporting mode:

• Measurement Report Transfer Mode: Unacknowledged mode RLC

• Periodical Reporting / Event Trigger Reporting Mode: Periodical
reporting

Inter-RAT measurement:

• E-UTRA frequency list

o E-UTRA frequency removal
▪ Remove no frequencies: (no data)
o New frequencies
▪ E-UTRA carrier frequency
<CR#E1381/begin>
▪ EARFCN extension
<CR#E1381/end>
▪ Measurement Bandwidth: 50
• Inter-RAT measurement quantity
o E-UTRA
▪ Measurement quantity: RSRP
▪ Filter coefficient: not included -> UE uses default
value 0
• Inter-RAT reporting quantity
o E-UTRA
▪ Reporting quantity: both (‘both’ means that UE
reports both RSRP and RSRQ)
• Reporting cell status
o Report cells within active set or within virtual active set or
of the other RAT
▪ Maximum number of reported cells: 6
• Periodical reporting criteria
o Amount of reporting: Infinity
o Reporting interval: based on RRM parameter, see
Handover Control FD

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 315(447)
Basic Call
 Functionality description

DPCH Compressed Mode Status Info:

• TGPSI: value 4

<CR#E1381/begin>
If the EARFCN of the downlink carrier frequency is greater than 65535,
the EARFCN is included in the EARFCN extension IE and the value of the
E-UTRA carrier frequency IE is set to 65535. The EARFCN extension IE
is absent if the EARFCN of the downlink carrier frequency is 0 - 65534.
<CR#E1381/end>

Other parameters in RRC configuration message are not affected by this

feature and they are used in legacy manner.
<Internal/End>

[Link] LTE neighbour measurement reporting from UE

When RRC: MEASUREMENT REPORT message is received from UE,

UE Specific RRC forwards the measurement report including the E-UTRA
Measured Results IE to RRM. The E-UTRA Measured Results IE includes
the measured RSRP and RSRQ per each measured E-UTRA cell within
the measured E-UTRA Carrier Frequency.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 316(447)
Basic Call
 Functionality description

Information Need Multi Type and Semantics Version

Element/Group name reference description
E-UTRA measured results MP 1 to REL-8
list <maxReport
edEUTRAFre
qs>
>E-UTRA Carrier MP Integer EARFCN of the REL-8
Frequency (0..65535) downlink carrier
frequency [64]. If the
IE indicates a value
of 65535, then the
EARFCN for this
instance should be
read from the
corresponding
instance of IE
"EARFCN extension"
in the E-UTRA
measured results
extension list.
>Measured E-UTRA cells MP 1 to REL-8
<maxReport
edEUTRACel
lPerFreq>
>>Physical Cell Identity MP Integer REL-8
(0..503)
>>RSRP OP Integer This shall be REL-8
(0..97) reported if the “Inter-
RAT measurement
quantity” IE is set to
‘RSRP’ or the “Inter-
RAT reporting
quantity” IE is set to
‘both’.
RSRP is mapped to
a value between 0
and 97 [36.133].
>>RSRQ OP Integer This quantity shall be REL-8
(0..33) reported if the “Inter-
RAT measurement
quantity” IE is set to
‘RSRQ’ or the “Inter-
RAT reporting
quantity” IE is set to
‘both’.
RSRQ_00 to
RSRQ_33 in [36.133]
are mapped to the
value between 0 and
33. RSRQ_34 in
[36.133] is mapped
to the value 33.
>>E-UTRA Results for SI OP [Link] REL-9
Acquisition 8
E-UTRA measured results OP 1 to REL-11
extension list <maxReport
edEUTRAFre
qs>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 317(447)
Basic Call
 Functionality description

>EARFCN extension OP Integer EARFCN of the REL-11

(65536..2 downlink carrier
62143) frequency [64].

<CR#E1381/begin>
If the E-UTRA Carrier Frequency IE has a value of 65535, then the
EARFCN of the downlink carrier frequency for this instance should be
read from the EARFCN extension IE in the corresponding instance of the
E-UTRA measured results extension list.
<CR#E1381/end>

<Internal/Begin>

[Link].1 Failure during LTE neighbour measurement initiation on UE

If UE rejects the measurement command by sending RRC:

MEASUREMENT CONTROL FAILURE message with cause value
"unsupported measurement", UE Specific RRC forwards the message to
RRM. Handover Control marks the UE as incapable for performing LTE
neighbour measurement and does not request the UE to start LTE
neighbour measurement as long as it remains in Cell_DCH state.
<Internal/End>

[Link] UE redirection to LTE

UE Specific RRC commands UE to LTE in the same way as defined in

RAN2717 Smart LTE Layering, i.e. by sending RRC: RRC CONNECTION
RELEASE message with E-UTRA Target Info to UE, <Internal/Begin> see
chapter ‘Ordering UE to LTE layer by sending RRC: RRC CONNECTION
RELEASE message’ of RAN2717 Smart LTE Layering <Internal/End>.
The LTE target frequencies define qualified frequencies, which are those
frequencies whose measured RSRP power and RSRQ quality values are
better than threshold values. The ‘qualified frequencies’ are indicated in
the order of best quality (RSRQ level) first.

UE Specific RRC updates the counter M1006C310 RRC CONN

RELEASE LTE REDIR IN DCH "Number of RRC connection releases for
LTE redirection due to periodic trigger" after it has sent RRC: RRC
CONNECTION RELEASE message to the UE due to periodic trigger.

Redirections based on other triggers are updated to legacy counters

defined in RAN2717 Smart LTE Layering, <Internal/Begin> see chapter
’RAN2717 and RAN2943 new counters’ of RAN2717 Smart LTE Layering.
<Internal/End>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 318(447)
Basic Call
 Functionality description

[Link] Interaction with LTE neighbour measurement and ‘state change trigger’
to LTE

When LTE redirection with measurement is about to trigger based on

'state change trigger', LTE redirection and UE state change (from
Cell_DCH to CCH) is delayed until LTE neighbour measurement is done.
Reason is that UE dedicated resources are needed for LTE neighbour
measurement.
Therefore CM parameters are configured to BTS and UE first, if needed,
and then UE is commanded to perform LTE neighbour measurement.
If redirection decision is made based on measurement, LTE redirection is
done in legacy way with RRC: RRC CONNECTION RELEASE message.

If DCH compressed mode measurement for SRB + PS NRT DCH 0/0 is

activated, UE is reconfigured to SRB + PS NRT DCH 0/0 directly as there
is no need to keep the inactive resources reserved. Measurement is
started on SRB (DCH compressed mode measurement for SRB + PS
NRT DCH 0/0 is added via EFS CR E2241).

Blind redirection is done, if the trigger is defined to use LTE

measurement, but UE does not support LTE measurement (added via
EFS CR E1153).

If redirection decision is not made based on measurement, UE state is

transferred to CCH (either to Cell_FACH or directly to Cell/URA_PCH)
and DCH state dedicated resources of UE are released. If UE data
activity restarts during measurement, measurement is continued, but UE
is not redirected to LTE. At next inactivity trigger, measurement is started
again.

If RRC state change away from Cell_DCH happens due to failure, the
failure is handled in same way as when LTE layering features are not
active and no layering decision to LTE is done by UE Specific RRC. That
covers both blind and measurement based redirection. Failure cases
covered include e.g. the following ones:
• procedure wait time expiry
• RL failure indication from BTS
• UP RB RLC reset
• cell update from UE indicating radio link failure/RLC unrecoverable
error

[Link] Interaction with LTE neighbour measurement and ‘CTS trigger’ to LTE

When LTE redirection with measurement is about to trigger based on

'CTS trigger', CTS from HS(D)PA to DCH is done first to ensure UE's
connectivity to RNC. After that CM parameters are configured to BTS and
UE, if needed, and UE is commanded to perform LTE neighbour
measurement.

If the CTS leads DCH (0/0) and DCH compressed mode measurement for
SRB + PS NRT DCH 0/0 is activated, measurement is started on SRB

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 319(447)
Basic Call
 Functionality description

(DCH compressed mode measurement for SRB + PS NRT DCH 0/0 is

added via EFS CR E2241).
If in above case DCH compressed mode measurement for SRB + PS
NRT DCH 0/0 is not activated, measurement is not started, since it can
not be performed without any RB. As a consequence UE is redirected
blindly to LTE based on 'state change trigger' (added via EFS CR E1153).
Blind redirection is also done, if the trigger is defined to use LTE
measurement, but UE does not support LTE measurement (added via
EFS CR E1153).

If redirection decision is made based on measurement, UE Specific RRC

performs the LTE redirection in legacy way with RRC: RRC
CONNECTION RELEASE message.
If redirection decision is not made based on measurement, UE remains in
WCDMA with current radio resources.

[Link] Interaction with LTE neighbour measurement and ‘CS RAB release
trigger’ to LTE

When LTE redirection with measurement is about to trigger based on 'CS

RAB release trigger', CS RAB release is done first.
After CS RAB release is completed, it is ensured that there is at least one
PS RAB before LTE neighbour measurement is performed. Then CM
parameters are configured to BTS and UE, if needed, and UE is
commanded to perform LTE neighbour measurement.

If the remaining PS RAB after CS RAB release is NRT DCH 0/0 and DCH
compressed mode measurement for SRB + PS NRT DCH 0/0 is
activated, measurement is started on SRB (DCH compressed mode
measurement for SRB + PS NRT DCH 0/0 is added via EFS CR E2241).
If in above case DCH compressed mode measurement for SRB + PS
NRT DCH 0/0 is not activated, measurement is not started, since it can
not be performed without any RB. As a consequence UE is redirected
blindly to LTE based on 'state change trigger' (added via EFS CR E1153).
Blind redirection is also done, if the trigger is defined to use LTE
measurement, but UE does not support LTE measurement (added via
EFS CR E1153).
If redirection decision is made based on measurement, UE Specific RRC
performs the LTE redirection in legacy way with RRC: RRC
CONNECTION RELEASE message.

If redirection decision is not made based on measurement, UE remains in

WCDMA with current radio resources.

[Link] Interworking with other features

[Link].1 Interworking with Fast Dormancy RAN2136

If UE sends RRC: SIGNALLING CONNECTION RELEASE INDICATION

message with cause value “UE Request PS Data Session End” while LTE
neighbour measurement is ongoing, the SCRI message is ignored by UE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 320(447)
Basic Call
 Functionality description

Specific RRC and measurement reports are waited by RRM after which a
redirection decision is made. If it is decided not to redirect UE to LTE
based on measurement, UE state transition is judged by legacy means.

If LTE neighbour measurement is not ongoing when SCRI message with

cause value “UE Request PS Data Session End” is received from UE, it
leads to ‘state change trigger’ during which state change away from
Cell_DCH is delayed until LTE neighbour measurement is performed.
However if LTE measurement is not ongoing, since it did not lead to the
successful redirection to LTE, then new LTE measurement is not started
for UE. UE state transition is judged by legacy means.

If the trigger in question is parametrisized not to use measurement, UE

Specific RRC redirects UE blindly to LTE in legacy way.

[Link].2 Interworking with Fast Dormancy Profiling RAN2451

If UE sends RRC: SIGNALLING CONNECTION RELEASE INDICATION

message without cause value while LTE neighbour measurement is
ongoing or has not yet been started, UE Specific RRC transfers UE to Idle
state.

If the trigger in question is parametrisized not to use measurement, UE

Specific RRC redirects UE blindly to LTE in legacy way.

[Link].3 Interworking with CSFB

[Link].3.1 Connection request priorisation and counters for CSFB calls

UE includes the CSFB Indication IE in RRC: RRC CONNECTION

REQUEST message to indicate that RRC connection request is due to CS
call, which is redirected from LTE to WCDMA. RAN2980 provides
connection request priorisation and counters for CSFB calls.
<PR255362/begin>

If UE includes the CSFB Indication IE in RRC: RRC CONNECTION

REQUEST and the received establishment cause is other than
“Terminating Conversational Call” or “Emergency Call”, the UE specific
RRC selects the CCH or DCH mapping for SRBs for RRC connection
setup as if the received establishment cause was “Originating
Conversational Call”.

< PR255362/end>

UE Specific RRC <Internal/Begin> includes CSFB Indication in RNTI

allocation request and based on that information L3 Resource Control
provides high priority for the RRC connection request in question.
TIIPRB <Internal/End> updates the following counters <Internal/Begin>
based on ticket sent by UE Specific RRC <Internal/End>:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 321(447)
Basic Call
 Functionality description

• M1001C747: RRC SETUP ATT CSFB “Number of RRC

connection setup attempts for CSFB”
• M1001C748: RRC SETUP ACCESS FAIL CSFB “Number of RRC
connection setup/access failures for CSFB”
• M1001C749: RRC ACCESS RELEASE CSFB “Number of RRC
access releases for CSFB”
• M1001C750: RRC SETUP ATT REPEAT CSFB “Number of RRC
connection setup repetitions for CSFB”

<Internal/Begin> UE Specific RRC sends the Establishment Cause

indicated by UE in resource request for UE specific RRM. Also CSFB
Indication is forwarded to UE specific RRM within resource request.

UE Specific RRM handles CSFB call as it would be indicated to have

been caused by “Conversational call”:
- If the Establishment Cause indicates 'Emergency Call', UE specific RRM
sets the cause value to "emergency call". L2 priority and queuing time of
emergency call establishment is used for resource request towards Cell
Specific RRM.
- with all other received Establishment Cause values, UE specific RRM
sets the cause value to ‘Originating Conversational Call’. L2 priority and
queuing time of normal voice call establishment is used for resource
request towards Cell Specific RRM.

After admission decision, the CS call establishment continues according

to legacy way.

This functionality is a generic change in the SW. It is not under any

license or PRFILE control.
<Internal/End>

[Link].3.2 CSFB indication reception and forwarding during SRNS relocation

UE Specific RRC receives CSFB indication for CBFB detection

functionality in the following occasions on condition that CSFB detection
is enabled:
• within RRC: RRC CONNECTION REQUEST message as CSFB
Indication IE
• within RANAP: RELOCATION REQUEST message as CSFB
Information IE
o CSFB Information is encoded inside Source RNC to Target
RNC Transparent Container IE
o CSFB Information contains values “CSFB” and “CSFB High
Priority”, which is interpreted also as “CSFB”
o This case is valid during incoming SRNS Relocation and
during incoming PS handover (Relocation) from LTE, as
well
• within RANAP: Iu RELEASE COMMAND message as End Of
CSFB IE

CSFB indication is stored during the lifetime of RRC connection and also
forwarded to RRM.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 322(447)
Basic Call
 Functionality description

When CSFB detected UE is relocated under different RNC, UE Specific

RRC includes CSFB indication for target RNC on condition that CSFB
detection is enabled.
UE Specific RRC encodes CSFB Information IE as “CSFB” within Source
RNC to Target RNC Transparent Container IE inside RANAP:
RELOCATION REQUIRED message.

[Link].4 Interworking with Layering in RRC Connection Release RAN2135

If redirection to LTE is possible to be done, then layering to other

WCDMA frequency is not done. If redirection to LTE is not possible to be
done, then layering to other WCDMA frequency is done, if possible.

<Internal/Begin>

[Link] RRC connection re-establishment during LTE neighbour measurement

If UE loses the radio connection due to radio link failure in Cell_DCH state
while LTE neighbour measurement is ongoing, RRC connection re-
establishment is performed according to the legacy implementation after
UE performs cell reselection by sending RRC: CELL UPDATE message
to RNC. LTE neighbour measurement is initiated according to new trigger,
if it occurs.
Similar handling is also valid for RLC re-establishments during ongoing
LTE measurement.
<Internal/End>

[Link] CS RAB establishment during LTE neighbour measurement

If RANAP: RAB ASSIGNMENT REQUEST message is received from CS

CN while LTE neighbour measurement is ongoing, measurement
continues and CS RAB is established according to legacy implementation.
The received measurement results are not used to redirect the UE to LTE.
Redirection to LTE is reconsidered after CS RAB is released.

[Link] Interworking with Iu release

If RANAP: IU RELEASE COMMAND message is received from CN during

LTE compressed mode measurements, RRC connection release is
initiated without redirecting the UE to LTE system.
If the ‘RRC state change trigger’ is defined not to use LTE compressed
mode measurements, RRC connection release is triggered to redirect the
UE blindly to LTE system.
UE is redirected blindly to LTE also in case when the ‘RRC state change
trigger’ is defined to use LTE compressed mode measurements, but
measurement can not be performed without any RB (added via EFS CR
E1153).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 323(447)
Basic Call
 Functionality description

[Link] UE is not redirected to LTE after emergency call

Redirection is not triggered for a UE in the following four emergency call

cases as long as the RRC connection exists.
Emergency call detection methods are listed in Admission Control FD
chapter “Emergency call detection methods”.

<Internal/Begin> The functionality, including the control and emergency

call identification, follows the same principles as specified in chapter
‘Redirection to LTE is not triggered in emergency call cases’ of RAN2717
Smart LTE Layering .
<Internal/End>

[Link] Interworking with CPC - Continuous Packet Connectivity RAN1644

LTE measurement due to inactivity is prioritised over the extended

inactivity timers for CPC user (InactCPCBatOptT, InactCPCNoBatOptT
parameters) or
non-CPC user (InactNonCPCBatOptT, InactNonCPCNoBatOptT
parameters). LTE measurement is started instead of starting these
extended inactivity timers.

If LTE measurement does not lead to the successful redirection/handover

to LTE and UE stays in WCDMA, the extended timers are started
according to the CPC feature.
If DCH compressed mode measurements on SRB + PS NRT DCH 0/0
don’t lead to successful redirection to LTE, UE is transferred to CCH
states, and extended timer is not started (DCH compressed mode
measurement for SRB + PS NRT DCH 0/0 is added via EFS CR E2241).

If extended timer is running, then LTE measurements are not started.

<RAN2980/End>

<RAN2930/begin>
<internal/begin>

2.3.40 RAN2930 IMSI-based Call Monitoring

This feature introduces collection of Control, User and Transport planes

monitoring data for individual calls based on given IMSI numbers. The
data capturing, processing and analyzing is done with the help of External
Monitoring Tool having graphical user interface, running on standard
Windows PC and connected remotely to the monitored RNC. The main
benefit of this feature is that it allows small size of the monitored data
while provides comprehensive monitored data content for individual
monitored calls.

Monitored data content:

• Control Plane in control plane processing units (ICSU in IPA-RNC

and USCP in mcRNC):

• DMX messages from most of call handling program families.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 324(447)
Basic Call
 Functionality description

• The families monitored in CP are: rrcprb, iuvprb, iurprb, l3ccmp,

uerprb, nrrprb, nrmprb, ha3prb

• User Plane in user plane processing units (DMPG/DSP in IPA-

RNC, not supported in mcRNC)

• Protocol headers on Iu-PS, IU-CS, Iub and Iur

• Internal messages related to L3-L2 interfaces

• Transport Plane in transport plane processing units (NPGE in IPA-

RNC, not supported in mcRNC)

• Protocol headers on Iu-PS, IU-CS, Iub and Iur

This feature has internal and public versions. While the monitored data
content is the same in both versions, the public version of this feature
provides limited presentation of data in External Monitoring Tool.

RAN2930 IMSI-based Call Monitoring is an optional feature (ASW) and it

is controlled by RNC license key "Call based monitoring'. Type of the
license key is on/off license.

When the internal version of the External Monitoring Tool uses the
feature, there is no need for a license.

This feature is an extension of RAN2631 Call Based Monitoring -

Advanced internal feature which provided basic Transport Plane protocol
headers monitoring for individual calls based on given IMSI numbers.

[Link] Control Plane monitoring

[Link].1 Monitoring activation

The External Monitoring Tool provides the monitoring conditions,

maximum and minimum threshold values for overload control and list of
IMSIs to the Centralized Monitoring Entity (CME) at the RNC.

The Centralized Monitoring Entity (CME) sends the interested IMSI(s) to

the Centralized Resource Control (RC3) which adds the IMSI(s) to be
monitored to its monitored IMSI table. The Centralized Resource Control
updates the list to the Decentralized Resource Control (RC3).

The Centralized Monitoring Entity sends the list of planes to be monitored

to the Centralized Resource Control which sends the same to the
Decentralized Resource Control.

The Decentralized Resource Control updates the list of planes to be

monitored to the UE specific RRC which in turn forwards it to the TRM
entity.

Monitoring is considered to be active in an RNC if the Centralized

Resource Control has a list of IMSIs to be monitored. On startup of a
control plane functional unit, the Decentralized Resource Control checks

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 325(447)
Basic Call
 Functionality description

from the Centralized Resource Control if there is an IMSI list to be

monitored.

NOTE: Dynamic changing of the IMSI list not allowed. If monitored IMSI
list need to be changed, all monitoring need to be stopped and then a
new IMSI list provided. Also starting of monitoring of ongoing calls is not
supported.

[Link].2 Monitoring deactivation

When the monitoring is deactivated by the user, the monitoring interface

control unit detects disconnection from External Monitoring Tool and
notifies the Centralized Resource Control.

The Centralized Resource Control sends the stop monitoring indication to

the Decentralized Resource Control on the functional units handling the
calls.

The Decentralized Resource Control sends the stop monitoring to the UE

specific RRC hands (MCC) of the monitored IMSI’s which notify all related
call specific L3 hands to stop the ongoing monitoring.

The UE specific RRC hand sends a resource bearer modification

message to the TRM. The TRM notifies stop monitoring to the correct set
of services in the relevant User Plane functional unit.

[Link].3 Maintaining monitoring status

The Decentralized Resource Control (RC3) updates the hand monitoring

status to UE specific RRC. After the call has been created, the status is
updated to all subsequently created hands.

When a hand participating in the call gets the indication that monitoring
status has changed, it updates the status to platform monitoring service
and forwards the status update message downstream to the other existing
hand processes participating in the same call.

The hand monitoring status has the following values:

• Before the start of monitoring,

o the status is “monitoring not activated”.
• After the start of monitoring
o For hands handling calls whose IMSI is not yet identified,
the status is “unknown”.
o For hands handling interested calls, the status is
“monitored”.
o For hands handling uninterested calls, the status is “not
monitored”.

When a monitored UE is moved to Cell_DCH state from

Cell_FACH/Cell_PCH, the new hands that are started are also monitored.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 326(447)
Basic Call
 Functionality description

[Link].3.1 Updating monitoring status after IMSI has been received

When an IMSI received from the Core Network in the RANAP: COMMON
ID in the mandatory IE: “Permanent NAS UE Identity", the Decentralized
Resource Control checks if it is an interested IMSI or not. The
Decentralized Resource Control notifies the UE specific RRC to update its
status to monitored/not monitored.

The UE specific RRC hands update the platform message monitoring

services about the monitoring status change and forward the status
update message to other existing hand processes serving that call. The
status update is also forwarded to the User Plane and Transport Plane by
the TRM entity.

NOTE: Monitoring in DRNC is not supported.

<internal/end>
<RAN2930/end>

<RAN2510/begin>

2.3.41 RAN2510 In-Bearer Application Optimization

RAN2510 In-Bearer Application Optimization is be used for DL NRT RABs and is

applied for R99 user in Cell_FACH or Cell_DCH state, HS-FACH users and HSDPA
users in Cell_DCH state traffic in RNC.

User traffic marked latency sensitive has different queue and is prioritized ahead of
non-latency sensitive traffic inside RNC. There are two queues in the RNC PDCP layer;
one for packets marked as latency sensitive called high priority queue and the second
one for non-latency sensitive packets called low priority [Link] RNC PDCP layer the
user flow is prioritized according to Deep packet inspection (DPI) marking received
from the core network. DPI engine in CN marks inner IP packets headers with DSCP
values which are delivered along with the data to PDCP in RNC. According the DSCP
values the data is then mapped to PDCP queues, one for packets marked as latency
sensitive called high priority queue and the second one for non-latency sensitive
packets called low priority queue. PDCP serves high priority queue with bigger weight
that is Weighted Fair Queuing, resulting in high priority packets get relatively higher
bandwidth and lower delay than low priority packets. (For more details please refer to
“58/ User Plane FDd” and ”57/ PDCP FDd”).

RAN2510 In-Bearer Application Optimization can be enabled/disabled using RNC level

RNP parameter “InBearerAppPrioEnabled (In Bearer Application Priority Enabled)” and
RAN2510 license. If RNP parameter “InBearerAppPrioEnabled” is set to enabled and
RN2510 license is on , feature is activated in RNC.

<internal/begin>

L3/Transport Resource Manager reads the license and activation parameter of In-
Bearer Application Optimization and sends the RAN2510 feature activation and
RAN2510 specific configuration parameters to PDCP whenever PDCP entity is
created.L3/Transport resource manager reads parameters “InBearerAppPrioEnabled”,
“IBAODSCPHighPrioQPart1”, “IBAODSCPHighPrioQPart2” and
“IBAOHighQueueWeight” from RNW database and send these parameters to RNC

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 327(447)
Basic Call
 Functionality description

Layer2 along with feature activation information while configuring this functionality to
RNC Layer2. Parameters are defined in RRM FD (35/ HSDPA RRM in RNC FD).

<internal/end>

<RAN2510/End>

<RAN2496/Begin>

2.3.42 RAN2496 Minimization of Drive Tests (MDT)

The RAN2496 Minimization of Drive Tests (MDT) feature provides

collection of periodic Rx-Tx Time Difference, GPS, SIR, SIR Error and
RTT measurements for the Megamon workstation in addition to periodic
CPICH EcNo/CPICH RSCP, UE Tx Power and DL BLER measurements
provided by the RAN2778 UE Periodic Measurement Report feature.

The network operator can select the quantities to be measured. The

periodic measurement reporting for UE Periodic Measurement Report
(alias Minimization of Drive Tests, MDT) purpose can be enabled for UEs
which have CS RAB or CS + PS multiRAB established, or for all UEs
regardless of the RAB configuration. The reporting period is configurable.
When the feature is activated in a cell, then UEs with the specified RAB
configuration in that cell of the RNC are ordered to perform selected
measurements if RNC processing load is not too high. Handover Control
starts periodic Rx-Tx Time Difference, CPICH EcNo/CPICH RSCP and
GPS measurements (see HC FD), UE Specific RRC/RRC-D starts
periodic UE Tx Power and UE Quality measurements and NBAP
signalling entity starts periodic SIR, SIR Error and RTT measurements
(see NBAP and RNSAP Procedures FD).

RAN2496 Minimization of Drive Tests (MDT) replaces the old RAN2778

UE Periodic Measurement Report feature. RAN2496 provides the same
UE measurements as RAN2778, but with added functionality and includes
also measurements done by BTS.

Note: UE specific RRC/CCM(L3C) is the one that actually checks which

measurements have been requested by the operator and if the feature is
active or not and it then provides this info to RRC-D, HC and NBAP for
actual measurement handling/decision making.

[Link] Starting of periodic DL BLER measurement

The UE specific RRC/RRC-D starts the periodic DL BLER measurement

for UE Periodic Measurement Report (alias Minimization of Drive Tests,
MDT) purpose for the UE if periodic DL BLER measurement is not
already started for other purposes and all of the following conditions are
true:

• RAN2778 ‘UE Periodic Measurement Report' license state is ‘ON’

in RNC

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 328(447)
Basic Call
 Functionality description

• IMSI specific MDT is enabled for the UE (Trace Type = MDT or

MDTGPS), or periodic DL BLER measurement is enabled for the
current RAB combination with the WCEL parameter
MDTPeriodicMeasEnabled in one or more active set cells
controlled by the serving RNC (cell specific MDT):

o When Bit2 (DL BLER) of the WCEL parameter

MDTPeriodicMeasEnabled is set to 1 and Bit7 (Call Type
Selection) of the WCEL parameter
MDTPeriodicMeasEnabled is set to 0, the periodic DL
BLER measurement is enabled in the cell for calls that
have CS RAB or CS + PS multi-RAB(s).

o When Bit2 (DL BLER) and Bit7 (Call Type Selection) of the
WCEL parameter MDTPeriodicMeasEnabled are set to 1,
the periodic DL BLER measurement is enabled in the cell
for all calls with at least one RAB. That RAB can be single-
CS or single-PS or CS + PS multi-RAB(s). Standalone
SRB is not measured for cell specific MDT.

• There has not been any emergency call related activity during the
RRC connection. Emergency call detection methods are listed in
Admission Control FD chapter “Emergency call detection
methods”.

• Average CPU load over 1 minute period in the unit where the UE
specific RRC/RRC-D resides is lower than or equal to the value of
the RNC parameter UePeriodicMeasCpuLimit. This condition
concerns only cell specific MDT. IMSI specific MDT is activated
regardless of the load of the own unit.

The UE specific RRC/RRC-D checks these conditions after RAB

setup/release, State transition to CELL_DCH state, Active set update,
Intra-RNC inter-frequency handover, Incoming inter-RAT handover and
Incoming SRNC relocation (UE involved or UE not involved) procedures.
The reporting interval of the periodic DL BLER measurement for UE
Periodic Measurement Report purpose is controlled with the RNC
parameter UePeriodicMeasInterval.

<internal/begin>

If the UE specific RRC/RRC-D receives the RRC: MEASUREMENT

CONTROL FAILURE message from the UE when it tries to start the
periodic DL BLER measurement for MDT purpose, then the UE specific
RRC/RRC-D does not retry to start the periodic DL BLER measurement
for MDT purpose for the UE as long as it stays in CELL_DCH state.

When UE send s the RRC: MEASUREMENT REPORT message with

periodic DL BLER measurement result for MDT purpose to the RNC, the
UE specific RRC/RRC-D decodes the message, packs the measurement
report to RNC internal message and forwards the RNC internal message
to a non-existent process id 0xFF00 so that the measurement reports are
visible in the Emil tool and the Megamon is able to collect the
measurement reports.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 329(447)
Basic Call
 Functionality description

<internal/end>

[Link] Stopping of periodic DL BLER measurement

The UE specific RRC/RRC-D stops the periodic DL BLER measurement

for the UE if it is needed only for UE Periodic Measurement Report (alias
Minimization of Drive Tests, MDT) purpose and one (or more) of the
following conditions becomes true:

• Active set changes so that none of the active set cells have
periodic DL BLER measurement enabled for the current RAB
combination with the WCEL parameter MDTPeriodicMeasEnabled
(cell specific MDT), or all active set cells are controlled by a DRNC
(cell and IMSI specific MDT). The active set can change through
active set updates, intra-RNC inter-frequency handover or inter-
frequency handover from SRNC to DRNC over Iur. In this case,
the RRC/RRC-D does not stop the periodic DL BLER
measurement until a 5 second hold-up time has elapsed.

• Periodic DL BLER measurement is not enabled after RAB

setup/release for the current RAB combination with the WCEL
parameter MDTPeriodicMeasEnabled (cell specific MDT). In this
case the UE specific RRC/RRC-D stops the periodic DL BLER
measurement immediately regardless of whether the 5 second
hold-up time after ASU exist or not.

• Emergency call is setup for the UE. Emergency call detection

methods are listed in Admission Control FD chapter “Emergency
call detection methods”.

<internal/begin>

After incoming relocation (UE involved/UE not involved) UE Specific

RRC/RRC-D always first releases the possibly ongoing periodic DL BLER
measurement based on the UE measurement list in the RRC Container.
Next the UE Specific RRC/RRC-D checks if condition for starting periodic
DL BLER measurement for UE Periodic Measurement Report purpose is
met.

<internal/end>

[Link] Interaction with RCPM and Subscriber Trace features

When UE Specific RRC/RRC-D receives UE Quality Measurement

request from RCPM or Subscriber Trace and the UE Quality
measurement is already ongoing due to UE Periodic Measurement Report
(alias Minimization of Drive Tests, MDT), the measurement can be kept
ongoing without any modifications.

If UE Quality measurements are needed for RCPM/Subscriber Trace

purposes and also for MDT purposes, the measurement is not released
by UE Specific RRC/RRC-D even if it is not anymore needed for
RCPM/Subscriber Trace purposes.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 330(447)
Basic Call
 Functionality description

If UE Quality measurements are ongoing due to MDT purposes and those

are also needed for RCPM/Subscriber Trace purposes and later if there is
no need to have UE Quality measurements for MDT purposes anymore,
then UE Quality measurement is not stopped/released because it is still
needed for RCPM/Subscriber Trace purposes.

UE Specific RRC/RRC-D does not update M1018 counters, if the UE

Quality measurements are started due to UE Periodic Measurement
Report only.

[Link] Starting of periodic UE Tx Power measurement

The UE specific RRC/RRC-D starts periodic UE Tx power measurement

for UE Periodic Measurement Report (alias Minimization of Drive Tests,
MDT) purpose for the UE when all of the following conditions are true:

• RAN2778 ‘UE Periodic Measurement Report' license state is ‘ON’

in RNC

• IMSI specific MDT is enabled for the UE (Trace Type = MDT or

MDTGPS), or periodic UE Tx power measurement is enabled for
the current RAB combination with the WCEL parameter
MDTPeriodicMeasEnabled in one or more active set cells
controlled by the serving RNC (cell specific MDT):

o When Bit1 (UE Tx Power) of the WCEL parameter

MDTPeriodicMeasEnabled is set to 1 and Bit7 (Call Type
Selection) of the WCEL parameter
MDTPeriodicMeasEnabled is set to 0, the periodic UE Tx
power measurement is enabled in the cell for calls that
have CS RAB or CS + PS multi-RAB(s).

o When Bit1 (UE Tx Power) and Bit7 (Call Type Selection) of

the WCEL parameter MDTPeriodicMeasEnabled are set to
1, the periodic UE Tx power measurement is enabled in
the cell for all calls with at least one RAB. That RAB can be
single-CS or single-PS or CS + PS multi-RAB(s).
Standalone SRB is not measured for cell specific MDT.

• There has not been any emergency call related activity during the
RRC connection. Emergency call detection methods are listed in
Admission Control FD chapter “Emergency call detection
methods”.

• Average CPU load over 1 minute period in the unit where the UE
specific RRC/RRC-D resides is lower than or equal to the value of
the RNC parameter UePeriodicMeasCpuLimit. This condition
concerns only cell specific MDT. IMSI specific MDT is activated
regardless of the load of the own unit.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 331(447)
Basic Call
 Functionality description

The UE specific RRC/RRC-D checks these conditions after RAB

setup/release, State transition to CELL_DCH state, Active set update,
Intra-RNC inter-frequency handover, Incoming inter-RAT handover and
Incoming SRNC relocation (UE involved or UE not involved) procedures.
The reporting interval of the periodic UE Tx Power measurement for UE
Periodic Measurement Report purpose is controlled with the RNC
parameter UePeriodicMeasInterval.

<internal/begin>

The UE specific RRC/RRC-D ensures that the number of different L3

filters to be configured to the UE does not exceed the maximum of two L3
filters for UE internal measurement type. This is done by using fixed L3
filtering (fc19_c) for periodical UE Tx Power measurement.

The mandatory and optional IEs to be transmitted in the RRC:

MEASUREMENT CONTROL message are described in the table below:

Message Type MEASUREMENT CONTROL

RRC transaction identifier RRC signalling entity allocates
Integrity check info RRC signalling entity allocates
Measurement Identity RRC signalling entity allocates
Measurement Command Setup
Measurement Reporting
Mode
> Transfer Mode Unacknowledged mode RLC
> Reporting Mode Periodical reporting
Measurement type UE internal measurement
Measurement quantity UE Transmitted Power
Filter coefficient L3 filtering of periodical UE Tx Power measurement is fixed
fc19_c and cannot be controlled by any RNP parameter.
Reporting quantity
> UE Transmitted Power TRUE.
> UE Rx-Tx time FALSE
difference
Reporting criteria Periodical reporting criteria
> Amount of reporting Infinity
> Reporting interval The parameter RNC-UePeriodicMeasInterval defines the
reporting interval for all MDT measurements.

If the UE specific RRC/RRC-D receives the RRC: MEASUREMENT

CONTROL FAILURE message from the UE when it tries to start the
periodic UE Tx Power measurement for MDT purpose, then the UE
specific RRC/RRC-D does not retry to start the periodic UE Tx Power
measurement for MDT purpose for the UE as long as it stays in
CELL_DCH state.

When UE sends the RRC: MEASUREMENT REPORT message with

periodic UE Tx Power measurement result for MDT purpose to the RNC,
the UE specific RRC/RRC-D decodes the message, packs the
measurement report to RNC internal message and forwards the RNC
internal message to a non-existent process id 0xFF00 so that the

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 332(447)
Basic Call
 Functionality description

measurement reports are visible in the Emil tool and the Megamon is able
to collect the measurement reports.

<internal/end>

[Link] Stopping of periodic UE Tx Power measurement

The UE specific RRC/RRC-D stops the periodic UE Tx Power

measurement for UE Periodic Measurement Report (alias Minimization of
Drive Tests, MDT) purpose for the UE when one (or more) of the following
conditions becomes true:

• Active set changes so that none of the active set cells have
periodic UE Tx Power measurement enabled for the current RAB
combination with the WCEL parameter MDTPeriodicMeasEnabled
(cell specific MDT), or all active set cells are controlled by a DRNC
(cell and IMSI specific MDT). The active set can change through
active set updates, intra-RNC inter-frequency handover or inter-
frequency handover from SRNC to DRNC over Iur. In this case,
the RRC/RRC-D does not stop the periodic UE Tx Power
measurement until a 5 second hold-up time has elapsed.

• Periodic UE Tx Power measurement is not enabled after RAB

setup/release for the current RAB combination with the WCEL
parameter MDTPeriodicMeasEnabled (cell specific MDT). In this
case the UE specific RRC/RRC-D stops the periodic UE Tx Power
measurement immediately regardless of whether the 5 second
hold-up time after ASU exist or not.

• Emergency call is setup for the UE. Emergency call detection

methods are listed in Admission Control FD chapter “Emergency
call detection methods”.

<internal/begin>

After incoming relocation (UE involved/UE not involved) UE Specific

RRC/RRC-D always first releases the possibly ongoing periodic UE Tx
Power measurement based on the UE measurement list in the RRC
Container. Next the UE Specific RRC/RRC-D checks if condition for
starting periodic UE Tx Power measurement for UE Periodic
Measurement Report purpose is met.

<internal/end>

[Link] UE measurements are not started in case of emergency call

The UE Specific RRC/RRC-D does not activate the UE measurements for

UE Periodic Measurement Report (alias Minimization of Drive Tests,
MDT) purpose in case of emergency call. Emergency call detection
methods are listed in Admission Control FD chapter “Emergency call
detection methods”.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 333(447)
Basic Call
 Functionality description

[Link] Ongoing UE measurements are stopped if emergency call is setup

The UE Specific RRC/RRC-D stop all ongoing UE measurements for UE

Periodic Measurement Report (alias Minimization of Drive Tests, MDT)
purpose if emergency call is setup for the UE. Emergency call detection
methods are listed in Admission Control FD chapter “Emergency call
detection methods”.

[Link] Emergency call is identified from RAB parameters of CS call

The RNW database parameters determine how CS call is identified as an

emergency call. A CS call is identified as an emergency call if its
Allocation/Retention Priority parameters match with the values of the
following RNW database parameters:

• Pre-emption capability with the value of the RNAC parameter

EmeCallPCIValue. Pre-emption capability is not considered to be
a factor in identifying emergency calls if the value of this
parameter is "Pre-emption capability is not considered".

• Pre-emption vulnerability with the value of the RNAC parameter

EmeCallPVIValue. Pre-emption vulnerability is not considered to
be a factor in identifying emergency calls if the value of this
parameter is "Pre-emption vulnerability is not considered".

• Priority level with the value of the RNAC parameter

EmeCallLevelValue.

The RNW database parameters above can be modified online, that is, a
new value is taken into use for the calls that are set up after the
modification.

RAB parameters are not used for identifying emergency calls if the value
of the RNAC parameter EmeCallPCIValue is "RAB parameters are not
considered".

<internal/begin>

Rationale: Identification can be used also by other features than UE

Periodic Measurement Report (alias Minimization of Drive Tests, MDT) in
future.

<internal/end>

<RAN2496/end>

<CR E1181/Begin>

<internal/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 334(447)
Basic Call
 Functionality description

2.3.43 AMR Fault Detection at Userplane

Scope of CR#E1181 is to provide functionality to detect faulty AMR frames

(no recovery is planned as part of this CR). Noisy/corrupted voice calls
have been frequently reported during maintenance. There is currently no
error detection/recovery mechanism for such noisy voice call issues. With
this functionality, AMR fault statistics can provide information about what
logs for additional scenarios can be requested for further debugging and
investigation.

AMR fault detection is an optional functionality applicable to releases

RNC16, mcRNC16, RN8.1MNT, mcRNC4.1MNT. It is controlled via a
PRFILE parameter AMRFaultDetection. This functionality reuses the
existing CS Silent call detection framework.

When a CS AMR call is set up, L3 checks currently if CS silence call

detection fishing is enabled on PRFILE. Additionally, L3 checks if PRFILE
parameter AMRFaultDetection is enabled. If it is enabled and call is
connected, L3 commands L2 to start AMR fault detection functionality. L3
uses the existing message L2_start_fishing_s with a new fishing command
“AMR_FAULT_DETECT. L3 follows the NAS signaling after Radio Bearer
Setup Complete. L3 commands L2 to start AMR fault detection after NAS
signal “CONNECT” after AMR call setup.

During UE involved and UE not involved Relocations for CS call, L3 shall

command L2 to start AMR fault detection after Relocation Complete is sent
to CN if functionality is enabled with PRFILE parameter. Similar to the CS
silence detection, AMR fault detection is not needed to be started again by
L3 during AMR re-establishment and during AMR channel type switches
(DCH<->HSPA).

AMR Fault detection (AFD) is not applicable to CSVoHSPA. The fishing

framework for AFD however is in line with the existing Silent Call detection
framework i.e. fishing trigger is sent from L3 to L2 for both R99 and
CSVoHSPA calls as is the present implementation. Only the fault detection
is not done at L2 for CSVoHSPA call. Once fishing trigger is sent from L3
to L2, the AFD configuration is maintained till the end of the call. In case of
CTS from R99 → HS, L2 will stop AFD and if HS→R99 CTS happens, L2
will start AFD. More specifically, for an ongoing R99 call, when
RNC_RAB_TRANSPORT_SWITCH_S (CTS) is triggered from L3, L2
immediately stops AFD and if the switch is not successful, AFD is resumed.
For an ongoing CSVoHSPA call, after a CTS trigger, only after the
successful switch to R99 is done, AFD is started for the call at L2 (
“Successful switch" means deletion of old transport and "unsuccessful
switch" means deletion of new transport”).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 335(447)
Basic Call
 Functionality description

AMR fault detection is started and stopped by L3 similar to CS Silence

detection i.e. L3 sends the stop fishing command when RRC detects NAS
message CC:RELEASE, CC:HOLD ACK or CC:DISCONNECT or when
RRC receives IU Release Command from CN or when timer T314 for the
CS service re-establishment expires. L3 sends the start fishing command
when RRC detects NAS message CC:CONNECT or CC:RETRIEVE ACK
or when RRC sends Relocation Complete to CS CN from Target RNC in
SRNC Relocation, inter RNC HHO and ISHO.

HPL logging is done based on parameters received in “L2_fishing_data_s”.

If “fishing_command” is set to “AMR_FAULT_DETECT” then L3 checks the
direction from message “L2_fishing_data_s”. If direction is set to “UL/0”, L3
shall do the logging that AMR fault is detected for UL direction. If direction
is set to “DL/1”, L3 shall do the logging that AMR fault is detected for DL
direction. Also, HPL logging shall be filtered based on the received fault
statistics from L2 i.e. if l2_fishing_data_s message contains ‘0’ faults, no
logging is done. When L3 receives L2_fishing_data_s message L3 will
write the HPL log only if

cause = amr_fault_cause_t_fault_c OR

cause = amr_fault_cause_t_release_c AND

sid_first_err_count_ul > 0 OR

sid_first_err_count_dl > 0

In any other case L3 shall not write the HPL log

CSD loggings/fishing data (silence duration in a call) is filtered away for

certain specific scenarios (SRNC Relocation/Inter RNC HHO/Role
Switch/ISHO/Cell Update procedure/CS call re-establishment/RL
failure/DSCR sent/UE out of service). With AFD, idea is to record the
number of faulty frames during a call – lifetime of a call. So HPL loggings
for AFD can be simply aligned with L2 behavior i.e. for all those scenarios
when L2 sends fishing data, HPL logging can be enabled at L3 i.e. HPL
logging for AFD can be done during those scenarios where CSD logging
may be ignored, with the additional filtering that no HPL logging is done
when L2 reports zero faults.

L3 shall provide statistics (Number of UL AMR faults and Number of DL

AMR faults) per ICSU/USPU Unit via Test Message Mechanism based on
the AMR fault statistics received from Userplane at the time of call release.

<internal/end>

<CR E1017/End>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 336(447)
Basic Call
 Functionality description

2.3.44 RAN2892 WCDMA-LTE Load Balancing

<RAN2892/begin>

WCDMA-LTE Load Balancing feature is used to check if the incoming

handover from LTE is due to load reason, i.e., LTE cell is in high load.
This feature also detects if the handover to LTE has been rejected by
eNB as the target LTE cell is in high load. If it is determined that LTE cell
is in high load, then the LTE cell is put under penalty, and no handover is
initiated by RNC to that LTE cell during penalty time. If redirection to LTE
is being initiated, either blindly or based on measurements, then those
LTE cells which are under penalty and belong to LTE frequency layers
selected for redirection to LTE, are signalled as blacklisted cells to UE,
see Smart LTE Layering about signaling the blacklisted cells.

See Hard Handover and SRNS Relocation FD and Handover Control FD

for more details.

<RAN2892/end>

<RAN3082/begin>

2.3.45 RAN3082 Device detection

This feature enables device type detection in the RNC based on the IMEI
TAC (Type Allocation Code) and SVN (Software version) information. A
certain feature or functionality usage can be allowed or blocked for a set
of UE models based on device detection framework. The IMEI information
retrieval for the Device Detection is performed during the PS RAB setup
or after CS RAB setup by the RNC. Alternatively in case the core network
either provides the IMEI to RNC in RANAP: COMMON ID message or
core network has the IMEI query enabled the RNC is able to retrieve the
IMEISV information from the related NAS signalling.

8 digits 6 digits 2 digits

TAC SNR SVN

IMEISV 16 digits

Device Detection feature introduces Whitelist and Blacklist mechanisms

based on the IMEI TAC and SVN information. Whitelisting a feature
means that only the listed IMEI (TAC, SVN) codes are allowed to use the
feature. Blacklisting a feature means that defined IMEI codes are not
allowed to use the feature.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 337(447)
Basic Call
 Functionality description

The features, like for example RAN1644 Continuous Packet Connectivity,

or functionalities control has the following principles:
The feature or functionality allocations can be controlled with the
RAN3082 Device Detection framework. The framework always contains a
possibility to operate via Whitelist or Blacklist based definitions. The
feature can be kept available for the UE models that operate properly with
the feature. At the same time the feature can be blocked from the UE
models that for some reason do not work correctly with the given feature
even though claiming to have the capability.

Additionally for the UE model information collection RNC has a generic

IMEI query functionality implemented. This can be used to collect more
detailed UE model behaviour information from the network to detect the
need for example to block a certain UE model from the feature scope
temporarily.

The overview of the IMEI collection and feature operation concept is

presented in the figure.
Monitor, collect / Generic Manage / RAN3082
- Convert TAC inf o to
RNC RNW model
TÜV
TAC list collection f or - Activate Device
TAC Detection
example with Excel NetAct
Full TAC list

NWI3 CM plan RNW

interface plan
L3 Data Collector (XML)

(Monitoring)
GUI
Equipment OMS
registry (EIR)
Traf f ica reporting with BTS O&M
IMEI inf ormation

CN Traffica RNC Traffica (xx% out of calls)

RNC
(IMEI query (IMEI delivery
enabled at CN) from RNC)

[Link] Core may provide IMEI to RNC

Core side may give the IMEI info to RNC, so that UE specific RRC doesn't
need to ask it by itself from UE.

Core may include IMEI information into RANAP: COMMON ID message

inside ‘UESBI-IuA’ field in optional UESBI-Iu IE. If ‘UESBI-IuA’ field length
inside UESBI-Iu IE is 64 bits, it contains IMEI.

RANAP entity shall check if the IMEI information is in the

RANAP:COMMON ID message and provide the data to UE specific RRC
along with all the other parameters and UE specific RRC uses the
provided IMEI.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 338(447)
Basic Call
 Functionality description

Core may also ask IMEI from UE during RRC connection setup phase via
NAS signalling. The placement and used NAS message depends is the
action done by CS or PS core. If core asks IMEI from UE via NAS
signalling, UE specific RRC acquires the IMEI from the NAS signaling.

UE specific RRC checks NAS signalling content of each incoming RRC

UL DIRECT TRANSFER message for the presence of IMEI information to
find out wheter the Core side is asking the IMEI from UE during RRC
Connection setup or initial UE-Core service negotiation (e.g. before RAB
setup starts).

IMEI information may be present in following NAS messages (3GPP spec

24.008):
- MM: IDENTITY RESPONSE – this is used by CS core
- GPRS MM:AUTHENTICATION AND CIPHERING RESPONSE – this is
used by PS core

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 339(447)
Basic Call
 Functionality description

UE RRC-D MCC CN

RRC Connection setup has been signalled- RRC Connection Setup Complete may or may not has arrived.

RRC-D has info that IMEI

is needed

RRC Initial UE Message

RANAP: INITIAL UE MESSAGE

RANAP: COMMON ID

UE-Core signalling if needed – additional ciphering + service negoitiation etc

RANAP: SECURITY MODE COMMAND

RRC Security Mode command

RRC Security Mode Complete

RANAP: SECURITY MODE COMPLETE

RANAP: DIRECT TRANSFER (MM:IDENTITY REQUEST - IMESV)

RRC DL Direct Transfer (MM:IDENTITY REQUEST)

RRC UL Direct Transfer (MM:IDENTITY RESPONSE)

UE & Core may also start service
signalling while IMEI is being asked
RRC-D checks message is
auth+cipher and IMEI is included
RANAP: DIRECT TRANSFER (MM:IDENTITY RESPONSE -IMEISV)

IMEI to MCC

Now IMEI/TAC check can be done

And value stored for future use

RANAP: RAB ASSIGMENT REQUEST

Normal RRM checks, with possibly white/blacklist info provided, DSP&transmission

reservation and BTS signalling (if resources immediately reserved from BTS)

rrc_rab_setup_req_int__s

RRC Radio Bearer Setup

RRC Radio Bearer Setup Complete

rrc_rab_setup_complete_s

RANAP:RAB ASSIGMENT RESPONSE

IMEI query by CS Core

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 340(447)
Basic Call
 Functionality description

UE RRC-D MCC CN

RRC Connection setup has been signalled- RRC Connection Setup Complete may or may not has arrived.

RRC-D has info that IMEI

is needed

RRC Initial UE Message

RANAP: INITIAL UE MESSAGE

RANAP: COMMON ID

RANAP: DIRECT TRANSFER (GPRS MM:AUTHENTICATION AND CIPHERING REQUEST - IMESV)

RRC DL Direct Transfer (GPRS MM:AUTHENTICATION AND CIPHERING REQUEST)

RRC UL Direct Transfer (GPRS MM:AUTHENTICATION AND CIPHERING RESPONSE)

RRC-D checks message is

auth+cipher and IMEI is included
RANAP: DIRECT TRANSFER (GPRS MM:AUTHENTICATION AND CIPHERING RESPONSE-IMEISV)

IMEI to MCC

Now IMEI/TAC check can be done

And value stored for future use

RANAP: SECURITY MODE COMMAND

RRC Security Mode command

RRC Security Mode Complete

RANAP: SECURITY MODE COMPLETE

UE-Core signalling if needed – additional ciphering + attach + PDP contex etc

RANAP: RAB ASSIGMENT REQUEST

Normal RRM checks, with possibly white/blacklist info provided, DSP&transmission

reservation and BTS signalling (if resources immediately reserved from BTS)

rrc_rab_setup_req_int__s

RRC Radio Bearer Setup

RRC Radio Bearer Setup Complete

rrc_rab_setup_complete_s

RANAP:RAB ASSIGMENT RESPONSE

IMEI query by PS Core

<internal/begin>

RRC-D is doing NAS signaling check already by default for all calls and it
is actually checking every UL DIRECT TRANSFER message – so it
doesn’t stop doing it after finding IMEI.

If IMEI is provided by Core using either of the options available to it, UE

specific RRC stores the information and at minimum it is then used when
doing ticket/counter updates for the call.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 341(447)
Basic Call
 Functionality description

<internal/end>

[Link] UE specific RRC checks if IMEI query is needed due to black- or

whitelisting

When RRC Connection Setup is being done UE specific RRC checks if

capacity license for Device Detection feature is ON or OFF from common
license file.

If it is ON, UE specific RRC checks if parameter 'RNC – WDEVControl’ is

enabled. If both the license is ON and parameter enabled, then UE
specific RRC checks if any IMEIs have been put into black-/whitelist for
any feature.

If there are IMEIs in the black-/whitelist for any feature/functionality and if

UE supports any of black-/whitelisted functionalities and if IMEI is still
unknown (it didn’t arrive via RANAP message or via NAS signaling), UE
specific RRC starts the IMEI query in appropriate place of signaling
according to call type.

[Link] IMEI is not asked by UE specific RRC for calls with establishment cause
“Detach”

If UE makes call using establishment cause “Detach”, IMEI is not needed,

because the call will end without RAB being setup.

[Link] Placement of IMEI query in call signaling depends on the call type

The point where UE specific RRC does the NAS signalling in relation of
other call signalling depends on call type and activated features.

IMEI query happens after RAB Setup for following call type:

- CS calls

IMEI query happens during RAB setup delaying the RB setup signaling
towards the UE for following call types/cases:

- in MBLB (Multi Band Load Balancing) case

- PS calls setup in cell_DCH state and having DRA in use

- PS calls when RAB setup is done in cell_FACH state

- PS calls in cell_DCH state with 0/0 initial bit rate used in RAB setup (=
DRA not in use)

Maximum introduced delay to RAB setup due to IMEI query is 500 ms.
This comes from the fact that UE specific RRC doesn’t wait more than
500 ms for the UE response to the IMEI query, before continuing with the
RAB setup.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 342(447)
Basic Call
 Functionality description

If call has connection to both CS and PS Core, the Core that starts the
RAB Setup first, defines following IMEI query actions for UE specific
RRC.

<internal/begin>

UE RRC-D MCC CN

RRC Connection setup has been done

RANAP: RAB ASSIGMENT REQUEST

IMEI/TAC is not known and direct resource allocation is done

Separate IMEI request needed – do now

RRC DL Direct Transfer (GMM:IDENTITY REQUEST) The same IMEI inquiry

message can be used
RRC UL Direct Transfer (IDENTITY RESPONSE) both with CS and PS.

IMEI to MCC

Now IMEI/TAC check can be done

And value stored for future use

Normal RRM checks and resource allocation, taking into account the IMEI & white/
black list info, DSP&transmission reservation and BTS signalling (if resources
immediately reserved from BTS)

rrc_rab_setup_req_int__s

RRC Radio Bearer Setup

RRC Radio Bearer Setup Complete

rrc_rab_setup_complete_s

RANAP:RAB ASSIGMENT RESPONSE

IMEI query during RAB/RB setup

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 343(447)
Basic Call
 Functionality description

UE RRC-D MCC CN

RRC Connection setup has been done

RANAP: RAB ASSIGMENT REQUEST

CS call

rrc_rab_setup_req_int__s

RRC Radio Bearer Setup

RRC Radio Bearer Setup Complete

rrc_rab_setup_complete_s

IMEI/TAC is not known

Separate IMEI request needed

Send IMEI request RANAP:RAB ASSIGMENT RESPONSE

RRC DL Direct Transfer (GMM/MM:IDENTITY REQUEST)

RRC UL Direct Transfer (IDENTITY RESPONSE)

IMEI to MCC

Now IMEI/TAC check can be done

And value stored for future use – when
resources are allocated for the RAB

IMEI query after RAB/RB setup

<internal/end>

[Link] UE specific RRC uses NAS signaling to ask the IMEI from UE

UE specific RRC encodes and sends NAS message IDENTITY

REQUEST with IMEI request to UE to acquire the IMEI from UE. The
NAS message shall be packed inside RRC DL DIRECT TRANSFER
message and sent to UE.

Core type defines the type of the used IDENTITY REQUEST. The actual
content of the message is the same in both cases, but the message type
depends on the Core type.

- If UE has connection to CS Core then MM:IDENTITY REQUEST

message is used.

- If UE has connection to PS Core then GMM:IDENTITY REQUEST

message is used.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 344(447)
Basic Call
 Functionality description

- If UE has connection to both Core types, then used type message can
be either one and used message is selected based on which Core starts
RAB setup first.

When UE responds with IDENTITY RESPONSE (packed inside RRC UL

DIRECT TRANSFER message), UE specific RRC doesn't forward the
NAS signalling (and via that the IMEI) to CN. Instead UE specific RRC
decodes the NAS message, check that it contains IMEI and stores the
IMEI to the common file where it is kept as long as the call continues.

<internal/begin>

Note: Currently the NAS message encoding is done by MCC and the
decoding by RRC-D. MCC is the one that then stores the IMEI after
getting it from RRC-D.

<internal/end>

[Link] UE specific RRC checks black-/whitelist status based on IMEI

As soon as IMEI has been acquired, UE specific RRC checks, if this UE

model has any black-/whitelisted features, and then stores this info into
the common file.

Required Black-/Whitelist functionalities of UE are checked only once per

RRC connection, immediately when IMEI is received from CN or UE.

Note: This means if new black-/whitelisted features are added (or old
ones removed) to the specific IMEI after UE with the IMEI has started
RRC Connection, the new added features have no effect to the ongoing
RRC Connection. If RRC Connection ends and the same UE makes a
new RRC Connection after the black-/whitelist modification, then the
modifications will take effect.

[Link] UE black-/whitelist decision depends on feature if IMEI is not known

when decision of black-/whitelisted functionality is made

If IMEI for UE is not known when decision about black-/whitelisted

functionality/partial functionality/feature is done and UE is capable of the
black-/whitelisted functionality, the decision about black-/withelisting of the
feature for the UE is defined for each feature separately when the black-
/whitelisting for the feature is made..

In CPC feature (RAN1644) case the decision was to do blacklisting if IMEI

is not known.

[Link] IMEI query for Traffica

If none of the other conditions for doing IMEI query for the call have been
fulfilled and IMEI has not been gotten from Core in RANAP: COMMON
ID message or found out from NAS signalling going to Core from UE
(RRC UL DIRECT TRANSFER), parameter "RNC - IMEIQuery" can
anyway require UE specific RRC to do IMEI query for the call for Traffica
purposes.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 345(447)
Basic Call
 Functionality description

If parameter RNC - IMEIQuery is "ON" (value >0), then the parameter

defines the percentage of the calls that need to have IMEI query done by
UE specific RRC after RAB setup, if the IMEI is still unknown after first
RAB has been setup.

So, this checking is controlled only via the "RNC - IMEIQuery" parameter.
The Device Detection license has no effect on this functionality or
checking the parameter value.

<internal/begin>

IMEI, if known, is already included into ticket updates. Via this additional
query, we get more IMEI information into Traffica which then can be used
by the operator to find the problematic (or good) UE models.

<internal/end>

[Link] Relocation and IMEI

UE specific RRC in SourceRNC provides the IMEI during relocation

to Nokia TargetRNC

When relocation is started towards Nokia Target RNC (IUR-

InterfaceMode = 0 for the TargetRNC), UE specifc RRC in Source RNC
includes IMEI information into Implementation specific parameters IE in
“SRNS Relocation Info” RRC message inside Source-RNC to target RNC
transparent container IE in the RANAP:RELOCATION REQUIRED
message.

If target RNC is not Nokia RNC, then IMEI information is not provided
during relocation by Nokia Source RNC.

The IMEI is in the first 64 bits of Implementation specific parameters IE.

<internal/begin>

IMEI uses digits (0 to 9), so each number can be represented by 4 bits

and IMEI has 16 digits, so it takes 64 bits.

<internal/end>

RANAP entity in TargetRNC checks if Core includes IMEI into

RANAP: RELOCATION REQUEST message

When relocation start arrives to Target RNC and the relocation is not from
GSM or LTE system, RANAP entity checks if Core has included IMEI info
into 'UESBI-IuA' field inside optional UESBI-Iu IE. If it is included, RANAP
entity decodes the IE and gives it to UE specific RRC.

UE specific RRC in TargetRNC checks if IMEI is included at any level

in RANAP: RELOCATION REQUEST message

If IMEI is not included into 'UESBI-IuA' field inside optional UESBI-Iu IE by

Core and Source RNC is Nokia RNC, UE specific RRC checks is
Implementation specific parameters IE in “SRNS Relocation Info” RRC

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 346(447)
Basic Call
 Functionality description

message inside Source-RNC to target RNC transparent container IE

present in RANAP:RELOCATION REQUEST and does it include IMEI.

UE specific RRC asks IMEI from UE, if not gotten via RANAP:
RELOCATION REQUEST message

If IMEI was not found from any possible place in RANAP: RELOCATION
REQUEST message or the relocation came from LTE or GSM, then UE
specific RRC asks the IMEI from UE via NAS signalling after UE has
moved under the Target RNC.

The NAS signalling for getting the IMEI is done after the RRC UTRAN
MOBILITY INFO (UMI) message has been sent to the UE.

<internal/begin>

Note: Due to timer updates to UE, UMI message is sent also during UE
Involved SRNC Relocation.

Note2: The IMEI query can be done/started at the required point even if
RAU/LAU update is done after the relocation (done via NAS signalling),
because UE handles each NAS signalling procedure one by one (first in,
first served), so other NAS procedures wait in queue.

UE RRC-D in Target MCC in Target RANAP in Target CN SRNC

RANAP RELOCATION REQUIRED

RANAP: RELOCATION REQUEST

Relocation request

Normal relocation actions

Relocation request acknowledge

RANAP: RELOCATION REQUEST ACKNOLWEDGE

RANAP: RELOCATION COMMAND

RSNAP: RELOCATION COMMIT

Relocation detect

RCC: UTRAN Mobility Information

RANAP: RELOCATION DETECT
RCC: UTRAN Mobility Information

Separate IMEI request needed

RRC DL Direct Transfer (GMM/MM:IDENTITY REQUEST)

RCC: UTRAN Mobility Information Confirm

RCC: UTRAN Mobility Information Confirm

RRC UL Direct Transfer (IDENTITY RESPONSE) Relocation complete

IMEI to MCC RANAP: RELOCATION COMPLETE

RANAP: IU RELEASE COMMAND

RANAP: IU RELEASE COMPLETE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 347(447)
Basic Call
 Functionality description

IMEI query in relocation in Target RNC

<internal/end>

<internal/begin>

[Link] IMEI query problem handling

Collision with Core query

In case UE specific RRC has started IMEI query and during this Core also
starts IMEI query, UE specific RRC forwards also the IMEI query from
Core to UE and makes sure that Core gets only one response, if UE
sends response both to the query done by RNC and the query done by
Core.

Note: This is realistic scenario only if UE has more than 1 Core

connection and the other Core does thing later than the “first” Core. It can
be done like this, because UE handles NAS procedures one by one, so if
there are several NAS procedures ongoing, the later ones wait in queue
until the first one has been completed.

RAB/RB setup failure

If IMEI query was supposed to be done after RB setup signalling with UE

and the RB setup fails due UE rejection and IMEI is still unknown, IMEI
query is started after the failure has been handled and if RRC Connection
still exists after the failure handling has been completed and IMEI is still
unknown. (valid for CS and traffic triggered queries)

Cell Update during IMEI query

If UE sends RRC CELL UPDATE during RB setup signalling and existing

conditions for continuing the RRC Connection are met and IMEI is still
unknown after RB setup has been completed, IMEI query is started.

Call drop and re-establishment during IMEI query

If RRC Connection drops in RNC when IMEI query started by UE specific

RRC is ongoing and RRC Connection is successfully recovered and IMEI
is still unknown, UE specific RRC re-attempts the IMEI query.

[Link] Features with black-/whitelisting

RAN number: tells the feature number of the original feature

WDCMA release : tells the release where the feature got black-
/whitelisting functionality.

Introductin via RANxxx: tells the feature number that introduced the
black-/whitelisting for the feature. Can be the same as the “RAN number”

RAN Feature/functionlity name WDCMA release Introduction via

number RANxxxx

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 348(447)
Basic Call
 Functionality description

RAN1644 Continuous Packet Connectivity WDCMA16 RAN3082

RAN2289 Blind IFHO in RAB Setup Phase/ WCDMA17 RAN3093
RAN2172 MBLB in RAB setup
RAN2172 Multi Band Load Balancing/ WCDMA17 RAN3093
RAN2172 MBLB in state
transition to Cell_DCH
RAN3093 Enhanced MBLB/RAN3093 MBLB WCDMA17 RAN3093
in voice call setup from CCH
RAN3093 Enhanced MBLB/ RAN3093 WCDMA17 RAN3093
MBLB in state transition to CCH

<internal/end>

<RAN3082/end>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 349(447)
Basic Call
 Functionality description

<RAN3093/begin>

2.3.46 RAN3093 Enhanced MBLB

The RAN3093 Enhanced MBLB feature contains enhancements to the

features RAN2172 Multi-Band Load Balancing and RAN2289 Blind IFHO
in RAB Setup Phase. The RAN3093 feature enhances load balancing,
layering during voice call setup, inactivity triggered layering and mobility
triggered layering functionalities of the RAN2172 feature, and introduces
new counters for monitoring SLHO Load State and HSPA Load State in
correlation with MBLB decisions.
The RAN3093 feature uses the same license as the RAN2172 feature.
That is, if an operator has purchased the RAN2712 feature and the
release where the RAN3093 feature is released, the operator gets the
functionality of the RAN3093 Enhanced MBLB feature.
The enhancements are listed below:

Enhanced load balancing

Enhanced load balancing makes it possible to use the MBLB feature just
for balancing HSPA load between the layers (without any preferred layer
definitions). It is also possible to prevent useless load balancing actions
when the HSPA load level is low. <Internal/begin> See details in
/47/.<Internal/end>

Enhanced layering during voice call setup - Blind IFHO in RRC setup

Currently it is possible to perform MBLB layer change for voice calls in

RAB setup phase. RAN3093 Enhanced MBLB feature makes it possible
to change to preferred layer for CS voice call already in the RRC
connection setup phase. <Internal/begin> See chapter [Link] for details.
<Internal/end>

Enhanced layering during voice call setup - Blind IFHO for CS voice
call from CCH states

RAN3093 Enhanced MBLB feature makes it possible to change to

preferred layer (Bind IFHO) for CS voice call when starting CS voice call
from CCH state.
Blind IFHO for CS voice call from CCH states functionality requires that
feature RAN2970 "Improvement to CS Call Setup Attempts Starting from
Cell_FACH / Cell_PCH" is activated. <Internal/begin> See details in /47/
and /18/.<Internal/end>

Enhanced layering during voice call setup - "HSPA load state"

bypass

<Internal/begin>See details in /47/.<Internal/end>

Enhanced inactivity triggered layering without compressed mode

measurements

<Internal/begin>See details in /47/ and /18/.<Internal/end>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 350(447)
Basic Call
 Functionality description

Enhanced inactivity triggered layering in state transition to CCH

state

<Internal/begin> See details in /47/ and /18/. <Internal/end>

Enhanced mobility triggered layering

<Internal/begin>
See details in /47/.
<Internal/end>

[Link] RAN3093 is controlled by license key and cell level activation parameters

The RAN2172 Multi-Band Load Balancing feature is enabled in the cell

when the state of the legacy license key 'Multi-Band Load Balancing LK' is
'On' and one or more of the following legacy parameters are set to value
'Enabled':

• WCEL - MBLBRABSetupEnabled
• WCEL - MBLBStateTransEnabled
• WCEL - MBLBInactivityEnabled
• WCEL – MBLBMobilityEnabled

When the RAN2172 Multi-Band Load Balancing feature is enabled in the

cell, the RAN3093 MBLB enhancements shall be controlled by the WCEL
parameter MBLBEnhancementsEnabled, <Internal/begin> see [Link].
<Internal/end>

<Internal/begin>

[Link] Blind IFHO in RRC setup indicating CS AMR speech call establishment

Need for the Blind IFHO is evaluated for the RRC connection request
indicating CS AMR speech call establishment. From signaling point of
view, the procedure is similar to legacy functionality "Frequency layer
change during RRC connection establishment" (see chapter [Link].2),
except that the BTS can also change. Only intra RNC layer/BTS changes
are supported. Blind IFHO in RRC setup moves UE to a frequency layer
within the same frequency band.

Blind IFHO in RRC setup is enabled if:

• The RAN2172 Multi-Band Load Balancing license key 'Multi-Band
Load Balancing LK' is 'On'
• Bit1 (2nd bit) of the parameter WCEL-
MBLBEnhancementsEnabled has value 1 AND
• WCEL - MBLBRABSetupEnabled is set to 'Enabled'

If Blind IFHO in RRC setup is enabled and the UE requests state

transition from RRC Idle mode to RRC Connected mode by sending RRC:
RRC CONNECTION REQUEST with the Establishment cause
“Originating Conversational Call” or “Terminating Conversational Call” ,
the UE specific RRC initiates Blind IFHO procedure. Blind IFHO in RRC
setup is not applied to the Emergency call.

<PR255362/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 351(447)
Basic Call
 Functionality description

If UE includes the CSFB Indication IE in RRC: RRC CONNECTION

REQUEST and the received establishment cause is other than
“Terminating Conversational Call” or “Emergency Call”, the UE specific
RRC initiates Blind IFHO procedure as if the received establishment
cause was “Originating Conversational Call”.

< PR255362/end>

The UE specific RRC indicates to UE specific RRM that Blind IFHO shall
be evaluated. If the HC decides to change the layer or BTS, the resources
are allocated from the other layer than the current one and UE specific
RRC orders the UE to the new frequency layer by sending the RRC:RRC
CONNECTION SETUP message including UARFCN downlink (Nd) IE in
Frequency info IE.

NOTE: If feature RAN1797 Common Channel Setup has been activated

for the Establishment cause “Originating Conversational Call” and/or
“Terminating Conversational Call” (and CPICH Ec/N0 and RACH/FACH
load allow SRBs on CCH), Blind IFHO in RRC setup is not triggered for
the corresponding Establishment cause.

Queue time and priority values of UP/Transport resource allocation

request are the same as used in the “Normal voice call establishment”
(under "RRC connection establishment procedures") case, see Table 2 in
chapter Error! Reference source not found..

NOTE: Blind IFHO in RRC setup overrides the legacy DRRC features.
This is valid for both the RAN2.0079 Directed RRC Connection Setup
feature and RAN964 Directed RRC Connection Setup for HSDPA Layer
feature.

<RAN3475/begin>

[Link].1 Interaction with RAN3475 Buffer-free WCDMA-LTE Refarming feature

Blind IFHO in RRC setup to the cell which has the RAN3475 Buffer-free
WCDMA-LTE Refarming feature enabled can be restricted depending on
the value of the RNMOBI parameter BFRFunctionalityControl:

• When Bit0 and Bit1 of the parameter BFRFunctionalityControl are

set to value 0, the RAN3475 Buffer-free WCDMA-LTE Refarming
feature does not restrict Blind IFHO in RRC setup.

• When Bit0 of the BFRFunctionalityControl is set to value 1 (default

value), the handover control shall prevent the Blind IFHO in RRC
setup.

• If Bit1 of the parameter BFRFunctionalityControl is set to value 1

when Bit0 is set to value 0, whether Blind IFHO in RRC setup is is
allowed or not depends on the value CPICH RSCP measurement
result of the source cell. See Handover Control FD for details.

<RAN3475/end>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 352(447)
Basic Call
 Functionality description

[Link].2 UE capability information received in the RR:RRC CONNECTION

REQUEST is used for definition of the preferred layer

UE-specific RRC provides the following UE capability information received

in the RRC:RRC CONNECTION REQUEST to Handover Control:

UE capability indication OP Enumerate Absence of this REL-6

d (HS- IE implies that
DSCH, HS- neither HS-
DSCH+E- DSCH nor E-
DCH) DCH are
supported by the
UE

Multi cell support OP Enumerate The absence of REL-8

d (TRUE) this IE indicates
that the UE
does not
support dual cell
operations on
adjacent
frequencies

Handover Control uses the UE capability information received in the RRC

CONNECTION REQUEST for selecting the PFL-PrefLayer... parameters
in case of Blind IFHO starting from the RRC Idle state.

[Link].3 Unsuccessful Blind IFHO in RRC connection request phase

The failure handling is performed in legacy manner as has been specified

for "Frequency layer change during RRC connection establishment" (see
chapter [Link].2 ), except that the BTS change may be attempted.

If instead of sending the RRC:RRC CONNECTION SETUP COMPLETE

as an answer to layer change attempt, the UE sends the new RRC:RRC
CONNECTION REQUEST message via the same cell, the UE specific
RRC detects it as unsuccessful Blind IFHO attempt. The UE specific RRC
forwards the frequency change attempt failure information to UE specific
RRM when requesting the resources thus avoiding allocating the
resources from another frequency layer than the current one.

In case of RNC failure or BTS failure in the target cell, the legacy RRC
connection setup failure handling is followed. If Blind IFHO in RRC
connection setup does not succeed in the target cell, RRC connection
setup continues in the source cell.

<Internal/end>

<RAN3093/end>
<RAN3253/begin>

2.3.47 RAN3253 IMSI Based Frequency Based HO

This feature introduces possibility to allow use of just one WCDMA

frequency band to all users of certain operator. Users of that operator are

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 353(447)
Basic Call
 Functionality description

then prevented from using cells in the other frequency bands reserved to
some other operator usage. Prevention is based on the PLMN of the user
(part of the IMSI of the user) and operator specific configuration in RNC to
define operator specific allowed WCDMA frequency band.

This feature can be used in cases where just one network PLMN is used
in all cells. The legacy features (e.g. IMSI based HO) cannot prevent use
of certain layer in this case, because they would require configuration
where allowed and prevented layer would have different network ids.

The allowed WCDMA frequency band is configured with the legacy WSG
and WANE parameters for each operator separately. If this 'allowed band'
definition exists for an operator, then all other bands are forbidden for
users of that operator.

Prevention of frequency band means the following things:

• User is moved away from the forbidden layer when the UE needs
to be moved to Cell_DCH state
• inter-frequency handover is prevented to the forbidden layer
• layering to forbidden layers is prevented (selected features, see
/47/).

UE can camp to the forbidden layer (Idle --> Connected) and stay there in
Cell/URA_PCH/Cell_FACH state, but no RABs with dedicated radio
resources can exist there.

Notice that RAN3253 special handling is not used for those users that
have been identified to have an emergency call.

<Internal/begin>

[Link] RAN3253 is controlled by license key and PRFILE parameters

RAN3253 IMSI Based Frequency based HO is an optional feature (ASW)

and it is be controlled by a RNC license key.

RAN3253 IMSI Based Frequency based HO feature is controlled by a

long term on/off license 'IMSI Based Frequency Based HO' (feature code:
4445).

The feature is enabled when all the following conditions are fulfilled:

• the license 'IMSI Based Frequency Based HO' is installed in the

RNC and the state of the feature is 'On'

• the license 'RU00028 IMSI based handover RLIC' is installed in

the RNC and the state of the feature is 'On' (FIFILE 002:895
IMSI_BASED_HANDOVER_SUP)

• value of the PRFILE parameters 002:2270 RU50_SPARE_08 and

002:2271 RU50_SPARE_09 are set to some other value than 0.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 354(447)
Basic Call
 Functionality description

The feature is out of use, if at least one of the conditions above are not
fulfilled.

RRM and L3 entities check that the feature is in use, before they execute
RAN3253 specific functionalities.

[Link] The allowed 3G frequencies are configured with the legacy WSG and
WANE parameters

The legacy WSG object contains the PLMN Id of the operator (WSG-
HomePLMN) and the identification of WANE object (WSG-
WSGAuthorisedNetworkId) where the authenticated networks are
configured for the operator in question. This legacy WANE object and its
legacy parameters are used now also to configure WCDMA frequency
band that is allowed to be used by the users of the operator. See the
details in Handover Control FD /47/.

GSM frequency range used in cases where older than rel6 UE is

redirected to GSM are set with the PRFILE parameters 002:2270
RU50_SPARE_08 and 002:2271 RU50_SPARE_09. Those parameters
also activate the whole RAN3253 feature. See the parameter definitions
in Handover Control FD /47/.

[Link] The UE specific RRC checks whether the UE is in allowed frequency

layer (cell)

The allowed WCDMA frequency band for an operator are read from the
WSG and WANE parameters. The UE specific RRC checks whether the
UE is in allowed WCDMA layer (cell), i.e. does the channel number
(WCEL-UARFCN) of the cell match with the allowed WCDMA band
definition.

All bands are allowed in emergency call cases. Emergency call detection
methods are listed in Admission Control FD chapter “Emergency call
detection methods”.

See also Handover Control FD /47/.

[Link] RNC moves the UE away from the forbidden frequency when the first
RAB for the UE in question is being setup

When a UE specific RRC receives the first RANAP:RAB ASSIGNMENT

REQUEST message of the RRC connection from CN and the UE is or is
moved to Cell_DCH state during RAB assignment procedure, the UE
specific RRC checks whether the UE is in allowed layer.

If the UE is not in the allowed layer, then the handover control is asked to
select the target cell for blind HO.

If the layer change is triggered, the consequent Blind IFHO procedures in

different cases are described in the following chapters.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 355(447)
Basic Call
 Functionality description

[Link].1 UE specific RRC executes blind IFHO after first RANAP:RAB

ASSIGNMENT REQUEST in Cell_DCH state

If the first RANAP:RAB ASSIGNMENT REQUEST has been received

while UE has been camping in the forbidden frequency layer and HC has
given target cell for Blind IFHO, the UE specific RRC proceeds with the
two procedure Blind IFHO as specified in RAN2289 Blind IFHO in RAB
Setup Phase.

NOTE: The one procedure Blind IFHO specified in RAN2289 shall not be
used when Blind IFHO is triggered by RAN3253 (no PRFILE checking).

Two procedure functionality:

1. First IFHO using Physical Channel Reconfiguration, Transport

Channel Reconfiguration or Radio Bearer Reconfiguration
procedure

2. Then RB setup

The UE specific RRC orders UE to the target frequency by including

UARFCN downlink (Nd) IE (UARFCN uplink (Nu) IE is optional) in the
Frequency info IE in the RRC:PHYSICAL CHANNEL/TRAFFFIC
CHANNEL/RADIO BEARER RECONFIGURATION message.

If the IFHO procedure fails, the UE specific RRC proceeds to redirect the
UE to GSM as defined in chapter [Link]. If the IFHO procedure
succeeds but the subsequent RB Setup procedure fails, legacy failure
handling is performed.

[Link].2 UE specific RRC executes blind IFHO after first PS NRT RANAP:RAB
ASSIGNMENT REQUEST in Cell_FACH state when UE is moved to Cell_DCH
state

If the RANAP:RAB ASSIGNMENT REQUEST has been received for PS

NRT RAB in Cell_FACH state, RAN3253 has been activated and the UE
is not in allowed layer, the UE specific RRC indicates to the UE Specific
RRM that the target for Blind IFHO is needed.

If the conditions for Direct Resource Allocation are fulfilled (UE is moved
to Cell_DCH) and the handover control gives target for Blind IFHO, the
UE specific RRC orders the UE to the selected cell by including UARFCN
downlink (Nd) IE (UARFCN uplink (Nu) IE is optional) in the Frequency
info IE in the RRC:RADIO BEARER SETUP message.

If RB Setup procedure fails or UE specific RRM indicates that no suitable

target cell has been found, the UE specific RRC proceeds to redirect the
UE to GSM as defined in chapter [Link].

PS NRT RAB without DRA:

If the RANAP:RAB ASSIGNMENT REQUEST has been received for

PS NRT RAB but Direct Resource Allocation is not triggered (UE
stays is Cell_FACH state), the UE specific RRC proceeds normally
with Radio Bearer Setup procedure towards the UE in Cell_FACH
state. In successful RAB Assignment procedure case UE is if needed

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 356(447)
Basic Call
 Functionality description

moved to the allowed frequency during state transition to Cell_DCH

state.

If Radio Bearer Setup procedure fails, legacy failure handling is

applied.

[Link].3 UE specific RRC executes blind IFHO after first CS RT RANAP:RAB

ASSIGNMENT REQUEST in Cell_FACH state

If the RANAP:RAB ASSIGNMENT REQUEST has been received for CS

RT RAB in Cell_FACH state, RAN3253 has been activated and the UE is
not in allowed layer, the UE specific RRC indicates that the target for
Blind IFHO is needed to the UE Specific RRM. If the handover control
gives target for Blind IFHO, the UE specific RRC orders UE to the
selected cell by including UARFCN downlink (Nd) IE (UARFCN uplink
(Nu) IE is optional) in the Frequency info IE in the RRC:RADIO BEARER
SETUP message.

[Link].4 UE specific RRC executes redirection to GSM if Blind IFHO in RAB

Setup Phase is not possible or it does not succeed

The failure handling is the same for the Blind IFHO with the
RRC:PHYSICAL CHANNEL/TRANPORT CHANNEL/RADIO BEARER
RECONFIGURATION procedure and RRC:RADIO BEARER SETUP
procedure.

If Blind IFHO procedure fails for any of the following reasons:

• RRC:PHYSICAL CHANNEL/TRANSPORT CHANNEL/RADIO

BEARER RECONFIGURATION FAILURE is received

• RRC:RADIO BEARER SETUP FAILURE is received

• RRC:CELL UPDATE is received (from forbidden frequency);

RRC:CELL UPDATE from allowed frequency is handled in legacy
way.

• RRM has indicated that no suitable target cell has been found

the UE specific RRC attempts to redirect the UE to the GSM. The UE

specific RRC executes the following:

• If UE release is Rel5 or earlier, the UE supports GSM and the UE

is in Cell_FACH state, the UE specific RRC shall proceed as
specified in [Link].5. Otherwise

• Sends RANAP: RAB ASSIGNMENT RESPONSE containing the

Radio Network Layer Cause 'Failure in the Radio Interface
Procedure(14)' to the CN

• Redirection to GSM as described in chapter [Link]

NOTE: RRC Procedure time out cases are handled in legacy way.

Below is an example of failed Blind IFHO during RAB assignment.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 357(447)
Basic Call
 Functionality description

UE BTS RNC CN

Signalling link established, UE in Cell_DCH state

RANAP: RAB ASSIGNMENT REQUEST

AMR RAB request

CS RT RAB is requested. Whether

UE is in allowed layer is checked.
UE is moved to the allowed layer

NBAP Radio Link Setup procedure

User plane setup

User Plane Setup

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION

(Frequency info)

RRC: CELL UPDATE

Cell Update from the forbidden frequency

-> Decision to redirect the UE to GSM

RANAP: RAB ASSIGNMENT RESPONSE

(Cause: Failure in the Radio Interface Procedure)

RANAP: IU RELASE REQUEST

RANAP:IU RELASE COMMAND

RRC:RRC CONNECTION RELEASE

(RPLMN Information/Redirection Info)
RANAP: IU RELASE COMPLETE

RRC:RRC RELASE COMPLETE

Figure 2.3.47-1 Failed Blind IFHO during AMR RAB setup

[Link].5 UE specific RRC moves the Rel 5 UE to Cell_DCH state before

redirection to GSM in RAB Setup Phase

If the Blind IFHO is RAB setup phase fails or is not possible and
redirection to GSM is triggered for Rel5 UE in Cell_FACH state, the UE
specific RRC first tries to move UE to Cell_DCH state in forbidden layer
with DCH 0/0 allocation. The UE specific RRC executes the following:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 358(447)
Basic Call
 Functionality description

• CS only RAB Assignment in Cell_FACH state (common channel

setup):
o RAB Assignment Response and Iu Release but then normal
RRC connection release without GSM redirection.
Note: No GSM redirection in this case.

• CS+PS RAB; CS RAB Assignment in Cell_FACH state:

o RANAP: RAB ASSIGNMENT RESPONSE is sent
o UE is moved to Cell_DCH state in forbidden layer in legacy
manner (with DCH 0/0 allocation)
o When state change to Cell_DCH has been completed, UE is
redirected to GSM with RRC:RRC CONNECTION RELEASE
as specified in [Link]

• PS only RAB Assignment with DRA in Cell_FACH state:

o RANAP: RAB ASSIGNMENT RESPONSE is sent
o UE is moved to Cell_DCH state in forbidden layer in legacy
manner (with DCH 0/0 allocation)
o When state change to Cell_DCH has been completed, UE is
redirected to GSM with RRC:RRC CONNECTION RELEASE
as specified in [Link]
o If RANAP:IU RELEASE COMMAND is received during state
change procedure, the RRC connection is released in legacy
manner without GSM redirection.

If the state transition to Cell_DCH fails, the RRC connection is

released normally without GSM redirection.

[Link] The UE specific RRC redirects the UEs to GSM if the layer change to
allowed layer fails or is not possible

In the following cases, the UE specific RRC attempts to redirect the UE to

the GSM:

• if layering during first RAB setup is not possible or it does not

succeed, see [Link].4

• if layering during state transition from Cell_FACH to Cell_DCH is

not possible or it does not succeed, see RAN3253 in /18/.

• if layering during direct state transition from Cell/URA_PCH to

Cell_DCH is not possible or it does not succeed, see RAN3253 in
/18/

• if UE has reselected a cell from a forbidden layer due to UE losing

radio connection, see RAN3253 in /18/

The UE specific RRC executes the following:

• If GSM redirection is not triggered by RAB Assignment, UE

release is Rel5 or earlier, the UE supports GSM and and the UE is
in Cell_FACH state, the UE specific RRC shall proceed as
specified in [Link].2. Otherwise

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 359(447)
Basic Call
 Functionality description

• The UE specific RRC starts Iu connection release by sending

RANAP: IU RELASE REQUEST containing the Radio Network
Layer Cause 'Failure in the Radio Interface Procedure(14)' to the
CN and waits for RANAP:IU RELEASE COMMAND.

• If the UE supports GSM , the UE specific RRC selects the

contents of the message (chapter [Link].1 ) and redirects the
UE to GSM by sending RRC:RRC CONNECTION RELEASE
containing Release cause value 'directed signaling connection re-
establishment'. If UE does not support GSM, normal RRC
connection release without GSM redirection is performed.

• NOTE: In special case when DCCH is no availablet, RANAP:IU

RELEASE REQUEST and RRC:RRC CONNECTION RELEASE
are sent simultaneously. Normally RRC:RRC CONNECTION
RELEASE is sent only after the RANAP:IU RELEASE COMMAND
has been received (legacy message sequence is used).

[Link].1 The UE specific RRC selects the contents of the RRC:RRC

CONNECTION RELEASE for GSM redirection

Depending on the UE release (Access Stratum Release Indicator IE in the

RRC:CONNECTION REQUEST), the UE specific RRC decides which IE
in RRC:RRC CONNECTION RELEASE is used to convey redirection
information.

Pre Rel6 UE

RPLMN Information IE
Information Element/Group Need Multi Type and Semantics Version
name reference description
GSM BA Range OP 1 to GSM BA Range
maxNumG
SMFreqRa
nges
>GSM Lower Range (UARFCN) MP Integer(0..16 Lower bound for
383) range of GSM BA
freqs
>GSM Upper Range (UARFCN) MP Integer(0..16 Upper bound for
383) range of GSM BA
freqs

The GSM Lower Range value is read from the PRFILE parameter
002:2270 RU50_SPARE_08.

The GSM Upper Range value is read from the PRFILE parameter
002:2271 RU50_SPARE_09.

Rel6 and later UE

Redirection Info->Inter-RAT Info IE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 360(447)
Basic Call
 Functionality description

Information Element/Group Need Multi Type and Semantics Version

name reference description
Inter-RAT info MP Enumerated
(GSM
, E-UTRA) REL-8
GSM target cell info CV-GSM GSM target REL-6
cell info
10.3.8.4g
E-UTRA target info CV-E- E-UTRA REL-8
UTRA target info
10.3.8.4L

The IE Inter-RAT info is set to the value ‘GSM’ (no GSM target cell info is
given).

[Link].2 The UE specific RRC moves the Rel5 UE to Cell_DCH state before
redirection to GSM

If layering to allowed layer is not possible or it does not succeed for Rel5
UE, the UE is in Cell_FACH state, UE supports GSM and the redirection
to GSM is triggered (for other reason then RAB Assignment), the UE
specific RRC executes the following:
• UE is moved to Cell_DCH state in the forbidden layer in legacy
manner (with DCH 0/0 allocation)
• When state change to Cell_DCH has been completed, UE is
redirected to GSM with RRC:RRC CONNECTION RELEASE as
specified in [Link]
• When RRC:RRC CONNECTION RELEASE COMPLETE has been
received, the Iu connection release shall be started as specified in
[Link]

If the state transition to Cell_DCH fails, the RRC connection is released

normally without GSM redirection.

<Internal/end>
<RAN3253/end>

<RAN2973/begin>

2.3.48 RAN2973 Enhanced IMSI Based Call Monitoring

This feature enhances feature RAN2930 IMSI-based Call Monitoring (see

chapter Error! Reference source not found. ) with the following
functionality:

• User Plane signaling and protocol headers for mcRNC

• Transport Plane protocol headers at IP-based interface units for
mcRNC
• User Plane monitoring for Cell_FACH state for mcRNC and IPA-
RNC
• PDCP, RLC and MAC-d monitoring for FACH, HS-FACH and HS-
RACH

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 361(447)
Basic Call
 Functionality description

• Drift RNC monitoring support for IPA-RNC and mcRNC

• Enhanced usability, decoding and graphical analysis of L3 Data
Analyzer (Emil)

This feature is under the same license control as RAN2930 i.e. it is

controlled by RNC license key "Call based monitoring'. Type of the
license key is on/off license.

From Control Plane monitoring point of view the most significant

enhancement is the monitoring support in DRNC. That functionality is
described in /20/ and /40/.

<Internal/begin>
[Link] Increased frequency of MAC throughput reporting for monitored calls

When the monitoring status of the call changes from unknown to

interesting, UE specific RRC indicates to TRM entity a shorter MAC
throughput reporting period (1 second unless configured value is smaller).

When the monitoring status of the call changes from interesting to

uninteresting, the UE specific RRC indicates to the TRM entity to reset
the MAC throughput reporting period to configured value.

<Internal/end>
<RAN2973/end>

<RAN3079/begin>
2.3.49 RAN3079 Dedicated Priorities

The RAN3079: Dedicated Priorities feature enables inter-frequency and

inter-RAT (GSM, LTE) cell reselection based on the dedicated
(subscriber-specific) WCDMA/LTE/GSM frequency priorities. When the
RAN3079 feature is activated, the RNC sends the dedicated
WCDMA/LTE/GSM frequency priorities to the specified Rel-8 UEs in the
RRC: UTRAN MOBILITY INFORMATION message is sent after RAB
setup and during the SRNC relocation procedure.

The UEs in question use the dedicated priorities for cell reselection in the
states: Idle, Cell_PCH, and URA_PCH instead of the absolute priorities
broadcasted in the System Information Block type 19 (SIB19) message.

The dedicated priorities are valid until the UE leaves the radio network or
the dedicated priorities are resent. The cell reselection strategy
(subscriber-specific, or user groupspecific) is controlled by the PLMN Id of
the subscriber and/or the Subscriber Profile ID (SPID) for RAT/Frequency
priority IE sent from the CN to the RNC in the RANAP: COMMON ID,
DIRECT TRANSFER or the RELOCATION REQUEST message.

The operator is able to define the WCDMA/LTE/GSM frequency priorities

dedicated to a certain subscriber's PLMN Id, to a certain SPID value or to
a certain PLMN Id and SPID combination. It is also possible to define the
WCDMA/LTE/GSM frequency priorities that are dedicated to all roaming
subscribers.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 362(447)
Basic Call
 Functionality description

Note: If some RAT-related information in SIB19 does not exist (because of

a missing priority for that RAT/frequency), the UE cannot make cell
reselection in the states: IDLE, Cell_PCH, and URA_PCH to that Radio
Access Technologies (RAT).

In case of RAN sharing, each operator can define the dedicated priorities
independently.

New parameter objects WSP (WCDMA Subscriber Profile ID) and WDP
(WCDMA Dedicated Priority) are available for operator specific camping
strategy handling. They have dependency to IUO object, because WSP
contains the associated IUO identifier to one of IUO parameter object
instances.

See following parameter settings options (Note: Home Subcribers are

handled in left side):

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 363(447)
Basic Call
 Functionality description

[Link] Information sending to UE after Common ID or Direct Transfer messages

received

In normal case RNC is expecting to receive SPID information in RANAP:

COMMON ID message.

In case RANAP: COMMON ID does not have SPID information it could

come in next RANAP: DIRECT TRANSFER messages. RNC waits SPID
information coming from CN until RANAP: RAB ASSIGNMENT
RESPONSE message is sent to CN for successfully established RAB.

If SPID information is received and RAB Assignment (SETUP) procedure

is completed, RNC sends RRC: UTRAN MOBILITY INFORMATION (UMI)
message with dedicated priority information to UE. Note: There is no
repetition of UMI message and no need to wait the RRC: UTRAN
MOBILITY INFORMATION CONFIRM (UMIC) message for dedicated
priorities.

If RNC does not receive SPID information before RANAP: RAB

ASSIGNMENT RESPONSE message is sent, then RNC checks if
SubscriberProfilePLMNId has a special value set on WSP parameter for
IMSI of UE, and if that requires sending of UMI message to UE still (see
parameters setting fiqure (above).

If no UMI message is sent with dedicated priority information to UE and

RANAP: COMMON ID or RANAP: DIRECT TRANSFER message is

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 364(447)
Basic Call
 Functionality description

received later (after RAB Assignment (Setup) procedure) with SPID

information, RNC sends UMI to UE with corresponding (Dedicated
Priority) information immediately. If UE is in Cell_PCH or URA_PCH state,
then UMI is sent immediately after UE is moved to Cell_FACH or
Cell_DCH state.

If UE does not have RAB, (and RNC has the reason to send dedicated
priorities (SRB only) and CN does not send RANAP: IU RELEASE
COMMAND message before Cell_PCH/URA_PCH/Cell_FACH state
transition happens) RNC sends dedicated priority information via UMI
message once before Cell_DCH to Cell_PCH/Cell_FACH/URA_PCH
state transition or Cell_FACH to Cell_PCH/URA_PCH state transition.

If UE does not have RAB and RANAP: IU RELEASE COMMAND

message comes from core network, RNC sends dedicated priority
information via UMI message once before RRC: RRC CONNECTION
RELEASE message is sent to UE (IDLE mode state transition).

Note: RRC messages are sent to UE sequentially without waiting UMIC.

In case of Cell Update message (UE lost, cell reselection…) coming from
UE, RNC (L3) sends dedicated priority information via UMI message once
after cell update comfirm message if dedicated priorities are not already
sent to UE or operator has made changes/modifications to WSP or WDP
parameters. Note: Layer 2 is having existing method of repeating
acknowledgement RLC messages when needed.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 365(447)
Basic Call
 Functionality description

UE RNC CN

RRC Connection setup has been signalled

RRC: INITIAL DIRECT TRANSFER

RANAP: INITIAL UE MESSAGE
RANAP: COMMON ID (
+ Subscriber Profile ID for RAT/Frequency priority IE)

If the Subscriber Profile ID for RAT/Frequency priority IE is

contained in the COMMON ID message OR DIRECT RANAP: DIRECT TRANSFER (
TRANSFER, the RNC shall store the received Subscriber GPRS MM:AUTHENTICATION AND CIPHERING REQUEST
Profile ID for RAT/ Frequency priority + Subscriber Profile ID for RAT/Frequency priority IE)

RRC: DL DIRECT TRANSFER (GPRS MM:AUTHENTICATION AND CIPHERING REQUEST)

RRC: UPLINK DIRECT TRANSFER (GPRS MM:AUTHENTICATION AND CIPHERING RESPONSE)

RANAP: DIRECT TRANSFER

(GPRS MM:AUTHENTICATION AND CIPHERING RESPONSE)

RANAP: SECURITY MODE COMMAND

RRC: SECURITY MODE COMMAND

RRC: SECURITY MODE COMPLETE

RANAP: SECURITY MODE COMPLETE

UE-Core signalling if needed – additional ciphering + attach + PDP contex etc

RANAP: RAB ASSIGMENT REQUEST

RRC: RADIO BEARERSETUP

RRC: RADIO BEARER SETUP COMPLETE

RANAP:RAB ASSIGMENT RESPONSE

If SPID information is received afterwards or PLMN based
dedicated priority sending selected, RNC sends UMI with
dedicated priorities information to UE in this phase

RRC: UTRAN Mobility Information ( + Dedicated priority information IE)

RRC: UTRAN Mobility Information Confirm

Figure. SPID coming from CN

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 366(447)
Basic Call
 Functionality description

UE RNC CN

RRC Connection Established

Location Update / routing Area Update

RRC: INITIAL DIRECT TRANSFER

RANAP: INITIAL UE MESSAGE

Signalling Connection Established

Identification

RANAP: COMMON ID (
+ Subscriber Profile ID for RAT/Frequency priority IE)
If the Subscriber Profile ID for RAT/Frequency priority IE is
contained in the COMMON ID message OR DIRECT TRANSFER, RANAP: DIRECT TRANSFER (
the RNC shall store the received Subscriber Profile ID for RAT/ Identity request
Frequency priority + Subscriber Profile ID for RAT/Frequency priority IE)
RRC: DL DIRECT TRANSFER (GPRS MM:AUTHENTICATION AND CIPHERING REQUEST)

RRC: UPLINK DIRECT TRANSFER

RANAP: DIRECT TRANSFER (Identity response)

RANAP: DIRECT TRANSFER (
Location update accepted
+ Subscriber Profile ID for RAT/Frequency priority IE)
RRC: DL DIRECT TRANSFER

RRC: UPLINK DIRECT TRANSFER

RANAP: DIRECT TRANSFER (TMSI reloc completed)

If SPID information is received afterwards or PLMN based
dedicated priority sending selected, RNC sends UMI with
dedicated priorities information to UE in this phase RANAP: IU RELEASE COMMAND

RRC: UTRAN Mobility Information ( + Dedicated priority information IE)

RRC: RRC CNNECTION RELEASE

RRC: UTRAN Mobility Information Confirm

RRC: RRC CONNECTION RELEASE COMPLETE

RANAP: IU RELEASE COMPLETE

Figure. Location / Routing area update

[Link] Information sending to UE after Relocation Request message

The RNC checks if dedicated priority information is sent to the UE (see

parameters setting fiqure (above)) after receipt of the RANAP:
RELOCATION REQUEST message.

If the check indicates that dedicated priority information must be sent to

the UE during the SRNC relocation procedure:

• In case UE not involved relocation in Cell_DCH state, the RNC

sends dedicated priority information with existing RRC: UTRAN
MOBILITY INFORMATION (UMI) sending after RNSAP:
RELOCATION COMMIT during SRNC relocation procedure. Note:
In case of UE not involved relocation in Cell_DCH state, UMI
message is sent RLC unacknowledgement mode.

• In case UE involved relocation in Cell_DCH state or UE not

Involved relocation in Cell_FACH state, the RNC sends dedicated
priority information with separate RRC: UTRAN MOBILITY

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 367(447)
Basic Call
 Functionality description

INFORMATION (UMI) message after RANAP: RELOCATION

COMPLETE message is sent to CN.

UE Target RNC CN SRNC

UE Not Involved Relocation / Cell_DCH state

RANAP RELOCATION REQUIRED

RANAP: RELOCATION REQUEST
(+ Subscriber Profile ID for RAT/Frequency priority IE)

If the Subscriber Profile ID for RAT/Frequency priority IE is

contained in the Source RNC to Target RNC Transparent Container
IE, the target RNC shall store the received Subscriber Profile ID for
RAT/Frequency priority.

RANAP: RELOCATION REQUEST ACKNOWLEDGE

RANAP: RELOCATION COMMAND

If SPID information is received in relocation
request, RNC sends UMI with dedicated RNSAP: RELOCATION COMMIT
priorities information to UE

RRC: UTRAN Mobility Information ( + Dedicated priority information IE)

RANAP: RELOCATION DETECT

RRC: UTRAN Mobility Information Confirm

RANAP: RELOCATION COMPLETE

RANAP: IU RELEASE COMMAND

RANAP: IU RELEASE COMPLETE

Figure. UE not involved relocation

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 368(447)
Basic Call
 Functionality description

UE Target RNC CN SRNC

UE Involved Relocation

RRC: MEASUREMENT REPORT

RANAP RELOCATION REQUIRED

RANAP: RELOCATION REQUEST
(+ Subscriber Profile ID for RAT/Frequency priority IE)

If the Subscriber Profile ID for RAT/Frequency priority IE is

contained in the Source RNC to Target RNC Transparent Container
IE, the target RNC shall store the received Subscriber Profile ID for
RAT/Frequency priority.

RANAP: RELOCATION REQUEST ACKNOWLEDGE

RANAP: RELOCATION COMMAND

PhyCH/TrCH/RB Reconfiguration procedure

RSNAP: RELOCATION COMMIT

RANAP: RELOCATION DETECT

RRC: …..COMPLETE

If SPID information is received in relocation

request, RNC sends UMI with dedicated
RANAP: RELOCATION COMPLETE
priorities information to UE

RRC: UTRAN Mobility Information ( + Dedicated priority information IE)

RRC: UTRAN Mobility Information Confirm RANAP: IU RELEASE COMMAND

RANAP: IU RELEASE COMPLETE

Figure. UE involved relocation

[Link] SPID information sending to UE via RRC message

User specific priority is sent to UE via RRC: UTRAN MOBILITY

INFORMATION message via "Dedicated priority information" IE
([Link].).
Following information shall be set to "Dedicated priority information" IE:
o RNC sets CHOICE "Action" as the value "Configure dedicated
priorities",
o RNC sets the value of IE "Priority level list" with "Priority status"
read from database.
o RNC sets the CHOICE "Radio Access Technology" to the value
read from database
o RNC sets the IE "priority" to the value read from database
o RNC sets the values in IE "Frequency List" or "BCCH ARFCN" to
the values received from database.
o RNC sets the values in IE "E-UTRA Detection" to the values
received from database.

See chapter 2.7 about parameters used for RAN3079.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 369(447)
Basic Call
 Functionality description

<CR#E1381/begin>

The E-UTRA frequencies 0 – 65535 are included in the IE “EARFCN” in

the E-UTRA Frequency List. If the E-UTRA frequency is greater than
65535, the E-UTRA frequency is included in the IE “EARFCN extension”
and the value of the IE “EARFCN” is set to 65535.

<CR#E1381/end>

NOTE: "Priority Level List" IEs contains maximum, 16 UARFCNs

corresponding to UTRAN frequencies, 32 EARFCNs or more than 3
occurrences of "GSM cell group".

[Link] Dedicated priority Information:

Please note: Nokia RNC does not send timer T322 and dedicated
priorities are valid until the next update.

Information Element/Group name Need Multi Type and Semantics

Reference description
CHOICE Action MP
>Configure dedicated priorities
>>Priority Level List OP 1 to
<maxPrio>
>>>priority OP Integer (0.. If this IE is absent then
<maxPrio–1>) the UE behaviour is
unspecified. 0 is the
lowest priority and
maxPrio-1 is the
highest.
>>>CHOICE Radio Access Technology MP
>>>>UTRA FDD
>>>>>Frequency List MP 1 to <
maxNumFDD
Freqs>
>>>>>>UARFCN MP Integer(0 .. UARFCN of the
16383) downlink carrier
frequency [25.101]
>>>>E-UTRA
>>>>>Frequency List 1 to
<maxNumEUT
RAFreqs>
>>>>>>EARFCN MP Integer(0 .. If the IE indicates a
65535) value of 65535, then
the EARFCN for this
instance should be
read from the
corresponding
instance of IE
"EARFCN extension".
>>>>>>EARFCN extension OP Integer(65536 EARFCN of the
…262143) downlink carrier
frequency [64].

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 370(447)
Basic Call
 Functionality description

>>>>GSM
>>>>>Starting ARFCN MP Integer (0..1023) First ARFCN value in
the set
>>>>>Band Indicator MP Enumerated GSM
(dcs1800, BAND_INDICATOR
pcs1900) [45]
>>>>>CHOICE Following ARFCNs MP
>>>>>>Explicit list
>>>>>>>List of ARFCNs MP 0 to 31 Integer (0..1023) Following ARFCN
values
>>>>>>Equally spaced
>>>>>>>ARFCN spacing MP Integer (1..8) Increment "d" ARFCN
values
>>>>>>>Number of following ARFCNs MP Integer (0..31) Number "n" of
following ARFCN
values, NOTE 1
>>>>>>Variable bitmap format
>>>>>>>Bitmap MP Octet string NOTE 2
(1..16)
>>>>>>Continuous range
>>>>>>>Ending ARFCN MP Integer (0..1023) Last ARFCN value in
the set, NOTE 3
>>E-UTRA detection MP Boolean ‘TRUE’ means that the
UE may detect the
presence of a E-UTRA
cell and report to NAS

NOTE: RNC ensures that priorities for different Radio Access

Technologies are always different (e.g. a GERAN group of cells cannot
have the same priority as a UTRA or E-UTRA frequency).

Please see more about the feature from /47/ Handover Control FD.
<RAN3079/end>

<RAN3110/begin>

2.3.50 RAN3110 HSPA Queueing and Resource Rotation with QoS

This feature introduces HSPA Queuing and NRT-over-NRT functionalities

to the queuing and the scheduling of the resources request for HSPA and
HSDPA allocations in CELL_DCH state.

For HSPA Queuing functionality, see /35/.

With HSPA NRT-over-NRT functionality, new HSPA capacity request may

trigger release of existing HSPA user. HSPA NRT-over-NRT may be
applied to lower, equal or even higher priority users depending on the
QoS settings, minimum allocation times and policy defined by user. NRT-
over-NRT may be based also on the ARP priority levels. However, RABs
are not totally pre-emptied, just mapped to 0/0 or RL is released.

RAN3110 HSPA Queuing and Resource Rotation with QoS is an optional

feature (ASW) and feature usage is controlled by RNC license key.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 371(447)
Basic Call
 Functionality description

Cell level parameter HSPANRTOVERNRTEnabled is used to enable

RAN3110 HSPA queuing and NRT-over-NRT functionalities.

[Link] UE specific RRC handles the victim RAB when NRT-over-NRT is

requested by the UE specific RRM

When NRT-over-NRT is triggered, the UE specific RRM requests the UE

specific RRC to do the NRT-over-NRT in the legacy manner i.e. request
release of the radio resources of the target RABs. The UE specific RRC
executes the NRT-over-NRT for the victim RAB in legacy manner similar
to RT-over-NRT case (PS RAB to DCH 0/0 or state change to CCH).
Direct state transition from Cell_DCH to Cell/URA_PCH is used when
possible.

The actions following NRT-over-NRT request are e.g. the following:

• The target RABs is reconfigured to DCH 0/0 (if not all/the last
active PS RABs are targeted and/or CS RAB exists)

• The UE is moved to Cell_FACH or Cell/URA_PCH state (if all/the

last active the PS RABs are targeted and no CS RAB exists).
Legacy target state decision is used.

NOTE: PRFILE parameter HSPA_DCH_MIN_RES should be set to

prioritize HSPA DCH users over HS-FACH users even if NRT-over-NRT
is triggered by HSPAtot (see parameter usage in /18/).

[Link] NRT-over-NRT over Iur

[Link].1 NRT-over-NRT triggered in DRNC

When UE specific RRM in DRNC indicates that NRT-over-NRT is needed

for resources controlled by SRNC, the UE specific RRC initiates sending
of RNSAP:RADIO LINK PREEMPTION REQUIRED INDICATION
message to SRNC. UE specific RRC includes E-DCH MAC-d Flow ID IE
and/or HS-DSCH MAC-d Flow ID IE in the message according to
information received from UE specific RRM.
There is no dedicated response message or procedure timer on L3.

[Link].2 Reception of RNSAP:RADIO LINK PREEMPTION REQUIRED message in

SRNC

When SRNC receives RNSAP:RADIO LINK PREEMPTION REQUIRED

INDICATION message from DRNC and it contains either E-DCH MAC-d
Flow ID IE and/or HS-DSCH MAC-d Flow ID IEs, the UE specific RRC
executes NRT-over-NRT on the corresponding NRT RAB. NRT-over-
NRT handling depends on whether the target UE has single HS(D)PA
NRT RAB (see [Link].4 NRT-over-NRT on the single NRT on HS(D)PA
RAB over Iur ) or both CS AMR and one HS(D)PA NRT RABs (see
[Link].5 NRT-over-NRT on CS AMR on DCH + one NRT on HS(D)PA
RAB combination over Iur).

If RNSAP:RADIO LINK PREEMPTION REQUIRED INDICATION

message does not contain neither E-DCH MAC-d Flow ID IE nor HS-

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 372(447)
Basic Call
 Functionality description

DSCH MAC-d Flow ID IEs, it is handled in legacy manner, see chapter

[Link] RNSAP Radio Link Pre-emption procedure in SRNC.

[Link].3 Reception of RNSAP: RADIO LINK CONGESTION INDICATION message

in SRNC

Note: Nokia DRNC does not use RNSAP:RADIO LINK CONGESTION

INDICATION to request NRT-over-NRT but other vendor’s RNC may do
so.

When SRNC receives RNSAP:RADIO LINK CONGESTION INDICATION

message from DRNC and it contains DCH Indicator For E-DCH-HSDPA
Operation IE, the SRNC ignores the DCH Rate Information IE. If also E-
DCH MAC-d Flow ID IE is present in the message, the UE specific RRC
executes NRT-over-NRT on the corresponding NRT RAB. NRT-over-NRT
handling depends on whether the target UE has single HS(D)PA NRT
RAB (see [Link].4 NRT-over-NRT on the single NRT on HS(D)PA RAB
over Iur) or both CS AMR and one HS(D)PA NRT RABs (see [Link].5
NRT-over-NRT on a CS AMR on DCH + one NRT on HS(D)PA RAB
combination over Iur). Congestion Cause IE is ignored.

If RNSAP:RADIO LINK CONGESTION INDICATION message does not

contain DCH Indicator For E-DCH-HSDPA Operation IE but does contain
Allowed Rate Information IE, it is handled in legacy manner, see chapter
[Link] Radio Link Congestion procedure in SRNC.

[Link].4 NRT-over-NRT on the single NRT on HS(D)PA RAB over Iur

When DRNC requests NRT-over-NRT of HSPA NRT RAB and SRNC

receives either RNSAP:RADIO LINK PREEMPTION REQUIRED
INDICATION MESSAGE or RNSAP:RADIO LINK CONGESTION
INDICATION message, the UE specific RRC either moves UE to
Cell_FACH or Cell/URA_PCH state or releases the call. Handling of NRT-
over-NRT in SRNC depends on whether the UE is in anchoring (all active
set cells of the UE are in DRNC) or soft handover situation (active set
cells in both SRNC and DRNC).

UE in soft handover

After NRT-over-NRT indication has been received, UE specific RRC

moves UE to Cell_FACH/Cell_PCH/URA_PCH state in legacy manner.

UE in anchoring
After NRT-over-NRT indication has been received, UE specific RRC
checks whether relocation is supported. If

• Relocation is supported: UE specific RRC moves the UE to

Cell_FACH state and omits C-RNTI from state change
command. This causes the UE to start Cell Update procedure
and triggers relocation procedure to DRNC.
• Relocation is not supported: UE specific RRC releases the call
and sends RRC:RRC CONNECTION RELEASE with cause

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 373(447)
Basic Call
 Functionality description

value ‘Directed Signalling Connection Re-establishment’ (DSCR)

to the UE

[Link].5 NRT-over-NRT on CS AMR on DCH + one NRT on HS(D)PA RAB

combination over Iur

When DRNC requests NRT-over-NRT of HSPA NRT RAB and SRNC

receives either RNSAP:RADIO LINK PREEMPTION REQUIRED
INDICATION MESSAGE or RNSAP:RADIO LINK CONGESTION
INDICATION message, UE specific RRC reconfigures NRT RAB to DCH
0/0 allocation (release the radio resources for the PS NRT RAB). Legacy
RNSAP/NBAB RL Reconfiguration and RRC RB Reconfiguration
procedures are used.

<RAN3110/end>

<RAN3342/begin>

2.3.51 RAN3342 Predictive IMSI Based HO

This feature is extension of feature RAN3253. In RAN3253, one

operator's (seeker) UEs are allowed to use certain WCDMA frequency
band of another operator (home), but cells of other WCDMA frequency
band, belonging to home operator, are forbidden for the UEs of seeker
operator. The seeker subscriber's UE are also prevented to be handed
over from allowed frequency band to forbidden frequency band.

The allowed WCDMA frequency band is configured with the legacy WSG
and WANE parameters for each operator separately.

RAN3342 inherits all the above functionalities of RAN3253. The

difference is that whereas RAN3253 uses blind IFHO to move UEs to
allowed frequency, RAN3342 uses legacy inter-frequency and inter-
system measurements for handover decision.

In RAN3342, whenever seeker subscriber's UE in forbidden frequency is

needed to be moved to Cell_DCH due to RAB Assignment Request, then
the call is established in forbidden layer, and inter-frequency
measurements are started to handover the UE to allowed frequency layer.
If the inter-frequency handover to the allowed frequency doesn't succeed,
the inter-system handover measurements for GSM system are started. If
the inter-system handover to GSM doesn't succeed, the handling of the
call depends whether the UE has CS RAB or not:

• For a UE with CS RAB, the option whether CS call continues or

CS call drops is checked. If the option is ‘CS Call to continue’,
then CS Call is continued in the forbidden layer, and IFHO/ISHO
measurements are performed at certain interval so that as soon as
either coverage of allowed frequency layer is available or GSM
system is available for the UE in question, then UE is handed over
accordingly. If the option is 'CS Call to Drop', then CS RAB is
released, and if this is the only RAB with UE, then UE's RRC
connection is released in forbidden layer.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 374(447)
Basic Call
 Functionality description

• The UE with only PS RAB is moved to CCH state.

When RAB Assignment Request for seeker UE is received for PS NRT

RAB, then this RAB is established without user plane allocation, i.e. PS
NRT RAB is mapped to DCH 0/0.

Emergency related calls from seeker subscriber UEs are allowed in all
frequency bands (including forbidden), and no restrictions of forbidden
layer are applied as long as RRC connection exists for the user of
emergency call.

[Link] RAN3342 is controlled by RNC license key of RAN3253 feature

RAN3342 reuses the RNC license key of feature RAN3253 IMSI Based
Frequency Based HO.

The license is long term on/off license 'IMSI Based Frequency Based HO'
(feature code: 4445).

The feature is enabled when all the following conditions are fulfilled:

• the license 'IMSI Based Frequency Based HO is installed in the

RNC and the state of the feature is 'On'

• the license 'RU00028 IMSI based handover RLIC' is installed in

the RNC and the state of the feature is 'On' (FIFILE 002:895
IMSI_BASED_HANDOVER_SUP)

• value of the PRFILE parameter 002:2275 RU50_SPARE_13 Bit at

position 1 is set to value '1' (see below)

[Link] PRFILE Parameter 002:2275 RU50_SPARE_13 is used to control

RAN3342

PRFILE Parameter 002:2275 RU50_SPARE_13 is used to control

following:

• Activation, and Deactivation of feature RAN3342 : 1 bit

• As a switch whether 'CS call to continue' or 'CS call to drop' : 1 bit

• Managed objects ID: 7 bits ( see /47/)

1st Bit : (LSB): Value '0' = Feature RAN3342 is Deactivated.

: Value '1' = Feature RAN3342 is Activated.

By default 1st Bit is set to '0' Feature RAN3342 is Deactivated.

2nd Bit : Value '0' = 'CS Call to Drop'

: Value '1' = 'CS Call to Continue'

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 375(447)
Basic Call
 Functionality description

By default 2nd Bit is set to value '0', i.e., CS Call to Drop

9th Bit to 3rd Bit : Managed Object ID

[Link] The allowed 3G frequencies are configured with the legacy WSG and
WANE parameters

The allowed frequencies are configured with legacy WSG and WANE
parameters as specified in RAN3253 (see [Link]).

[Link] Direct Resource Allocation is not applied to the UE in forbidden

frequency

When the RANAP:RAB ASSIGNMENT REQUEST for PS NRT RAB

either in Cell_FACH or in Cell_DCH state is received, the UE specific
RRC checks whether the UE is in allowed frequency. If the UE is not in
the allowed frequency DRA is not be applied.

PS RAB is always mapped to DCH 0/0 when UE is in forbidden layer in

Cell_DCH state.

[Link] UE is moved to allowed frequency after successful RAB Assignment

procedure in Cell_DCH state

After successful RAB Assignment procedure has been completed by

sending RANAP:RAB ASSIGNMENT RESPONSE when UE is in
Cell_DCH state, the UE specific RRC checks whether the UE is in
allowed frequency.

If the UE is not in the allowed layer, this is indicated to Handover Control

for handover decision to allowed layer. If handover control entity decides
to start inter-frequency/inter-system handover, the UE specific RRC
executes IFHO ([Link]) or ISHO ([Link]). If neither IFHO nor ISHO is
possible, the handover control entity indicates this to the UE specific RRC
which proceeds as specified in [Link].

If the UE stays in the Cell_FACH after the RAB Assignment procedure,

legacy RAB Assignment procedure is performed. The UE is, if needed,
moved to the allowed frequency when state transition to Cell_DCH state
is triggered ([Link]).

Depicted below are IFHO and ISHO procedures after RAB Assignment
procedure:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 376(447)
Basic Call
 Functionality description

UE BTS RNC CN

Signalling link established, UE in Cell_DCH state in forbidden frequency

RANAP: RAB ASSIGNMENT REQUEST

AMR RAB request

NBAP Radio Link Reconfiguration procedure

User plane setup

User Plane Setup

RRC: RADIO BEARER SETUP

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

Allowed layer check:

UE is not in allowed layer -> CM
for IFHO started

Compressed mode measurements for IFHO started

RRC: MEASUREMENT REPORT

Target cell found -> Decision to

move UE to the allowed layer

NBAP Radio Link setup procedure

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION

(Frequency info, Primary Scrambling Code)

UE changes the
frequency NBAP:SYNCHRONISATION INDICATION

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION COMPLETE

Radio Link Deletion

UE in allowed frequency in CELL_DCH state

Figure 2.3.51-1 CS RAB Assignment, Cell_DCH, IFHO

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 377(447)
Basic Call
 Functionality description

UE BTS RNC CN

Signalling link established, UE in Cell_DCH state in forbidden frequency

RANAP: RAB ASSIGNMENT REQUEST

AMR RAB request

NBAP Radio Link Reconfiguration procedure

User plane setup

User Plane Setup

RRC: RADIO BEARER SETUP

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

Allowed layer check:

UE is not in allowed layer -> CM
for IFHO started

Compressed mode measurements for IFHO started

RRC: MEASUREMENT REPORT

No IFHO target cell found->CM

for ISHO started

Compressed mode measurements for ISHO started

RRC: MEASUREMENT REPORT

GSM target found-> ISHO to

GSM

Legacy ISHO to GSM procedure

Figure 2.3.51-2 CS RAB Assignment, Cell_DCH, ISHO

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 378(447)
Basic Call
 Functionality description

UE BTS RNC PS CN

Signalling link established, UE in Cell_DCH state in forbidden frequency

RANAP: RAB ASSIGNMENT REQUEST

PS RAB request.
Allowed layer check:
UE in forbidden frequency ->
DRA not allowed, no UP
allocation

User Plane Setup

RRC: RADIO BEARER SETUP

RRC: RADIO BEARER SETUP COMPLETE

RANAP: RAB ASSIGNMENT RESPONSE

Allowed layer check:

UE is not in allowed layer -> CM
started

Compressed mode measurements for IFHO started

RRC: MEASUREMENT REPORT
(inter-frequency)

Target U2100 cell not found ->

Decision to change CM pattern
for ISHO. First GSM RSSI
measurements

NBAP:COMPRESSED MODE COMMAND

(CFN, TGPSI 2

RRC: MEASUREMENT CONTROL

(GSM RSSI, CFN, TGPSI 2)

RRC: MEASUREMENT REPORT

Optional CM pattern changed to

GSM BSIC verification

NBAP:COMPRESSED MODE COMMAND

(CFN, TGPSI 3)

RRC: MEASUREMENT CONTROL

(BSIC Identification, CFN, TGPSI 3)

RRC: MEASUREMENT REPORT

GSM target found-> inter-RAT

cell change

RRC: CELL CHANGE ORDER FROM UTRAN

Optional
RANAP:SRNS CONTEXT REQUEST

RANAP:SRNS CONTEXT RESPONSE

RANAP:SRNS DATA FORWARD COMMAND

RANAP: IU RELEASE COMMAND

RANAP: IU RELEASE COMPLETE

Radio Link Deletion (U900)

Figure 2.3.51-3: PS RAB Assignment, Cell_DCH, ISHO

[Link] UE specific RRC performs legacy IFHO procedure if triggered by
Handover Control for UE in the forbidden frequency

If triggered by handover control entity, UE specific RRC in legacy

manner starts inter-frequency compressed mode measurements, reports

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 379(447)
Basic Call
 Functionality description

measurement results to handover control entity and starts IFHO

procedure.

If there is a failure during CM configuration towards BTS or CM

measurement initiation on UE, the indication of failed CM start is
forwarded to the handover control entity. The UE specific RRC proceeds
as specified in [Link].

If there is a failure during IFHO procedure, failure indication is forwarded

to handover control entity and the UE specific RRC proceeds as
specified in [Link].

If no suitable IFHO target cell is found but ISHO is possible, the

handover control entity starts CM for ISHO and the UE specific RRC
proceeds as specified in [Link].

If no suitable IFHO target cell is found and ISHO is not possible, the
handover control entity indicates this to the UE specific RRC which
proceeds as specified in [Link].

[Link] The UE is moved to allowed frequency after the UE is transferred from

CCH state to Cell_DCH state

When the UE specific RRC decides to change the UE state from

Cell_PCH/URA_PCH/Cell_FACH to Cell_DCH for legacy reasons, the UE
specific RRC checks whether the UE is in allowed frequency.

After UE has indicated successful state change to Cell_DCH (RADIO

BEARER RECONFIGURATION COMPLETE is received) the UE specific
RRC checks whether the UE is in allowed frequency. If the UE is not in
the allowed frequency the UE specific RRC indicates this to handover
control entity for handover decision to allowed layer.

If handover control entity triggers IFHO, the UE specific RRC proceeds as

specified [Link].

If IFHO is not possible but ISHO is, the handover control entity starts CM
for ISHO and the UE specific RRC proceeds as specified in [Link].

If neither IFHO nor ISHO is possible, the handover control entity indicates
this to the UE specific RRC which proceeds as specified in [Link].

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 380(447)
Basic Call
 Functionality description

UE BTS RNC

UE in CELL_FACH

DL capacity request or
Measurement Report from UE is
received

If UE is in the forbidden
frequency, -> DCH 0/0
allocation

NBAP Radio Link Setup procedure

RRC:RADIO BEARER RECONFIGURATION

( Cell_DCH)

RRC:RADIO BEARER RECONFIGURATION COMPLETE

UE is in the forbidden frequency

-> HO indication to HC
-> CM started for IFHO

Compressed mode measurements for IFHO started

RRC: MEASUREMENT REPORT

Target cell found -> Decision to

move UE to the allowed layer

NBAP Radio Link setup procedure

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION

(Frequency info, Primary Scrambling Code)

UE changes the
frequency
NBAP:SYNCHRONISATION INDICATION

RRC: PHY/Tr CHANNEL/RB RECONFIGURATION COMPLETE

NBAP Radio Link Deletion procedure

UE in allowed frequency layer in CELL_DCH state

Figure 2.3.51-4: State transfer from Cell_FACH to Cell_DCH, IFHO

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 381(447)
Basic Call
 Functionality description

[Link] Failed IFHO procedure

If the UE specific RRC encounters internal errors (e.g. lack of

resources/timeout) before sending the HO command, this is indicated to
handover control entity and UE specific RRC proceeds as indicated by
handover control entity as below.

The UE specific RRC handles the following failed IFHO procedure cases
after sending the HO command message:

• RRC:PHYSICAL CHANNEL/TRANSPORT CHANNEL/RADIO

BEARER RECONFIGURATION FAILURE is received: Legacy
handling. The indication of the failed IFHO is forwarded to the
handover control entity and UE specific RRC proceeds as
indicated by HC below.

• RRC:CELL UPDATE is received: Legacy RRC connection re-

establishment. The UE specific RRC proceeds as specified in
[Link].

• RRCHHOtimer expires: Legacy RRC connection re-establishment.

The UE specific RRC proceeds as specified in [Link].

The handover control entity indicates after IFHO failure to UE specific

RRC to either

• Start CM measurements for ISHO to GSM. The UE specific RRC

proceeds as specified in [Link].

• Indication that ISHO to GSM is not possible. The UE specific RRC

proceeds as specified in [Link].

[Link] UE specific RRC performs legacy ISHO procedure if IFHO procedure to

move the UE from the forbidden frequency fails

If triggered by handover control entity, UE specific RRC in legacy manner

starts inter-system compressed mode measurements, report
measurement results to handover control entity and start ISHO
procedure.

If there is a failure during CM configuration on BTS or CM measurement

initiation on UE, the indication of failed CM start is forwarded to the
handover control entity. The UE specific RRC proceeds as specified in
[Link].

If there is a failure during ISHO procedure, the UE specific RRC proceeds

as specified in [Link] or [Link], depending on the used service.

If no suitable ISHO target cell is found, the handover control entity

indicates this to the UE specific RRC which proceeds as specified in
[Link].

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 382(447)
Basic Call
 Functionality description

[Link] Failed ISHO to GSM for CS service or CS+PS multi-service

The UE specific RRC handles the following failed ISHO procedure cases
after sending RRC:HANDOVER FROM UTRAN COMMAND message:

• RRC:HANDOVER FROM UTRAN FAILURE message is received:

Legacy handling; after RANAP:Relocation Cancel procedure the
UE specific RRC proceeds as specified in [Link].

• Timer TrelocOverall expires: Legacy handling; after

RANAP:Relocation Cancel procedure the UE specific RRC
proceeds as specified in [Link].

• RRC:CELL UPDATE message is received: After legacy RRC

connection re-establishment, the UE specific RRC proceeds as
specified in [Link].

• Timer T_Inter_RAT_HO expires: Legacy handling (RRC

Connection Re-establishment timer(s) started). After legacy RRC
connection re-establishment, the UE specific RRC proceeds as
specified in [Link]. NOTE: If parameter T314 is configured to
'0', this is not counted as an ISHO failure case.

• RRC Connection Re-establishment timer expires: Legacy handling

(Iu/RRC connection release).

[Link] Failed ISHO to GSM for PS service

The UE specific RRC handles the following failed ISHO procedure cases
after sending RRC:CELL CHANGE ORDER FROM UTRAN message:

• RRC:CELL CHANGE FROM UTRAN FAILURE message is

received: After legacy handling the UE specific RRC proceeds as
specified in [Link].

• RRC:CELL UPDATE message is received: After legacy RRC

connection re-establishment, the UE specific RRC proceeds as
specified in [Link].

• Timer GeneralRANAPTmr expires: Legacy handling (Iu/RRC

connection release).

• RRC Connection Re-establishment timer expires: Legacy handling

(Iu/RRC connection release).

[Link] UE specific RRC handles the case when ISHO to GSM is not possible or
it does not succeed

If the ISHO to GSM is not possible, there is a failure during CM

configuration on BTS or CM measurement initiation on UE or the ISHO
procedure has failed and the UE has CS RAB, the UE specific RRC
checks the PRFILE Parameter 002:2275 RU50_SPARE_13. When the
parameter has the following values, the UE specific RRC does either:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 383(447)
Basic Call
 Functionality description

• 'CS Call to Continue': Allow the CS or CS+PS call to continue on

forbidden frequency, see [Link].3

• 'CS Call to Drop': Release the CS or CS+PS call: see [Link].1

• UE with PS only RAB is moved to CCH state regardless of the

PRFILE Parameter 002:2275 RU50_SPARE_13 value, see
[Link].2.

[Link].1 CS or CS+PS call dropped from forbidden layer

If the PRFILE Parameter 002:2275 RU50_SPARE_13 (_252) has been

set to value 'CS Call to Drop' and

• UE has only CS RAB: The call is released with release cause

‘normal event’ used in the RRC:RRC CONNECTION RELEASE
and Network Layer Cause 'Failure in the Radio Interface
Procedure(14)' in RANAP: IU RELASE REQUEST

• UE has CS and PS RABs: The Iu CS connection is released (Iu

Cause 'Failure in the Radio Interface Procedure(14)'). CS RB and
signaling connection is released using RRC: RADIO BEARER
RELEASE message in legacy manner. Then the UE is moved to
CCH state as specified in [Link].2.

[Link].2 UE with PS only RAB is moved to CCH state

UE with only PS RAB is moved away from Cell_DCH state to

Cell/URA_PCH if possible as follows:

• Parameter RNFC-DCHtoPCHEnabled is overridden so that direct

state transition from Cell_DCH to Cell/URA_PCH is always
allowed.

• If the PCH states cannot be used e.g. the UE does not support
neither of the PCH states, the call is released. Release cause
‘normal event’ is used in the RRC:RRC CONNECTION RELEASE
and Network Layer Cause 'Failure in the Radio Interface
Procedure(14)' in RANAP: IU RELASE REQUEST

• If direct state transfer from Cell_DCH to Cell/URA_PCH is

prevented for any other reason, the UE is moved to Cell_FACH
state. Immediately after state transition, the UE is moved to
Cell/URA_PCH state.

When the UE is in Cell/URA_PCH state, the UE specific RRC proceeds

as specified in [Link].4.

[Link].3 CS or CS + PS call is allowed to continue in forbidden layer

If allowed by PRFILE Parameter 002:2275 RU50_SPARE_13 (parameter

set to 'CS Call to Continue'), CS or CS + PS call can continue in forbidden
layer due to unavailability of allowed layer (U2100) and GSM system.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 384(447)
Basic Call
 Functionality description

While UE stays in the forbidden layer, PS RAB remains on DCH 0/0. If PS

RAB Assignment request is received, PS RAB is established with DCH
0/0. UL/DL capacity requests for PS RAB are ignored.

If the handover control entity restarts IFHO/ISHO measurements to move

UE to allowed layer, the UE specific RRC proceeds as specified in
[Link] and [Link].

At the end of the CS only call, CS RAB is released in legacy way.

If PS RAB with DCH 0/0 still exists at the release of CS RAB, the legacy
Signaling Connection Release is performed for CS domain and the UE is
moved to CCH state as specified in [Link].2

[Link].4 PS call is allowed to continue in forbidden layer in Cell/URA_PCH

state

If the UE has been moved Cell/URA_PCH state to due to unavailability of

allowed layer (U2100) and GSM system, the received RRC:CELL
UPDATE messages are handled as follows:

• If RRC:CELL UPDATE has been received from allowed layer:

legacy handling

• If RRC:CELL UPDATE has been received from forbidden layer:

Either

o The message is ignored in case:

▪ RRC:CELL UPDATE is received as a response for
UTRAN generated paging when paging is triggered
by DL data indication from L2
▪ RRC:CELL UPDATE with Cell Update cause ‘uplink
data transmission’ and the Establishment cause
has not value ‘Originating Conversational Call’
▪ Ignoring the message means that no RRC:CELL
UPDATE CONFIRM message is sent to UE.
o In other cases legacy handling.

When UE is moved to Cell_FACH, UL/DL capacity requests are handled

normally.

[Link] Capacity request during CM measurements

If capacity request for PS call is received while IFHO/ISHO neighbor CM

measurement is ongoing to move the UE from forbidden frequency, the
request are ignored by UE specific RRC.

[Link] RRC connection re-establishment

If UE loses the radio connection due to radio link failure in Cell_DCH

state, RRC connection re-establishment is performed according to the
legacy implementation after UE performs cell reselection by sending
RRC: CELL UPDATE message to RNC.

If after RRC connection re-establishment the UE is in Cell_FACH state,

the UE specific RRC proceeds in legacy manner.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 385(447)
Basic Call
 Functionality description

If the RRC connection re-establishment is performed with direct state

transition to Cell_DCH state, after the procedure the UE specific RRC
checks whether the UE is in allowed layer.

If the UE is in the allowed layer the UE specific RRC proceeds in legacy

manner.

If the UE is not in the allowed layer the UE specific RRC indicates this to
handover control entity for handover decision to allowed layer.

The handover control entity either starts IFHO/ISHO measurements and

the UE specific RRC proceeds as specified in [Link]/[Link].

Or the handover control entity indicates that IFHO/ISHO is not possible

and the UE specific RRC proceeds as specified in [Link].

[Link] UE specific RRC evaluates the need for IFHO/ISHO after Relocation in
DRNC

After Relocation procedure has been completed in DRNC, the UE specific

RRC checks whether the UE is in allowed layer.

If the UE is not in the allowed layer and the UE has PS RAB(s) which
have UP allocated, the UE specific RRC reconfigures the PS RAB(s) to
DCH 0/0. If handover control entity decides to start inter-frequency/inter-
system handover, the UE specific RRC executes IFHO/ISHO as specified
in [Link]/[Link]. If neither IFHO nor ISHO is possible is, the handover
control indicates this to the UE specific RRC which proceeds as specified
in [Link].

[Link] UE specific RRC determines the Operator Id for the UE

The UE specific RRC sets the initial value of the Operator Id to value
'host'. When the IMSI becomes available, the UE specific RRC checks
whether the allowed WCDMA band definition exists for the UE. If the
allowed WCDMA band definition exists, the UE specific RRC changes the
Operator Id value to 'seeker'.

Values 'host' and 'seeker' are hardcoded so that 'host' corresponds to 1

and 'seeker' to 2.

The UE specific RRC uses the Operator Id when updating operator

specific counters and sends the Operator Id to TIIPRB for statistics
purposes.

[Link] UE specific RRC prevents MBLB triggered Blind IFHO when UE is in

forbidden layer

If either of the MBLB features RAN2172 or RAN3093 triggers Blind IFHO,

the UE specific RRC checks whether the UE is in allowed layer.

If the UE is not in the allowed layer, the UE specific RRC prevents the
Blind IFHO.

<RAN3342/end>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 386(447)
Basic Call
 Functionality description

<RAN3405/begin>

2.3.52 RAN3405 Selective Roaming with Shared Area PLMNs

RAN3405 (CRE1351) allows two operators to configure spectrum sharing

in RAN that is connected to only host operator’s core network. Host
operator’s cells are configured with IUO-PLMNid while sharing operator’s
cells are configured with IUO-SharedAreaPLMNid.

With this feature it possible to configure RNC so that international

roaming UEs are restricted to host operator’s cells. This requires that
IMSI Based HO feature is also activated. Legacy CN functionality
prevents the roaming UEs from camping to other than host operator’s
cells when the UE is in IDLE mode. Legacy IMSI based HO functionality
prevents handovers of roaming UEs to other than host operator’s cells.

New functionality implemented with this feature is prevention of roaming

UEs from making cell reselection to sharing operator’s cell in common
channel state (Cell_FACH/Cell_PCH/URA_PCH).

In addition, some changes are needed to Service Area Broadcast

functionality to allow cell configuration with Shared Area PLMN Id, see
/14/.

[Link] RAN3405 is controlled by PRFILE parameter

RAN3405 contains two sub-functionalities, but only the allowed cell check
subfunctionalty is controlled by 3rd bit of PRFILE parameter
RU50_SPARE_12 002:2274. If 3rd bit is “0”, the functionality is disabled
(default value). If 3rd bit is “1”, the functionality is enabled.

SAB functionality changes are enabled if IMSI based HO has been

activated in the RNC (control in FIFILE).

[Link] UE specific RRC checks that the UE is in the allowed cell after cell
resection

When SRNC receives RRC:CELL/URA UPDATE message, RNC checks

if RAN3405 and IMSI based HO features are enabled/activated. If they
are enabled/activated, the UE specific RRC checks whether the UE is in
allowed cell. By comparing PLMN Id of the IMSI to HomePLMN
parameter of the WSG objects, the UE specific RRC finds the correct
WANE object and the corresponding AuthorisedNetworkList. If the PLMN
identifier of the subscriber does not match with any of the configured
HomePLMN parameters, the default WANE object is used (configured
with parameter DefaultAuthorisedNetworkId). If the PLMN ID of the
current cell is included in the AuthorisedNetworkList, the UE is in the
allowed cell and legacy functionality is followed. If the UE is not in the
allowed cell, the RCC connection is released with RRC:RRC
CONNECTION RELEASE using cause ‘normal event’ and the Iu
connection is released with RANAP: IU RELASE REQUEST using NAS
Cause ‘Normal Release(83)’.

If RRC: CELL/URA UPDATE is received DRNC, it is forwarded to SRNC

over Iur in RNSAP: UPLINK SIGNALLING TRANSFER INDICATION.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 387(447)
Basic Call
 Functionality description

SRNC receives the PLMN Id of the cell in the SAI IE and makes the
allowed cell check. If the UE is not in allowed cell, the SRNC releases
RRC connection by sending RRC:RRC CONNECTION RELEASE over
Iur and sends RANAP: IU RELASE REQUEST to CN.

[Link] Feature interaction

[Link].1 Prerequisite features

The feature RAN2.0060 IMSI Based handover is the prerequisite for

RAN3405 feature.

[Link].2 Features which cannot be used simultaneously with RAN3405

The following features cannot operate simultaneously with RAN3405. The

simultaneous use of these features with RAN3405 hasn't been restricted
through any SW implementation.

• RAN2.0042 Nokia Multi-operator RAN (MORAN)

• RAN966 Multi-operator core network (MOCN)

• RAN2.0079 Directed RRC connection setup

• RAN964 Directed RRC connection setup for HSDPA layer

• RAN147 RRC Connection Redirection

• RAN1011 HSPA layering for UEs in common channels

• RAN2135 Layering in RRC Connection Release

• RAN3253 IMSI Based Frequency Based HO

• RAN3342 Predictive IMSI Based HO

<RAN3405/end>

<RAN3292/begin>

2.3.53 RAN3292 Idle Paging Repetition

To increase success probability for paging, this feature enables the RNC
to repeat each Idle Mode RRC: PAGING TYPE 1 messages two times.
This is done also for CN repeated Idle Paging messages.

As in legacy implementation, Resource Control sets the paging priority

(Low/High). L2 uses internally two new paging priority levels for
repetitions:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 388(447)
Basic Call
 Functionality description

• 1st Idle Paging Repetition, lower than Low prioritiy.

• 2nd Idle Paging Repetition, lowest priority.

This feature is part of the Basic Software. The RAN3292 feature is

activated in RNC when the management parameter RNFC-
IdlePageRepetitionEnabled is set to either value

• “Idle paging repetition for CS paging enabled”: Paging from CS CN is

repeated, OR

• “Idle paging repetition for CS and PS paging enabled”: Paging from

both CS and PS CN is repeated

RNC repeats paging only when there is capacity on the paging channel.

CN RNC UE
(Idle Mode)

RANAP:PAGING
RRC:PAGING TYPE 1 RNC(UTRAN) repeated
DRX length
paging for ‘Idle Mode’
, Next paging occasion
RRC:PAGING TYPE 1
UE.
(1st Idle Paging Repetition) 2 repetitions for Idle
Paging
RRC:PAGING TYPE 1 Improved Paging
2nd Idle Paging Repetition Success rate
Optional :CN Repeats
RANAP:PAGING
Paging in case of no
response from UE
RRC:PAGING TYPE 1

RRC:PAGING TYPE 1 Paging Repeated by CN

(1st Idle Paging Repetition)
are also repeated by
RNC
RRC:PAGING TYPE 1
2nd Idle Paging Repetition

Figure 2.3.53-1 Idle Paging Repetition

[Link] Setting of the idle paging repetition indicator

When Resource Control (RC3) receives RANAP:PAGING message from

CN, it finds out in legacy manner whether UE is in idle mode and did the
page came from CS or PS core. Resource Control sets the paging pritority
(High/Low) in legacy manner.

Resource Control reads the value of the parameter RNFC-

IdlePageRepetitionEnabled ("Idle paging repetition for CS paging
enabled", "Idle paging repetition for CS and PS paging enabled" or "Idle
paging repetition disabled") and sets the idle paging indication value
accordingly.

Resource Control forwards the idle paging indication with internal idle
paging message to L2 via Cell Traffic Manager (RRB).

Note: RNC originated idle mode pagings are not repeated.

<RAN3292/end>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 389(447)
Basic Call
 Functionality description

<RAN3431/beging>

2.3.54 RAN3431 Optimized CS Call Setup over Iur

The feature RAN3431 Optimized CS Call Setup over Iur extends the feature
RAN3228 CS Call Re-establishment over Iur, applying those existing
functionalities for Anchoring for re-establishment also to normal call setup
scenario.

When the AMR call is initiated at the same time with cell re-selection to a cell
under other RNC, the call is established immediately in anchoring and relocation
is performed afterwards, if still applicable.

This feature improves AMR call setup time and reliability in inter-RNC border
areas. Such areas are prone to cell reselections, where NAS procedures (LAU,
RAU) delay the call establishment in some case by several seconds. Without
RAN3431, until Cell_FACH relocation is completed (a precondition for call
establishment to proceed in new RNC), additional cell reselections can occur.

When RAN3431 is activated and SRNC receives RRC: CELL UPDATE from DRNC
indicating CS call establishment, the CS call is setup in anchoring mode.

Signaling flow of the procedure is depicted below.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 390(447)
Basic Call
 Functionality description

UE BTS 1 BTS 2 DRNC SRNC CS CN

UE is in CELL_FACH, CELL_PCH or
URA_PCH state

RRC: CELL UPDATE

( Estblishment Cause=Orig conv call)

RNSAP: UL SIGNALLING TRANSFER INDICATION

The UE selects a cell controlled by

(Cell Update(Orig conv call))
the target RNC and initiates a RRC
Cell Update Procedure via the BTS
2. Simultaneuosly UE starts CS call
RAN3431 active-> UE stays in anchoring

RNSAP:RADIO LINK SETUP REQUEST

(SRB)

NBAP:Radio Link Setup (SRB)

RNSAP:RADIO LINK SETUP RESPONSE

RNSAP: DL SIGNALLING TRANSFER INDICATION

(Cell Update Confirm (RRC State Indicator= Cell_DCH)

RRC: CELL UPDATE CONFIRM

(RRC State Indicator= Cell_DCH)

NBAP:RADIO LINK RESTORE INDICATION

RNSAP: RADIO LINK RESTORE INDICATION

RRC:RADIO BEARER RECONFIGURATION COMPLETE

CS call setup continues in anchoring

CC:CONNECT ACKNOWLEDGEMENT

After this message,

Relocation is
allowed to trigger

Figure 2.3.54-1 Optimized CS Call Setup over Iur

[Link] RAN3431 is controlled by RNC license key of RAN3228 feature

RAN3431 reuses the RNC license key of feature RAN3228 CS Call Re-
establishment over Iur.

The license is long term on/off license "CS Call Re-establishment over
Iur" (feature code: 5661).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 391(447)
Basic Call
 Functionality description

[Link] RAN3431 is controlled by the PRFILE Parameter and the License in

WCDMA17 release

The RAN3431 feature is enabled in RNC, when following conditions are

satisfied:

• The license “CS Call Re-establishment over Iur" exists and is set
to state “ON”

• PRFILE Parameter 002:2411 CTRL_MAINT_SPARE_14 is set to

value 01H

The RAN3431 feature is disabled in RNC, when one of following

conditions is satisfied:

• The license "CS Call Re-establishment over Iur" does not exist or
is set to state “OFF or CONFIG”

• PRFILE Parameter 002:2411 CTRL_MAINT_SPARE_14 is set to

value 00H

By default the feature is disabled.

[Link] RAN3431 is controlled by the Activation Parameter and the License in

WCDMA18 release

The RAN3431 feature is enabled in RNC, when following conditions are

satisfied:

• The license "CS Call Re-establishment over Iur" exists and is set
to state “ON”

• The management parameter IUR-OptCSCallOvIurEnabled is set

to value “Optimized CS Call Setup over Iur enabled”

The RAN3431 feature is disabled in RNC, when one of following

conditions is satisfied:

• The license "CS Call Re-establishment over Iur" doesn't exist or is

set to state “OFF or CONFIG”

• The management parameter IUR-OptCSCallOvIurEnabled is set

to value “Optimized CS Call Setup over Iur disabled"

The feature can be activated and deactivated without locking/unlocking of

any objects.

[Link] SRNC checks whether the Optimized CS Call Setup over Iur is to be
triggered

When SRNC receives RNSAP: UL SIGNALLING TRANSFER

INDICATION message over Iur containing RRC:CELL UPDATE, the UE
specific RRC checks whether the conditions exist to trigger Optimized CS
Call Setup over Iur functionality. The conditions are following:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 392(447)
Basic Call
 Functionality description

• The feature has been enabled. For WCDAM17 release see

[Link], for WCDMA18 release see [Link]

• The Establishment cause IE of the RRC:CELL UPDATE has value

“Originating Conversational Call”, “Terminating Conversational
Call” or “Emergency Call”.

If the conditions are satisfied, the UE specific RRC starts the Optimized
CS Call Setup over Iur procedure.

[Link] UE specific RRC initiates Optimized CS Call Setup over Iur procedure

If the conditions for Optimized CS Call Setup over Iur are fulfilled (see
above), the UE specific RRC initiates Optimized CS Call Setup over Iur
procedure. Only SRB radio resources are established in DRNC. DCH 0/0
is allocated to the PS NRT RAB(s).

Even if conditions for RAN2972 Multi-RAB SRNS Relocation

Incompatibility with Huawei DRNC functionality are satisfied, the UP is not
allocated for PS NRT RAB(s) during Optimized CS Call Setup over Iur
procedure.

The UE specific RRC entity sends a request for new RL Setup to DRNC
in the cell that the UE sent the RRC: CELL UPDATE. Similarly to
RAN3228, SRNC includes Propagation Delay (from RNSAP: UPLINK
SIGNALLING TRANSFER INDICATION). If RACH measurement for
CPICH Ec/No is not available, hardcoded value for Primary CPICH Ec/No
(-8 dB) is set to the RNSAP: RADIO LINK SETUP REQUEST.

In RNSAP: RL SETUP RESPONSE, SRNC receives the Primary

Scrambling Code IE, DL UARFCN IE and UL UARFCN IE.

After successful RL setup, the UE is ordered to Cell_DCH state with

RRC:CELL UPDATE CONFIRM in RNSAP: DOWNLINK SIGNALLING
TRANSFER INDICATION. SRNC sets the "D-RNTI Release Indication" IE
as "not Release D‑RNTI " in RNSAP message and includes the Primary
Scrambling Code received from the DRNC.

After the state transition is completed, the CS call setup proceeds in

anchoring mode.

[Link] UE specific RRC ignores PS capacity requests during CS Call Setup

When the Optimized CS Call Setup over Iur procedure is triggered, the
UE specific RRC starts an twelve second inhibition timer to prevent UP
allocations for PS. While the inhibition timer is running, UE specific RRC
ignores capacity request for PS service. The inhibition timer is stopped
when CS call setup is completed i.e. RRC:RADIO BEARER SETUP
COMPLETE is received from the UE.

If the timer UL_DLcapacityReqWait expires while the inhibition timer is

running, it is ignored.

If the inhibition timer expires, DSCR procedure is initiated for the UE.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 393(447)
Basic Call
 Functionality description

[Link] UE specific RRC rejects UE not involved Relocation initiations from

Handover Control during CS Call Setup

UE specific RRC rejects UE not involved Relocation initiation attempts

from Handover Control until the UE has responded to CC: CONNECT
from CS CN. UE not involved Relocation is allowed to proceed only after
the UE has sent RRC:UPLINK DIRECT TRANSFER containing
CC:CONNECT ACKNOWLEDGEMENT (MOC case) or received
CC:CONNECT ACKNOWLEDGEMENT from CS CN (MTC case).

After CC:CONNECT ACKNOWLEDGEMENT or RANAP:IU RELEASE

COMMAND from CS CN, UE not involved Relocation triggers
immediately.

NOTE: If after Relocation initiation there exists PS NRT RAB(s) with DCH
0/0 allocation and the conditions for RAN2972 Multi-RAB SRNS
Relocation Incompatibility with Huawei DRNC functionality are satisfied,
the Iu PS connection is released before Relocation.

[Link] UE specific RRC releases the call if CS Call Setup fails

If UE specific RRC in SRNC receives an error message or procedure

timer or inhibition timer expires indicating that the radio link setup for SRB
or the CS call setup over Iur does not succeed, the UE specific RRC
interrupts the procedure and initiates the DSCR procedure over Iur.

DSCR is also initiated if RRC:CELL UPDATE is received from DRNC or

RANAP:IU RELEASE COMMAND is received from CS CN during CS call
setup procedure.

The relevant legacy timers are:

• RL Setup supervision timer T_DRNC_response

• RRC: RADIO BEARER RECONFIGURATION COMPLETE wait

timer (length selection in legacy manner)

• RRC: RADIO BEARER SETUP procedure timer

T_RRC_Resp_DCH

[Link] SRNC handles CELL UPDATE via SRNC cell during the Optimized CS
Call Setup over Iur procedure

If RRC:CELL UPDATE is received via the SRNC cell during the

Optimized CS Call Setup over Iur procedure, the SRNC does the
following:

• If the CELL UPDATE is received before the Radio Link Setup

procedure has been started, the SRNC interrupts the procedure
and handles the CELL UPDATE in legacy manner.

• If the CELL UPDATE is received before RRC:RADIO BEARER

RECONFIGURATION COMPLETE response for CUC is received
but after the Radio Link Setup procedure has been started, the
SRNC interrupts the procedure and initiates the Radio Link

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 394(447)
Basic Call
 Functionality description

Deletion procedure for the existing RL. Response from DRNC for
RL Setup is waited before starting RL Deletion. After the RL has
been deleted, the SRNC handles the CELL UPDATE in legacy
manner.

• If the CELL UPDATE is received after RRC:RADIO BEARER

RECONFIGURATION COMPLETE response for CUC is received,
the SRNC shall handle the CELL UPDATE in legacy or in
RAN3376 specified manner.

[Link] UE specific RRC indicates that procedure is ongoing to L2

During DCH resource reservation, the UE specific RRC indicates to TRM

entity that the Optimized CS Call Setup over Iur procedure is ongoing by
using special value of rab_dcs_mode. TRM entity forwards the indication
to L2. This allows L2 to handle state transition from Cell_FACH to
Cell_DCH in the situation where UE is commanded to Cell_DCH state
over Iur with RRC:CELL UPDATE CONFIRM. Currently L2 needs
RRC:RADIO BEARER RECONFIGURATION as an input to make the
state transition.

[Link] DRNC shall Handle the Optimized CS Call Setup over Iur procedure as
specified in legacy feature RAN3228

The handling of RNSAP:RADIO LINK SETUP REQUEST is similar to

what has been specified to legacy feature RAN3228, see /20/ chapter “CS
Call Re-establishment over Iur in Anchoring (RAN3228)”.

Also the RRC:CELL UPDATE CONFIRM inside RNSAP: DL SIGNALLING

TRANSFER INDICATION is handled in legacy RAN3228 manner.

<RAN3431/end>

2.3.55 RAN3376 Accelerated Voice Setup

RAN3376 Accelerated Voice Setup (phase1) functionality has the following

optional optimizations for the accelerated CS voice (also CS data) call setup
signalling:

- Accelerated Security Mode Command procedure:

RNC acknowledges the security mode command procedure to CN without waiting
the UE reply, see /L3 Security FD/. This is used for both subscriber A and
subscriber B.

- The accelerated CS RAB assignment procedure:

RNC acknowledges the RAB assignment procedure to CN without waiting the UE
reply. This is used for both subscriber A and subscriber B.

Further for subscriber B, RNC "MTC late assignment" procedure, where by adding
Signal IE into the CC:SETUP message, network requests UE (subscriber B) to
send the ALERT before the traffic channel has been setup to UE. RNC adds signal
IE into the CC:SETUP message.

RAN3376 has activation parameter IUO-AccVoiSetupEnabled, and the license

ACCELERAVOICESETUP (feature code: 0000033753).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 395(447)
Basic Call
 Functionality description

Accelerated Voice Setup is used if the UE is in Cell_DCH state during security

mode command and CS call setup signalling. If CS call is established to UE in
state transition from Cell_FACH to Cell_DCH state, accelerated voice setup is not
used.

Accelerated Voice Setup is not used if RNC identifies that the call setup is for
emergency call.

Note: RAN3376 specification contains also a basic functionality (BSW) where E-

UTRAN capability inquiry is not done during RRC Connection Setup or relocation
procedure (controlled by PRFILE parameter 002:1916 RN60_MAINT_41), see
Handover FD.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 396(447)
Basic Call
 Functionality description

[Link] Accelerated Voice Setup Signalling

CS Call Establishment Subscriber A

NODE: TITLE: Rel.:
(Accelerated)
UE
BTS RNC CN
Subscriber A
RRC:RRC CONNECTION REQUEST

NBAP:RADIO LINK SETUP REQUEST

NBAP:RADIO LINK SETUP RESPONSE

RRC:RRC CONNECTION SETUP

NBAP:RADIO LINK RESTORE INDICATION

RRC:RRC CONNECTION SETUP COMPLETE

CS, MM: CM SERVICE REQUEST

MM:RRC AUTHENTICATION REQUEST

MM:AUTHENTICATION RESPONSE

RANAP:COMMON ID

RANAP:SECURITY MODE COMMAND

Early reply to CN RANAP:SECURITY MODE COMPLETE

RRC:SECURITY MODE COMMAND

RRC:SECURITY MODE COMPLETE

CC: SETUP

CC:CALL PROCEEDING

RANAP:RAB ASSIGNMENT REQUEST

NBAP:RL RECONFIGURATION PREPARE

NBAP:RL RECONFIGURATION PREPARE READY

RRC:RADIO BEARER SETUP

RANAP:RAB ASSIGNMENT RESPONSE

Early reply to CN
NBAP:RL RECONFIGURATION COMMIT

RRC:RADIO BEARER SETUP COMPLETE

NAS Messages sent to UE only after

RRC:RADIO BEARER SETUP COMPLETE
received from UE CC:PROGRESS

CC:ALERTING

CC:CONNECT

CC:CONNECT ACKNOWLEDGEMENT

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 397(447)
Basic Call
 Functionality description

Figure [Link]-1: Accelerated Voice Setup Signalling for Subscriber

A

- Accelerated security mode command procedure (early response to CN)

- Accelerated RAB setup procedure (early response to CN)

- buffering of NAS messages (CC:PROGRESS, CC:ALERTING,

CC:CONNECT) until RRC:RADIO BEARER SETUP COMPLETE is
received from UE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 398(447)
Basic Call
 Functionality description

CS Call Establishment Subscriber B

NODE: TITLE: Rel.:
(Accelerated)
UE
BTS RNC CN
subscriber B
RANAP:PAGING

RRC:PAGING TYPE1

RRC:RRC CONNECTION REQUEST

NBAP:RADIO LINK SETUP REQUEST

NBAP:RADIO LINK SETUP RESPONSE

RRC:RRC CONNECTION SETUP

NBAP:RADIO LINK RESTORE INDICATION

CS, RRM:PAGING RESPONSE

RRC:RRC CONNECTION SETUP COMPLETE

RANAP:COMMON ID

MM:RRC AUTHENTICATION REQUEST

MM:AUTHENTICATION RESPONSE

RANAP:SECURITY MODE COMMAND

RRC:SECURITY MODE COMMAND

RANAP:SECURITY MODE COMPLETE

Early reply to CN
RRC:SECURITY MODE COMPLETE

CC:SETUP
Not sent before security mode complete from UE
CC:SETUP (RNC adds Signal IE)

CC:CALL CONFIRMED

ALERTING UE Sends early due Signal IE

RANAP:RAB ASSIGNMENT REQUEST

NBAP:RL RECONFIGURATION PREPARE

NBAP:RL RECONFIGURATION PREPARE READY

Early reply to CN RANAP:RAB ASSIGNMENT RESPONSE

ALERTING to CN after RAB ALERTING
assignment response
RRC:RADIO BEARER SETUP

NBAP:RL RECONFIGURATION COMMIT

RRC:RADIO BEARER SETUP COMPLETE

CC:CONNECT

CC:CONNECT ACKNOWLEDGEMENT

Figure [Link]-2: Accelerated Voice Setup Signalling for Subscriber

B

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 399(447)
Basic Call
 Functionality description

- Accelerated security mode command procedure (early response to CN)

- Accelerated RAB setup procedure (early response to CN)

<PR CAS-173140-Y7T4/Begin>

- Buffering the sending of CC:CONNECT message to CN, until

RRC:RADIO BEARER SETUP COMPLETE is received from UE
(Subscriber B)

note: This ensures that the CONNECT ACKNOWLEDGE cannot arrive to mobile
terminating UE before the RB SETUP procedure is complete, and also the mobile
originating UE receives the CONNECT message only after the call setup is
sucessfull for the call terminating UE.

<PR CAS-173140-Y7T4/End>

- MTC Late Assignment procedure (RNC adds SIGNAL IE into

CC:SETUP message and buffers sending of ALERTING and CONNECT
to CN after RAB ASSIGNMENT RESPONSE)

[Link] Accelerated Voice Setup Functionality Control

Even though RAN3376 Accelerated Voice Setup functionality has

triggering conditions of Cpich Ecno/RSCP for Accelerated Security Mode
Command procedure and for accelerated RAB Assignment procedure,
the default values are so low that accelerated procedures will trigger. Also
even if the measurements are not available by default the functionality is
used. RNC considers that measurement are available if CPICH RSCP or
CPICH EcNo measurements from UE are not older than 2 seconds.

RNC gets either the CPICH RSCP or CPICH EcNo values from the
incoming RRC CONNECTION REQUEST or RRC:CELL UPDATE or from
RRC:INITIAL DIRECT TRANSFER (Measured Results on RACH IE).

PRFILE parameter 002:2399 CTRL_MAINT_SPARE_03 has control to

adjust Cpich Ecno/RSCP triggering conditions.

Parameter value:

0H = (Default) Precondition of -112 dBm CPICH RSCP and -24 dB

CPICH EcNo are used when available.

Even if CPICH RSCP or CPICH EcNo are not available, the accelerated
voice setup is used (e.g. CSFB).

bit 0 = 1 other than default value or values are used (activation bit of the
parameter)

bit 1 to bit 6 = CPICH EcNo other than default value (0) (integer, scale
from 1 to 37). Minimum value is 1 (UE can report minimum 0), Minimum
1 = -24 dB, Maximum 37 = -6 dB /6/.

bit 7 to bit 13 = CPICH RSCP other than default value (0) (integer, scale
from 3 to 55). Minimum value is 3 (UE can report minimum 0), . Minimum
3 = -112 dBm, Maximum 55 = -60 dBm

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 400(447)
Basic Call
 Functionality description

bit 14 = (0) Accelerated Voice Setup is used even if RSCP or EcNo

values are not available (Default).

= (1) Accelerated Voice Setup is not used if RSCP or EcNo values are not
available

PRFILE parameter 002: 2388 CTRL_MAINT_SPARE_01 has control to

deactivate accelerated Security Mode Command procedure or
accelerated RAB Assignment procedure.

<CR#E1449/begin>

0H = accelerated Security Mode Command procedure and accelerated

RAB Assignment (including late assignment for subscriber B) procedures
are used for both subscriber A (MOC) and subscriber B (MTC) (default)

-1H, where Accelerated Security Mode Command Procedure is

deactivated for Subscriber A

-2H, where Accelerated RAB Assignment procedure is deactivated for

Subscriber A

-3H, where both accelerated procedures are deactivated for Subscriber A

-10H, where Accelerated Security Mode Command Procedure is

deactivated for Subscriber B

-20H, where Accelerated RAB Assignment procedure including late

assignment procedure is deactivated for Subscriber B

-30H, where both accelerated procedures are deactivated for Subscriber

B

When selecting deactivation for both subscribers, PRFILE parameter

value is the sum of subscriber A value and subscriber B value.

<CR#E1449/end>

<CR#E1492/begin>

With PRFILE parameter 002:2429 CTRL_MAINT_SPARE_30 the usage

of RAN3376 Accelerated Voice Setup functionality can be limited UE
release specifically. PRIFLE parameter has the following values:

0H = default value. Not any UE release specific limitation for usage of

Accelerated Voice Setup

1H= Accelerated Voice Setup is not allowed for Rel-5 and older UEs

2H= Accelerated Voice Setup is not allowed for Rel-6 UE

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 401(447)
Basic Call
 Functionality description

4H = Accelerated Voice Setup is not allowed for Rel-7 UEsFor multiple

choice, e.g. Accelerated Voice Setup is not allowed for Rel-5 UEs and
Rel6 UEs = 1H + 2H = 3H.

The PRFILE parameter 002:2429 CTRL_MAINT_SPARE_30 content is

not public. The PRFILE 002:2429 CTRL_MAINT_SPARE_30 paramter
description is communicated to specific customers only. Those are the
customers that have not been able to activate RAN3376, due to the
problems in a couple of older UE models during accelerated voice setup
scenario.

<CR#E1492/end>

[Link] Accelerated Voice Setup CN Handling

As in accelerated Security Mode Command Procedure and accelerated

RAB assignment procedure RNC sends acknowledgement to CN before
the UE acknowledgement, CN can start a new procedure before UE
configuration for RAB assignment is complete.

RAB Assignment Procedure:

If CN is sending the IU Release Command for the CS RAB, whose RAB

setup signalling is not complete yet, the UE specific RRC Entity can
acknowledgement the IU Release Command to CN before the UE
response. UE specific RRC initiates RRC Connection Release (UE has
CS CN connection only) or Signalling Connection Release (UE has CS
CN + PS CN connection) of the UE only after the UE response
(RRC:RADIO BEARER SETUP COMPLETE).

RAB Reconfiguration:

If the CN is reconfiguring the CS RAB, whose RAB setup signalling with

UE is not complete yet, the UE specific RRC Entity must wait for the UE
response first before proceeding with the UE RB reconfiguration.

RL Failure (RAN3376 Phase2: Re-establishment during CS RB Setup is

not active):

If the UE is sending the CELL UPDATE indicating RL failure, when the

RAB Setup procedure is incomplete, the UE specific RRC Entity releases
the UE's RRC Connection (ÚE has CS CN connection only). If the UE has
also PS connection, the UE specific RRC Entity must initiate RRC
Connection re-establishment.

Location Reporting:

If CN is sending the LOCATION REPORTING CONTROL message for

the CS RAB, whose UE signaling is not complete yet, the UE specific
RRC Entity waits for the UE response before sending the response to the

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 402(447)
Basic Call
 Functionality description

CN (If the LOCATION REPORTING CONTROL procedure requires

sending of acknowledgement to CN).

IU Release after Registration:

If UE is making registration to CS CN, RNC sends the UE's

MM:LOCATION UPDATE REQUEST to CN. CN normally requests
Security Command Mode procedure after that. With Accelerated Setup
RNC is sending the immediate acknowledgement for RANAP:SECURITY
MODE COMMAND procedure. CN may send RANAP:IU RELEASE
COMMAND to RNC, before RNC received RRC: SECURITY MODE
COMMAND COMPLETE from UE. Even after receiving the RANAP:IU
RELEASE message, RNC updates the counter for successful or
unsuccessful security mode command procedure.

[Link] Accelerated Voice Setup Error Handling

In accelerated Security Mode Command Procedure and accelerated RAB

assignment procedure RNC sends acknowledgement to CN before the
UE acknowledgement. If

- Security Mode Command Procedure with UE fails

- Radio Bearer Setup procedure fails with BTS or UE or

because of internal RNC failure

RNC sends the RANAP:IU RELEASE REQUEST message with cause:

"Failure in Radio Interface Procedure" to CN.

[Link] Accelerated Voice Setup Feature Interworking with other Features

RAN2172: Multi-Band Load Balancing

-Accelerated RAB Assignment procedure in the RAN3376 feature is not

used of the Multi-Band Load Balancing (MBLB) layer change is done with
a single UE procedure

<RAN3376/end>

<RAN3293/begin>

2.3.56 RAN3293 KPI Boost trough Refined RRM

The RAN3293 KPI Boost through Refined RRM is a general feature

(BSW) in the RNC. The RAN3293 KPI Boost through Refined RRM
feature improves the call retainability by decreasing the number of Radio
Bearer Reconfiguration procedures.

The feature is enabled in the RNC when the 1st bit (Bit0) of the PRFILE
parameter 002:2155 RU40_MAINT_59 is set to value 1.

Subfunctionalites are controlled with RNFC parameter

RRMEnhancementsEnabled.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 403(447)
Basic Call
 Functionality description

One subfunctionality is ignoring UL/DL capacity requests during AMR call

setup.

[Link] UE specific RRC ignores UL/DL capacity requests during AMR call setup

When the 12th bit of the RNFC parameter RRMEnhancementsEnabled is set to

value 1, the UE specific RRC shall ignore all UL/DL capacity requests if the 8
second timer is running. The conditions of starting the timer are following:

• RNC receives an RRC: CELL UPDATE message or an RRC: INITIAL

DIRECT TRANSFER message from the UE with the establishment cause
'Emergency Call', ‘Originating Conversational Call’ or ‘Terminating
Conversational Call’.
• If the Establishment cause IE is not included in the RRC: CELL UPDATE
message which was sent as a response to the RRC: PAGING TYPE 1
(PCH) message or the IE is not included in the RRC: INITIAL DIRECT
TRANSFER message which was sent as a response to the RRC: PAGING
TYPE 2 (FACH) message but the stored Paging cause IE (if included)
from the RANAP: PAGING message is ‘Terminating Conversational Call’

The UE specific RRC starts handling the UL/DL capacity requests after the 8
seconds timer expires or after the AMR call setup is completed. That is, after the
RRC: RADIO BEARER SETUP COMPLETE message is received from the UE or the
RANAP: IU RELEASE COMMAND message is received from the CS CN.

[Link] Optimization of Activation time offset according to radio signal quality

UE specific RRM uses optimized Activation time offset according to radio

signal quality if the functionality of the feature RAN32393 KPI boost
through Refined RRM has been activated with the 13th bit of the RNFC
parameter RRMEnhancementsEnabled.

UE specific RRM uses parameter MinOptimizedATOffset to set the ATO if

the radio signal level and quality conditions are are over the tresholds.

UE specific RRM uses parameter MaxOptimizedATOffset to set the ATO if

the radio signal level is below the treshold.

For details of setting legacy/optimized ATO, see Handover Control FD,

Admission Control FD and the functionality FP provides CFN when
requested by PS described in the Packet Scheduler FD.

<RAN3293/end>

<RAN3401/begin>

2.3.57 RAN3401 Flexible QoS Differentiation

The RAN3401 Flexible QoS Differentiation feature provides the flexibility

to operators to use the complete range of Allocation and Retention
Priority (ARP). In addition separate QoS mapping for each operator (Iu) is
possible in RAN sharing arrangement, providing operator the flexibility to
define independent QoS differentiation.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 404(447)
Basic Call
 Functionality description

This feature extends support for the full range of ARP (Allocation and
Retention Priority), 0-15. The legacy QoS functionalities allows priority
configuration for ARP values of 1...3, values 4...15 are treated as value 3.

This feature supports THP (Traffic Handling Priority) range as the legacy,
1...3, while the 3GPP specs allow range of 1...15. Values 4...15 are
treated as value 3 with this feature.

For more information about the RAN3401, see HSDPA RRM in RNC,
HSUPA RRM in RNC and Packet Scheduler FDs.

[Link] Feature control

The RAN3401 Flexible QoS Differentiation feature is an optional feature

(ASW) and it is controlled by the RNC long term ON/OFF license key
'Flexible QoS Differentiation LK'.

The RAN3401 Flexible QoS Differentiation feature IS enabled in the RNC

when the following conditions are true:

• The RNC license key 'Flexible QoS Differentiation LK' is installed

in the RNC and the state of the license key is 'On'. License check
is valid for cRNC and mcRNC.

• Any of the parameters IUO - FlexibleQoSPriority - QoSIntTHP1,

QoSIntTHP2, QoSIntTHP3, QoSBackgr is configured into range of
[0 0 0 ...0] to [B B B...B]

[Link] UE spesific RRC reads the FlexibleQoSPriority from the selected IUO
object

In the shared RAN configuration (MOCN or MORAN), the RNC selects

the Iu operator (IUO object) in legacy manner. If RAN3401 is enabled, the
UE specific RRC reads FlexibleQoSPriority for QoS Priority mapping from
selected IUO object.

If RAN3401 is enabled but shared RAN has not been configured, the
FlexibleQoSPriority is read from the only available IUO object.

[Link] UE specific RRC defines priorities used by QoS prioritization according

to RAB parameters received from RANAP/RNSAP and operator configurable RNP
parameters

If RAN3401 is enabled, UE specific RRC defines QoS Priority at RAB

establishment, RAB reconfiguration, UP creation and SRNC relocation for
NRT services according to RAB parameters received from
RANAP/RNSAP and parameters of IUO-FlexibleQoSPriority and RNPS-
QoSPriorityMapping.

QoS Priority is signaled to BTS and L2.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 405(447)
Basic Call
 Functionality description

[Link].1 Branch addition over Iur

SRNC sets the priorities to RNSAP messages in legacy manner when

adding branch over Iur.
HSPA QoS prioritisation over Iur-interface is activated with PRFILE
parameter 002:1764 RN50_MAINT_47 (1st bit set to value '1'). If the
functionality has been activated and RAN3401 has been enabled in
SRNC, SPI value defined for Interactive and Background Traffic Class
(TC) with parameter IUO-FlexibleQoSPriority is used for NRT HS-DSCH
and E-DCH Mac-d flows over Iur.

DRNC uses the over Iur received priorities in legacy manner ( e.g. QoS
Priority mapping, THP mapping and SPI checking). In case of DCH over
Iur, SPI is not available over Iur in DRNC and DRNC uses legacy
mapping. Also THP is not supported in RNSAP. Even if RAN3401 is
enabled in target RNC, the legacy parameter RNPS-
QoSPriorityMapping is used for QoS Priority mapping.

See the legacy handling in HSDPA RRM FD.

[Link].2 Relocation

The target RNC defines QoS Priority in legacy manner according to RAB
parameters received in RANAP:RELOCATION REQUEST but with
parameter IUO-FlexibleQoSPriority used for Interactive and Background
traffic class NRT RABs instead of QoSPriorityMapping parameter if
RAN3401 is enabled in target RNC

<RAN3401/end>

2.4 Optional functionality

<Internal/begin>
<RAN3220/begin>

2.5 Frozen features

The following features are frozen. No new implementation is made for those
features and they are not needed to be taken into account when considering
feature interworking issues.
• RAN1004 Streaming QoS for HSPA
• RAN1689 CS Voice Over HSPA

<RAN3220/end>
<Internal/end>

2.6 Workarounds for not fully 3GPP compliant UEs and CNs
2.6.1 UE issues

Voice quality problems with Apple iPhone 3G/3Gs

002:1691 RN50_MAINT_16: Voice quality problems with Apple iPhone

3G/3Gs

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 406(447)
Basic Call
 Functionality description

Description:

iPhone cannot handle frequency-layer change during CS RAB setup from

Cell_FACH.

iPhone cannot handle CS Voice on DCH setup with transparent mode

RLC configuration, provided that the procedure is done with a state
transition from Cell_FACH to Cell_DCH and the procedure causes the UE
to be redirected to another frequency layer due to DRRC, MBLB or Blind
IFHO functionality. In the above case, iPhone applies the ciphering
configuration for TM RLC incorrectly.

In order to prevent voice quality problems with Apple iPhone 3G/3Gs, a

workaround is implemented in RNC SW which can be controlled by the
PRFILE parameter RN50_MAINT_16.

Possible workarounds are:

a) The PRFILE parameter RN50_MAINT_16 can be used to disable the

DRRC feature from CCH-to-DCH state transitions. By default the DRRC
functionality is not changed but, if separately disabled, a cell change is
not done for AMR calls during CCH-to-DCH state transition.

It should be noted that when the DRRC feature is disabled from CCH-to-
DCH state transitions, it can affect KPIs when a R99 high load is not
anymore triggering a layer change.

This workaround is available in RU20, RU30 and RU40.

b) If the AMR setup requires the UE to be redirected to another layer due

to DRRC or MBLB during state transition from CELL_FACH to Cell_DCH,
then NW will send an RRC message which will help Rel5 Ues to
differentiate a state transition procedure from Inter-frequency HHO
procedure. The UE can then perform ciphering correctly. This workaround
can be activated with the same PRFILE parameter RN50_MAINT_16 than
RU20 workaround (a)).

This workaround is available from RU30 onwards.

In RU30&RU40 and later releases it is recommended to disable the RU20

workaround (a)) and enable the RU30 workaround (b)).

Default value

The default value of this parameter is 0H, i.e. workarounds are not
activated.

Note also feature RAN2970: Improvement to CS Call Setup Attempts

Starting from Cell_FACH / Cell_PCH. With this feature UE is moved to
Cell_DCH state before RAB setup signaling and UE problem is not
visible.

Activation and deactivation, see RNC TN-149.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 407(447)
Basic Call
 Functionality description

Call setup failures due to iPhone 3GS has problem in handling

lossless PDU size change

Description:

When the PDU size is changed (e.g. from 336 to 656) the iPhone 3GS
has a problem in handling the Radio Bearer Setup or Radio Bearer
Reconfiguration procedure with lossless PDU size change, even though it
indicates the support of lossless PDU size change in the RRC Connection
Setup Complete message.

A PRFILE-controlled workaround has been made in the RNC not to

configure lossless PDU size change to such UE even when the UE
indicates it supports lossless PDU size change. RNC identifies
problematic UEs from UE Capability bits.

The default value of this parameter is 0H, i.e. the workaround is activated.

Note: The default value should not be changed!

Activation and deactivation, see RNC TN-149.

SRB RLC parameter handling in RRC Connection Setup phase (Rel-5

UE)

RRC_CONN_ACC_FAIL_RADIO with some unidentified Release 5 or

older Ues

Description:

By default RNC sends an optimized RRC Connection Setup message

including RLC information for SRB3 configured using same as RB2
option, and also does not send RB ID in the SRB Information Setup list
because it is optional in 3GPP 25.331. Also, the RNC uses shorter timer
for waiting RRC Connection Setup Complete procedure but it can’t be
handled correctly by some unidentified Rel5 or older Ues.

Note: RB-id’s for SRBs are MD (mandatory default) in 25.331 (RRC

specification). By default RB-id of SRB1 is “1”, RB-id of SRB2 is “2”, RB-id
of SRB3 is “3” and RB-id of SRB4 is “4”.

Note, 25.331 says: The UTRAN should only use the default value of the
IE "RB identity" within the RRC Connection Setup and Handover to
UTRAN Command messages.

The PRFILE-controlled workaround is implemented in the RNC to send

explicit RLC information for SRB3 if the UE is Rel5 or older, and also to
include the RB ID for each SRB being set up during the procedure.

Default value

The default value of this parameter is 0H, i.e. the workaround is not
activated.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 408(447)
Basic Call
 Functionality description

Note: The default value should not be changed! (From specialist: “We
probably never need to activate that. We did not have enough evidence
that it is really causing problem”.)

Activation and deactivation, see RNC TN-149.

RRC Connection Request with the protocol error indicator

002:1687 RN50_MAINT_14: RRC_CONN_ACC_FAIL_RADIO

(M1001C9) increased after RU20 with Apple iPhone 3G/3Gs/4

Description:

Sometimes a UE retransmits an RRCConnectionRequest very fast with a

protocol error indication, even before the UE has received the original
RRCConnectionSetup. This will cause the UE and RNC to go out of
synch, resulting in call setup failures which can be seen as an increase of
the counter M1001C9 (RRC_CONN_ACC_FAIL_RADIO).

Apple has been informed about this problem.

A PRFILE-controlled workaround for this UE problem is implemented in

the RNC. The RNC does not start to process the retransmitted
RRCConnectionRequest with protocol error indication immediately, but
waits for RRCConnectionComplete for a time specified by this PRFILE
parameter. If RRCConnectionSetupComplete is received during the
waiting time, then the RRCConnectionRequest with protocol error
indication is not processed.

Default value

The default / recommended value of the parameter is 0H i.e. the

workaround is active so the RNC uses a waiting time of one second
before the retransmitted RRCConnectionRequest with protocol error
indication is processed.

The waiting time can be configured from 200 ms to 1500 ms by using the
PRFILE parameter values 2H-FH. The waiting time formula is: value*100
ms.

See also chapter “Faulty protocol error handling during RRC Connection
setup procedure” (same case….this to be removed).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 409(447)
Basic Call
 Functionality description

Activation and deactivation, see RNC TN-149.

CS call setup failure with invalid configuration in loop which UE

does not recover

Description:

If a Qualcomm based UE detects a RL failure during the CS call setup

from Cell_FACH, it might hang in a loop, would not recover and the call
setup will not succeed.

If during CS call setup from Cell_FACH, RNC does not receive Radio
Bearer Setup Complete from UE but later UE makes Cell update due to
Radio Link failure then after RRC Connection re-establishment procedure,
all newer CS call attempts keep on failing.

UE keeps rejecting the new attempts with cause invalid configuration.

An improvement is made in RNC to recover UE in such scenario by

providing explicit new configuration when re-establishment will be
triggered after failed CS Call Setup attempt. Also a workaround to release
the hanging user in case UE keeps rejecting the CS call setup attempt is
implemented (the whole RRC Connection is released if providing te
explicit new configuration does not recover situation).

Special Conditions for Installation:

There are no special conditions for installation: a workaround is activated

by default without PRFILE controllable parameter.

Note also feature RAN2970: Improvement to CS Call Setup Attempts

Starting from Cell_FACH / Cell_PCH. With this feature UE is moved to
Cell_DCH state before RAB setup signaling and UE problem is not
visible.

AMR drops during the codec set modification

Due to UE problem, AMR drops during the codec set modification with the
cause configuration un-supported

Description:

Some Ues incorrectly reject AMR RAB reconfiguration if SF2 and SF3
DCHs and DL information per RL list are not sent in RBR even though
there are no changes in these Ies.

This happens when TrFO/TFO and multi-mode AMR are enabled. End
user experiences this fault as AMR drops. Operator sees these AMR
drops occur during the codec set modification with the cause
configuration un-supported.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 410(447)
Basic Call
 Functionality description

As a RNC workaround for UE fault these Ies are always sent in case of
AMR RAB reconfiguration even though they do not change.

Special Conditions for Installation:

There are no special conditions for installation: a workaround is activated

by default without PRFILE controllable parameter.

UE resets during ongoing data transfer after CPC activation

Description:

Some Nokia UE models restart during ongoing data transfer if CPC is

activated. A PRFILE controllable workaround is needed in RNC to disable
CPC for these users.

RNC identifies problematic UEs from UE capability bits.

Default value

The default value of this parameter is 0H i.e. workaround is disabled.

Activation and deactivation, see RNC TN-149.

F-DPCH does not work with some rel7 UEs

Description:

There has been few problems in the networks when F-DPCH is activated:
1. UE indicates supports for F-DPCH in the RRC CONNECTION
REQUEST message, but rejects when F-DPCH is given in RRC
CONNECTION SETUP message. Retry of RRC CONNECTION SETUP
message without F-DPCH works, but it increases the setup time.
2. UE rejects F-DPCH allocation whenever attempted with RAB Setup
(DRA), UP setup, channel type switches etc. Although RNC has
workaround not to configure F-DPCH to such device again, it relies still on
the fact that one attempt has to fail and Packet call KPIs indicate access
failure.
3. During PS release/inactivity when RNC reconfigures SRB only to
HSPA with ST, UE rejects the procedure.
4. UE rejects CS setup with SRB switched from HSPA to DCH, while PS
is kept on HSPA.

Workaround:

The workaround is that if PRFILE is enabled then rel7 UE does not get F-
DPCH at any phase (RRC Connection Setup, state transition to
Cell_DCH, HSPA allocation in Cell_DCH during UP setup or channel type
switches). The workaround can be enabled by setting the 5th bit (bit 4) of
PRFILE 002:2140 RU40_MAINT_44 to 1 (0x0010).

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 411(447)
Basic Call
 Functionality description

Device issues when CM for LTE measurements are activated and

network starts reconfiguration procedures during ongoing LTE CM

Description:

When LTE CM measurements are activated for UE and network starts

reconfiguration procedures during ongoing LTE CM measurements,
release 8 UEs cannot correctly handle reconfiguration procedures during
ongoing LTE CM measurements. They either crashes or loses radio
connection. There are 4 different problem cases and workarounds
described under “Compressed mode configuration” chapter in
“Measurement based LTE layering” feature.

Workarounds are controlled by PRFILE parameter 002:2134

RU40_MAINT_38.

Activation and deactivation, see RNC TN-149.

<CRE1391/beging>

Workaround to avoid HSPA setup failure for bad behaving UE

If the UE indicates the MAC-ehs support by including MAC-ehs support IE

in the UE radio access capability IE but does not sent the HS-DSCH
physical layer category extension IE, it works in 3GPP non-compliant
manner. This situation causes MAC-ehs allocation to fail at the BTS. In
this case the UE specific RRM (UER) prevents the MAC-ehs allocation
and uses HS-DSCH physical layer category IE for HS-DSCH allocation
decision. MAC-hs is used instead of MAC-ehs.

The workaround is controlled by PRFILE parameter 002:2147

RU40_MAINT_51. By default (with default value 0H), functionality is not
used. The functionality is activated by setting PRFILE parameter to 0x01.

<CRE1391/end>

<CRE1393/beging>

Workaround for UEs which don't send START value after CS call re-
establishment
WCDMA16:
When the CS call re-establishment procedure has been started and the
UE responds to RRC:CELL UPDATE CONFIRM message with
RRC:TRAFFIC CHANNEL/PHYSICAL CHANNEL/RADIO BEARER
RECONFIGURATION COMPLETE message, the UE specific RRC
checks whether:
• Ciphering has been started for the call and
• Did the UE include in response message “COUNT-C activation
time” IE and “START” IE for CS domain
If the ciphering has been started but ciphering parameters for CS domain
were not received from the UE, the UE specific RRC releases the CS call.
In case:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 412(447)
Basic Call
 Functionality description

• UE has only CS RAB: The call is released with release cause

‘unspecified’ used in the RRC:RRC CONNECTION RELEASE and
Miscellaneous Cause ' Unspecified Failure(115) ' in RANAP: IU
RELASE REQUEST
• UE has CS and PS RABs: The Iu CS connection is released (Iu
Cause Unspecified Failure(115) '). CS RB and signalling
connection is released using RRC: RADIO BEARER RELEASE
message in legacy manner. UE is moved to Cell_FACH state.
If CS call is released, the counter M1001C399 SERVICE LEVEL SPARE
1 is updated. For WCDMA17 M1001C399 is swapped for a new counter
M1001C837 REL_CS_CALL_DUE_TO_UE.

WCDMA17:
In addition to WCDMA16 functionality, RAN3228 CS Call Re-
establishment over Iur interworking is provided (see /20/).
If CS call re-establishment over Iur with relocation functionality is
triggered, the target RNC detects the presence of ciphering parameters in
UE’s response to RRC:CELL UPDATE CONFIRM message and acts as
specified above.
If CS call re-establishment over Iur in anchoring functionality is triggered,
the SRNC detects the presence of ciphering parameters in UE’s response
to RRC:CELL UPDATE CONFIRM message. If the ciphering has been
started but ciphering parameters for CS domain were not received from
the UE, the UE specific RRC releases the call both in CS only RAB and
CS + PS multi RAB cases. RRC connection is released over Iur with
release cause ‘unspecified’ and Iu connection(s) with RANAP cause
Miscellaneous Cause ' Unspecified Failure(115).
In both cases the new counter M1001C837 REL_CS_CALL_DUE_TO_UE
is updated.

<CRE1393/end>

<CRE1507/begin

Some incorrectly behaving UEs provide contradictory radio access

capability information. The fault appears e.g. in the following scenario:

UE does ISHO from LTE to 3G and announces that it has E-DCH

capability. UE is allocated HSPA resources. At the end of the ISHO, RNC
enquires 3G capabilities again and UE now saying it doesn’t support E-
DCH. This causes problems with statistics as the wrong Packet Call
attempt counter (HS-DSCH/DCH attempt) is incremented and no
increment to the successful allocation counter (HS-DSCH/E-DCH
allocation).

The workaround is that the UE specific RRC identifies that contradictory

UE capabilities has been provided and sends Packet Call release ticket
with correct information.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 413(447)
Basic Call
 Functionality description

The UE specific RRC sets the “out_request” (HSDPA/HSUPA) in Packet

Call ticket based on UE’s announced radio access capabilities in legacy
way, but if UE specific RRC has received incorrect UE radio access
capability information from UE and “out_request” indicates HSDPA but
“out_result” HSPA, the UE specific RRC changes the “out_request” to
value HSPA.

<CRE1507/end>

2.6.2 CN issues

SGSN does not support MBR negotiation

002:1670 RN50_MAINT_07: Release 5/6 Qualcomm based UEs are

unable to make PS calls when a Release 7 QoS is provisioned to the
subscriber with certain SGSN (e.g. Starent SGSN)

Description:

It was observed that Qualcomm based Rel5/6 UE are not be able to make
PS calls when

• The subscriber has a QoS with a maximum DL bit rate higher than
16Mbps provisioned in the HLR and

• The PS core network (SGSN and GGSN) are Release 7 and the
SGSN do not support the optional IE “Maximum Alternative Bit
Rate” in the RANAP RAB ASSIGNMENT REQUEST.

The root cause of the issue lies in some unclarity in the 3GPP
specification and some limitations observed in certain SGSN.

Upon receiving a successful PDP CONTEXT ACCEPT with the maximum

downlink bit rate higher than 16Mbps, the UE may request a deactivation
of the PDP context with the cause “QoS not supported”.

A Rel6 UE can support maximum downlink up to 16Mbps. So even if the

SGSN sends a maximum downlink bit rate higher than 16Mbps in the
QoS, a Rel5/6 UE in reality cannot support data rates higher than 16Mbps
in downlink.

The issue is initially resolved and active by default in RU20 SW. For this
default solution to work, the SGSN shall support the optional IE
“Maximum Alternative Bit Rate” in the RANAP RAB ASSIGNMENT
REQUEST.

However, it was observed that some SGSN do not support this optional
IE. Without the support of this IE it is impossible for the RNC to allocate
an alternative maximum bit rate during the RAB Assignment procedure
and that would lead to an unsuccessful PS call despite the active solution
by default in RNC.

It was observed, for example, that Starent SGSN did not support the
Alternative Maximum Bit Rate IE, thus preventing the RNC from adjusting
the downlink bit rate to a value that will be acceptable for the UE.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 414(447)
Basic Call
 Functionality description

Both Starent and Qualcomm have been informed about this issue.

To circumvent this SGSN limitation, a workaround is implemented in the

RNC. It will check the QoS in the L3_ACTIVATE_PDP_CONTEXT from a
Rel5/6 UE and if the maximum downlink bit rate is set to “subscribed”, the
RNC will then set it to 16Mbps (to the L3_ACTIVATE_PDP CONTEXT
NAS message) as it is the maximum downlink rate the UE can support.
This will then help the SGSN to set the maximum downlink bit rate to
16Mbps in the RAB_ASSIGNMENT REQUEST, resulting in a successful
PDP context activation.

Default value

The default value of the parameter is 0H i.e. the workaround is not

activated.

Activation and deactivation, see RNC TN-149.

Video Call is not working with Nortel MGW

002:1892 RN60_MAINT_16: Video Call is not working with Nortel MGW

Description:

This change is RNC workaround for Core Network functionality. Nortel CN

requires transport layer address to be sent in different format that RNC
currently does. Problem is seen only with Nortel, other CN vendors
support both formats. This is not regarded as a RNC problem but
workaround to support Nortel CN requirements.

Nortel CN requires 20 bytes length transport layer address when Video

Call is setup and RNC sends RAB Assignment Response message to the
Core Network.

A RNC workaround has been implemented which will make RNC to send
Transport Layer Address in the RAB Assignment Response of length 20
bytes during Video Call setup.

Since change impacts to CN signalling, workaround can be separately

activated when needed.

Default value

The default value of the parameter is 0H i.e. the workaround is not

activated.

Activation and deactivation, see RNC TN-149.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 415(447)
Basic Call
 Functionality description

2.7 Management parameters

2.7.1 RAN930 PS RAB reconfiguration Support

DESCRIPTION:

This parameter defines if the BTS can support the PS RAB

reconfiguration. Note that, this parameter needs to be checked by RNC
only in the case of HSPA connections, since BTS does HSPA scheduling
and this parameter need not be checked in the case of DCH/DCH,
RACH/FACH configurations.

DCH/HS-DSCH configuration: In this case, only support from Serving

BTS which controls serving cell should be checked.

E-DCH/HS-DSCH configuration: In this case, support from all the BTSs

which are involved in E-DCH active set should be checked.

Object Class: WBTS

Abbreviated Name: NodeBRABReconfigSupport
Parameter Name: NodeB PS RAB reconfiguration Support
Data Type: Enumeration
Range and Step: 0(Disabled),1(Enabled)
Default Value: 0
Default value notes: NodeB support for PS RAB reconfiguration is
disabled.
Modification: On-line
Related features: PS NRT RAB reconfiguration (Optional)

2.7.2 RAN285 HSPA Multi RABs parameters

Description:
Cell-specific parameter that defines whether RAN 285 features 'Multi NRT
RABs' is supported in this cell or not. The number of BTSs that support
feature RAN 285 is limited by ASW capacity license.
Short Description: Defines support of RAN 285 feature 'Multi NRT RABs'
in this cell.

Object: WCEL
Abbreviated Name: HspaMultiNrtRabSupport
Parameter Name: HSPA multi NRT RAB Support
Data Type: Enumeration
Hidden: No
Parameters included in this structure: -
Multiplicity: 1
Parameter group: PSConfiguration
Classification: Radio Resource Utilization
Range and Step: 0 - not supported, 1 - supported
Default Value: 0
Required on creation: Optional
Modification: Online
Related features: HSDPA (optional) AND HSPA Multi NRT RABs
(optional) OR HSDPA (optional) AND HSDPA Dynamic Resource

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 416(447)
Basic Call
 Functionality description

Allocation (optional) AND HSUPA (optional) AND HSPA Multi NRT RABs
(optional)
2.7.3 RAN1797 SRB mapping in RRC setup based on Establishment Cause

Abbreviated name: SRBMapRRCSetupEC

Description:
This parameter defines the Establishment Cause (EC) values which prefer
SRB mapping to the common channels (CCH) in the RRC connection
setup. Establishment Cause is RRC information element which is received
from the UE in the RRC message RRC Connection Request. The value 0
means that certain Establishment Cause prefers SRB mapping to the
dedicated channel (DCH) or to the high speed packet access (HSPA i.e.
on HS-DSCH/E-DCH) in the RRC connection setup. The value 1 means
that certain Establishment Cause prefers SRB mapping to the common
channels in the RRC connection setup. Bit 9: Emergency call does not
effect, SRBs of emergency call are always mapped to DCH in the RRC
connection setup.
<CRE1298/begin>
By default dedicated channels are used always when LTE band
capabilities need to be requested from a UE and SRBs cannot be mapped
to HS-RACH. In those cases this parameter is ignored. LTE band
capabilities are needed if LTE layering features are in use.
<CRE1298/end>
The parameter SRBBitRateRRCSetupEC defines preferred bit rate for the
SRB DCH if DCH is selected to be preferred instead of CCH in the RRC
connection setup.
The parameter FDPCHSetup defines allocation procedure of the F-DPCH
in the RRC connection setup.

Multiplicity: 1 (scalar parameter)

Related functions: Admission Control
Parameter group: ACConfiguration
Classification: Radio Resource Utilisation
Range and step:
Bit 0: Originating conversational call,
Bit 1: Originating streaming call,
Bit 2: Originating interactive call,
Bit 3: Originating background call,
Bit 4: Originating subscribed traffic call,
Bit 5: Terminating conversational call,
Bit 6: Terminating streaming call,
Bit 7: Terminating interactive call,
Bit 8: Terminating background call,
Bit 9: Emergency call, 'always constant value 0'
Bit 10: Inter-RAT cell re-selection,
Bit 11: Inter-RAT cell change order,
Bit 12: Registration,
Bit 13: Detach,
Bit 14: Originating high priority signalling,
Bit 15: Originating low priority signalling,
Bit 16: Call re-establishment,
Bit 17: Terminating high priority signalling,
Bit 18: Terminating low priority signalling,
Bit 19: Terminating cause unknown,

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 417(447)
Basic Call
 Functionality description

Bit 20: MBMS reception,

Bit 21: MBMS ptp RB request
Default value: 454656
Default value notes: 0001101111000000000000b
Required on creation: Optional
Modification: On-line
Related features: Call setup and channel activation time improvements
(standard)
Process/calculation: -
References: NSN reference: RAN1797 Signaling Performance
Improvements EFS
RNC stored:RNW Database
Interfaces: RAC <->RNC, EM <-> RNC, RACApp <-> RAC

2.7.4 RAN1797 SRB DCH bit rate in RRC setup based on Establishment Cause

Abbreviated name: SRBBitRateRRCSetupEC

Description:
This parameter defines the Establishment Cause (EC) values which prefer
faster dedicated channel (DCH) for SRBs in the RRC connection setup.
Establishment Cause is RRC information element which is received from
the UE in the RRC message RRC Connection Request. The value 0
means that certain Establishment Cause prefers 3.4 kbps dedicated
channel for SRBs in the RRC connection setup. The value 1 means that
certain Establishment Cause prefers 13.6 kbps dedicated channel for
SRBs in the RRC connection setup. If 13.6 kbps DCH is preferred one for
SRBs in the RRC connection setup but setup of it faces congestion, setup
is retried immediately with 3.4 kbps DCH.
<CRE1298/begin>
By default 13.6 kbps SRB DCH is used always if LTE band capabilities
need to be requested from a UE. In those cases this parameter is ignored.
LTE band capabilities are needed if LTE layering features are in use.
<CRE1298/end>
The parameter SRBMapRRCSetupEC defines preferred channel type in
the RRC connection setup, either common or dedicated channel.
The parameter FDPCHSetup defines allocation procedure of the F-DPCH
in the RRC connection setup.

Object: WCEL
Multiplicity: 1 (scalar parameter)
Related functions: Admission Control
Parameter group: ACConfiguration
Classification: Radio Resource Utilisation
Range and step:
Bit 0: Originating conversational call,
Bit 1: Originating streaming call,
Bit 2: Originating interactive call,
Bit 3: Originating background call,
Bit 4: Originating subscribed traffic call,
Bit 5: Terminating conversational call,
Bit 6: Terminating streaming call,
Bit 7: Terminating interactive call,
Bit 8: Terminating background call,
Bit 9: Emergency call,

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 418(447)
Basic Call
 Functionality description

Bit 10: Inter-RAT cell re-selection,

Bit 11: Inter-RAT cell change order,
Bit 12: Registration,
Bit 13: Detach,
Bit 14: Originating high priority signalling,
Bit 15: Originating low priority signalling,
Bit 16: Call re-establishment,
Bit 17: Terminating high priority signalling,
Bit 18: Terminating low priority signalling,
Bit 19: Terminating cause unknown
Bit 20: MBMS reception,
Bit 21: MBMS ptp RB request
Default value: 69631
Default value notes: 0000010000111111111111b
Required on creation: Optional
Modification: On-line
Related features: Call setup and channel activation time improvements
(standard)
References: NSN reference: RAN1797 Signaling Performance
Improvements EFS
RNC stored:RNW Database
Interfaces: RAC <->RNC, EM <-> RNC, RACApp <-> RAC

2.7.5 RAN1797 RRC setup on CCH enabled for R99 UE

Abbreviated name: RRCSetupCCHEnabledR99

Description:
This parameter defines whether RRC connection setup for R99 UEs is
allowed to be performed on common channels (CCH). If value of this
parameter is disabled, RRC connection setup is performed on dedicated
channel (DCH) despite of the value of the Establishment Cause
information element in the RRC message RRC Connection Request. If
value of this parameter is enabled and the value of the Establishment
Cause information element is interpreted so (parameter
SRBMapRRCSetupEC), RRC connection setup can be performed on
common channels.
The parameter SRBMapRRCSetupEC defines preferred channel type in
the RRC connection setup, either common or dedicated channel.
Object: RNC
Multiplicity: 1 (scalar parameter)
Related functions: Admission Control
Parameter group: ACConfiguration
Classification: Radio Resource Utilisation
Range and step: 0 (Disabled), 1 (Enabled)
Default value: 0
Default value notes: As a default SRBs of R99 UEs are mapped on DCH
in the RRC connection setup.
Required on creation: Optional
Modification: On-line
Related features: Call setup and channel activation time improvements
(standard)
References: NSN reference: RAN1797 Signaling Performance
Improvements EFS
RNC stored:RNW Database

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 419(447)
Basic Call
 Functionality description

Interfaces: RAC <->RNC, EM <-> RNC, RACApp <-> RAC

2.7.6 RAN1797 CPICH Ec/No thr for SRB mapping in RRC setup

Abbreviated name: CPICHEcNoSRBMapRRC

Description:
This parameter defines threshold for CPICH Ec/No to determine whether
RRC connection setup is allowed to perform on common channels (CCH).
RRC connection setup on common channels is not possible if CPICH
Ec/No measured and reported by the UE is less than value of this
parameter. If lowest possible parameter value is defined, in practice
CPICH Ec/No value does not affect to channel type selection algorithm for
SRBs.
Short description:
This parameter defines threshold for CPICH Ec/No to determine whether
RRC connection setup is allowed to perform on common channels (CCH).

Object: WCEL
Multiplicity: 1 (scalar parameter)
Related functions: Admission Control
Parameter group: ACConfiguration
Classification: Radio Resource Utilisation
Range and step: -24 … 0 dB, step 0.5 dB
Default value: -8.0 dB
Internal value: UI_value*2
Required on creation: Optional
Modification: On-line
Related features: Call setup and channel activation time improvements
(standard)
References: NSN reference: RAN1797 Signaling Performance
Improvements EFS
RNC stored:RNW Database
Interfaces: RAC <->RNC, EM <-> RNC, RACApp <-> RAC

2.7.7 RAN 1638 Flexible RLC

Data type: Enumeration

Abbreviated name: FRLCEnabled
Parameter name:Flexible RLC Enabled
Description: This parameter enables/disables use of feature Flexible RLC.
If the parameter is enabled (1), then feature Flexible RLC is used in the
RNC. If the parameter is disabled (0), then feature Flexible RLC is not
used in the RNC.
Short description: This parameter enables/disables use of feature Flexible
RLC. If the parameter is enabled (1), then feature Flexible RLC is used in
the RNC. If the parameter is disabled (0), then feature Flexible RLC is not
used in the RNC.
Additional information: -
3GPP Name: -
System information: -
Hidden: No

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 420(447)
Basic Call
 Functionality description

Object: RNC
Multiplicity: 1 (scalar parameter)
Related functions: Admission Control
Related parameters and Descriptions:
HSDPADynamicResourceAllocation Flexible RLC can be utilised only if
HSDPA Dynamic Resource Allocation is enabled in the RNC.
Parameter group: ACConfiguration
Classification: Radio Resource Utilisation
Range and step: 0 (Disabled), 1 (Enabled)
Default value: 0
Default value notes: -
Special value: -
Special value description: -
Internal value: = UI_value
Required on creation: Optional
Modification: Requires object locking
Modified: -
Related features: HSDPA Dynamic Resource Allocation (Optional)
Interfaces:
RAC <->RNC, EM<->RNC, RACApp<->RAC
Stored: RNC RNW database
2.7.8 RAN981 HSUPA 5.8 Mbps and RAN1470 HSUPA 2ms TTI

[Link] HSUPA 2MS TTI Enabled

Abbreviated name: HSUPA2MSTTIEnabled

Parameter name: HSUPA 2 ms TTI enabled
Data type: Enumeration
Object: WCEL
Description:
This parameter enables / disables the use of E-DCH 2ms TTI in the cell.
When the value of the parameter is set to 1, the HSUPA 2 ms TTI
functionality is enabled for the cell.
If the parameter is enabled (1) the system checks that the licence of the
HSUPA 2 ms TTI feature is active (state 'On' and exist). If not that is
informed by appropriate configuration error and parameter value change
to enabled is not allowed.
Short description: The parameter enables / disables the use of E-DCH
2ms TTI in the cell.
3GPP Name: -
System information:-
Hidden: No

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 421(447)
Basic Call
 Functionality description

Parameters included in this structure: None

Multiplicity: 1 (scalar parameter)
Related functions: Admission Control, Packet Scheduler
Related parameters and description:
WCEL-HSDPAenabled HSUPA 2 ms TTI can not be activated if HSDPA
is disabled. (public)
WCEL-HSUPAEnabled HSUPA 2 ms TTI can not be activated if HSUPA
is disabled. (public)
Parameter group: ACConfiguration
Classification: Radio Resource Utilisation
Range and step: 0 (Disabled), 1 (Enabled)
Default value: 0
Default value notes: -
Special value: -
Special value description: -
Internal value: UI_value
Required on creation: Optional
Modification: Object locking required
Modified: -
Related features: HSDPA (optional) and HSUPA (optional) and HSUPA 2
ms TTI (optional)
Process/calculation: -
References: RNC EFS HSUPA 5.8 Mbps and HSUPA 2 ms TTI (public)
Internal NE Type:
RNC stored:RNC RNW Database
[Link] Interfaces:RAC <->RNC, EM <-> RNC, RACApp <-> RACMaximum total
uplink symbol rate

Abbreviated name: MaxTotalUplinkSymbolRate

Parameter name: Maximum total uplink symbol rate
Object: WCEL
Data type: Enumeration
Description: This parameter determines the planned maximum total
uplink symbol rate of the E-DPDCH(s) of the UE in the cell.
The lowest parameter value among the values of the parameters of the
cells that belong to the E-DCH active set is used when the E-DCH is
allocated. The signalled value is updated when a soft handover branch
addition or deletion occurs and the lowest value changes. Note: Upgrade
is not always possible due to capacity reasons in the RNC.
The final maximum total uplink symbol rate is minimum of the following
limitations: UE capability, BTS capability, this cell based limitation,
possible limitation which is set based on maximum uplink user bit rate of
the RAB and actual available capacity in the RNC.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 422(447)
Basic Call
 Functionality description

The system checks that maximum number of BTSs capacity value of

'HSUPA 2 Mbps' feature is not exceeded, if respective parameter value is
set '2'. If it is exceeded that is informed by appropriate configuration error
and parameter value change to '2' is not allowed.
The system checks that licence of 'HSUPA 5.8 Mbps' feature is active
(state 'On' and exist), if respective parameter value is set '3'. If not active
that is informed by appropriate configuration error and parameter value
change to '3' is not allowed.
Information is signalled to the UE using the RRC: Maximum
channelisation codes IE and to the BTS using the NBAP: Maximum Set of
E-DPDCHs IE.
Short description: This parameter determines the planned maximum total
uplink symbol rate of the E-DPDCH(s) of the UE in the cell.
Additional information: -
3GPP Name: -
System information: -
Hidden: No
Multiplicity: 1 (scalar parameter)
Related functions: Packet Scheduler
Related parameters: WCEL-HSUPA2MSTTIEnabled Parameter value '3'
( 5760kbps, 2*SF2+2*SF4) can not be activate/set if the HSUPA 2 ms TTI
is disabled. (public)
Description of parameter relationships: -
Parameter group: PSParameters
Classification: Radio Resource Utilisation
Range and step: 0 (960 kbps, SF4), 1 (1920 kbps, 2*SF4), 2 (3840 kbps,
2*SF2), 3 (5760 kbps, 2*SF2 + 2*SF4)
Default value: 0
Default value notes: -
Required on creation: optional
Modification: Requires object locking
Modified: -
Related features: HSUPA (optional) AND HSUPA Basic RRM (optional)
Process/calculation: -
References: Nokia reference: HSUPA RRM SFS
NSN reference: RNC EFS 981 HSUPA 5.8 Mbps and 1470 HSUPA 2 ms
TTI (public)
Internal NE Type: max_tot_upl_sym_rat_t
2.7.9 RAN1201 F-DPCH

Data type: Enumeration

Abbreviated name: FDPCHSetup
Parameter name:FDPCH Setup

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 423(447)
Basic Call
 Functionality description

Description: This parameter defines the allocation procedure of F-DPCH

in the RRC connection setup phase in the cell.
This parameter defines the allocation procedure of Fractional DPCH (F-
DPCH) in the RRC connection setup phase in the cell.

When the value of the parameter is set to 0 (Immediate F-DPCH

allocation), the system allocates F-DPCH for the Rel-7 and newer UE that
supports Rel-7 F-DPCH immediately in RRC connection setup phase.

When the value of the parameter is set to 1 (F-DPCH allocation after RRC
connection setup), the system allocates F-DPCH for the UE immediately
after RRC message RRC Connection Setup Complete is received and if
UE has indicated that it supports Rel-7 F-DPCH. RRC connection setup
phase runs on common channels.

When the value of the parameter is set to 2 (F-DPCH allocation along with
user plane allocation), the system allocates F-DPCH for the UE after RRC
connection setup along with user-plane allocation if UE has indicated that
it supports Rel-7 F-DPCH. State transition to CELL_DCH state and DCH
allocation for SRBs is allocated immediately in RRC connection setup
phase.
Additional information: -
3GPP Name: -
System information: -
Hidden: No
Object: RNC
Multiplicity: 1 (scalar parameter)
Related functions: Admission Control, Packet Scheduler
Related parameters and Descriptions: -
Parameter group: ACConfiguration
Classification: Radio Resource Utilisation
Range and step: 0 (Immediate F-DPCH allocation), 1 (F-DPCH allocation after RRC
connection setup), 2 (F-DPCH allocation along with user plane allocation)
Default value: 0
Default value notes: -
Special value: -
Special value description: -
Internal value: = UI_value
Required on creation: Optional
Modification: On-line
Modified: -
Related features: HSDPA (optional) AND HSUPA (optional) AND QoS
Aware HSPA Scheduling (optional) AND Fractional DPCH (optional)
Interfaces:
RAC <->RNC, EM<->RNC, RACApp<->RAC

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 424(447)
Basic Call
 Functionality description

Stored: RNC RNW database

2.7.10 Emergency Call Redirect

Parameter Name: Emergency Call Redirect

Range: 0 (Disabled), 1 (Enabled)
Default value: Disabled
Description: This parameter enables/disables redirect feature for
emergency calls to GSM on connection creation. When this parameter is
enabled all emergency call are directed to GSM network.
Object: RNC
Parameter Name: Emergency Call Redirect Timer
Range: 0..255 s
Step: 1 s
Default value: 60 s
Description: This parameter sets the timer value for emergency call
redirect feature. Emergency call redirect feature redirects emergency calls
to GSM network, unless second emergency call from the same mobile is
done within time limit set by this parameter.

2.7.11 RAN1202: 24 kbps Paging Channel

PCH24kbpsEnabled Modifiable WCEL

NbrOfSCCPCHs (old parameter) Modifiable WCEL

<ADA3.0/begin>

2.7.12 RAN2051 Paging Optimization

[Link] IUCS - PagingOptSupport

Object: IUCS

Abbreviated name: PagingOptSupport

Parameter name: Support of Paging Optimization Feature

Data Type : Enumeration

Description: This parameter controls whether Paging Optimization

Feature is used for this IU interface or not. If enabled then for pagings
received on this interface, I-BTS will distribute the paging message among
paging group members.

Short description: This parameter controls the usage of Paging

Optimization feature for this IUCS interface

Hidden: No

Multiplicity: 1 (scalar parameter)

Related functions: Mobile Device Control

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 425(447)
Basic Call
 Functionality description

Related Parameters: IADA-PagingRoleType: This parameter shall only be

configurable in case PagingRoleType is 1(Paging Master) or 2(Paging
Standby)

Classification: Telecom

Range and Step: 0(disabled), 1(enabled)

Default value: 0

Default value notes: disabled

Required on creation: optional

Modification: On-line

Related features: Paging Optimization (optional)

References: NSN reference: 2051 Paging Optimizations

Internal NE Type: paging_opt_support_t

History: Created for ADA3.0

[Link] IUPS - PagingOptSupport

Object: IUPS

Abbreviated name: PagingOptSupport

Parameter name: Support of Paging Optimization Feature

Data Type : Enumeration

Description: This parameter controls whether Paging Optimization

Feature is used for this IU interface or not. If enabled then for pagings
received on this interface, I-BTS will distribute the paging message among
paging group members.

Short description: This parameter controls the usage of Paging

Optimization feature for this IUCS interface

Hidden: No

Multiplicity: 1 (scalar parameter)

Related functions: Mobile Device Control

Related Parameters: IADA-PagingRoleType: This parameter shall only be

configurable in case PagingRoleType is 1(Paging Master) or 2(Paging
Standby)

Classification: Telecom

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 426(447)
Basic Call
 Functionality description

Range and Step: 0(disabled), 1(enabled)

Default value: 0

Default value notes: disabled

Required on creation: optional

Modification: On-line

Related features: Paging Optimization (optional)

References: NSN reference: 2051 Paging Optimizations

Internal NE Type: paging_opt_support_t

History: Created for ADA3.0

2.7.13 CS enabling Handover

[Link] IADA - CSVoiceServiceSupport

Object class: IADA

Abbreviated name: CSVoiceServiceSupport

Parameter name: CS Voice Service Support in I-HSPA

Description: This parameter defines the CS Service Deployment in I-HSPA

Network. The following deployment scenarios possible in ADA3.0 with
respect to CS Voice Services Support.

i. PS Only Network: DSAC for CS domain is applied. CSEHO and CS

Voice support both are disabled.

ii. CS Enabling HO to overlaying 2G network (Overlay deployment) : w

iii. CS Voice Supported - Cs Voice supported in ADA3.0

Operator can configure this parameter to enable desired deployment

scenario.

Short description: The parameter enables / disables different CS

Deployment possible in I-HSPA Network.

Hidden: No

Multiplicity: 1 (scalar parameter)

Related functions: Handover Control, Mobile Device Control,

Admission Control

Related parameters:

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 427(447)
Basic Call
 Functionality description

Classification: Telecom

Range and step: 0 (PS_only_deployment), 1 (CS Enabling HO

Enabled), 2( CS Voice Supported)

Default value:

Default value notes: -

Required on creation: Mandatory

Modification: On-line

Related features:

References: Nokia reference:

Internal NE Type:

History: Created for ADA 3.0.

[Link] IADA – CSRedirWaitTimer

Object Class : IADA

Should be inherited from ADA 2.0

<ADA3.0/end>

2.7.14 RAN1645 HSUPA 16QAM

[Link] WCEL - HSUPA16QAMAllowed

Description: This parameter is used to define whether RNC allows the

usage of 16QAM modulation for HSUPA. If the parameter is enabled,
then RNC can use the HSUPA 16QAM feature in a cell. If the parameter
is disabled, then RNC can not use the HSUPA 16QAM feature in a cell.
The HSUPA 16QAM is allowed in the cell if the
MaxTotalUplinkSymbolRate has value "3" indicating the max symbol rate
of 5760 kbps.

Short description: This parameter is used to define whether RNC allows

the usage of 16QAM modulation for HSUPA. If the parameter is enabled,
then RNC can use the HSUPA 16QAM feature in a cell.

Additional information: -

3GPP Name: -

System information: -

Hidden: No

Multiplicity: 1 (scalar parameter)

Related functions: Admission Control

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 428(447)
Basic Call
 Functionality description

Related parameters: -

Description of parameter relationships: -

Parameter group: ACConfiguration

Classification: Radio Resource Utilisation

Range and step: 0 (Disabled), 1 (Enabled)

Default value: 0

Default value notes: -

Required on creation: optional

Modification: On-line

Modified: -

Related features: HSUPA 16QAM (optional) AND

HSUPA 5.8 Mbps (optional)

Process/calculation: -

References: NSN reference: RAN1645 HSUPA 16QAM EFS (public)

Internal NE Type: -

History: -

CM Views:

[Link] RNC - ETFCIBoost

Description: E-DPCCH power boosting was introduced to enable the

usage of E-DPCCH for demodulation channel estimation. The E-TFCI
Boost Information allows increasing the power of the E-DPCCH
depending on a configurable E-TFCI threshold.

Short description: E-TFCI threshold indicates when E-DPCCH power

boosting can be used.

Additional information: -

3GPP Name: -

System information: -

Hidden: Yes

Multiplicity: 1 (scalar parameter)

Related functions: Admission Control

Related parameters: -

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 429(447)
Basic Call
 Functionality description

Description of parameter relationships: -

Parameter group: PSParameters

Classification: Radio Resource Utilisation

Range and step: 0..127, step 1

Default value: 103

Default value notes: Boosting shall be used only for 16QAM.

Internal value: = UI_value

Required on creation: optional

Modification: On-line

Modified: -

Related features: HSUPA 16QAM (optional)

Process/calculation: -

References: NSN reference: RAN1645 HSUPA 16QAM EFS (public)

Internal NE Type: -

History: -

CM Views: -

[Link] RNC - DeltaT2TP

Description: Total E-DPDCH power across all codes to the combined

power of DPCCH and E-DPCCH

Short description: Total E-DPDCH power across all codes to the

combined power of DPCCH and E-DPCCH

Additional information: -

3GPP Name: -

System information: -

Hidden: Yes

Multiplicity: 1 (scalar parameter)

Related functions: Admission Control

Related parameters: -

Description of parameter relationships: -

Parameter group: PSParameters

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 430(447)
Basic Call
 Functionality description

Classification: Radio Resource Utilisation

Range and step: 0..6, step 1

Default value: 5

Default value notes: -

Internal value: = UI_value

Required on creation: optional

Modification: On-line

Modified: -

Related features: HSUPA 16QAM (optional)

Process/calculation: -

References: NSN reference: RAN1645 HSUPA 16QAM EFS (public)

Internal NE Type: -

History: -

CM Views:

[Link] RNC - EAGCHTable

Description: This hidden parameter is used for HSUPA 16QAM defining

the E-AGCH table to be used (either Absolute Grant Value Table 16B or
Absolute Grant Value Table 16B.1)

Short description: The E-AGCH table to be used for HSUPA 16QAM.

Additional information: -

3GPP Name: -

System information: -

Hidden: Yes

Multiplicity: 1 (scalar parameter)

Related functions: Admission Control

Related parameters: -

Description of parameter relationships: -

Parameter group: PSParameters

Classification: Radio Resource Utilisation

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 431(447)
Basic Call
 Functionality description

Range and step: 0 (Absolute Grant Value Table 16B), 1 (Absolute

Grant Value Table 16B.1)

Default value: 1

Default value notes: -

Required on creation: optional

Modification: On-line

Modified: -

Related features: HSUPA 16QAM (optional)

Process/calculation: -

References: NSN reference: RAN1645 HSUPA 16QAM EFS (public)

Internal NE Type: -

History: -

CM Views: -

[Link] RNC - EDPDCHPowerInterUsage

Description: This parameter enables/disables the usage of E-DPDCH

power interpolation for 10ms TTI and 2ms TTI. Note that for HSUPA
16QAM the E-DPDCH power interpolation shall always be used.

Short description: This parameter enables/disables the usage of E-

DPDCH power interpolation

Additional information: -

3GPP Name: -

System information: -

Hidden: Yes

Multiplicity: 1 (scalar parameter)

Related functions: Admission Control

Related parameters: -

Description of parameter relationships: -

Parameter group: ACConfiguration

Classification: Radio Resource Utilisation

Range and step: 0 (Enabled), 1 (Disabled)

Default value: 0

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 432(447)
Basic Call
 Functionality description

Default value notes: -

Required on creation: optional

Modification: Not modifiable

Modified: -

Related features: -

Process/calculation: -

References: NSN reference: HSUPA RRM FD (public)

Internal NE Type: -

History: -

CM Views: -

<RAN2717/begin>

2.7.15 RAN2717 Smart LTE layering

[Link] WCEL – SmartLTELayeringEnabled

Description: The parameter indicates whether or not the Smart LTE

Layering feature is enabled in the cell. It also defines what triggering
points are used. The following two triggering points are available:
T1: RRC state change Cell_DCH to CCH
T2: HSDPA/HSPA to DCH/DCH CTS
T3: CS RAB release
T4: Periodic trigger

Channel type switch means here cases where HS-DSCH is tried to be

switched to DCH (E-DCH/HS-DSCH --> DCH/DCH or DCH/HS-DSCH -->
DCH/DCH) with some other bit rate than 0 (pure release cases are
excluded).

CS RAB release trigger means case where an UE has CS RAB and at

least one active PS RAB and then CR RAB is released (UE would stay in
CELL_DCH state in WCDMA).

Periodic Trigger means LTE supported UEs, which remain longer than
time specified (by parameter RNC-LTEPeriodicTriggerTimer) in the
CELL_DCH state (packet switched) and provided no other trigger
received during that time, then measurements are triggered based on this
timer. The decision, whether UE shall be redirected to LTE or not, shall be
made on the basis of received measured results. Options (5-8) with
Periodic Trigger can be used, only if RAN2980 license is also in ON state.

Cell specific CPICH RSCP threshold for the functionality is set with the
SmartLTELayeringRSCP parameter.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 433(447)
Basic Call
 Functionality description

Cell specific user amount threshold for the functionality is set with the
SmartLTELayeringUA parameter.

Services that the UE to be redirected to LTE can be using are set with the
SmartLTELayeringServ parameter.

The minimum time that the UE must be in WCDMA system after RRC
Connection Setup Complete has been received or when Relocation
Request for PS service is received is set with the parameter
SmartLTELayeringPrevT.

Redirection to FDD LTE, TDD LTE or both of them is set with the
SmartLTELayeringTSysSel parameter.

Range and step: 0 (disabled), 1 (enabled for T1), 2 (enabled for T1 and
T2), 3 (enabled for T1 and T3), 4 (enabled for T1, T2 and T3), 5 (enabled
for T1 and T4), 6 (enabled for T1, T2 and T4), 7 (enabled for T1, T3 and
T4), 8 (enabled for all triggers)

Default value: 0

Default value notes: Feature is disabled

[Link] RNMOBI - SmartLTELayeringPrevT

Description: The parameter defines a minimum time that the UE must

be in WCDMA system after RRC Connection Setup Complete has been
received or when Relocation Request received from LTE. An UE can be
redirected to LTE by Smart LTE Layering feature after the timer defined
by this parameter expires. When this timer is running the Smart LTE
Layering is not triggered.

Setting timer value too low may cause ping pong redirections between
WCDMA and LTE, while setting the timer's value too high might trigger
redirection to LTE less frequently than needed to be effective.

Range and step: 1..120 s, step 1 s

Default value: 20 s

Default value notes: Smart LTE Layering is prevented for 20 seconds

after RRC setup or Relocation for PS service from LTE

<RAN2717/end>

<RAN2135/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 434(447)
Basic Call
 Functionality description

2.7.16 Layering in RRC Connection Release (RAN2135)

2.7.17 WCEL - LayeringRRCRelEnabled

Description: This parameter defines whether the layering in RRC

Connection Release is enabled in the cell. Layering in RRC Connection
Release directs UE to other frequency layer in RRC Connection Release.

Target frequencies and frequency ranges are defined with parameters

under LayeringRRCRelTargFreq structure. If no target frequencies are
defined, no layering is done in RRC Connection Release due to Layering
in RRC connection Release.

Range and step: 0 (Disabled), 1 (Enabled)

Default value: 0

Default value notes: -

[Link] WCEL - LayeringRRCRelTargFreq

Description: This parameter structure defines the target frequencies for

Layering in RRC Connection Release. Up to 8 different FDD UMTS
frequencies or frequency ranges can be defined.

In case of:
- frequency range, both TargFreqLower and TargFreqUpper are defined.
- frequency, only TargFreqLower is defined.

Parameters included in this structure: TargFreqLower, TargFreqUpper

Range and step: -

Default value: -

Default value notes: -

[Link] WCEL-LayeringRRCRelTargFreq-TargFreqLower

Description: This parameter defines the lower target frequency of a

frequency range or a single target frequency for layering in RRC
connection release. The parameter TargFreqUpper defines the upper
target frequency of frequency range. If parameter TargFreqUpper does
not define any frequency then this parameter defines single target
frequency.

The frequencies are given in UTRA Absolute Radio Frequency Channel

Number (UARFCN) format, which defines the downlink channel number
and the downlink carrier frequency.

Default value 0 means that UE is not directed to other frequency in RRC

Connection Release due to Layering in RRC connection Release.

Range and step: 0..16383, step 1

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 435(447)
Basic Call
 Functionality description

Default value: 0

Default value notes: UE is not directed to other frequency

[Link] WCEL - LayeringRRCRelTargFreq - TargFreqUpper

Description: This parameter defines the upper target frequency of a

frequency range for layering in RRC connection release. If this parameter
does not define any frequency then frequency range of several
frequencies are not used.

The frequencies are given in UTRA Absolute Radio Frequency Channel

Number (UARFCN) format, which defines the downlink channel number
and the downlink carrier frequency.

Default value 0 means that UE means that frequency range is not

defined.

Range and step: 0..16383, step 1

Default value: 0

Default value notes: Frequency range is not defined

<RAN2135/end>

<RAN3093/begin>

2.7.18 RAN3093 Enhanced MBLB

[Link] WCEL – MBLBEnhancementsEnabled

Description: The parameter enables the functionalities of the RAN3093

Enhanced MBLB (Multi-Band Load Balancing) feature.

The functionalities that are related to the MBLB enhancements are the
following. A certain functionality is disabled when the value of the
corresponding bit is 0 and enabled when the value is 1.

Bit0 (1st bit) Enhanced load balancing

Enables the use of the MBLB feature just for load balancing. The
enhancement is applied to Blind HO in RAB setup (WCEL-
MBLBRABSetupEnabled), Layering in state transition (WCEL-
MBLBStateTransEnabled), Inactivity triggered HO (WCEL-
MBLBInactivityEnabled) and Mobility triggered HO (WCEL-
MBLBMobilityEnabled) phases.

Bit1 (2nd bit) Enhanced layering during voice call setup - Blind IFHO in
RRC setup
Enables the use of the Blind IFHO in RRC setup if the establishment of
CS voice call is indicated.

Note: Blind IFHO in RRC setup is able to move UE to a frequency layer

within the same frequency band. If a layer change to another frequency
band is desired, Blind IFHO in RRC setup should not be used.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 436(447)
Basic Call
 Functionality description

Bit2 (3rd bit) Enhanced layering during voice call setup - Blind IFHO for
CS voice call from CCH states
Enables the use of Blind IFHO for CS voice call starting from CCH states.
This functionality requires the feature RAN2970 "Improvement to CS Call
Setup Attempts Starting from Cell_FACH/Cell_PCH" to be activated with
the parameter RNFC–CSCallSetUpFACHPCHImpr.

Bit3 (4th bit) Enhanced layering during voice call setup - "HSPA load
state" bypass
Enables the use of HSPA load state bypass for AMR call. The function is
applied to the MBLB Blind IFHO (WCEL-MBLBRABSetupEnabled,
WCEL-MBLBRABSetupMultiRAB) and MBLB Mobility triggered HO
(WCEL-MBLBMobilityEnabled).

Bit4 (5th bit) Enhanced inactivity triggered layering without CM

Enables inactivity triggered layer change without compressed mode
measurements if the radio conditions are good enough. The
enhancement is applied to Inactivity triggered HO (WCEL-
MBLBInactivityEnabled) phase.

Bit5 (6th bit) Enhanced mobility triggered layering

Enables the checking of need for mobility triggered layering after RAB
setup is completed, and in case of multi-RABs, after the AMR RAB is
setup. The enhancement is applied to Mobility triggered HO (WCEL-
MBLBMobilityEnabled) phase.

Bit6 (7th bit) Enhanced inactivity triggered layering in state transition to

CCH states
Enables inactivity triggered layer change in state transition (instead of
hard handover) when UE is moving from Cell_DCH to Cell_FACH/PCH or
URA_PCH state. The enhancement is applied to Inactivity triggered HO
(WCEL-MBLBInactivityEnabled) phase.

Range and step: Bit 0: Enhanced load balancing , Bit 1: Blind IFHO in
RRC setup , Bit 2: Blind IFHO for CS voice call from CCH states , Bit 3:
Bypass of HSPA load state in case of CS voice call , Bit 4: Enhanced
inactivity triggered layering without CM , Bit 5: Enhanced mobility
triggered layering , Bit 6: Enhanced inactivity triggered layering to CCH
states

Default value: 0

Default value notes: All enhancements disabled

<RAN3093/end>

<RAN3079/begin>

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 437(447)
Basic Call
 Functionality description

2.7.19 RAN3079 Dedicated Priorities

[Link] WSP – WSP Identifier (WSPId)

Description: WSP (WCDMA Subscriber Profile) object instance identifier.

The WSP object class contains subscriber specific priority information for
the WCDMA, LTE and GSM carrier frequencies to be used for the
absolute priority based cell reselection.

Note: that it is not possible to make handover or redirect UE to a LTE

carrier frequency that is not included in the subscriber specific priority
information.

Note that subscriber specific priority information does not affect inter-
frequency and GSM handover control.

Range and step: 1..255, step 1

Default value: -

[Link] WSP – WCDMA Subscriber Profile related Iu Operator

(WSProfileRelatedIUO)

Description: This parameter links the WSP (WCDMA Subscriber Profile)

object to a certain Iu Operator (IUO object).

Related Parameters:

• IUO-IUOId The related IUO object must exist. (public)

• WSP-SubscriberProfilePLMNId Combination of
WSProfileRelatedIUO, SubscriberProfilePLMNId and SPID in the
WSP object must be unique within all WSP object instances.
(public)

• WSP-SPID Combination of WSProfileRelatedIUO,

SubscriberProfilePLMNId and SPID in the WSP object must be
unique within all WSP object instances. (public)

Range and step: 1..255, step 1

Default value: -

[Link] WSP – Subscriber Profile ID (SPID)

Description:This parameter identifies subscriber specific priority

information for the WCDMA, LTE and GSM carrier frequencies to be used
for the absolute priority based cell reselection.

Note: that it is not possible to make handover or redirect UE to a LTE

carrier frequency that is not included in the subscriber specific priority
information.

Note: that subscriber specific priority information does not affect inter-
frequency and GSM handover control.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 438(447)
Basic Call
 Functionality description

The WSP object is not related to any particular SPID if the value of this
parameter is “Not defined”.

The WSP object contains a default subscriber profile for roaming

subscribers if it is not related to any particular PLMN and SPID. The WSP
object is not related to any particular PLMN if the value of the parameter
SubscriberProfilePLMNId is “Not defined”.

3GPP name: Subscriber Profile ID for RAT/Frequency Priority (SPID)

Related Parameters:

• WSP-WSProfileRelatedIUO Combination of
WSProfileRelatedIUO, SubscriberProfilePLMNId and SPID in the
WSP object must be unique within all WSP object instances.
(public)

• WSP-SubscriberProfilePLMNId Combination of
WSProfileRelatedIUO, SubscriberProfilePLMNId and SPID in the
WSP object must be unique within all WSP object instances.
(public)

Range and step: 1..256, step 1

Default value: 65535

Default value notes: Not defined

Special value: 65535

Special value description: Not defined

[Link] WSP – WCDMA Subscriber Profile E-UTRA detection

(WSProfileEUTRADetection)

Description: This parameter defines whether the UE with a given SPID

value in CELL_PCH, URA_PCH state or idle mode may detect the
presence of an E-UTRA cell on a frequency with an absolute priority lower
than the current UTRA cell and report the information to the NAS.

3GPP name: E-UTRA detection

Range and step: 0 (Disabled), 1 (Enabled)

Default value: 0

Default value notes: Detection of E-UTRA cell is disabled.

[Link] WSP – Subscriber Profile PLMN Identifier (SubscriberProfilePLMNId)

Description: This parameter contains the identifier of the Public Land

Mobile Network (PLMN) that is related to the WSP (WCDMA Subscriber
Profile) object.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 439(447)
Basic Call
 Functionality description

The WSP object is not related to any particular PLMN if the value of the
parameters SubscriberProfileMCC and SubscriberProfileMNC is “Not
defined”.

The WSP object contains a default subscriber profile for roaming

subscribers if it is not related to any particular PLMN and SPID. The WSP
object is not related to any particular SPID if the value of the parameter
WSP-SPID is “Not defined”.

Parameters included in this structure: SubscriberProfileMCC,

SubscriberProfileMNC, SubscriberProfileMNClength

Related Parameters:

• WSP-WSProfileRelatedIUO Combination of
WSProfileRelatedIUO, SubscriberProfilePLMNId and SPID in the
WSP object must be unique within all WSP object instances.
(public)

• WSP-SPID Combination of WSProfileRelatedIUO,

SubscriberProfilePLMNId and SPID in the WSP object must be
unique within all WSP object instances. (public)

[Link] WDP – WDP Identifier (WDPId)

Description: WDP (WCDMA Dedicated Priority) object instance identifier.

The WDP object class contains subscriber specific priority level for the
given WCDMA/LTE/GSM carrier frequencies to be used in the absolute
priority based cell reselection.

Note: that it is not possible to make handover or redirect UE to a LTE

carrier frequency which does not have subscriber specific priority level.

Note: that subscriber specific priority level does not affect inter-frequency
and GSM handover control.

Range and step: 1..8, step 1

[Link] WDP – Dedicated Priority Level (DedicatedPriorityLevel)

Description:This parameter defines the subscriber specific priority level

for the given WCDMA/LTE/GSM carrier frequencies in the absolute
priority based cell reselection. 0 indicates the lowest absolute priority level
and 7 indicates the highest absolute priority level.

Note: that it is not possible to make handover or redirect UE to a LTE

carrier frequency which does not have subscriber specific priority level.

Note: that subscriber specific priority level does not affect inter-frequency
and GSM handover control.

The parameter value must be unique within all subscriber specific

priorities associated with a certain Subscriber Profile ID.

Range and step: 0..7, step 1

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 440(447)
Basic Call
 Functionality description

[Link] WDP – Radio Access Technology (RadioAccessTechnology)

Description: This parameter defines the radio access technology (RAT)

of the downlink carrier frequencies for which the subscriber specific
priority level has been configured.

GSM or GSM1900 radio access technology can occur the maximum of 3

times within the subscriber specific priorities associated with a certain
Subscriber Profile ID.

Range and step: 0 (LTE), 1 (WCDMA), 2 (GSM), 3 (GSM1900)

[Link] WDP – Absolute Radio Frequency Channel Number (ARFCN)

Description: This parameter defines the Absolute Radio Frequency

Channel Number (ARFCN) of the downlink carrier frequency for which the
subscriber specific priority level has been configured.

The range is 0...65535 in case of LTE radio access technology.

The range is 0...16383 in case of WCDMA radio access technology.

The range is 0...1023 in case of GSM radio access technologies.

The maximum number of LTE carrier frequencies is 8 within one

subscriber specific priority level and 32 within all subscriber specific
priorities associated with a certain Subscriber Profile ID.

The maximum number of WCDMA carrier frequencies is 8 within one

subscriber specific priority level and 16 within all subscriber specific
priorities associated with a certain Subscriber Profile ID.

The maximum number of GSM carrier frequencies is 32 within one

subscriber specific priority level.

Note: If any of the LTE frequencies within one WDP instance (WDP-
ARFCN) is defined as neighbouring E-UTRA frequency in LTE
adjacencies (ADJL-AdjLEARFCN) under a WCEL instance, and any value
different from the special value (32 dB) is set to both HOPL-
AdjLThreshigh2 and HOPL-AdjLThreslow2 in some of those LTE
adjacencies under the WCEL instance, the operator must ensure that a
value different from the special value (32 dB) is set to both HOPL-
AdjLThreshigh2 and HOPL-AdjLThreslow2 in all those LTE adjacencies
under the WCEL instance in question. This instruction is valid only if
RNFC-DedicatedPriorityEnabled is set to value "Enabled".

3GPP name: EARFCN, UARFCN, ARFCN

Multiplicity: 32 (scalar parameter)

Related Parameters:

• WDP–RadioAccessTechnology The range is 0...65535 for LTE,

0...16383 for WCDMA and 0...1023 for GSM RATs. Max number

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 441(447)
Basic Call
 Functionality description

of LTE frequencies is 8 within one WDP instance and 32 within

WDP instances under the same WSP. Max number of WCDMA
frequencies is 8 within one WDP instance and 16 within WDP
instances under the same WSP. (public)

• ADJL- AdjLEARFCN The parameter relation is specified in detail

in the note in parameter description. (public)

• HOPL-AdjLThreshigh2 The parameter relation is specified in detail

in the note in parameter description. (public)

• HOPL-AdiLThreslow2 The parameter relation is specified in detail

in the note in parameter description. (public)

Range and step: 1.. 262143, step 1

<CR#E1381/begin>

The range of the parameter is extended from 0..65535 to 0...262143.

<CR#E1381/end>

<RAN3079/end>

<RAN3292/begin>

2.7.20 RAN3292 Idle Paging Repetition

[Link] RNFC-Idle Page Repetition Enabled (IdlePageRepetitionEnabled)

Description: This parameter activates the RAN3292 Idle Paging

Repetition feature. When the feature is enabled, the idle mode paging
messages are repeated autonomously by RNC. The feature can be
enabled separately for only CS or both CS and PS paging.

Functionality of Paging drop reduction during SFN jump is also enabled

together with Idle Paging Repetition.

Range and step: 0: Idle paging repetition disabled, 1: Idle paging

repetition for CS paging enabled, 2: Idle paging repetition for CS and PS
paging enabled

Default value: 0

Default value notes: Idle paging repetition functionality disabled

<RAN3292/end>

2.8 Hidden parameters

2.9 Parameters and Timers

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 442(447)
Basic Call
 Functionality description

Management parameters for timers used in this document

Parameter Default Description

GeneralRANAPTmr 4s This supervision timer is used supervising the

receipt of Iu Release Command from CN.
If/when the CS-CN releases the last RT-RAB
for the UE; the RRC entity shall start time
supervision GeneralRANAPTmr and wait for
an Iu Release Command from the CN. If/when
the supervision timer expires, the RRC entity
shall initiate the Iu Release procedure towards
the CS-CN and switch the UE to Cell_FACH
state (or Cell/URA_PCH).
RANAPprocInitWait 10 s Timer is used for supervising a reception of a
(Cell_DCH & Cell_FACH) RANAP procedure (RAB Assignment
Request, Iu Release Command, etc.) from the
PS-CN during the NAS signaling sequence in
Cell_FACH and Cell_DCH states. Range and
step: 0….30 s, Step 1 s
RANAPprocInitWaitCS 45 s Timer is used for supervising a reception of a
Internal supervision timer of fixed RANAP procedure (RAB Assignment
the RRC entity for NAS value Request, Iu Release Command, etc.) from the
signaling sequence towards CS-CN during the signaling connection
the CS-domain. establishment phase in Cell_FACH and
Cell_DCH states.
Note: In case of USSD service establishment
fixed value is 5 minutes.
SignConnActivitySupervision 60 s This timer defines whether it is allowed to
(Cell_PCH & URA_PCH) maintain an inactive signaling connection
towards the PS-CN and how long the RNC
keeps the connection before the Iu Release
Request procedure. UE is switched to PCH
states (if allowed/available).
Range and Step: 0 (0 seconds), 1 (10
seconds), 2(20 seconds), 3 (30 seconds), 4 (1
minute), 5 (2 minutes), 6 (5 minutes), 7 (10
minutes). Default 4
RRCmeasQueueTmr Future item.
T_RRC_Resp_DCH 6s This timer is started when the RRC message
is sent to the UE. Timer is stopped when an
acknowledge (negative or positive) is received
from the UE. In expiry of the timer, the RRC
entity initiates a release of the dedicated
resources and continues
UL_DLcapacityReqWait 5s This timer is set after setting up a PS-RAB for
the UE in Cell_DCH or Cell_FACH state. The
timer is also used in RRC connection re-
establishment when the UE (with NRT-RAB(s)
is transferred to the Cell_FACH state after a
radio link failure in Cell_DCH.
Range and step:0 …20 s, step 0.5 s.
UE-timer T314 4s RRC connection re-establishment timer for
RT service.
T_RRC_Resp_CCH 6s The timer is set when RNC initiates a RRC
procedure in common channel. The timer is
stopped when RNC has received a response
message from MS related to ongoing RRC
procedure.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 443(447)
Basic Call
 Functionality description

RRCconnRepTimer1 600 ms The timer defines the waiting time for the
repetition of the first RRC Connection Setup
message to the MS. Value 0 means that the
RRC Connection Setup retransmission
procedure is not used.
RRCconnRepTimer2 1200 ms The timer defines the waiting time for the
repetition of the second RRC Connection
Setup message to the MS in case of an RRC
Connection Setup Complete message is not
received from MS. Value 0 means that the
RRC Connection Setup retransmission
procedure is not used.

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 444(447)
Basic Call
 Implementation description

3. IMPLEMENTATION DESCRIPTION
Refer /56/.

4. CHANGE DESCRIPTION
5. OPEN ISSUE
6. APPENDICES
6.1 Appendix A: UE or Vendor Specific Functionality
6.1.1 Activation time shall be applied to the RB setup of NRT PS RAB

Activation time shall be applied to the RB setup procedure of NRT PS

RAB. Activation time other than ‘now’ shall be set to the RRC: RADIO
BEARER SETUP message if the functionality is enabled by the
hidden management parameter UETypeCheck. The parameter is
stored in GABFIL. The functionality is applicable to CELL_FACH and
CELL_DCH states.

The change concerns all the UEs in the network.

In case the usage of activation time is enabled, the CFN is determined

according to the principles specified in the requirement PS.18, i.e. the
determination of CFN is similar to the radio bearer reconfiguration.

Source: RRU

Rationale:

This hack has been originally made because of NEC VTB UEs which
required that activation time is set in the RRC: RADIO BEARER
SETUP message. However, it was not possible to separate VTBs
from other UEs and the change was made to concern all the UEs in
the network. Currently it is assumed that all the NEC VTB UEs will
disappear from the networks in the RAS06 time frame. Thus after
testing that all the UEs in the network support activation time ‘now’ it
can be switched on to decrease signaling delay.

6.1.2 Handling of the UE which are not fully 3GPP compliant

This requirement is deleted.

6.1.3 Uplink Traffic Volume measurement TX interruption time after trigger

VTX/VTB requirements are removed in from RAS06.

Reference: "WCDMA Parameter Dictionary Database" [31]

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 445(447)
Basic Call
 Appendices

Parameter Name: TrafVolTxInterruptionTimeUL

6.1.4 RNC instruction UE in RRC state Cell_FACH to prohibit transitions

RNC may instruct UE in RRC state CELL_FACH to prohibit

temporarily transmission of user data on the RACH after a
measurement report is triggered.

RNC shall signal ‘Tx interruption after trigger’ IE to UE using RRC:

MEASUREMENT CONTROL message before RRC connection is moved
to RRC state CELL_FACH. ‘Tx interruption after trigger’ IE indicates how
long the UE shall prohibit DTCH transmission on the RACH after a
measurement report is triggered.

Value of the ‘Tx interruption after trigger’ IE is controlled with the RNC
configuration parameter TrafVolPendingTimeUL.

Hidden RNC configuration parameter TrafVolTxInterruptionTimeUL allows

define fixed value for ‘Tx interruption after trigger’ IE instead of use of
TrafVolPendingTimeUL parameter. It is also possible to deny sending of
optional ‘Tx interruption after trigger’ IE.

6.1.5 GABFIL

In RNC there is special file where data structure of parameters that are
needed in order to handle a special vendor specific or UE(s) that network
must handled in special way has been collected. When RNC is booted up
it load this file into its internal memory unit and it will be available to be
used.

If new parameters has be added or deleted into/from this file it should be

updated and then make new sack for that.

6.2 Appendix B: AMR CALL time duration

AMR CALL setup time

RRC_CONNECTION_REQUEST 0.000
RRC_CONNECTION_SETUP 0.636
DCCH_RRC_CONNECTION_SETUP_COMPLETE 0.229
CM_SERVICE_REQUEST 0.292
AUTHENTICATION_REQUEST 0.286
AUTHENTICATION_RESPONSE 0.185
SECURITY_MODE_COMMAND 0.247
SECURITY_MODE_COMPLETE 0.016
SETUP 0.192
CALL_PROCEEDING 0.252
RADIO_BEARER_SETUP 0.659
RADIO_BEARER_SETUP_COMPLETE 0.450
ALERTING 0.352
Total 3.8 seconds

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 446(447)
Basic Call
 Appendices

DCCH was 3.4 kbps. With 13.4 kbps DCCH average MO call setup time
was 2.4 – 2.9 seconds

MTC AMR Call

PAGING_TYPE_1 0.000
RRC_CONNECTION_REQUEST 0.164
RRC_CONNECTION_SETUP 0.582
DCCH_RRC_CONNECTION_SETUP_COMPLETE 0.230
PAGING_RESPONSE 0.292
AUTHENTICATION_REQUEST 0.284
AUTHENTICATION_RESPONSE 0.173
SECURITY_MODE_COMMAND 0.252
SECURITY_MODE_COMPLETE 0.013
SETUP 0.225
CALL_CONFIRMED 0.027
RADIO_BEARER_SETUP 0.890
RADIO_BEARER_SETUP_COMPLETE 0.462
ALERTING 0.011
Total 3.6
0.027
RADIO_BEARER_SETUP 0.890
RADIO_BEARER_SETUP_COMPLETE 0.462
ALERTING 0.011
Total 3.6

Document name/edition Copyright © Nokia Solutions and Page

Functional Description Networks 447(447)
Basic Call