c03 - bsc6900 Umts v900r016c00spc650 Release Notes

BSC6900 UMTS
V900R016C00SPC650
Release Notes
Issue
01
Date
2014-12-31
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2014. 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 a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 01 (2014-12-31)
Huawei Proprietary and Confidential

Copyright Huawei
Technologies Co., Ltd.
BSC6900 UMTS
Release Notes
About This Document
About This Document

Author
Prepared by
Wang Erli, Xu
Qigang, Hou Wei, Li
Jian, Zhu Jiangbo
Date
2014-12-01
Reviewed by
Liu Yong, Liu Qi, Xu

Yousong, Wang Jun,
Wang Qingyan, Chen
Yiwen, Zhang Peng,
Wu Xiuliang
Date
2014-12-10
Tested by
Zheng Hang
Date
2014-12-17
Approved by
Wang Dong
Date
2014-12-31
Overview
This document provides only the changes between adjacent patch versions for
BSC6900V900R016C00SPC600.
If a BSC earlier than BSC6900V900R016C00SPC600 on the live network is upgraded to the
current patch version, obtain the release documentation matching
BSC6900V900R016C00SPC600 and use the obtained release documentation together with
this document.
If an intermediate version is required for the upgrade on the live network (for details, see
section 1.2 "Version Requirements" in the upgrade guide), obtain the release documentation
matching BSC6900V900R014C00SPC500 of the intermediate version and its patch
BSC6900V900R014C00SPH552.
The "Known Issues" chapter in each version describes the status of all known issues. If a
known issue has been resolved, the progress of this known issue will be displayed in the
"Resolved Issues" chapter in a later version.Users can check the progress of a known issue
according to its trouble ticket number.
Issue 01 (2014-12-31)

Copyright Huawei
ii
BSC6900 UMTS
Release Notes
About This Document
Change History
Issu
e
Date
Author
Description
01
2014-12-31
Wang Erli, Xu
Qigang, Hou Wei,
Li Jian, Zhu
Jiangbo
This is the first commercial release.
Introduction
This document is intended for system engineers. It provides the following information:
Version Requirements
This chapter lists all information about this product version, for example, software,
hardware, operating system (OS), database, documentation, and any other required
products. This chapter also provides important notes and virus scan results for this
product version.
Version Compatibility
This chapter describes the compatibility between this product version and earlier
versions, including their software and hardware versions.
Change Description
This chapter describes the changes in the current version compared with the previous
version, including the change summary, feature changes, resolved issues, and known
issues. Where,
The feature summary includes information about capacity and performance,

hardware, features, resolved issues, operation and maintenance, and related
documentation, as described in Table 1 Section description.
Table 1 Section description

Section
Description
Capacity and
performance
Describes the possible impact of a specific product version on system

capacity and network performance.
Hardware
Describes any hardware addition and modification in a specific product

version. The hardware end of marketing (EOM) and end of service
(EOS) information does not map onto the software version. For details,
see the corresponding PCN.
Features
Provides a summary of all feature changes in a specific product

version. Users can select desired features by "Impact on Capacity and
Performance", "Hardware Dependency", "Parameter Control?", or
"Parameter Control?".
Resolved issues
Provides a summary of all resolved issues in a specific product version.

Users can select desired resolved issues by "Solution Impact",
"Parameter Control?", or "Post-Upgrade Value".
Operation and
Describes the changes to configuration management, performance
Issue 01 (2014-12-31)

Copyright Huawei
iii
BSC6900 UMTS
Release Notes
About This Document
Section
Description
maintenance
management, fault management, license management, and their

management mechanisms and rules in a specific product version.
Related
documentation
Describes the changes to related documentation of a specific product

version.
Figure 1 Relationships among sections in Change Summary shows the relationships

among the preceding sections.
Figure 1 Relationships among sections in Change Summary
Feature Changes: details feature changes.
Resolved Issues: details resolved issues by severity.
Known Issues: details known issues in this product version by severity.
Operation and Maintenance Changes

This chapter describes changes to MML commands, parameters, alarms, events,
counters, and licenses.
Appendix
The appendixes describe how to obtain related documentation and provide acronyms and
abbreviations involved.
Issue 01 (2014-12-31)

Copyright Huawei
iv
BSC6900 UMTS
Release Notes
Contents
Contents
About This Document.......................................................................ii
1 Version Requirements...................................................................1
1.1 Product Version..............................................................................................................................................................1
1.2 Software Versions...........................................................................................................................................................1
1.3 Hardware Versions..........................................................................................................................................................1
1.4 Related Product Versions................................................................................................................................................3
1.5 OS and Database Versions..............................................................................................................................................4
1.6 Related Documentation..................................................................................................................................................5
1.7 Virus Scan Result............................................................................................................................................................7
1.8 Important Notes..............................................................................................................................................................7
2 Version Compatibility....................................................................8
2.1 Software Version Compatibility.....................................................................................................................................8
2.2 Hardware Version Compatibility....................................................................................................................................8
3 Changes from V900R016C00SPC630 to V900R016C00SPC650........10

3.1 Change Summary.........................................................................................................................................................10
3.1.1 Capacity and Performance.........................................................................................................................................11
3.1.2 Hardware...................................................................................................................................................................11
3.1.3 Features......................................................................................................................................................................11
3.1.4 Resolved Issues.........................................................................................................................................................12
3.1.5 Operation and Maintenance.......................................................................................................................................12
3.1.5.1 Configuration Management....................................................................................................................................12
3.1.5.2 Performance Management......................................................................................................................................12
3.1.5.3 Fault Management..................................................................................................................................................12
3.1.5.4 License Management..............................................................................................................................................13
3.1.6 Related Documentation.............................................................................................................................................13
3.2 Feature Changes...........................................................................................................................................................13
3.2.1 New Features.............................................................................................................................................................13
3.2.2 Modified Features......................................................................................................................................................13
3.2.2.1 Considering the Power Load of Multi-carrier HSDPA UEs in the CLB Algorithm...............................................13
3.2.2.2 Iur-p Link Loopback Detection Self-Healing.........................................................................................................15
3.2.2.3 Enhanced UMTS-to-LTE Fast Return Based on Combined Services....................................................................16
Issue 01 (2014-12-31)

Copyright Huawei
BSC6900 UMTS
Release Notes
Contents
3.2.2.4 Exporting Configuration Information in the SET LICENSE Command...............................................................18

3.2.2.5 Global Tracing of IMSI Messages in the CS Domain............................................................................................19
3.2.2.6 Optimization of NIC Information Collection Based on SOP.................................................................................22
3.2.2.7 LAI and SAI IEs Supported in the DIRECT TRANSFER Message in the CS Domain........................................23
3.2.2.8 Support notifying the information of UEs capable of downlink DC-HSDPA throughput optimization to the
NodeB.................................................................................................................................................................................25
3.2.2.9 Support for Checking Resources of License Resource Items During a Pre-upgrade.............................................26
3.2.2.10 Optimized Features for RACH Keepalive Function............................................................................................28
3.2.2.11 Optimizing Reporting of EVT-22915 SCTP Link Destination IP Changeover....................................................29
3.2.2.12 Enhancement of Active/Standby Status Consistency of Interface Boards and Ports Before and After an Upgrade
............................................................................................................................................................................................31
3.2.2.13 Optimizing Information Displayed at the Start of an Upgrade Phase on the Upgrade Tool................................32
3.2.2.14 Adding the Prompt Message for Configuration Data Change During a Rollback on the Upgrade Tool.............34
3.2.2.15 Changing Backup IP Address on the U_creator Tool...........................................................................................35
3.2.2.16 OMU Capacity Evaluation...................................................................................................................................37
3.2.2.17 Support for Querying Manually Cleared Alarms.................................................................................................39
3.2.2.18 Changing the Default Value of Automatic Synchronization Switch....................................................................40
3.2.2.19 Enhanced Support for Editing of Batch Configuration Parameters on the Web LMT.........................................42
3.2.2.20 Fan Box Noise Rectification at a High Fan Speed...............................................................................................43
3.2.3 Deleted Features........................................................................................................................................................44
3.3 Resolved Issues............................................................................................................................................................44
3.3.1 Critical.......................................................................................................................................................................44
3.3.1.1 The call drop rate increases when the satellite card cannot properly trace GPS satellite signals..........................44
3.3.2 Major.........................................................................................................................................................................45
3.3.2.1 The value of Number of Received CREF in ALM-21522 Low SCCP Setup Success Rate is incorrect................45
3.3.2.2 Configuration data on the OMU is different from that on the SPU after the command RMV UEXT3GCELL,
MOD UCELLFREQUENCY, or RMV UNRELATION is consecutively executed..........................................................45
3.3.2.3 When an RNC sends inter-frequency measurement control messages to UEs, some UEs experience call drops. 46
3.3.2.4 The number of transmitted HS-DSCH Capacity Request messages is not controlled when UEs in the
CELL_DCH state have no HSDPA service data to transmit within a certain period of time............................................47
3.3.2.5 Logs are not recorded if the RNC receives a SECURITY MODE COMMAND message during other procedures.
............................................................................................................................................................................................48
3.3.2.6 Downlink data transmission for PS services is interrupted....................................................................................49
3.3.2.7 Services fail to be set up if an RB setup procedure during an F2D state transition overlaps with a cell update
procedure............................................................................................................................................................................50
3.3.2.8 ALM-22501 DSP CPU Overload is suppressed.....................................................................................................51
3.3.2.9 A large number of UEs unexpectedly initiate registration requests and the RNC control-plane CPU usage
suddenly reaches an high value..........................................................................................................................................52
3.3.2.10 After the MOD UCELLID command is executed, performance objects are repeated.........................................53
3.3.2.11 UEs in a LAC area cannot be paged after the cell LAC information has been modified using the CME...........54
3.3.2.12 Changing the GTP-U local IP address at the transport layer causes service releases after the PS core network
modifies the service type....................................................................................................................................................54
3.3.2.13 The RNC fails to initiate a channel fallback in the event of service setup or reconfiguration failures in some
scenarios.............................................................................................................................................................................57
Issue 01 (2014-12-31)

Copyright Huawei
vi
BSC6900 UMTS
Release Notes
Contents
3.3.2.14 The SPU on a Huawei DRNC restarts if messages received from a non-Huawei SRNC over the Iur interface
carry protocol-incompliant IEs...........................................................................................................................................58
3.3.2.15 The RL reconfiguration fails when an ATM/IP dual stack is applied over the Iub interface...............................59
3.3.2.16 N7DPC specified by DPX is inconsistent with that specified by NI, SPC/SPCDNF, and DPC/DPCDNF in the
configuration of the UCNNODE or UNRNC MO.............................................................................................................60
3.3.2.17 Configuration commands cannot be delivered to a board because the board is mistakenly inhibited.................61
3.3.2.18 Vulnerability CVE-2014-3511 exists...................................................................................................................61
3.3.2.20 The XPU board may abnormally report counters in GU mode............................................................................63
3.3.2.21 Service setup fails after a BSC6900 is upgraded from V900R013C00SPC586 to V900R015C00SPH565........63
3.3.2.22 An interface board unexpectedly resets because of logical remote loopback detection failures..........................64
3.3.2.23 Logical remote loopback detection on an interface board becomes unavailable.................................................65
3.3.2.24 The level-1 clock source becomes unavailable after the clock cable to the GCGa/GCUa board panel is removed
and installed........................................................................................................................................................................65
3.3.3 Minor.........................................................................................................................................................................66
3.3.3.1 WPS UEs initiate preemption during soft handovers, increasing the call drop rate..............................................66
3.3.3.2 The information element "Support for UE assisted GPS measurement validity in CELL_PCH and URA_PCH
states" contained in the POSITION INITIATION REQUEST message is assigned an incorrect value............................67
3.3.3.3 Some alarms are incorrectly reported after the master and backup RNCs of a logical RNC are switched over
when RNC in Pool Node Redundancy is enabled..............................................................................................................67
3.3.3.4 The relocation process fails when the Iur interface-based common channel function is enabled..........................69
3.3.3.5 The CPU usage instantaneously increases when message tracing over the Iur-p interface is enabled..................71
3.3.3.6 Uplink BLER-related counters return inaccurate values when the AMRC feature is activated............................72
3.3.3.7 The RNC improperly processes security mode in incoming inter-RAT relocations for combined services or PS
services...............................................................................................................................................................................72
3.3.3.8 Counters related to Multiband Direct Retry Based on UE Location return inaccurate values if measurementbased periodic DRD is triggered........................................................................................................................................74
3.3.3.9 Parameter configuration for power control is inappropriate if PS services are set up following an AMR service
reconfiguration...................................................................................................................................................................75
3.3.3.10 The RNC fails to add secondary carrier links for the DC-HSUPA UE after a serving cell change failure..........76
3.3.3.11 Some UEs fail to run CS services when CS fallback is triggered........................................................................77
3.3.3.12 The RNC incorrectly measures certain performance counters for the MBDR-based inter-RAT handovers........78
3.3.3.13 Some IEs in the INITIAL UE MESSAGE message are not parsed during signaling tracing..............................79
3.3.3.14 In a PDP deactivation procedure, the RNC sends the core network a RAB RELEASE REQUEST message... .79
3.3.3.15 The IE "TargetCellId" contained in a DIRECT INFORMATION TRANSFER message is incorrectly examined
in a RIM procedure.............................................................................................................................................................80
3.3.3.16 Incorrect license control item usage and false alarms are reported for some features.........................................81
3.3.3.17 The SRNC does not send the DRNC a RESET REQUEST message after the SRNC is restarted on RNC in Pool
networking..........................................................................................................................................................................84
3.3.3.18 CS service setup fails when the coverage is strong and the delay over the Iub interface is large........................85
3.3.3.19 UEs experience PS service drops when the RNC initiates a PS RAB modification............................................85
3.3.3.21 The automatic switchover of the active and standby OMUs cannot be performed when the hard disk of the
active OMU is abnormal and that of the standby OMU is normal.....................................................................................87
Issue 01 (2014-12-31)

Copyright Huawei
vii
BSC6900 UMTS
Release Notes
Contents
3.3.3.22 TCP ISN security risks are found during CSEC scan...........................................................................................87
3.3.3.23 The base station controller does not report ALM-21541 SCTP Link Fault when an SCTP link whose
Application type is BBAP(BBAP) and Signalling link mode is SERVER(SERVER MOD) becomes faulty...................88
3.3.3.24 The GPS satellite health check function is not controlled by commands............................................................89
3.3.4 Suggestion.................................................................................................................................................................89
3.3.4.1 When the SRB over HSDPA feature takes effect, single HSUPA BE services are dropped..................................89
3.3.4.2 CS and PS combined services do not allow service-based inter-RAT handovers..................................................90
3.3.4.3 Some UEs report false measurement results or experience call drops after they start neighboring LTE cell
measurement.......................................................................................................................................................................91
3.3.4.4 User access delay is greater than expected because of redundant IEs in the RADIO BEARER SETUP message.
............................................................................................................................................................................................93
3.3.4.5 The MC-HSDPA UE can still use the DTX/DRX feature even when the MC-HSDPA secondary carrier does not
support this feature.............................................................................................................................................................94
3.3.4.6 The RNC cannot accurately control the percentage of UEs during outgoing inter-RAT handovers in the MBDR
algorithm.............................................................................................................................................................................94
3.3.4.7 The RNC cannot recognize the UE-sent packets with IE "Header Extension Type" of 2......................................95
3.3.4.8 UEs are handed over or redirected from a UMTS network to an LTE network before the penalty duration ends 96
3.3.4.9 The RNC does not penalize service-based UMTS-to-LTE redirections or handovers on UEs redirected from the
LTE network to the UMTS network...................................................................................................................................97
3.3.4.10 In some scenarios, the RNC does not perform a penalty of service-based UMTS-to-LTE blind redirections.. . .98
3.3.4.11 UEs redirected from an LTE network to a UMTS network cannot be handed over or redirected back to an LTE
network...............................................................................................................................................................................99
3.3.4.12 The LST ULTENCELL or LST U2GNCELL command output displays undesired neighbor relationship
information.......................................................................................................................................................................100
3.3.4.13 CPC reconfiguration messages transmitted over the Uu interface are added two more bytes...........................101
3.3.4.14 The Differentiated Service Based on SPI Weight feature is not provided with a control switch.......................102
3.4 Known Issues..............................................................................................................................................................102
3.4.1 Critical.....................................................................................................................................................................102
3.4.2 Major.......................................................................................................................................................................103
3.4.3 Minor.......................................................................................................................................................................103
3.4.4 Suggestion...............................................................................................................................................................103
4 Changes from V900R016C00SPH621 to V900R016C00SPC630......104

4.1 Change Summary.......................................................................................................................................................104
4.1.1 Capacity and Performance.......................................................................................................................................105
4.1.2 Hardware.................................................................................................................................................................105
4.1.3 Features....................................................................................................................................................................105
4.1.4 Resolved Issues.......................................................................................................................................................106
4.1.5 Operation and Maintenance.....................................................................................................................................106
4.1.5.1 Configuration Management..................................................................................................................................106
4.1.5.2 Performance Management....................................................................................................................................106
4.1.5.3 Fault Management................................................................................................................................................106
4.1.5.4 License Management............................................................................................................................................107
4.1.6 Related Documentation...........................................................................................................................................107
Issue 01 (2014-12-31)

Copyright Huawei
viii
BSC6900 UMTS
Release Notes
Contents
4.2 Feature Changes.........................................................................................................................................................107

4.2.1 New Features...........................................................................................................................................................107
4.2.2 Modified Features....................................................................................................................................................107
4.2.2.1 Coexistence Between the Single HARQ Process Scheduling and CPC Features................................................107
4.2.2.2 Optimized PS BE Service Setup Process.............................................................................................................108
4.2.2.3 Optimized Distance-based Access Control...........................................................................................................112
4.2.2.4 Optimization Against State Inconsistency for UEs in the CELL_FACH State....................................................114
4.2.2.5 Support for RRC Reestablishment Through a D2P Procedure.............................................................................117
4.2.2.6 Optimization of OMU Disk IO Flow Control......................................................................................................120
4.2.3 Deleted Features......................................................................................................................................................121
4.3 Resolved Issues..........................................................................................................................................................121
4.3.1 Critical.....................................................................................................................................................................121
4.3.2 Major.......................................................................................................................................................................121
4.3.2.1 PS BE Service Rate of Incoming Inter-RAT Handover UEs Are Limited...........................................................122
4.3.2.2 Peer AMR UEs are muted after the call reestablishment when the AMRC feature is activated..........................123
4.3.2.3 Peer UEs are muted because local UEs have not received the TFC CTRL message...........................................124
4.3.2.4 AMR voice quality deteriorates when the protocol CR0125 takes effect............................................................125
4.3.2.5 The value of VS.IRATHO.FailOutPS.UEGen is incorrect...................................................................................127
4.3.2.6 Values returned by counters related to the uplink BLER of PS R99 services are greater than expected.............127
4.3.2.7 Call drops occur if SRB over HSDPA or SRB over HSPA is enabled.................................................................129
4.3.2.8 The number of RAB setup attempts for HSPA services are incorrectly counted as that for R99 services...........130
4.3.2.9 An SAAL link cannot be established after it is removed and then added again...................................................131
4.3.2.10 An AOUa board may reset in some scenarios....................................................................................................132
4.3.3 Minor.......................................................................................................................................................................132
4.3.3.1 The HSUPA throughput rises slowly if a DRD procedure is triggered during service reconfiguration...............132
4.3.3.2 The SAI-based location fails because the RNC sends an SAI-based location report to the CN during the UE
relocation process.............................................................................................................................................................133
4.3.3.3 The CS service is abnormally released in the case of CS+PS combined services...............................................134
4.3.3.4 ALM-22206 UMTS Cell Setup Failed is reported again at 03:00 a.m.................................................................135
4.3.3.5 The UE transmit power increases due to AMR service reconfiguration in AMR+PS combined service scenarios.
..........................................................................................................................................................................................136
4.3.3.6 The PS service setup success rate is low..............................................................................................................137
4.3.4 Suggestion...............................................................................................................................................................138
4.3.4.1 In the case of insufficient HSPA users, CS services are released when UEs performing CS+PS combined
services experience a combined incoming hard handover and SRNS relocation............................................................138
4.3.4.2 UEs experience call drops if the RNC does not receive an IU RELEASE COMMAND message within a
specified time in specific scenarios..................................................................................................................................139
4.3.4.3 PS service drops occur after a cell update with SRNS relocation is complete.....................................................140
4.3.4.4 UEs experience call drops when an automatic link reestablishment procedure and an inter-RAT cell reselection
procedure are triggered concurrently................................................................................................................................141
4.3.4.5 No performance counter provides data rate increase for 0 kbit/s PS services......................................................142
4.3.4.6 In the single-signaling scenario where DRNC links exist, new PS services fail to be established in an E-DCH-toDCH SRB fallback procedure..........................................................................................................................................144
Issue 01 (2014-12-31)

Copyright Huawei
ix
BSC6900 UMTS
Release Notes
Contents
4.3.4.7 A moving UE in the connected state cannot update the RA or LA......................................................................145

4.3.4.8 No counter is provided to measure the number of times a UE in the CELL_PCH or URA_PCH state re-initiates
an RRC connection setup request.....................................................................................................................................147
4.3.4.9 Downlink code resources of the AMR+PS combined service cannot be saved...................................................148
4.3.4.10 A UE abnormally exits from the large retransmission state at an extremely low rate during the RB
reconfiguration for CS services........................................................................................................................................149
4.3.4.11 Data is inconsistent between the active OMU and the standby OMU after an upgrade....................................150
4.4 Known Issues..............................................................................................................................................................150
4.4.1 Critical.....................................................................................................................................................................150
4.4.2 Major.......................................................................................................................................................................150
4.4.3 Minor.......................................................................................................................................................................150
4.4.4 Suggestion...............................................................................................................................................................151
5 Changes from V900R016C00SPC620 to V900R016C00SPH621......152

5.1 Change Summary.......................................................................................................................................................152
5.1.2 Hardware.................................................................................................................................................................153
5.1.3 Features....................................................................................................................................................................153
5.1.4 Resolved Issues.......................................................................................................................................................154
5.2 Feature Changes.........................................................................................................................................................155
5.2.1 New Features...........................................................................................................................................................155
5.2.2.1 Configuration Script Browsing and Editing by using the Batch Configuration function of the WebLMT..........155
5.3 Resolved Issues..........................................................................................................................................................156
5.3.1 Critical.....................................................................................................................................................................156
5.3.2 Major.......................................................................................................................................................................156
5.3.3 Minor.......................................................................................................................................................................156
5.3.4 Suggestion...............................................................................................................................................................157
5.4 Known Issues..............................................................................................................................................................157
5.4.1 Critical.....................................................................................................................................................................157
5.4.2 Major.......................................................................................................................................................................157
5.4.3 Minor.......................................................................................................................................................................157
5.4.4 Suggestion...............................................................................................................................................................157
6 Changes from V900R016C00SPH609 to V900R016C00SPC620......158

6.1 Change Summary.......................................................................................................................................................158
Issue 01 (2014-12-31)

Copyright Huawei
BSC6900 UMTS
Release Notes
Contents

6.1.2 Hardware.................................................................................................................................................................159
6.1.3 Features....................................................................................................................................................................159
6.1.4 Resolved Issues.......................................................................................................................................................160
6.2 Feature Changes.........................................................................................................................................................161
6.2.1 New Features...........................................................................................................................................................161
6.2.2.1 IP Transmission Path Status Detection over the Iu and Iur Interfaces on the Backup RNC in RNC in Pool
Scenarios...........................................................................................................................................................................161
6.2.2.2 The POSITION ACTIVATION RESPONSE Message over the Iu-PC Interface Containing the Value of the Path
Loss...................................................................................................................................................................................163
6.2.2.3 Calibration of the Maximum Downlink Transmit Power for Special UEs..........................................................164
6.2.2.4 UOIP Loopback Detection Function Supported by DPUe Boards.......................................................................167
6.2.2.5 RRC Connections Established on FACHs When NodeB Resources Become Unavailable.................................168
6.2.2.6 Anti-Ping-Pong Mechanism for RRC Redirections Caused by Admission Failures............................................170
6.2.2.7 Optimized Features for AMR Services.................................................................................................................171
6.2.2.8 Optimization of How an RNC Handles the SIGNALLING CONNECTION RELEASE INDICATION Message
in the PS Domain for UEs Enabled with the Enhanced Fast Dormancy Feature.............................................................176
6.2.2.9 RL Reestablishment Event Blocks Now Added to RNC PCHR Logs.................................................................178
6.2.2.10 CN-Initiated Service Awareness Specific for Non-Roaming Users of the Primary Operator............................179
6.2.2.11 CS and PS Non-Service Direct Transfer Message Blocks Now Added to RNC PCHR Logs...........................181
6.2.2.12 Layer 2 Release Blocks Now Added to RNC PCHR Logs................................................................................184
6.2.2.13 Support for Subrack DIP Switch Status Check..................................................................................................185
6.2.2.14 Upgrade Tool Reliability Optimization..............................................................................................................187
6.2.2.15 Replacing SCUa with SCUb Online...................................................................................................................189
6.3 Resolved Issues..........................................................................................................................................................191
6.3.1 Critical.....................................................................................................................................................................191
6.3.2 Major.......................................................................................................................................................................191
6.3.2.1 PS services fail to be set up due to insufficient memory for the IP address pair table on the Iu-PS interface board.
..........................................................................................................................................................................................191
6.3.2.2 Services fail to be set up after a cell update with SRNS relocation is complete..................................................192
6.3.2.3 The RNC does not process INITIAL DIRECT TRANSFER messages in an RRC connection release procedure.
..........................................................................................................................................................................................192
6.3.2.4 The uplink SRB fails to be reconfigured again after it is reconfigured from the DCH to the E-DCH................193
6.3.2.5 The relocation preparation procedure fails when the target cell is not configured as an external neighboring
UMTS cell of the source cell............................................................................................................................................194
Issue 01 (2014-12-31)

Copyright Huawei
xi
BSC6900 UMTS
Release Notes
Contents
6.3.2.6 A cell cannot be selected as the target cell for CLB-triggered inter-frequency handover because this cell is not
configured with the CLB algorithm.................................................................................................................................195
6.3.2.7 Configuration information about intelligent optimization-related features is not displayed in the MML
configuration script...........................................................................................................................................................196
6.3.2.8 The RNC fails to deactivate the CPC-DTX/DRX function for non-serving radio links in soft handover scenarios.
..........................................................................................................................................................................................197
6.3.2.9 A UE cannot trigger the RB Parking function after a queuing failure..................................................................198
6.3.2.10 The DSP experiences a reset for self-healing due to a communication failure between the SPU subsystem and
the DSP.............................................................................................................................................................................198
6.3.2.11 Link configuration fails due to high maximum downlink transmit power of a UE...........................................199
6.3.2.12 PS streaming services cannot be established if the RAN does not support the MBR assigned by the CN........199
6.3.2.13 The RMV UEXT3GCELL, MOD UCELLFREQUENCY, or RMV UNRELATION command fails to be
executed............................................................................................................................................................................200
6.3.2.14 SRBs fail be carried on the HSDPA channel if UEs in the CELL_PCH or URA_PCH state switch to the
CELL_DCH state.............................................................................................................................................................201
6.3.2.15 PS services experience call drops during the CS service release after a CS service reconfiguration................202
6.3.2.16 UEs experience mute voices after the AMR-WB code reconfiguration function takes effect...........................203
6.3.2.17 Operator indexes of GSM cells served by all logical RNCs belonging to a physical RNC are modified after the
ADD UCNOPERATOR, RMV UCNOPERATOR, ADD UCNOPEREXTPLMN, or RMV UCNOPEREXTPLMN
command is executed.......................................................................................................................................................204
6.3.2.18 PTT service setup fails when Downlink Enhanced L2 is enabled.....................................................................205
6.3.2.19 The overflow RNC becomes faulty in RNC in Pool load sharing networking, and KPIs deteriorate significantly.
..........................................................................................................................................................................................206
6.3.2.20 The DRNC fails to identify platinum users........................................................................................................209
6.3.2.21 The RL reconfiguration over the Iur interface fails due to compatibility issues................................................209
6.3.2.22 The RNC sends SPID-specific dedicated priority to UEs that does not support LTE........................................211
6.3.2.23 The UE experiences a call drop during a UE-not-involved relocation...............................................................211
6.3.2.24 Services are interrupted after RL reestablishment..............................................................................................212
6.3.2.25 RL reconfiguration fails when a service is reconfigured from an HSUPA+ channel to an HSUPA channel.....213
6.3.2.26 The point-to-point short message service cannot be disabled on a per cell basis..............................................214
6.3.2.27 The number of hash indexes used on an interface board exceeds the maximum value during the ADD IPPATH
or ADD SCTPLNK command execution.........................................................................................................................215
6.3.3 Minor.......................................................................................................................................................................215
6.3.3.1 The RNC fails to encode RRC-related messages during a combined cell update and SRNS relocation.............215
6.3.3.2 The CELL ID+RTT positioning calculation fails.................................................................................................216
6.3.3.3 There is a possibility that the interval between two paging messages for a PTT service is 640 ms....................217
6.3.3.4 The UE occasionally experiences a CS service setup failure after it initiates a cell update procedure during the
security mode command procedure..................................................................................................................................218
6.3.3.5 The values of the VS.GTPU.Pkt.Tx and VS.GTPU.BytesPkt.Tx counters are incorrect....................................219
6.3.3.6 Links become out of synchronization due to the large transmission delay difference between cells in the active
set......................................................................................................................................................................................219
6.3.3.7 SAAL link-related counter is abnormal for AOUa, AEUa, and ATM-based UOIa boards..................................220
6.3.3.8 The CBSADDR and RNCCBCPUID objects cannot be synchronized from the backup RNC to the master RNC.
..........................................................................................................................................................................................221
Issue 01 (2014-12-31)

Copyright Huawei
xii
BSC6900 UMTS
Release Notes
Contents
6.3.3.9 The SPU CPU usage rises instantaneously due to the execution of the SET UCHRSCOPE or SET UMRSCOPE
command..........................................................................................................................................................................222
6.3.3.10 No statistics are available for UE transitions from common channels to dedicated channels that are triggered by
data transmission requirements........................................................................................................................................223
6.3.3.11 The RNC delivers MR A-GPS measurement control messages to UEs in the MR A-GPS blacklist immediately
after an incoming relocation.............................................................................................................................................225
6.3.3.12 Some SAAL links to an AOUa board become faulty after ATM overbooking is enabled or disabled..............226
6.3.3.13 The causes for signaling link interruption or transmission faults cannot be quickly identified.........................227
6.3.3.14 The value of the Hosted domain queried in the DSP OPC command output is incorrect..................................227
6.3.3.15 Optical port numbers are incorrect in ALM-21398 Optic Power Abnormal reported by a GOUa board..........228
6.3.4 Suggestion...............................................................................................................................................................229
6.3.4.1 The RNC fails to reset the Iu interface in Iu-Flex scenarios................................................................................229
6.3.4.2 An inappropriate message is displayed when the pre-upgrade check item "Operating system version" fails.....231
6.3.4.3 ALM-22302 KPI Exceed Threshold is not reported for KPI deterioration caused by DPUe hardware faults.....231
6.3.4.4 The RNC fails to respond to the CN with the RAB ASSIGNMENT RESPONSE message...............................232
6.3.4.5 When LDR is triggered due to cell code resource congestion, no UE cannot be selected for LDR because the
proportions of code resources utilized by all operators do not exceed the preset limit....................................................233
6.3.4.6 The call drop rate of UEs in the CELL_FACH state increases due to SRB resets...............................................234
6.3.4.7 The RNC cannot initiate redirections, handovers, or fast return to E-UTRAN cells on frequency band 28.......235
6.3.4.8 The RNC sends the UE EARFCNs that the UE does not support when initiating blind redirections or fast return.
..........................................................................................................................................................................................237
6.3.4.9 The RNC incorrectly calculates the GSM cell load when triggering a service-based or load-based UMTS-toGSM handover..................................................................................................................................................................238
6.3.4.10 The RNC fails to update the number of RB Parking UEs in a cell in time when the number of RB Parking UEs
in the cell reaches the maximum value.............................................................................................................................239
6.3.4.11 The RNC incorrectly sets the offset of the maximum FACH transmit power to 0 after the execution of the
MOD USCCPCH command.............................................................................................................................................239
6.3.4.12 The NodeB returns a failure message for RL setup or reconfiguration when the DC-HSDPA+MIMO and CPCDTX/DRX features are both configured or the DB-HSDPA+MIMO and CPC-DTX/DRX features are both configured.
..........................................................................................................................................................................................240
6.3.4.13 The RNC incorrectly determines whether WRFD-160208 160 HSPA Users per Cell and WRFD-160209 192
HSPA Users per Cell are enabled.....................................................................................................................................242
6.3.4.14 FAM data differs from BAM data if the MOD UCELLNAME command is executed after cell relocation.....243
6.3.4.15 Some terminals display the GPS icon that should not be displayed...................................................................243
6.3.4.16 Power consumption of some terminals increases because they fail to disable the A-GPS function..................245
6.3.4.17 The SPU subsystem is reset due to excess soft handover messages..................................................................246
6.3.4.18 The RNC fails to clear the timer as excepted after UEs whose resources are preempted enter the RB Parking
state...................................................................................................................................................................................247
6.3.4.19 The block status of cells and NodeBs cannot be synchronized from the master RNC to the backup RNC.......248
6.3.4.20 The MR function does not take effect for UEs whose best cells are DRNC cells.............................................248
6.3.4.21 Call drops occur because soft handovers cannot be triggered in time after incoming static relocations over the
Iur interface are complete.................................................................................................................................................249
6.3.4.22 Service groups that are added for a differentiated services code point (DSCP) after the digital signal processor
(DSP) is successfully loaded do not take effect...............................................................................................................250
6.3.4.23 The "Cell Load Information Group" IE in the RELOCATION REQUIRED message cannot be parsed..........251
Issue 01 (2014-12-31)

Copyright Huawei
xiii
BSC6900 UMTS
Release Notes
Contents
6.3.4.24 A UE in the CELL_FACH state fails to initiate CS services..............................................................................254

6.3.4.25 There are no license control items in the license file for features that are changed from trial features.............254
6.3.4.26 The RNC does not support measurements of downlink PS service quality related to multiple throughput
thresholds during the same period....................................................................................................................................256
6.3.4.27 The UE experiences a call drop due to RL failures caused by reasons other than synchronization failures.....259
6.3.4.28 Services or cells cannot be established on the DSP subsystem whose KPIs deteriorate....................................259
6.3.4.29 The SPU CPU usage rises instantaneously due to the execution of the SET UCHRSCOPE or SET UMRSCOPE
command..........................................................................................................................................................................260
6.3.4.30 The queried OMUc board electronic label is incorrect......................................................................................262
6.3.4.31 The alarm location information in some transmission alarms is insufficient.....................................................263
6.3.4.32 The failure cause cannot be quickly identified when an IP continuity check fails.............................................264
6.3.4.33 No information is available for locating the fault when a chip of the signaling processing board, service
processing board, service identification board, or interface processing board fails to be initialized...............................264
6.3.4.34 The setting of the Check active/standby status consistency option is inconsistent with the actual function
implementation.................................................................................................................................................................265
6.4 Known Issues..............................................................................................................................................................266
6.4.1 Critical.....................................................................................................................................................................266
6.4.2 Major.......................................................................................................................................................................266
6.4.3 Minor.......................................................................................................................................................................266
6.4.4 Suggestion...............................................................................................................................................................266
7 Changes from V900R016C00SPH608 to V900R016C00SPH609......267

7.1 Change Summary.......................................................................................................................................................267
7.1.2 Hardware.................................................................................................................................................................268
7.1.3 Features....................................................................................................................................................................268
7.1.4 Resolved Issues.......................................................................................................................................................268
7.2 Feature Changes.........................................................................................................................................................269
7.2.1 New Features...........................................................................................................................................................269
7.3 Resolved Issues..........................................................................................................................................................270
7.3.1 Critical.....................................................................................................................................................................270
7.3.2 Major.......................................................................................................................................................................270
7.3.2.1 The WebLMT displays a message "Internal error" if the file name of an uploaded file contains Chinese
characters in batch configuration......................................................................................................................................270
7.3.2.2 Multicast configuration fails after an SCU board has been running for an excessively long period of time.......270
7.3.3 Minor.......................................................................................................................................................................271
Issue 01 (2014-12-31)

Copyright Huawei
xiv
BSC6900 UMTS
Release Notes
Contents
7.3.4 Suggestion...............................................................................................................................................................271
7.4 Known Issues..............................................................................................................................................................271
7.4.1 Critical.....................................................................................................................................................................271
7.4.2 Major.......................................................................................................................................................................271
7.4.3 Minor.......................................................................................................................................................................272
7.4.4 Suggestion...............................................................................................................................................................272

8.1 Change Summary.......................................................................................................................................................273
8.1.2 Hardware.................................................................................................................................................................274
8.1.3 Features....................................................................................................................................................................274
8.1.4 Resolved Issues.......................................................................................................................................................275
8.2 Feature Changes.........................................................................................................................................................276
8.2.1 New Features...........................................................................................................................................................276
8.3 Resolved Issues..........................................................................................................................................................276
8.3.1 Critical.....................................................................................................................................................................276
8.3.2 Major.......................................................................................................................................................................276
8.3.2.1 The CN or the neighboring RNC signaling points become unavailable when the signaling point code is
expressed in segments......................................................................................................................................................276
8.3.2.2 The RNC incorrectly unblocks cells when processing the NBAP audit response message.................................277
8.3.2.3 The AOUc or UOIc boards are switched over after SAAL link loopback detection is enabled on these boards.278
8.3.2.4 The service awareness-based user experience evaluation function becomes unavailable after the NIUa board has
been running for more than 24 consecutive days.............................................................................................................279
8.3.3 Minor.......................................................................................................................................................................279
8.3.4 Suggestion...............................................................................................................................................................279
8.4 Known Issues..............................................................................................................................................................279
8.4.1 Critical.....................................................................................................................................................................279
8.4.2 Major.......................................................................................................................................................................280
8.4.3 Minor.......................................................................................................................................................................280
8.4.4 Suggestion...............................................................................................................................................................280

9.1 Change Summary.......................................................................................................................................................281
Issue 01 (2014-12-31)

Copyright Huawei
xv
BSC6900 UMTS
Release Notes
Contents
9.1.2 Hardware.................................................................................................................................................................282
9.1.3 Features....................................................................................................................................................................282
9.1.4 Resolved Issues.......................................................................................................................................................283
9.2 Feature Changes.........................................................................................................................................................284
9.2.1 New Features...........................................................................................................................................................284
9.2.2.1 Optimization of the Inter-Frequency DRD Function During PS Service Setup...................................................284
9.2.2.2 PCHR, MR, and VIP Files Generated Within a Full Hour...................................................................................285
9.2.2.3 Inter Frequency Load Balance Feature Considering HSDPA User Number in Candidate Cells.........................287
9.2.2.4 Transmission Requirements-based Channel Reconfiguration for the PS Service in CS+PS Combined Services
Considering RF Quality....................................................................................................................................................289
9.2.2.5 Uplink Rate of PS BE Services Not Reduced to the Initial Access Rate After HSUPA Reconfiguration...........292
9.2.2.6 Added the G_NIC Command Group for Encapsulating All Commands for the NIC Function...........................294
9.2.2.7 Enhanced Anti-Attack Protection for Fragmented Packets Received by the Interface Board.............................295
9.3 Resolved Issues..........................................................................................................................................................297
9.3.1 Critical.....................................................................................................................................................................297
9.3.1.1 Measurement control hampers the CS RB setup, leading to incorrect adjustment of encryption parameters.....297
9.3.2 Major.......................................................................................................................................................................298
9.3.2.1 The Huawei DRNC does not support radio link addition with serving cell changes...........................................298
9.3.2.2 The measured value of the VS.AMR.Erlang.Equiv.PLMN.RNC counter is incorrect in MOCN scenarios.......299
9.3.2.3 The IDs of six counters in RAN16.0 are inconsistent with the IDs of these counters in RAN15.0.....................300
9.3.2.4 UEs that cannot be handed over to the LTE network still start RSCP measurements after the function of servicebased UMTS-to-LTE handover requiring RSCP measurement is enabled.......................................................................300
9.3.2.5 Services cannot be set up after a large number of event 1J reports fail to be processed......................................301
9.3.2.6 Services carried on a port of the SCUa board are affected due to inconsistency between the detection result and
actual status of the port.....................................................................................................................................................302
9.3.2.7 KPIs related to the CS CDR and PS CDR deteriorate when the active port is on the GOUe working in standby
mode and the NodeB enables the FPMUX function........................................................................................................302
9.3.3 Minor.......................................................................................................................................................................303
9.3.3.1 The integrity of RNC configuration data may be damaged when the "easy-in, difficult-out" principle is used to
configure intra-frequency neighboring cells on the CME................................................................................................303
9.3.3.2 Synchronization between the controller and the U2000/CME has not been performed for a long time because
configuration synchronization times out for several times...............................................................................................304
9.3.3.3 The AOUc/POUc/UOIc/PEUc/SPUb/DPUe/NIUa/FG2c/GOUc board incorrectly reports ALM-20280 Board
Temperature Abnormal.....................................................................................................................................................305
9.3.4 Suggestion...............................................................................................................................................................306
Issue 01 (2014-12-31)

Copyright Huawei
xvi
BSC6900 UMTS
Release Notes
Contents
9.3.4.1 The UMTS cell load information sent by the RNC to the eNodeB is delayed.....................................................306
9.3.4.2 The call drop rate increases after the Fast Radio Bearer Setup feature is enabled in weak coverage areas.........307
9.3.4.3 A cell enabled with the Downlink Enhanced CELL_FACH feature accommodates a lesser number of DCH UEs
than the configuration allows due to a large number of FACH UEs are admitted...........................................................308
9.3.4.4 The solution for the problem that the channel type of a UE frequently switches between HSPA and DCH when
the UE performs LTE measurement without starting the compressed mode is not controlled by any MML parameter. 309
9.3.4.5 SRBs cannot be carried on HS-DSCHs when the SRB D2H enhancement algorithm is enabled and the uplink
admission fails..................................................................................................................................................................309
9.3.4.6 Cross-Iur handovers fail when SRBs are carried on E-DCHs in the uplink........................................................310
9.3.4.7 The permissions of local users are lost when the BSC database is abnormal......................................................311
9.3.4.8 Instantaneous traffic is too heavy after the FTP upload and download performance is optimized......................312
9.3.4.9 The value of a single bit in the FPGA of the AOUc/POUc/UOIc/PEUc/DPUe/NIUa/FG2c/GOUc board is
changed and the FPGA cannot recover through self-healing...........................................................................................312
9.4 Known Issues..............................................................................................................................................................313
9.4.1 Critical.....................................................................................................................................................................313
9.4.2 Major.......................................................................................................................................................................313
9.4.3 Minor.......................................................................................................................................................................313
9.4.4 Suggestion...............................................................................................................................................................313
10 Changes from V900R016C00SPC600 to V900R016C00SPH602.....314

10.1 Change Summary.....................................................................................................................................................314
10.1.1 Capacity and Performance.....................................................................................................................................315
10.1.2 Hardware...............................................................................................................................................................315
10.1.3 Features..................................................................................................................................................................315
10.1.4 Resolved Issues.....................................................................................................................................................316
10.1.5 Operation and Maintenance...................................................................................................................................316
10.1.5.1 Configuration Management................................................................................................................................316
10.1.5.2 Performance Management..................................................................................................................................316
10.1.5.3 Fault Management..............................................................................................................................................316
10.1.5.4 License Management..........................................................................................................................................317
10.1.6 Related Documentation.........................................................................................................................................317
10.2 Feature Changes.......................................................................................................................................................317
10.2.1 New Features.........................................................................................................................................................317
10.2.2 Modified Features..................................................................................................................................................317
10.2.2.1 Optimized Load Based Dynamic Adjustment of PCPICH.................................................................................317
10.2.2.2 Inter-RAT DRD for Combined Services............................................................................................................319
10.2.2.3 Control on the Scope of Intra-Frequency Periodic Measurement Reports.........................................................320
10.2.2.4 Control on the Number of Intra-Frequency Periodic Measurement Reports.....................................................322
10.2.2.5 Immediately Notifying the Peer End of the Receive Buffer Space Update.......................................................323
10.2.2.6 Upgrade Tool Supporting Risk Check Before an Upgrade................................................................................325
10.2.2.7 Removed the FTP Text Box from the Batch Configuration Module..................................................................327
10.2.2.8 Support for Feature-based Information Display in the LST LICENSE Command Output................................328
10.2.3 Deleted Features....................................................................................................................................................329
Issue 01 (2014-12-31)

Copyright Huawei
xvii
BSC6900 UMTS
Release Notes
Contents
10.3 Resolved Issues........................................................................................................................................................329

10.3.1 Critical...................................................................................................................................................................329
10.3.2 Major.....................................................................................................................................................................329
10.3.2.1 The measurement scopes are incomplete for counters measuring the number of successful CS service
establishments initiated by UEs........................................................................................................................................329
10.3.2.2 The RNC continues to allocate services to the DPU boards when the service subrack accommodating these
boards is being removed...................................................................................................................................................333
10.3.2.3 GPS data is redundantly broadcast among SPU subsystems..............................................................................334
10.3.2.4 Users cannot log in to the WebLMT on the PC where JRE of a specific version is installed............................335
10.3.2.5 The FG2a or GOUa board does not perform BFD in compliance with RFC 5880............................................335
10.3.2.6 The High-Risk Command List in MML Command Reference includes some non-risky commands................336
10.3.3 Minor.....................................................................................................................................................................337
10.3.3.1 Cell user number on Cell Performance Monitoring is still greater than 0 after the NodeB is powered off.......337
10.3.3.2 PS services whose resources cannot be preempted have their resources preempted.........................................337
10.3.3.3 The RNC does not record PCHR logs for online users in a certain scenario.....................................................338
10.3.3.4 The distribution of DC-HSDPA users is inconsistent before and after the upgrade...........................................339
10.3.3.5 The excessively long MML command outputs cannot be completely displayed on the U2000........................340
10.3.3.6 The BSC occasionally reports ALM-20241 Board Unavailable with Slot No. set to EMU..............................341
10.3.4 Suggestion.............................................................................................................................................................342
10.3.4.1 Configuration data in the OMU buffer may be inconsistent with that in the OMU database after the SET
UKPIALMTHD command is executed............................................................................................................................342
10.3.4.2 The functions of code resource preemption for HSPA common channels forcibly take effect in upgrade
scenarios...........................................................................................................................................................................342
10.3.4.3 The number of failed preparations for LTE-to-UMTS handovers increases due to incorrect calculation of DC
carrier group load on the RNC side..................................................................................................................................343
10.3.4.4 The measurement points of counters measuring the RRC and RAB setups of CSFB UEs have been changed.
..........................................................................................................................................................................................344
10.3.4.5 The call drop rate is high during SRB bearer channel reconfiguration..............................................................345
10.3.4.6 The combined cell update and relocation procedure fails when a UE has a single CS signaling connection....347
10.3.4.7 The alarm location information in ALM-21521, ALM-21503, and ALM-21553 is insufficient.......................348
10.3.4.8 The counter values measured during a patch upgrade are incorrect...................................................................348
10.4 Known Issues............................................................................................................................................................349
10.4.1 Critical...................................................................................................................................................................349
10.4.2 Major.....................................................................................................................................................................349
10.4.3 Minor.....................................................................................................................................................................349
10.4.4 Suggestion.............................................................................................................................................................349
11 Operation and Maintenance Changes........................................350

11.1 MML Command Changes........................................................................................................................................350
11.2 Parameter Changes...................................................................................................................................................350
11.3 Alarm Changes.........................................................................................................................................................350
11.4 Event Changes..........................................................................................................................................................350
11.5 Counter Changes.......................................................................................................................................................350
11.6 License Changes.......................................................................................................................................................351
Issue 01 (2014-12-31)

Copyright Huawei
xviii
BSC6900 UMTS
Release Notes
Contents
11.7 Other Changes..........................................................................................................................................................351
A Obtaining Documentation..........................................................352
B Acronyms and Abbreviations......................................................354
Issue 01 (2014-12-31)

Copyright Huawei
xix
BSC6900 UMTS
Release Notes
1 Version Requirements
Version Requirements
1.1 Product Version

Product Name
HUAWEI BSC6900
Product Model
HUAWEI BSC6900
Product
Version
V900R016C00SPC650
1.2 Software Versions

Software
Version
LMT
V900R016C00SPC650
BAM
V900R016C00SPC650
U2000 Mediation
BSC6900 UMTS:
iManagerOSS_BSC6900UMTS_MATCH_ENG_V200R014C00SP
C650
Issue 01 (2014-12-31)

Copyright Huawei
BSC6900 UMTS
Release Notes
1.3 Hardware Versions

Physical
Board
Name
Logical
Board
Name
Bar Code
Label
PCB
Version
BIOS/Exten
ded BIOS
Version
BootRO
M
Upgrade
Require
d
(Yes/No)
SCUa
SCUa
WP11SCUa
Ver.D
269
Yes
GCUa
GCUa
WP11GCUa
Ver.B
269
Yes
269
Yes
269
Yes
Ver.C
Ver.F
Ver.G
GCGa
GCGa
QW21WGC
Ga
Ver.B
Ver.C
Ver.F
Ver.G
SPUa
SPUa/UCP
WP11SPUa
SPUa/RUCP
Ver.B
Ver.C
DPUb
DPUb/UUP
WP13DPUb
Ver.C
269
Yes
AEUa
AEUa/ATM
WP11AEUa
Ver.A
120
Yes
AOUa
AOUa/ATM
WP11AOUa
Ver.A
120
Yes
UOIa
UOIa/ATM
WP11UOIa
Ver.A
120
Yes
UOIa/IP
PEUa
PEUa/IP
WP11PEUa
Ver.A
120
Yes
POUa
POUa/IP
WP11POUa
Ver.A
120
Yes
FG2a
FG2a/IP
WP11FG2a
Ver.A
120
Yes
GOUa
GOUa/IP
WP11GOUa
Ver.A
120
Yes
SPUb
SPUb/UCP
WP11SPUb
Ver.B
140
Yes
141
Yes
141
Yes
SPUb/RUC
P
Ver.C
SPUb/NASP
Ver.E
Ver.D
Ver.F
DPUe
DPUe/UUP
WP11DPUe
Ver.B
Ver.C
Ver.E
AOUc
AOUc/ATM
WP11AOUc
Ver.B
Ver.C
Issue 01 (2014-12-31)

Copyright Huawei
BSC6900 UMTS
Release Notes
Physical
Board
Name
Logical
Board
Name
Bar Code
Label
PCB
Version
BIOS/Exten
ded BIOS
Version
BootRO
M
Upgrade
Require
d
(Yes/No)
141
Yes
141
Yes
141
Yes
141
Yes
Ver.E
UOIc
UOIc/ATM
WP11UOIc
Ver.B
Ver.C
Ver.E
POUc
POUc/IP
WP11POUc
Ver.B
Ver.C
Ver.E
FG2c
FG2c/IP
WP11FG2c
Ver.B
Ver.C
Ver.E
GOUc
GOUc/IP
WP11GOUc
Ver.B
Ver.C
Ver.E
OMUa
OMUa
WP11OMUa
042
OMUc
OMUc
WP13OMUc
Ver.B
102
Yes
SCUb
SCUb
WP11SCUb
Ver.B
133
Yes
Ver.C
NIUa
NIUa
WP11NIUa
Ver.E
141
Yes
PEUc
PEUc
WP11PEUc
Ver.A
141
Yes
GCUb
GCUb
WP11GCUb
Ver.C
137
Yes
GCGb
GCGb
QW11WGC
Gb
Ver.C
137
Yes
SPUc
SPUc/UCP
WP11SPUc
Ver.A
106
Yes
WP11GOUe
Ver.A
106
Yes
SPUc/RUCP
SPUc/NASP
GOUe
Issue 01 (2014-12-31)
GOUe/IP

Copyright Huawei
BSC6900 UMTS
Release Notes
1.4 Related Product Versions

Product
Name
Product
Model
Product Version
Remar
ks
U2000
U2000
iManager U2000 V200R014C00SPC200 or

later
N/A
CME
CME
iManager U2000-CME
V200R014C00SPC200 or later
PRS
PRS
iManager PRS V100R014C00 or later
ECO6910
ECO6910
ECO6910 V100R003C00SPC600 or later
Tools
INSIGHT
SHARP
INSIGHT SHARP V100R002C00SPC700

or later
NASTAR
GENEX Nastar V600R014C00SPC100 or

later.
NOTE
If you need to configure two SAU boards,
the version of the two SAU boards must be
GENEX Nastar V600R011C00SPC201 or
later.
NodeB
NodeB V1
If the GNFD-201220 UMTS Data Service

Resource Analysis or GNFD-201230 UMTS
Terminal Traffic Model Analysis feature of
the GENEX Nastar needs to be enabled, the
GENEX Nastar in V600R014C00SPC230
or later is required.
DBS3800 V100R016C00SPC100
RAN16.0
BTS3812E V100R016C00SPC100
NodeB V2
BTS3900 V100R009C00SPC100 or later
RAN16.0
1.5 OS and Database Versions

OS/Database
Version
Patch Package
Version
Remarks
Windows 2003 Server

Standard Edition SP2
Patch package:
Only the installation can be

performed.
Win2k3ENx8620xxBasic(B
asic patch package) +
win2k3ENx8620xxyy(Incre
ment patch package)
NOTE
Install the increment patch
package only when it exists.
Contact Huawei engineers

who can obtain the patch
package by performing the
following operation:
1. Access
http://support.huawei.com.
2. After a successful login,
choose Software Center >
Issue 01 (2014-12-31)

Copyright Huawei
BSC6900 UMTS
Release Notes
OS/Database
Version
Patch Package
Version
Remarks
Version Software >
Wireless Product Line >
SingleRAN > MBSC.
3. Download the newest
patch version.
NOTE
The detailed information about
the patch is listed in the
Patches information list.
SUSE Linux 9
None

performed.
DOPRA Linux
V100R001C03
None
The installation and upgrade

can be performed.
DOPRA Linux V200R003
DOPRA Linux
V200R003C08SPC080
The installation can be

performed, and some
versions can be upgraded to
the latest patch version. For
details about these versions,
see section 1.1
"Environment Requirements
for Upgrade" in Guide to
Dopra Linux Operating
System Remote Patch
Upgrade.
NOTE
Patch packages of earlier
versions can still be used, but
you are advised to use the
DOPRA Linux patch package
of the latest version.
NOTE
Contact Huawei engineers who
can obtain Guide to Dopra
Linux Operating System
Remote Patch Upgrade by
performing the following
operation:
1. Access
http://support.huawei.com.
2. After a successful login,
choose Software Center >
Version Software > Wireless
Product Line > SingleRAN >
MBSC.
3. Download Guide to Dopra
Linux Operating System
Remote Patch Upgrade.
MySQL5.0.96
Issue 01 (2014-12-31)
None

Copyright Huawei

performed.
BSC6900 UMTS
Release Notes
1.6 Related Documentation

Solution
Version
Product
Version
Documentation
Website
RAN16.0
BSC6900
V900R016C00SPC6
50
(For
Customer)BSC6900
UMTS Product
Documentation(V900R
016C00_06)-EN
A Obtaining
Documentation
(For
Customer)RAN16.0
Feature Documentation
06 (HDX)-EN
RAN16.0
BSC6900
V900R016C00SPC6
30
(For
Customer)BSC6900
UMTS Product
Documentation(V900R
016C00_05)-EN
(For
Customer)RAN16.0
05 (HDX)-EN
RAN16.0
BSC6900
V900R016C00SPH6
21
BSC6900
V900R016C00SPC6
20
RAN16.0
BSC6900
V900R016C00SPH6
08
BSC6900
V900R016C00SPH6
05
RAN16.0
BSC6900
V900R016C00SPH6
02
(For
Customer)BSC6900
UMTS Product
Documentation(V900R
016C00_04)-EN
(For
Customer)RAN16.0
04 (HDX)-EN
(For
Customer)BSC6900
UMTS Product
Documentation(V900R
016C00_03)-EN
(For
Customer)RAN16.0
03 (HDX)-EN
(For
Customer)BSC6900
UMTS Product
Documentation(V900R
016C00_02)-EN
(For
Customer)RAN16.0
Issue 01 (2014-12-31)

Copyright Huawei
BSC6900 UMTS
Release Notes
Solution
Version
Product
Version
Documentation
Website
02 (HDX)-EN
RAN16.0
BSC6900
V900R016C00SPC6
00
(For
Customer)BSC6900
UMTS Product
Documentation(V900R
016C00_01)-EN
(For
Customer)RAN16.0
01 (HDX)-EN
1.7 Virus Scan Result

This software package has been scanned by the following antivirus software and no risks were
found. The following table lists the virus scan results.
Antivirus
Software
Name
Antivirus
Software
Version
Antivirus
Database
Version
Time of
Scan
Result
Kav
10.1.0.867
20141227060013
2014-12-31
No risks were
found.
Avira
8.03.28.004
7.11.198.020
2014-12-31
No risks were
found.
Symantec
12.1.2015.2015
2014-12-25r3
2014-12-31
No risks were
found.
McAfee
5600:1067
7662:0
2014-12-31
No risks were
found.
OSCE
9.750.1007
1136900
2014-12-31
No risks were
found.
1.8 Important Notes

Table 1.1 Important notes for using BSC6900 V900R016C00SPC650
No.
Event
Remarks
Time restrictions
None
Issue 01 (2014-12-31)

Copyright Huawei
BSC6900 UMTS
Release Notes
No.
Event
Remarks
Region/site restrictions
None
Other restrictions
The restricted features must be tested on one site

before the commercial release.
Version termination
The time that a version terminates depends on the

version lifecycle management.
Issue 01 (2014-12-31)

Copyright Huawei
BSC6900 UMTS
Release Notes
2 Version Compatibility
Version Compatibility
2.1 Software Version Compatibility

RNC version compatibility: The current version supports all the features of
BSC6900V900R015C00, BSC6900V900R014C00 and earlier versions.
2.2 Hardware Version Compatibility

The following table describes compatibility between the hardware and the software versions.
Y indicates that the current product version is compatible with an earlier board software version, and N
indicates that the current product version is incompatible with an earlier board software version.
Table 1.1
Board Name
BSC6900V900R015C
00
BSC6900V900R014C
00
SCUa
SCUb
GCUa
GCGa
SPUa
SPUb
DPUb
DPUe
AEUa
AOUa
AOUc
Issue 01 (2014-12-31)

Copyright Huawei
BSC6900 UMTS
Release Notes
2 Version Compatibility
Board Name
BSC6900V900R015C
00
BSC6900V900R014C
00
UOIa
UOIc
PEUa
POUa
POUc
FG2a
FG2c
GOUa
GOUc
OMUa
OMUc
NIUa
PEUc
GCUb
GCGb
SPUc
GOUe
Issue 01 (2014-12-31)

Copyright Huawei
10
BSC6900 UMTS
Release Notes
3 Changes from V900R016C00SPC630 to

V900R016C00SPC650
Changes from
V900R016C00SPC630 to
V900R016C00SPC650
3.1 Change Summary
Capacity and Performance
Compared with those in BSC6900 V900R016C00SPC630, capacity and performance remain
unchanged in V900R016C00SPC650.
Hardware
Compared with that in BSC6900 V900R016C00SPC630, hardware remains unchanged in
V900R016C00SPC650.
Features
Compared with those in BSC6900 V900R016C00SPC630, 20 features have been modified,
but no features have been added or deleted in V900R016C00SPC650.
3.1.3 Features provides the following information about new or modified features:
Whether this feature has any impact on capacity and performance
Whether this feature is license-controlled
Whether this feature requires hardware support
Whether data configurations are required to enable this feature
Resolved Issues
Compared with those in BSC6900 V900R016C00SPC630, 1 critical issues, 24 major issues,
24 minor issues, and 14 suggestion-level issues have been resolved in V900R016C00SPC650.
3.1.4 Resolved Issues provides the following information about resolved issues:
Issue 01 (2014-12-31)
Whether there is any impact of this solution

Copyright Huawei
11
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Whether this solution is controlled by a parameter
Default value of the parameter that controls the solution after an upgrade
Operation and Maintenance
Configuration management
Compared with those in BSC6900 V900R016C00SPC630, configuration management
functions remain unchanged in V900R016C00SPC650. For details, see 11.1 MML
Command Changes and 11.2 Parameter Changes.
Performance management
Compared with those in BSC6900 V900R016C00SPC630, performance management
functions remain unchanged in V900R016C00SPC650. For details about counter
changes, see 11.5 Counter Changes.
Fault management
Compared with those in BSC6900 V900R016C00SPC630, fault management functions
remain unchanged in V900R016C00SPC650. For details about alarm and event changes,
see 11.3 Alarm Changes and 11.4 Event Changes, respectively.
License management
Compared with those in BSC6900 V900R016C00SPC630, license management
functions remain unchanged in V900R016C00SPC650. For details, see 11.6 License
Changes.
Related Documentation
Compared with those in BSC6900 V900R016C00SPC630, document organization and
document templates remain unchanged in V900R016C00SPC650. For details, see 3.1.6
Related Documentation.
3.1.1 Capacity and Performance

This section describes the general impact of this versin on system capacity and network
performance.
unchanged in BSC6900 V900R016C00SPC650.
3.1.2 Hardware
This section describes any hardware addition and modification. The hardware end of
marketing (EOM) and end of service (EOS) information does not map onto the software
version. For details, see the corresponding product change notice (PCN).
New Hardware
None
Modified Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
12
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.1.3 Features
This section provides a summary of all features changes from BSC6900
V900R016C00SPC630 to V900R016C00SPC650.
The summary provides the following information:
Change type
Feature description
Impact on capacity and performance
Hardware support required by this feature
For a summary of these changes, see Summary of Feature Changes in BSC6900 UMTS
V900R016C00SPC650.xls, or see the V900R016C00SPC650 vs V900R016C00SPC630 sheet
in Summary of Feature Changes delivered with the release notes for a version later than
BSC6900 V900R016C00SPC650.
For details, see 3.2 Feature Changes.
3.1.4 Resolved Issues

This section provides the summary of the known issues in BSC6900 V900R016C00SPC630
that have been resolved in V900R016C00SPC650.
Trouble ticket number
Issue description
Severity
Solution impact
Parameter control
Default value of the parameter that controls the solution after an upgrade.
For a summary of these issues, see Summary of Resolved Issues in BSC6900 UMTS
V900R016C00SPC650.xls, or see the the V900R016C00SPC650 vs V900R016C00SPC630
sheet in Summary of Resolved Issues delivered with the release notes for a version later than
BSC6900 V900R016C00SPC650.
For details about these issues, see 3.3 Resolved Issues.
3.1.5 Operation and Maintenance

3.1.5.1 Configuration Management
Compared with V900R016C00SPC630, configuration management functions remain
unchanged in V900R016C00SPC650. For details about configuration management, see 11.1
MML Command Changes and 11.2 Parameter Changes.
Issue 01 (2014-12-31)

Copyright Huawei
13
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.1.5.2 Performance Management

Compared with V900R016C00SPC630, performance management functions remain
unchanged in V900R016C00SPC650. For details about counter changes, see 11.5 Counter
Changes.
3.1.5.3 Fault Management

Compared with V900R016C00SPC630, fault management functions remain unchanged in
V900R016C00SPC650. For details about changes to alarms and events, see 11.3 Alarm
Changes and 11.4 Event Changes.
3.1.5.4 License Management

Compared with V900R016C00SPC630, license management functions remain unchanged in
V900R016C00SPC650. For details about license changes, see 11.6 License Changes.
3.1.6 Related Documentation

For details about documentation updates, see (For Customer)BSC6900 UMTS Product
Documentation (V900R016C00_06)(HDX)-EN.
3.2 Feature Changes

3.2.1 New Features
None
3.2.2 Modified Features

3.2.2.1 Considering the Power Load of Multi-carrier HSDPA
UEs in the CLB Algorithm
Description
This feature allows the RNC to perform the following for a cell that supports multi-carrier
HSDPA:
Consider the power load of multi-carrier HSDPA UEs when making decisions on
enabling CLB for the cell based on downlink power.
Trigger inter-frequency handovers for multi-carrier HSDPA UEs after CLB has been
enabled for the cell.
Implementation
RESERVED_SWITCH_13_BIT18 under the RsvSwitch13 parameter in the SET
UALGORSVPARA command controls whether to enable this feature. By default, this feature
is disabled (default value: 0) for both new networks and upgrade scenarios.
When this feature is enabled, the RNC performs the following for a cell that supports multicarrier HSDPA:
Issue 01 (2014-12-31)

Copyright Huawei
14
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Considers the power load of multi-carrier HSDPA UEs when making decisions on
enabling CLB for the cell based on downlink power.
Triggers inter-frequency handovers for multi-carrier HSDPA UEs after CLB has been
enabled for the cell.
Impact on Capacity and Performance

After this feature is enabled:
The probability of enabling CLB for a cell increases.
Inter-frequency outgoing hard handover attempts (indicated by counter
VS.HHO.AttInterFreqOut.CS.TotalTxPwr and counter
VS.HHO.AttInterFreqOut.PS.TotalTxPwr) triggered by downlink power congestion increase.
The number of successful attempts (indicated by counter
VS.HHO.SuccInterFreqOut.CS.TotalTxPwr and counter
VS.HHO.SuccInterFreqOut.PS.TotalTxPwr) increases.
The call drop rate increases.
The RNC can evaluate cell load more accurately and balances inter-frequency load more
effectively, improving resource utilization.
Impact on NEs
None
Impact on Hardware
None
Impact on Inter-NE Interfaces

None
Impact on Operation and Maintenance
Impact on license management:

None
Impact on configuration management

UALGORSVPARA command is used to control whether to enable this feature.
Impact on performance management

None
Impact on fault management:

None
Impact on Other Features

None
Issue 01 (2014-12-31)

Copyright Huawei
15
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Related Operations
To enable this feature, run the following MML command:
SET UALGORSVPARA: RsvSwitch13 = RESERVED_SWITCH_13_BIT18-1;
To disable this feature, run the following MML command:
SET UALGORSVPARA: RsvSwitch13 = RESERVED_SWITCH_13_BIT18-0;
Trouble Ticket Number

DTS: DTS2014111402733
Feature ID
WRFD-140217
3.2.2.2 Iur-p Link Loopback Detection Self-Healing

Description
If an interface board that carries Iur-p links is improperly running, these links will be faulty
for a long time. This feature supports Iur-p link detection in this scenario and enables the
RNC to switch over or reset the faulty interface board once the Iur-p link fault in the interface
board is detected.
Implementation
If an Iur-p link becomes faulty, the RNC will automatically initiate a detection from the
control plane subsystem where the link is configured to the interface board that carries the
link and checks whether the interface board is running properly. If the interface board is
improperly running, the RNC will automatically switch over or reset the interface board.
SW19 of Reserved Switch Parameter1 in the SET TNRSVDPARA controls whether to
enable Iur-p link detection. By default, Iur-p link detection is enabled (default value: 0) for
both new networks and upgrade scenarios.
0: Iur-p link detection is enabled. If the interface board that carries Iur-p links are
improperly running, the base station controller will switch over or reset the interface
board.
1: Iur-p link detection is disabled.

None
Impact on NEs
None
Impact on Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
16
BSC6900 UMTS
Release Notes

V900R016C00SPC650

None
Impact on license management

None

Enabled SW19 of Reserved Switch Parameter1 in the SET TNRSVDPARA to control
whether to enable Iur-p link detection.

None
Impact on fault management

None

None
Related Operations
To enable Iur-p link detection, run the following command:

SET TNRSVDPARA: RSVDSW1=SW19-0;
To disable Iur-p link detection, run the following command:


DTS:DTS2014110900149
Feature ID
None
3.2.2.3 Enhanced UMTS-to-LTE Fast Return Based on

Combined Services
Description
In a UMTS-to-LTE fast return process, instead of triggering an RB release procedure, the
RNC directly sends an RRC CONNECTION RELEASE message to release CS services. As a
result, the delay in UMTS-to-LTE fast return is reduced.
Implementation
When the CS service is terminated on a CSFB UE that is running combined services, the UE
sends a DISCONNECT message to the RNC and the CS CN delivers an IU RELEASE
COMMAND message to the RNC. Upon receiving the IU RELEASE COMMAND message,
the RNC triggers a fast return procedure. After this feature takes effect, the RNC directly
sends the UE an RRC CONNECTION RELEASE message that contains the frequency
Issue 01 (2014-12-31)

Copyright Huawei
17
BSC6900 UMTS
Release Notes

V900R016C00SPC650
information about neighboring E-UTRAN cells. In this way, the delay caused by the RB
release is reduced.
UALGORSVPARA command controls whether to enable this solution. By default, this
solution is disabled (default value: 0) for both new networks and upgrade scenarios.
The delay for a UE to return to the LTE network decreases.
Service drops decrease.
Impact on NEs
None
Impact on Hardware
None

None

None

UALGORSVPARA command controls whether to enable this solution.

None

None

None
Related Operations
To enable this solution, run the following MML command:
SET UALGORSVPARA: RsvSwitch12=RESERVED_SWITCH_12_BIT12-1;
To disable this solution, run the following MML command:

DTS: DTS2014111706998
Issue 01 (2014-12-31)

Copyright Huawei
18
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Feature ID
WRFD-140226
3.2.2.4 Exporting Configuration Information in the SET

LICENSE Command
Description
This feature exports the configuration information in the SET LICENSE command to save
the license allocation information of each operator.
Implementation
The enumerated value LIC_CFG_MML(The Allocated Information File of License)

is added to the Log File Type parameter in the COL LOG command. When the COL
LOG: LOGTYPE=LIC_CFG_MML-1; command is executed, the licensed values
assigned to each operator can be saved to the setlicense.zip file in the OMU active
workspace directory bam\version_x\ftp\COLLOGINFO\CFGLOG\ExportLicCfgmml.
During a patch rollback, the base station controller automatically exports the
configuration information in the SET LICENSE command to the setlicense.zip file and
saves this file in the OMU active workspace directory
bam\version_x\ftp\operator_log\exp_log.

None
Impact on NEs
None
Impact on Hardware
None

None

None

Added the enumerated value LIC_CFG_MML(The Allocated Information File of
License) to the Log File Type parameter in the COL LOG command.

None
Issue 01 (2014-12-31)

Copyright Huawei
19
BSC6900 UMTS
Release Notes

V900R016C00SPC650
None

None
Related Operations
To export the license configuration information, run the following command:
COL LOG: LOGTYPE=LIC_CFG_MML-1;

DTS: DTS2014080103737
Feature ID
None
3.2.2.5 Global Tracing of IMSI Messages in the CS Domain

Description
The RNC supports global tracing of the international mobile subscriber identity (IMSI)
messages in the CS domain.
Implementation
1.
Issue 01 (2014-12-31)
The RNC initiates global tracing after receiving a CN_Invoke_Trace message over the
Iu-CS interface, as shown in the following figure:

Copyright Huawei
20
BSC6900 UMTS
Release Notes

V900R016C00SPC650
2.
After an Iu-CS interconnection is established and the RNC receives a CN INVOKE

TRACE message from the CN, the RNC initiates global tracing and the RNC can
report the RRC CONNECTION REQUEST, RADIO LINK SETUP REQUEST, and
CN INVOKE TRACE messages.
When the signaling connection over the Iu-CS interface is released, the RNC stops
the global tracing.
The RNC OMU generates a trace files and sends the files to the U2000. The U2000
receives the trace files from the RNC OMU. The trace file is named
A_XXXXXXXX_XXXXXX+YYYY_RNC_RRRR_TT.tmf. In the file name,
XXXXXXXX_XXXXXX indicates the date_time zone offset, YYYY indicates the
daylight saving time (DST), RRRR indicates the tracing reference, and TT indicates
the transaction ID.
Specifications and restrictions:
If the RNC has initiated UE tracing, RAN integrated tracing, or DTMF tracing, the
RNC cannot initiate global tracing on the UE.
In this case, if the RNC has initiated global tracing for the UE, the RNC can initiate
UE tracing, RAN integrated tracing, and DTMF tracing but reports no tracing results.
The RNC can initiate single-user tracing (such as the UE tracing, RAN integrated
tracing, and global tracing of IMSI signaling messages) for a maximum of 12 UEs at
a time.
RESERVED_SWITCH_0_BIT1 under the RSVSWITCH0 parameter in the SET
UCNNODERSVPARA command controls whether to enable this solution. By
default, this solution is disabled (default value: 0) for both new networks and upgrade
scenarios. When this solution is enabled, the RNC initiates global tracing. When this
solution is disabled, the RNC does not initiates global tracing.
Issue 01 (2014-12-31)

Copyright Huawei
21
BSC6900 UMTS
Release Notes

V900R016C00SPC650

CPU usage of the SPU subsystem surges and the RRC connection setup success rate
decreases during peak hours.
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
To enable this solution, run the following MML command:

SET UCNNODERSVPARA:
CnOpIndex=X, CNId= X, RSVSWITCH0=RESERVED_SWITCH_0_BIT1-1;
To disable this solution, run the following MML command:

SET UCNNODERSVPARA:
CnOpIndex= X, CNId= X, RSVSWITCH0=RESERVED_SWITCH_0_BIT1-0;

DTS: DTS2014110406934
Feature ID
None
Issue 01 (2014-12-31)

Copyright Huawei
22
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.2.2.6 Optimization of NIC Information Collection Based on

SOP
Description
When network information is collected using the NIC tool and UMTS_BSC6900_SOP is
selected as the collection scenario, input parameters of some collection items need to be
manually specified. This operation is not suitable for collecting large amount of information
and affects O&M efficiency. This feature enables the NIC tool to automatically collect
information about each collection item without manually specifying parameters.
Implementation
After the NIC tool delivers the command for querying collection item information to an NE,
the NIC tool parses the scripts sent from the NE to automatically obtain the required
parameter settings. In this way, users do not need to manually specify these parameters.
For example, before this feature is introduced, users need to manually specify Subrack No.
and Slot No. to collect board common information, as shown in the following figure.
After this feature is introduced, when network information is collected using the NIC tool and
UMTS_BSC6900_SOP is selected as the collection scenario, the parameters shown in the
preceding figure are no longer displayed and do not need to be manually specified. The NIC
tool can automatically collect information about each collection item.

None
Impact on NEs
None
Issue 01 (2014-12-31)

Copyright Huawei
23
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
None

DTS: DTS2014120801457
Feature ID
None
3.2.2.7 LAI and SAI IEs Supported in the DIRECT TRANSFER

Message in the CS Domain
Description
With this solution, the DIRECT TRANSFER message sent to the CN by the RNC can carry
the SAI and LAI IEs, which provides location information during CS service implementation.
Implementation
When a UE initiates CS services, the RNC sends the CN a DIRECT TRANSFER message
that does not carry the LAI or SAI IE by default.
UCNNODERSVPARA command controls whether the DIRECT TRANSFER message
carries the LAI and SAI IEs.
Issue 01 (2014-12-31)

Copyright Huawei
24
BSC6900 UMTS
Release Notes

V900R016C00SPC650
The SET UCNNODERSVPARA command takes effect only after the CnOpIndex and CNId
parameters are set.
By default, this solution is disabled (default value: 0) for both new networks and upgrade
scenarios.
When this solution is enabled, the DIRECT TRANSFER message sent to the CN by the RNC
carries the SAI and LAI IEs.

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
Run the following MML command to enable this solution:
SET UCNNODERSVPARA: CnOpIndex=X, CNId=X,
RSVSWITCH0=RESERVED_SWITCH_0_BIT2-1;
Run the following MML command to disable this solution:
SET UCNNODERSVPARA: CnOpIndex=X, CNId=X,
Issue 01 (2014-12-31)

Copyright Huawei
25
BSC6900 UMTS
Release Notes

V900R016C00SPC650

DTS: DTS2014111910118
Feature ID
None
3.2.2.8 Support notifying the information of UEs capable of

downlink DC-HSDPA throughput optimization to the NodeB
Description
For UEs that support downlink DC-HSDPA throughput optimization, the RNC includes the
proprietary extended IE reserved3-private with the value of 1 in the RADIO LINK SETUP
REQUEST, RADIO LINK ADDITION REQUEST, and RADIO LINK
RECONFIGURATION PREPARE messages sent to the NodeB over the Iub interface.
Corresponding modification is also made on the NodeB side. For details, see the description of
DTS2014112107374 in BTS3900 V100R009C00SPC186 Release Notes.
Implementation
RESERVED_SWITCH_BIT25 under the RsvSwitch parameter in the ADD UIMEITAC
and MOD UIMEITAC commands controls whether to enable this solution. By default, this
solution is disabled (default value: 0) for both new networks and upgrade scenarios. When
this solution is enabled, the RNC includes the reserved3-private IE in the three messages.
When this solution is disabled, the RNC does not include the reserved3-private IE in the three
messages.
ADD/MOD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=*, Description="*",
RsvSwitch=RESERVED_SWITCH_BIT25-1;
RsvSwitch= RESERVED_SWITCH_BIT25-0;
In order for the solution to take effect, all UEs must report their international mobile equipment
identities (IMEIs) in either of the following ways:
The CN can query the IMEI of a UE running PS services.
Run the following command to query the IMEI of a UE on the RNC:

SET URRCTRLSWITCH:
PROCESSSWITCH2=RNC_PS_QUERY_UE_IMEI_SWITCH-1;

None
Issue 01 (2014-12-31)

Copyright Huawei
26
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact on NEs
None
Impact on Hardware
None

None

None

RESERVED_SWITCH_BIT25 under the RsvSwitch parameter in ADD UIMEITAC
and MOD UIMEITAC commands is used.

None

None

None
Related Operations
To enable this feature, run the following command:

DTS: DTS2014111910125
Feature ID
None
3.2.2.9 Support for Checking Resources of License Resource

Items During a Pre-upgrade
Description
This feature adds a license file check mechanism to the upgrade tool during a pre-upgrade of
the base station controller. If the number of resources of feature resource items in the license
file does not meet the license sales principles, a message is displayed on the upgrade tool
indicating that resources allocated to license resource items are insufficient.
Issue 01 (2014-12-31)

Copyright Huawei
27
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Implementation
During a pre-upgrade to BSC6900 V900R016SPC620BSC6910 V100R016SPC620 or later,
the upgrade tool checks the number of resources of feature resource items in the license file. If
the licensed number of resources is less than the reference number of resources in the license
sales principles, a message is displayed indicating that resources allocated to license resource
items are insufficient. After the upgrade, ALM-20259 Number of Resources Used Exceeding
Threshold Specified by License may be reported, and you are advised to apply for licenses
according to the license sales principles as soon as possible. For details about the reference
number of resources of license resource items, see License Control Item Lists.

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
None

DTS: DTS2014073002842
Issue 01 (2014-12-31)

Copyright Huawei
28
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Feature ID
None
3.2.2.10 Optimized Features for RACH Keepalive Function

Description
If the transmission link for the random access channel (RACH) is disconnected, the RNC
negotiates with the NodeB to determine whether to enable the RACH keepalive function.
Implementation
The field "PRIVATE RACHKEEPALIVEDETECT CAPABILITY" has been added to the
audit response message so that the NodeB proactively reports whether a cell supports the
RACH keepalive function. If the NodeB reports that the cell supports the keepalive function
and the switch is also turned on, the RNC enables the RACH keepalive function. In other
cases, the RNC does not enable the RACH keepalive function.
RsvdSwitch1_Bit31 of the RsvdSwitch1 parameter in the SET UDPUCFGDATA command
controls whether to enable this solution. By default, this solution is enabled (default value: 0)
for both new networks and upgrade scenarios.
Run the following command to enable this solution:
SET UDPUCFGDATA: RsvdSwitch1=RsvdSwitch1_Bit31-0;
Run the following command to disable this solution:
If RACH_SYNC_CHK_EFFECT_MODE_SWITCH and the preceding new switch are both

turned on, the RACH keepalive function is enabled.
RACH_SYNC_CHK_EFFECT_MODE_SWITCH can be turned on only when the NodeB

supports the RACH keepalive function.
If the RNC receives a synchronization frame from the NodeB, the RNC enables the RACH
keepalive function.

None
Impact on NEs
None
Impact on Hardware
None

None
Issue 01 (2014-12-31)

Copyright Huawei
29
BSC6900 UMTS
Release Notes

V900R016C00SPC650

None

RsvdSwitch1_Bit31 in the SET UDPUCFGDATA command is used.

None

None

None
Related Operations
1.


DTS: DTS2014111204865
Feature ID
None
3.2.2.11 Optimizing Reporting of EVT-22915 SCTP Link

Destination IP Changeover
Description
If an SCTP link is configured with two local IP addresses and one peer IP address and
intermediate transmission becomes faulty, ALM-21541 SCTP Link Fault and EVT-22915
SCTP Link Destination IP Changeover are reported simultaneously. As a result, operation and
maintenance (O&M) are affected. This feature optimizes the mechanism for reporting EVT22915 SCTP Link Destination IP Changeover to reduce the impact of EVT-22915 on other
key events.
Implementation
SW18 of Reserved Switch Parameter1 in the SET TNRSVDPARA command controls
whether to report EVT-22915 SCTP Link Destination IP Changeover when an SCTP link is
configured with two local IP addresses and one peer IP address.
0: EVT-22915 SCTP Link Destination IP Changeover is reported.
1: EVT-22915 SCTP Link Destination IP Changeover is not reported.
By default, this feature is disabled (default value: 0) for both new networks and upgrade
scenarios.
Issue 01 (2014-12-31)

Copyright Huawei
30
BSC6900 UMTS
Release Notes

V900R016C00SPC650

None
Impact on NEs
None
Impact on Hardware
None

None

None

Enabled SW18 of Reserved Switch Parameter1 in the SET TNRSVDPARA
command.

None

None

None
Related Operations

DTS: DTS2014102701712
Feature ID
None
Issue 01 (2014-12-31)

Copyright Huawei
31
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.2.2.12 Enhancement of Active/Standby Status Consistency

of Interface Boards and Ports Before and After an Upgrade
Description
By default, the Check active/standby status consistency option is not selected. Therefore,
users need to manually select this option. If it is not manually selected, transmission
interruption triggered by a board switchover after an upgrade may occur. With this feature, the
Check active/standby status consistency option in the Input Step 3 window of the upgrade
tool is selected by default. This feature reduces risks of transmission interruption triggered by
a board switchover after an upgrade.
Implementation
In the Input Step 3 window of the upgrade tool, the Check active/standby status
consistency option is selected by default, as shown in the following figure.

None
Impact on NEs
None
Impact on Hardware
None

None

None

None
Issue 01 (2014-12-31)

Copyright Huawei
32
BSC6900 UMTS
Release Notes

V900R016C00SPC650
None

None

None
Related Operations
None

DTS: DTS2014092004984
Feature ID
None
3.2.2.13 Optimizing Information Displayed at the Start of an

Upgrade Phase on the Upgrade Tool
Description
When the pre-upgrade is complete on the upgrade tool, the Next button and the message "Are
you sure ?" displayed on the upgrade tool are the same as those in other steps. By viewing this
information, users are likely to perform an upgrade caused by misoperation. This feature is
introduced to optimize the information displayed in this scenario.
Implementation
When the pre-upgrade is complete, the Execute Upgrade button is displayed instead of the
Next button. In addition, the message "You will step into upgrade execution, and you cannot
cancel during execution. Are you sure ?" is displayed instead of the message "Are you sure ?",
as shown in the following figure.
Issue 01 (2014-12-31)

Copyright Huawei
33
BSC6900 UMTS
Release Notes

V900R016C00SPC650

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None
Issue 01 (2014-12-31)

Copyright Huawei
34
BSC6900 UMTS
Release Notes

V900R016C00SPC650

None
Related Operations
None

DTS: DTS2014102107316
Feature ID
None
3.2.2.14 Adding the Prompt Message for Configuration Data

Change During a Rollback on the Upgrade Tool
Description
When users perform a version rollback using the upgrade tool after ever modifying
configuration data, this feature enables the upgrade tool to prompt users that configuration
data is ever changed and the configuration data may be lost after the rollback.
Implementation
A rollback pre-check item "Whether the system configuration data is ever changed after an
upgrade" is added to the upgrade tool. If system configuration data is ever modified after an
upgrade, the check result of this item is "Warning" and prompts users to perform relevant
operations.
If system configuration data remains unchanged after an upgrade, the item passes the check.

None
Impact on NEs
None
Impact on Hardware
None

None
Issue 01 (2014-12-31)

Copyright Huawei
35
BSC6900 UMTS
Release Notes

V900R016C00SPC650
None

None

None

None

None
Related Operations
None

DTS: DTS2014110701204
Feature ID
None
3.2.2.15 Changing Backup IP Address on the U_creator Tool

Description
When the OMU OS is switched using the U_creator tool, this feature allows users to directly
change the backup IP address on the tool interface instead of changing it by following steps in
OMU Administration Guide, thereby improving tool usability.
Implementation
If Operate Type is set to Switch on the U_creator tool, the backup IP address input box can
be edited. If the backup IP address is in the same network segment as other IP addresses, users
can directly change the backup IP address on the U_creator tool interface. After the OMU OS
is switched using the U_creator tool, the OMU backup IP address is the same as that
configured on the U_creator tool.
Issue 01 (2014-12-31)
If Operating System Type is set to DopraLinux, the (1)Backup network IP and (2)Backup
network IP input boxes can be edited, as shown in the following figure.

Copyright Huawei
36
BSC6900 UMTS
Release Notes

V900R016C00SPC650
If Operating System Type is set to EulerLinux, the Backup network IP input box can be edited,
as shown in the following figure.

None
Impact on NEs
None
Issue 01 (2014-12-31)

Copyright Huawei
37
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
None

DTS: DTS2014070814183
Feature ID
None
3.2.2.16 OMU Capacity Evaluation

Description
This feature enables the OMU to record its capacity monitoring log. This log is used to
evaluate the OMU performance.
Implementation
The OMU Capacity Monitoring Log Switch parameter in the SET OMUPARA command
controls whether to enable this feature. By default, this feature is disabled (default value:
OFF) for new networks, and the status of this feature is inherited after upgrades.
When OMU Capacity Monitoring Log Switch is set to ON(On), the OMU records its
capacity monitoring logs, and the name of the log file is capacity.csv. The log file is
compressed and backed up each time its size reaches 20 MB. A maximum of ten backup log
files are saved.
Issue 01 (2014-12-31)

Copyright Huawei
38
BSC6900 UMTS
Release Notes

V900R016C00SPC650
The OMU capacity is recorded every other 2s in the capacity monitoring log. The following
table describes the monitoring items.
Monitoring Item
Description
Cpu Util
CPU usage
Load average
Number of tasks to be processed by the CPU
Free Memory
Available memory
Swap Usage
Number of memory pages using the swap partition
IO Util
I/O usage
Await
I/O waiting queue length in the Windows operating

system;
I/O waiting delay in the Linux operating system
IOPS
Number of read and write operations every second

None
Impact on NEs
None
Impact on Hardware
None

None

None

Added the OMU Capacity Monitoring Log Switch parameter to the SET OMUPARA
command.

None

None

None
Issue 01 (2014-12-31)

Copyright Huawei
39
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Related Operations

SET OMUPARA:CAPMONLOGSW=ON;
To disable this feature, run the following command:

SET OMUPARA:CAPMONLOGSW=OFF;

DTS: DTS2014112104386
Feature ID
None
3.2.2.17 Support for Querying Manually Cleared Alarms

Description
This feature enables users to query manually cleared alarms and provides reference for users
to handle currently reported alarms.
Implementation
The LST MANRESALMLOG command is added and used to query manually cleared
alarms.
The specifications for manually cleared alarms are as follows:

A maximum of 2000 manually cleared alarms can be saved. If the number of manually
cleared alarms exceeds 2000, only the latest 1600 alarms are saved and other alarms are
deleted.
Manually cleared alarms can be saved for 365 days. If the saving time of an alarm
exceeds 365 days, this alarm will be deleted.
The base station controller checks whether the recorded alarms exceed the specifications
on a daily basis. The deleted alarms are backed up and generated as a compressed file
and saved in ftp/manresalmlog.
Users can run the COL LOG: LOGTYPE=HISTORY_ALARM-1; command to

collect the manually cleared alarms.

None
Impact on NEs
None
Impact on Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
40
BSC6900 UMTS
Release Notes

V900R016C00SPC650

None

None

Added the LST MANRESALMLOG command.

None

None

None
Related Operations
None

DTS:DTS2014071408266
Feature ID
None
3.2.2.18 Changing the Default Value of Automatic

Synchronization Switch
Description
Before this feature is introduced, the automatic synchronization switch is turned off (default
value: OFF) for both new networks and upgrade scenarios by default and customers need to
manually enable this function by running the SET SYNSWITCH command.
With this feature, the automatic synchronization switch is turned on (default value: ON) for
both new networks and upgrade scenarios by default.
If the scheduled task triggered by running the ACT CRC command detects that the OMU
configuration data is inconsistent with the SCU/XPU configuration data and automatic
synchronization is enabled, the system will synchronize the configuration data from the OMU
to the SCU/XPU board. In this way, some data inconsistency problems can be resolved.
Implementation
By default, the automatic synchronization switch is turned on (default value: ON) for both
new networks and upgrade scenarios.
Issue 01 (2014-12-31)

Copyright Huawei
41
BSC6900 UMTS
Release Notes

V900R016C00SPC650

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
None

DTS: DTS2014121303252
Feature ID
None
3.2.2.19 Enhanced Support for Editing of Batch

Configuration Parameters on the Web LMT
Description
This feature allows users to edit the following batch configuration parameters on the Web
LMT to improve O&M efficiency:
Issue 01 (2014-12-31)

Copyright Huawei
42
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Capability of CN Node[k] in the CNNODE MO
Feature Supporting Mode of PS Domain, Length of PS NRI in bits, and NullNRI

VALUE in the OPERATORCFGPARA MO
Implementation
This feature allows users to edit the preceding parameters when using the batch configuration
function on the Web LMT. After importing configuration scripts, users can click the Edit
button to edit the preceding parameters.

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
None

DTS: DTS2014111706009
Issue 01 (2014-12-31)

Copyright Huawei
43
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Feature ID
None
3.2.2.20 Fan Box Noise Rectification at a High Fan Speed

Description
When the fan speed is high, the speed of fans in few fan boxes is unstable without affecting
services. This feature optimizes the fan speed precision controlled by software to prevent
unstable noise and fan speed in the preceding scenario.
Implementation
The fan speed adjustment precision is optimized. When the fan speed is high, the step in
which the fan speed is adjusted is decreased. This optimization helps ensure that the fan speed
is adjusted stably.

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
None
Issue 01 (2014-12-31)

Copyright Huawei
44
BSC6900 UMTS
Release Notes

V900R016C00SPC650

DTS: DTS2014121400421
Feature ID
None
3.2.3 Deleted Features

None
3.3 Resolved Issues

3.3.1 Critical
3.3.1.1 The call drop rate increases when the satellite card
cannot properly trace GPS satellite signals.
Trouble
Ticket
Number
iCare: 3741437
Description
Condition: The satellite card cannot properly trace GPS satellite signals.
DTS: DTS2014111110358
Symptom: The call drop rate increases.

Impact: Some KPIs deteriorate.
Severity
Critical
Root Cause
When the number of messages sent by the satellite card increases

because of external GPS signal deterioration, communication congestion
will occur. In this situation, the time information in the GCK board is
frequently adjusted because time-related messages sent by the satellite
card cannot be processed in a timely manner. As a result, the ongoing
call is interrupted.
Solution
Now, the time information in the GCK board is not adjusted based on the
messages sent by the satellite card.
Solution
Impact
The call drop rate decreases and service setup success rate increases in
the preceding scenario.
Test Case
CASE_Commercial_PR_Regression_R016C00SPC650_501
3.3.2 Major
3.3.2.1 The value of Number of Received CREF in ALM-21522
Low SCCP Setup Success Rate is incorrect.
Trouble
Issue 01 (2014-12-31)
iCare: 3146707
Copyright Huawei
45
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Ticket
Number
Description
DTS: DTS2014102302913
Condition: After sending a CR packet to the peer end, the SCCP module
of the base station controller receives another packet instead of a CC or
CREF packet from the peer end. When this happens, service setup fails
and ALM-21522 Low SCCP Setup Success Rate is reported.
Symptom: The value of Number of Received CREF in ALM-21522
Low SCCP Setup Success Rate is incorrect, and therefore some nonCREF packets are incorrectly measured as CREF packets.
Impact: Maintenance on the base station controller is affected.
Severity
Major
Root Cause
The algorithm for calculating the value of Number of Received CREF

in ALM-21522 Low SCCP Setup Success Rate is incorrect, and
therefore some non-CREF packets are incorrectly measured as CREF
packets.
Solution
The algorithm has been modified so that only the number of CREF
packets received from the peer end is measured as the value of Number
of Received CREF.
Solution
Impact
None
Test Case
3.3.2.2 Configuration data on the OMU is different from that

on the SPU after the command RMV UEXT3GCELL, MOD
UCELLFREQUENCY, or RMV UNRELATION is consecutively
executed.
Trouble
Ticket
Number
DTS: DTS2014071405287
Description
Condition: Adjacent RNC cells whose AP Cell ID is TRUE are

configured as neighboring cells of many cells.
Symptom: When the command RMV UEXT3GCELL, MOD
UCELLFREQUENCY, or RMV UNRELATION is consecutively
executed, some commands do not display command outputs within a
specified period.
Impact: Configuration data on the OMU is different from that on the
SPU.
Severity
Major
Root Cause
In the preceding scenario, a large amount of memory is requested on the

OMU, causing an exception on the OMU.
Solution
The OMU memory has been optimized to accommodate the memory
Issue 01 (2014-12-31)

Copyright Huawei
46
BSC6900 UMTS
Release Notes

V900R016C00SPC650
request of executing the command RMV UEXT3GCELL, MOD

UCELLFREQUENCY, or RMV UNRELATION.
Solution
Impact
None
Test Case
3.3.2.3 When an RNC sends inter-frequency measurement

control messages to UEs, some UEs experience call drops.
Trouble
Ticket
Number
iCare: 3477178
Descripti
on
Condition:
DTS: DTS2014111402837
1. CMP_UU_ADJACENT_FREQ_CM_SWITCH is turned on,

indicating that the RNC has enabled the inter-frequency measurement
on neighboring frequencies without starting the compressed mode.
2. 2. The RNC sends a UE an inter-frequency measurement control
message carrying the IE "AdjacentFrequencyIndex".
Symptom: The UE does not respond, and the RNC releases the RRC
connection.
Impact: The UE experiences a call drop. The call drop rate increases,
adversely affecting user experience.
Severity
Major
Root
Cause
In this scenario, some UEs have compatibility issues in processing the IE

"AdjacentFrequencyIndex".
Solution
Solution 1:
RESERVED_SWITCH_7_BIT16 under the RsvSwitch7 parameter in the
SET UALGORSVPARA command controls whether the inter-frequency
measurement control message carries the IE "AdjacentFrequencyIndex".
When this solution is enabled (set to 1), the inter-frequency measurement
control message carries the IE "AdjacentFrequencyIndex". When this
solution is disabled (set to 0), the inter-frequency measurement control
message does not carry the IE "AdjacentFrequencyIndex". By default, this
solution is enabled (default value: 1) for both new networks and upgrade
scenarios.
SET UALGORSVPARA:RsvSwitch7=RESERVED_SWITCH_7_BIT161;
Solution 2:
RESERVED_SWITCH_BIT24 under the RsvSwitch parameter in the
ADD UIMEITAC command controls whether special UEs are prohibited
Issue 01 (2014-12-31)

Copyright Huawei
47
BSC6900 UMTS
Release Notes

V900R016C00SPC650
from performing the inter-frequency measurement on the neighboring

frequencies or neighboring frequency bands without starting the
compressed mode. When this solution is enabled (set to 1), special UEs are
prohibited from performing this measurement without starting the
compressed mode. When this solution is disabled (set to 0), special UEs are
allowed to perform this measurement without starting the compressed
mode. By default, this solution is disabled (default value: 0) for both new
networks and upgrade scenarios.
ADD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=xxx,
Description="xxx", RsvSwitch= RESERVED_SWITCH_BIT24-1;
Solution
Impact
The call drop rate decreases.
Test Case
ID
3.3.2.4 The number of transmitted HS-DSCH Capacity

Request messages is not controlled when UEs in the
CELL_DCH state have no HSDPA service data to transmit
within a certain period of time.
Trouble
Ticket
Number
iCare: 3452710
Descriptio
n
Condition: All of the following conditions apply:
DTS: DTS2014092604683
A cell supports HSDPA services.
HSDPA services have been established on UEs in the cell.
The RNC frequently receives HS-DSCH Capacity Allocation messages

from the NodeB, even if UEs in the CELL_DCH state have no
HSDPA service data to transmit within a certain period of time.
Symptom: The RNC sends the NodeB a large number of HS-DSCH

Capacity Request messages.
Impact: Too many HS-DSCH Capacity Request messages increase the
signaling loads on the NodeB.
Severity
Major
Root Cause
In the preceding scenario, the RNC sends the NodeB an HS-DSCH

Capacity Request message each time the RNC receives an HS-DSCH
Capacity Allocation message from the NodeB.
Solution
The RNC now sends the NodeB a maximum of four consecutive HSDSCH Capacity Request messages.
RsvdSwitch1_Bit32 under the RsvdSwitch1 parameter in the SET
UDPUCFGDATA command controls whether to enable this solution.
By default, this solution is disabled (default value: 0) for both new
Issue 01 (2014-12-31)

Copyright Huawei
48
BSC6900 UMTS
Release Notes

V900R016C00SPC650
When this solution is enabled, the RNC sends the NodeB a maximum of
four consecutive HS-DSCH Capacity Request messages.
Solution
Impact
The number of HS-DSCH Capacity Request messages received at the

NodeB decreases when UEs in the CELL_DCH state have no HSDPA
service data to transmit within a certain period of time, reducing the
signaling loads on the NodeB.
Test Case
3.3.2.5 Logs are not recorded if the RNC receives a

SECURITY MODE COMMAND message during other
procedures.
Trouble
Ticket
Number
iCare: 3186596
Descriptio
n
Condition: The RNC receives a SECURITY MODE COMMAND

message from the CN while handling a soft handover through a single
signaling procedure, signaling radio bearer (SRB) resetting, or a cell
update.
DTS: DTS2014110405174
Symptom: On the CN side, the value of the counter measuring the

number of security mode complete timeout occasions increases.
Impact: Logs about the SECURITY MODE COMMAND message are
not recorded on the RNC side.
Severity
Major
Root Cause
While handling other procedures for a UE, the RNC receives a

SECURITY MODE COMMAND message from the CN and buffers it.
Before releasing the UE, the RNC does not handle the message before
the security mode timer on the CN side times out. In addition, logs about
the buffered message are not recorded on the RNC side.
This issue occurs in the following scenarios:
Scenario 1: While handling a soft handover through a single signaling
procedure, the RNC receives a SECURITY MODE COMMAND
message from the CN and buffers it. In the meantime, the RNC receives
a Cell Updates Due to SRB RLC Unrecoverable Error request from the
UE and therefore starts link re-establishment. Once the link is reestablished, the RNC sends the UE an Active Set Update message. While
the RNC is waiting for an acknowledgement from the UE, the CN sends
the RNC an IU RELEASE COMMAND message due to security mode
timeout.
Scenario 2: While handling a cell update procedure, the RNC receives a
SECURITY MODE COMMAND message from the CN and buffers it.
Issue 01 (2014-12-31)

Copyright Huawei
49
BSC6900 UMTS
Release Notes

V900R016C00SPC650
The cell update fails, and the RNC releases the UE. However, the RNC
does not handle the buffered SECURITY MODE COMMAND message
before releasing the UE.
Solution
Enable logging for all the following actions:
The RNC buffers a SECURITY MODE COMMAND message.
The RNC fails to take a SECURITY MODE COMMAND message out

of the buffer queue.
The RNC takes messages out of the buffer queue, excluding the
SECURITY MODE COMMAND message.
The RNC does not handle the buffered SECURITY MODE

COMMAND message before releasing a UE.
Solution
Impact
In the preceding scenarios, logs about the SECURITY MODE

COMMAND message are recorded on the RNC side.
Test Case
3.3.2.6 Downlink data transmission for PS services is

interrupted.
Trouble
Ticket
Number
iCare: 3315404
Descriptio
n
DTS: DTS2014110405556
A UE processing PS services starts downlink data transmission.
The RLC entity on the RNC side receives a STATUS PDU from the
UE, which consists of two BITMAP SUFIs and one ACK SUFI.
SUFI is short for super field.
The first sequence number (FSN) in the first BITMAP SUFI is less
than the value of a state variable VT(A) in the RLC entity on the
RNC side. In addition, the first BITMAP SUFI indicates that loss of
PDUs has occurred and the RLC entity needs to retransmit the lost
PDUs.
The second BITMAP SUFI indicates that no PDU has been lost.
The last sequence number (LSN) carried in the ACK SUFI is greater
than the FSN carried in the first BITMAP SUFI.
Symptom: If all of the preceding conditions apply, downlink data

transmission for PS services is interrupted.
Impact: User experience is adversely affected.
Severity
Major
Root Cause
According to 3GPP TS 25.322, VT(A) will be updated to the value of the

FSN in the first BITMAP SUFI if the RLC entity receives the preceding
STATUS PDU from the UE. However, the RNC falsely updates VT(A)
to the value of the LSN in the ACK SUFI.
The UE continues sending the preceding STATUS PDU, but the RNC
does not retransmit the lost PDUs because VT(A) has been falsely
Issue 01 (2014-12-31)

Copyright Huawei
50
BSC6900 UMTS
Release Notes

V900R016C00SPC650
updated. In addition, the RNC cannot update VT(A) any more. As a

result, downlink data transmission stops when the RLC transmission
window is full.
Solution
In the preceding scenario, the RNC now updates VT(A) to the value of
the FSN in the first BITMAP SUFI.
Solution
Impact
None
Test Case
3.3.2.7 Services fail to be set up if an RB setup procedure

during an F2D state transition overlaps with a cell update
procedure.
Trouble
Ticket
Number
DTS: DTS2014102600351
Description
Condition: After an RNC sends a UE the RADIO BEARER SETUP

message indicating an F2D state transition and before the RNC receives
the RADIO BEARER SETUP COMPLETE message, one of the
following situations occurs:
Situation 1: The RNC receives a CELL UPDATE message with the

cause value "cell reselection" from the UE in the original cell.
Situation 2: The RNC receives a CELL UPDATE with the cause value
"re-entered service area">RLC unrecoverable error">
NOTE
An F2D state transition refers to a transition from the CELL_FACH state to the
CELL_DCH state for a UE.
Symptom: Services fail to be set up.

Impact: The CS RAB setup success rate and PS RAB setup success rate
decrease.
Severity
Major
Root Cause
The RNC does not support service setup when the preceding two
procedures overlap.
Solution
RESERVED_SWITCH_12_BIT9 under the RsvSwitch12 parameter in

the SET UALGORSVPARA command controls whether to enable this
solution. By default, this solution is disabled (default value: 0) for both
new networks and upgrade scenarios. When this solution is enabled, the
RNC first processes the CELL UPDATE message and then initiates
service setup if the preceding two procedures overlap. When this
solution is disabled, services fail to be set up in the preceding scenarios.
SET UALGORSVPARA:
RsvSwitch12=RESERVED_SWITCH_12_BIT9-1;
Issue 01 (2014-12-31)

Copyright Huawei
51
BSC6900 UMTS
Release Notes

V900R016C00SPC650
SET UALGORSVPARA:
NOTE
Run one or both of the following commands to set the specified switches to 1
before enabling this solution:
SET URRCTRLSWITCH:
OptimizationSwitch= AMR_F2D_OVERLAP_CELLUPT_SWITCH-1;
SET URRCTRLSWITCH:
PROCESSSWITCH4= PS_F2D_OVERLAP_CELLUPT_SWITCH-1;
Solution
Impact
None
Test Case
3.3.2.8 ALM-22501 DSP CPU Overload is suppressed.

Trouble
Ticket
Number
iCare: 3315517
Description
Condition: A DSP is working properly but the CPU load of the DSP
exceeds the specified overload threshold.
DTS: DTS2014110405099
Symptom: The RNC does not report ALM-22501 DSP CPU Overload.
Impact: Operators cannot be alerted to user-plane resource insufficiency
by observing whether ALM-22501 DSP CPU Overload is reported.
Severity
Major
Root Cause
ALM-22501 DSP CPU Overload has been suppressed on the RNC and
cannot be triggered.
This alarm is suppressed due to the following causes:
Solution
This alarm is triggered based on CPU overload of individual DSPs.

However, DSPs share their resources on an RNC. Therefore, CPU
overload on one or several individual DSPs equal to or above the
specified overload threshold does not represent DSP resource
insufficiency on the user plane.
CPU overload on an individual DSP is strongly attributable to

behaviors of UEs served by the DSP. This alarm risks being
repeatedly reported and cleared.
ALM-22501 DSP CPU Overload will be disused in BSC6900

V900R017C10. ALM-22305 Resource overload on the user plane is now
used so that DSP insufficiency user plane resource can be reported only
when resources on all DSPs as a whole become insufficient.
The following are the report and clear mechanisms for the ALM-22305:
This alarm is reported when the average CPU usage of all DSPs
managed by the MPU exceeds the overload threshold. By running the
LST UALMTHD command to query the value of the "User Plane
threshold for generating alarm" parameter. This alarm is cleared when
the average CPU usage of the DSPs is less than the alarm clearance
Issue 01 (2014-12-31)

Copyright Huawei
52
BSC6900 UMTS
Release Notes

V900R016C00SPC650
threshold. By running run the LST UALMTHD command to query the

value of the "User Plane threshold for clearing alarm" parameter.
For the BSC6900, user-plane resources include the DSP resources
provided only by the DPUb and DPUe boards. And other details, see the
following document:
BSC6900 UMTS V900R016ENGC00SPC650 Alarm List.xls
BSC6900 GU V900R016ENGC00SPC650 Alarm List.xls
Solution
Impact
None
Test Case
3.3.2.9 A large number of UEs unexpectedly initiate

registration requests and the RNC control-plane CPU usage
suddenly reaches an high value.
Trouble
Ticket
Number
iCare: 3095045
Description
Condition: A large number of UEs unexpectedly initiate registration

requests.
DTS: DTS2014111403187
Symptom: Values returned by VS.XPU.CPULOAD.MAX drastically

increase.
Impact: The RNC control-plane CPU usage suddenly reaches an high
value.
Severity
Major
Root Cause
In this scenario, the RNC does not deliver a forwarding speed fast
enough for load sharing.
Solution
The RNC now has an accelerated forwarding speed for control-plane

load sharing.
the SET UALGORSVPARAPHY command controls whether to enable
this solution. By default, this solution is disabled (default value: 0) for
SET UALGORSVPARAPHY:
NOTE
RESERVED_SWITCH_0_BIT10 is an advanced parameter. Set this parameter
only with assistance from Huawei technical support personnel.
Solution
Issue 01 (2014-12-31)
Values returned by VS.XPU.CPULOAD.MAX decrease.

Copyright Huawei
53
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact
Test Case
3.3.2.10 After the MOD UCELLID command is executed,

performance objects are repeated.
Trouble
Ticket
Number
iCare: 3733888
Description
Condition:
DTS: DTS2014111406096
1. The following command is executed to turn on the switch specifying

whether to reserve the cell measurement set after a cell is deactivated:
SET UNBMPARA:
PerfEnhanceSwitch=PERFENH_DEACELL_PFMRSV_SWITCH-1;
2. The following operations are performed:
The MOD UCELLID command is executed to change the ID of cell

A to that of cell C, and the ID of cell B to that of cell A.
The ACT UCELL command is executed to activate the new cell C

and cell A.
Symptom: Performance objects of cell A are repeated on the U2000.

Impact: The northbound report cannot be generated on the U2000.
Severity
Major
Root Cause
In this scenario, the performance objects of the original cell A and cell B
are out of control and not removed. Then, after the ACT UCELL
command is executed to activate the new cell C and cell A, performance
objects are added to the new cell C and cell A. As a result, the new cell A
has two performance objects.
Solution
In this scenario, the performance objects of the original cell A and cell B
are now deleted, and after the ACT UCELL command is executed to
activate the new cell C and cell A, performance objects are not repeated
in the new cell A.
Solution
Impact
None
Test Case
ID
Issue 01 (2014-12-31)

Copyright Huawei
54
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.2.11 UEs in a LAC area cannot be paged after the cell

LAC information has been modified using the CME.
Trouble
Ticket
Number
iCare: 3808444
Description
Condition: The location area code (LAC) information of a cell is

modified using the CME.
DTS: DTS2014112800088
Symptom: The LAC information of the cell can be correctly updated in

the system information, but UEs in the LAC area cannot receive paging
messages.
Impact: UEs in the LAC area cannot be paged.
Severity
Major
Root Cause
Due to software defects, the cell LAC modified using the CME cannot
be modified on the RNC. As a result, only the LAC in the system
information is updated and the RNC cannot send paging messages to
UEs in the new LAC area.
Solution
Software defects have been rectified in the RNC.
Solution
Impact
None
Test Case
ID
3.3.2.12 Changing the GTP-U local IP address at the

transport layer causes service releases after the PS core
network modifies the service type.
Trouble
Ticket
Number
iCare: 3788216
Description
Condition:
DTS: DTS2014120603249
When Iu-PS adjacent nodes work in transmission resource pool mode, a

transmission resource pool on the RNC contains more than one source IP
address; when Iu-PS adjacent nodes do not work in transmission
resource pool mode, the RNC configures several IP paths to the user
plane of the PS core network, and these IP paths correspond to more
than one source IP address.
Symptom: After the PS service is set up, the PS core network initiates a
normal release of services in either of the following scenarios:
Issue 01 (2014-12-31)
Scenario 1: The PS core network sends the RNC a RAB

ASSIGNMENT REQUEST message and initiates a RAB
modification procedure to change the PS service type (indicated by
the information element "Traffic Class"). After the RAB modification
procedure is completed, the RNC responds to the core network with a

Copyright Huawei
55
BSC6900 UMTS
Release Notes

V900R016C00SPC650
RAB ASSIGNMENT RESPONSE message, and then the core

network immediately initiates a normal release of services.
Scenario 2: The PS core network initiates a RAB modification

procedure to change the PS service type, and the RNC initiates a
DCCC, hard handover, or cell update procedure. After the RNC sends
an Error Indication message to the PS core network over the GTP-U
layer, the core network immediately initiates a normal release of
services.
Impact: Downlink throughput of PS services decreases, and the value

returned by the VS.GTPU.ErrInd.Tx counter increases.
Severity
Major
Root Cause
For scenario 1:
The RNC has several local IP addresses at the transport layer and
changes the GTP-U local IP address at the transport layer, and the RAB
ASSIGNMENT RESPONSE message carries a new GTP-U local IP
address (indicated by the information element "Transport Layer
Address"). However, Huawei SGSN9810 V900R010C02 and earlier do
not support a change in the GTP-U local IP address on the RNC, and
therefore the core network initiates a normal release of services.
For scenario 2:
The RNC has several local IP addresses at the transport layer and
changes the GTP-U local IP address at the transport layer. However, the
RNC cannot notify the core network of the new GTP-U local IP address
by using messages exchanged in the DCCC, hard handover, or cell
update procedure, and the core network continues to send GTP-U data to
the original IP address. After the RNC sends an Error Indication message
to the core network over the GTP-U layer, the core network immediately
initiates a normal release of services.
NOTE
1. Scenario 1 is applicable only to the case where Huawei RNC connects to
Huawei SGSN9810 V900R010C02 or earlier.
2. Scenario 2 is applicable to the situation where Huawei RNC connects to any
PS core network node.
Solution
For scenario 1:
RESERVED_SWITCH_12_BIT14 under the RsvSwitch12 parameter
in the SET UALGORSVPARA command controls whether the RNC is
disallowed to change the GTP-U local IP address at the transport layer
after the PS core network initiates a RAB modification procedure.
networks and upgrade scenarios. When this solution is enabled, the RNC
is disallowed to change the GTP-U local IP address at the transport layer
after the PS core network initiates a RAB modification procedure. When
this solution is disabled, the RNC can change the GTP-U local IP
address at the transport layer.
SET UALGORSVPARA:
RsvSwitch12= RESERVED_SWITCH_12_BIT14-1;
Issue 01 (2014-12-31)

Copyright Huawei
56
BSC6900 UMTS
Release Notes

V900R016C00SPC650
SET UALGORSVPARA:
For scenario 2:
in the SET UALGORSVPARA command controls whether the RNC is
disallowed to change GTP-U local IP address at the transport layer while
initiating a DCCC, hard handover, or cell update procedure.
When this solution is enabled, the RNC is disallowed to change the
GTP-U local IP address at the transport layer while initiating a DCCC,
hard handover, or cell update procedure.
When this solution is disabled, the RNC can change the GTP-U local IP
address at the transport layer.
SET UALGORSVPARA:
SET UALGORSVPARA:
For both scenario 1 and scenario 2:SW29 under the RSVDSW1
parameter in the SET TNRSVDPARA command controls whether the
RNC preferentially selects the original local IP address at the transport
layer.
When this solution is enabled, the RNC preferentially selects the original
local IP address at the transport layer.
When this solution is disabled, the RNC selects a suitable one from all
local IP addresses at the transport layer.
NOTE
1. In scenario 1, both RESERVED_SWITCH_12_BIT14 and SW29 must be
set to 1.
2. In scenario 2, both RESERVED_SWITCH_12_BIT13 and SW29 must be
set to 1.
Solution
Impact
For scenario 1:
The RNC is disallowed to change the GTP-U local IP address at the
transport layer. If an exception occurs, for example, original transport
resources are congested, the number of failed attempts to apply for
transport resources increases. Specifically,
the value returned by the VS.RAB.FailModPS.TNL counter increases.
For scenario 2:
Issue 01 (2014-12-31)

Copyright Huawei
57
BSC6900 UMTS
Release Notes

V900R016C00SPC650
The RNC is disallowed to change the GTP-U local IP address at the

transport layer. If an exception occurs, for example, original transport
resources are congested, the number of failed attempts to apply for
transport resources increases. Specifically,
values returned by the following counters decrease:
VS.HHO.AttIntraFreqOut.InterNodeBIntraRNC
VS.HHO.AttIntraFreqOut.InterRNC
VS.HHO.AttIntraFreqOut.IntraNodeB
VS.HHO.AttIntraFreq.RNC
VS.HHO.AttInterFreq.RNC
VS.HHO.AttInterFreqOut
VS.HHO.AttInterFreq.RNC
VS.HSUPA.D2E.Att
VS.HSDPA.D2H.Att
VS.HHO.AttInterFreqOut.PS
VS.HHO.AttInterFreqOut.CS
VS.CellUpdt.Confirm
Values returned by the following KPIs increase:
Test Case
ID
PS Call Drop Rate in CS+PS Combined Services
CS Call Drop Rate in CS+PS Combined Services
PS Call Drop Ratio
PS R99 Call Drop Ratio
PS BE Call Drop Ratio
3.3.2.13 The RNC fails to initiate a channel fallback in the

event of service setup or reconfiguration failures in some
scenarios.
Trouble
Ticket
Number
DTS: DTS2014082607062
Description
Condition:
The ResCongDrdOptSwitch parameter is set to ON. This parameter

determines whether to enable DRD optimization after resource
congestion occurs.
The CPC parameters are incorrectly configured on the RNC level and
the cell level.
Symptom:
The CPC feature configuration fails during service setup, leading to
service setup failures.
Issue 01 (2014-12-31)

Copyright Huawei
58
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact:
The service setup success rate decreases.
Severity
Major
Root Cause
The RNC does not trigger a channel fallback but terminates the service
setup process after the CPC configuration fails.
Solution
The RNC now triggers a channel fallback to reestablish or reconfigure

services if a service setup or reconfiguration fails due to incorrect
parameter configurations.
Solution
Impact
None
Test Case
ID
3.3.2.14 The SPU on a Huawei DRNC restarts if messages

received from a non-Huawei SRNC over the Iur interface
carry protocol-incompliant IEs.
Trouble
Ticket
Number
iCare: 3883218
Description
Condition: A Huawei RNC serves as the DRNC, and an RNC provided

by another vendor serves as the SRNC. The SRNC sends a signaling
message over the Iur interface, and this message carries an information
element (IE) that is not defined in 3GPP protocols.
DTS: DTS2014121301622, DTS2014121604523
Symptom: Inter-RNC handovers initiated by the SRNC fail, and the

SPU on the Huawei DRNC restarts.
Impact: The value returned by the VS.SHO.AttRLSetupIur.Rx counter
decreases, the value returned by the VS.SHO.ErrIndIur.Tx counter
increases, and the SPU on the Huawei DRNC restarts.
Severity
Major
Root Cause
The DRNC records IEs that are carried in received signaling messages
but not defined in 3GPP protocols. If there are more than 10 such IEs,
the DRNC triggers self-healing for its memory, causing the SPU to
restart.
Solution
Solution 1:
The DRNC now records only the first 10 IEs that are carried in signaling
messages but not defined in 3GPP protocols, ignoring such IEs received
later on.
Solution 2:
the SET UALGORSVPARAPHY command controls whether the RNC
ignores IEs that are carried in signaling messages but not defined in
3GPP protocols.
Issue 01 (2014-12-31)

Copyright Huawei
59
BSC6900 UMTS
Release Notes

V900R016C00SPC650

ignores IEs that are carried in signaling messages but not defined in
3GPP protocols and continues to process these signaling messages.
When this solution is disabled, the RNC does not ignore those IEs but
instead, discards these signaling messages.
Solution
Impact
The SPU will not restart in this scenario.
Test Case
ID
When solution 2 is enabled, the value returned by

VS.SHO.AttRLSetupIur.Rx increases and the value returned by
VS.SHO.ErrIndIur.Tx decreases.
3.3.2.15 The RL reconfiguration fails when an ATM/IP dual

stack is applied over the Iub interface.
Trouble
Ticket
Number
DTS: DTS2014120802574
Description
Condition: The ATM/IP dual stack is applied over the Iu-b interface, and
both ATM and IP transmission resources are ready for the radio link
(RL).
Symptom: The RNC fails to send the RL reconfiguration message.
Impact: The RL reconfiguration fails, causing users to be abnormally
released and increasing the call drop rate.
Severity
Major
Root Cause
If the ATM transmission is used, the RL reconfiguration message does

not need to carry transport-layer information. However, in the preceding
scenario, the RNC sends the RL reconfiguration message carrying
transport-layer information in ATM transmission mode.
Solution
The RNC now sends the RL reconfiguration message without carrying

transport-layer information if the ATM transmission is used.
in the SET UALGORSVPARA command controls whether to enable
SET UALGORSVPARA:
Issue 01 (2014-12-31)

Copyright Huawei
60
BSC6900 UMTS
Release Notes

V900R016C00SPC650
SET UALGORSVPARA:
Solution
Impact
None
Test Case
ID
3.3.2.16 N7DPC specified by DPX is inconsistent with that

specified by NI, SPC/SPCDNF, and DPC/DPCDNF in the
configuration of the UCNNODE or UNRNC MO.
Trouble
Ticket
Number
iCare: 3608460
Description
Condition: In the configuration of the UCNNODE or UNRNC MO,

DPX, NI, SPC/SPCDNF, and DPC/DPCDNF are set, and N7DPC
specified by DPX is inconsistent with that specified by NI,
SPC/SPCDNF, and DPC/DPCDNF.
DTS: DTS2014120909927
Symptom: Services fail or handovers over the Iur interface fail.

Impact: Service KPIs (VS.CSLoad.Erlang.Equiv.RNC,
VS.R99PSLoad.DLThruput.RNC, and
VS.HSDPAPSLoad.DLThruput.RNC) deteriorate.
Severity
Major
Root Cause
In the configuration of the UCNNODE or UNRNC MO, the system

does not perform consistency check if DPX, NI, SPC/SPCDNF, and
DPC/DPCDNF are set.
When N7DPC specified by DPX is inconsistent with that specified by
NI, SPC/SPCDNF, and DPC/DPCDNF, the system uses incorrect
settings of NI, SPC/SPCDNF, and DPC/DPCDNF. As a result, services
become unavailable or handovers over the Iur interface fail.
Solution
Configuration restrictions or prompt messages are now added to the

ADD UCNNOD, MOD UCNNODE, ADD UNRNC, MOD UNRNC
commands, which ensures that N7DPC specified by DPX and that
specified by NI, SPC/SPCDNF, and DPC/DPCDNF are effective and
consistent.
Consistency and validity precheck is now added for DPX, NI,
SPC/SPCDNF, and DPC/DPCDNF during the upgrade, which verifies
that N7DPC specified by DPX and that specified by NI, SPC/SPCDNF,
and DPC/DPCDNF are effective and consistent before the upgrade.
If precheck fails, settings of DPX, NI, SPC/SPCDNF, and
DPC/DPCDNF are corrected.
Solution
Issue 01 (2014-12-31)
None
Copyright Huawei
61
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact
Test Case
ID
3.3.2.17 Configuration commands cannot be delivered to a

board because the board is mistakenly inhibited.
Trouble
Ticket
Number
iCare: 3539264
Descriptio
n
Condition:
DTS: DTS2014110302077
1. Before the ADD BRD command is executed to add a board, an SPU

board is installed in the specified slot.
2. The SCU board has reported ALM-20237 Incorrect MAC Entries for
Backplane Ports of the GE Switching Board of the SPU board.
Symptom: After the ADD BRD command is executed, the newly added
board is properly loaded, and the device panel shows that the board is
normal. Configuration commands are then successfully executed for the
board, but configuration data fails to be delivered to the board.
Impact: Configuration data that is dynamically modified cannot take
effect on the newly added board. As a result, services are impaired.
Severity
Major
Root
Cause
In the preceding scenario, the SCU board inhibits the board that has not
been configured and sets the board status to "inhibited". Due to a software
defect, when the ADD BRD command is executed to add the board, the
SCU board uninhibits the board, but the SCU board does not update the
board status to "uninhibited". After the newly added board starts, the SCU
board reports the board status "inhibited" to the OMU. As a result,
configuration commands subsequently executed are not delivered to the
newly added board.
Solution
The SCU board now correctly updates the board status to "uninhibited"
when a board is newly added in the preceding scenario. This solution
ensures that the SCU board reports the correct board status to the OMU.
Solution
Impact
None
Test Case
3.3.2.18 Vulnerability CVE-2014-3511 exists.

Trouble
Ticket
Number
DTS: DTS2014091102992
Description
Condition: The OMU functions as the SSL/TLS server and supports
Issue 01 (2014-12-31)
Vulnerability ID: HWPSIRT-2014-0816

Copyright Huawei
62
BSC6900 UMTS
Release Notes

V900R016C00SPC650
multiple SSL/TLS protocol versions. The handshake message received

by the OMU is maliciously tampered by attackers. As a result, the OMU
cannot obtain the SSL/TLS protocol versions from the handshake
message.
Symptom: After receiving the preceding handshake message, the OMU
uses the latest SSL/TLS protocol versions it supports to negotiate with
the client to establish connections.
Impact: The OMU does not reject the malicious handshake message,
which brings security risks.
Severity
Major
Root Cause
When this vulnerability is used, the SSL/TLS component used by the

OMU chooses the latest SSL/TLS protocol versions to negotiate with
the client to establish connections.
Solution
The SSL/TLS component used by the OMU has been upgraded to a

version in which this vulnerability is rectified.
Solution
Impact
If this vulnerability is maliciously used, the SSL/TLS negotiation

between the OMU and the client fails and new connections between
them cannot be established, thereby preventing the network element
(NE) against attacks.
Test Case

Trouble
Ticket
Number
DTS:DTS2014101702933
Description
Condition: The server and the client can communicate with each other
in compliance with SSL V3.0.
Symptom: By using this vulnerability, attackers can control the

handshake message between the server and the client and force the
server and client to use SSL V3.0 so as to intercept sensitive
information.
Impact: If this vulnerability is maliciously used, sensitive information
transmitted on the network may be disclosed.
Severity
Major
Root Cause
Vulnerability CVE-2014-3566 exists in SSL V3.0. Users cannot

configure a more secure TLS version for the OMU.
Solution
The SET SSLCONF command can now be used to set TLS/SSL

versions. If the server and client support more secure TLS versions,
you are advised to configure such TLS versions for the OMU by
running this command. By doing so, the security risks in SSL V3.0 can
be avoided.
Solution
Impact
1. At a site where the base station controller is newly added, before

adding a network element (NE) on the U2000, check whether this
Issue 01 (2014-12-31)

Copyright Huawei
63
BSC6900 UMTS
Release Notes

V900R016C00SPC650
vulnerability has been rectified on the U2000 by referring to the

corresponding U2000 Release Notes. If this vulnerability has been
rectified, check whether the OMU supports SSL V3.0 (the OMU
supports SSL V3.0 by default). If the OMU does not support SSL
V3.0, the connection between the U2000 and the OMU cannot be
established. After the NE is added and the connection between the
U2000 and the OMU is established, disable SSL V3.0 from the
OMU for security hardening.
2. The preceding problem does not occur at a site where the base
station controller is upgraded. In this scenario, disable SSL V3.0
from the OMU for security hardening.
Test Case
3.3.2.20 The XPU board may abnormally report counters in

GU mode.
Trouble
Ticket
Number
iCare: 2792615/3567585
Descriptio
n
Condition:
DTS: DTS2014101004813
1. This problem occurs only in GU mode but not in GSM-only or

UMTS-only mode.
2. The base station controller is configured with at least 20 pairs of XPU
boards, SPU boards, or some combination thereof.
Symptom: When an XPU board is added or an XPU board is added or
removed multiple times, the XPU board may abnormally report counters.
Impact: The values of counters reported by the XPU board are incorrect.
It is inconvenient for users to monitor network performance in real time.
Severity
Major
Root Cause
When an XPU board is added, the BSC allocates an ID to the XPU

board. Due to a defect in the ID allocation algorithm, no ID may be
allocated to an XPU board even when the number of configured XPU
boards is within the specified upper limit. When this occurs, the XPU
board abnormally reports counters.
Solution
The preceding defect has been rectified to ensure that the BSC
successfully allocates an ID to each XPU board. This way, the XPU
board properly reports counters.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
64
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.2.21 Service setup fails after a BSC6900 is upgraded

from V900R013C00SPC586 to V900R015C00SPH565.
Trouble
Ticket
Number
iCare: 3823534
Descripti
on
Condition: A BSC6900 is upgraded from V900R013C00SPC586 to

V900R015C00SPH565.
DTS: DTS2014121101488
Symptom: Service setup fails because an invalid activity factor is used.

Impact: CS and PS services using the invalid activity factor fail to access
the network.
Severity
Major
Root
Cause
Before an upgrade, the value of the activity factor used by services in the
data table is 255. After the upgrade, the value remains unchanged and the
BSC performs validity check on the activity factor used by services. If the
activity factor is not within the range of 0 to 100, service will fail to access
the network.
Solution
A pre-upgrade check item for the activity factor has been added to the
BSC6900 upgrade from V900R014C00 and earlier (excluding
V900R011C00) to V900R016C00SPC650. If the configuration data before
the upgrade contains an invalid activity factor, the upgrade will fail and a
message is displayed, prompting users to run the MOD TRMFACTOR
command to change the values of all invalid activator factors to 100.
Solution
Impact
None
Test Case
3.3.2.22 An interface board unexpectedly resets because of

logical remote loopback detection failures.
Trouble
Ticket
Number
iCare: 3828383
Descriptio
n
Condition: An FG2c/GOUc board carries services and calls meeting

board specifications are made for a long period of time.
DTS: DTS2014072104921
Symptom: The board unexpectedly resets because the logical remote

loopback detection fails.
Impact: Services on the board are interrupted and calls fail.
Severity
Major
Root
Cause
When calls meeting board specifications are made for a long period of
time, board resources become insufficient, and therefore packets for
logical remote loopback detection are discarded. As a result, the detection
fails and the board resets.
Issue 01 (2014-12-31)

Copyright Huawei
65
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Solution
Logical remote loopback detection has been shielded in the preceding

scenario to ensure that the board is running properly.
Solution
Impact
None
Test Case
ID
3.3.2.23 Logical remote loopback detection on an interface

board becomes unavailable.
Trouble
Ticket
Number
DTS: DTS2014120201007
Descriptio
n
Condition: An IP logical port is added to an GOUe/FG2c/GOUc board

and carries services.
Symptom: Logical remote loopback detection on the board becomes
unavailable.
Impact: When the board FPGA chip becomes faulty, the faulty board
cannot be recovered. As a result, the service assignment success rate
decreases.
Severity
Major
Root
Cause
The implementation of logical remote loopback detection does not

consider the preceding scenario. As a result, this detection becomes
unavailable in the preceding scenario.
Solution
Logical remote loopback detection has been implemented in the

preceding scenario.
Solution
Impact
The board CPU usage increases by up to 1%.
Test Case
ID
3.3.2.24 The level-1 clock source becomes unavailable after

the clock cable to the GCGa/GCUa board panel is removed
and installed.
Trouble
Ticket
Number
iCare: 3685842
Descriptio
n
Condition: The line clock rate is 1.544 Mbit/s and users remove and
then insert the clock cable to the GCGa/GCUa board panel.
DTS: DTS2014112708553
Symptom: The base station controller reports ALM-20205 System Clock

Issue 01 (2014-12-31)

Copyright Huawei
66
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Reference Source Unavailable.

Impact: The level-1 clock source becomes unavailable and line clock
signals cannot be extracted. In addition, ATM and TDM transmission
services are affected.
Severity
Major
Root Cause
Initial configuration of a 1.544 Mbit/s line clock has defects so that the
clock cannot be locked after the clock cable to the GCGa/GCUa board
panel is removed and installed. In this situation, the level-1 clock source
becomes unavailable and line clock signals cannot be extracted. As a
result, ATM and TDM transmission services are affected.
Solution
The defect in the clock initial configuration has been corrected to ensure
that the level-1 clock source is available in the preceding scenario.
Solution
Impact
None
Test Case
3.3.3 Minor
3.3.3.1 WPS UEs initiate preemption during soft handovers,
increasing the call drop rate.
Trouble
Ticket
Number
DTS: DTS2014092908128
Descripti
on
Condition: The WPS feature is activated by running the SET

UWPSALGO command with NbmWpsAlgorithmSwitch set to
ALGORITHM_ON.
Symptom: The call drop rate of common UEs increases.
Impact: User experience is adversely affected.
Severity
Minor
Root
Cause
If a WPS UE experiences an admission failure in a soft handover process,

the UE can initiate preemption. As a result, the number of preempted UEs
increases.
Solution
A switch now controls whether a WPS UE can initiate preemption in a soft

handover process.
SET UALGORSVPARA command controls whether to allow a WPS UE
to initiate preemption in a soft handover process. By default, this solution is
enabled (set to 1).
SET UALGORSVPARA: RsvSwitch7=
RESERVED_SWITCH_7_BIT15-1;
Issue 01 (2014-12-31)

Copyright Huawei
67
BSC6900 UMTS
Release Notes

V900R016C00SPC650

Solution
Impact
None
Test
Case ID
3.3.3.2 The information element "Support for UE assisted

GPS measurement validity in CELL_PCH and URA_PCH
states" contained in the POSITION INITIATION REQUEST
message is assigned an incorrect value.
Trouble
Ticket
Number
iCare: 3368537
Descripti
on
Condition:
DTS: DTS2014111309448
1. A UE sends the RNC an RRC CONNECTION SETUP COMPLETE

message, with the information element (IE) "Support for UP assisted
GPS measurement validity in CELL_PCH and URA_PCH states"
assigned the value TRUE.
2. The RNC sends the standalone SMLC (SAS) server a POSITION
INITIATION REQUEST message.
Symptom: The IE "Support for UE assisted GPS measurement validity in
CELL_PCH and URA_PCH states" contained in the POSITION
INITIATION REQUEST message is assigned the value FALSE.
Impact: The RNC does not set the value of the IE "Support for UE assisted
GPS measurement validity in CELL_PCH and URA_PCH states" in
compliant with 3GPP protocols.
Severity
Minor
Root
Cause
The RNC does not configure the IE "Support for UE assisted GPS
measurement validity in CELL_PCH and URA_PCH states"based on the
value of the IE "Support for UP assisted GPS measurement validity in
CELL_PCH and URA_PCH states" reported by the UE.
Solution
The RNC now configures the IE "Support for UE assisted GPS

measurement validity in CELL_PCH and URA_PCH states"based on the
value of the IE "Support for UP assisted GPS measurement validity in
CELL_PCH and URA_PCH states" reported by the UE.
Solution
Impact
None
Test
Case ID
Issue 01 (2014-12-31)

Copyright Huawei
68
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.3.3 Some alarms are incorrectly reported after the

master and backup RNCs of a logical RNC are switched over
when RNC in Pool Node Redundancy is enabled.
Trouble
Ticket
Number
DTS: DTS2014102902819
Descript
ion
Condition: When RNC in Pool Node Redundancy is enabled, the N7DPC

that does not belong to the logical RNC exists, and the master and backup
RNCs of a logical RNC are switched over.
Symptom: When a physical RNC works as the backup RNC after a
switchover, the following alarms for the N7DPC that does not belong to the
logical RNC are reported:
ALM-21553 M3UA Destination Entity Inaccessible
ALM-21552 M3UA Destination Entity Route Unavailable
ALM-21503 MTP3 DSP Inaccessible
ALM-21504 MTP3 Signaling Route Inaccessible
ALM-21521 SCCP Subsystem Prohibited
Impact: The preceding alarms are incorrectly reported and RNC

maintenance is affected.
Severity
Minor
Root
Cause
In the preceding scenario, all link sets of the logical RNC are deactivated
and alarms for the N7DPC that belongs to the logical RNC are suppressed.
However, the N7DPC that does not bind UNRNC/UNCNODE does not
belong to any logical RNC. Therefore, alarms for this N7DPC are
unsuppressed and reported incorrectly.
Solution
SW17 of Reserved Switch Parameter1 in the SET TNRSVDPARA

command specifies the policy for handling the N7DPC-related alarms after
the master and backup RNCs of a logical RNC are switched over. By
default, the OPC policy is used (default value: 0) for both new networks and
upgrade scenarios.
0: The OPC policy is used. Specifically, after the master and backup RNCs
of a logical RNC are switched over, all alarms for the N7DPC that
belongs to the OPC of the logical RNC are suppressed for the backup
RNC.
1: The DPC policy used. Specifically, after the master and backup RNCs
of a logical RNC are switched over, the alarms for the N7DPC that
belongs to the logical RNC are suppressed but the alarms for the N7DPC
that does not belong to the logical RNC are not suppressed for the
backup RNC.
NOTE
If SW17 of Reserved Switch Parameter1 is set to 0 and incorrect configurations of
UNRNC or UCNNODE that has the same NI and OPC exist in multiple logical RNCs,
signaling links for the OPC will be intermittently disconnected.
The following data configuration restriction has been imposed on the BSC6910 to
address this issue: The UNRNC or UCNNODE that has the same NI and OPC must be
configured in the same logical RNC. Otherwise, a yellow alarm indication will be
displayed during the pre-upgrade check. In this situation, modify or delete the incorrect
Issue 01 (2014-12-31)

Copyright Huawei
69
BSC6900 UMTS
Release Notes

V900R016C00SPC650
UNRNC or UCNNODE configurations by following steps in the alarm reference.
Solution
Impact
None
Test
Case
3.3.3.4 The relocation process fails when the Iur interfacebased common channel function is enabled.
Trouble
Ticket
Number
iCare: 2978836
Descript
ion
Condition: The SRNC and DRNC are both enabled with the Iur interfacebased common channel function. In addition, cross-Iur cell update is
triggered in concurrent with either of the following process:
DTS: DTS2014072201349
Cross-Iur F2P state transition
Cross-Iur P2P state transition
Symptom: The SRNC sends a COMMON TRANSPORT CHANNEL

RESOURCES REQUEST message to the DRNC over the Iur interface but
receives no response. Later, the SRNC initiates a relocation process but
Issue 01 (2014-12-31)

Copyright Huawei
70
BSC6900 UMTS
Release Notes

V900R016C00SPC650
preparations for the relocation fails.

Impact: Values of the following counters increase:
RELOC.AttPrepUENotInvolPS
RELOC.FailPrepUENotInvolPS.Unsp
NOTE
To enable the Iur interface-based common channel function, run the following
command:
MOD UNRNC: NRncId=*, SuppIurCch=YES;
Severity
Minor
Root
Cause
When the cross-Iur F2P and P2P processes end, the SRNC sends a
COMMON TRANSPORT CHANNEL RESOURCES RELEASE
REQUEST message to the DRNC. After receiving the message, the DRNC
releases the DRNTI. When the SRNC processes the cell update request
subsequently and initiates the relocation process, the relocation fails because
the DRNC cannot find the corresponding DRNTI.
Solution
The SRNC now directly triggers a Directed Signaling Connection Reestablishment (DSCR) process in the preceding scenario, instead of
triggering the Iur interface common channel resource initialization process
or the relocation process. RESERVED_SWITCH_12_BIT11 under the
RsvSwitch12 parameter in the SET UALGORSVPARA command controls
whether to enable this solution.
Issue 01 (2014-12-31)

Copyright Huawei
71
BSC6900 UMTS
Release Notes

V900R016C00SPC650
By default, this solution is disabled (default value: 0) for both new networks
and upgrade scenarios. When this solution is enabled, the SRNC directly
triggers the DSCR process instead of the relocation process. When this
solution is disabled, the SRNC triggers the relocation process in the
preceding scenario.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
Values of the following counters increase:

VS.RRC.AttConnRel.DSCR.RNC
VS.RRC.AttConnRel.DSCR.SRNC
VS.IU.RelReqPS.sum
VS.IU.RelReqCS.sum
Test
Case
3.3.3.5 The CPU usage instantaneously increases when

message tracing over the Iur-p interface is enabled.
Trouble
Ticket
Number
DTS: DTS2014102902660
Descripti
on
Condition: RNC in Pool Load Sharing is enabled on the basis of Huawei

smartphone traffic model. Message tracing over the Iur-p interface is
enabled when all messages under all process identifications (PIDs) are
traced by default.
Symptom: After message tracing over the Iur-p interface is enabled, the
CPU usage instantaneously increases and the OMU triggers flow control on
tracing tasks.
Impact: The CPU usage increases significantly.
Severity
Minor
Root
Cause
When message tracing over the Iur-p interface is enabled, all messages
under all PIDs are traced by default, including control frames and data
frames. If traffic is heavy, the number of traced messages will exceed the
OMU processing capability.
Solution
When message tracing over the Iur-p interface is enabled in the preceding
scenario, the number of traced packets has been decreased. In addition,
messages are not traced by PIDs and the PID selection function has been
removed from the LMT interface.
Solution
None
Issue 01 (2014-12-31)

Copyright Huawei
72
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact
Test Case
3.3.3.6 Uplink BLER-related counters return inaccurate

values when the AMRC feature is activated.
Trouble
Ticket
Number
DTS: DTS2014101307617
Descripti
on
Conditions:
The adaptive multi rate control (AMRC) feature is activated.
The Transcoder Free Operation (TrFO) function is enabled.
RB reconfiguration is triggered for AMR services for certain reasons,

such as resource optimization.
NOTE
For details about the triggering methods of RB reconfiguration in AMR services, see
the "Limitation on the Downlink Rate over the Air Interface for AMR Services" part
of section 6.4 "AMRC Based on TFO/TrFO" in AMR Feature Parameter Description.
Impact: Values returned by the following counters are greater than

expected:
VS.ULBler.AMRWB
VS.ULBler.AMRWB.ErrTB
VS.ULBLer.Out.AMR
VS.ULBler.AMR
VS.ULBler.AMR.ErrTB
Impact: Values returned by the preceding counters are inaccurate.

Severity
Minor
Root
Cause
The UEs do not transmit packets during the RB reconfiguration process.

Due to uplink DPDCH power exceptions, however, the NodeB incorrectly
ascertains that it receives packets from the UEs. In addition, the NodeB
incorrectly verifies the Cyclic Redundancy Check Indicator in the packets.
Consequently, the RNC measures the uplink BLER-related counters when
it should not.
Solution
The RNC does not now measure uplink BLER-related counters for AMR
services in the preceding scenario.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
73
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.3.7 The RNC improperly processes security mode in

incoming inter-RAT relocations for combined services or PS
services.
Trouble
Ticket
Number
DTS: DTS2014111310081
Descripti
on
Problem 1:
Condition: An LTE-to-UMTS relocation is triggered for PS+CS combined
services. The RNC receives a RELOCATION REQUEST message from the
PS domain and then a RELOCATION REQUEST message from the CS
domain.
Symptom: The RNC delivers a SECURITY MODE COMMAND message
only to the CS domain.
Impact: PS services fail after the relocation is complete.
Problem 2:
Condition:
In an LTE-to-UMTS relocation for PS+CS combined services or a GSMto-UMTS relocation for PS services, the RNC receives a HANDOVER
TO UTRAN COMPLETE message from the UE performing the
services.
Either of the following configurations takes effect:
SET
URRCTRLSWITCH:OptimizationSwitch3=L2U_UP_DELAY_OPT_
SWITCH-1;
The configuration enables the RNC to restore the user plane and send a
RELOCATION COMPLETE message to the core network (CN)
immediately after an LTE-to-UMTS PS handover is complete.
SET
URRCTRLSWITCH:PROCESSSWITCH3=INTERRAT2U_RESUM
E_PS_ASAP_SWITCH-1;
The configuration enables the RNC to restore the user plane and send a
RELOCATION COMPLETE message to the CN immediately after an
LTE-to-UMTS or a GSM-to-UMTS PS handover is complete.
Symptom: After receiving the HANDOVER TO UTRAN COMPLETE
message, the RNC sends a RELOCATION COMPLETE message to the
CN before sending a SECURITY MODE COMMAND message.
Impact: Integrity protection is not applied to NAS message, leading to an
incoming relocation failure.
Severity
Minor
Root
Cause
Problem 1:
The RNC executes security mode only for the domain indicated by the last
RELOCATION REQUEST message (which is received from the CS
domain). Therefore, the RNC does not execute security mode for the PS
domain, leading to PS service failures.
Problem 2:
Issue 01 (2014-12-31)

Copyright Huawei
74
BSC6900 UMTS
Release Notes

V900R016C00SPC650
NAS messages are sent prior to security mode execution and therefore lack
integrity protection.
Solution
Problem 1:
the SET UALGORSVPARA command controls whether the RNC sends a
SECURITY MODE COMMAND message to both the CS and PS domains.
sends a SECURITY MODE COMMAND message to the CS domain and
then to the PS domain in LTE-to-UMTS relocations for PS+CS combined
services. When this solution is disabled, the RNC sends a SECURITY
MODE COMMAND message to only for the domain indicated by the last
RELOCATION REQUEST message in LTE-to-UMTS relocations.
SET UALGORSVPARA:
SET UALGORSVPARA:
Problem 2:
the SET UALGORSVPARA command controls whether the RNC sends a
RELOCATION COMPLETE message to the CN immediately after
receiving a HANDOVER TO UTRAN COMPLETE message from a UE.
networks and upgrade scenarios. When this solution is enabled, the RNC,
after receiving a HANDOVER TO UTRAN COMPLETE message, sends a
RELOCATION COMPLETE message to the CN only after it has later
received a SECURITY MODE COMPLETE message from the UE. When
this solution is disabled, the RNC sends a RELOCATION COMPLETE
message immediately after receiving a HANDOVER TO UTRAN
COMPLETE message.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
75
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.3.8 Counters related to Multiband Direct Retry Based on

UE Location return inaccurate values if measurement-based
periodic DRD is triggered.
Trouble
Ticket
Number
DTS: DTS2014103008925
Descripti
on
Condition: This fault occurs when all of the following conditions apply:
The Multiband Direct Retry Based on UE Location feature is enabled.
The measurement-based periodic DRD algorithm is enabled.
Measurement-based periodic DRD is triggered when services are set up.
NOTE
For details about how to enable Multiband Direct Retry Based on UE Location and
measurement-based periodic DRD, see related feature documentation.
Symptom: The RNC measures the following counters:
VS.MCDRD.Periodic.AttIn
VS.MCDRD.Periodic.AttOut
VS.MCDRD.Periodic.SuccIn
VS.MCDRD.Periodic.SuccOut
VS.UELocation.MultiBand.DRD.AttIn
VS.UELocation.MultiBand.DRD.AttOut
VS.UELocation.MultiBand.DRD.SuccIn
VS.UELocation.MultiBand.DRD.SuccOut
Impact: The following counters return inaccurate values:
Severity
Minor
Root
Cause
The RNC falsely concludes that Multiband Direct Retry Based on UE

Location is triggered, because the RNC uses the sequencing algorithm of
this feature to select candidate target cells when triggering measurementbased periodic DRD. As a result, the RNC measures counters related to this
feature when it should not.
Solution
The RNC now does not measure counters related to Multiband Direct Retry
Based on UE Location in the preceding scenario.
Solution
Impact
Values of the following counters decrease:
Test Case
Issue 01 (2014-12-31)
Copyright Huawei
76
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.3.9 Parameter configuration for power control is

inappropriate if PS services are set up following an AMR
service reconfiguration.
Trouble
Ticket
Number
DTS: DTS2014102408648
Descripti
on
Condition:
PS services are set up after AMR services are reconfigured.
The maximum rate of reconfigured AMR services is less than the

maximum rate of PS services.
Symptom: The value of BetaD/BetaC contained in the RADIO BEARER

SETUP message for PS service setup is less than the value contained in the
RADIO BEARER RECONFIGURATION message for AMR service
reconfiguration.
NOTE
For details about BetaC and BetaD, see 3GPP TS 25.214.
Impact: The UE transmit power increases, and the cell uplink capacity
decreases.
Severity
Minor
Root
Cause
Before AMR service reconfiguration, the maximum AMR rate is greater

than the maximum PS rate and therefore BetaC and BetaD to be used by
the UE is calculated based on the reference BetaC and reference BetaD
defined in typical parameter configuration for AMR services. After AMR
service reconfiguration, the maximum PS rate is greater than the maximum
AMR rate and therefore BetaC and BetaD to be used by the UE is
calculated based on the reference BetaC and reference BetaD defined in
typical parameter configuration for PS services.
As a result, the value of BetaD/BetaC decreases after AMR service
reconfiguration. When the uplink DPDCH power remains unchanged, the
uplink DPCCH power increases and the total UE transmit power increases,
decreasing cell uplink capacity.
NOTE
Typical parameter configuration (in the ADD UTYPRABBASIC or MOD
UTYPRABBASIC command)for narrowband AMR services and that for wideband
AMR services define reference BetaC and reference BetaD only for AMR rate of 12.2
kbit/s and 23.85 kbit/s, respectively.
Solution
When selecting the reference BetaC and reference BetaD for UEs
processing AMR+PS services, the RNC now considers the maximum rate
as 12.2 kbit/s for narrowband AMR services and 23.85 kbit/s for wideband
AMR services.
Solution
Impact
The cell uplink capacity improves and the value of the VS.MeanRTWP
counter decreases in cells where UEs process the AMR 12.28 kbit/s+PS 8
kbit/s combined services or AMR 23.85 kbit/s+PS 16 kbit/s combined
services.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
77
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.3.10 The RNC fails to add secondary carrier links for the
DC-HSUPA UE after a serving cell change failure.
Trouble
Ticket
Number
DTS: DTS2014112103383
Descripti
on
Condition: After a serving cell change within the active set of the DCHSUPA UE fails, the RNC fails to add secondary carrier links for the UE
during a soft handover.
Symptom: In the preceding scenario, when a secondary carrier link is
added during a soft handover, the RL ID carried in an NBAP RL ADD
REQ message sent by the RNC to the NodeB is the same as the RL ID of
the target cell of the previous serving cell change. As a result, the NodeB
responds with an NBAP RL ADD FAIL message.
Impact: The soft handover fails, and therefore the soft handover success
rate decreases.
Severity
Minor
Root
Cause
After the serving cell change fails, the RL ID of the link is released but the
corresponding link is still used. This RL ID is then assigned to another link,
resulting in RL ID conflicts.
Solution
Before releasing an RL ID, the RNC now determines whether the RL ID is

used by a secondary carrier link. If it is, the RNC does not release the RL
ID.
Solution
Impact
In the preceding scenario, secondary carrier links can be successfully

added, and the soft handover success rate increases.
Test Case
3.3.3.11 Some UEs fail to run CS services when CS fallback

is triggered.
Trouble
Ticket
Number
DTS: DTS2014110406353
Descripti
on
Condition:
If a UE camping on the LTE network initiates a CS service, CS fallback to
UMTS is triggered.
Symptom: The CS service setup fails.
Impact: The UE cannot enjoy CS services.
Severity
Issue 01 (2014-12-31)
Minor
Copyright Huawei
78
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Root
Cause
Once CS fallback to UMTS is completed, the core network initiates

security mode requests to the RNC in both the CS and PS domains.
After the security mode is applied, the UE sends messages using integrity
protection parameters of the first security mode, but the RNC uses integrity
protection parameters of the second security mode for a check on the
messages. As a result, the check fails.
Solution

the SET UALGORSVPARA command controls whether the RNC uses
correct integrity protection parameters to check messages sent by the UE.
When this solution is enabled, the RNC uses correct integrity protection
parameters to check messages sent by the UE.
When this solution is disabled, the RNC uses the latest integrity protection
parameters to check messages sent by the UE.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
None
Test Case
3.3.3.12 The RNC incorrectly measures certain performance

counters for the MBDR-based inter-RAT handovers.
Trouble
Ticket
Number
DTS: DTS2014071807270
Descripti
on
Condition: In the single-signaling phase, the RNC triggers a measurementbased directed retry (MBDR)-based inter-RAT handover measurement but
the UE does not report a measurement report. Therefore, the RNC releases
the measurement control after the measurement timer expires.
Subsequently, the UE establishes CS services in a UMTS cell and then the
RNC triggers a non-MBDR-based inter-RAT handover.
Symptom: The RNC measures the performance counters
VS.IRATHO.SuccOutCS.MBDR and VS.IRATHO.AttOutCS.MBDR,
which results in unexpected increase in counter values.
Impact: The measured performance counters for the MBDR-based interRAT handover are inconsistent with the actual counter values.
Severity
Minor
Root
If the RNC has triggered MBDR inter-RAT measurement on a UE before,
Issue 01 (2014-12-31)

Copyright Huawei
79
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Cause
the RNC will measure the counters VS.IRATHO.SuccOutCS.MBDR and

VS.IRATHO.AttOutCS.MBDR regardless of the causes triggering interRAT handovers.
Solution
The RNC now measures only the counters

VS.IRATHO.SuccOutCS.MBDR and VS.IRATHO.AttOutCS.MBDR of
outgoing inter-RAT handovers triggered by the MBDR algorithm.
Solution
Impact
In the preceding scenario, values of the following performance counters

decrease:
Test Case
VS.IRATHO.SuccOutCS.MBDR
VS.IRATHO.AttOutCS.MBDR
3.3.3.13 Some IEs in the INITIAL UE MESSAGE message are

not parsed during signaling tracing.
Trouble
Ticket
Number
DTS: DTS2014071507850
Descripti
on
Condition:
When a CM Service Request or Location Updating process is triggered, the
RNC sends an INITIAL UE MESSAGE message to the CN.
Symptom:
The following IEs in the INITIAL UE MESSAGE message are not
displayed on the LMT tracing interface:
additional-update-para and device-properties for the CM Service Request

process
additional-update-para, device-properties, and ms-network-featuresupport for the Location Updating process
Impact:
Users cannot obtain complete information about the INITIAL UE
MESSAGE message.
NOTE
This issue has been resolved in V900R016C00SPC630, and its release notes are
added in this version.
Severity
Minor
Root
Cause
After a protocol upgrade, the ASN parsing file is not updated on the RNC
to comply with the new protocol.
Solution
The defect has been rectified. The ASN parsing file has been updated to
comply with the new protocol so that all IEs in the INITIAL UE
MESSAGE message can be parsed.
Solution
Impact
None
Issue 01 (2014-12-31)

Copyright Huawei
80
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Test Case
3.3.3.14 In a PDP deactivation procedure, the RNC sends the

core network a RAB RELEASE REQUEST message.
Trouble
Ticket
Number
DTS: DTS2014090301307
Descripti
on
Condition: A UE or the core network sends a DEACTIVATE PDP

CONTEXT REQUEST message to trigger a packet data protocol (PDP)
deactivation procedure.
Symptom: The RNC sends the core network a RAB RELEASE REQUEST
message with the cause value "GTP Resources Unavailable" after the core
network sends the RNC a RAB ASSIGNMENT REQUEST message to
release a RAB.
Impact: The RAB RELEASE REQUEST message is redundant.
Severity
Minor
Root
Cause
Once a PDP deactivation procedure is started, the core network will

immediately delete user-plane resources and sends the RNC a RAB
ASSIGNMENT REQUEST to release a RAB. However, the UE may still
initiate data transmission.
Consequently, the RNC sends the core network a RAB RELEASE
REQUEST message with the cause value "GTP Resources Unavailable".
Solution

the SET UALGORSVPARA command controls whether the RNC sends
the core network a RAB RELEASE REQUEST message with the cause
value "GTP Resources Unavailable" in a PDP deactivation procedure.
When this solution is enabled, the RNC does not send the core network a
RAB RELEASE REQUEST message with the cause value "GTP Resources
Unavailable".
When this solution is disabled, the RNC sends the core network a RAB
RELEASE REQUEST message with the cause value "GTP Resources
Unavailable".
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
Issue 01 (2014-12-31)
If GTPU_ERR_IND_DEF_SWITCH under the OptimizationSwitch

parameter in the SET URRCTRLSWITCH command is set to 0 (this
switch is turned off), the PS RAB drop rate decreases.

Copyright Huawei
81
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Test Case
3.3.3.15 The IE "TargetCellId" contained in a DIRECT

INFORMATION TRANSFER message is incorrectly examined
in a RIM procedure.
Trouble
Ticket
Number
DTS: DTS2014091503669
Descripti
on
Condition: A RAN Information Management (RIM) procedure is triggered.

Symptom: The information examined from the information element (IE)
"TargetCellId" contained in a DIRECT INFORMATION TRANSFER
message is different from the actual code stream. The message is traced on
the offline LMT, online LMT, or U2000.
Impact: The descriptions are misleading.
NOTE
Severity
Minor
Root
Cause
In the preceding scenario, the mechanism for examining the IE

"TargetCellId" is defective.
Solution
The defective mechanism has been corrected so that the information

examined from the IE is consistent with the actual code stream.
Solution
Impact
None
Test Case
3.3.3.16 Incorrect license control item usage and false

alarms are reported for some features.
Trouble
Ticket
Number
iCare: 3287049
Descripti
on
Condition: One of the features in the following table is deactivated.
Issue 01 (2014-12-31)
DTS: DTS2014080401853, DTS2014111403431, DTS2014090905949

Copyright Huawei
82
BSC6900 UMTS
Release Notes
Issue 01 (2014-12-31)

V900R016C00SPC650

Copyright Huawei
83
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Symptom:
The DSP LICUSAGE command output indicates that the usage of the
license control item(s) for the feature concerned is not zero.
An alarm is falsely reported for the license control item(s) of the feature.
Impact: Incorrect license control item usage and false alarms hinder
network operation and maintenance.
NOTE
Incorrect license control item usage does not affect the feature concerned.
Severity
Minor
Root
Cause
When calculating the license control item usage for the preceding features,
the RNC obtains incorrect information about the activation/deactivation
state of the features listed above.
Solution
The RNC now does not calculate license control item usage for the
preceding features if they have been deactivated.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
84
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.3.17 The SRNC does not send the DRNC a RESET

REQUEST message after the SRNC is restarted on RNC in
Pool networking.
Trouble
Ticket
Number
DTS: DTS2014082001582
Descripti
on
Condition:
The RNC in Pool Node Redundancy feature is enabled and the active
RNC is connected to a neighboring RNC through the Iur interface.
The active RNC is restarted.
The following process switch is turned on by running the SET

URRCTRLSWITCH command.
SET URRCTRLSWITCH:
OptimizationSwitch5=RNC_IN_POOL_IU_RESET_SWITCH-1;
Symptom: The active RNC does not send the neighboring RNC a RESET
REQUEST message.
Impact: The resources of the neighboring RNC cannot be released over the
Iur interface.
Severity
Minor
Root
Cause
In the scenario where the RNC in Pool Node Redundancy feature is

enabled, the standby-to-active switchover process and the main control
subsystem selection process concurrently occur. As a result, the active RNC
does not experience a normal Iur reset process.
Solution

the SET UALGORSVPARA command controls whether the active RNC
sends the neighboring RNC a RESET REQUEST message when the
standby-to-active switchover process and the RNC reset process
concurrently occur.
When this solution is enabled, the active RNC sends the neighboring RNC
a RESET REQUEST message through the Iur interface.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
85
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.3.18 CS service setup fails when the coverage is strong

and the delay over the Iub interface is large.
Trouble
Ticket
Number
iCare: 3471170
Description
Condition:
DTS: DTS2014110405620
In a Cell_DCH-to-Cell_DCH (D2D) RAB setup procedure, UEs that

use a signaling rate of 13.6 kbit/s are located in areas with strong
coverage.
The Iub delay is greater than 30 ms.
The following command is executed to turn on the switch specifying

whether the RNC reduces the activation time offset during the RB
setup to reduce the service setup delay in the strong coverage
scenario:
SET URNCTIMEPARA: SCovRbSetActTimeOptSwitch=ON;
Symptom: CS services fail to be set up.

Impact: The CS service setup success rate decreases.
Severity
Minor
Root Cause
In this scenario, the RNC sends the NodeB a RADIO LINK

RECONFIGURATION COMMIT message after the RB activation is
completed. As a result, the RNC fails to receive the RADIO BEARER
SETUP COMPLETE message from UEs. After the RB setup response
timer (RbSetupRspTmr) expires, CS service setup fails.
Solution
The RNC now sends the NodeB a RADIO LINK RECONFIGURATION

COMMIT message before the activation is completed.
Solution
Impact
The CS service setup success rate increases.
Test Case
3.3.3.19 UEs experience PS service drops when the RNC

initiates a PS RAB modification.
Trouble
Ticket
Number
iCare: 3643123
Description
Condition: RAB_ASS_MOD_TNL_ADDR_SUP_SWITCH under the

PROCESSSWITCH4 parameter and
RAB_MOD_IUPS_ADMIFAIL_GTPU_REEST_SWITCH under the
OptimizationSwitch5 parameter in the SET URRCTRLSWITCH
command are turned on (both set to 1). In this configuration, when the
SGSN initiates a PS RAB modification procedure, the SGSN changes its
user-plane IP address, and the new user-plane IP address and that carried
by the SGSN during the RAB establishment do not belong to the same
Issue 01 (2014-12-31)
DTS: DTS2014110900249

Copyright Huawei
86
BSC6900 UMTS
Release Notes

V900R016C00SPC650
adjacent node.
Symptom: After responding the SGSN with the RAB ASSIGNMENT
RESPONSE message, the RNC immediately sends the SGSN the RAB
RELEASE REQUEST message with the cause value "Radio Connection
With UE Lost", and the PS services are released unexpectedly.
Impact: The PS service drop rate increases.
Severity
Minor
Root Cause
In the preceding scenario, an error occurs when the RNC re-establishes a

GTP-U tunnel. As a result, the PS services are released unexpectedly.
Solution
The RNC correctly re-establishes the GTP-U tunnel.
Solution
Impact
The PS service drop rate decreases.
Test Case

Trouble
Ticket
Number
DTS: DTS2014091802306
Descriptio
n
Condition: The peer end uses the RC4 encryption algorithm to

communicate with the OMU.
Symptom: Communication data is vulnerable to plaintext-recovery

attacks.
Impact: Communication data between the peer end and the OMU is
vulnerable to attacks.
Severity
Minor
Root
Cause
The encryption algorithms supported by the OMU includes the RC4

algorithm. The RC4 algorithm, as used in the TLS protocol and SSL
protocol, has many single-byte biases, which makes it easier for remote
attackers to conduct plaintext-recovery attacks via statistical analysis of
ciphertext in a large number of sessions that use the same plaintext.
Solution
The OMU no longer supports the RC4 algorithm.
Solution
Impact
If the peer end uses the RC4 algorithm to communicate with the OMU,
the communication will fail.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
87
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.3.3.21 The automatic switchover of the active and standby

OMUs cannot be performed when the hard disk of the active
OMU is abnormal and that of the standby OMU is normal.
Trouble
Ticket
Number
DTS: DTS2014062605719
Description
Condition: In dual-OMU mode, the hard disk of the active OMU is

abnormal, and that of the standby OMU is normal.
Symptom: The automatic switchover of the active and standby OMUs
cannot be performed.
Impact: The stability and reliability of the OMU decrease.
Severity
Minor
Root Cause
The self-healing function is unavailable in the preceding scenario. As a

result, the automatic switchover of the active and standby OMUs cannot
be performed.
Solution
The self-healing function is now available in the preceding scenario. If

the hard disk of the active OMU is abnormal and that of the standby
OMU is normal, the automatic switchover of the active and standby
OMUs is performed.
The Reserved parameter 3 parameter in the SET DEVRSVDPARA
command controls whether to enable the self-healing function. When
this parameter is set to 1, this function is enabled. When this parameter
is set to a value other than 1, this function is disabled. By default, this
function is disabled (default value: 4294967295) for both new networks
and upgrade scenarios.
To enable this function, run the following command:
SET DEVRSVDPARA: RSVDPARA3=1;
To disable this function, run the following command:
SET DEVRSVDPARA: RSVDPARA3=0;
NOTE
The self-healing function is also controlled by the Self-healing Switch parameter
in the SET SLFSLVSW command. This function takes effect only when Selfhealing Switch is set to ON(ON). The automatic switchover of the active and
standby OMUs can be performed only once within a day.
Solution
Impact
None
Test Case
3.3.3.22 TCP ISN security risks are found during CSEC scan.
Trouble
Ticket
Number
Issue 01 (2014-12-31)
DTS: DTS2014111804809
Vulnerability number: HWPSIRT-2014-0880

Copyright Huawei
88
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Descriptio
n
Condition: Services use control plane TCP (for example, TWAMP)

connections.
Symptom: The initial sequence number (ISN) generation algorithm of the
control plane TCP components is used to generate a random ISN based on
time. R(t) in the formula used by the algorithm is a random value.
Attackers may guess the ISN when sampling a large number of packets
containing R(t) values.
Impact: When sampling a large number of packets containing R(t)
values, attackers may guess the ISN and simulate the peer device to attack
the base station controller.
Severity
Minor
Root
Cause
The current ISN generation algorithm uses the following formula to

calculate the ISN: ISN = M + R(t) + F (localhost, localport, remotehost,
remoteport). In this formula, M indicates a random value ranging from
4096 to 8191. R(t) indicates a random value that uses time as a seed. F
indicates the MD5 algorithm. When sampling a large number of packets
containing R(t) values, attackers can guess the ISN.
Solution
An enhanced ISN generation algorithm has been used to improve security.
Solution
Impact
None
Test Case
ID
3.3.3.23 The base station controller does not report ALM21541 SCTP Link Fault when an SCTP link whose Application
type is BBAP(BBAP) and Signalling link mode is
SERVER(SERVER MOD) becomes faulty.
Trouble
Ticket
Number
DTS: DTS2014083003635
Descripti
on
Condition: An SCTP link whose Application type is BBAP(BBAP) and

Signalling link mode is SERVER(SERVER MOD) becomes faulty.
Symptom: The base station controller does not report ALM-21541 SCTP
Link Fault.
Impact: Maintainability is poor and users are not prompted to handle a
fault in a timely manner when it occurs.
NOTE
Severity
Minor
Root
Cause
After the configuration of such an SCTP link takes effect in the preceding
scenario, if the link is always faulty, the base station controller does not
Issue 01 (2014-12-31)

Copyright Huawei
89
BSC6900 UMTS
Release Notes

V900R016C00SPC650
report ALM-21541 SCTP Link Fault.

Solution
The base station controller now reports ALM-21541 SCTP Link Fault if an
SCTP link becomes faulty in the preceding scenario.
Solution
Impact
None
Test Case
3.3.3.24 The GPS satellite health check function is not

controlled by commands.
Trouble
Ticket
Number
DTS: DTS2014112710508
Descripti
on
Condition: The GCGa/GCGb board and the global positioning system

(GPS) are configured.
Symptom: The GPS satellite health check function is enabled by default and
cannot be manually disabled.
Impact: Users cannot control whether to start the GPS satellite health
check.
Severity
Minor
Root
Cause
The GPS satellite health check function is enabled by default and is not
controlled by a switch. Users cannot enable or disable this function based on
actual conditions.
Solution
1. The GPS satellite health check function is now disabled by default.

2. The STR GPSSTAT and STP GPSSTAT commands have been added for
users to start and stop the GPS satellite health check, respectively.
Solution
Impact
Before running the DSP GPSSTAT command to query the GPS satellite
health status, users must run the STR GPSSTAT command to start the GPS
satellite health check.
Test
Case
3.3.4 Suggestion
3.3.4.1 When the SRB over HSDPA feature takes effect,
single HSUPA BE services are dropped.
Trouble
Ticket
Number
DTS: DTS2014111009554
Descripti
Condition:
Issue 01 (2014-12-31)

Copyright Huawei
90
BSC6900 UMTS
Release Notes

V900R016C00SPC650
on
SRBs are transmitted over HSDPA. Specifically, the SRB over HSDPA
feature takes effect.
The Adaptive Adjustment of HSUPA Small Target Retransmissions feature
takes effect
In a hard handover procedure, the uplink channel over which TRBs for a
single HSUPA BE service are transmitted falls back to DCH from E-DCH,
and then the uplink channel periodically attempts to be retried to E-DCH.
Symptom: Single HSUPA BE services are dropped.
Impact: The drop rate of single HSUPA BE services increases.
Severity
Suggestion
Root
Cause
In this scenario, the RNC does not correctly maintain the measurement
status for the Adaptive Adjustment of HSUPA Small Target
Retransmissions feature. As a result, single HSUPA BE services are
abnormally released.
Solution
The RNC now correctly maintains the measurement status for the Adaptive
Adjustment of HSUPA Small Target Retransmissions feature.
solution. By default, this solution is disabled (default value: 0) for both new
SET
UALGORSVPARA:RsvSwitch11=RESERVED_SWITCH_11_BIT17-1;
SET
Solution
Impact
The drop rate of single HSUPA BE services decreases.
Test Case
ID
3.3.4.2 CS and PS combined services do not allow servicebased inter-RAT handovers.

Trouble
Ticket
Number
DTS: DTS2014111403173
Descripti
on
Condition: A UMTS cell serves UEs running CS and PS combined

services.
Symptom: The RNC does not send service-based inter-RAT measurement
control messages to these UEs.
Impact: These UEs cannot be handed over to a GSM cell to perform CS
Issue 01 (2014-12-31)

Copyright Huawei
91
BSC6900 UMTS
Release Notes

V900R016C00SPC650
services.
Severity
Suggestion
Root
Cause
The RNC does not support service-based inter-RAT handovers for CS and
PS combined services.
Solution
The RNC now supports service-based inter-RAT handovers for CS and PS

combined services.
ADD UCELLCOALGOENHPARA or MOD
UCELLCOALGOENHPARA command controls whether to enable this
ADD UCELLCOALGOENHPARA/MOD
UCELLCOALGOENHPARA:
CellId=xxx,
ADD UCELLCOALGOENHPARA/MOD
UCELLCOALGOENHPARA:
CellId=xxx,
Solution
Impact
Test Case
ID
This solution reduces UMTS cell load and increases GSM cell load, which
can be seen in the increase in the values returned by the following counters:
VS.IRATHO.AttRelocPrepOutCS.Service
VS.IRATHO.SuccRelocPrepOutCS.Service
VS.IRATHO.SuccOutCS.Service
VS.IRATHO.AttOutPSUTRAN.Service
VS.IRATHO.SuccOutPSUTRAN.Service
3.3.4.3 Some UEs report false measurement results or

experience call drops after they start neighboring LTE cell
measurement.
Trouble
Ticket
Number
DTS: DTS2014111403179
Descripti
on
Condition: The RNC sends a UE an LTE cell measurement control

message.
Symptom:
1. After the UE reports the measurement result, the RNC triggers a
Issue 01 (2014-12-31)

Copyright Huawei
92
BSC6900 UMTS
Release Notes

V900R016C00SPC650
handover to an LTE cell for the UE. The handover fails because of poor
signal quality.
2. After LTE cell measurement times out, the UE unexpectedly
experiences a call drop.
Impact:
1. The UMTS-to-LTE handover success rate is low, affecting user
experience.
2. The call drop rate increases, affecting user experience.
Severity
Suggestion
Root
Cause
1. The UE reports a false measurement report, in which signal quality of

the measured LTE cell is higher than what actually is, or the UE reports
an event that will trigger a handover to an LTE cell with poor signal
quality.
2. The UE is incompatible with LTE cell measurement. As a result, when a
UE having the compatibility issue is measuring LTE cells or has
completed LTE cell measurement, it experiences a call drop.
Solution
The ADD UIMEITAC command is used to configure UEs having

compatibility issues as special UEs. Besides,
RESERVED_SWITCH_BIT22 under the RsvSwitch parameter in this
command controls whether to enable the special UEs to measure LTE cells.
When RESERVED_SWITCH_BIT22 is set to 1, this switch is turned on.
The special UEs are not allowed to measure LTE cells and the RNC will
not send LTE cell measurement control messages to them. When
RESERVED_SWITCH_BIT22 is set to 0, this switch is turned off. The
special UEs are allowed to measure LTE cells and the RNC will send LTE
cell measurement control messages to them when necessary. By default,
this solution is disabled (default value: 0) for both new networks and
upgrade scenarios.
Run the following MML command to forbid special UEs to measure LTE
cells:
ADD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=xxx,
Description="xxx", RsvSwitch= RESERVED_SWITCH_BIT22-1;
Solution
Impact
This solution increases UMTS-to-LTE handover success rate and reduces

call drops.
Values returned by the following counters decrease:
Issue 01 (2014-12-31)
VS.U2LTEHO.AttOutPS
VS.U2LTEHO.AttOutPS.Service
VS.U2LHO.AttOutPS.Coverage
VS.U2LTEHO.AttOutPS.Load
VS.U2LTEHO.AttRelocPrepOutPS
VS.U2LTEHO.AttRelocPrepOutPS.Service
VS.U2LHO.AttRelocPrepOutPS.Coverage
VS.U2LTEHO.AttRelocPrepOutPS.Load
VS.U2LTEHO.RRCRelease.Service
VS.U2LTEHO.RRCRelease.Coverage
VS.U2LTEHO.RRCRelease.Load
Copyright Huawei
93
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Test Case
ID
VS.U2LTEHO.MeasCtrl.Num
VS.U2LTEHO.FailOutPS.PhyChFail
3.3.4.4 User access delay is greater than expected because

of redundant IEs in the RADIO BEARER SETUP message.
Trouble
Ticket
Number
DTS: DTS2014111502251
Descripti
on
Condition: CS service setup procedure.

Symptom: The RADIO BEARER SETUP message carries the same value
of the IE "RLC info" for three subflows of a CS RAB.
Impact: These IE values are redundant and prolong user access delay.
Severity
Suggestion
Root
Cause
As stipulated in 3GPP TS 25.331:

When the RADIO BEARER SETUP message contains the same RLC
configurations for the three subflows of a CS RAB, the IE "RLC info" in
the IE "RB information to setup" for the second and third subflows can be
set to Same as RB: 0xM (M indicating the ID of the first subflow).
The RNC does not comply with this and parses the redundant IEs in the
RADIO BEARER SETUP message, prolonging user access delay.
Solution
The reserved bit RESERVED_SWITCH_8_BIT10 of the RsvSwitch8

parameter in the SET UALGORSVPARA command is now used to
control whether the RNC sets the IE "RLC info" in the IE "RB information
to setup" for the second and third subflows to Same as RB: 0xM (M
indicating the ID of the first subflow) in the RADIO BEARER SETUP
message. By default, this solution is disabled (default value: 0) for both
When this solution is enabled, the RNC sets the IE "RLC info" in the IE
"RB information to setup" for the second and third subflows to Same as
RB: 0xM (M indicating the ID of the first subflow) in the RADIO
BEARER SETUP message. When this solution is disabled, the original
process is used.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
Issue 01 (2014-12-31)
None

Copyright Huawei
94
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Test Case
ID
3.3.4.5 The MC-HSDPA UE can still use the DTX/DRX feature

even when the MC-HSDPA secondary carrier does not
support this feature.
Trouble
Ticket
Number
DTS: DTS2014093009852
Descripti
on
Condition:
The UE which uses the MC-HSDPA and DTX/DRX features initiates a cell
update procedure due to link out-of-synchronization. The target cell
supports MC-HSDPA. The MC-HSDPA primary carrier supports the
DTX/DRX feature, whereas the MC-HSDPA secondary carrier does not.
Symptom:
During cell update, the RNC configures the DTX/DRX feature by mistake.
Impact:
In the preceding scenario, the NodeB scheduling function is affected, but
the KPI is not affected.
Severity
Suggestion
Root
Cause
In the preceding scenario, the RNC does not check whether the MCHSDPA secondary carrier supports the DTX/DRX feature.
Solution
In the preceding scenario, the RNC now also checks whether the MCHSDPA secondary carrier supports the DTX/DRX feature.
Solution
Impact
None
Test Case
ID
3.3.4.6 The RNC cannot accurately control the percentage of

UEs during outgoing inter-RAT handovers in the MBDR
algorithm.
Trouble
Ticket
Number
DTS: DTS2014071606620
Descripti
on
Condition:
Issue 01 (2014-12-31)
1. Load is shared among subsystems of the RNC.

2. Inter-RAT handover is enabled for measurement-based directed retry
(MBDR) UEs.
Copyright Huawei
95
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Symptom: The actual percentage of MBDR UEs in outgoing inter-RAT

handovers is inconsistent with the value of the UserPercentage parameter.
Impact: The RNC cannot accurately control the percentage of UEs during
inter-RAT outgoing handovers in the MBDR algorithm.
Severity
Suggestion
Root
Cause
In the preceding scenario, the target subsystem for load sharing cannot
obtain the accurate information about whether the source subsystem allows
the current UE to perform an outgoing inter-RAT handover. Therefore, the
target subsystem incorrectly allows or disallows the MBDR-based interRAT handover of the current UE.
Solution
In the preceding scenario, when a subsystem decides whether to allow an

MBDR UE to initiate an outgoing inter-RAT handover, the subsystem
directly compares the value of UserPercentage with a random number and
then make a decision based on the comparison results.
the SET UALGORSVPARA command is used to control this solution. By
default, this solution is disabled (default value: 0) for both new networks
To enable this solution, run the following command:
SET
To disable this solution, run the following command:
SET
Solution
Impact
None
Test Case
ID
3.3.4.7 The RNC cannot recognize the UE-sent packets with

IE "Header Extension Type" of 2.
Trouble
Ticket
Number
DTS: DTS2014121002973
Descripti
on
Condition: A UE is handed over from a non-Huawei RNC to a Huawei

RNC. The non-Huawei RNC sends the UE the RADIO BEARER
RECONFIGURATION message carrying the IE "Use special value of HE
field", but sends the Huawei RNC the RELOCATION REQUIRED
message that does not carry the IE "Use special value of HE field".
Symptom: After the UE is handed over to the Huawei RNC, the PS service
rate drops to zero.
Impact: User experience is poor.
Severity
Issue 01 (2014-12-31)
Suggestion
Copyright Huawei
96
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Root
Cause
In this scenario, after the non-Huawei RNC sends the UE the RADIO
BEARER RECONFIGURATION message carrying the IE "Use special
value of HE field", the UE sends the Huawei RNC packets with IE "Header
Extension Type" of 2. However, the non-Huawei RNC sends the Huawei
RNC the RELOCATION REQUIRED message without carrying the IE
"Use special value of HE field". As a result, the Huawei RNC discards
these UE-sent packets with IE "Header Extension Type" of 2 in accordance
with protocol 3GPP TS25.322.
Solution

UDPUCFGDATA command controls whether the RNC performs
compatibility processing for UE-sent packets with IE "Header Extension
Type" of 2. By default, this solution is disabled (default value: 0) for both
When this solution is enabled, the RNC performs compatibility processing
for UE-sent packets with IE "Header Extension Type" of 2 by reassembling
these packets into an RLC SDU and delivering the RLC SDU to upper
layers.
When this solution is disabled, the RNC discards UE-sending packets
whose value of the IE "Header Extension Type" is 2.
Solution
Impact
None
Test Case
ID
3.3.4.8 UEs are handed over or redirected from a UMTS

network to an LTE network before the penalty duration ends
Trouble
Ticket
Number
DTS: DTS2014052808705
Descripti
on
Condition:
In the SET UU2LTEHONCOV command, the U2L Punish Switch

parameter is set to 1 and the value of the U2L Penalty Timer parameter
is greater than 0.
A UE, after being handed over or redirected from an LTE network to a

UMTS network, establishes a PS service.
The RNC starts the penalty timer and the UE establishes a CS service.
Then, the UE releases the CS service before the penalty timer expires.
Symptom:
After releasing the CS service, the UE is handed over or redirected to an
LTE network before the penalty timer expires.
Issue 01 (2014-12-31)

Copyright Huawei
97
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact:
Ping-pong handover or redirection occurs between UMTS and LTE
networks and user experience deteriorates.
Severity
Suggestion
Root
Cause
The RNC stops the penalty timer after the CS service is established.
Solution
The RNC now does not stop the penalty timer after the CS service is
established.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The value of VS.U2LTEHO.AttOutPS.Service decreases.
Test Case
ID
3.3.4.9 The RNC does not penalize service-based UMTS-toLTE redirections or handovers on UEs redirected from the
LTE network to the UMTS network.
Trouble
Ticket
Number
DTS: DTS2014052808705
Descripti
on
Condition:
1. In the SET UU2LTEHONCOV command settings, the U2L Punish
Switch parameter is set to 1 and the U2L Penalty Timer parameter is
set to a value greater than 0.
2. A UE is redirected from the LTE network to the UMTS network. After
an RRC connection is established, the UE updates its location area or
routing area and then promptly releases the RRC connection.
3. The UE establishes an RRC connection again on the UMTS network
and then sets up a PS service.
Symptom: After the PS service is established, the RNC triggers a servicebased handover or redirection within the duration specified by the U2L
Penalty Timer parameter.
Impact: The UE experiences frequent handovers or redirections between
Issue 01 (2014-12-31)

Copyright Huawei
98
BSC6900 UMTS
Release Notes

V900R016C00SPC650
the UMTS network and the LTE network within a short period of time.
Severity
Suggestion
Root
Cause
In this preceding scenario, after the RRC connection is established again on

the UMTS network, the RNC does not identify that the UE is redirected
from the LTE network. Therefore, the RNC does not perform a penalty of
service-based UMTS-to-LTE redirections or handovers on the UE.
Solution
The RNC now records information about such a UE and stores the
information for 30s after the first RRC connection is released. When the
RRC connection is established again, the RNC identifies the UE having
been redirected from the LTE network by referring to the stored
information and penalizes service-based UMTS-to-LTE redirections or
handovers on the UE.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The value of VS.U2LTEHO.AttOutPS.Service decreases.
Test Case
ID
3.3.4.10 In some scenarios, the RNC does not perform a

penalty of service-based UMTS-to-LTE blind redirections.
Trouble
Ticket
Number
DTS: DTS2014052808705
Descripti
on
Condition:
1. The U2L Blind Redir Anti-Pingpong Timer parameter in the SET
UHOCOMM command is set to a value greater than 0.
2. The RNC triggers a blind redirection to the LTE network for a UE. The
UE, however, does not access the LTE network and sets up an RRC
connection on the UMTS network. After updating the location area or
routing area, the UE promptly releases the RRC connection.
3. The UE establishes an RRC connection again on the UMTS network
and then sets up a PS service.
Symptom: After the PS service is established, the RNC promptly initiates a
service-based UMTS-to-LTE blind redirection.
Issue 01 (2014-12-31)

Copyright Huawei
99
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact: The UE experiences frequent service-based UMTS-to-LTE blind

redirections and user experience deteriorates.
Severity
Suggestion
Root
Cause
After the RNC triggers a blind redirection to the LTE network for a UE, the
RNC records the UE as a "blind redirection UE". After the UE accesses the
UMTS network again due to the blind redirection failure, the RNC
promptly clears the record. As a result, after the PS service is established on
the UMTS network, the RNC allows blind redirections for a UE that has
experienced blind redirections.
Solution
The RNC now stores information for 30s regarding UEs that have
experienced blind redirections.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The value of VS.U2LTEHO.RRCRelease.Sevice.Blind decreases.
Test Case
ID
3.3.4.11 UEs redirected from an LTE network to a UMTS

network cannot be handed over or redirected back to an LTE
network.
Trouble
Ticket
Number
DTS: DTS2014052808705
Descripti
on
Condition:
PERFENH_PERMIT_U2L_ONLY_UE_FROM_L_SWITCH under
the PerfEnhanceSwitch2 parameter in the SET UCORRMPARA
command is set to 1.
A UE is redirected from the LTE network to the UMTS network. After

establishing an RRC connection, the UE updates its location area or
routing area and then promptly releases the RRC connection.
The UE sets up an RRC connection again in the UMTS network to

establish a PS service.
Symptom:
The UE cannot be handed over or redirected to an LTE network.
Issue 01 (2014-12-31)

Copyright Huawei
100
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Impact:
User experience is affected.
Severity
Suggestion
Root
Cause
In this scenario, after the RRC connection is reestablished, the RNC cannot
identify the UE being redirected from an LTE network. If
PERFENH_PERMIT_U2L_ONLY_UE_FROM_L_SWITCH under the
PerfEnhanceSwitch2 parameter is turned on, the RNC does not hand over
or redirect the UE to an LTE network.
Solution
In this scenario, the RNC now records information about such a UE and
stores the information for 30s after the first RRC connection is released.
When the RRC connection is being reestablished, the RNC identifies the
UE having been redirected from an LTE network by referring to the stored
information.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
Test Case
ID
VS.U2LTEHO.AttOutPS.Service
VS.U2LHO.AttOutPS.Coverage
VS.U2LTEHO.RRCRelease.Coverage
VS.U2LTEHO.AttOutPS.Load
VS.U2LTEHO.RRCRelease.Load
VS.U2LTEHO.RRCRelease.Load.Blind
VS.U2LTEHO.RRCRelease.Sevice.Blind
VS.U2LTEHO.AttOutPS
3.3.4.12 The LST ULTENCELL or LST U2GNCELL command

output displays undesired neighbor relationship
information.
Trouble
Ticket
Number
iCare: SR3688338
Descripti
Condition:
Issue 01 (2014-12-31)
DTS: DTS2014111306946

Copyright Huawei
101
BSC6900 UMTS
Release Notes

V900R016C00SPC650
on
All of the following conditions apply:
Logical RNC 1 and RNC 2 are configured on the same physical RNC.
Logical RNC 1 is the active RNC and the neighboring RNC of logical
RNC 2.
Cells served by logical RNC 1 are external cells served by logical RNC
2.
Symptom:
The LST ULTENCELL or LST U2GNCELL command output displays
undesired neighbor relationship of cells served by a specified RNC.
Impact:
The command output contains undesired information, which affects user
experience.
Severity
Suggestion
Root
Cause
A defective mechanism is used for querying neighbor relationship of cells

served by an RNC.
Solution
The defective mechanism has been rectified to ensure that the LST
ULTENCELL or LST U2GNCELL command output displays only the
neighbor relationship information of cells served by the specified RNC.
Solution
Impact
None
Test Case
ID
3.3.4.13 CPC reconfiguration messages transmitted over the

Uu interface are added two more bytes.
Trouble
Ticket
Number
DTS: DTS2014102308582
Descripti
on
Condition:
The switch controlling the coexistence between single hybrid automatic

repeat request (HARQ) process scheduling and continuous packet
connectivity (CPC) features has been turned off.
During CPC service reconfigurations, only the value of the IE "UE DTX
DRX Offset" changes. The transmission time interval (TTI) remains the
same.
Symptom: CPC reconfiguration messages transmitted over the Uu

interface carry the IE "DTX-DRX timing information", increasing the
message size.
Impact: The call drop rate may increase.
Severity
Issue 01 (2014-12-31)
Suggestion
Copyright Huawei
102
BSC6900 UMTS
Release Notes

V900R016C00SPC650
Root
Cause
During CPC service reconfigurations, the RNC assigns a new value to the
IE "UE DTX DRX Offset" even though the TTI remains the same. If the
new value is different from the original one, the RNC delivers the new
value to the UE through the IE "DTX-DRX timing information".
Solution
The RNC now does not assign a new value to the IE "UE DTX DRX
Offset".
Solution
Impact
None
Test Case
ID
3.3.4.14 The Differentiated Service Based on SPI Weight

feature is not provided with a control switch.
Trouble
Ticket
Number
DTS: DTS2014121502456
Descripti
on
Condition: The RNC assigns different SPI weight values to UEs of

different priorities.
Symptom: The Differentiated Service Based on SPI Weight feature
automatically takes effect.
Impact: This problem hinders network operation and maintenance.
Severity
Suggestion
Root
Cause
The WRFD-020806 Differentiated Service Based on SPI Weight feature is

not provided with a control switch.
Solution

SET UALGORSVPARA command controls whether to enable the
Differentiated Service Based on SPI Weight feature. When the switch is
turned on (value: 1), this feature is active; when the switch is turned off
(value: 0), this feature is inactive. By default, this feature is enabled
(default value: 1) for both new networks and upgrade scenarios.
Run the following MML command to enable the feature:
Run the following MML command to disable the feature:
Solution
Impact
None
Test Case
ID
Issue 01 (2014-12-31)

Copyright Huawei
103
BSC6900 UMTS
Release Notes

V900R016C00SPC650
3.4 Known Issues

3.4.1 Critical
None
3.4.2 Major
None
3.4.3 Minor
None
3.4.4 Suggestion
None
Issue 01 (2014-12-31)

Copyright Huawei
104
BSC6900 UMTS
Release Notes
4 Changes from V900R016C00SPH621 to

V900R016C00SPC630
Changes from
V900R016C00SPH621 to
V900R016C00SPC630
4.1 Change Summary
Compared with those in BSC6900 V900R016C00SPH621, capacity and performance remain
Hardware
Compared with that in BSC6900 V900R016C00SPH621, hardware remains unchanged in
V900R016C00SPC630.
Features
Compared with those in BSC6900 V900R016C00SPH621, no features have been added, six
features have been modified, and no features have been deleted in V900R016C00SPC630.
Resolved Issues
Compared with those in BSC6900 V900R016C00SPH621, no critical issues, ten major issues,
six minor issues, and eleven suggestion-level issues have been resolved in
V900R016C00SPC630.
Issue 01 (2014-12-31)

Copyright Huawei
105
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Compared with those in BSC6900 V900R016C00SPH621, configuration management
Compared with those in BSC6900 V900R016C00SPH621, performance management
Fault management
Compared with those in BSC6900 V900R016C00SPH621, fault management functions
License management
Compared with those in BSC6900 V900R016C00SPH621, license management
Changes.
Compared with those in BSC6900 V900R016C00SPH621, document organization and

performance.
4.1.2 Hardware
New Hardware
None
Modified Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
106
BSC6900 UMTS
Release Notes

V900R016C00SPC630
4.1.3 Features
V900R016C00SPH621 to V900R016C00SPC630.
Change type
Feature description
V900R016C00SPC630.xls, or see the V900R016C00SPC630 vs V900R016C00SPH621 sheet
BSC6900 V900R016C00SPC630.

This section provides the summary of the known issues in BSC6900 V900R016C00SPH621
Issue description
Severity
Solution impact
Parameter control
V900R016C00SPC630.xls, or see the the V900R016C00SPC630 vs V900R016C00SPH621
BSC6900 V900R016C00SPC630.

Compared with V900R016C00SPH621, configuration management functions remain
Issue 01 (2014-12-31)

Copyright Huawei
107
BSC6900 UMTS
Release Notes

V900R016C00SPC630

Compared with V900R016C00SPH621, performance management functions remain
Changes.

Compared with V900R016C00SPH621, fault management functions remain unchanged in
V900R016C00SPC630. For details about changes to alarms and events, see 11.3 Alarm

V900R016C00SPH621. For details about license changes, see 11.6 License Changes.

4.2 Feature Changes

4.2.1 New Features
None

4.2.2.1 Coexistence Between the Single HARQ Process
Scheduling and CPC Features
Description
Before this function takes effect, the single HARQ process scheduling and CPC features
cannot coexist and therefore users cannot enjoy the gains of them at the same time.
After this function takes effect, the single HARQ process scheduling and CPC features can
coexist, and therefore users can enjoy the gains of them at the same time for maximized
benefits.
Implementation
The DPCCH transmission interval of CPC UEs is set to 8 TTIs to achieve the coexistence
between the single HARQ process scheduling and CPC features.
UALGORSVPARA command is used to control whether the function of coexistence between
the single HARQ process scheduling and CPC features takes effect. By default, this function
Issue 01 (2014-12-31)

Copyright Huawei
108
BSC6900 UMTS
Release Notes

V900R016C00SPC630

When this switch is set to on, the number of 2 ms TTI UEs and HSUPA throughput increase,
whereas the cell load decreases.
Impact on NEs
None
Impact on Hardware
None

None

None

UALGORSVPARA command is set to on.

None

None

None
Related Operations

DTS: DTS2014061800095
Feature ID
None
Issue 01 (2014-12-31)

Copyright Huawei
109
BSC6900 UMTS
Release Notes

V900R016C00SPC630
4.2.2.2 Optimized PS BE Service Setup Process

Description
A PS BE service is carried on a 0 kbit/s DCH during the service setup process and the data
rate is increased later on using an event 4A measurement report based on the traffic volume.
This feature simplifies the RB setup message during the service setup process, improving the
service setup success rate.
When the data rate of the service needs to be increased, this feature enables the RNC to admit
the service the same way it admits a new service based on resource utilization and to complete
coverage-based uplink and downlink channel configuration, improving the success rate of
data rate increase.
Implementation
This feature is not used in the following scenarios where new services are set up:
SRBs are carried on the HS-DSCH, E-DCH, or common channels.
The SRB data rate is 6.8 kbit/s.
A UE has set up a PS service.
The active set of a UE contains DRNC links and the DRNC does not allow the data rate
to be configured as 0 kbit/s.
A UE is on a specific terminal list. RESERVED_SWITCH_BIT16 under the

RsvSwitch parameter in the ADD UIMEITAC command controls whether to disable
this feature for specific terminals. By default, RESERVED_SWITCH_BIT16 is set to
0, which indicates that this feature is applicable to all terminals.
The following is the process of service setup and data rate increase for a new PS BE service
when this feature is enabled (RESERVED_SWITCH_9_BIT30 is turned on):
1. During the service setup process, the PS BE service is carried on a 0 kbit/s DCH without
SRB rate reconfiguration or inter-frequency DRD.
2. The RB setup message does not carry the activation time, and the UE is immediately
activated upon receiving the message.
3. The RB setup message is simplified. Specifically, the message does not carry the following
IEs: "Uplink DPCH info", "Downlink DPCH info common for all RL", "Downlink
information for each radio link", "UTRAN DRX cycle length coefficient", and "DCH quality
target". RESERVED_SWITCH_10_BIT17 under the RsvSwitch10 parameter in the SET
UALGORSVPARA command controls whether to simplify the RB setup message. By
default, this solution is disabled (default value: 0), which indicates the RB setup message is
not simplified.
When there exist DCH 0 kbit/s services, the RNC does not change the downlink blind
detection status of the UE, thereby avoiding call drops of the UE due to compatibility issues.
4. The UE can send the RNC an event 4A measurement report based on the traffic volume to
increase the data rate of a PS BE service that has been set up. If the RNC receives the
measurement report for the PS BE service for the first time, the RNC can delay increasing the
data rate. Bits 10 to 14 of RsvU32Para18 in the SET UALGORSVPARA command specify
Issue 01 (2014-12-31)

Copyright Huawei
110
BSC6900 UMTS
Release Notes

V900R016C00SPC630
the delay time in data rate increase for the PS BE service for the first time. By default, the
combined value of bits 10 to 14 is 0, which indicates that there is no delay in data rate
increase for a PS BE service. If the service does not initiate data rate increase, this service will
be released after the PS 0 kbit/s user inactive detecting timer expires. Bits 0 to 15 of
RsvU32Para19 in the SET UALGORSVPARA command specify the length of the PS 0
kbit/s user inactive detecting timer. By default, the combined value of bits 0 to 15 is 0. When
the value of this parameter is set to 0, the length of the PS 0 kbit/s user inactive detecting
timer is still set through the SET UPSINACTTIMER command.
5. When the data rate of the PS BE service needs to be increased, the RNC admits the service
the same way it admits a new service based on resource utilization. In addition, the algorithm
for determining whether BE services on the UE will switch from HSUPA channels to R99
channels, coverage-based BE service initial TTI selection algorithm, and coverage-based PS
H2D during access algorithm take effect in the process of data rate increase.
The algorithm for determining whether BE services on the UE will switch from HSUPA
channels to R99 channels algorithm is optimized as follows:
If the RSCP of the best cell is available, the HSUPA bearer is selected based on the measured
RSCP. If the RSCP is unavailable, the HSUPA bearer is selected based on the measured
Ec/N0. BeTTI10msRscpThd in the SET UCHLQUALITYEVALUATE command specifies
the threshold for deciding the HSUPA bearer. If the HSUPA bearer policy applies and the
RSCP of the best cell is less than or equal to this threshold, the PS BE service is transferred
from the E-DCH to the DCH in the uplink.
The coverage-based BE service initial TTI selection algorithm is optimized as follows:
If the RSCP of the best cell is available, the HSUPA TTI is selected using the measured RSCP.
If the RSCP is unavailable, the HSUPA TTI is selected using the measured Ec/N0.
BeTTI2msRscpThd in the SET UCHLQUALITYEVALUATE command specifies the
threshold for selecting the HSUPA TTI. If the HSUPA 2-ms TTI policy applies and the RSCP
of the best cell is less than or equal to this threshold, the PS BE service uses a 10-ms TTI in
the uplink.

This feature improves the PS BE service setup success rate but slightly increases CPU usage
of the SPUa and SPUb boards.
The values of counters related to statistics on PS BE services whose RABs are carried on
different types of bearers during the service setup process decrease. The following counters
are examples: VS.HSDPA.RAB.AttEstab, VS.HSUPA.RAB.AttEstab.
The values of counters related to statistics on PS BE services whose RABs are reconfigured to
different types of bearers increase. The following counters are examples:
VS.HSUPA.D2E.Att, VS.HSDPA.D2H.Att.
Impact on NEs
None
Impact on Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
111
BSC6900 UMTS
Release Notes

V900R016C00SPC630

None

None

UALGORSVPARA command controls whether to enable this feature.
UALGORSVPARA command controls whether to simplify the RB setup message. This
switch is available only when RESERVED_SWITCH_9_BIT30 is turned on.
RESERVED_SWITCH_BIT16 under the RsvSwitch parameter in the ADD
UIMEITAC command controls whether to disable this feature for specific terminals.
Bits 10 to 14 of RsvU32Para18 in the SET UALGORSVPARA command specify the
delay time in data rate increase for the PS BE service for the first time.
Bits 0 to 15 of RsvU32Para19 in the SETUALGORSVPARA command specify the
length of the PS 0 kbit/s user inactive detecting timer.

The VS.AttRecfg.DCH0K.Upsizing counter is added to count the number of attempts for
data rate increase triggered by this feature in the best cell.
The VS.SuccRecfg.DCH0K.Upsizing counter is added to count the number of times of
successful data rate increase triggered by this feature in the best cell.
27 counters related to causes of 0 kbit/s service data rate increase failures and target
channels of 0 kbit service initiating data rate increase are added to evaluate the data rate
increase of 0 kbit/s PS services. For details, see the release note with a trouble ticket
number of DTS2014091705401.

None

None
Related Operations
Run the following MML command to enable this feature:

Run the following MML command to enable the RNC to simplify the RB setup message:
SET UALGORSVPARA:
Run the following MML command to disable this feature for specific terminals:
ADD UIMEITAC:
TAC_FUNC=Special_User_Enhance, TAC=xxx, Description="xxx", RsvSwitch=
RESERVED_SWITCH_BIT16-1;
Issue 01 (2014-12-31)

Copyright Huawei
112
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Set RsvU32Para18 based on the parameter settings of the Delay time in data rate
increase for the PS BE service for the first time.
If the value of the RsvU32Para18 parameter is 0 (0000 0000 0000 0000 0000 0000 0000
0000), set the values of bits 10 to 14 in RsvU32Para18 to 8 (0000 0000 0000 0000 0010
0000 0000 0000) and the value of RsvU32Para18 is now 8192. Then run the following
command to set the value of RsvU32Para18 to 8192:
SET UALGORSVPARA: RsvU32Para18=8192;
Set RsvU32Para19 based on the parameter settings of the PS 0 kbit/s user inactive
detecting timer length.
If the value of the RsvU32Para19 parameter is 0 (0000 0000 0000 0000 0000 0000 0000
0000), set the values of bits 0 to 15 in RsvU32Para19 to 20 (0000 0000 0000 0000 0000
0000 0001 0100) and the value of RsvU32Para19 is now 20. Then run the following
command to set the value of RsvU32Para19 to 20:
SET UALGORSVPARA: RsvU32Para19= 20;

DTS: DTS2014091007315
Feature ID
None
4.2.2.3 Optimized Distance-based Access Control

Description
Distance-based Access Control gives operators precise control over a NodeB's coverage area
within a specified range and the ability to terminate service provision for out-of-range UEs in
special scenarios.
Implementation
1.
If the distance between a UE and the NodeB is beyond a specified range, the UE is
considered as an out-of-range UE under the following conditions:
The Distance-based Access Control algorithm is enabled.

RESERVED_SWITCH_0_BIT5 under the RsvSwitch0 parameter in the ADD
UCELLCOALGOENHPARA command controls whether to enable the Distancebased Access Control algorithm. By default, this algorithm is disabled (default value:
0) for both new networks and upgrade scenarios.
The propagation delay of the UE is greater than the propagation delay threshold for
access control.
This threshold is controlled by bits 0-11 under the RsvU32Para10 parameter in the
SET UCELLALGORSVPARA command. For this parameter, the GUI value range
is from 0 to 3072, the actual value range is from 0.25 to 768, and the recommended
value is 120. By default, this parameter is set to 0 for both new networks and upgrade
scenarios. In special scenarios, this parameter should be set to 120.
The propagation delay of a UE reflects the distance from the UE to the NodeB. The
NodeB can calculate the propagation delay to evaluate the distance whenever the UE
sends messages (for example, RRC CONNECTION REQUEST and CELL UPDATE
Issue 01 (2014-12-31)

Copyright Huawei
113
BSC6900 UMTS
Release Notes

V900R016C00SPC630
messages) over the uplink RACH. The NodeB then reports the obtained propagation
delay in RACH data frames.
Set RsvU32Para10 based on site requirements.
For example, to set bits 0-11 to 960 (0000 0000 0000 0000 0000 0011 1100 0000 in binary), run the
following command:
SET UCELLALGORSVPARA: RsvU32Para10 = 960;
2.
The RNC imposes access restrictions on an out-of-range UE in the following scenarios:
The UE sends an RRC CONNECTION REQUEST message.

If the message contains the cause value "Registration" or "Detach", the RNC
continues to process the message in the local cell so that the UE can complete the
registration or detach process.
The RNC directly rejects the message that contains other cause values.
The UE initiates a cell update, a state transition from CELL_FACH to CELL_DCH,

an RAB assignment process, or a short message process.
The RNC does not respond to these processes and directly releases the UE.
3.
After out-of-range UEs are detected, the following reserved counters on the RNC are
measured:
VS.Reserve.Counter31: provides the number of times that the RNC sends an RRC
CONNECTION REJECT message in a cell due to Distance-based Access Control.
VS.Reserve.Counter32: provides the number of times that RRC connections are

released in the best cell due to Distance-based Access Control.
If an RRC connection setup attempt is rejected due to Distance-based Access Control, the attempt and
the rejection are not included in other counters that measure RRC connection setup attempts and
rejections.
If a cell update attempt is rejected due to Distance-based Access Control, the attempt is not included in
other counters that measure cell update attempts.
Distance-based Access Control is not performed on a UE served by the DRNC or a UE in the
CELL_DCH state. Propagation delay of UEs in the CELL_DCH state cannot be obtained in real time,
and therefore, out-of-range UEs cannot be determined accurately.

The RAB assignment success rate decreases when out-of-range UEs initiate two or more of
the preceding processes.
Out-of-range UEs need to periodically retransmit short messages, increasing UE power
consumption.
Impact on NEs
After Distance-based Access Control takes effect, there is a decrease of the RAB assignment
success rate and paging success rate on the core network side.
Impact on Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
114
BSC6900 UMTS
Release Notes

V900R016C00SPC630

None

None

None

None

None

None
Related Operations
Run the following command to enable Distance-based Access Control:
ADD UCELLCOALGOENHPARA: CellId=xxx,
Run the following command to configure the propagation delay threshold for access control:
SET UCELLALGORSVPARA: CellId=xxx, RsvU32Para10=x;
Distance-based Access Control requires that the NodeB reports the propagation delay offset. Therefore,
it is good practice to run the following command to enable the NodeB to report the propagation delay
offset:
SET NODEBALGPARA: PDMEASMSW = ON;

DTS: DTS2014091503386
Feature ID
None
4.2.2.4 Optimization Against State Inconsistency for UEs in

the CELL_FACH State
Description
During a cell update procedure initiated by a UE in the CELL_FACH state, the RNC releases
the UE's RRC connection if it does not receive any response from the UE within a specified
period. However, it is most probably that the UE cannot receive the RRC CONNECTION
Issue 01 (2014-12-31)

Copyright Huawei
115
BSC6900 UMTS
Release Notes

V900R016C00SPC630
RELEASE message from the RNC, and consequently the UE remains in the CELL_FACH
state on the UE side. As a result, the UE's state is inconsistent between the UE and the RNC.
After the algorithm for optimization against the state inconsistency of UEs in the
CELL_FACH state is enabled, the RNC does not immediately release the RRC connection of
a UE in the CELL_FACH state if it does not receive any response from the UE within a
specified period during a cell update procedure.
Implementation
After the algorithm for optimization against the state inconsistency of UEs in CELL_FACH
state is enabled, the RNC does not immediately release the RRC connection of a UE, instead,
it retains the UE in the CELL_FACH state.
UALGORSVPARA command controls whether the RNC retains the UE in the CELL_FACH
state when it does not receive any response from the UE within a specified period during a
cell update procedure. By default, this solution is disabled (default value: 0) for both new
networks and upgrade scenarios. If this solution is enabled, the RNC retains the UE in the
CELL_FACH state. If this solution is disabled, the RNC releases the UE's RRC connection if
it does not receive any response from the UE within a specified period during a cell update
procedure.
RESERVED_SWITCH_BIT17 under the RsvSwitch parameter in the ADD UIMEITAC
command to controls whether to enable the algorithm for optimization against the state
inconsistency of UEs in the CELL_FACH state. By default, this algorithm is disabled (default
value: 0) for both new networks and upgrade scenarios. If this solution is enabled, the
algorithm does not take effect. If this solution is disabled, the algorithm takes effect.
ADD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=xxxxxxxx,
Description="xxxx", RsvSwitch=RESERVED_SWITCH_BIT17-1;
ADD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=xxxxxxxx,
Description="xxxx", RsvSwitch=RESERVED_SWITCH_BIT17-0;
This algorithm works together with the algorithm for optimizing the time of sending the
MEASUREMENT CONTROL message.

UEs stay in the CELL_FACH state for a longer time.
The number of UEs in the CELL_FACH state increases, which may aggravate FACH
congestion and increase the number of times UEs re-access the network. Specifically, values
of the following counters increases:
VS.CellFACHUEs
Issue 01 (2014-12-31)

Copyright Huawei
116
BSC6900 UMTS
Release Notes

V900R016C00SPC630
VS.FACH.DCCH.CONG.TIME
VS.FACH.DTCH.CONG.TIME
VS.FACH.CCCH.CONG.TIME
VS.RAB.NormRel.PS.UEReEst.CCHRelated
The number of call drops caused by the state consistency between the UE and RNC sides.
Specifically, the value returned by the VS.RAB.AbnormRel.PS counter decreases.
Impact on NEs
None
Impact on Hardware
None

None

None

UALGORSVPARA command controls whether the RNC retains the UE in the
CELL_FACH state when it does not receive any response from the UE within a specified
period during a cell update procedure.

None

None

None
Related Operations
Enabling the function
1.
Check whether the algorithm for optimizing the time of sending the MEASUREMENT
CONTROL message is enabled.
Specifically, check whether RESERVED_SWITCH_11_BIT6 under the RsvSwitch11
parameter in the LST UALGORSVPARA command is set to 1.
If it is set to 1, directly run the SET UALGORSVPARA command to enable the
algorithm for optimization against the state inconsistency of UEs in CELL_FACH state.
If it is set to 0, run the following command before enabling the algorithm for
optimization against the state inconsistency of UEs in CELL_FACH state:
Issue 01 (2014-12-31)

Copyright Huawei
117
BSC6900 UMTS
Release Notes

V900R016C00SPC630
SET UALGORSVPARA: RsvSwitch11=RESERVED_SWITCH_11_BIT6-1

2.
Run the following command to enable the algorithm for optimization against the state
inconsistency of UEs in CELL_FACH state:
3.
Run either of the following commands to configure the IMEI of the UE that does not
support the algorithm for optimization against the state inconsistency of UEs in
CELL_FACH state:
ADD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=XXXXX, RsvSwitch=

MOD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=XXXXX, RsvSwitch=
Disabling the function
1.
Run the following command to disable the algorithm for optimization against the state
inconsistency of UEs in CELL_FACH state:
SET UALGORSVPARA: RsvSwitch10=RESERVED_SWITCH_10_BIT15-0
2.
If the algorithm for optimizing the time of sending the MEASUREMENT CONTROL
message is enabled for UEs in the CELL_FACH state, run the following command to
disable this algorithm:
SET UALGORSVPARA: RsvSwitch11= RESERVED_SWITCH_11_BIT6-0

DTS: DTS2014091303110
Feature ID
WRFD-010801
4.2.2.5 Support for RRC Reestablishment Through a D2P

Procedure
Description
For fast dormancy-capable UEs running a single PS service, if the RNC experiences a TRB
reset or receives a RADIO LINK FAILURE INDICATION message from the NodeB and the
synchronization timer expires, the RNC triggers RRC reestablishment through a CELL_DCH
to CELL_PCH (D2P) procedure.
Implementation
In the preceding scenario, after call reestablishment caused by an RL out-of-synchronization
problem or PS TRB reset is enabled and the switch for RRC reestablishment through a D2P
procedure is turned on, RRC reestablishment through a D2P procedure takes precedence over
call reestablishment, if the best cell is served by the SRNC and no CS signaling message are
transmitted. Specifically, RRC reestablishment through a D2P procedure is preferentially
enabled. After the UE transits to the common channel, the RNC triggers UE state transition to
the DCH based on traffic volume to complete link reestablishment.
This solution does not take effect on UEs with any of the following switches turned on:
Issue 01 (2014-12-31)

Copyright Huawei
118
BSC6900 UMTS
Release Notes

V900R016C00SPC630
FD_TAC_FORCE_D2F_SWITCH (TAC-based D2F Switch for UEs Supporting Fast

Dormancy)
PCH_DISABLED_SWITCH (PCH Inhibition Switch)
SPECUSER_EFACH_DISABLED_SWITCH (EFACH Inhibition Switch)
SPECUSER_ERACH_DISABLED_SWITCH (ERACH Inhibition Switch)
RESERVED_SWITCH_BIT1 (under the RsvSwitch parameter in the ADD UIMEITAC

command, E-FACH or E-RACH D2P Inhibition Switch)

UALGORSVPARA command controls whether to enable this solution. By default, this
solution is disabled (default value: 0) for both new networks and upgrade scenarios. When
this solution takes effect, the RNC triggers RRC reestablishment through a D2P procedure,
not call reestablishment. When this solution does not take effect, the RNC triggers call
reestablishment, not RRC reestablishment through a D2P procedure.
Bits 24 to 31 under the RsvU32Para4 parameter in the SET UALGORSVPARA command
jointly specify the length of the timer to wait for radio link restoration before RRC
reestablishment through a D2P procedure is triggered if only one radio link exists.
Set RsvU32Para4 based on the current parameter setting.For example, if the current value of
RsvU32Para4 is 8388608 (0000 0000 1000 0000 0000 0000 0000 0000), set this parameter to
192937984 (0000 1011 1000 0000 0000 0000 0000 0000) with the combined value of bits 24 to 31 set to
11 by running the following command:

The number of D2P state transitions increases (including the number of D2P state transition
attempts and successful D2P state transitions), and the number of call drops or the number of
times the UE re-initiates an RRC connection in a D2P procedure increases. Specifically, the
values returned by the following counters increase:
VS.DCCC.D2P.Att
VS.DCCC.D2P.Succ
VS.RAB.AbnormRel.PS.D2P
VS.RAB.NormRel.PS.UEReEst.CCHRelated
Impact on NEs
None
Impact on Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
119
BSC6900 UMTS
Release Notes

V900R016C00SPC630

None

None

UALGORSVPARA command controls whether the RNC triggers RRC reestablishment
through a D2P procedure.

None

None

None
Related Operations
RESERVED_SWITCH_10_BIT19 is a Huawei advanced parameter. To change the value of one of this
parameter, contact Huawei Customer Service Center for technical support.
Enabling the function (RRC reestablishment through a D2P procedure)

This function depends on call reestablishment caused by an RL out-of-synchronization
problem or PS TRB reset.
Run the following command to enable call reestablishment:
SET URRCTRLSWITCH: PROCESSSWITCH4=PHY_RECFG_REEST_SWITCH-1&
TRB_RESET_RL_REEST_SWITCH-1,
OptimizationSwitch=SRB_RESET_RL_SETUP_SWITCH-1& PS_RL_SETUP_SWITCH1& RLFAIL_RL_SETUP_SWITCH-1& RB_RECFG_RL_REEST_SWITCH-1;
This function depends on D2P procedure optimization.
Run the following command to enable D2P procedure optimization:
After a D2P procedure succeeds, data transmission query for UEs is required if there is data to
transmit at the RLC layer.
Run the following command to enable data transmission query for UEs:
SET URRCTRLSWITCH:
PROCESSSWITCH4=F2P_DATATRANS_OPTIMIZE_SWITCH-1
Before enabling this function, turn on DL_TRB_RESET_BUFF_SWITCH to prevent UEs
from being released due to TRB resets in a D2P procedure.
Issue 01 (2014-12-31)

Copyright Huawei
120
BSC6900 UMTS
Release Notes

V900R016C00SPC630
DL_TRB_RESET_BUFF_SWITCH indicates whether the RNC immediately processes a

TRB RESET message if the corresponding TRB resets when an RRC-related process is in
progress. Note that the RRC-related process is a process that is initiated after the UE in
question has set up a service.
SET URRCTRLSWITCH: PROCESSSWITCH4=DL_TRB_RESET_BUFF_SWITCH-1
Run the following command to enable this function:
This function requires the parameter that specifies the timer to wait for radio link restoration
after the RNC receives a RADIO LINK FAILURE INDICATION message from the NodeB.
For details about parameter settings, see the description of RsvU32Para4 in
Implementation.
Disabling the function (RRC reestablishment through a D2P procedure)
Run the following command to disable this function:

DTS: DTS2014091303110
Feature ID
WRFD-140103
4.2.2.6 Optimization of OMU Disk IO Flow Control

Description
This feature decreases the Input Output (IO) load (read/write load) of the OMU disk and
raises the priority of processing communication messages between the OMU and the host,
thereby improving stability and reliability of the base station controller.
Implementation
This feature includes the following optimizations in OMU disk IO flow control:
1.
IO operations on the OMU are optimized to decrease the average IO load of the OMU
disk. Specifically, the OMU log recording mechanism and the OMU FTP transfer
mechanism are optimized. The optimized mechanisms help decrease the number of IO
operations on the OMU disk, thereby decreasing its IO load.
2.
The self-healing for disk IO overload function is introduced. The Self-healing Switch
for Disk IO Overload parameter in the SET SLFSLVSW command controls whether to
enable this function. By default, this function is disabled (default value: OFF) for both
When the Self-healing Switch for Disk IO Overload parameter is set to ON(On), if the
IO load of the OMU disk exceeds the specified threshold, IO flow control (decreasing
the frequency or speed of the OMU reading or writing the disk) is triggered. The detailed
mechanism is as follows:
Issue 01 (2014-12-31)
When maintenance logs are delivered, the OMU adjusts the buffer size based on the
flow control level to decrease the number of IO operations.
Copyright Huawei
121
BSC6900 UMTS
Release Notes

V900R016C00SPC630
When files are written by running the EXP CFGMML, EXP CFGBCP, RTR DB,
or BKP DB command, the OMU decreases the speed of its reading or writing the
disk to decelerate IO operations.
If the communication between the OMU and the host is abnormal for 15 consecutive
seconds, the OMU preferentially processes the messages between them. When the
communication recovers, the OMU adopts the original processing mechanism.

None
Impact on NEs
None
Impact on Hardware
None

None

None

Added the Self-healing Switch for Disk IO Overload parameter to the SET
SLFSLVSW command.

None

None

None
Related Operations
To enable the self-healing for disk IO overload function, run the following command:
SET SLFSLVSW: SWITCH=ON, DiskIOShSW=ON;
To disable the self-healing for disk IO overload function, run the following command:
SET SLFSLVSW: SWITCH=ON, DiskIOShSW=OFF;

DTS: DTS2014091204930
Issue 01 (2014-12-31)

Copyright Huawei
122
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Feature ID
None

None
4.3 Resolved Issues

4.3.1 Critical
None
4.3.2 Major
None
4.3.2.1 PS BE Service Rate of Incoming Inter-RAT Handover

UEs Are Limited.
Trouble
Ticket
Number
DTS: DTS2014091503200
Description
Condition:
The UE supports the 2 ms TTI and 64 QAM.
The cell supports the 2 ms TTI and 64 QAM.
The maximum uplink rate of PS BE services assigned by the CN is

greater than 2 Mbit/s and the maximum downlink rate is greater than
13.9 Mbit/s.
The Iu QoS negotiation function for PS BE services is enabled on the

RNC side by running the SET UCORRMALGOSWITCH
command with PS_BE_IU_QOS_NEG_SWITCH under the
PsSwitch parameter set to 1.
The strict Iu QoS negotiation function for PS BE services is disabled

on the RNC side by running the SET
UCORRMALGOSWITCHcommand with
PS_BE_STRICT_IU_QOS_NEG_SWITCH under the PsSwitch
parameter set to 0.
The value of the information element (IE) altMaxBitrateType in the

Relocation Request message is "unspecified".
Symptom: After an incoming inter-RAT handover, the PS BE services of

the UE can use the 2 ms TTI and 64 QAM, whereas the maximum
uplink rate is limited to 2 Mbit/s and the maximum downlink rate is
limited to 13.9 Mbit/s.
Impact: After an incoming inter-RAT handover, the PS BE service rate
of the UE is limited and therefore its HSDPA and HSUPA throughputs
are low.
Issue 01 (2014-12-31)

Copyright Huawei
123
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Severity
Major
Root Cause
The RNC incorrectly maintains the maximum rate in the preceding

scenario, which causes the service rate of the incoming inter-RAT
handover UE to be limited.
Solution
The RNC now correctly maintains the maximum rate in the preceding
scenario.
in the SET UALGORSVPARA command is used to control this
SET
UALGORSVPARA:RsvSwitch13=RESERVED_SWITCH_13_BIT231;
SET
Solution
Impact
After this solution takes effect, the HSDPA and HSUPA throughputs
increase.
Test Case
4.3.2.2 Peer AMR UEs are muted after the call

reestablishment when the AMRC feature is activated.
Trouble
Ticket
Number
DTS: DTS2014090108150
Description
Condition:
1. The AMR rate control (AMRC) feature is activated.
2. The TrFO function takes effect.
3. In the AMR service call process, if the downlink rate of the peer UE
is reduced through RB reconfiguration due to factors such as
resource optimization, the local UE must be notified to perform
uplink rate reduction. After the uplink rate reduction of the local UE
is complete, cell update and call reestablishment occur.
NOTE
For details about how to activate the AMRC feature, see AMR Feature
Parameter Description.
TFO/TrFO indicates Transcoder Free Operation, which must be supported by

the CN. For related parameter settings, see AMR Feature Parameter
Description.
Symptom: The peer UE is muted.

Impact: The AMR service voice quality deteriorates and therefore user
experience deteriorates.
Issue 01 (2014-12-31)

Copyright Huawei
124
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Severity
Major
Root Cause
In the preceding scenario, after the uplink rate reduction for the local UE
is complete, the local UE experiences cell update and call
reestablishment. However, the CELL UPDATE CONFIRM message sent
by the RNC to the local UE does not carry the transport format indicator
(TFI) of the reduced uplink rate. Then the local UE sends data at the
maximum uplink rate, which is greater than the downlink rate of the peer
UE. As a result, the peer UE is muted.
Solution
In the preceding scenario, the CELL UPDATE CONFIRM message sent

by the RNC to the local UE carries the TFI of the reduced AMR service
uplink rate. This ensures that the local UE sends data based on the
reduced uplink rate after its cell update is complete, thereby preventing
the peer UE from being muted.
SET
SET
Solution
Impact
After this solution is used, user experience improves.
Test Case
4.3.2.3 Peer UEs are muted because local UEs have not
received the TFC CTRL message.
Trouble
Ticket
Number
DTS: DTS2014090307256
Description
Condition:
1. The AMR rate control (AMRC) feature is activated.
2. The TrFO function takes effect.
3. In the AMR service call process, if the downlink rate of the peer UE
is reduced through RB reconfiguration due to factors such as
resource optimization, the local UE must be notified to perform
uplink rate reduction.
NOTE
Issue 01 (2014-12-31)

Copyright Huawei
125
BSC6900 UMTS
Release Notes

V900R016C00SPC630
TFO/TrFO indicates Transcoder Free Operation, which must be

supported by the CN. For related parameter settings, see AMR
Feature Parameter Description.
Symptom: After the downlink rate of the peer UE is reduced, the peer
UE is muted.
Impact: The AMR service voice quality deteriorates and therefore user
experience deteriorates.
Severity
Major
Root Cause
In the preceding scenario, when the local RNC is about to perform

uplink rate reduction for the local UE, the RNC sends a TFC CTRL
(TRANSPORT FORMAT COMBINATION CONTROL) message to the
UE. The UE does not receive the TFC CTRL message and therefore does
not perform uplink rate adjustment, nor gives any response. However,
the RNC considers the local UE rate reduction successful and notifies
the peer RNC of the successful uplink rate adjustment. After the peer
RNC receives the message of the successful rate adjustment, the peer
RNC reconfigures its downlink maximum rate for the peer UE. As a
result, the downlink rate of the peer UE is lower than the uplink rate of
the local UE, causing the peer UE to be muted.
Solution
In the preceding scenario, after the RNC sends the UE a TFC CTRL
message, there are the following cases:
If L3 receives a confirmation from the L2 RLC layer, the RNC starts

the TFC CTRL FAIL (TRANSPORT FORMAT COMBINATION
CONTROL FAILURE) message waiting timer. If the RNC does not
receive the TFC CTRL FAIL message before the timer expires, the
RNC considers the UE uplink rate adjustment successful.
If L3 does not receive a confirmation from the L2 RLC layer or the

UE responds with a TFC CTRL FAIL message, the RNC considers
the UE uplink rate adjustment failed.

SET
SET
RsvU8Para21 in the RNC-level command SET UALGORSVPARA is
used to set the length of the timer for the RNC to receive the TFC CTRL
FAIL message. If this parameter is set to 0, the duration specified by the
timer is 50 ms. GUI Value Range: 0 to 255. Unit: 10 ms. Recommended
value: 5. Actual value range: 10 ms to 2550 ms. By default, this
parameter is set to 0 for both new networks and upgrade scenarios.
To set the length of the timer for the RNC to receive the TFC CTRL
Issue 01 (2014-12-31)

Copyright Huawei
126
BSC6900 UMTS
Release Notes

V900R016C00SPC630
FAIL message to xxx (unit:10 ms), run the following command:

SET UALGORSVPARA: RsvU8Para21=xxx;
Solution
Impact
The AMR service voice quality and user experience are improved.
Test Case
4.3.2.4 AMR voice quality deteriorates when the protocol

CR0125 takes effect.
Trouble
Ticket
Number
DTS: DTS2014090207507
Description
Condition:
1.
2.
3.
4.
The AMR rate control (AMRC) feature is activated.

The TFO/TrFO function takes effect.
The protocol CR0125 takes effect.
In the AMR service call process, if the AMR service downlink rate of
the peer UE is reduced due to factors such as resource optimization,
the local UE must be notified to perform uplink rate reduction.
5. The current downlink rate of the local RNC is lower than the
maximum uplink rate of the peer RNC and the maximum downlink
rate of the local RNC is higher than or equal to the maximum uplink
rate of the peer RNC.
NOTE
TFO/TrFO indicates Transcoder Free Operation, which must be

supported by the CN. For related parameter settings, see AMR
Switch3GPP25415CR0125 under the 3GPP25415CR0125 parameter

in the ADD UCNNODE or MOD UCNNODE command is used to
set the protocol CR0125.
Symptom: The peer RNC performs rate reduction for uplink AMR
services and the number of the TFC CTRL (TRANSPORT
FORMATCOMBINATION CONTROL) messages increases.
Impact: After the AMR service rate reduction, the voice quality
deteriorates and the number of uplink rate adjustments by the peer RNC
as well as the AMR call drops increase.
Severity
Major
Root Cause
In the preceding scenario, after the local RNC successfully performs the
uplink rate reduction and the protocol CR0125 takes effect, the Rate
Control ACK message sent by the local RNC to the CN carries the
current downlink rate of the local RNC instead of the maximum
downlink rate of the local RNC, causing the peer RNC to initiate uplink
rate reduction.
Issue 01 (2014-12-31)

Copyright Huawei
127
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Solution
In the preceding scenario, the Rate Control ACK message sent by the
local RNC to the CN carries the local maximum downlink rate, which is
then sent to the peer RNC.
SET
SET
Solution
Impact
After the AMR service rate reduction, voice quality improves and the
number of uplink rate reductions by the peer RNC as well as the AMR
call drops decrease.
Test Case
4.3.2.5 The value of VS.IRATHO.FailOutPS.UEGen is

incorrect.
Trouble
Ticket
Number
iCare: 2974759
Description
Condition: In the CS+PS service scenario, a UE is handed over from the

UMTS network to the GSM network during a CS inter-RAT handover.
After the CS handover is complete, the UE is then handed over to the
UMTS network and initiates an RRC connection setup request before the
RNC receives the IU RELEASE COMMAND message from the core
network (CN) in the PS domain.
DTS: DTS2014091302099
Symptom: The value of VS.IRATHO.FailOutPS.UEGen is greater than

the actual value.
Impact: The value of VS.IRATHO.FailOutPS.UEGen is incorrect.
Severity
Major
Root Cause
VS.IRATHO.FailOutPS.UEGen should not be measured in this scenario.
Solution
VS.IRATHO.FailOutPS.UEGen is now measured only during PS interRAT handovers.
Solution
Impact
The value of VS.IRATHO.FailOutPS.UEGen decreases.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
128
BSC6900 UMTS
Release Notes

V900R016C00SPC630
4.3.2.6 Values returned by counters related to the uplink

BLER of PS R99 services are greater than expected.
Trouble
Ticket
Number
iCare: 3225445
Description
Condition: A UE establishes PS R99 services and then one of the

following two scenarios occurs:
DTS: DTS2014091302224
Scenario 1: The UE transits from the CELL_FACH state to the

CELL_DCH state or from the CELL_DCH state to the CELL_FACH
state.
Scenario 2: Soft handovers are triggered, and there are multiple radio
links (RLs).
Symptom: Values returned by the following counters related to the

uplink block error rate (BLER) of PS R99 services are greater than
expected:
VS.ULBler.PS.BE.DCH.8
Impact: Values returned by the preceding counters are inaccurate.

Severity
Major
Root Cause
Scenario 1: During the state transition, after receiving the RADIO

BEARER RECONFIGURATION message from the RNC, the UE does
not send data packages (including the RADIO BEARER
RECONFIGURATION COMPLETE message) to the RNC. However,
the RNC receives CRCI check error packages from the NodeB, and
these packages are incorrectly measured by counters related to the uplink
BLER of PS R99 services on the RNC. CRCI is short for Cyclic
Redundancy Checksum Indicator.
Scenario 2: During soft handovers, the UE does not send data packages
to the RNC. However, the RNC receives CRCI check error packages
from the NodeB on one RL, and these packages are incorrectly measured
by counters related to the uplink BLER of PS R99 services on the RNC.
Solution

of the SET UALGORSVPARA command controls whether to prevent
CRCI check error packages from being measured by counters related to
the uplink BLER of PS R99 services on the RNC in the preceding
scenarios. By default, this solution is disabled (default value: 0) for both
When this solution is enabled, CRCI check error packages are prevented
from being measured by counters related to the uplink BLER of PS R99
services on the RNC. When this solution is disabled, CRCI check error
Issue 01 (2014-12-31)

Copyright Huawei
129
BSC6900 UMTS
Release Notes

V900R016C00SPC630
packages are measured by counters related to the uplink BLER of PS

R99 services on the RNC.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
Values returned by the preceding counters decrease.
Test Case
4.3.2.7 Call drops occur if SRB over HSDPA or SRB over HSPA
is enabled.
Trouble
Ticket
Number
iCare: 3355970
Description
Condition: SRB over HSDPA or SRB over HSPA is enabled on the

RNC, and a UE transits from the CELL_PCH or URA_PCH state to the
CELL_DCH state and then to the CELL_DCH state.
DTS: DTS2014091302244
Symptom: The UE is abnormally released.

Impact: The PS service drop rate and CS call drop rate increase.
Severity
Major
Root Cause
After the UE transits from the CELL_PCH or URA_PCH state to the

CELL_DCH state, the RNC does not obtain the connection frame
number (CFN) of the HS-DSCH which the SRB is mapped to. As a
result, the CFN on the RNC is different from that on the UE and NodeB.
The CFN on the RNC is smaller than that on the UE and NodeB. In this
situation, when the UE transits from the CELL_DCH state to the
CELL_DCH state, the activation time of the UE is reached earlier than
that on the RNC and the UE sends the RNC the RADIO BEARER
RECONFIGURATION COMPLETE message. Upon receiving this
message, the RNC releases the code resources. However, the NodeB
does not release the codes. If the RNC assigns the released codes to new
UEs, the NodeB experiences code conflicts, causing the RNC to release
the UE that originally occupy the codes.
Solution

solution.
When this solution is enabled, the RNC obtains the CFN of the HSDSCH which the SRB is mapped to after the UE transits from the
Issue 01 (2014-12-31)

Copyright Huawei
130
BSC6900 UMTS
Release Notes

V900R016C00SPC630
CELL_PCH or URA_PCH state to the CELL_DCH state.

When this solution is disabled, the RNC does not obtain the CFN of the
HS-DSCH which the SRB is mapped to after the UE transits from the
CELL_PCH or URA_PCH state to the CELL_DCH state.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The PS service drop rate and CS call drop rate decrease.
Test Case
4.3.2.8 The number of RAB setup attempts for HSPA

services are incorrectly counted as that for R99 services.
Trouble
Ticket
Number
iCare: 2697042
Description
Condition: When RAB_SETUP_CNT_CORRECT_SWITCH under

the ImprovementSwitch parameter in the SET URRCTRLSWITCH
command is ON, a procedure for radio link reestablishment triggered by
RAB setup fails or a concurrent procedure for RAB setup and cell
update fails for HSPA services. Detailed scenarios are described as
follows:
DTS: DTS2014091302212
Scenario 1: During a RAB setup procedure where a UE remains in the

CELL_DCH state, the RNC does not receive a response to the
RADIO BEARER SETUP message from the UE within a specified
period. The RNC then triggers radio link reestablishment but the
radio link reestablishment fails.
Scenario 2: During an RAB setup procedure where a UE remains in

the CELL_DCH state, the RNC does not receive a response to the
RADIO BEARER SETUP message from the UE within a specified
period but receives a cell update message with the cause value "radio
link failure" or "RLC Unrecoverable error", and the cell update fails.
Scenario 3: During an RAB setup procedure where a UE transits from

the CELL_FACH state to the CELL_DCH state, the RNC receives a
cell update message with the cause value "cell reselection" after
sending the UE a RADIO BEARER SETUP message. However, the
cell update fails.
Symptom: The values returned by VS.HSDPA.RAB.AttEstab and

VS.HSUPA.RAB.AttEstab are less than expected. The value returned by
VS.RAB.AttEstab.PSR99 is greater than expected. The HSDPA RAB
setup success rate and HSUPA RAB setup success rate are greater than
expected, and the PS R99 RAB setup success rate is less than expected.
Issue 01 (2014-12-31)

Copyright Huawei
131
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Impact: The values returned by VS.HSDPA.RAB.AttEstab,

VS.HSUPA.RAB.AttEstab, and VS.RAB.AttEstab.PSR99 are incorrect.
The HSDPA RAB setup success rate, the HSUPA RAB setup success
rate, and the PS R99 RAB setup success rate are inaccurate.
NOTE
HSPA services include HSDPA and HSUPA services.
Severity
Major
Root Cause
When a radio link reestablishment procedure starts or the RNC

simultaneously processes a RAB setup and a cell update, the RNC does
not save the information about uplink and downlink transport channels
that carry services during the RAB setup. Consequently, the number of
RAB setup attempts for HSPA services are incorrectly counted as that
for R99 services.
Solution

in the SET UALGORSVPARA command controls whether the RNC
correctly measures VS.HSDPA.RAB.AttEstab and
VS.HSUPA.RAB.AttEstab. By default, this solution is disabled(default
value:0) for both new networks and upgrade scenarios.
When this solution is enabled, the number of RAB setup attempts for
HSPA services is counted into VS.HSDPA.RAB.AttEstab and
VS.HSUPA.RAB.AttEstab. When this solution is disabled, the number
of RAB setup attempts for HSPA services is counted into
VS.RAB.AttEstab.PSR99.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The values returned by VS.HSDPA.RAB.AttEstab and

VS.HSUPA.RAB.AttEstab increase, and the value returned by
VS.RAB.AttEstab.PSR99 decreases.
The HSDPA RAB setup success rate and HSUPA RAB setup success
rate decrease, and the PS R99 RAB setup success rate increases.
Test Case
4.3.2.9 An SAAL link cannot be established after it is

removed and then added again.
Trouble
Ticket
Number
iCare: 3415389
Description
Condition: Run the RMV SAALLNK and ADD SAALLNK

commands in sequence to remove and then add an SAAL link. In
addition, the added and removed SAAL links are distributed on the same
Issue 01 (2014-12-31)
DTS: DTS2014091200333

Copyright Huawei
132
BSC6900 UMTS
Release Notes

V900R016C00SPC630
XPU subsystem.
Symptom: After the ADD SAALLNK command is executed, the SAAL
link cannot be established.
Impact: The SAAL link may fail to be established.
Severity
Major
Root Cause
When the SCU delivers a message for removing the SAAL link to the
XPU, random values are included in the removed message. As a result,
the SAAL link configuration information on the XPU is not removed as
expected.
Solution
Correct values are now included in the message for removing an SAAL
link when the SCU sends the message to the XPU.
Solution
Impact
None
Test Case
4.3.2.10 An AOUa board may reset in some scenarios.

Trouble
Ticket
Number
DTS: DTS2014101602190
Description
Condition: When optical ports 0 and 1 on an AOUa board carry

services, one of the following conditions is met:
The ACT LICENSE command is executed to activate the license for a

new RNC. The license control item Overbooking on ATM
Transmission is disabled.
The value of the license control item Overbooking on ATM

Transmission is changed in the RNC license by running the ACT
LICENSE command.
A cross-R version upgrade is performed and the license control item

Overbooking on ATM Transmission is disabled. After the upgrade,
the problem may occur.
The MOD IMAGRP, ADD IMALNK, RMV IMALNK, MOD

ATMLOGICPORT, or MOD UNILNK command is executed for
objects on optical port 1 on an AOUa board. In addition, these
objects have upper-level bearers, such as SAAL links and AAL2
paths.
Symptom: The AOUa board resets to perform self-healing.

Impact: Services on the AOUa board are interrupted for 3 min to 6 min
during the board reset.
Severity
Major
Root Cause
The internal bandwidth is incorrectly calculated when the transmission

bandwidth of optical ports on the RNC is updated in the preceding
scenarios.
Issue 01 (2014-12-31)

Copyright Huawei
133
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Solution
A correct internal bandwidth is now used to update the transmission

bandwidth of optical ports in the preceding scenarios.
Solution
Impact
None
Test Case
4.3.3 Minor
None
4.3.3.1 The HSUPA throughput rises slowly if a DRD

procedure is triggered during service reconfiguration.
Trouble
Ticket
Number
DTS: DTS2014091007315
Description
Condition: The CMP_DRD_SRBOVERH_SWITCH and

CMP_RBCFG_DRD_SRBOVERH_SWITCH are turned on and a
DRD procedure is triggered during service reconfiguration.
Symptom: The HSUPA throughput reaches the peak value about five
seconds after service reconfiguration is complete.
Impact: The HSUPA throughput rises slowly.
Severity
Minor
Root Cause
A DRD procedure is triggered during service reconfiguration and SRBs

are carried over the DCH. The SRBs are reconfigured to an HSPA
channel five seconds after service reconfiguration is complete because
the ChannelRetryTimerLen parameter is set to the default value 5s,
which causes the slow rise in the HSUPA throughput.
Solution
In the preceding scenario, if the condition for SRB channel retries is met
after a DRD procedure is triggered during service reconfiguration, the
RNC starts the fast SRB channel retry timer. After the timer expires, the
SRBs are reconfigured to an HSPA channel. The length of the fast SRB
channel retry timer is specified by the SrbFastHRetryTimerLen
parameter.
SET UALGORSVPARA:
SET UALGORSVPARA:
Issue 01 (2014-12-31)

Copyright Huawei
134
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Solution
Impact
The HSUPA throughput increases.
Test Case
4.3.3.2 The SAI-based location fails because the RNC sends

an SAI-based location report to the CN during the UE
relocation process.
Trouble
Ticket
Number
DTS: DTS2014091302887
Description
Condition: After the core network (CN) allocates relocation resources,

the CN sends the DRNC a LOCATION REPORTING CONTROL
message in which IE "Event" is Change of Service Area and IE "Report
Area" is Service Area. IE stands for information element.
Symptom: The DRNC sends a service area identifier-based (SAI-based)
location report to the CN, but the CN does not handle this report.
Impact: The SAI-based location fails.
Severity
Minor
Root Cause
If the CN receives an SAI-based location report before a UE relocation

process completes, the CN considers this report to be unreliable and does
not handle this report.
Solution
The RNC now sends the SAI-based location report only after a UE
relocation process completes.
RESERVED_SWITCH_11_BIT9 of the RsvSwitch11 parameter in the
SET UALGORSVPARA command is now used to control whether this
solution takes effect. By default, this solution is disabled (default value:
SETUALGORSVPARA:RsvSwitch11=RESERVED_SWITCH_11_BI
T9-1;
T9-0;
Solution
Impact
During the UE relocation process, the RNC does not send the CN SAIbased location reports in a timely manner, and therefore SAI update is
delayed.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
135
BSC6900 UMTS
Release Notes

V900R016C00SPC630
4.3.3.3 The CS service is abnormally released in the case of

CS+PS combined services
Trouble
Ticket
Number
iCare: 2587193
Description
Condition: In the case of CS+PS combined services, when the DRNC is

handling the RADIO LINK RECONFIGURATION PREPARE message
received from the SRNC, the SRNC sends the DRNC a RADIO LINK
RECONFIGURATION CANCEL message after receiving a
SIGNALLING CONNECTION RELEASE INDICATION message
from a UE. Then the SRNC sends the DRNC a second RADIO LINK
RECONFIGURATION PREPARE message when the SRNC releases the
PS service.
DTS: DTS2014091302065
Symptom: The DRNC does not handle the second RADIO LINK
RECONFIGURATION PREPARE message, and therefore the SRNC
does not receive any response from the DRNC within the specified
period.
Impact: The SRNC abnormally releases the CS service.
Severity
Minor
Root Cause
In the preceding scenario, the DRNC does not buffer the second RADIO
LINK RECONFIGURATION PREPARE message when it is handling
the first same one. Consequently, the second RADIO LINK
RECONFIGURATION PREPARE message is not handled.
Solution

in the SET UALGORSVPARA command controls whether the DRNC
buffers the second RADIO LINK RECONFIGURATION PREPARE
message when it is handling the first same one. By default, this solution
is disabled (default value: 0) for both new networks and upgrade
scenarios.
When this solution is enabled, the DRNC buffers the second RADIO
LINK RECONFIGURATION PREPARE message. When this solution is
disabled, the DRNC does not handle the second RADIO LINK
RECONFIGURATION PREPARE message.
SET
SET
Solution
Impact
The CS service drop rate decreases.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
136
BSC6900 UMTS
Release Notes

V900R016C00SPC630
4.3.3.4 ALM-22206 UMTS Cell Setup Failed is reported again

at 03:00 a.m..
Trouble
Ticket
Number
iCare: 3611343
Description
Condition: The ALM-22206 UMTS Cell Setup Failed alarm is reported

and the alarm cause is not "Data configuration error or inconsistent with
physical resources".
DTS: DTS2014101001132
Symptom: ALM-22206 UMTS Cell Setup Failed is reported again at

03:00 a.m..
Impact: none
Severity
Minor
Root Cause
When the NodeB control is checked at 03:00 a.m., all cells in the RNC
require auditing of NodeBs no matter whether the NodeB control has
changed, and cell auditing waiting timers are started. The RNC performs
audit on NodeBs in a discrete manner. As a result, the RNC has not
performed audit on NodeBs to which some cells belong when the cell
auditing waiting timers for these cells expire. In this case, if a cell has
not been established, ALM-22206 UMTS Cell Setup Failed will be
reported with the alarm cause "Data configuration error or inconsistent
with physical resources".
If ALM-22206 UMTS Cell Setup Failed with a cause value other than
"Data configuration error or inconsistent with physical resources"
already exists, the RNC will clear the alarm first and then report the
alarm with the new cause value. Therefore, this alarm is reported again.
Solution
At 03:00 a.m., only cells controlled by NodeBs whose NodeB control

has changed require NodeB auditing.
Lengths of cell auditing waiting timers are corrected to ensure that

NodeBs of all cells can be audited within the timer duration.
Solution
Impact
None
Test Case
4.3.3.5 The UE transmit power increases due to AMR service

reconfiguration in AMR+PS combined service scenarios.
Trouble
Ticket
Number
DTS: DTS2014090900126
Description
Condition:
1. The service type is AMR+PS combined services.
2. After the AMR service reconfiguration, the maximum rate of the
AMR service is lower than that of the PS service.
Issue 01 (2014-12-31)

Copyright Huawei
137
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Symptom: In the preceding scenario, the value of bd/bc in the RADIO

BEARER RECONFIGURATION message during AMR service
reconfiguration is smaller than that in the RADIO BEARER SETUP
message during AMR service setup.
NOTE
For details about bc and bd, see 3GPP TS 25.214.
Impact: In the preceding scenario, the UE transmit power increases and

the cell uplink capacity decreases.
Severity
Minor
Root Cause
Before the AMR service reconfiguration, the maximum rate of the AMR
service is higher that of the PS service, and the bc and bd used by the UE
are obtained based on the reference bc and reference bd in the typical
parameters for the AMR service. After the AMR service reconfiguration,
the maximum rate of the AMR service is lower than that of the PS
service, and the bc and bd used by the UE are obtained based on the
reference bc and reference bd in the typical parameters for the PS service.
After the AMR service reconfiguration, the value of bd/bc decreases.
When the uplink DPDCH power remains unchanged, the uplink DPCCH
power increases and therefore the UE total transmit power increases. As
a result, the cell uplink capacity decreases.
NOTE
In the typical parameter setting (see MML command ADD UTYPRABBASIC or
MOD UTYPRABBASIC), there exists only the 12.2 kbit/s bc and 12.2 kbit/s bd
for the AMR-NB service and there exists only the 23.85 kbit/s bc and 23.85 kbit/s
bd for the AMR-WB service.
Solution
In the preceding scenario, when the AMR+PS combined service selects

reference bc and reference bd, the maximum rate of the AMR-NB service
is 12.2 kbit/s compared with the maximum rate of the PS service,
whereas the maximum rate of the AMR-WB service is 23.85 kbit/s
compared with the maximum rate of the PS service.
Solution
Impact
In the preceding scenario, the cell uplink capacity improves, especially

the cells with a large number of AMR-NB 12.28 kbit/s+PS 8 kbit/s or
AMR-WB 23.85 kbit/s+PS 16 kbit/s combined services. In addition, the
value of the counter VS.MeanRTWP decreases.
Test Case
4.3.3.6 The PS service setup success rate is low.

Trouble
Ticket
Number
DTS: DTS2014101307842
Description
Condition: SRBCHG_DRD_FAST_RB_SETUP_SWITCH under

thePROCESSSWITCH5 parameter in the SET URRCTRLSWITCH
command is set to 1, and RB setups are accompanied by DRDs with
changing SRBs in a RAB setup procedure.
NOTE
SRBCHG_DRD_FAST_RB_SETUP_SWITCH (RB Fast Setup Switch for RB
Issue 01 (2014-12-31)

Copyright Huawei
138
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Setups Accompanied by DRDs with Changing SRBs): Whether to use the RB fast
setup function for RB setups accompanied by DRDs with changing SRBs.
Symptom: In the soft handover procedure, RB setups are accompanied

by DRDs with changing SRBs. Before successfully sending a RADIO
BEARER SETUP message to the UE, the RNC receives a RADIO LINK
RESTORE INDICATION message specific to the soft handover from
the NodeB. As a result, the RADIO BEARER SETUP message fails to
be sent to the UE, and the UE cannot respond to the RNC with a RADIO
BEARER SETUP COMPLETE message.
Impact: The PS service setup success rate decreases.
Severity
Minor
Root Cause
In the preceding scenario, the mechanism for the RNC to manage the
status of the new link (for the DRD procedure) and original links (for the
soft handover) is defective.
Solution
In the preceding scenario, the defective mechanism has been corrected.

As a result, the RADIO BEARER SETUP message is successfully sent
to the UE.
Solution
Impact
The PS service setup success rate increases.
Test Case
4.3.4 Suggestion
None
4.3.4.1 In the case of insufficient HSPA users, CS services

are released when UEs performing CS+PS combined
services experience a combined incoming hard handover
and SRNS relocation.
Trouble
Ticket
Number
DTS: DTS2014091302909
Description
Condition: In the case of insufficient High Speed Packet Access (HSPA)

users, UEs performing CS+PS combined services experience a
combined incoming hard handover and SRNS relocation. Conditions for
PS services to be carried on the E-DCH or HS-DSCH are met.
Symptom: PS services fall back to the DCH. However, CS services are
released.
Impact: User experience is affected.
Severity
Suggestion
Root Cause
When PS services fall back to the DCH, the RNC incorrectly

reestablishes the IuUP entity, causing exceptions at the CS user plane
layer. In this case, the CN sends the IU RELEASE COMMAND
Issue 01 (2014-12-31)

Copyright Huawei
139
BSC6900 UMTS
Release Notes

V900R016C00SPC630
message to release CS services.

Solution
In the preceding scenario, PS services are directly carried on the DCH.

Specifically,
In the uplink, PS services are carried on the DCH when either of the
following conditions apply:
The percentage of remaining High Speed Uplink Packet Access
(HSUPA) users in the target cell is less than or equal to the value of
the SysInBeHsupaToDchThd parameter in the SET UFRC
command. The percentage of remaining HSUPA users is 0 on the
NodeB to which the target cell belongs.
In the downlink, PS services are carried on the DCH when either of

the following conditions apply:
The percentage of remaining High Speed Downlink Packet Access
(HSDPA) users in the target cell is less than or equal to the value of
the SysInBeHsdpaToDchThd parameter in the SET UFRC
command. The percentage of remaining HSDPA users is 0 on the
NodeB to which the target cell belongs.
RESERVED_SWITCH_11_BIT10 of the RsvSwitch11 parameter in

T10-1;
T10-0;
Solution
Impact
The number of times that CS services are interrupted is reduced and user
experience improves.
Test Case
4.3.4.2 UEs experience call drops if the RNC does not

receive an IU RELEASE COMMAND message within a
specified time in specific scenarios.
Trouble
Ticket
Number
DTS: DTS2014091100541
Description
Scenario 1:
Condition: In an automatic reselection to an inter-RAT neighboring cell,
the RNC sends the core network an SRNS CONTEXT RESPONSE
message after receiving an RANAP_SRNS_CONTEXT_REQ message.
Symptom: The RNC does not receive an IU RELEASE COMMAND
message within a specified time.
Issue 01 (2014-12-31)

Copyright Huawei
140
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Impact: The UE is released abnormally.

Scenario 2:
Condition: The RNC initiates a Direct Signaling Connection Reestablishment (DSCR) procedure.
Symptom: The RNC does not receive an IU RELEASE COMMAND
message within a specified time.
Severity
Suggestion
Root Cause
In the preceding scenarios, the RNC sends the core network an IU

RELEASE REQUEST message with the cause value of "TRELOCoverall
expiry".
Solution
Scenario 1:
sends the core network an IU RELEASE REQUEST message with the
cause value of "Normal Release" in the preceding scenario. By default,
upgrade scenarios.
When this solution is enabled, the RNC sends the core network an IU
RELEASE REQUEST message with the cause value of "Normal
Release". When this solution is disabled, the RNC sends the core
network an IU RELEASE REQUEST message with the cause value of
"TRELOCoverall expiry".
SET UALGORSVPARA:
SET UALGORSVPARA:
Scenario 2:
sends the core network an IU RELEASE REQUEST message with the
cause value of "Normal Release" in the preceding scenario. By default,
upgrade scenarios.
When this solution is enabled, the RNC sends the core network an IU
RELEASE REQUEST message with the cause value of "Normal
Release". When this solution is disabled, the RNC sends the core
network an IU RELEASE REQUEST message with the cause value of
"TRELOCoverall expiry".
SET UALGORSVPARA:
Issue 01 (2014-12-31)

Copyright Huawei
141
BSC6900 UMTS
Release Notes

V900R016C00SPC630
SET UALGORSVPARA:
Solution
Impact
This solution decreases the PS call drop rate.
Test Case
4.3.4.3 PS service drops occur after a cell update with SRNS

relocation is complete.
Trouble
Ticket
Number
DTS: DTS2014091100225
Description
Condition: A non-Huawei SRNC initiates a cell update with SRNS

relocation to a Huawei DRNC that has established radio links. After the
relocation is complete, the Huawei DRNC receives a RADIO BEARER
RECONFIGURATION COMPLETE message.
Symptom: PS services are interrupted.
Impact: The PS service drop rate increases.
Severity
Suggestion
Root Cause
The Huawei DRNC abnormally releases UEs.
Solution

in the SET UALGORSVPARA command controls whether the Huawei
RNC releases UEs in the preceding scenario. By default, this solution is
disabled (default value: 0) for both new networks and upgrade scenarios.
When this solution is enabled, the DRNC discards the RADIO BEARER
RECONFIGURATION COMPLETE message, without releasing UEs.
When this solution is disabled, the DRNC releases UEs.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The PS service drop rate decreases.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
142
BSC6900 UMTS
Release Notes

V900R016C00SPC630
4.3.4.4 UEs experience call drops when an automatic link

reestablishment procedure and an inter-RAT cell reselection
procedure are triggered concurrently.
Trouble
Ticket
Number
DTS: DTS2014091100541
Description
Condition: In an automatic link reestablishment procedure, the RNC

receives an SRNS CONTEXT REQUEST message.
Symptom: The RNC does not process the SRNS CONTEXT REQUEST
message but only continues to wait for a response from the UE.
However, the RNC does not receive any response from the UE within a
specified time.
Severity
Suggestion
Root Cause
The RNC does not support concurrent procedures of automatic link

reestablishment and outgoing inter-RAT cell reselection.
Solution

processes the preceding message in an automatic link establishment
procedure. By default, this solution is disabled (default value: 0) for both
When this solution is enabled, the RNC terminates the automatic link
establishment procedure and then processes the preceding message.
When this solution is disabled, the RNC does not process the preceding
message but continues to wait for a response from the UE.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
This solution decreases the PS call drop rate.
Test Case
4.3.4.5 No performance counter provides data rate increase

for 0 kbit/s PS services.
Trouble
Ticket
Number
DTS: DTS2014091705401
Description
Condition: A PS radio access bearer (RAB) is carried on a 0 kbit/s DCH
Issue 01 (2014-12-31)

Copyright Huawei
143
BSC6900 UMTS
Release Notes

V900R016C00SPC630
and the RAB is later reconfigured to an R99 DCH or HSPA channel to

increase the data rate, using an event 4A measurement report.
Symptom: The RNC does not provide any statistics on channel
reconfiguration to increase data rates of 0 kbit/s PS services or cause
values for data rate increase failures.
Impact: The data rate increase for 0 kbit/s PS services cannot be
measured, making it difficult to locate data rate increase failures.
Severity
Suggestion
Root Cause
In the preceding scenario, no counter is designed for such statistics on

the RNC.
Solution
Counters VS.Reserve.Counter34 through VS.Reserve.Counter52 are

now used to measure the number of data rate increase failures for 0
kbit/s PS services.
The counters are denoted as follows:
VS.Reserve.Counter34: provides the number of times of failed rate
increase reconfiguration for 0 kbit/s PS services over DCH for a cell
due to congestion.

increase reconfiguration for 0 kbit/s PS services over DCH for a cell due
to uplink CE congestion.
to downlink CE congestion.
to code congestion.
to uplink power congestion.
to downlink power congestion.
to downlink Iub bandwidth congestion.
to uplink Iub bandwidth congestion.
because the maximum number of HSUPA UEs is reached.
because the maximum number of HSDPA UEs is reached.
to invalid UE configurations during the RB reconfiguration procedure.
Issue 01 (2014-12-31)

Copyright Huawei
144
BSC6900 UMTS
Release Notes

V900R016C00SPC630

to the absence of a UE response during the RB reconfiguration
procedure.
to UE Uu-interface configuration failures during the RB reconfiguration
procedure.
to signaling Radio Link Control (RLC) resets during the RB
reconfiguration procedure.
to the operation of concurrent procedures during the RB reconfiguration
procedure.
to configurations not supported by UEs during the RB reconfiguration
procedure.
to physical channel failures during the RB reconfiguration procedure.
to radio link configuration failures during the RB reconfiguration
procedure.
to Iub transport bearer establishment failures during the RB
reconfiguration procedure.
Counters VS.Reserve.Counter53 through VS.Reserve.Counter60 are

now used to measure the number of HSPA and HSPA+
reconfiguration attempts to for increasing the data rate and the
number of times of successful HSPA and HSPA+ reconfiguration.
The counters are denoted as follows:
VS.Reserve.Counter53: provides the number of attempts to reconfigure

the downlink channel to HS-DSCH for 0 kbit/s PS services over DCH
for a cell.
the uplink channel to E-DCH for 0 kbit/s PS services over DCH for a
cell.
the downlink channel to DC HS-DSCH for 0 kbit/s PS services over
DCH for a cell.
VS.Reserve.Counter56: provides the number of times the downlink
channel is successfully reconfigured to HS-DSCH for 0 kbit/s PS
services over DCH for a cell.
VS.Reserve.Counter57: provides the number of times the uplink channel
is successfully reconfigured to E-DCH for 0 kbit/s PS services over
Issue 01 (2014-12-31)

Copyright Huawei
145
BSC6900 UMTS
Release Notes

V900R016C00SPC630
DCH for a cell.

channel is successfully reconfigured to DC HS-DSCH for 0 kbit/s PS
services over DCH for a cell.
the downlink channel to HS-DSCH (64QAM) for 0 kbit/s PS services
over DCH for a cell.
channel is successfully reconfigured to HS-DSCH (64QAM) for 0 kbit/s
PS services over DCH for a cell.
Solution
Impact
The preceding counters have been added.
Test Case
4.3.4.6 In the single-signaling scenario where DRNC links

exist, new PS services fail to be established in an E-DCH-toDCH SRB fallback procedure.
Trouble
Ticket
Number
DTS: DTS2014090901203
Description
Condition: PERFENH_SRB_OVER_HSUPA_TTI10_SWITCH
under the PerfEnhanceSwitch parameter in the SET UCORRMPARA
command is set to 1 (enabled), and new PS services fail to be established
in an E-DCH-to-DCH SRB fallback procedure in the single-signaling
scenario where DRNC links exist.
Symptom: The PS service fails to be set up.
Impact: The PS service setup success rate decreases.
Severity
Suggestion
Root Cause
In the preceding scenario, the SRNC sends the DRNC the Radio Link
Reconfiguration Prepare message containing incorrect information,
leading to service setup failures.
Solution

both new networks and upgrade scenarios. When this solution is
enabled, the SRNC sends the DRNC the Radio Link Reconfiguration
Prepare message with correct information contained. When this solution
is disabled, the original method is applied.
SET UALGORSVPARA:
SET UALGORSVPARA:
Issue 01 (2014-12-31)

Copyright Huawei
146
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Solution
Impact
The PS service setup success rate increases within the RNC boundaries.
Test Case
4.3.4.7 A moving UE in the connected state cannot update

the RA or LA.
Trouble
Ticket
Number
DTS: DTS2014091503802
Description
Condition: The routing area (RA) or location area (LA) is changed

when a UE in the connected state is moving.
Symptom: The UE in the connected state does not update the RA or LA
when the UE moves within the coverage of cells served by an RNC.
Impact: The core network (CN) fails to obtain the RA and LA of the UE
in real time.
Severity
Suggestion
Root Cause
When a UE in the connected state moves from one RA or LA to another,

the IE "CN INFORMATION" in 3GPP-specified Uu interface messages
sent by the RNC to the UE does not contain the RA or LA of the new
cell. As a result, the UE in the connected state does not initiate the RA or
LA update process.
Solution

this solution.
sends a UE a UTRAN Mobility Information message with the IE "CN
INFOMRATION" containing the RA and LA of the target cell if the UE
is in the connected state and moves from one RA or LA to another. When
this solution is disabled, the original method is applied.
SET UALGORSVPARA:
SET UALGORSVPARA:
Issue 01 (2014-12-31)

Copyright Huawei
147
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Solution
Impact
Test Case
The values returned by the following counters increase, and the increase
of the number of 3GPP-specified Uu interface messages leads to an
increase of the PS call drop rate:
VS.IU.RelCmdPS.sum
VS.IU.RelCmdCS.NormRel
VS.RRC.AttConnRel.RNC, VS.RRC.AttConnRel.Norm.RNC
RRC.AttConnRelDCCH.Norm
VS.RAB.NormRel.PS.RNC
VS.RAB.AttEstabPS.Bkg.RNC/VS.RAB.SuccEstabPS.Bkg.RNC
VS.RAB.AttEstabPS.Int.RNC/VS.RAB.SuccEstabPS.Int.RNC
VS.RAB.AttEstabPS.Str.RNC/VS.RAB.SuccEstabPS.Str.RNC
VS.RAB.AttEstabPS.Conv.RNC/VS.RAB.SuccEstabPS.Conv.RNC
VS.RAB.AttEstabPS.Bkg/VS.RAB.SuccEstabPS.Bkg
VS.RAB.AttEstabPS.Int/VS.RAB.SuccEstabPS.Int
VS.RAB.AttEstabPS.Str/VS.RAB.SuccEstabPS.Str
VS.RAB.AttEstabPS.Conv/VS.RAB.SuccEstabPS.Conv
VS.IU.MM.LocUpd.Req/ VS.IU.MM.LocUpd.Acc
VS.IU.GMM.RAU.Req / VS.IU.GMM.RAU.Acc
VS.IU.GMM.PDPAct.Req / VS.IU.GMM.PDPAct.Acc
VS.IU.Auth.Req / VS.IU.Auth.Rsp
VS.IU.SecModeCmd.Num / VS.IU.SecModeCmp.Num
VS.UU.AttSecMode
VS.UU.SuccSecMode
VS.IU.SIG.AttConnEstabCS
VS.IU.SIG.AttConnEstabPS
VS.IU.SCCP.Tx.Con.Req
VS.IU.SCCP.Rx.Con.Succ
4.3.4.8 No counter is provided to measure the number of

times a UE in the CELL_PCH or URA_PCH state re-initiates an
RRC connection setup request.
Trouble
Ticket
Number
DTS: DTS2014091303122
Description
Condition: A UE in the CELL_PCH or URA_PCH state re-initiates an

RRC connection setup request, as shown in the following figure:
Issue 01 (2014-12-31)

Copyright Huawei
148
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Symptom: No counter on the RNC is provided to measure how many

times a UE re-initiates an RRC connection setup request.
Impact: The fault location efficiency is affected.
Severity
Suggestion
Root Cause
In the preceding scenario, there is no counter designed for such statistics

on the RNC.
Solution
The measurement is triggered at point A as shown in the preceding

figure. After receiving an RRC CONNECTION REQUEST message
from a UE, the RNC uses the COMMON ID message sent from the CN
to determine that the UE already has a RAB connection not released, and
then sends the CN an IU RELEASE REQUEST message, with the cause
value of "UE Generated Signalling Connection Release". After that, the
CN sends back the RNC an IU RELEASE COMMAND message, and
then the RNC releases the UE's RAB connection and sends back the CN
an IU RELEASE COMPLETE message. In this case, the RNC measures
VS.Reserve.Counter14 in the best cell the UE camps on when the UE is
initiating a D2P procedure, F2P procedure, P2F procedure, or P2D
procedure or the UE is working in the CELL_PCH or URA_PCH state.
NOTE
D2P: CELL_DCH to CELL_PCH
F2P: CELL_FACH to CELL_PCH
P2F: CELL_PCH to CELL_FACH
P2D: CELL_PCH to CELL_DCH
VS.Reserve.Counter14 on the RNC is now provided to measure the

number of released RABs because a UE re-initiates an RRC connection
setup request.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
149
BSC6900 UMTS
Release Notes

V900R016C00SPC630
4.3.4.9 Downlink code resources of the AMR+PS combined

service cannot be saved.
Trouble
Ticket
Number
DTS: DTS2014101302232
Description
Condition:
1. The maximum rate of the AMR-NB service is less than or equal to
5.9 kbit/s.
2. The type of the combined service is R99 AMR+PS HSDPA or R99
AMR+PS 0 kbit/s service.
3. The downlink code resource-saving mode for the AMR-NB service is
enabled.
NOTE
Both the RNC-level and cell-level switches for the AMR-NB downlink code
resource-saving mode must be enabled.
Turn on the RNC-level switch by running the following command: SET UFRC:
DlSaveCodeResourceSwitch=ON;
Turn on the cell-level switch by running the following command: ADD
UCELLFRC: CellId=xxx, AllowedSaveCodeResource=TRUE;
Symptom: In the preceding scenario, the downlink code resource-saving

mode for the AMR-NB service does not take effect and therefore the
number of downlink codes used by combined services is not reduced.
Impact: Cell code resources are not saved.
Severity
Suggestion
Root Cause
In the preceding scenario, the RNC does not support the downlink code
resource-saving mode for combined services.
Solution
In the preceding scenario, the RNC now supports the downlink code
resource-saving mode for combined services. If the type of the combined
service is R99 AMR+PS HSDPA or R99 AMR+PS 0 kbit/s service, the
downlink code resource-saving mode for the AMR-NB service can still
take effect.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
Issue 01 (2014-12-31)
In the preceding scenario, cell code resources can be saved. The value of
the counter VS.MultRAB.SF256 increases and that of the counter
VS.MultRAB.SF128 decreases.
Copyright Huawei
150
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Test Case
4.3.4.10 A UE abnormally exits from the large

retransmission state at an extremely low rate during the RB
reconfiguration for CS services.
Trouble
Ticket
Number
DTS: DTS2014091808670
Description
Condition:
1. The UE establishes PS HSUPA services and enters the large
retransmission state at an extremely low rate.
2. CS services are established when PS HSUPA services exist.
3. RBs are reconfigured for CS services.
Symptom: The RNC changes the original SIR-Target of the large
retransmission state at an extremely low rate delivered to the NodeB to
that of small data retransmission state at a high rate.
Impact: The UE transmit power increases and the uplink load of the cell
increases.
Severity
Suggestion
Root Cause
In the preceding scenario, the RNC reconfigures the outer loop power
control (OLPC) state for the UE, and therefore the UE exits from the
large retransmission state at an extremely low rate.
Solution
In the preceding scenario, when the RNC initiates an RB reconfiguration

procedure for the CS service, the RNC does not change the OLPC state
of the UE.
Solution
Impact
The UE transmit power decreases and the uplink load of the cell
decreases.
Test Case
4.3.4.11 Data is inconsistent between the active OMU and

the standby OMU after an upgrade.
Trouble
Ticket
Number
DTS:DTS2014100804715
Descriptio
n
Condition: In dual-OMU mode, the BSC is upgraded to BSC6900

V900R016C00SPC620.
Symptom: After the upgrade, the CMP OMUDATA command is
executed to compare the active OMU data and the standby OMU data.
The command output shows that data is inconsistent between the active
OMU and the standby OMU.
Issue 01 (2014-12-31)

Copyright Huawei
151
BSC6900 UMTS
Release Notes

V900R016C00SPC630
Impact: Data is inconsistent between the active OMU and the standby
OMU after the upgrade.
Severity
Suggestion
Root
Cause
In V900R016C00SPC620, a flag is added to the OMU for subsequent

function expansion. The upgrade tool updates the flag to its initial value
during the upgrade. However, the upgrade tool uses different mechanisms
to update the flags on the active and standby OMUs during an upgrade in
dual-OMU mode. As a result, the flag values on the active and standby
OMUs are different, causing data consistency after the upgrade.
Solution
The upgrade tool now uses the same mechanism to update the flags on the
active and standby OMUs in dual-OMU mode.
Solution
Impact
None
Test Case
4.4 Known Issues

4.4.1 Critical
None
4.4.2 Major
None
4.4.3 Minor
None
4.4.4 Suggestion
None
Issue 01 (2014-12-31)

Copyright Huawei
152
BSC6900 UMTS
Release Notes

V900R016C00SPH621
Changes from
V900R016C00SPH621
5.1 Change Summary
unchanged in V900R016C00SPH621.
Hardware
V900R016C00SPH621.
Features
Compared with those in BSC6900 V900R016C00SPC620, no features have been added, one
features have been modified, and no features have been deleted in V900R016C00SPH621.
Resolved Issues
Compared with those in BSC6900 V900R016C00SPC620, no critical issues, no major issues,
no minor issues, and no suggestion-level issues have been resolved in V900R016C00SPH621.
Issue 01 (2014-12-31)

Copyright Huawei
153
BSC6900 UMTS
Release Notes

V900R016C00SPH621
functions remain unchanged in V900R016C00SPH621. For details, see 11.1 MML
functions remain unchanged in V900R016C00SPH621. For details about counter
Fault management
remain unchanged in V900R016C00SPH621. For details about alarm and event changes,
License management
functions remain unchanged in V900R016C00SPH621. For details, see 11.6 License
Changes.
document templates remain unchanged in V900R016C00SPH621. For details, see 5.1.6

performance.
unchanged in BSC6900 V900R016C00SPH621.
5.1.2 Hardware
New Hardware
None
Modified Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
154
BSC6900 UMTS
Release Notes

V900R016C00SPH621
5.1.3 Features
V900R016C00SPC620 to V900R016C00SPH621.
Change type
Feature description
V900R016C00SPH621.xls, or see the V900R016C00SPH621 vs V900R016C00SPC620 sheet
BSC6900 V900R016C00SPH621.

Compared with BSC6900 V900R016C00SPC620, there are no issues resolved in
V900R016C00SPH621.

unchanged in V900R016C00SPH621. For details about configuration management, see 11.1

unchanged in V900R016C00SPH621. For details about counter changes, see 11.5 Counter
Changes.

V900R016C00SPH621. For details about changes to alarms and events, see 11.3 Alarm

Issue 01 (2014-12-31)

Copyright Huawei
155
BSC6900 UMTS
Release Notes

V900R016C00SPH621

5.2 Feature Changes

5.2.1 New Features
None

5.2.2.1 Configuration Script Browsing and Editing by using
the Batch Configuration function of the WebLMT
Description
This feature allows users to browse and edit configuration scripts by using the WebLMT batch
configuration function. Specifically, users can browse MML commands and associated
parameters in configuration scripts, as well as modify the parameters.
Implementation
Some panes are added on the Batch Configuration tab. After importing an *.xml or *.ecf
configuration script by clicking Browse in File Path, a user can browse MML commands and
parameters in the script and modify the parameters as required in XML Browse, as shown in
the following figure.

None
Impact on NEs
None
Issue 01 (2014-12-31)

Copyright Huawei
156
BSC6900 UMTS
Release Notes

V900R016C00SPH621
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
None

DTS: DTS2014091904378
Feature ID
None

None
5.3 Resolved Issues

5.3.1 Critical
None
5.3.2 Major
None
Issue 01 (2014-12-31)

Copyright Huawei
157
BSC6900 UMTS
Release Notes

V900R016C00SPH621
5.3.3 Minor
None
5.3.4 Suggestion
None
5.4 Known Issues

5.4.1 Critical
None
5.4.2 Major
None
5.4.3 Minor
None
5.4.4 Suggestion
None
Issue 01 (2014-12-31)

Copyright Huawei
158
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Changes from
V900R016C00SPC620
6.1 Change Summary
Hardware
V900R016C00SPC620.
Features
Compared with those in BSC6900 V900R016C00SPH609, no features have been added,
fifteen features have been modified, and no features have been deleted in
V900R016C00SPC620.
Resolved Issues
Compared with those in BSC6900 V900R016C00SPH609, no critical issues, 27 major issues,
15 minor issues, and 33 suggestion-level issues have been resolved in V900R016C00SPC620.
Issue 01 (2014-12-31)

Copyright Huawei
159
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Fault management
License management
Changes.

performance.
6.1.2 Hardware
New Hardware
None
Modified Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
160
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.1.3 Features
V900R016C00SPH609 to V900R016C00SPC620.
Change type
Feature description
V900R016C00SPC620.xls, or see the V900R016C00SPC620 vs V900R016C00SPH609 sheet
BSC6900 V900R016C00SPC620.

Issue description
Severity
Solution impact
Parameter control
V900R016C00SPC620.xls, or see the the V900R016C00SPC620 vs V900R016C00SPH609
BSC6900 V900R016C00SPC620.

Issue 01 (2014-12-31)

Copyright Huawei
161
BSC6900 UMTS
Release Notes

V900R016C00SPC620

Changes.

V900R016C00SC620. For details about changes to alarms and events, see 11.3 Alarm

Compared with V900R016C00SPH609, license management functions remain unchanged in
V900R016C00SPC620. For details about license changes, see 11.6 License Changes.

6.2 Feature Changes

6.2.1 New Features
None

6.2.2.1 IP Transmission Path Status Detection over the Iu
and Iur Interfaces on the Backup RNC in RNC in Pool
Scenarios
Description
This feature enables the backup RNC to check the status of IP transmission paths. With this
feature, any transmission faults in the backup RNC can be detected before an RNC
switchover, and therefore users can rectify these faults in a timely manner. This feature
ensures that the transmission on the backup RNC is normal when the RNC in Pool Node
Redundancy or RNC in Pool Load Sharing is enabled.
Implementation
When the RNC in Pool Node Redundancy or RNC in Pool Load Sharing is enabled, if no
service accesses the backup RNC, the destination IP address of the adjacent node whose type
is Iu or Iur cannot be obtained. As a result, the transmission path status of the adjacent node
on the backup RNC side cannot be detected. This feature is introduced to address this
problem. SW26(SwPara26) of Reserved Switch Parameter1 in the SET TNRSVDPARA
command controls whether to enable this feature. By default, this feature is disabled (default
value: OFF) for both new networks and upgrade scenarios.
Issue 01 (2014-12-31)

Copyright Huawei
162
BSC6900 UMTS
Release Notes

V900R016C00SPC620
ON: This feature is enabled and the master RNC synchronizes the destination IP addresses to
the backup RNC. In this situation, the backup RNC detects the IP transmission path status of
the adjacent node whose type is Iu or Iur according to the obtained destination IP address. If
any faults are detected, the backup RNC reports ALM-21392 Adjacent Node IP Address Ping
Failure or ALM-21393 Adjacent Node IP Path Ping Failure. If the packet loss rate is high
during transmission, the backup RNC reports ALM-21394 Transmission Resource Pool Ping
Packet Loss or ALM-21395 Adjacent Node IP Path Excessive Packet Loss Rate.
OFF: This feature is disabled and the master RNC does not synchronize the destination IP
addresses to the backup RNC.

After this feature is enabled and the master RNC synchronizes the destination IP addresses of
adjacent node whose type is Iu or Iur to the backup RNC, the average CPU usage on the
control-plane subsystems increases by up to 0.1%.
Impact on NEs
None
Impact on Hardware
None

None

None

Enabled SW26(SwPara26) of Reserved Switch Parameter1 in the SET
TNRSVDPARA command to control whether to enable this feature.

None

None

None
Related Operations
Issue 01 (2014-12-31)

Copyright Huawei
163
BSC6900 UMTS
Release Notes

V900R016C00SPC620

CR-0000069497
Feature ID
None
6.2.2.2 The POSITION ACTIVATION RESPONSE Message over

the Iu-PC Interface Containing the Value of the Path Loss
Description
The RNC now calculates the path loss and sends the path loss to the stand-alone SMLC (SAS)
through the POSITION ACTIVATION RESPONSE message over the Iu-PC interface.
Implementation
This function works as follows:
1.
The SAS sends the RNC a POSITION ACTIVATION REQUEST message through the
Iu-PC interface, requesting for the measured values of the RSCP, Ec/N0, and path loss.
2.
The RNC delivers an intra-frequency measurement control message to the UE,

instructing the UE to report the preceding measured values. The period of intrafrequency measurement is configurable and the measurement can be performed on cells
in the detected set.
3.
Upon reception of the measured values, the RNC contains the measurement values in the
POSITION ACTIVATION RESPONSE message sent to the SAS. If the UE does not
report the path loss, the RNC calculates the path loss based on the transmit power of the
CPICH and the RSCP value reported by the UE.
This function is implemented by the following switches:
The CMP_IUPC_SUPP_ECNO_PATHLOSS_MEAS_SWITCH under the

CmpSwitch3 parameter in the SET UCORRMALGOSWITCH command controls
whether the RNC calculates the path loss. By default, this switch is disabled (default
value: 0) for both new networks and upgrade scenarios.
The RESERVED_SWITCH_13_BIT2 under the RsvSwitch13 parameter in the SET

UALGORSVPARA command controls whether the UE reports measured values such as
the RSCP, Ec/N0, and path loss to the RNC. By default, this switch is disabled (default
Bits 0 to 3 under the RsvU8Para30 parameter in the SET UALGORSVPARA

command specifies the period of intra-frequency measurement. By default, this switch is
set to 250 ms (value: 0) for both new networks and upgrade scenarios.

None
Issue 01 (2014-12-31)

Copyright Huawei
164
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
To enable this function, run the following commands:
SET UCORRMALGOSWITCH:
CmpSwitch3=CMP_IUPC_SUPP_ECNO_PATHLOSS_MEAS_SWITCH-1;

DTS: DTS2014070813193
Feature ID
None
6.2.2.3 Calibration of the Maximum Downlink Transmit

Power for Special UEs
Description
This function enables the RNC to calibrate the maximum downlink transmit power for UEs of
specified type approval codes (TACs), that is, whether the RNC increments the original
maximum downlink transmit power by a power offset for UEs of specified TACs to increase
Issue 01 (2014-12-31)

Copyright Huawei
165
BSC6900 UMTS
Release Notes

V900R016C00SPC620
the maximum downlink transmit power for these UEs. UEs of specified TACs are referred to
as special UEs in this document.
Implementation
1.
RESERVED_SWITCH_BIT18 under the Reserved Switch parameter in the RNClevel command ADD UIMEITAC is used to control whether the RNC calibrates the
maximum downlink transmit power for special UEs. Special UEs are set by the TAC
parameter in the ADD UIMEITAC command. By default, this feature is disabled
2.
Bit 0 to bit 15 under the RsvU32Para31 parameter in the RNC-level command SET
UALGORSVPARA is used to set the offset of the maximum downlink transmit power
for CS services of special UEs. After the switch controlling downlink maximum transmit
power calibration for special UEs is set to on, the RNC increments the original
maximum downlink transmit power by the power offset specified by this parameter after
a CS service setup for special UEs.
3.
for PS services of special UEs. After the switch controlling downlink maximum transmit
power calibration for special UEs is set to on, the RNC increments the original
maximum downlink transmit power by the power offset specified by this parameter after
a PS service setup for special UEs.

After this function takes effect:
The larger the parameter value, the higher the downlink transmit power, but the smaller
the cell capacity when requirements for downlink transmit power are high.
The smaller the parameter value, the larger the cell capacity when the requirements for
downlink transmit power are high, but the smaller the coverage scope for the UE.
The maximum transmit power of the original RL will be different from that of the new
RL if the SRNC and DRNC use different methods to calibrate the maximum downlink
transmit power of special UEs in cross-Iur soft handover or combined hard handover and
relocation scenarios.
Impact on NEs
None
Impact on Hardware
None

None

None
Issue 01 (2014-12-31)
Impact on configuration management:

Copyright Huawei
166
BSC6900 UMTS
Release Notes

V900R016C00SPC620
1.
RESERVED_SWITCH_BIT18 under the Reserved Switch parameter in the RNClevel command ADD UIMEITAC is used to control whether the RNC calibrates the
maximum downlink transmit power for special UEs.
2.
for CS services of special UEs. The valid parameter value range is 0 to 600 and the
corresponding actual parameter value range is -30 dB to 30 dB. If this parameter is set to
0 or a value greater than 600, the actual value -6 dB is used.
3.
for PS services of special UEs. The valid parameter value range is 0 to 600 and the
corresponding actual parameter value range is -30 dB to 30 dB. If this parameter is set to
0 or a value greater than 600, the actual value -6 dB is used.
Impact on performance management:

After this function is enabled:
The number of successful RRC connection setups, successful RAB setups, and
successful handovers decreases for special UEs, which can be observed by querying
the values of the following counters:
RRC.SuccConnEstab.sum
VS.RAB.SuccEstabCS.Conv
VS.RAB.SuccEstabCS.Str
VS.RAB.SuccEstabPS.Conv
VS.RAB.SuccEstabPS.Str
VS.RAB.SuccEstabPS.Int
VS.RAB.SuccEstabPS.Bkg
VS.SHO.SuccRLAdd
VS.HHO.SuccIntraFreqOut.IntraNodeB
VS.HHO.SuccIntraFreqOut.InterNodeBIntraRNC
VS.HHO.SuccIntraFreqOut.InterRNC
VS.HHO.SuccInterFreq.RNC
The number of call drops increases, which can be viewed by querying the values of
following counters:
VS.RAB.AbnormRel.PS
VS.RAB.AbnormRel.CS
VS.HSDPA.RAB.AbnormRel
VS.HSUPA.RAB.AbnormRel
The downlink non-HSPA transmit power in the cell decreases, which can be viewed
by querying the value of the VS.MeanTCP.NonHS counter.
HSDPA throughput increases, which can be viewed by querying the value of the
VS.HSDPA.MeanChThroughput counter.

None

None
Issue 01 (2014-12-31)

Copyright Huawei
167
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Related Operations
To calibrate the maximum downlink transmit power for a UE whose IMEI TAC
is12345678, run the following command:
ADD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=12345678,
Description="XXX", RsvSwitch=RESERVED_SWITCH_BIT18-1;
The offset of the maximum downlink transmit power for CS and PS services of special
UEs must be calculated based on site conditions. The RsvU32Para31 parameter is set
based on the calculated values.
For example, if the offset of the maximum downlink transmit power for CS services of
special UEs is 240 (binary value: 0000 0000 0000 0000 0000 0000 1111 0000) and the
offset of the maximum downlink transmit power for PS services of special UEs is 240
(binary value: 0000 0000 1111 0000 0000 0000 0000 0000), the value of RsvU32Para31
is 15728880 (binary value: 0000 0000 0000 0000 0000 0000 1111 0000). Run the
following command to set this parameter:

DTS: DTS2014071005182
Feature ID
WRFD-020504
6.2.2.4 UOIP Loopback Detection Function Supported by

DPUe Boards
Description
After the UOIP loopback detection function is supported by DPUe boards, hardware faults
that occur on the digital signal processor (DSP) can be quickly located according to logs.
Implementation
This function is implemented as follows:
The DSP sends UOIP loopback detection packets every second. With this function, the DSP
records key information in logs after detecting 16 missing packets or 2 erroneous packets
within 32 seconds.
BIT3 under the RSVDSW2 parameter in the SET DEVRSVDPARA command controls
whether to enable the UOIP loopback detection function. By default, this function is enabled

None
Impact on NEs
None
Issue 01 (2014-12-31)

Copyright Huawei
168
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Impact on Hardware
None

None

None

BIT3 under the RSVDSW2 parameter in the SET DEVRSVDPARA command is set to
1.

None

None

None
Related Operations
To enable the UOIP loopback detection function, run the following command:
SET DEVRSVDPARA: RSVDSW2=BIT3-1;
To disable the UOIP loopback detection function, run the following command:

DTS: DTS2014061101068
Feature ID
None
6.2.2.5 RRC Connections Established on FACHs When NodeB

Resources Become Unavailable
Description
If RRC connections cannot be set up on DCHs due to unavailable NodeB resources, the RNC
attempts to set up RRC connections on FACHs, which increases the RRC connection setup
success rate.
Issue 01 (2014-12-31)

Copyright Huawei
169
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Implementation
If RRC connections cannot be set up on DCHs due to unavailable NodeB resources, the RNC
attempts to set up RRC connections on FACHs. This function requires that FACH DCCHs
cannot be congested during the RRC phase.
If the RRC connection is successfully established on FACH and the RB Parking feature takes
effect during the RAB setup, the UE establishes services directly on FACH. In the original
processing, however, the UE first establishes services on DCH at a rate of 0 kbit/s and then
performs a state transition to CELL_FACH.
If the UE initiates another RRC connection setup request within 20s, an anti-ping-pong
mechanism is used for RRC redirections caused by admission failures to prevent the UE from
repetitively performing RRC redirections.
UALGORSVPARA command is used to control whether the RNC attempts to establish RRC
connections on FACHs if RRC connection setup attempts on DCHs fail due to unavailable
NodeB resources. By default, this function is disabled (default value: 0) for both new
When this function is disabled, the RNC does not attempt to establish RRC connections on
FACHs if RRC connection setup attempts on DCHs fail due to unavailable NodeB resources.
When this function is enabled, the RNC attempts to establish RRC connections on FACHs if
RRC connection setup attempts on DCHs fail due to unavailable NodeB resources. In
addition, an anti-ping-pong mechanism is used for RRC redirections caused by admission
failures.

When this function is enabled, the RRC connection setup success rate increase and the
number of RAB setup attempts increases. After RABs fail to be set up on DCHs, the RNC
performs an RB parking, which increases the PS service setup success rate and increase the
CS and PS traffic when the service requirements are sufficient.
Impact on NEs
None
Impact on Hardware
None

None

None

UALGORSVPARA command is used to control whether this function takes effect. By
Issue 01 (2014-12-31)

Copyright Huawei
170
BSC6900 UMTS
Release Notes

V900R016C00SPC620
default, this function is disabled (default value: 0) for both new networks and upgrade
scenarios.

None

None

None
Related Operations
SET UALGORSVPARA:RsvSwitch13=RESERVED_SWITCH_13_BIT12-1;

DTS: DTS2014071103655
Feature ID
None
6.2.2.6 Anti-Ping-Pong Mechanism for RRC Redirections

Caused by Admission Failures
Description
An anti-ping-pong mechanism is used for RRC redirections caused by admission failures.
After the RRC connection setup request fails, the UE triggers an RRC redirection. If the UE
initiates another RRC connection setup request within the 20s after the admission failure, it
cannot perform another RRC redirection. Instead, the UE is directly admitted to prevent pingpong RRC redirections.
Implementation
If a UE triggers an RRC redirection due to admission failures during the RRC connection
setup phase, the UE cannot perform another RRC redirection.
UALGORSVPARA command is used to control whether the anti-ping-pong mechanism
takes effect for RRC redirections caused by admission failures. By default, this function is
The anti-ping-pong mechanism is also required for the function of RRC connections
established on FACHs due to unavailable NodeB resources. Therefore, the anti-ping-pong
mechanism is also controlled by RESERVED_SWITCH_13_BIT12 under the RsvSwitch13
parameter in the SET UALGORSVPARA command. By default, this function is disabled
The anti-ping-pong mechanism takes effect if either of the two switches is set to on.
The anti-ping-pong mechanism does not take effect if both of the two switches are set to off.
Issue 01 (2014-12-31)

Copyright Huawei
171
BSC6900 UMTS
Release Notes

V900R016C00SPC620

The RNC uses the anti-ping-pong mechanism for RRC redirections caused by admission
failure for a period of time to reduce unnecessary RRC redirections, thereby improving user
experience. However, the probability of RRC redirections after admission failures is reduced
and the RRC connection setup fails if it cannot be set up on the FACH. After this function is
enabled, the value of the VS.RRC.Rej.Redir.PingPongNum counter increases.
Impact on NEs
None
Impact on Hardware
None

None

None

RESERVED_SWITCH_13_BIT13 and RESERVED_SWITCH_13_BIT12 under the
RsvSwitch13 parameter in the SET UALGORSVPARA command are used to control
whether this function takes effect. By default, the two switches are set to off (default

None

None

None
Related Operations
To enable this function, run either of the following commands:

DTS: DTS2014071103655
Feature ID
None
Issue 01 (2014-12-31)

Copyright Huawei
172
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.2.2.7 Optimized Features for AMR Services

Description
When IuUP version 2 is used, the RNC reduces the maximum rates of AMR services through
the RB reconfiguration procedure, which reduces the code resource consumption and
therefore increases the cell capacity.
In addition, the following functions are supported: symmetric uplink and downlink rate set
configuration for AMR services, optimized incoming and outgoing static relocation
procedures for AMR services, and enhanced compatibility for interconnection of devices from
different vendors.
AMR services described here include wideband AMR (AMR-WB) services and narrowband AMR
(AMR-NB) services.
Implementation
1.
Maximum rate limitation for AMR services through RB reconfiguration. When IuUP
version 2 is used, the RNC reduces the maximum rate of AMR services to the maximum
rate specific to the corresponding AMR service priority through the RB reconfiguration
procedure after an AMR service setup.
RESERVED_SWITCH_13_BIT3 under the RsvSwitch13 parameter in the RNC-level
command SET UALGORSVPARA is used to control whether this function takes effect.
By default, this function is disabled (default value: 0) for both new networks and
upgrade scenarios.
command SET UALGORSVPARA is used to control whether the RB reconfiguration
function can take effect for AMR services before the called party answers the AMR call.
When this function is enabled, the RB reconfiguration function can take effect for AMR
services before the called party answers the AMR call. When this function is disabled,
the RB reconfiguration function can take effect for AMR services only after the called
party answers the AMR call. By default, this function is disabled (default value: 0) for
RsvU8Para20 in the SET UALGORSVPARA command is used to specify the time to
delay the triggering of the Uu-interface RB reconfiguration procedure for AMR services.
Before the called party answers the AMR call, the CN may fail to correctly respond to
the downlink rate adjustment request sent by the RNC. Therefore, the RNC delays the
triggering of the Uu-interface RB reconfiguration procedure for AMR services after the
called party answers the AMR call. When this parameter is set to 0, the delay time is 500
ms.
GUI Value Range: 0 to 255. Unit: 10 ms.
Recommended value: 50. Actual value range: 10 ms to 2550 ms. By default, this
parameter is set to 0 for both new networks and upgrade scenarios.
1) This function takes effect only when the AMR Rate Control (AMRC) feature is activated.
2) If the CN includes the maximum bit rate (MBR) for the reverse direction in the ACK message
specific to the IuUP rate adjustment request, it is recommended that Switch3GPP25415CR0125 in the
ADD UCNNODE or MOD UCNNODE command be set to on to prevent inconsistent switch
configurations between the RNC and CN. If the configurations are inconsistent, the AMR RB
reconfiguration function used to limit the maximum rate of AMR services cannot take effect.
3) The maximum rate specific to an AMR service priority is set using the following commands:
Issue 01 (2014-12-31)

Copyright Huawei
173
BSC6900 UMTS
Release Notes

V900R016C00SPC620
RNC-level parameter setting:
SET UAMRC: GoldMaxMode=xxx, SilverMaxMode=yyy, CopperMaxMode=zzz;

SET UAMRCWB: GoldMaxMode=xxx,SilverMaxMode=yyy,CopperMaxMode=zzz;
Cell-level parameter setting:
ADD UCELLAMRC: GoldMaxMode=xxx,SilverMaxMode=yyy,CopperMaxMode=zzz;

ADD UCELLAMRCWB: GoldMaxMode=xxx,SilverMaxMode=yyy,CopperMaxMode=zzz;
4) If you need to prohibit the AMR RB reconfiguration function for special UEs, run the following
command:
ADD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=xxx, Description="yyy",
SpecUserFunctionSwitch4=SPECUSER_WBAMR_RB_RECFG_LIMIT_SWITCH-1;MOD
UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=xxx, Description="yyy",
SpecUserFunctionSwitch4=SPECUSER_WBAMR_RB_RECFG_LIMIT_SWITCH-1;
5) For AMR-NB services, both the RNC-level and cell-level switches for saving AMR-NB downlink
code resources need to be turned on to save code resources:
First run the following command to turn on the RNC-level switch:
SET UFRC: DlSaveCodeResourceSwitch=ON;
Then run the following command to turn on the cell-level switch:
ADD UCELLFRC: CellId=xxx, AllowedSaveCodeResource=TRUE;
2.
Symmetric uplink and downlink rate set configuration for AMR services. The RNC
configures symmetric uplink and downlink rate sets for UEs during the AMR service
setup.
upgrade scenarios.
If a UE is identified as a special UE and the SPECUSER_AMR_RATE_CHG_SWITCH is set to

on, this function does not take effect. The corresponding parameter settings are as follows:
ADD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=xxx, Description="yyy",
SpecUserFunctionSwitch2=SPECUSER_AMR_RATE_CHG_SWITCH-1;
or
MOD UIMEITAC: TAC_FUNC=Special_User_Enhance, TAC=xxx, Description="yyy",
SpecUserFunctionSwitch2=SPECUSER_AMR_RATE_CHG_SWITCH-1;
Load reshuffling (LDR)-triggered rate reduction for AMR services in access mode causes
asymmetric uplink and downlink rate set configuration, which does not comply with the requirement
of this function. Therefore, LDR-triggered rate reduction for AMR services in access mode does not
take effect.
It is recommended that the CN assign a maximum of four rates. Otherwise, combined services are
more likely to fail due to the limited transport format combination (TFC) capabilities of some UEs.
This function takes effect only when the number of rates assigned by the CN does not exceed 4.
This function is recommended only when compatibility issues occur during the interconnection of
devices from different vendors.
This function takes effect only when the AMRC feature is activated. When IuUP Version 2 is used,
the AMRC rate set extension function must also be enabled to ensure symmetric rate sets. You can
run the following commands to set the AMRC rate set extension function for AMR-WB and AMRNB services, respectively:
CsSwitch=CS_AMRC_WB_RATE_ADJUST_GRADUALLY_SWITCH-1;
SET UCORRMPARA:
PerfEnhanceSwitch3=PERFENH_NB_AMRC_UL_RATESET_EXT_SWITCH-1;
3.
Issue 01 (2014-12-31)
Compatible processing for inconsistent Iu and Uu rate set configurations during

incoming static relocation. When IuUP version 2 is used and the drift RNC (DRNC)
Copyright Huawei
174
BSC6900 UMTS
Release Notes

V900R016C00SPC620
receives a relocation request message, the DRNC sets the UE rate based on the rate set in
the "Source To Target Transparent Container" IE and performs IuUP initialization based
on the rate set in the "RAB Parameters" IE carried in the relocation request message.
upgrade scenarios.
4.
Outgoing static relocation allowed for AMR services that have experienced an RB
reconfiguration.
When this function takes effect, outgoing static relocation can be performed for AMR
services that have experienced an RB reconfiguration. By default, this function is
If this function is used for the SRNC, it is recommended that RESERVED_SWITCH_13_BIT5 be set
to on for the DRNC to prevent IuUP initiate failures caused by inconsistent Iu and Uu rate set
configurations. The parameter setting is as follows:

1.
After the function of maximum rate limitation for AMR services through RB
reconfiguration takes effect, downlink code resource congestion in a cell can be relieved,
which increases the cell downlink capacity, improves the downlink coverage for AMR
UEs but reduces the mean opinion score (MOS).
The number of rate limitations for AMR-WB and AMR-NB UEs after RB
reconfiguration increase. For example, if the rate of AMR-NB services is limited to
5.9 kbit/s, the values of the VS.RB.AMR.DL.5.9 and VS.RB.AMR.UL.5.9 counters
increase.
The number of RB reconfigurations increase and the increase can be observed by

querying the values of the VS.AttRBRecfg and VS.SuccRBRecfg counters.
The number of AMR rate reductions increase and the increase can be observed by
querying the values of the following counters: VS.AMR.DL.RateDown,
VS.AMR.UL.RateDown, VS.AMRWB.ULRateDown, and
VS.AMRWB.DLRateDown.
2.
After the function of symmetric uplink and downlink rate set configuration for AMR
services takes effect, LDR-triggered rate reduction for AMR services in access mode
does not take effect. This increases the success rate of cross-Iur soft handovers and the
increase can be observed by querying the value of the VS.SHO.SuccRLSetupIur.Rx
counter.
3.
After compatible processing for inconsistent Iu and Uu rate set configurations during
incoming static relocation takes effect, the success rate of static relocations for AMR
services increases. The increase can be observed by querying the value of the
RELOC.SuccResAllocUENotInvolCS counter.
4.
After the function of outgoing static relocation allowed for AMR services that have
experienced an RB reconfiguration is disabled, the Iur resource usage and congestion
probability decrease.
5.
After the RB is reconfigured for AMR services, service rates decrease. As a result,
average values of VQI and EVQI decrease, and the following counters are affected:
All counters under the EVQI.CELL function subset
Issue 01 (2014-12-31)

Copyright Huawei
175
BSC6900 UMTS
Release Notes

V900R016C00SPC620
VS.Voice.VQI.Average
VS.Voice.VQI.Excellent.TimeRate
VS.Voice.VQI.Good.TimeRate
VS.Voice.VQI.Accept.TimeRate
VS.Voice.VQI.Poor.TimeRate
VS.Voice.VQI.Bad.TimeRate
Impact on NEs
None
Impact on Hardware
None

None
License
None
RESERVED_SWITCH_13_BIT3 under the RsvSwitch13 parameter in the RNClevel command SET UALGORSVPARA is used.
RsvU8Para20 in the SET UALGORSVPARA command is used.

None

None

None
Related Operations
1.
To enable the function of maximum rate limitation for AMR services through RB
reconfiguration, run the following command:
Issue 01 (2014-12-31)

Copyright Huawei
176
BSC6900 UMTS
Release Notes

V900R016C00SPC620
2.
To enable the RB reconfiguration function for AMR services before the called party
answers the AMR call, run the following command:
3.
To enable the function of symmetric uplink and downlink link set configurations for
AMR services, run the following command:
4.
To enable compatible processing for inconsistent Iu and Uu rate set configurations

during incoming static relocation, run the following command:
5.
To allow outgoing static relocation for AMR services that have experienced an RB
reconfiguration, run the following command:
6.
To set the time to delay the triggering of the Uu-interface RB reconfiguration procedure
for AMR services to xxx (unit: 10 ms), run the following command:
SET UALGORSVPARA: RsvU8Para20=xxx;

DTS: DTS2014070817402
Feature ID
WRFD-011600
WRFD-020701
6.2.2.8 Optimization of How an RNC Handles the

SIGNALLING CONNECTION RELEASE INDICATION Message in
the PS Domain for UEs Enabled with the Enhanced Fast
Dormancy Feature
Description
During the RRC signaling procedure, an RNC receives a SIGNALLING CONNECTION
RELEASE INDICATION message in the PS domain from a UE enabled with the Enhanced
Fast Dormancy feature. After the RRC signaling procedure ends, the RNC initiates a PS
signaling connection release procedure instead of discarding the SIGNALLING
CONNECTION RELEASE INDICATION message when both the following conditions
apply:
The SIGNALLING CONNECTION RELEASE INDICATION message does not carry

release cause "UE Requested PS Data session end".
The RNC_FD_SCRI_FORCE_REL_SWITCH under parameter

PROCESSSWITCH2 in the SET URRCTRLSWITCH command is turned on, or the
RNC has received the SIGNALLING CONNECTION RELEASE INDICATION
message carrying release cause "UE Requested PS Data session end".
After this solution is enabled, the RNC immediately initiates a PS signaling connection
release procedure for UEs incompatible with the Enhanced Fast Dormancy feature, improving
user experience in PS services.
Issue 01 (2014-12-31)

Copyright Huawei
177
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Implementation
UALGORSVPARA command controls whether the RNC immediately initiates a PS
signaling connection release procedure for UEs enabled with the Enhanced Fast Dormancy
feature in the preceding scenario. By default, this solution is disabled (default value: 0) for
both new networks and upgrade scenarios. If this solution is enabled, the RNC initiates a PS
signaling connection release procedure after the RRC signaling procedure ends. If this
solution is disabled, the RNC discards the SIGNALLING CONNECTION RELEASE
INDICATION message in the PS domain after the RRC signaling procedure ends.
SET UALGORSVPARA:
SET UALGORSVPARA:

None
Impact on NEs
None
Impact on Hardware
None

None

None

Added RESERVED_SWITCH_10_BIT28 under the RsvSwitch10 parameter in the
SET UALGORSVPARA command to control whether the preceding solution takes
effect.

None

None
Issue 01 (2014-12-31)

Copyright Huawei
178
BSC6900 UMTS
Release Notes

V900R016C00SPC620

None
Related Operations

iCare: 2983422
DTS: DTS2014081801702
Feature ID
WRFD-020500
6.2.2.9 RL Reestablishment Event Blocks Now Added to RNC

PCHR Logs
Description
RL reestablishment event blocks are now added to RNC PCHR logs. These blocks record the
information about RL reestablishment.
Implementation
1.1 Trigger condition
When initiating an RL reestablishment procedure, the RNC starts to record the information
about RL reestablishment.
1.2 Output
When the RL reestablishment procedure is complete (including successful and failed RL
reestablishments), the RNC ends the information recording and exports logs.
UALGORSVPARA command controls whether the RNC exports RL reestablishment event
blocks to the OMU.This solution is enabled when either of the preceding switches is set to on.
By default, this solution is disabled (default value: 0) for both new networks and upgrade
scenarios. RESERVED_SWITCH_16_BIT13 under the same parameter controls whether
the RNC exports RL reestablishment event blocks to the SAU. This solution is enabled when
either of the preceding switches is set to on. By default, this solution is disabled (default

None
Impact on NEs
None
Issue 01 (2014-12-31)

Copyright Huawei
179
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
To enable this solution, run the following commands:
To disable this solution, run the following commands:

DTS: DTS2014082608974
Feature ID
None
6.2.2.10 CN-Initiated Service Awareness Specific for NonRoaming Users of the Primary Operator
Description
This feature enables the CN to perform service awareness only on the non-roaming users of
the primary operator.
Issue 01 (2014-12-31)

Copyright Huawei
180
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Implementation
Upon obtaining the international mobile subscriber identity (IMSI) of a user, the RNC
compares the public land mobile network (PLMN) of this IMSI with that configured through
the ADD UCNOPERATOR command. If they are consistent, the RNC determines that the
user is a non-roaming user of the primary operator. The CN performs service awareness on
this user.
is disabled (default value: 0) for both new networks and upgrade scenarios. When this feature
is enabled, the CN performs service awareness on only the non-roaming users of the primary
operator. When this feature is disabled, the CN performs service awareness on all users.

None
Impact on NEs
None
Impact on Hardware
None

None

None

UALGORSVPARA command is enabled.

None

None

After this feature is enabled, if DLE2EQoSSwitch and DPISourcePrio are set to ON and
CN, respectively, by running the following commands:
MOD UCNNODE:CnOpIndex=xxx, CNId=xxx, CNDomainId=PS_DOMAIN,
DLE2EQoSSwitch=ON;
The CnOpIndex parameter specifies the index of the primary operator, and the CNId parameter
specifies the ID of the CN node in the PS domain of the primary operator.
Issue 01 (2014-12-31)

Copyright Huawei
181
BSC6900 UMTS
Release Notes

V900R016C00SPC620
SET UUPALGOSWITCH: DPISourcePrio=CN;

The following features take effect on non-roaming users of the primary operator:
Web Browsing Acceleration, P2P Downloading Rate Control during Busy Hour, Video
Service Rate Adaption, VoIP Application Management, and Differentiated Service Based on
Application Resource Reservation
Related Operations
SET UALGORSVPARA:
SET UALGORSVPARA:

DTS: DTS2014073109355
Feature ID
WRFD-020132
WRFD-020133
WRFD-150252
WRFD-150253
WRFD-150254
6.2.2.11 CS and PS Non-Service Direct Transfer Message

Blocks Now Added to RNC PCHR Logs
Description
CS and PS non-service direct transfer message blocks are now added to RNC PCHR logs.
These message blocks record the information about CS and PS non-service direct transfer
messages.
Implementation
1. Logging of CS non-service direct transfer message blocks
Upon receiving a LOCATION UPDATING REQUEST or IMSI DETACH INITIATION
direct transfer message from the UE, the RNC starts to record the message information. At the
same time, the RNC starts a 10-second timer for exporting CS non-service direct transfer
message blocks.
Issue 01 (2014-12-31)

Copyright Huawei
182
BSC6900 UMTS
Release Notes

V900R016C00SPC620
1.2 Output
For the LOCATION UPDATING REQUEST direct transfer message
If the RNC receives a LOCATION UPDATING ACCEPT message from the CN

before the timer expires, the RNC ends the message information recording and
exports logs.
If the RNC receives a LOCATION UPDATING REJECT message from the CN

before the timer expires, the RNC records the reject cause, ends the message
information recording, and exports logs.
If the RNC does not receive any response, the RNC exports logs after the timer
expires.
For the IMSI DETACH INITIATION direct transfer message, the RNC directly ends the
message information recording and exports logs.

UALGORSVPARA command controls whether the RNC exports CS non-service direct
transfer message blocks to the OMU. RESERVED_SWITCH_12_BIT3 under the same
parameter controls whether the RNC exports CS non-service direct transfer message blocks to
the SAU. This solution is enabled when either of the preceding switches is set to on. By
scenarios.
2. Logging of PS non-service direct transfer message blocks
Upon receiving an ATTACH REQUEST, ROUTING AREA UPDATE REQUEST, or
DETACH REQUEST direct transfer message from the UE, the RNC starts to record the
message information. At the same time, the RNC starts a 10-second timer for exporting PS
non-service direct transfer message blocks.
2.2 Output
For the ATTACH REQUEST direct transfer message
If the RNC receives an ATTACH ACCEPT or ATTACH REJECT message from the CN
before the timer expires or if the RNC does not receive any response from the CN before the
timer expires, the RNC ends the message information recording and exports logs.
For the ROUTING AREA UPDATING direct transfer message
If the RNC receives a ROUTING AREA UPDATE ACCEPT or ROUTING AREA

UPDATING REJECT message from the CN before the timer expires or if the RNC does not
receive any response from the CN before the timer expires, the RNC ends the message
information recording and exports logs.
For the DETACH REQUEST direct transfer message, the RNC directly ends the
message information recording and exports logs.

UALGORSVPARA command controls whether the RNC exports PS non-service direct
transfer message blocks to the OMU. RESERVED_SWITCH_12_BIT4 under the same
parameter controls whether the RNC exports PS non-service direct transfer message blocks to
the SAU. This solution is enabled when either of the preceding switches is set to on. By
scenarios.
Issue 01 (2014-12-31)

Copyright Huawei
183
BSC6900 UMTS
Release Notes

V900R016C00SPC620

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
Issue 01 (2014-12-31)

Copyright Huawei
184
BSC6900 UMTS
Release Notes

V900R016C00SPC620

DTS: DTS2014081207836
Feature ID
None
6.2.2.12 Layer 2 Release Blocks Now Added to RNC PCHR

Logs
Description
Layer 2 release blocks are now added to RNC performance call history record (PCHR) logs.
Layer 2 release blocks record the transmission and reception of signaling packets when the
RRC connection is abnormal.
Implementation
When a UE's RRC connection is abnormally released, the RNC records the data transmission
and reception on logical signaling channels. The RNC records the data transmission and
reception of a maximum of three radio links (RLs) for the UE and exports layer 2 release
blocks.
UALGORSVPARA command controls whether the RNC exports layer 2 release blocks to
the OMU. RESERVED_SWITCH_10_BIT25 under the same parameter controls whether
the RNC exports layer 2 release blocks to the SAU. This solution is enabled when either of
the preceding switches is set to on. By default, this solution is disabled (default value: 0) for

None
Impact on NEs
None
Impact on Hardware
None

None

None

None
Issue 01 (2014-12-31)

Copyright Huawei
185
BSC6900 UMTS
Release Notes

V900R016C00SPC620

None

None

None
Related Operations
SET UALGORSVPARA:RsvSwitch10=RESERVED_SWITCH_10_BIT18-0;

DTS: DTS2014072405595
Feature ID
None
6.2.2.13 Support for Subrack DIP Switch Status Check

Description
The subrack DIP switch status check function is added to the FMA on the Web LMT. With
this function, users can check whether the DIP switch on a subrack is correctly set and
efficiently locate and resolve problems if the DIP switch status is abnormal.
Implementation
The subrack DIP switch status check function has been added to the Equipment health check
option of the Others node under UMTS fault analysis on the FMA tab page on the Web
LMT. When this option is selected, the system performs Fault Diagnosis function, including
DIP switch status check.
Issue 01 (2014-12-31)

Copyright Huawei
186
BSC6900 UMTS
Release Notes

V900R016C00SPC620

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None
Issue 01 (2014-12-31)

Copyright Huawei
187
BSC6900 UMTS
Release Notes

V900R016C00SPC620

None
Related Operations
None

DTS: DTS2014052300745
Feature ID
None
6.2.2.14 Upgrade Tool Reliability Optimization

Description
This feature optimizes the upgrade operation procedure and the display of upgrade reports on
the upgrade tool. With this feature, user misoperations can be reduced, and upgrade reports
better steer upgrade operations, thereby improving the reliability of the upgrade tool.
Implementation
The optimization is described as follows:
1.
The statements have been added to the Input Step 1 window on the upgrade tool, as
shown in the following figure. The statements help users avoid performing illegal
operations during an upgrade.
2.
In version upgrade scenarios, suggestive descriptions have been added to the Confirm
window displayed after users click Next in the Input Step 2 window on the upgrade
tool.
Issue 01 (2014-12-31)
For an upgrade not requiring an intermediate version, the following descriptions are
added.

Copyright Huawei
188
BSC6900 UMTS
Release Notes

V900R016C00SPC620
For an upgrade requiring an intermediate version, the following descriptions are

added.
3.
The display of the Runtime Result column in upgrade reports has been optimized. If
users select Continue when an item fails during an upgrade, instead of IGNORED,
error information is displayed in the Runtime Result column for the item, as shown in
the following figure.
4.
The Error Impact and Troubleshooting columns have been added to upgrade reports,
as shown in the following figure. The Error Impact column describes the impacts when
the execution of a check item fails. The Troubleshooting column provides guidance in
handling the failure.

None
Issue 01 (2014-12-31)

Copyright Huawei
189
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
None

DTS: DTS2014071004638
Feature ID
None
6.2.2.15 Replacing SCUa with SCUb Online

Description
This feature allows users to replace the SCUa board with the SCUb board online. Unlike
offline replacement, online replacement does not require resetting the entire subrack and
therefore decreases the service interruption duration.
Implementation
This feature applies to the following scenarios:
Issue 01 (2014-12-31)
Spare part replacement

Copyright Huawei
190
BSC6900 UMTS
Release Notes

V900R016C00SPC620
After the replacement, 1-Gbit ports on the SCUb board are used for inter-subrack
communications.
Inter-subrack bandwidth expansion

After the replacement, 10-Gbit ports on the SCUb board are used for inter-subrack
communications.
An SCUa board and an SCUb board are temporarily configured in active/standby mode.
The subrack does not reset during the replacement.

In spare part replacement and inter-subrack bandwidth expansion scenarios, the inter-subrack
bandwidth is halved after the replacement.
Impact on NEs
None
Impact on Hardware
None

None

None

Modified the MOD BRD command to accommodate this feature.
Added the SET MIXSCUPORT, CHK SCU, and SWP SCU commands to
accommodate this feature.

None

When an SCUa board and an SCUb board are temporarily configured in active/standby
mode, the following alarms are reported:
ALM-20221 Link Between GE Switching Boards Faulty
ALM-20222 Communication Between GE Switching Boards Faulty
ALM-20225 GE Link on GE Switching Board Panel Faulty
ALM-20228 GE Link Between GE Switching Board and Service Board Faulty

None
Issue 01 (2014-12-31)

Copyright Huawei
191
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Related Operations
Contact Huawei technical support.

DTS: DTS2014070820501
Feature ID
None

None
6.3 Resolved Issues

6.3.1 Critical
6.3.2 Major
6.3.2.1 PS services fail to be set up due to insufficient
memory for the IP address pair table on the Iu-PS interface
board.
Trouble
Ticket
Number
iCare: 2607391
Description
Condition: The Iu-PS interface board accommodates only 256 IP

address pairs, which are insufficient for new IP address pairs in the RAB
ASSIGNMENT REQUEST message.
DTS: DTS2014061003067
Symptom: PS services fail to be set up.

Impact: The PS radio access bearer (RAB) setup success rate decreases.
Severity
Major
Root Cause
In the preceding scenario, the memory for IP address pair table used for
maintenance on the Iu-PS interface board is insufficient for new IP
address pairs.
Solution
The memory for the IP address pair table used for maintenance on the
Iu-PS interface board is now expanded so that the Iu-PS interface board
accommodates 4,096 IP address pairs.
Solution
Impact
If the Iu-PS interface board has over 256 IP address pairs, the PS RAB
setup success rate increases. If the Iu-PS interface board has 4,096 IP
address pairs, the CPU usage of the Iu-PS interface board increases by
about 1%.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
192
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.2 Services fail to be set up after a cell update with

SRNS relocation is complete.
Trouble
Ticket
Number
DTS: DTS2014061900469
Description
Condition: A non-Huawei SRNC initiates a cell update with SRNS

relocation to a Huawei DRNC that has established radio links. After the
relocation is complete, the UE requests to reestablish services.
Symptom: Services fail to be set up for the UE.
Impact: The service setup success rate decreases.
Severity
Major
Root Cause
The Huawei DRNC maintains incorrect information about radio links.
Solution

rectifies incorrect radio information. By default, this solution is disabled
When this solution is enabled, the Huawei DRNC rectifies incorrect
radio link information. When this solution is disabled, the Huawei
DRNC does not rectify incorrect radio link information.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The service setup success rate increases.
Test Case
6.3.2.3 The RNC does not process INITIAL DIRECT TRANSFER

messages in an RRC connection release procedure.
Trouble
Ticket
Number
iCare: 2658703
Description
Condition: In an RRC connection release procedure, the RNC receives

an INITIAL DIRECT TRANSFER message from the CS domain, with
the cause value of "IMSI DETACH INDICATION".
Issue 01 (2014-12-31)
DTS: DTS2014060503397

Copyright Huawei
193
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Symptom: The RNC does not process the INITIAL DIRECT

TRANSFER message.
Impact: UEs cannot be paged, affecting user experience.
Severity
Major
Root Cause
In the preceding scenario, the RNC is releasing the RRC connection.
Solution

processes the preceding message in an RRC connection release
procedure. By default, this solution is disabled (default value: 0) for both
When this solution is enabled, the RNC processes the preceding
message.
When this solution is disabled, the RNC does not process the preceding
message.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
This solution increases the paging success rate of the core network and
the RNC, improves user experience, and increases the value of the
counters VS.IU.RelCmdCS.NormRel and VS.IU.RelCmdCS.sum.
Test Case
6.3.2.4 The uplink SRB fails to be reconfigured again after it

is reconfigured from the DCH to the E-DCH.
Trouble
Ticket
Number
DTS: DTS2014060407065
Description
Condition: The uplink SRB is reconfigured from the DCH to the EDCH in the following scenario:
NODEB_PRIVATE_INTERFACE_SWITCH under the

PROCESSSWITCH parameter in the SET URRCTRLSWITCH
command is set to on.
There are both R99 and E-DCH links in the active set.
Symptom: During the uplink SRB reconfiguration from the DCH to the
E-DCH, the RNC sends a RADIO LINK RECONFIGURATION
PREPARE message to the NodeB. When sending this message, the RNC
incorrectly sets the value of the TrafficClass-Private information element
(IE) to interactive-Private, not to srb-Private. In the second uplink SRB
reconfiguration procedure, the NodeB sends a RADIO LINK
RECONFIGURATION FAILURE message with the cause value
Issue 01 (2014-12-31)

Copyright Huawei
194
BSC6900 UMTS
Release Notes

V900R016C00SPC620
"Requested configuration not support" to the RNC.

Impact: UEs are abnormally released.
Severity
Major
Root Cause
In the preceding scenario:

1. The RNC incorrectly sets the value of the TrafficClass-Private IE to
interactive-Private when sending the RADIO LINK
RECONFIGURATION PREPARE message to the NodeB.
2. In the second uplink SRB reconfiguration procedure, the NodeB
compares the value of the TrafficClass-Private IE sent by the RNC
with that in the previous SRB reconfiguration procedure and
identifies an inconsistency. Consequently, the NodeB sends a
RADIO LINK RECONFIGURATION FAILURE message to the
RNC.
Solution

When this solution is enabled, the RNC changes the value of the
TrafficClass-Private IE to srb-Private when sending the RADIO LINK
When this solution is disabled, the RNC does not change the value of
the TrafficClass-Private IE when sending the RADIO LINK
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
After this solution takes effect, the measured value of the

VS.IUB.RLFailInd.CfgUnsupp counter decreases.
Test Case
6.3.2.5 The relocation preparation procedure fails when the

target cell is not configured as an external neighboring
UMTS cell of the source cell.
Trouble
Ticket
Number
DTS: DTS2014060308328
Description
Condition: This issue occurs in the following scenario:
Issue 01 (2014-12-31)
A UE in the CELL_PCH state moves to a cell under the DRNC and

performs a cell update procedure using the cause value "Cell
reselection."

Copyright Huawei
195
BSC6900 UMTS
Release Notes

V900R016C00SPC620
The cell under the DRNC is not configured as an external neighboring

UMTS cell of the source cell, and the cell under the DRNC supports
E-FACH.
Symptom: The relocation preparation procedure fails, and the core

network (CN) sends a
RANAP_RELOCATION_PREPARATION_FAILURE message with the
cause value "unknown target rnc" to the SRNC.
Impact: The success rate of relocation preparations decreases.
Severity
Major
Root Cause
The SRNC always fills in the PLMN ID of the target RNC in the
RANAP_RELOCATION_REQUIRED message with 0 in the preceding
scenario. As a result, the CN fails to identify the target RNC and sends
back a RANAP_RELOCATION_PREPARATION_FAILURE message
to the SRNC to terminate the relocation procedure.
Solution

this solution. When this solution is enabled, the SRNC correctly fills in
the PLMN ID of the target RNC according to the PLMN ID contained in
the CELL UPDATE message sent by the UE in the cell under the DRNC
in the preceding scenario. When this solution is disabled, the SRNC
always fills in the PLMN ID of the target RNC with 0 in the preceding
scenario, and then the relocation preparation fails.
SET UALGORSVPARA:
RsvSwitch16 = RESERVED_SWITCH_16_BIT11-1;
SET UALGORSVPARA:
RsvSwitch16 = RESERVED_SWITCH_16_BIT11-0;
Solution
Impact
When this solution is enabled, the success rate of relocation preparations

increases in the preceding scenario.
Test Case
6.3.2.6 A cell cannot be selected as the target cell for CLBtriggered inter-frequency handover because this cell is not
configured with the CLB algorithm.
Trouble
Ticket
Number
DTS: DTS2014062701365
Description
Condition: A cell is not configured with the cell-level parameters for the
Inter-Frequency Load Balancing Based on Configurable Load Threshold
(CLB) algorithm by using the ADD UCELLCLB command. This cell
Issue 01 (2014-12-31)

Copyright Huawei
196
BSC6900 UMTS
Release Notes

V900R016C00SPC620
was once in the CLB state due to insufficient power resources.

Symptom: This cell cannot be selected as the target cell for CLBtriggered inter-frequency handover.
Impact: The RNC cannot hand over UEs from cells that are configured
as the inter-frequency neighboring cells of this cell to this cell using the
CLB algorithm.
Severity
Major
Root Cause
When a cell enters the CLB state due to insufficient power resources, the
RNC forcibly sets the CLB power load margin of this cell to 0. If this
cell is not configured with the cell-level parameters for the CLB
algorithm, the RNC does not update the CLB power load margin for this
cell. As a result, the RNC considers that the remaining power resources
in this cell are insufficient and does not select this cell as the target cell
for CLB-triggered inter-frequency handover.
Solution
The RNC now updates the CLB power load margin of this cell even if
this cell is not configured with the cell-level parameters for the CLB
algorithm.
Solution
Impact
None
Test Case
6.3.2.7 Configuration information about intelligent

optimization-related features is not displayed in the MML
configuration script.
Trouble
Ticket
Number
DTS: DTS2014071101892
Description
Condition: The EXP CFGMML command is executed to export the

MML configuration script.
Symptom: Configuration information about intelligent optimizationrelated features is not displayed in the MML configuration script.
Configuration information about intelligent optimization-related features
includes the following MML commands:
ADD UIOPTFEATURE
ADD UIOPTFUNCTION
ADD UIOPTRULE
ACT UIOPTRULE
ADD UIOPTATOMRULE
ADD UIOPTRULEMEMBER
ADD UIOPTRULELINKRELAT
Impact: Configuration information about intelligent optimizationrelated features cannot be obtained from the MML configuration script,
Issue 01 (2014-12-31)

Copyright Huawei
197
BSC6900 UMTS
Release Notes

V900R016C00SPC620
which affects the OM of this feature.

Severity
Major
Root Cause
In the current version, users cannot execute the ADD-type MML

commands for intelligent optimization-related features. After these
commands are exported to the MML configuration script, the MML
configuration script execution fails.
Solution
Configuration information about intelligent optimization-related features

is now displayed in the MML configuration script in the comment
format (Two slashes (//) are added before MML commands related to
these features and these MML commands will be skipped during the
execution of the MML configuration script).
Solution
Impact
None
Test Case
6.3.2.8 The RNC fails to deactivate the CPC-DTX/DRX

function for non-serving radio links in soft handover
scenarios.
Trouble
Ticket
Number
DTS: DTS2014062406636
Description
Condition: A UE is configured with two radio links that support the

CPC-DTX/DRX function, link A and link B. Link A is the serving link
and link B is the non-serving link. The two links belong to different
NodeBs. The RNC is about to add a third link (link C) that does not
support the CPC-DTX/DRX function.
Symptom: During a link B reconfiguration in subsequent procedures,
the NodeB sends a message indicating that the RL reconfiguration fails.
Impact: The RL reconfiguration success rate is low.
Severity
Major
Root Cause
The RNC needs to deactivate the CPC-DTX/DRX function before

adding link C in the preceding scenario. If the configured value of the
cqiFeedback-CycleK information element (IE) changes, the RNC
deactivates the CPC-DTX/DRX function only for the serving link but
not for the non-serving link.
Solution
The RNC now deactivates the CPC-DTX/DRX function for all links in
the active set when the configured value of the cqiFeedback-CycleK IE
changes in the preceding scenario.
Solution
Impact
After this solution is used in the preceding scenario, the RL

reconfiguration success rate (indicated by the VS.IUB.SuccRLRecfg
counter) increases.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
198
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.9 A UE cannot trigger the RB Parking function after a

queuing failure.
Trouble
Ticket
Number
DTS: DTS2014061604937
Description
Condition:
Radio resources in a cell are congested, which include:

Uplink and downlink power resources
Uplink and downlink CE resources
Uplink and downlink Iub transmission bandwidth
Downlink code resources
The ResCongDrdOptSwitch in the SET UDRD command is set to

on. This switch controls the optimized DRD function in network
congestion scenarios.
Symptom: After a cell admission failure due to radio resource

congestion, a UE attempts to apply for cell resources through queuing.
However, the queuing fails and the UE cannot trigger the RB Parking
function.
Impact: The UE cannot trigger the RB Parking function and therefore
cannot be admitted.
Severity
Major
Root Cause
When the ResCongDrdOptSwitch in the SET UDRD command is set

to on, the RNC returns a service setup failure message
(RANAP_RAB_ASSIGNMENT_RESP) to the CN after a UE queuing
failure. As a result, the UE cannot trigger the RB Parking function.
Solution
The RNC now does not return a service setup failure message to the CN
after a UE queuing failure to ensure that the UE can trigger the RB
Parking function.
Solution
Impact
After this solution is used in the preceding scenario, the access success
rate for PS services increases.
Test Case
6.3.2.10 The DSP experiences a reset for self-healing due to

a communication failure between the SPU subsystem and
the DSP.
Trouble
Ticket
Number
DTS: DTS2014061108810
Description
Condition: The communication link between the SPU subsystem and
Issue 01 (2014-12-31)

Copyright Huawei
199
BSC6900 UMTS
Release Notes

V900R016C00SPC620
DSP is faulty.
Symptom: The DSP experiences a reset for self-healing.
Impact: The values returned by VS.DCCC.Succ.F2P and
VS.DCCC.D2P.Succ decrease.
Severity
Major
Root Cause
The RNC does not release all user-plane resources, so UEs fail to obtain
user-plane resources when switching from CELL_FACH or CELL_DCH
to CELL_PCH.
Solution
The RNC now releases all user-plane resources.
Solution
Impact
The values returned by VS.DCCC.Succ.F2P and VS.DCCC.D2P.Succ

increase.
Test Case
6.3.2.11 Link configuration fails due to high maximum

downlink transmit power of a UE.
Trouble
Ticket
Number
DTS: DTS2014071008167
Description
Condition: The maximum downlink transmit power on the P-CPICH is

too high.
Symptom: The maximum downlink transmit power of a UE exceeds the
maximum transmit power allowed by a cell, which leads to link
configuration failures.
Impact: Services cannot be set up.
Severity
Major
Root Cause
During link setup or link reconfiguration, the RNC calculates the

maximum downlink transmit power of a UE based on the maximum
downlink transmit power on the P-CPICH and the power offset to the
maximum downlink transmit power of the UE. If the maximum
downlink transmit power on the P-CPICH is too high, the maximum
downlink transmit power of the UE will exceed the maximum transmit
power allowed by the cell. As a result, link configuration fails.
Solution
The RNC now checks the maximum downlink transmit power of a UE

to ensure that the maximum downlink transmit power of the UE does
not exceed the maximum transmit power allowed by the cell.
Solution
Impact
After this solution is used, link setup or reconfiguration succeeds.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
200
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.12 PS streaming services cannot be established if the

RAN does not support the MBR assigned by the CN.
Trouble
Ticket
Number
DTS: DTS2014080601430
Description
Condition:
PS streaming services are being established.
The RAN does not support the maximum bit rate (MBR) assigned by
the CN.
The Iu QoS negotiation function is disabled on the RNC side (that is,
the PS_STREAM_IU_QOS_NEG_SWITCH under the PsSwitch
parameter in the SET UCORRMALGOSWITCH command is set
to 0) or Iu QoS negotiation fails.
Symptom: PS streaming services cannot be established.

Impact: The PS RAB setup success rate decreases.
Severity
Major
Root Cause
In the preceding scenario, the RNC fails to configure Uu-interface

bandwidth and PS streaming services cannot be established.
Solution
The RNC now automatically matches Uu-interface bandwidth based on

the MBR assigned by the CN and the RAN capability. The Iu QoS
negotiation function becomes invalid automatically for PS streaming
services.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
After this solution is used in the preceding scenario, the PS RAB setup
success rate increases.
Test Case
6.3.2.13 The RMV UEXT3GCELL, MOD UCELLFREQUENCY, or

RMV UNRELATION command fails to be executed.
Trouble
Ticket
Number
Issue 01 (2014-12-31)
DTS: DTS2014050401866

Copyright Huawei
201
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Description
Condition: An AP cell is configured with more than 1900 reverse

neighboring cells.
NOTE
If cell A is configured as an intra-frequency or inter-frequency neighboring cell of
cell B, cell B is called a reverse neighboring cell of cell A.
Symptom: A failure message is returned when the RMV

UEXT3GCELL, MOD UCELLFREQUENCY, or RMV
UNRELATION command is executed.
Impact: The command execution fails.
Severity
Major
Root Cause
During the execution of the RMV UEXT3GCELL, MOD

UCELLFREQUENCY, or RMV UNRELATION command, the OMU
sends configuration information to the SPU subsystem. The
configuration information includes a reverse neighboring cell list. If the
number of reverse neighboring cells exceeds 1900, the message size will
exceed the limit and the SPU subsystem returns a failure message to the
OMU.
Solution
If the number of reverse neighboring cells for an AP cell exceeds 192,

the OMU divides the configuration information into multiple small
message packets to ensure that the size of each message packet is within
the limit. The SPU subsystem updates the system information for each
cell 5 minutes after it has received all the message packets.
Solution
Impact
The execution duration of the RMV UEXT3GCELL, MOD

UCELLFREQUENCY, or RMV UNRELATION command prolongs
and the CPU usage of the SPU subsystem increases slightly.
For example, if the number of reverse neighboring cells for an AP cell is
5100, the execution duration of the RMV UEXT3GCELL, MOD
UCELLFREQUENCY, or RMV UNRELATION command is
prolonged to 10 minutes and the rise in the CPU usage of the SPU
subsystem is within 5%.
Test Case
6.3.2.14 SRBs fail be carried on the HSDPA channel if UEs in

the CELL_PCH or URA_PCH state switch to the CELL_DCH
state.
Trouble
Ticket
Number
DTS: DTS2014080402554
Description
Issue 01 (2014-12-31)
DRA_BASE_COVER_LOAD_SRB_H2D_SWITCH under the

DraSwitch2 parameter in the SET UCORRMALGOSWITCH
command is set to 1 on the RNC. That is, the coverage- and loadbased algorithm is enabled for dynamic configuration of the channel
mapped to downlink SRBs.

Copyright Huawei
202
BSC6900 UMTS
Release Notes

V900R016C00SPC620
The preceding algorithm causes that SRBs are carried on the DCH.
A UE switches from the CELL_DCH state to the CELL_PCH or

URA_PCH state directly instead of through the CELL_FACH state.
Then, the UE switches from the CELL_PCH or URA_PCH state
back to the CELL_DCH state, whether directly or through the
CELL_FACH state. The best cell does not change for the UE.
Symptom: When the UE switches to the CELL_DCH state, its SRBs

fail to be carried on the HSDPA channel.
Impact: The benefits caused by the SRB over HSDPA feature on system
capacity decease because the number of UEs with SRBs carried on the
HSDPA channel is reduced.
Severity
Major
Root Cause
In the preceding scenario, the RNC does not reselect the channel for
carrying SRBs by using the coverage- and load-based algorithm for
dynamic configuration of the channel mapped to downlink SRBs. In
addition, the RNC configures the DCH channel to carry the SRBs for the
UEs that have switched to the CELL_DCH state.
Solution
The RNC now reselects the channel for carrying SRBs by using the
coverage- and load-based algorithm for dynamic configuration of the
channel mapped to downlink SRBs.
new networks. In upgrade scenarios,
If the coverage- and load-based algorithm is enabled for dynamic

configuration of the channel mapped to downlink SRBs before an
upgrade, this solution is disabled by default after the upgrade (default
value: 0).
If the coverage- and load-based algorithm is disabled for dynamic

configuration of the channel mapped to downlink SRBs before an
upgrade, this solution is enabled by default after the upgrade (default
value: 1).

SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The number of UEs with SRBs carried on the HSDPA channel increases,
ensuring the benefits caused by the SRB over HSDPA feature on system
capacity. However, this solution increases the call drop rate.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
203
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.15 PS services experience call drops during the CS

service release after a CS service reconfiguration.
Trouble
Ticket
Number
DTS: DTS2014081602915
Description
Condition: The PERFENH_CS_PS_F2H_RATE_LIMIT_SWITCH

under the PerfEnhanceSwitch1 parameter in the SET
UCORRMPARA command is set to off. This switch controls whether
to limit the maximum data rate of HSDPA PS services after a CS service
setup triggers an F2D state transition for PS services. For a combined
service whose PS service is established prior to the CS service, the PS
service is carried over HS-DSCH in the downlink. The following
procedure is triggered:
1. The CS service is set up after the PS service transits to the
CELL_FACH state.
2. The AMR-WB code reconfiguration function takes effect and the CS
service is reconfigured.
3. The CS service is released.
NOTE
The AMR-WB code reconfiguration function takes effect when the following
MML command is executed:
CsSwitch=CS_WAMR_SF_RECONF_SWITCH-1
For other related MML configurations, see "AMRC Based on LDR" in AMR
Symptom: The PS service experiences a call drop when the CS service

is released.
Impact: The PS call drop rate increases.
Severity
Major
Root Cause
After a state transition from CELL_FACH to CELL_DCH, the PS

service is carried over HS-DSCH in the downlink and the downlink rate
is 8 kbit/s. After the AMR-WB code reconfiguration function takes
effect, the CS service is reconfigured and the layer-3 of the RNC also
reconfigures the downlink rate of the PS service. However, the RNC
fails to send the reconfigured downlink rate to layer-2. During the CS
service release, layer-2 detects that the downlink rate is abnormal and
therefore releases the PS service.
Solution
The layer-3 of the RNC now does not reconfigure the downlink rate of
the PS service during CS service reconfiguration.
Solution
Impact
After this solution is used, the PS call drop rate decreases.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
204
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.16 UEs experience mute voices after the AMR-WB code

reconfiguration function takes effect.
Trouble
Ticket
Number
DTS: DTS2014082602326
Description
Condition: The AMR-WB code reconfiguration function takes effect for

the local UE.
The current downlink rate maintained by the local RNC is the same as
the target rate reconfigured by the AMR-WB code reconfiguration
function.
The current uplink rate of the peer UE is greater than the current
downlink rate maintained by the local RNC.
The TFO/TrFO function takes effect.
NOTE
The AMR-WB code reconfiguration function takes effect when the following
MML command is executed:
CsSwitch=CS_WAMR_SF_RECONF_SWITCH-1
For other related MML configurations, see "AMRC Based on LDR" in AMR
Symptom: The local UE experiences mute voices after AMR-WB code

reconfiguration.
Impact: User experience deteriorates.
Severity
Major
Root Cause
If the current downlink rate maintained by the local RNC is the same as
the target rate reconfigured by the AMR-WB code reconfiguration
function, the local RNC directly sets the maximum downlink rate of the
local UE to the target rate, instead of sending a rate control message to
the CN to perform rate negotiation with the peer RNC. After the rate
reconfiguration, the current uplink rate of the peer UE is greater than the
maximum downlink receive rate of the local UE. As a result, the local
UE experiences mute voices.
Solution
The local RNC now sends a rate control message to the CN to perform
rate negotiation with the peer RNC before the AMR-WB code
reconfiguration. This solution ensures that the current uplink rate of the
peer UE is less than or equal to the maximum downlink rate of the local
UE.
Solution
Impact
After this solution is used, user experience improves.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
205
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.17 Operator indexes of GSM cells served by all logical

RNCs belonging to a physical RNC are modified after the
ADD UCNOPERATOR, RMV UCNOPERATOR, ADD
UCNOPEREXTPLMN, or RMV UCNOPEREXTPLMN command is
executed.
Trouble
Ticket
Number
DTS: DTS2014081306874, DTS2014062300535
Description
Condition: When RNC in Pool Node Redundancy is enabled, the

operator information about a logical RNC is modified using any of the
following commands:
ADD UCNOPERATOR
RMV UCNOPERATOR
ADD UCNOPEREXTPLMN
RMV UCNOPEREXTPLMN
Symptom: Operator indexes of GSM cells served by all logical RNCs

belonging to the physical RNC are modified. In this case, if the RNC in
Pool Load Sharing function is enabled, data inconsistency is detected
between the master RNC and the overflow RNC, and data
synchronization is triggered. The RNC in Pool Load Sharing function
becomes unavailable during data synchronization.
Impact: The inter-RAT handover success rate decreases. If RNC in Pool
Load Sharing is enabled, the RRC connection setup success rate
decreases.
Severity
Major
Root Cause
In the preceding scenario, the logical RNC ID is not checked, which

leads to the modification of operator indexes of all GSM cells on the
physical RNC without checking the logical RNC ID. In this situation,
after operator indexes of GSM cells served by the master RNC on the
physical RNC are modified, the master RNC does not actively initiate
data synchronization with the overflow RNC, leading to data
inconsistency between the master RNC and the overflow RNC, and data
synchronization is triggered. The RNC in Pool Load Sharing function
becomes unavailable during data synchronization.
Solution
The logical RNC ID is now checked, and only operator indexes of GSM
cells served the logical RNC with the specified RNC ID are modified. In
this case, after operator indexes of GSM cells served by the master RNC
are modified, the master RNC actively initiates data synchronization
with the overflow RNC, to prevent data inconsistency between the
overflow RNC and the master RNC.
Solution
Impact
The inter-RAT handover success rate increases. If RNC in Pool Load

Sharing is enabled, the RRC connection setup success rate increases.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
206
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.18 PTT service setup fails when Downlink Enhanced L2

is enabled.
Trouble
Ticket
Number
iCare: 3055899
Description
DTS: DTS2014061702438
The cell supports HSDPA services.
The Downlink Enhanced L2 feature has been enabled.
Push to talk (PTT) services are established for data transmission.
The Iub interface experiences out-of-order data transmission.
UEs do not support 3GPP TS 25.322 CR266.
NOTE
To enable Downlink Enhanced L2 only for PTT services, run the following
commands:
MOD
UCELLALGOSWITCH:
HspaPlusSwitch=DL_L2ENHANCED-1;
CellId=XXX,
SET
UCORRMALGOSWITCH:
CmpSwitch2=CMP_SINGLE_PTT_USE_DL_ENL2_SWITCH-1;
Symptom: PTT-enabled UEs cannot properly receive Call ACK

messages.
Impact: PTT services fail.
Severity
Major
Root Cause
When Downlink Enhanced L2 is enabled, the Call ACK message sent by

the RNC to a UE is encapsulated into two HS-DSCH DATA FRAME
TYPE 2 frames. Due to out-of-order data transmission over Iub, the UE
receives the second HS-DSCH DATA FRAME TYPE 2 frame first and
then the first frame. The UE discards the RLC PDU in the first frame
because of not supporting 3GPP TS 25.322 CR266. As a result, the Call
ACK message is discarded.
Solution

UDPUCFGDATA command controls whether to enable this solution.
encapsulates the Call ACK message into one HS-DSCH DATA FRAME
TYPE 2 frame and sends the frame to the UE. When this solution is
disabled, the original implementation persists.
Solution
Impact
Test Case
Issue 01 (2014-12-31)
When this solution is enabled,
PTT services are successful and user experience improves.
The value of VS.AM.RLC.Rtx.HsdpaTrf.PDU decreases.
Copyright Huawei
207
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.19 The overflow RNC becomes faulty in RNC in Pool

load sharing networking, and KPIs deteriorate significantly.
Trouble
Ticket
Number
DTS: DTS2014071709145
Description
Condition: In RNC in Pool load sharing networking, the overflow RNC

becomes faulty and the KPIs of the overflow RNC deteriorate
significantly. The master RNC is working properly.
Symptom: KPIs of the services that are handed over to the overflow
RNC deteriorate.
Impact: KPIs of the logical RNC deteriorate.
Severity
Major
Root Cause
The overflow RNC becomes faulty and KPIs such as access success rate
and call drop rate deteriorate significantly. However, no function is
available to automatically isolate the faulty overflow RNC, and
consequently services continue to be handed over to the overflow RNC
based on the load sharing algorithm.
Issue 01 (2014-12-31)

Copyright Huawei
208
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Solution

the SET UALGORSVPARAPHY command controls whether the KPI
recovery function is enabled in RNC in Pool load sharing networking.
By default, this solution is enabled (default value: 1) for both new
networks and upgrade scenarios. Bits 0 to 6 under the RsvU32Para3
parameter in the same command specify the access success rate
threshold for enabling the KPI recovery function. This threshold is in
units of percentage. The default threshold is 90 (the value 0 is mapped to
90).
In RNC in Pool load sharing networking, when the master RNC is
enabled with the KPI recovery function, it checks five types of KPIs
every 15 minutes.
Of these KPIs, if any accessibility-related KPI meets the following
conditions for two consecutive periods, the KPI recovery function is
enabled:
The access success rate of the overflow RNC is lower than the
threshold specified by bits 0 to 6 under the RsvU32Para3 parameter
in the SET UALGORSVPARAPHY command.
The difference between the access success rates of the master RNC
and logical RNC in this period is greater than 10%.
If either retainability-related KPI meets the following conditions for two

consecutive periods, the KPI recovery function is enabled:
The call drop rate of the overflow RNC is greater than 10%.
The difference between the call drop rates of the logical RNC and
master RNC is greater than 10%.
After the KPI recovery function is enabled, the system gradually reduces
the number of services that are handed over to the overflow RNC till the
KPIs of the logical RNC are recovered or till the KPIs of the logical
RNC become close to those of the master RNC.
NOTE
When the KPI recovery function is enabled, the master RNC periodically checks
the following types of KPIs:
RRC connection setup success rate

RRC connection setup success rate of the logical RNC =
(VS.RRC.SuccConnEstab.RNC/VS.RRC.AttConnEstab.RNC) x 100%
RRC connection setup success rate of the master RNC =
((VS.RRC.SuccConnEstab.RNC-VS.RRC.SuccConnEstab.NodeShare)/
(VS.RRC.AttConnEstab.RNC-VS.RRC.AttConnEstab.NodeShare)) x 100%
RRC connection setup success rate of the overflow RNC =
(VS.RRC.SuccConnEstab.NodeShare/VS.RRC.AttConnEstab.NodeShare) x
100%
CS RAB setup success rate

CS RAB setup success rate of the logical RNC =
(VS.RAB.SuccEstabCS.Conv.RNC/VS.RAB.AttEstabCS.Conv.RNC) x 100%
CS RAB setup success rate of the master RNC =
((VS.RAB.SuccEstabCS.Conv.RNCVS.RAB.SuccEstabCS.Conv.NodeShare)/(VS.RAB.AttEstabCS.Conv.RNCVS.RAB.AttEstabCS.Conv.NodeShare)) x 100%
CS RAB setup success rate of the overflow RNC equals
Issue 01 (2014-12-31)

Copyright Huawei
209
BSC6900 UMTS
Release Notes

V900R016C00SPC620
(VS.RAB.SuccEstabCS.Conv.NodeShare/VS.RAB.AttEstabCS.Conv.NodeSh
are) x 100%
PS RAB setup success rate

PS RAB setup success rate of the logical RNC =
((VS.RAB.SuccEstabPS.Bkg.RNC+VS.RAB.SuccEstabPS.Int.RNC)/
(VS.RAB.AttEstabPS.Bkg.RNC+VS.RAB.AttEstabPS.Int.RNC)) x 100%
PS RAB setup success rate of the master RNC =
((VS.RAB.SuccEstabPS.Bkg.RNC+VS.RAB.SuccEstabPS.Int.RNCVS.RAB.SuccEstabPS.Bkg.NodeShareVS.RAB.SuccEstabPS.Int.NodeShare)/
(VS.RAB.AttEstabPS.Bkg.RNC+VS.RAB.AttEstabPS.Int.RNCVS.RAB.AttEstabPS.Bkg.NodeShare-VS.RAB.AttEstabPS.Int.NodeShare)) x
100%
PS RAB setup success rate of the overflow RNC =
((VS.RAB.SuccEstabPS.Bkg.NodeShare+VS.RAB.SuccEstabPS.Int.NodeSha
re)/
(VS.RAB.AttEstabPS.Bkg.NodeShare+VS.RAB.AttEstabPS.Int.NodeShare))
x 100%
CS call drop rate

CS call drop rate of the logical RNC = (VS.RAB.AbnormRel.CS.RNC/
(VS.RAB.AbnormRel.CS.RNC+VS.RAB.NormRel.CS.RNC)) x 100%
CS call drop rate of the master RNC = ((VS.RAB.AbnormRel.CS.RNCVS.RAB.AbnormRel.CS.NodeShare)/
(VS.RAB.AbnormRel.CS.RNC+VS.RAB.NormRel.CS.RNCVS.RAB.AbnormRel.CS.NodeShare-VS.RAB.NormRel.CS.NodeShare)) x
100%
CS call drop rate of the overflow RNC = AbnormRel.CS.NodeShare +
VS.RAB.NormRel.CS.NodeShare)) x 100%
PS call drop rate

PS call drop rate of the logical RNC = (VS.RAB.AbnormRel.PS.RNC/
(VS.RAB.AbnormRel.PS.RNC+VS.RAB.NormRel.PS.RNC)) x 100%
PS call drop rate of the master RNC = ((VS.RAB.AbnormRel.PS.RNCVS.RAB.AbnormRel.PS.NodeShare)/
(VS.RAB.AbnormRel.PS.RNC+VS.RAB.NormRel.PS.RNCVS.RAB.AbnormRel.PS.NodeShare-VS.RAB.NormRel.PS.NodeShare)) x
100%
PS call drop rate of the overflow RNC =
(VS.RAB.AbnormRel.PS.NodeShare/
(VS.RAB.AbnormRel.PS.NodeShare+VS.RAB.NormRel.PS.NodeShare)) x
100%

To set the access success rate threshold for the KPI recovery function,
for example, to 90%, run the following command:
SET UALGORSVPARAPHY: RsvU32Para3=90;
Issue 01 (2014-12-31)

Copyright Huawei
210
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Solution
Impact
Test Case
The KPI recovery function affects the network as follows:
KPIs improve.
The number of UEs whose services are taken over by the overflow
RNC decreases.
The CPU usage of the master RNC increases.
6.3.2.20 The DRNC fails to identify platinum users.

Trouble
Ticket
Number
DTS: DTS2014080805175
Description
Condition: A UE establishes a PS service under the SRNC. This UE

then triggers a soft handover and establishes a radio link (RL) under the
DRNC.
Symptom: The DRNC does not identify this UE as a platinum user.
Impact: The DRNC does not identify this UE as a platinum user.
Consequently, this UE cannot preempt the resources of common users in
the case of resource insufficiency, and experience of this UE is affected.
Severity
Major
Root Cause
The DRNC does not identify this UE as a platinum user due to a

software bug.
Solution
The software bug has been fixed so that the DRNC can correctly
identify platinum users.
Solution
Impact
The DRNC can correctly identify platinum users.
Test Case
6.3.2.21 The RL reconfiguration over the Iur interface fails

due to compatibility issues.
Trouble
Ticket
Number
DTS: DTS2014082000641
Description
Condition: A Huawei RNC is interconnected with an RNC from another

vendor. When HSDPA services are reconfigured, the Huawei RNC sends
an RL RECFG PREP message to the peer RNC, indicating that the
transport layer information is not required. The peer RNC, however,
returns an RL RECFG READY message that contains transport layer
information.
Symptom: The Huawei RNC sends an RL RECFG CANCEL message
Issue 01 (2014-12-31)

Copyright Huawei
211
BSC6900 UMTS
Release Notes

V900R016C00SPC620
to the peer RNC.

Impact: The RL reconfiguration over the Iur interface fails in the
preceding scenario.
Severity
Major
Root Cause
The Huawei RNC informs the peer RNC that the transport layer
information is not required. The peer RNC, however, includes the
transport layer information in the RL RECFG READY message. The
Huawei RNC needs to perform compatibility processing under this
circumstance.
Solution
The transport layer information contained in the RL RECFG READY

message is the same as that in the service setup procedure.
RESERVED_SWITCH_0_BIT5 under the RSVSWITCH0
parameter in the SET UNRNCRSVPARA command controls
whether the RNC performs compatibility processing in the preceding
scenario. By default, this solution is disabled (default value: 0) for
When this solution is enabled, the Huawei RNC performs
compatibility processing, and the RL reconfiguration over the Iur
interface is successful. When this solution is disabled, the processing
in the preceding scenario remains unchanged.
SET UNRNCRSVPARA: NRncId=xxx,
The transport layer information contained in the RL RECFG READY

message differs from that in the service setup procedure.
RESERVED_SWITCH_0_BIT6 under the RSVSWITCH0
parameter in the SET UNRNCRSVPARA command controls
whether the RNC performs compatibility processing in the preceding
scenario. By default, this solution is disabled (default value: 0) for
When this solution is enabled, the Huawei RNC performs
compatibility processing, and the RL reconfiguration over the Iur
interface is successful. When this solution is disabled, the processing
in the preceding scenario remains unchanged.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
212
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.22 The RNC sends SPID-specific dedicated priority to

UEs that does not support LTE.
Trouble
Ticket
Number
DTS: DTS2014060408082
Description
Condition: A UE that does not support LTE initiates a PS service, and

the COMMAND ID message sent by the CN contains subscriber profile
ID (SPID).
Symptom: The UTRAN MOBILITY INFORMATION message sent by
the RNC to the UE contains SPID-specific dedicated priority.
Impact: The UE does not support LTE, so the RNC does not need to
send SPID-specific dedicated priority to the UE.
Severity
Major
Root Cause
The RNC does not check whether the UE supports LTE when sending
SPID-specific dedicated priority to the UE.
Solution
If the UE does not support LTE, the RNC does not send SPID-specific
dedicated priority to the UE.
Solution
Impact
None
Test Case
6.3.2.23 The UE experiences a call drop during a UE-notinvolved relocation.

Trouble
Ticket
Number
DTS: DTS2014082302518
Description
Condition: A UE using SRB over HSDPA initiates a serving cell change

procedure after the UE's RRC connection is established. After this
procedure, the UE is served by a cell under the DRNC. The UE
subsequently establishes a PS service that uses the Downlink Enhanced
L2 feature. Then, a UE-not-involved relocation is triggered.
Symptom: The RNC abnormally releases the UE during the UE-notinvolved relocation.
Impact: The call drop rate increases.
Severity
Major
Root Cause
In the preceding scenario, the DRNC incorrectly maintains the

information about the Downlink Enhanced L2 feature. Subsequently, the
DRNC fails to configure the PDU size for this feature, and the UE is
abnormally released.
Issue 01 (2014-12-31)

Copyright Huawei
213
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Solution
The DRNC correctly maintains the information about the Downlink

Enhanced L2 feature in the preceding scenario.
Solution
Impact
The call drop rate decreases.
Test Case
6.3.2.24 Services are interrupted after RL reestablishment.

Trouble
Ticket
Number
DTS: DTS2014081500580
Description
Scenario 1:
Condition: A UE in the CELL_DCH state establishes a service. When
the RNC is waiting for a response to the RADIO BEARER SETUP
message from the UE, RL reestablishment is triggered.
Symptom: The RNC does not receive a response from the UE within the
specified period of time after sending a CELL UPDATE CONFIRM
message to the UE during the RL reestablishment procedure.
Impact: The RL reestablishment procedure fails, and RAB setup fails.
Scenario 2:
Condition: The RNC sends a RADIO BEARER RECONFIGURATION
message to the UE, which instructs the UE to perform CELL_DCH-toCELL_DCH reconfiguration. When the RNC is waiting for a response
from the UE, RL reestablishment is triggered.
Symptom: After the RL reestablishment, data transmission of the
service is interrupted.
Severity
Major
Root Cause
Before RL reestablishment is triggered, the CELL_DCH-to-CELL_DCH

service establishment or reconfiguration process is rolled back but the
configuration of Macro Diversity Combining (MDC) parameters is not
rolled back. Therefore, the MDC configuration becomes incorrect and
some uplink signaling and service data is discarded by MDC.
Solution

in the SET UALGORSVPARA command controls whether the MDC
configuration is rolled back in the preceding situation. When this
solution is enabled, the MDC configuration is rolled back in the
preceding situation. When this solution is disabled, the MDC
configuration is not rolled back in the preceding situation. By default,
upgrade scenarios.
SET UALGORSVPARA:
Issue 01 (2014-12-31)

Copyright Huawei
214
BSC6900 UMTS
Release Notes

V900R016C00SPC620

SET UALGORSVPARA:
Solution
Impact
When this switch is set to on, the CS RAB setup success rate and PS
RAB setup success rate increases.
Test Case
6.3.2.25 RL reconfiguration fails when a service is

reconfigured from an HSUPA+ channel to an HSUPA channel.
Trouble
Ticket
Number
DTS: DTS2014081303689
Description
Condition: The SRB of a PS service is carried on an HSUPA channel

and the RB of the PS service is carried on an HSUPA+ channel. Then
the RNC triggers the serving link change process and reconfigures the
PS service to an HSUPA channel during the serving link change process.
Symptom: The RNC sends a RADIO LINK RECONFIGURATION
PREPARE message to the NodeB but receives a RADIO LINK
RECONFIGURATION FAILURE message from the NodeB.
Impact: The serving link change process fails and the service is
interrupted.
Severity
Major
Root Cause
The configuration information in the RADIO LINK

RECONFIGURATION PREPARE message sent by the RNC is
incorrect.
Solution
RESERVED_SWITCH_16_BIT17 of the RsvSwitch16 parameter in

the SET UALGORSVPARA command is used to control the solution
to this problem. When this solution is enabled, configuration
information in the RADIO LINK RECONFIGURATION PREPARE
message will be corrected. When this solution is disabled, configuration
information in the RADIO LINK RECONFIGURATION PREPARE
message will not be corrected. In deployment or upgrade scenarios, this
solution is disabled (RESERVED_SWITCH_16_BIT17 is set to 0) by
default.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
215
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.26 The point-to-point short message service cannot be

disabled on a per cell basis.
Trouble
Ticket
Number
DTS: DTS2014081505123
Description
When CS voice services do not have sufficient amount of resources in

heavy traffic scenarios, the point-to-point short message service cannot
be disabled to reserve the resources for CS voice services. A switch is
now introduced to control whether to discard the short messages in a
specific cell.
Severity
Major
Root Cause
The point-to-point short message service cannot be disabled on a per cell

basis.
Solution

the ADD UCELLCOALGOENHPARA command controls whether to
discard the short messages in a cell. By default, this solution is disabled
When this solution is enabled:
If the UE is processing CS services, the SRNC to which the best cell
belongs directly discards the received uplink or downlink short message
service (SMS) direct transfer messages.
If the UE is processing neither CS nor PS services, the SRNC releases
the UE's RRC connection.
If the UE is processing only PS services, the SRNC releases the UE's
signaling connection in the CS domain.
This solution does not take effect if the best cell belongs to the DRNC.
When this solution is disabled, the short messages in a cell are not
discarded.
ADD UCELLCOALGOENHPARA:
CellId=xxx,RsvSwitch0=RESERVED_SWITCH_0_BIT6-1;
MOD UCELLCOALGOENHPARA:
CellId=xxx,RsvSwitch0=RESERVED_SWITCH_0_BIT6-0;
Solution
Impact
The UE periodically retransmits short messages, and consequently the

UE standby time is shortened.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
216
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.2.27 The number of hash indexes used on an interface

board exceeds the maximum value during the ADD IPPATH
or ADD SCTPLNK command execution.
Trouble
Ticket
Number
iCare: 3232088
Description
Condition: Users run the MOD IPPATH command to modify the

configuration of an IP path whose Carry Flag is NULL(NULL).
DTS: DTS2014072100265
Symptom: When the number of hash indexes used on an interface

board does not reach the maximum, the error message "The number of
the hash indexes of the SCTPLINK and IPPATH has reached the
maximum value." is displayed during the ADD IPPATH or ADD
SCTPLNK command execution.
Impact: IP paths or SCTP links cannot be added to the interface board.
NOTE
Severity
Major
Root Cause
If the MOD IPPATH command is executed for the IP path whose

Carry Flag is NULL(NULL) in the preceding scenario, the hash
index table for IP paths or SCTP links on the interface board is
repeatedly applied, and therefore redundant records are generated. As a
result, the number of hash indexes available for IP paths or SCTP links
on the interface board decreases.
Solution
The application mode of the hash index table for the IP path whose
Carry Flag is NULL(NULL) has been changed to prevent repeated
table application during the MOD IPPATH command execution.
Solution
Impact
None
Test Case ID
6.3.3 Minor
6.3.3.1 The RNC fails to encode RRC-related messages
during a combined cell update and SRNS relocation.
Trouble
Ticket
Number
DTS: DTS2014062100923
Descriptio
n
Condition: UEs complying with Release 5 or Release 6 initiate a

combined cell update and SRNS relocation in the non-CELL_DCH state.
The RELOCATION REQUEST message carries HS-DSCH information,
but the information related to MAC-d flows is abnormal.
Issue 01 (2014-12-31)

Copyright Huawei
217
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Symptom: The incoming relocation fails because the downlink RRCrelated messages fail to be encoded.
Impact: The incoming relocation success rate is low.
Severity
Minor
Root
Cause
In the preceding scenario, when the RNC processes the HS-DSCH

information in the RELOCATION REQUEST message, the information
related to MAC-d flows is abnormal.
Solution
The RNC now performs compatibility processing on abnormal MAC-d

flows.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The incoming relocation success rate increases. Specifically, the value

returned by the VS.TRELOC.SuccExecUENotInvol and
VS.TRELOC.SuccExecUEInvol counter increases.
Test Case
6.3.3.2 The CELL ID+RTT positioning calculation fails.

Trouble
Ticket
Number
iCare: 2908171
Descriptio
n
Condition: An RNC initiates the CELL ID+RTT positioning, and a UE is

connected to three or more NodeBs over radio links (RLs) concurrently. In
this situation, the value of axis X or Y approaches to 0 for the UE in a
coordinate system that meets the following conditions:
DTS: DTS2014062100946
The position for the antenna of the reference cell specifies the
coordinate origin.
Axis Z is perpendicular to the sea surface.
Axis X points to the east.
Axis Y points to the north.
NOTE
RTT is short for Round Trip Time.
Symptom: After the RNC receives the RxTx measurement result of the
UE in the IE "UE Rx-Tx time difference type1" and the RTT measurement
results of all NodeBs, the CELL ID+RTT positioning calculation fails.
Then, the positioning method is degraded to CELL_CENTER, lowering
Issue 01 (2014-12-31)

Copyright Huawei
218
BSC6900 UMTS
Release Notes

V900R016C00SPC620
the positioning accuracy.

Impact: The positioning results are inaccurate.
Severity
Minor
Root
Cause
In the preceding scenario, when the value of axis X or Y approaches to 0

for the UE, an unexpected value occurs in the CELL ID+RTT positioning
calculation which causes the calculation to fail. Then, the positioning
method is degraded to CELL_CENTER, lowering the positioning
accuracy.
Solution
The CELL ID+RTT positioning algorithm is now optimized to ensure

successful CELL ID+RTT positioning.
Solution
Impact
The positioning accuracy has improved.
Test Case
6.3.3.3 There is a possibility that the interval between two

paging messages for a PTT service is 640 ms.
Trouble
Ticket
Number
DTS: DTS2014042102542
Descriptio
n
Condition: Delay variation is detected for push to talk (PTT) services

over the Iub interface.
Symptom: There is a possibility that the interval between two paging
messages for a PTT service is 640 ms.
Impact: The interval between two paging messages for a PTT service is
longer than 320 ms in the preceding scenario, affecting experience of PTT
services.
Severity
Minor
Root
Cause
This interval is determined by the paging occasion for PTT services,

which is determined by the RNC. In the preceding scenario, the RNC does
not consider the delay variation over the Iub interface when determining
the paging occasion for PTT services.
Solution
The RNC calculates the paging occasion for PTT services based on the
real-time delay over the Iub interface.
Solution
Impact
This solution reduces the interval between two paging messages for PTT
services to a value less than 320 ms.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
219
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.3.4 The UE occasionally experiences a CS service setup

failure after it initiates a cell update procedure during the
security mode command procedure.
Trouble
Ticket
Number
DTS: DTS2014050402220
Descriptio
n
Condition: After a UE establishes a PS service, it initiates a cell update

procure during the CS security mode command procedure. While waiting
for the UE's response in the cell update procedure, the RNC receives an
IU RELEASE COMMAND message from the CS domain of the core
network (CN).
Symptom: The RNC releases the UE's connection in the CS domain after
receiving the UE's response in the cell update procedure. If the UE
initiates a CS service setup request again, the CS service setup
occasionally fails.
Impact: The CS service setup occasionally fails in the preceding scenario,
and user experience is affected as a result.
Severity
Minor
Root
Cause
The UE has a compatibility issue in the preceding scenario, and

consequently the CS service setup occasionally fails.
Solution
RESERVED_SWITCH_BIT19 under the Reserved Switch parameter in

the ADD UIMEITAC command controls whether the RNC releases the
UE's connection upon receiving an IU RELEASE COMMAND message
from the CN when the cell update procedure is initiated during the
security mode command procedure. When this solution takes effect, the
RNC releases the UE's connection in the preceding scenario. When this
solution does not take effect, the RNC does not release the UE's
connection in the preceding scenario. By default, this solution is disabled
(default value: 0) for both new networks and upgrade scenarios to ensure
smooth upgrade.
ADD UIMEITAC:
TAC_FUNC=Special_User_Enhance, TAC=xx, Description="xx",
ADD UIMEITAC:
TAC_FUNC=Special_User_Enhance, TAC=xx, Description="xx",
Solution
Impact
This solution addresses the UE's compatibility issue in the preceding

scenario. After this solution takes effect, the CS service setup succeeds in
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
220
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.3.5 The values of the VS.GTPU.Pkt.Tx and

VS.GTPU.BytesPkt.Tx counters are incorrect.
Trouble
Ticket
Number
DTS: DTS2014052601371
Description
Condition: The RNC sends control packets and data packets to the
GPRS Tunneling Protocol-User plane (GTP-U) at the peer end.
Symptom: The values of the VS.GTPU.Pkt.Tx and
VS.GTPU.BytesPkt.Tx counters are less than their actual values.
Impact: The incorrect values of the VS.GTPU.Pkt.Tx and
VS.GTPU.BytesPkt.Tx counters affect the customer's observations on
the network performance.
Severity
Minor
Root Cause
When the RNC sends control packets and data packets to the GTP-U at
the peer end, the VS.GTPU.Pkt.Tx and VS.GTPU.BytesPkt.Tx
counters do not measure the control packets.
Solution
The measurement mechanisms of the VS.GTPU.Pkt.Tx and

VS.GTPU.BytesPkt.Tx counters have been modified so that the
VS.GTPU.Pkt.Tx and VS.GTPU.BytesPkt.Tx counters measure both
control packets and data packets that are sent by the RNC to the GTP-U
at the peer end.
Solution
Impact
After this solution is implemented, the values of the VS.GTPU.Pkt.Tx

and VS.GTPU.BytesPkt.Tx counters increase.
Test Case
6.3.3.6 Links become out of synchronization due to the

large transmission delay difference between cells in the
active set.
Trouble
Ticket
Number
DTS: DTS2014070817256
Description
Condition: A UE is undergoing a best cell change and the transmission

link attribute of the target best cell is different from that of the source
best cell (that is, one uses satellite transmission while the other does
not). The UE sends an event 1A or 1C report.
Symptom: After the best cell change, the RNC adds cells (contained in
the event 1A or 1C report) that have the same transmission link
attribute as the source best cell to the active set and the active set
includes both cells using satellite transmission and cells not using
satellite transmission.
Impact: The transmission delays of cells in the active set differ greatly
from each other and cells that have different transmission link attributes
from the source best cell are more likely to experience link out of
Issue 01 (2014-12-31)

Copyright Huawei
221
BSC6900 UMTS
Release Notes

V900R016C00SPC620
synchronization, which reduces the gains provided by soft handover.

Severity
Minor
Root Cause
In the preceding scenario, the RNC selects cells that have the same
transmission link attribute as the source best cell from the event 1A or
1C report. These cells will be added to the active set after the best cell
change. However, the transmission link attribute of the source best cell
changes after the best cell change but the RNC stills adds the
previously selected cells to the active set. As a result, the added cells
have different transmission link attributes from the source best cell.
Solution

in the SET UALGORSVPARA command is used to control the
solution for this problem. By default, this solution is disabled (default
When this solution is enabled, the RNC compares the transmission

link attribute of cells contained in event 1A or 1C report with that of
the source best cell after the best cell change. Only cells that have
the same transmission link attribute as the source best cell are added
to the active set.
When this solution is disabled, the original processing applies.

SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
After this problem is rectified, the number of times that links in a cell
become out of synchronization decreases.
Test Case
6.3.3.7 SAAL link-related counter is abnormal for AOUa,

AEUa, and ATM-based UOIa boards.
Trouble
Ticket
Number
DTS: DTS2012042705518
Descriptio
n
Condition: SAAL links are configured for AOUa, AEUa, and ATM-based
UOIa boards.
Symptom: The number of bytes in correct AAL5 CPS packets received
on an SAAL ATM link (measured by the counter
VS.SAALLNK.PVCLAYER.RXBYTESOFAAL5CPSPKTS) is greater
than the actual value. When the boards are upgraded from V900R014C00
or an earlier version to V900R015C00 or a later version, the value of this
counter decreases slightly.
Impact: The value of this counter is inconsistent with actual conditions so
that customers cannot observe network status.
Issue 01 (2014-12-31)

Copyright Huawei
222
BSC6900 UMTS
Release Notes

V900R016C00SPC620
NOTE
This issue has been resolved in V900R015C00. The RN is added in the current
version.
Severity
Minor
Root
Cause
When receiving an AAL5 CPS packet that is contained in one cell only,
the preceding three boards incorrectly add the IP/UOIP header of 40 bytes
to ATM-layer bytes for measurement. As a result, the counter value is
greater than the correct value.
Solution
When receiving an AAL5 CPS packet that is contained in one cell only,
the preceding three boards do not add the IP/UOIP header of 40 bytes to
ATM-layer bytes for measurement.
Solution
Impact
The counter value decreases after modification compared with that in

V900R014C00 and earlier versions.
Test Case
6.3.3.8 The CBSADDR and RNCCBCPUID objects cannot be

synchronized from the backup RNC to the master RNC.
Trouble
Ticket
Number
DTS: DTS2014073102907
Descriptio
n
Condition: In the RNC in Pool scenario, the BSC6900 serves as the

master RNC and the BSC6910 serves as the backup RNC. The
CBSADDR or RNCCBCPUID object is added to the BSC6910 and the
configuration data is synchronized from the BSC6910 to the BSC6900
using the CME.
Symptom: A failure message is returned for the ADD UCBSADDR or
ADD URNCCBCPUID command during data synchronization and data
synchronization fails.
Impact: Data cannot be synchronized from the backup RNC to the master
RNC.
Severity
Minor
Root
Cause
The configuration of the ADD UCBSADDR or ADD URNCCBCPUID

command differs between the BSC6900 and BSC6910. Take the ADD
UCBSADDR command as an example. The ADD UCBSADDR
command for the BSC6900 has two additional mandatory parameters
SRN and SN, which are absent in the ADD UCBSADDR command for
the BSC6910. As a result, data synchronization fails.
Solution
MML command configuration for the BSC6900 has been modified. The
attributes of the SRN and SN parameters in ADD UCBSADDR, and the
SRN, SN, and SSN parameters in ADD URNCCBCPUID have been
changed from mandatory to optional. If these parameters are not
configured, the system automatically allocates values for these
parameters. The allocation principle is as follows: Available boards and
subsystems are referentially allocated. The SRN, SN, and SSN with the
Issue 01 (2014-12-31)

Copyright Huawei
223
BSC6900 UMTS
Release Notes

V900R016C00SPC620
smallest number are preferentially allocated.

Solution
Impact
None
Test Case
6.3.3.9 The SPU CPU usage rises instantaneously due to the

execution of the SET UCHRSCOPE or SET UMRSCOPE
command.
Trouble
Ticket
Number
DTS: DTS2014072802274
Descriptio
n
Condition: The SET UCHRSCOPE or SET UMRSCOPE command is

executed and the ScopeType parameter under this command is set to
ByRnc.
Symptom: The SPU CPU usage rises instantaneously and the CPU usage
rise becomes more serious with the increasing number of cells configured
for the RNC.
Impact: The SPU CPU usage rises, which may affect services.
Severity
Minor
Root
Cause
When the ScopeType parameter is set to ByRnc, the setting of the CHR
or MR scope control switch (specified by the CHRScopeCtrl or
MRScopeCtrl parameter) must be modified for all cells under the RNC.
If the RNC is configured with 5100 cells, querying and modifying the
setting of this parameter for all cells take 5100 x 5100 cycles, which
dramatically increases the SPU CPU usage.
Solution
When the ScopeType parameter in the SET UCHRSCOPE or SET

UMRSCOPE command is set to ByRnc, the original processing of
setting the CHRScopeCtrl or MRScopeCtrl parameter for all cells
under the RNC is changed. Users now only need to set the RNC-level
CHRScopeCtrl or MRScopeCtrl parameter. In addition, a value
DEPEND_CELL_SWITCH is added to the CHRScopeCtrl or
MRScopeCtrl sub-parameter under the ByRnc parameter.
The SET URNCCHRSCOPE or SET URNCMRSCOPE command is

added to set the RNC-level CHR or MR scope control switch
(specified by the CHRScopeCtrl or MRScopeCtrl parameter). This
parameter can be set to ON, OFF, or DEPEND_CELL_SWITCH.
When the RNC-level CHRScopeCtrl or MRScopeCtrl parameter is set

to ON or OFF, the RNC-level parameter setting takes effect. When this
parameter is set to DEPEND_CELL_SWITCH, the cell-level parameter
setting takes effect.
To set the RNC-level CHR scope control switch to on, run the following
command:
SET URNCCHRSCOPE: CHRScopeCtrl=ON;

or
Issue 01 (2014-12-31)

Copyright Huawei
224
BSC6900 UMTS
Release Notes

V900R016C00SPC620
SET UCHRSCOPE: ScopeType=ByRnc, CHRScopeCtrl=ON;
Run the following commands to set the cell-level CHR scope control
switch to on. The following is an example:
SET
SET
or
SET
SET
URNCCHRSCOPE: CHRScopeCtrl=DEPEND_CELL_SWITCH;
UCHRSCOPE: ScopeType=ByCellId, CellId=1, CHRScopeCtrl=ON;
UCHRSCOPE: ScopeType=ByRnc, CHRScopeCtrl=DEPEND_CELL_SWITCH;
UCHRSCOPE: ScopeType=ByCellId, CellId=1, CHRScopeCtrl=ON;
To set the RNC-level MR scope control switch to on, run the following
command:
SET URNCMRSCOPE: MRScopeCtrl=ON;

or
SET UMRSCOPE:ScopeType=ByRnc, MRScopeCtrl=ON;
Run the following commands to set the cell-level MR scope control

SET
SET
or
SET
SET
URNCMRSCOPE: MRScopeCtrl=DEPEND_CELL_SWITCH;
UMRSCOPE: ScopeType=ByCellId, CellId=1, MRScopeCtrl=ON;
UMRSCOPE: ScopeType=ByRnc, MRScopeCtrl=DEPEND_CELL_SWITCH;
UMRSCOPE: ScopeType=ByCellId, CellId=1, MRScopeCtrl=ON;
Solution
Impact
None
Test Case
6.3.3.10 No statistics are available for UE transitions from

common channels to dedicated channels that are triggered
by data transmission requirements.
Trouble
Ticket
Number
DTS: DTS2014073107020
Descriptio
n
Condition: Data transmission requirements trigger UE transitions from

common channels (CELL_FACH, CELL_PCH, or URA_PCH) to
dedicated channels (CELL_DCH).
Symptom: The RNC does not provide statistics on related performance
counters.
Impact: The number of transition attempts and successful transitions
cannot be observed.
Severity
Minor
Root
Cause
The RNC does not provide statistics on related performance counters.
Solution
The following counters are enabled to measure the CELL_FACH-toCELL_DCH (F2D) state transition attempts:
Issue 01 (2014-12-31)
VS.AttRecfg.F2D.DataTransTrig: measures the number of F2D state

Copyright Huawei
225
BSC6900 UMTS
Release Notes

V900R016C00SPC620
transition attempts that are triggered by data transmission requirements

and for which both the uplink and downlink transmission channels are
DCHs.
VS.AttRecfg.F2H.DataTransTrig: measures the number of F2D state

and for which the downlink transmission channels are HS-DSCHs.
VS.AttRecfg.F2E.DataTransTrig: measures the number of F2D state

and for which the uplink transmission channels are E-DCHs.
The following counters are enabled to measure the failed and successful
F2D state transitions:
VS.FailRecfg.F2D.DataTransTrig.Cong: measures the number of F2D

state transition attempts that are triggered by data transmission
requirements but failed due to congestion.
VS.SuccRecfg.F2D.DataTransTrig: measures the number of successful

F2D state transitions that are triggered by data transmission
requirements and for which both the uplink and downlink transmission
channels are DCHs.
VS.SuccRecfg.F2H.DataTransTrig: measures the number of successful

requirements and for which the downlink transmission channels are
HS-DSCHs.
VS.SuccRecfg.F2E.DataTransTrig: measures the number of successful

requirements and for which the uplink transmission channels are EDCHs.
The following counters are enabled to measure the number of repeated

F2D state transition attempts:
VS.AttRecfg.Rep.F2D.DataTransTrig: measures the number of repeated

F2D state transition attempts that are triggered by data transmission
channels are DCHs.
VS.AttRecfg.Rep.F2H.DataTransTrig: measures the number of repeated

HS-DSCHs.
VS.AttRecfg.Rep.F2E.DataTransTrig: measures the number of repeated

The following counters are enabled to measure the number of

CELL_PCH-to-CELL_DCH or URA_PCH-to-CELL_DCH (P2D) state
transition attempts:
Issue 01 (2014-12-31)
VS.AttRecfg.P2D.DataTransTrig: measures the number of P2D state

and for which both the uplink and downlink transmission channels are
DCHs.
VS.AttRecfg.P2H.DataTransTrig: measures the number of P2D state

and for which the downlink transmission channels are HS-DSCHs.

Copyright Huawei
226
BSC6900 UMTS
Release Notes

V900R016C00SPC620
VS.AttRecfg.P2E.DataTransTrig: measures the number of P2D state

and for which the uplink transmission channels are E-DCHs.
The following counters are enabled to measure the number of successful

P2D state transitions:
VS.SuccRecfg.P2D.DataTransTrig: measures the number of successful

P2D state transitions that are triggered by data transmission
channels are DCHs.
VS.SuccRecfg.P2H.DataTransTrig: measures the number of successful

HS-DSCHs.
VS.SuccRecfg.P2E.DataTransTrig: measures the number of successful

Solution
Impact
Values of the preceding performance counters increase.
Test Case
6.3.3.11 The RNC delivers MR A-GPS measurement control

messages to UEs in the MR A-GPS blacklist immediately
after an incoming relocation.
Trouble
Ticket
Number
DTS: DTS2014081601514
Descriptio
n
Condition: The MR A-GPS function is enabled, the MR A-GPS blacklist

policy is used, and UEs are in the MR A-GPS blacklist.
Symptom: The RNC delivers MR AGPS measurement control messages
to UEs immediately after the incoming relocation.
Impact: UE compatibility issues occur.
Severity
Minor
Root
Cause
Before delivering MR A-GPS measurement control messages, the RNC

determines whether UEs are in the MR A-GPS blacklist. If yes, the RNC
does not deliver MR A-GPS measurement control messages to these UEs.
After an incoming relocation, the RNC cannot determine whether UEs are
in the MR A-GPS blacklist and immediately delivers MR AGPS
measurement control messages to these UEs.
Solution
If the MR A-GPS blacklist policy is used, the RNC delivers MR AGPS

measurement control messages to UEs only after determining that these
UEs are not in the MR AGPS blacklist.
the SET UALGORSVPARA command is used to control whether this
Issue 01 (2014-12-31)

Copyright Huawei
227
BSC6900 UMTS
Release Notes

V900R016C00SPC620
solution takes effect. By default, this solution is disabled (default value: 0)

When this solution is enabled, the RNC deliver MR AGPS measurement
control messages to UEs only after determining that these UEs are not in
the MR AGPS blacklist.
When this solution is disabled, the RNC delivers MR AGPS measurement
control messages to UEs immediately after the incoming relocation.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
None
Test Case
6.3.3.12 Some SAAL links to an AOUa board become faulty

after ATM overbooking is enabled or disabled.
Trouble
Ticket
Number
iCare: 3388586
Descriptio
n
Condition: When optical ports 0 and 1 on an AOUa board carry services,

one of the following conditions is met:
DTS: DTS2014082708574
The ACT LICENSE command is executed to activate the license for a

new RNC. The license control item Overbooking on ATM
Transmission is disabled.
The value of the license control item Overbooking on ATM

Transmission is changed in the RNC license by running the ACT
LICENSE command.
A cross-R version upgrade is performed and the license control item

Overbooking on ATM Transmission is disabled. After the upgrade, the
problem may occur.
The MOD IMAGRP, ADD IMALNK, RMV IMALNK, MOD

ATMLOGICPORT, or MOD UNILNK command is executed for
objects on optical port 1 on an AOUa board. In addition, these objects
have upper-level bearers, such as SAAL links and AAL2 paths.
Symptom: Some SAAL links become faulty.

Impact: Services on the faulty SAAL links are interrupted.
Severity
Minor
Root
Cause
An incorrect internal port No. is used to update the port bandwidth in the
preceding scenarios.
Issue 01 (2014-12-31)

Copyright Huawei
228
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Solution
A correct port No. is now used to update the port bandwidth in the
preceding scenarios.
Solution
Impact
None
Test Case
6.3.3.13 The causes for signaling link interruption or

transmission faults cannot be quickly identified.
Trouble
Ticket
Number
DTS: DTS2014070306001
Description
Condition: SCTP links are carried on an

FG2a/GOUa/FG2c/GOUc/GOUe board.
Symptom: When the SCTP links on the preceding boards are
interrupted or transmission on these links becomes faulty, the existing
information cannot help engineers quickly analyze the faults.
Impact: No method is available for engineers to quickly identify the
cause of SCTP link faults.
Severity
Minor
Root Cause
When SCTP links are interrupted or transmission on these links

becomes faulty, the existing information for quickly identifying the
fault cause is inadequate to determine whether the interface board can
correctly receive and send SCTP packets.
Solution
Packet capturing is used to collect the information about SCTP packet

headers, and tracing the route to the peer IP address using the
Tracert command is used to collect the information about the
transmission path of packets. This solution can be enabled on the
preceding boards for up to four times a day. Each packet capturing
lasts for 30s.
TS22(Time_slot_22) of Reserve switch 1 in the SET

TRANSRSVPARA command controls whether to automatically
enable the packet capturing and trace the route to the peer IP address
using the Tracert command when SCTP links become faulty. By
default, this solution is enabled (default value: 1) for both new
Solution
Impact
After this solution is used, the duration of automatic packet capturing

triggered by ALM-21388 Invalid Packets Exceeding Alarm is extended
from 10s to 30s.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
229
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.3.14 The value of the Hosted domain queried in the DSP

OPC command output is incorrect.
Trouble
Ticket
Number
iCare: 2831878
Descriptio
n
Condition: Users run the DSP OPCcommand with The host type of
signalling point set to SINGLEHOST(SINGLEHOST) or
ASSIST(ASSIST) to query the originating point code (OPC) status.
DTS: DTS2014061202688
Symptom: The value of Hosted is Yes in the DSP OPCcommand output.

Impact: The queried value of Hosted is incorrect and misleads users in
Severity
Minor
Root
Cause
The Hosted domain is invalid although its value is Yes when The host
type of signalling point is set to SINGLEHOST(SINGLEHOST) or
ASSIST(ASSIST).
Solution
Now, the value of Hosted in the DSP OPCcommand output is NULL

when The host type of signalling point is set to
SINGLEHOST(SINGLEHOST) or ASSIST(ASSIST).
Solution
Impact
None
Test Case
6.3.3.15 Optical port numbers are incorrect in ALM-21398

Optic Power Abnormal reported by a GOUa board.
Trouble
Ticket
Number
DTS: DTS2014050400801
Descripti
on
Condition: A GOUa board is used as an interface board, and optical power

is abnormal on the activated optical port.
Symptom: When ALM-21398 Optic Power Abnormal is reported, optical
port numbers are incorrect in alarm parameters. Specifically, optical port 0 is
incorrectly reported as optical port 1, and optical port 1 is incorrectly
reported as optical port 2.
Impact: Numbers of faulty optical ports that are reported are incorrect so
that customers cannot handle the alarm in time.
Severity
Minor
Root
Cause
The GOUa board has two optical ports. When it reports ALM-21398 Optic
Power Abnormal, the optical port numbers are incorrectly reported.
Specifically, optical port 0 is incorrectly reported as optical port 1, and
optical port 1 is incorrectly reported as optical port 2.
Solution
The numbers 1 and 2 in the alarm parameters have been modified to 0 and 1,
Issue 01 (2014-12-31)

Copyright Huawei
230
BSC6900 UMTS
Release Notes

V900R016C00SPC620
respectively, in parameters that are reported.

Solution
Impact
The reported optical port numbers are correct after the modification.
Test
Case
6.3.4 Suggestion
6.3.4.1 The RNC fails to reset the Iu interface in Iu-Flex
scenarios.
Trouble
Ticket
Number
DTS: DTS2014061900444
Description
Condition: In Iu Flex networking, the RNC receives a RESET message

from the CN, and the Global CN-ID IE contained in the message has a
value different from that assigned by the RNC.
Symptom: The RNC does not send a RESET ACKNOWLEDGE
message to the CN.
Impact: The RNC fails to reset the Iu interface, resulting in service
setup failures and a decrease in the values of the following counters:
VS.RAB.AttEstabPS.Bkg.RNC
VS.RAB.AttEstabPS.Conv.RNC
VS.RAB.AttEstabPS.Int.RNC
VS.RAB.AttEstabPS.Str.RNC
VS.RAB.AttEstabCS.Conv.RNC
VS.RAB.AttEstabCS.Str.RNC
VS.RAB.Num.CS.Mean
VS.RAB.Num.PS.Mean
Severity
Suggestion
Root Cause
The RNC discards the RESET message and therefore does not send a
response to the CN.
Solution

performs compatibility processing for RESET, RELOCATION
REQUEST, and PAGING messages. By default, this solution is disabled
When this solution is enabled, the RNC records the Global CN-ID
contained in the RESET, RELOCATION REQUEST, or PAGING
message and uses the Global CN-ID configured on the RNC to correctly
process the message. For the RESET message, the RNC sends a RESET
ACKNOWLEDGE message with the received Global CN-ID to the CN.
When this solution is disabled, the RNC discards the RESET or
Issue 01 (2014-12-31)

Copyright Huawei
231
BSC6900 UMTS
Release Notes

V900R016C00SPC620
RELOCATION REQUEST messages without recording the Global CNID contained in it. As for the PAGING message, the RNC randomly
selects a CN node for the CS service.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The RNC successfully resets the Iu interface. As a result, services are set
up and the values of the following performance counters increase:
VS.RAB.AttEstabPS.Bkg.RNC
VS.RAB.AttEstabPS.Conv.RNC
VS.RAB.AttEstabPS.Int.RNC
VS.RAB.AttEstabPS.Str.RNC
VS.RAB.AttEstabCS.Conv.RNC
VS.RAB.AttEstabCS.Str.RNC
VS.RAB.Num.CS.Mean
VS.RAB.Num.PS.Mean
The values of CS counters that are measured over the Iu interface

change, but the sum of these counter values on all CN nodes remain the
same. These counters are listed as follows:
Issue 01 (2014-12-31)
VS.IU.SIG.AttConnEstabCS
VS.IU.RelReqCS.sum
VS.IU.RelCmdCS.sum
VS.IU.RelReqCS.IngChkFail
VS.IU.RelReqCS.SigConnRel
VS.IU.RelReqCS.RadConnUELost
VS.IU.RelCmdCS.RelocSucc
VS.IU.RelCmdCS.NormRel
VS.IU.RelCmdCS.UTRANGen
VS.IU.RelCmdCS.RelocCan
VS.IU.RelCmdCS.NoRAB
VS.Iu.RelReqCS.RIPFail
VS.IU.RelReqCS.Preempt
VS.IU.RelReqCS.NetworkOpt
VS.IuCS.BytesPayldConv.Rx
VS.IuCS.BytesPayldStr.Rx
VS.IuCS.BytesPayldConv.Tx
VS.IuCS.BytesPayldStr.Tx
VS.IU.Auth.Req
VS.IU.Auth.Rsp

Copyright Huawei
232
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Test Case
VS.IU.SecModeCmd.Num
VS.IU.SecModeCmp.Num
VS.IU.SCCP.Tx.Con.Req
VS.IU.SCCP.Tx.Con.Succ
VS.IU.SCCP.Rx.Con.Req
VS.IU.SCCP.Rx.Con.Succ
6.3.4.2 An inappropriate message is displayed when the

pre-upgrade check item "Operating system version" fails.
Trouble
Ticket
Number
DTS: DTS2014072212025
Descriptio
n
Condition: Users perform the pre-upgrade on an OMU that runs the

Windows operation system.
Symptom: When the pre-upgrade check item "Operating system version"
fails, the upgrade tool prompts users to install the operating system patch.
However, the Windows Server 2003 operation system matching the OMU
is about to be end of service, and no more patches will be released for the
Windows Server 2003 operating system. Therefore, users cannot obtain
the latest Windows Server 2003 operation system patch.
Impact: The displayed message misleads users in the preceding scenario.
Severity
Suggestion
Root
Cause
When the "Operating system version" check item is executed, the upgrade
tool checks whether the security patch is installed in the Windows
operating system that the OMU runs. If the security patch is not installed,
the upgrade tool prompts users to install the security patch. However, the
Windows Server 2003 operating system matching the OMU is about to be
end of service, and no more patches will be released for the Windows
Server 2003 operating system. Therefore, users cannot obtain the latest
Windows Server 2003 operation system patch.
Solution
The mechanism for the "Operating system version" check item has been
modified. Once the upgrade tool checks that the OMU runs the Windows
operation system, the "Operating system version" check item fails. In
addition, the following message is displayed in the pre-upgrade report:
The Windows Server 2003 operating system matching the OMU is about
to be end of service (EOS) and needs to be switched to the latest Dopra
Linux operating system.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
233
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.4.3 ALM-22302 KPI Exceed Threshold is not reported for

KPI deterioration caused by DPUe hardware faults.
Trouble
Ticket
Number
DTS: DTS2014063001588
Description
Condition: On an RNC with a DPUe board installed, the RRC or RAB

access success rate drops for a Digital Signal Processor (DSP) after a
hardware fault occurs on the DPUe board.
Symptom: The RNC should report ALM-22302 KPI Exceed Threshold
with KPI Alarm Type being KPI Abnormality Caused by DPU
Hardware Fault, but it fails to do so.
Impact: DPUe faults cannot be promptly detected or handled.
Severity
Suggestion
Root Cause
The threshold for reporting ALM-22302 KPI Exceed Threshold with

KPI Alarm Type being KPI Abnormality Caused by DPU Hardware
Fault is excessively low. Specifically, this alarm is reported only when
the RRC or RAB access success rate for a DSP drops below 1%.
Solution
In the preceding scenario, the alarm reporting threshold has been

changed to 10% for the RRC or RAB access success rate for a DSP.
Solution
Impact
None
Test Case
6.3.4.4 The RNC fails to respond to the CN with the RAB

ASSIGNMENT RESPONSE message.
Trouble
Ticket
Number
iCare: 2758986
Description
Condition: The RNC receives a RAB ASSIGNMENT REQUEST

message from the CN that instructs the RNC to release a specific RAB.
During the RAB release process, SRB reset occurs and the RNC does
not trigger radio link reestablishment or state transition.
DTS: DTS2014061900488
Symptom: The RNC fails to respond to the CN with the RAB

Impact: The RAB release success rate of the CN decreases.
Severity
Suggestion
Root Cause
In the preceding scenario, the RNC directly releases the RRC connection
with the UE and therefore does not respond to the CN with the RAB
Solution

Issue 01 (2014-12-31)

Copyright Huawei
234
BSC6900 UMTS
Release Notes

V900R016C00SPC620
responds to the CN with the RAB ASSIGNMENT RESPONSE

message. By default, this solution is disabled (default value: 0) for both
When this solution is enabled, the RNC responds to the CN with the
RAB ASSIGNMENT RESPONSE message and then releases the RRC
connection with the UE. When this solution is disabled, the RNC does
not respond to the CN with the RAB ASSIGNMENT RESPONSE
message but directly releases the RRC connection with the UE.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The RAB release success rate of the CN increases.
Test Case
6.3.4.5 When LDR is triggered due to cell code resource

congestion, no UE cannot be selected for LDR because the
proportions of code resources utilized by all operators do
not exceed the preset limit.
Trouble
Ticket
Number
DTS: DTS2014053102894
Description
Condition: The ICR Demarcation or MOCN Demarcation feature is

enabled, and the NbmSFLdcUeSelSwitch parameter in the MOD
UCELLALGOSWITCH command is set to
NBM_SF_LDC_DEMARC.
Symptom: The RNC cannot select UEs for load reshuffling (LDR)
when LDR is triggered due to cell code resource congestion.
Impact: Code resource congestion cannot be relieved, which reduces
the UE access success rate.
Severity
Suggestion
Root Cause
When LDR is triggered due to cell code resource congestion, the RNC
selects UEs for LDR from operators whose proportion of utilized code
resources exceeds the preset limit. The RNC calculates this proportion
using the following formula: Code resources actually utilized by an
operator/Total code resources.
Total code resources include both utilized and unutilized code resources.
If the amount of unutilized code resources is large, the proportions of
code resources utilized by all operators will not exceed the limit.
Therefore, no UE can be selected for LDR.
Issue 01 (2014-12-31)

Copyright Huawei
235
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Solution
The RNC now uses the following formula to calculate the proportion of
code resources utilized by an operator: Code resources actually utilized
by an operator/Total code resources utilized by all operators.
Solution
Impact
After this solution is used, the duration of cells staying in the LDR state
due to downlink code resource congestion (indicated by the
VS.LCC.LDR.Time.DLCode counter) is reduced.
Test Case
6.3.4.6 The call drop rate of UEs in the CELL_FACH state

increases due to SRB resets.
Trouble
Ticket
Number
DTS: DTS2014062100919
Description
Condition: The RNC sends UE a traffic measurement control message

after the UE transits to the CELL_FACH state.
Symptom: The signaling radio bearer (SRB) resets.
Impact: The UE experiences call drops.
Severity
Suggestion
Root Cause
The RNC sends redundant traffic measurement control messages to the

UE that is reselected to another cell in the CELL_FACH state or
successfully transits to the CELL_FACH state.
Solution
The RNC now does not send additional traffic measurement control
messages to the UE that is reselected to another cell in the CELL_FACH
state or successfully transits to the CELL_FACH state if measurement
control parameters remain unchanged on the UE.
SETUALGORSVPARA:
Issue 01 (2014-12-31)

Copyright Huawei
236
BSC6900 UMTS
Release Notes

V900R016C00SPC620
SETUALGORSVPARA:
NOTE
When Push To Talk (PTT) services are running, this solution does not take effect.
Solution
Impact
The number of call drops caused by SRB resets decreases.
Test Case
6.3.4.7 The RNC cannot initiate redirections, handovers, or

fast return to E-UTRAN cells on frequency band 28.
Trouble
Ticket
Number
DTS: DTS2014062100761
Description
Condition: A UE supports the measurement of and access to the LTE

FDD frequency band 28, and neighboring cells and E-UTRA absolute
radio frequency channel numbers (EARFCNs) on LTE FDD frequency
band 28 have been configured on the RNC.
Symptom: The E-UTRAN cell measurement control message sent by
the RNC does not include EARFCNs on LTE FDD frequency band 28.
During the redirection or fast return, EARFCNs on LTE FDD frequency
band 28 are not included in the RRC_CONNECTION_RELEASE
message sent by the RNC to the UE.
Impact: The UE cannot access E-UTRAN cells of frequency band 28
through redirections, handovers, or fast return.
Severity
Suggestion
Root Cause
In 3GPP TS 36.104 Release 12, LTE FDD frequency bands 26 to 31 are

defined. However, the RNC does not support redirections, handovers, or
fast return to E-UTRAN cells on frequency bands 26 to 31.
Solution

the SET UALGORSVPARA command controls whether the solution
takes effect. By default, this solution is disabled (default value: 0) for
Run the following MML command to enable this solution, that is, to
enable the RNC to support redirections, handovers, or fast return to LTE
FDD bands 26 to 31:
SET UALGORSVPARA:
Run the following MML command to disable this solution, that is, not to
enable the RNC to support redirections, handovers, or fast return to LTE
FDD bands 26 to 31:
SET UALGORSVPARA:
The following lists the mapping between the LTE frequency band and
the E-UTRA absolute radio frequency channel number (EARFCN).
Issue 01 (2014-12-31)

Copyright Huawei
237
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Frequency bands 1 to 31 are LTE FDD frequency bands, and frequency

bands 33 to 43 are LTE TDD frequency bands.
Solution
Issue 01 (2014-12-31)
Frequency band 1: downlink EARFCN ranging from 0 to 599
The UMTS-to-LTE redirections, handovers, and fast return increase.

Copyright Huawei
238
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Impact
Test Case
6.3.4.8 The RNC sends the UE EARFCNs that the UE does not
support when initiating blind redirections or fast return.
Trouble
Ticket
Number
DTS: DTS2014062100761
Description
Condition: A UE supports E-UTRAN cell measurement and access.

When initiating blind redirections or fast return to an E-UTRAN cell,
the RNC includes the E-UTRA absolute radio frequency channel
number (EARFCN) in the RRC_CONNECTION_RELEASE message
sent to the UE.
Symptom: The UE is disconnected from the UMTS network and fails to
access the neighboring cell of the corresponding EARFCN.
Impact: Services are interrupted, and user experience deteriorates.
Severity
Suggestion
Root Cause
The RNC can identify whether the UE supports LTE FDD frequency
bands or LTE TDD frequency bands, but not the exact LTE frequency
band. Therefore, when selecting an EARFCN for blind redirections or
fast return, the RNC cannot determine whether the UE can access the EUTRAN cell of the EARFCN.
In this case, if the RNC sends the UE an EARFCN that the UE does not
support, the UE still attempts to access the E-UTRAN cell of the
EARFCN in vain.
Solution
If the UE supports E-UTRAN cell measurement, the RNC selects

EARFCNs based on the LTE frequency bands that the UE can measure
when initiating blind redirections or fast return.
SET UALGORSVPARA:
SET UALGORSVPARA:
NOTE
If the UE does not support E-UTRAN cell measurement, the RNC sends the UE
EARFCNs only in bands 1 to 25 or 33 to 43 when initiating blind redirections or
fast return.
Solution
Impact
Issue 01 (2014-12-31)
After the solution is enabled, values of the following counters decrease:

Copyright Huawei
239
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Test Case
VS.U2LTEHO.RRCRelease.Service
VS.U2LTEHO.RRCRelease.Sevice.Blind
6.3.4.9 The RNC incorrectly calculates the GSM cell load

when triggering a service-based or load-based UMTS-toGSM handover.
Trouble
Ticket
Number
DTS: DTS2014053003042
Description
Condition: The RNC triggers a service-based or load-based handover to

a GSM cell. During the relocation, the RNC determines the GSM cell
load based on the "Inter-System Information Transparent Container" IE
contained in the RELOCATION COMMAND message.
Symptom: Based on the received RELOCATION COMMAND
message, the RNC incorrectly determines that the GSM cell load is
unqualified for the handover and therefore cancels the handover.
However, the GSM cell load does actually meet the handover
conditions.
Impact: The service-based or load-based UMTS-to-GSM handover
fails.
NOTE
The RNC derives GSM cell load information from the "Inter-System Information
Transparent Container" IE contained in the RELOCATION COMMAND message
when the NcovHoOn2GldInd parameter in the SET UINTERRATHONCOV
command is set to ON.
Severity
Suggestion
Root Cause
The RNC incorrectly calculates the GSM cell load.
Solution
The method for calculating the GSM cell load has been corrected. As
defined in 3GPP TS 25.413, "Load Value" in the "Inter-System
Information Transparent Container" IE indicates the percentage of the
GSM cell load. The RNC now directly compares "Load Value" with the
value of CSHOOut2GloadThd or PSHOOut2GloadThd to determine
whether the GSM cell load meets the handover conditions.
SETUALGORSVPARA:
SETUALGORSVPARA:
Issue 01 (2014-12-31)

Copyright Huawei
240
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Solution
Impact

VS.IRATHO.SuccOutCS.Load
VS.IRATHO.SuccOutPSUTRAN.Load
VS.IRATHO.SuccOutCS.Service
VS.IRATHO.SuccOutPSUTRAN.Service
Test Case
6.3.4.10 The RNC fails to update the number of RB Parking

UEs in a cell in time when the number of RB Parking UEs in
the cell reaches the maximum value.
Trouble
Ticket
Number
DTS: DTS2014071006714
Description
Condition: The RB Parking feature is enabled.

Symptom: The RNC fails to initiate an RB Parking procedure as
expected or undesirably initiates an RB Parking procedure.
Impact: When radio resources in a cell become congested, the RB
Parking feature cannot increase the PS RAB setup success rate in the
cell to the expected level.
Severity
Suggestion
Root Cause
When the number of RB Parking UEs in a cell changes between the

maximum value and values less than the maximum value, the RNC fails
to update the number of RB Parking UEs in the cell in time. As a result,
the RNC incorrectly initiates an RB Parking procedure when the number
of RB Parking UEs in the cell has reached the maximum value but fails
to initiate an RB Parking procedure as expected when the number of RB
Parking UEs in the cell does not reach the maximum value.
Solution
The RNC now updates the number of RB Parking UEs in a cell in time.
Solution
Impact
None
Test Case
6.3.4.11 The RNC incorrectly sets the offset of the maximum

FACH transmit power to 0 after the execution of the MOD
USCCPCH command.
Trouble
Ticket
Number
DTS: DTS2014062009081
Description
Condition: The MML command MOD USCCPCH is executed to
Issue 01 (2014-12-31)

Copyright Huawei
241
BSC6900 UMTS
Release Notes

V900R016C00SPC620
modify configurations related to FACHs.

Symptom: After the command execution, the RNC sets the maxFACHPower information element (IE) carried in the
NBAP_COMM_TRANSP_CH_RECFG_REQ message to 0, instead of
the value configured in the MOD USCCPCH command. maxFACHPower refers to the offset of the maximum FACH transmit power
relative to the P-CPICH transmit power.
NBAP_COMM_TRANSP_CH_RECFG_REQ refers to the common
transmission channel reconfiguration request sent by the RNC to the
NodeB.
Impact: The offset of the maximum FACH transmit power is incorrectly
set to 0, which reduces the coverage range of downlink common
channels or reduces the cell capacity.
Severity
Suggestion
Root Cause
The RNC incorrectly sets the maxFACH-Power IE carried in the

NBAP_COMM_TRANSP_CH_RECFG_REQ message to 0.
Solution
The RNC now sets the maxFACH-Power IE based on the value

configured by the MOD USCCPCH command.
Solution
Impact
None
Test Case
6.3.4.12 The NodeB returns a failure message for RL setup

or reconfiguration when the DC-HSDPA+MIMO and CPCDTX/DRX features are both configured or the DBHSDPA+MIMO and CPC-DTX/DRX features are both
configured.
Trouble
Ticket
Number
DTS: DTS2014061800105
Description
Condition: The DC-HSDPA+MIMO and CPC-DTX/DRX features are

both configured or the DB-HSDPA+MIMO and CPC-DTX/DRX
features are both configured.
Symptom: The NodeB returns a failure message for radio link (RL)
setup or reconfiguration.
Impact: The success rate of RL setups or reconfigurations is low.
Severity
Suggestion
Root Cause
When the CPC-DTX/DRX feature is enabled, the SET

UDTXDRXPARA command is executed to set the
CQIFbCkinInDTXDRXmode parameter to configure the channel
quality indicator (CQI) feedback cycle. The default value of this
parameter is 2 ms. According to 3GPP TS 25.214, however, the value of
the CQI feedback cycle must be at least 4 ms when the DC-
Issue 01 (2014-12-31)

Copyright Huawei
242
BSC6900 UMTS
Release Notes

V900R016C00SPC620
HSDPA+MIMO or DB-HSDPA+MIMO feature is used. Therefore, the

NodeB returns a failure message.
Solution
1. The following two constraints must be met during the configuration of

the CQI feedback cycle:
Constraint 1: The CQI feedback cycle must be set to at least 4 ms

when the DC-HSDPA+MIMO or DB-HSDPA+MIMO feature is
used.
Constraint 2: The value of the DtxCycle2 parameter in the SET

UDTXDRXPARA command must be an integer multiple or a
divisor of the value of the CQI feedback cycle divided by 2.
2. The RNC configures the CQI feedback cycle according to the

following rules:
When the DC-HSDPA+MIMO and CPC-DTX/DRX features are not

configured at the same time and the DB-HSDPA+MIMO and CPCDTX/DRX features are not configured at the same time:
(1) If constraint 2 is met, the SET UDTXDRXPARA command is
executed to set the CQIFbCkinInDTXDRXmode parameter to
configure the CQI feedback cycle.
(2) If constraint 2 is not met, the RNC sets the CQI feedback cycle to
2 ms.
When the DC-HSDPA+MIMO and CPC-DTX/DRX features are both

configured or the DB-HSDPA+MIMO and CPC-DTX/DRX features
are both configured:
(1) If constraint 2 is met, the RNC sets the CQI feedback cycle to at
least 4 ms.
(2) If constraint 2 is not met:
Solution
Impact
Test Case
Issue 01 (2014-12-31)
When the DtxCycle2 parameter in the SET UDTXDRXPARA

command is not set to D5, the RNC sets the CQI feedback cycle
to 4 ms.

command is set to D5 and the maximum Dtx Cycle2 supported by
the cell is greater than or equal to D10, the RNC sets the CQI
feedback cycle to 4 ms and the Dtx Cycle2 to D10.

command is set to D5 and the maximum Dtx Cycle2 supported by
the cell is less than D10, the RNC returns a parameter
configuration failure message and attempts to perform a channel
fallback. In this case, the CPC-DTX/DRX feature cannot be
configured.
After this solution is used in the preceding scenario, the values of the
following counters increase:
VS.IUB.SuccRLRecfg
VS.IUB.SuccRLSetup

Copyright Huawei
243
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.4.13 The RNC incorrectly determines whether WRFD160208 160 HSPA Users per Cell and WRFD-160209 192
HSPA Users per Cell are enabled.
Trouble
Ticket
Number
DTS: DTS2014071106061
Description
Condition:
The RNC incorrectly determines whether WRFD-160208 160 HSPA
Users per Cell is enabled in the following scenarios:
The cell configuration meets the following condition: The value of the
MaxHsdpaUserNum parameter under the UCELLCAC MO is
greater than 128.
Algorithm parameters for the NodeB controlling the cell meet the
following condition: Under the UNODEBALGOPARA MO, the
value of the NodeBHsupaMaxUserNum parameter is less than 128
and the value of the NodeBHsdpaMaxUserNum parameter is
greater than 128.
The UCELLHSDPA MO is activated for the cell.
The RNC incorrectly determines whether WRFD-160209 192 HSPA

Users per Cell is enabled in the following scenarios:
The cell configuration meets the following condition: The value of the
MaxHsdpaUserNum parameter under the UCELLCAC MO is
greater than 160.
Algorithm parameters for the NodeB controlling the cell meet the
following condition: Under the UNODEBALGOPARA MO, the
value of the NodeBHsupaMaxUserNum parameter is less than 160
and the value of the NodeBHsdpaMaxUserNum parameter is
greater than 160.
The UCELLHSDPA MO is activated for the cell.
Symptom: ALM-20259 Number of Resources Used Exceeding Alarm

Threshold Specified by License should have been reported but not when
the number of resources actually used by WRFD-160208 160 HSPA
Users per Cell or WRFD-160209 192 HSPA Users per Cell exceeds the
capacity limit specified in the license file.
Impact: ALM-20259 Number of Resources Used Exceeding Alarm
Threshold Specified by License fails to be reported when the actual
license recourse usage exceeds the capacity limit.
Severity
Suggestion
Root Cause
The RNC should use the NodeBHsdpaMaxUserNum parameter under

the UNODEBALGOPARA MO to determine whether WRFD-160208
160 HSPA Users per Cell or WRFD-160209 192 HSPA Users per Cell is
enabled, instead of the NodeBHsupaMaxUserNum parameter.
However, when the value of the NodeBHsdpaMasxUserNum
parameter exceeds the preset threshold and the value of the
NodeBHsupaMaxUserNum parameter is less than the preset threshold,
the RNC incorrectly determines that both the values of two parameters
are less than the preset threshold. As a result, the RNC determines that
Issue 01 (2014-12-31)

Copyright Huawei
244
BSC6900 UMTS
Release Notes

V900R016C00SPC620
WRFD-160208 160 HSPA Users per Cell or WRFD-160209 192 HSPA

Users per Cell is not enabled. In this case, the conditions for reporting
ALM-20259 Number of Resources Used Exceeding Alarm Threshold
Specified by License are not met, and therefore this alarm is not
reported.
Solution
The RNC now uses the NodeBHsdpaMaxUserNum parameter to

determine whether WRFD-160208 160 HSPA Users per Cell or WRFD160209 192 HSPA Users per Cell is enabled, instead of the
NodeBHsupaMaxUserNum parameter.
Solution
Impact
The RNC can correctly determine whether WRFD-160208 160 HSPA

Users per Cell or WRFD-160209 192 HSPA Users per Cell is enabled,
and ALM-20259 Number of Resources Used Exceeding Alarm
Threshold Specified by License can be reported normally.
Test Case
6.3.4.14 FAM data differs from BAM data if the MOD

UCELLNAME command is executed after cell relocation.
Trouble
Ticket
Number
iCare: 3150231
Description
Condition: After dynamic cell distribution is enabled and a cell is

automatically relocated, then MOD UCELLNAME command is
executed to modify the name of the cell.
DTS: DTS2014071105778
Symptom: After the ACT CRC command is executed, the output shows
that front administration module (FAM) data differs from back
administration module (BAM) data.
Impact: Services are not impacted but ALM-20736 Data Inconsistency
Between OMU and Host is reported each early morning.
Severity
Suggestion
Root Cause
Configurations modified by running the MOD UCELLNAME

command do not need to be synchronized to the FAM. However, some
data that needs to be synchronized to the FAM is modified by this
command, which causes data inconsistency between the FAM and
BAM.
Solution
The implementation codes of the MOD UCELLNAME command have

been modified to ensure that only the "CELLNAME" field is modified.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
245
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.4.15 Some terminals display the GPS icon that should

not be displayed.
Trouble
Ticket
Number
DTS: DTS2014071100118
Description
Condition:
On the RNC side, MR_LCS_MEAS_SWITCH_10 under MR

Report Configure Switch in the SET UMRCTRL command is set
to on.
On the RNC side, LCS_AGPS_UEBASED_SWITCH_1 or

LCS_AGPS_STANDALONE_SWITCH_2 under MR LCS
Method Switch in the SET UMRCTRL command is set to on to
start the MR A-GPS measurement.
Symptom: Some terminals that receive an MR A-GPS measurement

control message display the GPS icon.
Severity
Suggestion
Root Cause
Some terminals that receive an MR A-GPS measurement control

message display the GPS icon due to the compatibility issue.
Solution
An A-GPS whitelist, excluding terminals having the compatibility

issue, has been added to the RNC so that the RNC sends the
periodical MR A-GPS measurement control message only to
terminals in this whitelist.
The RNC identifies terminals not having the compatibility issue as
special terminals by using the ADD UIMEITAC or MOD
UIMEITAC command. With RESERVED_SWITCH_BIT20 under
RsvSwitch in the ADD UIMEITAC or MOD UIMEITAC
command set to on, the RNC adds such special terminals to the AGPS whitelist. When RESERVED_SWITCH_BIT20 is set to on,
the RNC sends the periodical MR A-GPS measurement control
message only to special terminals. When
RESERVED_SWITCH_BIT20 is set to off, the RNC does not send
the periodical MR A-GPS measurement control message to special
terminals.
This function is disabled (set to 0) by default. In upgrade scenarios,
this function is disabled (set to 0) by default.
To add special terminals to the A-GPS whitelist, run the following

command:
ADD UIMEITAC:
TAC_FUNC=Special_User_Enhance,TAC=xxxxxxx,Description
="XXXXXX",RsvSwitch=RESERVED_SWITCH_BIT20-1;
To remove special terminals from the A-GPS whitelist, run the

following command:
ADD UIMEITAC:
TAC_FUNC=Special_User_Enhance,TAC=xxxxxxx,Description
="XXXXXX",RsvSwitch=RESERVED_SWITCH_BIT20-0;
Issue 01 (2014-12-31)

Copyright Huawei
246
BSC6900 UMTS
Release Notes

V900R016C00SPC620
RESERVED_SWITCH_13_BIT9 under RsvSwitch13 in the SET

UALGORSVPARA command controls whether the A-GPS whitelist
policy takes effect. When RESERVED_SWITCH_13_BIT9 is set
to on, the A-GPS whitelist policy takes effect. When
RESERVED_SWITCH_13_BIT9 is set to off, the A-GPS whitelist
policy does not take effect. By default, this solution is disabled
(default value: 0) for both new networks and upgrade scenarios. To
enable a whitelist, run the following command:
SET UALGORSVPARA:
To disable a whitelist, run the following command:

SET UALGORSVPARA:
Solution
Impact
After the A-GPS whitelist policy takes effect, the RNC does not enable
the MR A-GPS function for terminals not in the A-GPS whitelist.
Test Case
6.3.4.16 Power consumption of some terminals increases

because they fail to disable the A-GPS function.
Trouble
Ticket
Number
DTS: DTS2014071100118
Description
Condition:
On the RNC side, MR_LCS_MEAS_SWITCH_10 under MR

Report Configure Switch in the SET UMRCTRL command is set
to on.
On the RNC side, LCS_AGPS_UEBASED_SWITCH_1 or

LCS_AGPS_STANDALONE_SWITCH_2 under MR LCS
Method Switch in the SET UMRCTRL command is set to on to
start the MR A-GPS measurement.
Symptom: Some terminals turn on their GPS receivers upon reception

of an MR A-GPS measurement control message. However, they cannot
turn off the GPS receiver after the measurement.
Impact: Power consumption of these terminals increases.
Severity
Suggestion
Root Cause
Due to the compatibility issue, some terminals fail to turn off their GPS
receivers after they turn them on.
Solution
The RNC now sends the MR A-GPS measurement control message only
to the terminals having the compatibility issue, requiring these terminals
to report the measurement results for only once.
The RNC identifies terminals not having the compatibility issue as
special terminals by using the ADD UIMEITAC or MOD UIMEITAC
command. RESERVED_SWITCH_BIT21 under RsvSwitch in the
Issue 01 (2014-12-31)

Copyright Huawei
247
BSC6900 UMTS
Release Notes

V900R016C00SPC620
ADD UIMEITAC or MOD UIMEITAC command controls whether

the RNC sends the MR A-GPS measurement control message, requiring
the special terminals to report the measurement results for only once.
When RESERVED_SWITCH_BIT21 is set to on, the RNC sends the
MR A-GPS measurement control message, requiring the special
terminals to report the measurement results for only once. When
RESERVED_SWITCH_BIT21 is set to off, the RNC sends the
periodical MR A-GPS measurement control message to the special
terminals. This function is disabled (set to 0) by default. In upgrade
scenarios, This function is disabled (set to 0) by default.
To set RESERVED_SWITCH_BIT21 to on, run the following

command:
ADD UIMEITAC:
TAC_FUNC=Special_User_Enhance,TAC=xxxxxxx,Description="X
XXXXX",RsvSwitch=RESERVED_SWITCH_BIT21-1;
To set RESERVED_SWITCH_BIT21 to off, run the following

command:
ADD UIMEITAC:
TAC_FUNC=Special_User_Enhance,TAC=xxxxxxx,Description="X
XXXXX",RsvSwitch=RESERVED_SWITCH_BIT21-0;
Solution
Impact
None
Test Case
6.3.4.17 The SPU subsystem is reset due to excess soft

handover messages.
Trouble
Ticket
Number
DTS: DTS2014073009268
Description
Condition: Transmission resource congestion leads to repetitive soft

handover attempts.
Symptom: Excess soft handover messages overload the CPU of the
SPU subsystem and the CPU usage remains 100% for a long period of
time.
Impact: The SPU subsystem is reset.
Severity
Suggestion
Root Cause
When the transmission resources are congested, transmission resource

application for soft handovers fails and UEs cannot perform soft
handovers. If UEs repetitively initiate soft handover attempts, the CPU
of the SPU subsystem will be overloaded.
Solution
Flow control is now performed on soft handovers if the CPU usage of

the SPU subsystem exceeds a predefined threshold. If the CPU usage of
the SPU subsystem is greater than or equal to the soft handover flow
control threshold, the flow control probability is increased by 20% every
Issue 01 (2014-12-31)

Copyright Huawei
248
BSC6900 UMTS
Release Notes

V900R016C00SPC620
second until it reaches 100%. If the CPU usage of the SPU subsystem is
lower than the soft handover flow control threshold, the flow control
probability is reduced by 10% every second until it reaches 0%.
RESERVED_SWITCH_2_BIT3under the RsvSwitch2 parameter in
the SET UALGORSVPARAPHY command is used to control whether
this solution takes effect. By default, this solution is enabled (default
The soft handover flow control threshold is specified by the
RsvU8Para3 parameter in the SET UALGORSVPARAPHY
command. By default, this parameter is set to 0 (that is, the RNC uses
the value 97 as the flow control threshold) for both new networks and
upgrade scenarios. The valid parameter value range is 80 to 100. If this
range is exceeded, the RNC uses the value 97 as the flow control
threshold.
To set the soft handover flow control threshold to 97, run the following
command:
SET UALGORSVPARAPHY: RsvU8Para3=97;
Solution
Impact
After this solution is used, SPU subsystem resets caused by SPU CPU
overload due to excess soft handover messages can be prevented.
Test Case
6.3.4.18 The RNC fails to clear the timer as excepted after

UEs whose resources are preempted enter the RB Parking
state.
Trouble
Ticket
Number
DTS: DTS2014073104187
Description
Condition: A UE whose resources are preempted (referred to as a

preempted UE) is undergoing an RB Parking procedure. After delivering
an RRC_RB_RECFG message to the UE (instructing the UE to perform
a CELL_DCH to CELL_FACH state transition), the RNC starts a 2second timer. If the RNC does not receive an RRC_RB_RECFG_CMP
message from the UE before the timer expires, the RNC releases the
RRC connection of the UE. In the 2s,
1. The RNC does not receive the RRC_RB_RECFG_CMP message
from the UE.
2. The RNC abnormally releases the RRC connection of the UE.
3. After a new UE is admitted, the RNC allocates the same UE ID to the
Issue 01 (2014-12-31)

Copyright Huawei
249
BSC6900 UMTS
Release Notes

V900R016C00SPC620
new UE as that of the abnormally released UE.

Symptom: New UEs that are admitted after the timer expires are
forcibly released.
Impact: UEs experience abnormal call drops.
Severity
Suggestion
Root Cause
The RNC fails to clear the 2-second timer after abnormally releasing the
RRC connection of a preempted UE that is undergoing an RB Parking
procedure.
Solution
The RNC now clears the 2-second timer after abnormally releasing the
RRC connection of a preempted UE that is undergoing an RB Parking
procedure.
Solution
Impact
After this solution is used, the CS and PS call drop rates decrease.
Test Case
6.3.4.19 The block status of cells and NodeBs cannot be

synchronized from the master RNC to the backup RNC.
Trouble
Ticket
Number
DTS: DTS2014071900384
Description
Condition: In the RNC in Pool scenario, the BLK UNODEB or BLK

UCELL command is executed on the master RNC to block a NodeB or
cell. The configuration data is then synchronized from the master RNC
to the backup RNC using the CME.
Symptom: The block status (specified by the BLKSTATUS parameter)
of the cell and NodeB fails to be synchronized to the backup RNC.
Impact: Configurations between the master and backup RNCs are
inconsistent.
Severity
Suggestion
Root Cause
The block status of NodeBs and cells is not selected during data
synchronization.
Solution
The block status of NodeBs and cells is now selected and synchronized
to the backup RNC.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
250
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.4.20 The MR function does not take effect for UEs whose
best cells are DRNC cells.
Trouble
Ticket
Number
DTS: DTS2014071100118
Description
Condition:
The MR function is enabled for the SRNC and the SRNC delivers an
MR measurement control message to a UE.
The UE's best cell changes from an SRNC cell to a DRNC cell.
Symptom: After the best cell change, the SRNC delivers an MR

measurement control release message to the UE.
Impact: The MR function does not take effect.
Severity
Suggestion
Root Cause
The MR function does not take effect for UEs whose best cells are
DRNC cells.
Solution
The MR function now can take effect for UEs whose best cells are
DRNC cells if the RNC-level MR function is enabled for the SRNC.
RESERVED_SWITCH_13_BIT10under the RsvSwitch13 parameter
in the SET UALGORSVPARA command is used to control whether
this solution takes effect. By default, this solution is disabled (default
SET UALGORSVPARA:
SET UALGORSVPARA:
NOTE
The RNC-level MR function takes effect only when the result negotiated by manmachine and machine-machine commands is ON.
Solution
Impact
After this solution takes effect, Iur transmission load increases.
Test Case
6.3.4.21 Call drops occur because soft handovers cannot be

triggered in time after incoming static relocations over the
Iur interface are complete.
Trouble
Ticket
Number
DTS: DTS2014032400703
Description
Condition: Incoming static relocations are triggered.
Issue 01 (2014-12-31)

Copyright Huawei
251
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Symptom: Soft handovers cannot be triggered in time after the

relocations are complete, and consequently call drops occur.
Severity
Suggestion
Root Cause
After an incoming static relocation is complete, the RNC sends a

RADIO BEARER RECONFIGURATION message with the NAS
Synchronisation Indicator to the UE. Consequently, the RNC does not
send a measurement control message to the UE in time. Soft handovers
cannot be triggered in time, and call drops occur.
Solution
RELOC_IN_PROCESS_OPT_SWITCH under the

OptimizationSwitch5 parameter in the SET URRCTRLSWITCH
command controls whether the DRNC sends a RADIO BEARER
RECONFIGURATION message to the UE after an incoming static
relocation is complete and whether this message contains the
ActivationTime information element (IE). By default, this solution is
When this solution is enabled, the RNC compares the NAS
Synchronisation Indicator in the SRNC RRC container in the relocation
procedure with that sent by the CN.
If they are consistent, the RNC determines that the NAS
Synchronisation Indicator sent by the CN is consistent with that used by
the UE and does not send it to the UE again.
If they are inconsistent, the RNC sends a RADIO BEARER
RECONFIGURATION message with the NAS Synchronisation
Indicator to the UE, and this message does not contain the
ActivationTime IE.
SET URRCTRLSWITCH:
OptimizationSwitch5=RELOC_IN_PROCESS_OPT_SWITCH-1;
SET URRCTRLSWITCH:
OptimizationSwitch5=RELOC_IN_PROCESS_OPT_SWITCH-0;
Solution
Impact
The call drop rate decreases after this solution takes effect.
Test Case
6.3.4.22 Service groups that are added for a differentiated

services code point (DSCP) after the digital signal processor
(DSP) is successfully loaded do not take effect.
Trouble
Ticket
Number
DTS: DTS2014062508955
Description
Condition: The ADD UCNDSCPSERV command is executed to add

service groups and one to five IP address entities (pairs of IP address and
Issue 01 (2014-12-31)

Copyright Huawei
252
BSC6900 UMTS
Release Notes

V900R016C00SPC620
mask) for a DSCP. Then the DSP is reset.

Symptom: After the DSP is loaded successfully, the ADD
UCNDSCPSERV command is executed again to add service groups for
the DSCP, but the configuration fails to take effect.
Impact: The function of identifying the core network is affected.
Severity
Suggestion
Root Cause
After the DSP is loaded successfully, an incorrect mechanism is used to

maintain the existing configuration, so the configured IP address entities
are configured again, leading to the fact that the number of IP address
entities configured for the DSCP reaches the limitation. As a result, the
service groups added after the DSP is loaded successfully do not take
effect.
Solution
After a DSP is loaded, service groups that have been added for a DSCP
before loading of the DSP will not be added once more.
Solution
Impact
None
Test Case
6.3.4.23 The "Cell Load Information Group" IE in the

RELOCATION REQUIRED message cannot be parsed.
Trouble
Ticket
Number
DTS: DTS2014081801583
Description
Condition: The RNC triggers cell load-based UMTS-to-GSM CS

handovers.
Symptom: The LMT and U2000 cannot parse the "Cell Load
Information Group" information element (IE) subordinate to the optional
IE "Old BSS to New BSS Information" contained in the RELOCATION
REQUIRED message.
Issue 01 (2014-12-31)

Copyright Huawei
253
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Impact: The load status of UMTS cells cannot be obtained.

Severity
Suggestion
Root Cause
The RNC does not provide the LMT and U2000 with a solution to parse
the "Cell Load Information Group" IE subordinate to the optional IE
"Old BSS to New BSS Information" contained in the RELOCATION
REQUIRED message.
Solution
The RNC now provides the LMT and U2000 with a solution to parse the
"Cell Load Information Group" IE subordinate to the optional IE "Old
BSS to New BSS Information" contained in the RELOCATION
REQUIRED message.
Issue 01 (2014-12-31)

Copyright Huawei
254
BSC6900 UMTS
Release Notes

V900R016C00SPC620
NOTE
1. The RNC carries the optional IE "Old BSS to New BSS Information" contained
in the RELOCATION REQUIRED message only in a procedure for cell loadbased UMTS-to-GSM CS handovers.
2. Generally, the optional IE "Old BSS to New BSS Information" is in the lengthvalue (LV) format. When this solution is enabled, the LMT and U2000 can parse
the "Cell Load Information Group" IE.
However, when the cell load TL input switch (specified by
LOAD_IRAT_HO_RNC_FILL_TL) is turned on, the optional IE "Old BSS to
New BSS Information" contains an extra 1-byte Tag field, which changes the
optional IE "Old BSS to New BSS Information" from the LV format to the taglength-value (TLV) format. As a result, when this solution is enabled, the LMT
and U2000 still cannot parse the "Cell Load Information Group" IE.
LOAD_IRAT_HO_RNC_FILL_TL under the PROCESSSWITCH2 parameter
in the SET URRCTRLSWITCH command controls whether to turn on the cell
load TL input switch. This parameter is an advanced parameter. To change the
value of this parameter, contact Huawei Customer Service Center for technical
support.
3. Install mediation packages of BSC6900V900R015C00SPH565 or later on the
U2000 client.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
255
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.4.24 A UE in the CELL_FACH state fails to initiate CS

services.
Trouble
Ticket
Number
DTS: DTS2014071103543
Description
Condition: A UE is processing PS services in the CELL_FACH state.

The UE then initiates CS services and at the same time triggers a cell
update procedure.
Symptom: The CS RAB setup fails.
Impact: The CS RAB setup success rate decreases.
Severity
Suggestion
Root Cause
The RB setup procedure concurs with the cell update procedure in the
preceding scenario, and consequently the CS RAB setup fails.
Solution
When a UE in the CELL_FACH state sends an Initial Direct Transfer

message to initiate CS services, the RNC switches the UE from the
CELL_FACH state to the CELL_DCH state and then establishes a CS
RAB for the UE in the CELL_DCH state.
NOTE
UEs in the CELL_FACH state rarely send an Uplink Direct Transfer message to
initiate CS services. Therefore, no solution is developed for this scenario.

both new networks and upgrade scenarios. When this solution takes
effect, the RNC switches the UE to the CELL_DCH state and then
establishes a CS RAB for the UE. When this solution does not take
effect, the RNC establishes a CS RAB for the UE in the CELL_FACH
state.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The value of the VS.RAB.FailEstabCS.CellUpd counter decreases, and

the CS RAB setup success rate increases.
Test Case
6.3.4.25 There are no license control items in the license file

for features that are changed from trial features.
Trouble
Ticket
Issue 01 (2014-12-31)
DTS: DTS2014071603033

Copyright Huawei
256
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Number
Description
Condition: The RNC is upgraded from a version earlier than BSC6910

V100R016/BSC6900 V900R016 to BSC6910 V100R016/BSC6900
V900R016 or later. One of the following features has been enabled
before the upgrade, but the license control item of the feature is not
included in the license file after the upgrade.
Symptom: The feature becomes unavailable after the upgrade.

Impact: The preceding features are under license control in BSC6900
V900R016. If the corresponding licenses are not obtained, these features
become unavailable.
Severity
Suggestion
Root Cause
The preceding features are trial features before the upgrade and are
controlled only by switches. After the upgrade, trial features are changed
to commercial features, and corresponding license control items need to
be obtained. Otherwise, these features become unavailable after the
upgrade.
Solution
A check mechanism has been added to the pre-upgrade process. If the

switches controlling the preceding features are set to on but no license
control items are available in the license file for these features, a
message is displayed, informing operators that the corresponding license
control items are missing and advising them to apply for these license
control items at the earliest time possible.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
257
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.4.26 The RNC does not support measurements of

downlink PS service quality related to multiple throughput
thresholds during the same period.
Trouble
Ticket
Number
DTS: DTS2014081700402
Description
Condition: During the PS service data transmission, performance

counters related to PS service quality are measured.
Symptom:
1. The RNC cannot measure counters corresponding to multiple
downlink PS throughput thresholds of a cell during the same period.
These counters are as follows:
Number of times the DL PS requirement exceeds the threshold for a

cell
Number of times the required DL PS throughput exceeds the threshold

for a cell
Total traffic when the DL PS requirement exceeds the threshold for a

cell
2. The performance call history record (PCHR) does not log the
buffered traffic and transmitted traffic on the RLC layer during the
data transmission of downlink PS services.
Impact: The customer cannot easily observe the downlink PS service
quality.
Severity
Suggestion
Root Cause
Only one downlink PS throughput threshold can be specified on the

RNC for measurement of the preceding counters in the same period.
Solution
The following old counters are used:
The VS.PS.DLRequest.OverThd counter is used to measure the

number of times the DL PS requirement exceeds DL PS throughput
threshold 0 for a cell.
The VS.PS.DLThroughput.OverThd counter is used to measure the

number of times the required DL PS throughput exceeds threshold 0
for a cell.
The VS.PS.DLRequest.OverThd.Traffic counter is used to measure the

total traffic when the DL PS requirement exceeds threshold 0 for a
cell.
The following reserved counters are used:
Issue 01 (2014-12-31)
The VS.Reserve.Counter15 counter is used to measure the number of

times the DL PS requirement exceeds DL PS throughput threshold 1
for a cell.

times the required DL PS throughput exceeds threshold 1 for a cell.
The VS.Reserve.Counter17 counter is used to measure the total traffic

when the DL PS requirement exceeds threshold 1 for a cell.

Copyright Huawei
258
BSC6900 UMTS
Release Notes

V900R016C00SPC620
times the DL PS requirement exceeds DL PS throughput threshold 2

for a cell.

times the required DL PS throughput exceeds threshold 2 for a cell.
The VS.Reserve.Counter20 counter is used to measure the total traffic

when the DL PS requirement exceeds threshold 2 for a cell.
There are two solutions of applying downlink PS throughput thresholds

0, 1, and 2. Solution 1 uses cell-level thresholds. Solution 2 uses RNClevel thresholds.
Solution 1:
To apply cell-level downlink PS throughput thresholds 0, 1, and 2, do as

follows:
To apply cell-level downlink PS throughput threshold 0, run the MML

command ADD/MOD UCELLCOALGOENHPARA with
set to 1. In deployment and upgrade scenarios, this threshold is
disabled (RESERVED_SWITCH_0_BIT2 is set to 0) by default.


To enable solution 1, run the following command:

ADD/MOD UCELLCOALGOENHPARA:
CellId=xxxxx,RsvSwitch0=RESERVED_SWITCH_0_BIT21&RESERVED_SWITCH_0_BIT31&RESERVED_SWITCH_0_BIT4-1;
To disable solution 1, run the following command:
ADD/MOD UCELLCOALGOENHPARA:
CellId=xxxxx,RsvSwitch0=RESERVED_SWITCH_0_BIT20&RESERVED_SWITCH_0_BIT30&RESERVED_SWITCH_0_BIT4-0;
Cell-level downlink PS throughput thresholds are specified using the
following parameters:
Issue 01 (2014-12-31)
Cell-level downlink PS throughput threshold 0: RsvU8Para0

parameter in the ADD/MOD UCELLCOALGOENHPARA
command

command

command

Copyright Huawei
259
BSC6900 UMTS
Release Notes

V900R016C00SPC620
NOTE
Both the GUI value range and effective value range of the preceding three
parameters are 0 to 255, and the unit is 100 kbit/s.
In deployment or upgrade scenarios, run the following MML command to set celllevel downlink PS throughput thresholds to the default values:
ADD UCELLCOALGOENHPARA:
CellId=xxxxx, RabCombDrdSwitchValid=FALSE, RsvU8Para0=10,
RsvU8Para1=15, RsvU8Para2=20;
Solution 2:
Apply RNC-level downlink PS throughput threshold 0, 1, or 2 if the
corresponding cell-level threshold is not used or does not take effect.
RNC-level downlink PS throughput thresholds 0, 1, and 2 are
specified using the following parameters:
RNC-level downlink PS throughput threshold 0:
DLServiceThrouThd parameter in the SET UDPUCFGDATA
command.
RNC-level downlink PS throughput threshold 1: bits 16 to 31 of the
RsvdPara2 parameter in the SET UDPUCFGDATA command.
RNC-level downlink PS throughput threshold 2: bits 0 to 15 of the
RsvdPara4 parameter in the SET UDPUCFGDATA command.
NOTE
The GUI value range of bits 16 to 31 of theRsvdPara2 parameter in the SET
UDPUCFGDATA command is 0 to 65535 and the effective value range is 0 to
20000, with the unit of 10 kbit/s. The default value is 150 and any value beyond
the effective value range is used as the default value.
The GUI value range of bits 0 to 15 of theRsvdPara4 parameter in the SET
UDPUCFGDATA command is 0 to 65535 and the effective value range is 0 to
20000, with the unit of 10 kbit/s. The default value is 200 and any value beyond
the effective value range is used as the default value.
If an RNC is upgraded from V900R016C00SPC600 or later to
V900R016C00SPC620 or an RNC of V900R016C00SPC620 is newly deployed,
run the following command to restore the default throughput thresholds:
SET UDPUCFGDATA: RsvdPara2=9830400, RsvdPara4=100;
Values of RsvdPara2 and RsvdPara4 parameters need to be calculated according
to onsite configurations. For example: If the original value of RsvdPara2 is
2147483648 (1000 0000 0000 0000 0000 0000 0000 0000), it becomes 9830400
(1001 0110 0000 0000 0000 0000) after bits 16 to 31 of RsvdPara2 are set to 150.
This calculation method is also applied to RsvdPara4.
Solution 3
In the PS_SERVICE_TRAFFIC_STAT field of the RNC PCHR logs, the

buffered traffic and transmitted traffic on the RLC layer during the data
transmission of downlink PS services are now added.
The sampling period is 1 second and the traffic is sampled in the unit of
byte without RLC headers. The transmitted traffic on the RLC layer is
the traffic of the initial transmission.
NOTE
If the RNC is in V900R016C00SPC620 or later and the Nastar is used to parse the
measurement block collected in the PS_SERVICE_TRAFFIC_STAT field, the
Nastar must match the V600R014C00SPC230 version or later.
Solution
Impact
Issue 01 (2014-12-31)
None

Copyright Huawei
260
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Test Case
6.3.4.27 The UE experiences a call drop due to RL failures

caused by reasons other than synchronization failures.
Trouble
Ticket
Number
DTS: DTS2014090901292
Description
Condition: The RNC receives a RADIO LINK FAILURE

INDICATION message with a cause value other than "Synchronization
failure" from the NodeB.
Symptom: The RNC abnormally releases the UE's connection.
Severity
Suggestion
Root Cause
The NodeB sends the RNC a RADIO LINK FAILURE INDICATION

message with a cause value other than "Synchronization failure" for all
radio links (RLs) of the UE. Consequently, the RNC releases the UE's
connection.
Solution

triggers RL reestablishment for a UE when receiving a RADIO LINK
FAILURE INDICATION message with a cause value other than
"Synchronization failure" for all RLs of the UE. When this solution is
enabled, the RNC triggers RL reestablishment in the preceding scenario.
When this solution is disabled, the RNC abnormally releases the UE's
connection in the preceding scenario. By default, this solution is
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
The call drop rate decreases after this solution takes effect.
Test Case
6.3.4.28 Services or cells cannot be established on the DSP

subsystem whose KPIs deteriorate.
Trouble
Ticket
Number
Issue 01 (2014-12-31)
DTS: DTS2014063001526

Copyright Huawei
261
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Description
If the transmission becomes abnormal, the services or cells cannot be

established on a digital signal processor (DSP) whose RRC connection
setup success rate or RAB setup success rate drops to below 10%.
Severity
Suggestion
Root Cause
In the preceding scenario, the RNC incorrectly considers the faulty DSP
as a hardware fault, and then isolates the DSP. As a result, the services or
cells cannot be established on the DSP.
Solution

the SET UALGORSVPARA command controls whether the RNC
permanently isolates the DSP in the previous scenario. By default, this
solution is disabled (default value: 0) for both new networks and
upgrade scenarios.
After this solution is enabled:
The faulty DSP is isolated for one day. If the DSP is isolated for seven
consecutive days, the DSP will be isolated permanently.
The RNC can isolate a maximum of four DSPs managed by the same
MPU subsystem at a time, and the isolated DSPs must belong to the
same DPUb or DPUe board.

SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
None
Test Case
6.3.4.29 The SPU CPU usage rises instantaneously due to

the execution of the SET UCHRSCOPE or SET UMRSCOPE
command.
Trouble
Ticket
Number
DTS: DTS2014061708342
Descriptio
n
Condition: The SET UCHRSCOPE or SET UMRSCOPE command is

executed and the ScopeType parameter under this command is set to
ByRnc.
Symptom: The SPU CPU usage rises instantaneously and the CPU usage
rise becomes more serious with the increasing number of cells configured
for the RNC.
Impact: The SPU CPU usage rises, which may affect services.
Severity
Issue 01 (2014-12-31)
Suggestion
Copyright Huawei
262
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Root
Cause
When the ScopeType parameter is set to ByRnc, the setting of the CHR
or MR scope control switch (specified by the CHRScopeCtrl or
MRScopeCtrl parameter) must be modified for all cells under the RNC.
If the RNC is configured with 5100 cells, querying and modifying the
setting of this parameter for all cells take 5100 x 5100 cycles, which
dramatically increases the SPU CPU usage.
Solution
When the ScopeType parameter in the SET UCHRSCOPE, SET

UMRSCOPE, SET UMMCHRSCOPE, or SET
UMMMRSCOPEcommand is set to ByRnc, the original processing
of setting the CHRScopeCtrl or MRScopeCtrl parameter for all
cells under the RNC is changed. Users now only need to set the RNClevel CHRScopeCtrl or MRScopeCtrl parameter. In addition, a
value DEPEND_CELL_SWITCH is added to the CHRScopeCtrl
or MRScopeCtrl sub-parameter under the ByRnc parameter.
A SET URNCCHRSCOPE, SET URNCMRSCOPE, SET

UMMRNCCHRSCOPE, or SET UMMRNCMRSCOPE command
is added to set the RNC-level CHR or MR scope control switch
(specified by the CHRScopeCtrl or MRScopeCtrl parameter). This
parameter can be set to ON, OFF, or DEPEND_CELL_SWITCH.
When the RNC-level CHRScopeCtrl or MRScopeCtrl parameter is set

to ON or OFF, the RNC-level parameter setting takes effect. When this
parameter is set to DEPEND_CELL_SWITCH, the cell-level parameter
setting takes effect.
To set the RNC-level CHR scope control switch to on, run the
following command:
SET URNCCHRSCOPE: CHRScopeCtrl=ON;
or
SET UCHRSCOPE: ScopeType=ByRnc, CHRScopeCtrl=ON;
Run the following commands to set the cell-level CHR scope control
SET URNCCHRSCOPE:
CHRScopeCtrl=DEPEND_CELL_SWITCH;
SET UCHRSCOPE: ScopeType=ByCellId, CellId=1,
CHRScopeCtrl=ON;
or
SET UCHRSCOPE: ScopeType=ByRnc,
CHRScopeCtrl=DEPEND_CELL_SWITCH;
SET UCHRSCOPE: ScopeType=ByCellId, CellId=1,
CHRScopeCtrl=ON;
To set the RNC-level MR scope control switch to on, run the following
command:
SET URNCMRSCOPE: MRScopeCtrl=ON;
or
SET UMRSCOPE:ScopeType=ByRnc, MRScopeCtrl=ON;
Run the following commands to set the cell-level MR scope control

SET URNCMRSCOPE: MRScopeCtrl=DEPEND_CELL_SWITCH;
SET UMRSCOPE: ScopeType=ByCellId, CellId=1,
Issue 01 (2014-12-31)

Copyright Huawei
263
BSC6900 UMTS
Release Notes

V900R016C00SPC620
MRScopeCtrl=ON;
or
SET UMRSCOPE: ScopeType=ByRnc,
MRScopeCtrl=DEPEND_CELL_SWITCH;
SET UMRSCOPE: ScopeType=ByCellId, CellId=1,
MRScopeCtrl=ON;
NOTE
1. When RNC The machine-to-machine commands SET UMMRNCCHRSCOPE,
SET UMMRNCMRSCOPE, SET UMMCHRSCOPE, and SET
UMMMRSCOPE cannot be executed on the RNC, and functions controlled by
these commands can only be set on the Event Based Counter (EBC), eCoordinator,
Nastar, or Element Management System (EMS).
2. When RNC in Pool is enabled, the master RNC configurations are modified
using the SET URNCCHRSCOPE or SET URNCMRSCOPE command, and the
configurations modified by either of the two commands cannot be synchronized to
the overflow or backup RNC using the CME. In this situation, run SET
URNCCHRSCOPE or SET URNCMRSCOPE to set parameters with the same
configurations as those for the master RNC on the overflow or backup RNC.
Otherwise, configurations on the master RNC will be inconsistent with the
overflow or backup RNC.
Solution
Impact
None
Test Case
6.3.4.30 The queried OMUc board electronic label is

incorrect.
Trouble
Ticket
Number
DTS: DTS2014060407002
Descriptio
n
Condition: The DSP ELABEL: DEVTYPE=BOARD; command is

executed on an OMUc board to query its electronic label.
Symptom: The DSP ELABEL command output shows that the value of
the BarCode field is always empty.
Impact: The electronic label of the OMUc board queried using the DSP
ELABEL: DEVTYPE=BOARD; command is incorrect.
Severity
Suggestion
Root
Cause
The system does not process the BarCode field when the DSP ELABEL:
DEVTYPE=BOARD; command is executed on the OMUc board.
Solution
The system now processes the BarCode field when the DSP ELABEL:
DEVTYPE=BOARD; command is executed on the OMUc board.
Solution
Impact
The electronic label of the OMUc board queried using the DSP ELABEL:
DEVTYPE=BOARD; command is correct.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
264
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.4.31 The alarm location information in some

transmission alarms is insufficient.
Trouble
Ticket
Number
DTS: DTS2014071604715
Descriptio
n
Condition: Transmission objects become faulty or traffic on these objects

is congested. The following alarms and event are reported:
ALM-21501 MTP3 Signaling Link Congestion
ALM-21502 MTP3 DSP Congestion
ALM-21504 MTP3 Signaling Route Inaccessible
ALM-21505 MTP3 Signaling Link Set Unavailable
ALM-21506 MTP3 Signaling Link Faulty
ALM-21551 M3UA Link Fault
ALM-21552 M3UA Destination Entity Route Unavailable
ALM-21522 Low SCCP Setup Success Rate
EVT-22920 SCCP Subsystem Congested
Symptom: The information about the core network (CN) node or

neighboring RNC corresponding to the destination signaling point (DSP)
is not contained in the preceding alarms and event.
Impact: Users cannot determine which CN node or neighboring RNC is
faulty.
Severity
Suggestion
Root
Cause
The alarms and event reported by the base station controller contains only
the DSP information and do not contain the information about the faulty
CN node or neighboring RNC.
Solution
The alarm parameter Additional Information is added to the preceding

alarms and event.
If the DSP type is Iu-CS, Iu-PS, or Iu-CS_RANAP, the value of the

additional information parameter is "UMTS CN Node: CN domain
ID=y, CN node ID=z, Cn Operator Index=h, Cn Operator Name=j."
If the DSP type is Iur, the value of the additional information

parameter is "Neighboring RNC: Neighboring RNC ID=y."
For other DSP types, the value of the additional information parameter
is "NULL."
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
265
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.3.4.32 The failure cause cannot be quickly identified when

an IP continuity check fails.
Trouble
Ticket
Number
DTS: DTS2014071600532
Descriptio
n
Condition: An IP continuity check whose type is single-hop bidirectional

forwarding detection (SBFD) or address resolution protocol (ARP) is
started to detect faults.
Symptom: When an IP continuity check fails, the failure cause cannot be
quickly identified.
Impact: The existing IP continuity check mechanism cannot quickly
identify the failure cause.
Severity
Suggestion
Root
Cause
When an IP continuity check fails, especially the IP continuity check fails

and then recovers, the maintenance function for quickly identifying the
failure cause has defects, and therefore cannot determine whether an
interface board can properly receive or transmit BFD or ARP packets.
Solution
1. When an IP continuity check fails, MAC packet capturing is triggered

automatically.
2. SBFD/ARP packets are captured by a pair of boards in active/standby
configuration.
3. The packet capturing function can be automatically started on a board
for up to five times in a day and the packet capturing duration is 30s.
Solution
Impact
None
Test Case
6.3.4.33 No information is available for locating the fault

when a chip of the signaling processing board, service
processing board, service identification board, or interface
processing board fails to be initialized.
Trouble
Ticket
Number
iCare: 2680413
Descriptio
n
Condition: A chip of the board is faulty.
DTS: DTS2014051604005
Symptom: Due to a hardware fault, a board fails to start up, but no

information about the faulty chip is displayed.
Impact: Faults in the following chips cannot be located: memory chip,
flash chip, CPLD logic chip, FPGA logic chip, clock chip, and
temperature and voltage monitoring chip.
Severity
Issue 01 (2014-12-31)
Suggestion
Copyright Huawei
266
BSC6900 UMTS
Release Notes

V900R016C00SPC620
Root
Cause
The board's basic input/output system (BIOS) does not record required
information in the last word when a chip of the board fails to be
initialized.
Solution
The board's BIOS records the number of the chip that fails to be initialized
and the returned value in the last word.
Solution
Impact
None
Test Case
6.3.4.34 The setting of the Check active/standby status

consistency option is inconsistent with the actual function
implementation.
Trouble
Ticket
Number
DTS: DTS2014060405568
Descriptio
n
Condition:
A BSC6900 is upgraded from V900R015C00SPC525 or a later

V900R015C00 patch version to V900R016C00.
A BSC6900 is upgraded between V900R016C00 versions.
Symptom: The Check active/standby status consistency option is not

selected on the upgrade tool but the corresponding function is effective.
Impact: The graphical user interface (GUI) configuration is inconsistent
with the actual function implementation. As a result, user experience
deteriorates.
Severity
Suggestion
Root
Cause
The Interface Board and Port Active/Standby Status Consistency feature is

incorporated in BSC6900 V900R015C00SPC525 and later V900R015C00
patch versions as well as V900R016C00 versions. This feature causes the
Check active/standby status consistency option on the upgrade tool to
become ineffective.
Solution
In the preceding scenarios, the Check active/standby status consistency

option has been removed from the upgrade tool and the Interface Board
and Port Active/Standby Status Consistency feature is used instead of this
option.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
267
BSC6900 UMTS
Release Notes

V900R016C00SPC620
6.4 Known Issues

6.4.1 Critical
None
6.4.2 Major
None
6.4.3 Minor
None
6.4.4 Suggestion
None
Issue 01 (2014-12-31)

Copyright Huawei
268
BSC6900 UMTS
Release Notes

V900R016C00SPH609
Changes from
V900R016C00SPH609
7.1 Change Summary
Compared with those in BSC6900 V900R016C00SPH608, capacity and performance remains
Hardware
V900R016C00SPH609.
Features
Compared with those in BSC6900 V900R016C00SPH608, features remain
Resolved Issues
Compared with those in BSC6900 V900R016C00SPH608, 0 critical issues, 2 major issues, 0
minor issues, and 0 suggestion-level issues have been resolved in V900R016C00SPH609.
Issue 01 (2014-12-31)

Copyright Huawei
269
BSC6900 UMTS
Release Notes

V900R016C00SPH609

Fault management
License management
Changes.

performance.
7.1.2 Hardware
New Hardware
None
Modified Hardware
None
7.1.3 Features
Compared with those in BSC6900 V900R016C00SPH608, features remain
Issue 01 (2014-12-31)

Copyright Huawei
270
BSC6900 UMTS
Release Notes

V900R016C00SPH609

that have been resolved in V900R016C00SPH609.
Issue description
Severity
Solution impact
Parameter control
V900R016C00SPH609.xls, or see the the V900R016C00SPH609 vs V900R016C00SPH608
BSC6900 V900R016C00SPH609.


Changes.



Issue 01 (2014-12-31)

Copyright Huawei
271
BSC6900 UMTS
Release Notes

V900R016C00SPH609
7.2 Feature Changes

7.2.1 New Features
None

None

None
7.3 Resolved Issues

7.3.1 Critical
None
7.3.2 Major
None
7.3.2.1 The WebLMT displays a message "Internal error" if

the file name of an uploaded file contains Chinese
characters in batch configuration.
Trouble
Ticket
Number
DTS: DTS2014080500592
Description
Condition: A user uses the batch configuration function of the Web

LMT. The file name of an uploaded file or a file that has been
decrypted contains Chinese characters.
Symptom: The Web LMT displays a message "Internal error".
Impact: The batch configuration function fails.
Severity
Major
Root Cause
The Web LMT and interconnected NE adopt inconsistent character

encoding schemes. Specifically, if the file name of an uploaded file
contains Chinese characters in batch configuration, the Web LMT
notifies the interconnected NE of the file name in UTF-8, whereas the
interconnected NE reads the file name in GB2312.
Solution
In batch configuration, the Web LMT now converts the file name of
an uploaded file to codes supported by the language in use before
notifying the interconnected NE.
Issue 01 (2014-12-31)

Copyright Huawei
272
BSC6900 UMTS
Release Notes

V900R016C00SPH609
Solution
Impact
None
Test Case ID
CASE_Commercial_PR_Regression_R016C00SPH609_001
7.3.2.2 Multicast configuration fails after an SCU board has

been running for an excessively long period of time.
Trouble
Ticket
Number
iCare: 3292252
Description
Condition:
DTS: DTS2014082111156
An SCU board in a subrack (subrack A) has been running for more

than 497 days.
The total number of MPS and EPSs exceeds 2.
SCU boards in a subrack (subrack B) that is not directly connected

to subrack A reset.
Symptom: After the SCU boards in subrack B restart, multicast

configuration of subrack A cannot be added to the SCU boards in
subrack B.
Impact: Inter-subrack services are interrupted.
Severity
Major
Root Cause
After arithmetic overflow occurs on the global variable (TICK value)

recording the running period of the SCU board subrack A, if the SCU
boards in subrack B are switched over, the SCU board in subrack A
incorrectly performs calculation between the current TICK value and
the TICK value obtained during the previous multicast configuration.
In this situation, the conditions for sending inter-subrack multicast
configuration messages are not meet. As a result, multicast
configuration of subrack A cannot be added to the SCU boards
subrack B.
Solution
The SCU boards now correctly perform calculation between the

current TICK value and the TICK value obtained during the previous
multicast configuration in the preceding scenario. This ensures that
the calculated result is correct when arithmetic overflow occurs on the
TICK value.
Solution
Impact
None
Test Case ID
7.3.3 Minor
None
Issue 01 (2014-12-31)

Copyright Huawei
273
BSC6900 UMTS
Release Notes

V900R016C00SPH609
7.3.4 Suggestion
None
7.4 Known Issues

7.4.1 Critical
None
7.4.2 Major
None
7.4.3 Minor
None
7.4.4 Suggestion
None
Issue 01 (2014-12-31)

Copyright Huawei
274
BSC6900 UMTS
Release Notes

V900R016C00SPH608
Changes from
V900R016C00SPH608
8.1 Change Summary
Compared with those in BSC6900 V900R016C00SPH605, capacity increases/performance
improves in V900R016C00SPH608. For details, see 8.1.1 Capacity and Performance.
Hardware
V900R016C00SPH608.
Features
Compared with those in BSC6900 V900R016C00SPH605, 0 features have been added, 0
features have been modified, and 0 features have been deleted in V900R016C00SPH608.
Resolved Issues
Issue 01 (2014-12-31)

Copyright Huawei
275
BSC6900 UMTS
Release Notes

V900R016C00SPH608
Fault management
License management
Changes.

performance.
8.1.2 Hardware
New Hardware
None
Modified Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
276
BSC6900 UMTS
Release Notes

V900R016C00SPH608
8.1.3 Features
V900R016C00SPH605 to V900R016C00SPH608.
Change type
Feature description
V900R016C00SPH608.xls, or see the V900R016C00SPH608 vs V900R016C00SPH605 sheet
BSC6900 V900R016C00SPH608.

Issue description
Severity
Solution impact
Parameter control
BSC6900 V900R016C00SPH608.

Issue 01 (2014-12-31)

Copyright Huawei
277
BSC6900 UMTS
Release Notes

V900R016C00SPH608

Changes.



8.2 Feature Changes

8.2.1 New Features
None

None
8.3 Resolved Issues

8.3.1 Critical
None
8.3.2 Major
8.3.2.1 The CN or the neighboring RNC signaling points
become unavailable when the signaling point code is
expressed in segments.
Trouble
Ticket
Number
Issue 01 (2014-12-31)
DTS: DTS2014071609421

Copyright Huawei
278
BSC6900 UMTS
Release Notes

V900R016C00SPH608
Description
Condition:
The OPCSPDF or DPCSPDF parameter under the UCNNODE

managed object (MO) is set to DNF, which indicates that the
signaling point code is expressed in segments.
The OPCSPDF or DPCSPDF parameter under the UNRNC MO is

set to DNF.
Symptom:
If the OPCSPDF or DPCSPDF parameter under the UCNNODE MO

is set to DNF, the Iu interface becomes unavailable.
If the OPCSPDF or DPCSPDF parameter under the UNRNC MO is

set to DNF, the Iur interface becomes unavailable.
Impact:
If the OPCSPDF or DPCSPDF parameter under the UCNNODE MO

is set to DNF, this CN node becomes unavailable. If this CN node is
the only CN node in the whole CN domain, all the services in this
CN domain cannot be set up.
If the OPCSPDF or DPCSPDF parameter under the UNRNC MO is

set to DNF, services cannot be set up over this Iur interface.
Severity
Major
Root Cause
When the OPCSPDF or DPCSPDF parameter under the UCNNODE or

UNRNC MO is set to DNF, the RNC fails to convert the signaling point
code into an integer. As a result, services on the host cannot obtain the
correct information of a signaling point, leading to negotiation failures
for subsequent services.
Solution
When the OPCSPDF or DPCSPDF parameter under the UCNNODE or

UNRNC MO is set to DNF, the RNC converts the signaling point code
into an integer.
Solution
Impact
None
Test Case
8.3.2.2 The RNC incorrectly unblocks cells when processing

the NBAP audit response message.
Trouble
Ticket
Number
DTS: DTS2014070406978
Description
Condition: After local cells are blocked by running the NodeB MML
command BLK ULOCELL, the RNC triggers an NBAP audit
procedure. At this time point, however, these local cells have not been
unblocked using the UBL ULOCELL command.
Symptom: The RNC incorrectly unblocks the logical cells
corresponding to these local cells.
Impact: The RNC incorrectly considers that these local cells are
Issue 01 (2014-12-31)

Copyright Huawei
279
BSC6900 UMTS
Release Notes

V900R016C00SPH608
available and initiates DRDs and blind handovers to the logical cells
corresponding to these local cells, which increases the values of the
following counters:
VS.DRD.RBSetup.AttIn
VS.DRD.RBRecfg.AttIn
VS.HHO.AttBlindHO
Severity
Major
Root Cause
If the value of the resourceOperationalState information element (IE) in

the NBAP audit response message is enabled, the RNC incorrectly
considers that these local cells have been unblocked on the NodeB side
and therefore unblocks the logical cells corresponding to these local
cells on the RNC side.
Solution
The RNC now does not unblock cells based on the value of the
resourceOperationalState IE in the NBAP audit response message.
Solution
Impact
After this solution is used, the RNC will not initiate DRDs or blind
handovers to cells that are blocked, which decreases the values of the
following counters:
Test Case
VS.DRD.RBRecfg.AttIn
VS.HHO.AttBlindHO
8.3.2.3 The AOUc or UOIc boards are switched over after

SAAL link loopback detection is enabled on these boards.
Trouble
Ticket
Number
iCare: 3187564
Descripti
on
Condition:
DTS: DTS2014071506267
The BSC6900 is upgraded to V900R016C00 or later.
No transmission alarm is reported over local physical links to the AOUc

or UOIc boards on the RNC.
Two or more local SAAL links become faulty and use the same virtual
path identifier (VPI) and virtual channel identifier (VCI).
Symptom: The AOUc or UOIc boards trigger self-healing and reset.

Impact:
Severity
Issue 01 (2014-12-31)
If the AOUc or UOIc boards are configured in active/standby mode, the

board switchover is triggered only once in 24 hours.
If the AOUc or UOIc boards are configured in independent mode, these

boards reset only once in 24 hours. Services on these boards may be
interrupted during the reset and recover after these boards restart.
Major
Copyright Huawei
280
BSC6900 UMTS
Release Notes

V900R016C00SPH608
Root
Cause
Only one loopback detection task can be started on the links with the same
VPI and VCI on the AOUc or UOIc boards. However, this restriction is not
imposed on the system. As a result, the loopback detection task fails to be
started on a second link and the AOUc or UOIc boards trigger self-healing
unexpectedly.
Solution
The restriction is now imposed on the RNC to ensure that only one
loopback detection task can be started on the SAAL links with the same
VPI and VCI on a board.
Solution
Impact
None
Test Case
8.3.2.4 The service awareness-based user experience

evaluation function becomes unavailable after the NIUa
board has been running for more than 24 consecutive days.
Trouble
Ticket
Number
DTS: DTS2014071201434
Description
Condition: he NIUa board has been running for more than 24

consecutive days.
Symptom: The success rate of web page browsing displayed on the
iManager PRS decreases to 0.
Impact: The service awareness-based user experience evaluation
function cannot correctly evaluate the success rate of web page
browsing.
Severity
Major
Root Cause
When the NIUa board has been running for more than 24 consecutive
days, the web page browsing evaluation algorithm incorrectly maintains
the time information. Consequently, the service awareness-based user
experience evaluation function determines that web page browsing fails.
Solution
The web page browsing evaluation algorithm correctly maintains the

time information.
Solution
Impact
None
Test Case
8.3.3 Minor
None
Issue 01 (2014-12-31)

Copyright Huawei
281
BSC6900 UMTS
Release Notes

V900R016C00SPH608
8.3.4 Suggestion
None
8.4 Known Issues

8.4.1 Critical
None
8.4.2 Major
None
8.4.3 Minor
None
8.4.4 Suggestion
None
Issue 01 (2014-12-31)

Copyright Huawei
282
BSC6900 UMTS
Release Notes

V900R016C00SPH605
Changes from
V900R016C00SPH605
9.1 Change Summary
Compared with those in BSC6900 V900R016C00SPH602, capacity increases/performance
Hardware
V900R016C00SPH605.
Features
Compared with those in BSC6900 V900R016C00SPH602, 0 features have been added, 7
Resolved Issues
Issue 01 (2014-12-31)

Copyright Huawei
283
BSC6900 UMTS
Release Notes

V900R016C00SPH605
Fault management
License management
Changes.

performance.
9.1.2 Hardware
New Hardware
None
Modified Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
284
BSC6900 UMTS
Release Notes

V900R016C00SPH605
9.1.3 Features
V900R016C00SPH602 to V900R016C00SPH605.
Change type
Feature description
V900R016C00SPH605.xls, or see the V900R016C00SPH605 vs V900R016C00SPH602 sheet
BSC6900 V900R016C00SPH605.

Issue description
Severity
Solution impact
Parameter control
BSC6900 V900R016C00SPH605.

Issue 01 (2014-12-31)

Copyright Huawei
285
BSC6900 UMTS
Release Notes

V900R016C00SPH605

Changes.



9.2 Feature Changes

9.2.1 New Features
None

9.2.2.1 Optimization of the Inter-Frequency DRD Function
During PS Service Setup
Description
When the Iu CS connection is established for a UE, inter-frequency directed retry decision
(DRD) is not performed during PS service setup.
Implementation
is disabled (default value: 1) for both new networks and upgrade scenarios. This feature does
not take effect both before and after the upgrade. After the upgrade, a switch has been added
to control whether this feature takes effect, which does not affect smooth upgrade.
When a UE sends an Initial Direct transfer message or Uplink Direct transfer message with
the CS-domain cause value "cm service request" (calling party) and "paging response" (called
party), the RNC receives a PS RAB ASSIGNMENT REQUEST message and then a CS RAB
ASSIGNMENT REQUEST message. In this situation, inter-frequency DRD is not performed
during PS service setup.
Issue 01 (2014-12-31)

Copyright Huawei
286
BSC6900 UMTS
Release Notes

V900R016C00SPH605

None
Impact on NEs
None
Impact on Hardware
None

None

None

UALGORSVPARA command controls whether to enable this feature.

The values of the following counters decrease:
VS.DRD.RBSetup.AttOut

None

None
Related Operations
Run the following command to enable this feature:

DTS: DTS2014060502879
Feature ID
None
Issue 01 (2014-12-31)

Copyright Huawei
287
BSC6900 UMTS
Release Notes

V900R016C00SPH605
9.2.2.2 PCHR, MR, and VIP Files Generated Within a Full

Hour
Description
With this feature, performance call history record (PCHR), measurement report (MR), and
VIP files can be periodically generated within a full hour. This feature prevents data files from
being generated over different hours and therefore allows customers to obtain data files within
a full hour.
Implementation
1.
The Time-based New File Generation Flag parameter is added in the SET
UCDRFILE command to determine whether to generate the PCHR, MR, and VIP files
when the system time is an integer multiple of the Period of New File Generation[min]
parameter value. By default, this feature is disabled for both new networks and upgrade
scenarios.
2.
This feature takes effect and the system generates PCHR, MR, and VIP files within a full
hour when the parameter settings in the SET UCDRFILE command are as follows:
3.
The File Output Mode parameter is set to Periodical Generation of New File.
The Period of New File Generation[min] parameter is set to 5, 10, 15, 30, 60, 120,
180, or 240.
The Time-based New File Generation Flag parameter is set to YES.
In the SET UCDRFILE command, if the File Output Mode parameter is set to
Periodical Generation of New File but the Period of New File Generation[min] is set
to a value other than any of the preceding values, the Time-based New File Generation
Flag parameter is invalid.

None
Impact on NEs
None
Impact on Hardware
None

None
Impact on license management: None

Added the Time-based New File Generation Flag parameter to the SET UCDRFILE
command.
Issue 01 (2014-12-31)
Impact on performance management: None

Copyright Huawei
288
BSC6900 UMTS
Release Notes

V900R016C00SPH605
Impact on fault management: None

None
Related Operations
To enable the system to generate a PCHR, MR, or VIP file at an integer multiple of 15
minutes, run the following command:
SET UCDRFILE:MODE=CYCLE,CYCLE=15,ALIGNFLAG=YES;
In this case, the system generates a new file at XX:00, XX:15, XX:30, and XX:45 (XX
indicates the hour).

CR-0000069213
Feature ID
None
9.2.2.3 Inter Frequency Load Balance Feature Considering

HSDPA User Number in Candidate Cells
Description
This feature enables the RNC to consider the number of HSDPA UEs in the target cell or in
the NodeB of the target cell when performing an LDR-triggered load-based inter-frequency
handover. If the number of HSDPA UEs in the target cell or in the NodeB of the target cell
reaches the upper limit, HSDPA UEs in other cells cannot be handed over to the target cell.
LDR is short for load reshuffling.
Implementation
This feature is controlled by the RESERVED_SWITCH_6_BIT1 under the RsvSwitch6
parameter in the SET UCELLALGORSVPARA command. By default, this feature is
When this feature is enabled (default value: 1), if the target cell supports HSDPA and the
number of HSDPA UEs in the target cell or in the NodeB of the target cell reaches the upper
limit, HSDPA UEs whose downlink is carried on HSDPA channels cannot move to the target
cell through LDR-triggered load-based inter-frequency handovers.
When this feature is disabled, LDR-triggered load-based inter-frequency handovers select
candidate cells without considering the number of HSDPA UEs in the candidate cells.

After this feature is enabled, HSDPA UEs in other cells cannot move to the target cell through
LDR-triggered load-based inter-frequency handovers if the number of HSDPA UEs in the
target cell or in the NodeB of the target cell reaches the upper limit. This prevents HSDPA
UEs from falling back to R99 UEs after the handover, thereby increasing the HSDPA
Issue 01 (2014-12-31)

Copyright Huawei
289
BSC6900 UMTS
Release Notes

V900R016C00SPH605
throughput of the target cell. However, when other cells are overloaded, fewer cells can be
selected as the candidate cells of LDR-triggered load-based inter-frequency handovers, which
affects the congestion relief effect of LDR on these cells.
Impact on NEs
None
Impact on Hardware
None

None

This feature is controlled by the "Inter frequency load handover" license control item.
Feature enhancement does not involve license updates.

The RESERVED_SWITCH_6_BIT1 under the RsvSwitch6 parameter in the SET
UCELLALGORSVPARA command is used to control this feature.
1.
After this feature is enabled, the number of LDR-triggered load-based inter-frequency

handovers decreases, which is indicated by the following counters:
2.
VS.HHO.AttInterFreqOut.PS.TotalTxPwr
VS.HHO.AttInterFreqOut.PS.TotalRxPwr
VS.HHO.AttInterFreqOut.PS.UlCE
For the source cell that triggers the LDR, congestion is more difficult to relieve, which
results in:
Longer duration of the cell in the LDR state, which is indicated by the following
counters:
VS.LCC.LDR.Time.ULPower
VS.LCC.LDR.Time.DLPower
VS.LCC.LDR.Time.ULCE
More HSPDA UEs in the cell, which is indicated by the VS.HSDPA.UE.Mean.Cell

counter.
3.
For the target cell of the LDR-triggered load-based inter-frequency handover: This
feature prevents HSDPA UEs from falling back to R99 channels after the handover,
thereby increasing the HSDPA throughput of the target cell, which is indicated by the
VS.HSDPA.MeanChThroughput counter.

None
Issue 01 (2014-12-31)

Copyright Huawei
290
BSC6900 UMTS
Release Notes

V900R016C00SPH605
Related Operations

SET UCELLALGORSVPARA: CellId=xxx, RsvSwitch6=

SET UCELLALGORSVPARA: CellId=xxx, RsvSwitch6=

DTS: DTS2014052904169
Feature ID
WRFD-020103
9.2.2.4 Transmission Requirements-based Channel

Reconfiguration for the PS Service in CS+PS Combined
Services Considering RF Quality
Description
This feature enables the RNC to perform data transmission requirements-based channel
reconfiguration for the PS service in CS+PS combined services by considering the RF quality.
This feature prevents CS call drops while ensuring the experience of PS UEs with good signal
quality.
Implementation
1.
This feature involves the following parameters:
The RESERVED_SWITCH_0_BIT1 under the RsvSwitch0 parameter in the celllevel command ADD UCELLCOALGOENHPARA is used to control the
RESERVED_SWITCH_1_BIT1 under the RsvSwitch1 parameter. By default, this
feature is disabled (default value: 0) for both new networks and upgrade scenarios.
The RESERVED_SWITCH_1_BIT1 under the RsvSwitch1 parameter in the celllevel command ADD UCELLCOALGOENHPARA is used to control the function
of RF quality-based dynamic channel reconfiguration for the PS service in CS+PS
combined services.
When this switch is set to on, the RNC makes rate increase or decrease decisions for
the PS service in CS+PS combined services based on the UE's signal quality. By
default, this feature is enabled (default value: 1) for both new networks and upgrade
scenarios.
Issue 01 (2014-12-31)
Bit 0 to Bit 5 under the RsvU32Para30 parameter in the RNC-level command SET
UALGORSVPARA is used to specify the Ec/N0 threshold for the RNC to make rate
increase or decrease decisions for the PS service in CS+PS combined services based
on UE's signal quality.
UALGORSVPARA is used to specify the RSCP threshold for the RNC to make rate
increase or decrease decisions for the PS service in CS+PS combined services based
on UE's signal quality.
Copyright Huawei
291
BSC6900 UMTS
Release Notes

V900R016C00SPH605
UALGORSVPARA is used to specify the period for measuring the Ec/N0 and RSCP
values of intra-frequency cells for the RNC to make rate increase or decrease
decisions for the PS service in CS+PS combined services based on UE's signal
quality.
2.
Unless otherwise specified, cell-level parameters involved in this feature are those of the
best cell's by default.
3.
This feature does not take effect when either of the RESERVED_SWITCH_0_BIT1
and RESERVED_SWITCH_1_BIT1 is set to off.
4.
This feature takes effect only when both the RESERVED_SWITCH_0_BIT1 and
RESERVED_SWITCH_1_BIT1 are set to on. This feature works as follows:
After a CS+PS combined service setup, the RNC delivers an intra-frequency

measurement control message to the UE, instructing the UE to return a periodic intrafrequency measurement report in UM mode.
If the CS+PS combined service becomes an only-PS service or an only-CS service, the
previous intra-frequency measurement is released.
If the UE sends a rate increase or decrease request due to data transmission requirements
during the processing of the CS+PS combined service, the RNC makes PS rate increase
or decrease decisions based on the signal quality carried in the intra-frequency
measurement report.
When the following conditions are met, the RNC allows the PS rate increase or
decrease:
1.
The time of intra-frequency measurement report is within the effective time range
(specified by the EcN0EffectTime parameter).
2.
The Ec/N0 and RSCP values of the best cell in the active set is greater than or equal to
the Ec/No and RSCP thresholds for the RNC to make rate increase or decrease decisions
for the PS service in CS+PS combined services based on UE's signal quality, which
means that the UE's signal quality is good.
If either of the following conditions is met (which means UE's signal quality is bad), the
RNC forbids the PS rate increase or decrease even when there are date transmission
requirements. In addition, the RNC does not process event 4A or 4B reports
1.
The Ec/N0 value of the best cell in the active set is less than the Ec/No threshold for the
RNC to make rate increase or decrease decisions for the PS service in CS+PS combined
services based on UE's signal quality.
2.
The RSCP value of the best cell in the active set is less than the RSCP threshold for the
RNC to make rate increase or decrease decisions for the PS service in CS+PS combined
services based on UE's signal quality.
3.
The time of the intra-frequency measurement report is out of the effective time range.
4.
The intra-frequency measurement report does not include both the Ec/N0 and RSCP
values.
In the CS+PS combined service, the CS service is AMR service and the PS service is PS BE service.
The CS+PS combined service must consist of at least one AMR and one PS BE service.
At present, PS rate increase or decrease is triggered based on the traffic volume or throughput. PS
rate increase or decrease is achieved through the DCH DCCC and HSUPA DCCC functions.
This feature takes effect only with the RsvU32Para30 parameter configuration.
It is recommended that the periodic channel retry for CS+PS combined services function be enabled
before you use this feature:
SET UCORRMALGOSWITCH: DraSwitch=DRA_CSPS_NO_PERIOD_RETRY_SWITCH-1;
Issue 01 (2014-12-31)

Copyright Huawei
292
BSC6900 UMTS
Release Notes

V900R016C00SPH605
It is recommended that the restrictions on the channel types or rates of PS services in CS+PS
combined services be lifted based on actual requirements before you use this feature:
To enable the PS service in the CS+PS combined service to use the DCH in the downlink, run the
following command:
SET UCORRMALGOSWITCH: MapSwitch=MAP_CSPS_PS_DL_USE_DCH_SWITCH-0;
To enable the PS service in the CS+PS combined service to use the DCH in the uplink, run the
following command:
SET UCORRMALGOSWITCH: MapSwitch=MAP_CSPS_PS_UL_USE_DCH_SWITCH-0;
To set the upper limit of uplink R99 BE service rate in combined AMR services, run the following
command:
SET UFRC: UlDchBeUpperLimitforAmr;
To set the upper limit of downlink R99 BE service rate in combined AMR services, run the
following command:
SET UFRC: DlDchBeUpperLimitforAmr;

After this feature takes effect, rate increase or decrease is forbidden for the PS service in
CS+PS combined services in weak coverage scenarios, which reduces the number of failed
signaling interactions in weak coverage scenarios and therefore reduces the CS and PS call
drop rates of CS +PS combined services. In addition, SRBs are switched from E-DCHs to
DCHs, which reduces the uplink throughput of a single user.
Impact on NEs
None
Impact on Hardware
None

None
1.
The RESERVED_SWITCH_0_BIT1 under the RsvSwitch0 parameter in the cell-level

command ADD UCELLCOALGOENHPARA is used to control the
RESERVED_SWITCH_1_BIT1 under the RsvSwitch1 parameter.
2.
The RESERVED_SWITCH_1_BIT1 under the RsvSwitch0 parameter in the cell-level

command ADD UCELLCOALGOENHPARA is used to control the function of RF
quality-based dynamic channel reconfiguration for the PS service in CS+PS combined
services.
3.
UALGORSVPARA is used to specify the Ec/N0 threshold for the RNC to make rate
increase or decrease decisions for the PS service in CS+PS combined services based on
UE's signal quality.
4.
UALGORSVPARA is used to specify the RSCP threshold for the RNC to make rate
Issue 01 (2014-12-31)

Copyright Huawei
293
BSC6900 UMTS
Release Notes

V900R016C00SPH605
increase or decrease decisions for the PS service in CS+PS combined services based on
UE's signal quality.
5.
UALGORSVPARA is used to specify the period for measuring the Ec/N0 and RSCP
values of intra-frequency cells for the RNC to make rate increase or decrease decisions
for the PS service in CS+PS combined services based on UE's signal quality.

None
Related Operations
If the cell is not configured with connection-orientated cell-level algorithm enhance

parameters (UCELLCOALGOENHPARA), run the following command to configure
these cell-level parameters:
ADD UCELLCOALGOENHPARA: CellId=xxx;
Run the following command to enable the function of RF quality-based dynamical

channel reconfiguration for the PS service in CS+PS combined services:
MOD UCELLCOALGOENHPARA: CellId=xxx,
RsvSwitch0=RESERVED_SWITCH_0_BIT1-1,
Calculate the value of RsvU32Para30 based on the onsite configurations and the value
set of Ec/N0 threshold, RSCP threshold, and the period for measuring the Ec/N0 and
RSCP values.
For example, bit 0 to 5 that controls the value of the Ec/N0 threshold is set to 21 (0000
0000 0000 0000 0000 0000 0001 0101), bits 6 to 12 that control the value of the RSCP
threshold are set to 20 (0000 0000 0000 0000 0000 0101 0000 0000), bits 13 to 16 that
control the period for measuring the Ec/N0 and RSCP values are set to 4(0000 0000
0000 0000 1000 0000 0000 0000). In this case, the calculated value for RsvU32Para30
is 34069 (0000 0000 0000 0000 1000 0101 0001 0101). Then, run the following
command:

DTS: DTS2014053002835
Feature ID
WRFD-140104
9.2.2.5 Uplink Rate of PS BE Services Not Reduced to the

Initial Access Rate After HSUPA Reconfiguration
Description
In scenarios where the HSUPA DCCC function takes effect, this feature enables the RNC to
set the uplink rate of PS BE services to the smaller value between the current rate and the
Issue 01 (2014-12-31)

Copyright Huawei
294
BSC6900 UMTS
Release Notes

V900R016C00SPH605
maximum rate supported by the target cell during an HSUPA reconfiguration not triggered by
DCCC and HSPA retry. This feature prevents the problem that the uplink rate of PS BE
services is suddenly reduced to the initial access rate (specified by the HsupaInitialRate
parameter) and then is gradually increased. BE is short for best effort and DCCC is short for
dynamic channel configuration control.
Implementation
TheRESERVED_SWITCH_13_BIT1 under the RsvSwitch13 parameter in the SET
UALGORSVPARA command is used to control whether the RNC sets the uplink rate of PS
BE services to the initial access rate during an HSUPA reconfiguration not triggered by
DCCC and HSPA retry when the HSUPA DCCC function is enabled. When this feature is
enabled, the RNC sets the uplink rate of PS BE services to the smaller value between the
current rate and the maximum rate supported by the target cell. When this function is
disabled, the RNC sets the uplink rate of PS BE services to the initial access rate. By default,
this feature is disabled (default value: 0) for both new networks and upgrade scenarios.

After this feature is enabled, the RNC does not set the uplink rate of PS BE services to the
initial access rate but to a higher rate, which increases the HSUPA throughput of the cell but
also increases the uplink CE resource consumption.
Impact on NEs
None
Impact on Hardware
None

None
Impact on configuration management: None

None
Related Operations

Run the following command to disable this feature:

Issue 01 (2014-12-31)

Copyright Huawei
295
BSC6900 UMTS
Release Notes

V900R016C00SPH605

DTS: DTS2014053002802
Feature ID
WRFD-021101
9.2.2.6 Added the G_NIC Command Group for Encapsulating

All Commands for the NIC Function
Description
The G_NIC command group is added as the default command group to encapsulate all
commands for the NIC function. Customized users can perform the NIC function by adding
this command group without specifying a user-defined command group. This simplifies user
operations.
Implementation
All commands for the NIC function are encapsulated in the G_NIC command group.
Customized users can use this command group to perform the NIC function. Operations
related to this command group are as follows:
The Command Group parameter in the ADD OP command can be set to G_NIC when
this command is executed to add a customized user.
The Command Group parameter in the MOD OP command can be set to G_NIC when
this command is executed to modify a customized user.
The Command Group parameter in the LST OP command can be set to G_NIC when
this command is executed to query an operator's information by command group.
The Command Group parameter in the LST CCG command can be set to G_NIC
when this command is executed to query the commands in this command group.
The Command Group parameter in the LST CCGN command can be set to G_NIC to
query the name of this command group.

None
Impact on NEs
None
Impact on Hardware
None

None
Issue 01 (2014-12-31)

Copyright Huawei
296
BSC6900 UMTS
Release Notes

V900R016C00SPH605

None

Added the value G_NIC to the Command Group parameter in the ADD OP, MOD
OP, LST OP, LST CCG, and LST CCGN commands.

None

None

None
Related Operations
None

CR-0000072490
Feature ID
None
9.2.2.7 Enhanced Anti-Attack Protection for Fragmented

Packets Received by the Interface Board
Description
The protection against fragmented packet attack has been optimized for interface boards
AOUc/UOIc/POUc/PEUc/FG2c/GOUc/GOUe to prevent the impact of fragmented packet
attack on services. It is recommended that this feature be enabled in scenarios where there are
a great number of fragmented packets on the transmission network.
Implementation
This feature implements protection against fragmented packet attack by limiting the number
of fragmented packets received by the preceding interface boards 256. If the number of
fragmented packets required for assembling a complete packet is greater than 256, the packet
assembly fails and these fragmented packets are discarded.
BIT0 under the RSVDSW1 parameter in the SET DEVRSVDPARA command controls
whether to enable the function of limiting the number of fragmented packets received by
interface boards. When this function is enabled, the number of fragmented packets received
by interface boards is limited. When function is disabled, the number of fragmented packets
received by interface boards is not limited. By default, this function is disabled (default value:
Issue 01 (2014-12-31)

Copyright Huawei
297
BSC6900 UMTS
Release Notes

V900R016C00SPH605

None
Impact on NEs
None
Impact on Hardware
None

None

None

BIT0 under the RSVDSW1 parameter in the SET DEVRSVDPARA command is now
used.

None

None

None
Related Operations
Run the following command to enable the function of limiting the number of fragmented
packets received by interface boards:
Run the following command to disable the function of limiting the number of fragmented
packets received by interface boards:

DTS: DTS2014061603298
Feature ID
None
Issue 01 (2014-12-31)

Copyright Huawei
298
BSC6900 UMTS
Release Notes

V900R016C00SPH605

None
9.3 Resolved Issues

9.3.1 Critical
9.3.1.1 Measurement control hampers the CS RB setup,
leading to incorrect adjustment of encryption parameters.
Trouble
Ticket
Number
iCare: 2635315
Descripti
on
Condition: During the cell update or PS service setup procedure, the RNC
receives a CS RAB ASSIGNMENT REQUEST message from the CN.
After the preceding procedure is complete, the RNC sends a
DTS: DTS2014060505130
Symptom: The CS RADIO BEARER SETUP message is delayed.

Impact: The CS encryption parameter settings are incorrectly adjusted.
Severity
Critical
Root
Cause
In the preceding scenario, the MEASUREMENT CONTROL and RADIO

BEARER SETUP messages are sent in sequence over SRB2. In this
situation, the UE receives the RADIO BEARER SETUP message too late,
leading to a large delay for the RNC to receive the RADIO BEARER
SETUP COMPLETE message. As a result, the encryption parameters are
incorrectly adjusted.
Solution
In the preceding scenario, the RNC checks for the CS RAB

ASSIGNMENT REQUEST message. If the RNC has received the message,
the RNC waits until the CS service is established and then sends the
the SET UALGORSVPARA command controls whether to send the CS
RADIO BEARER SETUP message prior to the MEASUREMENT
CONTROL message. By default, this solution is disabled (default value: 0)
for both new networks and upgrade scenarios. When this solution is
enabled, the RNC preferentially sends the CS RADIO BEARER SETUP
message. When this solution is disabled, the RNC does not preferentially
send the CS RADIO BEARER SETUP message.
SET UALGORSVPARA:
SET UALGORSVPARA:
NOTE
Issue 01 (2014-12-31)

Copyright Huawei
299
BSC6900 UMTS
Release Notes

V900R016C00SPH605
If the compressed mode (CM) is required, this solution does not take effect.
Solution
Impact
If the measurement control is delayed, the handover may be delayed, which

increases the possibility of call drops. In this case, service rate increase or
decrease is delayed, affecting user experience.
Test Case
9.3.2 Major
9.3.2.1 The Huawei DRNC does not support radio link
addition with serving cell changes.
Trouble
Ticket
Number
DTS: DTS2014060307627
Description
Condition: A non-Huawei SRNC sends a RADIO LINK ADDITION

REQUEST message to a Huawei DRNC with serving links, instructing
the Huawei RNC to add links to an inter-frequency cell. During this
process, HSDPA serving cell changes are also required.
Symptom: The DRNC fails to handle the RADIO LINK ADDITION
REQUEST message and does not send a RADIO LINK ADDITION
RESPONSE message to the SRNC.
Impact: Radio link addition with HSDPA serving cell changes fails.
Severity
Major
Root Cause
In the preceding scenario, the Huawei DRNC does not support radio link
addition with HSDPA serving cell changes.
Solution

in the SET UALGORSVPARA command controls whether the DRNC
will handle radio link addition with HSDPA serving cell changes. By
default, this solution is disabled (default value: 0) for both new networks
When this solution is enabled, the DRNC sends a RADIO LINK
ADDITION RESPONSE message to the SRNC after handling a radio
link addition request with HSDPA serving cell changes. When this
solution is disabled, the DRNC cannot handle radio link addition
requests with HSDPA serving cell changes.
SET UALGORSVPARA:
SET UALGORSVPARA:
Solution
Impact
None.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
300
BSC6900 UMTS
Release Notes

V900R016C00SPH605
9.3.2.2 The measured value of the

VS.AMR.Erlang.Equiv.PLMN.RNC counter is incorrect in
MOCN scenarios.
Trouble
Ticket
Number
DTS: DTS2014060307590
Descripti
on
Condition: The multi-operator core network (MOCN) is enabled on the

network. PLMNID_INCLUDED under the IurPrivateInterfaceSwitch
parameter in the ADD UNRNC command is set to on for the DRNC and is
set to off for the SRNC.
Symptom: The value of the VS.AMR.Erlang.Equiv.PLMN.RNC counter
constantly increases and then drastically drops at 3:00 a.m..
Impact: The measured value of the VS.AMR.Erlang.Equiv.PLMN.RNC
counter is incorrect, affecting the consumption of the license item Voice
Erlang-Erlang.
Severity
Major
Root
Cause
1. A UE accesses a cell under the SRNC belonging to operator A and then

triggers a soft handover over the Iur interface to a cell under the DRNC.
The DRNC incorrectly determines that this UE belongs to operator B
and increases the value of the VS.AMR.Erlang.Equiv.PLMN.RNC
counter accordingly for operator B.
2. The SRNC initiates a UE-not-involved relocation procedure to relocate
the serving RNS role to the DRNC. On receiving the RELOCATION
REQUEST message from the core network (CN), the DRNC determines
that this UE belongs to operator A and adjusts the value of the preceding
counter for operators B and A accordingly.
3. The UE-not-involved relocation procedure fails.
4. Subsequently the SRNC initiates a radio link (RL) addition or
reconfiguration procedure on the DRNC side. The DRNC determines
that the UE belongs to operator B but does not adjust the value of this
counter for operators A and B.
5. After the UE's connection is released on the DRNC side, the DRNC
reduces the value of the VS.AMR.Erlang.Equiv.PLMN.RNC counter for
operator B accordingly.
As a result, the value of the VS.AMR.Erlang.Equiv.PLMN.RNC counter is
repeatedly measured for operator A but is less than its actual value for
operator B.
Solution
The value of the VS.AMR.Erlang.Equiv.PLMN.RNC counter is correctly

adjusted based on the mobility of the UE between different operators.
Solution
Impact
The measured value of the VS.AMR.Erlang.Equiv.PLMN.RNC counter is

correct, and the used value of the license item Voice Erlang-Erlang is
correct.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
301
BSC6900 UMTS
Release Notes

V900R016C00SPH605
9.3.2.3 The IDs of six counters in RAN16.0 are inconsistent

with the IDs of these counters in RAN15.0.
Trouble
Ticket
Number
DTS: DTS2014052903294
Descripti
on
Condition: An RNC running V900R015C00SPC525 or a later version is

upgraded to RAN16.0.
Symptom: The following counters cannot be queried by using their IDs in
RAN15.0:
VS.RRC.AttConnEstab.CSFB
VS.RRC.SuccConnEstab.CSFB
VS.RAB.AttEstabCS.CSFB.Redir
VS.RAB.SuccEstabCS.CSFB.Redir
VS.RAB.AttEstabCS.CSFB.PSHO
VS.RAB.SuccEstabCS.CSFB.PSHO
Impact: Routine maintenance and network optimization are affected.

Severity
Major
Root
Cause
The IDs of the preceding counters in RAN16.0 are inconsistent with the
IDs of these counters in RAN15.0.
Solution
The IDs of the preceding counters in RAN16.0 have been changed to the
same IDs of those in RAN15.0.
Solution
Impact
The preceding counters can be queried by using their IDs.
Test Case
9.3.2.4 UEs that cannot be handed over to the LTE network

still start RSCP measurements after the function of servicebased UMTS-to-LTE handover requiring RSCP measurement
is enabled.
Trouble
Ticket
Number
DTS: DTS2014052400829
Descriptio
n
Condition:
Issue 01 (2014-12-31)
The function of service-based UMTS-to-LTE handover requiring RSCP

measurement is enabled. That is, the
HO_LTE_SERVICE_NEED_RSCP_SWITCH under the

Copyright Huawei
302
BSC6900 UMTS
Release Notes

V900R016C00SPH605
HoSwitch1 parameter in the SET UCORRMALGOSWITCH

command is set to on, or the
HO_LTE_SERVICE_NEED_RSCP_SWITCH under the
U2LServAlgoSwitch parameter in the ADD
UCELLU2LTEHONCOV command is set to on. If this switch has
different values in the two commands, the value in the ADD
UCELLU2LTEHONCOV command prevails.
Some UEs cannot be handed over to the LTE network (for example,
UE's service profile identifier (SPID) forbids the UE to perform a
handover to the LTE network).
Symptom: UEs that cannot be handed over to the LTE network still start
RSCP measurements.
Impact: The number of RSCP measurement reports in a cell increases,
which slightly increases the uplink cell load.
Severity
Major
Root
Cause
After the function of service-based UMTS-to-LTE handover requiring

RSCP measurement is enabled, the RNC does not determine whether a
UE can be handed over to the LTE network when instructing the UE to
perform an RSCP measurement. As a result, UEs that cannot be handed
over to the LTE network still start RSCP measurements.
Solution
After the function of service-based UMTS-to-LTE handover requiring

RSCP measurement is enabled, the RNC does not instruct UEs that
cannot be handed over to the LTE network to perform RSCP
measurements.
Solution
Impact
After this problem is solved, the number of RSCP measurement reports in

a cell decreases, which slightly reduces the uplink cell load.
Test Case
9.3.2.5 Services cannot be set up after a large number of

event 1J reports fail to be processed.
Trouble
Ticket
Number
DTS: DTS2014061902195
Descripti
on
Condition: The RNC fails to process an event 1J report sent from a UE.
The UE then sends a report related to another event and triggers a
procedure to start the compressed mode, change its serving cell, or
reconfigure HSPA power control parameters.
This phenomenon occurs in a large scale on the network.
Symptom: Other UEs under the RNC cannot successfully initiate services.
Impact: The RRC connection setup success rate decreases, and the cell
throughput decreases.
Severity
Major
Root
When processing the event 1J report, the RNC pre-applies for some RNC
Issue 01 (2014-12-31)

Copyright Huawei
303
BSC6900 UMTS
Release Notes

V900R016C00SPH605
Cause
system resources. However, the RNC does not release these resources in
time in the preceding scenario. When the preceding phenomenon occurs in
a large scale on the network, a large number of RNC system resources are
occupied, and consequently new UEs fail to access the network.
Solution
The RNC releases the pre-allocated system resources immediately after it

fails to process the event 1J report.
Solution
Impact
After this solution takes effect, the RRC connection setup success rate
increases, and the cell throughput increases. In addition, the number of soft
handover attempts increases, and the number of rate adjustments through
dynamic channel configuration control (DCCC) increases.
Test
Case
9.3.2.6 Services carried on a port of the SCUa board are

affected due to inconsistency between the detection result
and actual status of the port.
Trouble
Ticket
Number
DTS: DTS2014061200807
Description
Condition: The detection result of a port on the SCUa board is

inconsistent with the actual status of the port.
Symptom: The fault isolation and self-healing function is not applied to
the faulty port on the SCUa board.
Impact: Services carried on the faulty port of the SCUa board are
affected.
Severity
Major
Root Cause
The mechanism for detecting port communication on the SCUa board

does not include verification of detection results. When the detection
result shows that a port is normal, the port is regarded as functional even
if the actual status of the port is inconsistent with the detection result. In
this case, The fault isolation and self-healing function is not applied to
the faulty port. As a result, services carried on the faulty port are
affected.
Solution
The mechanism for detecting port communication on the SCUa board

has been optimized so that detection results are verified. When the
detection result is inconsistent with the actual status of a port, the port is
regarded as faulty and the fault isolation and self-healing function is
applied to the faulty port.
Solution
Impact
The CPU usage of the SCUa board decreases by 0%~2%.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
304
BSC6900 UMTS
Release Notes

V900R016C00SPH605
9.3.2.7 KPIs related to the CS CDR and PS CDR deteriorate

when the active port is on the GOUe working in standby
mode and the NodeB enables the FPMUX function.
Trouble
Ticket
Number
DTS: DTS2014062001626
Description
Condition: When the active port is on the GOUe working in standby

mode, the NodeB enables the FPMUX function.
Symptom: In UMTS networks, KPIs related to the CS CDR and PS
CDR deteriorate.
Impact: Quality of voice services and data services deteriorates.
Severity
Major
Root Cause
A new user is established upon the releasing of a released user, and the
active port is on the GOUe working in standby mode. When deleting a
forwarding table of the released user, the GOUe incorrectly deletes that
of the new user due to insufficient protection. As a result, packets of the
new user are discarded after they are demodulated using the FPDEMUX
function but fail to find the forwarding table.
Solution
Enhance protection for the GOUe when a forwarding table is to be

deleted, and ensure that the forwarding table of a new user is not deleted
when the GOUe deletes that of a released user.
Solution
Impact
None
Test Case
9.3.3 Minor
9.3.3.1 The integrity of RNC configuration data may be
damaged when the "easy-in, difficult-out" principle is used
to configure intra-frequency neighboring cells on the CME.
Trouble
Ticket
Number
DTS: DTS2014060307399
Description
Condition:
Issue 01 (2014-12-31)
The RNC version is BSC6900 V900R015C00SPH516 or later.
The "easy-in, difficult-out" principle is used to configure intrafrequency neighboring cells on the CME.
The RESERVED_SWITCH_2_BIT14 under the RsvSwitch2

parameter in the SET UALGORSVPARA command is set to on.
There is at least one cell that has more than 31 intra-frequency

neighboring cells.

Copyright Huawei
305
BSC6900 UMTS
Release Notes

V900R016C00SPH605
Symptom: After an RNC upgrade to BSC6900 V900R016C00, an error

message "The number of intra-frequency neighboring cells of the cell
reaches the maximum." is displayed in the execution report of the
following command:
STR DATAVALID: DataType=RADIO;
Impact: The integrity of RNC configuration data is damaged.
Severity
Minor
Root Cause
In BSC6900 V900R015C00SPH516 or later, the maximum number of

intra-frequency neighboring cells is configured by a reserved parameter
but the constraints between the maximum number of intra-frequency
neighboring cells and a reserved parameter is not implemented on the
CME and therefore abnormal data is activated on the RNC. In addition,
there is no mechanism on the RNC to process abnormal data and the
integrity of RNC configuration data is damaged.
Solution
In BSC6900 V900R016C00, the

PERFENH_INTRAFREQ_NCELL_MAX_NUM_SWITCH under
the PerfEnhanceSwitch4 parameter in the SET UCORRMPARA
command is used to replace the function of the
the SET UALGORSVPARA command.
If there is at least one cell whose number of intra-frequency neighboring
cells exceeds 31, the
PERFENH_INTRAFREQ_NCELL_MAX_NUM_SWITCH is set to
off after the upgrade. If the number of intra-frequency neighboring cells
of all cells is less than or equal to 31, this switch is set to on after the
upgrade.
Solution
Impact
None
Test Case
9.3.3.2 Synchronization between the controller and the

U2000/CME has not been performed for a long time because
configuration synchronization times out for several times.
Trouble
Ticket
Number
iCare: 2417094
Description
Condition: When the EXP CFGMML command is being executed, the

command for exporting the data for configuration synchronization on the
U2000/CME is also being executed.
DTS: DTS2014051906196
Symptom: Execution of the command for exporting the data for

configuration synchronization on the U2000/CME times out for several
times. As a result, the synchronization between the controller and the
U2000/CME cannot be performed for a long time.
Impact: The controller data is not synchronized to the U2000/CME in a
Issue 01 (2014-12-31)

Copyright Huawei
306
BSC6900 UMTS
Release Notes

V900R016C00SPH605
timely manner.
Severity
Minor
Root Cause
When the EXP CFGMML command is being executed, the controller

receives the command for exporting the data for configuration
synchronization delivered by the U2000 and CME. Execution of the
EXP CFGMML command is too slow and blocks execution of the
command for exporting the data for configuration synchronization. As a
result, execution of the command for exporting the data for
configuration synchronization times out and a new full synchronization
is triggered. In this situation, the problem persists for a long time.
Solution
If one command for exporting data, such as EXP CFGMML and

EXP CFGBCP is being executed, re-execution of the EXP
CFGMML or EXP CFGBCP command will be rejected. If the
command for exporting data for configuration synchronization
delivered by U2000/CME is being executed, re-execution of the EXP
CFGBCP command will be rejected. This implementation does not
take effect if the EXP CFGMML or EXP CFGBCP command is
executed periodically.
If the message carrying the command for exporting the data for
configuration synchronization is in the queue during execution of the
EXP CFGMML or EXP CFGBCP command, configuration data
between the controller and the U2000/CME is synchronized after
execution of the EXP CFGMML or EXP CFGBCP command is
complete or times out.
If one EXP CFGMML command is being executed, execution of the

EXP CFGMML or EXP CFGBCP command will be rejected and
the error message "Please try again later as the EXP CFGMML
command is being executed." is displayed.
If one EXP CFGBCP command is being executed, execution of the

EXP CFGMML or EXP CFGBCP command will be rejected and
the error message "Please try again later as the EXP CFGBCP
command is being executed." is displayed.
If one command for exporting data for configuration synchronization

delivered by the U2000/CME is being executed, execution of the
EXP CFGBCP command will be rejected and the error message
"The export command for configuration synchronization on the
U2000/CME is being executed. Please try again later." is displayed.
Solution
Impact
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
307
BSC6900 UMTS
Release Notes

V900R016C00SPH605
9.3.3.3 The
AOUc/POUc/UOIc/PEUc/SPUb/DPUe/NIUa/FG2c/GOUc board
incorrectly reports ALM-20280 Board Temperature
Abnormal.
Trouble
Ticket
Number
iCare: 2572077, 2572059, and 2572067
Description
Condition: The CPU temperature sensor reports incorrect temperature.
DTS: DTS2014061209177
Symptom: ALM-20280 Board Temperature Abnormal is reported.

Impact: The fan box runs at full speed, which does not affect services.
Severity
Minor
Root Cause
A board has three temperature monitoring points. If the temperature of

any of the three temperature monitoring points exceeds the preset
threshold, ALM-20280 Board Temperature Abnormal is reported. Due to
the incorrect temperature reported by the CPU temperature sensor,
ALM-20280 Board Temperature Abnormal is reported when the board
temperature is within the normal range.
Solution
ALM-20280 Board Temperature Abnormal is now reported when the

temperatures of two temperature monitoring points exceed the preset
threshold.
Solution
Impact
None
Test Case
9.3.4 Suggestion
9.3.4.1 The UMTS cell load information sent by the RNC to
the eNodeB is delayed.
Trouble
Ticket
Number
DTS: DTS2014060303931
Descriptio
n
Condition: The mobility load balancing (MLB) feature is enabled for the
eNodeB.
Symptom: The UMTS cell load state sent by the RNC to the eNodeB is
not congested. When the eNodeB attempts to hand over a UE to a UMTS
cell, the UMTS cell rejects the handover request due to cell resource
congestion.
Impact: The number of LTE-to-UMTS handover preparation failures
increases.
Severity
Suggestion
Root
The UMTS cell load information sent by the RNC to the eNodeB is
Issue 01 (2014-12-31)

Copyright Huawei
308
BSC6900 UMTS
Release Notes

V900R016C00SPH605
Cause
delayed. Therefore, the eNodeB cannot obtain the accurate UMTS cell
load state and incorrectly switches the UE to a congested UMTS cell,
leading to handover preparation failures.
Solution
The solution for this problem is controlled by the following parameters:
The LoadUptForLTETimerLen parameter has been added to the SET

ULDM command to control the period for uploading UMTS cell load
information. When this parameter is set to a value other than 0, the
RNC scans the UMTS cell load changes in the subsystems within the
period specified by this parameter. By default, this parameter is set to
3. In upgrade scenarios, this parameter is set to 0. When this parameter
is set to 0, this solution does not take effect and it takes a maximum of
10s for the RNC to scan the UMTS cell load changes.
Bit 0 to bit 7 under the RsvU32Para1 parameter in SET

UALGORSVPARAPHY command has been used to control the
maximum number of UMTS cell load broadcast messages that can be
sent to the eNodeB by an RNC subsystem per second. The maximum
value of this parameter is 255. When this parameter is set to 0, each
cell can send only one UMTS cell load broadcast message to the
eNodeB per second. By default, this parameter is set to 0 for both new
Solution
Impact
After this solution takes effect, the number of LTE-to-UMTS handover

preparation failures decreases.
Test Case
9.3.4.2 The call drop rate increases after the Fast Radio
Bearer Setup feature is enabled in weak coverage areas.
Trouble
Ticket
Number
DTS: DTS2014040701688
Descripti
on
Condition: The Fast Radio Bearer Setup feature is enabled in weak

coverage areas.
Symptom: The call drop rate increases.
Impact: Counters measuring the call drop rate deteriorate.
Severity
Suggestion
Root
Cause
UEs that formerly failed to access the network successfully access the
network after the Fast Radio Bearer Setup feature is enabled in weak
coverage areas. However, if the coverage performance does not improve
after these UEs access the network, these UEs experience call drops due to
radio link (RL) out-of-synchronization or a procedure failure over the Uu
interface. As a result, the call drop rate increases.
Solution
The RsvU8Para36 parameter in the SET UALGORSVPARA command

specifies the Ec/N0 threshold for determining whether to use the Fast Radio
Bearer Setup feature. The GUI value of this parameter ranges from 0 to 49,
and its actual value ranges from -24.5 dB to 0 dB. By default, this
Issue 01 (2014-12-31)

Copyright Huawei
309
BSC6900 UMTS
Release Notes

V900R016C00SPH605
parameter is set to 0, indicating that whether to enable this feature is not

under the control of the Ec/N0.
If the Ec/N0 of a certain period of time cannot be obtained upon service
setup, whether to enable the Fast Radio Bearer Setup feature is not under
the control of the Ec/N0. This period is specified by the EcN0EffectTime
parameter in the ADD UCELLFRC or SET UFRC command.
Run the SET UALGORSVPARA command to set RsvU8Para36. The
following is an example:
Solution
Impact
After this solution takes effect, the service setup success rate decreases in
the preceding scenario, and consequently the call drop rate decreases.
Test Case
9.3.4.3 A cell enabled with the Downlink Enhanced

CELL_FACH feature accommodates a lesser number of DCH
UEs than the configuration allows due to a large number of
FACH UEs are admitted.
Trouble
Ticket
Number
DTS: DTS2014061401828
Descriptio
n
Condition:
The FACH_USER_NUM_NOT_CTRL switch under the

NBMCacAlgoSwitch parameter in the ADD
UCELLALGOSWITCH command is turned off, which controls
whether to lift the restriction on the number of UEs that use FACHs
(hereafter referred to as FACH UEs) in a cell.
The cell enabled with the Downlink Enhanced CELL_FACH feature.
Symptom: The cell accommodates a greater number of UEs in the

CELL_FACH state.
Impact: The cell accommodates a lesser number of UEs that use DCHs
(hereafter referred to as DCH UEs) than the configurations allow.
Severity
Suggestion
Root
Cause
UEs in the CELL_FACH state include FACH UEs and UEs that transmit
downlink data on HS-DSCHs (hereafter referred to as E-FACH UEs).
When admitting FACH UEs, the RNC does not consider the configuration
limit for the number of UEs in the CELL_FACH state. When this limit is
reached, new FACH UEs are still successfully admitted to the cell. As a
result, this limit is exceeded.
The configuration limit for the total number of UEs in the cell covers
DCH UEs and UEs in the CELL_FACH state. When the cell
accommodates a greater number of UEs in the CELL_FACH state than
the configuration allows, the cell can only accommodate a lesser number
of DCH UEs than the configuration allows.
Issue 01 (2014-12-31)

Copyright Huawei
310
BSC6900 UMTS
Release Notes

V900R016C00SPH605
Solution
The RNC can now consider the configuration limit for the number of UEs
in the CELL_FACH state when admitting FACH UEs. The RNC does so
when the newly added
PERFENH_FACHUSER_NUM_CTRL_ENH_SWITCH under the
PerfEnhanceSwitch parameter in the SET UNBMPARA command is
turned on. For new networks this solution is enabled (default value: 1). In
upgrade scenarios, this solution is disabled (default value: 0).
To turn on this switch, run the following command:
SET UNBMPARA:
PerfEnhanceSwitch=PERFENH_FACHUSER_NUM_CTRL_ENH_SWI
TCH-1;
To turn off this switch, run the following command:
SET UNBMPARA:
PerfEnhanceSwitch=PERFENH_FACHUSER_NUM_CTRL_ENH_SWI
TCH-0;
Solution
Impact
The number of FACH UEs is now subject to the configuration limit for
the number of UEs in the CELL_FACH state. Therefore, this limit will not
be exceeded and the cell can accommodate a configured number of DCH
UEs.
Test Case
9.3.4.4 The solution for the problem that the channel type
of a UE frequently switches between HSPA and DCH when
the UE performs LTE measurement without starting the
compressed mode is not controlled by any MML parameter.
Trouble
Ticket
Number
DTS: DTS2014053002752
Descriptio
n
The channel type of a UE frequently switches between HSPA and DCH

when the UE performs LTE measurement without starting the
compressed mode. However, there is no MML parameter controlling the
solution for this problem.
Severity
Suggestion
Root
Cause
The RNC directly solves this problem and does not specify an MML
parameter for controlling the solution for this problem.
Solution
The RESERVED_SWITCH_15_BIT1 under the RsvSwitch15

parameter in the SET UALGORSVPARA command is used to control
this solution. By default, this solution is enabled (default value: 1) for
new networks and is disabled (default value: 0) for upgrade scenarios.
When this solution takes effect, UEs that are performing LTE
measurement are now prohibited from using periodic DRD.

SET UALGORSVPARA:
Issue 01 (2014-12-31)

Copyright Huawei
311
BSC6900 UMTS
Release Notes

V900R016C00SPH605

SET UALGORSVPARA:
Solution
Impact
None
Test Case
9.3.4.5 SRBs cannot be carried on HS-DSCHs when the SRB

D2H enhancement algorithm is enabled and the uplink
admission fails.
Trouble
Ticket
Number
DTS: DTS2014061901760
Descriptio
n
Condition:
The optimized SRB D2H algorithm is enabled, that is, the

in the SET UALGORSVPARA command is set to on.
The conditions for SRB reconfigurations from DCHs to E-DCHs and

HS-DSCHs are met.
The uplink admission fails.
Symptom: SRBs cannot be switched from DCHs to HS-DSCHs.

Impact: User experience deteriorates.
Severity
Suggestion
Root
Cause
In the preceding scenario, SRB reconfiguration attempt from DCHs to HSDSCHs can be made only once.
Solution
SRB reconfiguration attempts now can be made without using the HSPA+
feature or SRB reconfiguration attempts from DCHs to HS-DSCHs can be
made when DCHs to E-DCHs reconfiguration is not performed.
Solution
Impact
User experience improves when the cell coverage is good or the cell
downlink non-HSPA power resources/downlink SF resources are
congested.
Test Case
9.3.4.6 Cross-Iur handovers fail when SRBs are carried on EDCHs in the uplink.
Trouble
Ticket
Issue 01 (2014-12-31)
DTS: DTS2014062010199

Copyright Huawei
312
BSC6900 UMTS
Release Notes

V900R016C00SPH605
Number
Descrip
tion
A Huawei RNC is interconnected with RNCs of other vendors and the two
sides use different methods to process the unidirectional-DCH-Indicator
information element (IE). As a result, Static Relocation fail when the SRBs
are carried on E-DCHs in the uplink.
Severity
Suggestion
Root
Cause
The Huawei RNC does not carry the unidirectional-DCH-Indicator IE in the

RL_SETUP_REQ message and therefore the RNCs of some vendors
consider that the SRBs are carried on DCHs in both the uplink and downlink.
The unidirectional-DCH-Indicator IE is optional. For details about this IE,
see section 9.2.2.4A in 3GPP TS 25.423 V9.1.0.
However, the SRB information carried in the RELOCATION_REQIURED
message during a static relocation indicates that the SRBs are carried on EDCHs in the uplink and on DCHs in the downlink. As a result, the
information used for the RNCs of some vendors to make cross-Iur handover
decisions is inconsistent, leading to cross-Iur handover failures.
Solution
The RESERVED_SWITCH_0_BIT4 under the RsvSwitch0 parameter in

the SET UNRNCRSVPARA command is now used to control whether the
DRNC Iur interface prohibits SRBs from being carried on E-DCHs. When
this switch is set to on, the SRB over E-DCH configuration is disabled before
a cross-Iur handover, that is, SRBs are switched from E-DCHs to DCHs
before the cross-Iur handover. When this switch is set to off, the cross-Iur
handover is performed without disabling the SRB over E-DCH configuration.
By default, this solution is disabled (default value: 0) for both new networks
After this solution is enabled, SRBs will not be carried on E-DCHs and the
problem is solved.


Solution
Impact
After this solution is enabled, the success rate of cross-Iur handovers

increases but the number of RB reconfigurations also increases, which
therefore increases the PS call drop rate. In addition, SRBs are switched from
E-DCHs to DCHs, which reduces the uplink throughput of a single user.
Test
Case
Issue 01 (2014-12-31)

Copyright Huawei
313
BSC6900 UMTS
Release Notes

V900R016C00SPH605
9.3.4.7 The permissions of local users are lost when the BSC
database is abnormal.
Trouble
Ticket
Number
iCare: 2745580
Descriptio
n
Condition: The connection between the BSC and the U2000 is normal. A
local user logs in to the FTP server when the BSC database is abnormal.
DTS: DTS2014061207937
Symptom: After the local user logs in to the LMT, a message is displayed
indicating that the local user has no permission to execute MML
commands.
Impact: The permissions of the local user are lost. As a result, the local
user cannot execute MML commands properly.
Severity
Suggestion
Root
Cause
A defect exists in the FTP login of a local user. Due to the defect,
information about the local user fails to be obtained during the login if the
BSC database is abnormal. In this case, the BSC grants the minimum
permissions to the local user.
Solution
During the authentication of an FTP login of a local user, if information

about the local user fails to be obtained due to database exceptions, the
BSC now stops the login and returns a message indicating the login
failure.
Solution
Impact
The permissions of local users are not affected even if the BSC database is
abnormal.
Test Case
9.3.4.8 Instantaneous traffic is too heavy after the FTP

upload and download performance is optimized.
Trouble
Ticket
Number
DTS: DTS2014060902431
Descriptio
n
Condition: The base station controller works as an FTP server to upload

and download files.
Symptom: Instantaneous traffic is too heavy during file upload and
download.
Impact: Traffic on the base station controller's Ethernet adapters is
congested. As a result, data transmission becomes slow and some packets
are lost.
Severity
Suggestion
Root
Cause
After the FTP upload and download performance is optimized, the base
station controller does not perform flow control over instantaneous traffic.
Solution
Flow control is now performed over FTP transmission to ensure that
Issue 01 (2014-12-31)

Copyright Huawei
314
BSC6900 UMTS
Release Notes

V900R016C00SPH605
traffic is smoothly processed during file upload and download. In this

way, data is transmitted symmetrically.
Solution
Impact
None
Test Case
9.3.4.9 The value of a single bit in the FPGA of the

AOUc/POUc/UOIc/PEUc/DPUe/NIUa/FG2c/GOUc board is
changed and the FPGA cannot recover through self-healing.
Trouble
Ticket
Number
DTS: DTS2014061808757
Descriptio
n
Condition: The value of a single bit in the FPGA of the

AOUc/POUc/UOIc/PEUc/DPUe/NIUa/FG2c/GOUc board is changed.
Symptom: The board does not perform self-healing on the changed bit of
the FPGA.
Impact: Internal data of the FPGA is incorrect, which affects services.
Severity
Suggestion
Root
Cause
The AOUc/POUc/UOIc/PEUc/DPUe/NIUa/FG2c/GOUc board does not

perform self-healing when the value of a single bit in the FPGA is
changed.
Solution
The AOUc/POUc/UOIc/PEUc/DPUe/NIUa/FG2c/GOUc board rectifies

the error when the value of a single bit in the FPGA is changed.
The BIT8 of the RSVDSW2 parameter in the SET DEVRSVDPARA
command is used to control this solution. By default, this solution is
enabled (default value: 1) for both new networks and upgrade scenarios.
When this solution is enabled, the
AOUc/POUc/UOIc/PEUc/DPUe/NIUa/FG2c/GOUc board rectifies the
error if the value of a single bit in the FPGA is changed. When this
solution is disabled, the
AOUc/POUc/UOIc/PEUc/DPUe/NIUa/FG2c/GOUc board does not
rectify the error if the value of a single bit in the FPGA is changed.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
315
BSC6900 UMTS
Release Notes

V900R016C00SPH605
9.4 Known Issues

9.4.1 Critical
None
9.4.2 Major
None
9.4.3 Minor
None
9.4.4 Suggestion
None
Issue 01 (2014-12-31)

Copyright Huawei
316
BSC6900 UMTS
Release Notes

V900R016C00SPH602
10
Changes from
V900R016C00SPH602
10.1 Change Summary
Compared with those in BSC6900 V900R016C00SPC600, capacity increases/performance
Hardware
V900R016C00SPH602.
Features
Compared with those in BSC6900 V900R016C00SPC600, 0 features have been added, 8
Resolved Issues
Compared with those in BSC6900 V900R016C00SPC600, 0 critical issues, 6 major issues, 6
Issue 01 (2014-12-31)

Copyright Huawei
317
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Fault management
License management
functions remain unchanged in V900R016C00SPH602. For details, see 10.1.5.4 License
Management.

10.1.2 Hardware
New Hardware
None
Modified Hardware
None
10.1.3 Features
V900R016C00SPC600 to V900R016C00SPH602.
Issue 01 (2014-12-31)

Copyright Huawei
318
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Change type
Feature description
BSC6900 V900R016C00SPH602.

This section provides the summary of the known issues in BSC6900 V900R016C00SPC600
Issue description
Severity
Solution impact
Parameter control
in Summary of Resolved Issues delivered with the release notes for a version later than
BSC6900 V900R016C00SPH602.


Changes.
Issue 01 (2014-12-31)

Copyright Huawei
319
BSC6900 UMTS
Release Notes

V900R016C00SPH602



10.2 Feature Changes

10.2.1 New Features
None

10.2.2.1 Optimized Load Based Dynamic Adjustment of
PCPICH
Description
The Load Based Dynamic Adjustment of PCPICH feature has been optimized. The P-CPICH
power of co-sector, co-coverage, and intra-band neighboring cell can be jointly adjusted.
Implementation
A cell-level parameter LdbPcpichPwrAdjLinkageAtrb is added to specify the attribute of
joint P-CPICH power adjustment.
When this parameter is set to 0, the P-CPICH power of the current cell does not need to
be jointly adjusted.
When this parameter is set to 1, the current cell is the dominant cell in joint P-CPICH
power adjustment. The dominant cell periodically checks whether the P-CPICH power of
itself and its co-coverage neighboring cells needs to be jointly adjusted. If yes, the
dominant cell sends an indication to the passive cells in the same coverage area,
instructing these cells to jointly adjust their P-CPICH power. It is recommended that one
coverage area be configured with only one dominant cell.
When this parameter is set to 2, the current cell is a passive cell in joint P-CPICH power
adjustment. Passive cells adjust their P-CPICH power according to the indication sent by
the dominant cell.
Issue 01 (2014-12-31)

Copyright Huawei
320
BSC6900 UMTS
Release Notes

V900R016C00SPH602

After the joint P-CPICH power adjustment function takes effect, the coverage scope of cocoverage neighboring cells becomes almost the same. This increases the DRD success rate but
causes coverage holes on multiple carriers, which reduces the handover success rate and
therefore increases the call drop rate. After some UEs are handed over to intra-frequency
neighboring cells, the number of UEs in the current cell decreases, which increases the
available HSPA power in the current cell and increases the cell throughput.
Impact on NEs
None
Impact on Hardware
None

None

None

Bit 0 and bit 1 under the RsvU8Para10 parameter in the SET
UCELLALGORSVPARA command has been used to set the attribute of joint PCPICH power adjustment.
The RsvU8Para10 parameter must be set based on site configurations.
For example, the current value of RsvU8Para10 is 8 (binary value: 0000 1000). After bit 0 and bit 1
under this parameter is set to 1, RsvU8Para10 is changed to 9 (binary value: 0000 1001). The following
shows an example of this configuration:
SET UCELLALGORSVPARA: CellId=xxx, RsvU8Para10=9;

None

None

None
Related Operations
Run the SET UCELLALGORSVPARA command to set the attribute of joint P-CPICH
power adjustment, the following is an example:
SET UCELLALGORSVPARA: CellId=xxx, RsvU8Para10=x;
Issue 01 (2014-12-31)

Copyright Huawei
321
BSC6900 UMTS
Release Notes

V900R016C00SPH602

DTS: DTS2014042407686
Feature ID
WRFD-150236
10.2.2.2 Inter-RAT DRD for Combined Services

Description
If a UE has established PS services on a UMTS network, newly-established CS services can
be transferred to the GSM system in a directed retry decision (DRD) procedure.
Implementation
DR_INTER_RAT_CSPS_MULTI_RAB_DRD_SWITCH under the DrSwitch parameter
in the SET UCORRMALGOSWITCH command controls whether to enable this feature. By
default, this feature is disabled (default value: 0) for both new networks and upgrade
scenarios.
This feature is enabled when both
DR_INTER_RAT_CSPS_MULTI_RAB_DRD_SWITCH and
DR_INTER_RAT_DRD_SWITCH under the DrSwitch parameter are turned on. If new CS
services fail to be established on a UMTS network because of an admission failure, the CS
services are transferred to the GSM system in a DRD procedure under either of the following
conditions:
The UE is in the CELL_DCH state and has only established PS services (excluding PTT
services) or Iu signaling connection has been set up in the PS domain.
The UE is in CELL_FACH state and only PS BE services have been established. When
the UE is in CELL_FACH state and newly-established CS services experience an
admission failure, the RNC reallocates DCHs for PS services whose service rate is set at
0 kbit/s so that the UE transits from CELL_FACH to CELL_DCH. Then, CS services are
transferred to the GSM system in a DRD procedure. If the UE fails to transit from
CELL_FACH to CELL_DCH, the RNC releases connection over the Iu interface in the
CS domain, with a cause value "No Radio Resources Available in Target cell".

After this feature is enabled, CS user experience improves and the resource utilization rate of
GSM and UMTS networks increases.
Impact on NEs
None
Impact on Hardware
None
Issue 01 (2014-12-31)

Copyright Huawei
322
BSC6900 UMTS
Release Notes

V900R016C00SPH602

None

This function is controlled by the license control item "Inter System Direct Retry".
Feature enhancement does not involve license updates.

DR_INTER_RAT_CSPS_MULTI_RAB_DRD_SWITCH under the DrSwitch
parameter in the SET UCORRMALGOSWITCH command controls whether to enable
this feature.

Enabling this feature increases the number of inter-RAT directed retries. To be specific,
the values of the following counters rise: VS.IRATHO.SuccOutCS.DR,
VS.IRATHO.AttRelocPrepOutCS.DR, and S.IRATHO.SuccRelocPrepOutCS.DR. In
addition, the number of abnormal PS service releases in the case of multi-RAB services
for cell during an inter-RAT handover increases. To be specific, the value of
VS.MultiRAB.PSAbnormRel.ResumeExp increases.

None

None
Related Operations
DrSwitch=DR_INTER_RAT_CSPS_MULTI_RAB_DRD_SWITCH-1;
Run the following command to disable this feature:
DrSwitch=DR_INTER_RAT_CSPS_MULTI_RAB_DRD_SWITCH-0;

DTS: DTS2014032904942, DTS2014050604450
Feature ID
WRFD-02040002
Issue 01 (2014-12-31)

Copyright Huawei
323
BSC6900 UMTS
Release Notes

V900R016C00SPH602
10.2.2.3 Control on the Scope of Intra-Frequency Periodic

Measurement Reports
Description
The scope of cells for which measurement reports are sent by a UE can be specified by the
intra-frequency periodic measurement report controlling function.
Implementation
The IntraFreqMrReportRange parameter is added to the RNC MML command SET

UMRCTRL to specify the scope of cells for which intra-frequency periodic
measurement reports are sent by a UE.
The IntraFreqMrReportRange parameter is added to the cell-level MML command

ADD UCELLMR to specify the scope of cells for which intra-frequency periodic
measurement reports are sent by a UE.
When the IntraFreqMrReportRange parameter is set in both the RNC-level command

SET UMRCTRL and cell-level command ADD UCELLMR, the parameter value set
by the cell-level command takes precedence.

None
Impact on NEs
None
Impact on Hardware
None

None

None
The IntraFreqMrReportRange parameter can be set in the RNC MML command

SET UMRCTRL or cell-level MML command ADD UCELLMR to specify the
scope of cells for which intra-frequency periodic measurement reports are sent by a
UE.
When the IntraFreqMrReportRange parameter is set in both the RNC-level

command SET UMRCTRL and cell-level command ADD UCELLMR, the
parameter value set by the cell-level command takes precedence.

None
Issue 01 (2014-12-31)

Copyright Huawei
324
BSC6900 UMTS
Release Notes

V900R016C00SPH602
None

None
Related Operations
To limit the scope of cells for which intra-frequency periodic measurement reports are
sent by a UE at the RNC level, run the SET UMRCTRL command. In the following
example, the scope is limited to cells in the active set:
SET UMRCTRL: IntraFreqAmountOfReport=WITHIN_ACTIVE_SET;
To limit the scope of cells for which intra-frequency periodic measurement reports are
sent by a UE at the cell level, run the ADD UCELLMR command. In the following
example, the scope is limited to cells in the active set:
ADD UCELLMR: CellId=xxx, IntraFreqAmountOfReport= WITHIN_ACTIVE_SET;

DTS: DTS2014051202476
Feature ID
None
10.2.2.4 Control on the Number of Intra-Frequency Periodic

Measurement Reports
Description
The number of measurement reports sent by a UE can be specified by the intra-frequency
periodic measurement report controlling function.
Implementation
The IntraFreqAmountOfReport parameter is added to the RNC MML command SET

UMRCTRL to specify the number of intra-frequency periodic measurement reports sent
by a UE.
The IntraFreqAmountOfReport parameter is added to the cell-level MML command

ADD UCELLMR to specify the number of intra-frequency periodic measurement
reports sent by a UE.
When the IntraFreqAmountOfReport parameter is set in both the RNC-level command

SET UMRCTRL and cell-level command ADD UCELLMR, the parameter value set
by the cell-level command takes precedence.

None
Impact on NEs
None
Issue 01 (2014-12-31)

Copyright Huawei
325
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Impact on Hardware
None

None

None
The IntraFreqAmountOfReport parameter can be set in the RNC MML command

SET UMRCTRL or cell-level MML command ADD UCELLMR to specify the
number of intra-frequency periodic measurement reports sent by a UE.
When the IntraFreqAmountOfReport parameter is set in both the RNC-level

command SET UMRCTRL and cell-level command ADD UCELLMR, the
parameter value set by the cell-level command takes precedence.

None

None

None
Related Operations
To set the number of intra-frequency periodic measurement reports sent by a UE at the

RNC level, run the SET UMRCTRL command. In the following example, the number
is set to 8:
SET UMRCTRL: IntraFreqAmountOfReport=D8;
To set the number of intra-frequency periodic measurement reports sent by a UE at the

cell level, run the ADD UCELLMR command. In the following example, the number is
set to 8:
ADD UCELLMR: CellId=xxx, IntraFreqAmountOfReport=D8;

DTS: DTS2014051202476
Feature ID
None
Issue 01 (2014-12-31)

Copyright Huawei
326
BSC6900 UMTS
Release Notes

V900R016C00SPH602
10.2.2.5 Immediately Notifying the Peer End of the Receive

Buffer Space Update
Description
When the remaining space of the receive buffer over an SCTP link is changed from 0 to a
value other than 0, the base station controller immediately notifies the peer end of the buffer
space update.
Implementation
The base station controller now sends the SACK packet upon a buffer space update to notify
the peer end of the update, regardless of whether the peer end sends a detection packet.
SW15(SwPara15) of Reserved Switch Parameter1in the SET TNRSVDPARA command
controls whether to enable this solution. By default, this solution is disabled (default value: 0)

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
Issue 01 (2014-12-31)

Copyright Huawei
327
BSC6900 UMTS
Release Notes

V900R016C00SPH602


DTS2014051201678
Feature ID
None
10.2.2.6 Upgrade Tool Supporting Risk Check Before an

Upgrade
Description
With this feature, the upgrade tool supports the risk check function before an upgrade. This
feature enables the upgrade tool to:
Automatically check the running status of the BSC before the upgrade.
Display check reports.
Remind users to rectify risks before the upgrade.

During a U2000-based upgrade of the BSC, the upgrade tool does not support the risk check function.
Implementation
The upgrade tool provides the Risk check option, as shown in the following figure.
If this option is selected:
The Pre-upgrade button changes to the Risk check button.
When uploading the NE software installation package, users also need to upload the
risk check package corresponding to the NE software version.
Before the pre-upgrade, the upgrade tool automatically performs risk check and
generates a check report.
If the check report only includes passed items (green), users can perform subsequent
upgrade operations.
If the check report includes warning items (yellow), the running of the BSC to be
upgraded has potential risks but has no critical impacts on the upgrade. In this
situation, users can perform subsequent upgrade operations.
Issue 01 (2014-12-31)

Copyright Huawei
328
BSC6900 UMTS
Release Notes

V900R016C00SPH602
If the check report includes failed items (red), the running of the BSC to be upgraded
has critical risks and may cause upgrade failures. In this situation, users are not
allowed to perform subsequent upgrade operations. Instead, these risks must be
eliminated before the upgrade.
If this option is deselected, the upgrade tool does not perform risk check before the
upgrade. Instead, it implements the upgrade following the original procedure.

None
Impact on NEs
None
Impact on Hardware
None

None

None

None

None

None

None
Related Operations
1.
Contact Huawei engineers who can obtain the risk check package corresponding to the
BSC version by performing the following operation (BSC6900 V900R016C00SPH602 is
used as an example):
1. Access http://support.huawei.com/.
2. After a successful login, choose Software Center > Version Software > Wireless
Product Line > SingleRAN > MBSC > BSC6900 > BSC6900 V900R016 > BSC6900
V900R016C00SPH602.
3. Download BSC6900 V900R016C00SPH602 Upgrade Risk Checking Package-EN.
2.
Issue 01 (2014-12-31)
Select the Risk check option on the upgrade tool and upload the risk check package.

Copyright Huawei
329
BSC6900 UMTS
Release Notes

V900R016C00SPH602

DTS: DTS2014052200999
Feature ID
None
10.2.2.7 Removed the FTP Text Box from the Batch

Configuration Module
Description
The FTP text box is removed from the batch configuration module.
Implementation
Under circumstances of keeping the batch configuration function in BSC Maintenance
module, in order to reduce user operation, the FTP Server IP, FTP User Name, and FTP
Password text boxes are deleted and the input operation is simplified.
The LST OMUAREA command is added to the GUI authorization item for batch
configuration. After a user-defined command group is configured with the GUI authorization
item for batch configuration, user-defined users bound to the command group have execute
permission for the LST OMUAREA command.
This feature is involved in a BSC6900 V900R016 upgrade from a version earlier than
BSC6900 V900R016C00SPH602 to BSC6900 V900R016C00SPH602.

None
Impact on NEs
None
Impact on Hardware
None

None
Impact on license: none
Impact on configuration management: none
Impact on performance management: none
Impact on fault management: none
Issue 01 (2014-12-31)

Copyright Huawei
330
BSC6900 UMTS
Release Notes

V900R016C00SPH602

None
Related Operations
None

REQ211851
Feature ID
None
10.2.2.8 Support for Feature-based Information Display in

the LST LICENSE Command Output
Description
Besides the existing file-based information display, the LST LICENSE command supports
the feature-based information display. Specifically, the detailed parameter information queried
from the license file can be displayed by feature in the command output. In this way, users can
query detailed information about features that have been requested.
Implementation
In the LST LICENSE command, the optional parameter Display Mode is added. When
Display Mode is set to Feature Mode, the detailed parameter information is displayed by
feature in the command output. The specific information includes the authorized values of the
permanent and trial license items and the expiration date of each feature.

None
Impact on NEs
None
Impact on Hardware
None

None
Impact on license management: none
Impact on configuration management: none
Issue 01 (2014-12-31)

Copyright Huawei
331
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Impact on performance management: none
Impact on fault management: none

None
Related Operations
None

CR-0000069393
Feature ID
None

None
10.3 Resolved Issues

10.3.1 Critical
None
10.3.2 Major
10.3.2.1 The measurement scopes are incomplete for
counters measuring the number of successful CS service
establishments initiated by UEs.
Trouble
Ticket
Number
DTS: DTS2014031800045
Descriptio
n
Condition: RAN16.0 introduces counters measuring the number of

access attempts and successful accesses initiated by UEs for CS services,
including AMR-WB, AMR-NB, and VP services. These counters are
measured based on the UE states and procedures UEs are performing:
idle, CELL_DCH, CELL_FACH, CELL_PCH/URA_PCH, redirectionbased CSFB, and handover-based CSFB. These counters are listed as
follows:
Issue 01 (2014-12-31)
VS.OrigCSCall.AttEstab.Idle
VS.OrigCSCall.AttEstab.CSFB.Redir
VS.OrigCSCall.AttEstab.DCH

Copyright Huawei
332
BSC6900 UMTS
Release Notes

V900R016C00SPH602
VS.OrigCSCall.AttEstab.FACH
VS.OrigCSCall.AttEstab.PCH
VS.OrigCSCall.AttEstab.CSFB.PSHO
VS.OrigCSCall.SuccEstab.Idle
VS.OrigCSCall.SuccEstab.CSFB.Redir
VS.OrigCSCall.SuccEstab.DCH
VS.OrigCSCall.SuccEstab.FACH
VS.OrigCSCall.SuccEstab.PCH
VS.OrigCSCall.SuccEstab.CSFB.PSHO
Symptom: The success rates of CS services initiated by UEs in different

states are low.
Impact: Network optimization and maintenance are affected.
Severity
Major
Root
Cause
The counters measuring the number of successful CS service

establishments initiated by UEs in different states are not measured in the
following scenarios:
Solution
A UE receives a Disconnect message from the core network (CN) right

after it initiates a CS call.
After sending a service request to the CN, the RNC receives not an
Alerting message but a Connect message from the CN.
After sending a service request to the CN, the RNC receives a

Disconnect message from the UE prior to the Alerting message from
the CN.
The counters measuring the number of successful CS service

establishments initiated by UEs in different states are now measured in
the following scenarios:
The RNC receives a Disconnect message from the CN with any of the
following causes, as shown by point B in the following figure:
Unassigned (unallocated) number
Operator determined barring
Normal call clearing
User busy
No user responding
User alerting, no answer
Call rejected
Number changed
Invalid number format (incomplete number)
Normal, unspecified
Service or option not available, unspecified
Service or option not implemented, unspecified
Recovery on timer expiry
Issue 01 (2014-12-31)

Copyright Huawei
333
BSC6900 UMTS
Release Notes

V900R016C00SPH602
For details about these causes, see 3GPP TS 24.008.
Issue 01 (2014-12-31)
After sending a service request to the CN, the RNC receives not an
Alerting message but a Connect message from the CN, as shown by
point B in the following figure.

Copyright Huawei
334
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Issue 01 (2014-12-31)
After sending a service request to the CN, the RNC receives a

Disconnect message from the UE prior to the Alerting message from
the CN, as shown by point B in the following figure.

Copyright Huawei
335
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Solution
Impact
Test Case
The values of the following counters increase after this solution takes
effect:
VS.OrigCSCall.SuccEstab.Idle
VS.OrigCSCall.SuccEstab.CSFB.Redir
VS.OrigCSCall.SuccEstab.DCH
VS.OrigCSCall.SuccEstab.FACH
VS.OrigCSCall.SuccEstab.PCH
VS.OrigCSCall.SuccEstab.CSFB.PSHO
10.3.2.2 The RNC continues to allocate services to the DPU

boards when the service subrack accommodating these
boards is being removed.
Trouble
Ticket
Number
DTS: DTS2014031408706
Descriptio
n
Condition: A service subrack is being removed, and the DPU boards in

this subrack have not been removed.
Issue 01 (2014-12-31)

Copyright Huawei
336
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Symptom: The RNC allocates services to the DPU boards in the service
subrack that is being removed.
Impact: The RRC connection setup success rate decreases.
Severity
Major
Root
Cause
The status of DPU boards is not changed when the service subrack
accommodating these DPU boards is being removed. Consequently, the
RNC continues to allocate services to these DPU boards.
Solution
The status of DPU boards is changed to faulty when the service subrack
accommodating these DPU boards is being removed. This ensures that
these DPU boards are not used to process services.
Solution
Impact
The RRC connection setup success rate increases in the preceding

scenario.
Test Case
10.3.2.3 GPS data is redundantly broadcast among SPU

subsystems.
Trouble
Ticket
Number
DTS: DTS2014030507309
Descriptio
n
Condition: A GPS receiver of the RNC type has been configured using
the MML command ADD GPS and the GPS receiver has been activated
using the MML command ACT GPS.
Symptom: After GPS data from the GCK board is broadcast to each
subsystem in the SPU board, each SPU subsystem broadcasts the data to
all other SPU subsystems.
Impact: A large number of redundant messages are broadcast between
subsystems. In an RNC configured with multiple subracks, unnecessary
overhead is caused by the underlying data transmission.
Severity
Major
Root
Cause
After receiving GPS data from the GCK board, each SPU subsystem
broadcasts the data again to all other subsystems, which is a redundant
process.
Solution
The process of each SPU subsystem broadcasting GPS data to all other
SPU subsystems has been removed.
Solution
Impact
The amount of data flow transmitted between subsystems is reduced,

decreasing the overhead caused by the underlying data transmission.
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
337
BSC6900 UMTS
Release Notes

V900R016C00SPH602
10.3.2.4 Users cannot log in to the WebLMT on the PC where

JRE of a specific version is installed.
Trouble
Ticket
Number
DTS: DTS2014050200096
Descripti
on
Condition: Users attempt to log in to the WebLMT on the PC where the

installed Java runtime environment (JRE) version (JRE 1.7.0.0 for
example) does not match the WebLMT.
Symptom: Users cannot log in to the WebLMT.
Impact: Users cannot use the WebLMT.
Severity
Major
Root
Cause
It is good practice to install the latest version (JRE 1.7.0.55) among JRE
1.7 series versions on the PC. Users are prohibited from accessing the
WebLMT on the PC where the installed JRE version does not match the
WebLMT. Besides, the WebLMT login page provides a download link for
JRE 1.6.0.26. If users install JRE 1.6.0.26 without uninstalling JRE 1.7.0.0
first, JRE 1.7.0.0 is still running on the PC.
Solution
The WebLMT login page now provides a download link for JRE 1.7.0.55.
Besides, users are allowed to access the WebLMT on the PC where the
installed JRE version does not match the WebLMT. In this case, a message
is displayed indicating a possible compatibility problem.
Solution
Impact
Some functions of the WebLMT are unavailable if the installed JRE version
does not match the WebLMT.
Test Case
10.3.2.5 The FG2a or GOUa board does not perform BFD in

compliance with RFC 5880.
Trouble
Ticket
Number
iCare: 2798661
Descripti
on
Condition: After the Bidirectional Forwarding Detection (BFD) function is

enabled on the FG2a or GOUa board that is interconnected with devices of
other vendors, transmission links become faulty.
DTS: DTS2014041708979
Symptom: After the transmission fault is corrected, there is a possibility

that ALM-21346 IP Connectivity Check Failure is repetitively reported.
Impact: ALM-21346 IP Connectivity Check Failure is repetitively reported
and then cleared, affecting ongoing services.
Severity
Major
Root
Cause
1. If the peer end does not receive or process the BFD UP packets with the
Poll (P) bit sent by the FG2a or GOUa board, the FG2a or GOUa board
does not clear the INIT packets with the Final (F) bit received from the
peer end as required by RFC 5880. As a result, the FG2a or GOUa
Issue 01 (2014-12-31)

Copyright Huawei
338
BSC6900 UMTS
Release Notes

V900R016C00SPH602
board will be in the UP state while the peer end will be in the INIT
state, and the peer end keeps sending INIT packets.
2. After receiving INIT packets in the UP state, the FG2a or GOUa board
does not treat the INIT packets as normal BFD packets as required by
RFC 5880 and BFD will expire. As a result, ALM-21346 IP
Connectivity Check Failure is reported.
Solution
1. After sending packets with the Poll (P) bit and then receiving packets
with the Final (F) bit from the peer end, the FG2a or GOUa board clears
the Poll (P) bit as required by RFC 5880.
2. After receiving INIT packets in the UP state, the FG2a or GOUa board
treats the INIT packets as normal BFD packets as required by RFC
5880 and ALM-21346 IP Connectivity Check Failure is not reported.
Solution
Impact
After this solution is enabled, the FG2a or GOUa board performs BFD in
compliance with RFC 5880 and ALM-21346 IP Connectivity Check
Failure is not repetitively reported after the transmission fault is corrected.
Test Case
10.3.2.6 The High-Risk Command List in MML Command

Reference includes some non-risky commands.
Trouble
Ticket
Number
DTS: DTS2014040903514
Descripti
on
Condition: This problem lies in MML Command Reference in the

BSC6900 product documentation or in reference documents for a certain
software version.
Symptom: The High-Risk Command List in MML Command Reference
includes some non-risky commands.
Impact: Some commands in the High-Risk Command List are non-risky
commands.
Severity
Major
Root
Cause
The High-Risk Command List includes all commands that have a dialog
box prompted before its execution. However, in addition to the dialog box,
risky commands should also interrupt services.
Solution
The High-Risk Command List now includes only risky commands.
Solution
Impact
The following commands are no longer included in High-Risk Command

List.
Issue 01 (2014-12-31)

Copyright Huawei
339
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Test Case
10.3.3 Minor
10.3.3.1 Cell user number on Cell Performance Monitoring is
still greater than 0 after the NodeB is powered off.
Trouble
Ticket
Number
DTS: DTS2014051502157
Descriptio
n
Condition: The NodeB is powered off.

Symptom: Cell user number on Cell Performance Monitoring of the
RNC LMT is still greater than 0.
Impact: None
Severity
Minor
Root
Cause
After a NodeB is powered off, the status of cells under this NodeB
becomes "Cell is setup but disabled." However, these cells can still be
selected as the target cell of DRD and UEs continue to be admitted to
these cells. As a result, cell user number on Cell Performance
Monitoring is still greater than 0.
Solution
When a DRD is triggered, the cell whose status is "Cell is setup but
disabled" will not be selected as the target cell of DRD.
Solution
Impact
None
Test Case
10.3.3.2 PS services whose resources cannot be preempted

have their resources preempted.
Trouble
Ticket
Issue 01 (2014-12-31)
DTS: DTS2014051502831

Copyright Huawei
340
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Number
Descriptio
n
Condition: Resources of PS services whose uplink is carried on HSUPA

and whose downlink is carried on HSDPA cannot be preempted. The RNC
adds a non-serving link for such PS services in a cell not supporting
HSUPA.
Symptom: Resources of these PS services are preempted and these PS
services are released.
Impact: These PS services are released.
Severity
Minor
Root
Cause
Resources of PS services whose uplink is carried on HSUPA and whose

downlink is carried on HSDPA cannot be preempted. When the RNC adds
a non-serving link for such a PS service in a cell not supporting HSUPA,
the added link does not carry this PS service. However, the RNC
considers that this PS service is carried on this added link but the RNC
cannot obtain the allocation/retention priority (ARP) of this PS service. As
a result, resources of this PS service are preempted.
Solution
The RNC now considers that the preceding PS services are not carried on
the link added in the preceding scenario.
The RESERVED_SWITCH_2_BIT26 under the RsvSwitch2 parameter
in the SET UALGORSVPARA command has been used to control this
When this solution is enabled, the RNC considers that these PS services
are not carried on the link added in the preceding scenario. When this
solution is disabled, the RNC considers that these PS services are carried
on the link added in the preceding scenario.

SET UALGORSVPARA:

SET UALGORSVPARA:
Solution
Impact
After this solution is enabled in the preceding scenario, the number of PS

RABs abnormally released due to RAB preemption (indicated by the
VS.RAB.AbnormRel.PS.Preempt counter) decreases.
Test Case
10.3.3.3 The RNC does not record PCHR logs for online users
in a certain scenario.
Trouble
Ticket
Number
DTS: DTS2013112105352
Descripti
Condition: Self-healing is triggered due to an internal error in the RNC.
Issue 01 (2014-12-31)

Copyright Huawei
341
BSC6900 UMTS
Release Notes

V900R016C00SPH602
on
Symptom: After self-healing is triggered due to an internal error in the

RNC, the RNC cannot record performance call history record (PCHR) logs
for online users.
Impact: PCHR logs are not recorded for online users.
Severity
Minor
Root
Cause
The RNC incorrectly clears the PCHR log record identifiers of online users
and consequently fails to record PCHR logs for online users.
Solution
The RNC does not clear the PCHR log record identifiers of online users in
Solution
Impact
None
Test Case
10.3.3.4 The distribution of DC-HSDPA users is inconsistent

before and after the upgrade.
Trouble
Ticket
Number
DTS: DTS2014050404753
Descriptio
n
Condition: The RNC is upgraded from V900R014C00 to V900R016C00.

Symptom: The distribution of DC-HSDPA users is inconsistent before
and after the upgrade. Before the upgrade, DC-HSDPA users are
distributed in one cell. After the upgrade, DC-HSDPA users are distributed
in both the primary and secondary cells.
Impact: The values of the VS.HSDPA.RAB.DC.AttEstab,
VS.HSDPA.RAB.DC.SuccEstab, and VS.HSDPA.UE.Mean.Cell counters
are affected.
Severity
Minor
Root
Cause
When the DRD algorithm is used for UEs to access DC-HSDPA cells, the
RNC makes a DRD decision based on the remaining DC-HSDPA user
number of the target cells. The cell with a larger remaining DC-HSDPA
user number will be selected as the target DRD cell.
No matter whether the primary and secondary cells belong to the same
subsystem, the primary carrier cell obtains the load information of the
secondary cell through load information broadcasting. Due to the delay in
load information broadcasting, the remaining DC-HSDPA user number is
different between the primary and secondary cells, which affects the DRD
decision.
NOTE
In V900R014C00, the primary and secondary cells must belong to the same
subsystem and there is no delay in reading the load information of the secondary
cell. Therefore, the remaining DC-HSDPA user number is always consistent
between the primary and secondary cells and the DRD algorithm selects only one
cell for UE access.
Issue 01 (2014-12-31)

Copyright Huawei
342
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Solution
When the primary and secondary DC-HSDPA cells belong to the same
subsystem, the primary cell directly reads the load information of the
secondary cell for the RNC to calculate the remaining DC-HSDPA user
number instead of reading the information through load information
broadcasting.
The RESERVED_SWITCH_2_BIT27 under the RsvSwitch2 parameter
in the SET UALGORSVPARA command has been used to control this
solution. By default, this solution is disabled (default value: 0) for new
networks. After an upgrade from V900R014C00 to V900R016C00, this
solution is enabled (default value: 1) by default. In other upgrade
scenarios, this solution is disabled (default value of
RESERVED_SWITCH_2_BIT27: 0)by default.

SET UALGORSVPARA:

SET UALGORSVPARA:
Solution
Impact
None
Test Case
10.3.3.5 The excessively long MML command outputs cannot

be completely displayed on the U2000.
Trouble
Ticket
Number
iCare: 2447222
Descripti
on
Condition: The length of the MML command output exceeds 64 KB.
DTS: DTS2014052101357
Symptom: The MML command output cannot be completely displayed on

the U2000.
Impact: This problem causes difficulty in executing MML commands on
the U2000.
Severity
Minor
Root
Cause
If the length of the MML command output exceeds 64 KB, the MML
command output is divided into multiple packets shorter than 64 KB
according to the OMU packet parsing mechanism. As a result, the packet
end flag may be unexpectedly inserted into the middle of the MML
command output. When this occurs, the U2000 stops receiving subsequent
packets upon detecting the packet end flag. This causes the incomplete
display of MML command outputs.
Solution
The OMU packet parsing mechanism has been optimized. When the length
of the MML command output exceeds 64 KB, the packet end flag is no
longer inserted into the middle of the MML command output.
Issue 01 (2014-12-31)

Copyright Huawei
343
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Solution
Impact
All MML command outputs are completely displayed on the U2000.
Test Case
10.3.3.6 The BSC occasionally reports ALM-20241 Board

Unavailable with Slot No. set to EMU.
Trouble
Ticket
Number
iCare: 2620289
Description
Condition: The environment monitoring unit (EMU) is properly

installed and connected to the BSC. The BSC sends the alarm severity
query and alarm query messages to the EMU every 4 seconds.
DTS: DTS2014051502683
Symptom: The BSC detects that the EMU is not installed and therefore
reports ALM-20241 Board Unavailable with Slot No. set to EMU and
Alarm Cause set to board uninstalled.
Impact: The reported alarm does not reflect the actual EMU status,
thereby affecting user experience.
Severity
Minor
Root Cause
The following function was added in BSC6900 V900R014C00

compared with BSC6900 V900R013C00: The BSC periodically sends
EMU alarm severity query messages to the EMU.
It takes a long period of time for the EMU to check the alarm severity.
Therefore, the EMU response delay occasionally occurs. As the BSC
does not receive the response from the EMU, the BSC determines that
the EMU is not installed and therefore reports ALM-20241 Board
Unavailable with Slot No. set to EMU and Alarm Cause set to board
uninstalled.
Solution
The EMU alarm severity is hardware information and needs to be

queried successfully only once. The BSC no longer periodically sends
EMU alarm severity query messages to the EMU. Instead, the BSC
stops sending the EMU alarm severity query message to the EMU once
the EMU alarm severity is queried successfully. In this manner, the
BSC no longer reports ALM-20241 Board Unavailable with Slot No.
set to EMU due to EMU response delay.
Solution
Impact
None
Test Case
Issue 01 (2014-12-31)

Copyright Huawei
344
BSC6900 UMTS
Release Notes

V900R016C00SPH602
10.3.4 Suggestion
10.3.4.1 Configuration data in the OMU buffer may be
inconsistent with that in the OMU database after the SET
UKPIALMTHD command is executed.
Trouble
Ticket
Number
DTS: DTS2014050806636
Descripti
on
Condition: The following MML command is executed to set parameters

related to the reporting of RNC KPI alarms:
SET UKPIALMTHD: DpuReliabilityAlgoSwitch=ON,
DpuSelfCureSwitch=OFF;
Symptom: After the CHK AUDIT command is executed to check the
consistency of OMU configuration data, the command output shows that
the configuration data in the OMU buffer is inconsistent with that in the
OMU database.
Impact: The configuration data consistency check fails but ongoing
services are not affected.
Severity
Suggestion
Root
Cause
To facilitate the configuration of parameters related to the reporting of

RNC KPI alarms, the attribute of some parameters in the SET
UKPIALMTHD command has been changed from independent
parameters to sub-parameters (sub-parameters are controlled by switches in
this command). However, the configurations of these sub-parameters are
not modified. As a result, these sub-parameters are incorrectly configured
when their controlling switches are set to off, which leads to OMU data
consistency check failures.
Solution
Sub-parameters in the SET UKPIALMTHD command are now correctly

configured.
Solution
Impact
None
Test Case
10.3.4.2 The functions of code resource preemption for

HSPA common channels forcibly take effect in upgrade
scenarios.
Trouble
Ticket
Number
DTS: DTS2014052000790
Descriptio
n
Condition: The RNC is upgraded from versions earlier than

BSC6900V900R016C00SPC600 to version
BSC6900V900R016C00SPC600.
Issue 01 (2014-12-31)

Copyright Huawei
345
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Symptom: After the upgrade,
The PREEMPT_ENH_HSSCCH_PREEMPT_SF_SWITCH under

the PreemptEnhSwitch parameter in the SET UQUEUEPREEMPT
command is set to on.
The PERFENH_HSUPA_CCH_PREEMPT_USER under the

PerfEnhanceSwitch parameter in the SET UNBMPARA command is
set to on.
Impact: After the upgrade, the functions of code resource preemption for
HS-SCCH (controlled by
PREEMPT_ENH_HSSCCH_PREEMPT_SF_SWITCH) and code
resource preemption for HSUPA common channels (controlled by
PERFENH_HSUPA_CCH_PREEMPT_USER) forcibly take effect. As
a result, the allocation of HSPA common channel code resources is
inconsistent before and after the upgrade.
Severity
Suggestion
Root
Cause
The upgrade rules for the preceding switches are incorrect:

PREEMPT_ENH_HSSCCH_PREEMPT_SF_SWITCH and
PERFENH_HSUPA_CCH_PREEMPT_USER are forcibly set to on
after the upgrade.
Solution
The upgrade rules have been corrected and the

PREEMPT_ENH_HSSCCH_PREEMPT_SF_SWITCH and
PERFENH_HSUPA_CCH_PREEMPT_USER inherit the values from
the source version.
Solution
Impact
None
Test Case
10.3.4.3 The number of failed preparations for LTE-to-UMTS

handovers increases due to incorrect calculation of DC
carrier group load on the RNC side.
Trouble
Ticket
Number
DTS: DTS2014050701768
Descriptio
n
Condition: The Mobility Load Balancing (MLB) feature is enabled on the

eNodeB side. On the RNC side, the incoming handover cell is a dualcarrier (DC) cell and the HSDPA_GBP_MEAS switch under the
NBMCacAlgoSwitch parameter in the ADD UCELLALGOSWITCH
command is set to off.
Symptom: The RNC sends a UMTS cell load information message to the
eNodeB, notifying the eNodeB that the target UMTS cell is not congested.
After the UE is handed over to the UMTS network, the RNC rejects the
handover request due to cell congestion.
Impact: The number of failed preparations for LTE-to-UMTS handovers
increases.
Issue 01 (2014-12-31)

Copyright Huawei
346
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Severity
Suggestion
Root
Cause
The RNC does not include the load status of the DC carrier group in the
UMTS cell load information message sent to the eNodeB. However, the
RNC considers the load status of the DC carrier group during UE
admission. When the HSDPA GBP measurement switch (controlled by
HSDPA_GBP_MEAS) is set to off, the RNC measures the load status of
the DC carrier group using the number of equivalent users in the cell. This
calculation method is different from that send to the eNodeB.
Solution
The PERFENH_DC_HSDPA_GROUP_LOAD_OPT_SWITCH has

been added to the PerfEnhanceSwitch2 parameter in the SET
UNBMPARA command to control this solution.
When this solution takes effect, the RNC considers the load status of the
DC carrier group when sending UMTS cell load information to the
eNodeB. When the HSDPA_GBP_MEAS switch is set to off, the RNC
does not measure the load status of the DC carrier group using the number
of equivalent users in the cell. Instead, the RNC uses value 0 for HSDPA
GBP measurement result. By default, this solution is disabled (default
Solution
Impact
After this solution takes effect, the number of failed preparations for LTEto-UMTS handovers decreases. When the HSDPA GBP measurement
switch is set to off, the probability that cell congestion is caused by the
DC carrier group is reduced and the cell load is prone to rise, which
reduces the RAB setup success rate.
Test Case
10.3.4.4 The measurement points of counters measuring the

RRC and RAB setups of CSFB UEs have been changed.
Trouble
Ticket
Number
DTS: DTS2014042603261
Description
Condition: A UE on the LTE network is redirected to the UMTS

network to perform CS services.
Symptom: In the preceding scenario, the RRC CONNECTION
REQUEST message contains the CSFB Indication information element
(IE), and the RNC determines that the UE is performing circuit
switched fallback (CSFB).
Impact: The measured values of the VS.RRC.AttConnEstab.CSFB,
VS.RRC.SuccConnEstab.CSFB, VS.RAB.AttEstabCS.CSFB.Redir,
and VS.RAB.SuccEstabCS.CSFB.Redir counters are less than their
actual values.
Severity
Suggestion
Root Cause
In the preceding scenario, the RNC determines that the UE is

performing CSFB only when the RRC CONNECTION REQUEST
message sent by the UE contains the CSFB Indication IE. The UE that
meets the second condition described in solution is also performing
Issue 01 (2014-12-31)

Copyright Huawei
347
BSC6900 UMTS
Release Notes

V900R016C00SPH602
CSFB, but the RNC does not identify them as CSFB UEs.
Solution
The measurement points of these four counters have been changed.

When either of the following conditions is met, the RNC determines
that a UE is performing CSFB and measures the corresponding
counters after the corresponding procedure is complete:
The RRC CONNECTION REQUEST message contains the CSFB

Indication IE. This IE is introduced in 3GPP Release 9.
All of the following conditions are met:
1. The RRC CONNECTION REQUEST message contains V860 and

meanwhile does not contain the Pre-redirection info IE. This IE is
introduced in 3GPP Release 8.
2. In the RRC CONNECTION SETUP COMPLETE message, the
value of the Support of E-UTRA FDD IE is
DoesSupportEUTRAFDD, or the value of the Support of E-UTRA
TDD IE is DoesSupportEUTRATDD. The Support of E-UTRA
FDD or Support of E-UTRA TDD IE is in the UE multimode/multi-RAT capability IE, which is in the UE radio access
capability IE.
3. When receiving the RRC CONNECTION SETUP COMPLETE
message, the RNC starts a timer, which lasts 10s. The UE initiates a
CS service before the timer expires. That is, the UE sends an
INITIAL DIRECT TRANSFER or UPLINK DIRECT TRANSFER
message to the CN, and the message type is CM Service Request
that contains "Mobile originating call establishment or packet mode
connection establishment" or "Emergency call establishment" or the
message type is Paging Response.
Solution
Impact
The measured values of these four counters increase in the preceding

scenario.
Test Case
10.3.4.5 The call drop rate is high during SRB bearer

channel reconfiguration.
Trouble
Ticket
Number
DTS: DTS2014050802878
Descripti
on
Condition: The WRFD-010652 SRB over HSDPA feature is enabled and

the DRA_BASE_COVER_LOAD_SRB_H2D_SWITCH under the
DraSwitch2 parameter in the SET UCORRMALGOSWITCH command
is set to on.
Symptom: The HSDPA call drop rate increases by more than 10%.
Impact: The call drop rate increases, which deteriorates user experience.
Severity
Issue 01 (2014-12-31)
Suggestion

Copyright Huawei
348
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Root
Cause
Solution
Solution
Impact
Issue 01 (2014-12-31)
In the following two scenarios, downlink SRBs of UEs in weak-coverage

areas are still carried on HS-DSCHs instead of being switched back to the
DCHs (SRB H2D):
A UE performs an SRB H2D channel switch without using the coverageand load-based algorithm for dynamically reconfiguring the bearer
channels for downlink SRBs. The UE then performs an SRB D2H retry
without being controlled by this algorithm. These UEs are randomly
located and therefore some UEs in weak coverage areas initiate an SRB
D2H retry, which increases the call drop rate.
When the coverage- and load-based algorithm for dynamically

reconfiguring the bearer channels for downlink SRBs is enabled, if the
cell code resources are congested, SRB are carried on HS-DSCHs in
spite of the cell coverage. In this case, a lot of SRBs in weak-coverage
areas are carried on HS-DSCHs, which increases the call drop rate.
The following measures are used to reduce the call drop rate in the
preceding scenarios when the
DRA_BASE_COVER_LOAD_SRB_H2D_SWITCH is set to on:
The RESERVED_SWITCH_11_BIT5under the RsvSwitch11 parameter

in the SET UALGORSVPARA command is used to control whether an
SRB D2H channel switch can be triggered only by using the coverageand load-based algorithm for dynamically reconfiguring the bearer
channels for downlink SRBs after an SRB H2D channel switch not
triggered by using this algorithm. When this solution is enabled, the SRB
D2H channel switch can be triggered only by using this algorithm in the
preceding scenario. When this solution is disabled, the SRB D2H
channel switch can be triggered using periodic retry or other
reconfiguration algorithms. By default, this solution is disabled (default
value: 0) for both new networks and upgrade scenarios. This solution is
recommended when the call drop rate needs to be reduced.
The RESERVED_SWITCH_7_BIT14under the RsvSwitch7 parameter

in the SET UALGORSVPARA command is used to control whether the
coverage- and load-based algorithm for dynamically reconfiguring the
bearer channels for downlink SRBs considers code resource usage when
determining the load condition. When this solution takes effect, code
resource usage is considered during load condition decision. When this
solution does not take effect, code resource usage is not considered
during load condition decision. By default, this solution is enabled
(default value: 1) for both new networks and upgrade scenarios to ensure
smooth upgrade. This solution takes effect both before and after the
upgrade. After the upgrade, a switch has been added to control whether
this solution takes effect, which does not affect smooth upgrade. This
solution is not recommended when the call drop rate needs to be
reduced.
When the coverage- and load-based algorithm for dynamically

reconfiguring the bearer channels for downlink SRBs takes effect, the call
drop rate in the following two scenarios decreases:
When the RESERVED_SWITCH_11_BIT5 under the RsvSwitch11

parameter in the SET UALGORSVPARA command is set to on, SRB
D2H channel switch can be triggered only when allowed by the current
coverage and load conditions. This reduces the call drop rate.
When the RESERVED_SWITCH_7_BIT14 under the RsvSwitch7

Copyright Huawei
349
BSC6900 UMTS
Release Notes

V900R016C00SPH602
parameter in the SET UALGORSVPARA command is set to off,

downlink SRBs will not be carried on HS-DSCHs in the case of code
resource congestion, which reduces the call drop rate in weak-coverage
areas. When the RESERVED_SWITCH_7_BIT14 is set to on,
downlink SRBs are carried on HS-DSCHs in the case of code resource
congestion, which relieves code resource congestion but increases the
call drop rate in weak coverage areas.
Test
Case
10.3.4.6 The combined cell update and relocation procedure

fails when a UE has a single CS signaling connection.
Trouble
Ticket
Number
DTS: DTS2014032603429
Descripti
on
Condition:
The UE is in the CELL_FACH state.
The UE has a single CS signaling connection and PS data services.
Symptom: The UE initiates a cell update request to a neighboring RNC cell

and a combined cell update and relocation procedure is triggered. The RNC
sends a relocation request to the CS CN but the relocation request is
rejected.
Impact: The combined cell update and relocation procedure fails and the
call drop rate increases.
Severity
Suggestion
Root
Cause
The CS CN does not support relocation for a UE that has a single CS

signaling connection and therefore rejects the relocation request. The
relocation procedure must be performed simultaneously for the CS and PS
domains, and therefore the PS relocation request is cancelled, leading to a
relocation failure.
Solution
The CU_WITH_RELOC_OPT_SWITCH under the SrnsrSwitch

parameter in the SET UCORRMALGOSWITCH command is used to
control this solution. By default, this solution is disabled (default value: 0)
When this solution takes effect, the RNC initiates a Direct Signaling
Connection Re-establishment (DSCR) procedure to allow the UE to reaccess the neighboring RNC cell and at the same time, sends the CS CN an
IU RELEASE REQUEST message, instructing the CS CN to release the
single CS signaling connection.
SET UCORRMALGOSWITCH: SrnsrSwitch=

CU_WITH_RELOC_OPT_SWITCH-1;
SET UCORRMALGOSWITCH: SrnsrSwitch=

Issue 01 (2014-12-31)

Copyright Huawei
350
BSC6900 UMTS
Release Notes

V900R016C00SPH602
CU_WITH_RELOC_OPT_SWITCH-0;
Solution
Impact
After this problem is rectified, the PS call drop rate decreases.
Test
Case
10.3.4.7 The alarm location information in ALM-21521, ALM21503, and ALM-21553 is insufficient.
Trouble
Ticket
Number
DTS: DTS2014052000137
Descripti
on
Condition: The destination signaling point (DSP) status changes from

Normal to Faulty.
Symptom: Users cannot determine which CN node or adjacent RNC is
faulty based on the alarm parameters in ALM-21521, ALM-21503, and
ALM-21553.
Impact: Users cannot quickly identify the problem cause.
Severity
Suggestion
Root
Cause
When the base station controller report ALM-21521, ALM-21503, or ALM21553, the alarm parameter specifies only the DSP information and does not
specify the information about the CN node or adjacent RNC.
Solution
The Additional Information parameter is added to ALM-21521, ALM21503, and ALM-21553. The following table lists the Additional
Information parameters for different destination signaling point (DSP)
types.
If the DSP type is Iu-CS, Iu-PS, or Iu-CS_RANAP, the value of the
additional information parameter is "UMTS CN Node: CN domain ID=y,
CN node ID=z, Cn Operator Index=h, Cn Operator Name=j".
If the DSP type is Iur, the value of the additional information parameter is
"Neighboring RNC:Neighboring RNC ID=y".
For other DSP types, the value of the additional information parameter is
"NULL".
Solution
Impact
None
Test
Case
10.3.4.8 The counter values measured during a patch

upgrade are incorrect.
Trouble
Issue 01 (2014-12-31)
iCare: 2686451
Copyright Huawei
351
BSC6900 UMTS
Release Notes

V900R016C00SPH602
Ticket
Number
Descripti
on
DTS: DTS2014051501133 and DTS2014041802705

Condition: Counters are measured when the OMU has been upgraded to the
new version but the host has not been upgraded to the new version because
the host is not reset during a patch upgrade.
Symptom: The counter values are inappropriate, for example, ultra-large
values are displayed.
Impact: The measured counter values are incorrect.
Severity
Suggestion
Root
Cause
During the patch upgrade, the OMU software version and the host software
version will be temporarily inconsistent, causing the number of counters for
the same measurement object to change after the upgrade. As a result, the
performance measurement result on the OMU is incorrect.
Solution
The following functions are now enabled during a patch upgrade:

The counters that users subscribed to before the upgrade are completely
inherited after the upgrade.
The OMU checks the performance measurement result file reported by the
host before performing the measurement. If the number of counters for a
measurement object is incorrect, the OMU does not measure performance
counters of the measurement object.
Solution
Impact
None
Test
Case
10.4 Known Issues

10.4.1 Critical
None
10.4.2 Major
None
10.4.3 Minor
None
10.4.4 Suggestion
None
Issue 01 (2014-12-31)

Copyright Huawei
352
BSC6900 UMTS
Release Notes
11 Operation and Maintenance Changes
11

Changes
11.1 MML Command Changes

See Appendix 1 of the release notes.
Appendix 1 BSC6900 UMTS V900R016C00SPC650 MML Command Changes.xls
11.2 Parameter Changes

For parameter changes, see Appendix 2 of the release notes:
Appendix 2 BSC6900 UMTS V900R016C00SPC650 MO and Parameter Changes.xls
For reserved parameter changes, see the following appendix:
BSC6900 UMTS V900R016C00SPC650 Used Reserved Parameter List.xls
11.3 Alarm Changes

Appendix 3 BSC6900 UMTS V900R016C00SPC650 Alarm Changes.xls
11.4 Event Changes

Appendix 4 BSC6900 UMTS V900R016C00SPC650 Event Changes.xls
Issue 01 (2014-12-31)

Copyright Huawei
353
BSC6900 UMTS
Release Notes
11 Operation and Maintenance Changes
11.5 Counter Changes

For counter changes, see Appendix 5 of the release notes.
Appendix 5 BSC6900 UMTS V900R016C00SPC650 Performance Counter Changes.xls
For reserved counter changes, see the following appendix:
BSC6900 UMTS V900R016C00SPC650 Used Reserved Counter List.xls
11.6 License Changes

Appendix 6 BSC6900 UMTS V900R016C00SPC650 License Changes.xls
11.7 Other Changes

Appendix 7 BSC6900 UMTS V900R016C00SPC650 EBC Changes.xls
Issue 01 (2014-12-31)

Copyright Huawei
354
BSC6900 UMTS
Release Notes
A Obtaining Documentation
Obtaining Documentation
You can view or download related documentation from http://support.huawei.com.

You must apply for permission to obtain documentation from the website. If you are using
http://support.huawei.com for the first time, first register with the website.
Registering with the Website

Step 1 Access http://support.huawei.com.
Step 2 Click Register, and follow the instructions to complete the registration process.
----End
If your registration is successful, you will be informed of your user name and password within two or
three working days.
Viewing or Downloading Documentation

To view or download documentation from http://support.huawei.com, perform the following
steps:
Step 1 Access http://support.huawei.com.
Step 2 Click Log In. In the dialog box that is displayed, enter the user name, password, and
verification code and click Login.
Step 3 On the Product Support tab page, enter BSC6900 WCDMA in the Enter Product Name text
box and then click Find. On the displayed page, click a search result.
To obtain feature parameter description (FPD), you need to enter RAN solution.
Step 4 On the Product Documentation tab page, select a version from the Version Selection dropdown list box.
Step 5 Click a link in the Title column to view the document or
to download the document.
----End
Issue 01 (2014-12-31)

Copyright Huawei
355
BSC6900 UMTS
Release Notes
A Obtaining Documentation
Issue 01 (2014-12-31)
If the file name extension of a documentation package is .hdx, use HedEx Lite to view the
documents. You can obtain the software from Huawei customer service engineers.

Copyright Huawei
356
BSC6900 UMTS
Release Notes
B Acronyms and Abbreviations
Acronyms and Abbreviations
A
AAL2
ATM Adaptation Layer type 2
ATM
Asynchronous Transfer Mode
B
BER
Bit Error Rate
BHCA
Busy Hour Call Attempt
BOOTP
Bootstrap Protocol
BIOS
Basic Input Output System
C
CBC
Cell Broadcast Center
CCP
Communication Control Port
CDT
Call Data Tracing
CoRRM
Connection Orient Radio Resource Management
CPLD
Complex Programmable Logical Device
CRC
Concentrate Routing Board
F
FE
Fast Ethernet
FP
Frame Protocol
FR
Frame Relay
Issue 01 (2014-12-31)

Copyright Huawei
357
BSC6900 UMTS
Release Notes
G
GCC
Group Call Control
GE
Gigabit Ethernet
GPRS
General Packet Radio Service
GPS
Global Positioning System
GSM
Global System for Mobile Communications
GTP-U
GPRS Tunneling Protocol for User Plane
H
HARQ
Hybrid Automatic Repeat Request
HDLC
High level Data Link Control
HSDPA
High Speed Downlink Packet Access
HS-DSCH
High Speed Downlink Shared Channel
HSUPA
High Speed Uplink Packet Access
I
IDC
Instance Distribution Control
IMA
Inverse Multiplexing on ATM
IP
Internet Protocol
IPoA
Internet Protocols over ATM
L
LAN
Local Area Network
LMT
Local Maintenance Terminal
LRM
Local Resource Management
M
MAC
Medium Access Control
MBMS
Multimedia Broadcast and Multicast Service
MIMO
Multi Input Multi Output
MOCN
Multiple Operator Core Network
MSIC
MS Instance Control
MSIP
MS Instance Process
Issue 01 (2014-12-31)

Copyright Huawei
358
BSC6900 UMTS
Release Notes
MSP
Multiplex Section Protection
MTP
Message Transfer Part
MTSS
Mapping and Transfer between SCCP entity and

Service entity
P
PARC
Platform of Advanced Radio Controller
PCU
Packet Control Unit
PDCP
Packet Data Convergence Protocol
PRR
Packet domain Radio Resource control
PGC
Paging Control
PPP
Point-to-Point Protocol
PVC
Permanent Virtual Channel
R
RDLC
Radio Link Control
RESC
Radio Embed-resources Set Control
RLC
RLC instance
RLCC
RLC resource Control
RRM
Radio Resource Management
Q
QoS
Quality of Service
S
SAAL
Signaling ATM Adaptation Layer
SABP
Service Area Broadcast Protocol
SCCP
Signaling Connection Control Part
SCP
Service Control Plane
SCTP
Stream Control Transmission Protocol
SIGPC
Signal Port ts resource Control
SPCC
Semi-Permanent Connection Control
SRAP
Service Resource Access Plane
SRCP
Service Resource Control Plane
Issue 01 (2014-12-31)

Copyright Huawei
359
BSC6900 UMTS
Release Notes
SRP
Service Resource Plane
T
TDM
Time Division Multiplex
TDMC
TDM resource Control
TRX
Transceiver
U
UE
User Equipment
UMTS
Universal Mobile Telecommunications System
UNI
User-Network Interface
UP
User Plane
V
VLAN
Virtual Local Area Network
VoIP
Voice over IP
W
WCDMA
Issue 01 (2014-12-31)
Wideband Code Division Multiple Access

Copyright Huawei
360

c03 - bsc6900 Umts v900r016c00spc650 Release Notes

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

c03 - bsc6900 Umts v900r016c00spc650 Release Notes

Enviado por

Direitos autorais:

Formatos disponíveis

BSC6900 UMTS

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

About This Document

About This Document

Liu Yong, Liu Qi, Xu

Huawei Proprietary and Confidential

About This Document

This is the first commercial release.

The feature summary includes information about capacity and performance,

Table 1 Section description

Describes the possible impact of a specific product version on system

Describes any hardware addition and modification in a specific product

Provides a summary of all feature changes in a specific product

Provides a summary of all resolved issues in a specific product version.

Describes the changes to configuration management, performance

Huawei Proprietary and Confidential

About This Document

management, fault management, license management, and their

Describes the changes to related documentation of a specific product

Figure 1 Relationships among sections in Change Summary shows the relationships

Feature Changes: details feature changes.

Resolved Issues: details resolved issues by severity.

Known Issues: details known issues in this product version by severity.

Operation and Maintenance Changes

Huawei Proprietary and Confidential

3 Changes from V900R016C00SPC630 to V900R016C00SPC650........10

Huawei Proprietary and Confidential

3.2.2.4 Exporting Configuration Information in the SET LICENSE Command...............................................................18

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

4 Changes from V900R016C00SPH621 to V900R016C00SPC630......104

Huawei Proprietary and Confidential

4.2 Feature Changes.........................................................................................................................................................107

Huawei Proprietary and Confidential

4.3.4.7 A moving UE in the connected state cannot update the RA or LA......................................................................145

5 Changes from V900R016C00SPC620 to V900R016C00SPH621......152

6 Changes from V900R016C00SPH609 to V900R016C00SPC620......158

Huawei Proprietary and Confidential

6.1.1 Capacity and Performance.......................................................................................................................................159

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

6.3.4.24 A UE in the CELL_FACH state fails to initiate CS services..............................................................................254

7 Changes from V900R016C00SPH608 to V900R016C00SPH609......267

Huawei Proprietary and Confidential

8 Changes from V900R016C00SPH605 to V900R016C00SPH608......273

9 Changes from V900R016C00SPH602 to V900R016C00SPH605......281

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

10 Changes from V900R016C00SPC600 to V900R016C00SPH602.....314

Huawei Proprietary and Confidential

10.3 Resolved Issues........................................................................................................................................................329

11 Operation and Maintenance Changes........................................350

Huawei Proprietary and Confidential

11.7 Other Changes..........................................................................................................................................................351

Huawei Proprietary and Confidential

1.1 Product Version

1.2 Software Versions