Load Control (RAN14.0 05)

RAN14.
0
Network Impact Report
Issue 05
Date 2013-06-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in 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: support@huawei.com
RAN14.0
Network Impact Report Contents
Contents
1 General Impact...........................................................................................................................2-1
1.1 Version Compatibility ..................................................................................................................... 2-1
1.2 Capacity and Performance ............................................................................................................ 2-1
1.2.1 RNC ...................................................................................................................................... 2-1
1.2.2 NodeB ................................................................................................................................... 2-6
1.2.3 M2000 ................................................................................................................................... 2-6
1.3 Hardware ....................................................................................................................................... 2-7
1.3.1 RNC ...................................................................................................................................... 2-7
1.3.2 NodeB ................................................................................................................................... 2-7
1.3.3 M2000 ................................................................................................................................... 2-8
1.4 Implementation .............................................................................................................................. 2-8
1.4.1 Upgrade Path ....................................................................................................................... 2-8
1.4.2 Upgrade from RAN13.0 to RAN14.0 .................................................................................... 2-8
1.5 License .......................................................................................................................................... 2-8
1.5.1 Permanent and Temporary License Authorization Mechanism ............................................ 2-9
1.5.2 Changes in the License ........................................................................................................ 2-9
1.6 Inter-NE Interface ........................................................................................................................ 2-11
1.7 Operation and Maintenance ........................................................................................................ 2-12
1.8 Impact on Other NEs ................................................................................................................... 2-12
2 Summary of Feature Impacts.................................................................................................2-1

3 Impacts of RAN14.0 Features on RAN13.0 .........................................................................3-1
3.1 WRFD-140101 System Improvements for RAN14.0 (New/Basic) ................................................ 3-1
3.1.1 Description ............................................................................................................................ 3-1
3.1.2 Capacity and Performance ................................................................................................... 3-1
3.1.3 Impact on NEs ...................................................................................................................... 3-1
3.1.4 Hardware .............................................................................................................................. 3-1
3.1.5 Inter-NE Interface ................................................................................................................. 3-1
3.1.6 Operation and Maintenance ................................................................................................. 3-2
3.1.7 Impact on Other Features..................................................................................................... 3-2
3.2 MRFD-210304 Enhanced Fault Management (Enhanced/Basic) ................................................. 3-2
3.2.1 Description ............................................................................................................................ 3-2
3.2.3 Impact on NEs ...................................................................................................................... 3-3
3.2.4 Hardware .............................................................................................................................. 3-3
3.3 WRFD-021350 Independent Demodulation of Signals from Multiple RRUs in One Cell
(Enhanced/Optional) ........................................................................................................................... 3-4
Issue 05 (2013-06-20) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd
RAN14.0
3.3.1 Description ............................................................................................................................ 3-4

3.3.3 Impact on NEs ...................................................................................................................... 3-5
3.3.4 Impact on Hardware ............................................................................................................. 3-5
3.4 WRFD-020111 One Tunnel (Enhanced/Optional) ......................................................................... 3-6
3.4.1 Description ............................................................................................................................ 3-6
3.4.3 Impact on NEs ...................................................................................................................... 3-6
3.5 MRFD-210103 Link Aggregation (Enhanced/Basic) ..................................................................... 3-7
3.5.1 Description ............................................................................................................................ 3-7
3.5.3 Impact on NEs ...................................................................................................................... 3-8
3.6 WRFD-030004 Adaptive Configuration of Typical HSPA Rate (New/Optional) ............................ 3-9
3.6.1 Description ............................................................................................................................ 3-9
3.6.3 Impact on NEs .................................................................................................................... 3-10
3.6.4 Hardware ............................................................................................................................ 3-10
3.6.5 Inter-NE Interface ............................................................................................................... 3-10
3.6.6 Operation and Maintenance ............................................................................................... 3-10
3.6.7 Impact on Other Features................................................................................................... 3-11
3.7 WRFD-140206 Layered Paging in URA_PCH (New/Optional) ................................................... 3-11
3.7.1 Description .......................................................................................................................... 3-11
3.7.2 Capacity and Performance ................................................................................................. 3-11
3.7.3 Impact on NEs .................................................................................................................... 3-12
3.7.4 Hardware ............................................................................................................................ 3-12
3.8 WRFD-140213 Intelligent Access Class Control (New/Optional) ............................................... 3-13
3.8.1 Description .......................................................................................................................... 3-13
Issue 05 (2013-06-20) Huawei Proprietary and Confidential ii

RAN14.0
3.8.3 Impact on NEs .................................................................................................................... 3-14

3.8.4 Hardware ............................................................................................................................ 3-14
3.9 WRFD-140201 AMR Voice Quality Improvement Based on PLVA (New/Optional) .................... 3-18
3.9.1 Description .......................................................................................................................... 3-18
3.9.3 Impact on NEs .................................................................................................................... 3-19
3.9.4 Hardware ............................................................................................................................ 3-19
3.10 WRFD-140205 Voice Service Experience Improvement for Weak Reception UEs (New/Optional)
........................................................................................................................................................... 3-20
3.10.1 Description ........................................................................................................................ 3-20
3.10.2 Capacity and Performance ............................................................................................... 3-20
3.10.3 Impact on NEs .................................................................................................................. 3-21
3.10.4 Hardware .......................................................................................................................... 3-21
3.10.5 Inter-NE Interface ............................................................................................................. 3-21
3.10.6 Operation and Maintenance ............................................................................................. 3-21
3.10.7 Impact on Other Features................................................................................................. 3-24
3.11 WRFD-140219 Micro NodeB Self-Planning (New/Optional) ..................................................... 3-24
3.11.1 Description ........................................................................................................................ 3-24
3.11.3 Impact on NEs .................................................................................................................. 3-24
3.11.4 Hardware .......................................................................................................................... 3-24
3.11.7 Impact on Other Features ................................................................................................. 3-25
3.12 WRFD-140222 Adaptive Adjustment of HSUPA Small Target Retransmissions(Try)
(New/Optional) .................................................................................................................................. 3-25
3.12.1 Description ........................................................................................................................ 3-25
3.12.3 Impact on NEs .................................................................................................................. 3-26
3.12.4 Hardware .......................................................................................................................... 3-26
3.13 WRFD-140221 HSDPA Scheduling based on UE Location (New/Optional)............................. 3-27
3.13.1 Description ........................................................................................................................ 3-27
Issue 05 (2013-06-20) Huawei Proprietary and Confidential iii

RAN14.0
3.13.3 Impact on NEs .................................................................................................................. 3-28

3.13.4 Hardware .......................................................................................................................... 3-28
3.14 WRFD-140204 DC-HSUPA (New/Optional) .............................................................................. 3-29
3.14.1 Description ........................................................................................................................ 3-29
3.14.3 Impact on NEs .................................................................................................................. 3-30
3.14.4 Hardware .......................................................................................................................... 3-30
3.15 WRFD-140203 HSPA+ Uplink 23 Mbit/s per User (New/Optional) ........................................... 3-36
3.15.1 Description ........................................................................................................................ 3-36
3.15.3 Impact on NEs .................................................................................................................. 3-36
3.15.4 Hardware .......................................................................................................................... 3-36
3.16 WRFD-01061002 HSUPA UE Category Support (Enhanced/Optional) .................................... 3-37
3.16.1 Description ........................................................................................................................ 3-37
3.16.3 Impact on NEs .................................................................................................................. 3-37
3.16.4 Hardware .......................................................................................................................... 3-38
3.17 WRFD-140202 Control Channel Parallel Interference Cancellation (Phase 2)(New/Optional) 3-38
3.17.1 Description ........................................................................................................................ 3-38
3.17.3 Impact on NEs .................................................................................................................. 3-39
3.17.4 Hardware .......................................................................................................................... 3-39
3.18 WRFD-140215 Dynamic Configuration of HSDPA CQI Feedback Period (New/Optional) ....... 3-41
3.18.1 Description ........................................................................................................................ 3-41
3.18.3 Impact on NEs .................................................................................................................. 3-42
3.18.4 Hardware .......................................................................................................................... 3-42
Issue 05 (2013-06-20) Huawei Proprietary and Confidential iv

RAN14.0

3.19 WRFD-140216 Load-based Uplink Target BLER Configuration (New/Optional) ...................... 3-44
3.19.1 Description ........................................................................................................................ 3-44
3.19.3 Impact on NEs .................................................................................................................. 3-44
3.19.4 Hardware .......................................................................................................................... 3-45
3.20 WRFD-140207 Iu/Iur Transmission Resource Pool in RNC (New/Optional) ............................ 3-46
3.20.1 Description ........................................................................................................................ 3-46
3.20.3 Impact on NEs .................................................................................................................. 3-47
3.20.4 Hardware .......................................................................................................................... 3-47
3.21 WRFD-140208 Iub Transmission Resource Pool in RNC (New/Optional) ............................... 3-50
3.21.1 Description ........................................................................................................................ 3-50
3.21.3 Impact on NEs .................................................................................................................. 3-51
3.21.4 Hardware .......................................................................................................................... 3-51
3.22 WRFD-140223 MOCN Cell Resource Demarcation (New/Optional) ........................................ 3-55
3.22.1 Description ........................................................................................................................ 3-55
3.22.3 Impact on NEs .................................................................................................................. 3-56
3.22.4 Hardware .......................................................................................................................... 3-56
3.23 WRFD-140210 NodeB PKI Support (New/Optional)................................................................. 3-59
3.23.1 Description ........................................................................................................................ 3-59
3.23.3 Impact on NEs .................................................................................................................. 3-60
3.23.4 Hardware .......................................................................................................................... 3-60
Issue 05 (2013-06-20) Huawei Proprietary and Confidential v

RAN14.0

3.24 WRFD-140209 NodeB Integrated IPSec (New/Optional) ......................................................... 3-62
3.24.1 Description ........................................................................................................................ 3-62
3.24.3 Impact on NEs .................................................................................................................. 3-64
3.24.4 Hardware .......................................................................................................................... 3-64
3.25 WRFD-050402 IP Transmission Introduction on Iub Interface (Enhanced/Optional) ............... 3-67
3.25.1 Description ........................................................................................................................ 3-67
3.25.3 Impact on NEs .................................................................................................................. 3-67
3.25.4 Hardware .......................................................................................................................... 3-67
3.26 WRFD-140218 Service-Based PS Handover from UMTS to LTE (New/Optional) ................... 3-69
3.26.1 Description ........................................................................................................................ 3-69
3.26.3 Impact on NEs .................................................................................................................. 3-70
3.26.4 Hardware .......................................................................................................................... 3-70
3.27 WRFD-140102 CS Fallback Guarantee for LTE Emergency Calls (New/Basic) ...................... 3-72
3.27.1 Description ........................................................................................................................ 3-72
3.27.3 Impact on NEs .................................................................................................................. 3-72
3.27.4 Hardware .......................................................................................................................... 3-72
3.28 WRFD-140212 CE Overbooking (New/Optional) ...................................................................... 3-73
3.28.1 Description ........................................................................................................................ 3-73
3.28.3 Impact on NEs .................................................................................................................. 3-75
3.28.4 Hardware .......................................................................................................................... 3-75
3.29 WRFD-020103 Inter-Frequency Load Balance (Enhanced/Optional) ...................................... 3-76
Issue 05 (2013-06-20) Huawei Proprietary and Confidential vi

RAN14.0
3.29.1 Description ........................................................................................................................ 3-76

3.29.3 Impact on NEs .................................................................................................................. 3-77
3.29.4 Hardware .......................................................................................................................... 3-77
3.30 WRFD-140217 Inter-Frequency Load Balancing Based on Configurable Load Threshold
(New/Optional) .................................................................................................................................. 3-79
3.30.1 Description ........................................................................................................................ 3-79
3.30.3 Impact on NEs .................................................................................................................. 3-80
3.30.4 Hardware .......................................................................................................................... 3-80
3.31 WRFD-020160 Enhanced Multiband Management (Enhanced/Optional) ................................ 3-84
3.31.1 Description ........................................................................................................................ 3-84
3.31.3 Impact on NEs .................................................................................................................. 3-85
3.31.4 Impact on Hardware ......................................................................................................... 3-85
3.32 WRFD-020110 Multi Frequency Band Networking Management (Enhanced/Optional) ........... 3-87
3.32.1 Description ........................................................................................................................ 3-87
3.32.3 Impact on NEs .................................................................................................................. 3-88
3.32.4 Hardware .......................................................................................................................... 3-88
3.33 WRFD-020503 Outer Loop Power Control (Enhanced/Basic) .................................................. 3-90
3.33.1 Description ........................................................................................................................ 3-90
3.33.3 Impact on NEs .................................................................................................................. 3-91
3.33.4 Hardware .......................................................................................................................... 3-91
3.34 WRFD-140211 Dynamic Target RoT Adjustment (New/Optional) ............................................. 3-92
3.34.1 Description ........................................................................................................................ 3-92
Issue 05 (2013-06-20) Huawei Proprietary and Confidential vii

RAN14.0

3.34.3 Impact on NEs .................................................................................................................. 3-93
3.34.4 Hardware .......................................................................................................................... 3-93
3.35 WRFD-140220 Intelligent Battery Management (New/Optional) .............................................. 3-95
3.35.1 Description ........................................................................................................................ 3-95
3.35.3 Impact on NEs .................................................................................................................. 3-95
3.35.4 Hardware .......................................................................................................................... 3-95
3.36 WRFD-02040005 Inter-Frequency Redirection Based on Distance (New/Optional) ................ 3-96
3.36.1 Description ........................................................................................................................ 3-96
3.36.3 Impact on NEs .................................................................................................................. 3-97
3.36.4 Hardware .......................................................................................................................... 3-97
3.36.7 Impact on Other Features............................................................................................... 3-101
3.37 WRFD-140224 Fast CS Fallback Based on RIM (New/Optional) ........................................... 3-101
3.37.1 Description ...................................................................................................................... 3-101
3.37.2 Capacity and Performance ............................................................................................. 3-102
3.37.3 Impact on NEs ................................................................................................................ 3-102
3.37.4 Hardware ........................................................................................................................ 3-102
3.37.5 Inter-NE Interface ........................................................................................................... 3-102
3.37.6 Operation and Maintenance ........................................................................................... 3-102
3.38 WRFD-140226 Fast Return from UMTS to LTE (New/Try) ..................................................... 3-104
3.38.1 Description ...................................................................................................................... 3-104
3.38.3 Impact on NEs ................................................................................................................ 3-105
3.38.4 Hardware ........................................................................................................................ 3-105
3.39 WRFD-150237 Horizontal Beamwidth Adjustment (New/Optional) ........................................ 3-106
3.39.1 Feature Description ........................................................................................................ 3-106
3.39.2 System Capacity and Network Performance.................................................................. 3-106
3.39.3 NEs ................................................................................................................................. 3-107
3.39.4 Hardware ........................................................................................................................ 3-107
Issue 05 (2013-06-20) Huawei Proprietary and Confidential viii

RAN14.0

3.39.7 Related Features ............................................................................................................ 3-108
3.40 WRFD-150238 Azimuth Adjustment (New/Optional) .............................................................. 3-108
3.40.3 NEs ................................................................................................................................. 3-109
3.40.4 Hardware ........................................................................................................................ 3-109
3.41 WRFD-140103 Call Reestablishment (New/Basic) ................................................................. 3-110
3.41.3 NEs .................................................................................................................................. 3-111
3.41.4 Hardware ......................................................................................................................... 3-111
3.41.5 Inter-NE Interfaces .......................................................................................................... 3-111
3.41.6 Operation and Maintenance ............................................................................................ 3-111
3.42 WRFD-140104 Enhanced Combined Services(New/Basic) ................................................... 3-113
3.42.3 NEs ................................................................................................................................. 3-114
3.42.4 Hardware ........................................................................................................................ 3-114
3.42.5 Inter-NE Interfaces ......................................................................................................... 3-114
3.43 GSM Power Control on Interference Frequency for GU Small Frequency gap (New/Optional/GU)
......................................................................................................................................................... 3-119
3.43.1 Description ...................................................................................................................... 3-119
3.43.3 Impact on NEs ................................................................................................................ 3-122
3.43.4 Hardware ........................................................................................................................ 3-122
3.44 Dynamic MA for GU Dynamic Spectrum Sharing (New/Optional/GU) .................................... 3-126
3.44.1 Description ...................................................................................................................... 3-126
3.44.3 Impact on NEs ................................................................................................................ 3-127
3.44.4 Hardware ........................................................................................................................ 3-127
Issue 05 (2013-06-20) Huawei Proprietary and Confidential ix

RAN14.0

3.45 Multi-mode BS Common IPSec (New/Optional/GUL) ............................................................. 3-129
3.45.1 Description ...................................................................................................................... 3-129
3.45.3 Impact on NEs ................................................................................................................ 3-130
3.45.4 Hardware ........................................................................................................................ 3-130
3.46 IP-Based Multi-mode Co-Transmission on BS side (Enhanced/Optional/GUL) ..................... 3-131
3.46.1 Description ...................................................................................................................... 3-131
3.46.3 Impact on NEs ................................................................................................................ 3-133
3.46.4 Hardware ........................................................................................................................ 3-133
3.47 IP-Based Multi-mode Common Clock on BS side (Enhanced/Optional/GUL) ........................ 3-136
3.47.1 Description ...................................................................................................................... 3-136
3.47.3 Impact on NEs ................................................................................................................ 3-138
3.47.6 Impact on Other NEs ...................................................................................................... 3-138
3.48 Bandwidth sharing of MBTS Multi-mode Co-Transmission (Enhanced/Optional/UL) ............. 3-138
3.48.1 Description ...................................................................................................................... 3-138
3.48.3 Impact on NEs ................................................................................................................ 3-139
3.48.4 Hardware ........................................................................................................................ 3-140
3.49 Other Impacts .......................................................................................................................... 3-140
3.49.1 Introduction ..................................................................................................................... 3-140
3.49.2 Increased Maximum Number of FACH Users ................................................................ 3-141
3.49.3 Shortened RRC CONNECTION SETUP Message ........................................................ 3-141
3.49.4 Enhanced Call Reestablishment .................................................................................... 3-142
3.49.5 Dynamic Activation Time Adjustment for 13.6 kbit/s Signaling ....................................... 3-142
3.49.6 HSPA Serving Cell Change in Weak-Coverage Scenarios ............................................ 3-143
3.49.7 Canceling of Inter-Frequency Handovers of Speech Services....................................... 3-143
Issue 05 (2013-06-20) Huawei Proprietary and Confidential x

RAN14.0
3.49.8 Optimized Control Mechanism for Inter-Frequency Handovers ..................................... 3-143

3.49.9 Asynchronous Reconfiguration for Inter-Frequency Handovers .................................... 3-143
3.49.10 Intelligent Fast State Transition .................................................................................... 3-144
3.49.11 Priorities of Inter-RAT Handovers and Inter-frequency Handovers .............................. 3-145
3.49.12 Optimization for Uplink Power Admission..................................................................... 3-145
3.49.13 Measurement of the Actual Uplink Service Load ......................................................... 3-146
3.49.14 Protection Against Outer-loop Power Control Congestion in the Case of a High RTWP ... 3-
147
3.49.15 Fast Synchronization on the Physical Layer (L1) ......................................................... 3-147
3.49.16 UMTS-to-LTE Fast Return ............................................................................................ 3-147
3.49.17 PS RRC Resource Preemption .................................................................................... 3-148
3.49.18 Initial TTI Selection for Coverage-based BE Services ................................................. 3-149
3.49.19 RSCP-based Cell Reselection ..................................................................................... 3-149
3.49.20 Dynamic BLER Adjustment for AMR Voice Services ................................................... 3-149
3.49.21 Maintenance Mode Alarms ........................................................................................... 3-150
3.49.22 Optimized Mechanism for Handling Major VSWR Alarms ........................................... 3-150
3.49.23 Standby/Active Switchover Time Configured Based on BFD ....................................... 3-151
3.49.24 Optimized Uplink Enhanced CELL_FACH ................................................................... 3-151
3.49.25 Inactivity-based F2P ..................................................................................................... 3-152
4 Glossary ......................................................................................................................................4-1
5 Acronyms and Abbreviations ................................................................................................5-1
6 References ..................................................................................................................................6-1
Issue 05 (2013-06-20) Huawei Proprietary and Confidential xi

RAN14.0
Network Impact Report About This Document
About This Document

Purpose
This document describes the impact of new and enhanced RAN14.0 features on RAN13.0. This
document also provides the required information for network planning personnel and operation and
maintenance (O&M) personnel to prepare for upgrades to RAN14.0.
This document is for reference purposes only and is subject to change during the development of this
new release.
Intended Audience
This document is intended for:
Network planning engineers
System engineers
Network operators
Change History
Changes between document issues are cumulative. The latest document issue contains all the changes
in earlier issues.
05 (2013-06-20)
This is the fifth official release of RAN14.0.
Compared with issue 04 (2013-05-10), this issue:
Added the network impact of WRFD-150237 Horizontal Beamwidth Adjustment.
Added the network impact of WRFD-150238 Azimuth Adjustment.
Added the network impact of WRFD-140103 Call Reestablishment
Added the network impact of WRFD-140104 Enhanced Combined Services
04 (2013-05-10)
This is the fourth official release of RAN14.0.
Added the network impact of WRFD-140226 Fast Return from UMTS to LTE.
Added the network impact of Optimized Uplink Enhanced CELL_FACH
Added the network impact of Inactivity-based F2P
03 (2012-11-30)
This is the third official release of RAN14.0.
Compared with issue 02 (2012-07-20), this issue optimizes some descriptions.
02 (2012-07-20)
This is the second official release of RAN14.0.
Issue 05 (2013-06-20) Huawei Proprietary and Confidential i

RAN14.0
Contains the following new information:

Description of the RRU3942 and RRU3926 added to the DBS3900
Description of the new UMTS signaling capacity license
Contains the following changes:
Impact of the increased maximum number of FACH users on network performance
Impact of optimized uplink power admission on network performance
Impact of CE Overbooking on network performance.
01 (2012-04-30)
This is the first commercial release for RAN14.0.
Compared with draft A (2012-02-15), this issue:
Added the following:
Impact of the increased number of control-plane boards on CPU usage.
Measurement of the actual uplink service load.
WRFD-02040005 Inter-Frequency Redirection Based on Distance.
WRFD-140224 Fast CS Fallback Based on RIM.
IP-Based Multi-mode Common Clock on BS side.
Modified the following:
Description of SAUc board functions.
Description
of IP-Based Multi-mode Co-Transmission on BS side. For details, see section 3.46 "IP-
Based Multi-mode Co-Transmission on BS side (Enhanced/Optional/GUL)."
Impact of the WRFD-021350 Independent Demodulation of Signals from Multiple RRUs in One Cell
feature on other features. For details, see section 3.3.7 "Impact on Other Features."
Impact of the WRFD-030004 Adaptive Configuration of Typical HSPA Rate feature on hardware. For
details, see section 3.6.4 "Hardware."
Impactof the WRFD-140201 AMR Voice Quality Improvement Based on PLVA feature on hardware.
For details, see section 3.9.4 "Hardware."
Impact of the WRFD-140221 HSDPA Scheduling Based on UE Location feature on hardware. For
details, see section 3.13.4 "Hardware."
Impact
of the WRFD-140204 DC-HSUPA feature on hardware. For details, see section 3.14.4
"Hardware."
Impactof the WRFD-140203 on HSPA+ Uplink 23 Mbit/s per User feature on hardware. For details,
see section 3.15.4 "Hardware."
Impactof the WRFD-140202 Control Channel Parallel Interference Cancellation (Phase 2) feature
on hardware. For details, see section 3.17.4 "Hardware."
Impactof the WRFD-140215 Dynamic Configuration of HSDPA CQI Feedback Period feature on
hardware and other features. For details, see sections 3.18.4 "Hardware" and 3.18.7 "Impact on
Other Features."
Impactof the WRFD-140216 Load-based Uplink Target BLER Configuration feature on hardware
and other features. For details, see sections 3.19.4 "Hardware" and 3.19.7 "Impact on Other
Features."
Impact of the WRFD-140210 NodeB PKI Support feature on hardware and inter-NE interfaces. For
details, see sections 3.23.4 "Hardware" and 3.23.5 "Inter-NE Interface."
Issue 05 (2013-06-20) Huawei Proprietary and Confidential ii

RAN14.0
Impact of the WRFD-140209 NodeB Integrated IPSec feature on transmission efficiency, hardware,
and operation and maintenance. For details, see sections 3.24.2 "Capacity and Performance",
3.24.3 "Impact on NEs", and 3.24.6 "Operation and Maintenance."
Impact of the WRFD-140212 CE Overbooking feature on network performance and hardware. For
details, see sections 3.28.2 "Capacity and Performance" and 3.28.4 "Hardware."
Impactof the WRFD-020503 Outer Loop Power Control feature on system capacity. For details, see
section 3.33.2 "Capacity and Performance."
Impactof the WRFD-140211 Dynamic Target RoT Adjustment feature on hardware. For details, see
section 3.34.4 "Hardware."
Dependency of the optimized uplink power admission algorithm on hardware and features. For
details, see section 3.49.12 "Optimization for Uplink Power Admission."
Deleted the following:
Description of version support for the iDBS3900.
Draft A (2012-02-15)
This is the first draft for RAN14.0.
Issue 05 (2013-06-20) Huawei Proprietary and Confidential iii

RAN14.0
Network Impact Report 1 General Impact
1 General Impact
1.1 Version Compatibility
Table 1-1 lists the products and versions involved in RAN14.0.
Table 1-1 Products and versions involved in RAN14.0
Product Version
RNC BSC6900 V900R014C00
NodeB BTS3812 series base stations:
BTS3812E V100R014C00
BTS3812A V100R014C00
BTS3812AE V100R014C00
DBS3800 V100R014C00
BTS3900 series base stations:
BTS3900 WCDMA V200R014C00
BTS3900 WCDMA V200R014C90, which supports the WBBPf
board
BTS3900A WCDMA V200R014C00
BTS3900C WCDMA V200R014C00
BTS3900L WCDMA V200R014C00
BTS3900AL WCDMA V200R014C00
BTS3902E WCDMA V200R014C00
DBS3900 series base stations:
DBS3900 WCDMA V200R014C00
DBS3900 WCDMA V200R014C90, which supports the WBBPf
board
M2000 iManager M2000 V200R012C00
CME iManager M2000-CME V200R012C00
1.2 Capacity and Performance

1.2.1 RNC
The RNC model for RAN14.0 is BSC6900.
Compared with RAN13.0 BSC6900, RAN14.0 BSC6900 has the following advantages and
disadvantages:
Increased system capacity
Improved processing for NodeB Application Part (NBAP) signaling
Increased CPU usage caused by control-plane board number increase
Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-1

RAN14.0
NOTE
For details about the BSC6900 specifications, see the SRAN7.0&GBSS14.0&RAN14.0 BSC6900 Product Description.
Increased System Capacity

Compared with RAN13.0 BSC6900, RAN14.0 BSC6900 provides increased system capacity for the
following:
Busy hour call attempts (BHCA)
Traffic volume (Erlang)
PS data throughput in the uplink and downlink
Table 1-2 lists the capacity specifications of RAN14.0 BSC6900 configured with HW69 R13 boards.
Table 1-2 RAN14.0 BSC6900 capacity specifications (with HW69 R13 boards)
Item Specifications
BHCA (k) 5300
BHCA (k) (SMS included) 7000
PS (UL+DL) data throughput (Mbit/s) 40,000
Traffic volume (Erlang) 167,500
NOTE
SMS stands for short message service.
In actual networks, these capacity specifications depend on specific traffic models and
configurations and cannot reach the maximum capacity simultaneously.
To simplify the BHCA comparison between RAN13.0 and RAN14.0, the BHCA specification is
provided for the balanced traffic model. For the BHCA specification in other traffic models, see
Table 1-4, Table 1-6, and Table 1-8.
The PS data throughput is listed based on a traffic rate of 64 kbit/s for the uplink and 384 kbit/s
for the downlink.
BSC6900 hardware configurations and capacity specifications vary depending on the traffic models.
The following describes the BSC6900 capacity specifications in typical traffic models:
Balanced traffic model
This model is applicable in networks that meet both of the following conditions:
Traffic volume from cell phones almost equals that from data cards.
Voice services and data services are balanced.
Table 1-3 describes the balanced traffic model for the BSC6900 UMTS.
Table 1-3 BSC6900 UMTS balanced traffic model (per user during busy hours)
Item Specifications Description
CS voice traffic 20 mE Adaptive multi-rate (AMR) speech
volume service, 0.96 BHCA
CS data traffic 1.5 mE UL: 64 kbit/s, DL: 64 kbit/s, 0.04 BHCA
volume

RAN14.0

PS throughput 4500 bit/s UL: 25 kbit/s, DL: 145 kbit/s, 2 BHCA
Proportion of soft 30% Proportion of all calls that use two
handovers channels simultaneously
Number of 8 Average number of handovers per CS
handovers per CS call
call
Number of 5 Average number of handovers per PS call
handovers per PS
call
Number of non- 3.6 Number of NAS procedures between the
access stratum CN and UE, including location area
(NAS) procedures update, international mobile subscriber
identity (IMSI) attach/detach, routing area
update, general packet radio service
(GPRS) attach/detach, and SMS
Table 1-4 lists the capacity specifications of a BSC6900 UMTS in typical hardware configurations. In
this table, the BSC6900 UMTS is configured with HW69 R13 boards and uses the balanced traffic
model.
Table 1-4 Capacity specifications of a BSC6900 UMTS in typical hardware configurations (with HW69 R13
boards)
Number of CS Voice PS Service BHCA (k) BHCA (k)
subscribers Service Capacity (Iub (SMS
Capacity UL+DL) (Mbit/s) Included)
(Erlang)
1,760,000 45,738 7,920 5,300 7,000
NOTE
CS voice service capacity and PS service capacity can reach the maximum capacity
simultaneously.
High-PS traffic model

This model is applicable to networks where data cards make up a large proportion of the total number
of admitted terminals. In this model, the PS throughput per user is relatively high. Table 1-5 describes
the high-PS traffic model for the BSC6900 UMTS.
Table 1-5 BSC6900 UMTS high-PS traffic model (per user during busy hours)
Item Specificati Description
ons
CS voice traffic 3 mE AMR speech service, 0.144 BHCA
volume

RAN14.0
Item Specificati Description

ons
volume
PS throughput 43,500 bit/s UL: 64 kbit/s, DL: 384 kbit/s, 3 BHCA
Proportion of soft 30% Proportion of all calls that use two channels
handovers simultaneously
Number of handovers 8 Average number of handovers per CS call
per CS call
Number of handovers 5 Average number of handovers per PS call
per PS call
Number of NAS 3.6 Number of NAS procedures between the
procedures CN and UE, including location area update,
IMSI attach/detach, routing area update,
GPRS attach/detach, and SMS
this table, the BSC6900 UMTS is configured with HW69 R13 boards and uses the high-PS traffic model.
boards)
Online Service Capacity (Iub (SMS
Users Capacity UL+DL) (Mbit/s) Included)
(Erlang)
925,000 3606 40,200 2900 3840
NOTE
simultaneously.
Traffic model for smartphones

With the increasing use of smartphones in a network (high smartphone penetration), RAN14.0
introduces the traffic model for smartphones. In this model, the average PS throughput is low and the
call access success rate is high. Table 1-7 describes the traffic model for smartphones for the
BSC6900 UMTS.
Table 1-7 BSC6900 UMTS traffic model for smartphones (per user during busy hours)
CS voice traffic 31 mE AMR speech service, 0.8 BHCA
volume
volume

RAN14.0

PS throughput 1600 bit/s UL: 1.5 kbit/s, DL: 7.5 kbit/s, 10 BHCA
Proportion of soft 35% Proportion of all calls that use two channels
handovers simultaneously
Number of 12 Average number of handovers per CS call
handovers per CS
call
Number of 1 Average number of handovers per PS call
handovers per PS
call
Number of NAS 3.8 Number of NAS procedures between the
procedures CN and UE, including location area update,
IMSI attach/detach, routing area update,
GPRS attach/detach, and SMS
this table, the BSC6900 UMTS is configured with HW69 R13 boards and uses the traffic model for
smartphones.
boards)
Online Service Capacity (Iub (SMS
Users Capacity UL+DL) (Mbit/s) Included)
(Erlang)
1,130,000 47,000 1860 12,800 14,000
NOTE
simultaneously.
Improved Processing for NBAP Signaling

RAN14.0 BSC6900 improves a single NodeB's processing for NBAP signaling, increasing the signaling
processing from 360 times per second in RAN13.0 to 1800 times per second in RAN14.0.
RAN14.0 BSC6900 enables the NBAP signaling of a single NodeB to be processed among multiple
signaling processing unit (SPU) subsystems. This prevents a bottleneck in the processing capability
that may occur when a single SPU subsystem is used.
Increased CPU Usage Due to an Increased Number of Control-Plane Boards

RAN14.0 BSC6900 supports up to 50 pairs of SPU boards, 20 pairs more than RAN13.0 BSC6900.
With the increase in the number of SPU boards, the amount of information to be synchronized inside
the BSC6900 increases, leading to a slight rise in the CPU usage of nearly all types of boards in the
BSC6900.
Table 1-9 describes the approximate rise in the CPU usage of each type of board.

RAN14.0
Table 1-9 Approximate rise in the CPU usage of each type of board
Board Type Approximate Rise in Absolute
CPU Usage
SPUa/SPUb 2%
AEUa/PEUa/UOIa/POUa/AOUa/GOUa/FG2a 2% to 3%
AOUc/POUc/UOIc/GOUc/FG2c 1%
SCUa/SCUb 3% to 4%
DPUb/DPUe No noticeable changes
1.2.2 NodeB
To meet the signaling processing requirements of hot spots with high capacity and increased smart-
phone penetration, RAN14.0 3900 series base stations provide the following solutions:
Adds the UMPT and UTRPc boards, improving the capability of a single base station to process
signaling
Adds the WBBPf board, improving uplink and downlink CE processing capabilities of a BBU3900
Supports BBU3900 interconnection, expanding specifications of a single base station
3900 series base stations are classified into the DBS3900, BTS3900, BTS3900A, and BTS3900L. Table
1-10 lists the capacity specifications of a single base station with different BBU3900 configurations.
Table 1-10 Capacity specifications of a single 3900 series base station with different BBU3900
configurations
BBU3900 Maximum Maximum Maximum Maximum
Configuration Number of Number of Number of CNBAP/s
Uplink CE Downlink CE Cells
Resources Resources
One BBU3900 3072 4608 24 1500
Two 5632 8448 48 1500
interconnected
BBU3900s
NOTE
For details about the specifications of 3900 series base stations, see the 3900 Series WCDMA Base Station Product
Description.
1.2.3 M2000
Compared with iManager M2000 V200R011, iManager M2000 V200R012C00 improves management
capability as follows:
For the ATAE-based multi-server load-sharing system (SLS), maximum management capability
increases from 400 equivalent network elements (NEs) (20,000 cells) to 800 equivalent NEs (40,000
cells).

RAN14.0
For the Sun-based M2000, maximum management capability remains unchanged. The M2000
manages a maximum of 2040 equivalent NEs (102,000 cells).
Performance specifications of iManager M2000 V200R012C00 remain unchanged from those of
iManager M2000 V200R011.
1.3 Hardware
1.3.1 RNC
Compared with RAN13.0 BSC6900, RAN14.0 BSC6900 introduces a new board, SAUc. Table 1-11
describes the SAUc board.
Table 1-11 SAUc board
Board Type Board Function
Name
Operation SAUc The SAUc board uses the HW69 R13 hardware version.
and It is a service perception unit and has the following
maintenance functions:
Collects raw data for the call history record (CHR).
Preprocesses raw data and saves preprocessed data.
Uploads preprocessed data to the Nastar.
This board is a mandatory component for most Nastar
features.
For details about the SAUc board, see the RAN14.0 BSC6900 UMTS product documentation.
1.3.2 NodeB
RAN14.0 NodeB includes the following hardware changes:
Ceased the support of the following models:
BBU3806C
Added the following models:
BTS3900AL. As an integrated outdoor macro base station, the BTS3900AL supports three modes
and five frequency bands for one cabinet and supports macro-coverage scenarios with multiple
modes and frequency bands.
BTS3902E. As a pico base station, the BTS3902E is used to fill the holes in coverage for hot spots.
Added the RRU3942 and RRU3926 to the DBS3900 in GUL triple-mode and GU dual-mode
applications, respectively. For details, see the RAN14.0 3900 Series WCDMA NodeB Product
Documentation.
Added the following BBU3900 boards: UMPT, UTRPc, and WBBPf. These boards are described in
Table 1-12. For details, see the RAN14.0 3900 Series WCDMA NodeB Product Documentation.

RAN14.0
Table 1-12 New BBU3900 boards

Board Type Board Function
Name
Main UMPT Provides higher signaling processing and transmission
processing capabilities than the WMPT board and supports Internet
and Protocol Security (IPSec).
transmission
Transmission UTRPc Supports FE/GE transmission and IPSec.
processing Provides higher signaling processing and transmission
capabilities than the UTRP board that supports FE/GE
transmission.
Baseband WBBPf Increases signaling processing capability and CE
processing capacity, and supports BBU interconnection and
simultaneous capacity expansion of two uplink resource
groups.
There are four types of WBBPf boards with different CE
capacity specifications in RAN14.0.
1.3.3 M2000
The iManager M2000 V200R011 hardware remains unchanged from that of iManager M2000
V200R012C00.
1.4 Implementation
1.4.1 Upgrade Path
In a live network, RAN13.0 can be upgraded to RAN14.0.
Versions earlier than RAN13.0 must be upgraded to RAN13.0 before being upgraded to RAN14.0.
1.4.2 Upgrade from RAN13.0 to RAN14.0

Before upgrading from RAN13.0 to RAN14.0, ensure that all required hardware has been installed and
licenses that allow the required network capacity have been obtained.
Then perform the upgrade in the following order:
1. Upgrade the M2000 to iManager M2000 V200R012C00.
2. Upgrade the CME to iManager M2000-CMEV200R012C00.
3. Upgrade the BSC6900 to BSC6900 V900R014C00.
4. Upgrade the NodeB to a corresponding RAN14.0 version listed in Table 1-1.
1.5 License
Compared with RAN13.0, RAN14.0 incorporates the following license changes:
Introduces an optional permanent and temporary license authorization mechanism.
Modifies license control items.

