Base Station Controller Equipment Reliability(SRAN9.0_Draft a)

SingleRAN

Base Station Controller EquipmentReliability Feature ParameterDescription

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 writtenconsent 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. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase 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 representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue Draft A (2014-01-20) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://www.huawei.com

mailto:[email protected]

Contents

1 About This Document..................................................................................................................11.1 Scope..............................................................................................................................................................................11.2 Intended Audience..........................................................................................................................................................11.3 Change History...............................................................................................................................................................1

2 Overview.........................................................................................................................................22.1 Introduction....................................................................................................................................................................22.2 Benefits...........................................................................................................................................................................22.3 Architecture....................................................................................................................................................................2

3 Reliability Specifications.............................................................................................................7

4 Planned Service Interruption......................................................................................................84.1 Overview........................................................................................................................................................................84.2 BSC/RNC Software Management..................................................................................................................................8

5 Redundancy Design....................................................................................................................115.1 Overview......................................................................................................................................................................115.2 RNC Redundancy Design.............................................................................................................................................125.2.1 Resource Management Plane.....................................................................................................................................125.2.2 Control plane.............................................................................................................................................................125.2.3 User Plane..................................................................................................................................................................145.2.4 Transport Plane..........................................................................................................................................................145.3 BSC Redundancy Design.............................................................................................................................................155.3.1 Resource Management Plane.....................................................................................................................................165.3.2 Control Plane.............................................................................................................................................................165.3.3 User Plane..................................................................................................................................................................185.3.4 Transport Plane..........................................................................................................................................................195.4 NewNode......................................................................................................................................................................20

6 Network Redundancy.................................................................................................................226.1 RNC in Pool..................................................................................................................................................................226.1.1 Overview...................................................................................................................................................................226.1.2 Benefits......................................................................................................................................................................236.2 RNC Node Redundancy...............................................................................................................................................24

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description Contents


ii

6.3 BSC Node Redundancy................................................................................................................................................266.3.1 Overview...................................................................................................................................................................266.3.2 Benefits......................................................................................................................................................................276.4 MSC Pool.....................................................................................................................................................................286.5 SGSN Pool....................................................................................................................................................................296.6 TC Pool.........................................................................................................................................................................29

7 Fault Management.......................................................................................................................307.1 Fault Management Architecture...................................................................................................................................307.1.1 NEL...........................................................................................................................................................................307.1.2 EML...........................................................................................................................................................................317.1.3 NML..........................................................................................................................................................................327.2 NE Fault Management..................................................................................................................................................32

8 Flow Control.................................................................................................................................368.1 RNC Flow Control........................................................................................................................................................368.1.1 Overview...................................................................................................................................................................368.1.2 Panorama...................................................................................................................................................................368.1.3 E2E Flow Control......................................................................................................................................................388.2 BSC Flow Control........................................................................................................................................................398.2.1 Overview...................................................................................................................................................................398.2.2 Panorama...................................................................................................................................................................39

9 Operation and Maintenance Reliability.................................................................................419.1 Overview......................................................................................................................................................................419.2 Technical Description...................................................................................................................................................41

10 Hardware Reliability................................................................................................................4510.1 BSC/RNC Board Redundancy....................................................................................................................................4610.1.1 BSC6910 Board Redundancy..................................................................................................................................4610.1.2 BSC6900 Board Redundancy..................................................................................................................................47

11 Related Features.........................................................................................................................49

12 Network Impact.........................................................................................................................50

13 Engineering Guidelines...........................................................................................................5113.1 When to Use Operation & Maintenance System One-Key Recovery........................................................................5113.2 Deployment................................................................................................................................................................5113.2.1 Process.....................................................................................................................................................................5113.2.2 Requirements...........................................................................................................................................................5113.2.3 Activation................................................................................................................................................................5113.2.4 Activation Observation............................................................................................................................................5213.2.5 Deactivation.............................................................................................................................................................5213.3 Performance Monitoring.............................................................................................................................................5213.4 Troubleshooting..........................................................................................................................................................52



iii

14 Parameters...................................................................................................................................53

15 Counters......................................................................................................................................54

16 Glossary.......................................................................................................................................57

17 Reference Documents...............................................................................................................58



iv

1 About This Document

1.1 ScopeThis document describes the Base Station Controller Equipment Reliability feature, includingits technical principles, related features, network impact, and engineering guidelines.

1.2 Intended AudienceThis document is intended for personnel who:

l Need to understand the features described hereinl Work with Huawei products

1.3 Change HistoryThis section provides information about the changes in different document versions. There aretwo 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

Draft A (2014-01-20)This is a new document for SRAN9.0.

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 1 About This Document


1

2 Overview

2.1 IntroductionReliability designs enable the controller to continue providing services even when it experiencesa fault, thereby maintaining high system reliability. Objectives of reliability include:

l Decreasing the number of accidentsl Minimizing the scope of fault influencel Shortening the duration of service interruption

Controller reliability designs include system availability, planned service interruption,redundancy design, network redundancy, fault management, flow control, operation andmaintenance reliability, and hardware reliability.

2.2 BenefitsReliability designs, which include redundancy design and hardware reliability design, eliminateor reduce the impact of equipment faults on services, thereby improving system reliability.

2.3 ArchitectureTable 1 lists the controller equipment reliability-related features and functions that are supportedby GSM and UMTS.

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 2 Overview


2

Table 2-1 Controller equipment reliability-related features and functions that are supported byGSM and UMTS

ReliabilityCategory

Feature/Function

RadioAccessTechnology

Feature ID/Feature Name

Remarks

Plannedserviceinterruption

BSC/RNCSoftwareManagement

GSM andUMTS

MRFD-210401BSC/RNCSoftwareManagement

For details aboutengineeringguidelines, seeOperation andMaintenance FeatureParameterDescription.

Redundancydesign

RNCRedundancy

UMTS None For details, see 5.2RNC RedundancyDesign.

BSCRedundancy

GSM None For details, see 5.3BSC RedundancyDesign.

BSC/RNCResourceSharing

GSM andUMTS

MRFD-210104BSC/RNCResource Sharing

For details aboutengineeringguidelines, seeController ResourceSharing FeatureParameterDescription inWCDMA RANdocuments.

Networkredundancy

