129579170 ran14 capacity monitoring guide

8/13/2019 129579170 RAN14 Capacity Monitoring Guide

1/48

RAN14.1

Capacity Monitoring Guide

Issue Draft A

Date 2012-07-23

HUAWEI TECHNOLOGIES CO., LTD.


2/48

Draft A (2012-07-23) Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

i

Copyright Huawei Technologies Co., Ltd. 2012. 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]
http://www.huawei.com/http://www.huawei.com/mailto:[email protected]:[email protected]:[email protected]://www.huawei.com/


3/48

RAN14.1

Capacity Monitoring Guide About This Document



ii

About This Document

Purpose

Traffic on a mobile telecommunications network, especially a newly deployed network,

increases over time. To support the ever-increasing traffic, more and more network resourcesare required, such as signaling processing resources, transmission resources, and air interface

resources.

If any type of network resource is insufficient, the key performance indicators (KPIs) decline

(for example, the call drop rate increases), and user experience deteriorates. Therefore,real-time resource monitoring, resource bottleneck detection, and timely network expansion

are critical to good user experience on a mobile telecommunications network. This documentis intended to help network maintenance personnel monitor UTRAN system capacity and

detect network resource bottlenecks.

This document applies to RAN14.1 UTRAN products, including BSC6910 and 3900 series

base stations. This document is only to be used as a reference for RNCs and NodeBs of earlier

versions.

Organization

This document provides guidelines for preventing resource congestion. When following these

guidelines, you must consider intuitiveness and operability based on site requirements.

This document consists of the following chapters.

Chapter Description

1 Network Resource

Monitoring Methods

Describes basic concepts associated with network resources, including definitions

and monitoring activities.

2 Network Resource

Performance CountersDescribes the counters for monitoring various network resources.

3 HSPA-related Resource

Monitoring

Describes how to monitor network resources when High Speed Packet Access

(HSPA) is enabled.

4 Diagnosis of Problems

Related to NetworkResources

Describes fault analysis and diagnosis methods that experienced WCDMA network

maintenance personnel can use to handle network congestion or overloadefficiently.

5 Counter Definitions Lists all performance counters mentioned in the preceding chapters and provides

the definitions of these counters.


4/48

RAN14.1

Capacity Monitoring Guide About This Document



iii

Change History

Issue Date Description Version Prepared By

1 2012-07-23 This is the Draft A release ofRAN14.1.

Draft A Inventory Solutions Department


5/48

RAN14.1

Capacity Monitoring Guide Contents



iv

Contents

About This Document ....................................................................................................................... ii1Network Resource Monitoring Methods ....................................................................................... 1

1.1 Introduction to Network Resources ............................................................... ................................................... 11.1.1 RNC Resources ..................................................................................................................... .................. 21.1.2 NodeB Resources ............................................................ .............................................................. .......... 21.1.3 Air Interface Resources ................................................................................... ........................................ 3

1.2 Resource Monitoring Procedure .......................................................... ............................................................. 32Network Resource Performance Counters ................................................................................... 5

2.1 RNC Resources ........................................................................................................ ........................................ 52.1.1 Control-Plane Load and User-Plane Load............................................................................................... 52.1.2 Interface Board Load .............................................................................................................................. 62.1.3 RNC Inter-Subrack Bandwidth .................................................................................. ............................. 7

2.2 NodeB Resources .......................................................... ................................................................. .................. 82.2.1 NodeB CPU Usage ......................................................... .............................................................. .......... 82.2.2 WMPT/UMPT CNBAP Usage ................................................. .............................................................. 82.2.3 CE Usage ................................................................................................................................................ 92.2.4 Iub Bandwidth ...................................................... ................................................................. ................ 11

2.3 Air Interface Resources ............................................................ .............................................................. ........ 112.3.1 Uplink Load ............................................................................................................... ........................... 112.3.2 Downlink Load .................................................................................... ................................................. 132.3.3 Downlink OVSF Code Usage .................................................................................... ........................... 142.3.4 Common Channels .......................................................... .............................................................. ........ 15

3HSPA-related Resource Monitoring ............................................................................................ 183.1 HSDPA ............................................................... ................................................................. ........................... 18

3.1.1 Power Resources ........................................................................................................ ........................... 183.1.2 OVSF Code Resources.......................................................................................................................... 19

3.2 HSUPA ............................................................... ................................................................. ........................... 203.2.1 CE Resources ....................................................... ................................................................. ................ 203.2.2 RTWP ........................................................ ................................................................. ........................... 20

4Diagnosis of Problems Related to Network Resources.............................................................. 214.1 Call Congestion in the Basic Call Flow ............................................. ............................................................ 21


6/48

RAN14.1

Capacity Monitoring Guide Contents



v

4.2 Call Congestion Counters ......................................................... .............................................................. ........ 234.2.1 Counters Related to Paging Loss ......................................................... ................................................. 234.2.2 Counters Related to RRC Congestion ............................................................. ...................................... 244.2.3 Counters Related to RAB Congestion ............................................................. ...................................... 24

4.3 Signaling Storms and Solutions ..................................................................................................................... 254.4 Resource Usage Analysis ................................................................................................. .............................. 27

4.4.1 RNC Resource Usage Analysis ............................................................................................................. 294.4.2 NodeB Resource Usage Analysis ......................................................... ................................................. 324.4.3 Air Resource Usage Analysis .......................................................................... ...................................... 35

5Counter Definitions ....................................................................................................................... 39


7/48

RAN14.1

Capacity Monitoring Guide 1 Network Resource Monitoring Methods



1

1 Network Resource Monitoring MethodsTwo methods are available for monitoring network resources and detecting resourcebottlenecks:

Prediction-based monitoringThis method monitors various network resources simultaneously. You can monitor the usage

of a network resource (for example, the downlink transmit power of a cell), compare thedetected resource usage with a preset upper threshold, predict the resource usage trend and

impact, and determine whether to perform network expansion. If the resource usage remainsabove the preset upper threshold for a long time (for example, a cell remains overloaded

during busy hours for several consecutive days), you can split the cell or add carriers for

network expansion.

This method is used to identify high-load cells and RNCs. It is a conventional means ofmonitoring resource usage and is easy to implement.

This chapter describes how to use this method to monitor network resources.

NOTE

For details about the counters for monitoring network resources, see chapter2 "Network ResourcePerformance Counters." For details about HSPA-related resources, see chapter3 "HSPA-related

Resource."

Problem-driven analysisThis method is used to analyze decreased network performance counters after network

congestion has occurred. This method is more complex than prediction-based monitoringbecause it requires more analysis instruments and skills. However, this method can maximize

how the system utilizes existing resources and eliminate the need for immediate network

expansion. For details about this method, see chapter4 "Diagnosis of Problems Related toNetwork Resources."

NOTE

Experienced network maintenance engineers can also use other methods to analyze network resourceproblems.

1.1 Introduction to Network Resources

Network resources that need to be monitored consist of RNC resources, NodeB resources, and

air interface resources.Figure 1-1 shows the distribution of these network resources.


8/48

RAN14.1




2

Figure 1-1Distribution of radio resources to be monitored

1.1.1 RNC Resources

The RNC resources that need to be monitored are as follows:

Control-plane and user-plane resourcesBSC6910 boards do not differentiate between the control plane and the user plane. Anew Evolved General Processing Unit REV: a (EGPUa) board was introduced into the

BSC6910 to process control-plane data and user-plane data. As the traffic volume grows,

the control-plane load and user-plane load of the EGPUa board may exceed its plannedprocessing capability and become a system bottleneck.

Interface board resourcesInterface boards on the RNC provide various transmission ports and resources to processtransport network messages and to enable interaction between RNC internal data andexternal data. On the interface boards, control-plane overload affects service connection,

and user-plane overload causes packets to be discarded.

Inter-subrack bandwidthThe RNC provides the bandwidth for inter-subrack information exchange.

1.1.2 NodeB Resources

The NodeB resources that need to be monitored are as follows:

Channel elements (CEs)CEs are baseband processing resources managed at the NodeB level. For a newly

deployed network, CE usage is initially set to a small value to savecapital expenditure(CAPEX). Generally, CE congestion is most likely to occur on the network.