RAN14.0
1.5.1 Permanent and Temporary License Authorization Mechanism

If the permanent and temporary license authorization mechanism is not used, the license authorization
remains unchanged before and after an upgrade.
With this mechanism, temporarily licensed resources can be used until the temporary license expires.
Permanent and temporary licenses can work concurrently. Expiration of a temporary system resource
license has no effect on the availability of permanently licensed system resources.
To mitigate the impact on the network, the system displays a warning before a temporary license
expires and disables the temporary license during low traffic hours, for example, late at night.
Compared with RAN13.0, RAN14.0 enables separate management of permanent and temporary
licenses, which ensures user rights and network security.
To implement this mechanism, users need to plan and configure the cells where a temporary license is
required and load new license files. A new license must be obtained before the temporary license
expires.
For long-term use, a permanent license is required.
For short-term use, a temporary license is sufficient.
If users fail to obtain the new license before the temporary license expires, available system resources
decrease, leading to a decrease in network capacity and deterioration in performance.
For details about this mechanism, see the License Management Feature Parameter Description.
NOTE
Coverage holes will occur in areas covered only by temporary licenses if the licenses are not renewed or replaced.
1.5.2 Changes in the License

Compared with RAN13.0, RAN14.0 incorporates the following license changes:
Modified license control items for existing features, as described in Table 1-13.
Table 1-13 License control items modified or deleted in RAN14.0
Feature ID Feature Name License Change
WRFD- HSUPA Iub Flow This feature was not under license control
01061212 Control in Case of in RAN13.0. In RAN14.0, this feature is
(WRFD- Iub Congestion combined to the WRFD-010612 HSUPA
010637 in Introduction Package feature and is under
RAN13.0) license control.
WRFD-020105 Potential User This feature has been changed from an
Control optional feature to a basic feature. The
control item corresponding to this feature
has been deleted.
WRFD-021102 Cell Barring This feature has been changed from an
optional feature to a basic feature. The
control item corresponding to this feature
has been deleted.

RAN14.0
Feature ID Feature Name License Change

WRFD-010506 RAB Quality of This feature has been changed from an
Service optional feature to a basic feature. The
Renegotiation over control item corresponding to this feature
Iu Interface has been deleted.
Added license control items for new RAN14.0 features, as described in Table 1-14.
Table 1-14 License control items added to RAN14.0
Feature ID Feature Name License Configured
on
WRFD-140201 AMR Voice Quality Improvement NodeB
Based on PLVA
WRFD-140202 Control Channel Parallel Interference NodeB
Cancellation (Phase 2)
WRFD-140203 HSPA+ Uplink 23 Mbit/s per User RNC
WRFD-140204 DC-HSUPA NodeB
WRFD-140205 Voice Experience Improvement for RNC
Weak Reception UEs
WRFD-140206 Layered Paging in URA_PCH RNC
WRFD-140207 Iu/Iur Transmission Resource Pool in RNC
RNC
WRFD-140208 Iub Transmission Resource Pool in RNC
RNC
WRFD-140209 NodeB Integrated IPSec NodeB
WRFD-140210 NodeB PKI Support NodeB
WRFD-140211 Dynamic Target RoT Adjustment RNC
WRFD-140212 CE Overbooking NodeB
WRFD-140213 Intelligent Access Class Control RNC
WRFD-140218 Service-Based PS Handover from RNC
UMTS to LTE
WRFD-140219 Micro NodeB Self-Planning NodeB
WRFD-030004 Adaptive Configuration of Typical RNC
HSPA Rate
WRFD-140215 Dynamic Configuration of HSDPA RNC
CQI Feedback Period
WRFD-140216 Load-based Uplink Target BLER RNC
Configuration

RAN14.0
Feature ID Feature Name License Configured

on
WRFD-140217 Inter-Frequency Load Balancing RNC
Based on Configurable Load
Threshold
WRFD-140221 HSDPA Scheduling Based on UE NodeB
Location
WRFD-140223 MOCN Cell Resource Demarcation RNC
WRFD-140220 Intelligent Battery Management NodeB
MRFD-2210803 Dynamic MA for GU Dynamic NodeB
Spectrum Sharing (UMTS)
MRFD-221804 GSM Power Control on Interference NodeB
Frequency for GU Small Frequency
gap (UMTS)
MRFD-221602 Multi-mode BS Common IPSec NodeB
(UMTS)
WRFD-140224 Fast CS Fallback Based on RIM RNC
WRFD-150237 Horizon Beam-Width Adjustment NodeB
WRFD-150238 Azimuth Adjustment NodeB
Added a UMTS signaling capacity license, as described in Table 1-15. If the NodeB signaling
processing load exceeds 350 CNBAP/s, you can configure licenses allowing more CNBAPs to
improve the CNBAP processing capability. Each license allows for an increase of 50 CNBAP/s.
Table 1-15 New hardware capacity license in RAN14.0
Hardware Capacity License Sales Dimension
License Configured on
UMTS signaling NodeB Per 50 CNBAP/s
capacity license
1.6 Inter-NE Interface

Iu, Iub, Iur, and Uu interfaces in RAN14.0 comply with 3GPP Release 9 and earlier releases.
RAN14.0 supports the S12 interface between the RNC and the serving gateway (S-GW), which was
introduced in 3GPP Release 8. The S12 interface is used for PS handovers between UMTS and LTE
networks. With the S12 interface, user plane data can be exchanged between the RNC and the S-GW
without passing through the serving GRPS support node (SGSN).
For the impact of each feature on these interfaces, see chapter 3 "Impacts of RAN14.0 Features on
RAN13.0."

RAN14.0
1.7 Operation and Maintenance

RAN14.0 introduces new and enhanced features and internal system optimizations; therefore, MML
commands, parameters, performance counters, alarms, events, and licenses have changed.
For information about the impact of each new and enhanced feature on operation and maintenance,
see chapter 3 "Impacts of RAN14.0 Features on RAN13.0."
The operation and maintenance changes for the RNC and NodeB are closely related to the software
version. For detailed changes in a specific software version, see the corresponding documentation for
MML command and parameter changes, performance counter changes, alarm changes, event changes,
and license changes, which are included in the RNC and NodeB releases documentation.
1.8 Impact on Other NEs

No impact.

RAN14.0
Network Impact Report 2 Summary of Feature Impacts
2 Summary of Feature Impacts

A feature impact is classified as "Major" when either of the following conditions is met:
The feature requires new or additional hardware.
The feature has impacts on RAN13.0 features or NEs.
All other types of impacts are classified as "Minor".
Table 2-1 lists the impact severities of new and enhanced features in RAN14.0. For detailed information
about the impact of each feature, see chapter 3 "Impacts of RAN14.0 Features on RAN13.0."
Table 2-1 Impact severities of new and enhanced features in RAN14.0
Feature ID Feature Name Impact New or Basic or
Severity Enhanced Optional
WRFD- System Improvement for Major New Basic
140101 RAN14.0
WRFD- CS Fallback Guarantee for Minor New Basic
140102 LTE Emergency Calls
WRFD- Outer Loop Power Control Minor Enhanced Basic
020503
WRFD- One Tunnel Minor Enhanced Optional
020111
WRFD- Independent Demodulation Minor Enhanced Optional
021350 of Signals from Multiple
RRUs in One Cell
MRFD- Link aggregation Minor Enhanced Basic
210103
WRFD- Adaptive Configuration of Minor New Optional
030004 Typical HSPA Rate
MRFD- Fault Management Minor Enhanced Basic
210304
WRFD- AMR Voice Quality Minor New Optional
140201 Improvement Based on
PLVA
WRFD- HSUPA UE Category Minor Enhanced Optional
01061201 Support
WRFD- Control Channel Parallel Minor New Optional
140202 Interference Cancellation
(Phase 2)
WRFD- HSPA+ Uplink 23 Mbit/s Minor New Optional
140203 per User
WRFD- DC-HSUPA Minor New Optional
140204

RAN14.0

WRFD- Voice Experience Major New Optional
140205 Improvement for Weak
Reception UEs
WRFD- Layered Paging in Major New Optional
140206 URA_PCH
WRFD- Iu/Iur Transmission Major New Optional
140207 Resource Pool in RNC
WRFD- Iub Transmission Resource Major New Optional
140208 Pool in RNC
WRFD- NodeB Integrated IPSec Major New Optional
140209
WRFD- NodeB PKI Support Major New Optional
140210
WRFD- Inter Frequency Load Minor Enhanced Optional
020103 Balance
WRFD- Multi Frequency Band Minor Enhanced Optional
020110 Networking Management
WRFD- Enhanced Multiband Minor Enhanced Optional
020160 Management
WRFD- Dynamic Target RoT Minor New Optional
140211 Adjustment
WRFD- CE Overbooking Minor New Optional
140212
WRFD- Intelligent Access Class Minor New Optional
140213 Control
WRFD- Service-Based PS Minor New Optional
140218 Handover from UMTS to
LTE
WRFD- Micro NodeB Self-Planning Minor New Optional
140219
WRFD- Dynamic Configuration of Minor New Optional
140215 HSDPA CQI Feedback
Period
WRFD- Load-based Uplink Target Minor New Optional
140216 BLER Configuration
WRFD- Inter-Frequency Load Minor New Optional
140217 Balancing Based on
Configurable Load
Threshold

RAN14.0

WRFD- HSDPA Scheduling Based Minor New Optional
140221 on UE Location
WRFD- Adaptive Adjustment of Minor New Optional
140222 HSUPA Small Target
Retransmissions (Try)
WRFD- MOCN Cell Resource Minor New Optional
140223 Demarcation
WRFD- Intelligent Battery Minor New Optional
140220 Management
MRFD- Dynamic MA for GU Minor New Optional
221803 Dynamic Spectrum Sharing (GU)
(UMTS)
MRFD- GSM Power Control on Minor New Optional
221804 Interference Frequency for (GU)
GU Small Frequency gap
(UMTS)
MRFD- Multi-mode BS Common Major New Optional
221602 IPSec (UMTS) (GUL)
MRFD- IP-Based Multi-mode Co- Minor Enhanced Optional
221501 Transmission on BS side (GUL)
(NodeB)
MRFD- IP-Based Multi-mode Minor Enhanced Optional
211601 Common Clock on BS side (GUL)
(NodeB)
MRFD- Bandwidth sharing of Minor Enhanced Optional
221505 MBTS Multi-mode Co- (UL)
Transmission (NodeB)
MRFD- Multi-mode BS Common Minor Enhanced Optional
221601 Reference Clock (NodeB) (GUL)
WRFD- Inter-Frequency Minor New Optional
02040005 Redirection Based on
Distance
WRFD- Fast CS Fallback Based on Minor New Optional
140224 RIM
WRFD- Fast Return from UMTS to Minor New Try
140226 LTE
WRFD- Horizontal Beamwidth Major New Optional
150237 Adjustment
WRFD- Major New Optional
150238 Azimuth Adjustment

RAN14.0

WRFD- Minor New Basic
140103 Call Reestablishment
WRFD- Enhanced Combined Minor New Basic
140104 Services

RAN14.0
Network Impact Report 3 Impacts of RAN14.0 Features on RAN13.0
3 Impacts of RAN14.0 Features on RAN13.0

This chapter describes how the new and enhanced features in RAN14.0 affect RAN13.0 from the
perspectives of capacity, performance, interfaces, and operation and maintenance. This chapter also
describes the dependencies of these features on other features, hardware, and NEs.
3.1 WRFD-140101 System Improvements for RAN14.0

(New/Basic)
3.1.1 Description
This feature is new in RAN14.0.
RAN14.0 has the following system enhancements and improvements compared with RAN13.0:
Support for new features specified in 3GPP Release 9 (March 2010) and all later releases
Improved NodeB capacity. For details, see section 1.2 "Capacity and Performance."
Improved downlink-CE resource sharing.
The maximum number of downlink CEs that can be used by each cell in a downlink resource group
cannot exceed the total number of downlink CEs supported by multiple boards in this group. The
number of CEs that can be shared between boards is limited by hardware capacity. For cells set up
on the WBBPb, WBBPd, or WBBPf1 board, the maximum number of downlink CEs that can be used
by each cell is 384. For cells set up on the WBBPf2, WBBPf3, or WBBPf4 board, the maximum
number of downlink CEs that can be used by each cell is 768.
Improved RNC signaling processing capability and specifications. For details, see section 1.2
"Capacity and Performance."
Enhanced system maintainability.
3.1.2 Capacity and Performance

System Capacity
See section 1.2 "Capacity and Performance" for details.
Network Performance
See section 1.2 "Capacity and Performance" for details.
3.1.3 Impact on NEs

This feature is implemented on the RNC, NodeB, and M2000.
3.1.4 Hardware
See section 1.3 "Hardware" for details.
3.1.5 Inter-NE Interface

See section 1.6 "Inter-NE Interface" for details.

RAN14.0
3.1.6 Operation and Maintenance

License
This feature is a basic feature and is not under license control.
Configuration Management
No impact.
Performance Management
No impact.
Fault Management
No impact.
3.1.7 Impact on Other Features

No impact.
3.2 MRFD-210304 Enhanced Fault Management

(Enhanced/Basic)
3.2.1 Description
This feature is enhanced in RAN14.0.
When services on the RNC are interrupted, operation and maintenance (O&M) personnel cannot
quickly locate faulty network elements (NEs) or boards. Therefore, O&M personnel cannot restore RNC
services by taking conventional measures, such as resetting, powering off, or replacing NEs or boards.
To address this issue, Huawei introduces the Enhanced Fault Management feature.
This feature incorporates a database, which is based on the experience of O&M experts and includes
various diagnostics for the following types of faults:
CS access failure
CS call drop
CS-traffic-related fault
Health check failure
Paging failure
PS access failure
PS call drop
PS-streaming-related fault
RRC connection failure
O&M personnel must specify a fault type when using this feature. Based on statistics and logs collected
from the problem site, this feature quickly analyzes the fault and provides an analysis report to O&M
personnel.
With this feature, O&M personnel can quickly locate and rectify faults, critical network problems can be
avoided, and O&M costs can be reduced.

RAN14.0

System Capacity
No impact.
Network Performance
No impact.
3.2.3 Impact on NEs

Enhanced Fault Management is implemented on the RNC and RNC local maintenance terminal (LMT).
3.2.4 Hardware
No impact.

No impact.

License
This feature is not under license control.
Enhanced Fault Management introduces two RNC-level commands.
Table 3-1 New commands on the RNC side
Change Type MML Description
Command
Added STR FMAANA The command is used to start a Fault
command Management Assistant (FMA) thread.
Added SET FMATH The command is used to set the FMA threshold.
command
No impact.
Fault Management
To activate Enhanced Fault Management, perform the following operations:
Step 1 Log in to the RNC LMT and click the Device Maintenance tab.
Step 2 In Device Navigation Tree, right-click the BSC node and choose Fault Management
Assistant from the shortcut menu. Figure 3-1 shows the results of the operations described in
steps 1 and 2.

RAN14.0
Figure 3-1 Results of operations
----End

No impact.
3.3 WRFD-021350 Independent Demodulation of Signals from

Multiple RRUs in One Cell (Enhanced/Optional)
3.3.1 Description
In RAN13.0, this feature operates with the fixed setting of two receive (RX) antennas. This setting may
affect uplink coverage in indoor coverage scenarios where RRUs are configured with a single RX
antenna. This feature is enhanced in RAN14.0 to address this issue. In RAN14.0, an RRU can be
configured with one or two RX antennas when multiple RRUs are configured in one cell. That is, RRUs
configured with a single RX antenna can work with RRUs configured with two RX antennas in one cell.
When compared with the existing scheme of multiple RRUs in one cell with digital combination and
division, this enhanced feature in RAN14.0 prevents rise over thermal (RoT) and mutual interference
caused by a mixture of RX signals received at multiple antennas. Therefore, the uplink coverage and
throughput of the cell are improved. This enhanced feature in RAN14.0 applies to the indoor and tunnel
coverage scenarios where RRUs are configured with a single RX antenna. This enhanced feature also
applies to in-depth coverage scenarios already supported by RAN13.0, such as high-speed railways,
freeways, F1 racing arenas, and residential areas.

System Capacity
In the indoor and tunnel coverage scenarios where RRUs are configured with single RX antennas, this
feature improves the uplink coverage and throughput of the cell, when compared with the scheme of
multiple RRUs in one cell with digital combination and division.
Network Performance
In the indoor and tunnel coverage scenarios where RRUs are configured with single RX antennas, this
feature increases the access success rate and lowers the call drop rate in unfavorable radio
environments, when compared with the scheme of multiple RRUs in one cell with digital combination
and division.

RAN14.0
3.3.3 Impact on NEs

This feature is implemented on the NodeB.
3.3.4 Impact on Hardware

Only the DBS3900 equipped with the WBBPb, WBBPd, or WBBPf board supports this feature. The
BTS3902E does not support this feature.
In the indoor and tunnel coverage scenarios where RRUs are configured with single RX antennas,
consider the following before replacing the existing scheme of multiple RRUs in one cell with digital
combination and division with this feature:
A maximum of six RRUs can be configured in one cell.
The feature specifications depend on the type of the baseband processing board. For details, see the
SRAN7.0&GBSS14.0&RAN14.0&eRAN3.0 DBS3900 Configuration Principles.

No impact.

License
This feature is under license control. The feature enhancement in RAN14.0 has no impact on the
license.
No impact.
No impact.
Fault Management
No impact.

This feature cannot be used together with the following functions or features:
Actual service load reporting sub-function of the load measurement function
Dynamic Configuration of HSDPA CQI Feedback Period
Extended Cell Coverage up to 200km
4-Way Receive Diversity
Frequency Domain Equalization
Load-based Uplink Target BLER Configuration
MIMO
Transmit Diversity
Uplink Enhanced CELL_FACH

RAN14.0
3.4 WRFD-020111 One Tunnel (Enhanced/Optional)

3.4.1 Description
On the UMTS network, this feature provides PS services with a direct tunnel on the user plane between
the RNC and the GGSN. This feature is enhanced in RAN14.0. The S12 interface has been added for
UMTS/LTE interoperability. This interface provides a direct tunnel for the user-plane data of PS services
between the RNC and the S-GW.
Figure 3-2 Networking over the S12 interface

System Capacity
No impact.
Network Performance
No impact.
3.4.3 Impact on NEs

The functionality of the S12 interface is implemented on the RNC.
If the S12 interface needs to be deployed, the S-GW must also support the S12 interface.

No impact.

The S12 interface has been added. This interface complies with the GTP-U protocol.

RAN14.0

License
This feature is under license control. The feature enhancement in RAN14.0 has no impact on the
license.
The configuration of the S12 interface in RAN14.0 is similar to the configuration for the WRFD-020111
One Tunnel feature in earlier versions.
With the newly introduced S12 interface in the enhanced feature, the parameter in Table 3-2 has been
changed on the RNC side.
Table 3-2 Parameter that has been modified on the RNC side
Change Paramete MML Description
Type r ID Comman
d
Modified SGSNFL ADD This parameter specifies whether the peer
parameter G ADJNOD node of the RNC is the SGSN, GGSN, or
E S-GW. This parameter is valid only when
the node type NODET is IUPS.
In RAN14.0, the value range of this
parameter changes. If this parameter is set
to NO, the peer node is GGSN or S-GW. In
earlier versions, if this parameter is set to
NO, the peer node can only be GGSN.
No impact.
Fault Management
No impact.

No impact.
3.5 MRFD-210103 Link Aggregation (Enhanced/Basic)

3.5.1 Description
A link aggregation group (LAG) works in either active/standby mode or load sharing mode. RAN14.0
has enhanced link aggregation on the RNC:
When a LAG works in active/standby mode, IP performance monitoring (IP PM) is available.
When a LAG works in load sharing mode, IP PM is supported within the Iub interface transmission
resource pool only if all the links in the LAG come from the same interface board.

RAN14.0
When a LAG created by means of manual aggregation works in active/standby mode and in non-
revertive mode, the active port supports bidirectional forwarding detection (BFD) and Address
Resolution Protocol (ARP) detection. The standby port supports only ARP detection. Active/standby
switchovers are performed based on the detection results.
Link aggregation complies with IEEE 802.3ad.

System Capacity
No impact.
Network Performance
No impact.
3.5.3 Impact on NEs

This feature is implemented on the RNC.
The feature enhancement requires support from peer-end intermediate devices, such as switches.

The feature enhancement applies to the BSC6900.

This feature has no impact on inter-NE interfaces.

License
This feature has an impact on the following RNC MML commands and parameters:
The SWP ETHTRKLNK command has been added. This command is used to force switchovers
between links in a LAG.
The following parameters have been added:
Table 3-3 New parameters on the RNC side
Parameter ID MML Command Description
WORKMODE STR IPCHK Working mode of the LAG
CHKTYPE STR IPCHK Detection mode of the LAG
WHETHERAFFEC STR IPCHK Whether port switchovers are affected
TSWAP
BAKIP STR IPCHK IP address of the standby port

RAN14.0

BAKMASK STR IPCHK Subnet mask for the IP address of the
standby port
The feature enhancement in RAN14.0 has no impact on counters.
Fault Management
The feature enhancement in RAN14.0 introduces the EVT-22863 Active/Standby Trunk Port Switchover
at the RNC.

No impact.
3.6 WRFD-030004 Adaptive Configuration of Typical HSPA Rate

(New/Optional)
3.6.1 Description
This feature is new in RAN14.0 and applies only to PS best effort (BE) services, including interactive
and background services.
With HSPA, mobile operators can provide services with various traffic rates. This is beneficial to mobile
operators in many cases, such as when competing with fixed-line operators and when justifying service
fees. The typical traffic rates configured at the RNC, however, are fixed and separated and may be
inconsistent with the maximum bit rates (MBRs) configured by mobile operators at the CN. Without
Adaptive Configuration of Typical HSPA Rate, the RNC selects a typical traffic rate closest to the MBR
assigned by the CN if this MBR cannot be mapped onto any of the typical traffic rates configured at the
RNC. As a result, the rate used by the UE is inconsistent with that propagated by mobile operators,
which can affect brand image.
With this feature, the RNC uses the MBR assigned by the CN to calculate the actual maximum traffic
rate when the MBR cannot be mapped onto any of the typical traffic rates.
This feature enables mobile operators to quickly and flexibly provide services with various traffic rates,
facilitating new network expansion and increasing revenue.
This feature is applicable only to PS BE services over HSPA channels.

System Capacity
No impact.
Network Performance
This feature ensures that the actual maximum traffic rate of the HSPA UE is consistent with the MBR
assigned by the CN.
With this feature:

RAN14.0
The actual maximum traffic rate of the UE increases if the MBR assigned by the CN becomes higher
than the typical traffic rates configured at the RNC.
The actual maximum traffic rate of the UE decreases if the MBR assigned by the CN becomes lower
than the typical traffic rates configured at the RNC.
3.6.3 Impact on NEs

This feature is implemented on the RNC and NodeB.
3.6.4 Hardware
The following requirements must be met:
The BTS3812E, BTS3812A, and BTS3812AE must be configured with the EBBI, EBOI, EULP +
EDLP, or EULPd + EDLP boards. Downlink services must be established on the EBBI, EBOI, or
EDLP board.
The DBS3800 must be configured with the EBBC or EBBCd board. Downlink services must be
established on the EBBC or EBBCd board.
The 3900 series base stations must be configured with the WBBPb, WBBPd, or WBBPf board.
Downlink services must be established on the WBBPb, WBBPd, or WBBPf board.

No impact.

License
An RNC-level license for this feature is added on the RNC side.
This feature is configured at the RNC. This feature adds a new switch on the RNC.
Table 3-4 New switch on the RNC side
Change Switch Parameter MML Description
Type ID Command
Added HSPA_AD PcSwitch SET This switch specifies whether
switch PTIVE_RA UCORRMA to enable this feature. The
TE_ALGO LGOSWITC value 0 indicates that the
_SWITCH H switch is turned off. The
value 1 indicates that the
switch is turned on. The
switch is turned on by
default.
No impact.

RAN14.0
Fault Management
No impact.

This feature depends on the following features:
WRFD-010610 HSDPA Introduction Package
WRFD-010612 HSUPA Introduction Package
3.7 WRFD-140206 Layered Paging in URA_PCH (New/Optional)

3.7.1 Description
With the rapid growth of smartphones in recent years, PS paging messages have accounted for an
increasingly large proportion of all paging messages.
Normally, the RNC pages UEs in the URA_PCH state in the entire UTRAN registration area (URA).
When Layered Paging in URA_PCH is activated, the RNC first pages a UE in the URA_PCH state in
the last camped-on cell and its neighboring cells under the same RNC. If the first-layer paging fails, the
RNC then pages the UE in the entire URA. This reduces the number of paging messages and the
possibility of PCH congestion and eliminates the need for manually dividing the URA.
The benefits of this feature are as follows:
Reduced number of paging messages
Decreased signaling overheads
Lowered probability of PCH congestion
The RNC must page a UE in the URA_PCH state in the entire URA because the RNC does not know
which cell the UE camps on. This results in a large number of unnecessary paging messages, which
can in turn lead to PCHs congestion, especially with the continuously increasing number of
smartphones in use.
To address this issue, Huawei introduces this feature based on the mobility regularity of UEs in the
URA_PCH state.
This feature enables the RNC to first page a UE in the URA_PCH state in the last camped-on cell and
its neighboring cells under the same RNC. If the RNC does not receive any response from the UE, the
RNC then pages the UE in the entire URA.

System Capacity
This feature can increase PCH capacity if the URA_PCH state has been enabled before Layered
Paging in URA_PCH is activated.
Network Performance
The delay is prolonged when the first-layer paging fails. The period of delay depends on the settings of
DRXCycleLenCoef and DrxCycleLenCoef. For example, if the calculated DRX cycle is 640 ms, the
longest delay is 1.2s.

RAN14.0
3.7.3 Impact on NEs

3.7.4 Hardware
No impact.

No impact.

License
Layered Paging in URA_PCH is controlled by a new license at the RNC level.
Table 3-5 lists the new switches on the RNC side.
Table 3-5 New switches on the RNC side
Type ID Command
Added URAPCH_LAY PROCESSS SET The switch controls
switch ERED_PAGIN WITCH URRCTRLS Layered Paging in
G_RT_SWITC WITCH URA_PCH for real-time
H services.
Added URAPCH_LAY The switch controls
switch ERED_PAGIN Layered Paging in
G_NRT_SWIT URA_PCH for non-
CH real-time services.
It is recommended that one RNC be configured with only one URA to facilitate RNC configuration and
that neighboring RNCs be configured with different URA IDs to avoid the load over the Iur interface.
Table 3-6 provides information about the RNC counters newly introduced with this feature.
Table 3-6 New counters on the RNC side
Counter Measuremen Description
t Unit
VS.Paging1.Att1.UR PAGE.CELL Number of Level-1 Paging Attempts for
A.RealTime.Cell UEs Processing Real-Time Services in
the URA_PCH State for Cell
VS.Paging1.Succ1. PAGE.CELL Number of Successful Level-1 Paging
URA.RealTime.Cell Attempts for UEs Processing Real-Time
Services in the URA_PCH State for Cell

RAN14.0
Counter Measuremen Description

t Unit
VS.Paging1.Att1.UR PAGE.CELL Number of Level-1 Paging Attempts for
A.NoneRealTime.C UEs Processing Non-Real-Time Services
ell in the URA_PCH State for Cell
VS.Paging1.Succ1. PAGE.CELL Number of Successful Level-1 Paging
URA.NoneRealTime Attempts for UEs Processing Non-Real-
.Cell Time Services in the URA_PCH State for
Cell
VS.Paging1.TotalSu PAGE.CELL Number of Successful Layered Paging
cc.URA.RealTime.C Attempts for UEs Processing Real-Time
ell Services in the URA_PCH State for Cell
VS.Paging1.TotalSu PAGE.CELL Number of Successful Layered Paging
cc.URA.NoneRealTi Attempts for UEs Processing Non-Real-
me.Cell Time Services in the URA_PCH State for
Cell
Fault Management
No impact.

Before activating Layered Paging in URA_PCH, ensure that the URA_PCH state has been enabled.
This state can be enabled by setting inactivity timers and parameters related to the F2P and P2U state
transitions.
It is recommended that the WRFD-020500 Enhanced Fast Dormancy feature be activated and
parameters related to the D2F state transition be set to enable smartphones to enter the URA_PCH
state if possible.
The WRFD-020134 Push to Talk feature is generally used together with the Enhanced PCH (E-PCH)
function to shorten the delay. However, E-PCH-capable UEs must enter the CELL_PCH state for a
short delay. Therefore, it is recommended that Layered Paging in URA_PCH not be used together with
Push to Talk.
3.8 WRFD-140213 Intelligent Access Class Control

(New/Optional)
3.8.1 Description
This feature prevents a large number of UEs from sending RRC connection setup requests
simultaneously. When the RNC determines that a cell is congested, the RNC performs access control
on more access classes (ACs). When the RNC determines that congestion is relieved in the cell, the
RNC performs access control on fewer ACs.
This feature prevents excessive RRC connection setup requests from wasting air interface resources
and RNC signaling resources, relieves network congestion, and improves system stability.

RAN14.0

System Capacity
When a cell is critically congested, this feature helps reduce the number of RRC connection setup
requests, saving system resources and possibly increasing the valid capacity of the cell.
Network Performance
When a cell is congested, this feature prevents cell congestion from getting worse, which improves
system stability. By reducing the number of RRC connection setup requests, this feature also increases
the RRC connection setup success rate and radio access bearer (RAB) setup success rate.
This feature provides differentiated services by preferentially ensuring CS services. However, when the
proportion of UEs complying with versions earlier than 3GPP Release 6 is large on the live network, CS
services cannot be effectively ensured, because access control cannot be performed on CS and PS
services separately for such UEs.
This feature adversely affects network performance as follows:
When access control is performed on an access class, UEs from this access class cannot initiate the
corresponding services, which may affect user experience.
This feature cannot be performed on a per operator basis. Therefore, in multi-operator networking
scenarios, such as Multi-Operator Core Network (MOCN), the congestion on one operator's network
may lead to access control on UEs of other operators.
This feature does not apply to PS services initiated by UEs in the CELL_PCH and URA_PCH states.
If there are a large number of such UEs on the live network and cell congestion is caused by overflow
of these PS services, this feature cannot take much effect.
When the RNC dynamically adjusts the number of barred ACs, different proportion of UEs on the live
network will be barred and the KPIs may fluctuate. Assume that the UEs are evenly distributed across
ACs 0 to 9, the unit of AC control is 10% when the number of barred ACs is increased or decreased.
The KPI fluctuation is especially evident when the UEs on the live network are not evenly distributed
across ACs 0 to 9 or in heavy traffic hours. In this case, the feature performance attenuates.
3.8.3 Impact on NEs

This feature requires UEs to meet the following requirements:
UEs must support access control indications delivered in System Information Block Type 3 (SIB 3)
messages.
For UEs complying with versions earlier than 3GPP release 6, access control cannot be performed on
CS and PS services separately. If the access class of such a UE is barred, the UE cannot initiate CS
or PS services.
For UEs complying with 3GPP release 6 and later, access control can be performed on CS and PS
services separately. Therefore, a UE can initiate CS services while being barred from initiating PS
services or initiate PS services while being barred from initiating CS services.
3.8.4 Hardware
No impact.

No impact.

RAN14.0

License
An RNC-level license for this feature is added on the RNC side.
The commands in Table 3-7 have been added to the RNC.
Change MML Description
Type Command
Added ADD This command is used to add the configuration of
command UCELLCONG the Intelligent Access Class Control feature.
ACALGO
Added LST This command is used to query the configuration of
ACALGO
Added MOD This command is used to modify the configuration of
ACALGO
Added RMV This command is used to remove the configuration
command UCELLCONG of the Intelligent Access Class Control feature.
ACALGO
Table 3-8 lists the key parameters of the ADD UCELLCONGACALGO and MOD
UCELLCONGACALGO commands.
Change Parameter ID Description
Type
Added CongACSwit Switch for Intelligent Access Class Control.
parameter ch
Added CongOfRAB Whether to consider the RAB setup request
parameter RejRateSwitc rejection rate when making cell congestion
h decisions.
Added CongOfUlLo Whether to consider UL load when making cell
parameter adSwitch congestion decisions.
Added CongRejTrig Threshold for cell congestion with the RRC or RAB
parameter Thd setup request rejection rate. When RRC or RAB
setup request rejection rate in a cell is equal to or
higher than this threshold, the BSC6900 regards the
cell as being congested.

RAN14.0
Change Parameter ID Description

Type
Added CongRejRelT Threshold for cell resource restoration with the RRC
parameter hd or RAB setup request rejection rate. When this
threshold is not exceeded, the BSC6900 regards the
cell as not being congested.
Added CongCheckP Cell congestion check interval. The BSC6900
parameter eriod checks whether cells are congested at this interval.
Added ACPollPeriod Polling interval for access control.
parameter
Added ACRstrctRan Range of restricted access classes.
parameter ge
Added RstrctR6PSM Maximum number of restricted access classes. This
parameter axACNum parameter is used when UEs of R6 or later initiate
PS-oriented RRC connection requests. When this
parameter is set to 0, no access classes are
restricted.
Added RstrctR5Max Maximum number of restricted access classes. This
parameter ACNum parameter is used when UEs of R5 or earlier initiate
RRC connection requests. When this parameter is
set to 0, no access classes are restricted.
Added RstrctR6CSM Maximum number of restricted access classes. This
parameter axACNum parameter is used when UEs of R6 or later initiate
CS-oriented RRC connection requests. When this
parameter is set to 0, no access classes are
restricted.
Added UlLoadCong Uplink cell power load threshold for cell congestion.
parameter TrigThd When uplink power load in a cell is equal to or
higher than this threshold, the BSC6900 regards the
cell as being congested due to high uplink cell
power load.
Added UlLoadCong Uplink cell power load threshold for cell resource
parameter RelThd restoration. When this threshold is not exceeded,
the BSC6900 regards the cell as being not
congested due to reduced uplink cell power load.
Added CongOfCpuS Whether to consider CPU usage when making cell
parameter witch congestion decisions.
Added CpuCongTrig CPU usage threshold for cell congestion. When
parameter Thd CPU usage on an SPU subsystem is equal to or
higher than threshold, the BSC6900 regards cells
served by the SPU subsystem as being congested.
Added CpuCongRel CPU usage threshold for cell resource restoration.
parameter Thd When CPU usage on an SPU subsystem is lower
than this threshold, the BSC6900 regards cells
served by the SPU subsystem as not being
congested.

RAN14.0
Table 3-9 lists the counters have been added to the RNC.
Counter Measurement Description
Unit
VS.AC.CongCtl.M ALGO2.Cell Mean Number of PS Access Classes
eanAcBarNum.Ab Restricted Due to Cell Resource
oveR6.PS Congestion (R6 or Later)
VS.AC.CongCtl.M ALGO2.Cell Mean Number of Access Classes
eanAcBarNum.Un Restricted Due to Cell Resource
derR5 Congestion (R5 or Earlier)
VS.AC.CongCtl.M ALGO2.Cell Mean Number of CS Access Classes
eanAcBarNum.Ab Restricted Due to Cell Resource
oveR6.CS Congestion (R6 or Later)
VS.AC.CongCtl.Ti ALGO2.Cell Duration of Access Class Restriction
me Triggered by Cell Resource Congestion
VS.RRC.AttConnE RRC.Setup.Cell Number of RRC Connection Setup
stab.PSDomain Requests for Cell (PS Domain)
VS.RRC.AttConnE RRC.Setup.Cell Number of RRC Connection Setup
stab.CSDomain Requests for Cell (CS Domain)
Fault Management
This feature adds a cause value to a new RNC alarm, as shown in Table 3-10.
Table 3-10 New alarm on the RNC side
Change Alarm NE Description
Type
Added alarm ALM-22238 Service RNC Cause value "Access class
Flow Control in a Cell control" works for this feature.

Besides Intelligent Access Class Control, the WRFD-021103 Access Class Restriction and WRFD-
020114 Domain Specific Access Control features also perform access control on ACs. For details, see
the DSAC Feature Parameter Description.
There are no dependencies between these three features. Any feature can be independently enabled or
disabled.
These three features function independently and they interact only in SIB 3 broadcasting. The ACs
controlled by these features are consolidated into a single list and then broadcast in the SIB 3 message.

RAN14.0
3.9 WRFD-140201 AMR Voice Quality Improvement Based on

PLVA (New/Optional)
3.9.1 Description
AMR is a speech coding standard widely used in GSM and UMTS communications systems. In UMTS,
convolutional codes are used to perform channel encoding and a power control mechanism is used to
ensure voice quality.
Figure 3-3 Channel encoding and power control for UMTS AMR voice services in the uplink
Most vendors use the Viterbi algorithm to decode convolutional codes. The Viterbi algorithm selects the
optimal path based on the maximum likelihood theory and exports the data decoded on the optimal path.
If the decoded data fails the cyclic redundancy check (CRC), the AMR speech codec usually discards
the data, and voice quality deteriorates as a result.
Huawei uses the PLVA to decode convolutional codes. The PLVA is an enhanced CRC-assisted Viterbi
algorithm. Instead of selecting only the top 1 optimal path, the PLVA selects the top N optimal paths and
performs CRC on the data decoded on these paths. The PLVA only exports data that passes the CRC.
If the data decoded on these paths fails the CRC, the PLVA only exports the data decoded on the
optimal path. In simulations where the PLVA selects four paths, the signal-to-noise ratio (SNR) is 0.2 to
0.8 dB better than that produced by the Viterbi algorithm.
This feature increases the mean opinion score (MOS) of AMR voice services, including narrowband and
wideband AMR voice services. Take 12.2 kbit/s AMR voice services as an example. In the uplink
simulations, if the BLER is 1%, the MOS is increased by about 0.08; if the BLER is greater than 10%,
the MOS is increased by about 0.35. (The BLER increase is generally caused by UE power limitation,
fast channel change, or strong interference.) Generally, the larger the BLER, the greater the MOS
increase produced by the PLVA. In addition, the MOS increase is generally the same under different
channel fading conditions.

RAN14.0
Figure 3-4 Different MOSs for 12.2 kbit/s AMR voice services on TU50 channels with different BLERs

System Capacity
No impact.
Network Performance
This feature improves the MOS of AMR voice services, especially the MOS of AMR voice services in
weak coverage areas.
3.9.3 Impact on NEs