RNC in Pool UMTS l WRFD-150211RNC in PoolLoad Sharing

l WRFD-150212RNC in PoolNodeRedundancy

l WRFD-150240RNC in PoolMultipleLogical RNCs

For details aboutengineeringguidelines, see RNC inPool FeatureParameterDescription inWCDMA RANdocuments.



3

ReliabilityCategory

Feature/Function



Remarks

RNC NodeRedundancy

UMTS WRFD-040202RNC NodeRedundancy

For details aboutengineeringguidelines, see RNCNode RedundancyFeature ParameterDescription inWCDMA RANdocuments.

BSC NodeRedundancy

GSM GBFD-113725BSC NodeRedundancy

For details aboutengineeringguidelines, see BSCNode RedundancyFeature ParameterDescription in GSMBSS documents.

MSC Pool GSM GBFD-117401MSC Pool

For details aboutengineeringguidelines, see MSCPool FeatureParameterDescription in GSMBSS documents.

SGSN Pool GSM GBFD-119701SGSN Pool

For details aboutengineeringguidelines, see SGSNPool FeatureParameterDescription in GSMBSS documents.

TC Pool GSM GBFD-113726 TCPool

For details aboutengineeringguidelines, see TCPool FeatureParameterDescription in GSMBSS documents.



4

ReliabilityCategory

Feature/Function



Remarks

Faultmanagement

FaultManagement

GSM andUMTS

MRFD-210304Fault Management

For details aboutengineeringguidelines, see FaultManagement FeatureParameterDescription inSingleRANdocuments.

Flow control RNC FlowControl

UMTS WRFD-040100Flow Control

For details aboutengineeringguidelines, see FlowControl FeatureParameterDescription inWCDMA RANdocuments.

BSC FlowControl

GSM l GBFD-111705GSM FlowControl

l GBFD-119117Flow Control onGb Interface

l GBFD-119116Packet UplinkFlow Control

l GBFD-511003Call-BasedFlow Control

l GBFD-115002Flow ControlBased on CellPriority

l GBFD-115003Flow ControlBased on UserPriority

For details aboutengineeringguidelines, see FlowControl FeatureParameterDescription in GSMBSS documents.

Operationandmaintenancereliability

OperationandMaintenance SystemOne-KeyRecovery

GSM andUMTS

GBFD-111214Operation &MaintenanceSystem One-KeyRecovery

For details, see 9Operation andMaintenanceReliability.



5

ReliabilityCategory

Feature/Function



Remarks

Hardwarereliability

BSC/RNCBoardRedundancy

GSM andUMTS

None For details, see 10HardwareReliability.



6

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

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 3 Reliability Specifications


7

4 Planned Service Interruption

4.1 OverviewPlanned service interruption aims to reduce the duration of service interruption caused byupgrades, minimize the impact of planned maintenance on live networks, and improveequipment 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 controllersoftware 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 programfiles and patch files between the FTP server and FTP client

l Using the controller as the transmission medium to transmit files between the U2000 andthe 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 softwareintegrity check after software loading and before software operation, and then completes digitalsignature verification.

The BSC/RNC is upgraded remotely by the dedicated upgrade tool, which consists of the upgradeclient and the upgrade server. Figure 4-1 shows the BSC/RNC remote upgrade process.

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 4 Planned Service Interruption


8

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 amajor 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 activeOMU.

Step 2 Conduct the pre-upgrade health check, backs up data and files, and upgrades the program anddata 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 standbyworkspace of the active OMU onto the standby workspaces of the FAM boards so that thestandby 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 theactive 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 hostprogram, BootROM, OS or data files are upgraded, the FAM boards are reset. When a cold patchis loaded to a type of FAM boards, only this type of FAM boards are reset and the boardsautomatically 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 ofthe standby OMU so that the standby OMU is upgraded to the latest version. After the workspaceswitchover is complete for the standby OMU, the standby OMU automatically synchronizes itsdata with the active OMU.

----End

Key SpecificationsTable 4-1 lists key specifications for BSC/RNC software management.



9

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

Index Version Implementation

Service interruption duration caused by anupgrade for a major release

Service interruption duration ≤ 3 min

Service interruption duration caused by apatch upgrade

No service interruption for a hot patchupgradeService interruption duration for a cold patchupgrade ≤ 3 min

Reloading time ≤ 7 min

Time from power-on to managementrecovery

≤ 10 min

Time from power-on to first NodeB recovery ≤ 10 min

Time from power-on to the recovery of allsites

≤ 12 min



10

5 Redundancy Design

5.1 OverviewThis section describes the MRFD-210101 System Redundancy feature and the GBFD-111701Board Switchover feature. System redundancy provides reliability designs that improve systemreliability. These designs include active/standby switchovers and load sharing.

Huawei base station controllers adopt reliability designs, such as load sharing and active/standbyswitchovers, 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 actsas 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 serviceoperations.

There are two types of switchovers:

– Automatic switchover: automatically triggered by the system if the active board isfaulty.

– Manual switchover: performed by maintenance personnel on the LMT. Maintenancepersonnel use the immediate switchover command to switch over the active and standbyboards.

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 isreset 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. Whenone or multiple processing units are faulty, new service requests are allocated to the normalprocessing units in the resource pool.

l Other reliability designs

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 5 Redundancy Design


11

Other reliability designs include the redundancy configuration of power and fan units. Inaddition, software versions and important data configuration files are backed up so that thesystem works normally even if an exception occurs in the software versions and files.

5.2 RNC Redundancy Design

5.2.1 Resource Management PlaneThe BSC6900 main processing unit (MPU) subsystems can be configured on multiple pairs ofSPU boards working in active/standby mode. The MPU subsystems manage transmissionresources 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, andtransport plane resources, and troubleshoots system faults.A pair of Resource Management Processing (RMP) boards perform the central layerfunctions.

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 CallAttempt (BHCA) or throughput. A sudden increase in the CPU usage is allowed within ashort period of time.

l A temporary fault in an RMP board does not interrupt ongoing services. This is becauseonly global resource scheduling is interrupted if an RMP board is faulty.

5.2.2 Control planeFor the BSC6900, the SPU boards, which work in active/standby mode, process control planedata.

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



12

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 differencesare as follows:

l A pair of BSC6900 active and standby control plane boards must be installed in adjacentslots.

l The BSC6910 control plane uses the process backup mechanism. All active CP processeson 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 UEinformation on the active subsystem are sent to the standby subsystem through the backupchannel. The standby subsystem then backs up the data. If the active subsystem is faulty, thestandby subsystem takes over services on the active subsystem to avoid service interruptions.

In addition to the redundancy design, the BSC6910 control plane also supports processpreemption. If a pair of active and standby CP processes of the BSC6910 are both faulty for acertain period of time (less than 5 minutes), the BSC6910 preempts another standby CP processto start the active CP process, thereby restoring services promptly.



13

5.2.3 User PlaneFor 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 inresource 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 subsystemare reestablished, and services are interrupted for less than 5 seconds and then restored. Duringthe service interruption, CS services are released, and PS services are interrupted and thenreconnected. The user-plane processing capability decreases, but the other functional user planesubsystems still work in resource pool mode.

The redundancy design is the same for the BSC6900 and BSC6910 user planes. Neither supportsuser-plane service backup.

5.2.4 Transport PlaneThe redundancy design is the same for the BSC6900 and BSC6910 transport planes. They bothsupport 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/standbyswitchover to reestablish the transmission links for the ongoing services on the standbyboard. 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 standbychannel.

l Port backup or load sharing

l Resource pool



14

In conclusion, the resource management plane, control plane, user plane, and transport plane allsupport the redundancy design. Therefore, the BSC6900 and BSC6910 do not experience a singlepoint of failure.

Table 5-1 describes the reliability indexes for transmission interface boards in differentscenarios.

Table 5-1 Reliability indexes for transmission interface boards in different scenarios

Scenario Availability AverageDowntime(Minute/Year)

QuantitativeReliabilityAnalysis

1+1 active/standbyredundancy

0.999999796 0.11 Low task reliabilityand low basicreliability under thesame traffic volume

1+1 active/standbyredundancy plusresource pool

0.999999918 0.04 High task reliabilityand low basicreliability under thesame traffic volume

Independent boardplus resource pool

0.999999183 0.43 Low task reliabilityand high basicreliability under thesame traffic volume

N+1 resource pool 0.999999836 0.09 High task reliabilityand high basicreliability under thesame traffic volume

Table 5-2 Key specifications of transmission redundancy


Switchover for interface boards The impact persists within 3s for stableservices.

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 precedingindexes. For example, if Link Aggregation Control Protocol (LACP) is enabled, the impact persists within9s for stable services in a switchover for interface boards.

5.3 BSC Redundancy Design



15

5.3.1 Resource Management PlaneThe BSC6900 MPU subsystems can be configured on multiple pairs of XPU boards working inactive/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, andtransport plane resources, and troubleshoots system faults.The BSC6900 is configured with a pair of EGPUa boards whose logical type is resourcemanagement processing (RMP). The EGPUa boards are responsible for managing globalresources 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) manageboard-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 followingcharacteristics:

l The CPU usage does not increase noticeably with the increase in the Busy Hour CallAttempt (BHCA) or throughput. A sudden increase in the CPU usage is allowed within ashort period of time.

l A temporary fault in an RMP board does not interrupt ongoing services. This is becauseonly global resource scheduling is interrupted if an RMP board is faulty.

5.3.2 Control PlaneFor the BSC6900, the XPU boards, which work in active/standby mode, process control planedata.

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



16

Figure 5-3 Control-plane redundancy design for the BSC6910

NOTE


The redundancy design is similar for the BSC6900 and BSC6910 control planes. The differencesare as follows:

l A pair of BSC6900 active and standby control plane boards must be installed in adjacentslots.

l The BSC6910 control plane uses the process backup mechanism. All active CP processeson an EGPUa board whose logical type is GCUP or GMCP have backups evenly distributedon 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 MSinformation on the active subsystem are sent to the standby subsystem through the backupchannel. The standby subsystem then backs up the data. If the active subsystem is faulty, thestandby subsystem takes over services on the active subsystem to avoid service interruptions.

In addition to the redundancy design, the BSC6910 control plane also supports processpreemption. If a pair of active and standby CP processes of the BSC6910 are both faulty for a



17

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

5.3.3 User PlaneFor 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 planedata. 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 andthen reconnected. The user-plane processing capability decreases, but the other functional userplane subsystems still work in resource pool mode.

The redundancy design is the same for the BSC6900 and BSC6910 user planes. Neither supportsuser-plane service backup.



18

5.3.4 Transport PlaneThe redundancy design is the same for the BSC6900 and BSC6910 transport planes. They bothsupport board redundancy, port backup/load sharing, and resource pool mode.

A transport interface board supports the following:

l 1+1 active/standby redundancyWhen detecting that an interface board is faulty, the system performs an active/standbyswitchover to reestablish the transmission links for the ongoing services on the standbyboard. 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 standbychannel.

l Port backup or load sharingl Resource pool

In conclusion, the resource management plane, control plane, user plane, and transport plane allsupport the redundancy design. Therefore, the BSC6900 and BSC6910 do not experience a singlepoint of failure.

Table 5-3 describes the reliability indexes for transmission interface boards in differentscenarios.

Table 5-3 Reliability indexes for transmission interface boards in different scenarios

Scenario Availability AverageDowntime(Minute/Year)

QuantitativeReliabilityAnalysis

1+1 active/standbyredundancy

0.999999796 0.11 Low taskreliability and lowbasic reliabilityunder the sametraffic volume

1+1 active/standbyredundancy plus resourcepool

0.999999918 0.04 High taskreliability and lowbasic reliabilityunder the sametraffic volume

Independent board plusresource pool

0.999999183 0.43 Low taskreliability and highbasic reliabilityunder the sametraffic volume

N+1 resource pool 0.999999836 0.09 High taskreliability and highbasic reliabilityunder the sametraffic volume



19

Table 5-4 Key specifications of transmission redundancy


Switchover for interface boards The impact persists within 3s for stableservices.

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 precedingindexes. For example, if Link Aggregation Control Protocol (LACP) is enabled, the impact persists within9s for stable services in a switchover for interface boards.

5.4 NewNodeThis section describes the MRFD-210104 BSC/RNC Resource Sharing feature. For details aboutthe 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 CPUusage 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 processingunits 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 planeand user plane based on service requirements. These adjustments improve hardware utilizationby balancing the control-plane and user-plane processing capabilities.