NodeB boardsNodeB boards are classified into the WMPT/UMPT, WCDMA Baseband ProcessingUnit (WBBP), and Universal Transmission Processing unit (UTRP).

The WCDMA Main Processing and Transmission unit (WMPT) or Universal MainProcessing and Transmission unit (UMPT) performs signaling processing and resource

management. Central processing unit (CPU) overload of the WMPT or UMPT decreases

system processing capabilities, which affects NodeB-related KPIs.

Iub transmission resourcesBased on the transmission medium, there are two types of transmission: asynchronous

transfer mode (ATM) transmission and Internet Protocol (IP) transmission.

On an IP transport network, the NodeB and RNC can dynamically adjust uplink and

downlink Iub transmission bandwidth. Generally, transmission resource bottlenecks do
http://3ms.huawei.com/term/docMaintain/termOperate.do?method=listTermAndDefinition&f_id=20090723000327&fd_id=25090&node_id=1-9&searchType=fulltext&searchValue=CAPEX&caseSensitive=&language_t=cnhttp://3ms.huawei.com/term/docMaintain/termOperate.do?method=listTermAndDefinition&f_id=20090723000327&fd_id=25090&node_id=1-9&searchType=fulltext&searchValue=CAPEX&caseSensitive=&language_t=cn


9/48

RAN14.1




3

not result from insufficient capacities of interface boards but from low bandwidthavailable on the IP transport network.

1.1.3 Air Interface Resources

The air interface resources that need to be monitored are as follows:

Received total wideband power (RTWP)RTWP is the total power received by a NodeB within a bandwidth, including the receiver

noise, external radio interference, and uplink power generated due to traffic. RTWP,

which is similar to the received signal strength indicator (RSSI) in the CDMA system,measures uplink load. RSSI measures the total channel power received by a UE in the

downlink.

Transmitted carrier power (TCP)TCP is the full-carrier transmit power in a cell and monitors downlink load. The TCPvalue is limited by the maximum transmission capability of the power amplifier on a

NodeB. Orthogonal variable spreading factor (OVSF)

OVSF is a downlink code resource. In the downlink, only one OVSF code tree is

available for each cell.

Paging channel (PCH)PCH usage is directly related to the location area code (LAC) plan and PCH state

transition. PCH overload decreases the paging success rate.

Random access channel (RACH) and forward access channel (FACH)The RACH and FACH carry signaling and a small amount of user-plane data.

RACH/FACH overload may decrease the access success rate, affecting user experience.

1.2 Resource Monitoring Procedure

This section describes the resource monitoring procedure. This procedure is easy to

implement and applicable in most scenarios.

For a newly deployed network, you can monitor only one resource. Once you detect that this

resource exceeds its upper threshold, check whether other resources exceed their upperthresholds.

If yes, the cell or NodeB is overloaded. Then, perform network expansion. If no, the cell or NodeB is not necessarily overloaded. In this case, network expansion is

not mandatory because the problem might be solved by adjusting parameter

configurations.

For example, the CE usage is above 70% but the usages of other resources such as RTWP,

TCP, and OVSF codes are within their allowed ranges. In this case, CE resources areinsufficient but the cell is not overloaded. To solve the problem, configure licenses allowingmore CEs or add baseband processing boards instead of performing network expansion

immediately.

After the load is basically balanced between the control plane and the user plane:

If the CPU usage of the control plane is above 50%, the RNC is overloaded. If the CPU usage of the user plane is above 60%, the RNC is overloaded.


10/48

RAN14.1




4

Figure 1-2 shows the details.

Figure 1-2Resource monitoring flowchart

Other resource usages are not used to determine whether the RNC is overloaded.

This flowchart applies to most resource monitoring scenarios, except when the systemoverload is caused by an unexpected event rather than a service increase. To simplify the

procedure, unexpected events are not considered in this flowchart. The causes of unexpectedevents might be located through a comprehensive analysis of various resource bottlenecks.

For details about how to locate a resource-related problem, see chapter4 "Diagnosis of

Problems Related to Network Resources."


11/48

RAN14.1

Capacity Monitoring Guide 2 Network Resource Performance Counters



5

2 Network Resource Performance CountersThis chapter provides the performance counters for monitoring the network resourcesdescribed in chapter 1 and their upper thresholds. These counters indicate the resource usage

or load on a UTRAN.

Identifying the busy hour is crucial to accurate counter monitoring. There are various methodsfor identifying the busy hour. The simplest method is recommended, that is, determining the

hour during which the most resources are consumed. If the value of a counter during the busyhour exceeds the upper threshold for three consecutive days, consider capacity expansion.

2.1 RNC Resources

Table 2-1 lists the counters for monitoring RNC resources.

Table 2-1Counters for monitoring RNC resourcesResource Type Counter Upper

Threshold

Control-plane load VS.SUBSYS.CPULOAD.MEAN 50%

User-plane load VS.SUBSYS.CPULOAD.MEAN 60%

CPU usage on the interface

boardVS.INT.CPULOAD.MEAN 50%

Forwarding load on the interface

board

VS.INT.TRANSLOAD.RATIO.M

EAN

70%

2.1.1 Control-Plane Load and User-Plane Load

The control plane processes air interface signaling and transport layer signaling. The controlplane may be overloaded due to signaling storms. If the control plane is overloaded, newmessages are discarded and new call requests are rejected. This affects end-user experience.

The user plane processes and distributes service data.

The BSC6910 uses the EGPUa board to process user-plane data and control-plane data

simultaneously. Different types of resources on all EGPUa boards form different resource


12/48

RAN14.1




6

pools. Control-plane resources form a control-plane resource pool, and user-plane resourcesform a user-plane resource pool. The number of resources allocated to the control plane and

user plane can be adjusted based on service requirements so that load is balanced between the

two planes. Consider the control-plane load and user-plane load comprehensively beforeperforming capacity expansion.

Configuration of Control-Plane and User-Plane Sharing

You can run the SET UCPUPFLEXCFG command to set resource sharing policies for the

control and user planes. In this command, the FlexCfgModeparameter specifies the dynamicadjustment mode.

Parameter

ID

Description Value Range Default Value

FlexCfgMode FrozenMode,

ManulMode,

AutoMode

FrozenMode

For details about other parameters in the SET UCPUPFLEXCFG command, seeBSC6910UMTS MML Command Reference.

Counters for Monitoring Average CPU Usage on the Control and User Planes

The VS.SUBSYS.CPULOAD.MEAN counter measures the average CPU usage of a

subsystem during a measurement period and reflects the CPU load and quality of thesubsystem during the measurement period.

The average CPU usage on the control plane is calculated by the following formula:

Average CPU usage on the control plane = Average (VS.SUBSYS.CPULOAD.MEAN

measured for all CP subsystems)

The average CPU usage on the user plane is calculated by the following formula:

Average CPU usage on the user plane = Average (VS.SUBSYS.CPULOAD.MEAN measured

for all UP subsystems)

The recommended upper thresholds for monitoring the average CPU usage on the control and

user planes are 50% and 60%, respectively.

When FlexCfgModeis set to ManulModeor FrozenMode, you are advised to enable

dynamic sharing or to adjust the ratio of resources split between processing user plane dataand control plane data if the control plane or user plane is overloaded. If the control-plane or

user-plane resources cannot meet your traffic model's requirements, perform capacityexpansion immediately.

2.1.2 Interface Board Load

CPU Usage on the Interface Board

The control-plane load on an interface board is indicated by the board CPU usage. The loadincludes forwarding load and session load. An RNC can house multiple interface boards. If an

interface board is overloaded, adjust the transmission bandwidth or add an interface board to

expand system capabilities.


13/48

RAN14.1




7

The counters for monitoring the CPU usage on the interface board are as follows:

VS.INT.CPULOAD.MEANThis counter measures the average CPU usage of an interface board as a percentage.

Average CPU usage for session loadThis counter is calculated by the following formula:

Average CPU usage for session load = VS.INT.CFG.INTERWORKING.NUM/Numberof established or released sessions per second x 60 x SP x 100%

where

VS.INT.CFG.INTERWORKING.NUM is the number of call setup attempts on aninterface board. SP is the measurement period (in minutes).

The number of established or released sessions per second is subject to systemspecifications: 5000 for the GOUc and FG2c boards and 50,000 for the EXOUaboard.