This feature is implemented on the RNC and NodeB and does not affect the UE and CN.
3.9.4 Hardware
The PLVA applies only to the AMR voice services carried on the WBBPd1, WBBPd2, WBBPd3, EBBCd,
EULPd, WBBPf1, WBBPf12, WBBPf3, and WBBPf4 boards. To implement this feature, the following
requirements must be met:
The BTS3812E, BTS3812A, and BTS3812AE must be configured with the EULPd board.
The BBU3806 must be configured with the EBBCd board.
The BBU3900 must be configured with the WBBPd or WBBPf board.
The BTS3902E must support this feature.
When the EULPd, EBBCd, WBBPd, or WBBPf board is installed in the same subrack as other types of
baseband board, AMR voice services may not be established on the EULPd, EBBCd, WBBPd, or
WBBPf board and therefore cannot use this feature.

A private information element (IE) has been added to the FP frame from the NodeB to the RNC over
the Iub interface. The IE carries the PLVA CRCI.

RAN14.0

License
This feature is controlled by a new NodeB-level license item on the NodeB.
No impact.
This feature adds a new counter on the NodeB, as shown in Table 3-11.
Table 3-11 New counter on the NodeB side
Unit
VS.PLVA ALGO.LOCELL This counter is to measure the number of UEs using
.User this feature in a cell.
This counter is measured on a per cell basis. At the
end of a measurement period, the RNC divides the
total number of UEs using this feature by the
number of samples to obtain the mean number of
UEs using this feature in a cell.
Fault Management
No impact.

No impact.
3.10 WRFD-140205 Voice Service Experience Improvement for

Weak Reception UEs (New/Optional)
3.10.1 Description
UEs with poor signal receiving capability are prone to drops of CS voice services. This feature enables
the radio network controller (RNC) to identify weak reception UEs based on the International Mobile
Station Equipment Identity Type Allocation Code (IMEI TAC) and assign them dedicated radio
performance parameters, including radio link (RL) power control and handover parameters. This
reduces the call drop rate and improves user experience.

System Capacity
The RNC configures a high RL DL transmit power for weak reception UEs, which increases the transmit
power in the cell. When a cell has fixed DL transmit power, this feature imposes impacts on cell capacity
and HSDPA throughput. This section describes the impacts based on the following simulations
conducted by Huawei:

RAN14.0
There is one HSDPA cell.

Two HSDPA UEs of category 10 are processing downlink services at the center of the cell, and the
channel quality indicator (CQI) is around 30.
UEs processing adaptive multi-rate (AMR) services are located at the cell edge (the Ec/N0 is -16 dB).
The maximum RL DL transmit power remains unchanged (the same as that configured for ordinary
UEs) or increases by 3 dB (3 dB higher than that configured for ordinary UEs).
Table 3-12 lists the simulation results.
Table 3-12 Impact of this feature on cell capacity and HSDPA throughput based on Huawei simulations
Number of HSDPA HSDPA Throughput Cell Capacity Throughput
UEs Throughput After a 3-dB Increase Reduction Reduction
Processing (kbit/s) in the Maximum RL DL Percentage After Percentage
AMR Transmit Power for the Increase After the
Services at UEs Processing AMR Increase
the Cell Edge Services (kbit/s)
1 9062.0 9048.8 0.23% 0.15%
2 8926.2 8867.9 1.83% 0.65%
4 8701.1 8570.3 3.62% 1.50%
8 8107.1 7737.0 12.10% 4.57%
The simulation results show that this feature has a small impact on cell capacity and throughput.
Network Performance
This feature reduces the call drop rate of weak reception UEs and improves user experience of CS
voice services.
3.10.3 Impact on NEs

This feature is implemented on the RNC and has no impact on UEs, NodeBs, and CNs.
3.10.4 Hardware
No impact.

No impact.

License
This feature is controlled by a new cell-level license item on the RNC.
Table 3-13 describes the new and modified parameters related to Voice Service Experience
Improvement for Weak Reception UEs on the RNC side.

RAN14.0
Table 3-13 New and modified parameters on the RNC side

Change Parameter MML Description
Type ID Command
Added TAC_FUN ADD/MOD A switch Special_User_Enhance is added to this
switch C UIMEITAC parameter. If the switch Special_User_Enhance is
selected, the TAC specifies the UEs that are enabled
with the Special User Enhance feature.
Added SpecUserF ADD/MOD 1) SPECUSER_AMR_HOENHANCE_SWITCH
paramete unctionSwi UIMEITAC (Handover Enhanced Switch for Special UEs for
r tch Speech Quality Improvement) When this switch is
turned on, the following handover parameters are used
to improve the speech quality of special UEs:
SpecUserHystFor2D, SpecUserCSThd2DEcN0,
SpecUserCSThd2FEcN0, SpecUserCSThd2DRSCP,
SpecUserCSThd2FRSCP. When this switch is turned
off, the preceding handover parameters are not used to
improve the speech quality of special UEs.
2) SPECUSER_AMR_PWRENHANCE_SWITCH
(Power Enhanced Switch for Special UEs for Speech
Quality Improvement) When this switch is turned on,
SpecUserRlMaxDlPwr in the ADD UCELLRLPWR
command is used to perform inner-loop power control
or to improve the speech quality of special UEs. When
this switch is turned off, SpecUserRlMaxDlPwr is not
used to perform inner-loop power control and to
improve the speech quality of special UEs.
Added SpecUserP ADD/MOD Threshold for the transmit power of carriers in a cell.
paramete wrEnDlPwr UCELLLDM This threshold is considered during the setting of the
r TrigThd maximum transmit power for special UEs. When the
transmit power of carriers in a cell is lower than this
threshold, the maximum transmit power of special UEs
identified by the value of TAC in the ADD UIMEITAC
command is equal to the value of
SpecUserRlMaxDlPwr in the ADD UCELLRLPWR
command if these UEs are processing 12.2 kbit/s AMR
services. When the transmit power of carriers in the cell
exceeds this threshold, the maximum transmit power of
all UEs is equal to the value of RlMaxDlPwr in the
ADD UCELLRLPWR command.
Added SpecUserR ADD/MOD Maximum transmit power of special UEs requiring good
paramete lMaxDlPwr UCELLRLPW voice experience. This parameter applies only to 12.2
r R kbit/s AMR services.
Added SpecUserH SET Delay in reporting the 2D event. This delay is specific to
paramete ystFor2D UHOCOMM, special UEs that require high speech quality and are
r ADD/MOD requested to perform an inter-frequency or inter-RAT
UCELLHOCO handover.
MM

RAN14.0

Type ID Command
Added SpecUserC SET Ec/N0 threshold for special UEs to report the 2D event.
paramete SThd2DEc UHOCOMM, When the Ec/N0 is a triggering condition for reporting
r N0 ADD/MOD the 2D event, a special UE reports the 2D event if the
UCELLHOCO measured Ec/N0 is lower than this threshold. After the
MM UE reports the event, the RNC sends the UE a
command requesting the UE to enter the compressed
mode and measure signal quality of other frequencies.
Added SpecUserC SET Ec/N0 threshold for special UEs to report the 2F event.
paramete SThd2FEc UHOCOMM, When the Ec/N0 is a triggering condition for reporting
r N0 ADD/MOD the 2F event, a special UE reports the 2F event if the
UCELLHOCO measured Ec/N0 is higher than this threshold. After the
command requesting the UE to stop operating in
compressed mode and measuring signal quality of
other frequencies.
Added SpecUserC SET RSCP threshold for special UEs to report the 2D event.
paramete SThd2DRS UHOCOMM, When the RSCP is a triggering condition for reporting
r CP ADD/MOD the 2D event, a special UE reports the 2D event if the
UCELLHOCO measured RSCP is lower than this threshold. After the
command requesting the UE to enter the compressed
mode and measure signal quality of other frequencies.
Added SpecUserC SET RSCP threshold for special UEs to report the 2F event.
paramete SThd2FRS UHOCOMM, When the RSCP is a triggering condition for reporting
r CP ADD/MOD the 2F event, a special UE reports the 2F event if the
UCELLHOCO measured RSCP is higher than this threshold. After the
command requesting the UE to stop operating in
compressed mode and measuring signal quality of
other frequencies.
Table 3-14 provides the new counters related to Voice Service Experience Improvement for Weak
Reception UEs on the RNC side.
Unit
VS.RAB.SpecialU ALGO2.Cell This counter measures the number of CS
ser.AbnormRel.C RABs abnormally released for special UEs
S in the best cells.
VS.RAB.SpecialU ALGO2.Cell This counter measures the number of CS
ser.NormRel.CS RABs normally released for special UEs in
the best cells.

RAN14.0
Fault Management
No impact.

No impact.
3.11 WRFD-140219 Micro NodeB Self-Planning (New/Optional)

3.11.1 Description
Network planning is mandatory for WCDMA network deployment. Network planning, including site
survey and network dimensioning, is generally performed manually, which is costly and requires a
lengthy deployment schedule.
To improve the network planning efficiency and implement automatic micro NodeB deployment, Huawei
provides the feature for remote self-planning of radio parameters for the micro NodeB. These
parameters include UARFCN, scrambling code, neighbor relationships with intra-frequency neighboring
cells, inter-frequency neighboring cells, and neighboring GSM cells, LAC, SAC, and RAC of the micro
NodeB.
This feature enables the system to perform the following functions:
Collect raw data by scanning radio environments.
Sets radio parameters using radio parameter planning algorithms.
Sends the radio parameter settings to NEs through the OM channel.

System Capacity
No impact.
Network Performance
No impact.

This feature is implemented on the BTS3902E and M2000.
This feature depends on the following NEs:
The M2000 supports NodeB automatic deployment and BTS3902E WCDMA self-planning.
The RNC version must be RAN13.0 or later, and the RNC data can be configured and modified on
the M2000.
3.11.4 Hardware
This feature depends on the following NodeB hardware:
Only the BTS3902E supports this feature.
The BTS3902E must be configured with a self-organizing network (SON) receiver.

RAN14.0
If the BTS3902E uses an integrated antenna, the SON receiver antenna and the service antenna are
combined. Therefore, the SON receiver antenna does not need to be additionally configured.
If the BTS3902E uses an external antenna, the SON receiver antenna needs to be additionally
configured.

This feature impacts the OM interface:
The scanning control information, scanning results, and planned parameters are transmitted through
the OM channel between the BTS3902E and M2000.
The planned parameters are transmitted through the OM channel between the RNC and M2000.

License
This feature is controlled by a new NodeB-level license item on the micro NodeB.
The UMTS Self-Planning page has been added to the Configuration window on the M2000. This
page is used to import the operating parameters of the SON receiver, indicate self-planning progress,
and generate self-planning result reports.
In NodeB Auto Deployment on the M2000, the UMTS Self-Planning item has been added to the
Select steps to execute page, which controls whether to enable micro NodeB self-planning.
No impact.
Fault Management
The BTS3902E supports to record SON receiver operation logs, such as information about SON
receiver scanning and reporting.

WRFD-031101 NodeB Self-discovery Based on IP Mode
WRFD-031102 NodeB Remote Self-configuration
3.12 WRFD-140222 Adaptive Adjustment of HSUPA Small

Target Retransmissions(Try) (New/Optional)
3.12.1 Description
It dynamically adjusts the small target number of retransmissions based on the uplink throughput of
individual HSUPA UEs and the uplink load of the cell. This increases the uplink cell throughput.

RAN14.0

System Capacity
This feature improves the uplink performance. It is recommended that this feature be enabled if the
uplink load of the cell is restricted and there are a large number of HSUPA UEs using a 10 ms TTI. If
some UEs in the cell are engaged in continuous uploading, this feature improves the uplink throughput
by 10% to 15%. If all services in the cell are burst services, this feature lowers the received total
wideband power (RTWP) by around 0.5 dB.
Network Performance
No impact.

3.12.4 Hardware
This feature has no impact on the hardware of the RNC and NodeB.

This feature has no impact on the Uu, Iub, Iur, or Iu interfaces.

License
This is a try feature and is therefore not under license control.
This feature has an impact on the RNC parameters, as shown in Table 3-15.
Table 3-15 Parameters that have been added or modified on the RNC side
Type ID Command
Added PC_HSUPA PcSwitch SET When the UE attempts to access the
switch _LITRETNU UCORRMAL network, the larger value between
M_INIT_SE GOSWITCH EdchTargetLittleRetransNum and
L_SWITCH EdchAltTarLittleRetransNum is used
as the small target number of
retransmissions if this switch is
selected, or
EdchTargetLittleRetransNum is used
if this switch is not selected.
Added PC_HSUPA PcSwitch SET This is the switch for the algorithm for
switch _LITRETNU UCORRMAL dynamically adjusting the small target
M_AUTO_A GOSWITCH number of retransmissions for HSUPA
DJUST_SW UEs.
ITCH

RAN14.0

Type ID Command
Added - EdchAltTa ADD/MOD Like EdchTargetLittleRetransNum,
parameter rLittleRetr UTYPRABOL this parameter specifies a small target
ansNum PC number of retransmissions over the
MAC-ES flow. These two parameters
work together to improve throughput for
cells.
No impact.
Fault Management
No impact.

Required Features
This feature depends on WRFD-010612 HSUPA Introduction Package.
Mutually Exclusive Features

A cell can be simultaneously configured with the Adaptive Adjustment of HSUPA Small Target
Retransmissions feature and the DC-HSUPA feature. However, if DC-HSUPA is enabled for a UE,
Adaptive Adjustment of HSUPA Small Target Retransmissions will not work for this UE.
3.13 WRFD-140221 HSDPA Scheduling based on UE Location

(New/Optional)
3.13.1 Description
This feature builds on the EPF algorithm and considers UE locations as criteria for adjusting HSDPA
scheduling weights. This feature gives more scheduling opportunities to UEs closer to the NodeB and
increases the downlink overall throughput of the cell.

System Capacity
This feature gives more scheduling opportunities to UEs closer to the NodeB and increases the
downlink overall throughput of the cell. Cell throughput gains relate to UEs' CQIs.
Network Performance
With this feature, HSDPA UEs at cell edges have fewer scheduling opportunities and lower throughput.
If GBRs are not configured for BE services, HSDPA UEs at cell edges may have to wait a long time
before they have scheduling opportunities. As a result, traffic radio bearers (TRBs) are more likely to
reset and the call drop rate increases. The magnitude of this impact depends on factors such as UE
location distribution and service distribution in the cell. It is recommended that GBRs be configured for
BE services to ensure network performance.

RAN14.0

3.13.4 Hardware
This feature has no impact on the hardware of the RNC.
This feature depends on the NodeB hardware as follows:
All base stations of the 3900 series support this feature if configured with the WBBPb, WBBPd, or
WBBPf board.


License
This feature is controlled by a new cell-level license item on the NodeB.
This feature has an impact on the NodeB parameters, as shown in Table 3-16.
Table 3-16 Parameters that have been added or modified on the NodeB side
Change Switch Parameter MML Command Description
Type ID
Added EPF_LO SM SET Switch for the
switch C MACHSPARA HSDPA scheduling
algorithm based on
UE locations
Added - LOCWEIG SET UE location weight
parameter HT MACHSPARA
No impact.
Fault Management
The NodeB alarm ALM-26811 Configured Capacity Limit Exceeding Licensed Limit is modified to
support this feature.

WRFD-010610 HSDPA Introduction Package
WRFD-010611 HSDPA Enhanced Package

RAN14.0
3.14 WRFD-140204 DC-HSUPA (New/Optional)

3.14.1 Description
Introduced in 3GPP Release 9, Dual-Carrier HSUPA (DC-HSUPA) allows a UE to use two adjacent
carriers simultaneously in the uplink. This increases the uplink peak rate of a single UE and cell
average throughput.

System Capacity
Number of system users
In RAN14.0, the number of DC-HSUPA UEs supported by each board in a NodeB is half the number
of SC-HSUPA UEs.
System load
Carrier uplink load increases because the secondary carrier uses the DPCCH for power control. The
increase is not noticeable when there is a small number of DC-HSUPA UEs. When there are a large
number of online DC-HSUPA UEs in CELL_DCH state, the overhead for the DPCCH raises the uplink
load over the air interface.
If the WRFD-140203 HSPA+ Uplink 23 Mbit/s per User feature is enabled to reach an uplink peak
rate of 23 Mbit/s, DC-HSUPA with uplink 16QAM must be enabled on E-DCHs of the primary and
secondary uplink carriers. As a result, the load of the two carriers is relatively high.
System throughput
Theoretically, DC-HSUPA does not increase spectral efficiency, and therefore will not increase system
throughput. In the scenario where the uplink load of two carrier cells is unbalanced and fluctuates,
DC-HSUPA can increase system throughput because it allows uplink load sharing between the two
carriers, which fully utilizes uplink load resources.
When there are a large number of online DC-HSUPA UEs in CELL_DCH state, cell uplink throughput
slightly decreases because the overhead for the DPCCH of the secondary carrier raises the uplink
load.
User throughput
DC-HSUPA supports a peak rate of 23 Mbit/s for a single UE.
In a lightly loaded system where the uplink load is not limited, DC-HSUPA introduces a significant
increase in the burst data rate. The user throughput gain of DC-HSUPA will decrease as the system
uplink load increases.
With the same system uplink load, DC-HSUPA allows the UEs to reach a high data rate more easily
than uplink 16QAM and SC-HSUPA.
The maximum radio bearer throughput supported by the DC-HSUPA feature is impacted by the
following factors:
The air interface uplink RTWP/RoT of two carriers
Radio channel quality (including multipath delay, interference, and UE moving speed)
E-DCH category of the UE
Uplink 16QAM availability
Transmission
DC-HSUPA requires that the Iub interface of each NodeB support a minimum of 25 Mbit/s bandwidth.
Otherwise, a single DC-HSUPA UE cannot reach the peak rate even if other requirements are met.

RAN14.0
Network Performance
Hardware
A DC-HSUPA UE consumes one more licensed CEs than an SC-HSUPA UE.
Coverage
DC-HSUPA coverage is slightly inferior to SC-HSUPA coverage because the secondary carrier uses
the DPCCH for power control and so consumes additional uplink power. This defect can be relieved
by enabling the HSUPA TTI Selection feature or coverage-based BE service fallback from the E-DCH
to DCH algorithm.
To support a peak rate of 23 Mbit/s, the RoT threshold must be raised. A higher RoT threshold may
result in smaller cell coverage, a higher service drop rate, and a lower handover success rate. This
defect can be relieved by enabling the Dynamic Target RoT Adjustment feature. The Dynamic Target
RoT Adjustment feature minimizes the impact of a higher RoT.
Downlink code words
E-RGCHs and E-HICHs (128 SF) must be configured for primary and secondary carriers. When the
number of DC-HSUPA UEs increases, more downlink E-RGCHs and E-HICHs are required,
consuming more downlink code words. An E-RGCH or E-HICH supports a maximum of 20 DC-
HSUPA UEs on this carrier.

This feature must be supported by the UE and CN. UEs must support E-DCH category 8 or 9, and the
CN must support a UE rate of 23 Mbit/s or higher.
UEs of E-DCH category 8 do not support DC-HSUPA with uplink 16QAM. It supports only DC-HSUPA
without uplink 16QAM and a peak rate of 11.5 Mbit/s. UEs of E-DCH category 9 support DC-HSUPA
with 16QAM, with a peak rate of 23 Mbit/s.
3.14.4 Hardware
This feature has no impact on the RNC hardware.
All 3900 series base stations support this feature after WBBPb, WBBPd, or WBBPf boards are
configured.
The DBS3800 support this feature after EBBC or EBBCd boards are configured.
The BTS3812E and BTS3812AE support this feature after EBBI, EBOI, EULP, or EULPd boards are
configured and downlink cells of this feature are configured on EBBI, EBOI, or EDLP boards.
When 4-way receive diversity is used, only the 3900 series base stations (excluding the BTS3902E)
support this feature.

To support DC-HSUPA, some new information elements (IEs) are added and existing IEs are modified
in messages over the Iub and Uu interfaces.
Impact on Iub Interface

The NodeB reports cell capability to the RNC using an AUDIT RESPONSE or RESOURCE STATUS
INDICATION message if any of the following occurs:
The cell receives an AUDIT REQUEST message.

RAN14.0
A new cell is set up.

Cell capability changes.
If a cell supports DC-HSUPA, the NodeB notifies the RNC of the cell capability using the Cell Capability
Container IE in the Local Cell Information IE.
During radio link establishment, the following messages incorporate new or enhanced IEs to indicate
information about the NodeB transport bearer and secondary carrier:
RADIO LINK SETUP REQUEST
RADIO LINK SETUP RESPONSE
RADIO LINK SETUP FAILURE
RADIO LINK ADDITION REQUEST
RADIO LINK ADDITION RESPONSE
RADIO LINK ADDITION FAILURE
RADIO LINK RECONFIGURATION PREPARE
RADIO LINK RECONFIGURATION READY
The following IEs are added to the above radio link establishment messages:
Multi Cell E-DCH Capability, Separate Iub Transport Bearer Capability, and E-DCH UL Flow
Multiplexing Capability in the Cell Capability Container IE
Multicell E-DCH Transport Bearer Mode IE
Additional E-DCH FDD Setup Information IE
Additional E-DCH FDD Information IE
Multicell E-DCH Information IE
Additional E-DCH FDD Update Information IE
Additional E-DCH FDD Information Response IE
Additional E-DCH Serving Cell Change Information Response IE
Additional Modified E-DCH FDD Information Response IE
Activation Information IE
Additional E-DCH Configuration Change Information IE
Additional E-DCH RL Specific Information To Setup IE
Additional E-DCH RL Specific Information To Add IE
Additional E-DCH RL Specific Information To Modify IE
Additional E-DCH FDD Information To Modify IE
Multicell E-DCH RL Specific Information IE
In addition, the procedure of "Exchanging information about the secondary UL frequency" has been
added to Node B Application Part (NBAP) over the Iub interface. This procedure allows the controlling
radio network controller (CRNC) to exchange information about the secondary uplink carrier with the
NodeB. This procedure involves two messages:
SECONDARY UL FREQUENCY REPORT: The CRNC uses this message to inform the NodeB about
the activation status of the secondary uplink carrier of the UE.
SECONDARY UL FREQUENCY UPDATE INDICATION: The NodeB uses this message to inform the
CRNC about updates to the activation status of the secondary uplink carrier of the UE.
DC-HSUPA supports E-DCH UL flow multiplexing mode on the user plane of the Iub interface. In this
mode, the NodeB uses one transport bearer to transmit MAC-d flows from both primary and secondary

RAN14.0
carriers to the serving radio network controller (SRNC). During uplink radio link establishment on the
secondary carrier, the SRNC notifies the NodeB of transport bearer mode. The NodeB transmits MAC-d
flows in E-DCH UL DATA FRAME TYPE 2 (MAC-i) format through the primary and secondary carriers to
the SRNC on one transport bearer.
Impact on Uu Interface
The following Uu interface messages incorporate new or enhanced IEs for indicating secondary DC-
HSUPA carrier information, including the channels, RABs, and capabilities:
CELL UPDATE CONFIRM
PHYSICAL CHANNEL RECONFIGURATION
RADIO BEARER RECONFIGURATION
RADIO BEARER RELEASE
RADIO BEARER SETUP
TRANSPORT CHANNEL RECONFIGURATION
INTER RAT HANDOVER INFO
RRC CONNECTION SETUP COMPLETE
UE CAPABILITY INFORMATION
ACTIVE SET UPDATE
MEASUREMENT CONTROL
MEASUREMENT REPORT
The following IEs are added to the above Uu interface messages:
E-DCH physical layer category extension 2 IE in the Physical channel capability IE and UE radio
access capability comp 2 IE
Uplink secondary cell info FDD IE
Secondary serving E-DCH info IE
Secondary E-DCH cell info common IE
Downlink information per radio link list on secondary UL frequency IE
Radio link addition information on secondary UL frequency IE
Radio link removal information on secondary UL frequency IE
E-DCH reconfiguration information on secondary UL frequency IE
E-DCH physical layer category extension 2 IE

License
This feature is controlled by a new cell-level license item on the NodeB.
This feature adds new RNC switches, as shown in Table 3-17.

RAN14.0
Table 3-17 New switches on the RNC side

Type ID Command
Added CFG_HSUPA CfgSwitch SET This switch specifies whether DC-HSUPA
switch _DC_SWITC UCORRMAL is configured for HSUPA services on this
H GOSWITCH RNC. The value 1 indicates that the
switch is turned on.
Added DC_HSUPA HspaPlusS SET This switch specifies whether DC-HSUPA
switch witch UCELLALGO can be used in this cell. The value ON
SWITCH indicates that the switch is turned on.
Added DC_HSUPA RetryCapa SET UFRC This switch specifies whether DC-HSUPA
switch bility is included in the HSPA retry technology.
The value ON indicates that the switch is
turned on.
This feature adds new NodeB MML commands, as shown in Table 3-18.
Table 3-18 New commands on the NodeB side
Change Parameter ID MML Description
Type Command
Added FIRSTLOCELL, ADD This command adds two cells to a DC-HSUPA
command SECONDLOCE ULDUALCELL carrier group. The two cells in the carrier group
LL GRP must be configured as DC-HSDPA cells.
Added FIRSTLOCELL, RMV This command removes cells from a DC-HSUPA
command SECONDLOCE ULDUALCELL carrier group.
LL GRP
Added - LST This command queries cells in a DC-HSUPA
command ULDUALCELL carrier group.
GRP
A DC-HSUPA tab page for configuring and managing cells in a DC-HSUPA carrier group is added to the
M2000/CME interface.
This feature modifies the NodeB counters to support DC-HSUPA, as shown in Table 3-19. For a DC-
HSUPA UE, the primary and the secondary carriers are measured separately with the counters.
Table 3-19 Counters that have been modified on the NodeB side
Counter Measurement Unit Description
VS.HSUPA.UnHappyUserNum HSUPA.LOCELL Number of Unhappy HSUPA users in a cell
VS.HSUPA.UserTtiNum HSUPA.LOCELL Number of TTIs in which at least one
HSUPA user exists in a cell

RAN14.0

VS.HSUPA.DataTtiNum HSUPA.LOCELL Number of TTIs in which HSUPA users
transmit data in a cell
VS.HSUPA.ACKTotal HSUPA.LOCELL Number of transmitted ACKs
VS.HSUPA.NACKTotal HSUPA.LOCELL Number of transmitted NACKs
VS.HSUPA.DTXTotal HSUPA.LOCELL Number of transmitted DTXs
VS.HSUPA.PDUNum HSUPA.LOCELL Number of successfully received MAC-e
PDUs from the UE in a cell
VS.HSUPA.RetransPDUNum HSUPA.LOCELL Number of MAC-e PDUs to be retransmitted
by the UE in a cell
VS.HSUPA.Thruput HSUPA.LOCELL Total traffic volume of HSUPA users in a cell
VS.HSUPA.UnHappyUserNum HSUPA.LOCELL Ratio of the number of Unhappy HSUPA
Ratio users to the total number of HSUPA users in
a cell
VS.HSUPA.DataUserNum.Me HSUPA.LOCELL Average number of HSUPA users that
an transmit data in a cell
VS.HSUPA.DataUserNum.Ma HSUPA.LOCELL Maximum number of HSUPA users that
x transmit data in a cell
VS.HSUPA.ScheduleUserNum HSUPA.LOCELL Average number of scheduled HSUPA users
.Mean in a cell
VS.HSUPA.ScheduleUserNum HSUPA.LOCELL Maximum number of scheduled HSUPA
.Max users in a cell
VS.HSUPA.MaxPwrLmtUserR HSUPA.LOCELL Ratio of the number of HSUPA users with
atio limited UPH to the total number of HSUPA
users in a cell
VS.HSUPA.LeftPwrLmtUserRa HSUPA.LOCELL Ratio of the number of HSUPA users with a
tio limited uplink load to the total number of
HSUPA users in a cell
VS.HSUPA.FDE.UtilizeTimePe HSUPA.LOCELL Proportion of the time when HSUPA users
rmillage use the FDE mode in a cell
VS.HSUPA.16QAM.UtilizeTim HSUPA.LOCELL Proportion of the time when HSUPA users
ePermillage use the 16QAM mode in a cell
VS.HSUPA.MeanBitRate HSUPA.LOCELL Average throughput of HSUPA users in a
cell
VS.HSUPA.MeanBitRate.With HSUPA.LOCELL Average throughput of HSUPA users in a
Data cell when data is transmitted
This feature adds new RNC counters, as shown in Table 3-20. This feature also modifies all the
HSUPA-related RNC counters to support DC-HSUPA, which are not listed below. For a DC-HSUPA UE,
the primary and the secondary carriers are measured separately with the counters.

RAN14.0

VS.HSUPA.RAB.DC.AttEsta HSUPA.CELL Number of DC-HSUPA RAB Setup Attempts
b for Cell. This counter is counted only on the
primary carrier for a DC-HSUPA UE.
VS.HSUPA.RAB.DC.SuccEst HSUPA.CELL Number of Successful DC-HSUPA RAB
ab Setups for Cell. This counter is counted only
on the primary carrier for a DC-HSUPA UE.
VS.HSUPA.RAB.DC.NormRe HSUPA.CELL Number of DC-HSUPA RABs Normally
l Released for Cell
VS.HSUPA.RAB.DC.Abnorm HSUPA.CELL Number of DC-HSUPA RABs Abnormally
Rel Released for Cell
VS.HSUPA.UE.Mean.CAT8 HSUPA.CELL Mean Number of HSUPA-enabled UEs of
Category 8 in a Serving Cell
VS.HSUPA.UE.Max.CAT8 HSUPA.CELL Maximum Number of HSUPA-enabled UEs
of Category 8 in a Serving Cell
VS.HSUPA.UE.Mean.CAT9 HSUPA.CELL Mean Number of HSUPA-enabled UEs of
Category 9 in a Serving Cell
VS.HSUPA.UE.Max.CAT9 HSUPA.CELL Maximum Number of HSUPA-enabled UEs
of Category 9 in a Serving Cell
VS.HSUPA.DC.PRIM.UE.Me HSUPA.Cell Mean Number of DC-HSUPA Users in the
an.Cell Cell with the Primary Carrier
VS.HSUPA.DC.SEC.UE.Mea HSUPA.Cell Mean Number of DC-HSUPA Users in the
n.Cell Cell with the Secondary Carrier
Fault Management
This feature has an impact on the alarms on the RNC and NodeB side, as shown in Table 3-21.
Table 3-21 Alarms that have been added or modified
Change Type Alarm NE Description
Modified alarm ALM-28206 Local Cell NodeB Cause value "Users have
Capability Decline configured the DC-HSUPA
capability for a cell but actually
the cell does not support the
DC-HSUPA capability" has been
added to the alarm.
Added alarm ALM-22237 UMTS Cell DC- RNC -
HSUPA Function Fault

RAN14.0

DC-HSUPA depends on the following features:
WRFD-010614 HSUPA Phase 2
WRFD-010695 UL Layer 2 Improvement
WRFD-010652 SRB over HSDPA
WRFD-010636 SRB over HSUPA
WRFD-010696 DC-HSDPA
WRFD-010638 Dynamic CE Resource Management
3.15 WRFD-140203 HSPA+ Uplink 23 Mbit/s per User

(New/Optional)
3.15.1 Description
This feature increases the uplink peak rate from 11.5 Mbit/s to 23 Mbit/s by collaborating with the DC-
HSUPA, UL 16QAM and E-DPCCH Boosting features.

System Capacity
No impact.
Network Performance
This feature increases uplink user throughput.
To support a peak rate of 23 Mbit/s, the RoT threshold must be raised in two carriers of DC-HSUPA. A
higher RoT threshold may result in smaller cell coverage, a higher service drop rate, and a lower
handover success rate.

This feature must be supported by the UE and CN. UEs must support E-DCH category 9, and the CN
must support a UE rate of 23 Mbit/s or higher.
3.15.4 Hardware
This feature depends on the following RNC hardware:
The DPUe or DPUb board must be configured.
In IP transmission mode, the POUc, FG2c, or GOUc board must be configured.
All 3900 series base stations support this feature after WBBPd or WBBPf boards are configured. The
BTS3902E supports this feature.
The DBS3800 support this feature after EBBCd boards are configured.
The BTS3812E and BTS3812AE support this feature after EULPd boards are configured and
downlink cells are configured on EBBI, EBOI, or EDLP boards.

RAN14.0
When 4-way receive diversity is used, only the 3900 series base stations support this feature.


License
This feature is controlled by a new RNC-level license item on the RNC.
No impact.
No impact.
Fault Management
No impact.

WRFD-010694 UL 16QAM
WRFD-010697 E-DPCCH Boosting
WRFD-140204 DC-HSUPA
WRFD-010698 HSPA+ Uplink 11.5Mbit/s per User
3.16 WRFD-01061002 HSUPA UE Category Support

(Enhanced/Optional)
3.16.1 Description
RAN14.0 supports UEs of categories 1 to 9.

System Capacity
No impact.
Network Performance
No impact.

This feature enhancement is implemented on the RNC to add some new counters.

RAN14.0
3.16.4 Hardware
No impact.

This feature enhancement has no impact on the Uu, Iub, Iur, or Iu interface.

License
No impact.
No impact.
The RNC counters are added to support this feature, as shown in Table 3-22.
Change Type Counter Measureme Description
nt Unit
Added counter VS.HSUPA.UE.Me HSUPA.CEL Mean Number of HSUPA-enabled UEs
an.CAT8 L of Category 8 in a Serving Cell
Added counter VS.HSUPA.UE.Ma HSUPA.CEL Maximum Number of HSUPA-enabled
x.CAT8 L UEs of Category 8 in a Serving Cell
Added counter VS.HSUPA.UE.Me HSUPA.CEL Mean Number of HSUPA-enabled UEs
an.CAT9 L of Category 9 in a Serving Cell
Added counter VS.HSUPA.UE.Ma HSUPA.CEL Maximum Number of HSUPA-enabled
x.CAT9 L UEs of Category 9 in a Serving Cell
Fault Management
No impact.

No impact.
3.17 WRFD-140202 Control Channel Parallel Interference

Cancellation (Phase 2)(New/Optional)
3.17.1 Description
This feature improves the efficiency of Control Channel Parallel Interference Cancellation (CCPIC) by
using the advanced regeneration cancellation algorithm. In addition, the benefits of CCPIC are shared
across baseband boards.

RAN14.0

System Capacity
This feature significantly increases the uplink system capacity. When the DPCCH uses a large
proportion of RTWP in a cell, this feature increases system capacity by up to 20%. This gain is possible
when, for example, the uplink throughput is not high but there are a large number of UEs in the cell.
Network Performance
Assume that a WBBPa or WBBPb board and a WBBPd or WBBPf board are inserted into one BBU to
form a UL resource group. To share the CCPIC gains of the WBBPd or WBBPf board when ICMODE is
set to FULL_IC, UEs with their data channel carried on the WBBPa or WBBPb board must set up
another DPCCH on the WBBPd or WBBPf board for power control. Of the UEs, those with their
downlink services carried on an HSDPA channel must set up another HS-DPCCH on the WBBPd or
WBBPf board. This additional channel setup limits the number of UEs to be admitted and reduces the
access success rate. Therefore, it is recommended that the WBBPa or WBBPb board be replaced with
a WBBPd or WBBPf board to fully utilize CCPIC Phase 2.

3.17.4 Hardware
To implement this feature, the following requirements must be met:
Only the 3900 series base stations (excluding the BTS3902E) support this feature.
At least one WBBPd or WBBPf board is configured.


License
This feature adds a new MML command on the NodeB side.
Table 3-23 New command on the NodeB side
Change Type Parameter ID MML Description
Command
Added command ICMODE SET This parameter specifies whether a
ICMODE WBBPa or WBBPb board can benefit
from interference cancellation (IC) gains
of a WBBPd or WBBPf board in the same
UL resource group.

RAN14.0
This feature adds new NodeB counters, as shown in Table 3-24.
Table 3-24 New counters on the NodeB side
Change Type Counter Measurement Description
Unit
Added counter VS.CellFirstStageIcEf HSUPA.LOCELL Average efficiency of first-stage
f.Mean IC in a cell
Added counter VS.CellFirstStageIcEf HSUPA.LOCELL Maximum efficiency of first-stage
f.Max IC in a cell
Efficiency of first-stage IC in a cell is calculated with the following formula:

Efficiency of first-stage IC in a cell = (RTWP measured before IC RTWP measured after first-stage
IC)/RTWP measured before IC
Fault Management
No impact.

Required Features
This feature depends on the WRFD-010210 Control Channel Parallel Interference Cancellation (CCPIC)
feature.
Affected Features
This feature (CCPIC Phase 2) affects the following features:
WRFD-010712 Adaptive Configuration of Traffic Channel Power offset for HSUPA
WRFD-010641 HSUPA Adaptive Retransmission
When CCPIC Phase 2 is enabled, gains from Adaptive Configuration of Traffic Channel Power offset for
HSUPA and HSUPA Adaptive Retransmission decrease. Likewise, when Adaptive Configuration of
Traffic Channel Power offset for HSUPA or HSUPA Adaptive Retransmission is enabled, gains from
CCPIC Phase 2 decrease. This is because CCPIC increases system capacity by canceling interference
from the DPCCH while Adaptive Configuration of Traffic Channel Power offset for HSUPA and HSUPA
Adaptive Retransmission reduce the DPCCH power and therefore leave less interference from the
DPCCH to be canceled.
System throughput is always greater when CCPIC Phase 2 is enabled together with Adaptive
Configuration of Traffic Channel Power offset for HSUPA or HSUPA Adaptive Retransmission, as
compared with when CCPIC Phase 2 is not enabled together with Adaptive Configuration of Traffic
Channel Power offset for HSUPA or HSUPA Adaptive Retransmission or none of the features is enabled.

RAN14.0
3.18 WRFD-140215 Dynamic Configuration of HSDPA CQI