The BSC6910 introduces a new service processing board: GPU. The GPU board cansimultaneously 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 planeproportionately. For details, see the RNC User Plane and Control Plane Resource SharingParameter 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. Whenconfiguring a base station or cell on the BSC6910, telecom operators do not need to specify thesubrack, slot, or subsystem. In addition, the BSC6910 monitors the distribution of base stationsand cells on the EGPUa boards. When EGPUa boards experience a load imbalance because thereare hotspot base stations or cells, the BSC6910 adjusts the distribution of base stations or cellson the EGPUa boards to achieve load balancing.



20

Dynamic reallocation of cells can be performed during peak hours, whereas dynamic reallocationof base stations must be performed during off-peak hours. During cell reallocation, UEs in theCELL_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 stationexperience call drops. Operators can schedule the time for base station reallocation. For details,see Controller Resource Sharing Feature Parameter Description.



21

6 Network Redundancy

6.1 RNC in PoolThis section describes the RNC in Pool feature. For details, see RNC in Pool Feature ParameterDescription.

6.1.1 OverviewThe rapid development of mobile internet brings fast service growth, which requires sustainablenetwork capacity expansion and high reliability of the RNC. New technologies need to beintroduced in network planning and deployment to ensure network reliability.

The existing technique for RNC capacity expansion requires an RNC to be split if the RNCcannot accommodate any additional hardware. RNC splitting, however, makes networkreconstruction more difficult, which may affect services on the live network and decreasenetwork reliability. When an RNC becomes faulty, all NodeBs under it go out of service. Thiscan cause huge losses for operators.

RNC in Pool is an ideal solution for smooth RNC capacity expansion without compromisingnetwork reliability. With this feature, interconnected RNCs form a resource pool over Iur-p, aHuawei-proprietary interface. Figure 6-1 shows the network architecture for RNC in Pool.

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 6 Network Redundancy


22

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 SharingThis feature allows load sharing between existing RNCs and another RNC added forcapacity expansion.

l WRFD-150212 RNC in Pool Node RedundancyThis feature prevents an RNC failure from causing a massive service interruption.

l WRFD-150240 RNC in Pool Multiple Logical RNCsThis feature allows multiple logical RNCs to be configured on a BSC6910 to implementload 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 doesnot support this feature.

You can enable the first or second feature above or both. The third feature, however, can onlybe enabled when one of the other features or both are also enabled.

6.1.2 BenefitsThe 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 nolonger requires RNC splitting or NodeB reparenting.Figure 6-2 shows a comparison betweencapacity expansion using existing techniques and using RNC in Pool.



23

Figure 6-2 Comparison between capacity expansion using existing techniques and using RNCin Pool

l Traffic balancing between RNCs for signaling burstsWith load balancing, the signaling bursts of an RNC can be processed by idle hardwareresources of another RNC in a pool, which increases the hardware resource utilization.

l Improved system reliabilityNode redundancy provided by RNC in Pool allows a backup RNC to take over services ofa faulty RNC. The redundancy technique enables fast service resumption and improvessystem reliability.

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



24

In a traditional WCDMA RAN, one NodeB is connected to only one RNC. The RNC controlsthe 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 setupfor 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. Inthis case, the RNS cannot provide radio access service in the coverage area.

Recent technological improvements allow the RNC to provide increasingly higher capacity tomeet 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 wholeRNS. To increase reliability, Huawei provides an RNC node redundancy solution. If one RNCfails, 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+1backup 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 towardstwo 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, theprimary RNC serves as the controlling RNC (CRNC) of the NodeB. When the primary RNCfails, 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, whereearthquakes 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 areaA, 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. Innormal situations, both RNCs provide services and the equipment can be fully utilized. Whenone of the RNCs fails, the other automatically takes over all the dual-homed NodeBs to protectthe NodeBs from being out of service.



25

6.3 BSC Node RedundancyThis section describes the GBFD-113725 BSC Node Redundancy feature. For details, see BSCNode Redundancy Feature Parameter Description.

6.3.1 OverviewIn traditional wireless networks, each BTS connects to only one BSC. If a BSC fails or all thesignaling links on the A interface are disconnected, the BSC cannot provide services and theBTSs served by the BSC cannot access the network. To ensure service continuity in the eventof 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-IPnetworking mode, where the A, Abis, and inter-BSC interfaces all use IP transmission. TwoBSCs in a redundancy group work in 1+1 backup mode. If one BSC fails or all the signalinglinks on the A interface of one BSC are disconnected, the other BSC takes over the services fromthe failed BSC. Figure 6-4 shows the networking diagram of two BSCs working in a redundancygroup.



26

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 peerBSC. To enable or disable this feature on the local and peer BSCs, set RedundancyMode to anappropriate value.

LocalBSCID and PeerBSCID specify the local and peer BSCs, respectively, in a redundancygroup. GROUPINDEX specifies a redundancy group.

6.3.2 BenefitsThis 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 otherBSC immediately takes over services from the failed BSC.



27

l More reliable transmission

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

6.4 MSC PoolThis section describes the GBFD-117401 MSC Pool feature. For details, see MSC Pool FeatureParameter Description.

An MSC pool consists of a group of MSCs handling the traffic generated from one MSC poolarea. A BSC belonging to an MSC pool is connected to each MSC in the MSC pool. Withresource 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 atthe same time. The traffic from the BSC is evenly distributed to the MSCs in the MSC poolbased 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 MSCpool area consists of several LAs. If different pool areas overlap each other, one LA can belongto more than one pool area. Within a pool area, an MS may roam without the need to change theserving MSC. The pool area is served by one or more MSCs in parallel. For example, the callsin LA 1 can be evenly distributed to MSC 1, MSC 2, and MSC 3. A call made by a roaming MSwithin 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 followingadvantages:



28

l All the MSCs in an MSC pool implement load balancing and resource sharing, increasingnetwork 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 MSCpool, the existing network architecture does not need to be adjusted. This helps implementMSC node redundancy and improve network reliability.

l Logically, all the MSCs in one MSC pool are regarded as one MSC. Therefore, inter-MSChandovers and the signaling between the MSCs and the Home Location Registers (HLRs)decrease, and the entire network performance is improved.