It is recommended that an interface board be added when the CPU usage or session load of aninterface board exceeds 50%.

Forwarding Load on the Interface Board

The VS.INT.TRANSLOAD.RATIO.MEAN counter measures the average forwarding load on

the user plane of the interface board as a percentage.

It is recommended that an interface board be added when the CPU usage for forwarding loadexceeds 70%.

2.1.3 RNC Inter-Subrack Bandwidth

Ports on the SCU boards form a trunk group, which connects the Main Process Subrack (MPS)and Extension Process Subrack (EPS). If the inter-subrack bandwidth approaches the overload

threshold, voice and data service quality deteriorates, network KPIs decline, and the systembecomes unstable.

Introduction

If active and standby SCUa boards are used, the inter-subrack bandwidth is 4 Gbit/s. If active

and standby SCUb boards are used, the inter-subrack bandwidth is 40 Gbit/s.

If the active or standby SCUa/SCUb board is faulty, the inter-subrack bandwidth decreases byhalf.

Counters for Monitoring Inter-Subrack Traffic

The counters for monitoring inter-subrack traffic are as follows:

Frame Peak Utility RatioThis counter measures the peak usage of inter-subrack traffic and is calculated by thefollowing formula:

Frame Peak Utility Ratio = VS.Frame.Flux.Peak.TxRate/Inter-subrack bandwidth x

100%

where

VS.Frame.Flux.Peak.TxRate is the peak traffic volume transmitted between subracks.


14/48

RAN14.1




8

If the value of Frame Peak Utility Ratio is greater than 60%, a prewarning is required.

Frame Mean Utility RatioThis counter measures the average usage of inter-subrack traffic and is calculated by thefollowing formula:

Frame Mean Utility Ratio = VS.Frame.Flux.Mean.TxRate/Inter-subrack bandwidth x100%

where

VS.Frame.Flux.Mean.TxRate is the average traffic volume transmitted betweensubracks.

If the value of Frame Mean Utility Ratio is greater than 40%, a prewarning is required.

Frame DropPackets RatioThis counter measures the packet loss rate between subracks and is calculated by the

following formula:

Frame DropPackets Ratio = VS.Frame.Flux.DropPackets/VS.Frame.Flux.TxPackets x

100%where

VS.Frame.Flux.DropPackets is the number of packets discarded during packettransmission between subracks.

VS.Frame.Flux.TxPackets is the number of packets transmitted between subracks.If the value of Frame DropPackets Ratio is greater than 0.01%, a prewarning is required.

If the prewarning threshold is reached or an inter-subrack bandwidth congestion alarm is

reported, contact Huawei engineers for problem handling.

2.2 NodeB Resources

2.2.1 NodeB CPU Usage

On a network with a large number of smartphones, the main control board, baseband

processing board, and extended transmission board may be overloaded due to signalingstorms. If the CPU of a NodeB board is overloaded, more signaling messages are discarded,

which may result in no response to new call requests.

The VS.BRD.CPULOAD.MEAN counter measures the average CPU usage of a NodeB board

as a percentage.

If the NodeB CPU usage is higher than 60%, you are advised to perform capacity expansionby adding a board, splitting the NodeB, or deploying a new NodeB.

2.2.2 WMPT/UMPT CNBAP Usage

The WMPT or UMPT board processes signaling messages and manages resources for otherboards. If the WMPT/UMPT board is overloaded, a radio link (RL) fails to be set up, or no

response to an RL setup request is received. This significantly decreases KPIs such as theradio resource control (RRC) connection setup success rate and the radio access bearer (RAB)

setup success rate. For a Huawei NodeB, Common NodeB Application Protocol (CNBAP) isused to assess the WMPT/UMPT processing capability. The CNBAP usage is calculated bythe following formula:


15/48

RAN14.1




9

CNBAP usage

where

VS.IUB.AttRLSetup is the number of Iub RL setup requests in a cell. VS.IUB.AttRLAdd is the number of Iub RL addition requests in a cell. VS.IUB.AttRLRecfg is the number of Iub RL reconfiguration attempts in a cell. SP is the measurement period (in seconds). CNBAP capacity of the NodeB depends on the configuration of the WMPT/UMPT,

WBBP, and UTRP boards.

If the CNBAP usage of the WMPT/UMPT board is above 60% on a Huawei NodeB, you are

advised to perform capacity expansion by adding a WBBP/UTRP board or splitting the

NodeB.

2.2.3 CE Usage

Channel elements (CEs) are baseband resources provided by NodeBs. One CE resource canbe consumed by a 12.2 kbit/s voice call. If available CE resources are insufficient, a new call

request is rejected.

The total available CE resources are limited by the hardware and configured licenses. If CE

resources on the WBBP board are sufficient, the CE resources are limited by only licenses. Inthis case, expand the licensed capacity. CE resources are managed and shared in a resource

group of the NodeB.

Separate baseband processing units are used in the uplink and downlink directions of a NodeB.

Therefore, uplink and downlink CE resources are managed and used independently of eachother.

The number of licensed CE resources is distributed by the M2000. The number of CE resources

provided by boards on a NodeB and the number of CE resources provided by boards in an uplinkresource group are calculated based on NodeB board configuration and specifications. You can runMML commands to query the NodeB board configuration.

Uplink CE Usage

Since RAN14.0, the CE Overbooking feature has been introduced for uplink CE resources.

The counters for monitoring uplink CE usage vary depending on whether CE Overbooking is

enabled.

If CE Overbooking is enabled, the following counters are used to monitor uplink CE usage:

VS.NodeB.ULCreditUsed.MeanThis counter measures the average uplink NodeB credit resource usage when CEOverbooking is enabled.

NodeB_UL_CE_MEAN_RATIOThis counter measures the uplink CE usage on a NodeB and is calculated by the

following formula:

NodeB_UL_CE_MEAN_RATIO = Sum_AllCells_of_NodeB

(VS.NodeB.ULCreditUsed.Mean/2)/UL CE Cfg Number


16/48

RAN14.1




10

where

VS.NodeB.ULCreditUsed.Mean is the average uplink NodeB credit resource usagewhen CE Overbooking is enabled.

UL CE Cfg Number is the number of available uplink CE resources on a NodeB. Thenumber is the smaller of the values for two counters: NodeB License UL CE Numberand NodeB Physical UL CE Capacity. NodeB License UL CE Number measures the

number of licensed uplink CE resources on a NodeB. NodeB Physical UL CECapacity measures the number of uplink CE resources provided by boards on aNodeB.

If CE Overbooking is disabled, the following counters are used to monitor uplink CE usage:

NodeB_UL_GRP_CE_MEAN_RATIOThis counter measures the CE usage in an uplink resource group of a NodeB. EachNodeB allows for multiple uplink resource groups. This counter is calculated by the

following formula:

NodeB_UL_GRP_CE_MEAN_RATIO = Sum_AllCells_of_ResourceGroup(VS.LC.ULCreditUsed.Mean/2)/UL GRP CE Cfg Number

where

VS.LC.ULCreditUsed.Mean is the average uplink NodeB credit resource usage in acell.

UL GRP CE Cfg Number is the number of available CE resources in an uplinkresource group. The number is the smaller of the values for two counters: NodeBLicense UL CE Number and NodeB Physical UL group CE Capacity. NodeB

Physical UL group CE Capacity measures the number of CE resources provided by

boards in an uplink resource group.

NodeB_UL_CE_MEAN_RATIOThis counter measures the uplink CE usage on a NodeB and is calculated by thefollowing formula:

NodeB_UL_CE_MEAN_RATIO = Sum_AllCells_of_NodeB

(VS.LC.ULCreditUsed.Mean/2)/UL CE Cfg Number

where

VS.LC.ULCreditUsed.Mean is the average uplink NodeB credit resource usage in acell.

UL CE Cfg Number is the number of available uplink CE resources on a NodeB.The upper threshold for uplink CE usage is 70%. If CE usage is above 70% in an uplink

resource group of a NodeB, add a WBBP board to the uplink resource group even if theCE usage is low on the NodeB.

Downlink CE Usage

The NodeB_DL_CE_MEAN_RATIO counter measures the downlink CE usage and is