Feedback Period (New/Optional)
3.18.1 Description
After a service is established over an HSDPA channel for a UE, the UE needs to periodically report its
CQI. From the CQI, the NodeB learns the UE's location and the radio quality at that location, based on
which the NodeB selects an appropriate rate to transmit data. A short CQI feedback period ensures
timely feedback on radio channel quality so that the NodeB can dynamically select appropriate rates to
correctly transmit data and achieve high downlink throughput with adequate resources. However, if the
CQI feedback period is too short, HSDPA UEs frequently send CQI feedback and increases the uplink
load. This problem becomes severe when a large number of HSDPA UEs are online. Frequent CQI
feedback is not necessary when there are a large number of HSDPA UEs online, because HSDPA UEs
are not likely to achieve high downlink throughput.
When only a small number of HSDPA UEs are online, this feature configures a short CQI feedback
period to ensure high downlink throughput for HSDPA UEs. When a large number of HSDPA UEs are
online and cause a heavy load on the uplink, this feature configures a long CQI feedback period to
alleviate the uplink load and increase the available capacity on uplink traffic channels.
Reducing the CQI feedback period lowers UE transmit power and thereby improves network
performance. For the combination of CS and PS services, this feature configures a long CQI feedback
period to improve coverage performance.

System Capacity
When a large number of HSDPA UEs are online, CQIs sent over HS-DPCCHs contribute to a large
proportion of the uplink load and compromise uplink capacity. In this case, if the total uplink load and
actual uplink service load are both restricted, the RNC configures the CQI feedback period (which can
improve capacity) for UEs in order to reduce power on control channels and increase power on traffic
channels. This raises the uplink throughput.
Emulation tests were performed based on small-packet transmission. The test results are as follows: If
the CQI feedback period is adjusted from 2 ms to 8 ms and there are 40 online HSDPA UEs, the uplink
actual load decreases by a maximum of 20% during busy hours. If the CQI feedback period is adjusted
from 4 ms to 8 ms, the uplink actual load decreases by a maximum of 10% during busy hours.
Network Performance
Increasing the CQI feedback period lowers the following:
Power required for CQI feedback
Uplink RTWP in the cell
Call drop rate
Increasing the CQI feedback period raises the following:
Uplink SNR
RRC connection success rate
RAB setup success rate
Soft handover success rate
Coverage performance

RAN14.0
For HSDPA UEs, a long CQI feedback period results in CQIs not being promptly reported. This may
lead to decreased throughput and longer delay.

3.18.4 Hardware
If Load-based Dynamic Configuration of the HSDPA CQI Feedback Period is required, the following
hardware dependences of NodeB are required because the actual load report is limited by the
following items:
The BTS3812E, BTS3812A, and BTS3812AE do not support the feature.
The DBS3800 does not support this feature.
If
the 3900 series base station is configured with WBBPa board or the 20 W RRU3801C, the 3900
series base station does not support this feature; otherwise, the 3900 series base station supports
this feature.
Dynamic configuration of the CQI feedback period for the combination of CS and PS services and
dynamic configuration of the CQI feedback period for E2D transitions due to limited coverage have no
hardware dependence of NodeB.

This feature has no impact on the Uu, Iur, or Iu interfaces. The NodeB reports the actual service load
over the Iub interface.

License
This feature has an impact on the RNC parameters, as shown in Table 3-25.
Type ID
Added PC_CQI_CY PcSwitch SET This is the switch for load-based
switch CLE_BASE UCORRMALGO dynamic configuration of the CQI
_CELLLOA SWITCH feedback period. The value 1
D_SWITCH indicates that the switch is turned
on.

RAN14.0

Type ID
Added PC_CQI_CY This is the switch for dynamic
switch CLE_BASE configuration of the CQI feedback
_CS_PLUS period for the combination of CS
_PS_SWITC and PS services. The value 1
H indicates that the switch is turned
on.
Added - CQIFBckBa SET This parameter specifies the length
parameter seCellLoad UHSDPCCH of the CQI feedback period when a
ADD/MOD PE BE service is carried on an
UCELLHSDPCC HSDPA channel on the downlink
H and the serving cell is congested on
the uplink.
Added - CQIFBckBa SET This parameter specifies the CQI
parameter seCsComb UHSDPCCH feedback period for the combination
Serv ADD/MOD of CS and PS services.
UCELLHSDPCC
H
Added - UlActualloa ADD/MOD This parameter specifies the
parameter dTrigLdrTh UCELLLDM threshold above which the actual
d uplink service load is restricted.
This feature adds new counters on the RNC side, as shown in Table 3-26.
nt Unit
Added counter VS.HSDPA.DynCfgAtt.L ALGO2.Cell Number of attempts to configure a
ongCQI long CQI feedback period for a cell
Added counter VS.HSDPA.DynCfgAtt.S ALGO2.Cell Number of attempts to configure a
hortCQI short CQI feedback period for a cell
If VS.HSDPA.DynCfgAtt.LongCQI is not 0, it indicates that the feature has taken effect. If

VS.HSDPA.DynCfgAtt.LongCQI constitutes a large proportion of the sum of
VS.HSDPA.DynCfgAtt.LongCQI and VS.HSDPA.DynCfgAtt.ShortCQI, it indicates that the feature has
yielded notable gains.
Fault Management
No impact.

This feature depends on the WRFD-010610 HSDPA Introduction Package feature.

RAN14.0
If the WRFD-021350 Independent Demodulation of Signals from Multiple RRUs in One Cell feature is
configured, the load-based dynamic configuration of the HSDPA CQI feedback period function in this
feature cannot take effect.
3.19 WRFD-140216 Load-based Uplink Target BLER

Configuration (New/Optional)
3.19.1 Description
In a WCDMA system, a high SNR increases the probability of data blocks being correctly received.
However, a high SNR requires high transmit power, which results in increased interference to the
system. Currently, most UEs only support R99 channels on the uplink. This feature dynamically
configures the target BLERs on R99 channels based on the uplink loads. When the uplink load is light,
this feature configures a small target BLER for each R99 channel to improve data transmission quality.
When the uplink load is heavy, this feature configures a large target BLER for each R99 channel to
sacrifice a little throughput for a reduced load on the channel and higher system capacity.
The BLER on a channel is controlled by the receiver by means of outer-loop power control. The RNC
can quickly adjust the target BLERs on uplink R99 channels. Therefore, this feature is used only if
uplink services are set up on dedicated physical channels (DPCHs).

System Capacity
When the total uplink load and actual uplink service load in a cell are restricted, increasing the target
BLER lowers the uplink load in the cell and raises the uplink throughput of the cell.
Emulation results show that the uplink load decreases by at most about 15% when there are 30 online
R99 UEs and the target BLER is adjusted.
Network Performance
When the total uplink load and actual uplink service load are restricted, the target BLER is increased to:
Lower the following:
Required UE power
Uplink RTWP in the cell
Call drop rate
Raise the following:
Uplink SNR in the cell
RRC connection success rate
RAB setup success rate
Soft handover success rate
If the target BLER is used for R99 UEs under load congestion, the actual BLER increases, the effective
rates for individual UEs drop, and delay is extended.


RAN14.0
3.19.4 Hardware
The following hardware dependences of NodeB are required because the actual load report is limited
by the following items:
The BTS3812E, BTS3812A, and BTS3812AE do not support the feature.
The DBS3800 does not support this feature.
If the 3900 series base station is configured with WBBPa board or the 20 W RRU3801C, the 3900
series base station does not support this feature. Otherwise, the 3900 series base station supports
the feature.

This feature has no impact on the Uu, Iur, or Iu interfaces. The NodeB reports the actual service load
over the Iub interface.

License
This feature has the following impact on RNC parameters.
Change Switch Parameter Command Function
Type
Added PC_BLER PcSwitch SET This is the switch for load-based target
switch _TARGET UCORRMAL BLER configuration for best effort (BE)
_BASE_C GOSWITCH services. The value 1 indicates that the
ELLLOAD switch is turned on.
_SWITCH
Added - BlerTarget SET This parameter specifies the target BLER
parameter BaseCellLo UHSDPCCH to be used when the uplink load is
ad ADD/MOD congested in the cell and the services
UCELLHSDP carried on DCHs on the uplink are all PS
CCH BE services.
Added - UlActualloa ADD/MOD This parameter specifies the threshold

parameter dTrigLdrTh UCELLLDM above which the actual uplink service
d load is restricted.
The following counters have been added to the RNC.

RAN14.0

nt Unit
Added counter VS.ULBler.BE.Large ALGO2.Cell Number of attempts to configure
BLER in a Congested Cell
Added counter VS.ULBler.BE.Small ALGO2.Cell Number of attempts to configure
BLER in a Normal Cell
If VS.ULBler.BE.Large is not 0, it indicates that the feature has taken effect. If VS.ULBler.BE.Large
constitutes a large proportion of the sum of VS.ULBler.BE.Large and VS.ULBler.BE.Small, it indicates
that the feature has yielded notable gains.
Fault Management
No impact.

The load-based uplink target BLER configuration feature dynamically adjusts the target BLER based on
the load. The more quickly the UE transmit power converges to the power corresponding to the new
target BLER, the more gains this feature yields. Therefore, it is recommended that the OLPC
enhancement algorithm be enabled when this feature is enabled. The OLPC enhancement algorithm
quickly adjusts the target SIR and thereby ensures high gains of the load-based uplink target BLER
configuration feature. The switch for the OLPC optimization algorithm is
PC_OLPC_FastDown_Optimize_SWITCH under PcSwitch.
If the WRFD-021350 Independent Demodulation of Signals from Multiple RRUs in One Cell feature is
configured, this feature cannot take effect.
3.20 WRFD-140207 Iu/Iur Transmission Resource Pool in RNC

(New/Optional)
3.20.1 Description
A transmission resource pool is formed by multiple interface boards on the RNC side. The IP addresses
assigned to these boards form an IP address pool. Any peer NE of the RNC over the Iu/Iur interface, for
example, an MGW, SGSN, GGSN, or NRNC, can be connected to any interface board in the
transmission resource pool. When a service needs to be set up, the RNC selects an IP address from
the IP address pool for the service in a way that ensures load balancing.
The transmission resource pool eliminates the need for configuring an IP path. A transmission link can
be set up directly between the RNC and a peer NE. Each peer NE is bound to an IP address pool on
the RNC side by using the corresponding adjacent node. Each IP address in the IP address pool is
bound to the egress port of an interface board according to the source-based route. The RNC selects
egress ports for packets based on the same source-based route.
This feature can be applied to the Iu/Iur interface.

RAN14.0

System Capacity
If transmission resource pools are configured, the RNC requires fewer interface boards but provides the
equal system capacity. The spared space for boards can be used for additional user-plane boards and
control-plane boards, expanding system capacity of the RNC.
Network Performance
If transmission resource pools are not configured, some interface boards may be congested while some
are lightly loaded. Board congestion may affect user throughput of an associated NodeB. If
transmission resource pools are configured, the RNC processes services in a way that ensures load
balancing and traffic is evenly distributed among interface boards. If the total capacity of interface
boards is sufficient, board congestion does not occur and the total user throughput may increase.

This feature is implemented on the RNC, CME, M2000, and RNC LMT.
3.20.4 Hardware
The interface boards of the RNC use the GOUc or FG2c boards.


License
A new license item has been introduced on the RNC to control this feature at the RNC level.
Table 3-29 describes the man-machine language (MML) commands that have been added on the RNC
for this feature.
MML Command Description
ADD/MOD/RMV IPPOOL Use these commands to add, modify, and remove a
transmission resource pool respectively.
LST IPPOOL Use this command to query the configuration of a
transmission resource pool.
DSP IPPOOL Use this command to query the state and load of IP
in a transmission resource pool.
ADD/RMV IPPOOLIP Use these commands to add an IP address to and
remove it from a transmission resource pool
respectively.
LST IPPOOLIP Use this command to query all IP addresses in a

RAN14.0

DSP IPPOOLIP Use this command to query all adjacent nodes
bound to the local IP address and the binding
causes.
BLK/UBL IPPOOLIP Use these commands to block and unblock an IP
address in a transmission resource pool
respectively. A blocked IP address cannot be used
by the transmission resource pool.
DSP ADJNODEDIP Use this command to query the IP address
information of an adjacent node.
DSP ADJNODEPING Use this command to query the status of
connectivity check with the ping command for an
adjacent node.
SET/LST Use these commands to set and query the load
TNLOADBALANCEPARA balancing parameters for the interface board and
MPU board respectively.
ADD/MOD/RMV SRCIPRT Use these commands to add, modify, and remove a
source-based route respectively.
LST SRCIPRT Use this command to query the configuration of a
source-based route.
DSP SRCIPRT Use this command to query the status of a source-
based route.
This feature also adds some new parameters to existing RNC commands, as shown in Table 3-30.
Change Type Parameter ID MML Command Description
Added parameter ISIPPOOL ADD/MOD Whether a transmission resource
ADJNODE pool is used.
Added parameter IPPOOLINDEX Index for a transmission resource
pool.
Added parameter PINGSWITCH Whether the connectivity check
with the ping command for an
adjacent node is used.
Added parameter PERIOD Period of connectivity check with
the ping command.
Added parameter CHECKCOUNT Number of timeouts for
connectivity check with the ping
command.
Added parameter ICMPPKGLEN Ping packet length.
The total length of the ping packet
contains the IP header.

RAN14.0

Added parameter CNMNGMODE Resource management mode.
Whether to share an adjacent
node over the Iu interface in a
multi-operator network.
Added parameter CNOPINDEX Index for an operator exclusively
occupying the adjacent node over
the Iu interface in a multi-operator
network.
Added parameter ISIPPOOL DSP IPCHN Whether a transmission resource
pool is used.
Added parameter IPADDR Local IP address of a transmission
resource pool.
The execution result of the DSP INTERWK command on the RNC has included the interworking
information about IP PM and connectivity check with the ping command for the transmission resource
pool.
Changes on the CME are as follows:
The following configuration objects have been added over the Iu/Iur interface:
Policy-Based Route Based on the Source IP Address
IP Pool
The Adjust Transmission Pool page has been added.
Table 3-31 describes the measurement units that have been added on the RNC for this feature.
Table 3-31 New measurement units on the RNC side
Change Type Measurement Unit Description
Added measurement unit IPPOOL.SIP.IPLAYER Statistics on packets received and sent at a
source IP address in the transmission
resource pool
Added measurement unit IPPOOL.ADJNODE Statistics on transmission quality of an
adjacent node in the transmission resource
pool
Added measurement unit IPPOOL.SIP Statistics on transmission quality at a source
IP address in the transmission resource pool
Added measurement unit IPPOOL.RTP Statistics on Real-Time Transport Protocol
(RTP) in the transmission resource pool
On the RNC LMT, IPPOOL LOCAL IP has been added to Monitor Item on the Link Performance
Monitoring page.

RAN14.0
Fault Management
There is no IP path in the transmission resource pool and therefore the alarms related to IP path are not
reported.
The following alarms have been added on the RNC:
ALM-21392 Adjacent Node IP Address Ping Failure
ALM-21393 Adjacent Node IP Path Ping Failure
ALM-21394 Transmission Resource Pool IP Packet Loss
ALM-21602 IP In IP Address Pool Blocked

Required Features
WRFD-050409 IP Transmission Introduction on Iu Interface
WRFD-050410 IP Transmission Introduction on Iur Interface

This feature and the WRFD-050412 UDP MUX for Iu-CS Transmission feature are mutually exclusive.
3.21 WRFD-140208 Iub Transmission Resource Pool in RNC

(New/Optional)
3.21.1 Description
A transmission resource pool is formed by multiple interface boards on the RNC side. The IP addresses
assigned to these boards form an IP address pool. Each NodeB is connected to an interface board in
the transmission resource pool. When a service needs to be set up, the RNC selects an IP address
from the IP address pool for the service in a way that ensures load balancing.
The transmission resource pool eliminates the need for configuring an IP path. A transmission link can
be set up directly between the RNC and the NodeB. Each NodeB is bound to an IP address pool on the
RNC side by using the corresponding adjacent node. Each IP address in the IP address pool is bound
to the egress port of an interface board according to the source-based route. The RNC selects egress
ports for packets based on the same source-based route.
This feature can be applied to the Iub interface.

System Capacity
If transmission resource pools are configured, the RNC provides a larger transmission capacity by using
the equal number of interface boards.
The following example briefs the benefit of a transmission resource pool to transmission capacity,
assuming that there are 500 base stations on the live network and an interface board on the RNC
serves 100 base stations:
The RNC requires 10 interface boards if no transmission resource pool is configured.

RAN14.0
Five pairs of interface boards in active/standby mode serve 500 base stations, with one pair for 100
base stations. Therefore, 10 interface boards are required.
The RNC requires only six interface boards if a transmission resource pool is configured.
Five interface boards serve 500 base stations and an extra interface board serves as redundancy.
This extra interface board maintains system capacity if a single interface board fails.
The spared space for boards can be used for additional user-plane boards and control-plane boards,
expanding system capacity of the RNC.
Network Performance
If transmission resource pools are not configured, some interface boards may be congested while some
are lightly loaded because a NodeB is bound to an interface board on the RNC side. Board congestion
may affect user throughput of an associated NodeB. If transmission resource pools are configured, the
RNC processes services in a way that ensures load balancing and traffic is evenly distributed among
interface boards. If the total capacity of interface boards is sufficient, board congestion does not occur
and the total user throughput may increase.

This feature is implemented on the RNC, CME, M2000, NodeB, RNC LMT, and NodeB LMT.
3.21.4 Hardware
Dependency on RNC Hardware
The interface boards of the RNC use the GOUc or FG2c boards.
Dependency on NodeB Hardware
The NodeB is a 3900 series base station or BTS3902E. The Ethernet interface boards of 3900 series
base stations support this feature, including the WMPT, UMPT, UTRP, and UTRPc boards.


License
A new license item has been introduced on the RNC to control this feature at the RNC level.
Table 3-32 describes the MML commands that have been added on the RNC and NodeB for this
feature.
Table 3-32 New commands on the RNC and NodeB
NE MML Command Description
RNC ADD/MOD/RMV IPPOOL Use these commands to add, modify, and
remove a transmission resource pool
respectively.
LST IPPOOL Use this command to query the configuration
of a transmission resource pool.

RAN14.0

DSP IPPOOL Use this command to query the state and load
of IP in a transmission resource pool.
ADD/RMV IPPOOLIP Use these commands to add an IP address to
and remove it from a transmission resource
pool respectively.
LST IPPOOLIP Use this command to query all IP addresses
in a transmission resource pool.
DSP IPPOOLIP Use this command to query all adjacent nodes
bound to the local IP address and the binding
causes.
BLK/UBL IPPOOLIP Use these commands to block and unblock an
IP address in a transmission resource pool
respectively.
A blocked IP address cannot be used by the
DSP ADJNODEDIP Use this command to query the IP address
information of an adjacent node.
DSP ADJNODEPING Use this command to query the status of
connectivity check with the ping command for
an adjacent node.
SET/LST Use these commands to set and query the
TNLOADBALANCEPARA load balancing parameters for the interface
board and MPU board.
ADD/MOD/RMV SRCIPRT Use these commands to add, modify, and
remove a source-based route respectively.
LST SRCIPRT Use this command to query the configuration
of a source-based route.
DSP SRCIPRT Use this command to query the status of a
source-based route.
ACT/DEA IPPOOLPM Use these commands to activate and
deactivate IP PM between the adjacent node
and the transmission resource pool
respectively.
LST IPPOOLPM Use this command to query the configuration
of IP PM between the adjacent node and the
DSP IPPOOLPM Use this command to query the monitoring
status of IP PM between the adjacent node
and the transmission resource pool.
ADD ADJNODEIPBIND Use this command to forcedly bind an
adjacent node to an IP address in the

RAN14.0

RMV/LST ADJNODEIPBIND Use these commands to remove and query
the binding relationship between an adjacent
node and an IP address in the transmission
resource pool respectively.
NodeB ADD SERVIP Use this command to set the service IP
address on the NodeB side.
RMV/LST/MOD SERVIP Use these commands to remove, query, and
modify the settings in the ADD SERVIP
command respectively.
Command
Added parameter ISIPPOOL ADD/MOD Whether a transmission resource pool
ADJNODE is used.
Added parameter IPPOOLINDEX Index for an IP address pool.
Added parameter PINGSWITCH Whether the connectivity check with
the ping command for an adjacent
node is used.
Added parameter PERIOD Period of connectivity check with the
ping command.
Added parameter CHECKCOUNT Number of timeouts for connectivity
check with the ping command.
Added parameter ICMPPKGLEN Ping packet length.
The total length of the ping packet
contains the IP header.
Added parameter TxBw Transmit bandwidth of an adjacent
node.
Also the service admission bandwidth
of an adjacent node.
Added parameter RxBw Receive bandwidth of an adjacent
node.
Also the service admission bandwidth
of an adjacent node.
Added parameter TRMLOADTHINDEX TRM load threshold index
Added parameter ISIPPOOL DSP Whether a transmission resource pool
IPCHN is used.

RAN14.0

Command
Added parameter IPADDR Local IP address of the IP address
pool.
The execution result of the DSP INTERWK command on the RNC has included the interworking
information about IP PM and connectivity check with the ping command for the transmission resource
pool.
Changes on the CME are as follows:
The following configuration objects have been added over the Iub interface:
Policy-Based Route Based on the Source IP Address
IP Pool
The Adjust Transmission Pool page has been added.
The topology view on the M2000 can display the binding between NodeBs and the transmission
resource pool.
Table 3-34 describes the measurement units that have been added on the RNC for this feature.
Table 3-34 New measurement units on the RNC side
Change Type Measurement Unit Description
Added measurement unit IPPOOL.SIP.IPLAYE Statistics on packets received and sent at a
R source IP address in the transmission
resource pool
Added measurement unit IPPOOL.ADJNODE Statistics on transmission quality of an
adjacent node in the transmission resource
pool
Added measurement unit IPPOOL.SIP Statistics on transmission quality at a source
IP address in the transmission resource pool
Added measurement unit IPPOOL.PM Statistics on IP PM between an adjacent
node and the transmission resource pool
On the RNC LMT, IPPOOL LOCAL IP and IPPOOL PM have been added to Monitor Item on the Link
Performance Monitoring page.
Fault Management
There is no IP path in the transmission resource pool and therefore the alarms related to IP path are not
reported.
The following alarms have been added on the RNC:
ALM-21392 Adjacent Node IP Address Ping Failure
ALM-21393 Adjacent Node IP Path Ping Failure

RAN14.0
ALM-21394 Transmission Resource Pool IP Packet Loss

ALM-21603 Adjacent Node Congestion
ALM-21602 IP In IP Address Pool Blocked

Required Features
This feature depends on the WRFD-050402 IP Transmission Introduction on Iub Interface feature.

This feature is mutually exclusive to the following features:
WRFD-021305 RAN Sharing Phase 2
WRFD-02130501 Dedicated Iub Transmission Control
WRFD-050420 FP MUX for IP Transmission
WRFD-050422 Dynamic Bandwidth Control of Iub IP
WRFD-050403 Hybrid Iub IP Transmission
Affected Features
This feature affects the following RAN features:
WRFD-050408 Overbooking on IP Transmission
Overbooking is implemented by means of admission, shaping, and backpressure over the logical
ports. When a transmission resource pool is used, logical ports are unavailable and therefore
overbooking cannot be implemented.
WRFD-020101 Admission Control
When a transmission resource pool is used, the RNC does not perform admission control for BE
services, including interactive services and background services. Only congestion control is
performed for BE services on the user plane.
3.22 WRFD-140223 MOCN Cell Resource Demarcation

(New/Optional)
3.22.1 Description
In MOCN networking scenarios, the MOCN Cell Resource Demarcation feature introduced in RAN14.0
prevents UEs of an operator from occupying excessive cell resources. This ensures fairness to each
operator in using shared cell resources. With this feature, the percentage of cell resources available for
each operator in a shared MOCN cell is configurable. The predefined cell resources are DL R99
spreading codes (SCs) and HSDPA power resources.
After this feature is enabled, the RAN manages DL R99 SCs and HSDPA power resources in a shared
MOCN cell as follows:
The RNC performs admission, preemption, and congestion control.
When cell resources are sufficient, the RNC admits UEs without differentiating between operators.
UEs of any operator can use more resources than the predefined resource percentage.
When a UE cannot be admitted due to insufficient cell resources, the RNC determines whether to
trigger preemption based on the actual percentage of resources being used by each operator.

RAN14.0
When congestion triggered by insufficient DL R99 SCs occurs in the cell, the RNC preferentially
performs congestion control on R99 UEs whose operator exceeds the predefined percentage of DL
R99 SCs the most.
The NodeB adjusts scheduling priority and performs scheduling for HSDPA UEs accordingly.
The NodeB adjusts scheduling priorities among HSDPA UEs of different operators in real time to
ensure the actual usage of each operator's HSDPA power resources is close to the percentage of
available HSDPA power resources predefined for each operator.

System Capacity
No impact.
Network Performance
With the MOCN Cell Resource Demarcation feature, the RNC is more likely to trigger preemption and
the call drop rate increases in a cell with heavy load if any operator uses more DL R99 SCs or HSDPA
power than its predefined resource percentage. In a cell with light load, however, this feature has no
impact on network performance because preemption is not triggered.

3.22.4 Hardware
Only the 3900 series base stations and the BTS3902E support this feature. The WBBPb, WBBPd, or
WBBPf board must be configured on the 3900 series base stations.

This feature affects Iub and Iur interfaces.
On the Iub interface:
Private IEs ucMocnoperatorIndex, ucMocnoperatordemarcationHpowerratio, and ucPrimOperIndex
are added to the PHYSICAL SHARED CHANNEL RECONFIGRATION REQUEST message. The
RNC indicates the indexes of MOCN operators, their predefined percentages of available HSDPA
power resources, and index of the primary operator in these IEs to the NodeB, respectively.
The private IE ucSharedOperIndex is added to the RADIO LINK SETUP REQUEST, RADIO LINK
RECONFIGURATION PREPARE, and RADIO LINK ADDTION REQUEST messages. The RNC
indicates information about each HSDPA UE's serving operator in this private IE to the NodeB.
The private IE OperatorHsdpaGbpPwrListPrivate is added to the COMMON MEASUREMENT
REPORT message. The NodeB uses this private IE to periodically notify the RNC of the total GBP
required for each operator's HSDPA UEs using network resources.
On the Iur interface, the private IE ulPlmnId is added to the RADIO LINK SETUP REQUEST, RADIO
LINK RECONFIGURATION PREPARE, and RADIO LINK ADDTION REQUEST messages. The SRNC
indicates information about a UE's serving operator in this private IE to the DRNC.

License

RAN14.0
Table 3-35 lists commands added on the RNC.
ADD/MOD/RMV/LST Use these commands to configure, modify,
UCELLMOCNSFDEMAR remove, and query the predefined
percentage of DL R99 SCs available for
each operator in a shared MOCN cell.
ADD/MOD/RMV/LST Use these commands to configure, modify,
UCELLMOCNDPAPOWERDEMAR remove, and query the predefined
percentage of HSDPA power resources
available for each operator in a shared
MOCN cell.
Table 3-36 New parameters and switches on the RNC side
Change Type Switch Parameter ID MML Description
Command
Added switch PLMNID_IN IurPrivateInterfa ADD/MOD Turn on this switch to enable
CLUDED ceSwitch UNRNC the SRNC to deliver
information about a UE's
serving operator to the
DRNC on the Iur interface.
Added parameter - IubPrivateInterf SET Select
aceSwitch URRCTRLS RL_OpIndex_INCLUDED
WITCH under this parameter to
enable the RNC to deliver on
the Iub interface information
about each HSDPA UE's
serving operator and each
operator's predefined
percentage of available
HSDPA resources.
Added parameter - DemarcPreempt ADD Select
Switch UCELLALG MOCN_DEMARC_PREEMP
OSWITCH T_SF and
MOCN_DEMARC_PREEMP
T_GBP under this parameter
to enable preemption based
on DL R99 SCs and
preemption based on GBP,
respectively.

RAN14.0
This feature adds new counters on the RNC or NodeB side, as shown in Table 3-37.
Table 3-37 New counters on the RNC and NodeB
NE Counter Measurement Description
Unit
RNC VS.RAB.SFOccupy.MAX PLMN.CELL Maximum Number of Spreading
.SharedOperator0 Codes Occupied by Shared Operator0
for Cell
RNC VS.RAB.SFOccupy.Shar PLMN.CELL Average Number of Spreading Codes
edOperator0 Occupied by Shared Operator0 for
Cell
for Cell
Cell
for Cell
Cell
for Cell
Cell
NodeB VS.HSDPAPwrRatio.Sh HSDPA.LOCELL Average HSDPA power ratio for
aredOperator0 operator 0 in a cell of an MOCN
network
network
network
network

RAN14.0
Fault Management
No impact.

The MOCN Cell Resource Demarcation feature depends on the WRFD-021311 MOCN Introduction
Package feature.
It is not recommended that this feature be used with the WRFD-010696 DC-HSDPA feature because
enabling Dual-Carrier High Speed Downlink Packet Access (DC-HSDPA) results in inaccurate statistics
on HSDPA power. DC-HSDPA takes statistics of HSDPA power resources based on two cells whereas
MOCN takes statistics of HSDPA power resources based on one cell.
3.23 WRFD-140210 NodeB PKI Support (New/Optional)

3.23.1 Description
PKI is the foundation and core of contemporary network security construction and provides information
security based on the asymmetric cryptographic algorithm. PKI is mainly used to manage digital
certificates. A digital certificate identifies a piece of equipment and is created by a trusted certificate
authority (CA), which digitally signs the equipment information and public key. A digital certificate
includes the following information:
Equipment information
Validity period of the certificate
Public key
Digital signature of the organization that grants the certificate
During digital certificate authentication, asymmetric keys are used to authenticate equipment identity.
The sender uses a private key to sign data, and the receiver uses the public key in the certificate to
check signature validity.
Huawei NodeBs support PKI-based end-to-end certificate management solutions, which involve the
certificate preconfiguration phase, deployment phase, and operation phase. This phased approach
facilitates the use of the certificates. Certificates in Huawei NodeBs are managed by using Certificate
Management Protocol (CMPv2).
For Huawei products, digital certificates are applicable in either of the following scenarios:
Authentication during the setup of an Internet Protocol Security (IPSec) tunnel between a base
station and an SeGW in a radio bearer network
Authentication during the setup of an SSL-encrypted operation and maintenance (O&M) channel
between a base station and the M2000. SSL stands for Secure Sockets Layer.
To use PKI, the peer device, such as the SeGW, must also support the PKI functionality.

System Capacity
No impact.
Network Performance
No impact.

RAN14.0

This feature is implemented on the NodeB and M2000.
3.23.4 Hardware
Only the 3900 series base stations support this feature. They must use the Ethernet ports of the UTRPc
or UMPT board to connect to the CA server.

The CMPv2 interface must be supported between the base station and the CA server for certificate
application and update.

License
A NodeB-level license for this feature is added on the NodeB side.
Table 3-38 lists commands added on the RNC.
MOD CERTREQ The command is used to modify a device certificate
request for generating a certificate request file.
LST CERTREQ The command is used to list the content of a device
certificate request.
ADD/LST/RMV CERTMK The commands are used to add, list, and remove a
device certificate, respectively.
DSP CERTMK The command is used to query the configurations of
a device certificate.
MOD/LST/TST APPCERT The commands are used to modify, list, and test a
device certificate used by a base station,
respectively.
DSP APPCERT The command is used to query the configurations of
a device certificate used by a base station.
LST CERTTYPE The command is used to list NE-supported
certificate application types.
ADD/RMV/LST The commands are used to add, remove, and list a
TRUSTCERT CA-issued certificate or a certificate chain,
respectively.
DSP TRUSTCERT The command is used to query the configurations of
a CA-issued certificate or a certificate chain.
ADD/RMV/LST CRL The commands are used to add, remove, and list a
CRL file.

RAN14.0

DSP CRL The command is used to query the configurations of
a CRL file.
ADD/RMV/LST CRLTSK The commands are used to add, remove, and list a
CRL update task, respectively.
SET/LST CRLPOLICY The commands are used to set and list CRL usage
policies, respectively.
SET/LST CERTCHKTSK The commands are used to set and list a task of
periodic certificate validity checks, respectively.
DLD CERTFILE The command is used to download a digital
certificate file.
LST CERTFILE The command is used to list a certificate file in the
directory where a base station stores downloaded
files.
RMV CERTFILE The command is used to remove a certificate file
from the directory where a base station stores
downloaded files.
The following user interfaces have been added on a per managed object (MO) basis on the CME:
CERTDEPLOY
CA
CERTREQ
CERTMK
APPCERT
TRUSTCERT
CERTCHKTSK
CRL
CRLPOLICY
CRLTSK
No impact.
Fault Management
The following NodeB alarms have been added:
ALM-26840 Imminent Certificate Expiry
ALM-26841 Certificate Invalid
ALM-26842 Automatic Certificate Update Failed
ALM-26832 Peer Certificate Expiry

RAN14.0

No impact.
3.24 WRFD-140209 NodeB Integrated IPSec (New/Optional)

3.24.1 Description
With the evolution towards IP-based networks, operators use an existing IP bearer network or a leased
telecom bearer network to reduce network deployment costs. This may pose security threats. Before
IPSec is introduced, a base station transmits control plane data, user plane data, and management
plane data in plaintext. Packets transmitted on an insecure network are vulnerable to unauthorized
access or malicious modification. To ensure transport network security, Huawei NodeBs incorporate the
IPSec function, by which IPSec tunnels are set up for secure packet communication.
As defined by the Internet Engineering Task Force (IETF), IPSec is a set of protocols that support
secure packet communication at the IP layer. These protocols are Authentication Header (AH),
Encapsulation Security Protocol (ESP), and Internet Key Exchange (IKE). IPSec provides transparent
end-to-end security services for IP networks, which protect IP packets from cyber attacks.
With IPSec, two communication parties (also known as IPSec peers) ensure the following security
features of data transmission on the network by encrypting and verifying IP packets:
Confidentiality. An IPSec entity encrypts user data and transmits the data in ciphertext to prevent the
data from being disclosed on the transmission path. The IPSec entity refers to the network element
(NE) or network device that uses IPSec for communication.
Integrity. The IPSec entity verifies the received data to ensure that it has not been tampered with.
Authenticity. The IPSec entity authenticates the data origin to confirm the sender of the data.
Anti-replay. The IPSec entity identifies packets and prevents malicious attackers from repeatedly
sending captured packets.
RAN14.0 introduces NodeB Integrated IPSec for Huawei NodeBs. Therefore, on Huawei's UMTS
networks, an IPSec tunnel can be established between the NodeB and SeGW, which protects data
transmitted between the NodeB and the radio network controller (RNC).

System Capacity
No impact.
Network Performance
IPSec ensures transmission security by encapsulating and encrypting IP packets. This reduces the
transmission efficiency of service packets on the bearer network.
Take ESP encapsulation in tunnel mode as an example. Assume that the IP payload is 500 bytes, the
packet length (including the IP header and Ethernet header) before IPSec encapsulation is 540 bytes,
the encryption algorithm is 3DES, and the authentication algorithm is MD5. Then, the packet structure
after encapsulation is as follows:
20 bytes (Ethernet header) + 20 bytes (external IP header) + 8 bytes (ESP header) + 20 bytes (internal
IP header) + 8 bytes (initialization vector) + 500 bytes (payload) + 2 bytes (padding) + 2 bytes (ESP
trailer) + 16 bytes (integrity check value for MD5)
The total length is 596 bytes. The transmission efficiency decreases from 92.59% to 83.89%.

RAN14.0
The impact of IPSec on the transmission efficiency of service data varies depending on the protocol,
algorithm, and encapsulation mode. Table 3-39 and Table 3-40 describe the impact of IPSec on the
transmission efficiency when the AH and the MD5, SHA, or SHA2 algorithm are used for integrity
verification.
Table 3-39 Impact of IPSec on the transmission efficiency in transport mode
Service AMR 12.2
PS 32 kbit/s CS 64 kbit/s PS 128 kbit/s PS 384 kbit/s
Algorithm kbit/s
IPSec disabled 29% 51.6% 69.3% 78.6% 83.5%

MD5 22.9% 43.7% 61.8% 73.6% 79.6%
SHA 22.3% 42.8% 60.8% 72.9% 78.9%
SHA-256 20.5% 40.2% 58.2% 71.0% 77.5%
Table 3-40 Impact of IPSec on the transmission efficiency in tunnel mode

Service AMR 12.2
Algorithm kbit/s
IPSec disabled 29% 51.6% 69.3% 78.6% 83.5%

MD5 20.0% 39.4% 57.4% 70.3% 77.0%
SHA 19.4% 38.6% 56.5% 769.7% 76.6%
SHA-256 18.4% 36.5% 54.2% 67.9% 75.1%
Table 3-41 and Table 3-42 describe the impact of IPSec on the transmission efficiency when the ESP
and the DES, 3DES, or AES algorithm are used for encryption.
Table 3-41 Impact of IPSec on the transmission efficiency in transport mode
Service AMR 12.2
Algorithm kbit/s
IPSec disabled 29% 51.6% 69.3% 78.6% 83.5%

DES/3DES+MD5 22.1% 43.0% 60.2% 72.4% 78.7%
DES/3DES
21.5% 42.1% 59.3% 71.7% 78.2%
+SHA
AES+MD5 20.9% 41.2% 58.4% 71.1% 78.7%
AES+SHA 20.3% 40.4% 57.6% 70.5% 78.2%

RAN14.0
Table 3-42 Impact of IPSec on the transmission efficiency in tunnel mode

Service AMR 12.2
Algorithm kbit/s
IPSec
29% 51.6% 69.3% 78.6% 83.5%
disabled
DES/3DES
18.7% 38.1% 56.7% 69.9% 76.7%
+MD5
DES/3DES
18.3% 37.4% 55.9% 69.3% 76.2%
+SHA
AES+MD5 18.7% 38.1% 55.2% 68.7% 76.7%
AES+SHA 18.3% 37.4% 54.4% 68.1% 76.2%
If IPSec is enabled, the first startup time of the NodeB increases by less than 2 minutes (excluding the
VLAN scanning time) when the NEs and transmission equipment are available. The increased time is
caused by the certificate request and IPSec tunnel establishment and depends on the response speed
of the external DHCP server and the encryption protocol used by the SeGW.

This feature is implemented on the NodeB, CME, M2000, and LMT.
If IPSec is enabled on an operator's network, the operator must deploy the security gateway (SeGW)
and Certificate Authority (CA).
If IPSec is enabled together with the plug-and-play function for the NodeB, the operator needs to deploy
an external Dynamic Host Configuration Protocol (DHCP) server.
CA
The CA must comply with the Certificate Management Protocol (CMP) in V2 (RFC 4210) and support
public key infrastructure (PKI). The format of the certificate request message must comply with RFC
4211.
SeGW
The SeGW must comply with the encryption protocol specified in RFC 2409 or RFC 4306. The SeGW
must support PKI or PSK authentication.
External DHCP Server
If IPSec is enabled together with the plug-and-play function for the NodeB, the operator needs to
deploy an external DHCP server for NodeB IP address distribution. Generally, the IP address is
temporarily assigned and is used for IPSec tunnel establishment between the NodeB and the SeGW
and for communication between the NodeB and the M2000 on the intranet.
3.24.4 Hardware
Only the 3900 series base stations support this feature. They must use the Ethernet ports of the UTRPc
or UMPT board to connect to the SeGW.

