Optional Feature Description of Huawei UMTS RAN11 - 0

Optional Feature Description of
Huawei UMTS RAN11.0
Issue 1.2
Date 2008-09-17
CONFIDENTIAL
HUAWEI TECHNOLOGIES CO., LTD.

Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service.
Please feel free to contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Copyright © Huawei Technologies Co., Ltd. 2008. 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 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.
Issue 1.2 (2008-09-17) Commercial in Confidence Page 2 of 288

Optional Feature Description of Huawei UMTS RAN11.0
Contents
1 RABs and Services ................................................................................................................... 9

1.1 WRFD-010615 Multiple RAB Package (PS RAB ≥2)...............................................................................9
1.1.1 WRFD-01061501 Combination of Two PS Services ......................................................................... 11
1.1.2 WRFD-01061502 Combination of One CS Service and Two PS Services .........................................12
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
1.2 WRFD-010613 AMR-WB (Adaptive Multi Rate Wide Band)....................................................................16
1.3 WRFD-010617 VoIP over HSPA...............................................................................................................17
1.3.1 WRFD-01061701 RAB Mapping.....................................................................................................18
1.3.2 WRFD-01061703 Optimized Scheduling for VoIP over HSPA..........................................................19
1.4 WRFD-010618 IMS Signaling over HSPA................................................................................................21
1.5 WRFD-010619 CS Voice over HSPA/HSPA+ ...........................................................................................22
1.6 WRFD-010610 HSDPA Introduction Package...........................................................................................24
1.6.1 WRFD-01061017 QPSK Modulation...............................................................................................26
1.6.2 WRFD-01061001 15 Codes per Cell ................................................................................................27
1.6.3 WRFD-01061018 Time and HS-PDSCH Code Multiplexing ............................................................28
1.6.4 WRFD-01061009 HSDPA H-ARQ & Scheduling (MAX C/I, RR, and PF).......................................29
1.6.5 WRFD-01061005 HSDPA Static Code Allocation ............................................................................31
1.6.6 WRFD-01061004 HSDPA Power Control ........................................................................................33
1.6.7 WRFD-01061003 HSDPA Admission Control..................................................................................35
1.6.8 WRFD-01061019 HSDPA Dynamic Power Allocation .....................................................................36
1.6.9 WRFD-01061010 HSDPA Flow Control ..........................................................................................38
1.6.10 WRFD-01061006 HSDPA Mobility Management...........................................................................39
1.6.11 WRFD-01061014 HSDPA Transport Resource Management ..........................................................41
1.6.12 WRFD-01061008 Interactive and Background Traffic Class on HSDPA .........................................43
1.6.13 WRFD-01061002 UE Category 1 to 12..........................................................................................44
1.6.14 WRFD-01061015 HSDPA 1.8 Mbit/s per User ...............................................................................46
1.6.15 WRFD-01061016 16 HSDPA Users per Cell ..................................................................................47
1.7 WRFD-010611 HSDPA Enhanced Package...............................................................................................48
1.7.1 WRFD-01061103 EPF and GBR Based Scheduling..........................................................................49
1.7.2 WRFD-01061111 HSDPA State Transition .......................................................................................52

1.7.3 WRFD-01061112 HSDPA DRD.......................................................................................................54
1.7.4 WRFD-01061113 HS-DPCCH Preamble Support.............................................................................55
1.8 WRFD-010629 16QAM Modulation.........................................................................................................57
1.9 WRFD-010630 Streaming Traffic Class on HSDPA ..................................................................................58
1.10 WRFD-010631 Dynamic Code Allocation Based NodeB.........................................................................59
1.11 WRFD-010622 32 HSDPA Users per Cell...............................................................................................60
1.14 WRFD-010620 HSDPA 3.6 Mbit/s per User............................................................................................62
1.15 WRFD-010621 HSDPA 7.2 Mbit/s per User............................................................................................63
1.16 WRFD-010650 HSDPA 13.976 Mbit/s per User ......................................................................................64
1.17 WRFD-010651 HSDPA over Iur .............................................................................................................65
1.18 WRFD-010652 SRB over HSDPA ..........................................................................................................67
1.19 WRFD-010612 HSUPA Introduction Package.........................................................................................68
1.19.1 WRFD-01061201 UE Category 1 to 6............................................................................................69
1.19.2 WRFD-01061209 HSUPA HARQ and Fast UL Scheduling in NodeB.............................................70
1.19.3 WRFD-01061202 HSUPA Admission Control................................................................................72
1.19.4 WRFD-01061203 HSUPA Power Control ......................................................................................74
1.19.5 WRFD-01061204 HSUPA Mobility Management...........................................................................76
1.19.6 WRFD-01061208 HSUPA DCCC ..................................................................................................78
1.19.7 WRFD-01061207 HSUPA Transport Resource Management ..........................................................79
1.19.8 WRFD-01061206 Interactive and Background Traffic Class on HSUPA .........................................82
1.19.9 WRFD-01061210 HSUPA 1.44 Mbit/s per User .............................................................................82
1.19.10 WRFD-01061211 20 HSUPA Users per Cell ................................................................................84
1.20 WRFD-010614 HSUPA Phase 2 .............................................................................................................85
1.20.1 WRFD-01061401 E-AGCH Power Control (Based on CQI or HS-SCCH) ......................................86
1.20.2 WRFD-01061402 Enhanced Fast UL scheduling............................................................................87
1.20.3 WRFD-01061403 HSUPA 2 ms TTI...............................................................................................88
1.20.4 WRFD-01061404 HSUPA 2 ms/10 ms TTI HO..............................................................................90
1.20.5 WRFD-01061405 HSUPA 5.74 Mbit/s per User .............................................................................91
1.21 WRFD-010632 Streaming Traffic Class on HSUPA ................................................................................92
1.22 WRFD-010634 60 HSUPA Users per Cell...............................................................................................93
1.23 WRFD-010639 96 HSUPA Users per Cell...............................................................................................94
1.24 WRFD-010635 HSUPA over Iur .............................................................................................................95
1.25 WRFD-010636 SRB over HSUPA ..........................................................................................................97
1.26 WRFD-010637 HSUPA Iub flow control in case of Iub congestion..........................................................98
1.27 WRFD-010638 Dynamic CE Resource Management...............................................................................99
1.28 WRFD-010680 HSPA+ Downlink 28 Mbit/s per User ...........................................................................101
1.29 WRFD-010681 HSPA+ Downlink 21 Mbit/s per User ...........................................................................102

1.30 WRFD-010683 Downlink 64QAM .......................................................................................................103

1.31 WRFD-010684 2 × 2 MIMO ................................................................................................................105
1.32 WRFD-010685 Enhanced L2................................................................................................................107
1.33 WRFD-010686 CPC-DTX/DRX...........................................................................................................108
1.34 WRFD-010687 CPC HS-SCCH Less Operation....................................................................................109
1.35 WRFD-010688 Enhanced CELL_FACH............................................................................................... 111
1.36 WRFD-010616 MBMS Introduction Package ....................................................................................... 112
1.36.1 WRFD-01061601 MBMS Broadcast Mode .................................................................................. 114
1.36.2 WRFD-01061602 MBMS Admission Control .............................................................................. 115
1.36.3 WRFD-01061603 MBMS Load Control....................................................................................... 116
1.36.4 WRFD-01061604 MBMS Soft/Selective Combination ................................................................. 117
1.36.5 WRFD-01061605 MBMS Transport Resource Management......................................................... 118
1.36.6 WRFD-01061606 Streaming Service on MBMS........................................................................... 119
1.36.7 WRFD-01061607 MBMS 2 Channels per Cell .............................................................................120
1.36.8 WRFD-01061608 64/128Kbps Channel Rate on MBMS ..............................................................121
1.36.9 WRFD-01061609 Combination of MBMS and CMB on Broadcast...............................................122
1.37 WRFD-010660 MBMS Phase 2............................................................................................................123
1.37.1 WRFD-01066001 MBMS Enhanced Broadcast Mode ..................................................................124
1.37.2 WRFD-01066002 MBMS P2P over HSDPA ................................................................................125
1.37.3 WRFD-01066003 MBMS Admission Enhancement .....................................................................126
1.37.4 WRFD-01066004 Inter-Frequency Neighboring Cell Selection for MBMS PTP Users ..................128
1.38 WRFD-010627 FACH Transmission Sharing for MBMS.......................................................................129
1.39 WRFD-010624 MBMS 8 Channels per Cell..........................................................................................131
1.40 WRFD-010625 256Kbps Channel Rate on MBMS................................................................................132
1.41 WRFD-010626 MBMS FLC (Frequency Layer Convergence)/FLD (Frequency Layer Dispersion)........133
1.42 WRFD-010628 MBMS 16 Channels per Cell........................................................................................134
1.43 WRFD-010661 MBMS over Iur............................................................................................................135
1.44 WRFD-010662 Dynamic Power Estimation for MTCH.........................................................................136
1.45 WRFD-010663 MSCH and MSCH Scheduling .....................................................................................137
1.46 WRFD-010665 MBMS Channel Audience Rating Statistics ..................................................................138
1.47 WRFD-011000 Cell Broadcast Service .................................................................................................139
1.48 WRFD-020801 Cell ID + RTT Function Based LCS .............................................................................140
1.49 WRFD-020802 OTDOA Based LCS.....................................................................................................142
1.50 WRFD-020803 A-GPS Based LCS .......................................................................................................143
1.51 WRFD-020804 LCS Classified Zones...................................................................................................144
1.52 WRFD-020805 LCS over Iur ................................................................................................................145
2 RAN Architecture & Functions .......................................................................................... 148

2.1 WRFD-010203 Transmit Diversity .........................................................................................................148
2.2 WRFD-010209 4-Antenna Receive Diversity..........................................................................................150

2.3 WRFD-010210 Control Channel Parallel Interference Cancellation (CCPIC) ..........................................151

2.4 WRFD-021102 Cell Barring ...................................................................................................................152
2.5 WRFD-021103 Access Class Restriction.................................................................................................153
2.6 WRFD-021303 IMSI Based Handover....................................................................................................154
2.7 WRFD-021304 RAN Sharing Introduction Package................................................................................155
2.7.1 WRFD-02130401 Dedicated Carrier for Each Operator..................................................................157
2.7.2 WRFD-02130402 Flexible Network Architecture...........................................................................158
2.7.3 WRFD-02130403 Mobility Control and Service Differentiation .....................................................160
2.7.4 WRFD-02130404 Independent License Control .............................................................................162
2.7.5 WRFD-02130405 Independent Cell-level FM/PM/CM...................................................................163
2.7.6 WRFD-02130406 Transmission Recourse Sharing on Iub/Iur Interface...........................................164
2.8 WRFD-021305 RAN Sharing Phase 2.....................................................................................................165
2.8.1 WRFD-02130501 Dedicated Iub Transmission Control ..................................................................166
2.9 WRFD-021311 MOCN Introduction Package .........................................................................................169
2.9.1 WRFD-02131101 Carrier Sharing Among Operators......................................................................171
2.9.2 WRFD-02131102 Dedicated NodeB/Cell for Operators..................................................................173
2.9.3 WRFD-02131103 MOCN Mobility Management ...........................................................................174
2.9.4 WRFD-02131104 MOCN Load Balance ........................................................................................174
2.9.5 WRFD-02131105 MOCN Independent Performance Management .................................................176
2.10 WRFD-021302 Iu Flex .........................................................................................................................177
2.11 WRFD-021306 Iu Flex Load Distribution Management.........................................................................181
2.12 WRFD-021308 Extended Cell Coverage up to 200km...........................................................................183
2.13 WRFD-021309 Improved Downlink Coverage......................................................................................184
2.14 WRFD-010206 High Speed Access.......................................................................................................185
2.15 WRFD-011500 PDCP Header Compression (RFC 2507).......................................................................186
2.16 WRFD-011501 PDCP Header Compression (RoHC).............................................................................187
2.17 WRFD-011502 Active Queue Management (AQM) ..............................................................................188
2.18 WRFD-020302 Inter Frequency Hard Handover Based on Coverage .....................................................189
2.19 WRFD-020304 Inter Frequency Hard Handover Based on DL QoS .......................................................191
2.20 WRFD-020605 SRNS Relocation Introduction Package........................................................................192
2.20.1 WRFD-02060501 SRNS Relocation (UE Not Involved)...............................................................193
2.20.2 WRFD-02060502 SRNS Relocation with Hard Handover ............................................................195
2.20.3 WRFD-02060503 SRNS Relocation with Cell/URA Update.........................................................196
2.20.4 WRFD-02060504 Lossless SRNS Relocation...............................................................................197
2.21 WRFD-020303 Inter-RAT Handover Based on Coverage ......................................................................198
2.22 WRFD-020307 Video Telephony Fallback to Speech (AMR) for Inter-RAT HO ....................................200
2.23 WRFD-020308 Inter-RAT Handover Phase 2 ........................................................................................202
2.23.1 WRFD-02030801 NACC (Network Assisted Cell Change)...........................................................203
2.23.2 WRFD-02030802 PS Handover between UMTS and GPRS .........................................................205
2.24 WRFD-020310 3G/2G Common Load Management .............................................................................206

2.25 WRFD-021200 HCS (Hierarchical Cell Structure) ................................................................................208

2.26 WRFD-011600 TFO/TrFO....................................................................................................................210
2.27 WRFD-010505 Queuing and Pre-Emption ............................................................................................ 211
2.28 WRFD-010506 RAB Quality of Service Renegotiation over Iu Interface ...............................................213
2.29 WRFD-010507 Rate Negotiation at Admission Control.........................................................................214
2.30 WRFD-020701 AMR/AMR-WB Speech Rates Control.........................................................................217
2.31 WRFD-020104 Intra-Frequency Load Balance......................................................................................219
2.32 WRFD-020103 Inter-Frequency Load Balance......................................................................................220
2.33 WRFD-020105 Potential User Control..................................................................................................221
2.34 WRFD-020305 Inter-RAT Handover Based on Service .........................................................................222
2.35 WRFD-020306 Inter-RAT Handover Based on Load .............................................................................223
2.36 WRFD-020309 Inter-RAT Handover Based on DL QoS ........................................................................224
2.37 WRFD-020400 DRD Introduction Package...........................................................................................225
2.37.1 WRFD-02040001 Intra System Direct Retry ................................................................................226
2.37.2 WRFD-02040002 Inter System Direct Retry ................................................................................227
2.37.3 WRFD-02040003 Inter System Redirect ......................................................................................228
2.38 WRFD-020110 Multi Frequency Band Networking Management ..........................................................229
2.39 WRFD-020111 One Tunnel ..................................................................................................................232
2.40 WRFD-020113 Uplink Macro Diversity Intelligent Receiving...............................................................233
2.41 WRFD-020114 Domain Specific Access Control (DSAC) .....................................................................235
2.42 WRFD-020116 Dynamic Power Sharing of Multi-Carriers....................................................................237
2.43 WRFD-020117 Multi-Carrier Switch off Based on Traffic Load ............................................................238
2.44 WRFD-020118 Energy Efficiency Improved .........................................................................................239
2.45 WRFD-020120 Service Steering in RRC Connection Setup...................................................................240
2.46 WRFD-020123 TCP Accelerator...........................................................................................................241
2.47 WRFD-020124 Uplink Flow Control of User Plane...............................................................................243
3 Transmission ........................................................................................................................ 244

3.1 WRFD-050104 Satellite Transmission on Iub Interface ...........................................................................244
3.2 WRFD-050105 ATM Switching Based Hub NodeB ................................................................................245
3.3 WRFD-050106 AAL2 Switching Based Hub NodeB...............................................................................248
3.4 WRFD-050107 IP routing Based Hub Node B ........................................................................................249
3.5 WRFD-050302 Fractional ATM Function on Iub Interface ......................................................................250
3.6 WRFD-050405 Overbooking on ATM Transmission ...............................................................................251
3.7 WRFD-050406 ATM QoS Introduction on Hub NodeB (Overbooking on Hub NodeB Transmission) ......254
3.8 WRFD-050402 IP Transmission Introduction on Iub Interface.................................................................256
3.9 WRFD-050408 Overbooking on IP Transmission....................................................................................260
3.10 WRFD-050411 Fractional IP Function on Iub Interface .........................................................................263
3.11 WRFD-050403 Hybrid Iub IP Transmission ..........................................................................................264
3.12 WRFD-050404 ATM/IP Dual Stack NodeB...........................................................................................266

3.13 WRFD-050409 IP Transmission Introduction on Iu Interface.................................................................268

3.14 WRFD-050410 IP Transmission Introduction on Iur Interface ...............................................................270
3.15 WRFD-050412 UDP MUX for Iu-CS Transmission ..............................................................................272
3.16 WRFD-050420 FP MUX for IP Transmission .......................................................................................273
3.17 WRFD-050421 IP Re-route Based on BFD/ARP...................................................................................274
3.18 WRFD-050422 Dynamic Bandwidth Control of Iub IP..........................................................................276
3.19 WRFD-050424 Traffic Priority Mapping onto Transmission Resources .................................................278
3.20 WRFD-050425 Ethernet OAM .............................................................................................................282
3.21 WRFD-050501 Clock Synchronization on Ethernet in NodeB ...............................................................284
3.22 WRFD-050502 Synchronous Ethernet ..................................................................................................286
4 Reliability ............................................................................................................................. 287

4.1 WRFD-040202 RNC Node Redundancy .................................................................................................287

1 RABs and Services
1.1 WRFD-010615 Multiple RAB Package (PS RAB ≥2)

Feature Number: WRFD-010615
Availability
This feature is available from RAN2.0
This feature is introduced in 3GPP R99.
Description
Multi-RAB can provide more abundant 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, Combination of four PS service is supported.

Dependency
The CN node and UE must have the corresponding multi-RAB support capability.
Benefits
Multi-RAB support capability provides operators with more choices for the service solution.

1.1.1 WRFD-01061501 Combination of Two PS Services

Availability
This feature is available from RAN2.0.
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 selected in the combination.
Enhancement
None.
Dependency
WRFD-010615 Multiple RAB Package (PS RAB ≥2).
Benefits
Multi-RAB support capability provides operators with more choices for the service solution.

1.1.2 WRFD-01061502 Combination of One CS Service and Two

PS Services
Availability
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
selected in the combination.
Enhancement
None.
Dependency
WRFD-010615 Multiple RAB Package (PS RAB ≥2)
Benefits
This feature provides operators with more choices for the service solution.

1.1.3 WRFD-01061503 Combination of Three PS Services

Availability
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 selected in the combination.
Enhancement
Dependency
Benefits

1.1.4 WRFD-01061504 Combination of One CS Service and Three

PS Services
Availability
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
selected in the combination.
Enhancement
Dependency
Benefits

1.1.5 WRFD-01061505 Combination of Four PS Services

Availability
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 below.
RAN11.0 supports four PS RABs per user, and the above VoIP + BE service is just one case.
Other service combinations like 4PS BE services are also possible.
Enhancement
None.
Dependency
The CN and UE must have the capability of supporting Multi-RAB.
Benefits
This feature enhances the system's compatibility with various VoIP UEs and facilitates the
development of VoIP.
3PS RAB VoIP + BE service combination could be support with this feature which enriches
the operator’s services portfolio.

1.2 WRFD-010613 AMR-WB (Adaptive Multi Rate Wide

Band)
Availability
This feature is introduce in 3GPP R5.
Description
AMR-WB (Wide Band) is a new feature in 3GPP_REL 5 for the purpose to provide improved
voice quality especially in terms of increased voice naturalness.
This feature provides the AMR-WB service with the bit rate defined as follows:
Codec Mode Source Codec BitRate

AMR-WB_23.85 23.85 kbit/s
The system will set up the AMR service according to the service request from the core
network. The algorithm for AMR-WB is the same as that for the AMR service with narrow
band.
Enhancement
None.
Dependency
The CN node and UE must have the corresponding support capability.
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.

1.3 WRFD-010617 VoIP over HSPA

Availability
Description
In the fixed network, Voice over IP (VoIP) has turned out to be an attractive and cost-effective
solution to support PS conversational services. The rapid growth of VoIP users urges the
cellular operator to introduce this feature to make their network more profitable. Moreover,
from the evolution point view, it is also helpful to converge the operator’s network into ONE
all-IP network and decrease the total operational cost accordingly.
In WCDMA system, on the one hand, VoIP can provide lower cost voice service compared to
the traditional CS voice, and on the other hand, such service can make it simpler to support
rich services like real-time video sharing or messenger. The reason is that they are all carried
on the PS domain and the end user will also benefit from it.
VoIP service can be carried on DCH or HSPA. When it is set up on the DCH, the capacity is
not competitive due to more resource consumption. Therefore, VoIP over HSPA is a better
solution. And Robust Header Compression (RoHC) should also be supported to improve the
overhead efficiency. In RAN10.0, Huawei supports the following features to provide VoIP
over HSPA solution:
l RAB Mapping
l Optimized scheduling for VoIP over HSPA
This feature is only trial feature in RAN10.0. From RAN11.0, it becomes commercial feature.
And other features such as PDCP Header Compression (RoHC) and Continuous Packet
Connectivity (CPC) can improve the transmission efficiency and capacity of VoIP service.
Enhancement
None.
Dependency
WRFD-010610 HSDPA Introduction Package
WRFD-010612 HSUPA Introduction Package
CN and UE should support VoIP.
Benefits
VoIP over 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