calculated by the following formula:

NodeB_DL_CE_MEAN_RATIO =

Sum_AllCells_of_NodeB(VS.LC.DLCreditUsed.Mean)/DL CE Cfg Number

where

VS.LC.DLCreditUsed.Mean is the average downlink NodeB credit resource usage in acell.


17/48

RAN14.1




11

DL CE Cfg Number is the number of available downlink CE resources on a NodeB. Thenumber is the smaller of the values for two counters: NodeB License DL CE Number

and NodeB Physical DL CE Capacity. NodeB License DL CE Number measures the

number of licensed downlink CE resources on a NodeB. NodeB Physical DL CECapacity measures the number of downlink CE resources provided by boards on a

NodeB.

If the downlink CE usage is above 70%, perform capacity expansion by adding a WBBPboard.

2.2.4 Iub Bandwidth

Generally, Iub bandwidth needs to be monitored. Based on the transmission medium, there aretwo types of transmission: ATM transmission and IP transmission.

On either an ATM or IP transport network, Huawei RNCs and NodeBs can monitor the

average traffic in the uplink and downlink, compare the average traffic with the total Iub

bandwidth, and obtain the Iub bandwidth usage. The average Iub bandwidth usage is indicated

by RNC counters related to transmission resources. If calls are frequently rejected due to alarge number of users on the network, the Iub bandwidth may be insufficient. If this occurs,

increase the Iub bandwidth as required.

Iub bandwidth is higher than air interface bandwidth. For an IP transport network, you are notadvised to monitor the Iub bandwidth when the prediction-based monitoring method is

implemented.

The BSC6910 does not support logical ports. The EGPUa board does not support virtual ports (VPs).

2.3 Air Interface Resources

2.3.1 Uplink Load

In a CDMA system, the radio performance of a cell is limited by the received noise. Therefore,

the total received interference in a cell is used to measure the uplink cell capability.

In a WCDMA system, received total wideband power (RTWP) is used to measure the uplinkcell capability. As is the case with the CDMA system, the RTWP value minus the cell

background noise is the interference increase that results from a service increase. Theinterference increase indicates the uplink service increase and is expressed as a percentage.For example, a 3 dB interference increase corresponds to 50% uplink load, and a 6 dB

interference increase corresponds to 75% uplink load.

Generally, the total uplink received bandwidth is 5 MHz and the background noise is -106

dBm in a WCDMA system.Figure 2-1 shows the relationship between RTWP, interferenceincrease, and uplink load.


18/48

RAN14.1




12

Figure 2-1Relationship between RTWP, interference increase, and uplink load

The recommended uplink load threshold is 75%, and the corresponding RTWP value issmaller than -100 dBm. If the RNC uses algorithm 2 during admission control, the value ofthe UL ENU Ratio counter should be smaller than 75%. UL ENU Ratio measures the ratio of

uplink equivalent users to users supported in the cell. Algorithm 2 is the Equivalent Numberof Users (ENU) algorithm.

If the RTWP value is greater than -100 dBm, the cell is overloaded in the uplink.

Generally, if a cell is overloaded or the RTWP value is too large, the cell coverage shrinks, thequality of ongoing services deteriorates, and new service requests may be rejected.

The following counters related to RTWP and ENU are used on Huawei RNCs:

VS.MeanRTWP: average RTWP (in dBms) in a cell VS.MinRTWP: minimum RTWP (in dBms) in a cell VS.RAC.UL.EqvUserNum: number of uplink equivalent users on all dedicated channels

in a cell

UL ENU Ratio: this counter is calculated by the following formula:UL ENU Ratio = VS.RAC.UL.EqvUserNum/UlTotalEqUserNum

where

UlTotalEqUserNum is the maximum number of equivalent users in a cell, which can be

set by running the ADD UCELLCACcommand.

In some areas, the background noise increases to far higher than -106 dBm due to other

interference or hardware problems, such as antennas or feeder connectors of poor quality. In

this case, the VS.MinRTWP counter, which measures the RTWP when there is no traffic in acell, reflects the background noise in the cell. If the VS.MinRTWP value during the idle houris larger than -100 dBm or smaller than -110 dBm for three consecutive days in one week,there are hardware problems or external interference. Find the cause, and troubleshoot the

problems or eliminate the external interference.

The recommended uplink load threshold is indicated by the VS.MeanRTWP counter. A cell is

considered heavily loaded in the uplink when either of the following is true for two or threedays in one week:


19/48

RAN14.1




13

The VS.MeanRTWP value during the busy hour remains above -100 dBm, whichcorresponds to a 6 dB interference increase or 75% load.

The UL ENU Ratio value during the busy hour remains above 75%.When the cell is heavily loaded, perform capacity expansion by adding a carrier or increasing

the UlTotalEqUserNum value.

2.3.2 Downlink Load

The downlink capacity of a cell is limited by its total available transmit power, which is

determined by the base station power amplifier (PA) and by software settings.

When the transmit power in a cell is exhausted, the following occur:

The cell coverage is insufficient. The data throughput is limited. The service quality deteriorates. New call requests may be rejected.The downlink power consumption in a cell is related to the cell load, UE location, and cell

coverage. Any one of the following scenarios leads to more power consumption:

Large cell coverage Long distance between the UE and the cell center Heavy cell loadIn a WCDMA system, TCP is used to measure the downlink total transmit power in a cell.

Four TCP-related counters are used on Huawei RNCs:

VS.MeanTCP: average downlink carrier transmit power in a cell VS.MaxTCP: maximum downlink carrier transmit power in a cell VS.MinTCP: minimum downlink carrier transmit power in a cell VS.MeanTCP.NonHS: average downlink carrier transmit power in a non-HSDPA cellThe downlink cell load is indicated by the TCP usage in the cell. If the TCP usage in a cell

remains above 85% of the VS.MaxTCP value, the cell is overloaded in the downlink. The

TCP usage in a cell is calculated by the following formula:

TCP usage in a cell = / x 100%

where

MaxTxPower is set by running the ADD UCELLSETUPcommand.

The following provides two examples of determining whether a cell is overloaded based onthe formula.

If Then

Downlink Maximum

Transmit Power

Upper Threshold for

TCP Usage

Upper TCP Threshold That

Triggers Cell Overload

20 W (43 dBm) 85% 17 W (42.3 dBm)


20/48

RAN14.1




14

40 W (46 dBm) 85% 34 W (45.3 dBm)

If the TCP usage during the busy hour remains above 85% for three consecutive days in oneweek, the cell is heavily loaded in the downlink. Then, perform capacity expansion by addinga carrier.

Some live networks use hierarchical cell structures with multiple carriers. The cell power

settings and the corresponding upper TCP thresholds vary depending on the networkingpolicy and cell service priority.

2.3.3 Downlink OVSF Code Usage

In a WCDMA system, channels are distinguished by code. For a channel, two types of codesare available: scrambling code and orthogonal variable spreading factor (OVSF) code.

In the uplink, each user is allocated a unique scrambling code.

In the downlink, each cell is allocated a unique scrambling code, that is, all users in a cell usethe same scrambling code. Each user in a cell is allocated a unique OVSF code.

In a WCDMA cell, data from different users is distinguished based on CDMA technique, andall user data is transmitted over the same central frequency almost at the same time. OVSF

codes provide perfect orthogonality, minimizing interference between different user data.

Figure 2-2 shows an OVSF code tree.

Figure 2-2OVSF code tree

In the downlink, the maximum spreading factor (SF) 256 can be used.

In a cell, only one OVSF code tree is available. In the OVSF code tree, sibling codes are

orthogonal to each other, but are not with their parent or child codes. As a result, once a codeis allocated to a user, neither its parent nor child code can be allocated to any other user.

OVSF code resources are limited. If available OVSF codes are insufficient to achieve the

desired quality of service (QoS), a new call request may be rejected.


21/48

RAN14.1




15

An OVSF code tree can be divided into 4 SF4 codes, 8 SF8 codes, 16 SF16 codes, or 256SF256 codes. Codes with various SFs can be considered as equivalent codes with SF 256. For

example, a code with SF 8 is equivalent to 32 codes with SF 256. Based on this equivalence

mapping, the OVSF code usage can be calculated for a user or in a cell.