No impact.

RAN14.0

License
This feature adds new NodeB MML commands, as shown in Table 3-43.
Table 3-43 New commands on the NodeB side
SET IKECFG The command is used to set basic IKE configurations when a
PSK is used for authentication.
LST IKECFG This command is used to query the basic IKE configuration.
DSP IKECFG The command is used to query the IKE status and basic IKE
configurations.
ADD/MOD/RMV The command is used to add, modify, or remove an IKE
IKEPROPOSAL proposal.
LST This command is used to query IKE proposal configuration.
IKEPROPOSAL
DSP The command is used to query the status and configurations
IKEPROPOSAL of an IKE proposal.
ADD/MOD/RMV The commands are used to add, modify, or remove an IKE
IKEPEER peer.
LST IKEPEER This command is used to query IKE peer configuration.
DSP IKEPEER The command is used to query the status and configurations
of an IKE peer.
DSP IKESTAT The command is used to query the basic information about
an IKE SA.
DSP IKEMSGSTAT The command is used to query the statistical information
about IKE messages.
DSP The command is used to query changes in the IKEv2
IKEV2EXCHSTAT exchange status.
DSP The command is used to query changes in the IKEv1
IKEV1EXCHSTAT exchange status.
ADD/MOD/RMV The commands are used to add, modify, or remove an IPSec
IPSECPROPOSAL proposal.
LST This command is used to query IPSec proposal configuration.
IPSECPROPOSAL
DSP The command is used to query the status and configurations
IPSECPROPOSAL of an IPSec proposal.

RAN14.0

ADD/MOD/RMV The commands are used to add, modify, or remove an IPSec
IPSECPOLICY policy.
DSP The command is used to query the status of an IPSec policy.
IPSECPOLICY
ADD/RMV The commands are used to add or remove the binding
IPSECBIND between an IPSec policy and a port.
LST IPSECBIND The command is used to list the binding between an IPSec
policy and a port.
DSP The command is used to query the statistical information
IPSECSADELSTAT about an IPSec SA.
DSP IKESA The command is used to query the status of an IKE SA.
DSP IPSECSA The command is used to query the status of an IPSec SA.
ADD/MOD/RMV This command is used to add, modify, and remove IPSec
IPSECDTNL active/standby channel relationships.
ADD/RMV The commands are used to add or remove the configurations
IPSECDTNL of the primary and secondary IPSec tunnels.
LST IPSECDTNL The command is used to list the configurations of the primary
and secondary IPSec tunnels.
DSP IPSECDTNL This command is used to query the status of IPSec
active/standby channels.
The following user interfaces have been added on a per managed object (MO) basis on the CME:
IKEPROPOSAL
IKEPEER
IPSECPROPOSAL
IPSECPOLICY
IPSECBIND
IKECFG
IPSECDTNL
No impact.
Fault Management
The following NodeB alarms have been added:
ALM-25891 IKE Negotiation Failure
ALM-25950 Base Station Being Attacked

RAN14.0

Required Features
This feature depends on the WRFD-050402 IP Transmission Introduction on Iub Interface feature.

This feature cannot be used with the AACP function in the WRFD-031101 NodeB Self-Discovery Based
on IP Route feature.
3.25 WRFD-050402 IP Transmission Introduction on Iub

Interface (Enhanced/Optional)
3.25.1 Description
The NodeB Integrated Firewall feature is an enhancement to the WRFD-050402 IP Transmission
Introduction on Iub Interface feature.
The NodeB Integrated Firewall feature increases the security protection capability of operator
equipment and prevents attack packets from affecting network operations. In an IP over FE/GE
transmission network, the NodeB Integrated Firewall feature provides the following functions:
ACL packet filter: An ACL is used to filter IP packets. NodeBs determine whether to allow the packets
to enter the system based on the ACL. This function filters out attack packets and junk packets.
Network attack prevention: This function enables NodeBs to counter certain attacks, such as flood
attacks, malformed packet attacks, and Address Resolution Protocol (ARP) spoofing. It also
safeguards NodeBs against attack packets that have not been filtered out by the ACL, which prevents
service quality deterioration and service interruption.
The following functions have been added to NodeBs in RAN14.0.
Layer 2 ACL packet filter: This function enables NodeBs to filter out invalid packets on layer 2.
Network attack prevention: This function enables NodeBs to counter certain attacks, such as flood
attacks, malformed packet attacks, and ARP spoofing.

System Capacity
The NodeB Integrated Firewall feature does not affect system capacity.
Network Performance
The NodeB Integrated Firewall feature does not affect network performance.

The NodeB Integrated Firewall feature is implemented on the NodeB and does not depend on other
network elements (NEs).
3.25.4 Hardware
The following hardware supports the NodeB Integrated Firewall feature in RAN14.0:
BTS3902E

RAN14.0
Ethernet IP interface boards in Huawei 3900 series base stations

The NodeB Integrated Firewall feature does not affect the Iub, Iur, and Iu interfaces.

License
The NodeB Integrated Firewall feature does not affect the license.
The NodeB Integrated Firewall feature introduces the NodeB parameters in Table 3-44.
Table 3-44 New parameters on the NodeB side
Added parameter FLDTYPE ADD/MOD/RMV The parameter specifies the flood
FLOODDEFEND attack type.
Added parameter DFDSW ADD/MOD The parameter specifies whether to
FLOODDEFEND enable flood attack prevention.
Added parameter DFDTHD The parameter specifies the
threshold beyond which the NodeB
discards excess packets.
Added parameter ALMSW ADD/MOD The parameter specifies whether the
FLOODDEFEND NodeB reports an alarm upon
encountering flood attacks.
Added parameter ALMTHD The parameter specifies the
threshold at which the NodeB reports
an alarm.
Added parameter ARPSPOOFCH SET IPGUARD The parameter specifies whether to
KSW detect ARP spoofing.
Added parameter ARPSPOOFAL The parameter specifies the ARP
MTHD spoofing alarm threshold. When the
number of ARP table update
attempts initiated by received
packets exceeds this threshold, the
NodeB reports an alarm.
Added parameter ARPLRNSTRI The parameter specifies whether to
CTSW enable strict ARP learning.
Added parameter ACLID2 ADD The parameter specifies the ID of a
PACKETFILTER layer 2 ACL.
Added parameter FM The parameter specifies the packet
filter mode. The NodeB can filter
packets based on layer 3/layer 4
ACL rules, layer 2 ACL rules, or
both.

RAN14.0

Added parameter VLANIDOP ADD/MOD The parameter specifies that the
ACLRULE virtual local area network (VLAN) ID
is used as the criterion for filtering
packets. The value of this parameter
can be one VLAN ID or a range of
VLAN IDs.
Added parameter VLANID1,VLA The parameter specifies the start
NID2 and end IDs, respectively, within a
range of VLAN IDs when VLANIDOP
is set to OP_RANGE.
No impact.
Fault Management
The NodeB Integrated Firewall feature introduces a new NodeB alarm ALM-25950 Base Station Being
Attacked

The NodeB Integrated Firewall feature does not affect other features.
3.26 WRFD-140218 Service-Based PS Handover from UMTS to

LTE (New/Optional)
3.26.1 Description
This feature allows the RNC to hand over a UE and the PS services it is processing to the LTE network
when the following conditions are met:
The UE within a UMTS/LTE overlapping coverage area initiates a PS service, or the UE after CSFB
has ended the CS service and still has an ongoing PS service on the UMTS network.
The LTE signal quality meets the conditions.
The benefits of this feature are as follows:
UEs can obtain a higher PS bandwidth from the LTE network. Compared with a PS redirection, a PS
handover interrupts services for a shorter period of time.
UMTS/LTE dual-mode UEs are served by the LTE network whenever possible in the initial phase of
LTE network deployment, making more efficient use of the LTE network and easing the traffic load on
the UMTS network.

System Capacity
No impact.

RAN14.0
Network Performance
With this feature, some PS services on the UMTS network can be handed over to the LTE network. In
this way, this feature eases the traffic load on the UMTS network, and increases the UMTS access
success rate and throughput for admitted users.

This feature depends on the CN and UE. The UE in connected mode must support LTE measurements
and UMTS-to-LTE PS handovers. The CN must support Iu-interface signaling messages relevant to this
feature.
3.26.4 Hardware
No impact.

This feature affects messages on the Iu interface. The involved IEs on the Iu interface are as follows:
E-UTRAN Service Handover: This optional IE has been added to the RAB Assignment Request
message, which is sent from the SGSN to the RNC. This IE indicates which radio access bearers
(RABs) cannot be switched over to LTE.
Target eNB-ID: This IE has been added to the Relocation Required message, which is sent from the
RNC to the SGSN. This IE indicates the destination eNodeB.
Source eNB to Target eNB Transparent Container: This IE has been added to the Relocation
Required message, which is sent from the RNC to the SGSN. This IE is required in a UMTS-to-LTE
PS handover, according to 3GPP TS 36.413.

License
No impact.
This feature adds new cell-level counters on the RNC side, as shown in Table 3-45.
VS.U2LTEHO.AttOutPS. U2LTE.HO.Cell Number of service-based UMTS-to-LTE PS
Service handover attempts for a cell
VS.U2LTEHO.SuccOutP U2LTE.HO.Cell Number of successful service-based UMTS-
S.Service to-LTE PS handovers for a cell
VS.U2LTEHO.FailOutPS U2LTE.HO.Cell Number of failed outgoing UMTS-to-LTE PS
.NoReply handovers due to Iu release command
timeout for a cell

RAN14.0

.CfgUnSupp handovers for a cell (Configuration
Unsupported)
.PhyChFail handovers for a cell (Physical Channel
Failure)
VS.U2LTEHO.FailOutPS U2LTE.HO.Cell Number of abnormally terminated outgoing
.Abort UMTS-to-LTE PS handovers for a cell
VS.U2LTEHO.AttRelocP U2LTE.HO.Cell Number of outgoing UMTS-to-LTE PS
repOutPS handover preparation attempts for a cell
VS.U2LTEHO.SuccRelo U2LTE.HO.Cell Number of successful preparations for
cPrepOutPS outgoing UMTS-to-LTE PS handovers for a
cell
VS.U2LTEHO.FailReloc U2LTE.HO.Cell Number of failed preparations for outgoing
PrepOutPS.NoResAvail UMTS-to-LTE PS handovers for a cell (No
Resource Available)
PrepOutPS.TgtFail UMTS-to-LTE PS handovers for a cell
(Relocation Failure in Target CN/RNC or
Target System)
PrepOutPS.ReloUnSupp UMTS-to-LTE PS handovers for a cell
(Relocation not supported in Target RNC or
Target system)
PrepOutPS.TgtHighLoad UMTS-to-LTE PS handovers for a cell
(Traffic Load In The Target Cell Higher Than
In The Source Cell)
PrepOutPS.TAlExp UMTS-to-LTE PS handovers for a cell
(TRELOCalloc expiry)
PrepOutPS.UnKnowRN UMTS-to-LTE PS handovers for a cell
C (Unknown Target RNC)
Fault Management
No impact.

No impact.

RAN14.0
3.27 WRFD-140102 CS Fallback Guarantee for LTE Emergency

Calls (New/Basic)
3.27.1 Description
CSFB applies to scenarios where the LTE network does not support voice services because the IMS is
not available for use. The eNodeB can instruct a UE to fall back to the UMTS network when the UE
attempts to initiate a CS service (including an emergency call) on the LTE network.
To initiate an emergency call on the LTE network, the UE in idle mode first needs to transit to connected
mode. Then, the UE falls back to the UMTS network by using CSFB. Each UE in connected mode
maintains a default PS connection on the LTE network, and this PS connection also needs to be
handed over or redirected to the UMTS network.
The eNodeB determines whether to perform CSFB by using an LTE-to-UMTS PS handover or
redirection. If an LTE-to-UMTS PS handover is to be implemented, the eNodeB notifies the RNC that
the PS handover is caused by CSFB for an emergency call. The UE can initiate an emergency call on
the UMTS network only after the PS service has been admitted to the UMTS network. This feature
ensures the success of PS admission by decreasing the PS service rate, performing resource
preemption, or both.

System Capacity
No impact.
Network Performance
This feature increases the success rate for LTE-to-UMTS PS handovers caused by CSFB for LTE
emergency calls.
When the destination UMTS cell is congested, too many CSFB requests caused by LTE emergency
calls may preempt the UMTS resources, leading to an increased call drop rate on the UMTS network.

3.27.4 Hardware
No impact.

This feature affects messages on the Iu interface.
A standard IE referred to as CSFB Information has been added to the Relocation Request message,
which is sent from the SGSN to the RNC. This IE specifies whether the CSFB service type is a common
CS service or an emergency call.

License
This feature is a new basic feature in RAN14.0 and is not under license control.

RAN14.0
This feature adds a new switch on the RNC, as shown in Table 3-46.
Table 3-46 New switch on the RNC side
Change Type Switch Parameter MML Description
ID Command
Added switch L2U_EmgCall_ HoSwitch SET The switch is used to control
Switch UCORRMAL whether to enable this
GOSwitch feature.
This feature adds new counters on the RNC side, performing handover-related measurements after CS
Fallback Guarantee for LTE Emergency Calls is activated, as shown in Table 3-47.
VS.L2U.AttRelocPrepInPS.E IRATHO.PS.RNC Number of incoming LTE-to-UMTS PS
merg.RNC handover attempts caused by emergency
calls at the RNC level
VS.L2U.SuccRelocInPS.Eme IRATHO.PS.RNC Number of successful incoming LTE-to-
rg.RNC UMTS PS handovers caused by
emergency calls at the RNC level
The success rate of LTE-to-UMTS PS handovers caused by CSFB for LTE emergency calls is
calculated with the following formula:
Success rate of LTE-to-UMTS PS handovers caused by CSFB for LTE emergency calls =
VS.L2U.SuccRelocInPS.Emerg.RNC/VS.L2U.AttRelocPrepInPS.Emerg.RNC
Fault Management
No impact.

No impact.
3.28 WRFD-140212 CE Overbooking (New/Optional)

3.28.1 Description
After WRFD-010638 Dynamic CE Resource Management is applied, the RNC calculates the credit
resource usage of an admitted HSUPA UE by using the following formula:
Credit resource usage = Max (Credit resources required for ensuring the GBR, Credit resources
required for transmitting one RLC PDU)

RAN14.0
In the preceding formula, GBR stands for guaranteed bit rate and RLC PDU stands for Radio Link
Control packet data unit. The RNC performs this calculation to ensure HSUPA user experience.
However, the actual CE usage of the NodeB is lower than the calculated credit resource usage of the
RNC in most cases due to the high penetration rate of smart phones with a 2 ms HSUPA transmission
time interval (TTI). As a result, the RNC may reject new UE access attempts even if the actual CE
usage of the NodeB is low. This limits the RNC's capability to perform admission control based on credit
resource usage.
To address this issue, Huawei introduces CE Overbooking.
With this feature, the NodeB adjusts the actual credit resource usage of admitted UEs based on the
traffic volume, and reports the actual credit resource usage to the RNC using a private IE. The RNC
directly uses the reported credit resource usage. Benefits from this feature are available when both of
the following are true:
The average throughput of an HSUPA UE is low, that is, the UE rate is lower than the GBR or the rate
at which an RLC PDU is transmitted.
The calculated credit resource usage of HSUPA UEs is less than the calculation result of the
preceding formula.
The benefits are as follows:
More admitted UEs
More HSUPA UEs with a 2 ms TTI
Reduced load reshuffling (LDR) actions caused by credit resource congestion
Reduced probability of admission-CE-based dynamic TTI adjustment from 2 ms to 10 ms over
HSUPA
Reduced credit resource usage of admitted UEs
Enhanced RNC's capability to perform admission control based on credit resource usage
This feature applies only to networks where the number of smart phones with an HSUPA TTI of 2 ms is
large and the average HSUPA throughput is low.
For details about Dynamic CE Resource Management, see the HSUPA Feature Parameter Description.

System Capacity
When the uplink credit resources are insufficient and the HSUPA throughput is low, CE Overbooking
enables more UEs to be admitted. Therefore, the average cell throughput increases when credit
resources are insufficient and Uu and Iub resources are sufficient.
However, when CE resources are insufficient, fewer resources are available for each user, leading to
lower per user throughput.
Network Performance
In a network where the average HSUPA throughput is low, CE Overbooking considers the uplink traffic
volume during the calculation of the remaining credit resources. This reduces the probability of
insufficient credit resources. Therefore, this feature affects network performance as follows:
Improves the wireless access success rate
Improves CE resource utilization
Increases the number of admitted UEs
Increases the call drop rate for HSUPA UEs

RAN14.0
When more UEs are admitted, the air interface load becomes heavier and CE resources may become
insufficient due to more concurrent data transmissions, either of which may lead to higher call drop
rates.
NOTE
With CE overbooking, more users can be admitted. When the credit resources are congested, CE overbooking may
decrease the handover success rate and RRC setup success rate. The probability of such decreases is low, and
therefore the network performance is generally not affected.
After CE Overbooking is enabled, there is a possibility that admission rejections increase over the Iub
interface if a large number of UEs has accessed the network. However, CE Overbooking does not
affect the UE access success rate.
Before CE Overbooking is enabled, the RNC updates the consumption of CE resources for UE
admission upon UE access or release.
After CE Overbooking is enabled, the NodeB updates the consumption of CE resources for UE
admission and reports to the RNC every 1s. During the report interval, the RNC cannot learn about the
accurate consumption of CE resources, resulting in information inconsistency between the RNC and
the NodeB. Therefore, there is a possibility that some UEs are admitted by the RNC but fail to be
admitted by the NodeB.

This feature is implemented on the RNC and NodeB and does not depend on the CN and the UE.
3.28.4 Hardware
The dependencies of this feature on NodeB hardware are as follows:
The BTS3812E, BTS3812A, or BTS3812AE must be configured with the EBBI, EBOI, EULP, or
EULPd board.
The DBS3800 must be configured with the EBBC or EBBCd board.
The 3900 series base stations must be configured with the WBBPb, WBBPd, or WBBPf board.

The following Huawei private IEs are added to Iub interface messages:
enCeOverbookingCap: added to the AUDIT RESPONSE and RESOURCE STATUS INDICATION
messages so that the RNC can determine whether CE Overbooking is activated.
UlNodeBMinGuaranteedCEPrivate: indicates the actual credit resource usage of admitted UEs at the
NodeB level. This IE has been added to cell measurement reports so that the RNC can calculate the
remaining credit resources at the NodeB level accordingly.
UlLcgMinGuaranteedCEPrivate: indicates the actual credit resource usage of admitted UEs in a cell
group. This IE has been added to cell measurement reports so that the RNC can calculate the
remaining credit resources at the cell group level accordingly.

License
This feature adds a new parameter on the NodeB side, as shown in Table 3-48.

RAN14.0
Table 3-48 New parameter on the NodeB side

REVDPARA4 SET Minimum number of CEs required for
NODEBRSVP admitting an HSUPA UE with a 2 ms TTI
This feature adds new counters on the RNC side to measure the NodeB credit usage after this feature
is activated, as shown in Table 3-49.
Unit
VS.NodeB.ULCredit ALGO.NODEB Average NodeB Credit Usage When CE
Used.Mean Overbooking Is Enabled
VS.NodeB.ULCredit ALGO.NODEB Maximum NodeB Credit Usage When CE
Used.Max Overbooking Is Enabled
VS.NodeB.ULCredit ALGO.NODEB Minimum NodeB Credit Usage When CE
Used.Min Overbooking Is Enabled
Fault Management
No impact.

CE Overbooking depends on WRFD-010638 Dynamic CE Resource Management.
CE Overbooking, although advantageous, may cause excessive CE utilization. For admitted UEs, the
calculated CE resources cannot be ensured in certain scenarios. For example, when there are many 2
ms HSUPA UEs and multiple 2 ms HSUPA UEs transmit data at the same time, call drops may occur.
However, if TTI selection is applied with CE Overbooking, the TTI for HSUPA UEs can be switched from
2 ms to 10 ms in this situation to reduce the call drop rate. Therefore, it is recommended that CE
Overbooking be used with Admission-CE-based Dynamic TTI Adjustment for a Single BE Service over
HSUPA. For details about Admission-CE-based Dynamic TTI Adjustment for a Single BE Service over
HSUPA, see the HSUPA TTI Selection Feature Parameter Description.
3.29 WRFD-020103 Inter-Frequency Load Balance

(Enhanced/Optional)
3.29.1 Description
Inter-frequency load balance is an important part of LDR. This feature enables some UEs in a cell in the
basic congestion state to be handed over to an inter-frequency neighboring cell. This reduces load in
the cell.

RAN14.0
When a cell is in the basic congestion state, this feature achieves system load balancing as follows:
The RNC selects the handover target cell based on the difference between the congestion threshold
and the current load in the candidate cells.
The RNC selects UEs to be handed over based on the UEs' integrated priority in the current cell.
The RNC performs a blind handover or measurement-based handover on the selected UEs
according to parameter configurations.
Before RAN14.0, inter-frequency load balance supported load-based inter-frequency handovers
triggered by basic congestion of only power or code resource. In RAN14.0, load-based inter-frequency
handovers can also be triggered by basic congestion of uplink credit resource.

System Capacity
No impact.
Network Performance
Inter-frequency load balance based on uplink credit resource enables some UEs to be handed over to
an inter-frequency neighboring cell when the current cell is in the basic congestion state, effectively
relieving the basic congestion of uplink credit resources. In this way, the admission failures due to uplink
credit resource congestion decrease.
In addition, this feature makes UEs processing PS services more likely to perform inter-frequency
handovers. This may slightly increase the PS call drop rate.

3.29.4 Hardware
No impact.

No impact.

License
This feature is already under RNC-level license control. The feature enhancement has no impact on the
license.
Table 3-50 describes the parameters added or modified to the existing MML commands on the RNC
side for this feature enhancement.

RAN14.0
Modified UlLdrFirstActi ADD The InterFreqLDHO option is added to
parameter on UNODEBLDR parameters UlLdrFirstAction to
UlLdrSeventh MOD UlLdrSeventhAction in the command
Action UNODEBLDR ADD UNODEBLDR or MOD
UNODEBLDR. The parameters
UlLdrFirstAction through
UlLdrSeventhAction specify the first
to the seventh uplink LDR actions. The
InterFreqLDHO option indicates an
eighth LDR action choice: inter-
frequency handover based on uplink
credit resources. With this action
added, LDR action choices extend to
the following:
NoAct
BERateRed
QoSRenego
CSInterRatShouldBeLDHO
PSInterRatShouldBeLDHO
AMRRateRed
CSInterRatShouldNotLDHO
PSInterRatShouldNotLDHO
InterFreqLDHO
Added parameter UlLdrEighthAc ADD The parameter is added to specify the
tion UNODEBLDR eighth LDR action. As with the seven
MOD previously-mentioned LDR actions, the
UNODEBLDR eighth LDR action has eight action
choices.
Added parameter UlInterFreqHo ADD The parameter is added to specify the
CeLDRSpaceT UNODEBLDR uplink credit margin threshold in the
hd MOD target cell for performing a load-based
UNODEBLDR inter-frequency handover triggered by
uplink credit resource congestion. A
cell can be selected as the target cell
only if the uplink credit margin of the
cell group including the cell and that of
the NodeB both exceed this threshold.
The uplink credit margin for LDR is
calculated by subtracting the uplink
reserved credit resources for LDR
corresponding to the SF specified by
UlLdrCreditSfResThd from the
remaining credit resources.

RAN14.0
Table 3-51 describes two cell-level counters added on the RNC side to measure inter-frequency
handovers triggered by the credit resource congestion.
Change Type Counter Measurem Description
ent Unit
Added counter VS.HHO.AttInterFreqOut. HHO.CELL Number of PS Inter-Frequency Hard
PS.UlCE Handover Attempts Based on UL
Credit Resources for Cell
Added counter VS.HHO.SuccInterFreqOu HHO.CELL Number of Successful PS Inter-
t.PS.UlCE Frequency Hard Handovers Based
on UL Credit Resources for Cell
Fault Management
No impact.

No impact.
3.30 WRFD-140217 Inter-Frequency Load Balancing Based on

Configurable Load Threshold (New/Optional)
3.30.1 Description
This feature (CLB for short) is new in RAN14.0.
CLB balances the load among inter-frequency cells by triggering measurement-based inter-frequency
handovers. With CLB, the RNC compares measurement results of uplink and downlink power resource,
code resource, and channel element (CE) resource in a cell with load thresholds for the corresponding
services. Based on the comparison result, the RNC selects the UEs and target cell for an inter-
frequency handover.
CLB supports load balancing among cells on the following frequencies:
Intra-band frequencies
Inter-band frequencies
Inter-RNC frequencies
Inter-vendor frequencies
Frequencies between the macro network and the micro network
Currently, CLB is recommended for the macro and micro combined network and the overlay network.
Macro and micro combined network: Macro and micro cells are networked together using different
frequencies.
Overlay network: The cells in a sector use the equipment provided by different vendors, and these
cells may be managed by different RNCs.

RAN14.0

System Capacity
With CLB, a heavily loaded cell can be relieved, and the resources of a lightly loaded cell can be fully
utilized, increasing the whole system capacity.
Network Performance
CLB improves the coverage performance of a heavily loaded cell.
The impact of CLB on network performance in different scenarios is as follows:
Macro and micro combined network using different frequencies
CLB offloads HSPA services on the macro network to the micro network. Resources of the micro
network deployed at hot spots are fully utilized and the quality of HSPA services after handovers is
ensured. In addition, the quality of CS services on the macro network is improved after the network
load decreases.
Overlay network
CLB supports inter-frequency load balancing for UEs in connected mode under different RNCs in an
overlay network, enabling effective network resource utilization of different vendors. The sector
capacity is expanded, and key performance indicators (KPIs) of heavily loaded cells are improved.
When CLB is implemented between different RNCs on the overlay network, ping-pong handovers
may occur because an RNC cannot obtain the information about the load of inter-frequency
neighboring cells under the neighboring RNC. Therefore, a load evaluation algorithm has been added
to evaluate the load of inter-frequency neighboring cells. If the number of failed inter-frequency
handovers during a certain period of time exceeds a preset threshold, a penalty timer is triggered and
UEs cannot be handed over to the inter-frequency neighboring cell until the penalty timer expires.
However, ping-pong handovers may still occur because this load evaluation algorithm makes a rough
estimate of the load of inter-frequency neighboring cells.
Other scenarios
CLB is used in other scenarios the similar way the WRFD-020103 Inter-Frequency Load Balance
feature is used. The difference is that CLB can implement load balancing before a cell enters the
basic congestion state so that the traffic load can evenly be distributed among cells. CLB helps
prevent a cell from being heavily loaded or having deteriorated KPIs.

3.30.4 Hardware
No impact.

No impact.

License

RAN14.0
This feature affects the MML commands and parameters on the RNC side.
Table 3-52 lists the new MML commands that have been added on the RNC side.
SET/LST UCLB Used to set the RNC-level parameters for the CLB.
ADD/MOD/RMV/LST Used to add, modify, remove, or list the NodeB-level
UNODEBCLB parameters for the CLB.
ADD/MOD/LST Used to add, modify, or list the cell-level parameters for
UCELLCLB CLB.
Table 3-53 lists the parameters that have been added to existing MML commands on the RNC side.
Table 3-53 Parameters that have been added to existing MML commands on the RNC side
ClbPeriodTimerLen SET CLB period
ULDCPERIOD
UlPwrCSClbTrigThd ADD/MOD CLB triggering threshold of the power
UCELLLDM load for uplink CS services
UlPwrPSClbTrigThd ADD/MOD CLB triggering threshold of the power
UCELLLDM load for uplink PS services
DlPwrCSClbTrigThd ADD/MOD CLB triggering threshold of the power
UCELLLDM load for downlink CS services
DlPwrPSClbTrigThd ADD/MOD CLB triggering threshold of the power
UCELLLDM load for downlink PS services
UlPwrCSClbRelThd ADD/MOD CLB releasing threshold of the power
UCELLLDM load for uplink CS services
UlPwrPSClbRelThd ADD/MOD CLB releasing threshold of the power
UCELLLDM load for uplink PS services
DlPwrCSClbRelThd ADD/MOD CLB releasing threshold of the power
UCELLLDM load for downlink CS services
DlPwrPSClbRelThd ADD/MOD CLB releasing threshold of the power
UCELLLDM load for downlink PS services
NCovCMUserNumCt SET UCMCF Control switch for the number of users
rlSwitch in compressed mode with SF/2
reduction in non-coverage-based inter-
frequency handovers
CellSFCMUserNumT SET UCMCF Threshold for the number of users in
hd compressed mode with SF/2 reduction
in a cell

RAN14.0

CLBFlag ADD/MOD CLB flag
UINTERFREQN
CELL
CLBPrio ADD/MOD Priority of an inter-frequency
UINTERFREQN neighboring cell whose CLBFlag is
CELL TRUE
UlLdTrnsHysTime ADD/MOD State transition hysteresis threshold
UCELLLDM for the uplink load
Table 3-54 lists the parameters that have been modified for existing MML commands on the RNC side.
Table 3-54 Parameters that have been modified for existing MML commands on the RNC side
Change Switch Paramet MML Description
Type er ID Command
Added UL_UU_ NBMLdc ADD/MOD The switch controls whether to
switch CLB AlgoSwit UCELLALG enable the uplink air-interface
ch OSWITCH load balancing algorithm.
Added DL_UU_ The switch controls whether to
switch CLB enable the downlink air-
interface load balancing
algorithm.
Added CELL_C The switch controls whether to
switch ODE_CL enable the cell code resource
B load balancing algorithm.
Added CELL_C The switch controls whether to
switch REDIT_C enable the cell credit load
LB balancing algorithm.
Added NODEB_ NodeBL ADD/MOD The switch controls whether to
switch CREDIT_ dcAlgoS UNODEBAL enable the NodeB credit load
CLB_SW witch GOPARA balancing algorithm.
ITCH
Added LCG_CR The switch controls whether to
switch EDIT_CL enable the local cell group
B_SWIT credit load balancing
CH algorithm.
Replaced - UESpdO SET This parameter replaces the
paramete ptSwitch UMCLDR MCLDRbsdUESpdOptSwitch
r ADD/MOD parameter.
UCELLMCL This parameter serves as the
DR reference user speed
optimization switch, extending
its applicable scope.

RAN14.0
Table 3-55 lists the counters that have been added or modified on the RNC side.
Table 3-55 Counters that have been added or modified on the RNC side
Change Counter Measuremen Description
Type t Unit
Added VS.LCC.CLB. ALGO2.Cell Number of CS users performing
counter CS.InterFreq measurement-based inter-frequency
load handovers in a cell in the CS
CLB state
Added VS.LCC.CLB. ALGO2.Cell Number of PS users performing
counter PS.InterFreq measurement-based inter-frequency
load handovers in a cell in the PS
CLB state
Added VS.HHO.Succ HHO.Cell Number of successful inter-
counter InterFreqOut. frequency hard handovers in the CS
CS.UlCE domain for a cell (triggered by uplink
CE resource)
counter InterFreqOut. frequency hard handovers in the CS
CS.DlCE domain for a cell (triggered by
downlink CE resource)
counter InterFreqOut. frequency hard handovers in the PS
PS.DlCE domain for a cell (triggered by
downlink CE resource)
Added VS.HHO.AttIn HHO.Cell Number of inter-frequency hard
counter terFreqOut.C handover attempts in the CS domain
S.DlCE for a cell (triggered by downlink CE
resource)
counter terFreqOut.P handover attempts in the PS domain
S.DlCE for a cell (triggered by downlink CE
resource)
counter terFreqOut.C handover attempts in the CS domain
S.UlCE for a cell (triggered by uplink CE
resource)
Modified VS.HHO.AttIn HHO.Cell Number of inter-frequency hard
counter terFreqOut.P handover attempts triggered by
S.UlCE uplink CE resource in the optimal cell
Modified VS.HHO.Succ HHO.Cell Number of successful inter-
counter InterFreqOut. frequency hard handovers triggered
PS.UlCE by uplink CE resource in the optimal
cell

RAN14.0
For a heavily loaded cell, this feature reduces the downlink power and uplink RTWP and improves the
success rate of inter-frequency hard handovers. This feature affects the following counters:
VS.MeanTCP: average value of transmit power of the TRX for a cell
VS.MeanRTWP: average value of received total wideband power for a cell
Inter-frequency hard handover success rate: calculated using the following formulas:
Inter-frequency
hard handover success rate (RNC) =
(VS.HHO.SuccInterFreq.RNC/VS.HHO.AttInterFreq.RNC) x 100%;
Inter-frequency
hard handover success rate (Cell) =
(VS.HHO.SuccInterFreqOut/VS.HHO.AttInterFreqOut) x 100%
Fault Management
No impact.

The impact of CLB on other features is as follows:
In the intra-band inter-frequency networking scenario, CLB does not depend on any features.
In the inter-band inter-frequency networking scenario, CLB depends on the WRFD-020110 Multi
Frequency Band Networking Management feature.
The difference between CLB and LDR lies in timing for algorithm triggering. LDR is used in the basic
congestion scenario. CLB is used for load balancing when:
The cell has not been congested.
The cell has been congested but LDR cannot be used for load balancing, such as load balancing
among cells under different RNCs.
CLB is independent from LDR.
3.31 WRFD-020160 Enhanced Multiband Management

(Enhanced/Optional)
3.31.1 Description
This feature implements load-based inter-band handovers based on measurement in a network with
multiple frequency bands. This feature helps balance load between frequency bands and improve the
system resource usage. In addition, the handovers based on measurement ensures the handover
success rate in such a network with the inter-band cells under different coverage. Before RAN14.0, this
feature supported load-based inter-band handovers based on measurement triggered by basic
congestion of only power resources. In RAN14.0, load-based inter-band handovers based on
measurement can also be triggered by basic congestion of uplink credit resources.

System Capacity
No impact.

RAN14.0
Network Performance
Load-based inter-band handovers based on measurement and uplink credit resources enable some
UEs to be handed over to an inter-band neighboring cell when the current cell is in the basic congestion
state, effectively relieving the basic congestion of uplink credit resources. In this way, the admission
failures due to uplink credit resource congestion decrease.
Only UEs processing PS services are selected to perform load-based inter-band handovers based on
measurement that are triggered by basic congestion of uplink credit resources. UEs processing CS
services are not selected because they consume a small amount of credit resources and therefore
handovers of them can do little to ease credit congestion.
This feature makes UEs processing PS services more likely to perform inter-frequency handovers. This
may slightly increase the PS call drop rate.


No impact.

No impact.

License
license.
Table 3-56 describes the parameters added or modified on the RNC side for this feature enhancement.

RAN14.0
Type ID Command
Modified UlLdrFirstA ADD The InterFreqLDHO option is added
paramete ction UNODEBLDR to parameters UlLdrFirstAction to
r UlLdrSeven MOD UlLdrSeventhAction in the command
thAction UNODEBLDR ADD UNODEBLDR or MOD
UNODEBLDR. The parameters
UlLdrFirstAction through
UlLdrSeventhAction specify the first
to the seventh uplink LDR actions. The
InterFreqLDHO option indicates an
eighth LDR action choice: inter-
frequency handover based on uplink
credit resources. With this action
added, LDR action choices extend to
the following:
NoAct
BERateRed
QoSRenego
AMRRateRed
InterFreqLDHO
Added UlLdrEighth ADD The parameter is added to specify the
paramete Action UNODEBLDR eighth LDR action. As with the seven
r MOD previously-mentioned LDR actions, the
UNODEBLDR eighth LDR action has eight action
choices.
Added UlInterFreq ADD The parameter is added to specify the
paramete HoCeLDRS UNODEBLDR uplink credit margin threshold in the
r paceThd MOD target cell for performing a load-based
UNODEBLDR inter-frequency handover triggered by
uplink credit resource congestion. A
cell can be selected as the target cell
only if the uplink credit margin of the
cell group including the cell and that of
the NodeB both exceed this threshold.
The uplink credit margin for LDR is
calculated by subtracting the uplink
reserved credit resources for LDR

RAN14.0
Table 3-57 describes two cell-level counters added on the RNC side to measure load-based inter-
frequency handovers triggered by credit resource congestion.
Change Counter Measurem Description
Type ent Unit
Added VS.HHO.Att HHO.CELL Number of PS Inter-Frequency Hard
counter InterFreqOu Handover Attempts Based on UL Credit
t.PS.UlCE Resources for Cell
Added VS.HHO.Su HHO.CELL Number of Successful PS Inter-Frequency
counter ccInterFreq Hard Handovers Based on UL Credit
Out.PS.UlC Resources for Cell
E
Fault Management
No impact.

Inter-band cell load balancing of this feature depends on the WRFD-020110 Multi Frequency Band
Networking Management and WRFD-020103 Inter-Frequency Load Balance features.
3.32 WRFD-020110 Multi Frequency Band Networking

Management (Enhanced/Optional)
3.32.1 Description
The Multi Frequency Band Networking Management feature enables telecom operators to provide
services on multiple frequency bands simultaneously. This feature provides mobility management, load
balancing, and traffic steering between different frequency bands. With this feature, load-based inter-
band handovers triggered by load reshuffling (LDR) adopt blind handovers. When a cell enters the
basic congestion state, this feature enables some UEs to be handed over to an inter-band cell to
balance the load.
Before RAN14.0, this feature supported inter-band blind handovers triggered by basic congestion of
only power resources. In RAN14.0, this feature also supports the handovers triggered by basic
congestion of uplink credit resources.

System Capacity
No impact.
Network Performance
Inter-band blind handovers triggered by uplink credit resource congestion enable some UEs to be
handed over to an inter-band neighboring cell when the current cell is in the basic congestion state,

RAN14.0
effectively relieving the basic congestion of uplink credit resources. In this way, the admission failures
due to uplink credit resource congestion decrease.
Only UEs processing PS services are selected to perform inter-band blind handovers triggered by basic
congestion of uplink credit resources. UEs processing CS services are not selected because they
consume a small amount of credit resources and therefore handovers of them can do little to ease
credit congestion.

