Base Station Controller Equipment Reliability (SRAN9.0 - Draft A)

SingleRAN
Base Station Controller Equipment

Reliability Feature Parameter
Description
Issue
Draft A
Date
2014-01-20
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:
[email protected]
Issue Draft A (2014-01-20)
Huawei Proprietary and Confidential

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
2 Overview.........................................................................................................................................2
2.1 Introduction....................................................................................................................................................................2
2.2 Benefits...........................................................................................................................................................................2
2.3 Architecture....................................................................................................................................................................2
3 Reliability Specifications.............................................................................................................7
4 Planned Service Interruption......................................................................................................8
4.1 Overview........................................................................................................................................................................8
4.2 BSC/RNC Software Management..................................................................................................................................8
5 Redundancy Design....................................................................................................................11
5.1 Overview......................................................................................................................................................................11
5.2 RNC Redundancy Design.............................................................................................................................................12
5.2.1 Resource Management Plane.....................................................................................................................................12
5.2.2 Control plane.............................................................................................................................................................12
5.2.3 User Plane..................................................................................................................................................................14
5.2.4 Transport Plane..........................................................................................................................................................14
5.3 BSC Redundancy Design.............................................................................................................................................15
5.3.1 Resource Management Plane.....................................................................................................................................16
5.3.2 Control Plane.............................................................................................................................................................16
5.3.3 User Plane..................................................................................................................................................................18
5.3.4 Transport Plane..........................................................................................................................................................19
5.4 NewNode......................................................................................................................................................................20
6 Network Redundancy.................................................................................................................22
6.1 RNC in Pool..................................................................................................................................................................22
6.1.1 Overview...................................................................................................................................................................22
6.1.2 Benefits......................................................................................................................................................................23
6.2 RNC Node Redundancy...............................................................................................................................................24

ii
SingleRAN
Contents
6.3 BSC Node Redundancy................................................................................................................................................26

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

9.1 Overview......................................................................................................................................................................41
9.2 Technical Description...................................................................................................................................................41
10 Hardware Reliability................................................................................................................45
10.1 BSC/RNC Board Redundancy....................................................................................................................................46
10.1.1 BSC6910 Board Redundancy..................................................................................................................................46
10.1.2 BSC6900 Board Redundancy..................................................................................................................................47
11 Related Features.........................................................................................................................49
12 Network Impact.........................................................................................................................50
13 Engineering Guidelines...........................................................................................................51
13.1 When to Use Operation & Maintenance System One-Key Recovery........................................................................51
13.2 Deployment................................................................................................................................................................51
13.2.1 Process.....................................................................................................................................................................51
13.2.2 Requirements...........................................................................................................................................................51
13.2.3 Activation................................................................................................................................................................51
13.2.4 Activation Observation............................................................................................................................................52
13.2.5 Deactivation.............................................................................................................................................................52
13.3 Performance Monitoring.............................................................................................................................................52
13.4 Troubleshooting..........................................................................................................................................................52

iii
SingleRAN
Contents
14 Parameters...................................................................................................................................53
15 Counters......................................................................................................................................54
16 Glossary.......................................................................................................................................57
17 Reference Documents...............................................................................................................58

iv
SingleRAN
1 About This Document
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
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
Editorial change:
Changes in wording or addition of information that was not described in the earlier version
Draft A (2014-01-20)
This is a new document for SRAN9.0.

SingleRAN
2 Overview
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
Minimizing the scope of fault influence
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
2 Overview
Table 2-1 Controller equipment reliability-related features and functions that are supported by
GSM and UMTS
Reliability
Category
Feature/
Function
Radio
Access
Technology
Feature ID/
Feature Name
Remarks
Planned
service
interruption
BSC/RNC
Software
Managemen
t
GSM and
UMTS
MRFD-210401
BSC/RNC
Software
Management
For details about

engineering
guidelines, see
Operation and
Maintenance Feature
Parameter
Description.
Redundancy
design
RNC
Redundancy
UMTS
None
For details, see 5.2

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

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

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

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

SingleRAN
Reliability
Category
2 Overview
Feature/
Function
Radio
Access
Technology
Feature ID/
Feature Name
Remarks
RNC Node
Redundancy
UMTS
WRFD-040202
RNC Node
Redundancy
For details about

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

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

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

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

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