1.3.1 WRFD-01061701 RAB Mapping

Availability
Description
VoIP over HSDPA and VoIP over HSUPA 10/2 ms TTI can be supported.
Due to the difference between 3GPP Release 5 and Release 6, the typical configuration of
VoIP for R5 and R6 UE is not the same. In TS34.108 and TR25.993, 3GPP defines some VoIP
configuration and related combinations as references. Huawei RAN supports these services.
Since all the RTP headers will be transmitted before ROHC is started and higher bit rate is
needed. After ROHC is started, lower bit rate can be used. The reconfiguration between
higher bit rate and lower bit rate is not supported in RAN10.0.
Whether to carry VoIP on DCH or HSPA is configurable on the cell level for the operator.
That is, when HSPA is chosen as the bearer with high priority, VoIP will be set up on it as
much as possible. If HSPA procedure is not successful, for example, due to the admission
control, a periodical timer will be started to trigger the reconfiguration of the HSPA
procedure.
Enhancement
None.
Dependency
WRFD-010617 VoIP over HSPA
Benefits
VoIP over HSPA mapping is supported

1.3.2 WRFD-01061703 Optimized Scheduling for VoIP over HSPA

Availability
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.
In addition, SRB effect shall also be taken into account in the DS algorithm since SRB over
HSPA is supported in RAN10.0 and SBR is also delay sensitive.
VoIP service in 3G consists of three kinds of packets, namely SIP signaling, RTP, and RTCP
packets. RTP and RTCP can be born on a single RAB.
UTRAN
UTRAN PS IMS
IMS PS UTRAN
UTRAN UE
UE UE
Domain Domain
Domain
Session control Signaling (SIP / SDP)
Media ( RTP) )
Real Time Media Control (RTCP)
The above packets have different characteristics:
Packet Characteristic
SIP signaling Delay sensitive.
RLC retransmission due to packet loss, impacting on delay.
VoIP-RTP Delay sensitive.
No RLC retransmission due to packet loss, impacting on delay and user
experience.
VoIP-RTCP Non-Delay sensitive. (if the carrying bearer over HS-DSCH is
independent of RTP)
SRB Delay sensitive.
RLC retransmission due to packet loss, impacting on delay.
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.
Enhancement

None.
Dependency
WRFD-010617 VoIP over HSPA
Benefits
This feature guarantees the delay requirement of VoIP services and improves the user
experience when VoIP over HSDPA is applied.

1.4 WRFD-010618 IMS Signaling over HSPA

Availability
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; it is considered to carry the service on HSPA, which brings better
performance for IMS service.
The type of channels carrying IMS signaling is configurable separately on the downlink and
uplink at cell level. That is, when HSPA is chosen as the bearer with high priority, IMS
signaling will be set up on it as much as possible. If the setup is not successful, for example,
due to admission control, a periodical timer will be started to trigger the reconfiguration of the
HSPA procedure.
Enhancement
None.
Dependency
WRFD-022000 Physical Channel Management
WRFD-010610 HSDPA Introduction Package and WRFD-010612 HSUPA Introduction
Package
CN should support the signaling indication at Iu interface.
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.

1.5 WRFD-010619 CS Voice over HSPA/HSPA+

Availability
Description
Generally Circuit Switched Voice is carried on DCH, from 3GPP’s Release 8 Circuit Switched
Voice over HSPA (CS Voice over HSPA) is introduced. Namely, the UL CS voice packet is
borne with E-DCH and the DL CS voice packet with 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. So 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 showing as below.
To deploy CS Voice over HSPA, just RNC and UE need to be updated for mapping CS service
to HSPA. There is no impact for MSC and Node B.
Not only frequency efficiency and cell capacity could be improved because of introducing
HSPA technology for CS Voice, but also the better talk time the user will have, as the CPC
technology in HSPA+ could be applied also.
Enhancement
None.
Dependency
The UE must be CS voice over HSPA capable.
Benefits

The use of the HSPA radio bearer will allow using all the power saving and capacity
enhancing features which has come with HSPA. This will improve user experience compared
to the R99 DCH by providing better talk time and better radio capacity.

1.6 WRFD-010610 HSDPA Introduction Package

Availability
Description
High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5.
The maximum downlink throughput is achieved in the way of sharing CE resources, power
resources, and code resources with new physical channels and downlink shared transport
channel for HSDPA, which include physical channels HS-SCCH, HS-PDSCH, and
HS-DPCCH, and the transport channel 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 round trip time is reduced greatly with 2 ms TTI. At the same time, some functions are
moved down to the NodeB that also has contribution to reducing the round trip time.
HARQ provides a highly efficient re-transmission mechanism than RLC retransmission. The
UE can request 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 good radio
environment, the transmission can adopt 16 QAM modulation mode and large transport
blocks so as to increase 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 that can bear the interactive, background, and
streaming services. And the HSDPA traffic can use a dedicated carrier or a shared carrier with
R99. The system shall be capable of handling both cases.
Mobility management for HSDPA service shall be considered in the system, including 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 detail,
refer to the enhancement of the features in the package.
Dependency

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.
UE should have the HSDPA capability.
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

1.6.1 WRFD-01061017 QPSK Modulation

Availability
Description
Quaternary Phase Shift Keying (QPSK)
The HS-PDSCH is used to carry the HS-DSCH data. 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.
Enhancement
None.
Dependency
Benefits
This feature provides higher service bit rate to improve the user experience.

1.6.2 WRFD-01061001 15 Codes per Cell

Availability
Description
High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5
which can provide high speed service for the downlink. A new downlink shared transport
channel, HS-DSCH, is introduced for carrying service. The spread factor of HS-DSCH is
fixed to 16.
The HS-DSCH can use up to 15 codes in one cell by which the supported peak rate of air
interface can reach up to 14.4 Mbit/s. The system capacity is improved by supporting 15
codes.
Enhancement
None.
Dependency
Benefits
HSDPA with 15 codes makes it possible to introduce higher bit rate service from day one and
improve system capacity.

1.6.3 WRFD-01061018 Time and HS-PDSCH Code Multiplexing

Availability
Description
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 case that the NodeB has more HS-PDSCH codes allocated than those supported by
the UE. For instance, the UE supports 5 codes and the NodeB has 10 codes available in a
single TTI. The code multiplexing can increase the resource utilization and system
throughput.
Enhancement
None.
Dependency
Benefits
This feature improves the efficiency and performance of HSDPA service.

1.6.4 WRFD-01061009 HSDPA H-ARQ & Scheduling (MAX C/I,

RR, and PF)
Availability
Description
HARQ
For 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.
Scheduling algorithm enables the system to decide which UEs to be transmitted each TTI (2
ms). 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
Moreover, 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 done on the basis of the reported CQI.
To avoid the negative system impact 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, EPF (enhanced proportional fair) is introduced in RAN5.1. And SPI mapping is
further optimized considering ARP. In addition, the services with GBR include the best effort

services and the configurable limit of the minimum throughput shall 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 shall not be
scheduled in this TTI.
Dependency
Benefits
This feature provides the flexibility for the operator to select schedule algorithm, considering
the system capacity and fairness among the users.

1.6.5 WRFD-01061005 HSDPA Static Code Allocation

Availability
Description
Before the NodeB starts to transmit the data on the HS-DSCH, the RNC shall allocate
channelization code for HS-SCCH with a spreading factor (SF) of 128 and for HS-PDSCH
with the SF of 16. Normally, the system capacity and spectral efficiency can be improved if it
allocates HS-PDSCH codes to the NodeB as many as possible. On the other side, the
channelization codes reserved for HS-PDSCH transmission cannot be simultaneously used for
transmission of R99 channel, and hence the allocation of many HS-PDSCH codes might
eventually result in blocking of R99 users. So it is important for the RNC and NodeB to make
good use of the channelization code resources so as to improve both efficiency and system
capacity.
There defined two types of code strategy for HS-PDSCH code allocation which can take
different effects on HSDPA service, static allocation, and dynamic allocation.
Static allocation is a code allocation method which might be used at the initial HSDPA
deployment stage, with the concern that there are less HSDPA users and R99 users taking
majority of the services. The RNC reserves some codes for the HS-PDSCH and the DPCH
while other common channels use the rest codes. The number of reserved codes for the
HS-PDSCH is configurable.
Code reserved for

common channel and Codes available
HS-SCCH Codes reserved for
for DPCH HS-PDSCH
SF=16
With the increasing requirement for HSDPA service, dynamic HS-PDSCH code allocation is
needed so as to increase code utilization efficiency. According to the code allocation
controller, the code allocation is of two types, namely the RNC-controlled dynamic
HS-PDSCH code allocation and the NodeB-controlled dynamic HS-PDSCH code allocation.
In the RNC-controlled dynamic HS-PDSCH code allocation, the RNC determines the
maximum number and minimum number of HS-PDSCH codes that the NodeB can use and
then notices the NodeB the code information through the Physical Shared Channel
Reconfigure Request signaling message. The code resource between the maximum number of
codes and the minimum number of codes is a shared code. When the shared code part is
available for HSDPA, the RNC will increase the minimum number of HS-PDSCH codes and
notices them to the NodeB. The RNC is in charge of the code management.

Code reserved for

common channel and
HS-SCCH Shared codes
SF=16
Max number Min number

of codes of codes
Codes available for DPCH Codes reserved for HS- PDSCH
Enhancement
In RAN5.1, the RNC-controlled dynamic HS-PDSCH code allocation is introduced.
Dependency
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 resource confliction.

1.6.6 WRFD-01061004 HSDPA Power Control

Availability
Description
When HSDPA service is introduced, the total transmit DL power resource per cell is divided
into three parts, 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.
As for R99 service, the power of DPCH is adjusted through inner and outer loop power
control. The power of HSDPA channel is allocated and adjusted dynamically among users
through the NodeB scheduling algorithm.
With dynamical power allocation, the NodeB estimates the power available for the entire
HSDPA channel per TTI as:
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 in each 2 ms TTI.
The NodeB then adjusts the power between HS-SCCH and HS-PDSCH. Normally, there are
three types of power control method 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 NodeB, the fixed transmit power of the HS-SCCH can be configured by the operator.
For power control based on CQI report, the HS-SCCH transmit power is adjusted as a
function of the CQI report received from the user.
For 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.
Dependency
Benefits

This feature enables the system to provide reliable reception quality for the HS-SCCH. It
can increase system capacity and reduce the NodeB power output for the HS-SCCH, thus
raising the total transmission power utilization.

1.6.7 WRFD-01061003 HSDPA Admission Control

Availability
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 make
good use of the system resources and fully utilize resources.
In the HSDPA admission control procedure, the HSDPA user per NodeB and per CELL shall
be considered in the way of configuring allowed maximum HSDPA user per NodeB and per
CELL.
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 so as 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. Only when
requested bit rate of the incoming call is greater than the threshold can the call be mapped on
HSDPA.
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 power shall not be pre-empted by R99 services, although the
power is shared between R99 and HSDPA.
In RAN6.0, queuing and pre-emption are considered for HSDPA if admission control fails.
Dependency
Benefits
This feature enables HSDPA service to make good use of 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 so as to
provide high bit rate service for users.

1.6.8 WRFD-01061019 HSDPA Dynamic Power Allocation

Availability
Description
The cell total transmit power is the constant resource. The DL power consists of the following
three parts:
Power of the HSDPA DL physical channel (HS-SCCH and HS-PDSCH)
Common channel power
DPCH power
Among the three parts, the second is reserved and the first is allocated by the NodeB.
Except those reserved for the common channels, the rest power resources of the cell are
allocated dynamically between the DPCH and the HSDPA DL physical channels. The DPCH
takes higher priority to use the rest power resources.
Full usage of power

Total Power
Power for HSDPA
Power for DPCH
Power for CCH
Flexible scheme Time
As shown in the figure above, the NodeB detects the R99 power load every 2 ms to determine
the available power for HSDPA. In this way, the cell load is more stable.
To obtain the available power for HSDPA, a power margin must be set aside to handle the
power increase caused by R99 power control each 2 ms.
Enhancement
None.
Dependency
Benefits

This feature enables HSDPA service to make good use of 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 so as to
provide high bit rate service for users.

1.6.9 WRFD-01061010 HSDPA Flow Control

Availability
Description
HSDPA flow control ensures that the NodeB queue has enough data to be transmitted for a
UE when this UE is scheduled. At the same time, flow control feature can minimize the buffer
size and buffer time in the NodeB in order to avoid data loss probably caused by overtime
data buffering.
The RNC sends CAPACITY REQUEST control frame to the NodeB through the Iub interface.
The NodeB will monitor the buffer status and measure the throughput when the UE is
scheduled. Meanwhile, the NodeB will consider the Iub interface throughput as well as the
Iub bandwidth. A CAPACITY ALLOCATION message will be sent to the RNC after the
NodeB decides how many data to send.
The NodeB can also initiate the update of capacity allocation towards the RNC based on the
buffer size of the queue and the available bandwidth on the Iub interface.
Enhancement
None.
Dependency
Benefits
This feature can prevent packet loss and maximize the utilization of power and code resources.
It enables the service scheduling and re-transmission functions in the NodeB and reduces the
data transmission latency.

1.6.10 WRFD-01061006 HSDPA Mobility Management

Availability
Description
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 moving. The mobility feature also
enables an HSDPA user to change the cell with less service interruption.
The big difference in mobility handling is that the HS-DSCH cannot perform soft handover
compared with the DCH. And there is only one serving HSDPA cell or HSDPA connection
for the HSDPA user. The HSDPA cell change procedure is used for the HSDPA user mobility
solution. The associated DCH can undergo soft handover and maintain the Active Set as
described in Release 99.
The similarity in mobility handling is that both HS-DSCH and DCH handovers are based on
the measurement report of the UE and controlled by the network. If the UE has both the
HSDPA and the DPCH connections, the measurement and the handover decision are made
separately.
Handover from HSDPA Cell to R99 Cell
When the UE is moving from an HSDPA cell to a R99 cell (intra-frequency) and event 1B, 1C
or 1D is triggered, the HSDPA connection between UE and HSDPA cell will be changed to
the DCH connection between UE and R99 cell through DCH soft handover and HS-DSCH
radio link reconfiguration. Since HSDPA cell is no longer the best cell in the Active Set and
the target cell does not support HSDPA, the current HS-DSCH cell will be replaced or
removed from the Active Set and the service will be changed to the DCH instead of the
HS-DSCH for service continuity.
If the neighboring cell of HSDPA cell is an inter-frequency cell and does not support HSDPA,
a hard handover will be performed. The HSDPA handover decision is based on the
measurement report of the pilot channels of neighboring cells.
Handover from R99 Cell to HSDPA Cell
When an HSDPA capable UE with interactive/background/streaming service accesses the R99
cell, only the DCH is used to carry these services. And when the UE is moving from R99 cell
to HSDPA cell (intra-frequency or inter-frequency), the system can change the service to
HS-DSCH channel.
For intra-frequency cell, the DPCH connection between UE and HSDPA cell will be set up
first due to event 1A. When the HSDPA cell becomes the best cell and event 1D is triggered,
the service will be switched from the DPCH to the HS-PDSCH of the HSDPA cell carrying
the PS service.
For inter-frequency cell, when the UE moves, an inter-frequency handover is triggered if the
quality of the signals of HSDPA cell improves. The UE changes from R99 cell to HSDPA cell
and the PS service will be switched from the DPCH to the HS-PDSCH.
Handover Among HSDPA Cells

For intra-frequency cell, cell change takes place when the HSDPA connection is moved from
one HSDPA cell to another. The source HSDPA cell is removed from the Active Set trigged by
event 1D and target HSDPA cell is added to the Active Set as a best cell.
For inter-frequency cell, an inter-frequency handover between HSDPA cells is triggered. The
service will be changed to the HS-DSCH of the target cell. The hard handover depends on the
UE measurement.
Handover from HSDPA Cell to 2G cell
The handover from 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.
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.
Dependency
Benefits
This feature reduces the user data interruption and improves user perceived data transfer
quality when the UE is moving with HSDPA service. It also provides a method to ensure the
service continuity among R99 cell and HSDPA cell.

1.6.11 WRFD-01061014 HSDPA Transport Resource Management

Availability
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 HSDPA services. The features concerned are as follows:
l Differentiated services mapping
l Transport resource load control
I. Differentiated services mapping
PS streaming and best effort services can be set up on HSDPA. Since different services have
different QoS requirements and the Iub transport will be IP and/or ATM, ATMHDRT,
ATMHDNRT, IPHDRT, and IPHDNRT traffic categories are added accordingly.
Traffic Traffic Type

Category
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 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.
Dependency
Optional feature WRFD-050402 IP Transmission (Iub interface), WRFD-050403 Hybrid IP
Transmission, and WRFD-050404 ATM/IP Dual Stack NodeB should be required when the
transmission resource management feature applied for IP transmission resources in those
scenarios.
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.

1.6.12 WRFD-01061008 Interactive and Background Traffic Class

on HSDPA
Availability
Description
This feature enables the best effort service (interactive and background) to be mapped onto
the HS-DSCH if a UE is HSDPA capable. 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 with interactive or background service, it can use another CS RAB or another
PS RAB. Two HSDPA BE RABs can be served on one UE simultaneously if the UE
capability is allowed.
Enhancement
None.
Dependency
Benefits
This feature enables the system to support a higher speed RAB of PS background and
interactive service.

1.6.13 WRFD-01061002 UE Category 1 to 12

Availability
Description
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.
In the table below, the UE of category 10 can support 15 codes with the maximum bit rate of
13.976 Mbit/s. In RAN6.0, up to 7.2 Mbit/s per user can be supported. Therefore, the
categories (9/10) of higher capability can be supported with 7.2 Mbit/s maximally.
HS-DSCH Maximum Minimu Maximum Number Maximum

Category Number of m of Bits Bit Rate
HS-DSCH Inter-TT
Codes Received I
Interval
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
Note: In the maximum number of bits, the bits refer to those of an HS-DSCH transport block
received within an HS-DSCH TTI.
Enhancement
None.
Dependency
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.

1.6.14 WRFD-01061015 HSDPA 1.8 Mbit/s per User

Availability
Description
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 improving the user experience.
Enhancement
None.
Dependency
Benefits
This feature provides higher peak bit rate and improves the end user experience.

1.6.15 WRFD-01061016 16 HSDPA Users per Cell

Availability
Description
A maximum of 16 HSDPA users can be served simultaneously in an HSDPA capable cell with
this feature.
Enhancement
None.
Dependency
Benefits
This feature provides operators with a maximum of 16 HSDPA users in an HSDPA capable
cell.

1.7 WRFD-010611 HSDPA Enhanced Package

Availability
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)
Enhancement
In RAN6.0 and RAN10.0, this feature is enhanced. For details, refer to the enhancement of
the features in the package.
Dependency
UE should support the functions connected with HSDPA Enhanced package.
Benefits
Enhance the HSDPA performance by introducing the GBR-based QoS guarantee mechanism.
Enhance the HSDPA networking capability to meet HSDPA networking requirements.

1.7.1 WRFD-01061103 EPF and GBR Based Scheduling

Availability
Description
Scheduling algorithm enables the system to decide which UE data should be transmitted each
TTI (2 ms). This feature provides different HSDPA scheduling algorithms, considering the
tradeoff between system capacity and fairness among users.
Four scheduling algorithms are provided for the operator to choose:
l Max C/I
l RR (round Robin)
l PF (proportional fair)
l EPF (enhanced proportional fair)
Based on the Proportional Fair (PF) algorithm, the EPF algorithm can guarantee the users’
Guaranteed Bit Rate (GBR) requirement when the cell is not in congestion. It is very useful to
guarantee the fairness of users who initiate the BE service.
The following figure shows the EPF-based scheduling algorithm periods. Each period is
segmented into three parts.
Scheduling Scheduling Scheduling Scheduling

algorithm period algorithm period algorithm period algorithm period
Time
GBR service s GBR service All service

cheduled with PF( X ) forcibly scheduled ( Y ) scheduled with PF( Z )
For the preceding figure:

In the X time segment, only the queues configured with GBR are scheduled according to the
PF algorithm.
In the Y time segment, only the queues configured with GBR but not achieved are scheduled
according to their scheduling priority indicator (SPI). Before the data rate of queues with
higher SPI reaches their GBR, the queues with lower SPI cannot be scheduled.
In the Z time segment, all queues are scheduled according to the PF algorithm.
The duration of the X, Y, and Z can be dynamically changed, which is a trade-off between the
cell throughput and the user’s fairness.

