Base Station Cabinets and Subracks (Including The BBU Subrack) Configuration (SingleRAN - 04)

SingleRAN
Base Station Controller Equipment

Reliability Feature Parameter
Description
Issue 01
Date 2014-04-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2015. 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-04-30) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
SingleRAN
Base Station Controller Equipment Reliability Feature
Parameter Description Contents
Contents
1 About This Document..................................................................................................................1

1.1 Scope..............................................................................................................................................................................1
1.2 Intended Audience..........................................................................................................................................................1
1.3 Change History...............................................................................................................................................................1
1.4 Differences Between Base Station Types.......................................................................................................................2
2 Overview.........................................................................................................................................3
2.1 Introduction....................................................................................................................................................................3
2.2 Benefits...........................................................................................................................................................................3
2.3 Architecture....................................................................................................................................................................3
3 Reliability Specifications.............................................................................................................8
4 Planned Service Interruption......................................................................................................9
4.1 Overview........................................................................................................................................................................9
4.2 BSC/RNC Software Management..................................................................................................................................9
5 Redundancy Design....................................................................................................................12
5.1 Overview......................................................................................................................................................................12
5.2 RNC Redundancy Design.............................................................................................................................................13
5.2.1 Resource Management Plane.....................................................................................................................................13
5.2.2 Control plane.............................................................................................................................................................13
5.2.3 User Plane..................................................................................................................................................................15
5.2.4 Transport Plane..........................................................................................................................................................15
5.3 BSC Redundancy Design.............................................................................................................................................16
5.3.1 Resource Management Plane.....................................................................................................................................17
5.3.2 Control Plane.............................................................................................................................................................17
5.3.3 User Plane..................................................................................................................................................................19
5.3.4 Transport Plane..........................................................................................................................................................20
5.4 New Node.....................................................................................................................................................................21
6 Network Redundancy.................................................................................................................23
6.1 RNC in Pool..................................................................................................................................................................23
6.1.1 Overview...................................................................................................................................................................23
6.1.2 Benefits......................................................................................................................................................................24
Issue 01 (2014-04-30) Huawei Proprietary and Confidential ii

SingleRAN
6.2 RNC Node Redundancy...............................................................................................................................................25

6.3 BSC Node Redundancy................................................................................................................................................27
6.3.1 Overview...................................................................................................................................................................27
6.3.2 Benefits......................................................................................................................................................................28
6.4 MSC Pool.....................................................................................................................................................................29
6.5 SGSN Pool....................................................................................................................................................................30
6.6 TC Pool.........................................................................................................................................................................30
7 Fault Management.......................................................................................................................31
7.1 Fault Management Architecture...................................................................................................................................31
7.1.1 NEL...........................................................................................................................................................................31
7.1.2 EML...........................................................................................................................................................................32
7.1.3 NML..........................................................................................................................................................................33
7.2 NE Fault Management..................................................................................................................................................33
8 Flow Control.................................................................................................................................37
8.1 RNC Flow Control........................................................................................................................................................37
8.1.1 Overview...................................................................................................................................................................37
8.1.2 Panorama...................................................................................................................................................................37
8.1.3 E2E Flow Control......................................................................................................................................................39
8.2 BSC Flow Control........................................................................................................................................................40
8.2.1 Overview...................................................................................................................................................................40
8.2.2 Panorama...................................................................................................................................................................40
9 Operation and Maintenance Reliability.................................................................................42

9.1 Overview......................................................................................................................................................................42
9.2 Technical Description...................................................................................................................................................42
10 Hardware Reliability................................................................................................................46
10.1 BSC/RNC Board Redundancy....................................................................................................................................47
10.1.1 BSC6910 Board Redundancy..................................................................................................................................47
10.1.2 BSC6900 Board Redundancy..................................................................................................................................48
11 Related Features.........................................................................................................................50
12 Network Impact.........................................................................................................................51
13 Engineering Guidelines...........................................................................................................52
13.1 When to Use Operation & Maintenance System One-Key Recovery........................................................................52
13.2 Deployment................................................................................................................................................................52
13.2.1 Process.....................................................................................................................................................................52
13.2.2 Requirements...........................................................................................................................................................52
13.2.3 Activation................................................................................................................................................................52
13.2.4 Activation Observation............................................................................................................................................53
13.2.5 Deactivation.............................................................................................................................................................53
13.3 Performance Monitoring.............................................................................................................................................53
Issue 01 (2014-04-30) Huawei Proprietary and Confidential iii

SingleRAN
13.4 Troubleshooting..........................................................................................................................................................53
14 Parameters...................................................................................................................................54
15 Counters......................................................................................................................................55
16 Glossary.......................................................................................................................................58
17 Reference Documents...............................................................................................................59
Issue 01 (2014-04-30) Huawei Proprietary and Confidential iv

SingleRAN
Parameter Description 1 About This Document
1 About This Document
1.1 Scope
This document describes the Base Station Controller Equipment Reliability feature, including
its technical principles, related features, network impact, and engineering guidelines.
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the features described herein

l Work with Huawei products
1.3 Change History

This section provides information about the changes in different document versions. There are
two types of changes, which are defined as follows:
l Feature change:
Changes in features of a specific product version
l Editorial change:
Changes in wording or addition of information that was not described in the earlier version
SRAN9.0 01 (2014-04-30)
This issue does not include any changes.
SRAN9.0 Draft A (2014-01-20)

This is a new document for SRAN9.0.
Issue 01 (2014-04-30) Huawei Proprietary and Confidential 1

SingleRAN
Parameter Description 1 About This Document
1.4 Differences Between Base Station Types

The features described in this document apply only to macro base stations.

SingleRAN
Parameter Description 2 Overview
2 Overview
2.1 Introduction
Reliability designs enable the controller to continue providing services even when it experiences
a fault, thereby maintaining high system reliability. Objectives of reliability include:
l Decreasing the number of accidents

l Minimizing the scope of fault influence
l Shortening the duration of service interruption
Controller reliability designs include system availability, planned service interruption,

redundancy design, network redundancy, fault management, flow control, operation and
maintenance reliability, and hardware reliability.
2.2 Benefits
Reliability designs, which include redundancy design and hardware reliability design, eliminate
or reduce the impact of equipment faults on services, thereby improving system reliability.
2.3 Architecture
Table 1 lists the controller equipment reliability-related features and functions that are supported
by GSM and UMTS.

SingleRAN
Table 2-1 Controller equipment reliability-related features and functions that are supported by
GSM and UMTS
Reliability Feature/ Radio Feature ID/ Remarks

Category Function Access Feature Name
Technology
Planned BSC/RNC GSM and MRFD-210401 For details about

service Software UMTS BSC/RNC engineering
interruption Managemen Software guidelines, see
t Management Operation and
Maintenance Feature
Parameter
Description.
Redundancy RNC UMTS None For details, see 5.2

design Redundancy RNC Redundancy
Design.
BSC GSM None For details, see 5.3

Redundancy BSC Redundancy
Design.
BSC/RNC GSM and MRFD-210104 For details about

Resource UMTS BSC/RNC engineering
Sharing Resource Sharing guidelines, see
Controller Resource
Sharing Feature
Parameter
Description in
WCDMA RAN
documents.
Network RNC in Pool UMTS l WRFD-150211 For details about

redundancy RNC in Pool engineering
Load Sharing guidelines, see RNC in
l WRFD-150212 Pool Feature
RNC in Pool Parameter
Node Description in
Redundancy WCDMA RAN
documents.
l WRFD-150240
RNC in Pool
Multiple
Logical RNCs

SingleRAN

Technology
RNC Node UMTS WRFD-040202 For details about

Redundancy RNC Node engineering
Redundancy guidelines, see RNC
Node Redundancy
Feature Parameter
Description in
WCDMA RAN
documents.
BSC Node GSM GBFD-113725 For details about

Redundancy BSC Node engineering
Redundancy guidelines, see BSC
Node Redundancy
Feature Parameter
Description in GSM
BSS documents.
MSC Pool GSM GBFD-117401 For details about

MSC Pool engineering
guidelines, see MSC
Pool Feature
Parameter
Description in GSM
BSS documents.
SGSN Pool GSM GBFD-119701 For details about

SGSN Pool engineering
guidelines, see SGSN
Pool Feature
Parameter
Description in GSM
BSS documents.
TC Pool GSM GBFD-113726 TC For details about

Pool engineering
guidelines, see TC
Pool Feature
Parameter
Description in GSM
BSS documents.

SingleRAN

Technology
Fault Fault GSM and MRFD-210304 For details about

management Managemen UMTS Fault Management engineering
t guidelines, see Fault
Management Feature
Parameter
Description in
SingleRAN
documents.
Flow control RNC Flow UMTS WRFD-040100 For details about

Control Flow Control engineering
guidelines, see Flow
Control Feature
Parameter
Description in
WCDMA RAN
documents.
BSC Flow GSM l GBFD-111705 For details about