3.32.4 Hardware
No impact.

No impact.

License
license.
Table 3-58 describes the parameters added or modified on the RNC side for this feature enhancement.

RAN14.0
Modified UlLdrFirstAction ADD The InterFreqLDHO option is added
parameter UNODEBLDR to parameters UlLdrFirstAction to
UlLdrSeventhActi MOD UlLdrSeventhAction in the
on UNODEBLDR command ADD UNODEBLDR or
MOD UNODEBLDR. The
parameters UlLdrFirstAction
through UlLdrSeventhAction
specify the first to the seventh uplink
LDR actions. The InterFreqLDHO
option indicates an eighth LDR
action choice: inter-frequency
handover based on uplink credit
resources. With this action added,
LDR action choices extend to the
following:
NoAct
BERateRed
QoSRenego
AMRRateRed
InterFreqLDHO
Added parameter UlLdrEighthActio ADD The parameter is added to specify
n UNODEBLDR the eighth LDR action. As with the
MOD seven previously-mentioned LDR
UNODEBLDR actions, the eighth LDR action has
eight action choices.
Added parameter UlInterFreqHoCe ADD The parameter is added to specify
LDRSpaceThd UNODEBLDR the uplink credit margin threshold in
MOD the target cell for performing a load-
UNODEBLDR based inter-frequency handover
triggered by uplink credit resource
congestion. A cell can be selected as
the target cell only if the uplink credit
margin of the cell group including the
cell and that of the NodeB both
exceed this threshold. The uplink
credit margin for LDR is calculated
by subtracting the uplink reserved
credit resources for LDR

RAN14.0
Table 3-59 describes two cell-level counters added on the RNC side to measure load-based inter-
frequency handovers triggered by credit resource congestion.
Change Type Counter Measuremen Description
t Unit
Added counter VS.HHO.AttInter HHO.CELL Number of PS Inter-Frequency Hard
FreqOut.PS.UlC Handover Attempts Based on UL Credit
E Resources for Cell
Added counter VS.HHO.SuccInt HHO.CELL Number of Successful PS Inter-Frequency
erFreqOut.PS.Ul Hard Handovers Based on UL Credit
CE Resources for Cell
Fault Management
No impact.

Load-based inter-band blind handovers of this feature depend on the WRFD-020103 Inter-Frequency
Load Balance feature.
3.33 WRFD-020503 Outer Loop Power Control (Enhanced/Basic)

3.33.1 Description
This feature is an enhanced feature in RAN14.0.
In versions earlier than RAN14.0, outer loop power control allows the uplink SIRtarget to quickly increase
but slowly decrease, wasting uplink power.
Outer loop power control is enhanced in RAN14.0 to allow different adjustment methods of the SIRtarget
in scenarios where uplink power is wasted. The scenarios include RB establishment or reconfiguration,
burst interference, and UE transmit power insufficiency.
Compared with versions earlier than RAN14.0, the enhanced feature reduces the uplink power waste
and increases cell uplink capacity using the following methods:
Use a larger step to decrease the SIRtarget so that the SIRtarget quickly decreases when RB
establishment or reconfiguration is complete.
Disable SIRtarget adjustment in a specified time to prevent sudden increases in the SIRtarget due to
short-term burst interference.
Set the uplink SIRtarget to the initial value when the UE transmit power is insufficient, and use a larger
step to decrease the SIRtarget when the UE transmit power becomes sufficient.

RAN14.0

System Capacity
The enhanced feature allows SIRtarget quick adjustment in scenarios of service establishment or
reconfiguration, burst interference, and UE transmit power insufficiency. The enhanced feature reduces
the uplink power waste and increases cell uplink capacity.
After RB reconfiguration, if the SIR on the DPCCH drastically increases from a low level to a high level,
the NodeB still uses the low SIRtarget when RB configuration has just taken effect, because
PC_RL_RECFG_SIR_TARGET_CARRY_SWITCH under the PcSwitch parameter of the RNC is
turned off by default. As a result, this feature yields no uplink capacity gains. If uplink capacity gains are
required in this scenario, it is recommended that PC_RL_RECFG_SIR_TARGET_CARRY_SWITCH
under the PcSwitch parameter of the RNC be turned on by using the SET UCORRMALGOSWITCH
command and PERFENH_RL_RECFG_SIR_CONSIDER_SWITCH under the PerfEnhanceSwitch
parameter of the RNC be turned on by using the SET UCORRMPAR command.
Network Performance
After the enhanced feature is introduced, more uplink power resources are saved.

3.33.4 Hardware
No impact.

No impact.

License
The feature enhancement in RAN14.0 has no impact on the license.
The feature enhancement has an impact on the RNC parameters, as shown in Table 3-60.
Command
Added switch PC_OLPC_FastD PcSwitch SET The switch controls the
own_Optimize_S UCORRMAL enhanced feature.
WITCH GOSWITCH
Added parameter - SIRtargetDo SET UOLPC This parameter specifies
wnSpeed the SIRtarget quick
decrease step.

RAN14.0

Command
Added parameter - RefSIRtarget ADD/MOD This parameter specifies
UTYPRABOL an RAB-specific
PC convergence value of the
SIRtarget when RB
establishment or
reconfiguration is
complete on the DCH.
Added parameter - RefSIRtarget ADD/MOD This parameter specifies
UTYPRABHS an RAB-specific
UPAPC convergence value of the
SIRtarget when RB
establishment or
reconfiguration is
complete on the E-DCH.
No impact.
Fault Management
No impact.

No impact.
3.34 WRFD-140211 Dynamic Target RoT Adjustment

(New/Optional)
3.34.1 Description
In the HSUPA fast scheduling algorithm, the target RoT is an important parameter that reflects the cell
uplink load level. A large target RoT leads to a heavy uplink cell load but a small uplink cell coverage
area. In a live network, the cell coverage varies greatly with radio environments, such as densely
populated urban areas and suburbs. Setting the target ROT to a fixed value cannot account for varied
radio environments. In a cell with good coverage, for example, in central business districts (CBDs), if
the target ROT is set to a relatively small value, the uplink cell load may reach the preset maximum
when the UE transmit power is still sufficient. This limits the uplink cell throughput. Therefore, Dynamic
Target RoT Adjustment is introduced to adaptively adjust the target RoT to increase the uplink cell
throughput without affecting the cell coverage.
This feature is implemented as follows:
When the actual cell load approaches or exceeds the maximum target load level and the transmit
power of all UEs in the cell is sufficient, the RNC gradually raises the maximum target cell load level
to increase cell throughput.
When the transmit power of an R99 UE in a cell is insufficient or when the transmit power of an
HSUPA UE in a cell is insufficient and its throughput is lower than the preset threshold, the RNC
rapidly decreases the maximum target cell load level to prevent KPIs from degrading.

RAN14.0

System Capacity
In scenarios where the cell coverage is not limited, this feature raises the target RoT to increase the
maximum uplink load for HSUPA UEs, increasing the uplink cell throughput. When the uplink traffic is
heavy, the uplink capacity can be increased by up to 20%.
Network Performance
Cell coverage has an inverse relationship with cell capacity. In a cell where there are no UEs with
limited transmit power, this feature increases the target RoT for the cell and cell coverage shrinks with
the increase of uplink cell throughput. As a result, the RRC connection success rate decreases. In a cell
where there are UEs with limited transmit power, this feature increases cell coverage by reducing the
target RoT at a step (MaxTargetUlLoadFactor specifies the lower limit). Before the target RoT is
adjusted to a proper value, call drops, handover failures, and throughput decrease may occur on the
UEs with limited transmit power.

3.34.4 Hardware
The BTS3812E, BTS3812A, and BTS3812AE support this feature after EBBI, EBOI, EULP and EDLP,
or EULPd and EDLP boards are configured and downlink cells are established on the EBBI, EBOI, or
EDLP boards.
The DBS3800 supports this feature after EBBC or EBBCd boards are configured and downlink cells are
established on the EBBC or EBBCd boards.
The 3900 series base stations support this feature after WBBPb, WBBPd, or WBBPf boards are
configured, and downlink cells are configured on the WBBPb, WBBPd, or WBBPf boards.

The NodeB sends the RNC a COMMON MEASUREMENT REPORT message containing the standard
IE UL Timeslot ISCP, which is "borrowed" by dynamic target ROT adjustment feature. The values of this
IE are as follows:
0: indicates that the NodeB requests the RNC to reduce the target RoT.
1: indicates that the NodeB requests the RNC to increase the target RoT.
2: indicates that the NodeB requests the RNC to keep the target RoT unchanged.

License
Table 3-61 describes the new parameters related to WRFD-140211 Dynamic Target RoT Adjustment on
the RNC side.

RAN14.0

DynTgtRoTCtrlSwitch ADD UCELLHSUPA Determines whether Dynamic Target RoT
Adjustment is enabled
TgtRoTAdjPeriod ADD UCELLHSUPA Period at which the RNC makes
decisions on whether to adjust the target
RoT
TgtRoTUpAdjStep ADD UCELLHSUPA Step size for increasing the target RoT
TgtRoTDownAdjStep ADD UCELLHSUPA Step size for reducing the target RoT
UpLimitForMaxULTgtLd ADD UCELLHSUPA Upper limit of the uplink load factor,
Factor which corresponds to the upper limit of
the target RoT. The relationship between
the uplink load factor and the RoT is as
follows:
RoT = -10 x log10(1 Uplink load factor)
After this feature is enabled, the value of the existing counter VS.HSUPA.MeanBitRate.WithData that
measures cell throughput increases.
This feature adds new counters on the RNC side, as shown in Table 3-62.
VS.HSUPA.TgtRoTInc ALGO2.Cell This counter measures the number of times
the RNC decides to increase the target RoT
within a specified period.
VS.HSUPA.TgtRoTDec ALGO2.Cell This counter measures the number of times
the RNC decides to reduce the target RoT
within a specified period.
Fault Management
No impact.

This feature depends on WRFD-010612 HSUPA Introduction Package.
This feature is independent of WRFD-020136 Anti-Interference Scheduling for HSUPA. Gains from the
two features are as follows:
In scenarios with external interference, Anti-Interference Scheduling for HSUPA has a positive gain.
In scenarios without external interference, Dynamic Target RoT Adjustment has a positive gain.

RAN14.0
In scenarios with IC, this feature, together with WRFD-020137 Dual Threshold Scheduling with HSUPA
Interference Cancellation, produces a greater gain in uplink capacity when compared with only the latter.
This is achieved by increasing the target RoT before and after IC when a cell has good coverage.
3.35 WRFD-140220 Intelligent Battery Management

(New/Optional)
3.35.1 Description
With this feature:
Batteries automatically switch between the charge-and-discharge modes depending on the selected
grid type, which prolongs the battery life.
The battery self-protection function is triggered at high ambient temperatures, which prevents battery
overuse and damage.
Battery runtime is displayed if the mains supply is cut off. Users can then take measures to prevent
service interruption, thereby reducing operating expense (OPEX).

System Capacity
No impact.
Network Performance
No impact.

This feature is implemented on the NodeB and M2000.
This feature does not depend on other NEs outside the RAN, such as the CN and UE.
3.35.4 Hardware
This feature applies only to APM30H (Ver.C), TP48600A, and BTS3900AL hardware.

No impact.

License
A NodeB-level license for this feature is added on the NodeB side.
This feature adds the following parameter to the NodeB.

Added parameter SET Whether to activate Intelligent Battery
BATIMS
EQUIPMENT Management

RAN14.0
No impact.
Fault Management
No impact.

No impact.
3.36 WRFD-02040005 Inter-Frequency Redirection Based on

Distance (New/Optional)
3.36.1 Description
This feature is available from RAN14.0.
Inter-Frequency Redirection Based on Distance is designed to solve excessive coverage problems in
UMTS cells.
Upon receiving an RRC CONNECTION REQUEST message from the UE, the RNC obtains the
propagation delay of the UE and compares it with the propagation delay threshold for inter-frequency
RRC redirections. If the propagation delay of the UE is greater than the threshold, the RNC considers
that the UE is in a cell with excessive coverage, and it triggers inter-frequency redirection based on
distance. Using this feature increases the RRC connection setup success rate and reduces the call
drop rate.

System Capacity
No impact.
Network Performance
Table 3-63 lists the impact of this feature on KPIs.
Table 3-63 Impact on KPIs
KPI Impact
Access RRC Setup Success Ratio This feature redirects UEs at the cell edge or in cells
with excessive coverage problems to inter-frequency
neighboring cells, which increases the RRC
connection setup success rate. The RRC
CONNECTION REJECT messages from RRC
redirections based on distance (including inter-RAT
and inter-frequency redirections) are not considered
as RRC connection setup failures. Therefore, such
rejections do not affect the RRC connection setup
success rate.

RAN14.0
KPI Impact
Maintainability Call Drop Ratio This feature redirects UEs at the cell edge or in cells
with excessive coverage problems to inter-frequency
neighboring cells, which reduces the call drop rate.

3.36.4 Hardware
No impact.

No impact.

License
This feature is not controlled by a separate license. As a sub-feature, it is controlled by the license for
the feature WRFD-020400 DRD Introduction Package.
Table 3-64 lists the new parameters on the RNC side.
Change Type Parameter ID MML Command Meaning
New InterFreqRedirSwitch ADD Whether to allow for
UCELLDISTANCEREDIREC inter-frequency
TION / SET redirection based on
UDISTANCEREDIRECTION distance. When this
switch is turned on,
distance-based inter-
frequency redirection is
allowed when an RRC
connection is being set
up. When this switch is
turned off, such
redirection is not
allowed
New InterFreqRedirDelayThd ADD Propagation delay
UCELLDISTANCEREDIREC threshold for inter-
TION / SET frequency redirection.
UDISTANCEREDIRECTION When the propagation
delay between a UE
and the NodeB
exceeds this threshold,
the inter-frequency

RAN14.0

redirection based on
distance algorithm will
be triggered. For
details about
propagation delay, see
3GPP TS 25.433.
New InterFreqRedirFactorOfL ADD Inter-frequency
DR UCELLDISTANCEREDIREC redirection factor for
TION / SET LDR. This parameter is
UDISTANCEREDIRECTION used to determine
whether to trigger the
inter-frequency
distance algorithm
when the cell enters
the LDR or OLC state.
When this parameter is
set to 0, the algorithm
will not be triggered
even though the cell
has entered the LDR or
OLC state.
New InterFreqRedirFactorOf ADD Inter-frequency
Norm UCELLDISTANCEREDIREC redirection factor for
TION / SET the normal state. This
UDISTANCEREDIRECTION parameter is used to
determine whether to
trigger the inter-
frequency redirection
based on distance
algorithm when the cell
load is within the valid
range. When this
parameter is set to 0,
the algorithm will not
be triggered when the
cell load is within the
valid range.
New RedirBandInd ADD Frequency band of the
UCELLDISTANCEREDIREC target UL and DL
TION / SET UARFCNs to which the
UDISTANCEREDIRECTION UE is redirected. It is
recommended that this
parameter is set to
Depending on the
configuration of
neighboring cells
without the
consideration of NRNC
neighboring cells, that
is, in the non-

RAN14.0

overlapped network.
This helps avoid auto-
redirection. Auto-
redirection is a case in
which redirection is
initiated in the current
cell when the UARFCN
to which the UE is
redirected is the same
as that of the current
cell.
New RedirUARFCNUplinkInd ADD Whether the target UL
UCELLDISTANCEREDIREC UARFCN to which the
TION / SET UE is redirected needs
UDISTANCEREDIRECTION to be configured.
TRUE indicates that
the UL UARFCN needs
to be configured.
FALSE indicates that
the UL UARFCN does
not need to be
manually configured
and it is automatically
configured according to
the relationship
between the UL and
DL UARFCNs.
New RedirUARFCNUplink ADD Target uplink UARFCN
UCELLDISTANCEREDIREC of a cell for RRC
TION / SET redirection. The value
UDISTANCEREDIRECTION range of the UL
UARFCN depends on
the value of
"RedirBandInd."
New RedirUARFCNDownlink ADD Target DL UARFCN for
UCELLDISTANCEREDIREC the RRC redirection.
TION / SET Different values of
UDISTANCEREDIRECTION "RedirBandInd"
correspond to different
value ranges of the
UARFCN.
Table 3-65 lists the parameter changes on the RNC side.

RAN14.0
Table 3-65 Parameter changes on the RNC side

Change Type Before After MML Command Change Reason
Parameter name Redirection Inter-Rat ADD The parameter

change Switch Redirection Switch UCELLDISTANCEREDI name has been
RECTION / SET changed to
UDISTANCEREDIRECT differentiate the
ION parameters for inter-
frequency
distance from those
for inter-RAT RRC
distance.
Parameter name Propagation Inter-Rat Redirect ADD The parameter
change delay Propa Delay Thres UCELLDISTANCEREDI name has been
threshold RECTION / SET changed to
frequency
distance from those
for inter-RAT RRC
distance.
change Factor Of Redirection Factor UCELLDISTANCEREDI name has been
LDR Of LDR RECTION / SET changed to
frequency
distance from those
for inter-RAT RRC
distance.
change Factor Of Redirection Factor UCELLDISTANCEREDI name has been
Normal Of Normal RECTION / SET changed to
frequency
distance from those
for inter-RAT RRC
distance.

RAN14.0
Table 3-66 lists the new and modified counters on the RNC side.
Table 3-66 New and modified counters on the RNC side
Counter Name Measurement Description
Unit
VS.RRC.Rej.Redir.Dist.IntraRat RRC.SetupFail This counter measures the
.Cell number of distance-based RRC
inter-frequency redirections in the
cell. VS.RRC.Rej.Redir.IntraRat
and VS.RRC.Rej.Redir.InterRat
are not measured when the
rejection is due to distance-based
redirection.
VS.RRC.Rej.Redir.Dist RRC.SetupFail This counter provides the number
.Cell of RRC connection rejects due to
distance-based redirection in the
cell, including inter-RAT
redirections and inter-frequency
redirections.
VS.RRC.Rej.Redir.IntraRat and
VS.RRC.Rej.Redir.InterRat are
not measured when the rejection
is due to distance-based
redirection.
Fault Management
No impact.

No impact.
3.37 WRFD-140224 Fast CS Fallback Based on RIM

(New/Optional)
3.37.1 Description
This feature is new in RAN14.0. Fast CS Fallback Based on RIM allows the RNC to transmit system
information of UMTS cells to the eNodeB before CSFB is performed. RIM is short for RAN information
management. When a UE initiates a CS service in the LTE network and the service needs to be
transferred to the UMTS network by redirection-based CS fallback (CSFB), the eNodeB sends the UE
an RRC CONNECTION RELEASE message that contains the system information of the target UMTS
cell. Upon receiving the message, the UE can access the target UMTS cell by sending an RRC
CONNECTION REQUEST message. This reduces the UE access delay and improves user experience.
The procedure for Fast CS Fallback Based on RIM is as follows:

RAN14.0
After the eNodeB sends the RNC a message requesting the system information of the UMTS cells,
the RNC responds with the requested information. If the cell system information (except for the UL
interference IE in SIB7) is changed, the RNC sends the updated system information to the eNodeB.
When a UE initiates a CS service in the LTE network and the service needs to be transferred to the
UMTS network by redirection-based CSFB, the eNodeB sends the UE an RRC CONNECTION
RELEASE message that contains the frequency, primary scrambling code, and system information of
the target UMTS cell.
Upon receiving the message, the UE sends the target UMTS cell an RRC Connection Request
message without reading the cell system information.

System Capacity
No impact.
Network Performance
The impact of this feature on network performance is as follows:
Fast CS Fallback Based on RIM reduces the CSFB delay by up to 1.28 seconds.
The RRC connection setup success rate may slightly decrease. This is because the RNC always
sends the eNodeB the value of -105 dBm as the value of the IE UL interference no matter how the
value is changed. When the UMTS uplink interference is higher than this value, the uplink PRACH
transmit power of the UE increases, which reduces the RRC connection setup success rate.

The feature has the following dependencies on the NEs:
The Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) must support RIM
procedures that comply with 3GPP Release 9 or later.
The UE must comply with 3GPP Release 9 or later and support Fast CS Fallback Based on RIM.
3.37.4 Hardware
No impact.

The procedures for obtaining the initial system information of the UMTS cells increase the load on the
RNC, core network (CN), and Iu interface. Therefore, Fast CS Fallback Based on RIM is recommended
during off-peak hours. The procedures for obtaining the updated system information have minor impacts
on the load on the RNC, CN, and Iu interface. This is because the MIB, SIB1, SIB3, SIB5, and SIB7
(except for the UL interference IE in SIB 7) barely change.

License
Table 3-67 lists the new parameter added on the RNC side.

RAN14.0
Table 3-67 New parameter

PROCESSSWI SET When the switch is turned off, the
TCH2: URRCTRLSWITCH BSC6900 supports fast CSFB(CS
FAST_CS_FB_ fallback) based on RIM.
BASEDON_RI When the switch is turned on, the
M_SWITCH BSC6900 does not support fast
CSFB(CS fallback) based on RIM.
Table 3-68 and Table 3-69 list the new counters added on the RNC side.
Table 3-68 Counters that measure the RIM procedures between the RNC and CN
Unit
VS.IU.RanInfo None This counter is increased by one when the
Req.Rx RNC receives a RAN INFORMATION
REQUEST message from the CN.
VS.IU.RanInfo. None This counter is increased by one when the
Tx RNC sends a RAN INFORMATION
message to the CN.
Table 3-69 Cell-level counters that measure the RIM procedures between the RNC and UE
Unit
VS.RRC.AttCo None This counter provides the number of RRC
nnEstab.WithSI CONNECTION REQUEST messages that
.CsDomain are for PS services, are received by the
RNC from the UE, and carry the value
TRUE for "System Information Container
Stored Indication".
VS.RRC.SuccC None This counter provides the number of RRC
onnEstab.With CONNECTION SETUP COMPLETE
SI.CsDomain messages that the RNC receives from the
UE after the RNC receives RRC
CONNECTION REQUEST messages that
are from the UE, for CS services, and carry
the value TRUE for "System Information
Container Stored Indication". This counter
is measured in the cell.

RAN14.0
Fault Management
No impact.

Fast CS Fallback Based on RIM requires the LTE feature LOFD-001052 Flash CS Fallback to UTRAN.
Fast CS Fallback Based on RIM must be enabled on both the RNC and eNodeB sides. If Fast CS
Fallback Based on RIM is not enabled on the eNodeB side, do not enable it on the RNC side.
Otherwise, the unnecessary RIM procedures initiated by the RNC will waste resources.
The eNodeB can apply the system information of the UMTS cells obtained by RIM procedures to other
types of LTE-to-UMTS redirections, such as load- and coverage-based PS redirections. This helps
shorten the redirection duration by up to 1.28 seconds. The load- and coverage-based PS redirections
relate to the following LTE features:
LOFD-001019 PS Inter-RAT Mobility between E-UTRAN and UTRAN
LOFD-001044 Inter-RAT Load Sharing to UTRAN
3.38 WRFD-140226 Fast Return from UMTS to LTE (New/Try)

3.38.1 Description
In scenarios where UMTS and LTE networks are deployed, if a multimode UE supporting UMTS and
LTE initiates a CS service in an LTE cell, the UE can access a UMTS cell by using a CS fallback (CSFB)
procedure. In versions earlier than RAN14.0, after finishing all its services in the UMTS cell, the UE can
return to the LTE cell by using only cell reselection. The reason is that the RRC CONNECTION
RELEASE message does not contain LTE frequencies and therefore the UE cannot determine whether
there is a neighboring LTE cell that meets the conditions for UE camping.
In RAN14.0, the Fast Return from UMTS to LTE feature was introduced to accelerate UMTS-to-LTE cell
reselection and improve user experience. With this feature, the RNC includes frequencies with higher
absolute priorities that are used by neighboring LTE cells in the RRC CONNECTION RELEASE
message. After releasing the RRC connection, the UE considers this information. If one of these LTE
cells meets the conditions for cell reselection, the UE attempts to camp on this LTE cell.
System Capacity
No impact.
Network Performance
Before this feature is enabled, it takes about 8 seconds for a CSFB-enabled UE to reselect an LTE cell.
After this feature is enabled, it takes only 480 milliseconds or less.
However, if signal quality of LTE frequencies contained in the RRC CONNECTION RELEASE message
is poor and does not meet the conditions for UE camping, the UE keeps searching for specified LTE
frequencies for at least 10 seconds, as stipulated in 3GPP specifications. If the UE fails to find a
suitable cell in the specified frequencies within 10 seconds, the UE searches for all LTE frequencies
supported by the UE. If the UE still fails to find the suitable LTE cell, the UE randomly camps on any
GSM or UMTS cell. When searching for LTE frequencies, the UE cannot originate or terminate a call. In
laboratory tests, Huawei E398 is used. The test results show that the Huawei E398 searches for LTE
signals for 23 seconds before it camps on a UMTS cell in a weak LTE coverage area.

RAN14.0

This feature is implemented on the RNC and requires either of the following conditions to be fulfilled:
If CSFB is implemented by using redirection, the UE must comply with 3GPP R9.4.0.
If CSFB is implemented by using PS handover, the Handover Request message sent by the LTE
network contains the cause value of "CS Fallback triggered," or this message contains the CSFB
Information IE and the value of this IE is CSFB or CSFB High Priority.
3.38.4 Hardware
No impact.

After this feature is enabled and a CSFB-enabled UE finishes its CS service in a UMTS cell, the RRC
CONNECTION RELEASE message contains frequencies used by neighboring LTE cells, as shown in
Figure 3-5.
Figure 3-5 RRC CONNECTION RELEASE message tracing
License
An RNC-level license has been introduced on the RNC side to accommodate this feature.
The following parameter has been introduced on the RNC side to accommodate this feature.
Table 3-70 New parameter on the RNC side
HoSwitch:HO_ SET Whether the UE preferentially camps on
UMTS_TO_LT UCORRMALGO an LTE cell after finishing the CS
E_FAST_RETU SWITCH service
RN_SWITCH
Check the interval between the time the UE receives an RRC CONNECTION RELEASE message and
the time the eNodeB sends a an RRC CONNECTION REQUEST message.

RAN14.0
Fault Management
No impact.
3.39 WRFD-150237 Horizontal Beamwidth Adjustment

(New/Optional)
3.39.1 Feature Description
This feature is introduced in RAN14.0.
When multiple arrays of antenna elements are placed horizontally and driven by several transceivers
(TRXs), the BTS3803E supports horizontal beamforming. For a site with this configuration, operators
can use this feature to adjust the horizontal beamwidth by changing the weight values for different
antenna arrays on the horizontal plane, therefore optimizing network coverage and improving network
performance.
Figure 3-6 illustrates horizontal beamwidth adjustment. The black ellipse indicates the beam direction of
a wide beam, and the red ellipse indicates the direction of a narrow beam.
Figure 3-6 Horizontal beamwidth adjustment
3.39.2 System Capacity and Network Performance
System Capacity
A wide beam improves network coverage and service offloading; while a narrow beam provides high
antenna gains and is suitable for in-depth network coverage.
When BTS3803Es are closely deployed for providing continuous coverage, a narrow beam better
reduces interference and increases system capacity.
Network Performance
In continuous coverage scenarios, beamwidth adjustment based on the distance between BTS3803Es
increases the success rate for handovers between BTS3803Es.

RAN14.0
3.39.3 NEs
This feature requires the support of the NodeB, M2000, and CME.
3.39.4 Hardware
This feature applies only to the BTS3803E.

None
License
This feature is controlled by licenses at the sector level.
The two MOs (VRETSUBUNIT and VRET) have been added.
The two MML commands (MOD VRETSUBUNIT and LST VRETSUBUNIT) have been added.
Table 3-71 lists the new parameters, MOs, and related MML commands.
Table 3-71 New parameters and MOs
Cha MO Parameter ID MML Command Description
nge
Type
New VRETSU DEVICENO MOD ID of the virtual
para BUNIT VRETSUBUNIT and antenna device
mete LST where a virtual
r VRETSUBUNIT antenna remote
electrical tilt (RET)
subunit is located
New VRETSU SUBUNITNO MOD ID of the RET
para BUNIT VRETSUBUNIT and subunit
mete LST
r VRETSUBUNIT
New VRETSU BEAMAZIMUT MOD Horizontal beam
para BUNIT H VRETSUBUNIT azimuth
mete
r
New VRETSU HORIZONTAL MOD Horizontal
para BUNIT BEAMWIDTH VRETSUBUNIT beamwidth
mete
r
New VRET N/A N/A MO for the virtual
MO RET in AAS
modeling

RAN14.0
None
Fault Management
None
3.39.7 Related Features

The adjustable horizontal bandwidth supported by this feature is constrained by the adjustable azimuth
supported by the WRFD-150238 Azimuth Adjustment feature.
3.40 WRFD-150238 Azimuth Adjustment (New/Optional)

This feature is introduced in RAN14.0.
When multiple arrays of antenna elements are placed horizontally and driven by several transceivers
(TRXs), the BTS3803E supports horizontal beamforming. For a site with this configuration, operators
can use this feature to adjust the horizontal beam azimuth by changing the weight values for different
antenna arrays on the horizontal plane, therefore optimizing network coverage and improving network
performance.
In addition, this feature allows operators to remotely adjust the horizontal beam azimuth, improving
maintenance efficiency and reducing the operating expense (OPEX).
A BTS3803E may not be installed in the best position for reasons such as:
Easy access to power supply or transmission resources
Unnoticeable deployment in scenarios such as residential areas
Figure 3-7 illustrates horizontal beam azimuth adjustment. The dashed black line indicates the normal
line of the beam before azimuth adjustment, and the red line indicates the variation range of the normal
line after azimuth adjustment.

RAN14.0
Figure 3-7 Horizontal beam azimuth adjustment
System Capacity
If the BTS3803E is installed in an inappropriate position, adjusting the horizontal azimuth can make the
antenna beam cover the target area effectively, therefore increasing the system capacity and offloading
efficiency.
Network Performance
User experience is improved after interference is controlled by horizontal azimuth adjustment.
3.40.3 NEs
This feature requires the support of the NodeB, M2000, and CME.
3.40.4 Hardware
This feature applies only to the BTS3803E.

None
License
This feature is controlled by licenses at the sector level.
For details about the new MOs and MML commands, see 3.39 "WRFD-150237 Horizontal Beamwidth Adjustment."
Table 3-72 lists the new parameters, MOs, and related MML commands.

RAN14.0
Table 3-72 New parameters, MOs, and related MML commands

Change MO Parameter ID MML Command Description
Type
New VRETSUBUNIT BEAMAZIMU MOD Horizontal
paramete TH VRETSUBUNIT beam
r azimuth
None
Fault Management
None

The adjustable horizontal beam azimuth supported by this feature is constrained by the adjustable
beamwidth supported by the WRFD-150237 Horizontal Beamwidth Adjustment feature.
3.41 WRFD-140103 Call Reestablishment (New/Basic)

Call reestablishment is a function by which radio links (RLs) are reestablished when a service
interruption or an access failure occurs in temporary coverage holes and in tunnels, elevators, and
buildings that cause significant signal quality fluctuation.
Call reestablishment can be initiated by a UE or the RAN.
Call reestablishment initiated by a UE: The UE sends a call reestablishment request to the network to
restore services upon detecting a downlink RL failure or a signaling radio bearer (SRB) reset.
Call reestablishment initiated by the RAN: After the RAN detects a service interruption or an access
failure (possibly due to an SRB reset or an uplink RL failure) before the UE does, the RAN stops the
UE's downlink RL sets to enable the UE to detect downlink RL failures as soon as possible. Upon
detecting a downlink RL failure, the UE sends a call reestablishment request to the RAN to restore
services.
This document describes only call reestablishment initiated by the RAN.

System Capacity
No impact.
Network Performance
Call reestablishment initiated by a UE reduces the call drop rate. Call reestablishment initiated by the
RAN reduces the call drop rate and ensures user experience.
During call reestablishment, CS UEs may experience temporary one-way audio or no audio. During RB
setups, call reestablishment prolongs the service setup delay.

RAN14.0
3.41.3 NEs
3.41.4 Hardware
No impact.
3.41.5 Inter-NE Interfaces

This feature affects the NBAP_RL_ACT_CMD message on the Iub interface. The RNC uses this
message to notify the NodeB that the downlink RL sets of a UE must be stopped.

License
For this feature, some switches have been added to the RNC, as listed in Table 3-73.
Table 3-73 Switches added for this feature on the RNC
Switch Parameter MML Description
Command
RSVDBIT RsvdPara SET This switch controls whether
1_BIT24 1 URRCTRLSW to trigger call reestablishment
ITCH in case of a CS call drop.
This switch is turned on when
RSVDBIT1_BIT24 is set to 0.
ITCH in case of a PS call drop.
This switch is turned on when
ITCH in case of an SRB reset. This
switch is turned on when
ITCH in case of an RL failure. This

RAN14.0

Command
IUR_RL_ ulProcess SET This switch controls whether
REEST_ Switch4 URRCTRLSW to trigger call reestablishment
SWITCH ITCH when a call is dropped and
there is an Iur link. This
IUR_RL_REEST_SWITCH is
set to 1.
RESERV Reserved SET This switch controls whether
ED_SWI Switch1 UCORRMPA to trigger call reestablishment
TCH_1_ RA in case of a PS TRB reset.
BIT26 This switch is turned on when
RESERVED_SWITCH_1_BI
T26 is set to 1.
ITCH when a UE sends the RNC a
CELL UPDATE message
with a cause value of an SRB
reset. This switch is turned
on when RSVDBIT1_BIT26
is set to 0.
RESERV RsvSwitc SET This switch controls whether
ED_SWI h1 UCORRMPA to trigger call reestablishment
TCH_1_ RA when RB reconfiguration
BIT14 triggered by the DCCC
feature fails. This switch is
turned on when
T14 is set to 1.
RESERV RsvSwitc SET This switch controls whether
ED_SWI h1 UCORRMPA to trigger call reestablishment
TCH_1_ RA when RB reconfiguration
BIT20 triggered by the DCCC
feature expires. This switch is
turned on when
T20 is set to 1.
RNCAP_ ulProcess SET This switch controls whether
RB_SET Switch4 URRCTRLSW to trigger call reestablishment
UP_RL_ ITCH when an SRB reset occurs in
REEST_ an RB setup. This switch is
SWITCH turned on when
RNCAP_RB_SETUP_RL_R
EEST_SWITCH is set to 1.

RAN14.0

Command
ASU_RS ulProcess SET This switch controls whether
P_TIME Switch2 URRCTRLSW to trigger call reestablishment
OUT_HA ITCH when an active set update
NDLE_S expires. This switch is turned
WITCH on when
ASU_RSP_TIMEOUT_HAN
DLE_SWITCH is set to 1.
PHY_RE PROCESS SET This switch controls whether
CFG_RE SWITCH4 URRCTRLSW to trigger call reestablishment
EST_SW ITCH when physical channel
ITCH reconfiguration fails. This
PHY_RECFG_REEST_SWIT
CH is set to 1.
RESERV PROCESS SET This switch controls whether
ED_SWI SWITCH1 URRCTRLSW to trigger call reestablishment
TCH_1_ ITCH when physical channel
BIT19 reconfiguration expires. This
T19 is set to 1.
No impact.
Fault Management
No impact.

No impact.
3.42 WRFD-140104 Enhanced Combined Services(New/Basic)

On networks with CS+PS combined services, the CS service in CS+PS combined services experiences
a higher call drop rate than a single CS service because CS+PS combined services have different
bearer channel types and signaling procedures from a single CS service.
This feature improves the performance of CS+PS combined services by implementing the following
policies: Bearer channel type and access rate control policy for PS BE services in combined services,
service release policy, rate increase policy, and cross processing of signaling procedures for CS+PS
combined services.

RAN14.0

System Capacity
The throughput of a single UE will be reduced if the following control policies are implemented on PS
BE services in combined services when data transmission requirements on the network are large:
The uplink or downlink of PS BE services are fixedly carried on the DCH.
Periodic channel retry is not allowed for PS BE services.
HSUPA services cannot use the 2 ms TTI.
The capacity of PS services on the whole network will be improved if the following policies are
implemented on PS BE services in combined services:
Bearerchannel type and access rate control policy for PS BE services during a setup of combined
services
Servicerelease policy for PS BE services in combined services (excluding the PS BE services not
released after the expiration of PS always online timer function)
CQI feedback period for combined services
Network Performance
The bearer channel type and access rate control policy for PS BE services during a setup of
combined service reduces the call drop rate of CS service in combined services and ensures the
experience of PS UEs because this policy does not control the bearer channel type and access rate
for PS BE services in the follow-up procedures.
The improvement of call drop rates is determined by network coverage, networking topology, and
parameter configurations. For example, on an inter-frequency network, the larger the coverage
scope, the less the improvement. On a network configured with the service steering networking
policy, the improvement is noticeable.
If
PS BE services in combined services cannot use the HSPA technology, they can only be carried
on the DCH that has low data rates when data transmission requirements on the network are large.
In this case, the experience of PS UEs deteriorates when the coverage is good.
If
downlink PS BE services switch from the HS-DSCH to the DCH, and the data rate of PS BE
services is greater than 0 kit/s, the combined services will consume more code resources in the
downlink. If the traffic volume of combined services is high, code resources will be congested.
This policy applies to a network where the frequency of PS BE data transmission in combined
services is low and most data packets are heartbeat packets. For example, PS BE data is transmitted
only one to two times every 90s during the processing of CS services and only heartbeat packets are
transmitted periodically.
Cross processing of signaling procedures for combined services improves the access success rate of
CS UEs.
3.42.3 NEs
3.42.4 Hardware
None
3.42.5 Inter-NE Interfaces

None

RAN14.0

License
The following parameters have been introduced on the RNC side, as describe in Table 3-74.
Table 3-74 New RNC parameters
RsvU8Para0 SET UALGORSVPARA Bearer channel
type and access
rate of PS BE
services during a
setup of combined
services
ReservedSwitch0:RESERVED_SWITCH_ SET UCORRMALGOSWITCH Whether P2D or
0_BIT28 P2F state transition
is first performed if
the UE in the
CELL_PCH or
URA_PCH state
initiates a CS
service
ReservedSwitch0:RESERVED_SWITCH_ SET UCORRMALGOSWITCH Whether the
0_BIT14 access rate of PS
BE services is set
to DCH0K when a
UE processing PS
BE services
initiates a CS
service and
performs a P2D
state transition
ReservedSwitch1:RESERVED_SWITCH_ SET UCORRMALGOSWITCH Whether PS BE
1_BIT6 services use low
data rates after a
UE processing PS
BE services
performs a P2D
state transition
0_BIT15 services in CS+PS
BE combined
services are carried
on the DCH in the
downlink
0_BIT11 services in CS+PS