6.5 SGSN PoolThis section describes the GBFD-119701 SGSN Pool feature. For details, see SGSN PoolFeature Parameter Description.

6.6 TC PoolThis section describes the GBFD-113726 TC Pool feature. For details, see TC Pool FeatureParameter Description.



29

7 Fault Management

7.1 Fault Management Architecture

7.1.1 NELThe NEL is where most alarms are generated. Most of these alarms are generated from maindevices of the NEs and peripherals, such as the environment monitoring device. The NEs mainlyinclude the base station controllers and base stations.

After detecting exceptions, an NE device first filters and judges them based on preset rules. Theexceptions 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 automationdevices, alarms are reported.

Figure 7-1 shows implementation of fault management on the NEL, using Huawei multi-modebase 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

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 7 Fault Management


30

l GE switching network and control unit (SCU) boardsl Service processing boardsl Monitoring devices

The OMU collects information about faults detected on the preceding devices, configures themapping and correlation for alarms and events, and post-processes the faults before reportingalarms to the U2000.

7.1.2 EMLA device vendor generally provides the EML, for example, the Huawei iManager U2000, tomanage the NEs of the device vendor. On certain EMLs, devices of multiple vendors can bemanaged.

On the EML, alarms are received, stored, and filtered. Alarms are dispatched through thenorthbound interface.

Figure 7-2 shows implementation of fault management on the EML, using Huawei iManagerU2000 as an example. Fault management of the U2000 involves alarm/event setting, alarm/eventreporting, and alarm/event notification.

Figure 7-2 Fault management of the U2000



31

7.1.3 NMLIn normal cases, telecom operators centrally manage their devices on the network managementlayer (NML) by using an NMS. The devices are deployed on various networks, such as the radioaccess network (RAN), core network, and transport network. The NMS is generally developedand managed by telecom operators themselves. The NMS manages the devices of differentvendors 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 workorders for these alarms.

7.2 NE Fault ManagementFault management provides the following basic functions:

l Fault detectionAfter detecting faults, a fault detection unit reports the faults to the fault managementmodule. Then, the fault management system reports alarms for these faults to the U2000or local maintenance terminal (LMT) after processing the faults on each layer. Faultdetection 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 collectionFault collection is the most important external interface of fault management. It collectsfaults reported by fault detection units and processes in a centralized manner.

l Duplicate fault filtering, fault transient rule, and fault toggle ruleThere are two filtering stages: primary filter and secondary filter. In the primary filter, faultdetection 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 ruleFaults or alarms of short duration can be filtered based on the alarm or fault generationdelay. Only the faults or alarms whose duration exceeds the threshold of the generationdelay 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 delaythreshold T, so fault 1 or alarm 1 is discarded. The duration of fault 2 or alarm 2 is longerthan T, so alarm 2 or an alarm for fault 2 can be reported.



32

Figure 7-3 Principles of the transient rule

– Toggle ruleThe 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 arefiltered using the toggle rule. After that, one fault and an alarm for the fault are reserved, andalarms for other duplicate faults are filtered. The fault detection units determine oscillationtermination conditions once oscillation starts. If the number of duplicate faults is within thethreshold in T2, the oscillation ends, which means that the fault does not occur.

l Fault troubleshootingFault troubleshooting involves device status switchover, fault isolation, and automatic faultrectification. Base stations and controllers filter faults and automatically rectify them basedon 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, alarmsare reported.

l Alarm mappingAlarm mapping is one of the core processes in fault management and aims to isolate faultinformation from the alarms reported to users. Alarms presented to users are in a uniformformat and easy to understand. Alarm mapping forces faults to map reported alarms. Faultsand events occur in the system and involve system details. Alarms provide fault analysisresults and are displayed in a uniform and simple format. You can rectify faults based onalarms. Rather than obtaining system details, you only need to locate the units where faultsoccur and that can be replaced or modified.

l Alarm box managementAlarm box management provides functions, such as specifying the severity of alarms to bereported to the alarm box, resetting the alarm box, and querying the alarm box version.



33

After you specify concerned alarms to be reported to an alarm box, the alarm box providesaudible and visual notifications for you to rectify faults in a timely manner.

l Alarm correlationAlarm correlation is one of the core processes in fault management. This function filtersout non-root faults and presents root faults to users. A root fault generally triggers multiplecorrelative faults. If alarm correlation is not performed, multiple alarms are reported, whichaffects fault location.Certain critical alarms, such as service-related alarms, cannot be masked based on alarmcorrelation even if the critical alarms are generated for correlative faults that includephysical device faults or data transmission faults. These alarms carry the serial numbers oftheir root alarms. In this way, the U2000 can present alarm correlations to maintenancepersonnel for fast fault location and troubleshooting.

l Supporting common alarms in the SingleRAN solutionIn a GSM/UMTS dual-mode base station, if two common alarms with the same informationare detected and the alarms are for GSM and UMTS, respectively, an alarm for only oneRAT can be displayed. This prevents redundant work order dispatches. The RAT displayedin the alarm varies according to the multi-RAT priority settings.

l Alarm synchronization between a base station and the U2000Alarm synchronization between a base station and the U2000 consists of two stages:

– Alarm synchronization between the base station and the controller: The controllerqueries active alarms from the base station, issues a command to the base station tocheck for alarms that have not been synchronized, and updates alarm records on thecontroller based on the check result.

– Alarm synchronization between the controller and the U2000.

l Alarm severity changeBased on 3GPP specifications, the severity of an uncleared alarm can be changed. Afterthe severity is changed, an alarm severity change message is reported.

l User-defined alarmsBase stations and controllers can be connected to external environment monitoring devicesto 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 relatedto 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 candynamically monitor the environment and devices.

l Alarm maskingWith this function, you can mask specified alarms by alarm ID or object.

– Masking alarms by alarm IDIf Shielded Flag of a specified alarm ID is set to Shielded, all the active alarms of thealarm ID are cleared. During alarm masking, the specified alarm will not be reportedeven 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 objectYou can mask a specified alarm or all alarms for a certain board, port, or digital signalprocessor (DSP), or mask a specified alarm for all objects.

l Fault log



34

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



35

8 Flow Control

8.1 RNC Flow Control

