Optional Feature Description of Huawei UMTS RAN11_0

Optional Feature Description of Huawei UMTS RAN11.0

Issue V1.9

Date 2009-06-11

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2009. 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 trademarks 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 the 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]

Telephone: 0755-28560000 4008302118

Fax: 0755-28560111

http://www.huawei.com

mailto:[email protected]


Issue V1.7 (2009-04-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd Page 3 of 281

Contents

1 Multiple RAB ......................................................................................................................... 11 1.1 WRFD-010615 Multiple RAB Package (PS RAB ≥2).............................................................................11

1.1.1 WRFD-01061501 Combination of Two PS Services .........................................................................12 1.1.2 WRFD-01061502 Combination of One CS Service and Two PS Services .........................................13 1.1.3 WRFD-01061503 Combination of Three PS Services.......................................................................13 1.1.4 WRFD-01061504 Combination of One CS Service and Three PS Services .......................................14 1.1.5 WRFD-01061505 Combination of Four PS Services ........................................................................15

2 HSDPA Introduction and HSDPA 3.6 Mbit/s per User .................................................... 17 2.1 WRFD-010610 HSDPA Introduction Package...........................................................................................17

2.1.1 WRFD-01061017 QPSK Modulation...............................................................................................18 2.1.2 WRFD-01061001 15 Codes per Cell ................................................................................................19 2.1.3 WRFD-01061018 Time and HS-PDSCH Codes Multiplex................................................................20 2.1.4 WRFD-01061009 HSDPA H-ARQ & Scheduling (MAX C/I, RR, and PF).......................................21 2.1.5 WRFD-01061005 HSDPA Static Code Allocation and RNC-Controlled Dynamic Code Allocation ...22 2.1.6 WRFD-01061004 HSDPA Power Control ........................................................................................24 2.1.7 WRFD-01061003 HSDPA Admission Control..................................................................................25 2.1.8 WRFD-01061019 HSDPA Dynamic Power Allocation .....................................................................26 2.1.9 WRFD-01061010 HSDPA Flow Control ..........................................................................................27 2.1.10 WRFD-01061006 HSDPA Mobility Management...........................................................................28 2.1.11 WRFD-01061014 HSDPA Transport Resource Management ..........................................................30 2.1.12 WRFD-01061008 Interactive and Background Traffic Class on HSDPA .........................................32 2.1.13 WRFD-01061002 HSDPA UE Category 1 to 18 .............................................................................33 2.1.14 WRFD-01061015 HSDPA 1.8 Mbit/s per User ...............................................................................34 2.1.15 WRFD-01061016 16 HSDPA Users per Cell ..................................................................................35

2.2 WRFD-010620 HSDPA 3.6Mbps per User................................................................................................35

3 16QAM Modulation .............................................................................................................. 37 3.1 WRFD-010629 16QAM Modulation.........................................................................................................37

4 Dynamic Code Allocation Based on Node B...................................................................... 39 4.1 WRFD-010631 Dynamic Code Allocation Based on Node B.....................................................................39

5 Enhanced HSDPA Solution and HSDPA 7.2Mbps per User ........................................... 41 5.1 WRFD-010621 HSDPA 7.2Mbps per User................................................................................................41



5.2 WRFD-010622 32 HSDPA Users per Cell.................................................................................................42 5.3 WRFD-010611 HSDPA Enhanced Package...............................................................................................42

5.3.1 WRFD-01061103 Scheduling based on EPF and GBR .....................................................................43 5.3.2 WRFD-01061111 HSDPA State Transition .......................................................................................44 5.3.3 WRFD-01061112 HSDPA DRD.......................................................................................................46 5.3.4 WRFD-01061113 HS-DPCCH Preamble Support.............................................................................47

5.4 WRFD-010630 Streaming Traffic Class on HSDPA ..................................................................................48

6 SRB over HSDPA and HSDPA 13.976Mbps per User....................................................... 50 6.1 WRFD-010650 HSDPA 13.976Mbps per User ..........................................................................................50 6.2 WRFD-010651 HSDPA over Iur ...............................................................................................................51 6.3 WRFD-010652 SRB over HSDPA ............................................................................................................52 6.4 WRFD-010623 64 HSDPA Users per Cell.................................................................................................53

7 HSUPA Introduction and HSUPA 1.44 Mbit/s per User................................................... 55 7.1 WRFD-010612 HSUPA Introduction Package...........................................................................................55

7.1.1 WRFD-01061201 HSUPA UE Category 1 to 6.................................................................................56 7.1.2 WRFD-01061209 HSUPA HARQ and Fast UL Scheduling in Node B..............................................57 7.1.3 WRFD-01061202 HSUPA Admission Control..................................................................................59 7.1.4 WRFD-01061203 HSUPA Power Control ........................................................................................60 7.1.5 WRFD-01061204 HSUPA Mobility Management ............................................................................61 7.1.6 WRFD-01061208 HSUPA DCCC ....................................................................................................63 7.1.7 WRFD-01061207 HSUPA Transport Resource Management ............................................................64 7.1.8 WRFD-01061206 Interactive and Background Traffic Class on HSUPA ...........................................66 7.1.9 WRFD-01061210 HSUPA 1.44Mbps per User .................................................................................67 7.1.10 WRFD-01061211 20 HSUPA Users per Cell ..................................................................................68

8 HSUPA5.74 Mbit/s per User and 60 HSUPA Users per Cell ............................................ 69 8.1 WRFD-010614 HSUPA Phase 2 ...............................................................................................................69

8.1.1 WRFD-01061401 E-AGCH Power Control (Based on CQI or HS-SCCH)........................................70 8.1.2 WRFD-01061402 Enhanced Fast UL scheduling..............................................................................71 8.1.3 WRFD-01061403 HSUPA 2ms TTI .................................................................................................72 8.1.4 WRFD-01061404 HSUPA 2 ms/10 ms TTI HO................................................................................73 8.1.5 WRFD-01061405 HSUPA 5.74Mbps per User .................................................................................74

8.2 WRFD-010632 Streaming Traffic Class on HSUPA ..................................................................................75 8.3 WRFD-010634 60 HSUPA Users per Cell.................................................................................................76 8.4 WRFD-010635 HSUPA over Iur ...............................................................................................................76 8.5 WRFD-010636 SRB over HSUPA ............................................................................................................78 8.6 WRFD-010640 Uplink Macro Diversity Intelligent Receiving...................................................................79 8.7 WRFD-010641 HSUPA Adaptive Retransmission .....................................................................................80

9 HSUPA Iub Flow Control in Case of Iub Congestion ...................................................... 81 9.1 WRFD-010637 HSUPA Iub Flow Control in Case of Iub Congestion ........................................................81

10 Dynamic CE Resource Management ................................................................................. 83



10.1 WRFD-010638 Dynamic CE Resource Management...............................................................................83

11 HSPA+ Introduction............................................................................................................ 85 11.1 WRFD-010680 HSPA+ Downlink 28Mbps per User ...............................................................................85 11.2 WRFD-010681 HSPA+ Downlink 21Mbps per User ...............................................................................86 11.3 WRFD-010685 Downlink Enhanced L2..................................................................................................87 11.4 WRFD-010688 Enhanced CELL-FACH..................................................................................................88

12 Downlink 64QAM ............................................................................................................... 90 12.1 WRFD-010683 Downlink 64QAM .........................................................................................................90

13 2×2 MIMO............................................................................................................................. 92 13.1 WRFD-010684 2×2 MIMO ....................................................................................................................92

14 HSPA+ Capacity Enhancement.......................................................................................... 93 14.1 WRFD-010686 CPC-DTX/DRX.............................................................................................................93 14.2 WRFD-010687 CPC-HS-SCCH Less operation ......................................................................................95 14.3 WRFD-010653 96 HSDPA Users per Cell...............................................................................................96 14.4 WRFD-010639 96 HSUPA Users per Cell...............................................................................................97

15 Differentiated Service Management ................................................................................. 98 15.1 WRFD-010505 Queuing and Pre-Emption ..............................................................................................98 15.2 WRFD-021103 Access Class Restriction...............................................................................................100 15.3 WRFD-050424 Traffic Priority Mapping onto Transmission Resources .................................................101 15.4 WRFD-020806 Differentiated Service Based on SPI Weight .................................................................104

16 Intra-RAT Mobility Management Solution ................................................................... 106 16.1 WRFD-020302 Inter Frequency Hard Handover Based on Coverage .....................................................106 16.2 WRFD-020304 Inter Frequency Hard Handover Based on DL QoS .......................................................108 16.3 WRFD-020605 SRNS Relocation Introduction Package........................................................................109

16.3.1 WRFD-02060501 SRNS Relocation (UE Not Involved)............................................................... 110 16.3.2 WRFD-02060502 SRNS Relocation with Hard Handover ............................................................ 111 16.3.3 WRFD-02060503 SRNS Relocation with Cell/URA Update......................................................... 112 16.3.4 WRFD-02060504 Lossless SRNS Relocation............................................................................... 112

17 Inter-RAT Mobility Management Solution ................................................................... 114 17.1 WRFD-020303 Inter-RAT Handover Based on Coverage ...................................................................... 114 17.2 WRFD-020309 Inter-RAT Handover Based on DL QoS ........................................................................ 116 17.3 WRFD-020307 Video Telephony Fallback to Speech (AMR) for Inter-RAT HO .................................... 117 17.4 WRFD-020308 Inter-RAT Handover Phase 2 ........................................................................................ 119

17.4.1 WRFD-02030801 NACC (Network Assisted Cell Change)........................................................... 119 17.4.2 WRFD-02030802 PS Handover between UMTS and GPRS .........................................................121

18 Load Control and Performance Enhancement................................................................ 122 18.1 WRFD-020103 Inter-Frequency Load Balance......................................................................................122 18.2 WRFD-020305 Inter-RAT Handover Based on Service .........................................................................123 18.3 WRFD-020306 Inter-RAT Handover Based on Load .............................................................................124



18.4 WRFD-020400 DRD Introduction Package...........................................................................................125 18.4.1 WRFD-02040001 Intra System Direct Retry ................................................................................125 18.4.2 WRFD-02040002 Inter System Direct Retry ................................................................................126 18.4.3 WRFD-02040003 Inter System Redirect ......................................................................................127

18.5 WRFD-021102 Cell Barring .................................................................................................................127 18.6 WRFD-020310 3G/2G Common Load Management .............................................................................128 18.7 WRFD-010506 RAB Quality of Service Renegotiation over Iu Interface ...............................................130 18.8 WRFD-010507 Rate Negotiation at Admission Control.........................................................................131 18.9 WRFD-020120 Service Steering and Load Sharing in RRC Connection Setup.......................................133 18.10 WRFD-020123 TCP Accelerator .........................................................................................................134 18.11 WRFD-020124 Uplink Flow Control of User Plane.............................................................................136

19 Cell Broadcast Service ....................................................................................................... 137 19.1 WRFD-011000 Cell Broadcast Service .................................................................................................137

20 TFO/TrFO............................................................................................................................ 138 20.1 WRFD-011600 TFO/TrFO....................................................................................................................138

21 Dynamic Power Sharing of Multi-Carriers .................................................................... 140 21.1 WRFD-020116 Dynamic Power Sharing of Multi-Carriers....................................................................140

22 Green Node B Solution ..................................................................................................... 142 22.1 WRFD-020117 Multi-Carrier Switch off Based on Traffic Load ............................................................142 22.2 WRFD-020118 Energy Efficiency Improved .........................................................................................143

23 AMR-WB (Adaptive Multi Rate Wide Band)................................................................. 145 23.1 WRFD-010613 AMR-WB (Adaptive Multi Rate Wide Band)................................................................145 23.2 WRFD-020701 AMR/AMR-WB Speech Rates Control.........................................................................146

24 Overbooking on ATM Transmission .............................................................................. 148 24.1 WRFD-050405 Overbooking on ATM Transmission .............................................................................148

25 VoIP over HSPA/HSPA+ .................................................................................................. 151 25.1 WRFD-010617 VoIP over HSPA /HSPA+ .............................................................................................151

25.1.1 WRFD-01061701 RAB Mapping.................................................................................................152 25.1.2 WRFD-01061703 Optimized Scheduling for VoIP over HSPA......................................................153

25.2 WRFD-010618 IMS Signaling over HSPA............................................................................................154 25.3 WRFD-011501 PDCP Header Compression (RoHC).............................................................................155

26 CS Voice over HSPA/HSPA+ ........................................................................................... 157 26.1 WRFD-010619 CS Voice over HSPA/HSPA+ .......................................................................................157

27 Positioning Service ............................................................................................................ 159 27.1 WRFD-020801 Cell ID + RTT Function Based LCS .............................................................................159 27.2 WRFD-020802 OTDOA Based LCS.....................................................................................................160 27.3 WRFD-020803 A-GPS Based LCS .......................................................................................................161 27.4 WRFD-020804 LCS Classified Zones...................................................................................................162



27.5 WRFD-020805 LCS over Iur ................................................................................................................163

28 RAN Sharing....................................................................................................................... 167 28.1 WRFD-021304 RAN Sharing Introduction Package..............................................................................167

28.1.1 WRFD-02130401 Dedicated Carrier for Each Operator ................................................................169 28.1.2 WRFD-02130402 Flexible Network Architecture .........................................................................170 28.1.3 WRFD-02130403 Mobility Control and Service Differentiation ...................................................172 28.1.4 WRFD-02130404 Independent License Control ...........................................................................173 28.1.5 WRFD-02130405 Independent Cell-level FM/PM/CM.................................................................174 28.1.6 WRFD-02130406 Transmission Resource Sharing on Iub/Iur Interface.........................................175

28.2 WRFD-021305 RAN Sharing Phase 2...................................................................................................176 28.2.1 WRFD-02130501 Dedicated Iub Transmission Control ................................................................177

28.3 WRFD-021303 IMSI Based Handover ..................................................................................................180

29 MOCN Introduction .......................................................................................................... 181 29.1 WRFD-021311 MOCN Introduction Package........................................................................................181

29.1.1 WRFD-02131101 Carrier Sharing Among Operators ....................................................................182 29.1.2 WRFD-02131102 Dedicated Node B/Cell for Operators...............................................................184 29.1.3 WRFD-02131103 MOCN Mobility Management .........................................................................185 29.1.4 WRFD-02131104 MOCN Load Balance ......................................................................................185 29.1.5 WRFD-02131105 MOCN Independent Performance Management ...............................................186

30 Iu Flex .................................................................................................................................. 187 30.1 WRFD-021302 Iu Flex .........................................................................................................................187 30.2 WRFD-021306 Iu Flex Load Distribution Management ........................................................................190

31 Multi Frequency Band Networking Management......................................................... 192 31.1 WRFD-020110 Multi Frequency Band Networking Management ..........................................................192

32 Satellite Transmission....................................................................................................... 195 32.1 WRFD-050104 Satellite Transmission on Iub Interface .........................................................................195

33 MBMS and Enhanced MBMS .......................................................................................... 196 33.1 WRFD-010616 MBMS Introduction Package .......................................................................................196

33.1.1 WRFD-01061601 MBMS Broadcast Mode ..................................................................................198 33.1.2 WRFD-01061602 MBMS Admission Control ..............................................................................199 33.1.3 WRFD-01061603 MBMS Load Control.......................................................................................199 33.1.4 WRFD-01061604 MBMS Soft/Selective Combination .................................................................200 33.1.5 WRFD-01061605 MBMS Transport Resource Management.........................................................201 33.1.6 WRFD-01061606 Streaming Service on MBMS...........................................................................202 33.1.7 WRFD-01061607 MBMS 2 Channels per Cell .............................................................................203 33.1.8 WRFD-01061608 16/32/64/128Kbps Channel Rate on MBMS.....................................................203

33.2 WRFD-010660 MBMS Phase 2............................................................................................................204 33.2.1 WRFD-01066001 MBMS Enhanced Broadcast Mode ..................................................................205 33.2.2 WRFD-01066002 MBMS P2P over HSDPA ................................................................................206



33.2.3 WRFD-01066003 MBMS Admission Enhancement .....................................................................207 33.2.4 WRFD-01066004 Inter-Frequency Neighboring Cell Selection for MBMS PTP Users ..................208

33.3 WRFD-010627 FACH Transmission Sharing for MBMS.......................................................................209 33.4 WRFD-010626 MBMS FLC (Frequency Layer Convergence)/FLD (Frequency Layer Dispersion)........210 33.5 WRFD-010624 MBMS 8 Channels per Cell.......................................................................................... 211

34 Enhanced MBMS ............................................................................................................... 213 34.1 WRFD-010625 256Kbps Channel Rate on MBMS................................................................................213 34.2 WRFD-010628 MBMS 16 Channels per Cell........................................................................................213 34.3 WRFD-010661 MBMS over Iur............................................................................................................214 34.4 WRFD-010662 Dynamic Power Estimation for MTCH.........................................................................215 34.5 WRFD-010663 MSCH and MSCH Scheduling .....................................................................................216 34.6 WRFD-010665 MBMS Channel Audience Rating Statistics ..................................................................217

35 Domain Specific Access Control (DSAC)....................................................................... 219 35.1 WRFD-020114 Domain Specific Access Control (DSAC) .....................................................................219

36 One Tunnel ......................................................................................................................... 221 36.1 WRFD-020111 One Tunnel ..................................................................................................................221

37 Iub over IP........................................................................................................................... 223 37.1 WRFD-050402 IP Transmission Introduction on Iub Interface...............................................................223 37.2 WRFD-050411 Fractional IP Function on Iub Interface .........................................................................225 37.3 WRFD-050403 Hybrid Iub IP Transmission..........................................................................................227 37.4 WRFD-050404 ATM/IP Dual Stack Node B..........................................................................................228

38 Iu/Iur over IP....................................................................................................................... 230 38.1 WRFD-050409 IP Transmission Introduction on Iu Interface.................................................................230 38.2 WRFD-050410 IP Transmission Introduction on Iur Interface ...............................................................231

39 IP Transmisson Efficiency Improvement ....................................................................... 233 39.1 WRFD-050420 FP MUX for IP Transmission .......................................................................................233 39.2 WRFD-050421 IP Re-route Based on BFD/ARP...................................................................................234 39.3 WRFD-050422 Dynamic Bandwidth Control of Iub IP..........................................................................236 39.4 WRFD-050408 Overbooking on IP Transmission..................................................................................237 39.5 WRFD-050412 UDP MUX for Iu-CS Transmission ..............................................................................240

40 ATM Switching Based Hub Node B................................................................................ 241 40.1 WRFD-050105 ATM Switching Based Hub Node B..............................................................................241

41 AAL2 Switching Based Hub Node B............................................................................... 243 41.1 WRFD-050106 AAL2 Switching Based Hub Node B............................................................................243

42 IP Routing Based Hub Node B......................................................................................... 245 42.1 WRFD-050107 IP Routing Based Hub Node B .....................................................................................245

43 Hub Node B Based ATM QoS Management.................................................................. 247 43.1 WRFD-050406 ATM QoS Introduction on Hub Node B (Overbooking on Hub Node B Transmission)...247



44 Ethernet OAM .................................................................................................................... 249 44.1 WRFD-050425 Ethernet OAM .............................................................................................................249

45 Clock Synchronization on Ethernet in Node B.............................................................. 251 45.1 WRFD-050501 Clock Synchronization on Ethernet in Node B ..............................................................251

46 Synchronous Ethernet ....................................................................................................... 253 46.1 WRFD-050502 Synchronous Ethernet ..................................................................................................253

47 RNC Node Redundancy.................................................................................................... 255 47.1 WRFD-040202 RNC Node Redundancy ...............................................................................................255

48 RRU Redundancy............................................................................................................... 257 48.1 WRFD-040203 RRU Redundancy ........................................................................................................257

49 Transmit Diversity............................................................................................................. 259 49.1 WRFD-010203 Transmit Diversity .......................................................................................................259

50 4-Antenna Receive Diversity............................................................................................ 261 50.1 WRFD-010209 4-Antenna Receive Diversity........................................................................................261

51 Control Channel Parallel Interference Cancellation (CCPIC) ..................................... 263 51.1 WRFD-010210 Control Channel Parallel Interference Cancellation (CCPIC).........................................263

52 Extended Cell Coverage up to 200km.............................................................................. 265 52.1 WRFD-021308 Extended Cell Coverage up to 200km...........................................................................265

53 Improved Downlink Coverage......................................................................................... 267 53.1 WRFD-021309 Improved Downlink Coverage......................................................................................267

54 High Speed Access............................................................................................................. 268 54.1 WRFD-010206 High Speed Access.......................................................................................................268

55 PDCP Head Compression (RFC 2507) ............................................................................. 270 55.1 WRFD-011500 PDCP Header Compression (RFC 2507).......................................................................270

56 Active Queue Management (AQM)................................................................................. 272 56.1 WRFD-011502 Active Queue Management (AQM) ..............................................................................272

57 Fractional ATM Function on Iub Interface..................................................................... 274 57.1 WRFD-050302 Fractional ATM Function on Iub Interface ....................................................................274

58 Hierarchical Cell Structure (HCS).................................................................................... 276 58.1 WRFD-021200 Hierarchical Cell Structure (HCS) ................................................................................276

59 Intra-Frequency Load Balance.......................................................................................... 278 59.1 WRFD-020104 Intra-Frequency Load Balance......................................................................................278

60 Potential User Control ....................................................................................................... 279 60.1 WRFD-020105 Potential User Control..................................................................................................279

61 Acronyms and Abbreviations........................................................................................... 280





1 Multiple RAB

1.1 WRFD-010615 Multiple RAB Package (PS RAB ≥2)

Availability This feature is available from RAN2.0.

This feature is introduced in 3GPP R99.

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:

l Combination of two PS services l One CS service + two PS services l Combination of three PS services l One CS service + three 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:

l Combination of three PS services including IMS signaling l 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 other NEs

The CN node and UE must have the corresponding multi-RAB support capability.

1.1.1 WRFD-01061501 Combination of Two PS Services


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 other RAN software functions

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

Dependency on other NEs




1.1.2 WRFD-01061502 Combination of One CS Service and Two PS Services


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.


WRFD-010615 Multiple RAB Package (PS RAB ≥2)



1.1.3 WRFD-01061503 Combination of Three PS Services


Summary This feature is a combination of three PS services.




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.





1.1.4 WRFD-01061504 Combination of One CS Service and Three PS Services


Summary This feature is a combination of one CS service and three PS services (including IMS signaling).


Description Huawei supports the combination of One CS Service + Three PS Services including IMS Signaling.

The bit rates of CS + 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.







1.1.5 WRFD-01061505 Combination of Four PS Services


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




The CN and UE must have the capability of supporting Multi-RAB.



2 HSDPA Introduction and HSDPA 3.6 Mbit/s per User

2.1 WRFD-010610 HSDPA Introduction Package



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:

l Providing high rate throughput l Shorter round trip time l 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 TTL greatly reduces the round trip time. At the same time, some functions are moved down to the Node B 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 enhancements of the sub-features in the HSDPA Introduction Package.

Dependency Dependency on Node B hardware

NDLP and NBBI do not support this feature.

Dependency on other RAN software functions

The HSDPA feature provides a number of methods to increase system throughput. It has to co-ordinate with other features, such as admission control, load control, and mobility management.


The UE should have the HSDPA capability.

2.1.1 WRFD-01061017 QPSK Modulation


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.


WRFD-010610 HSDPA Introduction Package

2.1.2 WRFD-01061001 15 Codes per Cell


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 Node B is configurable and depending on the license, the Node B can dynamically allocate codes to HS-PDSCH between cells in Node B.



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



2.1.3 WRFD-01061018 Time and HS-PDSCH Codes Multiplex


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 Node B has more HS-PDSCH codes for allocation than those supported by the UE. For instance, the UE supports 5 codes and the Node B has 10 codes available in a single TTI. The code multiplexing can increase the resource utilization and system throughput.

Enhancement None.





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


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.

l Max C/I l RR (round Robin) l PF (proportional fair) l EPF (enhanced 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:

l Channel environment of the UE l 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 RAN5.1, enhanced proportional fair (EPF) is introduced. SPI mapping is further optimized after considering ARP. In addition, the services with GBR include the best effort services, and the configurable limit of the minimum throughput should be strictly guaranteed during the scheduling in RAN5.1.

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.



2.1.5 WRFD-01061005 HSDPA Static Code Allocation and RNC-Controlled Dynamic Code Allocation


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 Node B 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 Node B 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 Node B 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 forcommon channel and

HS-SCCH Codes reserved forHS-PDSCH

SF=16

Codes availablefor 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 Node B-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 Node B can use and then informs the Node B 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 Node B 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 forcommon channel and

HS-SCCH

Enhancement In RAN5.1, the RNC-controlled dynamic HS-PDSCH code allocation is introduced.





2.1.6 WRFD-01061004 HSDPA Power Control


Summary This feature enables the operator to properly configure the power control mode of the HS-SCCH, thus 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 Node B power output for the HS-SCCH, thus 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 Node B scheduling algorithm.

With dynamical power allocation, the Node B 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 Node B then adjusts the power between HS-SCCH and HS-PDSCH. Normally, there are three types of power control methods for the HS-SCCH:

l Fixed transmitting power of the HS-SCCH l Based on CQI report l Based on downlink associated DPCH.

In the Node B, 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.

For the power control based on DL associated DPCH, a power offset between the HS-SCCH and the DPDCH can be set and the HS-SCCH transmit power is adjusted according to the transmit power of the associated downlink DPDCH.



Enhancement None



2.1.7 WRFD-01061003 HSDPA Admission Control


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 service to properly utilize system resources and enable HSDPA service and R99 service 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 Node B 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 streaming and 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.



2.1.8 WRFD-01061019 HSDPA Dynamic Power Allocation


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, thus greatly improving the power efficiency.

Benefits This feature enables HSDPA service to properly utilize system resources and enable HSDPA service and R99 service 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:

l Power of the HSDPA DL physical channel (HS-SCCH and HS-PDSCH) l Common channel power l DPCH power

Among the three parts, the second is reserved and the first is allocated by the Node B.

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 Node B 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.



2.1.9 WRFD-01061010 HSDPA Flow Control


Summary This feature enables the resource information interaction between the RNC and Node B 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 Node B 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 Node B and reduces the data transmission latency.

Flexible scheme

Power for CCH

Power for DPCH

Power for HSDPA

Full usage of power Total Power

Time



Description HSDPA flow control ensures that the Node B 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 Node B in order to avoid data loss probably caused by overtime data buffering.

The RNC sends CAPACITY REQUEST control frame to the Node B through the Iub interface. The Node B will monitor the buffer status and measure the throughput when the UE is scheduled. Meanwhile, the Node B considers the Iub interface throughput as well as the Iub bandwidth. A CAPACITY ALLOCATION message will be sent to the RNC after the Node B decides how much data to send.

The Node B 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.



2.1.10 WRFD-01061006 HSDPA Mobility Management


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, thus 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 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.

l 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.

l 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.

l 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.

l Handover from HSDPA Cell to 2G cell The handover from HSDPA cell to 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.

l Inter RNC Handover 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 CELL UPDATE message in the DRNC. At this time, the UE moves to the cell of the DRNC and no handover or relocation occurs.

Enhancement None.





2.1.11 WRFD-01061014 HSDPA Transport Resource Management

Availability This feature is available from RAN5.0

Summary This feature enables different HSDPA services to be mapped to different paths for classified management, thus optimizing the utilization of Iub transmission resources for the HSDPA services.

Benefits Differentiated service is implemented on different paths and thus 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:

l Differentiated services mapping l Transport resource load control

I. Differentiated services mapping

The PS streaming and best effort services can be set up on HSDPA. Different services have different QoS requirements, and the Iub transport will be IP and/or ATM. Therefore, the traffic categories such as ATMHDRT, ATMHDNRT, IPHDRT, and IPHDNRT are added accordingly.

Traffic Category Traffic Type

ATMHDRT HSDPA streaming service

ATMHDNRT HSDPA interactive service and HSDPA background service

IPHDRT HSDPA streaming service

PHDNRT HSDPA interactive service and HSDPA background service

Moreover, differentiated transmission must be applied according to the QoS requirements. The following table shows the mapping:



Item AAL2 Path Type Service Type of ATM Traffic

ATMHDRT HSPA CBR, RTVBR

ATMHDNRT HSPA NRTVBR, UBR

The mapping between traffic categories and path type is configurable. The following table shows an example in an ATM-based transmission network.

Traffic Category Primary Path Type Secondary Path Type

HSDPA streaming ATMHDRT None

HSDPA interactive ATMHDNRT None

HSDPA background ATMHDNRT 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 onto the secondary ATM path type to keep the services available or vice verse. The following table shows the configurations.


HSDPA streaming ATMHDRT IPHDRT

HSDPA interactive ATMHDNRT IPHDRT

HSDPA background ATMHDNRT IPHDRT

By using this feature, different services are carried on corresponding paths and then 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 scenarios including inter-frequency handover and inter-RAT handover. Such a feature belongs to the optional feature WRFD-020103 Inter Frequency Load Balance and WRFD-020306 Inter-RAT Handover Based on Load.

Enhancement In RAN6.1, each traffic class mapped onto transmission resource can be configured separately.





Optional features WRFD-050402 IP Transmission (Iub interface), WRFD-050403 Hybrid IP Transmission, and WRFD-050404 ATM/IP Dual Stack Node B are required when the transmission resource management feature is applied to IP transmission resources in those scenarios.

2.1.12 WRFD-01061008 Interactive and Background Traffic Class on HSDPA


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.





2.1.13 WRFD-01061002 HSDPA UE Category 1 to 18


Summary This feature can provide proper HSDPA services for the UEs of category 1 to category 18.

Benefits HSDPA with 12 UE categories makes it possible to introduce high bit rate service for different types of UE. The user can achieve the maximum bit rate according to the maximum UE capability.

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, 12 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

Category 1 5 3 7298 3.649

Category 2 5 3 7298 3.649

Category 3 5 2 7298 3.649

Category 4 5 2 7298 3.649

Category 5 5 1 7298 3.649

Category 6 5 1 7298 3.649

Category 7 10 1 14411 7.2055

Category 8 10 1 14411 7.2055

Category 9 15 1 20251 10.1255

Category 10 15 1 27952 13.976

Category 11 5 2 3630 1.815

Category 12 5 1 3630 1.815

Category 13 15 1 35280 17.64

Category 14 15 1 42192 21.096



HS-DSCH Category

Maximum Number of HS-DSCH Codes Received

Minimum Inter-TTI Interval

Maximum Number of Bits

Maximum Bit Rate

Category 15 15 1 23370 11.685

Category 16 15 1 27952 13.976

35280 17.64 Category 17 15 1

23370 11.685

42192 21.096 Category 18 15 1

27952 13.976

Note: In the maximum number of bits, the bits refer to those of an HS-DSCH transport block received within an HS-DSCH TTI.

In the above table, UEs of Category 13 and Category 14 are only required to support 64QAM, and 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.

Enhancement In RAN11.0, UEs of Category 13, Category 14, Category 15, Category 16, Category 17 and Category 18 are introduced.



2.1.14 WRFD-01061015 HSDPA 1.8 Mbit/s per User


Summary This feature enables the HSDPA rate to reach a maximum of 1.8 Mbit/s for each user.

Benefits This feature provides higher peak bit rate and enhances the end 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), thus greatly enhancing the user experience.

Enhancement None.



2.1.15 WRFD-01061016 16 HSDPA Users per Cell


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.



2.2 WRFD-010620 HSDPA 3.6Mbps per User





Summary This feature enables the HSDPA rate per user to reach a maximum of 3.6 Mbit/s.

Benefits This feature provides a higher peak bit rate and enhances user experience.

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). Thus, user experience is greatly enhanced.