RAN14.0

PE combined
services are carried
on the DCH in the
uplink
DraSwitch:DRA_CSPS_NO_PERIOD_RE SET UCORRMALGOSWITCH Prohibits UEs
TRY_SWITCH processing PS BE
services in CS+PS
BE combined
services from
performing periodic
channel retry
MapSwitch:MAP_CSPS_TTI_2MS_LIMIT_ SET UCORRMALGOSWITCH Prohibits UEs
SWITCH processing HSUPA
services in
combined services
from using the 2 ms
TTI
RsvSwitch1:RESERVED_SWITCH_1_BIT SET UALGORSVPARA Whether to
7 transition a UE to
the CELL_FACH
state if there is no
PS BE data
transmission after a
CS service release
in CS+PS BE
combined services
PROCESSSWITCH3:PS_INACT_NOTREL SET URRCTRLSWITCH Whether PS BE
_FOR_CSPS_SWITCH services are
released after the
PS always online
times expires in
CS+PS BE
combined services
RsvSwitch6:RESERVED_SWITCH_6_BIT3 SET UALGORSVPARA Whether rate
increase by DCCC
caused by event 4A
is allowed for a UE
with a data rate of
DCH0K in CS+PS
BE combined
services
RsvSwitch1:RESERVED_SWITCH_1_BIT SET UALGORSVPARA Whether rate
8 increase in both the
uplink and downlink
is allowed when
traffic volume-
based event 4A is
received in the
downlink or uplink

RAN14.0

of PS BE services
in CS+PS BE
combined services
ReservedSwitch1:RESERVED_SWITCH_ SET UCORRMPARA: Whether rate
1_BIT16 increase for PS BE
services in CS+PS
BE combined
services depends
on cell load
ReservedU32Para0 SET UNBMPARA Load threshold
factor for
determining
whether rate
increase is allowed
for PS BE services
when cell load-
based rate increase
for PS BE services
in CS+PS BE
combined services
is enabled
RsvSwitch0:RESERVED_SWITCH_0_BIT SET UALGORSVPARA Whether the RNC
17 sends the CN a
SECURITY MODE
COMMAND
REJECT message
when a cell update
procedure is
initiated during a
security mode
control procedure
ReservedSwitch0:RESERVED_SWITCH_ SET UCORRMPARA Whether CS
0_BIT17 service can be set
up during an F2P
state transition
RsvdPara1:RSVDBIT1_BIT21 SET URRCTRLSWITCH Whether the CS
service continues
to be established
when the UE sends
the RNC a CELL
UPDATE message
during a F2D state
transition
RsvSwitch0:RESERVED_SWITCH_0_BIT SET UALGORSVPARA Whether the CS
21 service continues
to be established
when the UE sends
the RNC a CELL
UPDATE message

RAN14.0

during the following
CS service setup
procedures:
The UE
processing PS
BE services in
the CELL_FACH
state initiates a
CS service.
The CS UE has
established an
RRC connection
in the
CELL_FACH
state.
PcSwitch:PC_CQI_CYCLE_BASE_CS_PL SET UCORRMALGOSWITCH Whether the CQI
US_PS_SWITCH feedback period is
specified by the
CQIFBckBaseCsC
ombServ
parameter for the
following combined
services:
The CS service is
carried on the
DCH in the uplink
and the service
type is
conversational
service.
PS BE services
are carried on
HSDPA channels
in the downlink.
CQIFBckBaseCsCombServ SET UHSDPCCH CQI feedback
ADD UCELLHSDPCCH period for CS+PS
BE combined
services
PacketReTransRatio ADD UCELLRLACTTIME Retransmission
rate of signaling
packets in CS+PS
BE combined
services
RsvSwitch1:RESERVED_SWITCH_1_BIT SET UALGORSVPARA Whether PS BE
1 services are
released before the
combined CS hard
handover and
relocation

RAN14.0

procedure when
CS service and PS
BE services in
combined services
use different
relocation policies
The following counters have been added on the RNC side, as described in Table 3-75.
Table 3-75 New RNC counters
Counter Name Measurement Description
Unit
VS.MultiRAB.CSAbnormRel.CSPS UCELL Number of Abnormal CS Service Releases of
CS+PS Combined Services for Cell
VS.MultiRAB.CSNormRel.CSPS UCELL Number of Normal CS Service Releases of
VS.MultiRAB.PSNormRel.CSPS UCELL Number of Normal PS Service Releases of
VS.MultiRAB.PSAbnormRel.CSPS UCELL Number of Abnormal PS Service Releases of
VS.MultiRAB.SuccEstab.CSPS UCELL Number of Successful CS+PS Combined
Service Setups for Cell
VS.MultiRAB.AttEstab.CSPS UCELL Number of CS+PS Combined Service Setup
Requests for Cell
Fault Management
None

None
3.43 GSM Power Control on Interference Frequency for GU

Small Frequency gap (New/Optional/GU)
3.43.1 Description
This multi-mode feature is new in SRAN7.0. It includes the following GBSS14.0 and RAN14.0 features:
MRFD-211804 GSM Power Control on Interference Frequency for GU Small Frequency gap (GSM)
MRFD-221804 GSM Power Control on Interference Frequency for GU Small Frequency gap (UMTS)

RAN14.0
In small GSM/UMTS frequency spacing scenarios (such as GU refarming 3.8 MHz and GU refarming
4.2 MHz), this feature reduces the interference of GSM to UMTS in the downlink by decreasing the
transmit power of the GSM frequency that is 2.0 MHz or 2.2 MHz away from the UMTS center
frequency, thereby increasing HSDPA throughput. Figure 3-8 shows the GU refarming 3.8 MHz and GU
refarming 4.2 MHz scenarios.
Figure 3-8 GU refarming 3.8 MHz and GU refarming 4.2 MHz
GSM data is sent in bursts on each TCH by using frequency hopping (FH). When the GSM data is
transmitted on a frequency that is 2.0 MHz or 2.2 MHz away from the UMTS center frequency, GSM
actively performs power compression on this frequency to reduce the interference to UMTS in the
downlink. To compensate for power loss caused by power compression, GSM performs power
compensation on non-interfering frequencies that also participate in FH. Power compression further
decreases the power after power control whereas power compensation further increases the power
after power control. Figure 3-9 illustrates the principles of power compression and power compensation.

RAN14.0
Figure 3-9 Principles of power compression and power compensation
In addition, GSM compensates for the decreased signal level to prevent cell-edge MSs from
unnecessary handovers.

System Capacity
In GU refarming 3.8 MHz and GU refarming 4.2 MHz scenarios, this feature improves HSDPA
performance of the UMTS network operating at 900 MHz by reducing the transmit power of the GSM
frequency that is 2.0 MHz or 2.2 MHz away from the UMTS center frequency.
The HSDPA performance is improved in the following aspects:
Reduced HSDPA interference
Enhanced HSDPA link quality
Increased HSDPA cell throughput
Increased average number of HSDPA UEs
Network Performance
To guarantee the GSM or UMTS network quality means to decrease the GSM receive quality. However,
to guarantee the UMTS network quality will greatly affect GSM key performance indicators (KPIs). The
affected GSM KPIs include the call drop rate, handover success rate, channel assignment success rate,
congestion rate, and mean opinion score (MOS). In addition, power compensation for non-interfering
frequencies increases the average downlink transmit power.
The following two policies are alternative:
Preferentially guaranteeing the GSM network quality
The GUDegratePwrPri parameter is set to GSM(GSM).
During power decrease:

RAN14.0
If
the power of non-interfering frequencies is sufficiently compensated, the transmit power of the
interfering frequency decreases to the desired value, which is equal to the maximum TRX transmit
power minus the value of the GU2000KHzMaxVal parameter.
If
the power of non-interfering frequencies is insufficiently compensated, the transmit power of the
interfering frequency decreases to the allowed value, which is determined based on the power
compensation amplitude.
Preferentially guaranteeing the UMTS network quality
The GUDegratePwrPri parameter is set to UMTS(UMTS). During power decrease, the transmit power
of the interfering frequency decreases to the desired value regardless of whether the power of non-
interfering frequencies is sufficiently compensated or not.
When the transmit power of GSM frequencies is reduced, the interference of GSM to UMTS
decreases. This improves the UMTS KPIs and affects the GSM KPIs. The improved UMTS KPIs
include HSDPA throughput and downlink quality-related counters, such as call drop rate and RAB
setup success rate.
Table 3-76 lists the affected GSM and UMTS KPIs.
Table 3-76 Affected GSM and UMTS KPIs
Mode KPI Impact
High quality indicator (HQI) Decrease
Call drop rate Slight increase

Channel assignment success rate Slight decrease
GSM Handover success rate Slight decrease
MOS Slight decrease
Average downlink transmit power Increase
Congestion rate Slight increase
HSDPA throughput Increase
UMTS Call drop rate Decrease
RAB setup success rate Increase

This feature is implemented on the GSM BSC, GSM BTS, and NodeB.
3.43.4 Hardware
No impact.

No impact.

RAN14.0

License
A site-level license for this feature is added on the GSM BSC side.
A site-level license for this feature is added on the NodeB side.
This feature introduces the parameters on the GSM BSC side, as shown in Table 3-77. This feature has
no impact on the UMTS side.
Table 3-77 New parameters on the GSM BSC side
Change Parameter MML Command Description
Type ID
Added GUDegrate SET Whether to enable frequency-
paramete PwrCtrl GCELLNonStand based power control
r ardBW
Added CELLID SET Cell in which frequency-based
paramete GCELLNonStand power control is enabled
r ardBW
Added GUDegrate SET Frequency-based power control
paramete PwrPri GCELLNonStand policy.
r ardBW If this parameter is set to
GSM(GSM), this feature
guarantees the GSM network
quality while minimizing
interference to the UMTS
network. If the non-interfering
frequencies do not obtain
sufficient power compensation,
the transmit power of the
interfering frequency cannot be
minimized.
If this parameter is set to
UMTS(UMTS), this feature
preferentially guarantees the
UMTS network quality. Even if the
non-interfering frequencies do not
obtain sufficient power
compensation, the transmit power
of the interfering frequency can
be minimized.
Added GU2000KHz SET Maximum decrease in the
paramete MaxVal GCELLNonStand transmit power of the interfering
r ardBW frequency when there is a 2.0
MHz frequency spacing between
the GSM and UMTS networks.
The desired transmit power of the
interfering frequency that is 2.0
MHz away from the UMTS center

RAN14.0

Type ID
frequency is equal to the
maximum TRX transmit power
minus the value of this parameter.
Added GU2200KHz SET Maximum decrease in the
paramete MaxVal GCELLNonStand transmit power of the interfering
r ardBW frequency when there is a 2.2
MHz frequency spacing between
the GSM and UMTS networks.
The desired transmit power of the
interfering frequency that is 2.2
MHz away from the UMTS center
frequency is equal to the
maximum TRX transmit power
minus the value of this parameter.
Added UMTSFreqN SET Downlink absolute radio
paramete um1 GCELLNonStand frequency channel number
r ardBW (ARFCN) for the first UMTS
frequency that has a 2.0 MHz or
2.2 MHz spacing with the GSM
frequency in GU refarming
scenarios.
Added UMTSFreqN SET Downlink ARFCN for the second
paramete um2 GCELLNonStand UMTS frequency that has a 2.0
r ardBW MHz or 2.2 MHz spacing with the
GSM frequency in GU refarming
scenarios.
Added NAHRComp SET Proportion of power
paramete Coeff GCELLNONSTAN compensation for the non-
r DARDBW interfering frequencies to power
decrease each time the transmit
power of the interfering frequency
is decreased by 1 dB for
enhanced full rate (EFR), full rate
(FR), half rate (HR), and adaptive
multirate (AMR) FR calls. When
this parameter is set to 0, power
compensation is not performed on
the non-interfering frequencies.
Added NAHRComp SET Power compensation offset for
paramete OffVal GCELLNonStand EFR, FR, HR, and AMR FR calls.
r ardBW This parameter is used to
calculate the power compensation
for the non-interfering
frequencies.
Added AHRCompC SET Proportion of power
paramete oeff GCELLNonStand compensation for the non-
r ardBW interfering frequencies to power
decrease each time the transmit

RAN14.0

Type ID
power of the interfering frequency
is decreased by 1 dB for AMR HR
calls. When this parameter is set
to 0, power compensation is not
performed on the non-interfering
frequencies.
Added AHRComp SET Power compensation offset for
paramete OffVal GCELLNonStand AMR HR calls. This parameter is
r ardBW used to calculate the power
compensation for the non-
interfering frequencies.
This feature adds the counters on the GSM BSC side, as shown in Table 3-78. This feature has no
impact on the UMTS side.
Table 3-78 New counters on the GSM BSC side
Type t Unit
Added CELL.2MDISTUR GBTS.GCELL Average Power Decrease on
counter B.AVG.FALL.POW GSM 2.0 MHz Interfering
ER.RANGE Frequency
Added CELL.2.2MDISTU GBTS.GCELL Average Power Decrease on
counter RB.AVG.FALL.PO GSM 2.2 MHz Interfering
WER.RANGE Frequency
Added CELL.UNDISTUR GBTS.GCELL Average Power Increase on
counter B.AVG.UP.POWE GSM Non-Interfering
R.RANGE Frequency
Fault Management
No impact.

This feature must be used together with the WRFD-021001 Flexible frequency bandwidth of UMTS
carrier feature or must be used with both of the following features:
MRFD-211703 2.0MHz Central Frequency point separation between GSM and UMTS mode (GSM)
MRFD-221703 2.0MHz Central Frequency point separation between GSM and UMTS mode (UMTS)
The UMTS network performance improves when this feature is used with any of the following features:
WRFD-020136 Anti-Interference Scheduling for HSUPA
GBFD-117601 HUAWEI III Power Control Algorithm

RAN14.0
GBFD-117602 Active Power Control

GBFD-114801 Discontinuous Transmission (DTX) Downlink
GBFD-114803 Discontinuous Transmission (DTX) Uplink
3.44 Dynamic MA for GU Dynamic Spectrum Sharing

(New/Optional/GU)
3.44.1 Description
This multi-mode feature is new in SRAN7.0. It includes the following on the GBSS14.0 and RAN14.0:
MRFD-211803 Dynamic MA for GU Dynamic Spectrum Sharing (GSM)
MRFD-221803 Dynamic MA for GU Dynamic Spectrum Sharing (UMTS)
This feature enables the BSC to change the mobile allocation (MA) of a timeslot set. After this feature is
enabled, the BSC monitors the channel occupation condition of the cell and determines whether the
spectrum sharing or spectrum reclaim conditions are met. When the conditions are met, the BSC
selects the timeslot set that is suitable for MA changing in a cell and starts a timer. When the timer
expires, the BSC notifies the BTS to change the MA of the timeslot set without affecting GSM services.

System Capacity
This feature increases the network throughput and single-user throughput by sharing GSM spectrum
with UMTS because UMTS has higher spectral efficiency than GSM.
In the GSM and UMTS Dynamic Spectrum Sharing feature which was introduced in SRAN6.0, a GSM
cell generally uses a single MA when spectrums are not shared. In addition, the BSC can share
spectrums only when the traffic volume of the cell is lighter than what can be carried on the BCCH TRX.
This limits the opportunities for spectrum sharing.
With the Dynamic MA for GU Dynamic Spectrum Sharing feature, the BSC shares spectrums without
affecting GSM services by changing the MA of timeslots when the traffic volume of the cell is lighter
than what can be carried on two or three TRXs. This increases the opportunities for spectrum sharing
and therefore increases the PS service throughput.
Network Performance
GSM network performance:
This feature reduces the GSM bandwidth because the BSC shares GSM spectrum with UMTS. The
impact on GSM KPIs is as follows:
The number of handovers increases.
During spectrum sharing, MSs are handed over from one TRX to another, and therefore the number
of handovers in the cell increases.
The call drop rate increases.
During spectrum sharing, the number of ARFCNs in the MA for GSM decreases. Therefore, the FH
gain decreases, the internal interference of GSM increases, and the call drop rate increases.
The service quality during drive test deteriorates.
During spectrum sharing, the FH gain decreases, the internal interference of GSM increases, and the
service quality during drive test deteriorates.
The congestion rate increases.

RAN14.0
During spectrum sharing, the number of TRXs for GSM decreases. Therefore, the congestion rate
may increase.
UMTS network performance:
The number of inter-frequency handovers increases.
During spectrum sharing, many MSs in the UMTS cell are handed over to new frequencies through
inter-frequency handovers. Similarly, when the UMTS reclaims spectrums to GSM, many MSs are
handed over to the original frequencies through inter-frequency handovers. As a result, the number of
inter-frequency handovers in the UMTS cell increases.
The inter-frequency handover success rate may decrease.
When the UMTS reclaims spectrums to GSM, a timer is started for inter-frequency handovers and
calls drop when the timer expires. During a sudden spectrum reclaim, blind handovers are performed.
Therefore, the inter-frequency handover success rate may decrease.
The call drop rate may increase.
When the UMTS reclaims spectrums to GSM, a timer is started for inter-frequency handovers and
calls drop when the timer expires. During a sudden spectrum reclaim, blind handovers are performed.
Therefore, the call drop rate may increase.

This feature is implemented on the GSM BSC, GSM BTS, and NodeB.
3.44.4 Hardware
No impact.

No impact.

License
A site-level license for this feature is added on the NodeB side.
A site-level license for this feature is added on the GSM BSC side.
The Dynamic MA for GU Dynamic Spectrum Sharing feature must be activated before this feature is
enabled.
This feature introduces the parameters on the GSM BSC side, as shown in Table 3-79. This feature has
no impact on the UMTS side.
Table 3-79 New parameters on the GSM BSC side
Change Parameter ID MML Command Description
Type
Added TRXDSSHOPI SET FH index of channels after
parameter NDEX GTRXCHANHOP spectrum sharing

RAN14.0
Change Parameter ID MML Command Description

Type
Added TRXDSSMAIO SET MAIO of channels after
parameter GTRXCHANHOP spectrum sharing
This feature introduces the BSC-level counters on the GSM BSC side, as shown in Table 3-80. This
feature has no impact on the UMTS side.
Table 3-80 New counters on the GSM BSC side
Type t Unit
Added CELL.DYN.MA.R GBTS.GCELL Number of dynamic MA changing
counter EQ requests
Added CELL.DYN.MA.S GBTS.GCELL Number of successful dynamic

counter UCC MA changing
Added CELL.DYN.MA.F GBTS.GCELL Number of failed dynamic MA

counter AIL changing
Fault Management
No impact.

Required Features
MRFD-211802 GSM and UMTS Dynamic Spectrum Sharing (GSM)
MRFD-221802 GSM and UMTS Dynamic Spectrum Sharing (UMTS)
GBFD-113701 Frequency Hopping (RF hopping, baseband hopping)

GBFD-117001 Flex MAIO
MRFD-211703 2.0MHz Central Frequency point separation between GSM and UMTS mode (GSM) or
MRFD-221703 2.0MHz Central Frequency point separation between GSM and UMTS mode (UMTS)
Affected Features
Handover algorithm: During dynamic MA changing, the BSC performs an intra-cell handover on MSs in
the GSM cell.
Admission algorithm: During dynamic MA changing, the BSC preferentially allocates timeslots with new
MA to new MSs.

RAN14.0
3.45 Multi-mode BS Common IPSec (New/Optional/GUL)

3.45.1 Description
This multi-mode feature is new in SRAN7.0. It includes the following on the GBSS14.0, RAN14.0, and
eRAN3.0:
MRFD-211602 Multi-mode BS Common IPSec (GSM)
MRFD-221602 Multi-mode BS Common IPSec (UMTS)
MRFD-231602 Multi-mode BS Common IPSec (LTE)
In IP networking, IPSec provides secure data transmission and encryption for base stations and
ensures confidentiality, integrity, and availability for transmission. IPSec security services are offered at
the IP layer, and therefore the following upper layers can use the security services:
Transmission Control Protocol (TCP)
User Datagram Protocol (UDP)
Internet Control Message Protocol (ICMP)
Stream Control Transmission Protocol (SCTP)
IPSec is a protocol suite for IP communications security and provides high-quality, interoperable, and
cryptography-based security for IP packet transmission. Communication parties ensure the following
security characteristics of data transmission on the network by encrypting and authenticating IP packets:
Confidentiality: User data is encrypted and transmitted in ciphertext.
Integrity: The received data is verified to determine whether the data has been tampered with.
Authentication: Data origin is verified to confirm the sender of the data.
Anti-replay: The main goal of anti-replay is to prevent malicious attackers from repeatedly sending
captured packets. The receiver discards old or repeated packets.
In dual-mode and multi-mode scenarios, IPSec tunnels are shared among GSM, UMTS, and LTE
modes by using the UTRP board or by interconnecting the GTMU and the LTE UMPT through the
backplane. This ensures secure data transmission and reduces operator's deployment costs. Figure 3-
10 illustrates the multi-mode networking.
Figure 3-10 Multi-mode networking
GSM
UMTS UTRP IP Backhaul
IP1 IPsec Tunnel
LTE IP2
SecGW BSC/SGW/MME/RNC

System Capacity
This feature has no impact on system capacity. However, a new IPSec header is prefixed to the IP
packet after IPSec is enabled. Therefore, a higher transmission bandwidth is required for the same
amount of network traffic. The increase in bandwidth varies depending on the site and traffic model.

RAN14.0
Network Performance
This feature improves transmission security for base stations. However, this feature involves encryption
and decryption and therefore increases transmission delay. The increase in one-way delay is less than
0.1 ms and can be ignored.

This feature requires that the MBTS in GSM/UMTS/LTE mode support IPSec.
3.45.4 Hardware
This feature requires Huawei multi-mode base stations (MBTSs) and depends on the following
hardware:
UTRPc
In dual-mode and multi-mode scenarios, this feature depends on the new UTRPc board introduced in
SRAN7.0.
GTMU and UMPT
In GL dual-mode scenarios, this feature requires that the GTMU and the LTE UMPT be
interconnected through the backplane.

This feature affects only the private interface between the MBTS and the M2000.

License
Site-level licenses for this feature are added on the GSM BSC, NodeB, and eNodeB.
When this feature is enabled, IPSec must be configured for the base station that controls the UTRPc
board. No new parameter related to this feature is added.
No new counter related to this feature is added.
Fault Management
No new alarm or event related to this feature is added.

Required Features
MRFD-221501 IP-Based Multi-mode Co-Transmission on BS side (NodeB)
Atleast, one of these features (GBFD-113524 BTS Integrated IPsec, WRFD-140209 NodeB
Integrated IPSec, LOFD-003009 IPsec) is required.
Affected Features
UMTS Automatic Address Configuration Protocol (AACP)
Multi-mode BS Common IPSec cannot be used together with the UMTS AACP function.

RAN14.0
In scenarios with IPSec enabled, the DHCP server must allocate an interface IP address to the base
station before site deployment is performed. The base station then uses the IP address to set up a
temporary IPSec tunnel to the SeGW and communicates with the M2000. In UMTS AACP, the
M2000 allocates the IP address through the SeGW. The SeGW, however, cannot transfer AACP
packets to the base station, which leads to AACP failures.
BTS Local Switch
Multi-mode BS Common IPSec cannot be used together with the GBFD-117702 BTS Local Switch
feature.
The BTS supports BTS Local Switch. When IPSec is used, implementing BTS Local Switch requires
the SeGW to transfer packets. However, BTS Local Switch is a Huawei proprietary feature, with
which the BTS cannot interconnect with the SeGW and does not perform Interoperability Test (IOT)
with the SeGW.
3.46 IP-Based Multi-mode Co-Transmission on BS side

(Enhanced/Optional/GUL)
3.46.1 Description
This multi-mode feature is enhanced in SRAN7.0. It includes the following on the GBSS14.0, RAN14.0,
and eRAN3.0:
MRFD-211501 IP-Based Multi-mode Co-Transmission on BS side (GBTS)
MRFD-231501 IP-Based Multi-mode Co-Transmission on BS side (eNodeB)
In SRAN7.0, this feature introduces a new function in which an MBTS supports IP-based co-
transmission through backplane interconnection. This function includes main-control-board-based co-
transmission through backplane interconnection and UTRPc-based co-transmission through backplane
interconnection.
NOTE
Both dual- and triple-mode base stations support IP-based co-transmission through backplane interconnection.
Co-transmission through panel interconnection
In this co-transmission mode, the main control board of a mode provides the co-transmission port and
the main control boards of all modes are connected through backplane interconnection. The co-
transmission port must be an FE/GE port.
Figure 3-11 shows an example of network topology for main-control-board-based IP co-transmission
through backplane interconnection on the GUL MBTS side.

RAN14.0
Figure 3-11 Main-control-board -based IP co-transmission through backplane interconnection on the GUL
MBTS side
MME
UCIU
S-GW
GTMUb
IP
UMPT_U network
GBSC
UMPT_L
RNC
MBSC
As shown in Figure 3-11, the UMPT_U provides the co-transmission port and the main control board of
LTE is connected to the UCIU through the CI optical ports. The UCIU is managed by GSM or UMTS
that is in the same BBU of the UCIU. It is recommended that GSM be preferentially used as the
managing mode of the UCIU, then UMTS, and the last LTE. Service data of GSM is transmitted
between the GTMUb and the UMPT_U through the UCIU. Service data of LTE is transmitted between
the UMPT_U and the UMPT_L through the UCIU.
UTRPc-based co-transmission through backplane interconnection
In this co-transmission mode, the UTRPc board of a mode provides the co-transmission port and the
main control boards of all modes are connected through backplane interconnection. The co-
transmission port must be an FE/GE port.
When a UTRPc is used for co-transmission, the UTRPc forwards data for multiple modes but is
managed by only one mode. The mode that manages the UTRPc is called the managing mode, and
other modes are called non-managing modes.
Figure 3-12 shows an example of network topology for UTRPc-based IP co-transmission through
backplane interconnection on the GUL MBTS side.

RAN14.0
Figure 3-12 UTRPc-based co-transmission through backplane interconnection on the GUL MBTS side
MME/S-GW
...
UCIU UTRPc IP
network
GTMUb
UMPT_U
MBSC
UMPT_L
As shown in Figure 3-12, the UTRPc provides the co-transmission port and the UMPT_L is connected
to the UCIU through the CI optical ports. The UCIU is managed by GSM or UMTS that is in the same
BBU of the UCIU. It is recommended that GSM be preferentially used as the managing mode of the
UCIU, then UMTS, and the last LTE. Service data of GSM and UMTS is directly transmitted between
the UTRPc and the service board of each mode. Service data of LTE is transmitted between the UTRPc
and the UMPT_L through the UCIU.

System Capacity
No impact.
Network Performance
No impact.

This feature is implemented on the GSM BTS, GSM BSC, NodeB, and CME.
3.46.4 Hardware
IP co-transmission on the GU MBTS side
GSM and UMTS base station should share the BBU to support this feature.
Main-control-board-based co-transmission through backplane interconnection requires that the
GTMUb be configured on the BTS side and the UMPT_U be configured on the NodeB side.

RAN14.0
UTRPc-based co-transmission through backplane interconnection requires that the GTMUb be

configured on the BTS side and the UTPRc be configured on the NodeB side.
IP co-transmission on the UL MBTS side
UMTS mode and LTE FDD mode boards must be co-located within the same BBU.
UMPT_U be configured on the NodeB side.
It is recommended that the UTRPc be configured on the eNodeB side in the case of UTRPc-based
co-transmission through backplane interconnection.
IP co-transmission on the GL MBTS side
GTMUb be configured on the BTS side.
It is recommended that the UTRPc be configured on the eNodeB side in the case of UTRPc-based
co-transmission through backplane interconnection.
IP co-transmission on the GUL MBTS side
A triple-mode base station supports BBU cascading by interconnecting the UCIU and UMPT boards
in two BBUs. BBU cascading by UCIU+UMPT enables the different modes of the GSM, UMTS, and
LTE to share the transmission resources.
GTMUb be configured on the BTS side, the UMPT_U be configured on the NodeB side, and the
UMPT_L be configured on the eNodeB side.
UTRPc-based co-transmission through backplane interconnection requires that the GTMUb be
configured on the BTS side. When the NodeB or eNodeB uses an independent BBU, the UMPT_U
must be configured on the NodeB side and the UMPT_L must be configured on the eNodeB side. It is
recommended that the UTRPc be configured on the eNodeB side.

No impact.

License
A site-level license for this feature exists on the GSM BSC side.
A site-level license for this feature exists on the NodeB side.
A site-level license for this feature exists on the eNodeB side.
The following commands are added to GSM BTS, NodeB, and eNodeB.
Change Type MML command Description

Added command SET BRDRAT Setting RAT of the UTRPc board
Added command ADD TUNNEL Adding a backplane tunnel for the
UTRPc board
Added command RMV TUNNEL Removing a backplane tunnel for the
UTRPc board

RAN14.0
Change Type MML command Description

Added command LST TUNNEL Listing backplane tunnels for the UTRPc
board
The following parameters are modified on NodeB, eNodeB.

Type ID Command
Modified PT ADD/MOD Port type. Added the port type of
parameter RSCGRP tunnel to configure transmission
resource groups on tunnels.
Modified PT SET Port type. Added the port type of
parameter RSCGRPALG tunnel to configure the transmission
resource group algorithm on tunnels.
Modified PT ADD/MOD Port type. Added the port type of
parameter IPPATH tunnel to configure IP paths on
tunnels.
Modified PT ADD/RMV Port type. Added the port type of
parameter HSUPAFLOW tunnel to configure HSUPA flow
CTRLPARA control on tunnels.
parameter HSDPAFLOW tunnel to configure HSDPA flow
CTRLPARA control on tunnels.
parameter IP2RSCGRP tunnel to configure the mapping
between an IP address and a
transmission resource group on
tunnels.
Modified PT SET LR Port type. Added the port type of
parameter tunnel to configure data rate limitation
on tunnels.
Counters related to this feature are measured on transmission ports. Therefore, no new counter is
added for this feature.
Fault Management
No impact.

IP co-transmission on the GU MBTS side

RAN14.0
GBFD-118601 Abis over IP or GBFD-118611 Abis IP over E1/T1

WRFD-050402 IP Transmission Introduction on Iub Interface
IP co-transmission on the UL MBTS side
IP co-transmission on the GUL MBTS side
GBFD-118601 Abis over IP
WRFD-050402 Iub over IP
3.47 IP-Based Multi-mode Common Clock on BS side

(Enhanced/Optional/GUL)
3.47.1 Description
This multi-mode feature is enhanced in SRAN7.0. It includes the following on the GBSS14.0, RAN14.0,
and eRAN3.0:
MRFD-211601 IP-Based Multi-mode Common Clock on BS side (GBTS)
MRFD-211601 IP-Based Multi-mode Common Clock on BS side (NodeB)
MRFD-231601 Multi-mode BS Common Reference Clock(eNodeB)
In SRAN7.0, this feature introduces a new function to support IP-Based Multi-mode Common Clock of a
triple-mode.
As shown in Figure 3-13 and Figure 3-14, one mode of a GUL triple-mode base station is configured
with a synchronous Ethernet clock source, which is then shared by the other two modes.
As shown in Figure 3-13, BBU Interconnection is activated on a GUL triple-mode base station. The
WMPT board receives synchronous Ethernet clock signals from the transport network using an FE link
and forwards them to the GTMU and UCIU boards. Upon receiving the clock signals, the UCIU board
sends them to the UMPT board.
As shown in Figure 3-14, BBU Interconnection is also activated on a GUL triple-mode base station. The
UMPT board receives synchronous Ethernet clock signals from the transport network using a GE link
and forwards them to the UCIU board. Upon receiving the clock signals, the UCIU board sends them to
the GTMU and WMPT boards.

RAN14.0
Figure 3-13 A common synchronous Ethernet reference clock in the primary BBU of a GUL triple-mode
base station
Figure 3-14 A common synchronous Ethernet reference clock in the secondary BBU of a GUL triple-mode
base station

RAN14.0

System Capacity
No impact.
Network Performance
No impact.

No impact.

No impact.

License
A site-level license for this feature exists on the GSM BSC side.
A site-level license for this feature exists on the eNodeB side.
No impact.
No impact.
No impact.
3.47.6 Impact on Other NEs

No impact.

No impact.
3.48 Bandwidth sharing of MBTS Multi-mode Co-Transmission

(Enhanced/Optional/UL)
3.48.1 Description
This multi-mode feature is enhanced in SRAN7.0. It includes the following on the RAN14.0 and
eRAN3.0:
MRFD-221505 Bandwidth sharing of MBTS Multi-mode Co-Transmission (NodeB)
MRFD-231505 Bandwidth sharing of MBTS Multi-mode Co-Transmission (eNodeB)

RAN14.0
This feature is applicable to scenarios of IP over FE/GE co-transmission of an MBTS. In SRAN7.0, this
feature introduces a new function to enable bandwidth sharing between UMTS and LTE. Figure 3-15
shows the networking mode.
Figure 3-15 Networking mode in bandwidth sharing of MBTS multi-mode co-transmission
GTP-U
GTP-U
GTP-U
GTP-U
GTP-U
GTP-U
GTP-U
GTP-U
GTP-U
GTP-U
UDP UDP
IP IP
IP SW IP SW IP
eNodeB LTE LTE MME/S-GW
/ Rou Rou
UMTS UMTS /
ter ter
PPP PPP
FP
FP
FP
FP
FP
FP
NodeB Co-transmission
FP Frame Protocol RNC
In LTE/UMTS co-transmission, telecom operators uniformly manage the UMTS and LTE transmission
resources by defining service priorities and assigning different bandwidth to services with different
priorities. When transmission resource congestion occurs, this feature maintains the continuity of high-
priority services by allowing them to dynamically share transmission resources.
Telecom operators can assign different priorities to UMTS and LTE services, for example, LTE signaling,
LTE voice service, LTE high-priority data service, LTE low-priority data service, UMTS signaling, UMTS
voice service, R99 data service, and HSPA service. Differentiated services code point (DSCP) values
are assigned according to the priority of each service. Transmission nodes preferentially forward data
packets of high-priority services based on DSCP values.
On detecting transmission resource congestion, the MBTS automatically reduces the bandwidth
allocation for low-priority services based on the service priority policies to eliminate congestion. This
ensures that the actual transmission bandwidth occupied by UMTS and LTE services during peak hours
always approaches the configured bandwidth (for example, 10 Mbit/s).
This feature allows telecom operators to reduce the investments in transmission devices. In UMTS/LTE
co-site scenarios, this feature reduces the transmission cost and simplifies the transmission network. In
addition, this feature enables the smooth evolution from UMTS to LTE.

System Capacity
No impact.
Network Performance
If inter-RAT parameter settings, such as inter-RAT bandwidth allocation and inter-RAT QoS planning,
are inappropriate, enabling this feature increases the service congestion rate. That is, the data rate of
low-priority services such as BE services decreases and their packets may be lost.
With appropriate network planning, this feature does not affect the network performance.

This feature is implemented on the RNC, NodeB, and eNodeB.
To enable this feature, the transmission devices on the bearer network must support DSCP-based
scheduling and level-1 shaping based on physical ports.

RAN14.0
3.48.4 Hardware
No impact.

No impact.

License
A site-level license for this feature is added on the eNodeB side.
To enable this feature, QoS parameters must be planned on the UMTS and LTE networks in a unified
way. In addition, the planned QoS parameters must be configured on the transmission equipment.
No parameter is added for this feature on the UMTS and LTE side.
No impact.
Fault Management
No impact.

This feature enhancement depends on the following features:
MRFD-231501 IP-Based Multi-mode Co-Transmission on BS side (eNodeB)
3.49 Other Impacts

3.49.1 Introduction
In RAN14.0, the following enhancements and improvements have been added:
Increased maximum number of FACH users
Shortened RRC CONNECTION SETUP message
Enhanced call reestablishment
Dynamic activation time adjustment for 13.6 kbit/s signaling
HSPA serving cell change in weak-coverage scenarios
Canceling of inter-frequency handovers of speech services
Optimized control mechanism for inter-frequency handovers
Asynchronous reconfiguration for inter-frequency handovers
Intelligent fast state transition
Priorities of inter-RAT handovers and inter-frequency handovers

RAN14.0
Optimization for uplink power admission

Protection against outer-loop power control congestion in the case of a high RTWP
Fast synchronization on the physical layer (L1)
UMTS-to-LTE fast return
PS RRC resource preemption
Initial TTI selection for coverage-based BE services
RSCP-based cell reselection
Dynamic BLER Adjustment for AMR Voice Services
Maintenance mode alarms
Optimized mechanism for handling major VSWR alarms
Standby/active switchover time configured based on BFD
3.49.2 Increased Maximum Number of FACH Users

RAN14.0 no longer has a limitation on the maximum number of users in the CELL_FACH state whose
CCCH/DCCH/DTCH is mapped onto the FACH in the downlink and onto the RACH in the uplink
(referred to as FACH users for short) in a cell. Compared with RAN13.0, RAN14.0 increases the
maximum number of E-FACH or E-RACH users in a cell from 48 to 300.
After the preceding limitation is removed, more online users can stay in the CELL_FACH state. This
prevents frequent state transitions, which reduce the control plane load and the cell load on the Uu
interface. However, increases in FACH bandwidth usage may lead to FACH congestion, which can be
alleviated by FACH decongestion.
Removing the limitation increases the number of FACH users and therefore brings the following
changes:
The FACH becomes more severely congested and a TRB reset occurs, which increases the downlink
call drop rate.
A large amount of data is transmitted on the RACH. Therefore, when the number of FACH users
increases and the number of users in the CELL_DCH state basically remains unchanged, the uplink
RTWP and call drop rate increase.
When the total number of FACH users and users in the CELL_DCH state basically remains
unchanged, more FACH users result in fewer users in the CELL_DCH state. This reduces the RTWP
in the cell and the transmit power of non-HSPA channels, increasing the RAB setup success rate.
The limitation on the maximum number of FACH users carried on the S-CCPCH can be removed by
running the RNC MML command ADD UCELLALGOSWITCH or MOD UCELLALGOSWITCH with
FACH_USER_NUM_NOT_CTRL under NBMCacAlgoSwitch set to 1. The
FACH_USER_NUM_NOT_CTRL switch is turned off by default.
MAXEFACHUserNum and MaxERACHUserNum in the RNC MML command ADD UCELLCAC or
MOD UCELLCAC specify the maximum number of E-FACH users and the maximum number of E-
RACH users, respectively.
3.49.3 Shortened RRC CONNECTION SETUP Message