There is only one queue can be selected in one TTI for one user. If one user has multiple
queues, the queue with the highest integrated priority will be selected. The queue selection of
one user is similar to the selection of different users. To put it simply, the user selection rather
than queue selection is applied as follows:
For the user selection in PF scheduling algorithm, the CQI, the filtered scheduling rate of the
UE, and the SPI of the queue are taken into account. The scheduling priority is calculated
with the following formula:
Ri (t )
Pr iority i = * γ SPI
ri (t ) (1)
Where:
Ri (t ) is the instant rate of UE i which can be reached according to the reported CQI at the
scheduling time t.
γ SPI is the weighed coefficient related to SPI. See the following table.
ri (t ) is the user’s scheduling rate after filtering, which is calculated with the following
formula:
1 1
ri (t ) = (1 − ) * ri (t − 1) + * Ri (t − 1)
Tc Tc
(2)
Where:
Tc is the time smoothing constant. The typical value of Tc is 800 with the unit of 2 ms.
Ri (t ) is the scheduling rate of the UE at the time of t, where the power resource, code
resource, data volume stored in the queue, and CQI are taken into account.
Parameter Name Weight of SPI

Parameter ID SPIWEIGHT
Physical Range & Unit Percent
Optional/Mandatory Mandatory
Description:
The parameter Weight of SPI is used in the scheduling algorithm to select the queue to
send data. The bigger the Weight of SPI is, the more the queue can be scheduled.
The weight of SPI is determined by the traffic class, user’s priority, and Traffic Handling
Priority (THP) of the interactive service.
The users can also be divided into the Gold,Silver, and Copper levels, which can be mapped
from the ARP and the mapping is configurable. Moreover, DL/UL GBR is also a user
definable parameter for each priority level and used for HSDPA scheduler algorithm. With
this feature, the QoS guarantee mechanism for HSDPA is enhanced.
In RAN5.1, the enhanced proportional fair (EPF) is introduced in RAN5.1. SPI mapping is
further optimized with ARP taken into account . In addition, the services with GBR including
best effort services are provided with the configurable limit of the minimum throughput,
which shall be strictly guaranteed during scheduling.
Enhancement
In RAN6.0, configurable GBR for the Gold/Silver/Copper level is supported to enhance the
QoS guarantee mechanism.
Dependency
WRFD-010611 HSDPA Enhanced Package
Benefits
Satisfy the GBR requirement of the streaming service and the BE service.

1.7.2 WRFD-01061111 HSDPA State Transition

Availability
Description
This feature enables the UE to perform a state transition among 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 flowing figure shows the RRC state relation.
CELL_DCH
CELL_PCH CELL_FACH
CELL_DCH
(with HS-DSCH)
Channel Switching Between CELL_DCH (HS-DSCH) and CELL_FACH

If the HS-DSCH is carrying BE service or streaming service and there is no data to be sent for
a long time, the transition from CELL_DCH (HS-DSCH) to CELL_FACH is triggered.
Actually this feature is supported in the same way as state transition from CELL_DCH to
CELL_FACH.
A UE on CELL_FACH will be switched to CELL_DCH (HS-DSCH) due to a higher bit rates
request on downlink.
Channel Switching Between CELL_DCH (HS-DSCH) and CELL_DCH
The channel switching between HS-DSCH and DCH is mainly triggered by mobility
management. The transition from CELL_DCH to CELL_DCH (HS-DSCH) can be triggered
by periodical retry and the traffic volume
The mobility triggering is described in WRFD-01061006 HSDPA Mobility Management
feature.
The traffic volume report that indicates a higher bit service needs to be transferred. The UE in
CELL_DCH will be transferred to CELL_DCH (HS-DSCH) if it is an HSDPA capable cell
and the UE has HSDPA capability. This feature enables the UE to enjoy high speed service.
If an HSDPA capable UE is set up on the DCH for BE services for some reasons. For example,
when the admission of the HS-DSCH fails, a periodical retry mechanism will take action,
allowing the UE to enter the CELL_DCH (HS-DSCH). The retry time is configurable.
Enhancement

None.
Dependency
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 in the way of
moving the UE to CELL_FACH if the UE is not in active state.

1.7.3 WRFD-01061112 HSDPA DRD

Availability
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 the HSDPA admission control allows.
When a UE camps on an HSDPA cell and requests for a streaming or BE service which is
HSDPA suitable, and if the HSDPA admission fails on the current cell but there is another
HSDPA capable cell which is concentric with current cell, the service will be mapped onto
the HS-DSCH of the concentric HSDPA capable cell if the HSDPA admission control allows.
An HSDPA capable UE has an HSDPA suitable service but currently be mapped onto the
DCH due to some limitations (for example, the current cell does not support HSDPA or the
HSDPA admission control fails). At this time, the UE moves and the best cell begins to
support HSDPA and the HSDPA admission control allows, the service will be re-mapped
onto the HS-DSCH of the best cell. If the best cell does not support HSDPA, but there is a
concentric cell which is HSDPA capable and the HSDPA admission control allows, the
service will be re-mapped onto the HS-DSCH of that concentric cell.
An HSDPA capable UE has an HSDPA suitable service but currently be mapped onto the
CELL_FACH or CELL_DCH (DCH only) and there is a data transmission request on the
downlink but the concentric cell rather than the current cell supports HSDPA. 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
currently is 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.
Dependency
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.

1.7.4 WRFD-01061113 HS-DPCCH Preamble Support

Availability
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 inform the sender of the result to further request
retransmissions.
If the UE has not detected the HS-SCCH control message, it will reply with a DTX message
to reduce the probability that the NodeB erroneously decodes this DTX as ACK. The
ACK/NACK requires high transmit power.
Huawei supports HS-DPCCH preamble mode detection. The proposed enhancement is to
send special Preamble and Postamble sub-frames in the uplink HS-DPCCH before and after
an ACK/NACK sub-frame. This method reduces the probability of a DTX->ACK error in the
NodeB, because the NodeB has to decode at least two successive timeslots erroneously before
the earlier mentioned scenario could take place. Due to the prior preamble information
detection, the same performance of the HARQ-ACK field detection can be kept with lower
power.
HS-SCCH N N+1 N+2 N+3
N N+1 N+2 N+3

HS-DSCH
Data Packet
HS-DPCCH PRE ACK or NACK POST
N-1 N N+1 N+2
PREAMBLE Normal ACK/NACK POSTAMBLE transmitted

transmitted in sub- to indicate correct or in sub-frame N+1
frame N-1 to indicate incorrect decoding of (unless a packet is
reception of relevant packet correctly decoded from
signalling information sub-frame N+1 on the
in sub-frame N on HS-DSCH, or control
HS-SCCH information is detected in
sub-frame N+2 on the
HS-SCCH)
Enhancement
None.

Dependency
This feature depends on the NodeB hardware: EBBI, or EBOI, or EBBC,or EULP.
Benefits
HS-DPCCH preamble mode technology enables the NodeB to distinguish between DTX and
ACK/NACK without requiring high ACK transmit power
The uplink coverage gain is about 0.2 dB to 0.9 dB with different accompanying DPCH
services.

1.8 WRFD-010629 16QAM Modulation

Availability
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 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 high-order 16QAM
modulation mode and large transport blocks to achieve high peak rate.
The UE of category 10 can support a maximum of 15 HS-PDSCH codes and 16QAM
modulation mode. The supported peak rate on the air interface can reach 14.4 Mbit/s.
Enhancement
None.
Dependency
UE should support the demodulation of 16QAM.
Benefits
Provide higher peak bit rate HSDPA service for HSDPA users.

1.9 WRFD-010630 Streaming Traffic Class on HSDPA

Availability
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 schedule algorithm also considers the GBR information of streaming traffic so
that all HSDPA streaming service shall be guaranteed when the bit rate is not less than GBR.
Dependency
Benefits
This feature enables the system to support a higher speed RAB of PS streaming service.

1.10 WRFD-010631 Dynamic Code Allocation Based

NodeB
Availability
Description
In NodeB-controlled dynamic HS-PDSCH code allocation, NodeB determines the
HS-PDSCH code use according to the code availability and scheduling algorithm in each 2ms
TTI. NodeB-controlled dynamic HS-PDSCH code allocation is more efficient and flexible
than RNC-controlled dynamic HS-PDSCH code allocation. The resource can be scheduled
and used in a short time at the NodeB, compared with signaling message transmission on the
Iub interface using RNC-controlled dynamic HS-PDSCH code allocation.
HS-DSCH transmission to multiple users in parallel during a single TTI requires more
HS-SCCH codes and more HS-PDSCH codes. Code multiplexing is adopted and is found
useful in case that the NodeB has more HS-PDSCH codes allocated than what is supported by
the UE. For instance, the UE supports 5 codes and the NodeB has 10 codes available in a
single TTI. The code multiplexing can increase the resource utilization and system
throughput.
Enhancement
None.
Dependency
Benefits
This feature increases the resource utilization and system throughput.

1.11 WRFD-010622 32 HSDPA Users per Cell

Availability
Description
Up to 32 HSDPA users can be admitted to a HSDPA cell.
Enhancement
None.
Dependency
Benefits
This feature provides HSDPA services at a higher peak bit rate for up to 32 users per cell.


Availability
Description
Up to 64 HSDPA users can be admitted to a HSDPA cell.
Enhancement
None.
Dependency
WRFD-010622 32 HSDPA Users per Cell
Benefits
This feature provides HSDPA services at a higher peak bit rate for up to 64 users per cell.

Availability
Description
RAN11.0 supports up to 96 HSDPA users per cell.
Enhancement
None.
Dependency
WRFD-010623 64 HSDPA Users per Cell
WRFD-010652 SRB over HSDPA
WRFD-010687 CPC HS-SCCH Less Operation
WRFD-010685 Enhanced L2
Benefits
This feature enables the system to serve more HSDPA users.

1.14 WRFD-010620 HSDPA 3.6 Mbit/s per User

Availability
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
UE should have the capability to support the rate.
Benefits
This feature provides a higher peak bit rate and enhances user experience.


Availability
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 7.2 Mbit/s (MAC layer). Thus, user experience is greatly
enhanced.
Enhancement
None.
Dependency
WRFD-010620 HSDPA 3.6Mbps per User
Benefits


Availability
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
WRFD-010621 HSDPA 7.2Mbps per User
This feature requires WFMRc board in BSC6800.
Benefits

1.17 WRFD-010651 HSDPA over Iur

Availability
Description
HSDPA over Iur is the scenario where the HSDPA serving cell is carried at the DRNC. The
feature includes HSDPA service management over Iur, HSDPA mobility management over Iur,
and so on.
HSDPA service management over Iur
HSDPA service management over Iur refers to HSDPA service setup, modification, release,
and state transition.
When the UE is in the CELL_DCH state and the DRNC cell is in the active set or the UE is in
the CELL_FACH state and camps in a DRNC cell, the HSDPA service can be setup, modified,
and released over Iur.
The service over Iur can be reconfigured between HSDPA and R99 with UE state transition
between CELL_DCH and CELL_FACH.
HSDPA mobility management over Iur
HSDPA mobility management over Iur includes hard handover, cell update (caused by radio
link failure), and serving cell change.
The 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.
Dependency
The neighbouring RNC should also support HSDPA over Iur.
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.

1.18 WRFD-010652 SRB over HSDPA

Availability
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 HSDPA rather than the DCH. Moreover, while the SRB is over HSDPA, the
F-DPCH multiplexed by users is introduced, and thus saving 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, if 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.
Dependency
This feature depends on the NodeB hardware (EBBI, EBOI, EULP or EBBC).
UE should support F-DPCH.
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.

1.19 WRFD-010612 HSUPA Introduction Package

Availability
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 NodeB.
The basic principle behind HARQ for HSUPA is the same as that for HSDPA. After each
transmitted TTI, the NodeB informs the transmitting UE of whether the uplink data was
received correctly or not. The UE retransmits the packet if incorrect reception occurs. HSUPA
HARQ either uses chase combing where each retransmission is the exact copy of the initial
data or incremental redundancy where the retransmission only contains the redundancy bits.
The fast scheduling algorithm at the NodeB enables the system to make scheduling decision
with the minimum latency as close to the radio interface as possible. Even though the NodeB
makes the scheduling decision, it is the UE that decides the transmitted power and the
transmit format.
In RAN6.0, only 10 ms TTI is supported and the maximum uplink rate is 1.44 Mbit/s (MAC
layer) per user. Each cell can support up to 20 HSUPA users.
Enhancement
In RAN10.0, HSUPA Introduction Package is enhanced. For detail, refer to the enhancement
of the features in the package.
Dependency
UE should have HSUPA capability.
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.

1.19.1 WRFD-01061201 UE Category 1 to 6

Availability
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 scategory 2/4/5/6 only uses 10 ms TTI in RAN6.0.
E-DCH Max. E-DCH TTI Max. Data Rate (Mbit/s)

Category Capability
Combination MAC MAC Air
Layer Layer Interface
10 ms 2 ms
TTI TTI
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 4 2 x SF2 10 ms and 2 ms 2.0 2.89 3.84
Category 6 2 x SF4 + 2 xS 10 ms and 2 ms 2.0 5.74 5.76

F2
RAN10.0 supports SF2 and 2 ms TTI.

Enhancement
RAN10.0 supports UEs of categories1-6 (2 ms).
Dependency
Cat 1/3 depends on WRFD-010612 HSUPA Introduction Package.
if Cat 2/4/5/6 need to support Max. Date Rate under 2ms TTI , it depends on WRFD-010614
HSUPA phase 2.
Benefits

HSUPA with six UE categories make 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.
1.19.2 WRFD-01061209 HSUPA HARQ and Fast UL Scheduling in

NodeB
Availability
Description
Release 6. HSUPA improves the system capacity and throughput for the uplink by
maximizing power utilization and adjusting the uplink bit rate according to the channel
quality.
The key functions used in HSUPA for maximizing resource utilization include 2 ms/10 ms
TTI, Hybrid Automatic Repeat Request (HARQ), and fast scheduling in the NodeB.
The basic principle of HSUPA HARQ is the same as that of HSDPA HARQ. In each TTI, the
NodeB informs the transmitting UE of whether the uplink data is received correctly or not.
The UE retransmits the packet if the uplink data is not correctly received. HSUPA HARQ
either uses chase combining where each retransmission is the exact copy of the initial data or
uses incremental redundancy where the retransmission contains the additional redundant
informtion for correct decoding.
The fast scheduling algorithm in the NodeB enables the system to make the scheduling
decision with the minimum latency as close to the radio interface as possible. Even though the
NodeB makes the scheduling decision, the UE shall decide the transmit power and the
transmit format.
RAN6.0 supports only 10 ms TTI and the maximum uplink rate of 1.44 Mbit/s per user (at the
MAC layer). Each cell supports up to 20 HSUPA users.
RAN10.0 supports 2 ms TTI and the maximum uplink rate of 5.74 Mbit/s per user (at the
MAC layer). Each cell supports up to 60 HSUPA users.
The users can also be categorized into three levels: gold, silver, and copper, which are mapped
from the Address Resolution Protocol (ARP). 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 is to determine each UE's primary rate and authorization indication

according to the buffer status of the UE and the congestion indication from the RNC. The
MAC-e scheduling algorithm performs scheduling based on the primary rate and
authorization indication.
Dependency
Benefits
HARQ scheme improves the data transmission effeciency and shortens the delay, thus
improves 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 limitations on CE resources.
The combination of the MAC-e scheduling and flow control algorithms further raises the
bandwidth efficiency for each UE.

1.19.3 WRFD-01061202 HSUPA Admission Control

Availability
Description
HSUPA service admission control enables HSUPA services to access to the network with
other R99 services by using the remaining uplink cell load as well as other resources. It can
make good use of the system resources and enables efficient resources utilization.
In the HSUPA admission control procedure, the HSUPA user per NodeB and per CELL
should be considered through the configuration of the maximum HSUPA users at the RNC.
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 traffics multiplied by a configurable threshold.
If the condition of PBR is not fulfilled, RNC further performs a check of power resource on
the basis of Received Total Wideband Power (RTWP) and Received Scheduled E-DCH Power
Share (RSEPS) measurement.
Both Iub resources and NodeB credit resources checks are done during the admission control
so as to enable HSUPA services and other R99 services to be admitted under a certain
guaranteed QoS.
During the admission control, the RNC decides whether the service is mapped to E-DCH or
not by setting service rate thresholds. The thresholds include a UL streaming service HSUPA
threshold and a UL BE service HSUPA threshold. Only when the requested bit rate of the
incoming call is higher than the threshold can the call be mapped on HSUPA.
Queuing and pre-emption are considered for HSUPA if admission control fails due to
limitation of user number or equivalent user number.
Enhancement
In RAN10.0, Received Scheduled E-DCH Power Share (RSEPS) measurement is supported,
and algorithm 2 is available.
Dependency


Benefits
This feature enables HSUPA services to make good use of system resources and enables
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 so as to
provide high bit rate services for users.

1.19.4 WRFD-01061203 HSUPA Power Control

Availability
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 for
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.
Dependency
Benefits

This feature enables system to provide reliable quality for HSUPA-related channels. It
increases system capacity and reduces uplink interference and downlink power output.

1.19.5 WRFD-01061204 HSUPA Mobility Management

Availability
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 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.
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 AS of DCH, since the active
set of E-DCH is independent of the AS 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.

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 is becoming better. The UE changes
from the R99 cell to the HSUPA cell and the PS services are switched from the DCH to the
E-DCH.
Handover from an HSUPA Cell to a 2G Cell
The handover from an HSUPA cell to a 2G cell is triggered by normal inter-RAT handover.
Refer to features of inter-RAT handover for detail information.
Inter-RNC Handover for HSUPA
For cell change between RNCs, inter-RNC soft handover over Iur for HSUPA is available.
Compressed mode measurement for HSUPA
Compressed mode measurement is available for E-DCH 10 ms in the case of inter-frequency
and inter-RAT handover.
Dependency
Enhancement
In RAN10.0, the AS of E-DCH is independent of the AS of DCH and 1J event report is
supported.
Dependency
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.

1.19.6 WRFD-01061208 HSUPA DCCC

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

Benefits
This feature improves CE resource utilization and makes it possible for the UE to enjoy the
high speed service. Meanwhile, if the UE is not in the active state, the system resources are
saved by the switch of the UE to CELL_FACH.
1.19.7 WRFD-01061207 HSUPA Transport Resource Management

Availability
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 HSUPA
services. The following features are concerned.
l Differentiated services mapping
l Transport resource load control
I. Differentiated services mapping
PS streaming and best effort services can be set up on HSUPA. Since different services have
different QoS requirements and the Iub transmission is over IP and/or ATM, ATMHURT,
ATMHUNRT, IPHURT, and IPHUNRT traffic categories are added accordingly.
Traffic Traffic Type

Categories
ATMHURT HSUPA streaming services
ATMHUNRT HSUPA interactive services and HSUPA background services
IPHURT HSUPA streaming services
PHUNRT 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
describes 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. Such 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.
Dependency
Optional feature WRFD-050402 IP Transmission (Iub interface), WRFD-050403 Hybrid IP
Transmission, and WRFD-050404 ATM/IP Dual Stack NodeB should be required when the
transmission resource management feature is applied for IP transmission resources in those
scenarios.
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.

1.19.8 WRFD-01061206 Interactive and Background Traffic Class

on HSUPA
Availability
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 thresholdthen . Otherwise, the requested service is mapped on the DCH. The service
rate threshold is configurable by 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 is with 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.
Dependency
Benefits
This feature enables the system to support a higher speed RAB of the PS interactive and
background services.
1.19.9 WRFD-01061210 HSUPA 1.44 Mbit/s per User

Availability
Description
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.
Dependency
Benefits
This feature provides a higher peak bit rate and enhances the user experience.

1.19.10 WRFD-01061211 20 HSUPA Users per Cell

Availability
Description
Up to 20 HSUPA users can be admitted to a HSUPA cell.
Enhancement
None.
Dependency
Benefits
This feature provides HSUPA services at a higher peak bit rate for up to 20 users per cell.

1.20 WRFD-010614 HSUPA Phase 2

Availability
Description
Release 6.
In RAN6.0, only 10 ms TTI is supported and the maximum uplink rate is1.44 Mbit/s (MAC
layer) /1.92 Mbit/s (physical layer) per user. Each cell supports up to 20 HSUPA users.
In RAN10.0, the 2 ms TTI is supported, the maximum uplink rate is 5.74 Mbit/s (MAC
layer)/5.76 Mbit/s (physical layer).
Enhancement
None.
Dependency
For hardware, the HSUPA phase 2 depends on the EBBC, or EBBI, EULP board in NodeB
and the software. The software dependency is described in each sub functions.
UE should support such functions as 2ms TTI and 5.74M rate, etc.
Benefits
HSUPA improves the performance of UMTS network by providing higher rate and higher
throughput for the uplink and higher capacity for the system.

