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.

i

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 Issue Draft A (2014-01-20)


ii


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 Issue Draft A (2014-01-20)


iii


Contents

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



iv


1

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

l

Work with Huawei products

1.3 Change History This section provides information about the changes in different document versions. There are two types of changes, which are defined as follows: l

Feature change: Changes in features of a specific product version

l

Editorial change: Changes in wording or addition of information that was not described in the earlier version

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



1


2 Overview

2

Overview

2.1 Introduction Reliability designs enable the controller to continue providing services even when it experiences a fault, thereby maintaining high system reliability. Objectives of reliability include: l

Decreasing the number of accidents

l

Minimizing the scope of fault influence

l

Shortening the duration of service interruption

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

2.2 Benefits Reliability designs, which include redundancy design and hardware reliability design, eliminate or reduce the impact of equipment faults on services, thereby improving system reliability.

2.3 Architecture Table 1 lists the controller equipment reliability-related features and functions that are supported by GSM and UMTS.



2


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



3


Reliability Category


2 Overview

Feature/ Function



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.


4


2 Overview


Feature/ Function



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.

5


2 Overview


Feature/ Function



Remarks

Hardware reliability

BSC/RNC Board Redundancy

GSM and UMTS

None

For details, see 10 Hardware Reliability.



6


3

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



7


4

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

l

Uploading, downloading, and activating the program files, patch files, and license files

l

Using the OMU of the controller as the FTP server and transmitting files such as program files and patch files between the FTP server and FTP client

l

Using the controller as the transmission medium to transmit files between the U2000 and the MBTS

In addition, users can manage the programs, patches, licenses, and logs using the Web LMT. The controller supports the software integrity check. The controller performs the software integrity check after software loading and before software operation, and then completes digital signature verification. The BSC/RNC is upgraded remotely by the dedicated upgrade tool, which consists of the upgrade client and the upgrade server. Figure 4-1 shows the BSC/RNC remote upgrade process. Issue Draft A (2014-01-20)


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 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. Issue Draft A (2014-01-20)


9



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


5 Redundancy Design

5

Redundancy Design

5.1 Overview This section describes the MRFD-210101 System Redundancy feature and the GBFD-111701 Board Switchover feature. System redundancy provides reliability designs that improve system reliability. These designs include active/standby switchovers and load sharing. Huawei base station controllers adopt reliability designs, such as load sharing and active/standby switchovers, to ensure the reliable operation of the system. l

Active/standby switchovers In active/standby mode, the active board processes services while the standby board acts as a backup for the active one. When the active board is faulty or needs to be replaced, services on the active board are switched over to the standby board to ensure normal service operations. There are two types of switchovers: – Automatic switchover: automatically triggered by the system if the active board is faulty. – Manual switchover: performed by maintenance personnel on the LMT. Maintenance personnel use the immediate switchover command to switch over the active and standby boards. A successful active/standby switchover requires the following: – The standby board works normally. – No major or critical alarm is reported on the standby board. When the standby board is switched over to the active state, the previously active board is reset automatically. If this board restarts normally, it is switched over to the standby state.

l

Load sharing In resource pool mode, load sharing is performed among processing units in the pool. When one or multiple processing units are faulty, new service requests are allocated to the normal processing units in the resource pool.

l

Other reliability designs



11


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.

l

The local layer manages board-level resources. A UCUP board performs the local layer functions.

RMP boards have the following characteristics: l

The CPU usage does not increase noticeably with the increase in the Busy Hour Call Attempt (BHCA) or throughput. A sudden increase in the CPU usage is allowed within a short period of time.

l

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

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



12


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.

l

The BSC6910 control plane uses the process backup mechanism. All active CP processes on a UCUP board have backups evenly distributed on the two adjacent UCUP boards.

When the BSC6900 or BSC6910 is running, the cell status, NodeB status, and online UE information on the active subsystem are sent to the standby subsystem through the backup channel. The standby subsystem then backs up the data. If the active subsystem is faulty, the standby subsystem takes over services on the active subsystem to avoid service interruptions. In addition to the redundancy design, the BSC6910 control plane also supports process preemption. If a pair of active and standby CP processes of the BSC6910 are both faulty for a certain period of time (less than 5 minutes), the BSC6910 preempts another standby CP process to start the active CP process, thereby restoring services promptly.



13


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.

l

Port backup or load sharing