Enhancement None.

Dependency WRFD-010610 HSDPA Introduction Package

The UE should support a rate of 3.6 Mbit/s.



3 16QAM Modulation

3.1 WRFD-010629 16QAM Modulation



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 poor 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.






UE should support the demodulation of 16QAM.



4 Dynamic Code Allocation Based on Node B

4.1 WRFD-010631 Dynamic Code Allocation Based on Node B


Summary This feature implements dynamic code allocation on the Node B side. The Node B 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 Node B-controlled dynamic HS-PDSCH code allocation, Node B determines the HS-PDSCH code use according to the code availability and scheduling algorithm in each 2ms TTI. Node B-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 at the Node B, 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 Node B has allocated more HS-PDSCH codes than what is supported by the UE. For instance, the UE supports 5 codes and the Node B has 10 codes available in a single TTI. The code multiplexing can increase the resource utilization and system throughput.

Enhancement None.







5 Enhanced HSDPA Solution and HSDPA 7.2Mbps per User



Summary This feature enables the HSDPA rate per user to reach a maximum of 7.2 Mbit/s.


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 of up to 7.2 Mbit/s (MAC layer). Thus, user experience is greatly enhanced.

Enhancement None.


WRFD-010620 HSDPA 3.6Mbps per User





5.2 WRFD-010622 32 HSDPA Users per Cell


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.