Control GSM Flow engineering
Control guidelines, see Flow
l GBFD-119117 Control Feature
Flow Control on Parameter
Gb Interface Description in GSM
BSS documents.
l GBFD-119116
Packet Uplink
Flow Control
l GBFD-511003
Call-Based
Flow Control
l GBFD-115002
Flow Control
Based on Cell
Priority
l GBFD-115003
Flow Control
Based on User
Priority
Operation Operation GSM and GBFD-111214 For details, see 9

and and UMTS Operation & Operation and
maintenance Maintenanc Maintenance Maintenance
reliability e System System One-Key Reliability.
One-Key Recovery
Recovery

SingleRAN

Technology
Hardware BSC/RNC GSM and None For details, see 10

reliability Board UMTS Hardware
Redundancy Reliability.

SingleRAN
Parameter Description 3 Reliability Specifications
3 Reliability Specifications
Table 3-1 Reliability specifications
Index Value
System availability > 99.999%
Mean time between failures (MTBF) ≥ 525000 hours
Mean time to repair (MTTR) ≤ 1 hour

SingleRAN
Parameter Description 4 Planned Service Interruption
4 Planned Service Interruption
4.1 Overview
Planned service interruption aims to reduce the duration of service interruption caused by
upgrades, minimize the impact of planned maintenance on live networks, and improve
equipment availability. Planned service interruption supports hot patches.
4.2 BSC/RNC Software Management

Overview
This section describes the MRFD-210401 BSC/RNC Software Management feature. For details,
see Operation and Maintenance Feature Parameter Description.
Huawei controllers support the uniform software management of GSM base station system
(GBSS) and radio access network (RAN), facilitating the remote management of the controller
software and improving the efficiency of software upgrades and downloads.
With this feature, users can implement the following operations on the U2000.
l Querying the software version and its status

l Uploading, downloading, and activating the program files, patch files, and license files
l Using the OMU of the controller as the FTP server and transmitting files such as program
files and patch files between the FTP server and FTP client
l Using the controller as the transmission medium to transmit files between the U2000 and
the MBTS
In addition, users can manage the programs, patches, licenses, and logs using the Web LMT.
The controller supports the software integrity check. The controller performs the software
integrity check after software loading and before software operation, and then completes digital
signature verification.
The BSC/RNC is upgraded remotely by the dedicated upgrade tool, which consists of the upgrade
client and the upgrade server. Figure 4-1 shows the BSC/RNC remote upgrade process.

SingleRAN
Figure 4-1 BSC/RNC remote upgrade process
The remote upgrade process is as follows:
Step 1 Upload the upgrade server program and the version files required for the upgrade (such as a
major release or patch version) to a specified directory of the active OMU. In addition,
synchronize the upgrade directory of the standby OMU with the specified directory of the active
OMU.
Step 2 Conduct the pre-upgrade health check, backs up data and files, and upgrades the program and
data files in the standby workspace of the active OMU and standby OMU.
Step 3 Load the host program, BootROM, operating system (OS), and data files in the standby
workspace of the active OMU onto the standby workspaces of the FAM boards so that the
standby workspaces of the FAM boards are synchronized with that of the OMU.
Step 4 After the synchronization is successful, switch over the active and standby workspaces of the
active OMU so that the active OMU is upgraded to the latest version.
Step 5 Switch over the active and standby workspaces of the FAM boards. When the platform host
program, BootROM, OS or data files are upgraded, the FAM boards are reset. When a cold patch
is loaded to a type of FAM boards, only this type of FAM board is reset and the boards
automatically load the program and data files from their flash memories to complete the upgrade.
Hot patches adopt one-click installation.
Step 6 After the service verification is successful, switch over the active and standby workspaces of
the standby OMU so that the standby OMU is upgraded to the latest version. After the workspace
switchover is complete for the standby OMU, the standby OMU automatically synchronizes its
data with the active OMU.
----End
Key Specifications
Table 4-1 lists key specifications for BSC/RNC software management.

SingleRAN
Table 4-1 Key specifications for BSC/RNC software management
Index Version Implementation
Service interruption duration caused by an Service interruption duration ≤ 3 min

upgrade for a major release
Service interruption duration caused by a No service interruption for a hot patch

patch upgrade upgrade
Service interruption duration for a cold patch
upgrade ≤ 3 min
Reloading time ≤ 7 min
Time from power-on to management ≤ 10 min

recovery
Time from power-on to first NodeB recovery ≤ 10 min
Time from power-on to the recovery of all ≤ 12 min

sites

SingleRAN
Parameter Description 5 Redundancy Design
5 Redundancy Design
5.1 Overview
This section describes the MRFD-210101 System Redundancy feature and the GBFD-111701
Board Switchover feature. System redundancy provides reliability designs that improve system
reliability. These designs include active/standby switchovers and load sharing.
Huawei base station controllers adopt reliability designs, such as load sharing and active/standby
switchovers, to ensure the reliable operation of the system.
l Active/standby switchovers
In active/standby mode, the active board processes services while the standby board acts
as a backup for the active one. When the active board is faulty or needs to be replaced,
services on the active board are switched over to the standby board to ensure normal service
operations.
There are two types of switchovers:
– Automatic switchover: automatically triggered by the system if the active board is
faulty.
– Manual switchover: performed by maintenance personnel on the LMT. Maintenance
personnel use the immediate switchover command to switch over the active and standby
boards.
A successful active/standby switchover requires the following:
– The standby board works normally.
– No major or critical alarm is reported on the standby board.
When the standby board is switched over to the active state, the previously active board is
reset automatically. If this board restarts normally, it is switched over to the standby state.
l Load sharing
In resource pool mode, load sharing is performed among processing units in the pool. When
one or multiple processing units are faulty, new service requests are allocated to the normal
processing units in the resource pool.
l Other reliability designs

SingleRAN
Other reliability designs include the redundancy configuration of power and fan units. In
addition, software versions and important data configuration files are backed up so that the
system works normally even if an exception occurs in the software versions and files.
5.2 RNC Redundancy Design
5.2.1 Resource Management Plane

The BSC6900 main processing unit (MPU) subsystems can be configured on multiple pairs of
SPU boards working in active/standby mode. The MPU subsystems manage transmission
resources and enable control- and user-plane load sharing.
The BSC6910 resource management plane consists of the central layer and local layer.
l The central layer manages global resources, including the control plane, user plane, and
transport plane resources, and troubleshoots system faults.
A pair of Resource Management Processing (RMP) boards perform the central layer
functions.
l The local layer manages board-level resources.
A UCUP board performs the local layer functions.
RMP boards have the following characteristics:
l The CPU usage does not increase noticeably with the increase in the Busy Hour Call
Attempt (BHCA) or throughput. A sudden increase in the CPU usage is allowed within a
short period of time.
l A temporary fault in an RMP board does not interrupt ongoing services. This is because
only global resource scheduling is interrupted if an RMP board is faulty.
5.2.2 Control plane

For the BSC6900, the SPU boards, which work in active/standby mode, process control plane
data.
For the BSC6910, the UCUP boards process control plane data. Processes on the control plane
work in active/standby mode. Every active CP process on a UCUP board has a backup on another
UCUP board, as shown in Figure 5-1.

SingleRAN
Figure 5-1 Control-plane redundancy design for the BSC6910
NOTE
CP stands for the control plane and UP stands for the user plane.
The redundancy design is similar for the BSC6900 and BSC6910 control planes. The differences
are as follows:
l A pair of BSC6900 active and standby control plane boards must be installed in adjacent
slots.
l The BSC6910 control plane uses the process backup mechanism. All active CP processes
on a UCUP board have backups evenly distributed on the two adjacent UCUP boards.
When the BSC6900 or BSC6910 is running, the cell status, NodeB status, and online UE
information on the active subsystem are sent to the standby subsystem through the backup
channel. The standby subsystem then backs up the data. If the active subsystem is faulty, the
standby subsystem takes over services on the active subsystem to avoid service interruptions.
In addition to the redundancy design, the BSC6910 control plane also supports process
preemption. If a pair of active and standby CP processes of the BSC6910 are both faulty for a
certain period of time (less than 5 minutes), the BSC6910 preempts another standby CP process
to start the active CP process, thereby restoring services promptly.

SingleRAN
5.2.3 User Plane

For the BSC6900, the digital signal processors (DSPs) in DPU boards process user plane data.
The DSPs work in resource pool mode.
For the BSC6910, the UCUP board processes user plane data. The user plane resources work in
resource pool mode, as shown in Figure 5-2.
Figure 5-2 User-plane redundancy design for the BSC6910
If a user plane subsystem is faulty, the common channels for the cells carried on the subsystem
are reestablished, and services are interrupted for less than 5 seconds and then restored. During
the service interruption, CS services are released, and PS services are interrupted and then
reconnected. The user-plane processing capability decreases, but the other functional user plane
subsystems still work in resource pool mode.
The redundancy design is the same for the BSC6900 and BSC6910 user planes. Neither supports
user-plane service backup.
5.2.4 Transport Plane

