RAN15.0 Optional Feature Description

RAN15.0 Optional Feature Description

Issue Draft B

Date 2012-09-27

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2012. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without

prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are the property of Huawei Technologies Co., Ltd. All other

trademarks and trade names mentioned in this document are the property of their respective

holders.

Notice

The purchased products, services and features are stipulated by the commercial contract made

between Huawei and the customer. All or partial products, services and features described in this

document may not be within the purchased scope or the usage scope. Unless otherwise agreed by

the contract, all statements, information, and recommendations in this document are provided "AS

IS" without warranties, guarantees or representations of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in

the preparation of this document to ensure accuracy of the contents, but all statements, information,

and recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base

Bantian, Longgang

Shenzhen 518129

People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

http://www.huawei.com/

mailto:[email protected]


Issue Draft B (2010-06-10) Commercial in Confidence Page 3 of 474

Contents

1 Voice & Service............................................................................................................................ 12

1.1 VoIP ................................................................................................................................................................ 12

1.1.1 WRFD-010617 VoIP over HSPA/HSPA+ ............................................................................................. 12

1.1.2 WRFD-01061701 RAB Mapping ......................................................................................................... 13

1.1.3 WRFD-01061703 Optimized Scheduling for VoIP over HSPA ............................................................ 15

1.1.4 WRFD-010618 IMS Signaling over HSPA ........................................................................................... 17

1.1.5 WRFD-011501 PDCP Header Compression (RoHC) ........................................................................... 18

1.1.6 WRFD-010619 CS Voice over HSPA/HSPA+ ...................................................................................... 19

1.2 Crystal Voice .................................................................................................................................................. 21

1.2.1 WRFD-010613 AMR-WB (Adaptive Multi Rate Wide Band) ............................................................. 21

1.2.2 WRFD-020701 AMR/WB-AMR Speech Rates Control ....................................................................... 23

1.2.3 WRFD-011600 TFO/TrFO .................................................................................................................... 24

1.2.4 WRFD-140201 AMR Voice Quality Improvement Based on PLVA ..................................................... 26

1.3 CBS ................................................................................................................................................................ 28

1.3.1 WRFD-011000 Cell Broadcast Service................................................................................................. 28

1.3.2 WRFD-011001 Simplified Cell Broadcast ............................................................................................ 29

1.3.3 WRFD-020127 Warning of Disaster ..................................................................................................... 30

1.4 MBMS ............................................................................................................................................................ 32

1.4.1 WRFD-010616 MBMS Introduction Package ...................................................................................... 32

1.4.2 WRFD-01061601 MBMS Broadcast Mode .......................................................................................... 34

1.4.3 WRFD-01061602 MBMS Admission Control ...................................................................................... 35

1.4.4 WRFD-01061603 MBMS Load Control ............................................................................................... 36

1.4.5 WRFD-01061604 MBMS Soft/Selective Combining ........................................................................... 38

1.4.6 WRFD-01061605 MBMS Transport Resource Management ............................................................... 39

1.4.7 WRFD-01061606 Streaming Service on MBMS .................................................................................. 40

1.4.8 WRFD-01061607 MBMS 2 Channels per Cell .................................................................................... 41

1.4.9 WRFD-01061608 16/32/64/128Kbit/s Channel Rate on MBMS.......................................................... 42

1.4.10 WRFD-010660 MBMS Phase 2 .......................................................................................................... 43

1.4.11 WRFD-01066001 MBMS Enhanced Broadcast Mode ....................................................................... 44

1.4.12 WRFD-01066002 MBMS P2P over HSDPA ...................................................................................... 45

1.4.13 WRFD-01066003 MBMS Admission Enhancement .......................................................................... 46

1.4.14 WRFD-01066004 Inter-Frequency Neighboring Cell Selection for MBMS PTP Users ..................... 48



1.4.15 WRFD-010627 FACH Transmission Sharing for MBMS .................................................................. 49

1.4.16 WRFD-010626 MBMS FLC(Frequency Layer Convergence)/FLD(Frequency Layer Dispersion) ... 51

1.4.17 WRFD-010624 MBMS 8 Channels per Cell ...................................................................................... 52

1.4.18 WRFD-010625 256Kbit/s Channel Rate on MBMS ........................................................................... 53

1.4.19 WRFD-010628 MBMS 16 Channels per Cell .................................................................................... 54

1.4.20 WRFD-010661 MBMS over Iur ......................................................................................................... 55

1.4.21 WRFD-010662 Dynamic Power Estimation for MTCH ..................................................................... 56

1.4.22 WRFD-010663 MSCH Scheduling ..................................................................................................... 57

1.4.23 WRFD-010665 MBMS Channel Audience Rating Statistics .............................................................. 59

1.5 LCS ................................................................................................................................................................ 60

1.5.1 WRFD-020801 Cell ID + RTT Function Based LCS ........................................................................... 60

1.5.2 WRFD-020802 OTDOA Based LCS .................................................................................................... 62

1.5.3 WRFD-020803 A-GPS Based LCS ....................................................................................................... 63

1.5.4 WRFD-020804 LCS Classified Zones .................................................................................................. 64

1.5.5 WRFD-020805 LCS over Iur ................................................................................................................ 65

1.5.6 WRFD-020807 Iupc Interface for LCS service .................................................................................... 69

1.6 PTT................................................................................................................................................................. 71

1.6.1 WRFD-020134 Push to Talk ................................................................................................................. 71

2 MBB ............................................................................................................................................... 74

2.1 HSUPA Prime Service .................................................................................................................................... 74

2.1.1 WRFD-010612 HSUPA Introduction Package...................................................................................... 74

2.1.2 WRFD-01061201 HSUPA UE Category Support ................................................................................. 75

2.1.3 WRFD-01061209 HSUPA HARQ and Fast UL Scheduling in NodeB ................................................ 77

2.1.4 WRFD-01061202 HSUPA Admission Control ..................................................................................... 79

2.1.5 WRFD-01061203 HSUPA Power Control ............................................................................................ 80

2.1.6 WRFD-01061204 HSUPA Mobility Management ................................................................................ 82

2.1.7 WRFD-01061208 HSUPA DCCC ......................................................................................................... 84

2.1.8 WRFD-01061207 HSUPA Transport Resource Management ............................................................... 86

2.1.9 WRFD-01061206 Interactive and Background Traffic Class on HSUPA ............................................. 88

2.1.10 WRFD-01061210 HSUPA 1.44Mbit/s per User.................................................................................. 89

2.1.11 WRFD-01061211 20 HSUPA Users per Cell ...................................................................................... 90

2.1.12 WRFD-01061212 HSUPA Iub Flow Control in Case of Iub Congestion ........................................... 91

2.1.13 WRFD-010614 HSUPA Phase 2 ......................................................................................................... 93

2.1.14 WRFD-01061401 HSUPA E-AGCH Power Control (Based on CQI or HS-SCCH) .......................... 94

2.1.15 WRFD-01061402 Enhanced Fast UL Scheduling............................................................................... 95

2.1.16 WRFD-01061403 HSUPA 2ms TTI .................................................................................................... 97

2.1.17 WRFD-01061404 HSUPA 2ms/10ms TTI Handover ......................................................................... 98

2.1.18 WRFD-01061405 HSUPA 5.74Mbit/s per User................................................................................ 100

2.1.19 WRFD-010632 Streaming Traffic Class on HSUPA ......................................................................... 101

2.1.20 WRFD-010635 HSUPA over Iur ....................................................................................................... 102



2.1.21 WRFD-010640 Uplink Macro Diversity Intelligent Receiving ........................................................ 103

2.2 HSUPA Performance Improvement.............................................................................................................. 105

2.2.1 WRFD-010690 TTI Switch for BE Services Based on Coverage ....................................................... 105

2.2.2 WRFD-010641 HSUPA Adaptive Transmission ................................................................................. 106

2.2.3 WRFD-010638 Dynamic CE Resource Management ......................................................................... 108

2.2.4 WRFD-010692 HSUPA FDE .............................................................................................................. 109

2.2.5 WRFD-010712 Adaptive Configuration of Traffic Channel Power offset for HSUPA ....................... 111

2.2.6 WRFD-020136 Anti-Interference Scheduling for HSUPA ................................................................. 112

2.2.7 WRFD-020137 Dual-Threshold Scheduling with HSUPA Interference Cancellation ........................ 113

2.2.8 WRFD-010634 60 HSUPA Users per Cell .......................................................................................... 115

2.2.9 WRFD-010210 Control Channel Parallel Interference Cancellation (CCPIC) ................................... 116

2.2.10 WRFD-140202 Control Channel Parallel Interference Cancellation (Phase 2) ................................ 117

2.2.11 WRFD-010691 HSUPA UL Interference Cancellation ..................................................................... 118

2.2.12 WRFD-010636 SRB over HSUPA .................................................................................................... 120

2.2.13 WRFD-140222 Adaptive Adjustment of HSUPA Small Target Retransmissions ............................. 121

2.2.14 WRFD-150206 Turbo IC .................................................................................................................. 123

2.2.15 WRFD-150222 HSUPA Time Division Scheduling .......................................................................... 124

2.3 HSDPA Prime Service .................................................................................................................................. 126

2.3.1 WRFD-010610 HSDPA Introduction Package.................................................................................... 126

2.3.2 WRFD-01061017 QPSK Modulation ................................................................................................. 128

2.3.3 WRFD-01061001 15 Codes per Cell .................................................................................................. 129

2.3.4 WRFD-01061018 Time and HS-PDSCH Codes Multiplex ................................................................ 130

2.3.5 WRFD-01061009 HSDPA H-ARQ & Scheduling (MAX C/I, RR and PF) ....................................... 131

2.3.6 WRFD-01061005 HSDPA Static Code Allocation and RNC-Controlled Dynamic Code Allocation . 133

2.3.7 WRFD-01061004 HSDPA Power Control .......................................................................................... 135

2.3.8 WRFD-01061003 HSDPA Admission Control ................................................................................... 136

2.3.9 WRFD-01061020 Improvement of User Experience in Low Traffic Service ..................................... 138

2.3.10 WRFD-01061019 HSDPA Dynamic Power Allocation .................................................................... 139

2.3.11 WRFD-01061010 HSDPA Flow Control .......................................................................................... 141

2.3.12 WRFD-01061006 HSDPA Mobility Management ............................................................................ 142

2.3.13 WRFD-01061014 HSDPA Transport Resource Management ........................................................... 144

2.3.14 WRFD-01061008 Interactive and Background Traffic Class on HSDPA ......................................... 145

2.3.15 WRFD-01061002 HSDPA UE Category 1 to 28............................................................................... 146

2.3.16 WRFD-01061015 HSDPA 1.8Mbit/s per User.................................................................................. 149

2.3.17 WRFD-01061016 16 HSDPA Users per Cell .................................................................................... 150

2.3.18 WRFD-010620 HSDPA 3.6Mbit/s per User ..................................................................................... 151

2.3.19 WRFD-010629 DL 16QAM Modulation .......................................................................................... 152

2.4 HSDPA Performance Improvement.............................................................................................................. 153

2.4.1 WRFD-010631 Dynamic Code Allocation Based on NodeB ............................................................. 153

2.4.2 WRFD-010621 HSDPA 7.2Mbit/s per User ....................................................................................... 154

2.4.3 WRFD-010622 32 HSDPA Users per Cell .......................................................................................... 155



2.4.4 WRFD-010611 HSDPA Enhanced Package ........................................................................................ 156

2.4.5 WRFD-01061103 Scheduling based on EPF and GBR ...................................................................... 157

2.4.6 WRFD-01061111 HSDPA State Transition ......................................................................................... 159

2.4.7 WRFD-01061112 HSDPA DRD ......................................................................................................... 161

2.4.8 WRFD-01061113 HS-DPCCH Preamble Support .............................................................................. 162

2.4.9 WRFD-010630 Streaming Traffic Class on HSDPA ........................................................................... 164

2.4.10 WRFD-010650 HSDPA 13.976Mbps per User ................................................................................. 165

2.4.11 WRFD-010651 HSDPA over Iur ....................................................................................................... 166

2.4.12 WRFD-010652 SRB over HSDPA .................................................................................................... 168

2.4.13 WRFD-010623 64 HSDPA Users per Cell ........................................................................................ 169

2.4.14 WRFD-030010 CQI Adjustment Based on Dynamic BLER Target ................................................. 170

2.4.15 WRFD-030011 MIMO Prime ........................................................................................................... 171

2.4.16 WRFD-030004 Adaptive Configuration of Typical HSPA Rate ....................................................... 173

2.4.17 WRFD-140221 HSDPA Scheduling Based on UE Location ............................................................ 174

2.5 HSPA+ Prime Service .................................................................................................................................. 176

2.5.1 WRFD-010680 HSPA+ Downlink 28Mbit/s per User ........................................................................ 176


2.5.3 WRFD-010685 Downlink Enhanced L2 ............................................................................................. 179


2.5.5 WRFD-010683 Downlink 64QAM ..................................................................................................... 181

2.5.6 WRFD-010684 2×2 MIMO ................................................................................................................ 183

2.5.7 WRFD-010693 DL 64QAM+MIMO .................................................................................................. 185

2.5.8 WRFD-010698 HSPA+ Uplink 11.5Mbit/s per User .......................................................................... 186

2.5.9 WRFD-010703 HSPA+ Downlink 84 Mbit/s per User ....................................................................... 187

2.5.10 WRFD-010699 DC-HSDPA+MIMO ................................................................................................ 189

2.5.11 WRFD-010694 UL 16QAM .............................................................................................................. 191

2.5.12 WRFD-010695 UL Layer 2 Improvement ........................................................................................ 192

2.5.13 WRFD-010696 DC-HSDPA ............................................................................................................. 194

2.5.14 WRFD-140203 HSPA+ Uplink 23 Mbit/s per User .......................................................................... 196

2.5.15 WRFD-140204 DC-HSUPA ............................................................................................................. 197

2.5.16 WRFD-150207 4C-HSDPA .............................................................................................................. 199

2.5.17 WRFD-150209 DB-HSDPA ............................................................................................................. 201

2.6 HSPA+ Performance Improvement .............................................................................................................. 203

2.6.1 WRFD-010688 Downlink Enhanced CELL-FACH ............................................................................ 203

2.6.2 WRFD-010700 Performance Improvement of MIMO and HSDPA Co-carrier .................................. 205

2.6.3 WRFD-010686 CPC - DTX / DRX .................................................................................................... 207

2.6.4 WRFD-010687 CPC - HS-SCCH less operation ................................................................................ 208

2.6.5 WRFD-010697 E-DPCCH Boosting .................................................................................................. 210

2.6.6 WRFD-010701 Uplink Enhanced CELL_FACH ................................................................................ 211

2.6.7 WRFD-010653 96 HSDPA Users per Cell .......................................................................................... 213

2.6.8 WRFD-010639 96 HSUPA Users per Cell .......................................................................................... 214



2.6.9 WRFD-010654 128 HSDPA Users per Cell ........................................................................................ 215

2.6.10 WRFD-010670 128 HSUPA Users per Cell ...................................................................................... 216

2.6.11 WRFD-010704 Flexible HSPA+ Technology Selection.................................................................... 218

2.6.12 WRFD-010713 Traffic-Based Activation and Deactivation of the Supplementary Carrier In

Multi-carrier ................................................................................................................................................. 219

2.6.13 WRFD-010702 Enhanced DRX ........................................................................................................ 220

2.6.14 WRFD-150208 Flexible DC/DB-HSDPA ......................................................................................... 221

3 Smart MBB ................................................................................................................................. 224

3.1 Smart Phone Solution ................................................................................................................................... 224

3.1.1 WRFD-020500 Enhanced Fast Dormancy .......................................................................................... 224

3.1.2 WRFD-140205 Voice Experience Improvement for Weak Reception UEs ........................................ 226

3.1.3 WRFD-140206 Layered Paging in URA_PCH ................................................................................... 227

3.1.4 WRFD-150205 Layered Paging in Idle Mode .................................................................................... 229

3.2 Smart Pipe .................................................................................................................................................... 230

3.2.1 WRFD-020132 Web Browsing Acceleration ...................................................................................... 230

3.2.2 WRFD-020133 P2P Downloading Rate Control during Busy Hour ................................................... 231

4 Green ........................................................................................................................................... 234

4.1 Power Consumption Saving ......................................................................................................................... 234

4.1.1 WRFD-020116 Dynamic Power Sharing in Multi-Carriers ................................................................ 234

4.1.2 WRFD-020117 Multi-Carrier Switch off Based on Traffic Load ....................................................... 235

4.1.3 WRFD-020118 Energy Efficiency Improved ...................................................................................... 236

4.1.4 WRFD-020119 Multi-Carrier Switch off Based on Power Backup .................................................... 238

4.1.5 WRFD-020122 Multi-Carrier Switch off Based on QoS .................................................................... 240

4.1.6 WRFD-020121 Intelligent Power Management .................................................................................. 242

5 Topology & Transmission ....................................................................................................... 244

5.1 RAN Sharing ................................................................................................................................................ 244

5.1.1 WRFD-021304 RAN Sharing Introduction Package .......................................................................... 244

5.1.2 WRFD-02130401 Dedicated Carrier for Each Operator ..................................................................... 246

5.1.3 WRFD-02130402 Flexible Network Architecture .............................................................................. 247

5.1.4 WRFD-02130403 Mobility Control and Service Differentiation ........................................................ 250

5.1.5 WRFD-02130404 Independent License Control ................................................................................. 252

5.1.6 WRFD-02130405 Independent Cell-level FM/PM/CM ...................................................................... 253

5.1.7 WRFD-02130406 Transmission Recourse Sharing on Iub/Iur Interface ............................................ 255

5.1.8 WRFD-021305 RAN Sharing Phase 2 ................................................................................................ 256

5.1.9 WRFD-02130501 Dedicated Iub Transmission Control ..................................................................... 257

5.1.10 WRFD-021303 IMSI Based Handover ............................................................................................. 261

5.1.11 WRFD-021311 MOCN Introduction Package .................................................................................. 262

5.1.12 WRFD-02131101 Carrier Sharing by Operators ............................................................................... 264

5.1.13 WRFD-02131102 Dedicated NodeB/Cell for Operators ................................................................... 266

5.1.14 WRFD-02131103 MOCN Mobility Management ............................................................................ 268



5.1.15 WRFD-02131104 MOCN Load Balance .......................................................................................... 269

5.1.16 WRFD-02131105 MOCN Independent Performance Management ................................................. 270

5.1.17 WRFD-02131106 Routing Roaming UEs in Proportion ................................................................... 271

5.1.18 WRFD-140223 MOCN Cell Resource Demarcation ........................................................................ 272

5.1.19 WRFD-150213 MOCN Independent Iub Transmission Resource Allocation................................... 274

5.1.20 WRFD-150214 MOCN Independent CE Resource Allocation ......................................................... 276

5.2 Topology Enhancement ................................................................................................................................ 278

5.2.1 WRFD-021200 HCS (Hierarchical Cell Structure) ............................................................................. 278

5.2.2 WRFD-020111 One Tunnel ................................................................................................................ 280

5.3 ATM Transmission ....................................................................................................................................... 282

5.3.1 WRFD-050405 Overbooking on ATM Transmission.......................................................................... 282

5.3.2 WRFD-050105 ATM Switching Based Hub NodeB ........................................................................... 285

5.3.3 WRFD-050106 AAL2 Switching Based Hub NodeB ......................................................................... 287

5.3.4 WRFD-050406 ATM QoS Introduction on Hub NodeB (Overbooking on Hub NodeB Transmission)

..................................................................................................................................................................... 288

5.3.5 WRFD-050302 Fractional ATM Function on Iub Interface ................................................................ 290

5.4 IP Transmission ............................................................................................................................................ 291

5.4.1 WRFD-050402 IP Transmission Introduction on Iub Interface .......................................................... 291

5.4.2 WRFD-050411 Fractional IP Function on Iub Interface ..................................................................... 296

5.4.3 WRFD-050403 Hybrid Iub IP Transmission ....................................................................................... 297

5.4.4 WRFD-050404 ATM/IP Dual Stack NodeB ....................................................................................... 299

5.4.5 WRFD-050409 IP Transmission Introduction on Iu Interface ............................................................ 301

5.4.6 WRFD-050410 IP Transmission Introduction on Iur Interface ........................................................... 303

5.4.7 WRFD-050420 FP MUX for IP Transmission .................................................................................... 306

5.4.8 WRFD-050422 Dynamic Bandwidth Control of Iub IP ...................................................................... 307

5.4.9 WRFD-050408 Overbooking on IP Transmission .............................................................................. 309

5.4.10 WRFD-050107 IP routing Based Hub NodeB .................................................................................. 311

5.4.11 WRFD-011500 PDCP Header Compression (RFC2507) .................................................................. 313

5.4.12 WRFD-050412 UDP MUX for Iu-CS Transmission ........................................................................ 314

5.4.13 WRFD-140207 Iu/Iur Transmission Resource Pool in RNC ............................................................ 315

5.4.14 WRFD-140208 Iub Transmission Resource Pool in RNC ................................................................ 317

5.5 Satellite Transmission .................................................................................................................................. 320

5.5.1 WRFD-050104 Satellite Transmission on Iub Interface ..................................................................... 320

5.5.2 WRFD-050108 Satellite Transmission on Iu Interface ....................................................................... 321

5.6 Clock ............................................................................................................................................................ 322

5.6.1 WRFD-050501 Clock Sync on Ethernet in NodeB ............................................................................. 322

5.6.2 WRFD-050502 Synchronous Ethernet ................................................................................................ 324

5.6.3 WRFD-050425 Ethernet OAM ........................................................................................................... 325

6 Network Security ...................................................................................................................... 328

6.1 Reliability ..................................................................................................................................................... 328

6.1.1 WRFD-040202 RNC Node Redundancy ............................................................................................ 328



6.1.2 WRFD-040203 RRU Redundancy ...................................................................................................... 329

6.1.3 WRFD-021302 Iu Flex ....................................................................................................................... 331

6.1.4 WRFD-021306 Iu Flex Load Distribution Management .................................................................... 334

6.1.5 WRFD-140209 NodeB Integrated IPSec ............................................................................................ 336

6.1.6 WRFD-140210 NodeB PKI Support ................................................................................................... 338

6.1.7 WRFD-141201 RNC User Plane and Control Plane Dynamic Sharing .............................................. 339

6.1.8 WRFD-150211 RNC in Pool Load Sharing ........................................................................................ 341

6.1.9 WRFD-150212 RNC in Pool Node Redundancy ................................................................................ 342

7 Network Performance .............................................................................................................. 345

7.1 Coverage Enhancement ................................................................................................................................ 345

7.1.1 WRFD-010203 Transmit Diversity ..................................................................................................... 345

7.1.2 WRFD-010209 4-Antenna Receive Diversity .................................................................................... 347

7.1.3 WRFD-021308 Extended Cell Coverage up to 200km ....................................................................... 348

7.1.4 WRFD-021309 Improved Downlink Coverage .................................................................................. 349

7.1.5 WRFD-020138 HSUPA Coverage Enhancement at UE Power Limitation......................................... 350

7.2 Spectrum Efficiency Improvement............................................................................................................... 351

7.2.1 WRFD-021001 Flexible frequency bandwidth of UMTS carrier ....................................................... 351

7.3 High Speed Mobility .................................................................................................................................... 353

7.3.1 WRFD-010206 High Speed Access .................................................................................................... 353

7.3.2 WRFD-021350 Independent Demodulation of Signals from Multiple RRUs in One Cell ................. 354

7.4 Intra-system Mobility Management ............................................................................................................. 356

7.4.1 WRFD-020302 Inter Frequency Hard Handover Based on Coverage ................................................ 356

7.4.2 WRFD-020304 Inter Frequency Hard Handover Based on DL QoS .................................................. 358

7.4.3 WRFD-020605 SRNS Relocation Introduction Package .................................................................... 359

7.4.4 WRFD-02060501 SRNS Relocation (UE Not Involved) .................................................................... 361

7.4.5 WRFD-02060502 SRNS Relocation with Hard Handover ................................................................. 362

7.4.6 WRFD-02060503 SRNS Relocation with Cell/URA Update ............................................................. 363

7.4.7 WRFD-02060504 Lossless SRNS Relocation .................................................................................... 364

7.5 Intra-system Radio Resource Management .................................................................................................. 365

7.5.1 WRFD-010615 Multiple RAB Package (PS RAB ≥ 2) ................................................................... 365

7.5.2 WRFD-01061501 Combination of Two PS Services .......................................................................... 367

7.5.3 WRFD-01061502 Combination of One CS Service and Two PS Services ......................................... 368

7.5.4 WRFD-01061503 Combination of Three PS Services ........................................................................ 369

7.5.5 WRFD-01061504 Combination of One CS Service and Three PS Services ....................................... 370

7.5.6 WRFD-01061505 Combination of Four PS Services ......................................................................... 371

7.5.7 WRFD-020103 Inter Frequency Load Balance ................................................................................... 372

7.5.8 WRFD-020114 Domain Specific Access Control (DSAC) ................................................................. 373

7.5.9 WRFD-020110 Multi Frequency Band Networking Management ..................................................... 375

7.5.10 WRFD-020160 Enhanced Multiband Management .......................................................................... 378

7.5.11 WRFD-020400 DRD Introduction Package ...................................................................................... 380



7.5.12 WRFD-02040001 Intra System Direct Retry .................................................................................... 381

7.5.13 WRFD-02040002 Inter System Direct Retry .................................................................................... 382

7.5.14 WRFD-02040003 Inter System Redirect .......................................................................................... 383

7.5.15 WRFD-02040004 Traffic Steering and Load Sharing During RAB Setup ....................................... 384

7.5.16 WRFD-02040005 Inter-Frequency Redirection Based on Distance ................................................. 385

7.5.17 WRFD-020402 Measurement Based Direct Retry ............................................................................ 386

7.5.18 WRFD-020120 Service Steering and Load Sharing in RRC Connection Setup ............................... 388

7.5.19 WRFD-020124 Uplink Flow Control of User Plane ......................................................................... 389

7.5.20 WRFD-140211 Dynamic Target RoT Adjustment ............................................................................ 390

7.5.21 WRFD-140212 CE Overbooking ...................................................................................................... 392

7.5.22 WRFD-140213 Intelligent Access Class Control .............................................................................. 394

7.5.23 WRFD-140215 Dynamic Configuration of HSDPA CQI Feedback Period ...................................... 396

7.5.24 WRFD-140216 Load-based Uplink Target BLER Configuration ..................................................... 398

7.5.25 WRFD-140217 Inter-Frequency Load Balancing Based on Configurable Load Threshold ............. 399

7.5.26 WRFD-150201 Micro Cell Dynamic Rx Sensitivity Control ........................................................... 401

7.5.27 WRFD-150232 Multiband Direct Retry Based on UE Location ...................................................... 404

7.6 GSM and UMTS Radio Resource Management .......................................................................................... 405

7.6.1 WRFD-070004 Load Based GSM and UMTS Handover Enhancement Based on Iur-g .................... 405

7.6.2 WRFD-070005 NACC Procedure Optimization Based on Iur-g ........................................................ 407

7.6.3 WRFD-070006 GSM and UMTS Load Balancing Based on Iur-g ..................................................... 409

7.6.4 WRFD-070007 GSM and UMTS Traffic Steering Based on Iur-g ..................................................... 411

7.6.5 WRFD-020303 Inter-RAT Handover Based on Coverage .................................................................. 414

7.6.6 WRFD-020309 Inter-RAT Handover Based on DL QoS .................................................................... 416

7.6.7 WRFD-020307 Video Telephony Fallback to Speech (AMR) for Inter-RAT HO .............................. 417

7.6.8 WRFD-020308 Inter-RAT Handover Phase 2 ..................................................................................... 419

7.6.9 WRFD-02030801 NACC(Network Assisted Cell Change) ................................................................ 420

7.6.10 WRFD-02030802 PS Handover Between UMTS and GPRS ........................................................... 422

7.6.11 WRFD-020305 Inter-RAT Handover Based on Service .................................................................... 423

7.6.12 WRFD-020306 Inter-RAT Handover Based on Load ....................................................................... 424

7.6.13 WRFD-020401 Inter-RAT Redirection Based on Distance ............................................................... 425

7.6.14 WRFD-020310 3G/2G Common Load Management ....................................................................... 426

7.7 UMTS and LTE Radio Resource Management ............................................................................................ 428

7.7.1 WRFD-020126 Mobility Between UMTS and LTE Phase1 ............................................................... 428

7.7.2 WRFD-020129 Service-Based PS Service Redirection from UMTS to LTE ..................................... 430

7.7.3 WRFD-140218 Service-Based PS Handover from UMTS to LTE ..................................................... 431

7.7.4 WRFD-140224 Fast CS Fallback Based on RIM ............................................................................... 433

7.7.5 WRFD-150215 SRVCC from LTE to UMTS with PS Handover ....................................................... 434

7.7.6 WRFD-150216 Load Based PS Redirection from UMTS to LTE ...................................................... 436

7.7.7 WRFD-150217 Load Based PS Handover from UMTS to LTE ......................................................... 437

7.7.8 WRFD-150219 Coverage Based PS Redirection from UMTS to LTE ............................................... 438

7.7.9 WRFD-150220 Coverage Based PS Handover from UMTS to LTE .................................................. 440



7.7.10 WRFD-150231 RIM Based UMTS Target Cell Selection for LTE ................................................... 442

7.8 UMTS and Wi-Fi Radio Resource Management .......................................................................................... 443

7.8.1 WRFD-150229 Intelligent Wi-Fi Detection and Selection ................................................................. 443

7.9 QoS............................................................................................................................................................... 444

7.9.1 WRFD-010505 Queuing and Pre-Emption ......................................................................................... 444

7.9.2 WRFD-021103 Access Class Restriction ............................................................................................ 447

7.9.3 WRFD-050424 Traffic Priority Mapping onto Transmission Resources ............................................ 448

7.9.4 WRFD-020806 Differentiated Service Based on SPI Weight ............................................................. 452

7.9.5 WRFD-020131 Optimization of R99 and HSUPA Users Fairness ..................................................... 454

7.9.6 WRFD-011502 Active Queue Management (AQM) ........................................................................... 455

7.9.7 WRFD-020128 Quality Improvement for Subscribed Service ........................................................... 456

7.9.8 WRFD-020123 TCP Accelerator ........................................................................................................ 457

7.9.9 WRFD-010507 Rate Negotiation at Admission Control ..................................................................... 460

7.9.10 WRFD-020130 Videophone Service Restriction .............................................................................. 463

7.9.11 WRFD-020135 Intelligent Inter-Carrier UE Layered Management .................................................. 464

7.9.12 WRFD-150204 Platinum User Prioritizing ....................................................................................... 465

8 O&M Experience ....................................................................................................................... 467

8.1 Advanced Planning ....................................................................................................................................... 467

8.1.1 WRFD-140219 Micro NodeB Self-Planning ...................................................................................... 467

9 Site Solution ............................................................................................................................... 470

9.1 Supporting .................................................................................................................................................... 470

9.1.1 WRFD-140220 Intelligent Battery Management ................................................................................ 470

10 Acronyms and Abbreviations ............................................................................................... 473



1 Voice & Service

1.1 VoIP

1.1.1 WRFD-010617 VoIP over HSPA/HSPA+

Availability

VoIP over HSPA is available from RAN10.0.

VoIP over HSPA+ is available from RAN11.0.

Summary

VoIP over HSPA meets the requirements of growing VoIP users. Compared with CS voice

over DCH, VoIP over HSPA or HSPA+ provides larger capacity through high spectral

efficiency and capacity enhancement of HSPA or HSPA+. This feature is a trial feature in

RAN10.0.

Benefits

VoIP over HSPA/HSPA+ has the following advantages:

Support evolution to all-IP network and decrease in the investment and maintenance cost

Large voice capacity

Description

In the fixed network, VoIP has turned out to be an attractive and cost-effective solution to

support PS conversational services. The rapid growth of VoIP users prompts cellular operators

to use this feature for enhanced revenue generation. Moreover, from the viewpoint of

evolution, VoIP helps operators converge their networks into an all-IP network and decrease

the total OPEX accordingly.

VoIP services can be carried over DCH or HSPA. When it is set up on the DCH, the capacity

is not competitive because RTP/UDP/IP protocol head will consume more resource than CS

voice service. However, HSPA has higher resource efficiency than DCH. Therefore, VoIP over

HSPA is a better choice. Moreover, Robust Header Compression (RoHC) is also introduced to



improve the overhead efficiency. In addition, the Continuous Packet Connectivity (CPC)

technology in the HSPA+ helps expand the VoIP capacity.

Compared with traditional CS voice over DCH, the capacity gain of VoIP over HSPA (HSUPA

with 2ms TTI) is expected to reach 20%. With CPC, the capacity gain of VoIP over HSPA

(HSUPA with 2ms TTI) is expected to reach 45%.

Enhancement

In RAN12.0, coverage-based TTI dynamic switching of VoIP over HSUPA is introduced. The

coverage performance of the HSUPA 10 ms TTI is better than that in R99, whereas the

coverage performance of the HSUPA 2 ms TTI is worse than that in R99. The 2 ms TTI,

however, has a greater gain in capacity. Therefore, for VoIP users, smooth switching from the

2 ms TTI to the 10 ms TTI must be implemented according to the limitation on the uplink

transmit power of the UE. This ensures seamless coverage and maximizes cell capacity.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should support VoIP.

Dependency on Other Network Units

None

Dependency on CN

CN should support IP multimedia subsystem (IMS).

Dependency on Other Features

When VoIP is over HSPA, the following features are required:

WRFD-010610 HSDPA Introduction Package

WRFD-010612 HSUPA Introduction Package

WRFD-010636 SRB over HSUPA

WRFD-010652 SRB over HSDPA

When VoIP is over HSPA+, the following feature is required:

WRFD-010686 CPC-DTX/DRX

1.1.2 WRFD-01061701 RAB Mapping

Availability

This feature is available from RAN10.0.



Summary

This feature enables a combination of multiple RABs to support rich service types.

Benefits

This feature enables VoIP over HSPA and more RAB combinations to be carried over HSPA

to enrich service combinations of the operator.

Description

This feature enables VoIP over HSDPA and VoIP over HSUPA 10/2 ms TTI. The following

RAB combinations are available:

1PS + 1CS

Conversational (VoIP)/UL: EUL[Maximum rate depends on UE category] DL:HSDPA

[Maximum rate depends on UE category] /PS RAB + UL: 3.4 kbit/s DL: 3.4 kbit/s

SRB for DCCH

2PS + 1CS

Conversational (VoIP)/UL: EUL DL: HSDPA/PS RAB + Interactive or

Background/UL: EUL [Maximum rate depends on UE category] DL: HSDPA

[Maximum rate depends on UE category] /PS RAB + UL: 3.4 kbit/s DL: DCCH. SRB

3.4 kbit/s.

3PS + 1CS

Conversational (VoIP) /UL: EUL [Maximum rate depends on UE category] DL:

HSDPA [Maximum rate depends on UE category] /PS RAB + Streaming/UL: EUL

[Maximum rate depends on UE category] DL: HSDPA [Maximum rate depends on UE

category] /PS RAB + Interactive or Background /UL:EUL [Maximum rate depends on

UE category] DL: HSDPA [Maximum rate depends on UE category] / PS RAB + UL:

3.4 kbit/s DL: DCCH. SRB 3.4 kbit/s.

"SRB + 1 VoIP over IMS + 1 PS" over HSPA

The typical configuration of VoIP is different in 3GPP R5 and R6. In TS34.108 and TR25.99,

3GPP defines some VoIP configurations and related combinations as reference. Huawei RAN

supports these services. As the RTP header is transmitted before RoHC is enabled, a higher

rate is required. After RoHC is enabled, a lower rate can be used. RAN10.0 does not support

the adjustment between a high rate and a low rate.

The operator can configure VoIP over DCH or HSPA on the cell side. That is, when HSPA is

preferentially selected as a bearer, VoIP is carried over HSPA as much as possible. If HSPA

operations fail (for example, admission control), the period timer starts to trigger the

configuration adjustment of HSPA operations.

Enhancement

None

Dependency

Dependency on RNC

None



Dependency on NodeB

None

Dependency on UE



None

Dependency on CN



When VoIP is over HSPA, the following features are required:



When VoIP is over HSPA+, the following feature is required:


1.1.3 WRFD-01061703 Optimized Scheduling for VoIP over HSPA

Availability


Summary

Based on the UL non-scheduling method and DL delay-sensitive scheduling algorithm, this

feature can ensure the delay requirements of VoIP services and signaling carried over HSPA.

Benefits

This feature guarantees the delay requirement of VoIP services and enhances user experience

when VoIP over HSPA is applied.

Description

In RAN10.0, VoIP over HSPA is supported. In order to guarantee the QoS of VoIP over HSPA,

non-scheduling method is used during HSUPA scheduling in the uplink. In the downlink,

delay-sensitive (DS) algorithm as an optimized HSDPA scheduling scheme is provided.

VoIP service in 3G consists of two kinds of packets: SIP signaling and RTP packets. RTP and

RTCP can be born on a single RAB.



UTRAN PS

Domain

IMS PS

Domain

UTRAN

)

UE UTRAN PS

Domain

IMS PS

Domain

UTRAN

Session control Signaling (SIP / SDP)

Media ( RTP)

UE UE UE

The preceding packets have different characteristics:

Packet Characteristics

SIP signaling Delay sensitive (call setup delay is affected).

RLC retransmission is triggered due to packet loss. The delay is affected.

VoIP-RTP Delay sensitive.

No RLC retransmission is triggered due to packet loss. The delay and user

experience are affected.

According to different characteristics, the MAC-hs scheduling algorithm should be enhanced

to guarantee the QoS, especially the delay.

DS scheduling algorithm for SRB and VoIP is always prior to scheduling algorithm for

streaming and BE. This feature is for the RAB which bares the RTP voice packet to guarantee

the delay in a certain range.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



None

Dependency on CN





VoIP over HSPA rely on:

WRFD-010611 HSDPA Enhanced Package


VoIP over HSPA+ rely on:



1.1.4 WRFD-010618 IMS Signaling over HSPA

Availability


This feature is introduced in 3GPP R5.

Summary

IMS signaling over HSPA can shorten the setup delay of IMS services like VoIP to save

network resources for the operator.

Benefits Since IMS signaling is carried on HSPA, the utilization of code resource and

transmission resource can be improved, compared with those carried on the DCH.

Better performance (short time delay) and capacity of IMS services.

Description

The IP Multimedia Subsystem (IMS) is an open and standardized architectural framework for

delivering Internet Protocol (IP) multimedia to mobile users. With this feature, operators

provide network-controlled multimedia services by combining voice and data in a single

packet switched network.

IMS uses Session Initiation Protocol (SIP) as the key control protocol, and implements

service management in the UTRAN. Such SIP signaling will be indicated by the CN in the

RAB Assignment Request message. The RAB should be an interactive QoS class service.

Before RAN10.0, such IMS signaling service can only be carried on the DCH. With F-DPCH

supported in RAN10.0, the service can be carried on HSPA, which brings better performance

for IMS service.

The type of channels carrying IMS signaling is configurable separately on the downlink and

uplink at cell level. That is, when HSPA is chosen as the bearer with high priority, IMS

signaling will be set up on it as much as possible. If the setup is not successful, for example,

due to admission control, a periodical timer will be started to trigger the reconfiguration of the

HSPA procedure.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

CN should support the signaling indication at Iu interface.




1.1.5 WRFD-011501 PDCP Header Compression (RoHC)

Availability



Summary

PDCP header compression (RoHC) mainly applies to VoIP services and it can decrease the

overhead of IP data.

Benefits Decrease the IP data overhead greatly from more than 60% to 10%.

Saving air interface and backhaul bandwidth occupancy, saving CAPEX & OPEX

Description

Robust Header Compression (RoHC) is defined in RFC3095 (July, 2001). Such feature

provides the IP data header compression mechanism which aims to save the bandwidth of air

interface, which utilize less radio resources.

The motivation for IP header compression is based on the following facts:

The multimedia payload is typically compressed at the application layer.

The headers occupy a large portion of the packet for some services.



The headers have significant redundancy.

The RoHC is implemented at the PDCP protocol layer between the RNC and UE; therefore,

the Iub bandwidth can be saved.

In RAN10.0, the following compress/uncompress profiles are supported:

RoHC Uncompressed

RoHC RTP: RTP/UDP/IP header

RoHC UDP: UDP/IP header

RoHC ESP: ESP/IP header

Generally, RTP/UDP/IP header is used in packet of VoIP, so RoHC Uncompressed or RoHC

RTP is used for VoIP. RoHC UDP and RoHC ESP are used in other scenarios when the hander

of packet is UDP/IP or ESP/IP.

Both IPV4 and IPV6 header compressions are supported.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should support the ROHC compression function.


None

Dependency on CN

None


WRFD-010619 CS Voice over HSPA/HSPA+

1.1.6 WRFD-010619 CS Voice over HSPA/HSPA+

Availability

This feature is available from RAN11.0. It is introduced in 3GPP R8.



Summary

Compared with CS voice over DCH, CS voice over HSPA/HSPA+ provides a larger voice

capacity through high spectral efficiency and capacity enhancement of HSPA or HSPA+.

Benefits

The use of the high spectral efficiency and capacity enhancement features of HSPA or HSPA+

increases the capacity of CS voice services. Compared with VoIP over HSPA or HSPA+, CS

voice over HSPA/HSPA+ does not require the support of the IMS and its implementation is

easier.

Description

Generally, CS voice services are carried over DCH. CS voice over HSPA is introduced in

3GPP Release 8 specifications. That is, UL CS voice packets are carried over E-DCH, and DL

CS voice packets are carried over HS-DSCH.

CS voice over HSPA refers to the Circuit Switched voice service based on legacy CS domain

Core Network. Therefore, operators do not need to deploy the IMS for VoIP services. The

following figure shows the difference in call routing between CS voice over HSPA and VoIP

over HSPA/HSPA+.

To deploy CS voice over HSPA, the only needed update is the way of mapping for this service

on the RNC. No additional modification is needed on the MSC or NodeB.

CS voice over HSPA improves the spectral efficiency and cell capacity. Moreover, the CPC

feature introduced in RAN11.0 HSPA+ package helps to extend the battery life of UEs

through UL DTX and DL DRX functions.

Compared with traditional CS voice over DCH, the capacity gain of VoIP over HSPA (HSUPA

with 2ms TTI) is expected to reach 23%. With CPC, the capacity gain of VoIP over HSPA

(HSUPA with 2ms TTI) is expected to reach 48%.

Enhancement

In RAN12.0, coverage-based TTI dynamic switching of VoIP over HSUPA is introduced. The

coverage performance of the HSUPA 10 ms TTI is better than that in DCH, whereas the

coverage performance of the HSUPA 2 ms TTI is worse than that in DCH. The 2 ms TTI,

however, has a greater gain in capacity. Therefore, for voice call over HSPA users, 2 ms TTI is

always configured to obtain high system capacity and smooth switching from the 2 ms TTI to



the 10 ms TTI must be implemented according to the limitation on the uplink transmit power

of the UE and the high BLER. This ensures seamless coverage and maximizes cell capacity.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE must be Release-8 (or later) and support CS voice over HSPA/HSPA+


None

Dependency on CN

None


When CS voice is over HSPA





When CS voice is over HSPA+


1.2 Crystal Voice

1.2.1 WRFD-010613 AMR-WB (Adaptive Multi Rate Wide Band)

Availability



Summary

This feature enables the operator to improve the quality of speech services if resources are

allowed.



Benefits

The AMR-WB provides improved voice quality especially in terms of increased voice

naturalness.

Description

AMR-WB (Wide Band) is a new feature in 3GPP_REL 5 for the purpose to provide improved

voice quality especially in terms of increased voice naturalness.

This feature provides the AMR-WB service with the bit rate defined as follows:

Codec Mode Source Codec BitRate

AMR-WB_23.85 23.85 kbit/s









The system will set up the AMR service according to the service request from the core

network. The algorithm for AMR-WB is the same as that for the AMR service with narrow

band.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE must have the corresponding support capability.




None

Dependency on CN

The CN must have the corresponding support capability.


None

1.2.2 WRFD-020701 AMR/WB-AMR Speech Rates Control

Availability



Summary

This feature enables the adjustment of AMR/AMR-WB speech rates triggered by multiple

factors. This feature can ensure a continuous service, expand the service coverage, and reduce

the cell load.

Benefits

For the same transmit power, a lower-rate AMR codec can provide wider uplink coverage.

When the radio environment is good, a high-rate codec can provide better speech quality than

a low-rate codec. When the radio environment is poor, a low-rate codec can provide better

speech quality than a high-rate codec. Therefore, the rate of the AMR codec should be

adjusted in real time to ensure high-quality speech services.

Description

The AMR Mode Control (AMRC) is a feature that enables the RNC to control 8 types of

speech rates, namely 12.2 kbit/s, 10.2 kbit/s, 7.95 kbit/s, 7.4 kbit/s, 6.7 kbit/s, 5.9 kbit/s, 5.15

kbit/s, 4.75 kbit/s, and wide band AMR 23.85 kbit/s, 23.05 kbit/s, 19.85 kbit/s, 18.25 kbit/s,

15.85 kbit/s, 14.25 kbit/s, 12.65 kbit/s, 8.85 kbit/s and 6.60 kbit/s. This improves speech

quality and enlarges uplink coverage and reduces system load level.

Before RAN5.0, the decision of adjusting the AMR rate considers the downlink transmitted

power for DL and UE transmitted power for UL. If the transmit power exceeds the

pre-defined threshold, it indicates that the link quality is poor.

In RAN5.1, cell load is used for AMRC trigger, where RNC will monitor the cell loading

continuously and dynamically to adjust the user’s speech code rate according to the change of

the cell loading. When the loading is heavy, low bit rate of AMR speech CODEC is used to

decrease the cell loading and when the cell loading is light, high bit rates of AMR speech

CODEC is used to provide higher voice quality for users.

The AMRC is one action to be done during the load reshuffling (LDR) procedure. The LDR is

one of the congestion control mechanisms triggered when NodeB Common Measurement (TCP, Transmitted Carrier Power) for DL, and NodeB Common Measurement (RTWP) for



UL, exceed the LDR threshold. The system will enter ‘basic congestion’ status. After the LDR

is triggered, the AMRC serves as a method to decease the system load. The RNC will select

the candidate AMR user according to the ARP and current user rate. Low ARP user will be

selected first to adjust the rate and if ARP is the same, the user with high voice rate will be

firstly selected to adjust the rate.

After the user voice rate is degraded, it depends on the downlink transmitted power for DL

and UE transmitted power for UL for rate increase, as the mechanism used for RAN5.0.

Enhancement

In RAN5.1, the AMRC is added as an action in basic feature WRFD-020106 Load

Reshuffling.

In RAN6.0, this feature can also be used to AMR-WB service which requires the optional

feature WRFD-010603 AMR-WB (Adaptive Multi Rate Wide Band).

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should support the processing of TFC control procedure.


None

Dependency on CN

None


If this feature is to be applied to the AMR-WB, then the Dependency is:

WRFD-010613 AMR-WB (Adaptive Multi Rate Wide Band)

1.2.3 WRFD-011600 TFO/TrFO

Availability

This feature is available from RAN3.0


Summary

This feature enables the identification and processing of the IUUP V2 CN to support the

TFO/TrFO service.



Benefits

This feature can prevent degradation of the speech quality introduced by the interpretation

between different codecs. The TrFO can also save the transmission resources.

Description

TFO/TrFO features are introduced in Release 4 and used to prevent degradation of the speech

quality. This degradation is produced by the interpretation between the different codecs and is

usually more noticeable when the speech CODECs are operating at low rates and in noisy

conditions.

Tandem Free Operation (TFO) removes the double speech encoding/decoding done in the

TRAUs in MS-to-MS calls by "tunneling" the "compressed" speech through the 64 kbit/s

PCM (Pulse Code Modulation) links of the core network. NO transmission resource will be

saved.

For Transcoder Free Operation (TrFO), there is no constraint to use PCM link on the Nb

interface; therefore, in addition of the advantages proposed by TFO, it can also save the

transmission resources. TrFO can also be used in mobile-to-fix calls.

On the access network side, the RNC cannot really identify the TFO/TrFO service. The RNC

can, however, identify the CN IUUP version and perform related processing of the IUUP V2

to support the TFO/TrFO service.

Enhancement

In RAN5.0, AMRC under TFO/TrFO is supported.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE must have the corresponding support capability.


None

Dependency on CN

The CN node needs to support the feature at the same time.


None



1.2.4 WRFD-140201 AMR Voice Quality Improvement Based on PLVA

Availability


Summary

AMR Voice Quality Improvement Based on PLVA improves adaptive multi-rate (AMR) voice

quality by using Huawei Parallel List Viterbi Algorithm (PLVA) to decode convolutional

codes, reducing the proportion of low and medium mean opinion scores (MOSs).

Benefits

This feature noticeably improves the quality of voice services, which in turn improves user

experience. In simulations, the MOS of AMR voice services increases by about 0.35 when the

block error rate (BLER) is greater than 10%.

Description

AMR is a speech coding standard widely used in GSM and UMTS communications systems.

In UMTS, convolutional codes are used to perform channel encoding and a power control

mechanism is used to ensure voice quality.

Figure 1.2.4-1 Channel encoding and power control for AMR voice services in the uplink in

UMTS

Uu

UE NodeB RNC CN

AMR Speech

Codec

Iub Iu

CC Encoder

Inner-Loop

Power Control

Outer-Loop

Power Control

CC Decoder

AMR Speech

Codec

Decoded Data

CRCI

Target

SINR

Power

Transmitter

Measured

SINR

Power

Commander

Currently, most vendors use the Viterbi algorithm to decode convolutional codes. The Viterbi

algorithm selects the optimal path based on the maximum likelihood theory and exports the

data decoded on the optimal path. If the data decoded on the optimal path fails the cyclic

redundancy check (CRC), the AMR speech codec usually discards the data, and voice quality

deteriorates as a result.



Huawei uses the PLVA algorithm to decode convolutional codes. The PLVA algorithm is an

enhanced CRC-assisted Viterbi algorithm. Instead of only selecting the optimal path, the

PLVA algorithm selects the top N optimal paths and performs CRC on the data decoded on

these paths. The PLVA algorithm only exports data that passes the CRC. If data decoded on

these paths fails the CRC, the NodeB exports the data decoded on the optimal path. In

simulations where the PLVA algorithm selects four paths, signal-to-noise ratio (SNR) is 0.2 to

0.8 dB better than that produced by the Viterbi algorithm.

This feature increases the MOS of AMR voice services, including narrowband and wideband

AMR voice services. Take 12.2 kbit/s AMR voice services as an example. In simulation, if the

BLER is 1%, the MOS is increased by 0.08. If the BLER is greater than 10%, the MOS is

increased by about 0.35. (The BLER increase is generally caused by UE power limitation, fast

channel change, or strong interference.) Generally, the MOS increase produced by the PLVA

algorithm is directly proportional to the BLER. In addition, MOS increase is generally the

same under different channel fading conditions.

Figure 1.2.4-2 Different MOSs for 12.2 kbit/s AMR voice services on TU50 channels with

different BLERs

Enhancement

None

Dependency

Dependency on RNC hardware

None

Dependency on NodeB hardware

The BTS3812E, BTS3812A and BTS3812AE must be configured with the EULPd

board.

The DBS3800 must be configured with the EBBCd board.

The 3900 series base stations must be configured with the WBBPd or WBBPf board.

Currently, for baseband boards, only the EULPd, EBBCd, WBBPd and WBBPf boards support the PLVA feature. When the EULPd, EBBCd, WBBPd or WBBPf board is



inserted together with the other types of baseband boards, AMR services cannot obtain

the PLVA gain if the AMR services are set up on the other types of baseband boards.

Dependency on the UE

None

Dependency on other NEs

None

Dependency on the CN

None

Dependency on other RAN features

None

1.3 CBS

1.3.1 WRFD-011000 Cell Broadcast Service

Availability



Summary

This feature supports the standard cell broadcast procedure as stipulated in protocols to assist

the CBC for the cell broadcast service.

Benefits

The users can use the new services based on the CBS.

Description

The CBS service is analogous to the teletex service offered on television, in that like teletex, it

permits a number of unacknowledged general CBS messages to be broadcast to all receivers

within a particular region. CBS messages are broadcast to defined geographical areas known

as cell broadcast areas. These areas may comprise of one or more cells, or may comprise the

entire PLMN.

The Iu BC interface connects the RNC in UTRAN with the broadcast domain of the Core

Network, namely with the Cell Broadcast Center. It is used to define the Cell Broadcast

information that is transmitted to the mobile user via the Cell Broadcast Service. The cell

broadcast center (CBC) is part of core network in UMTS and up to 4 CBCs can connect to

RNC via a routing node like WCDMA SGSN.



Enhancement

RAN6.0 supports four CBCs instead of one CBC of the previous versions.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should have the capability to receive cell broadcast messages.


None

Dependency on CN

None


None

1.3.2 WRFD-011001 Simplified Cell Broadcast

Availability

This feature is introduced in RAN11.1.

Summary

This feature offers a solution to broadcast some simple message to the UE while there is no

Simplified cell broadcast is a function implemented in RNC that allows using SMSCB (Short

Message Service Cell Broadcast) without the necessity of having a Cell Broadcast Center.

Benefits

With this feature, the most commonly used cell broadcast services are supported through a

simple command in RNC. Which avoids investing in a Cell Broadcast Center and contributes

to CAPEX saving.

Description

The Short Message Service Cell Broadcast (SMSCB) function enables the broadcast of short

messages to all MSs in one or several cells, or even the entire PLMN. The MSs can receive

the broadcast messages continuously or discontinuously according to the system

configuration.



Usually there is a Cell Broadcast Center (CBC) responsible for managing and scheduling the

SMSCB.

Huawei Simplified Cell Broadcast function performs through a built-in cell broadcast

processing module in the RNC without CBC, and reduces equipment costs.

Huawei simplified cell broadcast function enables the broadcast of messages, such as the cell

name, weather forecast, and social commonweal messages. The following describes the

details of these functions:

Information broadcast function: broadcasting messages such as the NodeB name, cell

name, weather forecast, or any character string. The maximum length is 100 ASC

symbols. The messages are input manually by MML command.

Information timing broadcast function: sending cell broadcast messages at specified

intervals.

Information management function: On the M2000 MML client, you can use the MML

commands to start or stop sending the broadcast messages in specified cells or all cells,

and stop sending a specified cell broadcast message. In addition, you can use the MML

commands to query the cell broadcast status.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should have the capability to receive cell broadcast messages.


None

Dependency on CN

None


The Huawei simplified cell broadcast function cannot be used simultaneously with

WRFD-011000 CBC cell broadcast function.

1.3.3 WRFD-020127 Warning of Disaster

Availability




Summary

The RNC can send a disaster notification to all the UEs in a cell through the simple cell

broadcast function right after a disaster occurs.

Benefits

This feature enables the RNC to quickly (within four seconds) send the disaster information to

all the UEs, reducing the impact of the disaster.

Description

When a disaster (such as earthquake or tsunami) occurs, a disaster pre-warning notification

can help reduce the casualty and losses.

Huawei RNC can perform simple cell broadcast through the built-in CBC. If no external CBC

is deployed, Huawei RNC can run an OM command to inform all the UEs in the cell of the

disaster information as soon as possible. The RNC can originate, modify, and release

broadcast messages. The RNC can also predefine a broadcasting area. All the broadcast

messages are triggered manually. When the RNC OM personnel know the disaster

information, the personnel must send a broadcast command and the broadcast information is

immediately sent to the RNC through an OM terminal. In RAN12.0, Huawei RNC shortens

the delay of each channel in the system to ensure that all the UEs within the RNC are

informed of the disaster information within a short period of time, generally four seconds.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-011001 Simplified Cell Broadcast



1.4 MBMS

1.4.1 WRFD-010616 MBMS Introduction Package

Availability



Summary

This feature provides basic MBMS functions to meet the requirements of the operator for

MBMS applications.

Benefits

This feature improves the network resource utilization, especially the utilization of resources

on the Uu interface. It is an efficient way for the operators to deploy the point-to-multipoint

services, such mobile TV.

Description

The multimedia broadcast and multicast service (MBMS) is a new important feature for the

3GPP Release 6 specifications. It is a point-to-multipoint service in which the data is

transmitted from a single source entity to multiple recipients. Transmitting the same data to

multiple recipients allows the network resources to be shared.

The MBMS bearer service offers two modes:

Broadcast mode;

Multicast mode.(Not supported by Huawei RNC)

The MBMS architecture enables the efficient use of the radio network and core network

resources, with an emphasis on the radio interface efficiency. For one MBMS service, there is

only one copy of data on the Iu interface, and the RNS distributes the data to all associated

UEs.

The MBMS is realized by a number of additional new capabilities in the existing functional

entities and additional new functional entities. The whole MBMS architecture is as follows:



UE SGSN

UE GERAN

UTRAN

HLR

GGSN

TPFBM - SC

ContentProvider /MulticastBroadcastSource

Uu Iu

Iu /Gb

Um

Gr

Gn /Gp

Gi

PDN

(e .g . Internet )

Gmb

ContentProvider /MulticastBroadcastSource

The introduction of the MBMS has the following impacts on the RAN:

Some new signaling procedures are added on the Iub/Uu/Iur/Iu interface.

New physical channels (MICH) are added.

New logical channels (MCCH/MTCH/MSCH) are added.

MAC-c/sh is changed to MAC-c/sh/m in order to add the MAC-m to the MBMS.

Soft/selective combination function of the common channels is introduced.

The common channels may be used over the air interface, and the UE may receive the service

in idle mode. So the number of UEs is not limited in a cell and a group.

The UE may receive the same MBMS service in the common channels from different cells.

And by soft/selective combination, less power is needed for the common channels.

The BSC6800 supports the MBMS services with the total traffic of up to 4096 kbit/s on the Iu

interface and 64 sessions can be supported simultaneously.

The BSC6900 supports the MBMS services with the total traffic of up to 8192 kbit/s on the Iu

interface and 256 sessions can be supported simultaneously.

Enhancement

In the RAN10.0, the MBMS introduction package is enhanced. For details, refer to the

enhancement of the features in the package.

Dependency

Dependency on RNC

The BSC6910 does not support this feature.

Dependency on NodeB

None



Dependency on UE

The UE should support MBMS functions.


None

Dependency on CN

The existing PS Domain functional entities (GGSN, SGSN, UTRAN, GERAN and UE)

need to be enhanced to provide the MBMS bearer service.

A new functional entity, the broadcast multicast service centre (BM-SC) is added to

provide a set of functions for the MBMS users Services.


None

1.4.2 WRFD-01061601 MBMS Broadcast Mode

Availability


Summary

In MBMS broadcast mode, MBMS information is transmitted through common channels of a

cell.

Benefits

With this feature, the operators can deploy rich multimedia services, such as mobile TV.

Description

The MBMS bearer service offers two modes:

Broadcast mode

Multicast mode

The broadcast mode is the unidirectional point-to-multipoint transmission of multimedia data

(such as text, audio, picture, video) from a single source entity to all users in the broadcast

service area. It is expected that charging data for the end user will not be generated for this

mode at the MBMS transport service layer. Charging data related to security procedures for

the end user at the MBMS user service layer may be generated.

The multicast mode allows the unidirectional point-to-multipoint transmission of multimedia

data (such as text, audio, picture, video) from a single source entity to a multicast group in the

multicast service area. Unlike the broadcast mode, the multicast mode generally requires a

subscription to the multicast subscription group and the users joining in the corresponding

multicast group. It is expected that charging data for the end user will be generated for this

mode at the MBMS transport service layer.



When receiving the MBMS services in the broadcast mode, the UE may stay in the

URA_PCH/CELL_PCH/CELL_FACH and idle mode. If the capability allowed, the UE can

receive the MBMS service even on the CELL_DCH.

Huawei UMTS RAN6.0 only supports the broadcast mode.

Enhancement

In RAN10.0, the UE in URA_PCH, CELL_PCH, FACH, or idle mode supports the MBMS

service.

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-010616 MBMS Introduction Package

1.4.3 WRFD-01061602 MBMS Admission Control

Availability


Summary

This feature is related to admission control for the MBMS service.

Benefits

The cell power is allocated preferentially to the MBMS broadcast service with higher priority.

Description

Like the admission control for the R99 services, the following factors will be taken into

account:

Cell available code resources



Cell available power resources

NodeB resource state, that is, NodeB credits

Available Iub transport layer resources

Only when all of these resources above are available can a MBMS service be admitted.

The MBMS broadcast service is established (PTM bearer) on the common channel. Two

power levels (upper and lower levels) are defined for the MBMS broadcast service.

When there is enough power resources in the cell, the upper power level will be used;

When the cell is in the basic congestion, the upper power level will be used for the

MBMS service whose priority is higher than or equal to a configured priority threshold

and the lower power level will be used for the MBMS service whose priority is lower

than the configured priority threshold;

When the cell load recovers from the congestion to normal, the RNC will automatically

adjust the power level to the upper one for that MBMS service.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



1.4.4 WRFD-01061603 MBMS Load Control

Availability


Summary

This feature is related to load control for the MBMS service.



Benefits

The feature helps to decrease the cell load when the cell enters the congestion state and

ensures the system stability.

Description

When the cell is in the basic congestion, reduction of the MBMS service power may be

triggered when the downlink congestion is detected. The details are as follows:

The RNC selects all the MBMS broadcast services with priority lower than the

configurable threshold named the MBMS priority threshold and sort them in the

ascending order;

When the cell is in the congestion, the RNC will check them one by one. If there is one

service that is using the upper power level threshold, the RNC can move it to the lower

power level threshold by common transport channel reconfiguration procedure. Then the

action ends.

If all the MBMS broadcast mode services are using the lower power level threshold, the

action ends.

When the cell is in the congestion, the RNC can trigger the release of the MBMS broadcast

mode service. Some MBMS services with the lowest priority will be released first. After that,

a periodic reestablishment attempt timer for each service will be started.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





1.4.5 WRFD-01061604 MBMS Soft/Selective Combining

Availability


Summary

This feature is related to soft combination and selective combination for the PTM MBMS

service.

Benefits

With this feature, the power of the S-CCPCH that bears the MBMS services can be saved.

Description

The common channel soft combination is a function introduced for the MBMS. It means that

the UE receiver combines the signal from the multiple cells either in the RAKE receiver or

after the RAKE receiver in the receiver chain prior to the decoding of the soft combination

transport channel. The maximum time difference between the S-CCPCHs carrying the same

service in different cells should be less than 1TTI+1slot.

The soft combination normally improves the UE reception gain by 5 - 7 dB.

The selective combination (SC) is an enhancement for the Release 6 PtM MBMS. The

network is to simulcast the PtM MBMS contents on the S-CCPCH, and the UE receives and

decodes the MBMS data from multiple radio links simultaneously. The selection of the radio

link is to be performed on a transport block basis at the RLC, based on the CRC results and

sequence numbers.

The selective combination normally improves the UE reception gain by 3 - 5 dB.

The RNC should ensure that the services data sent to the UE from different cells are

synchronized.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None




None

Dependency on CN

None



1.4.6 WRFD-01061605 MBMS Transport Resource Management

Availability


Summary

This feature is related to the transport resource management for the MBMS service.

Benefits

It is an essential feature to deploy MBMS broadcast mode services.

Description

For the same MBMS session in the same NodeB, a separate Iub transport bearer is established

for each cell. An example is shown in the following figure assuming 3 cells in one NodeB.

Three copies of exact same MBMS session data are sent through the Iub from the CRNC to

the NodeB.

CRNC Node B

MBMS stream

broad

CN

Iub transport bearers

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None



Dependency on UE

None


None

Dependency on CN

None



1.4.7 WRFD-01061606 Streaming Service on MBMS

Availability


Summary

This feature enables the MBMS service to be carried on the PS streaming class, ensuring

QoS.

Benefits

The feature can meet the QoS requirements of the service applications borne by the streaming

class.

Description

Compared with the point-to-point bearer services, the following limitations for the MBMS

services exist:

For the traffic class, only the background and streaming classes can be supported;

For the SDU error ratio, only larger values are supported, such as the values describing

higher numbers of the lost or corrupted SDUs (actual values for the background and

streaming classes are 10-2

and 10-1

);

For guaranteed bit rates of the streaming traffic class: it depends on the radio resource

usage by other services, some cells of the MBMS service area may not have sufficient

resources available for a MBMS session. The RAN may decide not to establish the RB in

the cells where requested resources are not available.

The MBMS bearer of the background class is most suitable for the transport of the MBMS

user services such as messaging or downloading. The MBMS bearer of streaming class is

most suitable for the transport of the MBMS user services such as mobile TV. The main

difference between the background and streaming classes for the MBMS is the support of a

guaranteed bit rate in the streaming case. The MBMS user services that normally use the

background class may however decide to use a streaming class if the MBMS user service

cannot cope with the high packet loss.

The RAN 6.1 only supports the streaming class MBMS service.



Enhancement

In the RAN10.0, a maximum of 2 PTP streaming RBs for the MBMS service can be

established for the UE in enhanced broadcast mode.

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



1.4.8 WRFD-01061607 MBMS 2 Channels per Cell

Availability


Summary

With this feature, each cell supports up to two channels for the MBMS service.

Benefits

The feature is an essential function for the deployment of the MBMS service application.

Description

The MBMS two channels per cell are supported.

Enhancement

None

Dependency

Dependency on RNC




Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



1.4.9 WRFD-01061608 16/32/64/128Kbit/s Channel Rate on MBMS

Availability


Summary

This feature is related to four MBMS channel rates: 16kbit/s, 32kbit/s, 64kbit/s, and 128kbit/s.

Benefits

The feature enables different channel rates and provides operators with more flexibility to

deploy the MBMS services.

Description

The MBMS broadcast mode service bit rate can be 64kbit/s or 128kbit/s. The TTI for 64kbit/s

is 80 ms and the TTI for 128kbit/s can be 40 ms or 80 ms.

Enhancement

In the RAN10.0, 16 kbit/s or 32kbit/s can also be supported for which only 80 ms is used by

the TTI.

Dependency

Dependency on RNC


Dependency on NodeB

None



Dependency on UE

None


None

Dependency on CN

None



1.4.10 WRFD-010660 MBMS Phase 2

Availability



Summary

This feature supports the enhanced MBMS (PTP/PTM) to save cell resources.

Benefits

Compared with the broadcast mode, MBMS Phase 2 can effectively implement PTM services,

for example, mobile TV. In PTP/PTM mode, cell resources can be saved.

Description

MBMS Phase 2 refers to enhanced broadcast mode introduced in 2006/09 3GPP

specifications. Compared with broadcast mode, the main differences include:

The "Counting/re-counting" function used for multicast mode is introduced for enhanced

broadcast. During the counting/re-counting procedure, the UE reports its selected

services to the RNC directly over the Uu interface.

Based on "Counting/re-counting" result, RNC can select optimum transfer mode: PTM

(Point To Multipoint) or PTP (Point To Point). In PTM mode, FACH/SCCPCH is used to

bear the MBMS services; in PTP mode, DCH or HSDPA is used to bear the MBMS

services. If in a cell there is no user interested in one specific MBMS service, RAN can

decide to cancel it.

Enhancement

None

Dependency

Dependency on RNC




Dependency on NodeB

None

Dependency on UE

The UE should support the corresponding enhanced MBMS functions.


None

Dependency on CN

None



1.4.11 WRFD-01066001 MBMS Enhanced Broadcast Mode

Availability


Summary

This feature is related to the enhanced broadcast mode for the MBMS service.

Benefits

Compared to broadcast mode, it is a more efficient way to deploy the point-to-multipoint

services, such mobile TV.

Description

MBMS enhanced broadcast mode is very similar to multicast mode on RAN side, but much

modification on CN side and NAS procedures are avoided by introducing

"counting/re-counting" function. To support it, the following functions on enhanced broadcast

mode are introduced:

Counting/Re-counting. In "MBMS Modified Services Information" message RNC

indicates UE to initiate counting/re-counting response and in "MBMS Access

Information" message RNC gives the "Access probability factor" to UEs in Idle mode.

For UEs in connected mode, it will report to RNC its selected services by "MBMS

Modification Request" message. So RNC will get the number of UEs which are

interested in one specific MBMS service.

In addition, in order to simplify the counting/re-counting procedure, RNC keeps X UEs

in the connected mode.

The dynamic switch between PTP and PTM transfer mode for one MBMS service. When

deciding the optimum transfer mode for one service in a cell, some factors are taken into

account: the load of cell, the number of UE, and the status of the MBMS neighboring

cells.



The mobility management for UE.

− From a PTM cell to another PTM cell. In this scenario, UE will select to receive the

MBMS services in the new cell.

− From a PTM cell to a PTP cell. In this scenario, PTP RB will be established for UE.

− From a PTP cell to a PTM cell. In this scenario, if PTM mode is used in the UEs’ best

cell, PTP RB will be released.

− From a PTP cell to another PTP cell. Handover will be supported.

The combination of MBMS service and non-MBMS services for UE.

− When the MBMS service is in PTM mode, UE can decide whether to receive this

service according to its capability;

− When MBMS service is in PTP mode, RNC will establish the separate PTP RB for

every UE and treat it as an ordinary PS RB. And multiple RAB will be supported.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



1.4.12 WRFD-01066002 MBMS P2P over HSDPA

Availability


Summary

This feature enables MBMS P2P services to be carried on the HS-DSCH, saving cell

resources.



Benefits

By HSDPA, the cell capacity will be improved.

Description

In enhanced broadcast mode, PTP and PTM mode can be selected to transport MBMS

services. If PTP mode is adopted, RNC will establish the separate PTP RB for every UE. Like

the non-MBMS service, HSDPA can be used to bear PTP MBMS RB and multiple RAB such

as combination of P2P MBMS streaming and I/B PS over HSDPA.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



1.4.13 WRFD-01066003 MBMS Admission Enhancement

Availability


Summary

This feature provides different admission policies for PTM and PTP MBMS services.

Benefits

MBMS PTM bearers should be treated differently so that they do not occupy too many

resources to block non-MBMS connection admission. In addition, some resources should be reserved for the use of MBMS PTM.



Description

Besides PTM bearer, MBMS enhanced broadcast also supports PTP bearer, which can be

carried on DCH or HS-DSCH. For MBMS PTP users, same admission, pre-emption and

congestion criteria are applied as with normal non-MBMS HSDPA users.

When performing pre-emption, all types of bearer are taken into account including MBMS

PTM bearer, MBMS PTP bearer, normal non-MBMS bearer, which means every bearer type

can pre-empt each other. Whether MBMS PTM bearer is allowed to pre-empt other services

are controlled by parameter settings.

In case PTM bearer is allowed to pre-empt other services, the following QoS rules are

possible by parameter settings:

PTM streaming bearer can pre-empt other MBMS or non-MBMS services with traffic

class interactive/background and less or equal ARP priority.

PTM background bearer can pre-empt other MBMS or non-MBMS services with traffic

background and less ARP priority.

No services are allowed to pre-empt PTM with streaming traffic class.

PTP or Non-MBMS guaranteed services are allowed to pre-empt PTM with background

traffic class and lower ARP priority.

PTP or Non-MBMS background services are allowed to pre-empt PTM with background

traffic class and lower ARP priority.

While MBMS PTM bearer consumes less resource but serves for more subscribers, some

special strategies are developed for it. 2 specific thresholds are introduced for only Power and

Code: Treserved, Tmax.

When all the resources occupied by all MBMS PTM bearers in a cell are below Treserved,

PTM bearers can NOT be pre-empted by non PTM bearers (that is, MBMS PTP bearers

or normal non-MBMS bearers).

When any resource occupied by all PTM bearers in a cell is above Tmax, PTM bearers are

rejected by admission control and they can NOT pre-empted non PTM bearers (that is,

MBMS PTP bearers or normal non-MBMS bearers). At this moment, they can only

pre-empt other low priority PTM bearers.

Other cases, the general pre-emption rules will be applied. When all the other priorities

are the same, the final prioritization is: MBMS PTM bearer > non-MBMS bearer >

MBMS PTP bearer.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE



None


None

Dependency on CN

None



1.4.14 WRFD-01066004 Inter-Frequency Neighboring Cell Selection for MBMS PTP Users

Availability


Summary

This feature enables the filtering and handover of a target cell based on the MBMS channel

resources in the inter-frequency neighboring cells, ensuring the continuity of the MBMS

service.

Benefits

With this feature, the neighboring cells which are not suitable for MBMS PTP users will be

filtered. This maintains the service continuity of MBMS in a more reasonable and intelligent

way.

Description

This function is applied when multi-carriers and single carriers are neighboring carriers. For

MBMS PTP users, inter-frequency handover may interrupt MBMS services; therefore, service

interruption should be avoided to ensure service continuity. This function is not intended for

MBMS PTM users or PTP users with other services accompanied.



As shown in the figure above, the f3 cell has inter-frequency neighboring cells f1 and f2. At

the border between the f1 or f2 cell and the f3 cell, when an MBMS PTP user handover from

the f3 cell to the f1 or f2 cell, the RNC shall select from the inter-frequency neighboring cell

list according to the current service received by the user. If the currently received service is

from channel 3, the RNC removes the f2 cell from the list; if the currently received service is

from channel 1 or 2, the RNC keeps the f1 and f2 cells in the list.

There can be more complicated cases.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



WRFD-010660 MBMS Phase 2

1.4.15 WRFD-010627 FACH Transmission Sharing for MBMS

Availability


Summary

This feature enables the FACH carrying the same MBMS service on the Iub interface to share

a transmission resource, saving the Iub bandwidth.

Benefits

This feature can save Iub transmission resources when the MBMS service is deployed.



Description

This feature improves efficient Iub transport for MBMS. In previous 3GPP Rel-6, for the

same MBMS session in the same NodeB, a separate Iub transport bearer has to be set up for

each cell. An example is shown in the following figure assuming 3 cells in one NodeB. Three

copies of exact same MBMS session data are sent via Iub from CRNC to NodeB, which is a

big waste of Iub bandwidth.

CRNC Node B

MBMS stream

broad

CN

Iub transport bearers

To maximize saving of Iub bandwidth, the latest 3GPP Rel-6 provide FACH transmission

sharing for MBMS solution to share transport bearers. RNC transports only single FACH data.

NodeB transport module performs data duplication and distributes them to different FACH

Channels, as shown in the following figure, where the common transport bearer is shared over

Iub. Obviously, two-third of Iub bandwidth is saved by the improved Iub transport.

CRNC Node B

MBMS stream

broad

CN

Iub transport bearer

The feature has optimization in the control plane. Bearer multiplexing information is carried

by newly introduced NBAP signaling IEs. The advantage of this solution is that current

MBMS FP structure is kept unchanged. However, due to lack of knowledge of NodeB's

capability to share transport bearer, CRNC always sends message of bearer multiplexing

request to NodeB no matter whether NodeB can/will share transport bearer or not. For NodeB

which can not or would not like to share, non-shared transmission bearer will be setup as in

the original way.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB



None

Dependency on UE

None


None

Dependency on CN

None



1.4.16 WRFD-010626 MBMS FLC(Frequency Layer Convergence)/FLD(Frequency Layer Dispersion)

Availability



Summary

This feature supports the reselection procedure of the MBMS frequency layer initiated by the

UE.

Benefits

With FLC, the user can acquire the information about MBMS services in time.

With FLD, the cell load can be reduced when the MBMS session is stopped.

Description

Frequency Layer Convergence denotes the process where the UTRAN requests UEs to

preferentially re-select to the frequency layer on which the MBMS service is intended to be

transmitted. This layer preference could be done by an additional MBMS session related

Layer Convergence Information (LCI) such as offset and target frequency. The FLC is

supported by specifications for both networks utilizing HCS and for networks not utilizing

HCS.

Frequency Layer Dispersion (FLD) denotes the process where the UTRAN redistributes UEs

across the frequencies. UTRAN can use FLD per MBMS session.

When FLD is applied, the UE stores the frequency where it was camped previously. Upon

session stop, the UE attempts to return to that frequency.

Enhancement

None



Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

The UE should support this function.


None

Dependency on CN

None




Availability


Summary

With this feature, each cell supports up to eight channels for the MBMS service.

Benefits

It provides the operator the flexibility to deploy more MBMS services in a cell.

Description

In RAN6.0, up to 8 channels are supported per cell if only the total bit rate of all channels is

no more than 1024 kbit/s. The MBMS channel bit rate can be 16, 32, 64, 128, or 256 kbit/s.

Enhancement

In RAN10.0, up to 8 channels can be supported per cell if only the total bit rate of all channels

is no more than 1792 kbit/s. The MBMS channel bit rate can be 16, 32, 64, 128, or 256 kbit/s.

Dependency

Dependency on RNC


Dependency on NodeB



None

Dependency on UE

None


None

Dependency on CN

None



Enhanced MBMS

1.4.18 WRFD-010625 256Kbit/s Channel Rate on MBMS

Availability


Summary

With this feature, Huawei RAN can support an MBMS channel rate of 256 kbit/s.

Benefits

The operator can deploy high bit-rate services to provide better user experience.

Description

In RAN6.0, 256 kbit/s MBMS Broadcast Mode service is supported and one cell can support

4 such services. The TTI for 256 kbit/s service is 40ms.

Enhancement

In RAN10.0, the maximum number of 256 kbit/s channels is enhanced from 4 to 7 per cell.

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None




None

Dependency on CN

None




Availability


Summary

With this feature, each cell supports up to 16 channels for the MBMS service.

Benefits

It provides the operator the flexibility to deploy more MBMS services in a cell.

Description

In RAN10.0, up to 16 channels can be supported per cell if only the total bit rate of all

channels is no more than 1792 kbit/s. The MBMS channel bit rate can be 16, 32, 64, 128, or

256 kbit/s.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





1.4.20 WRFD-010661 MBMS over Iur

Availability



Summary

This feature supports the MBMS service crossing the Iur interface to extend the application

scope of the MBMS service.

Benefits

This feature provides completed functions of MBMS over Iur and keeps the MBMS service

continuity and improves user perception.

Description When CELL_PCH/CELL_FACH/URA_PCH UE moves into DRNC and Iur interface

exists:

− if there is no non-MBMS services established for this UE, SRNC will indicate UE to

release the RRC connection;

− If there has been non-MBMS services established for this UE, SRNS relocation with

CELL/URA update will be triggered.

When CELL_DCH UE moves into DRNC and Iur interface exists, Iur soft handover will

be triggered.

When UE moves into DRNC and Iur interface does not exist, DRNC will indicate UE to

release the RRC connection.

DRNC informs SRNC through Direct Information Transfer:

The MBMS service transfer mode in the cell during Session setup;

The MBMS service transfer mode change in the cell during session transferring;

The Preferred Frequency Layer information of MBMS service;

The Iur interface mobility management is enhanced in RAN11.0. For example, when the UE

which has MBMS service in PTP mode in CELL_DCH state moves to DRNC from SRNC, it

will setup a new RL through Iur interface. However, if the cell in DRNC is transferring the

MBMS service through PTM mode, and the UE just has MBMS service, the UE will get the

MBMS service through PTM mode in DRNC to save transmission resources.

Enhancement

In RAN11.0, the DRNC informs the SRNC about more MBMS service control information

through the Direct Information Transfer message.



Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


The neighboring RNC should support MBMS Iur function.

Dependency on CN

None



1.4.21 WRFD-010662 Dynamic Power Estimation for MTCH

Availability


Summary

This feature enables the dynamic adjustment of the transmit power of the MTCH based on the

number of neighboring cells in PTM mode.

Benefits

Cell power can be saved by making use of soft combining gain with neighbors.

Description

To guarantee the QoS at the cell boundary, power setting for MTCH (PTM bearer) is high in

general, which means power waste. Simulation also shows that soft combining can provide

quite high gain (4.6–6.6 dB), so it’s possible to set power dynamically.

Dynamic Power Setting in PTM mode:

If more than a certain portion (operator accessible parameter) of neighbors adopt PTM

mode, the power setting for the serving cell can be decreased by a specific offset

(operator accessible parameter).

If less than a certain portion of neighbors adopt PTM mode, the power setting for the

serving cell would be recovered to the original one.



This feature will not conflict with the two power levels (Upper and Lower) defined for

MBMS Broadcast Service. Furthermore, this feature takes effect on the base of the latter

feature because it only introduced a power OFFSET.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



1.4.22 WRFD-010663 MSCH Scheduling

Availability


Summary

This feature enables the UE to perform DRX on the MTCH based on MSCH scheduling,

saving the power consumption of the UE.

Benefits

MSCH enables the UE to perform DRX on the MTCH and saves power consumption of the

UE.

Description

The RNC can send the MBMS scheduling information to the UE on the MSCH, which

enables the UE in PTM reception mode to implement Discontinuous Reception (DRX) on the

MTCH instead of continuous reception on the MTCH. This effectively reduces power consumption of the UE. The MBMS scheduling information is sent periodically and the



period is called "MSCH reception cycle". The MSCH reception cycle and its offset

information are transmitted on the MCCH. When the MSCH is used, each S-CCPCH bearing

the MTCH/FACH should carry an MSCH/FACH. The channel mapping is shown below:

RAN11.0 supports the MSCH as follows: One cell supports up to 8 MSCHs (in the case of 16

MTCHs and 8 S-CCPCHs)

Restriction: If one S-CCPCH bears only one MTCH, then the MSCH should not be used.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





1.4.23 WRFD-010665 MBMS Channel Audience Rating Statistics

Availability


Summary

This feature enables the statistics of the information on MBMS channels to help the operator

obtain the audience rating of the MBMS channels.

Benefits

With this feature, the operator can obtain the audience rating statistics on MBMS channels

and their occupation in system resources.

Description

This function takes traffic statistics based on MBMS channels. Up to five channels to be

measured can be set on the M2000, then the channels ID will be sent to the corresponding

RNC. The RNC takes statistics of the following counters:

Average number of users in PTP mode

Average number of users in PTM mode

Time for channels remaining in PTM mode

Time for channels remaining in PTP mode

Based on the previous counters, the average time for each online user of the channel can be

calculated.

Enhancement

Currently, general counters are measured on the basis of a cell.

As the operator has a strong desire to obtain the counters based on MBMS channels, this

feature is a very important function.

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None



Dependency on CN

The BMSC on the CN side shall identify the channels with a fixed TMGI when delivering the

program source.



Domain Specific Access Control (DSAC)

1.5 LCS

1.5.1 WRFD-020801 Cell ID + RTT Function Based LCS

Availability



Summary

With this feature, Huawei RAN supports location services based on Cell ID + RTT.

Benefits

This feature provides a location service for operators.

Description

Huawei RAN supports location service based on Cell-Id + RTT which locates the UE

(CELL-DCH) position by computing the TOA. (Time of Arrive).



The TOA can be derived by the NodeB RTT (Round Trip Time) measurement and the UE

Rx-Tx time difference Type 2 measurement.

NodeB

UE

RTT Measurement

UE Rx-Tx time difference Type2 Measurement

In the CELLID+RTT positioning method, the simplest solution is to take the geometrical

center of the reference cell coverage area as the positioning result. This solution requires no

positioning-related measurement and provides the shortest response time.

If the CN requires a positioning of high accuracy, the CELLID+RTT method must employ

more measurements as follows:

The RNC asks all cells in the active set to perform the RTT measurement.

The RNC asks the UE to perform the UE Rx-Tx type 2 measurement of the

corresponding cell. If the UE does not support the UE Rx-Tx type 2 measurements, the

RNC will ask the UE to perform the UE Rx-Tx type 1 measurement.

When the cell is located in different RNCs, the location over Iur is supported.



Enhancement

Location over Iur interface is supported in RAN5.1.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

UE is needed to report the relevant measurement results.


None

Dependency on CN

CN is needed to trigger the location request.


None

1.5.2 WRFD-020802 OTDOA Based LCS

Availability



Summary

With this feature, Huawei RAN supports IPDL-OTDOA location services.

Benefits

This feature provides a location service for operators.

Description

Huawei supports the IPDL-OTDOA location services. In this feature, the RNC initiates and

keeps tracing the GPS timing of cell frame measurements from the NodeBs, which are

configured with a GPS card and support the GPS timing of cell frame measurement. In

addition, the RNC initiates and keeps tracing the SFN-SFN observed time difference

measurement from LMUs deployed in the network. By taking advantage of the latest

measurement reports RNC can calculate the latest RTD (Relative Time difference) of cells

that are involved in a positioning procedure.



When RNC receives a LOCATON REPORT CONTROL message and the IPDL-OTDOA

method is selected, it requests SFN-SFN observed time difference measurement from UE, and

it calculates the UE's position after it receives the corresponding measurement report. To

assist the position calculation, RNC may request RTT measurements from NodeB and relative

Rx-Tx time difference measurements from UE.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The corresponding NodeBs should be equipped USCU card with GPS function.

Dependency on UE



None

Dependency on CN



None

1.5.3 WRFD-020803 A-GPS Based LCS

Availability



Summary

With this feature, Huawei RAN supports network-assisted GPS location services.

Benefits

This feature provides a highest accuracy location service.

Description

Huawei supports the UE-based and UE-assisted location services. To support this method,

RNC may deploy a GPS reference receiver to keep tracking the latest GPS data including



ephemeris, almanac, and DGPS data, and calculates the fresh GPS assistance data for UE

according to the latest GPS data and the UE's reference position.

When RNC receives a LOCATON REPORT CONTROL message and the A-GPS method is

selected, it sends a GPS measurement request to UE with the GPS assistance data calculated,

and calculates the position of UE when it receives the GPS measurement report. For

UE-based A-GPS method, RNC directly forwards the location estimate from UE to

MSC/SGSN.

When the cell is located in different RNCs, the location over Iur is supported.

Enhancement

RAN5.1 supports the positioning through the Iur interface.

Enhancement

None

Dependency

Dependency on RNC

If the GPS receiver is located at the RNC, the RNC must be configured with a clock board

that has a GPS module.

Dependency on NodeB

If the GPS receiver is located at the NodeB, the NodeB should be equipped with USCU card

with GPS function.

Dependency on UE



None

Dependency on CN



None

1.5.4 WRFD-020804 LCS Classified Zones

Availability





Summary

This feature enables a classified zone set on the OAM to be mapped to a specific service area.

When a classified zone of the UE is changed, the RNC sends a location report to the CN.

Benefits

The operator can provide the information and service for the subscriber actively according to

the location of the subscriber. The subscriber in movement can obtain its location information

quickly.

Description

The RNC supports mapping a classified zone set by OAM to a specific Service Area. When a

mobile enters or leaves a classified zone, the RNC will generate a location report and send the

location report to corresponding CN through Location Report procedure. In LOCATION

REPORT message, the Service Area of the UE in the Area Identity IE will be included. The

CN shall react to the LOCATION REPORT message with service vendor specific actions.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

The CN node must support this feature simultaneously.


None

1.5.5 WRFD-020805 LCS over Iur

Availability





Summary

With this feature, Huawei RAN can provide location services through the Iur interface to

extend the positioning area.

Benefits

As enhancement to location service, the positioning area is widely extended, and more

reliable and precise positioning capability is achieved.

Description

Location service over Iur is supported for CELL ID+RTT and A-GPS positioning.

CELL ID+RTT

CELL ID+RTT positioning is based on the cell position information and TOA (Time of

Arrival), for which RTT (Round Trip Time), UE RxTx time difference measurements are

needed. In case (illustrated in figure below) inter-RNC handover happened during the

positioning with CELL ID+RTT, CELL ID+RTT positioning over Iur should be

performed, including Iur interface dedicated measurement for RTT and information

exchange for neighbor RNC cell reference position (Geographical Coordinates).

Dedicated measurement over Iur for RTT

Iur dedicated measurement procedure for acquisition of RTT is illustrated in figure below.

DS-RTx

.

…

DS-NoUrgent

DS-Urgent

DS-PQ

Acquisition of RTT over Iur

SRNC

Site 2

Site 1

DRNC

MSC



Information exchange over Iur for cell reference position

To get the neighbor RNC cell reference position, information exchange procedure should be

performed, with "Information Type" IE set to "UTRAN Access Point Position", illustrated in

figure below.

A-GPS

GPS information is required by A-GPS positioning. RNC maintains the updated GPS data

from itself or neighboring RNCs. After the reference GPS receiver is configured, the GPS

data should be obtained from neighboring RNCs and the information exchange procedure

over Iub should be performed.

During the positioning, if reference cell is located in DRNC, then GPS data from DRNC will

be preferred, and information exchange over Iur for reference cell geographical position will

be triggered.

Information exchange over Iur for GPS information

Information exchange procedure for neighboring RNC’s GPS information (with "Information

Type" IE set to "GPS Information") is illustrated in figure below. To get the updated

information, periodic information reporting is applied.

DRNC SRNC

INFORMATION EXCHANGE INITIATION REQUEST

(Information Type: UTRAN Access Point Position)

INFORMATION EXCHANGE INITIATION RESPONSE

(Geographical Coordinates)

DRNC SRNC

DEDICATED MEASUREMENT INITIATION REQUEST

(Measurement Type: RTT)

DEDICATED MEASUREMENT INITIATION RESPONSE

DEDICATED MEASUREMENT REPORT

(Measurement Value: RTT)



Information exchange over Iur for reference cell geographical position

To get geographical position of reference cell, information exchange procedure is triggered on

demand, for every positioning.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


DRNC SRNC


(Information Type: UTRAN Access Point Position)


RNC 2 RNC 1


(Information Type: GPS Information)


INFORMATION REPORT



The neighboring RNC should support the information exchanging and related procedures.

Dependency on CN

None


WRFD-020801 Cell ID + RTT Function Based LCS

WRFD-020803 A-GPS Based LCS

1.5.6 WRFD-020807 Iupc Interface for LCS service

Availability


Summary

This feature supports to connect RNC and SAS (Stand-Alone SMLC) with Iupc interface

which is fully compliant with 3GPP. In this way the LCS function is working under

SAS-centric mode. This feature is usually employed when one SAS connects with many

RNCs.

Benefits

This feature offers a SAS centric Position Service mode. The merits of SAS centric mode are:

The deployed LCS algorithm and the accuracy for a certain LCS procedure are controlled by

the SAS. The operator can conveniently do the LCS service maintenance without the

technical support of RNC vendors.

In SAS-centric mode, the SAS calculate the location data. In this way, the RNC does not need

to reserve resource for LCS services.

Description

3GPP protocol offers SAS-centric mode and RNC-centric mode LCS functions.

When it works in SAS-centric mode, SAS can receive location request via RNC from CN, it

will initiate measurement request to RNC, RNC will trigger UE measurement and send the

measure result to SAS, SAS calculate the location and send the location result to CN via

RNC.

The SAS-centric mode is illustrated in the network diagram below:



Huawei supports to connect RNC and SAS with Iupc interface. The Iupc interface is fully

compliant with the 3GPP protocol. The Iupc interface is available with IP connection. All the

IP interface boards for Iu/Iur interface in RNC support Iupc with SCCP connection.

Huawei RNC supports the following functions:

SAS-centric mode: LCS algorithm and process are controlled by SAS, the RNC only offers

LCS measurement;

In SAS-centric mode, RNC supports A-GPS and CELLID+RTT LCS method;

If the operator needs to use other LCS algorithm or process, the RNC-centric mode is

recommended.

Enhancement

None

Dependency

Dependency on RNC

Only IP interface boards support this feature.

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

R

N

C

(

S

M

L

C

)

I

u

U

E

R

N

C

U

E

U

E

S

A

S

L

C

S

C

l

i

e

n

t

G

M

L

C

M

S

C

I

u

S

A

S

I

u

P

C

I

u

b

U

u

R

N

C

R

N

C

I

u

r

S

G

S

N

N

o

d

e

B

N

o

d

e

B

U

E

G

P

S

n

e

t

w

o

r

k

,

f

o

r

e

x

a

m

p

l

e

:

W

A

R

N



None


When the operator employs Cell ID+RTT algorithm, the feature WRFD-020801 Cell ID

+ RTT Function Based LCS is needed.

When the operator employs A-GPS algorithm, the feature WRFD-020803 A-GPS Based

LCS is needed.

1.6 PTT

1.6.1 WRFD-020134 Push to Talk

Availability


Summary

This feature is a part of end-to-end PTT solution. PTT needs support from the UE, RAN, CN,

and PTT server. In this feature, the RAN identifies PTT services and implements technologies

to reduce the delay of PTT services.

Benefits

This feature supports PTT solution from RAN side. By reducing the delay of PTT service, this

feature can also help to improve user satisfaction.

Description

PTT is a service option of conversing on half-duplex and point-to-point or point-to-multipoint

communication lines. A PTT connection connects instantly without ringing after a subscriber

simply presses a key. In addition, a caller can speak to a group of persons with a single button

press. Therefore, PTT is characterized by quick call establishment and convenient team

communication. The following figure shows an application of PTT in a UMTS network.



PTT services consist of start-up process and call setup process:

Start-up process

After a UE starts the PTT client, the startup process begins. The process includes the

following actions:

PTT UE registration

In this process, UE registers itself in PTT server by message exchange.

PTT UE identification

In this process, RNC will identify the PTT UE when receiving a RAB Assignment with

special QoS parameters and then keep the UE in CELL_PCH/URA_PCH state.

Call setup process

After a subscriber presses the PTT button, the call setup process begins. The network will

setup channel for the PTT service.

The delay of PTT call establishment should be short. To reduce the end-to-end delay, the

following technologies are used in the call setup process.

Always On: RNC retains the UE in CELL_PCH/URA_PCH state when there is no data

activity, that is, the UE is always on in RNC. CN also has mechanism to keep UE always on.

The Always On state allows when the UE has traffic, it need not to re-setup the RRC

connection and perform activation procedure.

P2D direct state transition: A PTT UE directly transfers its state from the

CELL_PCH/URA_PCH state to the CELL_DCH state. This is to reduce the PTT transmission

delay and improve the PTT call setup performance.

Preferred paging: The RNC prioritizes PTT paging over paging of other lower priority

applications to improve PTT call setup delay performance.

Early Reception and Transmission: RAN supports the reception of PTT user data on E-DCH

before receiving the Cell Update Confirm Response message from the PTT UE; RAN also

supports transmit message to the PTT UE over the HS-DSCH channel without waiting for the

Cell Update Confirm Response to reduce the delay.

Fast L1 synchronization: The TS 25.331 in 3GPP Release 6 introduces the "Post-verification

period" IE to indicate whether a UE uses fast L1 synchronization. This IE is included in the

Radio Bearer Reconfiguration and Cell Update Confirm messages. Fast L1 synchronization

allows PTT UEs to perform uplink and downlink L1 synchronization concurrently, reduces

the PTT call setup delay for PTT UEs in CELL_PCH/URA_PCH state at the start of the call.

Scheduling: PTT services are carried on the HSPA, NodeB schedules PTT as VoIP in the

downlink, and NodeB applies non-scheduling policy for PTT in the uplink.

Enhanced CELL-PCH: With E-PCH function, PCCH can be mapped to HS-DSCH when UE

in URA_PCH state, PCCH/DCCH/DTCH can be mapped to HS-DSCH when UE is in

CELL_PCH state, UE can directly receive data on HS-DSCH without any state transfer, so

the data transmission delay will be reduced.

With these technologies, the PTT call setup time can be reduced to about 1.1-1.3s.



Enhancement

None

Dependency


None


None




WRFD-010688 Downlink Enhanced CELL_FACH



The UE, CN should support the PTT solution.



2 MBB

2.1 HSUPA Prime Service

2.1.1 WRFD-010612 HSUPA Introduction Package

Availability



Summary

This feature package enables the system to process HSUPA services, improving the uplink

rate and system throughput. This feature package provides basic functions of HSUPA to meet

the basic requirements for operation of HSUPA services.

Benefits

HSUPA improves the performance of UMTS network by providing higher rate and higher

throughput for the uplink and higher capacity for the system.

Description

High Speed Uplink Packet Access (HSUPA) is an important feature introduced in 3GPP

Release 6. A new uplink transport channel, E-DCH, is introduced. Like what is done for

HSDPA, HSUPA improves the system capacity and throughout for uplink by maximizing

power utilization and adjusting the uplink bit rate according to channel quality.

The key functions used in HSUPA for maximizing resource utilization include 2 ms/10 ms

TTI, Hybrid Automatic Repeat Request (HARQ), and fast scheduling in the NodeB.

The basic principle behind HARQ for HSUPA is the same as that for HSDPA. After each

transmitted TTI, the NodeB informs the transmitting UE of whether the uplink data was

received correctly or not. The UE retransmits the packet if incorrect reception occurs. HSUPA

HARQ either uses chase combing where each retransmission is the exact copy of the initial

data or incremental redundancy where the retransmission only contains the redundancy bits.

The fast scheduling algorithm in the NodeB enables the system to make the scheduling

decision with the minimum latency as close to the radio interface as possible. Even though the



NodeB makes the scheduling decision, it is the UE that decides the transmitted power and the

transmit format.

In RAN6.0, only 10 ms TTI is supported and the maximum uplink rate is 1.44 Mbit/s (MAC

layer) per user. Each cell can support up to 20 HSUPA users.

Enhancement

In RAN10.0, HSUPA Introduction Package is enhanced. For details, refer to the enhancement

of the features in the package.

Dependency

Dependency on RNC

None

Dependency on NodeB

The NBBI and NULP board cannot support this feature.

Dependency on UE

The UE should have HSUPA capability.


None

Dependency on CN

None


None

2.1.2 WRFD-01061201 HSUPA UE Category Support

Availability


Summary

This feature enables Huawei NodeB to support UEs of category 1 to category 7 defined in

3GPP.

Benefits

This feature supports HSUPA services for seven categories of UE so as to provide high bit

rate services for different categories of UEs. The maximum bit rate that can be achieved by

the UE depends on the UE specification.



Description

In order to provide services of multiple bit rates, seven HSUPA UE categories are defined in

3GPP specifications. The maximum number of codes over the E-DCH supported varies with

the UE category. That is, different UE categories support different maximum bit rates.

For example, in the following table, UE of category 3 supports two SF4 codes and the

maximum data rate can be 1.44 Mbit/s.

E-DCH Category

Max. Capability Combination

E-DCH TTI Max. Data Rate (Mbit/s)

MAC Layer

10 ms TTI

MAC Layer

2 ms TTI

Air Interface

Category 1 1 x SF4 10 ms only 0.71 – 0.96

Category 2 2 x SF4 10 ms and 2 ms 1.44 1.40 1.92




Category 6 2 x SF4 + 2 xS

F2

10 ms and 2 ms 2.0 5.74 5.76

Category 7 2 x SF4 + 2 xS

F2

10 ms and 2 ms 2.0 11.50 11.52

Category 8 2 x SF4 + 2 x

SF2

2 ms 11.50 11.52


SF2

2 ms 23 23.04

RAN10.0 supports SF2 and 2 ms TTI.

UEs of category 8 support only quadrature phase-shift keying (QPSK) when DC-HSUPA is

enabled. UEs of category 9 support QPSK and 16 quadrature amplitude modulation (16QAM)

when DC-HSUPA is enabled.

Enhancement

RAN6.0 supports only SF4 and TTI of only 10 ms. Therefore, UEs of categories 2, 4, 5, and 6

can support TTI of only 10 ms in RAN6.0.

RAN10.0 supports SF2 and 2 ms TTI of UEs of categories 1 to 6.

RAN12.0 supports UEs of categories 1 to 7.

RAN14.0 supports UEs of categories 1 to 9.



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-010612 HSUPA introduction package

2.1.3 WRFD-01061209 HSUPA HARQ and Fast UL Scheduling in NodeB

Availability


Summary

The operator can set different QoS parameters such as user priority, scheduling weight, and

GBR. Based on the QoS parameters, this feature can ensure that different users enjoy

differentiated QoS experience and higher cell throughput.

Benefits

HARQ scheme improves the data transmission efficiency and reduces the delay, thereby

enhancing the users service perception.

The MAC-e scheduling algorithm improves the UL throughput of the UE and increases the

CE resource utilization in view of the limitations on the CE resources.

The combination of the MAC-e scheduling and flow control algorithms further increases the

bandwidth efficiency for each UE.

Description


Release 6. HSUPA improves the system capacity and throughput for the uplink by

maximizing power utilization and adjusting the uplink bit rate according to the channel quality.



The key functions used in HSUPA for maximizing resource utilization include 2 ms/10 ms

TTI, Hybrid Automatic Repeat Request (HARQ), and fast scheduling in the NodeB.

The basic principle of HSUPA HARQ is the same as that of HSDPA HARQ. In each TTI, the

NodeB informs the transmitting UE of whether the uplink data is received correctly or not.

The UE retransmits the packet if the uplink data is not correctly received. HSUPA HARQ

either uses chase combining where each retransmission is the exact copy of the initial data or

uses incremental redundancy where the retransmission contains the additional redundant

information for correct decoding.

The fast scheduling algorithm in the NodeB enables the system to make the scheduling

decision with the minimum latency as close to the radio interface as possible. Even though the

NodeB makes the scheduling decision, the UE shall decide the transmit power and the

transmit format.

RAN6.0 supports only 10 ms TTI and the maximum uplink rate of 1.44 Mbit/s per user (at the

MAC layer). Each cell supports up to 20 HSUPA users.

RAN10.0 supports 2 ms TTI and the maximum uplink rate of 5.74 Mbit/s per user (at the

MAC layer). Each cell supports up to 60 HSUPA users.

The users can also be categorized into three levels: gold, silver, and copper, which are mapped

from the ALLOCATION / RETENTION PRIORITY. The mapping is configurable. Moreover,

the DL/UL GBR is also a user-defined parameter for each priority level and is used for

HSUPA scheduler algorithm. This feature also improves the mechanism for ensuring the QoS

of HSUPA.

Enhancement

RAN10.0 supports 2 ms TTI.

In RAN10.0, the MAC-e scheduling algorithm considers the limitation on CE resources

during scheduling.

In RAN11.0, the MAC-e scheduling algorithm is optimized by combining the flow control

algorithm. Flow control determines each UE's primary rate and authorization indication

according to the buffer status of the UE and the congestion indication from the RNC. The

MAC-e scheduling algorithm performs scheduling based on the primary rate and

authorization indication.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None



Dependency on CN

None


WRFD-010612 HSUPA Introduction Package.

2.1.4 WRFD-01061202 HSUPA Admission Control

Availability


Summary

This feature enables HSUPA and R99 services to simultaneously access the network by using

the remaining uplink cell load and other resources, improving the utilization of system

resources and ensuring QoS.

Benefits

This feature enables HSUPA services to properly utilize system resources and enables HSUPA

and R99 services to exist in the same cell. The system resources such as the Iub transport

resources, cell load resources, and user number resources can be reserved to provide high bit

rate services for users.

Description

HSUPA service admission control enables HSUPA services to access the network with other

R99 services by using the remaining uplink cell load as well as other resources. It can fully

utilize the system resources.

In the HSUPA admission control procedure, the HSUPA users per NodeB and per cell are

determined by the configuration on the RNC side.

Besides the limitation of total HSUPA user number for best effort and streaming services, the

sum of uplink cell radio load resources for both DCH and E-DCH should also be considered.

The following two algorithms are available for uplink cell radio load:

Algorithm 1: uplink cell radio load admission decision based on Equivalent Number of

Users (ENU)

Based on the current equivalent number of users (including existing R99 and HSUPA

users) and the access request, the RNC decides whether the equivalent number of users

exceeds the threshold or not and whether to admit a new call. GBR is used to calculate

the ENU of HSUPA services.

Algorithm 2: uplink cell radio load admission decision based on Provided Bit Rate (PBR)

and power

The RNC performs a check to ensure that the aggregated traffic at the provided bit rate

exceeds the sum of all GBRs for existing traffic multiplied by a configurable threshold.

If the condition of PBR is not fulfilled, RNC further performs a check of the power

resource on the basis of Received Total Wideband Power (RTWP) and Received

Scheduled E-DCH Power Share (RSEPS) measurement.



Both Iub resources and NodeB credit resources should be checked during the admission

control to enable the HSUPA services and other R99 services to be admitted under a certain

guaranteed QoS.

During the admission control, the RNC decides whether the service is mapped to E-DCH or

not by setting service rate thresholds. The thresholds include a UL streaming service HSUPA

threshold and a UL BE service HSUPA threshold. Only when the requested bit rate of the

incoming call is higher than the threshold can the call be mapped on HSUPA.

Queuing and pre-emption are considered for HSUPA if admission control fails due to

limitation of user number or equivalent user number.

Enhancement

In RAN10.0, Received Scheduled E-DCH Power Share (RSEPS) measurement is supported,

and algorithm 2 is available.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.1.5 WRFD-01061203 HSUPA Power Control

Availability


Summary

With the introduction of new physical channels, this feature improves the power efficiency of

the system, reduce UL and DL interference, and increase the system capacity.



Benefits

This feature enables the system to provide reliable quality for HSUPA-related channels. It

increases system capacity and reduces uplink interference and downlink power output.

Description

When HSUPA service is introduced, the E-DCH transport channel is used. Five new physical

channels, namely, E-DPDCH, E-DPCCH, E-HICH, E-RGCH and E-AGCH are used.

E-DPDCH is used to carry the E-DCH transport channel, and E-DPCCH is used to transmit

control information related to the E-DCH.

An E-DPCCH power offset related to the DPCCH is used to perform the power control on

E-DPCCH. The power of DPCCH is adjusted by inner loop power control, and the E-DPCCH

power is also controlled by the inner loop power control. The power offset can be set at the

RNC. The scheme of inner loop power control is introduced in WRFD-020504.

For the E-DPDCH, another power offset related to DPCCH is used and the same power

control method as that of the E-DPCCH is used. The power offset is also configurable at the

RNC.

For the E-HICH and E-RGCH, there are two methods to control the transmit power: constant

transmit power and DPCH-based dynamic power control. When a constant transmit power is

used, the transmit power of E-RGCH and E-HICH is given by a power offset related to the

transmit power on the P-CPICH. When DPCH-based dynamic power control is used, three

different power offsets related to the DPCCH are used.

For the E-AGCH, the methods of constant transmit power and DPCH-based dynamic power

control can also be used.

For the E-DCH, the initial power is controlled by open loop power control.

On the uplink, outer loop power control for the E-DCH is also used to control link quality.

E-DCH SIR target is adjusted by the E-DCH OLPC scheme, which is the same as that of the

DCH. The DCH OLPC scheme is introduced in WRFD-020503.

In addition, the reference E-TFCI power offset and HARQ power offset can also be adjusted

by the E-DCH OLPC scheme through a reconfiguration procedure.

Enhancement

In RAN 6.0, the E-DCH OLPC algorithm is performed based on NHR and PROB. NHR is

defined as the number of HARQ retransmissions, and PROB is defined as the probability of

receiving packets whose retransmission times are more than the NHR target.

In RAN10.0, the E-DCH OLPC algorithm based on residual BLER instead of PROB is

provided. It is applicable to zero retransmission and delay-sensitive services.

In RAN10.0, the E-DCH supports dynamic power control based on CQI and HS-SCCH. In

addition, the E-DCH can also use the constant transmit power and DPCH-based dynamic

power control in RAN6.0.

Dependency

Dependency on RNC



None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.1.6 WRFD-01061204 HSUPA Mobility Management

Availability


Summary

This feature is related to HSUPA mobility management. This feature can ensure that HSUPA

services are continuous.

Benefits

This feature reduces user data interruption and improves perceived data transfer quality when

UE moves with HSUPA services. It also provides a method to ensure the service continuity

between R99 cells and HSUPA cells.

Description

HSUPA mobility management function enables the handover for an HSUPA user to an R99

cell or another HSUPA cell when HSUPA user is moving. The feature also enables the

HSUPA user to change a cell with less chance of service interruption.

The E-DCH can perform soft/softer handover on the uplink while the HS-DSCH cannot.

Soft handover of the E-DCH is the HSUPA user mobility solution. The handover of the

E-DCH and DCH are very similar. Both are based on the measurement report of the UE and

are controlled by the network. If the downlink channel is DCH, soft handover is also used on

the downlink as stipulated in Release 99.

If the UE has both HSDPA and HSUPA, the HS-DSCH cell change procedure is used for the

downlink. As the uplink and downlink are independent, the measurement and the handover

decision are made separately.



Compared with DCH, the maximum E-DCH active set size is 4, but the maximum DCH

active set size is 6. Therefore, the Active Set (AS) of E-DCH is independent of the AS of

DCH.

UL channel type selection is determined by whether the best cell in DCH AS can support

HSUPA or not.

For intra-frequency cells, soft/softer handover occurs when the HSUPA connection is moved

from one HSUPA cell to another HSUPA cell. The target HSUPA cell could be added into

Active Set triggered by 1a, 1c, and 1d event report, or removed from Active Set trigged by 1b

event report.

The active set of E-DCH is independent of the AS of DCH. 1J event report is supported. A

non-active E-DCH but active DCH primary CPICH becomes better than an active E-DCH

primary CPICH. This non-active E-DCH cell is added into the AS of E-DCH.

For inter-frequency neighboring cells, inter-frequency hard handover between HSUPA cells is

triggered. The service is changed to E-DCH of target cell. The hard handover depends on the

UE measurement.

Handover from an HSUPA Cell to an R99 Cell

When the UE is moving from an HSUPA cell to an R99 cell (intra-frequency) and 1a

event is triggered, the HSUPA connection between UE and HSUPA cell is not changed

unless this R99 cell becomes the best cell. Then, this R99 cell is added into the active set

of DCH because the active set of E-DCH is independent of the active set of DCH.

If the neighboring cell of HSUPA cell is an inter-frequency cell and does not support

HSUPA, hard handover, together with a channel switch from E-DCH to DCH, is

performed. The HSUPA handover decision is based on the measurement report of the

pilot channels of neighboring cells.

Handover from an R99 Cell to an HSUPA Cell

When an HSUPA-capable UE accesses an R99 cell, only the DCH channel is used to

carry the services. When the UE moves from an R99 cell to an HSUPA cell:

If the R99 cell and the HSDPA cell are intra-frequency cells, this HSUPA cell is added to

the AS of E-DCH since the active set of E-DCH is independent of the AS of DCH.

If the R99 cell and the HSDPA cell are inter-frequency cells, inter-frequency hard

handover is triggered when the quality of the signals of HSUPA cell becomes better. The

UE changes from the R99 cell to the HSUPA cell and the PS services are switched from

the DCH to the E-DCH.

Handover from an HSUPA Cell to a 2G Cell

The handover from an HSUPA cell to a 2G cell is triggered by normal inter-RAT

handover. See features of inter-RAT handover for detailed information.

Inter-RNC Handover for HSUPA

For cell change between RNCs, inter-RNC soft handover over Iur for HSUPA is

available.

Compressed mode measurement for HSUPA

Compressed mode measurement is available for E-DCH with TTI of 10 ms or 2ms in the

case of inter-frequency and inter-RAT handover.



Enhancement

In RAN10.0, the AS of E-DCH is independent of the AS of DCH and 1J event report is

supported.

The 2ms TTI of the E-DCH can be measured in compressed mode.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.1.7 WRFD-01061208 HSUPA DCCC

Availability


Summary

HSUPA DCCC can dynamically adjust the minimum SF code of HSUPA based on the user

throughput and flexibly switch the UE state based on the user traffic, improving the utilization

of CE resources and system efficiency.

Benefits

This feature improves the utilization of CE resources and make it possible for the UE to enjoy

the high-speed service. When the UE is in inactive state, this feature enables the UE to be

handed over to the CELL_FACH to save system resources.

Description

HSUPA DCCC is comprised of rate re-allocation and UE state transition functions:

Rate re-allocation



Rate re-allocation of HSUPA DCCC is based on traffic volume. According to traffic

volume measurement report received from the RNC, rate re-allocation increases or

decreases the uplink data rate for the best effort (BE) services (that is, interactive and

background services) to a proper value to improve the CE resource utilization.

UE state transition

With the introduction of HSUPA, a new RRC state of CELL_DCH (E-DCH) is provided,

which means that the UE is in the CELL_DCH state with services mapping on the

E-DCH channel.

Channel Switching Between CELL_DCH (E-DCH) and CELL_FACH

If the E-DCH is carrying BE service or streaming service and there is no data to be sent for a

long time, the transition from CELL_DCH (E-DCH) to CELL_FACH is triggered. Actually,

this feature is supported in the same way as the state transition from CELL_DCH to

CELL_FACH.

The switch from CELL_FACH to CELL_DCH (E-DCH) is triggered by a request for higher

bit rates on uplink.

Channel Switching Between CELL_DCH (E-DCH) and CELL_DCH

The channel switching between e-DCH and DCH is mainly triggered by mobility

management. The transition from CELL_DCH to CELL_DCH (E-DCH) can be triggered by

periodical retries and the traffic volume.

The mobility trigger is described in WRFD-01061204 HSUPA mobility management feature.

Traffic volume measurement report indicates that a higher bit service needs to be transferred.

The UE in CELL_FACH is transferred to CELL_DCH (E-DCH) if it is in a HSUPA capable

cell and the UE has HSUPA capabilities. This feature enables the UE to be served with high

speed service.

If a service of the HSUPA-capable UE is set up on the DCH due to some reasons, for example,

admission to E-DCH fails, the periodical retry mechanism takes action, allowing the UE state

to be transferred to CELL_DCH (E-DCH). The retry time is configurable.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None



Dependency on CN

None



Professinal Serice

Recommend to deploy this feature with UMTS SmartPhone Solution Service

2.1.8 WRFD-01061207 HSUPA Transport Resource Management

Availability


Summary

This feature covers the mapping and allocation of differentiated transmission resources for

different HSUPA users and the admission control and congestion control of transmission

resources. These algorithms implement QoS classification and differentiation in end-to-end,

seamless mapping. This feature can greatly improve the utilization of Iub resources and

ensure QoS and differentiation.

Benefits

Differentiated service is implemented by different traffic being carried on different paths, and

optimizes the QoS and network performance. This feature improves transport resource usage

efficiency and saves OPEX on Iub transmission.

Description

With HSUPA feature introduced, the throughput over Iub interface may be increased and

varied greatly. This feature is used to optimize the usage of Iub transport resources for the

HSUPA services. The following features are concerned.

Differentiated services mapping

Transport resource load control

I. Differentiated services mapping

The PS streaming and best effort services can be set up on HSUPA. Different services have

different QoS requirements, and the Iub transport will be IP and/or ATM. Therefore, the traffic

categories such as ATMHURT, ATMHUNRT, IPHURT, and IPHUNRT are added accordingly.

Traffic Categories

Traffic Type

ATMHURT HSUPA streaming services

ATMHUNRT HSUPA interactive services and HSUPA background services



IPHURT HSUPA streaming services

IPHUNRT HSUPA interactive services and HSDPA background services

Moreover, differentiated transmission must be applied according to the QoS requirements of

services. The following table describes the mapping relationship.

AAL2 Path Type Service Type of ATM Traffic

ATMHURT, HSPA CBR, RTVBR

ATMHUNRT HSPA NRTVBR, UBR

The mapping between traffic categories and path types is configurable. The following table

provides an example on an ATM-based network.

Traffic Category Primary Path Type Secondary Path Type

HSUPA streaming ATMHURT None

HSUPA interactive ATMHUNRT None

HSUPA background ATMHUNRT None

The secondary path type configuration can be used as mutual backup of transmission

resources especially in ATM and IP hybrid transmission solutions, that is, when IP

transmission fails, the service can be mapped to the secondary ATM path to keep the services

available, or vice verse. The following table describes such configurations.

Traffic Category Primary Path Type Secondary Path Type

HSUPA streaming ATMHURT IPHURT

HSUPA interactive ATMHUNRT IPHURT

HSUPA background ATMHUNRT IPHURT

By using this feature, different services are carried on corresponding paths, and the

differentiated service is implemented.

II. Transmission resource load control

Transmission resource load control refers to admission control and congestion control.

For the admission control, Guaranteed Bit Rate (GBR) is considered for HSUPA service

admission, and it belongs to the optional feature WRFD-01061202 HSUPA Admission

Control.



For the congestion control, the load reshuffling strategy is applied in scenarios such as

inter-RAT handover. This feature belongs to the optional feature WRFD-020306 Inter-RAT

Handover Based on Load.

Enhancement

In RAN6.1, each traffic class mapped onto transmission resource can be configured

separately.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



Optional feature WRFD-050402 IP Transmission (Iub interface), WRFD-050403 Hybrid

IP Transmission, and WRFD-050404 ATM/IP Dual Stack NodeB should be required

when the transmission resource management feature is applied for IP transmission

resources in those scenarios.

2.1.9 WRFD-01061206 Interactive and Background Traffic Class on HSUPA

Availability


Summary

This feature enables interactive and background services to be mapped to the E-DCH to

obtain a higher service rate and enhance user experience.

Benefits

This feature enables the system to support a higher speed RAB of the PS interactive and

background services.



Description

This feature enables the best effort (interactive and background) services to be mapped onto

the E-DCH if a UE is HSUPA capable. The system sets a switch to enable or disable the

feature that BE traffic is mapped on to E-DCH. A service rate threshold is also set so that the

requested service can be mapped on E-DCH only when the requested service bit rate is higher

than the threshold. Otherwise, the requested service is mapped onto the DCH. The service rate

threshold is configurable by the operator.

When the best effort service is carried on the E-DCH, the maximum uplink bit rate is 5.74

Mbit/s (MAC layer).

When a UE has BE service on E-DCH, it can use another DCH CS RAB or another DCH PS

RAB simultaneously. If the UE capability is allowed, the UE can be served by two HSUPA

RABs.

GBR of HSUPA BE traffic is set and used to estimate whether the maximum available

resource for HSUPA can satisfy the requirements of streaming services and BE services in

admission control. The GBR of HSUPA BE traffic is configurable by operator.

The HSUPA schedule algorithm also considers the configured GBR information of HSUPA

BE traffic.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.1.10 WRFD-01061210 HSUPA 1.44Mbit/s per User

Availability




Summary

This feature enables the HSUPA rate per user to reach a maximum of 1.44 Mbit/s.

Benefits

This feature provides a higher peak bit rate and enhances user experience.

Description

High Speed Uplink Packet Access (HSUPA) is an important feature of 3GPP Release 6 that

provides high speed service for uplink. With this feature, the UE with interactive or

background services on the E-DCH can reach the peak bit rate of 1.44 Mbit/s (MAC Layer).

Therefore, user experience is greatly enhanced.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should have the capability of HSDPA Category 3 (or later).


None

Dependency on CN

The CN supports an uplink rate of at least 1.44 Mbit/s.



2.1.11 WRFD-01061211 20 HSUPA Users per Cell

Availability


Summary

This feature enables a single HSUPA cell to simultaneously support 20 HSUPA users. If the

number of HSUPA users exceeds 20, the DCH is attempted for service provisioning.



Benefits

This feature provides HSUPA services at a higher peak bit rate for up to 20 users per cell.

Description

Up to 20 HSUPA users can be admitted to a HSUPA cell.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.1.12 WRFD-01061212 HSUPA Iub Flow Control in Case of Iub Congestion

Availability



Summary

This feature enables the monitoring of Iub transmission resources to dynamically adjust the

uplink Uu throughput, greatly improving the resource utilization.

Benefits

This feature improves the transport resource usage efficiency greatly and reduce the throughput fluctuation in the case of the Iub congestion.



Description

The UL Uu throughput is controlled by the scheduler according to the UL load resource and

the Iub bandwidth resource simultaneously. The schedule algorithm estimates the influence on

the load resource and the Iub resource of the change of the serving grant (SG) and decides

whether to assign the absolute grant (AG) or relative grant (RG) to UEs.

The flow control algorithm maintains the Iub available bandwidth resource on the following

principles:

1. The Iub buffer occupancy status:

If the Iub buffer occupancy ratio increases, the available bandwidth may be reduced by a

step.

If the Iub buffer occupancy ratio decreases, the available bandwidth may be increased by

a step.

2. The transmission network congestion status (the NodeB detects it according to the

transmission network layer (TNL)) indicator is indicated by the RNC:

If the transmission network is congested, the available bandwidth may be reduced by a

step.

If the transmission network is not-congested, the available bandwidth may be increased

by a step.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





2.1.13 WRFD-010614 HSUPA Phase 2

Availability



Summary

HSUPA Phase2 is an enhanced HSUPA feature that supports 2ms transmission time interval

(TTI).

Compared with 10ms TTI provided in the HSUPA introduction package, this feature can

provide a higher uplink rate and lower delay. This feature provides a series of enhanced

HSUPA functions to meet the commercial requirements of HSUPA services.

Benefits

HSUPA improves the performance of UMTS network by providing higher rate and higher

throughput for the uplink and higher capacity for the system.

Description


Release 6.

In RAN6.0, only 10 ms TTI is supported and the maximum uplink rate is1.44 Mbit/s (MAC

layer) /1.92 Mbit/s (physical layer) per user. Each cell supports up to 20 HSUPA users.

In RAN10.0, the 2 ms TTI is supported, the maximum uplink rate is 5.74 Mbit/s (MAC

layer)/5.76 Mbit/s (physical layer).

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The BTS3812E, BTS3812A and BTS3812AE must be configured with the EBBI, EBOI,

EDLP, or EDLPd board.

The BBU3806 must be configured with the EBBC or EBBCd board.

The BBU3900 must be configured with the WBBPb, WBBPd, or WBBPf board.

Dependency on UE

None




None

Dependency on CN

None



The software dependency is described in each sub functions.

2.1.14 WRFD-01061401 HSUPA E-AGCH Power Control (Based on CQI or HS-SCCH)

Availability


Summary

This feature enables the UE to report the CQI and HS-SCCH as a reference, effectively

reducing the power consumption of the E-AGCH.

Benefits

E-AGCH power control based on CQI or HS-SCCH makes it more efficient to adjust the

power of E-AGCH under the condition that HSDPA co-exists with HSUPA.

By using E-AGCH power control based on CQI or HS-SCCH, the following advantages are

introduced:

Less power consumption of E-AGCH

Flexible power control for E-AGCH

Description

In 3GPP specifications, the serving cell of HSUPA should be the same with that of HSDPA.

Meanwhile, E-AGCH belongs to the serving cell of HSUPA, so the power control of E-

AGCH can take advantage of the information of HSDPA, such as CQI and HS-SCCH, which

can reflect the quality of transmission in the serving cell.

The power control of E-AGCH is enhanced in HSUPA phase II when HSUPA coexists with

HSDPA. At this time, CQI or HS-SCCH information is used to adjust the power offset of

E-AGCH. Consequently, it can spare more power for the downlink transmission.

CQI reflects the channel quality of the serving cell. When the CQI information is

available, it can be used to adjust the power offset of E-AGCH.

The demodulation error probability of HS-SCCH can be adjusted by modification of the

transmission power of HS-SCCH. Since the demodulation requirements for E- AGCH

are similar to those for HS-SCCH, power offset of E-AGCH can be modified based on

that of HS-SCCH.



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None




2.1.15 WRFD-01061402 Enhanced Fast UL Scheduling

Availability


Summary

This feature enables comprehensive considerations of system resources and QoS parameters

preset for different users to ensure accurate differentiated user experience and improve cell

throughput.

Benefits

Enhanced UL scheduling makes it more efficient to accommodate different scenarios, such as

hub NodeB, IP convergence, and RAN sharing.

This feature enables more efficient usage of uplink resource by maximizing the uplink

throughput of the cell under the condition that the QoS requirements of all UEs are met.

This feature provides better fairness among users. If there are users with the same priority, the

uplink resources allocated to them are similar.

This feature provides flexible priorities among users. If a UE has a higher priority, it can

obtain more uplink resources.



Description

In HSUPA phase II, the 2 ms TTI is supported. The UL scheduling is enhanced based on the

shorter TTI.

The Proportional Fair (PF) scheduling algorithm is enhanced in HSUPA phase II. PF is based

on uplink load factor and takes advantage of downlink control channels (E-AGCH/E-RGCH)

to influence the E-TFCI that the UE may use. Consequently, it can tightly control the uplink

interference.

When the scheduling period arrives, the PF scheduling algorithm performs the following

operations:

Queue the HSUPA users based on the scheduling priority indicator, GBR, and data rate.

Consider the CE resources and Iub transport resources.

Assign absolute grant according to the Scheduling Information (SI) sent by the UE,

which can control the maximum rate the UE may use.

Assign relative grant according to the happy bit on the E-DPCCH.

Shorter TTI means more efficient schedule process.

High Speed Uplink Packet Access (HSUPA) is an important feature of 3GPP Release 6 that

provides high speed service for the uplink. In order to provide multiple bit rate services, six

UE categories are defined in 3GPP. Different UE categories support different maximum codes

for E-DCH, which means that different maximum bit rates can be achieved.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



WRFD-010638 Dynamic CE Resource Management



2.1.16 WRFD-01061403 HSUPA 2ms TTI

Availability


Summary

The 2ms TTI of HSUPA enables a single user to obtain a higher UL throughput and shorter

delay.

Benefits

By using a shorter TTI on the Uu interface, HSUPA has the following advantages:

Faster data scheduling

Higher UL peak data rate

Lower latency

Description

There are two Transmission Time Intervals (TTIs) defined in the 3GPP protocol for HSUPA.

10 ms TTI is mandatory for all HSUPA capable UEs while 2 ms TTI is optional. Switching

between the two TTIs is performed by UTRAN through L3 signaling.

In RAN10.0, 2 ms TTI is supported. Therefore, all UEs of the six categories can be supported.

E-DCH Category

Max. Capability Combination

E-DCH TTI Max. Data Rate (Mbit/s)

MAC Layer

10 ms TTI

MAC Layer

2 ms TTI

Air Interface







SF2

10 ms and 2 ms 2.0 5.74 5.76


SF2

10 ms and 2 ms 2.0 11.498 11.52

Compressed mode measurement is available for E-DCH 2 ms in the case of inter-frequency

and inter-RAT handover.



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The BTS3812E, BTS3812A and BTS3812AE must be configured with EBBI, EBOI,

EDLP, or EDLPd board.



Dependency on UE

The UE should have the capability of HSUPA Category 2, 4, 6, 7, 8, 9


None

Dependency on CN

None



2.1.17 WRFD-01061404 HSUPA 2ms/10ms TTI Handover

Availability


Summary

As 2 ms TTI capable cells and 10 ms TTI capable cells coexist in the network and different

TTIs are required for different throughputs, the handover between 2 ms TTI and 10 ms TTI is

necessary. This feature can ensure that HSUPA users smoothly move between different cells

and resources are allocated for throughput requirements.

Benefits

This feature supports mobility between 2 ms TTI capable cell and non-2 ms-scheduling

capable cell.

This feature maximizes the possibility for 2 ms TTI capable UE to get the best performance

by using 2 ms scheduling feature.



Description

Both 10 ms and 2 ms TTI are defined in the 3GPP protocol for HSUPA. In the HSUPA

network, when UE moves between cells that support HSUPA 2 ms TTI and those does not, the

switching schedule between 10 ms and 2 ms TTIs is needed. Such switching generally occurs

in the handover scenario as described below.

When the soft handover happens to an UE using HSUPA 2 ms TTI and the target cell

does not support 2 ms TTI, the RNC first reconfigures the UE to 10 ms TTI and then

performs the handover procedure.

When the hard handover happens to an UE using HSUPA 2 ms TTI and the target cell

does not support 2 ms TTI, the RNC performs the handover and reconfigures the UE to

10 ms TTI at the same time.

When all the cells in active set using HSUPA 10 ms TTI support 2 ms TTI, a periodical

retry to reconfigure to 2 ms TTI is implemented to make it possible to get better

performance. On the other hand, a configurable bit rate threshold is triggered by such

retry procedure, that is, when the RAB maximum bit rate assigned is lower than the

threshold, it is unnecessary to use 2 ms TTI.

The RNC gets the 2 ms TTI capability from the audit message sent by the NodeB. For the

neighboring cells that are not controlled by the RNC, such capability can be configured by the

operator.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The BTS3812E, BTS3812A and BTS3812AE must be configured with EBBI, EBOI,

EULP, or EULPd board.



Dependency on UE

None


None

Dependency on CN

None


WRFD-010614 HSUPA Phase 2



2.1.18 WRFD-01061405 HSUPA 5.74Mbit/s per User

Availability


Summary

This feature enables the HSUPA rate per user at MAC layer to reach a maximum of 5.74

Mbit/s. The rate is a peak rate defined in 3GPP specifications.

Benefits

This feature greatly enhances user experience.

Description

Based on the 2 ms TTI and enhanced fast UL schedule, with 2 SF4 and 2 SF2 codes

combination, the UE can reach the peak rate of 5.74 Mbit/s at MAC layer.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The BTS3812E, BTS3812A, and BTS3812AE must be configured with the EULP, EBBI,

EBOI, or EULPd board.



Dependency on UE

The UE should have the capability of HSDPA Category 6, 7, 8, or 9.


None

Dependency on CN

The CN supports an uplink rate of at least 5.74 Mbit/s.





2.1.19 WRFD-010632 Streaming Traffic Class on HSUPA

Availability



Summary

This feature enables the streaming service to be mapped onto the E-DCH, improving the

utilization of cell resources.

Benefits

This feature enables the system to support higher speed RAB of the PS streaming traffic.

Description

This feature enables the streaming service to be mapped onto the E-DCH if a UE is HSUPA

capable. The system sets a switch to enable or disable the feature by which the streaming

traffic can be mapped onto the E-DCH. And a service rate threshold is also need to be set so

that only when the requested service bit rate is higher than the threshold, the request service

can be mapped onto the E-DCH. Otherwise, the requested service will be mapped onto the

DCH. The service rate threshold can be set by the operators too.

When the streaming service is carried on the E-DCH, the maximum uplink bit rate can reach

up to 384 kbit/s.

The UE with the streaming service on the E-DCH can use another CS RAB or another PS

RAB simultaneously. One HSUPA BE RAB and one HSUPA streaming RAB can be served

on one UE simultaneously if the capability of the UE is allowed.

The GBR of the streaming traffic is used to estimate whether the maximum available resource

for the HSUPA can satisfy the requirement of the streaming service in the admission control.

The HSUPA schedule algorithm also considers the GBR information of the streaming traffic

so that in all HSUPA streaming services that the bit rate is not less than the GBR can be

guaranteed.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



None


None

Dependency on CN

None



2.1.20 WRFD-010635 HSUPA over Iur

Availability



Summary

This feature enables HSUPA services to be carried on the Iur interface and provides

continuous HSUPA services for UEs moving between RNCs.

Benefits

The HSUPA over the Iur provides continuous HSUPA services for mobile users moving

between the RNCs. It enlarges the range of the HSUPA services to the RNCs which have the

Iur connections with a certain RNC.

Description

The HSUPA over the Iur is the scenario that the DRNC cell is in the HSUPA E-DCH active

state. The feature comprises the HSUPA service management over the Iur, the HSUPA

mobility management over the Iur, and so on. The HSUPA capability of the DRNC cell is

configurable.

HSUPA service management over Iur

The HSUPA service management over the Iur includes the HSUPA service setup,

modification, release, and the dynamic channel configuration control (DCCC).

When the UE is in CELL_DCH state and the DRNC cell is in the E-DCH active state or

the UE is in CELL_FACH state and the camps in the DRNC cell, the HSUPA service can

be set up, modified and released over the Iur.

The HSUPA DCCC over the Iur is similar to the WRFD-01061208 HSUPA DCCC and

the difference is that some of the cells are in the DRNC.

HSUPA mobility management over Iur

The HSUPA mobility management over the Iur includes the soft handover, hard

handover, cell update (because of radio link failure), and serving cell change.



The process is similar to the corresponding mobility management described in the

WRFD-01061204 HSUPA Mobility Management and the difference is that the cells

change between the RNCs.

HSUPA static relocation

If the HSUPA service is over the Iur and the radio links are provided only by the target

RNC, the static relocation can be triggered by the Iur congestion.

HSUPA service pre-emption in DRNC

When the new HSUPA service is not admitted to access the network, the CRNC may

trigger the pre-emption of other HSUPA services with lower priorities. If the CRNC is

the DRNC, it will send the radio link pre-emption required indication to the SRNC and

the SRNC will release the HSUPA services indicated in the radio link pre-emption

required indication.

The other functions of this feature are the HSUPA E-DCH power offset adjustment over

the Iur, and so on. The process is similar to that on the Iub interface.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


The neighboring RNC must support HSUPA over Iur too.

Dependency on CN

None



2.1.21 WRFD-010640 Uplink Macro Diversity Intelligent Receiving

Availability




Summary

Based on the resource occupation, this feature enables the dynamic selection of different

macro diversity combination modes for high-speed non-real-time services (UL) and

low-speed real-time services (SRB and VoIP). This feature can save Iub/Iur transmission

resources and CE resources, affect the pre-emption policy, and improve the investment return.

Benefits

This feature can greatly save CE resources and transmission resources, improve the resource

utilization, enhance the network performance, and reduce the TCO.

Description

The WCDMA system supports soft handover to control the power of the UE in the overlapped

handover area and provides the MDC gain. The uplink receiving and processing resources and

transmission resources, however, are consumed. With the introduction of HSPA+ in 3GPP R7,

resources are further consumed. This feature can be used to preempt the resources on

non-serving links for serving links to greatly improve the resource utilization and reduce

CAPEX and OPEX.

If some users in the NodeB require a higher rate, and Iub transmission resources or CE

demodulation resources are insufficient, the NodeB can dynamically preempt the Iub

transmission resources or CE demodulation resources occupied by non-serving links and then

allocate them to the serving links requiring a higher rate. This feature can increase the total

effective throughput and improve the utilization of Iub transmission resources or CE

demodulation resources.

To ensure normal uplink signaling transmission and power control, the NodeB dynamically

preempts the CE demodulation resources and Iub transmission resources on only the data

channels instead of those required by the uplink control channels on non-serving links.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None




WRFD-01061212 HSUPA Iub Flow Control in Case of Iub Congestion


2.2 HSUPA Performance Improvement

2.2.1 WRFD-010690 TTI Switch for BE Services Based on Coverage

Availability

This feature is available since RAN12.0.

Summary

With this feature, the transmit power and the actual throughput of the HSUPA-based BE

services are monitored. When the transmit power is insufficient, the Transmission Time

Interval (TTI) is switched from 2 ms to 10 ms to reduce the requirements on transmit power.

This ensures continuous network coverage.

Benefits

Generally, the TTI of the HSUPA-based BE services that require high transmission rate is set

to 2 ms to ensure a high transmission rate in areas with good coverage; however, call drops

are likely to occur at the edge of the cell. With this feature, the call drop rate of these services

is greatly reduced in the areas with weak coverage.

Description

When the TTI is set to 2ms, the peak rate supported by a UE is higher than that when the TTI

is set to 10 ms. Therefore, the TTI of the HSUPA-based BE services that require high

transmission rate is generally set to 2 ms.

When the UE is in an area with weak coverage, the transmit power of the HSUPA-based BE

service with a 2 ms TTI is likely to be insufficient. This will increase the call drop rate. The

reason for this is analyzed as follows: Data is sent in the RLC PDU form. If the size of one

RLC PDU is 336 bits, for example, then the minimum transmission rates in the case of 10 ms

and 2 ms TTIs are 32 kbit/s and 168 kbit/s respectively. Obviously, the minimum transmission

rate in the case of a 2 ms TTI is greater than that in the case of a 10 ms TTI. Accordingly, the

minimum transmit power required in the case of a 2 ms TTI is greater than that in the case of

a 10 ms TTI. As a result, when the TTI is set to 2 ms, call drop is likely to occur due to

insufficient transmit power in the area with weak coverage. In this case, the TTI should be

switched to 10 ms to reduce the required transmission power, ensuring the network coverage.

After this feature is enabled, the RNC monitors the uplink transmit power and the

transmission rate of the HSUPA-based BE services with 2 ms TTI. When the uplink

transmit-power is insufficient, the RNC switches the TTI to 10 ms to reduce the required

transmit power, avoiding call drops.



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should support HSUPA 2ms TTI


None

Dependency on CN

None



Professional Service

Recommend to deploy this feature with UMTS Uplink Capacity Improvement Service

2.2.2 WRFD-010641 HSUPA Adaptive Transmission

Availability


Summary

With comprehensive considerations of cell uplink power load, CE resources, and limited

uplink coverage, this feature enables the adaptive adjustment of the number of target uplink

retransmissions to improve the throughput per user and cell uplink capacity.

Benefits In a limited uplink coverage scenario, a user’s uplink cell edge throughput can be

increased, in order to enhance user experience. According to simulation results, single

user throughput has been show to increase by 15%-60%.

In a scenario where the cell uplink power load is limited, increasing the retransmission

number can improve cell throughput and cell uplink capacity. Simulation results have

shown an increase of 53% in cell throughput under multi-user scenarios.



Description

HARQ retransmission number is used as the target value of HSUPA uplink outer loop power

control. When UE signal quality is good and uplink transmission power is not limited, a small

retransmission can improve single user throughput. However, when capacity is limited and

cell uplink power becomes a bottleneck, increasing retransmission number can improve cell

throughput. Increasing retransmission number can also boost user cell edge throughput, where

UE uplink power is limited. Therefore there’s a need to realize the adaptive adjustment of

retransmission number.

This feature is only effective in BE traffic. If a user, only has BE traffic (with the exception of

SRB) on E-DCH, then dynamic adjustment of the target retransmission number is allowed.

Adjusting the users target retransmission number to a relatively smaller value is permitted

when the uplink power of all the cells belonging to the serving RLS is smaller than a certain

threshold and the UE uplink power is not limited and/or uplink CE’s are limited. When the

uplink power of any cell belonging to the serving RLS experiences congestion or UE’s uplink

power is limited, then setting the users target retransmission number to a relatively larger

value is permitted, as long as the uplink CE resources are sufficient.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The BTS3812E and BTS3812AE must be configured with the EBBI, EBOI, EULP or

EULPd board.



Dependency on UE

None


None

Dependency on CN

None







2.2.3 WRFD-010638 Dynamic CE Resource Management

Availability


Summary

To improve the efficiency of CE resources, Huawei RAN introduces the dynamic CE resource

management feature. Based on the GBR and actual rate, this feature enables the fast

adjustment of CE allocation. When CE resources are preempted, this feature enables the

proper allocation of CE resources to ensure the pre-emption fairness.

Benefits

The dynamic CE allocation can call back the CE resources in time when the user’s throughput

decreases, saving the CE resources.

Description

A channel element (CE) is defined as the baseband resources required in the NodeB to

provide capacity for 12.2 k AMR voice, including 3.4 k DCCH. The HSUPA shares the CE

resource with the R99 services.

The HSUPA aims at improving the uplink in terms of reducing delays, increasing data rates

and increasing the capacity, but it requires a large CE consumption.

If there is no dynamic CE resource management, the RNC will assign a maximum set of

E-DPDCHs for every user when the radio link is set up or reconfigured, which is the

maximum data rate that the UE supports.

Accordingly the NodeB will allocate the CE resources according to the maximum set of

E-DPDCHs, even if the user’s actual traffic is very low. So the utility of the CE resource is

inefficient.

Huawei adopts the dynamic CE resource management to save the CE resources. Each TTI,

NodeB can call back the CE resources if the user’s throughput decreases, allocate the CE

resources during the radio link setup or reconfiguration, allocate the CE resources for the

AG(Absolute Grant) ‘UP’ users, and preempt the CE resources for the RG(Relative

Grant)‘UP’ users. The dynamic CE resource management process is described in the

following figure.

For example, one user has the maximum bit rate at1.45 Mbit/s, but the actual throughput is

always changed. With the dynamic CE resource management, the CE consumption is

dynamically changed with the bit rates (blue line), not allocated according to the maximum

set of the E-DPDCHs (red line).

0

500

1000

1500

2000

0 20 40 60 80 100 120 140

Time (s)

Throughput (kbps)

Throughput (kbps)



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.2.4 WRFD-010692 HSUPA FDE

Availability


Summary

HSUPA frequency domain equalization (HSUPA FDE) is performed to equalize the spectrum

in the frequency domain on the HSUPA E-DPDCH through the UL receiver of the NodeB to

suppress the inter-path interference on the E-DPDCH. Therefore, the SNR on the E-DPDCH

and the UL capacity of the HSUPA network are increased. The rate of HSUPA services

initiated by UEs of categories 6 and 7 is also increased in the multi-path environment.

Benefits

This feature can suppress UL inter-path interference on HSUPA users and help HSUPA users

get higher peak rate. In the case of multi-path, the higher the rate is, the larger the inter-path

interference and the harder the rate increasing. HSUPA FDE can suppress the inter-path

interference and help the real HSUPA peak rate closer to the theoretic value. HSUPA FDE can

increase the real peak rate up to 20%.



Description

HSUPA is an important feature as defined in 3GPP Release 6 to provide UL high-rate services.

Six categories of UEs that support services at several rates are defined in the 3GPP

specifications. UE category 7, which supports the 16QAM mode and a UL peak rate of up to

11.5 Mbit/s in theory, is introduced in 3GPP Release 7.

Multi-path effect is a major feature of the UMTS. The traditional RAKE receiver combines all

searched paths through multi-path effect to obtain multi-path combination gain. It also

increases the system throughput by improving the SNR of UL services.

The inter-path interference, however, is lower than the gain caused by multi-path combination

because the inter-path interference is insignificant when the UE moves at a low speed.

Therefore, the traditional RAKE receiver can be used to obtain the gain. In contrast, when the

UE moves at a high speed, the inter-path interference is significant, and inter-path interference

increases with the UL service rate. In a specified channel environment, the peak rate of a user

is limited by the inter-path interference and cannot be increased.

HSUPA FDE is performed to equalize the spectrum in the frequency domain on the HSUPA

E-DPDCH through the UL receiver of the NodeB. After the FDE, the inter-path interference

on the E-DPDCH is suppressed, and the SNR on the E-DPDCH is increased.

When supporting FDE feature, the NodeB cannot support 4 Rx diversity feature.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The BTS3812E and BTS3812AE must be configured with the EULPd board.



Dependency on UE

None


None

Dependency on CN

None







2.2.5 WRFD-010712 Adaptive Configuration of Traffic Channel Power offset for HSUPA

Availability


Summary

This feature is applicable to the HSUPA Best Effort (BE) service. When an HSUPA UE is in

the small retransmission state, this feature dynamically configures an optimal power offset for

the data channel based on the changes in uplink load and throughput. This feature helps

maintain the power of such UE on the uplink DPCCH at an optimal level, thereby increasing

the capacity of an HSUPA cell with multiple HSUPA UEs.

Benefits

This feature significantly improves the capacity of HSUPA cells in a live network, where the

feature WRFD-010641 HSUPA Adaptive Transmission is unavailable or UEs cannot enter the

large retransmission state due to CE limitation.

This feature significantly increases the HSUPA capacity of cells where a large number of

HSUPA UEs are processing low-speed uplink services. When there are a large number of UEs

processing data services in hot spots in busy hours, this feature improves the HSUPA capacity

of the cell by 5% to 20%, without increasing the cell load. This capacity improvement is

indicated by the increase in average cell throughput, in the number of UEs that can

simultaneously perform data transmission in the uplink, or in the decrease in Received Total

Wideband Power (RTWP).

Description

The offset of E-DPDCH power relative to DPCCH power is one of the major factors that

determine DPCCH power in the uplink. For an HSUPA UE in the small retransmission state,

if the data rate is low, a high offset can be configured for the E-DPDCH. This decreases the

power on the DPCCH and reduces the load on the uplink control channel. After the load is

reduced, UEs can transmit more data in the uplink, thereby increasing the capacity of HSUPA

cells. If the data rate is high, a low offset can be configured for the E-DPDCH. This increases

the power on the DPCCH, thereby meeting the power requirements of multipath searching

and channel estimation and ensuring the performance of HSUPA services.

When the feature WRFD-010641 HSUPA Adaptive Transmission is enabled, the offset of the

E-DPDCH power relative to the DPCCH power is not adjusted. In such a case, the gain of the

HSUPA Adaptive Transmission feature is not affected. Because the feature WRFD-010641

HSUPA Adaptive Transmission enables HSUPA UEs to adjust to the large retransmission state,

the capacity of the cell will be greatly increased, but with more CE consumption.

This feature is independent from the feature WRFD-010641 HSUPA Adaptive Transmission,

but these two features can be enabled together. Using these features together further increases the uplink capacity of the cell.



Enhancement

Before RAN15.0, this feature is only applicable to the HSUPA 10 ms BE service. In RAN15.0,

this feature is applicable to both HSUPA 10 ms BE service and HSUPA 2 ms BE service.

Dependency


None


None




None



2.2.6 WRFD-020136 Anti-Interference Scheduling for HSUPA

Availability


Summary

Sites in a commercial network experience strong and random external uplink interference.

This interference significantly reduces the HSUPA throughput in cells of the site and

negatively affects user experience.

This feature counteracts this interference, thereby ensuring high HSUPA throughput and

improving user experience.

Benefits

This feature ensures high HSUPA throughput in the cells of sites that experience strong uplink

interference from external sources. Under optimal conditions, applying this feature can raise

the HSUPA throughput in a cell with strong external interference to the level of a cell with no

interference.

Description

When a site in a commercial network experiences strong uplink interference from external

sources, the Received Total Wideband Power (RTWP) of cells of the site will increase

significantly. Before the introduction of this feature, the HSUPA scheduling algorithm



performs scheduling based on only the RTWP of the cell. As the interference reduces the load

margin available for use, the HSUPA throughput in cells of the site drops significantly.

With this feature, scheduling is performed on HSUPA UEs based on not only the RTWP of the

cell but also the traffic volume of the R99 and HSUPA UEs in the cell with strong uplink

interference. As long as the traffic volume is lower than the predefined threshold, sufficient

resources can be ensured for the R99 and HSUPA UEs even if the RTWP of the cell increases

to a very high value. This ensures high HSUPA throughput for the cell. The actual throughput

improvement due to this feature depends on the strength of the interference and parameter

configuration.

Enhancement

None

Dependency


None


The BTS3812E and BTS3812AE must be configured with the HBBI, EBBI, HULP,

EBOI, EULP, or EULPd board. The downlink services can only be set up on the EBBI,

EBOI, or EDLP board.

For the BBU3806, the downlink services can only be set up on EBBC or EBBCd board.





None



2.2.7 WRFD-020137 Dual-Threshold Scheduling with HSUPA Interference Cancellation

Availability


Summary

This feature is applicable to cells enabled with the WRFD-010691 HSUPA UL Interference

Cancellation feature. With this feature, scheduling is based on the RTWP thresholds before



and after HSUPA UL interference cancellation. This feature also raises the RTWP target value

before interference cancellation. This can increase the HSUPA throughput of the cell.

Benefits

This feature further increases the HSUPA throughput of cells enabled with the HSUPA UL

Interference Cancellation feature by around 5%-15%.

Description

In a cell enabled with the HSUPA UL Interference Cancellation feature, the RTWP after the

interference cancellation is always lower than that before the interference cancellation.

This feature dynamically raises the RTWP target value of the cell before interference

cancellation while keeping the RTWP after interference cancellation lower than or equal to

the RTWP target value of the cell with the feature not enabled. In this manner, the HSUPA

throughput of the cell can be increased without compromising coverage or network KPIs such

as call completion rate and call drop rate.

To minimize the impact on neighboring cells, this feature adopts a predefined upper threshold

for the increased RTWP target value before interference cancellation is performed.

Enhancement

None

Dependency


None


The BTS3812E/AE must be configured with EULPd board, and all users of the cell

should be established in one EULPd board.


The 3900 series base stations must be configured with the WBBPd or WBBPf board in

the UL resource pool which support IC feature, and slot 2 or 3 must be configured with

at least one WBBPd or WBBPf board.

The RRU3801C 20W and the MTFU for the BTS3812E and BTS3812AE do not support

this feature. The BTS3812E and BTS3812AE configured with the 8U WRFU support

this feature.



WRFD-010691 HSUPA UL Interference Cancellation


None






Availability


Summary

This feature enables a single HSUPA cell to simultaneously support 60 HSUPA users. If the

number of HSUPA users exceeds 60, the DCH is attempted for service provisioning.

Benefits

Compared with the HSUPA introduction package, more HSUPA users are available in one

cell.

Description

Up to 60 HSUPA users can be admitted to a HSUPA capable cell.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



WRFD-010614 HSUPA phase 2



2.2.9 WRFD-010210 Control Channel Parallel Interference Cancellation (CCPIC)

Availability


Summary

The self interference in the WCDMA system greatly affects its capacity and coverage. This

feature can effectively reduce UL interference and improve network performance.

Benefits

It can improve capacity so that the CAPEX is reduced.

Description

The control channels are always on and they are a substantial source of interference especially

with lower data rate and lower activity services.

CCPIC is a simplified and practical application of MUD technology for base station receivers.

It cancels the uplink control channel signal, decreases uplink interference to improve the

performance.

The DPCCH demodulation is performed first. According to all valid paths’ time delay and

fading information of received users, the received DPCCH signal can be reconstructed. All

users’ data channels such as DPDCH, E-DPCCH, and E-DPDCH can be demodulated after

the received DPCCH signal is subtracted from baseband signal.

In the case of the urban macro cell, TU3 channel, and AMR12.2k user with a 50% load, the

CCPIC will bring 11% capacity improvement; with a 75% load, the capacity improvement is

18%.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The CCPIC depends on the EBBC board or EBBI, EBOI, EULP, EBBCd or EULPd.

The BBU3900 needs to configure WBBPb, WBBPd or WBBPf board.

Dependency on UE

None




None

Dependency on CN

None


None



2.2.10 WRFD-140202 Control Channel Parallel Interference Cancellation (Phase 2)

Availability


Summary

This feature improves the efficiency of Control Channel Parallel Interference Cancellation

(CCPIC) by using the advanced regeneration cancellation algorithm. In addition, the benefits

of CCPIC are shared across baseband boards.

Benefits

This feature significantly increases the uplink system capacity. When the DPCCH uses a large

proportion of received total wideband power (RTWP) in a cell, this feature increases system

capacity by up to 20%. This gain is possible when the uplink throughput is not high but there

are a large number of UEs in the cell.

Description

This feature introduces the advanced regeneration cancellation algorithm, which makes

DPCCH regeneration more accurate and improves CCPIC efficiency as a result.

In addition, this feature allows the benefits of CCPIC to be shared across baseband boards.

When multiple baseband boards form a resource pool, CCPIC gain for UEs carried on one

board benefits UEs carried on other boards. Similarly, UEs carried on one board benefit from

the CCPIC gain of UEs carried on another board.

Enhancement

None

Dependency


None




The 3900 series base stations (except the BTS3902E) must be configured with the

WBBPd or WBBPf board.

To support inter-board IC, the WBBPd or WBBPf board must be configured for the

uplink resource group that supports inter-board IC. In addition, at least one WBBPd or

WBBPf board must be configured in slot 2 or 3.


None


None


None


WRFD-010210 Control Channel Parallel Interference Cancellation (CCPIC)



2.2.11 WRFD-010691 HSUPA UL Interference Cancellation

Availability


Summary

HSUPA UL interference cancellation (IC) is performed to offset the interference caused by the

UL high rate E-DPDCH data of other users, improving the demodulation signal-to-noise ratio

(SNR) and increasing the UL capacity of the UMTS system.

Benefits

The IC technology significantly decreases the UL interference and improves the UL capacity

of the cell. In some scenarios, the gain of the IC technology is significant. For example, if in a

cell there are a small number of HSUPA users with high throughput and a large number of

HSUPA users with low throughput at the same time, IC technology allows canceling the high

interference generated by high rate HSUPA users. If IC technology is not available, the cell

might suffer from reduced capacity of low rate users, such as VoIP users, or/and decreased

rate of high rate services.

Description

HSUPA is an important feature as defined in 3GPP Release 6 to provide UL high-rate services.

Six categories of UEs that support services at several rates are defined in the 3GPP

specifications. The maximum number of E-DCH codes varies depending on the UE’s category.



That is, UEs support different peak rates, even up to 5.74 Mbit/s. UE category 7, which

supports the 16QAM mode and a UL peak rate of up to 11.5 Mbit/s in theory, is introduced in

3GPP Release 7.

Based on the wideband code division multiple access technology, the UMTS is a

self-interfering system. With the increase of the HSUPA rate, the UL interference becomes

more and more heavy. The UL interference is a major factor affecting the UL capacity of the

UMTS.

The IC technology supports different types of HSUPA users, including UEs of categories 1 to

7. The principle of the IC technology is as follows: The UMTS is a self-interfering system.

The interference to a user comes mainly from signals of other users and from the background

noise in the cell. Without the IC technology, signal demodulation is performed in high

interference. Therefore, the capacity of the cell is highly reduced. With the IC technology, the

signals over E-DPDCH from IC-enabled users are analyzed and reconstructed. Then, the

interference from the reconstructed signals is subtracted from the total interference. As a

result, the total interference of the cell is reduced and the system capacity increases.

The IC feature of Huawei NodeB has the following benefits:

IC can be performed to the HSUPA services at 2 ms TTI and 10 ms TTI simultaneously.

The IC feature does not consume extra CE resources.

The IC gain can be shared by all the UEs in a cell, including the IC-enabled UEs and

IC-disabled UEs.

During HSUPA scheduling, the actual load of the cell and the load of the cell after

interference cancellation can be managed at the same time. While the stable operation of the

system is ensured, the system capacity can be maximized.

In addition, Huawei NodeB sets up an IC resource pool, which enables IC result to be shared

between boards. The IC resource pool has the following functions:

IC result is shared between IC-capable boards. That is, when multiple IC-capable boards exist

in a NodeB, these boards can share the signals after interference cancellation. Therefore, each

UE finally is demodulated from the signals whose interferences of E-DPDCHs from other

users are cancelled, maximizing the system capacity.

IC result can be shared by IC-incapable boards. That is, when the IC-capable boards and

IC-incapable boards coexist in a NodeB, the IC-capable boards transmit signals after

interference cancellation to the IC-incapable boards. Therefore, UEs carried by IC-incapable

boards are also demodulated from signals whose interference is reduced rather than original

signals. In this way, the demodulation performance of IC-incapable boards is improved and

the IC gain maximized.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB



The BTS3812E and BTS3812AE must be configured with the EULPd board, the

downlink service cannot be established on HBBI/HDLP/NDLP, and the IC effect cannot

be shared between BB boards.

The DBS3800 must be configured with the EBBCd board and the IC effect can be shared

between the BB boards.

The 3900 series base stations must be configured with the WBBPd or WBBPf board, and

only if slot 2 or 3 is configured with at least one WBBPd or WBBPf board, IC effect can

be shared between the WBBPd or WBBPf boards.

Dependency on UE

None


None

Dependency on CN

None





2.2.12 WRFD-010636 SRB over HSUPA

Availability



Summary

This feature enables UL SRBs to be carried over HSUPA. This feature can obtain a lower call

delay and save transmission resources.

Benefits

This feature provides a higher signaling rate and reduces the call process delay. Since the SRB

is carried on the HSUPA, the transmission resource can be saved, compared with that is

carried on the DCH.

Description

The signaling over the SRB is delay sensitive and irregular. Compared with the DCH, it is

more appropriate to set up the SRB over the HSUPA. The SRB over the HSUPA can be

applied during the RRC connection setup or other procedures such as the mobility

management.



If the SRB is set up over the DCH, it can be reconfigured to be mapped onto the HSUPA in

some cases such as the target cell of the handover supports the HSUPA while the source cell

does not. Inversely, the SRB mapping on the HSUPA can also be reconfigured to be mapped

onto the DCH if the target cell of the handover does not support the HSUPA.

The SRB over the HSUPA is configurable. The operator can enable/disable the SRB over

HSUPA function.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The 38XX series NodeB supports this feature, and the EBBI, EBOI, EULP, EULPd,

EBBC or EBBCd is required.

The 3900 series NodeB supports this feature, and the WBBPb, WBBPd, or WBBPf is

required.

Dependency on UE

None


None

Dependency on CN

None



2.2.13 WRFD-140222 Adaptive Adjustment of HSUPA Small Target Retransmissions

Availability


Summary

This feature dynamically adjusts the target number of retransmissions based on the uplink

throughput of UEs and the uplink load on the serving cell. The purpose is to improve the

uplink throughput of the serving cell.



Benefits

This feature improves the system capacity in cases where multiple HSUPA UEs with a 10 ms

transmission time interval (TTI) are uploading data in a cell with a limited uplink load.

Description

When the uplink load is limited, a small target number of retransmissions will impose high

requirements on the signal-to-interference ratio (SIR) on the Dedicated Physical Control

Channel (DPCCH), and the DPCCH must use higher power. This leads to a decrease in the

power of available data channels, a lower UE throughput, and a lower HSUPA cell throughput.

The adaptive adjustment of HSUPA small target retransmissions feature has been introduced

to address these problems. This feature supports an alternative small target number of

retransmissions for each typical type of service. The actual target number of retransmissions

can dynamically shift between the original fixed number and the alternative number

depending on the throughput of UEs and the uplink load on the cell. This improves the system

capacity when the uplink load is limited.

A cell can be simutaneouslly configured with the feature Adptive Adjustment of HSUPA

Samll Target Retransmissions and the feature DC-HSUPA. However, if DC-HSUPA is enable

for a UE, Adaptive Adjustment of HSUPA Small Target Retransmissions will not work for this

UE.

Enhancement

None

Dependency


None


None


None


None


None

Dependency on other features

This feature depends on WRFD-010612 HSUPA Introduction Package.



2.2.14 WRFD-150206 Turbo IC

Availability


Summary

Turbo Interference Cancellation (IC) improves IC efficiency by regenerating decoded signals

from the E-DPDCH. This feature also supports uplink E-DPCCH IC, improving the

signal-to-noise ratio (SNR) for demodulation and increasing system capacity in the uplink.

This feature supports High Speed Uplink Packet Access (HSUPA) UEs using the 2 ms

transmission time interval (TTI) only.

Benefits

This feature improves IC efficiency and increases system capacity in the uplink.

In addition to the uplink IC gains provided by HSUPA, this feature further increases the

uplink system capacity by a maximum of about 10% in the following scenarios:

A large number of UEs use the 2 ms TTI for continuous data transmission in the serving

cell.

The throughput of HSUPA 2 ms TTI UEs is high.

Description

UMTS, which is based on the code division multiple access (CDMA) technology, is a

self-interfering system. A UMTS UE experiences interference from other UEs' signals and the

serving cell's background noise. In HSUPA, uplink interference increases along with the

growing data rates and is now the main bottleneck for increasing UMTS uplink capacity.

Turbo IC addresses this issue. This feature improves IC performance by regenerating decoded

signals from the E-DPDCH to obtain more accurate signals. Turbo IC also supports uplink

E-DPCCH IC. That is, this feature reduces the interference from regenerated signals on the

E-DPDCH and E-DPCCH, decreasing the total interference in the serving cell and improving

uplink system capacity.

This feature:

Supports HUSPA UEs using the 2 ms TTI only

Consumes no additional channel element (CE) resources

Supports uplink IC resource groups:

− If all the boards configured in the uplink resource groups support Turbo IC,

inter-board UEs can share centralized IC gains.

− If only a few boards configured in the uplink resource groups support Turbo IC,

inter-board UEs can share only the HSUPA uplink IC gains and intra-board UEs can

share Turbo IC gains only for the boards supporting Turbo IC.

Enhancement

None



Dependency


None


Only the 3900 series base stations (except the BTS3902E) DBS3900, BTS3900, BTS3900A,

and BTS3900L support this feature and must be configured with the WBBPf board.

If the NodeB needs to support inter-board IC sharing, a minimum of one WBBPd or WBBPf

board must be configured in slot 2 or 3 for an uplink resource group that supports inter-board

IC sharing.

Dependency on UEs

The UEs must be of category 6 or higher.


None


None


WRFD-01061403 HSUPA 2ms TTI

WRFD-010691 HSUPA UL Interference Cancellation

2.2.15 WRFD-150222 HSUPA Time Division Scheduling

Availability


Summary

In a cell with multiple high-speed 2 ms TTI HSUPA UEs, this feature performs time division

scheduling on these UEs to reduce interference caused by simultaneous data transmission of

the UEs. This improves the uplink throughput for this cell.

Benefits

This feature enables a cell to provide a high HSUPA throughput, even when multiple 2 ms

TTI HSUPA UEs are simultaneously performing high-speed data transmission in the cell.

With this feature, the throughput of the cell with two to eight 2 ms TTI HSUPA UEs is nearly

the same as that of the cell with only one 2 ms TTI HSUPA UE in optimal situations. For

example, all UEs are static and time division scheduled and are performing stable and

high-speed uploading services.

This feature helps increase the cell uplink throughput by 15% if:

A cell has two receive antennas.



Eight UEs are performing continuous FTP uploading in the cell.

The cell is enabled with the WRFD-010691 HSUPA UL Interference Cancellation

feature.

Description

WCDMA is a self-interfering system. Any UE in this system is an interference source for

other UEs. The higher the data rate of a UE, the greater the interference this UE imposes on

the uplink channels of the cell. When a cell has multiple high-speed 2 ms TTI HSUPA UEs,

the uplink channel interference is the main bottleneck for the cell uplink capacity.

This feature applies to a cell with multiple high-speed 2 ms TTI HSUPA UEs, especially a

one-antenna cell where Uu-interface resources are insufficient. This feature allocates the eight

Hybrid Automatic Repeat Request (HARQ) processes of 2 ms TTI HSUPA to different UEs to

perform data transmission. During each 2 ms TTI, only one UE is transmitting data. This

reduces the interference caused by simultaneous data transmission of the UEs and improves

the cell uplink throughput.

The following figure compares code division scheduling and time division scheduling.

The gain provided by this feature depends on the UE traffic model. A static UE performing

stable and high-speed uploading has the highest gain. If all UEs in a cell are time division

scheduled and transmit data using different HARQ processes, this feature provides the highest

gain in cell throughput. As the number of time division scheduled UEs increases, however, the

load of the uplink DPCCH increases. This reduces the available resources on the E-DPDCH,

which slightly decreases cell throughput.

The gain provided by this feature also depends on whether the transmitting intervals overlap.

This feature does not apply to UEs performing soft handovers because mobility will cause the

transmitting intervals to overlap. This feature provides higher gains in indoor environments

than in outdoor environments because soft handover is less likely to occur in indoor

environments and more UEs can be scheduled in time division mode.

This feature does not apply to a cell served by multiple RRUs because Uu-interface resources

are not shared by different RRUs.

Enhancement

None



Dependency


None


Only the 3900 series base stations (except the BTS3902E) support this feature and must be

configured with the WBBPf board support this feature. The downlink of the cell cannot be set

up on the WBBPa board.

Dependency on UEs

The UEs must be of HSUPA category 6, 7, 8, or 9.


None


None


WRFD-01061403 HSUPA 2ms TTI


2.3 HSDPA Prime Service

2.3.1 WRFD-010610 HSDPA Introduction Package

Availability



Summary

High Speed Downlink Packet Access (HSDPA) is one of the important features defined in

3GPP specifications. HSDPA can greatly increase the peak rate per user, shorten the round trip

delay, and improve the system capacity. This feature package provides the basic functions of

HSDPA to meet the requirements for test or trial operations of HSDPA services.

Benefits

HSDPA improves the performance of the UMTS network in the following aspects:

Providing high rate throughput

Shorter round trip time

Higher system capacity



Description

High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5.

The maximum downlink throughput is achieved by sharing CE resources, power resources,

and code resources with new physical channels and downlink shared transport channel for

HSDPA. The physical channels are HS-SCCH, HS-PDSCH, and HS-DPCCH, and the

transport channel is HS-DSCH. HD-PDSCH (SF = 16) will utilize the remaining TX power

and codes in a cell, which enables the resource to be dynamically shared among users.

Some key functions are also used in HSDPA for maximizing resource utilization, including 2

ms TTI, hybrid ARQ with soft combining (HARQ), Adaptive Modulation and Coding (AMC),

and fast scheduling algorithm.

The application of 2 ms TTI greatly reduces the round trip time. At the same time, some

functions are moved down to the NodeB that also contributes to reducing the round trip time.

When compared with RLC re-transmission, HARQ provides a more highly efficient

re-transmission mechanism. The UE can request for retransmission of only erroneously

received data immediately and combine the retransmission data with original transmission

data through soft combining.

AMC enables the system to decide the Transport Block (TB) size and the modulation mode

according to estimated channel condition indicated by the UE. When the UE is in favorable

radio environment, the transmission can adopt 16 QAM modulation mode and large transport

blocks to increase the capacity and data rate.

The fast scheduling algorithm includes Max C/I, Round Robin, Proportional Fair (PF), and

Enhanced Proportional Fair (EPF). EPF is based on the PF algorithm which can provide users

with Guaranteed Bit Rate service for I/B services.

HSDPA is mainly used for packet services and can bear the interactive, background, and

streaming services. The HSDPA traffic can use a dedicated carrier or a shared carrier with

R99. The system should be capable of handling both cases.

The system should consider the mobility management of the HSDPA services, such as the

intra-RNC handover, inter-RNC handover, and soft handover for the DCH.

Enhancement

In RAN5.1, RAN6.0, and RAN10.0, HSDPA Introduction Package is enhanced. For details,

see the enhancement of the sub-features in the HSDPA Introduction Package.

Dependency

Dependency on RNC

None

Dependency on NodeB

NBBI and NDLP do not support this feature.

Dependency on UE

The UE should have the HSDPA capability.




None

Dependency on CN

None


None

2.3.2 WRFD-01061017 QPSK Modulation

Availability


Summary

This feature is related to QPSK modulation. QPSK modulation is a basic downlink data

modulation function that is used after HSDPA is introduced.

Benefits

This feature provides higher service bit rate to enhance the user experience.

Description

Quaternary Phase Shift Keying (QPSK)

The HS-PDSCH is used to carry the HS-DSCH data. HS-PDSCH can use QPSK or 16QAM

modulation symbols.

When the UE is in the unfavorable radio environment, the transmission can adopt the

low-order QPSK modulation mode and small transport blocks to ensure communication

quality.

When the UE is in the favorable radio environment, the transmission can adopt the high order

16QAM modulation mode and large transport blocks to reach a high peak rate.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



None


None

Dependency on CN

None



2.3.3 WRFD-01061001 15 Codes per Cell

Availability


Summary

This feature provides code resources occupied by Huawei HSDPA services. The HS-PDSCHs

can use up to 15 codes in a cell.

Benefits

HSDPA with 15 codes makes it possible to introduce higher bit rate service from day one and

improve system capacity.

Description

High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5,

which provides high speed downlink services. A new downlink shared transport channel,

HS-DSCH, is introduced for carrying services. The transport channel HS-DSCH is mapped on

one or several High-Speed Physical Downlink Shared Channels (HS-PDSCHs) which are

simultaneously received by the UE. In the 3GPP standard, there are up to 15 HS-PDSCHs per

cell with the spreading factor fixed to 16. The number of HS-PDSCHs per NodeB is

configurable and depending on the license, the NodeB can dynamically share codes licenses

to HS-PDSCH between cells.

The HS-PDSCHs can use up to 15 codes in one cell by which the supported peak rate of air

interface can reach up to 14.4 Mbit/s. The system capacity is improved by supporting 15

codes.

Enhancement

None

Dependency

Dependency on RNC

None



Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.3.4 WRFD-01061018 Time and HS-PDSCH Codes Multiplex

Availability


Summary

This feature enables the allocation of different codes in the same TTI to different users or the

time division multiplexing of the same code in different TTIs for different users to provide the

utilization of code resources and the system throughput.

Benefits

This feature improves the efficiency and performance of HSDPA service.

Description

The parallel data transmission of multiple users over HS-DSCH requires more HS-SCCH

codes and HS-PDSCH codes within a single TTI. Code multiplexing is adopted and is found

useful when the NodeB has more HS-PDSCH codes for allocation than those supported by the

UE. For instance, the UE supports 5 codes and the NodeB has 10 codes available in a single

TTI. The code multiplexing can increase the resource utilization and system throughput.

Enhancement

None

Dependency

Dependency on RNC

None



Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.3.5 WRFD-01061009 HSDPA H-ARQ & Scheduling (MAX C/I, RR and PF)

Availability


Summary

This feature is related to hybrid automatic repeat request (HARQ) and HSDPA scheduling

algorithms. Huawei provides multiple HSDPA scheduling algorithms such as Max C/I, RR,

PF, and EPF.

Benefits

This feature provides the flexibility for the operator to select the scheduling algorithm, after

considering the system capacity and fairness among the users.

Description

HARQ

For the HSDPA services at the physical layer, if errors occur in decoding, the HARQ reserves

the data before the decoding and combines it with the retransmitted data.

Compared with R99, HARQ retransmission is faster and more efficient than RLC

retransmission. In this sense, the HARQ can be called a new technology and a combination of

the Forward Error Correction (FEC) and ARQ. HARQ has a higher downlink performance

gain.

At every TTI (2 ms), the scheduling algorithm enables the system to decide the UEs for data

transmission. This feature provides different HSDPA schedule algorithms, considering the

tradeoff between system capacity and fairness among the users.

Four scheduling algorithms are provided and the operator decides which algorithm to choose.



Max C/I

RR (round Robin)

PF (proportional fair)

During the scheduling procedure, the several aspects to be considered include CQI, user

priority, channel quality, service bit rate, and re-transmission. All scheduling algorithms

support the retransmission priority rule. If a UE requires retransmission at a certain

scheduling time, the UE is scheduled at a higher priority.

In addition, two factors may affect the accuracy of the CQI reported by the UE:

Channel environment of the UE

Measurement error of a specific UE

If the CQI reported by the UE does not reflect the actual radio conditions, this will lead to the

decrease of HS-DSCH transmission efficiency, because both scheduling and TFRC selection

are performed on the basis of the reported CQI.

To avoid the negative impact on the system caused by inaccurate CQI reports, the CQI

adjustment algorithm can revise the reported CQI according to the ACK or NACK of initial

transmission and the initial BLER target. The adjusted CQI is used for MAC-hs scheduling

and TFRC selection.

Enhancement

In RAN10.0, the functionality of compressed mode tracing during scheduling is supported.

That is, if a TTI is overlapped with a UE’s compression mode gap, this UE should not be

scheduled in this TTI.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





2.3.6 WRFD-01061005 HSDPA Static Code Allocation and RNC-Controlled Dynamic Code Allocation

Availability


Summary

This feature is related to HSDPA static code allocation and RNC-controlled dynamic code

allocation. When R99 and HSDPA services co-exist, this feature enables full use of

channelized code resources to improve the efficiency and system capacity.

Benefits

The HSPDA static code allocation function helps to improve the system throughput of

HSDPA service and achieve high code utilization. R99 service and HSDPA service can

co-exist with less conflict of resources.

Description

Before the NodeB starts to transmit data on the HS-DSCH, the RNC shall allocate the

channelization code for HS-SCCH with an SF of 128 and for HS-PDSCH with an SF of 16.

Generally, the RNC allocates as many HS-PDSCH codes to the NodeB as possible to improve

the system capacity and spectral efficiency. On the other hand, the channelization codes

reserved for HS-PDSCH transmission cannot be simultaneously used for transmission of the

R99 channel, and hence the allocation of many HS-PDSCH codes might eventually result in

blocking of R99 users. Therefore, it is important for the RNC and NodeB to properly utilize

the channelization code resources to improve both efficiency and system capacity.

There are two strategies for allocating HS-PDSCH codes: static allocation and dynamic

allocation. The two strategies have different effects on the HSDPA service.

There defined two types of code strategy for HS-PDSCH code allocation, which can take

different effects on the HSDPA service, static allocation, and dynamic allocation.

Static allocation is generally used at the initial HSDPA deployment stage because there are

less HSDPA users and more R99 users at this stage. The RNC reserves some codes for the

HS-PDSCH and the DPCH while other common channels use the rest codes. The number of

reserved codes for the HS-PDSCH is configurable.

Code reserved for

common channel and

HS-SCCH Codes reserved for

HS-PDSCH

SF=16

Codes available

for DPCH

With the increasing demand for the HSDPA service, dynamic HS-PDSCH code allocation is

needed to increase code utilization efficiency. According to the code allocation controller, the



code allocation is of two types, namely the RNC-controlled dynamic HS-PDSCH code

allocation and the NodeB-controlled dynamic HS-PDSCH code allocation.

In the RNC-controlled dynamic HS-PDSCH code allocation, the RNC determines the

maximum number and minimum number of HS-PDSCH codes that NodeB can use and then

informs the NodeB about the code information through the Physical Shared Channel

Reconfigure Request signaling message. The code resources between the maximum number

of codes and the minimum number of codes are shared codes. If the shared codes are available

for HSDPA, the RNC increases the minimum number of HS-PDSCH codes and informs the

NodeB about this information. The RNC is in charge of the code management.

Shared codes

Max numberof codes

Min numberof codes

SF=16

Codes available for DPCH Codes reserved for HS- PDSCH

Code reserved for

common channel and

HS-SCCH

Enhancement

In RAN5.1, the RNC-controlled dynamic HS-PDSCH code allocation is introduced.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





2.3.7 WRFD-01061004 HSDPA Power Control

Availability


Summary

This feature enables the operator to properly configure the power control mode of the

HS-SCCH, improving the power efficiency and obtaining higher system capacity and user

experience.

Benefits

This feature enables the system to provide reliable reception quality for the HS-SCCH. It can

increase system capacity and reduce the NodeB power output for the HS-SCCH, raising the

total transmission power utilization.

Description

When the HSDPA service is introduced, the total transmit DL power resource per cell is

divided into three parts, namely, common channel power, DPCH power, and HSDPA physical

channel power (HS-PDSCH and HS-SCCH).

In order to achieve high HSDPA performance, the power resource, except for those reserved

for common channel, is dynamically allocated between DPCH and HSDPA physical channel.

In the case of the R99 service, the power of DPCH is adjusted through inner and outer loop

power control. The power of HSDPA channel is allocated and adjusted dynamically among

users through the NodeB scheduling algorithm.

With dynamical power allocation, the NodeB estimates the power available for the entire

HSDPA channel per TTI by using the following formula:

P(hs) = P(total) - P(margin) - P(non-hsdpa).

The P(total) is the maximum downlink transmission power for the cell that is configured in

the RNC. The P(non-hsdpa) is the total transmitted carrier power of all codes not used for

HS-PDSCH and HS-SCCH. P(margin) is a configurable value which is used for the power

increase caused by R99 power control at every 2 ms TTI.

The NodeB then adjusts the power between HS-SCCH and HS-PDSCH. Normally, there are

two types of power control methods for the HS-SCCH:

Fixed transmitting power of the HS-SCCH

Based on CQI report

In the NodeB, the fixed transmit power of the HS-SCCH can be configured by the operator.

For the power control based on CQI report, the HS-SCCH transmit power is adjusted on the

basis of the CQI report received from the user.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.3.8 WRFD-01061003 HSDPA Admission Control

Availability


Summary

This feature implements admission control over HSDPA users in the aspects such as the

number of HSDPA users, remaining power resources, Iub interface resources, and service rate

thresholds. This feature can ensure QoS of the existing HSDPA users while fully utilizing the

resources.

Benefits

This feature enables HSDPA services to properly utilize system resources and enables HSDPA

and R99 services to exist in the same cell. The system resource can be reserved in terms of the

Iub transport resource, power resources, and user number resources to provide high bit rate

service for users.

Description

HSDPA service admission control enables HSDPA service to access the network with other

R99 services by using the remaining power resource as well as other resources. It can utilize

the system resources greatly.

In the HSDPA admission control procedure, the maximum number of HSDPA users per

NodeB and per cell is dependent on the configuration.



If the downlink carrier power is dynamically allocated between R99 and HSDPA channels, the

admission control will involve not only the limitation of total HSDPA user number for best

effort services, but also the sum of downlink code transmission power for both DPCH and

HS-PDSCH carrying streaming service.

Iub interface resources check is performed during the admission control to allow HSDPA

service and other R99 services to be admitted under a certain ensured QoS.

During the admission control, the RNC will decide whether to map the service onto the

HS-DSCH by setting service rate thresholds in the RNC. The thresholds include a DL

streaming service HSDPA threshold and a DL BE service HSDPA threshold. The call can be

mapped on HSDPA only when the requested bit rate of the incoming call is greater than the

threshold.

Enhancement

In RAN5.1, GBR for BE (interactive/background) over HSPA can be configured, so the

minimum throughput for BE over HSPA should be guaranteed. GBR is used to estimate

whether the maximum available power for HSDPA can satisfy the requirement of

interactive/background service in RAN5.1.

In RAN5.1, the power available for HSDPA GBR services shall be guaranteed during the

admission control. This part of the power shall not be pre-empted by R99 services, although

the power is shared between R99 and HSDPA.

In RAN6.0, queuing and pre-emption are considered for HSDPA if admission control fails.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





2.3.9 WRFD-01061020 Improvement of User Experience in Low Traffic Service

Availability


Summary

This feature is implemented in the following procedure: NodeB identifies the characteristics

of services carried on the HSPA channel to find the low traffic services, such as gaming

service and chat service (MSN messenger for example), which have a small number of data to

transmit each time. Then, improve the capability of services to obtain resources on the basis

of the scheduling and flow control principles of HSPA, improving the low traffic service

delay experience.

Benefits

UEs can obtain good delay experience when they use the services with burst low traffic.

Description

The HSPA provides higher bandwidth and supports more services.

However, UMTS network is a radio network whose radio resources are shared by all the UEs

in a cell. When the traffic volume in a cell is high, the QoS of low traffic services is easily

impacted by other services, such as gaming and chatting. This feature identifies a burst

service based on the traffic features, and then reallocates much higher bandwidth to it.

Therefore, a larger bandwidth is available for the data transmission of the low traffic service,

and the UE obtains better service delay experience.

The priority of the UE can be considered in the feature to provide differentiated services to

low traffic services.

Enhancement

None

Dependency

Dependency on RNC

Only the BSC6900 supports this feature.

Dependency on NodeB

The BTS3812E, BTS3812A, and BTS3812AE must be configured with the EULP, EBBI,

EBOI or EULPd board.



Dependency on UE



None


None

Dependency on CN

None


WRFD-010610 HSDPA Introduction Package or


2.3.10 WRFD-01061019 HSDPA Dynamic Power Allocation

Availability


Summary

This feature enables R99 and HSDPA services to share the cell power. This feature can ensure

the requirements of R99 users and make HSDPA users obtain a higher throughput, greatly

improving the power efficiency.

Benefits

This feature enables HSDPA services to properly utilize system resources and enables HSDPA

and R99 services to exist in the same cell. The system resource can be reserved in terms of the

Iub transport resource, power resources, and user number resources to provide high bit rate

service for users.

Description

The cell total transmit power is the constant resource. The DL power consists of the following

three parts:

Power of the HSDPA DL physical channel (HS-SCCH and HS-PDSCH)

Common channel power

DPCH power

Among the three parts, the second is reserved and the first is allocated by the NodeB.

Except those reserved for the common channels, the remaining power resources of the cell are

allocated dynamically between the DPCH and the HSDPA DL physical channels. The DPCH

assumes higher priority with regard to using the remaining power resources.



As shown in the figure above, the NodeB detects the R99 power load every 2 ms to determine

the available power for HSDPA. In this way, the cell load is more stable.

To obtain the available power for HSDPA, a power margin must be set aside to handle the

power increase caused by R99 power control every 2 ms.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



Flexible scheme

Power for CCH

Power for DPCH

Power for HSDPA

F

u

l

l

u

s

a

g

e

o

f

p

o

w

e

r

Total Power

Time



2.3.11 WRFD-01061010 HSDPA Flow Control

Availability


Summary

This feature enables the resource information interaction between the RNC and NodeB to

ensure that the data to be transmitted by the UE matches the scheduled one. In addition, this

feature can minimize the buffer size and buffer time of the NodeB to avoid data loss probably

caused by overtime data buffering.

Benefits

This feature can prevent packet loss and maximize the utilization of power and code resources.

It enables the service scheduling and re-transmission functions in the NodeB and reduces the

data transmission latency.

Description

HSDPA flow control ensures that the NodeB queue has enough data to be transmitted for a

UE when this UE is scheduled. At the same time, flow control feature can minimize the buffer

size and buffer time in the NodeB in order to avoid data loss probably caused by overtime

data buffering.

The RNC sends CAPACITY REQUEST control frame to the NodeB through the Iub interface.

The NodeB will monitor the buffer status and measure the throughput when the UE is

scheduled. Meanwhile, the NodeB considers the Iub interface throughput as well as the Iub

bandwidth. A CAPACITY ALLOCATION message will be sent to the RNC after the NodeB

decides how much data to send.

The NodeB can also initiate the update of capacity allocation towards the RNC based on the

buffer size of the queue and the available bandwidth on the Iub interface.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None




None

Dependency on CN

None



2.3.12 WRFD-01061006 HSDPA Mobility Management

Availability


Summary

This feature is related to HSDPA mobility management in different scenarios. This feature

ensures that the HSDPA services are continuous.

Benefits

This feature reduces the service disruption of the UE in movement when performing the

HSDPA service, enhancing user experience. In addition, this feature ensures that the services

between R99 and HSDPA cells are continuous.

Description

The HSDPA mobility management function enables an HSDPA user to change the cell to an

R99 cell or another HSDPA cell when the HSDPA user is in movement. The mobility feature

also enables an HSDPA user to change the servicing cell with less service interruption.

The difference in mobility handling is that the HS-DSCH cannot perform soft handover

compared with the DCH. In addition, there is only one serving HSDPA cell or HSDPA

connection for the HSDPA user. The HSDPA cell change procedure is used for the HSDPA

user mobility solution. The associated DCH can undergo soft handover and maintain the

Active Set as described in Release 99.

The similarity in mobility handling is that both HS-DSCH and DCH handovers are based on

the measurement report of the UE and controlled by the network. If the UE has both the

HSDPA and the DPCH connections, the measurement and the handover decision are made

separately.

Handover from HSDPA Cell to R99 Cell

When the UE is moving from an HSDPA cell to a R99 cell (intra-frequency) and event

1B, 1C or 1D is triggered, the HSDPA connection between UE and HSDPA cell will be

changed to the DCH connection between UE and R99 cell through DCH soft handover

and HS-DSCH radio link reconfiguration. The HSDPA cell is no longer the best cell in

the Active Set and the target cell does not support HSDPA. Therefore, the current

HS-DSCH cell will be replaced or removed from the Active Set and the service will be

changed to the DCH instead of the HS-DSCH for service continuity.



If the neighboring cell of HSDPA cell is an inter-frequency cell and does not support

HSDPA, a hard handover will be performed. The HSDPA handover decision is based on

the measurement report of the pilot channels of neighboring cells.

Handover from R99 Cell to HSDPA Cell

When an HSDPA capable UE with interactive/background/streaming service accesses the

R99 cell, only the DCH is used to carry these services. And when the UE is moving from

R99 cell to HSDPA cell (intra-frequency or inter-frequency), the system can change the

service to HS-DSCH channel.

For intra-frequency cell, the DPCH connection between UE and HSDPA cell will be set

up first due to event 1A. When the HSDPA cell becomes the best cell and event 1D is

triggered, the service will be switched from the DPCH to the HS-PDSCH of the HSDPA

cell carrying the PS service.

For inter-frequency cell, when the UE moves, an inter-frequency handover is triggered if

the quality of the signals of HSDPA cell improves. The UE changes from R99 cell to

HSDPA cell and the PS service will be switched from the DPCH to the HS-PDSCH.

Handover Among HSDPA Cells

For intra-frequency cell, cell change takes place when the HSDPA connection is moved

from one HSDPA cell to another. The source HSDPA cell is removed from the Active Set

trigged by event 1D and target HSDPA cell is added to the Active Set as a best cell.

For inter-frequency cell, an inter-frequency handover between HSDPA cells is triggered.

The service will be changed to the HS-DSCH of the target cell. The hard handover

depends on the UE measurement.

Handover from HSDPA Cell to 2G cell

The handover from an HSDPA cell to a 2G cell is triggered by normal inter-RAT

handover. For details, refer to the features of inter-RAT handover. Whether to downgrade

the HSDPA service to the R99 service before handover can be configured by the

operator.

Inter RNC mobility for HSDPA

For cell change between RNCs, the Directed Signaling Connection Re-establishment

(DSCR) and SRNC relocation procedure will be used. The DSCR is used for the UE

moving between RNCs without the Iur interface. The procedure is trigged by the UE

which sends the RRC CONNECTION SETUP REQUEST message in the DRNC. At this

time, the UE moves to the cell of the DRNC and no handover or relocation occurs.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None




None

Dependency on CN

None



2.3.13 WRFD-01061014 HSDPA Transport Resource Management

Availability


Summary

This feature enables different HSDPA services to be mapped to different paths for classified

management, optimizing the utilization of Iub transmission resources for the HSDPA services.

Benefits

Differentiated service is implemented on different paths and the QoS and network

performance are optimized. Improve the transport resource utilization and save OPEX for Iub

transmission.

Description

With the introduction of the HSDPA feature, the throughput over the Iub interface may be

increased and varied greatly. This feature is used to optimize the usage of Iub transport

resources for the HSDPA services. The features concerned are as follows:

Differentiated services mapping

Transport resource load control

I. Differentiated services mapping

The CS conversational, PS conversational, PS streaming and best effort services can be set up

on HSDPA. Different services have different QoS requirements, in RAN11.0 HSDPA services

are considered unified with common channel and R99 services in Transmission Resource

Mapping. The details of unified Transmission Resource Mapping belongs to optional feature

WRFD-050424 Traffic Priority Mapping onto Transmission Resources. By using this feature,

different services are carried on corresponding paths, and the differentiated service is

implemented.

II. Transmission resource load control

Transmission resource load control includes admission control and congestion control.



For the admission control, the Guaranteed Bit Rate (GBR) will be considered in the HSDPA

service admission procedure. The GBR belongs to the optional feature WRFD-01061003

HSDPA Admission Control.

For the congestion control, the load reshuffling strategies will be applied to inter-RAT

handover which belongs to the optional feature WRFD-020306 Inter-RAT Handover Based on

Load.

Enhancement

In RAN6.1, each traffic class mapped onto transmission resource can be configured

separately.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


Optional feature WRFD-050402 IP Transmission (Iub interface), WRFD-050403 Hybrid IP

Transmission, and WRFD-050404 ATM/IP Dual Stack NodeB should be required when the

transmission resource management feature is applied for IP transmission resources in those

scenarios.

2.3.14 WRFD-01061008 Interactive and Background Traffic Class on HSDPA

Availability


Summary

This feature enables interactive and background services to be mapped to the HS-DSCH to

obtain a higher service rate and enhance user experience.



Benefits

This feature enables the system to support a higher speed RAB of PS background and

interactive service.

Description

This feature enables the best effort service (interactive and background) to be mapped onto

the HS-DSCH as long as the UE supports HSDPA. The system can set the service rate

threshold and only when the requested service bit rate is higher than the threshold, the request

service can be mapped onto the HS-DSCH. Otherwise, the requested service will be mapped

onto the DCH. The service rate threshold can be configured by the operator. When the best

effort service is carried on the HS-DSCH, the maximum downlink bit rate can be up to 1.8

Mbit/s (MAC layer).

When a UE is performing interactive or background service, it can use another CS RAB or

another PS RAB. If allowed, the UE can use two HSDPA BE RABs simultaneously.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.3.15 WRFD-01061002 HSDPA UE Category 1 to 28

Availability




Summary

This feature can provide suitable HSDPA services for the UEs of category 1 to category 28.

Benefits

This feature supports HSDPA services for 28 categories of UE so as to provide high bit rate

services for different categories of UEs. The maximum bit rate that can be achieved by the UE

depends on the UE specification.

Description

High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5

which can provide high speed service for the downlink. In order to provide multiple bit rate

services, 28 UE categories are defined in 3GPP. Different UE categories can support different

maximum codes for the HS-DSCH, which means that different maximum bit rates can be

achieved.

HS-DSCH Category

Maximum Number of HS-DSCH Codes Received

Minimum Inter-TTI Interval

Maximum Number of Bits

Maximum Bit Rate

(Mbit/s)

Category 1 5 3 7,298 3.649

Category 2 5 3 7,298 3.649

Category 3 5 2 7,298 3.649

Category 4 5 2 7,298 3.649

Category 5 5 1 7,298 3.649

Category 6 5 1 7,298 3.649

Category 7 10 1 14,411 7.2055

Category 8 10 1 14,411 7.2055

Category 9 15 1 20,251 10.1255

Category 10 15 1 27,952 13.976

Category 11 5 2 3,630 1.815

Category 12 5 1 3,630 1.815

Category 13 15 1 35,280 17.64

Category 14 15 1 42,192 21.096

Category 15 15 1 23,370 23.37

Category 16 15 1 27,952 27.952

Category 17 15 1 35,280 17.64

23,370 23.37



HS-DSCH Category

Maximum Number of HS-DSCH Codes Received

Minimum Inter-TTI Interval

Maximum Number of Bits

Maximum Bit Rate

(Mbit/s)

Category 18 15 1 42,192 21.096

27,952 27.952

Category 19 15 1 35,280 35.280

Category 20 15 1 42,192 42.192

Category 21 15 1 23,370 23.370

Category 22 15 1 27,952 27.952

Category 23 15 1 35,280 35.280

Category 24 15 1 42,192 42.192

Category 25 15 1 23,370 46.740

Category 26 15 1 27,952 55.904

Category 27 15 1 35,280 70.560

Category 28 15 1 42,192 84.384

Note: In the "Maximum Number of Bits" column, the bits refer to bits received by the

HS-DSCH transport block during a TTI on the HS-DSCH.

In the preceding table,

UEs of category 13 and category 14 are only required to support 64QAM.

UEs of category 15 and category 16 are only required to support MIMO.

UEs of category 17 and category 18 support 64QAM and MIMO, but not simultaneously.

UEs of category 19 and category 20 support 64QAM+MIMO.

UEs of category 21 and category 22 support 16QAM+DC-HSPA \.

UEs of category 23 and category 24 support 64QAM+DC-HSPA.

UEs of category 25 and category 26 support 16QAM+MIMO+DC-HSPA.

UEs of category 27 and category 28 support 64QAM+MIMO+DC-HSPA.

Enhancement

In RAN11.0, UEs of category 13, category 14, category 15, category 16, category 17, and

category 18 are introduced.

In RAN12.0, UEs of category 19 to category 24 are introduced.

In RAN13.0, UEs of category 25 to category 28 are introduced.



Dependency


None


None




None

2.3.16 WRFD-01061015 HSDPA 1.8Mbit/s per User

Availability


Summary

This feature enables the HSDPA rate to reach a maximum of 1.8 Mbit/s for each user.

Benefits

This feature provides a higher peak bit rate and enhances the user experience.

Description

High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5

which can provide high speed service for the downlink. With this feature, the UE with

interactive or background service on the HS-DSCH can reach a peak rate of up to 1.8 Mbit/s

(MAC layer), greatly enhancing user experience.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



The UE should have the capability of HSDPA Category 12 (or later), that is, category 3, 4, 5,

6, 7, 8, 9, 10, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, or 28.


None

Dependency on CN

The CN must support a user rate of at least 1.8 Mbit/s.



2.3.17 WRFD-01061016 16 HSDPA Users per Cell

Availability


Summary

This feature enables a single HSDPA cell to support 16 HSDPA users simultaneously. If the

number of HSDPA users exceeds 16, the DCH is used for service provisioning.

Benefits

This feature provides operators with a maximum of 16 HSDPA users in an HSDPA capable

cell.

Description

A maximum of 16 HSDPA users can be served simultaneously in an HSDPA capable cell with

this feature.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None



Dependency on CN

None




Availability



Summary

This feature enables the HSDPA rate per user to reach a maximum of 3.6 Mbit/s.

Benefits


Description

HSDPA is an important feature of 3GPP Release 5 that can provide high speed service for

downlink. With this feature, the UE with interactive or background services on the HS-DSCH

can reach the peak bit rate up to 3.6 Mbit/s (MAC layer). Therefore, user experience is greatly

enhanced.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should have the capability of HSDPA Category 5 (or later), that is, category 5, 6, 7, 8,

9, 10, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, or 28.


None

Dependency on CN






2.3.19 WRFD-010629 DL 16QAM Modulation

Availability



Summary

Compared with the QPSK modulation, the 16QAM modulation is a higher-order downlink

data modulation mode. This feature enables the peak rate on the Uu interface to reach 14.4

Mbit/s.

Benefits

Provides higher peak bit rate HSDPA service for HSDPA users.

Description

The HS-PDSCH is used to carry the HS-DSCH data. The HS-PDSCH may use QPSK or

16QAM modulation symbols.

When the UE is in the unfavorable radio environment, the transmission can adopt the

low-order QPSK modulation mode and small transport blocks to ensure communication

quality.

When the UE is in good radio environment, the transmission can adopt the high-order

16QAM modulation mode and large transport blocks to achieve high peak rate.

The UE of category 10 can support a maximum of 15 HS-PDSCH codes and 16QAM

modulation mode. The supported peak rate on the air interface can reach 14.4 Mbit/s.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



The UE should have the capability of HSDPA besides Category 11 and Category 12:category

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28.


None

Dependency on CN

None



2.4 HSDPA Performance Improvement

2.4.1 WRFD-010631 Dynamic Code Allocation Based on NodeB

Availability


Summary

This feature implements dynamic code allocation on the NodeB side. The NodeB adjusts the

allocation of code resources in each TTI according to available code resources and scheduling

algorithms. This feature can further improve the utilization of code resources.

Benefits

This feature increases the resource utilization and system throughput.

Description

In NodeB-controlled dynamic HS-PDSCH code allocation, NodeB determines the

HS-PDSCH code use according to the code availability and scheduling algorithm in each 2ms

TTI. NodeB-controlled dynamic HS-PDSCH code allocation is more efficient and flexible

than RNC-controlled dynamic HS-PDSCH code allocation. The resource can be scheduled

and used in a short time in the NodeB, compared with signaling message transmission on the

Iub interface using RNC-controlled dynamic HS-PDSCH code allocation.

HS-DSCH transmission to multiple users in parallel during a single TTI requires more

HS-SCCH codes and more HS-PDSCH codes. Code multiplexing is adopted and is found

useful in cases where the NodeB has allocated more HS-PDSCH codes than what is supported

by the UE. For instance, the UE supports 5 codes and the NodeB has 10 codes available in a

single TTI. The code multiplexing can increase the resource utilization and system

throughput.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None




Availability


Summary


Benefits


Description



can reach the peak bit rate of up to 7.2 Mbit/s (MAC layer). Therefore, user experience is

greatly enhanced.

Enhancement

None

Dependency

Dependency on RNC



None

Dependency on NodeB

None

Dependency on UE

The UE should have the capability of HSDPA Category 7 (or later), that is, category 7, 8, 9,

10, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, or 28.


None

Dependency on CN



WRFD-010620 HSDPA 3.6Mbit/s per User

WRFD-010629 DL 16QAM Modulation


Availability


Summary

This feature enables a single HSDPA cell to simultaneously support 32 HSDPA users. If the

number of HSDPA users exceeds 32, the DCH is attempted for service provisioning.

Benefits

This feature provides HSDPA services at a higher peak bit rate for up to 32 users per cell.

Description

Up to 32 HSDPA users can be admitted to a HSDPA cell.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None




None

Dependency on CN

None



2.4.4 WRFD-010611 HSDPA Enhanced Package

Availability



Summary

This feature provides a series of enhanced HSDPA functions to meet the commercial

requirements of HSDPA services.

Benefits

Enhance the HSDPA performance by introducing the GBR-based QoS guarantee mechanism.

Enhance the HSDPA networking capability to meet HSDPA networking requirements.

Description

HSDPA enhanced package is introduced on the basis of WRFD-010610 HSDPA Introduction

Package, and provides enhancement features to meet the QoS and HSDPA network

requirements. Related features include:

EPF and GBR Based Scheduling

HSDPA State Transition

HSDPA DRD (Direct Retry Decision)

HS-DPCCH preamble support

Enhancement

In RAN6.0 and RAN10.0, this feature is enhanced. For details, refer to the enhancement of

the features in the package.

Dependency

Dependency on RNC

None



Dependency on NodeB

None

Dependency on UE

The UE should support the functions connected with HSDPA Enhanced package.


None

Dependency on CN

None



2.4.5 WRFD-01061103 Scheduling based on EPF and GBR

Availability


Summary

The operator can set different QoS parameters (such as priority, weight, and GBR) for

different users. Based on the QoS parameters, the EPF algorithm can accurately allocate

resources by proportion. This feature can make different users obtain accurate differentiated

experience.

Benefits

By satisfying quality requirements of different traffic types, the system capacity is maximized.

Description

Scheduling algorithm is to schedule UEs’ transmission every 2ms TTI. Considering a

compromise between the system capacity and user fairness, this feature provides four HSDPA

scheduling algorithms for the operators to choose from:

Max C/I

Round robin algorithm

Proportional Fair algorithm (PF)

Enhanced Proportional Fair algorithm (EPF)

1. In enhanced proportional fair algorithm (EPF), HSDPA carrying services are divided into

two categories: delay-sensitive and throughput-sensitive. Priority is given to delay-sensitive

services during schedule ordering.

2. During uncongested periods in the cell, the EPF algorithm (which is based on the PF algorithm) can fulfill the latency requirements of delay-sensitive services, and also provide



Guaranteed Bit Rate (GBR) to throughput-sensitive services. In this way fairness can be

effectively guaranteed between the user and a low QoS priority requirement service.

3. During uncongested periods in the cell after fulfilling the basic QoS requirements of every

user, the EPF algorithm can distribute surplus resources according to Scheduling Priority

Indicator (SPI) weight, allowing throughput-sensitive services to attain higher speeds. In

order to satisfy more users, once BE services have achieved Happy Bit Rate (HBR), the

scheduling priority is reduced significantly, thereby letting the resources to be distributed

among other users. HBR can be configured by the operator.

4. When a cell is uncongested, EPF algorithm will give priority to delay-sensitive services

during resource distribution, thereby guaranteeing the networks basic traffic QoS. In case of

surplus resources, remaining resources will be assigned to throughput-sensitive services.

Moreover, the services will be provided with GBR speed services according to the traffic’s

SPI sequence.

5. SPI weight depends on the traffic class, user priority and traffic handling priority (THP).

6. Users can be divided into Gold, Silver and Bronze categories, all mapped by ARP, which

are configurable. Moreover, uplink and downlink GBR configuration is also based on user

priority, and is used for HSDPA scheduling algorithms. Through this feature, HSDPA’s QoS

guarantee mechanism is enhanced.

7. EPF algorithm was introduced in RAN5.1. Based on ARP, SPI mapping also receives

further optimization. Moreover, the minimum throughput of GBR services including BE

services can be configured. Minimal limitations during the scheduling process need to receive

strict assurances.

Enhancement

In RAN6.0, the GBR for Gold/Silver/Bronze users can be configured, this enhances QoS

guarantee mechanism.

In RAN10.0, the scheduling function concerning the signaling RB is added to the EPF

algorithm. In addition, the traffic is classified into delay-sensitive services and

throughput-sensitive services.

In RAN11.0 EPF algorithm increased the scheduling capabilities of CELL_FACH’s status

queue, moreover it introduced HBR, in order to improve user satisfaction.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None



Dependency on CN

None




Recommend to deploy this feature with UMTS Differentiated QoS Service

2.4.6 WRFD-01061111 HSDPA State Transition

Availability


Summary

This feature enables the handover between the DCH and HS-DSCH and makes it possible for

the UE to enjoy the high-speed service. When the UE is in the inactive state, this feature

enables the UE to be handed over to the CELL_FACH to save the system resources when

there is no data transferred for a long time.

Benefits

This feature supports the switching between DCH and HS-DSCH and makes it possible for

the UE to enjoy the high speed service. Meanwhile, the system resource is saved by moving

the UE to CELL_FACH when there is no data transferred for a long time.

Description

This feature enables the UE to perform a state transition between CELL_DCH (HS-DSCH),

CELL_DCH, and CELL_FACH. With the introduction of HSDPA, a new RRC state of

CELL_DCH (HS-DSCH) is provided. The following figure shows the RRC state relationship.

CELL_PCH CELL_FACH

CELL_DCH

CELL_DCH(with HS-DSCH)

Channel Switching Between CELL_DCH (HS-DSCH) and CELL_FACH

If the HS-DSCH is carrying BE service or streaming service and there is no data to be sent for a long time, the transition from CELL_DCH (HS-DSCH) to CELL_FACH is



triggered. Actually, this feature is supported in the same way as the state transition from

CELL_DCH to CELL_FACH.

A UE on CELL_FACH will be switched to CELL_DCH (HS-DSCH) due to a higher bit

rates request on downlink.

Channel Switching Between CELL_DCH (HS-DSCH) and CELL_DCH

The channel switching between HS-DSCH and DCH is mainly triggered by mobility

management. The transition from CELL_DCH to CELL_DCH (HS-DSCH) can be

triggered by periodical retry and the traffic volume

The mobility triggering is described in WRFD-01061006 HSDPA Mobility Management

feature.

The traffic volume report that indicates a higher bit service needs to be transferred. The

UE in CELL_DCH will be transferred to CELL_DCH (HS-DSCH) if it is an HSDPA

capable cell and the UE has HSDPA capability. This feature enables the UE to enjoy high

speed service.

If an HSDPA capable UE is set up on the DCH for BE services for some reasons, for

example, the admission of the HS-DSCH fails, then a periodical retry mechanism is

triggered, allowing the UE to enter the CELL_DCH (HS-DSCH). The retry time is

configurable.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None







2.4.7 WRFD-01061112 HSDPA DRD

Availability


Summary

This feature enables HSDPA suitable service to be established on the HS-DSCH cell as much

as possible if a UE is HS-DSCH capable, achieving better service performance.

Benefits

This feature enables HSDPA suitable service to be established on the HS-DSCH cell as much

as possible if a UE is HS-DSCH capable, achieving better service performance.

Description

This feature enables HSDPA suitable service be mapped onto the HS-DSCH as soon as

possible if a UE is HS-DSCH capable.

When a UE camps on an R99-concentric cell and requests for a streaming or BE service

which is HSDPA suitable, the service will be mapped onto the HS-DSCH of the HSDPA

capable cell if allowed by the HSDPA admission control.

In the case a UE camps on an HSDPA cell and requests for a streaming or BE service which is

compatible with HSDPA, if the HSDPA admission fails on the current cell but another

HSDPA capable cell which has the same center as the current cell is available, then the service

will be mapped onto the HS-DSCH of the HSDPA capable cell that has the same center as the

current cell if it is allowed by the HSDPA admission control.

An HSDPA capable UE has an HSDPA suitable service but is currently mapped onto the DCH

due to some limitations (for example, the current cell does not support HSDPA or the HSDPA

admission control fails). If the UE moves around and the best cell begins to support HSDPA,

the service will be re-mapped onto the HS-DSCH of the best cell if allowed by the HSDPA

admission control. If the best cell does not support HSDPA, but there is an HSDPA capable

concentric cell and the HSDPA admission control is allowed, the service will be re-mapped

onto the HS-DSCH of that concentric cell.

An HSDPA capable UE has an HSDPA suitable service, but is currently mapped onto the

CELL_FACH or CELL_DCH (DCH only). In addition, there is a data transmission request on

the downlink, and the concentric cell supports HSDPA instead of the current cell. In this case,

the service will be re-mapped onto the HS-DSCH of that HSDPA capable cell.

Enhancement

In RAN5.1, in any condition, if an HSDPA capable UE has an HSDPA suitable service, but is

currently not mapped onto the HS-DSCH, and if the current best cell or the concentric cell of

the best cell is HSDPA capable, the RNC will periodically attempt to re-map the service onto

the HS-DSCH until the service retry succeeds.

In RAN12, to reduce the call drop rate, a punishment mechanism is implemented. The D2H

DRD is forbidden for the users which encountered DRD failure at the RAB Setup procedure.

This mechanism can be configured by operator.



In RAN12 Periodically DRD based on measurement is introduced, RAB can be setup in the

original DCH cell, and by following inter frequency measurement to chose a HSDPA cell to

perform DRD, reduce the drop rate caused by blind handover. The Periodically DRD based on

blind handover or based on measurement can be selected by operator.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



WRFD-020400 DRD Introduction Package

2.4.8 WRFD-01061113 HS-DPCCH Preamble Support

Availability


Summary

This feature enables the transmission of dedicated preamble subframes before ACK/NACK

subframes are transmitted on the HS-DPCCH, improving transmission reliability.

Benefits

HS-DPCCH preamble mode technology enables the NodeB to distinguish between DTX and

ACK/NACK without requiring high ACK transmit power

The uplink coverage gain is about 0.2 dB to 0.9 dB with different accompanying DPCH

services.



Description

The High Speed Dedicated Physical Control Channel (HS-DPCCH) carries uplink feedback

signaling related to downlink HS-DSCH transmission. The HS-DSCH-related feedback

signaling consists of Hybrid-ARQ Acknowledgment (HARQ-ACK) and Channel-Quality

Indication (CQI).

If UE detects the HS-SCCH control message, it will reply with an ACK or NACK message

based on the result of the decoding and it will inform the sender of the result to further request

retransmissions.

If the UE does not detect the HS-SCCH control message, it will reply with a DTX message.

To reduce the probability that the NodeB decodes this DTX as ACK by mistake, the transmit

power of the ACK/NACK message should be high.

Huawei supports HS-DPCCH preamble mode detection. The proposed enhancement is to

send special Preamble sub-frames in the uplink HS-DPCCH before an ACK/NACK

sub-frame. This method reduces the probability of a DTX->ACK error in the NodeB, because

the NodeB has to decode at least two successive timeslots erroneously before the earlier

mentioned scenario can take place. Due to the prior preamble information detection, the same

performance of the HARQ-ACK field detection can be sustained with lower power.

N

HS-DPCCH

HS-DSCH

HS-SCCH

ACK or NACK

Data Packet

N N+1 N+2 N+3

N N+1 N+2 N-1

PRE

PREAMBLE transmitted in sub-frame N-1 to indicate reception of relevant signalling information in sub-frame N on HS-SCCH

Normal ACK/NACK to indicate correct or incorrect decoding of packet

POSTAMBLE transmitted in sub-frame N+1 (unless a packet is correctly decoded from sub-frame N+1 on the HS-DSCH, or control information is detected in sub-frame N+2 on the HS-SCCH)

N+1 N+2 N+3

POST

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

This feature also depends on the NodeB hardware:




EULP, or EULPd board.

The BBU3806 needs to configure the EBBC or EBBCd board.

The BBU3900 needs to configure the WBBPb, WBBPd, or WBBPf board.

Dependency on UE

The UE should have the capability of HSDPA Category 6 (or later) and support this feature.


None

Dependency on CN

None



2.4.9 WRFD-010630 Streaming Traffic Class on HSDPA

Availability



Summary

This feature enables the streaming services to be mapped onto the HS-DSCH, improving the

utilization of cell resources.

Benefits

This feature enables the system to support a higher speed RAB of PS streaming service.

Description

This feature enables the streaming service to be mapped onto the HS-DSCH if a UE is

HSDPA capable. The system sets a switch to enable or disable the feature that streaming

service is mapped onto the HS-DSCH. A service rate threshold is also set only when the

requested service bit rate is higher than the threshold. At this time, the requested service can

be mapped onto the HS-DSCH. Otherwise, it will be mapped onto DCH. The service rate

threshold can be configured by the operator.

When the streaming service is carried on the HS-DSCH, the maximum downlink bit rate can

reach 384 kbit/s.

When a UE has a streaming service on the HS-DSCH, it can use another CS RAB or another

PS RAB simultaneously. One HSDPA BE RAB and one HSDPA streaming RAB can be used by one UE simultaneously if the UE capability permits.



Enhancement

In RAN5.1, GBR of streaming traffic is used to estimate whether the maximum available

power for HSDPA can satisfy the requirement of streaming service and

interactive/background service in admission control in RAN5.1.

The HSDPA scheduling algorithm also considers the GBR information of streaming traffic so

that all HSDPA streaming services are guaranteed when the bit rate is not less than GBR.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



2.4.10 WRFD-010650 HSDPA 13.976Mbps per User

Availability



Summary


Benefits


Description





can reach the peak bit rate up to 13.976 Mbit/s (MAC layer). Therefore, user experience is

greatly enhanced.

Enhancement

None

Dependency

Dependency on RNC

This feature requires WFMRc board in BSC6800.

Dependency on NodeB

None

Dependency on UE

The UE should have the capability of HSDPA Category 10, 13 (or later), that is, category 10,

13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, or 28.


None

Dependency on CN



WRFD-010621 HSDPA 7.2Mbit/s per User

2.4.11 WRFD-010651 HSDPA over Iur

Availability



Summary

This feature enables HSDPA services to be carried on the Iur interface and provides

continuous HSDPA services for UEs moving between RNCs.

Benefits

HSDPA over Iur provides continuous HSDPA services for mobile users moving between

RNCs. It enlarges the range of HSDPA services to the RNCs that have Iur connections with a

certain RNC.



Description

HSDPA over Iur is the scenario where the HSDPA serving cell is carried at the DRNC. The

feature includes HSDPA service management over Iur, HSDPA mobility management over Iur,

and so on.

HSDPA service management over Iur

HSDPA service management over Iur refers to HSDPA service setup, modification,

release, and state transition.

When the UE is in the CELL_DCH state and the DRNC cell is in the active set or the UE

is in the CELL_FACH state and camps in a DRNC cell, the HSDPA service can be setup,

modified, and released over Iur.

The service over Iur can be reconfigured between HSDPA and R99 with UE state

transition between CELL_DCH and CELL_FACH.

HSDPA mobility management over Iur

HSDPA mobility management over Iur includes hard handover, cell update (caused by

radio link failure), and serving cell change.

The process is similar to the corresponding mobility management described in

WRFD-01061006 HSDPA Mobility Management, and the difference is that the cells

change between RNCs.

HSDPA static relocation

If the HSDPA service is over Iur and the radio links are provided only by the target RNC, the

static relocation can be triggered by Iur congestion.

HSDPA service pre-emption at the DRNC

When the new HSDPA service is not admitted to access the network, the CRNC may trigger a

pre-emption of other HSDPA services with lower priorities. If the CRNC is the DRNC, it

sends RADIO LINK PREEMPTION REQUIRED INDICATION to the SRNC and the SRNC

releases the HSDPA services indicated in the RADIO LINK PREEMPTION REQUIRED

INDICATION.

Other functions of this feature, such as HSDPA power offset adjustment over Iur and

HSDPA radio link parameter update over Iur are similar to the processes realized on the

Iub interface.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None




The neighboring RNC should also support HSDPA over Iur.

Dependency on CN

None



2.4.12 WRFD-010652 SRB over HSDPA

Availability



Summary

SRB over HSDPA enables the DL SRBs of multiple UEs to be carried over HSDPA through

the FDPCH multiplexing technology, reducing the consumption of DL code resources and the

call setup delay.

Benefits This feature provides a higher signaling rate and reduces the call process delay.

Compared with the scenario where the SRB is carried on the DCH, code resources are

saved and cell load is reduced when the SRB is carried on HSDPA.

Description

The signaling over the SRB is delay sensitive and irregular. In some cases, the code may be

limited prior to power and the cell capacity is affected. Therefore, it is more appropriate to set

up SRB over the HSDPA rather than the DCH. When compared with SRB over DCH, SRB

over HSDPA and F-DPCH multiplexing can save code resources.

SRB over HSDPA can be applied during the RRC connection setup procedure or other

procedures such as mobility management.

If the SRB is set up over the DCH, it can be reconfigured to the mapping on HSDPA in some

cases, for example, the target cell of handover supports HSDPA while the source cell does not.

Inversely, the SRB mapping on HSDPA can also be reconfigured to the mapping on DCH if

the target cell of handover does not support HSDPA.

SRB over HSDPA is configurable. The operator can also configure whether SRB over HSDPA

is applied to RRC connection setup or not.

Enhancement

Enhanced F-DPCH is supported in RAN11.0.



Dependency

Dependency on RNC

None

Dependency on NodeB

This feature depends on the NodeB hardware:

The BTS3812E, BTS3812A and BTS3812AE must be configured with EBBI board,

EBOI board or EDLP board.

The BBU3806 needs to configure EBBC or EBBCd board.


Dependency on UE

The UE should support FDPCH/EFDPCH.


None

Dependency on CN

None




Availability


Summary

This feature enables a single HSDPA cell to simultaneously support 64 HSDPA users. If the

number of HSDPA users exceeds 64, the DCH is attempted for service provisioning.

Benefits

This feature provides HSDPA services at a higher peak bit rate for up to 64 users per cell.

Description

Up to 64 HSDPA users can be admitted to a HSDPA cell.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-010622 32 HSDPA Users per Cell

HSUPA Introduction and HSUPA 1.44 Mbit/s per User

2.4.14 WRFD-030010 CQI Adjustment Based on Dynamic BLER Target

Availability


Summary

In live networks, channel quality fluctuates constantly. To achieve the highest possible

downlink throughput, an appropriate Block Error Rate (BLER) target is required.

This feature helps select the optimum BLER target based on downlink channel quality

fluctuations in real time.

Benefits

This feature increases the downlink throughput in HSDPA cells by up to 10%.

Description

In radio environments, many factors affect downlink throughput, such as multipath fading and

UE movement speeds. To achieve the highest possible downlink throughput for HSDPA users

in an ever-changing radio environment, the NodeB needs to dynamically adjust the BLER

target. This feature enables the NodeB to do so. After adjusting the BLER target, the NodeB

can then adjust the Channel Quality Indicator (CQI) to increase the downlink throughput.

This feature supports CQI adjustment based on dynamic BLER target for non-MIMO mode UE in RAN13.0 and RAN14.0 when HSDPA is both deployed in network side and UE side.



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

BTS3812E and BTS3812AE must be configured with the EBBI, EBOI, or EDLP board.

BBU3806 must be configured with the EBBC or EBBCd board.

BBU3900 must be configured with the WBBPb, WBBPd, or WBBPf board.

Dependency on UE

None


None

Dependency on CN

None




Recommend to deploy this feature with UMTS Downlink Capacity Improvement Service

2.4.15 WRFD-030011 MIMO Prime

Availability


Summary

MIMO Prime is one of Huawei's proprietary performance technologies. Based on

dual-transmission RF modules, it can greatly improve spectrum utilization and increase

network capacity.

Benefits

In the scenario of the large traffic in down link, MIMO Prime can increase the capacity of the

cell in which MIMO has not been implemented by about 5% to 10%. The increase in the

overall cell throughput helps to greatly improve the experience of users in medium and bad

radio conditions. The trial test shows that this feature can increase the throughput of the single

user in medium and bad radio conditions by about 15% and 20% respectively.



MIMO Prime does not depend on the UE and is applicable to various services including

HSDPA and 64QAM. Furthermore, it does not affect the performance of traditional UEs.

When the penetration of MIMO-capable UEs is low, MIMO Prime can effectively protect the

investments of operators who have already deployed MIMO-capable RF modules but haven’t

implemented MIMO. As the number of MIMO-capable UEs increases, operators can

gradually enable the MIMO feature to achieve the maximum benefits in terms of capacity and

user experience.

Description

MIMO Prime is based on Virtual Antenna Mapping (VAM), which applies matrix processing

to the original signal before sending it over the antennas. The original signal is allocated to the

two antennas with equal power. After VAM is enabled, each signal is split into two signals.

This results in a certain phase difference in the two received signals, which affects the

strength of the signals after they are combined. MIMO Prime supports automatic phase

adjustment based on the signal environment, thereby achieving increased UE throughput by

enhancing the reception quality of the UE.

Figure2-6-14-1 Principles of MIMO Prime

Enhancement

None

Dependency


None


This feature is supported only by the 40W RRU3801C, RRU3804, RRU3806, RRU3808,

WRFU, RRU3805, WRFUd, RRU3828, RRU3829, RRU3928, RRU3929, MRFUd,

MRFUe, as well as the RRU3908 V1 operating in 850 MHz, 900 MHz, and 1900 MHz.

For RF modules providing only one transmit channel, two such RF modules need to be

interconnected to support this feature.


The BTS3812E and BTS3812AE do not support this feature.



The DBS3800 does not support this feature.

RRU3908 V2 and MRFU V2 modules support this feature from RAN14.0.0




None

Dependency on UE

None



2.4.16 WRFD-030004 Adaptive Configuration of Typical HSPA Rate

Availability


Summary

This feature is applicable only to PS best effort (BE) services over High Speed Packet Access

(HSPA) channels. This feature enables the RNC to calculate the actual maximum traffic rate

based on the maximum bit rate (MBR) assigned by the CN.

Benefits

This feature enables mobile operators to quickly and flexibly provide services with various

traffic rates, facilitating new market expansion to increase revenue.

Description

To meet market requirements, mobile operators need to provide services with various traffic

rates over HSPA. Typical traffic rates configured at the RNC, however, are fixed and

separated, and may be inconsistent with the MBR required by mobile operators.

Without this feature, the RNC selects a typical traffic rate closest to the MBR assigned by the

CN if a traffic rate inconsistency occurs between the RNC and CN. This rate, not the MBR, is

then used for calculating the actual maximum traffic rate of the UE. As a result, the rates

propagated by mobile operators are unavailable for UEs, affecting brand image.

With this feature, the RNC can use the MBR assigned by the CN to calculate the actual

maximum traffic rate when the MBR cannot be mapped onto any typical traffic rate.

Note that the MBR assigned to UEs with an HSUPA TTI of 10 ms must be higher than 32

kbit/s and the MBR assigned to UEs with an HSUPA TTI of 2 ms must be higher than144 kbit/s. Otherwise, these UEs cannot achieve traffic rates higher than corresponding MBRs.



Enhancement

None

Dependency


None


The BTS3812E, BTS3812A, and BTS3812AE must be configured with the EBBI, EBOI,

EULP+EDLP, or EULPd+EDLP boards. Downlink services must be established on the

EBBI, EBOI, or EDLP board.

The DBS3800 must be configured with the EBBC or EBBCd board. Downlink services

must be established on the EBBC or EBBCd board.

The 3900 series base stations must be configured with the WBBPb, WBBPd or WBBPf

board. Downlink services must be established on the WBBPb, WBBPd or WBBPf board.


None


None


None




2.4.17 WRFD-140221 HSDPA Scheduling Based on UE Location

Availability


Summary

Developed on the basis of the EPF algorithm, this feature considers UE locations as the

criterion for adjusting HSDPA scheduling weights. This feature gives more scheduling

opportunities to UEs close to the NodeB and increases the cell throughput on the downlink.

Benefits

This feature increases HSDPA throughput for UEs close to the NodeB and thereby increases

the average throughput of the cell. The amount of the feature’s gain is based on the actual

services and the users’ location in the cell.



Description

Huawei provides five HSDPA scheduling algorithms: maximum C/I (MAXCI), round-robin

(RR), proportional fair (PF), enhanced proportional fair (EPF), and EPF based on UE location

(EPF_LOC). They are detailed as follows:

MAXCI

This algorithm only considers the radio channel quality and sequences all UEs in a cell

by carrier-to-interference ratio (C/I). This algorithm ensures a high throughput for the

cell but cannot ensure equity among UEs.

RR

UEs are sequenced in descending order of waiting time in the MAC-hs queue. UEs have

equal scheduling opportunities but the cell capacity decreases.

PF

UEs are sequenced in descending order of R/r, where R is the maximum rate

corresponding to the CQI reported by a UE and r is the average rate of the UE at the

MAC-hs layer. This algorithm provides each UE with an average throughput that is

proportionate to the maximum rate corresponding to the CQI reported by the UE. This

algorithm compromises cell capacity to increase equity among UEs.

EPF

Developed on the basis of the PF algorithm, the EPF algorithm classifies services into

different types. While ensuring guaranteed bit rates (GBRs), the EPF algorithm allocates

resources based on scheduling priority indicators (SPIs). This balances service

differentiation with equity among UEs.

EPF_LOC

Developed on the basis of the EPF algorithm, the EPF_LOC algorithm considers UE

locations as HSDPA scheduling weights. While ensuring GBRs, the EPF_LOC algorithm

gives more scheduling opportunities and a higher throughput to UEs close to the NodeB.

In the EPF_LOC algorithm, the more weight given to UE locations, the more significantly

UEs at different distances from the NodeB are differentiated between, the more scheduling

opportunities and the higher throughput UEs close to the NodeB have, the fewer scheduling

opportunities and the lower throughput UEs far from the NodeB have. It is recommended that

GBRs be configured for all UEs to ensure service quality for UEs at cell edges.

Enhancement

None

Dependency


None


All 3900 series base stations support this feature. To support this feature, the 3900 series

base stations must be configured with the WBBPb, WBBPd, or WBBPf board.

All DBS3800 series base stations support this feature. To support this feature, the DBS3800 series base station must be configured with the EBBC or EBBCd board.



The BTS3812E/BTS3812A/BTS3812AE supports this feature. To support this feature,

the BTS3812E/BTS3812A/BTS3812AE must be configured with the EBBI, EDLP or

EBOI board.


None


None


None





Recommend to deploy this feature with UMTS Downlink Capacity Improvement Service and

UMTS Differentiated QoS Service

2.5 HSPA+ Prime Service

2.5.1 WRFD-010680 HSPA+ Downlink 28Mbit/s per User

Availability



Summary

This feature enables the HSPA+ MIMO rate per user to reach a maximum of 28 Mbit/s. This

feature enhances user experience for high-speed data services.

Benefits This feature improves the frequency utilization and increases the maximum downlink

rate.

This feature can provide end users with high-speed data experience.

Description

HSPA+ is introduced in 3GPP Release 7 to provide high-rate data services. With this feature,

the downlink peak rate increases from 13.976 Mbit/s per user in R6 to 28 Mbit/s per user

(MAC layer).



Enhancement

DC-HSDPA is available from RAN12.0. With DC-HSDPA and downlink 16QAM, the

downlink peak rate also can increases from 13.976 Mbit/s per user in R6 to 28 Mbit/s per user

(MAC layer).

DB-HSDPA is available from RAN15.0. With DB-HSDPA, the downlink peak rate can reach

28 Mbit/s per user.

Dependency

Dependency on RNC


Dependency on NodeB

The BTS3812E, BTS3812A, and BTS3812AE must be configured with the EBBI, EBOI

or EDLP board.



For the RF part, the RF module of Huawei NodeB supports one TX channel each, and

two interconnected RF modules can provide two TX channels to support 2 x 2 MIMO

Dependency on UE

The UE category must support cat16, cat18 (or later).


None

Dependency on CN

The CN must support a user rate of at least 28 Mbit/s.


WRFD-010684 2*2 MIMO

WRFD-010650 HSDPA 13.976Mbps per User

or

WRFD-010696 DC-HSDPA


or

WRFD-150209 DB-HSDPA



Recommend to deploy this feature with UMTS HSPA+ Introduction Service




Availability



Summary

This feature enables the HSPA+ 64QAM rate per user to reach a maximum of 21 Mbit/s. With

this feature, users can enjoy high-speed data experience.


rate.

This feature can provide end users with high-speed data experience.

Description

HSPA+ is introduced in 3GPP Release 7 to provide high speed data services. With this feature,

the downlink peak rate increases from 13.976 Mbit/s per user in R6 to 21 Mbit/s per user

(MAC layer).

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

To support this feature, the following configurations are required:


or EDLP board.

The BBU3806 needs to configure the EBBC or EBBCd board.

The BBU3900 needs to configure the WBBPb, WBBPd, or WBBPf board.

Dependency on UE

The UE category must support cat 14,18,20,24 or 28


None

Dependency on CN





WRFD-010683 Downlink 64QAM




2.5.3 WRFD-010685 Downlink Enhanced L2

Availability



Summary

Downlink Enhanced L2 supports the variable PDU size, which eliminates the contradictions

between the high-speed transmission that requires a large PDU size and the cell-edge

coverage that requires a small PDU size. This feature enables the dynamic adjustment of the

PDU size to improve the transmission efficiency on the Iub and Uu interfaces and increase the

cell edge throughput and coverage radius.

Benefits

This feature is a prerequisite of the 64QAM, MIMO, and enhanced CELL_FACH, which also

improves the transmission efficiency on the Iub and Uu interfaces.

Description

Downlink Enhanced L2 supports the variable PDU size, which eliminates the contradictions

between the high-speed transmission that requires a large PDU size and the cell-edge

coverage that requires a small PDU size. In addition, enhanced L2 reduces excessive overhead

caused by the fixed PDU size, and improves the transmission efficiency on the Iub and Uu

interfaces.

Downlink Enhanced L2 is a prerequisite for 64QAM, MIMO and enhanced CELL_FACH. It

removes the restrictions on the RLC window for users whose transmission rate is more than

14 Mbit/s. At the cell edge, small PDU size requires relative low SNR, better service coverage

and throughput will be attained.

Enhancement

None

Dependency

Dependency on other RAN software functions




Dependency on UE

The UE must be Release 7 (or later) UE and support this feature.




Availability

This feature is available from RAN12.0. It is introduced in 3GPP Release 8.

Summary

This feature enables the peak rate of the data service over HSPA+ to reach 42 Mbit/s per user.


rate.

This feature provides end users with high-rate data services.

Description

HSPA+ is introduced in 3GPP Release 7 to provide high-rate data services. With the

2*2MIMO+64QAM or 64QAM+DC HSDPA technologies introduced in R8 and the enhanced

performance of relevant NEs, the downlink peak rate per user reaches up to 42 Mbit/s.

TCP protocol is widely used in data transmission. As a file is being downloaded, the TCP

acknowledgment is sent in uplink. The higher the rate of download is, the larger the

bandwidth is required in uplink. If the download rate reaches up to 42 Mbit/s, the rate of TCP

acknowledgment in uplink is much higher than 384 kbit/s which is the highest rate supported

by DCH. HSUPA bearer is required to provide high bandwidth in uplink to transmit TCP

acknowledgment in time. DL 42 Mbit/s per user can be supported only in case of HSUPA

being used.

Enhancement

DB-HSDPA is available from RAN15.0. With DB-HSDPA and downlink 64QAM, the

downlink peak rate can reach 42 Mbit/s per user.

Dependency

Dependency on RNC

To enable this feature on a BSC6900, you are advised to configure a DPUe board in the

BSC6900 to support more peak-rate UEs.

Dependency on NodeB



The BTS3812E, BTS3812A, or BTS3812AE must be configured with the EBBI, EBOI

or EDLP board.

The BBU3806 must be configured with the EBBC or EBBCd card.


For the RF part which supports only one TX channel, two interconnected RF modules

can provide two TX channels to support 2 x 2 MIMO. In terms of RF modules including

2 Tx channels, no additional RF modules is required for 2*2MIMO.


WRFD-010681 HSPA+ Downlink 21Mbit/s per User plus WRFD-010696 DC-HSDPA plus

WRFD-010612 HSUPA Introduction Package,

or

WRFD-010681 HSPA+ Downlink 21Mbit/s per User plus WRFD-010680 HSPA+ Downlink

28Mbit/s per User plus WRFD-010693 DL 64QAM+MIMO plus WRFD-010612 HSUPA

Introduction Package

or

WRFD-010681 HSPA+ Downlink 21Mbit/s per User plus WRFD-150209 DB-HSDPA plus

WRFD-010612 HSUPA Introduction Package,


The UE should support category of 21(or later), that is, category: 21, 22, 23, 24, 25, 26, 27, or

28.

Dependency on CN

CN needs to support sending RAB assignment with relate data rate.



2.5.5 WRFD-010683 Downlink 64QAM

Availability



Summary

Compared with the 16QAM modulation, the 64QAM modulation is a higher-order downlink

data modulation mode. This feature enables the peak rate on the Uu interface to reach 21

Mbit/s.

Benefits

Downlink 64QAM increases the peak rate per user and improves the local cell capability.



Operators attach great importance to data service and regard it as a growing point for profits.

Many consulting companies predict that the data traffic volume will grow rapidly and

accordingly raise higher requirements to the network throughput. If the bandwidth remains

unchanged, 64QAM will increase the average throughput of the system by 7% to 16% and

further improves the spectral efficiency of the system. In this way, the system provides users

with higher throughput and ultimately increases operators' profits on the per bandwidth basis.

On the other hand, 64QAM also raises the peak rate per user and provides a higher download

data rate for users. This enhances not only user experience but also operators'

competitiveness.

Description

3GPP R5 introduces 16QAM to increase the peak rate per user and expands the system

capacity, whereas 64QAM introduced in 3GPP R7 protocols is a further enhancement of

16QAM.

With downlink 64QAM, higher order modulation technology than 16QAM can be used when

the channel is of higher quality. Theoretically, 64QAM supports a peak data rate of 21 Mbit/s

and at the same time increases the average throughput of the system. Simulation shows that

compared with 16QAM, 64QAM can increase the average throughput by 7% and 16%

respectively in macro cell and in micro cell, if the UEs in the cells use the type 3 receivers.

The 3GPP R7 protocols define the categories of the UEs that support 64QAM, and add the

information elements (IEs) that support 64QAM in the reporting of local cell capability. The

RNC determines whether the RL between the NodeB and the UE supports 64QAM according

to the local cell capability reported by the NodeB and the UE capability. If the RL supports

64QAM, the MAC-hs scheduler of the NodeB determines every 2 ms whether to use 64QAM

according to the following aspects:

Channel Quality Indicator (CQI) reported by the UE

HS-PDSCH code resources and power resources of the NodeB

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB





Dependency on UE

The UE category must support 64QAM. That is, the UE must belong to category

13,14,17,18,19,20,23, 24, 27, 28, as specified by the 3GPP protocols.




None

Dependency on CN

None



WRFD-010685 Enhanced L2



2.5.6 WRFD-010684 2×2 MIMO

Availability



Summary

Based on space dimension resources, MIMO uses the multi-antenna technology at the

transmit end and receive end. This feature can double the transmission capacity of the

wireless communication system in a high SNR environment without the transmit power

added.

Benefits

2x2 MIMO increases the average throughput and peak rate of the cell. In the case of

unchanged bandwidth, 2x2 MIMO increases the average throughput of the system by 14% to

23%. Theoretically, the peak rate per 2X2 MIMO user can be twice the original peak rate. In

addition, MIMO has gains even under lower geographical factors (G = Ior/Ioc) and have more

gains under higher Ior/Ioc. From the service point of view, MIMO has a similar driving force

to 64QAM.

Description

2x2 Multiple Input Multiple Output (MIMO) uses two transmit antennas in the NodeB to

transmit orthogonal (parallel) data streams to the two receive antennas at the UEs. Using two

antennas and additional signal processing at the receiver and the transmitter, 2x2 MIMO can

increase the system capacity and double user data rates without using additional bandwidth.

2x2 MIMO adopts different modes in the 3GPP protocols, with QPSK and 16QAM in R7, and

later with 64QAM in R8. With dual-stream dual-antenna mode and 16QAM modulation, the

peak data rate per user is doubled to 28 Mbit/s and the average throughput of the system is

enhanced.

The 3GPP R7 protocols define the categories of the UEs that support MIMO, and add the

information elements (IEs) that support MIMO in the reporting of local cell capability. The



RNC determines whether the RL between the NodeB and the UE supports MIMO according

to the local cell capability and UE capability reported by the NodeB. If the RL supports

MIMO, the MAC-hs scheduler of the NodeB determines every 2 ms whether to use MIMO

according to the following aspects:

Channel Quality Indicator (CQI) reported by the UE

Precoding Control Indication (PCI)

HS-PDSCH code resources and power resources of the NodeB

For MIMO and HSDPA Co-carrier scenario, refer to WRFD-010700 Performance

Improvement of MIMO and HSDPA Co-carrier.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB





For the RF part, the RF module of Huawei NodeB supports one TX channel each and two

interconnected RF modules can provide two TX channels to support 2 x 2 MIMO.

20W RRU3801c can only support MIMO by using together with the same module (20W

RRU3801c)

Dependency on UE

The UE must belong to category 15 (or later), that is, category 15, 16, 17, 18, 19, 20, 21, 22,

23, 24, 25, 26, 27, or 28.


None

Dependency on CN

None



WRFD-010685 Downlink Enhanced L2






2.5.7 WRFD-010693 DL 64QAM+MIMO

Availability


Summary

MIMO and 64QAM are introduced in 3GPP Release 7 and can only be used independently. In

3GPP Release 8, however, MIMO and 64QAM can be used in combination to increase the

peak throughput of a single user.

Benefits

With 64QAM+MIMO, the peak throughput of a single user can reach 42 Mbit/s, compared to

28 Mbit/s with 16QAM+MIMO or 21 Mbit/s with 64QAM only.

Description Channel bearer

The SRB, CS service, IMS signaling, and PS conversational services are not carried on

MIMO, 64QAM, or MIMO+64QAM because the data flow is small and the gain is

insignificant. The PS streaming service, PS interactive service, PS background service,

and the combined services with previous services can be carried on MIMO+64QAM.

Scheduling

The user scheduling based on a new extended CQI table for the MIMO+64QAM user is

supported.

Mobility management

The UE can be handed over from an MIMO+64QAM capable cell to an MIMO+64QAM

incapable cell and the MIMO+64QAM falls back. If UE moves in the opposite direction,

the MIMO+64QAM can be reconfigured to the UE after handover.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The HBBI and HDLP of the BTS3812E and BTS3812AE do not support

64QAM+MIMO. To support 64QAM+MIMO, the EBBI or EDLP must be configured.



The BBU3806 of the DBS3800 does not support 64QAM+MIMO. To support

64QAM+MIMO, the EBBC or EBBCd board must be configured.

The 3900 series base stations support 64QAM+MIMO when the WBBPb, WBBPd or

WBBPf board is configured.

Dependency on UE

The UE must support HS-DSCH category 19, 20, 23, 24, 27 or 28.


None

Dependency on CN

None


WRFD-010683 Downlink 64QAM

WRFD-010684 2×2 MIMO



2.5.8 WRFD-010698 HSPA+ Uplink 11.5Mbit/s per User

Availability


Summary

This feature provides an uplink peak rate of 11.5 Mbit/s for a single user through uplink

16QAM and E-DPCCH boosting or DC-HSUPA.

Benefits

This feature improves spectrum efficiency and increases the peak uplink rate, allowing end

users to enjoy high-speed uplink data services.

Description

This feature utilizes 16QAM (introduced in 3GPP Release 7) and E-DPCCH boosting to

increase the uplink peak rate from 5.74 Mbit/s to 11.5 Mbit/s.

Enhancement

None



Dependency


None


For uplink 16QAM+E-DPCCH boosting,

The BTS3812E, BTS3812A and BTS3812AE must be configured with the EULPd board.



For DC-HSUPA,

The BTS3812E, BTS3812A and BTS3812AE must be configured with the EULP or

EULPd board.

The DBS3800 must be configured with the EBBC or EBBCd board.


board.


For uplink 16QAM+E-DPCCH boosting,

WRFD-010694 UL 16QAM


WRFD-010697 E-DPCCH Boosting

For DC-HSUPA,

WRFD-140204 DC-HSUPA



The UE must support E-DPCCH boosting. The UE must be of HSUPA category 7, 8 or 9.

The CN must support an uplink data rate of at least 11.5 Mbit/s.



2.5.9 WRFD-010703 HSPA+ Downlink 84 Mbit/s per User

Availability




Summary

This feature provides a downlink peak rate of 84 Mbit/s for a single user through the

simultaneous use of 64QAM, multiple-input multiple output (MIMO), and dual-cell HSDPA

(DC-HSDPA).

Benefits

This feature enables end users to enjoy high-speed data services.

Description

3GPP Release 9 defines the scenario where MIMO and DC-HSDPA are used together. When

the techniques 64QAM, MIMO, and DC-HSDPA are jointly used, a downlink peak rate of 84

Mbit/s can be achieved for a single user.

Enhancement

DB-HSDPA+MIMO can be used together with 4C-HSDPA or downlink 64QAM+MIMO

from RAN15.0. With either feature group, the downlink peak rate can reach 84 Mbit/s per

user.

Dependency


To enable this feature on a BSC6900, the DPUe board must be configured for the data

plane and the interface board FG2a (GE port), FG2c (GE port), GOUa, or GOUc must be

configured.

To enable this feature on a BSC6910, the interface board FG2c (GE port), GOUc, or

EXOUa must be configured.


The BTS3812AE/BTS3812E and DBS3800 cannot provide the downlink peak rate of 84

Mbit/s per user.

The 3900 series base stations must be configured with the WBBPb3,WBBPb4,WBBPd

or WBBPf board.

Dependency on other UE

The UE must be of category 28, 31 or 32 to support 84 Mbit/s in the downlink, according

to 3GPP Release 9.

Dependency on other NE

None

Dependency on CN



WRFD-010689 HSPA+ Downlink 42Mbit/s per User



WRFD-010693 Downlink 64QAM+MIMO

WRFD-010699 DC-HSDPA+MIMO

or


WRFD-150207 4C-HSDPA

or


WRFD-010693 Downlink 64QAM+MIMO

WRFD-150227 DB-HSDPA+MIMO


It is recommended that this feature be used together with UMTS HSPA+ Introduction Service.

2.5.10 WRFD-010699 DC-HSDPA+MIMO

Availability


Summary

DC-HSDPA+MIMO is introduced in 3GPP Release 9. This feature combines DC-HSDPA

(introduced in 3GPP Release 8) and MIMO (introduced in 3GPP Release 7). This feature

allows the NodeB to send HSDPA data to a UE simultaneously over two adjacent carriers on

the same frequency band within the same coverage area by using MIMO.

Benefits

This feature fully utilizes the advantages of dual-carrier and dual-antenna techniques of

DC-HSDPA and MIMO respectively. It improves the spectrum efficiency and significantly

increases the single-user peak throughput, cell-edge-user throughput, and cell capacity.

Increasing the single user peak throughput

DC-HSDPA+MIMO achieves higher spatial multiplexing gain than DC-HSDPA. This

feature doubles the single-user peak rate from 28 Mbit/s to 56 Mbit/s (When using

16QAM modulation) or from 42 Mbit/s to 84 Mbit/s (with 64QAM).

DC-HSDPA+MIMO uses two carriers simultaneously while SC-HSDPA uses only one

carrier. This feature doubles the single-user peak rate, as mentioned previously.

Increasing the cell-edge-user throughput

DC-HSDPA+MIMO achieves closed-loop transmit diversity gain on the cell edge,

compared with DC-HSDPA.

DC-HSDPA+MIMO use two carriers and doubles the throughput, compared with

SC-HSDPA+MIMO.

Increasing the cell capacity



DC-HSDPA+MIMO improve the spectrum efficiency within 10 MHz bandwidth and

Huawei simulation test shows that it can increase the system throughput by 10% to 20%,

compared with DC-HSDPA.

Description

The following figure shows the basic principles of DC-HSDPA+MIMO.

The DC-HSDPA+MIMO feature brings together the performance enhancement benefits of the

two different technologies DC-HSDPA and MIMO.

RAN13.0 supports the configuration of MIMO on one or two carriers to reach the theoretical

peak rate of 63 Mbit/s or 84 Mbit/s respectively.

The PS best effort services are carried over DC-HSDPA+MIMO.

DC-HSDPA+MIMO apply the same principles as DC-HSDPA in load control and mobility

management.

Enhancement

In RAN15.0, non-adjacent carriers at the same frequency band can be used for DC-HSDPA.

Dependency


None


The BTS3812E and BTS3812AE must be configured with the EBBI or EDLP board, and

the uplink services cannot be set up on HBBI/HULP board.

The DBS3800 must be configured with the EBBC or EBBCd board. In addition, the

DBS3800 supports a maximum of DC+MIMOx1, that is, only one frequency in the

DC-HSDPA cell can be configured with the MIMO feature.

The 3900 series base stations must be configured with the WBBPb, WBBPd, or WBBPf

board.





WRFD-010684 2x2 MIMO


The UE must be of HS-DSCH category 25, 26, 27, or 28.

Differentiated Service Management



2.5.11 WRFD-010694 UL 16QAM

Availability


Summary

3GPP Release 7 introduces HSUPA UE category 7, which supports the 16QAM mode and a

UL peak rate of up to 11.5 Mbit/s in theory.

Benefits

The UL system capacity of the HSUPA network is increased.

The peak rate of HSUPA users (UE category 7) is increased.

Description

3GPP R7 introduces UE category 7, which supports the 16QAM mode and a UL peak rate of

up to 11.5 Mbit/s in theory. This is a 100% improvement over the previous 3GPP release of

HSUPA for which the maximum peak rate is 5.74 Mbit/s"

The HSUPA 16QAM improves the UL data transmission performance and increases the

system capacity of HSUPA cells.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The BTS3812E and BTS3812AE must be configured with the EULPd board.

The DBS3800 supports must be configured with the EBBCd board.




Dependency on UE

The UE must be of category 7, category 9.


None

Dependency on CN

None





2.5.12 WRFD-010695 UL Layer 2 Improvement

Availability


Summary

In RAN11.0 or earlier versions, the UL radio link controller (RLC) operates only in fixed

PDU mode. The size of protocol data units (PDUs) is fixed. After UL layer 2 improvement is

introduced, the UL RLC (in UM and AM modes) can operate in flexible PDU or fixed PDU

mode, depending on the higher-layer configuration. When the RLC operates in flexible PDU

mode, it can receive PDUs of flexible sizes so as to decrease the size of UL PDUs and

increase the UL throughput in the case that the UL transmit power of the UE is limited.

Benefits

This feature improves the user peak throughput as well as the uplink throughput in weak

coverage. When the UE moves from the center of the cell to the border of the cell and no

layer 2 improvement is available, the transmit power of the UE is limited if the distance from

the center of the cell reaches a specified value. In such a case, the throughput decreases

sharply, and the transportation may be interrupted. After UL layer 2 improvement is

introduced, the throughput can decrease smoothly because the size of PDUs transmitted by

the UE decreases. Therefore, the transportation is more continuous.

Description

In 3GPP R7, in the downlink, MAC layer segmentation is introduced through the change from

the fixed PDU size to the flexible PDU size for the RLC. Therefore, the DL supports the high

rate, DL layer 2 evolution, and smooth evolution of old protocol formats to new formats.

The UL has similar problems. The PDUs of a fixed size cannot support high rate services

effectively because PDUs of a small size are not applicable to high rate services. Though

PDUs of a large size are applicable to high rate services, the power at the border of the cell is



limited. Moreover, the fixed PDU size may lead to additional padding bits, affecting the

transmission efficiency.

UL layer 2 improvement has the following characteristics:

RLC supports flexible RLC PDU sizes.

The MAC layer introduces the MAC-i/is entity. The biggest difference between the

MAC-i/is entity and the MAC-e/es entity is that the MAC-i/is entity supports data

segmentation and concatenation at the MAC layer and can select an appropriate PDU

size based on the air interface quality to improve the data transmission efficiency.

The RNC can determine whether layer 2 improvement is required according to the UE

capability, cell capability, and active set capability.

The network side supports the handover between the cells with UL layer 2 improvement and

the cells without UL layer 2 improvement.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

For BTS3812E and BTS3812AE, EBBI/EBOI/EULP/EULPd is needed.

For BBU3806, EBBC or EBBCd is needed.

For BBU3900, WBBPb, WBBPd, or WBBPf is needed.

Dependency on UE

The UE needs to be compliant with 3GPP Release 8 (or later) to support the feature.


None

Dependency on CN

None








2.5.13 WRFD-010696 DC-HSDPA

Availability


Summary

The Dual Cell-HSDPA (DC-HSDPA) feature allows the UE to establish connections to two

adjacent inter-frequency same-coverage cells. With this feature, the UE can use the resources

in both cells that perform an operation on different carriers, increasing the peak throughput of

the UE.

Benefits

This feature improves the single-user throughput and the cell throughput.

Single-user throughput

After DC-HSDPA is introduced, the throughput is doubled at the center and border of the cell.

Theoretically, DC-HSDPA in 64QAM mode can provide a peak throughput of 42 Mbit/s at the

center of the cell. The gain also shortens the data transmission delay and improves user

experience.

Cell throughput

After DC-HSDPA is introduced, DC-HSDPA has the cell throughput gain of 5%–10% relative

to the total throughput of the two inter-frequency co-coverage cells. The gain is inversely

proportional to the number of UEs in a cell.

Description Configuration of primary and secondary carriers

When two frequencies, for example, f1 and f2 are used in DC-HSDPA, one DL frequency

serves as the primary carrier and the other as the secondary carrier, which is defined in 3GPP

TR25.825. In the UL, only one frequency is used, which serves as the primary carrier.

Both DC-HSDPA cells are configured with the PCPICH, SCH, PCCPCH, SCCPCH, and

PRACH. Both cells have the basic common channel (CCH) configuration for retaining and

initiating services. The single carrier (SC) UEs can camp or originate a call in each cell.

DC-HSDPA differentiated bearer policy

The CS service, IMS signaling, SRB signaling, or PS conversational service is carried on a

single carrier instead of DC-HSDPA because the amount of data is small and the gain is

insignificant when DC-HSDPA is used.

The BE or streaming service can be carried over the DC-HSDPA. The BE/streaming

combined service is carried over the DC-HSDPA preferentially.

Mobility management

The active set information and measurement reports are sent on the primary carrier during the

handover of DC users. Whether to perform an intra-frequency or inter-frequency handover depends on the frequencies of the primary carrier and the neighboring cell.



RAN12.0 supports handovers between DC cells, between the DC cell and the SC cell, and

between the DC cell and the system using the other RAT, to ensure seamless roaming of DC

terminals.

State transition in DC-HSDPA

The UE state transition in DC-HSDPA is performed in the same way as the state transition in

SC mode.

Traffic steering in DC-HSDPA

In the original network, R99 services preferentially use f1 and HSPA services use f2. After

DC-HSDPA is introduced, both f1 and f2 can be used for DL DC-HSDPA, and f2 is preferred

for HSUPA. In this way, the UL load on f1 is reduced, without disrupting R99 services.

If the R99 and HSPA services have the same priority on f1 and f2 in the original network,

traffic steering is kept the same as that of HSPA after DC-HSDPA is introduced.

STTD mode is not supported when activate DC-HSDPA.

Enhancement

In RAN15.0, non-adjacent carriers at the same frequency band can be used for DC-HSDPA.

Dependency

Dependency on RNC

None

Dependency on NodeB

The HBBI and HDLP of the BTS3812E and BTS3812AE do not support DC-HSDPA. To

support DC-HSDPA, the EBBI or EDLP board must be configured.

The BBU3806 configured with the EBBC or EBBCd board supports this feature.

The 3900 series base stations support this feature when the WBBPb, WBBPd, or WBBPf

board is configured.

Dependency on UE

The HS-DSCH capabilities are classified into category 21, 22, 23, 24, 25, 26, 27, 28.


None

Dependency on CN

None









2.5.14 WRFD-140203 HSPA+ Uplink 23 Mbit/s per User

Availability


Summary

This feature allows a maximum uplink rate of 23 Mbit/s per user by using DC-HSUPA and

16QAM techniques.

Benefits

The benefits of this feature are as follows:

Improves frequency utilization and increases the uplink peak rate per user.

Provides end users with a high-speed uplink data service experience.

Description

Based on the existing HSUPA peak rate of 11.5 Mbit/s, this feature increases the peak rate to

23 Mbit/s by using DC-HSUPA and 16QAM techniques.

Enhancement

None

Dependency


When the BSC6900 works in IP transmission, the BSC6900 must be configured with the

FG2a, FG2c, GOUa, GOUc, or POUc board.


All 3900 series base stations support this feature. The WBBPd or WBBPf board must be

configured on these base stations.

All DBS3800 series base stations support this feature. The EBBCd board must be


The BTS3812E, BTS3812A and BTS3812AE support this feature. The EULPd board

must be configured on these base stations. Downlink services must be established on the

EBBI, EBOI or EDLP board.

When 4-way receive diversity is used, only the 3900 series base stations (except the

BTS3902E) support this feature.


The UE must support E-DPCCH Boosting and DC-HUSPA.



The UE must be of HSUPA UE category 9.

Dependency on the other NEs

None


The CN is of 3GPP Release 7 or later to support a maximum uplink rate of 23 Mbit/s or

higher, which is promised at service subscription time.


WRFD-010694 UL 16QAM

WRFD-010697 E-DPCCH Boosting

WRFD-140204 DC-HSUPA

WRFD-010698 HSPA+ Uplink 11.5Mbit/s per User



2.5.15 WRFD-140204 DC-HSUPA

Availability


Summary

Introduced in 3GPP Release 9, the feature Dual-Cell High Speed Uplink Packet Access

(DC-HSUPA) allows a UE in the uplink to use two adjacent 5 MHz carriers at the same time.

This increases the peak rate per user for uplink data transmission and the average cell

throughput.

Benefits


Increased uplink peak rate per user and a higher possibility to achieve high rates with the

same uplink received total wideband power (RTWP).

High-speed uplink data service experience for end users.

Description

DC-HSUPA achieves a smooth evolution of HSPA by using uplink carrier aggregation. This

feature enables a UE to perform E-DCH transmission simultaneously on adjacent carriers of

two neighboring cells and therefore supports a higher transmission rate.

With DC-HSUPA, one enhanced dedicated channel (E-DCH) is established on each of the two

carriers. On both E-DCHs, only 2 ms transmission time interval (TTI) can be used. To use DC-HSUPA, the UE must also be enabled with DC-HSDPA, Uplink Layer 2 Improvement,



SRB over HSUPA, and SRB over HSDPA. The F-DPCH must be used in the downlink and

the DPDCH cannot be used in the uplink.

The primary DC-HSDPA carrier, which carries the HS-DPCCH in the uplink, is also the

primary DC-HSUPA carrier. Both carriers use the DPCCH in the uplink and F-DPCH in the

downlink for closed-loop power control.

DC-HSUPA can work with both or either of UL 16QAM and E-DPCCH Boosting. The two

carriers must have the same feature configuration. For example, if the primary carrier is

configured with DC-HSUPA and UL 16QAM, the secondary carrier must also be configured

with DC-HSUPA and UL 16 QAM.

The two DC-HSUPA carriers have separate uplink and downlink signaling control, for

example, scheduling information (SI) and happy bit in the uplink and absolute grant (AG) and

relative grant (RG) in the downlink.

High-speed PS streaming and BE services can be carried over DC-HSUPA.

SRB signaling, CS services, IMS signaling, PS conversational services, as well as

combinations of SRB signaling and one of these three services are not carried over

DC-HSUPA. This is because these services produce only a small amount of data and therefore

using DC-HSUPA brings unnoticeable gains.

Non-scheduling services can only be carried over the primary DC-HSUPA carrier.

DL: HS-PDSCH, HS-SCCH

UL: HS-DPCCH

UL: E-DPDCH, E-DPCCH

DL: E-AGCH, E-RGCH, E-HICH

HS-DSCH

UL: DPCCH

DL: F-DPCH

E-DCH

Secondary

carrier

DL: HS-PDSCH, HS-SCCH

UL: E-DPDCH, E-DPCCH

DL: E-AGCH, E-RGCH, E-HICH

HS-DSCH

UL: DPCCH

DL: F-DPCH

E-DCH

Primary

carrier

UE

NodeB

Enhancement

None

Dependency


None




All 3900 series base stations support this feature. The WBBPd or WBBPf board must be


All DBS3800 series base stations support this feature. The EBBCd board must be


The BTS3812E, BTS3812A and BTS3812AE configured with the EBBI, EBOI, EULP

or EULPd board support this feature. Downlink services must be established on the

EBBI, EBOI or EDLP board.

When 4-way receive diversity is used, only the 3900 series base stations (except the

BTS3902E) support this feature.


The UE must comply with 3GPP Release 9 or later.

The UE must be of HSUPA UE category 8 or 9.

Category-8 UEs support only DC-HSUPA+QPSK. Their peak rate is 11.5 Mbit/s.

Category-9 UEs support DC-HSUPA+16QAM. Their peak rate is 23 Mbit/s.


None


None



WRFD-010695 UL Layer 2 Improvement







2.5.16 WRFD-150207 4C-HSDPA

Availability


Summary

This feature, four-carrier HSDPA (4C-HSDPA), uses three or four carriers for the High Speed

Downlink Packet Access (HSDPA) transmission of a UE, which increases the UE downlink

throughput.



Benefits

This feature increases the single-user throughput by about 300% compared with HSDPA. The

increase in the single-user throughput is noticeable even at the cell edge.

Description

This feature was first specified by 3GPP Release 10.

This feature allows a UE to set up HSDPA connections with three or four carriers that use

HSDPA and 64QAM. In the downlink, the UE simultaneously receives data from different

carriers, increasing the single-user throughput. In the uplink, the UE uses Dedicated Channel

(DCH), High Speed Uplink Packet Access (HSUPA), or Dual-Carrier HSUPA (DC-HSUPA).

The signaling radio bearer (SRB) for the UE is carried over DCH or HSDPA.

The radio access network (RAN) schedules 4C-HSDPA UEs and other HSDPA UEs jointly

for fast resource allocation and load balancing among carriers. The joint scheduling also

increases the UE throughput and the fairness among UEs on different carriers.

When a UE uses four carriers for HSDPA transmission, the four carriers must belong to one

NodeB, cover the same area, and operate at two frequency bands. For details about the

frequency bands that can be used for the HSDPA transmission of a UE, see 3GPP TS 25.104.

When a UE uses three carriers for HSDPA transmission, the three carriers can operate either at

one frequency band or at two frequency bands. Two of the three carriers must be adjacent, as

shown in the following figure:

64QAM 64QAM 64QAM

Band a

N x 5 MHz

This feature applies to PS best effort (BE) services, streaming services, and combined services

that include PS BE or streaming services.

This feature does not apply to CS services, IP Multimedia Subsystem (IMS) signaling, PS

conversational services, or SRB signaling, because the gains provided by this feature are not

noticeable for services that have only a small amount of data to transmit.

Enhancement

None

Dependency


None


The BTS3812E, BTS3812AE, and BTS3812A must be configured with the EBBI,

EDLP+EULP, or EDLP+EULPd boards to support 3C-HSDPA. The three carriers must

operate at the same frequency band.



The DBS3800 must be configured with the EBBC or EBBCd board to support

3C-HSDPA. The three carriers can operate at different frequency bands.

The 3900 series base stations (excluding the BTS3902E) support this feature. The 3900

series base stations must be configured with the WBBPb, WBBPd, or WBBPf board to

support 3C-HSDPA and must be configured with the WBBPd or WBBPf board to

support 4C-HSDPA.

Dependency on UEs

The UEs must belong to HSDPA category 29, 30, 31, or 32.


WRFD-150208 Flexible DC/DB-HSDPA

WRFD-010683 Downlink 64 QAM


In a cell group that uses 4C-HSDPA, if one cell in the group operates at a different

frequency band from other cells, all cells in the group must support DB-HSDPA. (DB is

short for dual band.)


In a cell group that uses 4C-HSDPA, if multiple cells in the group operate at the same

frequency band, all these cells must support DC-HSDPA.

2.5.17 WRFD-150209 DB-HSDPA

Availability


It was first specified by 3GPP Release 9.

Summary

The Dual-Band HSDPA (DB-HSDPA) feature allows UEs to simultaneously establish

connections in two inter-band same-coverage cells. With this feature, UEs can use the

resources of two cells operating at different frequency bands, which increase the peak

throughput of UEs.

Benefits

This feature provides the following benefits to multi-band networks:

Increased single-user throughput

This feature doubles single-user throughput for multi-band networks. Specifically, this

feature can provide a maximum single-user throughput of 42 Mbit/s in the cell center

with 64QAM enabled. The increase in single-user throughput reduces transmission delay,

which improves user experience.

Increased cell throughput

This feature increases cell throughput by 5% to 10% for multi-band networks. The

throughput gain is inversely proportional to the number of UEs that have data to send in

the cell.



Description

This feature is described as follows:

Primary/secondary carrier configuration in a DB-HSDPA cell group

If a DB-HSDPA cell group consists of two cells, 3GPP Release 9 specifies that a

DB-HSDPA UE must:

− Use the downlink frequency of one cell as the primary carrier and that of the other

cell as the secondary carrier.

− Use the uplink frequency of the cell corresponding to the primary carrier only.

Two cells in a DB-HSDPA cell group are both configured with the P-CPICH, SCH,

P-CCPCH, S-CCPCH, and PRACH. In addition, this feature enables UEs to camp on

and initiate services in the two cells.

Application scope

This feature does not apply to CS services, IP Multimedia Subsystem (IMS) signaling,

PS conversational services, or SRB signaling because the gains provided by this feature

are not noticeable for services that have only a small amount of data to transmit. This

feature applies to services that may have a large amount of data to transmit, for example,

streaming or best effort (BE) services.

Selection of DB-HSDPA or Dual-Carrier HSDPA (DC-HSDPA) cell groups

In a network supporting both DB-HSDPA and DC-HSDPA, the two features have the

same configuration priority because:

− A UE supporting DB-HSDPA also supports DC-HSDPA.

− DB-HSDPA and DC-HSDPA provide similar gains.

Therefore, the selection of DB-HSDPA or DC-HSDPA cell groups depends on the traffic

steering or load balancing policy.

Mobility management

The active set information and measurement results are based on the primary carrier

when a DB-HSDPA UE is being handed over. If the frequencies of the primary carrier

before and after the handover are the same, this handover is an intra-frequency handover.

Otherwise, this handover is an inter-frequency handover.

RAN15.0 supports handovers between DB-HSDPA cells, DB-HSDPA and DC-HSDPA

cells, DB-HSDPA and Single-Carrier HSDPA (SC-HSDPA) cells, and DB-HSDPA and

inter-RAT cells to ensure seamless roaming for DB-HSDPA UEs. (RAT is short for radio

access technology.)

State transition for DB-HSDPA UEs

The state transition procedure for DB-HSDPA UEs is the same as that for

non-DB-HSDPA UEs.

DB-HSDPA cannot be used with space time transmit diversity (STTD).

Enhancement

None

Dependency


None




The RF modules must support the frequency bands on which DB-HSDPA carrier groups

operate.

The requirements for baseband modules are as follows:

The 3900 series base stations (excluding the BTS3902E) support this feature and must be

configured with the WBBPb, WBBPd, or WBBPf board.

The BBU3806 of DBS3800 must be configured with the EBBC or EBBCd board. The

BBU3806C does not support this feature.

The BTS3812A, BTS3812AE and BTS3812E series base stations do not support this

feature.

Dependency on UEs

The UEs must be of HSDPA category 25 or higher and must support DB-HSDPA.





2.6 HSPA+ Performance Improvement

2.6.1 WRFD-010688 Downlink Enhanced CELL-FACH

Availability



Summary

This feature enables the FACH to be carried on the HS-DSCH. Based on this feature, the UE

can receive data at a higher rate in CELL_FACH state.

Benefits

This feature enables the UE to transmit data at a higher rate in CELL_FACH state and shorten

the state transition delay of the UE, thereby enhancing the experience of end users in online

state.

Description

Enhanced CELL-FACH is a new feature introduced in R7.

Based on this feature, the UE can receive data on the HS-DSCH at a higher rate in

CELL_FACH state.



After this feature is introduced, the UE is still in CELL_FACH state. This feature is used for

downlink data transmission of the UE. The data carried on the BCCH, CCCH, DCCH, or

DTCH can be mapped to the HS-DSCH and then transmitted to the UE through the HSDPA

shared channel on the Uu interface. In this case, the UE in CELL_FACH state can share

HSDPA code resources and power resources as the UE in CELL_DCH does, implementing

downlink high-speed data transmission and shortening the state transition delay of the UE.

This feature enhances the traditional CELL-FACH that is used for only low-speed (32 kbit/s)

data transmission. In R7, the UE incapable of enhanced CELL-FACH uses the traditional

CELL-FACH to receive data, and the UE capable of enhanced CELL-FACH uses the

enhanced CELL-FACH to receive data if the cell on which the UE camps supports the

enhanced CELL-FACH.

To enable the UE to receive data from the HS-DSCH in CELL_FACH state, UTRAN adds

HS-DSCH receiving parameters in CELL_FACH state to the system broadcast information.

The parameters include HS-SCCH configuration, HS-PDSCH configuration, and common

H-RNTI identifier.

When the cell is configured with HS-DSCH receiving, the UE preferentially uses the

HS-DSCH to receive dedicated signaling data carried on the FACH in CELL_FACH state

instead of on the SCCPCH.

The UE in CELL_FACH state keeps monitoring the HS-SCCH. If any data is available, the

UE automatically receives data from the HS-DSCH without state handover from the FACH to

DCH, avoiding the delay caused by the state handover.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The HBBI and HDLP of the BTS3812E and BTS3812AE do not support this feature. The

EBBI or EDLP board must be configured for this feature.

The BBU3806 of the DBS3800 does not support this feature. The EBBC or EBBCd

board must be configured for this feature.

The WBBPa of the 3900 series base stations does not support this feature. The WBBPb,

WBBPd, or WBBPf board must be configured for this feature.




The UE must be Release 7 (or later) UE and support this feature.





2.6.2 WRFD-010700 Performance Improvement of MIMO and HSDPA Co-carrier

Availability


Summary

The performance of MIMO cells configured with Spatial Time Transmit Diversity (STTD)

deteriorates obviously, because the receivers of legacy HSDPA-supportive UEs fall back from

equalizer to rake. At an early phase of MIMO deployment, a large number of legacy

HSDPA-supportive UEs are in use on networks. In the MIMO and HSDPA co-carrier case, the

deterioration in system performance has become the greatest obstacle to commercial launch of

MIMO.

To solve the preceding problem and improve the MIMO and HSDPA co-carrier performance,

Huawei develops PSP-based MIMO, where PSP refers to the Primary/Secondary common

Pilot mode.

Benefits

This feature solves performance deterioration in networks where STTD is employed and

legacy HSDPA-enabled UEs are used. This feature helps implement the MIMO and HSDPA

co-carrier deployment.

With this feature, MIMO and HSDPA can be properly deployed on the same carrier so that

frequency resources are saved.

Description

MIMO-supportive UEs estimate the characteristics of channels transmitted from each antenna,

based on the Common Pilot Channel (CPICH). In a cell, signals are transmitted over the

CPICH in two modes: STTD on the Primary CPICH (P-CPICH) and PSP.

In STTD mode, the receivers of legacy HSDPA-supportive UEs fall back from equalizer to

rake. This causes obvious deterioration in the system performance.

This feature adopts PSP-based MIMO to improve the MIMO and HSDPA co-carrier

performance. The key techniques involved are PSP, Intelligent Interference Control (IIC), and

Virtual Antenna Mapping (VAM).



PSP is applied in MIMO mode. The P-CPICH is configured on one antenna and the S-CPICH

is configured on the other antenna so that diversity is prevented. The P-CPICH and S-CPICH

are used for channel estimation of MIMO users. In this way, the receivers of

HSDPA-supportive UEs do not fall back from equalizer to rake.

If PSP is enabled, the signals transmitted from the secondary antenna are unknown to

HSDPA-supportive UEs, and therefore the receivers of the UEs cannot suppress the multipath

interface caused by the signals from the secondary antenna. In this case, the system

performance deteriorates. To solve this problem, IIC is applied. IIC monitors the percentage

of each type of UE in a cell in an intelligent manner and dynamically adjusts the available

power that is allocated to MIMO users and HSDPA users. In this way, IIC controls the

interference caused by the signals from the secondary antenna to the signals of legacy

HSDPA-supportive UEs.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

This feature is only supported by 40W RRU3801C, RRU3804, RRU3806, RRU3808,

WRFU, RRU3805, WRFUd, RRU3828, RRU3829, RRU3928, RRU3929, MRFUd,

MRFUe and 850M/900M/1900M RRU3908V1

The BTS3812E/AE cannot support this feature.

The RRU3908 V2 and MRFU V2 modules support this feature from RAN14.0.

Dependency on UE

The UE must be support 2x2 MIMO. That is, the UE category must be category 15, 16, 17, or

18 as defined by 3GPP


None



Dependency on CN

None




WRFD-010684 2x2 MIMO



2.6.3 WRFD-010686 CPC - DTX / DRX

Availability



Summary

This feature is related to uplink DTX and downlink DRX. This feature can reduce the

interference between UEs and improve the HSPA+ user capacity per cell.

Benefits

This feature improves the always online experience of end users, increase the system capacity,

and save the battery consumption of the UE.

Description

Discontinuous Transmission (DTX)/Discontinuous Reception (DRX) are the key features of

the CPC, which consists of DTX in the uplink and DRX in the downlink.

Uplink DTX means that the UE automatically makes discontinuous transmission on the

DPCCH according to a certain pattern when there is no transmission on the EDCH and the

HS-DPCCH in the uplink. The UL DPCCH DTX pattern is configured by SRNC to on one

hand minimize the transmission on DPCCH and on the other hand maintain the physical

uplink synchronization between NodeB and UE by periodically sending. Uplink DTX reduces

the noise raised by the DPCCH in the uplink and also reduces the redundant signal on the

DPCCH.

Downlink DRX is implemented on the basis of Uplink DTX. Downlink DRX means that the

UE receives data on the HS-SCCH according to the transport pattern that RNC configures,

and the UE need not detect the HS-SCCH in the period when no data would be sent according

to the pattern.

In the scenario that multi-users continue to download with full of data in downlink, this

feature can reduce uplink load by 30% to 40% as well as help to save UE’s battery in different

level.



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB


EULP, EULPd board (supporting uplink DTX), or EDLP board (supporting downlink

DRX).



Dependency on UE

The UE must be Release-7 (or later) to support this feature.


None

Dependency on CN

None




2.6.4 WRFD-010687 CPC - HS-SCCH less operation

Availability



Summary

This feature is related to HS-SCCH less operation. This feature can increase the capacity of

downlink data services.

Benefits

This feature can increase the capacity of downlink data services.



Description

The HS-SCCH Less HS-DSCH Transmission (HS-SCCH Less Operation for short)

mechanism means that the HS-DSCH need not be accompanied by the HS-SCCH when

sending the predefined small transport blocks, and the HARQ retransmission for the first

HS-DSCH transmission requires the company of the HS-SCCH. This is one of the key

features of the CPC.

HS-SCCH Less HS-DSCH Transmission only applies to the UE in CELL_DCH state when

the F-DPCH is configured but the DCH is not configured in the UL and DL directions

(actually the uplink is more concerned). This mechanism can be initiated without DTX/DRX,

that is, HS-SCCH Less HS-DSCH Transmission and DTX/DRX are independent of each

other.

In addition, HS-SCCH Less Operation has the following features:

Supports the QPSK modulation only.

Supports only four predefined transport formats (MAC-hs PDU).

Provides four semi-static transport formats for UEs.

HS-PDSCH CRC is 24 bit and UE-specific (HS-PDSCH CRC is the same as HS-SCCH

CRC; therefore, HS-PDSCH CRC contains a 16-bit H-RNTI).

Allocates up to two predefined HS-PDSCH codes to each UE:

− The predefined HS-PDSCH codes are allocated to the UE in semi-static state.

− The UE can receive HS-SCCH Less HS-DSCH Transmission at any time on one or

two codes, and can perform blind detection in four formats.

− The UE must keep cyclic buffer for 13 continuous TTIs for blind detection of the

HS-PDSCH codes.

The UE does not send the NACK for the first transmission but it sends the ACK/NACK

for retransmission.

Limitations of HARQ:

− Two retransmissions

− Predefined redundancy version (not configurable)

HARQ retransmission of HS-SCCH Less HS-DSCH Transmission should accompany

the HS-SCCH by using the same channel codes and encoding modes between Release 5

and Release 6. Some bits, however, may change their meanings and inform the UE of the

following information:

− The HS-SCCH is used for HS-SCCH Less Operation.

− The retransmission is the first or the second one.

− The channel codes and TB size used by HARQ.

− HARQ combined information, which uses the offset of current TTI to indicate the

position where the information has been sent.

The UE keeps attempting to receive data from the HS-SCCH in a traditional sense.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE must be Release-7 (or later) to support this feature.


None

Dependency on CN

None




2.6.5 WRFD-010697 E-DPCCH Boosting

Availability


Summary

This feature uses the E-DCH dedicated physical control channel (E-DPCCH) instead of the

DPCCH as the reference channel for channel estimation during HSUPA demodulation. This

feature helps reduce the SIR requirement of the DPCCH and increase the rates of HSUPA

services.

Benefits

This feature together with uplink 16QAM increases uplink rates to the theoretical peak rate

11.5 Mbit/s instead of less than 8 Mbit/s due to SIR target limitation of the DPCCH.

Description E-DPCCH boosting is introduced in 3GPP Release 7.

This technique is a prerequisite for uplink 16QAM to increase uplink rates because a

higher rate requires more accurate channel estimation.

Traditionally, the DPCCH is selected as the reference channel for channel estimation.

The DPCCH, however, cannot meet the power requirement in the case of high-speed

transmission bursts in the uplink. This is because the DPCCH power is affected by outer-loop power control, and therefore delay exists in the power adjustment. Also, the SIR target of the



DPCCH is limited. These limitations of the DPCCH adversely affect the accuracy of channel

estimation.

To solve this limitation, the E-DPCCH boosting technique increases the transmit power

of E-DPCCH and uses the E-DPCCH for channel estimation. The boosting technique can

lower the requirement for DPCCH SIR. The E-DPCCH can increase the accuracy of channel

estimation because its transmit power is not limited. In this way, this feature improves the

reception quality of uplink high-speed services.

Enhancement

None

Dependency


None


The BTS3812E and BTS3812AE must be configured with the EULPd board, and the

downlink services cannot be set up on HBBI/HDLP/NDLP board.




The UE must be Release-7 (or later) to support the boosting technique.

Dependency on CN

The CN must support a data bit rate of at least 11.5 Mbit/s.





2.6.6 WRFD-010701 Uplink Enhanced CELL_FACH

Availability


Summary

This feature enables the random access channel (RACH) to be mapped onto the E-DCH

Dedicated Physical Data Control Channel (E-DPDCH). With this feature, UEs in the

CELL_FACH state can transmit uplink data at higher rates.



Benefits

This feature improves the "always-on" experience by providing high-speed uplink data

transmission for UEs in the CELL_FACH state and shortening the UE state transition and

service setup delay.

Compared with the traditional CELL_FACH state, the service setup delay for a UE to transit

from idle mode to the CELL_DCH state and the UE state transition delay from CELL_FACH

to CELL_DCH can be shortened by more than 50%.

Description

Enhanced uplink for the CELL_FACH state is introduced in 3GPP Release 8.

This feature enables UEs in idle mode or the CELL_FACH state to use the E-DPDCH for data

transmission at higher rates. Higher rates are achieved because the RACH is mapped onto the

E-DPCH instead of the physical random access channel (PRACH). In contrast to the PRACH,

which provides 20 ms TTI and 8 kbit/s, the E-DPCH provides 2 ms or 10 ms TTI. This feature

can increase the maximum transmission rate, theoretically, to 5.76 Mbit/s.

In addition, this feature uses the E-AI (Extended AI) to support more signature sequences.

As a result, the probability that UEs compete for uplink transmission resources is lower, and

user experience is improved.

Enhancement

The feature enhancement in RAN15.0 allows UEs in the CELL_FACH state to send feedback

on the High Speed Downlink Shared Channel (HS-DSCH) to NodeBs during simultaneous

uplink and downlink data transmission. The UEs send ACK/CK responses and channel quality

indicator (CQI) information to the NodeBs over the High Speed Dedicated Physical Control

Channel (HS-DPCCH). This improves the downlink average throughput for the

WRFD-010688 Downlink Enhanced CELL_FACH feature. (The FACH is mapped onto the

HS-DSCH.)

Before this feature is enhanced, data is retransmitted to the NodeBs on the HS-DSCH

regardless of whether the data is received. UEs only report the "Measured results on RACH"

in the uplink. This is insufficient for evaluating downlink HS-DSCH transmission quality.

After this feature is enhanced, UEs promptly report downlink channel transmission changes to

NodeBs. This greatly improves data transmission efficiency in favorable channel

environments.

According to 3GPP protocols, the feature enhancement enables UEs in the CELL_FACH state

to transmit data at a peak rate of 1.8 Mbit/s in the downlink.

The feature enhancement improves the downlink average throughput by 60% to 360% for a

cell with UEs in the CELL_FACH state if the following conditions are met:

The power is sufficient.

The data source is sufficient.

The channel environment is favorable, that is, the reported CQI is greater than 13.

The percentage of the period during which data is transmitted in the uplink and downlink

simultaneously is 50% to 80% for UEs in the CELL_FACH state.



Dependency


None


The BTS3812E, BTS3812A and BTS3812AE must be configured with the EULPd, EBBI,

EBOI or EULP board. The downlink services must be set up on the EBBI, EBOI, or

EULP board. The E-AI is not supported.

The DBS3800 must be configured with the EBBC or EBBCd board. The downlink

services must be set up on the EBBC or EBBCd board. To support the E-AI, the

DBS3800 must be configured with the EBBCd board.


board. The downlink services must be set up on the WBBPb, WBBPd or WBBPf board.

To support the E-AI, the 3900 series base stations must be configured with the WBBPd

or WBBPf board.




WRFD-010695 UL Layer 2 Improvement

WRFD-010688 Downlink Enhanced CELL_FACH


The UE must be Release-8 (or later) UE and support uplink for CELL_FACH enhancement

state.




Availability


Summary

This feature enables a single HSDPA cell to simultaneously support 96 HSDPA VoIP or other

low-rate users.

Benefits

This feature enables the system to serve more HSDPA users.



Description

In RAN11.0, a single cell can support up to 96 HSDPA users in VoIP or other low-rate

applications. The UE must support CPC-DTX/DRX. With this feature, the operator can

increase the voice service capacity per cell and provide services for more VoIP or low-rate

users in dense areas.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

In order to support this feature

EBBI, EBOI, EULP, EULPd is needed for BTS3812E and BTS3812AE.

EBBC, EBBCd is needed for BBU3806.

WBBPb, WBBPd or WBBPf is needed for BBU3900.

Dependency on UE

None


None

Dependency on CN

None



WRFD-010686 CPC - DTX / DRX


Availability


Summary

This feature enables a single HSUPA cell to simultaneously support 96 HSUPA VoIP or other

low-rate users. This feature can increase the capacity of voice services or other low-rate

services per cell.



Benefits

This feature allows more HSUPA users in one cell and improves the system capacity.

Description

In RAN11.0, a single cell can support up to 96 HSUPA users in VoIP or other low-rate

applications. The UE must support CPC-DTX/DRX.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

In order to support this feature

EBBI, EBOI, EULP, EULPd is needed for BTS3812E and BTS3812AE.

EBBC, EBBCd is needed for BBU3806.

WBBPb, WBBPd or WBBPf is needed for BBU3900.

Dependency on UE

None


None

Dependency on CN

None


WRFD-010634 60 HSUPA Users per Cell



Availability


Summary

This feature enables a single HSDPA cell to support a maximum of 128 HSDPA users

simultaneously.



Benefits

This feature increases the maximum number of HSDPA users that can be supported in a cell.

This is particularly useful when most calls use low rate services (such as VoIP over HSPA), as

the number of such calls can be quite larger than with high data rate services.

Description

With this feature, a maximum of 128 HSDPA users can be supported in one cell. This can be

especially useful to increase the system capacity for VoIP services or other low-rate services

which can be established simultaneously over HSDPA. For such services, it is necessary to

use the Continuous Packet Connectivity (CPC) feature to reduce the radio resources of each

user. This feature improves the CS traffic capacity of a single cell and provides VoIP services

or other low-rate services to more users.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The feature is only available for 3900 series NodeB, 3900 series NodeB (except BTS3902E)

requires WBBPd2/WBBPd3 board, which is one type of WBBPd or WBBPf.

Dependency on UE

None


None

Dependency on CN

None





Availability




Summary

This feature enables a single HSUPA cell to support a maximum of 128 HSUPA users

simultaneously.

Benefits

This feature increases the maximum number of HSUPA users that can be supported in a cell.

This is particularly useful when most calls use low rate services (such as VoIP over HSPA), as

the number of such calls can be quite larger than with high data rate services.

Description

With this feature, a maximum of 128 HSUPA users can be supported in one cell. This can be

especially useful to increase the system capacity for VoIP services or other low-rate services

which can be established simultaneously over HSUPA. For such services, it may be necessary

to use also the Continuous Packet Connectivity (CPC) feature, to reduce the radio resources

required by each user. This feature improves the CS traffic capacity of a single cell and

provides VoIP services or other low-rate services to more users.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The feature is only available for 3900 series NodeB, 3900 series NodeB (except BTS3902E)

requires WBBPd2/WBBPd3 board, which is one type of WBBPd or WBBPf.

Dependency on UE

None


None

Dependency on CN

None






2.6.11 WRFD-010704 Flexible HSPA+ Technology Selection

Availability


Summary

This feature allows dynamic selection of DC-HSDPA or MIMO for newly admitted users

according to the number of HSDPA users (including SC-HSDPA and DC-HSDPA users) and

the downlink load status.

Benefits

This feature selects DC-HSDPA or MIMO for newly admitted users according to the number

of HSDPA users and the downlink load status. This allows users to obtain the optimum bearer

mode and the highest possible throughput.

Description

DC-HSDPA and MIMO provide differing benefits in different scenarios: Carrying traffic over

DC-HSDPA when the number of HSPDA users is low and cell load is light provides relatively

high throughput. Likewise, carrying traffic over MIMO when the number of HSDPA users is

high and cell load is heavy also provides relatively high throughput.

Under DC-HSDPA networking scenarios, one or two carriers may simultaneously support

MIMO depending on the configuration by the operator. The number of HSDPA users and the

downlink load carried on each carrier change over time. The optimum bearer mode varies in

different circumstances. In scenarios supporting both of these technologies, this feature allows

dynamic selection of DC-HSDPA or MIMO for newly admitted users according to the current

number of HSDPA users and the downlink load carried on the two carriers. This allows users

to use the best relative HSPA+ technology and experience high throughput in different

scenarios, thereby improving the user experience.

Enhancement

None

Dependency

Dependency on the RNC hardware

None

Dependency on the NodeB hardware

BTS3812E, BTS3812A, and BTS3812AE should configure EBBI, EBOI, and EDLP

boards. In addition, uplink services cannot be established on HBBI or HULP boards.

The BBU3806 of the DBS3800 must be configured with the EBBC or EBBCd board.


board.



Huawei BTS RF modules support only one transmission channel. MIMO requires

interconnection of two RF modules.


UEs must be HSDPA category 21 or higher. That is: HSDPA category 21, 22, 23, 24, 25, 26,

27, or 28.



WRFD-010684 2×2 MIMO

2.6.12 WRFD-010713 Traffic-Based Activation and Deactivation of the Supplementary Carrier In Multi-carrier

Availability


Summary

This feature requires the downlink service of the user is carried on DC-HSDPA or

DC-HSDPA+MIMO and the uplink service is carried on DC or SC-HSUPA. It can deactivate

the supplementary carrier of a UE when the traffic volume to be processed by the UE is low.

When the traffic volume rises, the supplementary carrier can then be activated, the user

becomes dual-carrier user again.

Benefits

Compared with the dual-carrier transmission, because only prime carrier is demodulated by

the UE, the transmission power of HS-DPCCH can be reduced, which decreasing the uplink

transmission load as well.

Taking DC-HSDPA as an example, in the scenario of a large amount of users and low traffic

in the downlink, and the penetration rate of DC-HSDPA terminal is 100%, deactivating the

secondary carrier can theoretically reduce the uplink load by 5% to 10%.

Description

The NodeB decides whether to deactivate the secondary carrier of a UE based on the amount

of data to be transmitted by the UE and the throughput of the UE. Given a small amount of

data and low throughput, the NodeB deactivates the secondary carrier and sends an HS-SCCH

order to notify the UE of the deactivation. When the amount of data becomes large or the

throughput becomes high, the NodeB activates the secondary carrier and sends an HS-SCCH

order to notify the UE of the activation.

Enhancement

This feature applies to DB-HSDPA and DB-HSDPA+MIMO users after DB-HSDPA and

DB-HSDPA+MIMO are introduced in RAN15.0.



Dependency


None


None


The UE must support DC-HSDPA or DB-HSDPA.



or




2.6.13 WRFD-010702 Enhanced DRX

Availability


Summary

The enhanced discontinuous reception (DRX) feature enables UEs in the enhanced

CELL_FACH state to receive the high-speed downlink shared channel (HS-DSCH)

discontinuously. This feature helps UEs that process a small amount of services to save power,

by changing the state of such UEs to the enhanced CELL_FACH state.

Benefits

In the enhanced CELL_FACH state, a UE that discontinuously receives the HS-DSCH

consumes less power than a UE that continuously detects the HS-SCCH and continuously

receives the HS-DSCH.

Description

Continuous connectivity (CPC) for packet data users is introduced in 3GPP Release 7. CPC

incorporates the DRX technique that helps HSPA UEs in the CELL_DCH state save power.

Enhanced DRX is introduced in 3GPP Release 8 to further save UE power when the UE is in

enhanced CELL_FACH state. After this feature is enabled, the RAN and UEs in the enhanced

CELL_FACH state transmit and receive data at a specified time. The UE detects the

HS-SCCH at regular intervals instead of detecting the HS-SCCH continuously. When there is

no data to transmit, the UE shuts down the receiver. As a result, the power consumption of the

UE decreases.



If enhanced DRX is enabled and the RAN has data to transmit to the UE, the data is

transmitted only at user-specified times, which leads to a slight increase in transmission delay.

Enhancement

None

Dependency


None


The BTS3812E, BTS3812A, and BTS3812AE must be configured with the EULPd,

EBBI, EBOI, or EULP board.




WRFD-010688 Enhanced CELL_FACH


The UE must be Release-8 (or later) UE and support Enhanced DRX.

HSPA+ Downlink 42Mbit/s per User


Recommend to deploy this feature with UMTS Multicarrier Service

2.6.14 WRFD-150208 Flexible DC/DB-HSDPA

Availability


Summary

Flexible DC/DB-HSDPA allows UEs to set up HSDPA connections with any two

inter-frequency same-coverage cells under a NodeB. A pair of these cells is a DC/DB-HSDPA

group. The RAN schedules services in all DC/DB-HSDPA groups, which improves the UE

data rate and system capacity.

Benefits

This feature enables cells to form as many DC/DB-HSDPA groups as possible. The

DC/DB-HSDPA groups dynamically use instantaneous idle frequency resources in a cell,

increasing the UE data rate and system capacity. In the case of three carriers, this feature

increases the UE data rate by about 20% when UEs are processing burst services.



This feature supports smooth evolution to future technologies.

Description

This feature enables cells to form as many overlapping DC/DB-HSDPA groups as possible.

With this feature, some cells may simultaneously belong to multiple DC-HSDPA groups, as

shown in the following figure:

64QAM

64QAM

64QAM

DC-HSDPA

DB-HSDPA

F1 900 MHz

F2 2.1 GHZMIMO

64QAM

64QAMDC-HSDPA

DC-HSDPA

F1

F1 and F2 form a DC-HSDPA group.

F2 and F3 form a DC-HSDPA group.

F1 forms a DB-HSDPA group either

with F2 or with F3. F2 and F3 form a

DC-HSDPA group. Therefore, F2 or F3

belongs to DB-HSDPA and DC-HSDPA

groups simultaneously.

MIMO

64QAM

64QAM

DC-HSDPA

DC-HSDPA

F3

F1

F2

MIMODC-MIMO

4 carrier evolution

F2

F3

F4

F3 2.1 GHz

This feature applies to scenarios where one of the following features or any combination of

them is enabled: DC-HSDPA, DB-HSDPA, or DC-HSDPA+MIMO.

This feature has the same requirements for frequencies, bandwidths, and frequency bands as

DC-HSDPA, DB-HSDPA, and DC-HSDPA+MIMO.

This feature supports up to four carriers, which can operate at a maximum of two frequency

bands. The four carriers may include a maximum of two adjacent MIMO carriers.

The MAC-ehs entity on the RAN side jointly schedules DC/DB-HSDPA UEs. Based on the

load of carriers in a DC/DB-HSDPA group, the MAC-ehs entity assigns as many resources of

the lightly loaded carrier as possible to double-carrier UEs. In this way, more resources of the

heavily loaded carrier are assigned to single-carrier UEs. The joint scheduling achieves fast

resource allocation among carriers and prevents a temporary heavy load on a carrier from

affecting UE experience, which increases system resource utilization and system capacity.

Enhancement

None

Dependency


None


The BTS3812E, BTS3812AE, and BTS3812A must be configured with the EBBI,

EDLP+EULP, or EDLP+EULPd boards to support a maximum of three carriers. The

three carriers must operate at the same frequency band.

The DBS3800 must be configured with the EBBC or EBBCd board to support a

maximum of three carriers. The three carriers can operate at different frequency bands.

The 3900 series base stations (excluding the BTS3902E) support this feature. Only the 3900 series base stations support a maximum of four carriers and MIMO. The 3900



series base stations must be configured with the WBBPb, WBBPd, or WBBPf board to

support.

Dependency on UEs

The UEs must belong to HSDPA category 21 or higher.



In a cell group that uses Flexible DC/DB-HSDPA, if one cell in the group operates at a

different frequency band from other cells, all cells in the group must support

DB-HSDPA.


In a cell group that uses Flexible DC/DB-HSDPA, if multiple cells in the group operate

at the same frequency band, all these cells must support DC-HSDPA.



3 Smart MBB

3.1 Smart Phone Solution

3.1.1 WRFD-020500 Enhanced Fast Dormancy

Availability


Summary

This feature is concerned with the impact of Fast Dormancy to the RNC. To reduce the

signaling processing cost in the Fast Dormancy procedure, when receiving SCRI (signaling

connection release indication) message from UE or UE inactivity timer expires, RNC can

transfer UE state to CELL_FACH or through Cell_FACH to CELL/URA_PCH instead of

IDLE mode which is in legacy Fast Dormancy processing.

Benefits

This feature can reduce the signal processing cost of RNC in a network comprised of

intelligent UEs with FAST DORMANCY capable, avoid overflow of signaling processing

unit in RNC caused by Fast Dormancy.

Description

Some intelligent UEs support Fast dormancy function. To save the power, when there is no PS

data transfer, UE can send a SCRI message to require RNC release the RRC connection and

then periodically send heartbeat message to the core network, without implementation of this

feature, RNC will release the RRC connection, then each of the following heartbeat messages

will cause RRC connection setup, authentication, encryption and RAB setup procedures.

Comparing to normal PS call procedure, this Fast dormancy mechanism will greatly increase

the signaling processing cost of RNC and may cause overflow of signaling processing unit in

RNC.

With this feature, when receiving SCRI from UE or UE inactivity timer expires, RNC will

decided to transfer the state of the UE to CELL_FACH or through Cell_FACH to

CELL/URA_PCH instead of IDLE mode. When UE periodically sends heartbeat message,

RNC will reconfigure UE to CELL_FACH or CELL_DCH. The signaling procedure between

UE and RNC will be limited to only a few message exchanges because the RRC connection



keep existing, at least 40% signaling exchange can be reduced and RNC CPU resources can

be saved significantly while UE battery consumption is saved as much as that in IDLE mode.

When receiving SCRI message, if one of the following condition is met, RNC will look the

UE as FAST DORMANCY capable, initial this feature and transfer UE to CELL_FACH or

through Cell_FACH to CELL/URA_PCH state:

IMEI of the UE belongs to the range of IMEIs defined by operator configuration

RNC can get the IMEI of the UE by sending a "IDENTITY REQUEST" to UE and get UE

response;

Because the producer and model information are included in IMEI, operator can configure the

range of IMEIs with FAST DORMANCY function.

The cause value in SCRI message is "UE Requested PS Data session end."

When UE inactivity timer expires, if IMEI of the UE belongs to the range of IMEIs defined

by operator configuration, the UE will be transferred to CELL_FACH or through Cell_FACH

to CELL/URA_PCH state instead of IDLE state.

Be aware that when SCRI without cause value was sent and smart phone will be transferred to

CELL_FACH or through Cell_FACH to CELL/URA_PCH state which might have the risk of

incompatibility. In this case, we strongly suggest providing the feature together with Huawei

professional services.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


None



3.1.2 WRFD-140205 Voice Experience Improvement for Weak Reception UEs

Availability


Summary

For UEs that are prone to CS voice service drops due to weak reception, this feature enables

the radio network controller (RNC) to identify these UEs based on the International Mobile

Station Equipment Identity Type Allocation Code (IMEI TAC) and assign them dedicated

radio performance parameters. These parameters include radio link (RL) power control and

handover parameters.

Benefits

This feature provides the following benefits:

Reduces the call drop rate for weak reception UEs in weak coverage areas, improving the

user experience for CS voice services.

Enables weak reception UEs to perform inter-RAT handovers at a specified threshold.

This prevents frequent compressed mode measurements and call drops caused by signal

quality fluctuations.



Description

On a live UMTS network, weak reception UEs may easily experience call drops because they

are prone to downlink signaling radio bearer (SRB) failures. However, these UEs are likely to

be used by high Average Revenue Per User (ARPU) users. To solve this problem, Huawei

introduces the Voice Experience Improvement for Weak Reception UEs feature.

This feature is implemented as follows:

The RNC identifies a weak reception UE based on its IMEI.

The RNC configures dedicated power control and handover parameters for the UE.

Based on the parameter settings, the UE obtains a high downlink power control threshold

in a weak coverage area and performs a handover at a specified threshold.

This feature improves the user experience of CS voice services for weak reception UEs by

performing power compensation on these UEs. This leads to more power consumption and

reduces the cell capacity.

Currently, this feature applies only to iPhone 3GS and iPhone 4.

Enhancement

None

Dependency


None


None


None


None


None


None

3.1.3 WRFD-140206 Layered Paging in URA_PCH

Availability




Summary

Due to the rapid rise of smart phone use in recent years, paging messages have been

increasing. Conventionally, paging messages are sent to the entire UTRAN registration area

(URA). Once Layered Paging in URA_PCH is activated, paging messages are first sent to the

last camped-on cell of the UEs in the URA_PCH state and the neighboring cells of the last

camped-on cell. When necessary, these messages will be sent to the URA. This reduces the

number of paging messages and the possibility of PCH congestion, eliminates the need for

manually dividing URAs, and reduces the number of URA updates.

Benefits


Automatic generating of paging areas and therefore reduced costs for manual URA

planning and optimization

Reduce number of URA updates and signaling overhead.

Description

The RNC transits UEs processing PS services to the URA_PCH state instead of the

CELL_PCH state to prolong the time users are online and reduce high signaling overheads

caused by frequent state transitions from the idle mode to another state. However, the RNC

must page a UE in the URA_PCH state in the entire URA because the RNC does not know

which cell the UE camps on. This results in a large number of unnecessary paging messages,

which can in turn lead to PCHs being congested, especially with the continuously increasing

number of smart phones in use.

With this feature, the RNC first pages the UE in the last cell on which the UE camped and the

neighboring cells. If the RNC still does not receive any response from the UE, the RNC pages

the UE in the URA.

Enhancement

None

Dependency


None


None


None


None

Dependency on CN



None


None



3.1.4 WRFD-150205 Layered Paging in Idle Mode

Availability


Summary

With the increasing penetration rate of smartphones, UE paging is triggered more and more

by applications.

Conventionally, the RNC directly pages a UE in idle mode in the entire location area (LA) or

routing area (RA). This results in a large number of unnecessary Uu-interface paging

messages, which increases PCH congestion.

With this feature, the RNC first pages a UE in idle mode in the last camped-on cell and its

neighboring cells. If no response is received from the UE, the RNC then pages the UE in the

entire LA or RA.

Benefits


Fewer Uu-interface paging messages

Lower PCH congestion probability

Eliminates the need to manually divide or split the LA or RA

For example, if there are 1200 cells in an LA or RA and the average number of neighboring

cells configured for each cell is 43, this feature reduces the number of Uu-interface paging

messages by 30% to 70% if the first-layer paging success rate is 90%.

Description

With the increasing penetration rate of smartphones, UE paging is triggered more and more

by applications. However, the RNC must page a UE in idle mode in the entire LA or RA

because the RNC does not know which cell the UE camps on. This results in a large number

of unnecessary Uu-interface paging messages, which increases PCH congestion.

To solve this problem, Huawei introduces the Layered Paging in IDLE Mode feature based on

the mobility characteristics of UEs in idle mode.

With this feature, the RNC first pages a UE in idle mode in the last camped-on cell and its

neighboring cells, which is called first-layer paging. If no response is received from the UE,

the RNC then pages the UE in the entire LA or RA. This process is second-layer paging.



Enhancement

None

Dependency


None


None

Dependency on UEs

None


None


None


None

3.2 Smart Pipe

3.2.1 WRFD-020132 Web Browsing Acceleration

Availability


Summary

This feature enables detection of web page accesses and allocation of higher downlink

bandwidth, reducing delay in loading web pages.

Benefits

This feature decreases the time users spend waiting for web pages to load, significantly

improving user experience.

Description

Web browsing is the most widely used data service. Users expect to be able to quickly load

web pages at any time or place. In traditional mobile telecommunication systems, however,

multiple services coexist and equally compete for limited bandwidth resources. Bandwidth is not allocated preferentially to web page access, making it difficult for users to enjoy



high-quality, low-delay web browsing. During high-traffic hours, web access is frequently

impacted by other services and users experience high levels of delay.

This feature recognizes web browsing services by using service awareness technique and then

preferentially allocates higher bandwidth to these services. As a result, the load time for web

pages decreases and the user experience improves.

This feature is applicable to web page access acceleration where HSDPA users take priority

over other users and combined services over other services.

Enhancement

None

Dependency


The BSC6900 must be configured with the NIUa board.

The BSC6910 must be configured with the ENIUa board.


The BTS3812E and BTS3812AE must be configured with the EBBI or EDLP board. The

HBBI and HDLP board cannot support this feature.

The DBS3800 must be configured with the EBBC or EBBCd board. The HBBU cannot

support this feature.


board. The WBBPa board cannot support this feature.


None


None



3.2.2 WRFD-020133 P2P Downloading Rate Control during Busy Hour

Availability




Summary

This feature enables the detection of P2P download services and rate restrictions on P2P

services when the system load is high. When the system load is low, the rate of P2P download

services is not restricted.

Benefits

As high-bandwidth mobile telecommunication systems grow rapidly, more and more users are

using P2P services to download music or video. Due to its high volume and long duration,

P2P traffic consumes a large amount of system resources. This significantly increases

operating costs and adversely affects the quality of other delay-sensitive services.

This feature restricts P2P traffic during busy hours, thereby reducing operating costs and

improving the user experience of other delay-sensitive services. During non-busy hours, P2P

downloads are not restricted and P2P users can enjoy high speeds and make full use of

network resources.

Description

In the traditional P2P flow control scheme, the maximum rate restriction is set on the CN side.

The limitation of this scheme is that radio resources cannot be fully utilized when the traffic

load of the system is low.

This feature recognizes the P2P download traffic by using service awareness technique. When

the system load is high, rate restriction limits the rate of P2P download services to release the

occupied resources for other services. When the system load is low, resources for P2P are

unrestricted and P2P services are still able to engage in high speed downloads. This allows

multiple users and services to fully utilize network resources.

This feature is applicable to P2P rate restriction where HSDPA users take priority over other

users and combined services over other services.

Enhancement

None

Dependency


The BSC6900 must be configured with the NIUa board.

The BSC6910 must be configured with the ENIUa board.


The BTS3812E and BTS3812AE must be configured with the EBBI or EDLP board. The

HBBI and HDLP cannot support this feature.

The DBS3800 must be configured with the EBBC or EBBCd board. The HBBU cannot







None


None





4 Green

4.1 Power Consumption Saving

4.1.1 WRFD-020116 Dynamic Power Sharing in Multi-Carriers

Availability


Summary

This feature enables power sharing between carriers to improve the utilization of power

resources. In RAN11.0, the NodeB allows the carrier carrying HSDPA services to share the

unused power resources of another carrier carrying R99 services.

Benefits

This feature improves the network performance and the utilization of the existing equipment.

The simulation shows that with dynamic power sharing of two carriers, the capacity of the

HSDPA cell increases by 5% to 6%.

Description

Dynamic Power Sharing of Multi-Carriers means that among multiple carriers, the carrier

bearing HSPA service can dynamically share the unused power resource of another carrier.

This function increases the utilization of the power amplifier as well as the HSPA service rate

of the cell. For asymmetrical power configuration, the carrier with higher emitting power can

not share the unused power resource of the carrier with lower emitting power.

RAN11.0 supports the power sharing of two carriers. When one carrier is for R99 and the

other is for HSDPA, the HSDPA carrier can determine in real time the power to be used

according to the power used by the R99 carrier.

The simulation shows that with dynamic power sharing of two carriers, the capacity of the

HSDPA cell increases by 5% to 6%.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



4.1.2 WRFD-020117 Multi-Carrier Switch off Based on Traffic Load

Availability


Summary

When the network is idle or traffic load is very low, this feature enables the RNC to switch off

one or more carriers in the same coverage area to reduce the power consumption of the

NodeB.

Benefits

This feature optimizes the energy-efficiency by disabling the idle carriers; this feature brings

the following benefits:

Reduce the negative impact on environment

Save the TCO for operator

Description

In terms of power consumption assessment of the products in mobile networks, it shows that

the radio access network (and particularly the Base Stations) is the highest contributor of

power consumption and CO2 emissions in the use phase.



If there are multi carriers running in the same coverage area, Huawei provides operators with

adaptive carriers’ power management to reduce the power consumption. The traffic volume is

different at different times. For example, the NodeB in the Central Business District (CBD)

has relative high traffic volume in the daytime which requires more than one carrier to serve

all the subscribers, but from midnight to early morning of the next day the traffic volume is

relative low. In RAN10.0, during idle periods which are configurable for operator, the RNC

can dynamically shut down the carrier which has no subscriber and the other carriers in the

same area are in normal status. The carrier will be turned on again while the traffic volume in

the other carriers enters into LDR status or the idle periods ends. The energy can be saved in

this way.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


None

4.1.3 WRFD-020118 Energy Efficiency Improved

Availability


Summary

Based on the high efficient power amplification techniques, RAN11.0 introduces dynamic

adjustment of the power amplification parameters to further improve the power amplification

efficiency upon low load. The NodeB adjusts the Power Amplifier (PA) bias voltage based on

the output power that varies with the traffic load, improving the PA efficiency and reducing

the static PA power consumption.



Benefits

The energy-saving and less power consumption feature of the system has become a major

concern of the operators. The improved energy efficiency of the PA, the major component of

the NodeB, reduces the power consumption of the entire NodeB. Therefore, this feature helps

to save OPEX of the operator and is environment-friendly.

In addition, it lowers the requirements for basic power supply and heat dissipation of

equipment and reduces the difficulty in component selection. This greatly improves the

reliability of equipment.

Description

Huawei provides operators with various effective solutions to reduce the power consumption,

among which the key solution is to reduce the power consumption of the PA.

The RF module uses the Digital Pre-Distortion (DPD) technology and A-Doherty technology.

Therefore, the PA efficiency reaches 40%, and the power consumption of the entire NodeB is

greatly decreased.

Based on the high efficient power amplification techniques, RAN11.0 introduces dynamic

adjustment of the power amplification parameters to further improve the power amplification

efficiency upon low load.

In the actual operation of the network, the traffic load changes constantly, and the PA output

power of the NodeB is changed accordingly. Generally, the PA efficiency is proportional to

the PA output power, that is, the efficiency is higher when the output power is greater. The PA

bias voltage is also proportional to the PA output power. When the PA output power is great, a

high bias voltage is required to protect the linearity of power amplification so as to reduce the

signal distortion. When the traffic load is low, the PA output power decreases. However, if the

bias voltage is not adjusted at this time, the PA efficiency will be decreased because the static

power consumption is high. Therefore, the bias voltage can be decreased along with the PA

output power so that the static power consumption can be decreased and the PA efficiency can

be improved.

To improve the power efficiency in low traffic load, Huawei NodeB supports the technology

of dynamically adjusting the PA parameters. The PA dynamically adjusts the PA bias voltage

according to the output power, improving the PA efficiency and reducing the power

consumption when the output power is low.

The NodeB may experience different traffic load in different periods of a day. For example,

the NodeBs in the central business district (CBD), the traffic load is high in the day time but is

very low in the midnight till the morning of the next day. The transmit power of the NodeB

varies with the traffic load, and the output power of the NodeB is low when the traffic is light.

The NodeB monitors the traffic load in real time and dynamically adjusts the PA parameters

to improve the PA efficiency when the output power is low. Therefore, the energy can be

saved.

Enhancement

RAN11.0 supports dynamical adjustment of the PA parameters only when there are no

HSDPA services. In RAN11.0, the RF module does not support the dynamic adjustment of the

PA parameters if there are any ongoing HSDPA services.

RAN12.0 supports dynamic PA parameter adjustment when the HSDPA service is carried.



Dependency

Dependency on RNC

None

Dependency on NodeB

MTRU for BTS3812E/AE and RRU3801C for Distributed baseband site cannot provide this

function, whereas other RF modules support this feature.

Dependency on UE

None


None

Dependency on CN

None


None

4.1.4 WRFD-020119 Multi-Carrier Switch off Based on Power Backup

Availability


Summary

In case of mains failure, the backup power system starts to operate. In this case, this feature

can achieve hierarchical carrier shutdown based on the shutdown duration and cell priority.

Benefits

This feature can reduce the NodeB power consumption and extend the up time of running

batteries in case of mains failure. For batteries, long-time running leads to aging, decreasing

the power backup time. This feature, however, can extend the up time of batteries, so that the

aged batteries still meet the requirements of the NodeB for power backup time. In other words,

the service life of batteries is prolonged.

Description

After this feature is enabled, the NodeB can assign priorities to carriers and then shut down

carriers by priority. In case of mains failure, the batteries start to operate. Then, the NodeB is

triggered to shut down the non-reserved and reserved local cells based on the preset shutdown

durations (T1, T2). After the mains failure is rectified, the NodeB automatically restores all

the cells that were shut down.



Enhancement

In RAN 15.0, a parameter is added for specifying the RAT-specific power backup and energy

saving policy. A mode of the multi-mode base station uses a specific set of shutdown

durations based on parameter settings. RAT is short for radio access technology.

Dependency

Dependency on RNC

None

Dependency on NodeB

The BTS3902E does not support this feature.

Dependency on UE

None


None

Dependency on CN

None


None



4.1.5 WRFD-020122 Multi-Carrier Switch off Based on QoS

Availability


Summary

In the preconfigured time segments, this feature enables some carriers to be shut down,

ensuring the real-time rate of DCH and high Average Revenue Per User (ARPU) for HSPA

users, and only the GBR rate for low ARPU HSPA users. The purpose is to save power.

This feature is applied in the scenarios of multi-carriers with same coverage.

Benefits

According to an estimate on power consumption in mobile networks, power consumption and

carbon dioxide emission from RAN, especially NodeB, account for the major part of total

consumption. Telecom operators expect that the carriers with the same coverage be shut down

during low-traffic hours (for example, at midnight) to reduce costs.

However, with the rapid development of mobile broadband networks, an increasing number of

low ARPU users often stay connected 24 hours a day to download video and audio files.

Since their real-time rate is always ensured, the actual network load is still heavy even at

midnight, and it is hard to trigger the shutdown of same-coverage carriers.

After this feature is introduced, the real-time rates of DCH and high ARPU HSPA users are

ensured, whereas only the GBR rate is ensured for low ARPU HSPA users. As long as the

total load based on this requirement is below the specified threshold, the same-coverage

carriers can be shut down. This reduces energy consumption and increases the profits of

telecom operators.

Description

For multiple carriers with the same coverage, when the preconfigured time segment begins,

the users in the serving carrier (F2 in the following figure) are handed over to the

same-coverage neighboring carrier (F1 in the following figure). This can only happen if the

available resources plus non-GBR resources of low ARPU HSPA users in F1 meet the load

requirements of the real-time rates of DCH and high ARPU HSPA users as well as the GBR of

low ARPU HSPA users in F2. Then, the F2 can be shut down.



When F1 comes into the basic congestion state or the preconfigured time segment comes to an

end, F2 is activated again.

In this way, not only the experience of high ARPU users is ensured but also idle carriers can

be shut down, and the profit of the operators is increased.

The high ARPU and low ARPU users are configured by operators based on the SPI

(Scheduling Priority Indicator), and the GBP (Guaranteed Bit Power) in the above figure

means guaranteed power for GBR rate.

Enhancement

None

Dependency


None


None


WRFD-010610 HSDPA introduction package


None



4.1.6 WRFD-020121 Intelligent Power Management

Availability


Summary

This feature introduces the function of Power Supply Unit (PSU) intelligent shutdown. With

this feature, certain PSUs can be powered on or off according to the power consumption of

the NodeB, reducing the power consumption.

Benefits

The PSU intelligent shutdown function can save about 4% of the electricity expenses for

operators in typical configuration.

Description

A NodeB with AC input is generally configured with multiple PSUs (converting AC into DC).

The number of configured PSUs depends on the maximum power consumption of the NodeB.

The purpose is to ensure that the NodeB operates properly even at the maximum load. In most

cases, the NodeB does not operate at full load, and the PSUs do not operate at full power.

Generally, the PSU conversion efficiency is proportional to its output power. In other words,

the decrease in the conversion efficiency increases the overall power consumption of the

NodeB. The following figure takes four configured PSUs as an example to show the

relationship between the PSU conversion efficiency and the PSU output power. As shown in

the figure, the total power of the four PSUs is 6,400 W and high PSU output power leads to

high power conversion efficiency.

When the NodeB is powered by multiple PSUs, the PSU intelligent shutdown function

enables shutting down one or several PSUs according to the actual load and the power supply



need. This ensures that the NodeB is always working at the state when PSUs are in the best

working efficiency. In this way, the remaining PSUs work in full load mode, ensuring their

best level of efficiency.

For MBTS scenario, because MBTS of GSM, UMTS and LTE are sharing one PMU, only one

license of GSM, UMTS and LTE is required for MBTS, but if the corresponding network is

down, this function will be deactivated for MBTS.

Enhancement

None

Dependency


None


Only when DBS3900, BTS3900AL or BTS3900A is used with APM30 and battery


None


None



5 Topology & Transmission

5.1 RAN Sharing

5.1.1 WRFD-021304 RAN Sharing Introduction Package

Availability


Summary

This feature enables multiple operators to share the same RAN equipment and have their own

independent cells. The same RAN equipment can provide different operators with rich and

personalized services.

Benefits

The most important and urgent factor for driving operators to share network is the substantial

CAPEX and OPEX saving. Approximately 30%– 40% CAPEX and OPEX can be saved if

RAN is shared. Another advantage is the increased roll-out speed and enlarged coverage-area

that can result in a quick network deployment and a success of UMTS. On the other hand,

reduced independency results in co-operation between operators and some restrictions when

expanding.

Description

There is growing optimism among 3G license holders about the prospects of sharing 3G

network infrastructures. The primary motivation for this sharing is to rapidly launch service

and reduce the costs of deployment, thereby improving the overall financial health of the

industry.

Analysis of a typical 3G Capital Expenditure (CPEX) model reveals that a majority of the

upfront costs are related to establishing coverage (that is, access related CPEX). As shown in

Figure 2, approximately 70% of the CPEX involves acquiring the sites, access equipment,

civil works (that is, construction of the site, installation of the equipment) and laying the

transmission network. With 3G, these fundamental implementation issues will be further

complicated by the lack of sites, tighter environmental regulations, and health concerns

regarding the hazards of radiation. In view of these challenges faced by 3G license holders,

shared network infrastructure solutions need to be explored in order to reduce the financial

risks facing the industry, establish faster universal coverage and improve time-to-revenue.



Since the deployment cost of RAN takes up the most among the total network, so RAN

sharing would be a preferred approach to share the heavy deployment costs for mobile

networks among operators in the roll-out phase and to increase the network utilization. It can

offer advantages for all parties involved in UMTS.

With this feature, all the RAN elements are physically shared, including the RNC, NodeBs,

Sites, and transport equipment. By ‘soft-splitting’ a physical RAN into different logical RANs,

multi-operators can cover the same area with their own frequency with only one physical

RAN. Each operator deploys its own frequency including its own Mobile Network Code

(MNC) and each operator has individually assigned cells. RNC routes the UE according the

cell or MNC&MCC derived from the IMSI and the Network Resource Identify (NRI) derived

from TMSI/P-TMSI, when Iu-Flex is used. The following figure shows the RAN sharing

solution architecture.

Iu interface

RNC

Operator A

CN

Macro

Node B

Iub

interface

Operator B

CN

Shared RAN

RRU

Operator B OSSOperator A OSS

Shared Master OSS

Itf-NIu interface

RNC

Operator A

CN

Macro

Node B

Iub

interface

Operator B

CN

Shared RAN

RRU

Operator B OSSOperator B OSSOperator A OSSOperator A OSS

Shared Master OSS

Itf-N

In RAN sharing architecture, RNC is shared by multiple operators (maximum is 4), and the

CN networks are supplied by operators separately. For the shared RNC, both shared and

non-shared NodeB/RNC could be connected. For each operator’s CN network, Iu Flex may be

applied, and the decision could be made independently.

RAN sharing solution does not require any UE release dependency. The call traffic is routed

to appropriate CN network belonging to the operator selected by UE. In the shared RAN,

inter-system handover and intra-system handover within each operator are handled normally.

A switch is supplied to indicate whether intra-system handover between operators would be

allowed. For broadcast service such as CBS and MBMS, the traffics will be restricted in each

operator’s dedicated cells.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


Cannot work with WRFD-021311 MOCN Introduction Package at the same time.


Recommend to deploy this feature with UMTS RAN Sharing Introduction Service

5.1.2 WRFD-02130401 Dedicated Carrier for Each Operator

Availability


Summary

This feature enables the allocation of frequency resources to different operators for

independent operation.

Benefits

For license holders, distinct cost saving would be achieved, including the CAPEX and OPEX,

because all the RAN elements could be shared.

Description

RAN sharing solution is applicable for operators that have multiple frequency allocations, that

is, all operators have their own licenses. In this scenario, the RAN elements but not the radio

frequencies are shared between operators, as illustrated in the following figure.



1 (1)

Nokia Svenska AB06.05.2002

Frequency one

Frequency two

Shared RNC

Frequency one

Frequency two

Shared Node B

MNCone

MNCtwo

Operator one

Operator two

In this solution, 3GPP Release 99 specific is applied. For multiple operators that share the

RAN, their own PLMN codes are transmitted on their dedicated carrier, that is, unique PLMN

code (composed by MCC and MNC) is broadcasted via system information within each

operator’s dedicated cells.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-021304 RAN Sharing Introduction Package



5.1.3 WRFD-02130402 Flexible Network Architecture

Availability




Summary

This feature can meet the networking requirements of different operators.

Benefits

Various requirements can be met with the help of the flexible architecture. Differentiated

service and effective cost are also achievable.

Description

In RAN Sharing solution, the flexibility of the network architecture is well supported. The

involved interfaces are Iub, Iur, Iu, and Iu-BC.

Iu interface

CN network is supplied by operator separately. On Iu interface, each operator may employ Iu

Flex or not independently. The maximum number of CN nodes (MSC or SGSN) that can be

connected is the same between shared or non-shared RNC. For the shared RNC, the capacity

will be divided by all operators.

For example, as illustrated in the following figure, operator A adopts the Iu Flex while

operator B does not.

Iu-BC interface

To the shared RNC, maximum 4 CBCs can be connected, that is, each operator can have

a dedicated CBC, shown below.

Shared RNC

MSC 3 MSC 2

MSC 1

SGSN 2 SGSN 1

MSC

SGSN

Operator A Operator B



With dedicated Iu-BC connection, each operator can independently deploy the Cell Broadcast

Service.

Iub interface

In the shared RAN, RAN elements could be shared by multiple operators, including

RNC and NodeBs. However, there might be the case that shared NodeBs and non-shared

NodeBs coexist. In this RAN sharing solution, both shared and non-shared NodeBs are

allowed to connect to the shared RNC. See the following figure.

Iur interface

The Iur interface is similar to the Iub interface. That is, both shared RNCs and non-shared

RNCs can be connected to a shared RNC.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

Operator B

Operator A

Shared

RNC

Shared by

Operator A & B

Shared by

Operator A & B

Shared

RNC

CBC-B Operator B

Operator A CBC-A

SAs of Operator A

SAs of Operator B



None

Dependency on UE

None


None

Dependency on CN

None





5.1.4 WRFD-02130403 Mobility Control and Service Differentiation

Availability


Summary

This feature provides the configuration of different services for multiple operators to meet

their personalized requirements.

Benefits

Based on the service differentiation mechanism, operators that share the RAN can deploy

different service provision strategies to their subscribers.

Description Initial NAS message routing

In the dedicated carrier RAN sharing solution, each cell belongs to one operator. The

initial NAS message (for registration or call setup) will be routed to appropriate target

CN network, to which operator of the current cell (from which the call is initiated) also

belongs. As shown in the following figure for example, if UE initiates a call from one

cell belonging to operator B, then the initial NAS message will be routed to the CN

network of operator B.



If the Iu Flex is adopted, then the NNSF will be applied right after the selection of CN

network, to decide which CN node should be the target of routing.

Differentiated and isolated CBS

CBS information content is broadcasted with a set of CBS SAs (service areas), and each

CBS SA is composed by a set of cells. In the dedicated carrier shared RAN, the CBS SA

is also operator dedicated, that is, each operator’s CBS SA can be composed only by its

own cell. Therefore, the CBS is isolated between operators in the shared RAN.

Furthermore, since each operator can deploy a standalone CBS equipment, differentiated

and independent service provision is also achievable.

Differentiated and isolated MBMS

The MBMS is similar to the CBS. MBMS service is distributed in a set of MBMS

broadcast areas, also called "MBMS SA". Each MBMS SA is composed of a set of cells.

In the dedicated carrier shared RAN, the MBMS SA is also dedicated. MBMS service

initiated from dedicated SGSN is distributed (p-to-p or p-to-m) within operator dedicated

MBMS SAs, that is, operator dedicated cells.

Furthermore, differentiated and independent MBMS service provision is also achievable.

Mobility control

Shared

RNC

MBMS SAs of

Operator A

MBMS SAs of

Operator B

BM-SC SGSN

Operator A

BM-SC SGSN

Operator B

Shared

RNC

Operator A

CN

Operator B

CN

Target CN network Originated Cell



Inter-operator handover is usually forbidden by operators, but sometimes it is allowed. A

configurable flag is provided to indicate whether inter-operator intra-system handover is

allowed or not. The default setting is not allowed. The inter-system handover is handled

normally.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





5.1.5 WRFD-02130404 Independent License Control

Availability


Summary

With this feature, operators can have their independent capacity and choose optional features,

meeting different service and operation requirements.

Benefits

With independent license control, total capacity of the physical RNC will be shared by

operators, and each can take specific proportion.



Description

License control refers to the control of the capacity (Erlang, NodeB CE and PO) and optional

features (except RAN Sharing feature itself). For multiple operators that share the RNC,

independent capacity and optional features control for each operator is supplied.

For independent capacity control, the total capacity could be split by multiple operators. Each

operator can get specific proportion of the total capacity based on its requirement, and the

actual capacity usage will be monitored and controlled.

For independent optional features control, each operator may choose different set of optional

features For example, one operator may choose some optional features but the others do not.

Most optional features can be controlled separately by operators. For example, if the MBMS

is chosen by operator A but not by operator B, then operator A can provide the MBMS, but

operator cannot provide the MBMS.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





5.1.6 WRFD-02130405 Independent Cell-level FM/PM/CM

Availability




Summary

With this feature, operators can monitor and maintain their own cells.

Benefits

Providing Independent Cell-level FM/PM/CM

Description Independent cell-level Fault Management

Most alarms are object related. For those alarms related to cells, they are contained only

in the data collection of the corresponding instance set. For those alarms not related to

cells or any objects, they are contained in all data collections of all instance sets. As each

instance set corresponds to only one manager, the operator dedicated alarms can only be

accessed by the owner FM manager.

For operations originated from the FM manager (that is, alarm handling operations,

setting operations), as the operated targets are alarms, they are processed in the same way.

Each manager can only operate the alarms in the corresponding instance set, that is, the

alarms dedicated to one operator.

Independent cell-level Performance Management

All counters are object related. For those counters related to cells, their statistical results

are contained only in the data collection of the corresponding instance set. For those

counters not related to cells, their statistical results are contained in all data collections of

all instance sets. As each instance set corresponds to only one manager, the operator

dedicated results can only be accessed by the owner PM manager.

For operations originated from the PM Manager (that is, job management operations,

threshold setting operations), as the operated targets are objects, they are processed in the

same way. Each manager can only operate the objects in the corresponding instance set,

that is, the objects dedicated to one operator. For example, each operator can only create

measurement jobs on his own cells. Dedicated cell-level measurement of each operator is

supported including NodeB CE utilization and cell traffic throughput. RAN also supports

non cell-level measurement, which is shared by operators. Items are RNC/NodeB

utilization, PA utilization and Iub capacity & throughput.

Independent cell-level Configuration Management

The configuration flows are the same in both sharing and non-sharing mode. The

difference lies in data, and is embodied in cell-level configuration.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None



Dependency on UE

None


None

Dependency on CN

None





5.1.7 WRFD-02130406 Transmission Recourse Sharing on Iub/Iur Interface

Availability


Summary

With this feature, operators can share Iub/Iur transmission resources to effectively use the

transmission bandwidth and reduce the operation cost.

Benefits

Transmission resource is costly. Shared transmission resource management strategy leads to

effective usage of the bandwidth, and will finally bring cost saving to all the operators sharing

the RAN.

Description

In the shared RAN, shared transmission resource management strategy is adopted on both Iub

and Iur interface.

Iub interface,

The Iub interface is composed of NodeB control port (NCP), CCPs, ALCAP link (not

applicable for IP transmission), OM path, and a number of user plan links.

For each NodeB, only one unique NCP could exist. Generally multiple CCPs can exist,

but they need to work in load sharing mode. In normal case, the ALCAP link is also

unique for each NodeB. Shared OM path for one NodeB is also proposed, because the

NodeB is shared, though multiple OM paths are allowable, but it brings no benefit. So,

the control plane links (NCP, CCP, ALCAP link) should be shared by operators.

To achieve effective transmission resource usage, user plane links are also shared by

operators.



Iur interface

SS7 is adopted for Iur interface control plane. SS7 links work in load sharing and

redundant mode, and all the SS7 links must be shared by operators utilizing the Iur

interface.

For the Iur interface user plane, it is handled in the same way as that for the Iub interface.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





5.1.8 WRFD-021305 RAN Sharing Phase 2

Availability


Summary

This feature provides multiple operators with separated Iub transmission resource

management to meet their QoS requirements.

Benefits

In the shared RAN, operator’s differentiated QoS requirement is guaranteed with this feature.



Description

Based on RAN Sharing phase 1, dedicated Iub transmission control function was introduced

in phase 2, in which separated Iub transmission resource management is provided for

operators sharing the RAN.

On the common Iub interface, separated Iub transmission resource management aims to

guarantee the QoS for operators, and no interference between each other.

In RAN sharing phase 2, dedicated Iub transmission control is not mandatory, that is, shared

transmission resource in Iub is still applicable.

Enhancement

None

Dependency

Dependency on RNC

When Iub over IP is applied, the BSC6910 does not support this feature.

NoneDependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





5.1.9 WRFD-02130501 Dedicated Iub Transmission Control

Availability


Summary

This feature provides multiple operators with separated Iub transmission resource

management to meet their QoS requirements.



Benefits

In the shared RAN, operator’s differentiated QoS requirement is guaranteed with this feature.

Description

Dedicated Iub transmission control refers to separated Iub transmission resource management

for operators sharing the RAN. It is only applicable for user plane, but not control plane and

OM path. Control plane must be shared by operators.

Control plane links (including NCP, CCPs, ALCAP link) and bandwidth (occupied by these

links) should be commonly used by operators. However, in user plane, each operator may use

dedicated links (such as AAL2 paths / IP paths) and bandwidth (occupied by these links).

Refer to the following figure (example in ATM transmission).

For user plane bandwidth, the shared mode is supplied in phase 1, while phase 2 supports

dedicated mode. In dedicated mode, operator dedicated logical resource group is introduced,

which aims to separate the user plane bandwidth between operators.

For logical resource group, two different cases are applicable. In case 1, physical link is

common to all groups. In case 2, physical links are dedicated to each group. Both cases will

be supported. These two cases are illustrated as follows.

I. Case 1

GROUP-A

GROUP-B

Physical Link

II. Case 2

NCP bandwidth

CCPs bandwidth

ALCAP bandwidth

O&M bandwidth

User plane

bandwidth

Could be dedicated

or shared

Must be shared



Physical Link

Physical Link

GROUP-A

GROUP-B

When creating a logical group, the operator to which bandwidth belongs and the maximum

available bandwidth should be specified. To achieve the separate resource management, each

operator’s dedicated group should contain some user plane links, which will also become

operator dedicated.

Based on the dedicated logical resource group, the operator can perform admission control

and congestion control independently.

Admission Control

In this feature, admission control for transmission resource is performed separately to avoid

conflict between operators. That is, for each operator’s call traffic, the required transmission

resource (bandwidth) would only be allocated from this operator’s dedicated group. There is

no difference whether the resource groups are carried by the shared physical link (case 1) or

separated physical links (case 2). See the example in the following figure.

Congestion Control

In this feature, congestion control of transmission resource is also performed separately.

Congestion is detected and reported independently for operator dedicated group, and only its

own users are involved in the control process. As shown in the following figure for example,

if congestion happens to Group-B (owned by operator B), only users that belong to operator B

are involved.



Besides the admission control and congestion control, the flow control for the HSDPA is also

isolated between operators.

HSDPA flow control

As shown in the preceding figure, HSDPA flow control is performed separately for operator A

and B. For example, available bandwidth for HSDPA within dedicated group is calculated as:

Available bandwidth for HSDPA within Group-A

=min {(maximum bandwidth of Group-A - total bandwidth allocated for R99 within

Group-A), maximum bandwidth for HDSPA within Group-A}

Where:

Group-A is dedicated for Operator A.

Enhancement

In RAN12, the transmission resource management of different operators can be configured.

Iub CAC and flow control can be configured as one of the following three modes:

a. In Iub CAC, different users are admitted according to divided bandwidth of different

operators, flow control algorithm is performed according to their individual bandwidth

either.

b. In Iub CAC, all the users are admitted according to total bandwidth instead of

individual bandwidth, flow control algorithm is also performed according to total

bandwidth.

c. In Iub CAC, different users are admitted according to divided bandwidth of different

operators, but flow control algorithm is performed according to total bandwidth.

In these three modes,

a. Different operators can have different QoS mapping scheme (ARP/TC/THP)

b. The mapping between QoS attributes (TC/ARP/THP) and SPI/SPI weight/User GBR of

BE service can be configured for each operator.

c. The Iub CAC and congestion control to the users of different operators are performed

according to their individual mapping configurations.



Dependency

Dependency on RNC

When Iub over IP is applied, the BSC6910 does not support this feature .

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





5.1.10 WRFD-021303 IMSI Based Handover

Availability


Summary

This feature supports the configuration of SNA-related information on the RNC side. When

the CN does not support the SNA function, this feature enables the UTRAN to provide

limitations to mobile areas of the UE.

Benefits

With this feature, the RNC can prevent the UE in connected mode from being moved to an

un-subscribed area without CN support. This feature can also be used as a supplement for

implementing shared networks solutions.

Description

This feature is an alternate solution when the CN does not support the function of the shared

network support in connected mode which is described in WRFD-021301 Shared Network

Support in Connected Mode. That is, the following mappings must be configured on the RNC

instead of informed by the CN.

The SNA that an LA belongs to



The SNA that the UE is allowed to connect to

With this information, UTRAN can provide the same restrict mechanism for UE in connected

mode without CN node support.

The following procedures are affected in the IMSI-based handover and the process is the

same as described in the feature WRFD-021301 Shared Network Support in Connected

Mode:

RRC Establishment

Cell Update

URA Update

Handover

Relocation

Handling Common ID

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



5.1.11 WRFD-021311 MOCN Introduction Package

Availability




Summary

With this feature, multiple operators can share a cell. This feature applies to the scenarios

wherein multiple operators share a carrier or further sharing is required.

Benefits

MOCN enables the operators to save Capital Expenditure (CAPEX) and Operation

Expenditure (OPEX), especially in areas where a single carrier is sufficient to support

subscribers from different operators. For operators involved in the fierce competition of the

telecom industry, MOCN can help them to achieve capital gains as well as corporate

soundness and competitiveness.

Compared with other sharing modes that use independent carriers, MOCN can share carrier

resources and better utilize resources.

Description

MOCN, introduced in the 3GPP R6 protocols, is known as one of the access network sharing

modes. In addition to access nodes such as RNC and NodeB, MOCN also shares the carriers.

The network architecture of MOCN is shown below:

Different from RAN Sharing that uses independent carriers, MOCN uses common carrier

resources. Similar to RAN Sharing, the Core Network (CN) in MOCN is independent, that is,

the CN nodes belong to different operators. When multiple operators share common carrier

resources, the users of these operators have cell resources in common. In this respect,

compared with RAN Sharing, MOCN can better utilize resources.

Huawei does not offer the MOCN solution with RAN Sharing solution together.

In MOCN solution, all the software features cannot be controlled separately by different

operators. one optional feature needs be bought by all the customers before it is available.

MOCN introduction package has the following features:

Common carriers shared by operators

Dedicated NodeB or cell for operators

MOCN mobility management

MOCN load balancing

MOCN independent performance management



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should support the MOCN function.


None

Dependency on CN

The CN should support the MOCN function.


Cannot work with WRFD-021304 RAN Sharing Introduction Package at the same time.



5.1.12 WRFD-02131101 Carrier Sharing by Operators

Availability


Summary

With this feature, multiple operators can share a carrier.

Benefits

MOCN enables the operators to save Capital Expenditure (CAPEX) and Operation

Expenditure (OPEX), especially in areas where a single carrier is sufficient to support

subscribers from both operators. For operators involved in the fierce competition of the

telecom industry, MOCN can help them to achieve capital gains as well as corporate

soundness and competitiveness.

Compared with the sharing mode that uses independent carriers, MOCN can share carrier

resources and better utilize resources.



Description

MOCN uses common carrier resources and enables multiple operators to share the RAN

equipment and the same carriers. One cell can belong to and serve different operators.

The basic functions of MOCN are as follows:

System information broadcast

The RNC broadcasts the PLMN IDs of multiple operators in the Master Information

Block (MIB) to send the UE the information about these operators. Based on the

information, the UE performs PLMN selection.

Network selection

MOCN network sharing specifies the following two types of UE:

− Supporting UE: refers to the UE that supports network sharing.

In MOCN network sharing, the RNC broadcasts the PLMN information of multiple

operators through the Multiple-PLMN list IE in the MIB. The supporting UE can

analyze the PLMN information and inform the RNC of the selected PLMN through

the initial direct transfer message. The supporting UE should support the 3GPP R6

protocols.

− Non-supporting UE: refers to the UE that does not support network sharing.

The non-supporting UE cannot analyze the PLMN information of operators from the

system information.

The RNC adopts different methods to select suitable operators for the two types of UEs.

The supporting UE selects a suitable PLMN ID from the PLMN IDs of multiple operators as

broadcast in the MIB, and reports the selected PLMN ID to the RNC through the initial direct

transfer message. Accordingly, the RNC selects a suitable CN node for the UE based on the

PLMN ID of the UE. If the operator enables the Iu Flex function, the RNC selects one of the

CN nodes based on the NAS Node Selection Function (NNSF).

The non-supporting UE does not report PLMN ID to the RNC through the initial direct

transfer message. The RNC selects a CN node for the UE through the redirection function.

PS/CS consistency

The CS/PS consistency is achieved by coordinating the RNC and the CN. It prevents the

RNC from selecting two CN operators (for CS domain and PS domain respectively) for

the UE. For a network with the Gs interface, the CS registration is forwarded from the

PS domain; therefore, the SGSN is responsible for ensuring the CS/PS consistency. For a

network without the Gs interface, the RNC ensures the CS/PS consistency.

In addition, to facilitate the implementation of MOCN, some UEs that support 3GPP R5

rather than 3GPP R6 may realize the MOCN-associated features of Release 6. The RNC

supports these pre-R6 UEs which implement MOCN independently.

Enhancement

None

Dependency

Dependency on RNC

None



Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-021311 MOCN Introduction Package



5.1.13 WRFD-02131102 Dedicated NodeB/Cell for Operators

Availability


Summary

This feature enables operators to independently control a NodeB or cell in MOCN scenarios.

Benefits

Through dedicated NodeBs/Cells, the operators can flexibly set the network sharing areas to

meet various requirements for network sharing and scenarios.

Description

To satisfy the special requirements of different operators, the RNC can not only connect to a

shared NodeB of multiple operators (known as MOCN NodeB), but also connect to a

dedicated NodeB, namely, non-shared NodeB which serves one operator only, as shown

below:



The dedicated NodeB belongs to Operator A only; therefore, all the UEs that access the

network from this NodeB will be connected to the CN node of Operator A.

For MOCN NodeB, some cells of the shared NodeB can be dedicated to one operator and

serve this operator only. The RNC supports the dedicated cell for an operator.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None







5.1.14 WRFD-02131103 MOCN Mobility Management

Availability


Summary

This feature adapts to different MOCN mobility policies. Whether the UE can be handed over

to a new cell depends on the PLMN ID of the target cell and the operator ID of the UE.

Benefits

This feature can ensure a continuous shared network service, improve user perception, and

provide more flexible mobility management policies, meeting different network sharing

requirements of operators.

Description

Generally, inter-operator handover is prohibited, but there are some exceptions. The RNC

provides a flag implying that the inter-operator handover within the system is allowed. The

flag can be configured by operators although the inter-operator handover is prohibited by

default. If the flag is provided, it indicates that the UE movement is not limited by operators.

The inter-RAT handover between operators is allowed no matter what the flag is.

MOCN mobility management prevents the UE from being handed over to the cells that

belong to a different operator when the inter-operator handover is prohibited. The handover of

UEs include soft handover, hard handover, intra-frequency handover, and inter-frequency

handover.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None







5.1.15 WRFD-02131104 MOCN Load Balance

Availability


Summary

This feature enables load balancing between multiple operators and ensures the network

fairness.

Benefits

This feature ensures the balance of load and the fairness of network sharing between different

operators.

Description

For a non-supporting UE, the RNC selects a suitable operator for the UE based on the

redirection function. In some cases, multiple operators can serve one UE (for example, a

roaming UE); therefore, the load balancing mechanism is required to ensure the balance of

load and the fairness of network sharing between operators.

The RNC supports the load balancing mechanism of MOCN. In the first and the following

attempts of redirection, the RNC selects the operator with least times of success access. This

allows multiple UEs to be evenly allocated to different CN operators and guarantees the load

balance between operators.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None




None

Dependency on CN

None





5.1.16 WRFD-02131105 MOCN Independent Performance Management

Availability


Summary

This feature enables operators to independently obtain the information about network

operation such as traffic and network quality.

Benefits

With this feature, operators can independently obtain the information about network operation

such as traffic and network quality.

Description

The RNC supports independent performance management for different operators. That is to

say, the operators can obtain their specific information about network operation, such as

traffic volume and network quality.

In addition, the performance counters related to MOCN, for example, the redirections with

various causes are added to the RNC performance counters.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None



Dependency on UE

None


None

Dependency on CN

None





5.1.17 WRFD-02131106 Routing Roaming UEs in Proportion

Availability


Summary

If an RNC is shared by several operators that support the Multi-Operator Core Network

(MOCN) and have a roaming agreement with each other, when UEs of another RNC enter the

coverage area of this RNC, this RNC routes these UEs to the CNs of different operators

according to the predefined routing proportion.

Benefits With this feature, the telecom operators sharing one RNC can flexibly route roaming

UEs to CNs.

Description

In a shared RNC, roaming relationships can be configured between the operators who share

the RNC and other operators who do not. For the UEs of an operator that enter the coverage

area of the shared RNC, the allocation proportions among the operators who share the RNC

can also be configured.

When UEs of other operators roam into the area served by the shared RNC, and the UEs are

non-supporting (meaning they do not support network sharing, as specified in the optional

feature WRFD-02131101Carrier Sharing Among Operators), the RNC randomly routes these

UEs to a CN if the RNC does not receive the messages carrying IMSI information. If the CN

rejects the UE access requests or indicates that CS/PS coordination is required, the CN returns

the UE IMSI to the RNC. The RNC then obtains the PLMN from the IMSI and routes the UEs

to the CN of the operators who share the RNC according to the predefined roaming

relationships and proportions. If the roaming UEs are supporting-UEs (supporting network

sharing), this feature is not applied.



Enhancement

None

Dependency


None


None




None



5.1.18 WRFD-140223 MOCN Cell Resource Demarcation

Availability




Summary

When the Multi-Operator Core Network (MOCN) function is enabled, operation and

maintenance (O&M) personnel can predefine the percentage of cell resources available to

UEs of each operator involved. If a cell has idle resources, the UEs of each operator can use

more resources than their predefined resource percentage. However, when the cell resource

usage reaches a specified threshold, the percentage of resources occupied by the UEs of each

operator needs to be controlled as follows:

During admission control, the RNC allows a new UE to preempt resources occupied by a

UE whose operator exceeds the predefined resource percentage.

During congestion control, the RNC preferentially selects UEs whose operator exceeds

the predefined resource percentage the most.

Benefits

By sharing frequencies among operators, this feature maximizes resource utilization and

keeps resource usage of each operator during busy hours close to their respective predefined

resource percentage. This provides a mechanism for defining resource allocation among

operators and prevents the UEs of an operator from occupying excessive resources.

Description

The percentage of downlink code resources assigned to R99 users (DL R99 code resources for

short) available to UEs of each MOCN-enabled operator is configurable at the cell level.

When the total DL R99 code resource usage in a cell reaches a specified threshold, the RNC

allows a new UE to preempt resources occupied by a UE whose operator exceeds the

predefined resource percentage during admission control, based on the code resource usage of

each operator. As usual, the RNC preferentially selects the UE with the lowest priority for

preemption.

If the cell is congested, the RNC analyzes the cause of the congestion. If the congestion is

caused by insufficient DL R99 code resources, the RNC preferentially selects UEs whose

operator exceeds the predefined percentage of DL R99 code resources for load reshuffling

(LDR).

The percentage of HSDPA power available to UEs of each MOCN-enabled operator is

configurable at the cell level. The RNC informs the NodeB of the percentage. The NodeB

calculates the HSDPA power usage of UEs of each operator and adjusts the scheduling

priority of UEs of this operator. The difference between the predefined percentage and the

HSDPA power usage of UEs of an operator increases with the scheduling priority of the UEs

of this operator.

When HSDPA power usage in a cell reaches a specified threshold, the RNC allows a new UE

to preempt resources occupied by a UE whose operator exceeds predefined HSDPA power

percentage during admission control, based on the guaranteed bit power (GBP) usage of each

operator.

You are not advised to use this feature with WRFD-010696 DC-HSDPA. That is because

enabling DC-HSDPA affects power measurement accuracy.

Enhancement

None



Dependency


None


Only the 3900 series base stations configured with the WBBPb, WBBPd or WBBPf board



None


None


None



5.1.19 WRFD-150213 MOCN Independent Iub Transmission Resource Allocation

Availability


Summary

This feature allocates Iub user-plane transmission resources to operators in multi-operator

core network (MOCN) scenarios.

Benefits

This feature prevents one operator from occupying excess Iub user-plane transmission

resources in MOCN scenarios and ensures that operators retain independent Iub user-plane

transmission resources.

Description

Iub transmission resources can be logically divided into user- and control-plane transmission

resources.

In MOCN scenarios, this feature allocates user-plane bandwidth to each operator

independently and enables operators to share control-plane bandwidth and the common

channel bandwidth in a shared cell. The following figure shows the details.



To allocate user-plane bandwidth to each operator independently, the RNC is configured with

different logical ports, with each logical port corresponding to one operator; after identifying

the UE's operator, the RNC sends the UE's user-plane data to the corresponding logical port.

This feature applies to the following scenarios:

Scenario 1: Operators share one physical link over the Iub interface.

Scenario 2: Each operator uses a dedicated physical link over the Iub interface.



Enhancement

None

Dependency


This feature does not support BSC6910 IP transmission.


None

Dependency on UEs

None


None


None


This feature depends on WRFD-021311 MOCN Introduction Package. This feature cannot be

used with WRFD-02130501 Dedicated Iub Transmission Control or WRFD-140208 Iub

Transmission Resource Pool in RNC.

5.1.20 WRFD-150214 MOCN Independent CE Resource Allocation

Availability


Summary

This feature allocates a NodeB's uplink and downlink channel element (CE) resources to

operators in MOCN scenarios.

Benefits

This feature prevents one operator from occupying excess CE resources in MOCN scenarios.

This ensures that each operator retains independent CE resources.

Description

This feature provides the following functions:

The M2000 allocates a NodeB's uplink and downlink CE resources to operators.

When distributing CE licenses, the M2000 allocates a NodeB's uplink and downlink CE

resources by configuring private and common groups. The CE resources in a private



group belong to only one operator. The CE resources in the common group can be shared

by all operators. The following figure shows the details.

After identifying a UE's operator, the NodeB allocates the CE resources in the operator's

private group to the UE.

After dividing the CE resources into different groups and identifying a UE's operator, the

NodeB allocates the CE resources in this operator's private group to the UE. An operator

can use the CE resources in the common group only after the CE resources in its private

group are used up. The CE resources in the common group are used on a first come, first

served basis.

The RNC relieves CE congestion for each operator separately.

If the available CE resources for an operator are insufficient, the RNC relieves CE

congestion for this operator by reducing the BE service rate for some users or adjusting

the transmission time interval (TTI) for HSUPA users from 2 ms to 10 ms.

Enhancement

None

Dependency


None


Only the 3900 series base stations configured with the WBBPb, WBBPd, or WBBPf board


Dependency on UEs

None


None


None


This feature depends on WRFD-021311 MOCN Introduction Package. This feature cannot be

used with WRFD-021304 RAN Sharing Introduction Package.



5.2 Topology Enhancement

5.2.1 WRFD-021200 HCS (Hierarchical Cell Structure)

Availability



Summary

This feature complies with the hierarchical cell structure (HCS) as stipulated in 3GPP

specifications. It enables the UE to be handed over to the relevant hierarchical cell according

to its moving speed.

Benefits Improve the conversation quality for fast-moving UEs.

Improve the system capacity.

Reduce the signaling load by decreasing the unnecessary handover.

Description

In 3G networks, the so-called hot spots in radio communications may appear with the increase

of subscribers and traffic. This requires more cells to expand the network capacity. More cells

and smaller cell radius indicate that more frequent handovers of UEs take place. For a UE at a

fast speed, frequent handovers reduce call quality, increase uplink interference, and increase

signaling load.

In this situation, Hierarchical Cell Structure (HCS) is required to divide cells into different

hierarchies and up to 8 hierarchies are supported.

Cell Type Characteristics

Macro Cell Large coverage

Continuous coverage networking

Low requirement on capacity

Fast-moving environment

Micro Cell Densely populated areas

High requirement on capacity

Slow-moving environment

Pico Cell Indoor coverage

Outdoor dead-area coverage

Where, the Pico cell has the highest priority and the macro cell has the lowest priority.



Speed Estimation

The speed estimation on each hierarchy of an HCS cell falls into one of the following

types:

− Fast speed

− Normal speed

− Slow speed

According to the number of changes of the best cell within time unit, speed estimation

algorithm estimates the moving speed of the UEs. See details as follows:

− If the number of changes of best cell for a UE is above the fast-speed threshold, this

UE is decided in fast speed;

− If the number of changes of best cell for a UE is below the slow-speed threshold, this

UE is decided in slow speed;

− If the number of changes of best cell for a UE is between fast-speed threshold and

slow-speed threshold, this UE is decided in normal speed.

HCS Handover Based on Speed Estimation

After the moving speed of the UE is estimated, inter-hierarchy handover algorithm

initiates the corresponding handover based on this speed decision.

According to the results of speed estimation,

− The UE in fast speed is handed over to the cell of lower priority.

− The UE in slow speed is handed over to the cell of higher priority.

− The UE in normal speed is not required to be handed over to any cell.

According to speed estimation, the RNC orders the fast-moving UE to handover to the cells of

lower priority to reduce the number of handovers, and orders the slow-moving UEs to

handover to the cells of higher priority to increase network capacity.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None




None

5.2.2 WRFD-020111 One Tunnel

Availability



Summary

This feature works between the RNC and the GGSN on the UMTS core network. It is a

feature defined by 3GPP R7.

This feature has been enhanced in RAN14.0 so that it supports One Tunnel between the RNC

and the S-GW on the evolved packet core (EPC). The S12 interface is used between these two

network elements (NEs). The enhanced feature is defined by 3GPP R8.

Benefits

This feature further simplifies mobile packet data networks. By using the optimal lines on

networks, this feature significantly reduces the number of the data links required and thereby

achieves a flat user plane. This feature is particularly suitable for 3G networks. With this

feature, telecom operators can make the most of their investments in network construction,

easily expand their networks, and lower the operation and maintenance costs. In addition,

evolution to LTE is convenient.

Description

Based on the traditional 3G network architecture, One Tunnel is an innovative technique for

network optimization. The SGSN is responsible for establishing a direct tunnel from the RNC

to the GGSN. User-plane data is transmitted over this direct tunnel instead of being

transmitted through the SGSN. This achieves a flat user plane. On a traditional UMTS

network, there is a tunnel between the GGSN and the SGSN, and there is another tunnel

between the SGSN and the RNC, as shown in the upper portion of the following figure. Data

on both the control plane and the user plane is transmitted between the RNC and the GGSN

through the SGSN. This is known as Two Tunnel (two GTP tunnels).

With Two Tunnel, user-plane data of PS services is forwarded to the GGSN by the SGSN.

Amid the rapid increases in the PS traffic volume, the user-plane capacity of the SGSN is

becoming a bottleneck. One Tunnel is the solution to this problem. With One Tunnel, a direct

tunnel is established between the RNC and the GGSN for the user-plane data of PS services,

as shown in the lower portion of the following figure. The SGSN works as the central control

point for One Tunnel. Control-plane data is still transmitted between the RNC and the GGSN

through the SGSN. User-plane data is directly transmitted between the RNC and the GGSN.

One Tunnel between the RNC and the GGSN was first introduced in 3GPP R7.

Figure 5.2.2-1 One Tunnel between RNC and GGSN



Enhancement

One Tunnel has been enhanced in RAN14.0. Without One Tunnel, two tunnels are used for

UMTS/LTE interoperability, one between the RNC and the SGSN and the other between the

SGSN and the S-GW. One Tunnel between the RNC and the S-GW was introduced in 3GPP

R8. The S12 interface is used to achieve One Tunnel between the RNC and the S-GW. With

One Tunnel, a direct tunnel is established between the RNC and the S-GW. User-plane data is

directly transmitted between the RNC and the S-GW. This way, the SGSN will not become a

bottleneck for UMTS/LTE interoperability, and telecom operators do not need to upgrade the

SGSN frequently.

Figure 5.2.2-2 S12 between RNC and Serving Gateway

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None




The serving gateway (S-GW) must support this feature.

Dependency on CN

The GGSN must support this feature.


None


Recommend to deploy this feature with UMTS RAN Network Design Service

5.3 ATM Transmission

5.3.1 WRFD-050405 Overbooking on ATM Transmission

Availability


Summary

This feature improves the usage efficiency in ATM transmission scenarios.

Benefits

This feature provides a method for greatly saving OPEX on ATM transmission, especially on

the Iub Interface, and when deploying HSDPA high speed service.

Description

Overbooking on ATM transmission is used to improve the usage efficiency on ATM

transmission scenario, and this feature comprises of following two parts:

Overbooking on Call Admission Control and basic congestion control

Fast inner loop backpressure on the interface board

I. Overbooking on Call Admission Control and Basic Congestion Control

Transmission rate of the data service varies in different periods. For example, data flow is

generated when you are downloading a webpage, but no data flow is generated when you are

browsing the webpage. Therefore, there is a high peak/average ratio between the actual

transmission rate and the channel transmission rate. And this can be represented by activity

factor of each service type. Such activity factor can be configured as a network requirement.

The thought of the Iub overbooking is that the transmission bandwidth of the Iub interface is

allocated according to a certain activating ratio instead of 100% of the maximum traffic ratio

when the admission is performed. As a result, the bandwidth shared by multiple users may not

meet the requirements for peak rate transmission. In this case, efficiency of using the bandwidth on the Iub interface becomes quite low if no flow control is performed on the RNC.



The reason for such a case is that random packet loss on the Iub interface leads to PDU

re-transmission by the RLC and the transmission rate is degraded when the time delay for

transmitting TCP packet increases and the TCP flow control starts.

To solve this problem, packet loss on the Iub interface should be avoided and ensure that the

time delay for transmitting TCP packets is not affected by the packet loss.

To configure the re-transmission threshold and explain the Iub overbooking solution, two

events are defined: event A and event B:

When the re-transmission rate is continuously greater than the high threshold, event A is

reported from RLC to MAC-d and the latter one will inhibit the maximum current TFI.

If the re-transmission rate is continuously smaller than the low threshold, event B is

reported from RLC to MAC-d and the upper-level TFI inhibited previously is restored.

With this basic congestion control mechanism which applied in RLC and MAC player, the

data rate will be decreased immediately, but since data loss has occurred, the gain of

transmission resource usage efficiency and user feeling will be affected accordingly.

Therefore, the second part of this feature is introduced to enhance the performance farther.

II. Fast inner loop backpressure on the interface board

Such fast inner loop backpressure mechanism is implemented in the interface board and it

works as described below:

The RNC monitors the Buffer Occupancy (BO) status of each physical port and VP (Virtual

Port) or VC at the Iub transport network layer user plane continuously.

If the BO exceeds congestion threshold (TH2), the system enters congestion state and a

congestion backpressure signal will be generated and sent to radio network layer user

plane. Then the RNL UP will decrease the data sending rate to release the congestion.

If the BO is lower than congestion release threshold (TH1), the system enters normal

state and a congestion release backpressure signal will be generated and sent to the RNL

UP. Then the RNL UP will increase the data sending rate.

If the BO is higher than discard threshold (TH3), the system enters extreme congestion

state and the data will be discarded at the TNL UP directly.

Time

TH1

TH3

TH2

Buffer Occupancy

Time

TH1

TH3

TH2

Buffer Occupancy



RNL User Plane

Iub TNL User Plane

① ② ④ ⑤③

From CN

To NodeB

RNL User Plane

Iub TNL User Plane

① ② ④ ⑤③

From CN

To NodeB

Since this backpressure mechanism works in the 10ms level, generally data loss will not occur

and Iub bandwidth usage efficiency is greatly increased accordingly.

This mechanism depends on the ATM interface board on RNC like AOU/UOI/AUE, and

NodeB must be connected to RNC directly through ATM interface board. It is not applied for

Hub NodeB.

Enhancement

In RAN6.1, fast inner loop backpressure feature based on VC is supported for ATM transport.

In RAN10.0, fast inner loop backpressure feature based on port and VP is supported for ATM

transport.

Dependency

Dependency on RNC

The backpressure and VP shaping mechanism depends on the ATM interface board on RNC

like AOUa/UOIa/AEUa/AOUc/UOIc.

Dependency on NodeB

The BTS3902E cannot support this feature.

Dependency on UE

None


None

Dependency on CN

None




None

5.3.2 WRFD-050105 ATM Switching Based Hub NodeB

Availability

This feature is available from RAN 5.1

Summary

With this feature, Huawei NodeB is capable of transmission convergence in ATM transport

mode.

Benefits

This feature can provide the convergence gain and reduce the cost of transmission lines.

Description

The ATM switching based hub NodeB extends the tree topology, as shown in the following

figure.

The hub NodeB is connected to the RNC through the STM-1 or E1 port. The hub NodeB is

connected to the cascaded NodeBs through the E1 port. The NodeBs are converged on the hub

NodeB and then connected to the RNC. ATM transmission convergence implements the

convergence gain on the Iub interface.

RNC

NodeB

Hub NodeB

NodeB

NodeB

NodeB

NodeB

NodeB

ATM transmission convergence consists of PVC convergence and AAL2 convergence. The

following figure shows the topology of PVC convergence. PVC convergence is implemented

on the basis of tree-link PVC and group bandwidth management technologies. The PVC

convergence function of the hub NodeB can implement switching between PVC 1 and PVC A

(NodeB 1), between PVC 2 and PVC B (NodeB 2), and between PVC 3 and PVC C (NodeB



3). The RNC provides the group bandwidth management function to ensure that downstream

NodeBs and hub NodeB can share the transmission bandwidth of the Iub interface.

Physical link

Hub NodeB

Physical link

PVC A

PVC B

PVC C

PVC

PVC 1

PVC 2

PVC 3

NodeB 1

NodeB 2

NodeB 3

Group bandwidth management is an improvement of the CAC algorithm based on AAL2 path.

This algorithm can ensure that the total bandwidth for UE admission is smaller than that of

physical ports and the total bandwidth of all configured AAL2 paths is greater than that of

physical ports.

In PVC convergence mode, the hub NodeB can support four-level connections of downstream

NodeBs and up to 16 downstream NodeBs.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB


Dependency on UE

None


None

Dependency on CN

None


None



5.3.3 WRFD-050106 AAL2 Switching Based Hub NodeB

Availability


Summary

With this feature, Huawei NodeB is capable of AAL2 transmission convergence in ATM

transport mode.

Benefits

This feature can provide the convergence gain and reduce the cost of transmission lines.

Description

The AAL2 switching Based Hub NodeB is a feature in ATM transport mode. It is the

extension of the tree topology. The hub NodeB topology has two solutions: PVC convergence

and AAL2 Convergence. In order to achieve better congregation efficiency, the AAL2

convergence is introduced.

The AAL2 convergence is implemented through AAL2 switching. As shown in the following

figure, the bandwidth that the RNC allocates to the AAL2 paths of the NodeBs (NodeB 1,

NodeB 2, and NodeB 3) is converged and switched on the AAL2 path of the hub NodeB.

Therefore, all the NodeBs share the Iub bandwidth of the AAL2 path.

Physical link

Hub NodeB

Physical link

AAL2 Link

NodeB1

NodeB2

NodeB3PVC

PVC

The hub NodeB supports connections to 4 level downstream NodeBs in AAL2 convergence

mode. The hub NodeB supports up to 16 downstream NodeBs.

Enhancement

None

Dependency

Dependency on RNC

None



Dependency on NodeB

The DBS3800 cannot support this feature.


Dependency on UE

None


None

Dependency on CN

None


WRFD-050105 ATM Switching Based Hub NodeB

5.3.4 WRFD-050406 ATM QoS Introduction on Hub NodeB (Overbooking on Hub NodeB Transmission)

Availability

This feature is available from RAN6.0 in BSC6800.

This feature is introduced from RAN10.0 in BSC6810.

Summary

With this feature, the RNC can detect each virtual port through the VP shaping mechanism to

share the bandwidth of the Iub interface.

Benefits

This feature provides a method for greatly saving OPEX on ATM Hub NodeB transmission,

and when deploying HSDPA service.

Description

The Iub transmission aggregation is a very important method to save operator’s CAPEX. The

figure below shows an example.

NodeB1

(Hub 1)

NodeB2

(Hub 2)

NodeB3

(Leaf)

RNC

SDH Backhaul

NodeB1

(Hub 1)

NodeB2

(Hub 2)

NodeB3

(Leaf)

RNC

SDH Backhaul



When the hub NodeB transmission is applied, the RNC can be connected to more NodeBs

with only one physical port. In this case, the RNC may send out data with a high bit rate, and

if all the data is sending to one NodeB, for example, NodeB 3 in upper figure, congestion may

happen at NodeB 2 and data will be lost accordingly. In order to avoid the possible data loss,

Iub Overbooking on Hub NodeB Transmission is introduced in the RNC.

Iub Overbooking on Hub NodeB Transmission feature uses Iub Overbooking CAC (Call

Admission Control) algorithm and VP (virtual Port) shaping mechanism. The Iub

Overbooking CAC algorithm is the same as that in feature WRFD-050405.

In VP shaping mechanism, all PVCs connected to one NodeB are considered as one virtual

port; if one NodeB is a hub NodeB, all PVCs connected to it and PVCs connected to its leaf

NodeBs are considered as one virtual port only.

The VP shaping mechanism is almost the same as backpressure mechanism in feature

WRFD-050405. The difference is that the RNC monitors the buffer occupancy status of each

virtual port but not physical port when the VP shaping is applied.

With the VP shaping mechanism, data loss will not happen and Iub bandwidth can be fully

used.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB


Dependency on UE

None


None

Dependency on CN

None


WRFD-050405 Overbooking on ATM transmission



5.3.5 WRFD-050302 Fractional ATM Function on Iub Interface

Availability

This feature was first available from RAN2.0.

Summary

This feature enables ATM cells to be transmitted on some timeslots of the E1/T1 bearer and

other data to be transmitted on other timeslots. It applies to the scenario where 2G and 3G

data is transmitted simultaneously.

Benefits

ATM on Fractional supports:

Sharing of transmission links between 2G and 3G systems

Reduced time in market at initial rollout

Reduced transmission costs when 2G and 3G are co-sited

Description

The Fractional ATM mode is an ATM transport mode in the TC sub layer of ATM physical

layer.

In fractional ATM, ATM cells are transmitted by using some of the 32 E1 timeslots. ATM cells

are mapped to some of the E1 timeslots, instead of all of the timeslots. At the peer end, the

ATM cell stream is recovered from these E1 timeslots. The timeslots that are unavailable for

ATM cell transmission can transmit other information.

The E1/T1 boards can be configured for a fraction of a full E1/T1. For example, the GSM

system can share the transport links with the WCDMA system. This feature is both used for

small sites where one 2G BTS and one WCDMA BTS can share one link and when for

example 0.5 links are needed for the WCDMA BTS and there is 0.5 link free capacity for the

2G BTS. This will in many cases save the cost for installation of one link.

Enhancement

None



Dependency

Dependency on RNC

The BSC6900 must be configured with the AEUa or AOUc board.

The BSC6910 must be configured with the AOUc board.

The BSC6910 does not support fractional IMA.

Dependency on NodeB


Dependency on UE

None


None

Dependency on CN

None


None

5.4 IP Transmission

5.4.1 WRFD-050402 IP Transmission Introduction on Iub Interface

Availability



Summary

This feature enables the Iub interface to be carried on the IP network.

Benefits

This feature provides a new Iub transport solution for operator. With IP transmission,

transport cost will decrease greatly with HSDPA/HSUPA service compared with ATM

transport cost.

Description

Huawei RNC provides the following physical port types on Iub IP transmission solution to

support different networking requirements:

E1/T1



FE

GE (with LAN Switch in BSC6800)

STM-1/OC-3c(POS (Packet Over SDH), BSC6900 only)

Channelized STM-1/OC-3(CPOS (Channelized POS), BSC6900 only)

Huawei NodeB provides the following physical port types on Iub IP transmission solution to

support different networking requirements:

E1/T1

Electrical FE

Optical FE (3900 NodeB only)

Electrical GE (3900 NodeB only)

Optical GE (3900 NodeB only)

The following features are also included:

Compliance with 3GPP R5 TR25.933

Support GE/FE/E1/T1/channelized STM-1/channelized OC-3/STM-1/OC-3c physical

interface

Support Diffserv mechanism and IEEE802.1P

Support IPV4

Support IP head compression

Support ML-PPP and MC-PPP, RAN11.0 NodeB support ML-PPP combined two

transmission card

Support DHCP, PPP Mux and VLAN

Support 1+1 and 1:1 MSP

The following figure shows the IP networking on the Iub Interface.



Besides the transport layer change (for example, M3UA, SCTP), the Iub IP brings about some

changes in CAC as well as service differentiation.

In CAC, IP PATH is defined as the connection between RNC and NodeB. Each IP PATH is

configured with the maximum DL PATH bandwidth and the maximum UL PATH bandwidth

by operators. When a new call is coming, RNC will compare the required service bandwidth

with the available IP PATH bandwidth for UL and DL. If the IP PATH bandwidth available for

use is insufficient, the call is rejected. If the call is admitted, RNC will reserve the bandwidth

and mark it as being used.

The Iub IP adopts the DiffServ for QoS differentiation, similar to the differentiated ATM PVC.

PHB is defined according to the traffic type, each PHB having a DSCP (DiffServ Code Point)

and priority.

BEPS Background

AF1PS Interactive

AF3PS Streaming

AF4PS Conversational

EFCS

EFSRB

EFCommon Channels

PHB(Per Hop Behavior)Traffic Type

BEPS Background

AF1PS Interactive

AF3PS Streaming

AF4PS Conversational

EFCS

EFSRB

EFCommon Channels

PHB(Per Hop Behavior)Traffic Type

6B'000000BE

5B'001010AF1

4B'010010AF2

3B'011110AF3

2B'100110AF4

1B'101110EF

Prior Queue #DSCPPHB

6B'000000BE

5B'001010AF1

4B'010010AF2

3B'011110AF3

2B'100110AF4

1B'101110EF

Prior Queue #DSCPPHB

RAN14.0 supports the whitelist, VLAN-based packet filtering, and malformed packet attack

defense functions.



Enhancement

In RAN10.0, the BSC6810 supports the POS/CPOS interface (UOIa and POUa).

RAN10.0, when the gateway or peer entity is faulty, this feature enables the RNC to detect the

link fault and then trigger IP re-route or board switch, avoiding packet loss and call drop.

RAN11.0 NodeB support ML-PPP combined two transmission card.

RAN13.0 Iub support RNC and NodeB integrated firewall

RNC integrated firewall include the following factions:

The internal firewall inspects the incoming IP data over the OM interface and provides the

following functions:

IP address filter. This technique allows only the IP data from authorized IP addresses and

network segments.

Safeguard against attacks of ICMP ping, IP fragments, low TTL, smurf, and DDos.

Safeguard against attacks of TCP sequence prediction, and SYN flood.

The internal firewall inspects the incoming IP data over the Iub, Iur, and Iu interfaces and

provides the following functions:

Intelligent white-listing: With this function, only data from permissible peer IP addresses and

ports and data of permissible protocol types can access the RNC.

Safeguard against ARP and ICMP flood

Safeguard against malformed packets

Limiting speed of the broadcast messages

NodeB integrated firewall include the following functions:

The internal firewall inspects incoming all the IP data including maintenance data, control

plane data and user plane data and provides the following functions:

White-listing: With this function, only data from permissible peer IP addresses and ports

and data of permissible protocol types can access the NodeB. Ping denial function will

be supported; NodeB will drop the ICMP packets in this mode.

Maintenance data, control plane data and user plane data of 3900 series NodeB and

Maintenance data and control plane data of BTS3812E/AE and DBS3800 will filter by

White-listing function.

Safeguard against Address Resolution Protocol (ARP) and Internet Control Message

Protocol (ICMP) flood

Since RAN14.0, white-listing, VLAN packet filtering, and tool-based protection against

malformed packets are supported.

Broadcast-message speed limiting

The BSC6910 supports 10 GE interface boards from RAN15.0.

From RAN15.0 onwards, IP paths do not need to be configured, simplifying the transmission network configuration. When IP paths are not configured, each adjacent node is configured



with a transmit bandwidth and a receive bandwidth, which are configurable for operators.

When a new call is initiated, the RNC compares the required service bandwidth with the

available transmit bandwidth and receive bandwidth of the adjacent node. If the bandwidth

available for use is insufficient, the call is rejected. If the call is admitted, RNC reserves the

bandwidth and marks it as in use.

Dependency

Dependency on RNC

BSC6900

Only the PEUa, POUa, and POUc boards support IP head compression.

Only the DOPRA Linux operating system supports the RNC integrated firewall for the

OM interface.

Only the FG2c and GOUc boards support the RNC integrated firewall.

Only the FG2a, FG2c, GOUa, and GOUc boards support BFD.

10 GE interface boards are not supported.

BSC6910

All IP interface boards support the RNC integrated firewall and BFD.

10 GE interface boards are supported.

IP over E1 is not supported.

IP head compression is not supported.

PPP, MC-PPP and PPP Mux are not supported.

IP paths and IP-path-based bandwidth configuration are not supported.

Trunks support the active/standby mode, but ports do not support it.

Dependency on NodeB

NUTI board is needed with BTS3812E/AE to support this feature.

Only the 3900 series NodeB supports inter-board ML-PPP.

Dependency on UE

None


None

Dependency on CN

None


None




Recommend to deploy this feature with following services:

New construct scenario: UMTS RAN Network Design Service,

Re-construct scenario: UMTS IP RAN Evolution Service

5.4.2 WRFD-050411 Fractional IP Function on Iub Interface

Availability


Summary

This feature enables IP packets to be transmitted on some timeslots of the E1/T1 bearer and

other data to be transmitted on other timeslots. This feature mainly applies to the scenario

where the 2G Abis interface shares the 3G transport network.

Benefits Sharing of transmission links between 2G and 3G systems

Reduced time in market at initial rollout

Reduced transmission costs when 2G and 3G are co-sited

Description

In fractional IP, IP packages are transmitted using some of the 32 E1 timeslots. IP packages

are mapped to some of the E1 timeslots, instead of all of the timeslots. At the peer end, the IP

package is recovered from these E1 timeslots. The timeslots that do not use for IP package

transmission can transmit other information.

The E1/T1 boards can be configured for a fraction of a full E1/T1. This is for instance useful

when a 2G system, like GSM, shall share the transport links with the WCDMA system. This

feature is both used for small sites where one 2G BTS and one WCDMA BTS can share one

link and when for example 0.5 links are needed for the WCDMA BTS and there is 0.5 link



free capacity for the 2G BTS. This will in many cases save the cost for installation of one

link.

Enhancement

None

Dependency


The BSC6900 must be configured with the PEUa, POUa, or POUc board.





None


None


None


WRFD-050402 IP Transmission Introduction on the Iub Interface

5.4.3 WRFD-050403 Hybrid Iub IP Transmission

Availability


Summary

This feature enables the transmission of real-time services and non-real-time services on

different paths to meet the requirements of UMTS services.

Benefits

This feature provides a method for saving OPEX on Iub transmission, especially when

deploying HSDPA/HSUPA service.

Description

The hybrid IP is a kind of innovative transmission solution provided by Huawei to meet the

requirements of different services in UMTS. That is, it transmits real-time service and



non-real-time service on different paths. Two kinds of hybrid transmissions are available:

FE+E1/T1 and FE+FE.

With the introduction of HSDPA technology and the capacity increase over the air interface,

the demand on Iub transmission bandwidth increases greatly. If E1 LL (Lease Line) is adopted,

the operator would need to rent a large amount of circuit, and it may be very expensive to rent

and maintain the transport network. The requirement of different service in 3G is quite

different in transport bandwidth, BER and timing delay.

Considering the requirement of cost and QoS, the Iub hybrid transmission is introduced with

Iub IP transmission. The Iub hybrid transmission considers the service difference and select

different transport physical layer or transport path for different services. Real-time services

such as voice and streaming data services are transported on IP over E1/STM-1, while

non-real-time services such as interactive and background services are transported on IP over

Ethernet, as shown in the following figure.

In RAN10.0, Resiliency Hybrid Iub IP Transmission solution is introduced. Iub user plane

traffic and Iub NBAP signaling can be carried over hybrid networks on backup mode. When

one path fails, all the new coming traffic is carried on another path.

Enhancement

In RAN10.0, Resiliency Hybrid Iub IP Transmission solution is introduced.

Dependency

Dependency on RNC


Dependency on NodeB


Dependency on UE

None


None



Dependency on CN

None


WRFD-050402 IP Transmission Introduction on Iub Interface





5.4.4 WRFD-050404 ATM/IP Dual Stack NodeB

Availability


Summary

This feature enables Huawei NodeB to support hybrid transmission based on ATM and IP.

With this feature, the services with different QoS requirements can be carried on the links of

different protocols. In addition, transmission backup can be implemented by this feature.

Benefits

This feature provides smooth upgrading from ATM transmission to IP transmission on the Iub

Interface. It helps protect operator’s investment and provide flexible networking.

Description

This feature helps protect operator’s investment and provide flexible networking. For existing

ATM network expansion, operator can overlay IP network in the existing ATM network. The

RNC can support IP NodeB or ATM NodeB, so you can add IP NodeB in the existed ATM

network.

Moreover, the NodeB can support ATM and IP dual protocol. You can add an interface card or

modify the configuration to get Iub IP network with existed ATM network, which has no

effect to the existed configuration. For example:

You can add a NUTI board to support IP transmission in a ATM NodeB which has only

NDTI board;

You can upgrade NodeB configuration to support IP transmission in a ATM NodeB has

NUTI board;



In RAN10.0, Resiliency solution is introduced. Iub user plane traffic and Iub NBAP signaling

can be carried over ATM network and IP network on backup mode. When one path fails, all

the new coming traffic is carried on another path.

Enhancement

In RAN10.0, Resiliency ATM/IP dual stack NodeB Transmission solution is introduced.

Dependency

Dependency on RNC

The BSC6910 does not support load balance based on the admission bandwidth.

Dependency on NodeB


Dependency on UE

None


None

Dependency on CN

None









5.4.5 WRFD-050409 IP Transmission Introduction on Iu Interface

Availability



Summary

This feature enables the Iu interface to be carried on the IP network.

Benefits

This feature provides a new Iu transport solution for operator. With IP transmission, transport

cost will decrease greatly compared with ATM transport cost.

Description

This feature provides Iu over IP transport solution including the following features:


Support IP over FE electrical interface

Support IP over GE electrical interface and GE optical interface

Support IP over STM-1/OC-3c optical interface (POS (Packet Over SDH)) (BSC6900

only)

Support IP over channelized STM-1/OC-3 optical interface(CPOS (Channelized POS))

(BSC6900 only)

Support IuCS over IP over E1/T1 physical interface (BSC6900 only)


Support IPV4


Support ML-PPP and MC-PPP

Support PPP Mux and VLAN

Support FE/GE 1+1 backup redundancy

Support FE/GE load share redundancy

Support STM-1/OC-3c 1+1 and 1:1 MSP

Support channelized STM-1/OC-3 1+1 and 1:1 MSP

IP networking solution can be L1, L2, L3 networking on Iu interface similar to that on the Iub

Interface.

Besides the transport layer change, Iu IP brings some changes in CAC as well as service

differentiation

In CAC, IP PATH is defined as the connection between RNC and CN. Each IP PATH is



with the available IP PATH bandwidth for UL and DL. If available IP PATH bandwidth is



insufficient, the call is rejected. If the call is admitted, RNC will reserve the bandwidth and

mark it as being used.

Enhancement

In RAN10.0, the BSC6810 supports the POS/CPOS interface (UOIa and POUa).

In RAN10.0, when the gateway or peer entity is faulty, this feature enables the RNC to detect

the link fault and then trigger IP re-route or board switch, avoiding packet loss and call drop.

In RAN13.0, RNC integrated firewall is supported, which include the following functions:




network segments.











From RAN15.0 onwards, IP paths do not need to be configured, simplifying the transmission

network configuration. If IP paths are not configured, each adjacent node is configured with a

transmit bandwidth and a receive bandwidth, which are configurable for operators. When a

new call is initiated, the RNC compares the required service bandwidth with the available

transmit bandwidth and receive bandwidth of the adjacent node. If the bandwidth available for

use is insufficient, the call is rejected. If the call is admitted, RNC reserves the bandwidth and

marks it as in use.

Dependency

Dependency on RNC

BSC6900


OM interface.




BSC6910






PPP, MC-PPP, and PPP Mux are not supported.



Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

CN should support IP transportation.


None





5.4.6 WRFD-050410 IP Transmission Introduction on Iur Interface

Availability



Summary

This feature enables the Iur interface to be carried on the IP network.

Benefits

This feature provides a new Iur transport solution for operator. With IP transmission, transport

cost will decrease greatly compared with ATM transport cost.



Description

This feature provides Iur over IP transport solution including the following features:


Support GE/FE/E1/T1 physical interface

Support IP over FE electrical interface

Support IP over GE electrical interface and GE optical interface (BSC6900 only)

Support IP over STM-1/OC-3c optical interface (POS (Packet Over SDH)) (BSC6900

only)

Support IP over channelized STM-1/OC-3 optical interface(CPOS (Channelized POS))

(BSC6900 only)

Support IP over E1/T1 physical interface (BSC6900 only)


Support IPV4


Support ML-PPP and MC-PPP

Support DHCP, PPP Mux and VLAN

Support FE/GE 1+1 backup redundancy

Support FE/GE load share redundancy

Support STM-1/OC-3c 1+1 and 1:1 MSP

Support channelized STM-1/OC-3 1+1 and 1:1 MSP

IP networking solution can be L1, L2, L3 networking on Iur interface similar to that on the

Iub Interface.

Besides the transport layer change, Iur IP brings some changes in CAC as well as service

differentiation.

In CAC, IP PATH is defined as the connection between SRNC and DRNC. Each IP PATH is



with the available IP PATH bandwidth for UL and DL. The call will be rejected if no enough

IP PATH bandwidth is available. After the call is admitted, RNC will reserve bandwidth as in

use.

The Iub IP adopts the DiffServ for QoS differentiation, similar to the differentiated ATM PVC.

PHB is defined according to the traffic type, each PHB having a DSCP (DiffServ Code Point)

and priority.

Enhancement

In RAN10.0, packet over STM-1/OC-3c is supported.

In RAN10.0, packet over channelized STM-1/OC-3 is supported.

In RAN10.0, when the gateway or peer entity is faulty, this feature enables the RNC to detect

the link fault and then trigger IP re-route or board switch, avoiding packet loss and call drop.

In RAN13.0, RNC integrated firewall is supported, which include the following functions:






network segments.











From RAN15.0 onwards, IP paths do not need to be configured, simplifying the transmission

network configuration. If IP paths are not configured, each adjacent node is configured with a

transmit bandwidth and a receive bandwidth, which are configurable for operators. When a

new call is initiated, the RNC compares the required service bandwidth with the available

transmit bandwidth and receive bandwidth of the adjacent node. If the bandwidth available for

use is insufficient, the call is rejected. If the call is admitted, RNC reserves the bandwidth and

marks it as in use.

Dependency

Dependency on RNC

BSC6900


OM interface.




BSC6910




PPP, MC-PPP, and PPP Mux are not supported.





Dependency on NodeB

None

Dependency on UE

None


The neighboring RNC should also support IP transportation.

Dependency on CN

None


None





5.4.7 WRFD-050420 FP MUX for IP Transmission

Availability


Summary

This feature enables the multiplexing of FP packets on the IP network to improve the

transmission efficiency.

Benefits Save IUB IP transport resource to provide higher transport efficiency for IUB IP

transport.

Without FP MUX, the efficiency for voice packet is less than 50%; with FP-MUX, the

efficiency for voice packet is up to 80%.

Description

When IP transport is adopted for Iub interface, the packet of user plane is encapsulated within

UDP/IP/L2, the UDP, IP and L2 encapsulated head is too large for short packet, which leads

to the low transport efficiency.

Packet multiplexing is adopted to enhance the transport efficiency. Using FP MUX feature,

multiple FP packets with same source IP, destination IP and DSCP (DiffServ Code Point) are

packed into one UDP/IP packet, with compressed UDP information. Since less packet head,

higher transport efficiency is achieved.



FP MUX is Huawei proprietary protocol. RNC and NodeB must support this feature

simultaneously.

Enhancement

None

Dependency


The BSC6900 supports this feature when the FG2a, FG2c, GOUa, GOUc, or POUc

board is used.


None


None


None


None



5.4.8 WRFD-050422 Dynamic Bandwidth Control of Iub IP

Availability


Summary

This feature enables the RNC to adjust the available transport bandwidth according to the

packet loss rate and jitter on links detected by IP PM.

Benefits

When the packet loss or jitter increases, RNC will reduce the transmitting throughput to

alleviate and eliminate congestion. Therefore, there is less packet loss and jitter, less packet

retransmission rate, and the transport efficiency is enhanced.

Description

Following scenarios need dynamic bandwidth control:



1. ADSL and ADSL 2+ are adopted for Iub IP and the bandwidth of Iub interface is influenced

by line quality.

2. IP traffic convergence. There is congestion when multiple nodes transmit packets with large

throughput simultaneously. This will become normal when HSPA service is large deployed.

When IP transport is adopted for Iub transport, the packet is transmitted in UDP/IP format, so

there is no congestion detection and congestion elimination mechanism. If there is congestion

in the network, the delay will arise, even packet will lose. This will trigger RLC

retransmission and decrease the transport efficiency.

The dynamic bandwidth control of Iub IP adjusts the available transport bandwidth according

to the packet loss rate of link and jitter detected by IP PM (Performance Monitor). When the

packet loss rate or jitter increases, the available bandwidth decreases. When the packet loss

rate or jitter decreases, the available bandwidth is increases.

The principle of IP PM is similar to that of ATM OAM PM. One end sends an FM (Forward

Monitoring) message periodically, the other end responds to the PM with the BR (Backward

Reporting) message as soon as it receives the FM message.

With FM and BR, packet loss rate of link and jitter could be calculated accordingly.

IP PM is Huawei proprietary protocol. RNC and NodeB must support this feature

simultaneously. FG2a/FG2c, GOUa/GOUc of BSC6900, WFIE of BSC6800 and NUTI of

NodeB support this feature.

Enhancement

None

Dependency

Dependency on RNC

The FG2a/GOUa/FG2c/GOUc support this feature for BSC6900.


Dependency on NodeB

None

Dependency on UE

None




None

Dependency on CN

None



5.4.9 WRFD-050408 Overbooking on IP Transmission

Availability

This feature is available from RAN 6.1.

Summary

Overbooking on IP transmission can save Iub transmission resources.

Benefits

This feature can save many Iub transmission resources, reduce the transport CAPEX and

OPEX of the operator, and improve the perception of end users.

Description

Iub Overbooking on IP Transmission feature comprises of the following three parts:

Iub Overbooking CAC algorithm on Iub IP transmission

Fast inner loop backpressure mechanism.

IP shaping and policing

The data rates of many services vary with time during transmission in UMTS RAN. For

example, the rate of voice service is 12.2 kbit/s during conversation, but very low during

silence because only a few data frames are transmitted.

If the RNC allocates the maximum bandwidth for each service, many Iub transport resources

will be wasted. For example, downloading a 50 KB page takes only about one second, but

reading this page needs tens of seconds. In this case, over 90% of the Iub transport bandwidth

is wasted which means a lot of service rejections and a small Iub bandwidth usage.

Service actually occupied bandwidth can be estimated through the activity factor of the

service. Based on the activity factor, the RNC allocates a proper Iub transport bandwidth for

the service to make the RNC admit service as much as possible. More traffic is admitted,

more statistics multiplexing gain could be get. This is called Iub Overbooking CAC

algorithm.

With Iub Overbooking CAC algorithm, more services are admitted than without overbooking

CAC. However, a potential problem is: if all services transmit with data rate higher than

admitted bandwidth simultaneously, congestion on the Iub Interface will happen and packets

will lose. As a result, the end user perception is bad and Iub bandwidth usage is not optimal.

Also, this will disable the Iub overbooking CAC algorithm.



To solve possible data congestion, a fast inner loop backpressure mechanism is also

implemented in system. It is described as follows:

RNC monitors the buffer occupancy situation of each physical port and logic port at the Iub

transport network layer user plane continuously.

If the BO exceeds congestion threshold (TH2), the system enters congestion state and a

congestion backpressure signal will be generated and sent to radio network layer user plane.

Then the RNL UP will decrease the data sending rate to release the congestion.

If the BO is lower than congestion release threshold (TH1), the system enters normal state and

a congestion release backpressure signal will be generated and sent to RNL UP. Then the RNL

UP will increase the data sending rate.

If the BO is higher than discard threshold (TH3), the system enters extreme congestion state

and data will be discarded at the TNL UP directly.

Time

TH1

TH3

TH2

Buffer Occupancy

Time

TH1

TH3

TH2

Buffer Occupancy

RNL User Plane

Iub TNL User Plane

① ② ④ ⑤③

From CN

To NodeB

RNL User Plane

Iub TNL User Plane

① ② ④ ⑤③

From CN

To NodeB



With the backpressure mechanism, data loss will not occur and Iub bandwidth usage is

optimal.

IP shaping and policing feature is also supported and provides the virtual port traffic shaping

function. All data between RNC and NodeBs are classified and put into separate queues by

different service type. With IP shaping, RNC builds several logical ports on one physical port.

Each logical port has its queues for buffering and all logical ports are scheduled as a whole for

IP transmission. RNC monitors the buffer occupancy of each virtual port as well as total

buffer occupancy of physical port. With this feature, transport congestion and packet loss

could be effectively eliminated in the scenario of limited transport bandwidth.

For example, FE or GE is used in RNC side and E1 is adopted in NodeB side, the bandwidth

for such NodeB is limited by E1. Without IP shaping, RNC will transmit the traffic at the

physical bandwidth of FE or GE, the throughput to the NodeB would exceed the bandwidth of

Iub interface, and cause congestion and packet loss. The transport efficiency will degrade due

to packet loss and retransmission.

Enhancement

In RAN10.0, fast inner loop backpressure based on logical ports is supported.

Dependency

Dependency on RNC

All IP interface boards in the BSC6900 support the backpressure mechanism.

The BSC6900 supports IP shaping when the FG2a, FG2c, GOUa, GOUc, or UOIa

interface board is used.

The EXOUa interface board in the BSC6910 does not support the backpressure

mechanism and IP shaping based on logical ports.

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



5.4.10 WRFD-050107 IP routing Based Hub NodeB

Availability




Summary

With this feature, Huawei NodeB is capable of transmission convergence in IP transport

mode.

Benefits

Reduce costs in transmission lines with the obtained convergence gain.

Description

The IP routing Based Hub NodeB is a feature in IP transport mode. It is the extension of the

tree topology, as shown in the following figure. The downstream NodeBs connect to the RNC

after the convergence at the hub NodeB. The convergence gain is obtained from this topology.

RNC

NodeB

Hub NodeB

NodeB

NodeB

NodeB

NodeB

NodeB

The hub NodeB supports connections to 2 level downstream NodeBs and provides IP routing

for downstream NodeBs. The different IP path convergence at the hub NodeB and multiplex

the Iub bandwidth. The hub NodeB supports up to 8 downstream NodeBs.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

Only 3900 series NodeB can support IP routing Based Hub NodeB.

BTS3902E does not support this feature.

Dependency on UE

None




None

Dependency on CN

None



Hub NodeB Based ATM QoS Management

5.4.11 WRFD-011500 PDCP Header Compression (RFC2507)

Availability



Summary

This feature complies with the header compression function of packet data as defined in RFC

2507. It enables the deletion of redundant information such as TCP/IP header. The system

compresses the redundant protocol header before the data is transmitted on a link. In addition,

the system can decompress the received data.

Benefits

This feature can decrease the throughput of the Uu interface and improve the efficiency of

radio links.

Description

For TCP packets in telecommunications, many fields are constant and others change with

small and predictable values. Depending on whether the fields remain constant or change in

specific patterns, some fields can be either excluded from each packet or represented in a

smaller number of bits. This is described as header compression. Header compression uses the

concept of packet stream context. A context is a set of data about field values and value

change patterns in the packet header. For each packet stream, the context is formed at the

compressor and the de-compressor. After the context is established on both sides, the

compressor can compress the packets.

For packet data, TCP/IP header always takes up too many bytes in the whole packet. By

compressing the header of the TCP/IP contexts, the radio link efficiency can be greatly

improved. Meanwhile, small packet data due to header compressed can shorten the data

latency as well as the RTT.

The algorithm for header compression includes:

Compressible Chain of Sub-header Judgment Algorithm

Packet Stream Judgment Algorithm



Twice Algorithm for TCP Packet Streams

Header Request Algorithm for TCP Packet Streams

Compression Slow-Start Algorithm for Non-TCP Packet Streams

Periodic Header Refresh Algorithm for Non-TCP Packet Streams

Enhancement

In RAN5.0, IP V6 header compression is supported.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should support the compression function.


None

Dependency on CN

None


None

5.4.12 WRFD-050412 UDP MUX for Iu-CS Transmission

Availability


Summary

This feature enables multiple RTP units to be encapsulated in one UDP packet on the Iu-CS

interface to improve the transmission efficiency.

Benefits

This feature improves the utilization of Iu transmission resources, protect customer

investment, and reduce operation cost.



Description

After IP transport is introduced to the Iu-CS interface, packets on the user plane are

encapsulated with RTP/UDP/IP header, which reduces the transport efficiency, especially

when short packets are concerned.

UDP multiplexing (MUX) can be used to solve the problem by adding a shorter UDP MUX

sub header which makes it possible to encapsulate multiple RTP units in one UDP packet,

therefore, less overhead and higher transport efficiency can be achieved. Such feature can be

applied no matter RTP compression is on or not.

Generally, the feature improves the Iu CS transport efficiency by 30% to 40%.

Enhancement

None

Dependency

Dependency on RNC

The BSC6900 supports this feature when the FG2a, FG2c, GOUa, GOUc, or POUc

board is used.

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

The feature requires the CS CN element (MGW) to support UDP MUX.


WRFD-050409 IP Transmission Introduction on Iu Interface

5.4.13 WRFD-140207 Iu/Iur Transmission Resource Pool in RNC

Availability


Summary

With this feature, multiple Iu or Iur interface boards form a transmission resource pool. A

network element (NE) interconnected with the RNC, such as a neighboring RNC (NRNC),

the MGW, the SGSN, or the GGSN, can access all boards in this pool. This helps balance the

load shared by these boards.



Benefits


The board and port utilization is increased.

RNC capacity expansion can be easily implemented.

Transmission configurations on the RNC side do not need to be modified and load is

dynamically balanced on the RNC side when capacity expansion or adjustment is

performed on an interconnected NE.

Description

Before this feature is introduced, Iu or Iur interface boards and their ports are configured to

work in active/standby mode. This increases the transmission reliability, but decreases board

and port utilization and expanding the RNC capacity is a difficult process.

The following figure shows the networking of an Iu/Iur transmission resource pool:

Figure5.4.14-1 Networking of an Iu/Iur transmission resource pool

Core Network

IP1

IP4

IP3

IP2

CE

CE

Interface

board 1

Interface

board 2

Interface

board 3

Interface

board 4

IP/MPLS

After this feature is activated, a transmission resource pool is set up between multiple Iu or Iur

interface boards and an NE interconnected with the RNC can access all boards in this pool.

The RNC preferentially assigns new services to a lightly loaded interface board in this pool

based on the load sharing mechanisms.

With this feature, IP addresses in an Iu or Iur transmission resource pool are connected to a

fixed gateway. Therefore, IP route configurations for the RNC do not need to be modified if

either of the following conditions is met:

New user-plane IP addresses are assigned to an interconnected NE.

Existing user-plane IP addresses of an interconnected NE are modified.

In addition, SCTP links on the control plane are carried by two interface boards in this pool

using dual homing to ensure stable link connectivity.

In an Iu or Iur transmission resource pool, interface boards can work in active/standby mode

or independent mode. When interface boards work in active/standby mode, the transmission

reliability is high and ongoing calls are not interrupted even if an interface board becomes

faulty. When interface boards work in independent mode, the board utilization is high but

ongoing calls are interrupted if an interface board becomes faulty.

This feature requires that IP routers be used between the RNC and an interconnected NE and

that the interconnected NE be able to access all boards in the Iu or Iur transmission resource pool.



Enhancement

None

Dependency


The BSC6900 supports this feature when the FG2c or GOUc board is used.

All IP interface boards in the BSC6910 support this feature.

The BSC6910 supports the active/standby mode for trunks, not for ports.


None


None


An NE interconnected with the RNC must be able to access all boards in the Iu or Iur

transmission resource pool.

Dependency on CN

None


WRFD-050409 IP Transmission Introduction on Iu Interface

or

WRFD-050410 IP Transmission Introduction on Iur Interface

Dependency on professional services

Deploying this feature on RNC transmission ports that work in active/standby mode requires

Huawei professional services.




Re-construct scenario: UMTS IP Transmission Resource Pools Migration Service

5.4.14 WRFD-140208 Iub Transmission Resource Pool in RNC

Availability




Summary

With this feature, multiple Iub interface boards form a transmission resource pool. Each

NodeB interconnected with the RNC can access all boards in this pool. This helps balance the

load shared by these boards.

Benefits


Improved board and port utilization.

Easy RNC capacity expansion. Base stations do not need to be moved from one interface

board to another when new transmission ports or boards are added.

Dynamic load balancing across Iub interface boards without moving base stations from

one interface board to another.

IP path configuration free. This improves maintainability.

Description

Before this feature is introduced, Iub interface boards and their ports are configured to work

in active/standby mode. This increases the transmission reliability but decreases board and

port utilization. In addition, because each NodeB is connected to a fixed GE port on an Iub

interface board, expanding the RNC capacity is a difficult process, especially for NodeBs with

heavy traffic.

Figure 5.4.15-1Networking of an Iub transmission resource pool

NodeB

NodeB

IP1

IP4

IP3

IP2

CE

CE

Interface

board 1

Interface

board 2

Interface

board 3

Interface

board 4

IP/MPLS

After this feature is activated, a transmission resource pool is set up between multiple Iub

interface boards and each NodeB interconnected with the RNC can access all boards in this

pool. The RNC preferentially assigns new services to a lightly loaded interface board in this

pool based on the load sharing mechanisms.

With this feature, the IP addresses in an Iub transmission resource pool are connected to a

fixed gateway. Therefore, IP route configurations for the RNC do not need to be modified

when an interconnected NodeB is undergoing capacity expansion or configuration

modification. In addition, SCTP links on the control plane are carried by two interface boards

in this pool using dual homing to ensure stable link connectivity.

In an Iub transmission resource pool, interface boards can work in active/standby mode or

independent mode. When interface boards work in active/standby mode, the transmission

reliability is high and ongoing calls are not interrupted even if an interface board becomes



faulty. When interface boards work in independent mode, the board utilization is high but

ongoing calls are interrupted if an interface board becomes faulty.

This feature requires that IP routers be used between the RNC and interconnected NodeBs and

that these NodeBs be able to access all boards in the Iub transmission resource pool.

Enhancement

None

Dependency


The BSC6900 supports this feature when the FG2c or GOUc board is used.

All IP interface boards in the BSC6910 support this feature.

The BSC6910 supports the active/standby mode for trunks, not for ports.


Only the 3900 series base stations support this feature.


None


The RNC can communicate with an interconnected NE by any route using their respective

user-plane IP addresses.

The requirements for the routers on the RNC side are as follows:

If the RNC boards work in active/standby mode, dynamic routing protocols such as Open

Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (ISIS) must

be configured on the RNC, and policy-based routing must be configured on routers.

Bidirectional Forwarding Detection (BFD) must be configured for static routes on routers.

In addition, configuring fast reroute (FRR) is recommended to implement second-level

fast reroute.


None




Deploying this feature on RNC transmission ports that work in active/standby mode requires

Huawei professional services.






Re-construct scenario: UMTS IP Transmission Resource Pools Migration Service

5.5 Satellite Transmission

5.5.1 WRFD-050104 Satellite Transmission on Iub Interface

Availability


Summary

This feature enables the transmission through satellite links on the Iub interface.

Benefits

This transmission feature is provided to support certain difficult types of geographical

application environments, such as islands, deserts or places where there is a lack of terrestrial

transmission facilities available for the operator. In this case, the operator may propose to use

satellite transmission support for Iub interface connection to the rest of the UMTS network.

Description

This function supports satellite transmission on the Iub interface, which is useful to cover

remote districts, such as an island.

When satellite transmission is applied over the Iub interface, the delay increases and the timer

in SAAL/NBAP/ALCAP should be adjusted to avoid data or link error due to transmission

delay and to meet satellite transmission requirements.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None



Dependency on CN

None


None

5.5.2 WRFD-050108 Satellite Transmission on Iu Interface

Availability


Summary

This feature allows operator to set up the Iu interface connection with Satellite Transmission.

Benefits

This transmission feature supports certain difficult types of geographical application

environments, such as islands, deserts or places where lack of terrestrial transmission facilities

available for the operator. In this case, the operator may propose to use satellite transmission

support for Iu interface connection to the core network.

Description

Satellite communication is a special form of microwave trunk communication and functions

as the supplementary and standby means of common communication methods. Satellite

communication features wide coverage, little impact by terrains, good mobility performance,

and flexible link scheduling. However, the equipment cost and link rental cost are high, and

the transmission quality is likely to be affected by environments.

The extra loopback delay of satellite transmission is usually 500 ms to 700 ms. Generally, the

delay is about 600 ms. The delay depends on the distance between the Earth station and the

satellite and the satellite technologies.

This function is available for satellite transmission on the Iu interface and can be used to

cover remote areas, such as islands.

When satellite transmission is used on the Iu interface, the transmission delay prolongs. In

addition, the SAAL/UP timers should be adjusted to avoid data error or link failure due to

transmission delay. The related parameters can be set to meet the requirements of satellite

transmission.

Enhancement

None

Dependency

Dependency on RNC

None



Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


None

5.6 Clock

5.6.1 WRFD-050501 Clock Sync on Ethernet in NodeB

Availability


Summary

This feature is introduced to provide a solution for clock synchronization in all-IP networking

mode. With this feature, the operator can keep clock synchronization for NodeBs without

changing the existing data network and adding QoS requirements of the transport network.

Benefits

The IP clock is one of the major features of the Iub interface in an all-IP network.

The NodeB supports Ethernet clock synchronization and obtains timing signals from the IP

network. This feature provides a low-cost clock solution.

Description

In ATM networking, the NodeB obtains timing signals from GPS, BITS, TDM, and so on. In

IP networking, however, there may be some problems. GPS is still available in an all-IP

network but causes inconvenience because the GPS antennas and feeders have to be presented.

Only a few NodeBs can obtain timing signals from BITS, and TDM cannot be used in all-IP

networks. Therefore, the NodeBs need to obtain timing signals from the IP network, which is

called clock synchronization on Ethernet.

The clock servers generate time stamps and send the time stamps to NodeBs, which act as

clock clients in this case. Because there is great delay in packet networks, NodeBs use an

adaptive method to get rid of the delay and restore the timing signals. The time stamps are set



in packets at the UDP layer, and then transmitted at physical layer after related packet head is

added so there will be an extra spending in bandwidth.

The following figure shows an example of networking.

Note the following information:

There are clock servers and clock clients. The servers can be placed in the network

independently, and the clients are integrated into the NodeBs.

An adaptive algorithm is taken in the system. The clock servers send time stamps, and

clock clients receive time stamps to restore the frequency.

One clock server serves a maximum of 512 NodeBs.

Two or more clock servers can be used together to improve reliability. This is optional.

The required Iub transmission bandwidth of time stamps in unicast mode is from 5 kbit/s

to 100 kbit/s for each clock client. In most cases, 25 kbit/s is recommended.

Frequency accuracy obtained in the NodeB complies with 3GPP.

Enhancement

RAN11.0 supports IEEE 1588V2.

RAN13.0 support the G.8265.1 frequency synchronization protocol which was defined based

on 1588V2 in 2010 by ITU. NodeB can work with the 3rd

party’s time server if the standard

protocol was supported by the server.

Dependency

Dependency on RNC

None

Dependency on NodeB

None



Dependency on UE

None


Huawei clock server should support this feature.

Dependency on CN

None



5.6.2 WRFD-050502 Synchronous Ethernet

Availability

This feature is available from RAN 11.0

Summary

This feature is introduced to provide a solution for clock synchronization in all-IP networking

mode. It enables the clock to be extracted and recovered from the Ethernet physical layer

(PHY). As no additional hardware is required on the NodeB and RNC sides, this feature is a

convenient solution for clock synchronization.

Benefits

The synchronous Ethernet technology is one of the key features in the solution for network

over all IP solution. It is an economical, convenient solution.

Description

The synchronous Ethernet technology extracts clock signals from the Ethernet link code flows.

It is a physical layer based clock synchronization technology. A highly precise clock is used

by the Ethernet physical layer (PHY) for data transmission. The receiving end extracts and

recovers the clock from data stream, and the high precision can be maintained. This is the

basic principle of synchronous Ethernet technology.



In NodeB, there is no extra synchronization equipment or hardware needed to realize

synchronous Ethernet technology.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

It is only applicable in 3900 series NodeB.

Dependency on UE

None


The synchronous Ethernet technology requires that all the equipment on the clock relay path

must support the synchronous Ethernet.

Dependency on CN

None



5.6.3 WRFD-050425 Ethernet OAM

Availability


Summary

This feature is related to point-to-point and end-to-end Ethernet OAM. It provides an effective

solution for Ethernet link management and fault detection.

Benefits The Ethernet OAM helps the operator to manage user access in terms of detection,

monitoring, and rectification of Ethernet faults.

This feature achieves reliability and high availability of Ethernet services, enables the

service provider to provide economical and efficient advanced Ethernet services, and

ensures that the services have high quality and reliability that are required by

telecommunications services.



This feature is implemented at the RAN equipment, minimizing the impact of Ethernet

bandwidth fluctuation or faults on RAN.

Description

With the introduction of IP RAN to the WCDMA system, the Ethernet as a type of transport

bearer is widely applied. As a L2 protocol, Ethernet OAM can report the status of the network

at the data link layer, monitoring and managing the network more effectively.

The functions of Ethernet OAM consist of fault detection, notification, verification and

identification. The faults involve the hard faults that can be detected by the physical layer,

such as broken links, and the soft faults that cannot be detected by the physical layer, such as

memory bridging unit damage. Ethernet OAM plays a significant role in reducing

CAPEX/OPEX and complying with the Service Level Agreement (SLA).

RAN supports two types of Ethernet OAM: point-to-point Ethernet OAM (802.3ah) and

end-to-end Ethernet OAM (802.1ag). The two types are described as follows:

Point-to-point Ethernet OAM

The point-to-point Ethernet OAM complies with IEEE 802.3ah. What the point-to-point

Ethernet OAM takes into consideration is the last mile, rather than the specific services.

The OAM implements point-to-point maintenance of the Ethernet through mechanisms

such as OAM discovery, loopback, link monitoring, and fault detection.

End-to-end Ethernet OAM

The end-to-end Ethernet OAM complies with IEEE 802.7ag. With regard to the OAM

domain as a whole, it establishes end-to-end detection to perform maintenance of the

Ethernet based on the services.

Enhancement

RAN12.0 the end-to-end Ethernet OAM complies with IEEE 802.8ag.

In RAN 15.0, NodeBs support ITU-T Y.1731, which has incorporated the following functions

specified by IEEE 802.1ag:

Continuity checking

Loopback testing

Link tracing

End-to-end monitoring on packet loss, delay, and delay variation

Therefore, ITU-T Y.1731 can be used to replace IEEE 802.1ag. When using ITU-T Y.1731, users do not need to enable IEEE 802.1ag.



Dependency

Dependency on RNC

The RNC does not support ITU-T Y.1731..

Dependency on NodeB

RAN11.0, BTS3812E/AE and DBS3800 can only support IEEE 802.1ag draft 7; 3900

series NodeB can support IEEE 802.3ah and IEEE 802.1ag draft 7.

RAN12.0, BTS3812E/AE, DBS3800, 3900 series NodeB can support both IEEE 802.3ah

and IEEE 802.1ag draft 8.

Only the 3900 series base stations (except BTS3902E) support Y.1731 and mus be

configured with the UMPT or UTRPc board to support Y.1731..

Dependency on UE

None


None

Dependency on CN

None


WRFD-050402 IP Transmission Introduction on the Iub Interface, or

WRFD-050409 IP Transmission Introduction on the Iu Interface, or

WRFD-050410 IP Transmission Introduction on the Iur Interface



6 Network Security

6.1 Reliability

6.1.1 WRFD-040202 RNC Node Redundancy

Availability

This feature is available from RAN11.0 and is only applicable to the BSC6900.

Summary

With this feature, NodeBs can be connected to multiple RNCs and heartbeat detection is

performed on the interfaces of the active RNC. When the active RNC is faulty, the NodeBs

can be fast switched to the standby RNC for service provisioning.

Benefits

This feature improves the reliability and robustness of RAN and shortens the time of service

interruption due to single-point failure of the RNC. Therefore, the quality of service is

improved.

Description

An RNC controls the radio resources of an RNS. If the RNC incurs faults, all the NodeBs

within the RNS cannot access the network and the communication in the entire area covered

by the RNS is disabled.

Aiming to avoid the above-mentioned situations, the RNC node redundancy provides a

backup scheme of network element level. The RNC supports 1+1 backup mode. The principle

of the 1+1 backup mode are as follows:

Two sets of transport links are configured for the NodeB. One set of links are connected to the

master home RNC, and the other to the slave home RNC. (All the data related to NodeBs,

cells, and neighboring cells have backup on both RNCs.) In normal cases, the master home

RNC serves as the CRNC that controls the NodeB. If the master RNC fails, the NodeB tries to

use the slave RNC as its CRNC and resumes work.



The NodeB has two Iub interfaces (two sets of control plane, user plane and maintenance

plane links) and has two RNCs that can serve as the CRNC. Therefore, the cold backup (call

not protected) is implemented and the reliability is improved. The master and slave RNCs

have no active/standby relationship with each other. Both are in working state under normal

conditions, which maximizes the utilization of the equipment. If one of the RNCs incurs faults,

the other RNC can take over all the NodeBs controlled by the faulty RNC. This prevents the

NodeBs from being out of service and prevents the single-point failure of RNC equipment

level.

Enhancement

None

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


None

6.1.2 WRFD-040203 RRU Redundancy

Availability




Summary

RRU redundancy improves the reliability and robustness of the RAN, shorten the service

disruption time caused by RRU failure, and guarantee QoS.

Benefits

This feature improves the reliability and robustness of the RAN, shorten the service disruption

time caused by RRU failure, and guarantee QoS.

Description

In some rural area wherein the environment is unfavorable, the maintenance of the RRU is

inconvenient. RRU redundancy provides the receiver and transmitter backup solution. In the

case of the RRU redundancy, a local cell is configured with two RRUs: one active RRU and

one standby RRU. When the active RRU fails, the standby RRU resumes work.

In the case of the transmit diversity cell or MIMO cell, the cell will drop down to

NON-diversity mode or NON-MIMO mode, which can keep the network operating normally.

In the case of the non-transmit diversity cell, when the active RRU fails, the cells on the

active RRU will be re-allocated to the standby RRU.

In the case of the transmit diversity or MIMO cell, when one transmit path of RRU fails, the

cells on the RRU will be re-established with non-transmit diversity or non-MIMO mode.

Meanwhile NodeB will keep the same transmitter power as far as possible. The cell will

attempt to switch to the cell with transmit diversity or MIMO mode until the transmit path

fault is rectified.

The cell re-establishment will cause service interruption, wherein interruption time is less than

30s.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB


Dependency on UE

None


None

Dependency on CN

None




None

6.1.3 WRFD-021302 Iu Flex

Availability



Summary

This feature allows one physical RNC to connect to multiple MSCs and/or SGSNs, and these

CS/PS domain nodes can form different pools to serve the same pool area.

Benefits

Iu Flex greatly enhances the serviceability of the whole network including:

Enhancing the flexibility of the Iu interface

Increasing the total capacity of CN nodes

Enhancing the disaster tolerance capability of CN nodes

Reducing the signaling traffic of the CN

Enhancing the system utilization

In conclusion, the Iu Flex greatly enhances the serviceability of the whole network.

Description

This feature allows one physical RNC to connect to multiple MSCs and/or SGSNs, and these

CS/PS domain nodes can form different pools to serve the same pool area. The pool area has

the following characteristics:

A pool area is a collection of one or more MSC or SGSN serving areas.

A pool area is served by one or more CN nodes in parallel that share the traffic of this

area between each other.

The pool areas may overlap. The RAN Node belongs to all the overlapping pool areas.

In one pool area, the UE roams without needing to change the serving CN node.

The pool areas of the CS domain and of the PS domain are configured independently.

Therefore, the pool area enhances the flexibility of the Iu interface, and the typical structure of

Iu Flex is shown as the figure below.



Area 1

RAN

node

Area 5

RAN

node

Area 6

RAN

node

Area 7

RAN

node

Area 8

RAN

node

Area 2

RAN

node

Area 3

RAN

node

Area 4

RAN

node

PS pool-area 2PS pool-area 1

CS pool-

area 2CS pool-

area 1

MSC 3MSC 2

MSC 1

MSC 6MSC 5

MSC 4

SGSN 6

SGSN 2

SGSN 1

SGSN 5

SGSN 4

SGSN 3

MSC 7

The Network Resource Identity (NRI) identifies uniquely an individual CN node that serves a

pool area. Each CN node that supports the Iu Flex is configured with one or more specific

NRIs.

The CN node allocates the route information to the UE. If the CN node supports the Iu Flex,

the TMSI (or P-TMSI) allocated by the node contains the NRI. Then UE encodes the route

information which consists of 10 bits according to the TMSI (or P-TMSI), and sends the

parameter to the RNC through the INITIAL DIRECT TRANSFER message. Such a message

contains an IE "Intra Domain NAS Node Selection (IDNNS)" which consists of not only the

route parameter but also an indication about from which identity (TMSI/PTMSI, IMSI, IMEI)

the route parameter is derived. Then RNC will use NAS Node Selection Function (NNSF) to

select the proper CN node (MSC or SGSN) for the UE. That is, if the NNSF finds the CN

node that the NRI derived from the initial NAS signaling message identifies, it routes the

message or frame to that CN node. Otherwise, the NNSF selects an available CN node

according to the signaling load balancing.

The UE encodes the route information according to the following rules:

The UE preferentially encodes the route information identified by the TMSI or P-TMSI.

If the TMSI or P-TMSI is unavailable and the UE contains the USIM or SIM card, the

UE encodes the route information identified by the IMSI.

If the TMSI or P-TMSI is unavailable and the UE does not contain the USIM or SIM

card, the UE encodes the route information identified by the IMEI.



Accordingly, RNC selects the route based on the route parameter in the IDNNS of the

INITIAL DIRECT TRANSFER message as follows:

When the route parameter is derived from the TMSI or P-TMSI

The RNC derives the NRI from the parameter according to the configured length of the

NRI. Then the RNC selects the CN node according to the configured corresponding

relationship between the NRI and the CN node. If no NRI is configured to the CN node,

the RNC selects a CN Node based on the load balancing.

When the route parameter is derived from the IMSI

The parameter is an integer within the range from 0 through 999. The value can be

derived by (IMSI/10) MOD 1000. When route parameter is derived from the IMSI, it

should be indicated by the "IDNNS" IE that the current call attempt is an originating or

terminating call (response to paging).

For originating call, RNC would select the CN node according to either the IMSI V

value (the corresponding relationship between the IMSI V value and the CN node should

be preconfigured) or load balancing.

For terminating call, RNC should attempt to get the previously stored IMSI and Global

CN-Id. If succeeded, the CN node identified by the found Global CN-Id will be selected.

Otherwise, CN node will be selected as originating call.

When the route parameter is derived from the IMEI

The RNC selects the CN Node based on load balancing.

CS domain IMSI Paging handling

To increase the success rate of routing the paging response message to the CN node that

issues the paging request, the Iu-Flex-capable RNC needs to process the IMSI paging

message as follows:

In R5 protocols, an optional IE "Global CN-ID" is added to the RANAP PAGING message. If

RNC provides the Iu Flex feature and the paging message contains only the IMSI rather than

the TMSI, the paging message must contain Global CN-ID.

The NNSF in the RNC temporarily stores the IMSI and Global CN-ID upon reception of the

paging message. When the NNSF receives the INITIAL DIRECT TRANSFER message (a

paging response with an IMSI), it directly forwards the paging response to the CN node

identified by the Global CN-ID.

If the CN node is set to Mode 1 which indicates the Gs interface existing, the paging message

of the CS domain might be delivered on the Iu-PS interface. In this case, the SGSN adds the

Global CN-ID of the CS domain into the paging message.

Load Balancing Criteria

When the mapping between UE and CN node is not found, RNC will select a proper one

based on load balancing. The criteria is to select the lightest load CN node according to the

OVERLOAD indication from Iu interface and when the loads are the same, they will be

selected in turn.

The NRI length and the mapping relationship between IMSI route parameters in IDNNS and

CN Node can be configured as needed.

Load balancing based on the capacity of CNs can also be used in the case that NNSF cannot

get right NRI from the initial NAS signaling message. The traffic will be distributed to CNs

according to their capacity ratio.



Enhancement

In RAN6.1, load balancing based on the capacity of CNs is supported.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

Require MSC or SGSN support such feature at the same time.


None

6.1.4 WRFD-021306 Iu Flex Load Distribution Management

Availability


Summary

This feature enables load balancing between multiple CN nodes in Iu Flex scenarios.

Benefits

Improving the performance and meeting the operator’s load distribution strategy in Iu Flex

networking scenario.

Description

This feature includes enhanced load balancing and load re-distribution. It's applicable for both

CS domain and PS domain.

Enhanced load balancing

According to 3GPP TS 23.236, when IMSI V value is carried by UE, RNC may route the IDT

message based on the pre-configured IMSI routing parameters, that is, the mapping

relationship between IMSI V value and CN-Id. Actually, it is hard work for operators to

configure these parameters.



In this feature, the configuration for IMSI routing parameters is optional. For each IMSI V

value, load balancing is performed if routing parameter for this V value does not exist.

Load balancing in proportion based on the capacity of CN nodes is also introduced in this

feature. Because the capacity of the connected MSCs (CS domain)/SGSNs (PS domain) differ

from each other, the capacity of each MSC/SGSN should be take into account to balance the

load between MSCs/SGSNs, and the capacity of each MSC/SGSN can be configured by

operator or informed by MSC/SGSN through the messages INFORMATION TRANSFER

IND and INFORMATION TRANSFER CONFIRM with Huawei private extension IE. RNC

will distribute the UE according to the CN capacity ratio, this will avoid the impact for the

low capacity CN when too many UE in the system cannot get the CN relationship mapping.

Load Re-distribution

This feature is introduced from 3GPP R6, and is used to off-load traffic for MSC/SGSN. It's

helpful for some specific cases, such as the safely preparing for MSC/SGSN migration,

quickly restoring the load of MSC/SGSN that is recovered from failure, and so on. For load

re-distribution, two important identities are introduced, namely, "null-NRI" and

"Non-broadcast LAI/RAI".

This procedure is initiated from the MSC/SGSN, and the cooperation from the RNC is

required. During the load re-distribution phase, "Non-broadcast LAI/RAI" will be allocated to

UE by MSC/SGSN, which will trigger the Location/routing area updating procedure.

"Null-NRI" will be carried in the subsequent IDT message. The RNC will then route such

IDT message to MSCs/SGSNs which are not in "off-load" state. The "off-load" state should

be preconfigured on RNC for MSCs/SGSNs to off-load.

In RAN10.0, new counters related to load balancing are added including:

1. VS.LdBalRt.IMSI: The user number that was routed to CN node according to IMSI during

the load balance procedure.

2. VS.LdBalRt.InValidNRI: The user number that was routed to CN node, where the user’s

NRI is invalid, during the load balance procedure.

3. VS.LdBalRt.IMEI: The user number that was routed to CN node according to IMEI during

the load balance procedure.

Enhancement

In RAN10.0, following features are enhanced:

The capacity of each MSC/SGSN can be informed by MSC/SGSN through

INFORMATION TRANSFER IND and INFORMATION TRANSFER CONFIRM

messages with Huawei private extension IE.

New counters related to load balancing are added.

CN node status is reported to M2000 when the CN node status is changed.

Dependency

Dependency on RNC

None

Dependency on NodeB

None



Dependency on UE

None


None

Dependency on CN

None


WRFD-021302 Iu Flex

6.1.5 WRFD-140209 NodeB Integrated IPSec

Availability


Summary

This feature enables encrypted transmissions between the NodeB and the Security Gateway

(SeGW) to ensure data confidentiality, integrity, and anti-replay protection. With this feature,

operators can deploy a secure end-to-end network.

Benefits

This feature ensures network reliability and security by establishing a virtual dedicated

transport network on a public IP network. This feature costs less than external IP Security

(IPSec) solutions.

Description

The evolution towards IP-based networks improves network performance and reduces

network deployment costs. However, the inherent vulnerability of the IP network leaves it

open to security threats.

Before IPSec is introduced, a base station transmits control plane data, user plane data, and

management plane data in plaintext. Packets transmitted on an insecure network are

vulnerable to unauthorized access or malicious modification. To ensure transmission network

security, Huawei base stations incorporate the IPSec function, by which IPSec tunnels are

established for secure data transmission.

As defined by the Internet Engineering Task Force (IETF), IPSec is a set of protocols

supported at the IP layer. These protocols are Authentication Header (AH), Encapsulation

Security Protocol (ESP), and Internet Key Exchange (IKE). IPSec provides transparent

end-to-end security services for IP networks, which protects IP packets from cyber attacks.

With IPSec, two communication parties (also known as IPSec peers) gain four advantages by

encrypting and verifying IP packets:

Confidentiality. An IPSec entity encrypts user data and transmits the data in ciphertext to

protect the data from being disclosed on the transmission path. The IPSec entity refers to

the network element (NE) or network device that uses IPSec for communication.



Integrity. The IPSec entity verifies the received data to ensure that it has not been tampered

with.

Authenticity. The IPSec entity authenticates the data origin to confirm the sender of the

data.

Anti-replay. The IPSec entity identifies packets and prevents malicious users from

repeatedly sending captured packets.

In secure networking scenarios, IPSec tunnels between the base station and the SeGW can

provide protection for data transmission between the base station and the radio network

controller. Following figure shows secure networking for Wideband Code Division Multiple

Access (WCDMA).

Figure6.1.5-1 Secure networking for WCDMA

This feature cannot be used with the Automatic Address Configuration Protocol (AACP)

function in the WRFD-031101 NodeB Self-Discovery Based on IP Route feature.

Enhancement

None

Dependency


None


Only the 3900 series base stations equipped with the UTRPc or UMPT board support this

feature on Ethernet ports.

Dependency on UEs

None


In a UMTS network, the S-GW must support the IPSec function on the RNC side.


None





WRFD-140210 NodeB PKI Support

This feature depends on the NodeB PKI Support feature when a digital certification is used

for IPSec authentication.



6.1.6 WRFD-140210 NodeB PKI Support

Availability


Summary

This feature enables the NodeB on a live network to use the Certificate Management Protocol

version 2 (CMPv2) to automatically obtain a device digital certificate signed by the operator's

certificate authority (CA). With the device digital certificate, the NodeB and other network

elements authenticate each other according to IPSec and Secure Sockets Layer (SSL).

Benefits

This feature enables network elements to authenticate each other and ensures network

security.

Description

PKI is the foundation and core of contemporary network security construction and provides

information security based on the asymmetric cryptographic algorithm. A digital certificate

identifies a piece of equipment and authenticates the equipment identity during network

communication. The digital certificate includes the following information:

Equipment information

Validity period of the certificate

Public key

Digital signature of the organization that issues the certificate A trusted certificate authority

(CA) digitally signs the equipment information and public key to create a digital certificate.

During digital certificate authentication, asymmetric keys are used to authenticate equipment

identity. The sender uses a private key to sign data, and the receiver uses the public key in the

certificate to check signature validity.

Huawei base stations support PKI-based certificate management solutions, which include the

certificate-preconfiguration phase, deployment phase, and operation phase. This phased

approach facilitates use of the certificates. Certificates in Huawei base stations are managed

by using Certificate Management Protocol (CMPv2).



For Huawei products, digital certificates are applicable in either of the following scenarios:

Authentication during the setup of an IPSec tunnel between a base station and a SeGW in

a radio bearer network

Authentication during the setup of an SSL-encrypted operation and maintenance (O&M)

channel between a base station and the M2000

To use this feature, the peer device, such as a SeGW, must also support the PKI function.

Enhancement

None

Dependency


None


The 3900 series base stations must be configured with the UTRPc or UMPT board to support

this feature.


None


The operator's CA must be deployed in the network.


None


None



6.1.7 WRFD-141201 RNC User Plane and Control Plane Dynamic Sharing

Availability


Summary

A new service processing board Evolved General Processing Unit REV:a (EGPUa) is

introduced in the BSC6910 to simultaneously process user-plane data and control-plane data.



The RNC can automatically adjust the ratio of resources split between processing user-plane

data and control-plane data.

Benefits

This feature increases the hardware usage and reduces the maintenance cost.

Description

The RNC automatically monitors the user-plane load and control-plane load. When the

difference between user-plane load and control-plane load reaches a specified threshold, the

RNC automatically adjusts the ratio of resources split between processing user-plane data and

control-plane data.

The services on the CPU resources adjusted will drop from the network.

The operator can specify the time for automatic adjustment. It is recommended to perform the

automatic adjustment during off-peak hours to minimize the impact on services.

Enhancement

None

Dependency




None

Dependency on UE

None


The M2000 and CME versions must be compatible with the BSC6910.


None




None

6.1.8 WRFD-150211 RNC in Pool Load Sharing

Availability


Summary

This feature enables load sharing among RNCs in an RNC pool.

Benefits

RNC hardware capacity may not meet signaling capacity requirements because of the sharp

increase in smartphones.

Without this feature, operators must split the RNC when the signaling capacity requirement is

over RNC hardware capacity, which may require complex network reconstruction and affect

ongoing services.

With this feature, RNCs in an RNC pool can share the control-plane load. The split of RNC

may be avoided and the impact on the network KPIs may be minimized when the bursting

signaling capacity requirement is over RNC hardware capacity.

Description

This feature enables RNCs in an RNC pool to share the control-plane load. When the average

CPU load on the control plane of an RNC exceeds a specified threshold, this feature allocates

new services from this RNC to other RNCs in the pool. The RNCs communicate with each

other over the Iur-p interface, which is private. The IP transmission is used for Iur-p interface.

This feature does not affect other NEs or interfaces.



Enhancement

None

Dependency


The BSC6900 must be configured with IP interface board GOUc or FG2c to support Iur-p

interface.

The BSC6910 must be configured with IP interface board GOUc, FG2c or EXOUa to support

Iur-p interface.


None

Dependency on UEs

None


Parameters must be configured consistently on the CME for the RNCs. When configuring one

RNC on the LMT, you must synchronize the configuration to other RNCs using the CME.


None


None

6.1.9 WRFD-150212 RNC in Pool Node Redundancy

Availability


Summary

This feature enables RNC redundancy in an RNC pool. When an RNC in the pool fails, the

backup RNC takes over the services.

Benefits

Without this feature, if an RNC fails, all NodeBs under that RNC stop providing services.

RNCs may fail because of natural disasters, power outages, and software and hardware faults.

This feature solves this problem and improves service reliability.

Description

This feature enables RNCs in an RNC pool to work as backups for each other. The RNCs

communicate with each other over the Iur-p interface, which is private.



The backup mechanism is as follows:

In RNC pool networking, a NodeB that requires a backup RNC is configured with

transmission links to the master and backup RNCs. In normal situations, the master RNC

provides services for the NodeB, and the backup RNC periodically checks the running status

of the master RNC. Once the master RNC fails, the backup RNC takes over the NodeB

services.

A BSC6910 in the pool can work as the master RNC for some NodeBs and as the backup

RNC for other NodeBs simultaneously.

The IP transmission is used for Iur-p interface.

NOTE If the master RNC fails and the idle hardware capacity of the backup RNC is less than the hardware

capacity of the master RNC, the quality of services that are taken over by the backup RNC may

deteriorate.

Enhancement

None

Dependency


The BSC6900 must be configured with IP interface board GOUc or FG2c to support Iur-p

interface.

The BSC6910 must be configured with IP interface board GOUc, FG2c or EXOUa to support

Iur-p interface.


Only the 3900 series base stations and 3803E support this feature.



Dependency on UEs

None


Parameters must be configured consistently on the CME for the RNCs.


A route from the backup RNC to the master RNC must be configured on the CN.


None



7 Network Performance

7.1 Coverage Enhancement

7.1.1 WRFD-010203 Transmit Diversity

Availability


Summary

TX diversity enables the NodeB to provide twice the number of RF DL channels compared

with no TX diversity. This feature can support STTD, TSTD, and CLD1 to effectively

improve the reception performance of the UE. In TX diversity mode, the UE must support

diversity reception.

Benefits

TX diversity can improve terminal performance in special circumstances, especially when

there is less valid multi-path effect and the UE speed is low. In this case, capacity and

coverage can be obviously improved and investment can be reduced while the same QoS is

guaranteed and the CAPEX and OPEX can be cut down by operators.

Description

There are several transmit diversity modes adopted in WCDMA 3GPP, namely the Time

Switched Transmit Diversity (TSTD) mode, Space Time Transmit Diversity (STTD) mode,

and Closed Loop Transmit Diversity Mode1 (CLD1). The TSTD and the STTD are open loop

transmit diversity, which do not need feedback information compared with the closed loop

diversity. The following table summarizes the possible application of open and closed loop

transmit diversity modes on different types of downlink physical channels.



Physical channel type Open loop mode Closed loop mode

TSTD STTD Mode 1

P-CCPCH – X –

SCH X – –

S-CCPCH – X –

DPCH – X X

PICH – X –

MICH – X –

HS-PDSCH – X X

HS-SCCH – X –

E-AGCH – X –

E-RGCH – X –

E-HICH – X –

AICH – X –

If a cell works in TX diversity mode, the CPICH, PCCPCH, and SCH of the cell must also

work in TX diversity mode.

There are two types of physical channels that can use the Closed Loop Transmit Diversity

Mode1 (CLD1), that is, DPCH and HS-PDSCH. Huawei RAN6.0 supports this feature.

Enhancement

In RAN5.0, after the HSDPA feature is deployed, STTD for HS-PDSCH and HS-SCCH is

supported.

In RAN6.0, after the HSUPA feature is deployed, STTD for E-AGCH, E-RGCH and E-HICH

is supported.

Closed Loop Transmit Diversity Mode1 is a new feature of RAN6.0.

Dependency

Dependency on RNC

None

Dependency on NodeB

TX diversity requires the NodeB to provide two times RF channel resources compared with

no TX diversity mode. In TX diversity mode, the UE must support diversity reception, STTD,

TSTD, and CLD1.



Dependency on UE

The UE must support diversity reception, STTD, TSTD, and CLD1.


None

Dependency on CN

None


None

7.1.2 WRFD-010209 4-Antenna Receive Diversity

Availability


Summary

The 4-antenna RX diversity technology enables the NodeB to provide twice the number of RF

UL channels compared with the 2-antenna RX diversity technology. In this way, the system

can obtain a higher UL coverage gain.

Benefits

It can improve receiver sensitivity and uplink coverage, so that the CAPEX is reduced.

Description

Receive diversity refers to a technique of monitoring multiple frequencies from the same

signal source, or multiple radios and antennas monitoring the same frequency, in order to

combat signal fade and interference.

Receive diversity is one way to enhance the reception performance of uplink channels. It does

not involve RNC or UE.

Huawei NodeBs support both RX diversity and none RX diversity. In RX diversity mode, the

NodeB can be configured with 4 antennas (4-way), and 4 antennas for economical purpose

(4-way economical) through the Antenna Magnitude parameter. The only difference between

4-way and 4-way economical modes is that in the latter mode signals on the random access

channel are received from two antennas, but the signals on the dedicate channel are received

from four antennas.

In RX diversity mode, the NodeB does not require additional devices and works with the

same algorithms. The 4-way RX diversity requires twice the number of RX channels

compared with 2-way RX diversity. The number of RX channels depends on the settings of

the antenna connectors on the cabinet top.

Enhancement

None

http://www.answers.com/topic/frequency

http://www.answers.com/topic/fading

http://www.answers.com/topic/interference



Dependency

Dependency on RNC

None

Dependency on NodeB

The RX diversity requires the NodeB to provide enough RF channels and demodulation

resources that can match the number of diversity antennas.


Dependency on UE

None


None

Dependency on CN

None


None

7.1.3 WRFD-021308 Extended Cell Coverage up to 200km

Availability


Summary

With this feature, the operator can use less NodeBs to extend the cell coverage.

Benefits

Improve the cell coverage to enable the ultra coverage with the minimal site number.

Description

This feature is helpful for scenarios of low capacity and ultra coverage (such as seas, deserts,

and rural areas). The cell coverage will extend to 30–200 km.

Before RAN10.0, the increase in cell range up to 180 km does not require additional hardware

from a functional perspective, as long as the HBBI (macro NodeB BTS3812E and

BTS3812AE) or HBBU (Distributed NodeB DBS3800) board is used. For cell ranges above

30 km hardware dimensioning is required for RACH, that is, one HBBI or one HBBU board

per cell-carrier is needed.

In RAN10.0, if the NodeB supports remote cells whose radius is greater than 30 km, a remote

cell group can be set so that the baseband board supports the same number of remote cells as that of common cells and no additional baseband resources are required by the remote cells.



Enhancement

In RAN10.0, Extended Cell Coverage is up to 200 km.

Dependency

Dependency on RNC

None

Dependency on NodeB

All types of baseband boards support this feature. However, only the WBBPb, WBBPd,

WBBPf (3900 series NodeB), EBBI, EBOI, EULP, EULPd (BTS3812E/AE), and EBBC

or EBBCd (DBS3800) support remote cell groups.


Dependency on UE

None


None

Dependency on CN

None


None

7.1.4 WRFD-021309 Improved Downlink Coverage

Availability


Summary

This feature supports the deltaqrxlevmin parameter introduced in 3GPP R5. It can extend the

DL coverage of a cell.

Benefits Improves the downlink coverage and UE access capability

Improves the cell capacity by adjustment of PCPICH power in indoor scenario

Improves the access capability in long distance coverage scenario

Reduces the sites number required.



Description

With supporting the parameter deltaqrxlevmin introduced in 3GPP Release5, UE is allowed

to camp on the cell and access the network with CPICH RSCP that is -119 dBm, therefore,

improve the downlink coverage compared to the original -115dBm.

Such parameter deltaqrxlevmin can be configured by operator.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-021308 Extended Cell Coverage up to 200km

7.1.5 WRFD-020138 HSUPA Coverage Enhancement at UE Power Limitation

Availability


Summary

This technique is introduced in 3GPP Release 8 to improve the coverage performance for

HSUPA services on the HSUPA cell edge.

Benefits

This feature improves coverage at the HSUPA cell edge for BE services and voice services.

The emulation results show that the coverage can be increased by about 10%.



Description This feature improves the HSUPA coverage performance through HSUPA power control

enhancement at UE power limitation introduced in 3GPP Release 8.

When a UE detects that its transmit power is limited, the UE enters power scaling mode.

In this mode, the transmit power on uplink physical channels is reduced proportionately to

improve coverage quality.

In the traditional power-scaling technique, the power offset of E-DPDCH relative to

DPCCH is not the most appropriate value, and therefore scaling mode offers only limited

gains. In the enhanced power scaling technique, the network side provides optimized transport

block size and the power offset of E-DPDCH relative to DPCCH. The UE uses these

optimized settings when its power is limited at the cell edge. In contrast to the traditional

power-scaling technique, the enhanced technique allows for more appropriate transport block

size and E-DPDCH power-offset settings, improving coverage performance at the HSUPA

cell edge.

Enhancement

None

Dependency


None


None




The UE needs to support 3GPP Release 8 or later. It also needs to support improved EUL

power control at UE power limitation.



7.2 Spectrum Efficiency Improvement

7.2.1 WRFD-021001 Flexible frequency bandwidth of UMTS carrier

Availability




Summary

Huawei provide flexible frequency bandwidth range from 4.2MHz to 5MHz with algorithm

enhancement. Therefore, Huawei can support the frequency separation range from 2.2MHz to

2.6MHz in UMTS and GSM co-site scenario. And Huawei also can support the frequency

separation range from 4.2MHz to 5MHz in UMTS and UMTS co-site scenario.

Benefits

It will increase the frequency utilization and provide UMTS mode even the frequency

resource is not enough for 5MHz. This feature can solve the problem that frequency is rare

resources for operators.

Description

Usually, the frequency bandwidth of UMTS must be 5MHz. With the development of 3G

service, the frequency resource is become more and more rare. The conflict is evident on the

high quality frequency band. Many operators cannot refarm 5MHz for the limited frequency

resource, but they want to deploy the new services on 850/900MHz for the competition

pressure. Through algorithm enhancement, Huawei can support frequency bandwidth less

than 5MHz. The feature only can be used in GU or UU co-site scenario.

However, KPI is impacted even with carefully network planning and optimization when

frequency bandwidth is less than 5MHz. The impact on the KPI can be reduced with Huawei

professional service, but it cannot get rid of the impact thoroughly. Therefore, operator must

balance between the KPI and bandwidth utilization.

Due to the sensitivity of KPIs, it is recommended that operators purchase Huawei's network

optimization services when using this feature. This ensures accurate setting and fine tuning of

different parameters to obtain optimum KPIs.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

For 4.6 MHz to 5 MHz (including 4.6 MHz), all the RF modules can support this feature.

For 4.2 MHz to 4.6 MHz (excluding 4.6 MHz), only 850/1900 MHz RRU3804, 850

MHz WRFU, MRFU v1/v2 and RRU3908 v1/v2, WRFUd, RRU3828, RRU3829,

RRU3928, RRU3929, MRFUd, and MRFUe can support this feature.

Dependency on UE

None


None



Dependency on CN

None


None


Recommend to deploy this feature with UMTS Non-standard Bandwidth Features

Introduction Service

7.3 High Speed Mobility

7.3.1 WRFD-010206 High Speed Access

Availability


Summary

With the advent of higher-speed vehicles, how to provide mobile communication services on

a high-speed moving vehicle becomes a challenge for the operator. This feature is one of the

major high-speed coverage solutions.

Benefits

High speed access is one of the key features in the differential solution for high speed

coverage. The NodeBs using high speed access supports coverage under which the moving

speed of UEs can exceed 400 km/h.

Description

Currently, the high-speed trains in some countries and regions can reach speeds of 200 km/h

to 300 km/h. The maglev train in Shanghai can reach a maximum speed of 430 km/h.

High-speed access is one of the key features in the high-speed coverage differentiation

solution. With this feature, the NodeB can provide the coverage for the UE moving at a speed

of up to 450 km/h.

When the UE moves at a high speed, Doppler shift occurs. As Doppler shift affects the signal

reception on the baseband unit of the NodeB, automatic frequency control (AFC) should be

implemented on the RAKE receiver. The NodeB supports AFC for UL DPCH and PRACH.

The parameter "High Speed Movement Mode" can be used to activate AFC on the PRACH.

The frequency offset can be mapped to the maximum moving speed through the parameter

"Speed Rate (km/h)" on the LMT.

When this feature is enabled, the Extended Cell status will not be supported any more. The

capability of the HULP, HBBI, and HBBU carrying access channels falls (each board can

carry access channels for only one cell). In addition, this feature is not supported when

4-antenna RX diversity is configured.



The WBBP, EBBI, EBOI and EBBC are added to support this feature without compromising

the performance.

Enhancement

In RAN10.0, the WBBP, EBBI, EBOI and EBBC are added to support this feature without

compromising the performance.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


None


Recommend to deploy this feature with High-Speed Train Feature Introduction Service

7.3.2 WRFD-021350 Independent Demodulation of Signals from Multiple RRUs in One Cell

Availability


Summary

The feature of independent demodulation of signals from multiple RRUs in one cell enables

the signals from multiple RRUs to be demodulated independently and combined within a

BBU. It effectively reduces the number of handovers between cells for users.

Benefits

This feature introduces independent demodulation of signals from multiple RRUs in one cell.

Different RRU coverage areas in the same cell can reduce the number of handovers between



cells and increase cell capacity and throughput. Multiple RRU coverage areas can also be

used to flexibly form wire-shaped coverage areas. Using a relatively small number of cells,

the coverage needs of transportation routes can be met.

Description

This feature provides independent demodulation of signals from multiple RRUs in one cell. In

uplink, the NodeB performs independent demodulation and combination of the multiple RRU

receiver signals within a BBU. In downlink, the NodeB copies the signal of a cell and outputs

it to multiple RRUs. A cell can be divided into multiple coverage area, each coverage area has

independent RRU, and multiple RRUs belong to the same cell and have the same scrambling

code.

Baseband combination technology is used. Therefore, multiple RRU combined signals will

not introduce signal background noise or influence uplink receiver sensitivity.

In RRU cascade scenario, one 1.25G CPRI can support independent demodulation of

maximum 4 RRU in a cell; a 2.5G CPRI can support independent demodulation of maximum

6 RRU in a cell. Similarly, if there are 2 frequencies in one RRU, then one 1.25G CPRI can

support independent demodulation of maximum 2 RRU in a cell and a 2.5G CPRI can support

independent demodulation of maximum 4 RRU in a cell.

This feature is suitable for coverage in special locations with high speed motion such as

highways, railroad tracks, or formula 1 tracks.

When using this feature, 4-Antenna Receive Diversity, TX diversity, MIMO, FDE,UL

CELL_FACH enhancement, extended cell, load measurement (based on the report of actual

service load), Load-based Uplink Target BLER Configuration, or Dynamic Configuration of

HSDPA CQI Feedback Period cannot be supported.

Enhancement

In RAN14.0, an RRU can be configured with one or two receive (RX) antennas when

multiple RRUs are configured for one cell. That is, RRUs configured with a single RX

antenna can work with RRUs configured with two RX antennas in one cell. This enhanced

feature also applies to indoor and tunnel coverage scenarios where RRUs are configured with

single RX antennas. In comparison with the existing scheme of multiple RRUs in one cell

with digital combination and division, this enhanced feature in RAN14.0 prevents RoT and

mutual interference caused by a mixture of RX signals received by multiple antennas. This

enhanced feature improves the cell uplink coverage and throughput.



Dependency

Dependency on RNC

None

Dependency on NodeB

Only the DBS3900 configured with the WBBPb, WBBPd or WBBPf board supports this

feature.

The BTS3902E does not support this feature.


None


None


Recommend to deploy this feature with UMTS Uplink Capacity Improvement Service and

High-Speed Train Feature Introduction Service

7.4 Intra-system Mobility Management

7.4.1 WRFD-020302 Inter Frequency Hard Handover Based on Coverage

Availability



Summary

This feature introduces inter-frequency hard handover triggered by Active Set quality

measurement event 2D or by Uplink Radio Link QoS or emergency blind handover triggered

by event 1F.

Benefits

Coverage based Inter frequency hard handover provides supplementary coverage in

inter-frequency networking cells to prevent call drop, therefore, improve the network

performance and end user feeling.

Enhancement of inter frequency hard handover between multi frequency band cells can be

used to support multi frequency band networking scenario.



Description

Inter frequency hard handover is hard handover between cells of different frequencies. It can

be triggered by coverage, load or speed which is suitable for the corresponding scenarios. The

trigger condition based on the cell load belongs to the optional feature which is described in

WRFD-020103 Inter Frequency Load Balance. The trigger condition based on the UE speed

which is evaluated by RNC belongs to the optional feature which is described in

WRFD-021200 HCS (Hierarchical Cell Structure). In this feature, the handover is triggered

by coverage reason.

This trigger condition is based on the quality measurement. The compressed mode

measurement for DL or UL will be triggered by event measurement report 2D for

inter-frequency or inter-RAT handover and stopped by event measurement report 2F. When

compressed mode measurement is triggered, RNC will start the inter frequency measurement

in UE to get the target cell to handover if inter-frequency neighboring cells are configured.

The measurement quantity is combination of RSCP and Ec/N0. The compressed mode can

also be triggered by the combination of Ec/N0 and RSCP. Moreover, event 2B and period

measurement report mode are supported and which measurement quantity and mode to use

can be configured by operator. The measurement related parameters include threshold,

hysteresis, and trigger delay time. The inter-frequency neighboring cell number can be up to

64.

The compressed mode is divided into two types, namely, spreading factor reduction (SF/2)

and high layer approaches. The type of compressed mode to be used is decided by the RNC

automatically, according to the configurable spreading factor used in uplink and downlink.

Another measurement report 1F can also trigger inter-frequency hard handover, but

compressed mode will not be triggered in this scenario since such a report means a call drop

may occur at any time and there is no time to implement the measurement procedure. The

target cell of handover is selected based on the equivalent down link overage of the inter

frequency blind neighboring cells. By this means the handover success rate can be guaranteed,

and the equivalent down link coverage is represented by RSCP of CPICH channel which is

determined after network planning.

Inter-frequency handover triggered by limitation of UE TX power or high UL BLER is

available for PS BE, CS AMR and VP services.

In multi frequency band networking scenario which is described in WRFD-020110 Multi

Frequency Band Networking Management, the inter frequency hard handover is enhanced to

meet the networking requirements. That is, coverage based hard handover between different

frequency bands is supported and UE measurement capability will be considered to guarantee

that the UE is not handed over to the cell where the UE does not have the corresponding

capability on that frequency band. When the capability of the UE is insufficient can be

acquired, whether to implement the handover can be configured by operator.

Enhancement

In RAN3.0, event report mode and periodical report mode are supported.

In RAN5.1, compressed mode is triggered by combination of Ec/N0 and RSCP is supported.

In RAN5.1, puncturing mode as one compressed mode type is not supported anymore since

such a mode has been removed from 3GPP.

In RAN6.0, coverage based inter-frequency hard handover between multi frequency band cell

is supported.



In RAN6.0, combination of RSCP and Ec/N0 measurement is supported when triggering

compressed mode measurement, and available only for periodic measurement report mode.

In RAN10.0, combination of RSCP and Ec/N0 measurement is available when event 2B

measurement report mode is selected.

In RAN10.0, the inter-frequency handover triggered by limitation of UE TX power or high

UL BLER is applicable to the PS BE, CS AMR, and VP services.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should support the relevant measurements and the procedure of handover.


None

Dependency on CN

None


None

7.4.2 WRFD-020304 Inter Frequency Hard Handover Based on DL QoS

Availability



Summary

When the load of services is higher in the cell and downlink QoS drops, this feature enables

the UE to be handed over to an inter-frequency cell, guaranteeing QoS requirements.

Benefits

DL QoS based inter frequency hard handover provides the method to prevent call drop and

guarantee the QoS in inter-frequency networking, therefore, improves the network

performance and enhances end user experience.



Description

In the scenarios of severe fading and high load, the call drop could take place due to the

limitation of DL transmitted code power. In addition, coverage area is different for different

services in network planning, thereby the system should take actions in order to guarantee the

downlink QoS and keep the connection as could as possible. The evaluation of downlink QoS

status is on the basis of TCP (Transmitted Code Power) or RLC retransmission (only for PS

BE).

Once the downlink QoS is detected to be in bad condition, inter-frequency handover could be

triggered:

For AMR and VP services, inter-frequency handover could be triggered based on TCP.

For PS BE service, inter-frequency handover could be triggered based on TCP and RLC

retransmission.

This feature can be switched on/off separately for AMR, VP and PS BE services.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-020302 Inter Frequency Hard Handover Based on Coverage

7.4.3 WRFD-020605 SRNS Relocation Introduction Package

Availability





Summary

This feature provides multiple solutions for user mobility between RNCs. The solutions

include the static relocation solution (with Iur interface), and hard handover/cell update/URA

update relocation solutions (without Iur interface).

Benefits Reduce the bandwidth occupied by the Iur interface.

Reduce the transmission delay of user plane.

Obtain the parameters of cell-level algorithms to optimize the performance.

Ensure that communications are not interrupted when the UE moves to the coverage area

of another RNC while the Iur interface is not available.

Help to keep the integrity and continuity of the data transfer, and improve the best effort

service performance during the SRNS relocation procedure.

Description

The serving RNS (SRNS) manages the connection between the UE and the UTRAN and can

be relocated.

The SRNS Relocation Introduction Package includes following features:

SRNS Relocation (UE Not Involved)

SRNS Relocation with Hard Handover

SRNS Relocation with Cell/URA Update

Lossless SRNS Relocation

Enhancement

In RAN3.0, RAN5.0 SRNS Relocation Introduction Package is enhanced. For details, refer to

the enhancement of the features in the package.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


The CN and DRNC must support this feature simultaneously.

Dependency on CN





None

7.4.4 WRFD-02060501 SRNS Relocation (UE Not Involved)

Availability


Summary

This feature supports the SRNS procedure based on the standard Iu interface defined by 3GPP.

The static relocation procedure does not involve the UE and radio connections are affected

during the relocation. The static relocation is an optimal relocation mode.

Benefits Reduce the bandwidth occupied by the Iur interface.

Reduce the transmission delay of user plane.

Obtain the parameters of cell-level algorithms to optimize the performance.

Description

When the Iur interface exists, the UE may use the radio resources of one RNC and connects to

the CN through another RNC.

After the SRNS is relocated (UE not involved), the Iur resources for the UE are released. The

target RNC not only provides radio resources for the UE but also connects the UE to the CN.

If the radio links are provided only by the target RNC, the static relocation for UEs in

CELL_DCH state can be triggered in the following four conditions:

SRNS relocation based on delay optimization

The SRNC calculates the transmission delay on the user plane. If the delay exceeds the

threshold, the SRNC initiates the SRNS relocation.

SRNS relocation based on transmission optimization

The SRNC calculates the bandwidth occupancy on the Iur interface. If the transmission

resource of Iur interface is congested, the SRNC initiates SRNS relocation to reduce the

transmission bandwidth occupation.

SRNS relocation based on separation time

The SRNC initiates SRNS relocation when the SRNC and the CRNC have been

separated for a period of time which exceeds the threshold.

SRNS relocation based on location separation

The SRNC initiates SRNS relocation when the UE moves to an area which is controlled

by the DRNC.

The UE’s only behavior during the procedure is that it is notified with new UTRAN

MOBILITY INFORMATION.



Enhancement

In RAN3.0, the SRNS relocation based on delay optimization is supported.

In RAN5.0, the SRNS relocation based on separation time and location separation are

supported.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None



Dependency on CN



None

7.4.5 WRFD-02060502 SRNS Relocation with Hard Handover

Availability


Summary

When the Iur interface is unavailable, this feature enables the UE to move between RNCs.

Benefits

It can ensure communications are not interrupted when the UE moves to the coverage area of

another RNC while the Iur interface is not available.

Description

SRNS relocation with hard handover, which applies to UEs in CELL_DCH state, occurs in

the following conditions:

Inter-frequency or intra-frequency hard handover is performed.

The target cell and the source cell belong to different RNCs.



There is no Iur interface between the two RNCs or there are not enough resources to set

up a connection through the Iur interface.

In such scenarios, the UE is ordered to be relocated to a new RNC with hard handover to

prevent call drop.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None



Dependency on CN



None

7.4.6 WRFD-02060503 SRNS Relocation with Cell/URA Update

Availability


Summary

When the Iur interface does not support CCH or Iur-CCH is unavailable, this feature enables

the UE in CELL_FACH, CELL_PCH, or URA_PCH state to move between RNCs.

Benefits

It ensures that communications are not interrupted when the UE in CCH state moves to the

coverage area of another RNC.



Description

If Iur interface support CCH, the cell/URA update does not trigger relocation immediately.

When Iur interface does not support CCH or Iur-CCH is unavailable, the SRNS relocation

with cell update occurs when all the following conditions are met:

The cell update procedure is performed.

The target cell and the source cell belong to different RNCs.

There is Iur interface between two RNCs, but Iur does not support CCH or Iur-CCH is

unavailable.

It is caused by cell reselection of UE in CELL_FACH, CELL_PCH or URA_PCH state. The

message Cell Update or URA Update sent by the UE is forwarded from the new RNC to the

old RNC through the Iur interface, and then the relocation procedure starts.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None



Dependency on CN

None


None

7.4.7 WRFD-02060504 Lossless SRNS Relocation

Availability


Summary

This feature enables the forwarding of SRNS contexts and DL N-PDU duplicates to the target

relocation cell during the relocation. With this feature, the higher layer on the user plane does not need to resend the data lost during the relocation, improving the BE service performance.



Benefits

This feature helps to keep the data transfer integrity and continuity, and improve the best

effort service performance in the SRNS relocation procedure.

Description

Lossless SRNS relocation is used to forward the context in SRNS and DL N-PDU duplicates

towards the relocation target RNC during the relocation procedure. That is, the RNC supports

the maintenance of PDCP sequence numbers for radio bearers which are used to forward data

not acknowledged by the UE. With this feature, the higher layer in user plane does not need to

resend the data lost during relocation procedure; therefore, the best effort service performance

is improved.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


The UE, CN and DRNC must support this feature simultaneously.

Dependency on CN

None


None

7.5 Intra-system Radio Resource Management

7.5.1 WRFD-010615 Multiple RAB Package (PS RAB ≥ 2)

Availability





Summary

This feature is a combination of two or more PS RABs.

Benefits

Multi-RAB support capability provides operators with more choices for the service solution.

Description

Multi-RAB can provide many services simultaneously to the upper layer. When multi-RAB

has more than one PS RAB, Huawei supports the following specifications:

Combination of two PS services

One CS service + two PS services

Combination of three PS services

One CS service + three PS services

Combination of Four PS Services

In all the above combinations, the bit rates of CS and PS services are not limited. That is, any

bit rate defined in WRFD-010501 Conversational QoS Class, WRFD-010502 Streaming QoS

Class, WRFD-010503 Interactive QoS Class, and WRFD-010501 Background QoS Class can

be selected in the combination.

The PS conversational/streaming/interactive/background services can also be mapped onto

HS-DSCH or E-DCH channels, such a feature will be supported with the optional feature

WRFD-010610 HSDPA Introduction Package and WRFD-010612 HSUPA Introduction

Package.

Enhancement

In RAN6.0, the following specifications can be supported:

Combination of three PS services including IMS signaling

One CS service + three PS services including IMS signaling

In RAN10.0, the limitation that one of 3 PS service must be IMS signaling is removed.

In RAN11.0, the combination of four PS service is supported.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE must have the corresponding multi-RAB support capability.




None

Dependency on CN

The CN must have the corresponding multi-RAB support capability.


None

7.5.2 WRFD-01061501 Combination of Two PS Services

Availability


Summary

This feature is a combination of two PS services.

Benefits

Multi-RAB support capability provides operators with more choices for the service solution.

Description

Huawei supports the combination of two PS services.

The bit rates of PS services are not limited. That is, any bit rate defined in WRFD-010501

Conversational QoS Class, WRFD-010502 Streaming QoS Class, WRFD-010503 Interactive

QoS Class, and WRFD-010501 Background QoS Class can be applied to this feature.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



None

Dependency on CN





WRFD-010615 Multiple RAB Package (PS RAB ≥ 2)

7.5.3 WRFD-01061502 Combination of One CS Service and Two PS Services

Availability


Summary

This feature is a combination of one CS service and two PS services.

Benefits

This feature provides operators with more choices for the service solution.

Description

Huawei supports the combination of one CS service + two PS services.

The bit rates of CS and PS services are not limited. That is, any bit rate defined in

WRFD-010501 Conversational QoS Class, WRFD-010502 Streaming QoS Class,

WRFD-010503 Interactive QoS Class, and WRFD-010501 Background QoS Class can be

applied to this feature.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



None

Dependency on CN






7.5.4 WRFD-01061503 Combination of Three PS Services

Availability


Summary

This feature is a combination of three PS services.

Benefits


Description

Huawei supports the combination of three PS Services.

The bit rates of PS services are not limited. That is, any bit rate defined in WRFD-010501

Conversational QoS Class, WRFD-010502 Streaming QoS Class, WRFD-010503 Interactive

QoS Class, and WRFD-010501 Background QoS Class can be applied to this feature.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



None

Dependency on CN






7.5.5 WRFD-01061504 Combination of One CS Service and Three PS Services

Availability


Summary

This feature is a combination of one CS service and three PS services (including IMS

signaling).

Benefits


Description

Huawei supports the combination of one CS service and three PS services, including IMS

signaling.

The bit rates of CS and PS services are not limited. That is, any bit rate defined in

WRFD-010501 Conversational QoS Class, WRFD-010502 Streaming QoS Class,

WRFD-010503 Interactive QoS Class, and WRFD-010501 Background QoS Class can be

applied to this feature.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



None

Dependency on CN






7.5.6 WRFD-01061505 Combination of Four PS Services

Availability


Summary

This feature is a combination of four PS services. The service combination can be VoIP + BE

or four PS BE services.

Benefits

This feature enhances the system's compatibility with various VoIP UEs and facilitates the

development of VoIP.

The service combination 3PS RAB VoIP + BE can be applied, which enriches the operator’s

services portfolio.

Description

RAN11.0 supports up to four PS RABs per user. A typical application of Multi-RAB is VoIP

plus BE service where VoIP may need up to three RABs to transmit SIP signaling, Real-Time

Transport Protocol (RTP) (voice), and Real-Time Transport Control Protocol (RTCP) (media

monitoring) respectively, as shown in the following figure.

RAN11.0 supports four PS RABs per user, and the service combination VoIP + BE is

supported. Other service combination like 4PS BE is also supported.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE





None

Dependency on CN




7.5.7 WRFD-020103 Inter Frequency Load Balance

Availability


Summary

When a cell is in initial congestion state, this feature enables some UEs in the cell to be

handed over to an inter-frequency co-coverage cell, reducing the load of the cell.

Benefits

This feature is used to reduce the system load by handing over UE to neighboring cells,

keeping the system in a safe state.

Description

This feature is an important action for Load Reshuffling (LDR). It enables the system to

perform inter-frequency handover that hands over UE to an inter-frequency neighboring cell,

thereby reducing the current cell load.

This action is triggered when system detects that the current serving cell load is beyond the

pre-defined congestion threshold and the cell is entering a basic congestion state. Normally

the resource used for cell load level measurement is the power resource, if inter frequency

load balance is taken as an action for LDR. The load measurement is done both for UL and

DL.

A target cell will then be selected according to the load difference between current cell load

and congestion threshold of each target cell. Only when the load difference exceeds a certain

value can the cell be selected as the target cell for blind handover. The limitation for target

cell selection is used to ensure that the handover does not cause the load increase of target

cell.

Besides, the system will select a UE to be handed over during the LDR according to the UE

priority. If the UEs have the same priority, the UE with higher service bit rate will be selected

first.

Inter-frequency load balance is also applied to hierarchical cell structure.



Enhancement

In RAN5.1, the user selection criterion considers the Traffic Class, ARP, and bear type (R99

or HSPA) when calculating the UE priority, and THP factor added in RAN6.0.

HSDPA service is considered during inter-frequency load balance procedure in RAN5.0.

HSUPA service is considered during inter-frequency load balance procedure in RAN6.0.

Blind handover is used to perform inter-frequency handover before RAN12.0. Measurement

based handover is added as one choice of actions to perform inter-frequency handover in

RAN12.0. In RAN12.0, by MML command, operator can inhibit some types of service being

selected for inter-frequency load balance.

Before RAN14.0, inter-frequency load balancing can be triggered only by basic congestion of

power resources or code resources. In RAN14.0, load-based inter-frequency handovers can

also be triggered by basic congestion of uplink credit resources. This helps mitigate basic

congestion of uplink credit resources and therefore lowers the probability of admission

failures due to uplink credit resource congestion. In RAN14.0, inter-frequency blind

handovers and measurement-based inter-frequency handovers can be triggered by basic

congestion of uplink credit resources.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


When this feature is used for HSDPA/HSUPA load control, WRFD-010610 HSDPA

Introduction Package and WRFD-010612 HSUPA Introduction Package are required.



7.5.8 WRFD-020114 Domain Specific Access Control (DSAC)

Availability




Summary

In urgent cases, for example, the CN is overloaded, this feature enables fast reduction of the

load, avoiding further overload.

Benefits

In urgent cases, for example, the overload of the CN, the DSAC function can quickly lower

the current load and reduce the risk of overload.

If one CN domain is overloaded or unavailable, the other CN domain is not affected. This

improves the disaster tolerance and availability of the network.

Description

In the 3GPP protocols, the PRACH resources (such as access slots and access preambles in

FDD mode) provide access services of different priorities by distinguishing different Access

Service Classes (ASCs). The value range of the ASC is 0–7. The value 0 represents the

highest priority and the value 7 represents the lowest priority. The value 0 of ASC is used for

emergency calls. The Information Element (IE) "AC-to-ASC mapping" in SIB 5 or SIB 5bis

indicates the mapping between Access Class (AC) and ASC. This mapping is usually applied

to the access phase, for example, sending an RRC CONNECTION REQUEST message;

therefore, different access services are provided by controlling the access probability of the

UEs which belong to the ASCs of different priorities.

In SIB 3/4, the IE "Domain Specific Access Restriction Parameters" is used to indicate which

access class is barred or allowed. The UE will read its access class and compare it with the

access class stored in the SIM card. After comparison, the UE knows whether it is allowed to

access the cell.

The DSAC function can be used in the following scenarios:

1. When the RNC knows through the Iu interface that the CN is overloaded, it triggers the

DSAC function as follows:

− The RNC sets the step as X% to limit the access of the UE under the RNC at a fixed

interval, namely, "Access Class Restriction interval". Within the next interval, the

RNC limits the other X% UEs and releases all the other UEs.

− The RNC bars the access of UEs according to different domains. That is, the RNC

prevents the UEs from accessing the overloaded CS domain. If the PS domain is

overloaded, the RNC also prevents the UEs from accessing the PS domain.

− If X% = 100%, the RNC bars the access of all the UEs. The UEs camp on the

coverage area under the RNC but cannot access the corresponding domain.

− When the CN is no longer overloaded, all the barred ACs will be released.

− The operators can set X% and Access Class Restriction interval.

− The operator can decide whether to trigger the DSAC function when a domain of the

CN is overloaded.

2. When Iu Flex is used, the DSAC function can be automatically triggered only when all the

CN nodes of the corresponding domain connected to the RNC are overloaded.

3. When the DSAC function is triggered, based on logs and alarms, the operator can easily

monitor the DSAC status, network status, the process of removing restrictions on access

classes, and so on.



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

Only the UEs of R6 (or later) can support this function.


None

Dependency on CN

CN nodes should support this message on the Iu interface.


None

7.5.9 WRFD-020110 Multi Frequency Band Networking Management

Availability


Summary

With this feature, the operator can simultaneously provide services on multiple frequency

bands. This feature implements the functions such as mobility management, load balancing,

and traffic balancing between frequency bands.

Benefits

In multi-frequency-band networking scenarios, this feature can provide seamless

communication to improve the system capacity.

Description

IMT-2000/UMTS service was launched in the core band (1920-1980 MHz/2110-2170 MHz)

during the year 2001, and by mid-2006 there were more than 75 million IMT-2000/UMTS

subscriptions worldwide in more than 110 IMT-2000/UMTS networks launched

commercially.



However, there are still sparsely populated and remote areas where there are difficulties to

provide IMT-2000/UMTS services in a cost-efficient way. Therefore, other frequency band

re-farming is required to provide UMTS service to meet the requirements. For example,

UMTS deployment in 900 MHz band can facilitate the provision of the expected

IMT-2000/UMTS services to users in those areas. The 900 MHz band is identified for

IMT-2000/UMTS at ITU and from a regulatory point of view it can be used for

IMT-2000/UMTS.

The most significant benefit comes from the fact that compared to 2 GHz band, radio wave

propagation path-loss in 900 MHz frequency band is much smaller. Therefore, for the offering

of the same service (data rates) and same coverage, the required number of base station sites

in 900 MHz band is reduced by 60% compared to that at 2 GHz, as shown by the following

table.

Service 2 GHz band 900 MHz Band Site Number Reduction

Circuit switched, 64 kbit/s 224 90 60%

Packet switched, 384 kbit/s 468 181 61%

In addition, the use of the 900 MHz band can significantly improve indoor coverage in urban

areas. The economic benefit of the 900 MHz band on UMTS operators’ investments makes it

possible to propagate benefits to the end-users in terms of wider coverage and possibly lower

level of usage costs. Improved indoor coverage is important because more and more mobile

voice and data services are used in the indoor environment. This is of particular interest when

considering the increasing use of the mobile phones as a replacement or a complement to

fixed phone, PC and TV usage. The UMTS900 will be deployed by reusing the GSM sites

within the existing service area, and the benefits are achieved because of:

Reuse of the existing base station sites

Reuse of the existing antenna systems and feeders

From a practical implementation point of view, operators only need either to add a new base

station cabinet or to replace the existing GSM base station by a multimode GSM+UMTS base

station subject to site situation or manufacturer’s design. It should be noted that the base

station equipment cost represents only a small portion of the total site cost.

Huawei supports the following frequency band:

Operating Band

UL Frequencies

UE transmit, NodeB receive

DL frequencies

UE receive, NodeB transmit

Availability

I 1920 to 1980 MHz 2110 to 2170 MHz RAN2.0

II 1850 to 1910 MHz 1930 to 1990 MHz Macro: RAN5.0

RRU: RAN5.1

III 1710 to 1785 MHz 1805 to 1880 MHz Macro: RAN5.0

RRU: RAN5.1

V 824 to 849 MHz 869 to 894 MHz RAN6.0



VIII 880 to 915 MHz 925 to 960 MHz RAN6.0

IV 1710 to1755 MHz 2110 to 2155 MHz RRU: RAN6.1

IX 1749.9 to 1784.9 MHz 1844.9 to 1879.9 MHz RRU: RAN6.0

Huawei also provides the full mobility solution between these frequency bands and the

mobility between these frequency bands and GSM cells. The main related features are as

follows:

Cell selection / reselection

Service distribution and Directed retry: Load Balance DRD is supported, which enables

the RNC to direct the UE to a preferable layer according to the load conditions of current

cell and target cell. Service priority could be set to cells, corresponding to different

service types including R99 RT, R99 NRT, HSPA and other (for example, MBMS). This

enables service differentiation and/or load balance between multi-frequency layers. In

call setup procedures, the RNC would direct the UE to an inter-frequency cell with

higher service priority. The RNC also considers the capabilities of the cell/UE, and the

requested RAB. Service Differentiate DRD and Load Balance DRD could work

independently or cooperatively. In later case service priority will be first considered.

Such a feature depends on the optional feature WRFD-020400 DRD Introduction

Package.

Coverage based handover: If coverage based inter-frequency handover is needed, the

optional feature WRFD-020302 Inter Frequency Hard Handover Based on Coverage

should be enabled. If coverage based inter-RAT handover is needed, WRFD-020303

Inter-RAT Handover Based on Coverage should be enabled.

Load based handover: Such feature enables the load based inter-RAT handover, which

depends on the optional feature WRFD-020306 Inter-RAT Handover Based on Load.

Service based handover: Such feature depends on the optional feature WRFD-020305

Inter-RAT Handover Based on Service

Hierarchical Cell Structure capability is also available which is operator configurable in

order to prioritize the different UMTS2100, UMTS900 and GSM layers. And such

feature depends on the optional feature WRFD-021200 HCS (Hierarchical Cell

Structure).

The network operator can have full flexibility to prioritize different UMTS2100 and

UMTS900 cells.

Enhancement

In RAN12.0, the inter-band blind handover based on load is supported to share the load in

case of cell overload.

In RAN14.0, inter-band blind handovers can be triggered by basic congestion of uplink credit

resources. This helps mitigate basic congestion of uplink credit resources and therefore lowers

the probability of admission failures due to uplink credit resource congestion.

Dependency

Dependency on RNC

None



Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-020400 DRD Introduction Package or

WRFD-020302 Inter Frequency Hard Handover Based on Coverage or

WRFD-020303 Inter-RAT Handover Based on Coverage should be enabled or

WRFD-020306 Inter-RAT Handover Based on Load or

WRFD-020305 Inter-RAT Handover Based on Service or

WRFD-021200 HCS (Hierarchical Cell Structure)

WRFD-020103 Inter Frequency Load Balance

If one of these dependent features is not enabled, the corresponding function will not be

available in the multi frequency band networking solution. Operator can choose which feature

to use or not.



7.5.10 WRFD-020160 Enhanced Multiband Management

Availability


Summary

In a multiband network, the cells that perform an operation on different frequency bands have

different coverage areas. Generally, when the UE needs to perform an inter-frequency

handover, it performs handover decision according to the inter-frequency measurement result

rather than performs a blind handover. This increases the handover success rate.

Inter-frequency measurement is performed for handover decision of the inter-frequency

handover based on traffic steering or load sharing.



Benefits

With this feature, the traffic steering or load sharing between the cells operating on different

frequency bands can be implemented, enhancing the resource usage while ensuring the

handover success rate.

Description

In the inter-frequency traffic steering, each cell is configured with the priority for carrying

each type of services (R99 RT, R99 NRT, HSPA, and others). After the RAB is setup,

inter-frequency measurement is performed to ensure that the UE accesses the cell with the

highest priority. To enable inter-frequency measurement for traffic steering, enable the

features WRFD-020110 Multi Frequency Band Networking Management and WRFD-020400

DRD Introduction Package.

In the inter-frequency load sharing, after the RAB setup, load reshuffling (LDR) may trigger a

load-based inter-frequency handover. The target cell is selected on the basis of the quality

measurement of cells. Only the cell that meets the quality requirement is selected. To enable

inter-frequency measurement for load sharing, enable the features WRFD-020110 Multi

Frequency Band Networking Management and WRFD-020103 Inter-Frequency Load

Balance.

Enhancement

Before RAN14.0, measurement-based inter-band handovers for inter-band load balancing are

triggered only by basic congestion of power resources. In RAN14.0, inter-band handovers can

also be triggered by basic congestion of uplink credit resources. This helps mitigate basic

congestion of uplink credit resources and therefore lowers the probability of admission

failures due to uplink credit resource congestion.

Dependency

Dependency on RNC


Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


WRFD-020110 Multi Frequency Band Networking Management and WRFD-020400

DRD Introduction Package or



WRFD-020110 Multi Frequency Band Networking Management and WRFD-020103

Inter-Frequency Load Balance



7.5.11 WRFD-020400 DRD Introduction Package

Availability



Summary

This feature supports inter-frequency or inter-system direct retry and redirect.

Benefits

These features can decrease the access failure rate and improve the QoS of the network.

Description

The DRD Introduction Package includes the following features:

Intra System Direct Retry

Inter System Direct Retry

Inter System Redirect

Traffic Steering and Load Sharing During RAB Setup

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None



Dependency on CN

None


None

7.5.12 WRFD-02040001 Intra System Direct Retry

Availability


Summary

This feature is related to intra-system direct retry during the RRC Connection setup or RAB

assignment.

Benefits

Intra system Directed Retry can decrease the access failure rate, and improve the QoS of the

network.

Description

Intra System Direct Retry is a feature used during Admission Control when a new call fails to

access the network in the admission procedure. This feature can be executed in RRC

connection setup procedure and in RAB ASSIGNMENT procedure.

As for RRC procedure, it occurs when a UE initiates a RRC CONNECTION REQUEST and

the request is refused in the original cell. The system will then make a decision whether the

connection setup request can be set up in a inter-frequency neighboring cell. This decision is

done according to the configuration of inter-frequency blind neighboring cells. The new cell

information will be sent to UE in the RRC CONNECTION SETUP message, indicating UE to

access to the new cell.

As for RAB procedure, it occurs when a new call fails for admission during RAB

ASSIGNMENT procedure. The system will try a blind handover to inter-frequency

neighboring cell. In order to increase the blind handover success rate, the neighbor

inter-frequency neighboring cell should cover the original cell range.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None



Dependency on UE

None


None

Dependency on CN

None



7.5.13 WRFD-02040002 Inter System Direct Retry

Availability


Summary

This feature is related to inter-system direct retry during the RAB assignment.

Benefits

Inter system Directed Retry can decrease the access failure rate, and improve the QoS of the

network.

Description

Inter System Direct Retry is a feature used during Admission Control when a new call fails to

access the network in the admission procedure. This feature is executed in RAB

ASSIGNMENT procedure.

If the RAB ASSIGNMENT procedure fails during admission, the RNC will respond with the

RAB ASSIGNEMNT RESPONSE message with the cause "Direct Retry". Then, a relocation

procedure will be initiated by RNC with the cause of "Direct Retry".

The following procedure is as the same as the normal inter-RAT handover procedure.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None



Dependency on UE

None


None

Dependency on CN

None



7.5.14 WRFD-02040003 Inter System Redirect

Availability


Summary

This feature is related to inter-system redirect during the RRC assignment.

Benefits

Inter-system Redirect can decrease the access failure rate, and improve the QoS of the

network.

Description

Redirect feature is used during admission procedure when a new call is failed due to resource

unavailable. It occurs in RRC CONNECTION SETUP procedure.

When a UE initiates a RRC CONNECTION REQUEST and the request is refused in the

original cell. And RRC direct retry fails too. The system will send RRC CONNECTION

REJECT message with Redirection info indicating UE to access to an inter-system cell.

Compared with RRC Direct Retry procedure, UE will perform a new cell-reselection

procedure in inter-system Redirect.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None



Dependency on UE

None


None

Dependency on CN

None



7.5.15 WRFD-02040004 Traffic Steering and Load Sharing During RAB Setup

Availability


Summary

With this feature, the load of the service and the required service type are considered during

RAB setup to implement traffic steering and load sharing between different frequencies or

different frequency bands.

Benefits

If traffic steering is enabled during RAB setup, newly admitted services are carried on the

specified frequency to reduce the impact on the old services, achieving smooth network

evolution.

If load sharing is enabled during RAB setup, the probability of congestion on each frequency

is reduced, the service access success rate is improved, and the number of load-based

handovers performed after service setup is reduced. Therefore, the quality of service is

improved.

Description

Services are classified into four types: R99 RT, R99 NRT, HSPA, and others (such as MBMS).

Different priorities are defined for different types of services in each cell. If traffic steering is

enabled, the cell with the highest priority is selected according to the service type during the

RAB setup.

If load sharing is enabled, the load on the current cell and the loads on the neighboring cells

that cover the same area are considered during RAB setup to ensure that new services access

the cell with the lowest traffic load.

Traffic steering and load sharing during RAB setup can be enabled or disabled respectively. If

both of the functions are enabled, traffic steering takes precedence over load sharing. That is,

the cell with the highest priority is selected on the basis of traffic steering. If multiple cells

have the same priority, then the cell with the lowest traffic load is selected.



Traffic steering and load sharing are implemented through blind handovers. These two

functions apply to the scenarios where neighboring cells have the same coverage.

Enhancement

In RAN12 Periodically DRD based on measurement is introduced, RAB can be setup in the

original cell, and by following inter frequency measurement to chose a neighboring cell to

perform DRD, reduce the drop rate caused by blind handover. The Periodically DRD based on

blind handover or based on measurement can be selected by operator.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None





7.5.16 WRFD-02040005 Inter-Frequency Redirection Based on Distance

Availability


Summary

This feature supports inter-frequency redirection based on distance during RRC connection

setup.



Benefits

This feature increases the RRC connection setup success rate and reduces the call drop rate.

Description

This feature solves the coverage overlap problem for UMTS networks.

Upon receiving an RRC CONNECTION REQUEST message from a UE, the RNC calculates

the propagation delay for the UE. The RNC then compares the propagation delay with the

inter-frequency redirection threshold and performs inter-frequency redirection based on the

distance between the NodeB and the UE.

Enhancement

None

Dependency


None


None


None


None


None


None



7.5.17 WRFD-020402 Measurement Based Direct Retry

Availability




Summary

After the setup of UE RRC connection, RNC can immediately initiate inter frequency or inter

system measurement, then RNC can perform direct retry according to the measurement result

when the RAB assignment is received from CN.

Benefits

The feature can increase the success rate of DRD, reduce the drop rate caused by DRD with

blind handover, improves the network performance.

Description

When an RAB is set up and the DRD is triggered, the Directed Retry Decision (DRD)

algorithm uses the blind handover procedure to setup the RAB in another cell. In this situation,

if the current cell and the DRD target cell cover different areas, the UE DRD may fail.

After the Measurement based direct retry (MBDR) function is implemented, inter-frequency

or inter-RAT measurement is performed. This ensures good signal quality of the DRD target

cell. With this function, the success rate of inter-frequency or inter-RAT DRD can be ensured

even if the current cell and the DRD target cell cover different areas.

The function can be configured with the service type:

The following types of service support inter-frequency MBDR:

− CS AMR

− CS non-AMR

− PS R99

− PS HSPA

Only CS AMR services support inter-RAT MBDR.

After an RRC connection setup, the RNC determines whether to establish services in

inter-frequency or inter-RAT cells based on the current cell load and the type of services to be

established. If required, the RNC sends the UE an inter-frequency or inter-RAT measurement

control message, instructing the UE to measure the signal quality of the target cell. If the

signal quality of the target cell meets the specified requirements, the RNC establishes services

in the target cell.

If MBDR is executed, the other types of DRD will not be performed subsequently in the call.

Enhancement None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



None


None

Dependency on CN

None





7.5.18 WRFD-020120 Service Steering and Load Sharing in RRC Connection Setup

Availability


Summary

This feature enables service and load sharing between different frequencies, bands, or systems

based on the service type and cell load.

Benefits

In the RRC connection setup phase, this feature can implement service steering and shorten

the delay of service setup. In addition, this feature can provide inter-frequency or inter-RAT

load sharing under different coverage and increase the success rate of load sharing.

Description

In the RRC connection setup phase, this feature enables the following functions: (1)

inter-frequency or inter-RAT service steering based on the setup reasons of RRC connections;

(2) inter-frequency or inter-RAT load sharing under different coverage based on the cell load

or redirect proportion.

With this feature, service steering and load sharing are available through RRC redirection in

the RRC connection setup phase. In the RAB setup phase, the direct retry is used for service

steering and load sharing. As the RRC redirection is a cell reselection procedure based on UE

measurement, this feature is more suitable for the scenarios (for example, different frequency

bands are available or no site is shared) to implement service steering and load sharing of two

TRXs.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE needs to be compliant with 3GPP Release 6 (or later) to support the feature.


None

Dependency on CN

None



7.5.19 WRFD-020124 Uplink Flow Control of User Plane

Availability


Summary

This feature enables the proprietary IEs on the Iub interface to detect the uplink packet loss of

R99 services. In addition, this feature enables the transmission of TF limitations to control

uplink traffic.

Benefits

This feature prevents the uplink transmission from packet loss for lack of flow control, and

increases the service transmission efficiency.

Description

This feature is applicable to R99 service. The Uplink Flow Control of User Plane feature for

HSUPA users is a standard flow control mode defined by the 3GPP protocols and has been

implemented.

In uplink single service data transmission, when the NodeB transmits data on the Iub interface,

packet loss may occur due to insufficient processing capability of the buffer or insufficient

transport network capability. In this case, data is repeatedly retransmitted, which causes the

decrease of transmission and service processing efficiency.

Huawei RAN uses the spare field in the Iub FP frame, which enables the RNC to detect the

information about the packet loss in the uplink. When the packet loss threshold is reached, the



RNC decides that this service enters the congestion state in the uplink, and then reduces the

uplink data transmission rate of the UE by sending the TF Restriction message to the UE.

This is a proprietary feature of Huawei.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


None

7.5.20 WRFD-140211 Dynamic Target RoT Adjustment

Availability


Summary

In a cell where the uplink coverage is not limited, this feature adaptively adjusts the target

Rise over Thermal (RoT) to increase uplink cell throughput.

Benefits

With this feature, the RNC can dynamically adjust the target RoT based on cell coverage to

achieve a balance between coverage and capacity. In scenarios where the uplink coverage is

not limited, such as densely populated urban areas, the uplink throughput can be increased by

up to 20% with this feature.



Description

In the uplink cell load control algorithm, RoT is an important parameter that reflects the cell

uplink load level. A large target RoT leads to a heavy uplink cell load but a small cell

coverage area. In a live network, the cell coverage performance varies greatly by radio

environment, such as densely populated urban areas and suburbs. Setting the target RoT to a

fixed value cannot account for varied radio environments.

In a cell with good coverage, for example, in central business districts (CBDs), if the target

RoT is set to a fixed value, the uplink cell load may reach the preset maximum when the UE

transmit power is still sufficient. This leads to limited uplink cell throughput.

This feature enables the RNC to automatically adjust the target RoT to increase the uplink cell

throughput without affecting network performance. The RNC adjusts the target RoT by

changing the value of the information element (IE) Maximum Target Received Total Wide

Band contained in the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST

message sent to the NodeB.

When the actual RoT for a cell approaches or exceeds the target cell load and the

transmit power resources for UEs in the cell are sufficient, the RNC gradually raises the

target cell load to increase cell throughput.

When the transmit power of a R99 UE in a cell is insufficient or when the transmit

power of an HSUPA UE is insufficient and its throughput is lower than the preset

threshold, the RNC rapidly decreases the target cell load to prevent KPI degradation.

This feature may incur the following risks:

When the cell coverage is insufficient, this feature increases the cell coverage by

reducing the target RoT. The RNC adjusts the target RoT step by step. Adjusting RoT

may lead to call drops of users in weak coverage areas. Therefore, this feature may

increase the call drop rate.

In scenarios where the RNC increases the target RoT, the uplink cell coverage shrinks.

This causes UEs in idle mode unable in weak coverage areas to access the network,

affecting user experience.

It is recommended that this feature be used together with Huawei professional services to

avoid these risks.

Enhancement

None

Dependency


None



EULP+EDLP, or EULPd+EDLP boards. Downlink services must be established on the

EBBI, EBOI, or EDLP board.

The DBS3800 must be configured with the EBBC or EBBCd board, and downlink services must be established on the EBBC or EBBCd board.




board. Downlink services must be established on the WBBPb, WBBPd or WBBPf board.


None


None


None




This feature should be used with Huawei professional services.



7.5.21 WRFD-140212 CE Overbooking

Availability


Summary

This feature enables the RNC to adjust its credit resource usage based on the actual channel

element (CE) usage of admitted UEs. Therefore, the RNC's capability to perform admission

control based on credit resource usage is enhanced.

Benefits

In networks where actual CE usage is low due to low transmission rates of HSUPA UEs, this

feature provides the following benefits:

More UEs can be admitted.

More HSUPA UEs can use 2 ms transmission time interval (TTI).

Compared with 10 ms TTI, 2 ms TTI enables HSUPA UEs to achieve a higher peak rate

and a shorter scheduling delay, which improves user experience and admits more UEs.

Using 2 ms TTI also increases uplink cell throughput when Uu and Iub resources are

sufficient.

Improves user experience for UEs in connected mode.



Description

Generally, the RNC reserves a certain amount of credit resources for each admitted UE. To

ensure user experience for HSUPA UEs, the RNC reserves more credit resources for 2 ms

TTI HSUPA UEs. When the total amount of reserved credit resources exceeds a specified

threshold, the RNC rejects new UE access attempts. However, the actual CE usage of the

NodeB is low. This is because the transmission rates of HSUPA UEs are low in most cases

due to the high penetration rate of smart phones.

To solve this problem, Huawei introduces CE Overbooking. With this feature, the NodeB

adjusts the actual credit resource usage of admitted UEs based on traffic volume and reports

the actual credit resource usage to the RNC through a private interface. The RNC then

performs admission control on new UEs based on the reported credit resource usage. In

networks where actual CE usage is low due to low transmission rates of HSUPA UEs, more

UEs can be admitted after this feature is enabled, which increases uplink cell throughput.

This feature has the following impact on the algorithms related to credit resources:

Increases the number of admitted UEs.

Increases the number of 2 ms TTI HSUPA UEs during a PS best effort (BE) service setup

or reconfiguration.

Reduces the probability of basic congestion of credit resources.

Reduces the probability of admitted-CE-based dynamic TTI adjustment for 2 ms TTI

HSUPA UEs processing BE services.

Using this feature poses the following risks:

If more UEs are admitted to the NodeB and a large number of UEs transmit data

simultaneously:

- Actual bit rate might be less than the guaranteed bit rate (GBR).

- The CE resources allocated by the NodeB to a 2 ms TTI HSUPA UE may not be

sufficient for this UE to transmit one Radio Link Control packet data unit (RLC

PDU). If Admission-CE-based Dynamic TTI Adjustment for a Single BE Service over

HSUPA is disabled, Traffic Radio Bearer (TRB) may be reset, which could result in

call drops. If Admission-CE-based Dynamic TTI Adjustment for a Single BE Service

over HSUPA is enabled, dynamic TTI adjustments from 2 ms to 10 ms will be

triggered, decreasing the risk of call drops. Therefore, it is recommended that

Admission-CE-based Dynamic TTI Adjustment for a Single BE Service over HSUPA

be enabled.

In networks where actual CE usage is low due to low transmission rates of HSUPA UEs,

the air interface load increases in proportion with the number of admitted UEs, which

may increase the call drop rate.

Enhancement

None

Dependency


None





or EULPd board.

The DBS3800 must be configured with the EBBC or EBBCd board.


board.


None


None


None




This feature should be used with Huawei professional services.



7.5.22 WRFD-140213 Intelligent Access Class Control

Availability


Summary

This feature prevents a large number of UEs from sending RRC connection setup requests

simultaneously. When the RNC determines that a cell is congested, the RNC restricts the

access of UEs of more access classes. When the RNC determines that congestion is relieved

in the cell, the RNC decreases number of access classes on which access control is performed.

Benefits

When a large number of RRC connection setup requests are rejected due to cell congestion,

this feature enables UEs to access the network at the scheduled time. This prevents excessive

RRC connection setup requests from wasting Um interface resources and RNC processing

resources, relieves network congestion, and improves system stability.



Description

When this feature is enabled, the RNC periodically determines whether a cell is congested and

controls access classes based on the cell status. If a cell is congested, the RNC restricts the

access of UEs of more access classes. If congestion is relieved in the cell, the RNC decreases

number of access classes on which access control is performed. The access classes that are not

allowed to access the network are defined in the system information. The RNC restricts the

access classes in round robin mode at the specified period so that UEs access the network at

the scheduled time. This prevents network storms caused by simultaneous access of a large

number of UEs, saves network resources, and relieves cell congestion as a result.

Enhancement

None

Dependency


None


None


UEs must support access class control delivered in system information.

For UEs complying with 3GPP Release 5 and earlier releases, access class control cannot

be performed on CS and PS services separately. If the access class of such a UE is barred,

the UE can process neither CS nor PS services.

For UEs complying with 3GPP Release 6 and later releases, access class control can be

performed on CS and PS services separately. Therefore, such a UE can process CS

services while being barred from processing PS services.


None


None


None





7.5.23 WRFD-140215 Dynamic Configuration of HSDPA CQI Feedback Period

Availability


Summary

This feature considers the uplink load as the criterion for dynamically adjusting the channel

quality indicator (CQI) feedback period for HSDPA UEs. The goal is to ensure high downlink

rates when only a small number of HSDPA UEs are online and to increase the uplink capacity

when a large number of HSDPA UEs are online.

This feature dynamically configures the CQI feedback period for PS services carried on

HSDPA in CS/PS combined services. This helps ensure satisfactory coverage for CS services

in CS/PS combined services.

Benefits


This feature increases HSDPA throughput or uplink capacity based on the uplink load.

This feature improves coverage for CS services in CS/PS combined services.

Description

After a service is set up on an HS-DSCH channel, the UE periodically reports its channel

quality indicator (CQI). The NodeB performs power control and data scheduling based on the

UE location and the radio channel quality. A short CQI feedback period ensures timely

feedback detailing radio channel quality so that the NodeB can dynamically select appropriate

data transmission rates. When there are sufficient resources, this mechanism helps ensure a

high downlink throughput. However, with a short CQI feedback period, HSDPA UEs

frequently send CQI feedback and thereby increases the uplink load. This problem is

especially severe when a large number of HDSPA UEs are online. A long CQI feedback

period may lead to insufficient CQI information acquisition of the NodeB, decreasing the

peak HSDPA throughput. When there are a large number of HSDPA UEs online, HSDPA

users generally cannot obtain sufficient resources to achieve the downlink peak throughput.

Therefore, increasing the CQI feedback period affects HSDPA users slightly in this case.

When only a small number of HSDPA UEs are online, this feature configures a short CQI

feedback period to ensure a high downlink throughput for HSDPA UEs. When a large number

of HSDPA UEs are online causing a heavy load on the uplink, this feature configures a long

CQI feedback period to ease the uplink load and thereby increase the available capacity on

uplink traffic channels.

Increasing the CQI feedback period lowers the transmit power of UEs and thereby improves

coverage. For CS/PS combined services, this feature configures a long CQI feedback period

to improve the coverage of CS services in CS/PS combined services.

Emulation tests were performed based on small-packet transmission. The test results are as

follows: If the CQI feedback period is adjusted from 2 ms to 8 ms and there are 40 online HSDPA UEs, the actual uplink load decreases by a maximum of 20% during busy hours. If the



CQI feedback period is adjusted from 4 ms to 8 ms, the uplink actual load decreases by a

maximum of 10% during busy hours.

This feature is not supported when WRFD-021350 Independent Demodulation of Signals

from Multiple RRUs in One Cell is enabled.

Enhancement

None

Dependency


None


To implement dynamic configuration of CQI feedback period based on the uplink load, the

NodeB needs to reports actual service load. The reported value has the following

requirements for the NodeB configuration:

The BTS3812E, BTS3812A and BTS3812AE do not support this feature.


If the 3900 series base stations are configured with the WBBPa board or the RRU3801C

20 W, this feature is not supported. In other configurations, this feature is supported,

To implement dynamic configuration of CQI feedback period based on CS+PS services or

based on limited coverage, the NodeB does not require any dependency.


The UE must support HSDPA.


None


None







7.5.24 WRFD-140216 Load-based Uplink Target BLER Configuration

Availability


Summary

This feature dynamically configures the target BLER on uplink R99 channels based on the

uplink load.

Benefits

This feature increases the total uplink capacity by slightly decreasing the throughput on a

single link when the uplink load is heavy.

Description

In the WCDMA system, a high signal-to-noise ratio (SNR) increases the possibility of data

blocks being correctly received. However, a high SNR requires high transmit power, which

results in increased interference to the system. Currently, most UEs only support R99

channels on the uplink. This feature considers the uplink load as the criterion for dynamically

configuring the target BLERs on R99 channels. When the uplink load is light, this feature

configures a small target BLER for each R99 channel to improve data transmission quality.

When the uplink load is heavy, this feature configures a large target BLER for each R99 link

to reduce link load and increase system capacity. This, however, slightly compromises the

system capacity.

In the WCDMA system, the BLER on a channel is controlled by the receiver by means of

outer loop power control. The RNC can quickly adjust the target BLERs of R99 channels on

the uplink. Therefore, this feature is used only if uplink services are set up on dedicated

physical channels.

Emulation results show that the actual uplink load decreases by at most about 15% when there

are 30 online HSDPA UEs (or R99 UEs) and the target BLER is adjusted.

This feature is not supported when WRFD-021350 Independent Demodulation of Signals

from Multiple RRUs in One Cell is enabled.

Enhancement

None

Dependency


None




This features requires the NodeB to report the value of the uplink actual service load. The

reported value has the following requirements for the NodeB configuration:

The BTS3812E, BTS3812A and BTS3812AE do not support this feature.


If the 3900 series base stations are configured with the WBBPa board or the RRU3801C

20 W, this feature is not supported. In other configurations, this feature is supported.


None


None


None


None



7.5.25 WRFD-140217 Inter-Frequency Load Balancing Based on Configurable Load Threshold

Availability


Summary

This feature balances inter-frequency load by triggering measurement-based inter-frequency

handovers. With this feature, the RNC compares measurement results of uplink and downlink

power resources, code resources, and channel element (CE) resources in a cell with load

thresholds for the corresponding service. Based on the comparison result, the RNC selects the

UEs and target cell for an inter-frequency handover.

This feature supports load balancing between cells on the following:

Intra-band frequencies

Inter-band frequencies

Inter-RNC frequencies

Inter-vendor frequencies

Frequencies between the macro network and the micro network



Benefits

This feature achieves load balancing in a diverse range of inter-frequency scenarios by

flexibly setting load thresholds. For example, this feature sets different load thresholds to

accommodate load balancing requirements in the following typical scenarios:

Overlay network: Different load thresholds are set for circuit switched (CS) services and

packet switched (PS) services to achieve load balancing between inter-frequency cells

under different RNCs.

Macro and micro combined network: Different load thresholds are set for the macro

network and micro network so that traffic preferentially flows in the micro network.

Description

Different from load reshuffling (LDR) for UEs in connected mode, this feature balances loads

between inter-frequency cells under different RNCs by using configurable load thresholds.

If the power resources, code resources, or CE resources reach the preset threshold, the RNC

selects a specified number of UEs for measurement and hands over the UEs that meet

handover conditions to an inter-frequency cell.

This feature supports multiband load balancing between inter-frequency cells under the same

RNC or different RNCs, and between macro and micro networks.

This feature provides separate cell-level switches and load thresholds for power resources,

code resources, or CE resources in the uplink and downlink. The switches determine whether

the measurement of related resources is considered during load balancing. In addition, this

feature provides configurable thresholds for triggering and stopping load balancing of CS and

PS services.

Enhancement

None

Dependency


None


None


None


None


In the inter-band scenario, this feature depends on WRFD-020110 Multi Frequency Band

Networking Management.





7.5.26 WRFD-150201 Micro Cell Dynamic Rx Sensitivity Control

Availability


Summary

This feature applies to the following typical scenario:

A macro cell and its neighboring micro cell use the same frequency.

The maximum transmit power of the macro cell is 20 W.

The maximum transmit power of the micro cell is 5 W or 1 W.

The difference in the downlink pilot power between the macro cell and micro cell is 6 dB

or 13 dB.

The difference in pilot power causes two problematic areas:

Soft handover (SHO) area

Non-SHO area

Non-SHO Area

In the non-SHO area, the best cell for a UE is the macro cell, and the UE is closer to the micro

cell than to the macro cell. The UE causes greater interference to the micro cell than to the

macro cell.

SHO Area

In the SHO area, the best cell for a UE is the macro cell, and the UE is also connected to the

micro cell. In this case, both the macro cell and micro cell perform uplink inner-loop power

control on this UE. Inner-loop power control performed by the micro cell plays the leading

role because the uplink Signal-to-Interference Ratio (SIR) on the dedicated physical control

channel (DPCCH) received in the micro cell is greater than that received in the macro cell.

This affects the HSDPA or HSUPA throughput for the macro cell. The following figure shows

the two problematic areas.

This feature provides the following functions:



Inter-frequency redirection in the problematic areas

Inter-frequency handover in the problematic areas

Macro and micro cells joint desensitization

Benefits


Decreases the call drop rate.

Increases the HSDPA or HSUPA throughput for a UE in the problematic areas.

Reduces strong uplink interference the micro cell suffers from UEs in the macro cell.

Description

When you enable this feature, the system performs the following three steps to solve the

problem:

1. Partially desensitizes the micro cell on the basis of the macro and micro cells joint

desensitization algorithm, increases the background noise, and reduces the receive

sensitivity for the micro cell. These actions prevent the UEs carried on the macro cell's

RACH from blocking the uplink of the micro cell, and they narrow the difference in the

uplink between the macro and micro cells.

2. Redirects or hands over the UEs in the problematic areas to an inter-frequency macro

cell that has no intra-frequency neighboring micro cells. This action is based on the

problematic-area inter-frequency redirection algorithm and the problematic-area

inter-frequency handover algorithm. This avoids call drops or throughout drops caused

by the difference in the uplink between the macro and micro cells. The following figure

shows that UEs in the problematic areas are handed over to another inter-frequency

macro cell.

3. If some UEs remain in the problematic areas, the system totally desensitizes the micro

cell based on the macro and micro cells joint desensitization algorithm to increase the

background noise and reduce the receive sensitivity for the micro cell until the uplink

SIR on the DPCCH received in the macro cell is the same as that received in the micro

cell when a UE is at the downlink boundary. This eliminates the difference in the uplink

between the macro and micro cells, reduces the call drop rate in the problematic areas,

and improves the throughput for the UEs in the problematic areas. The following figure

shows that the two problematic areas are eliminated.



Enhancement

None

Dependency


None


Only the 3900 series and 3902E base stations support this feature.

Dependency on UEs

None


None


None


Inter-frequency redirection in the problematic areas depends on the WRFD-020400 DRD

Introduction Package.

In the inter-band scenario, inter-frequency handover in the problematic areas depends on

the WRFD-020110 Multi Frequency Band Networking Management.



7.5.27 WRFD-150232 Multiband Direct Retry Based on UE Location

Availability


Summary

During service setup or reconfiguration, this feature performs the following actions on UEs

based on UE path loss:

Enables UEs in the center of a low-frequency cell to access a high-frequency

neighboring cell.

Enables UEs at the edge of a high-frequency cell to access a low-frequency neighboring

cell.

This feature achieves load sharing between high- and low-frequency cells.

Benefits

In a UMTS multiband network where high- and low-frequency carriers are under the same

NodeB and cover the same area, this feature preferentially helps ensure capacity for

high-frequency carriers and helps ensure coverage for low-frequency carriers.

Description

This feature consists of the following phases:

1. After a UE sets up a radio resource control (RRC) connection, the RNC starts periodic

intra-frequency measurement control over the UE.

2. The RNC obtains measurement reports from the UE.

3. Upon receiving the RAB ASSIGNMENT REQUEST message from the CN, the RNC

calculates the UE path loss based on the measurement results. Then, the RNC performs

Directed Retry Decisions (DRDs) based on the UE path loss to select a suitable

frequency band for the UE:

− If the UE accesses a low-frequency cell and the UE path loss is lower than a specified

threshold, the RNC determines that the UE is located in the cell center. Then, the

RNC instructs the UE to preferentially access a high-frequency neighboring cell

through a blind handover.

− If the UE accesses a high-frequency cell and the UE path loss is higher than a

specified threshold, the RNC determines that the UE is located at the cell edge. Then,

the RNC instructs the UE to preferentially access a low-frequency neighboring cell

through a blind handover.

This feature improves user experience in the following ways:

UEs at the edge of high-frequency cells are handed over to lower-frequency cells

because low frequency band has good propagation performance.

In certain scenarios, UEs in the center of lower-frequency cells are handed over to high-frequency cells to reduce the lower-frequency cells load and guarantee the

coverage.



This feature is based on blind handovers and applies to scenarios where high- and

low-frequency carriers are under the same NodeB and cover the same area. This feature takes

precedence over other DRD algorithms.

This feature is only applied to HSDPA users.

Enhancement

None

Dependency


None


None

Dependency on UEs

The UEs must support both high- and low-frequency bands.


None


None



WRFD-020110 Multi Frequency Band Networking Management


7.6 GSM and UMTS Radio Resource Management

7.6.1 WRFD-070004 Load Based GSM and UMTS Handover Enhancement Based on Iur-g

Availability


Summary

This feature is based on Huawei private information exchange mechanism over the Iur-g

interface. With this feature, the traffic is distributed through the RRC redirection and

load-based handover from the 3G network to the 2G network on the basis of the service



attributes and the load of the 2G networks when 3G cell enters LDR status. In this manner, the

load is shared by the GSM network when the load of UMTS network is heavy.

Benefits

Based on Huawei private information exchange mechanism over the Iur-g interface, this

feature shares the load of the UMTS network by the GSM network. As a result, the load of the

GSM network and the UMTS network in the same coverage area remains even, the risk of

network congestion due to the load imbalance between networks is reduced, and the network

usage is increased.

Description

With this feature, the networks in the same coverage area have nearly the same load.

Therefore, the access failures during the MS access are greatly reduced, and each network has

remaining resources to provide a higher rate for the PS services. If the GSM cell and the

UMTS cell under the same MBSC with co-sited MBTSs have the same-coverage area,

3G-to-2G handover algorithm enhancement in connection state is available based on the

private information exchange mechanism.

For the load management of the 3G cells, the inter-RAT handover based on load or HCS by

coverage is enhanced on the basis of Huawei private information exchange mechanism over

the Iur-g interface. With this feature, a more proper target cell can be selected for the

inter-RAT handover. In addition, the probability of the ping-pong handover due to the high

load of the neighboring 2G cell can be minimized if the following requirements are met:

The inter-RAT neighboring cell with the lowest load is selected.

The difference between the load in the source cell and the load in the target 2G cell

exceeds the configured threshold.

The handover does not lead to congestion in the target cell.

Enhancement

None

Dependency


In the BSC6900, only the FG2a, FG2c, GOUa, or GOUc board supports the Iur-g

interface.


None


None


None

Dependency on CN



None

Dependency on Other features

WRFD-020306 Inter-RAT Handover Based on Load or WRFD-021200 HCS

(Hierarchical Cell Structure)

GBFD-511101 GSM/UMTS Load Handover Enhancement based on Iur-g

7.6.2 WRFD-070005 NACC Procedure Optimization Based on Iur-g

Availability


Summary

This feature enables the exchange of messages containing the RAN Information Management

(RIM) information over the Iur-g interface between the RNC and BSC. The Iur-g protocol

stack complies with the 3GPP specifications. In this way, the NACC procedure for PS

services from a UMTS cell to a GSM cell does not require the information transfer via the

CN.

Benefits

This feature provides a solution that enables the NACC procedure when the CN does not

support the RIM procedure. The simulation results show that this feature helps shorten the

delay of PS handover by two seconds. As the delay is shortened, the user experience can be

improved.

Description

As indicated in the 3GPP specifications, the GERAN (P) SI is obtained through the RIM

procedure during the NACC procedure. The NACC procedure involves the RNC, UMTS

SGSN, GSM SGSN, and BSC. When this feature is applied, the GSM/UMTS GERAN (P) SI

information is transferred over the Iur-g interface between the base station controllers, without

being transferred via the CN.

This feature applies only to the Iur-g interface, which connects different base station

controllers. In such a case, the GERAN (P) SI information is transferred over the protocol

stack complying with the 3GPP specifications. If there is no Iur-g interface between UMTS

and GSM, the GERAN (P) SI information can be exchanged only via the CN, and accordingly

the NACC procedure can be implemented only through the CN, as specified in the 3GPP

specifications.

The following figure shows the network topology that supports this feature. As shown in the

figure, the Huawei RNCs and BSCs are connected through the Iur-g interface. This feature

applies to the BSC/RNC of other vendors only if it has passed the interoperability test (IOT).

Otherwise, the CN-involved NACC procedure is applied. For the BSC/RNC of other vendors,

the common cell reselection procedure is performed if the CN does not support the RIM

procedure.



Enhancement

None

Dependency



interface.


None


UEs must support NACC procedure.


None

Dependency on CN

None


GBFD-511102 NACC Procedure Optimization Based on Iur-g between GSM and UMTS

or WRFD-020303 Inter-RAT Handover Based on Coverage

or WRFD-020305 Inter-RAT Handover Based on Service

Huawei RNC/MBSC

UMTS cell

GSM Cell

Huawei GBSC/MBSC

Iur-g

GBSC/RNC of other venders

UMTS SGSN SSGSN

GSM SGSN

NACC

NACC

GSM cell



or WRFD-020306 Inter-RAT Handover Based on Load

or WRFD-021200 Hierarchical Cell Structure (HCS)

7.6.3 WRFD-070006 GSM and UMTS Load Balancing Based on Iur-g

Availability


Summary

This feature implements RRC redirection and the load-based GSM/UMTS handover through

the exchange of Huawei proprietary IE over the Iur-g interface. The Iur-g protocol stack

complies with the 3GPP specifications. With this feature, the traffic is distributed on the basis

of the service handover indicator and the load of the GSM network and UMTS network

during RRC connection setup or after RAB setup. In this way, a load balance is achieved

between the GSM network and UMTS network.

Benefits

This feature aims at striking a load balance between the GSM network and UMTS network. It

reduces the possibility of congestion in areas covered by both GSM and UMTS. The network

utilization is consequently increased. The simulation results show that this feature reduces the

percentage of invalid handovers between the GSM network and UMTS network by up to 6%

and decreases the access congestion rate during busy hours by up to 4%.

Description

As high-speed PS services are on great demand by a large number of GSM/UMTS dual-mode

handsets in well-established 2G/3G commercial networks, the load of UMTS network has

become increasingly heavy. Facing the situation, network operators focus on reducing the

congestion rate and making full utilization of the present network capacity. This feature can

efficiently address this issue. With this feature, the load balance between the GSM network

and UMTS network can be achieved. This helps reduce the possibility of network congestion

and the percentage of invalid inter-RAT handovers. As a result, the capacity of both the GSM

network and UMTS network can be fully utilized.

The following figure shows the applicable scenario where the GSM cell and UMTS cell have

the same coverage. Through the exchange of load information of the GSM network and

UMTS network over the Iur-g interface, redirection for load-balancing can be performed

during RRC connection setup, and load-based handover can be performed after RAB setup.

Redirection for load-balancing during RRC connection setup

Redirection for load-balancing during RRC connection setup is performed on a number of

UEs requesting CS services in a UMTS cell when the same-coverage GSM cell is lightly

loaded. In such a case, the RNC redirects a number of UEs to the GSM cell according to the

predefined distribution rate. The rate is considered as a probability rate with respect to the

redirection of a single UE. In this way, a load balance between the UMTS network and GSM

network can be



maintained.

Load-based handover after RAB setup

Load-based handover from UMTS to GSM after RAB setup is performed on the basis of the

service handover indicator, PS service rate, and load difference between the UMTS network

and GSM network.

If the UE requests only the CS service in a UMTS cell, the RNC decides whether the UMTS

network or GSM network processes the request. The conditions on which the decision is

based are as follows:

The UE supports GSM services.

The service handover indicator assigned by the CN or configured at the RNC shows that

the CS service can be handed over to the GSM cell.

The target GSM cell is lightly loaded.

The load difference between the source UMTS cell and target GSM cell exceeds the

predefined threshold.

The GBSC/MBSC determines whether to perform the inter-RAT handover on a number of

UEs according to the predefined distribution rate. The rate is considered as a probability rate

with respect to the redirection of a single UE. In this way, the load between the GSM network

and UMTS network is balanced.

Network operators can decide which load-balancing scheme to be applied according to the

actual situations. The major differences between the two schemes are as follows:

As it is difficult to learn the traffic class requested by the UE, the traffic class mapping

needs to be verified before performing redirection for load-balancing. For example,

whether the GSM network supports the conversational service from the UMTS network

should be verified. If the traffic class is not supported, the RNC can decide whether the

UE can be handed over to the GSM network only after RAB setup is complete.

UMTS

GSM

UEs access the UMTS network

x% of CS calls redirected to GSM network

(1-x)% of CS calls and PS services



The redirection function does not require the UE to enable the compressed mode but it

may prolong the delay of service access and also affect user experience. For the

handover performed after RAB setup, the RNC can select a candidate GSM cell as the

target cell, which improves the efficiency of load balancing. In addition, the handover

success rate is higher than the redirection success rate. In contrast to the redirection

process, the inter-RAT handover process requires the UE to enable the compressed mode.

Therefore, the handover is a relatively long process, during which the UMTS network

still provides system resources for the UEs steered to the GSM network.

To guarantee its success rate, the redirection process requires that the source UMTS cell

and the target GSM cell should have the same coverage. Differently, the handover

process only requires that the GSM cell and the UMTS cell should be neighboring cells.

Enhancement

None

Dependency

Dependency on RNC


interface.

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



WRFD-020305 Inter-RAT Handover Based on Service

GBFD-511103 GSM and UMTS Load Balancing Based on Iur-g

7.6.4 WRFD-070007 GSM and UMTS Traffic Steering Based on Iur-g

Availability




Summary

This feature supports RRC redirection and GSM/UMTS inter-RAT handover based on service.

With this feature, services are steered on the basis of the service handover indicator,

hierarchical network planning, and the load of the GSM network and UMTS network when an

MS accesses the network. Service steering enables UEs requesting speech or low-speed PS

services to access the GSM network and those requesting high-speed PS services to access the

UMTS network.

Benefits

This feature helps operators to develop network services in hierarchies, which facilitates the

hierarchical network planning. With this feature, the spectrum utilization is increased. The

simulation results show that this feature reduces the percentage of invalid inter-RAT

handovers by up to 8% and increases the total capacity of the GSM and UMTS networks by

up to 8%.

Description

In the case of evolution from a legacy GSM network to a GSM&UMTS network, the UMTS

network usually has a larger capacity in the early stage. How to fully utilize the UMTS

network to carry high-speed services has become a major concern for network operators. This

feature provides the service steering function for the benefit of network planning. Service

steering helps improve the utilization of resources in each network and divide frequencies and

RATs into different hierarchies.

When a GSM cell and a UMTS cell have the same coverage, considering resource utilization

and QoS requirements, speech services are steered to the GSM cell whereas data services are

steered to the UMTS cell.

In addition to service steering, the selection of RAT for a UE to access also depends on the

network load.

This helps optimize the network performance in the following aspects:

Tasks of different RATs can be clearly defined, which facilitates the planning of network

capacity.

Service steering can reduce interference between different traffic classes, increasing the

capacity of the UMTS network.

The flexible distribution of services to the UMTS and GSM cells can improve the

utilization of system resources, reduce the access congestion rate, and enhance the QoS

of the network.

This feature provides two load-balancing schemes. One is to redirect CS services to the GSM

cell during RRC connection setup, and the other is to perform load-based handovers between

the GSM and UMTS cells after RAB setup.

During the redirection process, if the UE initiating the RRC connection request in the UMTS

cell uses the protocol of R6 or later, the UE carries information about the access domain and

call type when the GSM cell under the same coverage is lightly loaded. If the access domain

is the CS domain and the call type is the speech service, the service is redirected to the GSM

cell. In this way, the UE initiating the request for speech services in the UMTS cell is steered



to the GSM cell. Therefore, more capacity of the UMTS system is reserved for the UEs

requesting high-speed PS services.

The load-based handover between the UMTS and GSM cells after RAB setup is an enhanced

function of the existing handover feature provided by Huawei. This function is determined by

the service handover indicator, PS service rate, and load of the UMTS/GSM system after

RAB setup.

If the UE requests only the CS service in a UMTS cell, the RNC hands the UE over to a

neighboring GSM cell when the following conditions are met:

The UE supports GSM services.

The neighboring GSM cell is lightly loaded.

Network operators can decide which load-balancing scheme to be applied according to the

actual situations. The major differences between the two schemes are as follows:

As it is difficult to learn the traffic class requested by the UE, the traffic class mapping

needs to be verified before performing redirection for load-balancing. For example,

whether the GSM network supports the conversational service from the UMTS network

should be verified. If the traffic class is not supported, the RNC can decide whether the

UE can be handed over to the GSM network only after RAB setup is complete.

The redirection function does not require the UE to enable the compressed mode but it

may prolong the delay of service access and also affect user experience. For the

handover performed after RAB setup, the RNC can select a candidate GSM cell as the

target cell, which improves the efficiency of service steering. In addition, the handover

success rate is higher than the redirection success rate. In contrast to the redirection

process, the inter-RAT handover process requires the UE to enable the compressed mode.

Therefore, the handover is a relatively long process, during which the UMTS network

still provides system resources for the UEs steered to the GSM network.

To guarantee its success rate, the redirection process requires that the source UMTS cell

and the target GSM cell should have the same coverage. Differently, the handover

process only requires that the GSM cell and the UMTS cell should be neighboring cells.

Enhancement

None

Dependency

Dependency on RNC


interface.

Dependency on NodeB

None

Dependency on UE

None


None



Dependency on CN

None




GBFD-511104 GSM and UMTS Traffic Steering Based on Iur-g

7.6.5 WRFD-020303 Inter-RAT Handover Based on Coverage

Availability


Summary

This feature is related to inter-RAT handover based on coverage such as Active Set Quality

measurement 2D, UE uplink QoS or emergency blind handover triggered by event 1F. This

feature deals with the inter-RAT handover caused by coverage reason or UE mobility.

Benefits

Inter-RAT handover improves flexibility in planning UMTS and GSM networks for the

network operator. It can also reduce cost by utilizing the existing GSM network resources and

provide coverage expansion, load sharing, and layered service.

Description

Inter-RAT handover from UMTS to GSM/GPRS Function is the procedure during which the

WCDMA RAN initiates handover (for CS services) or UE initiates cell reselection (for PS

services) to the GSM.

The GSM/GPRS system cannot perform CS and PS services simultaneously. Therefore, when

the handover for CS and PS domain combined services is determined, the CS service can be

handed over from the WCDMA system to the GSM/GPRS system successfully, but the PS

service will be suspended. After the CS call is finished, a resume request will be sent to the

2G SGSN to continue the PS service.

Inter-RAT handover from UMTS to GSM can be triggered by coverage reason, cell load,

service of UE and HCS. The trigger condition based on the cell load belongs to the optional

feature WRFD-020306 Inter-RAT Handover Based on Load. The trigger condition based on

the service assigned by CN node belongs to the optional feature WRFD-020305 Inter-RAT

Handover Based on Service. This feature deals with inter-RAT handover triggered by

coverage reason.

This trigger condition is based on the quality measurement. The compressed mode for DL or

UL will be triggered by event measurement report 2d for inter-frequency and inter-RAT

handover and stopped by event measurement report 2f. When the compressed mode triggered,

the RNC will start the inter-RAT measurement in UE to get the target cell to handover if

inter-RAT neighboring cells are configured.



The related measurement quantity can be either Ec/N0 or RSCP. Moreover, event 3A and

period measurement report mode are supported and which measurement quantity and mode to

use can be configured by operator. The measurement related parameters include threshold,

hysteresis, and trigger delay time. The inter-RAT neighboring cell number can be up to 32.

The compressed mode includes two types, spreading factor reduction (SF/2) and high layer

approaches. The usage of type of compressed mode is decided by the RNC automatically,

according to the configurable spreading factor used in uplink and downlink.

Another measurement report 1F can also trigger inter-RAT handover, but compressed mode

will not be triggered in this scenario since such report means call drop may occur in any time

and there is no time to implement measurement procedure. The target cell to handover will be

selected based on the configurable parameter "Blind Handover Priority" in the neighboring

inter RAT cells, Priority 0-15 indicates the handover successful rate can be guaranteed, such

parameter will be certain as the result of network planning.

Inter-RAT handover triggered by UE TX power is available for PS BE, CS AMR services.

This function can be switched on/off by operator.

The procedure of Inter-RAT handover from UMTS to GSM is executed by Relocation

Preparation procedure at Iu interface and handover or cell change order command at Uu

interface.

When the UE is in CELL_FACH, CELL_PCH, or URA_PCH state, UMTS GSM handover

in PS domain is triggered through Inter-RAT Cell Re-selection from UMTS to GPRS

procedure. This procedure is triggered by UE and realized by Routing Area Update procedure.

The parameters for inter-RAT handover can be configured and are different for CS and PS

services respectively.

Since the GSM/GPRS system cannot perform CS and PS services simultaneously, Inter-RAT

handover from GSM/GPRS to UMTS Function can be divided to CS and PS individually.

On the UMTS side:

For CS: inter-RAT handover from GSM/GPRS to UMTS is comprised of Relocation Resource

Allocation, Relocation detect, Relocation complete procedure at Iu interface and

HANDOVER TO UTRAN COMPLETE message processing at Uu interface.

For PS: inter-RAT handover from GSM/GPRS to UMTS is the same as the setup of a PS

service.

Enhancement

In RAN10.0, inter-RAT handover triggered by UE TX power or high UL BLER is available

for PS BE and CS AMR services.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE





None

Dependency on CN

None


None

7.6.6 WRFD-020309 Inter-RAT Handover Based on DL QoS

Availability

This feature is introduced in RAN10.0

Summary

When the load of voice and PS BE services is higher in the cell and downlink QoS drops, this

feature enables the UE to be handed over to an inter-RAT cell, guaranteeing QoS

requirements.

Benefits

DL QoS based inter-RAT handover provides the method to prevent call drop and guarantee

the QoS in inter-RAT networking, therefore, improving the network performance and

enhancing the end user experience.

Description

In the scenarios of severe fading and high load, the call drop could take place due to the

limitation of DL transmitted code power. In addition, coverage area is different for different

services in network planning, thereby the system should take actions in order to guarantee the

downlink QoS and keep the connection as could as possible. The evaluation of downlink QoS

status is on the basis of TCP (Transmitted Code Power) or RLC retransmission (only for PS

BE).

Once the downlink QoS is detected in bad condition, inter-RAT handover could be triggered if

in inter-system networking:

For AMR service, inter-RAT handover could be triggered based on TCP;

For PS BE service, inter-RAT handover could be triggered based on TCP and RLC

retransmission.

This feature can be switched on/off separately for AMR and PS BE services.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE



None

Dependency on CN

None


WRFD-020303 Inter-RAT Handover Based on Coverage

7.6.7 WRFD-020307 Video Telephony Fallback to Speech (AMR) for Inter-RAT HO

Availability



Summary

Before VP services are handed over to the 2G system, this feature enables the fallback of

video telephony to speech to ensure continuous calls.

Benefits

This feature provides an inter-RAT handover mechanism for the VP service which falls back

to speech instead of call drop.

Description

Video telephony is a service exclusive for 3G system. However, due to the limitation of UE

and network support capability, it is possible that the service cannot be implemented.

Therefore, Service Change and UDI Fallback (SCUDIF) is introduced in Release 6. This

feature provides the mechanism to fall back to Speech instead of call drop in these scenarios.

In 3GPP protocol TS23.172, there are two defined fall back methods:

Fallback: multi-media service fall back to speech during the setup procedure



Service Change: multi-media service fall back to speech during the RAB modification

procedure

They all belong to the bound of multi-media fall back procedure.

Fallback

This procedure can be triggered by UE or network side and implemented by the NAS

signaling. Therefore, to RAN, it is corresponding to the RAB Assignment procedure over

the Iu interface.

Service Change

This procedure can also be triggered by UE or network. When it is triggered by UE, the

CN will initiate an RAB Assignment (Modify) procedure over the Iu interface when

receiving the fallback request from the UE. When it is triggered by UTRAN, the scenario

generally aims to the 3G to 2G handover during which the VP service cannot be

supported. The following flow chart describes the procedure:

UE A MSC A

MODIFY (BCspeech)

MSC B UE B

MODIFY (BCspeech)

MODIFY COMPLETE (BCspeech)

Core Network Procedure

MODIFY COMPLETE (BCspeech)

RNC A

RANAP RAB Assignment

(configuration1, configuration 2)

RANAP Modify Request

(alternate configuration requested)

RAB Assignment Modify (Configuration 2, Configuration1)

Firstly, the MSC must assign the alternative configuration when setting up a VP service to let

UTRAN know it has the fallback capability.

When the user with VP service needs to be handed over to the 2G network, the RNC will

initiate an RAB modify request to trigger fallback. Then, fallback will be implemented by the

MODIFY procedure. From UTRAN view, it is corresponding to the RAB Assignment

(Modify) procedure over the Iu interface.

After the VP service falls back to speech successfully, the following speech inter-RAT

handover can be implemented.

Enhancement

None

Dependency

Dependency on RNC

None



Dependency on NodeB

None

Dependency on UE

The UE needs to be compliant with 3GPP Release 6 to support the feature.


None

Dependency on CN

The MSC needs to be compliant with 3GPP Release 6 to support the feature.





or WRFD-021200 HCS (Hierarchical Cell Structure)

7.6.8 WRFD-020308 Inter-RAT Handover Phase 2

Availability



Summary

This feature provides the inter-RAT relocation procedure for NACC and PS services to

shorten the interruption time of PS services caused by inter-RAT handover.

Benefits

The service interruption for PS service inter-system handover will be shorter or reduced. With

this feature, in scenario of inter-RAT handover, the user experience will be enhanced greatly

especially for the real-time PS service.

Description

The inter-RAT Handover Enhanced Package includes following features:

NACC (Network Assisted Cell Change)

PS Handover Between UMTS and GPRS

With these features, the service interruption for PS service inter-system handover will be

shorter or reduced.



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should also support NACC and PS handover.


BSC should support NACC RIM (RAN Information Management) and PS handover

procedure.

Dependency on CN

The SGSN should also support NACC and PS handover.






7.6.9 WRFD-02030801 NACC(Network Assisted Cell Change)

Availability

This feature is available from RAN6.1 (BSC6900 only).

Summary

This feature supports the standard NACC procedure defined in 3GPP specifications.

Benefits

Compared with the normal cell change, the NACC can shorten a service interruption of about

four to eight seconds and greatly enhance user experience.

Description

The NACC refers to Network Assisted Cell Change from UTRAN to GERAN, which is

different from normal cell change order procedure, due to network providing GERAN (P) SI

to UE.



In today's GPRS networks (without NACC), cell re-selection may cause a service interruption

between 4 – 8 seconds, which obviously has an impact on the user experience. Similar

interruption time can be expected in mixed UMTS and GPRS networks, during UE cell

re-selection from UTRAN to GERAN.

GERAN (P)SI information is acquired by RIM (RAN Information Management) procedure.

In this feature, when handover from UTRAN to GERAN is to be performed, and if both UE

and network support NACC, then RNC will firstly trigger the RIM procedure. If (P)SI is

obtained successfully, cell change order from UTRAN message carrying the GERAN (P)SI

information will be sent. That is, NACC is completed, which is illustrated in the following

figure. Otherwise, normal cell change order would be performed.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should also support NACC handover.


BSC should support NACC RIM (RAN Information Management).

Dependency on CN

SGSN should also support NACC handover.

BSC SRNC

UE

SGSN

RRC MEASUREMENT REPORT

WITH GERAN BEST CELL DIRECT INFORMATION

TRANSFER (RAN IFORMATION

REQUEST)

RAN INFORMATION DIRECT INFORMATION

TRANSFER (RAN

INFORMATION REPORT)

RAN INFORMATION

CELL CHANGE ORDER FROM

UTRAN (((P)SI))




WRFD-020308 Inter-RAT Handover Phase 2

7.6.10 WRFD-02030802 PS Handover Between UMTS and GPRS

Availability


Summary

This feature enables the relocation of PS services between systems.

Benefits

In inter-system handover scenarios, this feature can greatly improve user perception,

especially for real-time PS services.

Description

The PS handover is different from NACC or normal cell change function, with which the

relocation procedure between 3G and 2G is applied, just like the CS inter-system handover.

With this feature, the service interruption for PS service inter-system handover is reduced by a

great extent.

In this feature, both handover from UTRAN to GERAN and handover from GERAN to

UTRAN are supplied. If both UE and network support PS handover, handover between

UTRAN and GERAN would be performed. Otherwise, either NACC or normal cell change

order would be selected.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

The UE should also support PS handover.


BSC should support PS handover procedure.

Dependency on CN

SGSN should also support PS handover.




WRFD-020308 Inter-RAT Handover Phase 2

7.6.11 WRFD-020305 Inter-RAT Handover Based on Service

Availability



Summary

This feature supports 3G to 2G handover based on service attributes. When 3G and 2G

coexist, this feature enables the 3G traffic to be directed to the 2G system.

Benefits

This feature provides an inter-RAT handover mechanism according to the service. It can

balance the load between the two systems by transferring some kind of appropriate services to

GSM/GPRS and prevent the handover course from bad effect to services according to

attributes of the services.

Description

Inter-RAT Handover based on Service introduces a precondition for UMTS to GSM/GPRS

handover to UTRAN.

The RAB ASSIGNMENT REQUEST message sent from the CN to the RNC may include a

service handover IE. With this IE, the UTRAN determines whether to switch the

corresponding RAB from UTRAN to GSM/GPRS. The operation (the CN sends the RAB

ASSIGNMENT REQUEST message to the RNC) can also influence decisions made

regarding UTRAN-initiated inter-system handovers.

If this indicator is not included in the RAB ASSIGNMENT REQUEST message, the RNC can

use its pre-configured value for various kinds of services.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None




None

Dependency on CN

None


None


Recommend to deploy this feature with GUL Co-Operation Audit and Optimization Service

7.6.12 WRFD-020306 Inter-RAT Handover Based on Load

Availability


Summary

When a cell is in initial congestion state, this feature enables some UEs in the cell to be

handed over to an inter-RAT co-coverage cell, reducing the load of the cell.

Benefits

This feature reduces the load of the cell in basic congestion and keeps the system in a safety

state.

Description

This feature is an important action for Load Reshuffling (LDR). It enables the system to

perform inter-RAT handover that handover UE to GSM/GPRS cell and reduce current cell

load.

This action is triggered when system detects that the current serving cell load is beyond the

pre-defined congestion threshold and a cell is entering a basic congestion state. Normally the

resource used for cell load level measurement includes the power resource, that used for

NodeB load level includes Iub transport resource and NodeB CE resource if Inter-RAT

handover is taken as an action for LDR. The load measurement is done both for UL and DL.

The system will select a UE to handover during the LDR according to the UE priority. If the

UEs have the same priority, the UE with higher service bit rate will be selected first.

Enhancement

In RAN5.1, the user selection criterion considers the Traffic Class, ARP, and bear type (R99

or HSPA) when calculating the UE priority, and THP factor added in RAN6.0.



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


When this feature is used for HSDPA/HSUPA load control, WRFD-010610 HSDPA

Introduction Package and WRFD-010612 HSUPA Introduction Package are required.



7.6.13 WRFD-020401 Inter-RAT Redirection Based on Distance

Availability


Summary

If UE initialize a voice call with a long distance to the antenna, UMTS RAN can consider it as

a call attempt in the pilot contaminated area, and redirect it to GSM to avoid handover drop in

the following call procedure.

Benefits

The feature can reduce the drop rate in handover in a 2G/3G co-coverage area, solve the pilot

contamination problem and improve the network performance.

Description

Pilot contamination is a phenomenon that can cause call drop in handover.

For example, in the picture, A’ is the pilot contaminated area of Cell A. If UE setup a call in

area A’, when it moves to the cells in blue which are not the neighboring cells of cell A, the

call will drop because cell A has no handover relationship with these cells.



To solve this problem, for the voice call initiated in the contaminated area which is

co-covered by 2G and 3G, RAN will directly redirect it to GSM.

Operator can configure a distance threshold for each cell by LMT, the UE distance is

measured by RAN when RRC CONNECT REQUEST message is received, if the distance to

the antenna is beyond this threshold, the UE location will be seemed as in the contaminated

area, the system then redirect the call to GSM. In this way, the handover drop in the call

procedure will be reduced.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None



7.6.14 WRFD-020310 3G/2G Common Load Management

Availability





Summary

During inter-RAT handover or inter-system direct retry, this feature supports the transfer of

load information as stipulated in 3GPP specifications to reduce inter-RAT ping-pong

handover.

Benefits Decrease the probability of 2G system overload or congestion due to inter-RAT handover

from 3G to 2G based on service or load.

Avoid 3G system overload due to inter-RAT handover from 2G to 3G.

Avoid ping-pong handover between 3G and 2G.

Description

The 3G/2G Common Load Management applies to inter-RAT handover and inter system

direct retry. The load of source cell and target cell are considered during inter-RAT handover

from 3G to 2G or from 2G to 3G and inter system direct retry.

During inter-RAT handover from 3G to 2G, the RNC will send the load information of the

source cell to 2G through RELOCATION REQUIRED message and may get the load

information of target cell from RELOCATION COMMAND message. If the load of target

cell is in a high level (over the threshold configured) and the inter-RAT handover from 3G to

2G is triggered not because of coverage, then the inter-RAT handover from 3G to 2G will be

cancelled.

During inter-RAT handover from 2G to 3G, the RNC may get the load information of the

source cell from RELOCATION REQUEST message. If the load of source cell is not in a

high level (less than the threshold configured) and the inter-RAT handover from 2G to 3G is

triggered not because of coverage, then the inter-RAT handover from 2G to 3G will be

refused.

During inter system direct retry, the procedure and decision is similar to that of inter-RAT

handover from 3G to 2G. If the load of target cell is in a high level (over the threshold

configured), inter system direct retry will be cancelled.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None




The BSS should support this feature.

Dependency on CN

The CN should support this feature.





or WRFD-020400 DRD Introduction Package

or WRFD-020308 Inter-RAT Handover Phase 2

7.7 UMTS and LTE Radio Resource Management

7.7.1 WRFD-020126 Mobility Between UMTS and LTE Phase1

Availability


Summary

This feature covers the following functions:

UE cell selects/reselects between LTE and UMTS network.

UE with PS service handovers from the LTE network to the UMTS network are

supported.

Benefits

This feature improves the high-speed service experience of LTE UEs in the area

simultaneously covered by the UMTS network and the LTE network. In addition, in the area

not covered by the LTE network or when the LTE network is heavily loaded, some UEs with

PS service are handed over from the LTE network to the UMTS network.

Description

This feature provides a basic mobility solution for the operators who want to evolve from

UMTS to LTE.

UE cell selects/reselects between UMTS and LTE network.

The RNC supports broadcasting the information about LTE frequencies in a cell and the

parameters related to cell select/reselect. Therefore, the UEs in idle state can camp on an LTE

cell preferentially. In this way, on one hand, the UEs can obtain better experience of high-speed services in the area covered by the LTE network; on the other hand, the potential



cell load and network load of the UMTS network are reduced because these UEs gain access

to the LTE

network.

UE with PS service handovers from the LTE network to the UMTS network are

supported.

At the early construction stage of the LTE network, operators may plan the LTE network

coverage only in hot spot areas. When some UEs leave the hot spot area or the LTE system

load is heavy, these UEs need to be handed over from the LTE network to the UMTS network.

With this feature, the RNC can processes the migration requests from the LTE system. This

feature does not support the UE handover from the UMTS network to the LTE network.

Enhancement

None

Dependency

Dependency on RNC

None

LTE Cell

UMTS Cell UMTS Cell

MTS Cell

Handover

LTE Cell

UMTS Cell

LTE Cell

UMTS Cell

Normal UE:

LTE UE

Cell reselection



Dependency on NodeB

None

Dependency on UE

UE has the capability of both UMTS and LTE.


None

Dependency on CN

LTE should also support this feature


None

7.7.2 WRFD-020129 Service-Based PS Service Redirection from UMTS to LTE

Availability


Summary

If a UMTS/LTE dual-mode UE establishes services in the UMTS network, this feature allows

the RNC to redirect the UE to the LTE network when both UMTS and LTE coverage is

available and the UE establishes only PS services.

Benefits

In a UMTS/LTE multi-layer network where PS handover from UMTS to LTE is not supported

by UE or network, this feature redirects the UEs that process only PS services from the

UMTS network to the LTE network, improving user experience for PS service users.

Description

In a UMTS/LTE multi-layer network, if UE or network does not support the handover from

UMTS to LTE, then the UE will be redirected from UMTS to LTE, the following conditions

must be met:

1. The conditions for PS handover from UMTS to LTE are met and the UE or the network

cannot support the handover from UMTS to LTE.

2. The UE supports both UMTS and LTE.

3. The UE is processing only the PS services. The RAB assignment message from the SGSN

does not indicate that the PS services cannot be handed over to the LTE network.

The RNC carries the LTE frequency information in the RRC Connection Release message and directs the UE to access the LTE network.



Enhancement

In RAN15.0, the following functions are added:

Triggering redirection when the best cell changes

Support for blind redirection

Added frequency information in the SIB19 message for redirection or blind redirection.

Dependency


None


None

Dependency on UE

The UE must support 3GPP Release 8 (September 2008) or later. It also must support both

UMTS and LTE.


None

Dependency on CN

CN should support cooperation from UMTS to LTE.


None

7.7.3 WRFD-140218 Service-Based PS Handover from UMTS to LTE

Availability


Summary

If a UMTS and LTE dual-mode UE in a UMTS and LTE overlapping coverage area processes

only PS services in the UMTS network, Service-Based PS Handover from UMTS to LTE

allows the RNC to hand over the PS services to the LTE network.

Benefits


Improved user experience for PS services

Reduced service interruption time compared with redirection



Increased LTE network utilization

Description

This feature allows the RNC to hand over a UE and its PS service to the LTE network in

either of the following scenarios:

The UE in the UMTS and LTE overlapping coverage area originates a PS service in the

UMTS network.

For a UE in the UMTS and LTE overlapping coverage area that is handed over from the

LTE network to the UMTS network due to a CS fallback (CSFB), after the UE

terminates the CS voice service in the UMTS network, the UE still has ongoing PS

services.

The implementation is as follows:

1. The RNC sends the SGSN a Relocation Required message, which contains the information

about the target LTE cell.

2. The SGSN forwards the relocation request to the MME.

3. After the LTE side has made preparations for the inter-RAT handover, the MME instructs

the SGSN to send a Relocation Response message to the RNC.

4. Upon receipt of the Relocation Command message forwarded by the SGSN from the MME,

the RNC instructs the UE to hand over to the target eNodeB.

To use this feature, both the UMTS network and the UE must support LTE measurement and

UMTS-to-LTE PS handovers.

This feature supports interoperability between the UMTS network and the TDD LTE network

and between the UMTS network and the FDD LTE network. The TDD LTE and FDD LTE

networks, however, cannot coexist.

When the MOCN feature is enabled in the target LTE network, Service-Based PS Handover

from UMTS to LTE must not be enabled if the UMTS and LTE networks do not share the

same PLMN. Otherwise, call drops may occur.

Enhancement

In RAN15.0, the PS handover can be triggered when the best cell changes.

Dependency


None


None


The UE must comply with 3GPP Release 8 or later and support UMTS-to-LTE PS handovers

and LTE measurement.




The eNodeB and MME must support UMTS-to-LTE PS handovers.


The SGSN must support UMTS-to-LTE PS handovers.


None



7.7.4 WRFD-140224 Fast CS Fallback Based on RIM

Availability


Summary

This feature enables the eNodeB to obtain and maintain the system information of the UMTS

cell, including the ID of the target cell and convolutional code, through the RAN Information

Management (RIM) procedure and sends the information to the UE in the RRC Connection

Release message. This can reduce the access time when the UE is redirected from an LTE

network to a UMTS network without reading system information, improving user experience.

Benefits

The LTE-to-UMTS redirection delay can be reduced by up to 1.28s, depending on the size of

SIB11. This improves user experience because the access time is shortened during redirection.

Description

Upon receiving a RIM request for the system information of the UMTS cell from the eNodeB,

the RNC sends the system information of the UMTS cell to the eNodeB through the RIM

procedure. If the system information of the UMTS cell changes (except for changes in the

information element UL interference in SIB7), the RNC sends the updated system information

to the LTE network through the RIM update procedure.

The eNodeB receives and maintains the system information of the UMTS cell. With flash

circuit-switched fallback (CSFB) in Release 9, the eNodeB then forwards the system

information of the UMTS cell to the UE in the RRC Connection Release message. Therefore,

the UE does not need to read system information after redirection, which reduces the

redirection delay.

Enhancement

None

Dependency




None


None


The UE must support flash CSFB in Release 9.


None


The mobility management entity (MME) and serving GPRS support node (SGSN) must

support the RIM procedure in 3GPP release 9.

If the core network (CN) is earlier than 3GPP release 9, it must support eNodeB ID

conversion.


None

7.7.5 WRFD-150215 SRVCC from LTE to UMTS with PS Handover

Availability


Summary

This feature is part of the UMTS/LTE interoperability solution. This feature must be

supported by the UEs, radio access network, and core network.

Benefits

This feature supports single radio voice call continuity (SRVCC) from the RAN side.

This feature ensures voice service continuity by allocating VoIP services and PS services (or

default PS bearers) from the LTE network to the UMTS network.

Description

IP Multimedia Subsystem (IMS) is not deployed at the early stage of LTE network

deployment. Therefore, IMS VoIP cannot be used to provide normal voice services and

emergency call services. UEs performing normal voice services and emergency call services

should be handed over to the UMTS network through Circuit Switch FallBack (CSFB) and PS

handover.

After an LTE network is deployed with IMS, the LTE network can support VoIP services.

When a UE performing VoIP services on the LTE network moves out of the LTE coverage, if

there is UMTS coverage, the UE should be handed over to the UMTS network for voice



service continuity. When a UE is performing VoIP services on the LTE network, there must be

at least one PS bearer. The reason is that there must be a default PS bearer for a UE in

connected mode on the LTE network, even if the UE is not performing PS services. When

SRVCC from LTE to UMTS is being performed, the PS bearers will also be handed over to

the UMTS network.

Based on network configuration, the LTE network selects one handover scheme to perform an

LTE-to-UMTS handover. Candidate handover schemes are as follows:

If UMTS supports VoIP, a PS handover is performed on VoIP. This process is an

inter-RAT PS handover, which does not involve the switchover from the PS domain to

the CS domain.

CS-only SRVCC, which is called SRVCC from LTE to UMTS without PS handover.

That is, VoIP services are first handed over to the CS domain of the UMTS network

through the switchover of the core network, while PS bearers are transferred to the

UMTS network through a routing area update (RAU) procedure. From the perspective of

UMTS RAN, the process is only an inter-RAT CS handover.

PS+CS SRVCC, which is called SRVCC from LTE to UMTS with PS handover. That is,

through the switchover of the core network, VoIP and PS services are handed over to the

CS and PS domains of the UMTS network, respectively. From the perspective of UMTS

RAN, the process is an inter-RAT CS+PS handover.

The first two handover schemes have already been supported by Huawei RAN. The last

handover scheme will be implemented by this feature.

Enhancement

None

Dependency


None


None

Dependency on UEs

The UEs must be of 3GPP Release 8 or later and must support SRVCC.


The eRAN must support SRVCC.


The CN must support SRVCC.


None



7.7.6 WRFD-150216 Load Based PS Redirection from UMTS to LTE

Availability


Summary

This feature enables the RNC to redirect a UMTS/LTE dual-mode UE processing only PS

services to the LTE network when the UE is located in the hybrid network coverage of UMTS

and LTE and the serving UMTS cell is in the basic congestion state.

Benefits

This feature reduces the possibility of congestion for a UMTS network by allowing more UEs

in the UMTS network to be redirected to the LTE network. In addition, this feature helps

improve the LTE network resource utilization at the early stage of LTE network deployment.

Description

In the hybrid network coverage of UMTS and LTE, if UEs, the UMTS network, or the LTE

network does not support the UMTS-to-LTE PS handover, operators can use this feature to

redirect UEs to the LTE network where UEs will reestablish their PS services. This feature is

applicable only when the following conditions are met:

The serving UMTS cell meets the conditions for load reshuffling (LDR).

The UE to be redirected supports both UMTS and LTE.

The UE to be redirected processes only PS services, and all the processed PS services

can be established on the LTE network. In the RAB assignment message sent from the

SGSN, there is no indication that the PS services processed by the UE cannot be

established on the LTE network.

Redirection is categorized into blind redirection and measurement-based redirection. If the

UE in connected mode does not support measurements on the neighboring LTE cell and

allows blind redirection to the LTE network, the RRC Connection Release message sent from

the RNC to the UE will include the LTE frequency information, instructing the UE to

implement redirection. If the UE in connected mode supports measurements on the

neighboring LTE cell, the RNC instructs the UE to enter the compressed mode for

measurements and the RRC Connection Release message will include the frequency of the

neighboring LTE cell that was reported by the UE.

Enhancement

None

Dependency


None




None

Dependency on UEs

The UEs must support both UMTS and LTE and support 3GPP Release 8 or later.


None


None


None

7.7.7 WRFD-150217 Load Based PS Handover from UMTS to LTE

Availability


Summary

This feature enables the RNC to hand over a UMTS/LTE dual-mode UE processing only PS

services to the LTE network when the UE is located in the hybrid network coverage of UMTS

and LTE and the serving UMTS cell is in the basic congestion state.

Benefits

This feature reduces the possibility of congestion for a UMTS network by allowing more UEs

in the UMTS network to be handed over to the LTE network. Compared with PS redirection,

PS handover shortens the service interruption duration, improving user experience. In

addition, this feature helps improve the LTE network resource utilization at the early stage of

LTE network deployment.

Description

In the hybrid network coverage of UMTS and LTE, if UEs, the UMTS network, and the LTE

network support the UMTS-to-LTE PS handover, operators can use this feature to hand over

UEs to the LTE network. This feature is applicable only when the following conditions are

met:

The serving UMTS cell meets the conditions for LDR.

The UE to be handed over supports both UMTS and LTE.

The UE to be handed over processes only PS services, and all the processed PS services

can be established on the LTE network. In the RAB assignment message sent from the

SGSN, there is no indication that the PS services processed by the UE cannot be

established on the LTE network.

The neighboring LTE cell meets the conditions for the UMTS-to-LTE handover.



The procedure for the UMTS-to-LTE PS handover is briefed as follows:

1. The RNC sends the SGSN a Relocation Required message, which contains the

information about the target LTE cell.

2. The SGSN forwards the Relocation Required message to the MME.

3. After the LTE network is ready for the inter-RAT handover, the MME instructs the

SGSN to send a Relocation Response message to the RNC.

4. Upon receipt of the Relocation Response message from the SGSN, the RNC instructs the

UE to be handed over to the target eNodeB.

Enhancement

None

Dependency


None


None

Dependency on UEs

The UEs must support:

3GPP Release 8 or later

UMTS-to-LTE PS handover

Measurements on the neighboring LTE cell in connected mode


The eNodeB and MME must support the UMTS-to-LTE PS handover.


The SGSN must support the UMTS-to-LTE PS handover.


None

7.7.8 WRFD-150219 Coverage Based PS Redirection from UMTS to LTE

Availability


Summary

This feature enables the RNC to redirect a UMTS/LTE dual-mode UE processing only PS

services to the LTE network when:



The UE is located in the hybrid network coverage of UMTS and LTE.

The UMTS signal quality received at the UE is poor.

The LTE signal quality received at the UE is good.

When the UMTS signal quality received at the UE is very poor, the RNC can redirect the UE

to the LTE network through blind redirection.

Benefits


This feature provides an alternative to the PS handover. When UEs, the UMTS network,

or the LTE network does not support the UMTS-to-LTE PS handover, this feature

enables PS redirection to the LTE network.

When the UMTS signal quality is poor and the LTE signal quality is good, this feature

allows the UE to be redirected to the LTE network to ensure the continuity of PS

services.

When the UMTS signal quality is very poor, this feature allows blind redirection to the

LTE network, reducing service drops.

During UE redirection to the LTE network, this feature allows the RNC to obtain the

LTE frequency from the system information or from the neighboring LTE cell. If the

RNC obtains the LTE frequency from the system information, operators can eliminate

the workload for configuring the neighboring LTE cell.

Description When the UMTS signal quality is poor and the LTE signal quality is good, the RNC

decides whether to initiate measurements on the neighboring LTE cell and whether to

redirect a UE to the LTE network by considering the UE capabilities and the redirection

switch status. This feature is applicable only when the following conditions are met:

− The UE to be redirected supports both UMTS and LTE and supports measurements

on the neighboring LTE cell.

− The UE to be redirected processes only PS services, and all the processed PS services

can be established on the LTE network.

With this feature, the RNC sends the UE an RRC Connection Release message to

instruct the UE to access the LTE network. This message includes the LTE frequency

information. The RNC obtains the LTE frequency information from the system

information or the neighboring LTE cell, depending on the redirection switch status.

When the UMTS signal quality is very poor, the RNC redirects the UE to the LTE

network through blind redirection without measurements on the neighboring LTE cell.

This feature is applicable only when the following conditions are met:

− The UE to be redirected supports both UMTS and LTE.

− The UE to be redirected processes only PS services, and all the processed PS services


With this feature, the RNC sends the UE an RRC Connection Release message to

instruct the UE to access the LTE network. This message includes the LTE frequency

information. The RNC obtains the LTE frequency information from the system

information or the neighboring LTE cell, depending on the redirection switch status.



Enhancement

None

Dependency


None


None

Dependency on UEs

The UEs must support both UMTS and LTE and support 3GPP Release 8 or later.


None


None


None

7.7.9 WRFD-150220 Coverage Based PS Handover from UMTS to LTE

Availability


Summary

This feature enables the RNC to hand over a UMTS/LTE dual-mode UE processing only PS

services to the LTE network when:

The UE is located in the hybrid network coverage of UMTS and LTE.

The UMTS signal quality received at the UE is poor.

The LTE signal quality received at the UE is good.

Benefits

When the UMTS signal quality is poor and the LTE signal quality is good, this feature allows

the UE to be handed over to the LTE network to ensure the continuity of PS services and

avoid service drops. Compared with PS redirection, PS handover shortens the service

interruption duration, improving user experience.



Description

When the UMTS signal quality is poor and the LTE signal quality is good, the RNC decides

whether to initiate measurements on the neighboring LTE cell and whether to hand over a UE

to the LTE network by considering the UE capabilities and the handover switch status. This

feature is applicable only when the following conditions are met:

The UE to be handed over supports both UMTS and LTE and supports measurements on

the neighboring LTE cell.

The UE to be handed over processes only PS services, and all the processed PS services


The procedure for the UMTS-to-LTE PS handover is briefed as follows:

1. The RNC sends the SGSN a Relocation Required message, which contains the

information about the target LTE cell.

2. The SGSN forwards the Relocation Required message to the MME.

3. After the LTE network is ready for the inter-RAT handover, the MME instructs the

SGSN to send a Relocation Response message to the RNC.

4. Upon receipt of the Relocation Response message from the SGSN, the RNC instructs the

UE to be handed over to the target eNodeB.

Enhancement

None

Dependency


None


None

Dependency on UEs

The UEs must support:

Both UMTS and LTE

3GPP Release 8 or later

UMTS-to-LTE PS handover

Measurements on the neighboring LTE cell in connected mode


The eNodeB and MME must support the UMTS-to-LTE PS handover.


The SGSN must support the UMTS-to-LTE PS handover.


None



7.7.10 WRFD-150231 RIM Based UMTS Target Cell Selection for LTE

Availability


Summary

This feature enables the eNodeB to obtain the load information of the UMTS cells through the

RAN Information Management (RIM) procedure and select the target UMTS cell base on the

cell load during redirection or handover from LTE to UMTS. This can increase the success

rate of redirection and handover from LTE to UMTS and reduce inter-RAT ping-pong

handover.

Benefits

This feature can increase the success rate of redirection and handover from LTE to UMTS and

reduce inter-RAT ping-pong handover.

Description

The redirection or handover from LTE to UMTS, such as CS fallback or LTE to UMTS PS

handover based on load, may fail when the target UMTS cell is congested. This will impact

the success rate of redirection and handover from LTE to UMTS, bring unnecessary signaling

process for handover preparing in eNodeB and delay the handover.

This feature enables the eNodeB to obtain the load information of the UMTS cells through the

RIM procedure. Therefore the eNodeB is able to select the proper target UMTS cell according

to the cell load.

Upon receiving a RIM request for the UMTS cells load information from the eNodeB, the

RNC sends the UMTS cells load information to the eNodeB through the RIM procedure. If

the UMTS cell load changes, the RNC sends the updated cell load information to the LTE

network through the RIM update procedure.

Enhancement

None

Dependency


None


None

Dependency on UEs

None




None


The CN must support the RIM procedure in 3GPP release 9.


None

7.8 UMTS and Wi-Fi Radio Resource Management

7.8.1 WRFD-150229 Intelligent Wi-Fi Detection and Selection

Availability


Summary

This feature uses a UMTS macro network to help the user equipment (UE) detect Wireless

Fidelity (Wi-Fi) hotspots. If the cell load in the macro network reaches a specified threshold

and a nearby Wi-Fi Access Point (AP) is available, this feature redistributes the data flows of

the UE to the Wi-Fi network. This feature must be supported by UEs and the radio access

network.

Benefits


Reduced manual operations due to automatic detection of and access to Wi-Fi hotspots

Reduced power consumption for UEs and improved user experience with Wi-Fi

Increased usage of Wi-Fi hotspots due to cooperation between the macro and Wi-Fi

networks

Maximized resource usage due to convergence of the macro and Wi-Fi networks

Description

Existing Wi-Fi networks are not fully utilized, probably because subscribers do not always

know the location of Wi-Fi hotspots and therefore do not always open the Wi-Fi function to

reduce the power consumption of UEs. To address this issue, this feature helps UEs detect

Wi-Fi hotspots and enables UEs to access Wi-Fi hotspots.

This feature has the following functions:

Intelligent detection and selection of Wi-Fi hotspots

When a UE initiates a data service, if the cell load reaches a specified threshold and a

nearby Wi-Fi AP is available, the network informs the UE of the detected hotspots and

instructs the UE to switch its data service to the Wi-Fi network.



Access to the Wi-Fi network

After a UE receives a message indicating a detected Wi-Fi hotspot, it can switch its data

service to the Wi-Fi network.

Interface between macro and micro cells

An interface connects the RNC and the Wi-Fi Access Controller (AC). This interface

transmits Wi-Fi AP availability information, based on which the RNC determines

whether to switch UEs to the Wi-Fi network.

Enhancement

None

Dependency


The BSC6900 must be configured with SPUb boards.

The BSC6910 must be configured with EGPUa boards.


None

Dependency on UEs

The required application software must be installed on the UEs.


None


None


None

7.9 QoS

7.9.1 WRFD-010505 Queuing and Pre-Emption

Availability



Summary

This feature enables service differentiation when the network is congested to provide better

services for high-priority users.



Benefits

This feature provides operators with a method to differentiate users according to their priority.

High priority users can obtain the system resources with high priority in case of resource

limitation. In this way, operators can provide better service to those high priority users.

Description

Queuing and Pre-emption are two functions related to access control and are methods for

differentiating services. It enables operators to provide different services by setting different

priorities, which will affect the user call setup success rate during the call setup procedure. If

there are not enough resources and a new call is not admitted to access to the network, high

priority user will have more chances to access to the network than low priority users by

queuing or pre-empting other low priority users.

The priority information is obtained from the RAB parameters including TC (Traffic Class),

ARP (Allocation / Retention Priority), and THP (Traffic Handling Priority for interactive

service), in the message of RAB ASSIGNMENT REQUEST. The RNC will assign the user

priority according to TC, ARP, as well as THP.

Pre-emption will take action if admitting a call fails due to lack of resource. The service with

the attribution of Pre-emption Capability and Pre-emption Vulnerability indicates the service

ability of pre-empt and pre-emption vulnerability. The pre-emption capability indicates the

pre-emption capability of the request on other RAB, and pre-emption vulnerability indicates

the vulnerability of the RAB to pre-emption of other RAB.

If a new call pre-emption does not take effect due to some reasons such as no service can be

pre-empted or current call has no ability of pre-empting other calls, the call will perform

queuing function if queuing ability is allowed.

To support the call queuing function, there’s an establishment queue (actually a buffer) per

cell for RNC to keep the RABs when a call queuing is triggered. A configurable timer is used

to indicate how long the associated RAB can be queued and the maximum waiting length is

configured according to the Priority Levels. Resource re-allocation for the RABs in the queue

is done periodically.

If a queued RAB failed due to expiry of the maximum waiting length, it will be removed from

the queue, and the RNC will report in a subsequent RAB ASSIGNMENT RESPONSE

message indicating that the RAB failed to setup or modify with IE Cause "queuing Expiry".

Queuing and pre-emption can be applied into following procedures:

New RAB request

Existing RAB modification request

Partial RAB assignment failure request

SRNS relocation request

The users can also be divided to Golden/Silver/Copper level which is mapped from ARP, and

the mapping relationship is configurable. And the Gold user is not allowed to be pre-empted.

Enhancement

In RAN5.0, only ARP is considered for candidate calls to be pre-empted. The functionalities

of pre-emption and queuing are applied for R99 and HSDPA, but DCH service can only



pre-empt other DCH services with low priority and HSDPA can only pre-empt other HSDPA

services with low priority.

In RAN5.1, the priority is enhanced by introducing RAB integrate priority (TC top-priority or

ARP top-priority), user integrate priority and user priority (Gold, Silver and Copper)

considering Traffic Class (TC) and Carrier Type as parameters when selecting candidate call

to be pre-empted.

In RAN6.0, THP is considered for interactive service if TC and ARP have the same priority.

In addition, the functionalities of pre-emption and queuing are also applied for HSUPA, but

HSUPA can only pre-empt other HSUPA services with low priority.

In RAN10.0, there is an enhancement which ARP should be considered in the case of

different TC. This improvement is only applied for Streaming and I/B traffic class. That is, the

ARP of user to be pre-empted should be lower than or equal to that of a new request user in

the case of different traffic classes. For example, streaming service can preempt I/B with

equal or lower ARP.

In RAN10.0, pre-emption can take place between HSDPA and DCH services due to limitation

of power and Iub transmission resources. ARP, TC and THP are also used for pre-emption.

For example, Gold R99 user will be able to preempt a silver HSPA user, and a Gold HSPA

user will be able to preempt Silver R99 user.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

This feature need the CN bring the ARP IE to RNC during RAB assignment procedure so that

RNC can get the service priority with those RAB parameters.


This feature requires optional feature WRFD-010610 HSDPA Introduction Package and

WRFD-010612 HSUPA Introduction Package when HSDPA / HSUPA queuing and

Pre-emption are required.





7.9.2 WRFD-021103 Access Class Restriction

Availability



Summary

When the RNC’s Signaling Processing Unit(SPU) is overloaded as while as too many UEs

initiate random access, this feature allows operator to control the access priority according to

UEs’ Access Class (AC) via broadcasting System Information Block 3 (SIB3).

Benefits

The benefit of this feature is to decrease the signaling processing load of SPU in certain level

via controlling the UEs’ access sequence, as well as to increase the UEs’ access rate.

Description

The PRACH resources (that is, access slots and preamble signatures for FDD), timeslot (with

specific frame allocation and channelization code for 3.84 Mcps TDD and SYNC_UL codes

(with specific frame allocation) for 1.28 Mcps TDD) may be divided between different Access

Service Classes in order to provide different priorities of RACH usage.

Access Service Classes shall be numbered in the range 0 i NumASC 7. The ASC 0 has

the highest priority, and the ASC 7 has the lowest priority. The ASC 0 shall be used in case of

Emergency Call or for reasons with equivalent priority.

A mapping between Access Class (AC) and Access Service Class (ASC) shall be indicated by

the information element "AC-to-ASC mapping" in SIB 5 or SIB 5bis. Access Classes shall

only be applied at initial access, that is, when an RRC CONNECTION REQUEST message is

sent.

In SIB 3/4, IE "Access Class Barred list "is used to indicate which access class is barred or

allowed. UE reads its access class stored in SIM and compares it with that in SIB 3/4. And

then UE will know whether it can access into this cell.

Access Class Restriction information will be updated in the following scenarios:

When the cell is in signaling overload, "Access Class Barred list" will be updated

automatically and some access classes are barred to prevent too many users accessing

into the cell; when cell signaling load becomes low, more access classes will be

unbarred.

Enhancement

None



Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


None



7.9.3 WRFD-050424 Traffic Priority Mapping onto Transmission Resources

Availability


Summary

This feature enables the dynamical mapping of the services onto the transport bearers

according to the TC, ARP, and THP of the user. The operator can flexibly configure the

mapping to fulfill differentiated services while guaranteeing the QoS.

Benefits

This feature implements the mapping from traffic priorities to transmission resources and

provides flexible configuration means for differentiated services and for guarantee of QoS.

Description

This feature dynamically maps the services onto the transport bearers, according to the TC

(Traffic Class), ARP (Allocation/Retention Priority), and THP (Traffic Handling Priority for

interactive service) of the user. The operator can flexibly configure the mapping of service

types onto transmission resources. According to different combinations of TC+ARP+THP, the

operator can choose the transmission resources with different QoS requirements to fulfill

differentiated services while guaranteeing the QoS.



TC\ARP Gold Silver Bronze

R99 conversational R99 C

R99 streaming R99 S1 R99 S2 R99 S3

R99 interactive THP

High

THP

Middle

THP

Low

THP

High

THP

Middle

THP

Low

THP

High

THP

Middle

THP

Low

R99

I11

R99 I12 R99

I13

R99

I21

R99 I22 R99

I23

R99

I31

R99 I32 R99

I33

R99 background R99 B1 R99 B2 R99 B3

HSPA

conversational

HS C

HSPA streaming HS S1 HS S2 HS S3

HSPA interactive THP

High

THP

Middle

THP

Low

THP

High

THP

Middle

THP

Low

THP

High

THP

Middle

THP

Low

HS I11 HS I12 HS

I13

HS I21 HS I22 HS

I23

HS I31 HS I32 HS

I33

HSPA background HS B1 HS B2 HS B3

ATM transport

In ATM transport, the service data with different priorities is mapped to different ATM

service types. The practical mapping can be flexibly configured.

IP transport

In IP transport, the service data with different priorities is mapped to the IP data stream

with different PHB attributes. The practical mapping can be flexibly configured.





The mapping between service bearer and transmission resource also support the primary and

secondary path configuration. In the admission of transmission resource, the primary path is

considered for the service setup firstly, and secondary path will be selected in case of the lack

of primary path bandwidth or failure of the primary path, with this feature, both transmission

reliability and transport efficiency can be improved.

In RAN11.0, the load balancing algorithm is introduced for the path selection to prevent the

uneven load distribution on the primary and secondary path which may lead to the decrease of

transport efficiency. That is, when the load of primary path is too high and the difference with

the secondary path is higher than a configurable threshold, the secondary path will be

selected.

Enhancement

In RAN11.0, the mapping from AAL2 path types to ATM service types is removed, which

makes the priority mapping of ATM services more flexible.

In RAN11.0, the mapping from IP path types to PHBs is removed, which makes the priority

mapping of IP services more flexible.

In RAN11.0, the load balancing algorithm is introduced for the transmission path selection to

enhance transmission efficiency improvement.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


None





7.9.4 WRFD-020806 Differentiated Service Based on SPI Weight

Availability


Summary

HSPA users share Uu interface resources, CE resources, and Iub interface resources. If these

resources cannot provide the maximum bit rate (MBR) for all online HSPA users,

differentiated resource allocation can be performed on users according to user priority or

service type (interactive or background). The differentiation in resource allocation is

controlled by SPI weight.

Benefits

With the development of the HSPA technology, HSPA channels have become the main radio

bearer of UMTS services. This feature is mainly applicable to HSPA channels. It provides

users with differentiated services according to user priority or service type, so that the service

quality of high-priority users is preferentially ensured and high-priority services are

preferentially processed when resources are insufficient. In addition, while meeting the

requirement of GBR, the ratio of the user throughput will try to reach the ratio of SPI weight.

There are three user priorities: gold, silver, and copper. If gold, silver, and copper users are in

the same radio environment, the ratio of user throughput of these users is equivalent to the

ratio of SPI weights of the users. Here is an example:

The ratio of SPI weights of gold, silver, and copper users is 9:3:1.

Services are processed in a cell whose total available bandwidth is 3 Mbit/s.

The cell has a total number of 10 users, and all the users have a large amount of data to

transmit but resources are insufficient.

The mean user throughput of gold, silver, and copper users is 1.1 Mbit/s, 380 kbit/s, and

120 kbit/s, which is equivalent to 9:3:1.

The following table shows the details:

User Priority Gold Silver Copper

Mean Cell Throughput

3 Mbit/s

Number of Online Users

1 3 6

Mean User Throughput

1.1 Mbit/s 380 kbit/s 120 kbit/s

This feature supports differentiated tariff policies, for example, high-tariff users are provided

with better services. It also supports differentiated service quality according to service type

(interactive or background), for example, background services are provided with low service

quality if network bandwidth is insufficient.



Description

HSPA users share Uu interface resources, CE resources, and Iub interface resources, which

are allocated according to their respective resource scheduling algorithms. If this feature is not

enabled, the resource scheduling algorithms mainly ensure the fairness between BE services

(interactive and background services). That is, the resource scheduling algorithms fairly

allocate resources between users based on the guaranteed bit rate (GBR) and maximum bit

rate (MBR) required.

After this feature is enabled, SPI weights can be set for user priorities (gold, silver, and

copper). Resources are allocated according to the set SPI weights. The quality of services with

high SPI weight is preferentially ensured. For example, if Uu interface resources are

insufficient, higher data rate or shorter transmission delay is achieved preferentially for

services with high SPI weight.

Enhancement

In RAN13, except user priority (golden, silver, bronze), SPI Weight can be configured

according to UE category or user subscribed MBR. In this way, the operator can adopt more

flexible promotion strategy to increase the revenue.

Dependency


None


None


When applied in the downlink on the Uu interface, this feature depends on the feature

WRFD-01061103 Scheduling based on EPF and GBR.

When applied in the uplink on the Uu interface, this feature depends on the feature

WRFD-01061402 Enhanced Fast UL Scheduling or WRFD-010638 Dynamic CE

Resource Management. When this feature is enabled together with the feature

WRFD-01061402 Enhanced Fast UL Scheduling, only the uplink Uu interface resources

can be differentially scheduled. When this feature is enabled together with the feature

WRFD-010638 Dynamic CE Resource Management, both the uplink Uu interface

resources and CE resources can be differentially scheduled.

When applied in the downlink on the Iub interface, this feature depends on the features

WRFD-010610 HSDPA Introduction Package and WRFD-050405 Overbooking on ATM

Transmission, or depends on the features WRFD-010610 HSDPA Introduction Package

and WRFD-050408 Overbooking on IP Transmission.

When applied in the uplink on the Iub interface, this feature depends on the feature

WRFD-01061212 HSUPA Iub Flow Control in Case of Iub Congestion.


None





7.9.5 WRFD-020131 Optimization of R99 and HSUPA Users Fairness

Availability


Summary

In scenarios where R99 users and HSUPA users share the same carrier, this feature enables

telecom operators to provide service for R99 and HSUPA users in a fair way and improve the

experience of HSUPA users. This is achieved by considering the satisfaction rate (real-time

user rate/GBR) of both types of user.

Benefits

This feature helps improve the fairness of resource allocation between HSUPA and R99 users

and raise the satisfaction of HSUPA users.

Description

With the increase of the commercial use of HSUPA, the HSUPA user experience has become

more and more important. As a result, the original policy based on which R99 users take

precedence over other users does not follow this trend. In scenarios where R99 users and

HSUPA users share the same carrier, the throughput of R99 users might be higher than that of

HSUPA users at the same priority level.

This feature enables the periodic comparison of satisfaction between R99 and HSUPA users.

The comparison considers the ratio of actual service rates of users to the Guaranteed Bit Rate

(GBR) values. If the satisfaction degree of R99 users is higher than that of HSUPA users and

reaches a certain preset threshold, the rate decrease of high-rate R99 BE services is triggered

and the rate increase of low-rate R99 BE services is limited.

Enhancement

None

Dependency


None


The BTS3812E and BTS3812AE must be configured with the EBBI, EDLP board. The

HBBI and HDLP cannot support this feature.

The DBS3800 must be configured with the EBBC or EBBCd board. The BBU3806

cannot support this feature.






WRFD-010612 HSUPA introduction package

WRFD-021101 Dynamic Channel Configuration Control (DCCC)


None



7.9.6 WRFD-011502 Active Queue Management (AQM)

Availability


Summary

This feature provides approach of queue management and shorten the period of HTTP

queuing.

Benefits

AQM can improve user experience when HTTP and download services simultaneously exist.

Description

This feature is valid for R99 packet connections for up to 384 kbit/s packet data.

In an interactive packet-data connection, the packet data to transfer is typically characterized

by large variations, so the buffer is introduced to even out the variations. However, if the

buffer is filled up or an overflow situation takes place, it will result in loss of data packets.

Currently, TCP as the main transport layer protocol is used on Internet. Packet loss is regarded

as link congestion by TCP, and TCP will correspondingly reduce the data transmission rate.

TCP protocol is also sensitive to round trip delays and it will take actions differently in case

just one packet is missing or if a burst of packets is lost. In case of uncontrolled packet losses,

it may take a considerable time for the data rate to increase again, leading to poor radio link

utilization and causing long delays for the end user.

In addition, in case a user is performing parallel activities, for example, FTP download and

web browsing, if the file download would fill the buffers and thereby cause a long delay

before anything would happen when clicking on a link.

The functionality of AQM is provided as an optimized buffer handling method, in order to

interact with the TCP protocol in a favorable manner and reduce the buffering delay. It is

possible for the operator to switch on/off the Active Queue Management function



Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

None


None

7.9.7 WRFD-020128 Quality Improvement for Subscribed Service

Availability


Summary

To provide better services to customers and to enhance the competitiveness, some service

providers are ready to pay extra to network operators to sign a contract for obtaining better

transmission quality for specific services. These service providers are called subscribed

customers and the specific services are called subscribed services.

IP transmission is used widely. In IP transmission, the service data is transmitted in IP packets,

and the IP header contains the information that indicates the source IP address, destination IP

address, source port number, and destination port number. So the data source can be identified

through IP header analyzing. Based on this technique, the network operator can identify the

data of subscribed services and ensure that the subscribed services have better quality such as

higher throughput or shorter delay. In this way, customers can have better experience for

subscribed services than for ordinary services.

Benefits

With this feature, end users can have better experience for subscribed services and the status

of the subscribed service provider is elevated. In this way, the competitiveness of the

subscribed service provider is enhanced. Moreover, the network operator can get extra income

from the subscribed service provider.



Description

If IP transmission is used at the network layer, the IP header contains the information that

indicates the source of the service data. So the operator can identify whether the data is of the

subscribed services by checking the IP address and port number in the IP header. For the data

of subscribed services, if the data is carried over HSPA channels, the operator enhances the

capability of the service to obtain Iub interface resources, Uu interface resources, and CE

resources. In this way, the throughput of the service on the radio access network is enhanced,

the data transmission delay is reduced, and the user experience is enhanced.

The effect of this feature is more obvious when the traffic load over the access network is

high.

Enhancement

None

Dependency

Dependency on RNC

None

Dependency on NodeB

The BTS3812E and BTS3812AE must be configured with the EBBI, EBOI, EULP or

EULPd board.



Dependency on UE

None


None

Dependency on CN

None





7.9.8 WRFD-020123 TCP Accelerator

Availability




Summary

A series of enhanced TCP functions adaptive to the link characteristics on the RAN side are

implemented on the RNC. This feature enables the performance of the TCP protocol derived

from the wired network to be greatly improved in the wireless network, improving user

experience and system efficiency.

Benefits

This feature mitigates the impact of some factors such as packet loss on the RAN to affect

negatively the performance of TCP data transmission, accelerates the slow startup and fast

retransmission of the server during the data transmission, increases the UL/DL data

transmission efficiency, and reduces the UL/DL transmission delay, greatly improving the PS

data transmission performance.

For example: (1) The time to download a small size file of 500kbyte can be decreased by 20%.

(2) When a user downloads and uploads large size files with the bandwidth of 2 Mbit/s and

one TCP connection at the same time, the downlink rate can be increased by 50%.

Description

The TCP/IP protocol is extensively used all over the world. It was initially developed for

wired transmission and later also used in wireless networks. However wireless networks

exhibit some characteristics quite different from the wired network. A typical example is that

of packet losses which, in a wired network, is commonly due to congestion in some network

elements, whereas in a wireless network such losses can be due to transmission errors over the

air interface. This has a significant impact on the overall performance of the data transmission,

due to the way the TCP/IP protocols reacts to such packet losses. To mitigate this effect, a

number of enhancements have been implemented in the RNC

A TCP accelerator functionality is implemented in the RNC. The TCP Proxy Entity (TPE for

short) is used to improve the data transmission performance in the wireless network. The TPE

processes the TCP/IP packets by adopting TCP performance optimization technologies such

buffering and sorting of DL data, ACK splitting, DupACK duplication, local retransmission,

building Window Scaling (WS) indication, and enhanced simultaneous DL/UL data

transmission. In addition, the buffering and sorting of UL data is adopted to prevent factors,

such as packet loss and transmission delay in the RAN, from affecting the UL TCP data

transmission. This feature also accelerates the slow startup and congestion prevention of the

server during the UL data transmission, increases the UL data transmission efficiency, reduces

the UL transmission delay, and improves the DL throughput in the case of simultaneous

uploading and downloading. Therefore, this feature greatly improves the PS data transmission

performance.

ACK splitting

In TCP, the congestion window is updated according to the number of received ACK

messages and is expanded by increasing the number of ACK messages. When a slow

startup occurs at the transmitting end, ACK splitting can quickly recover the congestion

window; when the transmitting end works in congestion avoidance mode, ACK splitting

can accelerate the expansion of the congestion window.

DupACK duplication

In TCP, a lost TCP packet is retransmitted after three DupACK are received. With this

feature, after the TPE receives the ACK message from the UE, the TPE immediately

duplicates three DupACK messages and sends them to the Server if it detects that the



packets requested by the ACK are not in the buffer. This shortens the time for packet

retransmission.

Local retransmission

When packet loss occurs on the air interface, the TPE, rather than the transmitting end,

retransmits the packet to the receiving end, reducing the time for retransmission.

Packet sorting

Sorting of the disordered DL packets is as follows. The TPE sorts and transmits the

disordered DL packets to avoid unnecessary transmission of DupACKs in the uplink and

to prevent TPE local retransmission caused by disordered packets. In this way,

transmission resources are saved.

Sorting of the disordered UL packets is as follows. The TPE sorts the UL packets and

transmits them to the core network (CN) in sequence. This avoids the deterioration of the

UL data transmission performance caused by the disordered UL packets.

Building WS indication

When TCP window size in server side is 64KB, the synchronization packet will not

include WS indication. If the receiving side detects that there is no WS indication, the

synchronization ACK packet returned by receiving side will not include WS indication.

In this case, even if the capability of the receiving end is greater than 64KB, the window

size is limited to 64KB. Therefore, the throughput is decreased if the actual receiving

capability exceeds 64KB.

Enhanced simultaneous downlink and uplink transmission

If data are transmitted in the uplink and downlink simultaneously, UE needs to send data

and TCP ACK/NACK information corresponding to downlink data. However, TCP

ACK/NACK information may be blocked on the UE side by uplink data packet.

Therefore, the TCP ACK information of downlink data is delayed, which may affect the

downlink throughput. This feature can monitor the TCP packet reception in UE. If a TCP

packet is received by UE correctly, TPE builds ACK information and sends it to the

server. Then, the server TCP TX window can slide more quickly and the downlink

throughput will be increased.

Enhancement

The enhanced UL data transmission is introduced in RAN12.0.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN



None


None

7.9.9 WRFD-010507 Rate Negotiation at Admission Control

Availability



Summary

This feature enables QoS negotiation and RAB downsizing on the Iu interface.

Benefits

Based on the QoS negotiation mechanism, this feature can enhance the RAB setup process

and shorten the service setup time.

This feature can greatly increase the success rate of call setup and hard handover and

maximize resource usage and system capacity.

Description

This feature makes it possible for a call to access the network with a lower bit rate in case that

cell resource is not enough, and it comprises the following two parts

Iu QoS negotiation

RAB Downsizing

The access success rate, system capacity, and performance can be improved with this feature.

I. Iu QoS negotiation

In Release 99, the UTRAN accepts or rejects a radio access bearer request only from the CN.

If the QoS requirement of the service defined in the RAN establishment request is higher than

that can be handled by UTRAN, the UTRAN cannot accept it. For the services having higher

QoS requirement could accept lower QoS requirements than those requested by the CN in the

RAB establishment request. There are no means for the UTRAN to propose an alternative

(lower) QoS.

For such services, the RAB establishment will fail, or alternatively the CN could re-attempt

the RAB re-establishment with lower QoS requirements. This would significantly increase the

setup time. Therefore, a QoS negotiation mechanism is introduced in Release 4. This aligns

the procedure with the already existing CN solution used in GPRS and shortens the service

setup time. Such a mechanism also applies to the relocation procedure by adding Alternative

RAB Parameter Values IE in the RANAP RAB ASSIGNMENT REQUEST or

RELOCATION REQUEST message.

The Iu QoS negotiation mainly aims for the PS streaming service and is used to negotiate the

maximum and initial bit rate for the service.



Maximum bit rate negotiation

The UE capability will be considered to decide the maximum bit rate. That is, the

maximum bit rate will be selected among the maximum bit rate assigned and the

alternative ones in descending order until it meets the UE capability. If the HSPA is

related, the UE capability with HSPA will be used.

Initial bit rate negotiation

To decide the initial bit rate, the following load information should be considered:

− Uplink and downlink radio load states of the cell

− Iub resource state

− Minimum spreading factor supported

− HSPA capability. If a service is related to HSPA, the UE capability must be

considered to get a proper bit rate.

When the cell with radio load or Iub resource load is congested, the minimum bit rate among

the assigned Guaranteed Bit Rate (GBR) will be selected for service admission. Otherwise,

the bit rate among negotiated maximum bit rate and guaranteed bit rate will be selected in

descending order until it meets the load and capability requirements mentioned above.

After the maximum and initial bit rates are made certain and the subsequent admission

procedure is successful, the RNC will inform the CN node of the negotiated bit rate through

RAB ASSIGNMENT REPONSE or RELOCATION REQUEST ACKNOWLEDGE message.

II. RAB downsizing

The RAB downsizing applies mainly to Best Effort (BE) service (interactive or background

service). In an ideal scenario, BE service can always access the network with the maximum

request bit rate if there is enough cell resources, but such a process cannot meet the system

capacity and performance requirements while the system resource is limited. Therefore, the

RNC will try to negotiate the proper maximum and initial bit rate as Iu QoS negotiation does.

Maximum bit rate negotiation

The UE capability will be considered to decide the maximum bit rate. That is, the

maximum bit rate will be selected among the maximum bit rate assigned to 8 kbit/s in

descending order until it meets the UE capability. If the HDPA is related, UE capability

with HSPA will be used.

Initial or target bit rate negotiation

The following load information will be considered to decide the initial bit rate:

− Uplink and downlink radio load states of the cell

− Available Iub resource

− Minimum spreading factor supported

− Available credit resource

− HSPA capability, if the service related to HSPA, the UE-related capability must be

considered to get a proper bit rate.

When radio load is congested, GBR will be selected to admit to maximize the access

successful rate. Otherwise, the bit rate among negotiated maximum bit rate to 8 kbit/s will be

selected in descending order until it meets the load and capability requirements mentioned

above.



RAB downsizing can also be applied in the hard handover procedure. That is, with this feature,

during the hard handover procedure, the target cell load will be considered, the downgraded

hard handover may be triggered to maximize the handover successful rate.

Enhancement

In RAN5.0, Iu QoS negotiation feature is introduced.

In RAN5.0, RAB downsizing used in the hard handover procedure is supported.

In RAN5.1, HSPA capability is taken into consideration, and in RAN6.0 the HSUPA feature is

introduced.

In RAN10.0, RAB downsizing can also be applied when the request for adding new radio

links in the AS in soft/softer handover is rejected by admission control due to resource

limitation. The rate will be downgraded according to the cell load information, in order to

avoid the call drop due to soft handover failure.

In RAN11.0, the newly added policy is that the access of the PS service, if denied, allows an

access rate of 0 kbit/s or the implementation on the FACH.

RAN11.0 decides the downlink initial access rate of the R99 BE service on the DCH

according to the Ec/Io contained in the RRC CONNECTION REQUEST message. If the

Ec/Io is higher than the related threshold, the downlink initial access rate is min[384k, MBR]

(where MBR is the maximum bit rate assigned by the CN); if the Ec/Io is lower than the

threshold, the downlink initial access rate is the default value.

Dependency

Dependency on RNC

None

Dependency on NodeB

None

Dependency on UE

None


None

Dependency on CN

For Iu QoS negotiation, the CN node needs to support this feature, but for RAB downsizing,

the CN node does not need to support this feature.


None



7.9.10 WRFD-020130 Videophone Service Restriction

Availability


Summary

This feature disables the videophone (VP) function of a cell through cell-level configurations.

Benefits

This feature meets telecom operators' requirements for information security in restricted areas.

It prevents leakage of information through VP.

Description

In restricted areas such as military management areas and key laboratories, the use of VP may

lead to leakage of information. To meet the security requirements in these areas, the RNC

supports the prohibition of VP services at the cell level. Through configurations on the Local

Maintenance Terminal (LMT), the VP services of all UEs in a cell can be prohibited.

The implementation of this feature involves the following aspects:

Prohibiting VP service setup during service establishment

Releasing VP services in the case of an incoming handover, for example, retaining other

services except VP services when the UE has multiple concurrent services to process

Enhancement

None

Dependency


None


None


None


None





7.9.11 WRFD-020135 Intelligent Inter-Carrier UE Layered Management

Availability


Summary

This feature allows the RAN to intelligently distinguish between UEs and data cards in

multi-carrier scenarios and to separately set up services on different carriers.

Benefits

With the rapid growth of mobile broadband, use of data cards to access the Internet has

become a common occurrence. Data card traffic is characterized by its long duration and high

volume. It increases operator profit but also increases network load. Other services of the

same carrier may be negatively affected.

Use of separate carriers for data card services allows full utilization of carrier resources and

keeps data card traffic from affecting other services. This helps operators formulate flexible

billing policies, develop large-scale data card services, and establish Mobile Broadband

(MBB) brands.

Description

This feature allows the RAN to intelligently distinguish between UEs and data cards in

multi-carrier scenarios and to separately establish services on different carriers based on

priority configuration. This feature is applicable to UEs during the access procedure and in

connected mode.

This feature requires operators to separately allocate IMSI ranges to UEs and data cards. The

RNC determines the terminal type based on the IMSI of the terminal and configured rules.

Each carrier is assigned a priority corresponding to a terminal type. During the RAB setup,

the cell with the highest priority for the terminal type is chosen for access. This achieves the

layered assignment of terminals to specific carriers. After a service is established, periodic

directed retry based on the terminal type can be performed for handover to the highest-priority

carrier.



Enhancement

None

Dependency

This feature requires operators to separately allocate IMSI ranges to UEs and data cards.

Dependency on the RNC hardware

None

Dependency on the NodeB hardware

None





7.9.12 WRFD-150204 Platinum User Prioritizing

Availability


Summary

This feature improves user experience for platinum users by:

Allocating a high admission priority to them when network congestion occurs

Allocating the highest High Speed Packet Access (HSPA) service scheduling priority to

them

Enhancing voice quality for them when downlink coverage is weak

Benefits

This feature provides the following benefits for platinum users:

Increased access success rate and HSPA throughput

Improved voice quality

Description

If network congestion occurs during gatherings, sports events, and festivals, it is difficult for

platinum users (for example, policemen and firefighters) to access the network.

With this feature, the RNC preferentially allows platinum users to access the network during

radio resource control (RRC) connection setup or radio access bearer (RAB) setup. A list of

platinum users is saved on the RNC and the list is configurable.



Circuit switched (CS) services initiated by platinum users have the highest admission priority,

and packet switched (PS) services initiated by common users have the lowest admission

priority. The admission priority of PS services initiated by platinum users and the admission

priority of CS services initiated by common users are configurable.

When downlink coverage is weak, this feature improves voice quality for platinum users.

Additionally, this feature enables the RNC to allocate the highest HSPA service scheduling

priority to platinum users, increasing their HSPA throughput.

Enhancement

None

Dependency


None


None

Dependency on UEs

None


None


None


None



8 O&M Experience

8.1 Advanced Planning

8.1.1 WRFD-140219 Micro NodeB Self-Planning

Availability


Summary

This feature automatically plans the following information for micro NodeBs:

Available UTRA Absolute Radio Frequency Channel Numbers (UARFCNs)

Scrambling codes

Intra-frequency neighboring cells

Inter-frequency neighboring cells

Inter-RAT neighboring cells between UMTS and GSM,

LAC/SAC/RAC parameters

Benefits

With this feature, the system automatically scans the radio environment around a micro

NodeB and sets the radio parameters such as UARFCNs and scrambling codes. This feature

simplifies micro NodeB network planning while also making it more efficient and reducing

the cost.

Description

Network planning is mandatory for WCDMA network deployment. WCDMA network

planning, including site survey and network dimensioning, is generally performed manually,

which results in a high cost and a lengthy deployment schedule.

To improve network planning efficiency and meet the customers' requirements of automatic

micro NodeB deployment, this feature automatically determines available UARFCNs,

scrambling codes, intra-frequency neighboring cells, inter-frequency neighboring cells,



inter-RAT neighboring cells between UMTS and GSM, and LAC/SAC/RAC parameters for

micro NodeBs. With this feature, the system automatically performs the following functions:

Scans the radio environment around a micro NodeB to collect raw data.

Sets radio parameters by using radio parameter planning algorithms.

Configures radio parameters on network elements (NEs) through the operation and

maintenance (O&M) channel.

Enhancement

In RAN15.0, the following functions are added:

Self-planning for micro NodeBs in dual-carrier scenarios

Automatic planning of camping, mobility, and load control parameters based on the

operators' networking policy

Automatic planning of inter-RAT neighboring cells between UMTS and LTE and of URA

parameters

Dependency


The RNC version must be RAN13.0 or later, and the RNC data can be configured and

modified on the M2000.


Only the BTS3902E supports this feature.

The BTS3902E must be configured with a self-organizing network (SON) receiver and a SON

receiver antenna.


None


The NodeB auto deployment function is enabled on the M2000 side.

The M2000 must support BTS3902E WCDMA self-planning.

The GBSC version must be GBSS 14.0 or later to support remote configuration by the

M2000.

The eNodeB must support the modification of the inter-RAT neighbor relationship

between LTE and UMTS on the M2000.


None


WRFD-031101 NodeB Self-Discovery Based on IP Route

WRFD-031102 NodeB Remote Self-configuration





9 Site Solution

9.1 Supporting

9.1.1 WRFD-140220 Intelligent Battery Management

Availability


Summary

With this feature,

The battery management mode automatically changes depending on the selected grid

type, which prolongs the battery lifespan.

The battery self-protection function is triggered under high temperature, which prevents

battery overuse and damage.

The runtime of batteries is displayed if the mains supply is cut off. Users can then take

measures to prevent service interruption.

Benefits


Prolonged battery lifespan

Less energy consumption

Reduced operation costs

Improved system stability

Description Automatic change of the battery management mode

The PMU board records the number of times the power supply is cut and the duration of each

instance. Then, the PMU board determines the grid type and correspondingly activates the

appropriate power management mode. If the grid type is 1 or 2, batteries can enter the

hibernation state, in which batteries do not charge or discharge, which helps prolong battery

lifespan.



Number of Hours Without External Power in a 15-Day Period

Grid Type

Charge and Discharge Mode

Current Limitation Valve

Hibernation

Voltage (V) Hibernation

Duration

(Days)

Estimated Battery Lifespan Improvement Rate

≤ 5 1 Mode A 0.10 C 52 13 100%

5-30 2 Mode B 0.15 C 52 6 50%

30-120 3 Mode C 0.15 C N/A N/A 0%

≥ 120 4 Mode C N/A N/A

The automatic change function of the battery management mode is under license control. This

function is disabled by default and users can enable it by running an MML command.

Self-protection under high temperature

If the battery temperature exceeds the threshold for entering the floating charge state for 5

minutes, the batteries enter this state and no alarms are generated.

If the battery temperature exceeds the threshold for triggering the self-protection function for

5 minutes, the batteries are automatically powered off or the battery voltage is automatically

adjusted.

Battery runtime display

If the mains supply is cut off, the base station calculates the battery runtime based on such

information as the remaining power capacity and discharge current. Users can query the

runtime by running an MML command.

The NodeB calculates the runtime of batteries with the following formula:

Runtime of batteries = (Remaining power capacity x Total power capacity x Discharge

efficiency)/(Mean discharge current x Aging coefficient)

Enhancement

None

Dependency


None


The APM30H (Ver. C), BTS3900AL, TP48600A, and batteries must be configured.


None




None


None



10 Acronyms and Abbreviations

3G The Third Generation

AP Access Point

APM Advanced Power Module

AQM Active Queue Management

BBU Baseband Unit

BITS Building Integrated Timing Supply System

BTS Base Station

CBS Cell Broadcast Service

CPC Continuous Packet Connectivity

CPE Customer Premises Equipment

DNBS Distributed NodeB System

DSAC Domain Specific Access Control

ETSI European Telecommunications Standards Institute

FTP File Transfer Protocol

GIS Geographical Information System

GA General Available

GBR Guaranteed Bit Rate

GLONASS GLObal Navigation Satellite System

GPS Global Position System

HCS hierarchical Cell Structure

HSDPA High Speed Downlink Packet Access

HSUPA High Speed Uplink Packet Access

LCS Location Service



LTE Long Term Evolution

MBMS Multimedia Broadcast Multicast Service

MIMO Multi-Input Multi-Output

NACC Network Assisted Cell Change

PA Power Amplifier

PARC Platform Advanced Radio Control

PPS Pulse Per Second

QAM Quadrature Amplitude Modulation

RAN Radio Access Network

RET Remote Electrical Antenna

RNC Radio Network Controller

ROHC Robust Header Compression

RRM Radio Resource Management

SAE System Architecture Evolution

SASA Same Band Antenna Sharing Adapter

SASU Same Band Antenna Sharing Unit

SNone Shared Network Area

TGW Transmission Gateway

VoIP Voice over IP

WCDMA Wideband Code Division Multiple Access

Documents

RAN15.0 Optional Feature Description