HSxPA Engineering Guide UA5.0 v02.09

HSxPA Engineering Guide

Document number: UMT/IRC/APP/016664 Document issue: 02.09 / EN Document status: Standard Date: 03/August/2007

EXTERNAL Document

Copyright 2007 Alcatel-Lucent, All Rights Reserved

Printed in France

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is “write protected”; it may be altered only by authorized persons. While copies may be printed, it is not recommended. Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded as uncontrolled copies.

ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose the information only to its employees with a need to know, and shall protect the information from disclosure and dissemination to third parties. Except as expressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have received this document in error, please notify the sender and destroy it immediately.


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

UMT/IRC/APP/016664 02.09 / EN Standard 03/August/2007 Page 2/276

PUBLICATION HISTORY

03/August/2007

Issue 02.09 / EN, Standard

Document updated for UA5.0 ChR delivery (DR5 delivery)

25/June/2007

Issue 02.08 / EN, Preliminary

Document updated for UA5.0.1

13/April/2007

Issue 02.07 / EN, Preliminary

Document updated for UA5.0 CuR delivery

16/March/2007

Issue 02.06 / EN, Draft

Document updated for UA5.0 pre-CuR delivery

15/Decembre/2006


Document update after Internal Review

05/Decembre/2006


Document update after primes contribution integration

28/Aug/2006


Document Creation based on HSDPA Eng’g Guide v01.09




CONTENTS

1 INTRODUCTION..........................................................................................................................11

1.1 OBJECT..................................................................................................................................11

1.2 SCOPE OF THIS DOCUMENT .....................................................................................................11

1.3 NOMENCLATURE .....................................................................................................................12

2 RELATED DOCUMENTS .................................. ..........................................................................14

2.1 REFERENCE DOCUMENTS........................................................................................................14

3 HSXPA OVERVIEW.....................................................................................................................15

3.1 SYSTEM OVERVIEW .................................................................................................................15

3.1.1 HSDPA ..........................................................................................................................18 3.1.1.1 Transport and physical channels.............................................................................. 18 3.1.1.2 Fast link adaptation .................................................................................................. 21 3.1.1.3 Fast Retransmission Mechanism (HARQ) ............................................................... 21 3.1.1.4 Fast scheduling ........................................................................................................ 29 3.1.2 HSUPA (E-DCH) ...........................................................................................................35 3.1.2.1 transport and physical channels ............................................................................... 35 3.1.2.2 UA5 implementation for E-DCH ............................................................................... 42

3.2 DEPLOYEMENT SCENARIOS .....................................................................................................44

3.2.1 UA4.2 Deployment status .............................................................................................45 3.2.1.1 BTS hardware configuration..................................................................................... 45 3.2.1.2 UA4.2 Carrier & ATM Deployment Status ................................................................ 45 3.2.1.3 Network HSDPA Activation Status ........................................................................... 45 3.2.2 UA4.2 to UA5.0 Cell Topology evolution.......................................................................46 3.2.2.1 UA4.2 Cell Topologies.............................................................................................. 46 3.2.2.2 HSxPA/ R99 deployed in 1 Shared Frequency ........................................................ 47 3.2.2.3 HSxPA and R99 deployed in 2 Dedicated Carriers.................................................. 48 3.2.2.4 Mixed HSDPA/ R99 shared carrier and R6 HSxPA dedicated carrier ..................... 49 3.2.2.5 Mixed HSDPA/ R99 shared carrier and HSxPA/ R99 shared carrier ....................... 50 3.2.2.6 Dedicated R99 carrier and HSxPA/ R99 shared carrier........................................... 51 3.2.3 UA4.2 to UA5.0 Carrier Deployment Recommendations..............................................52 3.2.3.1 HSDPA Deployment scenarios Evolution................................................................. 52 3.2.3.2 Dedicated HSXPA carrier inside mono-carrier HSXPA area deployment choices .. 53 3.2.3.3 STSR2 versus STSR 1+1......................................................................................... 55 3.2.3.4 UMTS 2100MHz versus UMTS 900MHz.................................................................. 56

3.3 HSXPA RESOURCES ..............................................................................................................57

3.3.1 HSxPA activation ..........................................................................................................57 3.3.2 HSDPA ..........................................................................................................................58 3.3.2.1 OVSF Codes ............................................................................................................ 58 3.3.2.2 Power........................................................................................................................ 69 3.3.2.3 HSDPA Channels & CQI .......................................................................................... 69 3.3.3 HSUPA ..........................................................................................................................81 3.3.3.1 UL load management ............................................................................................... 81 3.3.3.2 Scheduling ................................................................................................................ 85 3.3.3.3 DL power management ............................................................................................ 92

3.4 UE CATEGORIES ....................................................................................................................95

3.4.1 HSDPA ..........................................................................................................................95 3.4.2 HSUPA ..........................................................................................................................99




3.5 CALL MANAGEMENT..............................................................................................................100

3.5.1 Multi-carrier management ...........................................................................................101 3.5.1.1 Overview................................................................................................................. 101 3.5.1.2 RRC Traffic Segmentation...................................................................................... 103 3.5.1.3 IMCTA..................................................................................................................... 107 3.5.2 HSxPA CAC ................................................................................................................108 3.5.2.1 RAB matching......................................................................................................... 108 3.5.2.2 Admission phase .................................................................................................... 108 3.5.2.3 HSPA to DCH fallback............................................................................................ 110 3.5.3 Supported Transitions regarding HSxPA Bearers ......................................................113 3.5.3.1 Supported transition regarding HSDPA Bearers .................................................... 113 3.5.3.2 Supported transition regarding HSUPA Bearers .................................................... 114 3.5.3.3 RLC Reconfiguration procedure............................................................................. 116 3.5.4 Multi-RAB Handling.....................................................................................................120 3.5.4.1 Multi-RAB Handling on HSDPA.............................................................................. 120 3.5.4.2 Multi-RAB Handling on HSUPA.............................................................................. 126 3.5.5 Call Setup (Dataflow) ..................................................................................................127 3.5.5.1 Initial connection phase: ......................................................................................... 127 3.5.5.2 RAB allocation phase: ............................................................................................ 128 3.5.6 Call Release (Dataflow) ..............................................................................................130 3.5.6.1 Iu release case ....................................................................................................... 130 3.5.6.2 RAB release case................................................................................................... 130

4 HSXPA CONFIGURATION ................................ .......................................................................132

4.1 RAN MODEL AND PARAMETERS ............................................................................................132

4.1.1 HSDPA ........................................................................................................................132 4.1.1.1 RRM Subtree Parameters ...................................................................................... 132 4.1.1.2 FddCell subtree Parameters .................................................................................. 142 4.1.1.3 Bts Subtree Parameters ......................................................................................... 143 4.1.2 HSUPA ........................................................................................................................145 4.1.2.1 RRM Subtree Parameters ...................................................................................... 145 4.1.2.2 FDDCell Subtree Parameters................................................................................. 152 4.1.2.3 BTS Subtree Parameters ....................................................................................... 152

4.2 HSXPA ACTIVATION .............................................................................................................154

6 HSXPA SPECIFIC FEATURES & IMPACT ON EXISTING ALGORI THMS.............................156

6.1 RRM ALGORITHMS ...............................................................................................................156

6.1.1 Always On ...................................................................................................................156 6.1.1.1 Mechanism ............................................................................................................. 156 6.1.1.2 New RRC states ..................................................................................................... 156 6.1.1.3 Activation & ModeS ................................................................................................ 158 6.1.1.4 Parameters Settings and Recommendations......................................................... 167 6.1.2 Irm Scheduling Downgrade/Upgrade Interworking .....................................................169 6.1.3 iRM Cac/iRM Pre-Emption Interworking .....................................................................169 6.1.4 RB Adaptation Interworking ........................................................................................170

6.2 MOBILITY PROCEDURES........................................................................................................170

6.2.1 Intra-Frequency Mobility for HSxPA............................................................................171 6.2.1.1 Mobility of Associated DCH.................................................................................... 171 6.2.1.2 Mobility of HS-DSCH .............................................................................................. 171 6.2.1.3 Mobility of E-DPCH................................................................................................. 172 6.2.1.4 Full Event SHO setting for HSxPA ......................................................................... 174 6.2.1.5 Intra-frequency mobility over Iur ............................................................................. 175 6.2.2 Compressed Mode while in HSxPA ............................................................................178 6.2.2.1 Compressed Mode in MAC-hs ............................................................................... 178 6.2.2.2 Compressed Mode in MAC-e ................................................................................. 181




6.2.3 Inter-Frequency and Inter-System HHO for HSxPA ...................................................181 6.2.3.1 Inter-Frequency Mobility for HSxPA ....................................................................... 182 6.2.3.2 Inter-System Mobility for HSxPA ............................................................................ 185 6.2.4 U-Plane Traffic Handling .............................................................................................186 6.2.5 Example of Inter-Frequency and Inter-System scenario ............................................187

6.3 POWER MANAGEMENT ..........................................................................................................188

6.3.1 Introduction..................................................................................................................188 6.3.2 Flexible power management feature...........................................................................188 6.3.2.1 Aim.......................................................................................................................... 188 6.3.2.2 Power allocation ..................................................................................................... 188 6.3.2.3 Power measurements............................................................................................. 192 6.3.2.4 HSDPA power distribution ...................................................................................... 195 6.3.2.5 HS-DSCH power management .............................................................................. 197 6.3.2.6 First transmission ................................................................................................... 198 6.3.2.7 Retransmission....................................................................................................... 204 6.3.2.8 Multi-users per TTI ................................................................................................. 206 6.3.3 HS-SCCH power control feature .................................................................................206 6.3.4 Parameters Settings and Recommendations .............................................................207

6.4 OTHER FEATURES ................................................................................................................210

6.4.1 HSDPA and E-DCH Service Indicator (32520) ...........................................................210 6.4.2 HSDPA Performance Enhancement (29819) .............................................................211

6.5 TRANSPORT .........................................................................................................................212

6.5.1 IUB interface................................................................................................................212 6.5.1.1 iub deployment cases............................................................................................. 212 6.5.1.2 IUB bandwidth ........................................................................................................ 214 6.5.1.3 IMA and/or multi-pcm on iub................................................................................... 215 6.5.1.4 ATM priority management ...................................................................................... 218 6.5.1.5 AAL2 required services .......................................................................................... 220 6.5.2 Iu User Traffic Conformance .......................................................................................220 6.5.2.1 Feature applicable .................................................................................................. 220 6.5.2.2 Algorithm................................................................................................................. 221 6.5.2.3 Parameters ............................................................................................................. 222 6.5.2.4 Feature Behaviour .................................................................................................. 224 6.5.3 Iub Bandwidth Limitation .............................................................................................224 6.5.3.1 Why this feature is needed?................................................................................... 224 6.5.3.2 Feature Description ................................................................................................ 226 6.5.3.3 Case of Drift Iur ...................................................................................................... 228 6.5.3.4 Parameters Settings and Recommendations......................................................... 228

8 HSXPA CAPACITY ASPECTS ............................. ....................................................................235

8.1 CEM CAPACITY....................................................................................................................235

8.1.1 Product limits...............................................................................................................235 8.1.1.1 H-BBU..................................................................................................................... 235 8.1.1.2 E-BBU..................................................................................................................... 237 8.1.1.3 D-BBU..................................................................................................................... 240

8.2 RNC CAPACITY ....................................................................................................................240

9 PRODUCT RECOMMENDATIONS...........................................................................................241

9.1 HSXPA COMPATIBILITY WITH UTRAN NETWORK ELEMENTS ..................................................241

9.1.1 RNC.............................................................................................................................241 9.1.2 HSDPA & E-DCH support over NodeB.......................................................................242 9.1.2.1 HSxPA support according to NodeB cabinet.......................................................... 242 9.1.2.2 HSxPA support according to RF configurations..................................................... 243

9.2 HSXPA COMPATIBILITY WITH MODULES .................................................................................245




9.2.1 RNC.............................................................................................................................245 9.2.2 BTS .............................................................................................................................245 9.2.2.1 HSxPA Ready modules .......................................................................................... 245 9.2.2.2 BTS Modules Mixity................................................................................................ 245 9.2.2.3 BTS Minimal Configuration for Hsdpa .................................................................... 246 9.2.2.4 BTS Minimal Configuration for HsUpa ................................................................... 246

9.3 HSXPA SYSTEM IMPACT..................................................................................................247

9.3.1 RNC functions .............................................................................................................247 9.3.1.1 RNC Ressources Management.............................................................................. 247 9.3.2 BTS functions ..............................................................................................................247 9.3.2.1 CEM and BBU Roles .............................................................................................. 247 9.3.2.2 BTS HSxPA System Limits..................................................................................... 248 9.3.2.3 BBU Allocation........................................................................................................ 249 9.3.2.4 BTS reliability.......................................................................................................... 253 9.3.2.5 MCPA Power .......................................................................................................... 253

9.4 HSXPA AND UTRAN INTERFACES........................................................................................253

9.4.1 Radio Interface............................................................................................................253 9.4.2 IuB ...............................................................................................................................254 9.4.2.1 Physical Interfaces Impacts.................................................................................... 254 9.4.2.2 ATM Layer .............................................................................................................. 254 9.4.3 Iu-CS ...........................................................................................................................255 9.4.4 Iu-PS ...........................................................................................................................255 9.4.5 Iu-R..............................................................................................................................255 9.4.6 Iu-PC ...........................................................................................................................255

10 ABBREVIATIONS AND DEFINITIONS...................... ...............................................................257

10.1 ABBREVIATIONS ....................................................................................................................257

10.2 DEFINITIONS.........................................................................................................................260

11 APPENDIXES ............................................................................................................................261

11.1 APPENDIX A: OPTIMIZED CQI MAPPING TABLES WITH 336 MAC-D PDU SIZE ...........................261

11.2 APPENDIX B: OPTIMIZED CQI MAPPING TABLES WITH 656 MAC-D PDU SIZE ...........................266

11.3 APPENDIX C: CQI MAPPING TABLES FOR UE CAT 7, 8, 9 AND 10 WITH 336 MAC-D PDU SIZE ..271

11.4 APPENDIX D: CQI MAPPING TABLES FOR UE CAT 7, 8, 9 AND 10 WITH 656 MAC-D PDU SIZE ..273




TABLES

Table 1: HSUPA / HSDPA comparison 17 Table 2: Number of processes per UE category 22 Table 3: RV coding for 16QAM 23 Table 4: RV coding for QPSK 23 Table 5: RV update table in the MIR case (Trv[i]) 26 Table 6: RV update table in the PIR case (Trv[i]) 26 Table 7: RV updates tables when harqType set to Dynamic Redundancy 27 Table 8: E-DPCCH slot formats 38 Table 9: E-DPCCH slot formats 38 Table 10: E-DPCCH power offset index vs. amplitude 39 Table 11: Relative grant information (E-RGCH) 41 Table 12: ACK/NACK information (E-HICH) 42 Table 13: Transitions to HSxPA/R99 deployed in shared carrier 47 Table 14: Transitions to HSxPA & R99 deployed in 2 dedicated carriers 48 Table 15: Transitions to mixed HSDPA/R99 shared carrier & R6 HSxPA dedicated carrier 49 Table 16: Transitions to mixed HSDPA/R99 shared carrier & R6 HSxPA dedicated carrier 50 Table 17: Transitions to mixed HSDPA/R99 shared carrier & R99 dedicated carrier 51 Table 18: R99 & HSxPA on 2 dedicated carriers hot-spots pros/cons 54 Table 19: Mixed HSDPA/ R99 shared carrier and R6 HSxPA dedicated carrier 54 Table 20: Reference Signaled E-TFCI 87 Table 21: referenceEtfci & referenceEtfciPowerOffset 88 Table 22: Grant Index values 89 Table 23: HSDPA UE categories (3GPP TS25.306) 95 Table 24: CQI mapping table update for UE cat 9 97 Table 25: HSUPA UE categories (3GPP TS25.306) 99 Table 26: HSDPA RB Configuration and system behavior 100 Table 27: HSUPA RB Configuration and system behavior 101 Table 28: Summary of RNC detection regarding RRC Traffic Segmentation 105 Table 29: RRC Connection Request and suitable layer 106 Table 30: iMCTA Priority Table 108 Table 31: Always-on timer usage (URA/Cell_PCH state s not used) 165 Table 32: Always-on timer usage (URA/Cell_PCH states are used) 166 Table 33: SHO Event Recommended Settings Summary 175 Table 34: HHO Event Recommended Settings Summary 185 Table 35: CQI management up to CQI 15 (all UE categories) 202 Table 36: CQI management between CQI 15 and 22 (UE categories 1 to 10) 202 Table 37: CQI management for CQI 16 (UE categories 11 to 12) 203 Table 38: CQI management between CQI 23 and 25 (UE categories 7 to 10) 203 Table 39: CQI management for CQI 26 to 27 (UE category 9) 203 Table 40: CQI management for CQI 26 to 30 (UE category 10) 204 Table 41: maximum Transport Block Size used according to UE category for PDU 336 bits 204 Table 42: HS-SCCH power offset table according the reported CQI 207 Table 43: Necessary throughput per HSDPA UE category 214 Table 44: Iub bandwidth per number of E1 links 214 Table 45: Traffic mapping of ATM Service Categories 218 Table 46: H-BBU limitations 235 Table 47: H-BBU capacity details 236 Table 48: E-BBU limitations 238 Table 50: HSxPA support over NodeB in UA05.0 242 Table 51: BBU functions distribution 248 Table 52: CQI mapping table update for UE cat 1 to 6 262 Table 53: CQI mapping table update for UE cat 7 and 8 263 Table 54: CQI mapping table update for UE cat 9 263 Table 55: CQI mapping table update for UE cat 10 264 Table 56: CQI mapping table update for UE cat 11 and 12 265




Table 57: CQI mapping table update for UE cat 1 to 6 267 Table 58: CQI mapping table update for UE cat 7 and 8 268 Table 59: CQI mapping table update for UE cat 9 269 Table 60: CQI mapping table update for UE cat 10 270 Table 61: CQI mapping table update for UE cat 11 and 12 270 Table 62: CQI mapping table update for UE cat 7 and 8 271 Table 63: CQI mapping table update for UE cat 9 272 Table 64: CQI mapping table update for UE cat 10 273 Table 65: CQI mapping table update for UE cat 7 and 8 274 Table 66: CQI mapping table update for UE cat 9 274 Table 67: CQI mapping table update for UE cat 10 275




FIGURES

Figure 1: R99 principle ...................................................................................................................................... 15 Figure 2: HSDPA principle ................................................................................................................................ 15 Figure 3: HSDPA layer2/layer1 flows .............................................................................................................. 16 Figure 4: Mac-hs entity on UTRAN side ......................................................................................................... 16 Figure 5: Protocol Architecture of E-DCH....................................................................................................... 18 Figure 6: UE side MAC architecture ................................................................................................................ 18 Figure 7: Transport channel configuration ...................................................................................................... 19 Figure 8: HSDPA channels and associated R99 channels .......................................................................... 20 Figure 9: Example of AMC: Throughput versus Ior/Ioc (radio condition) ................................................... 21 Figure 10: RV parameters assignment algorithm .......................................................................................... 24 Figure 11: ACK/NACK/DTX management for HARQ processes ................................................................ 25 Figure 12: Dynamic selection of HARQ type.................................................................................................. 28 Figure 13: Mac-hs scheduler overview ........................................................................................................... 30 Figure 14: HSUPA channels and associated R99 channels........................................................................ 36 Figure 15: E-DPCCH / E-DPDCH frame structure ........................................................................................ 37 Figure 16: E-DPDCH/E-DPCCH multiplexing on I/Q .................................................................................... 38 Figure 17: Uplink physical channels multiplexing .......................................................................................... 39 Figure 18: E-AGCH frame structure ................................................................................................................ 40 Figure 19: E-HICH frame structure .................................................................................................................. 41 Figure 20: Mono frequency HSDPA area evolution ...................................................................................... 52 Figure 21: Dedicated carrier inside mono frequency HSDPA area evolution ........................................... 53 Figure 22: Dedicated HSDPA carrier area evolution .................................................................................... 53 Figure 23: Example of OVSF tree usage with HSDPA in U4.2 ................................................................... 58 Figure 24: R99, HSDPA & HSUPA Common Channels codes allocation ................................................. 59 Figure 25: Illustration of the HS-PDSCH re-allocation blocking .................................................................. 63 Figure 26: Timing relationship at NodeB between physical channels ........................................................ 70 Figure 27: HS-SCCH structure......................................................................................................................... 70 Figure 28: HS-PDSCH structure ...................................................................................................................... 71 Figure 29: HS-DPCCH structure ...................................................................................................................... 71 Figure 30: CQI Processing................................................................................................................................ 73 Figure 31: CQI adjustment to BLER algorithm............................................................................................... 77 Figure 32: HS-DPCCH synchronization algorithm ........................................................................................ 79 Figure 33: Noise Rise vs. UL Load .................................................................................................................. 82 Figure 34: Example of uplink load (thermal noise/R99/E-DCH) .................................................................. 82 Figure 35: 3GPP Transport Block table (TTI 10 ms)..................................................................................... 86 Figure 36: E-DPDCH Power vs. Transport Block Size ................................................................................. 86 Figure 37: Power allocation at RNC level ....................................................................................................... 92 Figure 38: Padding bits in the Mac-hs PDU ................................................................................................... 96 Figure 39: Example of multi-layer structure.................................................................................................. 102 Figure 40: HSxPA Call setup / initial connection (Cell_DCH) .................................................................... 127 Figure 41: HSDPA Call setup / RAB allocation phase (call establishment done on DCH) ................... 128 Figure 42: HSUPA Call setup / RAB allocation phase (call establishment done on DCH) ................... 129 Figure 43: Call release (RAB release case) ................................................................................................. 131 Figure 44: AO state transitions ....................................................................................................................... 158 Figure 45: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates ≠ none).......... 162 Figure 46: Always-on for HSDPA/E-DCH (degraded2AlwaysOn mode, PchRrcStates = none) ......... 163 Figure 47: Always-on for HSDPA/E-DCH (releaseOnly mode) ................................................................. 164 Figure 48: HS-DSCH link is deleted and re-established on new primary (nominal case) ..................... 172 Figure 49: E-DPCH link is deleted and re-established on new primary (nominal case) ........................ 173 Figure 50: Example of Inter-frequency and Inter-System scenario .......................................................... 187 Figure 51: Power allocation at RNC level ..................................................................................................... 189 Figure 52: Physical shared channel reconfiguration message .................................................................. 191 Figure 53: Power allocation at NodeB level ................................................................................................. 191 Figure 54: Transmitted carrier power (on the left) and averaged HSDPA power (on the right) ........... 193 Figure 55: Common measurement ................................................................................................................ 194




Figure 56: Power measurement process...................................................................................................... 195 Figure 57: Power distribution between HS-DSCH and HS-SCCH channels........................................... 196 Figure 58: measurementPowerOffset transmission .................................................................................... 197 Figure 59: HS-DSCH power management for 1st transmission................................................................ 199 Figure 60: Mac-hs transport block adaptation according to the number of Mac-d PDU to transmit .... 201 Figure 61: Remaining power for multi-users per TTI scheduling .............................................................. 206 Figure 62: HS-SCCH power control overview.............................................................................................. 207 Figure 63: VCCs end-to-end........................................................................................................................... 212 Figure 64: VP with ATM priority shaped ....................................................................................................... 213 Figure 65: VP with ATM priority, not shaped................................................................................................ 213 Figure 66: VP shaping activated in the RNC................................................................................................ 214 Figure 67: Iub Bandwidth repartition.............................................................................................................. 215 Figure 68: IMA framing and ICP cell distribution on a link group .............................................................. 216 Figure 69: Multi-PCM with IMA....................................................................................................................... 217 Figure 70: Multi-PCM+ 1 IMA Group ............................................................................................................. 218 Figure 71: Transport topology with ATM Priority ......................................................................................... 219 Figure 72: Transport topology without ATM Priority.................................................................................... 219 Figure 73: AAL2 Connections UA4.2 vs. UA5.0 .......................................................................................... 220 Figure 74: Traffic Conformance Algorithm.................................................................................................... 222 Figure 75: Estimated Cell Rate vs. Real Cell Rate (example)................................................................... 224 Figure 76: discard and backpressure thresholds......................................................................................... 226 Figure 77: example of traffic regulation with backpressure........................................................................ 228 Figure 78: feature behaviour on Iur ............................................................................................................... 228 Figure 79: BBU HW high level structure ....................................................................................................... 238 Figure 89: 6 sectors x 1 carrier : BBUs allocation on iCEM 128 ............................................................... 250




1 INTRODUCTION

1.1 OBJECT

The objective of this document is to describe from an engineering point of view the HSDPA & E-DCH (HSUPA) system.

This includes a system description, configuration aspect and engineering recommendations.

1.2 SCOPE OF THIS DOCUMENT

The following features are described in the document:

Feature Id Feature description Section

UA4.2 features

27942 Always-on On HSDPA §6.1.1

27936 HSDPA Intra-frequency Mobility §6.2.1

27937 HSDPA Alarm Mobility - inter RAT: 3G to 2G only and blind §6.2.3.2

27943 Iub Bandwidth Limitation Handling §6.5.3

27930 HSDPA Service §3.5

27931 HSDPA Flexible resources Mgt §6.3.2

27932 HSDPA Step 1 § 3

27939 HS-SCCH Power Control §6.3.3

27940 H-BBU Pool Across Sectors § 9

27941 Node-B Module Operation For HSDPA § 9

27945 HSDPA Radio Bearer §3.5.3

UA5.0 features

29840 E-DCH Step1 (HSUPA) 3

30741 Multi-Services Handling On HSUPA 3.5.4

29809 UE Cat 7 & 8 Support 3.4.1

29813 UE Cat 9 & 10 Support - Demo 3.4.1

29802 Inter-frequency Inter-system HSDPA HHO 6.2.3

29817 HSDPA over Iur 6.2.1.4

29797 Multi-RAB Handling on HSDPA 3.5.4




32602 HSDPA to DCH fallback 3.5.2.3

29801 H-BBU Capacity Enhancement 8.1.1.1

29800 Dynamic DL Code Tree Mgt For HSDPA 3.3.2.1

29807 Mac-hs scheduler improvement 3.1.1.4

29798 Compressed Mode in MAC-hs 6.2.2.1

32520 HSDPA and E-DCH Service Indicator 6.4.1

29819 HSDPA Performance Enhancement 6.4.2

32309 2 carriers in HSDPA §9.1

Restriction: Pico/Micro NodeB

The Pico/Micro NodeB product is out of scope of this document, thus all eng’g information, algorithms description and parameters values provided in this document are strictly related to “standard” Alcatel-Lucent NodeB products.

See [R16] for details related to HSxPA implementation in Pico & Micro NodeB.

1.3 NOMENCLATURE

• The parameter names are written in bold italic .

• The objects names are written in bold .

• The parameters properties are presented as follow:

Parameter Object Range & Unit User Class

Granularity

Value

• The protocol messages are written in CAPITAL LETTERS.

• The Information Elements (IE) contained in the protocol messages are written the following way: TPC_DL_Step_Size.

• The datafill rules are presented as the following:

Rule:

• The system restrictions are presented as the following:




Restriction:

• The engineering recommendations on parameter value are presented as the following:

Engineering Recommendation:

• The difference between Release N and Release N-1 are presented as the following:

UA5.0-UA5.1 Delta:

• Some parameters values can not be provided in this document; in that case, the following abbreviations are used:

o N.A.: Not Applicable.

o N.S.: Not Significant.

o O.D.: Operator Dependant (depends on operator network specific configuration. Example: addressing parameters).




2 RELATED DOCUMENTS

2.1 REFERENCE DOCUMENTS

[R01] UMT/DCL/DD/0020 UTRAN Parameters User Guide

[R02] 3GPP TS 25.308 UTRA High Speed Downlink Packet Access (HSPDA); Overall description; Stage 2

[R03] 3GPP TS 34.108 Common Test Environments for User Equipment (UE) Conformance Testing

[R04] 3GPP TS 25.212 Multiplexing and channel coding (Release6)

[R05] 3GPP TS 25.214 Physical layer procedures (FDD)

[R06] UMT/IRC/APP/0164 Iub transport Engineering Guide

[R07] NN-20500-061 HSxPA Feature Activation Procedure

[R08] UMT/SYS/DD/013319 HSDPA System Specification

[R09] UMT/SYS/DD/018827 E-DCH System Specification

[R10] UMT/PLM/INF/018122 CEM Capacity

[R11] 3GPP TS 23.107 Quality of Service (QoS) concept and architecture

[R12] 3GPP TS 25.306 UE Radio Access capabilities definition

[R13] 3GPP TS 25.321 Medium Access Control protocol specification

[R14] 3GPP TS25.213 Spreading and modulation (FDD)

[R15] UMT/PLM/INF/004862 UMTS RNC Capacity Roadmap

[R16] UMT/BTS/INF/016135 Micro NodeB & 9314 Pico NodeB – Feature Planning Guide

[R17] UMT/IRC/APP/007147 UMTS BTS Product Engineering Information




3 HSXPA OVERVIEW

3.1 SYSTEM OVERVIEW

HSDPA

3GPP has standardized HSDPA in Release 5 [R02] in order to increase maximum user throughput for downlink packet data (streaming, interactive and background traffic classes) and decrease downlink packet transmission delay. This Release 5 is fully compatible with the previous Release 99 (R99).

In R99, data are transmitted on a dedicated channel with a given user throughput and a downlink transmitted power controlled according to the radio conditions:

PowerPowerControlControl

Data Power

Unused Power Data

Unused

Same Throughput

Figure 1: R99 principle

In HSDPA, data are transmitted on a shared channel by using all the available power and by controlling the downlink user throughput according to the radio conditions:

RateRateAdaptationAdaptation 100% Power

100%

Figure 2: HSDPA principle

Typically, a user in good radio conditions will receive his data with a high bit rate whereas a user in bad radio conditions will receive his data with a lower bit rate.

The efficiency of this rate adaptation is due to a new MAC entity, the Mac-hs layer, located in the NodeB (see the two following figures), near the physical channel, which




allows a high reactivity in the resource allocation according to the RF conditions changes. This Mac-hs layer manages the scheduling of users and the retransmissions of packets.

HS-DSCHAssociated

UplinkSignaling

AssociatedDownlinkSignaling

DCCH DTCHDTCHMAC Control MAC ControlCCCH CTCHBCCHPCCHMAC Control

RRC (RNC)RRC (RNC)

RLC (RNC)RLC (RNC)

HS-PDSCH

FACH

S-CCPCH

FACH

S-CCPCH

RACH

PRACH

RACH

PRACH

DSCH

PDSCH

DSCH

PDSCH

DCH

DPCH

CPCH

PCPCH

CPCH

PCPCH

PCH

S-CCPCH

PCHPCH

S-CCPCHHS-DPCCHHS-SCCH

MAC-c/sh(C-RNC)

MAC-c/sh(C-RNC)

DCH

DPDCH/DPCCH

R99 L1: Channel Coding / Multiplexing (NodeB)R99 L1: Channel Coding / Multiplexing (NodeB)R5 L1: HSDPA (NodeB)R5 L1: HSDPA (NodeB)

MAC-d(S-RNC)

MAC-hs(NodeB)

MAC-hs(NodeB)

Figure 3: HSDPA layer2/layer1 flows

Figure 4: Mac-hs entity on UTRAN side




HSDPA benefits are based on:

• New transport and physical channels.

• Fast link adaptation.

• Fast retransmission mechanism (HARQ).

• Fast scheduling.

HSUPA

3GPP has standardized HSUPA (official name is E-DCH) in release 6 in order to increase maximum user coverage and throughput for uplink packet data and decrease uplink packet transmission delay. This Release 6 is fully compatible with the previous Releases (R99 and R5).

HSUPA uses the same new techniques of HSDPA:

• Fast scheduling

• Fast retransmission mechanism (HARQ)

Macrodiv TTI Modulation

Channel coding

Power control

HARQ Fast

scheduling Fast link

adaptation

HSDPA Not

supported 2 ms only

QPSK and 16QAM

Turbo No Supported Supported Supported

HSUPA Supported 2 ms, 10 ms

BPSK and QPSK

Turbo Yes Supported Supported

but less reactive

Supported but less reactive

Table 1: HSUPA / HSDPA comparison

The physical layer is similar to R99:

• BPSK modulation only, QPSK is used when there is more than one E-DPDCH physical channel (SF≤4).

• Turbo coding

• Spreading on a separate OVSF code and scrambling together with other physical channels.

• HSUPA is power controlled as for R99. Indeed, HSUPA channels have a power offset relative to DPCCH.




PHY PHY

EDCH FP EDCH FP

Iub UE NodeB Uu

DCCH DTCH

TNL TNL

DTCH DCCH

MAC-e

SRNC

MAC-d

MAC-e

MAC-d

MAC-es / MAC-e

MAC-es

Iur

TNL TNL

DRNC

Figure 5: Protocol Architecture of E-DCH

Associated

D ownlink

S ignalling

E-DCH

MAC-d

FACH RACH

DCCH DTCH DTCH

DSCH DCH DCH

MAC Contro l

USCH ( TDD only )

CPCH ( FDD only )

CTCH BCCH CCCH SHCCH ( TDD only )

PCCH

PCH FACH

MAC-c/sh

USCH ( TDD only )

DSCH

MAC-hs

HS-DSCH

Assoc iated

U plink

S ignalling

A ssoc ia ted

D ownlink

S igna lling

MAC-es /

MAC-e

Associated

U plink

S ignalling

Figure 6: UE side MAC architecture

3.1.1 HSDPA

3.1.1.1 TRANSPORT AND PHYSICAL CHANNELS

In R99, downlink data are sent on a DCH (Dedicated CHannel) which is mapped on the DPDCH (Dedicated Physical Data CHannel). In HSDPA, downlink data are sent on a HS-DSCH (High Speed – Downlink Shared CHannel) which is mapped on one or several HS-PDSCH (High Speed – Physical Downlink Shared CHannel). Users are multiplexed on the HS-DSCH channel in time and code. Transmission is based on shorter sub-frames of 2ms (TTI) instead of 10ms in R99.




In downlink, the HS-PDSCH are transmitted with the HS-SCCH (High Speed – Shared Control CHannel) channel. This channel is broadcasted over the cell but his information concerned only the user who has to receive the HS-PDSCH. The HS-SCCH allows the user to know if the HS-PDSCH is for him and to decode them correctly.

Radio conditions information and acknowledgement are reported by the UE to the NodeB through the HS-DPCCH channel. This channel allows the NodeB to adapt the downlink data rate and to manage retransmission process. The HS-DPCCH is divided in two parts. The first one is the Channel Quality Indicator (CQI) which is a value between 1 and 30 characterizing the radio conditions (1 = bad radio conditions and 30 = good radio conditions). The second one is the acknowledgement information: if data are well received by the UE, the UE sends to the NodeB an Ack, otherwise a Nack.

HS-DSCH channel is always associated to a DCH. This induces the following transport channel configuration for any UE established in HSDPA (see the following figure):

• One DCH handling the signaling in both UL and DL,

• One DCH transporting the UL traffic,

• One HS-DSCH for the DL traffic.

Figure 7: Transport channel configuration




The following figure summarizes the different channels needed for a HSDPA call:

NodeB

HSDPA UE

HS-PDSCH for data (I/B) trafficHS-PDSCH for data (I/B) traffic

HSDPA channelsHSDPA channels

HS-SCCH signaling part (UE id, …) associated to HS-PDSCHHS-SCCH signaling part (UE id, …) associated to HS-PDSCH

HS-DPCCH Feedback informationHS-DPCCH Feedback information

Associated DPCH for data, speech + SRB trafficAssociated DPCH for data, speech + SRB traffic

Figure 8: HSDPA channels and associated R99 channel s

In this release of HSDPA, several UE categories are supported (see section 3.4.1). As a consequence the following radio bearers are be supported:

• Interactive or background / UL:8 DL: [max bit rate for UE category x] / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH (see below)

• Interactive or background / UL:32 DL: [max bit rate for UE category x] / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH




The maximum bit rate that can be achieved in the UL can be the bottleneck for the maximum bit rate achievable in the DL. For instance, excessive delay of RLC/TCP acknowledgements due to low bandwidth in the UL will limit the DL throughput, even if the RF conditions would allow more.

From UA04.2, the RB adaptation feature is supported. This feature dynamically adapts the UL bit rate to the amount of traffic carried over the RB. UL adaptation ranges from 8kbps up to 384kbps, but 8kbps is not recommended to be activated (configured as eligible). Therefore, although UL:8 DL:[max bit rate for UE categories 12 and 6] will be allocated by the RNC if UL:8 is explicitly requested in the RAB assignment, it is not recommended to do so, otherwise the user will experience low throughput in the DL.




3.1.1.2 FAST LINK ADAPTATION

Every TTI, Adaptive Modulation and Coding (AMC) is updated according to the radio conditions experienced by the UE and his category (see 3.4 “UE Categories” section). AMC (number of codes, code rate and modulation type) is chosen among 30 possibilities corresponding to one CQI in order to reach the maximum bit rate while guarantying a certain QoS (10% BLER for example). All UE categories have to support QPSK and 16QAM modulation except categories 11 and 12 which only support QPSK (16QAM modulation allowing higher bit rate). The following figure illustrates the AMC by showing the throughput versus the radio conditions (Ior/Ioc):

QPSK ¼QPSK ½QPSK ¾16QAM ½16QAM ¾

-20 -15 -10 -5 0 50

100

200

300

400

500

600

700

800

Ior/Ioc (dB)

Thr

ough

put (

kbps

)

AMC Illustration



-20 -15 -10 -5 0 50

100

200

300

400

500

600

700

800

Ior/Ioc (dB)

Thr

ough

put (

kbps

)

AMC Illustration

Figure 9: Example of AMC: Throughput versus Ior/Ioc (radio condition)

3.1.1.3 FAST RETRANSMISSION MECHANISM (HARQ)

The HARQ (Hybrid Automatic Repeat Query) is a retransmission mechanism which consists in:

• Retransmitting by the NodeB the data blocks not received or received with errors by the UE;

• Combining by the UE the transmission and the retransmissions in order to increase the probability to decode correctly the information.

3.1.1.3.1 NUMBER OF HARQ PROCESSES

There is an HARQ process assigned per transport block for all the transmissions. The number of processes per UE is limited and depends on its category. The number of processes per UE category is the one given in [R03]:




Ue Category 1 2 3 4 5 6 7 8 9 10 11 12

Number of HARQ Processes 2 2 3 3 6 6 6 6 6 6 3 6

Table 2: Number of processes per UE category

Once this number is reached, the UE should not be eligible by the scheduler for new transmissions unless one of them is reset (ACK reception, discard timer expiration, max number of retransmissions reached).

3.1.1.3.2 RV PARAMETERS

The IR (Incremental Redundancy) and modulation parameters necessary for the channel coding and modulation steps are: the r, s and b values. The r and s parameters (Redundancy Version or RV parameters) are used in the second rate matching stage, while the b parameter is used in the constellation rearrangement step (see [R04] for details):

• s is used to indicate whether the systematic bits (s=1) or the non-systematic bits (s=0) are prioritized in transmissions.

• r (range 0 to rmax-1) changes the initialization Rate Matching parameter value in order to modify the puncturing or repetition pattern.

• The b parameter can take 4 values (0 …3) and determines which operations are produced on the 4 bits of each symbol in 16QAM. This parameter is not used in QPSK and constitutes the 16QAM constellation rotation for averaging LLR at the turbo decoder input.

These three parameters are indicated to the UE by the Xrv value sent on the HS-SCCH (see section §3.3.2.3 "HSDPA Channels & CQI”). The coding tables of Xrv are given hereafter:




Xrv (Value) s r b

0 1 0 0

1 0 0 0

2 1 1 1

3 0 1 1

4 1 0 1

5 1 0 2

6 1 0 3

7 1 1 0

Table 3: RV coding for 16QAM

Xrv (Value) s r

0 1 0

1 0 0

2 1 1

3 0 1

4 1 2

5 0 2

6 1 3

7 0 3

Table 4: RV coding for QPSK

The determination of the s, r and b parameters will be based on the Xrv update, but not necessarily in the increasing order. The update indeed follows a predefined order stored in a table (called hereafter Trv). The only requirement to fill this table is that Trv[0] = 0 for QPSK, or Trv[0] = 0, 4, 5 or 6 for 16QAM (s = 1 and r = 0 must be the nominal configuration).

The rules to compute the Xrv parameters then are (see the following figure):

• For the first transmission, Xrv is initialized to Trv[0].

• Upon reception of a NACK, Xrv is assigned the next value in the table (once the last value of the table, Nmax, has been set, the next value should be the first one again).

• In case of no reception of ACK/NACK (DTX indication), the parameters must not be updated so that the same information not received by the UE should be




sent again (this ensure no systematic bits are lost, because all blocks may not be self-decodable).

New transmission ?Xrv = Trv[0]

k = 0

Y

N

DTX indication ? Xrv(n) = Xrv(n-1)Y

N

k = k + 1Xrv(n) = Trv[k mod Nmax]

Nmax = 1 (CC)= 4 (PIR - QPSK)= 6 (PIR – 16QAM)= 8 (MIR)

Figure 10: RV parameters assignment algorithm

An update table is defined per HARQ type as described in section 3.1.1.3.4

3.1.1.3.3 STATE OF HARQ PROCESSES

The following figure describes the different states of HARQ processes and possible actions related to these.




ACK/NACK/DTX ?

HARQ process assignedby the scheduler

Y

Update of RV parametersData transmission

Wait for ACK/NACK reception

Insertion of DTX indication

Reset HARQ processRemove Mac-d PDUUpdate structures

Nret = Nret +1

Nret > Nret_max ?

Wait for retransmission

NACK

DTX

N

WACK state

NACK/DTX state

ACK

Figure 11: ACK/NACK/DTX management for HARQ process es

Once a UE is scheduled, an HARQ process is assigned that may correspond to either a new Transport Block or a retransmission. The RV parameters are computed accordingly as described before (see §3.1.1.3.2 “RV Parameters” section) and data is transmitted. The HARQ process is then waiting for feedback information (ACK/NACK/DTX) and is set in the so-called “WACK state” (Waiting for Ack/Nack/DTX). The exact timing for reception of the feedback information must be computed thanks to the chip offset and relatively to the TTI corresponding to the transmission.

Upon reception of the feedback information, three behaviors occur:

• In case of an ACK, the HARQ process is reset and corresponding Mac-d PDUs are removed from memory. This HARQ process can now be used for a new transmission.

• In case of a NACK, the number of retransmissions must be incremented. If the maximum number of retransmissions is not reached, the HARQ process is set in the so-called “NACK state” and then inserted in the “NACK list” of HARQ processes.

• In case of a DTX indication, the same actions as for a NACK reception are done, except that a parameter must be updated to notify DTX detection (this




changes the RV parameter update, see §3.1.1.3.2 “RV Parameters” section). The process is then set in the “DTX state”.

The processes in the NACK or DTX state are just waiting for being re-scheduled for a new retransmission.

3.1.1.3.4 CHOICE OF THE HARQ TYPE

A configurable parameter (CC/PIR/MIR) indicates the possibility of switching between Chase Combining, a Partial IR or a mix between Partial and Full IR sequence. It implies that 3 different tables must be stored (see below), chosen accordingly:

• The Chase Combining option corresponds to the first redundancy version always applied for all (re)transmissions.

• The PIR indicates that for all redundancy versions, the systematic bits must be transmitted (blocks are self-decodable). Only the RV with s = 1 must be taken into account.

• The MIR corresponds to a sequence where both systematic and non-systematic bits can be punctured. All possible redundancy versions are assumed and it corresponds to default version.

Each HARQ type is characterized by its update table Trv (see tables below)

i 1 2 3 4 5 6 7 8

Xrv(QPSK) 0 2 5 6 1 3 4 7

Xrv(16QAM) 6 2 1 5 0 3 4 7

Table 5: RV update table in the MIR case (Trv[i])

i 1 2 3 4 5 6

Xrv(QPSK) 0 2 4 6

Xrv(16QAM) 6 2 5 0 4 7

Table 6: RV update table in the PIR case (Trv[i])

The choice of the HARQ type (CC, MIR or PIR) is defined for all the retransmissions by setting the parameter harqType (= 1 for MIR, = 2 for PIR and = 3 for CC). When the HARQ type is selected, specific RV tables are used, one for QPSK and another one for 16QAM (as explained in the previous paragraphs).

With the feature “HSDPA Performance Enhancement – Optimal Redundancy Version for HARQ retransmission” (29819), a fourth HARQ type can be selected: the Dynamic




Redundancy noted DR (harqType = 4). This value is introduced to indicate that dynamic RV selection must be performed.

The aim of this sub-feature is to optimize the redundancy version (RV) of the retransmissions by dynamically selecting the most efficient HARQ type (and his corresponding RV table presented below) according to several parameters: UE category, number of HARQ processes and applied AMC for first transmission.

The different HARQ types (each one being associated to a restricted redundancy version set) that can be selected are:

� Chase Combining (CC): same redundancy version than first transmission is applied (QPSK only).

RV = 0.

� CC + Constellation rearrangement (CC+CoRe): same puncturing pattern is applied but constellation rotation is performed (16QAM only).

RV ∈ [0; 4; 5; 6].

� Partial Incremental Redundancy (PIR): systematic bits are prioritized. RV ∈ [0; 2; 4; 6] in QPSK and [0; 2; 4; 5; 6; 7] in 16QAM.

� Full Incremental Redundancy (FIR): parity bits are prioritized. RV ∈ [1; 3; 5; 7] in QPSK and [1; 3] in 16QAM

Table 7: RV updates tables when harqType set to Dyn amic Redundancy

The principle is that incremental redundancy is only selected when required, i.e. as soon as punctured bits by the 2nd Rate Matching stage AND total number of softbits per HARQ process the UE can handle are higher than the number of transmitted bits. Otherwise, chase combining is sufficient. In case of IR, it is only necessary to puncture systematic bits (FIR) in case it is not possible to transmit all parity bits punctured by the 2nd RM stage in the first retransmission.

More in detail, during the Rate Matching step, following variables are computed :

• NDATA: total number of radio bits, i.e. the number of HS-PDSCH codes times the modulation order (2 or 4) times 960 bits.

• NIR: total number of softbits per HARQ process the UE can handle. It only depends on the UE category and the number of allocated HARQ processes.

• NSYS: number of systematic bits (not equal to transport block size).

• NP1 and NP2: number of parity bits 1 and 2 after 1st RM step.




• NRM1 = NSYS + NP1 + NP2

• NPUNC2 = NRM1 - NDATA: number of bits punctured by 2nd RM stage.

These values are then used to select the right HARQ type as explained by the following figure:

Figure 12: Dynamic selection of HARQ type

Note: As the RV of the 1st transmission is identical whatever the HARQ type is, previous variables should then be stored during the rate matching of the first transmission. The HARQ Type only needs to be determined when 1st retransmission occurs.

Parameters Settings:

Parameter harqType Object HsdpaConf Range & Unit [mirType, pirType, ccType, drType, MIRWithPowerAdaptation,

PIRWithPowerAdaptation, CCWithPowerAdaptation, DRWithPowerAdaptation]

User Customer Class 3

Granularity BTSCell

Value DRWithPowerAdaptation




Engineering Recommendation: harqType

The harqType has to be set to drType in order to activate the Optimal Redundancy Version for HARQ retransmission.

3.1.1.4 FAST SCHEDULING

3.1.1.4.1 PRINCIPLES

The aim of the Mac-hs scheduler is to optimize the radio resources occupancy between users. Every TTI, it must then select Queue IDs for which data is going to be transmitted and the amount of corresponding Mac-d PDUs to transmit.

The scheduler first receives as input every TTI the number of codes available and the remaining power for HS-PDSCH and HS-SCCH (see “Power Management” section). The received ACK/NACK and CQI must also be provided to the scheduler when available. Thanks to this information, UE capabilities, configuration parameters provided by the RNC and taking into account the previously scheduled data, the scheduler can select the sub flows of the users to schedule in order to optimally use available resources. The main concepts of the scheduler are:

• Retransmissions are of higher priority than new transmissions and should be scheduled first.

• The Queue ID (QId) is chosen according the Scheduling Priority Indicator (SPI or CmCH-PI) and the radio condition based on CQI.

• The transport blocks should always be optimized according to the transmitted CQI when possible (if enough codes and power are available and if there’s no CPU limitation).

• No queue ID should be left starving, i.e. the scheduler should always allocate even a small part of radio resources to all users (even those with low priority and bad CQI).

In UA5.0, the Mac-hs scheduler has been enhanced (29807 – Mac-hs scheduler improvement) in order to

• Support of various MAC-hs scheduler types (proportional fair, fair, Max C/I, Round Robin in addition to current version)

• Manage SPI.

The scheduling method for the different scheduler is the following one:

• Round Robin: UEs are scheduled one after the other one

• Max C/I: UE with the best CQI is scheduled.

• Pure Fair scheduler: Throughput provided per UE must be equal. Users with the lowest throughput are then scheduled first.




• Classical proportional fair: Users are chosen according to the instantaneous CQI/averaged CQI criteria. UEs that are in their best instantaneous conditions with regard to their average are scheduled first.

• Nortel proportional fair scheduler: Users are chosen according to the number of transmitted bits and the reported CQI

3.1.1.4.2 ALGORITHM

As described in the figure below, MAC-hs scheduling consists of choosing the Mac-d flow (QId) to serve.

Figure 13: Mac-hs scheduler overview

The QId is selected using radio (CQI) and priority (SPI) criteria. The selection of a QId to be scheduled is based on a single cost function which inputs are two costs:

- The first one (C1) depends on the scheduler type. It takes into account the radio criterion.

- The second one (C2) takes into account the priority of the QID and mainly depends on the base credits assigned to this SPI priority and the average CQI. This is only used by Nortel and Classical PF schedulers.




The resulting cost is a function of these two costs, and is different according to the scheduler type. Indeed, for Nortel Proportional Fair scheduler, the resulting cost should be equal to αC1+βC2, while for the classical Proportional Fair, the resulting cost is rather equal to γ*C1*C2 (α, β, γ being hard coded). The QId with the smallest cost is scheduled first. Costs are updated after the QId has been served.

3.1.1.4.3 SCHEDULER TYPES

As explained in [R08], the RF cost function noted C1 is based on the following principles :

- Nortel:

costT = ρ.costT-1 + (1 - ρ).(nb_bits_transmitted / nb_bits_optimum(CQI) )

The goal is to favour mobiles that have not been served (nb_bits_transmitted) versus what they should have been (according to the CQI reported, nb_bits_optimum), because there was not enough resources (power, codes or processing).

- Proportional Fair:

costT = CQIavT / CQIinstT with CQIavT = ρ * CQIavT-1 + (1 - ρ) * CQIinstT

The goal is to favour mobiles that report a high CQI versus their averaged CQI to take benefit from instantaneous good radio conditions vs. average conditions.

- Round Robin:

costT = costT-1 + δ with δ = 1 if scheduled, 0 otherwise

The goal is to serve mobiles one after the other.

- Max C/I:

costT = 30 - CQIinstT

The goal is to serve the mobile which reports the best radio conditions.

- Fair:

costT-1 = costT-1

-1 + nb_bits_transmitted

The goal is that all mobiles benefit from the same throughput.

Where ρ is the forgetting factor (see the parameter hsdpaSchedulerWeightingFactor ), nb_bits_transmitted represents the number of bits actually sent to the mobile (transport block size used), CQIinst is the latest CQI reported (considered before CQI Bler adjustment).




Note for Round Robin scheduler: UEs are scheduled one after the other one. When 2 UE are scheduled in the same TTI, the scheduling is not fair since the second one will be always the last UE served and will have only the remaining resources. Then, a second criterion is then taken into account to choose the UEs order for each “round”: the one with smallest throughput is scheduled first. This introduces some variability so that UEs that are scheduled first in the TTI are different. To get a proper round robin behavior, the number of HS-SCCH should be set to 1 (cell throughput would nevertheless be impacted in that case)

Parameters:

Parameter hsdpaSchedulerWeightingFactor Object HsdpaConf Range & Unit [1…8] decimal User Customer Class 3

Granularity BTSCell

Value 5

The selection of any of these scheduler types can be changed on line through a customer class 3 parameter: hsdpaSchedulerAlgorithm .

Parameter hsdpaSchedulerAlgorithm Object HsdpaConf Range & Unit [Nortel, proportionalFair, roundRobin, maxCtoI, fair] Enum User Customer Class 3

Granularity BTSCell

Value proportionalFair

3.1.1.4.4 SPI MANAGEMENT

SPI management only applies to Nortel and Proportional Fair schedulers and is not supported by the other schedulers.

The second cost function C2 is based on the priority of the QId, and mainly on the based credits allocated to this SPI priority, and on the average CQI in order to share the HSDPA radio capacity of the cell between users so that the throughput of each QId will be proportional :

• to the weight of the SPI (see the parameter hsdpaSpiRelativeWeight )

• to the transport block size of the averaged CQI reported by the UE

For example, with two different QIds, the throughput of both QId is such that:

Thpt(QId1)/Thpt(QId2) =

Weight SPI(QId1)/ Weight SPI(QId2) * TBS[CQIav(QId1)] / TBS[CQIav(QId2)]




The base credits assigned per SPI priority (via hsdpaSpiRelativeWeight ) provide the relative weight given per priority. The absolute value is not meaningful, only the ratio between priorities is important. Example: if base credits of priority queue #4 (resp #3) is set to 20 (resp 10), a UE in priority queue #4 would be provided around twice throughput than a UE in priority queue #3 if CQI are equal.

In case all base credits are set to 100, the whole SPI management is deactivated. It allows recovering exactly UA4.2 behavior in case Nortel’s PF is selected and only one SPI activated. Note that in case base credits are equal but with a value different from 100, the behavior should nevertheless roughly be the same but the SPI management part is active.

Note that the ratio on throughputs may be subject to a certain tolerance (around 10%) and will not be respected in case there is no resource limitation for some UEs (to avoid wasting resources by artificially restraining some UEs while other UEs suffer very bad radio conditions).

Parameters:

Parameter hsdpaSpiRelativeWeight Object HsdpaConf Range & Unit [1..16][1..100] List of Decimal User Customer Class 3

Granularity BTSCell

Value 2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32

Restriction: SPI management not supported by NodeB4 .2

For RNC UA5.0 connected to NodeB UA4.2, the SPI management has to be desactivated by setting all the SPI to 0 (or to the same value for all SPI) because SPI management is not supported by NodeB UA4.2.

Different values can be set for each SPI only if all the NodeB connected to RNC UA5.0 are upgraded in UA5.0.

Note: the setting of SPI (value in the range [0…15]) is done in RNC / RadioAccessService / TrafficClassBasedQos / ArpBasedQos / ThpBasedQos

3.1.1.4.5 UE CATEGORY MANAGEMENT

UE categories also add some bias in the way virtual buffer are filled, described above. The impact depends on the value of the OMC-B parameter hsdpaUeCategoryThroughputWeighting. It defines the way balance is performed between different categories when one of them is limited by the transport block size. Indeed, above CQI 15 for instance, the transport block size of a UE cat 12 remains




constant while for other categories (e.g. 6 or 10) their transport block size still increases with the CQI.

Two behaviours are then defined according to the value of the parameter:

• ueCategoryEquity: UE categories will reach the same throughput in average at the same CQI. For instance at CQI 21, a UE cat 12 and 6 will get the same throughput even if instantaneously, the UE cat 6 will benefit from higher transport block size. UE cat 12 will then be scheduled more often to compensate this.

• ueCategoryProportionality: UEs’ throughput will depend on their category. Their ratio throughput will then be proportional to the ratio of transport block size of corresponding CQI (when UEs have the same CQI). For instance, at CQI 21 a UE cat 6 will roughly have twice the throughput of a UE category 12 (6554/3319 = 1.97), even though they are scheduled as often. Note that below CQI 15, their throughput remains equal.

It must be noted that this parameter is only applicable when SPI management is activated . It is then useless in case of fair, max C/I and round robin schedulers, or if all hsdpaSpiRelativeWeights[SPI] are equal to 100.

Parameter hsdpaUeCategoryThroughputWeighting Object HsdpaConf Range & Unit [ueCategoryEquity, ueCategoryProportionality] Enum User Customer Class 3

Granularity BTSCell

Value ueCategoryProportionality

3.1.1.4.6 HSDPA USER SCHEDULING

Every TTI, the scheduler is launched in order to efficiently assign the available resources (number of codes and remaining power) to the different users.

The first step consists in managing the retransmissions. The NACKed blocks are scheduled first, in a FIFO order when possible (in case the UE capabilities prevent from receiving data in the corresponding TTI, it is not retransmitted in that TTI). Then, once retransmissions are handled, the remaining number of codes and power are computed and constitute the input of the next step.

When there is no more retransmission to send, the scheduler selects the suitable QId (according the cost function) for a user transmitting his packet for the first time. This selection is repeated as long as some resources remain (codes, power and CPU) and if data can be scheduled for the corresponding TTI.

A user can only be considered as candidate if it is allowed to receive some data in the current TTI, i.e. if several criteria are respected (CQIprocessed ≠ 0, min inter TTI distance,




AckNack repetition factor, one HARQ process available, UE not already scheduled for retransmissions).

For each candidate user, HS-SCCH power is determined (see “Power Management” section) and power checking is done on both the current TTI and the previous one (HS-SCCH and corresponding HS-PDSCH only overlap by 1 slot). If there is not enough power to transmit the HS-SCCH in the current TTI, the user is not selected.

Then for the UE with the lowest cost within the remaining candidates UEs, the number of PDU to transmit as well as the number of codes and the transmitted power are chosen according to the processed CQI in order to fit as well as possible to what the UE can correctly receive (see “Power Management” section for more details on the algorithm):

• If there doesn’t remain enough power to transmit the HS-PDSCH, another configuration requiring less power is selected if possible (transport block size reduced, corresponding to a smaller CQI referred as CQIapplied in Section §6.3 “Power Management”.

• If there doesn’t remain enough codes to transmit the HS-PDSCH, the configuration is changed (transport block size reduced, corresponding to a smaller CQI) to use the remaining codes. The power is then updated accordingly.

3.1.2 HSUPA (E-DCH)

3.1.2.1 TRANSPORT AND PHYSICAL CHANNELS

HSUPA proposed the following set of new physical channels:

• E-DPCCH carries the UL signaling information

• E-DPDCH carries the data traffic

• E-HICH (Hybrid ARQ Indicator Channel) in DL to indicate if the UL transmission are well received (ACK/NACK channel)

• E-AGCH (Absolute Grant Channel) and E-RGCH (Relative Grant Channel) in DL to indicate to the HSUPA UE (individually or per group) what are their allocated UL resources. This indication can be done using an explicit value (through e-AGCH) or relatively to the last allocated UL resources (with e-RGCH)




E-D

PCC

HE-

DPD

CH

E-H

ICH

E-H

ICH

E-AG

CH

E-AG

CH

E-R

GC

H

E-R

GC

H

Figure 14: HSUPA channels and associated R99 channe ls

A specific E-DCH transport channel is defined. As the classical DCH transport channel it allows to offer transport services to higher layers. The E-DCH transport channel is characterized by:

• Only for UL

• Two possible TTI : 10ms and 2ms

• Transport block size and Transport Block set size are free attributes of the transport format.

• Possibility of HARQ process with retransmission procedures applied at NodeB. Max number of retransmission is defined with edchHarqMaxRetrans . Each transmitted blocks are numbered.

• Possibility of smart redundancy management at Rx (harqRvConfiguration ). The Redundancy Version (RV) used for the transmission must be managed in order to apply Chase combining or Incremental Combining mechanisms.

• Turbo coding with rate 1/3 is used

• CRC is 24 bits length

• E-TFCI (Transport Format Combination Indication) indicates which format is currently used for the UL transmission




Sequence number, redundancy version, E-TFCI must be placed onto E-DPCCH channel. On the other hand the traffic transported by E-DCH TrCh must be placed on the E-DPDCH part.

Parameter edchHarqMaxRetrans Object EdchTfcConf Range & Unit [0..15] User Customer Class 3

Granularity RNC

Value 4

Parameter harqRvConfiguration Object EdchTfcConf Range & Unit rv0, rvtable User Customer Class 3

Granularity RNC

Value rvtable

3.1.2.1.1 UPLINK CHANNELS

The E-DPDCH is used to carry the E-DCH transport channel. There may be zero, one, or several E-DPDCH on each radio link.

The E-DPCCH is a physical channel used to transmit control information associated with the E-DCH. There is at most one E-DPCCH on each radio link.

The E-DPDCH and E-DPCCH (sub) frame structure is presented on the figure below (from [3GPPref]):

Data, Ndata bits

Slot #1 Slot #14 Slot #2 Slot #i Slot #0

Tslot = 2560 chips, Ndata = 10*2k bits (k=0…7)

Tslot = 2560 chips

1 subframe = 2 ms

1 radio frame, Tf = 10 ms

E-DPDCH E-DPDCH

E-DPCCH 10 bits

Figure 15: E-DPCCH / E-DPDCH frame structure




On uplink, each radio frame is divided in 5 sub frames, each of length 2 ms. Different E-DPDCH and E-DPCCH slot formats have been defined as shown on the two tables below:

Slot Format #i Channel Bit Rate (kbps) SF Bits/ Fra me Bits/ Subframe Bits/Slot Ndata

0 15 256 150 30 10 1 30 128 300 60 20 2 60 64 600 120 40 3 120 32 1200 240 80 4 240 16 2400 480 160 5 480 8 4800 960 320 6 960 4 9600 1920 640 7 1920 2 19200 3840 1280

Table 8: E-DPCCH slot formats

Slot Format #i Channel Bit Rate (kbps) SF Bits/ Frame Bits/ Sub frame Bits/Slot Ndata

0 15 256 150 30 10

Table 9: E-DPCCH slot formats

E-DCH multicode transmission is possible only for SF = 4 and SF = 2.

The possible codes are SF 256 for e-DPCCH and SF2 to SF256 for e-DPDCH. These two new channels produced a composite complex signal as described in the figure below [3GPP ref]:

Σ I+jQ

Se-dpch

ced,1 βed,1

E-DPDCH1

iqed,1

ced,k βed,k

E-DPDCHk

iqed,k

ced,K βed,K

E-DPDCHN

iqed,K

cec βec

E-DPCCH

iqec

.

.

.

.

.

.

.

.

Figure 16: E-DPDCH/E-DPCCH multiplexing on I/Q




Σ Sdpch,n

I+jQ

Sdpch

Shs-dpcch

S

Se-dpch

Spreading

Spreading

Spreading

DPCCH DPDCHs

HS-DPCCH

E-DPDCHs E-DPCCH

Figure 17: Uplink physical channels multiplexing

The reference E-TFCI transport blocks and power offsets are signaled through the call setup message. They contain a subset of the authorized E-TFCI.

One E-DPCCH frame contains 10 bits, 7 for E-TFCI index, 2 for the RV version used (HARQ process), and 1 happy bit. The power offset of the E-DPCCH can be set through deltaEdpcch:

Parameter deltaEdpcch Object EdchTfcConf Range & Unit [0..8] User Customer Class 0

Granularity RNC

Value 4

Rule: deltaEdpcch

The deltaEdpcch recommended value (4) has to be filed in all EdchTfcConf instances (0…7).

The correspondence between the index and the amplitude is specified by 3GPP [R14]:

Signalling values for ∆∆∆∆ E-DPCCH Quantized amplitude ratios for

∆ −

2010

DPCCHE

8 30/15 7 24/15 6 19/15 5 15/15 4 12/15 3 9/15 2 8/15 1 6/15 0 5/15

Table 10: E-DPCCH power offset index vs. amplitude




The value of ββββec is based on the power offset ∆E-DPCCH signalled by higher layers. The formula to apply is:

∆ −

⋅= 2010

DPCCHE

cec ββ

3.1.2.1.2 DL CHANNELS

The E-DCH Absolute Grant Channel (E-AGCH) is a fixed rate (30 kbps, SF=256) downlink physical channel carrying the uplink E-DCH absolute grant. The next figure illustrates the frame and sub-frame structure of the E-AGCH:

Slot #1 Slot #14 Slot #2 Slot #i Slot #0

Tslot = 2560 chips

1 subframe = 2 ms

1 radio frame, Tf = 10 ms

E-AGCH 20 bits

Figure 18: E-AGCH frame structure

An E-DCH absolute grant shall be transmitted over one E-AGCH sub-frame or one E-AGCH frame. The transmission over one E-AGCH sub-frame and over one E-AGCH frame shall be used for UEs for which E-DCH TTI is set to respectively 2 ms and 10 ms. 6 bits are used to code Access Grant values. One 16 bits CRC (xored by UE id) is attached to the AG value to form one 22 bits word. A rate 1/3 convolution coding (constraint length 9) is then used leading to a total of 90 protected bits. A specific puncturing scheme is then applied to finally select a 60 bits sequences (30 bits are removed). With this kind of mechanisms only one UE can be touched at each e-DCH TTI.

• The E-DCH Relative Grant Channel (E-RGCH) is a fixed rate (SF=128) dedicated downlink physical channel carrying the uplink E-DCH relative grants. The structure of the E-RGCH is the same than the one used for e-HICH channel.

A relative grant is transmitted using 3, 12 or 15 consecutive slots and in each slot a sequence of 40 ternary values is transmitted. The 3 and 12 slot duration shall be used on an E-RGCH transmitted to UEs for which the cell transmitting the E-RGCH is in the E-DCH serving radio link set and for which the E-DCH TTI is respectively 2 and 10




ms. The 15 slot duration shall be used on an E-RGCH transmitted to UEs for which the cell transmitting the E-RGCH is not in the E-DCH serving radio link set.

The sequence bi,0, bi,1, …, bi,39 transmitted in slot I (see Figure 19: E-HICH frame structure) is given by:

bi,j = a Css,40,m(i),j

In a serving E-DCH radio link set, the relative grant a is set to +1, 0, or -1 and in a radio link not belonging to the serving E-DCH radio link set, the relative grant a is set to 0 or -1.

The relative grant (RG) command is mapped to the relative grant value as described in the table below:

Command RG Value (serving E-DCH RLS) RG Value (other radio links)

UP +1 not allowed

HOLD 0 0

DOWN -1 -1

Table 11: Relative grant information (E-RGCH)

The orthogonal signature sequences Css,40, m(i) and the index m(i) in slot i are chosen in the same tables than those used for e-HICH ACK/NACK indicators. The E-RGCH signature sequence index l is given by higher layers.

In each cell, the E-RGCH and E-HICH assigned to a UE shall be configured with the same channelisation code (SF 128).

• The E-DCH Hybrid ARQ Indicator Channel (E-HICH) is a fixed rate (SF=128) dedicated downlink physical channel carrying the uplink E-DCH hybrid ARQ acknowledgement indicator.

The following figure illustrates the structure of the E-HICH:

S lot #14

T slot = 2560 chip

b i,39 b i,1 b i,0

S lot #0 Slot #1 Slot #2 Slot #i

1 radio fram e, T f = 10 m s

1 subframe = 2 m s

Figure 19: E-HICH frame structure




A hybrid ARQ acknowledgement indicator is transmitted using 3 or 12 consecutive slots and in each slot a sequence of 40 binary values is transmitted. The 3 and 12 slot duration shall be used for UEs which E-DCH TTI is set to respectively 2 ms and 10 ms.

The sequence bi,0, bi,1, …, bi,39 transmitted in slot i in previous figure is given by :

bi,j = a Css,40, m(i),j.

In a radio link set containing the serving E-DCH radio link set, the hybrid ARQ acknowledgement indicator a is set to +1 or –1, and in a radio link set not containing the serving E-DCH radio link set the hybrid ARQ indicator a is set to +1 or 0.

The ACK/NACK command is mapped to the HARQ acknowledgement indicator as described in the table below.

Command HARQ acknowledgement indicator

ACK +1

NACK (RLSs not containing the serving E-DCH cell) 0

NACK (RLS containing the serving E-DCH cell) -1

Table 12: ACK/NACK information (E-HICH)

The orthogonal signature sequences Css,40,m(i) and the index m(i) are given in specific tables. The E-HICH signature sequence index l is given by higher layers.

3.1.2.2 UA5 IMPLEMENTATION FOR E-DCH

Rule: HSUPA-HSDPA interaction

HSUPA works only together with HSDPA in DL.

Restriction: HSUPA TTI in UA5.0

In UA5.0, only TTI 10 ms is supported

Restriction: HSUPA Macro-Diversity

In UA5.0 the macro-diversity on UL E-DCH channels is not supported. The E-RGCH is not supported also.




Restriction: E-DPDCH spreading factor

The UL SF 2 is not supported in UA5. The maximum throughput is performed with 2xSF4.

Restriction: Non scheduled transmission

Non-scheduled transmission is not supported in UA5.




3.2 DEPLOYEMENT SCENARIOS

This part aims at:

• Listing all the topologies that could be faced in UA5.0,

• Providing the UA5.0 Deployment Engineering Recommendations.

In order to limit only to realistic use cases, selection of the target UA5.0 topologies had been based on:

• HSxPA & R99 Performance expectations

• Capacity usage efficiency

• Deployment cost: New Hardware or Optimization activities (Network re-engineering actions) required

At last, STSR1+1 Versus STSR2 Engineering recommendations are suggested when 2 carriers sites have to be deployed.

A clean UL radio behavior and performance is required for correct HSUPA introduction and associated performance (see section 3.3.3.1 “UL load management”). RSSI level and stability is a good indicator of the UL load estimation.

It is important to ensure an appropriate value for the RSSI indicator. Engineering optimization shall be considered around UL/DL unbalanced paths, missing cell declaration in neighboring, NodeB cabling, external interference sources.




3.2.1 UA4.2 DEPLOYMENT STATUS

3.2.1.1 BTS HARDWARE CONFIGURATION

3.2.1.2 UA4.2 CARRIER & ATM DEPLOYMENT STATUS

Even with HSDPA introduction, Operators still keep mainly Mono-Frequency & Mono-PCM BTSs:

� Majority of customers are exclusively or mainly mono-carrier networks with sometimes few sites deployed on STSR1+1

� Minority of Operators have either deployed multi-carrier BTS’s in localized cities or exclusively deployed multi-carrier BTS’s

� Majority of Operators have mainly mono-PCM BTS: from 75% to 90% depending on the PS traffic

� Minority of customer networks contain all their BTS with multi-PCM to mainly propose aggressive HSDPA services

Most of the BTSs with two carriers are deployed STSR2 when large multi-carrier area.

3.2.1.3 NETWORK HSDPA ACTIVATION STATUS

Three level of HSDPA activation are observed:

o Networks with HSDPA deployment everywhere:

o The biggest HSDPA traffic in these networks

o The highest proportion of multi-PCM BTS

o Not depending on the carriers deployment strategies, all types are observed:

� Exclusively shared mono carrier

� Mainly shared mono-carrier with localized STSR1+1

� Exclusively 2 dedicated carriers

o Networks with large HSDPA deployment with 2 carrier deployment strategies:

o Exclusively shared mono carrier

o mixed shared/dedicated carrier

o Networks with small HSDPA deployment carrier




Networks with aggressive HSDPA deployment have currently boosted the 3G PS traffic even if it is deployed only in 1 carrier

3.2.2 UA4.2 TO UA5.0 CELL TOPOLOGY EVOLUTION

3.2.2.1 UA4.2 CELL TOPOLOGIES

Three UA4.2 cell topologies are currently used by the operator:

• One Frequency with R99 traffic:

o Represented in this document by:

o Do not carry any HSDPA traffic

• One Frequency with HSDPA/ R99:

o Represented in this document by

o R99 and HSDPA traffic are cohabiting on the same frequency

o Only 5 OVSF DL SF16 codes statistically booked & generally 1 PCM deployed

• Two Frequencies with HSDPA/ R99:

o Represented in this document by:

o HSDPA traffic is carried on a dedicated carrier

o 10 OVSF DL SF16 codes statistically booked & more than 1 PCM generally deployed

o Mostly STSR2 deployed and very few STSR1+1

It is assumed that in UA5.0, HSUPA is activated wherever HSDPA is activated and so, UA5.0 cell topologies with HSDPA but no HSUPA are not considered in this document. This being a standard HSDPA deployment scenario, information about it can be found in the UA4.2 version of this document.

R99

R99 / HSDPA

R99

HSDPA

R99

HSDPA




3.2.2.2 HSXPA/ R99 DEPLOYED IN 1 SHARED FREQUENCY

R99

R99 / HSDPA

R99

HSDPA

Mobility Optimization

Performance Expectation

Resource Usage

Hardware requirement

☺☺☺☺

☺☺☺☺ ☺☺☺☺

��

��

��

��

☺☺☺☺

��

R99 / HSxPA

R99 / HSxPA

R99 / HSxPA

☺☺☺☺

☺☺☺☺

Table 13: Transitions to HSxPA/R99 deployed in shar ed carrier

This configuration does not require any 3G inter-layer mobility and iMCTA CAC by default to save the R99 call by performing HHO to 2G neighboring cells when necessary.

Concerning Performance aspect, HSXPA throughput could be limited by Power & by Codes and R99 could potentially be impacted by interference generated during HSXPA activity period. Therefore, it is recommended to assess the OVSF Code Usage and the DL Power Usage

In term of hardware cost, it is the cheapest one with only 1 E-BBU and 1 H-BBU mandatory.

Globally, it should be the most common cell topology in UA5.0 since HSDPA was also mainly deployed in 1 carrier except in these specific cases:

• if 2 carriers were already deployed in UA4.2 or

• if the UA4.2 traffic increases highly and impacts the current R99 or HSDPA performances




3.2.2.3 HSXPA AND R99 DEPLOYED IN 2 DEDICATED CARRI ERS



Resource Usage


☺☺☺☺ ☺☺☺☺

��

��

R99

HSxPA

R99

HSxPA

��

☺☺☺☺

☺☺☺☺

☺☺☺☺

��

��

��

R99

R99 / HSDPA

R99

HSDPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

Table 14: Transitions to HSxPA & R99 deployed in 2 dedicated carriers

In this configuration, RRC Traffic Segmentation is favors to redirect the call at RRC establishment. iMCTA Service is then use to ensure R99 calls are re-directed on F1.

Since HSxPA traffic and R99 traffic separated, neither HSxPA interference in R99 carrier nor HSxPA Throughput limited by Power are expected.

Concerning capacity, Free codes and power available on layer 1 will not be available for HSXPA traffic (and vice-versa).

The Hardware requirements are at least 1 H-BBU, 1 E-BBU & 1 TRM (if 1 carrier previously).

Globally, it should be a likely configuration chosen if already 2 dedicated carrier deployed in UA4.2 or traffic increase. Interesting U5.0 cell topology for 2 main reasons:

• to avoid R99/ HSXPA cohabitation issue & so safe configuration for R99/HSXPA performance

• Traffic segmentation usage & avoid bad impact of Compress Mode for static HSxPA UE’s




3.2.2.4 MIXED HSDPA/ R99 SHARED CARRIER AND R6 HSXP A DEDICATED CARRIER



Resource Usage


��

��

��

��

��

��

��

��

��

��

R99

R99 / HSDPA

R99

HSDPA

R99 / HSDPA

HSxPA

R99 / HSDPA

HSxPA

R99 / HSDPA

HSxPA

R99 / HSDPA

HSxPA

R99 / HSDPA

HSxPA

R99 / HSDPA

HSxPA

Table 15: Transitions to mixed HSDPA/R99 shared car rier & R6 HSxPA dedicated carrier

RRC Traffic Segmentation is not possible in this configuration since the system can not distinguish R6 and R5 HSDPA calls. Therefore, only usage of iMCTA Service is possible to redirect R6 HSxPA on F2

Moreover, HCS activation is mandatory to select always F1

R99 could be potentially impacted by interference generated during HSxPA activity period and by Compressed Mode generated at each HSUPA call established on F1. On contrary, this is an optimum configuration for HSUPA Throughput since no cohabitation between HSUPA and UL DCH traffic is forecasted.

iMCTA service partitioning is favored vs. load balancing and could lead to waste of resources.

The minimum hardware requirements are at least At least 2 H-BBU, 1 E-BBU & 1 TRM (if 1 carrier previously).

Globally, this is an expensive UA5.0 Cell Topology which is possible in localized HSDPA hot spots inside mono-carrier area. Interesting U5.0 cell topology for 2 main reasons:

• to reach the best HSUPA Performance (only R6 PS calls on F2)

• to allow R5 HSDPA service continuity in F1 inside mono-frequency area




3.2.2.5 MIXED HSDPA/ R99 SHARED CARRIER AND HSXPA/ R99 SHARED CARRIER



Resource Usage


��

��

��

��

��

☺☺☺☺

☺☺☺☺

☺☺☺☺

R99

R99 / HSDPA

R99

HSDPA

R99 / HSDPA

R99 / HSxPA

R99 / HSDPA

R99 / HSxPA

R99 / HSDPA

R99 / HSxPA

R99 / HSDPA

R99 / HSxPA

R99 / HSDPA

R99 / HSxPA

R99 / HSDPA

R99 / HSxPA

Table 16: Transitions to mixed HSDPA/R99 shared car rier & R6 HSxPA dedicated carrier

RRC Traffic Segmentation is not possible in this configuration since the system can not distinguish R6 and R5 HSDPA calls. Therefore, only usage of iMCTA Service is possible to redirect R6 HSXPA on F2

Moreover, HCS activation is mandatory to select always F1

R99 potentially impacted by interference generated during HSXPA activity period and by Compressed Mode generated at each HSUPA call established on F1

R99 PS UL Traffic could degrade HSUPA Throughput.

Load balancing between frequencies is possible for R99 calls.

The minimum hardware requirements are at least 2 H-BBU, 1 E-BBU & 1 TRM (if 1 carrier previously).

This is an expensive UA5.0 Cell Topology interesting for its resource usage capabilities but no guarantee on the HSUPA Performance. Therefore no deployment is currently forecasted in UA5.0.




3.2.2.6 DEDICATED R99 CARRIER AND HSXPA/ R99 SHARED CARRIER

This is a scenario foreseen by some customers that wants to expand R99 capacity



Resource Usage


☺☺☺☺

☺☺☺☺

��

��

☺☺☺☺

☺☺☺☺

☺☺☺☺

��

��

��

��

R99

R99 / HSDPA

R99

HSDPA

R99 / HSxPA

R99

R99 / HSxPA

R99

R99 / HSxPA

R99



Resource Usage


☺☺☺☺

☺☺☺☺

��

��

☺☺☺☺

☺☺☺☺

☺☺☺☺

��

��

��

��

R99

R99 / HSDPA

R99

HSDPA

R99 / HSxPA

R99

R99 / HSxPA

R99

R99 / HSxPA

R99

R99 / HSxPA

R99

R99 / HSxPA

R99

R99 / HSxPA

R99

Table 17: Transitions to mixed HSDPA/R99 shared car rier & R99 dedicated carrier

RRC Traffic Segmentation & iMCTA service will be used to redirect the R5+ call on HSDPA layer

HSxPA throughput could be limited by DL Power limitation or by DL OVSF Code limitation. Therefore, it is recommended to assess the DL Power Usage & the OVSF Code Usage to activate properly the Dynamic Code Tree Management.

Load Balancing is triggered to re-direct R99 call when shared carrier is loaded (Red or Yellow color)

The minimum Hardware required is at least 1 H-BBU, 1 E-BBU & 1 TRM (if 1 carrier previously)

This is a probable configuration chosen if high traffic of R99 inside HSxPA/ R99 shared carrier area. Interesting U5.0 cell topology for 2 main reasons:

• to use iMCTA load balancing to share R99 load

• Traffic segmentation usage and to avoid bad impact of Compress Mode for static HSxPA UE’s




3.2.3 UA4.2 TO UA5.0 CARRIER DEPLOYMENT RECOMMENDATIONS

3.2.3.1 HSDPA DEPLOYMENT SCENARIOS EVOLUTION

Three HSDPA deployment scenarios are currently observed in UA4.2:

• Mono-frequency HSDPA area

• Dedicated HSDPA carrier inside mono frequency HSDPA area

• Dedicated HSDPA Carrier.

The mono frequency HSDPA area deployment should evolve as follow:

• Mono-frequency HSXPA area (most probable case)

• Mono-frequency HSXPA area with few 2 carriers sites in localized sites

• HSXPA & R99 in 2 dedicated carriers area.

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or If HSUPA traffic can not cohabite with R99 in most of cells inside the area

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or If R99 quality needs to be improved

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or if HSUPA traffic can not cohabite with

R99 in few sites of the area

R99 / HSDPA R99 / HSDPA R99 / HSDPA R99 / HSDPA R99 / HSDPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA

R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPAR99 / HSDPA

HSxPA

R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA

R99

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or If HSUPA traffic can not cohabite with R99 in most of cells inside the area

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or If R99 quality needs to be improved

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or if HSUPA traffic can not cohabite with

R99 in few sites of the area

R99 / HSDPA R99 / HSDPA R99 / HSDPA R99 / HSDPA R99 / HSDPAR99 / HSDPA R99 / HSDPA R99 / HSDPA R99 / HSDPA R99 / HSDPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPAR99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA


HSxPA


HSxPA

R99 / HSDPA

HSxPA


HSxPA

R99R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99


R99R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPAR99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA

R99

Figure 20: Mono frequency HSDPA area evolution




The dedicated carrier inside mono frequency HSDPA area deployment should evolve as follow:

• Mono-frequency HSXPA area with few 2 carriers sites in localized sites

• HSXPA & R99 in 2 dedicated carriers area.

R99 / HSDPA R99 / HSDPA R99 / HSDPA R99 / HSDPAR99

HSDPA


HSxPA

R99


HSxPA


R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or If R99

quality needs to be improved

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or If

HSUPA traffic can not cohabite with R99 in most of cells inside the area


HSDPA


HSDPA


HSxPA


HSxPA

R99


HSxPA


HSxPA

R99 / HSDPA

HSxPA


R99R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPAR99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA R99 / HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or If R99

quality needs to be improved

Either if HSDPA/ R99 Traffic requires more resources (power/ codes) or If

HSUPA traffic can not cohabite with R99 in most of cells inside the area

Figure 21: Dedicated carrier inside mono frequency HSDPA area evolution

The dedicated HSDPA carrier area should carry also the R6 HSDPA traffic and remain dedicated HSXPA.

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99

HSxPA

R99R99

HSDPA

R99

HSDPA

R99

HSDPA

R99

HSDPA

R99

HSDPA

R99

HSDPA

R99

HSDPA

R99

HSDPA

R99

HSDPA

R99

HSDPA

Figure 22: Dedicated HSDPA carrier area evolution

3.2.3.2 DEDICATED HSXPA CARRIER INSIDE MONO-CARRIER HSXPA AREA DEPLOYMENT CHOICES

Two probable choices are possible when 2 carriers have to be deployed inside a mono-carrier area:

• R99 & HSXPA on 2 dedicated carriers or

• Mixed HSDPA/ R99 shared carrier and R6 HSXPA dedicated carrier

In this part, the advantages and disadvantages of each configuration are given so that to help the operator to the most appropriate choice.


HSxPA


HSxPA

R99




Advantages Disadvantages

RRC Traffic Segmentation can be fully enabled

� HSPA users camping on F1 automatically redirected to F2 at RRC establishment

� F1 will be less impacted by unexpected HSPA UEs

CM occurrence for R5 & R6 UE each time they enter F1

� interference, loss of capacity

Best configuration for HSDPA Throughput if not moving

Impact on HSDPA continuity: throughput disruption for more than 5s (TBC) when R5 UEs enter/leave STSR2 coverage

No need to add 1 H-BBU on F1

Table 18: R99 & HSxPA on 2 dedicated carriers hot-s pots pros/cons


HSxPA


HSxPA

R99 / HSDPA

HSxPA

Advantages Disadvantages

HSDPA Service continuity � No HSDPA throughput disruption

No Traffic Segmentation possible:

� CM occurrence for R6 UE each time they enter and

� CM occurrence for R6 UE each time they establish the HSUPA call on F1

� HCS Mandatory to favor F1 for R5 and R99 calls

No CM occurrence for R5 UE each time they enter F1

1 H-BBU is required on F1

Best config. for HSUPA Performance Low F2 resource usage as R5 UEs are systematically redirected to F1

Table 19: Mixed HSDPA/ R99 shared carrier and R6 HS xPA dedicated carrier




In conclusion the choice between the 2 deployment areas depends on UE mobility behavior:

• R99 & HSXPA on 2 dedicated carriers incase of static HSDPA users during activity period

• Mixed HSDPA/ R99 shared carrier and R6 HSxPA dedicated carrier in case of moving HSDPA users during activity period

3.2.3.3 STSR2 VERSUS STSR 1+1

At first, here are the 2 pre-requisites conditions to allow deployment on STSR2:

• A certain spacing (F2-F1) between the 2 frequencies are required: [4.6; 5.1] (while STSR1+1 frequencies spacing: [4.6; 55.2])

• The radio coverage of the cells are not noise limited: Average RSCP < -90 dBm (average RSCP anticipated by subtracting 3 dB to the current average RSCP in case of PCPICH - 3dB)

If the 2 above conditions are respected, STSR2 will be favor in large bi-carriers deployment area due to the hardware cost saving (no need of 2 PA). In this case it special attention should be performed at border with the mono-carrier area.

In case of small 2 carriers deployment area, if STSR2 is selected then an assessment of the impact on HSDPA & R99 traffic have to be performed depending on the 2 CPICH design choices:

• Choice 1: keep same CPICH design on F1 layer & (CPICH-3dB) on F2

o DL Power bandwidth available for R99 & HSDPA will drastically decrease high risk of HSDPA throughput degradation

o potential impact on R99 capacity on F1 cells

o R99 & HSDPA parameters retuning on F1 cells (e.g. PLC thresholds, MPO)

• Choice 2: (CPICH-3dB) on F1 cells & (CPICH-3dB) on F2

o Impact on current cell footprints requires RF re-design &/OR densification

o F1 potential mobility issues at cell border due to unbalanced CPICH high risk of HSDPA throughput degradation

o R99 params retuning (e.g. RSCP related)

Therefore, even considering the additive hardware cost, STSR1+1 deployment in localized hot spot should be favors choice in order to not degrade Performance of current HSDPA & R99




3.2.3.4 UMTS 2100MHZ VERSUS UMTS 900MHZ

Basically, UMTS 900 MHz appears as an interesting deployment solution able to increase HSxPA cell throughput and increase R99 capacity or decrease number of sites compared to UMTS 2100 MHz thanks to a better radio propagation at 900MHz than 2100MHz. Different deployment scenarios exist for UMTS 900MHz:

• Same site location for UMTS 900MHz as for UMTS 2100MHz (same number of sites) – Case 1.

• Same R99 capacity for UMTS 900MHz as for UMTS 2100MHz (same subscriber density and same Effective Service Area) – Case 2.

• Same downlink coverage for UMTS 900MHz as for UMTS 2100MHz (same CPICH received power) – Case 3.

The choice of the deployment strategy (case 1, 2 or 3) depends on a tradeoff between capacity improvement and number of sites. The most important constraint to deploy UMTS 900 MHz is the frequency band available by the operator knowing that this frequency band is already used for GSM network. Note that HSUPA mobiles working at 900MHz are not available




3.3 HSXPA RESOURCES

3.3.1 HSXPA ACTIVATION

HSDPA and HSUPA are activated thought several activation flags at RNC, FDDCell and BTSCell level:

HSDPA:

Parameter isHsdpaAllowed Object RadioAccessService Range & Unit False, True User Customer Class 3

Granularity RNC

Value True

Parameter hsdpaActivation Object FDDCell Range & Unit False, True User Customer Class 2

Granularity Cell

Value True

Parameter hsdpaResourceActivation Object BTSCell Range & Unit False, True User Customer Class 2

Granularity Cell

Value True

HSUPA:

Parameter isEdchallowed Object RadioAccessService Range & Unit False, True User Customer Class 3

Granularity RNC

Value True

Parameter edchActivation Object FDDCell Range & Unit False, True User Customer Class 2

Granularity Cell

Value True




Parameter edchResourceActivation Object BTSCell Range & Unit False, True User Customer Class 0

Granularity Cell

Value True

Note that isHsdpaAllowed exists also in two other objects (RNC / NeighbouringRNC and RNC / NodeB / FDDCell / UMTSFddNeighbouringCell) in order to know if the HSDPA call has to be reconfigured or not in DCH when the primary cell changes in case of mobility over Iur.

3.3.2 HSDPA

3.3.2.1 OVSF CODES

3.3.2.1.1 CELL CONFIGURATION

The following figure presents the cell configuration in UA4.2. In this release, the common channels OVSF codes (CPICH, P-CCPCH, S-CCPCH, …) are reserved at the top of OVSF tree (low OVSF code index) and the HSDPA codes are reserved in a static mode at the bottom of the tree (up to 4 SF128 for HS-SCCH are reserved just after up to 15 SF16 codes for HS-PDSCH).

Figure 23: Example of OVSF tree usage with HSDPA in U4.2

In UA5.0 codes reservation at cell setup has changed:

• Only the HS-PDSCH codes are reserved at the bottom of the OVSF tree. All the other channels are reserved just after the common channels (1) common channels, 2) OCNS, 3) HS-SCCH channels, 4) DL HSUPA channels)

• “Multiple S-CCPCH” feature allows to use up to 3 S-CCPCH (1st S-CCPCH on SF64,1, 2

nd S_CCPCH on SF128,4, 3rd S-CCPCH on SF128,5). Then the common




channels take the equivalent of a SF32 in mono-S-CCPCH mode, a SF32 + a SF128 in bi-S-CCPCH mode and a SF32 + 1SF64 in tri-S-CCPCH mode.

• The number of HS-PDSCH codes reserved at cell setup is still defined by the numberOfHsPdschCodes parameter as in UA4.2. When the feature “Dynamic DL Codes Tree Management for HSDPA” is activated the number of HS-PDSCH codes reserved for HSDPA traffic can be updated dynamically according the number of free OVSF codes

The following figures illustrate the different Common Channels configurations described above:

Configuration with 3 S-CCPCHConfiguration with 2 S-CCPCHConfiguration with 1 S-CCPCH Configuration with 3 S-CCPCHConfiguration with 2 S-CCPCHConfiguration with 1 S-CCPCH

Figure 24: R99, HSDPA & HSUPA Common Channels codes allocation

In UA4.2, HS-PDSCH codes allocation is static: HS-PDSCH codes can not be used for R99 traffic even if there is no HSDPA user and HSDPA users can not used more than the allocated HS-PDSCH codes even if there is no R99 traffic.

In UA5.0, the “Dynamic Code Tree Mgt” feature allows a dynamic HS-PDSCH codes allocation depending on number of free OVSF codes. The benefit of the feature is to maximize the usage of the cell code resources in adjusting dynamically (code pre-emption or reallocation) the number of SF16 codes for HSDPA versus the DCH load on the OVSF tree. Thus, the Node-B is able to cope with any HSDPA/DCH traffic




variations while ensuring both, the priority to DCH traffic and a minimum of HSDPA activity when configured by the customer.

The feature consists in monitoring the DCH code tree load toward a code margin defined by the customer. This is a preventive solution to avoid potential DCH call drops due to an instantaneous unavailability of codes for DCH.

3.3.2.1.2 HSDPA CODE ALLOCATION

When the feature “Dynamic. Code Tree Mgt” is deactivated by setting the isHsPdschDynamicManagementAllowed parameter to False, the HS-PDSCH codes are allocated in static and cannot be used or pre-empted for other services. The behavior is the same as in UA4.2 except that the HS-SCCH codes are allocated at the top of the OVSF tree after the common channels. The number of HS-SCCH is defined, as in UA4.2, by the numberofHsScchCodes .

When the feature “Dynamic Code Tree Mgt” is activated by setting the isHsPdschDynamicManagementAllowed parameter to True, the HS-PDSCH codes can be pre-empted or re-allocated according the number of free OVSF codes. The number of free OVSF codes is re-evaluated for each R99 code release or allocation. The new configuration (number of HS-PDSCH codes; HS-PDSCH start code number) is transmitted from the RNC to the NodeB through a NBAP PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST and replaces the old one instantaneously (at the next TTI) as only asynchronous mode is supported. Note that the HS-PDSCH codes are only reserved and may be unused (pre-emption and re-allocation occurs even if there is no HSDPA user in the cell).

Monitoring line

The HS-PDSCH codes pre-emption or re-allocation is triggered by some thresholds defined compared to the number of free OVSF codes noted #FreeOvsfCodesSfx. The number of free OVSF codes can be monitored for different Spreading Factor from SF16 to SF256.

This monitoring line is set by default to SF16 via the spreadingFactorLevelForOvsfMonitoring parameter.

HS-PDSCH codes pre-emption

The pre-emption (or stealing) of HS-PDSCH codes is triggered when the number of free OVSF codes is strictly lower than threshCodesToTriggerStealing .

Triggering condition for HS-PDSCH codes pre-emption:

#FreeOvsfCodesSfx < threshCodesToTriggerStealing (Cond.1)

OR




threshCodesToTriggerStealing * SF8/SFMonitoring ≥1

AND Nf of free SF8 codes == 0 (Cond.2)

As SFMonitoring can not be lower than SF16, the second condtion (Cond.2) allows to check the availability of one SF8.

When the pre-emption condition is encountered, the RNC steals some HS-PDSCH codes in order to have numCodesForDchAfterStealing free OVSF codes.

Number of free OVSF codes after stealing:

#FreeOvsfCodesSfx ≥ numCodesForDchAfterStealing (Cond.3)

OR

New Nb of free SF8 codes > 0 if

((old Number of free SF8 codes == 0) AND ((threshCodesToTriggerStealing * SF8/SFMonitoring) ≥ 1)) (Cond.4)

The second condition (Cond.4) allows to guarantee at least one SF8 if needed.

The HS-PDSCH codes are pre-empted from the top to the bottom of the OVSF tree and the minNumberOfHsPdschCodes parameter guarantees a minimum number of HS-PDSCH codes that can not be stolen.

In order to avoid reallocation just after a stealing, the RNC starts a timer (minTimeBeforeReallocationofHsPdsch ) when a stealing is triggered during which reallocation is forbidden but stealing is allowed.

HS-PDSCH codes re-allocation

The re-allocation of HS-PDSCH codes is triggered when the number of free OVSF codes is strictly higher than threshCodesToTriggerReallocation .

Triggering condition for HS-PDSCH reallocation:

#FreeOvsfCodesSfx > threshCodesToTriggerReallocation

When the re-allocation condition is encountered, the RNC re-allocate some HS-PDSCH codes in order to have numCodesForDchAfterReallocation free OVSF codes.




Number of free OVSF codes after re-allocation:

#FreeOvsfCodesSfx ≥ numCodesForDchAfterReallocation (Cond.5)

OR

New Nb of free SF8 codes > 0 if

((old Number of free SF8 codes == 0) AND ((threshCodesToTriggerStealing * SF8/SFMonitoring) ≥ 1)) (Cond.6)

The second condition (Cond.6) allows to guarantee at least one SF8 if needed.

The HS-PDSCH codes are re-allocated from the bottom to the top of the OVSF tree and the maxNumberOfHsPdschCodes parameter guarantees a maximum number of HS-PDSCH codes that can be re-allocated.

PARAMETERS SETTINGS AND RECOMMENDATIONS

Restriction: HS-PDSCH codes re-allocation can be bl ocked by a R99 code even if re-allocation is triggered

The HS-PDSCH codes have to be consecutive whatever the free OVSF codes. So, if a R99 code is contiguous to the HS-PDSCH codes already reserved, new HS-PDSCH can not be re-allocated. This scenario is illustrated by the following figure. HSDPA throughput impact should be low since it appears in specific condition and can be reduce by setting appropriate value for the minimum codes for HS-PDSCH.




SF

256

SF

128

SF

64

SF

32

SF

16

SF

8

SF

4

SF

256

SF

128

SF

64

SF

32

SF

16

SF

8

SF

4

0

10

02

31

0

10

02

31

4

52

16

73

4

52

16

73

8

94

210

115

8

94

210

115

12

136

314

157

12

136

314

157

HS-PDSCH (4 for ex)

Free OVSF codes

R99 codes

Common channels(3 S-CCPCH) + 2 HS-SCCH

Reallocation of a 5th HS-PDSCH code is impossible because of theR99 code even if the number of

free codes triggers the reallocation

Figure 25: Illustration of the HS-PDSCH re-allocati on blocking

The isHsPdschDynamicManagementAllowed parameter allows the activation of the “Dynamic Code Tree Mgt” feature:

Parameter isHsPdschDynamicManagementAllowed Object RadioAccessService Range & Unit [false, true] User Customer Class 3

Granularity RNC

Value True

Restriction: Dynamic Code Tree mgt feature activati on

The current parameter isHsPdschDynamicManagementAllowed activates the feature at RNC level for all the NodeB whatever their release, UA4.2 or UA5.0. The feature activation at RNC level will lead to a Physical Shared Channel Request Failure on NodeB UA4.2.

In order to avoid this issue and to activate the feature only on a limited number of NodeB, activation at FDDCell level is requested. The solution for UA5.0 is to use the unused parameter isHighPerformanceAllowed.




Parameter isHighPerformanceAllowed Object HsdpaCellClass Range & Unit [false, true] User Customer Class 0

Granularity CellClass

Value True

Note : When feature is disabled at RNC level, no NBAP message is sent by RNC to provide NodeB with new configuration, that is to say that the number of HS-PDSCH remains the same after desactivation and is not equal to numberOfHsPdschCodes . In order to reinitialize the number of HS-PDSCH to numberOfHsPdschCodes , we need either to lock/unlock the cell or to disable the feature at FDDCell level (parameter being class 0).

Parameter numberOfHsPdschCodes Object HsdpaCellClass Range & Unit [1..15] User Customer Class 3


Value 5

Parameter numberOfHsScchCodes Object HsdpaCellClass Range & Unit [1..4] User Customer Class 3

Granularity CellClas

Value 2

Engineering Recommendation: numberOfHsPdschCodes & numberOfHsScchCodes

In UA4.2, the recommended configuration for (numberOfHsPdschCodes ; numberOfHsScchCodes ) is (5;1) for shared carrier and (10;2) for HSDPA dedicated carrier.

When the feature is activated:

numberOfHsPdschCodes = 5 in order to keep the same behavior as in UA4.2 when the feature is deactivated

numberOfHsScchCodes = 2 in order to schedule up to 2 HSDPA users when R99 traffic is low

numberOfHsScchCodes = 4 in order to schedule up to 4 HSDPA users when DL throughput is low (number of HS-PDSCH needed is low) for HSUPA or VoIP services

Parameter maxNumberOfHsPdschCodes Object HsPdschDynamicManagement Range & Unit [1..15] User Customer Class 3


Value 15




Engineering Recommendation: maxNumberOfHsPdschCodes

This maximum value of 15 can never be reached because of the presence of at least the common channel codes, the free codes and codes for SRB. Nevertheless, there is no reason to limit this value.

Parameter minNumberOfHsPdschCodes Object HsPdschDynamicManagement Range & Unit [1..15] User Customer Class 3


Value 1

Engineering Recommendation: minNumberOfHsPdschCodes

This parameter allows to guarantee a minimum QoS for HSDPA and depends on the operator strategy:

Operator strategy Recommended value

Full flexibility of the feature 1

No impact on HSDPA cat12 user 5

Minimum HDSPA throughput (at least throughput of 1 PS384) 2

The number of OVSF codes of SFX in the tree is monitored at each OVSF code allocation or deallocation. The “X” corresponds to the parameter called spreadingFactorLevelForOvsfMonitoring

Parameter spreadingFactorLevelForOvsfMonitoring Object HsPdschDynamicManagement Range & Unit

[16, 32, 64, 128, 256]



Value 16

The number of HS-PDSCH codes (SF16) that are reallocated will be computed so that after reallocation, the number of SFX free for DCH is targeted to numCodesForDchAfterReallocation parameter.

Parameter numCodesForDchAfterReallocation Object HsPdschDynamicManagement Range & Unit

[1..255]



Value 2

The number of HS-PDSCH codes (SF16) that are stolen will be computed so that after stealing, the number of SFX free for DCH is targeted to numCodesForDchAfterStealing parameter




Parameter numCodesForDchAfterStealing Object HsPdschDynamicManagement Range & Unit [1..255] User Customer Class 3


Value 2

When the number of free SFX codes (that are not allocated to DCH or HSPDSCH) is strictly greater than threshCodesToTriggerReallocation parameter, the RNC will reallocate some HS-PDSCH codes.

Parameter threshCodesToTriggerReallocation Object HsPdschDynamicManagement Range & Unit

[1..255]



Value 2

When the number of free SFX codes (that are not allocated to DCH or HSPDSCH) is strictly lower than threshCodesToTriggerStealing parameter, the RNC will steal some HS-PDSCH codes.

Parameter threshCodesToTriggerStealing Object HsPdschDynamicManagement Range & Unit [1..255] User Customer Class 3


Value 2

Engineering Recommendation: numCodesForDchAfterX & threshCodesToTriggerX

Parameters numCodesForDchAfterX & threshCodesToTriggerX allow defining the number of free OVSF code when there is no pre-emption or re-allocation. This number of free OVSF codes gives the bigger RAB that the RNC can accept.

If the operator PS allocation policy is based on PS128, the parameters has to be set so that the number of free codes to be equal to 1 SF16;

If the operator PS allocation policy is based on P384, the parameters have to be set so that the number of free codes to be equal to 2 SF16.

Note that these values assume spreadingFactorLevelForOvsfMonitoring = SF16.

The above recommendations are given for a PS384 adm ission policy .




Engineering Recommendation: spreadingFactorLevelForOvsfMonitoring

With typical parameters setting (monitoring line = SF16 and 2 free SF16), the maximum number of HS-PDSCH is 11 (1 SF16 for commom channel, 3 free SF16, 1 SF16 for SRBs).

For HSDPA KPI tests, the maximum number of HS-PDSCH codes can be increased by increasing monitoring line SFx and by decreasing number of free SFx codes (in order to schedule several HSDPA ue in the same TTI).

Higher number of HS-PDSCH codes can be reached with monitoring line equal to SF128 and 1 free SF128 (1 SF16 for common channel including several HS-SCCH, 1 SF16 for SRBs including 1 free SF128 and 14 SF16 for HS-PDSCH).

Note that configuration with monitoring line equal to SF256 and 1 free SF256 does not allow to admit several HSDPA ue since HSDPA call is established with SRB13.6 (SF128). After establishment, SRB13.6 is reconfigured in SRB3.4 (SF256).

When stealing has been triggered, the RNC starts minTimeBeforeReallocationOfHsPdsch timer during which reallocation is forbidden but stealing is allowed

Parameter minTimeBeforeReallocationOfHsPdsch Object HsPdschDynamicManagement Range & Unit

[0..3600] Decimal (s)



Value 0

Engineering Recommendation: minTimeBeforeReallocationOfHsPdsch

Increase this parameter leads to decrease the number of PSCR for reallocation but HSDPA throughput may be degraded if some free SF16 are not reallocated because of this timer. That why his value is 0.

Note: The number of free OVSF codes is re-evaluated for each R99 code release or allocation except at timer expiry. When the timer minTimeBeforeReallocationOfHsPdsch is expired, RNC will check automatically the threshold compared to the number of free OVSF codes without waiting for a R99 code release or reallocation.




Rule: Coherence between the parameters

To have normal feature behaviour:

numCodesForDcfhAfterReallocation <= threshCodesToTriggerReallocation

numCodesForDchAfterStealing >= threshCodesToTriggerStealing

To avoid ping-pong:

numCodesForDchAfterReallocation >= threshCodesToTriggerStealing

numCodesForDchAfterStealing <= threshCodesToTriggerReallocation

To be in line with monitoring line

numCodesForDchAfterReallocation <= spreadingFactorLevelForOvsfMonitoring

numCodesForDchAfterStealing <= spreadingFactorLevelForOvsfMonitoring

threshCodesToTriggerReallocation <= spreadingFactorLevelForOvsfMonitoring

threshCodesToTriggerStealing <= spreadingFactorLevelForOvsfMonitoring

To be coherent at cell setup

minNumberOfHsPdschCodes <= numberOfHsPdschCodes

numberOfHsPdschCodes <= maxNumberOfHsPdschCodes




Engineering Recommendation: OCNS configuration

OCNS code allocation is done before HSDPA configuration and it may lead to a conflict as HS-PDSCH codes are always allocated from the bottom and need to be contiguous. To avoid any issue with HS-PDSCH and the common channels codes, OCNS configuration has to be modified according to the number of S-CCPCH codes:

Param identity

(Customer Class 2) Default value Recommended value Range

RNC / NodeB / FDDCell

OCNSActivation False - Enum [False; True]

OCNSSpreadingFactor SF8 SF256 Enum [SF4 … SF256]

RNC / NodeB / FDDCell / OCNSChannelsParameters

OCNSPower 100% - Integer [0…100]

OCNSChannelizationCodeNumber 7

8 with 1 S-CCPCH

10 with 2 S-CCPCH

12 with 3 S-CCPCH

Integer [0…511]

3.3.2.2 POWER

In HSDPA, PA power has to be shared between common channels, DCH channels and HSDPA channels. In order to manage correctly this new power partition, some new margins or thresholds are added at RNC and NodeB level:

• At RNC level, a minimum power can be reserved for HSDPA.

• At NodeB level, a DCH margin allows to take into account the R99 power fluctuation due to power control.

For more details, see section §6.3 “Power Management”.

3.3.2.3 HSDPA CHANNELS & CQI

3.3.2.3.1 PHYSICAL CHANNELS

The following flowchart describes the timing relations between the different physical channels:




HS-SCCH#2

ACK ACK ACK

7,5 slots

HS-SCCH#1

HS-PDSCH

N_acknack_transmit = 2

2 ms

HS-DPCCH

2 slots

Figure 26: Timing relationship at NodeB between phy sical channels

The mobile receives a HS-SCCH subframe (see the following figure) containing control information among which:

• Channelization-code-set information (7 bits – slot #0 of subframe)

• Modulation scheme information (1 bit – slot #0 of subframe), i.e. QPSK/16QAM

• Transport-block size information (6 bits – slots #1 & #2 of subframe)

• Hybrid-ARQ process information (3 bits – slots #1 & #2 of subframe)

• Redundancy and constellation version (3 bit – slots #1 & #2 of subframe)

• New data indicator (1 bit – slots #1 & #2 of subframe)

• UE identity (16 bits – used as a mask in slots #0, #1 & #2 of subframe), i.e. subset of the HRNTI

The SF is fixed to 128. It indicates to which UE data is intended to, on which codes and with which parameters. There are as many HS-SCCH transmitted during a TTI as scheduled user number.

Data

Slot #0 Slot #1 Slot #2

1 HS-SCCH subframe = 2ms

Tslot = 2560 chips = 40 bits

Figure 27: HS-SCCH structure




A mobile decoding its identity in the slot #0 of an HS-SCCH knows that it has been assigned resources on the HS-PDSCH channels (as indicated, with modulation, in this slot #0, other information are given in slots #1 and 2): the mobile receives a transport block on one or several HS-PDSCH (see the following figure).

M= 2 for QPSK (960 coded bits per TTI)M = 4 for 16QAM (1920 coded bits per TTI)

Data

Slot #0 Slot #1 Slot #2

1 HS-PDSCH subframe = 2ms

Tslot = 2560 chips = M*10*2k bits (k = 4, SF16)

Figure 28: HS-PDSCH structure

The HS-PDSCH on which is mapped the HS-DSCH carries only the data payload. The SF is equal to 16 and up to 15 codes can be reserved to HS-PDSCH per cell. One HS-DSCH can be mapped onto one or several HS-PDSCH (the maximum number of codes is given by UE capabilities).

When addressed on HS-SCCH, the UE will then send feedback frame(s) on HS-DPCCH (SF = 256), roughly 7.5slots after HS-PDSCH frame, containing (see the following figure):

• The HARQ Ack/Nack;

• The CQI (Channel Quality Indication).

CQI

Subframe #0 Subframe #i Subframe #4

1 radio frame = 10ms

Tslot = 2560 chips = 10 bits

ACK/NACK

2.Tslot = 5120 chips = 20 bits

Figure 29: HS-DPCCH structure

The HARQ Ack is possibly repeated in consecutive HS-DPCCH subframes using the N_acknack_transmit parameter, as specified in [R05] §6A.1.1.




Parameter ackNackRepetitionFactor Object HsdpaUserService Range & Unit [1..4] User Customer Class 3

Granularity RNCl

Value 1

The CQI is only sent in some specific subframes, as specified in [R05] §6A.1.1, depending on the following parameters:

• The CQI feedback cycle: k,

• The repetition factor of CQI: N_cqi_transmit.

Parameter cqiRepetitionFactor Object HsdpaUserService Range & Unit [1..4] User Customer Class 3

Granularity RNCl

Value 1

Parameter cqiFeedbackCycleK Object HsdpaUserService Range & Unit Enum {0, 2, 4, 8, 10, 20, 40, 80, 160} ms User Customer Class 3

Granularity RNC

Value 2

Rule: cqiRepetitionFactor and cqiFeedbackCycleK

These parameters have to respect the following rule:

cqiRepetitionFactor ≤ cqiFeedbackCycleK / 2

Note that cqiFeedbackCycleK = 0 is not supported.

Parameter cqiPowerOffset Object HsdpaUserService Range & Unit [0..8] User Customer Class 3

Granularity RNC

Value 5

Parameter ackPowerOffset Object HsdpaUserService Range & Unit [0..8] User Customer Class 3

Granularity RNC

Value 6




Parameter nackPowerOffset Object HsdpaUserService Range & Unit [0..8] User Customer Class 3

Granularity RNC

Value 7

Engineering Recommendation: HS-DPCCH power

Note that power allocated on the HS-DPCCH can be different for each data (Ack, Nack or CQI) through the power offset parameters: ackPowerOffset, nackPowerOffset and cqiPowerOffset. The nackPowerOffset has to be higher than the other power offset in order to secure the reception of Nack, a Nack misdetection being unfavorable when TCP retransmission occurs.

3.3.2.3.2 CQI

The HS-DPCCH channel contains the CQI computed by the mobile from P-CPICH power measurements. This CQI after demodulation and decoding by the NodeB (noted CQIreported) is directly used by the scheduler.

HS-DPCCH demodulationand CQI decoding

CQI adjustment based on BLER (to reach a BLER target)

and HS-DPCCH activity (in order to deactivatedeficient UE by artificially setting its CQI to 0)

CQIreported

CQIprocessed

HS-DPCCH demodulationand CQI decoding

CQI adjustment based on BLER (to reach a BLER target)

and HS-DPCCH activity (in order to deactivatedeficient UE by artificially setting its CQI to 0)

CQIreported

CQIprocessed

Figure 30: CQI Processing

CQI ADJUSTMENT

Two algorithms have been introduced to handle bad UE behaviors that would disrupt the system. Note that in the nominal case, these algorithms should not have any impact.

The purpose of these algorithms is respectively to:

• Adjust the received CQI (CQIreported) in order to maintain an acceptable BLER on first transmission.




• Isolate a deficient UE which never responds (constant DTX detection).

Both algorithms are processed just after the CQI report and can be processed in any order. The resulting CQI from both steps (referred as CQIprocessed in the document) constitutes the input of both flow control and scheduler algorithms (except HS-SCCH power control).

CQI ADJUSTMENT ACCORDING TO BLER

Principle

A CQI BLER adaptation algorithm has been introduced in UA4.2. The idea was to compute an offset to apply on reported CQI in order to keep the BLER on first transmission within an acceptable range (typically between 0 and 30%).

In UA5.0, the purpose of the feature “HSDPA performance enhancements – Configurable CQI adjustment according to BLER target algorithm” is to put the parameters of this algorithm at the OMC-B so that the operator can tune its BLER target. The tuning of the algorithm is made though the following parameters:

• hsdpaBlerTargetUpperLimit : defines the expected BLER target.

• hsdpaBlerObservationWindow : corresponds to the update period of the CQI offset

• hsdpaBlerStepSize : it corresponds to step in dB applied upon reception of NACK. In case of ACK, the step is a function of this parameter and of the BLER target.

• hsdpaCqiBlerAdjustmentAlgo : this parameter is used to deactivate the feature:

o 0: deactivated.

o 1: blerRangeBasedAlgo. It corresponds to UA4.2 algorithm, with no possible parameterization, for iso-functional introduction.

o 2: outerLoopLikeAlgo. It corresponds to the proposed evolution.

The UA4.2 algorithm was rather a defense algorithm than a solution converging towards an exact BLER target. Simulations showed that convergence is not guaranteed when the range is too small for instance. A slight evolution is then proposed along with parameterization of the algorithm, enabling to define and converge towards a specific BLER target (and not a range).

The main principle still remains, i.e. computation and use of a DeltaCqi, but the way and the frequency this variable is updated changes:

- A CQI offset is computed and applied on the received CQI.




- This offset is updated according to received feedback for first transmission, ACK or NACK only.

- This offset is now updated as an outer-loop-like algorithm. Up (resp. down) steps are applied upon reception of ACK (resp. NACK). The steps are computed in accordance to the defined BLER target.

- Anytime a CQI is received, the offset is applied and the resulting value constitutes the entry point of the scheduler.

Algorithm

The new algorithm needs some new parameters:

“BlerTarget” corresponds to the BLER target configured by the operator. BlerTarget is set to hsdpaBlerTargetUpperLimit (OMC-B parameter).

“DeltaCqi” corresponds to the offset applied to the reported CQI. It is derived from “DeltaCqiCur” any “CountCqi”.

“DeltaCqiCur” corresponds to the current value of the offset, updated anytime a feedback is received from a first transmission.

“CountCQI” corresponds to the update period. CountCQI is set to hsdpaBlerObservationWindow (OMC-B parameter).

“DownStep” (<0) is the step to update “DeltaCqiCur” when a NACK is received.

“UpStep” (>0) is the step to update “DeltaCqiCur” when an ACK is received.

In order to converge to the right BLER target, DownStep and UpStep are determined by the following rules:

If (hsdpaCqiBlerAdjustmentAlgo = 0) // deactivated

DownStep = 0;

UpStep = 0;

Else

if BlerTarget = 100

DownStep = 0;

UpStep = hsdpaBlerStepSize

Else

DownStep = - hsdpaBlerStepSize

UpStep = - DownStep*BlerTarget/(100-BlerTarget)

Following steps are then performed:




• Anytime feedback information is received from a scheduled UE, DeltaCqiCur is updated:

o If ACK, DeltaCqiCur is increased by UpStep.

o If NACK, DeltaCqiCur is decreased by DownStep

o If DTX, no update (as in UA4.2).

• Any CountCQI ACK/NACK information received, DeltaCqi is updated. The rounded valued of DeltaCqiCur, bounded by limits (±5), is added to DeltaCqi.

DeltaCqi variation between two updates is limited to ±5 (CQI) because the wide range of OMC-B parameters may lead to an algorithm divergence for certain set of values (e.g. large update period with a big step).




The following figure summarizes the CQI offset computation:

Figure 31: CQI adjustment to BLER algorithm

Parameters:

Parameter hsdpaCqiBlerAdjustmentAlgo Object HSDPAConf Range & Unit [deactivated, blerRangeBasedAlgo, outerLoopLikeAlgo] User Customer Class 3

Granularity BTSCell

Value outerLoopLikeAlgo




Engineering Recommendation: hsdpaCqiBlerAdjustmentAlgo

Bler Target algo (outerLooLikeAlgo) brings gain in specific cases because his setting (Bler target value) depends on several factors : number of simultaneous ue, ue cat., CQI distribution.

That why UA4.2 algo is recommended because his performances are good in most cases.

Parameter hsdpaBlerTargetUpperLimit Object HSDPAConf Range & Unit [[0..100]] % User Customer Class 3

Granularity BTSCell

Value 30

Parameter hsdpaBlerObservationWindow Object HSDPAConf Range & Unit [1..500] Decimal (TTIs) User Customer Class 3

Granularity BTSCell

Value 10

Parameter hsdpaBlerStepSize Object HSDPAConf Range & Unit [0.1..3.0] step:0.1 User Customer Class 3

Granularity BTSCell

Value 0.1

HS-DPCCH PRESENCE DETECTION

In UA5.0, the feature “HSDPA performance enhancements – HS-DPCCH detection based on CQI” is introduced to detect the presence of HS-DPCCH based on CQI in order to schedule the UE only when HS-DPCCH decoding is reliable enough to get valid CQI information and correctly decode ACK/NACK.

It is necessary for Compressed Mode in Mac-hs feature to introduce a detection algorithm on CQI.

This algorithm manages two states: HSDPA Synchronized and HSDPA-Not Synchronized. Main principles of the algorithm are the following:

− The initial state is considered as not synchronized (HSD _OUT_SYNC), i.e. nothing has been yet received on HS-DPCCH.

− To acquire the synchronization on the HS-DPCCH (HSD_IN_SYNC), N successive CQI must be detected.

− Once in that HSD_IN_SYNC state, CQI are taken into account in the MAC-hs. In case of DTX, the last decoded value is kept.

− If M successive expected CQI are not detected (DTX), then the UE falls into the HSD_OUT_SYNC state.




− During that HSD_OUT_SYNC state, the UE must not be scheduled anymore. CQI still remains to be detected & decoded in order to reactivate the UE if possible (back to step 2). If ACK/NACK is expected during that out-of-synchronization period from previously transmitted transport blocks, they must be decoded and taken into account for HARQ process update. Pending retransmissions are nevertheless not transmitted and are stored until the HSD_IN_SYNC state is back. Finally, during that state, no Capacity Allocation should be sent to the RNC.

Note: At the beginning of the communication, the UE is considered as unsynchronized as long as no valid CQI sequence is received. No Capa alloc is sent during that time, and that may delay a little bit the effective activation.

In case the CQI falls into an UL transmission gap (compressed mode), it must not be taken into account for this algorithm, i.e. neither as DTX nor as detected.

The following flowchart summarizes the state change triggers.

Figure 32: HS-DPCCH synchronization algorithm

The HS-DPCCH synchronization algorithm is activated thanks to the bit 1 of the RxDemodulation parameter:

- bit 1 = 0 ⇒ ON - HS-DPCCH synchronization based on CQI is activated

- bit 1 = 1 ⇒ OFF - HS-DPCCH synchronization based on CQI is deactivated

This algorithm is activated by default. As the parameter is class 0, it then cannot be changed online.

Parameter RxDemodulation Object BTSEquipmentl Range & Unit [0..2147483647] Decimal User Customer Class 0

Granularity BTS

Value 0 or 71582784 (see Recommedation below for details)




This parameter is used to activate/deactivate 3 features as follows:

Bit0 :

• 0: Activate the common Layer1 UL enhancement algorithm.

• 1: do not activate the common activate Layer1 UL enhancement algorithm

Bit 1 :

• 0: H-BBU detection of the HS-DPCCH presence based on CQI ON

• 1: H-BBU detection of the HS-DPCCH presence based on CQI OFF

Bit 2 :

• 0 : enhanced demodulation for high speed UE OFF

• 1 : enhanced demodulation for high speed UE ON

All other Bit values are reserved.

Engineering Recommendation: RxDemodulation

In order to activate/deactivate one of the features mentioned above, follow the table below in most of HSxPA deployment scenarios:

RxDemodulation value common Layer1 UL

enhancement

HS-DPCCH presence

detection

enhanced

demodulation for high

speed UE

3 OFF OFF OFF

2 ON OFF OFF

1 OFF ON OFF

7 OFF OFF ON

5 OFF ON ON

6 ON OFF ON

0 ON ON OFF

4 ON ON ON

M and N values are hard coded and fixed to 2 (for both)

When coming back into the HSD_IN_SYNC state, scheduler cost function must be reinitialized (both costs set to respective lower cost of active QIDs).




3.3.3 HSUPA

3.3.3.1 UL LOAD MANAGEMENT

The uplink load management is a key step towards E-DCH deployment. Indeed the uplink should be correctly estimated and allocated for R99 and E-DCH traffic.

As for HSDPA, the R99 traffic has the priority over E-DCH traffic. Therefore the uplink load unused by R99 is allocated for E-DCH scheduling.

The UL load is computed based on the Node B thermal noise that is the RTWP when there is no UL traffic (RTWPref).

UL load = 1 –RTWPref/ RTWP = 1 – 1/Noise Rise

RTWPref depends on several factors such as NodeB configuration, cable length, TMA usage or not, temperature. Therefore, a self learning algorithm has been implemented that keeps tracking this parameter every day based on the average of the minimum samples of RTWP observation. This algorithm is activated by default.

Parameter isRtwpReferenceSelfLearning Object BTSEquipment Range & Unit False, True User Customer Class 3

Granularity Cell

Value True

Note that the reference RTWP is not transmitted to the RNC. Therefore the non E-DCH RTWP transmitted through NBAP common message assumed a default value for the thermal noise:

NBAP RTWPnon E-DCH = -106.1 + RoTnon-EDCH

Parameter rtwpReference Object BTSCell Range & Unit [-115.0..-50.0] step:0.1 dBm User Customer Class 3

Granularity Cell

Value -106.1

The parameter rtwpReference is the reference of RTWP when the BTS does not receive any radio signal for this cell. If the parameter isRtwpReferenceSelfLearning is set to TRUE, this parameter is only used to initiate the RTWP self learning feature.

The noise rise is expressed as:

Noise rise = RTWP/RTWP ref




Figure 33: Noise Rise vs. UL Load

The maximum allowable UL load should not set too high. It should not set to a too low value in order no to impact the E-DCH capacity. A correct value is between 50 and 80% (i.e. 3 and 7 dB noise rise).

Thermal Noise

CS12.2

CS12.2

PS64

CS64

Max allowed UL load

Available UL load for E-DCH scheduling

RS

SI

Figure 34: Example of uplink load (thermal noise/R9 9/E-DCH)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

2

4

6

8

10

12

14

16

18

20

UL load

Noi

se R

ise

(dB

)

Noise Rise vs. UL load




There are two parameters that defined the maximum UL load, one for R99 and one for HSUPA.

Parameter totalRotMax Object FDDCell Range & Unit [0..20] step:0.1 (db) User Customer Class 2

Granularity Cell

Value 6

Parameter rtwpMaxCellLoadNonEdch Object BTSCell Range & Unit [0..100] (%) User Customer Class 3

Granularity Cell

Value 50 (%)

Note that there is the referenceRtwp parameter in FDDCell (whereas rtwpReference is in BtsCell ) that is only used internally by the NodeB in order to compute the difference between the RTWP max (= referenceRtwp + totalRotmax) and the RTWP min (=referenceRtwp). So, his value is not meaningful but to be coherent referenceRtwp is equal to rtwpReference .

Rule: Max UL Load:

The non E-DCH maxload should be lower or equal to the total max load:

rtwpMaxCellLoadNonEdch <= 1 – 1/10^(totalRotMax/10)

If this rule is not respected, the E-DCH cell setup will fail.

Rule: Max UL Load:

The max uplink load should not be higher than 8 dB, otherwise the system is not stable:

totalRotMax <= 7 dB

This corresponds to 80% max uplink load for R99 and E-DCH traffic.

The non E-DCH RTWP is estimated and averaged over 100 ms period. It is based on the RTWP estimation minus the E-DCH contribution:

DCHEDCHnonE RTWPRTWPRTWP −− −=




When the RTWP exceeds the maximum allowed RTWP (totalRoTMax) by more than the RTWP margin and during a period of at least rtwpTimeDetection, all E-DCH UE are de-granted.

ALARM

totalRoTMax

rtwpMarginRoT

Time

rtwpTimeDetection

OKOK

Parameter rtwpMargin Object BTSCell Range & Unit [0.5..2.0] step:0.5 dB User Customer Class 3

Granularity Cell

Value 2 dB

Parameter rtwpTimeDetection Object BTSCell Range & Unit [100..400] step:100 ms User Customer Class 3

Granularity Cell

Value 400 ms

Engineering Recommendation: Uplink power control

The recommendation are the following:

- PowerCtrlAlgo = Algo1 in RNC / RadioAccessService / DedicatedConf / PowerCtrlConf / UlInnerloopConf

- minSirTarget = maxSirTarget = initialUlSirTarget = 6.7dB for HSUPA+SRB3.4 in order to disable OLPC

- minSirTarget = initialUlSirTarget = 5.5dB and maxSirTarget = 6.7dB for HSUPA+AMR or +CS in order to limit the OLPC




Parameter isRtwpAdjustmentForRnc Object BTSEquipment Range & Unit False, True User Customer Class 3

Granularity Cell

Value True

This parameter indicates if the BTS does a correction of the RTWP before reporting it to RNC in the NBAP COMMON MEASUREMENT REPORT If the parameter is set to TRUE, the correction is: -106.1 + (Rtwp_measured - rtwpReferenceOrSelfLearned) Example : isRtwpReferenceSelfLearned is set to TRUE. The selfLearned rtwpReference is measured by the BTS to -105dBm. The BTS read a RTWP of -100dBm --> The BTS will report: -106.1 + (-100 + 105) = -101.1 dBm (instead of -100)

3.3.3.2 SCHEDULING

3.3.3.2.1 REFERENCE E-TFCI

The user is allowed to use a subset of authorized E-TFCI. 4 transport block tables have been defined by 3GPP TS25.321 for MAC-e. Only 2 are available in UA5.0 (10 ms TTI).

Parameter edchTfcsTableIndex Object EdchTfcConf Range & Unit 2msTtiTable0, 2msTtiTable1, 10msTtiTable0, 10msTtiTable1 User Customer Class 3

Granularity RNC

Value 10msTtiTable1

Rule: edchTfcsTableIndex

The edchTfcsTableIndex recommended value (10msTtiTable1) has to be filed in all EdchTfcConf instances (0…7).

Note that there are 128 different TFCS defined for the table 10msTtiTable0 and 121 for 10msTtiTable1.




Figure 35: 3GPP Transport Block table (TTI 10 ms)

For each E-TFCI transport block, there is one associated transport block. In order not to signal all possible transport blocks (up to 128). Only a subset of these transport blocks are signaled as reference, other transport blocks are obtained through interpolation as specified in 3GPP:

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2

x 104

0

5

10

15

20

25

30

TB size (bits)

E-D

PD

CH

pow

er r

elat

iv t

o D

PC

CH

(dB

)

E-DPDCH power vs. transport block size

Reference signaled E-TFCI

Figure 36: E-DPDCH Power vs. Transport Block Size




A reference signaled E-TFCI contains a couple of values: the transport block index and its associated amplitude from [R14]:

Signaled values for ∆E-DPDCH Quantized amplitude ratios Aed =βed/βc

29 168/15 28 150/15 27 134/15 26 119/15 25 106/15 24 95/15 23 84/15 22 75/15 21 67/15 20 60/15 19 53/15 18 47/15 17 42/15 16 38/15 15 34/15 14 30/15 13 27/15 12 24/15 11 21/15 10 19/15 9 17/15 8 15/15 7 13/15 6 12/15 5 11/15 4 9/15 3 8/15 2 7/15 1 6/15 0 5/15

Table 20: Reference Signaled E-TFCI

Parameter referenceEtfci Object ReferenceEtfciList Range & Unit [0:127] User Customer Class 3

Granularity RNC

Value cf. table below

Parameter referenceEtfciPowerOffset Object ReferenceEtfciList Range & Unit [0:29] User Customer Class 3

Granularity RNC

Value cf. table below




ReferenceEtfciList referenceEtfci referenceEtfciPowerOffset

0 0 2

1 3 11

2 11 15

3 85 22

4 90 29

Table 21: referenceEtfci & referenceEtfciPowerOffse t

Rule: ReferenceEtfciList

The above ReferenceEtfciList table and associated recommended values for referenceEtfci & referenceEtfciPowerOffset has to be filed in all EdchTfcConf instances (0…7).

Parameter powerOffsetForSchedInfo Object EdchUserService Range & Unit [0..6] User Customer Class 3

Granularity RNC

Value 6

3.3.3.2.2 GRANT COMPUTATION

E-DCH scheduling is performed through E-AGCH signaling. The E-AGCH contains the grant information for one given user. The grant is the maximum allowed power transmitted on the E-DPDCH. Note that this takes also into account multiple physical E-DPDCH (2xSF4).

The grant index value belongs to the following table from [R04]:




Absolute Grant Value Index (168/15)2x6 31 (150/15)2x6 30 (168/15)2x4 29 (150/15)2x4 28 (134/15)2x4 27 (119/15)2x4 26 (150/15)2x2 25 (95/15)2x4 24 (168/15)2 23 (150/15)2 22 (134/15)2 21 (119/15)2 20 (106/15)2 19 (95/15)2 18 (84/15)2 17 (75/15)2 16 (67/15)2 15 (60/15)2 14 (53/15)2 13 (47/15)2 12 (42/15)2 11 (38/15)2 10 (34/15)2 9 (30/15)2 8 (27/15)2 7 (24/15)2 6 (19/15)2 5 (15/15)2 4 (11/15)2 3 (7/15)2 2

ZERO_GRANT* 1 INACTIVE* 0

Table 22: Grant Index values

Once the grant is signaled, the E-DPDCH power should not exceed the grant information:

2. edn β < signaled grant value

Where n stands for the number of E-DPDCH physical channels.

The HSUPA scheduler monitors the available UL load. An average value of the UL RTWP is available once every 100 ms.

The grant sent to each UE is decided based by the HSUPA scheduler based on:

• UL load available for HSUPA

• Number for E-DCH UE asking for grant allocation

• Scheduling information transmitted by each UE. The scheduling information are transmitted periodically on the E-DPDCH according to periodicityOfSchedInfoGrant and periodicityOfSchedInfoNoGrant (depending on whether the UE is granted or not): They contain the following information:




o User power headroom that is the ratio between max UE transmitted power and the DPCCH power quantized in 5 bits.

o Max bit rate capabilities

o User buffer quantized in 5 bits.

• Happy bit : this bit is transmitted on the E-DPCCH and represents the UE state according to his current max grant notification.

• E-BBU capacity limitations.

The resulting maximum grant allocation is the minimum of all grant allocations provided by each of the step described above and is sent on one E-AGCH (RNTI and Grant info).

Parameter periodicityOfSchedInfoGrant Object EdchUserService Range & Unit EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000 User Customer Class 3

Granularity RNC

Value 50

Parameter periodicityOfSchedInfoNoGrant Object EdchUserService Range & Unit EveryEdchTti, 4, 10, 20, 50, 100, 200, 500, 1000 User Customer Class 3

Granularity RNC

Value 10

Parameter happyBitDelay Object EdchUserService Range & Unit Enum {2, 10, 20, 50, 100, 200, 500, 1000} User Customer Class 3

Granularity RNC

Value 50

3.3.3.2.3 MAC-E SCHEDULER

The Mac-e scheduling (located in the E-BBU in the Node B) of the different E-DCH users of the cell is done by providing absolute grants (E-AGCH channel) when the cell is the serving cell of the call. Each UE will adapt its throughput on E-DPDCH according to the grants it has received, by selecting an E-TFC in the E-TFCS that is compatible with the power granted.

The grants are computed by the scheduler to provide some fairness between users. They are limited by the fact that the global uplink interferences level from must not go above a certain threshold (totalRotMax – over which the system might become instable and might diverge) and by the BTS processing capabilities dedicated to E-DCH. The main target of the scheduler is to grant UEs so that the total UL load of the cell stays near the target load (totalRotMax ), but not above. If the uplink load gets above this limit, then the scheduler will reduce the grants of the E-DCH links. In case of radio “overload” (due to other traffics: CCH, DCH, inter-cell interferences and other interferences), the grants of E-DCH users get down to 0 (ZERO_GRANT) in order to avoid radio divergence and all H-ARQ processes are ACKED to avoid retransmissions




and stop traffic as soon as possible. The radio overload condition is defined by the fact by the UL load is above the RTWPlimit (totalRotMax + rtwpMargin ) during a certain time (rtwpTimeDetection ). If the UL load is below the limit then the E-DCH UEs may be granted more.

When the grants of a UE are modified, the MAC-e scheduler reevaluates the contribution of this UE to the uplink load so that the load shall stay near the target load (totalRotMax ) without exceeding it. If it happens that the UE has not correctly decoded the E-AGCH channel, it may use incorrect grants. If it uses too low grants, this situation cannot be detected by the scheduler and the UE will experience a lower throughput until it is granted again. In order to limit the effect of this issue, the scheduler will resent the grants periodically (~500ms) if they do not change. If the UE uses too important grants, then the Node B will not be able to decode correctly the data (since hardware resources have not been reserved for such transport blocks) but it will detect this situation from the E-TFCI used by the UE and will resent immediately the grants to the UE.

In case grants are reduced, this will reduce the load of the system and will free resources for other E-DCH users. However the UE which grants have been reduced will continue using former grants for ongoing H-ARQ retransmissions, meaning that resources cannot be reallocated immediately to other users.

Two kinds of scheduler are available :

• rate scheduling scheme

• time scheduling scheme (not supported in UA5.0)

Parameter edchSchedulerAlgorithm Object EdchConf Range & Unit Enum {roundRobinSlidingWindow, rateScheduling}


Granularity Cell

Value rateScheduling

Rate scheduler :

In this scheme, all E-DCH active users (having data to transmit) are transmitting (having grants) simultaneously. They share resources in a fair way,the general principle being that :

• hardware resources are shared equally between all active cells (containing at least one active user)

• hardware resources assigned to an active cell are shared equally between all active users of this cell

• the cell load (apart from R99 part) is shared equally between all active users of this cell

Grants are modified when :

• the number of active user changes (one becomes active or one becomes inactive)

• R99 uplink radio load has changed significantly

• Periodically, each T_Threshold_TTI (100ms) for UEs that are granted above the fairness index

• Periodically each 500ms




Time Scheduler :

In this scheme, users are granted in a time-multiplexing scheme : each user is granted for a part of the time and degranted (ZERO_GRANT) for the rest of the time. The total period is computed in order to serve all active users. The advantage of this method is that it allow a UE to be granted at the maximum resources (eg : 2xSF4) because it does not have to share them with many other users.

For more details, see [R09].

Restriction: UL throughput not stable with 1 E1

In UA5.0, 2 E1 per NodeB are needed to perform HSUPA fairness distribution when there are several users. The best targetted throughputs in HSUPA multi-users environment can be reached assuming there is no Iub bandwidth limitation. In UA6.0, the feature UL Flow Control on NodeB will ensure a fair sharing ressources on Iub in case of BW shortage.

3.3.3.3 DL POWER MANAGEMENT

For E-DCH, three new downlink channels have been defined: E-AGCH, E-HICH and E-RGCH (knowing that E-RGCH is not supported in this release).

At RNC level, the E-DCH channels are reserved as done for common channels. This power is not accessible for DCH traffic at RNC call admission.Therefore this power is pre-empted from R99 capacity. The RNC will reserve power for E-AGCH and E-RGCH/E-HICH according the following figure:

CCCRNC

SHO margin

Ptraffic

RN

C

OCNS (opt.)

PminHsdpa

PMaxCell

Max Power for HS-DSCH& HS-SCCH, E-AGCH,E-HICH and E-RGCHto be transmittedto the NodeB

E-DCH

CCCRNC

SHO margin

Ptraffic

RN

C

OCNS (opt.)

PminHsdpa

PMaxCell

Max Power for HS-DSCH& HS-SCCH, E-AGCH,E-HICH and E-RGCHto be transmittedto the NodeB

E-DCH

Figure 37: Power allocation at RNC level

This E-DCH power is defined by the parameter eagchErgchEhichTotalPower .




Parameter eagchErgchEhichTotalPower Object EdchCellClass Range & Unit [0.0..50.0] step:0.1 dBm User Customer Class 0

Granularity RNC

Value 10 dBm

At NodeB level, the downlink power for E-AGCH, E-RGCH/E-HICH channels is dynamically allocated on a 2 ms basis when there is a need to address E-DCH users on these channels. The power that is not used by these channels can be used for HSDPA downlink channels (HS-SCCH and HS-PDSCH).

In this release, these channels are not power controlled and are transmitted at a predefined power. Power control mode could be activated for each DL channels though the following parameters located in edchConf:

eagchPowerControlMode

ehichPowerControlMode

ergchPowerControlMode

When Power control mode is ON, power for each DL channels is relative to the pilot bits on the DL DPCCH channel (edchCellClass) through:

eagchPowerOffset

ehichPowerOffset

ergchPowerOffset

In this release power for each DL channel is fixed and defined by the following parameters (relative to P-CPICH power):

eagchPower is the power allocated for one e-agch channel (up to 3 E-AGCH can be used). At each TTI, only one UE can be addressed on each E-AGCH code.

Parameter eagchPower Object EdchConf Range & Unit [-35.0..15.0] step:0.1 dB User Customer Class 3

Granularity Cell

Value -2.5

ehichPowerSignature is the power allocated for one E-HICH signature (up to 15 E-HICH signatures can be used).

Parameter ehichPowerSignature Object EdchConf Range & Unit [-35.0..15.0] step:0.1 dB User Customer Class 3

Granularity Cell

Value -8.0 dB




ergchPowerSignature is the power allocated for one E-RGCH signature (up to 15 E-RGCH signatures can be used)

Parameter ergchPowerSignature Object EdchConf Range & Unit [-35.0..15.0] step:0.1 dB User Customer Class 3

Granularity Cell

Value -22.0 dB

Note that even if E-RGCH is not supported, ergchPowerSignature has to be set with a value higher than -22dB in order to succeed a NodeB power check.

The DL HSUPA power has to be linked with the number of E-AGCH and E-HICH/E-RGCH channels. The BTS can make use of 3 E-AGCH or E-HICH/E-RGCH channels at maximum.

Parameter maxNrOfEagch Object EdchCellClass

Range & Unit Integer [1..8] User Customer Class 0

Granularity RNC

Value 1

Parameter maxNrOfErgchEhich Object EdchCellClass

Range & Unit Integer [1..8] User Customer Class 0

Granularity RNC

Value 1

Note that E-HICH and E-RGCH share the same OVSF code(s). UEs are differentiated by the signature. One E-BBU can handle up to 15 E-DCH users (ie. 15 radio-links with E-DCH) for all cells that the E-BBU manages. Number of signature can not excess the maximum number of mobiles authorized in the cell




3.4 UE CATEGORIES

3.4.1 HSDPA

3GPP has standardized several UE categories to accommodate a large spectrum of HSDPA mobile implementations (see [R12]). The UE category provides the mobile capabilities like max number of HS-PDSCH codes supported, modulation schemes (16QAM, QPSK), MAC-HS transport block size, etc.

HS-DSCH category Maximum number of HS-DSCH

codes received

Minimum inter-

TTI interval

Maximum number of bits of an HS-DSCH

transport block received within an HS-DSCH TTI

Total number of

soft channel bits

Category 1 5 3 7298 19200 Category 2 5 3 7298 28800 Category 3 5 2 7298 28800 Category 4 5 2 7298 38400 Category 5 5 1 7298 57600 Category 6 5 1 7298 67200 Category 7 10 1 14411 115200 Category 8 10 1 14411 134400 Category 9 15 1 20251 172800 Category 10 15 1 27952 172800 Category 11 5 2 3630 14400 Category 12 5 1 3630 28800

Table 23: HSDPA UE categories (3GPP TS25.306)

UEs of Categories 11 and 12 support QPSK only.

Each UE category has a table with 30 CQI (channel quality indicator) values. Each CQI value provides complete information regarding the HS-DSCH to be received by UE in DL in the next TTI.

Transport Block Size Optimization

When a UE is scheduled, the applied MCS (transport block size, number of codes, modulation and reference power) depends on the reported CQI. Correspondence between both is defined in CQI mapping tables. In UA4.2, reference tables provided in [R05] are used.

In most cases, these defined transport block sizes lead to a high number of padding bits with the MAC-d PDU sizes used (336 or 656 bits).




Figure 38: Padding bits in the Mac-hs PDU

The purpose of the feature “HSDPA performance enhancement – Optimization of transport block sizes” is then to define new CQI mapping tables, depending on the MAC-d PDU size. These are provided in Appendix A and B.

These new tables are activated via the following class 3 OMC-B parameters:

Parameter ueCategoryX X = [1..12]

Object HsdpaUeCategoryTransportBlockOptimisation

Range & Unit

True, False


Granularity BTSCell

Value True (for the desired categories)

Note that such activation is independent per UE category and only part of them can then be optimized.

UE Category support

The features “UE Cat 7&8 support” and “UE Cat 9&10 support” consist in supporting these categories of UE up to their maximum capability, with Mac-d PDU size equal to 336 bits. The support of Mac-d PDU size 656 bits is also required for demonstration purposes. With UE cat 9&10, for iCEM, it is only necessary to be able to provide 15 codes 16QAM for a single UE, addressing at least a transport block size equal to 21648 bits.

UE Cat 7&8 support

No specific development is required for this feature. Capabilities of the H-BBU already allow (since UA4.2) configuring the maximum throughput to a UE cat 7 or 8 in case a single cell is active in the H-BBU: maximum transport block size = 14411 bits, i.e. 42 PDUs @ 336 bits or 21 PDUs @ 656 bits per TTI, reached for a CQI 25 with CQI mapping tables implemented, reminded in appendix C and D.

Some tests must be performed in order to check whether the MAC-d PDU size 656 bits with such category is supported. Note that the scope is only for demonstration purposes, the test area might then be restricted.

320 1621 320 16 Padding

Mac-d SDU = Mac-d PDU

Mac-hs SDU

Mac-hs PDU = 1TTI

RLC SDU

320 16




Note: There is a 3GPP limitation regarding the number of MAC-d PDUs that can be allocated in a Capacity Allocation: 2046 PDUs. This means that in order to provide the maximum bit rate for a single UE of category 7 or 8, the hsdschInterval parameter must be set inferior or equal to:

- 90ms with 336-bits MAC-d PDU size (2046/42*2)

- 190ms for 656-bits MAC-d PDU size.

UE Cat 9&10 support

For both categories, some tests must be performed in order to check whether the MAC-d PDU size 656 bits is supported. Note that the scope is only for demonstration purposes, the test area might then be restricted.

New parameters introduction impacts all internal interfaces.

CQI mapping tables are reminded in appendix C and D for both UE categories.

UE Cat 9

Capabilities of the H-BBU already allow (since UA4.2) configuring the maximum throughput of a UE cat 9 in alignment with the CQI mapping tables referred in [R03] This nevertheless only provides a configuration with 12 codes and a maximum throughput below its capabilities (8.6Mbps vs. 10.1Mbps). It can then be envisaged to change this CQI mapping table with the following parameters for CQI 27 to 30, in order to be able to provide the maximum bit rate in good radio conditions1.

A class 3 parameter (ueCategory9 in hsdpaMaxUeCategoryCapabilityActivation object) is defined at OMC-B to activate or not this CQI mapping table update.

Nb of MAC-d PDUs CQI Transport Block Size

Number of HS-PDSCH

Modulation Ref. Power Adjustment ∆∆∆∆

336 bits 656 bits

27 20251 15 16QAM 0 60 30

28 20251 15 16QAM -1 60 30

29 20251 15 16QAM -2 60 30

30 20251 15 16QAM -3 60 30

Table 24: CQI mapping table update for UE cat 9

Note: There is a 3GPP limitation regarding the number of MAC-d PDUs that can be allocated in a Capacity Allocation: 2046 PDUs. This means that in order to provide the

1 The maximum bit rate must be understood as the maximum transport block size in a TTI. The throughput

depends on other UEs in the cell and parameterization of SPI.




maximum bit rate for a single UE cat 9, the hsdschInterval parameter must be set inferior or equal to:

- 60ms with 336-bits MAC-d PDU size

- 130ms for 656-bits MAC-d PDU size.

UE Cat 10

The maximum bit rate of UE cat 10 cannot be provided by current iCEM software. Moreover, the capabilities only allow to provide up to 12 codes to a single UE with CQI mapping tables defined in [R05]. It is then necessary to upgrade the H-BBU capability in order to be able to assign up to 15 codes to transmit 64 PDUs. The minimum capability that should be provided in term of max number of (transport block) bits per TTI per cell is 21754 bits .

A class 3 parameter (ueCategory10 in hsdpaMaxUeCategoryCapabilityActivation object) is defined at OMC-B to activate or not this CQI mapping table update .

Note: There is a 3GPP limitation regarding the number of MAC-d PDUs that can be allocated in a Capacity Allocation: 2046 PDUs. This means that in order to provide the maximum bit rate for a single UE cat 10, the maximum possible value for the hsdschInterval parameter is

- 60ms with 336-bits MAC-d PDU size for iCEM

- 130ms with 656-bits MAC-d PDU size for iCEM.

Restriction

The maximum RLC throughput with UE category may be limited (limit around 4-4.5 Mb/s) due to the RLC window size limitation.

Against RLC window size limitation, prohibitedStatusTimer parameter can be decreased (from 70ms to 30ms) or PDU size can be increased (from 336 bits to 656 bits) in order to reach higher throughput.

Decrease the prohibitedStatusTimer leads to increase the uplink Status traffic (impact has to be study especially in multi-ue scenario).

PDU size of 656 bits :

- was not available in UA4.2

- is available in UA5.0 but with RLC reconfiguration not supported (demo only)

- will be available in UA5.1 without reconfiguration (if needed, DCH fallback may appear)

- will be available in UA6/0 with reconfiguration




3.4.2 HSUPA

For HSUPA, the following UE categories have been specified in 3GPP [R12]:

E-DCH category

Maximum number of

E-DCH codes

transmitted

Minimum spreading

factor

Support for 10 and 2 ms

TTI EDCH

Maximum number of bits of an E-DCH transport block

transmitted within a 10 ms E-DCH TTI

Maximum number of bits of an E-DCH transport block

transmitted within a 2 ms E-DCH TTI

Category 1 1 SF4 10 ms TTI only

7110 -

Category 2 2 SF4 10 ms and 2 ms TTI

14484 2798


14484 -


20000 5772


20000 -


20000 11484

NOTE: When 4 codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4

Table 25: HSUPA UE categories (3GPP TS25.306)

Restriction: HSUPA UE categories supported in UA5.0

In UA5 only category 1, 2, 3, and 5 are supported

In UA5.0 only TTI 10 ms is supported.

In UA5.0 up to 2 x SF4 is supported, thus UE category 5 can be served up to 1.4 Mb/s.

In term of bit rate, we can expect a maximum MAC-e throughput of:

• 1.4 Mbits/s for TTI = 10 ms

• 5.76 Mbits/s for TTI = 2 ms (Not Applicable to UA5.0)

And a maximum RLC throughput for 10 ms TTI of:

• Category 1: 672 kb/s

• Category 3 & 5: 1362 kb/s




3.5 CALL MANAGEMENT

HSxPA only applies to the PS domain meaning that all the CS domain RABs are supported on dedicated channels (DCH).

The Utran supports only the Traffic Classes Interactive & Background on HSDPA. So, the TC Streaming is served on DCH.

Moreover, only the mono RB PS I/B are mapped on HSDPA implying that any combination of RB PS I/B with RB CS call or with any other RB PS I/B (Multi PS) is served on DCH.

System behavior RB Configuration

UA4.2 UA5.0

All RABs DCH available in HSDPA Cell

Supported: no impact coming from HSDPA. All RAB combinations existing in this release are available on DCH in an HSDPA cell (either for a mobile that does not support HSDPA or for a RAB combination that is not supported on HSDPA)

PS I/B on HSDPA Supported Supported

(PS I/B+PS I/B) on HSDPA

Not supported on HSDPA � channel is mapped on DCH Supported

PS Streaming on HSDPA

Not supported on HSDPA � channel is mapped on DCH

Speech on DCH + PS I/B on HSDPA


CSD/DCH + PS I/B on HSDPA


Speech on DCH + (PS+PS) on HSDPA


(PS I/B+PS Streaming) on HSDPA

Not supported on HSDPA � channel is mapped on DCH

Table 26: HSDPA RB Configuration and system behavio r




RB Configuration System behavior

All RABs DCH available in HSUPA Cell

Supported: no impact coming from HSDPA. All RAB combinations existing in this release are available on DCH in an HSDPA cell (either for a mobile that does not support HSDPA or for a RAB combination that is not supported on HSDPA)

PS I/B on HSUPA Supported

(PS I/B+PS I/B) on HSDPA

Not supported on HSUPA � channel is mapped on DCH

Speech on DCH + PS I/B on HSUPA

Supported

Speech on DCH + (PS+PS) on HSUPA

Not supported on HSUPA � channel is mapped on DCH

CSD/DCH + PS I/B on HSDPA

Supported

Table 27: HSUPA RB Configuration and system behavio r

3.5.1 MULTI-CARRIER MANAGEMENT

3.5.1.1 OVERVIEW

To increase the network capacity, operators may deploy multi-layer configurations with several layers structures:

• Multi-layers with equal coverage,

• Hot spots micro or pico cells,

Moreover, the introduction of HSUPA in UA5.0 networks will be also progressive with hot spots and there is a real need to redirect HSDPA/HSUPA capable mobile (R5, R6) towards the appropriate layer.




2G

FDD2

FDD1 HSDPA only

HSUPA

2G

FDD2

FDD1 HSDPA only

HSUPA

Figure 39: Example of multi-layer structure

UA5.0 makes use of several features in order to distribute the traffic between the different layers including 2G (GSM, CDMA):

• RRC Traffic Segmentation, already present in UA4.2, allows redirecting UE at RRC connection establishment, based on their release and possibly on the Traffic Class sent to RNC in RRC Connection Request message.

• Hierarchical Cell Structure (HCS), newly introduced in UA5.0, allows prioritizing cell layers for mobiles in idle mode, Cell_FACH and URA/Cell_PCH connected modes. The cell reselection algorithm also takes into account UE speed so that fast moving UEs can be placed in large cells to avoid excessive cell reselections.

• Intelligent Multi-Carrier Traffic Allocation (iMCTA), newly introduced in UA5.0, eventually allows redirecting UE to another layer when in Cell_DCH connected mode:

o In case of coverage gap,

o In case of RAB establishment failure,

o After Service Type change, Intra-frequency mobility or Always-On upsize.

For both HCS and iMCTA, please refer to:

• UTRAN Parameters User Guide,[R01], in order to have a complete view of mechanism and setting.




3.5.1.2 RRC TRAFFIC SEGMENTATION

In case HSxPA is deployed on one frequency layer on top of the R99/R4 layer, it shall be possible to redirect UEs on the proper frequency layer at call setup depending on its capabilities and requested establishment cause:

• an HSxPA capable UE (R5/R6) camping on a R99 cell is re-directed to the HSxPA layer

• similarly, a R99/R4 UE camping on a HSxPA cell can be redirected to the R99 layer

This feature impacts the choice of the target cell and the frequency layer at the call establishment.

The main benefits are to allow HSxPA capable mobiles to benefit from HSxPA service and to avoid loading the HSxPA layer with R99/R4 mobiles.

This algorithm has not evolved from UA4.2, i.e. RNC only makes the difference between R99/R4 UEs and the other ones (i.e. R5 or R6). As a consequence, RRC redirection never occurs for the 2 following topologies:

• one cell is HSDPA-capable and the twin cell is HSUPA-capable

• both twin cells are HSDPA capable

TRAFFIC SEGMENTATION MECHANISM:

Redirection is only performed by RNC at RRC connection establishment phase based on the twin-cell configuration (redirection during the call is performed with iMCTA, cf.[R01]). Such feature can be activated using isRedirectionForTrafficSegmentation activation flag.

Emergency calls are never redirected and are served on the layer selected by the mobile to limit the probability of call setup failure.

TRAFFIC SEGMENTATION CRITERIA:

Two filtering can be operated in order to execute the redirection on the suitable layer:

• First criterion is based on the Access Stratum Release Indication IE in the RRC Connection Request message for the identification of the R99/R4 mobiles versus the R5/R6 mobiles.

• Second optional criterion is based on the Establishment Cause IE in the RRC Connection Request message to distinguish the calls I/B potentially served on HSxPA from the others.

This filtering is not necessarily representative of the service setup during the life time of the RRC connection (for example, UE may establish RRC connection in order to perform a CS call and then establish a HSxPA I/B RAB on the same RRC connection).




TRAFFIC SEGMENTATION PROCEDURE:

When receiving RRC Connection Request message, RNC identifies:

• the UE Release via the ‘Access Stratum Release indicator IE’, knowing that:

o R99/R4 mobiles do not support HSxPA configuration

o Sending this IE is not mandatory for R99/R4 mobiles as per 3GPP

• the requested service via the ‘Establishment Cause IE’ knowing that traffic class Conversational and Streaming can not be served on HSxPA layer. This filtering is optional depending on the setting of the parameter isRedirectionBasedOnEstablishmentCause

So, based on the information of Access Stratum Release indicator and Establishment Cause IE, the RNC can start the redirection procedure for the R5/R6 mobiles requesting a PS I/B session.

The redirection consists in indicating the target frequency in the RRC Connection Setup message via the ‘Frequency Info IE’, frequency corresponding to the twin cell’s.

UE will send the RRC Connection Setup Complete towards the twin cell on the right layer.

The following table depicts the decision taken by RNC depending on the value of both parameters:

• isRedirectionForTrafficSegmentation

• isRedirectionBasedOnEstablishmentCause




isRedirectionForTrafficSegmentation InterFreqHhoFddCell object FALSE TRUE

FALSE No redirection is performed

• R5 mobile is re-directed to HSDPA cell • R99 mobile is re-directed to non-HSDPA cell

In all cases, “emergency” cause calls are not redirected.

isR

edire

ctio

nBas

edO

nEst

ablis

hmen

tCau

se

TRUE No redirection is performed

• R5 mobile with establishment cause “Conversational” or “Streaming” is redirected to non-HSDPA cell

• R5 mobile with establishment cause “Interactive”, “Background”, “Originating Subscribed Traffic Call”, “Registration” or “Originating High Priority Signalling” is redirected to HSDPA cell

• R5 mobile with establishment cause other than the above are not re-directed

• R99 mobile is re-directed to non-HSDPA cell In all cases, “emergency” cause calls are not redirected.

Table 28: Summary of RNC detection regarding RRC Tr affic Segmentation

Hereafter the static mapping between the Establishment cause sent by the mobile in the RRC Connection Request and the suitable layer pointed by RNC:




Cause Suitable layer Meaning

Originating Conversational Call DCH

Originating Streaming Call DCH

Originating Interactive Call HSxPA

Originating Background Call HSxPA

Originating Subscribed traffic Call HSxPA

Request for access following a request for service expressed by the mobile user

Terminating Conversational Call DCH

Terminating Streaming Call DCH

Terminating Interactive Call HSxPA

Terminating Background Call HSxPA

Request for access, following a paging indication received by the mobile.

Emergency Call DCH or HSxPA

(i.e. no re-direction) Speech emergency mobile originated call

Inter-RAT cell re-selection DCH or HSxPA

(i.e. no re-direction) User location registration following an inter-

system cell reselection

Inter-RAT cell change order DCH or HSxPA

(i.e. no re-direction)

User location registration following an inter-system cell change commanded by the

source system

Registration HSxPA Request for user registration, following a

mobile power-on

Detach DCH or HSXPA

(i.e. no re-direction) Request for user de-registration, following a

mobile power-off Originating High Priority

Signalling HSxPA

Originating Low Priority Signalling

DCH or HSXPA (i.e. no re-direction)

Access request for signalling exchange (e.g. SMS)

Call re-establishment – CS case DCH or HSXPA


Access requested for service re-establishment (due to loss of radio

connection)

Call re-establishment – PS case DCH or HSXPA

(i.e. no re-direction) Routing Area update due to "directed

signalling call re-establishment" RRC release Terminating High Priority

Signalling DCH or HSXPA

(i.e. no re-direction) Terminating Low Priority

Signalling DCH or HSXPA


Access request for network initiated signalling exchange (e.g. SMS)

Terminating – cause unknown DCH or HSXPA

(i.e. no re-direction) This cause is received when no paging cause

is provided from the Core Network.

Table 29: RRC Connection Request and suitable layer




PARAMETERS:

isRedirectionForTrafficSegmentation : This parameter is used by RRC traffic segmentation feature, in order to redirect mobiles to the adequate layer according to the UE release indicator.

Parameter isRedirectionForTrafficSegmentation Object InterFreqHhoFddCell Range & Unit Boolean

{True, False} User Customer Class 3

Granularity FDDCell

Value TRUE

isRedirectionBasedOnEstablishmentCause : This parameter is used by the traffic segmentation feature in order to take into the establishment cause if the redirection algorithm.

Parameter isRedirectionBasedOnEstablishmentCause Object InterFreqHhoFddCell Range & Unit Boolean


Granularity FDDCell

Value TRUE

Restriction:

RRC Traffic Segmentation does not distinguish HSDPA-capable and HSUPA-capable cells. Therefore, this feature can not be applied to a NodeB with 2 dedicated carriers, one for HSDPA and another for HSUPA. isRedirectionForTrafficSegmentation must then be set to FALSE for such a topology.

3.5.1.3 IMCTA

iMCTA is an algorithm allowing to allocate traffic across 3G and 2G layers; it is invoked at the following events:

• an alarm condition is reached, so-called iMCTA Alarm

• CAC failure at RAB establishment/release, so-called iMCTA CAC

• after a successful RAB establishment/release, an Always-On upsize or a Primary Cell change, to move the call to a more appropriate carrier, so-called iMCTA Service

Once triggered, iMCTA requests UE to perform either inter-frequency or inter-system measurements, following the analysis of:

• 3G and 2G neighborhoods

• UE and FDD HSxPA capabilities

• The priority for each carrier of the requested service type, through Priority Table as depicted hereafter:




Priority Table

CS

speech

CS conv. CS streaming PS

streaming

PS

I/B

CS speech +

other

FDD1 P2 P1 P1 P1 P2 P2

FDD2 P3 P2 P2 P2 P1 P1

2G P1 PNA P3 P3 P3 P3

Table 30: iMCTA Priority Table

iMCTA eventually triggers HHO towards one of the reported cell depending on the originating and target cell loads, the capabilities of the reported cell…

iMCTA Alarm and CAC are not specific to HSxPA as they do not distinguish R99 from R5/R6 mobiles.

HSxPA specific mechanisms are part of iMCTA Service as it fully allows to allocate traffic on different layers based on mobile and FDD HSxPA-capabilities and through 3 different Priority tables:

• Service Priority Table for HSUPA

• Service Priority Table for HSDPA

• Service Priority General Table (i.e. for R99 mobiles)

3.5.2 HSXPA CAC

3.5.2.1 RAB MATCHING

Any PS RAB request with Interactive or Background traffic class is matched to the HSDPA/HSUPA Radio Bearer configuration if the mobile is HSDPA/HSUPA capable and the primary cell of the active set supports HSDPA/HSUPA.

- If the HSUPA is not supported in the cell (but the HSDPA is present), the request is mapped on: UL DCH/DL HSDPA.

- If neither HSUPA nor HSDPA are supported in the cell, the request is mapped on: UL/DL DCH (iRM CAC is performed).

3.5.2.2 ADMISSION PHASE

As today, this mechanism is triggered by the reception of RAB Assignment Request and follows the RAB matching process.




In this implementation, the specific CAC admission process in the RNC for HSDPA/HSUPA is based on the number of simultaneous authorized users per cell to limit the degradation of the quality of service. So, iRM CAC is not played for HSDPA/HSUPA RAB.

3.5.2.2.1 RNC CAC

Any Interactive/background RAB request is admitted on HSDPA until the maximum number of simultaneous users allowed on HSDPA is reached for the cell. Unlike the iRM CAC performed for the RB mapped on DCH channels, the admission on HSDPA doesn’t take into account any other criterion like RF power.

Same for HSUPA, any Interactive/background RAB request is admitted on HSUPA until the maximum number of simultaneous users allowed on HSDPA is reached for the cell.

The RNC performs the HSDPA CAC before checking the HSUPA resources availability. Once HSDPA CAC has been done, the RNC performs the admission on the associated UL HSUPA or UL DCHs (if HSUPA not available):

• Regarding DL SRB admission, CAC is performed as usual

• Regarding UL SRB admission, CAC is performed as usual

• Regarding UL DCH admission, CAC is performed as usual.

In case of RNC CAC failure (not enough HSDPA or HSUPA resources), the HSPA to DCH fallback mechanism is triggered (see section 3.5.2.3))

Parameters:

maximumNumberOfUsers : Used for the HSDPA CAC done by the RNC. The number of users is per cell

Parameter maximumNumberOfUsers Object HsdpaCellClass Range & Unit Integer [0..100]


Granularity RNC

Value 100

By default this parameter is set to 100 (when the value is set to 100 the RNC CAC is deactivated, i.e. NodeB performs the Call Admission Contro) which is highly above the H-BBU capacity limit (48).

edchMaxUsersPerCell Used for the HSUPA CAC done by the RNC. The number of users is per cell




Parameter edchMaxUsersPerCell Object EdchCellClass Range & Unit Integer [0..64]


Granularity RNC

Value 15

Engineering Recommendation: edchMaxUsersPerCell

The recommended value (15) is in-line with the E-BBU capacity limitation (worst case scenario when all HSUPA active users are in one cell)

Restriction: edchMaxUsersPerCell does not trigger RNC CAC

RNC CAC is not triggered in case edchMaxUsersPerCell is reached (RNC parameter). Therefore, maximum number of E-DCH users is only controlled through BTS parameters edchMaxNumberUserEbbu and edchMaxNumberUserNodeB (BTSEquipment parameter), cf. section 8.1.1.2.1.

3.5.2.2.2 NODEB CAC

Once the RNC CAC passed, the NodB is requested for CEM resources allocation through Radio Link Reconfiguration procedure (see call setup call flow in the section 3.5.5)

The CEM resources are split between HSDPA and HSUPA:

- HSDPA resources are handled by H-BBU function (see 8.1.1.1)

- HSUPA resources are handled by E-BBU function (see 8.1.1.2)

Each of these modules has some capacity limitations and this capacity is limited through some sets of parameters (see 8.1.1.1.1 for H-BBU parameters and 8.1.1.2.1 for E-BBU parameters).

If one of the E-BBU or H-BBU limit is reached, the BTS will send a RL Reconfiguration Failure (meaning NodeB CAC failure)

In case of BTS CAC failure (not enough HSDPA or HSUPA resources), the HSPA to DCH fallback mechanism is triggered (see section 3.5.2.3))

3.5.2.3 HSPA TO DCH FALLBACK

HSPA to DCH fallback feature allows establishing or reconfiguring the PS I/B RAB into DCH in case of HSDPA or HSUPA CAC failure (see section 3.5.2.2). The following HSxPA CAC failure scenarios trigger such a fallback:

• RAB assignment (to establish or to release)

• IU release




• Primary cell change

• Inter-RNC UE involved Hard Handover

• Alarm Hard Handover

Restriction:

HSPA to DCH fallback at Always-On upsize is not supported in UA5.0. However, fallback at Always-On upsize is triggered when a second RAB is being established (either CS or PS).

RNC tries and remaps a call establish “fall-backed to DCH RAB” onto HSDPA or HSUPA in the following cases:

• RAB assignment (to establish or to release a second RAB)

• Primary Cell change

• Inter-RNC (UE involved or not) HHO

In case HSPA to DCH fallback is disabled, any HSxPA CAC failure leads to an IU-PS Release procedure.

Note that HSPA to DCH fallback is only processed when RNC is acting as Serving RNC. When acting as Drift RNC, any HSPA CAC failure leads to a RNSAP Radio Link Reconfiguration or Setup Failure.

3.5.2.3.1 FALLBACK MECHANISM:

In case of HSPA CAC failure, i.e. lack of resources, HSPA to DCH fallback feature allows reconfiguring UL and/or DL into DCH as if UE was not HSUPA and/or HSDPA capable, mainly based on failure causes:

• Internal to RNC: maximum number of HSDPA or HSUPA users

• External to RNC: NBAP or RNSAP failure causes

For the HSxPA CAC failure scenarios mentioned above, when RNC receives NBAP RadioLinkReconfigurationFailure, DCH fallback is systematically triggered whatever the NBAP cause (even for NodeB_resource_unavailable), as 3GPP does not specificy anything for the usage of such NBAP causes.

However, when receiving a cause that gives specific information on UL or DL, RNC directly takes the good decision, depending on the different permissions presented below.

HSDPA is directly reconfigured into DCH whereas 2 steps can be provisioned for HSUPA through edchToDchFallbackSteps parameter:

• MonoStep to directly reconfigure HSUPA into DCH




• MultiStep to try and reconfigure first into HSDPA (and then into DCH in case of HSDPA CAC failure)

HSDPA or HSUPA to DCH fallbacks can be activated through hsdpaToDchFallbackPermission or edchToDchFallbackPermission parameters:

• NoFallBack: feature is deactivated

• RabAssignment: fallback only occurs at RAB assignment procedure and IU release

• Mobility: fallback only occurs at Primary Cell change and HHO

• AnyCase corresponds to both RabAssignment and Mobility scenarios

3.5.2.3.2 PARAMETERS SETTINGS AND RECOMMENDATIONS:

hsdpaToDchFallbackPermission : This parameter defines the scope where a Fallback on DCH is tried when a failure occurred due HSDPA CAC resource shortage.

Parameter hsdpaToDchFallbackPermission Object RadioAccessService Range & Unit Enum

{NoFallBack, RabAssignment, Mobility, AnyCase} User Customer Class 3

Granularity RNC

Value AnyCase

edchToDchFallbackPermission : This parameter defines the scope where a Fallback on DCH is tried when a failure occurred due HSUPA CAC resource shortage.

Parameter edchToDchFallbackPermission Object RadioAccessService Range & Unit Enum

{NoFallBack, RabAssignment, Mobility, AnyCase} User Customer Class 3

Granularity RNC

Value AnyCase

edchToDchFallbackSteps : This parameter defines whether a fallback on DCH is Multi-steps (i.e. first fallback attempt to HSDPA and then to DCH) or Mono-step (i.e. direct fallback to DCH).

Parameter edchToDchFallbackSteps Object RadioAccessService Range & Unit Enum

{MonoStep, MultiStep} User Customer Class 3

Granularity RNC

Value MultiStep




Engineering Recommendation: hsdpaToDchFallBackPermission and edchToDchFallBackPermission

Both permissions should be set to AnyCase in order to improve Accessibility and Retainability.

WARNING:

The 2 following activation flags are still present in RAN model: isHsdpaToDchFallbackAllowed and isEdchToDchFallbackAllowed . Please note that these two parameters are NOT used and will be removed from RAN model in the next release.

3.5.3 SUPPORTED TRANSITIONS REGARDING HSXPA BEARERS

3.5.3.1 SUPPORTED TRANSITION REGARDING HSDPA BEARER S

The following tables provide the supported transition regarding HSDPA Bearers.

3.5.3.1.1 RB ADDITION

Initial State Requested service to add Result

CS PS I/B HSDPA CS + PS I/B HSDPA

PS I/B HSDPA CS CS + PS I/B HSDPA

PS I/B HSDPA PS I/B PS I/B HSDPA + PS I/B HSDPA

CS + PS I/B HSDPA PS I/B CS + PS I/B HSDPA + PS I/B HSDPA

CS PS I/B HSDPA + PS I/B HSDPA CS + PS I/B HSDPA + PS I/B HSDPA

PS I/B AOds (FACH) CS CS + PS I/B HSDPA

(Ao State is reset)

PS I/B AOds (FACH) PS I/B PS I/B HSDPA + PS I/B HSDPA

(Ao State is reset)

3.5.3.1.2 RB DELETION

Initial State Requested service to release Result

CS + PS I/B HSDPA PS I/B CS

PS I/B HSDPA + PS I/B HSDPA PS I/B HSDPA + PS I/B HSDPA Sig (DCH)





(or Iu PS release command)

CS + PS I/B HSDPA + PS I/B HSDPA

PS I/B HSDPA + PS I/B HSDPA

(or Iu PS release command)

CS

CS + PS I/B AOds CS PS I/B AOds

CS + PS I/B HSDPA CS PS I/B HSDPA

PS I/B HSDPA + PS I/B HSDPA PS I/B HSDPA PS I/B HSDPA

CS + PS I/B HSDPA + PS I/B HSDPA

PS I/B HSDPA CS + PS I/B HSDPA

PS I/B HSDPA PS I/B HSDPA Sig (DCH)

3.5.3.1.3 ALWAYS ON DOWNSIZE

Always On Downsize is not applicable to HSDPA with MultiRAB. Therefore, if a AO downsize is triggered while in such configuration, the configuration is unchanged, and AO step 2 trigger is then applied.

Initial State AO trigger Result

PS I/B HSDPA Downsize PS I/B AOds FACH

CS + PS I/B HSDPA Downsize CS + PS I/B HSDPA

(AO Step 1 not applicable to this configuration)

PS I/B HSDPA + PS I/B HSDPA Downsize PS I/B HSDPA + PS I/B HSDPA


3.5.3.1.4 ALWAYS ON UPSIZE

Since AO downsize may not have happen in case of HSDPA MultiRAB Combination, AO upsize may not lead to a HSDPA MultiRab Combination

Initial State AO Trigger Result

PS I/B AOds Cell_FACH Upsize PS IB HSDPA

3.5.3.2 SUPPORTED TRANSITION REGARDING HSUPA BEARER S

The following tables provide the supported transition regarding HSUPA Bearers.




3.5.3.2.1 RB ADDITION

Initial State Requested service to add Result

CS PS I/B EDCH CS + PS I/B EDCH

PS I/B EDCH CS CS + PS I/B EDCH

PS I/B EDCH PS I/B (PS I/B + PS I/B) on DCH

CS + PS I/B EDCH PS I/B CS + (PS I/B + PS I/B) on DCH

PS I/B AOds (FACH) CS CS + PS I/B EDCH

(Ao State is reset)

PS I/B AOds (FACH) PS I/B (PS I/B + PS I/B) on DCH

3.5.3.2.2 RB DELETION


CS + PS I/B EDCH PS I/B CS

CS + PS I/B EDCH CS PS I/B EDCH

(PS I/B + PS I/B) on DCH PS I/B PS I/B EDCH

CS + (PS I/B + PS I/B) on DCH PS I/B CS + PS I/B EDCH

3.5.3.2.3 ALWAYS ON DOWNSIZE

Always On Downsize is not applicable to HSUPA with MultiRAB. Therefore, if a AO downsize is triggered while in such configuration, the configuration is unchanged, and AO step 2 trigger is then applied.


CS + PS I/B EDCH Downsize PS I/B AOds FACH

CS + PS I/B EDCH Downsize CS + PS I/B EDCH


3.5.3.2.4 ALWAYS ON UPSIZE


PS I/B AOds Cell_FACH Upsize PS IB EDCH




3.5.3.3 RLC RECONFIGURATION PROCEDURE

3.5.3.3.1 HSDPA CASE

It is possible to trigger an RLC reconfiguration after a channel type switching between DCH and HS-DSCH. This reconfiguration is optional and is useful to tune the RLC settings (like timers) to the characteristics of the transport channel. It only applies to the RB corresponding to the PS I/B RAB (so only RLC AM parameters) and RLC PDU size cannot be changed.

When it is associated to a RB Reconfiguration procedure (due to mobility or Always-On), it is done simultaneously with the transport channel reconfiguration (synchronous reconfiguration).

When it is associated to a RB addition/deletion (due to RAB assignment/release, with PS I/B RAB already established and not affected), it cannot be performed simultaneously with the RB addition/deletion . It is performed afterwards as a stand-alone procedure, using a RB Reconfiguration procedure. It is possible to use either a synchronous or an asynchronous procedure.

Summary of RLC Reconfiguration procedure events during HSDPA related transitions:

• dch ↔ hs-dsch:

o case of mobility to or from a non-hsdpa cell:

RLC Reconfiguration is simultaneously performed with the synchronized RB Reconfiguration procedure via the parameter deltaCfnForHsdpaChannelTypeSwitching and is conditioned to the activation flag value isRLCReconfigurationForChannelTypeSwitching

o case of addition/release CS/PS when PS hsdpa is on-going:

RLC Reconfiguration is performed in a synchronous way after the RB Reconfiguration to setup the new transport channel information. The RLC reconfiguration is triggered via the parameter deltaCfnForHsdpaRLCReconfiguration (if deltaCfnForHsdpaRLCReconfiguration =0, the rlc reconfiguration becomes an a-synchronous procedure).

• fach ↔ hs-dsch:

RLC Reconfiguration is simultaneously performed with the a-synchronized RB Reconfiguration procedure and is conditioned to the activation flag value isRLCReconfigurationForChannelTypeSwitching .




• hs-dsch ↔ hs-dsch:

No RLC Reconfiguration because the transport channel keeps unchanged but the establishment of the radio link on the new primary cell supporting hsdpa needs a synchronized RB reconfiguration via the parameter deltaCfnForHsdpaMobility .

Restriction:

• DL RLC PDU size is not changed (such a reconfiguration needs to re-establish the RLC entities so lose all PDUs under transmission).

• The RNC RLC Queue Size is never reconfigured. The implication is that if a R5 mobile is performing the RAB Assignment procedure in non-HSDPA cell, the RLC Queue Size of the resulting (DCH) RBSetConf would be retained for the duration of the call, even if the user is subsequently transitioned to a HSDPA cell.

Parameters:

isRLCReconfigurationForChannelTypeSwitching : Activation of the RLC reconfiguration after a channel type switching related to release or addition of another RAB.

Parameter isRLCReconfigurationForChannelTypeSwitching Object HsdpaRncConf Range & Unit Boolean


Granularity RNC

Value True

deltaCfnForHsdpaMobility : Delta CFN used for HS-DSCH creation when primary cell is changed.

Parameter deltaCfnForHsdpaMobility Object HsdpaRncConf Range & Unit Integer

[0..255] (x10ms) User Customer r Class 3

Granularity RNC

Value 45

deltaCfnForHsdpaChannelTypeSwitching : Delta CFN used for SRLR due to channel type switching between DCH and HS-DSCH

Parameter deltaCfnForHsdpaChannelTypeSwitching Object HsdpaRncConf Range & Unit Integer

[0..255] (x10ms) User Customer Class 3

Granularity RNC

Value 80




deltaCfnForHsdpaRLCReconfiguration : Delta CFN used for RLC reconfiguration when done in stand-alone (0 means asynchronous reconfiguration).

Parameter deltaCfnForHsdpaRLCReconfiguration Object HsdpaRncConf Range & Unit Integer


Granularity RNC

Value 0

3.5.3.3.2 HSUPA CASE

It is possible to trigger an RLC reconfiguration after an uplink channel type switching between DCH/RACH and E-DCH. This reconfiguration is optional and is useful to tune the RLC settings (like timers) to the characteristics of the transport channel. It only applies to the RB corresponding to the PS I/B RAB (so only RLC AM parameters) and RLC PDU size and RLC queue size cannot be changed.

In case a channel type switching is also performed in the downlink (HS-DSCH <-> DCH/FACH) a bi-directional reconfiguration is performed. If there is no channel type switching in the downlink, then a mono-directional reconfiguration is performed.

In case of E-DCH to RACH transition on Always-On downsize, the RLC parameters used for the reconfiguration are the ones of the reference DCH radio bearer. This is needed in case the UE further moves to a primary cell that is not E-DCH capable and is then upsized (to DCH), it will use RLC parameters suited for this radio bearer (since no RLC reconfiguration is done on the RACH->DCH uplink reconfiguration). In case the UE stays with an E-DCH-capable primary cell, RLC will be reconfigured to E-DCH values on the upsizing from RACH to E-DCH.

When it is associated to a RB Reconfiguration procedure (due to mobility or Always-On), it is done simultaneously with the transport channel reconfiguration (synchronous reconfiguration).

When it is associated to a RB addition/deletion (due to RAB assignment/release, with PS I/B RAB already established and not affected), it cannot be performed simultaneously with the RB addition/deletion because it is not possible to reconfigure an existing RB. It is performed after as a stand-alone procedure, using a RB Reconfiguration procedure. It is possible to use either a synchronous or an asynchronous procedure.




Restriction:

• UL RLC PDU size is not changed (such a reconfiguration needs to re-establish the RLC entities so lose all PDUs under transmission).

• The UE RLC Queue Size is never reconfigured. The implication is that if a R6 mobile is performing the RAB Assignment procedure in non-E-DCH cell, the RLC Queue Size of the resulting (DCH) RBSetConf would be retained for the duration of the call, even if the user is subsequently transitioned to a e-DCH cell.

Parameters:

isRlcReconfigurationForChannelTypeSwitchingEdch : Activation of the RLC reconfiguration during a channel type switching between DCH and EDCH.

Parameter isRLCReconfigurationForChannelTypeSwitchingEdch Object EdchRncConf Range & Unit

Boolean {True, False}


Granularity RNC

Value True

deltaCfnForEdchAndHsdpaMobility : Delta CFN used for HSDPA+EDCH mobility when primary cell is changed and HSDPA+EDCH is following the primary cell.

Parameter deltaCfnForEdchAndHsdpaMobility Object EdchRncConf Range & Unit Integer

[0..255] (x10ms) User Customer r Class 3

Granularity RNC

Value 150

deltaCfnForEdchChannelTypeSwitching : Delta CFN used for SRLR due to channel type switching of Edch only. (HSDPA configuration is not impacted in this case, otherwise use deltaCfnForEdchAndHsdpaChannelTypeSwitching )

Parameter deltaCfnForEdchChannelTypeSwitching Object EdchRncConf Range & Unit Integer


Granularity RNC

Value 150




deltaCfnForEdchAndHsdpaChannelTypeSwitching : Delta CFN used for SRLR due to channel type switching of both HSDPA and EDCH.

Parameter deltaCfnForEdchAndHsdpaChannelTypeSwitching Object EdchRncConf Range & Unit

Integer [0..255] (x10ms)


Granularity RNC

Value 150

deltaCfnForEdchRlcReconfiguration : Delta CFN used for RLC reconfiguration when done in stand-alone (0 means asynchronous reconfiguration).

Parameter deltaCfnForEdchRlcReconfiguration Object EdchRncConf Range & Unit Integer


Granularity RNC

Value 150

Engineering Recommendation: deltaCfnForEdchXXX

The rule of these parameters has to be deeper investigated in order to define the correct value. For the moment they are filed with default values

The decision will be based on field test results

3.5.4 MULTI-RAB HANDLING

3.5.4.1 MULTI-RAB HANDLING ON HSDPA


The feature Multi-Rab Handling on HSDPA brings service enhancements to the HSDPA Step1 feature introduced in V4.2.

UA4.2 call management was not fully HSDPA in terms of coverage, i.E. only single PS I/B on HSDPA was supported, implying transport channel switch between DCH and HS-DSCH on RAB addition or release.

HSDPA Multiservice introduces full support of HSDPA and thus avoids needs for transport channel switch between DCH and HS-DSCH on RAB addition or release: other RABs than the one to add or release are not impacted when calls is in Cell_DCH.

With this feature, RNC will be able to handle new configurations such as:

• CS speech DCH + PS i/b HSDPA

• CSD DCH + PS i/b HSDPA




• PS i/b HSDPA + PS i/b HSDPA [+CS speech]

• PS streaming DCH + PS i/b HSDPA [+CS speech]

These configurations have to be handled in any transitions cases:

• Rab Assign

• Rab Release

• Incoming Relocation

• Mobility HSDPA<-> DCH Cell

• Always On Upsize

• Etc.

Note :

• When having a PS + PS hsdpa configuration, 2 HS-DSCH Mac-d Flows are Established in NodeB

• Always On Step2 applies for Multi-Rab HSDPA configurations (no Step 1).

3.5.4.1.2 MULTI-RAB COMBINATION CONFIGURATION (HSDPA)

Firstly, a main activation flag allows to enable all multi RAB combinations using HSDPA (PS MUX on HSDPA and PS HSDPA + other):

Parameter isMultiRabOnHsdpaAllowed Object RadioAccessService Range & Unit

Boolean {True, False}


Granularity RNC

Value True

Note : when the feature is deactivated, then the resulting DluserService will be mapped on DCH only.

DlUserService instances corresponding to Combinations including HSDPA shall be enabled for the RAB Matching (parameter enabledForRabMatching in DlUserService )




Rule:

When the multiRab on HSDPA is activated, it is recommended to ensure that the related DlUserService are enabled for Rab Matching:

• Speech + HSDPA

• CSD + HSDPA

• PS Streaming + HSDPA

• Speech + PS Streaming + HSDPA

For each DlUserService , it is required to configure the allowed transitions from 1 single PS HSDSCH to PS + PS HSDPA Configuration:

• The only DluserService supporting PS HSDPA Mux are:

o PS HSDPA only

o CS Speech + PS HSDPA

• When the DluserService includes 1 PS Streaming, then PS HSDPA Mux is not allowed

For each DluserService :

• 3 HSDPACombinationList must be configured, corresponding to the number of PS HSDSCH supported by this service:

o HSDPACombinationList/0 � no PS HSDPA

o HSDPACombinationList/1 � 1 PS HSDPA supported with this DluserService

o HSDPACombinationList/2 � 2 PS HSDPA supported with this DluserService

• 2 HSDPACombinationEntry must be configured per HSDPACombinationList , corresponding to the number of PS Streaming over HSDPA Supported with this DlUserService :

o HSDPACombinationEntry/0 � no PS Streaming on HSDPA

o HSDPACombinationEntry/1 � PS Streaming over HSDPA is supported with this DlUserService

Note : PS Streaming over HSDPA is not supported in this version

The flag allowed in HSDPACombinationEntry determines if the related configuration is supported.




HSDPACombinationList HSDPACombinationEntry DlUserService

Instance Instance Allowed

0 False 0

1 False

0 True 1

1 False

0 True

PS_HSDSCHxSRB_3_4K

2 1 False

0 False 0

1 False

0 True 1

1 False

0 True

CS_AMR_NBxPS_HSDSCHxSRB_3_4K

2 1 False

0 False 0

1 False

0 True 1

1 False

0 False

PS_16k_STRxPS_HSDSCHxSRB_3_4K

2 1 False

0 False 0

1 False

0 True 1

1 False

0 False


2 1 False

0 False 0

1 False

0 True 1

1 False

0 False


2 1 False

PS_256k_STRxPS_HSDSCHxSRB_3_4K 0 0 False






1 False

0 True 1

1 False

0 False 2

1 False

0 False 0

1 False

0 True 1

1 False

0 False

CS_64k_HSDSCHxSRB_3_4K

2 1 False

0 False 0

1 False

0 True 1

1 False

0 False

CS_AMR_NBxPS_16k_STRxPS_HSDSCHxSRB_3_4K

2 1 False

0 False 0

1 False

0 True 1

1 False

0 False


2 1 False

0 False 0

1 False

0 True 1

1 False

0 False


2 1 False

0 False CS_AMR_NBxPS_256k_STRxPS_HSDSCHxSRB_3_4K 0

1 False






0 True 1

1 False

0 False 2

1 False

0 True 0

1 False

0 False 1

1 False

0 False

All other DluserService

(do not include PS_HSDSCH)

2 1 False

3.5.4.1.3 RESTRICTION ON COMBINATION STREAMING + HSDPA

UE are basically classified into 4 categories (TS 25.306):

• those that can support a maximum of 32kbps on DCH with a simultaneous HS-DSCH configuration,

• those that can support a maximum of 64kbps,

• those that can support a maximum of 128kbps,

• and those that can support a maximum of 384kbps.

As a consequence:

• UE with a maximum capability of 32kbps does not support:

o PS Streaming DL:64kbps/128kbps/256kbps+PS I/B (HS-DSCH)

o CSD 64 + PS I/B (HS-DSCH)


o PS Streaming DL:128kbps/256kbps+PS I/B (HS-DSCH)


o PS Streaming DL:256kbps+PS I/B (HS-DSCH)

For all the above related cases, the corresponding combinations with CS are not supported either.

There is no limitation for UE with a maximum capability of 384kbps.




The DL capability with simultaneous HS-DSCH configuration IE is ignored by the RNC in UA05. Consequently, there will be a failure if the RNC attempts to establish one of the previously listed combinations for the corresponding UE. To avoid this situation, it is possible to fallback all (CS+)PS Streaming+PS I/B combinations to DCH.

This option is not activated by default but there is a flag to activate it:

isPsStreamingOnHSDPAAllowed (radioAccessService)

When set to false, all PS I/B + PS Str combinations will be mapped into DCH.

3.5.4.2 MULTI-RAB HANDLING ON HSUPA


Unlike multi service on HSDPA, there is no activation flag to enable or disable the multi RAB on HSDPA.

The activation is to be done thought the parameter enabledForRabMatching in UluserService Object for the following instances:

• Speech + EDCH

• CSD + EDCH

• PS Streaming + EDCH

• Speech + PS Streaming + EDCH

Note : if the related UlUserServcie are not allowed to be used by the RAB Matching, there is no fallback on DCH, implying RAB Assignment Failure during RB Setup.

3.5.4.2.2 RESTRICTION ON COMBINATION STREAMING + HSUPA

UE Radio Access Capabilities specification (TS 25.306) includes UE UL DPCH Capability with simultaneous E-DCH information, which defines the modification of transmission capabilities in uplink in terms of DPCH in case an E-DCH is configured simultaneously.

TS 25.306 indicates that UE can only support a maximum of 64kbps on DCH with a simultaneous E-DCH configuration Hence the following combination is not supported (ie. no automatic fallback to 64kbps on DCH) :

• PS Streaming UL:128kbps+PS I/B (E-DCH)

• Corresponding combination with CS is not supported either.




As a consequence, there will be a failure if the RNC attempts to establish the previous combination.

To workaround this issue, it is possible to fallback all (CS+)PS Streaming + PS I/B combinations to DCH.

This workaround is not activated by default but there is a flag to activate it, isMonoDirectionalHsdpaRabAllowed (radioAccessService). When set to False, the combinations (CS+)PS Streaming + PS I/B HSDPA are fallbacked on (CS+)PS Streaming + PS I/B DCH.

3.5.5 CALL SETUP (DATAFLOW)

3.5.5.1 INITIAL CONNECTION PHASE:

There is nothing specific to HSDPA/HSUPA in this phase.

In the scenario of a mobile being redirected due to the traffic segmentation feature, the target frequency is indicated in the RRC Connection Setup (frequency info IE) but the call flow is the same.

SGSN Node B RNC UE

RRC/ RACH / RRC connection Request

(cause)

SCCP/ Connection Request (Initial UE msg (Activate PDP Context Request))

SCCP/ Connection Confirm

RRC/ FACH / RRC Connection Setup (DCCH, U-RNTI,

RRC state = CELL_DCH, [frequency info])

RRC/ RACH / RRC Connection Setup Complete

RRC/ RACH / Initial Direct Transfer (Activate PDP Context Request, PS domain)

The RRC Connection Setup message contains the

signalling bearers (DCCH) definition. A UTRAN

Radio Network Temporary Identity is also

allocated to the UE.

The target RRC state is set to CELL_DCH by the

RNC

If the mobile is redirected for traffic segmentation

reason then frequency info is included

In addition to the initial NAS message, the Initial Direct Transfer message

also contains the CN domain identity, used by the RNC to route the NAS

message to the relevant CN domain (i.e. CS or PS)

The RRC Connection Request message initiated

by the UE contains the establishment cause.

The initial UE message is piggybacked in the

SCCP connection resquest

NBAP/ RL Setup Request)

NBAP / RL Setup

Response

Figure 40: HSxPA Call setup / initial connection (C ell_DCH)




3.5.5.2 RAB ALLOCATION PHASE:

In this phase, only the NBAP Radio Link Reconfiguration procedure and RRC Radio Bearer Reconfiguration are modified because of HSDPA. Same dataflow is presented below for HSUPA (showing RL Reconfiguration modification for E-DCH))

SGSN Node B RNC UE

SM/ Activate PDP Context

Accept

GMM/ Authentication and Ciphering

Request GMM/ Authentication and Ciphering

Response

The UE is authenticated by the SGSN

RANAP/ Security Mode Command

RANAP/ Security Mode

Complete

RRC/ Security Mode Command

RRC/ Security Mode Complete

The ciphering and integrity procedures are activated by the MSC

The RNS supports the following algorithms:

• UIA1 for integrity

• UEA1 for ciphering

RANAP/ RAB Assignment Response

RANAP/ RAB Assignment Request (RAB param, binding Id)

The Radio Access Bearer assignment procedure

The RAB is now established. the mobile is now waiting for end-to-end

service accept.

RRC/ RB Setup (DCCH + DTCH,

HS-DSCH information)

RRC/ RB Setup Complete

The UE is provided with the new radio link

configuration. A new RAB (corresponding to the

new DTCH) is added to the current configuration

NBAP/ Radio Link Reconfiguration Request (

HS-DSCH Radio Link)

NBAP/ Radio Link Reconfiguration Ready (HS-SCCH codes allocated)

A HS-DSCH Radio Link is created as well as the

associated DCH

FP/ DL Synchronisation (CFN)

FP/ UL Synchronisation (ToA)

The DCH is synchronised

RANAP/ Common Id

(IMSI)

"Common Id" is used to provide the RNC with the user IMSI

NBAP/ Radio Link Reconfiguration Commit (

CFN)

Figure 41: HSDPA Call setup / RAB allocation phase (call establishment done on DCH)




SGSN Node B RNC UE

SM/ Activate PDP Context

Accept

GMM/ Authentication and Ciphering

Request GMM/ Authentication and Ciphering

Response

The UE is authenticated by the SGSN

RANAP/ Security Mode Command (UIAx, UEAy)

RANAP/ Security Mode

Complete

RRC/ Security Mode Command

RRC/ Security Mode Complete

The ciphering and integrity procedures are activated by the MSC

The RNS supports the following algorithms:

• UIA1 for integrity

• UEA1 for ciphering

RANAP/ RAB Assignment Response

RANAP/ RAB Assignment Request (RAB param, binding Id)

The Radio Access Bearer assignment procedure

The RAB is now established. the mobile is now waiting for end-to-end

service accept.

RRC/ RB Setup (E-DCH info, E-RNTI,

CFN)

RRC/ RB Setup Complete

The UE is provided with the new radio link

configuration. A new RAB (corresponding to the

new DTCH) is added to the current configuration

NBAP/ Radio Link Reconfiguration Prepare (

E-DPCH info, E-DCH FDD info, E-DCH mac-d flow to add, Serving

E-DCH RL, E-DCH RL indication=E-DCH, E-DCH Specific Info….)

NBAP/ Radio Link Reconfiguration Ready (E-DCH FDD info Response, E-DCH FDD DL

Control Channel …

The Radio Link is reconfigured to add the E-

DPCH in uplink in the serving cell. (The HS-

DSCH part is not shown)

RANAP/ Common Id

(IMSI)

"Common Id" is used to provide the RNC with the user IMSI

NBAP/ Radio Link Reconfiguration Commit (

CFN)

Figure 42: HSUPA Call setup / RAB allocation phase (call establishment done on DCH)




3.5.6 CALL RELEASE (DATAFLOW)

The call release is initiated either by the mobile or the network through a PDP context de-activation procedure, or by the RNC (Always-On step 2) through Iu Release Request.

Depending on the Core Network implementation, the UTRAN is released, either using an Iu release or a RAB release procedure.

3.5.6.1 IU RELEASE CASE

In such a case, the UTRAN resource release is requested by the Core Network through an Iu Release Command message.

On reception of this message:

• the RRC connection is released

• the HSDPA and associated HSUPA or UL DCH are released. A Radio Link Deletion request is sent to each of the BTS being part of the active set, including the BTS which supports the HS-DSCH.

3.5.6.2 RAB RELEASE CASE

In such a case the UTRAN resource release is requested by the Core Network through an RAB Assignment Request (cause RAB to release) message.

On reception of this message, as illustrated in the following picture:

• the RNC attempts a Radio Link Reconfiguration to remove the HSDPA MAC-d flow from the cell supporting it and

• a RB Release removes the HSDPA RB.




SGSN Node B RNC UE

GMM/ Deactivate PDP

context GMM/ Deactivate PDP context

accept

The SGSN asks for the release of the corresponding RAB.

In this example, this is the only RAB supported by the mobile

RANAP/ RAB Assignment request (RAB to release)

RANAP/ RAB Assignment request response

NBAP/ Radio Link Reconfiguration Prepare

(remove HSDPA MAC-d flow)

The radio link is re-configured (only primary cell).

RRC/ RRC Connection Release

NBAP/ Radio Link Deletion

Request NBAP/ Radio Link Deletion

Response

SCCP/ Released

RANAP/ Iu Release Complete

RANAP/ Iu Release Command

If isRABRelMgtAllowed is set to "false", the RNC requests for a

global Iu Release.

RRC/ RRC Connection Release Complete

Release of radio bearer and RRC connection

RANAP/ Iu Release Request

NBAP/ Radio Link Reconfiguration Ready

NBAP/ Radio Link Reconfiguration Commit

([activation CFN])

RRC/ RB Release (remove HSDPA ; [activation CFN])

RRC/ RB Release Complete

All the RLs of the active set are deleted

(so may imply several Node Bs)

Figure 43: Call release (RAB release case)




4 HSXPA CONFIGURATION

4.1 RAN MODEL AND PARAMETERS

4.1.1 HSDPA

4.1.1.1 RRM SUBTREE PARAMETERS

4.1.1.1.1 RADIOACCESSSERVICE

The path of this object is:

• RNC/§ RadioAcessService/0

Parameter User Class Unit Range

hsdpaToDchFallbackPermission Customer 3 N.A.

Enum [NoFallback; RabAssignment; Mobility; AnyCase]

isDynamicMacdPduSizeManagementAllowed Customer 3 Flag Boolean isHsdpaAllowed Customer 3 Flag Boolean isHsdpaHhoWithMeasAllowed Customer 3 Flag Boolean isHsdpaOverIurAsDrncAllowed Customer 3 Flag Boolean isHsdpaOverIurAsSrncAllowed Customer 3 Flag Boolean isHsdpaToDchFallbackAllowed Customer 3 Flag Boolean isHsPdschDynamicManagementAllowed Customer 3 Flag Boolean isHsxpaServiceIndicatorEnabled Customer 3 Flag Boolean isMonoDirectionalHsdpaRabAllowed Customer 3 Flag Boolean isMultiRabOnHsdpaAllowed Customer 3 Flag Boolean isPsStreamingOnHsdpaAllowed Customer 3 Flag Boolean

4.1.1.1.2 ALWAYSONTIMER


• RNC/§ RadioAcessService/0 AlwaysOnConf/0 AlwaysOnTi mer/0




timerT1ForHsdpa Customer 3 ms Integer [10...3600000] Step = 10

timerT1ForHsdpaAndEdch Customer 3 ms Integer [10...3600000] Step = 10

timerT2ForHsdpa Customer 3 ms Integer [10...10800000] Step = 10




timerT2ForHsdpaAndEdch Customer 3 ms Integer [10...10800000] Step = 10

timerT2ForMultiRabHsdpa Customer 3 ms Integer [10...10800000] Step = 10

4.1.1.1.3 DLRBSETCONF


• RNC/§ RadioAcessService/0 DlRbSetConf/PS_HSDSCH_IB

• RNC/§ RadioAcessService/0 DlRbSetConf/PS_HSDSCH_IB_ MUX

Parameter User Class Optional Unit Range

allowedDlRbSetForMatching Customer 3 TRUE N.A. Integer

dlIrmTableConfClassId Customer 3 TRUE Pointer ServiceLink: target = DlIrmTableConfClass

dlOutOfOrderSduDeliveryMethod Customer 3 FALSE N.A. Enum [InSequence; OutOfSequenceProprietary]

dlRbPduSizeList Customer 3 FALSE bytes List (1..4) Integer: min = 2, max = 625

dlRbPduSizeList Customer 3 FALSE bytes Integer List [1…4][2…625]

dlRbRateAdaptationDownsizeThreshold Customer 3 TRUE Kbits/s Integer [0...2048]

dlRbRateAdaptationUpsizeThreshold Customer 3 TRUE Kbits/s Integer [0...2048]

dlRlcQueueSize Customer 3 FALSE N.A. Integer [1...128]

dlSrbErrorMatching Customer 3 FALSE N.A. Integer [-3.00...4.00] Step = 0.01

dlSyncRetryPeriod Customer 3 FALSE ms Integer [0...65535]

enabledForRABMatching Customer 3 FALSE N.A. Boolean

endPoint Customer 3 FALSE ms Integer [0...2559]

fallbackRbRate Customer 3 FALSE Kbytes Integer [0...2048]

isAdaptiveRlcStatusFilterEnabled Customer 3 FALSE Flag Boolean

isAlwaysOnAllowed Customer 3 FALSE Flag

Enum [disabled; degraded2AlwaysOnOnly; releaseOnly]

isDlRbRateAdaptationAllowedForThisDlRbSetConf Customer 3 FALSE Flag Boolean

isDlReferenceTransportChannelAllowed Customer 3 FALSE Flag Boolean

isThisRbRateAdaptationDlRbSetTargetAllowed Customer 3 FALSE Flag Boolean




iubIurTransportQosId Customer 3 FALSE N.A. Integer [0...3]

iuCsTransportQosId Customer 3 FALSE N.A. Integer [0...3]

maxDlSyncRetries Customer 3 FALSE N.A. Integer [0...255]

nInit Customer 3 FALSE N.A. Integer [0...255]

periodicDlSyncInterval Customer 3 FALSE s Integer [0...65535]

reEstablishTimer Customer 3 FALSE N.A. Enum [reestablishTimerUseT314; reestablishTimerUseT315]

rlcConfClassId Customer 0 FALSE Pointer ServiceLink: target = RlcConfClass

rncWs Customer 3 FALSE ms Integer [3...80]

slidingWindowSize Customer 3 FALSE N.A. Integer [0...255]

startPoint Customer 3 FALSE ms Integer [0...1279]

syncWaitInterval Customer 3 FALSE ms Integer [0...65535]

tInit Customer 3 FALSE ms Integer [0...65535]

4.1.1.1.4 DLRLCACKMODE


• RNC/§ RadioAcessService/0 RlcConfClass/PS_HSDSCH_ED CH_IB_AM DlRlcAckMode/0

• RNC/§ RadioAcessService/0 RlcConfClass/PS_HSDSCH_AM _DL DlRlcAckMode/0

Parameter User Class Optional Range

lastRetransPuPoll Customer 3 FALSE Boolean

lastTransPuPoll Customer 3 FALSE Boolean

maxDat Customer 3 FALSE Enum [1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 15; 20; 25; 30; 35; 40]

maxNbrOfResetRetrans Customer 3 FALSE Enum [1; 4; 6; 8; 12; 16; 24; 32]

misPuIndic Customer 3 FALSE Boolean

nbrOfPuBetweenPolling Customer 3 TRUE Enum [1; 2; 4; 8; 16; 32; 64; 128]

nbrOfSduBetweenPolling Customer 3 TRUE Enum [1; 4; 16; 64]




pollingTimer Customer 3 TRUE

Enum (ms) [10; 20; 30; 40; 50; 60; 70; 80; 90; 100; 110; 120; 130; 140; 150; 160; 170; 180; 190; 200; 210; 220; 230; 240; 250; 260; 270; 280; 290; 300; 310; 320; 330; 340; 350; 360; 370; 380; 390; 400; 410; 420; 430; 440; 450; 460; 470; 480; 490; 500; 510; 520; 530; 540; 550; 600; 650; 700; 750; 800; 850; 900; 950; 1000]

pollwindow Customer 3 TRUE

Enum [pollWindow50(0); pollWindow60; pollWindow70; pollWindow80; pollWindow85; pollWindow90; pollWindow95; pollWindow99]

prohibitedPollingTimer Customer 3 TRUE

Enum (ms) [10; 20; 30; 40; 50; 60; 70; ;80; 90; 100; 110; 120; 130; 140; 150; 160; 170; 180; 190; 200; 210; 220; 230; 240; 250; 260; 270; 280; 290; 300; 310; 320; 330; 340; 350; 360; 370; 380; 390; 400; 410; 420; 430; 440; 450; 460; 470; 480; 490; 500; 510; 520; 530; 540; 550; 600; 650; 700; 750; 800; 850; 900; 950; 1000]

prohibitedStatusTimer Customer 3 TRUE

Enum (ms) [10; 20; 30; 40; 50; 60; 70; 80; 90; 100; 110; 120; 130; 140; 150; 160; 170; 180; 190; 200; 210; 220; 230; 240; 250; 260; 270; 280; 290; 300; 310; 320; 330; 340; 350; 360; 370; 380; 390; 400; 410; 420; 430; 440; 450; 460; 470; 480; 490; 500; 510; 520; 530; 540; 550; 600; 650; 700; 750; 800; 850; 900; 950; 1000]

receptionWindowSize Customer 3 FALSE

Enum [1; 8; 16; 32; 64; 128; 256; 512; 768; 1024; 1536; 2047; 2560; 3072; 3584; 4095]

resetTimer Customer 3 FALSE

Enum (ms) [50; 100; 150; 200; 250; 300; 350; 400; 450; 500; 550; 600; 700; 800; 900; 1000]

timerPollPeriod Customer 3 TRUE

Enum [tpollper100; tpollper200; tpollper300; tpollper400; tpollper500; tpollper750; tpollper1000; tpollper2000]

timerStatPeriod Customer 3 TRUE


transmissionWindowSize Customer 3 FALSE

Enum [1; 8; 16; 32; 64; 128; 256; 512; 768; 1024; 1536; 2047; 2560; 3072; 3584; 4095]

4.1.1.1.5 DLUSERSERVICE


• RNC/§ RadioAcessService/0 DlUserService/ xPS_HSDSCH xSRB_3_4K




Parameter User Class Unit Step Range

cmodePCDeltaSirAfter1 Customer 3 dB Float [0.0...3.0] Step = 0.1

cmodePCItp Customer 3 N.A. N.A. Enum [cmodeItpMode0; cmodeItpMode1]

cmodePCRpp Customer 3 N.A. N.A. Enum [cmodeRppMode0; cmodeRppMode1]

dlReferencePower Customer 3 dB 0,1 Float [-35.0…15.0] Step = 0.1

enabledForRabMatching Customer 3 N.A. N.A. Boolean

isAlwaysOnAllowed Customer 3 N.A. N.A. Boolean

isDlRbRateAdaptationAllowedForThisDlUserService Customer 3 N.A. N.A. Boolean

isGsmCModeActivationAllowed Customer 3 N.A. N.A. Boolean

isInterFreqCModeActivationAllowed Customer 3 N.A. N.A. Boolean

isIrmSchedulingUpgradeAllowedFromThisUS Customer 3 N.A. N.A. Boolean

isIrmSchedulingUpgradeAllowedToThisUS Customer 3 N.A. N.A. Boolean

isTransCodePowerIrmScheduling DowngradeAllowedFromThisDlUserService Customer 3 N.A. N.A. Boolean

minimumCpichEcNoValueForHO Customer 3 dB 0,1 Float [-24.0...0.0] Step = 0.1

minimumCpichRscpValueForHO Customer 3 dBm 1 Integer [-120...-25]

po1ForTfciBits Customer 3 N.A. 1 Integer [0...24]

po2ForTpcBits Customer 3 N.A. 1 Integer [0...24]

po3ForPilotBits Customer 3 N.A. 1 Integer [0...24]

powerBalancingRequired Customer 3 N.A. N.A. Boolean

serviceType Customer 3 N.A. N.A.

Enum [CsSpeech; CsConversational; CsStreaming; PsStreaming; PsIb; CsSpeechPlusOther; UnusedA; UnusedB; UnusedC; UnusedD; UnusedE; UnusedF; None]

4.1.1.1.6 DLUSERPOWERCONF


• RNC/§ RadioAcessService/0 DedicatedConf/0 PowerConf Class/§ DlUsPowerConf/ xPS_HSDSCHxSRB_3_4K





algo1DeltaTargetPower Customer 3 dB Float [-35.0...15.0] Step = 0.1

algo2DeltaTargetPower Customer 3 dB Float [-35.0...15.0] Step= 0 .1

initialDlEcnoTarget Customer 3 dB Float [-24.5...0.0] Step = 0.5

isIrmSchedDowngradeTxcpAllowed Customer 3 N.A. Boolean

isIrmSchedulingUpgradeAllowedFromThisUS Customer 3 N.A. Boolean

isIrmSchedulingUpgradeAllowedToThisUS Customer 3 N.A. Boolean

maxDlTxPower Customer 3 dB Float [-35...15] Step = 0.1

minDlTxPower Customer 3 dB Float [-35...15] Step = 0.1

4.1.1.1.7 FASTALARMHARDHOCONF


• RNC/§ RadioAcessService/0 DedicatedConf/0 HoConfCla ss/§ UsHoConf/ xPS_HSDSCHxSRB_3_4K FastAlarmHardHoConf/0


counter Customer 3 N.A. Integer [0...100]

cpichEcNoThreshold Customer 3 dB Float [-24...0] Step = 0.1

cpichRscpThreshold Customer 3 dBm Integer [-120...-25]

stepDown Customer 3 N.A. Integer [0...20]

stepUp Customer 3 N.A. Integer [0...20]

4.1.1.1.8 SOFTHOCONF


• RNC/§ RadioAcessService/0 DedicatedConf/0 HoConfCla ss/§ UsHoConf/ xPS_HSDSCHxSRB_3_4K SoftHoConf/0





legAdditionDelta Customer 3 FALSE dB Float [0.0...24] Step = 0.5

legDroppingDelta Customer 3 FALSE dB Float [0...24] Step = 0.5

maxActiveSetSize Customer 3 FALSE N.A. Integer [1...6]

shoLinkAdditionAbsoluteThresholdEnable Customer 3 FALSE N.A. Boolean

shoLinkDeletionAbsoluteThresholdEnable Customer 3 FALSE N.A. Boolean

shoLinkDeletionDelayEnable Customer 3 FALSE N.A. Boolean

shoLinkDeletionDelayTimeout Customer 3 TRUE ms

Enum [500; 1000; 1500; 2000; 3000; 4000; 5000; 6000]

4.1.1.1.9 SHOLINKADDITIONPARAMS


• RNC/§ RadioAcessService/0 DedicatedConf/0 HoConfCla ss/§ UsHoConf/ xPS_HSDSCHxSRB_3_4K SoftHoConf/0 ShoLinkAdditionPar ams/0


shoLinkAdditionActiveSetSizeConsideration Customer 3 N.A.

Enum [alwaysApplyAlgoExtension; dontApplyAlgoExtensionActiveSetSizeLe1; dontApplyAlgoExtensionActiveSetSizeLe2; dontApplyAlgoExtensionActiveSetSizeLe3; dontApplyAlgoExtensionActiveSetSizeLe4]

shoLinkAdditionCpichEcNoThreshold Customer 3 dB Float [-24.0...0.0] Step = 0.1

shoLinkAdditionCpichRscpThreshold Customer 3 dBm Integer [-120...-25]

4.1.1.1.10 SHOLINKDELETIONPARAMS


• RNC/§ RadioAcessService/0 DedicatedConf/0 HoConfCla ss/§ UsHoConf/ xPS_HSDSCHxSRB_3_4K SoftHoConf/0 ShoLinkDeletionPar ams/0


shoLinkDeletionActiveSetSizeConsideration Customer 3 N.A.

Enum [alwaysApplyAlgoExtension; dontApplyAlgoExtensionActiveSetSizeLe1; dontApplyAlgoExtensionActiveSetSizeLe2; dontApplyAlgoExtensionActiveSetSizeLe3; dontApplyAlgoExtensionActiveSetSizeLe4]




shoLinkDeletionCpichEcNoThreshold Customer 3 dB Float [-24...0] Step = 0.1

shoLinkDeletionCpichRscpThreshold Customer 3 dBm Integer [-120...-25]

4.1.1.1.11 HSDPACELLCLASS


• RNC/§ RadioAcessService/0 HsdpaCellClass/§


isAggregatedGbrCacActivated Customer 0 FALSE Boolean

isHighPerformanceAllowed Customer 0 FALSE Boolean

maximumAggregatedGbr Customer 0 FALSE Integer (bit/s) [0...16777215]

maximumNumberOfUsers Customer 0 FALSE Integer [0...100]

maxNbStreamingHsdpaUsers Customer 0 FALSE Integer [0...100]

minimumPowerForHsdpa Customer 0 TRUE Float (dB) [0...50] Step = 0.1

numberOfHsPdschCodes Customer 0 FALSE Integer [1...15]

numberOfHsScchCodes Customer 0 FALSE Integer [1...4]

4.1.1.1.12 HSPDSCHDYNAMICMANAGEMENT


• RNC/§ RadioAcessService/0 HsdpaCellClass/§ HspdschDynamicManagement/0

Parameter User Class Range

maxNumberOfHsPdschCodes Customer 3 Integer [1…15]

minNumberOfHsPdschCodes Customer 3 Integer [0…15]

minTimeBeforeReallocationOfHsPdsch Customer 3 Integer [0…3600]

numCodesForDchAfterReallocation Customer 3 Integer [1…255]

numCodesForDchAfterStealing Customer 3 Integer [1…255]

spreadingFactorLevelForOvsfMonitoring Customer 3 Enum [16; 32; 64; 128; 256]




threshCodesToTriggerReallocation Customer 3 Integer [1…255]

threshCodesToTriggerStealing Customer 3 Integer [1…255]

4.1.1.1.13 HSDPAUSERSERVICE


• RNC/§ RadioAcessService/0 HsdpaUserService/0


ackNackRepetitionFactor Customer 3 FALSE N.A. Integer [1...4]

ackPowerOffset Customer 3 FALSE N.A. Integer [0...8]

cqiFeedbackCycleK Customer 3 FALSE ms Enum [0; 2; 4; 8; 10; 20; 40; 80; 160]

cqiPowerOffset Customer 3 FALSE N.A. Integer [0...8]

cqiRepetitionFactor Customer 3 TRUE N.A. Integer [1...4]

discardTimer Customer 3 TRUE ms

Enum [20; 40; 60; 80; 100; 120; 140; 160; 180 ; 200; 250; 300; 400; 500; 750; 1000; 1250; 1500; 1750; 2000; 2500; 3000; 3500; 4000; 4500; 5000; 7500]

hsScchPowerOffset Customer 3 TRUE dB Float [-32.00...31.75] Step = .25

macHsWindowSize Customer 3 FALSE N.A. Enum [4; 6; 8; 12; 16; 24; 32]

measurementPowerOffset Customer 3 FALSE N.A. Integer [-12...26]

nackPowerOffset Customer 3 FALSE N.A. Integer [0...8]

timerT1 Customer 3 FALSE ms

Enum [10; 20; 30; 40; 50; 60; 70; 80; 90; 100; 120; 140; 160; 200; 300; 400]

4.1.1.1.14 HSDPARNCCONF


• RNC/§ RadioAcessService/0 HsdpaRncConf/0


deltaCfnForHsdpaChannelTypeSwitching Customer 3 Integer [0...255]

deltaCfnForHsdpaMobility Customer 3 Integer [0...255]




deltaCfnForHsdpaRLCReconfiguration Customer 3 Integer [0...255]

eligibleUeCategoryForHighPerformance Customer 3 BitString length = 64

isPsIbGbrActivated Customer 3 Boolean

isRLCReconfigurationForChannelTypeSwitching Customer 3 Boolean

minimumUserMbrForHighPerformance Customer 3 Integer (bit/s) [0...16000000]

nbOfSpiConfiguration Manufacturer 3 Integer [0..3]

suspendTimeOffset Customer 3 Integer [0...255]

transportTypeSelectionTransferDelayThreshold Customer 3 Integer (ms) [0…65536]

4.1.1.1.15 HSDSCHFLOWINFORMATION


• RNC/§ RadioAcessService/0 HsdpaRncConf/0 HsDschFlow Information/0


maxNumberOfRetryRequest Customer 3 Integer [0...255]

minTimeBetweenRequest Customer 3 Integer [0...65535]

4.1.1.1.16 PSIBGBRENTRY


• RNC/§ RadioAcessService/0 HsdpaRncConf/0 PsIbGbrLis t/0


gbr Customer 3 bits/s Integer [0...16000000]

isGbrForNodeb Customer 3 Flag Boolean

4.1.1.1.17 DLSOURCECONFORMANCEINFORMATION

Path of this object is:




RNC/§ RadioAcessService/0 SourceConformanceConf/0 DlSourceConformanceInformation/0


bucketBufferTime Customer 3 ms Integer [10...30000] Step = 10

maximumTokenGenerationRate Customer 3 Kbytes/s Integer [1...2000]

sourceConformanceActivation Customer 3 N.A. Enum Off, On

4.1.1.2 FDDCELL SUBTREE PARAMETERS

4.1.1.2.1 FDDCELL


RNC/§ NodeB/§ FddCell/§


hsdpaActivation Customer 2 Boolean

hsdpaServiceIndicatorMethod Customer 3 Enum [Off; On; Auto]

4.1.1.2.2 HSDPARESOURCE


RNC/§ NodeB/§ FddCell/§ HsdpaResource/0


hsdpaCellClassId Customer 2 ServiceLink target = HsdpaCellClass

4.1.1.2.3 INTERFREQHHOFDDCELL


RNC/§ NodeB/§ FddCell/§ InterFreqHhoFddcell/0


isRedirectionBasedOnEstablishmentCause Customer 3 Boolean

isRedirectionForTrafficSegmentation Customer 3 Boolean




4.1.1.2.4 NEIGHBOURINGRNC


RNC/§ neighbouringRNC/§

Parameter User Class Range isHsdpaAllowed Customer 3 Boolean

4.1.1.3 BTS SUBTREE PARAMETERS

4.1.1.3.1 BTSEQUIPMENT


BtsEquipment/§


hsdpaMaxNumberQueueIdHbbu Customer 0 Integer [0..65535]

hsdpaMaxNumberUser Customer 0 Integer [0..65535]

hsdpaMaxNumberUserPerNodeB Customer 0 Integer [0..65535]

hsdpaResourceMaxCapacity Customer 0 Integer [50..100]

4.1.1.3.2 BTSCELL


BtsEquipment/§ BTSCell/§


hsdpaResourceActivation Customer 0 Boolean

4.1.1.3.3 HSDPACONF


BtsEquipment/§ BTSCell/§ HsdpaConf/0


dchPowerMargin Customer 3 % Integer [0...100]

harqNbMaxRetransmissions Customer 3 N.A. Integer [0...31]

harqType Customer 3 N.A. Enum [mirType, pirType, ccType, drType,




MIRWithPowerAdaptation, PIRWithPowerAdaptation, CCWithPowerAdaptation, DRWithPowerAdaptation]

hsdpaBlerObservationWindow Customer 3 TTIs Integer [1...500]

hsdpaBlerStepSize Customer 3 CQI Float [0.1...3.0] Step = 0.1

hsdpaBlerTargetLowerLimit Customer 3 % Integer [0...100]

hsdpaBlerTargetUpperLimit Customer 3 % Integer [0...100]

hsdpaCqiBlerAdjustmentAlgo Customer 3 N.A.

Enum [deactivated; blerRangeBasedAlgo, outerLoopLikeAlgo]

hsdpaResourceId Customer 0 N.A. Integer [0...5]

hsdpaSchedulerAlgorithm Customer 3 N.A. Enum [nortel; proportionalFair; roundRobin; maxCtoI; fair]

hsdpaSchedulerWeightingFactor Customer 3 N.A. Integer [1...8]

hsdpaSpiRelativeWeight Customer 3 N.A. Integer [1…16][1...100]

hsdpaUeCategoryThroughputWeighting Customer 3 N.A. Enum [ueCategoryEquity; ueCategoryProportionality]

hsdschInterval Customer 3 ms Integer [10...500]

hsscchPcOffset Customer 3 dB Float [1…30][-28.0...28.0] (step = 0.1)

maxRateGrowth Customer 3 N.A. Integer [1...16]

4.1.1.3.4 HSDPAMAXUECATEGORYCAPABILITYACTIVATION


BtsEquipment/§ BTSCell/§ HsdpaConf/0 HsdpaMaxUeCategoryCapabilityActivation/0

Parameter User Class Range ueCategory1 Customer 3 Boolean ueCategory10 Customer 3 Boolean ueCategory11 Customer 3 Boolean ueCategory12 Customer 3 Boolean ueCategory2 Customer 3 Boolean ueCategory3 Customer 3 Boolean ueCategory4 Customer 3 Boolean ueCategory5 Customer 3 Boolean ueCategory6 Customer 3 Boolean ueCategory7 Customer 3 Boolean ueCategory8 Customer 3 Boolean ueCategory9 Customer 3 Boolean




4.1.1.3.5 HSDPAUECATEGORYTRANSPORTBLOCKOPTIMIZATION


BtsEquipment/§ BTSCell/§ HsdpaConf/0 HsdpaUeCategoryTransportBlockOptimization/0

Parameter User Class Range ueCategory1 Customer 3 Boolean ueCategory10 Customer 3 Boolean ueCategory11 Customer 3 Boolean ueCategory12 Customer 3 Boolean ueCategory2 Customer 3 Boolean ueCategory3 Customer 3 Boolean ueCategory4 Customer 3 Boolean ueCategory5 Customer 3 Boolean ueCategory6 Customer 3 Boolean ueCategory7 Customer 3 Boolean ueCategory8 Customer 3 Boolean ueCategory9 Customer 3 Boolean

4.1.2 HSUPA

4.1.2.1 RRM SUBTREE PARAMETERS

4.1.2.1.1 RADIOACCESSSERVICE


• RNC/§ RadioAcessService/0


isEdchAllowed Customer 3 Boolean

isEdchHhoWithMeasAllowed Customer 3 Boolean

isHsxpaServiceIndicatorEnabled Customer 3 Boolean

timerT1ForHsdpaAndEdch Customer 3 Integer (ms) [10…3600000] Step = 10 ms

timerT2ForHsdpaAndEdch Customer 3 Integer (ms) [10…10800000]

4.1.2.1.2 ULRBSETCONF


• RNC/§ RadioAcessService/0 UlRbSetConf/PS_EDCH





allowedUlRbSetForMatching Customer 3 TRUE Integer [0…30]

enabledForRABMatching Customer 3 FALSE Boolean

endPoint Customer 3 FALSE Integer (ms) [0…1279]

isAlwaysOnAllowed Customer 3 FALSE Enum [disabled; degraded2AlwaysOnOnly; releaseOnly]

isThisRbRateAdaptationUlRbSetTargetAllowed Customer 3 FALSE Boolean

isUlRbRateAdaptationAllowedForThisUlRbSetConf Customer 3 FALSE Boolean

iubIurTransportQosId Customer 3 FALSE Integer [0…3]

iuCsTransportQosId Customer 3 FALSE Integer [0…3]

maxUlSyncRetries Customer 3 FALSE Integer [0…255]

nInit Customer 3 FALSE Integer [0…255]

outOfOrderSduDeliveryEnable Customer 3 FALSE Boolean

periodicUlSyncInterval Customer 3 FALSE Integer (s) [0…65535]

reEstablishTimer Customer 3 FALSE Enum [reestablishTimerUseT314; reestablishTimerUseT315]

rlcConfClassId Customer 0 FALSE ServiceLink target = rlcConfClass

rncBufferSize Customer 3 FALSE Integer (ms) [0…2147483647]

rncWs Customer 3 FALSE Integer (ms) [0…1279]

slidingWindowSize Customer 3 FALSE Integer (ms) [0…255]

startPoint Customer 3 FALSE Integer (ms) [0…1279]

tInit Customer 3 FALSE Integer (ms) [0…65535]

ulIrmTableConfClassId Customer 3 TRUE ServiceLink target = ulIrmTableConfClass

ulOutOfOrderSduDeliveryMethod Customer 3 FALSE

Enum [InSequence; OutOfSequenceStandard; OutOfSequenceProprietary]

ulRbPduSizeList Customer 3 FALSE Integer (Bytes) [2…625]

ulRbRateAdaptationDownsizeThreshold Customer 3 TRUE Integer (kbps) [0…2048]

ulRbRateAdaptationUpsizeThreshold Customer 3 TRUE Integer (kbps) [0…2048]




4.1.2.1.3 ULRLCACKMODE


• RNC/§ RadioAcessService/0 RlcConfClass/PS_HSDSCH_ED CH_IB_AM UlRlcAckMode/0


lastRetransPuPoll Customer 3 FALSE Boolean

lastTransPuPoll Customer 3 FALSE Boolean

maxDat Customer 3 FALSE Enum [1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 15; 20; 25; 30; 35; 40]

maxNbrOfResetRetrans Customer 3 FALSE Enum [1; 4; 6; 8; 12; 16; 24; 32]

misPuIndic Customer 3 FALSE Boolean

nbrOfPuBetweenPolling Customer 3 TRUE Enum [1; 2; 4; 8; 16; 32; 64; 128]

nbrOfSduBetweenPolling Customer 3 TRUE Enum [1; 4; 16; 64]

pollingTimer Customer 3 TRUE

Enum (ms) [10; 20; 30; 40; 50; 60; 70; 80; 90; 100; 110; 120; 130; 140; 150; 160; 170; 180; 190; 200; 210; 220; 230; 240; 250; 260; 270; 280; 290; 300; 310; 320; 330; 340; 350; 360; 370; 380; 390; 400; 410; 420; 430; 440; 450; 460; 470; 480; 490; 500; 510; 520; 530; 540; 550; 600; 650; 700; 750; 800; 850; 900; 950; 1000]

pollwindow Customer 3 TRUE

Enum [pollWindow50(0); pollWindow60; pollWindow70; pollWindow80; pollWindow85; pollWindow90; pollWindow95; pollWindow99]

prohibitedPollingTimer Customer 3 TRUE

Enum (ms) [10; 20; 30; 40; 50; 60; 70; ;80; 90; 100; 110; 120; 130; 140; 150; 160; 170; 180; 190; 200; 210; 220; 230; 240; 250; 260; 270; 280; 290; 300; 310; 320; 330; 340; 350; 360; 370; 380; 390; 400; 410; 420; 430; 440; 450; 460; 470; 480; 490; 500; 510; 520; 530; 540; 550; 600; 650; 700; 750; 800; 850; 900; 950; 1000]

prohibitedStatusTimer Customer 3 TRUE

Enum (ms) [10; 20; 30; 40; 50; 60; 70; 80; 90; 100; 110; 120; 130; 140; 150; 160; 170; 180; 190; 200; 210; 220; 230; 240; 250; 260; 270; 280; 290; 300; 310; 320; 330; 340; 350; 360; 370; 380; 390; 400; 410; 420; 430; 440; 450; 460; 470; 480; 490; 500; 510; 520; 530; 540; 550; 600; 650; 700; 750; 800; 850; 900; 950; 1000]




receptionWindowSize Customer 3 FALSE

Enum [1; 8; 16; 32; 64; 128; 256; 512; 768; 1024; 1536; 2047; 2560; 3072; 3584; 4095]

resetTimer Customer 3 FALSE

Enum (ms) [50; 100; 150; 200; 250; 300; 350; 400; 450; 500; 550; 600; 700; 800; 900; 1000]

timerPollPeriod Customer 3 TRUE


timerStatPeriod Customer 3 TRUE


transmissionWindowSize Customer 3 FALSE

Enum [1; 8; 16; 32; 64; 128; 256; 512; 768; 1024; 1536; 2047; 2560; 3072; 3584; 4095]

4.1.2.1.4 ULUSERSERVICE


• RNC/§ RadioAcessService/0 UlUserService/ xPS_EDCHxS RB_3_4K


deltaSir1 Customer 3 Float (dB) [0.0…3.0] Step = 0.1 dB

deltaSirAfter1 Customer 3 Float (dB) [0.0…3.0] Step = 0.1 dB

enabledForRabMatching Customer 3 Boolean

isAlwaysOnAllowed Customer 3 Boolean

isUlRbRateAdaptationAllowedForThisUlUserService Customer 3 Boolean

ulCostForUlTokenCac Customer 3 Integer [0…511]

4.1.2.1.5 ULOUTERLOOPPOWERCTRL


• RNC/§ RadioAcessService/0 UlUserService/ xPS_EDCHxS RB_3_4K UlOuterLoopPowerCtrl/0


isUlOuterPCActivated Customer 3 Boolean




ulDownSirStep Customer 3 Float (dB) [0.1…2.0] Step = 0.1 dB

ulUpdatePeriod Customer 3 Integer [0…255]

4.1.2.1.6 ULUSPOWERCONF


• RNC/§ RadioAcessService/0 DedicatedConf/0 PowerConf Class/§ UlUsPowerConf/xPS_EDCHxSRB_3_4K


initialUlSirTarget Customer 3 Float (dB) [-8.2...17.3] Step = 0.1 dB

maxAllowedUlTxPower Customer 3 Integer (dBm) [-50...33]

maxSirTarget Customer 3 Float (dB) [-8.2...17.3] Step = 0.1 dB

minSirTarget Customer 3 Float (dB) [-8.2...17.3] Step = 0.1 dB

4.1.2.1.7 EDCHUSERSERVICE


RNC/§ RadioAcessService/0 EdchUserService/0


edchHarqMaxRetrans Customer 3 Integer [0...15]

edchMacdPowerOffset Customer 3 Integer [0...6]

edchTfcConfId Customer 3 ServiceLink target = EdchTfcConf

happyBitDelay Customer 3 Enum [2; 10; 20; 50; 100; 200; 500; 1000]

harqRvConfiguration Customer 3 Enum [rv0; rvtable]

periodicityOfSchedInfoGrant Customer 3 Enum (ms) [EveryEdchTti; 4; 10; 20; 50; 100; 200; 500; 1000]

periodicityOfSchedInfoNoGrant Customer 3 Enum (ms) [EveryEdchTti; 4; 10; 20; 50; 100; 200; 500; 1000]

powerOffsetForSchedInfo Customer 3 Integer (dB) [0...6]




Rule: edchTfcConfId

This parameter can point to only two EdchTfcConf instances (0 or 4).

When pointing to EdchTfcConf 0, the system will consider a set of 4 EdchTfcConf classes (0, 1, 3, and 4), one for each E-DCH UE category supported in UA5.0.

Same for EdchTfcConf 4.

See 3.1.2.1.1 and 3.3.3.2.1 for details in EdchTfcConf associated parameters recommended values

4.1.2.1.8 EDCHCELLCLASS


• RNC/§ RadioAcessService/0 DedicatedConf/0 EdchCellC lass/§


eagchErgchEhichTotalPower Customer 0 Float (dBm) [0.0...50.0] Step = 0.1

eagchPowerOffset Customer 0 Float (dB) [-32.00...31.75] Step = 0.25

edchMaxUsersPerCell Customer 0 Integer [1...64]

ehichPowerOffset Customer 0 Float [[-32.00...31.75] -32.00…31.75]

ergchPowerOffset Customer 0 Float [[-32.00...31.75] -32.00…31.75]

maxNrOfEagch Customer 0 Integer [1...8]

maxNrOfErgchEhich Customer 0 Integer [1...8]

4.1.2.1.9 EDCHRNCCONF


RNC/§ RadioAcessService/0 EdchRncConf/0


deltaCfnForEdchAndHsdpaChannelTypeSwitching Customer 3 Integer [0...255]

deltaCfnForEdchAndHsdpaMobility Customer 3 Integer [0...255]

deltaCfnForEdchChannelTypeSwitching Customer 3 Integer [0...255]

deltaCfnForEdchRlcReconfiguration Customer 3 Integer [0...255]

edchCongestionControlNotificationBackoffTimer Customer 3 Integer [0...255]




edchFpNoCongestionTimer Customer 3 Integer [0...255]

edchProcessingOverloadLevel Customer 3 Integer [0...10]

edchReceivingWindowTti2 Customer 3 Integer [0...63]

isCmHlsAllowedWithEdch Customer 3 Boolean

isCmSfo2AllowedWithEdch Customer 3 Boolean

isRlcReconfigurationForChannelTypeSwitchingEdch Customer 3 Boolean

iubEdchDelayVariation Customer 3 Integer [0...255]

maxNumberOfRlEdch Customer 3 Integer [1...4]

4.1.2.1.10 EDCHTFCCONF


RNC/§ RadioAcessService/0 EdchTfcConf/§


deltaEdpcch Customer 0 Integer [0…8]

edchMinSetEtfci Customer 0 Integer [0...127]

edchTfcsTableIndex Customer 0 Enum [2msTtiTable0; 2msTable1; 10msTtiTable0; 10msTtiTable1]

ergch2IndexStepThreshold Customer 0 Integer [0...37]

ergch3IndexStepThreshold Customer 0 Integer [0...37]

4.1.2.1.11 REFERENCEETFCICONFLIST


RNC/§ RadioAcessService/0 EdchTfcConf/§ referenceEt fciConfList/§


referenceEtfci Customer 0 Integer [0…127]

referenceEtfciPowerOffset Customer 0 Integer [0…29]

4.1.2.1.12 ULSOURCECONFORMANCEINFORMATION

Path of this object is:




RNC/§ RadioAcessService/0 SourceConformanceConf/0 UlSourceConformanceInformation/0


bucketBufferTime Customer 3 Integer (ms) [10…30000] Step = 10 ms

maximumTokenGenerationRate Customer 3 Integer (kBytes/s) [1…2000]

sourceConformanceActivation Customer 3 Enum [off; on]

4.1.2.2 FDDCELL SUBTREE PARAMETERS

4.1.2.2.1 FDDCELL


RNC/§ NodeB/§ FddCell/§


edchActivation Customer 2 Boolean

referenceRtwp Customer 2 Float (dBm) [-112.0…-70.0] Step = 0.1

totalRotMax Customer 2 Float (dB) [0.0…20.0] Step = 0.1

4.1.2.2.2 EDCHRESOURCE


RNC/§ NodeB/§ FddCell/§ EdchResource/0

Parameter User Parameter Range

edchCellClassId Customer 2 ServiceLink: target = EdchCellClass

4.1.2.3 BTS SUBTREE PARAMETERS

4.1.2.3.1 BTSEQUIPMENT


BtsEquipment/§





edchCapability Customer N.A.

edchMaxNumberUserEbbu Manufacturer 0 Integer [0…65535]

edchMaxNumberUserNodeB Manufacturer 0 Integer [0…65535]

edchOperationalState Customer N.A.

edchSharedChannelInfo Customer N.A.

isRtwpAdjustmentForRnc Customer 3 Boolean

isRtwpReferenceSelfLearning Customer 3 Boolean

numberEdchUsers Customer N.A.

4.1.2.3.2 BTSCELL


BtsEquipment/§ BTSCell/§


edchResourceActivation Customer 0 Boolean

rtwpMaxCellLoadCacActivation Customer 3 Boolean

rtwpMaxCellLoadNonEdch Customer 3 Integer (%) [0…100]

rtwpReference Customer 3 Float (dBm) [-115.0…-50.0] Step = 0.1

4.1.2.3.3 EDCHCONF


BtsEquipment/§ BTSCell/§ EdchConf/0


eagchPower Customer 3 Float (dB) [-35.0...15.0] Step = 0.1

eagchPowerControlMode Customer 3 Enum [fixed; dynamic]

eDchResourceId Customer 0 Integer [0...5]

edchSchedulerAlgorithm Customer 3 Enum [roundRobinSlidingWindow; rateScheduling]




ehichPowerControlMode Customer 3 Enum [fixed; dynamic]

ehichPowerSignature Customer 3 Float (dB) [-35.0...15.0] Step = 0.1

ergchPowerControlMode Customer 3 Enum [fixed; dynamic]

ergchPowerSignature Customer 3 Float (dB) [-35.0...15.0] Step = 0.1

harqType Customer 3 Enum [ irType; ccType]

maxEdchCommonChannelPower Customer 3 Float (dB) [-35.0...15.0] Step = 0.1

ttiType Customer 3 Enum [2ms; 10ms]

4.2 HSXPA ACTIVATION

Refer to [R07] NN-20500-061 “HSxPA Feature Activation Procedure”







6 HSXPA SPECIFIC FEATURES & IMPACT ON EXISTING ALGORITHMS

6.1 RRM ALGORITHMS

6.1.1 ALWAYS ON

6.1.1.1 MECHANISM

The Always-on mechanism applies to HSDPA in DL and E-DCH in UL the same way as for R99 radio bearers. Only Interactive/Background QoS traffic classes are eligible to Always-on.

Note: Always-on does not apply if the Signaling Indication parameter of the RAB Assignment Request associated with the Interactive RAB has been set to “signaling”. In this case (example Video Streaming signaling like RTSP protocol, or VoIP signaling like SIP protocol), the RB will not be downsized by Always-on.

Always-on allows to optimize radio resource usage for bursty traffic (low activity factor), but at the same time shall take into account the limitation in terms of simultaneous connected users on the traffic shared channels:

• In DL, HSDPA CAC (see § 3.5.2.2).

• In UL, E-DCH CAC, (see § 3.5.2.2)

The monitoring of user activity at RLC level (DTCH) for both UL and DL is the same as for R99. Nevertheless, some new parameters appear. Let’s introduce them in the next chapters.

6.1.1.2 NEW RRC STATES

In UA05, all RRC states are supported. The two new PCH states are useful for PS data subscribers who can fallback to one of these states when they are completely inactive.

The advantage of using the CELL_PCH and URA_PCH states are:

� no dedicated physical channel is allocated to the UE, hence the users have no impact on the cell capacity and only consume RRC context resource.

� users benefit from a quicker re-establishment time compared to from idle mode while the UE battery consumption is equivalent to the idle mode.

Always-on controls a user session by introducing three states (see Figure 44: AO state transitions):




• Normal Mode : In this state the session is operating with the original RB that was allocated at call admission or reconfigured by other PS Call Management features (RB Adaptation, iRM Scheduling, iRM Preemption). For a session to be maintained in this state, the user traffic must remain above a predefined threshold: if it falls and stays below this threshold during a given period of time, the RAB is downsized. A session is returned to this state, from idle mode or downsized mode, if user traffic

� is resumed (from Idle, CELL_PCH or URA_PCH states)

� exceeds a pre-defined threshold (from CELL_FACH state).

• Downsized Mode : In this state the session is operating with a downgraded (from a bandwidth perspective) RB compared to the one that was originally allocated by the RAB Matching Algorithm. A session is downgraded to the downsized mode from the normal mode if user traffic falls and stays below a pre-defined threshold for a given period. This downsized state contains the following two sub-steps:

� AO Step 1, for the case where CELL_FACH is used (PS8 is no more supported as an Always ON downsized configuration from UA5 except for multiservices RAB)

� AO Step 2, for the case where CELL_PCH or URA_PCH is used.

• Idle Mode: In this state the session has released all its radio resources and the RRC context, but the PDP context is still maintained by the Core Network. A session is downgraded to idle mode if there has been no (or very little) user traffic for a given (provisionable) period of time. This state is also known as AO Step 3 (and was previously referred to as AO Step 2).




The simplified state transitions are shown in Figure 44.

CELL_FACH

CELL_PCH

URA_PCH

Normal mode

Idle mode

Downsizing (Tdownsize expiry)

Release (Tinactivity expiry)

RB Ré-establishment (Traffic resuming) (Tinactivity expiry)

Upsizing (Traffic

resuming)

Normal mode AO Step 1 AO Step 2 AO Step 3

Downsized mode

Figure 44 : AO state transitions

For more details on Always ON transitions in UA5.0 see UPUG [R01]

6.1.1.3 ACTIVATION & MODES

6.1.1.3.1 ACTIVATION

Always-on has to be activated for HSDPA and E-DCH. Several parameters are to be set:

• First, Always-on has to be activated on RNC :

Parameter isAlwaysOnAllowed Object AlwaysOnConf Range & Unit Boolean


Granularity RNC

Value False (de-activate the feature) True (activate the feature)

• Then, Always-on has to be activated on user service:




Parameter isAlwaysOnAllowed Object DlUserService Range & Unit Boolean


Granularity DlUserService

Value See table below

DlUserService isAlwaysOnAllowed

CS_64KxPS_HSDSCHxSRB_3_4K True CS_AMR_NBxPS_16K_STRxPS_HSDSCHxSRB_3_4K True

CS_AMR_NBxPS_64K_STRxPS_HSDSCHxSRB_3_4K True



CS_AMR_NBxPS_HSDSCHxSRB_3_4K True

PS_16K_STRxPS_HSDSCHxSRB_3_4K True




PS_HSDSCHxSRB_3_4K True

• The suitable Always-on mode has to be set on RB configuration:

Parameter isAlwaysOnAllowed Object DlRbSetConf Range & Unit Enumeration

{disabled, degraded2AlwaysOnOnly, releaseOnly} User Customer Class 3

Granularity DlRbSetConf


DlRbSetConf isAlwaysOnAllowed PS_HSDSCH_IB degraded2AlwaysOnOnly PS_HSDSCH_IB_MUX releaseOnly

Rule: Eligibility of RbSetConf to Step 2 mechanism

Multi-service calls are not allowed to the 2 steps Always-on mechanism. Hence for the PS_HSDSCH_IB_MUX, the parameter isAlwaysOnAllowed shall not be set to degraded2AlwaysOnOnly, but to releaseOnly.

For E-DCH, the corresponding parameters are:

Parameter isAlwaysOnAllowed Object UlUserService Range & Unit Boolean


Granularity UlUserService





UlUserService isAlwaysOnAllowed

CS_64KxPS_EDCHxSRB_3_4K True CS_AMR_NBxPS_16K_STRxPS_EDCHxSRB_3_4K True

CS_AMR_NBxPS_32K_STRxPS_EDCHxSRB_3_4K True

CS_AMR_NBxPS_128K_STRxPS_EDCHxSRB_3_4K True

CS_AMR_NBxPS_EDCHxSRB_3_4K True

PS_16K_STRxPS_EDCHxSRB_3_4K True



PS_EDCHxSRB_3_4K True

Parameter isAlwaysOnAllowed Object UlRbSetConf Range & Unit Enumeration

{disabled, degraded2AlwaysOnOnly, releaseOnly} User Customer Class 3

Granularity UlRbSetConf


UlRbSetConf isAlwaysOnAllowed PS_EDCH degraded2AlwaysOnOnly

Rule: Always-on Step 2 applicability to Streaming R AB

The RNC shall not send RAB Release or Iu Release with cause "User Inactivity" for Streaming RAB.

For that reason, associated PS I/B (DCH or HSDSCH) which are used for the signalling should not be downsize/released by Always-on.

• The new RRC states are activated by the operator:

Parameter PchRrcStates Object Radio Access Service Range & Unit Enumeration

{none, UraPchEnabled, CellPchEnabled, UraAndCellPchEnabled} User Customer Class 3

Granularity

Value UraAndCellPchEnabled

Engineering Recommendation: PchRrcStates

The problematic of URA size (equal to 1 cell in case of CELL_PCH) is similar to RANAP paging, except that an UTRAN generated paging involves less processing that a CN generated paging since no RANAP message are sent on Iu. Hence the optimal URA size corresponds to the RNC coverage (we recommend to avoid splitting LAC/RAC across RNC borders)

If the URA/Cell_PCH states are not activated (PchRrcStates = none), then the Step 2 and Step 3 described above are replaced by only one step (named “Step 2 ” in the previous UA releases).




For more details on RRC states configuration see UPUG [R01]

6.1.1.3.2 MODES

The following modes are possible :

• Downsize / Release (3 steps) : PchRrcStates ≠ none

When Cell/URA_PCH states are activated, Always-on mechanism is using 3 steps for the downsize part:

o Step 1 : The user is first downsized after a period T1 of low activity (or inactivity). The associated timer for HSDPA and E-DCH is a new parameter: timerT1ForHsdpaAndEDch

o Step 2 : The user is further downsized after a period T2 of inactivity. There is one timer per target downsized state. Hence the new parameters fachToCellPchTimer and fachToUraPchTimer

o Step 3 : In URA_PCH or CELL_PCH the user does not have a DTCH assigned, hence it is not possible to measure activity at RLC/MAC level. The user is released after a period T3 of inactivity. As the decision can be taken in either the Cell FACH, URA_PCH or Cell_PCH state, there is one timer per source state. Hence the algorithm uses the new parameters cellPchToIdleTimer / uraPchToIdleTimer.

The transition between the CELL_PCH and the URA_PCH is independent of Always-on mechanism and relies on signalling volume criteria. After receiving nbOfCellUpdatesFromCellPchToUraPch cell updates procedures with cause “cell reselection” (and before expiration of cellPchToIdleTimer or upsize procedure), the RNC triggers a state change of the UE to URA_PCH

If the URA/Cell_PCH states are not activated (PchRrcStates = none), then the Step 2 and Step 3 described above are replaced by only one step (named “Step 2 ” in the previous releases):

o Step 2 (“old”) : The user is released after a period T2 of inactivity. The associated timer for HSDPA and EDCH is the existing parameter: timerT2




Figure 45: Always-on for HSDPA/E-DCH (degraded2Alwa ysOn mode, PchRrcStates ≠ none)

The downsize condition is the same as for R99.

When downsizing to CELL_FACH, if no resource are available (CAC failure on FACH), the call is released (as in R99).

When Cell/URA_PCH states are not activated, Always-on mechanism may use 1 or 2 steps for the downsize part (behaviour as before UA5.0)

• Downsize / Release (2 steps) : PchRrcStates = none

In this mode, the Always-on feature first downsize the user to Always-on CELL_FACH and perform the release in a second time.

The timers used are:

o timerT1ForHsdpa in case of HSDPA only

o timerT1ForHsdpaAndEDch in case HSDPA & DCH are both activated.

Activity (UL or DL) Low activity / Inactivity

HSDPA + UL DCH HSDPA + E-DCH CELL_FACH

Downsize timer Step 2

(fachToCellPchTimer, fachToUraPchTimer)

t

Always-on (degraded2AlwaysOnOnly, PchRrcStates ≠ none)

Downsize (step 1)

Inactivity

t

Traffic UL/DL

timerT1ForHsdpaAndEDch)


(timerT1ForHsdpa,

Downsize (step 2)

CELL_PCH / URA_PCH

Downsize (step 3)


(cellPchToIdleTimer, uraPchToIdleTimer)




Activity (UL or DL) Low activity / Inactivity

HSDPA + UL DCH HSDPA + E-DCH

Downsized RB (CELL_FACH)

Release timer (timerT2)

t

Always-on (degraded2AlwaysOnOnly, PchRrcStates = none)

Downsize

Release

Inactivity

t Traffic UL/DL


Downsize timer

(timerT1ForHsdp

Figure 46: Always-on for HSDPA/E-DCH (degraded2Alwa ysOn mode, PchRrcStates = none)

• Release only (1 step)

In this mode, the Always-on feature directly releases the user after a period T2 of inactivity. The timers used are:

o timerT2ForHsdpa in case of HSDPA only

o timerT2ForHsdpaAndEDch in case HSDPA & DCH are both activated.




Activity (UL or DL) Low activity

Release timer (timerT2ForHsdpa


t

Always-on (releaseOnly)

Release

Inactivity

t Traffic UL/DL

HSDPA + UL DCH

HSDPA + E-DCH

Figure 47: Always-on for HSDPA/E-DCH (releaseOnly m ode)

6.1.1.3.3 MULTISERVICE WITH HSDPA (HSDPA+CS & HSDPA+STR)

In case of multi PS services supported in HSDPA (HSDPA PS Mux), after a period T2 of inactivity, the user is transferred in Cell/URA_PCH state (if activated) and after an additional T3 of inactivity the call is released. If Cell/URA_PCH states are not active, the call is released after T2 timer.

The timer used is: timerT2ForMultiRabHsdpa

In case of HSDPA multi-service (HSDPA+CS or HSDPA+STR) the Always-on algorithm behavior is the same as in “Release only” mode with Cell/URA_PCH not activated.

The timer used is: timerT2ForHsdpa

6.1.1.3.4 UPSIZE

For Always-on upsize, the mechanism and the parameters are the same as for R99.

When upsizing to HSDPA or EDCH and no resource are available (in case of CAC failure), the call will be released.




6.1.1.3.5 REMINDER FOR TIMER USAGE

In the following tables, the D is used ton indicate degraded2AlwaysOn mode and the R stands for the releaseOnly mode.

First case when PchRrcStates = none :

Always-on mode T1 ( => FACH) T2 ( => Idle)

Single RAB Case

D timerT1 timerT2 R99

R timerT2

D timerT1ForHsdpa timerT2 HSDPA only

R timerT2ForHsdpa

D timerT1ForHsdpaAndEDch timerT2 HSDPA & EDCH

R timerT2ForHsdpaAndEDch

Multi RAB Case

R99 PS Mux R timerT2ForMultiIBRab

HSDPA PS Mux R timerT2ForMultiRabHsdpa

CS + PS I/B R99 D (PS) timerT1 (2) timerT2

CS + PS HSDPA D (PS) timerT2ForHsdpa (1)

CS + PS Mux R99 D (PS) timerT2ForMultiIBRab (1)

CS + PS Mux HSDPA D (PS) timerT2ForMultiRabHsdpa (1)

PS Streaming + PS I/B 8 D (PS I/B) timerT2(3)

PS Streaming + PS HSDPA D (PS HSDPA) timerT2ForHsdpa(3)

CS + PS Streaming + PS I/B 8 D (PS I/B) timerT2(4)

CS + PS Streaming + PS HSDPA D (PS HSDPA) timerT2ForHsdpa(4)

Table 31: Always-on timer usage (URA/Cell_PCH state s not used)

PS Component released, CS remaining.

CS +PS I/B R99 is downsized towards PS 8k and not CELL_FACH

PS I/B (DCH or HSDPA) is released and PS Streaming is remaining (but Always-on is not applied to the associated PS I/B RAB if the Signalling Indication IE is set to "signaling")

PS I/B (DCH or HSDPA) is released and CS and PS Streaming component are remaining (but Always-on is not applied to the associated PS I/B RAB if the Signalling Indication IE is set to "signaling")




Second case when x_PCH is activated (PchRrcStates ≠ none):

Always

On Mode T1 (�� FACH) T2 (�� Cell/URA_PCH) T3 (�� Idle)

Single RAB Case

fachToUraPchTimer uraPchToIdleTimer D timerT1

fachToCellPchTimer cellPchToIdleTimer R99

R timerT2

fachToUraPchTimer uraPchToIdleTimer D timerT1ForHsdpa

fachToCellPchTimer cellPchToIdleTimer HSDPA only

R timerT2forHsdpa

fachToUraPchTimer uraPchToIdleTimer D timerT1ForHsdpaAndEdch

fachToCellPchTimer cellPchToIdleTimer HSDPA + E_DCH

R timerT2forHsdpaAndEdch

Multi RAB Case

uraPchToIdleTimer R99 PS_MUX R timerT2ForMultiRab (1)

cellPchToIdleTimer

uraPchToIdleTimer HSDPA_MUX R

timerT2ForMultiRabHsdpa (1) cellPchToIdleTimer

CS + PS R99 D (PS) timerT1 (3) timerT2

CS + HSDPA D (HSDPA) timerT2forHsdpa (2)

PS Streaming + PS I/B 8

D (PS) timerT2(3)

PS Streaming + PS HSDPA

D (HSDPA) timerT2forHsdpa(3)

CS + PS Streaming + PS I/B 8

D (PS) timerT2(4)

CS + PS Streaming + PS HSDPA

D (HSDPA) timerT2forHsdpa(4)

Table 32: Always-on timer usage (URA/Cell_PCH state s are used)

(1) The PS I/B Multiplexed (on DCH or on HSDSCH) go directly to CELL_PCH or URA_PCH after T2, without performing downsize step 1, in case PCH states are enabled.

(2) PS Component released, CS remaining

(3) PS I/B (DCH or HSDPA) is released and PS Streaming is remaining (but Always-on is not applied to the associated PS I/B RAB if the Signalling Indication IE is set to "signaling"). PS I/B on HSPA is never downsized towards PS I/B 8 kbps.

(4) PS I/B (DCH or HSDPA) is released and CS and PS Streaming component are remaining (but Always-on is not applied to the associated PS I/B RAB if the Signalling Indication IE is set to "signaling").




Restriction:

The Always-on configuration has to be consistent in UL & DL (same Always-on mode), otherwise the downsize can not be triggered by the RNC.

6.1.1.4 PARAMETERS SETTINGS AND RECOMMENDATIONS

The timers timerT1ForHsdpa and timerT1ForHsdpaAndEDch are used when the Always-on mode on RbSetConf is set to degraded2AlwaysOn.

• timerT1ForHsdpa is used for DL HSDPA / UL DCH

• timerT1ForHsdpaAndEDch is used fro DL HSDPA / UL E-DCH

Parameter timerT1ForHsdpa, timerT1ForHsdpaAndEDch

Object AlwaysOnTimer

Range & Unit [10..3600000] (ms) User Customer Class 3

Granularity OLS

Value 10000

Engineering Recommendation: timerT1ForHsdpa, timerT1ForHsdpaAndEDch

10000 (i.e. 10 s) is the recommended value, to allow relative early transition to CELL_FACH if UE is inactive. This avoids UE processing waste on HS-SCCH decoding if inactive. Delay for transition from CELL_FACH to CELL_DCH is fast (< 600 ms) in case the user becomes active again.

The timers fachToCellPchTimer and fachToUraPchTimer are used when the Always-on mode on RbSetConf is set to degraded2AlwaysOn and PchRrcStates ≠ none.

• fachToCellPchTimer is used for transition from CELL_FACH to CELL_PCH when PchRrcStates = CellPchEnabled or PchRrcStates = UraAndCellPchEnabled

• fachToUraPchTimer is used for transition from CELL_FACH to URA_PCH when PchRrcStates = UraPchEnabled

Parameter fachToCellPchTimer, fachToUraPchTimer


Range & Unit [1..3600] (s) User Customer Class 3

Granularity OLS

Value 10

Engineering Recommendation: fachToCellPchTimer & fachToUraPchTimer




fachToCellPchTimer and fachToUraPchTimer represent the time where the user is kept in CELL FACH, before being downsized either to URA_PCH or to CELL_PCH. When upgrading from UA4.2 to UA5.0, it is recommended to keep these timers as low as possible, as the AO step 3 (X_PCH) minimizes UE battery consumption and system capacity impacts compared to FACH.

The timers timerT2ForHsdpa & timerT2ForHsdpaAndEDch are only used in case the Always-on mechanism is configured to release the call without going through the downsized state (releaseOnly for DL HSDPA and UL EDCH / UL DCH).

Parameter timerT2ForHsdpa, timerT2ForHsdpaAndEDch


Range & Unit [10..10800000] (ms) User Customer Class 3

Granularity OLS

Value 10000

The timerT2ForMultiRabHsdpa is only used in case the Always-on mechanism is configured to release the HSDPA Multi-RAB call without going through the downsized state (releaseOnly for HSDPA).

Parameter timerT2ForMultiRabHsdpa Object AlwaysOnTimer Range & Unit [10..10800000] (ms) User Customer Class 3

Granularity OLS

Value 10000

The uraPchToIdleTimer and the cellPchToIdleTimer are used for the downsizing respectively from URA_PCH and CELL_PCH to Idle state.

Parameter uraPchToIdleTimer, cellPchToIdleTimer


Range & Unit [1..7200] (min) User Customer Class 3

Granularity OLS

Value 60

Engineering Recommendation: uraPchToIdleTimer, cellPchToIdleTimer

The recommended value of those timers is highly dependent on the call model (ratio of PS data call with bursty nature) and is determined from the maximum number of users in X_PCH, which is an RNC CallP dimensioning constant. Beyond a certain timer duration, we can consider that the subscriber will not resume its data session anymore, and it is legitim to release the radio resources.

Parameter nbOfCellUpdatesFromCellPchToUraPch Object RadioAccessService Range & Unit [1..65535] User Customer Class 3

Granularity RNC

Value 1





As soon as the mobility is detected, the user is moved to URA_PCH. Static users will stay in CELL_PCH state and will be able to be paged only on their cell (location known at cell level in CELL_PCH state while location is known at URA level in URA_PCH state).

6.1.2 IRM SCHEDULING DOWNGRADE/UPGRADE INTERWORKING

HSxPA links are not eligible to iRM scheduling downgrade/upgrade procedures.

6.1.3 IRM CAC/IRM PRE-EMPTION INTERWORKING

HSDPA links are not eligible to iRM Cac/iRM Pre-Emption procedures since the throughput adaptation is provided by the Mac-hs scheduler i.e. the more users multiplexed on HS-DSCH, the less users will be allocated high bit rates.

However, as it is possible to reserve some power for HSDPA users, this power shall be consider as consumed in cell color calculation for the HSDPA cells.

In the same way, OVSF codes reserved for HS-PDSCH and HS-SCCH are considered to be used in the cell color calculation.

In UA4.2 and UA5.0 (when feature Dynamic Code tree management is deactivated) the OVSF codes load is computed following the usual formula:

∑−=SFAll SF

actorSpreadingFeeCodesPerNumberOfFr

torsreadingFacNumberOfSpLoadCode

_

*1

1_

Where SF=4, 8, 16, 32, 64, 128 and 256 (NumberOfSpreadingFactors=7).

In UA5.0, when the feature Dynamic Code tree management is activated (see section 3.3.2.1.2 for details) the code load is computed according to the following formula:

∑

×−

×+

−=SFAll SF

SFdesfHsPdschCominNumberOCeil

SFPdschocatedToHs16CodesAllNumberOfSFCeil

actorSpreadingFeeCodesPerNumberOfFr

torsreadingFacNumberOfSpLoadCode

_

16(

16(

*1

1_

Where Ceil(x) , is the function that rounds to the nearest integer equal or greater than x (because SF/16 can be fractional).




The goal is to make the HS-PDSCH codes that can be stolen considered as free by the iRM color calculation. Nevertheless, the minNumberOfPdschCodes are considered as used in the cell code load computation. For IRM cell color, numberOfHsPdschCodes (UA4.2) and minNumberOfHsPdschCodes (UA5.0) have the same impact: SF16 codes that can not be used by R99. So, if admission strategy (iRM cell color thresholds) has been defined according to numberOfHsPdschCodes in 4.2, then, in UA5.0 with DCTM enabled, thresholds have to be changed according to minNumberOfHsPdschCodes in order to keep the same admission strategy (except if numberOfHsPdschCodes = minNumberOfHsPdschCodes ).

Moreover, the iRM thresholds can be tuned independently from the HSDPA configuration.

The operator may tune iRM thresholds so that color turns yellow before stealing HS-DSCH codes and red before having stolen all HS-DSCH codes.

For more details see UTRAN Parameters Used Guide [R01]

On the Iub, the Iub load color takes into account the actual traffic on the link on a selected set of VCC QoS, so may include or not HSDPA traffic according to operator’s provisioning.

6.1.4 RB ADAPTATION INTERWORKING

HSxPA links are not eligible to RB Adaptation procedures.

Note : the RB Adaptation is applied independently on the UL link in case of UL DCH with DL HSDPA.

6.2 MOBILITY PROCEDURES

This section describes the existing mobility procedures for HSxPA calls.

If there is any error during HSxPA mobility procedure the RAB is released.

If it is not possible to re-establish HSxPA on the new primary (CAC failure), HSPA to DCH fallback mechanism is applied if provisioned (cf. relative section), otherwise RNC triggers IU-PS Release procedure.

Mobiles can be spread over HSxPA and not-HSxPA layers thanks to RRC Traffic Segmentation, iMCTA and HCS features, as presented into Multi-carrier management section.




6.2.1 INTRA-FREQUENCY MOBILITY FOR HSXPA

6.2.1.1 MOBILITY OF ASSOCIATED DCH

Soft and softer handovers are handled normally on the associated DCHs and the Active Set is managed as usual.

For more details, see the Mobility chapter in UTRAN Parameters User Guide,[R01].

6.2.1.2 MOBILITY OF HS-DSCH

As defined by 3GPP, HS-DSCH is established in only one cell so is never in soft handover . In Alcatel-Lucent implementation, the serving HS-DSCH RL always follows that of the primary cell.

When a cell is added in the active set without primary cell change (i.e. HS-DSCH still running on former primary cell), the new radio link is established with DL SRB 3.4 kbps + DL TRB 0 kbps (+ another possible DL TRB in case of multi-service).

Mobility is done as long as the target cell is HSDPA capable. When the primary cell changes:

• If the former primary cell is no longer present in the new Active Set (following an Active Set Update procedure), the HS-DSCH link is immediately released (NBAP RL Deletion) before the RRC Measurement Control procedure. A new HS-DSCH link is then setup – using a normal SRLR procedure – on the new primary cell, after the RRC Measurement Control.

• If the former primary cell remains in the Active Set, the HS-DSCH RL is deleted on the former primary (right after the RRC Measurement Control procedure) and it is re-established under the new one synchronously via the RRC RB Reconfiguration message.

• If the new primary cell does not support HSDPA then the RB is reconfigured to DCH. iRM CAC is performed and if there is a CAC failure, the call is dropped.

• If the new primary cell supports HSDPA while the former did not, then the RB is reconfigured to HS-DSCH. In case HSDPA CAC failure occurs, fallback to DCH may occur if provisioned; IU-PS is released otherwise.

During the reconfiguration, data transfer is suspended by the RNC. Data that were in the Mac-hs buffer of the former cell are discarded (except if both cells are managed by the same H-BBU board). User data are not lost thanks to RLC retransmissions but if the primary cell changes too often, the data throughput can be impacted.




Figure 48: HS-DSCH link is deleted and re-establish ed on new primary (nominal case)


In case of TMA usage, externalAttenuationMainDivUL/DL values need to be accurately filled with cable losses. Otherwise, HSDPA mobility can be highly impacted (UL reception asymmetry for soft handover).

6.2.1.3 MOBILITY OF E-DPCH

When a cell is added in the active set without primary cell change (i.e. E-DPCH still running on former primary cell), the new radio link is established with UL SRB 3.4 kbps + UL TRB 0 kbps (+ another possible UL TRB in case of multi-service).

When the primary cell changes, intra-frequency mobility of the E-DPCH serving link is managed through deleting and re-establishing on the new primary cell (synchronous reconfiguration if the new primary cell was in the old active set). The HS-DSCH is reconfigured in the same SRLR procedure.

RNC Node B

source

Node B

target

UE

RB Reconfiguration (Activation CFN)

RL Reconfiguration Ready

Measurement Control (new neighbouring list)

RL Reconfiguration Prepare (HS-DSCH information)

RB Reconfiguration Complete

Primary cell change


RL Reconfiguration Prepare

(MAC-d flow to Delete)

RL Reconfiguration Commit (Activation CFN)

Activation CFN

RL Reconfiguration Commit

(Activation CFN)




If it is not possible to establish the E-DPDCH on the new cell (i.e. HSUPA CAC failure) then the RAB mapped on E-DPDCH is released unless HSUPA to DCH fallback is provisioned (cf. HSxPA CAC section).

When a new primary cell is selected, the transport channel type selector is played:

• If the old primary cell was E-DCH and not the new one, the RB is reconfigured to DCH.

• If the old primary cell was not E-DCH but the new one is, the RB is reconfigured to E-DCH.

• If the new primary cell is E-DCH and the call was E-DCH, then call is kept on E-DCH.

Figure 49: E-DPCH link is deleted and re-establishe d on new primary (nominal case)

RNC Node B

source

Node B

target

UE

RB Reconfiguration (Activation CFN)


Measurement Control (new neighbouring list)

RL Reconfiguration Prepare (E-DPCH information)

RB Reconfiguration Complete

Primary cell change


RL Reconfiguration Prepare (E-DCH

MAC-d flow to Delete)

RL Reconfiguration Commit (Activation CFN)

Activation CFN

RL Reconfiguration Commit

(Activation CFN)




6.2.1.4 FULL EVENT SHO SETTING FOR HSXPA

UA4.2 ETP lead to specific SHO setting for standalone HSDPA UsHoConf (with respect to DCH recommendation depicted in UPUG Vol. 7, [14]).

• cpichEcNoReportingRange1A = 3.5 dB

• cpichEcNoReportingRange1B = 5.5 dB

• hysteresis1D = 4 (i.e. 2 dB)

• timeToTrigger1D = 1280 ms

The following rule applies in UA5.0 regarding HSDPA multi-service UsHoConfs newly introduced in UA5.0.

Rule: SHO setting for HSDPA multi-service UsHoConfs

A specific rule must be defined for the SHO settings of the newly introduced HSDPA multi-service UsHoConfs:

• Applicable to reportingRange 1A, 1B, 1E and 1F

• DCH setting shall be applied to HSDPA multi-service UsHoConfs

Some other SHO settings are defined per MeasurementConfClass, i.e. per FDD cell, which are thus common to standalone DCH, standalone HSDPA and HSDPA multi-service UsHoConfs. In such a case, the following rule shall apply:




Rule: Common SHO setting for HSxPA-capable FDD cell

A specific rule must be defined for the SHO settings that are common to all UsHoConfs in case FDD cell is HSxPA capable:

• Applicable to timeToTriggers plus reportingRange 1C and 1D

• HSDPA setting shall be applied to HSxPA-capable cell

The following table summarizes the recommended parameters set, when Full Event for SHO is used:

Eve

nt

Parameter Object

Standalone

HSDPA

UsHoConf

Multi-service

HSDPA

UsHoConfs

cpichEcNoReportingRange1A FullEventHOConfShoMgt 3.5 dB 4.5 dB 1A

timeToTrigger1A FullEventRepCritShoMgtEvent1A 200 ms

cpichEcNoReportingRange1B FullEventHOConfShoMgt 5.5 dB 7.5 dB 1B

timeToTrigger1B FullEventRepCritShoMgtEvent1B 1280 ms

hysteresis1C FullEventRepCritShoMgtEvent1C 7.5 dB 1C

timeToTrigger1C FullEventRepCritShoMgtEvent1C 320 ms

hysteresis1D FullEventRepCritShoMgtEvent1D 4

timeToTrigger1D FullEventRepCritShoMgtEvent1D 1280 ms

1D

useCioFor1D FullEventRepCritShoMgtEvent1D False

shoLinkAdditionAbsoluteThresholdEnable SoftHoConf False

cpichEcNoThresholdUsedFreq1E FullEventHOConfShoMgt -11 dB (N.S.)

1E

timeToTrigger1E FullEventRepCritShoMgtEvent1E 100 ms (N.S.)

shoLinkDeletionAbsoluteThresholdEnable SoftHoConf True

cpichEcNoThresholdUsedFreq1F FullEventHOConfShoMgt -15 dB

1F

timeToTrigger1F FullEventRepCritShoMgtEvent1F 640 ms

Table 33: SHO Event Recommended Settings Summary

6.2.1.5 INTRA-FREQUENCY MOBILITY OVER IUR

HSDPA OVER IUR:

HSDPA over Iur capability is required in both SRNC and DRNC to allow the handling of the configuration, maintenance and release of active HSDPA calls over Iur. In




HSDPA mode, the SRNC configures one radio link to the UE with HS-DSCH specific

information.

• As a SRNC, the decision to configure an existing RL over Iur with HSDPA is taken

when the primary cell selection results with a cell belonging to a neighbouring

RNC. The request is sent to the neighbouring RNC using a RNSAP Radio Link

Reconfiguration Prepare message with HS-DSCH information. The UE is

configured accordingly.

• As a DRNC:

o In a Alcatel-Lucent - Alcatel-Lucent case, an existing radio link is configured to HSDPA when the DRNC receives a RNSAP Radio Link Reconfiguration Prepare message with HS-DSCH IEs.

o In a non Alcatel-Lucent - Alcatel-Lucent case, an HSDPA configuration

occurs when the DRNC receives a RNSAP Radio Link Setup Request or

a Radio Link Reconfiguration Prepare message with HS-DSCH IEs.

Restriction: HSDPA over Iur fully supported on UA5. 1

Iub Bandwidth Limitation feature does not take into account DL traffic (NDS and HSDPA) coming through Iur. Therefore, in case of Iub congestion on the Drift leg, no back pressure mechanism is implemented on Drift RNC. Please refer to Transport section for more details.

Due to this restriction, HSDPA mobility over Iur is under test restriction in UA5.0.

This restriction will be removed in UA5.1 with feature 29817 HSDPA over Iur b/w managment.

Restriction: HSDPA over Iur with non Alcatel-Lucent RNC

HSDPA over Iur is not guaranteed when facing non Alcatel-Lucent RNC. (for details refer to [R08])

Therefore, in such cases, on Alcatel-Lucent serving RNC, the neighbour RNC should be provisioned as non HSDPA capable.

HSUPA OVER IUR:

Restriction: HSUPA over Iur

In UA5.0, HSUPA over Iur is NOT supported.

While HSUPA running, if the primary cell goes under the control of a DRNC then the SRNC will consider that the new primary is not E-DCH capable and, as such, will perform an UL Transport Channel type switching to DCH whereas DL HS-DSCH is properly reconfigured over Iur (in case HSDPA over Iur is provisioned).

PARAMETERS:




isHsdpaOverIurAsSrncAllowed : This parameter allows RNC to enable/disable HSDPA over Iur when acting as a Serving RNC.

Parameter isHsdpaOverIurAsSrncAllowed Object RadioAccessService Range & Unit Boolean


Granularity RNC

Value FALSE

isHsdpaOverIurAsDrncAllowed : This parameter allows RNC to accept/reject HSDPA reconfiguration over Iur when acting as a Drift RNC.

Parameter isHsdpaOverIurAsDrncAllowed Object RadioAccessService Range & Unit Boolean


Granularity RNC

Value FALSE

isHsdpaAllowed : This parameter defines the HSDPA capabilities of neighbouring RNC to which Iur link is provisioned.

Parameter isHsdpaAllowed Object NeighbouringRNC Range & Unit Boolean


Granularity RNC

Value FALSE

Engineering Recommendation: isHsdpaOverIurAsSrncAllowed and isHsdpaAllowed

isHsdpaAllowed dealing with neighbouring RNC must be set to TRUE in case isHsdpaOverIurAsSrncAllowed = TRUE, otherwise HSDPA will be reconfigured into DCH at primary cell change.

Parameter isHsdpaAllowed Object UMTSFddNeighbouringCell Range & Unit False, True User Customer Class 3

Granularity Cell

Value True




6.2.2 COMPRESSED MODE WHILE IN HSXPA

6.2.2.1 COMPRESSED MODE IN MAC-HS

6.2.2.1.1 FEATURE DESCRIPTION

The feature “Compressed mode in Mac-hs” consists in taking into account the existence of the DL&UL compressed frames (i.e. both compressed slots and transmission gaps) as un-scheduling criterion for the connected HSDPA user in CM period. Thus, no data re-transmission or transmission is performed by the MAC-hs scheduler for the UE in CM period during a UL&DL compressed frame. Any re-transmission as well as transmission of data blocks during the transmission gaps is a loss of scheduling efficiency while other active UE(s) are potentially eligible to the MAC-hs scheduler. Informing the MAC-hs with the DL CM pattern to prevent any waste of scheduling activity on these connected UE maximizes the packet scheduler efficiency in focusing only on listening UE(s) (i.e. out of the transmission gaps).

The feature allows maximizing the cell HSDPA throughput avoiding in wasting MAC-hs scheduling resources during compressed frames of connected HSDPA user.

The principle of the CM in mac-hs can be divided into 3 parts:

• Compressed mode configuration

• Transmission gap patterns evaluation

• Compressed frames management

Note that the two first parts are also applicable to HSUPA

6.2.2.1.2 COMPRESSED MODE CONFIGURATION

The parameters of transmission gap patterns are given by the RNC via the Transmission Gap Pattern Sequence Info (TGPSI) IE. It is provided either in the RL Setup procedure or in the RL Reconfiguration Prepare one.

The activation of these patterns is performed via the Activation Pattern Sequence Info (APSI) provided either in the RL Setup or in the commit message of an SRLR procedure, or finally via the dedicated procedure Compressed Mode Command.

The configuration of the HS-DSCH for a UE may then occur before, after or at the same time of both or only one of these two IEs. In all cases, they must be forwarded to the H-BBU.

As the APSI specifies only the activation CFN for the pattern, H-BBU has to be inform on the current status of these patterns in order to avoid any ambiguity (in case that activation CFN for the pattern already started when configuring the HSDPA part). The additional needed information is:




o Current CFN . It corresponds to the current CFN observed on the D-BBU when reporting this CM status information.

o CMCFN. It corresponds to the CFN at which new activations have to be taken into account (provided in the CM Command message). A specific value “INVALID” indicates that the CMCFN already elapsed on D-BBU.

o Status [Id] 2. Four states are defined:

o Not started - the activation CFN provided in the APSI (TGCFN) corresponds to the next CFN with this value unless CMCFN is provided. In that case, the activation CFN corresponds to the next CFN with that value after CMCFN (activation occurs at CMCFN if values are equal).

o On going - the pattern already started. The activation CFN information is then useless and the position in the pattern must be recovered thanks to the three included parameters defined below. If CMCFN is valid, current patterns have to be stopped at CMCFN if not finished yet.

o On going + not started – this mix state can only be notified if CMCFN is valid. In that case, the on going pattern is handled as previously described but must be stopped at CMCFN. Then, the new APSI is provided and must be taken into account as described in the “not started” state.

o Finished – the pattern is already finished so the whole activation information can be ignored. Note that this state is not explicitly needed as it may also be deduced by the non-presence of pattern Id in CM status.

o Current TGP [Id] (only if “on going” or “on going + not started” state). Fits in the range [0..TGPRC-1].

o Position in pattern [Id] (only if “on going” or “on going + not started” state). Fits in the range [0..TGPL-1].

o TGPRC [Id] (only if “on going” or “on going + not started” state). Range [0..511].

o APSI [Id] (only if “not started” or “on going + not started” state).

[Id] means that this information must be provided for each configured pattern.

This information should be provided by the D-BBU in the “DBBU Info Response” already sent to provide some synchronization information. This information must systematically be provided to the H-BBU except in case of RL Setup.

6.2.2.1.3 TRANSMISISON GAP PATTERNS EVALUATION

Upon reception of all compressed mode information indicated above, the H-BBU must then determine if patterns are active or not. If a pattern is active, the current position within it must then be derived. Once this is performed, the on going evaluation of the frame status (compressed or not, position of the gaps, etc) must continue as for the DCH.

2 [Id] means that this information must be provided for each configured pattern.




To determine the current position in the pattern, the H-BBU needs information of both the APSI and the CM status. The following rules describe the way of using this information. These rules must be applied for each pattern independently, either UL or DL.

The action to perform mainly depends on the reported status:

� If the pattern is reported as not started yet on the D-BBU, H-BBU must ensure it has not started during the time the message has been forwarded from the D-BBU to the H-BBU… If not, no specific action is required except waiting for the TGCFN. If yes, current position must be computed and the pattern will then continuously be evaluated.

� If the pattern is reported as already started, the H-BBU must then retrieve the current position (that is not the same as the one reported in the message as some time elapsed…).

� If the pattern is reported as both on-going and not started yet, it means that H-BBU must retrieve position in current pattern and continue to evaluate it until CMCFN. Then the new APSI will be taken into account.

� Finally, if the pattern is reported as finished, no action is required anymore.

6.2.2.1.4 COMPRESSED FRAMES MANAGEMENT

Once the status of each pattern is clarified and position within the pattern determined, several actions can be performed on the H-BBU.

The H-BBU can decide not to schedule a UE in two cases:

• when his HS-PDSCH or HS-SCCH sub-frame overlaps with a DL compressed frame .

• when his ACK/NACK will overlap with an UL transmission gap. As the forecast of this event is tricky, the decision is done with the DL pattern (if processing is at a frame level) by assuming that UL and DL are often synchronous.

In UL, the compressed mode patterns needs to be consider precisely on a slot basis to precisely take into account the gap in order to perform properly the channel impulse response estimation (Anytime an UL frame is compressed, the right DPCCH pilot bits sequence must be assumed (the number of pilot bits is changed as well as the pattern). Anytime a slot is not transmitted, the impulse response estimation must not be performed). This information can also be used in order to properly handle the ACK/NACK and CQI fields:

• If the ACK/NACK overlaps with a transmission gap, it is not transmitted by the UE. In that case, a DTX must be assumed.

• If the CQI sub-frame overlaps with a transmission gap, it is not transmitted by the UE so it should not be taken into account and the last CQI value should be assumed.




6.2.2.2 COMPRESSED MODE IN MAC-E

Restriction: Compressed mode in MAC-e

Compressed mode in MAC-e will not be supported in UA5.0. Impact of not having this feature during UA5.0 period:

- No impact on Call Drop.

- Impact on the data transfer performance for HSUPA calls in mobility.

6.2.3 INTER-FREQUENCY AND INTER-SYSTEM HHO FOR HSXPA

In UA5.0, CM for Inter-frequency and Inter-system is supported while in HSxPA (cf. previous section). Therefore, Inter-frequency and Inter-system HHO can occur following iMCTA Alarm, CAC or Service triggering. The selection between FDD and 2G Access is part of iMCTA algorithm, mostly based on UE capabilities, priority tables and available neighbouring cells (cf. [R01]).

The measurement configuration procedure is the same as for non-HSxPA RAB:

• Configuring CM and neighbouring cells to be reported by UE through RRC Measurement Control messages

• Configuring CM in NodeB through NBAP Compressed Mode Command message

PARAMETERS:

isInterFreqMeasActivationAllowed : This parameter indicates if the inter-frequency measurement activation is allowed or not in the RNC.

Parameter isInterFreqMeasActivationAllowed Object RadioAccessService Range & Unit Boolean


Granularity RNC

Value TRUE




isInterFreqCModeActivationAllowed : This parameter allows to enable CM activation for Inter-frequency measurements, per DlUserService.

Parameter isInterFreqCModeActivationAllowed Object DlUserService Range & Unit Boolean



Value See following recommendation

isGsmCModeActivationAllowed : This parameter allows to enable CM activation for GSM measurements, per DlUserService.

Parameter isGsmCModeActivationAllowed Object DlUserService Range & Unit Boolean



Value See following recommendation


isInterFreqCModeActivationAllowed and isGsmCModeActivationAllowed must be set to TRUE for the all DlUserServices that include HS-DSCH:

• HS-DSCH + SRB

• CSD 64 + HS-DSCH + SRB

• CS + HS-DSCH + SRB

• Any PS Streaming + HS-DSCH + SRB

• CS + any PS Streaming + HS-DSCH + SRB

This setting is also applicable to HSUPA RAB as the parameters are per DlUserService (i.e. HS-DSCH).

Restriction:

CM in MAC-e has been de-scoped from UA5.0. However, CM can not be deactivated as isInterFreqCModeActivationAllowed and isGsmCModeActivationAllowed are defined by DlUserService, i.e. HS-DSCH.

6.2.3.1 INTER-FREQUENCY MOBILITY FOR HSXPA

Any transition is now supported either Intra- or Inter-RNC:

• HSxPA to DCH

• HSxPA to HSxPA

• DCH to HSxPA




6.2.3.1.1 INTER-FREQUENCY INTRA-RNC MOBILITY FOR HSXPA

In case of Intra-RNC HHO, RNC selects the target Transport Channel type based on:

• The activation flag of HSDPA HHO feature (isHsdpaHhoWithMeasAllowed )

• The activation flag of HSUPA HHO feature (isEdchHhoWithMeasAllowed )

• The HSxPA capabilities of the target cell and the mobile

Then, RNC establishes a Radio Link on the target cell and reconfigures the mobile on the new frequency (with new HS-DSCH and E-DCH information). Previous Radio Link is released once RNC has received RRC Radio Bearer Reconfiguration Complete from UE.

PARAMETERS:

isHsdpaHhoWithMeasAllowed : When set to FALSE, this parameter prevents any Intra-RNC HHO to HSDPA, and only the 2 following transitions can then occur for DL Transport Channel:

• HSDPA to DCH

• DCH to DCH

Note: This parameter is not used by RNC in case of outgoing and incoming HHO (i.e. Inter-RNC HHO).

Parameter isHsdpaHhoWithMeasAllowed Object RadioAccessService Range & Unit Boolean


Granularity RNC

Value TRUE

isEdchHhoWithMeasAllowed : When set to FALSE, this parameter prevents any Intra-RNC HHO to HSUPA, and only the 2 following transitions can then occur for UL Transport Channel:

• HSUPA to DCH

• DCH to DCH

Note: This parameter is not used by RNC in case of outgoing and incoming HHO (i.e. Inter-RNC HHO).

Parameter isEdchHhoWithMeasAllowed Object RadioAccessService Range & Unit Boolean


Granularity RNC

Value TRUE





If HSxPA is deployed on the same NodeB using 2 dedicated carriers, isHsdpaHhoWithMeasAllowed and isEdchHhoWithMeasAllowed must be set to TRUE in order to prevent any conflict with iMCTA Service strategy.

6.2.3.1.2 INTER-FREQUENCY INTER-RNC WITHOUT IUR MOBILITY FOR HSXPA

In case of Inter-RNC mobility, source RNC uses R5 or R6 extensions (depending on established RAB) in order to indicate in the RRC container:

• The HSxPA-capabilities of the mobile

• The RAB currently running on Source RNC (either HS-DSCH or E-DCH)

This nominal RRC container allows Target RNC to directly reconfigure the RAB in HSxPA without any DCH transition.

However, in very specific cases where HSxPA capabilities are missing (e.g. RNC 4.2 facing RNC 5.0), Target RNC first establishes the PS RAB into DCH, requests UE’s HSxPA-capabilities through RRC UE Enquiry Capability procedure and eventually reconfigures the PS RAB into HSxPA if needed.

Relocation procedures are detailed in [R01]

6.2.3.1.3 INTER-FREQUENCY INTER-RNC WITH IUR MOBILITY FOR HSXPA

Inter-frequency Inter-RNC HHO with Iur is handled the same way as for DCH calls. Please refer to UTRAN Parameters User Guide,[R01].

6.2.3.1.4 FULL EVENT HHO SETTING FOR HSXPA

Specific 2D/2F thresholds must be set to all UsHoConfs that contain HS-DSCH in order to prevent call drop that may occur due radio degradation following CM activation. The following table depicts the Engineering recommendation for HSxPA whose RSCP thresholds differs from DCH setting presented in UPUG Vol. 7 [14].




E

vent

Parameter Object

Val

ue

cpichEcNoThresholdUsedFreq2D FullEventHOConfHhoMgt -14

cpichRscpThresholdUsedFreq2D FullEventHOConfHhoMgt -97

2D

timeToTrigger2D FullEventRepCritHHOMgt 1280

cpichEcNoThresholdUsedFreq2F FullEventHOConfHhoMgt -13

cpichRscpThresholdUsedFreq2F FullEventHOConfHhoMgt -95

2F

timeToTrigger2F FullEventRepCritHHOMgt 1280

timerAlarmHOEvent FullEventHOConfHhoMgt 0

Table 34: HHO Event Recommended Settings Summary

.

Note that minimumCpichEcNoValueForHO and minimumCpichRscpValueForHO (defined per DlUserService) must be set accordingly to 2D thresholds and network topology in order to prevent abusive successive inter-frequency HHO.

6.2.3.2 INTER-SYSTEM MOBILITY FOR HSXPA

6.2.3.2.1 3G TO 2G HANDOVER

In case iMCTA has selected 2G as Target Access, RNC configures CM for Inter-System and UE may report GSM cells while in HSxPA.

Hard Handover is supported by RNC for 3G-2G mobility and is handled the same way as for R99 calls. Please refer to [R01] for more details.

If UE does not report any neighbouring cell (either Inter-Frequency or Inter-System) or if the reported signal is lower than the minimum threshold, Blind HO towards 2G may be triggered if provisioned. This is only applicable for iMCTA Alarm and CAC, not for iMCTA Service as the latter trigger is for comfort purpose.

6.2.3.2.2 2G TO 3G HANDOVER

From the target RNC, this is seen as a new Mobile Originated PS call. The same rules as the initial admission apply, leading possibly to the allocation of HSxPA to the incoming UE.




6.2.4 U-PLANE TRAFFIC HANDLING

There are 2 aspects to consider during HSDPA mobility:

1. Traffic handling policy toward the source cell.

This policy is only applicable when the old serving HS-DSCH RL is still part of the Active Set. At time (Activation Time – Suspend Time Offset), the RNC no longer sends data to the source cell.

Parameter suspendTimeOffset Object HsdpaRncConf Range & Unit Integer

[0 … 255] (x 10ms) User Customer Class 3

Granularity RNC

Value 24

2. HS-DSCH credit acquisition policy from the targe t cell .

Based on the following NodeB behaviour specifications:

• All HS-DSCH Capacity Requests that are sent to the NodeB before the starting activation time are silently discarded.

• When the credits are not yet explicitly granted, the NodeB silently delete HS-DSCH data coming from the RNC (i.e. no HS-DSCH Capacity Allocation is sent to the RNC).

• After the activation time, on the first HS-DSCH Capacity Request with nonzero BO (Buffer Occupancy), the NodeB immediately replies with HS-DSCH Capacity Allocation.

• In the steady-state (after that first HS-DSCH Capacity Request message), a Capacity Allocation can be sent at any time (depending on NodeB buffer occupancy) indicating to the RNC the number of MAC-d PDUs it can send for the corresponding MAC-d flow with the associated priority. This is done without needing a Capacity Request and without evaluation the BO (RNC Buffer Occupancy).

The RNC HS-DSCH initial credit acquisition policy is as followed:

1. If an initial HS-DSCH credit is explicitly returned by the NodeB in the NBAP RL Reconfiguration Ready message, the RNC will start to use that credit at the activation time. Otherwise, the RNC will assume that the credits are set to zero. This is applicable to both intra and inter-NodeB mobility cases.

2. At the activation time, if the HS-DSCH credit is zero and there are outstanding data to be transmitted, the RNC will initiate the HS-DSCH Capacity Request toward the target cell in the u-plane – nothing will be sent before the activation time.




6.2.5 EXAMPLE OF INTER-FREQUENCY AND INTER-SYSTEM SCENARIO

The following example depicts a topology where HSxPA is deployed on a dedicated carrier.

R99 R99R99 R99

HSxPA

R99

HSxPA

GSM

HSxPA

R99

��

R99 R99R99 R99

HSxPA

R99

HSxPA

GSM

HSxPA

R99

��

Figure 50: Example of Inter-frequency and Inter-Sys tem scenario

Three HHO scenarios are presented on the figure (among many others):

1. An HSxPA user performing PS call enters HSxPA coverage: after SHO mobility, iMCTA Service triggers Inter-frequency HHO towards the HSxPA layer.

2. An HSxPA mobile performing HSxPA call leaves HSxPA coverage: iMCTA Alarm triggers Inter-frequency HHO towards R99 layer.

3. A mobile is leaving the UMTS coverage: iMCTA Alarm triggers Inter-system HHO towards GSM.

Please refer to:

• [R01]for complete details on iMCTA algorithm and settings




6.3 POWER MANAGEMENT

6.3.1 INTRODUCTION

The HSDPA principle is to allocate the power not used by DCH calls to HSDPA channels. This implies an accurate power management in order to not impact DCH calls and to allow the highest data rate on HSDPA channels.

Power management is based on two features:

• the flexible power management feature,

• the HS-SCCH power control feature.

When the cell is HSUPA capable, the new DL channels associated to E-DCH request some additional power: E-AGCH and E-HICH channels (E-RGCH channel being not used in this release).

For power computation, described below, this DL HSUPA power is considered as DCH power. Note that the power consumes for DL HSUPA is low (few percentage of PA).

For simplification, in the following paragraph, “DCH channels” refers only to DCH channels when HSUPA is not activated and to DCH + DL HSUPA channels when HSUPA is activated.

6.3.2 FLEXIBLE POWER MANAGEMENT FEATURE

6.3.2.1 AIM

The aim of this feature is to adapt the power allocated to HSDPA channels according the DCH power variation without impacting DCH calls.

6.3.2.2 POWER ALLOCATION

6.3.2.2.1 RNC LEVEL

First, the RNC reserves power for common channels. Typically, the common channels power is equal to about 20-25% of the maximum cell power noted PMaxCell in the following figure.

Note that the common channels power reserved by RNC supposed 100% activity for each channels. That leads to over-estimate the power consumption compared to the NodeB.




PmaxHsdpa

CCCRNC

SHO margin

RN

C

OCNS (opt.)

PminHsdpa

PMaxCell

HSUPA

Ptraffic

PmaxHsdpa

CCCRNC

SHO margin

RN

C

OCNS (opt.)

PminHsdpa

PMaxCell

HSUPA

Ptraffic

Figure 51: Power allocation at RNC level

When OCNS is required (for cell loading during acceptance or trial tests), his power is defined as a percentage of the power not used by common channels such as:

POCNS = (PMaxCell - PCCC) x OCNSpower

where OCNSpower = [0 … 100]%

It is possible to reserve a minimum power for HSDPA noted PminHsdpa that is subtracted from the power of the DCH pool. This power is defined through the minimumPowerForHsdpa parameter such as:

PminHsdpa = PMaxCell – minimumPowerForHSDPA

So, the higher this parameter, the lower the minimum power for HSDPA. This power is reserved for the purposes of the Call Admission Control (CAC) only and then can not be guaranteed at NodeB level if some DCH users need more power. This reservation limits the DCH admission. This power is reserved after OCNS one (if OCNS is activated in the cell) and this may lead to refuse the configuration of HSDPA if there is not enough power.

Rule: Relationship between OCNS power and minimum p ower for HSDPA

The minimum power for HSDPA PminHsdpa is reserved after OCNS one (if OCNS is activated in the cell) and this may lead to refuse the configuration of HSDPA if there is not enough power.

PminHsdpa < PMaxCell - POCNS - PCCC




Note : the activation of OCNS with HSDPA & Multiple S-CCPCH requires modifications of OCNS default parameters. Refer to section 3.3.2.1.2 for more details.

The minimum power for HSDPA is managed by the RNC as the SHO margin. It is a power reservation used only for CAC and can not be guaranteed at NodeB level. The SHO margin allows to reserve power for the users in soft handover and can not be used for users in first admission. This power is a percentage of the traffic power:

PSHO = (1 - CallAdmissionRatio ).Ptraffic

with :

In UA4.2 : Ptraffic = PMaxCell - PCCC - POCNS - PminHsdpa

In UA5.0 : Ptraffic = PMaxCell - PCCC * ActivityFactorCch - POCNS - Pedch - PminHsdpa

ActivityFactorCch is hard coded to 66% and Pedch is linked to the parameter eagchErgchEhichTotalPower (see 3.3.3.3).

Recommended value for CallAdmissionRatio is 85%

In UA4.2, this leads to define the maximum power that the RNC can allocate to HSDPA channels: PmaxHsdpa. This maximum power is computed at the RNC and given to NodeB during the cell setup inside the physical shared reconfiguration channel NBAP message. In UA4.2, this upper limit for HSDPA correspond to the maximum downlink transmit power of the cell minus the power needed for the common channel, the power for eventual OCNS and the power reserved for SHO:

PmaxHsdpa = PMaxCell - PSHO - PCCC - POCNS

In UA5.0, a maximum power that the RNC can allocate to HSxPA channels is defined and an activity factor is applied on the common channel power and SHO power is not taken into account anymore because power consumption these channels is over-estimated (activity factor at RNC level equal to 1) especially if several S-CCPCH channels are configured. Without this modification and because of new channels such as S-CCPCH channels, the probability to be HSDPA power limited is high. So, the UA5.0 formula is:

PmaxHspa = PMaxCell - PCCC * ActivityFactorCch - POCNS

ActivityFactorCch being hard coded to 66%.

Typically, PmaxHspa was around 60% of PA power in UA4.2 whereas it is around 80% in UA5.0 thanks to the activity factor on common channels.

In UA4.2, the maximum power is transmitted from the RNC to the NodeB in the information element (IE) HS-PDSCH_and_HS-SCCH_total_power through the PHYSICAL SHARED CHANNEL RECONFIGURATION MESSAGE during the cell setup. In UA5.0 this IE is replaced by HS-PDSCH_HSSCCH_EAGCH_E-




RGCH_and_E-HICH_Total_Power. If it is not present, HSDPA can be allocated the whole power. The number of HS-PDSCH and HS-SCCH reserved in the cell are also sent through this message, respectively in the IE HS-PDSCH_FDD_code_information and HS-SCCH_FDD_code_information (see the following figure).

PHYSICAL SHARED CHANNEL RECONFIGURATION MESSAGE

during Cell Setup

HS-PDSCH_FDD_code_information

HS-PDSCH, HSSCCH, EAGCH, E-RGCH and E-HICHTotal Power

HS-SCCH_FDD_code_information

HS-PDSCH_FDD_code_information

HS-PDSCH, HSSCCH, EAGCH, E-RGCH and E-HICHTotal Power

HS-SCCH_FDD_code_information

Figure 52: Physical shared channel reconfiguration message

6.3.2.2.2 NODEB LEVEL

In a HSDPA cell, a new margin is introduced in order to anticipate power fluctuation on DCH channel mainly due to power control and then avoid PA overload: the DCH margin (see the following figure). HSDPA channels can not use this margin. If the power for DCH calls exceeds the DCH power margin then HSDPA will reduce his power to provide DCH calls with power resource.

PRemain

PTotNonHsdpaWithMargin

CCCNodeB

DCH margin

DCHNod

eB

OCNS (opt.)

PMaxCell

PTotNonHsdpa

E-DCH

PRemain

PTotNonHsdpaWithMargin

CCCNodeB

DCH margin

DCHNod

eB

OCNS (opt.)

PMaxCell

PTotNonHsdpa

E-DCH

Figure 53: Power allocation at NodeB level




Note that the common channel consumption at NodeB level is lower than at RNC level due to activity factor consideration.

The power consumed by this DCH margin depends on the dchPowerMargin parameter. This parameter is a percentage of the non HSDPA power minus the P-CPICH power:

PDCHmargin = dchPowerMargin.(PTotNonHsdpa – PCPICH)

where PTotNonHsdpa is the sum of the DCH power, OCNS power, common channels power and the E-DCH power:

PTotNonHsdpa = PDCH + POCNS + PCCC + PE-DCH

The dchPowerMargin parameter should be tuned so that the DCH margin is large enough to manage the power fluctuation on the DCH and so that not too much unnecessary power is reserved.

The remaining power PRemain is the power usable by HSDPA:

PRemain = PMaxCell – PTotNonHsdpaWithMargin

with PTotNonHsdpaWithMargin = PTotNonHsdpa + PDCHmargin

Note that the common channels power used by the NodeB is fewer than power reserved by RNC because of time multiplexing of several common channels.

6.3.2.2.3 POWER AVAILABLE FOR HSDPA CHANNELS

Flexible power management feature consists in using for HSDPA all the remaining power left by dedicated and common channels according the RNC upper limit. Then, the power available for HSDPA is defined by:

PHSDPA = min(PRemain, PmaxHspa)

6.3.2.3 POWER MEASUREMENTS

The computation of the available HSDPA power requires some power measurements.

6.3.2.3.1 TRANSMITTED CARRIER POWER

The transmitted carrier power PTotCell (see the following figure) is the total cell power consumed by all codes. This transmitted carrier power is measured and




communicated within the BTS every 100ms through a Power Management Message (PMM) ATM cell.

6.3.2.3.2 AVERAGED HSDPA POWER

The averaged total power transmitted on the HS-PDSCH and HS-SCCH codes PTotHsdpa (see the following figure) is computed and updated any TTI. An exponential averaging is applied, whose coefficient is chosen to be coherent with the PMM measurement. Any TTI, the following processing must then be done:

PTotHsdpa(TTI) = Rho.PTotHsdpa(TTI – 1) + (1 – Rho).PInstHsdpa(TTI)

where PInstHSDPA corresponds to the total transmitted power of HSDPA over the TTI in linear, and Rho is the weighting factor (Rho = 0.9775). PTotHSDPA should be initialized with the instantaneous value.

Power consumed by

all codes

Nod

eB

PMaxCell

PTotCell

Power consumed by non HSDPA

codes

Nod

eB

PMaxCell

PTotCell

HSDPA PTotHsdpa

Figure 54: Transmitted carrier power (on the left) and averaged HSDPA power (on the right)

Note that power consumed by non HSDPA codes includes, in this release, the downlink HSUPA channels.

6.3.2.3.3 TOTAL NON HSDPA POWER

The total power not used by HSDPA (PTotNonHsdpa) is then computed over the last period by subtracting the total HSDPA power to the total cell power:

PTotNonHsdpa = PTotCell - PTotHsdpa

This measurement is reported (see the following figure) from the NodeB to the RNC through a COMMON MEASUREMENT message in the element information (IE) Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, E-




AGCH, E-RGCH or E-HICH transmission defined as a percentage of the max cell power. This measurement is used by the RNC CAC on DCH (only for HSxPA cells) instead of Transmitted Carrier Power measurement (this latest continues to be reported and is still used for non-HSDPA cells). The measurement period is 100ms but the report periodicity (for these two measurements) toward RNC is much higher (1mn).

COMMON MEASUREMENT

Transmitted carrier power of all codes not used for HS-

PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmissi on

COMMON MEASUREMENT

Transmitted carrier power of all codes not used for HS-

PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmissi on

Figure 55: Common measurement

Restriction: Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH or E-HICH transmission

In UA5.0, the NodeB will not remove the E-DCH contribution to the power measurement, leading to slightly overestimate the R99 contribution and impact DCH call admission control. This effect can be attenuated by increasing DCH admission threshold on power for HSUPA cells (see [R08] for details)

6.3.2.3.4 AVAILABLE HSDPA POWER

The available power for HSDPA for the next 100ms period can then be computed. It corresponds to the difference between the maximum available power in the cell PMaxCell and the total non HSDPA power with DCH margin PTotNonHsdpaWithMargin. It is bounded by PMaxHspa:

PHSDPA = min(PMaxCell - PTotNonHsdpaWithMargin , PMaxHspa)

with PTotNonHsdpaWithMargin = (1+ DchPowerMargin/100) * (PTotNonHsdpa - PCPICH) + PCPICH




The following flowchart summarize this measurement process:

Update transmitted HSDPA power (P TotHsdpa ) any TTI PMM ATM cell reception any 100ms

Y

ATM cell received ? Recovery in the ATM payload of the «Transmitted Carrier Power » of the

corresponding cell P TotCell

N

Computation of the « Transmitted carrier power on non HSDPA channels »

PTotNonHsdpa = PTotCell - PTotHsdpa

PTotCellPTotHsdpa

PTotNonHsdpa

Assume a margin on the non HSDPA power.PRem = PMaxCell – PTotNonHsdpaWithMargin

Computation of the total HSDPA power available :PHSDPA = min(P Rem, PMaxHsdpa )

Transmit P TotNonHsdpa every100ms to CallP (commonmeasurement process)

Use PHSDPA as scheduler input until next refresh

PHSDPA

Figure 56: Power measurement process

6.3.2.4 HSDPA POWER DISTRIBUTION

6.3.2.4.1 HS-SCCH POWER

The available power for HSDPA PHSDPA is shared between HS-SCCH and HS-DSCH channels (see the following figure).




CCC

DCH margin

PHsdpa

DCHNod

eB

OCNS (opt.)

HS-DSCH

HS-SCCH

Figure 57: Power distribution between HS-DSCH and H S-SCCH channels

A HSDPA user is scheduled only if there is enough power for HS-SCCH i.e. if:

PHS-SCCH < PHSDPA

If not, the scheduler will try to schedule another user.

The power allocated to HS-SCCH is explained in section dedicated to the feature “HS-SCCH power control”.

6.3.2.4.2 HS-DSCH POWER

The HSDPA power not allocated to HS-SCCH can be used for HS-DSCH:

PTemp = PHSDPA – PHS-SCCH

HSDPA UE needs to have a power as reference in order to adapt his reported CQI to the radio link condition (in the same radio condition, the reported CQI will be higher if more power is used to transmit the HS-DSCH channel). Then, the CQI is chosen to insure a transmission with a given BLER (cf section 3.3.2.3.2) assuming a downlink power equals to:

PHS-DSCH[dBm] = PP-CPICH[dBm] + Γ[dB] + ∆(CQIprocessed)[dB]

where

− PP-CPICH is the power of the P-CPICH channel,

− Γ is the measurement power offset

− ∆ is the reference power offset given by the tables of CQI [R05].




This reference power PHS-DSCH is defined by a power offset compared to the P-CPICH power. This power offset corresponds to the measurementPowerOffset parameter. The mobile is able to compute this reference power thanks to the P-CPICH power measurement and to the measurementPowerOffset parameter. The measurementPowerOffset parameters is sent from the RNC to the NodeB through the HS-DSCH FDD INFORMATION message during the Radio Link Setup/Reconfiguration and from the RNC to the UE through the DOWNLINK HS-PDSCH INFORMATION message during the Radio Bearer Setup/Reconfiguration (see the following figure). In case this parameter is not present in the setup message, the configuration must then be rejected.

DOWNLINK HS-PDSCH INFORMATION

during Radio BearerSetup/Reconfiguration

HS-DSCH FDD INFORMATION

during Radio LinkSetup/Reconfiguration

measurementPowerOffset

Figure 58: measurementPowerOffset transmission

In fact, this power can be seen as the HS-DSCH power required by the mobile corresponding to his reported CQI. From a NodeB point of view, this power is the maximum power that can be allocated to one HSDPA user even if more power could be used (Note that for CQI lower than 5 the allocated power may be higher).

Note that the reference power offset ∆ is the one corresponding to the processed CQI (CQIprocessed) and not the reported CQI (CQIreported). See “CQI” section for more details.

6.3.2.4.3 HS-PDSCH POWER

The power HS-DSCH is equally distributed around the physical channels HS-PDSCH:

PHS-PDSCH[dBm] = PHS-DSCH[dBm] - 10.log(#codes)

6.3.2.5 HS-DSCH POWER MANAGEMENT

The HSDPA UE requests to the NodeB a CQI corresponding to a reference power PHS-DSCH. The power effectively available at NodeB level can be lower than this requested power. Then power adjustments are needed. Other resource limitations as codes limitation can lead to adjust the HS-DSCH power. The following section




presents how the scheduler manages the HS-DSCH power according the available resources.

6.3.2.6 FIRST TRANSMISSION

The transport formats always remain based on the CQI mapping tables. Two different CQI correspond to different transport formats with the same power to reach the same performance level, but could also correspond to two different powers with the same transport format. A step of 1dB is considered to go from one CQI to the next one.

The transport format is determined according to the processed CQI, CQIprocessed. In case of a lack of resources (codes or power), the applied CQI, CQIapplied, is then modified according to the previous rule to take this into account. It is done in four steps:

• Power limitation management,

• codes limitation management,

• lack of MAC-d PDU in buffer or transport block size limitation (multi-cell per H-BBU for instance),

• optimization of CQI according to MAC-d PDU size.




The whole process is described in the following figure:

Y

UE selected

Ptemp = PHSDPA – PHS-SCCH

PHS-DSCH = PP-CPICH + Γ + ∆(CQIprocessed)

PHS-DSCH < Ptemp ?

P’HS-DSCH = PP-CPICH + Γ

∆RP = round(10.log(Ptemp / P’HS-DSCH))

CQI1 = CQIprocessed + ∆RP

∆RP = 0

CQI1 = CQIprocessed

CQI1 > 0 ?

ncodes = f(CQI1) UE not scheduled

Y

N

N

YnCodes < nCodesRemain ?

Select the highest CQI (CQI2) which numberof codes equals the remaining number of

codes

∆RC = CQI2 – CQI1

N

∆RC = 0

CQI2 = CQI1

Enough PDU available ? TrBlk size manageable ?

Select the highest CQI (CQI3) fulfilling both criteria

∆RO = CQI3 – CQI2

N∆RO = 0

CQI3 = CQI2

Y

CQIapplied = f(CQI3, MAC-d PDU size)

∆RCqi = CQIapplied – CQI3

PHS-DSCH = PP-CPICH + Γ + ∆(CQI3) + ∆RP + ∆RC + ∆RO + ∆RCqi

P’HS-DSCH = min(PTemp, PHS-DSCH)

PRemain = PTemp – P’HS-DSCH

[nCodes, nPDU] = f(CQIapplied)

UE scheduled

Pow

er li

mita

tion

man

agem

ent

Cod

e lim

itatio

nm

anag

emen

tO

ther

limita

tion

man

agem

ent

CQ

I opt

imiz

atio

nm

anag

emen

t

Figure 59: HS-DSCH power management for 1st transmi ssion




6.3.2.6.1 POWER LIMITATION

In case there doesn’t remain enough power to transmit data corresponding to the processed CQI to a selected UE, the transport format is modified in order to reduce its power (Ptemp refers to the available power at NodeB level and PHS-DSCH to the needed power by the UE). The excess power, corresponding to the total needed power minus the maximum allowed power, is computed (∆RP). This value, expressed in dB, then directly indicates the number of CQI levels one should decrease in order to remain at the same level of performances. In case the resulting value is not valid CQI (≤0), the UE is not scheduled; otherwise the new configuration is the one considered for the next checking. Note that in case the initial processed CQI is such that the associated reference power adjustment is different from 0 (depending on UE category and associated CQI mapping table given in [R05]), it must not be considered to compute the CQI decrease, as described in the previous figure.

6.3.2.6.2 CODES LIMITATION

If the resulting configuration, corresponding to the derived CQI from the previous step (CQI1), leads to a number of necessary HS-PDSCH codes higher than the remaining one, the CQI is also reduced in order to reach the exact number of remaining codes. A power offset equal (in dB) to the difference between the input and output CQI is then applied (1dB per CQI rule). Note that if this power reduction leads to a power inferior to the minimum manageable one by the H-BBU, it is then set to this minimum power.

6.3.2.6.3 OTHER LIMITATIONS

• Less available PDUs than required

In case there are less Mac-d PDU available in the buffer than what would have allowed the scheduler to transmit relatively to the derived CQI from previous steps (CQI2), the configuration is then chosen to match to the lowest CQI (CQI3) than enables to transmit this number of PDU (see the following figure). The power must of course be decreased accordingly with the same rules than before.




320 1621 Padding

Mac-d PDU

Mac-hs transport block(CQI 2)

320 16

320 1621 Padding

Mac-d PDU

Mac-hs transport block(CQI 3)

320 16

Figure 60: Mac-hs transport block adaptation accord ing to the number of Mac-d PDU to transmit

• Limited processing resource

The processing resource may be limited in the H-BBU pool configuration for instance. All transport block sizes may then not be handled. In case the one corresponding to the last processed CQI is not manageable, the CQI is reduced to the highest one that fits with the available resources. The power is decreased as well accordingly.

6.3.2.6.4 CQI OPTIMIZATION ACCORDING TO MAC-D PDU SIZE

A last optimization is considered according to the resulting CQI from previous steps (CQI3). Indeed, the Mac-d PDU size may not allow all CQI to be used or may lead to an un-optimized solution. As the only supported Mac-d PDU size is 336 bits, the rules described below must apply:

• CQI 0: means that the mobile considers it is out of range. In such a case no data for this specific user is scheduled by the MAC-hs

• CQI 1 to 4 : in this case, the MAC-hs consider the mobile has reported a CQI 5 (see below). The scheduler relies on a power adjustment on HS-PDSCH and on the HARQ repetitions to cope with low radio link quality (+1 dB per CQI value rule).

• CQI 5 is processed normally.

• CQI 6, 7 (and resp. 9) : in this case the MAC-hs considers the mobile has reported a CQI 5 (resp. 8) to minimize padding. The scheduler lowers the power requirement on HS-PDSCH (-1dB/CQI).

• CQI 10 to 30 : are processed as described below, lowering power requirements by 1 dB per CQI when the UE is addressed using a lower MCS than the reported CQI (because of power shortage or because UE capabilities are reached)




Given the MAC-d PDU size used in this version, the following table provides the number of MAC-d which can be packed in a Transport Block, depending on the CQI value (mobile may be scheduled using a limited set of CQI values according to its UE Category). Two tables are considered for TBS selection: one is the default 3GPP one, the second is the optimized one (to minimize padding). The OMC-B parameter hsdpaUeCategoryTransportBlockOptimisation allows selecting the table to consider. Note : for some CQI, the two tables may be equal.

CQI 1 to 15 :

Transport Block Size CQI

value

Default

Optimised

Num of 336 bit MAC-d

PDU Modulation

Num of HS-PDSCH codes

1 137 1 QPSK 1 +4 dB 2 173 1 QPSK 1 +3 dB 3 233 1 QPSK 1 +2 dB 4 317 1 QPSK 1 +1 dB 5 377 365 1 QPSK 1 6 461 1 QPSK 1 -1 dB 7 650 1 QPSK 2 -2 dB 8 792 699 2 QPSK 2 9 931 2 QPSK 2

-1 dB 10 1262 1036 3 QPSK 3 11 1483 1380 4 QPSK 3 12 1742 1711 5 QPSK 3 13 2279 2046 6 QPSK 4 14 2583 2404 7 QPSK 4 15 3319 3090 9 QPSK 5

Table 35: CQI management up to CQI 15 (all UE categ ories)

CQI 16 to 22 :


value

Default

Optimised


PDU Modulation


16 3565 3440 10 16-QAM 5 17 4189 4115 12 16-QAM 5 18 4664 4420 13 16-QAM 5 19 5287 5101 15 16-QAM 5 20 5887 5782 17 16-QAM 5 21 6554 6438 19 16-QAM 5 22 7168 7168 21 16-QAM 5

Table 36: CQI management between CQI 15 and 22 (UE categories 1 to 10)

For UE categories 11 and 12, due to the fact that there are limited to 3630 bits per transport block, CQI >= 16 are scheduled using a transport block of 3440 bits (10x336 MAC-d PDU) to minimize padding (power requirements are then lowered by 1dB/CQI).




The Transport Block Size for CQI 16 is always equal to 3440 bits for Categories 11 and 12 whatever the TBS optimization activation.

CQI value Transport Block Size

Num of 336 bit MAC-d PDU Modulation Num of HS-

PDSCH codes 16 3440 10 QPSK 5

Table 37: CQI management for CQI 16 (UE categories 11 to 12)

CQI 23 to 25 :


value

Default

Optimised


PDU Modulation


23 9719 9546 28 16-QAM 7 24 11418 11216 33 16-QAM 8 25 14411 14155 42 16-QAM 10

Table 38: CQI management between CQI 23 and 25 (UE categories 7 to 10)

For UE categories 1 to 6, due to the fact that there are limited to 7298 bits per transport block, CQI >= 23 are scheduled as CQI 22 but lowering power requirements (1dB/CQI).

CQI 26 to 30 :

For UE categories 7 and 8, due to the fact that there are limited to 14411 bits per transport block, CQI >= 26 are scheduled as CQI 25 but lowering power requirements (1dB/CQI).

Table 39: CQI management for CQI 26 to 27 (UE categ ory 9)

For UE category 9, due to the fact that it is limited to 20251 bits per transport block, CQI >= 27 is scheduled using 20251 bits to minimize padding, lowering power by -1 dB per CQI (FRS29813: this may be deactivated by the parameter hsdpaMaxUeCategoryCapabilityActivation[9] : in this case, CQI >= 27 are scheduled as CQI 26 – 17237 bits- lowering power by -1 dB per CQI).

CQI value

Transport Block Size

Num of 336 bit MAC-d PDU

Modulation Num of HS-

PDSCH codes

26 17237 51 16-QAM 12

27 20251 60 16-QAM 15




CQI value Transport Block Size

Num of 336 bit MAC-d PDU Modulation Num of HS-PDSCH

codes 26 17237 51 16-QAM 12 27 21754 64 16-QAM 15 28 21754 (-1dB) 64 (iCEM) 16-QAM 15 29 21754 (-2dB) 64 (iCEM) 16-QAM 15

Table 40: CQI management for CQI 26 to 30 (UE categ ory 10)

For UE category 10 with iCEM, CQI above 27 are scheduled as CQI 27 (21754 bits), lowering power requirements by -1 dB per CQI.

Summary of maximum TBS from UE category :

As described above, if the MCS selected corresponds to a Transport Block Size that exceeds what the UE can support according to its category (see UEs of Categories 11 and 12 support QPSK only. in section 3.4.1) then a lower MCS is selected and the power requirements are lowered by -1dB/CQI. This is described in the below table.

UE category Maximum HS-DSCH TBS per TTI

(bits)

Maximum MCS TBS applied from maximum MCS (bits)

1 to 6 7298 22 7168 7 to 8 14411 25 14411

9 20251 26 20251 10 (iCEM) 27952 27 21754

(limit is iCEM capability) 11 to 12 3630 16 3440

Table 41: maximum Transport Block Size used accordi ng to UE category for PDU 336 bits

6.3.2.7 RETRANSMISSION

The same AMC than first transmission is applied for retransmissions, i.e. same transport block size, number of HS-PDSCH codes and modulation. Besides, in UA4.2 the same power is also applied if possible3.

The purpose of the feature “HSDPA performance enhancement – Power adaptation for HARQ retransmissions” is then to adapt the power of retransmissions to new radio conditions, in order to improve decoding probability while saving power when possible. In case of erroneous CQI decoding for the initial transmission, it also allows to recover retransmissions.

A power offset wrt initial transmission is then computed and depends on CQI variation or retransmission index. It is a linear function of the CQI difference:

Power_offset dB = (CQI1st – CQIret)*Step – Const.




Step and Const are constants to determine. “Step” is positive; it helps handling the erroneous CQI and allows consuming right power according to new conditions. “Const” illustrates the gain brought by redundancy versions recombining and should be positive; a negative value could also be set to enforce first retransmission to be decoded while consuming maybe unnecessary power.

Default values provided by studies are: Step = 0.5; Const = 3. These values may evolve if another set appears more relevant.

Note that the CQI of the first transmission corresponds to the reported one (including DeltaCqi adjustment) and not the applied one. Indeed, it is important to compensate radio condition variations so reported CQI illustrates this. Once the offset is computed, it is applied on top of the applied power of the first transmission as scheduler rules should have adapted the transport format and related power in order to keep constant the QoS.

To activate this feature, it is proposed to use the harqType parameter as well.

4 values are currently defined: MIR/PIR/CC/DR (see definition in section 3.1.1.3.4) corresponding to 1/2/3/4.

As the power adaptation is independent of the HARQ type selected, 4 new values are defined to activate or not power adaptation with any HARQ Type. The following coding is then performed:

- If harqType < 10, no power adaptation

- If harqType ≥ 10, power adaptation is activated and harqType = harqType-10

The fourth new following values are then introduced:

� MIRwithPowerAdaptation (11)

� PIRwithPowerAdaptation (12)

� CCwithPowerAdaptation (13)

� DRwithPowerAdaptation (14)

Note that ‘Step’ and ‘Const’ cannot be changed as there’s no available parameter at OMC-B. They will then be hard-coded.

Parameters Settings:

Parameter HarqType Object HsdpaConf Range & Unit [mirType, pirType, ccType, drType, MIRWithPowerAdaptation,

PIRWithPowerAdaptation, CCWithPowerAdaptation, DRWithPowerAdaptation]


Granularity BTSCell

Value DRWithPowerAdaptation




6.3.2.8 MULTI-USERS PER TTI

Once a user has been chosen to be scheduled at the next TTI, the Mac-hs scheduler checks that there is enough remaining power for the HS-SCCH. If it is not the case then it tries to schedule another user. After HS-SCCH power has been allocated, the scheduler computes the remaining power that can be used for HS-DSCH (as described in the previous section). Once a user has been scheduled, the scheduler will try to serve another user in the same TTI with the power that remains (PRemain in the following figure), if there is still a free HS-SCCH code for this TTI.

CCC

DCH margin

PRemain

DCHNod

eB

OCNS (opt.)

HS-DSCH

HS-SCCH

Figure 61: Remaining power for multi-users per TTI scheduling

6.3.3 HS-SCCH POWER CONTROL FEATURE

The aim of this feature is to adjust, according to the radio condition, the power allocated to HS-SCCH in order

• to save power for data or other UE,

• to have a good detection probability of HS-SCCH

HS-SCCH power control is not a true power control mechanism but rather a power mapping between CQI and HS-SCCH power. The power allocated for HS-SCCH is derived from the reported CQI (noted CQIreported), not from CQI computed for CQI adjustment according to BLER or power and code limitation or CQI optimization, in order to adapt the transmission power to radio conditions. This is configured in a table that gives a power offset relative to P-CPICH for each CQI such as:

PHS-SCCH = PP-CPICH + hsScchPcOffset(CQIreported)




where hsScchPcOffset is a table giving a power offset relative to P-CPICH for each CQI (see the following figure).

CQIreported hsScchPcOffset relative to PCPICH Power

1 hsScchPcOffset(1)

2 hsScchPcOffset(2)

……….

30 hsScchPcOffset(30)

Table 42: HS-SCCH power offset table according the reported CQI

Disabling the power control consists in setting all hsScchPcOffset to the same value.

The following figure summarizes the HS-SCCH power control:

CQ

I

PHS-SCCH = PP-CPICH + hsScchPcOffset(CQI Reported )

CQIReported hsScchPcOffset(CQIReported)

CQ

I

PHS-SCCH = PP-CPICH + hsScchPcOffset(CQI Reported )

CQIReported hsScchPcOffset(CQIReported)

Figure 62: HS-SCCH power control overview

Rule: Dependency between hsScchPcOffset and measure mentPowerOffset

The hsScchPcOffset parameters depend on the CQI reported by the UE to the NodeB. However the UE computes his CQI according to the measurementPowerOffset parameter which defines the reference power. Then hsScchPcOffset parameters have to be linked to a measurementPowerOffset value. If the measurementPowerOffset increases of 1dB, the hsScchPcOffset table has to be shifted of 1 unit.

6.3.4 PARAMETERS SETTINGS AND RECOMMENDATIONS

The following section gives the properties of the parameters describe previously.




Parameter dchPowerMargin Object HsdpaConf Range & Unit Integer (%)

[0 … 100] User Customer Class 3

Granularity BTSCell

Value 20

Engineering Recommendation: dchPowerMargin versus c ell load

The recommended value for dchPowerMargin is set to 20% for high cell load. At low load, 10% could be used due to smaller power fluctuation.

Parameter hsScchPcOffset Object HsdpaConf Range & Unit List[1..30]

[-28.0..28.0] dB User Customer Class 3

Granularity BTSCell

Value 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -3.0 -3.0 -5.0 -5.0 -5.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0 -8.0

Rule: hsScchPcOffset relationship with pCpichPower & MaxTxPower

For each value of the list of hsScchPcOffset , the following relationship must be verified:

HsScchPcOffset + pCpichPower ≥ maxTxPower – 35 dB

Parameter minimumPowerForHsdpa Object HsdpaCellClass Range & Unit Integer (dB)

[0 … 50] step 0.1 User Customer Class 0

Granularity FDDCell

Value Unset or 50

Engineering Recommendation: minimumPowerForHsdpa

The recommendation is that no power has to be reserved for HSDPA . Two solutions are possible:

1) minimumPowerForHsdpa = 50dB so that the minimum power reserved for HSDPA is very low (ex : PminHsdpa = PMaxCell – minimumPowerForHsdpa = 45dBm – 50dB = -5dBm = 0.3mW).

2) minimumPowerForHsdpa = unset so that no minimum power is reserved for HSDPA.

Rule: Minimum value for parameter minimumPowerForHsdpa

If the minimum value of this parameter is used in order to reserve entire power for HSDPA (which is not recommended ), there will be a conflict between power allocated to common channels and power reserved for HSDPA (see details about power reservation formula in chapter 6.3.2.2.1). Also, there will be not enough power in the cell to setup an SRB. This will forbid any HSDPA call establishments.




In order to allow HSDPA calls, following formula has to be used to compute the minimum value for this parameter:

minimumPowerForHsdpa Min = Pccc + PSRB

See [R01] for details about power reservation for CCs and SRBs.

Parameter numberOfHsPdschCodes Object HsdpaCellClass Range & Unit Integer


Granularity FDDCell

Value 5

Engineering Recommendation: numberOfHsPdschCodes

The number of HS-PDSCH codes reserved in the HSDPA cell (numberOfHsPdschCodes ) has to be chosen according to the number of HS-SCCH codes (numberOfHsScchCodes ) reserved and on the UE category. For example, if only one HS-SCCH codes (one user per TTI) is reserved and UE Category 6 or 12 (5 HS-PDSCH codes max), there is no need to reserved more than 5 HS-PDSCH codes. In a trial context, we suppose 2 HS-SCCH codes (up to 2 UE per TTI) and UE category 6 or 12 (5 HS-PDSCH codes max). So 10 HS-PDSCH codes are required.

Parameter numberOfHsScchCodes Object HsdpaCellClass Range & Unit Integer


Granularity FDDCell

Value 1

Engineering Recommendation: numberOfHsScchCodes

The number of HS-SCCH codes numberOfHsScchCodes defines the number of UE that could be scheduled during a TTI. When a UE is scheduled, the HS-SCCH channel requires up to about 10% of PA power. If n UE are scheduled during a TTI, n*10% of PA power is needed.

There is a low probability to have more than 2 users scheduled during the same TTI Moreover, the more UE are scheduled, the more HS-PDSCH codes are needed. This is the reason why the number of HS-SCCH codes is set to 2.

Parameter measurementPowerOffset Object HsdpaUserService Range & Unit Integer (0.5 dB)

[-12..26] User Customer Class 3

Granularity RNC

Value 14




Engineering Recommendation: measurementPowerOffset

measurementPowerOffset parameter defines the reference power used by the UE to compute his CQI and the maximum power that the NodeB can allocated to one UE. The value 7.0 dB allows to allocate up to about 60% of PA power (PA = 45dBm and Cpich power = 35dBm) for the HS-DSCH channel. A lower value favours the scheduling of 2 UE per TTI by limiting the power per HSDPA user. For first deployments, the probability to have 2 UE scheduled in the same TTI will be low. Then with this value, the HSDPA user throughput is not limited by power.

It is recommend to avoid setting the measurementPowerOffset to a too high value to avoid power limitation but high enough to optimize the HSDPA capacity, the following rule should be taken into account:

0.8.PA > Log2lin(pcpichPower + measurementPowerOffset )

6.4 OTHER FEATURES

6.4.1 HSDPA AND E-DCH SERVICE INDICATOR (32520)

This feature allows the mobile to display an indication when it is under HSDPA or HSDPA and HSUPA coverage: The cell capability is broadcast on SYSINFO message (SIB5) with value HSDPA/E-DCH Capable.

Thanks to this feature, the end-user can be made aware that he is within HSDPA/HSUPA coverage, and can then decide whether to use or not services that require high bandwidths.

Parameters available for this feature:

isHsxpaServiceIndicatorEnabled allows to enable/disable the feature & RNC level

Parameter isHsxpaServiceIndicatorEnabled Object FDDCell

Range & Unit False, True User Customer Class 3

Granularity RNC

Value True

hsdpaServiceIndicatorMetho d allows to enable/disable at cell level the broadcast of the HSDPA CellIndicator flag within SIB 5

Parameter hsdpaServiceIndicatorMetho d Object FDDCell

Range & Unit ON, OFF, AUTO User Customer Class 3

Granularity FDDCell

Value Auto




edchServiceIndicatorMethod allows to enable/disable at cell level the broadcast of the E-DCH CellIndicator flag within SIB 5

Parameter edchServiceIndicatorMethod Object FDDcell

Range & Unit ON, OFF, AUTO User Customer Class 3

Granularity FDDCell

Value Auto

Once the feature is activated at RNC level, three operating modes are possible for each cell indicator (HSDPA and HSUPA), all combinations between HSDPA and HSUPA being allowed:

• OFF: the ‘hsdpaServiceIndicator’ (or respectively the ‘edchServiceIndicator’ ) information is not broadcasted in SYSINFO message.

• ON: if feature is enabled at RNC level, the ‘hsdpaServiceIndicator’ (or respectively the ‘edchServiceIndicator’) information is always broadcasted on SYSINFO, with value HSDPA_CAPABLE (or respectively EDCH_CAPABLE). This information is broadcasted to the UE even if the corresponding service (HSDPA (or respectively E-DCH)) is not operational on the corresponding cell.

• AUTO, if the feature is enabled at RNC level, ‘hsdpaServiceIndicator’ (or respectively the ‘edchServiceIndicator’) information is broadcasted to the UE indicating the current state of the corresponding service: HSDPA_CAPABLE if service is operational, HSDPA_NOT_CAPABLE otherwise (or respectively EDCH_CAPABLE if service is operational, EDCH_NOT_CAPABLE otherwise)

6.4.2 HSDPA PERFORMANCE ENHANCEMENT (29819)

This feature consists in improving HSDPA performance thanks to several different sub-features quite independent from each other:

− Optimization of transport block sizes.

− Optimal redundancy version.

− Power adaptation for HARQ retransmissions.

− HS-DPCCH detection based on CQI.

− Configurable CQI adjustment according to BLER target algorithm

− Enhanced HS-DPCCH demodulation (mainly in high speed condition)

All these sub-features have already been described in the previous sections except the last one:

Enhanced algorithms for DCH demodulation on H-BBU




This feature consists in improving HS-DPCCH demodulation mainly in high speed configurations. Solutions developed for the DCH have partially been introduced on the H-BBU in UA4.2. The purpose of this item then is to include the remaining part of such enhanced algorithms.

The solution is based on delayed channel estimation technique, but a trade-off between taking into account the next slots for demodulation and limiting the delay impacts on ACK/NACK and CQI information delivery to scheduler is considered. The integrality of next slot will then not be taken into account but only the first pilot bit in specific case.

The enhanced demodulation algorithm for high speed feature is activated thanks to the bit 2 of the RxDemodulation parameter (see also section 3.3.2.3.2):

- bit 2 = 0 ⇒ OFF - enhanced demodulation for high speed UE is deactivated

- bit 2 = 1 ⇒ ON - enhanced demodulation for high speed UE is activated

The algorithm is deactivated by default. As the parameter is class 0, it then cannot be changed online.

6.5 TRANSPORT

This section summarizes the requirements on the ATM transport network, according to the customer network design. It’s mainly focus on IUB, which is per experience the most impacting interface.

6.5.1 IUB INTERFACE

6.5.1.1 IUB DEPLOYMENT CASES

Case 1: VCCs end-to-end:

STM1

E1PP7K

RNC

ATM

STM1E1 PP7K

RNC

STM1

E1PP7K

RNC

ATM

STM1

E1PP7K

RNC

ATM

STM1E1 PP7K

RNCTransport Node

Transport Node STM1

E1PP7K

RNC

ATM

STM1E1 PP7K

RNC

STM1

E1PP7K

RNC

ATM

STM1

E1PP7K

RNC

ATM

STM1E1 PP7K

RNCTransport Node

Transport Node

Figure 63: VCCs end-to-end

This is typically the case for point-to-point interfaces or for non-policed backbone. There are no VPs defined, the intermediate nodes (PoC, other ATM switches) switch iub VCCs.




Regarding the fact that traffic flows associated to UMTS service classes are mapped onto ATM VCCs, due to the evolving characteristics of UMTS traffic, bandwidth requirements of the individual VCCs are not easily predictable. Therefore, traffic shaping on the VCC level might lead to inappropriate traffic handling (e.g. delays) and non-optimal utilization of transport resources.

On the other hand, it is much easier to estimate the total (w/o splitting to each service class) traffic volume on a given interface. If the traffic flows in the backbone network are organized in VPCs, then the bandwidth requirements of a VPC can be estimated easier, with better accuracy, than those of individual VCCs.

Case 2: VP with ATM priority shaped

STM1

Shaped VPPublic ATMnetwk

E1 PP7K

RNCSTM1

Standard VPT(Policy)

STM1


E1 PP7K

RNCSTM1


STM1


E1 PP7K

RNCSTM1


Transport Node STM1


E1 PP7K

RNCSTM1


STM1


E1 PP7K

RNCSTM1


STM1


E1 PP7K

RNCSTM1


Transport Node

Figure 64: VP with ATM priority shaped

This is typically the case when the UTRAN Nodes are connected through a public ATM network. The advantages of using VP are:

• Simplifying network engineering and interface configuration rules (via managing aggregated “path” and not individual “circuits” through the backbone).

• More efficient use of “policed backbone” resources (via shaping applied to VPCs and not to individual VCCs)

• More practical in case of 3rd party agreements.

VPT is performed in a node that can manage VCCs priorities (for example in a PP7K) and facing a policed ATM backbone, hence shaping should be activated in the node facing the ATM backbone.

Case 3: VP with ATM priority, not shaped

RNCSTM1

PrivateATM netwk

E1RNC

STM1

PrivateATM netwk

E1RNC

STM1

PrivateATM netwk

E1

Figure 65: VP with ATM priority, not shaped

This is typically the case when the UTRAN Nodes are connected through a private ATM network. The advantages are similar to case 2, except that in case 3, there is no need to shape the traffic as the backbone ATM is private.




Case 4: VP shaping activated in the RNC

STM1

Shaped VPPublicATMnetwk

E1

RNC

(Basic VPT)(Policy)

STM1


E1

RNC

(Basic VPT)(Policy)

STM1


E1

RNC

(Basic VPT)(Policy)

Figure 66: VP shaping activated in the RNC

This is the case when the RNC faces directly a public ATM backbone doing policy, with a shaped VP. However the standard VPT is not supported by the RNC; RNC supports only basic VPT. With basic VPT, the VCCs priorities are not taken into account. It’s why this case is not recommended at all. In this configuration, DS queuing delay can be impacted by the presence of NDS or HSDPA traffic.

6.5.1.2 IUB BANDWIDTH

The connection of a NodeB to an RNC may be done with (1) E1 and up to (8) E1.

Before UA4.2, the R99 traffic could be supported with only one E1. With the introduction of HSDPA in UA4.2, even if HSDPA service can be launched with (1) E1 per NodeB, it’s highly recommended to deploy HSDPA with at least (2) E1 and certainly more, depending of the quality of service the operator wants to offer to the customer. The table bellow gives an idea of the necessary bandwidth to support the different category of mobiles HSDPA at peak of traffic:

HS-DSCH category Throughput at RLC level (kbps) Throughput. at ATM layer

(+30% protocol headers)

Cat 11 - 12 1 440 kbps 1 872 kbps

Cat 1 - 6 3 360 kbps 4 368 kbps

Cat 7 - 8 6 720 kbps 8 736 kbps

Cat 9 8 160 kbps 10 608 kbps

Cat 10 12 160 kbps 15 808 kbps

Table 43: Necessary throughput per HSDPA UE categor y

Table 44: Iub bandwidth per number of E1 links

# E1 1 E1

(Kbps)

2 E1

(Kbps)

3 E1

(Kbps)

4 E1

(Kbps)

5 E1

(Kbps)

6 E1

(Kbps)

7 E1

(Kbps)

8 E1

(Kbps)

IuB bandwidth

1 920 3840 5760 7680 9600 11520 13440 15360




It’s not recommended to dedicate 1 E1 for HSDPA and 1 E1 for R99 traffic, no efficiency. As soon as at least multiple E1 are required per NodeB, the IMA feature must be activated on passport and all the E1 links must be associated to an IMA link group.

+10%

signalling

&OaM

Iub Links

(E1)

Eng margin

+31% Protocol headers

HSDPA trafficat RLC layer

R99 DL trafficat RLC layer

10% signalling&OaM

+Macro Diversity (eg. 30%)

Protocol headers

+RLC BLER for PS (eg. 10%)R99+HSDPA average trafficat ATM layer

Bw = 5% (Aal5-Vcc)

+10%

signalling

&OaM

Iub Links

(E1)

Eng margin




10% signalling&OaM


Protocol headers


Bw = 5% (Aal5-Vcc)

+10%

signalling

&OaM

Iub Links

(E1)

Eng margin




10% signalling&OaM


Protocol headers


Bw = 5% (Aal5-Vcc)

Figure 67: Iub Bandwidth repartition

6.5.1.3 IMA AND/OR MULTI-PCM ON IUB

Compared to multi-PCM feature, IMA (inverse multiplexed ATM) offers an optimized way of the link bandwidth use. Multi PCM feature consists in distributing VCCs through different physical links, whereas IMA consists in distributing cells from different VCCs through different physical links. IMA is the standard 3GPP connectivity of BTS to RNC.

IMA introduces supplementary signalling traffic on the PCM. ATM cells being transmitted over a link are apportioned into frames containing 128 cells, permitting the insertion of one ICP (IMA Control protocol) cell within each frame on a physical link.

IMA as an impact on TD dimensioning for DS and NDS traffic:

• Without IMA: PCR is set to 4528 cell/s per E1

• With IMA: PCR is set to 4490 cell/s per E1.




0 1 2 3 127 0 1 2 3 127 0 1 2 3 127Cell #

IMA frame 0 IMA frame 1 IMA frame 2

0 1 2 3 127 0 1 2 3 127 0 1 2 3 127

0 1 2 3 127 0 1 2 3 127 0 1 2 3 127

Link 2

ICP ICP ICP

ICP ICP ICP

ICP ICP ICP

Link 1

Link 0

FP running IMAIn NodeB

FP running IMAIn Passport

Direction of cell flow

Example of IMA framing and ICP cell ditribution on a link group

0 1 2 3 127 0 1 2 3 127 0 1 2 3 127Cell #


0 1 2 3 127 0 1 2 3 127 0 1 2 3 127

0 1 2 3 127 0 1 2 3 127 0 1 2 3 127

Link 2

ICP ICP ICP

ICP ICP ICP

ICP ICP ICP

Link 1

Link 0




0 1 2 3 127 0 1 2 3 127 0 1 2 3 127Cell #


0 1 2 3 127 0 1 2 3 127 0 1 2 3 127

0 1 2 3 127 0 1 2 3 127 0 1 2 3 127

Link 2

ICP ICP ICP

ICP ICP ICP

ICP ICP ICP

Link 1

Link 0




0 1 2 3 127 0 1 2 3 127 0 1 2 3 127Cell # 0 1 2 3 127 0 1 2 3 127 0 1 2 3 127Cell #


0 1 2 3 127 0 1 2 3 127 0 1 2 3 127

0 1 2 3 127 0 1 2 3 127 0 1 2 3 127

Link 2

ICP ICP ICP

ICP ICP ICP

ICP ICP ICP

Link 1

Link 0




Example of IMA framing and ICP cell ditribution on a link group

Figure 68: IMA framing and ICP cell distribution on a link group

The following configurations of PCM links are available:

• Single PCM

• Multi-PCM without IMA

• Multi-PCM with IMA

• Multi-PCM + 1 IMA group - not supported in UA5.0

6.5.1.3.1 SINGLE PCM (E1/T1)

Acceptable for R99 traffic, but not recommended as soon as HSDPA traffic is available. As seen previously, HSDPA introduces bursts of traffic which is not compatible with a single E1 bandwidth.

6.5.1.3.2 MULTI-PCM (E1/T1) WITHOUT IMA

Multi-PCM feature may be used only to increase the bandwidth on IUB but do not assure any redundancy mechanism. If one of the PCM fails, all the VCCs created on this link are down and then all the services supported by these VCCs are lost.

The feature Iub bandwidth limitation does not work when DS/NDS/HSDPA physical bandwidths are separated (this is the case of multi-PCMs without IMA).

In some cases, especially when a 3rd provider is in charge of the ATM network, IMA feature may not be supported by the ATM provider. In that specific case, multi-PCM feature will be used without IMA, but in that case the customer has to be informed of the risks and limitations. As this feature is incompatible with HSDPA and Iub bandwidth limitation feature (activated by RNC), it won’t be possible to mix NodeB with IMA and NodeB without IMA on the same RNC. Alcatel-Lucent recommendation in that case is to reparent the NodeB on different RNCs:




• reparent the NodeB Multi-PCM without IMA on a specific RNC, Iub bw limitation feature disabled,

• reparent NodeB Multi-PCM with IMA on an other RNC, Iub bw limitation feature enabled

6.5.1.3.3 MULTI-PCM (E1/T1) WITH IMA

IMA feature activation is the recommendation as soon as there is more than one E1 per NodeB.

IMA ensures the transmission of single streams of ATM cells over a pool of PCM links called IMA group.

With the 32p DS1/E1 FP in the Passport, it is possible to configure a total of 8 links in an IMA link group.

RNCNodeB

Single PCM (E1/T1)

STM-1

IMA link Group

Up to 8 PCM/ NodeB

Up to 16 UP Vcc/NodeB

IUB InterfaceIUB Interface

Up to 200 NodeBs/RNC

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

VCC UP DS (x1)

VCC UP NDS (x1)

VCC CP (x1)

VCC CCP (x1 to x6)

VCC OAM (x1)

Aal2

Aal5

VCC UP HSDPA (x1)

NodeBCEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

VCC UP DS (x2)

VCC UP NDS (x2)

VCC CP (x1)

VCC CCP (x1 to x6)

VCC OAM (x1)

Aal2

Aal5

VCC UP HSPA (x2)

Multi-PCM with IMA

ATMnetwk

E1

E1

RNCNodeB

Single PCM (E1/T1)

STM-1

IMA link Group

Up to 8 PCM/ NodeB




CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

VCC UP DS (x1)

VCC UP NDS (x1)

VCC CP (x1)

VCC CCP (x1 to x6)

VCC OAM (x1)

Aal2

Aal5

VCC UP HSDPA (x1)

NodeBCEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

VCC UP DS (x2)

VCC UP NDS (x2)

VCC CP (x1)

VCC CCP (x1 to x6)

VCC OAM (x1)

Aal2

Aal5

VCC UP HSPA (x2)

Multi-PCM with IMA

ATMnetwk

RNCNodeB

Single PCM (E1/T1)

STM-1

IMA link Group

Up to 8 PCM/ NodeB




CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

VCC UP DS (x1)

VCC UP NDS (x1)

VCC CP (x1)

VCC CCP (x1 to x6)

VCC OAM (x1)

Aal2

Aal5

VCC UP HSDPA (x1)

NodeBCEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

NodeBCEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

CEM

card

VCC UP DS (x2)

VCC UP NDS (x2)

VCC CP (x1)

VCC CCP (x1 to x6)

VCC OAM (x1)

Aal2

Aal5

VCC UP HSPA (x2)

Multi-PCM with IMA

ATMnetwk

E1

E1

Figure 69: Multi-PCM with IMA

Restriction:

- If IMA is used on BTS, it groups all available PCM interfaces (in other word, on the BTS with multi-PCM, it’s not possible to define some links with IMA and some links without IMA).

- 2 IMA group configuration is not supported in UA5.0.

6.5.1.3.4 MULTI-PCM + 1 IMA GROUP

This configuration (Multi-PCM + 1 IMA Group) allows un-expensive backhauling for HSDPA traffic by splitting IUB into two parts:

• nE1s inside an IMA group (supporting HSDPA traffic)

• pE1s outside the IMA group (to support R99, Nbap and Oam traffic)




RNC

R99, Nbap, OamoverATM

nE1

IMA group

NodeB

HSDPA overlow cost backhaul

pE1

RNC


nE1

IMA group

NodeB


pE1

RNC


nE1

IMA group

NodeB


pE1

Figure 70: Multi-PCM+ 1 IMA Group

Restriction: MULTI-PCM + 1 IMA GROUP support in UA5 .0

Multi-PCM + 1 IMA Group is not supported in UA5.0. due to following depedencies:

� Iub bandwidth limitation feature on multi-PCM without IMA is unpredictable and has to be de-activated at RNC level.

� HSDPA on Multi-PCM without IMA is not supported; it only works with a single IMA or a single E1 for the whole Iub:

� Existing checks/locks mechanism in BTS OAM prevents configuring some PCMs in IMA and others in multi-PCM mode; hence it is one or the other.

6.5.1.4 ATM PRIORITY MANAGEMENT

The intermediate ATM network should be able to manage different priorities associated to ATM VCCs.

This can be managed through ATM service categories:

Traffic type Bearer mapping or signalling VCCs Serv ice Category

DS traffic Speech, CS64, Str14.4K, Str57.6K, SRB DCH, SRB CCH

rtVBR

NDS traffic I/B 64K, 128K, 384K nrtVBR

HSxPA traffic I/B on HSDPA/HSUPA UBR

Signaling CP and CCP rtVBR

OAM OAM UBR

Table 45: Traffic mapping of ATM Service Categories




6.5.1.4.1 TRANSPORT TOPOLOGY WITH ATM PRIORITY

STM1

PrivateATM ntw

E1

RNC

Transport Topology « with ATM priority »

STM1

PrivateATM ntw

E1

RNC

Transport Topology « with ATM priority »VCCs

VCC buffers

NodeB E1s

DS queuing delay

not impacted by

the presence of

NDS or HSDPA

HSDPA

NDS

DS

VCCs

VCC buffers

NodeB E1s

DS queuing delay

not impacted by

the presence of

NDS or HSDPA

HSDPA

NDS

DS

VCCs

VCC buffers

NodeB E1s

DS queuing delay

not impacted by

the presence of

NDS or HSDPA

HSDPA

NDS

DSSTM1

PrivateATM ntw

E1

RNC

Transport Topology « with ATM priority »

STM1

PrivateATM ntw

E1

RNC

Transport Topology « with ATM priority »VCCs

VCC buffers

NodeB E1s

DS queuing delay

not impacted by

the presence of

NDS or HSDPA

HSDPA

NDS

DS

VCCs

VCC buffers

NodeB E1s

DS queuing delay

not impacted by

the presence of

NDS or HSDPA

HSDPA

NDS

DS

VCCs

VCC buffers

NodeB E1s

DS queuing delay

not impacted by

the presence of

NDS or HSDPA

HSDPA

NDS

DS

Figure 71: Transport topology with ATM Priority

This is the normal behaviour and correspond to cases 1, 2 and 3 seen previously.

DS has highest ATM priority compared to NDS; idem for NDS vs. HSDPA. DS is not influenced by the presence of NDS and HSDPA. NDS is not influenced by the presence of HSDPA.

6.5.1.4.2 TRANSPORT TOPOLOGY WITHOUT ATM PRIORITY

STM1

Shaped VP

E1

RNC

(Basic VPT)( policy)

Transport Topology « without ATM priority »

PublicATM ntw

STM1

Shaped VP

E1

RNC



PublicATM ntw

RNC VP buffer

(Common for all flows)

Shaped VP

DS queuing delay

impacted by the

presence of NDS

or HSDPA

HSDPA

NDS

DS

VCCs

NodeB E1s

RNC VP buffer


Shaped VP

DS queuing delay

impacted by the

presence of NDS

or HSDPA

HSDPA

NDS

DS

VCCs

NodeB E1s

STM1

Shaped VP

E1

RNC



PublicATM ntw

STM1

Shaped VP

E1

RNC



PublicATM ntw

RNC VP buffer


Shaped VP

DS queuing delay

impacted by the

presence of NDS

or HSDPA

HSDPA

NDS

DS

VCCs

NodeB E1s

RNC VP buffer


Shaped VP

DS queuing delay

impacted by the

presence of NDS

or HSDPA

HSDPA

NDS

DS

VCCs

NodeB E1s

Figure 72: Transport topology without ATM Priority

This is the case when the RNC interface a public ATM network doing policies. In the RNC, VP shaping is activated; as the RNC supports only basic VP, all the VCCs point to the VP buffer and then the VCCs priorities are not taken into account. In this case corresponding to case 4 seen previously, DS queuing delay can be impacted by the presence of NDS or HSDPA. To prevent the risk on speech delay, the actual recommendation is to set conservative EBR values in this case. However this prevents from efficient Iub link usage and may introduce high call blocking at AAL2 CAC

Alcatel-Lucent recommendation is to add a PP7K supporting standard VPT between the RNC and the ATM network.




6.5.1.5 AAL2 REQUIRED SERVICES

Figure 73: AAL2 Connections UA4.2 vs. UA5.0

One of the main difference between UA4.2 and UA5.0, concerns the path of HSDPA UP in uplink:

• In UA4.2, the HSDPA uplink traffic is carried with the UP NDS traffic within the UP NDS Path (QoS1) whereas the HSDPA downlink traffic is carried on its own path (QoS2). Dedicated SRB associated to HSDPA is carried over the UP DS Path (QoS0)

• In UA5.0, an HSUPA leg is always associated to an HSDPA leg: a Alcatel-Lucent BTS will only report to be E-DCH capable when it is also HSDPA capable. HSUPA and HSDPA traffic are carried within the HSDPA Path (QoS2). Dedicated SRB associated to HSxPA is carried over the UP DS Path (QoS0).

There is some limitations in term of CID allocations and then HSDPA/HSUPA sessions. See “Iub transport engineering guide”, [R06] section ATM, to determine the amount of HSPA VCCs and number of sessions in the different releases.

6.5.2 IU USER TRAFFIC CONFORMANCE

For HS-DSCH (HSDPA) and E-DCH traffic (HSUPA), the RNC implements a traffic conformance mechanism on the Iu interface to ensure that the user traffic never exceeds the maximum bit rate negotiated at RAB establishment. This is only applicable in downlink/uplink.

This mechanism is optional and can be activated at RNC level (applicable to HSxPA Service).

6.5.2.1 FEATURE APPLICABLE

In UA4.2, an HSDPA RAB is allocated in the following conditions:

• 1) the UE is HSDPA capable (release 5 compatible – cat 1-12),




• 2) the primary cell supports HSDPA ,

• 3) the UE is requesting Interactive or Background Service

The HSDPA DL channel is given regardless of the MaxBitRate in the Core RAB

A R5 UE user that has a subscription in the HLR of MaxBitRate=64K or 384K or 2M will be given with the same HSDPA DL channel and will benefit of throughputs up to 1.2M ( UE cat12)

If a subscriber (whatever MaxBitRate in HLR ) inserts its SIM into a HSDPA UE , it will have access to a throughput that is only limited by the UE ( cat12=>1.4Megs, cat6=>3.4Megs)

In UA5.0, a PS-EDCH RAB is allocated if:

• 1) the UE is eligible to E-DCH (must indicate support for R6 or later release in the Access stratum indicator and E-DCH capability in UE Radio Access Capability IE). E-DCH UE categories have been defined by 3GPP according to their radio capabilities (cat 1 to 6: Spec 25.306)

• 2) the primary cell supports E-DCH,

• 3) the UE is requesting Interactive or Background Service.

Coupled with the usage of HSDPA to carry the DL traffic, HSUPA has been designed to carry only a best effort traffic (i.e. interactive/background traffic on E-DCH); in other word an Hsupa leg is always associated to an Hsdpa leg.

6.5.2.2 ALGORITHM

This capability is based on a token bucket algorithm as specified in [R11].

This algorithm is used to verify that traffic packets submitted by the Core Network to a UMTS bearer do not exceed the requested Max value. It uses the following two parameters (r and b) for the traffic contract and one variable (TBC) for the internal usage.

• r: token rate, (corresponds to the monitored Maximum bit rate).

• b: bucket size, (the upper bound of TBC, corresponds to bounded burst size).

• TBC (Token bucket counter): the number of remaining tokens at any time.




Figure 74: Traffic Conformance Algorithm

Each Time a packet of length Li arrives, the value of TBC is checked. If TBC is large enough (b ≥ Li), meaning that the packet fits into the buffer, the traffic is considered as conformant and the packet is accepted (as L1 and L2 in picture above), otherwise it is deleted (as L3).

The value of TBC increases at a rate of “r” by time unit, and does not exceed “b”. The RNC will actually updates TBC each time it receives a packet, by dT*r where dT is the difference of time between the reception of the current packet and the previous packet.

In the scope of HSxPA implementation, this algorithm is used to make sure users do not exceed the original QoS contract.

Note : the bandwidth limit used in the algorithm is actually the RAB Maximum Bitrate, bounded by a provisonable parameter MaximumTokenGenerationRate. This is useful in case the Core Network has not be configured appropriately. The bucket size b is equal to the provisionable parameter BucketBufferTime * MBR.

6.5.2.3 PARAMETERS

The following three parameters are used to activate and configure the Iu User traffic Conformance Feature:

• sourceConformanceStatus is used to activate/inhibit the Iu conformance algorithm for downlink HSDPA user data.

o Possible values:

� Off: Source conformance algorithm is not activated.




� CompDrop: non compliant flow is discarded.

Parameter sourceConformanceStatus Object SourceConformanceInformation Range & Unit Enum

{Off, CompDrop} User Customer Class 3

Granularity RNC

Value Default: Off Recommended: CompDrop if the operator wants to limit UE throughput

• maximumTokenGenerationRate is the Absolute Max threshold and is only used in the case the MaxBitRate of the Core RAB is greater than this parameter.

Parameter maximumTokenGenerationRate Object SourceConformanceInformation Range & Unit Integer (Bytes/s)

[0..2000000] User Customer Class 3

Granularity RNC

Value Default: 512000

The default value corresponds to ~4Mbits/s, meaning above UE capabilities, so no limitation occurs.

Note: If the operator wants that none user benefits of cat6 Qos (only Cat12) , it can be set to 1.4 M/s=175000bytes/s

• maximumBucketSize Is the max burst allowed by the bucket algorithm .The greater this value is, the "slower" the algorithm will reject frames.

Parameter maximumBucketSize Object SourceConformanceInformation Range & Unit Integer (Bytes)

[1..2000000] User Customer Class 3

Granularity RNC

Value Default: 250000

Engineering Recommendation: maximumBucketSize

The higher the value, the larger the burst allowed and the better performance is noticed by a UE making bursty traffic.

To limit PS 384k users, this parameters shall be set according to:

maximumBucketSize = 2 * max UE throughput * 1 sec

maximumBucketSize = 96000bytes for limiting PS384K users




6.5.2.4 FEATURE BEHAVIOUR

The feature monitors each user throughput and deletes IU SDUs that overpass threshold given Core RAB or RNC provisioned absolute threshold

When Sequence Number loss is detected, TCP layer slows down (reduces window ) so that sender throughput is decreased.

HSDPA subscribers will have access to the full UE Cat12 throughput when in HSDPA cell. If the HSDPA subscriber goes into R99 area it has PS384K R99 channel.

Provisioning to be changed: The Downlink MaxBitRate in the HLR needs increased for HSDPA subscribers to 1.4 Megs ( case cat12 and 3.4M if cat6 is allowed)

R99 subscribers keep their MaxBitRate to 384K in HLR . A R99 subscriber using a HSDPA capable UE in a HSDPA cell will have a HSDPA channel being limited to 384K throughput ( value from Core RAB)

6.5.3 IUB BANDWIDTH LIMITATION

6.5.3.1 WHY THIS FEATURE IS NEEDED?

6.5.3.1.1 BEFORE UA4.2: IUB CONGESTION IS CONTROLLED BY AAL2 CAC.

• Case of DS traffic:

the RB activity is more or less constant and predictable. Therefore EBR can be set properly and call admission control is enough to manage Iub congestion in an efficient way.

• Case of NDS traffic:

the RB activity is not constant and very unpredictable, due to the diversity of applications (ftp, streaming, web, email, etc.). Therefore it is very difficult to control Iub congestion at call admission with a deterministic cost per RB.

Iub traffic: Real vs Estimated

0

500

1000

1500

2000

2500

3000

3500

4000

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

cells

/s

0

5

10

15

20

25

30

35

RB

Blo

cked

RB Estab on current cell Blocked by Iub ECR Estimated ECR realy passed

Mostly CS traffic

ECR Estimated

Real ECR

Iub traffic: Real vs Estimated

0

500

1000

1500

2000

2500

3000

3500

4000

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

00:00

03:00

06:00

09:00

12:00

15:00

18:00

21:00

cells

/s

0

5

10

15

20

25

30

35

RB

Blo

cked

RB Estab on current cell Blocked by Iub ECR Estimated ECR realy passed

Mostly CS traffic

ECR Estimated

Real ECR

Figure 75: Estimated Cell Rate vs. Real Cell Rate ( example)




The efficient control of Iub congestion via AAL2 CAC requires to set very conservative EBR, which means a lot of call rejections and a small Iub usage.

As shown in the above figure, which corresponds to a real customer network, configuring EBRs at 100% Activity Factor for PS traffic (instead of 4 to 16% observed in this customer call profile) is creating important “false” blocking and Iub utilization is 3 times inferior to the bandwidth estimated by the RNC.

Settings aggressive EBRs provides acceptable Iub capacity but potentially huge Iub congestion: peaks of NDS traffic increase delays spent in ATM buffers. When delays become high, the DCHFPs are received late (hence are lost and BLER increases). When the congestion increases, ATM buffer are full. The loss of ATM cells causes also the loss of DCHFPs. The combination of BLER increase and delay increase causes RLC window to stall. From an end to end point of view, the increase of delays causes TCP to slow down. As a result, the end user perception is bad (small throughput) and the Iub usage not optimal

6.5.3.1.2 IN UA4.2: INTRODUCTION OF NEW HSDPA FLOW

The introduction of HSDPA increases the Iub congestion problems due to the huge throughput (up to 3.4Mbit/s at RLC) per user cat6. Also the credits allocated by the NodeB (capacity allocation) are based on the RF conditions and do not take into account Iub. If the Iub bandwidth is small compared to the RF capacity, bursts of traffic higher than Iub bandwidth can be sent even by a single user (note: 1 UE cat 6 at 3.4Mbit/s at RLC requires 2.3E1 at ATM layer, assuming 31% overhead).

Note that AAL2 CAC uses the ECR_GCAC formula based on SCR and PCR values of the VCCs traffic descriptors to estimate the Iub bandwidth.

• R99 traffic configured with service category rtVBR and nrtVBR is regulated by AAL2 CAC.

• HSDPA traffic configured with service category UBR(SCR=PCR=0) is not taken into account by AAL2 CAC; the only regulation is done on a max number of HSDPA users (configurable parameter in the RNC: HsdpaCellClass/maximumNumberOfUser)

6.5.3.1.3 IN UA5.0: INTRODUCTION OF NEW HSUPA FLOW

IUB bandwidth limitation feature acts on I/B downlink traffic only. HSUPA (Uplink traffic) is not concerned by this feature. The only regulation is done on a max number of HSUPA users, which is x-BBU dependent.




6.5.3.1.4 GOAL OF IUB BANDWIDTH LIMITATION

Iub bandwidth limitation helps to control congestion on Iub through NDS & HSDPA traffic regulation. DS traffic is not regulated by Iub bw limitation, but by CAC AAL2

Each 10ms, the algorithm takes into account the transmission of ATM cells on the physical bandwidth and the transmission of NDS and HSDPA traffic at RLC layer can be stopped during a period of time to regulate the flow of traffic.

6.5.3.2 FEATURE DESCRIPTION

A continuous monitoring of DS, NDS and HSDPA traffic in DL at FP level is done by the PMC PC. The feature works with thresholds, which represent the peak of traffic allowed on Iub:

• 2 Discard thresholds: Th1 for DS+NDS and Th2 for DS+NDS+HSDPA

o When DS+NDS reaches Th1, NDS FPs are deleted by PMC PC.

o When DS+NDS+HSDPA reaches Th2, HSDPA FPs are deleted by PMC PC.

• 2 Back Pressure thresholds: Xoff1 for NDS and Xoff2 for HSDPA (eg. Xoffi=95% Thi)

o When DS+NDS reaches Xoff1 , PMC PC ask PMC RAB to stop transmission of NDS FPs during Txoff1

o When DS+NDS+HSDPA reaches Xoff2 , PMC PC ask PMC RAB to stop transmission of HSDPA FPs during Txoff2

Th0=Sum(ECR_GCAC)

Th1Xoff1

Th2 Xoff2

10ms

Eg. 43cells for 1 E1

Eg. 4*Th0=172cells

Eg. 6*Th0=258cellsEg. 95%*Th2=245cells

Eg. 95%*Th1=163cells

time

Figure 76: discard and backpressure thresholds

DS traffic is not regulated by « Iub bandwidth limitation » (DS regulation is done by AAL2 CAC)




The algorithm works with 10ms granularity : the thresholds are expressed in amount of data (eg. ATM cells) sent in 10ms. Each 10ms, the algorithm takes into account the transmission of ATM cells on the physical bandwidth.

The regulation is done for AAL2 traffic only . The Iub bandwidth (noted « Th0 ») for AAL2 traffic is given to the RNC through the PCR&SCR parameters defined for the AAL2 VCCs in the RNC. Th0=sum(ECR_GCAC).

If we have typically 5% of AAL5 traffic (compared to AAL2) in DL, then SCR&PCR need to be set so that Th0=95%*Iub_bandwidth*10ms ; for 1E1 (4528cells/s), Th0=43cells


SCR&PCR parameters of RNC UP VCCs must be properly set to have Sum(ECR GCAC) as close as possible to 95% of the NodeB Iub bandwidth

Th2 is set as a multiple of Th0. In the system, we define a parameter « qosDt(2) »: Th2=qosDt(2)*Th0

Th1 is set as a multiple of Th0-DS_traffic. In the system, we define a parameter « qosDt(1) »: Th1=qosDt(1)*(Th0-DS_traffic) . DS_traffic is measured within a period of 1s. Therefore Th1 may change in time.

The regulation is not done for small FP sizes (less than 50bytes). This avoids the regulation of control frames (eg. Flow control)

Thanks to backpressure, the discard does not happen

The Xoffi thresholds (i=1 or 2) are set thanks to the parameters « qosBPt(i) »: Xoffi=qosBPt(i) * Thi

When Xoffi is reached, the RLC layers of each RB belonging to QoSi, stop the transmission during Txoffi. Txoffi is calculated by the system from Thi: Txoffi =ceil((Xoffi / 2)/Th0)*10ms.

During Txoff, the RLC buffer may overflow, unless the TCP window is set lower than RLC: slowing down RLC slows down the generation of TCP Ack (by UE). TCP is paced at the rate UE receives data.

Restriction:

The feature does not work when DS/NDS/HSDPA physical bandwidths are separated (this is the case of multi-PCMs without IMA)




The following picture shows an example of traffic regulation (with backpressure) for DS and HSDPA traffic (no NDS):

Th0=Sum(ECR_GCAC)

Xoff2=qosBPt(2)*qosDt(2)*Th0

qosBPt(2)=95%; qosDt(2)=6

Txoff2=30ms

DS traffic

HSDPA traffic

DS+HSDPA traffic

HSDPA traffic is stopped

HSDPA traffic is resumed

Txoff2=30ms

HSDPA traffic is stopped

10ms 20ms 30ms 40ms 50ms0ms

Figure 77: example of traffic regulation with backp ressure

6.5.3.3 CASE OF DRIFT IUR

When Iub congestion takes place on Serving Iub (blue mobile in the picture below), the traffic is regulated.

When Iub congestion takes place on Drift Iub (red mobile in the picture below), the SRNC is not informed of the congestion.

SRNC DRNC

Iub Iub

Iur

SRNCDRNC

xoff

Figure 78: feature behaviour on Iur

6.5.3.4 PARAMETERS SETTINGS AND RECOMMENDATIONS

Thresholds must be set:




• to avoid loss of data on Iub. This requires to control the max number of ATM cells sent in buffers (must be less than max buffer size). The NDS queuing delays must be also controlled to avoid DCHFP received outside TOAWS window (and therefore lost). This constraint does not exist for HSDPA.

• to control Iub jitter contribution to end to end delays (for KPI).

6.5.3.4.1 ENGINEERING RULES

Case « with ATM priority »

• Each traffic type (DS, NDS, HSDPA) is associated to a QoS: DS (QoS0), NDS (QoS1), HSDPA (QoS2). Max ATM buffer size: Xoffi represents the max amount of data waiting in the ATM buffers of QoSi, in the ATM switch doing the regulation at the NodeB bandwidth (eg: the ATM switch interfacing the NodeB E1s, or the ATM switch doing VP shaping at the NodeB Iub bandwidth). To avoid loss of ATM cells, Xoffi must be smaller than the max ATM buffer size managing QoSi .

• NDS Iub DL queuing delay: max time spent by ATM cells in buffer Qd1=10ms*[MaxCells1/(Th0-DS traffic)]=10ms*qosBPt(1)*qosDt(1). Let’s note delta_Iub the delay between 2 adjacent NodeBs. To receive DCHFPs within TOAWS, we must have: Qd1≤TOAWS-Delta_Iub, therefore: qosBPt(1)*qosDt(1) ≤(TOAWS-Delta_Iub)/10ms .

• HSDPA Iub DL queuing delay: the max time spent by ATM cells in the HSDPA buffer is equal to Qd2=max(0;10ms*[MaxCells2/(Th0- DS&NDS traffic)]). HSDPA has no delay constraint coming from HS-DSCHFP. However for end to end performance, a max Iub delay can be considered, for instance 100ms: Qd2≤100ms, hence: qosBPt(2)*qosDt(2) ≤ max(0;10*[1-DS&NDStraffic/Th0]) .

Case « without ATM priority »

• This is the case when the RNC faces directly an ATM backbone doing policing, with a shaped VP. However the standard VPT is not supported by the RNC. With basic VPT, the VCCs priorities are not taken into account.

• Max ATM buffer size: the max number of cells in the buffer (common for all flows) is equal to Xoff1+Xoff2 ≤(qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2))*Th0, and mu st be smaller than MaxBufferSize of the RNC VP .

• DS/NDS/HSDPA Iub DL queuing delay: without ATM priority, NDS and HSDPA impact DS delays. Like NDS, the max delay allowed by DS comes from the DCHFP synchronization mechanism. We must have: qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2)≤(TOAWS-Delta_Iub)/10ms.




With such settings, Iub jitter would contribute up to TOAWS (eg. 50ms) to DS end to end delay. If this additional delay is not acceptable for the end to end DS delay budget, more constraining delays can be used. For instance, if we want to have Iub jitter less than 20ms for DS, then: qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2) ≤ 2.

6.5.3.4.2 NUMERICAL EXAMPLE

Let’s give a numerical example for a NodeB with 2 IMA E1s (Th0=2*4490*95%*10ms=85cells). DS+NDS traffic=50% of Iub bandwidth =1.9Mbit/s=45cells each 10ms. TOAWS=50ms. Delta_Iub=15ms.

Case « with ATM priority »

> In our example, the NodeB is connected to the RNC via a PP7K with MSA32 card

• Delay requirements: Qd1≤TOAWS-Delta_Iub=35ms, Qd2≤100ms imposes: qosBPt(1)*qosDt(1)≤3.5 and qosBPt(2)*qosDt(2)≤5. If we use qosBPt(1)=qosBPt(2)=95%, then we can use: qosBPt(1)=3.5 and qosBPt(2)=5

• the NodeB is connected to 1 PP7K with default MSA32 buffer sizes (UBR effective buffer size=630cells). For Xoff2=95%*5*Th0, the max number of ATM cells in the PP7K HSDPA VCC buffer is equal to: 95%*5*Th0=404cells. The default MSA32 buffer size is large enough to keep CLR=0. Note however that with more than 3 E1, the default ATM buffer size of the HSDPA VCC must be increased!

Case « without ATM priority »

> The NodeB VP is shaped at the RNC (basic VPT)

• Let use qosDt(1)=3 and qosDt(2)=5. How to set BP thresholds?

• Delay requirements: Qd≤20ms imposes: qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2)≤2. We can use: qosBPt(1)=1/3 and qosBPt(2)=1/5.

• The max number of ATM cells in the IN 16pOC3 VP buffer is equal to (qosBPt(1)*qosDt(1)+qosBPt(2)+qosDt(2))*Th0=170cells. The effective VP ATM buffer size must be set higher than this value to guarantee CLR=0!

6.5.3.4.3 ATM BUFFER RECOMMENDATIONS

The complete ATM buffer recommendations can be found in the Iub TEG. following parts provide ATM buffer recommendations for 2 typical cases:

1. case where the NodeB is connected to the RNC via a PP7K with MSA32 card (case “with ATM priority”)

2. case where the RNC manages VP shaping (basic VPT; case “without ATM priority”)




Case where the NodeB is connected to the RNC via a PP7K MSA32 card

Relation between min buffer size, #E1s and Iub bw parameters:

HSDPA Buffer size ≥ #E1*43*qosBPt(2)*qosDt(2)

With the default recommended thresholds « with ATM priority » qosBPt(2)=500 and qosDt(2)=95%, this leads to:

HSDPA Buffer size ≥ #E1*204 cells

With the default HSDPA buffer size in PP7K (MSA32):

> ATTRIBUTE AtmIf Vcc Vcd Tm txQueueLimit (txQlim)=SameAsCA

> ATTRIBUTE AtmIf CA UBR txQueueLimit (txql)=1792

> By default UBR is at Discard Priority 3, this means that ATM cells received beyond ≈35% of the txQueueLimit are discarded. The effective HSDPA buffer size is therefore: 35%*1792= 630 cells

> When the number of E1 per NodeB is lower or equal to 630/204=3, no ATM cell can be lost in ATM buffer.

> With more than 3 E1, there is a risk (depending on the real HSDPA traffic) to loose ATM cells in the default HSDPA buffer size (case of MSA32)

Recommendation

Queue limit of the HSDPA VCC (case no VPT, PP7K with MSA32)

If #E1>3 (but <7): ATTRIBUTE AtmIf Vcc Vcd Tm txQueueLimit (txQlim) =2*1792.

If #E1 ≥ 7: ATTRIBUTE AtmIf Vcc Vcd Tm txQueueLimit (txQlim) = #E1*583

Case where the RNC manage VP shaping

> Relation between VPC min buffer size, #E1s and Iub bw parameters:

VPC Buffer size ≥ #E1*43*(qosBPt(1)*qosDt(1)+qosBPt(2)*qosDt(2))

> With the default recommended thresholds « without ATM priority » qosBPt(1)=300, qosDt(1)=33%, qosBPt(2)=500, qosDt(2)=20% this leads to:

VPC Buffer size ≥ #E1*86

> With the default VPC rtVBR buffer size in IN (16pOC3):

> ATTRIBUTE AtmIf Vpc Vpd Tm txQueueLimit (txQlim)=SameAsCA

> ATTRIBUTE AtmIf CA rtVBR txQueueLimit (txql)=autoconfigure

> The effective VPC buffer size (for CC3) is: 35%*88= around 31 cells, which is too small compared to the requirements.

> By setting the VPC rtVBR txQueueLimit to 4000, the corresponding buffer size is adjusted to values dictated by the PCR e.g. if PCR= #E1*4490cells/s, the effective




buffer size (for CC3) is equal to 35%*#E1*270cells=#E1*94, which fits the buffer size requirements.

Recommendation

Queue limit of the VPC (case VPT)

ATTRIBUTE AtmIf Vpc Vpd Tm txQueueLimit (txQlim)=40 00

6.5.3.4.4 PARAMETERS

Parameter iubFlowControlActivation (iubFcAct)

Object IubTransportFlowControl (Fc)

Range & Unit • disabled = 0, • discardOnly = 1, • discardAndBackPressure= 2

User Class NA

Granularity RNC

Value 2


Backpressure must be activated (iubFcAct=2)

Parameter qosDiscardThreshold qosDt(0to4)


Range & Unit 0..1000 Unit= %

User Class NA

Granularity RNC

Value qosDt(0)=qosDt(4)=0 Case « with ATM priority »: *qosDt(1)=350 *qosDt(2)=500 Case « without ATM priority »: *qosDt(1)=300 *qosDt(2)=500




Parameter qosBackPressureThreshold qosBPt(0to4)


Range & Unit 0..100 Unit= %

User Class NA

Granularity RNC

Value qosBPt(0)=qosBPt(4)=0 Case « with ATM priority »: *qosBPt(1)=qosBPt(2)=95 Case « without ATM priority »: *qosBPt(1)=1/3=33% *qosBPt(2)=1/5=20%

*Note: the recommended values are valid for the following assumptions

• TOAWS=50ms, Delta_Iub=15ms

• Qd2<100ms

• DS&NDS traffic=50% Th0

• Qd0<20ms (for the case « without ATM priority »).







8 HSXPA CAPACITY ASPECTS

8.1 CEM CAPACITY

8.1.1 PRODUCT LIMITS

The iCEM board contains 1 or 2 BBUs (according to the iCEM model). These BBUs can take different sw functions:

• D-BBU = DCH-BBU: BBU managing dedicated services (and also carrying common channels)

• H-BBU = HSDPA-BBU: BBU managing HSDPA services

• E-BBU = e-DCH-BBU: BBU managing e-DCH (HSUPA) services

This is referring mainly to H-BBU and D-BBU capacity.

D-BBU capacity will be focused only on aspects related to UL dedicated traffic related to HSDPA and common channels.

8.1.1.1 H-BBU

The CEM capacity for HSDPA is given by the H-BBU limitation in terms of:

• Maximum number of users

• Maximum number of OVSF codes

• Throughput

The capacity figures are given in the following table:

UA4.2 UA5.0

Maximum number of users 20 48

Maximum number of OVSF Codes

(limitation here given by cell)

15 SF 16 (HS-PDSCH) +

4 SF 128 (HS-SCCH)

15 SF 16 (HS-PDSCH) +

4 SF 128 (HS-SCCH)

Throughput at Mac-hs (Mbps) 10.8 10.8

Table 46: H-BBU limitations

An H-BBU can work either in “mono-cell mode” (the H-BBU is managing one cell only) or in “shared mode” (the H-BBU is managing two or three cells). The H-BBU operating mode is chosen at provisioning time.

When the H-BBU is working in “shared mode”, each cell will be granted with a fraction of the overall H-BBU capacity, as described below:




H-BBU capacity per active cell

1 active (*) cell per HBBU 2 active (*) cells per HBBU

3 active (*) cells per HBBU

Processing capacity in #codes (SF16)

15 codes for the active cell (radio cell limit)

11 codes for each active cell (HBBU limit)

7 codes for each active cell (HBBU limit)

Processing capacity in Mbit/s

14.4Mbps (at air interface) or 10.2Mbit/s (at RLC SDU) for the cell

7,2Mbps (at air interface) or 5.1 Mbit/s (at RLC SDU) for each active cell

4,8Mbps (at air interface) or 3.4 Mbit/s (at RLC SDU) for each active cell

Table 47: H-BBU capacity details

(*) – An “active cell” is a cell which contains at least 1 “HSDPA active user”. An “HSPDA active user” is a user who receives data on HS-PDSCH. A user with DPCCH and associated DCH, but who does not receive data on HS-PDSCH (“HSDPA connected user”) is not considered as an “HSDPA active user”.

When the number of active cells changes, the H-BBU processing capacity per sector is reconfigured within 1 radio TTI (2ms).

The H-BBU managing the HSDPA traffic is not handling common channels or other dedicated traffic.

Rule: H-BBU Capacity with 2 Carriers Configuration:

From UA5.0, HSDPA is supported on 2 different carriers. One H-BBU is capable to support only one carrier . Thus, additional H-BBU resources are to be foreseen for the second carrier, if HSDPA is activated on two carriers

The BBU managing the HSDPA traffic (H-BBU) is not supported on CEM alpha board.

8.1.1.1.1 PARAMETERS SETTINGS AND RECOMMENDATIONS

These are parameters that control/Limit H-BBU capacity and are used by the CAC BTS to decide if a new HSDPA call is admitted or not.

The hsdpaMaxNumberUserHbbu is used to configure the max number of HSDPA Users per H-BBU (in the limit of product capability which is 48 users/H-BBU in UA5.0)

Parameter hsdpaMaxNumberUserHbbu Object BTSEquipment Range & Unit [0..65535] User Customer Class 0

Granularity BTS

Value 0 (meaning maximum user allowed by the product)

This parameter replaces UA4.2 Manufacturer parameter hsdpaMaxNumberUser .




Engineering Recommendation: hsdpaMaxNumberUserHbbu

The recommended value for the hsdpaMaxNumberUserHbbu in UA5.0 is 0 (meaning the max capacity allowed for the product).

As the value of hsdpaMaxNumberUser in UA4.2 is 20 and hsdpaMaxNumberUserHbbu will take the same value after UA5.0 Upgrade, an additional configuration action is required for all NodeB upgraded from UA4.2 to UA5.0 to position the hsdpaMaxNumberUserHbbu value to 0.

For new sites created in UA5.0, the hsdpaMaxNumberUserHbbu will be positioned to 0 by default.

The hsdpaResourceMaxCapacity can be used to reduce the CEM resources allocated to HSDPA by 50% (commercial reasons for instance)

Parameter hsdpaResourceMaxCapacity Object BTSEquipment Range & Unit [50 or 100] User Customer Class 0

Granularity BTS

Value 100 (all resources can be used)

Engineering Recommendation: hsdpaResourceMaxCapacity

The recommended value for the hsdpaResourceMaxCapacity in UA5.0 is 100 (meaning no limitation in terms of resources to be used).

The hsdpaMaxNumberUserPerNodeB is used to limit the max number of HSDPA Users per NodeB . This parameter provides the mean to control the HSDPA user load impact on the NodeB DCH processing resources (D-BBU) due to associated UL DCH load. Thus, the accessibility of the Node-B processing resources for any DCH traffic (speech, CSD) can be ensured defining a maximal load of HSDPA users per site.

Parameter hsdpaMaxNumberUserPerNodeB Object BTSEquipment Range & Unit [0..65535] User Customer Class 0

Granularity BTS

Value 0 (no limitation)

Engineering Recommendation: hsdpaMaxNumberUserPerNodeB

The recommended value for the hsdpaMaxNumberUserPerNodeB in UA5.0 is 0 (meaning no limitation).

8.1.1.2 E-BBU

The CEM capacity for HSUPA is given by the E-BBU limitation in terms of:

• Maximum number of users

• Maximum number of codes




• Throughput

Rule: E-BBU supported Configurations:

• In UA5.0, an E-BBU can work only in “shared mode” (the E-BBU is managing all the cells of a NodeB).

• Only 1 E-BBU per NodeB is supported in UA5.0

The capacity figures are given in the following table:

UA5.0

Maximum number of users 15

Maximum number of UL Codes 3 x (2xSF4)

(2xSF4 per modem)

Throughput at Mac-e (Mbps) 2.1

Table 48: E-BBU limitations

2.1 Mbps (at Mac-e level) is a CODEC module limitation (CODEC is an iCEM hw component)

The 3 MODEMS of an E-BBU (MODEM is an iCEM hw component) are dynamically shared between the active E-DCH cells of the NodeB

BBUCodec

ModemCRCP

Modem ModemCRCP CRCP

BBUCodec

ModemCRCP

Modem ModemCRCP CRCP

Figure 79: BBU HW high level structure

A modem can manage a maximum of 5 E-DCH UE in parallel. The global limitation of 15 UE per E-BBU is driven by the maximum load for each specific MODEM.

The choice of UL Codes is depending on the number of connection already establish on a MODEM.

One E-DCH UE can be handled on only one MODEM at a given time.

E-DCH performance of an UE is limited to the performance/load of the associated MODEM (max 2xSF4)




Rule: E-BBU Resources allocation at call admission

For a Bi/Tri active cells configuration, with a max of 15 UE per E-BBU freely shared per cell (with a minimum of one user per cell), the following Modem/SF allocation rules are applied:

• The less loaded Modem is chosen at each E-DCH call setup. One MODEM is never directly associated to a specific cell.

• The choice of SF is depending on the number of connection already establish on the MODEM. The table mentioned above is used.

The E-BBU managing the HSUPA traffic is not handling cell common channels or other dedicated traffic.

The BBU managing the HSUPA traffic (E-BBU) is not supported on CEM alpha board.

8.1.1.2.1 PARAMETERS SETTINGS AND RECOMMENDATIONS

These are parameters that control/Limit E-BBU capacity and are used by the CAC BTS to decide if a new HSUPA call is admitted or not.

The edchMaxNumberUserEbbu is used to configure the max number of HSUPA Users per E-BBU (in the limit of product capability which is 15 users/E-BBU in UA5.0)

Parameter edchMaxNumberUserEbbu Object BTSEquipment Range & Unit [0..65535] User Customer Class 0

Granularity BTS

Value 0 (meaning maximum user allowed by the product)

Engineering Recommendation: edchMaxNumberUserEbbu

The recommended value for the edchMaxNumberUserEbbu in UA5.0 is 0 (meaning the max capacity allowed for the product).

The edchMaxNumberUserNodeB is used to limit the max number of HSUPA Users per NodeB ..

Parameter edchMaxNumberUserNodeB Object BTSEquipment Range & Unit [0..65535] User Customer Class 0

Granularity BTS

Value 0 (no limitation)

Engineering Recommendation: edchMaxNumberUserNodeB

The recommended value for the edchMaxNumberUserNodeB in UA5.0 is 0 (meaning no limitation).




8.1.1.3 D-BBU

The D-BBU function is handling the Common Channels associated to each available cell (including HSxPA Cells) and all dedicated traffic (DCH) including the UL traffic associated to the DL HSDPA traffic.

D-BBU capacity figures are provided in the PLM Document CEM Capacity see [R10].

The management and configuration of D-BBU resources is detailed in BTS Product Engineering Information (PEI), see [R17].

8.2 RNC CAPACITY

In UA5.0, no major capacity impact is foreseen due to HSxPA introduction.

For RNC capacity figures in UA5.0 please refer to RNC capacity Roadmap [R15]




9 PRODUCT RECOMMENDATIONS

Features listed below have impacts on Alcatel-Lucent UTRAN products with regards to HSDPA & HSUPA feature:

Feature Id Feature description

27930 HSDPA Service

27932 HSDPA Step 1

27940 H-BBU Pool Across Sectors

27941 Node-B Module Operation For HSDPA

29801 48-user HSDPA iCEM BBU Capacity

29840 Commercial HSUPA Introduction

32039 HSDPA 2-carrier NodeB configuration

9.1 HSXPA COMPATIBILITY WITH UTRAN NETWORK ELEMENTS

9.1.1 RNC

HSDPA & HSUPA are supported on RNC 1500 platform for all UA5.0 supported Market Models (RNC 1000 is no more supported in UA5.0)




9.1.2 HSDPA & E-DCH SUPPORT OVER NODEB

9.1.2.1 HSXPA SUPPORT ACCORDING TO NODEB CABINET

NodeB HSDPA support

E-DCH support

Comments

d2U Yes Yes

Pico Yes No

Micro Yes No

- Micro & Pico BTS remain in UA04.2.7 SW load, without UA05.0 feature set (Multiple RAB PS I/B + PS I/B over HSDPA, SF4 DL not supported) - UA05 feature set + E-DCH support planned in UA05.1

Mono BTS 1020 (*) Yes No Only 1 slot for CEM : 2 BBUs max (D-BBU and H-BBU)

Street BTS 1120(*) Yes Yes

Compact Indoor 6010 (UMTS 1900 only)

Yes Yes

dCompact (dBTS 6100)

Yes Yes

rCompact (rBTS 6100)

Yes Yes May be specific SW stream for rBTS in UA05.0 (no decision today)

Indoor 600 (*) Yes Yes

Indoor 700 (*) Yes Yes

Macro Indoor (Indoor 2)

Yes Yes

Outdoor 1 (*) Yes Yes

Macro Outdoor (Outdoor 2)

Yes Yes

RRH 2100 20W Yes Yes E-DCH on RRH supported from UA05.0 DR5

(*) Products in grey are "Manufacture Discontinue", meaning that they are not orderable but they are still on field and supported.

Table 50: HSxPA support over NodeB in UA05.0

E-DCH support was on restriction for RRH in UA05.0 DR4 load. This restriction is removed in DR5 load.




Restriction: NodeB not supporting HSUPA in UA05.0

In UA05.0 DR5 load, HSUPA is not supported in the f ollowing cabinets :

- Mono BTS 1020 - Micro NodeB - Pico NodeB - All UMTS NodeB managing optical repeaters

Except Mono BTS 1020, all other products are Hardware ready to support HSUPA. The support on, Pico and Micro product is planned in UA05.1 post DR5 load, see dedicated FPG for more details.

9.1.2.2 HSXPA SUPPORT ACCORDING TO RF CONFIGURATION S

The following configurations are supported in UA05.0 :

• HSDPA & E-DCH are supported over all RF configurations of NodeB except OTSR / OTBR

• HSDPA can be activated over up to 6 sectors x 2 carriers (according to cabinet capabilities, see below) on a cell per cell basis.

• E-DCH can be activated over up to 3 sectors x 1 carrier (belonging to a same Local Cell Group)

• HSDPA is mandatory on cells where E-DCH is activated.

• HSxPA can be activated on dedicated carrier or on shared carrier with R99

HSDPA and E-DCH are supported over all frequency bands.

Restriction: Configurations not supporting HSDPA in UA05.0

In UA05.0 load, HSxPA is not supported in the follo wing configurations :

- OTSR - OTBR




Restriction: BTS support of HSDPA over 2 carriers

UMTS BTS 1020 doesn't support 2 carriers configurat ion.

In Compact Indoor BTS 6010 and Street BTS 6020, HSD PA over 2 carriers is not available if 2 TRM are used.

In UMTS BTS 6010 / 6020 cabinets, only 3 slots are available for CEM/TRM boards and at least 2 iCEM boards (3 BBU) are requested to manage HSDPA over 2 carriers

Restriction: HSUPA support on only 1 carrier

In UA05.0 load, HSUPA is supported on 1 carrier onl y.

Restriction: HSUPA support on more than 3 sectors

For configurations with more than 3 sectors, HSUPA can be activated only on a cluster of 3 sectors.

In UA05.0 load, only 1 E-BBU per NodeB is supported.

Restriction: BTS 6010 & 6020 support of HSUPA

In Compact Indoor BTS 6010 and Street BTS 6020, HSU PA is not available if 2 TRM are used.

In UMTS BTS 6010 / 6020 cabinets, only 3 slots are available for CEM/TRM boards and at least 2 iCEM boards (3 BBU) are requested to manage HSUPA




9.2 HSXPA COMPATIBILITY WITH MODULES

9.2.1 RNC

There are no additional requirements on RNC modules in relation with HSPDA & HSUPA. As such, UA05.0 and products related requirements apply.

9.2.2 BTS

This chapter applies to all UMTS BTS except Micro BTS 1120 and Pico BTS 1010.

The architecture of this BTS is different from other UMTS BTS. In particular, no CEM module is used.

9.2.2.1 HSXPA READY MODULES

CEM module from Digital Rack is the one impacted by HSxPA from a system perspective, as such all other modules from both Digital (CCM, TRM and GPSAM), Radio Racks (DDM, MCPA…) and Antenna System are compatible with HSDPA.

Within the CEM portfolio, compatibility matrix is the following with regards to HSxPA:

• CEM alpha = NOT compatible (*)

• i-Module iCEM 64 and 128 = Compatible

• i-Module version 2 iCEM-2 64 and iCEM-2 128 = Compatible

(*) Warning: This does not imply that a CEM alpha cannot be plugged into a BTS with HSxPA activated, it can indeed not manage HSxPA resources but can still process dedicated and/or common channels, please refer to next sections.

9.2.2.2 BTS MODULES MIXITY

From BTS product point of view, as long the minimal configuration requirements described into the section below are met, there are no specific constraints in terms of mixity in relation with HSxPA.

From operational point of view, some precautions are to be taken when planning to mix different types of CEM boards (iCEM and CEM alpha) in the same NodeB:

The E-BBU & H-BBU functions can be mapped only on iCEM. The rest of NodeB CEM resources will be used to perform D-BBU function (see details about these BBU functions in section 9.3.2.1). If CEM alpha is used in the site and iCEM resources exceed the need in terms of H-BBU and E-BBU, the D-BBU function will be handled on both CEM alpha and remaining iCEM resources.




Engineering Recommendation: Mix of iCEM & CEM alpha

It is recommended to avoid mixing CEM alpha and iCEM boards to perform D-BBU function in a NodeB.

• In case of 1 Carrier BTS configuration, the E-BBU and H-BBU will be mapped on iCEM. The D-BBU is recommended to be mapped either on CEM alpha or on iCEM (to be planed during Network Design / Dimensioning exercise)

• For 2 Carriers BTS configuration it is recommended to avoid the usage of CEM alpha

Indeed, when mixing both types of CEM boards to perform D-BBU function, the following impacts are foreseen:

- In case of 1 Carrier BTS configuration:

• CEM load monitoring through CEMUsed counter becomes less reliable because there is only one counter to monitor 2 different load models (already the case in UA4.2) - In case of 2 Carriers BTS configuration:

• CEM alpha is not supporting the new UA5.0 functionality “Dynamic management of iCEM resources” (see details in [R17]).This can lead to capacity issues in case of unbalanced load between frequencies (already the case in UA4.2).

9.2.2.3 BTS MINIMAL CONFIGURATION FOR HSDPA

In order to activate HSDPA on a BTS configuration, CEM MINIMAL requirements are:

• One CEM alpha, or one iCEM (-1 / -2) 64, or one half of iCEM (-1 / -2) 128 for NON HSDPA resources.

AND

• One iCEM (-1 / -2) 64 or one half of iCEM (-1 / -2) 128 for HSDPA.

These requirements are for HSDPA activation on 1 frequency over up to 3 cells.

9.2.2.4 BTS MINIMAL CONFIGURATION FOR HSUPA

In order to activate HSUPA on a BTS configuration, CEM MINIMAL requirements are:

• One CEM alpha, or one iCEM (-1 / -2) 64, or one half of iCEM (-1 / -2) 128 for NON HSDPA resources.

AND

• Two iCEM (-1 / -2) 64 or one iCEM (-1 / -2) 128 for HSDPA + HSUPA (HSUPA activation requires that HSDPA is also activated).

These requirements are for HSDPA + HSUPA activation on 1 frequency over up to 3 cells.




9.3 HSXPA SYSTEM IMPACT

Reminder: HSDPA and HSUPA are OPTIONAL feature.

9.3.1 RNC FUNCTIONS

9.3.1.1 RNC RESSOURCES MANAGEMENT

Please refer to Transport section for associated Iub Congestion Management and CAC AAL2 related mechanisms description.

9.3.2 BTS FUNCTIONS

BTS functions mainly impacted from a system perspective by HSxPA have been located into the BBU unit of CEM boards.

9.3.2.1 CEM AND BBU ROLES

Depending on CEM board, as illustrated below, one or two BBUs are available. Furthermore a system constraint is that one BBU can ONLY process EITHER common and/or dedicated services OR HSxPA services. As a matter of facts, BTS BBUs have been specialized into:

• D-BBU = DCH-BBU: BBU managing dedicated services (but can also carry common channels)

• H-BBU = HSDPA-BBU: BBU managing HSDPA services

• E-BBU = e-DCH-BBU: BBU managing e-DCH (HSUPA) services




This leads to the possible BBU distribution below:

CEM type BBU1 BBU2 Comments

CEM alpha D-BBU D-BBU Only D-BBU for CEMα

D-BBU

H-BBU iCEM (-1 or -2) 64

E-BBU

D-BBU D-BBU

D-BBU H-BBU

H-BBU D-BBU

H-BBU H-BBU

D-BBU E-BBU

E-BBU D-BBU

E-BBU H-BBU

iCEM (-1 or -2) 128

H-BBU E-BBU

Each BBU of iCEM can be allocated independently with D-BBU, H-BBU or E-BBU (except 2 E-BBU)

Table 51: BBU functions distribution

Restriction: 1 E-BBU per NodeB

In UA05.0 load, only one E-BBU can be configured in a NodeB.

In the table above ( Table 51), 2 E-BBUs configured on a iCEM128 is not availabl e in UA05.0

9.3.2.2 BTS HSXPA SYSTEM LIMITS

HSDPA is supported by Alcatel-Lucent BTS within the following system limits:

• A given HSDPA Cell is managed by one single H-BBU and cannot be split between several H-BBU

• From one to three cells per H-BBU. All the cells must belong to same LocalCellGroup .

HSUPA is supported by Alcatel-Lucent BTS within the following system limits:

• ONLY one single carrier with HSUPA, and HSDPA must be activated on this carrier

• Only 1 E-BBU maximum per nodeB

• Up to 3 HSUPA Cells per BTS




9.3.2.3 BBU ALLOCATION

D-BBU, H-BBU and E-BBU allocation is performed within a BTS shelf:

• At CCM Startup

• At CEM Startup if no allocation was already achieved for this CEM at CCM Startup. This covers cases where the CEM was not enabled (HW failure, Board locked) or not inserted (later CEM plug-in) at CCM Startup time.

• After a CEM loss, the remaining CEM that do not manage any traffic can be re-allocated

D-BBU, H-BBU and E-BBU roles allocation algorithm relies on minimumR99RessourceRequired, hsdpaResourceActivatio n, hsdpaResourceId, edchResourceActivation and edch ResourceId parameters of BTSEquipment /BTSCell objects.

The allocation algorithms (at CCM startup or after a CEM loss) are described here-after.

Criteria for a successful allocation are:

• Number of D-BBU in accordance to parameter minimumR99RessourceRequired .

• Number of H-BBU to be allocated = Number of different hsdpaResourceId among BTS Cells with their hsdpaResourceActivation set to TRUE and within BTS HSDPA System limits.

• Number of E-BBU to be allocated = Number of different edchResourceId among BTS Cells with their edchResourceActivation set to TRUE and within BTS HSUPA System limits.




The Allocation Algorithm at CCM Startup has been improved since UA04.2 :

- E-BBU allocation (for HSUPA resources)

- Support of 6 sectors configurations

It is composed by 4 steps :

1. Allocation of each LocalCellGroup (LCG) into a pool of LCG (up to 2 pools).

A LocalCellGroup (LCG) is a group of cells for which SrHO is available (currently 3 sectors x 1 frequency).

An (i)CEM can manage a maximum of 2 LCG.

This step of algorithm groups the LCG into pools : - For BTS with 1 or 2 LCG : only 1 pool grouping all LCG (cases STSR1, STSR2, STSR1+1, 6 sectors with only 1 frequency). - For BTS with 3 or 4 LCG (6 sectors with 2 frequencies cases) : 2 pools are used. The LCG are grouped by antenna cluster.

Softer HO

Softer HO

Soft HO

Soft HO

Softer HO

Softer HO

BTS

Antenna cluster 02 carriers F1 + F26 cells


LocalCellGroup 0 (LCG0) :3 cells of F1 on Antenna cluster 0


Pool 1 = LCG0 + LCG2




Softer HO

Softer HO

Soft HO

Soft HO

Softer HO

Softer HO

BTSBTS









Figure 89: 6 sectors x 1 carrier : BBUs allocation on iCEM 128

2. Computation of required BBU for each pool of LCG.

- Number of D-BBU to be allocated = [(sum over each LCG of the pool of the parameter minimumR99RessourceRequired ) + 32] / 64

- Number of H-BBU to be allocated = Number of different hsdpaResourceId among BTS Cells with their hsdpaResourceActivation set to TRUE and within BTS HSDPA System limits.

- Number of E-BBU to be allocated = Number of different edchResourceId among BTS Cells with their edchResourceActivation set to TRUE and within BTS HSUPA System limits.




3. Allocation of each CEM to a pool.

- The CEM alpha are allocated to the pools that manage at least 1 LCG without RRH

- For each (i)CEM, the algorithm allocates the board to the pool that has the more BBU remaining requested. Example : for the allocation of the 2nd iCEM, if the pool 1 needs to have 2 additional BBU and the pool 2 needs 3 additional BBU, this board will be allocated to pool 2.

4. Allocation of service (D-, H- or E-) for each BBU inside a pool.

Inside each pool :

- CEM alpha are set to D-BBU if there is no RRH or optical repeater.

- BBU(s) of iCEM are allocated to R99 (D-) first, then to HSDPA (H-) and last to HSUPA (E-)

- When all required resources (according to step2) are allocated, all remaining BBU(s) are D-BBU.

At last, H- and E- BBU are allocated to each hsdpaResourceId and edchResourceId

The minimum number of iCEM is given by the followin g formula

((N1 Div 2) + (N2 Div 2)) iCEM128 + ((N1 modulo 2) + (N2 modulo 2)) iCEM64

With:

• N1 = minimum number of required BBU for Antenna Cluster 0 : 1 D-BBU + 1 E-BBU (if HSUPA) + 1 or 2 H-BBU (depends on number of carriers with HSDPA on antenna cluster 0)

• N2 = minimum number of required BBU for Antenna Cluster 1 : 1 D-BBU + 1 E-BBU (if HSUPA) + 1 or 2 H-BBU (depends on number of carriers with HSDPA on antenna cluster 1)

Engineering Recommendation: BBU allocation

The datafill of resources required for each service must be done carefully according to the resources available inside the BTS.

In particular, it is critical that minimumR99RessourceRequired and number of hsdpaResourceId + edchResourceId reflect the capability of the BTS.




In case of CEMs enabled after CCM Startup (plug-in or unlocked board), then algorithm above applies starting at Step 3.




9.3.2.4 BTS RELIABILITY

In UA05, a new algorithm is introduced to manage the failure cases of CEM, ensuring service recovery when it is possible, without impacting remaining traffic.

The Pre-emption Algorithm is started in following c ases :

- CEM failure for more than 3 minutes. - Set administrative state of the BOARD CEM to LOCKED. - Plug out of the CEM. - An iCEM becomes enabled AND there was a board that has been de-allocated. This case can happen when, for instance: iCEM<a> is reset and iCEM<b> is plugged-out. When the iCEM<a> restarts, it may be reallocated.

This algorithm applies only to iCEM, as CEM alpha are configured only with D-BBU.

- After a CEM (alpha or iCEM) failure inside a pool, the algorithm checks all iCEM of the pool.

- If the entire iCEM (the 2 BBU in case of iCEM128) does not manage any traffic, the board is pre-empted.

- All the pre-empted iCEM are re-allocated according to Step 4 of initial allocation algorithm.

Other BTS redundancy mechanisms remain unchanged.

9.3.2.5 MCPA POWER

Alcatel-Lucent BTS offers one MCPA per Sector (carrying one or two carriers). As a matter of fact Power made available by a given PA is shared by Cells associated to this sector. So HSDPA resources will also require and use some of this available power, which reduces power available for R99. Only exception is when 1+1 configuration is used, then a MCPA is dedicated to each frequency layer within a sector.

9.4 HSXPA AND UTRAN INTERFACES

9.4.1 RADIO INTERFACE

UA05.0 supports following UMTS frequency bands : I (2100), II (1900), V (850) and VIII (900).




Alcatel-Lucent RNC in UA05.0 supports 2 frequency bands.

Alcatel-Lucent NodeB in UA05.0 supports only 1 frequency band. No Dual band configuration are supported.

Rule: Max Number of HSDPA Carriers:

In UA05.0 loads, HSDPA is supported on up to two carriers.

Rule: Max Number of HSUPA Carriers:

In UA05.0 loads, HSUPA is supported on only one carrier.

9.4.2 IUB

9.4.2.1 PHYSICAL INTERFACES IMPACTS

In UA05.0, HSDPA is supported over all available options exception made of “Multi-PCM” configuration. In case several PCM are used, IMA must be used.

9.4.2.2 ATM LAYER

From ATM connectivity point of view HSxPA impact is as follows on a plane basis:

• Control Plane: One CCP is mandatory for CEM having at least one D-BBU. In case all BBUs of a given CEM are H-BBU or E-BBU, there is no need to configure one CCP for this CEM since CCP is only used for dedicated NBAP procedures. Nevertheless, the recommendation is to configure 1 CCP per CEM board (see explanations below).

Warning: In case more CCP than CEM board carring D-BBU have been configured, they will appear as DISABLED at the W-N MS level. Reason for this is that all UEs have a DCH part, even if they are configured in HSDPA or E-DCH. H-BBU only manages the HSDPA channels and E-BBU only manages the E-DCH channels, while the DCH part is managed by a D-BBU. So the context of the communication is located on a CEM handling the DCH part of the UE (the HSDPA may be de-configured for instance while the DCH always remain). As a matter of fact all NBAP messages intended to that UE are then sent to the VCC of the CEM managing the DCH, so no VCC needs to be allocated to a CEM that is configured without D-BBUs.




Engineering Recommendation: CCP configuration

It is recommended to configure as many CCP as CEM b oards in the NodeB.

If some CEM boards have no D-BBU, some CCP will be disabled without service impact.

The rationale for this recommendation is :

- BBU function allocation is performed automatically by an algorithm (see dedicated §) and the result is not easily predictable.

- The algorithm result may be different if it is triggered first when a CEM is added without NodeB restart then after a NodeB restart.

- In case of CEM failure, remaining CEM may be pre-empted and the BBU functions changed to recover resources.

In all these cases, a CEM that didn't host D-BBU may be reconfigured and then host a D-BBU.

• User Plane: HSxPA requires at least per BTS one dedicated ATM AAL2 VCC for User Plane associated to Qos 2.

Please refer to [R06] for further details.

9.4.3 IU-CS

Not Applicable to HSDPA context.

9.4.4 IU-PS

HSDPA does not imply new requirements from a Product and Architecture perspectives.

9.4.5 IU-R

HSDPA is not supported over IuR interfaces.

9.4.6 IU-PC

Not Applicable to HSDPA context.







10 ABBREVIATIONS AND DEFINITIONS

10.1 ABBREVIATIONS

AICH Acquisition Indicator Channel

AM Acknowledged Mode

AS Access Stratum

BCC Base Color Code

BCH Broadcast Channel

BSIC Base Station Identity Code

CAC Call Admission Control

CBR Constant Bit Rate

CC Call Control

CEM Channel Element Module

CN Core Network

CoS Class Of service

CP Passport: Control Processor

CPCS Common Part Convergence Sublayer

CPICH Common Pilot CHannel

CS Circuit Switched

DDM Dual Duplexer Module

DL Downlink

DPCCH Dedicated Physical Control Channel

DPDCH Dedicated Physical Data Channel

DTAP Direct Transfer Application Part

FP 3GPP: Frame Protocol

FP Passport: Function Processor

GMM GPRS Mobility Management

HCS Hierarchical Cell Structure

HSDPA High Speed Data Packet Access

HHO Hard HandOver

IE Information Element

IMEI International Mobile Equipment Identification

IMSI International Mobile Subscriber Identification

RNC-AN RNC Access Node

RNC-CN RNC Control Node

RNC-IN RNC Interface Node

ITP Initial Transmit Power




ITU International Telecommunication Union

LA Location Area

LAC Location Area Code

MBG Minimum Bandwidth Guaranteed

MCPA Multi-Carrier Power Amplifier (same as PA)

MIB Management Information Base

MIB Master Information Block

MM Mobility Management

MMI Man-Machine Interface

MO Mobile Originated

MT Mobile Terminated

NAS Non Access Stratum

NCC Network Color Code

NE Network Element

NSAP Network Service Access Point

OCAN Offline Configuration of Access Network, Alcatel-Lucent’s tool for UTRAN configuration

OVSF Orthogonal Variable Spreading Factor

PA Power Amplifier (same as MCPA)

P-CCPCH Primary Common Control Physical Channel

PCI Peripheral Component Interconnect bus

PCPCH Physical Common Packet Channel

P-CPICH Primary Common Pilot Channel

PICH Paging Indicator Channel

PLMN Public Land Mobile Network

PRACH Physical Random Access Channel

PS Packet Switched

P-SCH Primary Synchronization Channel

QoS Quality of Service

RA Registration Area

RAB Radio Access Bearer

RACH Random Access Channel

RANAP Radio Access Network Application Part

RAT Radio Access Technology

RB Radio Bearer

RL Radio Link

RLC Radio Link Control

RMS Root Mean Square

RNC Radio Network Controller




RNS One RNC + Its associated Node-B

RRC Radio Resource Control

RRM Radio Resource Management

RSCP Received Signal Code Power

RSSI Received Signal Strength Indicator

SAR Segmentation and Re-assembly

SCCP Signalling Connection Control Part

S-CCPCH Secondary Common Control Physical Channel

S-CPICH Secondary Common Pilot Channel

SCR Sustainable Cell Rate

SDH Synchronous Digital Hierarchy

SF Spreading Factor

SFN System Frame Number

SHO Soft HandOff

SIB System Information Block

SM Session Management

SRB Signalling Radio Bearer

SS7 Signalling System 7

S-SCH Secondary Synchronization Channel

SSCS Service Specific Convergence Sublayer

SSD Source Statistic Description

TFC Transport Format Combination

TFCS Transport Format Combination Set

TM Transparent Mode

TRB Traffic Radio Bearer

TrCH Transport CHannel

TRM TRansceiver Module

TS Time Slot

TTI Transmission Time Interval

UBR Unspecified Bit Rate

UE User Equipment

UL Uplink

UM Unacknowledged Mode

URA UTRAN Registration Area

UTRAN Universal Terrestrial Radio Access Network

VBR Variable Bit Rate

VBR-nrt Variable Bit Rate - non real time

VBR-rt Variable Bit Rate - real time

VC Virtual Channel




VCC Virtual Channel Connection

VCI Virtual Channel Identifier

VP Virtual Path

VPI Virtual Path Identifier

WG Wireless Gateway

10.2 DEFINITIONS




11 APPENDIXES

11.1 APPENDIX A: OPTIMIZED CQI MAPPING TABLES WITH 336 MAC-D PDU SIZE

The following CQI mapping tables will be used with 336 bits MAC-d PDU size when hsdpaUeCategoryTransportBlockOptimization is set to TRUE for corresponding UE category.

For UE cat 9 and 6, some changes are proposed in brackets in case the parameter hsdpaMaxUeCategoryCapabilityActivation is set to TRUE for corresponding UE category.

Updates are highlighted in red.

CQI Transport block size Nb of HS-PDSCH Modulation Reference Power adjustment

Nb of PDUs (336 bits)

Index

1 365 1 QPSK +4 1 20

2 365 1 QPSK +3 1 20

3 365 1 QPSK +2 1 20

4 365 1 QPSK +1 1 20

5 365 1 QPSK 0 1 20

6 365 1 QPSK -1 1 20

7 365 1 QPSK -2 1 20

8 699 2 QPSK 0 2 48

9 699 2 QPSK -1 2 48

10 1036 3 QPSK 0 3 70

11 1380 3 QPSK 0 4 86

12 1711 3 QPSK 0 5 98

13 2046 4 QPSK 0 6 108

14 2404 4 QPSK 0 7 117

15 3090 5 QPSK 0 9 131

16 3440 5 16-QAM 0 10 137

17 4115 5 16-QAM 0 12 147

18 4420 5 16-QAM 0 13 151

19 5101 5 16-QAM 0 15 159

20 5782 5 16-QAM 0 17 166

21 6438 5 16-QAM 0 19 172

22 7168 5 16-QAM 0 21 178

23 7168 5 16-QAM -1 21 178

24 7168 5 16-QAM -2 21 178




25 7168 5 16-QAM -3 21 178

26 7168 5 16-QAM -4 21 178

27 7168 5 16-QAM -5 21 178

28 7168 5 16-QAM -6 21 178

29 7168 5 16-QAM -7 21 178

30 7168 5 16-QAM -8 21 178

Table 52: CQI mapping table update for UE cat 1 to 6

CQI Transport block size

Nb of HS-PDSCH

Modulation Reference Power adjustment


Index

1 365 1 QPSK +4 1 20

2 365 1 QPSK +3 1 20

3 365 1 QPSK +2 1 20

4 365 1 QPSK +1 1 20

5 365 1 QPSK 0 1 20

6 365 1 QPSK -1 1 20

7 365 1 QPSK -2 1 20

8 699 2 QPSK 0 2 48

9 699 2 QPSK -1 2 48

10 1036 3 QPSK 0 3 70

11 1380 3 QPSK 0 4 86

12 1711 3 QPSK 0 5 98

13 2046 4 QPSK 0 6 108

14 2404 4 QPSK 0 7 117

15 3090 5 QPSK 0 9 131

16 3440 5 16-QAM 0 10 137

17 4115 5 16-QAM 0 12 147

18 4420 5 16-QAM 0 13 151

19 5101 5 16-QAM 0 15 159

20 5782 5 16-QAM 0 17 166

21 6438 5 16-QAM 0 19 172

22 7168 5 16-QAM 0 21 178

23 9546 7 16-QAM 0 28 194

24 11216 8 16-QAM 0 33 203

25 14155 10 16-QAM 0 42 216

26 14155 10 16-QAM -1 42 216

27 14155 10 16-QAM -2 42 216

28 14155 10 16-QAM -3 42 216

29 14155 10 16-QAM -4 42 216




30 14155 10 16-QAM -5 42 216

Table 53: CQI mapping table update for UE cat 7 and 8


Nb of HS-PDSCH



Index

1 365 1 QPSK +4 1 20

2 365 1 QPSK +3 1 20

3 365 1 QPSK +2 1 20

4 365 1 QPSK +1 1 20

5 365 1 QPSK 0 1 20

6 365 1 QPSK -1 1 20

7 365 1 QPSK -2 1 20

8 699 2 QPSK 0 2 48

9 699 2 QPSK -1 2 48

10 1036 3 QPSK 0 3 70

11 1380 3 QPSK 0 4 86

12 1711 3 QPSK 0 5 98

13 2046 4 QPSK 0 6 108

14 2404 4 QPSK 0 7 117

15 3090 5 QPSK 0 9 131

16 3440 5 16-QAM 0 10 137

17 4115 5 16-QAM 0 12 147

18 4420 5 16-QAM 0 13 151

19 5101 5 16-QAM 0 15 159

20 5782 5 16-QAM 0 17 166

21 6438 5 16-QAM 0 19 172

22 7168 5 16-QAM 0 21 178

23 9546 7 16-QAM 0 28 194

24 11216 8 16-QAM 0 33 203

25 14155 10 16-QAM 0 42 216

26 17237 12 16-QAM 0 51 227

27 17237 [20251] 12

[15]

16-QAM

[16-QAM]

-1

[0]

51

[60]

227

[236]

28 17237 [20251] 12

[15]

16-QAM

[16-QAM]

-2

[-1]

51

[60]

227 [236]

29 17237 [20251] 12

[15]

16-QAM

[16-QAM]

-3

[-2]

51

[60]

227

[236]

30 17237 [20251] 12

[15]

16-QAM

[16-QAM]

-4

[-3]

51

[60]

227

[236]






Nb of HS-PDSCH



Index

1 365 1 QPSK +4 1 20

2 365 1 QPSK +3 1 20

3 365 1 QPSK +2 1 20

4 365 1 QPSK +1 1 20

5 365 1 QPSK 0 1 20

6 365 1 QPSK -1 1 20

7 365 1 QPSK -2 1 20

8 699 2 QPSK 0 2 48

9 699 2 QPSK -1 2 48

10 1036 3 QPSK 0 3 70

11 1380 3 QPSK 0 4 86

12 1711 3 QPSK 0 5 98

13 2046 4 QPSK 0 6 108

14 2404 4 QPSK 0 7 117

15 3090 5 QPSK 0 9 131

16 3440 5 16-QAM 0 10 137

17 4115 5 16-QAM 0 12 147

18 4420 5 16-QAM 0 13 151

19 5101 5 16-QAM 0 15 159

20 5782 5 16-QAM 0 17 166

21 6438 5 16-QAM 0 19 172

22 7168 5 16-QAM 0 21 178

23 9546 7 16-QAM 0 28 194

24 11216 8 16-QAM 0 33 203

25 14155 10 16-QAM 0 42 216

26 17237 12 16-QAM 0 51 216

27 21754 15 16-QAM 0 64 240

i 21754 15 16-QAM -1 64 240 28

x 23370 15 16-QAM 0 69 244

i 21754 15 16-QAM -2 64 240 29

x 23792 15 16-QAM 0 70 245

i 21754 15 16-QAM -3 64 240 30

x 23792 15 16-QAM -1 70 245



Nb of HS-PDSCH



Index




1 365 1 QPSK +4 1 20

2 365 1 QPSK +3 1 20

3 365 1 QPSK +2 1 20

4 365 1 QPSK +1 1 20

5 365 1 QPSK 0 1 20

6 365 1 QPSK -1 1 20

7 365 1 QPSK -2 1 20

8 699 2 QPSK 0 2 48

9 699 2 QPSK -1 2 48

10 1036 3 QPSK 0 3 70

11 1380 3 QPSK 0 4 86

12 1711 3 QPSK 0 5 98

13 2046 4 QPSK 0 6 108

14 2404 4 QPSK 0 7 117

15 3090 5 QPSK 0 9 131

16 3440 5 QPSK 0 10 137

17 3440 5 QPSK -1 10 137

18 3440 5 QPSK -2 10 137

19 3440 5 QPSK -3 10 137

20 3440 5 QPSK -4 10 137

21 3440 5 QPSK -5 10 137

22 3440 5 QPSK -6 10 137

23 3440 5 QPSK -7 10 137

24 3440 5 QPSK -8 10 137

25 3440 5 QPSK -9 10 137

26 3440 5 QPSK -10 10 137

27 3440 5 QPSK -11 10 137

28 3440 5 QPSK -12 10 137

29 3440 5 QPSK -13 10 137

30 3440 5 QPSK -14 10 137

Table 56: CQI mapping table update for UE cat 11 an d 12




11.2 APPENDIX B: OPTIMIZED CQI MAPPING TABLES WITH 656 MAC-D PDU SIZE

The following CQI mapping tables will be used with 656 bits MAC-d PDU size when hsdpaUeCategoryTransportBlockOptimization is set to TRUE for corresponding UE category.


Updates are highlighted in red.


Nb of HS-PDSCH



Index

1 686 2 QPSK +7 1 47

2 686 2 QPSK +6 1 47

3 686 2 QPSK +5 1 47

4 686 2 QPSK +4 1 47

5 686 2 QPSK +3 1 47

6 686 2 QPSK +2 1 47

7 686 2 QPSK +1 1 47

8 686 2 QPSK 0 1 47

9 686 2 QPSK -1 1 47

10 686 2 QPSK -2 1 47

11 1356 3 QPSK 0 2 85

12 1356 3 QPSK -1 2 85

13 2010 4 QPSK 0 3 107

14 2677 4 QPSK 0 4 123

15 3319 5 QPSK 0 5 135

16 3319 5 QPSK -1 5 135

17 3970 5 16-QAM 0 6 145

18 4664 5 16-QAM 0 7 154

19 5287 5 16-QAM 0 8 161

20 5287 5 16-QAM -1 8 161

21 5993 5 16-QAM 0 9 168

22 6673 5 16-QAM 0

10 174

23 6673

[7298]

5 16-QAM -1

[0]

10

[11]

174

[179]

24 6673

[7298]

5 16-QAM -2

[-1]

10

[11]

174

[179]




25 6673

[7298]

5 16-QAM -3

[-2]

10

[11]

174

[179]

26 6673

[7298]

5 16-QAM -4

[-3]

10

[11]

174

[179]

27 6673

[7298]

5 16-QAM -5

[-4]

10

[11]

174

[179]

28 6673

[7298]

5 16-QAM -6

[-5]

10

[11]

174

[179]

29 6673

[7298]

5 16-QAM -7

[-6]

10

[11]

174

[179]

30 6673

[7298]

5 16-QAM -8

[-7]

10

[11]

174

[179]

Table 57: CQI mapping table update for UE cat 1 to 6


Nb of HS-PDSCH



Index

1 686 2 QPSK +7 1 47

2 686 2 QPSK +6 1 47

3 686 2 QPSK +5 1 47

4 686 2 QPSK +4 1 47

5 686 2 QPSK +3 1 47

6 686 2 QPSK +2 1 47

7 686 2 QPSK +1 1 47

8 686 2 QPSK 0 1 47

9 686 2 QPSK -1 1 47

10 686 2 QPSK -2 1 47

11 1356 3 QPSK 0 2 85

12 1356 3 QPSK -1 2 85

13 2010 4 QPSK 0 3 107

14 2677 4 QPSK 0 4 123

15 3319 5 QPSK 0 5 135

16 3319 5 QPSK -1 5 135

17 3970 5 16-QAM 0 6 145

18 4664 5 16-QAM 0 7 154

19 5287 5 16-QAM 0 8 161

20 5287 5 16-QAM -1 8 161

21 5993 5 16-QAM 0 9 168

22 6673 5 16-QAM 0 10 174

23 9210 7 16-QAM 0 14 192

24 11216 8 16-QAM 0 17 203

25 13904 10 16-QAM 0 21 215




26 13904 10 16-QAM -1

21 215

27 13904 10 16-QAM -2

21 215

28 13904 10 16-QAM -3

21 215

29 13904 10 16-QAM -4 21 215

30 13904 10 16-QAM -5 21 215



Nb of HS-PDSCH



Index

1 686 2 QPSK +7 1 47

2 686 2 QPSK +6 1 47

3 686 2 QPSK +5 1 47

4 686 2 QPSK +4 1 47

5 686 2 QPSK +3 1 47

6 686 2 QPSK +2 1 47

7 686 2 QPSK +1 1 47

8 686 2 QPSK 0 1 47

9 686 2 QPSK -1 1 47

10 686 2 QPSK -2 1 47

11 1356 3 QPSK 0 2 85

12 1356 3 QPSK -1 2 85

13 2010 4 QPSK 0 3 107

14 2677 4 QPSK 0 4 123

15 3319 5 QPSK 0 5 135

16 3319 5 QPSK -1 5 135

17 3970 5 16-QAM 0 6 145

18 4664 5 16-QAM 0 7 154

19 5287 5 16-QAM 0 8 161

20 5287 5 16-QAM -1 8 161

21 5993 5 16-QAM 0 9 168

22 6673 5 16-QAM 0 10 174

23 9210 7 16-QAM 0 14 192

24 11216 8 16-QAM 0 17 203

25 13904 10 16-QAM 0 21 215

26 17237 12 16-QAM 0 26 227

27 17237 [20251] 12

[15]

16-QAM

[16-QAM]

-1

[0]

26

[30]

227

[236]




28 17237 [20251] 12

[15]

16-QAM

[16-QAM]

-2

[-1]

26

[30]

227 [236]

29 17237 [20251] 12

[15]

16-QAM

[16-QAM]

-3

[-2]

26

[30]

227 [236]

30 17237 [20251] 12

[15]

16-QAM

[16-QAM]

-4

[-3]

26

[30]

227 [236]



Nb of HS-PDSCH



Index

1 686 2 QPSK +7 1 47

2 686 2 QPSK +6 1 47

3 686 2 QPSK +5 1 47

4 686 2 QPSK +4 1 47

5 686 2 QPSK +3 1 47

6 686 2 QPSK +2 1 47

7 686 2 QPSK +1 1 47

8 686 2 QPSK 0 1 47

9 686 2 QPSK -1 1 47

10 686 2 QPSK -2 1 47

11 1356 3 QPSK 0 2 85

12 1356 3 QPSK -1 2 85

13 2010 4 QPSK 0 3 107

14 2677 4 QPSK 0 4 123

15 3319 5 QPSK 0 5 135

16 3319 5 QPSK -1 5 135

17 3970 5 16-QAM 0 6 145

18 4664 5 16-QAM 0 7 154

19 5287 5 16-QAM 0 8 161

20 5287 5 16-QAM -1 8 161

21 5993 5 16-QAM 0 9 168

22 6673 5 16-QAM 0 10 174

23 9210 7 16-QAM 0 14 192

24 11216 8 16-QAM 0 17 203

25 13904 10 16-QAM 0 21 215

26 17237 12 16-QAM 0 26 227

27 21754 15 16-QAM 0 33 240

i 21754 15 16-QAM -1 33 240 28

x 23370 15 16-QAM 0 35 244

29 i 21754 15 16-QAM -2 33 240




x 24222 15 16-QAM 0 36 246

i 21754 15 16-QAM -3 33 240 30

x 25558

[27952]

15

[15]

16-QAM

[16-QAM]

0

[+1]

38

[42]

249

[254]



Nb of HS-PDSCH



Index

1 686 2 QPSK +7 1 47

2 686 2 QPSK +6 1 47

3 686 2 QPSK +5 1 47

4 686 2 QPSK +4 1 47

5 686 2 QPSK +3 1 47

6 686 2 QPSK +2 1 47

7 686 2 QPSK +1 1 47

8 686 2 QPSK 0 1 47

9 686 2 QPSK -1 1 47

10 686 2 QPSK -2 1 47

11 1356 3 QPSK 0 2 85

12 1356 3 QPSK -1 2 85

13 2010 4 QPSK 0 3 107

14 2677 4 QPSK 0 4 123

15 3319 5 QPSK 0 5 135

16 3319 5 QPSK -1 5 135

17 3319 5 QPSK -2 5 135

18 3319 5 QPSK -3 5 135

19 3319 5 QPSK -4 5 135

20 3319 5 QPSK -5 5 135

21 3319 5 QPSK -6 5 135

22 3319 5 QPSK -7 5 135

23 3319 5 QPSK -8 5 135

24 3319 5 QPSK -9 5 135

25 3319 5 QPSK -10 5 135

26 3319 5 QPSK -11 5 135

27 3319 5 QPSK -12 5 135

28 3319 5 QPSK -13 5 135

29 3319 5 QPSK -14 5 135

30 3319 5 QPSK -15 5 135

Table 61: CQI mapping table update for UE cat 11 an d 12




11.3 APPENDIX C: CQI MAPPING TABLES FOR UE CAT 7, 8 , 9 AND 10 WITH 336 MAC-D PDU SIZE

The following CQI mapping tables will be used by default.

For UE cat 9, some changes are proposed in brackets in case the parameter hsdpaMaxUeCategoryCapabilityActivation is set to TRUE for corresponding UE category.

For UE cat 10, different configurations are proposed for iCEM (i) or xCEM (x) for some CQIs.


Nb of HS-PDSCH



Index

1 377 1 QPSK +4 1 21 2 377 1 QPSK +3 1 21 3 377 1 QPSK +2 1 21 4 377 1 QPSK +1 1 21 5 377 1 QPSK 0 1 21 6 377 1 QPSK -1 1 21 7 377 1 QPSK -2 1 21 8 792 2 QPSK 0 2 55 9 792 2 QPSK -1 2 55 10 1262 3 QPSK 0 3 81 11 1483 3 QPSK 0 4 90 12 1742 3 QPSK 0 5 99 13 2279 4 QPSK 0 6 114 14 2583 4 QPSK 0 7 121 15 3319 5 QPSK 0 9 135 16 3565 5 16-QAM 0 10 139 17 4189 5 16-QAM 0 12 148 18 4664 5 16-QAM 0 13 154 19 5287 5 16-QAM 0 15 161 20 5887 5 16-QAM 0 17 167 21 6554 5 16-QAM 0 19 173 22 7168 5 16-QAM 0 21 178 23 9719 7 16-QAM 0 28 195 24 11418 8 16-QAM 0 33 204 25 14411 10 16-QAM 0 42 217 26 14411 10 16-QAM -1 42 217 27 14411 10 16-QAM -2 42 217 28 14411 10 16-QAM -3 42 217 29 14411 10 16-QAM -4 42 217 30 14411 10 16-QAM -5 42 217


CQI Transport

block size Nb of HS-PDSCH



Index

1 377 1 QPSK +4 1 21 2 377 1 QPSK +3 1 21 3 377 1 QPSK +2 1 21 4 377 1 QPSK +1 1 21 5 377 1 QPSK 0 1 21




6 377 1 QPSK -1 1 21 7 377 1 QPSK -2 1 21 8 792 2 QPSK 0 2 55 9 792 2 QPSK -1 2 55 10 1262 3 QPSK 0 3 81 11 1483 3 QPSK 0 4 90 12 1742 3 QPSK 0 5 99 13 2279 4 QPSK 0 6 114 14 2583 4 QPSK 0 7 121 15 3319 5 QPSK 0 9 135 16 3565 5 16-QAM 0 10 139 17 4189 5 16-QAM 0 12 148 18 4664 5 16-QAM 0 13 154 19 5287 5 16-QAM 0 15 161 20 5887 5 16-QAM 0 17 167 21 6554 5 16-QAM 0 19 173 22 7168 5 16-QAM 0 21 178 23 9719 7 16-QAM 0 28 195 24 11418 8 16-QAM 0 33 204 25 14411 10 16-QAM 0 42 217 26 17237 12 16-QAM 0 51 227 27 17237

[20251] 12 [15]

16-QAM [16-QAM]

-1 [0]

51 [60]

227 [236]

28 17237 [20251]

12 [15]

16-QAM [16-QAM]

-2 [-1]

51 [60]

227 [236]

29 17237 [20251]

12 [15]

16-QAM [16-QAM]

-3 [-2]

51 [60]

227 [236]

30 17237 [20251]

12 [15]

16-QAM [16-QAM]

-4 [-3]

51 [60]

227 [236]


CQI Transport




Index

1 377 1 QPSK +4 1 21 2 377 1 QPSK +3 1 21 3 377 1 QPSK +2 1 21 4 377 1 QPSK +1 1 21 5 377 1 QPSK 0 1 21 6 377 1 QPSK -1 1 21 7 377 1 QPSK -2 1 21 8 792 2 QPSK 0 2 55 9 792 2 QPSK -1 2 55 10 1262 3 QPSK 0 3 81 11 1483 3 QPSK 0 4 90 12 1742 3 QPSK 0 5 99 13 2279 4 QPSK 0 6 114 14 2583 4 QPSK 0 7 121 15 3319 5 QPSK 0 9 135 16 3565 5 16-QAM 0 10 139 17 4189 5 16-QAM 0 12 148 18 4664 5 16-QAM 0 13 154 19 5287 5 16-QAM 0 15 161 20 5887 5 16-QAM 0 17 167 21 6554 5 16-QAM 0 19 173 22 7168 5 16-QAM 0 21 178 23 9719 7 16-QAM 0 28 195




24 11418 8 16-QAM 0 33 204 25 14411 10 16-QAM 0 42 217 26 17237 12 16-QAM 0 51 227 27 21754 15 16-QAM 0 64 240 28 i 21754 15 16-QAM -1 64 240 x 23370 15 16-QAM 0 69 244 29 i 21754 15 16-QAM -2 64 240 x 23792 15 16-QAM 0 70 245 30 i 21754 15 16-QAM -3 64 240 x 23792 15 16-QAM -1 70 245


11.4 APPENDIX D: CQI MAPPING TABLES FOR UE CAT 7, 8 , 9 AND 10 WITH 656 MAC-D PDU SIZE

The following CQI mapping tables will be used by default.


For UE cat 10, different configurations are also proposed for iCEM (i) or xCEM (x) for some CQIs.


Nb of HS-PDSCH



Index

1 792 2 QPSK +7 1 55 2 792 2 QPSK +6 1 55 3 792 2 QPSK +5 1 55 4 792 2 QPSK +4 1 55 5 792 2 QPSK +3 1 55 6 792 2 QPSK +2 1 55 7 792 2 QPSK +1 1 55 8 792 2 QPSK 0 1 55 9 792 3 QPSK -1 1 55 10 792 3 QPSK -2 1 55 11 1483 3 QPSK 0 2 90 12 1483 3 QPSK -1 2 90 13 2279 4 QPSK 0 3 114 14 2279 4 QPSK -1 3 114 15 3319 5 QPSK 0 5 135 16 3319 5 QPSK -1 5 135 17 4189 5 16-QAM 0 6 148 18 4664 5 16-QAM 0 7 154 19 5287 5 16-QAM 0 8 161 20 5287 5 16-QAM -1 8 161 21 6554 5 16-QAM 0 9 173 22 7168 5 16-QAM 0 10 178 23 9719 7 16-QAM 0 14 195 24 11418 8 16-QAM 0 17 204 25 14411 10 16-QAM 0 21 217 26 14411 10 16-QAM -1 21 217 27 14411 10 16-QAM -2 21 217




28 14411 10 16-QAM -3 21 217 29 14411 10 16-QAM -4 21 217 30 14411 10 16-QAM -5 21 217


CQI Transport




Index

1 792 2 QPSK +7 1 55 2 792 2 QPSK +6 1 55 3 792 2 QPSK +5 1 55 4 792 2 QPSK +4 1 55 5 792 2 QPSK +3 1 55 6 792 2 QPSK +2 1 55 7 792 2 QPSK +1 1 55 8 792 2 QPSK 0 1 55 9 792 3 QPSK -1 1 55 10 792 3 QPSK -2 1 55 11 1483 3 QPSK 0 2 90 12 1483 3 QPSK -1 2 90 13 2279 4 QPSK 0 3 114 14 2279 4 QPSK -1 3 114 15 3319 5 QPSK 0 5 135 16 3319 5 QPSK -1 5 135 17 4189 5 16-QAM 0 6 148 18 4664 5 16-QAM 0 7 154 19 5287 5 16-QAM 0 8 161 20 5287 5 16-QAM -1 8 161 21 6554 5 16-QAM 0 9 173 22 7168 5 16-QAM 0 10 178 23 9719 7 16-QAM 0 14 195 24 11418 8 16-QAM 0 17 204 25 14411 10 16-QAM 0 21 217 26 17237 12 16-QAM 0 26 227 27 17237

[20251] 12 [15]

16-QAM [16-QAM]

-1 [0]

26 [30]

227 [236]

28 17237 [20251]

12 [15]

16-QAM [16-QAM]

-2 [-1]

26 [30]

227 [236]

29 17237 [20251]

12 [15]

16-QAM [16-QAM]

-3 [-2]

26 [30]

227 [236]

30 17237 [20251]

12 [15]

16-QAM [16-QAM]

-4 [-3]

26 [30]

227 [236]


CQI Transport




Index

1 792 2 QPSK +7 1 55 2 792 2 QPSK +6 1 55 3 792 2 QPSK +5 1 55 4 792 2 QPSK +4 1 55 5 792 2 QPSK +3 1 55 6 792 2 QPSK +2 1 55 7 792 2 QPSK +1 1 55 8 792 2 QPSK 0 1 55 9 792 3 QPSK -1 1 55 10 792 3 QPSK -2 1 55




11 1483 3 QPSK 0 2 90 12 1483 3 QPSK -1 2 90 13 2279 4 QPSK 0 3 114 14 2279 4 QPSK -1 3 114 15 3319 5 QPSK 0 5 135 16 3319 5 QPSK -1 5 135 17 4189 5 16-QAM 0 6 148 18 4664 5 16-QAM 0 7 154 19 5287 5 16-QAM 0 8 161 20 5287 5 16-QAM -1 8 161 21 6554 5 16-QAM 0 9 173 22 7168 5 16-QAM 0 10 178 23 9719 7 16-QAM 0 14 195 24 11418 8 16-QAM 0 17 204 25 14411 10 16-QAM 0 21 217 26 17237 12 16-QAM 0 26 227 27 21754 15 16-QAM 0 33 240

i 21754 15 16-QAM -1 33 240 28 x 23370 15 16-QAM 0 35 244

i 21754 15 16-QAM -2 33 240 29 x 24222 15 16-QAM 0 36 246

i 21754 15 16-QAM -3 33 240 30 x 25558

[27952] 15 [15]

16-QAM [16-QAM]

0 [+1]

38 [42]

249 [254]





END OF DOCUMENT

Documents

HSxPA Engineering Guide UA5.0 v02.09