The redundancy design is the same for the BSC6900 and BSC6910 transport planes. They both
support board redundancy, port backup/load sharing, and resource pool mode.
A transport interface board supports the following:
l 1+1 active/standby redundancy

When detecting that an interface board is faulty, the system performs an active/standby
switchover to reestablish the transmission links for the ongoing services on the standby
board. When detecting that the active channel is unavailable, the system performs an active/
standby switchover to enable the ongoing services to be transmitted through the standby
channel.
l Port backup or load sharing
l Resource pool

SingleRAN
In conclusion, the resource management plane, control plane, user plane, and transport plane all
support the redundancy design. Therefore, the BSC6900 and BSC6910 do not experience a single
point of failure.
Table 5-1 describes the reliability indexes for transmission interface boards in different
scenarios.
Table 5-1 Reliability indexes for transmission interface boards in different scenarios
Scenario Availability Average Quantitative

Downtime Reliability
(Minute/Year) Analysis
1+1 active/standby 0.999999796 0.11 Low task reliability

redundancy and low basic
reliability under the
same traffic volume
1+1 active/standby 0.999999918 0.04 High task reliability

redundancy plus and low basic
resource pool reliability under the
same traffic volume
Independent board 0.999999183 0.43 Low task reliability

plus resource pool and high basic
same traffic volume
N+1 resource pool 0.999999836 0.09 High task reliability

and high basic
same traffic volume
Table 5-2 Key specifications of transmission redundancy
Switchover for interface boards The impact persists within 3s for ongoing services.
Switchover for other boards New services can be admitted in 15s.
NOTE
The delay caused by protocol negotiation with the peer equipment is not considered in the preceding
indexes. For example, if Link Aggregation Control Protocol (LACP) is enabled, the impact of a switchover
between interface boards persists within 9s for ongoing services.
5.3 BSC Redundancy Design

SingleRAN
5.3.1 Resource Management Plane

The BSC6900 MPU subsystems can be configured on multiple pairs of XPU boards working in
active/standby mode. The MPU subsystems manage transmission resources and enable control-
and user-plane load sharing.
The BSC6910 resource management plane consists of the central layer and local layer.
l The central layer manages global resources, including the control plane, user plane, and
transport plane resources, and troubleshoots system faults.
The BSC6900 is configured with a pair of EGPUa boards whose logical type is resource
management processing (RMP). The EGPUa boards are responsible for managing global
resources and troubleshooting system faults.
l The local layer manages board-level resources.
NOTE
EGPUa boards whose logical type is GCUP or GMCP (referred to as GCUP or GMCP boards) manage
board-level resources. GCUP or GMCP is short for GSM BSC Control plane and User plane Processing.
EGPUa boards whose logical type is RMP (referred to as RMP boards) have the following
characteristics:
l The CPU usage does not increase noticeably with the increase in the Busy Hour Call
Attempt (BHCA) or throughput. A sudden increase in the CPU usage is allowed within a
short period of time.
l A temporary fault in an RMP board does not interrupt ongoing services. This is because
only global resource scheduling is interrupted if an RMP board is faulty.
5.3.2 Control Plane

For the BSC6900, the XPU boards, which work in active/standby mode, process control plane
data.
For the BSC6910, the EGPUa boards whose logical type is GCUP or GMCP process control
plane data. Processes on the control plane work in active/standby mode. Every active CP process
on an EGPUa board whose logical type is GCUP or GMCP has a backup on another EGPUa
board whose logical type is GCUP or GMCP, as shown in Figure 5-3.

SingleRAN
Figure 5-3 Control-plane redundancy design for the BSC6910
NOTE
The redundancy design is similar for the BSC6900 and BSC6910 control planes. The differences
are as follows:
l A pair of BSC6900 active and standby control plane boards must be installed in adjacent
slots.
l The BSC6910 control plane uses the process backup mechanism. All active CP processes
on an EGPUa board whose logical type is GCUP or GMCP have backups evenly distributed
on the two adjacent EGPUa boards whose logical type is GCUP or GMCP.
When the BSC6900 or BSC6910 is running, the cell status, BTS status, and online MS
information on the active subsystem are sent to the standby subsystem through the backup
channel. The standby subsystem then backs up the data. If the active subsystem is faulty, the
standby subsystem takes over services on the active subsystem to avoid service interruptions.
In addition to the redundancy design, the BSC6910 control plane also supports process
preemption. If a pair of active and standby CP processes of the BSC6910 are both faulty for a

SingleRAN
certain period of time (less than 5 minutes), the BSC6910 preempts another standby CP process
to start the active CP process, thereby restoring services promptly.
5.3.3 User Plane

For the BSC6900, the digital signal processors (DSPs) in DPU boards process user plane data.
The DSPs work in resource pool mode.
For the BSC6910, the EGPUa boards whose logical type is GCUP or GMCP process user plane
data. The user plane resources work in resource pool mode, as shown in Figure 5-4.
Figure 5-4 User-plane redundancy design for the BSC6910
NOTE
If a user plane subsystem is faulty, CS services are released, and PS services are interrupted and
then reconnected. The user-plane processing capability decreases, but the other functional user
plane subsystems still work in resource pool mode.
The redundancy design is the same for the BSC6900 and BSC6910 user planes. Neither supports
user-plane service backup.

SingleRAN
5.3.4 Transport Plane

The redundancy design is the same for the BSC6900 and BSC6910 transport planes. They both
support board redundancy, port backup/load sharing, and resource pool mode.
A transport interface board supports the following:
l 1+1 active/standby redundancy

When detecting that an interface board is faulty, the system performs an active/standby
switchover to reestablish the transmission links for the ongoing services on the standby
board. When detecting that the active channel is unavailable, the system performs an active/
standby switchover to enable the ongoing services to be transmitted through the standby
channel.
l Port backup or load sharing
l Resource pool
Table 5-3 describes the reliability indexes for transmission interface boards in different
scenarios.
Table 5-3 Reliability indexes for transmission interface boards in different scenarios
Scenario Availability Average Quantitative

Downtime Reliability
(Minute/Year) Analysis
1+1 active/standby 0.999999796 0.11 Low task

redundancy reliability and low
basic reliability
under the same
traffic volume
1+1 active/standby 0.999999918 0.04 High task

redundancy plus resource reliability and low
pool basic reliability
under the same
traffic volume
Independent board plus 0.999999183 0.43 Low task

resource pool reliability and high
basic reliability
under the same
traffic volume
N+1 resource pool 0.999999836 0.09 High task

reliability and high
basic reliability
under the same
traffic volume

SingleRAN
Table 5-4 Key specifications of transmission redundancy
Switchover for interface boards The impact persists within 3s for ongoing services.
Switchover for other boards New services can be admitted in 15s.
NOTE
The delay caused by protocol negotiation with the peer equipment is not considered in the preceding
indexes. For example, if Link Aggregation Control Protocol (LACP) is enabled, the impact of a switchover
between interface boards persists within 9s for ongoing services.
In conclusion, the resource management plane, control plane, user plane, and transport plane all
support the redundancy design. Therefore, the BSC6900 and BSC6910 do not experience a single
point of failure.
5.4 New Node

This section describes the MRFD-210104 BSC/RNC Resource Sharing feature. For details about
the engineering guidelines, see Controller Resource Sharing Feature Parameter Description.
l BSC6900 control plane resource sharing
Control plane resource sharing is used to share the CPU usage and memory. When the CPU
usage of a certain control-plane processing unit is too high or the memory of a certain control-
plane processing unit is insufficient, new calls are forwarded to other control-plane processing
units with light load.
l BSC6900 user plane resource sharing
The RNC implements dynamic resource sharing based on the resource pool and load balancing.
If a certain user-plane processing unit is overloaded, new services are forwarded to other user-
plane processing units with light load.
For details on load sharing, see Flow Control Feature Parameter Description.
l BSC6910 user plane and control plane dynamic sharing
The BSC6910 dynamically adjusts the numbers of multi-core DSPs allocated to the control plane
and user plane based on service requirements. These adjustments improve hardware utilization
by balancing the control-plane and user-plane processing capabilities.
The BSC6910 introduces a new service processing board: GPU. The GPU board can
simultaneously process user-plane and control-plane data. The BSC6910 monitors the user-
plane and control-plane resource usage and adjusts resources (multi-core DSPs) for each plane
proportionately. For details, see the RNC User Plane and Control Plane Resource Sharing
Parameter Description.
l Automatic base station and cell allocation in the BSC6910
The BSC6910 automatically allocates a new base station or cell to an EGPUa board. When
configuring a base station or cell on the BSC6910, telecom operators do not need to specify the
subrack, slot, or subsystem. In addition, the BSC6910 monitors the distribution of base stations