1.20.1 WRFD-01061401 E-AGCH Power Control (Based on CQI or

HS-SCCH)
Availability
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.
Dependency
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, following advantages are
introduced:
l Less power consumption of E-AGCH
l Flexible power control for E-AGCH

1.20.2 WRFD-01061402 Enhanced Fast UL scheduling

Availability
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 Consider the scheduling priority indicator, GBR, and data rate while queuing the HSUPA
users.
l Consider the CE resources and Iub transport resources.
Shorter TTI means more efficient schedule process.
provides high speed service for the uplink. In order to provide multiple bit rate services, six
UE categories are defined in 3GPP. Different UE categories support different maximum
codes for E-DCH, which means that different maximum bit rates can be achieved.
Enhancement
None.
Dependency
WRFD-010638 Dynamic CE Resource Management
Benefits
Enhanced UL scheduling makes it more efficient to accommodate different scenarios, such as
hub NodeB, IP convergence, and RAN sharing.
This feature enables more efficient usage of uplink resource by maximizing the uplink
throughput of the cell under the condition that the QoS requirements of all UEs are met.
This feature provides better fairness among users. If there are users with the same priority, the
uplink resources allocated to them are similar.

This feature provides flexible priorities among users. If a UE has a higher priority, it can
obtain more uplink resources.
1.20.3 WRFD-01061403 HSUPA 2 ms TTI

Availability
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.
E-DCH Max. E-DCH TTI Max. Data Rate (Mbit/s)

Category Capability
Combination MAC MAC Air
Layer Layer Interface
10 ms 2 ms
TTI TTI
Category 1 x SF4 10 ms only 0.71 – 0.96
1
Category 2 x SF4 10 ms and 2 ms 1.45 1.40 1.92
2
3
Category 2 x SF2 10 ms and 2 ms 2.0 2.89 3.84

4
5
Category 2 x SF4 + 2 x 10 ms and 2 ms 2.0 5.74 5.76
6 SF2
Compressed mode measurement is available for E-DCH 2 ms in the case of inter-frequency

and inter-RAT handover.
Enhancement
None.
Dependency

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

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

Availability
Description
Both 10 ms and 2 ms TTI are defined in the 3GPP protocol for HSUPA. In the HSUPA
network, when UE moves between cells that support HSUPA 2 ms TTI and those does not, the
switching schedule between 10 ms and 2 ms TTIs is needed. Such switching generally occurs
in the handover scenario as described below.
When the soft handover happens to an UE using HSUPA 2 ms TTI and the target cell doesn’t
support 2 ms TTI, the RNC first reconfigures the UE to 10 ms TTI and then performs the
handover procedure.
When the hard handover happens to an UE using HSUPA 2 ms TTI and the target cell doesn’t
support 2 ms TTI, the RNC performs the handover and reconfigures the UE to 10 ms TTI at
the same time.
When all the cells in active set using HSUPA 10 ms TTI support 2 ms TTI, a periodical retry
to reconfigure to 2 ms TTI is implemented to make it possible to get better performance. On
the other hand, a configurable bit rate threshold is triggered by such retry procedure, that is,
when the RAB maximum bit rate assigned is lower than the threshold, it is unnecessary to use
2 ms TTI.
The RNC gets the 2 ms TTI capability from the audit message sent by the NodeB. For the
neighboring cells that are not controlled by the RNC, such capability can be configured by the
operator.
Enhancement
None.
Dependency
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.

1.20.5 WRFD-01061405 HSUPA 5.74 Mbit/s per User

Availability
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.
Dependency
Benefits
This feature greatly enhances user experience.

1.21 WRFD-010632 Streaming Traffic Class on HSUPA

Availability
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.
Dependency
Benefits
This feature enables the system to support higher speed RAB of the PS streaming traffic.

1.22 WRFD-010634 60 HSUPA Users per Cell

Availability
Description
Up to 60 HSUPA users can be admitted to a HSUPA capable cell.
Enhancement
None.
Dependency
WRFD-010614 HSUPA phase 2
Benefits
Compared with the HSUPA introduction package, more HSUPA users are available in one
cell.

1.23 WRFD-010639 96 HSUPA Users per Cell

Feature number: WRFD-010639
Availability
Description
RAN11.0 supports up to 96 HSUPA users per cell.
Enhancement
None.
Dependency
WRFD-010634 60 HSUPA Users per Cell
WRFD-010686 CPC - DTX / DRX
Benefits
This feature allows more HSUPA users in one cell and improves the system capacity.

1.24 WRFD-010635 HSUPA over Iur

Availability
Description
The HSUPA over the Iur is the scenario that the DRNC cell is in the HSUPA E-DCH active
state. The feature comprises the HSUPA service management over the Iur, the HSUPA
mobility management over the Iur, and so on. The HSUPA capability of the DRNC cell is
configurable.
HSUPA service management over Iur
The HSUPA service management over the Iur includes the HSUPA service setup, modification,
release, and the dynamic channel configuration control (DCCC).
When the UE is in CELL_DCH state and the DRNC cell is in the E-DCH active state or the
UE is in CELL_FACH state and the camps in the DRNC cell, the HSUPA service can be set
up, modified and released over the Iur.
The HSUPA DCCC over the Iur is similar to the WRFD-01061208 HSUPA DCCC and the
difference is that some of the cells are in the DRNC.
HSUPA mobility management over Iur
The HSUPA mobility management over the Iur includes the soft handover, hard handover, cell
update (because of radio link failure), and serving cell change.
The process is similar to the corresponding mobility management described in the
WRFD-01061204 HSUPA Mobility Management and the difference is that the cells change
between the RNCs.
HSUPA static relocation
If the HSUPA service is over the Iur and the radio links are provided only by the target RNC,
the static relocation can be triggered by the Iur congestion.
HSUPA service pre-emption in DRNC
When the new HSUPA service is not admitted to access the network, the CRNC may trigger
the 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 processis similar to that on the Iub interface.
Enhancement
None.

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

1.25 WRFD-010636 SRB over HSUPA

Availability
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.
Dependency
WRFD-010652 SRB over HSDPA.
This feature depends on the NodeB hardware EBBI, EBOI, EULP or EBBC
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.

1.26 WRFD-010637 HSUPA Iub flow control in case of Iub

congestion
Availability
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 NodeB 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.
Dependency
Benefits
This feature can improve the transport resource usage efficiency greatly and reduce the
throughput fluctuation in the case of the Iub congestion.

1.27 WRFD-010638 Dynamic CE Resource Management

Availability
Description
A channel element (CE) is defined as the baseband resources required in the NodeB to
provide capacity for 12.2 k AMR voice, including 3.4 k DCCH. The HSUPA shares the CE
resource with the R99 services.
The 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 NodeB will allocate the CE resources according to the maximum set of
E-DPDCHs, even if the user’s actual traffic is very low. So the utility of the CE resource is
inefficient.
Huawei adopts the dynamic CE resource management to save the CE resources. Each TTI,
NodeB can call back the CE resources if the user’s throughput decreases, allocate the CE
resources during the radio link setup or reconfiguration, allocate the CE resources for the
AG(Absolute Grant) ‘UP’ users, and preempt the CE resources for the RG(Relative
Grant )‘UP’ users. The dynamic CE resource management process is described in the
following figure.
For example, one user has the maximum bit rate at1.45 Mbit/s, but the actual throughput is
always changed. With the dynamic CE resource management, the CE consumption is
dynamically changed with the bit rates (blue line), not allocated according to the maximum
set of the E-DPDCHs (red line).
Throughput (kbps)
2000
Throughput (kbps)
1500
1000
500
0
0 20 40 60 80 100 120 140
Time (s)
Enhancement
None.
Dependency

Benefits
The dynamic CE allocation can call back the CE resources in time when the user’s throughput
decreases, saving the CE resources.

1.28 WRFD-010680 HSPA+ Downlink 28 Mbit/s per User

Availability
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 28 Mbps per
user (MAC layer).
Enhancement
None
Dependency
WRFD-010650 HSDPA 13.976 Mbit/s per User
WRFD-010684 2 x 2 MIMO
To support this feature, the following configurations are required:
l The BTS3812E, BTS3812A and BTS3812AE should be configured with EBBI board.
l The BBU3806 should be configured with EBBC board; the BBU3806C should be
configured with EBBM board.
l The BBU3900 should be configured with WBBPb board.
l The BSC6800 should be configured with FMRc boards.
For the RF part, the RF module of Huawei NodeB supports one TX channel each, and two
interconnected RF modules can provide two TX channels to support 2 x 2 MIMO,.
The UE category must support 2×2 MIMO. That is, the UE must belong to category 15,16,17
or18, as specified by the 3GPP protocols.
Benefits
This feature brings the following benefits:
l Increase the utilization ratio of the frequency
l Increase the user peak data rate in downlink
l Enhances user experience in high-speed online services

1.29 WRFD-010681 HSPA+ Downlink 21 Mbit/s per User

Feature number: WRFD -010681
Availability
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.
Dependency
WRFD-010683 64QAM
WRFD-010650 HSDPA 13.976 Mbit/s per User
In the BSC6800, the FMRc boards are required for user plane data processing.
To support this feature, the following configurations are required:
The UE category must support 64QAM. That is, the UE must belong to category 13, 14,17or
18, as specified by the 3GPP protocols.
Benefits
l Increase the utilization ratio of the frequency
l Increase the user peak data rate in downlink
l Enhances user experience in high-speed online services

1.30 WRFD-010683 Downlink 64QAM

Availability
Description
3GPP R5 introduces 16QAM to increase the peak rate per user and expands the system
capacity, whereas 64QAM introduced in 3GPP R7 protocols is a further enhancement of
16QAM.
With downlink 64QAM, higher order modulation technology than 16QAM can be used when
the channel is of higher quality. Theoretically, 64QAM supports a peak data rate of 21 Mbit/s
and at the same time increases the average throughput of the system. Simulation shows that
compared with 16QAM, 64QAM can increase the average throughput by 7% and 16%
respectively in macro cell and in micro cell, if the UEs in the cells use the type 3 receivers.
The 3GPP R7 protocols define the categories of the UEs that support 64QAM, and add the
information elements (IEs) that support 64QAM in the reporting of local cell capability. The
RNC determines whether the RL between the NodeB and the UE supports 64QAM according
to the local cell capability reported by the NodeB and the UE capability. If the RL supports
64QAM, the MAC-hs scheduler of the NodeB determines every 2 ms whether to use 64QAM
according to the following aspects:
l Channel Quality Indicator (CQI) reported by the UE
l HS-PDSCH code resources and power resources of the NodeB
Enhancement
None.
Dependency
RAN10.0 is hardware ready for 64QAM. To support 64QAM, the following configurations
are required:
The UE category must support 64QAM. That is, the UE must belong to category 13, 14,17or
18, as specified by the 3GPP protocols.
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 not only improves user experience but also enhances operators'
competitiveness.

1.31 WRFD-010684 2 × 2 MIMO

Availability
Description
2×2 Multiple Input Multiple Output (MIMO) uses two transmit antennas at the NodeB to
transmit orthogonal (parallel) data streams to the two receive antennas at the UEs. Using two
antennas and additional signal processing at the receiver and the transmitter, 2×2 MIMO can
increase the system capacity and double user data rates without using additional bandwidth. 2
×2 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 also the average throughput of the system
is enhanced.
The 3GPP R7 protocols define the categories of the UEs that support MIMO, and add the
information elements (IEs) that support MIMO in the reporting of local cell capability. The
RNC determines whether the RL between the NodeB and the UE supports MIMO according
to the local cell capability and UE capability reported by the NodeB. If the RL supports
MIMO, the MAC-hs scheduler of the NodeB determines every 2 ms whether to use MIMO
according to the following aspects:
l Channel Quality Indicator (CQI) reported by the UE
l Precoding Control Indication (PCI)
l HS-PDSCH code resources and power resources of the NodeB
Enhancement
None.
Dependency
RAN10.0 is hardware ready for 2×2MIMO. To support 2×2 MIMO, the following
configurations are required:
For the RF part, the RF module of Huawei NodeB supports one TX channel each and two
interconnected RF modules can provide two TX channels to support 2 x 2 MIMO,.

The UE category must support 2×2 MIMO. That is, the UE must belong to category 15, 16,
17 or18, as specified by the 3GPP protocols.
Benefit
2×2 MIMO increases the average throughput and peak rate of the cell. In the case of
unchanged bandwidth, 2×2 MIMO increases the average throughput of the system by 14% to
23%. Theoretically, the peak rate per 2×2 MIMO user can be twice the original peak rate. In
addition, MIMO have 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.

1.32 WRFD-010685 Enhanced L2

Availability
Description
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.
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 the better service coverage
and throughput will be got.
Enhancement
None.
Dependency
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.

1.33 WRFD-010686 CPC-DTX/DRX

Availability
Description
Discontinuous Transmission (DTX)/Discontinuous Reception (DRX) are the key features of
the CPC, 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 certain pattern when there is no transmission on the EDCH and the
HS-DPCCH in the uplink. The UL DPCCH DTX pattern is configured by SRNC to on one
hand minimize the transmission on DPCCH and on the other hand maintain the physical
uplink synchronization between NodeB and UE by periodically sending. Uplink DTX reduces
the noise raised by the DPCCH in the uplink and also reduces the redundant signal on the
DPCCH.
Downlink DRX is implemented on the basis of Uplink DTX. Downlink DRX means that the
UE receives data on the HS-SCCH according to the transport pattern that RNC configures,
and thus the UE need not detect the HS-SCCH in the period when no data would be sent
according to the pattern.
Enhancement
None.
Dependency
The UE should support this feature.
Benefits
l Improves the user experience of "always on"
l Expands the system capacity
l Reduces the power consumption of UEs

1.34 WRFD-010687 CPC HS-SCCH Less Operation

Availability
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.
l 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.
Dependency
The UE should support this feature.
Benefits
This feature increases the data service capacity in the downlink because of the less
transmission of HS-SCCH. According to the simulation of 3GPP, about 15% downlink
capacity of VoIP service could be increased.

1.35 WRFD-010688 Enhanced CELL_FACH

Availability
Description
Enhanced CELL_FACH is a new feature introduced in R7. It enables the UE in CELL_FACH
state to receive data at a higher rate on the HS-DSCH.
In enhanced CELL_FACH, the UE remains in CELL-FACH state. Enhanced CELL_FACH
mainly functions in downlink data transmission, that is, the data carried on the logical
channels such as BCCH, CCCH, DCCH, and DTCH can be mapped to the HS-DSCH, and
then transferred to the UE on the HS-PDSCH. In this way, the UE in CELL_FACH state can
share downlink code resources and power resources with the UE in CELL_DCH state.
In R7, the UE that does not support enhanced CELL_FACH can receive data from the FACH
while the UE that supports enhanced CELL_FACH can receive data from either FACH or
HS-DSCH, depending on whether the current cell supports enhanced CELL_FACH.
The UTRAN send in the system information the parameters for HS-DSCH reception in
CELL_FACH state so as to validate the data receiving by the UE. The parameters include
HS-SCCH, HS-PDSCH configuration, and common H-RNTI. When a cell is configured with
HS-DSCH reception in CELL_FACH state, the UE in CELL_FACH state gives priority to the
HS-DSCH rather than the SCCPCH to receive the dedicated signaling data carried on the
FACH.
The UE in CELL_FACH state keeps monitoring the HS-SCCH and automatically receives
data on the HS-DSCH upon receipt of data, without switching from CELL_FACH state to
CELL_DCH state. This avoids the delay caused by state transition.
Enhancement
None.
Dependency
The UE should support the enhanced CELL_FACH.
Benefits
This feature provides higher-speed data transmission for the UE in CELL_FACH state, thus
improving user experience of "always on", and shortens the delay caused by state transition.

1.36 WRFD-010616 MBMS Introduction Package

Availability
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, 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:
PDN
(e.g. Internet )
Content
Provider /
Multicast
Broadcast
HLR Source
Gr
Gmb Content
Uu Iu Gn /Gp Provider /
GGSN Multicast
UE UTRAN SGSN BM -SC Broadcast
TPF Source
Gi
Iu /Gb
Um
UE GERAN
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 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 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.
Dependency
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, the broadcast multicast service centre (BM-SC) is added to
provide a set of functions for the MBMS users Services.
l UE should support MBMS functions.
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.

1.36.1 WRFD-01061601 MBMS Broadcast Mode

Availability
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. Offered the capability, the UE can
receive the MBMS service even in the CELL_DCH.
Huawei UMTS RAN6.0 only supports the broadcast mode.
Enhancement
None.
Dependency
WRFD-010616 MBMS Introduction Package
Benefits
With this feature, the operators can deploy rich multimedia services, such as mobile TV.

1.36.2 WRFD-01061602 MBMS Admission Control

Availability
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 NodeB resource state, that is, NodeB 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 a 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.
Dependency
Benefits
The cell power is allocated preferentially to the MBMS broadcast service with higher priority.

1.36.3 WRFD-01061603 MBMS Load Control

Availability
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.
Dependency
Benefits
The feature helps to decrease the cell load when the cell enters the congestion state and
ensures the system stability.

1.36.4 WRFD-01061604 MBMS Soft/Selective Combination

Availability
Description
The common channel soft combination is a function introduced for the MBMS. It means that
the UE receiver combines the signal from the multiple cells either in the RAKE receiver or
after the RAKE receiver in the receiver chain prior to the decoding of the soft combination
transport channel. The maximum time difference between the S-CCPCHs carrying the same
service in different cells should be less than 1TTI+1slot.
The soft combination normally improves the UE reception gain by 5 - 7 dB.
The selective combination (SC) is an enhancement for the Release 6 PtM MBMS. The
network is to simulcast the PtM MBMS contents on the S-CCPCH, and the UE receives and
decodes the MBMS data from multiple radio links simultaneously. The selection of the
radio link is to be performed on a transport block basis at the RLC, based on the CRC results
and sequence numbers.
The selective combination normally improves the UE reception gain by 3 - 5 dB.
The RNC should ensure that the services data sent to the UE from different cells are
synchronized.
Enhancement
None.
Dependency
Benefits
With this feature, the power of the S-CCPCH that bears the MBMS services can be saved.

1.36.5 WRFD-01061605 MBMS Transport Resource Management

Availability
Description
For the same MBMS session in the same NodeB, a separate Iub transport bearer is established
for each cell. An example is shown in the following figure assuming 3 cells in one NodeB.
Three copies of exact same MBMS session data are sent through the Iub from the CRNC to
the NodeB.
CN CRNC Node B
Iub transport bearers
MBMS stream
Enhancement
None.
Dependency
Benefits
It is an essential feature to deploy MBMS broadcast mode services.

1.36.6 WRFD-01061606 Streaming Service on MBMS

Availability
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.
Dependency
Benefits
The feature can meet the QoS requirements of the service applications borne by the streaming
class.

1.36.7 WRFD-01061607 MBMS 2 Channels per Cell

Availability
Description
The MBMS two channels per cell are supported.
Enhancement
None.
Dependency
Benefits
The feature is an essential function for the deployment of the MBMS service application.

1.36.8 WRFD-01061608 64/128Kbps Channel Rate on MBMS

Availability
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 theTTI.
Dependency
Benefits
The feature enables the different channel rates provide operators with more flexibility to
deploy the MBMS services.

1.36.9 WRFD-01061609 Combination of MBMS and CMB on

Broadcast
Availability
Description
The cell multimedia broadcast (CMB) is an innovative mobile TV solution of Huawei before
the MBMS is introduced in the 3GPP. Like the MBMS, the common channel is used to bear
the service and there is only one copy of data on the Iu interface. So it is possible to
combine them.
For the same service channel provided by the CMB and the MBMS, there is only one copy of
data sent on the SCCPCH. The user plane function is shared by the CMB and the MBMS.
The CMB UEs that want to enjoy the MBMS service access into the network by normal CMB
access procedures, such as triggering the RRC connection and the RAB setup procedure. And
the MBMS UEs perform the normal MBMS access procedures, such as listening to the MICH
and the MCCH broadcast information.
Enhancement
None.
Dependency
Benefits
The feature provides smooth evolution from the CMB to the MBMS.

1.37 WRFD-010660 MBMS Phase 2

Availability
This feature is available from RAN 10.0.
Description
MBMS Phase 2 refers to enhanced broadcast mode introduced in 2006/09 3GPP
specifications. Compared with broadcast mode, the main differences include:
l “Counting/re-counting” function used for multicast mode is introduced for enhanced
broadcast. During the counting/re-counting procedure, UE reports to RNC its selected
services directly on 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
Dependency
UE should support the corresponding enhanced MBMS functions.
Benefits
Compared with broadcast mode, It is a more efficient way to deploy the point-to-multipoint
services (such as mobile TV), because the cell resource can be saved based on PTP/PTM
mode selection.

1.37.1 WRFD-01066001 MBMS Enhanced Broadcast Mode

Availability
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
Dependency
Benefits
Compared to broadcast mode, it is a more efficient way to deploy the point-to-multipoint
services, such mobile TV.