8.1.1 OverviewFlow control is a protective measure for communications between the RNC and its peerequipment. 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 PanoramaDuring mass gathering events, the traffic volume may exceed the processing capability of thesystem. As a result, the system becomes overloaded, which may lead to messages being randomlydiscarded and NE resetting, as well as response failures, call drops, service access failures, andother 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 memoryl Air interface resources, including channels, codes, and powerl Transmission resourcesl Core network processing capabilities

To keep system stability and capabilities at the maximum possible level, Huawei RNCs performflow control at four points in the system, which are numbered inFigure 8-1.

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 8 Flow Control


36

Figure 8-1 Four points in flow control

Flow control involves discarding originating messages (such as RRC connection requests) thatoverload the system when system resources are insufficient, refusing to process low-priorityservices, and rejecting access requests for low-priority services.

l To address problems caused by limited RNC resources (labeled 1 in Figure 8-1), the RNCperforms flow control for RNC units. The software of each RNC board monitors the systemresource usage. When necessary, the RNC starts basic flow control functions that suspendnon-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 performsother 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), theRNC performs call attempt per second (CAPS) control, PCH congestion control, and FACHcongestion 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 byCAPS control.

– When the paging channel is congested, the RNC allows CS-domain paging messagesto preempt PS-domain paging messages in order to raise the paging success rate in theCS domain.

– When the forward access channel (FACH) is congested, the RNC restricts messageretransmissions on the logical channels, rejects certain PS service requests, and triggersstate 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 CSservices, keeps a high cell update success rate, and reduces call drops.The RNC performs admission control, load reshuffling, and overload control on codeand power resources. For details about admission control, see Call Admission ControlFeature Parameter Description. For details about load reshuffling and overload control,see Load Control Feature Parameter Description and Overload Control FeatureParameter Description.

l To address problems caused by limited signaling bandwidth over the Iu interface (labeled3 in Figure 8-1), the RNC works with the core network to perform flow control over the Iuinterface. Based on link congestion conditions detected at the local end and congestion



37

indications reported from the peer end, the RNC performs flow control on initial directtransfer messages to reduce the signaling traffic over the Iu interface. This prevents severecongestion on the signaling link between the RNC and the core network and also reducesthe 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 Iubinterface. Specifically, the RNC restricts the data transmission rates when there istransmission congestion over the Iub interface. This prevents packet loss and makes moreefficient use of the bandwidth.

For RRC connection requests, the RNC supports control-plane load sharing and user-plane loadsharing. This achieves dynamic resource sharing, balances the load among subracks and boards,and improves RNC service processing efficiency. For details, see Controller Resource SharingFeature Parameter Description.

NOTE

The BSC6910 inherits the flow control function from the BSC6900. The only difference is in the RNCunits that flow control works on. Unless otherwise stated, the following descriptions apply to both theBSC6900 and BSC6910.

8.1.3 E2E Flow ControlE2E Flow Control protects NEs in a RAN from being overloaded. The NEs that participate inflow control are the RNC and NodeB.

Without E2E flow control, when the CPU of the baseband board or WMPT is congested oroverloaded, or when the cell power is congested, the RNC will not know. Therefore, the RNCcontinues to admit a large number of RRC CONNECTION REQUEST messages and sendRADIO LINK SETUP REQUEST messages to the NodeB over the Iub interface even when theNodeB is congested or overloaded. In this case, the NodeB should reject or discard these RADIOLINK SETUP REQUEST messages, which lower the cell resource utilization. In addition, theaccess of high-priority services cannot be guaranteed because the NodeB is unaware of theservice priority of each message. To address these issues, Huawei has introduced the followingE2E 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 stableoperation 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 ParameterDescription. Compared with flow control performed on a single NE, E2E Flow Control has thefollowing benefits:

l More reference information is provided for flow control because of cooperation betweenNEs. For example, if the RNC provides service priority information for the NodeB, theNodeB can implement differentiated flow control based on service priorities topreferentially ensure the access of high-priority services.

l Better flow control effects can be achieved because of cooperation between NEs. In E2EFlow Control Phase 2, the RNC performs flow control on RRC CONNECTION REQUEST



38

messages, and the NodeB performs flow control on RADIO LINK SETUP REQUESTmessages. Consequently, if the NodeB is overloaded, the RNC reduces the number ofunnecessary RRC CONNECTION REQUEST messages to be processed. This actionreduces 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 ParameterDescription.

8.2 BSC Flow Control

8.2.1 OverviewThis section briefly describes how BSC flow control works. Flow control includes BSC flowcontrol, BTS/cell service flow control, interface signaling flow control, flow control based onuser priority, and load sharing. For details on the related features, network impacts andengineering guidelines, see Flow Control Feature Parameter Description

8.2.2 PanoramaDuring base station subsystem (BSS) construction, the system capacity is planned according tothe estimated traffic volume in the coverage areas. When the traffic volume is lower than orequal to the planned capacity, the BSS can process services properly. However, in certainsituations, such as major events or disasters, the traffic volume surges and sometimes exceedsthe 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 controlat the six points marked in Figure 8-2. Flow control enables Huawei BSS to discard certainmessages, such as random access requests, and to reject low-priority services if system resourcesare insufficient.

Figure 8-2 Flow control points numbered 1 through 6

The flow control points are described as follows:



39

l BSC: Base station controller (BSC) flow control is introduced to address BSC resourceinsufficiency. BSC boards monitor the system resource usage in real time and stop somefunctions, 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-interface resource insufficiency.

l Abis interface: Flow control based on the message arrival rate, flow control based on LAPDsignaling links, and flow control based on the call type are introduced to address Abis-interface resource insufficiency.

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) flowcontrol are introduced to address Gb-interface insufficiency. BSSGP refers to Base StationSubsystem GPRS Protocol. The SGSN adjusts the downlink data rates for cells and MSsbased on their maximum packet switched (PS) data volumes and the data transfer ratereported by the BSC.

Huawei BSS introduces flow control based on user priorities. In addition, control-plane loadsharing and user-plane load sharing are introduced to process random access requests. Thisachieves dynamic resource sharing, balances the load among subracks and boards, and improvesBSC service processing efficiency.



40

9 Operation and Maintenance Reliability