5.3 WRFD-010611 HSDPA Enhanced Package



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:

l EPF and GBR Based Scheduling l HSDPA State Transition l HSDPA DRD (Direct Retry Decision) l 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.




UE should support the functions connected with HSDPA Enhanced package.

5.3.1 WRFD-01061103 Scheduling based on EPF and GBR


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:

l Max C/I l Round robin algorithm l Proportional Fair algorithm (PF) l 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, thus 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 amongst 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.



5.3.2 WRFD-01061111 HSDPA State Transition




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.

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 the UE is not in active state.

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 relation.

CELL_PCH CELL_FACH

CELL_DCH

CELL_DCH(with HS-DSCH)

l 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 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.

l 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.



5.3.3 WRFD-01061112 HSDPA DRD


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, thus 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, thus 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.



WRFD-020400 DRD Introduction Package

5.3.4 WRFD-01061113 HS-DPCCH Preamble Support


Summary This feature enables the transmission of dedicated preamble subframes before ACK/NACK subframes are transmitted on the HS-DPCCH, thus improving transmission reliability.

Benefits HS-DPCCH preamble mode technology enables the Node B 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 Acknowledgement (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 Node B 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 Node B, because the Node B 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.


l The BTS3812E, BTS3812A, and BTS3812AE should be configured with the EBBI or EULP board.

l The BBU3806 should be configured with the EBBC board; the BBU3806C should be configured with the EBBM board.

l The BBU3900 should be configured with the WBBPb board.




UE should support the feature.

5.4 WRFD-010630 Streaming Traffic Class on HSDPA



Summary This feature enables the streaming services to be mapped onto the HS-DSCH, thus 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 also 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.


WRFD-010611 HSDPA Enhanced Package



6 SRB over HSDPA and HSDPA 13.976Mbps per User




Summary This feature enables the HSDPA rate per user to reach a maximum of 13.976 Mbit/s. The rate is a peak rate defined in 3GPP specifications.


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 13.976 Mbit/s (MAC layer). Thus, user experience is greatly enhanced.

Enhancement None.

Dependency Dependency on RNC hardware

This feature requires WFMRc board in the BSC6800.







6.2 WRFD-010651 HSDPA over Iur



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.

l 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.

l 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 processes are 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 the network, the CRNC may trigger 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.




The neighboring RNC should also support HSDPA over Iur.

6.3 WRFD-010652 SRB over HSDPA



Summary SRB over HSDPA enables the DL SRBs of multiple UEs to be carried over HSDPA through the FDPCH multiplexing technology, thus reducing the consumption of DL code resources and transmission resources and improving the call setup delay.

Benefits l This feature provides a higher signaling rate and reduces the call process delay. l 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 SRB is delay-sensitive and irregular. In some cases, the code may be limited prior to power and the cell capacity is affected. Thus, 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 channel and 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 None.


This feature depends on the Node B hardware:

l The BTS3812E, BTS3812A, and BTS3812AE should be configured with the EBBI or EDLP board.






The UE should support F-DPCH.



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.




WRFD-010622 32 HSDPA Users per Cell



7 HSUPA Introduction and HSUPA 1.44 Mbit/s per User

7.1 WRFD-010612 HSUPA Introduction Package



Summary This feature package enables the system to process HSUPA services, thus improving the uplink rate and system throughput. This feature package provides basic functions of HSUPA to meet the requirements for test or trial operation of HSUPA services.

Benefits HSUPA improves the performance of UMTS network by providing higher rate and higher throughput for the uplink as well as 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 at the Node B.

The basic principle behind HARQ for HSUPA is the same as that for HSDPA. After each transmitted TTI, the Node B 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 at the Node B enables the system to make scheduling decision with the minimum latency as close to the radio interface as possible. Even though the Node B 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.


NBBI does not support this feature.


UE should have HSUPA capability.

7.1.1 WRFD-01061201 HSUPA UE Category 1 to 6


Summary This feature enables Huawei Node B to support six UE categories defined in 3GPP specifications.

Benefits HSUPA with six UE categories makes it possible to introduce high bit rate services for different types of UE. The user can achieve the maximum bit rate according to the maximum UE capability.

Description 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.

From the table, the UE of category 3 supports two SF4 codes with the maximum bit rate of 1.44 Mbit/s.

Note: RAN6.0 only supports the minimum spreading factor of SF4 and 10 ms TTI. Thus, the UE of scategories 2/4/5/6 only uses 10 ms TTI in RAN6.0.



Max. Data Rate (Mbit/s) E-DCH Category

Max. Capability Combination

E-DCH TTI

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

RAN10.0 supports SF2 and 2 ms TTI.

Enhancement RAN10.0 supports UEs of categories1-6 (2 ms).


WRFD-010612 HSUPA Introduction Package.

7.1.2 WRFD-01061209 HSUPA HARQ and Fast UL Scheduling in Node B


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 effeciency 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 High Speed Uplink Packet Access (HSUPA) is an important feature introduced in 3GPP 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 Node B.

The basic principle of HSUPA HARQ is the same as that of HSDPA HARQ. In each TTI, the Node B 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 informtion for correct decoding.

The fast scheduling algorithm in the Node B enables the system to make the scheduling decision with the minimum latency as close to the radio interface as possible. Even though the Node B 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.


WRFD-010612 HSUPA Introduction Package



7.1.3 WRFD-01061202 HSUPA Admission Control


Summary This feature enables HSUPA and R99 services to simultaneously access the network by using the remaining uplink cell load and other resources, thus improving the utilization of system resources and ensuring QoS.

Benefits This feature enables HSUPA services to properly utilize the system resources and enable HSUPA service and R99 service 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 Node B 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:

l 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.

l 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 Node B 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.



7.1.4 WRFD-01061203 HSUPA Power Control


Summary With the introduction of new physical channels, this feature can improve 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 thus 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.



7.1.5 WRFD-01061204 HSUPA Mobility Management


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 can not.

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.

l 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 doesn’t 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.

l 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.

l 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.

l 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 10 ms 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.



7.1.6 WRFD-01061208 HSUPA DCCC


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, thus improving the utilization of CE resources and system efficiency.

Benefits This feature can improve 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:

l 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 (i.e. interactive and background services) to a proper value to improve the CE resource utilization.

l 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_DCH 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.



7.1.7 WRFD-01061207 HSUPA Transport Resource Management


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 thus 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 usage of Iub transport resources for the HSUPA services. The following features are concerned.

l Differentiated services mapping l 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.


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.


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 strategies are applied in this scenario, including inter-frequency handover and inter-RAT handover. This feature belongs to the optional feature WRFD-020103 Inter Frequency Load Balance and WRFD-020306 Inter-RAT Handover Based on Load.

Enhancement In RAN6.1, each traffic class mapping to transmission resource can be configured separately.



Optional feature WRFD-050402 IP Transmission (Iub interface), WRFD-050403 Hybrid IP Transmission, and WRFD-050404 ATM/IP Dual Stack Node B should be required when the transmission resource management feature is applied for IP transmission resources in those scenarios.

7.1.8 WRFD-01061206 Interactive and Background Traffic Class on HSUPA


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 on 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 on 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 1.44 Mbit/s (MAC layer).

When a UE has BE service on E-DCH, it can use another CS RAB or another PS RAB simultaneously. If the UE capability is allowed, the UE can be served by one HSUPA BE RAB and one HSUPA streaming RAB or by two HSUPA BE 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.



7.1.9 WRFD-01061210 HSUPA 1.44Mbps per User


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 the 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). Thus, user experience is greatly enhanced.

Enhancement None.





7.1.10 WRFD-01061211 20 HSUPA Users per Cell


Summary This feature enables a single HSUPA cell to simultaneously support 20 HSUPA users. If the number of HSUPA users exceeds 16, 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.





8 HSUPA5.74 Mbit/s per User and 60 HSUPA Users per Cell

8.1 WRFD-010614 HSUPA Phase 2



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 High Speed Uplink Packet Access (HSUPA) is an important feature introduced in 3GPP 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.


For hardware, the HSUPA phase 2 depends on the EBBC, or EBBI, EULP board in Node B and the software. The software dependency is described in each sub functions.



8.1.1 WRFD-01061401 E-AGCH Power Control (Based on CQI or HS-SCCH)


Summary This feature enables the UE to report the CQI and HS-SCCH as a reference, thus 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:

l Less power consumption of E-AGCH l Flexible power control for E-AGCH

Description In 3GPP specifications, the serving cell of HSUPA should be the same with that of HSDPA. Meanwhile, AGCH belongs to the serving cell of HSUPA, so the power control of 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 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 AGCH. Consequently, it can spare more power for the downlink transmission.

l 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 AGCH.

l The demodulation error probability of HS-SCCH can be adjusted by modification of the transmission power of HS-SCCH. Since the demodulation requirements for AGCH are similar to those for HS-SCCH, power offset of AGCH can be modified based on that of HS-SCCH.

Enhancement None.






8.1.2 WRFD-01061402 Enhanced Fast UL scheduling


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 Node B, 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 (AGCH/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:

l Assign absolute grant according to the Scheduling Information (SI) sent by the UE, which can control the maximum rate the UE may use.

l Assign relative grant according to the happy bit on the E-DPCCH. l Queue the HSUPA users based on the scheduling priority indicator, GBR, and data rate. l Consider the CE resources and Iub transport resources.

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.





WRFD-010638 Dynamic CE Resource Management

8.1.3 WRFD-01061403 HSUPA 2ms TTI


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:

l Faster data scheduling l Higher UL peak data rate l 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. Thus, all UEs of the six categories can be supported.

Max. Data Rate (Mbit/s) E-DCH Category

Max. Capability Combination

E-DCH TTI

MAC Layer 10 ms TTI

MAC Layer 2 ms TTI

Air Interface






Category 6 2 x SF4 + 2 x SF2

10 ms and 2 ms 2.0 5.74 5.76



Compressed mode measurement is available for E-DCH 2 ms in the case of inter-frequency and inter-RAT handover.

Enhancement None.

Dependency This feature depends on the Node B hardware:

l The BTS3812E, BTS3812A, and BTS3812AE should be configured with the EBBI or EULP board.





8.1.4 WRFD-01061404 HSUPA 2 ms/10 ms TTI HO


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.

l When the soft handover happens to an UE using HSUPA 2 ms TTI and the target cell doesn’t support 2 ms TTI, the RNC first reconfigures the UE to 10 ms TTI and then performs the handover procedure.



l When the hard handover happens to an UE using HSUPA 2 ms TTI and the target cell doesn’t support 2 ms TTI, the RNC performs the handover and reconfigures the UE to 10 ms TTI at the same time.

l 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 Node B. For the neighboring cells that are not controlled by the RNC, such capability can be configured by the operator.

Enhancement None.



8.1.5 WRFD-01061405 HSUPA 5.74Mbps per User


Summary This feature enables the HSUPA rate per user 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.

Enhancement None.



WRFD-010636 SRB over HSUPA



8.2 WRFD-010632 Streaming Traffic Class on HSUPA



Summary This feature enables the streaming service to be mapped onto the E-DCH, thus 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 on 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 on 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 on the E-DCH. Otherwise, the requested service will be mapped on 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 and the BE 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.





8.3 WRFD-010634 60 HSUPA Users per Cell


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.



WRFD-010614 HSUPA Phase 2


8.4 WRFD-010635 HSUPA over Iur



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.

l 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.

l 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.

l 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.

l HSUPA service pre-emption in DRNC When the new HSUPA service is not admitted to access the network, the CRNC may trigger the preemption of other HSUPA services with lower priorities. If the CRNC is the DRNC, it will send the radio link preemption required indication to the SRNC and the SRNC will release the HSUPA services indicated in the radio link preemption 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.




The neighboring RNC should support this feature.



8.5 WRFD-010636 SRB over HSUPA



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 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 on 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 on the DCH if the target cell of the handover does not support the HSUPA.

If the SRB is mapped on the HSUPA in the uplink, then it must be mapped on the HSDPA in the downlink simultaneously.

The SRB over the HSUPA is configurable. The operator can enable/disable the SRB over HSUPA function.

Enhancement None.


The 38XX series Node B supports this feature, and the EBBI, EBOI, EULP, or EBBC is required.

The 3900 series Node B supports this feature, and the WBBPb is required.





8.6 WRFD-010640 Uplink Macro Diversity Intelligent Receiving


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 preemption 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 Node B require a higher rate, and Iub transmission resources or CE demodulation resources are insufficient, the Node B 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 Node B 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.





8.7 WRFD-010641 HSUPA Adaptive Retransmission


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 l 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%.

l 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 higher value is permitted, as long as the uplink CE resources are sufficient.

Enhancement





9 HSUPA Iub Flow Control in Case of Iub Congestion

9.1 WRFD-010637 HSUPA Iub Flow Control in Case of Iub Congestion



Summary This feature enables the monitoring of Iub transmission resources to dynamically adjust the uplink Uu throughput, thus greatly improving the resource utilization.

Benefits This feature can improve 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:

l If the Iub buffer occupancy ratio increases, the available bandwidth may be reduced by a step.

l If the Iub buffer occupancy ratio decreases, the available bandwidth may be increased by a step.

2. The transmission network congestion status (the Node B detects it according to the transmission network layer (TNL)) indicator is indicated by the RNC:

l If the transmission network is congested, the available bandwidth may be reduced by a step.



l If the transmission network is not-congested, the available bandwidth may be increased by a step.

Enhancement None.





10 Dynamic CE Resource Management

10.1 WRFD-010638 Dynamic CE Resource Management


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 preemption 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 Node B 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 HUSPA 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 Node B 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, Node B 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).