1.37.2 WRFD-01066002 MBMS P2P over HSDPA

Availability
Description
In enhanced broadcast mode, PTP and PTM mode can be selected to transport MBMS
services. If PTP mode is adopted, RNC will establish the separate PTP RB for every UE. Like
the non-MBMS service, HSDPA can be used to bear PTP MBMS RB and multiple RAB such
as combination of P2P MBMS streaming and I/B PS over HSDPA.
Enhancement
None
Dependency
Benefits
By HSDPA, the cell capacity will be improved.

1.37.3 WRFD-01066003 MBMS Admission Enhancement

Availability
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
Dependency

Benefits
MBMS PTM bearers are treated differently, so they will not occupy too much resource to
block non-MBMS connection admission and they also got safeguard by reservation.

1.37.4 WRFD-01066004 Inter-Frequency Neighboring Cell

Selection for MBMS PTP Users
Availability
Description
This function is applied when multi-carriers and single carriers are neighboring carriers. For
MBMS PTP users, inter-frequency handover may interrupt MBMS services; therefore, service
interruption should be avoided to ensure service continuity. This function is not intended for
MBMS PTM users or PTP users with other services accompanied.
As shown in the figure above, the f3 cell has inter-frequency neighboring cells f1 and f2. At
the border between the f1 or f2 cell and the f3 cell, when an MBMS PTP user handover from
the f3 cell to the f1 or f2 cell, the RNC shall select from the inter-frequency neighboring cell
list according to the current service received by the user. If the currently received service is
from channel 3, the RNC removes the f2 cell from the list; if the currently received service is
from channel 1 or 2, the RNC keeps the f1 and f2 cells in the list.
There can be more complicated cases.
Enhancement
None.
Dependency
WRFD-010660 MBMS Phase 2
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.

1.38 WRFD-010627 FACH Transmission Sharing for

MBMS
Availability
Description
This feature improves efficient Iub transport for MBMS. In previous 3GPP Rel-6, for the
same MBMS session in the same NodeB, a separate Iub transport bearer has to be set up for
each cell. An example is shown in the following figure assuming 3 cells in one NodeB. Three
copies of exact same MBMS session data are sent via Iub from CRNC to NodeB, which is a
big waste of Iub bandwidth.
CN CRNC Node B
Iub transport bearers
MBMS stream
To maximize saving of Iub bandwidth, the latest 3GPP Rel-6 provide FACH transmission
sharing for MBMS solution to share transport bearers. RNC transports only single FACH data.
NodeB transport module performs data duplication and distributes them to different FACH
Channels, as shown in the following figure, where the common transport bearer is shared over
Iub. Obviously, two-third of Iub bandwidth is saved by the improved Iub transport.
CN CRNC Node B
MBMS stream Iub transport bearer
The feature has optimization in the control plane. Bearer multiplexing information is carried
by additional NBAP signaling messages. The advantage of this solution is that current MBMS
FP structure is kept unchanged. However, new NBAP signaling is needed. And due to lack of
knowledge of NodeB’s capability to share transport bearer, CRNC always sends message of
bearer multiplexing request to NodeB no matter whether NodeB can/will share transport
bearer or not. For NodeB which can not or would not like to share, the message is a waste.
Enhancement
None
Dependency
Benefits
Iub transport resource can be saved much.

1.39 WRFD-010624 MBMS 8 Channels per Cell

Availability
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 64, 128, or 256Kbps.
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,792Kbps. The MBMS channel bit rate can be 16, 32, 64, 128, or 256Kbps.
Dependency
Benefits
It provides the operator the flexibility to deploy more MBMS services in a cell.

1.40 WRFD-010625 256Kbps Channel Rate on MBMS

Availability
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.
Dependency
Benefits
The operator can deploy high bit-rate services to provide better user experience.

1.41 WRFD-010626 MBMS FLC (Frequency Layer

Convergence)/FLD (Frequency Layer Dispersion)
Availability
Description
Frequency Layer Convergence denotes the process where the UTRAN requests UEs to
preferentially re-select to the frequency layer on which the MBMS service is intended to be
transmitted. This layer preference could be done by an additional MBMS session related
Layer Convergence Information (LCI) such as offset and target frequency. The FLC is
supported by specifications for both networks utilizing HCS and for networks not utilizing
HCS.
Frequency Layer Dispersion (FLD) denotes the process where the UTRAN redistributes UEs
across the frequencies. UTRAN can use FLD per MBMS session.
When FLD is applied, the UE stores the frequency where it was camped previously. Upon
session stop, the UE attempts to return to that frequency.
Enhancement
None
Dependency
UE should support this function.
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.

1.42 WRFD-010628 MBMS 16 Channels per Cell

Availability
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
Dependency
Benefits
It provides the operator the flexibility to deploy more MBMS services in a cell.

1.43 WRFD-010661 MBMS over Iur

Availability
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, DRNC informs SRNC more MBMS service control information through Direct
Information Transfer.
Dependency
The neighboring RNC should support MBMS Iur function.
Benefits
Provide completed functions of MBMS over Iur, Keep the MBMS service continuity and
improve user perception.

1.44 WRFD-010662 Dynamic Power Estimation for MTCH

Availability
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
Dependency
Benefits
Cell power can be saved by making use of soft combining gain with neighbors.

1.45 WRFD-010663 MSCH and MSCH Scheduling

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

l One cell supports up to 8 MSCHs (in the case of 16 MTCHs and 8 S-CCPCHs)
l Restriction: If one S-CCPCH bears only one MTCH, then the MSCH should not be used.
Enhancement
None.
Dependency
Benefits
MSCH enables the UE to perform DRX on the MTCH and thus to save power consumption of
the UE.

1.46 WRFD-010665 MBMS Channel Audience Rating

Statistics
Availability
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
None.
Dependency
The BMSC on the CN side shall identify the channels with a fixed TMGI when delivering the
program source.
Benefits
This feature provides operators with information about channel audience rating and
familiarizes operators with the usage of system resources by MBMS channels.

1.47 WRFD-011000 Cell Broadcast Service

Availability
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
In RAN6.0, 4 CBCs can be supported instead of 1 CBC before.
Dependency
UE should have the capability to receive cell broadcast messages.
Benefits
The users can use the new services based on the CBS.

1.48 WRFD-020801 Cell ID + RTT Function Based LCS

Availability
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).
TOA= (RTT-UeRxTx)/2
UE1 NodeB NodeB
UE2
UE selection the best cell for location

reference when UE in soft handover state NodeB
The TOA can be derived by the NodeB RTT (Round Trip Time) measurement and the UE
Rx-Tx time difference Type 2 measurement.

R T T M e as ure m en t
N od e B
UE
U E R x-T x tim e d ifferen c e
T ype 2 M ea s u rem en t
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 locates in the different RNC, the location over Iur is supported.
Enhancement
In RAN3.0, location over Iur interface is supported in RAN5.1.
Dependency
UE is needed to report the relevant measurement results.
CN is needed to trigger the location request.
Benefits
This feature provides a location service for operators.

1.49 WRFD-020802 OTDOA Based LCS

Availability
Description
Huawei supports the IPDL-OTDOA location services. To support this method, RNC initiates
and keeps tracking GPS timing of cell frame measurements from NodeBs that deploy a GPS
card and support the GPS timing of cell frame measurement, and it initiates and keeps
tracking 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 requests RTT measurement from NodeB and relative
Rx-Tx time difference measurement from UE.
Enhancement
None
Dependency
The corresponding NodeBs should be equipped with GPS card.
Benefits
This feature provides a location service for operators.

1.50 WRFD-020803 A-GPS Based LCS

Availability
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 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
In RAN5.1, location over Iur interface is supported.
Dependency
If GPS receiver is located at RNC, clock board such as GCGa is required to support this
feature.
If GPS receiver is located at Node B, main process board with GPS such as WMPT (with GPS)
is required to support this feature.
Benefits
This feature provides a highest accuracy location service.

1.51 WRFD-020804 LCS Classified Zones

Availability
Description
The RNC supports mapping a classified zone set by OAM to a specific Service Area. When a
mobile enters or leaves a classified zone, the RNC will generate a location report and send the
location report to corresponding CN through Location Report procedure. In LOCATION
REPORT message, the Service Area of the UE in the Area Identity IE will be included. The
CN shall react to the LOCATION REPORT message with service vendor specific actions.
Enhancement
None
Dependency
CN node must support this feature simultaneously.
Benefits
Operator can provide the information and service for subscriber forwardly according to the
location of user.
The subscriber can obtain the information related to own location as soon as possible in
moving.

1.52 WRFD-020805 LCS over Iur

Availability
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 ).
DRNC Site 2
DS-RTx
.
MSC SRNC
Site 1
Dedicated measurement over Iur for RTT

Iur dedicated measurement procedure for acquisition of RTT is illustrated in figure below.

SRNC DRNC
DEDICATED MEASUREMENT INITIATION REQUEST
(Measurement Type: RTT)
DEDICATED MEASUREMENT INITIATION RESPONSE
DEDICATED MEASUREMENT REPORT

(Measurement Value: RTT)
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.
SRNC DRNC
INFORMATION EXCHANGE INITIATION REQUEST

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

(Geographical Coordinates)
l A-GPS
GPS information is required by A-GPS positioning. RNC maintains the updated GPS data
from RNC itself or neighboring RNCs. The obtain GPS data from neighboring RNCs,
information exchange procedure over Iur should be performed, once the reference GPS
receiver is configured.
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.

RNC 1 RNC 2
(Information Type: GPS Information)
INFORMATION REPORT
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.
SRNC DRNC

(Information Type: UTRAN Access Point Position)
Enhancement
None
Dependency
WRFD-020801 Cell ID + RTT Function Based LCS
or WRFD-020803 A-GPS Based LCS
The neighbouring RNC should support the information exchanging and related procedures.
Benefits
As enhancement to location service, positioning area is wide extended, and more reliable and
precise positioning capability is also achievable.

2 RAN Architecture & Functions
2.1 WRFD-010203 Transmit Diversity

Availability
Description
There are several transmit diversity modes adopted in WCDMA 3GPP, namely the Time
Switched Transmit Diversity (TSTD) mode, Space Time Transmit Diversity (STTD) mode,
and Closed Loop Transmit Diversity Mode1 (CLD1). The TSTD and the STTD are open loop
transmit diversity, which do not need feedback information compared with the closed loop
diversity. The following table summarizes the possible application of open and closed loop
transmit diversity modes on different types of downlink physical channels.

Physical channel type Open loop mode Closed loop mode

TSTD STTD Mode 1
P-CCPCH – X –
SCH X – –
S-CCPCH – X –
DPCH – X X
PICH – X –
MICH – X –
HS-PDSCH – X X
HS-SCCH – X –
E-AGCH – X –
E-RGCH – X –
E-HICH – X –
AICH – X –
If a cell works in TX diversity mode, the CPICH, PCCPCH, and SCH of the cell must also
work in TX diversity mode.
There are two types of physical channels (DPCH, HS-PDSCH) which can use the Closed
Loop Transmit Diversity Mode1 (CLD1). Huawei RAN supports this feature in RAN6.0.
Enhancement
In RAN5.0, with the HSDPA feature deployed, STTD for HS-PDSCH and HS-SCCH is
supported.
In RAN6.0, with the HSUPA feature 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 NodeB to provide two times RF channel resources compared with
no TX diversity mode. In TX diversity mode, the UE must support diversity reception, STTD,
TSTD, and CLD1. This diversity mode has no special requirements for the RNC.
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.

2.2 WRFD-010209 4-Antenna Receive Diversity

Availability
Description
Receive diversity refers to a technique of monitoring multiple frequencies from the same
signal source, or multiple radios and antennas monitoring the same frequency, in order to
combat signal fade and interference.
Receive diversity is one way to enhance the reception performance of uplink channels. It does
not involve RNC or UE.
Huawei NodeBs support both RX diversity and none RX diversity. In RX diversity mode, the
NodeB can be configured with 4 antennas (4-way), and 4 antennas for economical purpose
(4-way economical) through the Antenna Magnitude parameter. The only difference between
4-way and 4-way economical modes is that in the latter mode signals on the random access
channel are received from two antennas, , but the Dedicate channel are received from four
antennas.
In RX diversity mode, the NodeB does not require additional devices and works with the
same algorithms. The 4-way RX diversity requires twice the number of RX channels
compared with 2-way RX diversity. The number of RX channels depends on the settings of
the antenna connectors on the cabinet top.
Enhancement
None
Dependency
The RX diversity requires the NodeB to provide enough RF channels and demodulation
resources that can match the number of diversity antennas. It has no special requirements for
RNC or UE.
Benefits
It can improve receiver sensitivity and uplink coverage, so that the CAPEX is reduced.

2.3 WRFD-010210 Control Channel Parallel Interference

Cancellation (CCPIC)
Availability
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.
DPCCH demodulation is completed ahead. According to all valid paths’ time delay and fading
information of received users, the received DPCCH siganl can be reconstructed. All users’
data channel such as DPDCH, E-DPCCH and E-DPDCH can be demodulated after the
received DPCCH signal is subtracted from baseband signal.
In the presence of urban macro cell, TU3 channel, AMR12.2k user with a 50% load, the
CCPIC will bring 11% capacity improvement；with a 75% load, the capacity improvement is
18%.
Enhancement
None
Dependency
The CCPIC depends on the EBBC board or EBBI, EBOI, EULP.
Benefits
It can improve capacity, so that the CAPEX is reduced.

2.4 WRFD-021102 Cell Barring

Availability
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, as a matter of fact, 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.
l So 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
Benefits
l Prevent the user from initiating the useless access when the Iu interface is down
l Ensure 3G users can move to the 2G network when the Iu interface breaks down
l Provide the operator with the flexibility in some scenarios (e.g. for maintenance purpose)

2.5 WRFD-021103 Access Class Restriction

Availability
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
Benefits
Reduce signaling overload (call attempts) to increase network accessibility.
Reduce CN Overload.

2.6 WRFD-021303 IMSI Based Handover

Availability
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 does not need to support the feature Shared Network Support in Connected
mode. But if Iur interface is involved, the connected RNC should also support the feature.
Benefits
With this feature, the RNC can prevent UE in connected mode from moving to an
un-subscribed area without CN support, and it can also be used as a supplement feature for
implementing shared networks solutions.

2.7 WRFD-021304 RAN Sharing Introduction Package

Availability
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, NodeBs,
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
form TMSI/P-TMSI, when Iu-Flex is used. The following figure shows the RAN sharing
solution architecture.

Operator A Operator B
CN CN
Operator A OSS Operator B OSS

Iu interface
Itf-N
iM anagerTM M 2000
RNC
Iub
Shared Master OSS interface
Macro
Node B
RRU
Shared RAN
In RAN sharing architecture, RNC is shared by multiple operators (maximum is 4), and the
CN networks are supplied by operators separately. For the shared RNC, both shared and
non-shared NodeB/RNC could be connected. For each operator’s CN network, Iu Flex may be
applied, and the decision could be made independently.
RAN sharing solution does not require any UE release dependency. The call traffic is routed
to appropriate CN network belonging to the operator selected by UE. In the shared RAN,
inter-system handover and intra-system handover within each operator are handled normally.
A switch is supplied to indicate whether intra-system handover between operators would be
allowed. For broadcast service such as CBS and MBMS, the traffics will be restricted in each
operator’s dedicated cells.
Enhancement
None
Dependency
None
Benefits
The most important and urgent driving for 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.

2.7.1 WRFD-02130401 Dedicated Carrier for Each Operator

Availability
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, illustrated below.
Operator one Shared RNC Shared Node B
Frequency one Frequency one MNC

Operator two one
Frequency two Frequency two MNC

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
WRFD-021304 RAN Sharing Introduction Package
Benefits
For license holders, distinct cost saving would be achieved, including the CAPEX and OPEX,
because all the RAN elements could be shared.

2.7.2 WRFD-02130402 Flexible Network Architecture

Availability
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 capability
will be split by all operators.
For example illustrated in figure below, operator A adopts the Iu Flex while Operator B does
not.
MSC 1
MSC 2
MSC 3 MSC
Operator A Operator B
SGSN
SGSN 1
SGSN 2
Shared RNC
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.
SAs of Operator A
Operator A CBC-A
Shared
RNC
Operator B CBC-B
SAs of 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 NodeBs. But, it’s not precluded that non-shared NodeB may exist. In this RAN
sharing solution, both shared and non-shared NodeB are allowed to connect to the shared
RNC. Please refer to the following figure.
Operator A
Shared by
Shared Operator A & B
RNC
Shared by
Operator A & B
Operator B
l Iur interface
It’s similar to Iub interface, both shared RNC and non-shared RNC could be connected
to a shared RNC.
Enhancement
None
Dependency
Benefits
Various requirements can be met with the help of the flexible architecture. Differentiated
service and effective cost are also achievable.

2.7.3 WRFD-02130403 Mobility Control and Service

Differentiation
Availability
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. For example (illustrated in figure below), if UE initiated call from one cell
belongs to operator B’s, then initial NAS message will be routed to operator B’s CN
network.
Operator A
CN
Shared
RNC
Operator B
CN
Originated Cell Target CN network
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.
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 by 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.

MBMS SAs of
Operator A
Operator A
BM-SC SGSN
Shared
RNC
Operator B
BM-SC SGSN
MBMS SAs of
Operator B
l Mobility control
Inter-operator handover is usually forbidden by operators, but it would not be precluded.
A configurable flag is supplied to indicate whether inter-operator intra-system handover
is allowed, and the default is not. For inter-system handover, it’s handled normally.
Enhancement
None
Dependency
Benefits
Based on the service differentiation mechanism, operators that share the RAN can deploy
different service provision strategy to their subscribers.

2.7.4 WRFD-02130404 Independent License Control

Availability
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, i.e. one operator may choose some optional features but the others do not. For all the
optional features, there 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 B
could not.
Enhancement
None
Dependency
Benefits
With independent license control, total capacity of the physical RNC will be shared by
operators, and each can take specific proportion.

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

Availability
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 NodeB CE utilization, cell traffic throughput, etc.
RAN also supports non cell-level measurement, which is shared by operators. Items are
RNC/NodeB 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
Benefits
Providing Independent Cell-level FM/PM/CM

2.7.6 WRFD-02130406 Transmission Recourse Sharing on Iub/Iur

Interface
Availability
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 by NCP (NodeB control port), CCPs, ALCAP link (not
applicable for IP transmission scenario), OM path and a number of user plan links.
For each NodeB, only one unique NCP could exist. Though generally multiple CCPs
may exist, but they had better work in load sharing mode. In normal case, the ALCAP
link is also the unique one for each NodeB. Shared OM path for one NodeB is also
proposed, because the NodeB is shared, though multiple OM paths are allowable, but it
brings no benefit. So, the control plane links (NCP, CCP, ALCAP link) should be shared
by operators.
To achieve effective transmission resource usage, user plane links are also shared by
operators.
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
Benefits
Transmission resource consumes much cost. 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.

2.8 WRFD-021305 RAN Sharing Phase 2

Availability
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.
Dependency
Benefits
In the shared RAN, operator’s differentiated QoS requirement is guaranteed with this feature.

2.8.1 WRFD-02130501 Dedicated Iub Transmission Control

Availability
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).
NCP bandwidth
Must be shared CCPs bandwidth
ALCAP bandwidth
O&M bandwidth
Could be dedicated User plane

or shared bandwidth
For user plane bandwidth, the shared mode is supplied in phase 1, while phase 2 supports
dedicated mode. In dedicated mode, operator dedicated logical resource group is introduced,
which aims to separate the user plane bandwidth between operators.
For logical resource group, two different cases are applicable. In case 1, physical link is
common to all groups. In case 2, physical links are dedicated to each group. Both cases will
be supported. These two cases are illustrated as follows.
I. Case 1
GROUP-A
Physical Link
GROUP-B
II. Case 2

Physical Link GROUP-A
Physical Link GROUP-B
When creating a logical group, it is specified that to which operator the bandwidth belongs to,
the maximum bandwidth that could be used. To achieve the separate resource management,
each operator’s dedicated group should contain some user plane links, and then the contained
links become also operator dedicated.
Based on the dedicated logical resource group, admission control and congestion control are
executed separately from each operator.
l Admission Control
In this feature, admission control for transmission resource is performed separately without
conflict between operators, i.e. for each operator’s call traffic, needed 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). Please refer to the example in the following figure.
l Congestion Control
In this feature, congestion control of transmission resource is also executed seperately.
Congestion is detected and reported independently for operator dedicated group, and only its
own users would be the target of the following control actions. For example (please refer to
the following figure), if congestion happens to Group-B (owned by operator B), only users
that belong to operator B will then be involved.

Besides the admission control and congestion control, the flow control for the HSDPA is also
isolated between operators.
l HSDPA flow control
Refer to above figure, HSDPA flow control is separately executed 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.
Dependency
Benefits
In the shared RAN, operator’s differentiated QoS requirement is guaranteed with this feature.