SingleRAN
and cells on the EGPUa boards. When EGPUa boards experience a load imbalance because there
are hotspot base stations or cells, the BSC6910 adjusts the distribution of base stations or cells
on the EGPUa boards to achieve load balancing.
Dynamic reallocation of cells can be performed during peak hours, whereas dynamic reallocation
of base stations must be performed during off-peak hours. During cell reallocation, UEs in the
CELL_DCH state in the cell do not drop from the network. During base station reallocation,
services carried by the base station are interrupted, and UEs controlled by the base station
experience call drops. Operators can schedule the time for base station reallocation. For details,
see Controller Resource Sharing Feature Parameter Description.

SingleRAN
Parameter Description 6 Network Redundancy
6 Network Redundancy
6.1 RNC in Pool

This section describes the RNC in Pool feature. For details, see RNC in Pool Feature Parameter
Description.
6.1.1 Overview
The rapid development of mobile internet brings fast service growth, which requires sustainable
network capacity expansion and high reliability of the RNC. New technologies need to be
introduced in network planning and deployment to ensure network reliability.
The existing technique for RNC capacity expansion requires an RNC to be split if the RNC
cannot accommodate any additional hardware. RNC splitting, however, makes network
reconstruction more difficult, which may affect services on the live network and decrease
network reliability. When an RNC becomes faulty, all NodeBs under it go out of service. This
can cause huge losses for operators.
RNC in Pool is an ideal solution for smooth RNC capacity expansion without compromising
network reliability. With this feature, interconnected RNCs form a resource pool over Iur-p, a
Huawei-proprietary interface. Figure 6-1 shows the network architecture for RNC in Pool.

SingleRAN
Figure 6-1 Network architecture for RNC in Pool
RNC in Pool consists of the following three optional features:

l WRFD-150211 RNC in Pool Load Sharing
This feature allows load sharing between existing RNCs and another RNC added for
capacity expansion.
l WRFD-150212 RNC in Pool Node Redundancy
This feature prevents an RNC failure from causing a massive service interruption.
l WRFD-150240 RNC in Pool Multiple Logical RNCs
This feature allows multiple logical RNCs to be configured on a BSC6910 to implement
load sharing or node redundancy. For example, if a BSC6910 carries three logical RNCs,
it can serve as the overflow RNC or backup RNC for three BSC6900s. The BSC6900 does
not support this feature.
You can enable the first or second feature above or both. The third feature, however, can only
be enabled when one of the other features or both are also enabled.
6.1.2 Benefits
The benefits of RNC in Pool are as follows:
l Load sharing for smooth RNC capacity expansion
Load sharing provided by RNC in Pool enables smooth RNC capacity expansion, which no
longer requires RNC splitting or NodeB reparenting. Figure 6-2 shows a comparison between
capacity expansion using existing techniques and using RNC in Pool.

SingleRAN
Figure 6-2 Comparison between capacity expansion using existing techniques and using RNC
in Pool
l Traffic balancing between RNCs for signaling bursts

With load balancing, the signaling bursts of an RNC can be processed by idle hardware
resources of another RNC in a pool, which increases the hardware resource utilization.
l Improved system reliability
Node redundancy provided by RNC in Pool allows a backup RNC to take over services of
a faulty RNC. The redundancy technique enables fast service resumption and improves
system reliability.
6.2 RNC Node Redundancy

This section describes the WRFD-040202 RNC Node Redundancy feature. For details, see RNC
Node Redundancy Feature Parameter Description.

SingleRAN
In a traditional WCDMA RAN, one NodeB is connected to only one RNC. The RNC controls
the radio access services of all the UEs in the RNS coverage area. To achieve high reliability,
the RNC uses many redundancy technologies, such as control-board backup, resource pool setup
for data processing boards, interface-board backup, and transmission redundancy. The RNC,
however, may break down in a disaster such as fire, water damage, explosion, or earthquake. In
this case, the RNS cannot provide radio access service in the coverage area.
Recent technological improvements allow the RNC to provide increasingly higher capacity to
meet the rapid growth of mobile services. The RNC is the control center of the RNS. Therefore,
RNC reliability is a great concern because a failure in the RNC affects the security of the whole
RNS. To increase reliability, Huawei provides an RNC node redundancy solution. If one RNC
fails, another RNC automatically takes over all the dual-homed NodeBs under the failed RNC.
RNC node redundancy uses 1+1 backup mode. Figure 6-3 shows the basic principles of 1+1
backup mode.
Figure 6-3 RNC-supported 1+1 backup mode
As shown in Figure 6-3, each NodeB is configured with two transmission links pointed towards
two RNCs, which are the primary RNC and the secondary RNC. All the data related to NodeBs,
cells, and their neighboring cells is configured on both the RNCs. Under normal conditions, the
primary RNC serves as the controlling RNC (CRNC) of the NodeB. When the primary RNC
fails, the NodeB tries to connect to the secondary RNC to resume work.
Assume that RNC1 and RNC2 are grouped into an RNC pool. RNC1 is installed in area A, where
earthquakes occur frequently, and RNC2 is installed in area B, where earthquakes rarely occur.
If RNC1 serves as the primary RNC of the NodeBs and fails when an earthquake occurs in area
A, RNC2 automatically takes over the NodeB control rights, and the NodeBs resume work.
In the RNC node redundancy solution, the two RNCs do not work in active/standby mode. In
normal situations, both RNCs provide services and the equipment can be fully utilized. When
one of the RNCs fails, the other automatically takes over all the dual-homed NodeBs to protect
the NodeBs from being out of service.

SingleRAN
6.3 BSC Node Redundancy

This section describes the GBFD-113725 BSC Node Redundancy feature. For details, see BSC
Node Redundancy Feature Parameter Description.
6.3.1 Overview
In traditional wireless networks, each BTS connects to only one BSC. If a BSC fails or all the
signaling links on the A interface are disconnected, the BSC cannot provide services and the
BTSs served by the BSC cannot access the network. To ensure service continuity in the event
of the preceding faults, Huawei introduces the BSC Node Redundancy feature, which is a BSC-
level redundancy solution.
NOTE
This feature applies to the following scenarios:

l BSC failure
A BSC fails or all the A interface boards are faulty. In either case, the BSC cannot process services.
l Failure in signaling links on the A interface
All the signaling links on the A interface are disconnected.
The BSC Node Redundancy feature enables two BSCs to form a redundancy group in all-IP
networking mode, where the A, Abis, and inter-BSC interfaces all use IP transmission. Two
BSCs in a redundancy group work in 1+1 backup mode. If one BSC fails or all the signaling
links on the A interface of one BSC are disconnected, the other BSC takes over the services from
the failed BSC. Figure 6-4 shows the networking diagram of two BSCs working in a redundancy
group.

SingleRAN
Figure 6-4 Networking diagram of two BSCs working in a redundancy group
In a redundancy group, each BSC considers itself as the local BSC and the other as the peer
BSC. To enable or disable this feature on the local and peer BSCs, set RedundancyMode to an
appropriate value.
LocalBSCID and PeerBSCID specify the local and peer BSCs, respectively, in a redundancy
group. GROUPINDEX specifies a redundancy group.
6.3.2 Benefits
This feature provides the following benefits:
l More reliable BSCs

Two BSCs in a redundancy group work in 1+1 backup mode. If one BSC fails, the other
BSC immediately takes over services from the failed BSC.

SingleRAN
l More reliable transmission

Both BSCs in a redundancy group connect to a core network (CN) over the A interface. If
all the signaling links on the A interface of one BSC are disconnected, the other BSC
immediately takes over services from the failed BSC.
6.4 MSC Pool

This section describes the GBFD-117401 MSC Pool feature. For details, see MSC Pool Feature
An MSC pool consists of a group of MSCs handling the traffic generated from one MSC pool
area. A BSC belonging to an MSC pool is connected to each MSC in the MSC pool. With
resource and load sharing, the traffic is evenly distributed to all the MSCs in an MSC pool,
reducing inter-MSC handovers and implementing MSC node redundancy.
Figure 6-5 shows the network topology of an MSC pool.
Figure 6-5 Network topology of an MSC pool
As shown in Figure 1, MSC 1, MSC 2, and MSC 3 form an MSC pool; and location area (LA)
1, LA 2, LA 3, and LA 4 form an MSC pool area. One BSC is connected to multiple MSCs at
the same time. The traffic from the BSC is evenly distributed to the MSCs in the MSC pool
based on Network Resource Identifiers (NRIs) or according to the load sharing principle.
The MSC pool area is a service area with one or more radio access network nodes. One MSC
pool area consists of several LAs. If different pool areas overlap each other, one LA can belong
to more than one pool area. Within a pool area, an MS may roam without the need to change the
serving MSC. The pool area is served by one or more MSCs in parallel. For example, the calls
in LA 1 can be evenly distributed to MSC 1, MSC 2, and MSC 3. A call made by a roaming MS
within the pool area does not trigger an inter-MSC handover.
The MSC Pool feature complies with the 3GPP TS 23.236 V6.3.0. This feature has the following
advantages:

SingleRAN
l All the MSCs in an MSC pool implement load balancing and resource sharing, increasing
network capacity and reducing equipment investment.
l If an MSC in an MSC pool is faulty or if an MSC is added to or removed from an MSC
pool, the existing network architecture does not need to be adjusted. This helps implement
MSC node redundancy and improve network reliability.
l Logically, all the MSCs in one MSC pool are regarded as one MSC. Therefore, inter-MSC
handovers and the signaling between the MSCs and the Home Location Registers (HLRs)
decrease, and the entire network performance is improved.
6.5 SGSN Pool

This section describes the GBFD-119701 SGSN Pool feature. For details, see SGSN Pool
Feature Parameter Description.
6.6 TC Pool
This section describes the GBFD-113726 TC Pool feature. For details, see TC Pool Feature

SingleRAN
Parameter Description 7 Fault Management
7 Fault Management
7.1 Fault Management Architecture
7.1.1 NEL
The NEL is where most alarms are generated. Most of these alarms are generated from main
devices of the NEs and peripherals, such as the environment monitoring device. The NEs mainly
include the base station controllers and base stations.
After detecting exceptions, an NE device first filters and judges them based on preset rules. The
exceptions that cannot be resolved are defined as faults. NE devices can directly rectify faults.
When certain faults need to be rectified with manual operations or using other automation
devices, alarms are reported.
Figure 7-1 shows implementation of fault management on the NEL, using Huawei multi-mode
base station controller as an example.
Figure 7-1 Fault management on the NEL
As shown in Figure 7-1 a controller includes the following devices:
l Operation and maintenance unit (OMU) boards

SingleRAN
l GE switching network and control unit (SCU) boards

l Service processing boards
l Monitoring devices
The OMU collects information about faults detected on the preceding devices, configures the
mapping and correlation for alarms and events, and post-processes the faults before reporting
alarms to the U2000.
7.1.2 EML
A device vendor generally provides the EML, for example, the Huawei iManager U2000, to
manage the NEs of the device vendor. On certain EMLs, devices of multiple vendors can be
managed.
On the EML, alarms are received, stored, and filtered. Alarms are dispatched through the
northbound interface.
Figure 7-2 shows implementation of fault management on the EML, using Huawei iManager
U2000 as an example. Fault management of the U2000 involves alarm/event setting, alarm/event
reporting, and alarm/event notification.
Figure 7-2 Fault management of the U2000

SingleRAN
7.1.3 NML
In normal cases, telecom operators centrally manage their devices on the network management
layer (NML) by using an NMS. The devices are deployed on various networks, such as the radio
access network (RAN), core network, and transport network. The NMS is generally developed
and managed by telecom operators themselves. The NMS manages the devices of different
vendors and fields on a comprehensive basis.
Fault management is an important function of the NMS. With this function, the NMS can receive,
filter, and store alarms generated on devices of multiple vendors and fields, and dispatch work
orders for these alarms.
7.2 NE Fault Management

Fault management provides the following basic functions:
l Fault detection
After detecting faults, a fault detection unit reports the faults to the fault management
module. Then, the fault management system reports alarms for these faults to the U2000
or local maintenance terminal (LMT) after processing the faults on each layer. Fault
detection units can detect faults of all MOs including software and hardware, such as TRXs,
ports, channels, boards, base stations, cells, links, and signaling messages.
l Fault collection
Fault collection is the most important external interface of fault management. It collects
faults reported by fault detection units and processes in a centralized manner.
l Duplicate fault filtering, fault transient rule, and fault toggle rule
There are two filtering stages: primary filter and secondary filter. In the primary filter, fault
detection units filter duplicate faults and other faults using the transient rule and toggle rule.
In the secondary filter, alarms to be reported are filtered.
– Transient rule
Faults or alarms of short duration can be filtered based on the alarm or fault generation
delay. Only the faults or alarms whose duration exceeds the threshold of the generation
delay comply with the transient rule and are reserved for next filtering.
As shown in Figure 7-3, the duration of fault 1 or alarm 1 is shorter than the delay
threshold T, so fault 1 or alarm 1 is discarded. The duration of fault 2 or alarm 2 is longer
than T, so alarm 2 or an alarm for fault 2 can be reported.

SingleRAN
Figure 7-3 Principles of the transient rule
– Toggle rule
The toggle rule applies to the faults that frequently occur and has oscillation characters.
Figure 7-4 shows the principles of the toggle rule.
Figure 7-4 Principles of the toggle rule
If the number of duplicate faults exceeds a threshold in a period T1, the duplicate faults are
filtered using the toggle rule. After that, one fault and an alarm for the fault are reserved, and
alarms for other duplicate faults are filtered. The fault detection units determine oscillation
termination conditions once oscillation starts. If the number of duplicate faults is within the
threshold in T2, the oscillation ends, which means that the fault does not occur.
l Fault troubleshooting
Fault troubleshooting involves device status switchover, fault isolation, and automatic fault
rectification. Base stations and controllers filter faults and automatically rectify them based
on preset policies. If required, the preset policies can be modified by adjusting parameters.
When faults fail to be automatically rectified and manual interventions are required, alarms
are reported.
l Alarm mapping
Alarm mapping is one of the core processes in fault management and aims to isolate fault
information from the alarms reported to users. Alarms presented to users are in a uniform
format and easy to understand. Alarm mapping forces faults to map reported alarms. Faults
and events occur in the system and involve system details. Alarms provide fault analysis
results and are displayed in a uniform and simple format. You can rectify faults based on
alarms. Rather than obtaining system details, you only need to locate the units where faults
occur and that can be replaced or modified.
l Alarm box management
Alarm box management provides functions, such as specifying the severity of alarms to be
reported to the alarm box, resetting the alarm box, and querying the alarm box version.

SingleRAN
After you specify concerned alarms to be reported to an alarm box, the alarm box provides
audible and visual notifications for you to rectify faults in a timely manner.
l Alarm correlation
Alarm correlation is one of the core processes in fault management. This function filters
out non-root faults and presents root faults to users. A root fault generally triggers multiple
correlative faults. If alarm correlation is not performed, multiple alarms are reported, which
affects fault location.
Certain critical alarms, such as service-related alarms, cannot be masked based on alarm
correlation even if the critical alarms are generated for correlative faults that include
physical device faults or data transmission faults. These alarms carry the serial numbers of
their root alarms. In this way, the U2000 can present alarm correlations to maintenance
personnel for fast fault location and troubleshooting.
l Supporting common alarms in the SingleRAN solution
In a GSM/UMTS dual-mode base station, if two common alarms with the same information
are detected and the alarms are for GSM and UMTS, respectively, an alarm for only one
RAT can be displayed. This prevents redundant work order dispatches. The RAT displayed
in the alarm varies according to the multi-RAT priority settings.
l Alarm synchronization between a base station and the U2000
Alarm synchronization between a base station and the U2000 consists of two stages:
– Alarm synchronization between the base station and the controller: The controller
queries active alarms from the base station, issues a command to the base station to
check for alarms that have not been synchronized, and updates alarm records on the
controller based on the check result.
– Alarm synchronization between the controller and the U2000.
l Alarm severity change
Based on 3GPP specifications, the severity of an uncleared alarm can be changed. After
the severity is changed, an alarm severity change message is reported.
l User-defined alarms
Base stations and controllers can be connected to external environment monitoring devices
to monitor the environment and device status, such as the temperature, humidity, voltage,
theft, and smoke. You can define alarms on base stations and controllers for faults related
to the status of the environment and devices. You can also set parameters for these alarms,
such as the alarm name, severity, and network management type. In this way, you can
dynamically monitor the environment and devices.
l Alarm masking
With this function, you can mask specified alarms by alarm ID or object.
– Masking alarms by alarm ID
If Shielded Flag of a specified alarm ID is set to Shielded, all the active alarms of the
alarm ID are cleared. During alarm masking, the specified alarm will not be reported
even if the fault persists. If the fault is not rectified after alarm masking is disabled,
alarms of the specified alarm ID are reported.
– Masking alarms by object
You can mask a specified alarm or all alarms for a certain board, port, or digital signal
processor (DSP), or mask a specified alarm for all objects.
l Fault log

SingleRAN
Fault logs are classified into local fault logs and central fault logs. Local fault logs record faults
on faulty boards and are stored in a nonvolatile storage device. Central fault logs record the
information about all faults, based on which you can obtain all the fault information about an
NE.

SingleRAN
Parameter Description 8 Flow Control
8 Flow Control
8.1 RNC Flow Control
8.1.1 Overview
Flow control is a protective measure for communications between the RNC and its peer
equipment. Flow control provides protection in the following ways:
l It restricts incoming traffic to:

– Protect equipment from overload, thereby maintaining system stability.
– Ensure that equipment can properly process services even under heavy traffic.
l It restricts outgoing traffic to reduce the load on the peer equipment.
8.1.2 Panorama
During mass gathering events, the traffic volume may exceed the processing capability of the
system. As a result, the system becomes overloaded, which may lead to messages being randomly
discarded and NE resetting, as well as response failures, call drops, service access failures, and
other unexpected events.
Resources in a WCDMA system are limited, so how they are used affects system performance.
The resources concerned here are:
l Equipment system resources, including CPU resources and memory