SingleRAN
2 Overview
Reliability
Category
Feature/
Function
Radio
Access
Technology
Feature ID/
Feature Name
Remarks
Fault
management
Fault
Managemen
t
GSM and
UMTS
MRFD-210304
Fault Management
For details about

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

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

engineering
guidelines, see Flow
Control Feature
Parameter
Description in GSM
BSS documents.
l GBFD-119117
Flow Control on
Gb Interface
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
and
maintenance
reliability
Operation
and
Maintenanc
e System
One-Key
Recovery
GSM and
UMTS
GBFD-111214
Operation &
Maintenance
System One-Key
Recovery

For details, see 9

Operation and
Maintenance
Reliability.
SingleRAN
2 Overview
Reliability
Category
Feature/
Function
Radio
Access
Technology
Feature ID/
Feature Name
Remarks
Hardware
reliability
BSC/RNC
Board
Redundancy
GSM and
UMTS
None
For details, see 10

Hardware
Reliability.

SingleRAN
3 Reliability Specifications
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
4 Planned Service Interruption
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
Uploading, downloading, and activating the program files, patch files, and license files
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
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 boards are 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

upgrade for a major release
Service interruption duration 3 min
Service interruption duration caused by a

patch upgrade
No service interruption for a hot patch

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

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

sites
12 min

10
SingleRAN
5 Redundancy Design
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.
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.
Other reliability designs

11
SingleRAN
5 Redundancy Design
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.
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.
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.

12
SingleRAN
5 Redundancy Design
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.
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.

13
SingleRAN
5 Redundancy Design
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.
Port backup or load sharing
Resource pool

14
SingleRAN
5 Redundancy Design
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
Downtime
(Minute/Year)
Quantitative
Reliability
Analysis
1+1 active/standby
redundancy
0.999999796
0.11
Low task reliability

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

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

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

Index
Switchover for interface boards
The impact persists within 3s for stable

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 persists within
9s for stable services in a switchover for interface boards.
5.3 BSC Redundancy Design


15
SingleRAN
5 Redundancy Design
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 controland 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.
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.
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.

16
SingleRAN
5 Redundancy Design
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.
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

17
SingleRAN
5 Redundancy Design
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.

18
SingleRAN
5 Redundancy Design
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.
Port backup or load sharing
Resource pool
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-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
Downtime
(Minute/Year)
Quantitative
Reliability
Analysis
1+1 active/standby
redundancy
0.999999796
0.11
Low task
reliability and low
basic reliability
under the same
traffic volume
1+1 active/standby
redundancy plus resource
pool
0.999999918
0.04
High task
reliability and low
basic reliability
under the same
traffic volume
Independent board plus

resource pool
0.999999183
0.43
Low task
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

19
SingleRAN
5 Redundancy Design
Table 5-4 Key specifications of transmission redundancy

Index
Switchover for interface boards
The impact persists within 3s for stable

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 persists within
9s for stable services in a switchover for interface boards.
5.4 NewNode
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 controlplane 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 userplane 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 userplane 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
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.

20
SingleRAN
5 Redundancy Design
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.

21
SingleRAN
6 Network Redundancy
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.

22
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.
WRFD-150212 RNC in Pool Node Redundancy

This feature prevents an RNC failure from causing a massive service interruption.
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.

23
SingleRAN
Figure 6-2 Comparison between capacity expansion using existing techniques and using RNC
in Pool
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.
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.

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

25
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 BSClevel 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.

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

27
SingleRAN
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:

28
SingleRAN
All the MSCs in an MSC pool implement load balancing and resource sharing, increasing
network capacity and reducing equipment investment.
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.
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

29
SingleRAN
7 Fault Management
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

30
SingleRAN
GE switching network and control unit (SCU) boards
Service processing boards
Monitoring devices
7 Fault Management
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

31
SingleRAN
7 Fault Management
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.
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.
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.

32
SingleRAN
7 Fault Management
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.
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.
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.

33
SingleRAN
7 Fault Management
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.
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.
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.
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.
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.
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.
Fault log

34
SingleRAN
7 Fault Management
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.

35
SingleRAN
8 Flow Control
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.
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
Air interface resources, including channels, codes, and power
Transmission resources
Core network processing capabilities
To keep system stability and capabilities at the maximum possible level, Huawei RNCs perform
flow control at four points in the system, which are numbered inFigure 8-1.

