83984%2DMIMO for WCDMA FN Preliminary V02%2E01

1

83984- MIMO for W-CDMA Functional Note

Document number: UMT/BTS/DD/028488 Document issue: 02.01 / EN Document status: Preliminary Date: 09/08/2010

Copyright 2010 Alcatel-Lucent, All Rights Reserved 2

3

4

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

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

83984- MIMO for WCDMA FN

UMT/BTS/DD/028488 02.01 / EN Preliminary 09/08/2010 /171

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

PUBLICATION HISTORY 15

09/08/2010 16

Issue 02.01 / EN, Preliminary 17

Section 1 modified concerning configurations with Twin RRH 18

Update according to FRS issue 01.09 and FTS issue 01.08 19

(Values for VAM coefficients are changed) 20

Close open issues related to Layer1/PQ3 21

19/02/2010 22

Issue 01.04 / EN, Preliminary 23

Update with review comments 24 25

20/11/2009 26

Issue 01.03 / EN, Draft 27

Updated with S-CPICH and VAM impacts 28

06/11/2009 29


Initial version: iBTS Architecture team. 31

Takes into account contributions for MIMO aspects only. S-CPICH and VAM not 32 included. 33

List of contributors: 34

ROBIEUX Christian; SAINTOT Patrice; DAGORN Delphine; PIERRARD Arnaud; 35 UNNIKRISHNAN Brijesh, LECUYER Jean-Luc 36

06/08/2009 37


Initial version: iBTS Architecture team. 39

Created from MIMO pre-study“IBTS MIMO functional note” UMT/BTS/DD/025882 ed 40 01.01 05/01/2009 41

42




CONTENTS 43

1 INTRODUCTION............................................................................................................................9 44

1.1 OBJECT....................................................................................................................................9 45

1.2 FRS ........................................................................................................................................9 46

1.3 SCOPE OF THIS DOCUMENT .......................................................................................................9 47

1.4 AUDIENCE FOR THIS DOCUMENT ................................................................................................9 48

1.5 MIMO CONFIGURATIONS ........................................................................................................10 49

1.6 INTEGRATION PHASES & DEPENDENCIES .................................................................................12 50

2 RELATED DOCUMENTS .................................. ..........................................................................13 51

2.1 APPLICABLE DOCUMENTS ........................................................................................................13 52

2.2 REFERENCE DOCUMENTS........................................................................................................13 53

3 FUNCTION OVERVIEW ..............................................................................................................15 54

3.1 MIMO PRINCIPLE....................................................................................................................15 55

3.2 VIRTUAL ANTENNA MAPPING (VAM) ........................................................................................17 56

3.3 COMPLIANCE MATRIX..............................................................................................................18 57

3.4 DEPLOYMENT OF MIMO IN UTRAN SYSTEM ..............................................................................20 58

3.5 CHOICE OF 2 WAYS RECEIVE DIVERSITY RATHER THAN 4 WAYS ..................................................20 59

4 FUNCTIONAL DESCRIPTION ............................. .......................................................................22 60

4.1 NBAP....................................................................................................................................22 61

4.1.1 NBAP new or modified parameters...............................................................................23 62 4.1.1.1 MIMO Capability (9.2.1.118)..................................................................................... 23 63 4.1.1.2 MIMO Power Offset For S-CPICH Capability (9.2.2.118) ........................................ 23 64 4.1.1.3 SixtyfourQAM DL and MIMO Combined Capability (9.2.1.121) ............................... 23 65 4.1.1.4 MIMO Activation Indicator (9.2.1.119)...................................................................... 24 66 4.1.1.5 MIMO Mode Indicator (9.2.1.120) ............................................................................ 24 67 4.1.1.6 MIMO N/M Ratio (9.2.2.96) ...................................................................................... 24 68 4.1.1.7 HARQ Memory Partitioning (9.2.1.102).................................................................... 24 69 4.1.1.8 MIMO Pilot Configuration (9.2.2.73)......................................................................... 25 70 4.1.1.9 MIMO Pilot Configuration Extension (9.2.2.120) ...................................................... 26 71 4.1.1.10 Power Offset For Secondary CPICH for MIMO (9.2.2.119) ..................................... 26 72 4.1.1.11 Precoding Weight Set Restriction (9.2.2.124) .......................................................... 26 73 4.1.1.12 Tx Diversity on DL Control Channel by MIMO UE capability (9.2.2.121)................. 27 74 4.1.2 Impacts on NBAP procedures.......................................................................................27 75 4.1.2.1 Audit Response ........................................................................................................ 27 76 4.1.2.2 Resource Status Indication....................................................................................... 27 77 4.1.2.3 Cell Setup ................................................................................................................. 28 78 4.1.2.4 Cell Reconfiguration ................................................................................................. 28 79 4.1.2.5 Radio Link Setup ...................................................................................................... 28 80 4.1.2.6 Radio Link Reconfiguration Prepare ........................................................................ 29 81 4.1.2.7 Radio Link Addition................................................................................................... 30 82




4.1.2.8 S-CPICH Power Management ................................................................................. 30 83 4.1.2.9 Impacts on MIMO calls when cell MIMO capability is lost........................................ 31 84

4.2 DELAYS IN MIMO PATHS .........................................................................................................32 85

4.2.1 Delay adjustment principle ............................................................................................32 86 4.2.2 Delay adjustment mechanism.......................................................................................32 87

4.3 SUPPORTED CONFIGURATIONS................................................................................................33 88

4.3.1 MIMO solution with distributed BTS sector with Paired RRH (Not a commercial 89 configuration)................................................................................................................................35 90 4.3.2 MIMO solution with distributed BTS sector with Twin RRH (preliminary) .....................37 91 4.3.3 MIMO on TRDU.............................................................................................................39 92 4.3.4 STRS2-M on iBTS with adjacent frequencies (Not requested for the 1st commercial 93 delivery) 40 94 4.3.5 STRS2-M on iBTS with non adjacent frequencies (not supported) ..............................41 95 4.3.6 STRS3-M on iBTS (not supported) ...............................................................................42 96

4.4 ASUMPTIONS AND RESTRICTIONS ............................................................................................42 97

4.5 USES CASES...........................................................................................................................43 98

4.5.1 MIMO Cell Activation/De-activation...............................................................................44 99 4.5.2 MIMO Cell Setup...........................................................................................................45 100 4.5.3 R99/HSPA Cell Setup ...................................................................................................46 101 4.5.4 MIMO Cell Reconfiguration (S-CPICH Power Offset)...................................................47 102 4.5.5 MIMO parameters online modification ..........................................................................48 103 4.5.6 MIMO Cell Delete..........................................................................................................49 104 4.5.7 Full RL Setup with MIMO HSDPA (RL-Setup Success case)......................................50 105 4.5.8 MIMO HSDPA Setup (RL-Setup CCM CallP Failure case) ..........................................51 106 4.5.9 R99 to MIMO HSDPA Setup (RL-Reconf-Prepare Success case)...............................52 107 4.5.10 R99 to MIMO HSDPA Setup (RL-Reconf-Commit / Cancel Success cases) ...............53 108 4.5.11 R99 to MIMO HSDPA Setup (RL-Reconf-Prepare CCM CallP Failure case)...............54 109 4.5.12 Serving HS-DSCH Modification from MIMO to non MIMO ...........................................55 110 4.5.13 Serving HS-DSCH Modification from non MIMO to MIMO ...........................................56 111 4.5.14 MIMO HSDPA Removal (RL Delete case)....................................................................57 112 4.5.15 MIMO HSDPA Removal (MAC-d Flow Delete case) ....................................................58 113 4.5.16 PA Failure (MIMO cell) ..................................................................................................59 114 4.5.17 PA Recovery (MIMO Cell).............................................................................................60 115 4.5.18 PA Failure (R99 cell) .....................................................................................................61 116 4.5.19 PA Recovery (R99 Cell) ................................................................................................62 117 4.5.20 Internal S-CPICH Power offset Reconfiguration (successful case) ..............................63 118 4.5.21 Internal S-CPICH power offset Reconfiguration (failure case) .....................................64 119 4.5.22 Internal S-CPICH power offset Reconfiguration (lost of MIMO capability) ...................65 120 4.5.23 MIMO Cell Setup (Failure case)...................................................................................66 121

4.6 FUNCTION DISTRIBUTION .........................................................................................................67 122

4.6.1 CCM OAM.....................................................................................................................67 123 4.6.1.1 Parameter Check...................................................................................................... 67 124 4.6.1.2 HW Configuration Validation .................................................................................... 68 125 4.6.1.3 NBAP interface and procedure impacts ................................................................... 68 126 4.6.1.4 SBBLINK routing map .............................................................................................. 70 127 4.6.1.5 TRM / PA defense .................................................................................................... 73 128 4.6.1.6 RRH/ TRDU defense ................................................................................................ 74 129 4.6.1.7 Capacity Licensing ................................................................................................... 75 130

4.6.1.7.1 additionalRadioPerSector..................................................................................... 75 131 4.6.1.7.2 PA Power/ RRH Power......................................................................................... 75 132

4.6.1.8 get DD: getRadioPowerInfo...................................................................................... 76 133 4.6.1.9 CCM Call Processing – CCM OAM Interaction ........................................................ 76 134 4.6.1.10 eCEM SLOAM – CCM OAM Interaction................................................................... 76 135 4.6.1.11 Timing alignment ...................................................................................................... 76 136




4.6.1.12 Counters ................................................................................................................... 77 137 4.6.2 CCM CallP.....................................................................................................................78 138 4.6.2.1 CCM CallP – OAM Interaction.................................................................................. 78 139 4.6.2.2 NBAP Manager......................................................................................................... 78 140 4.6.2.3 S-CPICH power offset reconfiguration procedure .................................................... 80 141 4.6.2.4 Transmit Carrier Power Measurement ..................................................................... 81 142 4.6.2.5 Load Balancing impacts ........................................................................................... 82 143 4.6.3 eCEM/Modem Controller...............................................................................................83 144 4.6.3.1 SLOAM ..................................................................................................................... 83 145 4.6.3.2 OAL........................................................................................................................... 83 146 4.6.3.3 NBAPR ..................................................................................................................... 83 147 4.6.3.4 BRM.......................................................................................................................... 84 148 4.6.3.5 CCC.......................................................................................................................... 85 149 4.6.3.6 DCC.......................................................................................................................... 85 150 4.6.4 eCEM/CE Controller......................................................................................................86 151 4.6.4.1 Control Plane............................................................................................................ 86 152

4.6.4.1.1 UCU Manager....................................................................................................... 86 153 4.6.4.1.2 PSB BBR .............................................................................................................. 87 154 4.6.4.1.3 HSDPA BBR......................................................................................................... 88 155 4.6.4.1.4 HSD BBR.............................................................................................................. 88 156 4.6.4.1.5 BBR Monitor ......................................................................................................... 90 157

4.6.4.2 User Plane................................................................................................................ 90 158 4.6.4.2.1 HSDPA Scheduler ................................................................................................ 90 159 4.6.4.2.2 UeContext............................................................................................................. 92 160 4.6.4.2.3 HS-SCCH and HS-PDSCH code selection .......................................................... 98 161 4.6.4.2.4 Look up tables ...................................................................................................... 99 162

4.6.4.3 FRAMING PROTOCOL............................................................................................ 99 163 4.6.4.4 Power Reservation ................................................................................................. 100 164

4.6.4.4.1 Power Reservation with MIMO for HS I/B Configured with minBR (fair sharing)100 165 4.6.4.4.2 Power Reservation with Vam for R99 DCH (fair sharing) .................................. 100 166

4.6.4.5 Interfaces between HSDPA Scheduler and OC+ CE............................................. 100 167 4.6.4.6 Counters ................................................................................................................. 101 168 4.6.5 eCEM/Layer 1 .............................................................................................................102 169 4.6.5.1 Layer 1 Overview.................................................................................................... 102 170 4.6.5.2 CE Message Interface ............................................................................................ 102 171 4.6.5.3 OneChip to PQ3 Interface ...................................................................................... 102 172 4.6.5.4 OCC Firmware Modifications.................................................................................. 103 173 4.6.5.5 OneChip Plus to PQ3 Interface .............................................................................. 104 174

4.6.5.5.1 Cell Configuration Request................................................................................. 104 175 4.6.5.5.2 HS Configuration Request: HS-DSCH Information VIE ..................................... 104 176 4.6.5.5.3 (Uplink) HS-DPCCH: Ack/Nack Indicators ......................................................... 104 177 4.6.5.5.4 (Uplink) HS-DPCCH: Composite PCI/CQI reporting ......................................... 106 178 4.6.5.5.5 PCI/CQI Timing constraints ................................................................................ 110 179 4.6.5.5.6 (Downlink) HS-SCCH Type 3 ............................................................................. 111 180 4.6.5.5.7 (Downlink) HS-PDSCH....................................................................................... 111 181

4.6.5.6 CE Configuration parameters................................................................................. 112 182 4.6.5.7 CE to HSSL Interface – Virtual Antenna Mapping function.................................... 112 183 4.6.6 xCEM impacts .............................................................................................................117 184 4.6.7 TRM impacts ...............................................................................................................117 185 4.6.8 RRH/TRDU impacts ....................................................................................................117 186 4.6.9 Loader .........................................................................................................................117 187 4.6.10 Platform software ........................................................................................................117 188

4.7 FEATURE INTERWORKING ......................................................................................................118 189

4.7.1 UA07 FRS 34391 (Multiple xCEM per Carrier) ...........................................................118 190 4.7.2 UA07 FRS 34388 (RLC Flexible and Mac-ehs) ..........................................................118 191 4.7.3 UA07 FRS 34386 (64 QAM for HSDPA).....................................................................118 192




4.7.4 UA07 FRS 81204 (Dual Cell HSDPA) ........................................................................118 193 4.7.5 UA08 FRS 104832 (Dual Cell HSDPA Capacity Increase) ........................................118 194 4.7.6 UA07 FRS 24186 (Common Channel Defense) .........................................................118 195 4.7.7 UA06 FRS 29808 (PA Power Pooling) .......................................................................118 196 4.7.8 UA08 FRS 89411 (eCEM HSPA aggregate throughput increase) .............................118 197 4.7.9 UA07 FRS 34396, 34194 (Automatic Carrier Switch Off)...........................................118 198 4.7.10 UA07 FRS 81122 (eCEM HSPA aggregate throughput increase) .............................119 199 4.7.11 FN 74682 BTS Serving RRH2x40W 2100 ..................................................................119 200

4.8 PERFORMANCE OBJECTIVES AND IMPACTS ............................................................................120 201

4.8.1 System performances .................................................................................................120 202 4.8.2 Dimensioning...............................................................................................................120 203 4.8.3 Capacity ......................................................................................................................120 204 4.8.4 Dependability...............................................................................................................120 205

4.9 SECURITY.............................................................................................................................120 206

5 INTERFACES ............................................................................................................................121 207

5.1 IUB INTERFACE: MIMO IMPACT IN NBAP PROCEDURES .........................................................121 208

5.2 INTERNAL INTERFACES..........................................................................................................121 209

5.2.1 ITF2: CCM CallP – eCEM CallP .................................................................................121 210 5.2.2 ITF3: CCM OAM – eCEM SLOAM..............................................................................122 211 5.2.3 ITF4: eCEM SLOAM – eCEM CallP ...........................................................................122 212 5.2.4 ITF7: CPIF...................................................................................................................123 213 5.2.5 OC Interface ................................................................................................................124 214 5.2.6 OCP Interface..............................................................................................................125 215 5.2.7 CCM OAM – CCM CallP Interface..............................................................................126 216 5.2.8 CCM – Core_OAM/REproxy ......................................................................................126 217 5.2.9 CPRI............................................................................................................................127 218

6 OAM ...........................................................................................................................................128 219

6.1 CONFIGURATION MANAGEMENT .............................................................................................129 220

6.1.1 dualPaUsage...............................................................................................................129 221 6.1.2 vamParameters...........................................................................................................129 222 6.1.2.1 vamAmplitudeCoeff ................................................................................................ 130 223 6.1.2.2 vamPhaseCoeff ...................................................................................................... 131 224 6.1.3 IsPrecodingWeightSetRestrictionPreferred ................................................................132 225 6.1.4 nCqiTypeAMCqiRatio..................................................................................................132 226 6.1.5 hsScchType3SingleStreamSnr ...................................................................................133 227 6.1.6 hsScchType3DualStreamSnr......................................................................................133 228 6.1.7 DualCellHsdpaMimoMaxNumberUserEcem...............................................................133 229

6.2 FAULT MANAGEMENT ............................................................................................................135 230

6.2.1 Alarms .........................................................................................................................135 231 6.2.2 Errors Message List ....................................................................................................136 232

6.3 PERFORMANCE MANAGEMENT ..............................................................................................137 233

6.3.1 Counters......................................................................................................................137 234 6.3.1.1 Counters for the measurement of the Tx powers ................................................... 137 235 6.3.1.2 Introduction of new UE categories: ........................................................................ 138 236 6.3.1.3 Counters that shall take into account dual streams for MIMO UE’s....................... 138 237 6.3.1.4 Information concerning Single stream/Dual Stream statistics................................ 139 238

7 O&M PROCEDURES.................................................................................................................141 239

7.1 WCDMA IBTS UPGRADE ......................................................................................................141 240




7.2 BENIGNESS, BACKWARD COMPATIBILITY................................................................................141 241

7.3 INSTALLATION AND COMMISSIONING ......................................................................................141 242

7.4 WIPS TOOL .........................................................................................................................141 243

8 FIELD INTRODUCTION ............................................................................................................141 244

8.1 HARDWARE CONSTRAINTS.....................................................................................................141 245

8.2 MS INTERWORKING...............................................................................................................141 246

9 TOOLS IMPACTS...................................... ................................................................................142 247

9.1 TIL IMPACTS.........................................................................................................................142 248

9.2 CDM IMPACTS......................................................................................................................142 249

9.2.1 CDM reported by PQ3.................................................................................................142 250 9.2.2 CDM reported by PQ2 CallP CEM..............................................................................143 251

10 OPEN ISSUES ...........................................................................................................................144 252

11 ABBREVIATIONS & DEFINITIONS........................ ..................................................................145 253

12 ANNEX.......................................................................................................................................147 254

12.1 WORK TO ACHIEVE DELAYS ALIGMENT ....................................................................................147 255

12.1.1 Constraints of delays for radio modules in MIMO.......................................................147 256 12.1.2 Delay alignments of TX paths .....................................................................................147 257 12.1.2.1 R&D approach to associate 2 radio modules in a MIMO sector ............................ 147 258 12.1.2.2 Computation of TX delay constraint for a radio module ......................................... 147 259 12.1.2.3 Dispersion of TX delays of radio modules.............................................................. 148 260 12.1.2.4 Measured delay in MCPA versus firmware delay .................................................. 150 261

12.1.2.4.1 Influence of MCPA technology on Delay variation ........................................... 150 262 12.1.2.4.2 Table of MCPA measured delays..................................................................... 150 263

12.1.2.5 MCPA mixity rules .................................................................................................. 151 264 12.1.2.6 Delay aligment of TX paths with CPRI Radio modules .......................................... 151 265 12.1.3 RRH Delay Alignment example in daisy chained configuration..................................153 266 12.1.4 Delay aligment of RX paths.........................................................................................155 267 12.1.4.1 Delay alignments of RX paths in iBTS Macro ........................................................ 155 268 12.1.4.2 Delay alignments of RX paths for CPRI modules .................................................. 155 269 12.1.5 xTRM delay realignment .............................................................................................164 270 12.1.5.1 Focus delay alignment on TX path......................................................................... 164 271 12.1.5.2 OAM CCM recovers radio delays........................................................................... 165 272 12.1.5.3 OAM CCM TX delay realignment ........................................................................... 165 273

12.1.5.3.1 Integer delay compensation ............................................................................. 166 274 12.1.5.3.2 Fractional delay compensation......................................................................... 166 275 12.1.5.3.3 xTRM Delay Alignment example ...................................................................... 167 276

12.2 WORK ON TRANSCEIVER ASPECTS..........................................................................................168 277

12.2.1 Work on CPRI modules (RRH & TRDU).....................................................................168 278 12.2.2 Work on xTRM ............................................................................................................168 279 12.2.2.1 xTRM role of delay adjustment............................................................................... 168 280 12.2.2.2 Operation with 3 xTRM (not supported) ................................................................. 168 281 12.2.3 STRS3-M Mimo on iBTS.............................................................................................169 282

12.3 2 DDM PER SECTOR: ARCHITECTURE NOT SUPPORTED IN IBTS ..............................................171 283




284 285 TABLE OF FIGURES 286 287 Figure 1: MIMO operation for HS-PDSCH transmission 15 288 Figure 2: VAM Schematic diagram for MIMO cell 17 289 Figure 3: MIMO sector using Paired RRH (star or daisy chain) 35 290 Figure 4: d2U configuration using Paired RRH STSR2-M in star 35 291 Figure 5: d2U configuration using Paired RRH STSR2-M in full daisy chaining 36 292 Figure 6: MIMO sector using one Twin RRH (star or daisy chaining) 37 293 Figure 7: d2U MIMO configuration using Twin RRH STSR2-M in star 37 294 Figure 8: d2U MIMO configuration using Twin RRH STSR2-M in daisy chain 38 295 Figure 9: STSR2-M with TRDU 39 296 Figure 10: Macro iBTS STSR2-M (adjacent frequencies) 40 297 Figure 11: Macro iBTS STSR2-M (non adjacent frequencies) 41 298 Figure 12: MIMO solution for iBTS Macro STRS3-M 42 299 Figure 13: Generation of S-CPICH in OneChip 104 300 Figure 14: Ack/Nack User Info Format (proposal) 106 301 Figure 15: PCI/CQI User Info Format (Proposal) 110 302 Figure 16: VAM Function 113 303 Figure 17: Architectural view of VAM 114 304 Figure 18: Block diagram of the VAM Implementation 115 305 Figure 19:RE in star. TX diversity 153 306 Figure 20 UL Realignment Scenario 156 307 Figure 21 Rx Path Sequence modification triggered by UL delay alignment 161 308 Figure 22: Delay alignment in modem 165 309 Figure 23: MIMO solution for iBTS Macro STRS3-M (not supported) 170 310 Figure 24: MIMO solution for iBTS Macro STSR1+1 TX2, RX4 (not supported) 171 311 312




1 INTRODUCTION 313

1.1 OBJECT 314

This document is the functional specification describing the impacts in the iBTS due to the introduction 315 of the feature: “FRS 83984 - MIMO for W-CDMA“. 316

1.2 FRS 317

FRS 83984 - MIMO for W-CDMA“. 318

1.3 SCOPE OF THIS DOCUMENT 319

This document covers iBTS impacts due to introduction of MIMO feature in UA08.0 release. 320

In the scope: iBTS, OEM RRH, ALU RRH, TRDU, MC-TRX, 321

Out of scope: OneBTS, MSNB, HSSL RRH since not required with MIMO. 322

The document will describe also the constraints linked to the introduction of future feature DC-MIMO DL 323 (84 Mbps) in longer term deliverables in 2012. 324

325

1.4 AUDIENCE FOR THIS DOCUMENT 326

This document is intended for iBTS development and integration teams as well as system and RNC 327 architecture, system integration, engineering and PLM teams. 328




1.5 MIMO CONFIGURATIONS 329

The targeted Node B configuration for live validation is separated in 2 priorities P1 & P2: 330 331

• P1: Most expected Configuration : Support with Twin RRH product (2100 MHz). 332 333

RRH 2x40

F1&2&3

RRH 2x40

F1&2&3

RRH 2x40

F1&2&3

9326 d2U

Tw

in P

A R

RH

334 335 The current working view is that Twin RRH 2x40 2100MHz will be part of May 2011 deliverables 336 but not including MIMO functionalities. 337 338 339 At this point, there is no official specifications of the Twin RRH RRH2x40 2100MHz 340 (See [R15]). 341 Section 4.3.2 “MIMO solution with distributed BTS s ector with Twin RRH (preliminary)” is 342 a preliminary description. 343 344 345 The present MIMO FN document does not specify the i mpact of MIMO configuration with 346 Twin RRH, but with a pair of RRH equipments (Called “Paired RRH”) as illustrated in 347 hereafter figure. 348 349 350 The introduction of Twin RRH in MIMO configuration shall be covered by FN 74682 - BTS 351 Serving RRH2x40W 2100. 352

353 354




Temporary configuration using Paired RRH (Not a com mercial delivery) 355

356 357

• P2 : Configuration with TRDU 60W . 358 359

The use of TRDU in MacroBTS requires the introduction of xCOB modules. 360 361

eCEM

eCEM

eCEM

eCEM

eCEM

eCEM

GPSAM TRDU60

TRDU60

TRDU60

TRDU60

TRDU60

TRDU60

Network

Interface

362 363

If xCOB is not available, the configuration is bas ed on a distributed BTS using D2U. 364 365

366




1.6 INTEGRATION PHASES & DEPENDENCIES 367

Here are the intermediate integration phases that can be defined in order to de-risk the introduction of 368 VAM cells , VAMandMIMO cells on RRH/TRDU and Twin RRH configurations. 369 370 Integration phases: 371

Phase_1. De-risk the VAM performances 372 Phase_2. Control Plane for VAMandMIMO cells on RRH/TRDU 373 Phase_3. User Plane for VAMandMIMO cells on RRH/TRDU 374 Phase_4. De-risk Twin RRH User plane with VAM Cells 375 Phase_5. VAMandMIMO cells on Twin RRH 376

377 The table below summarizes the requested partial deliveries and the chosen configurations during the 378 phases. 379 380 Phase Radio

Board CPRI

REproxy MODEM SBBLINK Control

Plane User Plane

Cell Type

1 RRH or TRDU-60W (Note 1)

RRH2x not introduced

Only VAM added in FPGA Combiner

Standard Paired RRH configuration

Modified No change VAM

2 TRDU RRH2x not introduced

All L1 implemented


Modified No change VAM VAMandMIMO

3 TRDU RRH2x not introduced

All L1 implemented


Modified Modified VAM VAMandMIMO

4 Twin RRH Step 1.2 (Note 2)

RRH2x introduced

All L1 implemented


Modified Modified VAM

5 Twin RRH Step 2 (Note 2)

RRH2x introduced

All L1 implemented

All supported configurations

Modified Modified VAM VAMandMIMO

381 Note 1: Radio board able to accept long optic fibers in order to test the Tx delay compensation. 382 383 Note 2: 384

Twin RRH Step1: 385 Official UA8.0 delivery not including MIMO functionalities. 386 387 Twin RRH Step1.2: 388 Modified Step1 version where the 2 AxC downlink containers are connected to the 2 Tx paths 389 according to the standard paired RRH configuration given in 4.6.1.4 SBBLINK routing map (not 390 configurable). The alarms, PM counters and power measurements are unchanged compared to 391 Step1. 392 393 Twin RRH Step2: 394 Official UA8.1 delivery including MIMO functionalities. 395

396 397 398 399

400




2 RELATED DOCUMENTS 401

2.1 APPLICABLE DOCUMENTS 402

[A1] FTS – “MIMO for WCDMA UMT/SYS/APR/027000 01.08/EN Standard 403 18/August/2010 404

[A2] FRS 83984 - “MIMO for W-CDMA“ 405 Version 1.9 406

[A3] UTRAN Iub Interface NBAP Signalling (Release 8) 407 3GPP TS 25.433 V8.8.0 (2009-09) 408

[A4] Physical channels and mapping of transport channels (FDD) 409 3GPP TS 25.211 (V8.5.0) 410

[A5] Multiplexing and channel coding (FDD) 411 3GPP TS 25.212 (v 8.6.0) 412

[A6] Physical layer procedures (FDD) 413 3GPP TS 25.214 (V8.7.0) 414

[A7] UE Radio Access capabilities 415 3GPP TS 25.306 (V8.8.0) 416

[A8] UE Radio transmission and reception (FDD) 417 3GPP TS 25.101 (V8.8.0) 418

[A9] BS Radio transmission and reception (FDD) 419 3GPP TS 25.104 (V8.8.0) 420

[A10] RRC Protocol 421 3GPP TS 25.331 (V8.10.0) 422

2.2 REFERENCE DOCUMENTS 423

[R1] Diversity in 3G, UMT/BTS/INF/24,V01.04/EN Study dated of 11/10/2001 but 424 conclusions are still valid. 425

[R2] Multi-paths Diversity for MIMO (MPD) “Advanced Studies” team Hassan El Nahas 426 (2003) 427 https://wcdma-ll.app.alcatel-428 lucent.com/livelink/livelink.exe?func=ll&objId=45065344&objAction=browse&sort=name 429

[R3] “Channel element Platform” SRD6103 Version ??? 430

[R4] UMTS Channel Element OneChipPlus Algorithms Specification for Uplink Baseband 431 Receiver for HS-DPCCH Livelink Document number 4192884 432

[R5] UMTS Channel Element OneChip Plus TIER0 Architecture document 433 UMT/CE/DD/026459 Edition 15.0 434

[R6] UMTS Channel Element OneChip Plus Message Catalogue for phase 8/UA08 435 UMT/CE/DD/025272 436

[R7] CPRI Radio Module Management 437 UMT/BTS/DD/021952 438

https://wcdma-ll.app.alcatel-439 lucent.com/livelink/livelink.exe?func=ll&objId=45574224&objAction=browse 440




[R8] Dual Cell HSDPA operation 441 UMT/BTS/DD/029670 Issue 01.03 Preliminary. 442

[R9] TN MAC-hs 443

[R10] UA07 Capacity Licensing improvement (FN for FRS34454) 444 UMT/BTS/DD/025148 445

[R11] FRS16746 Capacity Licensing Functional Note 446 UMT/BTS/DD/022460 447

[R12] UMTS Channel Element OneChip Plus Algorithms Specification for Downlink Baseband 448 transmitter for HSDPA 449

UMT/CE/DD/026892 Issue: 2.2 Draft 450

[R13] UMTS Channel Element OneChip Plus and OC-CR Plus Host Software Interface 451 Manual (HSIM) 452

UMT/CE/DD/026804 Issue 12.0 453

[R14] FRS 104832 – Dual Cell HSDPA Capacity Increase 454

UMT/BTS/DD/031036 issue 01.01 455

[R15] FN 74682 – BTS Serving RRH2x40W 2100 456

UMT/BTS/DD/031734 Draft issue 01.03 (08/20/2010) 457

458

459

460

461

462

463

464




3 FUNCTION OVERVIEW 465

3.1 MIMO PRINCIPLE 466

MIMO means Multiple Input, Multiple Output. 467 468

The general transmitter structure to support MIMO operation for HS-PDSCH transmission is shown in 469 Figure 1: 470

471

472 473

Figure 1: MIMO operation for HS-PDSCH transmission 474 475 MIMO for HSDPA has been introduced by 3GPP Release 7 which specifies MIMO with 16 QAM. MIMO 476 with 64 QAM is introduced in Release 8. 477 478 The scheme is called Double Transmit Adaptive Array (DTxAA) when dual streams are transmitted and 479 called Transmit Adaptive Array (TxAA) when single stream is transmitted. 480 481 Channel coding, interleaving and spreading for each stream are done as in non-MIMO mode. 482 The Node B scheduler decides to transmit one or two transport blocks to a UE in one TTI (and what 483 transport block size(s) and modulation scheme(s) to use for each of them taking into account the CQI 484 (Channel Quality Indication) and PCI (Precoding Control Indication) information received from UE on 485 HS-DPCCH. 486 For each transmission, the Node B signals to the UE the pre-coding weight w2 applied on the HS-487 PDSCH sub-frame using the pre-coding weight indication bits of part 1 of the corresponding HS-SCCH 488 sub-frame. 489 490 DTxAA MIMO double the peak user throughput due to the possibility to transmit two transport blocks. 491 492 In the BTS, the Modulation Scheme Switching and diversity algorithms are executed in the modem. The 493 space diversity is supported by a second TX path in the iBTS or a second RRH or a Twin RRH, or a 494 second TRDU. 495 496




BTS and Mobile software are combining these techniques to maximise the quality of transmission in all 497 radio conditions. In particular, it avoids the BER degradation due to fading. 498 499 Precoding Weight Set Restriction Mode 500 501 When the UE is configured with precoding weight set restriction by the higher layers, only 2 values 502

prefW2 are allowed (instead of 4) when only one transport block is preferred by the UE as reported in the 503

composite PCI/CQI. This mode has been introduced in the standard in order to balance the power onto 504 the 2 Tx branches in single stream. 505 OAM BTS Cell Parameter IsPrecodingWeightSetRestrictionPreferred indicates to the RNC whether this 506 mode is preferred or not by the NodeB. 507 The NodeB is not able to know whether the MIMO user is finally configured in this mode or not (i.e. no 508 NBAP IE specified). 509 The CE shall always decode PCI out of the 4 possible values and reports it to the scheduler. 510 When IsPrecodingWeightSetRestrictionPreferred=True, the scheduler forces any invalid PCI coming 511 from the CE to a valid value based on the latest valid PCI received. 512 See section PCI/CQI reporting of FTS document [A1] for details. 513 514 515




3.2 VIRTUAL ANTENNA MAPPING (VAM) 516

When deploying MIMO with two transmit antennas, supporting legacy devices by means of transmit 517 diversity seems to be a natural approach. However, lately there has been some focus on the 518 performance of open loop transmit diversity, STTD, deployments in real networks. There have been 519 concerns with the performance in STTD mode for non-MIMO UEs. 520 521 An alternative way to deploy MIMO is to utilize the option of having an S-CPICH as a phase reference 522 for the second antenna. In this case, legacy channels would be transmitted from the first antenna alone. 523 524 One drawback with such a solution is that, if separate power amplifiers (PA) are used for the two 525 transmit antennas; the total power resource is not utilized to its full extent. Non-MIMO traffic will only 526 utilize half of the available power, while MIMO traffic will utilize the total installed power resource. One 527 way to overcome this problem would be to use a power balancing network (a.k.a. Virtual Antenna 528 Mapping). In this way both power amplifiers will be fully utilized even for signals transmitted from the first 529 antenna. 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 Figure 2: VAM Schematic diagram for MIMO cell 552 553 VAM allows the Node-B to “appear” to the UE as if it has fewer Tx antennas than it actually has. 554 Unbalanced power at virtual antenna ports is transformed by VAM into balanced power at physical 555 antenna ports. 556

P-CPICH and S-CPICH are transmitted from both the antennas simultaneously. It is expected that the 557 channel impulse response to be the same for both pilots. It helps mitigate the problem for legacy Type-2 558 or 3 receivers using MMSE equalizer to orthogonalize both channels with same equalization. 559

Polarization domain (using co-located X-pol antenna) is relied upon for avoiding peak-null interference 560 patterns. 561

562

563

564

PA-1

PA-2 p2

p1

v2

v1

Common CCH

DPCH /F-DPCH

HS-PDSCH (Non-MIMO)

MIMO Stream 1

P-CPICH

MIMO Stream 2

w3

w4

w2

w1

VAM

v21

v12

v11

v22

Virtual antenna ports

Physical antenna ports

S-CPICH

v11 v12 v21 v22

VAM Matrix =

a1ejφ1 a2e

jφ2

a3ejφ3 a4e

jφ4




3.3 COMPLIANCE MATRIX 565

CM is based on FRS 83984 ed 1.8. 566 567 Require-ment # General Requirements R&D compliance

statement

R1

For R7 and MIMO UE : support the 2 way data multiplexing (DTxAA <> TxAA). Expected max throughput in an “optimized MIMO channel” is 2 time cat 10 max performances. First delivery of the solution could also support cat 19/20 being treated by the system as cat 17/18. Rel 8 UE may also support MIMO + 64 QAM capabilities (cat 19/20 full performances)

Compliant

Compliant

R2 VAM for non MIMO UEs (HS-PDSCH), R99, signalling and common channels. Objective is to keep the same power capabilities and manage on the same frequency MIMO and non MIMO UEs. To balance the power between the 2 TX paths all channels should use VAM. As soon as MIMO is enabled on one FDD cell, all cells belonging to this sector shall be configured with VAM to benefit for the second PA power. VAM coefficient shall be configurable on per cell basis

Compliant

R3 Support of mobility features : fallback to 1*1 HSDPA combined with intra-frequency mobility procedure activation in case neighbouring -cell do not support space diversity features.

Compliant

R4 Inter-frequency mobility from cell with space diversity to another cell also using space diversity : upgrade the call after mobility done to its supported Tx-DIV scheme ( CM supported)

Compliant Tx-Div not requested

R5 Interaction with IMCTA to be studied : If dedicated layer is available, IMCTA/iMCRA may be used to allocate the call on the appropriate layer.

NA (RNC feature)

R6 Not requested for the first commercial MIMO delivery. Support of this feature on D2U + RRH equipment

• 2 identical RRH on the cell with MIMO activated same type means same engineering code: same vendor, same RF power, same model.

Configuration not supported with MIMO: RRH20

Compliant

R7 Support of this feature with 2 TRDU60-21: • The two TRDU must be identical, i.e. same APN Alcatel

Part Number • Introduction of an xCOB module into xCCM is required

for the macro BTS. Otherwise a d2U is to be used to connect the TRDU

MIMO validation for BTS configuration with 2 xTRM and 2 MCPA per sector (both MCPA having the same RF power) is not requested for the first commercial MIMO delivery

Compliant Configuration supported:

STSR1-M, STSR2-M (adjacent frequencies)

STSR3-M

Configuration not supported:

STSR2-M (non adjacent frequencies)

STSR3-M Macro IBTS with MCPA is not

supported




STSR x+y R8 Support of this feature with RRH

• With D2U + TwinRRH (2x40W, 2100 MHz) is a must have.

MIMO validation with 2 RRH modules in one sector is not requested.

Compliant

R9 Defense mechanism available at RNC and NodeB to manage a degraded mode in case of 1 TX failure detection.

Compliant

R11 Support the S-CPICH on UTRAN : required to manage MIMO

and non MIMO UEs on the same frequency Compliant

R12 Capacity licensing : Two HSDPA connections shall be

considered for capacity licensing in case of a MIMO UE.

Compliant

R13 MIMO shall be supported with single PS I/B over HSPA (E-DCH/HSDPA) Whether MIMO support should be extended for other RAB combinations is a choice that is left to design

Compliant

568 Require-ment # Node B & RNC requirements R&D compliance

statement

R14

Support requested on eCEM with up to 15 MIMO users per board. Note that the sum of MIMO and DC users per board is 15. In case a call is setup by a new MIMO capable UE and the board limit (15) is reached then single transmission mode shall be configured.. Support is requested with xCCM with GE MDA and eCCM (not with iCCM or xCCM with E1 MDA)

Compliant

R15 RNC hardware for MIMO: • MIMO support is requested with DCPS (and DCPS

evolution if available) • MIMO support with PSFP is not requested.

N/A

569 Require-ment # Performance / Capacity / Reliability Requirements R&D compliance

statement

R16

Single user throughput in lab (ideal RF condition in lab) with 16QAM at TCP level: 24 Mbps Multi user throughput (4 users) in lab (ideal RF condition in lab) with 16QAM at TCP level: 6,0 Mbps Target single user throughput in cell center condition in live environment with 16QAM at TCP level: 15 Mbps

Compliant

R17

Optimization of the PA capabilities when MIMO is introduced Performance assessment shall quantify the impact of the S-CPICH/VAM on the non MIMO UE for HSDPA traffic

Compliant




R18

570 Require-ment # Counter Requirements R&D compliance

statement

R19 Estimation of number of stream / TTI usage : may help to identify the (2*2 scheme) MIMO contribution on cell edge improvement;

Compliant

571 Require-ment # Fault Management and Alarm Requirements R&D compliance

statement

R20 Alarm required if the detected hw of i/dBTS is not compatible with TX div or MIMO feature requested in config file (DLU)

Compliant

572 Require-ment # Configuration Management and Parameter Requirements R&D compliance

statement R21 Activation of the feature at NodeB (per cell) and RNC. Compliant

R22 WIPS tool modified to check the consistency between MIMO activation and HW available + configuration on MIMO channels.

NA (WIPS feature)

573 Require-ment # Billing Requirements R&D compliance

statement

R23

MIMO shall be handled by feature licensing Capacity licensing shall consider 2 HSDPA connections used per MIMO UE

Compliant

574 Require-ment # Serviceability Requirements R&D compliance

statement

None

575 Require-ment # Specific Documentation Requirements R&D compliance

statement R23 None

576 577

3.4 DEPLOYMENT OF MIMO IN UTRAN SYSTEM 578

MIMO can be deployed as: 579 • A second frequency in addition to a frequency layer for R99 and HSxPA 580 • A third frequency layer, in addition of the first frequency layer for R99, the second frequency 581

layer for HSxPA. 582 583

This hypothesis is not restricting or constraining since the RNC can configure the second or third carrier 584 in MIMO. 585

3.5 CHOICE OF 2 WAYS RECEIVE DIVERSITY RATHER THAN 4 586

WAYS 587

This paragraph explains why MIMO solution is designed with 2 ways receive diversity rather than a 4 588 ways receive diversity. 589

590 Notations : 591




RX2= 2 ways RX diversity 592 RX4 = 4 ways RX diversity 593 MIMO 2*2 : 2 ways TX diversity + 2 ways RX diversity at the iBTS level 594

595 RX 4 has a significant impact on CEM algorithms: the number of fingers to track is doubled 596

597 RX 4 has a moderate gain (2dB for RX4 compared to RX2). 598 599 The gain of RX 4 with respect to RX 2 in iBTS is analysed in the document “Diversity in 3G” [R1]. This 600 gain depends on the type of antenna used (cross polar or vertical). 601

602 Its main conclusion is: 603

604 “A 0.7 to 1.6 dB gain (…) on uplink for a 4-way diversity solution with 2 cross-polar antennas compared 605 with a classical 2-way diversity with vertical antennas solution may not justify such a (RX4) diversity 606 solution.” 607

608 RX 4 would require 2 DDM instead of 1 per sector to connect 4 antennas per sector. An example of 609 iBTS architecture with RX 4 is given in annex 12.3. 610 611 Rx 4 ways diversity is not supported. 612 613




4 FUNCTIONAL DESCRIPTION 614

MIMO shall be supported in iBTS on eCEM boards. Support on xCEM is not feasible due to lack of 615 FPGA resources. 616 Maximum throughput achievable with MIMO is feasible only with IP transport solution and then requires 617 xCCM or eCCM. 618 MIMO feature is compliant with 3GPP Release-8 September, 2009 specifications and thus, will support 619 corresponding ASN.1 format. Feature can be activated/de-activated per local cell in iBTS. 620

Following impacts have been identified for the NodeB: 621

1. Support of different BTS configurations for MIMO 622

2. Introduction of new OAM parameters for controlling activation/de-activation of the feature. 623

3. NBAP Protocol handing for modifications due to MIMO 624

4. Evolution of load balancing algorithm due to MIMO users 625

5. Delay adjustment to handle requirements related to timing alignment error 626

6. Evolution of MAC-ehs scheduler to take care of MIMO operation 627

7. Handling of modified HS-DPCCH format, handling of HS-SCCH type 3 and MIMO Transmission 628 in Layer 1 & 2 629

8. Counter Management 630

OAM modules in controller and modem boards are impacted to take care of activation/de-activation of 631 the feature, control and reporting of MIMO capability to RNC, validation of different configurations and 632 parameters as per requirements/constraints of MIMO and finally delay adjustments in modem boards 633 and radio modules for controlling timing alignment. 634

Call processing modules in controller and modem boards are impacted to support NBAP evolutions for 635 MIMO, evolution of load balancing algorithm and counters management for MIMO. 636

Radio modules (xTRM, TRDU and CPRI RRH) are impacted to take care of timing alignments (delay 637 adjustments). 638

Layer 1 & 2 in modem boards is impacted to support MIMO MAC-ehs scheduler evolutions, handling of 639 new HS-DPCCH format, handling of HS-SCCH type 3 and transmission of one or two transport blocks 640 per TTI to a UE and counters management for MIMO. 641

4.1 NBAP 642

For this feature the following new NBAP parameters are introduced: 643 • (9.2.1.118) MIMO Capability 644 • (9.2.2.118) MIMO Power Offset For S-CPICH Capability 645 • (9.2.1.121) SixtyfourQAM DL and MIMO Combined Capability 646 • (9.2.1.119) MIMO Activation Indicator 647 • (9.2.1.120) MIMO Mode Indicator 648 • (9.2.2.96) MIMO N/M Ratio 649 • (9.2.1.102) HARQ Memory Partitioning 650 • (9.2.2.73) MIMO Pilot Configuration 651 • (9.2.2.120) MIMO Pilot Configuration Extension 652 • (9.2.2.119) Power Offset For Secondary CPICH for MIMO 653 • (9.2.2.124) Precoding Weight Set Restriction 654

They are described more in details in the following sections. 655




4.1.1 NBAP new or modified parameters 656

4.1.1.1 MIMO Capability (9.2.1.118) 657

This parameter defined the capability of the Local Cell to support MIMO 658 659

IE/Group Name Presence Range IE Type and Reference

Semantics Description

MIMO Capability ENUMERATED (MIMO Capable, MIMO Non-Capable)

660 This IE is contained in: 661

• Audit Response 662 • Resource Status Indication 663 664

4.1.1.2 MIMO Power Offset For S-CPICH Capability (9 .2.2.118) 665

666 IE/Group Name Presence Range IE Type and

Reference Semantics Description

MIMO Power Offset For S-CPICH Capability

ENUMERATED (S-CPICH Power Offset Capable, S-CPICH Power Offset Not Capable)


• Audit Response 669 • Resource Status Indication 670

671

4.1.1.3 SixtyfourQAM DL and MIMO Combined Capabilit y (9.2.1.121) 672

This parameter defines the SixtyfourQAM downlink and MIMO combined capability for a Local Cell. 673 674



SixtyfourQAM DL and MIMO Combined Capability

ENUMERATED (SixtyfourQAM DL and MIMO Combined Capable, SixtyfourQAM DL and MIMO Combined Non-Capable)


• Audit Response 677 • Resource Status Indication 678

679




4.1.1.4 MIMO Activation Indicator (9.2.1.119) 680

This parameter indicates if the NodeB shall activate MIMO. 681 682



MIMO Activation Indicator M NULL 683 This IE is included in “(9.2.2.18E) HS-DSCH FDD information” IE which is contained in: 684

• RL Setup Request 685 • RL Reconfiguration Prepare Request 686 • RL Addition Request (not supported by Node B) 687 • RL Setup Failure 688

It is also included in “(9.2.2.112) HS-DSCH preconfiguration Setup” IE that is currently not supported. 689 690 Note: the “HS-DSCH FDD information” IE in the RL Addition Request is not supported by the NodeB. 691

692

4.1.1.5 MIMO Mode Indicator (9.2.1.120) 693

This parameter indicates if the NodeB shall activate/ deactivate MIMO. 694 695



MIMO Mode Indicator ENUMERATED (Activate, Deactivate)

696 This IE is included in the “HS-DSCH Information To Modify” IE which is contained in: 697

• RL Reconfiguration Prepare 698 • RL Addition Request (not supported by Node B) 699

700 Note: the “HS-DSCH FDD information” IE in the RL Addition Request is not supported by the NodeB. 701 702

4.1.1.6 MIMO N/M Ratio (9.2.2.96) 703

This parameter indicates which UE reporting configuration (N/M ratio) NodeB has decided to use. 704 705



MIMO N/M Ratio M ENUMERATED (1/2, 2/3, 3/4, 4/5, 5/6, 6/7, 7/8, 8/9, 9/10, 1/1,…)

706 This IE is included in “HS-DSCH FDD information Response ” IE which is contained in: 707

• RL Setup Response 708 • RL Reconfiguration Ready 709 • RL Addition Response (not supported by Node B) 710

711 712

4.1.1.7 HARQ Memory Partitioning (9.2.1.102) 713



Criticality Assigned Criticality




CHOICE HARQ Memory Partitioning

1 –

>Implicit >>Number of Processes M INTEGER

(1..8,...12,14,16) For HARQ process IDs going from 0 to "Number of Processes" – 1 the Total number of soft channel bits [33] is partitioned equally between all HARQ processes according to the rules in [18].

–

>Explicit >>HARQ Memory Partitioning Information

1..<maxnoofHARQprocesses>

The first instance of the parameter corresponds to HARQ process with identifier 0, the second instance to HARQ process with identifier 1, and so on.

–

>>>Process Memory Size M 9.2.1.49D See [18] – >>HARQ Memory Partitioning Information Extension For MIMO

0, 4, 6 or 8 For FDD and 1.28Mcps TDD only The 1st instance corresponds to HARQ process with identifier set to “maxnoofHARQprocesses”, the 2nd instance to HARQ process with identifier set to “maxnoofHARQprocesses+1”, and so on.

GLOBAL Ignore

>>>Process Memory Size M 9.2.1.49D See [18]

–

714 This IE is included in: 715 -IE 9.2.2.18E HS-DSCH FDD Information response (so in RL setup failure to) etc ... 716 -IE 9.2.2.77 HS-DSCH Common System Information response (so in PSCR response) 717 -IE 9.2.3.74 RL Reconf Ready. 718 719 Note: in the current implementation only the “HARQ Memory Partitioning mode” implicit (ie: Number of 720 Processes) is supported. 721

4.1.1.8 MIMO Pilot Configuration (9.2.2.73) 722

This parameter indicates which Pilot Configuration shall be used when MIMO is configured in the cell. 723 724






CHOICE Pilot Configuration M >Primary and Secondary CPICH

>>Associated Secondary CPICH

M Common Physical Channel ID 9.2.1.13

>Normal and Diversity Primary CPICH

NULL This IE in not used in this release.

725 This IE is included in: 726

• Cell Setup Request 727 • Cell Reconfiguration Request 728

4.1.1.9 MIMO Pilot Configuration Extension (9.2.2.1 20) 729

730 IE/Group Name Presence Range IE Type and

Reference Semantics Description

CHOICE Pilot Configuration M >Primary and Secondary CPICH

>> Power Offset For Secondary CPICH for MIMO

M 9.2.2.119

>Normal and Diversity Primary CPICH

NULL This IE is not used in this release.



735

4.1.1.10 Power Offset For Secondary CPICH for MIMO (9.2.2.119) 736

The Power Offset For S-CPICH for MIMO IE indicates the relative transmit power of the S-CPICH 737 compared to the primary CPICH transmit power, when S-CPICH is used as a phase reference for a 738 second transmit antenna in MIMO mode. 739 740



Power Offset For Secondary CPICH for MIMO

INTEGER(-6 .. 0) Offset in dB

741 This IE is included in IE MIMO Pilot configuration Extension in: 742


745

4.1.1.11 Precoding Weight Set Restriction (9.2.2.12 4) 746

This parameter defines the preferred Precoding Weight Set Restriction configuration. 747 748






Precoding Weight Set Restriction

ENUMERATED (Preferred, Not Preferred)


• Resource Status Indication 751 • Audit Response 752

753 This parameter does not belong to 3GPP Rel 8 September 2009. Refer to CR 1789 for the Introduction 754 of this parameter in release 8.8.0. 755 756

4.1.1.12 Tx Diversity on DL Control Channel by MIMO UE capability (9.2.2.121) 757

The following optional IE shall not be used because TxD functionality is not supported this MIMO 758 release on iBTS. 759 760

IE/Group Name Presence

Range IE Type and Reference Semantics Description

TX Diversity on DL Control Channels by MIMO UE Capability

ENUMERATED ( DLControl Channel TxDiversity for MIMO UE with non-diverse P-CPICH Capable, DL Control Channel Tx Diversity for MIMO UE with non-diverse PCPICH NotCapable )


• Resource Status Indication 763 • Audit Response 764

765

4.1.2 Impacts on NBAP procedures 766

4.1.2.1 Audit Response 767

For every MIMO-capable Local Cell the Node B shall include: 768 • the MIMO Capability IE set to "MIMO Capable". 769 • SixtyfourQAM DL and MIMO Combined Capability IE set to "SixtyfourQAM DL and MIMO 770

Combined Capable" if 64QAM+MIMO is supported and 771 • MIMO Power Offset For S-CPICH Capability IE set to "S-CPICH Power Offset Capable“ 772 • Precoding Weight Set Restriction. 773

774 In the NBAP Audit Response message. 775

776

4.1.2.2 Resource Status Indication 777

If a Local Cell is MIMO-capable when it becomes existing, then the Node B shall include: 778 • the MIMO Capability IE set to "MIMO Capable" 779 • SixtyfourQAM DL and MIMO Combined Capability IE set to "SixtyfourQAM DL and MIMO 780

Combined Capable" (64QAM is always supported on eCEM) and 781 • MIMO Power Offset For S-CPICH Capability IE set to "S-CPICH Power Offset Capable“ 782




• Precoding Weight Set Restriction set to Preferred (resp. Not_Preferred) if OMC parameter 783 IsprecodingWeightSetRestriction is True (resp. False). 784

785 In the NBAP Resource Status Indication message. 786

787 Capability Change of a Local Cell: 788 If the MIMO capability has changed for the Local Cell, then the new capability shall be indicated in the 789 MIMO Capability IE 790

4.1.2.3 Cell Setup 791

The RNC sends a CELL SET UP REQUEST message with MIMO to iBTS only on FDD cells that the 792 iBTS has declared as “MIMO capable”. 793 794 If the MIMO Pilot Configuration IE is included in the CELL SETUP REQUEST message and the Local 795 Cell associated is MIMO Capable, then the parameters defining the pilot configuration for MIMO shall be 796 stored in the Node B and applied when MIMO mode is used. 797 798 If the MIMO Pilot Configuration Extension IE is included in the CELL SETUP REQUEST message and 799 the Local Cell associated is MIMO Capable, then the parameters defining the pilot configuration for 800 MIMO shall be stored in the Node B and applied when MIMO mode is used 801 802

Err_Mess 4.1.2.3-1 803 If the MIMO Pilot Configuration IE or the MIMO Pilot Configuration Extension IE is included in the CELL 804 SETUP REQUEST message and the Local Cell associated is not MIMO Capable, then the NodeB shall 805 reject by sending a CELL SETUP FAILURE with cause “MIMO not available” 806 807

Err_Mess 4.1.2.3-2 808 If the “Secondary CPICH Information” IE is included in the CELL SETUP REQUEST message and the 809 Local Cell associated is not MIMO Capable, then the NodeB shall reject by sending a CELL SETUP 810 FAILURE with cause “MIMO not available” 811

4.1.2.4 Cell Reconfiguration 812

If the MIMO Pilot Configuration IE is included in the CELL RECONFIGURATION REQUEST message 813 and the Local Cell associated is MIMO Capable, then the parameters defining the pilot configuration for 814 MIMO shall be stored in the Node B and applied when MIMO mode is used. 815 816 If the MIMO Pilot Configuration Extension IE is included in the CELL RECONFIGURATION REQUEST 817 message and the Local Cell associated is MIMO Capable, then the parameters defining the pilot 818 configuration for MIMO shall be stored in the Node B and applied when MIMO mode is used 819 820

Err_Mess 4.1.2.4-1 821 If the MIMO Pilot Configuration IE or the MIMO Pilot Configuration Extension IE is included in the CELL 822 RECONFIGURATION REQUEST message and the Local Cell associated is not MIMO Capable, then 823 the NodeB shall reject by sending a CELL RECONFIGURATION FAILURE with cause “MIMO not 824 available” 825

4.1.2.5 Radio Link Setup 826

If the MIMO Activation Indicator IE is included in the HS-DSCH FDD Information IE, then the Node B 827 shall activate the MIMO mode for the HS-DSCH Radio Link and the Node B shall decide the UE 828 reporting configuration (N/M ratio) for MIMO and include the MIMO N/M Ratio IE in the HS-DSCH FDD 829 Information Response IE in the RADIO LINK SETUP RESPONSE message. 830 831




If the HS-DSCH Information IE is present in the RADIO LINK SETUP REQUEST message, the Node B 832 shall include the HARQ Memory Partitioning IE in the HS-DSCH FDD Information Response IE in the 833 RADIO LINK SETUP RESPONSE message. The HARQ Memory Partitioning IE shall contain the 834 Number of Processes IE set to a value higher than "8", if the MIMO Activation Indicator IE is included in 835 the HS-DSCH Information IE. 836 837

Err_Mess 4.1.2.5-1 838 If the RADIO LINK SETUP REQUEST message contains the MIMO Activation Indicator IE and/or 839 Sixtyfour QAM Usage Allowed Indicator IE set to "Allowed", but does not contain the HS-DSCH MAC-d 840 PDU Size Format IE set to "Flexible MAC-d PDU Size", then the Node B shall reject the procedure 841 using the RADIO LINK SETUP FAILURE message with “Protocol Cause” set to “Semantic error” 842 843

Err_Mess 4.1.2.5-2 844 If the RADIO LINK SETUP REQUEST message contains the MIMO Activation Indicator IE and an 845 additional HS cell Information RL Setup IE, then the NodeB shal reject the procedure using the RADIO 846 LINK SETUP FAILURE message with cause “MIMO not available”. 847

4.1.2.6 Radio Link Reconfiguration Prepare 848

HS-DSCH Setup: 849 If the HS-DSCH Information IE is present in the RADIO LINK RECONFIGURATION PREPARE 850 message, then the Node B shall include the HARQ Memory Partitioning IE in the HS-DSCH FDD 851 Information Response IE in the RADIO LINK RECONFIGURATION READY message. The HARQ 852 Memory Partitioning IE shall contain the Number of Processes IE set to a value higher than "8", if the 853 MIMO Activation Indicator IE is included in the HS-DSCH Information IE. 854 855 If the MIMO Activation Indicator IE is included in the HS-DSCH FDD Information IE, then the Node B 856 shall activate the MIMO mode for the HS-DSCH Radio Link and the Node B shall decide the UE 857 reporting configuration (N/M ratio) for MIMO and include the MIMO N/M Ratio IE in the HS-DSCH FDD 858 Information Response IE in the RADIO LINK RECONFIGURATION READY message. 859 860 Intra-Node B Serving HS-DSCH Radio Link Change: 861 If the RADIO LINK RECONFIGURATION PREPARE message includes the HS-PDSCH RL ID IE, this 862 indicates the new Serving HS-DSCH Radio Link: 863

• In the new configuration the Node B shall de-allocate the HS-PDSCH resources of the old 864 Serving HS-PDSCH Radio Link and allocate the HS-PDSCH resources for the new Serving 865 HS-PDSCH Radio Link. 866

• The Node B may include the HARQ Memory Partitioning IE in the HS-DSCH FDD Information 867 Response IE in the RADIO LINK RECONFIGURATION READY message. The HARQ 868 Memory Partitioning IE may contain the Number of Processes IE set to a value higher than 869 "8". 870

871 HS-DSCH Modification: 872 If the RADIO LINK RECONFIGURATION PREPARE message includes the HS-DSCH Information To 873 Modify IE, then: 874

• If the RADIO LINK RECONFIGURATION PREPARE message includes the HS-DSCH Physical 875 Layer Category IE in the HS-DSCH Information To Modify IE, the Node B shall use this 876 information in the new configuration and may include the HARQ Memory Partitioning IE in the 877 RADIO LINK RECONFIGURATION READY message. The HARQ Memory Partitioning IE may 878 contain the Number of Processes IE set to a value higher than "8". 879

• If the MIMO Mode Indicator IE is included in the HS-DSCH Information To Modify IE, then the 880 Node B shall activate/deactivate the MIMO mode for the HS-DSCH Radio Link in accordance 881 with the MIMO Mode Indicator IE. 882

• If the MIMO Mode Indicator IE is set to "Activate", then the Node B shall decide the UE 883 reporting configuration (N/M ratio) for MIMO and include the MIMO N/M Ratio IE in the HS-884




DSCH FDD Information Response IE in the RADIO LINK RECONFIGURATION READY 885 message. 886

887 HS-DSCH MAC-d Flow Addition/Deletion: 888 The Node B may include the HARQ Memory Partitioning IE in the RADIO LINK RECONFIGURATION 889 READY message. 890

Err_Mess 4.1.2.6-1 891 If the concerned Node B Communication Context is configured to apply MIMO or allowed to apply 64 892 QAM but is not configured to use flexible MAC-d PDU Size, then the Node B shall reject the procedure 893 using the RADIO LINK RECONFIGURATION FAILURE message. 894 895

Err_Mess 4.1.2.6-2 896 If the message contains the MIMO Activation Indicator IE and an additional HS cell Information RL 897 Reconf Prepare IE, then the NodeB shal reject the procedure using the RADIO LINK SETUP FAILURE 898 message with cause “MIMO not available”. 899 900

4.1.2.7 Radio Link Addition 901

Err_Mess 4.1.2.7-1 902 The “HS-DSCH FDD information” IE in the RL Addition Request is not supported by the Node B. If 903 present in Radio Link Addition Request message the Node B shall answer with a Radio Link Addition 904 Failure with cause “Requested configuration not supported” (existing behavior already implemented). 905

4.1.2.8 S-CPICH Power Management 906

3GPP CR R1-092912 discusses the impact of MIMO activation on non-MIMO UEs where it is shown 907 that the non-MIMO UEs experience a performance degradation due the presence of two downlink 908 transmit antennas. 909 910 In order to reduce the MIMO impact on legacy UEs and to co-exist with MIMO UEs that use the P-911 CPICH and S-CPICH, 3GPP proposed using different power offset for the S-CPICH configured for 912 MIMO 913 914 NodeB shall be capable of applying different power offsets (w.r.t. P-CPICH) to S-CPICH in MIMO mode 915 and in non-MIMO mode. This means the configured S-CPICH will be transmitted with different power 916 depending upon whether there is any UE in MIMO mode in the cell. 917 918 RNC communicates in NBAP CellSetupRequest/CellReconfigurationRequest messages the power 919 offsets (w.r.t. P-CPICH) to be used for S-CPICH depending on presence of any UE in MIMO mode: 920

• IE Secondary CPICH Information with IE Secondary CPICH Power. This power offset is to be 921 applied when there is no UE in the cell in MIMO mode. 922

• IE MIMO Pilot Configuration extension with IE Power Offset For Secondary CPICH for MIMO. 923 This power offset is to be applied when there is at least one UE in the cell in MIMO mode. 924

925 CCM CallP shall save the two S-CPICH power offset “Secondary CPICH Power” and “Power Offset For 926 Secondary CPICH for MIMO” received in Cell Setup Request or Cell Reconfiguration request messages 927 from RNC. 928 929 eCEM does not manage the IE “MIMO Pilot Configuration Extension”. It is up to CCM CallP to provide 930 the IE “Secondary CPICH Power” filled with the right S-CPICH power depending upon whether there is 931 any UE in MIMO mode in the cell by using the S-CPICH power offset reconfiguration procedure (see 932 section 4.6.2.3). 933 934 In case of lost of MIMO capability in a cell this is indicated by CCM OAM to RNC using RSI-SI message 935 and to CCM CallP using OMIU_MODIFY_LOCAL_CELL_REQ message with MIMO activation = false. 936




CCM CallP shall keep untouched the S-CPICH configuration but reconfigured the S-CPICH power to 937 the minimum value using the S-CPICH power offset reconfiguration procedure (see section 4.6.2.3). 938

4.1.2.9 Impacts on MIMO calls when cell MIMO capabi lity is lost 939

In case of lost of MIMO capability (PA failure for example) the impact on MIMO calls is expected only 940 due to available power reduction. This can be minimal depending upon cell load. 941 942 Since MIMO UEs are still enabling HSDPA in MIMO mode, the NodeB shall continue scheduling the 943 MIMO UEs using HSDPA/MIMO control signalling (HS-SCCH Type 3 and HS-DPCCH/MIMO) according 944 to their channel conditions even if MIMO capability in the cell was lost. 945 946 No impact also on calls in progress (RL Setup request, RL Reconfiguration Request) which will be 947 setup, reconfigured as MIMO calls. 948 949 It is up to the RNC to reconfigure or not the call to non MIMO (RNC behaviour is out of the scope of this 950 document). 951




4.2 DELAYS IN MIMO PATHS 952

4.2.1 Delay adjustment principle 953

The MIMO solution uses several radio modules in parallel. 954 955 Dual paths in UL implies to align relative delays on both UL paths 956 957 Dual paths in DL implies to align relative delays on both DL paths 958 959 The constraint in DL is TC/4 (3GPP requirement) and in UL better than TC/4. 960 961 If delay adjustment is inaccurate, the BER gets degraded. Delays must be adjusted on the 2 TX path 962 such that: 963

• | delay DL Main - delay DL Div | < TC/4 (3GPP requirement) 964 965

Delays must be adjusted on the 2 RX paths such that: 966 • | delay UL Main - delay UL Div | < TC/4 967

968

4.2.2 Delay adjustment mechanism 969

The delay will be compensated in modems and in the RRH for the dBTS + RRH or dBTS + TRDU 970 solutions. The integer part of delay is compensated in modem, and the fractional part is compensated in 971 RRH. 972 973 The delay of each MIMO path in DL will be compensated in modems and TRM for the TRM+MCPA 974 +DDM solution. There is no compensation needed in UL as the two Rx path used the same DDM. 975 976 More details in delay adjustment mechanism can be found in section 12.1 977 978

979 980




4.3 SUPPORTED CONFIGURATIONS 981

MIMO Not supported

MIMO Supported

Priority

Number of sectors

6 sectors 3 sectors (max 6MCPA/Node B)

TX diversity (MCPA, Twin_RRH, RRH, TRDU)

2 TX paths P1: Twin RRH

P2: TRDU60W

RX diversity (DDM, Twin_RRH, RRH, TRDU)

2 RX paths P1: Twin RRH

P2: TRDU60-21

MCPA Cajun MCPA MIMO supported only on same type of MCPA+DDM on both TX paths, and same on DDM RX paths Not requested for first commercial delivery

Not for 1st Commercial delivery

MCPA mixity Mixity of TRDU + MCPA is not, supported

Transceivers (TRM) in iBTS

TRM, iTRM xTRM, xTRM2. xTRM, xTRM2 mixity is supported

Not for 1st Commercial delivery

Modems CEM alpha, iCEM, xCEM

eCEM, eCEM-U,

Controllers CCM, iCCM, iCCM2 xCCM, xCCM-U, eCCM-U, eCCM

RRH 2020 Not required, Not supported

CPRI Twin RRH CPRI Twin RRH is supported P1

CPRI RRH CPRI RRH are supported, including RRH21-40W ALU RRH21-60W OEM RRH 40W ALU in other frequency bands A pair of CPRI RRH supporting MIMO are of same vendor, same model (same APN Alcatel Part Number) Star or daisy chaining

Not a commercial requirement. See Note.

CPRI RRH (single PA)

4RX on 4 antennas

TRDU TRDU are supported A pair of TRDU supporting MIMO are of same vendor, same model (same APN Alcatel Part Number) TRDU40W in star or TRDU 60W in star or daisy chaining

P2: TRDU60-21

Repeaters RRH in repeater mode




MIMO Not supported

MIMO Supported

Priority

iBTS macro cabinets

STSR3-M Macro IBTS with MCPA

is not supported

STSR1-M, STSR2-M Macro iBTS with MCPA STSR1-M, STSR2-M or STSR3-M New compact 9312+RRH ( 2 or 3 carriers) STSR1-M, STSR2-M or STSR3-M New compact 9312+TRDU ( 2 or 3 carriers)

P2 if xCOB is available

Distributed BTS configurations

MSNB

(dBTS + C-MSR )

is not supported (not required)

STSR1-M, STSR2-M or STSR3-M dBTS 2U 9326 + RRH ( 2 or 3 carriers) STSR1-M, STSR2-M or STSR3-M dBTS 2U 9326 + TRDU ( 2 or 3 carriers) STSR1-M, STSR2-M or STSR3-M dBTS 2U 9326 + MC-TRX( 2 or 3 carriers)

P2 if xCOB is not available

982 Note: Only one type and model of RRH is selected for the temporary Paired RRH configuration. The 983 type and model the closest to the Twin RRH will to be chosen.984




4.3.1 MIMO solution with distributed BTS sector wit h Paired RRH (Not a 985 commercial configuration) 986

987 The following MIMO configuration will be developed as an intermediate configuration while Twin RRH is 988 not available. See section 4.3 Supported Configurations. 989 Only one type of RRH shall be used, the closest to Twin RRH. 990 Only configuration in star shall be used as described on below, this configuration being similar to the 991 Twin RRH configuration. 992

993 One MIMO sector is built with one pair of RRHs, since the CPRI RRH has one PA and 2 RX paths 994 (Main and Div). 995 996

997 Figure 3: MIMO sector using Paired RRH (star or da isy chain) 998

999 Figure 4: d2U configuration using Paired RRH STSR2- M in star 1000

1001 This architecture is derived from the 6 RRH in star, with STSR x+y feature. 1002

d2U

α α’

β β’

γ γ’

RRH 11

Fiber 1

Fiber 2

Fiber 3

RRH 12

RRH 21

RRH 31

RRH 32

RRH 22

1st RX path=

RX Main f1, f2

2 nd RX path

unused

TX path=TXMain f1, f2

Duplexor Duplexor

1st RX path=

RX Divf1, f2

2nd RX path

unused

TX path=TX Div

f1, f2

Duplexor Duplexor

Main Main Div Div

(i/ d)BTS

One sector

RRH n

1st RX path=

RX Main f1, f2

2 nd RX path

unused

TX path=TXMain f1, f2

Duplexor Duplexor

RRH n+1

1st RX path=

RX Divf1, f2

2nd RX path

unused

TX path=TX Div

f1, f2

Duplexor Duplexor

Main Main Div Div

(i/ d)BTS

BB Processing

E O

E O

E O

E O

BB Processing

Short connection Daisy chaining

Antenna #1 Antenna #2




The two Main antennas of RRH are associated in the UTRAN system through the 1003 antennaAccessId parameter, as in the x+y feature. 1004 Example: Paired RRH11 / RRH12 is associated to sector1 (α, α’). 1005 1006

1007 Figure 5: d2U configuration using Paired RRH STSR2- M in full daisy chaining 1008

1009 This architecture is derived from the STSR x+y feature in daisy chaining. 1010 The 2 RRH serving a MIMO sector are consecutive in the daisy chain. 1011 Example: paired RRH (RRH13, 14) is associated to sector2 (β, β’). 1012 This dBTS+RRH architecture supports STRS2-M and STRS3-M configurations if RRH have a 1013 capability of transmitting 3 carriers. 1014

d2U

Fiber 1

α α’

RRH 11

RRH 12

γ γ’ RRH 15 RRH 16

β β’

RRH 13

RRH 14

Fiber 1

Fiber 1

Not required




1015

4.3.2 MIMO solution with distributed BTS sector wit h Twin RRH (preliminary) 1016

The basic MIMO solution shall be developped for the dBTS+CPRI Twin RRH architecture. 1017 One MIMO sector is built with one Twin RRH in 2T2R configuration as shown in the following figure. 1018 As the CPRI Twin RRH has two PAs, and 2 RX paths (Main and Div) per PA, one MIMO sector can be 1019 built with one Twin RRH. 1020 STRS3-M configurations are supported if the Twin RRH has the capability of transmitting 3 carriers. 1021 1022

Main

Ante

nna

(Ant #1)

Div

Ante

nna

(Ant #2)

1023 Figure 6: MIMO sector using one Twin RRH (star or d aisy chaining) 1024

1025 1026

1027 Figure 7: d2U MIMO configuration using Twin RRH STS R2-M in star 1028

1029 This architecture is derived from the Paired RRH in star configuration with STSR x+y feature, 1030 each paired RRH being replaced with one Twin RRH. 1031 Example: Twin RRH 1 is associated to sector1 (α, α’). 1032

d2U

α α’

β β’

γ γ’

Twin RRH 1

Twin RRH 2

Twin RRH 3

Fiber 1

Fiber 2

Fiber 3




1033 Figure 8: d2U MIMO configuration using Twin RRH STS R2-M in daisy chain 1034

1035 This architecture is derived from the Paired RRH in daisy chain configuration with STSR x+y 1036 feature, each paired RRH being replaced with one Twin RRH. 1037 Example: Twin RRH 1 is associated to sector1 (α, α’). 1038

d2U

α β γ α’ β’ γ’

Twin RRH 1 Twin RRH 2 Twin RRH 3

Fiber 1 Fiber 1 Fiber 1




4.3.3 MIMO on TRDU 1039

1040 MIMO solutions with TRDU are similar to MIMO solutions with RRH described in the previous 1041 paragraph. 1042 This solution is illustrated on the next figure for STSR2 MIMO sector with 6 TRDU in star 1043

1044 Figure 9: STSR2-M with TRDU 1045

1046 MIMO solution with TRDU in star 1047

• The basic solution uses the basic TRDU 21-40 which has no daisy chaining capability. 1048 • A first TRDU transmits TX Main and receives RX Main for f1 and f2. 1049 • A second TRDU transmits TX Div and receives RX Div for f1 and f2. 1050 • Each TRDU is connected on its Main antenna. Div antenna is not connected. 1051 • The two Main antennas of TRDU are associated in the UTRAN system through the 1052

antennaAccessID parameter, as in the x+y feature. 1053 • Example: TRDU 1011 and 1041 are associated in sector1. 1054

1055 MIMO solution with TRDU in daisy chaining 1056

• MIMO solutions with TRDU in daisy chaining can be supported if the TRDU model supports 1057 daisy chaining (future TRDU 60W) 1058

• In daisy chain, the two TRDU serving a MIMO site are consecutive in the daisy chain: the daisy 1059 chain starts with (TRDU 1011+TRDU 1012). 1060

• MIMO 2*2 supported using STSR x+y hw config star of daisy chain case: 1061 • TRDU supports the delay adjustment feature. For more details see : § 4.1 1062

1063 This dBTS+TRDU architecture supports STRS2-M and STRS3-M configurations. STSR3-M can be 1064 supported if TRDU has the capability of transmitting 3 carriers 1065

(i/ d)BTS

One sector

TRDU n

RX path =

RX Main f1, f2

TX path =

TX Main f1, f2

Duplexor

Main Div

RX path unused

TRDU n+1

RX

path =

RX Div f1, f2

TX

path =

TX Div f1, f2

Duplexor

Main Div

RX path unused

Same antennaAccessId

Duplexor Duplexor

One sector

TRDU n

RX path =

RX Main f1, f2

TX path =

TX Main f1, f2

Duplexor

Main Div

RX path unused

TRDU n+1

RX path =

RX Div f1, f2

TX path =

TX Div f1, f2

Duplexor

Main Div

RX path unused


Duplexor Duplexor

One sector

TRDU n

RX path =

RX Main f1, f2

TX path =

TX Main f1, f2

Duplexor

Main Div

RX path unused

TRDU m

RX path =

RX Div f1, f2

TX path =

TX Div f1, f2

Duplexor

Main Div

RX path unused


Duplexor Duplexor

(i/ d)BTS

One sector

TRDU n

RX path =

RX Main f1, f2

TX path =

TX Main f1, f2

Duplexor

Main Div

RX path unused

TRDU n+1

RX

path =

RX Div f1, f2

TX

path =

TX Div f1, f2

Duplexor

Main Div

RX path unused


Duplexor Duplexor

One sector

TRDU n

RX path =

RX Main f1, f2

TX path =

TX Main f1, f2

Duplexor

Main Div

RX path unused

TRDU n+1

RX

path =

RX Div f1, f2

TX

path =

TX Div f1, f2

Duplexor

Main Div

RX path unused

TRDU n+1

RX

path =

RX Div f1, f2

TX

path =

TX Div f1, f2

Duplexor

Main Div

RX path unused


Duplexor Duplexor

One sector

TRDU n

RX path =

RX Main f1, f2

TX path =

TX Main f1, f2

Duplexor

Main Div

RX path unused

TRDU n+1

RX path =

RX Div f1, f2

TX path =

TX Div f1, f2

Duplexor

Main Div

RX path unused


Duplexor Duplexor

One sector

TRDU n

RX path =

RX Main f1, f2

TX path =

TX Main f1, f2

Duplexor

Main Div

RX path unused

TRDU n+1

RX path =

RX Div f1, f2

TX path =

TX Div f1, f2

Duplexor

Main Div

RX path unused

TRDU n+1

RX path =

RX Div f1, f2

TX path =

TX Div f1, f2

Duplexor

Main Div

RX path unused


Duplexor Duplexor

One sector

TRDU n

RX path =

RX Main f1, f2

TX path =

TX Main f1, f2

Duplexor

Main Div

RX path unused

TRDU m

RX path =

RX Div f1, f2

TX path =

TX Div f1, f2

Duplexor

Main Div

RX path unused


Duplexor Duplexor

One sector

TRDU n

RX path =

RX Main f1, f2

TX path =

TX Main f1, f2

Duplexor

Main Div

RX path unused

TRDU m

RX path =

RX Div f1, f2

TX path =

TX Div f1, f2

Duplexor

Main Div

RX path unused

TRDU m

RX path =

RX Div f1, f2

TX path =

TX Div f1, f2

Duplexor

Main Div

RX path unused


Duplexor Duplexor




4.3.4 STRS2-M on iBTS with adjacent frequencies (No t requested for the 1 st 1066 commercial delivery) 1067

This architecture is derived from the classical STSR2 iBTS architecture where the two frequencies are 1068 adjacent. 1069 1070 A second xTRM is added to generate the TX div signals to the three sectors. 1071 3 MCPA are added to have two MCPA per sector. 1072

1073 1074

1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089

1090 Figure 10: Macro iBTS STSR2-M (adjacent frequencies ) 1091

Note: STSR1-M which is STSR2-M with only one frequency configured is supported also. 1092 If the xtrmcarrierlicense = 0 and carriers are adjacent, it is possible that RX -F1 is on TRM1 and Rx-F2 1093 is on TRM2. 1094

iBTS

eCEM

xCCM

xTRM

TX f1, f2 MainRx f1, f2 Main,

Div

HSS

PC

DivMain

6 Rx signals

f1,f2

xTRM

TX f1, f2 Div

No RX processed

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA6 Rx signals

f1,f2 Main

f1,f2 Div

f1, f2 are adjacent

iBTS

eCEM

xCCM

xTRM

TX f1, f2 MainRx f1, f2 Main,

Div

HSS

PC

DivMain

6 Rx signals

f1,f2

xTRM

TX f1, f2 Div

No RX processed

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA6 Rx signals

f1,f2 Main

f1,f2 Div

f1, f2 are adjacent




4.3.5 STRS2-M on iBTS with non adjacent frequencies (not supported) 1095

If frequencies are not adjacent (operator spectrum constraint), a possible architecture is: 1096 1097

• TX Main (f1,f2) and RX Main/Div(f1) are assigned to the first xTRM 1098 • TX Div (f1,f2) and RX Main/Div(f2) are assigned to the second xTRM. 1099 1100

Since one xTRM processes only one frequency in reception, f1, and f2 may be not adjacent. 1101 1102

Support of this configuration would correspond to a new development to enforce RX paths allocation on 1103 both xTRM. It is not a nominal behaviour as the behaviour of figure Figure 1104 1105 In case of xTRM failure, the reconfiguration scenario of this configuration would be a new software 1106 behaviour to develop. 1107 1108 This configuration is not supported. 1109

1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140

Figure 11: Macro iBTS STSR2-M (non adjacent frequen cies) 1141 1142

iBTS

eCEM

xCCM

xTRM

TX f1, f2 MainRx f1 Main, Div

HSS

PC

DivMain

6 Rx signals

xTRM

TX f1, f2 DivRx f2 Main, Div

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA6 Rx signals

f1,f2 Main

f1, f2 may be not adjacent

f1,f2 Div

Not supported

iBTS

eCEM

xCCM

xTRM


HSS

PC

DivMain

6 Rx signals

xTRM


MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA6 Rx signals

f1,f2 Main


f1,f2 Div

iBTS

eCEM

xCCM

xTRM


HSS

PC

DivMain

6 Rx signals

xTRM


MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA6 Rx signals

f1,f2 Main


f1,f2 Div

iBTS

eCEM

xCCM

xTRM


HSS

PC

DivMain

6 Rx signals

xTRM


MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA6 Rx signals

f1,f2 Main


f1,f2 Div

Not supported




4.3.6 STRS3-M on iBTS (not supported) 1143

The iBTS is currently limited to 2xTRM due to the TRM mastership algorithm to manage the DDM and 1144 their RF cabling findings. This limitation should be extended. Consequently, the TRM mastership 1145 function and RF cabling test should be reworked to allow 3xTRMs. 1146 1147 This configuration is not supported. 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176

Figure 12: MIMO solution for iBTS Macro STRS3-M 1177

4.4 ASUMPTIONS AND RESTRICTIONS 1178

FRS 81204 “Dual Cell HSDPA” is a pre-requisite for the development of MIMO. 1179 The functional dependencies concern the following aspects: 1180

• Common OAM parameter DualCellHsdpaMimoMaxNumberUserEcem: it is assumed that this 1181 parameter was already introduced by DualCell feature. 1182

• Common L1/PQ3 interface: Is is assumed that the interface is partially compliant (i.e. includes 1183 parameters for DualCell) 1184

1185 MIMO is supported on BTS equipped with eCEM boards (ie: no mixity with ix/CEM). Before introducing 1186 MIMO in an existing site i/xCEM boards shall be replaced by eCEM boards. 1187 1188 With MIMO only 3 sectors are supported (see section 4.3) 1189

iBTSH

SSP

C

eCEM

xCCM

xTRMTX M f1, f2, f3 S1, TX D f1, f2, f3 S1Rx MD f1 S1S2S3

DivMain

6 Rx signals

f1,f2,f3 Main MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA


xTRMTX D f1, f2, f3 S3TX D f1, f2, f3 S3

RxMD f3 S1,S2,S3

f1,f2,f3 Div

3 xTRM are required to manage MIMO on 3 carriers * 3 sectors * 2TX pathsCurrent limitation of 2 xTRM should beextended. Impact on TRM mastership of DDM and RF cablingprocedure to bereworked.

f1,f2,f3 Main

f1,f2,f3 Div

f1, f2, f3 must be adjacentNo

t supporte

d

iBTSH

SSP

C

eCEM

xCCM


DivMain

6 Rx signals

f1,f2,f3 Main MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA



RxMD f3 S1,S2,S3

f1,f2,f3 Div


f1,f2,f3 Main

f1,f2,f3 Div

f1, f2, f3 must be adjacent

iBTSH

SSP

C

eCEM

xCCM


DivMain

6 Rx signals

f1,f2,f3 Main MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA



RxMD f3 S1,S2,S3

f1,f2,f3 Div


f1,f2,f3 Main

f1,f2,f3 Div

f1, f2, f3 must be adjacentNo

t supporte

d




4.5 USES CASES 1190

A MIMO user is at first an HSDPA user. Introduction of MIMO does not change deeply the CallP 1191 scenarios to establish, reconfigure or delete a MIMO call compare to an HSDPA call. 1192 1193 This section will highlight mainly uses cases which are interesting to understand MIMO aspects but is 1194 not exhaustive. For example the call scenario where DCH part and HSPA part are not collocated is not 1195 depicted as not adding value compare to co-located case in the context of MIMO. 1196 1197 eCEM SLOAM acts only as a relay between CCM OAM and eCEM PQ2 CallP and then it is not 1198 represented to simplify the uses cases. 1199 1200 For MIMO calls uses cases the exchanges between eCEM/PQ3 and eCEM CE do not change 1201 compared to what is done for a non MIMO call (HSDPA call) so to avoid overloading of the figures this 1202 is not represented. 1203 1204 To simplify uses cases is used when possible to represent a REQUEST and 1205 its associated RESPONSE. 1206 1207 1208 1209




4.5.1 MIMO Cell Activation/De-activation 1210

1211 1212 1213 1214

CCM OAM CCM CallP

OMIU_ADD_LOCAL_CELL_REQ

OMIU_ADD_LOCAL_CELL_ACK

(Cell 1, MIMOActivation=true)

OMIU_MODIFY_LOCAL_CELL_REQ

OMIU_MODIFY_LOCAL_CELL_ACK

(Cell 1, MIMOActivation=false)

Inform CCM CallP about change in MIMO capability of the Cell 1.

Inform CCM CallP about MIMO cell capability of a cell that is reported to RNC.

RSI-SI (Cell 1, MIMO not capable)

RSI-SI (Cell1, MIMO Capable)

RNC

-Cell 1 is enabled and is MIMO capable - Store the information regarding MIMO capability in the cell context of Cell1. - Use this information to check if MIMO call can be allowed on this cell.

- Store the information regarding MIMO in the cell context of Cell 1.




4.5.2 MIMO Cell Setup 1215

1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253

Take into account MaxTxPower from Cell Setup

CellConfigReq

Cell Setup Response

S-CPICH Setup

P-CPICH Setup

SCH Setup

psbCellSetupRsp

UcuMgrCellCreateRsp

Cell Setup Request

CCM OAM CCM CallP eCEM PQ2 CallP eCEM PQ3

Local Cell Config Resp

eCEM CE

Local Cell Config Req (VamEnabled, VAM Coeff, IsPrecodingWeightSetRestriction)

(MIMO S-CPICH …)

UcuMgrCellCreateReq (VamEnabled, VAM Coeff MaxTxPower, IsPrecodingWeightSetRestriction

psbCellSetupReq

RSI-SI (MIMO capable, MaxTxpower = min(PA1, PA2) + 3dBm)

Cell Setup Request

(MIMO, S-CPICH MaxTxpower = PA1 + PA2)

Cell Setup Response

Cell Setup Request

Cell Setup Response

Store InternalDualPaUsage & VAM coefficients

Take into account InternalDualPaUsage & VAM coefficients

CellConfigReq

PSCR Response

PSCR Request

HsdpaPhyShareChannelSetupReq

PSCR Request

PSCR Response

PSCR Request

PSCR Response

Take into account MIMO parameters received in Hsdpa Config Req

HsdpaPhyShareChannelSetupRsp

Program VAM enabled in FPGA Combiner

OMIU_ADD_LOCAL_CELL_REQ MIMOActivation=true)

TRM1 TRM2

Cell_config_req (MaxTxpower/2)



Hsdpa Config Resp

Hsdpa Config Req (MIMO parameters)

Store MIMO parameters

(S-CPICH)




4.5.3 R99/HSPA Cell Setup 1254

1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292

Take into account MaxTxPower from Cell Setup

CellConfigReq

Cell Setup Response

P-CPICH Setup

SCH Setup

psbCellSetupRsp

UcuMgrCellCreateRsp

Cell Setup Request



eCEM CE

Local Cell Config Req (VamEnabled, VAM Coeff)

UcuMgrCellCreateReq

(VamEnabled, VAM Coeff), MaxTxPower, PrecodingWeighRestriction

psbCellSetupReq

RSI-SI (MaxTxpower = min(PA1, PA2) + 3dBm)

Cell Setup Request MaxTxpower = PA1 + PA2)

Cell Setup Response

Cell Setup Request

Cell Setup Response



TRM1 TRM2




OMIU_ADD_LOCAL_CELL_REQ MIMOActivation=false)


Hsdpa Config Resp

Hsdpa Config Req

CellConfigReq

PSCR Response

PSCR Request

HsdpaPhyShareChannelSetupReq

PSCR Request

PSCR Response

PSCR Request

PSCR Response

Take into account HSDPA parameters received in Hsdpa Config Req

HsdpaPhyShareChannelSetupRsp

If cell is HSDPA capable




4.5.4 MIMO Cell Reconfiguration (S-CPICH Power Offs et) 1293

1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326

PA failure

Cell Reconf Response

S-CPICH Reconf

psbCellReconfRsp

Cell Reconf Request

CCM OAM CCM CallP eCEM PQ2 CallP eCEM PQ3 eCEM CE

(MIMO)

psbCellReconfReq

Cell Reconf Request (S-CPICH Power)


Cell Reconf Request


Failure case

Cell Reconf Request (S-CPICH Power Offset)

Cell Reconf Failure

Cell Reconf Request

Cell Reconf Failure

RSI-SI (MIMO not capable, new MaxTxpower = PA1 or PA2)

Crossing between RSI MIMO not capable and Cell Reconf: ==> Cell Reconf Failure cause “MIMO not available

(cause: MIMO not available)



MIMOActivation=false)

S-CPICH Power

CCM OAM memorizes the new value and reconfigure the S-CPICH Power offset in eCEM depending of the conditions (see section 4.6.2.3)




4.5.5 MIMO parameters online modification 1327

1328

UcuMgrCellUpdateRsp



eCEM CE

Local Cell Config Req (VAM Coeff, PrecodingWeightSetRestriction,)

UcuMgrCellUpdateReq

(VAM Coeff,) PrecodingWeightSetRestriction


Update VAM parameters in FPGA Combiner

Hsdpa Config Resp

Hsdpa Config Req (nCqiTypeAMCqiRatio …)

HsdpaSchedulerParamUpdateReq

Take into account HSDPA parameters received in Hsdpa Config Req

HsdpaSchedulerParamUpdateRsp

Take into account by MAC-ehs scheduler: * hsScchType3SingleStreamSnr and hsScchType3DualStreamSnr at next scheduler activation Take into account by HSD-BBR: * nCqiTypeAMCqiRatio at next HSD setup

From OMC-B TEE(SET:BtsCell:VAMparameters, PrecodingWeightSetRestriction …)

REE(SET:OK)

From OMC-B TEE(SET:Bts:HsdpaConf:nCqiTypeAMCqiRatio …)

REE(SET:OK)

(:nCqiTypeAMCqiRatio …)




4.5.6 MIMO Cell Delete 1329

1330

Cell Hardware Config Delete

Cell Delete Response

Channel Delete (S-CPICH)

Channel Delete (P-CPICH)

Channel Delete (SCH)

ChannelReleaseRsp

UcuMgrCellCreateRsp

Cell Delete Request

CCM OAM CCM CallP eCEM PQ2 CallP eCEM PQ3 eCEM CE

UcuMgrCellDeleteReq

ChannelReleaseReq

Cell Delete Request


Cell Delete Request


TRM1 TRM2

Cell_delete_req

Cell_delete_req

(PSB)

OMIU_DELETE_LOCAL_CELL_REQ

OMIU_DELETE_LOCAL_CELL_ACK

Channel Delete (PRACH)

Channel Delete (Etc.)




4.5.7 Full RL Setup with MIMO HSDPA (RL-Setup Succ ess case) 1331

1332

1333 Note: The above figure is drawn for a case where DCH part and HSxPA part of the call are allocated on 1334 same eCEM board. In case DCH is allocated on a different eCEM board, then only HSxPA part would 1335 be established on this CEM along with silent DCH part. Also, we may only have DCH + HSDPA part and 1336 no HSUPA part. 1337

HARQ Memory Partitioning, MIMO N/M Ratio

CEM_FULL_RL_SETUP_RSP

RNC CCM CallP eCEM PQ2 CallP

eCEM PQ3

DCC BRM

NBAP: RL SETUP REQ

CEM_FULL_RL_SETUP_REQ

NBAP: RL SETUP RESPONSE

HSD_SETUP_REQ

HSD_SETUP_RESP

Resource Request (MIMO HSD)

Resource Response

- Do semantic & logical checks - Run load balancing algorithm to find suitable eCEM - Allocate resources for MIMO HSDPA call

{ > HS-PDSCH RL ID > C-ID > MIMO Activation Indicator …… }

Setup AAL2 micro-channels for HSD and HSU MacD flows Resource Request

(HSU) Resource Response

MIMO Activation Indicator

HSU_SETUP_REQ

HSU_SETUP_RESP

FP_CON_SETUP_REQ (HSU)

FP_CON_SETUP_RESP (HSD)

FP_CON _SETUP_REQ (HSD)

FP_CON_SETUP_RESP (HSU)

Setup DCH channel

Do semantic & logical checks for the NBAP message


MIMO Activation Indicator Indicator


If it is the Setup of the first MIMO RL, Reconfigure the S-CPICH Power to “Power Offset For Secondary CPICH for MIMO”

See section 4.5.20

Allocate resources for MIMO HSD (2 HSPDA resources)

Exchanges between

eCEM/PQ3 and eCEM/CE are not represented to

avoid overloading of the figure




4.5.8 MIMO HSDPA Setup (RL-Setup CCM CallP Failure case) 1338

1339

1340 1341

RNC CCM

NBAP: RL SETUP REQ

Cell not MIMO capable or Failure in

allocating resources for serving HS-DSCH RL

{

> HS-PDSCH RL ID > C-ID

> MIMO Activation Indicator …… }

NBAP: RL SETUP FAILURE

Failure causes: � MIMO not available

� DL radio resources not available or � UL radio resources not available or � Node B Resources Unavailable




4.5.9 R99 to MIMO HSDPA Setup (RL-Reconf-Prepare Su ccess case) 1342

1343

1344 1345


eCEM PQ3

DCC BRM

NBAP: RL RECONF PREPARE

NBAP: RL RECONF READY

CEM_RL_RECONF_PREP_HSPA_RSP

HSD_SETUP_PREP_REQ

HSD_SETUP_PREP_RESP

Resource Request (MIMO HSD)

Resource Response

{ > HS-PDSCH RL ID > C-ID > MIMO Activation Indicator …… }


FP_CON_SETUP_RESP (HSD)

FP_CON _SETUP_REQ (HSD)

CEM_ RL_RECONF_PREPARE

CEM_RL_RECONF_PREP_HSPA_REQ


CEM_ RL_RECONF_READY

)

Setup AAL2 micro-channels for HSD MacD flows


UE has been configured with DCH successfully previously


(HARQ Memory Partitioning, MIMO N/M Ratio)




- Do semantic & logical checks - Allocate HSDPA resources for MIMO HSDPA user

Allocate resources for MIMO HSD (2 HSPDA resources)

Exchanges between






4.5.10 R99 to MIMO HSDPA Setup (RL-Reconf-Commit / Cancel Success cases) 1346

1347 1348

1349 1350


eCEM PQ3

DCC BRM

NBAP: RL RECONF COMMIT

CEM_RL_RECONF_COMMIT_HSPA_IND

HSD_COMMIT_REQ

HSD_COMMIT_RESP

CEM_ RL_RECONF_COMMIT

CEM_RL_RECONF_COMMIT_HSPA

Update the context with Reconf context and remove Reconf context

NBAP: RL RECONF CANCEL

CEM_RL_RECONF_CANCEL_HSPA_IND

CHANNEL_RELEASE_REQ

CHANNEL_RELEASE_RESP

CEM_ RL_RECONF_CANCEL

CEM_RL_RECONF_CANCEL_HSPA

- De-allocate resources for DC-HSDPA call

(HSD Resource)

Resource Release Ind

(HSD Resource)

Successful RL Reconfigure Prepare for MIMO Setup

Delete AAL2 micro-channels for HSD MacD flows


See section 4.5.20

Exchanges between






4.5.11 R99 to MIMO HSDPA Setup (RL-Reconf-Prepare C CM CallP Failure case) 1351

1352

1353 1354 1355 1356 1357 1358 1359 1360 1361


eCEM PQ3

DCC BRM


NBAP: RL RECONF FAILURE

{ > HS-PDSCH RL ID > C-ID > …… }

(Cause)


UE has been configured with DCH successfully previously

- Do semantic & logical checks - Allocate MIMO resource for serving HS-DSCH RL)


CEM_ RL_RECONF_FAIL

(Cause)

- Resource allocation failure for serving HS-DSCH RL Cause: -- MIMO not capable -- DL radio resources not available or -- UL radio resources not available or -- Node B Resources Unavailable




4.5.12 Serving HS-DSCH Modification from MIMO to no n MIMO 1362

1363

(HS-DSCH FDD Information Response)



eCEM PQ3

DCC BRM




HSD_RECONF_PREP_REQ

HSD_RECONF_PREP_RESP

{ …… HS-DSCH Information To Modify IE MIMO Mode indicator= Deactivate }

(MIMO Mode indicator= Deactivate)








HSD_COMMIT_REQ

HSD_COMMIT_RESP



BRM : Update HSDPA resource usage from MIMO HDSPA user to single HSDPA user




HSD_CANCEL_IND


UE has been configured with “DCH + MIMO HSDPA” successfully previously

Update HSDPA resource usage from MIMO HSDPA user to single HSDPA user



If it is the deletion of the last MIMO RL, Reconfigure the S-CPICH Power to “Secondary CPICH Power”

See section 4.5.20

Update Resource Request MIMO � non MIMO

Exchanges between






4.5.13 Serving HS-DSCH Modification from non MIMO t o MIMO 1364

1365


eCEM PQ3

DCC BRM




HSD_RECONF_PREP_REQ

HSD_RECONF_PREP_RESP

{ …… HS-DSCH Information To Modify IE MIMO Mode indicator= Activate }

(MIMO Mode indicator= Activate)








HSD_COMMIT_REQ

HSD_COMMIT_RESP



BRM : Update HSDPA resource usage from single HDSPA user to MIMO HSDPA user




HSD_CANCEL_IND


UE has been configured with “DCH + HSDPA” successfully previously

Update HSDPA resource usage from single HSDPA user to MIMO HSDPA user






See section 4.5.20

Update Resource Request Non MIMO � MIMO

Exchanges between






4.5.14 MIMO HSDPA Removal (RL Delete case) 1366

1367

1368 1369


eCEM PQ3

DCC BRM

NBAP: RL DELETE REQUEST

CEM_ RL_DELETION_REQ

CEM_RL_DELETION_HSPA_REQ

NBAP: RL DELETE RESPONSE

CHANNEL_RELEASE_REQ

CHANNEL_RELEASE_RESP

CEM_RL_DELETION_HSPA_RSP

CEM_RL_DELETION_RSP

- De-allocate resources for MIMO HSDPA call (Serving HS-DSCH RL)

(HSD Resource)

Resource Release Ind

(MIMO HSD)

UE has been configured with HSDPA MIMO successfully previously

Delete AAL2 micro-channels for HSD MacD flows

{ …… RL Information: > RL ID }

Delete DCH part

If it is the deletion of the last MIMO RL, Reconfigure the S-CPICH Power to “Secondary CPICH Power”

See section 4.5.20

Exchanges between






4.5.15 MIMO HSDPA Removal (MAC-d Flow Delete case) 1370

1371

1372 1373 1374


eCEM PQ3

DCC BRM




HSD_RECONF_PREP_REQ

HSD_RECONF_PREP_RES

{ …… HS-DSCH MAC-d Flows To Delete …… }

(HS-DSCH MAC-d Flows To Delete)



Update the Reconf context





HSD_COMMIT_REQ

HSD_COMMIT_RESP



- Update the UE context with Reconf context - De-allocate MIMO HSDPA resources




HSD_CANCEL_IND


UE has been configured with “DCH + MIMO HSDPA successfully previously

Remove Reconf context


Release HSD Channel when number

of remaining MAC-d flows = 0

Request to delete all MAC-d flows

If it is the last MIMO RL Deletion, Reconfigure the S-CPICH Power to “Secondary CPICH Power”

See section 4.5.20

Exchanges between






4.5.16 PA Failure (MIMO cell) 1375

1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391

RSI-SI (MIMO not capable, S-CPICH disabled, new MaxTxpower = PA1)

UcuMgrCellUpdateRsp



eCEM CE

Local Cell Config (VamDegradedToMainOnly)

UcuMgrCellUpdateReq

(MaxTxPower)

PA2 Failure

Cell Reconf Request Cell Reconf Request

Cell Reconf Request (MaxTxPower )


Cell ReconfResponse


UcuMgrCellUpdateReq

(VamDegradedToMainOnly)

UcuMgrCellUpdateRsp

PSCR Response

PSCR Request

HsdpaPhyShareChannelReconfReq

PSCR Request

PSCR Response

PSCR Request (new HSDPAmax power)

PSCR Response

HsdpaPhyShareChannelReconfRsp

MAC-ehs scheduler is updated with the new HSDPA max power No impact in CE

Program VAM to VAM degradedToMainOnly in FPGA Combiner MAC-ehs scheduler is updated to VamDegradedToMainOnly No impact in CE.

TRM2

Cell_delete_req

(new HSDPAmax power)

PSCR is optional (RNC behavior)




MAC-ehs scheduler is updated with new Max TxPower No impact in CE.

Reconfigure the S-CPICH Power to “minimum value” See section 4.5.22




4.5.17 PA Recovery (MIMO Cell) 1392

1393 1394 1395 1396 1397

RSI-SI (MIMO capable, S-CPICH enabled, new MaxTxpower = PA1 + PA2)

UcuMgrCellUpdateRsp



eCEM CE

Local Cell Config Req (VamAndMimoEnabled)

UcuMgrCellUpdateReq

(MaxTxPower)

PA2 Recovery


Cell Reconf Request (MaxTxpower)


Cell ReconfResponse


UcuMgrCellUpdateReq

(Vam Enable)

UcuMgrCellUpdateRsp

PSCR Response

PSCR Request

HsdpaPhyShareChannelReconfR

PSCR Request

PSCR Response

PSCR Request (new HSDPAmax power)

PSCR Response

HsdpaPhyShareChannelReconfRs

MAC-ehs scheduler is updated with the new HSDPA max power No impact in CE

Program VAM enabled in FPGA Combiner MAC-ehs scheduler is updated to VamAndMimoEnabled No impact in CE

(new HSDPAmax power)

MAC-ehs scheduler is updated with new MaxTxPower No impact in CE

PSCR is optional (RNC behavior)



MIMOActivation=true)


TRM2

Reconfigure the S-CPICH Power to Secondary CPICH Power See section 4.5.20




4.5.18 PA Failure (R99 cell) 1398

1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415

RSI-SI (new MaxTxpower = PA1)

UcuMgrCellUpdateRsp



eCEM CE

Local Cell Config (VamDegradedToMainOnly)

UcuMgrCellUpdateReq

(MaxTxPower)

PA2 Failure


Cell Reconf Request (MaxTxPower )


Cell ReconfResponse


UcuMgrCellUpdateReq

(VamDegradedToMainOnly)

UcuMgrCellUpdateRsp

Program VAM to VAM degradedToMainOnly in FPGA Combiner No impact in CE

TRM2

Cell_delete_req




4.5.19 PA Recovery (R99 Cell) 1416

1417 1418

RSI-SI ( new MaxTxpower = PA1 + PA2)

UcuMgrCellUpdateRsp



eCEM CE

Local Cell Config Req (VamAndMimoEnabled)

UcuMgrCellUpdateReq

(MaxTxPower)

PA2 Recovery


Cell Reconf Request (MaxTxpower)




UcuMgrCellUpdateReq

(VamAndMimoEnabled)

UcuMgrCellUpdateRsp

Program VAM enabled in FPGA Combiner No impact in CE


TRM2




4.5.20 Internal S-CPICH Power offset Reconfiguratio n (successful case) 1419

1420 1421 1422 1423 1424

(Secondary CPICH Power)


eCEM PQ3 CCM CallP eCEM PQ2 CallP

CCC

SCPICH_POWER_OFFSET_RECONF_REQ


SCPICH_POWER_OFFSET_RECONF_RSP

If Cell is MIMO capable: Check for first MIMO Call in requested cell. If (noOfMIMOUser = 1) Secondary CPICH Power = Power Offset for Secondary CPICH for MIMO If (noOfMIMOUser = 0) Secondary CPICH Power = Secondary CPICH Power

psbCellReconfRsp

psbCellReconfReq

SCPICH Reconf Req

SCPICH Reconf Resp

Triggers: CEM_RL_SETUP_RSP CEM_RL_RECONF_COMMIT_HSPA_IND CEM_RL_DELETION_HSPA_RSP …

eCEM CE

Cell is MIMO capable




4.5.21 Internal S-CPICH power offset Reconfiguratio n (failure case) 1425

1426



TIMEOUT on non response from eCEM


CCC



SCPICH_POWER_OFFSET_RECONF_FAIL

If Cell is MIMO capable: Check for first MIMO Call in requested cell. If (noOfMIMOUser = 1) Secondary CPICH Power = Power Offset for Secondary CPICH for MIMO If (noOfMIMOUser = 0) Secondary CPICH Power = Secondary CPICH Power

psbCellReconfFail

psbCellReconfReq

SCPICH Reconf Req

SCPICH Reconf Resp

Triggers: CEM_RL_SETUP_RSP CEM_RL_RECONF_COMMIT_HSPA_IND CEM_RL_DELETION_HSPA_RSP …

eCEM CE

RESET_SLAVE_BOARD_IND

CCM OAM

RESET_SLAVE_BOARD_IND

CCM OAM






4.5.22 Internal S-CPICH power offset Reconfiguratio n (lost of MIMO capability) 1427




CCC



SCPICH_POWER_OFFSET_RECONF_RSP

psbCellReconfRsp

psbCellReconfReq

SCPICH Reconf Req

SCPICH Reconf Resp

eCEM CE CCM OAM

Secondary CPICH Power = minimum power offset





PA2 Failure




4.5.23 MIMO Cell Setup (Failure case) 1428

1429 1430 Case 1: Same defense behaviour as for non MIMO cells. 1431 1432 Case 2: Same defense behaviour as shown in section 4.5.16 PA Failure (MIMO cell) 1433

CellConfigReq

Cell SetupFailure

S-CPICH Setup

P-CPICH Setup

SCH Setup

psbCellSetupRsp

UcuMgrCellCreateRsp

Cell Setup Request



eCEM CE

Local Cell Config Req (VamEnabled, VAM Coeff, IsPrecodingWeightSetRestriction)

(MIMO S-CPICH …)

UcuMgrCellCreateReq (VamEnabled, VAM Coeff MaxTxPower, IsPrecodingWeightSetRestriction

psbCellSetupReq

RSI-SI (MIMO capable, MaxTxpower = min(PA1, PA2) + 3dBm)

Cell Setup Request

(MIMO, S-CPICH MaxTxpower = PA1 + PA2)

Cell Setup Failure

Cell Setup Request

Cell Setup Failure




OMIU_ADD_LOCAL_CELL_REQ MIMOActivation=true)

TRM1 TRM2




(S-CPICH)

Case 1: Failure coming from eCEM

Case 2: PA Failure



RSI-SI (MIMO not capable, S-CPICH disabled, new MaxTxpower = PA1)




4.6 FUNCTION DISTRIBUTION 1434

4.6.1 CCM OAM 1435

MIMO can be activated by setting the new parameter DualPAUsage (BTSCell) to VamAndMimo. MIMO 1436 is supported only on eCEM and requires two transmit path on each sector. If the cell configured for 1437 MIMO is served by an xCEM or an iCEM, MIMO is not enabled for that cell and an alarm is raised as 1438 mentioned in section 4.6.1.1. 1439

OAM also ensures that for a MIMO activated cell, VAM parameters are configured. This VAM 1440 parameters are passed on to eCEM for VAM activation.( Refer section 4.6.1.10). 1441

CCM OAM informs CCM-CallP about whether a cell is MIMO capable or not. CCM CallP is notified 1442 whenever there is a change in MIMO capability of a cell. 1443

OAM configures the SBBLINK needed for the additional tx path needed in MIMO configurations. Delay 1444 adjustments are performed to make sure that the delay between two transmit path is less that Tc/4. 1445

Major OAM impacts can be classified as follows: 1446

• Parameter Check 1447 • HW Configuration Validation 1448 • NBAP Interface and procedure impacts for Audit Response and Resource Status Indication 1449 • SBBLINK routing map changes 1450 • Interface with CCM-CallP and eCEM SLOAM 1451 • Radio Modules (xTRM, TRDU, RRH) timing Delay Adjustment 1452 • Counter Management 1453 • Capacity Licensing 1454 1455

MIMO requires two transmit paths and a cell is MIMO capable only if all the following conditions are 1456 true: 1457

• The parameter dualPaUsage is set to “VamAndMimo” 1458 • The cell has two PA resources or two PAResourceRRHs attached. 1459 • The cell is served by an eCEM 1460 • Two transmit paths are enabled. 1461 1462

STSRx+y configurations are not supported. Hence frequency group id of all the carriers will be set to 0. 1463 Hot plugin of TRM is not supported as before. 1464

4.6.1.1 Parameter Check 1465

MIMO is not supported on STSR2+1, STSR2+2, STRS3-M macro iBTS configurations. Hence 1466 configuration file is checked to ensure that if MIMO is activated, no more than 2 frequencies are 1467 configured. However STRS3-M is supported on configurations mentioned in Section 4.3. In such 1468 scenarios, the above check for the number of frequencies does not hold true. 1469

For each MIMO/VAM activated cell (DualPaUsage = VamAndMimo or DualPaUsage = Vam), check 1470 shall be done to ensure that there are two PA Resources associated to it and that the PA resource ids 1471 are valid ( i.e PA resource instance must exist). Conversely if dualPAUsage is set to “none”, then there 1472 should be only one PA resource associated to this. 1473

If BtsCell.antennaConnection <= 6 // Local Sector 1474 If BtsCell. DualPAUsage = VamAndMimo or Vam 1475 The number of paResource of this BtsCell shall be = 2 1476 Else 1477 The number of paResource of this BtsCell shall be = 1 1478 EndIf 1479 Else // remote or CPRI sectors 1480




Similar Check is done for RRH. 1481 In case of Paired RRH configuration: 2 instances of RRH/TRDU should be present for 1482

Vam/VamAndMimo Cells; the number of PAResource of each RRH is 1. 1483 Note: In case of Twin RRH configuration: One instance of Twin RRH is present; the number of 1484

PAResource is 2. 1485 EndIf 1486 1487 The pair of PA resource Ids for a mimo cell with same antenna connection shall be the same. 1488 Conversely, two mimo cells having different antenna connection shall not have the same PA resource 1489 ids. 1490 1491 If a cell is configured with DualPaUsage = VamAndMimo or Vam, then the VAM parameters shall be 1492 present. 1493

If there is at least 1 BtsCell with MIMO or VAM, then the parameter RfCarrier.hspaHardwareAllocation 1494 should be set to xCemOnly 1495

If there is at least 1 BtsCell with MIMO or VAM, then the parameter eCemxCemPreference.should be 1496 set to eCEM. 1497

If dualPaUsage of a BTSCell is set to “vamAndMimo” or “vam”, all BTSCell(s) mapped on the same 1498 sector as that BTSCell should have their dualPaUsage parameter set to “vamAndMimo” or “vam”. 1499 Failure of the above condition would make all the cells on that sector as “MIMO not capable” 1500

When either of these checks fails, BTS would set MIB in state KO and report the alarm INVALID 1501 CONFIGURATION DATA. 1502

4.6.1.2 HW Configuration Validation 1503

When there is atleast one BTSCell with MIMO or VAM configured, mixity of eCEM with iCEM/xCEM is 1504 not allowed. If there is an iCEM/xCEM along with an eCEM at BTS startup or if an iCEM/xCEM is 1505 plugged in, the iCEM/xCEM board object is set to disabled (operationalState set to disabled) and an 1506 alarm “UNSUPPORTED EQUIPMENT/CEM(271_4)” is reported on the associated BOARD object 1507

Mimo is supported only on xCCM/u. if alpha/iCCM is present, cells will not be MIMO capable. Audit 1508 Response / RSI ( to RNC) and ADD/MODIFY_LOCAL_CELL (to CCM- Callp), will indicate that MIMO is 1509 not capable for the cells. 1510

4.6.1.3 NBAP interface and procedure impacts 1511

Audit response 1512

The Node B shall include the MIMO Capability IE and set the MIMO Capability IE value to "MIMO 1513 Capable" for every MIMO capable Local Cell which is on an eCEM and has two transmit paths. The 1514 message shall include the MIMO Power Offset For S-CPICH Capability IE set to "S-CPICH Power 1515 Offset Capable“ for every MIMO capable cell. If 64 QAM is enabled, the NodeB shall include the IE 1516 SixtyfourQAM DL and MIMO Combined Capability and set the value as “SixtyfourQAM DL and MIMO 1517 Combined Capable”. The message shall include the IE Precoding weight set restriction set to true if OMC 1518 parameter IsPrecodingWeightSetRestriction (BTSCell) is true, else false. 1519

Resource Status Indication 1520

When the Local Cell is enabled, the Node B shall include the MIMO Capability IE and set the MIMO 1521 Capability IE value to "MIMO Capable" for every MIMO capable Local Cell which is on an eCEM and 1522 has two transmit paths. The message shall include the MIMO Power Offset For S-CPICH Capability IE 1523 set to "S-CPICH Power Offset Capable“ for every MIMO capable cell. If 64 QAM is enabled, the NodeB 1524 shall include the IE SixtyfourQAM DL and MIMO Combined Capability and set the value as 1525 “SixtyfourQAM DL and MIMO Combined Capable”.The message shall include the IE Precoding weight set 1526 restriction set to true if OMC parameter IsPrecodingWeightSetRestriction (BTSCell) is true, else false. 1527




1528

Tx path failure 1529

When any of the Tx path of a MIMO cell goes down, RSI SI has to be sent for that cell with MIMO 1530 Capability IE as "MIMO Not Capable" and with maxDlPowerCapability set to the max power of the 1531 remaining Tx path. The RSI shall include the MIMO Power Offset For S-CPICH Capability IE set to "S-1532 CPICH Power Offset Not Capable“. RSI shall include also “Secondary CPICH Individual Information IE 1533 populated with Common Physical Channel ID as received in NBAP Cell Setup/Reconfiguration request 1534 message, Resource Operational State “: disabled” and Availability Status “: power off”. 1535

When the failed Tx path is restored, RSI SI will be sent for the cell with MIMO Capability IE as "MIMO 1536 Capable" ", Power Offset For S-CPICH Capability IE set to "S-CPICH Power Offset Capable“ and with 1537 maxDlPowerCapability as sum of both Tx paths. RSI shall include also “Secondary CPICH Individual 1538 Information IE populated with Common Physical Channel ID as received in NBAP Cell 1539 Setup/Reconfiguration request message, Resource Operational State “: enabled” and Availability Status 1540 “: empty. 1541

maxDLPowerCapability Computation 1542

maxDLPowerCapability is computed by deducting the internal and external losses from the PA power ( 1543 based on PAratio for that cell and maxPowerAmplification of the PA or maxRRHPowerAmplification of 1544 the RRH). For Mimo it is quite possible that the external losses of the two paths are different and though 1545 PA power is the same, maxDLPowerCapability would be different for both the tx paths. Hence for MIMO 1546 cells, maxDLPowerCapability reported to RNC would be: 1547

Minimum (MaxDlPowerCapability(Main), MaxDlPowerCapability(Div)) + 3dB 1548

(+3dB corresponds to multiplication by 2 in Watt due to the 2 PA) 1549

Online change of maxPowerAmplification/ maxRRHPower Amplification / 1550 maxMCTRXPowerAmplification 1551

The maxPowerAmplification value of both the PAresource attached to a MIMO or VAM capable cell is 1552 recommended to be the same. However if maxPowerAmplification of either of PA is changed to such 1553 effect that the newly computed MaxDLPowerCapability value becomes different than the one which was 1554 reported to RNC before, RSI with the new MaxDlPowerCapability is sent to RNC. 1555

The same holds true for maxRRHPowerAmplification and maxMCTRXPowerAmplification. 1556




4.6.1.4 SBBLINK routing map 1557

CCM OAM shall configure FLINK and RLINK connections (BBLINK) specific to MIMO configurations. 1558 There is no change in the way SBBLINK is configured. 1559

Following figures gives the sBBLINK routing map for the two supported configurations: 1560

STRS2-M Macro 1561

1562

1563

8398

4- M

IMO

for

WC

DM

A F

N

UM

T/B

TS

/DD

/028

488

02.0

1 / E

N

Pre

limin

ary

09/0

8/20

10

Pag

e 71

/171

Pas

sing

on

or c

opyi

ng o

f thi

s do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts n

ot p

erm

itted

with

out A

lcat

el-L

ucen

t writ

ten

auth

oriz

atio

n

ST

RS

2-M

Dis

trib

uted

: 15

64

1565




1566 STSR3 Distributed (RRH): 1567

STSR3 configurations can be supported if RRH has the capability of transmitting 3 carriers. The SBBlink 1568 configurations are quite similar to STSR2 distributed shown above. ST1 of the third frequency will be on 1569 the next even channel/AxC for the RRH on the main Tx path and corresponding ST2 will be on the next 1570 odd channel/AxC for the RRH on the div Tx path. 1571

MIMO with Twin RRH 1572 1573 This routing map would be detailed in Twin RRH FN. However the routing map would be similar to 1574 STSR2-M ( distributed), except that the unused 6 channels for DPEG 1, 2 and 3 would be used for the 1575 transmit path for second streams for sector 1, 2 and 3 respectively. Since there would be only 3 Twin 1576 RRH radio, we need to use 3 DPEGs only. 1577 1578

PMM Cells: 1579

PMM cells shall contain power information on both main and diversity path. For simplification, main and 1580 diversity can be configured in AddPmmForwarding routine for all cases (MIMO or not MIMO) 1581

1582




4.6.1.5 TRM / PA defense 1583

1584

Tx Path Defense 1585

In case of xTRM2 or PA2 failure, no reconfiguration is required. However if xTRM1 or PA1 fails, CCM 1586 OAM has to reconfigure the Tx path carrying stream 1 on the remaining path. (xTRM2, PA2). CCM 1587 OAM will need to reconfigure the sBBLINK for this failure (similar to STSR2 non-MIMO scenario). CCM 1588 OAM will configure RX paths on TRM2. However in both the cases, the MIMO capability of the cell will 1589 be lost. Same is the case during lock or plug out scenario. 1590

Tx channelizer failure is handled the same way as a TRM failure. 1591

1592 In case of a PA failure, CCM_OAM has to send the new maxDlPowerCapability ( of the remaining PA) 1593 to RNC along with MIMO Capability IE as "MIMO Not Capable" and S-CPICH Op-State as disabled, S-1594 CPICH Availability status as “power off”. 1595 1596 An alarm PARTIAL TX PATH FAILURE is raised to indicate that a MIMO Tx path has failed. 1597 1598 CCM OAM instructs TRM to perform a cell delete on the failed PA. 1599 1600 CCM OAM forwards the Cell Reconfig Request message received from RNC to CCM CallP. 1601 1602

iBTS

eCEM

xCCM

xTRM1

TX f1ST1, f2 ST1Rx f1,f2 Main, Div

HSSP

C

Div Main

6 Rx signals

Macro iBTS STSR 2 MIMO

xTRM2

TX f1ST2, f2ST2

Rx None

MC DDM

MC

MC DDM

MC

MC DDM

MC6 Rx

signals

F1stream 1, F2 stream 1

F1stream 2, F2 stream 2




Along with this CCM OAM sends LocalCellConfig to CEM to instruct it to stop VAM for the tx path. 1603 1604 In case of failure of the first Tx branch, the VAM coefficients for the cell shall be to eCEM in order to 1605 autonomously reconfigured the channels being fed to the first virtual antenna to use the second Tx 1606 branch. VAM coefficients shall be changed as following: 1607 1608

( )

=

=

=

=

=

=

00

00deg_

00

10_

_

43

21

43

21

43

21

2221

1211

43

21

φφφφ

φφ

φφ

tscoefficienPhase

aa

aatscoefficienAmplitude

eaea

eaea

VV

VVMatrixVAM

jj

jj

1609

1610 1611 1612 In case of failure of the second Tx branch, the VAM coefficients for the cell shall be sent to eCEM in 1613 order to autonomously reconfigure the channels being fed to the second virtual antenna to use the first 1614 Tx branch. VAM coefficients shall be changed as following: 1615 1616

( )

=

=

=

=

=

=

00

00deg_

00

01_

_

43

21

43

21

43

21

2221

1211

43

21

φφφφ

φφ

φφ

tscoefficienPhase

aa

aatscoefficienAmplitude

eaea

eaea

VV

VVMatrixVAM

jj

jj

1617

1618 In case of a timeout, the existing defense mechanism would hold good and the alarm is cleared. 1619 1620 For a VAM only cell, above mentioned procedure is still maintained, except that the MIMO information is 1621 not passed to RNC in RSI message. 1622 1623 When PA recovers, similar reverse procedure is applied. 1624 1625 Rx Path Defense 1626 1627 This is same as TRM defense 1628

4.6.1.6 RRH/ TRDU defense 1629

Same as TRM/PA defense. 1630 1631




4.6.1.7 Capacity Licensing 1632

Mimo activation is controlled by additionalRadioPerSector, paPower and rrhPower licensing 1633 parameters. Details pertaining to the above licensing are available at reference documents [R10] and 1634 [R11]. 1635 1636

4.6.1.7.1 additionalRadioPerSector 1637

There is no change in the computation of HW and SW capacities. However, MIMO paths have to be 1638 taken into consideration while computing the needed tokens. 1639 1640 For a MIMO cell, one additionalRadioPerSector token is required, since it has two radio paths. For 1641 UA8.0, the configuration would be either STSR x+y or MIMO. For STSR x+y current algorithm for 1642 computing the needed tokens are used. For MIMO configurations, the needed tokens would be the 1643 number of sectors which support the MIMO cells. 1644 1645 Resource Allocation: 1646 1647 In addition to UA7 criteria, the algorithm will take into account the number, of sectors on which two 1648 PA’s/RRH’s/TRDU’s are configured. If a “MIMO and/or VAM sector” cannot be configured with two 1649 Radios, the cell is not considered as a MIMO cell and CapacityLicensing alarm is raised. 1650 1651 License Increase: 1652 1653 When the license is increased, as in UA 7.0, an additional tx path is setup. It may be possible that a non 1654 MIMO cell can become a MIMO cell. See open issue [16]. 1655 If so procedure pertaining to PA/tx path recovery is performed, as described in section 4.6.1.5 1656 1657 License decrease: 1658 1659 When the license is decreased, as in UA 7.0, an additional tx path may be brought down and BTS is 1660 reset as per current 7.0 algorithm. 1661 1662

4.6.1.7.2 PA Power/ RRH Power 1663

For a MIMO cell, power from both PAs/RRHs is added in the capacity algorithm. There is no change in 1664 the computation of HW and SW capacities. 1665 1666 Resource Allocation: 1667 1668 There is no change from UA7 but in case one or more PA’s/RRH’s/TRDU’s have to be disabled, the 1669 BTS should first disable one of the two PA’s/RRH’s/ configured in “MIMO sectors” so that BTSCell(s) 1670 that are mapped on the impacted sector will still work with one PA/RRH/TRDU. The defense mechanism 1671 mentioned in section 4.6.1.5 is followed. 1672 1673 License Increase: 1674 1675 When the license is increased, as in UA 7.0, an additional PA/RRH may be enabled. It may be possible 1676 that a non MIMO cell can become a MIMO cell. If so procedure pertaining to PA/tx path recovery is 1677 performed, as described in section 4.6.1.5 1678 1679 License decrease: 1680 1681




When the license is decreased, as in UA 7.0, a PA/RRH may be disabled. It may be possible that a 1682 MIMO cell may lose its MIMO capability. If so procedure pertaining to PA/Tx path failure is performed, 1683 as described in section 4.6.1.5 1684

4.6.1.8 get DD: getRadioPowerInfo 1685

The CCM OAM will have to get the TX Power for Main and Div to fill the txPowerSector and txPowerCell 1686 for MIMO and VAM Cell 1687

4.6.1.9 CCM Call Processing – CCM OAM Interaction 1688

Setup and Modification of Local Cell 1689

MIMO activation parameter (MIMOActivation) will be added in OMIU_ADD_LOCAL_CELL and 1690 OMIU_MODIFY_LOCAL_CELL messages (Refer Section 5.2.5). CCM CallP will allow or deny MIMO 1691 calls on that cell based on this parameter. OAM will set this parameter as true / false based on the 1692 MIMO capability of the cell. Whenever the MIMO capability changes OAM updates the CallP by sending 1693 this parameter in the OMIU_MODIFY_LOCAL_CELL message. 1694

4.6.1.10 eCEM SLOAM – CCM OAM Interaction 1695

MIMO information is required by eCEM PQ3. This information has to be passed on ITF-3 to eCEM 1696 SLOAM in LOCAL_CELL_CONFIG_REQ message. CCM OAM shall set DLMapping with main and 1697 diversity bits per cell. 1698

LOCAL_CELL_CONFIG_REQ message is modified to carry the InternalDualPaUsage value and the 1699 VAM parameters to eCEM (Refer Section 5.2.2). CCM OAM shall fill “InternalDualPaUsage”, 1700 VAMAmplitudeCoeff and VAMPhaseCoeff taking into account the “DualPaUsage” configured by OAM 1701 and the hardware available and running at a given time: 1702

OAM: DualPaUsage Hardware available

InternalDualPaUsage Vam coefficients

None PA1 (Main) VamDisabled Amplitude (1,0;0,0)

Phase (0,0;0,0)

Vam or VamAndMimo PA1 (Main) and PA2 (Div)

VamEnabled O&M vamAmplitudeCoeff

O&M vamPhaseCoeff

Vam or VamAndMimo PA2 failure VamDegradedToMainOnly Amplitude (1,0;0,0)

Phase (0,0;0,0)

Vam or VamAndMimo PA1 failure VamDegradedToDivOnly Amplitude (0,1;0,0)

Phase (0,0;0,0)

1703

CCM shall update the eCEM via a LOCAL_CELL_CONFIG_REQ each time there is a change in this 1704 configuration (startup, PA failure, Pa recovery, TRM failure …). CCM OAM shall set DLMapping with 1705 Main and Diversity bits per cell. 1706

4.6.1.11 Timing alignment 1707

Timing alignment is needed for MIMO activated cells, since the two tx path come from two different 1708 TRMs /RRHs/ TRDUs. The delay calculations and compensations are described in the section 12.1. 1709

The delay aligment procedure is always performed whatever type of radio board used. The only 1710 difference is the way the delays are provides by the radio board. 1711




4.6.1.12 Counters 1712

Existing PM counter #10205 shall be modified for a MIMO capable cell to have screening for two different 1713 power amplifiers. 1714 Counter #10225 is retained with its existing functionality, but for Cells with Tx diversity such as MIMO 1715 cells this counter reports the distribution curve of the combined power information for the Main PA and 1716 the Div PA. 1717 Two new counters #10228 & #10229 (as an example) are added in order to report separated distribution 1718 curves for the Main PA and the Div PA. Their format is the same as for counter #10225. 1719 1720 PM module needs to ensure that it retrieves the values for these new screening ids from Radio 1721 counters.. 1722 PM should also ensure that all these new screening ids are added as part of PM observation file (XDR). 1723 PM currently provides the decoding mechanism to convert the XDR (binary) file to ASCII file and display 1724 the ASCII file. Both decoding and display mechanism should include these new screenings. 1725

See section 6.3.1. 1726

1727

1728

1729




4.6.2 CCM CallP 1730

4.6.2.1 CCM CallP – OAM Interaction 1731

MIMO activation parameter (MimoActivation) is added in both OMIU_ADD_LOCAL_CELL and 1732 OMIU_MODIFY_CELL messages. CCM CallP will allow or deny MIMO calls on that cell based on this 1733 parameter. 1734

4.6.2.2 NBAP Manager 1735

The NBAP Manager is enhanced to process the new IE’s introduced to manage MIMO. NBAP manager 1736 shall do the semantic checks defined in section 4.1.2. 1737 1738 The following checks need to be done by CCM CallP for call admission control: 1739 1740 Cell Setup 1741 1742 See section 4.1.2.3 for NBAP checks to be done. 1743 1744 In complement to these checks: 1745 1746

Err_Mess 4.6.2.2-1 1747 If Node B receives “Transmit Diversity Indicator” for S-CPICH set to ‘active’ it shall send a NBAP CELL 1748 SETUP FAILURE” with “Radio Network Layer Cause” set to “Requested Tx Diversity Mode not 1749 supported” (VAM and Transmit Diversity are exclusive). 1750

Err_Mess 4.6.2.2-2 1751 If the IE Pilot Configuration” included in MIMO Pilot Configuration IE or MIMO Pilot Configuration 1752 Extension IE is set to “Normal and Diversity Primary CPICH” NodeB shall send a NBAP CELL SETUP 1753 FAILURE” with “Radio Network Layer Cause” set to “Requested Configuration not supported” 1754 1755 If all the checks pass then CCM CallP shall proceed with the procedure and send the related ITF2 1756 request message to eCEM CallP 1757 1758 When CCM CallP received the ITF2 Cell Setup Response message from the eCEM it shall propagate 1759 the response to the RNC in the NBAP Cell Setup Response message. 1760 1761 In order to reduce the MIMO impact on legacy UE’s and to coexist with MIMO UE’s which use the P-1762 CPICH and S-CPICH 3GPP propose to use different power offset for the s-CPICH configured for MIMO. 1763 1764 Node B shall be capable of applying different power offsets (w.r.t P-CPICH) to S-CPICH in MIMO mode 1765 and in non MIMO mode. This means the configured S-CPICH will be transmitted with different power 1766 depending upon whether there is any UE in MIMO mode in the cell. 1767 1768 eCEM CallP does not manage the IE “MIMO Pilot Configuration Extension” directly. CCM CallP shall 1769 provide the S-CPICH Power configured via Cell Setup or Cell Reconfiguration Request with: 1770

• Value from “S-CPICH power” IE if there is no MIMO call in the cell 1771 • Value from “Power Offset For Secondary CPICH for MIMO” if there is at least one MIMO call in 1772

the cell. 1773 1774 Cell Reconfiguration 1775 1776 See section 4.1.2.4 for NBAP checks to be done. 1777 1778 In complement to these checks: 1779 1780




Err_Mess 4.6.2.2-3 1781 If Node B receives “Transmit Diversity Indicator” for S-CPICH set to ‘active’ it shall send a NBAP CELL 1782 RECONFIGURATION FAILURE” with “Radio Network Layer Cause” set to “Requested Tx Diversity 1783 Mode not supported” (VAM and Transmit Diversity are exclusive). 1784 1785 If all the checks pass then CCM CallP shall proceed with the procedure and send the related ITF2 1786 request message to eCEM CallP 1787 1788 When CCM CallP received the ITF2 Cell Reconfiguration Response message from the eCEM it shall 1789 propagate the response to the RNC in the NBAP Cell Reconfiguration Response message. 1790 1791 Radio Link Setup 1792 1793 See section 4.1.2.4 for NBAP checks to be done. 1794 1795

Err_Mess 4.6.2.2-4 1796 If the Local cell is not MIMO-capable then CCM CallP shall reject the procedure by sending a Radio 1797 Link Setup Failure with cause “MIMO not available” 1798 1799

Err_Mess 4.6.2.2-5 1800 If the RADIO LINK SETUP REQUEST message contains the MIMO Activation Indicator IE and/or 1801 Sixtyfour QAM Usage Allowed Indicator IE set to "Allowed", but does not contain the HS-DSCH MAC-d 1802 PDU Size Format IE set to "Flexible MAC-d PDU Size", then CCM CallP shall reject the procedure using 1803 the RADIO LINK SETUP FAILURE message with “Protocol Cause” set to “Semantic error”. 1804 1805

Err_Mess 4.6.2.2-6 1806 If the RADIO LINK SETUP REQUEST message contains the MIMO Activation Indicator IE and Sixtyfour 1807 QAM Usage Allowed Indicator IE set to "Not Allowed", but does not contain the “HS-PDSCH Physical 1808 Layer Category “ IE in the range [15, 20] then the Node B shall reject the procedure using the RADIO 1809 LINK SETUP FAILURE message with “Protocol Cause” set to “Semantic error”. 1810 1811

Err_Mess 4.6.2.2-7 1812 If the RADIO LINK SETUP REQUEST message contains the MIMO Activation Indicator IE and Sixtyfour 1813 QAM Usage Allowed Indicator IE set to "Allowed", but does not contain the “HS-PDSCH Physical Layer 1814 Category “ IE in the range [19, 20] then the Node B shall reject the procedure using the RADIO LINK 1815

SETUP FAILURE message with “Protocol Cause” set to “Semantic error”. 1816 1817 CCM CallP uses the Load Balancing services to allocate MIMO HSDPA resources. 1818 1819

Err_Mess 4.6.2.2-8 1820 In case of allocation failure when max number of MIMO users on one eCEM exceeds the limit, CCM 1821 CallP shall reject the procedure using Radio Link Setup Failure with cause “FDD - MIMO Not Available” 1822 when the RL is MIMO. 1823 1824 If all checks pass then CCM CallP shall send the related ITF2 request message 1825 (CEM_xxx_RL_SETUP_REQ) to eCEM CallP 1826 1827 When CCM CallP received the ITF2 Radio Link Setup Response message from the eCEM it shall 1828 forward the “MIMO N/M Ratio” and the “HARQ Memory Partitioning IE” (if contained) in the HS-DSCH 1829 FDD Information Response IE of the RADIO LINK SETUP RESPONSE message to the RNC. 1830 1831 If it is the Setup of the first MIMO call configured in the cell CCM Call shall reconfigure the S-CPICH 1832 power to “¨Power Offset For S-CPICH for MIMO”. 1833 1834




Radio Link Reconfiguration Prepare 1835 1836 See section 4.1.2.6 for NBAP checks to be done. 1837 1838 When CCM CallP receives the Radio Link Reconfiguration Prepare message from eCEM at ITF2: 1839 1840

Err_Mess 4.6.2.2-9 1841 If the Local cell is not MIMO-capable then CCM CallP shall reject the procedure by sending a Radio 1842 Link Reconfiguration Failure with cause “MIMO not available” to eCEM at ITF2 1843 1844

Err_Mess 4.6.2.2-10 1845 If the concerned Node B Communication Context is configured to apply MIMO or allowed to apply 64 1846 QAM but is not configured to use flexible MAC-d PDU Size, then the Node B shall reject the procedure 1847 using the RADIO LINK RECONFIGURATION FAILURE message. 1848 1849

Err_Mess 4.6.2.2-11 1850 If the concerned Node B Communication Context is configured to apply MIMO or allowed to apply 64 1851 QAM but does not contain the “HS-PDSCH Physical Layer Category “ IE in the range [15, 20], then the 1852 Node B shall reject the procedure using the RADIO LINK RECONFIGURATION FAILURE message with 1853 “Protocol Cause” set to “Semantic error”. 1854 1855 If all the checks pass CCM CallP proceeds with the procedure and send the related ITF2 request 1856 message to eCEM CallP. 1857 1858 When CCM CallP received the ITF2 Radio Link Reconfiguration Ready message from the eCEM it shall 1859 forward the “MIMO N/M Ratio” and the “HARQ Memory Partitioning IE” (if contained) in the HS-DSCH 1860 FDD Information Response IE in CEM_RL_RECONF_READY message to eCEM CallP. 1861 1862 Radio Reconfiguration Commit 1863 1864 If the Radio Link Reconfiguration Commit leads to Setup the first MIMO call in the cell, CCM Call shall 1865 reconfigure the S-CPICH power to “¨Power Offset For S-CPICH for MIMO” when receiving 1866 CEM_RL_RECONF_COMMIT_HSPA_IND (see use case section ). 1867 1868 If the Radio Link Reconfiguration Commit leads to delete the latest MIMO call in the cell then CCM Call 1869 shall reconfigure the S-CPICH power to “Secondary CPICH Power” when receiving 1870 CEM_RL_RECONF_COMMIT_HSPA_IND (see use case section 4.5.14) 1871 1872 Radio Link Addition (not supported) 1873 1874 See section 4.1.2.7 for NBAP. 1875 1876 Radio Link Deletion 1877 1878 If the Radio Link Deletion leads to delete the last MIMO call in the cell then CCM Call shall reconfigure 1879 the S-CPICH power to “Secondary CPICH Power” when receiving CEM_RL_DELETION_HSPA_RSP 1880 (see use case section 4.5.14) 1881 1882

4.6.2.3 S-CPICH power offset reconfiguration proced ure 1883

CCM CallP shall manage the S-CPICH power as defined in section 4.1.2.8. 1884 1885 CCM CallP shall generate a CemScpichPowerOffsetReconfReq message with parameter “Secondary 1886 CPICH Power” filled with Secondary CPICH Power or Power Offset For Secondary CPICH for MIMO 1887 (see use case 4.5.20) 1888




1889 S-CPICH power offset reconfiguration procedure is triggered by CCM CallP: 1890

• After CCM CallP has sent the Radio Link Setup Response message to the RNC if it is the Setup 1891 of the first MIMO Call in the cell CCM CallP shall reconfigure the S-CPICH power offset to 1892 “Secondary CPICH Power”. 1893

• After CCM CallP has received a CEM_RL_RECONF_COMMIT_HSPA_IND from eCEM CallP: 1894 o if it is the Setup of the first MIMO Call in the cell CCM CallP shall reconfigure the S-1895

CPICH power offset to “Power Offset For Secondary CPICH for MIMO”. 1896 o if it is the deletion of the last MIMO Call in the cell CCM CallP shall reconfigure the S-1897

CPICH power offset to “Secondary CPICH Power”. 1898 • After CCM CallP has received a CEM_RL_DELETION_HSPA_RSP from eCEM CallP if it is the 1899

deletion of the last MIMO Call in the cell CCM CallP shall reconfigure the S-CPICH power offset 1900 to Secondary CPICH Power. 1901

• After CCM CallP has received a OMIU_MODIFY_LOCAL_CELL_REQ from CCM OAM: 1902 o If MIMOActivation = false CCM CallP shall reconfigure the S-CPICH power offset to the 1903

“minimum value”. 1904 o If MIMOActivation = true CCM CallP shall reconfigure the S-CPICH power offset to 1905

“Secondary CPICH Power”. 1906 1907 eCEM CallP shall answer with a CemScpichPowerOffsetReconfRsp message if it is successful. 1908 1909 If eCEM CallP sends a CemScpichPowerOffsetReconfFail or if there is no response from the eCEM 1910 (Time Out) CCM CallP shall send a RESET_SLAVE_BOARD_IND to CCM OAM (existing behavior). 1911 1912 To minimize performance impacts CemScpichPowerOffsetReconfReq message in sent only to eCEM 1913 board which manage the PSB channels contrary to CemCellSetupReq and CemCellReconfReq 1914 messages which are sent to all the eCEM boards managing the frequency. 1915 1916 In case of relocation of PSB the existing CemPsbSetupReq message shall be enhanced to provide the 1917 S-CPICH power offset to be used in the cell. eCEM CallP shall use this S-CPICH power offset to 1918 configure the S-CPICH in PQ3/CE. 1919 1920 In case of Cell Reconfiguration Request from the RNC the existing CemCellReconfReq message shall 1921 be enhanced to provide the S-CPICH power offset to be used in the cell. eCEM CallP shall use this S-1922 CPICH power offset instead of the one provided in ASN1 message from RNC to configure the S-CPICH 1923 in CE Controller. 1924

4.6.2.4 Transmit Carrier Power Measurement 1925

The common NBAP measurement Transmit Carrier Power (TCP) is managed by CallP. TCP 1926 measurement result is given as a percentage of the maxTxPower configured by RNC. In a Vam or 1927 VamAndMimo cell the power is balanced on the two PA then: 1928 TCP cell = (TCP_MAIN + TCP_DIV)/2 = TCP_MAIN = TCP_DIV 1929 1930 Launching the measurement on the Main path (TRM, RRH, TRDU or MC-TRX) is sufficient to report the 1931 good result. 1932 1933 CCM CallP shall use the information provided by CCM CallP in OMIU_ADD_LOCAL_CELL_REQ and 1934 OMIU_MODIFY_LOCAL_CELL_REQ to know which the TX Main is. The detailed content of these 1935 messages needs further investigations (see open issue [2]). 1936




4.6.2.5 Load Balancing impacts 1937

The Load Balancing (LB) entity needs to manage allocation/de-allocation of HSDPA resources for 1938 MIMO calls. Each MIMO call costs 2 HSDPA resources compared to a non MIMO call even if only one 1939 OCP resource is allocated in the Channel Element 1940 1941 The capacity of the eCEM board is impacted in term of the number of HSDPA users that can be 1942 supported and LB shall verify that: 1943 1944

• nb of single HSDPA users + 2 x nb of DC-HsdpaMIMO users <= 128 1945 • nb of MIMO users + nb of DC-HSDPA users <= MIN 1946

( 1947 dualCellHsdpaMimoMaxNumberUserEcem, 1948 internalMaxDualCellHsdpaMIMOUsersAllowed 1949 ) 1950

1951 Where: 1952

• nb of single HSDPA users : number of HSDPA users which are not MIMO or DC-HSDPA users 1953 • nb DC-HsdpaMIMO : combined number of Dual Cell HSDPA and MIMO users. 1954

1955 1956 Parameter internalMaxDualCellHsdpaMIMOUsersAllowed is received in Capacity Response 1957 message from eCEM boards. See section 6.1.7. 1958 1959 Parameter dualCellHsdpaMimoMaxNumberUserEcem is a new OAM parameter introduced for 1960 Dual-Cell and MIMO features (i. e. one single parameter shared by the 2 features). See section 1961 6.1.7. 1962 1963 If S-CPICH has different SF Code, then may be extra resources shall be allocated on CE for S-1964 CPICH, see open issue [9]. 1965 1966 The latest inputs from CE design indicate that the resource needed in the uplink is not the same for 1967 MIMO and DualCell calls (only 1 resource for MIMO calls). This may impact to the definition of the 1968 common DualCell + MIMO parameters. See open issue [14]. 1969 1970




4.6.3 eCEM/Modem Controller 1971

4.6.3.1 SLOAM 1972

SLOAM shall forward LocalCellConfigRequest message received from CCM OAM to Modem Controller 1973 (OAL part) 1974 SLOAM shall forward LocalCellConfigResponse message received from OAL to CCM OAM. 1975 1976 SLOAM shall forward HsdpaConfigRequest message received from CCM OAM to Modem Controller 1977 (OAL part) 1978 SLOAM shall forward HsdpaConfigResponse message received from OAL to CCM OAM. 1979

4.6.3.2 OAL 1980

OAL shall process the new parameters of LocalCellConfigRequest message (see section: 5.2.3). 1981 OAL checks the range of the parameters and sends back a LocalCellConfigResponse Nack in case of 1982 error. 1983 If checks are successful OAL propagates these parameters to CCC and sends back a 1984 LocalCellConfigResponse Ack to CCM OAM via SLOAM. 1985 1986 OAL shall process the new parameters of HsdpaConfigRequest message (see section: 5.2.3). 1987 OAL checks the range of the parameters and sends back a HspdaConfigResponse Nack in case of 1988 error. 1989 If checks are successful OAL propagates these parameters to CCC and sends back a 1990 HspdaConfigResponse Ack to CCM OAM via SLOAM. 1991 1992 New tunables for MIMO Ack/Nack thresholds are defined in CPIF interface (see section 5.2.4) and are 1993 provided by AO MCtl to CCC at eCEM startup. 1994

4.6.3.3 NBAPR 1995

NBAPR shall decode MIMO cell aspects in NBAP procedures at ITF2: 1996 1997

• Cell Setup Request, Cell Reconfiguration Request 1998 o MIMO Pilot Configuration 1999 o Secondary CPICH Information 2000 o MIMO Pilot Configuration Extension 2001

2002 NBAPR shall decode MIMO UE aspects in NBAP procedures at ITF1 and ITF2: 2003 2004

• Radio Link Setup Request 2005 o IE MIMO Activation Indicator 2006

• Radio Link Reconfiguration Prepare 2007 o MIMO Activation Indicator 2008 o MIMO Mode Indicator (in HS-DSCH Info to Modify). 2009

• Radio Link Addition Request (see: note) 2010 o IE MIMO Activation Indicator 2011

2012 NBAPR shall propagate new internal message ScpichPowerOffsetReconfReq to CCC. 2013 2014 NBAPR shall redo all the semantics checks of the NBAP protocol (see section 4.1.2) when possible 2015 even if already done by CCM CallP (see open issue [7]). 2016 2017 eCEM CallP is not aware of the MIMO Capability of the cell. NBAPR shall rely on CCM CallP to check 2018 the MIMO capability of the cell (ie: not checked by eCEM CallP) and to reject the procedure if 2019 necessary. 2020




2021 eCEM CallP does not manage the IE “MIMO Pilot Configuration Extension” nevertheless NBAPR can 2022 verify the semantic of the IE in conformance to 3GPP NBAP (already done by CCM CallP) but does not 2023 propagate it to CE Controller. 2024 2025 If all checks pass NBAPR shall forward the Cell Setup Request/Reconfiguration Request to CCC. 2026 2027 If all checks pass NBAPR shall forward the Radio Link Setup Request or Radio Link Reconfiguration 2028 Prepare to DCC. 2029 2030 When receiving the response from DCC NBAPR shall encode MIMO aspects in NBAP procedures at 2031 ITF1 and ITF2: 2032 2033

• Radio Link Setup Response, Radio Link Reconfiguration Ready,Radio Link Setup Failure: 2034 o IE HARQ Memory Partitioning 2035 o IE MIMO N/M Ratio 2036

4.6.3.4 BRM 2037

BRM needs to manage allocation/de-allocation of HSDPA resources for MIMO calls. Each MIMO call 2038 costs 2 HSDPA resources compared to a non MIMO single cell call even though only one HSD BBR 2039 resource is allocated for a MIMO call. 2040 The coast being the same for DualCell and MIMO calls, the same operations have to be performed for 2041 DualCell and MIMO. 2042 But in order to make easier code evolutions, it is recommended to distinguish DualCell and MIMO calls 2043 with separated objects “HSD MIMO” and “HSD DualCell”. This appears in figures in chapter Uses 2044 Cases. 2045 The number of HSDPA users allocated on an eCEM is verified by the Load Balancing (see section: 2046 4.6.2.4) nevertheless BRM shall verify that: 2047

• Nb of single HSDPA users + 2 * nb of DualCellHsdpaMIMO users <= 128 2048 • Nb of DualCellHsdpaMIMO users <= num_dual_cell_hsdpa_MIMO_users 2049

2050 Where num_dual_cell_hsdpa_MIMO_users indicates the maximum combined number of DualCell and 2051 MIMO calls that can be supported by eCEM board. BRM retrieves this parameter from UCU Manager 2052 via UcuMgrGetCeCapabilityResp message and propagates it to CCM CallP in CemCapacityResp 2053 message. 2054 This parameter has already been introduced with feature DualCell capacity Increase. 2055 2056 Note: the verification at the BRM level only takes into account the physical limitations of the eCEM, the 2057 limitation introduced by OAM parameter dualCellHsdpaMimoMaxNumberUserEcem is not concerned. 2058 2059 Normally as this check has already been done by LB on CCM then allocation/de-allocation should be 2060 always successful. Nevertheless on a ResourceReq message from DCC in case of no available 2061 resource BRM answers by a Resource Failure. 2062 2063 The interface between DCC and BRM needs to evolve for resource allocation/de-allocation for MIMO 2064 calls. 2065 The following proposal is compliant with DC-HSDPA introduction: 2066

• Resource-Request (HSD, Normal): This would indicate to BRM to allocate 1 HSDPA resource 2067 for single cell HSDPA setup as done today. (R99 => non MIMO HSDPA scenario) 2068

• Resource-Request (HSD, MIMO): This would indicate to BRM to allocate 2 HSDPA resources 2069 for MIMO setup. (R99 => MIMO scenario) 2070

• Update Resource-Request (HSD, MIMO, ResourceId): This would indicate to BRM to allocate 2071 1 more HSDPA resource for Reconfiguration of the call from non MIMO to MIMO. The 2072 parameter “ResourceId” would tell the resource Id of previously established HSDPA call. (non 2073 MIMO => MIMO scenario) 2074




• Update-Resource-Request (HSD, Normal, ResourceId): This would indicate to BRM to de-2075 allocate HSDPA resource for MIMO removal. The parameter “ResourceId” would tell the 2076 resource Id of previously established single cell HSDPA call. (MIMO => non MIMO scenario) 2077

• Resource-Release-Ind (HSD): This would indicate to BRM to de-allocate all HSDPA 2078 resources. (1 HSDPA resource for SC-HSDPA or 2 HSDPA resources for MIMO) 2079

2080 Note: The terminology “Normal” is used here to indicate a single cell HSDPA call (i.e. non MIMO 2081 HSDPA call) 2082 2083

4.6.3.5 CCC 2084

CCC shall propagate the VAM configuration received in LocalCellConfigRequest message received 2085 from CCM OAM via OAL to Cell BBR via UcuMgrCellCreateReq/ UcuMgrCellUpdateReq message. 2086 2087 CCC shall propagate tunables MIMO Ack/Nack thresholds retrieved from AO MCtl to Cell BBR in 2088 UcuMgrCellCreateReq message. 2089 2090 CCC shall process “S-CPICH Information” IE contained in Cell Setup Request (respectively Cell Setup 2091 Reconfiguration Request) and propagate the S-CPICH information via PsbCellSetupReq (respectively 2092 PsbCellReconfReq) message to the PSB BBR. 2093 2094 CCC shall process “S-CPICH Power Offset” parameter contained in CemScpichPowerOffsetReconfReq 2095 and propagate the information via PsbCellReconfReq message to the PSB BBR. 2096 2097 CCC shall propagate the new parameters received from OAL to CE Controller (HSDPA BBR) via CPIF 2098 messages in: 2099 2100

• HsdpaPhySharedChannelSetupReq when receiving a PSCR (setup) from CCM CallP 2101 • HsdpaSchedulerParamUpdateReq when receiving an update of these parameters and when 2102

the HSDPA BBR is already configured (ie : PSCR already received) 2103

4.6.3.6 DCC 2104

DCC shall use the BRM allocation/de-allocation messages enhanced to managed MIMO users (see 2105 section 4.6.3.4) 2106 2107 DCC shall request a HSD-BBR to BRM when MIMO is configured via a Radio Link Setup or a Radio 2108 Link Reconfigure. In case of Resource Failure from BRM DCC shall fail the procedure with a Radio Link 2109 Setup Failure or a Radio reconfiguration Failure. 2110 2111 DCC shall provide MIMO IE’s decoded by NBAPR to HSD-BBR at CPIF interface in the relevant 2112 messages: 2113 2114

• MIMO Activation Indicator in HsdSetupReq, HsdSetupPrepReq, HsdReconfPrepReq, 2115 HsdMigrationPrepareReq 2116

• MIMO Mode Indicator in HsdReconfPrepReq 2117 2118 DCC shall provide MIMO IE’s received from HSD-BBR at CPIF interface to be encoded by NBAPR in 2119 the relevant messages: 2120 2121

• MIMO N/M Ratio and HARQ Memory Partitioning in HsdSetupResp, HsdSetupPrepResp, 2122 HsdMigrationPrepareResp, HsdReconfPrepResp, RLSetupFailure. 2123

2124




4.6.4 eCEM/CE Controller 2125

4.6.4.1 Control Plane 2126

4.6.4.1.1 UCU Manager 2127

The UCU Manager is responsible for managing all resources on the UCU, namely the BBRs, CEs and 2128 cells. The BBRs are managed with the help of the various BBR objects, each CE with the help of a CE 2129 Manager and each cell with the help of a Cell Manager. 2130 For setting up cells the UCU Manager forwards Cell Create Requests to one of the Cell Manager 2131 instances depending on the cell index. 2132 2133 The Cell Manager class stores cell related parameters, namely all information that is received in the Cell 2134 Create Request and in the Cell Update Request. 2135 2136 Since the SCPICH Setup Request (see 4.6.4.1.2) contains the new parameters 2137 Tx_Accumulator_Indicator with the value Tx_accumulator_B (see 4.6.5.3), this one must be configured 2138 in the CellHwConfigSetupReq as it is currently done for the Tx_accumulator_A. These two parameters 2139 indicate the stream index associated to the primary and secondary antenna stream (respectively 2140 Tx_accumulator_a and Tx_accumulator_b). As explained in the section 4.6.5.4, these two values will be 2141 used to inform the VAM Stream Pair Selection parameter provided to the CE by the PQ3 (see the 2142 paragraph following). 2143 2144 The CellConfigReq contains a new parameter, CQI Delay Distance for MIMO users. The value of this 2145 field shall be the same that the CQI Delay Distance use for legacy users. 2146 2147 Cell Manager shall use the InternalDualPaUsage, VAMAmplitudeCoeff and VAMPhaseCoeff to 2148 configure the VAM accordingly (see section: 4.6.1.10) 2149 2150 These parameters are used to inform new ones in the CE (see section 4.6.5.6 and [R13] table 15-3) : 2151 - VAM Coefficients, Float 0..1 step 0.000000001 obtained thanks to the polar to cartesian 2152 conversion. (see section 4.6.5.7) for details concerning the calculation and the PA failure case). The 2153 calculation is detailed below. 2154 - VAM Stream Pair Selection (2*stream indexes with the stream index a number between 0 and 2155 11) corresponds to the value of the Tx_accumulator_a and the Tx_accumulator_b (see section 4.6.5.7 2156 for details) 2157

- Update_flag: Boolean to indicate to the CE a new update of the VAM coefficient. 2158 These parameters are available thanks to a dedicated access to the FPGA Combiner. This 2159 development is provided by BCS Platform. 2160 2161 The PQ3 provides to the CE a 2x2 complex matrix. 2162

++++

=

=

)4sin4(cos4)3sin3(cos3

)2sin2(cos2)1sin1(cos1

2221

1211

φφφφφφφφ

jaja

jaja

vv

vvientsVAMCoeffic 2163

The recommend values are described in the section 6.1.2. 2164




In case of one PA failure, the VAM Coefficients to provide to the CE shall be: 2165

If 1st Tx branch failure: VAM Coefficients =

=

00

10

2221

1211

VV

VV 2166

If 2nd Tx branch failure: VAM Coefficients =

=

00

01

2221

1211

VV

VV 2167

New Hsdpa ACK/NACK thresholds (see section 5.2.4) provided in UcuMgrCellSetupReq message and 2168 used by HSD-BBR (see section 4.6.4.1.4) shall be stored in cell related parameters. 2169 2170 At eCEM startup UCU Manager shall fill the “maxDualCellHsdpaMIMOUsersAllowed” with the capacity 2171 of the board (see section 4.8.3) that can be supported on the eCEM board in 2172 UcuMgrGetCeCapabilityResp message sent to eCEM CallP in response to UcuMgrGetCeCapabilityReq 2173 message. 2174 2175 There is a new parameter “IsPrecodingWeightSetRestrictionPreferred” in the UcuMgrCellCreateReq 2176 message (CellParamInd structure) and UcuMgrCellUpdateReq message(CellUpdate structure). This 2177 parameter is forwarded to the mac-ehs scheduler. 2178 2179

4.6.4.1.2 PSB BBR 2180

A pilot/sync/broadcast (PSB) BBR instance is responsible for providing the synchronization channel 2181 (SCH), primary common pilot channel (PCPICH), secondary common pilot channel (SCPICH), and 2182 primary common control physical channel (PCCPCH). 2183 2184 On reception of a PSB cell setup request or a PSB cell reconfigure request, the PSB BBR take into 2185 account Secondary CPICH Power (in Secondary CPICH Information structure). 2186 2187 Currently, the parameters are not transmitted from the eCEM CallP to the PQ3 over CPIF. A structure 2188 must be added in PQ3 CPIF interface in the common data, in the PsbCellReq structure: 2189 secondaryCPICHInformation (optional) refer to 5.2.4 ITF7: CPIF. 2190 The structure secondaryCPICHInformation shall be used to fill the structure sent to CE in SCPICH 2191 Setup Request or SCPICH Reconfiguration Request (existing messages not used up to now) 2192 2193 In the SCPICH Setup Request, a new field TA(Tx_Accumulator_Indicator) is added and corresponds to 2194 the value Tx_accumulator_B. The field Transmit_Diversity_Indicator shall be put to inactive.(see section 2195 4.6.5.3). 2196 2197 Cell Reconfiguration 2198 2199 PSB BBR does not manage the IE “MIMO Pilot Configuration Extension” directly (see section 4.6.2.2). 2200 eCEM CallP shall provide the S-CPICH Power configured via PsbCellSetupReq or PsbCellReconfReq 2201 with “Secondary CPICH Power set : 2202 2203

• To “S-CPICH power” IE if there is no MIMO call in the cell 2204 • To “Power Offset For Secondary CPICH for MIMO” if there is at least one MIMO call in the cell. 2205 • To “minimum value” when the cell has lost the MIMO capability. 2206

2207 PSB BBR shall update the CE via SCPICH Reconfiguration Request message. 2208 2209




4.6.4.1.3 HSDPA BBR 2210

The HSDPA BBR instance is responsible for providing the resources to support the HSDPA Shared 2211 Channels (HS-SCCHs and HS-PDSCH) for one cell. 2212 2213 Within the PhysicalSharedChannelSetup message, it receives the information that is necessary to 2214 configure the MAC-hs and OC+ CE. This is mainly information about the OVSF codes as well as the 2215 total transmit power for HSDPA. 2216 The PhysicalSharedChannelSetup and HsdpaSchedulerParamUpdateReq contain a HsdpaCellParams 2217 field where ncqiTypeAMCqiRatio(which be used in the response structure), 2218 hsScchType3SingleStreamSnr and hsScchType3DualStreamSnr are used to calculate HS-SCCH 2219 power. 2220 2221 MAC-ehs shall calculate the demanded power taking into account the two Tx branches in case of MIMO 2222 (see section 4.6.4.2.1). HSDPA BBR shall use the field InternalDualPaUsage part of 2223 UcuMgrCellCreateReq or UcuMgrCellUpdateReq message to know which Tx branches are valid in 2224 PMM cells received from CCM concerning the demanded power: 2225

• VamDisabled : Main branch 2226 • VamEnabled : Main and Diversity branches 2227 • VamDegradedToMainOnly : Main branch 2228 • VamDegradedToDivOnly : Diversity branch 2229

2230 The PMM cells are managed by the BCS Platform so this information would be usefull for the platform 2231 when decoded the PMM cells.(to be verify!!) 2232 2233 Fault management: case of one of the Tx branch fails and failure recovery 2234 2235 The CRNC shall recalculate max HSDPA power (corresponds to HS-PDSCH, HS-SCCH, E-AGCH, E-2236 RGCH, and E-HICH total power IE) according to the new Maximum Transmission Power (Reconfigured 2237 with NBAP CELL RECONFIGURATION REQUEST). This new max HSDPA power is reconfigured using 2238 PhysicalSharedChannelReconfiguration procedure. 2239 2240 As soon as a PA failure is detected thanks to the variable “internalDualPaUsage”, the BBR updates the 2241 maxTxPower (received in UcuMgrCellUpdateReq) and max HSDPA power dividing it by two (the 2242 scheduler can react quickly and we don’t wait for the HsdpaPhysicalShareChannelReconfReq which is 2243 optional). Then if HsdpaPhysicalShareChannelReconfReq is received, the BBR takes into account the 2244 new value of max HSDPA power. The SINGLE_STREAM_ONLY flag will be set to TRUE and the 2245 indication of PA failure is sent to BCS platform to update the Tx Branches to use. 2246 The HSDPA BBR shall send the information to HSD BBR to update the maximum bit rate in the framing 2247 protocole for this UE. 2248 When PA recovery is detected thanks to to the variable “internalDualPaUsage”, the BBR updates the 2249 maxTxPower (received in UcuMgrCellUpdateReq) and max HSDPA power multiplicating the actual 2250 value by 2 (it permits to react as HsdpaPhysicalShareChannelReconfReq is optional). Then if 2251 HsdpaPhysicalShareChannelReconfReq is received, the BBR takes into account the new value of max 2252 HSDPA power. 2253 The scheduler takes into account the indication of PA recovery provided by the HSDPA BBR and no 2254 more forces the SINGLE_STREAM_ONLY flag. 2255 BCS platform will use the new indication to update the Tx Branches to use. 2256 2257

4.6.4.1.4 HSD BBR 2258

The HSD BBR instance is responsible for providing the dedicated resources to support the HSDPA 2259 connection for an individual UE. 2260

HSD Setup / HSD Setup Prep 2261




HSDSetupReq : On response to a NBAP Radio Link Setup or NBAP Radio Link Reconf. 2262

HSDSetupPrepReq : On response to a NBAP Radio Link Reconfiguration. Request which results to the 2263 addition of a HSD radio link to the already existing DCH connection. 2264

For the call setup, the two possibilities can be encountered. 2265

2266

At HSD Setup, the HSD BBR checks whether the HsdInformationMimoActivationIndicatorPresent flag is 2267 present or not. - If present, MIMO shall be activated, the MIMO usage bit in the UE context is set to 2268 “true” and the response message includes the “HsdInfoResponse” IE with “nCQITypeAMCqiRatio” and 2269 the Number of Processes in “HarqMemory-Partitioning”. In case of use of Harq Memory Partitioning 2270 explicit, the field “HarqMemoryPartitioningInfoExtensionForMIMO” (optional) shall be included in 2271 HarqMemoryPartioningExplicit. (Today, only the Harq Memory Partitioning mode implicit is supported.) 2272

2273

The HSD BBR checks whether the “SixtyfourQamUsageAllowedInd” is present or not. If it is present, the 2274 64QAM usage bit in the UE context is set to “true” and “sixtyfourQamDlUsageInd ” IE is included in the 2275 response message with value “SixtyfourQamDlUsed ”. 2276

The presence of MAC-ehs mode (HS-DSCH MAC-d PDU Size Format present in the “HS-DSCH 2277 Information’ with the value “Flexible MAC-d PDU Size) and the test on the category (“HS-PDSCH 2278 Physical Layer Category” IE with a value of 15, 16, 17, 18, 19 or 20 and a value of 19 or 20 for MIMO + 2279 64QAM) are done by CCM CallP (see section 4.6.2.2). It might be necessary to repeat these checks at 2280 PQ3 side in order to detect the inconsistencies in PQ3 specific test environment. The decision is left to 2281 the development team. 2282

HSD Reconf 2283

For a call reconfiguration from MIMO to NON-MIMO, on a NBAP radio link reconfiguration, the field 2284 MimoModeIndicator contained in HsdDschInfoToModify is set to ‘MimoModeIndicatorDeactivate. The 2285 MIMO usage bit is set to “false” in the UE Context and MIMO shall be deactivated. 2286

The HsdReconfPrepResp does not include the nCqiTypeAMCqiRatio in HsdInfoResponse and the 2287 Number of Processes contained in HarqMemoryPartitioning corresponds to the non-MIMO scenario. In 2288 case of use of Harq Memory Partitioning explicit, the structure HarqMemoryPartitioningExplicit does not 2289 include the “HarqMemoryPartitioningInfoExtensionForMimo” field. (Today, only the Harq Memory 2290 Partitioning mode implicit is supported.) 2291

For an Intra NodeB Cell Change Procedure with both source and target cells are MIMO capable and 2292 MIMO configured on the call, the field MIMO Mode Indicator shall not be include in 2293 HsdDschInfoToModify. 2294

For a call reconfiguration from NON-MIMO to MIMO, the field MimoModeIndicator contained in 2295 HsdDschInfoToModify is set to ‘MimoModeIndicatorActive”. The MIMO usage bit is set to “true” in the 2296 UE Context and MIMO shall be activated. 2297

The HsdReconfPrepResp includes nCqiTypeAMCqiRatio in HsdInfoResponse and the number of 2298 Processes contained in HarqMemoryPartitioning corresponds to the MIMO scenario. In case of use of 2299 Harq Memory Partitioning explicit, the field “HarqMemoryPartitioningInfoExtensionForMIMO” (optional) 2300 shall be included in HarqMemoryPartioningExplicit. (Today, only the Harq Memory Partitioning mode 2301 implicit is supported.) 2302

In the configuration message sent to the CE, new parameters shall be added (see section 4.6.5.6) : 2303

• MIMO Activation (Boolean) set according the MIMO usage bit of the UE Context 2304

• MIMO N/M Ratio (Index to N/M Ratio table) 2305

• Dual ACK/NACK Threshold (5*16bits values) provided by the field HsdpaUcuParams during the 2306 cell create (see section 4.6.4.1.1). 2307

HSD Migration 2308




In response of an NBAP Radio Link Reconfiguration Request that demands a change of HSDPA Cell, 2309 this news HSDPA cell is served by a scheduler on another modem controller. 2310 At Hsd Migration Prepare, the HSD BBR checks whether the “MimoActivationIndicator” is set to true or 2311 false. 2312

- If true, MIMO shall be activated, the MIMO usage bit in the UE context is set to “true” and the response 2313 message includes the “HsdInfoResponse” IE with “nCqiTypeAMCqiRatio” and the Number of Processes 2314 in “HarqMemoryPartitioning”. In case of use of Harq Memory Partitioning explicit, the field 2315 “HarqMemoryPartitioningInfoExtensionForMIMO” (optional) shall be included in 2316 HarqMemoryPartioningExplicit. (Today, only the Harq Memory Partitioning mode implicit is supported.) 2317

The HSD BBR checks whether the “SixtyfourQamUsageAllowedInd” is present or not. If it is present, the 2318 64QAM usage bit in the UE context is set to “true” and “sixtyfourQamDlUsageInd ” IE is included in the 2319 response message with value “SixtyfourQamDlUsed ”. 2320

2321

4.6.4.1.5 BBR Monitor 2322

The BBR Monitor shall support the CDM changes for this feature (se section 9.2). 2323

ExtendedTbSize: With MIMO, MAC-ehs scheduler shall support TB size up to 27464 bits with 16 QAM 2324 and 42192 bits with 64 QAM. 2325 The measurements for the two transport blocks for one user in case of dual stream. 2326 The measurement of the ratio in percentage between dual stream transmission out of the total (single 2327 and dual stream) transmission per TTI shall be forwarded through CPIF (see 5.2.4) 2328 2329

4.6.4.2 User Plane 2330

4.6.4.2.1 HSDPA Scheduler 2331

MIMO is supported by the MAC-ehs scheduler 2332

The impacts on the MAC-ehs scheduler: 2333

• HARQ Process 2334

• A flag to indicate if the MIMO user is in single stream transmission or not 2335

• User ranking – SINR - SE – TFRC – Channel rate 2336

• Transport Format Selection 2337

• BLER Control Loop (not supported in UA8.0) 2338

• HS-PDSCH power allocation 2339

• HS-SCCH power allocation 2340

4.6.4.2.1.1 PARAMETER UPDATES 2341

There are two new parameters provided by HSDPA BBR(see section 4.6.4.1.3): 2342

• HsScchType3SingleStreamSnrt defines the additionnal SNR requirement due to higher code 2343 rate of HS-SCCH type 3 of single stream transmission. Used to Calculate the required HS-2344 SCCH power Ptx

HS-SCCH 2345

• HsScchType3DualStreamSnr defines the additional SNR requirement due to higher code rate of 2346 HS-SCCH type 3 of dual stream transmission. Used to Calculate the required HS-SCCH power 2347 Ptx

HS-SCCH 2348




4.6.4.2.1.2 CALCULATE CELL POWER MEASUREMENTS 2349

CCM reports eCEM periodically with demanded power PCell. In a VAM capable cell (sector-carrier, 2350 MIMO or non-MIMO), the demanded power shall be based on both Tx branches (i.e. PA1+PA2). There 2351 is no impact in the scheduler with the introduction of VAM. 2352

In case of one Tx branch failure, the reported power is from the working Tx branch (i.e either PA1 or 2353 PA2, whichever is working). 2354

4.6.4.2.1.3 UL PROCESSING 2355

The Channel Element (CE) shall provide following information to the HsScheduler every TTI: 2356

- Flag to indicate Type-A or Type-B CQI/PCI report (not used by the scheduler see section 4.6.5.5.4) 2357

- Flag to indicate single or dual stream CQI/PCI report (SS/DS see section 4.6.5.5.4) 2358

- CQI_predicted (EcNt format, as done for legacy HSDPA scheduler) (one value for single stream 2359 (CQI_S) and two values for dual stream CQI_1 and CQI_2 see section 4.6.5.5.4) 2360

- An index into the precoder codebook (PCI) 2361

- One set of (cqi_mean, NMSE, NVAR) if single/dual stream CQI/PCI. 2362

The timing constrains concerning the CQI measurement delay (the delay from the start of the CQI 2363 measurement period in the UE to the start of the TTI in which the corresponding DL HS-PDSCH 2364 transmission occurs) for MIMO users shall be same as legacy users. The CQI value shall be provided 2365 with a delay of 9ms for all MIMO and non MIMO users. 2366

- Two ACK/NACK in case of dual stream 2367

The content of the ACK/NACK packet is described in section 4.6.5.5.3. Three ACK/NACK fields are 2368 received (in MIMO, the CE does not perform hard decision regarding ACK/NACK for single and dual 2369 streams and this decision is left to scheduler. It means the CE does not know if it is a single or dual 2370 stream transmission). The scheduler shall have memorised the flag single/dual stream for the 2371 transmission corresponding to know which field(s) to use. 2372

The content of the CQI packet is described in section 4.6.5.5.4. A test is done on the SS/DS field to 2373 know which CQI fields to use. In case of single stream, the CQI_s field shall be decoded, in case of dual 2374 stream, the CQI_1 and CQI_2 shall be decoded. The decoded CQI value(s) shall be mapped into SINR 2375 value. 2376

4.6.4.2.1.4 HARQ PROCESS 2377

The number of HARQ processes (NB_HARQ_PROCESSES) in MIMO mode = 2 * 2378 HARQ_process_mapping_table[UE Category, Number of HARQ Processes] with 2379 HARQ_process_mapping_table a NodeB tunable parameter giving the number of configured HARQ 2380 process. 2381

So MAC-ehs Scheduler shall support 12 to 16 HARQ Processes. 2382

For a scheduled user configured in MIMO mode, two HARQ processes are pre-selected (see TN-MAC-2383 hs-803). 2384

Harq Process 1(HP1) and HARQ Process 2 (HP2) are the two pre-selected HARQ Process. HP2 is 2385 defined by: 2386

HP2 = (HP1+ (Nproc/2)) mod (Nproc) 2387

Where Nproc is NB_HARQ_PROCESSES. 2388

The MAC-ehs scheduler must followed additional rules for the HARQ Process pre-selection phase (see 2389 TN-MAC-hs-804): 2390




In case of single stream transmission/retransmission OR no paired HARQ Processes available, the 2391 packet is set to HARQ Process 1 and HARQ Process 2 shall be empty 2392

If there is a retransmission ready to transmit, because of its priority, choose HARQ Process 1 as the 2393 process with the oldest packet. 2394

The mapping with the stream is done during TFRC phase (see section 4.6.4.2.2.2.2). 2395

4.6.4.2.1.5 COMPUTE OF A SINGLE_STREAM_ONLY FLAG (TN-MAC-HS-809) 2396

For each scheduled user configured in MIMO mode, a SINGLE_STREAM_ONLY_FLAG is 2397 computed as follows: 2398

A test is done on the flag which indicates a single or dual stream CQI/PCI report provided by the 2399 CE. If it indicates a single stream CQI/PCI report or if HP2 is not available to transmit (HP selected 2400 previously see section 4.6.4.2.1.4), then : 2401

Set SINGLE_STREAM_ONLY = TRUE for that user 2402

Else 2403

Set SINGLE_STREAM_ONLY = FALSE for that user 2404

4.6.4.2.2 UeContext 2405

4.6.4.2.2.1 UL PROCESSING 2406

In a first step, the UEContext receives the (N)ACK data. It calculates the target subframe number and 2407 check the UL sync status. 2408

Then, the UeContext performs different actions for a specific HARQ process. 2409

In MIMO mode, in case of dual stream transmission, the UeContext will contain two ACK/NACK datas 2410 with two specific HARQ Processes. The process must be done for the two ACK/NACK datas. 2411

In a second step, the UE Context receives the CQI value(s).(see UL Processing of HSDPA Scheduler 2412 section 4.6.4.2.1.3). 2413

It calculates the SINR(SINRmap(Ui)) : 2414

In MIMO mode, the existing LUT table is used for 'single transport block Type A CQI' or 'Type B CQI' 2415 (see UL Processing of HSDPA Scheduler section 4.6.4.2.1.3) testing SINGLE_STREAM_ONLY = 2416 TRUE. 2417

In MIMO mode, a new LUT table is used when 'dual Transport block Type A CQI' is reported by UE 2418 (means dual CQI/PCI report) testing SINGLE_STREAM_ONLY = FALSE. Refers to TN-MAC-hs-786 2419 for the values of this news table: 2420




2421

4.6.4.2.2.2 DL PROCESSING 2422

4.6.4.2.2.2.1 Eligibility check and resources Selection 2423

The UeContext checks for HS-PDSCH codes available. In MIMO mode, if two transport blocks are 2424 transmitted, the same set of OVSF code shall be used for both transport blocks so we check only for the 2425 primary stream. 2426

If the UE is eligible for transmission, the following steps are performed: 2427

• Calculate the required HS-SCCH power PtxHS-SCCH 2428

Because of the amount of information contained in the HS-SCCH type 3, 3 extra bits in single stream 2429 and another 8 extra bits in dual stream are needed comparing to HS-SCCH type 1. It results that 2430 additional power is required. 2431

The following equation shall be used to calculate power for HS-SCCH type 3 used with MIMO (TN-2432 MAC-hs-788): 2433

( ) ( ) ( ) ( )coeff1010iSCCH-HSidBMap,CPICHPdBmTx,SCCH_Type3-HSi

SCCHHSdBmTx, AOClog10-

16

128log10uΨuSINRΓPsnruP ⋅

⋅−+−++= −− 2434

Where, 2435

SCCH_Type3HS-snr is defined by parameter HsScchType3SingleStreamSnr (HsdpaConf) in case of single 2436

stream transmission. This parameter is defined section 4.6.4.2.1.1. 2437

SCCH_Type3HS-snr is defined by parameter HsScchType3DualStreamSnr (HsdpaConf) in case of dual 2438

stream transmission. This parameter is defined section 4.6.4.2.1.1. 2439

SINRMap,dB(ui) is as defined in [A3] #145 converted to dB. The CQI value to be considered is the latest 2440 single CQI (i.e. latest type A CQI with single TB or type B CQI). 2441

ΨHS-SCCH(ui) is as defined in [A3] #177. The input parameters to LUT, provided by CE every sub-frame, 2442 are based on latest single CQI. 2443




Γ is defined as following : 2444

dBCPICHSCPICHP

PDSCHHSMIMO PP

P

+=Γ

−−

− 2445

Where : 2446

PDSCHHSP − is the total (i.e. across both Tx branches) allocated power. 2447

PP-CPICH is the Tx power of the P-CPICH 2448

PS-CPICH is the Tx power of the S-CPICH for MIMO 2449

2450 2451

• Calculate the available HS-PDSCH power PavHS-PDSCH 2452

On a VAM capable cell (MIMO or non-MIMO), it is expected that the PA usage will be balanced 2453 between PA-1 and PA-2. Available power for HSDPA shall be based on combined power of PA1 and 2454 PA2. Under balanced PA usage (possible when all the common channels and all the existing 2455 dedicated/shared channels are transmitted through VAM), Pav

HSDPA shall be derived considering both Tx 2456 branches (i.e. PA1 +PA2) 2457

Where, PavHSDPA is available power for HSDPA considering both the Tx branches of VAM capable cell 2458

(sectorcarrier, MIMO or non-MIMO). 2459

There are additional rules to the current procedure (TN-MAC-hs-182) of allocated power to HS-PDSCH 2460 for a call configured in MIMO mode (refers to TN-MAC-hs 891). 2461 In MIMO mode, the calculation of Pav

HS-PDSCH(ui) (TN MAC-HS #183) is done as following using PavHSDPA 2462

and considering both Tx branches (i.e. PA1+PA2) : 2463 2464 2465

( ) ( )

−⋅= −−i

SCCHHSTx

HSDPAavHSDPA

avi

PDSCHHSav uPP

W

1uP 2466

2467 Pav

HSDPA shall be updated by the MAC-ehs scheduler as following (TN MAC-HS #247) whenever a user 2468 has been selected from the ranking list. Pav

HSDPA is initialised at the start of a HS-DSCH TTI according to 2469 TN MAC-HS #169. 2470 2471

( ) ( )iSCCHHS

TxiDSCHHS

TxHSDPA

avHSDPA

av uPuPPP −− −−=: 2472

2473 2474 PTx

HS-DSCH(ui) shall be calculated for MIMO or non-MIMO UE taking into account the total (i.e. across 2475 both Tx branches) allocated power. 2476 2477 PTx

HS-SCCH(ui) is total (i.e. across both Tx branches) HS-SCCH power for MIMO or non-MIMO UE. 2478 Wav

HSDPA is updated according to (TN MAC-HS #248) 2479 Note 1: In a call configured in MIMO, the transport block on each Tx Branch has the same total power 2480 allocated than the other one. Available to both single and dual stream transmissions. 2481 2482 Note 2: In case of dual stream transmission, the power per OVSF code is divided evenly among the two 2483 transport blocks. The power per OVSF code for each transport block is the same for all the OVSF codes 2484 used. The power per transport block is the same for both transport blocks. 2485 2486




Note 3: The estimated SIR is computed by the scheduler based on the CQI, which is computed at the 2487 UE assuming halving of power for dual stream transmission compared to single stream MIMO. So the 2488 UE already accounts for the fact that power is split evenly among the two codewords. 2489

2490

• Calculate SINRdB(Ui) + Map SINR vers SE (TN-MAC-hs-815) 2491

For a MIMO user, achievable spectral efficiency (SE(ui)) is computed as follows: 2492

If SINGLE_STREAM_ONLY = TRUE (see section 4.6.4.2.1.5), the spectral efficiency SE(ui) for 2493 the user is obtained using the existing algorithm and set SE(ui) = SE_single(ui) 2494

With SE(ui) obtained as follows : 2495

- First calculating the SINRdB(ui) thanks to the SINRmap(ui) (using the CQI from the 2496 latest single stream CQI report).(see the equation following or the TN-MAC-hs-815) 2497

- Then Converting SINRdB(ui) to SINR(ui) i.e. linear domain 2498

- Mapping the SINR(ui) to SE(ui) thanks to a LUT table (see TN-MAC-hs-495) 2499

If SINGLE_STREAM_ONLY = FALSE (see section 4.6.4.2.1.5), the spectral efficiency SE(ui) 2500 for the user is obtained using the existing algorithm to both stream separately and set 2501 SE(ui)=SE1(ui)+SE2(ui)=SE_dual(ui). 2502

With SE1(ui) obtained as follows : 2503

- First calculating the SINR1dB(ui) thanks to the SINRmap(ui) from the primary 2504 stream(using the CQI1 from the latest dual stream CQI report).(see the equation 2505 following or the TN-MAC-hs-815) 2506

- Then Converting SINR1dB(ui) to SINR1(ui) i.e. linear domain 2507

- Mapping the SINR1(ui) to SE1(ui) thanks to a LUT table (see TN-MAC-hs-495) 2508

With SE2(ui) obtained as follows : 2509

- First calculating the SINR2dB(ui) thanks to the SINRmap(ui) from the secondary 2510 stream(using the CQI2 from the latest dual stream CQI report).(see the equation 2511 following or the TN-MAC-hs-815) 2512

- Then Converting SINR2dB(ui) to SINR2(ui) i.e. linear domain 2513

Mapping the SINR2(ui) to SE2(ui) thanks to a LUT table (see TN-MAC-hs-495) 2514

2515 Following equation is used for MIMO UEs when single Type-A or Type-B CQI is received from UE : 2516

( ) ( ) ( ) ( ) ( )coeff10iCPICH

dBmTx,CPICHPdBmTx,i

PDSCHHSdBmav,idBMap,idB AOClog10uδΓPPuPuSINRuSINR ⋅++−−−+= −−−

S

2517

2518 Pav,dBm

HS-PDSCH is the value as taken from TN-MAC-hs-183 in dBm considering power from both PAs. 2519 PTx,dBm

S-CPICH is the Tx power of the S-CPICH for MIMO in dBm. 2520 Other terms are as defined in TN-MAC-hs-188. 2521 2522 Following equation is used for MIMO UEs when dual Type-A CQI is received from UE (applicable 2523 independently to both CQI values) : 2524

( ) ( ) ( ) ( ) ( )coeff10iCPICH

dBmTx,CPICHPdBmTx,i

PDSCHHSdBmav,idBMap,idB AOClog10uδΓPPuPuSINRuSINR ⋅++−−−+= −−−

S

2525

2526 Pav,dBm

HS-PDSCH is the value as taken from TN-MAC-hs-183 in dBm considering power from both PAs. 2527 PTx,dBm

S-CPICH is the Tx power of the S-CPICH for MIMO in dBm. 2528 Other terms are as defined in TN-MAC-hs-188. 2529




2530 Note: The equation at present is the same for single stream and dual stream transmissions in MIMO 2531

mode. It is an open issue whether to modify measurement power offset (Γ ) in accordance with reported 2532 PCI for single stream transmission in MIMO mode. If it is decided to implement this, the equations for 2533 single stream and dual stream transmissions in MIMO mode will be different as well. 2534 2535

• Calculate the CR(ui) 2536

The SE(ui) obtained is used to calculate the CR(ui) (TN MAC-HS #605) 2537

• Calculate the SEcum(Ui) 2538

• TFRC selection phase (see next point) 2539

4.6.4.2.2.2.2 TFRC Selection phase 2540

Transport format selection for a MIMO user consists of the following steps (see TN-MAC-hs-823): 2541 2542 1. Select single or dual stream transmission: 2543 testing the SINGLE_STREAM_ONLY flag for the user. If TRUE, select single stream 2544 transmissionElse, select dual stream transmission. 2545

2546 2. HARQ process to stream mapping shall use the following logic: 2547 2548 In case of single stream transmission: HARQ process HP1 is used for transmission/ retransmission. 2549

2550 In case of dual stream transmission: 2551 - if HP1 AND HP2 ready for new transmissions OR HP1 AND HP2 ready for retransmissions, set the 2552

HARQ Process with the larger block size to the primary stream. 2553 - if one HARQ process is used for a new transmission and the other one for a retransmission, set 2554

HP1(which the retransmission according to 4.6.4.2.1.5 and TN-MAC-hs-804) for primary stream and 2555 HP2 for secondary stream. 2556 2557 3. Select transport format for one transport block in case of single stream and transport formats for two 2558 transport blocks in case of dual stream transmission. Refer (Ref. TN MAC-HS, #567). 2559 2560 For single stream transmissions, the current TF selection algorithm is used with the latest single stream 2561 SE for the user as input (see TN-MAC-hs-567). 2562

2563 For dual stream transmissions, the current TF selection algorithm is used with SE1(ui) as input for the 2564 primary stream transmission and SE2(ui) as input for the secondary stream transmission (see TN-MAC-2565 hs-567). 2566

2567 • If the secondary stream is for a new transmission : 2568

- Inform the “modulation” capable flag as indicated in TN-MAC-hs-823. 2569 - Set the number of available codes (same as number of code iin the primary streamTF) 2570 - If the number of codes resulting is fewer, set flag SINGLE_STREAM_ONLY = TRUE. 2571

Only one transport block on the primary stream will be transmit. 2572 2573 • If the secondary stream is for a retransmission : 2574

- set number of codes to be equal to that of the primary, 2575 - Inform the “modulation”, capable flag as indicated in TN-MAC-hs-823. 2576 2577 Note: The modulation order of the primary transport block is always larger or equal to the modulation 2578 order of the secondary transport block. 2579 2580




Note1: If UE reports dual CQI but the scheduler, decides to send a single stream transmission, the SE it 2581 uses for single TB selection corresponds to CQI1. It happens if there is no paired HARQ Process 2582 available or the case describes previously. 2583

2584 4. Precoder Weight Selection: 2585

If the parameter “isPrecodingWeightsetRestrictionPreferred” provided by the bbr is set to false, the 2586 scheduler sends to the CE the PCI value received in the CQI packet. There is no modification done by 2587 the scheduler. 2588

If the parameter “isPrecodingWeightsetRestrictionPreferred” provided by the bbr is set to true and if the 2589 UE preferres a dual stream transmission (means SS/DS set to DS in the CQI packet received from the 2590 CE), there is no modification of the PCI value. 2591

If the If the parameter “isPrecodingWeightsetRestrictionPreferred” provided by the bbr is set to true and 2592 if the UE preferres a single stream transmission (means SS/DS set to SS in the CQI packet received 2593 from the CE): 2594

- The valid values of PCI are PCI = 0 or PCI = 3 2595

- If the PCI value is “invalid” (different than 0 or 3), the scheduler enforces the 2596 valid PCI by sending to the CE the last valid PCI value received. If no valid 2597 PCI value has been received before, the scheduler shall use the valid PCIs 2598 alternatively in consecutive TTIs until valid PCI is received. 2599

Note2 : In case of TFRC selection failure, set the flag SINGLE_STREAM_ONLY = TRUE. (TN MAC-HS 2600 will be updated in Sept/October 2010) 2601

The TFRC selection can failed due to: 2602

In case of TFRC lookup for retransmission: 2603

• Insufficient HSDSCH power, which resulted in low SINR. (since power is one of the input while 2604 calculating SINR). 2605

• ‘Low’ CQI reported by UE is not sufficient to transmit the retransmission TB. 2606 • Available codes are not sufficient for the retransmission TB. Number of codes is one of the input 2607

for LUT lookup. 2608 2609

1. Both are in re-transmission: 2610 2611

• Primary TFRC lookup failure: set the flag SINGLE_STREAM_ONLY = TRUE. HP2 is 2612 transmitted using the best CQI out of dual CQI report, if TFRC selection for this HARQ is 2613 successful. Note that TFRC lookup is not performed for secondary stream in case both 2614 transmissions are re-transmissions. 2615

2616 2. Both are in new-transmission 2617 2618

• If secondary stream PDSCH codes are less than primary stream PDSCH codes, then set the 2619 flag SINGLE_STREAM_ONLY = TRUE. Note that TRFC lookup for new transmissions cannot 2620 fail. 2621

2622 3. One of them is in re-transmission 2623 2624

• Primary stream TFRC lookup failure: Transition set the flag SINGLE_STREAM_ONLY = TRUE 2625 and transmit HP2 using best CQI out of dual CQI report, if TFRC chain for this HARQ passes. 2626 2627

• If secondary stream PDSCH codes are less than primary stream PDSCH codes, then set the 2628 flag SINGLE_STREAM_ONLY = TRUE. Note that secondary stream is new transmission and 2629 hence TFRC lookup cannot fail. 2630

2631




4.6.4.2.2.2.3 Update of Resources 2632

The HS-PDSCH power allocated to this UE needs to be calculated. This is done based on the available 2633 power Pav

HSDPA, the selected number of HS-PDSCH codes and a power redistribution factor. 2634

The last step is to update the still left scheduling resources (used power and used codes) which would 2635 be available to the next UE to be scheduled. 2636

Prepare for transmission 2637

• Choose the free HARQ process from the free_list 2638

For MIMO users, this is done during TFRC step. 2639

• Trigger the priority queue to assemble MAC-ehs PDU 2640

• Set up the reorder buffer 2641

• Store data to be sent in HARQ Process (according the rules seen previously) 2642

• UeContext send data associated to this HARQ Process to the OCP 2643

These actions must be done for the two HARQ Processes in the UeContex in case of dual stream. 2644

4.6.4.2.2.2.4 Ranking Weight Calculation 2645

Job size and average user throughput, which are also taken into account for user ranking, continue to 2646 be used as they are currently done. Average user throughput is calculated based on successfully 2647 acknowledged PDUs. In case of dual stream transmissions, it has to be cumulated for the transport 2648 blocks while for single stream transmission, it will be primary transport block only. 2649

4.6.4.2.3 HS-SCCH and HS-PDSCH code selection 2650

For MIMO Single stream users with QPSK or 16QAM, reservation of HS-SCCH index list will be 2651 removed. 64 QAM users will be treated like any non-MIMO 64 QAM user 2652

For MIMO users with dual stream, following actions are taken. 2653

Let Codes_WithoutP be the codes available without parity checks. 2654

• If modulation combination is ( 64QAM and QPSK ) 2655

o Reserve HS-SCCH index based on parity checks. Let Codes_WithP be the codes available 2656 with parity 2657

• If Codes_WithP is less than Codes_WithoutP 2658

- Invoke LUT for primary. Let the result be TFRC_primary. 2659

- Invoke LUT for secondary. Let the result be TFRC_secondary 2660

o Case 1: TFRC_primary == PASS && TFRC_secondary == PASS 2661

Note: TFRC_primary == PASS means, TFRC lookup for primary stream has returned valid TFRC 2662 combination. It is same for TFRC_secondary as well. 2663

� Sub case 1: Modulation 64QAM, QPSK 2664

• Dual stream transmission with Codes_WithP codes 2665




� Sub case 2: Modulation not equal to 64QAM, QPSK 2666

• Un-reserve HS-SCCH index 2667

• Make dual stream transmission with Codes_WithoutP codes 2668

o Case 2: TFRC_primary == FAIL && TFRC_secondary == FAIL 2669

� Fail this UE scheduling 2670

o Case 3: TFRC_primary == PASS && TFRC_secondary == FAIL 2671

� Sub Case 1: primary stream modulation is 64 QAM 2672

• Make single stream transmission with Codes_WithP codes 2673

� Sub case 2: primary stream modulation equal to QPSK or 16QAM 2674

• Un-reserve HS-SCCH index 2675

• Make single stream transmission with Codes_WithoutP codes. 2676

o Case 4: TFRC_primary == FAIL && TFRC_secondary == PASS 2677

� Un-reserve HS-SCCH index 2678

� Make single stream transmission with Codes_WithoutP codes 2679

• Else 2680

o Make dual transmission Codes_WithP. 2681

2682

4.6.4.2.4 Look up tables 2683

There is a new CQI to SINR LUT for MIMO mode, ‘dual transport block type A CQI report’. See 2684 4.6.4.2.2.1 UeContext Ul Processing. 2685

4.6.4.3 FRAMING PROTOCOL 2686

The HSD BBR configures the flow control function, part of the framing protocol with a maximum bit rate 2687 for the UE. 2688 The HSD BBR takes into account the maximum data rate which depends on the HS-DSCH Physical 2689 Layer Category. It shall take into account the MIMO activation which can transmit two transport blocks 2690 within a TTI. 2691

HS-DSCH category

Peak data rate (Mbps)

Peak data rate for two transport blocks (Mbps)

15/17 23.37 46.74

16/18 27.95 55.90

19 35.28 70.56




20 42.19 84.38 2692 In case of reconfiguration of the UE context (MIMO->non MIMO and non MIMO->MIMO), HSD BBR 2693 informs the flow control instance associated to the Framing Protocol instance about the new maximum 2694 bit rate. 2695 2696

4.6.4.4 Power Reservation 2697

4.6.4.4.1 Power Reservation with MIMO for HS I/B Co nfigured with minBR (fair 2698 sharing) 2699

For PS I/B MAC-d flows having a GBR (through minBR when minBR is considered to be a GBR), the 2700 power consumption is updated based on the NBAP measurement ‘HS-DSCH Required Power Value’; 2701 The HS-DSCH Required Power Value indicates the minimum necessary power for a given priority class 2702 to meet the Guaranteed Bit Rate for all the established HS-DSCH connections belonging to this priority 2703 class i.e. per SPI. This measurement definition does not differentiate between users with/without MIMO. 2704

4.6.4.4.2 Power Reservation with Vam for R99 DCH (f air sharing) 2705

The NBAP measurement ‘Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, E-2706 AGCH, E-RGCH or E-HICH transmission’ is used to obtain the DCH power usage. 2707 The ‘Transmitted carrier power of all codes not used for HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH or 2708 EHICH transmission’ measurement reported by a VAM capable cell (MIMO or non-MIMO) shall be the 2709 ratio between the sum of the total transmitted powers of all codes not used for HS-PDSCH, HS-SCCH, 2710 EAGCH, E-RGCH or E-HICH transmitted on the cell (sector-carrier) and the maximum transmission 2711 power the cell (sector-carrier). Here, the maximum transmission power is the mean power [W] on one 2712 carrier from both the PAs. 2713

4.6.4.5 Interfaces between HSDPA Scheduler and OC+ CE 2714

Uplink 2715

There are changes because of the multiple values of CQI and ACK/NACK packets. See 4.6.4.2.1. 2716

In case of inconsistencies between the information already known by the scheduler and the information 2717 provided by the CE, the packet will be ignored and a warning is generated (example: MT field == 0 for a 2718 call configured in MIMO Mode). 2719

Downlink 2720

The HSDPA Scheduler send HS-SCCH+ and HS-PDSCH data to the OC+ CE. 2721

The description of the HS-SCCH+ packet is given in section 4.6.5.5.6. 2722

In case of MIMO, the fields: 2723

- Xms give the modulation scheme(QPSK, 16QAM or 64QAM) for the primary transport block and 2724 Xms stb, the modulation scheme for the secondary transport block 2725

- Xpwipb corresponds to the PCI value (see section 4.6.4.2.2.2.2 point 4) 2726

- Xtbs and Xtbs stb contain the transport bloc size information for the primary transport block and 2727 secondary transport block 2728

- Xrv and Xrv stb contain the redundancy and constellation version coding for the primary block 2729 and secondary block 2730

- Xhap represents the HARQ Process identifier included between 0 and 15 for MIMO 2731




- HS-PDSCH base addresses and HS-PDSCH base addresses stb correspond to the base 2732 address of the corresponding HS-PDSCH packet for the primary transport block and the 2733 secondary transport block. 2734

The way to fill these fields doesn’t change comparing with the existing except for the HS-PDSCH 2735 Transmit Power. 2736

The HS-PDSCH transmit Power expected by the CE is caculated as following: 2737

HS-PDSCH Transmit Power = Ptotal/(N_ChCodes * N_TrBlks) – in linear domain 2738

where 2739

Ptotal = Total HS-PDSCH power allocated to both PAs 2740

N_ChCodes = number of HS-PDSCH channelization codes 2741

N_TrBlks = number of HS-DSCH transport blocks 2742

Until now, this number of transport blocks was always one but now with MIMO, it can be two 2743 transport blocks. 2744

The description of the changes in the HS-PDSCH is precised in section 4.6.5.5.7. It concerns the 2745 indication of the MIMO mode in MT field and if the packet is for a primary transport block or a secondary 2746 transport block thanks to P/S field. There is one HS-PDSCH packet per transport block. 2747

4.6.4.6 Counters 2748

Among the counters described in section 6.3.1, MAC-ehs scheduler shall take into account: 2749 2750

• New counter #10850 HsdpaMimoDualStreamFraction 2751 This new counter is added in the structure hsdpaMacHsPerfMeasReport. No change in the CPIF 2752 interface for this structure, the evolution is present in CdmHsdpaMacHsPerfMeasReport. 2753 The scheduler shall calculate this ratio each TTI and indicate the value in the field 2754 hsdpaMimoDualStreamFraction of hsdpaMacHsPerfMeasReport structure. 2755 hsdpaMimoDualStreamFraction corresponds to the ratio in percentage between dual stream 2756 transmission out of the total (single and dual stream) transmission per TTI. 2757

2758 • Counters #10825 (HsdpaTTIperUEcat) and #10826 (HsdpaTxDataBitPerUEcat) 2759 • Counter #10819(HsdpaReceivedCQI) provides CQI received per cell but the CQI has a new 2760

range 0-255. The CQI_S provided by the CE must be used. 2761 • Counters #10806 (HsdpaMACdPDUAckBits), #10810 (HsdpaNbrACKRcv), #10811 2762

(HsdpaNbrNACKRcv) and #10812 (HsdpaNbrDTX) shall take into account both single and dual 2763 stream transmissions. 2764

2765




4.6.5 eCEM/Layer 1 2766

4.6.5.1 Layer 1 Overview 2767

The OCPlus CE shall be capable of supporting HSDPA MIMO users with the following capabilities & 2768 configurations: 2769

• Compliant to 3GPP Release 8 2770

• Up to 15 MIMO Users 2x2 MIMO with DL QPSK, 16QAM or 64QAM 2771

• Each MIMO user consumes 2 HSDPA resources (out of 128), remaining resources being 2772 available for non-MIMO users. 2773

• Each MIMO user consumes up to 30 HS-PDSCH channel resources so up to 15 OVSF codes, 2774 since the 2 MIMO streams use the same code. 2775

• Maximum data rate at physical layer is 43.2Mbps (i.e. 3.6Msym/sec (15codes) x 2776 6bit/sym(64QAM) x2 (MIMO) 2777

• Two way data multiplexing DTxAA and TxAA are supported. 2778

• Up to 6 MIMO cells per eCEM(-u) board. 2779

• Up to 8 HS-SCCH per cell, 48 HS-SCCH per board and 48(*) HS-PDSCH physical resources 2780 per board 2781

• Up to 30 HS-PDSCH physical resources per cell 2782

• Introduction of HS-SCCH Type 3 for UE configured in MIMO mode (**). 2783

• Introduction of HS-DPCCH decoding form for UE configured in MIMO mode. 2784

• Support of PCI/CQI_DTX, CQI old/new and CQI erasure information 2785

• CQI measurement delay is the same as for Dual Cell HSDPA: variable delay 9ms or 11ms. 2786

• For MIMO Cell Antenna-1: Antenna-1 modulation pattern of P-CPICH 2787 Unchanged compared to non-MIMO Cells) 2788 • For MIMO Cell Antenna-2: Antenna-1 modulation pattern of S-CPICH 2789

New physical channel generated by the OC. See sections OneChip to PQ3 Interface and OCC 2790 Modifications. 2791

• Use of a Virtual Antenna Mapping (VAM) function for PA balancing. This function is 2792 implemented into the CE to HSSL interface. 2793

(*): With Feature 89411 Aggregate Throughput Increase, the max number of HS-PDSCH is extended to 2794 90. 2795

(**): In a given subframe, a mix of HS-SCCH type 1 and type 3 can be supported. 2796

HS-SCCH orders are not requested to be supported. 2797

The maximum number of HS-SCCH per subframe is also limited to the maximum number of HS-2798 PDSCH CE resources. Example: 48 HS-SCCH with 2 transport blocks cannot be supported because 2799 2x48>90. 2800

4.6.5.2 CE Message Interface 2801

The CE has two interfaces to the PQ3: one for the OC and one for the OCPlus. They are covered by the 2802 OC Message Catalogue and the OCPlus Message Catalogue. The following sections detail these two 2803 interfaces. 2804

4.6.5.3 OneChip to PQ3 Interface 2805

The OC/PQ3 interface is modified in order to include the additional parameters for the configuration of 2806 the S-CPICH. 2807




During the MIMO Cell setup: 2808

On the reception of a NBAP message Cell Setup Request, when the cell is MIMO, one additional CE 2809 Message SCPICH Setup Request is used. This message already exists but was not used in precedent 2810 releases. 2811

A new field Tx_Accumulator_Indicator is also added into the SCPICH Setup Request message in 2812 order to indicate whether the S-CPICH is to be generated onto Tx_accumulator_A or 2813 Tx_accumulator_B, as detailed in section 4.6.5.4. 2814 Tx_Accumulator_Indicator can be equal to: Tx_accumulator_A, Tx_accumulator_B or Absent 2815 2816 Tx_Accumulator_A sums all transmitter output streams that will be sent to antenna A (also called 2817 primary antenna). See Figure . 2818 In the same manner Tx_Accumulator_B sums all transmitter output streams that will be sent to antenna 2819 B (also called secondary antenna). 2820 2821 During a MIMO Cell Setup the SCPICH Setup Request is used with parameters: 2822

• Transmit_Diversity_Indicator = Inactive. 2823 • Tx_Accumulator_Indicator = Tx_accumulator_B. 2824 2825

In case of PA failure: Activation/Deactivation of the S-CPICH 2826

The activation/desactivation of the S-CPICH is done by changing its power level thanks to the NBAP 2827 message Cell reconfiguration Request . On reception of this message, one CE message SCPICH 2828 reconfiguration request is send to the OneChip. 2829

On a PA failure the S-CPICH power is reduced to its minimum level. 2830

On a PA recovery, the S-CPICH power level is reconfigured to its normal value. 2831

Note that despite the fact that the VAM will be reconfigured on a PA failure and so the S-CPICH no 2832 more will be transmitted, the S-CPICH power level is reduced anyway for consistency. This is required 2833 because the S-CPICH power level is used by the MAC-ehs scheduler for the SINR calculation 2834

4.6.5.4 OCC Firmware Modifications 2835

The OCC procedure associated to the CE message SCPICH Setup Request shall be modified in order 2836 to take into account the new parameter Tx_Accumulator_Indicator . 2837

In the OC, the 2 parameters Tx_accumulator_A and Tx_accumulator_B , which are provided by the 2838 Cell Hardware Setup request message, indicate the stream index associated to the primary antenna A 2839 and the stream index associated to the secondary antenna B that was reserved for the TxDiv modes. 2840

In case of a MIMO cell setup the S-CPICH channel is configured as shown in the following figure. 2841

2842




OneChip

TxA

B

TxA

B

TxA

B

S-CPICH

TX_Accumulator_A

TX_Accumulator_B

S

S

Stream to VAMVirtual Antenna 1

Stream to VAMVirtual Antenna 2

Should not be connectedNo TxDiv mode

antenna A

antenna B

2843

Figure 13: Generation of S-CPICH in OneChip 2844 The S-CPICH transmitter is configured in normal mode (no TxDiv) and its primary output A is connected 2845 to the accumulator Tx_accumulator_B that was provisioned for TxDiv mode. For all transmitters the 2846 TxDiv mode should not be used and their secondary antenna B should no more be connected to 2847 Tx_accumulator_B as for non-MIMO Cells. 2848

The two output streams Antenna A and Antenna B are sent to the VAM element inputs streams Virtual 2849 antenna 1 and Virtual antenna 2 respectively. 2850

4.6.5.5 OneChip Plus to PQ3 Interface 2851

The OCPlus/PQ3 interface is modified in order to include the additional parameters for MIMO. 2852

4.6.5.5.1 Cell Configuration Request 2853

A new parameter CQI Delay Distance is added for MIMO. 2854

CQI Delay Distance=4 for 9ms CQI Measurement Delay. 2855 CQI Delay Distance=5 for 11ms CQI Measurement Delay. 2856 2857

4.6.5.5.2 HS Configuration Request: HS-DSCH Informa tion VIE 2858

• The 5 Ack/Nack thresholds of the VIE are mapped for MIMO as follows : 2859

Field in the VIE Thresholds for MIMO Ack_1 Single Stream: Ack Threshold Nack_1 Single Stream: Nack Threshold Ack_2 Dual Stream: Ack(STB) Ack(PTB) Nack_2 Dual Stream: Nack(STB) Nack(PTB) Ack_Nack Dual Stream: Ack(STB) Nack(PTB) and Nack(STB) Ack(PTB) 2860

• MIMO Activation Indicator is added. 2861

MIMO N/M Ratio is added. See section 4.6.5.5.4. 2862

4.6.5.5.3 (Uplink) HS-DPCCH: Ack/Nack Indicators 2863

The Ack/Nack user info field of uplink ACK/NACK packets shall contain 4 indicators: 2864




• UE_Mode : Indicates when UE is in MIMO mode. 2865 The two boolean indicators MT and DCT are re-interpreted as a 2-bit coded enumeration 2866 UE_Mode as follows: 2867

UE_Mode

(MT=bit1) , (DCT=bit0)

User configuration

00 : Normal UE not in Dual Cell and not in MIMO

01: DC UE in Dual Cell mode

10: MIMO UE in MIMO Mode

11: reserved Reserved for DC+MIMO

2868 This naming convention is used in the present document not be necessarily in the OC Plus 2869 Message Catalogue, which is the official specification document. 2870 2871 UE_Mode is not needed by PQ3, which has the information already, but may be used for alarm 2872 management. 2873

2874 • Ack/Nack SS : MIMO users and single stream 2875 • Ack/Nack DS_PTB: MIMO user and Dual stream - Primary Transport Block 2876 • Ack/Nack DS_STB: MIMO user and Dual stream - Secondary Transport Block 2877

2878

The 3 Ack/Nack indicators correspond to the outputs of the HS-DPCCH decoder that are systematically 2879 decoded by the OC+. 2880

It is up to the PQ3 to read them depending on UE_Mode and the existence of the secondary transport 2881 block. 2882

The table below indicates the list of fields in the Ack/Nack user info that have to be interpreted 2883 depending on UE_Mode. 2884

UE_Mode

Field 00

Normal

01

DC

10

MIMO

SC/DC Single Cell / Dual cell

HDSC Hard Decision Single Cell

Ack/Nack Ack/Nack Ack/Nack Primary Cell Ack/Nack SS

Ack/Nack DS_PTB Ack/Nack DS_PTB

Ack/Nack SC/DS_STB Ack/Nack Secondary Cell Ack/Nack DS_STB

2885

New field added for MIMO

2886




The following figure is a proposal for the definition of Ack/Nack User . The official specification is given 2887 in OC Plus Message Catalogue [R6]. 2888

UE

_M

ode

ULC

M inhib

it fla

g

HD

SC

Ack/N

ack

SS

C/D

S_STB

DLC

M inhib

it fla

g

Ack/N

ack

SC

/DC

Fra

me S

ync S

tatu

s

Ack/N

ack

DS

_P

TB

2889

2890

Figure 14: Ack/Nack User Info Format (proposal) 2891 2892

4.6.5.5.4 (Uplink) HS-DPCCH: Composite PCI/CQI rep orting 2893

There are 2 types for the received composite PCI/CQI: 2894

Type A: Contains the CQI for either one transport format or two transport formats depending on the 2895 preferred number of transport blocks. 2896

• CQI = 15 x CQI_1 + CQI_2 + 31 when 2 transport blocks are preferred by the UE 2897 • CQI = CQI_s when 1 transport block is preferred by the UE 2898

2899 Type B: Contains the CQI for one transport format (i.e. CQI = CQI_s) 2900

The 2 types are multiplexed in time, using a dynamic ratio between the number of type A and type B. 2901 This time multiplex, as detailed in 3GPP TS25.214 section 6A.1.2.2, depends on parameter “MIMO 2902 N/M Ratio” and is known by the OCPlus. 2903

The OCPlus decodes the composite PCI/CQI, depending on its type A or B and returns the following 2904 indicators in the CQI user info field of uplink CQI packets : 2905

• UE_Mode : Indicates when UE is in MIMO mode. 2906 • PCI: (Decoded bits) Preferred primary precoding vector. 2907

This indicator provides the NodeB with the preferred precoding weight w2. This information is 2908 sufficient to derive the remaining weights w3 and w4. 2909

See paragraph Precoding weight set restriction hereafter. 2910

• SS/DS: Single Stream / Dual stream decoded indicator 2911

Value is Dual stream when UE in MIMO mode and decoded CQI ≥ 31 (i.e. 2 transport blocks 2912 are preferred by the UE) 2913

SS/DS is forced to SS for a PCI/CQI Type B. 2914

• TypeA/B : Indicates the type of PCI/CQI reporting. 2915

This indicator is not used by the scheduler but is added in the interface for debugging or for 2916 PQ3/OC+ synchronization monitoring. 2917

• Total DTX : True when the CQI/PCI has not been reported by the UE (i.e. PCI/CQI is seen 2918 DTXed in all subframes of the CQI repeat interval) 2919

During compress mode on DPCH or F-DPCH, the UE shall use DTX in conditions given in 2920 3GPP TS25.214 section 6A.3. 2921

Basically the behaviour with CM in MIMO is the same as for non-MIMO case. 2922




• CQI Single stream information : Set of information associated to the single stream (CQI_s) 2923

It is always reported and updated (i.e. whatever the type decoded SS or DS) 2924

It is composed of the following elements: 2925

• CQI decoded (Bit format) 2926

• CQI decoded (EcNt format) 2927

• CQI predicted (EcNt format) 2928

• CQI mean (long term average EcNt) 2929

• CQI Nvar (Normalized variance) 2930

• CQI NMSE (Normalized Mean Square Error) 2931

• CQI Dual stream information : Set of information associated to the dual stream. 2932

It is updated and reported only when dual stream is decoded. 2933

It is composed of 2 sets of information, one set for the PTB and one set for the STB. Each set 2934 is composed of the following elements: 2935

• CQI decoded (Bit format) 2936

• CQI decoded (EcNt format) 2937

• CQI predicted (EcNt format) 2938

2939

• CQI Quality metric : Quality metric computed onto the joint PCI/CQI ???? 2940

The format of this metric is described in algorithm document [R4] 2941

2942

The format of the CQI user info field should be consistent with Dual Cell 2943

2944




The table below indicates the list of fields in the CQI user info field that have to be interpreted 2945 depending on UE_Mode. 2946

UE_Mode

Field 00

Normal

01

DC

10

MIMO

Additional validity condition

SS/DS � SS/DS=SS when TypeA/B=B

TypeA/B �

Total DTX � � �

Old/New � � �

Erasure � � �

CQI decoded bit � � �

CQI2 decoded bit � � SC/DC=Dual or SS/DS=Dual

CQI3 decoded bit � SS/DS=Dual

CQI decoded (EcNt format) � � �

CQI2 decoded (EcNt format) � � SS/DS=Dual or SC/DC=Dual

CQI3 decoded (EcNt format) � SS/DS=Dual

CQI predicted (EcNt format) � � �

CQI2 predicted (EcNt format) � � SS/DS=Dual or SC/DC=Dual

CQI3 predicted (EcNt format) � SS/DS=Dual

CQI Quality Metric � � �

CQI Normalized Variance � � �

CQI2 Normalized Variance � SC/DC=Dual

CQI NMSE � � �

CQI2 NMSE � SC/DC=Dual

CQI Mean � � �

CQI2 Mean � SC/DC=Dual

PCI ��

2947 New field added for MIMO

2948




Mapping of MIMO elements into the PCI/CQI User Info Format (proposal): 2949

2950 Information Element Field

CQI Single Stream Information

CQI decoded (Bit format) CQI decoded bit

CQI decoded (EcNt format) CQI decoded (EcNt format)

CQI predicted (EcNt format) CQI predicted (EcNt format)

CQI mean (long term average EcNt) CQI Mean

CQI Nvar (Normalized variance) CQI Normalized Variance

CQI NMSE (Normalized Mean Square Error) CQI NMSE

CQI Dual Stream Information

PTB (Primary Transport Block)

CQI decoded (Bit format) CQI2 decoded bit

CQI decoded (EcNt format) CQI2 decoded (EcNt format)

CQI predicted (EcNt format) CQI2 predicted (EcNt format)

STB (Secondary Transport Block)

CQI decoded (Bit format) CQI3 decoded bit

CQI decoded (EcNt format) CQI3 decoded (EcNt format)

CQI predicted (EcNt format) CQI3 predicted (EcNt format)

2951

The following figure is a proposal for the definition of PCI/CQI User . The official specification is given in 2952 OC Plus Message Catalogue [R6]. 2953




UE

_M

ode

CQ

IE

rase

CQ

IO

ld/N

ew

CQ

ITota

l D

TX

Type

A/B

SS

/D

S

PC

I

2954 Figure 15: PCI/CQI User Info Format (Proposal) 2955

The timing constraints for the completion of PCI/CQI decode process are detailed in the following 2956 section. 2957

2958

Precoding Weight Set Restriction 2959

When the UE is configured with Precoding Weight Set Restriction, it reports only 2 possible PCI 2960 values, but the PCI decoder in the CE always decodes one value out of the total of 4 values. 2961

The scheduler should take into account the fact that the CE may decode one invalid PCI value. 2962

This situation may appear for the following reasons: 2963

• Precoding Weight Set Restriction has not been configured by RNC on the UE, 2964

• Precoding Weight Set Restriction has been configured by RNC on the UE but it is non-2965 compliant, 2966

• PCI value decoded by the CE is in error. 2967

2968

2969

4.6.5.5.5 PCI/CQI Timing constraints 2970

The timing constraints are detailed in document OCPlus Tier0 document [R5] in section CQI Timing. 2971

The CQI handling should be the same for Dual Cell and MIMO, this is mainly due to the fact that a cell 2972 may handle DC and MIMO UEs simultaneously. 2973

So the CQI measurement delay for MIMO is variable (i.e. 9ms or 11ms) as for Dual Cell. 2974

With a CQI Measurement delay of 9ms (resp. 11 ms), the scheduler uses CQI from subframe N-1 2975 (resp. N-2) when making decisions associated with the Ack interrupt for subframe N. 2976

Since MIMO feature is requested on eCEM board, the interrupt mode is always set to “latest cell”. 2977

The CQI interrupt shall be positioned as it is done for Dual Cell case. 2978




4.6.5.5.6 (Downlink) HS-SCCH Type 3 2979

A new type has been defined for MIMO users. For a UE in MIMO mode, when (re)transmitting a 2980 transport block the NodeB shall use this type for one of the HS-SCCHs in the UE’s HS-SCCH set. 2981

2982

In order to include new parameters introduced by HS-SCCH Type 3, the HS-SCCH+ Packet is 2983 modified as follows: 2984

• UE_Mode : Indicating when UE is in MIMO mode. 2985 • PTB/STB : Single or Dual stream transmission 2986 • Xms : Modulation scheme & Number of transport blocks (information for the 2 transport blocks) 2987 • Xpwipb: Precoding weight information for the primary transport block (*) 2988 • Xtbspb, Xrvpb: Size, Redundancy and Constellation version for the primary transport block 2989 • Xtbssb, Xrvsb: Size, Redundancy and Constellation version for the secondary transport block 2990 • Channelization code set information : Xccs (unchanged) 2991 • UE identity : Xue (unchanged) 2992 • Hybrid -ARQ process information: Xhap 2993 • HS-PDSCH base addresses : One additional parameter provides the base address of the 2994

secondary transport block in the HS-PDSCH buffer. 2995 • Stb size index: HS-PDSCH Transport block size index Kt for the secondary transport block. 2996

2997 The format of the Hybrid-HARQ process information (Xhap ) is different for non-MIMO and MIMO (range 2998 0..7 for non-MIMO and range 0..15 for MIMO). 2999

3000 Note (*): PCI is proposed to be communicated to and from the scheduler because the NodeB can 3001 potentially override the UE recommendation, and it is currently not clear whether the scheduler would 3002 play a part in that decision in a future version of the algorithm. The way the algorithm is defined 3003 currently, the scheduler does not need to know the PCI - the CE can use whatever the UE reported, or 3004 can potentially use a PCI predictor to recommend a precoder index different from the one reported by 3005 the UE. 3006 The decoding of HS-SCCH orders is not supported by the OC Plus. 3007

4.6.5.5.7 (Downlink) HS-PDSCH 3008

Introduction 3009

The HS-PDSCH is generated in the OCPlus CE using information coming from PQ3 thanks to HS-3010 PDSCH and HS-SCCH+ Packets. These packets contain the following additional fields for MIMO: 3011

• MT: Indicates if the UE is in MIMO mode, 3012 • P/S: Primary or Secondary transport block. 3013

3014

For MIMO there are 2 separate HS-PDSCH Packets for the transmission of the 2 transports blocks. The 3015 2 packets can be distinguished thanks to P/S flag. 3016

3017 Behavior of the CE in case of a missing HS-PDSCH pa cket 3018

If the HS-PDSCH packet for the secondary transport block is not received there will be no 3019 secondary transport block transmitted. Note however that the primary transport block will be 3020 transmitted if the HS-PDSCH packet for the primary transport block is received within the 3021 allowable window (i.e. 1 ms before the HS-PDSCH subframe boundary). The CE does not 3022 know or care that two transport blocks (primary transport block and secondary transport 3023 block) are paired for MIMO. 3024

3025 Behavior if any HS-PDSCH packet is received late 3026




In the current pre-MIMO HSTX implementation, a late error is flagged to the DSP if the 3027 scheduler attempts to write to the HS-PDSCH Traffic Packet Buffer outside the write window in 3028 which the scheduler owns the buffer (outside the write window = a scheduler write 3029 attempt within 1 ms of the HS-PDSCH subframe boundary). In the specific case of MIMO with 3030 two transport blocks where the HS-PDSCH packet for the secondary transport block is received 3031 late, the CE behavior does not change from that described for pre-MIMO. 3032 3033

As documented in section 2.5.2.2.2 CQI Timing of the Tier 0, for MIMO with only a primary transport 3034 block transmission the HS-SCCH encoding time in the CE increases. In the worst case (all HS-SCCH 3035 are for MIMO with only a primary transport block) the total encoding time increases from ~.015 ms to 3036 ~.018 ms). This reduces the amount of time available to the scheduler for providing HS-SCCH packets 3037 to the CE by ~.003 ms. 3038

4.6.5.6 CE Configuration parameters 3039

This section gives the list of new parameters needed for MIMO and modifications done for existing 3040 parameters. 3041

3042

Parameter Message Type Comments

CQI Delay Distance Cell Configuration Request Integer A new parameter is added for MIMO users

S-CPICH activation Cell Setup Request Boolean Already existing parameter.

See OC message catalogue Section 7.14 Cell setup.

MIMO activation HS-DSCH Information Element

Boolean New parameter

Tx_Accumulator_Indicator S-CPICH Setup Request Boolean New parameter (per cell)

MIMO N/M Ratio HS-DSCH Information Element

Index to the N/M ratio table

New parameter (per cell)

Dual ACK/NACK Threshold

HS-DSCH Information Element

5 x 16-bit values New parameters

Single stream - Ack Threshold Single stream - Nack Threshold Dual stream - Ack/Ack(*) Threshold Dual stream - Ack/Nack & Nack/Ack Threshold Dual stream - Nack/Nack Threshold (*):(TB/STB)

VAM coefficients Dedicated access to the FPGA combiner by the PQ3

2x2 complex matrix

New parameters (per cell)

3043

4.6.5.7 CE to HSSL Interface – Virtual Antenna Mapp ing function 3044

Introduction 3045

The aim of the VAM function is to create 2 virtual antennas seen by the UEs, thanks to the 2 physical 3046 antennas and with a weighting matrix as shown in the following figure. 3047




Cro

ss p

ola

rized

ante

nna

3048

Figure 16: VAM Function 3049 The objective of the VAM function is to balance power at the 2 physical antennas. 3050

The VAM coefficients are of the form: 3051

=

=

43

21

43

21

2221

1211φφ

φφ

jj

jj

ejaea

eaea

vv

vvVAM 3052

3053

The typical values that are provided by the RNC are: 3054

=

=

2

1

2

12

1

2

1

43

21

aa

aaAmplitudes ,

=

=

00

00

43

21

φφφφ

Phases 3055

In case of a PA failure, the coefficients are reconfigured by the CCM OAM with the following values that 3056 do not depend on coefficients a1 to a4 and φ1 to φ4: 3057

In case of 1st Tx branch failure:

=

00

10Amplitudes ,

=

00

00Phases i.e. P2 <= V1 3058

In case of 2nd Tx branch failure:

=

00

01Amplitudes ,

=

00

00Phases i.e. P1 <= V1 3059

3060




Where is the VAM from an Architectural point of vie w? 3061

Due to the summation stages in the eCEM boards and xCCM, the VAM function is implemented in a 3062 distributed manner as illustrated in the following block diagram. 3063

3064

Figure 17: Architectural view of VAM 3065 There are 6 distributed VAM elements per eCEM, each being associated with one cell. 3066

In case of a non-VAM cell, the associated VAM element should be bypassed (P1<=V1; P2<=V2). 3067

In case of multiple distributed VAM elements for one cell, it is not needed to synchronize their 3068 configuration at a specific frame boundary. 3069

The current view is to update coefficients at the BFN boundary. 3070

3071

3072




Detailed specifications of VAM 3073

X

X

X

X

+

+

complex multipliers

complex

complex

complex

registersBFN boundary

3074

3075

3076

Figure 18: Block diagram of the VAM Implementation 3077 3078 The VAM coefficients are complex values {Re, Im}. Since coefficients provided by the RNC are in polar 3079 format {Amplitude, Phase} a polar to Cartesian conversion is to be performed by the PQ3. 3080 The VAM coefficients provided to the FPGA are 16-bit signed complex and the detail of quantization is 3081 given in the algorithm document [R12]. 3082 The exact definition of interface registers is given in HSIM document [R13] 3083 3084 In the NodeB, the 2 streams dedicated to each OC+ Cell are allocated using the following constant rule: 3085 OC+Cell index = idx => Tx_Accumulator_A = 2*idx and Tx_Accumulator_B = 2*idx+1 3086 Where idx is in range from 0 to 5. 3087




3088 For this reason, a direct mapping shall be implemented as represented in figure above. 3089 3090 Each VAM element is either activated when it is associated to one cell or not used. 3091 Each VAM element for a non-VAM cell is bypassed. The bypass is directly performed by changing 3092 coefficients. 3093 The figure represents here functional multiplexers that will be certainly implemented thanks to a time 3094 multiplexed mechanism. 3095 3096 VAM Configuration Parameters at FPGA Interface 3097 3098 VAM Parameters should be programmed by the PQ3 during start-up and during a cell setup or cell 3099 reconfiguration. 3100 3101 Parameter Type Description V11, V12, V21, V22 6x

2x2 Complex Matrix Each coefficient is a Complex <16,1,t>

Per VAM element coefficient matrix

Update_Flag 6x Boolean

Per VAM element Update flag indicating that the coefficients should be updated by the CE at the next BFN boundary. See timing constraints hereafter.

3102 Timing Constraints: 3103 There is no particular timing constraint concerning the VAM parameters update. Since other modules in 3104 the FPGA combiner are updated on the BFN boundary, the same synchronization mechanism shall be 3105 used for the VAM coefficients. PQ3 being able to write to VAM coefficients at any time (no constraint for 3106 PQ3), a double-buffer mechanism is to be implemented using an update flag. 3107 3108 Since the cell reconfiguration is performed by independent per cell processes in PQ3, and since the 3109 processes are not synchronized with BFN boundaries, update flag shall be separated per VAM element 3110 (i.e. there is one update flag per VAM element at separated address). 3111 3112 3113




4.6.6 xCEM impacts 3114

Since this feature is supported only on eCEM and not xCEM, the interface changes are restricted to 3115 eCEM-CCM and not xCEM-CCM ITF2. Nevertheless for compatibility UCU Manager on xCEM/PQ3 3116 shall set maxDualCellHsdpaMIMOUsersAllowed to 0 in UcuMgrGetCeCapabilityResp message. xCEM 3117 CallP shall propagate this information in CemCapacityResp message to CCM CallP so that it knows it is 3118 an xCEM which cannot support MIMO (see section 4.6.3.4). 3119

4.6.7 TRM impacts 3120

No impact. 3121 The remaining fractional part of the delay is compensated by the TRM in DL is already implemented in 3122 the context of DC-HSDPA. 3123 The fact that there are two DL paths Main and Div from CCM OAM point of view instanciated on 2 TRM 3124 is transparent for TRM itself which is always configured with Main path. 3125 3126

4.6.8 RRH/TRDU impacts 3127

The remaining fractional part of the delay is compensated by the RRH. For DL this is already 3128 implemented in the context of DC-HSDPA. For UL this has to be implemented. 3129 3130 RRH shall handle RE_SetDelayRequest message (Refer to section 12.1.4.2 for more details) 3131

4.6.9 Loader 3132

No impact 3133

4.6.10 Platform software 3134

No Impact. 3135




4.7 FEATURE INTERWORKING 3136

MIMO feature is not compatible with STSR x+y configurations (these two features use 2PA per sector 3137 but in a different manner) 3138

4.7.1 UA07 FRS 34391 (Multiple xCEM per Carrier) 3139

To achieve maximum possible throughput from each Modem board for each MIMO cell, feature 3140 “Multiple xCEM per Carrier” should be used. 3141

4.7.2 UA07 FRS 34388 (RLC Flexible and Mac-ehs) 3142

Mac-ehs configuration is a pre-requisite for MIMO operation. 3143

4.7.3 UA07 FRS 34386 (64 QAM for HSDPA) 3144

To achieve maximum peak throughput for MIMO, 64QAM modulation is required. 3145

4.7.4 UA07 FRS 81204 (Dual Cell HSDPA) 3146

It is possible to configure simultaneously a cell DC-HSDPA and MIMO capable for iBTS configurations 3147 supporting MIMO which is a subset of iBTS configurations supporting DC-HSDPA. 3148 3149 A given UE can be DC capable, MIMO capable or both DC and MIMO capable but a call cannot be 3150 configured in DC+MIMO simultaneously (Not allowed in Rel-8 standard). 3151 Simultaneous DualCell-MIMO calls shall be rejected as detailed in section 4.1.2.5 Radio Link Setup. 3152 3153 Since such calls will be introduced in 3GPP Rel-9, for future compliancy, information elements for 3154 DualCell and MIMO at all interfaces should not be exclusive. 3155 3156

4.7.5 UA08 FRS 104832 (Dual Cell HSDPA Capacity Inc rease) 3157

Dual Cell HSDPA feature is supported in UA07.1 with some limitations. These limitations are removed in 3158 UA08. The major impact to MIMO is the introduction of additional parameters used to indicate the 3159 maximum number of users MIMO and DualCell that can be simultaneously handled by the eCEM board. 3160

4.7.6 UA07 FRS 24186 (Common Channel Defense) 3161

PsbSetup message is enhanced with S-CPICH power offset (see section 4.6.2.3). 3162

4.7.7 UA06 FRS 29808 (PA Power Pooling) 3163

It is possible to activate PA Power Pooling with MIMO if the R99 cell associated to the MIMO cell is 3164 configured with DualPaUsage set to “Vam”. (checked by CCM OAM see section 4.6.1.1). 3165

4.7.8 UA08 FRS 89411 (eCEM HSPA aggregate throughpu t increase) 3166

This feature introduces a new parameter eCemxCemPreference. The interaction with MIMO is to add 3167 the following check: 3168

• This parameter should be different from xCEM when there is 1 BtsCell MIMO or VAM on the 3169 HsxpaResource. 3170

3171

4.7.9 UA07 FRS 34396, 34194 (Automatic Carrier Swit ch Off) 3172

Automatic Carrier SwitchOff - Overview 3173 When AC failure is detected, some of the PAs would be switched off to save the DC power. "These PAs 3174 can be switched off" is configured in DLU. On detection of AC Failure, CCM OAM identifies these PAs 3175 that need to be shutdown. CCM OAM send block resource requests to RNC for the list of cells that are 3176 supported by these PAs. RNC inturn triggers the cell delete request on these cells if there is no 3177 emergency call running on that PA. Please note that TRM shuts down the PA when it receives the last 3178 cell delete request for the cells hosted on that PA. 3179




3180 Interactions: 3181 With MIMO, one cell is being served by more than one PA/TRM. 3182 3183 Let's say cell 101 is being served by PAs 1 and 2, Cell 101 is MIMO capable. I propose the following if 3184 there is an AC failure, 3185 3186 "PA 1" is part of the PAs that can be switched Off: - 3187 iBTS can't send block resource request since RNC will trigger the cell delete after this request. 3188 iBTS shall send RSI-SI for this cell with the MaxTxPower of PA2 and it shall also indicate that MIMO is 3189 not capable. RNC would trigger cell reconfig request to iBTS with the modified MaxTxPower. This 3190 reconfig request would inturn translate into Cell delete request for PA1/TRM1. This is similar to PA1 3191 Failure sceanrio. 3192 3193 "PA 2" is part of the PAs that can be switched Off: 3194 We can't send block resource request since RNC will trigger the cell delete after this message. 3195 iBTS shall send RSI-SI for this cell with the MaxTxPower of PA1 and it shall also indicate that MIMO is 3196 not capable. RNC would trigger cell reconfig request to iBTS. This reconfig request would in-turn 3197 translate into Cell delete request on PA2. This is similar to PA2 Failure scenario. 3198 3199 Both PA1 and PA2 are part of the PAs that can be sw itched Off:- 3200 No impact here. iBTS shall send Block resource request to RNC for the list of cells that are 3201 served by these PAs. 3202 3203

4.7.10 UA07 FRS 81122 (eCEM HSPA aggregate throughp ut increase) 3204

Enhanced Cell Block – Overview 3205 3206 Operator shall trigger shutdown on CPRI RRH/CMSR. iBTS would inturn send NBAP "Block resource 3207 req" to RNC for the cells that are configured in that CPRI RRH/CMSR. RNC in turn triggers the Cell 3208 delete on these cells if there is no emergency call running on those cells. 3209 3210 Interactions: 3211 3212 With MIMO, one cell is being served by more than one RRH. So shutdown of one RRH doesn't directly 3213 impact the Cell states. So CCM OAM should not trigger the Block resource request to RNC. 3214 3215 For example, say cell 101 is being served by RRHs 1 & 2 and it is MIMO capable. When operator 3216 triggers shutdown on RRH 1, CCM OAM should not trigger "Block Cell request" on Cell 101 as this cell 3217 101 is also served by other RRH (2). So CCM OAM should put MIMO as "Not capable" send RSI for cell 3218 101. When operator triggers the shutdown on RRH 2 (RRH 1 already in shutdown/locked state) at later 3219 point of time, CCM OAM shall send NBAP "Block resource request" to RNC. 3220 3221

4.7.11 FN 74682 BTS Serving RRH2x40W 2100 3222

This feature specifies the use of the Twin RRH equipement RRH2x40_2100MHz in WCDMA 3223 applications in UA8/UA8.1/UA9 releases. This feature specifies the usage of the Twin RRH for the 3224 configuration of a MIMO cell. 3225

3226




4.8 PERFORMANCE OBJECTIVES AND IMPACTS 3227

4.8.1 System performances 3228

MIMO feature tends to achieve up to 43.2 Mbps user peak throughput in ideal conditions (single UE 3229 scenario) for a 3GPP Rel-8 Category 20 MIMO enabled UE. 3230

With eCEM, it should be possible to achieve peak throughput of 43.2 Mbps for conditions mentioned 3231 above. This assumes that 21.6 Mbps can be achieved for Category 14 UE. 3232

Nevertheless this section shall be updated to take into account DC HSDPA measur 3233

As done (or going to be) in the DC FN, the real throughput should be highlighted here. There are some 3234 limitations implemented for 64QAM. The actual max throughput is not and will never be 21.6Mbps! So 3235 the max MIMO throughput will never be 43Mbps. 3236

Also, for Dual cell there are some ongoing discussions wrt the achievable throughput depending if the 3237 xCCM has a FE MDA or a GE MDA. Conclusions of these discussions/tests will have to be highlighted 3238 in this FN as well see open issues [10] and [11]. 3239

4.8.2 Dimensioning 3240

To achieve 43.2 Mbps Mac-ehs throughput per cell on eCEM, each eCEM board should have one 3241 sector only. Thus, cabinet should have eCEM boards in proportion of configured MIMO enabled sectors. 3242

4.8.3 Capacity 3243

The hardware of the eCEM board can support up to 64 simultaneous MIMO and DualCell combined 3244 users at maximum. 3245

In UA07.1.2, for eCEM board, the max number of DualCell users in 4 and MIMO is not supported. 3246

In UA8.0, for theCEM board, the maximum combined number of MIMO and DualCell users is 15. 3247

In UA8.0, for the xCEM, MIMO is not supported. 3248

The maximum number of HSDPA users is 128. 3249

3250 3251 With eCEM: up to 43.2 Mbps MAC-ehs throughput per cell can be supported. 3252

4.8.4 Dependability 3253

Not impacted. 3254

In comparison to STSR1+1, this feature adds a level of redundancy. In STSR1+1, when a PA is 3255 disabled we loss 1 carrier x 1 sector. In MIMO, we keep both Cells alive but with less power. 3256

This is the same in case of TRM failure we keep all cells alive but with less power. 3257

4.9 SECURITY 3258

Not impacted. 3259




5 INTERFACES 3260

5.1 IUB INTERFACE: MIMO IMPACT IN NBAP PROCEDURES 3261

See section 4.1. 3262

5.2 INTERNAL INTERFACES 3263

Note: Following data/structure definitions are just a proposal. Design teams shall discuss and finalize 3264 the exact structure definitions. These finalized interfaces shall be maintained in the dedicated Interface 3265 documents. 3266 3267

5.2.1 ITF2: CCM CallP – eCEM CallP 3268

The following messages are enhanced with new parameters: 3269 3270 Remind concerning CemCapacityRsp (x/eCEM -> CCM): 3271

• maxDualCellHsdpaMIMOUsersAllowed // 15 in UA08. 3272 Parameter maxDualCellHsdpaMIMOUsersAllowed has been introduced with DualCell Capacity 3273 Increase. It denotes the maximum combined number of DualCell and MIMO users supported by the 3274 eCEM. 3275 This parameter replaced former parameter maxDualCellHsdpaUsersAllowed. 3276 Feature DualCell Capacity Increase being pre-required for MIMO, there is no change to be done. 3277 3278 CemPsbSetupReq (CCM -> eCEM) 3279

• S-CPICH Power Offset // (-350…150) same range as IE DL Power (9.2.1.121) in TS 25-433 3280 // CP_16_NOT_DEF (0x7fff) (i.e. S-CPICH not configured) 3281

Note: This message is only used in case of defense. 3282 3283

CemCellReconfReq (CCM -> eCEM) 3284 • S-CPICH Power Offset // (-350…150) same range as IE DL Power (9.2.1.121) in TS 25-433 3285

// CP_16_NOT_DEF (0x7fff) (i.e. S-CPICH not configured) 3286 3287 CemCellSetupReq (CCM -> eCEM) 3288

• S-CPICH Power Offset // (-350…150) same range as IE DL Power (9.2.1.121) in TS 25-433 3289 // CP_16_NOT_DEF (0x7fff) (i.e. S-CPICH not configured) 3290 3291 The following new messages are added: 3292 3293 CemScpichPowerOffsetReconfReq (CCM -> eCEM) 3294 3295 New message from CCM Callp to the eCEM Callp to reconfigure the S-CPICH offset to be used in the 3296 cell. Parameters are: 3297

• objectType //CELL 3298 • object Id //Cell Id 3299 • cem //CEM Id 3300 • S-CPICH Power Offset // Secondary CPICH Power or Power Offset For 3301

// Secondary CPICH for MIMO 3302 // (-350…150) same range as IE DL Power (9.2.1. 21) in TS 25-433 3303 // CP_16_NOT_DEF (0x7fff) (i.e. S-CPICH not configured) 3304

3305 CemScpichPowerOffsetReconfRsp (eCEM -> CCM) 3306




3307 New message from eCEM Callp to CCM Callp in response (success) to 3308 CemScpichPowerOffsetReconfReq message. Parameters are: 3309

• objectType //CELL 3310 • object Id //Cell Id 3311 • cem //CEM Id 3312

3313 CemScpichPowerOffsetReconfFail (eCEM -> CCM) 3314 3315 New msg from eCEM Callp to the CCM Callp in response (failure) to the 3316 CemScpichPowerOffsetReconfReq message. Parameters are: 3317

• objectType //CELL 3318 • object Id //Cell Id 3319 • cem //CEM Id 3320

This message can occur on reception of a PsbCellReconfFail from PQ3, which contains the failure 3321 causes. 3322 The list of causes is not clarified by PQ3 team at this point (see open issue 13). 3323 3324 Message structures: 3325 3326 The following message structures have to be updated to convey HARQ partitioning Info Ext for MIMO 3327 and N/M ratio. 3328

• CemHspaRlReconfPrepRsp_t 3329 • CemRlReconfReady_t 3330 • xCemHspaMigrationPrepRsp_t 3331

3332 Use a structure condition u8 IsMIMOInfoRespPresent the same way as defined for DualCell. 3333 3334 3335

5.2.2 ITF3: CCM OAM – eCEM SLOAM 3336

The messages HsdpaConfigRequest and LocalCellConfigRequest are modified as defined at ITF4 (see 3337 section 5.2.3) 3338 3339

5.2.3 ITF4: eCEM SLOAM – eCEM CallP 3340

The following existing messages are enhanced with the new parameters: 3341 3342 HsdpaConfigRequest: 3343

• nCqiTypeAMCqiRatio 3344 (enum) nCqiTypeAMCqiRatio : N_M_Ratio_1_2, N_M_Ratio_2_3, N_M_Ratio_3_4, 3345

N_M_Ratio_4_5, N_M_Ratio_5_6, N_M_Ratio_6_7, N_M_Ratio_7_8, N_M_Ratio_8_9, 3346 N_M_Ratio_9_10, N_M_Ratio_1_1 3347

Default {N_M_Ratio_1_1} 3348 3349

• (word32) hsScchType3SingleStreamSnr Range: -50 to 190 , Default:14 3350 • (word32) hsScchType3DualStreaamSnr Range: -50 to 190 , Default:23 3351

3352 LocalCellConfigRequest: 3353

• InternalDualPaUsage: (enum) 3354 o VamDisabled, 3355 o VamEnabled, 3356 o VamDegradedToMainOnly, 3357 o VamDegradedToDivOnly Default{VamDisabled} 3358




• (List(4) of word32)VAMAmplitudeCoeff Range: 0 to 2^9-1 , Default: {707106781, 3359 707106781, 707106781, 707106781} 3360

• (List(4) of word32)VAMPhaseCoeff Range: 0 to 350 , Default: {0, 135, 45, 0} 3361 • (Boolean)IsPrecodingWeightSetRestrictionPreferred Default: True 3362

3363

5.2.4 ITF7: CPIF 3364

The following existing messages are enhanced to support MIMO parameters: 3365 3366 Remind concerning message UcuMgrGetCeCapabilityResp: 3367 >> ucuBoardInfo 3368

>>> ceCapability 3369 >>>> num_dual_cell_hsdpa_MIMO_users // 15 in UA08 3370

3371 Parameter maxDualCellHsdpaMIMOUsersAllowed has been introduced with DualCell Capacity 3372 Increase. It denotes the maximum combined number of DualCell and MIMO users supported by the 3373 eCEM. 3374 This parameter replaced former parameter maxDualCellHsdpaUsersAllowed. 3375 Feature DualCell Capacity Increase being pre-required for MIMO, there is no change to be done. 3376

3377 UcuMgrCellCreateReq: 3378 >> CellParamInd 3379 >>> (enum)InternalDualPaUsage: VamDisabled, VamEnabled, VamDegradedToMainOnly, 3380 VamDegradedToDivOnly Default{VamDisabled} 3381 >>> (word32)VAMAmplitudeCoeff[4] – Range [0..1*10e9] * 10e-9 Default {707106781, 707106781, 3382 707106781, 707106781} 3383 >>> (word16)VAMPhaseCoeff[4] - Range [0..359] step 1 Default {0, 135, 45, 0} 3384 >>> (word8)IsPrecodingWeightSetRestrictionPreferred – True, False Default{True} Optional 3385 >>> UcuParams 3386 >>>> HdspaUcuParams 3387

>>>>> (words16)MimoHsdpaAckThreshold – Range [-80;-10] * 0.1db Default{-47} 3388 >>>>> (words16)MimoHsdpaNackThreshold – Range [-80;-10] * 0.1db Default{-47} 3389 >>>>> (words16)MimoHsdpaAckAckThreshold – Range [-80;-10] * 0.1db Default{-47} 3390 >>>>> (words16)MimoHspdaAckNackThreshold // same threshold used for 3391

NackAck – Range [-80;-10] step 0.1db Default{-47} 3392 >>>>> (words16)MimoHsdpaNackNackThreshold – Range [-80;-10] * 0.1db Default{-47} 3393 3394 3395

UcuMgrCellUpdateReq: 3396 >> CellUpdate 3397 >>>(enum)InternalDualPaUsage: VamDisabled, VamEnabled, VamDegradedToMainOnly, 3398 VamDegradedToDivOnly default{VamDisabled} 3399

>>>(word32)VAMAmplitudeCoeff [4] – Range [0..1*10e9] * 10e-9 Default {707106781, 3400 707106781, 707106781, 707106781} 3401

>>>(word16)VAMPhaseCoeff[4] - Range [0..359] step 1 Default {0,135,45,0} 3402 >>>(word8)IsPrecodingWeightSetRestrictionPreferred – True, False Default{True} Optional 3403 3404 3405 HsdpaPhySharedChannelSetupReq and HsdpaSchedulerPar amUpdateReq: 3406

>>HsdpaCellParams 3407 >>> (enum) nCqiTypeAMCqiRatio : N_M_Ratio_1_2, N_M_Ratio_2_3, N_M_Ratio_3_4, 3408

N_M_Ratio_4_5, N_M_Ratio_5_6, N_M_Ratio_6_7, N_M_Ratio_7_8, N_M_Ratio_8_9, 3409 N_M_Ratio_9_10, N_M_Ratio_1_1 Default {N_M_Ratio_1_1} 3410

>>> (words16) hsScchType3SingleStreamSnr – Range [-50..190] * 0.1db Default{14} 3411 >>> (words16) hsScchType3DualStreamSnr – Range [-50..190] * 0.1db Default {23} 3412

3413




PsbCellSetupReq, PsbCellReconfReq: 3414 >>PsbCellReq 3415

>>> SecondaryCPICHInformation (optional) 3416 >>>> CommonPhysicalChannelId Range[0..255] 3417 >>>> secondaryCPICHPower (*) Range[-350..150] and FF not significant (S-CPICH not 3418

configured) 3419 >>>> txDiversityIndicator Enum: txDiversityActive, txDiversityInactive Default{ 3420

txDiversityInactive} 3421 >>>> (word32) FDD DL Channelisation Code Number 3422

>>>> (word32) secondaryScramblingCode (same as primary scrambling code) 3423 (*) see note in next section. 3424

3425 HsdSetupReq, HsdSetupPrepReq, HsdMigrationPrepareRe q: 3426 3427 New flag HsdInformationMIMOActivationIndicatorPresent in optional flag in HsdInformation 3428 >>HsdConfig 3429 >>>HsdInformation 3430 >>>>OptionalFlag 3431

3432 HsdReconfPrepReq,: 3433

>>HsdDschInfoToModify 3434 >>>(enum)MimoModeIndicator : MimoModeIndicatorActivate, MimoModeIndicatorDeactivate 3435

default{ MimoModeIndicatorDeactivate} 3436 3437 HsdSetupResp, HsdSetupPrepResp, HsdMigrationPrepare Resp, HsdReconfPrepResp: 3438

>>HsdInfoResponse 3439 >>> (enum) nCqiTypeAMCqiRatio : N_M_Ratio_1_2, N_M_Ratio_2_3, N_M_Ratio_3_4, 3440

N_M_Ratio_4_5, N_M_Ratio_5_6, N_M_Ratio_6_7, N_M_Ratio_7_8, N_M_Ratio_8_9, 3441 N_M_Ratio_9_10, N_M_Ratio_1_1 Default {N_M_Ratio_1_1} 3442

>>>HarqMemoryPartitioning 3443 >>>>HarqMemoryPartitioningImplExpl (*) 3444 >>>>>HarqMemoryPartitioningExplicit 3445 >>>>>> (HarqMemoryPartitioningInfo) 3446

HarqMemoryPartitioningInfoExtensionForMIMO: Optional according to MIMOActivationIndicator 3447 and MIMOModeIndicator value 3448

3449 (*):HarqMemoryPartitioningExplicit is not used, only HarqMemoryPartitioningImplicit is supported. But as 3450 the current implementation contains the HarqMemoryPartitioningExplicit, it has been extended for MIMO 3451 to be in line with the existing. 3452

3453 See 9.2 CDM impacts for all the CPIF impacts bring by CDM. 3454 3455 >HsdpaPerfMeasReportInd 3456 >>hsdpaPerfMeasReport 3457 >>>HsdpaXcemPerfMeasReport 3458 >>>>word8 HsdpaMimoDualStreamFraction 3459 [NBAP_MAX_HSDSCH_PHYSICAL_LAYER_CATEGORY+1]; #10850 3460

3461 3462

5.2.5 OC Interface 3463

The changes concern the introduction of the S-CPICH. 3464 3465 When Message to OC

Interface Additional Parameters See

Section On reception of SCPICH Setup Secondary CPICH power(*) 4.6.5.3




NBAP Cell Setup Request

Request (Message Added)

DL Scrambling code DL Channelization Number CE Cell Index Transmit Diversity Indicator=false Tx_Accumulator_Indicator=Tx_Accumulator_ B (New parameter)

On reception of NBAP Cell Reconfiguration Request

SCPICH Reconfiguration Request (Added)

Secondary CPICH power(*)

4.6.5.3

Table 5-1 - OC Interface Changes 3466 3467 (*): Indicates the power level relative to P-CPICH power (i.e. the format is identical to parameter S-3468 CPICH power offset at ITF2 interface). 3469 3470 Since the firmware and the OC Interface are common for OneChip on xCEM and OC-CR on eCEM, the 3471 changes should keep the backward compatibility. The additional parameters shall be optional. 3472 3473

5.2.6 OCP Interface 3474

3475 The changes concern the Ack/Nack, PCI/CQI reporting and the VAM configuration. 3476 3477 When Message to OC+ Interface New (Changed) Parameters See Section On reception of NBAP Cell Setup Request

Cell Configuration Request • CQI Delay Distance for MIMO 4.6.5.5.1

On reception of NBAP Cell Setup Request

HS Configuration Request • Five Ack/NackThresholds • MIMO Activation indicator • MIMO N/M Ratio

4.6.5.5.2

Bearer Traffic HS-DPCCH: Ack/Nack Packet • UE_Mode • Ack/Nack SS • Ack/Nack DS_PTB • Ack/Nack DS_STB

4.6.5.5.3

Bearer Traffic HS-DPCCH: CQI Packet • UE_Mode • SS/DS • TypeA/B • Single Stream:CQI decoded, CQI

decoded EcNt format, CQI predicted, CQI mean, CQI nvar, CQI Nmse

• Dual Stream: 2 sets (CQI decoded, CQI decode EcNt format, CQI predicted EcNt format)

4.6.5.5.4

Bearer Traffic HS-SCCH+ Packet • UE_Mode • PTB/STB • Precoding Weight Info • HS-PDSCH base address for the STB • Transport block size index for the STB • Modulation scheme & Nbr of TB • HARQ process information • Size,RV & Constellation version

4.6.5.5.6

Bearer Traffic HS-PDSCH Packet • MT : MIMO Mode • P/S: Primary or Secondary TB

4.6.5.5.7

On reception of NBAP Cell Setup Request

Dedicated access to FPGA via the local bus

• VAM Activation • VAM Coefficients

4.6.5.7

On reception of CCM callP (upon a PA Failure) Cell reconfiguration Request

Dedicated access to FPGA via the local bus

• VAM Coefficients 4.6.5.7

Table 5-2 – OCP Interface Changes 3478 3479




5.2.7 CCM OAM – CCM CallP Interface 3480

Add Local Cell/Modify Local Cell 3481 3482 A new parameter “MimoActivation” shall be introduced in ADD_LOCAL_CELL and 3483 MODIFY_LOCAL_CELL specific request message from CCM OAM to CCM CallP as given below (in 3484 blue color): 3485

3486 ADD_LOCAL_CELL_REQ / MODIFY_LOCAL_CELL_REQ 3487 3488

0 type: SPECIFIC_REQ 1 Sub-type: ADD_LOCAL_CELL

MODIFY_LOCAL_CELL 2 Master_id: 3 Length _hi 4 Length_lo 5 Spare1 6 Spare2 7 Offset_ie 8 9 10 11 Local Cell Identifier 12 Number of TRM paths (nTrm) (For each Trm path) 13 TRM path type 14 TRM number 15 Channel number 13 + (nTrm*3) Logical Frequency Index 14 + (nTrm*3) Cell Size 15 + (nTrm*3) antennaConfiguration 16 + (nTrm*3) Dynamic Persistence Level 17 + (nTrm*3) dualCellActivation 18 19 20 21 + (nTrm*3)

secondaryServingCellId

22 + (nTrm*3) MimoActivation

3489 3490 (8-11) Local cell identifier 3491 …….. 3492 …….. 3493 3494 (22 + nTRM*3) MimoActivation 3495 3496 TRUE (1): The cell is Mimo capable 3497

FALSE (0): the cell is not Mimo capable 3498 3499

5.2.8 CCM – Core_OAM/REproxy 3500

The impact of the introduction of MIMO feature is under study. 3501 See open issue [15]. 3502 The behaviour of the Core_OAM/REproxy may need to be modified because the configuration of a 3503 MIMO cell is not identical to a STSR x+y configuration: there are 2 Tx paths for the cell instead of one 3504 for STSR x+y. 3505 The impact of the partial Tx failure to the Twin RRH or Paired RRH is to be investigated. 3506 3507




5.2.9 CPRI 3508

CPRI interface is impacted by UL delay alignment. The impact on existing interface definition is under 3509 study. 3510 See open issue [15]. 3511 3512




6 OAM 3513

New parameters are introduced in iBTS for MIMO. 3514 3515 Since BTS cell can have more than 1PAs, we need to make a list of PAresource ids ( as shown in the 3516 shaded box in orange) 3517

DualCellActivation

HSDPA CONF

N

1..N

N

HSXPA RESOURCE

RDN

hsdpaResourceId

BTS Equipment

RDN

1

1..N

RDN

Antenna Access

1..N

1..N Antenna Connection

RDN

Local Cell Group

1..N

Local Cell Group Id 1

1..N

0..1

1

EDCH CONF

0..1

edchResourceId

1

hsxpaResourceId

RDN

BTS Cell

Local Cell Id

Antenna Connection List

Local Cell Group Id N

r99ResourceId

rfCarrierId

RDN

R99 RESOURCE

1..N

N

RDN

RF CARRIER

1..N

N

1

1

RDN

HSDPA RESOURCE 1..N

RDN

RemoteRadioHead

0..N

repeaterCellList

1..N

1..N

RDN

PA RESOURCE RRH

1..N

RDN

PA RESOURCE

1..N

paResourceIdList N

2 1

3518 3519




6.1 CONFIGURATION MANAGEMENT 3520

6.1.1 dualPaUsage 3521

Source Creation Domain BTS object name BTSCell parameter name dualPaUsage Definition The parameter defines whether the cell (sector-carrier) is configured with

two PAs. activationFlag Optional feature Optional No Category Class 0 Associated Event Range Enum (None, Vam, VamAndMimo) Unit Initial values None Recommended value Upgrade rule No Check rule If this parameter is set to ‘Vam’ or ‘VamAndMimo’ and the cell (sector-

carrier) is equipped with one PA/RRH/TRDU, the BTS rejects the configuration. If this parameter is set to ‘Vam’ or ‘VanAndMimo’ and VAM Parameters are not present or invalid, the BTS rejects the configuration. If this parameter is set to ‘none’ and two PA’s/RRH’s/TRDU’s are used for that cell (sector-carrier), the BTS rejects the configuration.

3522

6.1.2 vamParameters 3523

A new object will be supported for VAM related parameters. This object will be named VamParams and 3524 its definition is the following: 3525

Object Property Comments Path BTSEquipment BTSCell

VamParameters SMO

Children N/A Link(s) N/A Identifier(s) rdnId Cardinality 0..1 Create (off-line) Yes Create on-line NotAllowed Delete on-line NotAllowed MO presence Optional Object to lock N/A 3526 3527 3528 3529 3530 3531 3532 3533




6.1.2.1 vamAmplitudeCoeff 3534

3535 Source Creation Domain BTS object name BTSCell Sub-Managed Object name

VAMParameters

parameter name vamAmplitudeCoeff Definition The parameter defines four amplitude coefficients applicable to VAM matrix

in a MIMO or non-MIMO cell. activationFlag Optional feature Optional No Category Class 3 Associated Event Range Fixed(4) List of Float 0..1 step 0.000000001 (i.e. step 10exp-9) Unit Initial values {0.707106781, 0.707106781, 0.707106781, 0.707106781} Recommended value Upgrade rule No Check rule 3536 Note: This is RAN model. in the BTS model and ASN1, the VAM parameter are INTEGER. The PQ3 3537 receives the parameters with this format and shall do a conversion (multiply the parameter by 10exp9) 3538 as detailed in the algorithm document [R12]. 3539




6.1.2.2 vamPhaseCoeff 3540

Source Creation Domain BTS object name BTSCell Sub-Managed Object name

VAMParameters

parameter name vamPhaseCoeff Definition The parameter defines four phase coefficients applicable to VAM matrix in

a MIMO or non-MIMO cell. activationFlag Optional feature Optional No Category Class 3 Associated Event Range Fixed(4) List of INTEGER 0..359 step 1 Unit degree Initial values { 0, 135, 45, 0 } Recommended value

{0, 135, 45, 0} is THE tuning to be used on a MIMO cell with PCI codebook restriction in UA08. Other tunings are problematic in a MIMO cell in terms of PA usage balance and throughput degradation (see attachment for some W*VAM results) : {0, 90, 90, 0} leads to PA usage imbalance. {0, 0, 0, 0} is optimum for legacy non-MIMO UEs but results in ~24% cell throughput degradation with MIMO UE (see attached ppt). Note: {0, 0, 0, 0} can be used on a non-MIMO VAM cell. It is being analyzed whether {0, 0, 0, 0} is more optimum compared to {0, 135, 45, 0} for a non-MIMO VAM cell.

Upgrade rule No Check rule 3541




6.1.3 IsPrecodingWeightSetRestrictionPreferred 3542

Source Creation Domain BTS object name BTSCell parameter name isPrecodingWeightsetRestrictionPreferred Definition The parameter defines whether precoding weight set restriction is preferred

at the cell (sector-carrier). If enabled, the NodeB conveys the preference to RNC in NBAP AR/RSI message.

activationFlag Optional feature Optional No Category Class 3 A1 Associated Event Range Boolean (TRUE, FALSE) Unit Initial values TRUE Recommended value Upgrade rule No Check rule 3543 3544

6.1.4 nCqiTypeAMCqiRatio 3545

Source Creation Domain BTS object name HsdpaConf parameter name nCqiTypeAMCqiRatio Definition The parameter defines of ratio between the number N of dynamic

single/dual (Type A) CQI reports out of a sequence of M CQI reports in case the UE is configured in MIMO mode.

activationFlag Optional feature Optional No Category Class 3 Associated Event Next RL Setup or Reconfiguration Range ENUMERATED (1/2, 2/3, 3/4, 4/5, 5/6, 6/7, 7/8, 8/9, 9/10, 1/1) Unit Initial values 1/1 Recommended value Upgrade rule None Check rule 3546




6.1.5 hsScchType3SingleStreamSnr 3547

Source Creation Domain BTS object name HsdpaConf parameter name hsScchType3SingleStreamSnr Definition The parameter defines the symbol level SNR requirement of HS-SCCH

Type 3 of single stream transmission. activationFlag Optional feature Optional No Category Class 3 Associated Event Range Real [-5.0..19.0] step 0.1 dB Unit Initial values 1.4 dB Recommended value Upgrade rule None Check rule 3548

6.1.6 hsScchType3DualStreamSnr 3549

Source Creation Domain BTS object name HsdpaConf parameter name hsScchType3DualStreamSnr Definition The parameter defines the symbol level SNR requirement of HS-SCCH

Type 3 of dual streams transmission. activationFlag Optional feature Optional No Category Class 3 Associated Event Range Real [-5.0..19.0] step 0.1 dB Unit Initial values 2.3 dB Recommended value Upgrade rule None Check rule 3550

6.1.7 DualCellHsdpaMimoMaxNumberUserEcem 3551

It is not strictly speaking a new parameter because this BTS parameter is shared with the 2 features 3552 Dual Cell HSDPA Capacity Increase and MIMO. 3553 3554 It is used by the operator in order to limit the real maximum number of DC and MIMO users combined 3555 that can be handled by the eCEM board. 3556 3557 Warning: This parameter is unconnected with a possible way to limit, at the RNC level, the number of 3558 users per cell , as suggested in requirement R1 of FRS Dual Cell HSDPA Capacity Increase [R14]. 3559




Source Creation Domain BTS object name BTSEquipement parameter name dualCellHsdpaMimoMaxNumberUserEcem Definition This parameter represents the Maximum number of DC-HSDPA and MIMO users

combined (logical channel) allowed per eCEM board. Each DC-HSDPA or MIMO user takes two resources, e.g. if value 15 is given, actually 30 resources will be taken from ECEM board and thus, number of legacy HSDPA users is 128 – 30 (rather than 128 – 15). For UA08 release, there will be an internal limit on max number of combined DC-HSDPA MIMO users per ECEM. This limit is named internalMaxMIMODualCellHsdpaUsersAllowed, its value is limited to 15. Moreover, internalMaxMIMODualCellHsdpaUsersAllowed is not configurable. If value of dualCellHsdpaMimoMaxNumberUserEcem is greater than the internal limit, the kept value is the MIN(dualCellHsdpaMimoMaxNumberUserEcem, internalMaxMIMODualCellHsdpaUsersAllowed).

activationFlag Optional feature Optional No Category Class 3-A1 Associated Event Range [1..64] Unit Integer Initial values 15 Recommended value 15 Upgrade rule No Check rule No 3560

3561

3562

3563

3564




6.2 FAULT MANAGEMENT 3565

6.2.1 Alarms 3566

UNSUPPORTED EQUIPMENT / CEM alarm is used to indicate that the BTS hardware (CEM or PA) is 3567 not compatible with MIMO configuration as described I section 4.6.1.2. The description (Reason field) of 3568 this alarm shall be updated in order to include MIMO case, i.e. add the following text "the CEM is iCEM 3569 or xCEM and the cell is configured with MIMO and/or VAM". 3570 3571 The existing TX Path Failure alarms cannot be used in the context of MIMO because those alarms 3572 reflect a total outage of the BTSCells while in MIMO configuration, the service is still possible although 3573 in degraded mode. A new alarm “PARTIAL TX FAILURE ” is created for this purpose: 3574 3575 (1) Alarm cause M (v3) PARTIAL TX FAILURE (2) Cause value TBD

(3) Object class M ANTENNA ACCESS

(4) Equipment type M SECTOR

(5) Description M This alarm indicates that one of the two TX paths has failed on a sector

(6) Reason M One of the two Tx paths is lost for the cells configured on this sector (vam or vamAndMimo)

(7) Impacts M Associated BTS cell works only with a single Tx path.

(8) Maintenance action M

Check radio equipment and restart them if necessary. If the equipment has to be replaced, refer to UMTS BTS Hardware Maintenance Guides.

(9) EventType M equipmentAlarm (10) ProbableCause M equipmentMalfunction (11) PerceivedSeverity M Minor/Cleared (12) For BTSs All (13) Dallas info - - (14) Manuf-info - - (15) PCM info - - (16) IP info - - (17) First version M UA 08 (18) Introduction reason M FRS 83984 (19) Comments - 3576




3577

6.2.2 Errors Message List 3578

The following table sums up the errors associated to MIMO. It shows also the relationship with other 3579 features for interworking (e.g. Dual Cell Capacity Increase). 3580 3581 Not a new Error message

3582 Received message Presence of IEs Error/Type/Cause Additional error condition Error Reference CELL SETUP REQUEST

IE MIMO Pilot Configuration or IE MIMO Pilot Configuration Extension

CELL SETUP FAILURE Logical error MIMO not available

Cell not MIMO Capable Err_Mess 4.1.2.3-1

CELL SETUP REQUEST

IE Secondary CPICH Information

CELL SETUP FAILURE Logical error MIMO not available


CELL RECONFIGURATION

IE MIMO Pilot Configuration or IE MIMO Pilot Configuration Extension

CELL RECONF FAILURE Logical error MIMO not available


RADIO LINK SETUP IE MIMO Activation Indicator And/or IE Sixtyfour QAM usage Allowed

RL SETUP FAILURE Logical error Semantic error

IE Sixtyfour QAM usage Allowed=”Allowed” And IE HS-DSCH MAC-d PDU size format ≠ “Flexible MAC-d PDU size”

Err_Mess 4.1.2.5-1

RADIO LINK SETUP IE MIMO Activation And IE Additional HS cell Information RL Setup

RL SETUP FAILURE Logical error MIMO not available

Err_Mess 4.1.2.5-2

RADIO LINK RECONF PREPARE

RL RECONF FAILURE

See error reference Err_Mess 4.1.2.6-1


IE MIMO Activation And IE Additional HS cell Information RL Reconf Prepare

RL SETUP FAILURE Logical error MIMO not available

Err_Mess 4.1.2.6-2

RADIO LINK ADDITION

IE HS-DSCH FDD Information

RL ADDITION FAILURE Requested configuration not supported

IE present Err_Mess 4.1.2.7-1

CELL SETUP REQUEST

IE Primary CPICH Information >Transmit Diversity Indicator

CELL SETUP FAILURE Requested Tx Diversity Mode not supported

Transmit Diversity Indicator =active

Err_Mess 4.6.2.2-1

CELL SETUP REQUEST

IE MIMO Pilot Configuration

CELL SETUP FAILURE Requested Configuration not supported

>Pilot Configuration present Or MIMO Pilot Configuration = “Normal and Diversity Primary CPICH”

Err_Mess 4.6.2.2-2

CELL SETUP REQUEST

IE Secondary CPICH Information > Transmit Diversity Indicator

CELL RECONFIGURATION FAILURE Radio network Layer cause = Requested Tx Diversity not supported”

Transmit Diversity Indicator=active

Err_Mess 4.6.2.2-3

RADIO LINK SETUP REQUEST

RADIO LINK SETUP FAILURE MIMO Not Available



IE MIMO Activation RADIO LINK SETUP FAILURE Protocol cause=Semantic error

IE Sixtyfour QAM Usage=Allowed And IE HS-DSCH MAC-d PDU size Format

Err_Mess 4.6.2.2-5

RADIO LINK SETUP IE MIMO Activation RADIO LINK SETUP IE HS-PDSCH Physical layer Err_Mess 4.6.2.2-6




REQUEST And IE Sixtyfour QAM Usage=Not Allowed

FAILURE Protocol cause=Semantic error

category not in range [15..20]


IE MIMO Activation And IE Sixtyfour QAM Usage=Allowed

RADIO LINK SETUP FAILURE Protocol cause=Semantic error

IE HS-PDSCH Physical layer category not in range [19..20]

Err_Mess 4.6.2.2-7


IE MIMO Activation

RADIO LINK SETUP FAILURE FDD MIMO not Available

Allocation failure: max number of DC+MIMO users exceeds limit

Err_Mess 4.6.2.2-8


HS-DSCH Physical layer Category > HS-DSCH Information to modify

RADIO LINK RECONFIGURATION FAILURE MIMO not available




RADIO LINK RECONFIGURATION FAILURE

See reference for condition Err_Mess 4.6.2.2-10



RADIO LINK RECONFIGURATION FAILURE Protocol cause=Semantic error

See reference for condition Err_Mess 4.6.2.2-11

3583 Table 6-1 Error message list 3584

3585 3586 3587

6.3 PERFORMANCE MANAGEMENT 3588

6.3.1 Counters 3589

6.3.1.1 Counters for the measurement of the Tx powe rs 3590

Counter #10205 shall be modified in order to report 2 separated screenings for the mean power 3591 information for the Main PA (i.e. Physical antenna 1) and the Div PA (.i.e. Physical antenna 2). 3592 The sum of the 2 screenings gives the operator the combined mean power for the cell. 3593 3594 Counter #10225 is retained with its existing functionality, but for Cells with Tx diversity such as MIMO 3595 cells this counter reports the distribution curve of the combined power information for the Main PA and 3596 the Div PA. 3597 Avoid misunderstanding: the operation to be performed here is not the combining of the distribution 3598 curves of powers but the distribution curve of the combined powers. 3599 3600 Just add to the counter description: “For Cells with Tx diversity such as MIMO cells, this counter 3601 provides the distribution curve of the combined power of Main & Div Tx transmitters”. 3602 It is up to the OAM CCM to sum the two powers from Main PA and Div PA, which come from separated 3603 radio boards. 3604 3605 Two new counters #10228 & #10229 (as an example), under object “BTSCell”, are added in order to 3606 report separated distribution curves for PA Main and PA Div. Their format is the same as for counter 3607 #10225. 3608 3609 Since the radio boards ignore which PA is Main or Div, it is up to the CCM OAM to peg the 2 PA power 3610 measurements to the appropriate counters #10228 and #10229. 3611 3612




6.3.1.2 Introduction of new UE categories: 3613

Counters #10825 and #10826 are not modified but associated screening is modified to take into account 3614 UE categories 19 and 20 (already done for DC-HSDPA which added categories 21, 22, 23 and 24). 3615 3616 3617

6.3.1.3 Counters that shall take into account dual streams for MIMO UE’s. 3618

3619 Counter_Name Meaning Impact #10806 HsdpaMACdPDUAckBits

Number of successfully transmitted MAC-d PDU bits (an ACK has been received for the corresponding transport block).

For MIMO UE, calculate bits transmitted per cell. Same as for legacy UE.

#10807 HsdpaRxDataBitsMAChs

Number of data bits received by the NodeB. It corresponds to the bits of all the MAC-d PDUs received in every FP data frame

For MIMO UE, calculate bits received per cell. Same as for legacy UE.

#10808 HsdpaTxDataBitsMAChs

Number of data bits (transport block size) first transmitted by the MAC-hs. The retransmissions are then not taken into account, meaning that a block retransmitted several times is only taken into account once at the first transmission.


#10809 HsdpaTxDataBitsSchedTotal

Number of data bits (transport block size) scheduled any TTI, taking into account the retransmissions. Any time a block is retransmitted, its bits are added.


#10810 HsdpaNbrACKRcv

Number of acknowledged transport blocks ('ACK' received for a transmitted transport block).

For MIMO UE, calculate transport blocks acknowledged per cell taking into account both single and dual stream transmissions.

#10811 HsdpaNbrNACKRcv

Number of negatively acknowledged transport blocks ('NACK' received for a transmitted transport block).

For MIMO UE, calculate transport blocks negatively acknowledged per cell taking into account both single and dual stream transmissions.

#10812 HsdpaNbrDTX

Number of DTX detected (neither 'ACK' nor 'NACK' received for a transmitted transport block).

For MIMO UE, calculate DTX received per cell taking into account both single and dual stream transmissions.

#10813 HsdpaDiscMACdPDUsTimerExpiry

Number of MAC-d PDUs that have been discarded due to 'discard timer' expiration.

For MIMO UEs, the procedure remains same as for legacy UEs.

#10814 HsdpaDiscTransportBlocksOnMaxRetrans

Number of transport blocks that have been discarded because the maximum number of retransmissions was reached.

For MIMO UE, calculate transport blocks discarded per cell.

#10815 HsdpaMeanNbrRetrans

Number of necessary retransmissions for acknowledged Transport blocks (0 means the block has been correctly received after the first transmission). The blocks discarded due to the maximum number of retransmissions

For MIMO UE, calculate number of retransmissions per cell.




reached are not taken into account. #10816 HsdpaDataBufferedNodeB

Number of data Kbits (MAC-d PDU bits) buffered in NodeB. Each 100ms, the counter is updated by the averaged value during this period. Min and max values are nevertheless updated on a TTI basis.


#10819 HsdpaReceivedCQI

level of UE quality reception for HSDPA For MIMO UE, provide CQI received per cell. CQI range is 0-255.

#10825 HsdpaTTIperUEcat

number of TTI for which there is data to be transmitted, per UE category

For MIMO UE, calculate per cell.

#10826 HsdpaTxDataBitPerUEcat

Number of transmitted bits, per UE category (only first transmissions are considered)

For MIMO UE, calculate per cell

#10828 HsdpaNbUserWithDataTTI

Number of users with data to transmit For MIMO UE, the procedure remains same as for legacy UEs.

#10829 HsdpaBufferDelay

Distribution of number of PDU's with delay between the request and the first transmission of MAC-d PDUs


#10830 HsdpaMACdPDUAckBitsForGbr

Total number of successfully transmitted MAC-d PDU bits (an ACK has been received for the corresponding transport block) for flows configured with a non null GBR.


#10833 HsdpaGbrDeficitRatioPerSpi

This counter represents the observed throughput deficit over a given period (1s) due to radio congestion, expressed as a percentage of configured GBR for all unsatisfied GBR flows.

For MIMO UE, the procedure remains same as for legacy UEs.

#10834 HsdpaGbrSatisfiedFlows

Number of flows per sampling period (1s) that either fulfil their GBR or that are in starvation (cause external to NodeB).


#10837 HsdpaMACdPDUAckBitsPerSPI

Number of successfully transmitted MAC-d PDU bits (an ACK has been received for the corresponding transport block), per SPI


#10841 HsdpaModulationType

Number of scheduled mobiles using 16QAM, 64QAM or QPSK

For MIMO UE, take into account both single stream and dual stream transmissions.

#10844 HsdpaGbrCodeRatio

This measurement provides a distribution of the ratio of number of SF16 codes used to schedule GBR users to the total number of HS-PDSCH codes available.


#10846 HsdpaProvidedBitRate

Provided bit rate is calculated For MIMO UE, the procedure remains same as for legacy UEs.

#10848 HsdpaGbrFailedFlows

Number of GBR flows per sampling period that failed with their respected rates


3620 3621

6.3.1.4 Information concerning Single stream/Dual S tream statistics 3622

A new counter #10850 HsdpaMimoDualStreamFraction is introduced. 3623 3624




#10850 Counter_Name: HsdpaMimoDualStreamFraction FRS: 83984 FRS_name: MIMO Standard: No Apply to: BTSCellHSDPA Unit: Percentage Range:

0 - 100 Type: CUM

Meaning: Define fraction of HSDPA MIMO dual stream transmission out of the total (single and dual stream) transmitted in 2 ms TTI Triggering event: Updated at each TTI: +1 only if data to be transmitted (per category) First release: UA8.0 Last release: Family: HSDPA statistics Screening: according to the UE category - table SCR_11 Notes: Evolution:

3625




7 O&M PROCEDURES 3626

7.1 WCDMA IBTS UPGRADE 3627

Deals with introduction of this feature on a real network. 3628

Parameter setting to ensure iso functionality on release upgrade: 3629

• DualPaUsage shall be set to “None”. 3630

Feature activation 3631

• DualPaUsage shall be set to “VamAndMimo”. 3632

7.2 BENIGNESS, BACKWARD COMPATIBILITY 3633

Feature activation should not affect processing for legacy non-MIMO capable UEs. No functional 3634 regression should be required for these legacy UEs. However, as mentioned in Section 4.8.3, total 3635 number of HSDPA users supported per modem board gets affected due to extra resources required for 3636 MIMO users. 3637

Feature de-activation should not affect processing for legacy non MIMO capable UEs. In this case, even 3638 the number of HSDPA users supported per modem board should not degrade (isofunctional as pre-3639 MIMOHSDPA feature implementation). Note that to achieve isofunctionality, all HSDPA cells hosted on 3640 that modem board should have feature deactivated. 3641

Feature de-activation will also declare corresponding local cells as MIMO Not Capable to RNC. RNC 3642 should not place any call requiring MIMO capability for this local cell, but if this happens (inconsistent 3643 RNC behavior), iBTS will reject such calls. 3644

7.3 INSTALLATION AND COMMISSIONING 3645

No impacts. 3646

7.4 WIPS TOOL 3647

WIPS tool shall be modified to check the consistency between MIMO activation and HW available. The 3648 objective is to make sure that verification is done within the configuration tool before the RNC and NodeB 3649 configuration parameters are downloaded in the equipment. 3650

WIPS tools is out of the scope of this document and checks for MIMO are described in the FTS 3651 document [A1]. 3652

8 FIELD INTRODUCTION 3653

8.1 HARDWARE CONSTRAINTS 3654

See section 4.3. 3655

8.2 MS INTERWORKING 3656

3GPP Rel-8 UE supporting the feature (Categories 15, 16, 17, 18, 19, 20). 3657




9 TOOLS IMPACTS 3658

9.1 TIL IMPACTS 3659

No impacts 3660

9.2 CDM IMPACTS 3661

9.2.1 CDM reported by PQ3 3662

3663

The following structures shall take into account the reports of measurement for two streams. 3664

For the moment, these structures evoluate with Dual Cell feature to consider two measurement reports 3665 per UE Context (one per cell). With MIMO, we add two measurement reports per UE context in the 3666 same cell. The constant CDM_MAX_NUM_HSD_CELLS_PER_UE_CXT should be extended for MIMO 3667 and replaced by CDM_MAX_HSD_REPORTS_PER_UE_CXT (value 4). For the structure only impacted 3668 by MIMO, the constant CDM_MAX_NUM_HSD_STREAMS_PER_UE_CXT (value 2) shall be used to 3669 take into account the two measurements report per UE Context. 3670

3671

CdmHsdReportInd_t 3672

>CdmHsdReport 3673

>>CdmHarqAckSummaryData[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3674

>> CdmHarqAckDetailData[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3675

>>CdmDeltaUiDetailData[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3676

>>CdmCqiValueDetailData[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3677

>> CdmHsdpaAckNackInfoDetailData[CDM_MAX_NUM_HSD_STREAMS_PER_UE_CXT] 3678

>>> ack_nack_info_flags[CDM_MAX_HSD_MEAS] : 3679

bit 0: HS_MIMO; currently unused (needs to be updated) 3680

bit 1: HS_DUAL_CELL; currently unused(needs to be updated) 3681

bit 2: HS_SC_DC; currently unused(needs to be updated) 3682

bit 3: HS_HDSC; currently unused(needs to be updated) 3683

>>CdmHsScchDataDetailData[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3684

>>CdmSinrDbDetailData[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3685

>>CdmSeDetailData[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3686

>> CdmHsDschTbSizeDetailData[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3687

>>CdmHarqAckSummaryData[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3688

>>CdmCqiCpichMeasurementDetailData 3689

>>>CQI_Info[CDM_MAX_HSD_REPORTS_PER_UE_CXT] [CDM_MAX_HSD_MEAS] 3690

>> CdmCqiValueSummaryData 3691

>>> cqi_value_min[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3692

>>> cqi_value_max[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3693




>>> cqi_value_mean[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3694

>>CdmCqiValueSummaryDataReduced 3695

>>> cqi_value_min[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3696

>>> cqi_value_max[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3697

>>> cqi_value_mean[CDM_MAX_HSD_REPORTS_PER_UE_CXT] 3698

3699

CdmHsdpaCellReportInd 3700

>CdmHsdpaCellReport 3701

>> CdmHsdpaCellAllUesReportFullDetailData 3702

>>> CdmHsdpaCellUeFullDetailedData[][CDM_MAX_NUM_HSD_STREAMS_PER_UE_CXT] 3703

>>CdmHsdpaCellAllUesReportHarqDetailData 3704

>>>CdmHsdpaCellUeHarqDetailedData[][CDM_MAX_NUM_HSD_STREAMS_PER_UE_CXT] 3705

>>CdmHsdpaCellAllUesReportSchedulingInfoDetailData 3706

3707 >>>CdmHsdpaCellUeSchedulingInfoDetailedData[][CDM_MAX_NUM_HSD_STREAMS_PER_UE_CXT3708 ] 3709

>>CdmHsdpaPerfMeasSummaryData 3710

>>>CdmHsdpaMacHsPerfMeasReport 3711

3712 >>>>(word8)HsdpaMimoDualStreamFraction[NBAP_MAX_HSDSCH_PHYSICAL_LAYER_CATEGORY3713 +1]; : Defines fraction of HSDPA MIMO dual stream transmission out of the total (single and dual 3714 stream) 3715

9.2.2 CDM reported by PQ2 CallP CEM 3716

3717 New HSDPA “MIMO activation indicator”. 3718

3719




10 OPEN ISSUES 3720

3721 3722 3723 3724

Item Description Status 1. Counters #10205 and #10225 are duplicated for Main and Div Tx transmitters but the exact

way the PM provides screens is to be detailed CLOSED

2. For TCP measurement CCM CallP needs to know which the Tx Main to launch the measurement is. The way this information is provided by CCM OAM needs further investigations.

OPEN

3. CDM impacts are not defined. CLOSED

4. Interworking between MIMO and DC HSDPA CLOSED

5. Possible simplification of the VAM pair selection mapping The pair selection mappers are removed since the streams are always allocated using a constant rule.

CLOSED

6. Quantization study for the polar to Cartesian conversion of VAM coefficients Shall be specified in Algorithm document [R12]

CLOSED

7. "NBAPR shall redo all the semantics checks of the NBAP protocol". Currently NBAPR does not redo the semantics checks. This is a "method" change. To discuss with eCEM CallP Team

OPEN

8. For DC-HSDPA, we are getting request to introduce OMC variable to control number of DC-HSDPA users per board. I believe same is requested for MIMO as well. This new requirement part of FRS 104832 “HSDPA Dual Cell phase 2” is not taken into account in the document.

CLOSED

9. If S-CPICH has different SF Code, then why extra resources are not allocated on CE for S-CPICH? Load Balancing impacts? To be checked. PSB-BBR is used to manage SCH, P-CPICH and S-CPICH. The SF for S-CPICH is 256.

OPEN

10. As done (or going to be) in the DC FN, the real throughput should be highlighted here. There are some limitations implemented for 64QAM. The actual max throughput is not and will never be 21.6Mbps ! So the max MIMO throughput will never be 43Mbps. Also, for Dual cell there are some ongoing discussions wrt the achievable throughput depending if the xCCM has a FE MDA or a GE MDA. Conclusions of these discussions/tests will have to be highlighted in this FN as well.

OPEN

11. Are we sure EVM requirements allow top achieve those peak throughput values even in very ideal radio conditions? According to the issues we already had to be able to achieve 20 Mbps with 64 QAM only, I doubt that it is possible to achieve 43 Mbps with MIMO on top of 64 QAM. Inorder to anticipate such issues, a study should be carried on about the EVM impact on performance, and what are the realistic figures we can get, and what has to be done specifically to avoid similar issues observed when testing 64 QAM.

OPEN

12. New iteration 1.6 of FRS 83984 is not taken into account in the document. CLOSED

13. Uppon which causes CemScpichPowerOffsetReconfFail can occur? See section 5.2.1 ITF2: CCM CallP – eCEM CallP

OPEN

14. MIMO resources for the uplink are different of uplink resources in uplink for DualCell: is common OAM parameter for DC+MIMO still valid?

CLOSED

15. Impact to CCM Core OAM and REproxy Possible impact to the CPRI interface.

OPEN

16. The exact use case of license Increase/Decrease given in section 4.6.1.7.1 is to be clarified OPEN




11 ABBREVIATIONS & DEFINITIONS 3725

3726 3GPP 3rd Generation Partnership Project 3727 ALCAP Access Link Control Application Part 3728 ALTP Alcatel-Lucent Technical Publication 3729 DR1 Level of feature maturity allowing a code start (note: not the DR1 for the global program) 3730 FRS Feature Requirement Specification, usually created by PLM and capturing "business 3731

level" requirements. 3732 FTS Feature Technical Specification, technical counterpart of the FRS produced by Systems 3733

Engineering / Design or Feature Architecture Prime 3734 3735 AWGN Additive White Gaussian Noise 3736 BBR BaseBand Ressource (CE Controller component) 3737 BLER Block Error Rate 3738 BRM Board Resource Manager (in CallP) 3739 CAC Call Admission Control 3740 CCC Control Channel Controller 3741 CCM Core Control Module 3742 CE Channel Element 3743 CEM Channel Element Modem boards (can be xCEM, eCEM etc.) 3744 CPIF PQ2/PQ3 Interface on CEM board (ITF7) 3745 CPRI Common public Radio Interface 3746 CQI Channel Quality Indicator 3747 CR Channel Rate 3748 CRC Cyclic Redundancy Check 3749 DCC Data Channel Controller 3750 DDM Dual Duplexer Module 3751 DDU Digital Data Unit / Digital Distribution Unit 3752 DTX Discontinuous Transmission 3753 DTxAA Double Transmit Adaptive Array 3754 FA Frequency Allocation 3755 FPGA Field Programmable Gate Array (programmable hw component) 3756 GBR Guaranteed Bit-rate 3757 HARQ Hybrid Automatic Repeat Request 3758 HSDPA High Speed Downlink Packet Access 3759 HS-DSCH High Speed Downlink Shared Channel 3760 HS-PDSCH High Speed Physical Downlink Shared Channel 3761 HS-SCCH High Speed Shared Control Channel 3762 HSSL High Speed Serial Link 3763 IE Information Element 3764 iMCTA intelligent Multi-Carrier Traffic Allocation 3765 LUT Look-up Table 3766 M*N M Transmit Antenna, N Receive Antenna 3767 MCPA Multiple Carrier Power Amplifier 3768 MIMO Multiple Input Multiple Output 3769 MMSE Minimised Mean Square Error 3770 MRC Maximum Ratio Combining 3771 NBAP NodeB Application Part 3772 NBAPR NBAP Router 3773 NMSE Normalised Mean Square Error 3774 N/M Ratio Ratio between Type_A and Type_B CQI reports 3775 NVAR Normalized Variance 3776 OAL OAM Abstraction Layer (ITF4) 3777




OAM Operation And Maintenance 3778 OCC OneChip Controller (OneChip Firmware) 3779 OVSF Orthogonal Variable Spreading Factor 3780 P-CPICH Primary Common Pilot Channel 3781 PA Power Amplifier 3782 PCI Precoding Control Indication 3783 PDU Protocol Data Unit 3784 PQ Priority Queue 3785 PTB Primary Transport Block 3786 16QAM 16ary Quadrature Amplitude Modulation 3787 64QAM 64ary Quadrature Amplitude Modulation 3788 QPSK Quadrature Phase Shift Keying 3789 R&CV Redundancy & Constellation Version 3790 RL Radio Link 3791 RRH Remote Radio Head 3792 SBBLINK Baseband switch in the CCM board 3793 SCM Spatial Channel Model 3794 S-CPICH Secondary Common Pilot Channel 3795 SE Spectral Efficiency 3796 SINR Signal to Interference and Noise Ratio 3797 SLOAM 3798 SPI Service Priority Indicator 3799 STB Secondary Transport Block 3800 STSR 2/3 Sectorized Transmit Sectorized Receive 2: 2 carriers, 3: 3 carriers 3801 STTD Space Time Transmit Diversity 3802 TC Chip duration 3803 TFRC Transport Format Resource Combination 3804 TFRI Transport Format Resource Indicator 3805 TRDU Transmitter Receiver Duplexer Unit 3806 TRM Transceiver Radio Module 3807 TTI Transmission Time Interval 3808 TxAA Transmit Adaptive Array 3809 TxD Transmit Diversity 3810 Twin RRH RRH equipment with 2 transmitters. 3811 UE User Equipment 3812 VAM Virtual Antenna Mapping 3813 Wrt With respect to 3814




12 ANNEX 3815

This section is left for information but is not part of the MIMO specification. 3816

12.1 WORK TO ACHIEVE DELAYS ALIGMENT 3817

12.1.1 Constraints of delays for radio modules in M IMO 3818

When associating two MCPA/DDM or RRH or TRDU in MIMO in one sector, the main issue is the 3819 uncertainty in the calibration data of the MCPA/DDM or RRH or TRDU in case of heterogeneous family 3820 /vendor/ variant. 3821 3822 Principles and performance impacts have been described in § 4.2.1 3823 3824 The following paragraphs 3825

• describe the targets to achieve delay alignment in TX paths and RX paths, in Macro iBTS, RRH, 3826 or TRDU. 3827

• Define which radio module will be ok for MIMO. 3828 3829

12.1.2 Delay alignments of TX paths 3830

12.1.2.1 R&D approach to associate 2 radio modules in a MIMO sector 3831

In a given sector, the MIMO solution associates: 3832 3833

o 2 MCPA (MCPA 1 and MCPA2 are of any kind among all models), 3834 o If the MCPAs used are of the same model, the delay dispersion is low and we will not need 3835

any realignment. In case where MCPA are model different, we shall realign delays, Delay 3836 provisioned on each MCPA has been verified in Lab. 3837

3838 o or 2 RRH (RRH 1 and RRH 2 are of same model, same Peccode) 3839

3840 o or 2 TRDU (TRDU 1 and TRDU 2 are of same model, same Peccode) 3841

3842 The next paragraphs deal with the calibration quality: 3843 3844 A first paragraph focuses on delay dispersion for any couple of radio modules associated in a MIMO 3845 sector. A delay dispersion constraint is computed to allow to associate any MCPA with any MCPA, or 3846 any RRH with any RRH, any TRDU with any TRDU. 3847 3848 A second paragraph, we study whether the delay decared by MCPAs are real with respect to what the 3849 firmware declares. 3850 3851 A 3rd paragraph defines MCPA mixity rules 3852 A 4th paragraph talks about RRH40-21 delays. 3853

3854

12.1.2.2 Computation of TX delay constraint for a r adio module 3855

The modem compensates for the mean delay (model1) and mean delay(model2), the difference of 3856 delays will have an average of zero but with a certain dispersion (variance) of the MCPA populations 3857 3858 What is the dispersion of delay difference? Mean (µ) and standard deviation (σ). 3859




3860 Notations: 3861 D1= delay of MCPA model1 3862 D2= delay of MCPA model2 3863 Variance = σ² 3864 Standard deviation = square root of variance 3865 Standard deviation = σ 3866 Tc= 1/3840000 = 260ns 3867 Tc/4= 65ns 3868 3869 The square root of variance of the difference of delays (D1-D2) must be compatible of the accuracy of 3870 +/- (Tc/4) 3871

3872 Variance (D1-D2) = Variance(D1)+ Variance(D2) 3873

3874 Variance (D1-D2) < (TC/4)² 3875

3876 As we are looking for a constraint on an individual radio unit, we assume here that they are all 3877 respecting a same limit of variation: 3878 Variance(D1)= Variance(D2) 3879 3880

Variance(D1)+ Variance(D2) < (TC/4)² 3881 2 Variance (Di) < (TC/4)² 3882

Variance (Di) < (1/2)*(TC/4)² 3883 3884

σ <(1/ √2) (Tc/4) 3885 Finally 3886

σ < 46ns 3887

A radio unit (MCPA or RRH or TRDU) should have a de lay variation 3888

smaller than 46ns across the product population 3889 Where populations are : 3890 3891

o Population1: all MCPA in same band, same power 3892

o Population 2: RRH of same power 3893

o Population 3: TRDUs 3894

12.1.2.3 Dispersion of TX delays of radio modules 3895

MCPA vendors have given statistics of delay dispersion across the population of MCPA, RRH, TRDU 3896 that they deliver; these statistics are in the following table (focused on 2100MHz band) 3897

3898

Radio module

Manufacturer Pec code

Pop

ulat

ion

dep

loye

d

Delay statistics requested to product manufactu

rer

Delay statistics (known / Unknown By Alcatel Lucent)

Average delay

µ in ns

Delay variation

(standard deviation

)

σ in ns

Are delays stable

enough to use

this unit in MIMO sector?

σ<46ns




Radio module

Manufacturer Pec code

Pop

ulat

ion

dep

loye

d

Delay statistics requested to product manufactu

rer

Delay statistics (known / Unknown By Alcatel Lucent)

Average delay

µ in ns

Delay variation

(standard deviation

)

σ in ns

Are delays stable

enough to use

this unit in MIMO sector?

σ<46ns

MCPA 45W Powerwave NTUM30AA 23491

Unknown Delay not

declared by this PA. Default

value to be used by CCM OAM

MCPA 45W Powerwave

Yes (mail JL Galiez 7th July 2008, 17th Sept

2008)

Unknown

MCPA 45W Remec Unknown

MCPA 45W TAZ1.0

Andrew

NTUM30CA 42240

Yes Counted on 364 units

82.256

0.136 Min

81.886 Max

82.668

OK

MCPA 45W MCPA-3 TAZ1.5

Andrew NTUM90EA 37600 Yes Counted on 331 units

73.79 0.17 OK

MCPA60W-B (BBPD)

Alcatel-Lucent NTUM30WA 2800 Not

supported

MCPA60W-A Andrew NTUM30FM 10500 Yes Counted on

140 units 74.50 0.21 OK

RRH 40-21 TX path Yes Counted on

798 units 13.23 OK

RRH 40-21 RX path

Alcatel-Lucent

Yes Counted on 798 units)

140 This is a hw bug

that will be corrected

for most of the

population

OK

after bug correction

RRH 60-21 Andrew Yes Unknown

TRDU 40-21 Andrew

Yes (Message to

Andrew A Pierrard 10th Sept 2008)

Unknown

3899 3900 3901




12.1.2.4 Measured delay in MCPA versus firmware del ay 3902

12.1.2.4.1 Influence of MCPA technology on Delay va riation 3903

MCPAs have no integrated filter. 3904 3905 MCPAs implementing the feed forward technology such as Powerwave 3906

o The propagation delay is very small :~11 12 ns 3907 o The delay dispersion across population is negligible (delay line length <<8ns) 3908

3909 MCPAs implementing the cross cancellation technology such as Remec : 3910

o The propagation delay is small 3911 o The delay dispersion across population is negligible (delay line length) 3912

3913 MCPAs implementing the ADPD technology (ADPD :Adaptive Digital Predistortion) 3914

o The propagation delay is larger 3915 o The delay dispersion across population is negligible 3916 o Signal is demodulated down to base band to deduce correction to adjust the RF (via a vector 3917

modulator) 3918 o Delay line length are larger but constant => constant delay. 3919

3920

12.1.2.4.2 Table of MCPA measured delays 3921

The following table compares real MCPA delays and delays declared by MCPA firmware 3922 3923 Real delays have been measured in Alcatel-Lucent radio laboratory on the following MCPA models: 3924 3925

code Original design

HW release

SW release

measured delay

(B/M/T) in ns

delay coded (ns)

Difference

2100MHz/45W/4C NTUM30AA PW V2 25 34 None None

2100MHz/45W/4C NTUM30AA ANDREW V04 01

85 / 82 / 84

81,3 < 4ns

2100MHz/45W/4C NTUM30AA REMEC ??

19 / 19 / 20

16,26 < 4ns

2100MHz/45W/4C NTUM30CA ANDREW V04 01

85 / 82 / 84

81,3 < 4ns

2100MHz/45W/4C NTUM30CA REMEC ??

19 / 19 / 20

16,26 < 4ns

2100MHz/45W/3C NTUM90EA ANDREW V03 02 75 all 73,17 < 2ns

2100MHz/45W/3C NTUM90EA POWERWAVE V01.06 19 16,26 < 3ns

2100MHz/60W/3C 3JR 21100 AA ANDREW Kirk 01 V01 04 < 4ns

2100MHz/60W/3C NTUM30FM ANDREW (012710): V01.10 75 73,17 < 2ns

1900MHz/60W/2C 3JR 21001 BA ANDREW not exist

900MHz/55W/1C NTUM30GA ANDREW V04 08

89 / 82 / 89 81,3

< 8ns

900MHz/55W/2C 3JR 21000 HA/

NTUM30EM ANDREW 90 / 81/ 89 81,3 < 8ns

850MHz/45W/2C NTUM30EA ANDREW V03 02

84 / 83 / 85

81,3 < 4ns

1800MHz/45W/3C NTUM30DA ANDREW 74 /74 / 77 73,17 < 4ns

1900MHz/45W/3C NTUM30PA ANDREW 32 to 34 ns 32,52 < 2ns




2100MHz/60W/2C NTUM30WA NORTEL 10 8,13 < 2ns 3926 This table shows that real MCPA delays are very close to delays declared by MCPA firmware: the 3927 difference is always below 8 ns while the acceptable tolerance is 46ns. 3928

3929 3930

12.1.2.5 MCPA mixity rules 3931

As firmware delays are trustable, we can define mixity rules for MCPA in MIMO solutions. 3932 3933 The 2 MCPA in a sector may be of different types (PEC code) MCPA delays will adjusted in xTRM 3934 according to MCPA delay in firmware (from the previous table, we know that this declared delay is very 3935 close to real delay). In case of MCPA mixity, if we need to realign transmit paths, we will use the 3936 “TX_INT_DELAY” value of BBPD FPGA, it enables the xTRM/xTRM2 to delay its TX path up to 1.5 Tc 3937 (394 ns) 3938

12.1.2.6 Delay aligment of TX paths with CPRI Radio modules 3939

This chapter deals with transmit realignment (Mandatory for MiMo or Tx div configuration), in case of 3940 transmit realignment, we shall take into account the delay difference between Main Path & Diversity 3941 Path. 3942 3943 Dl_Delay_Realignment_Main = 0; 3944 Dl_Delay_Realignment_Div = 0; 3945 3946 As the radio delay reported to CEM can be different from original delay (due to modem compensation of 3947 fiber) 3948 3949 Realignment (due to Fiber) 3950 If (T12(Main path) >= T12(Div path) ) 3951 Delay_Realignment_Main += T12(Main path) - T12(Div path); 3952 Else 3953 Delay_Realignment_Div += T12(Div path) - T12(Main path) ; 3954 3955 3956 RRH delays are modified in order to provide, to the CEM, delays multiple of UMTS Chip (Tc), as the 3957 delays are provided in Tc/32, the value provided must be a multiple of 32. 3958 3959 Integer DL Delay Main Path X = 32*ceil( (Global DL Delay Main Path X+ Dl_Delay_Realignment_Main) /32); next integer part 3960 Integer DL Delay Div Path X = 32*ceil( (Global DL Delay Div Path X + Dl_Delay_Realignment_Div /32); // next integer part 3961 3962 RRH_OAM_DL_Delay_Main += (Integer DL Delay Main Path X - Global DL Delay Main Path X) ; // RRH delays to CEM 3963 RRH_OAM_DL_Delay_Div += (Integer DL Delay Div Path X - Global DL Delay Div Path X); // RRH delays to CEM 3964 3965 RRH adjustment DL Delay Main Path X = (Integer DL Delay Main Path X - (Global DL Delay Main Path 3966 X+Delay_Realignment_Main )) 3967 RRH adjustment DL Delay Div Path X = (Integer DL Delay Div Path X - (Global DL Delay Div Path X + 3968 Delay_Realignment_Div)); 3969 3970 Integer delay compensation 3971 The integer part is compensated in the modem. 3972 3973 Global DL Delay Main Path & Global DL Delay Div Path are the sum of all the different delays collected 3974 by OAM CCM: 3975 3976 DL = DL (CCM) + DL (TRM) + DL (PA) + DL (DDM) + DL (TMA) + DL (TxSplitter) + DL (Cable) 3977 3978




As the delay between CEM and antenna is equal to the static delay DL delay, the difference for Main & 3979 Div path will be compensated by the modem. Once Fractional delay part is added to the RRH we get a 3980 global delay which is equal to the integer part: 3981 3982 Global DL Delay Main Path = Integer DL Delay Main Path X ; 3983 Global DL Delay Div Path = Integer DL Delay Div Path X ; 3984 3985

Type: SPECIFIC_REQ Sub-type: LOCAL_CELL_DELAY Generic part Nb of Local Cell Id Local Cell Id #1 DL Delay Main Path #1 = CCM DL + RRH_OAM_DL_Delay_Main DL Delay Div Path #1 = CCM DL + RRH_OAM_DL_Delay_Div UL Delay Main and Div Path #1 UL Delay Div Path #1

3986 3987 RRH delay adjustment 3988 To achieve to a perfect correction of Main & Div path in the modem, we shall provide to the CEM delays 3989 which are multiple of Tc, as the delays are provided in Tc/32, the delays provided to the CEM shall be a 3990 multiple of 32. The RRH delay is compensated such global delay is a multiple of Tc, for that we use the 3991 CPRI C&M command RE_SetDelay_Request 3992 3993 -> RE_SetDelay_Request (old delay + RRH adjustment DL Delay Main Path X ); 3994 -> RE_SetDelay_Request (old delay + RRH adjustment DL Delay Div Path X ); 3995 3996 “old delay” is the original T2A provided by RRH 3997 //------------------------------------------------------------------------------------------------ 3998 3999




12.1.3 RRH Delay Alignment example in daisy chained configuration 4000

In this example : 4001

CPRI

BTS

Site 1

RRH RRH

3 sites x 1 sector x 2 FDDcellsTx and RX diversity

Site 2

RRH RRH

Site 3

RRH RRH

CPRI

BTS

Site 1

RRH RRH

Site 1

RRH RRHRRH RRH

3 sites x 1 sector x 2 FDDcellsTx and RX diversity

Site 2

RRH RRH

Site 2

RRH RRHRRH RRH

Site 3

RRH RRH

Site 3

RRH RRHRRH RRH

4002 Figure 19:RE in star. TX diversity 4003

4004 In our example we will focus on sector 1 which is formed with 2 RRHs to form a MiMo cell 4005 First RRH is a one kilometer away from D2U & second RRH is 20 meters away from first RRH. 4006 If we consider a refractive index of the fiber of 1.5, the propagation delay through 1km is 614 Tc/32, the 4007 propagation delay through 20m is 12Tc/32 4008 4009 In our example T14(1) = 1443; // is equal to 2 * 1Km + Toffset(1) + 191Tc/32 which correspond to the 4010 value found serdes loopback mode (on iCCMu). 4011 4012 Toffset(1) = 23; 4013 Toffset(2) = 23; 4014 TBdelay DL(1) = 5; 4015 TBdelay UL(1) = 67; 4016 NFrame_diff(1) = 96; // is expressed in Tc/32 so the value must be a multiple of 32. 4017 4018 First RRH: 4019 T12 = (T14(1) – Toffset(1))/2; 4020 = 710 4021 T34 = (T14(1) – Toffset(1))/2; 4022 = 710 4023 CCM_UL_BBLINK_OFFSET = mod(T14(1), 800); // Not used in this example 4024 = 643 4025 4026 Second RRH: 4027 T12 = (T14(1) + Nframe_diff(1) – Toffset(2) + TBdelayDL(1) - TBdelayUL(1) )/2 ; 4028 T12 = (1443 + 96 – 23 + 5 – 67)/2 4029 = 727 4030 4031 T34 = (T14(1) + Nframe_diff(1) – Toffset(2) - TBdelayDL(1) + TBdelayUL(1) )/2 ; 4032 T34 = (1443 + 96 – 23 -5 +67)/2 4033 = 789 4034




CCM_UL_BBLINK_OFFSET = mod(T14(1), 800); 4035 = 643 4036 4037 1) OAM CCM collects all different delays (startup & RF inventory ..): 4038 4039 Tx Main path: 4040 iCCMu(902) + RRH_T2A (1843); 4041 4042 Tx Div path: 4043 iCCMu(902) + RRH_T2A (1843); 4044 4045 Realignment (due to Fiber) 4046 T12(Div path) = 727 4047 T12(Main path) = 710 4048 4049 Dl_Delay_Realignment_Div += T12(Div path) - T12(Main path) ; 4050 = 17; 4051 4052 4053 It means that Div Signal arrives 17Tc/32 after Main path, which is correct (+5 for TBDL & +12 for 4054 20meters of cable) 4055 4056 4057 2) OAM CCM computes realignment delays: 4058 Integer DL Delay Main Path X = 32* ceil( (902 + 1843 +0 ) /32); // keeps only the integer delay part 4059 = 2752 4060 Integer DL Delay Div Path X = 32* ceil((902+1843+17) /32); // keeps only the integer delay part 4061 = 2784 4062 4063 RRH_OAM_DL_Delay_Main += (Integer DL Delay Main Path X - Global DL Delay Main Path X) ; // RRH delays to CEM 4064 = 1843 + (2752 - (902+1843)= 4065 = 1850 4066 RRH_OAM_DL_Delay_Div += (Integer DL Delay Div Path X - Global DL Delay Div Path X); // RRH delays to CEM 4067

= 1843 + (2784 - (902+1843)= 4068 = 1882 4069 4070 RRH adjustment DL Delay Main Path X = (Integer DL Delay Main Path X - (Global DL Delay Main Path 4071 X+Delay_Realignment_Main )) 4072 =( 2752 - (902+1843+0)) 4073 = 7; //we have to add 7Tc/32 on the xTRM Main 4074 RRH adjustment DL Delay Div Path X = 2784 - (902+1843+17) ; 4075 = 22; //we have to add 22Tc/32 on the xTRM Div 4076 4077 3 )OAM CCM provide delay to the modem: 4078 OAM CCM provide the localcelldelay(iCEM) or localcellconfig(xCEM) with downlink delay equal to 4079 integer part: 4080 4081 4082

0 Type: SPECIFIC_REQ 1 Sub-type: LOCAL_CELL_DELAY 2...7 Generic part 8 Nb of Local Cell Id 9-12 Local Cell Id #1 13-15 DL Delay Main Path #1 = 2752 16-18 DL Delay Div Path #1 = 2784

UL Delay Main and Div Path #1 19-21 UL Delay Div Path #1

4083 4) OAM CCM provide the residual part to the RRH: 4084 4085 RRH adjustment DL Delay Main Path X (first RRH) 4086

� SetDelay_req(MAIN_CONNECTOR, 1843 + 7); add 7 Tc/32 on RRH 4087




RRH adjustment DL Delay Div Path X (second RRH) 4088 � SetDelay_req(MAIN_CONNECTOR, 1843 + 22); add 22 Tc/32 on RRH 4089 4090 4091

5) Bilan 4092 4093 The CEM will delay its main path of (109Tc) – round(2752 / 32 ) = 23 Tc 4094 The CEM will delay its Div path of (109Tc) – round(2784 / 32 ) = 22 Tc 4095 4096 The RRH Main will have an additional delay of 7 Tc/32 4097 The RRH Div will have an additional delay of 22 Tc/32 4098 4099 Delay DL main = CEM(23*32) + iCCM(902) + Fiber_1km(614)+ RRH (1843 + 7) = 4102 Tc/32 4100 4101 Delay Div = CEM(22*32) + iCCM(902) + Fiber_1km(614) + TBdelayDL(5) + Fiber_20m(12) + RRH 4102 (1843 + 22) = 4102 Tc/32 4103

4104 Note: The final downlink delay is equal to static delay (109) + T12(1) 4105 4106

Input from RRH R&D - Mark Britton's 4107

Delay were measured in factory on CPRI RRH 2100MHZ Lucent design. 4108

Results are : 4109

Tx Delay 4110 � Measured at centre frequency. 4111 � Number of RRHs measured = 798 4112 � Variation = 13.53ns. 4113

4114 The variation when a single MTP was considered reduced to 7.5ns. 4115 4116 Therefore the transmit path can meet the MIMO requirements . 4117 4118 ACTION ITEM: The specification for the allowable measurement tolerance needs updated. It is 4119 currently at +/- 40 ns. It appears from the factory test that this tolerance can be tightened up quite a bit. 4120 The HW development team needs to confirm an achievable value that will avoid the issue with not 4121 meeting the differential delay requirements and at the same time not impact the yield level from the 4122 factory. 4123

12.1.4 Delay aligment of RX paths 4124

12.1.4.1 Delay alignments of RX paths in iBTS Macro 4125

There should be no issue on filter side for MIMO2*2 as the same DDM is driving the 2 antennae on the 4126 same DDM for a sector. 4127

12.1.4.2 Delay alignments of RX paths for CPRI modu les 4128

This chapter describes how to realign UL signal data path of data flow i(extracted from STSRx+y FN) 4129

In the MiMo configuration, there are two UL data paths from different RRH for each local cell, the UL 4130 delay difference between Main Path and Diversity Path is determined by these two factors: 4131

� CCM_UL_BBLINK_OFFSET 4132

The CCM_UL_BBLINK_OFFSET corresponds to the delay mismatch of the CCM due to the BBLINK 4133 reframing, the UL CCM propagation delay may be different for each optical link, the UL real CCM 4134 propagation delay = Fixed_VALUE - CCM_UL_BBLINK_OFFSET. 4135




CCM_UL_BBLINK_OFFSET = mod (T14 (1), 800) 4136

T14 (1) can be retrieved from the register of CPRI Driver: 4137

CPRI_Driver_Return_Code_t CPRI_R21_Coarse_Timer (u8 cpri_lid, u16* pvalue) 4138

� Uplink Optical propagation delay (T34) offset 4139

The optical fibers paired RRH used may have different length, in order to multiply UL signal from main 4140 and diversity path correctly, the UL optical delay offset should also be considered. 4141

Downlink: T12 = (T12 + T34 + ∑TBdelayDL(i) - ∑TBdelayUL(i) )/2, i=1, .., x-1 4142

= (T14 - Toffset + ∑TBdelayDL(i) - ∑TBdelayUL(i) )/2, i=1, .., x-1 4143

Uplink: T34 = (T12 + T34 - ∑TBdelayDL(i) + ∑TBdelayUL(i) )/2, i=1, .., x-1 4144

= (T14 - Toffset - ∑TBdelayDL(i) + ∑TBdelayUL(i) )/2, i=1, .., x-1 4145

Where 4146

<T14> = < T14 (1)> + Tc ×∑N (i), i=1... X-1 4147

As data flow is sampled at 3.84 Mbps in the modem, so modem is easy to adjust the delay which is 4148 integer of Tc, and because RRH samples the radio signal at a higher speed, it is easy to delay the 4149 signal of fractional of Tc, so we propose is that the integer part of delay can be forwarded to CEM to 4150 adjust, and the decimal fraction part can be forwarded to RRH to adjust. 4151

4152

Figure 20 UL Realignment Scenario 4153 4154

For both star mode and daisy chaining mode, the Uplink delay offset is determined by CCM UL dynamic 4155 delay ( mod (T14(1) ,800 ) ,because of CPRI RTT ) and UL Optical link delay (T34), therefore the Uplink 4156 delay realignment formula is applicable for star and daisy chaining configuration. 4157

Our Uplink realignment proposal is that the integer part of Tc is compensated in modem side, the 4158 fractional part is compensated in Radio module side. 4159

LocalCellConfigRsp

GetDelayR

GetDelaytReq

SetDelatReq SetDelayRsp

LocalCellDela

LocalCellDela

OAM CPRI RE

OAM perform realignment if needed

CPRI RE provides : -T2A,TA3, Toffset, NFramediff, TB DL,TB UL

RRH delays are computed such delays send to CEM are

i-CEM x-CEM

LocalCellConfigReq

As delays are multiple of Tc, the CEM perform the realignment




1) UL delay offset value 4160

UL_Delay_Realignment_Main = 0 4161

UL_Delay_Realignment_Div = 0 4162

� Realignment (due to Fibber) 4163

If (T34 (Main path) >= T34 (Div path)) 4164

UL_Delay_Realignment_Main += T34 (Main path) - T34 (Div path) 4165

Else 4166

UL_Delay_Realignment_Div += T34 (Div path) – T34 (Main path) 4167

� CCM UL delay offset 4168

If (CCM_UL_BBLINK_OFFSET (Main) >= CCM_UL_BBLINK_OFFSET (Div)) 4169

UL_Delay_Realignment_Div += CCM_UL_BBLINK_OFFSET (Main) - 4170 CCM_UL_BBLINK_OFFSET (Div) 4171

Else 4172

UL_Delay_Realignment_Main += CCM_UL_BBLINK_OFFSET (Div) - 4173 CCM_UL_BBLINK_OFFSET (Main) 4174

2) Integer delay compensation in modem 4175

To achieve to a perfect correction of Main & Div path in the modem, we shall provide to the CEM delays 4176 which are multiple of Tc, as the delays are provided in Tc/32, the delays provided to the CEM shall be a 4177 multiple of 32. 4178

Integer UL Delay Main Path = 32*ceil ((Global UL Delay Main Path (1) + 4179 UL_Delay_Realignment_Main) /32) //next integer part 4180

Integer UL Delay Div Path = 32*ceil ((Global UL Delay Div Path + UL_Delay_Realignment_Div /32) 4181 // next integer part 4182

Note (1): Global UL Delay Main Path & Global UL Delay Div Path is the sum of all the different delays 4183 collected by OAM CCM: 4184

UL = UL (CCM) + UL (TRM) + UL (DDM) + UL (TMA) + UL (TxSplitter) + UL (Cable) 4185

As the delay between CEM and antenna is equal to the static delay, the difference for Main & Div path 4186 will be compensated by the modem. Once Fractional delay part is added to the RRH we get a global 4187 delay which is equal to the integer part: 4188

CEM UL Main delay = Static UL delay – Integer UL Delay Main Path 4189

CEM UL Div delay = Static UL delay – Integer UL Delay Div Path 4190

3) RRH UL delay adjustment 4191

RRH UL delay value should be modified because of UL delay offset and the decimal part compensation 4192 in order to provide CEM multiply of Tc delay. 4193

RRH_OAM_UL_Delay = Ta3 4194

RRH_OAM_UL_Delay_Main += (Integer UL Delay Main Path - Global UL Delay Main Path) // RRH 4195 delays to CEM 4196

RRH_OAM_UL_Delay_Div += (Integer UL Delay Div Path - Global UL Delay Div Path) // RRH 4197 delays to CEM 4198

RRH adjustment UL Delay Main Path = (Integer UL Delay Main Path X - (Global UL Delay Main Path 4199 +UL Delay_Realignment_Main )) 4200




RRH adjustment UL Delay Div Path = (Integer UL Delay Div Path - (Global UL Delay Div Path + UL 4201 Delay_Realignment_Div)); 4202

The UL delay should be adjusted in RRH will be sent via CPRI C&M command RE_SetDelay_Request 4203

-> RE_SetDelay_Request (RRH adjustment UL Delay Main Path); 4204

-> RE_SetDelay_Request (RRH adjustment UL Delay Div Path); 4205

� UL Delay Alignment scenario 4206

Current CCM OAM thought for all cells in one Tx Path/ Rx Path have the same DL/ UL delay, identically 4207 for different carriers, and although each cell’s UL delay (Ta3) is carrier dependant for ex-Lucent RRH, 4208 this value is similar with the delay (mid band delay) retrieved before carrier configuration (the offset is 4209 less than 100ns), therefore CCM OAM use the mid band delay value to replace each carrier’s delay. 4210




4211

Figure 4212 below describes the process to calculate the UL delay offset for a paired RRH, trigger 4213 Set Delay Sequence for RRH to adjust the fractional part of UL delay offset, and trigger 4214 Local cell delay sequence for all corresponding cells. 4215




1) At the beginning of Rx Path configure sequence, if the radio module is CPRI RE, 4216 send the RE_Get Delay Request to CPRI RE to retrieve detail delay values 4217 (Toffset, TBdelayDL, TBdelayUL, N_Framediff) and store them in the 4218 corresponding RRH instance, get the T14(1) value via call function 4219 CPRI_R21_Coarse_Timer provided by CPRI Driver 4220

2) At the end of Rx Path configure sequence, check if BTS is in MiMo configuration, 4221 and check if there is paired RRH existing and this paired RRH has finished its Rx 4222 Path configuration which means 2 Rx Path exist for each cell and know their detail 4223 delay info to determine the integer part delay adjustment for modems and fractional 4224 part delay adjustment for CPRI RE, if these conditions are satisfied, start to 4225 calculate the fractional part of UL delay to RRH , and trigger Set Delay Sequence if 4226 the delay needed to adjust is not zero. 4227

3) According to the formula: RRH adjustment UL Delay Path = (Integer UL Delay Path 4228 - (Global UL Delay Path +UL Delay_Realignment) calculate the fractional part 4229 delay for paired RRHs. If the delay is not zero, trigger the Set Delay sequence to 4230 notify RRH to align the delay. 4231

4) For each cell, if the cell’s delay state is in CELL_CEM_DELAY_OK, which means 4232 this cell’s delay info has previously sent to modem and will be updated after Set 4233 Delay Sequence, trigger a local cell delay sequence to update its integer part of UL 4234 delay to modem. If cell’s delay state is in NO_CEM_DELAY_SENT, no need to 4235 trigger local cell delay sequence, because after the physical cell’s operational state 4236 is ok, CCM OAM will trigger this sequence. 4237

A new sequence CPRISetDelay Sequence is introduced to control CPRI RE’s delay 4238 adjustment procedure. 4239

1) Add a parameter type for SetDelaySequence 4240

USequenceParameters 4241

{ 4242

SParamForSetDelaySeq setDelayParam; 4243

} 4244

typedef struct 4245

{ 4246

CAbstractRrh * pRrh; 4247

u32 DLdelay; //reserved for MIMO 4248

U32 ULdelay // unit: Tc/32 4249

} SParamForSetDelaySeq 4250

2) During the CPRISetDelay Sequence, CCM OAM will build the RE_SetDelay 4251 Request message to CPRI RE according to the delay value and Rrh instance, and 4252 until receives RE_SetDelay Response close the sequence, If the set delay failure, 4253 raise a alarm “ HW not consistent 4254




4255

Figure 21 Rx Path Sequence modification triggered b y UL delay alignment 4256

According to the formula Integer UL Delay Path = 32*ceil ((Global UL Delay Path + 4257 UL_Delay_Realignment) /32) supply the function to calculate the integer part UL delay 4258 sent to modem. 4259




4260

// integer part UL delay

u32 CPhysicalCell ::getULDelay( Erfchain rfchain )

{

if(m_nbRxPath != 0 && m_nbRxPath != 2)

{

keep the previous rule;

}

else if(m_nbRxPath ==2 )

{

for( i= 0; i< m_nbRxPath ; i++)

{

if (m_RxPath[i]->getRfChain( )== rfchain )

{

ULdelay = 32 *ceil (( m_RxPath[i] ->getULDelay + getULOffset( rfchain ))/32);

return ULdelay;

}

}

if( i ==m_nbRxPath)

CORE_ERROR (" Not found corresponding Rx Path ");

}

}




4261

u32 CPhysicalCell ::getULOffset( ERfChain rfchain )

(

u32 ULOffset =0;

if( m_nbRxPath ==2 )

{

for( i =0; i< m_nbRxPath; i++)

(

if( m_RxPath[i]->getRfChain( ) == rfchain && rfchain == MAIN )

{

CRxPath * m_RxPathMain = m_RxPath[i];

else

CRxPath * m_RxPathDiv = m_RxPath[i];

}

T14Main = m_RxPathMain ->getT14 ( );

T14Div = m_RxPathDiv ->getT14 ( );

T34Main = m_RxPathMain ->getT34 ( );

T34Div = m_RxPathDiv ->getT34 ( );

if T14Main < = T14Div //get T14 offset

{

if( rfchain == MAIN )

ULOffset = T14Div - T14Main;

}

else

{

if( rfchain == DIV )

ULOffset = T14Main- T14Div;

}

if( T34Main >= T34Div ) //get T34 offset

{

if( rfchain == MAIN)

ULOffset + = T34Main - T34Div;

}

else

{

if (rfchain == DIV)

ULOffset + = T34Div - T34DMain;

}

return ULOffset;

}…




4262

� Daisy Chaining configuration 4263

In the case of daisy chaining configuration, the UL delay offset is also caused by the 4264 CCM dynamic delay and UL optical link delay. 4265

The Uplink Optical link delay of RRH in rank x 4266

T34 = (T12 + T34 - ∑ TBdelayDL(i) + ∑ TBdelayUL(i) )/2, i=1, .., x-1 4267

= (T14 - Toffset - ∑ TBdelayDL(i) + ∑ TBdelayUL(i) )/2, i=1, .., x-1 4268

Round Trip delay: 4269

T14 = T14(1) + Tc ×∑ N(i), i=1,.., x-1 4270

Therefore T34 = ( T14(1) + Tc ×∑ N(i) - Toffset - ∑ TBdelayDL(i) + ∑ TBdelayUL(i) ), 4271 i=1,.., x-1 4272

The RRHx’s UL optical link delay calculation depends on that REC should have already 4273 obtained the RRHs’ dealy info in previous rank. 4274

One main principle of software upgrade in daisy chaining is that if RRH in higher rank 4275 starts up faster than the previous RRH, CCM OAM will not allow to start the Rf Inventory 4276 Sequence, until after all RRH in the chain are software updated, this principle avoids the 4277 case that REPROXY report the RRH delay info in higher rank while it can not obtain the 4278 previous RRHs’ delay info. Therefore CCM OAM can calculate RRHx ‘s UL optical link 4279 delay via retrieving the TBdelayDL & TBdelayUL value in lower Rank RRHs( i =1,..x-1). 4280 In a simple word, the UL delay alignment proposal is general for star and daisy chaining 4281 configuration. 4282

4283

Input from RRH R&D - Mark Britton's 4284

Rx delay 4285 • Measured at centre frequency. 4286 • Single MTP only considered. 4287 • Variation = 142ns. 4288

4289 RX delay variation is above the expected delay diff erential. The 4290 specification for the factory delay measurement error should not exceed +/- 4291 40ns therefore it was expected that the delay differential should not exceed 80 4292 ns in total. The largest differential delay measured between two individual 4293 RRHs was, as shown above, 142 ns with a single test setup. The SAW filters in 4294 the RX path are a large component to this delay differential (the TX path has no 4295 SAW filter). 4296 4297

12.1.5 xTRM delay realignment 4298

12.1.5.1 Focus delay alignment on TX path 4299

xTRM & xTRM2 will have the same propagation delays. 4300 But in the case we use different MCPA types; we may need to realign the different Tx path. 4301 We will not need to realign Rx path as main & div are cabled to the same xTRM all delays discussed 4302 here if not specified are expressed in Tc/32. With this procedure realignment is perfomed on main path 4303 without knowing delay of div path and vice and versa, this can only be done with xTRM configuration. 4304 4305




12.1.5.2 OAM CCM recovers radio delays 4306

xTRM provide its delay at startup using BoardInitRsp () used during the start up sequence 4307 4308

PA , DDM and TX splitter delays are recovered through TRM during the inventory process 4309 RF_Inventory_Req () 4310 4311 4312

12.1.5.3 OAM CCM TX delay realignment 4313

Delay is provided to the modem through the LocalCellConfig (xCEM) and LocalCellDelay (iCEM). 4314 Delay is provided to xTRM through new message SetAdditionalDelay. 4315 4316

(i/x) CCM

(i/x) CEM

BoardInitReqBoardInitRsp

StatusReqStatusRsp

CellMappingReq

CellMappingRsp

All the cells must be here declared

(i) CEM programs static and dynamic registers with default

values

Static and dynamic registers are reprogrammed with real

values

CellDelayReq

CellDelayRsp

(i/x) CCM

(i/x) CEM

BoardInitReqBoardInitRsp

StatusReqStatusRsp

CellMappingReq

CellMappingRsp

All the cells must be here declared

(i) CEM programs static and dynamic registers with default

values

Static and dynamic registers are reprogrammed with real

values

CellDelayReq

CellDelayRsp 4317

Figure 22: Delay alignment in modem 4318 4319 4320 Delay is provided to the modem through the CellDelayReq (iCEM) or via LocalCellConfig (xCEM)): 4321 4322

0 Type: SPECIFIC_REQ 1 Sub-type: LOCAL_CELL_DELAY 2...7 Generic part 8 Nb of Local Cell Id 9-12 Local Cell Id #1 13-15 DL Delay Main Path #1 16-18 DL Delay Div Path #1 19-21 UL Delay Main and Div Path #1 …

4323 4324 This message has one consequence: 4325 4326 With iBTS, we consider that transmit delay is static & equal to (static delay _DL = 102 Tc) so the modem 4327 will round the external delay in Tc & add the necessary delay (step of Tc) to reach this static delay 4328




4329 Once OAM CCM recovered all downlink delays, 4330 4331 it shall split integer and fractional chip delay (modem are only able to modify chip integer part (they 4332 round the provided delay): 4333 4334 4335 Integer DL Delay Main Path X = 32* ceil(DL Delay Main Path X /32); // take the next integer delay part 4336 Integer DL Delay Div Path X = 32* ceil(DL Delay Div Path X /32); // take the next integer delay part 4337 4338 Fractionnal DL Delay Main Path X = DL Delay Main Path X - Integer DL Delay Main Path X ; 4339 Fractionnal DL Delay Div Path X = DL Delay Div Path X - Integer DL Delay Div Path X ; 4340 4341 4342

12.1.5.3.1 Integer delay compensation 4343

The integer part is compensated in the modem when OAM CCM provides the delay. 4344 4345 DL Delay Main Path & DL Delay Div Path are the sum of all the different delays collected by OAM CCM: 4346 4347 DL = DL (CCM) + DL(CEM) + DL (TRM) + DL (PA) + DL (DDM) + DL (TMA) + DL (TxSplitter) + DL (Cable) 4348 4349 The Radio Module delay is adjusted such a way the delay provided to the modem is a multiple of 4350 WCDMA chip, such a way the compensation is done in modem part. 4351 4352 DL Delay Main Path = Integer DL Delay Main Path X ; 4353 DL Delay Div Path = Integer DL Delay Div Path X ; 4354 4355 As a consequence of reducing the delay provided to the modem the modem will compensate the delay 4356 path to reach a fix delay. 4357 4358 4359

12.1.5.3.2 Fractional delay compensation 4360

4361 To achieve to a perfect correction of Main & Div path in the modem, we shall provide to the CEM delays 4362 which are multiple of Tc, as the delays are provided in Tc/32, the delays provided to the CEM shall be a 4363 multiple of 32. 4364

To achieve that we will compensate at xTRM side such global downlink delay achieve the next “multiple 4365 of 32”. 4366

The compensating part of the delay is compensated by the xTRM using a SetAdditionalDelay_req (shall 4367 be introduced), this new request will act on the BBPD FPGA of the xTRM (present also in xTRM2), the 4368 signal pass through the BBPD FPGA even if we don’t use predistorsion. 4369

With the actual BBPD FPGA implementation it is possible without any new FPGA delivery to modify the 4370 transmit path via register configuration. 4371

SetAdditionalDelay_req will act on register ALG_MNGT_REGISTER bits 5 to 0 are used to set 64fc 4372 extra delay of the Tx path. 4373

-> SetAdditionalDelay_req(Fractionnal DL Delay Main Path X ); 4374

// setAdditionalDelay is sent on xTRM carrying main path 4375

> SetAdditionalDelay_req(Fractionnal DL Delay Div Path X ); 4376

// setAdditionalDelay is sent on xTRM carrying div path 4377




4378

The SetAdditionalDelay_req will provide the delay to be added in Tc/32, the xTRM shall perform a 4379 translation in 64fc clock cycle: 4380

TX_INT_DELAY_ADDITIONAL = delay_expressed_in_32tc * (64*1.2288) / (32*3.84); 4381

TX_INT_DELAY_ADDITIONAL = round( delay_expressed_in_32tc * 16/25 ); 4382

delay_expressed_in_32tc shall remain below 32 as it is fractional part. 4383

4384

TX_INT_DELAY = TX_INT_DELAY_ADDITIONAL + 1; //=> 1 is the xTRM default delay 4385

=> BBPD_FPGA_WRITE( (ALG_MNG_IDX == 10) , … 4386

(ALG_MNG & 0xFFE0) | TX_INT_DELAY ) 4387

4388

12.1.5.3.3 xTRM Delay Alignment example 4389

Tx Main path: 4390 iCCM(902) + xTRM (1955) + MCPA powerwave 2100MHz/45W/3C NTUM90EA delay (2) + DDM(3) + cable (1) 4391 4392 Tx Div path: 4393 iCCM(902) + xTRM (1955) + MCPA ANDREW 2100MHz/45W/4C NTUM30AA delay (10) + DDM(3) + cable (1) 4394

4395 1) OAM CCM collects all different delays (startup & RF inventory ..): 4396 4397 Main = 2863 4398 Div = 2871 4399 4400 Main path adjustment: 4401 Integer DL Delay Main Path X = 32* ceil(2863 /32); 4402 = 2880 // Value provided to modem for main 4403 4404 Fractionnal DL Delay Main Path X = 2880 - 2863 ; 4405 = 17 // additional delay set on xTRM 4406

// to reach global delay provided to modem 4407 4408 Div path adjustment: 4409 Integer DL Delay Main Path X = 32* ceil(2871 /32); 4410 = 2880 // Value provided to modem for div delay 4411 4412 Fractionnal DL Delay Main Path X = 2880 - 2871 ; 4413 = 9 // additional delay set on xTRM 4414

// to reach global delay provided to modem 4415 4416 2 )OAM CCM provide delay to the modem: 4417 4418 OAM CCM provide the localcelldelay(iCEM) or localcellconfig(xCEM) with downlink delay equal to 4419 integer part: 4420 4421 4422

0 Type: SPECIFIC_REQ 1 Sub-type: LOCAL_CELL_DELAY 2...7 Generic part 8 Nb of Local Cell Id 9-12 Local Cell Id #1 13-15 DL Delay Main Path #1 = 2880 16-18 DL Delay Div Path #1 = 2880 19-21 UL Delay Main and Div Path #1

4423




3) OAM CCM provide the residual part to the xTRM: 4424 4425

Fractionnal DL Delay Main Path X 4426 � SetAdditionalDelay_req(17 ); //add 17 Tc/32 to the main path 4427

Fractionnal DL Delay Div Path X 4428 � SetAdditionalDelay_req(9 ); //add 9 Tc/32 to the main path 4429

4430 5) Global delays 4431 4432 The CEM will delay its main path of (102Tc) – round(2880 / 32 ) = 12 Tc 4433 The CEM will delay its Div path of (102Tc) – round(2880 / 32 ) = 12 Tc 4434 4435 The xTRM main will have an additional delay of 17 Tc/32 4436 The xTRM div will have an additional delay of 9 Tc/32 4437 4438 Delay main = CEM(12*32) + iCCM(902) + xTRM (1955) + additional_delay(17) … 4439

MCPA powerwave 2100MHz/45W/3C NTUM90EA delay (2) + … 4440 DDM(3) + cable (1) 4441 = 3264 Tc/32 //which corresponds exactly to static delay = 102 Tc 4442

4443 Delay Div = CEM(12*32) + iCCM(902) + xTRM (1955) + additional_delay(9) +… 4444

MCPA ANDREW 2100MHz/45W/4C NTUM30AA delay (10) + … 4445 DDM(3) + cable (1) 4446 = 3264 Tc/32 //which corresponds exactly to static delay = 102 Tc 4447 4448

4449

12.2 WORK ON TRANSCEIVER ASPECTS 4450

12.2.1 Work on CPRI modules (RRH & TRDU) 4451

No additional work is needed as these modules shall support delay adjustment via the RE_Set_Delay 4452 Request commands. 4453

12.2.2 Work on xTRM 4454

12.2.2.1 xTRM role of delay adjustment 4455

UA7.1 or UA8: xTRM will be commanded to adjust TX paths delays Main and Div. the command Set 4456 delay will be introduced. The delay adjustment is done by the BBPD FPGA (even if Base Band 4457 Predistorsion is not used) .This will allow general mixity across the MCPA populations and types. 4458 4459 TRM delays depends on the number of configured carriers in sector. The delay changes as the TX 4460 channelizers are cascaded in another manner and if some frequencies are switched in the base band 4461 filtrer. 4462 4463 CEM/CCM/TRM use cases must be reworked to define the messages to reconfigure delay values when 4464 they are changing in TRM for the previous reasons. 4465 4466 Specific issue to be looked at in the possibility to support mixity between xTRM and xTRM2. 4467 4468

12.2.2.2 Operation with 3 xTRM (not supported) 4469

For STRS3-M MIMO on iBTS: The iBTS is currently limited to 2xTRM due to the TRM mastership 4470 algorithm to manage the DDM. This limitation should be extended to 3xTRM. Consequently, the TRM 4471




mastership function must be reworked to allow 3xTRMs. 4472 4473 Development of the remote RF cabling is required: 4474 4475 Issue : the different TRM have not all access to all DDMs. So they must collaborate to know the DDM 4476 status : are you receiving what I am sending? 4477 4478 Pb to resolve: Which TRM can see which DDMs? It depend on the xTRM slot, If the xTRM is in specific 4479 slots, it is hw connected on the DDM shelf1 (DDM1, 2, 3) , in other TRM slots it is connected to DDM 4480 shelf2 (DDM 4, 5, 6)?. 4481 4482 Each xTRM needs his knowledge to interpret the result of RF cabling from other xTRMs 4483 4484 xTRM sw will be inspired of the method applied in the 6 sectors functional note (to be detailed) 4485 4486 Step1 : Perform RF cabling for local radios on TRM corresponding to DDM shelf1 (table in six sector 4487 FS) 4488 CCM gives the TRM1 master role to the first TRM which transmits. 4489 4490 Step 2: Election of “TRM master of DDM” (the TRM who sees more DDMs) 4491 4492 Step 3: Execute the remote RF cabling procedure on TRM that are not in the initial DDM shelf tested. 4493 4494 “TRM not master of DDM” asks to the “TRM master of DDM” the status of the DDM that “TRM not 4495 master of DDM” does not see 4496 4497 This remote RF cabling procedure requires communication of DDM client in “TRM not master of DDM” 4498 sw with “TRM master of DDM”. 4499 4500 The principles of communication between 3 TRM is described in the 4501 STSR1+1_functional_specification(FRS_28900). The sw module “DDM client” communicates with sw 4502 module “DDM master” via SMSG. 4503

12.2.3 STRS3-M Mimo on iBTS 4504

This paragraph describes how to make a STRS3-M MIMO configuration. See next figure. MIMO 4505 requires twice more TX channelizers resources for TX Main+ div than for TX Main only: 4506 4507 The conventional STRS3-M configuration 4508 Uses (9 TX channelizers = 3 carriers* 3 sectors * 1 TX path (Main only). 4509 has 2xTRM* (6TX channelizers/xTRM) = 12 TX channelizers 4510 iBTS STRS3-M MIMO requires 4511 18 TX channelizers = 3 carriers * 3 sectors * 2 TX paths (Main and Div) : twice more than the 4512 conventional STRS3-M 4513 4514 In the iBTS STRS3-M MIMO, we can reuse for TX div the channelizers 4, 5, 6 unused in the second 4515 xTRM in the conventional STRS3-M configuration. We need however another xTRM to get 18 TX 4516 channelizers. 4517 4518 The iBTS is currently limited to 2xTRM due to the TRM mastership algorithm to manage the DDM and 4519 their RF cabling findings. This limitation should be extended. Consequently, the TRM mastership 4520 function and RF cabling test must be reworked to allow 3xTRMs. 4521 4522 A restriction is that MCPAs should be MCPA-A 60W (and not MCPA-B 60W).MCPA60W-B BBPD have 4523 a BBPD bandwidth too low for 3 adjacent carriers. 4524 4525




This architecture assumes also that the STRS3-M configuration in WIPS is completely recabled, and 4526 reconfigured from scratch. 4527 4528 On the RX side, each of the three xTRM may be assigned a single frequency in reception. This 4529 eliminates the xTRM constraint of frequency adjacency: f1, f2, f3 may be not adjacent since assigned 4530 on different xTRMs. 4531

4532 As 3 slots are taken for xTRMs, 4 slots remain available for xCEMs in Macro iBTS 4533 4534

4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564

4565 4566 4567

Figure 23: MIMO solution for iBTS Macro STRS3-M (no t supported) 4568

iBTS

HS

SP

C

xCEM

xCCM


DivMain

6 Rx signals

f1,f2,f3 Main MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA



RxMD f3 S1,S2,S3

f1,f2,f3 Div


f1,f2,f3 Main

f1,f2,f3 Div


iBTS

HS

SP

C

xCEM

xCCM


DivMain

6 Rx signals

f1,f2,f3 Main MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA

MCPA

DDM

MCPA



RxMD f3 S1,S2,S3

f1,f2,f3 Div


f1,f2,f3 Main

f1,f2,f3 Div





12.3 2 DDM PER SECTOR: ARCHITECTURE NOT SUPPORTED IN 4569

IBTS 4570

4571

This picture, technically feasible, is not supported. 4572 4573

iBTS

xCEM

xCCM

TRM or (i/x)TRMprocesses TX f1, f2 M

Rx f1,f2 Main1, Div1

HSS

PC

DivMain

6 Rx signals

f1,f2

MIMO architecture necessary to support 4 RX diversity (not supported)

TRM or (i/x)TRMprocesses

TX f1, f2 DivRx f1,2 Main2,

Div2

f3

MCPA

MCPA

DDM

DDM

MCPA

MCPA

DDM

DDM

MCPA

MCPA

DDM

DDM

4 antennasper sector

Not supported

iBTS

xCEM

xCCM



HSS

PC

DivMain

6 Rx signals

f1,f2




Div2

f3

MCPA

MCPA

DDM

DDM

MCPA

MCPA

DDM

DDM

MCPA

MCPA

DDM

DDM

iBTS

xCEM

xCCM



HSS

PC

DivMain

6 Rx signals

f1,f2




Div2

f3

MCPA

MCPA

DDM

DDM

MCPA

MCPA

DDM DDM

DDM DDM

MCPA

MCPA

DDM

DDM

MCPA

MCPA

DDM DDM

DDM DDM

MCPA

MCPA

DDM

DDM

MCPA

MCPA

DDM DDM

DDM DDM

4 antennasper sector

Not supported

4574 Figure 24: MIMO solution for iBTS Macro STSR1+1 TX2 , RX4 (not supported) 4575

4576

4577

4578

83984%2DMIMO for WCDMA FN Preliminary V02%2E01

Documents

Transcript of 83984%2DMIMO for WCDMA FN Preliminary V02%2E01