In RAN14.0, the RRC CONNECTION SETUP message sent from the RNC to the UE is shortened by
replacing the information element (IE) RLC info under SRB3 or SRB4 with the IE same as RB:0x2(2).
This function enables more UEs to receive the shortened message when coverage is weak and
increases the success rate of radio resource control (RRC) connection setup.

RAN14.0
This function can be enabled by turning on the RRC_CONN_SETUP_OPT_SWITCH switch under

PROCESSSWITCH4 in the SET URRCTRLSWITCH command. This switch is turned off by default.
3.49.4 Enhanced Call Reestablishment

RAN14.0 supports call reestablishment in the following scenarios:
Scenario 1: A call fails to be set up due to a signaling radio bearer (SRB) reset during a physical
channel reconfiguration. The physical channel reconfiguration may occur during the following
processes:
Compressed mode startup
Intra- or inter-frequency hard handover
Serving cell change
Code tree reshuffling
HSUPA power adjustment
Event 6D or 6F reporting
Scenario 2: A call fails to be set up when an SRB reset occurs or the RNC receives a CELL UPDATE
message during a radio bearer (RB) setup.
Scenario 3: Call reestablishment is implemented across the Iur interface.
This function can be enabled by turning on one of the following switches under PROCESSSWITCH4 in
the SET URRCTRLSWITCH command:
PHY_RECFG_REEST_SWITCH: applies to scenario 1 and is turned off by default.
RB_SETUP_RL_REEST_SWITCH: applies to scenario 2 and is turned off by default.
IUR_RL_REEST_SWITCH: applies to scenario 3 and is turned off by default.
With this function, the call drop rate decreases and the service setup success rate increases. For
combined services, the probability of service setup failures or call drops decreases. However, this
function has the following negative impacts:
CS users may experience temporary one-way audio or mute phenomenon.
Service setup delay increases during an RB setup.
3.49.5 Dynamic Activation Time Adjustment for 13.6 kbit/s

Signaling
If the signal quality Ec/No of the best cell reported by a UE is greater than or equal to the preset
threshold, the RNC does not change the current activation time offset for 13.6 kbit/s signaling. If the
signal quality Ec/No is smaller than the preset threshold, the RNC increases the activation time offset.
The threshold is specified by the RNC parameter ActtimeAdjustQualThd in the SET UFRC command.
In scenarios with weak coverage, this function increases the number of signaling messages
retransmitted at the Radio Link Control (RLC) layer during a synchronous reconfiguration. Therefore,
the probability of UEs receiving the signaling messages increases, which in turn increases the service
access success rate. In this case, service setup delay is prolonged by about 500 ms.
The value range of ActtimeAdjustQualThd is -24 to 0 (in unit of dBs). The default value of this
parameter is -24, indicating that this function is unavailable.

RAN14.0
3.49.6 HSPA Serving Cell Change in Weak-Coverage Scenarios

Upon receiving an event 1D report, the RNC does not trigger an HSPA serving cell change if the Ec/Io
of the target serving cell is smaller than the threshold specified by the RNC parameter
WeakCovHSPAQualThds in the SET UHOCOMM command.
In scenarios with weak coverage, this function reduces frequent HSPA serving cell changes, which in
turn reduces the call drop rate. In this case, however, UEs may not be handed over in a timely manner
to target cells with better signal quality, and data transmission performance may deteriorate for UEs
processing both CS and PS services.
The value range of WeakCovHSPAQualThds is -24 to 0 (in unit of dBs). The default value of this
parameter is -24, indicating that this function is unavailable.
3.49.7 Canceling of Inter-Frequency Handovers of Speech Services

When a UE is performing an inter-frequency handover, the RNC does not immediately release the radio
link for the UE upon receiving a PHYSICAL CHANNEL RECONFIGURATION FAILURE message. The
UE returns to the source cell.
This function reduces call drops caused by inter-frequency handover failures in speech services, which
improves user experience. After a handover failure, if the hyper frame number (HFN) of the UE is not
adjusted based on the change in the connection frame number (CFN), there is a possibility that speech
noise occurs.
This function can be enabled by turning on the AMR_HHO_FAIL_ROLLBACK_SWITCH switch under
PROCESSSWITCH4 in the RNC MML command SET URRCTRLSWITCH. This switch is turned off by
default.
3.49.8 Optimized Control Mechanism for Inter-Frequency

Handovers
In periodic measurements for an inter-frequency handover, a UE must report downlink signal quality of
the best cell in the original active set. If the signal quality Ec/No is greater than the upper threshold
UsedFreqUpperThdEcNo or is smaller than the lower threshold UsedFreqLowerThdEcNo, the RNC
does not trigger the inter-frequency handover.
When the signal quality Ec/No is smaller than the lower threshold, inter-frequency handovers are not
performed. This prevents handover failures and call drops due to UEs not receiving any inter-frequency
handover instruction during fast fading of the source cell. When the signal quality Ec/No is greater than
the upper threshold, the source cell can still ensure radio link quality and user experience after
measurement results are reported. In this case, inter-frequency handovers are unnecessary, which
prevents handover failures and call drops caused by fast fading in the target cell.
This function can be enabled by turning on the HO_HHO_WITH_INTRA_FREQ_MR_SWITCH switch
under HoSwitch in the SET UCORRMALGOSWITCH command. This switch is turned off by default.
3.49.9 Asynchronous Reconfiguration for Inter-Frequency

Handovers
In scenarios where the uplink and downlink transport channels carrying SRBs remain unchanged
before and after inter-frequency handovers, RAN14.0 introduces asynchronous reconfiguration.
Compared with synchronous reconfiguration, asynchronous reconfiguration does not require activation
time and therefore increases the number of retransmitted RLC packet data units (PDUs) in a
PHYSICAL CHANNEL RECONFIGURATION message.

RAN14.0
This function increases the probability of UEs receiving PHYSICAL CHANNEL RECONFIGURATION
messages so that UEs can achieve fast synchronization with the target cell. This provides the following
advantages:
Increased handover success rate
Reduced call drop rate
Shortened signaling delay during inter-frequency handovers
During an inter-frequency handover, however, service interruption delay may increase by 10 ms to 50
ms.
For inter-frequency handovers that are not across the Iur interface:
For a CS service, this function can be enabled by turning on the CS_HHO_ASYNC_CTRL_SWITCH
switch under PROCESSSWITCH4 in the RNC MML command SET URRCTRLSWITCH. This switch
is turned off by default.
For a PS service, this function can be enabled by turning on the PS_HHO_ASYNC_CTRL_SWITCH
switch under PROCESSSWITCH4 in the RNC MML command SET URRCTRLSWITCH. This switch
is turned off by default.
For inter-frequency handovers across the Iur interface, this function can be enabled by turning on the
preceding switches and the IUR_HHO_ASYNC_CTRL_SWITCH switch under PROCESSSWITCH4.
The IUR_HHO_ASYNC_CTRL_SWITCH switch is turned off by default.
3.49.10 Intelligent Fast State Transition

In RAN14.0, intelligent fast state transition enables the RNC to analyze and estimate a UE's data
transmission based on historical data sent from the UE and determine whether to perform fast state
transition on the UE. Before enabling this function, the CELL_PCH function must be enabled on the
network.
RAN14.0 implements intelligent fast state transition in two scenarios.
Scenario 1: From CELL_DCH to CELL_FACH

For a UE in connected mode, the RNC counts the interval between the time when the UE moves from
the CELL_DCH to CELL_FACH state and the time when the UE moves back from the CELL_FACH to
CELL_DCH state. Based on the interval at which the UE currently transmits data, the RNC estimates
the interval for subsequent data transmission. If the current interval is greater than a threshold specified
by the RNC parameter TthdForSFSTUserIdentify, the RNC decides to perform fast state transition on
the UE. Upon completing data transmission, the UE quickly moves from the CELL_DCH state to the
CELL_FACH state.
Compared with state transition controlled by a default timer in earlier versions, fast state transition in
scenario 1 enables UEs to move from the CELL_DCH state to the CELL_FACH state in a shorter
period of time after data transmission. This provides the following advantages:
Reduces the time when UEs without data transmission use DCHs
Reduces the Uu interference from the UE on other UEs
Increases system capacity
Improves CE resource utilization
Fast state transition in scenario 1 applies to networks where there are a large proportion of
smartphones that do not send Signaling Connection Release Indication (SCRI) messages. In this
scenario, this function is controlled by the DRA_SMART_FAST_STATE_TRANS_SWITCH switch
under DraSwitch in the RNC MML commands SET UCORRMALGOSWITCH and ADD
UCELLDCCC/MOD UCELLDCCC, which are used to set the switch for the RNC and cell, respectively.

RAN14.0
Scenario 2: From CELL_PCH to CELL_DCH

For a connected UE, the RNC counts the data transmission volume between the time when the UE
moves from the CELL_PCH state to the CELL_FACH or CELL_DCH state and the time when the UE
moves back from the CELL_FACH or CELL_DCH to CELL_PCH state. The RNC collects the UE's data
transmission volume for multiple occurrences to predict the UE's data transmission volume for the next
occurrence.
If the data transmission volume is consistently greater than the threshold specified by the RNC
parameter TvmThdForSmartP2D, the RNC predicts that the UE's data transmission volume will be
greater than this threshold at the next occurrence. When the UE transmits data at the next
occurrence, the RNC directly puts the UE in the CELL_PCH state into the CELL_DCH state for fast
transmission.
If the data transmission volume is not consistently greater than this threshold, the RNC predicts that
the UE will transmit a small amount of data at the next occurrence. When the UE transmits data at the
next occurrence, the RNC puts the UE in the CELL_PCH state into the CELL_FACH state.
In RAN14.0, the cell-level 4A threshold is configurable and is specified by the RNC parameter
BeF2DHTvmThdForFACHCong. In case of FACH congestion in a cell, this threshold can be set to a
small value. Fast state transition in scenario 2 has the following advantages:
Reduces FACH congestion in the cell.
Reduces delay during transmission of a large amount of data.
Improves user experience.
In this scenario, this function is controlled by the DRA_PCH_UE_SMART_P2D_SWITCH switch under
DraSwitch in the RNC MML commands SET UCORRMALGOSWITCH and ADD UCELLDCCC/MOD
UCELLDCCC, which are used to set the switch for the RNC and cell, respectively.
3.49.11 Priorities of Inter-RAT Handovers and Inter-frequency

Handovers
This function only works for coverage-based inter-RAT handovers and inter-frequency handovers.
When a user needs to perform an inter-RAT or inter-frequency handover, the RNC first delivers an inter-
frequency measurement control message and starts a timer. The RNC delivers an inter-RAT
measurement control message if the timer expires.
With this function, neighboring UMTS cells take precedence over neighboring GSM cells as handover
target cells. This improves user experience and increases the proportion of inter-frequency handovers.
If inter-frequency signals are poor, delay in inter-frequency handovers is longer and therefore call drops
are more likely to occur.
For CS services and CS/PS combined services, the timer is CsHoPrioMeasTimerLen. For PS services,
the timer is PsHoPrioMeasTimerLen. The default values of the timers are 0, indicating that this
function is disabled. If the default values are used, the RNC delivers an inter-RAT measurement control
message and an inter-frequency measurement control message simultaneously. The target cell chosen
depends on which type of measurement report reaches the RNC and meets the handover conditions
earlier. The value of the CsHoPrioMeasTimerLen or PsHoPrioMeasTimerLen parameter cannot be
too large. Otherwise, users cannot be handed over to neighboring inter-RAT cells when there are no
suitable neighboring inter-frequency cells. This increases the probability of call drops.
3.49.12 Optimization for Uplink Power Admission

RAN14.0 provides a new algorithm: uplink power admission algorithm 4. This algorithm makes
admission decisions based on the uplink service load in a cell. It uses service-specific admission
thresholds. When the load of the network is heavy, CS services are admitted on a preferential basis.

RAN14.0
When the ratio of the RTWP in a cell to the background noise remains high, both the average number
of online users and the number of online HSUPA users are large. In this case, this function reduces the
RTWP to improve coverage and lowers the call drop rate to increase the effective capacity of the
system.
When the number of users in a cell is small and the RTWP is high due to heavy traffic, uplink power
admission algorithm 4 has the following advantages over uplink power admission algorithms 1 and 3:
More admitted users
Increased access and handover success rates
Reduced call drop rate
Uplink power admission algorithm 2 is based on the number of equivalent users. When the number of
equivalent users specified by UlTotalEqUserNum is set to a large value using uplink power admission
algorithm 2, compared with uplink power admission algorithm 2, uplink power admission algorithm 4 is
stricter and brings the following changes:
Admits fewer users
Reduces the handover success rate
Increases the call drop rate
In uplink power admission algorithm 4, the uplink service load is calculated based on the background
noise. The background noise used for the calculation depends on whether the Auto-Adaptive
Background Noise Update Algorithm is enabled:
If the algorithm is enabled, the automatically updated background noise is used.
If the algorithm is disabled, the preconfigured background noise is used.
If the background noise used for the calculation is lower than the actual value, the calculated uplink
service load is higher than its actual value, which decreases the admission success rate. If the
background noise used for the calculation is higher than the actual value, the admission success rate
increases. However, the RTWP and call drop rate also increase.
The switch for this function is controlled by the RNC-side cell-level parameter
NBMUlCacAlgoSelSwitch. To enable this function, run the ADD UCELLALGOSWITCH or MOD
UCELLALGOSWITCH command to set this parameter to ALGORITHM_FOURTH.
Uplink power admission algorithm 4 makes admission decisions based on the total uplink service load
which depends on the NodeB boards' measurement of the uplink service load. Not all NodeB boards
support the measurement. Therefore, not all NodeBs support uplink power admission algorithm 4. The
following NodeBs do not support uplink power admission algorithm 4:
The BTS3812A, BTS3812E, and BTS3812AE do not support uplink power admission algorithm 4.
The DBS3800 does not support uplink power admission algorithm 4.
The DBS3900 does not support uplink power admission algorithm 4 if it is configured with a WBBPa
board or a 20 W RRU3801C.
Uplink power admission algorithm 4 cannot be used together with the WRFD-021350 Independent
Demodulation of Signals from Multiple RRUs in One Cell feature.
3.49.13 Measurement of the Actual Uplink Service Load

RAN14.0 introduces the measurement of the actual uplink service load, which takes the received total
wideband power (RTWP), total uplink service load, and minimum guaranteed uplink service load into
consideration. The total uplink service load equals the total load of R99 services, HSUPA services, and
control channels. The minimum guaranteed uplink service load equals the total load of R99 services,
HSUPA services performed at the GBR, and control channels.

RAN14.0
Not all NodeBs support the measurement of the total uplink service load, the minimum guaranteed
uplink service load, and the actual uplink service load. The following NodeBs do not support the
measurement:
The BTS3812A, BTS3812E, and BTS3812AE do not support the measurement.
The DBS3800 does not support the measurement.
The 3900 series base station does not support the measurement if it is configured with a WBBPa
board or a 20 W RRU3801C.
3.49.14 Protection Against Outer-loop Power Control Congestion in

the Case of a High RTWP
With this function, when the RTWP is too high, the NodeB restricts increases in the target signal-to-
interference ratio (SIR) to keep the RTWP within an acceptable range.
When the RTWP is high, this function reduces the RTWP, which has the following impact:
Improves voice service quality
Reduces the target signal-to-interference ratio (SIR) of BE services, and therefore increases the
BLER on DCHs and HARQ retransmissions on HSUPA channels for BE services and reduces the
cell throughput in either of the following scenarios:
The RTWP is high, the external interference is strong, and the cell has a large number of users.
The RTWP is high and most users are located in a certain area of the cell.
The switch for this function is the NodeB parameter RTWPSIRTGTADJSWITCH in the SET
ALGOPARA command. By default, this function is disabled.
3.49.15 Fast Synchronization on the Physical Layer (L1)

RAN14.0 supports fast synchronization on the physical layer for users that do not use Push to Talk
(PTT). For UEs that support R6 or a later release of 3GPP specifications, the information element Post-
Verification Period is sent to the UE during service setups, state transitions, and handovers. Upon
receiving this information element, the UE sends data over the dedicated physical control channel
(DPCCH) on the uplink. The UE does not need to wait for downlink synchronization to complete, and
therefore the delay decreases by 40 ms under optimal conditions.
NOTE
This function was introduced in 3GPP Release 6. However, whether a UE that complies with 3GPP Release 6 or later
supports this function depends on UE implementation. If a UE that complies with 3GPP Release 6 or later does not
support this function, the UE cannot obtain the gain in delay.
If a UE performs multipath searching and channel estimation based on the DPCH or F-DPCH rather than P-CPICH on
the downlink, the number of Transmit Power Control (TPC) error codes increases when the UE sets up a radio link.
The increase of error codes causes the uplink RTWP to fluctuate.
The gain from this function varies depending on the UE. Lab test results show that the average reduction in the delay
for a UE is 25 ms on the user plane and 30 ms on the control plane.
The switch for this function is nonPTT_L1_Fast_Sync_Switch under the RNC-level parameter
PROCESSSWITCH in the SET URRCTRLSWITCH command. By default, this function is disabled.
3.49.16 UMTS-to-LTE Fast Return

In versions earlier than RAN14.0, when a UMTS/LTE dual-mode UE that complies with 3GPP Release
8 or later in a UMTS and LTE overlapping coverage area accesses a UMTS cell due to a CS fallback
(CSFB) and terminates all services in the UMTS cell, the following is implemented:

RAN14.0
The RRC CONNECTION RELEASE message does not contain the frequencies of the neighboring
LTE cells of the UMTS cell.
The UE releases the RRC connection.
This is true irrespective of whether there is a neighboring LTE cell whose frequency has a higher
absolute priority. After releasing the RRC connection, the UE selects and camps on the UMTS cell,
obtains the UMTS cell system information from the MIB, SIB1, SIB3, SIB5, SIB7, or SIB19 message,
and measures the signal quality of neighboring LTE cells. Upon detecting a neighboring LTE cell that
fulfills the criteria for cell reselection, the UE attempts to camp on the LTE cell by using cell reselection.
RAN14.0 supports UMTS-to-LTE fast return. With this function, the RNC sends the RRC
CONNECTION RELEASE message containing the frequencies of the neighboring LTE cells whose
frequencies have higher absolute priorities to the UE. After releasing the RRC connection, the UE
selects and camps on any suitable LTE cell that use the specified frequencies. This function accelerates
UMTS-to-LTE cell reselection and improves user experience.
This function is applicable in any of the following continuous LTE coverage scenarios:
A UMTS/LTE dual-mode UE that originates a CS service in an LTE cell accesses a UMTS cell due to
PS-handover-based CSFB (the cause value carried in the RELOCATION REQUEST message is CS
Fallback triggered (268), or CSFB information carried in the RELOCATION REQUEST message is
set to CSFB or CSFB High Priority) and terminates all services in the UMTS cell.
A UMTS/LTE dual-mode UE that complies with 3GPP Release 9.4.0 or later releases and originates
only CS services in an LTE cell accesses a UMTS cell due to redirection-based CSFB and terminates
all services in the UMTS cell. In addition, the first service that the UE sets up in the UMTS cell is a CS
service.
As indicated in 3GPP specifications, if the signal quality of the LTE frequencies contained in the RRC
CONNECTION RELEASE message does not meet the conditions for UE camping, the UE keeps
searching for these LTE frequencies for at least 10 seconds. Then, the UE attempts to search for all
LTE frequencies supported by the UE. If the UE still cannot detect the optimal LTE cell, the UE
randomly camps on a suitable cell. When searching for LTE signals, the UE cannot originate a call or
be paged. Lab test results show that Huawei's UE E398 equipped searches for LTE signals for 23
seconds before camping on a UMTS cell in weak LTE coverage areas.
The switch for UMTS-to-LTE fast return is HO_UMTS_TO_LTE_FAST_RETURN_SWITCH under the
HoSwitch parameter. By default, this function is disabled. To enable it, run the SET
UCORRMALGOSWITCH command on the RNC and set the value of this switch to 1.
In addition, this feature requires that the following parameters be configured:
SPriority in the ADD UCELLSELRESEL or MOD UCELLSELRESEL command: This parameter
specifies the absolute priority of the serving UMTS cell.
NPriority in the ADD UCELLNFREQPRIOINFO or MOD UCELLNFREQPRIOINFO command: This
parameter specifies the absolute priorities of LTE frequencies.
NOTE
If the value of NPriority is greater than that of SPriority, the LTE cell meets the conditions for UMTS-to-LTE fast return.
In this case, the RRC CONNECTION RELEASE message contains the frequency of a neighboring LTE cell. Otherwise,
this message does not contain the frequency of a neighboring LTE cell.
3.49.17 PS RRC Resource Preemption

The function of preempting PS RRC resources has been added to RAN14.0. RRC resources allocated
to BE services in the PS domain can be preempted.
This function extends the range of resources that can be preempted. When resource congestion occurs
and there are no radio access bearers (RABs) to preempt, high-priority services like CS services can

RAN14.0
preempt RRC resources allocated to BE services in the PS domain. This function raises the setup
success rates of high-priority services.
The switch for this function is the RNC-level parameter PsBERrcPreemptVulnerable. By default, this
function is disabled. To enable it, run the SET UQUEUEPREEMPT command on the RNC to set the
value of this switch to 1.
3.49.18 Initial TTI Selection for Coverage-based BE Services

When a BE service is set up or reconfigured for an HSUPA user and the user meets the conditions for
using a 2-ms transmission time interval (TTI), the following criteria are used for selecting a 2-ms TTI or
a 10-ms TTI:
The RRC CONNECTION REQUEST message received by the RNC contains a P-CPICH Ec/No
value. The RNC sets the TTI to 10 ms when both the conditions are met:
The time that has elapsed since this Ec/No value was reported is less than the value of the
EcN0EffectTime parameter in the RNC command SET UFRC.
This Ec/No value is not greater than the value of the EcN0ThsFor2msTo10ms parameter in SET
UFRC.
Otherwise, the RNC sets the TTI to 2 ms.
A 2-ms TTI is used only for HSUPA users performing BE services in good uplink coverage after this
function is enabled. For HSUPA users performing BE services in weak uplink coverage, a 10-ms TTI is
used. This reduces the HSUPA PS connection failure rate and increases the RAB access success rate.
This function can be enabled by turning on the DRA_BASE_COVER_BE_TTI_RECFG_SWITCH and
DRA_BASE_COVER_BE_TTI_INIT_SEL_SWITCH switches under the RNC-level parameter
DraSwitch in the SET UCORRMALGOSWITCH command. This function is disabled by default.
3.49.19 RSCP-based Cell Reselection

RAN14.0 introduces RSCP-based cell reselection. This function also enables the UE to trigger a cell
reselection based on the received signal code power (RSCP) value when the SIB3 or SIB4 message
contains the IEs SsearchHCS and SHCSRat, instead of only based on the Ec/Io.
With this function, UEs are quickly reselected to GSM cells when UMTS signals are weak and GSM
signals are strong. This increases the probability of cell reselection for UEs in weak coverage areas and
increases the RRC connection setup success rate as a result.
This function can be enabled by running the command ADD UCELLHCS on the RNC with the
NonHCSCompatSwitch parameter set to ON. This function is disabled by default.
3.49.20 Dynamic BLER Adjustment for AMR Voice Services

To improve AMR voice service quality, this function adjusts the initially configured BLERtarget of AMR
voice services based on the uplink load during initial access:
If the uplink of the best cell is not congested, this function reduces the initially configured BLERtarget
to improve voice service quality and user experience. However, the UE transmit power and cell uplink
load will increase.
If the uplink of the best cell is congested (LDR or OLC is triggered), the initially configured
BLERtarget is used. This does not affect the uplink capacity.
This function is controlled by the switch PERFENH_OLPC_BLER_COEF_ADJUST in the
PerfEnhanceSwitch parameter and it is turned on by default. To change the setting for this switch, run
the RNC command SET UCORRMPARA.

RAN14.0
3.49.21 Maintenance Mode Alarms

The maintenance mode is an NE configuration mode. The method for configuring the maintenance
mode for an NE is the same as that for configuring cells to be blocked or unblocked.
Compared with RAN13.0, RAN14.0 incorporates the following changes in maintenance mode alarms:
In maintenance mode, only alarms that may cause severe damage to site equipment are displayed
on the alarm console and reported to the network management system (NMS) through the
northbound interface. These alarms include smoke alarms, over-temperature alarms, and water
damage alarms. In this manner, maintenance personnel can handle these alarms in a timely manner.
The maintenance mode can be configured in two ways: scheduled configuration and manual
configuration.
In
scheduled configuration, users can set the start time and end time of the maintenance mode. The
NE changes the maintenance mode as scheduled.
In other cases, users must manually change the maintenance mode.
The method for backing up and restoring maintenance mode data is the same as that for other
configuration data.
Users can modify NE configuration data by using:
M2000 GUI for configuring maintenance mode
CME
MML commands on the M2000 and LMT
The precautions for using maintenance mode alarms are as follows:
Set the maintenance mode to Testing mode during base station deployment or relocation.
When preparing data by using the CME or other tools, set the maintenance mode to Testing mode for
new base station to prevent a large number of unnecessary alarms.
Check the maintenance mode of NodeBs after replacing the main control board.
If the NodeB works as an independent NE, ensure that the maintenance mode is set as required after
the main control board is replaced. In the case of an independent NE, the M2000 sends configuration
and maintenance data directly to the NodeB, without going across the RNC.
Check that maintenance mode configurations are the same between the NodeB and the RNC.
If the NodeB and RNC operate as independent NEs to each other, ensure that the maintenance
mode configurations are the same between the NodeB and the RNC when using the CME or running
MML commands. If there are any discrepancies, some alarms may have incorrect maintenance mode
tags.
Perform manual operations to exit the maintenance mode.
Manual operations are required for exiting the maintenance mode. If the required manual operations
are not performed, alarms reported by NEs may not be reported to the NMS or be displayed on the
M2000.
3.49.22 Optimized Mechanism for Handling Major VSWR Alarms

This function has an impact on 3900 series base stations.
In RAN13.0, the base station shuts down the power amplifier on a radio frequency (RF) module when a
major ALM-26529 RF Unit VSWR Threshold Crossed is reported on the RF module. VSWR stands for
voltage standing wave ratio. This causes the cell served by the RF module to be out of service and
therefore network quality deteriorates and KPIs degrade. However, the base station can still function by
reducing the output power of the RF module in this case and enable the cell to provide basic services.

RAN14.0
In SRAN7.0, the mechanism for handling major VSWR alarms is optimized for single-mode and multi-
mode base stations. When a major VSWR alarm is reported on an RF module, the base station decides
whether to shut down the power amplifier based on user configurations.
If the user configurations specify that the power amplifier needs to be disabled upon the alarm
generation, the base station shuts down the power amplifier immediately and the cell is out of service.
If the user configurations specify that the power amplifier needs not to be disabled upon the alarm
generation, the base station reduces the transmit power of RF modules by half to prevent cell
services from being interrupted.
This function has no impact on inter-NE interfaces and system capacity. Enabling this function helps to
enhance network performance, improve KPIs, and reduce the probability of base stations being out of
service.
3.49.23 Standby/Active Switchover Time Configured Based on BFD

This function has been added to the NodeB.
When two static routes for a base station work in active/standby mode, the base station uses the active
route by default. If a fault occurs on the active route, an active/standby route switchover is performed.
After the active route is restored, the base station automatically switches back to the active route.
The switchover from the standby route to the active route (standby/active switchover for short) depends
on Bidirectional Forwarding Detection (BFD). The BFD checks whether the link status of the active
route is normal on a per second basis. If the link status is normal, the standby/active switchover is
performed. However, it may take 1 minute to 5 minutes to restore the active route, depending on the IP
network deployed by different operators. Therefore, services may be interrupted for several minutes
after the standby/active switchover.
New parameters have been added so that users can configure the switchover time. This ensures the
consistency between the switchover delay and the convergence time of the router. The switchover
delay must be greater than or equal to the convergence time of the router. Otherwise, services are
interrupted.
3.49.24 Optimized Uplink Enhanced CELL_FACH

Compared with the Uplink Enhanced CELL_FACH feature in RAN13.0, which enables UEs in the uplink
enhanced CELL_FACH state to share E-RGCH/E-HICH signature sequences with HSUPA users, the
optimized Uplink Enhanced CELL_FACH feature in RAN14.0 reserves some fixed E-RGCH/E-HICH
signature sequences for UEs in this state. The optimization to the Uplink Enhanced CELL_FACH
feature automatically takes effect after this feature is activated.
The optimized Uplink Enhanced CELL_FACH feature ensures that UEs in the uplink enhanced
CELL_FACH state can always obtain E-RGCH/E-HICH signature sequences. If the E-RGCH/E-HICH
signature sequences reserved for UEs in the uplink enhanced CELL_FACH state are occupied by
HSUPA users, the optimized Uplink Enhanced CELL_FACH feature forcibly releases HSUPA users.
Therefore, this feature may increase the call drop rate of HSUPA users. You are advised to use this
feature during off-peak hours, for example, in the early morning. In addition, the total number of E-
RGCH/E-HICH signature sequences is fixed on a cell. This feature reserves some E-RGCH/E-HICH
signature sequences for UEs in the uplink enhanced CELL_FACH state and consequently reduces the
number of HSUPA online users on the cell.

RAN14.0
NOTE
The sum of common E-DCH resources configured for the optimized Uplink Enhanced CELL_FACH feature (indicated by
the CommonEdchResourceNum parameter) and HSUPA online users (which can be estimated based on counters
VS.HSUPA.UE.Mean.Cell and VS.HSUPA.UE.Max.Cell must be less than or equal to 20 multiplying
ErgchEhichCodeNum. ErgchEhichCodeNum should be set based on the estimated HSUPA online user number and
the number of common E-DCH resources configured for the optimized Uplink Enhanced CELL_FACH feature.
3.49.25 Inactivity-based F2P

The RNC performs inactivity-related measurements. If a UE does not receive or transmit any data
during a period specified by the inactivity timer and the RLC buffer is blank, the RNC enables the UE to
transit from the CELL_FACH state to the CELL_PCH state (abbreviated as F2P).
Inactivity-based F2P increases the accuracy for triggering F2P transitions, and UEs receiving or
transmitting small packets will not experience F2P transitions. This function sets more strict conditions
for triggering F2P transitions and therefore reduces the reconfigurations for F2P2F transitions
(transitions from CELL_FACH to CELL_PCH and then to CELL_FACH again). Based on the same
traffic model, this function reduces signaling messages used for RB reconfigurations and cell updates
and does not significantly affect the distribution of the number of users in the CELL_FACH and
CELL_PCH states.
Inactivity-based F2P is disabled by default. To enable it, run the RNC MML command SET
UALGORSVPARA with RESERVED_SWITCH_1_BIT31 under RsvSwitch turned on.

RAN14.0
Network Impact Report 4 Glossary
4 Glossary
C
CELL_DCH An RRC connected mode in which the DCCH and DTCH are available.
The DCCH and DTCH are mapped to the DCH
CELL_PCH An RRC connected mode in which neither the DCCH nor the DTCH is
available
Control Channel A channel used to transmit digital control information between the
base station and a cell phone
H
Handover A transfer of a user's connection from one radio channel to
another(can be the same or different cells)
L
LMT The LMT is a logical concept. The LMT is connected to the external
network of the RNC and provides the user interface for RNC operation
and maintenance.
O
Outer loop power control A power control mode where the SRNC changes the target SIR for
(OLPC) inner loop power control based on the quality estimation of uplink
frames.
P
Push to Talk A service option for conversing in half-duplex mode. When a
subscriber presses the PPT button, a PTT connection is set up
instantly in the operator's network. A cell phone enabled with PTT
integrates the functions of a walkie-talkie.
U
Uplink A unidirectional radio link for the transmission of signals from the user
equipment to a base station, from a mobile station to another, or from
a mobile station to a base station
URA_PCH An RRC connected mode in which neither the DCCH nor the DTCH is
available

RAN14.0
Network Impact Report 5 Acronyms and Abbreviations
5 Acronyms and Abbreviations

3
3GPP Third Generation Partnership Project
A
AMR adaptive multi-rate
ARP Address Resolution Protocol
B
BBU BaseBand Unit
BFD Bidirectional Forwarding Detection
BLER Block Error Rate
BSC Base Station Controller
C
CFN Connection Frame Number
CHR Call History Record
CME Configuration Management Express
CN Core Network
CPU Central Processing Unit
CQI Channel Quality Indicator
CS Circuit Switched
D
DCH Dedicated Channel
DL Downlink
DPCCH Dedicated Physical Control Channel
DPCH Dedicated Physical Channel
DSS Dynamic Spectrum Sharing
E
ETSI European Telecommunications Standards Institute
F
FACH Forward Access Channel
F-DPCH Fractional DPCH
FE Fast Ethernet
G

RAN14.0
GE Gigabit Ethernet
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
GTP-U GPRS Tunneling Protocol-User plane
H
HFN Hyper Frame Number
HSDPA High Speed Downlink Packet Access
HSUPA High Speed Uplink Packet Access
I
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IPSec IP Security
L
LDR Load Reshuffling
LMT Local Maintenance Terminal
LTE Long Term Evolution
M
MA Mobile Allocation
MML Man-Machine Language
MR Measurement Report
MO Managed Object
N
NAS Non-access Stratum
NBAP NodeB Application Part
O
OLC Overload Control
P
PCH Paging Channel
P-CPICH Primary Common Pilot Channel
PKI Public Key Infrastructure
PS Packet Switched
PTT Push to Talk

RAN14.0
Q
QoS Quality of Service
R
RAB Radio Access Bearer
RAN Radio Access Network
RAT Radio Access Technology
RB Radio Bearer
RLC Radio Link Control
RNC Radio Network Controller
RRC Radio Resource Control
RRU Remote Radio Unit
RTWP Received Total Wideband Power
S
SGSN Serving GPRS Support Node
S-GW Serving Gateway
SMS Short Message Service
SMSC Short Message Service Center
SPU Signaling Processing Unit
SRB Signaling Radio Bearer
T
TPC Transmission Power Control
TTI Transmission Time Interval
U
UE User Equipment
UL Uplink
UMTS Universal Mobile Telecommunication System
URA UTRAN Registration Area
W
WCDMA Wideband Code Division Multiple Access

RAN14.0
Network Impact Report 6 References
6 References
[1] RAN14.0 Feature List
[2] RAN14.0 Feature Description
[3] SRAN7.0&GBSS14.0&RAN14.0&eRAN3.0 DBS3900 Configuration Principle
[4] RAN14.0 BTS3900C WCDMA Product Description
[5] RAN13.0 BSC6900 Product Description
[6] BSC6900 V9R014 UMTS Release Notes (for a specific patch)
[7] 3900 Series WCDMA NodeB V200R014 Release Notes (for a specific patch)
[8] BSC6900 UMTS Product Documentation
[9] 3900 Series WCDMA NodeB Product Documentation
[10] RAN14.0 Feature Documentation
[11] M2000 V200R012 Network Impact Report
[12] M2000 Product Documentation


Load Control (RAN14.0 05)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Load Control (RAN14.0 05)

Transféré par

Droits d'auteur :

Formats disponibles

RAN14.

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

2 Summary of Feature Impacts.................................................................................................2-1

Issue 05 (2013-06-20) Huawei Proprietary and Confidential i

3.3.1 Description ............................................................................................................................ 3-4

Issue 05 (2013-06-20) Huawei Proprietary and Confidential ii

3.8.3 Impact on NEs .................................................................................................................... 3-14

Issue 05 (2013-06-20) Huawei Proprietary and Confidential iii

3.13.3 Impact on NEs .................................................................................................................. 3-28

Issue 05 (2013-06-20) Huawei Proprietary and Confidential iv

3.18.5 Inter-NE Interface ............................................................................................................. 3-42

Issue 05 (2013-06-20) Huawei Proprietary and Confidential v

3.23.7 Impact on Other Features................................................................................................. 3-62

Issue 05 (2013-06-20) Huawei Proprietary and Confidential vi

3.29.1 Description ........................................................................................................................ 3-76

Issue 05 (2013-06-20) Huawei Proprietary and Confidential vii

3.34.2 Capacity and Performance ............................................................................................... 3-93

Issue 05 (2013-06-20) Huawei Proprietary and Confidential viii

3.39.5 Inter-NE Interface ........................................................................................................... 3-107

Issue 05 (2013-06-20) Huawei Proprietary and Confidential ix

3.44.6 Operation and Maintenance ........................................................................................... 3-127

Issue 05 (2013-06-20) Huawei Proprietary and Confidential x

3.49.8 Optimized Control Mechanism for Inter-Frequency Handovers ..................................... 3-143

Issue 05 (2013-06-20) Huawei Proprietary and Confidential xi

About This Document

Issue 05 (2013-06-20) Huawei Proprietary and Confidential i

Contains the following new information:

Issue 05 (2013-06-20) Huawei Proprietary and Confidential ii

Issue 05 (2013-06-20) Huawei Proprietary and Confidential iii

1.2 Capacity and Performance

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-1

Increased System Capacity

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-2

Item Specifications Description

High-PS traffic model

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-3

Item Specificati Description

Traffic model for smartphones

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-4

Item Specifications Description

Improved Processing for NBAP Signaling

Increased CPU Usage Due to an Increased Number of Control-Plane Boards

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-5

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-6

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-7

Table 1-12 New BBU3900 boards

1.4.2 Upgrade from RAN13.0 to RAN14.0

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-8

1.5.1 Permanent and Temporary License Authorization Mechanism

1.5.2 Changes in the License

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-9

Feature ID Feature Name License Change

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-10

Feature ID Feature Name License Configured

WRFD-150237 Horizon Beam-Width Adjustment NodeB

WRFD-150238 Azimuth Adjustment NodeB

1.6 Inter-NE Interface

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-11

1.7 Operation and Maintenance

1.8 Impact on Other NEs

Issue 05 (2013-06-20) Huawei Proprietary and Confidential 2-12