Enhancement None.



0

500

1000

1500

2000

0 20 40 60 80 100 120 140

Time (s)

Throughput (kbps)

Throughput (kbps)



11 HSPA+ Introduction

11.1 WRFD-010680 HSPA+ Downlink 28Mbps per User



Summary This feature enables the HSPA+ MIMO rate per user to reach a maximum of 28 Mbit/s. This feature enhances the user experience for high-speed data services.

Benefits l This feature can improve the frequency utilization and increase the maximum downlink

rate. l 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 peak downlink rate increases from 13.976 Mbps per user in R6 to 28 Mbps per user (MAC layer).

Enhancement None


The BSC6800 should be configured with FMRc boards.

Dependency on Node B hardware





l The BBU3900 should be configured with the WBBPb board. l For the RF part, the RF module of Huawei Node B supports one TX channel each, and

two interconnected RF modules can provide two TX channels to support 2 x 2 MIMO


WRFD-010685 Enhanced L2

WRFD-010684 2*2 MIMO



The UE category must support 2X2 MIMO. That is, the UE must belong to category 15, 16, 17, or 18, as specified in the 3GPP specifications.

11.2 WRFD-010681 HSPA+ Downlink 21Mbps per User



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.

Benefits l This feature can improve the frequency utilization and increase the maximum downlink

rate. l This feature can provide end users with high-speed data experience.

Description HSPA+ is introduced in 3GPP Release 7 to provide high speed for data services. With this feature, the peak downlink rate increases from 13.976 Mbps per user in R6 to 21 Mbps per user (MAC layer).

Enhancement None.


In the BSC6800, the FMRc boards are required for user plane data processing.




l The BTS3812E, BTS3812A and BTS3812AE need to configure EBBI board or EDLP board.

l The BBU3806 need to configure EBBC board; the BBU3806C need to configure EBBM board.

l The BBU3900 need to configure WBBPb board.


WRFD-010683 64QAM


WRFD-010650 HSDPA 13.976 Mbit/s per User


The UE category must support 64QAM. That is, the UE must belong to category 13, 14, 17, or 18, as specified by the 3GPP protocols.

11.3 WRFD-010685 Downlink Enhanced L2



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 thus 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, thus better service coverage and throughput will be attained.



Enhancement None.



UE should support this feature.

11.4 WRFD-010688 Enhanced CELL-FACH



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, thus 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, thus avoiding the delay caused by the state handover.

Enhancement None.


WRFD-010685 Downlink Enhanced L2



The UE should support this feature.



12 Downlink 64QAM

12.1 WRFD-010683 Downlink 64QAM



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 Node B and the UE supports 64QAM according to the local cell capability reported by the Node B and the UE capability. If the RL supports 64QAM, the MAC-hs scheduler of the Node B determines every 2 ms whether to use 64QAM according to the following aspects:

l Channel Quality Indicator (CQI) reported by the UE l HS-PDSCH code resources and power resources of the Node B

Enhancement None.


RAN10.0 new baseband board is hardware ready for 64QAM. To support 64QAM, the following configurations are required:


l The BBU3806 should be configured with the EBBC board. The BBU3806C should be configured with the EBBM board.






The UE category must support 64QAM. That is, the UE must belong to category 13, 14, 17, or 18, as specified by the 3GPP protocols.



13 2×2 MIMO

13.1 WRFD-010684 2×2 MIMO



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 at the Node B 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 and16QAM 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 Node B and the UE supports MIMO according to the local cell capability and UE capability reported by the Node B. If the RL supports MIMO, the MAC-hs scheduler of the Node B determines every 2 ms whether to use MIMO according to the following aspects:

l Channel Quality Indicator (CQI) reported by the UE l Precoding Control Indication (PCI)



l HS-PDSCH code resources and power resources of the Node B

Enhancement None.


RAN10.0 new baseband board is hardware ready for 2×2 MIMO. To support 2×2 MIMO, the following configurations are required:


l The BBU3806 should be configured with the EBBC board. The BBU3806C should be configured with the EBBM board.

l The BBU3900 should be configured with the WBBPb board. For the RF part, the RF module of Huawei Node B supports one TX channel each and two interconnected RF modules can provide two TX channels to support 2×2 MIMO.



WRFD-010685 Downlink Enhanced L2


The UE category must support 2×2 MIMO. That is, the UE must belong to category 15, 16, 17, or 18, as specified by the 3GPP protocols.

14 HSPA+ Capacity Enhancement

14.1 WRFD-010686 CPC-DTX/DRX





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 can improve 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 Node B 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 thus the UE need not detect the HS-SCCH in the period when no data would be sent according to the pattern.

Enhancement None.


l The following configurations are required to support this feature: − For the BTS3812E, BTS3812A and BTS3812AE, the EBBI, EULP (supporting

uplink DTX), and EDLP (supporting downlink DRX) should be configured. − For the BBU3806, the EBBC should be configured. For the BBU3806C, the EBBM

should be configured. − For the BBU3900, the WBBPb should be configured.

l Dependency on other RAN software functions − WRFD-010636 SRB over HSUPA − WRFD-010652 SRB over HSDPA

l Dependency on other NEs − The UE should support this feature.



14.2 WRFD-010687 CPC-HS-SCCH Less operation



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:

l Supports the QPSK modulation only. l Supports only four predefined transport formats (MAC-hs PDU). l Provides four semi-static transport formats for UEs. l 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). l 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. l 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)



l 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. l The UE keeps attempting to receive data from the HS-SCCH in a traditional sense.

Enhancement None.


WRFD-010652 SRB over HSDPA






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.


l WRFD-010623 64 HSDPA Users per Cell l WRFD-010652 SRB over HSDPA l WRFD-010686 CPC-DTX/DRX

14.4 WRFD-010639 96 HSUPA Users per Cell


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.


l WRFD-010634 60 HSUPA Users per Cell l WRFD-010686 CPC - DTX / DRX



15 Differentiated Service Management

15.1 WRFD-010505 Queuing and Pre-Emption



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 preemption of other RAB.

If a new call pre-emption doesn’t 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:

l New RAB request l Existing RAB modification request l Partial RAB assignment failure request l SRNS relocation request

The users can also be divided to Golden/Silver/Copper level which is mapped from ARP, and the mapping relation 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 preemption 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 preemption 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.


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.




This feature needs the core network to bring the ARP IE to RNC during RAB assignment procedure so that RNC can get the service priority with those RAB parameters.

15.2 WRFD-021103 Access Class Restriction



Summary When the cell or system is overloaded, this feature can restrict user access based on the service class allowed by SIB, thus controlling potential load requirements of the system.

Benefits Reduce signaling overload (call attempts) to increase network accessibility.

Reduce CN Overload.