l

Resource pool



14


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

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 Issue Draft A (2014-01-20)


15


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.

l

The local layer manages board-level resources. NOTE

EGPUa boards whose logical type is GCUP or GMCP (referred to as GCUP or GMCP boards) manage board-level resources. GCUP or GMCP is short for GSM BSC Control plane and User plane Processing.

EGPUa boards whose logical type is RMP (referred to as RMP boards) have the following characteristics: l

The CPU usage does not increase noticeably with the increase in the Busy Hour Call Attempt (BHCA) or throughput. A sudden increase in the CPU usage is allowed within a short period of time.

l

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

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



16


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.

l

The BSC6910 control plane uses the process backup mechanism. All active CP processes on an EGPUa board whose logical type is GCUP or GMCP have backups evenly distributed on the two adjacent EGPUa boards whose logical type is GCUP or GMCP.

When the BSC6900 or BSC6910 is running, the cell status, BTS status, and online MS information on the active subsystem are sent to the standby subsystem through the backup channel. The standby subsystem then backs up the data. If the active subsystem is faulty, the standby subsystem takes over services on the active subsystem to avoid service interruptions. In addition to the redundancy design, the BSC6910 control plane also supports process preemption. If a pair of active and standby CP processes of the BSC6910 are both faulty for a Issue Draft A (2014-01-20)


17


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. Issue Draft A (2014-01-20)


18


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.

l

Port backup or load sharing

l

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


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. Issue Draft A (2014-01-20)


20


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


6 Network Redundancy

6

Network Redundancy

6.1 RNC in Pool This section describes the RNC in Pool feature. For details, see RNC in Pool Feature Parameter Description.

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



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 Sharing This feature allows load sharing between existing RNCs and another RNC added for capacity expansion.

l

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

l

WRFD-150240 RNC in Pool Multiple Logical RNCs This feature allows multiple logical RNCs to be configured on a BSC6910 to implement load sharing or node redundancy. For example, if a BSC6910 carries three logical RNCs, it can serve as the overflow RNC or backup RNC for three BSC6900s. The BSC6900 does not support this feature.

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

6.1.2 Benefits The benefits of RNC in Pool are as follows: l

Load sharing for smooth RNC capacity expansion

Load sharing provided by RNC in Pool enables smooth RNC capacity expansion, which no longer requires RNC splitting or NodeB reparenting.Figure 6-2 shows a comparison between capacity expansion using existing techniques and using RNC in Pool. Issue Draft A (2014-01-20)


23



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

l

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

l

Improved system reliability Node redundancy provided by RNC in Pool allows a backup RNC to take over services of a faulty RNC. The redundancy technique enables fast service resumption and improves system reliability.

6.2 RNC Node Redundancy This section describes the WRFD-040202 RNC Node Redundancy feature. For details, see RNC Node Redundancy Feature Parameter Description. Issue Draft A (2014-01-20)


24



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



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



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


l


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

6.4 MSC Pool This section describes the GBFD-117401 MSC Pool feature. For details, see MSC Pool Feature Parameter Description. 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: Issue Draft A (2014-01-20)


28



l

All the MSCs in an MSC pool implement load balancing and resource sharing, increasing network capacity and reducing equipment investment.

l

If an MSC in an MSC pool is faulty or if an MSC is added to or removed from an MSC pool, the existing network architecture does not need to be adjusted. This helps implement MSC node redundancy and improve network reliability.

l

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

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

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



29


7 Fault Management

7

Fault Management

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

As shown in Figure 7-1 a controller includes the following devices: l

Operation and maintenance unit (OMU) boards



30


l

GE switching network and control unit (SCU) boards

l

Service processing boards

l

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


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.

l

Fault collection Fault collection is the most important external interface of fault management. It collects faults reported by fault detection units and processes in a centralized manner.

l

Duplicate fault filtering, fault transient rule, and fault toggle rule There are two filtering stages: primary filter and secondary filter. In the primary filter, fault detection units filter duplicate faults and other faults using the transient rule and toggle rule. In the secondary filter, alarms to be reported are filtered. – Transient rule Faults or alarms of short duration can be filtered based on the alarm or fault generation delay. Only the faults or alarms whose duration exceeds the threshold of the generation delay comply with the transient rule and are reserved for next filtering. As shown in Figure 7-3, the duration of fault 1 or alarm 1 is shorter than the delay threshold T, so fault 1 or alarm 1 is discarded. The duration of fault 2 or alarm 2 is longer than T, so alarm 2 or an alarm for fault 2 can be reported.