l Air interface resources, including channels, codes, and power
l Transmission resources
l Core network processing capabilities
To keep system stability and capabilities at the maximum level, Huawei RNCs perform flow
control at four points in the system, which are numbered in Figure 8-1.

SingleRAN
Figure 8-1 Four points in flow control
Flow control involves discarding originating messages (such as RRC connection requests) that
overload the system when system resources are insufficient, refusing to process low-priority
services, and rejecting access requests for low-priority services.
l To address problems caused by limited RNC resources (labeled 1 in Figure 8-1), the RNC
performs flow control for RNC units. The software of each RNC board monitors the system
resource usage. When necessary, the RNC starts basic flow control functions that suspend
non-critical functions, such as recording logs and printing to reduce the system load. Then,
based on the system load and the switch status of flow control functions, the RNC performs
other flow control functions to ensure system stability and reliability.
l To address problems caused by limited air interface resources (labeled 2 in Figure 8-1),
the RNC performs call attempt per second (CAPS) control, PCH congestion control, and
FACH congestion control.
– When the cell is overloaded with services, the RNC limits the number of RRC
connection requests admitted to a cell each second. This processing is implemented by
CAPS control.
– When the paging channel is congested, the RNC allows CS-domain paging messages
to preempt PS-domain paging messages in order to raise the paging success rate in the
CS domain.
– When the forward access channel (FACH) is congested, the RNC restricts message
retransmissions on the logical channels, rejects certain PS service requests, and triggers
state transitions such as CELL_PCH to CELL_DCH (P2D) and CELL_DCH to idle
(D2Idle). This gives priority to access requests for high-priority services such as CS
services, keeps a high cell update success rate, and reduces call drops.
The RNC performs admission control, load reshuffling, and overload control on code
and power resources. For details about admission control, see Call Admission Control
Feature Parameter Description. For details about load reshuffling and overload control,
see Load Control Feature Parameter Description and Overload Control Feature
l To address problems caused by limited signaling bandwidth over the Iu interface (labeled
3 in Figure 8-1), the RNC works with the core network to perform flow control over the
Iu interface. Based on link congestion conditions detected at the local end and congestion

SingleRAN
indications reported from the peer end, the RNC performs flow control on initial direct
transfer messages to reduce the signaling traffic over the Iu interface. This prevents severe
congestion on the signaling link between the RNC and the core network and also reduces
the load on the core network when it is overloaded.
l To address problems caused by limited transmission resources over the Iub interface
(labeled 4 in Figure 8-1), the RNC supports user-plane congestion control over the Iub
interface. Specifically, the RNC restricts the data transmission rates when there is
transmission congestion over the Iub interface. This prevents packet loss and makes more
efficient use of the bandwidth.
For RRC connection requests, the RNC supports control-plane load sharing and user-plane load
sharing. This achieves dynamic resource sharing, balances the load among subracks and boards,
and improves RNC service processing efficiency. For details, see Controller Resource Sharing
Feature Parameter Description.
NOTE
The BSC6910 inherits the flow control function from the BSC6900. The only difference is in the RNC
units that flow control works on. Unless otherwise stated, the following descriptions apply to both the
BSC6900 and BSC6910.
8.1.3 E2E Flow Control

E2E Flow Control protects NEs in a RAN from being overloaded. The NEs that participate in
flow control are the RNC and NodeB.
Without E2E flow control, when the CPU of the baseband board or WMPT is congested or
overloaded, or when the cell power is congested, the RNC will not know. Therefore, the RNC
continues to admit a large number of RRC CONNECTION REQUEST messages and send
RADIO LINK SETUP REQUEST messages to the NodeB over the Iub interface even when the
NodeB is congested or overloaded. In this case, the NodeB should reject or discard these RADIO
LINK SETUP REQUEST messages, which lower the cell resource utilization. In addition, the
access of high-priority services cannot be guaranteed because the NodeB is unaware of the
service priority of each message. To address these issues, Huawei has introduced the following
E2E flow control functions:
l E2E flow control based on NodeB CPU load

– E2E flow control phase 1
– E2E flow control phase 2
l E2E flow control based on power congestion
E2E Flow Control limits the traffic flow that enters NEs and therefore ensures the stable
operation of NEs when these NEs are overloaded. For details about other flow control measures,
such as flow control for overloaded RNC units, see Flow Control Feature Parameter
Description. Compared with flow control performed on a single NE, E2E Flow Control has the
following benefits:
l More reference information is provided for flow control because of cooperation between
NEs. For example, if the RNC provides service priority information for the NodeB, the
NodeB can implement differentiated flow control based on service priorities to
preferentially ensure the access of high-priority services.
l Better flow control effects can be achieved because of cooperation between NEs. In E2E
Flow Control Phase 2, the RNC performs flow control on RRC CONNECTION REQUEST

SingleRAN
messages, and the NodeB performs flow control on RADIO LINK SETUP REQUEST
messages. Consequently, if the NodeB is overloaded, the RNC reduces the number of
unnecessary RRC CONNECTION REQUEST messages to be processed. This action
reduces the NodeB Application Part (NBAP) signaling traffic on the Iub interface,
increasing resources available to admitted UEs and RAN resource utilization.
For details about the engineering guidelines, see E2E Flow Control Feature Parameter
Description.
8.2 BSC Flow Control
8.2.1 Overview
This section briefly describes how BSC flow control works. Flow control includes BSC flow
control, BTS/cell service flow control, interface signaling flow control, flow control based on
user priority, and load sharing. For details on the related features, network impacts and
engineering guidelines, see Flow Control Feature Parameter Description
8.2.2 Panorama
During base station subsystem (BSS) construction, the system capacity is planned according to
the estimated traffic volume in the coverage areas. When the traffic volume is lower than or
equal to the planned capacity, the BSS can process services properly. However, in certain
situations, such as major events or disasters, the traffic volume surges and sometimes exceeds
the planned capacity, leading to BSS overload. If no measures are taken to protect the BSS,
system performance may deteriorate noticeably and the system may even destabilize.
To ensure system stability and the maximum processing capability, Huawei applies flow control
at the six points marked in Figure 8-2. Flow control enables Huawei BSS to discard certain
messages, such as random access requests, and to reject low-priority services if system resources
are insufficient.
Figure 8-2 Flow control points numbered 1 through 6
The flow control points are described as follows:

SingleRAN
l BSC: Base station controller (BSC) flow control is introduced to address BSC resource
insufficiency. BSC boards monitor the system resource usage in real time and stop some
functions, such as printing and recording logs, to decrease the central processing unit (CPU)
usage to ensure system stability and reliability.
l Um interface: SDCCH flow control and PCH flow control are introduced to address Um-
interface resource insufficiency.
l A interface: CN flow control and A-interface flow control are introduced to address A-
l Abis interface: Flow control based on the message arrival rate, flow control based on LAPD
signaling links, and flow control based on the call type are introduced to address Abis-
l Lb interface: Flow control on location request messages is introduced to address Lb-
interface insufficiency.
l Gb interface: BSSGP Virtual Connection (BVC) flow control and mobile station (MS) flow
control are introduced to address Gb-interface insufficiency. BSSGP refers to Base Station
Subsystem GPRS Protocol. The SGSN adjusts the downlink data rates for cells and MSs
based on their maximum packet switched (PS) data volumes and the data transfer rate
reported by the BSC.
Huawei BSS introduces flow control based on user priorities. In addition, control-plane load
sharing and user-plane load sharing are introduced to process random access requests. This
achieves dynamic resource sharing, balances the load among subracks and boards, and improves
BSC service processing efficiency.

SingleRAN
Parameter Description 9 Operation and Maintenance Reliability
9 Operation and Maintenance Reliability
9.1 Overview
The Operation & Maintenance System One-Key Recovery feature reduces the complexity of
the backup and recovery of the OS and the complexity of OMU data configuration. In addition,
this feature minimizes the duration of service disruption caused by the operation & maintenance
operations. This feature is applicable only to the DOPRA Linux OS and mainly used in the
following scenarios:
l The DOPRA Linux OS on the OMU board is corrupted.

l OMU applications are corrupted.
l (Only for the BSC6900) The OS on the OMU board is switched from non-DOPRA Linux
to DOPRA Linux.
9.2 Technical Description

This section describes how to implement the Operation & Maintenance System One-Key
Recovery feature.
Scheme 1
The USB creator is used to create the USB disk for installing the DOPRA Linux OS and the
OMU applications. The USB installation disk is plugged into the USB port on the OMU board.
The OMU board is then reset. Five to ten minutes later, the OS or OMU applications on the
OMU board are recovered.
Note that the OS, OMU applications, and the respective configuration information must be stored
onto the USB installation disk during the creation of the USB installation disk. Then, Bootstrap
scripts are generated on the USB installation disk to facilitate the start-up of the OMU board
through the USB installation disk.
The Bootstrap scripts first install the DOPRA Linux OS and configure the information for the
OS. Then, the Bootstrap scripts install the OMU applications and configure the information for
the OMU applications. Figure 9-1 shows the OMU board software recovery process.