Description The PRACH resources (i.e. 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, i.e. 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:

l 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 None.

15.3 WRFD-050424 Traffic Priority Mapping onto Transmission Resources


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

THP High

THP Middle

THP Low

THP High

THP Middle

THP Low

THP High

THP Middle

THP Low

R99 interactive

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



TC\ARP Gold Silver Bronze

HS I11 HS I12 HS I13



HSPA background HS B1 HS B2 HS B3

l 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.

l 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 None.

15.4 WRFD-020806 Differentiated Service Based on SPI Weight


Summary When air interface resources, CE resources, and Iub transmission resources do not meet the GBR of all online users, the differentiated service based on SPI weight can preferentially guarantee the GBR of high-priority users to provide differentiated services while ensuring the fairness. This feature can ensure the service experience of high-priority users.

Benefits This feature can ensure the service experience of high-priority users and provide differentiated services while ensuring the fairness.

Description HSDPA, HSUPA and HSPA+ can provide higher peak rate for users, improve the system capacity and user’s service perception. But with the improvement of system’s throughput, the system congestion will happen because of lack of resources.

The system resources mentioned here includes air interface resource, CE resources, and transmission resources of Iub. In the basic congestion status, current HSPA scheduling



algorithm and flow control algorithm of Iub will coordinate the resources to guarantee the GBR (Guaranteed Bit Rate) for all online users, to prevent some users from using too many resources, which will result in other users being deprived of the resources. If serious congestion occurs and all the resources of all online users are rescheduled, the guaranteed bit rate will still not be reached. This will lead to the decrease in user experience.

The differentiated service based on SPI weight can provide the different service perception for all online users. When there are spare system resources after the GBR requirement for all online users is fulfilled, the high priority users will have preferential right to get the spare system resources. When the GBR requirement can not be fulfilled for all online users, the system resources requirement of the high priority users will be guaranteed with high priority. If this kind of mechanism is unavailable, the throughput of all online users will be decreased, and the advantages of high priority users cannot be fully implemented.

Enhancement None

Dependency This feature enhances the HSPA scheduling and flow control algorithms.





16 Intra-RAT Mobility Management Solution

16.1 WRFD-020302 Inter Frequency Hard Handover Based on Coverage



Summary This feature is related to inter-frequency hard handover based on coverage.

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.

l Coverage-based 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 related measurement quantity can be either Ec/N0 or RSCP or 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 including threshold, hysteresis, and trigger delay time, etc. The inter-frequency neighboring cell number can be up to 32. 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 configurable parameter “Blind Handover Priority” in the neighboring inter frequency cells. This parameter indicates the handover success rate can be guaranteed, and its value is determined after network planning. Inter-frequency handover triggered by limitation of UE Tx power is available for PS BE, CS AMR and VP services. Inter frequency hard handover based on coverage is also applied to hierarchical cell structure.

l Load-based This trigger condition is based on the cell load, and belongs to the optional feature which is described in WRFD-020103 Inter Frequency Load Balance.

l Speed-based This trigger condition is based on the UE speed which is evaluated by RNC, and such feature is the optional feature which described in WRFD-021200 HCS (Hierarchical Cell Structure). 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 RN5.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 is applicable to the PS BE, CS AMR, and VP services.



Dependency The UE should support the relevant measurements and the procedure of handover.

16.2 WRFD-020304 Inter Frequency Hard Handover Based on DL QoS



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-RAT cell, thus 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:

l For AMR and VP services, inter-frequency handover could be triggered based on TCP. l 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 None.



16.3 WRFD-020605 SRNS Relocation Introduction Package



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 l Reduce the bandwidth occupied by the Iur interface. l Reduce the transmission delay of user plane. l Get the parameters of cell-level algorithms to optimize the performances. l Ensure that communications are not interrupted when the UE moves to the coverage area

of another RNC while the Iur interface is not available. l 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:

l SRNS Relocation (UE Not Involved) l SRNS Relocation with Hard Handover l SRNS Relocation with Cell/URA Update l Lossless SRNS Relocation

Enhancement In RAN3.0, RAN5.0 SRNS Relocation Introduction Package is enhanced. For details, please refer to the enhancement of the features in the package.


The CN node must support this feature simultaneously.

The SRNC and DRNC must support this feature simultaneously.



16.3.1 WRFD-02060501 SRNS Relocation (UE Not Involved)


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 l Reduce the bandwidth occupied by the Iur interface l Reduce the transmission delay of user plane l Obtain the parameters of cell-level algorithms to optimize the performances

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:

l 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.

l SRNS relocation based on transmission optimization The SRNC calculates the bandwidth occupancy on the Iur interface. You can set the threshold through the MML commands. If the occupancy exceeds the threshold, the SRNC initiates SRNS relocation. When the SRNS relocation is complete, the occupancy becomes lower than the threshold or there is no UE to be relocated.

l 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.

l 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.




WRFD-020605 SRNS Relocation Introduction Package


The CN node must support this feature.

16.3.2 WRFD-02060502 SRNS Relocation with Hard Handover


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:

l Inter-frequency or intra-frequency hard handover is performed. l The target cell and the source cell belong to different RNCs. l 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.




The SRNC and the DRNC must support this feature simultaneously.



16.3.3 WRFD-02060503 SRNS Relocation with Cell/URA Update


Summary When the Iur interface 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 The SRNS relocation with cell update occurs when all the following conditions are met:

l The cell update procedure is performed. l The target cell and the source cell belong to different RNCs. l There is the Iur interface between two RNCs.

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



16.3.4 WRFD-02060504 Lossless SRNS Relocation


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, thus 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.





17 Inter-RAT Mobility Management Solution

17.1 WRFD-020303 Inter-RAT Handover Based on Coverage



Summary This feature is related to inter-RAT handover based on coverage that is a basic function of interoperability.

Benefits Inter-RAT handover improves flexibility in planning UMTS and GSM networks for the network operator. It can also save cost by utilizing the existing GSM network resources and provide coverage expansion, load sharing, and layered service.

Enhancement of inter-RAT handover between multi frequency band cells can be used to support multi frequency band networking scenario.

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 applies to the CS services and can be triggered by the following causes:

l Coverage-based



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, etc. 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.

l Load-based This trigger condition is based on the cell load, and belongs to the optional feature WRFD-020306 Inter-RAT Handover Based on Load.

l Service-based This trigger condition is based on the service assigned by CN node, and belongs to the optional feature WRFD-020305 Inter-RAT Handover Based on Service.

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.

In multi frequency band networking scenario which is described in WRFD-020110 Multi Frequency Band Networking Management, the inter-RAT handover is enhanced to meet the networking requirements. That is, coverage based handover between different frequency band is supported and UE measurement capability will be considered to guarantee UE will not be handed over to the cell which UE has no the corresponding capability on that frequency band. When no enough UE capability can be acquired, whether to implement the handover can be configured by operator.

Since the GSM/GPRS system can’t 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 is available for PS BE and CS AMR services.


The UE should support the relevant measurements and the procedure of handover

17.2 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, thus 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:

l For AMR service, inter-RAT handover could be triggered based on TCP; l 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.


The UE should support related measurement and handover procedures.

17.3 WRFD-020307 Video Telephony Fallback to Speech (AMR) for Inter-RAT HO



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. But 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:

l Fallback: multi-media service fall back to speech during the setup procedure l 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.

l 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.

l 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.


WRFD-020303 Inter-RAT Handover Based on Coverage

or WRFD-020305 Inter-RAT Handover Based on Service

or WRFD-020306 Inter-RAT Handover Based on Load

or WRFD-021200 HCS (Hierarchical Cell Structure)


The MSC and UE need to be compliant with 3GPP Release 6 to support the feature.



17.4 WRFD-020308 Inter-RAT Handover Phase 2



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:

l NACC (Network Assisted Cell Change) l 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.


WRFD-020303 Inter-RAT Handover Based on Coverage

or WRFD-020305 Inter-RAT Handover Based on Service




BSC should support NACC RIM (RAN Information Management) and PS handover procedure.

17.4.1 WRFD-02030801 NACC (Network Assisted Cell Change)

Availability This feature is available from RAN6.1 (BSC6810 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.


WRFD-020308 PS Inter-RAT Handover Phase 2.

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 )



17.4.2 WRFD-02030802 PS Handover between UMTS and GPRS


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.


WRFD-020308 PS Inter-RAT Handover Phase 2.



18 Load Control and Performance Enhancement

18.1 WRFD-020103 Inter-Frequency Load Balance


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, thus reducing the load of the cell.

Benefits This feature is used to reduce the system load by handing over UE to neighbor cells, thus 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 blind handover that hands over UE to an inter-frequency neighbor 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 includes the power resource, Iub transmission resource and Node CE resource, if inter frequency load balance is taken as an action for LDR. The load measure 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.


This feature can also be applied to HSDPA and HSUPA load control which requires the optional features WRFD-010610 HSDPA Introduction Package and WRFD-010612 HSUPA Introduction Package.

18.2 WRFD-020305 Inter-RAT Handover Based on Service



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.




The CN support should be needed for the kind of condition in which the indicator is forwarded from the CN.

18.3 WRFD-020306 Inter-RAT Handover Based on Load


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, thus 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 cell is entering into a basic congestion state. Normally the resource used for cell load level measurement includes the power resource, Iub transport resource and Node 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 firstly.

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.


This feature can also be applied to HSDPA and HSUPA load control which requires the optional features WRFD-010610 HSDPA Introduction Package and WRFD-010612 HSUPA Introduction Package.



18.4 WRFD-020400 DRD Introduction Package



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:

l Intra System Direct Retry l Inter System Direct Retry l Inter System Redirect

Enhancement None.

Dependency None.

18.4.1 WRFD-02040001 Intra System Direct Retry


Summary This feature is related to intra-system direct retry during the RRC 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 to 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 neighbor cell. This decision is done according to the configuration of interfrequency blind neighbor 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 neighbor cell or inter-RAT cell (WRFD-020101). In order to increase the blind handover success rate, the neighbor inter-frequency or inter-RAT neighbor cell shall have the same coverage.

Enhancement None.



18.4.2 WRFD-02040002 Inter System Direct Retry


Summary This feature is related to inter-system direct retry during the RRC or 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.





18.4.3 WRFD-02040003 Inter System Redirect


Summary This feature is related to inter-system redirect during the RRC or RAB 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.



18.5 WRFD-021102 Cell Barring




Summary When a cell is abnormal, this feature enables the operator to automatically or manually bar the cell.

Benefits l When the Iu interface is disconnected, this feature can prevent the UE from initiating

useless access requests and ensure that 3G UEs are handed over to the 2G network. l This feature can provide flexibility for the operator in some scenarios (for example,

maintenance).

Description It is in SIB 3/4 to indicate whether the cell is barred or not. When cell status "barred" is indicated, the UE is not permitted to select/re-select this cell, not even for emergency calls.

The cell can be barred or unbarred manually and automatically.

l Manual operation. The operator can bar/unbar the cell by the MML commands. And then RNC will update the system information of this cell to indicate UE the change;

l Automatic operation. In cases of Iu breakdown, the RNC keeps providing coverage (but not service) to the UEs under its control. This means that several UEs are kept in 3G coverage, but, actually, they cannot access the network. In this case, RNC bars the cell automatically. If the Iu-CS breaks down, the RNC will bar the Iu-CS domain service for the cell; if the Iu-PS breaks down, the RNC will bar the Iu-PS domain service for the cell.

Therefore, UE can perform a re-selection towards the underlying GSM layer; when Iu-CS recovers, the RNC will unbar the cell.

Enhancement In RAN 10.0, the RNC can sequentially bar one of the cells under its control every TimeCellBarring seconds (with TimeCellBarring configurable by the operator).

Dependency None.

18.6 WRFD-020310 3G/2G Common Load Management



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 l Decrease the probability of 2G system overload or congestion due to inter-RAT handover

from 3G to 2G based on service or load. l Avoid 3G system overload due to inter-RAT handover from 2G to 3G. l 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.


WRFD-020305 Inter-RAT Handover Based on Service



or WRFD-020400 DRD Introduction Package

or WRFD-020308 Inter-RAT Handover Phase 2


The CN and BSS should support this feature.



18.7 WRFD-010506 RAB Quality of Service Renegotiation over Iu Interface



Summary This feature enables the RNC to initiate a renegotiation request on the Iu interface for the MBR and GBR of PS real-time services to decrease the rate of real-time services.

Benefits This feature enables operator to reduce the cell load by downgrade real-time service bit rate.

Description RAB Quality of Service Renegotiation over Iu interface is an action for R99 real-time service during the LDR (Load Reshuffling) procedure to reduce the system load. When the usage of cell resource exceeds a basic congestion trigger threshold, the RNC will perform load control algorithm, including the Load Reshuffling (LDR) (WRFD-020106) and Overload control (OLC) (WRFD-020107). Usually, several actions will be taken to relieve the congestion status according to the service type.

Real-time service cannot perform rate down-switch automatically like best effort service due to the QoS requirement. That is, Guarantee Bit Rate (GBR) is specified in RAB assignment procedure and must be guaranteed. When the system needs to adjust real-time service rate to relieve the system load, the RNC has to initiate a rate renegotiation over the Iu interface by requesting a new RAB parameters with a lower bit rate for real time service via RAB Modification procedure.

The RNC will request a new Max Bit rate, Guaranteed Bit rate which are the lowest ones among the alternative configurations in the RAB ASSIGNMENT message from the CN. And it is up to the CN to decide how to react to the request upon reception of the RAB MODIFY REQUEST message.

Whether to implement this feature and the action sequence in LDR can be configured as required.

Enhancement None.


The core NEs should support selective configuration for MBR and GBR.



18.8 WRFD-010507 Rate Negotiation at Admission Control



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

l Iu QoS negotiation l 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.

l 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.

l 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.

l Maximum bit rate negotiation 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.

l 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.


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.

18.9 WRFD-020120 Service Steering and Load Sharing in RRC Connection Setup


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.



18.10 WRFD-020123 TCP Accelerator


Summary A series of enhanced TCP functions are implemented on the RNC and the functions properly adapt to the link characteristics on the RAN side. This feature enables the performance of the TCP protocol derived from a wired network to be greatly improved, thus improving user perception and system efficiency.

Benefits This feature can prevent the factors such as packet loss on the RAN side from affecting DL TCP data transmission, accelerate the slow startup and fast retransmission of the server during the DL data transmission, and greatly reduce the effect of the delay on the wired-network side on the performance of TCP data transmission during the DL data transmission. In addition, the UL data buffer sorting technology is used to optimize the performance of UL TCP data transmission, and the DL transmission rate is increased in simultaneous DL and UL data transmission scenarios. This feature can improve the performance of PS data transmission.

Description Currently, the TCP/IP protocols of the Internet are developed and designed for wired transmission, whereas with their introduction into the wireless system, the TCP/IP data transmission is not very compatible with the wireless system because of the high error bit rate, long delay, and environmental fluctuation of wireless communications.

Downlink TCP Accelerator is implemented in the RNC. The TCP 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 the TCP performance optimization technologies such as downlink data buffer sorting, ACK splitting, DupACK duplication, building WS (Window Scaling) indication, enhanced simultaneous downloading / uploading and local retransmission.

l ACK splitting



In TCP, the congestion window is updated according to the number of received ACKs and is expanded by increasing the number of ACKs. When the transmitting end incurs slow-start, ACK splitting can quickly recover the congestion window; when the transmitting end incurs congestion avoidance, ACK splitting can also accelerate the expansion of the congestion window.

l DupACK duplication Through TCP, three DupACK retransmission loss packets can be received. After the TPE receives the ACK from the UE, the TPE immediately duplicates three DupACKs and sends them to the Server if it detects that the packets requested by the ACK is not in the buffer. This shortens the time for packet retransmission.

l Local retransmission When packet loss occurs on the air interface, the TPE performs local retransmission to the receiving end instead of the transmitting end, thus reducing the time for retransmission.

l Packet sorting Handling the disordered DL packets The TPC 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. Handling the disordered UL packets The TPC sorts the UL data packets and transmits them to the CN in order. This avoids the deterioration of transmission performance caused by normally disordered UL packets.

l Building WS indication When TCP window size in server side is 64K, the synchronization packet will not include WS indication. And if receiving side detects that there is no WS indication, the response synchronization packet created by receiving side will not include WS indication, no matter whether the window size is bigger than 64K. In this scenario, the peak throughput will be limited if the receiver window size is 128K. With this feature, window size can be up to the biggest value. And system could provide higher peak rate.

l Enhanced simultaneous downloading and uploading In the case of simultaneous downloading and uploading files, in the uplink, UE needs to send data and TCP ACK/NACK information corresponding to downlink data. However, TCP ACK/NACK information may be blocked by uplink service data so that TCP ACK information of downlink data is delayed, which could influence downlink throughput. This feature can build ACK information initiatively. Then, the server TCP can slide more quickly and the downlink throughput will be increased.

Enhancement None.

Dependency None.



18.11 WRFD-020124 Uplink Flow Control of User Plane


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 Node B 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 None.



19 Cell Broadcast Service

19.1 WRFD-011000 Cell Broadcast Service



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 Centre. 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 The UE should have the capability to receive cell broadcast messages.



20 TFO/TrFO

20.1 WRFD-011600 TFO/TrFO



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.




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



21 Dynamic Power Sharing of Multi-Carriers

21.1 WRFD-020116 Dynamic Power Sharing of Multi-Carriers


Summary This feature enables power sharing between carriers to improve the utilization of power resources. In RAN11.0, the Node B allows the carrier carrying HSDPA services to share the unused power resources of another carrier carrying R99 services.

Benefits This feature can improve 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.

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 None.



22 Green Node B Solution

22.1 WRFD-020117 Multi-Carrier Switch off Based on Traffic Load


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 Node B.

Benefits This feature optimizes the energy-efficiency by disabling the idle carriers; this feature brings the following benefits:

l Reduce the negative impact on environment l 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 Node B 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 None.

22.2 WRFD-020118 Energy Efficiency Improved


Summary Huawei RF module can adjust the transmit power based on traffic volume to save the energy. Different transmit powers of the power amplifier result in different levels of efficiency. To enable the power amplifier to work effectively, Huawei launches the energy efficiency improved solution.

Benefits With the operation efficiency of the power amplifier improved, this feature can save operation costs for the operator and reduce the negative effect of the equipment on the environment.

Description It is environment-friendly and economical to reduce the power consumption of equipment. With the reduction in power consumption, the operation costs, the requirements for basic power supply and heat dissipation of equipment, and the difficulty in parts selection decrease accordingly. This greatly improves the reliability of equipment.

Huawei provides operators with various effective power consumption solutions, among which the key solution is to reduce the power consumption of the Power Amplifier (PA).

The RF module adopts the Digital Pre-Distortion (DPD) and X-Power technologies. The power efficiency of the PA reaches 40%, which reduces the power consumption of the entire Node B.

To improve the power efficiency in low traffic load, Huawei Node B supports the technology of dynamically adjusting the PA parameters. The PA dynamically adjusts the parameters according to different output power to reduce power consumption in low traffic load scenario, such as midnight.

RAN11.0 support PA parameters dynamically adjusting when no HSDPA service is in use. When HSDPA service is in use, the PA will reject PA parameters adjusting.

Enhancement None.




Only WRFU and RRU3804 support this feature.



23 AMR-WB (Adaptive Multi Rate Wide Band)

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



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.

The AMR-WB can be used for transporting music signals and other non-speech signals. The AMR-WB Codec performance with music signals is satisfactory at the highest bit rate of 23.85 kbit/s. For music signals, this mode is generally acceptable for all customers.

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






Codec Mode Source Codec BitRate


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.


The CN node and UE must have the corresponding support capability.

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



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. Thus, 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 6.60 kbit/s, 8.85 kbit/s, 12.65 kbit/s, 15.85 kbit/s, and 23.85 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 Node B Common Measurement (TCP, Transmitted Carrier Power) for DL, and Node B Common Measurement (RTWP) for UL, exceed the LCR 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).


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

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


The UE should support the processing of TFC control procedure.



24 Overbooking on ATM Transmission

24.1 WRFD-050405 Overbooking on ATM Transmission


Summary This feature can improve the usage efficiency in ATM transmission scenarios.

Benefits This feature provides a method for greatly saving OPEX on ATM transmission, especially on 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:

l Overbooking on Call Admission Control and basic congestion control l 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 active factor of each service type. Such active 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 thus 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:



l 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.

l 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.

l 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.

l 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.

l 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.

According to this mechanism, the ATM interface boards (BSC6800 WOSEc and BSC6810 AOUa/UOIa/AEUa) should be installed on the RNC and the Iub connections to the Node B should be configured through the optical port or electrical port.

This mechanism requests each Node B to be connected to RNC directly through ATM interface board. It is not applied for Hub Node B transmission.

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.


The backpressure and VP shaping mechanism especially requests ATM interface board (WOSEc board for BSC6800 & AOUa/UOIa/AEUa boards for BSC6810) to be installed in the RNC and the Iub connection to Node B shall be configured through the optical or electrical port.



25 VoIP over HSPA/HSPA+

25.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/HSPA+ enables the introduction of IP voice services to the mobile network and the application of HSPA/HSPA+ on the Uu interface instead of on the DCH. Compared with traditional CS voice services, this solution has lower cost and charge, higher capacity, and more flexible services.

Benefits VoIP over HSPA and HSPA+ can bring the following benefits:

l All IP network evolution and decrease in the investment and operational cost l Larger voice capacity l More flexible and rich IP services

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 operational cost accordingly.

In the WCDMA system, VoIP can provide low cost voice services compared with the traditional CS service, and on the other hand, VoIP facilitates the implementation of services like real-time video sharing or instant messaging because they are all carried on the PS domain. This also brings benefits for end users.

The VoIP service can be carried on the DCH or HSPA. When the service is set up on the DCH, the capacity is not competitive because of more resource consumption. Therefore, VoIP over HSPA is a better solution. Moreover, Robust Header Compression (RoHC) should also be supported to improve the overhead efficiency. In addition, HSPA+ CPC further improves the VoIP capacity.

Comparing with traditional CS call over DCH, the capacity gain due to VoIP over HSPA (HSUPA with 2ms TTI) is expected up to 20%. With CPC, the capacity gain of VoIP over HSPA (HSUPA with 2ms TTI) is expected up to 45%.



Enhancement None.





This feature depends on UE capability and IMS system.

25.1.1 WRFD-01061701 RAB Mapping


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:

l 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

l 2PS + 1CS l 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.

l 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.

l "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.





The CN and UE should support VoIP.

25.1.2 WRFD-01061703 Optimized Scheduling for VoIP over HSPA


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 the user experience when VoIP over HSDPA 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.





The CN and UE should support VoIP.

25.2 WRFD-010618 IMS Signaling over HSPA





Summary IMS signaling over HSPA can shorten the setup delay of IMS services like VoIP to save network resources for the operator.

Benefits l 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. l 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.





The CN should support the signaling indication over Iu interface.

25.3 WRFD-011501 PDCP Header Compression (RoHC)





Summary PDCP header compression (RoHC) mainly applies to VoIP services and it can decrease the overhead of IP data.

Benefits l Decrease the IP data overhead greatly from more than 60% to 10%. l 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:

l The multimedia payload is typically compressed at the application layer. l The headers occupy a large portion of the packet for some services. l 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:

l RoHC Uncompressed l RoHC RTP: RTP/UDP/IP header l RoHC UDP: UDP/IP header l 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.





26 CS Voice over HSPA/HSPA+

26.1 WRFD-010619 CS Voice over HSPA/HSPA+



Summary With CS voice services carried over HSPA/HSPA+, this feature can improve the capacity of voice services per cell.