Huawei RNCs monitor the average code usage of an OVSF code tree based on the number ofequivalent codes with SF 256. The VS.RAB.SFOccupy counter measures the average code

usage of an OVSF code tree.

The counters for monitoring the OVSF code usage are as follows:

OVSF_Utilization, which is calculated by the following formula:OVSF_Utilization = VS.RAB.SFOccupy/256

DCH_OVSF_Utilization, which is calculated by the following formula:DCH_OVSF_Utilization = DCH_OVSF_CODE/256

where

DCH_OVSF_CODE is calculated as follows:DCH_OVSF_CODE = (( + ) x 64 +

( + ) x 32 + ( +

) x 16 + ( + ) x 8 +( + ) x 4 + ( +

) x 2 + ( + ))

If the DCH_OVSF_Utilization value during the busy hour remains above 70% for three

consecutive days in one week, the cell runs out of OVSF codes. Perform capacity expansionby splitting the cell or adding a carrier.

2.3.4 Common Channels

Common channels include paging channels (PCHs) and forward access channels (FACHs).

Both the PCH and the FACH are downlink transport channels. The PCH is used to transmit

paging messages. The FACH is used to transmit user signaling and a small amount of user

data to UEs in the CELL_FACH state. The capacity of PCHs and FACHs is configurable. If

the PCH or FACH capacity is insufficient, signaling messages or user data is lost.

Common channel resource analysis involves the monitoring of both PCHs and FACHs. If the

PCH usage is too high, paging messages may be lost. Paging messages are broadcast across

an area identified by location area code (LAC), which is referred to as a LAC area for short.

Therefore, improper LAC planning leads to high PCH usage. High FACH usage is mainly

caused by two factors:

State transition of a large number of UEs performing packet switched (PS) services RRC signaling stormsBased on the default parameter settings for Huawei RNCs, the PCH and FACH usages are

calculated as follows:

PCH usageThe PCH Physical Channel Utility Ratio counter measures the PCH usage and is



22/48

RAN14.1




16

PCH Physical Channel Utility Ratio = VS.UTRAN.AttPaging1/( x 60 x 5/0.01)

where

VS.UTRAN.AttPaging1 is the number of PAGING TYPE1 messages transmitted in acell.

SP indicates the measurement period (in seconds).The basic principles for evaluating PCHs are as follows:

If paging messages are not retransmitted, 5% of them will be lost when the PCHusage reaches 60%.

If paging messages are retransmitted once or twice, 1% of them will be lost when thePCH usage reaches 70%.

Based on the basic principles, you are advised to perform fault diagnosis or replan LAC

areas.

FACH usageThe FACH usage is indicated by the FACH Utility Ratio counter. The method for

calculating the value of this counter varies depending on whether a standalone secondarycommon control physical channel (SCCPCH) is used.

If a FACH is carried on a non-standalone SCCPCH, the FACH usage is calculated by the

following formula:

FACH Utility Ratio = VS.CRNCIubBytesFACH.Tx x 8/((60 x x 168 x 1/0.01) xVS.PCH.Bandwidth.UsageRate x 6/7 + (60 x x 360 x 1/0.01) x (1-VS.PCH.Bandwidth.UsageRate x 6/7))

where

VS.CRNCIubBytesFACH.Tx is the traffic transmitted on the FACH on the Iubinterface.

VS.PCH.Bandwidth.UsageRate is the PCH bandwidth usage and is calculated asfollows:

VS.PCH.Bandwidth.UsageRate =/( x SP x 60.0)

In this formula, VS.CRNCIubBytesPCH.Tx measures the traffic transmitted on the

PCH on the Iub interface; VS.CRNC.IUB.PCH.Bandwidth measures the PCH

bandwidth for the CRNC in a cell.

SP is the measurement period (in seconds).If a FACH is carried on a standalone SCCPCH, the FACH usage is calculated by thefollowing formula:

FACH Utility Ratio = VS.CRNCIubBytesFACH.Tx x 8/(60 x x 360 x 1/0.01)

where VS.CRNCIubBytesFACH.Tx is the traffic transmitted on the FACH on the Iub

interface.

SP is the measurement period (in seconds). Ratio of users on the FACH to users allowed to use the FACH

This ratio is indicated by the FACH UserNum Utility Ratio counter. The method for

calculating the value of this counter varies depending on the value of the

FACH_60_USER_SWITCHparameter in the SET UCACALGOSWITCH command.

If FACH_60_USER_SWITCHis set to OFF, this counter is calculated by thefollowing formula:

FACH UserNum Utility Ratio = VS.FACHUEs/30 x 100%


23/48

RAN14.1




17

where

VS.FACHUEs is the number of users on the FACH.

If FACH_60_USER_SWITCHis set to ON, this counter is calculated by thefollowing formula:

FACH UserNum Utility Ratio = VS.FACHUEs/60 x 100%

where

VS.FACHUEs is the number of users on the FACH.

If the FACH usage or the ratio of users on the FACH to users allowed to use the FACH

reaches 70%, you are advised to modify the parameter settings.


24/48

RAN14.1

Capacity Monitoring Guide 3 HSPA-related Resource Monitoring



18

3 HSPA-related Resource MonitoringHSPA includes High Speed Downlink Packet Access (HSDPA) and High Speed UplinkPacket Access (HSUPA). HSDPA and HSUPA protocols are part of the WCDMA standard.

HSPA includes techniques such as fast scheduling, adaptive modulation, and hybrid automatic

repeat request (HARQ) to achieve high speed data transmission.

HSPA carries PS services. Conversational services are prioritized over PS services, and

therefore HSPA uses network resources only after conversational services are served. Thischapter describes how to monitor network resources when HSPA is enabled.

3.1 HSDPA

3.1.1 Power Resources

Figure 3-1 illustrates how the downlink transmit power in a cell is allocated. The dashed lineindicates the total downlink transmit power in a cell.

Figure 3-1Dynamic power resource allocation


25/48

RAN14.1




19

The downlink transmit power in a cell is divided into four portions:

Power for CCH: This portion of power is allocated to common transport channels (CCHs)in the cell, such as the broadcast channel, pilot channel, and paging channel.

Power margin: This portion of power cannot be allocated. The power margin is reservedto ensure that the system can remain stable even if the UE position or environmentchanges.

Power for DPCH: This portion of power is allocated to real-time services (voice andvideo calls) and PS R99 services, and it varies with the number and location of users.

The RNC and UE can adjust power for DPCH based on the power control algorithm.

Power for HSPA: This portion of power is allocated to HSDPA and is calculated by thefollowing formula:

HSDPA User Power = Max Cell Transmit Power - (Power for CCH + Power Margin +Power for DPCH)

HSPA power schedulers are designed primarily to maximize power efficiency.

For an HSDPA-enabled cell, you still need to monitor the TCP to check whether the cell isoverloaded in the downlink. TCP thresholds for this cell are the same as those for a cell

without HSDPA. With HSDPA, downlink power overload affects HSDPA performance before

it affects conversational services.

3.1.2 OVSF Code Resources

OVSF code resources can be shared between HSDPA services and real-time services. The

system can dynamically reallocate OVSF codes to HSDPA services and real-time services

based on parameter settings, such as the number of codes reserved only for HSDPA and thenumber of codes that can be shared. The parameter settings can be modified online based on

the network plan.

When HSDPA is enabled, OVSF code resources are monitored in the same way as when

HSDPA is not enabled.

You can reduce high OVSF code usage by modifying the parameter settings.

Figure 3-2OVSF code sharing


26/48

RAN14.1




20

3.2 HSUPA

3.2.1 CE Resources

HSUPA channels are dedicated channels, and resource consumption of HUSPA services ismeasured by CEs. When HSUPA is enabled, uplink CE resources are shared between R99

services and HSUPA services.

HSUPA increases uplink throughput and improves user experience. However, HSUPAconsumes more uplink CE overhead for HARQ and soft handovers. Therefore, uplink CEresources may become a system bottleneck. Uplink CE usage needs to be monitored when

HSUPA is enabled. Huawei NodeBs support dynamic HSUPA CE resource management,which uses CE resources efficiently.

3.2.2 RTWP

Just as HSDPA makes the most of downlink power resources, HSUPA maximizes uplink