32


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.

l

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

l

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



33


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.

l

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

l

Alarm synchronization between a base station and the U2000 Alarm synchronization between a base station and the U2000 consists of two stages: – Alarm synchronization between the base station and the controller: The controller queries active alarms from the base station, issues a command to the base station to check for alarms that have not been synchronized, and updates alarm records on the controller based on the check result. – Alarm synchronization between the controller and the U2000.

l

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

l

User-defined alarms Base stations and controllers can be connected to external environment monitoring devices to monitor the environment and device status, such as the temperature, humidity, voltage, theft, and smoke. You can define alarms on base stations and controllers for faults related to the status of the environment and devices. You can also set parameters for these alarms, such as the alarm name, severity, and network management type. In this way, you can dynamically monitor the environment and devices.

l

Alarm masking With this function, you can mask specified alarms by alarm ID or object. – Masking alarms by alarm ID If Shielded Flag of a specified alarm ID is set to Shielded, all the active alarms of the alarm ID are cleared. During alarm masking, the specified alarm will not be reported even if the fault persists. If the fault is not rectified after alarm masking is disabled, alarms of the specified alarm ID are reported. – Masking alarms by object You can mask a specified alarm or all alarms for a certain board, port, or digital signal processor (DSP), or mask a specified alarm for all objects.

l

Fault log



34


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


8 Flow Control

8

Flow Control

8.1 RNC Flow Control 8.1.1 Overview Flow control is a protective measure for communications between the RNC and its peer equipment. Flow control provides protection in the following ways: l

It restricts incoming traffic to: – Protect equipment from overload, thereby maintaining system stability. – Ensure that equipment can properly process services even under heavy traffic.

l

It restricts outgoing traffic to reduce the load on the peer equipment.

8.1.2 Panorama During mass gathering events, the traffic volume may exceed the processing capability of the system. As a result, the system becomes overloaded, which may lead to messages being randomly discarded and NE resetting, as well as response failures, call drops, service access failures, and other unexpected events. Resources in a WCDMA system are limited, so how they are used affects system performance. The resources concerned here are: l

Equipment system resources, including CPU resources and memory

l

Air interface resources, including channels, codes, and power

l

Transmission resources

l

Core network processing capabilities

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



36


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.

l

To address problems caused by limited air interface resources (labeled 2 in Figure 8-1), the RNC performs call attempt per second (CAPS) control, PCH congestion control, and FACH congestion control. – When the cell is overloaded with services, the RNC limits the number of RRC connection requests admitted to a cell each second. This processing is implemented by CAPS control. – When the paging channel is congested, the RNC allows CS-domain paging messages to preempt PS-domain paging messages in order to raise the paging success rate in the CS domain. – When the forward access channel (FACH) is congested, the RNC restricts message retransmissions on the logical channels, rejects certain PS service requests, and triggers state transitions such as CELL_PCH to CELL_DCH (P2D) and CELL_DCH to idle (D2Idle). This gives priority to access requests for high-priority services such as CS services, keeps a high cell update success rate, and reduces call drops. The RNC performs admission control, load reshuffling, and overload control on code and power resources. For details about admission control, see Call Admission Control Feature Parameter Description. For details about load reshuffling and overload control, see Load Control Feature Parameter Description and Overload Control Feature Parameter Description.

l

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



37


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

l

E2E flow control based on power congestion

E2E Flow Control limits the traffic flow that enters NEs and therefore ensures the stable operation of NEs when these NEs are overloaded. For details about other flow control measures, such as flow control for overloaded RNC units, see Flow Control Feature Parameter Description. Compared with flow control performed on a single NE, E2E Flow Control has the following benefits: l

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

l

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



38


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: Issue Draft A (2014-01-20)


39


8 Flow Control

l

BSC: Base station controller (BSC) flow control is introduced to address BSC resource insufficiency. BSC boards monitor the system resource usage in real time and stop some functions, such as printing and recording logs, to decrease the central processing unit (CPU) usage to ensure system stability and reliability.

l

Um interface: SDCCH flow control and PCH flow control are introduced to address Uminterface resource insufficiency.

l

A interface: CN flow control and A-interface flow control are introduced to address Ainterface resource insufficiency.