2.9 WRFD-021311 MOCN Introduction Package

Availability
Description
MOCN, introduced in the 3GPP R6 protocols, is known as one of the access network sharing
modes. In addition to access nodes such as RNC and NodeB, MOCN also shares the carriers.
The network architecture of MOCN is shown below:
Different from RAN Sharing that uses independent carriers, MOCN uses common carrier
resources. Similar to RAN Sharing, the Core Network (CN) in MOCN is independent, that is,
the CN nodes belong to different operators. When multiple operators share common carrier
resources, the users of these operators have cell resources in common. In this respect,
compared with RAN Sharing, MOCN can better utilize resources.
MOCN introduction package has the following features:
l Common carriers shared by operators
l Dedicated NodeB or cell for operators
l MOCN mobility management
l MOCN load balancing
l MOCN independent performance management
Enhancement
None.
Dependency
The CN and UE should support the MOCN function.
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.

2.9.1 WRFD-02131101 Carrier Sharing Among Operators

Availability
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 also 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 the selected PLMN ID to the RNC through the initial
direct transfer message. The RNC selects a CN node for the non-supporting UE based on the
redirection function. For non-supporting UE, RNC set the PLMN in LAI as Common PLMN
when constructing the LAI parameters in initial UE message. At the same time, all the
operators with different PLMN need configure Common PLMN in the list of Equivalent
PLMN.
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
support these pre-R6 UEs which implement MOCN independently.
Enhancement
None.
Dependency
WRFD-021311 MOCN Introduction Package
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.

2.9.2 WRFD-02131102 Dedicated NodeB/Cell for Operators

Availability
Description
To satisfy the special requirements of different operators, the RNC can not only connect to a
shared NodeB of multiple operators (known as MOCN NodeB), but also connect to a
dedicated NodeB, namely, non-shared NodeB which serves one operator only, as shown
below:
The dedicated NodeB belongs to Operator A only; therefore, all the UEs that access the
network from this NodeB will be connected to the CN node of Operator A.
For MOCN NodeB, some cells of the shared NodeB can be dedicated to one operator and
serve this operator only. The RNC supports the dedicated cell for an operator.
Enhancement
None.
Dependency
Benefits
Through dedicated NodeBs/Cells, the operators can flexibly set the network sharing areas to
meet various requirements for network sharing and scenarios.

2.9.3 WRFD-02131103 MOCN Mobility Management

Availability
Description
Generally, inter-operator handover is prohibited, but there are some exceptions. The RNC
provides a flag implying that the inter-operator handover within the system is allowed. The
flag can be configured by operators although the inter-operator handover is prohibited by
default. If the flag is provided, it indicates that the UE movement is not limited by operators.
The inter-RAT handover between operators is allowed no matter what the flag is.
MOCN mobility management prevents the UE from being handed over to the cells that
belong to a different operator when the inter-operator handover is prohibited. The handover of
UEs include soft handover, hard handover, intra-frequency handover, and inter-frequency
handover.
Enhancement
None.
Dependency
Benefits
l Ensures the service continuity of the shared network
l Enhances user experience
l Provides more flexible mobility management solutions
l Meets operators' different requirements for network sharing
2.9.4 WRFD-02131104 MOCN Load Balance

Availability
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.
Dependency
Benefits
This feature ensures the balance of load and the fairness of network sharing between different
operators.

2.9.5 WRFD-02131105 MOCN Independent Performance

Management
Availability
Description
The RNC supports independent performance management for different operators. That is to
say, the operators can obtain their specific information about network operation, such as
traffic volume and network quality.
In addition, the performance counters related to MOCN, for example, the redirections with
various causes are added to the RNC performance counters.
Enhancement
None.
Dependency
Benefits
With this feature, the operators can obtain their specific information about network operation,
such as traffic volume and network quality.

2.10 WRFD-021302 Iu Flex

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

MSC 3 MSC 6
MSC 2 MSC 5
MSC 1 MSC 4 MSC 7
CS pool-
CS pool-
area 2
area 1
RAN RAN RAN RAN

node node node node
Area 1 Area 2 Area 3 Area 4
RAN RAN RAN RAN

node node node node
Area 5 Area 6 Area 7 Area 8
PS pool-area 1 PS pool-area 2
SGSN 1 SGSN 3 SGSN 6

SGSN 2 SGSN 4
SGSN 5
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 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
l 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 load are the same, they will be
selected by turns.

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 in RAN6.1
Dependency
Require MSC and SGSN support such feature at the same time.
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
l In conclusion, the Iu Flex greatly enhances the serviceability of the whole network

2.11 WRFD-021306 Iu Flex Load Distribution Management

Availability
Description
This feature includes enhanced load balancing and load re-distribution. It's applicable for both
CS domain and PS domain.
Enhanced load balancing
As 3GPP TS 23.236, when IMSI V value is carried by UE, RNC may routes the IDT message
based on the pre-configured IMSI routing parameters, i.e. The mapping relationship between
IMSI V value and CN-Id. Actually, it's a 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. Since the capacity of the connected MSCs (CS domain) / SGSNs (PS domain) differ
with each other, so the capacity of each MSC/SGSN should be take in 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 INFORMATION TRANSFER IND and
INFORMATION TRANSFER CONFIRM messages with Huawei private extension IE.
Load Re-distribution
This feature is introducing in 3GPP Rel'6 specification, which make it possible for
MSC/SGSN to off-load. It's helpful for some specific cases, such as safely preparation for
migration of MSC/SGSN, quickly restore the load of MSC/SGSN recovering from failure, etc.
For load re-distribution, two important identities are introduced, which is called "null-NRI"
and "Non-broadcast LAI/RAI".
This procedure is initiated from MSC/SGSN side, and cooperated by RNC. 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, and "Null-NRI" will be
carried in the following IDT message, 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:
l VS.LdBalRt.IMSI: The user number that was routed to CN node according to IMSI
during the load balance procedure.
l VS.LdBalRt.InValidNRI: The user number that was routed to CN node, where the user’s
NRI is invalid, during the load balance procedure.
l 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.
Dependency
WRFD-021302 Iu Flex
Benefits
Improving the performance and meet the operator’s load distribution strategy in Iu Flex
networking scenario.

2.12 WRFD-021308 Extended Cell Coverage up to 200km

Availability
Improved cell Coverage was available from RAN 3.0.
Description
The feature helps to coverage such scenario: low capacity, ultra coverage, such as sea, desert,
and rural coverage. 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, provided that 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 (Uni BTS), 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 WBBP can support 6 cell-carriers.
The improved cell coverage does not require additional hardware, but the environment will be
requested open and flat like sea coverage. The antenna will be installed on the hills or 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 200km.
Dependency
None
Benefits
Improve the cell coverage to enable the ultra coverage with the minimal site number.

2.13 WRFD-021309 Improved Downlink Coverage

Availability
Improved cell Coverage was available from RAN 6.1.
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 is -119 dBm, therefore, improve
the downlink coverage compared to the original -115dBm.
Such parameter deltaqrxlevmin can be configured by operator.
Enhancement
None
Dependency
WRFD-021308 Extended Cell Coverage up to 200km
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.

2.14 WRFD-010206 High Speed Access

Availability
High speed access feature was available from RAN 5.1.
Description
At present, high speed railways in some countries and regions has reached 200 km/h or even
300 km/h. The top speed of the maglev railway built in Shanghai, China, reaches 430 km/h.
The Doppler shift caused by high speed movement of the UE is reflected on the signals
received on the Node B baseband units. Therefore, a RAKE receiver is required for the
implementation of the AFC function.
The function of Automatic Frequency Control (AFC) is required for the NodeB to support
high speed access. A RAKE receiver not supporting AFC is unable to correctly demodulate
signals even if the signal-to-noise ratio infinitely increases when the frequency offset reaches
800 Hz or above. Then, a call may drop or is unable to be connected.
The UL channel can be classified into the UL dedicated physical channel (DPCH) and the UL
physical random access channel (PRACH). Therefore, the NodeB must support AFC both for
the UL DPCH and for the UL PRACH. AFC for PRACH could be enabled or disabled
through the High Speed Movement Mode parameter. The frequency offset value is mapped to
the maximum moving speed in LMT, through the Speed Rate (km/h) parameter.
The high speed access has the following impact on the other features:
l The high speed access is not supported in 4-way receive configuration..
Enhancement
None
Dependency
None
Benefits
High speed access is one of the key features in the differential solution for high speed
coverage. The NodeBs using high speed access support coverage under which the moving
speed of UEs can reach above 400 km/h.

2.15 WRFD-011500 PDCP Header Compression (RFC 2507)

Availability
Description
This feature support header compression function of packet data according to RFC 2507,
which can remove the redundancy of information, such as the head of TCP/IP.
The system shall compress the redundant protocol header before transmitted on a link. At the
same time, the system can decompress the received data.
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.
Dependency
UE should support the compression function.
Benefits
This feature can reduce the throughput of the air interface and increase the efficiency of the
radio link.

2.16 WRFD-011501 PDCP Header Compression (RoHC)

Availability
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 facts that
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 in the PDCP protocol layer which locates in RNC and UE,
therefore, Iub bandwidth occupied can also 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 are used for VoIP. RoHC UDP and RoHC ESP are used in other scenarios when the
hander of packet is UDP/IP or ESP/IP.
The IPV4 and IPV6 header compression are all supported.
Enhancement
None
Dependency
UE should support ROHC compression function.
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

2.17 WRFD-011502 Active Queue Management (AQM)

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

2.18 WRFD-020302 Inter Frequency Hard Handover Based

on Coverage
Availability
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 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-frequency hard 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 frequency cells which indicate the handover successful rate can be
guaranteed, such parameter will be certain as the result of 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
described in WRFD-020103 Inter Frequency Load Balance.
l Speed-based

This trigger condition is based on the UE speed which RNC evaluated, and such feature
is the optional feature which described in WRFD-021200 HCS (Hierarchical Cell
Structure).
In multi frequency band networking scenario which 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 band is supported and UE measurement capability will be considered to guarantee
UE will not handover 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.
Enhancement
In RAN3.0, event report mode is supported additional to period mode.
In RN5.1, compressed mode 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 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, inter-frequency handover triggered by limitation of UE Tx power is available for
PS BE, CS AMR and VP services.
Dependency
UE should support the relevant measurements and the procedure of handover.
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.

2.19 WRFD-020304 Inter Frequency Hard Handover Based

on DL QoS
Availability
This feature is introduced in RAN10.0
This feature is introduced in 3GPP R99
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-frequency handover could be
triggered if in inter-frequency networking:
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
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 end user experience.

2.20 WRFD-020605 SRNS Relocation Introduction Package

Availability
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 detail, please
refer to the enhancement of the features in the package.
Dependency
The CN node must support this feature simultaneously.
The SRNC and DRNC must support this feature simultaneously.
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.

2.20.1 WRFD-02060501 SRNS Relocation (UE Not Involved)

Availability
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.
Dependency
WRFD-020605 SRNS Relocation Introduction Package
The CN node must support this feature simultaneously.
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

2.20.2 WRFD-02060502 SRNS Relocation with Hard Handover

Availability
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 no enough resources that
make it possible to setup a connection through Iur interface.
In such scenarios, the UE is ordered to be relocated to a new RNC with hard handover to
prevent call drop.
Enhancement
None
Dependency
The SRNC and the DRNC must support this feature simultaneously.
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.

2.20.3 WRFD-02060503 SRNS Relocation with Cell/URA Update

Availability
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 Iur interface between the 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
Dependency
Benefits
It ensures that communications are not interrupted when the UE in CCH state moves to the
coverage area of another RNC.

2.20.4 WRFD-02060504 Lossless SRNS Relocation

Availability
Description
Lossless SRNS relocation is used to forward the context in SRNS and DL N-PDU duplicates
towards the relocation target RNC during the relocation procedure. That is, the RNC supports
the maintenance of PDCP sequence numbers for radio bearers which are used to forward data
not acknowledged by the UE. With this feature, the higher layer in user plane does not need to
resend the data lost during relocation procedure; therefore, the best effort service performance
is improved.
Enhancement
None
Dependency
Benefits
This feature helps to keep the data transfer integrity and continuity, and improve the best
effort service performance in the SRNS relocation procedure.

2.21 WRFD-020303 Inter-RAT Handover Based on

Coverage
Availability
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.
Since the GSM/GPRS system cannot perform CS and PS services simultaneously, when CS
and PS domain combined services are decided to handover, the CS service will handover 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
including 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 be different for CS and PS
services respectively.
In multi frequency band networking scenario which 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
handover 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, CS AMR
services
Dependency
UE should support the relevant measurements and the procedure of handover 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.

2.22 WRFD-020307 Video Telephony Fallback to Speech

(AMR) for Inter-RAT HO
Availability
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 Release6, 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 side. When it is triggered by the
UE, the CN will initial a RAB Assignment (Modify) procedure over the Iu interface
when receiving the fallback request from 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 RNC A MSC A MSC B UE B
RANAP RAB Assignment

(configuration1, configuration 2)
RANAP Modify Request

(alternate configuration requested)
MODIFY
(BCspeech)
MODIFY
(BCspeech)
MODIFY COMPLETE Core Network
(BCspeech) Procedure
RAB Assignment Modify MODIFY COMPLETE

(Configuration 2, Configuration1) (BCspeech)
Firstly, the MSC must assign the alternative configuration when setting up a VP service so as
to let UTRAN know it has the fallback capability.
When the user with such VP service has to handover to 2G system, the RNC will initial a
RAB modify request to trigger fallback, then fallback will be implemented by the MODIFY
procedure. From UTRAN view, it is corresponding to the RAB Assignment (Modify)
procedure over the Iu interface.
After the VP service falls back to speech successfully, the following speech inter-RAT
handover can be implemented.
Enhancement
None
Dependency
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.
Benefits
This feature provides an inter-RAT handover mechanism for the VP service which falls back
to speech instead of call drop.

2.23 WRFD-020308 Inter-RAT Handover Phase 2

Availability
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
Dependency
WRFD-020303 Inter-RAT Handover Based on Coverage
or WRFD-020305 Inter-RAT Handover Based on Service
UE and SGSN should also support NACC and PS handover.
BSC should support NACC RIM (RAN Information Management) and PS handover
procedure.
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 improved greatly
especially for the real-time PS service.

2.23.1 WRFD-02030801 NACC (Network Assisted Cell Change)

Availability
This feature is available from RAN6.1 (BSC6810 only).
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 are capable of NACC, then RNC will firstly trigger the RIM procedure. If it is
acquiring (P)SI successfully, cell change order from UTRAN message with GERAN (P)SI
information will be sent, i.e. NACC performed, illustrated in figure below. Otherwise, normal
cell change order would be performed.
UE SRNC SGSN BSC

RRC MEASUREMENT REPORT
WITH GERAN BEST CELL DIRECT INFORMATION
TRANSFER (RAN IFORMATION
REQUEST)
RAN INFORMATION
RAN INFORMATION
DIRECT INFORMATION
TRANSFER (RAN
INFORMATION REPORT)
CELL CHANGE ORDER FROM

UTRAN ( (P)SI )
Enhancement
None
Dependency
WRFD-020308 PS Inter-RAT Handover Phase 2.
Benefits

About 4 to 8 seconds of service interruption time will be shortened by NACC, comparing

with the normal cell change. The user experience would be improved obviously with this
feature.

2.23.2 WRFD-02030802 PS Handover between UMTS and GPRS

Availability
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
extremely.
In this feature, both handover from UTRAN to GERAN and handover from GERAN to
UTRAN are supplied. If both UE and network support PS handover, handover between
UTRAN and GERAN would be performed. Otherwise, either NACC or normal cell change
order would be selected.
Enhancement
None
Dependency
WRFD-020308 PS Inter-RAT Handover Phase 2.
Benefits
With this feature, user experience is improved extremely and would be acceptable even for
real-time PS service.
With this feature, in the scenario of inter-RAT handover, the user experience will be improved
greatly especially for the real-time PS service.

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

Availability
Description
The 3G/2G Common Load Management applies to inter-RAT handover and inter system
direct retry. The load of source cell and target cell are considered during inter-RAT handover
from 3G to 2G or from 2G to 3G and inter system direct retry.
During inter-RAT handover from 3G to 2G, the RNC will send the load information of the
source cell to 2G through RELOCATION REQUIRED message and may get the load
information of target cell from RELOCATION COMMAND message. If the load of target
cell is in a high level (over the threshold configured) and the inter-RAT handover from 3G to
2G is triggered not because of coverage, then the inter-RAT handover from 3G to 2G will be
cancelled.
During inter-RAT handover from 2G to 3G, the RNC may get the load information of the
source cell from RELOCATION REQUEST message. If the load of source cell is not in a
high level (less than the threshold configured) and the inter-RAT handover from 2G to 3G is
triggered not because of coverage, then the inter-RAT handover from 2G to 3G will be
refused.
During inter system direct retry, the procedure and decision is similar to that of inter-RAT
handover from 3G to 2G. If the load of target cell is in a high level (over the threshold
configured), inter system direct retry will be cancelled.
Enhancement
None
Dependency
WRFD-020305 Inter-RAT Handover Based on Service
or WRFD-020400 DRD Introduction Package
or WRFD-020308 Inter-RAT Handover Phase 2
CN and BSS should support this feature.
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.

2.25 WRFD-021200 HCS (Hierarchical Cell Structure)

Availability
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 is supported.
Cell Type Characteristic

Macro Cell Large coverage
Continuous coverage networking
Low requirement on capacity
Fast-moving environment
Micro Cell Densely populated areas
High requirement on capacity
Slow-moving environment
Pico Cell Indoor coverage
Outdoor dead-area coverage
Where, the Pico cell has the highest priority and the macro cell has the lowest priority.
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 order the fast-moving UE to handover to the cells of
lower priority to reduce the number of handovers, and order the slow-moving UEs to
handover to the cells of higher priority to increase network capacity.
Enhancement
None
Dependency
None
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.

2.26 WRFD-011600 TFO/TrFO

Availability
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 codec and
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.
Enhancement
In RAN5.0, AMRC under TFO/TrFO is supported.
Dependency
The CN node needs to support the feature at the same time.
Benefits
This feature can prevent degradation of the speech quality introduced by the interpretation
between the different codec and TrFO can also save the transmission resources.

2.27 WRFD-010505 Queuing and Pre-Emption

Availability
Description
Queuing and Pre-emption are two functions related to access control and are methods for
differentiating services. It enables operator 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-emption 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 be 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 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. f
Dependency
This feature need the core network bring the ARP IE to RNC during RAB assignment
procedure so that RNC can get the service priority with those RAB parameters.
This feature requires optional feature WRFD-010610 HSDPA Introduction Package and
WRFD-010612 HSUPA Introduction Package when HSDPA / HSUPA queuing and
Pre-emption are required.
Benefits
This feature provides operators with a method to differentiate users according to their priority.
High priority user can obtain the system resources with high priority in case of resource
limitation. In this way, operator can provide better service to those high priority users.

2.28 WRFD-010506 RAB Quality of Service Renegotiation

over Iu Interface
Availability
Description
RAB Quality of Service Renegotiation over Iu interface is an action for R99 real-time service
during the LDR (Load Reshuffling) procedure so as 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
requirement.
Enhancement
None
Dependency
This feature needs the core network element to provide alternative configuration of Max Bit
Rate and Guaranteed Bit Rate and take further action to implement the real time service
negotiation procedure.
Benefits
This feature enables operator to reduce the cell load by downgrade real-time service bit rate.

2.29 WRFD-010507 Rate Negotiation at Admission Control

Availability
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.
1. Iu QoS negotiation
In Release 99, the UTRAN can only accept or reject a radio access bearer request from the
CN. For services that 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 which 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
The following load information will be considered to decide the initial bit rate:
− Uplink and downlink radio load states of the cell
− Iub resource state
− Minimum spreading factor supported
− HSPA capability, if the service related to HSPA, the UE-related 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 to admit. Otherwise, the bit rate

among negotiated maximum bit rate, guaranteed bit rate and alternative ones 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.
2. RAB downsizing
The RAB downsizing mainly aims to Best Effort (BE) service (interactive or background
service). In an ideal scenario, BE service can always access to the network with the maximum
request bit rate if there is enough cell resource, but such process cannot meet the system
capacity and performance requirements while 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
introduced.
In RAN10.0, RAB downsizing can also be applied when the request for adding new radio
links in the AS in soft/softer handover is rejected by admission control due to resource
limitation. The rate will be downgraded according to the cell load information, in order to
avoid the call drop due to soft handover failure.
In RAN11.0, the newly added policy is that the access of the PS service, if denied, allows an
access rate of 0 kbit/s or the implementation on the FACH.