Benefits The use of the high spectral efficiency and capacity enhancement features of the HSPA and HSPA+ technologies increases the capacity of the CS voice service. This will increase the call time of UEs compared with the voice service on the R99 DCH. Compared with VoIP, CS voice over HSPA/HSPA+ does not require the support of the IP multimedia subsystem (IMS) and its implementation is easier.

Description Generally, Circuit Switched Voice is carried on DCH. In 3GPP Release 8, Circuit Switched Voice over HSPA (CS Voice over HSPA) is introduced. That is, the UL CS voice is carried on E-DCH and the DL CS voice is carried on HS-DSCH.

Basically, CS voice over HSPA takes the ordinary mobile circuit voice service, using ordinary dialers on the phone, and circuit core switches in the network. Therefore, it’s not necessary for the operator to have IMS deployed already. The different traffic flow paths between CS voice over HSPA and VoIP over HSPA are shown as below.



To deploy CS Voice over HSPA, only the RNC needs to be updated for mapping CS service to HSPA. There is no impact for MSC and Node B.

Not only is the frequency efficiency and cell capacity improved by introducing HSPA technology for CS Voice, but the user will also have better talk time because of the application of the DTX/DRX technology in HSPA+.

Compared with traditional CS call over DCH, the capacity gain due to CS over HSPA (HSUPA with 2ms TTI) is expected up to 23%. With CPC, the capacity gain of CS over HSPA (HSUPA with 2ms TTI) is expected up to 48%.

Enhancement None.


CS over HSPA depend on WRFD-010610 HSDPA Introduction Package and WRFD-010612 HSUPA Introduction Package

CS over HSPA+ depend on WRFD-010686 CPC - DTX / DRX


The UE must be capable of CS voice over HSPA.



27 Positioning Service

27.1 WRFD-020801 Cell ID + RTT Function Based LCS



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

UE1 NodeB NodeB

NodeB

TOA= (RTT-UeRxTx)/2

UE2

UE selection the best cell for location reference when UE in soft handover state



The TOA can be derived by the Node B RTT (Round Trip Time) measurement and the UE Rx-Tx time difference Type 2 measurement.

N odeB

U E

R TT M easurem ent

U E R x-Tx tim e d ifference Type2 M easurem ent

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:

l The RNC asks all cells in the active set to perform the RTT measurement. l 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 the different RNC, the location over Iur is supported.

Enhancement Location over Iur interface is supported in RAN5.1.


The CN and UE should support this feature.

27.2 WRFD-020802 OTDOA Based LCS





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 Node Bs, which are installed 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 Node B and relative Rx-Tx time difference measurements from UE.

Enhancement None.


The corresponding Node Bs should be equipped with GPS card.



27.3 WRFD-020803 A-GPS Based LCS



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, DGPS data, etc, 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 locates in the different RNC, the location over Iur is supported.

Enhancement

RAN5.1 supports the positioning through the Iur interface.

Enhancement None.


If GPS receiver is located at RNC, BSC6800 should add GPS module. BSC6810 needs clock board such as GCGa to support this feature..


If GPS receiver is located at Node B, GPS module is required to support this feature.



27.4 WRFD-020804 LCS Classified Zones



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 changes, 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.


The CN must support this feature.

27.5 WRFD-020805 LCS over Iur



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.

l 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.

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.

DS-RTx .

SRNC

Site 2

Site 1

DRNC

MSC

DRNC SRNC DEDICATED MEASUREMENT INITIATION REQUEST

(Measurement Type: RTT)

DEDICATED MEASUREMENT INITIATION RESPONSE

DEDICATED MEASUREMENT REPORT

(Measurement Value: RTT)



l 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.

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.

RNC 2 RNC 1

INFORMATION EXCHANGE INITIATION REQUEST

(Information Type: GPS Information)

INFORMATION EXCHANGE INITIATION RESPONSE

INFORMATION REPORT

DRNC SRNC

INFORMATION EXCHANGE INITIATION REQUEST (Information Type: UTRAN Access Point Position)


(Geographical Coordinates)



Enhancement None.


WRFD-020801 Cell ID + RTT Function Based LCS

or WRFD-020803 A-GPS Based LCS


The neighboring RNC should support the information exchanging and related procedures.

DRNC SRNC

INFORMATION EXCHANGE INITIATION REQUEST (Information Type: UTRAN Access Point Position)




28 RAN Sharing

28.1 WRFD-021304 RAN Sharing Introduction Package


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 (i.e. access related CPEX). As shown in Figure 2, approximately 70% of the CPEX involves acquiring the sites, access equipment, civil works (i.e. 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 thus 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, Node Bs, Sites, transmissions. 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 ACN

Macro Node B

Iubinterface

Operator BCN

Shared RAN

RRU

Operator B OSSOperator A OSS

iManagerTM M2000

Shared Master OSS

Itf-NIu interface

RNC

Operator ACN

Macro Node B

Iubinterface

Operator BCN

Shared RAN

RRU

Operator B OSSOperator B OSSOperator A OSSOperator A OSS

iManagerTM M2000

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 Node B/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 This feature cannot be used with WRFD-021311 MOCN Introduction Package at the same time.

28.1.1 WRFD-02130401 Dedicated Carrier for Each Operator


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, i.e. 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.

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, i.e. unique PLMN code (composed by MCC and MNC) is broadcasted via system information within each operator’s dedicated cells.

Enhancement None.

Dependency None.



28.1.2 WRFD-02130402 Flexible Network Architecture


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.

l 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.

l Iu-BC interface To the shared RNC, maximum 4 CBCs can be connected, i.e. 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.

l Iub interface In the shared RAN, RAN elements could be shared by multiple operators, including RNC and Node Bs. But there might be the case that shared Node Bs and non-shared Node Bs coexist. In this RAN sharing solution, both shared and non-shared Node Bs are allowed to connect to the shared RNC. See the following figure.

l 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 None.

Shared RNC

CBC-B Operator B

Operator A CBC-A

SAs of Operator A

SAs of Operator B

Operator B

Operator A

Shared RNC

Shared by Operator A & B

Shared by Operator A & B



28.1.3 WRFD-02130403 Mobility Control and Service Differentiation


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 l 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, etc.) 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.

l 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, i.e. 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 stand alone CBS equipment, differentiated and independent service provision is also achievable.

Shared RNC

Operator A CN

Operator B CN

Target CN network Originated Cell



l 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, i.e. operator dedicated cells. Furthermore, differentiated and independent MBMS service provision is also achievable.

l Mobility control 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 None.

28.1.4 WRFD-02130404 Independent License Control


Summary With this feature, operators can have their independent capacity and choose optional features, thus 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.

Shared RNC

MBMS SAs of Operator A

MBMS SAs of Operator B

BM-SC SGSN Operator A

BM-SC SGSN Operator B



Description License control refers to the control of the capacity (Erlang 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. All the optional features are fully controlled separately. 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 None.

28.1.5 WRFD-02130405 Independent Cell-level FM/PM/CM


Summary With this feature, operators can monitor and maintain their own cells.

Benefits Providing Independent Cell-level FM/PM/CM

Description l 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 (i.e., alarm handling operations, setting operations, etc.), 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, i.e., the alarms dedicated to one operator.

l 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 (i.e., job management operations, threshold setting operations, etc.), 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, i.e., 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 Node B CE utilization, cell traffic throughput, etc. RAN also supports non cell-level measurement, which is shared by operators. Items are RNC/Node B utilization, PA utilization and Iub capacity & throughput, etc.

l 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 None.

28.1.6 WRFD-02130406 Transmission Resource Sharing on Iub/Iur Interface


Summary With this feature, operators can share Iub 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.

l Iub interface, The Iub interface is composed of Node B control port (NCP), CCPs, ALCAP link (not applicable for IP transmission), OM path, and a number of user plan links. For each Node B, 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 Node B. Shared OM path for one Node B is also proposed, because the



Node B 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.

l 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 None.

28.2 WRFD-021305 RAN Sharing Phase 2


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, i.e. shared transmission resource in Iub is still applicable.

Enhancement None.




WRFD-021304 RAN Sharing Introduction Package

28.2.1 WRFD-02130501 Dedicated Iub Transmission Control


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. But 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

NCP bandwidth CCPs bandwidth ALCAP bandwidth O&M bandwidth

User plane bandwidth

Could be dedicated or shared

Must be shared



GROUP-A

GROUP-B

Physical Link

II. Case 2

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.

l 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.

l 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.

l 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 None.


WRFD-021304 RAN Sharing Introduction Package



28.3 WRFD-021303 IMSI Based Handover


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.

l The SNA that an LA belongs to l 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:

l RRC Establishment l Cell Update l URA Update l Handover l Relocation l Handling Common ID

Enhancement None.

Dependency The CN node is not required to support the feature "WRFD-021301 Shared Network Support in Connected Mode". If the Iur interface is involved, the RNC in connected mode should support this feature.



29 MOCN Introduction

29.1 WRFD-021311 MOCN Introduction Package


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 Node B, 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. Thus one optional feature needs be bought by all the customers before it is available.

MOCN introduction package has the following features:

l Common carriers shared by operators l Dedicated Node B or cell for operators l MOCN mobility management l MOCN load balancing l MOCN independent performance management

Enhancement None.


The CN and UE should support the MOCN function.

This feature cannot be used with WRFD-021304 RAN Sharing Introduction Package at the same time.

29.1.1 WRFD-02131101 Carrier Sharing Among Operators


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:

l 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.

l 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.

l 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.


WRFD-021311 MOCN Introduction Package



29.1.2 WRFD-02131102 Dedicated Node B/Cell for Operators


Summary This feature enables operators to independently control a Node B or cell in MOCN scenarios.

Benefits Through dedicated Node Bs/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 Node B of multiple operators (known as MOCN Node B), but also connect to a dedicated Node B, namely, non-shared Node B which serves one operator only, as shown below:

The dedicated Node B belongs to Operator A only; therefore, all the UEs that access the network from this Node B will be connected to the CN node of Operator A.

For MOCN Node B, some cells of the shared Node B can be dedicated to one operator and serve this operator only. The RNC supports the dedicated cell for an operator.

Enhancement None.





29.1.3 WRFD-02131103 MOCN Mobility Management


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, thus 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.



29.1.4 WRFD-02131104 MOCN Load Balance


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 thus guarantees the load balance between operators.

Enhancement None.



29.1.5 WRFD-02131105 MOCN Independent Performance Management


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.



30 Iu Flex

30.1 WRFD-021302 Iu Flex



Summary This feature allows one physical RNC to be connected to multiple MSCs and/or SGSNs, and these CS/PS domain nodes can form different pools that serve the same pool area.

Benefits Iu Flex greatly enhances the serviceability of the whole network including:

l Enhancing the flexibility of the Iu interface l Increasing the total capacity of CN nodes l Enhancing the disaster tolerance capability of CN nodes l Reducing the signaling traffic of the CN l Enhancing the system utilization

In conclusion, the Iu Flex greatly enhances the serviceability of the whole network.



Description This function allows one physical RNC to connect to multiple MSCs and/or SGSNs, and these CS/PS domain nodes can form different pools which serves the same pool area. The pool area has the following characteristics:

l A pool area is a collection of one or more MSC or SGSN serving areas. l A pool area is served by one or more CN nodes in parallel that share the traffic of this

area between each other. l The pool areas may overlap. The RAN Node belongs to all the overlapping pool areas. l In one pool area, the UE roams without needing to change the serving CN node. l 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

RANnode

Area 5

RANnode

Area 6

RANnode

Area 7

RANnode

Area 8

RANnode

Area 2

RANnode

Area 3

RANnode

Area 4

RANnode

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 5SGSN 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:

l The UE preferentially encodes the route information identified by the TMSI or P-TMSI. l 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. l 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:

l 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.

l 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.

l 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 relation 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 can not 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.


Require MSC or SGSN support such feature at the same time.

30.2 WRFD-021306 Iu Flex Load Distribution Management


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.

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:

l 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.

l New counters related to load balancing are added. l CN node status is reported to M2000 when the CN node status is changed.


WRFD-021302 Iu Flex



31 Multi Frequency Band Networking Management

31.1 WRFD-020110 Multi Frequency Band Networking Management


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. So, 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:

l Reuse of the existing base station sites l 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, Node B receive

DL frequencies UE receive, Node B 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:

l Cell selection / reselection l 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 (e.g. 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.

l 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.

l 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.

l Service based handover: Such feature depends on the optional feature WRFD-020305 Inter-RAT Handover Based on Service

l 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 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)

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.



32 Satellite Transmission

32.1 WRFD-050104 Satellite Transmission on Iub Interface


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. These related parameters are configurable to meet satellite transmission requirements.

Enhancement None.

Dependency None.



33 MBMS and Enhanced MBMS

33.1 WRFD-010616 MBMS Introduction Package



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:

l Broadcast mode; l Multicast mode.

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

GGSNTPF

BM -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:

l Some new signaling procedures are added on the Iub/Uu/Iur/Iu interface. l New physical channels (MICH) are added. l New logical channels (MCCH/MTCH/MSCH) are added. l MAC-c/sh is changed to MAC-c/sh/m in order to add the MAC-m to the MBMS. l 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 BSC6810 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, please refer to the enhancements of the features in the package.


l The existing PS Domain functional entities (GGSN, SGSN, UTRAN, GERAN and UE) need to be enhanced to provide the MBMS bearer service.

l A new functional entity, that is, the broadcast multicast service centre (BM-SC) is added to provide a set of functions for the MBMS users Services.

l The UE should support MBMS functions.



33.1.1 WRFD-01061601 MBMS Broadcast Mode


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:

l Broadcast mode l 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.


WRFD-010616 MBMS Introduction Package



33.1.2 WRFD-01061602 MBMS Admission Control


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:

l Cell available code resources l Cell available power resources l Node B resource state, that is, Node B credits l 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.

l When there is enough power resources in the cell, the upper power level will be used; l 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;

l 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.



33.1.3 WRFD-01061603 MBMS Load Control




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:

l 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;

l 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.

l 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.



33.1.4 WRFD-01061604 MBMS Soft/Selective Combination


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.



33.1.5 WRFD-01061605 MBMS Transport Resource Management


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 Node B, a separate Iub transport bearer is established for each cell. An example is shown in the following figure assuming 3 cells in one Node B. Three copies of exact same MBMS session data are sent through the Iub from the CRNC to the Node B.



CRNC Node B

MBMS stream

CN

Iub transport bearers

Enhancement None.



33.1.6 WRFD-01061606 Streaming Service on MBMS


Summary This feature enables the MBMS service to be carried on the PS streaming class, thus 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:

l For the traffic class, only the background and streaming classes can be supported; l For the SDU error ratio, only higher 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);

l 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 RAN 10.0, a maximum of 2 PTP streaming RBs for the MBMS service can be established for the UE in enhanced broadcast mode.



33.1.7 WRFD-01061607 MBMS 2 Channels per Cell


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.



33.1.8 WRFD-01061608 16/32/64/128Kbps Channel Rate on MBMS




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

Benefits The feature enables different channel rates and thus provides operators with more flexibility to deploy the MBMS services.

Description The MBMS broadcast mode service bit rate can be 64 kbit/s or 128 kbit/s. The TTI for 64 kbit/s is 80 ms and the TTI for 128 kbit/s can be 40 ms or 80 ms.

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

Dependency WRFD-010616 MBMS Introduction Package

33.2 WRFD-010660 MBMS Phase 2

Availability This feature is available from RAN 10.0.


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:

l 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.

l 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.




UE should support the corresponding enhanced MBMS functions.