l

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

l

Lb interface: Flow control on location request messages is introduced to address Lbinterface insufficiency.

l

Gb interface: BSSGP Virtual Connection (BVC) flow control and mobile station (MS) flow control are introduced to address Gb-interface insufficiency. BSSGP refers to Base Station Subsystem GPRS Protocol. The SGSN adjusts the downlink data rates for cells and MSs based on their maximum packet switched (PS) data volumes and the data transfer rate reported by the BSC.

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



40


9

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.

l

OMU applications are corrupted.

l

(Only for the BSC6900) The OS on the OMU board is switched from non-DOPRA Linux to DOPRA Linux.

9.2 Technical Description This section describes how to implement the Operation & Maintenance System One-Key Recovery feature.

Scheme 1 The USB creator is used to create the USB disk for installing the DOPRA Linux OS and the OMU applications. The USB installation disk is plugged into the USB port on the OMU board. The OMU board is then reset. Five to ten minutes later, the OS or OMU applications on the OMU board are recovered. Note that the OS, OMU applications, and the respective configuration information must be stored onto the USB installation disk during the creation of the USB installation disk. Then, Bootstrap scripts are generated on the USB installation disk to facilitate the start-up of the OMU board through the USB installation disk. The Bootstrap scripts first install the DOPRA Linux OS and configure the information for the OS. Then, the Bootstrap scripts install the OMU applications and configure the information for the OMU applications. Figure 9-1 shows the OMU board software recovery process. Issue Draft A (2014-01-20)


41



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



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



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


10

10 Hardware Reliability

Hardware Reliability

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



45



10.1 BSC/RNC Board Redundancy 10.1.1 BSC6910 Board Redundancy BSC6910 board redundancy has two types: board backup and resource pool. NOTE

The BSC6910 interface boards have an effective mechanism for fault detection and automatic recovery. When the BSC6910 detects that a certain proportion of resources of an interface board are unavailable for a specified period of time, the BSC6910 resets the interface board. If the faulty board is the active one in a pair of active and standby boards, the BSC6910 switches over the active and standby boards. For example, l The BSC6910 resets an Iub interface board if a certain proportion of cells under the Iub interface board are unavailable for a specified period of time because of a failure in Iub transmission links. l The BSC6910 resets an Iub interface board under the following conditions: The RRC connection setup success rate in a cell is lower than a predefined threshold because of a failure in Iub transmission links, the proportion of such cells under the Iub interface board reaches a predefined cell threshold, the proportion of NodeBs having such cells reaches a predefined NodeB threshold, and this situation persists for a specified period of time. l If the BSC6910 detects any transmission fault, the BSC6910 reports an alarm instead of resetting the interface board.

l

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

l

Resource pool of DPUf boards The DPUf boards of the BSC6910 and the GUPTC subsystem of each DPUf work in resource pool mode.

l

Backup of EXOUa/FG2c/GOUc/FG2d/GOUd boards When two EXOUa/FG2c/GOUc/FG2d/GOUd boards are installed in adjacent active and standby slots in a BSC6910 subrack, the two boards can be configured to work in board backup mode.

l

Resource pool of ENIUa boards The ENIUa boards of the BSC6910 work in resource pool mode.

l

Backup of SCUb boards The BSC6910 is configured with two SCUb boards in adjacent active and standby slots in each subrack. The two boards work in board backup mode.

l

Backup of GCUa/GCUb/GCGa/GCGb boards The BSC6910 is configured with two GCUa/GCUb/GCGa/GCGb boards in adjacent active and standby slots in the MPS. The two boards work in board backup mode.

l

Backup of EOMUa boards When two EOMUa boards are installed in adjacent active and standby slots in the BSC6910 MPS, the two boards work in board backup mode.

l

Independent mode of the ESAUa Board The BSC6910 is configured with one ESAUa board, which works in independent mode.



46


l


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

10.1.2 BSC6900 Board Redundancy BSC6900 board redundancy has two types: board backup and resource pool. NOTE