RAN11.0 decides the downlink initial access rate of the R99 BE service on the DCH
according to the Ec/Io contained in the RRC CONNECTION REQUEST message. If the
Ec/Io is higher than the related threshold, the downlink initial access rate is min[384k, MBR]
(where MBR is the maximum bit rate assigned by the CN); if the Ec/Io is lower than the
threshold, the downlink initial access rate is the default value.
Dependency
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.
Benefits
l Provides a QoS negotiation mechanism which enhances the RAB SETUP procedure and
shortens the service setup time
l Greatly increases the call setup and hard handover success rate
l Maximizes the resource utilization and system capacity

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

Availability
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.
The trigger for AMR rate adjusting before RAN5.0 considered the downlink transmitted
power for DL and UE transmitted power for UL, when the transmitted power exceeds the
pre-defined threshold, implying a poor quality of the link.
In RAN5.1, cell load is used for AMRC trigger, where RNC will monitor the cell loading
continuously and dynamically to adjust the user’s speech code rate according to the change of
the cell loading. When the loading is heavy, low bit rate of AMR speech CODEC is used to
decrease the cell loading and when the cell loading is light, high bit rates of AMR speech
CODEC is used to provide higher voice quality for users.
The AMRC is one action to be done during the load reshuffling (LDR) procedure. The LDR is
one of the congestion control mechanisms triggered when NodeB Common Measurement
(TCP, Transmitted Carrier Power) for DL, and NodeB Common Measurement (RTWP) for
UL, exceed the 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
firstly selected 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 will depend on the downlink transmitted power for DL
and UE transmitted power for UL for rate increase, just using the same mechanism in
RAN5.0.
Enhancement
In RAN5.1, the AMRC is added as an action in basic feature WRFD-020106 Load
Reshuffling.
In RAN6.0, this feature can also be used to AMR-WB service which requires the optional
feature WRFD-010603 AMR-WB (Adaptive Multi Rate Wide Band).
Dependency
If this feature is to be applied to the AMR-WB, then the Dependency is:
WRFD-010613 AMR-WB (Adaptive Multi Rate Wide Band)

UE should support the processing of TFC control procedure.

Benefits
With the same transmitted power, lower AMR codec mode can provide larger uplink coverage
distance to expand the UL coverage.
When the radio environment is good, high codec mode can provide better voice quality than
low codec mode. When the radio environment is poor, low codec mode can provide better
voice quality than high codec mode. Therefore, the AMR codec mode should be adjusted in
real time to guarantee good voice service.

2.31 WRFD-020104 Intra-Frequency Load Balance

Availability
Description
This feature is used to change the cell load by adjusting cell PCPICH power.
The change of PCPICH power will enlarge or reduce the cell coverage which will affect the
UE in cell edge, especially those UEs in soft handover state.
When UE in soft handover, the PCPICH power change can make the cell be removed from
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 with one step. And if current cell load is less than the pre-defined under-load
threshold, the system will automatically increase the PCIPCH power with one step.
Enhancement
None
Dependency
None
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.

2.32 WRFD-020103 Inter-Frequency Load Balance

Availability
Description
This feature is an important action for Load Reshuffling (LDR). It enables the system to
perform inter-frequency blind handover that handover UE to inter-frequency neighbor cell,
reducing current cell load.
This action is triggered when system detects 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 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.
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.
Dependency
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.
Benefits
This feature is used to reduce the system load by handover UE to neighbor cells which can
keep the system in a safety state.

2.33 WRFD-020105 Potential User Control

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

2.34 WRFD-020305 Inter-RAT Handover Based on Service

Availability
Description
Inter-RAT Handover based on Service introduces a precondition for UMTS to GSM/GPRS handover
to UTRAN.
A service handover IE may be included in RAB ASSIGNMENT REQUEST message from CN. It
indicates to UTRAN the corresponding RAB should, should not, or shall not handover to
GSM/GPRS. It can trigger a handover to GSM/GPRS and can also influence decisions made
regarding UTRAN-initiated inter-system handovers.
If this indicator is not included in RAB ASSIGNMENT REQUEST message, the RNC can use its
pre-configured value for kinds of services.
Enhancement
None
Dependency
The CN support should be needed for the kind of condition in which the indicator is forwarded from
the CN.
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.

2.35 WRFD-020306 Inter-RAT Handover Based on Load

Availability
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 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.
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.
Dependency
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.
Benefits
This feature reduces the load of the cell in basic congestion and keeps the system in a safety state.

2.36 WRFD-020309 Inter-RAT Handover Based on DL QoS

Availability
This feature is introduced in RAN10.0
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
Dependency
None
Benefits
DL QoS based inter-RAT handover provides the method to prevent call drop and guarantee the QoS
in inter-RAT networking, therefore, improves the network performance and end user experience.

2.37 WRFD-020400 DRD Introduction Package

Availability
Description
The DRD Introduction Package includes following features:
l Intra System Direct Retry
l Inter System Direct Retry
l Inter System Redirect
Enhancement
None
Dependency
None
Benefits
These features can decrease the access failure rate and improve the QoS of the network.

2.37.1 WRFD-02040001 Intra System Direct Retry

Availability
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 new cell, inter-frequency or intra-frequency neighbor cell. This
decision is done according to the RACH report information from UE during RRC CONNECTION
REQUEST procedure since the RACH report information contains the neighbor cell quality. 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
Dependency
WRFD-020400 DRD Introduction Package
Benefits
Intra system Directed Retry can decrease the access failure rate, and improve the QoS of the
network.

2.37.2 WRFD-02040002 Inter System Direct Retry

Availability
Description
Inter System Direct Retry a feature used during Admission Control when a new call fails to access to
the network in the admission procedure. This feature is executed in RAB ASSIGNMENT procedure.
If a new call fails RAB ASSIGNMENT procedure during admission, the RNC will response a RAB
ASSIGNEMNT RESPONSE with the cause of “Direct Retry”. Then a relocation procedure will be
initiated by RNC with the cause of “Direct Retry”.
The following procedure is as the same as the normal inter-RAT handover procedure.
Enhancement
None
Dependency
Benefits
Inter system Directed Retry can decrease the access failure rate, and improve the QoS of the
network.

2.37.3 WRFD-02040003 Inter System Redirect

Availability
Description
Redirect feature is used during admission procedure when a new call is failed due to resource
unavailable. It occurs in RRC CONNECTION SETUP procedure.
When a UE initiates a RRC CONNECTION REQUEST and the request is refused in the original cell.
And RRC direct retry fails too. The system will send RRC CONNECTION REJECT message with
Redirection info indicating UE to access to an inter-system cell.
Compared with RRC Direct Retry procedure, UE will perform a new cell-reselection procedure in
inter-system Redirect.
Enhancement
None
Dependency
Benefits
Inter-system Redirect can decrease the access failure rate, and improve the QoS of the network.

2.38 WRFD-020110 Multi Frequency Band Networking

Management
Availability
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 are 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 are
needed to provides 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 particularly 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 benefits
will also be gained 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:

UL Frequencies DL frequencies
Operating Availability
Band UE transmit, NodeB UE receive, NodeB
receive transmit
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
Also, Huawei provides the full mobility solution between these frequency band and the mobility
between them and GSM cells, the mainly related features include:
l Cell selection / reselection
l Service distribution and Directed retry: Load Balance DRD is supported which enables the
RNC 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 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 inter frequency load balance or load based
inter-RAT handover, which depends on the optional feature WRFD-020103 Inter Frequency
Load Balance and 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
Dependency
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-020103 Inter Frequency Load Balance 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 are 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.
Benefits
Provide the seamless communication and improve the capacity when applying multi frequency band
networking scenario.

2.39 WRFD-020111 One Tunnel

Availability
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 really required 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
Dependency
Require GGSN and SGSN support such feature at the same time.
Benefits
This feature improves efficiency for PS traffic. It avoids SGSN to be the bottle neck of the network
while high PS traffic occurs.

2.40 WRFD-020113 Uplink Macro Diversity Intelligent

Receiving
Availability
Description
Through soft handover, the WCDMA system implements the power control and provides Macro
Diversity Combining (MDC) gains for the UEs in the overlapping area of handover. In this case,
however, additional resources need to be processed and transported. Particularly, when UL service
data rate is increased by HSUPA, more resources are consumed. Enhanced uplink MDC can increase
soft handover gains and also maximize resource utilization, thus reducing both CAPEX and OPEX.
Based on the factors such as transmission resources, service characteristics, and related measurement
reports, the SRNC can decide whether the traffic MAC-d flow on the E-DCH can support the uplink
MDC, that is, whether the Iub/Iur transport bearers (TBs) need to be established. In addition, the
SRNC can also decide that the MDC-supportive uplink data and the non-MDC-supportive uplink
data shall not be multiplexed in the same MAC-d flow, that is, they shall not be multiplexed in the
same Uu TB block.
In general, the high-speed non-real-time uplink services can be set as "Not requested for MDC",
because they utilize more transmission resources and provide lower MDC gains. The low-speed
real-time services, such as SRB and VoIP, can be set as "Requested for MDC". The SRNC can set
the "Transport Bearer Not Requested Indicator" of the corresponding MAC-d flow as follows:
A. Not Requested
B. Transport Bearer shall not be Established
C. Transport Bearer may not be Established
where:
l A means that the setting is compatible with the traditional mode.
l B means that the uplink macro diversity data need not be forwarded.
l C means that the NodeB can decide by itself whether to forward the uplink macro diversity
data.
When the non-serving NodeB receives the Radio link Setup Request message as mentioned
previously, it decides whether to establish the Iub transport bearer and forward the uplink data, and
then sets the "Transport Bearer Not Setup Indicator" in the corresponding MAC-d flow of the Radio
link Setup Response message as follows:
a. "Not requested", and allocates the "Binding ID and Transport Layer Address" of the Iub
transport layer
b. "Transport Bearer Not Setup"
where:
l A means that the setting is compatible with the traditional mode (which corresponds to A or C
of the Radio Link Setup Request message)
l b means that the NodeB confirms that the uplink macro diversity data need not be forwarded
(which corresponds to B or C of the Radio Link Setup Request message)

The previous selective UL MDC solution shows that the non-serving NodeB can choose to
demodulate part of the uplink data on the air interface. By setting an appropriate threshold, the
non-serving NodeB need not demodulate the big TBs for high-speed non-real-time services. Instead,
it should demodulate only the small TBs for low-speed real-time services and then forward the data
to the SRNC for MDC.
In addition, if all the MAC-d flows are set to "Not requested for MDC" or the non-serving NodeB
carries heavy load and lacks uplink demodulation resources, then after the non-serving NodeB
receives the SHO RL setup request message, it demodulates only the uplink control channels used
for load estimation and the control channels used for uplink transmit power adjustment indication by
the downlink transmitting UEs. In this case, not all the uplink data channels need to be demodulated.
That is to say, only the demodulation resources of the uplink DCCH and E-DCCH, and the
modulation resources of the downlink E-RGCH and F-DPCH need to be allocated. This is used to
control the neighboring cell interference and thus save the demodulation resources of the uplink data
channels for the non-serving NodeB.
Enhancement
None.
Dependency
Benefits
l Greatly saves the CE resources and transmission resources
l Improves resource utilization
l Enhances network performance
l Reduces the Total Cost of Operation (TCO) for operators

2.41 WRFD-020114 Domain Specific Access Control

(DSAC)
Availability
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:
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.
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.
When the DSAC function is triggered, based on logs and alarms, the operator can easily
monitor the DSAC status, network status, and the process of removing restrictions on access
classes, and so on.
Enhancement
None.

Dependency
Since this is a feature specified in 3GPP R6, only the UEs of R6 can support this function.
DSAC is based on the CN overload message and so the CN nodes should support this message on
the Iu interface.
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.

2.42 WRFD-020116 Dynamic Power Sharing of

Multi-Carriers
Availability
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.
Benefits
l Improves the network performance
l Increases the utilization of existing network equipment
l Increases the capacity of the HSDPA cell by 5% to 6% in the case of dynamic power sharing of
two carriers (based on the emulation)

2.43 WRFD-020117 Multi-Carrier Switch off Based on

Traffic Load
Availability
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 time. For example, the NodeB in the Central Business District (CBD) has
relative high traffic volume in the daytime which requires more than one carrier to serve all the
subscribers, but from midnight to early morning of the next day the traffic volume is relative low. In
RAN10.0, during idle periods which are configurable for operator, the RNC can dynamically shut
down the carrier which has no subscriber and the other carriers in the same area are in normal status.
The carrier will be turned on again while the traffic volume in the other carriers enters into LDR
status or the idle periods ends. The energy can be saved in this way.
Enhancement
None
Dependency
None
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

2.44 WRFD-020118 Energy Efficiency Improved

Availability
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 A-Doherty technologies. The power
efficiency of the PA reaches 40%, which reduces the power consumption of the entire NodeB.
Dynamically adjusting output power means that the PA dynamically adjusts the parameters
according to different output power so as to increase the PA efficiency and reduce power
consumption.
Enhancement
None.
Dependency
None.
Benefits
l Improves the efficiency of energy
l Reduces negative effect on environment
l Enhances social responsibility of Huawei and operators

2.45 WRFD-020120 Service Steering in RRC Connection

Setup
Availability
Description
In the RRC connection setup phase, the following functions are implemented according to the causes
for RRC connection setup:
l Inter-frequency or inter-RAT service steering
l Load sharing between the inter-frequency networks under different coverage
In addition, it is taken into account the load level of the access cell or the fixed ratio of redirection in
order to control load sharing in RAN11.0.
Enhancement
None.
Dependency
Benefits
l Implements service steering in the RRC connection setup phase
l Provides inter-frequency or inter-RAT load sharing under different coverage
l Increases the success rate of network access

2.46 WRFD-020123 TCP Accelerator

Availability
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.
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, and local retransmission. In addition, the TPE also adopts the uplink
data buffer sorting technology.
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.
Enhancement
None.

Dependency
None.
Benefits
l Effectively shields the negative effect on the DL TCP data transmission caused by packet loss
and other factors on the radio network side
l Accelerates the slow-start and fast retransmission of the Server during downlink data
transmission
l Greatly reduces the negative effect on the TCP data transmission performance due to the delay
on the wired network side during downlink data transmission
l Adopts the uplink data buffer sorting technology to optimize the uplink TCP data transmission
performance, which greatly improves the PS data transmission performance

2.47 WRFD-020124 Uplink Flow Control of User Plane

Availability
Description
This feature is applicable to R99 service. The Uplink Flow Control of User Plane feature for HSUPA
users is a standard flow control mode defined by the 3GPP protocols and has been implemented.
In uplink single service data transmission, when the NodeB transmits data on the Iub interface,
packet loss may occur due to insufficient processing capability of the buffer or insufficient transport
network capability. In this case, data is repeatedly retransmitted, which causes the decrease of
transmission and service processing efficiency.
Huawei RAN uses the spare field in the Iub FP frame, which enables the RNC to detect the
information about the packet loss in the uplink. When the packet loss threshold is reached, the RNC
decides that this service enters the congestion state in the uplink, and then reduces the uplink data
transmission rate of the UE by sending the TF Restriction message to the UE.
This is a proprietary feature of Huawei.
Enhancement
None.
Dependency
None.
Benefits
This feature prevents the uplink transmission from packet loss for lack of flow control, and increases
the service transmission efficiency.

3 Transmission
3.1 WRFD-050104 Satellite Transmission on Iub Interface

Availability
Description
This function supports satellite transmission on the Iub interface, which is useful to cover remote
districts, such as an island.
When Iub uses satellite transmission, the latency become longer and there should be some adjust for
timer in SAAL/NBAP/ALCAP so as to avoid data or link error due to transmission delay. These
related parameters are configurable to meet satellite transmission requirements.
Enhancement
None
Dependency
None
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.

3.2 WRFD-050105 ATM Switching Based Hub NodeB

Availability
This feature was available from RAN 5.1
Description
The ATM Switching Based Hub NodeB is a feature in ATM transport mode. It is the extension
of the tree topology, as shown in the following figure. The downstream NodeBs connect to
the RNC after the convergence at the hub NodeB. The convergence gain is obtained from this
topology.
NodeB
NodeB
NodeB
NodeB
Hub NodeB RNC
NodeB
NodeB
The hub NodeB topology has two solutions: PVC convergence and AAL2 convergence.
l PVC convergence, RAN5.1 supported
The PVC convergence is shown in the following figure. The PVC convergence uses two
technologies: tree link PVC and group bandwidth management.
PVC convergence is implemented through PVC (or ATM) switching. As shown in the
following figure, the PVC convergence function of the hub NodeB allows the switching
between PVC 1 and PVC a (NodeB 1), PVC 2 and PVC b (NodeB 2), and PVC 3 and PVC c
(NodeB 3).

Physical link
PVC A
PVC Physical link
NodeB 1
PVC B PVC 1
PVC 2
NodeB 2 PVC 3
PVC C
NodeB 3 Hub NodeB
As shown in the following figure, group bandwidth management ensures that the bandwidth
of the downstream NodeBs and the hub NodeB is multiplexed to support the convergence
function. Group bandwidth management is a bandwidth admission function provided by the
RNC.
Group bandwidth management is an improvement on the CAC algorithm. CAC is based on

AAL2 path. Group bandwidth management involves both AAL2 path and bandwidth
management to assure that the summed bandwidth of admitted UEs is lower than the total
bandwidth at physical ports. The summed bandwidth of all AAL2 paths configured for
physical ports can be higher than the total bandwidth of physical ports.
The hub NodeB supports connections to 4-level downstream NodeBs in PVC convergence
mode. The hub NodeB supports up to 16 downstream NodeBs.
Enhancement
None
Dependency
None
Benefits
Reduce costs in transmission lines with the obtained convergence gain.

3.3 WRFD-050106 AAL2 Switching Based Hub NodeB

Availability
AAL2 switching Based Hub NodeB is available from RAN6.0.
Description
The AAL2 switching Based Hub NodeB is a feature in ATM transport mode. It is the
extension of the tree topology. The hub NodeB topology has two solutions: PVC convergence
and AAL2 Convergence.
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 NodeBs (NodeB 1,
NodeB 2, and NodeB 3) is converged and switched on the AAL2 path of the hub NodeB.
Therefore, all the NodeBs share the Iub bandwidth of the AAL2 path.
Physical link
AAL2 Link Physical link
NodeB1
NodeB2
PVC
NodeB3 Hub NodeB
PVC
The hub NodeB supports connections to 4 level downstream NodeBs in AAL2 convergence
mode. The hub NodeB supports up to 16 downstream NodeBs.
Enhancement
None
Dependency
WRFD-050105 ATM Switching Based Hub NodeB
Benefits

3.4 WRFD-050107 IP routing Based Hub Node B

Availability
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 NodeBs connect to the
RNC after the convergence at the hub Node B. The convergence gain is obtained from this
topology.
NodeB
NodeB
NodeB
NodeB
Hub NodeB RNC
NodeB
NodeB
The hub NodeB supports connections to 2 level downstream NodeBs and provides IP routing
for downstream NodeBs. The different IP path convergence at the hub Node B and multiplex
the Iub bandwidth. The hub NodeB supports up to 8 downstream NodeBs.
Enhancement
None
Dependency
WRFD-050402 IP Transmission Introduction on Iub Interface
Only Uni BTS (DBS3900/BTS3900/BTS3900A) can support IP routing Based Hub Node B.
Benefits

3.5 WRFD-050302 Fractional ATM Function on Iub

Interface
Availability
This feature was first available from RAN2.0.
Description
The Fractional ATM mode is an ATM transport mode in the TC sub layer of ATM physical
layer.
In fractional ATM, ATM cells are transmitted by using some of the 32 E1 timeslots. ATM cells
are mapped to some of the E1 timeslots, instead of all of the timeslots. At the peer end, the
ATM cell stream is recovered from these E1 timeslots. The timeslots that are unavailable for
ATM cell transmission can transmit other information.
The E1/T1 boards can be configured for using a fraction of a full E1/T1. For instance, when a
2G system, like GSM, shall share the transport links with the WCDMA system. This feature is
both used for small sites where one 2G BTS and one WCDMA BTS can share one link and
when for example 0.5 links are needed for the WCDMA BTS and there is 0.5 link free
capacity for the 2G BTS. This will in many cases save the cost for installation of one link.
Enhancement
None
Dependency
AEUa and AOUa board in BSC6810 support the feature.
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

3.6 WRFD-050405 Overbooking on ATM Transmission

Availability
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.
The essential to solve this problem is to avoid packet loss on the Iub interface 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.
Buffer Occupancy
TH3
TH2
TH1
Time
From CN
RNL User Plane
① ② ③ ④ ⑤
Iub TNL User Plane
To NodeB

Since this backpressure mechanism works in the 10ms level, generally data loss will not occur
and Iub bandwidth usage efficiency is greatly increased accordingly.
This mechanism requests each NodeB been connected to RNC directly through ATM interface
board. It is not applied for Hub NodeB 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.
Dependency
The backpressure and VP shaping mechanism especially requests ATM interface board
(WOSEc board for BSC6800 & AOUa/UOIa/AEUa boards for BSC6810) be installed in RNC
and the Iub connection to NodeB shall be configured through the optical or electrical port.
Benefits
This feature provides a method for greatly saving OPEX on ATM transmission especially on
Iub interface, and when deploying HSDPA high speed service.