33.2.1 WRFD-01066001 MBMS Enhanced Broadcast Mode


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:

l 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.

l 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.

l 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.

l 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.



33.2.2 WRFD-01066002 MBMS P2P over HSDPA


Summary This feature enables MBMS P2P services to be carried on the HS-DSCH, thus 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.





33.2.3 WRFD-01066003 MBMS Admission Enhancement


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:

l PTM streaming bearer can pre-empt other MBMS or non-MBMS services with traffic class interactive/background and less or equal ARP priority.

l PTM background bearer can pre-empt other MBMS or non-MBMS services with traffic background and less ARP priority.

l No services are allowed to pre-empt PTM with streaming traffic class. l PTP or Non-MBMS guaranteed services are allowed to pre-empt PTM with background

traffic class and lower ARP priority. l 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.

l 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 (i.e. MBMS PTP bearers or normal non-MBMS bearers).

l 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 (i.e. MBMS PTP bearers or normal non-MBMS bearers). At this moment, they can only pre-empt other low priority PTM bearers.



l 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.



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


Summary This feature enables the filtering and handover of a target cell based on the MBMS channel resources in the inter-frequency neighboring cells, thus 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.



WRFD-010660 MBMS Phase 2

33.3 WRFD-010627 FACH Transmission Sharing for MBMS


Summary This feature enables the FACH carrying the same MBMS service on the Iub interface to share a transmission resource, thus 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 Node B, 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 Node B. Three copies of exact same MBMS session data are sent via Iub from CRNC to Node B, which is a big waste of Iub bandwidth.



CRNC Node B

MBMS stream

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. Node B 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

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 Node B’s capability to share transport bearer, CRNC always sends message of bearer multiplexing request to Node B no matter whether Node B can/will share transport bearer or not. For Node B which can not or would not like to share, non-shared transmission bearer will be setup as in the original way.

Enhancement None.



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





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.





33.5 WRFD-010624 MBMS 8 Channels per Cell


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 512Kbps. 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 1,792 kbit/s. The MBMS channel bit rate can be 16, 32, 64, 128, or 256 kbit/s.





34 Enhanced MBMS

34.1 WRFD-010625 256Kbps Channel Rate on MBMS


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, 256K bps MBMS Broadcast Mode service is supported and one cell can support 4 such services. The TTI for 256K bps service is 40ms.

Enhancement In RAN 10.0, the maximum number of 256Kbps channels is enhanced from 4 to 7 per cell.



34.2 WRFD-010628 MBMS 16 Channels per Cell


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 1,792Kbps. The MBMS channel bit rate can be 16, 32, 64, 128, or 256Kbps.

Enhancement None.



34.3 WRFD-010661 MBMS over Iur



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 l 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. l When CELL_DCH UE moves into DRNC and Iur interface exists, Iur soft handover will

be triggered. l When UE moves into DRNC and Iur interface does not exist, DRNC will indicate UE to

release the RRC connection. l 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. But 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.




The neighboring RNC should support MBMS Iur function.

34.4 WRFD-010662 Dynamic Power Estimation for MTCH


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.6dB), so it’s possible to set power dynamically.

Dynamic Power Setting in PTM mode:

l If more than a certain portion (operator accessible parameter) of neighbours adopt PTM mode, the power setting for the serving cell can be decreased by a specific offset (operator accessible parameter).

l If less than a certain portion of neighbours 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.



34.5 WRFD-010663 MSCH and MSCH Scheduling


Summary This feature enables the UE to perform DRX on the MTCH based on MSCH scheduling, thus saving the power consumption of the UE.

Benefits MSCH enables the UE to perform DRX on the MTCH and thus 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.



34.6 WRFD-010665 MBMS Channel Audience Rating Statistics


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:

l Average number of users in PTP mode l Average number of users in PTM mode l Time for channels remaining in PTM mode l 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.




The BMSC on the CN side shall identify the channels with a fixed TMGI when delivering the program source.



35 Domain Specific Access Control (DSAC)

35.1 WRFD-020114 Domain Specific Access Control (DSAC)


Summary In urgent cases, for example, the CN is overloaded, this feature enables fast reduction of the load, thus 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.


Since this is a feature specified in 3GPP R6, only the UEs of R6 support this function.

DSAC is based on the CN overload message and so the CN nodes should support this message on the Iu interface.



36 One Tunnel

36.1 WRFD-020111 One Tunnel



Summary With this feature, there is only one tunnel between the RNC and GGSN.

Benefits This feature improves efficiency for PS traffic. It avoids SGSN to be the bottle neck of the network while high PS traffic occurs.

Description The specification of One-Tunnel (direct connection between RNC and GGSN) is a part of 3GPP Release 7.

In 3G packet core architecture the SGSN (Serving GPRS Support Node) which is the gateway between the radio network and the core network handles both signaling traffic (e.g. to keep track of a users location) and the actual data packets exchanged between the user and the Internet. Since the users' location can change at any time, data packets are tunneled (encapsulated) from the gateway to the Internet (The Gateway GPRS Support Node, GGSN) via the SGSN over the radio network to the mobile device. The current architecture uses a tunnel between the GGSN and the SGSN and another one between the SGSN and the Radio Network Controller (RNC). All data packets thus have to pass the SGSN which has to terminate one tunnel extract the packet and put it into another tunnel. This requires both time and processing power.

Since both the RNC and the GGSN are IP routers this process is not necessary in most circumstances. With one tunnel approach the SGSN can create a direct tunnel between the RNC and the GGSN and thus remove itself from the chain. Mobility Management remains on the SGSN, however, which means for example that it continues to be responsible to modify the tunnel in case the mobile device is moved to an area served by another RNC.

Enhancement None.




Require GGSN and SGSN support such feature at the same time.



37 Iub over IP

37.1 WRFD-050402 IP Transmission Introduction on Iub Interface



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:

l E1/T1 l FE l GE (with LAN Switch in BSC6800) l STM-1/OC-3c(POS (Packet Over SDH), BSC6810 only) l Channelized STM-1/OC-3(CPOS (Channelized POS), BSC6810 only)

Huawei Node B provides the following physical port types on Iub IP transmission solution to support different networking requirements:

l E1/T1 l Electrical FE l Optical FE ( 3900 Node B only ) l Electrical GE ( 3900 Node B only ) l Optical GE ( 3900 Node B only )



The following features are also included:

l Compliant with 3GPP R5 TR25.933 l Support GE/FE/E1/T1/channelized STM-1/channelized OC-3/STM-1/OC-3c physical

interface l Support Diffserv mechanism and IEEE802.1P l Support IPV4 l Support IP head compression l Support ML-PPP and MC-PPP, RAN11.0 Node B support ML-PPP combined two

transmission card l Support DHCP, PPP Mux and VLAN l Support 1+1 and 1:1 MSP

The following figure shows the IP networking on Iub interface.

Besides the transport layer change (e.g. M3UA, SCTP), the Iub IP brings about some changes in CAC as well as service differentiation.

NodeBNodeBRNC

E1/STM-1 E1/STM-1

RNL

UDP/SCTP

IP

PPP/HDLC

PHY PHY

RNL

UDP/SCTP

IP

PHYPHY

PPP/HDLC

SDH/PDHADM ADM

NodeBNodeBRNC

L2 NetworkFE FE

RNL

UDP/SCTP

IP

MAC(L2)

PHY

MAC(L2)

PHY

RNL

UDP/SCTP

IP

MAC(L2)

PHY

MAC(L2)

PHY

LAN Switch LAN Switch



In CAC, IP PATH is defined as the connection between RNC and Node B. Each IP PATH is configured with a maximum DL PATH bandwidth and maximum UL PATH bandwidth, which is configurable for 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

Enhancement In RAN10.0, the BSC6810 supports the POS/CPOS interface (UOIa and POUa).

RAN11.0 Node B support ML-PPP combined two transmission card.


IP head compression is supported by PEUa and POUa board.


Only the 3900 series Node B supports inter-board ML-PPP.

37.2 WRFD-050411 Fractional IP Function on Iub Interface

Availability This feature was available from RAN6.1.



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 l Sharing of transmission links between 2G and 3G systems. l Reduced initial rollout Time in market at. l Savings on transmission costs when co-site 2G and 3G

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 don’t use for IP package transmission can transmit other information.

The E1/T1 boards can be configured for using 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.


WRFD-050402 IP Transmission Introduction on Iub Interface



37.3 WRFD-050403 Hybrid Iub IP Transmission


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 maybe 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.



37.4 WRFD-050404 ATM/IP Dual Stack Node B


Summary This feature enables Huawei Node B 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 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 Node B or ATM Node B, so you can add IP Node B in the existed ATM network.

Moreover, the Node B 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:

l You can add a NUTI board to support IP transmission in a ATM Node B which has only NDTI board;

l You can upgrade Node B configuration to support IP transmission in a ATM Node B 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 Node B Transmission solution is introduced.





38 Iu/Iur over IP

38.1 WRFD-050409 IP Transmission Introduction on Iu Interface



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:

l Compliance with 3GPP R5 TR25.933 l Support IP over FE electrical interface l Support IP over GE electrical interface and GE optical interface l Support IP over STM-1/OC-3c optical interface (POS (Packet Over SDH)) (BSC6810

only) l Support IP over channelized STM-1/OC-3 optical interface(CPOS (Channelized POS))

(BSC6810 only) l Support IuCS over IP over E1/T1 physical interface (BSC6810 only) l Support Diffserv mechanism and IEEE802.1P l Support IPV4 l Support IP head compression l Support ML-PPP and MC-PPP l Support PPP Mux and VLAN l Support FE/GE 1+1 backup redundancy l Support FE/GE load share redundancy



l Support STM-1/OC-3c 1+1 and 1:1 MSP l 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 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 configured with a maximum DL PATH bandwidth and maximum UL PATH bandwidth, which is configurable by operator. When a new call is coming, RNC will compare the required service bandwidth 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).


The CN should support IP transportation.

38.2 WRFD-050410 IP Transmission Introduction on Iur Interface



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:

l Compliant with 3GPP R5 TR25.933 l Support GE/FE/E1/T1 physical interface l Support IP over FE electrical interface l Support IP over GE electrical interface and GE optical interface (BSC6810 only)



l Support IP over STM-1/OC-3c optical interface (POS (Packet Over SDH)) (BSC6810 only)

l Support IP over channelized STM-1/OC-3 optical interface(CPOS (Channelized POS)) (BSC6810 only)

l Support IP over E1/T1 physical interface (BSC6810 only) l Support Diffserv mechanism and IEEE802.1P l Support IPV4 l Support IP head compression l Support ML-PPP and MC-PPP l Support DHCP, PPP Mux and VLAN l Support FE/GE 1+1 backup redundancy l Support FE/GE load share redundancy l Support STM-1/OC-3c 1+1 and 1:1 MSP l 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 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 configured with a maximum DL PATH bandwidth and maximum UL PATH bandwidth, which is configurable by operator. When a new call is coming, RNC will compare the required service bandwidth 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.


The neighboring RNC should also support IP transportation.



39 IP Transmisson Efficiency Improvement

39.1 WRFD-050420 FP MUX for IP Transmission


Summary This feature enables the multiplexing of FP packets on the IP network to improve the transmission efficiency.

Benefits l Save IUB IP transport resource to provide higher transport efficiency for IUB IP

transport. l 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 private protocol. RNC and Node B must support this feature simultaneously. FG2a and GOUa of BSC6810, WFIE of BSC6800 and NUTI of Node B support this feature.

Enhancement None.


The FG2a and GOUa support FP MUX for BSC6810.



The FIE of the BSC6800 supports FP MUX.



39.2 WRFD-050421 IP Re-route Based on BFD/ARP


Summary When the gateway or peer entity is faulty, this feature enables the RNC to trigger IP re-route, thus avoiding packet loss and call drop.

Benefits l With BFD, the RNC could detect the failure of gateway or peer entity very rapidly and

trigger IP re-route, thereby reducing packet loss and preventing call drop. l With ARP, the RNC could detect the failure of gateway or peer entity and trigger IP

re-route, to avoid call drop.

Description The BFD (Bidirectional Failure Detection) is a method for IP connection failure detection by periodically transmitting BFD packets between two nodes. When no BFD packets are received during the detection interval, failure is declared and related recover action will be triggered, such as IP re-route, to avoid traffic drop. The interval of BFD detection is short (about 100ms), so it could be used for telecom service above IP network.

BFD includes one hop and multi-hop solution. Currently RNC only support one hop, Node B support one hop and multi-hop.

BFD could be adopted in two scenarios:

1. It could be used for the gateway availability detection when router is adopted;

Node B/CN/RNC

R1

R2

R3

R4

p1

p2

RNC



BFD is activated for p1 and p2 failure detection. When p1 is faulty, trigger IP re-route, and packets are transmitted from p2. In RAN10.0, Node B does not support BFD. RAN11.0 Node B supports BFD.

2. It could be used for peer entity availability detection when RNC is directly connected to peer device (e.g. Node B, MGW, and RNC).

BFD is activated for p1 and p2 failure detection, when p1 is fault, trigger IP re-route, and packets are transmitted from p2. In RAN10.0, Node B does not support BFD.

Address Resolution Protocol (ARP) is another method for failure detection. It could also be used to detect gateway availability or peer entity availability for the preceding two scenarios. When failure is detected, IP re-route if triggered to avoid call drop. Because MAC broadcast is used for ARP, the period for transmission ARP detection packet is usually set in seconds. Thus, the ARP detection time is larger than BFD, and the failure influence is larger than BFD accordingly.

BFD is preferred if both BFD and ARP are supported. ARP is an alternative method when there is no BFD.

Enhancement RAN11.0 Node B supports BFD, and Iub interface supports BFD.


The FG2a and GOUa of the BSC6810 support BFD and ARP.

The WFIE of the BSC6800 supports BFD and ARP.


The 3900 series Node B should support this feature.



or WRFD-050409 IP Transmission Introduction on Iu Interface

or WRFD-050410 IP Transmission Introduction on Iur Interface


Node B/CN/RNC

p1

p2



Router or peer entity should support BFD.

39.3 WRFD-050422 Dynamic Bandwidth Control of Iub IP


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. Thus, 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 private protocol. RNC and Node B must support this feature simultaneously. FG2a, GOUa of BSC6810, WFIE of BSC6800 and NUTI of Node B support this feature.

Enhancement None.


The FG2a and GOUa support this feature for BSC6810.

The WFIE supports this feature for BSC6800.


The NUTI supports this feature for Node B.



39.4 WRFD-050408 Overbooking on IP Transmission

Availability This feature was 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:

l Iub Overbooking CAC algorithm on Iub IP transmission l Fast inner loop backpressure mechanism. l 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.2Kbps 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 active factor of the service. Based on the active 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 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), 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), 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), 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 Node Bs 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 Node B side, the bandwidth for such Node B is limited by E1. Without IP shaping, RNC will transmit the traffic at the physical bandwidth of FE or GE, the throughput to the Node B 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 logic port is supported.


RNC IP interface boards (WFIE / WFEE / WEIE board for BSC6800 & PEUa / FG2a / UOIa IP/ GOUa board for BSC6810) all support backpressure mechanism. FG2a/GOUa/UOIa_IP in BSC6810 and WFIE board in BSC6800 support LP shaping.





39.5 WRFD-050412 UDP MUX for Iu-CS Transmission


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 can improve 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 can improve the Iu CS transport efficiency by 30% to 40%.

Enhancement None.


The feature requires the CS CN element (MGW) to support UDP MUX.