The BSC6900 interface boards have an effective mechanism for fault detection and automatic recovery. When the BSC6900 detects that a certain proportion of resources of an interface board are unavailable for a specified period of time, the BSC6900 resets the interface board. If the faulty board is the active one in a pair of active and standby boards, the BSC6900 switches over the active and standby boards. For example, l The BSC6900 resets an Iub interface board if a certain proportion of cells under the Iub interface board are unavailable for a specified period of time because of a failure in Iub transmission links. l The BSC6900 resets an Iub interface board under the following conditions: The RRC connection setup success rate in a cell is lower than a predefined threshold because of a failure in Iub transmission links, the proportion of such cells under the Iub interface board reaches a predefined cell threshold, the proportion of NodeBs having such cells reaches a predefined NodeB threshold, and this situation persists for a specified period of time. l If the BSC6900 detects any transmission fault, the BSC6900 reports an alarm instead of resetting the interface board.

l

Backup of AEUa boards When two AEUa boards are configured in adjacent active and standby slots in a BSC6900 subrack, the two boards can be configured to work in board backup mode.

l

Backup of EIUa/EIUb boards When two EIUa/EIUb boards are configured in adjacent active and standby slots in a BSC6900 subrack, the two boards can be configured to work in board backup mode.

l

Resource pool of NIUa boards The NIUa boards of the BSC6900 work in resource pool mode.

l

Backup of OIUa/OIUb boards When two OIUa/OIUb boards are configured in adjacent active and standby slots in a BSC6900 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 a BSC6900 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 standby slots in each subrack. The two boards work in board backup mode.

l

Backup of TNUa/TNUb boards The BSC6900 is configured with two TNUa/TNUb boards in adjacent active and standby slots in some subracks. The two boards work in board backup mode.

l

Backup of AOUa/AOUc boards



47



When two AOUa/AOUc boards are configured in adjacent active and standby slots in a BSC6900 subrack, the two boards can be configured to work in board backup mode or optical port backup mode. l

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

l

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

l

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

l

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

l

Backup of POUa/POUc boards When two POUa/POUc boards are configured in adjacent active and standby slots in a BSC6900 subrack, the two boards can be configured to work in board backup mode or optical port backup mode.

l

Independent mode of the SAUa/SAUc board The BSC6900 is configured with one SAUa/SAUc board, which works in independent mode.

l

Backup of UOIa/UOIc boards When two UOIa/UOIc boards are configured in adjacent active and standby slots in a BSC6900 subrack, the two boards can be configured to work in board backup mode or optical port backup mode.

l

Backup of XPUa/XPUb/SPUa/SPUb boards When two XPUa/XPUb/SPUa/SPUb boards are installed in adjacent active and standby slots in a BSC6900 subrack, the two boards can be configured to work in board backup mode.

l

Resource pool of DPUa/DPUb/DPUc/DPUd/DPUe/DPUf/DPUg boards The DPUa/DPUb/DPUc/DPUd/DPUe/DPUf/DPUg boards of the BSC6900 and the digital signal processors (DSPs) in all the DPUa/DPUb/DPUc/DPUd/DPUe/DPUf/DPUg boards work in resource pool mode.



48


11 Related Features

11

Related Features

Prerequisite Features None

Mutually Exclusive Features None

Impacted Features None



49


12 Network Impact

12

Network Impact

System Capacity None

Network Performance None



50


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.

l

Existing sites Install the latest DOPRA Linux OS using the USB installation disk, or upgrade the DOPRA Linux OS to the latest version using the controller upgrade tool.

13.2.2 Requirements l

New sites N/A

l

Existing sites – If the USB installation disk is used to install the DOPRA Linux OS, a USB disk with a capacity of 2 GB or higher must be ready. – If the controller upgrade tool is used to upgrade the DOPRA Linux OS, the controller must run on the DOPRA Linux OS.

13.2.3 Activation l

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



51


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


14 Parameters

14

Parameters

There are no specific parameters associated with this feature.



53


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




54


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


73441493

VS.Frame.Flux. DropPackets

R9732a:Numbe r of Discarded Inter-Subrack Packets

BSC6900

MRFD-210104


73441494

VS.Frame.Flux. TxPackets

R9732b:Numbe r of Sent InterSubrack Packets

BSC6900

MRFD-210104


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




55


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


73441493

VS.Frame.Flux. DropPackets

R9732a:Numbe r of Discarded Inter-Subrack Packets

BSC6910

MRFD-210104


73441494

VS.Frame.Flux. TxPackets

R9732b:Numbe r of Sent InterSubrack Packets

BSC6910

MRFD-210104




56


16 Glossary

16

Glossary

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



57


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)

Recommend Documents