capacity. HSUPA data can always be sent in authorized mode unless the RTWP rises to 6

dBm.

HSUPA increases uplink cell throughput but consumes a large amount of uplink RTWP. Theuplink RTWP is monitored in the same way regardless of whether HSUPA is enabled. If

RTWP overload occurs, HSUPA service rates must be lowered to ensure the QoS ofconversational services.


27/48

RAN14.1

Capacity Monitoring Guide 4 Diagnosis of Problems Related to Network Resources



21

4 Diagnosis of Problems Related to NetworkResources

The preceding chapters describe the basic methods for monitoring network resources. Thesemethods can be used to resolve most problems caused by high resource usage. In certain

scenarios, further problem diagnosis is required to determine whether high resource usage iscaused by a traffic increase or exceptions.

This chapter describes how to diagnose problems related to network resources, including thefollowing topics:

4.1 Call Congestion in the Basic Call Flow 4.2 Call Congestion Counters 4.3 Signaling Storms and Solutions 4.4 Resource Usage AnalysisThis chapter is intended for experts who have a deep understanding of WCDMA networks.

4.1 Call Congestion in the Basic Call Flow

When network resources are insufficient, KPIs related to system accessibility are likely to beaffected first.

Figure 4-1 shows the basic call flow in which possible block points and failure points aremarked. This flow uses a mobile-terminated call as an example. For details about the call flow,

see 3GPP TS 25.931.


28/48

RAN14.1




22

Figure 4-1Call flowchart showing possible block and failure points

The call flow inFigure 4-1 works as follows:

1. The CN sends a paging message to the RNC.2. Upon receiving the paging message, the RNC broadcasts the message on the PCH. If the

PCH is congested, the RNC may discard the message, as shown by block point 1.3. The UE probably cannot receive the paging message or connect to the network, as shown

by failure point 2.

4. If the UE receives the paging message, it sends an RRC connection request message tothe RNC.

5. Upon receiving the RRC connection request message, the RNC may discard the messageif the RNC is congested, as shown by block point 3.

6. If the RNC receives the RRC connection request message and does not discard themessage, the RNC determines whether to accept or reject the request. The request maybe rejected due to insufficient resources, as shown by block point 4.

7. If the RNC accepts the request, the RNC instructs the UE to set up an RRC connection.However, the RRC connection setup may fail, the UE probably cannot receive the


29/48

RAN14.1




23

instruction, or the UE receives the message but finds the configuration incorrect, asshown by failure points 5 and 6.

8. If the RRC connection is set up, the UE sends non-access stratum (NAS) messages tonegotiate with the CN about service setup. If the CN determines to set up a service, the

CN sends an RAB assignment request to the RNC.9. Upon receiving the RAB assignment request, the RNC accepts or rejects the request

based on the resource usage on the RAN side. If the RNC rejects the request, the failureis shown by block point 7.

10. If the RNC accepts the RAB assignment request, the RNC initiates a radio bearer (RB)setup procedure. During the procedure, the RNC allocates resources as follows:

The RNC allocates transmission resources over the Iub interface by setting up an RLto the NodeB.

The RNC allocates channel resources over the Uu interface by sending an RB setupmessage to the UE.

A failure may occur in the RL or RB setup process, as shown by failure points 8 and 9.

4.2 Call Congestion Counters

As shown inFigure 4-1,call congestion may affect paging, RRC connection setup, or RAB

setup.

The following describes the performance counters and KPIs related to call congestion rate.

For details about call congestion counters, see chapter5 "Counter Definitions." You can alsorefer to the following documents:

BSC6910 UMTS Performance Counter Referencein theBSC6910 UMTS ProductDocumentation

NodeB Performance Counter Referencein the 3900 Series WCDMA NodeB ProductDocumentation

4.2.1 Counters Related to Paging Loss

Counters related to paging loss are monitored at the RNC and cell levels.

The RNC-level counters related to paging loss are as follows:

VS.RANAP.CsPaging.Loss: measures the number of CS paging messages discarded dueto Iu-interface flow control, CPU overload, or PCH congestion.

VS.RANAP.PsPaging.Loss: measures the number of PS paging messages discarded dueto Iu-interface flow control, CPU overload, or PCH congestion.

IU Paging Congestion Ratio (RNC): measures the ratio of discarded paging messages tototal paging messages at the RNC level and is calculated by the following formula:

IU Paging Congestion Ratio (RNC) = [(VS.RANAP.CsPaging.Loss+VS.RANAP.PsPaging.Loss)/(VS.RANAP.CsPaging.Att + VS.RANAP.PsPaging.Att)] x100%

The cell-level counters related to paging loss are as follows:

VS.RRC.Paging1.Loss.PCHCong.Cell: measures the number of paging messagesdiscarded due to PCH congestion in a cell.

IU Paging Congestion Ratio (Cell): measures the ratio of discarded paging messages tototal paging messages at the cell level and is calculated by the following formula:


30/48

RAN14.1




24

IU Paging Congestion Ratio (Cell) = (VS.RRC.Paging1.Loss.PCHCong.Cell/VS.UTRAN.AttPaging1) x 100%

4.2.2 Counters Related to RRC Congestion

The counters related to RRC congestion are as follows:

Counters for measuring the number of rejected RRC connection setup requests,including:

VS.RRC.Rej.ULPower.Cong (due to uplink power congestion) VS.RRC.Rej.DLPower.Cong (due to downlink power congestion) VS.RRC.Rej.UL.CE.Cong (due to uplink CE congestion) VS.RRC.Rej.DL.CE.Cong (due to downlink CE congestion) VS.RRC.Rej.ULIUBBand.Cong (due to uplink Iub bandwidth congestion) VS.RRC.Rej.DLIUBBand.Cong (due to downlink Iub bandwidth congestion) VS.RRC.Rej.Code.Cong (due to downlink code resource congestion)

VS.RRC.AttConnEstab.SumThis counter measures the total number of RRC connection setup requests in a cell.

Vs.RRC.Block.RateThis counter measures the call congestion rate and is calculated by the following formula:

Vs.RRC.Block.Rate = Total RRC Rej/VS.RRC.AttConnEstab.Sum x 100%

where

Total RRC Rej is calculated as follows:

Total RRC Rej = < VS.RRC.Rej.ULPower.Cong > + < VS.RRC.Rej.DLPower.Cong > + + < VS.RRC.Rej.DL.CE.Cong > + + < VS.RRC.Rej.DLIUBBand.Cong > +

4.2.3 Counters Related to RAB Congestion

The counters related to RAB congestion are as follows:

Counters for measuring the number of failed RAB establishments due to powercongestion, including:

VS.RAB.FailEstabCS.ULPower.Cong VS.RAB.FailEstabCS.DLPower.Cong VS.RAB.FailEstabPS.ULPower.Cong VS.RAB.FailEstabPS.DLPower.Cong

Counters for measuring the number of failed RAB establishments due to uplink CEcongestion, including:

VS.RAB.FailEstabCS.ULCE.Cong VS.RAB.FailEstabPS.ULCE.Cong

Counters for measuring the number of failed RAB establishments due to downlink CEcongestion, including:

VS.RAB.FailEstabCs.DLCE.Cong


31/48

RAN14.1




25

VS.RAB.FailEstabPs.DLCE.Cong Counters for measuring the number of failed RAB establishments due to downlink code

resource congestion, including:

VS.RAB.FailEstabCs.Code.Cong VS.RAB.FailEstabPs.Code.Cong

Counters for measuring the number of failed RAB establishments due to Iub bandwidthcongestion, including:

VS.RAB.FailEstabCS.DLIUBBand.Cong VS.RAB.FailEstabCS.ULIUBBand.Cong VS.RAB.FailEstabPS.DLIUBBand.Cong VS.RAB.FailEstabPS.ULIUBBand.Cong

VS.RAB.AttEstab.CellThis counter measures the total number of RAB establishment requests in a cell.

VS.RAB.Block.RateThis counter measures the RAB congestion rate and is calculated by the following

formula:

VS.RAB.Block.Rate = Total number of failed RAB establishments regardless of the

cause of failure/VS.RAB.AttEstab.Cell

4.3 Signaling Storms and Solutions