WRFD-050409 IP Transmission Introduction on Iu Interface.



40 ATM Switching Based Hub Node B

40.1 WRFD-050105 ATM Switching Based Hub Node B

Availability This feature was available from RAN 5.1

Summary With this feature, Huawei Node B 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 Node B extends the tree topology, as shown in the following figure.

The hub Node B is connected to the RNC through the STM-1 or E1 port. The hub Node B is connected to the cascaded Node Bs through the E1 port. The Node Bs are converged on the hub Node B 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 Node B can implement switching between PVC 1 and PVC A (Node B 1), between PVC 2 and PVC B (Node B 2), and between PVC 3 and PVC C (Node B 3). The RNC provides the group bandwidth management function to ensure that downstream Node Bs and hub Node B can share the transmission bandwidth of the Iub interface.

Physical link

Hub NodeB

Physical linkPVC 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 Node B can support four-level connections of downstream Node Bs and up to 16 downstream Node Bs.

Enhancement None.

Dependency None.



41 AAL2 Switching Based Hub Node B

41.1 WRFD-050106 AAL2 Switching Based Hub Node B


Summary With this feature, Huawei Node B 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 Node B is a feature in ATM transport mode. It is the extension of the tree topology. The hub Node B topology has two solutions: PVC convergence and AAL2 Convergence.

l AAL2 convergence, RAN6.0 supported

In order to achieve better congregation efficiency, the AAL2 convergence is introduced in RAN6.0.

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 Node Bs (Node B 1, Node B 2, and Node B 3) is converged and switched on the AAL2 path of the hub Node B. Therefore, all the Node Bs share the Iub bandwidth of the AAL2 path.

Physical link

Hub NodeB

Physical link

AAL2 Link

NodeB1

NodeB2

NodeB3PVC

PVC



The hub Node B supports connections to 4 level downstream Node Bs in AAL2 convergence mode. The hub Node B supports up to 16 downstream Node Bs.

Enhancement None.


WRFD-050105 ATM Switching Based Hub Node B



42 IP Routing Based Hub Node B

42.1 WRFD-050107 IP Routing Based Hub Node B


Summary With this feature, Huawei Node B 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 Node B is a feature in IP transport mode. It is the extension of the tree topology, as shown in the following figure. The downstream Node Bs connect to the RNC after the convergence at the hub Node B. The convergence gain is obtained from this topology.

RNC

NodeB

Hub NodeB

NodeB

NodeB

NodeB

NodeB

NodeB



The hub Node B supports connections to 2 level downstream Node Bs and provides IP routing for downstream Node Bs. The different IP path convergence at the hub Node B and multiplex the Iub bandwidth. The hub Node B supports up to 8 downstream Node Bs.

Enhancement None.


Only 3900 series Node B can support IP routing Based Hub Node B.



Only Uni BTS (DBS3900/BTS3900/BTS3900A) can support IP routing Based Hub Node B.



43 Hub Node B Based ATM QoS Management

43.1 WRFD-050406 ATM QoS Introduction on Hub Node B (Overbooking on Hub Node B 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 Node B 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 Node B transmission is applied, the RNC can be connected to more Node Bs 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 Node B, for example, Node B 3 in upper figure, congestion



may happen at Node B 2 and data will be lost accordingly. In order to avoid the possible data loss, Iub Overbooking on Hub Node B Transmission is introduced in the RNC.

Iub Overbooking on Hub Node B 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 Node B are considered as one virtual port; if one Node B is a hub Node B, all PVCs connected to it and PVCs connected to its leaf Node Bs 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.


WRFD-050405 Overbooking on ATM transmission



44 Ethernet OAM

44.1 WRFD-050425 Ethernet OAM

Availability This feature is available from RAN11.0 and is only applicable to the BSC6810.

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 l The Ethernet OAM helps the operator to manage user access in terms of detection,

monitoring, and rectification of Ethernet faults. l 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.

l This feature is implemented at the RAN equipment, thus 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, thus 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:

l 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.

l End-to-end Ethernet OAM The end-to-end Ethernet OAM complies with IEEE 802.1ag. 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.

When the RNC detects Ethernet faults or degraded network performance through the Ethernet OAM, the RNC, based on the practical configuration, can take actions such as route reselection, port switchover, and board switchover to ensure the proper communication in the Ethernet.

Enhancement 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

Dependency on RNC hardware

It is only applicable in 3900 series Node B and BSC6810.


On the Node B side, the macro Node Bs BTS3812E/AE and DBS3800 support only IEEE 802.1ag draft 7, and the 3900 series Node B supports IEEE 802.3ah and IEEE 802.1ag draft 7.



45 Clock Synchronization on Ethernet in Node B

45.1 WRFD-050501 Clock Synchronization on Ethernet in Node B


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 Node Bs 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 Node B supports Ethernet clock synchronization and obtains timing signals form the IP network. This feature provides a low-cost clock solution.

Description In ATM networking, the Node B 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 Node Bs can obtain timing signals from BITS, and TDM cannot be used in all-IP networks. Therefore, the Node Bs 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 Node Bs, which act as clock clients in this case. Because there is great delay in packet networks, Node Bs 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:

l There are clock servers and clock clients. The servers can be placed in the network independently, and the clients are integrated into the Node Bs.

l An adaptive algorithm is taken in the system. The clock servers send time stamps, and clock clients receive time stamps to restore the frequency.

l One clock server serves a maximum of 512 Node Bs. l Two or more clock servers can be used together to improve reliability. This is optional. l 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. l Frequency accuracy obtained in the Node B complies with 3GPP.

Enhancement RAN11.0 supports IEEE 1588V2.


WRFD-050402 IP Transmission Introduction on the Iub Interface


Huawei clock server should support this feature.



46 Synchronous Ethernet

46.1 WRFD-050502 Synchronous Ethernet


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 Node B 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 Node B, there is no extra synchronization equipment or hardware needed to realize synchronous Ethernet technology.



Enhancement None.


This feature is only applicable to 3900 series Node B.


WRFD-050402 IP Transmission Introduction on the Iub Interface


The synchronous Ethernet technology requires that all the equipments on the clock relay path must support the synchronous Ethernet.



47 RNC Node Redundancy

47.1 WRFD-040202 RNC Node Redundancy

Availability This feature is available from RAN11.0 and is only applicable to the BSC6810.

Summary With this feature, Node Bs 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 Node Bs 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. Thus, the quality of service is improved.

Description An RNC controls the radio resources of an RNS. If the RNC incurs faults, all the Node Bs 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 principles of the 1+1 backup mode are as follows:

Two sets of transport links are configured for the Node B. One set of links are connected to the master home RNC, and the other to the slave home RNC. (All the data related to Node Bs, cells, and neighboring cells have backup on both RNCs.) In normal cases, the master home RNC serves as the CRNC that controls the Node B. If the master RNC fails, the Node B tries to use the slave RNC as its CRNC and resumes work.



The Node B 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 relation 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 Node Bs controlled by the faulty RNC. This prevents the Node Bs from being out of service and prevents the single-point failure of RNC equipment level.

When the master RNC incurs faults, the maximum serving capability (such as Erlang of CS domain and the throughput of PS domain) decreases from the combined capability of two RNCs to the capability of one RNC. As a result, the processing specifications of the network level decreases.

Enhancement None.

Dependency None.



48 RRU Redundancy

48.1 WRFD-040203 RRU Redundancy


Summary RRU redundancy can improve the reliability and robustness of the RAN, shorten the service disruption time caused by RRU failure, and guarantee QoS.

Benefits This feature can improve 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 Node B 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 None.



49 Transmit Diversity

49.1 WRFD-010203 Transmit Diversity


Summary TX diversity enables the Node B 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.



Open loop mode Closed loop mode Physical channel type

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 TX diversity requires the Node B 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. This diversity mode has no special requirements for the RNC.



50 4-Antenna Receive Diversity

50.1 WRFD-010209 4-Antenna Receive Diversity


Summary The 4-antenna RX diversity technology enables the Node B 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 Node Bs support both RX diversity and none RX diversity. In RX diversity mode, the Node B 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 Node B 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.




In RX diversity mode, the Node B should provide sufficient RF channels and demodulation resources to meet the requirements for the number of antenna diversities.



51 Control Channel Parallel Interference Cancellation (CCPIC)

51.1 WRFD-010210 Control Channel Parallel Interference Cancellation (CCPIC)


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.




The CCPIC depends on the EBBC board or EBBI, EBOI, EULP. The BBU3900 need configure WBBPb board.



52 Extended Cell Coverage up to 200km

52.1 WRFD-021308 Extended Cell Coverage up to 200km


Summary With this feature, the operator can use less Node Bs 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 30km ~ 200km.

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 Node B BTS3812E/BTS3812AE) or HBBU (Distributed Node B DBS3800) board is used. For cell ranges above 30 km hardware dimensioning is required for RACH, i.e. one HBBI or one HBBU board per cell-carrier is needed.

In RAN10.0, new hardware WBBP (3900 Node B), EBBI (macro Node B BTS3812E/BTS3812AE) or EBBC (Distributed Node B DBS3800) board increases in cell range up to 200 km from a functional perspective. For cell ranges above 30 km, there is no impact in hardware dimensioning, i.e. one WBBPb4 can support 6 cell-carriers.

The improved cell coverage does not require additional hardware, but the environment should be open and flat like sea coverage. The antenna will be installed on the hills or on a high tower. It’s better to use four-antenna-diversity. High output power. The network planning and parameter will be optimized, such as higher CPICH power.

Enhancement In RAN10.0, Extended Cell Coverage is up to 200 km.




In RAN10.0, the Node B supports extended cell coverage up to 200 km. The WBBPb(3900 series Node B), EBBI (BTS3812E/AE), and EBBC/EBBM (DBS3800) are required for this feature.



53 Improved Downlink Coverage

53.1 WRFD-021309 Improved Downlink Coverage


Summary This feature supports the deltaqrxlevmin parameter introduced in 3GPP R5. It can extend the DL coverage of a cell.

Benefits l Improves the downlink coverage and UE access capability l Improves the cell capacity by adjustment of PCPICH power in indoor scenario l Improves the access capability in long distance coverage scenario l 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.


WRFD-021308 Extended Cell Coverage up to 200km



54 High Speed Access

54.1 WRFD-010206 High Speed Access


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 Node Bs 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 Node B 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 Node B, automatic frequency control (AFC) should be implemented on the RAKE receiver. The Node B 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.

In the versions earlier than RAN10.0, when this feature is enabled, 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.

In RAN10.0, the WBBP, EBBI, and EBBC are added to support this feature without compromising the performance.

Enhancement In RAN10.0, the WBBP, EBBI, and EBBC are added to support this feature without compromising the performance.



Dependency None.



55 PDCP Head Compression (RFC 2507)

55.1 WRFD-011500 PDCP Header Compression (RFC 2507)



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:

l Compressible Chain of Sub-header Judgment Algorithm l Packet Stream Judgment Algorithm l Twice Algorithm for TCP Packet Streams



l Header Request Algorithm for TCP Packet Streams l Compression Slow-Start Algorithm for Non-TCP Packet Streams l Periodic Header Refresh Algorithm for Non-TCP Packet Streams

Enhancement In RAN5.0, IP V6 header compression is supported.


The UE should support the compression function.



56 Active Queue Management (AQM)

56.1 WRFD-011502 Active Queue Management (AQM)


Summary This feature provides the approach to buffer optimization to interact with the TCP protocol in a favorable manner and shorten the buffering delay.

Benefits The Active Queue Management feature improves the end user service in different ways. With AQM, where the buffer fill level is balanced to the UE data rate, the delay is significantly reduced.

Description This feature is valid for R99 packet connections for up to 384 kbps 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, e.g. 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 introduces three congestion detection thresholds (including early congestion threshold, congestion target threshold and absolute threshold of buffer limit) to detect buffer occupancy. Once the buffer is filled up to one of the thresholds, intelligent packet dropping mechanism will be applied correspondingly, avoiding subsequent packets from being discarded. This



packet dropping mechanism is also called as APDC (Adaptive Packet Discard Counter) algorithm.

It is possible for the operator to switch on/off the Active Queue Management function

Enhancement None.

Dependency None.



57 Fractional ATM Function on Iub Interface

57.1 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:

l Sharing of transmission links between 2G and 3G systems. l Reduced time in market at initial rollout. l Savings of transmission costs when co-site 2G and 3G

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 using 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.


The AEUa of the RNC supports Fractional ATM and the AOUa does not support this function.



58 Hierarchical Cell Structure (HCS)

58.1 WRFD-021200 Hierarchical Cell Structure (HCS)



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 l Improve the conversation quality for fast-moving UEs. l Improve the system capacity. l 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



Cell Type Characteristics

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.

l 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. l 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 None.



59 Intra-Frequency Load Balance

59.1 WRFD-020104 Intra-Frequency Load Balance


Summary This feature enables the adjustment of the PCPICH power in a cell to change cell load.

Benefits This feature is an action for reducing cell load. For those UEs in soft handover state, this feature enables the intra-frequency neighbor cells to share the cell load by removing high load cell from Active Set.

Description When the PCPICH power changes, the coverage of a cell increases or decreases. In this case, the UE at the edge of the cell, especially the UE in soft handover state, is affected.

In the case the UE is in soft handover state, the PCPICH power change can make the cell be removed from the Active Set. By this way, the cell load can be reduced.

The system provides a switch for operator to enable or disable this feature. The power adjust step and cell load threshold are configurable. In case the algorithm switch is ON, and cell load is greater than pre-defined overload threshold, the system will automatically decrease the PCPICH power by one step. If the current cell load is less than the pre-defined underload threshold, the system will automatically increase the PCIPCH power by one step

Enhancement None.

Dependency None.



60 Potential User Control

60.1 WRFD-020105 Potential User Control


Summary This feature is used to reduce the system load by modifying cell selection and reselection parameters of the UE to control the UE to camp on an appropriate cell according the cell load.

Benefits This feature is used to reduce the system load by modifying UE cell selection and re-selection parameters so as to control the UE to camp in a cell according the cell load.

Description This feature is an important action for Load Control. The feature controls the UE’s cell selection and re-selection behavior which is in Idle or Connect mode (CELL_FACH, CELL_PCH, URA_PCH) by automatically adjusting the parameters for cell selection and re-selection. The updated parameters will be sent to UE via system message updating procedure with SIB 3 and SIB4.

The system will periodically monitor the cell downlink load and compare the measurement value with configurable threshold. According to the current cell load, three cell load level are defined: Heavy, Normal, and Light.

l If the current cell load becomes heavy, PUC modifies cell selection and reselection parameters and broadcasts them via system information. By this way, UE will perform cell selection and re-selection procedure and camp to neighbor cells with light load.

l If the current cell load becomes normal, PUC will use the default cell selection and reselection parameters.

l If the cell load becomes light, PUC modifies cell selection and reselection parameters and broadcasts them through system information. By this way, PUC will enable the UEs in neighbor cells to select to current cell easily.

Enhancement None.

Dependency None.



61 Acronyms and Abbreviations

Table 61-1 Acronyms and Abbreviations

Acronym and Abbreviation Expansion

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 Node B 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



Acronym and Abbreviation Expansion

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

SNA Shared Network Area

TGW Transmission Gateway

VoIP Voice over IP

WCDMA Wideband Code Division Multiple Access

Optional Feature Description of Huawei UMTS RAN11_0

Documents

interconnected

huawei private

optional feature

large transport

huawei umts

variable pdu

small transport

peak bit rate