ran13.0 optional feature description v1.0(20111228)
TRANSCRIPT
RAN13.0 Optional Feature Description(3GPP)
Issue 1.0
Date 2011-12-28
HUAWEI TECHNOLOGIES CO., LTD.
Copyright © Huawei Technologies Co., Ltd. 2010. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without
prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are the property of Huawei Technologies Co., Ltd. All other
trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the commercial contract made
between Huawei and the customer. All or partial products, services and features described in this
document may not be within the purchased scope or the usage scope. Unless otherwise agreed by
the contract, all statements, information, and recommendations in this document are provided “AS
IS” without warranties, guarantees or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in
the preparation of this document to ensure accuracy of the contents, but all statements, information,
and recommendations in this document do not constitute the warranty of any kind, express or
implied.
Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: [email protected]
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 3 of 174
Contents
1 Voice & Service.............................................................................................................................. 7
1.1 VoIP .................................................................................................................................................................. 7
1.1.1 WRFD-010617 VoIP over HSPA/HSPA+ ............................................................................................... 7
1.1.2 WRFD-010618 IMS Signaling over HSPA ............................................................................................. 8
1.1.3 WRFD-011501 PDCP Header Compression (RoHC) ........................................................................... 10
1.1.4 WRFD-010619 CS voice over HSPA/HSPA+ ...................................................................................... 11
1.2 Crystal Voice .................................................................................................................................................. 13
1.2.1 WRFD-010613 AMR-WB (Adaptive Multi Rate Wide Band) ............................................................. 13
1.2.2 WRFD-020701 AMR/WB-AMR Speech Rates Control ....................................................................... 14
1.2.3 WRFD-011600 TFO/TrFO .................................................................................................................... 16
1.3 CBS ................................................................................................................................................................ 17
1.3.1 WRFD-011000 Cell Broadcast Service................................................................................................. 17
1.4 MBMS ............................................................................................................................................................ 18
1.4.1 WRFD-010616 MBMS Introduction Package ...................................................................................... 18
1.4.2 WRFD-01061601 MBMS Broadcast Mode .......................................................................................... 20
1.4.3 WRFD-01061604 MBMS Soft/Selective Combining ........................................................................... 22
1.4.4 WRFD-01061606 Streaming Service on MBMS .................................................................................. 23
1.4.5 WRFD-01061608 16/32/64/128Kbit/s Channel Rate on MBMS.......................................................... 24
1.4.6 WRFD-010660 MBMS Phase 2 ............................................................................................................ 25
1.4.7 WRFD-01066001 MBMS Enhanced Broadcast Mode ......................................................................... 26
1.4.8 WRFD-01066002 MBMS P2P over HSDPA ........................................................................................ 28
1.4.9 WRFD-010626 MBMS FLC(Frequency Layer Convergence)/FLD(Frequency Layer Dispersion) ..... 29
1.4.10 WRFD-010625 256Kbit/s Channel Rate on MBMS ........................................................................... 30
1.4.11 WRFD-010661 MBMS over Iur ......................................................................................................... 31
1.4.12 WRFD-010663 MSCH Scheduling ..................................................................................................... 32
1.5 LCS ................................................................................................................................................................ 34
1.5.1 WRFD-020801 Cell ID + RTT Function Based LCS ........................................................................ 34
1.5.2 WRFD-020802 OTDOA Based LCS .................................................................................................... 36
1.5.3 WRFD-020803 A-GPS Based LCS ....................................................................................................... 37
1.5.4 WRFD-020804 LCS Classified Zones .................................................................................................. 38
1.5.5 WRFD-020805 LCS over Iur ................................................................................................................ 39
1.5.6 WRFD-020807 Iupc Interface for LCS service .................................................................................... 42
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 4 of 174
2 MBB ............................................................................................................................................... 45
2.1 HSUPA Prime Service .................................................................................................................................... 45
2.1.1 WRFD-010612 HSUPA Introduction Package...................................................................................... 45
2.1.2 WRFD-01061201 HSUPA UE Category 1 to 7 .................................................................................... 46
2.1.3 WRFD-01061206 Interactive and Background Traffic Class on HSUPA ............................................. 48
2.1.4 WRFD-01061210 HSUPA 1.44Mbit/s per User.................................................................................... 49
2.1.5 WRFD-010614 HSUPA Phase 2 ........................................................................................................... 50
2.1.6 WRFD-01061403 HSUPA 2ms TTI ...................................................................................................... 51
2.1.7 WRFD-01061405 HSUPA 5.74Mbit/s per User.................................................................................... 53
2.1.8 WRFD-010632 Streaming Traffic Class on HSUPA ............................................................................. 54
2.1.9 WRFD-010635 HSUPA over Iur ........................................................................................................... 55
2.2 HSUPA Performance Improvement................................................................................................................ 57
2.2.1 WRFD-010637 HSUPA Iub Flow Control in Case of Iub Congestion ................................................. 57
2.2.2 WRFD-010636 SRB over HSUPA ........................................................................................................ 58
2.3 HSDPA Prime Service .................................................................................................................................... 59
2.3.1 WRFD-010610 HSDPA Introduction Package...................................................................................... 59
2.3.2 WRFD-01061017 QPSK Modulation ................................................................................................... 61
2.3.3 WRFD-01061001 15 Codes per Cell .................................................................................................... 62
2.3.4 WRFD-01061018 Time and HS-PDSCH Codes Multiplex .................................................................. 63
2.3.5 WRFD-01061008 Interactive and Background Traffic Class on HSDPA ............................................. 64
2.3.6 WRFD-01061002 HSDPA UE Category 1 to 28................................................................................... 65
2.3.7 WRFD-01061015 HSDPA 1.8Mbit/s per User ..................................................................................... 68
2.3.8 WRFD-010620 HSDPA 3.6Mbit/s per User ......................................................................................... 69
2.3.9 WRFD-010629 DL 16QAM Modulation .............................................................................................. 70
2.4 HSDPA Performance Improvement................................................................................................................ 71
2.4.1 WRFD-010621 HSDPA 7.2Mbit/s per User ......................................................................................... 71
2.4.2 WRFD-010611 HSDPA Enhanced Package .......................................................................................... 72
2.4.3 WRFD-01061113 HS-DPCCH Preamble Support ................................................................................ 73
2.4.4 WRFD-010630 Streaming Traffic Class on HSDPA ............................................................................. 75
2.4.5 WRFD-010650 HSDPA 13.976Mbit/s per User.................................................................................... 76
2.4.6 WRFD-010651 HSDPA over Iur ........................................................................................................... 77
2.4.7 WRFD-010652 SRB over HSDPA ........................................................................................................ 78
2.5 HSPA+ Prime Service .................................................................................................................................... 80
2.5.1 WRFD-010680 HSPA+ Downlink 28Mbit/s per User .......................................................................... 80
2.5.2 WRFD-010681 HSPA+ Downlink 21Mbit/s per User .......................................................................... 81
2.5.3 WRFD-010685 Downlink Enhanced L2 ............................................................................................... 82
2.5.4 WRFD-010689 HSPA+ Downlink 42Mbit/s per User .......................................................................... 83
2.5.5 WRFD-010683 Downlink 64QAM ....................................................................................................... 85
2.5.6 WRFD-010684 2×2 MIMO .................................................................................................................. 86
2.5.7 WRFD-010693 DL 64QAM+MIMO .................................................................................................... 88
2.5.8 WRFD-010698 HSPA+ Uplink 11.5 Mbit/s per User ........................................................................... 89
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 5 of 174
2.5.9 WRFD-010703 HSPA+ Downlink 84 Mbit/s per User (Trial) .............................................................. 90
2.5.10 WRFD-010699 DC-HSDPA+MIMO (Trial) ....................................................................................... 91
2.5.11 WRFD-010694 UL 16QAM ................................................................................................................ 93
2.5.12 WRFD-010695 UL Layer 2 Improvement .......................................................................................... 94
2.5.13 WRFD-010696 DC-HSDPA ............................................................................................................... 96
2.6 HSPA+ Performance Improvement ................................................................................................................ 98
2.6.1 WRFD-010688 Downlink Enhanced CELL-FACH .............................................................................. 98
2.6.2 WRFD-010686 CPC - DTX / DRX ...................................................................................................... 99
2.6.3 WRFD-010687 CPC - HS-SCCH less operation ................................................................................ 101
2.6.4 WRFD-010697 E-DPCCH Boosting .................................................................................................. 102
2.6.5 WRFD-010701 Uplink Enhanced CELL_FACH ................................................................................ 104
2.6.6 WRFD-010702 Enhanced DRX .......................................................................................................... 105
3 Topology & Transmission ....................................................................................................... 107
3.1 RAN Sharing ................................................................................................................................................ 107
3.1.1 WRFD-021311 MOCN Introduction Package .................................................................................... 107
3.1.2 WRFD-02131101 Carrier Sharing by Operators ................................................................................. 109
3.2 Topology Enhancement ................................................................................................................................ 111
3.2.1 WRFD-021200 HCS (Hierarchical Cell Structure) ............................................................................. 111
3.2.2 WRFD-020111 One Tunnel ................................................................................................................ 113
3.3 ATM Transimission ...................................................................................................................................... 114
3.3.1 WRFD-050302 Fractional ATM Function on Iub Interface ................................................................ 114
3.4 IP Transmission ............................................................................................................................................ 116
3.4.1 WRFD-050402 IP Transmission Introduction on Iub Interface .......................................................... 116
3.4.2 WRFD-050411 Fractional IP Function on Iub Interface ..................................................................... 119
3.4.3 WRFD-050409 IP Transmission Introduction on Iu Interface ............................................................ 121
3.4.4 WRFD-050410 IP Transmission Introduction on Iur Interface ........................................................... 123
3.4.5 WRFD-011500 PDCP Header Compression (RFC2507) .................................................................... 125
3.5 Satellite Transmission .................................................................................................................................. 127
3.5.1 WRFD-050104 Satellite Transmission on Iub Interface ..................................................................... 127
3.5.2 WRFD-050108 Satellite Transmission on Iu Interface ....................................................................... 128
3.6 Clock ............................................................................................................................................................ 129
3.6.1 WRFD-050502 Synchronous Ethernet ................................................................................................ 129
3.6.2 WRFD-050425 Ethernet OAM ........................................................................................................... 130
4 Network Security ...................................................................................................................... 133
4.1 Reliability ..................................................................................................................................................... 133
4.1.1 WRFD-021302 Iu Flex ....................................................................................................................... 133
5 Network Performance .............................................................................................................. 137
5.1 Coverage Enhancement ................................................................................................................................ 137
5.1.1 WRFD-010203 Transmit Diversity ..................................................................................................... 137
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 6 of 174
5.1.2 WRFD-021309 Improved Downlink Coverage .................................................................................. 139
5.1.3 WRFD-020138 HSUPA Coverage Enhancement at UE Power Limitation......................................... 140
5.2 Intra-system Mobility Management ............................................................................................................. 141
5.2.1 WRFD-020605 SRNS Relocation Introduction Package .................................................................... 141
5.2.2 WRFD-02060501 SRNS Relocation (UE Not Involved) .................................................................... 142
5.2.3 WRFD-02060502 SRNS Relocation with Hard Handover ................................................................. 144
5.2.4 WRFD-02060503 SRNS Relocation with Cell/URA Update ............................................................. 145
5.2.5 WRFD-02060504 Lossless SRNS Relocation .................................................................................... 146
5.3 Intra-system Radio Resource Management .................................................................................................. 147
5.3.1 WRFD-010615 Multiple RAB Package (PS RAB ≥2) ..................................................................... 147
5.3.2 WRFD-020114 Domain Specific Access Control (DSAC) ................................................................. 148
5.3.3 WRFD-020400 DRD Introduction Package........................................................................................ 150
5.3.4 WRFD-021102 Cell Barring ............................................................................................................... 151
5.4 GSM and UMTS Radio Resource Management .......................................................................................... 152
5.4.1 WRFD-020307 Video Telephony Fallback to Speech (AMR) for Inter-RAT HO .............................. 152
5.4.2 WRFD-020308 Inter-RAT Handover Phase 2 ..................................................................................... 154
5.4.3 WRFD-02030801 NACC(Network Assisted Cell Change) ................................................................ 155
5.4.4 WRFD-02030802 PS Handover Between UMTS and GPRS ............................................................. 157
5.4.5 WRFD-020305 Inter-RAT Handover Based on Service ..................................................................... 158
5.4.6 WRFD-020310 3G/2G Common Load Management ......................................................................... 159
5.5 UMTS and LTE Radio Resource Management ............................................................................................ 160
5.5.1 WRFD-020126 Mobility Between UMTS and LTE Phase1 ............................................................... 160
5.6 QoS............................................................................................................................................................... 162
5.6.1 WRFD-021103 Access Class Restriction ............................................................................................ 162
5.6.2 WRFD-050424 Traffic Priority Mapping onto Transmission Resources ............................................ 164
5.6.3 WRFD-010506 RAB Quality of Service Renegotiation over Iu Interface .......................................... 167
5.6.4 WRFD-010507 Rate Negotiation at Admission Control ..................................................................... 169
5.6.5 WRFD-020130 Videophone Service Restriction ................................................................................ 171
6 Acronyms and Abbreviations ................................................................................................. 173
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 7 of 174
1 Voice & Service
1.1 VoIP
1.1.1 WRFD-010617 VoIP over HSPA/HSPA+
Availability
VoIP over HSPA is available from RAN10.0.
VoIP over HSPA+ is available from RAN11.0.
Summary
VoIP over HSPA meets the requirements of growing VoIP users. Compared with CS voice
over DCH, VoIP over HSPA or HSPA+ provides larger capacity through high spectral
efficiency and capacity enhancement of HSPA or HSPA+. This feature is a trial feature in
RAN10.0.
Benefits
VoIP over HSPA/HSPA+ has the following advantages:
Support evolution to all-IP network and decrease in the investment and maintenance cost
Large voice capacity
Description
In the fixed network, VoIP has turned out to be an attractive and cost-effective solution to
support PS conversational services. The rapid growth of VoIP users prompts cellular operators
to use this feature for enhanced revenue generation. Moreover, from the viewpoint of
evolution, VoIP helps operators converge their networks into an all-IP network and decrease
the total OPEX accordingly.
VoIP services can be carried over DCH or HSPA. When it is set up on the DCH, the capacity
is not competitive because RTP/UDP/IP protocol head will consume more resource than CS
voice service. But HSPA has higher resource efficiency than DCH. Therefore, VoIP over
HSPA is a better choice. Moreover, Robust Header Compression (RoHC) is also introduced to
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 8 of 174
improve the overhead efficiency. In addition, the Continuous Packet Connectivity (CPC)
technology in the HSPA+ helps expand the VoIP capacity.
Compared with traditional CS voice over DCH, the capacity gain of VoIP over HSPA (HSUPA
with 2ms TTI) is expected to reach 20%. With CPC, the capacity gain of VoIP over HSPA
(HSUPA with 2ms TTI) is expected to reach 45%.
Enhancement
In RAN12.0, coverage-based TTI dynamic switching of VoIP over HSUPA is introduced. The
coverage performance of the HSUPA 10 ms TTI is better than that in R99, whereas the
coverage performance of the HSUPA 2 ms TTI is worse than that in R99. The 2 ms TTI,
however, has a greater gain in capacity. Therefore, for VoIP users, smooth switching from the
2 ms TTI to the 10 ms TTI must be implemented according to the limitation on the uplink
transmit power of the UE. This ensures seamless coverage and maximizes cell capacity.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should support VoIP.
Dependency on Other Network Units
NA
Dependency on CN
CN should support IP multimedia subsystem (IMS).
Dependency on Other Features
When VoIP is over HSPA, the following features are required:
WRFD-010610 HSDPA Introduction Package
WRFD-010612 HSUPA Introduction Package
WRFD-010636 SRB over HSUPA
WRFD-010652 SRB over HSDPA
When VoIP is over HSPA+, the following feature is required:
WRFD-010686 CPC-DTX/DRX
1.1.2 WRFD-010618 IMS Signaling over HSPA
Availability
This feature is available from RAN10.0.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 9 of 174
This feature is introduced in 3GPP R5.
Summary
IMS signaling over HSPA can shorten the setup delay of IMS services like VoIP to save
network resources for the operator.
Benefits Since IMS signaling is carried on HSPA, the utilization of code resource and
transmission resource can be improved, compared with those carried on the DCH.
Better performance (short time delay) and capacity of IMS services.
Description
The IP Multimedia Subsystem (IMS) is an open and standardized architectural framework for
delivering Internet Protocol (IP) multimedia to mobile users. With this feature, operators
provide network-controlled multimedia services by combining voice and data in a single
packet switched network.
IMS uses Session Initiation Protocol (SIP) as the key control protocol, and implements
service management in the UTRAN. Such SIP signaling will be indicated by the CN in the
RAB Assignment Request message. The RAB should be an interactive QoS class service.
Before RAN10.0, such IMS signaling service can only be carried on the DCH. With F-DPCH
supported in RAN10.0, the service can be carried on HSPA, which brings better performance
for IMS service.
The type of channels carrying IMS signaling is configurable separately on the downlink and
uplink at cell level. That is, when HSPA is chosen as the bearer with high priority, IMS
signaling will be set up on it as much as possible. If the setup is not successful, for example,
due to admission control, a periodical timer will be started to trigger the reconfiguration of the
HSPA procedure.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 10 of 174
CN should support the signaling indication at Iu interface.
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
WRFD-010612 HSUPA Introduction Package
1.1.3 WRFD-011501 PDCP Header Compression (RoHC)
Availability
This feature is available from RAN10.0.
This feature is introduced in 3GPP R4.
Summary
PDCP header compression (RoHC) mainly applies to VoIP services and it can decrease the
overhead of IP data.
Benefits Decrease the IP data overhead greatly from more than 60% to 10%.
Saving air interface and backhaul bandwidth occupancy, saving CAPEX & OPEX
Description
Robust Header Compression (RoHC) is defined in RFC3095 (July, 2001). Such feature
provides the IP data header compression mechanism which aims to save the bandwidth of air
interface, which utilize less radio resources.
The motivation for IP header compression is based on the following facts:
The multimedia payload is typically compressed at the application layer.
The headers occupy a large portion of the packet for some services.
The headers have significant redundancy.
The RoHC is implemented at the PDCP protocol layer between the RNC and UE; therefore,
the Iub bandwidth can be saved.
In RAN10.0, the following compress/uncompress profiles are supported:
RoHC Uncompressed
RoHC RTP: RTP/UDP/IP header
RoHC UDP: UDP/IP header
RoHC ESP: ESP/IP header
Generally, RTP/UDP/IP header is used in packet of VoIP, so RoHC Uncompressed or RoHC
RTP is used for VoIP. RoHC UDP and RoHC ESP are used in other scenarios when the hander
of packet is UDP/IP or ESP/IP.
Both IPV4 and IPV6 header compressions are supported.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 11 of 174
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should support ROHC compression function.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010619 CS Voice over HSPA/HSPA+
1.1.4 WRFD-010619 CS voice over HSPA/HSPA+
Availability
This feature is available from RAN11.0. It is introduced in 3GPP R8.
Summary
Compared with CS voice over DCH, CS voice over HSPA/HSPA+ provides a larger voice
capacity through high spectral efficiency and capacity enhancement of HSPA or HSPA+.
Benefits
The use of the high spectral efficiency and capacity enhancement features of HSPA or HSPA+
increases the capacity of CS voice services. Compared with VoIP over HSPA or HSPA+, CS
voice over HSPA/HSPA+ does not require the support of the IMS and its implementation is
easier.
Description
Generally, CS voice services are carried over DCH. CS voice over HSPA is introduced in
3GPP Release 8 specifications. That is, UL CS voice packets are carried over E-DCH, and DL
CS voice packets are carried over HS-DSCH.
CS voice over HSPA refers to the Circuit Switched voice service based on legacy CS domain
Core Network. Therefore, operators do not need to deploy the IMS for VoIP services. The
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 12 of 174
following figure shows the difference in call routing between CS voice over HSPA and VoIP
over HSPA/HSPA+.
To deploy CS voice over HSPA, the only needed update is the way of mapping for this service
on the RNC. No additional modification is needed on the MSC or Node B.
CS voice over HSPA improves the spectral efficiency and cell capacity. Moreover, the CPC
feature introduced in RAN11.0 HSPA+ package helps to extend the battery life of UEs
through UL DTX and DL DRX functions.
Compared with traditional CS over DCH, the capacity gain of CS over HSPA (HSUPA with
2ms TTI) is expected to reach 23%. With CPC, the capacity gain of VoIP over HSPA (HSUPA
with 2ms TTI) is expected to reach 48%.
Enhancement
In RAN12.0, coverage-based TTI dynamic switching of CS over HSUPA is introduced. The
coverage performance of the HSUPA 10 ms TTI is better than that in DCH, whereas the
coverage performance of the HSUPA 2 ms TTI is worse than that in DCH. The 2 ms TTI,
however, has greater gain in capacity. Therefore, for voice call over HSPA users, 2 ms TTI is
always configured to obtain high system capacity and smooth switching from the 2 ms TTI to
the 10 ms TTI must be implemented according to the limitation on the uplink transmit power
of the UE and the high BLER. This ensures seamless coverage and maximizes cell capacity.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
The UE must be Release-8 (or later) and support CS voice over HSPA/HSPA+
Dependency on Other Network Units
NA
Dependency on CN
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 13 of 174
NA
Dependency on Other Features
When CS voice is over HSPA
WRFD-010610 HSDPA Introduction Package
RFD-010612 HSUPA Introduction Package
WRFD-010636 SRB over HSUPA
WRFD-010652 SRB over HSDPA
When CS voice is over HSPA+
WRFD-010686 CPC DTX/DRX
1.2 Crystal Voice
1.2.1 WRFD-010613 AMR-WB (Adaptive Multi Rate Wide Band)
Availability
This feature is available from RAN6.0.
This feature is introduced in 3GPP R5.
Summary
This feature enables the operator to improve the quality of speech services if resources are
allowed.
Benefits
The AMR-WB provides improved voice quality especially in terms of increased voice
naturalness.
Description
AMR-WB (Wide Band) is a new feature in 3GPP_REL 5 for the purpose to provide improved
voice quality especially in terms of increased voice naturalness.
This feature provides the AMR-WB service with the bit rate defined as follows:
Codec Mode Source Codec BitRate
AMR-WB_23.85 23.85 kbit/s
AMR-WB_15.85 15.85 kbit/s
AMR-WB_12.65 12.65 kbit/s
AMR-WB_8.85 8.85 kbit/s
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 14 of 174
Codec Mode Source Codec BitRate
AMR-WB_6.60 6.60 kbit/s
The system will set up the AMR service according to the service request from the core
network. The algorithm for AMR-WB is the same as that for the AMR service with narrow
band.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
The UE must have the corresponding support capability.
Dependency on Other Network Units
NA
Dependency on CN
The CN must have the corresponding support capability.
Dependency on Other Features
NA
1.2.2 WRFD-020701 AMR/WB-AMR Speech Rates Control
Availability
This feature is available from RAN2.0.
This feature is introduced in 3GPP R99.
Summary
This feature enables the adjustment of AMR/AMR-WB speech rates triggered by multiple
factors. This feature can ensure a continuous service, expand the service coverage, and reduce
the cell load.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 15 of 174
Benefits
For the same transmit power, a lower-rate AMR codec can provide wider uplink coverage.
When the radio environment is good, a high-rate codec can provide better speech quality than
a low-rate codec. When the radio environment is poor, a low-rate codec can provide better
speech quality than a high-rate codec. Thus, the rate of the AMR codec should be adjusted in
real time to ensure high-quality speech services.
Description
The AMR Mode Control (AMRC) is a feature that enables the RNC to control 8 types of
speech rates, namely 12.2 kbit/s, 10.2 kbit/s, 7.95 kbit/s, 7.4 kbit/s, 6.7 kbit/s, 5.9 kbit/s, 5.15
kbit/s, 4.75 kbit/s, and wide band AMR 6.60 kbit/s, 8.85 kbit/s, 12.65 kbit/s, 15.85 kbit/s, and
23.85 kbit/s. This improves speech quality and enlarges uplink coverage and reduces system
load level.
Before RAN5.0, the decision of adjusting the AMR rate considers the downlink transmitted
power for DL and UE transmitted power for UL. If the transmit power exceeds the
pre-defined threshold, it indicates that the link quality is poor.
In RAN5.1, cell load is used for AMRC trigger, where RNC will monitor the cell loading
continuously and dynamically to adjust the user‟s speech code rate according to the change of
the cell loading. When the loading is heavy, low bit rate of AMR speech CODEC is used to
decrease the cell loading and when the cell loading is light, high bit rates of AMR speech
CODEC is used to provide higher voice quality for users.
The AMRC is one action to be done during the load reshuffling (LDR) procedure. The LDR is
one of the congestion control mechanisms triggered when Node B Common Measurement
(TCP, Transmitted Carrier Power) for DL, and Node B Common Measurement (RTWP) for
UL, exceed the LDR threshold. The system will enter „basic congestion‟ status. After the LDR
is triggered, the AMRC serves as a method to decease the system load. The RNC will select
the candidate AMR user according to the ARP and current user rate. Low ARP user will be
selected first to adjust the rate and if ARP is the same, the user with high voice rate will be
firstly selected to adjust the rate.
After the user voice rate is degraded, it depends on the downlink transmitted power for DL
and UE transmitted power for UL for rate increase, as the mechanism used for RAN5.0.
Enhancement
In RAN5.1, the AMRC is added as an action in basic feature WRFD-020106 Load
Reshuffling.
In RAN6.0, this feature can also be used to AMR-WB service which requires the optional
feature WRFD-010603 AMR-WB (Adaptive Multi Rate Wide Band).
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 16 of 174
Dependency on UE
UE should support the processing of TFC control procedure.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
If this feature is to be applied to the AMR-WB, then the Dependency is:
WRFD-010613 AMR-WB (Adaptive Multi Rate Wide Band)
Overbooking on ATM Transmission
1.2.3 WRFD-011600 TFO/TrFO
Availability
This feature is available from RAN3.0
This feature is introduced in 3GPP R4.
Summary
This feature enables the identification and processing of the IUUP V2 CN to support the
TFO/TrFO service.
Benefits
This feature can prevent degradation of the speech quality introduced by the interpretation
between different codecs. The TrFO can also save the transmission resources.
Description
TFO/TrFO features are introduced in Release 4 and used to prevent degradation of the speech
quality. This degradation is produced by the interpretation between the different codecs and is
usually more noticeable when the speech CODECs are operating at low rates and in noisy
conditions.
Tandem Free Operation (TFO) removes the double speech encoding/decoding done in the
TRAUs in MS-to-MS calls by “tunneling” the “compressed” speech through the 64 kbit/s
PCM (Pulse Code Modulation) links of the core network. NO transmission resource will be
saved.
For Transcoder Free Operation (TrFO), there is no constraint to use PCM link on the Nb
interface; therefore, in addition of the advantages proposed by TFO, it can also save the
transmission resources. TrFO can also be used in mobile-to-fix calls.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 17 of 174
On the access network side, the RNC cannot really identify the TFO/TrFO service. The RNC
can, however, identify the CN IUUP version and perform related processing of the IUUP V2
to support the TFO/TrFO service.
Enhancement
In RAN5.0, AMRC under TFO/TrFO is supported.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
The UE must have the corresponding support capability.
Dependency on Other Network Units
NA
Dependency on CN
The CN node needs to support the feature at the same time.
Dependency on Other Features
NA
1.3 CBS
1.3.1 WRFD-011000 Cell Broadcast Service
Availability
This feature is available from RAN3.0
This feature is introduced in 3GPP R99.
Summary
This feature supports the standard cell broadcast procedure as stipulated in protocols to assist
the CBC for the cell broadcast service.
Benefits
The users can use the new services based on the CBS.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 18 of 174
Description
The CBS service is analogous to the Teletex service offered on television, in that like Teletex,
it permits a number of unacknowledged general CBS messages to be broadcast to all receivers
within a particular region. CBS messages are broadcast to defined geographical areas known
as cell broadcast areas. These areas may comprise of one or more cells, or may comprise the
entire PLMN.
The Iu BC interface connects the RNC in UTRAN with the broadcast domain of the Core
Network, namely with the Cell Broadcast Centre. It is used to define the Cell Broadcast
information that is transmitted to the mobile user via the Cell Broadcast Service. The cell
broadcast center (CBC) is part of core network in UMTS and up to 4 CBCs can connect to
RNC via a routing node like WCDMA SGSN.
Enhancement
RAN6.0 supports four CBCs instead of one CBC of the previous versions.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should have the capability to receive cell broadcast messages.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
1.4 MBMS
1.4.1 WRFD-010616 MBMS Introduction Package
Availability
This feature is available from RAN6.0.
This feature is introduced in 3GPP R6.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 19 of 174
Summary
This feature provides basic MBMS functions to meet the requirements of the operator for
MBMS applications.
Benefits
This feature improves the network resource utilization, especially the utilization of resources
on the Uu interface. It is an efficient way for the operators to deploy the point-to-multipoint
services, such mobile TV.
Description
The multimedia broadcast and multicast service (MBMS) is a new important feature for the
3GPP Release 6 specifications. It is a point-to-multipoint service in which the data is
transmitted from a single source entity to multiple recipients. Transmitting the same data to
multiple recipients allows the network resources to be shared.
The MBMS bearer service offers two modes:
Broadcast mode;
Multicast mode.( Not supported by Huawei RNC)
The MBMS architecture enables the efficient use of the radio network and core network
resources, with an emphasis on the radio interface efficiency. For one MBMS service, there is
only one copy of data on the Iu interface, and the RNS distributes the data to all associated
UEs.
The MBMS is realized by a number of additional new capabilities in the existing functional
entities and additional new functional entities. The whole MBMS architecture is as follows:
UE SGSN
UE GERAN
UTRAN
HLR
GGSN
TPFBM - SC
ContentProvider /MulticastBroadcastSource
Uu Iu
Iu /Gb
Um
Gr
Gn /Gp
Gi
PDN
(e .g . Internet )
Gmb
ContentProvider /MulticastBroadcastSource
The introduction of the MBMS has the following impacts on the RAN:
Some new signaling procedures are added on the Iub/Uu/Iur/Iu interface.
New physical channels (MICH) are added.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 20 of 174
New logical channels (MCCH/MTCH/MSCH) are added.
MAC-c/sh is changed to MAC-c/sh/m in order to add the MAC-m to the MBMS.
Soft/selective combination function of the common channels is introduced.
The common channels may be used over the air interface, and the UE may receive the service
in idle mode. So the number of UEs is not limited in a cell and a group.
The UE may receive the same MBMS service in the common channels from different cells.
And by soft/selective combination, less power is needed for the common channels.
The BSC6800 supports the MBMS services with the total traffic of up to 4096 kbit/s on the Iu
interface and 64 sessions can be supported simultaneously.
The BSC6900 supports the MBMS services with the total traffic of up to 8192 kbit/s on the Iu
interface and 256 sessions can be supported simultaneously.
Enhancement
In the RAN10.0, the MBMS introduction package is enhanced. For details, please refer to the
enhancements of the features in the package.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
Dependency on Other Network Units
NA
Dependency on CN
The existing PS Domain functional entities (GGSN, SGSN, UTRAN, GERAN and UE)
need to be enhanced to provide the MBMS bearer service.
A new functional entity, the broadcast multicast service centre (BM-SC) is added to
provide a set of functions for the MBMS users Services.
Dependency on Other Features
NA
1.4.2 WRFD-01061601 MBMS Broadcast Mode
Availability
This feature is available from RAN6.0.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 21 of 174
Summary
In MBMS broadcast mode, MBMS information is transmitted through common channels of a
cell.
Benefits
With this feature, the operators can deploy rich multimedia services, such as mobile TV.
Description
The MBMS bearer service offers two modes:
Broadcast mode
Multicast mode
The broadcast mode is the unidirectional point-to-multipoint transmission of multimedia data
(such as text, audio, picture, video) from a single source entity to all users in the broadcast
service area. It is expected that charging data for the end user will not be generated for this
mode at the MBMS transport service layer. Charging data related to security procedures for
the end user at the MBMS user service layer may be generated.
The multicast mode allows the unidirectional point-to-multipoint transmission of multimedia
data (such as text, audio, picture, video) from a single source entity to a multicast group in the
multicast service area. Unlike the broadcast mode, the multicast mode generally requires a
subscription to the multicast subscription group and the users joining in the corresponding
multicast group. It is expected that charging data for the end user will be generated for this
mode at the MBMS transport service layer.
When receiving the MBMS services in the broadcast mode, the UE may stay in the
URA_PCH/CELL_PCH/CELL_FACH and idle mode. If the capability allowed, the UE can
receive the MBMS service even on the CELL_DCH.
Huawei UMTS RAN6.0 only supports the broadcast mode.
Enhancement
In RAN10.0, the UE in URA_PCH, CELL_PCH, FACH, or idle mode supports the MBMS
service.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 22 of 174
Dependency on CN
NA
Dependency on Other Features
WRFD-010616 MBMS Introduction Package
1.4.3 WRFD-01061604 MBMS Soft/Selective Combining
Availability
This feature is available from RAN6.0.
Summary
This feature is related to soft combination and selective combination for the PTM MBMS
service.
Benefits
With this feature, the power of the S-CCPCH that bears the MBMS services can be saved.
Description
The common channel soft combination is a function introduced for the MBMS. It means that
the UE receiver combines the signal from the multiple cells either in the RAKE receiver or
after the RAKE receiver in the receiver chain prior to the decoding of the soft combination
transport channel. The maximum time difference between the S-CCPCHs carrying the same
service in different cells should be less than 1TTI+1slot.
The soft combination normally improves the UE reception gain by 5 - 7 dB.
The selective combination (SC) is an enhancement for the Release 6 PtM MBMS. The
network is to simulcast the PtM MBMS contents on the S-CCPCH, and the UE receives and
decodes the MBMS data from multiple radio links simultaneously. The selection of the radio
link is to be performed on a transport block basis at the RLC, based on the CRC results and
sequence numbers.
The selective combination normally improves the UE reception gain by 3 - 5 dB.
The RNC should ensure that the services data sent to the UE from different cells are
synchronized.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 23 of 174
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010616 MBMS Introduction Package
1.4.4 WRFD-01061606 Streaming Service on MBMS
Availability
This feature is available from RAN6.0.
Summary
This feature enables the MBMS service to be carried on the PS streaming class, thus ensuring
QoS.
Benefits
The feature can meet the QoS requirements of the service applications borne by the streaming
class.
Description
Compared with the point-to-point bearer services, the following limitations for the MBMS
services exist:
For the traffic class, only the background and streaming classes can be supported;
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
);
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.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 24 of 174
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
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010616 MBMS Introduction Package
1.4.5 WRFD-01061608 16/32/64/128Kbit/s Channel Rate on MBMS
Availability
This feature is available from RAN6.0.
Summary
This feature is related to four MBMS channel rates: 16kbit/s, 32kbit/s, 64kbit/s, and 128kbit/s.
Benefits
The feature enables different channel rates and thus provides operators with more flexibility
to deploy the MBMS services.
Description
The MBMS broadcast mode service bit rate can be 64kbit/s or 128kbit/s. The TTI for 64kbit/s
is 80 ms and the TTI for 128kbit/s can be 40 ms or 80 ms.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 25 of 174
Enhancement
In the RAN10.0, 16 kbit/s or 32kbit/s can also be supported for which only 80 ms is used by
the TTI.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010616 MBMS Introduction Package
1.4.6 WRFD-010660 MBMS Phase 2
Availability
This feature is available from RAN 10.0.
This feature is introduced in 3GPP R6.
Summary
This feature supports the enhanced MBMS (PTP/PTM) to save cell resources.
Benefits
Compared with the broadcast mode, MBMS Phase 2 can effectively implement PTM services,
for example, mobile TV. In PTP/PTM mode, cell resources can be saved.
Description
MBMS Phase 2 refers to enhanced broadcast mode introduced in 2006/09 3GPP
specifications. Compared with broadcast mode, the main differences include:
The “Counting/re-counting” function used for multicast mode is introduced for enhanced
broadcast. During the counting/re-counting procedure, the UE reports its selected
services to the RNC directly over the Uu interface.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 26 of 174
Based on “Counting/re-counting” result, RNC can select optimum transfer mode: PTM
(Point To Multipoint) or PTP (Point To Point). In PTM mode, FACH/SCCPCH is used to
bear the MBMS services; in PTP mode, DCH or HSDPA is used to bear the MBMS
services. If in a cell there is no user interested in one specific MBMS service, RAN can
decide to cancel it.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should support the corresponding enhanced MBMS functions.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010616 MBMS Introduction Package
1.4.7 WRFD-01066001 MBMS Enhanced Broadcast Mode
Availability
This feature is available from RAN 10.0.
Summary
This feature is related to the enhanced broadcast mode for the MBMS service.
Benefits
Compared to broadcast mode, it is a more efficient way to deploy the point-to-multipoint
services, such mobile TV.
Description
MBMS enhanced broadcast mode is very similar to multicast mode on RAN side, but much
modification on CN side and NAS procedures are avoided by introducing
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 27 of 174
“counting/re-counting” function. To support it, the following functions on enhanced broadcast
mode are introduced:
Counting/Re-counting. In “MBMS Modified Services Information” message RNC
indicates UE to initiate counting/re-counting response and in “MBMS Access
Information” message RNC gives the “Access probability factor” to UEs in Idle mode.
For UEs in connected mode, it will report to RNC its selected services by “MBMS
Modification Request” message. So RNC will get the number of UEs which are
interested in one specific MBMS service.
In addition, in order to simplify the counting/re-counting procedure, RNC keeps X UEs
in the connected mode.
The dynamic switch between PTP and PTM transfer mode for one MBMS service. When
deciding the optimum transfer mode for one service in a cell, some factors are taken into
account: the load of cell, the number of UE, and the status of the MBMS neighboring
cells.
The mobility management for UE.
− From a PTM cell to another PTM cell. In this scenario, UE will select to receive the
MBMS services in the new cell.
− From a PTM cell to a PTP cell. In this scenario, PTP RB will be established for UE.
− From a PTP cell to a PTM cell. In this scenario, if PTM mode is used in the UEs‟ best
cell, PTP RB will be released.
− From a PTP cell to another PTP cell. Handover will be supported.
The combination of MBMS service and non-MBMS services for UE.
− When the MBMS service is in PTM mode, UE can decide whether to receive this
service according to its capability;
− When MBMS service is in PTP mode, RNC will establish the separate PTP RB for
every UE and treat it as an ordinary PS RB. And multiple RAB will be supported.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 28 of 174
Dependency on Other Features
WRFD-010616 MBMS Introduction Package
1.4.8 WRFD-01066002 MBMS P2P over HSDPA
Availability
This feature is available from RAN 10.0.
Summary
This feature enables MBMS P2P services to be carried on the HS-DSCH, thus saving cell
resources.
Benefits
By HSDPA, the cell capacity will be improved.
Description
In enhanced broadcast mode, PTP and PTM mode can be selected to transport MBMS
services. If PTP mode is adopted, RNC will establish the separate PTP RB for every UE. Like
the non-MBMS service, HSDPA can be used to bear PTP MBMS RB and multiple RAB such
as combination of P2P MBMS streaming and I/B PS over HSDPA.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010616 MBMS Introduction Package
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 29 of 174
1.4.9 WRFD-010626 MBMS FLC(Frequency Layer Convergence)/FLD(Frequency Layer Dispersion)
Availability
This feature is available from RAN6.0.
This feature is introduced in 3GPP R6.
Summary
This feature supports the reselection procedure of the MBMS frequency layer initiated by the
UE.
Benefits
With FLC, the user can acquire the information about MBMS services in time.
With FLD, the cell load can be reduced when the MBMS session is stopped.
Description
Frequency Layer Convergence denotes the process where the UTRAN requests UEs to
preferentially re-select to the frequency layer on which the MBMS service is intended to be
transmitted. This layer preference could be done by an additional MBMS session related
Layer Convergence Information (LCI) such as offset and target frequency. The FLC is
supported by specifications for both networks utilizing HCS and for networks not utilizing
HCS.
Frequency Layer Dispersion (FLD) denotes the process where the UTRAN redistributes UEs
across the frequencies. UTRAN can use FLD per MBMS session.
When FLD is applied, the UE stores the frequency where it was camped previously. Upon
session stop, the UE attempts to return to that frequency.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should support this function.
Dependency on Other Network Units
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 30 of 174
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010616 MBMS Introduction Package
1.4.10 WRFD-010625 256Kbit/s Channel Rate on MBMS
Availability
This feature is available from RAN6.0.
Summary
With this feature, Huawei RAN can support an MBMS channel rate of 256kbit/s.
Benefits
The operator can deploy high bit-rate services to provide better user experience.
Description
In RAN6.0, 256kbit/s MBMS Broadcast Mode service is supported and one cell can support 4
such services. The TTI for 256kbit/s service is 40ms.
Enhancement
In RAN 10.0, the maximum number of 256kbit/s channels is enhanced from 4 to 7 per cell.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 31 of 174
WRFD-010616 MBMS Introduction Package
1.4.11 WRFD-010661 MBMS over Iur
Availability
This feature is available from RAN 10.0.
This feature is introduced in 3GPP R6.
Summary
This feature supports the MBMS service crossing the Iur interface to extend the application
scope of the MBMS service.
Benefits
This feature provides completed functions of MBMS over Iur and keeps the MBMS service
continuity and improves user perception.
Description When CELL_PCH/CELL_FACH/URA_PCH UE moves into DRNC and Iur interface
exists:
− if there is no non-MBMS services established for this UE, SRNC will indicate UE to
release the RRC connection;
− If there has been non-MBMS services established for this UE, SRNS relocation with
CELL/URA update will be triggered.
When CELL_DCH UE moves into DRNC and Iur interface exists, Iur soft handover will
be triggered.
When UE moves into DRNC and Iur interface does not exist, DRNC will indicate UE to
release the RRC connection.
DRNC informs SRNC through Direct Information Transfer:
The MBMS service transfer mode in the cell during Session setup;
The MBMS service transfer mode change in the cell during session transferring;
The Preferred Frequency Layer information of MBMS service;
The Iur interface mobility management is enhanced in RAN11.0. For example, when the UE
which has MBMS service in PTP mode in CELL_DCH state moves to DRNC from SRNC, it
will setup a new RL through Iur interface. But if the cell in DRNC is transferring the MBMS
service through PTM mode, and the UE just has MBMS service, the UE will get the MBMS
service through PTM mode in DRNC to save transmission resources.
Enhancement
In RAN11.0, the DRNC informs the SRNC about more MBMS service control information
through the Direct Information Transfer message.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 32 of 174
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
The neighboring RNC should support MBMS Iur function.
Dependency on CN
NA
Dependency on Other Features
WRFD-010660 MBMS Phase 2
1.4.12 WRFD-010663 MSCH Scheduling
Availability
This feature is available from RAN11.0.
Summary
This feature enables the UE to perform DRX on the MTCH based on MSCH scheduling, thus
saving the power consumption of the UE.
Benefits
MSCH enables the UE to perform DRX on the MTCH and thus saves power consumption of
the UE.
Description
The RNC can send the MBMS scheduling information to the UE on the MSCH, which
enables the UE in PTM reception mode to implement Discontinuous Reception (DRX) on the
MTCH instead of continuous reception on the MTCH. This effectively reduces power
consumption of the UE. The MBMS scheduling information is sent periodically and the
period is called "MSCH reception cycle". The MSCH reception cycle and its offset
information are transmitted on the MCCH. When the MSCH is used, each S-CCPCH bearing
the MTCH/FACH should carry an MSCH/FACH. The channel mapping is shown below:
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 33 of 174
RAN11.0 supports the MSCH as follows: One cell supports up to 8 MSCHs (in the case of 16
MTCHs and 8 S-CCPCHs)
Restriction: If one S-CCPCH bears only one MTCH, then the MSCH should not be used.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010616 MBMS Introduction Package
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 34 of 174
1.5 LCS
1.5.1 WRFD-020801 Cell ID + RTT Function Based LCS
Availability
This feature is available from RAN3.0.
This feature is introduced in 3GPP R99.
Summary
With this feature, Huawei RAN supports location services based on Cell ID + RTT.
Benefits
This feature provides a location service for operators.
Description
Huawei RAN supports location service based on Cell-Id + RTT which locates the UE
(CELL-DCH) position by computing the TOA. (Time of Arrive).
The TOA can be derived by the Node B RTT (Round Trip Time) measurement and the UE
Rx-Tx time difference Type 2 measurement.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 35 of 174
NodeB
UE
RTT Measurement
UE Rx-Tx time difference Type2 Measurement
In the CELLID+RTT positioning method, the simplest solution is to take the geometrical
center of the reference cell coverage area as the positioning result. This solution requires no
positioning-related measurement and provides the shortest response time.
If the CN requires a positioning of high accuracy, the CELLID+RTT method must employ
more measurements as follows:
The RNC asks all cells in the active set to perform the RTT measurement.
The RNC asks the UE to perform the UE Rx-Tx type 2 measurement of the
corresponding cell. If the UE does not support the UE Rx-Tx type 2 measurements, the
RNC will ask the UE to perform the UE Rx-Tx type 1 measurement.
When the cell is located in the different RNC, the location over Iur is supported.
Enhancement
Location over Iur interface is supported in RAN5.1.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE is needed to report the relevant measurement results.
Dependency on Other Network Units
NA
Dependency on CN
CN is needed to trigger the location request.
Dependency on Other Features
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 36 of 174
NA
1.5.2 WRFD-020802 OTDOA Based LCS
Availability
This feature is available from RAN3.0.
This feature is introduced in 3GPP R99.
Summary
With this feature, Huawei RAN supports IPDL-OTDOA location services.
Benefits
This feature provides a location service for operators.
Description
Huawei supports the IPDL-OTDOA location services. In this feature, the RNC initiates and
keeps tracing the GPS timing of cell frame measurements from the Node Bs, which are
installed with a GPS card and support the GPS timing of cell frame measurement. In addition,
the RNC initiates and keeps tracing the SFN-SFN observed time difference measurement
from LMUs deployed in the network. By taking advantage of the latest measurement reports
RNC can calculate the latest RTD (Relative Time difference) of cells that are involved in a
positioning procedure.
When RNC receives a LOCATON REPORT CONTROL message and the IPDL-OTDOA
method is selected, it requests SFN-SFN observed time difference measurement from UE, and
it calculates the UE's position after it receives the corresponding measurement report. To
assist the position calculation, RNC may request RTT measurements from Node B and
relative Rx-Tx time difference measurements from UE.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
The corresponding Node Bs should be equipped USCU card with GPS function.
Dependency on UE
UE is needed to report the relevant measurement results.
Dependency on Other Network Units
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 37 of 174
Dependency on CN
CN is needed to trigger the location request.
Dependency on Other Features
NA
1.5.3 WRFD-020803 A-GPS Based LCS
Availability
This feature is available from RAN5.0.
This feature is introduced in 3GPP R99.
Summary
With this feature, Huawei RAN supports network-assisted GPS location services.
Benefits
This feature provides a highest accuracy location service.
Description
Huawei supports the UE-based and UE-assisted location services. To support this method,
RNC may deploy a GPS reference receiver to keep tracking the latest GPS data including
ephemeris, almanac, DGPS data, etc, and calculates the fresh GPS assistance data for UE
according to the latest GPS data and the UE's reference position.
When RNC receives a LOCATON REPORT CONTROL message and the A-GPS method is
selected, it sends a GPS measurement request to UE with the GPS assistance data calculated,
and calculates the position of UE when it receives the GPS measurement report. For
UE-based A-GPS method, RNC directly forwards the location estimate from UE to
MSC/SGSN.
When the cell locates in the different RNC, the location over Iur is supported.
Enhancement
RAN5.1 supports the positioning through the Iur interface.
Enhancement
None.
Dependency
Dependency on RNC
If GPS receiver is located at RNC, BSC6800 should be equipped with receiver unit, BSC6900
needs clock board such as GCGa to support this feature.
Dependency on Node B
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 38 of 174
If GPS receiver is located at Node B, Node B should be equipped with USCU card with GPS
function.
Dependency on UE
UE is needed to report the relevant measurement results.
Dependency on Other Network Units
NA
Dependency on CN
CN is needed to trigger the location request.
Dependency on Other Features
NA
1.5.4 WRFD-020804 LCS Classified Zones
Availability
This feature is available from RAN3.0
This feature is introduced in 3GPP R99.
Summary
This feature enables a classified zone set on the OAM to be mapped to a specific service area.
When a classified zone of the UE is changed, the RNC sends a location report to the CN.
Benefits
The operator can provide the information and service for the subscriber actively according to
the location of the subscriber. The subscriber in movement can obtain its location information
quickly.
Description
The RNC supports mapping a classified zone set by OAM to a specific Service Area. When a
mobile enters or leaves a classified zone, the RNC will generate a location report and send the
location report to corresponding CN through Location Report procedure. In LOCATION
REPORT message, the Service Area of the UE in the Area Identity IE will be included. The
CN shall react to the LOCATION REPORT message with service vendor specific actions.
Enhancement
None.
Dependency
Dependency on RNC
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 39 of 174
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
CN node must support this feature simultaneously.
Dependency on Other Features
NA
1.5.5 WRFD-020805 LCS over Iur
Availability
This feature is available from RAN5.1.
This feature is introduced in 3GPP R99.
Summary
With this feature, Huawei RAN can provide location services through the Iur interface to
extend the positioning area.
Benefits
As enhancement to location service, the positioning area is widely extended, and more
reliable and precise positioning capability is achieved.
Description
Location service over Iur is supported for CELL ID+RTT and A-GPS positioning.
CELL ID+RTT
CELL ID+RTT positioning is based on the cell position information and TOA (Time of
Arrival), for which RTT (Round Trip Time), UE RxTx time difference measurements are
needed. In case (illustrated in figure below ) inter-RNC handover happened during the
positioning with CELL ID+RTT, CELL ID+RTT positioning over Iur should be
performed, including Iur interface dedicated measurement for RTT and information
exchange for neighbor RNC cell reference position (Geographical Coordinates ).
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 40 of 174
Dedicated measurement over Iur for RTT
Iur dedicated measurement procedure for acquisition of RTT is illustrated in figure below.
Information exchange over Iur for cell reference position
To get the neighbor RNC cell reference position, information exchange procedure should be
performed, with “Information Type” IE set to “UTRAN Access Point Position”, illustrated in
figure below.
DRNC SRNC
DEDICATED MEASUREMENT INITIATION REQUEST
(Measurement Type: RTT)
DEDICATED MEASUREMENT INITIATION RESPONSE
DEDICATED MEASUREMENT REPORT
(Measurement Value: RTT)
DS-RTx
.
…
DS-NoUrgent
DS-Urgent
DS-PQ
Acquisition of RTT over Iur
SRNC
Site 2
Site 1
DRNC
MSC
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 41 of 174
A-GPS
GPS information is required by A-GPS positioning. RNC maintains the updated GPS data
from itself or neighboring RNCs. After the reference GPS receiver is configured, the GPS
data should be obtained from neighboring RNCs and the information exchange procedure
over Iub should be performed.
During the positioning, if reference cell is located in DRNC, then GPS data from DRNC will
be preferred, and information exchange over Iur for reference cell geographical position will
be triggered.
Information exchange over Iur for GPS information
Information exchange procedure for neighboring RNC‟s GPS information (with “Information
Type” IE set to “GPS Information”) is illustrated in figure below. To get the updated
information, periodic information reporting is applied.
Information exchange over Iur for reference cell geographical position
To get geographical position of reference cell, information exchange procedure is triggered on
demand, for every positioning.
RNC 2 RNC 1
INFORMATION EXCHANGE INITIATION REQUEST
(Information Type: GPS Information)
INFORMATION EXCHANGE INITIATION RESPONSE
INFORMATION REPORT
DRNC SRNC
INFORMATION EXCHANGE INITIATION REQUEST
(Information Type: UTRAN Access Point Position)
INFORMATION EXCHANGE INITIATION RESPONSE
(Geographical Coordinates)
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 42 of 174
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
The neighbouring RNC should support the information exchanging and related procedures.
Dependency on CN
NA
Dependency on Other Features
WRFD-020801 Cell ID + RTT Function Based LCS
WRFD-020803 A-GPS Based LCS
1.5.6 WRFD-020807 Iupc Interface for LCS service
Availability
This feature is available from RAN12.0.
Summary
This feature supports to connect RNC and SAS (Stand-Alone SMLC) with Iupc interface
which is fully compliant with 3GPP. In this way the LCS function is working under
DRNC SRNC
INFORMATION EXCHANGE INITIATION REQUEST
(Information Type: UTRAN Access Point Position)
INFORMATION EXCHANGE INITIATION RESPONSE
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 43 of 174
SAS-centric mode. This feature is usually employed when one SAS connects with many
RNCs.
Benefits
This feature offers a SAS centric Position Service mode. The merits of SAS centric mode are:
The deployed LCS algorithm and the accuracy for a certain LCS procedure are controlled by
the SAS. The operator can conveniently do the LCS service maintenance without the
technical support of RNC vendors.
In SAS-centric mode, the SAS calculate the location data. In this way, the RNC does not need
to reserve resource for LCS services.
Description
3GPP protocol offers SAS-centric mode and RNC-centric mode LCS functions.
When it works in SAS-centric mode, SAS can receive location request via RNC from CN, it
will initiate measurement request to RNC, RNC will trigger UE measurement and send the
measure result to SAS, SAS calculate the location and send the location result to CN via
RNC.
The SAS-centric mode is illustrated in the network diagram below:
Huawei supports to connect RNC and SAS with Iupc interface. The Iupc interface is fully
compliant with the 3GPP protocol. The Iupc interface is available with IP connection. All the
IP interface boards for Iu/Iur interface in RNC support Iupc with SCCP connection.
Huawei RNC supports the following functions:
SAS-centric mode: LCS algorithm and process are controlled by SAS, the RNC only offers LCS measurement;
R
N
C
(
S
M
L
C
)
I
u
U
E
R
N
C
U
E
U
E
S
A
S
L
C
S
C
l
i
e
n
t
G
M
L
C
M
S
C
I
u
S
A
S
I
u
P
C
I
u
b
U
u
R
N
C
R
N
C
I
u
r
S
G
S
N
N
o
d
e
B
N
o
d
e
B
U
E
G
P
S
n
e
t
w
o
r
k
,
f
o
r
e
x
a
m
p
l
e
:
W
A
R
N
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 44 of 174
In SAS-centric mode, RNC supports A-GPS and CELLID+RTT LCS method;
If the operator needs to use other LCS algorithm or process, the RNC-centric mode is
recommended.
Enhancement
None
Dependency
Dependency on RNC
IP interface boards of BSC6900 support this feature.
BSC6800 cannot support this feature.
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
When the operator employs Cell ID+RTT algorithm, the feature WRFD-020801 Cell ID
+ RTT Function Based LCS is needed.
When the operator employs A-GPS algorithm, the feature WRFD-020803 A-GPS Based
LCS is needed.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 45 of 174
2 MBB
2.1 HSUPA Prime Service
2.1.1 WRFD-010612 HSUPA Introduction Package
Availability
This feature is available from RAN6.0.
This feature is introduced in 3GPP R6.
Summary
This feature package enables the system to process HSUPA services, thus improving the
uplink rate and system throughput. This feature package provides basic functions of HSUPA
to meet the basic requirements for operation of HSUPA services.
Benefits
HSUPA improves the performance of UMTS network by providing higher rate and higher
throughput for the uplink as well as higher capacity for the system.
Description
High Speed Uplink Packet Access (HSUPA) is an important feature introduced in 3GPP
Release 6. A new uplink transport channel, E-DCH, is introduced. Like what is done for
HSDPA, HSUPA improves the system capacity and throughout for uplink by maximizing
power utilization and adjusting the uplink bit rate according to channel quality.
The key functions used in HSUPA for maximizing resource utilization include 2 ms/10 ms
TTI, Hybrid Automatic Repeat Request (HARQ), and fast scheduling at the Node B.
The basic principle behind HARQ for HSUPA is the same as that for HSDPA. After each
transmitted TTI, the Node B informs the transmitting UE of whether the uplink data was
received correctly or not. The UE retransmits the packet if incorrect reception occurs. HSUPA
HARQ either uses chase combing where each retransmission is the exact copy of the initial
data or incremental redundancy where the retransmission only contains the redundancy bits.
The fast scheduling algorithm at the Node B enables the system to make scheduling decision
with the minimum latency as close to the radio interface as possible. Even though the Node B
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 46 of 174
makes the scheduling decision, it is the UE that decides the transmitted power and the
transmit format.
In RAN6.0, only 10 ms TTI is supported and the maximum uplink rate is 1.44 Mbit/s (MAC
layer) per user. Each cell can support up to 20 HSUPA users.
Enhancement
In RAN10.0, HSUPA Introduction Package is enhanced. For details, refer to the enhancement
of the features in the package.
Dependency
Dependency on RNC
NA
Dependency on Node B
NBBI and NULP board can not support this feature.
Dependency on UE
UE should have HSUPA capability.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
2.1.2 WRFD-01061201 HSUPA UE Category 1 to 7
Availability
This feature is available from RAN6.0.
Summary
This feature enables Huawei Node B to support UEs of category 1 to category 7 defined in
3GPP.
Benefits
This feature supports HSUPA services for seven categories of UE so as to provide high bit
rate services for different categories of UEs. The maximum bit rate that can be achieved by
the UE depends on the UE specification.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 47 of 174
Description
In order to provide services of multiple bit rates, seven HSUPA UE categories are defined in
3GPP specifications. The maximum number of codes over the E-DCH supported varies with
the UE category. That is, different UE categories support different maximum bit rates.
For example, in the following table, UE of category 3 supports two SF4 codes and the
maximum data rate can be 1.44 Mbit/s.
E-DCH Category
Max. Capability Combination
E-DCH TTI Max. Data Rate (Mbit/s)
MAC Layer
10 ms TTI
MAC Layer
2 ms TTI
Air Interface
Category 1 1 x SF4 10 ms only 0.71 – 0.96
Category 2 2 x SF4 10 ms and 2 ms 1.44 1.40 1.92
Category 3 2 x SF4 10 ms only 1.44 – 1.92
Category 4 2 x SF2 10 ms and 2 ms 2.0 2.89 3.84
Category 5 2 x SF2 10 ms only 2.0 – 3.84
Category 6 2 x SF4 + 2 xS
F2
10 ms and 2 ms 2.0 5.74 5.76
Category 7 2 x SF4 + 2 xS
F2
10 ms and 2 ms 2.0 11.50 11.52
RAN10.0 supports SF2 and 2 ms TTI.
Enhancement
RAN6.0 supports only SF4 and TTI of only 10 ms. Therefore, UEs of categories 2, 4, 5, and 6
can support TTI of only 10 ms in RAN6.0.
RAN10.0 supports SF2 and 2 ms TTI of categories 1~6.
RAN12.0 supports UEs of categories 7.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 48 of 174
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010612 HSUPA introduction package
2.1.3 WRFD-01061206 Interactive and Background Traffic Class on HSUPA
Availability
This feature is available from RAN6.0.
Summary
This feature enables interactive and background services to be mapped to the E-DCH to
obtain a higher service rate and enhance user experience.
Benefits
This feature enables the system to support a higher speed RAB of the PS interactive and
background services.
Description
This feature enables the best effort (interactive and background) services to be mapped on the
E-DCH if a UE is HSUPA capable. The system sets a switch to enable or disable the feature
that BE traffic is mapped on to E-DCH. A service rate threshold is also set so that the
requested service can be mapped on E-DCH only when the requested service bit rate is higher
than the threshold. Otherwise, the requested service is mapped on the DCH. The service rate
threshold is configurable by the operator.
When the best effort service is carried on the E-DCH, the maximum uplink bit rate is 5.74
Mbit/s (MAC layer).
When a UE has BE service on E-DCH, it can use another DCH CS RAB or another DCH PS
RAB simultaneously. If the UE capability is allowed, the UE can be served by two HSUPA
RABs.
GBR of HSUPA BE traffic is set and used to estimate whether the maximum available
resource for HSUPA can satisfy the requirements of streaming services and BE services in
admission control. The GBR of HSUPA BE traffic is configurable by operator.
The HSUPA schedule algorithm also considers the configured GBR information of HSUPA
BE traffic.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 49 of 174
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010612 HSUPA Introduction Package
2.1.4 WRFD-01061210 HSUPA 1.44Mbit/s per User
Availability
This feature is available from RAN6.0
Summary
This feature enables the HSUPA rate per user to reach a maximum of 1.44 Mbit/s.
Benefits
This feature provides a higher peak bit rate and enhances the user experience.
Description
High Speed Uplink Packet Access (HSUPA) is an important feature of 3GPP Release 6 that
provides high speed service for uplink. With this feature, the UE with interactive or
background services on the E-DCH can reach the peak bit rate of 1.44 Mbit/s (MAC Layer).
Thus, user experience is greatly enhanced.
Enhancement
None.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 50 of 174
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should have the capability of HSDPA Category 3(or later)
Dependency on Other Network Units
NA
Dependency on CN
CN support the uplink speed of 1.44Mbit/s (or more)
Dependency on Other Features
WRFD-010612 HSUPA Introduction Package
2.1.5 WRFD-010614 HSUPA Phase 2
Availability
This feature is available from RAN10.0.
This feature is introduced in 3GPP R6.
Summary
HSUPA Phase2 is an enhanced HSUPA feature that supports 2ms transmission time interval
(TTI).
Compared with 10ms TTI provided in the HSUPA introduction package, this feature can
provide a higher uplink rate and lower delay. This feature provides a series of enhanced
HSUPA functions to meet the commercial requirements of HSUPA services.
Benefits
HSUPA improves the performance of UMTS network by providing higher rate and higher
throughput for the uplink and higher capacity for the system.
Description
High Speed Uplink Packet Access (HSUPA) is an important feature introduced in 3GPP
Release 6.
In RAN6.0, only 10 ms TTI is supported and the maximum uplink rate is1.44 Mbit/s (MAC
layer) /1.92 Mbit/s (physical layer) per user. Each cell supports up to 20 HSUPA users.
In RAN10.0, the 2 ms TTI is supported, the maximum uplink rate is 5.74 Mbit/s (MAC
layer)/5.76 Mbit/s (physical layer).
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 51 of 174
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
The BTS3812E, BTS3812A and BTS3812AE need to configure EBBI board,EBOI board,
EDLP or EDLPd board.
The BBU3806 need to configure EBBC/EBBCd board; the BBU3806C need to configure
EBBM board.
The BBU3900 need to configure WBBPb/WBBPd board.
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010612 HSUPA Introduction Package
The software dependency is described in each sub functions.
2.1.6 WRFD-01061403 HSUPA 2ms TTI
Availability
This feature is available from RAN10.0.
Summary
The 2ms TTI of HSUPA enables a single user to obtain a higher UL throughput and shorter
delay.
Benefits
By using a shorter TTI on the Uu interface, HSUPA has the following advantages:
Faster data scheduling
Higher UL peak data rate
Lower latency
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 52 of 174
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 Category
Max. Capability Combination
E-DCH TTI Max. Data Rate (Mbit/s)
MAC Layer
10 ms TTI
MAC Layer
2 ms TTI
Air Interface
Category 1 1 x SF4 10 ms only 0.71 – 0.96
Category 2 2 x SF4 10 ms and 2 ms 1.45 1.40 1.92
Category 3 2 x SF4 10 ms only 1.45 – 1.92
Category 4 2 x SF2 10 ms and 2 ms 2.0 2.89 3.84
Category 5 2 x SF2 10 ms only 2.0 – 3.84
Category 6 2 x SF4 + 2 x
SF2
10 ms and 2 ms 2.0 5.74 5.76
Category 7 2 x SF4 + 2 x
SF2
10 ms and 2 ms 2.0 11.498 11.52
Compressed mode measurement is available for E-DCH 2 ms in the case of inter-frequency
and inter-RAT handover.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
The BTS3812E, BTS3812A and BTS3812AE need to configure EBBI board, EBOI
board, EDLP or EDLPd board.
The BBU3806 need to configure EBBC/EBBCd board; the BBU3806C need to configure
EBBM board.
The BBU3900 need to configure WBBPb/WBBPd board.
Dependency on UE
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 53 of 174
UE should have the capability of HSDPA Category 2, 4, 6, 7, 8, 9
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010612 HSUPA Introduction Package
2.1.7 WRFD-01061405 HSUPA 5.74Mbit/s per User
Availability
This feature is available from RAN10.0.
Summary
This feature enables the HSUPA rate per user at MAC layer to reach a maximum of 5.74
Mbit/s. The rate is a peak rate defined in 3GPP specifications.
Benefits
This feature greatly enhances user experience.
Description
Based on the 2 ms TTI and enhanced fast UL schedule, with 2 SF4 and 2 SF2 codes
combination, the UE can reach the peak rate of 5.74 Mbit/s at MAC layer.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
The BTS3812E, BTS3812A, and BTS3812AE should be configured with the EULP,
EBBI, EBOI, EULPd board.
The BBU3806 should be configured with the EBBC, EBBCd board; the BBU3806C
should be configured with the EBBM board.
The BBU3900 should be configured with the WBBPb, WBBPd board.
Dependency on UE
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 54 of 174
UE should have the capability of HSDPA Category 6,7,8,9
Dependency on Other Network Units
NA
Dependency on CN
CN support the uplink speed of 5.74Mbit/s (or more)
Dependency on Other Features
WRFD-010636 SRB over HSUPA
2.1.8 WRFD-010632 Streaming Traffic Class on HSUPA
Availability
This feature is available from RAN6.0.
This feature is introduced in 3GPP R6.
Summary
This feature enables the streaming service to be mapped onto the E-DCH, thus improving the
utilization of cell resources.
Benefits
This feature enables the system to support higher speed RAB of the PS streaming traffic.
Description
This feature enables the streaming service to be mapped on the E-DCH if a UE is HSUPA
capable. The system sets a switch to enable or disable the feature by which the streaming
traffic can be mapped on the E-DCH. And a service rate threshold is also need to be set so that
only when the requested service bit rate is higher than the threshold, the request service can be
mapped on the E-DCH. Otherwise, the requested service will be mapped on the DCH. The
service rate threshold can be set by the operators too.
When the streaming service is carried on the E-DCH, the maximum uplink bit rate can reach
up to 384 kbit/s.
The UE with the streaming service on the E-DCH can use another CS RAB or another PS
RAB simultaneously. One HSUPA BE RAB and one HSUPA streaming RAB can be served
on one UE simultaneously if the capability of the UE is allowed.
The GBR of the streaming traffic is used to estimate whether the maximum available resource
for the HSUPA can satisfy the requirement of the streaming service 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.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 55 of 174
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010612 HSUPA Introduction Package
2.1.9 WRFD-010635 HSUPA over Iur
Availability
This feature is available from RAN10.0.
This feature is introduced in 3GPP R6.
Summary
This feature enables HSUPA services to be carried on the Iur interface and provides
continuous HSUPA services for UEs moving between RNCs.
Benefits
The HSUPA over the Iur provides continuous HSUPA services for mobile users moving
between the RNCs. It enlarges the range of the HSUPA services to the RNCs which have the
Iur connections with a certain RNC.
Description
The HSUPA over the Iur is the scenario that the DRNC cell is in the HSUPA E-DCH active
state. The feature comprises the HSUPA service management over the Iur, the HSUPA
mobility management over the Iur, and so on. The HSUPA capability of the DRNC cell is
configurable.
HSUPA service management over Iur
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 56 of 174
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 process is similar to that on the Iub interface.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
The neighbouring RNC must support HSUPA over Iur too.
Dependency on CN
NA
Dependency on Other Features
WRFD-010612 HSUPA Introduction Package
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 57 of 174
2.2 HSUPA Performance Improvement
2.2.1 WRFD-010637 HSUPA Iub Flow Control in Case of Iub Congestion
Availability
This feature is available from RAN10.0.
This feature is introduced in 3GPP R6.
Summary
This feature enables the monitoring of Iub transmission resources to dynamically adjust the
uplink Uu throughput, thus greatly improving the resource utilization.
Benefits
This feature can improve the transport resource usage efficiency greatly and reduce the
throughput fluctuation in the case of the Iub congestion.
Description
The UL Uu throughput is controlled by the scheduler according to the UL load resource and
the Iub bandwidth resource simultaneously. The schedule algorithm estimates the influence on
the load resource and the Iub resource of the change of the serving grant (SG) and decides
whether to assign the absolute grant (AG) or relative grant (RG) to UEs.
The flow control algorithm maintains the Iub available bandwidth resource on the following
principles:
1. The Iub buffer occupancy status:
If the Iub buffer occupancy ratio increases, the available bandwidth may be reduced by a
step.
If the Iub buffer occupancy ratio decreases, the available bandwidth may be increased by
a step.
2. The transmission network congestion status (the Node B detects it according to the
transmission network layer (TNL)) indicator is indicated by the RNC:
If the transmission network is congested, the available bandwidth may be reduced by a
step.
If the transmission network is not-congested, the available bandwidth may be increased
by a step.
Enhancement
None.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 58 of 174
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010612 HSUPA Introduction Package
2.2.2 WRFD-010636 SRB over HSUPA
Availability
This feature is available from RAN10.0.
This feature is introduced in 3GPP R6.
Summary
This feature enables UL SRBs to be carried over HSUPA. This feature can obtain a lower call
delay and save transmission resources.
Benefits
This feature provides higher signaling rate and reduces the call process delay. Since the SRB
is carried on the HSUPA, the transmission resource can be saved, compared with that is
carried on the DCH.
Description
The signaling over the SRB is delay sensitive and irregular. Compared with the DCH, it is
more appropriate to set up the SRB over the HSUPA. The SRB over the HSUPA can be
applied during the RRC connection setup or other procedures such as the mobility
management.
If the SRB is set up over the DCH, it can be reconfigured to be mapped on the HSUPA in
some cases such as the target cell of the handover supports the HSUPA while the source cell
does not. Inversely, the SRB mapping on the HSUPA can also be reconfigured to be mapped
on the DCH if the target cell of the handover does not support the HSUPA.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 59 of 174
The SRB over the HSUPA is configurable. The operator can enable/disable the SRB over
HSUPA function.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
The 38XX series Node B supports this feature, and the EBBI, EBOI, EULP, EULPd,
EBBC, EBBCd or EBBM is required.
The 3900 series Node B supports this feature, and the WBBPb or WBBPd is required.
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010612 HSUPA Introduction Package
2.3 HSDPA Prime Service
2.3.1 WRFD-010610 HSDPA Introduction Package
Availability
This feature is available from RAN5.0.
This feature is introduced in 3GPP R5.
Summary
High Speed Downlink Packet Access (HSDPA) is one of the important features defined in
3GPP specifications. HSDPA can greatly increase the peak rate per user, shorten the round trip
delay, and improve the system capacity. This feature package provides the basic functions of
HSDPA to meet the requirements for test or trial operations of HSDPA services.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 60 of 174
Benefits
HSDPA improves the performance of the UMTS network in the following aspects:
Providing high rate throughput
Shorter round trip time
Higher system capacity
Description
High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5.
The maximum downlink throughput is achieved by sharing CE resources, power resources,
and code resources with new physical channels and downlink shared transport channel for
HSDPA. The physical channels are HS-SCCH, HS-PDSCH, and HS-DPCCH, and the
transport channel is HS-DSCH. HD-PDSCH (SF = 16) will utilize the remaining TX power
and codes in a cell, which enables the resource to be dynamically shared among users.
Some key functions are also used in HSDPA for maximizing resource utilization, including 2
ms TTI, hybrid ARQ with soft combining (HARQ), Adaptive Modulation and Coding (AMC),
and fast scheduling algorithm.
The application of 2 ms TTI greatly reduces the round trip time. At the same time, some
functions are moved down to the Node B that also contributes to reducing the round trip time.
When compared with RLC re-transmission, HARQ provides a more highly efficient
re-transmission mechanism. The UE can request for retransmission of only erroneously
received data immediately and combine the retransmission data with original transmission
data through soft combining.
AMC enables the system to decide the Transport Block (TB) size and the modulation mode
according to estimated channel condition indicated by the UE. When the UE is in favorable
radio environment, the transmission can adopt 16 QAM modulation mode and large transport
blocks to increase the capacity and data rate.
The fast scheduling algorithm includes Max C/I, Round Robin, Proportional Fair (PF), and
Enhanced Proportional Fair (EPF). EPF is based on the PF algorithm which can provide users
with Guaranteed Bit Rate service for I/B services.
HSDPA is mainly used for packet services and can bear the interactive, background, and
streaming services. The HSDPA traffic can use a dedicated carrier or a shared carrier with
R99. The system should be capable of handling both cases.
The system should consider the mobility management of the HSDPA services, such as the
intra-RNC handover, inter-RNC handover, and soft handover for the DCH.
Enhancement
In RAN5.1, RAN6.0, and RAN10.0, HSDPA Introduction Package is enhanced. For details,
see the enhancements of the sub-features in the HSDPA Introduction Package.
Dependency
Dependency on RNC
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 61 of 174
Dependency on Node B
NBBI and NDLP do not support this feature.
Dependency on UE
UE should have the HSDPA capability.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
2.3.2 WRFD-01061017 QPSK Modulation
Availability
This feature is available from RAN5.0.
Summary
This feature is related to QPSK modulation. QPSK modulation is a basic downlink data
modulation function that is used after HSDPA is introduced.
Benefits
This feature provides higher service bit rate to enhance the user experience.
Description
Quaternary Phase Shift Keying (QPSK)
The HS-PDSCH is used to carry the HS-DSCH data. HS-PDSCH can use QPSK or 16QAM
modulation symbols.
When the UE is in the unfavorable radio environment, the transmission can adopt the low
order QPSK modulation mode and small transport blocks to ensure communication quality.
When the UE is in the favorable radio environment, the transmission can adopt the high order
16QAM modulation mode and large transport blocks to reach a high peak rate.
Enhancement
None.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 62 of 174
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
2.3.3 WRFD-01061001 15 Codes per Cell
Availability
This feature is available from RAN5.0.
Summary
This feature provides code resources occupied by Huawei HSDPA services. The HS-PDSCHs
can use up to 15 codes in a cell.
Benefits
HSDPA with 15 codes makes it possible to introduce higher bit rate service from day one and
improve system capacity.
Description
High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5,
which provides high speed downlink services. A new downlink shared transport channel,
HS-DSCH, is introduced for carrying services. The transport channel HS-DSCH is mapped on
one or several High-Speed Physical Downlink Shared Channels (HS-PDSCHs) which are
simultaneously received by the UE. In the 3GPP standard, there are up to 15 HS-PDSCHs per
cell with the spreading factor fixed to 16. The number of HS-PDSCHs per Node B is
configurable and depending on the license, the Node B can dynamically share codes licences
to HS-PDSCH between cells.
The HS-PDSCHs can use up to 15 codes in one cell by which the supported peak rate of air
interface can reach up to 14.4 Mbit/s. The system capacity is improved by supporting 15
codes.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 63 of 174
Enhancement
None
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
2.3.4 WRFD-01061018 Time and HS-PDSCH Codes Multiplex
Availability
This feature is available from RAN5.0.
Summary
This feature enables the allocation of different codes in the same TTI to different users or the
time division multiplexing of the same code in different TTIs for different users to provide the
utilization of code resources and the system throughput.
Benefits
This feature improves the efficiency and performance of HSDPA service.
Description
The parallel data transmission of multiple users over HS-DSCH requires more HS-SCCH
codes and HS-PDSCH codes within a single TTI. Code multiplexing is adopted and is found
useful when the Node B has more HS-PDSCH codes for allocation than those supported by
the UE. For instance, the UE supports 5 codes and the Node B has 10 codes available in a
single TTI. The code multiplexing can increase the resource utilization and system
throughput.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 64 of 174
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
2.3.5 WRFD-01061008 Interactive and Background Traffic Class on HSDPA
Availability
This feature is available from RAN5.0.
Summary
This feature enables interactive and background services to be mapped to the HS-DSCH to
obtain a higher service rate and enhance user experience.
Benefits
This feature enables the system to support a higher speed RAB of PS background and
interactive service.
Description
This feature enables the best effort service (interactive and background) to be mapped onto
the HS-DSCH as long as the UE supports HSDPA. The system can set the service rate
threshold and only when the requested service bit rate is higher than the threshold, the request
service can be mapped onto the HS-DSCH. Otherwise, the requested service will be mapped
onto the DCH. The service rate threshold can be configured by the operator. When the best
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 65 of 174
effort service is carried on the HS-DSCH, the maximum downlink bit rate can be up to 1.8
Mbit/s (MAC layer).
When a UE is performing interactive or background service, it can use another CS RAB or
another PS RAB. If allowed, the UE can use two HSDPA BE RABs simultaneously.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
2.3.6 WRFD-01061002 HSDPA UE Category 1 to 28
Availability
This feature is available from RAN5.0.
Summary
This feature can provide suitable HSDPA services for the UEs of category 1 to category 28.
Benefits
This feature supports HSDPA services for 28 categories of UE so as to provide high bit rate
service for different categories of UEs. The maximum bit rate that can be achieved by the UE
depends on the UE specification.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 66 of 174
Description
High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5
which can provide high speed service for the downlink. In order to provide multiple bit rate
services, 28 UE categories are defined in 3GPP. Different UE categories can support different
maximum codes for the HS-DSCH, which means that different maximum bit rates can be
achieved.
HS-DSCH Category
Maximum Number of HS-DSCH Codes Received
Minimum Inter-TTI Interval
Maximum Number of Bits
Maximum Bit Rate
(Mbit/s)
Category 1 5 3 7,298 3.649
Category 2 5 3 7,298 3.649
Category 3 5 2 7,298 3.649
Category 4 5 2 7,298 3.649
Category 5 5 1 7,298 3.649
Category 6 5 1 7,298 3.649
Category 7 10 1 14,411 7.2055
Category 8 10 1 14,411 7.2055
Category 9 15 1 20,251 10.1255
Category 10 15 1 27,952 13.976
Category 11 5 2 3,630 1.815
Category 12 5 1 3,630 1.815
Category 13 15 1 35,280 17.64
Category 14 15 1 42,192 21.096
Category 15 15 1 23,370 23.37
Category 16 15 1 27,952 27.952
Category 17 15 1 35,280 17.64
23,370 23.37
Category 18 15 1 42,192 21.096
27,952 27.952
Category 19 15 1 35,280 35.280
Category 20 15 1 42,192 42.192
Category 21 15 1 23,370 23.370
Category 22 15 1 27,952 27.952
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 67 of 174
HS-DSCH Category
Maximum Number of HS-DSCH Codes Received
Minimum Inter-TTI Interval
Maximum Number of Bits
Maximum Bit Rate
(Mbit/s)
Category 23 15 1 35,280 35.280
Category 24 15 1 42,192 42.192
Category 25 15 1 23,370 46.740
Category 26 15 1 27,952 55.904
Category 27 15 1 35,280 70.560
Category 28 15 1 42,192 84.384
Note: In the "Maximum Number of Bits" column, the bits refer to bits received by the
HS-DSCH transport block during a TTI on the HS-DSCH.
In the preceding table,
UEs of category 13 and category 14 are only required to support 64QAM.
UEs of category 15 and category 16 are only required to support MIMO.
UEs of category 17 and category 18 support 64QAM and MIMO, but not simultaneously.
UEs of category 19 and category 20 support 64QAM+MIMO.
UEs of category 21 and category 22 support 16QAM+DC-HSPA \.
UEs of category 23 and category 24 support 64QAM+DC-HSPA.
UEs of category 25 and category 26 support 16QAM+MIMO+DC-HSPA.
UEs of category 27 and category 28 support 64QAM+MIMO+DC-HSPA.
Enhancement
In RAN11.0, UEs of category 13, category 14, category 15, category 16, category 17, and
category 18 are introduced.
In RAN12.0, UEs of category 19 to category 24 are introduced.
In RAN13.0, UEs of category 25 to category 28 are introduced.
Dependency
Dependency on RNC hardware
None
Dependency on Node B hardware
None
Dependency on other RAN features
WRFD-010610 HSDPA Introduction Package
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 68 of 174
Dependency on other NEs
None
2.3.7 WRFD-01061015 HSDPA 1.8Mbit/s per User
Availability
This feature is available from RAN5.0.
Summary
This feature enables the HSDPA rate to reach a maximum of 1.8 Mbit/s for each user.
Benefits
This feature provides higher peak bit rate and enhances the end user experience.
Description
High Speed Downlink Packet Access (HSDPA) is an important feature of 3GPP Release 5
which can provide high speed service for the downlink. With this feature, the UE with
interactive or background service on the HS-DSCH can reach a peak rate of up to 1.8 Mbit/s
(MAC layer), thus greatly enhancing the user experience.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should have the capability of HSDPA Category 12(or later):category 3,4,5,6,7,8,9,10,12,
13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28
Dependency on Other Network Units
NA
Dependency on CN
CN support user rate of 1.8Mbit/s or above.
Dependency on Other Features
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 69 of 174
WRFD-010610 HSDPA Introduction Package
2.3.8 WRFD-010620 HSDPA 3.6Mbit/s per User
Availability
This feature is available from RAN5.1.
This feature is introduced in 3GPP R5.
Summary
This feature enables the HSDPA rate per user to reach a maximum of 3.6 Mbit/s.
Benefits
This feature provides a higher peak bit rate and enhances user experience.
Description
HSDPA is an important feature of 3GPP Release 5 that can provide high speed service for
downlink. With this feature, the UE with interactive or background services on the HS-DSCH
can reach the peak bit rate up to 3.6 Mbit/s (MAC layer). Thus, user experience is greatly
enhanced.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should have the capability of HSDPA Category 5(or later):category 5,
6,7,8,9,10,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28
Dependency on Other Network Units
NA
Dependency on CN
CN support user rate of 3.6Mbit/s or above.
Dependency on Other Features
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 70 of 174
WRFD-010610 HSDPA Introduction Package
2.3.9 WRFD-010629 DL 16QAM Modulation
Availability
This feature is available from RAN5.0.
This feature is introduced in 3GPP R5.
Summary
Compared with the QPSK modulation, the 16QAM modulation is a higher-order downlink
data modulation mode. This feature enables the peak rate on the Uu interface to reach 14.4
Mbit/s.
Benefits
Provides higher peak bit rate HSDPA service for HSDPA users.
Description
The HS-PDSCH is used to carry the HS-DSCH data. The HS-PDSCH may use QPSK or
16QAM modulation symbols.
When the UE is in poor radio environment, the transmission can adopt the low-order QPSK
modulation mode and small transport blocks to ensure communication quality.
When the UE is in good radio environment, the transmission can adopt the high-order
16QAM modulation mode and large transport blocks to achieve high peak rate.
The UE of category 10 can support a maximum of 15 HS-PDSCH codes and 16QAM
modulation mode. The supported peak rate on the air interface can reach 14.4 Mbit/s.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should have the capability of HSDPA besides Category 11 and Category 12:category
1,2,3,4,5,6,7,8,9,10,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28
Dependency on Other Network Units
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 71 of 174
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
2.4 HSDPA Performance Improvement
2.4.1 WRFD-010621 HSDPA 7.2Mbit/s per User
Availability
This feature is available from RAN6.0.
Summary
This feature enables the HSDPA rate per user to reach a maximum of 7.2 Mbit/s.
Benefits
This feature provides a higher peak bit rate and enhances user experience.
Description
HSDPA is an important feature of 3GPP Release 5 that can provide high speed service for
downlink. With this feature, the UE with interactive or background services on the HS-DSCH
can reach the peak bit rate of up to 7.2 Mbit/s (MAC layer). Thus, user experience is greatly
enhanced.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should have the capability of HSDPA Category 7(or later):category
7,8,9,10,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28
Dependency on Other Network Units
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 72 of 174
NA
Dependency on CN
CN support user rate of 7.2Mbit/s or above.
Dependency on Other Features
WRFD-010620 HSDPA 3.6Mbit/s per User
WRFD-010629 DL 16QAM Modulation
2.4.2 WRFD-010611 HSDPA Enhanced Package
Availability
This feature is available from RAN5.1.
This feature is introduced in 3GPP R5.
Summary
This feature provides a series of enhanced HSDPA functions to meet the commercial
requirements of HSDPA services.
Benefits
Enhance the HSDPA performance by introducing the GBR-based QoS guarantee mechanism.
Enhance the HSDPA networking capability to meet HSDPA networking requirements.
Description
HSDPA enhanced package is introduced on the basis of WRFD-010610 HSDPA Introduction
Package, and provides enhancement features to meet the QoS and HSDPA network
requirements. Related features include:
EPF and GBR Based Scheduling
HSDPA State Transition
HSDPA DRD (Direct Retry Decision)
HS-DPCCH preamble support
Enhancement
In RAN6.0 and RAN10.0, this feature is enhanced. For details, refer to the enhancement of
the features in the package.
Dependency
Dependency on RNC
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 73 of 174
Dependency on Node B
NA
Dependency on UE
UE should support the functions connected with HSDPA Enhanced package.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
2.4.3 WRFD-01061113 HS-DPCCH Preamble Support
Availability
This feature is available from RAN10.0.
Summary
This feature enables the transmission of dedicated preamble subframes before ACK/NACK
subframes are transmitted on the HS-DPCCH, thus improving transmission reliability.
Benefits
HS-DPCCH preamble mode technology enables the Node B to distinguish between DTX and
ACK/NACK without requiring high ACK transmit power
The uplink coverage gain is about 0.2 dB to 0.9 dB with different accompanying DPCH
services.
Description
The High Speed Dedicated Physical Control Channel (HS-DPCCH) carries uplink feedback
signaling related to downlink HS-DSCH transmission. The HS-DSCH-related feedback
signaling consists of Hybrid-ARQ Acknowledgement (HARQ-ACK) and Channel-Quality
Indication (CQI).
If UE detects the HS-SCCH control message, it will reply with an ACK or NACK message
based on the result of the decoding and it will inform the sender of the result to further request
retransmissions.
If the UE does not detect the HS-SCCH control message, it will reply with a DTX message.
To reduce the probability that the Node B decodes this DTX as ACK by mistake, the transmit
power of the ACK/NACK message should be high.
Huawei supports HS-DPCCH preamble mode detection. The proposed enhancement is to
send special Preamble sub-frames in the uplink HS-DPCCH before an ACK/NACK sub-frame. This method reduces the probability of a DTX->ACK error in the Node B, because
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 74 of 174
the Node B has to decode at least two successive timeslots erroneously before the earlier
mentioned scenario can take place. Due to the prior preamble information detection, the same
performance of the HARQ-ACK field detection can be sustained with lower power.
N
HS-DPCCH
HS-DSCH
HS-SCCH
ACK or NACK
Data Packet
N N+1 N+2 N+3
N N+1 N+2 N-1
PRE
PREAMBLE transmitted in sub-frame N-1 to indicate reception of relevant signalling information in sub-frame N on HS-SCCH
Normal ACK/NACK to indicate correct or incorrect decoding of packet
POSTAMBLE transmitted in sub-frame N+1 (unless a packet is correctly decoded from sub-frame N+1 on the HS-DSCH, or control information is detected in sub-frame N+2 on the HS-SCCH)
N+1 N+2 N+3
POST
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
This feature also depends on the Node B hardware:
The BTS3812E, BTS3812A and BTS3812AE need to configure EBBI board, EBOI
board, EULP or EULPd board.
The BBU3806 needs to configure EBBC or EBBCd board; the BBU3806C needs to
configure EBBM board.
0 needs to configure WBBPb or WBBPd board.
Dependency on UE
UE should have the capability of HSDPA Category 6(or later) and support this feature.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 75 of 174
WRFD-010610 HSDPA Introduction Package
2.4.4 WRFD-010630 Streaming Traffic Class on HSDPA
Availability
This feature is available from RAN5.0.
This feature is introduced in 3GPP R5.
Summary
This feature enables the streaming services to be mapped onto the HS-DSCH, thus improving
the utilization of cell resources.
Benefits
This feature enables the system to support a higher speed RAB of PS streaming service.
Description
This feature enables the streaming service to be mapped onto the HS-DSCH if a UE is
HSDPA capable. The system sets a switch to enable or disable the feature that streaming
service is mapped onto the HS-DSCH. A service rate threshold is also set only when the
requested service bit rate is higher than the threshold. At this time, the requested service can
be mapped onto the HS-DSCH. Otherwise, it will be mapped onto DCH. The service rate
threshold can also be configured by the operator.
When the streaming service is carried on the HS-DSCH, the maximum downlink bit rate can
reach 384 kbit/s.
When a UE has a streaming service on the HS-DSCH, it can use another CS RAB or another
PS RAB simultaneously. One HSDPA BE RAB and one HSDPA streaming RAB can be used
by one UE simultaneously if the UE capability permits.
Enhancement
In RAN5.1, GBR of streaming traffic is used to estimate whether the maximum available
power for HSDPA can satisfy the requirement of streaming service and
interactive/background service in admission control in RAN5.1.
The HSDPA scheduling algorithm also considers the GBR information of streaming traffic so
that all HSDPA streaming services are guaranteed when the bit rate is not less than GBR.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 76 of 174
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010611 HSDPA Enhanced Package
2.4.5 WRFD-010650 HSDPA 13.976Mbit/s per User
Availability
This feature is available from RAN10.0.
This feature is introduced in 3GPP R5.
Summary
This feature enables the HSDPA rate per user to reach a maximum of 13.976 Mbit/s.
Benefits
This feature provides a higher peak bit rate and enhances user experience.
Description
HSDPA is an important feature of 3GPP Release 5 that can provide high speed service for
downlink. With this feature, the UE with interactive or background services on the HS-DSCH
can reach the peak bit rate up to 13.976 Mbit/s (MAC layer). Thus, user experience is greatly
enhanced.
Enhancement
None.
Dependency
Dependency on RNC
This feature requires WFMRc board in BSC6800.
Dependency on Node B
NA
Dependency on UE
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 77 of 174
UE should have the capability of HSDPA Category 10, 13(or later),category
10,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28
Dependency on Other Network Units
NA
Dependency on CN
CN support user rate of 13.976Mbit/s or above.
Dependency on Other Features
WRFD-010621 HSDPA 7.2Mbit/s per User
2.4.6 WRFD-010651 HSDPA over Iur
Availability
This feature is available from RAN10.0.
This feature is introduced in 3GPP R5.
Summary
This feature enables HSDPA services to be carried on the Iur interface and provides
continuous HSDPA services for UEs moving between RNCs.
Benefits
HSDPA over Iur provides continuous HSDPA services for mobile users moving between
RNCs. It enlarges the range of HSDPA services to the RNCs that have Iur connections with a
certain RNC.
Description
HSDPA over Iur is the scenario where the HSDPA serving cell is carried at the DRNC. The
feature includes HSDPA service management over Iur, HSDPA mobility management over Iur,
and so on.
HSDPA service management over Iur
HSDPA service management over Iur refers to HSDPA service setup, modification,
release, and state transition.
When the UE is in the CELL_DCH state and the DRNC cell is in the active set or the UE
is in the CELL_FACH state and camps in a DRNC cell, the HSDPA service can be setup,
modified, and released over Iur.
The service over Iur can be reconfigured between HSDPA and R99 with UE state
transition between CELL_DCH and CELL_FACH.
HSDPA mobility management over Iur
HSDPA mobility management over Iur includes hard handover, cell update (caused by
radio link failure), and serving cell change.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 78 of 174
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
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
The neighbouring RNC should also support HSDPA over Iur.
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
2.4.7 WRFD-010652 SRB over HSDPA
Availability
This feature is available from RAN10.0.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 79 of 174
This feature is introduced in 3GPP R6.
Summary
SRB over HSDPA enables the DL SRBs of multiple UEs to be carried over HSDPA through
the FDPCH multiplexing technology, thus reducing the consumption of DL code resources
and the call setup delay.
Benefits This feature provides a higher signaling rate and reduces the call process delay.
Compared with the scenario where the SRB is carried on the DCH, code resources are
saved and cell load is reduced when the SRB is carried on HSDPA.
Description
The signaling over SRB is delay-sensitive and irregular. In some cases, the code may be
limited prior to power and the cell capacity is affected. Thus, it is more appropriate to set up
SRB over the HSDPA rather than the DCH. When compared with SRB over DCH, SRB over
HSDPA and F-DPCH multiplexing can save code resources.
SRB over HSDPA can be applied during the RRC connection setup procedure or other
procedures such as mobility management.
If the SRB is set up over the DCH, it can be reconfigured to the mapping on HSDPA in some
cases, for example, the target cell of handover supports HSDPA while the source cell does not.
Inversely, the SRB mapping on HSDPA can also be reconfigured to the mapping on DCH if
the target cell of handover does not support HSDPA.
SRB over HSDPA is configurable. The operator can also configure whether SRB over HSDPA
is applied to RRC connection setup or not.
Enhancement
Enhanced F-DPCH is supported in RAN11.0.
Dependency
Dependency on RNC
NA
Dependency on Node B
This feature depends on the Node B hardware:
The BTS3812E, BTS3812A and BTS3812AE need to configure EBBI board, EBOI
board or EDLP board.
The BBU3806 needs to configure EBBC or EBBCd board; the BBU3806C needs to
configure EBBM board.
The BBU3900 need to configure WBBPb or WBBPd board
Dependency on UE
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 80 of 174
The UE should support FDPCH/EFDPCH
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
2.5 HSPA+ Prime Service
2.5.1 WRFD-010680 HSPA+ Downlink 28Mbit/s per User
Availability
This feature is available from RAN11.0.
This feature is introduced in 3GPP R7.
Summary
This feature enables the HSPA+ MIMO rate per user to reach a maximum of 28 Mbit/s. This
feature enhances the user experience for high-speed data services.
Benefits This feature can improve the frequency utilization and increase the maximum downlink
rate.
This feature can provide end users with high-speed data experience.
Description
HSPA+ is introduced in 3GPP Release 7 to provide high speed data services. With this feature,
the peak downlink rate increases from 13.976 Mbit/s per user in R6 to 28 Mbit/s per user
(MAC layer).
Enhancement
DC-HSDPA is available from RAN12.0. With DC-HSDPA and downlink 16QAM, the peak
downlink rate also can increases from 13.976 Mbit/s per user in R6 to 28 Mbit/s per user
(MAC layer).
Dependency
Dependency on RNC
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 81 of 174
This feature requires WFMRc board in BSC6800.
Dependency on Node B
The BTS3812E, BTS3812A, and BTS3812AE should be configured with the EBBI,
EBOI or EDLP board.
The BBU3806 should be configured with the EBBC or EBBCd board; the BBU3806C
should be configured with the EBBM board.
The BBU3900 should be configured with the WBBPb or WBBPd board.
For the RF part, the RF module of Huawei Node B supports one TX channel each, and
two interconnected RF modules can provide two TX channels to support 2 x 2 MIMO
Dependency on UE
The UE category must support cat16, cat18(or later)
Dependency on Other Network Units
NA
Dependency on CN
CN support user rate of 28Mbit/s or above.
Dependency on Other Features
WRFD-010684 2*2 MIMO
WRFD-010650 HSDPA 13.976Mbit/s per User
or
WRFD-010696 DC-HSDPA
WRFD-010650 HSDPA 13.976Mbit/s per User
2.5.2 WRFD-010681 HSPA+ Downlink 21Mbit/s per User
Availability
This feature is available from RAN11.0.
This feature is introduced in 3GPP R7.
Summary
This feature enables the HSPA+ 64QAM rate per user to reach a maximum of 21 Mbit/s. With
this feature, users can enjoy high-speed data experience.
Benefits This feature can improve the frequency utilization and increase the maximum downlink
rate.
This feature can provide end users with high-speed data experience.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 82 of 174
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 Mbit/s per user in R6 to 21 Mbit/s per
user (MAC layer).
Enhancement
None.
Dependency
Dependency on RNC
This feature requires WFMRc board in BSC6800.
Dependency on Node B
To support this feature, the following configurations are required:
The BTS3812E, BTS3812A and BTS3812AE need to configure EBBI board, EBOI
board or EDLP board.
The BBU3806 needs to configure EBBC or EBBCd board; the BBU3806C needs to
configure EBBM board.
The BBU3900 needs to configure WBBPb or WBBPd board.
Dependency on UE
The UE category must support cat 14,18,20,24 or 28
Dependency on Other Network Units
NA
Dependency on CN
CN support user rate of 21Mbit/s or above.
Dependency on Other Features
WRFD-010683 64QAM
WRFD-010650 HSDPA 13.976 Mbit/s per User
2.5.3 WRFD-010685 Downlink Enhanced L2
Availability
This feature is available from RAN11.0.
This feature is introduced in 3GPP R7.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 83 of 174
Summary
Downlink Enhanced L2 supports the variable PDU size, which eliminates the contradictions
between the high-speed transmission that requires a large PDU size and the cell-edge
coverage that requires a small PDU size. This feature enables the dynamic adjustment of the
PDU size to improve the transmission efficiency on the Iub and Uu interfaces and increase the
cell edge throughput and coverage radius.
Benefits
This feature is a prerequisite of the 64QAM, MIMO, and enhanced CELL_FACH, which also
improves the transmission efficiency on the Iub and Uu interfaces.
Description
Downlink Enhanced L2 supports the variable PDU size, which eliminates the contradictions
between the high-speed transmission that requires a large PDU size and the cell-edge
coverage that requires a small PDU size. In addition, enhanced L2 reduces excessive overhead
caused by the fixed PDU size, and thus improves the transmission efficiency on the Iub and
Uu interfaces.
Downlink Enhanced L2 is a prerequisite for 64QAM, MIMO and enhanced CELL_FACH. It
removes the restrictions on the RLC window for users whose transmission rate is more than
14 Mbit/s. At the cell edge, small PDU size requires relative low SNR, thus better service
coverage and throughput will be attained.
Enhancement
None.
Dependency
Dependency on other RAN software functions
WRFD-010610 HSDPA Introduction Package
Dependency on UE
The UE must be Release 7 (or later) UE and support this feature.
2.5.4 WRFD-010689 HSPA+ Downlink 42Mbit/s per User
Availability
This feature is available from RAN12.0. It is introduced in 3GPP Release 8.
Summary
This feature enables the peak rate of the data service over HSPA+ to reach 42 Mbit/s per user.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 84 of 174
Benefits This feature improves the frequency utilization and increases the maximum downlink
rate.
This feature provides end users with high-rate data services.
Description
HSPA+ is introduced in 3GPP Release 7 to provide high-rate data services. With the
2*2MIMO+64QAM or 64QAM+DC HSDPA technologies introduced in R8 and the enhanced
performance of relevant NEs, the peak downlink rate per user reaches up to 42 Mbit/s.
TCP protocol is widely used in data transmission. As a file is being downloaded, the TCP
acknowledgement is sent in uplink. The higher the rate of download is, the larger the
bandwidth is required in uplink. If the download rate reaches up to 42Mbit/s, the rate of TCP
acknowledgement in uplink is much higher than 384 kbit/s which is the highest rate supported
by DCH. HSUPA bearer is required to provide high bandwidth in uplink to transmit TCP
acknowledgement in time. DL 42Mbit/s per user can be supported only in case of HSUPA
being used.
Enhancement
None.
Dependency
Dependency on RNC
Only BSC6900 supports this feature.
When this feature is applied, DPUe board is preferred to support more users with peak
rate.
DPUb board is not recommended for commercial deployment and it is only valid for
trials.
Dependency on NodeB
The BTS3812E, BTS3812A, or BTS3812AE must be configured with the EBBI, EBOI
or EDLP board.
The BBU3806 must be configured with the EBBC or EBBCd card; the BBU3806C must
be configured with the EBBM card.BBU3806C+EBBM only supports 64QAM+DC
HSDPA function.
The BBU3900 must be configured with the WBBPb or WBBPd card.
For the RF part which supports only one TX channel, two interconnected RF modules
can provide two TX channels to support 2 x 2 MIMO. In terms of RF modules including
2 Tx channels, no additional RF modules is required for 2*2MIMO.
Dependency on other RAN software functions
WRFD-010689 HSPA+ Downlink 21Mbit/s per User plus WRFD-010696 DC-HSPA plus
WRFD-010612 HSUPA Introduction Package,
or
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 85 of 174
WRFD-010689 HSPA+ Downlink 21Mbit/s per User plus WRFD-010680 HSPA+ Downlink
28Mbit/s per User plus WRFD-010693 DL 64QAM+MIMO plus WRFD-010612 HSUPA
Introduction Package
Dependency on other NEs
The UE should support category of 21(or later), categorie: 21, 22, 23, 24, 25, 26, 27, 28.
Dependency on CN
CN needs to support sending RAB assignment with relate data rate.
2.5.5 WRFD-010683 Downlink 64QAM
Availability
This feature is available from RAN11.0.
This feature is introduced in 3GPP R7.
Summary
Compared with the 16QAM modulation, the 64QAM modulation is a higher-order downlink
data modulation mode. This feature enables the peak rate on the Uu interface to reach 21
Mbit/s.
Benefits
Downlink 64QAM increases the peak rate per user and improves the local cell capability.
Operators attach great importance to data service and regard it as a growing point for profits.
Many consulting companies predict that the data traffic volume will grow rapidly and
accordingly raise higher requirements to the network throughput. If the bandwidth remains
unchanged, 64QAM will increase the average throughput of the system by 7% to 16% and
further improves the spectral efficiency of the system. In this way, the system provides users
with higher throughput and ultimately increases operators' profits on the per bandwidth basis.
On the other hand, 64QAM also raises the peak rate per user and provides a higher download
data rate for users. This enhances not only user experience but also operators'
competitiveness.
Description
3GPP R5 introduces 16QAM to increase the peak rate per user and expands the system
capacity, whereas 64QAM introduced in 3GPP R7 protocols is a further enhancement of
16QAM.
With downlink 64QAM, higher order modulation technology than 16QAM can be used when
the channel is of higher quality. Theoretically, 64QAM supports a peak data rate of 21 Mbit/s
and at the same time increases the average throughput of the system. Simulation shows that
compared with 16QAM, 64QAM can increase the average throughput by 7% and 16%
respectively in macro cell and in micro cell, if the UEs in the cells use the type 3 receivers.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 86 of 174
The 3GPP R7 protocols define the categories of the UEs that support 64QAM, and add the
information elements (IEs) that support 64QAM in the reporting of local cell capability. The
RNC determines whether the RL between the Node B and the UE supports 64QAM according
to the local cell capability reported by the Node B and the UE capability. If the RL supports
64QAM, the MAC-hs scheduler of the Node B determines every 2 ms whether to use 64QAM
according to the following aspects:
Channel Quality Indicator (CQI) reported by the UE
HS-PDSCH code resources and power resources of the Node B
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
The BTS3812E, BTS3812A and BTS3812AE need to configure EBBI board, EBOI
board or EDLP board.
The BBU3806 need to configure EBBC, EBBCd board; the BBU3806C need to
configure EBBM board.
The BBU3900 need to configure WBBPb, WBBPd board.
Dependency on UE
The UE category must support 64QAM. That is, the UE must belong to category
13,14,17,18,19,20,23, 24, 27, 28, as specified by the 3GPP protocols
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
WRFD-010685 Enhanced L2
2.5.6 WRFD-010684 2×2 MIMO
Availability
This feature is available from RAN11.0.
This feature is introduced in 3GPP R7.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 87 of 174
Summary
Based on space dimension resources, MIMO uses the multi-antenna technology at the
transmit end and receive end. This feature can double the transmission capacity of the
wireless communication system in a high SNR environment without the transmit power
added.
Benefits
2x2 MIMO increases the average throughput and peak rate of the cell. In the case of
unchanged bandwidth, 2x2 MIMO increases the average throughput of the system by 14% to
23%. Theoretically, the peak rate per 2X2 MIMO user can be twice the original peak rate. In
addition, MIMO has gains even under lower geographical factors (G = Ior/Ioc) and have more
gains under higher Ior/Ioc. From the service point of view, MIMO has a similar driving force
to 64QAM.
Description
2x2 Multiple Input Multiple Output (MIMO) uses two transmit antennas at the Node B to
transmit orthogonal (parallel) data streams to the two receive antennas at the UEs. Using two
antennas and additional signal processing at the receiver and the transmitter, 2x2 MIMO can
increase the system capacity and double user data rates without using additional bandwidth.
2x2 MIMO adopts different modes in the 3GPP protocols, with QPSK and 16QAM in R7, and
later with 64QAM in R8. With dual-stream dual-antenna mode and16QAM modulation, the
peak data rate per user is doubled to 28 Mbit/s and the average throughput of the system is
enhanced.
The 3GPP R7 protocols define the categories of the UEs that support MIMO, and add the
information elements (IEs) that support MIMO in the reporting of local cell capability. The
RNC determines whether the RL between the Node B and the UE supports MIMO according
to the local cell capability and UE capability reported by the Node B. If the RL supports
MIMO, the MAC-hs scheduler of the Node B determines every 2 ms whether to use MIMO
according to the following aspects:
Channel Quality Indicator (CQI) reported by the UE
Precoding Control Indication (PCI)
HS-PDSCH code resources and power resources of the Node B
For MIMO and HSDPA Co-carrier scenario, please refer to WRFD-010700 Performace
Improvement of MIMO and HSDPA Co-carrier.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
The BTS3812E, BTS3812A and BTS3812AE need to configure EBBI board, EBOI
board or EDLP board.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 88 of 174
The BBU3806 needs to configure EBBC, EBBCd board; the BBU3806C needs to
configure EBBM board.
The BBU3900 needs to configure WBBPb, WBBPd board.
For the RF part, the RF module of Huawei Node B supports one TX channel each and
two interconnected RF modules can provide two TX channels to support 2 x 2 MIMO.
20W RRU3801c can only support MIMO by using together with the same module (20W
RRU3801c)
Dependency on UE
The UE must belong to category 15(or later), that is category 15, 16, 17, 18, 19, 20, 21, 22, 23,
24, 25, 26, 27, 28
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
WRFD-010685 Downlink Enhanced L2
WRFD-010629 DL 16QAM Modulation
2.5.7 WRFD-010693 DL 64QAM+MIMO
Availability
This feature is available from RAN12.0.
Summary
MIMO and 64QAM are introduced in 3GPP Release 7 and can only be used independently. In
3GPP Release 8, however, MIMO and 64QAM can be used in combination to increase the
peak throughput of a single user.
Benefits
With 64QAM+MIMO, the peak throughput of a single user can reach 42Mbit/s, compared to
28Mbit/s with 16QAM+MIMO or 21Mbit/s with 64QAM only.
Description Channel bearer
The SRB, CS service, IMS signaling, and PS conversational services are not carried on
MIMO, 64QAM, or MIMO+64QAM because the data flow is small and the gain is
insignificant. The PS streaming service, PS interactive service, PS background service,
and the combined services with previous services can be carried on MIMO+64QAM.
Scheduling
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 89 of 174
The user scheduling based on a new extended CQI table for the MIMO+64QAM user is
supported.
Mobility management
The UE can be handed over from an MIMO+64QAM capable cell to an MIMO+64QAM
incapable cell and the MIMO+64QAM falls back. If UE moves in the opposite direction,
the MIMO+64QAM can be reconfigured to the UE after handover.
Enhancement
None.
Dependency
None
2.5.8 WRFD-010698 HSPA+ Uplink 11.5 Mbit/s per User
Availability
This feature is available from RAN13.0.
Summary
This feature provides an uplink peak rate of 11.5 Mbit/s for a single user through uplink
16QAM and E-DPCCH boosting.
Benefits
This feature improves spectrum efficiency and increases the peak uplink rate, allowing end
users to enjoy high-speed uplink data services.
Description
This feature utilizes 16QAM (introduced in 3GPP Release 7) and E-DPCCH boosting to
increase the uplink peak rate from 5.74 Mbit/s to 11.5 Mbit/s.
Enhancement
None
Dependency
Dependency on RNC hardware
None
Dependency on NodeB hardware
The BTS3812E and BTS3812AE need to be configured with the EULPd board, and the
downlink services cannot be setup on HBBI/HDLP/NDLP board.
The DBS3800 needs to be configured with the EBBCd board.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 90 of 174
The 3900 series multi-mode base stations need to be configured with the WBBPd board.
or
The BTS3812E and BTS3812AE need to be configured with the EULP/EULPd board.
The DBS3800 needs to be configured with the EBBC/EBBCd board.
The 3900 series multi-mode base stations need to be configured with the
WBBPb/WBBPd board.
Dependency on other RAN features
WRFD-010694 UL 16QAM
WRFD-010614 HSUPA Phase 2
WRFD-010697 E-DPCCH Boosting
or
WRFD-140204 DC-HSUPA
WRFD-010614 HSUPA Phase 2
Dependency on other NEs
The UE must support E-DPCCH boosting. The UE must be of HSUPA category 7, 8, or
9.
The CN must support an uplink data rate of 11.5Mbit/s or above.
UL Layer 2 Improvement
or
The UE must support HSUPA and be the one of HSUPA category 8, or 9.
The CN must support an uplink data rate of 11.5Mbit/s or above.
2.5.9 WRFD-010703 HSPA+ Downlink 84 Mbit/s per User (Trial)
Availability
This feature is available from RAN13.0.
Summary
This feature provides a downlink peak rate of 84 Mbit/s for a single user through the
simultaneous use of 64QAM, multiple-input multiple output (MIMO), and dual-cell HSDPA
(DC-HSDPA).
Benefits
This feature enables end users to enjoy high-speed data services.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 91 of 174
Description
3GPP Release 9 defines the scenario where MIMO and DC-HSDPA are used together. When
the techniques 64QAM, MIMO, and DC-HSDPA are jointly used, a peak downlink rate of 84
Mbit/s can be achieved for a single user.
Enhancement
None
Dependency
Dependency on RNC hardware
The DPUe is required to support this feature.
Dependency on NodeB hardware
The BTS3812AE/BTS3812E and DBS3800 cannot provide the downlink peak rate of 84
Mbit/s per user.
The 3900 series multi-mode base stations need to be configured with the
WBBPd/WBBPb3/WBBPb4 board.
Dependency on other RAN features
WRFD-010689 HSPA+ Downlink 42Mbit/s per User
WRFD-010693 Downlink 64QAM+MIMO
WRFD-010699 DC-HSDPA+MIMO
Dependency on other NE
The UE must be of category 28 to support 84 Mbit/s in the downlink, according to 3GPP
Release 9.
CN support user rate of 84Mbit/s or above.
Downlink 64QAM
2.5.10 WRFD-010699 DC-HSDPA+MIMO (Trial)
Availability
This feature is available from RAN13.0.
Summary
DC-HSDPA+MIMO is introduced in 3GPP Release 9. This feature combines DC-HSDPA
(introduced in 3GPP Release 8) and MIMO (introduced in 3GPP Release 7). This feature
allows the NodeB to send HSDPA data to a UE simultaneously over two adjacent carriers on
the same frequency band within the same coverage area by using MIMO.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 92 of 174
Benefits
This feature fully utilizes the advantages of dual-carrier and dual-antenna techniques of
DC-HSDPA and MIMO respectively. It improves the spectrum efficiency and thus
significantly increases the single-user peak throughput, cell-edge-user throughput, and cell
capacity.
Increasing the single user peak throughput
DC-HSDPA+MIMO achieves higher spatial multiplexing gain than DC-HSDPA. This
feature doubles the single-user peak rate from 28 Mbit/s to 56 Mbit/s (When using
16QAM modulation) or from 42 Mbit/s to 84 Mbit/s (with 64QAM).
DC-HSDPA+MIMO uses two carriers simultaneously while SC-HSDPA uses only one
carrier. This feature doubles the single-user peak rate, as mentioned previously.
Increasing the cell-edge-user throughput
DC-HSDPA+MIMO achieves closed-loop transmit diversity gain on the cell edge,
compared with DC-HSDPA.
DC-HSDPA+MIMO use two carriers and thus doubles the throughput, compared with
SC-HSDPA+MIMO.
Increasing the cell capacity
DC-HSDPA+MIMO improve the spectrum efficiency within 10 MHz bandwidth and
Huawei simulation testshows that it can increase the system throughput by 10% to 20 %,
compared with DC-HSDPA.
Description
The following figure shows the basic principles of DC-HSDPA+MIMO.
The DC-HSDPA+MIMO feature brings together the performance enhancement benefits of the
two different technologies DC-HSDPA and MIMO.
RAN13.0 supports the configuration of MIMO on one or two carriers to reach the theoretical
peak rate of 63 Mbit/s or 84 Mbit/s respectively.
The PS best effort services are carried over DC-HSDPA+MIMO.
DC-HSDPA+MIMO apply the same principles as DC-HSDPA in load control and mobility
management.
Enhancement
None
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 93 of 174
Dependency
Dependency on RNC hardware
None
Dependency on NodeB hardware
The BTS3812E and BTS3812AE need to be configured with the EBBI or EDLP board,
and the uplink services cannot be setup on HBBI/HULP board.
The DBS3800 needs to be configured with the EBBC or EBBCd board. In addition, the
DBS3800 supports a maximum of DC+MIMOx1, that is, only one frequency in the
DC-HSDPA cell can be configured with the MIMO feature.
The 3900 series multi-mode base stations need to be configured with the WBBPb or
WBBPd board.
Dependency on other RAN features
WRFD-010696 DC-HSDPA
WRFD-010684 2x2 MIMO
Dependency on other NEs
The UE must be of HS-DSCH category 25, 26, 27, or 28.
Differentiated Service Management
2.5.11 WRFD-010694 UL 16QAM
Availability
This feature is available from RAN12.0.
Summary
3GPP Release 7 introduces HSUPA UE category 7, which supports the 16QAM mode and an
UL peak rate of up to 11.5 Mbit/s in theory.
Benefits
The UL system capacity of the HSUPA network is increased.
The peak rate of HSUPA users (UE category 7) is increased.
Description
3GPP R7 introduces UE category 7, which supports the 16QAM mode and an UL peak rate of
up to 11.5 Mbit/s in theory. This is a 100% improvement over the previous 3GPP release of
HSUPA for which the maximum peak rate is 5.74 Mbit/s"
The HSUPA 16QAM improves the UL data transmission performance and increases the system capacity of HSUPA cells.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 94 of 174
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
The BTS3812E/BTS3812AE must be configured with the EULPd board.
The DBS3800 supports must be configured with the EBBCd board.
The 3900 series base stations must be configured with the WBBPd board.
Dependency on UE
The UE must be of category 7, category 9.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010614 HSUPA Phase 2
2.5.12 WRFD-010695 UL Layer 2 Improvement
Availability
This feature is available from RAN12.0.
Summary
In RAN11.0 or earlier versions, the UL radio link controller (RLC) operates only in fixed
PDU mode. The size of protocol data units (PDUs) is fixed. After UL layer 2 improvement is
introduced, the UL RLC (in UM and AM modes) can operate in flexible PDU or fixed PDU
mode, depending on the higher-layer configuration. When the RLC operates in flexible PDU
mode, it can receive PDUs of flexible sizes so as to decrease the size of UL PDUs and
increase the UL throughput in the case that the UL transmit power of the UE is limited.
Benefits
This feature improves the user peak throughput as well as the uplink throughput in weak
coverage. When the UE moves from the center of the cell to the border of the cell and no
layer 2 improvement is available, the transmit power of the UE is limited if the distance from
the center of the cell reaches a specified value. In such a case, the throughput decreases
sharply, and the transportation may be interrupted. After UL layer 2 improvement is
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 95 of 174
introduced, the throughput can decrease smoothly because the size of PDUs transmitted by
the UE decreases. Therefore, the transportation is more continuous.
Description
In 3GPP R7, in the downlink, MAC layer segmentation is introduced through the change from
the fixed PDU size to the flexible PDU size for the RLC. Therefore, the DL supports the high
rate, DL layer 2 evolution, and smooth evolution of old protocol formats to new formats.
The UL has similar problems. The PDUs of a fixed size cannot support high rate services
effectively because PDUs of a small size are not applicable to high rate services. Though
PDUs of a large size are applicable to high rate services, the power at the border of the cell is
limited. Moreover, the fixed PDU size may lead to additional padding bits, thus affecting the
transmission efficiency.
UL layer 2 improvement has the following characteristics:
RLC supports flexible RLC PDU sizes.
The MAC layer introduces the MAC-i/is entity. The biggest difference between the
MAC-i/is entity and the MAC-e/es entity is that the MAC-i/is entity supports data
segmentation and concatenation at the MAC layer and can select an appropriate PDU
size based on the air interface quality to improve the data transmission efficiency.
The RNC can determine whether layer 2 improvement is required according to the UE
capability, cell capability, and active set capability.
The network side supports the handover between the cells with UL layer 2 improvement and
the cells without UL layer 2 improvement.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
For BTS3812E and BTS3812AE, EBBI/EBOI/EULP/EULPd is needed.
For BBU3806,EBBC or EBBCd is needed;For BBU3806C,EBBM is needed.
For BBU3900, WBBPb or WBBPd is needed.
Dependency on UE
The UE need to be compliant with 3GPP Release 8(or later) to support the feature
Dependency on Other Network Units
NA
Dependency on CN
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 96 of 174
Dependency on Other Features
WRFD-010612 HSUPA Introduction Package
WRFD-010685 Downlink Enhanced L2
2.5.13 WRFD-010696 DC-HSDPA
Availability
This feature is available from RAN12.0.
Summary
The Dual Cell-HSDPA (DC-HSDPA) feature allows the UE to establish connections to two
adjacent inter-frequency same-coverage cells. With this feature, the UE can use the resources
in both cells that operate on different carriers, thus increasing the peak throughput of the UE.
Benefits
This feature improves the single-user throughput and the cell throughput.
Single-user throughput
After DC-HSDPA is introduced, the throughput is doubled at the center and border of the cell.
Theoretically, DC-HSDPA in 64QAM mode can provide a peak throughput of 42 Mbit/s at the
center of the cell. The gain also shortens the data transmission delay and improves the user
experience.
Cell throughput
After DC-HSDPA is introduced, DC-HSDPA has the cell throughput gain of 5%–10% relative
to the total throughput of the two inter-frequency co-coverage cells. The gain is inversely
proportional to the number of UEs in a cell.
Description Configuration of primary and secondary carriers
When two frequencies, for example, f1 and f2 are used in DC-HSDPA, one DL frequency
serves as the primary carrier and the other as the secondary carrier, which is defined in 3GPP
TR25.825. In the UL, only one frequency is used, which serves as the primary carrier.
Both DC-HSDPA cells are configured with the PCPICH, SCH, PCCPCH, SCCPCH, and
PRACH. Both cells have the basic common channel (CCH) configuration for retaining and
initiating services. The single carrier (SC) UEs can camp or originate a call in each cell.
DC-HSDPA differentiated bearer policy
The CS service, IMS signaling, SRB signaling, or PS conversational service is carried on a
single carrier instead of DC-HSDPA because the amount of data is small and the gain is
insignificant when DC-HSDPA is used.
The BE or streaming service can be carried over the DC-HSDPA. The BE/streaming
combined service is carried over the DC-HSDPA preferentially.
Mobility management
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 97 of 174
The active set information and measurement reports are sent on the primary carrier during the
handover of DC users. Whether to perform an intra-frequency or inter-frequency handover
depends on the frequencies of the primary carrier and the neighboring cell.
RAN12.0 supports handovers between DC cells, between the DC cell and the SC cell, and
between the DC cell and the system using the other RAT, to ensure seamless roaming of DC
terminals.
State transition in DC-HSDPA
The UE state transition in DC-HSDPA is performed in the same way as the state transition in
SC mode.
Traffic steering in DC-HSDPA
In the original network, R99 services preferentially use f1 and HSPA services use f2. After
DC-HSDPA is introduced, both f1 and f2 can be used for DL DC-HSDPA, and f2 is preferred
for HSUPA. In this way, the UL load on f1 is reduced, without disrupting R99 services.
If the R99 and HSPA services have the same priority on f1 and f2 in the original network,
traffic steering is kept the same as that of HSPA after DC-HSDPA is introduced.
STTD mode is not supported when activate DC-HSDPA.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
The HBBI and HDLP of the BTS3812E/BTS3812AE do not support DC-HSDPA. To
support DC-HSDPA, the EBBI or EDLP board must be configured.
The BBU3806 with EBBC/EBBCd and the BBU3806C with EBBM support this feature.
The 3900 series base station supports the function when the WBBPb or WBBPd is
configured.
Dependency on UE
The HS-DSCH capabilities are classified into category 21, 22, 23, 24, 25, 26, 27, 28.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010610 HSDPA Introduction Package
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 98 of 174
WRFD-010685 Downlink Enhanced L2
WRFD-010629 DL 16QAM Modulation
2.6 HSPA+ Performance Improvement
2.6.1 WRFD-010688 Downlink Enhanced CELL-FACH
Availability
This feature is available from RAN11.0.
This feature is introduced in 3GPP R7.
Summary
This feature enables the FACH to be carried on the HS-DSCH. Based on this feature, the UE
can receive data at a higher rate in CELL_FACH state.
Benefits
This feature enables the UE to transmit data at a higher rate in CELL_FACH state and shorten
the state transition delay of the UE, thereby enhancing the experience of end users in online
state.
Description
Enhanced CELL-FACH is a new feature introduced in R7.
Based on this feature, the UE can receive data on the HS-DSCH at a higher rate in
CELL_FACH state.
After this feature is introduced, the UE is still in CELL_FACH state. This feature is used for
downlink data transmission of the UE. The data carried on the BCCH, CCCH, DCCH, or
DTCH can be mapped to the HS-DSCH and then transmitted to the UE through the HSDPA
shared channel on the Uu interface. In this case, the UE in CELL_FACH state can share
HSDPA code resources and power resources as the UE in CELL_DCH does, thus
implementing downlink high-speed data transmission and shortening the state transition delay
of the UE. This feature enhances the traditional CELL-FACH that is used for only low-speed
(32 kbit/s) data transmission. In R7, the UE incapable of enhanced CELL-FACH uses the
traditional CELL-FACH to receive data, and the UE capable of enhanced CELL-FACH uses
the enhanced CELL-FACH to receive data if the cell on which the UE camps supports the
enhanced CELL-FACH.
To enable the UE to receive data from the HS-DSCH in CELL_FACH state, UTRAN adds
HS-DSCH receiving parameters in CELL_FACH state to the system broadcast information.
The parameters include HS-SCCH configuration, HS-PDSCH configuration, and common
H-RNTI identifier.
When the cell is configured with HS-DSCH receiving, the UE preferentially uses the
HS-DSCH to receive dedicated signaling data carried on the FACH in CELL_FACH state instead of on the SCCPCH.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 99 of 174
The UE in CELL_FACH state keeps monitoring the HS-SCCH. If any data is available, the
UE automatically receives data from the HS-DSCH without state handover from the FACH to
DCH, thus avoiding the delay caused by the state handover.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
HBBI、HDLP on BTS3812E/BTS3812AE do not support this feature, EBBI, EDLP is
needed.
BBU3806 does not support this feature, EBBC or EBBCd is needed. EBBM is needed
by BBU3806C to support this feature.
3900 series NodeB: WBBPa does not support this feature, WBBPb or WBBPd is needed.
Dependency on other RAN software functions
WRFD-010685 Downlink Enhanced L2
Dependency on other NEs
The UE must be Release 7 (or later) UE and support this feature.
2.6.2 WRFD-010686 CPC - DTX / DRX
Availability
This feature is available from RAN11.0.
This feature is introduced in 3GPP R7.
Summary
This feature is related to uplink DTX and downlink DRX. This feature can reduce the
interference between UEs and improve the HSPA+ user capacity per cell.
Benefits
This feature can improve the always online experience of end users, increase the system
capacity, and save the battery consumption of the UE.
Description
Discontinuous Transmission (DTX)/Discontinuous Reception (DRX) are the key features of
the CPC, which consists of DTX in the uplink and DRX in the downlink.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 100 of 174
Uplink DTX means that the UE automatically makes discontinuous transmission on the
DPCCH according to a certain pattern when there is no transmission on the EDCH and the
HS-DPCCH in the uplink. The UL DPCCH DTX pattern is configured by SRNC to on one
hand minimize the transmission on DPCCH and on the other hand maintain the physical
uplink synchronization between Node B and UE by periodically sending. Uplink DTX
reduces the noise raised by the DPCCH in the uplink and also reduces the redundant signal on
the DPCCH.
Downlink DRX is implemented on the basis of Uplink DTX. Downlink DRX means that the
UE receives data on the HS-SCCH according to the transport pattern that RNC configures,
and thus the UE need not detect the HS-SCCH in the period when no data would be sent
according to the pattern.
In the scenario that multi-users continue to download with full of data in downlink, this
feature can reduce uplink load by 30% to 40% as well as help to save UE‟s battery in different
level.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
For the BTS3812E, BTS3812A and BTS3812AE, the EBBI, EBOI, EULP/EULPd
(supporting uplink DTX), and EDLP (supporting downlink DRX) should be configured.
For the BBU3806, the EBBC/EBBCd should be configured. For the BBU3806C, the
EBBM should be configured.
For the BBU3900, the WBBPb/WBBPd should be configured.
Dependency on UE
The UE must be Release-7 (or later) to support this feature.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010652 SRB over HSDPA
WRFD-010636 SRB over HSUPA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 101 of 174
2.6.3 WRFD-010687 CPC - HS-SCCH less operation
Availability
This feature is available from RAN11.0.
This feature is introduced in 3GPP R7.
Summary
This feature is related to HS-SCCH less operation. This feature can increase the capacity of
downlink data services.
Benefits
This feature can increase the capacity of downlink data services.
Description
The HS-SCCH Less HS-DSCH Transmission (HS-SCCH Less Operation for short)
mechanism means that the HS-DSCH need not be accompanied by the HS-SCCH when
sending the predefined small transport blocks, and the HARQ retransmission for the first
HS-DSCH transmission requires the company of the HS-SCCH. This is one of the key
features of the CPC.
HS-SCCH Less HS-DSCH Transmission only applies to the UE in CELL_DCH state when
the F-DPCH is configured but the DCH is not configured in the UL and DL directions
(actually the uplink is more concerned). This mechanism can be initiated without DTX/DRX,
that is, HS-SCCH Less HS-DSCH Transmission and DTX/DRX are independent of each
other.
In addition, HS-SCCH Less Operation has the following features:
Supports the QPSK modulation only.
Supports only four predefined transport formats (MAC-hs PDU).
Provides four semi-static transport formats for UEs.
HS-PDSCH CRC is 24 bit and UE-specific (HS-PDSCH CRC is the same as HS-SCCH
CRC; therefore, HS-PDSCH CRC contains a 16-bit H-RNTI).
Allocates up to two predefined HS-PDSCH codes to each UE:
− The predefined HS-PDSCH codes are allocated to the UE in semi-static state.
− The UE can receive HS-SCCH Less HS-DSCH Transmission at any time on one or
two codes, and can perform blind detection in four formats.
− The UE must keep cyclic buffer for 13 continuous TTIs for blind detection of the
HS-PDSCH codes.
The UE does not send the NACK for the first transmission but it sends the ACK/NACK
for retransmission.
Limitations of HARQ:
− Two retransmissions
− Predefined redundancy version (not configurable)
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 102 of 174
HARQ retransmission of HS-SCCH Less HS-DSCH Transmission should accompany
the HS-SCCH by using the same channel codes and encoding modes between Release 5
and Release 6. Some bits, however, may change their meanings and inform the UE of the
following information:
− The HS-SCCH is used for HS-SCCH Less Operation.
− The retransmission is the first or the second one.
− The channel codes and TB size used by HARQ.
− HARQ combined information, which uses the offset of current TTI to indicate the
position where the information has been sent.
The UE keeps attempting to receive data from the HS-SCCH in a traditional sense.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
The UE must be Release-7 (or later) to support this feature.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-010652 SRB over HSDPA
WRFD-010636 SRB over HSUPA
2.6.4 WRFD-010697 E-DPCCH Boosting
Availability
This feature is available from RAN13.0.
Summary
This feature uses the E-DCH dedicated physical control channel (E-DPCCH) instead of the
DPCCH as the reference channel for channel estimation during HSUPA demodulation. This
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 103 of 174
feature helps reduce the SIR requirement of the DPCCH and increase the rates of HSUPA
services.
Benefits
This feature together with uplink 16QAM increases uplink rates to the theoretical peak rate
11.5 Mbit/s instead of less than 8 Mbit/s due to SIR target limitation of the DPCCH.
Description
E-DPCCH boosting is introduced in 3GPP Release 7.
This technique is a prerequisite for uplink 16QAM to increase uplink rates because a higher
rate requires more accurate channel estimation.
Traditionally, the DPCCH is selected as the reference channel for channel estimation. The
DPCCH, however, cannot meet the power requirement in the case of high-speed transmission
bursts in the uplink. This is because the DPCCH power is affected by outer-loop power
control, and therefore delay exists in the power adjustment. Also, the SIR target of the
DPCCH is limited. These limitations of the DPCCH adversely affect the accuracy of channel
estimation.
To solve this limitation, the E-DPCCH boosting technique increases the transmit power of
E-DPCCH and uses the E-DPCCH for channel estimation. The boosting technique can lower
the requirement for DPCCH SIR.The E-DPCCH can increase the accuracy of channel
estimation because its transmit power is not limited. In this way, this feature improves the
reception quality of uplink high-speed services.
Enhancement
None
Dependency
Dependency on RNC hardware
None
Dependency on NodeB hardware
The BTS3812E and BTS3812AE need to be configured with the EULPd board, and the
downlink services cannot be setup on HBBI/HDLP/NDLP board.
The DBS3800 needs to be configured with the EBBCd board.
The 3900 series multi-mode base stations need to be configured with the WBBPd board.
Dependency on other NEs
The UE must be Release-7 (or later) to support the boosting technique.
Dependency on CN
CN supports data bit rate of 11.5Mbit/s or above.
Dependency on other RAN features
WRFD-010612 HSUPA Introduction Package
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 104 of 174
2.6.5 WRFD-010701 Uplink Enhanced CELL_FACH
Availability
This feature is available from RAN13.0.
Summary
This feature enables the random access channel (RACH) to be mapped onto the E-DCH
Dedicated Physical Data Control Channel (E-DPDCH). With this feature, UEs in the
CELL_FACH state can transmit uplink data at higher rates.
Benefits
This feature improves the "always-on" experience by providing high-speed uplink data
transmission for UEs in the CELL_FACH state and shortening the UE state transition and
service setup delay.
Compared with the traditional CELL_FACH state, the service setup delay for a UE to transit
from idle mode to the CELL_DCH state and the UE state transition delay from CELL_FACH
to CELL_DCH can be shortened by more than 50%.
Description
Enhanced uplink for the CELL_FACH state is introduced in 3GPP Release 8.
This feature enables UEs in idle mode or the CELL_FACH state to use the E-DPDCH for data
transmission at higher rates. Higher rates are achieved because the RACH is mapped onto the
E-DPCH instead of the physical random access channel (PRACH). In contrast to the PRACH,
which provides 20 ms TTI and 8 kbit/s, the E-DPCH provides 2 ms or 10 ms TTI. This feature
can increase the maximum transmission rate, theoretically, to 5.76 Mbit/s.
In addition, this feature uses the E-AI (Extended AI) to support more signature sequences. As
a result, the probability that UEs compete for uplink transmission resources is lower, and the
user experience is improved.
Enhancement
None
Dependency
Dependency on RNC hardware
None
Dependency on NodeB hardware
The BTS3812E, BTS3812A, and BTS3812AE need to be configured with the EULPd,
EBBI, EBOI, or EULP board. The downlink services cannot be setup on
HBBI/HDLP/NDLP board.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 105 of 174
The BBU3806 must be configured with the EBBC/EBBCd board. To support the E-AI,
the BBU3806 must be configured with the EBBCd board.
The BBU3900 must be configured with the WBBPb/WBBPd board. To support the E-AI,
the BBU3900 must be configured with the WBBPd board.
Dependency on other RAN features
WRFD-010652 SRB over HSDPA
WRFD-010636 SRB over HSUPA
WRFD-010695 UL Layer 2 Improvement
WRFD-010688 Downlink Enhanced CELL_FACH
Dependency on other NEs
The UE must be Release-8 (or later) UE and support uplink for CELL_FACH enhancement
state.
2.6.6 WRFD-010702 Enhanced DRX
Availability
This feature is available from RAN13.0.
Summary
The enhanced discontinuous reception (DRX) feature enables UEs in the enhanced
CELL_FACH state to receive the high-speed downlink shared channel (HS-DSCH)
discontinuously. This feature helps UEs that process a small amount of services to save power,
by changing the state of such UEs to the enhanced CELL_FACH state.
Benefits
In the enhanced CELL_FACH state, a UE that discontinuously receives the HS-DSCH
consumes less power than a UE that continuously detects the HS-SCCH and continuously
receives the HS-DSCH.
Description
Continuous connectivity (CPC) for packet data users is introduced in 3GPP Release 7. CPC
incorporates the DRX technique that helps HSPA UEs in the CELL_DCH state save power.
Enhanced DRX is introduced in 3GPP Release 8 to further save UE power when the UE is in
enhanced CELL_FACH state. After this feature is enabled, the RAN and UEs in the enhanced
CELL_FACH state transmit and receive data at a specified time. The UE detects the
HS-SCCH at regular intervals instead of detecting the HS-SCCH continuously. When there is
no data to transmit, the UE shuts down the receiver. As a result, the power consumption of the
UE decreases.
If enhanced DRX is enabled and the RAN has data to transmit to the UE, the data is transmitted only at user-specified times, which leads to a slight increase in transmission delay.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 106 of 174
Enhancement
None
Dependency
Dependency on RNC hardware
None
Dependency on NodeB hardware
The BTS3812E, BTS3812A, and BTS3812AE need to be configured with the EULPd,
EBBI, EBOI, or EULP board.
The BBU3806 needs to be configured with the EBBC or EBBCd board. The BBU3806C
needs to be configured with the EBBM board.
The BBU3900 needs to be configured with the WBBPb or WBBPd board.
Dependency on other RAN features
WRFD-010688 Enhanced CELL_FACH
Dependency on other NEs
The UE must be Release-8 (or later) UE and support enhanced Enhanced DRX.
HSPA+ Downlink 42Mbit/s per User
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 107 of 174
3 Topology & Transmission
3.1 RAN Sharing
3.1.1 WRFD-021311 MOCN Introduction Package
Availability
This feature is available from RAN11.0.
Summary
With this feature, multiple operators can share a cell. This feature applies to the scenarios
wherein multiple operators share a carrier or further sharing is required.
Benefits
MOCN enables the operators to save Capital Expenditure (CAPEX) and Operation
Expenditure (OPEX), especially in areas where a single carrier is sufficient to support
subscribers from different operators. For operators involved in the fierce competition of the
telecom industry, MOCN can help them to achieve capital gains as well as corporate
soundness and competitiveness.
Compared with other sharing modes that use independent carriers, MOCN can share carrier
resources and better utilize resources.
Description
MOCN, introduced in the 3GPP R6 protocols, is known as one of the access network sharing
modes. In addition to access nodes such as RNC and Node B, MOCN also shares the carriers.
The network architecture of MOCN is shown below:
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 108 of 174
Different from RAN Sharing that uses independent carriers, MOCN uses common carrier
resources. Similar to RAN Sharing, the Core Network (CN) in MOCN is independent, that is,
the CN nodes belong to different operators. When multiple operators share common carrier
resources, the users of these operators have cell resources in common. In this respect,
compared with RAN Sharing, MOCN can better utilize resources.
Huawei does not offer the MOCN solution with RAN Sharing solution together.
In MOCN solution, all the software features cannot be controlled separately by different
operators. Thus one optional feature needs be bought by all the customers before it is
available.
MOCN introduction package has the following features:
Common carriers shared by operators
Dedicated Node B or cell for operators
MOCN mobility management
MOCN load balancing
MOCN independent performance management
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
The UE should support the MOCN function.
Dependency on Other Network Units
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 109 of 174
Dependency on CN
The CN should support the MOCN function.
Dependency on Other Features
Cannot work with WRFD-021304 RAN Sharing Introduction Package at the same time.
3.1.2 WRFD-02131101 Carrier Sharing by Operators
Availability
This feature is available from RAN11.0.
Summary
With this feature, multiple operators can share a carrier.
Benefits
MOCN enables the operators to save Capital Expenditure (CAPEX) and Operation
Expenditure (OPEX), especially in areas where a single carrier is sufficient to support
subscribers from both operators. For operators involved in the fierce competition of the
telecom industry, MOCN can help them to achieve capital gains as well as corporate
soundness and competitiveness.
Compared with the sharing mode that uses independent carriers, MOCN can share carrier
resources and better utilize resources.
Description
MOCN uses common carrier resources and enables multiple operators to share the RAN
equipment and the same carriers. One cell can belong to and serve different operators.
The basic functions of MOCN are as follows:
System information broadcast
The RNC broadcasts the PLMN IDs of multiple operators in the Master Information
Block (MIB) to send the UE the information about these operators. Based on the
information, the UE performs PLMN selection.
Network selection
MOCN network sharing specifies the following two types of UE:
− Supporting UE: refers to the UE that supports network sharing.
In MOCN network sharing, the RNC broadcasts the PLMN information of multiple
operators through the Multiple-PLMN list IE in the MIB. The supporting UE can
analyze the PLMN information and inform the RNC of the selected PLMN through
the initial direct transfer message. The supporting UE should support the 3GPP R6
protocols.
− Non-supporting UE: refers to the UE that does not support network sharing.
The non-supporting UE cannot analyze the PLMN information of operators from the
system information.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 110 of 174
The RNC adopts different methods to select suitable operators for the two types of UEs.
The supporting UE selects a suitable PLMN ID from the PLMN IDs of multiple operators as
broadcast in the MIB, and reports the selected PLMN ID to the RNC through the initial direct
transfer message. Accordingly, the RNC selects a suitable CN node for the UE based on the
PLMN ID of the UE. If the operator enables the Iu Flex function, the RNC selects one of the
CN nodes based on the NAS Node Selection Function (NNSF).
The non-supporting UE does not report PLMN ID to the RNC through the initial direct
transfer message. The RNC selects a CN node for the UE through the redirection function.
PS/CS consistency
The CS/PS consistency is achieved by coordinating the RNC and the CN. It prevents the
RNC from selecting two CN operators (for CS domain and PS domain respectively) for
the UE. For a network with the Gs interface, the CS registration is forwarded from the
PS domain; therefore, the SGSN is responsible for ensuring the CS/PS consistency. For a
network without the Gs interface, the RNC ensures the CS/PS consistency.
In addition, to facilitate the implementation of MOCN, some UEs that support 3GPP R5
rather than 3GPP R6 may realize the MOCN-associated features of Release 6. The RNC
supports these pre-R6 UEs which implement MOCN independently.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-021311 MOCN Introduction Package
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 111 of 174
3.2 Topology Enhancement
3.2.1 WRFD-021200 HCS (Hierarchical Cell Structure)
Availability
This feature is available from RAN5.0.
This feature is introduced in 3GPP R99.
Summary
This feature complies with the hierarchical cell structure (HCS) as stipulated in 3GPP
specifications. It enables the UE to be handed over to the relevant hierarchical cell according
to its moving speed.
Benefits Improve the conversation quality for fast-moving UEs.
Improve the system capacity.
Reduce the signaling load by decreasing the unnecessary handover.
Description
In 3G networks, the so-called hot spots in radio communications may appear with the increase
of subscribers and traffic. This requires more cells to expand the network capacity. More cells
and smaller cell radius indicate that more frequent handovers of UEs take place. For a UE at a
fast speed, frequent handovers reduce call quality, increase uplink interference, and increase
signaling load.
In this situation, Hierarchical Cell Structure (HCS) is required to divide cells into different
hierarchies and up to 8 hierarchies are supported.
Cell Type Characteristics
Macro Cell Large coverage
Continuous coverage networking
Low requirement on capacity
Fast-moving environment
Micro Cell Densely populated areas
High requirement on capacity
Slow-moving environment
Pico Cell Indoor coverage
Outdoor dead-area coverage
Where, the Pico cell has the highest priority and the macro cell has the lowest priority.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 112 of 174
Speed Estimation
The speed estimation on each hierarchy of an HCS cell falls into one of the following
types:
− Fast speed
− Normal speed
− Slow speed
According to the number of changes of the best cell within time unit, speed estimation
algorithm estimates the moving speed of the UEs. See details as follows:
− If the number of changes of best cell for a UE is above the fast-speed threshold, this
UE is decided in fast speed;
− If the number of changes of best cell for a UE is below the slow-speed threshold, this
UE is decided in slow speed;
− If the number of changes of best cell for a UE is between fast-speed threshold and
slow-speed threshold, this UE is decided in normal speed.
HCS Handover Based on Speed Estimation
After the moving speed of the UE is estimated, inter-hierarchy handover algorithm
initiates the corresponding handover based on this speed decision.
According to the results of speed estimation,
− The UE in fast speed is handed over to the cell of lower priority.
− The UE in slow speed is handed over to the cell of higher priority.
− The UE in normal speed is not required to be handed over to any cell.
According to speed estimation, the RNC orders the fast-moving UE to handover to the cells of
lower priority to reduce the number of handovers, and orders the slow-moving UEs to
handover to the cells of higher priority to increase network capacity.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 113 of 174
Dependency on Other Features
NA
3.2.2 WRFD-020111 One Tunnel
Availability
This feature is available from RAN10.0.
This feature is introduced in 3GPP R7.
Summary
With this feature, there is only one tunnel between the RNC and GGSN.
Benefits
This feature improves efficiency for PS traffic. It avoids SGSN to be the bottle neck of the
network while high PS traffic occurs.
Description
The specification of One-Tunnel (direct connection between RNC and GGSN) is a part of
3GPP Release 7.
In 3G packet core architecture the SGSN (Serving GPRS Support Node) which is the gateway
between the radio network and the core network handles both signaling traffic (e.g. to keep
track of a users location) and the actual data packets exchanged between the user and the
Internet. Since the users' location can change at any time, data packets are tunneled
(encapsulated) from the gateway to the Internet (The Gateway GPRS Support Node, GGSN)
via the SGSN over the radio network to the mobile device. The current architecture uses a
tunnel between the GGSN and the SGSN and another one between the SGSN and the Radio
Network Controller (RNC). All data packets thus have to pass the SGSN which has to
terminate one tunnel extract the packet and put it into another tunnel. This requires both time
and processing power.
Since both the RNC and the GGSN are IP routers this process is not necessary in most
circumstances. With one tunnel approach the SGSN can create a direct tunnel between the
RNC and the GGSN and thus remove itself from the chain. Mobility Management remains on
the SGSN, however, which means for example that it continues to be responsible to modify
the tunnel in case the mobile device is moved to an area served by another RNC.
Enhancement
None.
Dependency
Dependency on RNC
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 114 of 174
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
Require GGSN and SGSN support such feature at the same time.
Dependency on Other Features
NA
3.3 ATM Transimission
3.3.1 WRFD-050302 Fractional ATM Function on Iub Interface
Availability
This feature was first available from RAN2.0.
Summary
This feature enables ATM cells to be transmitted on some timeslots of the E1/T1 bearer and
other data to be transmitted on other timeslots. It applies to the scenario where 2G and 3G
data is transmitted simultaneously.
Benefits
ATM on Fractional supports:
Sharing of transmission links between 2G and 3G systems.
Reduced time in market at initial rollout.
Savings of transmission costs when co-site 2G and 3G
Description
The Fractional ATM mode is an ATM transport mode in the TC sub layer of ATM physical
layer.
In fractional ATM, ATM cells are transmitted by using some of the 32 E1 timeslots. ATM cells
are mapped to some of the E1 timeslots, instead of all of the timeslots. At the peer end, the
ATM cell stream is recovered from these E1 timeslots. The timeslots that are unavailable for
ATM cell transmission can transmit other information.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 115 of 174
The E1/T1 boards can be configured using a fraction of a full E1/T1. For example, the GSM
system can share the transport links with the WCDMA system. This feature is both used for
small sites where one 2G BTS and one WCDMA BTS can share one link and when for
example 0.5 links are needed for the WCDMA BTS and there is 0.5 link free capacity for the
2G BTS. This will in many cases save the cost for installation of one link.
Enhancement
None.
Dependency
Dependency on RNC
The AEUa/AOUc of the RNC supports Fractional ATM.
Dependency on Node B
BTS3902E can‟t support this feature.
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 116 of 174
3.4 IP Transmission
3.4.1 WRFD-050402 IP Transmission Introduction on Iub Interface
Availability
This feature is available from RAN5.1.
This feature is introduced in 3GPP R5.
Summary
This feature enables the Iub interface to be carried on the IP network.
Benefits
This feature provides a new Iub transport solution for operator. With IP transmission,
transport cost will decrease greatly with HSDPA/HSUPA service compared with ATM
transport cost.
Description
Huawei RNC provides the following physical port types on Iub IP transmission solution to
support different networking requirements:
E1/T1
FE
GE (with LAN Switch in BSC6800)
STM-1/OC-3c(POS (Packet Over SDH), BSC6900 only)
Channelized STM-1/OC-3(CPOS (Channelized POS), BSC6900 only)
Huawei Node B provides the following physical port types on Iub IP transmission solution to
support different networking requirements:
E1/T1
Electrical FE
Optical FE ( 3900 Node B only )
Electrical GE ( 3900 Node B only )
Optical GE ( 3900 Node B only )
The following features are also included:
Compliant with 3GPP R5 TR25.933
Support GE/FE/E1/T1/channelized STM-1/channelized OC-3/STM-1/OC-3c physical
interface
Support Diffserv mechanism and IEEE802.1P
Support IPV4
Support IP head compression
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 117 of 174
Support ML-PPP and MC-PPP, RAN11.0 Node B support ML-PPP combined two
transmission card
Support DHCP, PPP Mux and VLAN
Support 1+1 and 1:1 MSP
The following figure shows the IP networking on Iub interface.
Besides the transport layer change (e.g. M3UA, SCTP), the Iub IP brings about some changes
in CAC as well as service differentiation.
In CAC, IP PATH is defined as the connection between RNC and Node B. Each IP PATH is
configured with a maximum DL PATH bandwidth and maximum UL PATH bandwidth, which
is configurable for operators. When a new call is coming, RNC will compare the required
service bandwidth with the available IP PATH bandwidth for UL and DL. If the IP PATH
bandwidth available for use is insufficient, the call is rejected. If the call is admitted, RNC
will reserve the bandwidth and mark it as being used.
The Iub IP adopts the DiffServ for QoS differentiation, similar to the differentiated ATM PVC.
PHB is defined according to the traffic type, each PHB having a DSCP (DiffServ Code Point) and priority.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 118 of 174
BEPS Background
AF1PS Interactive
AF3PS Streaming
AF4PS Conversational
EFCS
EFSRB
EFCommon Channels
PHB(Per Hop Behavior)Traffic Type
BEPS Background
AF1PS Interactive
AF3PS Streaming
AF4PS Conversational
EFCS
EFSRB
EFCommon Channels
PHB(Per Hop Behavior)Traffic Type
6B'000000BE
5B'001010AF1
4B'010010AF2
3B'011110AF3
2B'100110AF4
1B'101110EF
Prior Queue #DSCPPHB
6B'000000BE
5B'001010AF1
4B'010010AF2
3B'011110AF3
2B'100110AF4
1B'101110EF
Prior Queue #DSCPPHB
Enhancement
In RAN10.0, the BSC6810 supports the POS/CPOS interface (UOIa and POUa).
RAN10.0, when the gateway or peer entity is faulty, this feature enables the RNC to detect the
link fault and then trigger IP re-route or board switch, thus avoiding packet loss and call drop.
RAN11.0 Node B support ML-PPP combined two transmission card.
RAN13.0 Iub support RNC and Node B integrated firewall
RNC integrated firewall include the following fuctions:
The internal firewall inspects the incoming IP data over the OM interface and provides the
following functions:
IP address filter. This technique allows only the IP data from authorized IP addresses and
network segments.
Safeguard against attacks of ICMP ping, IP fragments, low TTL, smurf, and DDos.
Safeguard against attacks of TCP sequence prediction, and SYN flood.
The internal firewall inspects the incoming IP data over the Iub, Iur, and Iu interfaces and
provides the following functions:
Intelligent white-listing: With this function, only data from permissible peer IP addresses and
ports and data of permissible protocol types can access the RNC.
Safeguard against ARP and ICMP flood
Safeguard against malformed packets
Limiting speed of the broadcast messages
NodeB integrated firewall include the following fuctions:
The internal firewall inspects incoming all the IP data including maintenance data, control
plane data and user plane data and provides the following functions:
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 119 of 174
White-listing: With this function, only data from permissible peer IP addresses and ports
and data of permissible protocol types can access the NodeB. Ping denial function will
be supported; NodeB will drop the ICMP packets in this mode.
Maintenance data, control plane data and user plane data of 3900 series NodeB and
Maintenance data and control plane data of BTS3812E/AE and DBS3800 will filter by
White-listing function.
Safeguard against Address Resolution Protocol (ARP) and Internet Control Message
Protocol (ICMP) flood
Broadcast-message speed limiting
Dependency
Dependency on RNC
IP head compression is supported by PEUa/POUa/POUc board.
Only the Dopra Linux operating system supports the RNC integrated firewall for the OM
interface.
Only the FG2c and GOUc boards support the RNC integrated firewall for the Iub, Iur,
and Iu interfaces.
To support BFD, the FG2a/GOUa/FG2c/GOUc are needed for BSC6900.
Dependency on Node B
NUTI board is needed with BTS3812E/AE to support this feature.
Only the 3900 series Node B supports inter-board ML-PPP.
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
3.4.2 WRFD-050411 Fractional IP Function on Iub Interface
Availability
This feature was available from RAN6.1.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 120 of 174
Summary
This feature enables IP packets to be transmitted on some timeslots of the E1/T1 bearer and
other data to be transmitted on other timeslots. This feature mainly applies to the scenario
where the 2G Abis interface shares the 3G transport network.
Benefits Sharing of transmission links between 2G and 3G systems.
Reduced initial rollout Time in market at.
Savings on transmission costs when co-site 2G and 3G
Description
In fractional IP, IP packages are transmitted using some of the 32 E1 timeslots. IP packages
are mapped to some of the E1 timeslots, instead of all of the timeslots. At the peer end, the IP
package is recovered from these E1 timeslots. The timeslots that don‟t use for IP package
transmission can transmit other information.
The E1/T1 boards can be configured for using a fraction of a full E1/T1. This is for instance
useful when a 2G system, like GSM, shall share the transport links with the WCDMA system.
This feature is both used for small sites where one 2G BTS and one WCDMA BTS can share
one link and when for example 0.5 links are needed for the WCDMA BTS and there is 0.5
link free capacity for the 2G BTS. This will in many cases save the cost for installation of one
link.
Enhancement
None.
Dependency
Dependency on RNC
PEUa/POUa/POUc board in BSC6900 support the feature.
Dependency on Node B
BTS3902E can‟t support this feature.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 121 of 174
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-050402 IP Transmission Introduction on Iub Interface
3.4.3 WRFD-050409 IP Transmission Introduction on Iu Interface
Availability
This feature is available from RAN6.1.
This feature is introduced in 3GPP R5.
Summary
This feature enables the Iu interface to be carried on the IP network.
Benefits
This feature provides a new Iu transport solution for operator. With IP transmission, transport
cost will decrease greatly compared with ATM transport cost.
Description
This feature provides Iu over IP transport solution including the following features:
Compliance with 3GPP R5 TR25.933
Support IP over FE electrical interface
Support IP over GE electrical interface and GE optical interface
Support IP over STM-1/OC-3c optical interface (POS (Packet Over SDH)) (BSC6900
only)
Support IP over channelized STM-1/OC-3 optical interface(CPOS (Channelized POS))
(BSC6900 only)
Support IuCS over IP over E1/T1 physical interface (BSC6900 only)
Support Diffserv mechanism and IEEE802.1P
Support IPV4
Support IP head compression
Support ML-PPP and MC-PPP
Support PPP Mux and VLAN
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 122 of 174
Support FE/GE 1+1 backup redundancy
Support FE/GE load share redundancy
Support STM-1/OC-3c 1+1 and 1:1 MSP
Support channelized STM-1/OC-3 1+1 and 1:1 MSP
IP networking solution can be L1, L2, L3 networking on Iu interface similar to that on Iub
interface.
Besides the transport layer change, Iu IP brings some changes in CAC as well as service
differentiation
In CAC, IP PATH is defined as the connection between RNC and CN. Each IP PATH is
configured with a maximum DL PATH bandwidth and maximum UL PATH bandwidth, which
is configurable by operator. When a new call is coming, RNC will compare the required
service bandwidth with the available IP PATH bandwidth for UL and DL. If available IP
PATH bandwidth is insufficient, the call is rejected. If the call is admitted, RNC will reserve
the bandwidth and mark it as being used.
Enhancement
In RAN10.0, the BSC6810 supports the POS/CPOS interface (UOIa and POUa).
In RAN10.0, when the gateway or peer entity is faulty, this feature enables the RNC to detect
the link fault and then trigger IP re-route or board switch, thus avoiding packet loss and call
drop.
In RAN13.0, RNC integrated firewall was supported, which include the following functions:
The internal firewall inspects the incoming IP data over the OM interface and provides the
following functions:
IP address filter. This technique allows only the IP data from authorized IP addresses and
network segments.
Safeguard against attacks of ICMP ping, IP fragments, low TTL, smurf, and DDos.
Safeguard against attacks of TCP sequence prediction, and SYN flood.
The internal firewall inspects the incoming IP data over the Iub, Iur, and Iu interfaces and
provides the following functions:
Intelligent white-listing: With this function, only data from permissible peer IP addresses and
ports and data of permissible protocol types can access the RNC.
Safeguard against ARP and ICMP flood
Safeguard against malformed packets
Limiting speed of the broadcast messages
Dependency
Dependency on RNC
Only the Dopra Linux operating system supports the RNC integrated firewall for the OM
interface.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 123 of 174
Only the FG2c and GOUc boards support the RNC integrated firewall for the Iub, Iur,
and Iu interfaces.
To support BFD, the FG2a/GOUa/FG2c/GOUc are needed for BSC6900.
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
CN should support IP transportation.
Dependency on Other Features
NA
3.4.4 WRFD-050410 IP Transmission Introduction on Iur Interface
Availability
This feature is available from RAN6.1.
This feature is introduced in 3GPP R5.
Summary
This feature enables the Iur interface to be carried on the IP network.
Benefits
This feature provides a new Iur transport solution for operator. With IP transmission, transport
cost will decrease greatly compared with ATM transport cost.
Description
This feature provides Iur over IP transport solution including the following features:
Compliant with 3GPP R5 TR25.933
Support GE/FE/E1/T1 physical interface
Support IP over FE electrical interface
Support IP over GE electrical interface and GE optical interface (BSC6900 only)
Support IP over STM-1/OC-3c optical interface (POS (Packet Over SDH)) (BSC6900
only)
Support IP over channelized STM-1/OC-3 optical interface(CPOS (Channelized POS))
(BSC6900 only)
Support IP over E1/T1 physical interface (BSC6900 only)
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 124 of 174
Support Diffserv mechanism and IEEE802.1P
Support IPV4
Support IP head compression
Support ML-PPP and MC-PPP
Support DHCP, PPP Mux and VLAN
Support FE/GE 1+1 backup redundancy
Support FE/GE load share redundancy
Support STM-1/OC-3c 1+1 and 1:1 MSP
Support channelized STM-1/OC-3 1+1 and 1:1 MSP
IP networking solution can be L1, L2, L3 networking on Iur interface similar to that on Iub
interface.
Besides the transport layer change, Iur IP brings some changes in CAC as well as service
differentiation.
In CAC, IP PATH is defined as the connection between SRNC and DRNC. Each IP PATH is
configured with a maximum DL PATH bandwidth and maximum UL PATH bandwidth, which
is configurable by operator. When a new call is coming, RNC will compare the required
service bandwidth with the available IP PATH bandwidth for UL and DL. The call will be
rejected if no enough IP PATH bandwidth is available. After the call is admitted, RNC will
reserve bandwidth as in use.
The Iub IP adopts the DiffServ for QoS differentiation, similar to the differentiated ATM PVC.
PHB is defined according to the traffic type, each PHB having a DSCP (DiffServ Code Point)
and priority.
Enhancement
In RAN10.0, packet over STM-1/OC-3c is supported.
In RAN10.0, packet over channelized STM-1/OC-3 is supported.
In RAN10.0, when the gateway or peer entity is faulty, this feature enables the RNC to detect
the link fault and then trigger IP re-route or board switch, thus avoiding packet loss and call
drop.
In RAN13.0, RNC integrated firewall is supported, which include the following functions:
The internal firewall inspects the incoming IP data over the OM interface and provides the
following functions:
IP address filter. This technique allows only the IP data from authorized IP addresses and
network segments.
Safeguard against attacks of ICMP ping, IP fragments, low TTL, smurf, and DDos.
Safeguard against attacks of TCP sequence prediction, and SYN flood.
The internal firewall inspects the incoming IP data over the Iub, Iur, and Iu interfaces and
provides the following functions:
Intelligent white-listing: With this function, only data from permissible peer IP addresses and
ports and data of permissible protocol types can access the RNC.
Safeguard against ARP and ICMP flood
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 125 of 174
Safeguard against malformed packets
Limiting speed of the broadcast messages
Dependency
Dependency on RNC
Only the Dopra Linux operating system supports the RNC integrated firewall for the OM
interface.
Only the FG2c and GOUc boards support the RNC integrated firewall for the Iub, Iur,
and Iu interfaces.
To support BFD, the FG2a/GOUa/FG2c/GOUc are needed for BSC6900.
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
The neighbouring RNC should also support IP transportation.
Dependency on CN
NA
Dependency on Other Features
NA
3.4.5 WRFD-011500 PDCP Header Compression (RFC2507)
Availability
This feature is available from RAN2.0.
This feature is introduced in 3GPP R99.
Summary
This feature complies with the header compression function of packet data as defined in RFC
2507. It enables the deletion of redundant information such as TCP/IP header. The system
compresses the redundant protocol header before the data is transmitted on a link. In addition,
the system can decompress the received data.
Benefits
This feature can decrease the throughput of the Uu interface and improve the efficiency of
radio links.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 126 of 174
Description
For TCP packets in telecommunications, many fields are constant and others change with
small and predictable values. Depending on whether the fields remain constant or change in
specific patterns, some fields can be either excluded from each packet or represented in a
smaller number of bits. This is described as header compression. Header compression uses the
concept of packet stream context. A context is a set of data about field values and value
change patterns in the packet header. For each packet stream, the context is formed at the
compressor and the de-compressor. After the context is established on both sides, the
compressor can compress the packets.
For packet data, TCP/IP header always takes up too many bytes in the whole packet. By
compressing the header of the TCP/IP contexts, the radio link efficiency can be greatly
improved. Meanwhile, small packet data due to header compressed can shorten the data
latency as well as the RTT.
The algorithm for header compression includes:
Compressible Chain of Sub-header Judgment Algorithm
Packet Stream Judgment Algorithm
Twice Algorithm for TCP Packet Streams
Header Request Algorithm for TCP Packet Streams
Compression Slow-Start Algorithm for Non-TCP Packet Streams
Periodic Header Refresh Algorithm for Non-TCP Packet Streams
Enhancement
In RAN5.0, IP V6 header compression is supported.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should support the compression function.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 127 of 174
3.5 Satellite Transmission
3.5.1 WRFD-050104 Satellite Transmission on Iub Interface
Availability
This feature is available from RAN3.0.
Summary
This feature enables the transmission through satellite links on the Iub interface.
Benefits
This transmission feature is provided to support certain difficult types of geographical
application environments, such as islands, deserts or places where there is a lack of terrestrial
transmission facilities available for the operator. In this case, the operator may propose to use
satellite transmission support for Iub interface connection to the rest of the UMTS network.
Description
This function supports satellite transmission on the Iub interface, which is useful to cover
remote districts, such as an island.
When satellite transmission is applied over the Iub interface, the delay increases and the timer
in SAAL/NBAP/ALCAP should be adjusted to avoid data or link error due to transmission
delay and to meet satellite transmission requirements.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 128 of 174
NA
3.5.2 WRFD-050108 Satellite Transmission on Iu Interface
Availability
This feature is available from RAN11.1.
Summary
This feature allows operator to set up the Iu interface connection with Satellite Transmission.
Benefits
This transmission feature supports certain difficult types of geographical application
environments, such as islands, deserts or places where lack of terrestrial transmission facilities
available for the operator. In this case, the operator may propose to use satellite transmission
support for Iu interface connection to the core network.
Description
Satellite communication is a special form of microwave trunk communication and functions
as the supplementary and standby means of common communication methods. Satellite
communication features wide coverage, little impact by terrains, good mobility performance,
and flexible link scheduling. However, the equipment cost and link rental cost are high, and
the transmission quality is likely to be affected by environments.
The extra loopback delay of satellite transmission is usually 500 ms to 700 ms. Generally, the
delay is about 600 ms. The delay depends on the distance between the Earth station and the
satellite and the satellite technologies.
This function is available for satellite transmission on the Iu interface and can be used to
cover remote areas, such as islands.
When satellite transmission is used on the Iu interface, the transmission delay prolongs. In
addition, the SAAL/UP timers should be adjusted to avoid data error or link failure due to
transmission delay. The related parameters can be set to meet the requirements of satellite
transmission.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 129 of 174
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
3.6 Clock
3.6.1 WRFD-050502 Synchronous Ethernet
Availability
This feature was available from RAN 11.0
Summary
This feature is introduced to provide a solution for clock synchronization in all-IP networking
mode. It enables the clock to be extracted and recovered from the Ethernet physical layer
(PHY). As no additional hardware is required on the Node B and RNC sides, this feature is a
convenient solution for clock synchronization.
Benefits
The synchronous Ethernet technology is one of the key features in the solution for network
over all IP solution. It is an economical, convenient solution.
Description
The synchronous Ethernet technology extracts clock signals from the Ethernet link code flows.
It is a physical layer based clock synchronization technology. A highly precise clock is used
by the Ethernet physical layer (PHY) for data transmission. The receiving end extracts and
recovers the clock from data stream, and the high precision can be maintained. This is the
basic principle of synchronous Ethernet technology.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 130 of 174
In Node B, there is no extra synchronization equipment or hardware needed to realize
synchronous Ethernet technology.
Enhancement
None.
Dependency
Dependency on RNC
Only BSC6900 supports this feature.
Dependency on Node B
It is only applicable in 3900 series Node B.
Dependency on UE
NA
Dependency on Other Network Units
The synchronous Ethernet technology requires that all the equipments on the clock relay path
must support the synchronous Ethernet.
Dependency on CN
NA
Dependency on Other Features
WRFD-050402 IP Transmission Introduction on the Iub Interface
3.6.2 WRFD-050425 Ethernet OAM
Availability
This feature is available from RAN11.0 and is only applicable to the BSC6900.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 131 of 174
Summary
This feature is related to point-to-point and end-to-end Ethernet OAM. It provides an effective
solution for Ethernet link management and fault detection.
Benefits The Ethernet OAM helps the operator to manage user access in terms of detection,
monitoring, and rectification of Ethernet faults.
This feature achieves reliability and high availability of Ethernet services, enables the
service provider to provide economical and efficient advanced Ethernet services, and
ensures that the services have high quality and reliability that are required by
telecommunications services.
This feature is implemented at the RAN equipment, thus minimizing the impact of
Ethernet bandwidth fluctuation or faults on RAN.
Description
With the introduction of IP RAN to the WCDMA system, the Ethernet as a type of transport
bearer is widely applied. As a L2 protocol, Ethernet OAM can report the status of the network
at the data link layer, thus monitoring and managing the network more effectively.
The functions of Ethernet OAM consist of fault detection, notification, verification and
identification. The faults involve the hard faults that can be detected by the physical layer,
such as broken links, and the soft faults that cannot be detected by the physical layer, such as
memory bridging unit damage. Ethernet OAM plays a significant role in reducing
CAPEX/OPEX and complying with the Service Level Agreement (SLA).
RAN supports two types of Ethernet OAM: point-to-point Ethernet OAM (802.3ah) and
end-to-end Ethernet OAM (802.1ag). The two types are described as follows:
Point-to-point Ethernet OAM
The point-to-point Ethernet OAM complies with IEEE 802.3ah. What the point-to-point
Ethernet OAM takes into consideration is the last mile, rather than the specific services.
The OAM implements point-to-point maintenance of the Ethernet through mechanisms
such as OAM discovery, loopback, link monitoring, and fault detection.
End-to-end Ethernet OAM
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 132 of 174
The end-to-end Ethernet OAM complies with IEEE 802.7ag. With regard to the OAM
domain as a whole, it establishes end-to-end detection to perform maintenance of the
Ethernet based on the services.
Enhancement
RAN12.0 the end-to-end Ethernet OAM complies with IEEE 802.8ag.
Dependency
Dependency on RNC
Only BSC6900 supports this feature.
Dependency on Node B
RAN11.0, BTS3812E/AE and DBS3800 can only support IEEE 802.1ag draft 7; 3900
series NodeB can support IEEE 802.3ah and IEEE 802.1ag draft 7.
RAN12.0, BTS3812E/AE, DBS3800, 3900 series NodeB can support both IEEE 802.3ah
and IEEE 802.1ag draft 8.
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-050402 IP Transmission Introduction on the Iub Interface, or
WRFD-050409 IP Transmission Introduction on the Iu Interface, or
WRFD-050410 IP Transmission Introduction on the Iur Interface
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 133 of 174
4 Network Security
4.1 Reliability
4.1.1 WRFD-021302 Iu Flex
Availability
This feature is available from RAN3.0.
This feature is introduced in 3GPP R5.
Summary
This feature allows one physical RNC to be connected to multiple MSCs and/or SGSNs, and
these CS/PS domain nodes can form different pools that serve the same pool area.
Benefits
Iu Flex greatly enhances the serviceability of the whole network including:
Enhancing the flexibility of the Iu interface
Increasing the total capacity of CN nodes
Enhancing the disaster tolerance capability of CN nodes
Reducing the signaling traffic of the CN
Enhancing the system utilization
In conclusion, the Iu Flex greatly enhances the serviceability of the whole network.
Description
This 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:
A pool area is a collection of one or more MSC or SGSN serving areas.
A pool area is served by one or more CN nodes in parallel that share the traffic of this
area between each other.
The pool areas may overlap. The RAN Node belongs to all the overlapping pool areas.
In one pool area, the UE roams without needing to change the serving CN node.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 134 of 174
The pool areas of the CS domain and of the PS domain are configured independently.
Therefore, the pool area enhances the flexibility of the Iu interface, and the typical structure of
Iu Flex is shown as the figure below.
Area 1
RAN
node
Area 5
RAN
node
Area 6
RAN
node
Area 7
RAN
node
Area 8
RAN
node
Area 2
RAN
node
Area 3
RAN
node
Area 4
RAN
node
PS pool-area 2PS pool-area 1
CS pool-
area 2CS pool-
area 1
MSC 3MSC 2
MSC 1
MSC 6MSC 5
MSC 4
SGSN 6
SGSN 2
SGSN 1
SGSN 5
SGSN 4
SGSN 3
MSC 7
The Network Resource Identity (NRI) identifies uniquely an individual CN node that serves a
pool area. Each CN node that supports the Iu Flex is configured with one or more specific
NRIs.
The CN node allocates the route information to the UE. If the CN node supports the Iu Flex,
the TMSI (or P-TMSI) allocated by the node contains the NRI. Then UE encodes the route
information which consists of 10 bits according to the TMSI (or P-TMSI), and sends the
parameter to the RNC through the INITIAL DIRECT TRANSFER message. Such a message
contains an IE ”Intra Domain NAS Node Selection (IDNNS)” which consists of not only the
route parameter but also an indication about from which identity (TMSI/PTMSI, IMSI, IMEI)
the route parameter is derived. Then RNC will use NAS Node Selection Function (NNSF) to
select the proper CN node (MSC or SGSN) for the UE. That is, if the NNSF finds the CN
node that the NRI derived from the initial NAS signaling message identifies, it routes the
message or frame to that CN node. Otherwise, the NNSF selects an available CN node
according to the signaling load balancing.
The UE encodes the route information according to the following rules:
The UE preferentially encodes the route information identified by the TMSI or P-TMSI.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 135 of 174
If the TMSI or P-TMSI is unavailable and the UE contains the USIM or SIM card, the
UE encodes the route information identified by the IMSI.
If the TMSI or P-TMSI is unavailable and the UE does not contain the USIM or SIM
card, the UE encodes the route information identified by the IMEI.
Accordingly, RNC selects the route based on the route parameter in the IDNNS of the
INITIAL DIRECT TRANSFER message as follows:
When the route parameter is derived from the TMSI or P-TMSI
The RNC derives the NRI from the parameter according to the configured length of the
NRI. Then the RNC selects the CN node according to the configured corresponding
relationship between the NRI and the CN node. If no NRI is configured to the CN node,
the RNC selects a CN Node based on the load balancing.
When the route parameter is derived from the IMSI
The parameter is an integer within the range from 0 through 999. The value can be
derived by (IMSI/10) MOD 1000. When route parameter is derived from the IMSI, it
should be indicated by the “IDNNS” IE that the current call attempt is an originating or
terminating call (response to paging).
For originating call, RNC would select the CN node according to either the IMSI V
value (the corresponding relationship between the IMSI V value and the CN node should
be preconfigured) or load balancing.
For terminating call, RNC should attempt to get the previously stored IMSI and Global
CN-Id. If succeeded, the CN node identified by the found Global CN-Id will be selected.
Otherwise, CN node will be selected as originating call.
When the route parameter is derived from the IMEI
The RNC selects the CN Node based on load balancing.
CS domain IMSI Paging handling
To increase the success rate of routing the paging response message to the CN node that
issues the paging request, the Iu-Flex-capable RNC needs to process the IMSI paging
message as follows:
In R5 protocols, an optional IE “Global CN-ID” is added to the RANAP PAGING message. If
RNC provides the Iu Flex feature and the paging message contains only the IMSI rather than
the TMSI, the paging message must contain Global CN-ID.
The NNSF in the RNC temporarily stores the IMSI and Global CN-ID upon reception of the
paging message. When the NNSF receives the INITIAL DIRECT TRANSFER message (a
paging response with an IMSI), it directly forwards the paging response to the CN node
identified by the Global CN-ID.
If the CN node is set to Mode 1 which indicates the Gs interface existing, the paging message
of the CS domain might be delivered on the Iu-PS interface. In this case, the SGSN adds the
Global CN-ID of the CS domain into the paging message.
Load Balancing Criteria
When the mapping between UE and CN node is not found, RNC will select a proper one
based on load balancing. The criteria is to select the lightest load CN node according to the
OVERLOAD indication from Iu interface and when the loads are the same, they will be
selected in turn.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 136 of 174
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.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
Require MSC or SGSN support such feature at the same time.
Dependency on Other Features
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 137 of 174
5 Network Performance
5.1 Coverage Enhancement
5.1.1 WRFD-010203 Transmit Diversity
Availability
This feature is available from RAN2.0.
Summary
TX diversity enables the Node B to provide twice the number of RF DL channels compared
with no TX diversity. This feature can support STTD, TSTD, and CLD1 to effectively
improve the reception performance of the UE. In TX diversity mode, the UE must support
diversity reception.
Benefits
TX diversity can improve terminal performance in special circumstances, especially when
there is less valid multi-path effect and the UE speed is low. In this case, capacity and
coverage can be obviously improved and investment can be reduced while the same QoS is
guaranteed and the CAPEX and OPEX can be cut down by operators.
Description
There are several transmit diversity modes adopted in WCDMA 3GPP, namely the Time
Switched Transmit Diversity (TSTD) mode, Space Time Transmit Diversity (STTD) mode,
and Closed Loop Transmit Diversity Mode1 (CLD1). The TSTD and the STTD are open loop
transmit diversity, which do not need feedback information compared with the closed loop
diversity. The following table summarizes the possible application of open and closed loop
transmit diversity modes on different types of downlink physical channels.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 138 of 174
Physical channel type Open loop mode Closed loop mode
TSTD STTD Mode 1
P-CCPCH – X –
SCH X – –
S-CCPCH – X –
DPCH – X X
PICH – X –
MICH – X –
HS-PDSCH – X X
HS-SCCH – X –
E-AGCH – X –
E-RGCH – X –
E-HICH – X –
AICH – X –
If a cell works in TX diversity mode, the CPICH, PCCPCH, and SCH of the cell must also
work in TX diversity mode.
There are two types of physical channels that can use the Closed Loop Transmit Diversity
Mode1 (CLD1), that is, DPCH and HS-PDSCH. Huawei RAN6.0 supports this feature.
Enhancement
In RAN5.0, after the HSDPA feature is deployed, STTD for HS-PDSCH and HS-SCCH is
supported.
In RAN6.0, after the HSUPA feature is deployed, STTD for E-AGCH, E-RGCH and E-HICH
is supported.
Closed Loop Transmit Diversity Mode1 is a new feature of RAN6.0.
Dependency
Dependency on RNC
NA
Dependency on Node B
TX diversity requires the Node B to provide two times RF channel resources compared with
no TX diversity mode. In TX diversity mode, the UE must support diversity reception, STTD,
TSTD, and CLD1.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 139 of 174
Dependency on UE
The UE must support diversity reception, STTD, TSTD, and CLD1.
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
5.1.2 WRFD-021309 Improved Downlink Coverage
Availability
This feature is available from RAN 6.1.
Summary
This feature supports the deltaqrxlevmin parameter introduced in 3GPP R5. It can extend the
DL coverage of a cell.
Benefits Improves the downlink coverage and UE access capability
Improves the cell capacity by adjustment of PCPICH power in indoor scenario
Improves the access capability in long distance coverage scenario
Reduces the sites number required.
Description
With supporting the parameter deltaqrxlevmin introduced in 3GPP Release5, UE is allowed
to camp on the cell and access the network with CPICH RSCP that is -119 dBm, therefore,
improve the downlink coverage compared to the original -115dBm.
Such parameter deltaqrxlevmin can be configured by operator.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 140 of 174
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
WRFD-021308 Extended Cell Coverage up to 200km
5.1.3 WRFD-020138 HSUPA Coverage Enhancement at UE Power Limitation
Availability
This feature is available from RAN13.0.
Summary
This technique is introduced in 3GPP Release 8 to improve the coverage performance for
HSUPA services on the HSUPA cell edge.
Benefits
This feature improves coverage at the HSUPA cell edge for BE services and voice services.
The emulation results show that the coverage can be increased by about 10%.
Description
This feature improves the HSUPA coverage performance through HSUPA power control
enhancement at UE power limitation introduced in 3GPP Release 8.
When a UE detects that its transmit power is limited, the UE enters power scaling mode. In
this mode, the transmit power on uplink physical channels is reduced proportionately to
improve coverage quality.
In the traditional power-scaling technique, the power offset of E-DPDCH relative to DPCCH
is not the most appropriate value, and therefore scaling mode offers only limited gains. In the
enhanced power scaling technique, the network side provides optimized transport block size
and the power offset of E-DPDCH relative to DPCCH. The UE uses these optimized settings
when its power is limited at the cell edge. In contrast to the traditional power-scaling
technique, the enhanced technique allows for more appropriate transport block size and
E-DPDCH power-offset settings, improving coverage performance at the HSUPA cell edge.
Enhancement
None
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 141 of 174
Dependency
Dependency on RNC hardware
None
Dependency on NodeB hardware
None
Dependency on other RAN features
WRFD-010612 HSUPA Introduction Package
Dependency on other NEs
The UE needs to support 3GPP Release 8 or later. It also needs to support improved EUL
power control at UE power limitation.
5.2 Intra-system Mobility Management
5.2.1 WRFD-020605 SRNS Relocation Introduction Package
Availability
This feature is available from RAN2.0.
This feature is introduced in 3GPP R99.
Summary
This feature provides multiple solutions for user mobility between RNCs. The solutions
include the static relocation solution (with Iur interface), and hard handover/cell update/URA
update relocation solutions (without Iur interface).
Benefits Reduce the bandwidth occupied by the Iur interface.
Reduce the transmission delay of user plane.
Get the parameters of cell-level algorithms to optimize the performances.
Ensure that communications are not interrupted when the UE moves to the coverage area
of another RNC while the Iur interface is not available.
Help to keep the integrity and continuity of the data transfer, and improve the best effort
service performance during the SRNS relocation procedure.
Description
The serving RNS (SRNS) manages the connection between the UE and the UTRAN and can
be relocated.
The SRNS Relocation Introduction Package includes following features:
SRNS Relocation (UE Not Involved)
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 142 of 174
SRNS Relocation with Hard Handover
SRNS Relocation with Cell/URA Update
Lossless SRNS Relocation
Enhancement
In RAN3.0, RAN5.0 SRNS Relocation Introduction Package is enhanced. For details, please
refer to the enhancement of the features in the package.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
The CN and DRNC must support this feature simultaneously.
Dependency on CN
The CN node must support this feature simultaneously.
Dependency on Other Features
NA
5.2.2 WRFD-02060501 SRNS Relocation (UE Not Involved)
Availability
This feature is available from RAN2.0.
Summary
This feature supports the SRNS procedure based on the standard Iu interface defined by 3GPP.
The static relocation procedure does not involve the UE and radio connections are affected
during the relocation. The static relocation is an optimal relocation mode.
Benefits Reduce the bandwidth occupied by the Iur interface
Reduce the transmission delay of user plane
Obtain the parameters of cell-level algorithms to optimize the performances
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 143 of 174
Description
When the Iur interface exists, the UE may use the radio resources of one RNC and connects to
the CN through another RNC.
After the SRNS is relocated (UE not involved), the Iur resources for the UE are released. The
target RNC not only provides radio resources for the UE but also connects the UE to the CN.
If the radio links are provided only by the target RNC, the static relocation for UEs in
CELL_DCH state can be triggered in the following four conditions:
SRNS relocation based on delay optimization
The SRNC calculates the transmission delay on the user plane. If the delay exceeds the
threshold, the SRNC initiates the SRNS relocation.
SRNS relocation based on transmission optimization
The SRNC calculates the bandwidth occupancy on the Iur interface. If the transmission
resource of Iur interface is congested, the SRNC initiates SRNS relocation to reduce the
transmission bandwidth occupation.
SRNS relocation based on separation time
The SRNC initiates SRNS relocation when the SRNC and the CRNC have been
separated for a period of time which exceeds the threshold.
SRNS relocation based on location separation
The SRNC initiates SRNS relocation when the UE moves to an area which is controlled
by the DRNC.
The UE‟s only behavior during the procedure is that it is notified with new UTRAN
MOBILITY INFORMATION.
Enhancement
In RAN3.0, the SRNS relocation based on delay optimization is supported.
In RAN5.0, the SRNS relocation based on separation time and location separation are
supported.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
The CN and DRNC must support this feature simultaneously.
Dependency on CN
The CN node must support this feature simultaneously.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 144 of 174
Dependency on Other Features
NA
5.2.3 WRFD-02060502 SRNS Relocation with Hard Handover
Availability
This feature is available from RAN2.0.
Summary
When the Iur interface is unavailable, this feature enables the UE to move between RNCs.
Benefits
It can ensure communications are not interrupted when the UE moves to the coverage area of
another RNC while the Iur interface is not available.
Description
SRNS relocation with hard handover, which applies to UEs in CELL_DCH state, occurs in
the following conditions:
Inter-frequency or intra-frequency hard handover is performed.
The target cell and the source cell belong to different RNCs.
There is no Iur interface between the two RNCs or there are not enough resources to set
up a connection through the Iur interface.
In such scenarios, the UE is ordered to be relocated to a new RNC with hard handover to
prevent call drop.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
The CN and DRNC must support this feature simultaneously.
Dependency on CN
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 145 of 174
The CN node must support this feature simultaneously.
Dependency on Other Features
NA
5.2.4 WRFD-02060503 SRNS Relocation with Cell/URA Update
Availability
This feature is available from RAN2.0.
Summary
When the Iur interface does not support CCH or Iur-CCH is unavailable, this feature enables
the UE in CELL_FACH, CELL_PCH, or URA_PCH state to move between RNCs.
Benefits
It ensures that communications are not interrupted when the UE in CCH state moves to the
coverage area of another RNC.
Description
If Iur interface support CCH, the cell/URA update does not trigger relocation immediately.
When Iur interface does not support CCH or Iur-CCH is unavailable, the SRNS relocation
with cell update occurs when all the following conditions are met:
The cell update procedure is performed.
The target cell and the source cell belong to different RNCs.
There is Iur interface between two RNCs, but Iur does not support CCH or Iur-CCH is
unavailable.
It is caused by cell reselection of UE in CELL_FACH, CELL_PCH or URA_PCH state. The
message Cell Update or URA Update sent by the UE is forwarded from the new RNC to the
old RNC through the Iur interface, and then the relocation procedure starts.
Enhancement
None
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 146 of 174
Dependency on Other Network Units
The CN and DRNC must support this feature simultaneously.
Dependency on CN
NA
Dependency on Other Features
NA
5.2.5 WRFD-02060504 Lossless SRNS Relocation
Availability
This feature is available from RAN3.0.
Summary
This feature enables the forwarding of SRNS contexts and DL N-PDU duplicates to the target
relocation cell during the relocation. With this feature, the higher layer on the user plane does
not need to resend the data lost during the relocation, thus improving the BE service
performance.
Benefits
This feature helps to keep the data transfer integrity and continuity, and improve the best
effort service performance in the SRNS relocation procedure.
Description
Lossless SRNS relocation is used to forward the context in SRNS and DL N-PDU duplicates
towards the relocation target RNC during the relocation procedure. That is, the RNC supports
the maintenance of PDCP sequence numbers for radio bearers which are used to forward data
not acknowledged by the UE. With this feature, the higher layer in user plane does not need to
resend the data lost during relocation procedure; therefore, the best effort service performance
is improved.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 147 of 174
NA
Dependency on Other Network Units
The UE, CN and DRNC must support this feature simultaneously.
Dependency on CN
NA
Dependency on Other Features
NA
5.3 Intra-system Radio Resource Management
5.3.1 WRFD-010615 Multiple RAB Package (PS RAB ≥2)
Availability
This feature is available from RAN2.0.
This feature is introduced in 3GPP R99.
Summary
This feature is a combination of two or more PS RABs.
Benefits
Multi-RAB support capability provides operators with more choices for the service solution.
Description
Multi-RAB can provide many services simultaneously to the upper layer. When multi-RAB
has more than one PS RAB, Huawei supports the following specifications:
Combination of two PS services
One CS service + two PS services
Combination of three PS services
One CS service + three PS services
Combination of Four PS Services
In all the above combinations, the bit rates of CS and PS services are not limited. That is, any
bit rate defined in WRFD-010501 Conversational QoS Class, WRFD-010502 Streaming QoS
Class, WRFD-010503 Interactive QoS Class, and WRFD-010501 Background QoS Class can
be selected in the combination.
The PS conversational/streaming/interactive/background services can also be mapped onto
HS-DSCH or E-DCH channels, such a feature will be supported with the optional feature
WRFD-010610 HSDPA Introduction Package and WRFD-010612 HSUPA Introduction
Package.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 148 of 174
Enhancement
In RAN6.0, the following specifications can be supported:
Combination of three PS services including IMS signaling
One CS service + three PS services including IMS signaling
In RAN10.0, the limitation that one of 3 PS service must be IMS signaling is removed.
In RAN11.0, the combination of four PS service is supported.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
The UE must have the corresponding multi-RAB support capability.
Dependency on Other Network Units
NA
Dependency on CN
The CN must have the corresponding multi-RAB support capability.
Dependency on Other Features
NA
5.3.2 WRFD-020114 Domain Specific Access Control (DSAC)
Availability
This feature is available from RAN11.0.
Summary
In urgent cases, for example, the CN is overloaded, this feature enables fast reduction of the
load, thus avoiding further overload.
Benefits
In urgent cases, for example, the overload of the CN, the DSAC function can quickly lower
the current load and reduce the risk of overload.
If one CN domain is overloaded or unavailable, the other CN domain is not affected. This
improves the disaster tolerance and availability of the network.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 149 of 174
Description
In the 3GPP protocols, the PRACH resources (such as access slots and access preambles in
FDD mode) provide access services of different priorities by distinguishing different Access
Service Classes (ASCs). The value range of the ASC is 0–7. The value 0 represents the
highest priority and the value 7 represents the lowest priority. The value 0 of ASC is used for
emergency calls. The Information Element (IE) "AC-to-ASC mapping" in SIB 5 or SIB 5bis
indicates the mapping between Access Class (AC) and ASC. This mapping is usually applied
to the access phase, for example, sending an RRC CONNECTION REQUEST message;
therefore, different access services are provided by controlling the access probability of the
UEs which belong to the ASCs of different priorities.
In SIB 3/4, the IE "Domain Specific Access Restriction Parameters" is used to indicate which
access class is barred or allowed. The UE will read its access class and compare it with the
access class stored in the SIM card. After comparison, the UE knows whether it is allowed to
access the cell.
The DSAC function can be used in the following scenarios:
1. When the RNC knows through the Iu interface that the CN is overloaded, it triggers the
DSAC function as follows:
− The RNC sets the step as X% to limit the access of the UE under the RNC at a fixed
interval, namely, "Access Class Restriction interval". Within the next interval, the
RNC limits the other X% UEs and releases all the other UEs.
− The RNC bars the access of UEs according to different domains. That is, the RNC
prevents the UEs from accessing the overloaded CS domain. If the PS domain is
overloaded, the RNC also prevents the UEs from accessing the PS domain.
− If X% = 100%, the RNC bars the access of all the UEs. The UEs camp on the
coverage area under the RNC but cannot access the corresponding domain.
− When the CN is no longer overloaded, all the barred ACs will be released.
− The operators can set X% and Access Class Restriction interval.
− The operator can decide whether to trigger the DSAC function when a domain of the
CN is overloaded.
2. When Iu Flex is used, the DSAC function can be automatically triggered only when all the
CN nodes of the corresponding domain connected to the RNC are overloaded.
3. When the DSAC function is triggered, based on logs and alarms, the operator can easily
monitor the DSAC status, network status, the process of removing restrictions on access
classes, and so on.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 150 of 174
Dependency on UE
Only the UEs of R6(or later) can support this function.
Dependency on Other Network Units
NA
Dependency on CN
CN nodes should support this message on the Iu interface.
Dependency on Other Features
NA
5.3.3 WRFD-020400 DRD Introduction Package
Availability
This feature is available from RAN3.0.
This feature is introduced in 3GPP R99.
Summary
This feature supports inter-frequency or inter-system direct retry and redirect.
Benefits
These features can decrease the access failure rate and improve the QoS of the network.
Description
The DRD Introduction Package includes the following features:
Intra System Direct Retry
Inter System Direct Retry
Inter System Redirect
Traffic Steering and Load Sharing During RAB Setup
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 151 of 174
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
5.3.4 WRFD-021102 Cell Barring
Availability
This feature is available from RAN5.1.
Summary
When a cell is abnormal, this feature enables the operator to automatically or manually bar the
cell.
Benefits When the Iu interface is disconnected, this feature can prevent the UE from initiating
useless access requests and ensure that 3G UEs are handed over to the 2G network.
This feature can provide flexibility for the operator in some scenarios (for example,
maintenance).
Description
It is in SIB 3/4 to indicate whether the cell is barred or not. When cell status "barred" is
indicated, the UE is not permitted to select/re-select this cell, not even for emergency calls.
The cell can be barred or unbarred manually and automatically.
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;
Automatic operation. In cases of Iu breakdown, the RNC keeps providing coverage (but
not service) to the UEs under its control. This means that several UEs are kept in 3G
coverage, but, actually, they cannot access the network. In this case, RNC bars the cell
automatically. If the Iu-CS breaks down, the RNC will bar the Iu-CS domain service for
the cell; if the Iu-PS breaks down, the RNC will bar the Iu-PS domain service for the
cell.
Therefore, UE can perform a re-selection towards the underlying GSM layer; when Iu-CS
recovers, the RNC will unbar the cell.
Enhancement
In RAN 10.0, the RNC can sequentially bar one of the cells under its control every Cell
Barring period . The period length is configurable.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 152 of 174
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
5.4 GSM and UMTS Radio Resource Management
5.4.1 WRFD-020307 Video Telephony Fallback to Speech (AMR) for Inter-RAT HO
Availability
This feature is available from RAN6.0.
This feature is introduced in 3GPP R6.
Summary
Before VP services are handed over to the 2G system, this feature enables the fallback of
video telephony to speech to ensure continuous calls.
Benefits
This feature provides an inter-RAT handover mechanism for the VP service which falls back
to speech instead of call drop.
Description
Video telephony is a service exclusive for 3G system. But due to the limitation of UE and
network support capability, it is possible that the service cannot be implemented. Therefore,
Service Change and UDI Fallback (SCUDIF) is introduced in Release 6. This feature provides
the mechanism to fall back to Speech instead of call drop in these scenarios.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 153 of 174
In 3GPP protocol TS23.172, there are two defined fall back methods:
Fallback: multi-media service fall back to speech during the setup procedure
Service Change: multi-media service fall back to speech during the RAB modification
procedure
They all belong to the bound of multi-media fall back procedure.
Fallback
This procedure can be triggered by UE or network side and implemented by the NAS
signaling. Therefore, to RAN, it is corresponding to the RAB Assignment procedure over
the Iu interface.
Service Change
This procedure can also be triggered by UE or network. When it is triggered by UE, the
CN will initiate an RAB Assignment (Modify) procedure over the Iu interface when
receiving the fallback request from the UE. When it is triggered by UTRAN, the scenario
generally aims to the 3G to 2G handover during which the VP service cannot be
supported. The following flow chart describes the procedure:
UE A MSC A
MODIFY (BCspeech)
MSC B UE B
MODIFY (BCspeech)
MODIFY COMPLETE (BCspeech)
Core Network Procedure
MODIFY COMPLETE (BCspeech)
RNC A
RANAP RAB Assignment
(configuration1, configuration 2)
RANAP Modify Request
(alternate configuration requested)
RAB Assignment Modify (Configuration 2, Configuration1)
Firstly, the MSC must assign the alternative configuration when setting up a VP service to let
UTRAN know it has the fallback capability.
When the user with VP service needs to be handed over to the 2G network, the RNC will
initiate an RAB modify request to trigger fallback. Then, fallback will be implemented by the
MODIFY procedure. From UTRAN view, it is corresponding to the RAB Assignment
(Modify) procedure over the Iu interface.
After the VP service falls back to speech successfully, the following speech inter-RAT
handover can be implemented.
Enhancement
None.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 154 of 174
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
The UE needs to be compliant with 3GPP Release 6 to support the feature.
Dependency on Other Network Units
NA
Dependency on CN
The MSC needs to be compliant with 3GPP Release 6 to support the feature.
Dependency on Other Features
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)
5.4.2 WRFD-020308 Inter-RAT Handover Phase 2
Availability
This feature is available from RAN6.1.
This feature is introduced in 3GPP R6.
Summary
This feature provides the inter-RAT relocation procedure for NACC and PS services to
shorten the interruption time of PS services caused by inter-RAT handover.
Benefits
The service interruption for PS service inter-system handover will be shorter or reduced. With
this feature, in scenario of inter-RAT handover, the user experience will be enhanced greatly
especially for the real-time PS service.
Description
The inter-RAT Handover Enhanced Package includes following features:
NACC (Network Assisted Cell Change)
PS Handover Between UMTS and GPRS
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 155 of 174
With these features, the service interruption for PS service inter-system handover will be
shorter or reduced.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should also support NACC and PS handover.
Dependency on Other Network Units
BSC should support NACC RIM (RAN Information Management) and PS handover
procedure.
Dependency on CN
SGSN should also support NACC and PS handover.
Dependency on Other Features
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)
5.4.3 WRFD-02030801 NACC(Network Assisted Cell Change)
Availability
This feature is available from RAN6.1 (BSC6900 only).
Summary
This feature supports the standard NACC procedure defined in 3GPP specifications.
Benefits
Compared with the normal cell change, the NACC can shorten a service interruption of about
four to eight seconds and greatly enhance user experience.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 156 of 174
Description
The NACC refers to Network Assisted Cell Change from UTRAN to GERAN, which is
different from normal cell change order procedure, due to network providing GERAN (P) SI
to UE.
In today's GPRS networks (without NACC), cell re-selection may cause a service interruption
between 4 – 8 seconds, which obviously has an impact on the user experience. Similar
interruption time can be expected in mixed UMTS and GPRS networks, during UE cell
re-selection from UTRAN to GERAN.
GERAN (P)SI information is acquired by RIM (RAN Information Management) procedure.
In this feature, when handover from UTRAN to GERAN is to be performed, and if both UE
and network support NACC, then RNC will firstly trigger the RIM procedure. If (P)SI is
obtained successfully, cell change order from UTRAN message carrying the GERAN (P)SI
information will be sent. That is, NACC is completed, which is illustrated in the following
figure. Otherwise, normal cell change order would be performed.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should also support NACC handover.
Dependency on Other Network Units
BSC SRNC
UE
SGSN
RRC MEASUREMENT REPORT
WITH GERAN BEST CELL DIRECT INFORMATION
TRANSFER (RAN IFORMATION
REQUEST)
RAN INFORMATION DIRECT INFORMATION
TRANSFER (RAN
INFORMATION REPORT)
RAN INFORMATION
CELL CHANGE ORDER FROM
UTRAN ( (P)SI )
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 157 of 174
BSC should support NACC RIM (RAN Information Management).
Dependency on CN
SGSN should also support NACC handover.
Dependency on Other Features
WRFD-020308 Inter-RAT Handover Phase 2
5.4.4 WRFD-02030802 PS Handover Between UMTS and GPRS
Availability
This feature is available from RAN6.1.
Summary
This feature enables the relocation of PS services between systems.
Benefits
In inter-system handover scenarios, this feature can greatly improve user perception,
especially for real-time PS services.
Description
The PS handover is different from NACC or normal cell change function, with which the
relocation procedure between 3G and 2G is applied, just like the CS inter-system handover.
With this feature, the service interruption for PS service inter-system handover is reduced by a
great extent.
In this feature, both handover from UTRAN to GERAN and handover from GERAN to
UTRAN are supplied. If both UE and network support PS handover, handover between
UTRAN and GERAN would be performed. Otherwise, either NACC or normal cell change
order would be selected.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE should also support PS handover.
Dependency on Other Network Units
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 158 of 174
BSC should support PS handover procedure.
Dependency on CN
SGSN should also support PS handover.
Dependency on Other Features
WRFD-020308 Inter-RAT Handover Phase 2
5.4.5 WRFD-020305 Inter-RAT Handover Based on Service
Availability
This feature is available from RAN5.0.
This feature is introduced in 3GPP R99.
Summary
This feature supports 3G to 2G handover based on service attributes. When 3G and 2G
coexist, this feature enables the 3G traffic to be directed to the 2G system.
Benefits
This feature provides an inter-RAT handover mechanism according to the service. It can
balance the load between the two systems by transferring some kind of appropriate services to
GSM/GPRS and prevent the handover course from bad effect to services according to
attributes of the services.
Description
Inter-RAT Handover based on Service introduces a precondition for UMTS to GSM/GPRS
handover to UTRAN.
The RAB ASSIGNMENT REQUEST message sent from the CN to the RNC may include a
service handover IE. With this IE, the UTRAN determines whether to switch the
corresponding RAB from UTRAN to GSM/GPRS. The operation (the CN sends the RAB
ASSIGNMENT REQUEST message to the RNC) can also influence decisions made
regarding UTRAN-initiated inter-system handovers.
If this indicator is not included in the RAB ASSIGNMENT REQUEST message, the RNC can
use its pre-configured value for various kinds of services.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 159 of 174
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
5.4.6 WRFD-020310 3G/2G Common Load Management
Availability
This feature is available from RAN10.0.
This feature is introduced in 3GPP R5.
Summary
During inter-RAT handover or inter-system direct retry, this feature supports the transfer of
load information as stipulated in 3GPP specifications to reduce inter-RAT ping-pong
handover.
Benefits Decrease the probability of 2G system overload or congestion due to inter-RAT handover
from 3G to 2G based on service or load.
Avoid 3G system overload due to inter-RAT handover from 2G to 3G.
Avoid ping-pong handover between 3G and 2G.
Description
The 3G/2G Common Load Management applies to inter-RAT handover and inter system
direct retry. The load of source cell and target cell are considered during inter-RAT handover
from 3G to 2G or from 2G to 3G and inter system direct retry.
During inter-RAT handover from 3G to 2G, the RNC will send the load information of the
source cell to 2G through RELOCATION REQUIRED message and may get the load
information of target cell from RELOCATION COMMAND message. If the load of target
cell is in a high level (over the threshold configured) and the inter-RAT handover from 3G to
2G is triggered not because of coverage, then the inter-RAT handover from 3G to 2G will be
cancelled.
During inter-RAT handover from 2G to 3G, the RNC may get the load information of the
source cell from RELOCATION REQUEST message. If the load of source cell is not in a
high level (less than the threshold configured) and the inter-RAT handover from 2G to 3G is
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 160 of 174
triggered not because of coverage, then the inter-RAT handover from 2G to 3G will be
refused.
During inter system direct retry, the procedure and decision is similar to that of inter-RAT
handover from 3G to 2G. If the load of target cell is in a high level (over the threshold
configured), inter system direct retry will be cancelled.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
BSS should support this feature.
Dependency on CN
CN should support this feature.
Dependency on Other Features
WRFD-020305 Inter-RAT Handover Based on Service
or WRFD-020306 Inter-RAT Handover Based on Load
or WRFD-021200 HCS (Hierarchical Cell Structure)
or WRFD-020400 DRD Introduction Package
or WRFD-020308 Inter-RAT Handover Phase 2
5.5 UMTS and LTE Radio Resource Management
5.5.1 WRFD-020126 Mobility Between UMTS and LTE Phase1
Availability
This feature is available from RAN12.0.
Summary
This feature covers the following functions:
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 161 of 174
UE cell selects/reselects between LTE and UMTS network.
UE with PS service handovers from the LTE network to the UMTS network are
supported.
Benefits
This feature improves the high-speed service experience of LTE UEs in the area
simultaneously covered by the UMTS network and the LTE network. In addition, in the area
not covered by the LTE network or when the LTE network is heavily loaded, some UEs with
PS service are handed over from the LTE network to the UMTS network.
Description
This feature provides a basic mobility solution for the operators who want to evolve from
UMTS to LTE.
UE cell selects/reselects between UMTS and LTE network.
The RNC supports broadcasting the information about LTE frequencies in a cell and the
parameters related to cell select/reselect. Thus, the UEs in idle state can camp on an LTE cell
preferentially. In this way, on one hand, the UEs can obtain better experience of high-speed
services in the area covered by the LTE network; on the other hand, the potential cell load and
network load of the UMTS network are reduced because these UEs gain access to the LTE
network.
UE with PS service handovers from the LTE network to the UMTS network are
supported.
At the early construction stage of the LTE network, operators may plan the LTE network
coverage only in hot spot areas. When some UEs leave the hot spot area or the LTE system
load is heavy, these UEs need to be handed over from the LTE network to the UMTS network.
With this feature, the RNC can processes the migration requests from the LTE system. This
feature does not support the UE handover from the UMTS network to the LTE network.
LTE Cell
UMTS Cell
LTE Cell
UMTS Cell
Normal UE:
LTE UE
Cell reselection
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 162 of 174
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
UE has the capability of both UMTS and LTE.
Dependency on Other Network Units
NA
Dependency on CN
LTE should also support this feature
Dependency on Other Features
NA
5.6 QoS
5.6.1 WRFD-021103 Access Class Restriction
Availability
This feature is available from RAN5.1.
This feature is introduced in 3GPP R99.
LTE Cell
UMTS Cell UMTS Cell
MTS Cell
Handover
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 163 of 174
Summary
When the RNC‟s Signaling Processing Unit(SPU) is overloaded as while as too many UEs
initiate random access, this feature allows operator to control the access priority according to
UEs‟ Access Class (AC) via broadcasting System Information Block 3 (SIB3).
Benefits
The benefit of this feature is to decrease the signaling processing load of SPU in certain level
via controlling the UEs‟ access sequence, as well as to increase the UEs‟ access rate.
Description
The PRACH resources (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:
When the cell is in signaling overload, “Access Class Barred list” will be updated
automatically and some access classes are barred to prevent too many users accessing
into the cell; when cell signaling load becomes low, more access classes will be
unbarred.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 164 of 174
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
5.6.2 WRFD-050424 Traffic Priority Mapping onto Transmission Resources
Availability
This feature is available from RAN10.0.
Summary
This feature enables the dynamical mapping of the services onto the transport bearers
according to the TC, ARP, and THP of the user. The operator can flexibly configure the
mapping to fulfill differentiated services while guaranteeing the QoS.
Benefits
This feature implements the mapping from traffic priorities to transmission resources and
provides flexible configuration means for differentiated services and for guarantee of QoS.
Description
This feature dynamically maps the services onto the transport bearers, according to the TC
(Traffic Class), ARP (Allocation/Retention Priority), and THP (Traffic Handling Priority for
interactive service) of the user. The operator can flexibly configure the mapping of service
types onto transmission resources. According to different combinations of TC+ARP+THP, the
operator can choose the transmission resources with different QoS requirements to fulfill
differentiated services while guaranteeing the QoS.
TC\ARP Gold Silver Bronze
R99 conversational R99 C
R99 streaming R99 S1 R99 S2 R99 S3
R99 interactive THP
High
THP
Middle
THP
Low
THP
High
THP
Middle
THP
Low
THP
High
THP
Middle
THP
Low
R99
I11
R99 I12 R99
I13
R99
I21
R99 I22 R99
I23
R99
I31
R99 I32 R99
I33
R99 background R99 B1 R99 B2 R99 B3
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 165 of 174
TC\ARP Gold Silver Bronze
HSPA
conversational
HS C
HSPA streaming HS S1 HS S2 HS S3
HSPA interactive THP
High
THP
Middle
THP
Low
THP
High
THP
Middle
THP
Low
THP
High
THP
Middle
THP
Low
HS I11 HS I12 HS
I13
HS I21 HS I22 HS
I23
HS I31 HS I32 HS
I33
HSPA background HS B1 HS B2 HS B3
ATM transport
In ATM transport, the service data with different priorities is mapped to different ATM
service types. The practical mapping can be flexibly configured.
IP transport
In IP transport, the service data with different priorities is mapped to the IP data stream
with different PHB attributes. The practical mapping can be flexibly configured.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 166 of 174
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 167 of 174
The mapping between service bearer and transmission resource also support the primary and
secondary path configuration. In the admission of transmission resource, the primary path is
considered for the service setup firstly, and secondary path will be selected in case of the lack
of primary path bandwidth or failure of the primary path, with this feature, both transmission
reliability and transport efficiency can be improved.
In RAN11.0, the load balancing algorithm is introduced for the path selection to prevent the
uneven load distribution on the primary and secondary path which may lead to the decrease of
transport efficiency. That is, when the load of primary path is too high and the difference with
the secondary path is higher than a configurable threshold, the secondary path will be
selected.
Enhancement
In RAN11.0, the mapping from AAL2 path types to ATM service types is removed, which
makes the priority mapping of ATM services more flexible.
In RAN11.0, the mapping from IP path types to PHBs is removed, which makes the priority
mapping of IP services more flexible.
In RAN11.0, the load balancing algorithm is introduced for the transmission path selection to
enhance transmission efficiency improvement.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
Dependency on Other Features
NA
5.6.3 WRFD-010506 RAB Quality of Service Renegotiation over Iu Interface
Availability
This feature is available from RAN5.0
This feature is introduced in 3GPP R4.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 168 of 174
Summary
This feature enables the RNC to initiate a renegotiation request on the Iu interface for the
MBR and GBR of PS real-time services to decrease the rate of real-time services.
Benefits
This feature enables operator to reduce the cell load by downgrade real-time service bit rate.
Description
RAB Quality of Service Renegotiation over Iu interface is an action for R99 real-time service
during the LDR (Load Reshuffling) procedure to reduce the system load. When the usage of
cell resource exceeds a basic congestion trigger threshold, the RNC will perform load control
algorithm, including the Load Reshuffling (LDR) (WRFD-020106) and Overload control
(OLC) (WRFD-020107). Usually, several actions will be taken to relieve the congestion status
according to the service type.
Real-time service cannot perform rate down-switch automatically like best effort service due
to the QoS requirement. That is, Guarantee Bit Rate (GBR) is specified in RAB assignment
procedure and must be guaranteed. When the system needs to adjust real-time service rate to
relieve the system load, the RNC has to initiate a rate renegotiation over the Iu interface by
requesting a new RAB parameters with a lower bit rate for real time service via RAB
Modification procedure.
The RNC will request a new Max Bit rate, Guaranteed Bit rate which are the lowest ones
among the alternative configurations in the RAB ASSIGNMENT message from the CN. And
it is up to the CN to decide how to react to the request upon reception of the RAB MODIFY
REQUEST message.
Enhancement
None.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
NA
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 169 of 174
Dependency on Other Features
NA
5.6.4 WRFD-010507 Rate Negotiation at Admission Control
Availability
This feature is available from RAN3.0.
This feature is introduced in 3GPP R4.
Summary
This feature enables QoS negotiation and RAB downsizing on the Iu interface.
Benefits
Based on the QoS negotiation mechanism, this feature can enhance the RAB setup process
and shorten the service setup time.
This feature can greatly increase the success rate of call setup and hard handover and
maximize resource usage and system capacity.
Description
This feature makes it possible for a call to access the network with a lower bit rate in case that
cell resource is not enough, and it comprises the following two parts
Iu QoS negotiation
RAB Downsizing
The access success rate, system capacity, and performance can be improved with this feature.
I. Iu QoS negotiation
In Release 99, the UTRAN accepts or rejects a radio access bearer request only from the CN.
If the QoS requirement of the service defined in the RAN establishment request is higher than
that can be handled by UTRAN, the UTRAN cannot accept it. For the services having higher
QoS requirement could accept lower QoS requirements than those requested by the CN in the
RAB establishment request. There are no means for the UTRAN to propose an alternative
(lower) QoS.
For such services, the RAB establishment will fail, or alternatively the CN could re-attempt
the RAB re-establishment with lower QoS requirements. This would significantly increase the
setup time. Therefore, a QoS negotiation mechanism is introduced in Release 4. This aligns
the procedure with the already existing CN solution used in GPRS and shortens the service
setup time. Such a mechanism also applies to the relocation procedure by adding Alternative
RAB Parameter Values IE in the RANAP RAB ASSIGNMENT REQUEST or
RELOCATION REQUEST message.
The Iu QoS negotiation mainly aims for the PS streaming service and is used to negotiate the
maximum and initial bit rate for the service.
Maximum bit rate negotiation
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 170 of 174
The UE capability will be considered to decide the maximum bit rate. That is, the
maximum bit rate will be selected among the maximum bit rate assigned and the
alternative ones in descending order until it meets the UE capability. If the HSPA is
related, the UE capability with HSPA will be used.
Initial bit rate negotiation
To decide the initial bit rate, the following load information should be considered:
− Uplink and downlink radio load states of the cell
− Iub resource state
− Minimum spreading factor supported
− HSPA capability. If a service is related to HSPA, the UE capability must be
considered to get a proper bit rate.
When the cell with radio load or Iub resource load is congested, the minimum bit rate among
the assigned Guaranteed Bit Rate (GBR) will be selected for service admission. Otherwise,
the bit rate among negotiated maximum bit rate and guaranteed bit rate will be selected in
descending order until it meets the load and capability requirements mentioned above.
After the maximum and initial bit rates are made certain and the subsequent admission
procedure is successful, the RNC will inform the CN node of the negotiated bit rate through
RAB ASSIGNMENT REPONSE or RELOCATION REQUEST ACKNOWLEDGE message.
II. RAB downsizing
The RAB downsizing applies mainly to Best Effort (BE) service (interactive or background
service). In an ideal scenario, BE service can always access the network with the maximum
request bit rate if there is enough cell resources, but such a process cannot meet the system
capacity and performance requirements while the system resource is limited. Therefore, the
RNC will try to negotiate the proper maximum and initial bit rate as Iu QoS negotiation does.
Maximum bit rate negotiation
UE capability will be considered to decide the maximum bit rate. That is, the maximum
bit rate will be selected among the maximum bit rate assigned to 8 kbit/s in descending
order until it meets the UE capability. If the HDPA is related, UE capability with HSPA
will be used.
Initial or target bit rate negotiation
The following load information will be considered to decide the initial bit rate:
− Uplink and downlink radio load states of the cell
− Available Iub resource
− Minimum spreading factor supported
− Available credit resource
− HSPA capability, if the service related to HSPA, the UE-related capability must be
considered to get a proper bit rate.
When radio load is congested, GBR will be selected to admit to maximize the access
successful rate. Otherwise, the bit rate among negotiated maximum bit rate to 8 kbit/s will be
selected in descending order until it meets the load and capability requirements mentioned
above.
RAB downsizing can also be applied in the hard handover procedure. That is, with this feature,
during the hard handover procedure, the target cell load will be considered, the downgraded hard handover may be triggered to maximize the handover successful rate.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 171 of 174
Enhancement
In RAN5.0, Iu QoS negotiation feature is introduced.
In RAN5.0, RAB downsizing used in the hard handover procedure is supported.
In RAN5.1, HSPA capability is taken into consideration, and in RAN6.0 the HSUPA feature is
introduced.
In RAN10.0, RAB downsizing can also be applied when the request for adding new radio
links in the AS in soft/softer handover is rejected by admission control due to resource
limitation. The rate will be downgraded according to the cell load information, in order to
avoid the call drop due to soft handover failure.
In RAN11.0, the newly added policy is that the access of the PS service, if denied, allows an
access rate of 0 kbit/s or the implementation on the FACH.
RAN11.0 decides the downlink initial access rate of the R99 BE service on the DCH
according to the Ec/Io contained in the RRC CONNECTION REQUEST message. If the
Ec/Io is higher than the related threshold, the downlink initial access rate is min[384k, MBR]
(where MBR is the maximum bit rate assigned by the CN); if the Ec/Io is lower than the
threshold, the downlink initial access rate is the default value.
Dependency
Dependency on RNC
NA
Dependency on Node B
NA
Dependency on UE
NA
Dependency on Other Network Units
NA
Dependency on CN
For Iu QoS negotiation, the CN node needs to support this feature, but for RAB downsizing,
the CN node does not need to support this feature.
Dependency on Other Features
NA
5.6.5 WRFD-020130 Videophone Service Restriction
Availability
This feature is available from RAN13.0.
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 172 of 174
Summary
This feature disables the videophone (VP) function of a cell through cell-level configurations.
Benefits
This feature meets telecom operators' requirements for information security in restricted areas.
It prevents leakage of information through VP.
Description
In restricted areas such as military management areas and key laboratories, the use of VP may
lead to leakage of information. To meet the security requirements in these areas, the RNC
supports the prohibition of VP services at the cell level. Through configurations on the Local
Maintenance Terminal (LMT), the VP services of all UEs in a cell can be prohibited.
The implementation of this feature involves the following aspects:
Prohibiting VP service setup during service establishment
Releasing VP services in the case of an incoming handover, for example, retaining other
services except VP services when the UE has multiple concurrent services to process
Enhancement
None
Dependency
Dependency on RNC hardware
None
Dependency on NodeB hardware
None
Dependency on other RAN features
None
Dependency on other NEs
None
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 173 of 174
6 Acronyms and Abbreviations
3G The Third Generation
AP Access Point
APM Advanced Power Module
AQM Active Queue Management
BBU Baseband Unit
BITS Building Integrated Timing Supply System
BTS Base Station
CBS Cell Broadcast Service
CPC Continuous Packet Connectivity
CPE Customer Premises Equipment
DNBS Distributed Node B System
DSAC Domain Specific Access Control
ETSI European Telecommunications Standards Institute
FTP File Transfer Protocol
GIS Geographical Information System
GA General Available
GBR Guaranteed Bit Rate
GLONASS GLObal Navigation Satellite System
GPS Global Position System
HCS hierarchical Cell Structure
HSDPA High Speed Downlink Packet Access
HSUPA High Speed Uplink Packet Access
LCS Location Service
RAN12.0 Optional Feature Description(3GPP)
Issue 1.0 (2010-06-10) Commercial in Confidence Page 174 of 174
LTE Long Term Evolution
MBMS Multimedia Broadcast Multicast Service
MIMO Multi-Input Multi-Output
NACC Network Assisted Cell Change
PA Power Amplifier
PARC Platform Advanced Radio Control
PPS Pulse Per Second
QAM Quadrature Amplitude Modulation
RAN Radio Access Network
RET Remote Electrical Antenna
RNC Radio Network Controller
ROHC Robust Header Compression
RRM Radio Resource Management
SAE System Architecture Evolution
SASA Same Band Antenna Sharing Adapter
SASU Same Band Antenna Sharing Unit
SNA Shared Network Area
TGW Transmission Gateway
VoIP Voice over IP
WCDMA Wideband Code Division Multiple Access