9.1 OverviewThe Operation & Maintenance System One-Key Recovery feature reduces the complexity ofthe 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 & maintenanceoperations. This feature is applicable only to the DOPRA Linux OS and mainly used in thefollowing 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 Linuxto DOPRA Linux.

9.2 Technical DescriptionThis section describes how to implement the Operation & Maintenance System One-KeyRecovery feature.

Scheme 1

The USB creator is used to create the USB disk for installing the DOPRA Linux OS and theOMU 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 theOMU board are recovered.

Note that the OS, OMU applications, and the respective configuration information must be storedonto the USB installation disk during the creation of the USB installation disk. Then, Bootstrapscripts are generated on the USB installation disk to facilitate the start-up of the OMU boardthrough the USB installation disk.

The Bootstrap scripts first install the DOPRA Linux OS and configure the information for theOS. Then, the Bootstrap scripts install the OMU applications and configure the information forthe OMU applications. Figure 9-1 shows the OMU board software recovery process.

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 9 Operation and Maintenance Reliability


41

Figure 9-1 OMU board software recovery process

When the OS on the existing OMU boards is switched from non-DOPRA Linux to DOPRALinux, the USB creator is used to obtain the configuration information, especially the networkconfiguration information, the OMU applications configuration information, and the NEconfirmation information, of the OMU board whose OS is to be switched. Based on theinformation obtained, the USB creator creates a USB installation disk for installing the DOPRALinux OS. The USB installation disk is plugged into the USB port on the OMU board. The OMUboard is then reset. Five to ten minutes later, the switchover of the OS is complete.



42

Scheme 2

When OMU hardware is not damaged, the files are backed up through the existing OS on theOMU board. In this way, users can recover the OMU OS without using an external storagemedium.

Before recovering the OMU OS, connect a keyboard and a monitor to the OMU board and thenreset the OMU board. When the system boot menu is displayed, select the system recovery optionusing the keyboard. The OMU board starts to install the DOPRA Linux OS automatically. Fiveto ten minutes later, the OS on the OMU board is recovered. Figure 9-2 shows the OS recoveryprocess 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 defaultOS and does not perform OS recovery.



43

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



44

10 Hardware Reliability

For the acronyms, abbreviations, terms, and definitions, see the Glossary.

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 10 Hardware Reliability


45

10.1 BSC/RNC Board Redundancy

10.1.1 BSC6910 Board RedundancyBSC6910 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 fora specified period of time, the BSC6910 resets the interface board. If the faulty board is the active one ina 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 boardare 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 setupsuccess 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, theproportion of NodeBs having such cells reaches a predefined NodeB threshold, and this situationpersists for a specified period of time.

l If the BSC6910 detects any transmission fault, the BSC6910 reports an alarm instead of resetting theinterface board.

l Backup of AOUc/UOIc/POUc boards

When two AOUc/UOIc/POUc boards are installed in adjacent active and standby slots ina BSC6910 subrack, the two boards can be configured to work in board backup or opticalport backup mode.

l Resource pool of DPUf boards

The DPUf boards of the BSC6910 and the GUPTC subsystem of each DPUf work inresource pool mode.

l Backup of EXOUa/FG2c/GOUc/FG2d/GOUd boards

When two EXOUa/FG2c/GOUc/FG2d/GOUd boards are installed in adjacent active andstandby slots in a BSC6910 subrack, the two boards can be configured to work in boardbackup 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 ineach 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 activeand 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 BSC6910MPS, 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.



46

l Resource pool and board backup of EGPUa/EXPUa boards

The EGPUa board provides the following logical functions: RMP for resourcemanagement, UCUP for UMTS service processing, and GCUP for GSM serviceprocessing. The EXPUa board provides the function of GSM service processing. Theredundancy mode of the EGPUa/EXPUa board varies depending on its logical type.

10.1.2 BSC6900 Board RedundancyBSC6900 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 fora specified period of time, the BSC6900 resets the interface board. If the faulty board is the active one ina 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 boardare 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 setupsuccess 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, theproportion of NodeBs having such cells reaches a predefined NodeB threshold, and this situationpersists for a specified period of time.

l If the BSC6900 detects any transmission fault, the BSC6900 reports an alarm instead of resetting theinterface board.

l Backup of AEUa boards

When two AEUa boards are configured in adjacent active and standby slots in a BSC6900subrack, 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 aBSC6900 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 aBSC6900 subrack, the two boards can be configured to work in board backup mode.

l Backup of PEUa/PEUc boards

When two PEUa/PEUc boards are configured in adjacent active and standby slots in aBSC6900 subrack, the two boards can be configured to work in board backup mode.

l Backup of SCUa/SCUb boards

The BSC6900 is configured with two SCUa/SCUb boards in adjacent active and standbyslots 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 standbyslots in some subracks. The two boards work in board backup mode.

l Backup of AOUa/AOUc boards



47

When two AOUa/AOUc boards are configured in adjacent active and standby slots in aBSC6900 subrack, the two boards can be configured to work in board backup mode oroptical port backup mode.

l Backup of FG2a/FG2c/FG2d boardsWhen two FG2a/FG2c/FG2d boards are configured in adjacent active and standby slots ina BSC6900 subrack, the two boards can be configured to work in either of the followingmodes: board backup with no port backup and board backup with port backup.

l Backup of GCUa/GCUb/GCGa/GCGb boardsThe BSC6900 is configured with two GCUa/GCUb/GCGa/GCGb boards in adjacent activeand standby slots in the MPS. The two boards work in board backup mode.

l Backup of GOUa/GOUc/GOUd boardsWhen two GOUa/GOUc/GOUd boards are configured in adjacent active and standby slotsin a BSC6900 subrack, the two boards can be configured to work in either of the followingmodes: board backup with no port backup and board backup with port backup.

l Backup of OMUa/OMUb/OMUc boardsWhen two OMUa/OMUb/OMUc boards are installed in adjacent active and standby slotsin the BSC6900 MPS, the two boards work in board backup mode.

l Backup of POUa/POUc boardsWhen two POUa/POUc boards are configured in adjacent active and standby slots in aBSC6900 subrack, the two boards can be configured to work in board backup mode oroptical port backup mode.

l Independent mode of the SAUa/SAUc boardThe BSC6900 is configured with one SAUa/SAUc board, which works in independentmode.