In most cases, a smartphone makes more than 10 PS RAB setup attempts during a busy hour.

This leads to more signaling exchanges on a smartphone than on a common UE during the

service process. The additional signaling exchanges consume a large amount of signalingprocessing resources on the control plane of the RNC and NodeB.

Figure 4-2 shows the process for analyzing signaling storms.


32/48

RAN14.1




26

Figure 4-2Process for analyzing signaling storms

Table 4-1 describes solutions to signaling storms. These solutions aim to reduce signaling load

so that the network capacity does not need to be expanded immediately.


33/48

RAN14.1




27

Table 4-1Signaling storm causes and solutionsUE Behavior UE Type Solution

The UE does not send

signaling connectionrelease indication (SCRI)messages.

Common

Nokia/Samsung/Motorola UEs

Enable the CELL_PCH function to

reduce signaling traffic because thesecommon UEs do not send SCRImessages.

The UE sends SCRI

messages that do notcontain the cause value

iPhone (R6) Enable the enhanced fast dormancy

(EFD) function on the RNC, and add theinternational mobile equipment identities

(IMEIs) of the iPhones to the whitelist.

The R8 UE sends SCRI

messages containing thecause value

iPhone4 (after

R6)

Enable the R8 FD function on the RNC,

and add the IMEIs of the iPhones to thewhitelist.

4.4 Resource Usage Analysis

Figure 4-3 illustrates the general troubleshooting process for resource usage issues.


34/48

RAN14.1




28

Figure 4-3General troubleshooting process

In most cases, an abnormal KPI triggers the troubleshooting process. Determining thepossible top N problem cells facilitates follow-up troubleshooting.

You are advised to analyze accessibility KPIs to identify the system bottleneck that causes

access congestion.


35/48

RAN14.1




29

Figure 4-4Key points for bottleneck analysis

4.4.1 RNC Resource Usage Analysis

Analysis of High CPU Usage of the Control PlaneSmartphones cause signaling storms on live networks. Therefore, signaling processing

capability on the control plane is most likely to become a system bottleneck.

If the control-plane load exceeds a preset alarm threshold, the RNC starts flow control anddiscards some RRC connection request messages or paging request messages. From the

perspective of maintenance, the CPU usage of the control plane must be kept strictly belowthe alarm threshold to ensure system security.


36/48

RAN14.1




30

Figure 4-5Process for analyzing the CPU usage of the control plane

As shown inFigure 4-5,if the CPU usage of the control plane is above 50%, identify the

causes to prevent a continuous increase in the CPU usage. If the high CPU usage is caused by

signaling storms, determine whether the parameter settings are correct. If the high CPU usageis caused by a traffic increase, add an EGPUa board.

Control-plane and user-plane sharing adjusts the load on EGPUa boards to balance theaverage load on the control and user planes. NodeB Management (NBM) load cannot be

shared between the control and user planes. Therefore, you must perform dynamic cell


37/48

RAN14.1




31

reallocation to balance the NBM load among EGPUa boards in the control-plane resourcepool. After the traffic model changes, reduce the number of cells under the RNC or add an

EGPUa board when both of the following conditions are met:

Control-plane and user-plane sharing is enabled. The load is imbalanced between the control and user planes. For example, the

control-plane load is lighter than the user-plane load, but the available control-planeresources are insufficient to add a NodeB or cell.

Analysis of High CPU Usage of the User Plane

If the user-plane load on an EGPU board or interface board is heavy, the RNC discards someuser-plane data. Therefore, user-plane resources must be strictly monitored.

Figure 4-6Process for analyzing the CPU usage of the user plane


38/48

RAN14.1




32

If the CPU usage of the user plane is above 60%, identify the causes to prevent a continuousincrease in the CPU usage. If the high CPU usage is caused by a traffic increase, add an

EGPUa board.

4.4.2NodeB Resource Usage Analysis

CE Usage Analysis

CE resources form a resource pool, which is shared among services on the NodeB. Common

channels do not consume extra CE resources because the NodeB has reserved CE resourcesfor these channels. Signaling, which is carried on an associated channel of the DCH, does notconsume extra CE resources.

When CE Overbooking is enabled, the NodeB calculates the CE usage of all admitted UEs atthe cell group and NodeB levels, and reports the CE resource to the RNC every measurement

period. The RNC then performs admission control based on the reported CE usage.

Table 4-2Number of CE resources consumed by different servicesService type Number of Consumed

CE Resources in the

Uplink

Number of Consumed

CE Resources in the

Downlink

AMR 12.2 kbit/s 1 1

CS 64 kbit/s 3 2

PS 64 kbit/s 3 2

PS 128 kbit/s 5 4

PS 144 kbit/s 5 4

PS 384 kbit/s 10 8

SF32 (HSUPA) 1 N/A

SF16 (HSUPA) 2 N/A

SF8 (HSUPA) 4 N/A

SF4 (HSUPA) 8 N/A

2 x SF4 (HSUPA) 16 N/A

2 x SF2 (HSUPA) 32 N/A

2 x SF2+2 x SF4 (HSUPA) 48 N/A

2 x M2+2 x M4 64 N/A

NOTE

The preceding table assumes that signaling radio bearers (SRBs) are carried over HSUPA. If an SRB is

carried on an R99 DCH separately, an extra CE is consumed by the SRB. In this case, add 1 to each

number listed in the preceding table.


39/48

RAN14.1




33

HSDPA services do no consume downlink R99 CE resources. HSUPA services and R99services share uplink CE resources.

CE congestion or routine CE usage monitoring may trigger CE resource analysis.

If the CE usage remains above a preset capacity expansion threshold or CE congestion occurs,the CE resources are insufficient and must be increased to ensure system stability.

Figure 4-7Process for analyzing CE congestion


40/48

RAN14.1




34

CE resources can be shared within a resource group. Therefore, CE usage on the NodeB mustbe calculated to determine where CE congestion occurs in a resource group or on the NodeB.

If CE congestion occurs in a resource group, reallocate CE resources between resource groups.

If CE congestion occurs on the site, perform site capacity expansion and modify parametersettings.

Iub Bandwidth Usage Analysis

NOTE

After IP RAN is introduced, Iub resources no longer need to be monitored. This section is retained toprovide a complete solution so that operators can compare solutions provided by different vendors.

If insufficient Iub bandwidth causes congestion, check the Iub bandwidth usage.

If the Iub bandwidth usage remains above 80% for a period of time, the Iub bandwidth is

insufficient.

If no more Iub bandwidth is available or the issue is not urgent, decrease the activity factor for

PS services to admit more users. The activity factor, which is the ratio of actual bandwidthoccupied by a UE to the allocated bandwidth, is used to estimate the real bandwidth usage.The activity factor can be set on a per-NodeB basis. The default activity factor is 0.7 for voice

services and 0.4 for PS best effort (BE) services.

Figure 4-8Process for analyzing Iub bandwidth congestion


41/48

RAN14.1




35

4.4.3 Air Resource Usage Analysis

Power Resource Analysis

If the RTWP and TCP values are greater than preset thresholds, power congestion occurs.

If the power congestion occurs in the downlink, enable the load reshuffling (LDR) andoverload control (OLC) functions.

If the power congestion occurs in the uplink, check whether any interference exists. This is

because in most cases, interference rather than traffic increases causes uplink power

congestion.

If the RTWP value remains above -97 dBm for a period of time, identify root causes and

troubleshoot the problem.

If the high RTWP is caused by heavy traffic instead of signaling storms, implement thefollowing:

Enable LDR and OLC for temporary troubleshooting. Add carriers or split cells for a long-term solution.

Figure 4-9Process for analyzing power resource usage


42/48

RAN14.1




36

NOTE

RRC-related counters are updated based on the cause values in the RRC connection requests. This

facilitates analysis of risks related to signaling storms.

Generally, adding a carrier is the most effective means for relieving uplink power congestion.If no additional carrier is available, consider deploying a new site or splitting the cell by

reducing the tilt angle of the antenna.

Code Resource Usage Analysis

For Huawei RNCs, a certain number of codes can be reserved for HSDPA services by setting

parameters. However, if five SF16 codes are reserved for HSDPA services, code congestion

may occur under high traffic.

The only solution to code congestion is to add carriers or split sectors because code resources