SingleRAN
Figure 9-1 OMU board software recovery process
When the OS on the existing OMU boards is switched from non-DOPRA Linux to DOPRA
Linux, the USB creator is used to obtain the configuration information, especially the network
configuration information, the OMU applications configuration information, and the NE
confirmation information, of the OMU board whose OS is to be switched. Based on the
information obtained, the USB creator creates a USB installation disk for installing the DOPRA
Linux OS. The USB installation disk is plugged into the USB port on the OMU board. The OMU
board is then reset. Five to ten minutes later, the switchover of the OS is complete.

SingleRAN
Scheme 2
When OMU hardware is not damaged, the files are backed up through the existing OS on the
OMU board. In this way, users can recover the OMU OS without using an external storage
medium.
Before recovering the OMU OS, connect a keyboard and a monitor to the OMU board and then
reset the OMU board. When the system boot menu is displayed, select the system recovery option
using the keyboard. The OMU board starts to install the DOPRA Linux OS automatically. Five
to ten minutes later, the OS on the OMU board is recovered. Figure 9-2 shows the OS recovery
process for the OMU board.
Figure 9-2 OS recovery process for the OMU board
If no keystroke is detected after the boot menu is displayed, the OMU board boots the default
OS and does not perform OS recovery.

SingleRAN
The Operation & Maintenance System One-Key Recovery feature is activated by default for the
newly delivered OMUs, and the OS backup and the system recovery program are preset. For the
existing OMUs, this feature can be activated through an OS switchover or upgrade.

SingleRAN
Parameter Description 10 Hardware Reliability
10 Hardware Reliability
For the acronyms, abbreviations, terms, and definitions, see the Glossary.

SingleRAN
10.1 BSC/RNC Board Redundancy
10.1.1 BSC6910 Board Redundancy

BSC6910 board redundancy has two types: board backup and resource pool.
NOTE
The BSC6910 interface boards have an effective mechanism for fault detection and automatic recovery.
When the BSC6910 detects that a certain proportion of resources of an interface board are unavailable for
a specified period of time, the BSC6910 resets the interface board. If the faulty board is the active one in
a pair of active and standby boards, the BSC6910 switches over the active and standby boards. For example:
l The BSC6910 resets an Iub interface board if a certain proportion of cells under the Iub interface board
are unavailable for a specified period of time because of a failure in Iub transmission links.
l The BSC6910 resets an Iub interface board under the following conditions: The RRC connection setup
success rate in a cell is lower than a predefined threshold because of a failure in Iub transmission links,
the proportion of such cells under the Iub interface board reaches a predefined cell threshold, the
proportion of NodeBs having such cells reaches a predefined NodeB threshold, and this situation
persists for a specified period of time.
l If the BSC6910 detects any transmission fault, the BSC6910 reports an alarm instead of resetting the
interface board.
l Backup of AOUc/UOIc/POUc boards
When two AOUc/UOIc/POUc boards are installed in adjacent active and standby slots in
a BSC6910 subrack, the two boards can be configured to work in board backup or optical
port backup mode.
l Resource pool of DPUf boards
The DPUf boards of the BSC6910 and the GUPTC subsystem of each DPUf work in
resource pool mode.
l Backup of EXOUa/FG2c/GOUc/FG2d/GOUd boards
When two EXOUa/FG2c/GOUc/FG2d/GOUd boards are installed in adjacent active and
standby slots in a BSC6910 subrack, the two boards can be configured to work in board
backup mode.
l Resource pool of ENIUa boards
The ENIUa boards of the BSC6910 work in resource pool mode.
l Backup of SCUb boards
The BSC6910 is configured with two SCUb boards in adjacent active and standby slots in
each subrack. The two boards work in board backup mode.
l Backup of GCUa/GCUb/GCGa/GCGb boards
The BSC6910 is configured with two GCUa/GCUb/GCGa/GCGb boards in adjacent active
and standby slots in the MPS. The two boards work in board backup mode.
l Backup of EOMUa boards
When two EOMUa boards are installed in adjacent active and standby slots in the BSC6910
MPS, the two boards work in board backup mode.
l Independent mode of the ESAUa Board
The BSC6910 is configured with one ESAUa board, which works in independent mode.

SingleRAN
l Resource pool and board backup of EGPUa/EXPUa boards

The EGPUa board provides the following logical functions: RMP for resource
management, UCUP for UMTS service processing, and GCUP for GSM service
processing. The EXPUa board provides the function of GSM service processing. The
redundancy mode of the EGPUa/EXPUa board varies depending on its logical type.
10.1.2 BSC6900 Board Redundancy

BSC6900 board redundancy has two types: board backup and resource pool.
NOTE
The BSC6900 interface boards have an effective mechanism for fault detection and automatic recovery.
When the BSC6900 detects that a certain proportion of resources of an interface board are unavailable for
a specified period of time, the BSC6900 resets the interface board. If the faulty board is the active one in
a pair of active and standby boards, the BSC6900 switches over the active and standby boards. For example:
l The BSC6900 resets an Iub interface board if a certain proportion of cells under the Iub interface board
are unavailable for a specified period of time because of a failure in Iub transmission links.
l The BSC6900 resets an Iub interface board under the following conditions: The RRC connection setup
success rate in a cell is lower than a predefined threshold because of a failure in Iub transmission links,
the proportion of such cells under the Iub interface board reaches a predefined cell threshold, the
proportion of NodeBs having such cells reaches a predefined NodeB threshold, and this situation
persists for a specified period of time.
l If the BSC6900 detects any transmission fault, the BSC6900 reports an alarm instead of resetting the
interface board.
l Backup of AEUa boards
When two AEUa boards are configured in adjacent active and standby slots in a BSC6900
subrack, the two boards can be configured to work in board backup mode.
l Backup of EIUa/EIUb boards
When two EIUa/EIUb boards are configured in adjacent active and standby slots in a
BSC6900 subrack, the two boards can be configured to work in board backup mode.
l Resource pool of NIUa boards
The NIUa boards of the BSC6900 work in resource pool mode.
l Backup of OIUa/OIUb boards
When two OIUa/OIUb boards are configured in adjacent active and standby slots in a
l Backup of PEUa/PEUc boards
When two PEUa/PEUc boards are configured in adjacent active and standby slots in a
l Backup of SCUa/SCUb boards
The BSC6900 is configured with two SCUa/SCUb boards in adjacent active and standby
slots in each subrack. The two boards work in board backup mode.
l Backup of TNUa/TNUb boards
The BSC6900 is configured with two TNUa/TNUb boards in adjacent active and standby
slots in some subracks. The two boards work in board backup mode.
l Backup of AOUa/AOUc boards

SingleRAN
When two AOUa/AOUc boards are configured in adjacent active and standby slots in a
BSC6900 subrack, the two boards can be configured to work in board backup mode or
optical port backup mode.
l Backup of FG2a/FG2c/FG2d boards
When two FG2a/FG2c/FG2d boards are configured in adjacent active and standby slots in
a BSC6900 subrack, the two boards can be configured to work in either of the following
modes: board backup with no port backup and board backup with port backup.
l Backup of GCUa/GCUb/GCGa/GCGb boards
The BSC6900 is configured with two GCUa/GCUb/GCGa/GCGb boards in adjacent active
and standby slots in the MPS. The two boards work in board backup mode.
l Backup of GOUa/GOUc/GOUd boards
When two GOUa/GOUc/GOUd boards are configured in adjacent active and standby slots
in a BSC6900 subrack, the two boards can be configured to work in either of the following
modes: board backup with no port backup and board backup with port backup.
l Backup of OMUa/OMUb/OMUc boards
When two OMUa/OMUb/OMUc boards are installed in adjacent active and standby slots
in the BSC6900 MPS, the two boards work in board backup mode.
l Backup of POUa/POUc boards
When two POUa/POUc boards are configured in adjacent active and standby slots in a
l Independent mode of the SAUa/SAUc board
The BSC6900 is configured with one SAUa/SAUc board, which works in independent
mode.
l Backup of UOIa/UOIc boards
When two UOIa/UOIc boards are configured in adjacent active and standby slots in a
l Backup of XPUa/XPUb/SPUa/SPUb boards
When two XPUa/XPUb/SPUa/SPUb boards are installed in adjacent active and standby
slots in a BSC6900 subrack, the two boards can be configured to work in board backup
mode.
l Resource pool of DPUa/DPUb/DPUc/DPUd/DPUe/DPUf/DPUg boards
The DPUa/DPUb/DPUc/DPUd/DPUe/DPUf/DPUg boards of the BSC6900 and the digital
signal processors (DSPs) in all the DPUa/DPUb/DPUc/DPUd/DPUe/DPUf/DPUg boards
work in resource pool mode.

SingleRAN
Parameter Description 11 Related Features
11 Related Features
Prerequisite Features
None
Mutually Exclusive Features

None
Impacted Features
None