3.7 WRFD-050406 ATM QoS Introduction on Hub NodeB

(Overbooking on Hub NodeB Transmission)
Availability
This feature is available from RAN6.0 in BSC6800.
This feature is introduced from RAN10.0 in BSC6810.
Description
The Iub transmission aggregation is a very important method to save operator’s CAPEX. The
figure below shows an example.
SDH Backhaul
NodeB1 NodeB2 NodeB3

(Hub 1) (Hub 2) (Leaf)
RNC
When the hub NodeB transmission is applied, the RNC can be connected to more NodeBs
with only one physical port. In this case, the RNC may send out data with a high bit rate, and
if all the data is sending to one NodeB, for example, NodeB 3 in upper figure, congestion may
happen at NodeB 2 and data will be lost accordingly. In order to avoid the possible data loss,
Iub Overbooking on Hub NodeB Transmission is introduced in the RNC.
Iub Overbooking on Hub NodeB Transmission feature uses Iub Overbooking CAC (Call
Admission Control) algorithm and VP (virtual Port) shaping mechanism. The Iub
Overbooking CAC algorithm is the same as that in feature WRFD-050405.
In VP shaping mechanism, all PVCs connected to one NodeB are considered as one virtual
port; if one NodeB is a hub NodeB, all PVCs connected to it and PVCs connected to its leaf
NodeBs are considered as one virtual port only.
The VP shaping mechanism is almost the same as backpressure mechanism in feature
WRFD-050405. The difference is that the RNC monitors the buffer occupancy status of each
virtual port but not physical port when the VP shaping is applied.
With the VP shaping mechanism, data loss will not happen and Iub bandwidth can be fully
used.
Enhancement
None
Dependency

WRFD-050405 Overbooking on ATM transmission

Benefits
This feature provides a method for greatly saving OPEX on ATM Hub NodeB transmission,
and when deploying HSDPA service.

3.8 WRFD-050402 IP Transmission Introduction on Iub

Interface
Availability
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 NodeB support IP transmission interface boards. Macro NodeB BTS3812E/A support
3 slots for transmission interface boards in RAN 5.1 and 4 slots for transmission interface
boards in RAN6.0. The Macro NodeB supports the NDTI and NUTI interface board. The
NDTI only supports the ATM. The NUTI can be used for the ATM or IP.
NUTI:
l support 8 ports(E1/T1) per board for IP
l support 2FE ports
Huawei Distributed NodeB DBS3800 supports 8 ports (E1/T1) and 2 FE ports on HBBU. The
E1/T1 can be configured as ATM or IP. The NUTI can also expand the transmission through
daughterboard.
The NUTI and HBBU are constructed by motherboard and daughterboard. Up to RAN6.0,
there are no daughterboard of IP transmission.
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
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.
E1/STM-1 E1/
ADM SDH/PDH ADM STM-1
NodeB
RNC
RNL RNL
UDP/SCTP UDP/SCTP
IP IP
PPP/HDLC PPP/HDLC
PHY PHY PHY PHY
FE L2 Network FE
LAN Switch LAN Switch

NodeB
RNC
RNL RNL
UDP/SCTP UDP/SCTP
IP IP
MAC(L2) MAC(L2) MAC(L2) MAC(L2)
PHY PHY PHY PHY
When Iub IP is introduced, both RNC and NodeB will use new IP interface boards to support
IP transport. The IP board will transfer IP stack to ATM stack so that the RNC and NodeB will
process the data, for core platform in RNC and NodeB is still ATM based. (Shown in below
figure)

AAL2 SSS AR
UDP AAL2 CPS
IP AAL5
cUDP
ATM
PPP MUX
MC/ML PPP
PPP
MAC
HDLC
E1/T1 FE CELL BUS
To NodeB User plane Control
User plane data flow
Besides the transport layer change (e.g. M3UA, SCTP) , the Iub IP brings about some changes
in CAC as well as service differentiation
In CAC, IP PATH is defined as the connection between RNC and a NodeB. Each IP PATH is
configured 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.
As what is done in ATM PVC for service differentiation, the Iub IP adopts the DiffServ for
service differentiation so as to handle the QoS. PHB will firstly be defined according traffic
type, and each PHB has a DSCP (DiffServ Code Point) as well as a priority.
Traffic Type PHB(Per Hop Behavior) PHB DSCP Prior Queue #
Common Channels EF EF B'101110 1
SRB EF
AF4 B'100110 2
CS EF
AF3 B'011110 3
PS Conversational AF4
AF2 B'010010 4
PS Streaming AF3
AF1 B'001010 5
PS Interactive AF1
PS Background BE BE B'000000 6
Dependency
IP head compression is supported by PEUa and POUa board.

Enhancement
In RAN10.0, packet over STM-1/OC-3c is supported in RNC.
In RAN10.0, packet over channelized STM-1/OC-3 is supported in RNC.
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.

3.9 WRFD-050408 Overbooking on IP Transmission

Availability
This feature was available from RAN 6.1.
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 make the Iub overbooking CAC algorithm been disabled.
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.

Buffer Occupancy
TH3
TH2
TH1
Time
From CN
RNL User Plane
① ② ③ ④ ⑤
Iub TNL User Plane
To NodeB
With the backpressure mechanism, data loss will not happen 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.
Dependency
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.
Benefits
This feature can save a great deal of Iub transport resource and reduce the operator's CAPEX
and OPEX on transport and improve the end user’s experience.

3.10 WRFD-050411 Fractional IP Function on Iub Interface

Availability
This feature was available from RAN6.1.
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
Dependency
PEUa and POUa board in BSC6810 support the feature.
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

3.11 WRFD-050403 Hybrid Iub IP Transmission

Availability
Description
The hybrid IP is a kind of innovative transmission solution provided by Huawei adaptive to
requirements of different services in UMTS. That is, transmits real-time service and
non-real-time service on different paths. Two kinds of hybrid transmissions: FE+E1/T1 and
FE+FE are supported.
After HSDPA technology was introduced, with the air capacity increase, Iub transmission
bandwidth demand boomed. 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 service
such as voice and streaming data service will be transported on IP over E1/STM-1, while
non-real-time service such as interactive and background transport on IP over Ethernet. (Show
as below).
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 is failure, all the new coming traffic will be carried over another path.
Enhancement
In RAN10.0, Resiliency Hybrid Iub IP Transmission solution is introduced.
Dependency
Benefits
This feature provides a method for saving OPEX on Iub transmission, especially when
deploying HSDPA/HSUPA high speed service.

3.12 WRFD-050404 ATM/IP Dual Stack NodeB

Availability
Description
This feature benefits to protect operator’s investment and flexible network. For existed ATM
network expansion, operator can overlay IP network in the existed ATM network. The RNC
can support IP NodeB or ATM NodeB, so you can add IP NodeB in the existed ATM network.
Moreover, the NodeB can support ATM and IP dual protocol. You can add an interface card or
modify the configuration to get Iub IP network with existed ATM network, which has no
effect to the existed configuration. For example:
l You can add a NUTI board to support IP transmission in a ATM NodeB which has only
NDTI board;
l You can upgrade NodeB configuration to support IP transmission in a ATM NodeB has
NUTI board;
In RAN10.0, Resiliency solution is introduced. Iub user plane traffic and Iub NBAP signaling
can be carried over ATM network and IP network on backup mode. When one path is failure,
all the new coming traffic will be carried over another path.
Enhancement
In RAN10.0, Resiliency ATM/IP dual stack NodeB Transmission solution is introduced.
Dependency
Benefits

This feature provides smooth upgrading from ATM transmission to IP transmission on Iub
interface. It benefits to protect operator’s investment and make networking flexible.

3.13 WRFD-050409 IP Transmission Introduction on Iu

Interface
Availability
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 (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 IuCS over IP over E1/T1 physical interface (BSC6810 only)
l Support IPV4
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 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
Enhancement

In RAN10.0, packet over STM-1/OC-3c is supported.

In RAN10.0, packet over channelized STM-1/OC-3 is supported.
Dependency
CN should support IP transportation.
Benefits
This feature provides a new Iu transport solution for operator. With IP transmission, transport
cost will decrease greatly compared with ATM transport cost.

3.14 WRFD-050410 IP Transmission Introduction on Iur

Interface
Availability
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 IPV4
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

As what is done in ATM PVC for service differentiation, Iur IP adopts the DiffServ for service
differentiation so as to handling the service QoS. PHB will firstly be defined according traffic
type, and each PHB has a DSCP (DiffServ Code Point) as well as a 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.
Dependency
The neighbouring RNC should also support IP transportation.
Benefits
This feature provides a new Iur transport solution for operator. With IP transmission, transport
cost will decrease greatly compared with ATM transport cost.

3.15 WRFD-050412 UDP MUX for Iu-CS Transmission

Availability
This feature is available from RAN11.0, and it is only applicable to the BSC6810.
Description
After IP transport is introduced to the Iu-CS interface, packets on the user plane are
encapsulated within RTP/UDP/IP. As far as short packets are concerned, the overhead of
header encapsulation reduces transport efficiency.
UDP multiplexing (MUX) adds a shorter UDP MUX sub header than the UDP to a packet and
reduces the proportion of the header, thus improving the transport efficiency of short packets.
Based on the number of packets under multiplexing, the feature improves the transport
efficiency by 30% to 40%.
Enhancement
None.
Dependency
This feature requires the CS CN elements to support UDP MUX. The BSC6810 should be
configured with FG2a or GOUa interface board.
Benefits
This feature improves the utilization of Iu transmission resources, which protects the
investment of the operator and saves the OPEX.

3.16 WRFD-050420 FP MUX for IP Transmission

Availability
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 NodeB must support this feature
simultaneously. FG2a and GOUa of BSC6810, WFIE of BSC6800 and NUTI of Node B
support this feature.
Enhancement
None
Dependency
The FG2a and GOUa support FP MUX for BSC6810.
The WFIE supports FP MUX for BSC6800.
The NUTI supports FP MUX for Node B.
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%.

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

Availability
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 BDF detection is short
(about 100ms), so it could be used for telecom service above IP network.
Currently one hop is supported for BFD.
BFD could be adopted in two scenarios:
1. It could be used for the gateway availability detection when router is adopted;
RNC NodeB/CN/RNC
R1 R3
p1
p2 R2 R4
BFD is activated for p1 and p2 failure detection, when p1 is fault, trigger IP re-route, and
packets are transmitted from p2.
2. It could be used for peer entity availability detection when RNC is directional connected to
peer device (e.g. NodeB, MGW, RNC).
NodeB/CN/RNC
p1
p2

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, only Iu interface supports BFD.
ARP (Address Resolution Protocol) is another method used for failure detection. It could also
be used to detect gateway availability or peer entity availability for the above two scenarios.
When failure is detected, trigger IP re-route to avoid call drop. Because MAC broadcast is
used for ARP, the period for transmission ARP detection packet usually set at second level,
this cause the detection time is larger than BFD, so the failure influence is larger than BFD.
BFD is preferred if both support BDF, ARP is alternative method when no BFD.
Enhancement
None
Dependency
or WRFD-050409 IP Transmission Introduction on Iu Interface
or WRFD-050410 IP Transmission Introduction on Iur Interface
The FG2a and GOUa support BFD/ARP for BSC6810.
The WFIE supports BFD/ARP for BSC6800.
Router or peer entity should support BFD.
Benefits
l With BFD, the RNC could detect the failure of gateway or peer entity very rapidly and
trigger IP re-route, so less packet loss and no 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.

3.18 WRFD-050422 Dynamic Bandwidth Control of Iub IP

Availability
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 is decreased. When the packet loss
rate or jitter decreases, the available bandwidth is increased.
The principle of IP PM is similar to that of ATM OAM PM. One end send FM (Forward
Monitoring) message periodically, the other end echo PM with BR (Backward Reporting)
message as soon as it receives 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
Dependency

The FG2a and GOUa support this feature for BSC6810.

The WFIE supports this feature for BSC6800.
The NUTI supports this feature for Node B.
Benefits
When the packet loss or jitter increase, RNC will reduce the transmitting throughput to
alleviate and eliminate congestion, so less packet loss and jitter, less packet retransmission
rate, and the transport efficiency is enhanced.

3.19 WRFD-050424 Traffic Priority Mapping onto

Transmission Resources
Availability
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 so as to fulfill
differentiated services while guaranteeing the QoS.
TC\ARP Gold Silver Bronze

R99
R99 C
conversational
R99
R99 S1 R99 S2 R99 S3
streaming
TH TH TH
THP TH THP TH THP TH
P P P
Middl P Middl P Middl P
R99 Hig Hig Hig
e Low e Low e Low
interactive h h h
R99 R99 R99 R99 R99 R99 R99 R99 R99
I11 I12 I13 I21 I22 I23 I31 I32 I33
R99
R99 B1 R99 B2 R99 B3
background
HSPA
HS C
conversational
HSPA
HS S1 HS S2 HS S3
streaming
TH TH TH
THP TH THP TH THP TH
P P P
Middl P Middl P Middl P
HSPA Hig Hig Hig
e Low e Low e Low
interactive h h h
HS HS HS HS HS HS HS HS HS
I11 I12 I13 I21 I22 I23 I31 I32 I33

TC\ARP Gold Silver Bronze

HSPA
HS B1 HS B2 HS B3
background
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 datagrams
with different PHB attributes. The practical mapping can be flexibly configured.

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

3.20 WRFD-050425 Ethernet OAM

Availability
This feature is available from RAN11.0, and it is only applicable to the BSC6810.
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 concerns 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. Regarding 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.
Dependency
l WRFD-050402 IP Transmission Introduction on the Iub Interface, or
l WRFD-050409 IP Transmission Introduction on the Iu Interface, or
l WRFD-050410 IP Transmission Introduction on the Iur Interface.
It is only applicable in 3900 series NodeB.
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.

3.21 WRFD-050501 Clock Synchronization on Ethernet in

NodeB
Availability
Description
In ATM networking, the NodeB obtains timing signals from GPS, BITS, TDM, and so on. In
IP networking, however, there may be some troubles. GPS is still available in an all-IP
network but brings inconvenience because the GPS antennas and feeders have to be presented.
Only a few NodeBs can obtain timing signals from BITS, and TDM cannot be used in all-IP
networks. Therefore, the NodeBs need to obtain timing signals from the IP network, which is
called clock synchronization on Ethernet.
The clock servers generate time stamps and send the time stamps to NodeBs, which act as
clock clients in this case. Because there is great delay in packet networks, NodeBs use an
adaptive method to get rid of the delay and restore the timing signals. The time stamps are set
in packets at the UDP layer ,and will be 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 NodeBs.

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 NodeBs.
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 NodeB complies with 3GPP.
Enhancement
RAN11.0 supports IEEE 1588V2.
Dependency
WRFD-050402 IP Transmission Introduction on the Iub Interface
Benefits
Clock over IP is one of the key features provided by the solution of all-IP networking on the
Iub interface. Compared with the GPS clock solution, the clock over IP saves construction
cost of the operator and is easy for management and maintenance.

3.22 WRFD-050502 Synchronous Ethernet

Availability
Description
The synchronous Ethernet technology that adopts Ethernet link code flows to recover clocks
is a physical layer based clock synchronization. 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
Dependency
The synchronous Ethernet technology requires that all the equipments on the clock relay path
must support the synchronous Ethernet.
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.

4 Reliability
4.1 WRFD-040202 RNC Node Redundancy

Availability
This feature is available from RAN11.0 and is only applicable to the BSC6810.
Description
An RNC controls the radio resources of an RNS. If the RNC incurs faults, all the NodeBs
within the RNS cannot access the network and the communication in the entire area covered
by the RNS is disabled.
Aiming to avoid the above-mentioned situations, the RNC node redundancy provides a
backup scheme of network element level. The RNC supports 1+1 backup mode. The
principles of the 1+1 backup mode are as follows:
Two sets of transport links are configured for the NodeB. One set of links are connected to the
master home RNC, and the other to the slave home RNC. (All the data related to NodeBs,
cells, and neighboring cells has backup on both RNCs.) In normal cases, the master home
RNC serves as the CRNC that controls the NodeB. If the master RNC incurs faults, the
NodeB tries to have the slave RNC as its CRNC and resumes work.
The NodeB has two Iub interfaces (two sets of control plane, user plane and maintenance
plane links) and has two RNCs that can serve as the CRNC. Therefore, the cold backup (call
not protected) is implemented and the reliability is improved. The master and slave RNCs
have no active/standby 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 NodeBs controlled by the faulty RNC, so as to prevent the
NodeBs from being out of service and prevent 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.
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.

Optional Feature Description of Huawei UMTS RAN11 - 0

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Optional Feature Description of Huawei UMTS RAN11 - 0

Hochgeladen von

Copyright:

Verfügbare Formate

Optional Feature Description of

Huawei UMTS RAN11.0

HUAWEI TECHNOLOGIES CO., LTD.

Huawei Technologies Co., Ltd.

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

Trademarks and Permissions

Issue 1.2 (2008-09-17) Commercial in Confidence Page 2 of 288

1 RABs and Services ................................................................................................................... 9

1.7.2 WRFD-01061111 HSDPA State Transition .......................................................................................52

Issue 1.2 (2008-09-17) Commercial in Confidence Page 4 of 288

1.30 WRFD-010683 Downlink 64QAM .......................................................................................................103

2 RAN Architecture & Functions .......................................................................................... 148

Issue 1.2 (2008-09-17) Commercial in Confidence Page 5 of 288

2.3 WRFD-010210 Control Channel Parallel Interference Cancellation (CCPIC) ..........................................151

Issue 1.2 (2008-09-17) Commercial in Confidence Page 6 of 288

2.25 WRFD-021200 HCS (Hierarchical Cell Structure) ................................................................................208

3 Transmission ........................................................................................................................ 244

Issue 1.2 (2008-09-17) Commercial in Confidence Page 7 of 288

3.13 WRFD-050409 IP Transmission Introduction on Iu Interface.................................................................268

4 Reliability ............................................................................................................................. 287

Issue 1.2 (2008-09-17) Commercial in Confidence Page 8 of 288

1 RABs and Services

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

Issue 1.2 (2008-09-17) Commercial in Confidence Page 9 of 288

In RAN11.0, Combination of four PS service is supported.

Issue 1.2 (2008-09-17) Commercial in Confidence Page 10 of 288

1.1.1 WRFD-01061501 Combination of Two PS Services

Issue 1.2 (2008-09-17) Commercial in Confidence Page 11 of 288

1.1.2 WRFD-01061502 Combination of One CS Service and Two

Issue 1.2 (2008-09-17) Commercial in Confidence Page 12 of 288

1.1.3 WRFD-01061503 Combination of Three PS Services

Issue 1.2 (2008-09-17) Commercial in Confidence Page 13 of 288

1.1.4 WRFD-01061504 Combination of One CS Service and Three

Issue 1.2 (2008-09-17) Commercial in Confidence Page 14 of 288

1.1.5 WRFD-01061505 Combination of Four PS Services

Issue 1.2 (2008-09-17) Commercial in Confidence Page 15 of 288

1.2 WRFD-010613 AMR-WB (Adaptive Multi Rate Wide

Codec Mode Source Codec BitRate

AMR-WB_12.65 12.65 kbit/s

AMR-WB_8.85 8.85 kbit/s

AMR-WB_6.60 6.60 kbit/s

Issue 1.2 (2008-09-17) Commercial in Confidence Page 16 of 288

1.3 WRFD-010617 VoIP over HSPA

Issue 1.2 (2008-09-17) Commercial in Confidence Page 17 of 288

1.3.1 WRFD-01061701 RAB Mapping

Issue 1.2 (2008-09-17) Commercial in Confidence Page 18 of 288

1.3.2 WRFD-01061703 Optimized Scheduling for VoIP over HSPA

The above packets have different characteristics:

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

Issue 1.2 (2008-09-17) Commercial in Confidence Page 19 of 288

Issue 1.2 (2008-09-17) Commercial in Confidence Page 20 of 288

1.4 WRFD-010618 IMS Signaling over HSPA

Issue 1.2 (2008-09-17) Commercial in Confidence Page 21 of 288

1.5 WRFD-010619 CS Voice over HSPA/HSPA+

Issue 1.2 (2008-09-17) Commercial in Confidence Page 22 of 288

Issue 1.2 (2008-09-17) Commercial in Confidence Page 23 of 288

1.6 WRFD-010610 HSDPA Introduction Package

Issue 1.2 (2008-09-17) Commercial in Confidence Page 24 of 288

HSDPA feature provides a number of methods to increase system throughput. It has to

Issue 1.2 (2008-09-17) Commercial in Confidence Page 25 of 288

1.6.1 WRFD-01061017 QPSK Modulation

Issue 1.2 (2008-09-17) Commercial in Confidence Page 26 of 288

1.6.2 WRFD-01061001 15 Codes per Cell