l Backup of UOIa/UOIc boardsWhen two UOIa/UOIc boards are configured in adjacent active and standby slots in aBSC6900 subrack, the two boards can be configured to work in board backup mode oroptical port backup mode.

l Backup of XPUa/XPUb/SPUa/SPUb boardsWhen two XPUa/XPUb/SPUa/SPUb boards are installed in adjacent active and standbyslots in a BSC6900 subrack, the two boards can be configured to work in board backupmode.

l Resource pool of DPUa/DPUb/DPUc/DPUd/DPUe/DPUf/DPUg boardsThe DPUa/DPUb/DPUc/DPUd/DPUe/DPUf/DPUg boards of the BSC6900 and the digitalsignal processors (DSPs) in all the DPUa/DPUb/DPUc/DPUd/DPUe/DPUf/DPUg boardswork in resource pool mode.



48

11 Related Features

Prerequisite FeaturesNone

Mutually Exclusive FeaturesNone

Impacted FeaturesNone

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 11 Related Features


49

12 Network Impact

System CapacityNone

Network PerformanceNone

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 12 Network Impact


50

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 usingan external storage medium, such as a USB disk or CD-ROM.

13.2 Deployment

13.2.1 Processl 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 DOPRALinux OS to the latest version using the controller upgrade tool.

13.2.2 Requirementsl New sites

N/A

l Existing sites

– If the USB installation disk is used to install the DOPRA Linux OS, a USB disk with acapacity of 2 GB or higher must be ready.

– If the controller upgrade tool is used to upgrade the DOPRA Linux OS, the controllermust run on the DOPRA Linux OS.

13.2.3 Activationl Using the USB installation disk to install the latest DOPRA Linux OS

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 13 Engineering Guidelines


51

Prepare the USB installation disk for switching the OMU OS from non-DOPRA Linux toDOPRA Linux. Next, use the USB installation disk to install DOPRA Linux. For detailedoperations, see Operation Guide to Switching OMU Operating System Through USBDisks.

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, seeGuide 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 OperatingSystem Remote Patch Upgrade.

13.2.4 Activation ObservationN/A

13.2.5 DeactivationN/A

13.3 Performance MonitoringN/A

13.4 TroubleshootingN/A

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 13 Engineering Guidelines


52

14 Parameters

There are no specific parameters associated with this feature.

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 14 Parameters


53

15 Counters

Table 15-1 Counter description

Counter ID Counter Name CounterDescription

NE Feature ID Feature Name

67194469 VS.SDH.SWAP.REASON.REQUEST.COUNTS

T7041:Numberof SDH PortSwitchovers onConditionalRequests

BSC6900 MRFD-210101 SystemRedundancy

67194470 VS.SDH.SWAP.REASON.KBYTE.COUNTS

T7042:Numberof SDH PortSwitchovers onK byte Requests


67194471 VS.SDH.SWAP.REASON.EXTERNAL.COUNTS

T7043:Numberof SDH PortSwitchovers onexternalRequests


67194472 VS.SDH.FAULT.CHANNEL.PROTECT.COUNTS

T7044:Numberof SDHProtectionChannelFailures


67194473 VS.SDH.FAULT.CHANNEL.WORK.COUNTS

T7045:Numberof SDHWorkingChannelFailures


73436939 VS.Frame.Flux.Peak.TxRate

HR9732a:PeakInter-SubrackTransmittingTraffic

BSC6900 MRFD-210104 BSC/RNCResourceSharing

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 15 Counters


54



73436941 VS.Frame.Flux.Mean.TxRate

AR9732a:Average Inter-SubrackTransmittingTraffic


73441493 VS.Frame.Flux.DropPackets

R9732a:Number of DiscardedInter-SubrackPackets


73441494 VS.Frame.Flux.TxPackets

R9732b:Number of Sent Inter-Subrack Packets


67194469 VS.SDH.SWAP.REASON.REQUEST.COUNTS

T7041:Numberof SDH PortSwitchovers onConditionalRequests


67194470 VS.SDH.SWAP.REASON.KBYTE.COUNTS

T7042:Numberof SDH PortSwitchovers onK byte Requests


67194471 VS.SDH.SWAP.REASON.EXTERNAL.COUNTS

T7043:Numberof SDH PortSwitchovers onexternalRequests


67194472 VS.SDH.FAULT.CHANNEL.PROTECT.COUNTS

T7044:Numberof SDHProtectionChannelFailures


67194473 VS.SDH.FAULT.CHANNEL.WORK.COUNTS

T7045:Numberof SDHWorkingChannelFailures


73436939 VS.Frame.Flux.Peak.TxRate

HR9732a:PeakInter-SubrackTransmittingTraffic




55



73436941 VS.Frame.Flux.Mean.TxRate

AR9732a:Average Inter-SubrackTransmittingTraffic


73441493 VS.Frame.Flux.DropPackets

R9732a:Number of DiscardedInter-SubrackPackets


73441494 VS.Frame.Flux.TxPackets

R9732b:Number of Sent Inter-Subrack Packets




56

16 Glossary

For the acronyms, abbreviations, terms, and definitions, see the Glossary.

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 16 Glossary


57

17 Reference Documents

1. Operation and Maintenance Feature Parameter Description for GSM BSS or WCDMARAN

2. Controller Resource Sharing Feature Parameter Description for WCDMA RAN3. Flow Control Feature Parameter Description for GSM BSS or WCDMA RAN4. RNC in Pool Feature Parameter Description for WCDMA RAN5. RNC Node Redundancy Feature Parameter Description for WCDMA RAN6. BSC Node Redundancy Feature Parameter Description for GSM BSS7. MSC Pool Feature Parameter Description for GSM BSS8. SGSN Pool Feature Parameter Description for GSM BSS9. TC Pool Feature Parameter Description for GSM BSS10. Call Admission Control Feature Parameter Description for WCDMA RAN11. Load Control Feature Parameter Description for WCDMA RAN12. Overload Control Feature Parameter Description for WCDMA RAN13. E2E Flow Control Feature Parameter Description for WCDMA RAN14. Fault Management Feature Parameter Description for SingleRAN

SingleRANBase Station Controller Equipment Reliability FeatureParameter Description 17 Reference Documents


58