36
SingleRAN
8 Flow Control
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.
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
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

37
SingleRAN
8 Flow Control
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
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.
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

38
SingleRAN
8 Flow Control
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:


39
SingleRAN
8 Flow Control
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.
Um interface: SDCCH flow control and PCH flow control are introduced to address Uminterface resource insufficiency.
A interface: CN flow control and A-interface flow control are introduced to address Ainterface resource insufficiency.
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 Abisinterface resource insufficiency.
Lb interface: Flow control on location request messages is introduced to address Lbinterface insufficiency.
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.

40
SingleRAN
9 Operation and Maintenance Reliability
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.
OMU applications are corrupted.
(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.

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

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

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

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

45
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.
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.
Resource pool of DPUf boards

The DPUf boards of the BSC6910 and the GUPTC subsystem of each DPUf work in
resource pool mode.
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.
Resource pool of ENIUa boards

The ENIUa boards of the BSC6910 work in resource pool mode.
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.
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.
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.
Independent mode of the ESAUa Board

The BSC6910 is configured with one ESAUa board, which works in independent mode.

46
SingleRAN
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.
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.
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.
Resource pool of NIUa boards

The NIUa boards of the BSC6900 work in resource pool mode.
Backup of OIUa/OIUb boards

When two OIUa/OIUb boards are configured in adjacent active and standby slots in a
Backup of PEUa/PEUc boards

When two PEUa/PEUc boards are configured in adjacent active and standby slots in a
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.
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.
Backup of AOUa/AOUc boards

47
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.
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.
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.
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.
Backup of POUa/POUc boards

When two POUa/POUc boards are configured in adjacent active and standby slots in a
Independent mode of the SAUa/SAUc board

The BSC6900 is configured with one SAUa/SAUc board, which works in independent
mode.
Backup of UOIa/UOIc boards

When two UOIa/UOIc boards are configured in adjacent active and standby slots in a
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.
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.

48
SingleRAN
11 Related Features
11
Related Features
Prerequisite Features
None
Mutually Exclusive Features

None
Impacted Features
None

49
SingleRAN
12 Network Impact
12
Network Impact
System Capacity
None
Network Performance
None

50
SingleRAN
13
13 Engineering Guidelines
Engineering Guidelines
13.1 When to Use Operation & Maintenance System OneKey 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.
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
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

51
SingleRAN
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

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

53
SingleRAN
15 Counters
15
Counters
Table 15-1 Counter description

Counter ID
Counter Name
Counter
Description
NE
Feature ID
Feature Name
67194469
VS.SDH.SWAP
.REASON.REQ
UEST.COUNT
S
T7041:Number
of SDH Port
Switchovers on
Conditional
Requests
BSC6900
MRFD-210101
System
Redundancy
67194470
VS.SDH.SWAP
.REASON.KBY
TE.COUNTS
T7042:Number
of SDH Port
Switchovers on
K byte Requests
BSC6900
MRFD-210101
System
Redundancy
67194471
VS.SDH.SWAP
.REASON.EXT
ERNAL.COUN
TS
T7043:Number
of SDH Port
Switchovers on
external
Requests
BSC6900
MRFD-210101
System
Redundancy
67194472
VS.SDH.FAUL
T.CHANNEL.P
ROTECT.COU
NTS
T7044:Number
of SDH
Protection
Channel
Failures
BSC6900
MRFD-210101
System
Redundancy
67194473
VS.SDH.FAUL
T.CHANNEL.
WORK.COUN
TS
T7045:Number
of SDH
Working
Channel
Failures
BSC6900
MRFD-210101
System
Redundancy
73436939
VS.Frame.Flux.
Peak.TxRate
HR9732a:Peak
Inter-Subrack
Transmitting
Traffic
BSC6900
MRFD-210104
BSC/RNC
Resource
Sharing

54
SingleRAN
15 Counters
Counter ID
Counter Name
Counter
Description
NE
Feature ID
Feature Name
73436941
VS.Frame.Flux.
Mean.TxRate
AR9732a:Avera
ge Inter-Subrack
Transmitting
Traffic
BSC6900
MRFD-210104
BSC/RNC
Resource
Sharing
73441493
VS.Frame.Flux.
DropPackets
R9732a:Numbe
r of Discarded
Inter-Subrack
Packets
BSC6900
MRFD-210104
BSC/RNC
Resource
Sharing
73441494
VS.Frame.Flux.
TxPackets
R9732b:Numbe
r of Sent InterSubrack Packets
BSC6900
MRFD-210104
BSC/RNC
Resource
Sharing
67194469
VS.SDH.SWAP
.REASON.REQ
UEST.COUNT
S
T7041:Number
of SDH Port
Switchovers on
Conditional
Requests
BSC6910
MRFD-210101
System
Redundancy
67194470
VS.SDH.SWAP
.REASON.KBY
TE.COUNTS
T7042:Number
of SDH Port
Switchovers on
K byte Requests
BSC6910
MRFD-210101
System
Redundancy
67194471
VS.SDH.SWAP
.REASON.EXT
ERNAL.COUN
TS
T7043:Number
of SDH Port
Switchovers on
external
Requests
BSC6910
MRFD-210101
System
Redundancy
67194472
VS.SDH.FAUL
T.CHANNEL.P
ROTECT.COU
NTS
T7044:Number
of SDH
Protection
Channel
Failures
BSC6910
MRFD-210101
System
Redundancy
67194473
VS.SDH.FAUL
T.CHANNEL.
WORK.COUN
TS
T7045:Number
of SDH
Working
Channel
Failures
BSC6910
MRFD-210101
System
Redundancy
73436939
VS.Frame.Flux.
Peak.TxRate
HR9732a:Peak
Inter-Subrack
Transmitting
Traffic
BSC6910
MRFD-210104
BSC/RNC
Resource
Sharing

55
SingleRAN
15 Counters
Counter ID
Counter Name
Counter
Description
NE
Feature ID
Feature Name
73436941
VS.Frame.Flux.
Mean.TxRate
AR9732a:Avera
ge Inter-Subrack
Transmitting
Traffic
BSC6910
MRFD-210104
BSC/RNC
Resource
Sharing
73441493
VS.Frame.Flux.
DropPackets
R9732a:Numbe
r of Discarded
Inter-Subrack
Packets
BSC6910
MRFD-210104
BSC/RNC
Resource
Sharing
73441494
VS.Frame.Flux.
TxPackets
R9732b:Numbe
r of Sent InterSubrack Packets
BSC6910
MRFD-210104
BSC/RNC
Resource
Sharing

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

57
SingleRAN
17
17 Reference Documents
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

58

Base Station Controller Equipment Reliability (SRAN9.0 - Draft A)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Base Station Controller Equipment Reliability (SRAN9.0 - Draft A)

Uploaded by

Copyright:

Available Formats

SingleRAN

Base Station Controller Equipment

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Issue Draft A (2014-01-20)

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

6.3 BSC Node Redundancy................................................................................................................................................26

9 Operation and Maintenance Reliability.................................................................................41

Huawei Proprietary and Confidential

Issue Draft A (2014-01-20)

Huawei Proprietary and Confidential

1 About This Document

About This Document

1.2 Intended Audience

Need to understand the features described herein

Work with Huawei products

1.3 Change History

Issue Draft A (2014-01-20)

Huawei Proprietary and Confidential

Decreasing the number of accidents

Minimizing the scope of fault influence

Shortening the duration of service interruption

Controller reliability designs include system availability, planned service interruption,

Issue Draft A (2014-01-20)

Huawei Proprietary and Confidential

For details about

For details, see 5.2

For details, see 5.3

For details about

For details about

Issue Draft A (2014-01-20)

Huawei Proprietary and Confidential

Issue Draft A (2014-01-20)

For details about

For details about

For details about

For details about

For details about

Huawei Proprietary and Confidential

For details about

For details about

For details about

Issue Draft A (2014-01-20)

Huawei Proprietary and Confidential

For details, see 9

For details, see 10

Issue Draft A (2014-01-20)

Huawei Proprietary and Confidential

Table 3-1 Reliability specifications

Mean time between failures (MTBF)

Mean time to repair (MTTR)

Issue Draft A (2014-01-20)

Huawei Proprietary and Confidential

4 Planned Service Interruption

Planned Service Interruption

4.2 BSC/RNC Software Management

Querying the software version and its status

Huawei Proprietary and Confidential