are strongly correlated to hardware.

In some scenarios, massive signaling exchanges on the network occupy a large number ofcodes, which results in code congestion, power congestion, or CPU overload. In thesescenarios, analyze and pinpoint the exact cause, and rectify the fault rather than expand

capacity immediately.

If code congestion occurs, perform the following operations to reduce system load before

expanding capacity:

Reduce the maximum number of PS RABs. Enable code-based LDR. Reduce the minimum number of codes reserved for HSDPA services. Activate the license for dynamic code allocation on the NodeB.The thresholds for parameters involved in the preceding operations must be set based on the

operator's requirements for service quality.

PCH Usage Analysis

In most cases, PCHs are overloaded because improper LAC planning results in excess paging

messages. A common measure for PCH overload is to replan LAC areas.


43/48

RAN14.1




37

Figure 4-10Process for analyzing PCH usage

FACH Usage Analysis

FACH congestion is less likely to occur when UE state transition is disabled. However, the

RNC usually enables UE state transition to transfer low-traffic services to FACHs. This saves

radio resources, but increases traffic on FACHs.

Two methods are available for relieving FACH congestion:

Reduce the period during which PS services are carried on FACHs to enable fast UEstate transition to the CELL_PCH state or idle mode. In addition, set up RRC

connections on DCHs if DCH resources are sufficient.

Add an SCCPCH to carry FACHs.


44/48

RAN14.1




38

Figure 4-11Process for analyzing FACH usage


45/48

RAN14.1

Capacity Monitoring Guide 5 Counter Definitions



39

5 Counter DefinitionsTable 5-1 defines all performance counters mentioned in the preceding chapters.

Table 5-1CountersCounter Name Associated Counter Calculation Formula

# Blocking Metrics

Call block rate Vs.Call.Block.Rate (custom) Vs.RRC.Block.Rate +

(

/( +)) x

Vs.Rab.Block.Rate

RRC block rate Vs.RRC.Block.Rate (custom) ( +

+

+ +

+ +)/

RAB block rate Vs.RAB.Block.Rate (custom) ( +

+ +

+

+ +

+

+ +

+ +

+

+)/VS.

RAB.AttEstab.Cell


46/48

RAN14.1




40

Counter Name Associated Counter Calculation Formula

Call AttemptTimes

VS.RAB.AttEstab.Cell (custom) ( + +

+

+ +)

>>Power metrics

R99_TCP_Utiliz

ation_RatioVS.MeanTCP.NonHS VS.MeanTCP.NonHS/Configured_Total_Cell_T

CP (43 dBm or 46 dBm)

Total_TCP_Utili

zation_RatioVS.MeanTCP VS.MeanTCP/Configured_Total_Cell_TCP

Max UL RTWP VS.MaxRTWP VS.MaxRTWP

Mean UL RTWP VS.MeanRTWP VS.MeanRTWP

Min UL RTWP VS.MinRTWP VS.MinRTWP

UL ENU Ratio VS.RAC.UL.EqvUserNum VS.RAC.UL.EqvUserNum/UlTotalEqUserNum

>>IUB Metrics

IUB BW

Utilization ratioNODEB_Throughput (custom)

NODEB_Trans_Cap (custom)

NODEB_Throughput/NODEB_Trans_Cap

NODEB_Trans_Cap

VS.IPDLTotal.1

VS.IPDLTotal.2VS.IPDLTotal.3

VS.IPDLTotal.4

(VS.IPDLTotal.1 + VS.IPDLTotal.2 +VS.IPDLTotal.3 + VS.IPDLTotal.4)

NODEB_Throughput

NODEB_Throughput_DL (custom)

NODEB_Throughput_UL (custom)

MAX(NODEB_Throughput_DL,NODEB_Throughput_UL)

NODEB_Throug

hput_DLVS.IPDLAvgUsed.1

VS.IPDLAvgUsed.2

VS.IPDLAvgUsed.3

VS.IPDLAvgUsed.4

(VS.IPDLAvgUsed.1 + VS.IPDLAvgUsed.2 +

VS.IPDLAvgUsed.3 + VS.IPDLAvgUsed.4)

NODEB_Throug

hput_ULVS.IPULAvgUsed.1

VS.IPULAvgUsed.2

VS.IPULAvgUsed.3

VS.IPULAvgUsed.4

(VS.IPULAvgUsed.1 + VS.IPULAvgUsed.2 +

VS.IPULAvgUsed.3 + VS.IPULAvgUsed.4)

>>PCH&FACH Utilization Metrics

PCH Physical

Channel Utility

Ratio

VS.UTRAN.AttPaging1 VS.UTRAN.AttPaging1/(60 x 60 x 5/0.01)


47/48

RAN14.1




41


FACH UtilityRatio

VS.CRNCIubBytesFACH.Tx

VS.PCH.Bandwidth.UsageRate

(1) Utilization of FACH carried onnon-standalone SCCPCH

FACH Utility Ratio =VS.CRNCIubBytesFACH.Tx x 8/((60 x x168 x 1/0.01) x VS.PCH.Bandwidth.UsageRate x6/7 + (60 x x 360 x 1/0.01) x (1-

VS.PCH.Bandwidth.UsageRate x 6/7))

where

VS.PCH.Bandwidth.UsageRate =/( x SP x 60.0)

(2) Utilization of FACH carried on standaloneSCCPCH

FACH Utility Ratio =VS.CRNCIubBytesFACH.Tx x 8/(60 x x

360 x 1/0.01)

FACH UserNum

Utility RatioVS.FACHUEs (1)FACH_60_USER_SWITCH = OFF

FACH UserNum Utility Ratio =VS.FACHUEs/30 x 100%

(2)FACH_60_USER_SWITCH = ON

FACH UserNum Utility Ratio =VS.FACHUEs/60*100%

>>OVSF Utilization Metrics

OVSF

occupancyVS.RAB.SFOccupy VS.RAB.SFOccupy

OVSF UsabilityRatio

VS.RAB.SFOccupy.Ratio VS.RAB.SFOccupy/256

DCH OVSF

RatioDCH_OVSF_Utilization (( + )

x 64 + ( +) x 32 +

( +) x 16 +

( +

) x 8 +( +

) x 4 +

( +) x 2 +

( +))/256

>>CPU Usage Metrics

CP Utilization

RateVS.SUBSYS.CPULOAD.MEAN VS.SUBSYS.CPULOAD.MEAN


48/48

RAN14.1



UP UtilizationRate

VS.SUBSYS.CPULOAD.MEAN VS.SUBSYS.CPULOAD.MEAN

INT UtilizationRate

VS.INT.CPULOAD.MEAN

VS.INT.TRANSLOAD.RATIO.MEA

N

VS.INT.CPULOAD.MEAN

VS.INT.TRANSLOAD.RATIO.MEAN

NodeB CPU

Utilization RateVS.BRD.CPULOAD.MEAN VS.BRD.CPULOAD.MEAN

>>Credit Utilization Metrics

NODEB UL CE

Utility RatioVS.NodeB.ULCreditUsed.Mean;

VS.LC.ULCreditUsed.Mean;

When CE Overbooking is enabled,NodeB_UL_CE_MEAN_RATIO is


NodeB_UL_CE_MEAN_RATIO =Sum_AllCells_of_NodeB(VS.NodeB.ULCreditUsed.Mean/2)/UL CE Cfg Number

When CE Overbooking is disabled,NodeB_UL_CE_MEAN_RATIO iscalculated by the following formula:

NodeB_UL_CE_MEAN_RATIO =

Sum_AllCells_of_NodeB

(VS.LC.ULCreditUsed.Mean/2)/UL CE CfgNumber

NodeB_UL_GR

P_CE_MEAN_RATIO

NodeB_UL_GRP_CE_MEAN_RATIO =

Sum_AllCells_of_ResourceGroup(VS.LC.ULCreditUsed.Mean/2)/UL GRP CE Cfg Number

NodeB_DL_CE_

MEAN_RATIOVS.LC.DLCreditUsed.Mean

Sum_AllCells_of_NodeB

(VS.LC.DLCreditUsed.Mean)/MIN(NodeB

License DL CE Number, NodeB Physical DL CE

Capacity)

129579170 ran14 capacity monitoring guide

Documents