SingleRAN
Parameter Description 12 Network Impact
12 Network Impact
System Capacity
None
Network Performance
None

SingleRAN
Parameter Description 13 Engineering Guidelines
13 Engineering Guidelines
13.1 When to Use Operation & Maintenance System One-

Key Recovery
When the OS of the OMU board malfunctions, use this feature to recover the OS without using
an external storage medium, such as a USB disk or CD-ROM.
13.2 Deployment
13.2.1 Process
l New sites
The feature has been activated for the delivered OMU boards by default.
l Existing sites
Install the latest DOPRA Linux OS using the USB installation disk, or upgrade the DOPRA
Linux OS to the latest version using the controller upgrade tool.
13.2.2 Requirements
l New sites
N/A
l Existing sites
– If the USB installation disk is used to install the DOPRA Linux OS, a USB disk with a
capacity of 2 GB or higher must be ready.
– If the controller upgrade tool is used to upgrade the DOPRA Linux OS, the controller
must run on the DOPRA Linux OS.
13.2.3 Activation
l Using the USB installation disk to install the latest DOPRA Linux OS

SingleRAN
Parameter Description 13 Engineering Guidelines
Prepare the USB installation disk for switching the OMU OS from non-DOPRA Linux to
DOPRA Linux. Next, use the USB installation disk to install DOPRA Linux. For detailed
operations, see Operation Guide to Switching OMU Operating System Through USB
Disks.
l Upgrading the DOPRA Linux OS to the latest version using the controller upgrade tool
– Confirm the controller software version required by DOPRA Linux. For details, see
Guide to Dopra Linux Operating System Remote Patch Upgrade.
– Upgrade the controller software version by referring to the controller upgrade guide.
– Upgrade the DOPRA Linux OS. For details, see Guide to Dopra Linux Operating
System Remote Patch Upgrade.
13.2.4 Activation Observation

N/A
13.2.5 Deactivation
N/A
13.3 Performance Monitoring

N/A
13.4 Troubleshooting
N/A

SingleRAN
Parameter Description 14 Parameters
14 Parameters
There are no specific parameters associated with this feature.

SingleRAN
Parameter Description 15 Counters
15 Counters
Table 15-1 Counter description
Counter ID Counter Name Counter NE Feature ID Feature Name

Description
67194469 VS.SDH.SWAP T7041:Number BSC6900 MRFD-210101 System

.REASON.REQ of SDH Port Redundancy
UEST.COUNT Switchovers on
S Conditional
Requests

.REASON.KBY of SDH Port Redundancy
TE.COUNTS Switchovers on
K byte Requests

.REASON.EXT of SDH Port Redundancy
ERNAL.COUN Switchovers on
TS external
Requests
67194472 VS.SDH.FAUL T7044:Number BSC6900 MRFD-210101 System

T.CHANNEL.P of SDH Redundancy
ROTECT.COU Protection
NTS Channel
Failures

T.CHANNEL. of SDH Redundancy
WORK.COUN Working
TS Channel
Failures
73436939 VS.Frame.Flux. HR9732a:Peak BSC6900 MRFD-210104 BSC/RNC

Peak.TxRate Inter-Subrack Resource
Transmitting Sharing
Traffic

SingleRAN

Description
73436941 VS.Frame.Flux. AR9732a:Avera BSC6900 MRFD-210104 BSC/RNC

Mean.TxRate ge Inter-Subrack Resource
Traffic
73441493 VS.Frame.Flux. R9732a:Numbe BSC6900 MRFD-210104 BSC/RNC

DropPackets r of Discarded Resource
Inter-Subrack Sharing
Packets
73441494 VS.Frame.Flux. R9732b:Numbe BSC6900 MRFD-210104 BSC/RNC

TxPackets r of Sent Inter- Resource
Subrack Packets Sharing

.REASON.REQ of SDH Port Redundancy
UEST.COUNT Switchovers on
S Conditional
Requests

.REASON.KBY of SDH Port Redundancy
TE.COUNTS Switchovers on
K byte Requests

.REASON.EXT of SDH Port Redundancy
ERNAL.COUN Switchovers on
TS external
Requests

T.CHANNEL.P of SDH Redundancy
ROTECT.COU Protection
NTS Channel
Failures

T.CHANNEL. of SDH Redundancy
WORK.COUN Working
TS Channel
Failures
73436939 VS.Frame.Flux. HR9732a:Peak BSC6910 MRFD-210104 BSC/RNC

Peak.TxRate Inter-Subrack Resource
Traffic

SingleRAN

Description
73436941 VS.Frame.Flux. AR9732a:Avera BSC6910 MRFD-210104 BSC/RNC

Mean.TxRate ge Inter-Subrack Resource
Traffic
73441493 VS.Frame.Flux. R9732a:Numbe BSC6910 MRFD-210104 BSC/RNC

DropPackets r of Discarded Resource
Inter-Subrack Sharing
Packets
73441494 VS.Frame.Flux. R9732b:Numbe BSC6910 MRFD-210104 BSC/RNC

TxPackets r of Sent Inter- Resource
Subrack Packets Sharing

SingleRAN
Parameter Description 16 Glossary
16 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.

SingleRAN
Parameter Description 17 Reference Documents
17 Reference Documents
1. Operation and Maintenance Feature Parameter Description for GSM BSS or WCDMA
RAN
2. Controller Resource Sharing Feature Parameter Description for WCDMA RAN
3. Flow Control Feature Parameter Description for GSM BSS or WCDMA RAN
4. RNC in Pool Feature Parameter Description for WCDMA RAN
5. RNC Node Redundancy Feature Parameter Description for WCDMA RAN
6. BSC Node Redundancy Feature Parameter Description for GSM BSS
7. MSC Pool Feature Parameter Description for GSM BSS
8. SGSN Pool Feature Parameter Description for GSM BSS
9. TC Pool Feature Parameter Description for GSM BSS
10. Call Admission Control Feature Parameter Description for WCDMA RAN
11. Load Control Feature Parameter Description for WCDMA RAN
12. Overload Control Feature Parameter Description for WCDMA RAN
13. E2E Flow Control Feature Parameter Description for WCDMA RAN
14. Fault Management Feature Parameter Description for SingleRAN


Base Station Cabinets and Subracks (Including The BBU Subrack) Configuration (SingleRAN - 04)

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Base Station Cabinets and Subracks (Including The BBU Subrack) Configuration (SingleRAN - 04)

Загружено:

Авторское право:

Доступные форматы

SingleRAN

Base Station Controller Equipment

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2014-04-30) Huawei Proprietary and Confidential i

1 About This Document..................................................................................................................1

Issue 01 (2014-04-30) Huawei Proprietary and Confidential ii

6.2 RNC Node Redundancy...............................................................................................................................................25

9 Operation and Maintenance Reliability.................................................................................42

Issue 01 (2014-04-30) Huawei Proprietary and Confidential iii

Issue 01 (2014-04-30) Huawei Proprietary and Confidential iv

1 About This Document

1.2 Intended Audience

l Need to understand the features described herein

1.3 Change History

SRAN9.0 Draft A (2014-01-20)

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 1

1.4 Differences Between Base Station Types

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 2

l Decreasing the number of accidents

Controller reliability designs include system availability, planned service interruption,

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 3

Reliability Feature/ Radio Feature ID/ Remarks

Planned BSC/RNC GSM and MRFD-210401 For details about

Redundancy RNC UMTS None For details, see 5.2

BSC GSM None For details, see 5.3

BSC/RNC GSM and MRFD-210104 For details about

Network RNC in Pool UMTS l WRFD-150211 For details about

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 4

Reliability Feature/ Radio Feature ID/ Remarks

RNC Node UMTS WRFD-040202 For details about

BSC Node GSM GBFD-113725 For details about

MSC Pool GSM GBFD-117401 For details about

SGSN Pool GSM GBFD-119701 For details about

TC Pool GSM GBFD-113726 TC For details about

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 5

Reliability Feature/ Radio Feature ID/ Remarks

Fault Fault GSM and MRFD-210304 For details about

Flow control RNC Flow UMTS WRFD-040100 For details about

BSC Flow GSM l GBFD-111705 For details about

Operation Operation GSM and GBFD-111214 For details, see 9

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 6

Reliability Feature/ Radio Feature ID/ Remarks

Hardware BSC/RNC GSM and None For details, see 10

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 7

Table 3-1 Reliability specifications

System availability > 99.999%

Mean time between failures (MTBF) ≥ 525000 hours

Mean time to repair (MTTR) ≤ 1 hour

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 8

4 Planned Service Interruption

4.2 BSC/RNC Software Management

l Querying the software version and its status

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 9

Figure 4-1 BSC/RNC remote upgrade process

The remote upgrade process is as follows:

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 10

Table 4-1 Key specifications for BSC/RNC software management

Index Version Implementation

Service interruption duration caused by an Service interruption duration ≤ 3 min

Service interruption duration caused by a No service interruption for a hot patch

Reloading time ≤ 7 min