5.Capacity Monitoring Guide

RAN14.0

Capacity Monitoring Guide

Issue 03

Date 2012-11-07

HUAWEI TECHNOLOGIES CO., LTD.

Issue 03 (2012-11-07) 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/

mailto:[email protected]

RAN14.0

Capacity Monitoring Guide About This Document



ii

About This Document

Purpose

Traffic on a mobile telecommunications network, especially a new network, increases by the

day. To support the increasing traffic, more and more resources are required, such as signaling

processing resources, transmission resources, and air interface resources.

If any type of network resource is insufficient, user experience is affected (for example, the

call drop rate increases). This means that real-time resource monitoring, timely resource

bottleneck detection, and proper network expansion are critical to good user experience on a

mobile telecommunications network. This document describes how to monitor usage of

various network resources, locate network resource bottlenecks, and perform network

expansion in a timely manner.

Guidelines provided in this document are applicable to BSC6900 and BTS3900 series base

stations, but can only be used as references for RNCs and NodeBs of earlier versions.

Audience

This document is intended for network maintenance personnel.

Organization

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

Counters

Describes various network resources.

3 HSPA Related

Resources

Describes how to monitor network resources when HSPA is enabled.

4 Diagnosis of Problems

Related to Network

Resources

Provides fault analysis and locating methods that experienced WCDMA network

maintenance personnel can use to handle network congestion or overload events

efficiently.

RAN14.0

Capacity Monitoring Guide About This Document



iii

Chapter Description

5 Counter Definitions Lists all performance counters mentioned in the other chapters. These counters

help in monitoring network resources and designing resource analyzing

instruments.

Change History

Changes between document issues are cumulative. Therefore, the latest document issue

contains all changes made in previous issues.

03 (2012-11-07)

This is the third commercial release of RAN 14.0.

Compared with issue 02 (2012-06-30), this issue incorporates the following changes:

Updated section 2.12 “CNBAP Load of the NodeB Main Processing and Transmission

Unit (WMPT/UMPT)”.

02 (2012-06-30)

This is the second commercial release of RAN 14.0.

Compared with issue 01 (2012-04-30), this issue incorporates the following changes:

Update the formula for calculating CE usage, replace the NodeB counter with RNC

Counter.

Add MPU part.

Adjust SPU,DPU,Interface board threshold.

Adjust the document structure.

01 (2012-04-30)

This is the first commercial release of RAN 14.0.

Compared with issue Draft A (2012-02-15), this issue optimizes the description.

Draft A (2012-02-15)

This is the draft for RAN14.0.

RAN14.0

Capacity Monitoring Guide Contents



iv

Contents

About This Document .................................................................................................................... ii

1 Network Resource Monitoring Methods ................................................................................. 1

1.1 Network Resource Introduction ....................................................................................................................... 1

1.2 Resource Monitoring Procedure ....................................................................................................................... 2

2 Network Resource Counters ....................................................................................................... 4

2.1 SPU CPU Load ................................................................................................................................................ 4

2.2 MPU CPU Load ............................................................................................................................................... 5

2.3 DPU DSP Load ................................................................................................................................................ 6

2.4 Interface Board Load ........................................................................................................................................ 6

2.5 Uplink Load ..................................................................................................................................................... 6

2.6 Downlink Load ................................................................................................................................................. 8

2.7 CE Usage .......................................................................................................................................................... 8

2.8 OVSF Code Usage ........................................................................................................................................... 9

2.9 Iub Bandwidth ................................................................................................................................................ 11

2.10 Common Channels ....................................................................................................................................... 11

2.11 NodeB CPU Load ......................................................................................................................................... 12

2.12 CNBAP Load of the NodeB Main Processing and Transmission Unit (WMPT/UMPT) ............................. 12

3 HSPA Related Resources ........................................................................................................... 14

3.1 HSDPA ........................................................................................................................................................... 14

3.1.1 Power Resources ................................................................................................................................... 14

3.1.2 Code Resources ..................................................................................................................................... 15

3.2 HSUPA ........................................................................................................................................................... 16

3.2.1 CE Resources ........................................................................................................................................ 16

3.2.2 RTWP .................................................................................................................................................... 16

4 Diagnosis of Problems Related to Network Resources ....................................................... 17

4.1 Call Blocks in the Basic Call Flow ................................................................................................................ 17

4.2 Call Congestion Counters ............................................................................................................................... 19

4.2.1 Performance Counters Associated with Paging Loss ............................................................................ 19

4.2.2 Performance Counters Associated with RRC Congestion Rates ........................................................... 19

4.2.3 Performance Counters Associated with RAB Congestion Rates........................................................... 20

4.3 Signaling Storms and Solutions ..................................................................................................................... 21

RAN14.0

Capacity Monitoring Guide Contents



v

4.4 Resource Analysis .......................................................................................................................................... 23

4.4.1 CE Resource Consumption Analysis .................................................................................................... 25

4.4.2 Code Resource Usage Analysis ............................................................................................................. 28

4.4.3 Iub Resource Analysis ........................................................................................................................... 28

4.4.4 Power Resource Analysis ...................................................................................................................... 29

4.4.5 SPU CPU Usage Analysis ..................................................................................................................... 30

4.4.6 DPU DSP and Interface Board CPU Usage Analysis ........................................................................... 32

4.4.7 PCH Usage Analysis ............................................................................................................................. 32

4.4.8 FACH Usage Analysis .......................................................................................................................... 33

5 Counter Definitions .................................................................................................................... 35

RAN14.0

Capacity Monitoring Guide 1 Network Resource Monitoring Methods



1

1 Network Resource Monitoring Methods

There are two methods of monitoring system resources and detecting resource bottlenecks:

Prediction-based monitoring: This is a proactive approach wherein various network resources

are monitored simultaneously.

You can monitor usage of a network resource (for example, the downlink transmit power of a

cell), predict the resource usage trend and impacts, and determine whether to perform network

expansion after comparing the detected resource usage with a preset upper threshold. After

detecting that usage of a resource is higher than its 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 approach, which applies to daily

resource monitoring, is easy to implement and can be used to determine high-load cells and

RNCs. This chapter describes the procedure for monitoring network resources.

NOTE

For details on network resources, see chapter 2 "Network Resource Counters." For details on

HSPA-associated resources, see chapter 3 "HSPA Related Resources."

Problem-driven analysis: When a network performance counter deteriorates (for example,

calls are dropped), a thorough analysis is performed. This method is applicable to analysis

upon network congestion. This method requires more analysis instruments and skills than the

prediction-based monitoring method, but can use the current system and eliminates the need

for an immediate network expansion. For details on this method, see chapter 4 "Diagnosis of

Problems Related to Network Resources."

NOTE

In addition to the preceding two methods, other methods may also be used by network maintenance

engineers for system problem analysis.

1.1 Network Resource Introduction

The network resources that can be monitored are as follows:

SPU: indicates the signaling processing unit on an RNC. An RNC supports various types

of SPUs. SPUs process air interface signaling and manage transport resources. They are

the most likely network resource bottleneck.

MPU: indicates the main control processing unit on an RNC. It manages control-plane

resources, user-plane resources, and transport resources. If provided on an SPUb board,

the MPU subsystem may be overloaded.

RAN14.0




2

DPU: indicates the user-plane processing unit on an RNC. It distributes user-plane

service data. With rapid development of mobile broadband (MBB), more and more DPU

resources are consumed. There is a high possibility that the preset DPU resource

capability cannot meet the requirements for the rapid development.

Received total wideband power (RTWP): indicates the total wideband power received by

a base station within a bandwidth (namely, the uplink load generated due to the receiver

noise, external radio interference, and uplink traffic). This is a counter for measuring

uplink load, similar to the received signal strength counter (RSSI) in the CDMA system.

RSSI is a downlink load measurement, indicating the total channel power received by a

UE.

Transmitting carrier power (TCP): indicates the full-carrier power transmitted by a cell

and is a counter for monitoring downlink load. This counter value is limited by the

maximum transmission capability of the power amplifier at a NodeB.

Channel element (CE): indicates the baseband processing resource. CEs are managed

and shared at the NodeB level. For a new network, this counter has a small start value to

lower capital expenditure (CAPEX). Generally, CEs are the most likely resource

bottleneck that results in network congestion.

Orthogonal variable spreading factor (OVSF): indicates the downlink OVSF code

resource. For a cell, only one OVSF code tree is available in the downlink direction.

Iub interface resource: On an IP transport network, uplink and downlink Iub interface

bandwidth can be dynamically adjusted for both NodeBs and RNCs. Generally, transport

resource bottlenecks do not result from insufficient capacities of interface boards but

from low bandwidth available on the IP transport network.

Paging channel (PCH): The PCH usage is directly related to the LAC area plan and PCH

state transition. PCH overload will cause a decrease in the paging success ratio.

Random access channel (RACH) and forward access channel (FACH): The RACH and

FACH carry signaling and some user-plane data. RACH/FACH overload will cause a

decrease in access success ratio and affect user experience.

Main processing and transmission unit(WMPT/UMPT): The main processing and

transmission unit performs site transmission, signaling, and system management. CPU

overload of the WMPT will cause a decrease in system processing capabilities, therefore

affecting NodeB-related KPIs.

Figure 1-1 Allocation of radio resources that can be monitored

1.2 Resource Monitoring Procedure

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

implement and is applicable to most scenarios.

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

RAN14.0




3

For a newly constructed network, you can monitor only one resource. Once detecting that this

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

thresholds.

If yes, the cell or NodeB is overloaded. Perform network expansion.

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

not mandatory and the problem can be solved by other adjustments or optimizations.

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

TCP, and OVSF codes are within their allowed ranges. In this case, CE resources are

insufficient but the cell is not overloaded. To solve the problem in this example, configure

licenses allowing more CEs or add baseband processing boards, instead of performing

network expansion immediately.

Figure 1-2 Resource monitoring flowchart

As shown in Figure 1-2, an SPU is overloaded if its CPU usage is 50% to 60%, regardless of

other resource usages.

This flowchart is applicable to most resource monitoring scenarios, except when the system

overload is due to an unexpected event, but not a service increase. Unexpected events are not

considered in this flowchart.

Causes for unexpected events can be located based on their association with various resource

bottlenecks. For details on how to locate a resource-related problem, see chapter 4 "Diagnosis

of Problems Related to Network Resources."

RAN14.0

Capacity Monitoring Guide 2 Network Resource Counters



4

2 Network Resource Counters

Various counters are defined to represent the resource usage or load of a UTRAN system. In

addition, upper thresholds for these counters are predefined.

Identifying the busy hour is a key to accurate counter analysis. There are various methods of

identifying the busy hour. The simplest one is to take the hour when the most resources are

consumed as the busy hour.

Table 2-1 RNC resources and threshold

Resources Type Counter Monitoring

Threshold

SPU CPU VS.XPU.CPULOAD.MEAN 50%

MPU CPU VS.XPU.CPULOAD.MEAN 50%

DPU DSP Load VS.DSP.UsageAvg 60%

Interface Board CPU

Load

VS.INT.CPULOAD.MEAN 50%

Interface Board

Forwarding Load

VS.INT.TRANSLOAD.RATIO.MEAN 70%

2.1 SPU CPU Load

SPUs process all the air interface signaling and transmission interface signaling. They are the

boards most likely to be overloaded due to signaling storms.

If SPUs are overloaded, new messages are discarded and new call requests are rejected. This

will affect end user experience.

The load indicator of SPUs is their CPU usage. A Huawei RNC can house multiple SPUs.

Each SPUa board contains four CPUs (each represents a subsystem). Each SPUb board

contains eight CPUs.

A Huawei RNC automatically shares and balances its load between CPUs. If an SPU is

overloaded, add SPUs as required.

RAN14.0




5

The mean SPU resource usage (SPU CPU load) is indicated by the counter

VS.XPU.CPULOAD.MEAN expressed in percentage.

It is recommended:

If the SPU CPU usage is over 50% in the busy hour for three consecutive days in one

week, add SPUs as required.

If the SPU CPU usage is over 60% in the busy hour for three consecutive days in one

week, take emergency expansion measures.

Figure 2-2 SPU Threshold

2.2 MPU CPU Load

MPU is a resource manager which take charge of resource allocation of SPU, DPU and

interface board for UE call.

Physically, it corresponds to subsystem 0 on a certain SPUa/SPUb.

The MPU CPU load is indicated by the counter VS.XPU.CPULOAD.MEAN and the mean

MPU CPU load is expressed as a percentage.

It is recommended that 50% be used as the monitoring threshold. If any one MPU CPU load

is over 50% for a specified period, adjust the resources between MPUs or add more MPU.

Huawei provides professional services to accomplish the adjustment.

The maximum 5 MPU can be defined in per subrack.

How to find the MPU? Execute the MML “DSP BRD” and check if one SPUa or SPUb’s subsystem 0

“Logic function type = RUCP” , if Yes, it is MPU. Or check the RNC configuration files to find

“ADD BRD”, for example:

ADD BRD: SRN=0, BRDCLASS=XPU, BRDTYPE=SPUb, LGCAPPTYPE=RUCP, SN=0;

LGCAPPTYPE=RUCP indicates the subsystem 0 of the SPU is MPU.

RAN14.0




6

2.3 DPU DSP Load

The performance of a DPU is measured by its DSP usage. An RNC can house multiple DPU

boards. Each DPUb or DPUe board contains several DSPs.

Load on an RNC can be dynamically balanced between all its DSPs. The DPU resource usage

(the DSP load) is indicated by the counter VS.DSP.UsageAvg (the mean DSP load expressed

in percentage).

It is recommended that the average DPU DSP usage be not higher than 60%. If the DPU DSP

usage is higher than 60% in the busy hour for three consecutive days in one week, expand the

DPU capacity.

2.4 Interface Board Load

The interface board performance is measured by its CPU usage (for forwarding load or

session load). An RNC can house several interface boards. If an interface board is overloaded,

re-allocate the load to other interface boards or add an interface board.

The interface board resource usage is indicated by the following counters:

VS.INT.CPULOAD.MEAN: mean CPU usage of an interface board, which is expressed

in percentage.

VS.INT.TRANSLOAD.RATIO.MEAN: mean forwarding load of an interface board,

which is expressed in percentage.

Session load = VS.INT.CFG.INTERWORKING.NUM/Number of session setup or

release times x 60 x SP

where

VS.INT.CFG.INTERWORKING.NUM: indicates the number of call setup attempts on an

interface board.

SP: indicates the measurement period, expressed in minutes.

Number of session setup or release times (per second): 500 for a single-core interface

board (1000 for the GOUa and FG2a) and 5000 for a multi-core interface board.

It is recommended that you expand the interface board capacity if the mean CPU usage or the

session load is higher than 50% or the forwarding load is higher than 70% for three

consecutive days in one week.

2.5 Uplink Load

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

means that the total received noise (or total received power) in a cell can be used to measure

the uplink cell capability.

In a WCDMA system, the RTWP value minus the cell background noise is the noise increase

that results from a service increase. The noise increase (%) represents the uplink service

increase. For example, a 3 dB noise increase corresponds to 50% uplink load and a 6 dB noise

increase corresponds to 75% uplink load.

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

dBm. For the relationship between RTWP, noise increase, and uplink load, see Figure 2-3.

RAN14.0




7

Figure 2-3 Relationship between RTWP, noise increase, and uplink load

Generally, the uplink load threshold is 75% and the corresponding RTWP is smaller than –100

dBm. The corresponding equivalent number of users (ENU) ratio should be smaller than 75%

if the power-based admission decision is based on algorithm 2 (the algorithm for the ENU).

If the RTWP value is larger than –100 dBm, the cell is overloaded in the uplink direction.

Generally, if a cell is overloaded or the RTWP value is too large, the cell coverage decreases,

live service quality declines, or new service requests are rejected.

Huawei RNCs support the following RTWP and ENU counters:

VS.MeanRTWP: mean RTWP in a cell (unit: dBm)

VS.MinRTWP: minimum RTWP in a cell (unit: dBm)

VS.RAC.UL.EqvUserN: uplink mean ENU on all dedicated channels in a cell

UlTotalEqUserNum: maximum ENU that is configured by the ADD UCELLCAC

command.

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

In some areas, the background noise increases to more than –106 dBm due to other

interference or hardware faults (for example, poor quality of antennas or feeder connectors).

In this case, the VS.MinRTWP counter value (RTWP when the cell carries no traffic) is

considered the background noise.

If the VS.MinRTWP value is larger than –100 dBm or smaller than –110 dBm in the idle hour

for three consecutive days in one week, there are hardware faults or external interference.

Locate and rectify the faults.

Normally, VS.MeanRTWP is used as the cell capacity indicator. If the VS.MeanRTWP value

is higher than –100 dBm (corresponding to a 6 dB noise increase or 75% load) or the uplink

ENU ratio is higher than 75% in the busy hour for two or three days in one week, the cell is

regarded as heavily loaded.

When the cell is heavily loaded, perform capacity expansion operations such as adding a

carrier or increasing the UlTotalEqUserNum values.

RAN14.0




8

2.6 Downlink Load

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

determined by the base station amplifier and by software settings.

When the downlink power is exhausted, the following may occur:

The cell coverage decreases.

The data throughput decreases.

The service quality declines.

New call requests are rejected.

The amount of consumed downlink power in a cell is not only related to cell traffic (or load),

but also related to the user's location and the cell coverage. The larger the cell coverage and

the farther the user is located from the cell, the more power is consumed. The heavier the

traffic in a cell, the more power is consumed.

In a WCDMA system, TCP is defined to measure the downlink total transmit power. For

Huawei RNCs, four TCP-associated counters are defined:

VS.MeanTCP: mean carrier transmit power in a cell

VS.MaxTCP: maximum carrier transmit power in a cell

VS.MinTCP: minimum carrier transmit power in a cell

VS.MeanTCP.NonHS: mean downlink carrier transmit power for non-HSDPA in a cell

VS.MeanTCP is used as the downlink load indicator. If VS.MeanTCP is constantly higher

than 85% VS.MaxTCP, the cell is overloaded in the downlink direction.

Some live UTRAN networks use hierarchical cell structures with multiple frequency layers.

The downlink power settings and the corresponding downlink TCP thresholds vary by carrier.

For example,

If the maximum TCP value is 20 W (43 dBm), the downlink TCP threshold is 17 W (42.3

dBm).

If the maximum TCP value is 40 W (46 dBm), the downlink TCP threshold is 34 W (45.3

dBm).

If VS.MeanTCP or VS.MaxTCP exceeds 85% of its threshold in the busy hour for three

consecutive days in one week, the cell is regarded as heavily loaded in the uplink direction.

Perform capacity expansion operations such as adding a carrier.

2.7 CE Usage

CE resources are baseband resources in a NodeB. One CE is the resources consumed by a

12.2 kbit/s voice call. If a new call arrives but there are not enough CEs (not enough baseband

processing resources), the call will be blocked.

CE resources are managed and shared at the NodeB level (note that 850 MHz and 1900 MHz

cells cannot share CEs with each other, because the cells belong to different license groups).

The total available CE resources are limited by both the installed hardware and the configured

software licenses. If the hardware resources in the current installation are sufficient and the

CEs are only limited by licenses, then the corrective action is to modify the license file to expand the cell capacity.

RAN14.0




9

The usage metric can also be used to monitor CE resources. Once the CE usage is consistently

higher than the threshold 70%, the NodeB is overloaded, with respect to CE usage. CE

expansion is required.

Since separate baseband processing units are used in the uplink and downlink, CE

management is also separate for the uplink and downlink. CE usage for the uplink and

downlink is defined as:

NodeB_UL_CE_MEAN_RATIO = UL Mean CE Used Number / UL NodeB CE Cfg Number

If VS.NodeB.ULCreditUsed.Mean>0, it indicates that CE OVERBOOKING feature is

available, then UL Mean CE Used Number= VS.NodeB.ULCreditUsed.Mean/2 ,otherwise

UL Mean CE Used Number = Sum_AllCells_of_NodeB(VS.LC.ULCreditUsed.Mean/2),

VS.LC.ULCreditUsed.Mean counts usage of UL Credit for cell, “/2” is for the uplink credit

number is twice the number of uplink CEs, and the downlink credit number is equal to the

number of downlink CEs.

UL NodeB CE Cfg Number = MIN(NodeB License UL CE Number, NodeB Physical UL CE

Capacity)

NodeB_DL_CE_MEAN_RATIO = DL Mean CE Used Number / DL CE Cfg Number

Where,

DL Mean CE Used Number = Sum_AllCells_of_NodeB(VS.LC.DLCreditUsed.Mean),

VS.LC.DLCreditUsed.Mean counts usage of DL Credit for cell.

DL CE Cfg Number = MIN(NodeB License DL CE Number, NodeB Physical DL CE

Capacity)

The counter is from RNC.

The License CE Number is distributed by M2000, the NodeB Physical CE Capacity is calculation by

NodeB board configuration and board specification(MML query).

2.8 OVSF Code Usage

In a WCDMA system, channels are distinguished by code. For each channel, two types of

codes are available: scramble code and orthogonal variable spreading factor (OVSF) code.

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

In the downlink, each cell is allocated a unique scramble code. That is, the users in a cell use

the same scramble code. Each user in a cell is allocated a unique OVSF code.

In a WCDMA cell, data from different users is distinguished based on code division and all

user data is transmitted over the same frequency almost at the same time. OVSF codes

provide perfect orthogonality, minimizing interference between data from different users.

Figure 2-4 shows an OVSF code tree.

RAN14.0




10

Figure 2-4 OVSF code tree

A maximum spreading factor (SF) of 256 is supported.

For a cell, only an OVSF code tree is available, with sibling codes orthogonal to each other

but not with their parent or child codes. As a result, once a code is allocated to a user, neither

its parent nor child code can be allocated to any other user. The total OVSF resources are

limited. If available OVSF codes are insufficient to implement the desired QoS, a new call

request may be rejected.

An OVSF code tree can be divided to four codes (SF = 4), 8 codes (SF = 8), 16 codes (SF =

16), or 256 codes (SF = 256). This means that code resources with various SFs can be

considered N x equivalent SF = 256 codes. For example, one SF = 8 code is equivalent to

thirty-two SF = 256 codes. Based on this equivalence mapping, the OVSF code usage for a

user or a cell can be calculated.

A Huawei RNC monitors the average code usage of an OVSF code tree based on the number

of occupied equivalent SF = 256 codes. The average code usage of an OVSF code tree is

indicated by the VS.RAB.SFOccupy counter.

OVSF code usages are defined as follows:

OVSF_Utilization = VS.RAB.SFOccupy/256

DCH_OVSF_Utilization = DCH_OVSF_CODE/256

where

DCH_OVSF_CODE = (<VS.SingleRAB.SF4> + <VS.MultRAB.SF4>) x 64 +

(<VS.MultRAB.SF8> + <VS.SingleRAB.SF8>) x 32 + (<VS.MultRAB.SF16> +

<VS.SingleRAB.SF16>) x 16 + (<VS.SingleRAB.SF32> + <VS.MultRAB.SF32>) x 8 +

(<VS.MultRAB.SF64> + <VS.SingleRAB.SF64>) x 4 + (<VS.SingleRAB.SF128> +

<VS.MultRAB.SF128>) x 2 + (<VS.SingleRAB.SF256> + <VS.MultRAB.SF256>)

A threshold (such as 70%) can be defined for DCH_OVSF_Utilization to judge whether a cell

runs out of OVSF codes. If OVSF code resources are insufficient in the busy hour for three

consecutive days in one week, perform capacity expansion operations such as adding a carrier

or splitting the cell.

RAN14.0




11

2.9 Iub Bandwidth

Iub bandwidth needs to be monitored. Based on transport media, Iub transport is classified

into ATM transport and IP transport.

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

average uplink/downlink load. You can learn the Iub bandwidth usage by comparing the

average uplink/downlink load and the total Iub bandwidth.

On an ATM transport network, Huawei RNCs and NodeBs can dynamically adjust the

bandwidth allowed for each user based on the service QoS requirements and user priorities,

and use reverse pressure to increase Iub bandwidth usage efficiency. On an IP transport

network, however, Huawei RNCs can use only upper-layer (RLC layer, for example)

measures to prevent packet loss over an Iub interface.

If calls are frequently rejected due to too many users accessing the network, the Iub

bandwidth may be insufficient. If so, increase Iub interfaces as required.

For an IP transport network, it is recommended that you do not monitor Iub bandwidth during

the implementation phase of the prediction-based monitoring method.

2.10 Common Channels

Capacities of common channels, such as PCHs , RACHs and FACHs. If common channels

capacities are insufficient, messages may be lost.

A PCH is used to transport paging messages.

An FACH or RACH is used to transport user signaling and a small amount of user data.

Common channel analysis needs to be conducted based on monitoring of PCHs, FACHs and

RACHs. A paging message may be lost if the PCH usage is too high. Paging messages are

broadcast across an entire LAC. Therefore, improper LAC planning will contribute to high

PCH usage. Two major sources contribute to FACH traffic: PS service state transition and

RRC signaling traffic.

Based on the default configurations for Huawei RNCs, the PCH usage and FACH usage are

calculated as follows:

PCH usage = VS.UTRAN.AttPaging1/(<SP> *60*5/0.01)

Usage of an FACH carried on a non-standalone SCCPCH =

VS.CRNCIubBytesFACH.Tx *8/[(60 *<SP> *168

*1/0.01)*VS.PCH.Bandwidth.UsageRate *6/7 + [60 *<SP> *360 *1/0.01)*(1-

VS.PCH.Bandwidth.UsageRate *6/7)]

where,

VS.PCH.Bandwidth.UsageRate = <VS.CRNCIubBytesPCH.Tx>

/( <VS.CRNC.IUB.PCH.Bandwidth> *SP *60.0)

Usage of an FACH carried on a stand-alone SCCPCH

FACH Utility Ratio = ((VS.SRBNum.FACH-VS.OneSRBTTINum.FACH)/2

+VS.OneSRBTTINum.FACH + VS.IndepTRBNum.FACH) /(3600/0.01)

In the preceding formulas, SP indicates the measurement period in minutes.

RACH usage

RAN14.0




12

There is one RACH channel in a cell. When both signaling and traffic exist，RACH Utility

Ratio could be calculated as follow：

RACH Utility Ratio= (（VS.CRNCIubBytesRACH.Rx - VS.TRBNum.RACH*360/8）*8/168)

/ ({sp} * 60 * 4 / 0.02))+ VS.TRBNum.RACH/ ({sp} * 60 * 4 / 0.02)

The basic principles for evaluating PCHs are as follows:

If paging messages are not re-transported, 5% of them will be lost when the PCH usage

reaches 60%. It is recommended that you troubleshoot this message loss or replan the

LAC.

If paging messages are re-transported once or twice, 1% of them will be lost when the

PCH usage reaches 70%. It is recommended that you troubleshoot this message loss or

replan the LAC.

The basic principle for evaluating FACHs is as follows:

If the FACH usage reaches 70%, it is recommended that you optimize specific policies or

parameters, or add FACHs as required.

The basic principle for evaluating RACHs is as follows:

If the RACH usage reaches 70%，adding carriers will be recommended.

2.11 NodeB CPU Load

Main control and transmission board, baseband boards, and extension transmission boards are

most likely to be overloaded on a network with many smart terminals. When the CPU on any

of the preceding boards is overloaded, the signaling message discard ratio increases and new

call requests are rejected.

The signaling performance of these boards is measured by their mean CPU usage

(VS.BRD.CPULOAD.MEAN) expressed in percentage.

It is recommended that you perform capacity expansion (such as splitting the corresponding

NodeB or adding a NodeB) if VS.BRD.CPULOAD.MEAN is greater than 60% in the busy

hour for three consecutive days in one week.

2.12 CNBAP Load of the NodeB Main Processing and Transmission Unit (WMPT/UMPT)

The NodeB main processing and transmission unit (WMPT/UMPT) processes signaling

messages and manages resources for other boards.

If the main processing and transmission unit is overloaded, a radio link will fail to be set up or

a radio link setup request will not receive a response. This significantly decreases KPIs, such

as the RRC connection setup success rate and RAB setup success rate.

To address this issue, Huawei uses the control NodeB application part (CNBAP) load ratio to

assess the processing capacity of the main processing and transmission unit.

If soft handover factor < 0.4

RAN14.0




13

If soft handover factor ≥ 0.4

where

VS.RadioLink.Recv.Mean: indicates the average number of wireless connection

receptions per second. It is a NodeB counter.

VS.DedicMeaRpt.MEAN: indicates the average number of dedicated measurement

reports per second. It is also a NodeB counter.

SP: indicates the measurement period. It is expressed in minutes.

CNBAP Capacity of NodeB: depends on the configurations of main processing and

transmission units, baseband processing boards, and extended transmission boards.

Note: Generally, VS.DedicMeaRpt.MEAN can be ignored. In the second formula,

VS.DedicMeaRpt.MEAN/12 is used for equivalent conversion.

The soft handover factor is a cell-level counter.

Soft handover factor =

((<VS.SHO.AS.1RL> + <VS.SHO.AS.2RL> + <VS.SHO.AS.3RL> + <VS.SHO.AS.4RL> +

<VS.SHO.AS.5RL> + <VS.SHO.AS.6RL>)/(<VS.SHO.AS.1RL> + <VS.SHO.AS.2RL> /2 +

<VS.SHO.AS.3RL> /3 + <VS.SHO.AS.4RL> /4 + <VS.SHO.AS.5RL> /5 +

<VS.SHO.AS.6RL> /6)) – 1

VS.SHO.AS.1RL: Mean Number of UEs with One Radio Link for Cell; RNC counter

VS.SHO.AS.2RL: Mean Number of UEs with Two Radio Links for Cell; RNC counter

VS.SHO.AS.3RL: Mean Number of UEs with Three Radio Links for Cell; RNC counter

VS.SHO.AS.4RL: Mean Number of UEs with four Radio Links for Cell; RNC counter

VS.SHO.AS.5RL: Mean Number of UEs with five Radio Links for Cell; RNC counter

VS.SHO.AS.6RL: Mean Number of UEs with six Radio Links for Cell; RNC counter

The NodeB soft handover factor equals the average soft handover factor of all cells under the

NodeB.

If the CNBAP Load Ratio is higher than 60% in the busy hour for three consecutive days in

one week, the main processing and transmission unit is becoming overloaded. If this happens,

add a baseband processing board or an extended transmission board, or split the NodeB.

RAN14.0

Capacity Monitoring Guide 3 HSPA Related Resources



14

3 HSPA Related Resources

High Speed Packet Access (HSPA) includes High Speed Downlink Packet Access (HSDPA)

and High Speed Uplink Packet Access (HSUPA). HSDPA and HSUPA functionalities are part

of the WCDMA standard. HSPA uses technologies such as fast scheduling, adaptive

modulation, and hybrid automatic repeat request (HARQ) to transport data at high speed.

HSPA carries PS data. As conversational services are prioritized over PS data, HSPA uses

system resources only after conversational services are served. This chapter looks into how to

efficiently use the system resources by means of HSPA without changing the existing pattern

for resource allocation.

3.1 HSDPA

3.1.1 Power Resources

Figure 3-1 illustrates how the downlink transmit power of a cell is allocated. The dashed line

indicates the total downlink transmit power of a cell.

Figure 3-1 Dynamic power resource allocation

RAN14.0




15

Power for CCH: This portion of power is allocated to common transport channels (CCHs) of

the cell such as the broadcast channel, pilot channel, and paging channel.

Power margin: This portion of power is not allocated. The power margin is reserved to ensure

that the system can remain stable even if the UE position or environment changes.

Power for DPCH: This portion of power is allocated to real-time services (voice and video

calls) and PS R99 services, and varies with the number and locations of users. RNCs and UEs

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

HSDPA user power = Maximum cell transmit power – (Power for CCH + Power margin +

Power for DPCH)

HSPA power schedulers are designed primarily to make the most of available power.

In an HSDPA-enabled cell, TCP is still monitored to see if the system is overloaded 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 Code Resources

HSDPA can share code resources with real-time services. The system can dynamically

reallocate OVSF codes to HSDPA services and real-time services based on OVSF code

allocation settings (such as the number of codes reserved only for HSDPA and the number of

codes that can be shared). These settings can be changed online based on the network plan.

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

is not enabled. Note that a high OVSF usage can be reduced by adjusting OVSF code

allocation settings (such as the number of codes reserved only for HSDPA and the number of

codes that can be shared).

Figure 3-2 OVSF code sharing

RAN14.0




16

3.2 HSUPA

3.2.1 CE Resources

HSUPA channels are dedicated channels, and resource consumption of HUSPA services is

measured by CE. UL CEs are shared between R99 services and HSUPA services.

HSUPA improves user experience and uplink throughput, but also consumes more uplink CE

overhead for hybrid automatic repeat requests (HARQ) and soft handovers. This means that

uplink CE resources may become a system bottleneck. Therefore, uplink CE usage needs to

be monitored when HSUPA is enabled.

Huawei NodeBs support dynamic HSUPA CE management.

3.2.2 RTWP

Similar to HSDPA, which is designed to make the most of the downlink power, HSUPA is

designed to make the most of uplink capacity margin. HSUPA is always authorized to send

data until the RTWP rises to 6 dBm.

HSUPA provision increases uplink data throughput but also consumes a large amount of

uplink RTWP, which is monitored in the same way regardless of whether HSUPA is

provisioned. If RTWP overload occurs, rates of HSUPA services must be lowered to ensure

QoS of conversational services.

RAN14.0

Capacity Monitoring Guide 4 Diagnosis of Problems Related to Network Resources



17

4 Diagnosis of Problems Related to Network Resources

The preceding chapters describe the basic methods of monitoring network resources. These

methods can be used to resolve most problems caused by high resource usage. In certain

scenarios, further analysis is required to determine whether high resource usage is caused by a

traffic increase or other exceptions.

This chapter describes how to diagnose problems related to network resources. This chapter is

intended for experts who have a deep understanding of WCDMA networks.

4.1 Call Blocks in the Basic Call Flow

When network resources are running out, KPIs related to system accessibility are most likely

to be affected first.

Figure 4-1 shows the basic call flowchart where possible block and failure points are marked.

For details about the call flow, see 3GPP TS 25.931.

RAN14.0




18

Figure 4-1 Call flowchart where possible block and failure points are marked

The call flow, which uses a mobile-terminated call as an example, is described as follows:

Step 1 The CN sends a paging message to the RNC.

Step 2 Upon receipt of the paging message, the RNC broadcasts the message on a PCH. If the PCH

is congested, the RNC may drop the message. See block point #1.

Step 3 The UE cannot receive the paging message or fails to connect to the network. See failure

point # 2.

Step 4 After receiving the paging message, the UE sends an RRC connection request to the RNC.

Step 5 If the RNC is congested when receiving the RRC connection request, the RNC may drop the

request. See block point #3.

RAN14.0




19

Step 6 If the RNC receives the RRC connection request and does not drop it, the RNC determines

whether to accept or reject the request. The request may be rejected due to insufficient

resources. See block point #4.

Step 7 If the RNC accepts the request, the RNC instructs the UE to set up an RRC connection. The

RRC connection setup may fail, the UE does not receive the instruction, or the UE receives

the message but finds the configuration information to be incorrect. See failure points #5 and

#6.

Step 8 After the RRC connection is set up, the UE sends NAS messages to negotiate 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.

Step 9 The RNC accepts or rejects the RAB assignment request based on the resource usage on the

RAN side. See block point #7.

Step 10 If the RNC accepts the RAB assignment request, the RNC initiates an RB setup process.

During the process, the RNC sets up transmission resources over the Iub interface by setting

up a radio link (RL) to the NodeB, and sets up channel resources over the Uu interface by

sending an RB setup message to the UE. A failure may occur in the RL or RB setup process.

See failure points #8 and #9.

4.2 Call Congestion Counters

As shown in Figure 4-1, call congestion may occur during paging, RRC connection setup, or

RAB establishment.

The following describes performance counters and KPIs associated with call congestion rates.

For details about call congestion counters, see chapter 5 "Counter Definitions." You can also

refer to the BSC6900 UMTS Performance Counter Reference and 3900 Series WCDMA NodeB Performance Counter Reference.

4.2.1 Performance Counters Associated with Paging Loss

RNC-level and cell-level performance counters can be used to measure paging loss rates:

Paging loss (RNC)

Counters indicating that RNC-level paging loss ratio are caused by Iu-interface flow

control, CPU overload, or RNC-level PCH congestion: VS.RANAP.CsPaging.Loss and

VS.RANAP.PsPaging.Loss

Iu-interface paging loss ratio (RNC) = [(VS.RANAP.CsPaging.Loss +

VS.RANAP.PsPaging.Loss)/(VS.RANAP.CsPaging.Att + VS.RANAP.PsPaging.Att)] x

100%

Paging loss (Cell)

Counter indicating that paging requests are discarded due to cell-level PCH congestion:

VS.RRC.Paging1.Loss.PCHCong.Cell

Iu-interface paging loss ratio (cell) =

(VS.RRC.Paging1.Loss.PCHCong.Cell/VS.UTRAN.AttPaging1) x 100%

4.2.2 Performance Counters Associated with RRC Congestion Rates

RRC congestion rates are associated with:

RAN14.0




20

Insufficient uplink power resources: VS.RRC.Rej.ULPower.Cong

Insufficient downlink power resources: VS.RRC.Rej.DLPower.Cong

Insufficient uplink CE resources: VS.RRC.Rej.UL.CE.Cong

Insufficient downlink CE resources: VS.RRC.Rej.DL.CE.Cong

Insufficient uplink Iub bandwidth resources: VS.RRC.Rej.ULIUBBand.Cong

Insufficient downlink Iub bandwidth resources: VS.RRC.Rej.DLIUBBand.Cong

Insufficient downlink code resources: VS.RRC.Rej.Code.Cong

Number of RRC requests: VS.RRC.AttConnEstab.Sum

The following is the formula for calculating the paging loss ratio:

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

Where

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

< VS.RRC.Rej.UL.CE.Cong > + < VS.RRC.Rej.DL.CE.Cong > +

< VS.RRC.Rej.ULIUBBand.Cong > + < VS.RRC.Rej.DLIUBBand.Cong > +

< VS.RRC.Rej.Code.Cong >

4.2.3 Performance Counters Associated with RAB Congestion Rates

RAB congestion rates are associated with:

Insufficient power resources

− VS.RAB.FailEstabCS.ULPower.Cong

− VS.RAB.FailEstabCS.DLPower.Cong

− VS.RAB.FailEstabPS.ULPower.Cong

− VS.RAB.FailEstabPS.DLPower.Cong

Insufficient uplink CE resources

− VS.RAB.FailEstabCS.ULCE.Cong

− VS.RAB.FailEstabPS.ULCE.Cong

Insufficient downlink CE resources

− VS.RAB.FailEstabCs.DLCE.Cong

− VS.RAB.FailEstabPs.DLCE.Cong

Insufficient downlink code resources

− VS.RAB.FailEstabCs.Code.Cong

− VS.RAB.FailEstabPs.Code.Cong

Insufficient downlink Iub bandwidth resources

− VS.RAB.FailEstabCS.DLIUBBand.Cong

− VS.RAB.FailEstabCS.ULIUBBand.Cong

− VS.RAB.FailEstabPS.DLIUBBand.Cong

− VS.RAB.FailEstabPS.ULIUBBand.Cong

Number of RAB setup requests: VS.RAB.AttEstab.Cell

RAN14.0




21

The following is the formula for calculating the call congestion ratio:

VS.RAB.Block.Rate = Total number of congestions due to the preceding

causes/VS.RAB.AttEstab.Cell

4.3 Signaling Storms and Solutions

In busy hours, a smart terminal makes about 10 more call attempts than a common terminal

per call. The additional call attempts generate massive signaling exchange and occupy a large

amount of signaling processing resources of the RNC and NodeB on the control plane.

RAN14.0




22

Figure 4-2 Process for analyzing signaling storms

Table 4-1 provides solutions to signaling storms. These solutions attempt to reduce signaling

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

RAN14.0




23

Table 4-1 Signaling storm causes and solutions

UE Behavior UE Type Solution

No signaling connection

release indication (SCRI)

Nokia, Samsung, or

Motorola feature phones

Enable the Cell_PCH function to decrease signaling

services for these terminals.

SCRI without values

indicating causes

iPhone (R6) Enable the enhanced fast dormancy (EFD) function for

RNCs and add international mobile equipment

identities (IMEIs) of terminals to the whitelist.

R8 terminals with SCRI

carrying values

indicating causes

iPhone4 (after R6) Enable the R8 FD function for RNCs and add terminal

IMEIs to the whitelist.

4.4 Resource Analysis

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

RAN14.0




24

Figure 4-3 General troubleshooting process

Generally, an abnormal KPI initiates a troubleshooting process. Determining the top N cells

that may have problems facilitates follow-up troubleshooting.

It is recommended to analyze accessibility KPIs to identify the system bottleneck that causes

access congestion.

RAN14.0




25

Figure 4-4 Key points for bottleneck analysis

4.4.1 CE Resource Consumption Analysis

Cells under one NodeB share CEs. Common channels have reserved CE resources and

signaling is carried on a channel accompanying the DCH. Therefore, CCHs and signaling are

considered not to consume CEs.

Table 4-2 Number of CEs consumed by different services

Service Type Number of Consumed CEs on the Uplink

Number of Consumed CEs on 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*SF4 (HSUPA) 16 N/A

2*SF2 (HSUPA) 32 N/A

RAN14.0




26

Service Type Number of Consumed CEs on the Uplink

Number of Consumed CEs on the Downlink

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

2xM2+2xM4 64 N/A

NOTE CE usage in Table 4-2 assumes that the signaling radio bearer (SRB) over HSUPA feature is enabled. If

the SRB is carried on an R99 DCH independently, an extra CE is consumed by the SRB. Therefore, add

one CE to the number listed in Table 4-2.

HSDPA services do not consume downlink R99 CEs. HSUPA services and R99 services share

uplink CEs.

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

If the CE resource usage is higher than a preset threshold for a period of time or CE

congestion occurs, the CE resources are insufficient and must be increased to ensure system

stability.

RAN14.0




27

Figure 4-5 Process for analyzing CE resource consumption

Cells belonging to the same NodeB share CEs and CE resources consumed by a NodeB must

be manually calculated.

Check whether CE resource congestion occurs in a resource group or an entire site. If CE

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

CE resource congestion occurs in an entire site, perform site capacity expansion and

reconfigure CEs as required.

RAN14.0




28

4.4.2 Code Resource Usage Analysis

Huawei RNCs can reserve codes (for example, five SF = 16 codes) for HSDPA services. If

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

In some scenarios, massive signaling exchange on the network occupies a large amount of

codes, causing code congestion, power congestion, or CPU overload. In these scenarios,

identify root causes and rectify faults rather than expanding capacity.

If code congestion occurs, operators can perform the following operations before expanding

capacity:

Decrease the maximum number of PS RABs.

Enable code-based load reshuffling (LDR).

Decrease the minimum number of codes reserved for HSDPA services.

Activate the license for dynamic code allocation on the NodeB.

Thresholds for the preceding code congestion-related operations must be set based on

operators' requirements for services quality.

4.4.3 Iub Resource Analysis

NOTE After IP RAN is introduced, Iub resources no longer need to be monitored. This section is retained to

provide 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 higher than 80% for a certain period, it can be determined

that the Iub bandwidth is insufficient.

If no more Iub resources are available or the issue is not urgent, decrease PS activity factors

so the system admits more users. The activity factor, which is the ratio of actual bandwidth

occupied by a user to the allocated bandwidth, is used to estimate the real bandwidth needed

in admission. The activity factor can be set on a per-NodeB basis. The default activity factor

is 70% for voice services and 40% for PS BE services.

RAN14.0




29

Figure 4-6 Process for analyzing Iub resources

4.4.4 Power Resource Analysis

Power congestion occurs if RTWP and TCP values are larger than preset thresholds.

If downlink power congestion occurs, enable the LDR and OLC function.

If uplink power is restricted, check whether any interference exists.

In most cases, interference rather than traffic increase causes uplink power restriction.

If RTWP is larger than –97 dBm over a period of time, analyze root causes and troubleshoot

the problem.

For high RTWP caused by high traffic (instead of signaling storms):

Workaround: Enable the LDR and OLC functions.

Solution: Add carriers or split cells.

RAN14.0




30

Figure 4-7 Process for analyzing power resources

Adding carriers is the most efficient solution to insufficient uplink power. If no more carriers

are available, add more sites or tilt down antennas to spit cells.

4.4.5 SPU CPU Usage Analysis

Among all RNC CPUs, SPU CPUs are the most likely resources to cause system bottlenecks

because smart terminals often cause signaling storms on networks.

If the SPU CPU usage is higher than the SPU CPU alarming threshold, RNCs will enable the

flow control function to discard some RRC setup or paging requests. Ensure that the CPU

usage is not higher than the SPU CPU alarming threshold.

RAN14.0




31

Figure 4-8 Process for analyzing SPU CPUs

If the SPU CPU usage is higher than 50%, advise customers to add SPU boards. If SPU CPU

usage is higher than 60%, add SPU boards immediately.

Check whether SPU subsystem loads are balanced. If they are unbalanced, adjust load sharing

thresholds so that subsystems share loads evenly.

In addition, identify root causes for the high CPU usage.

If signaling storms occur, check whether system configurations are correct or the transmission

link is interrupted. If high traffic causes the high CPU usage, add SPU boards to expand capacity.

RAN14.0




32

4.4.6 DPU DSP and Interface Board CPU Usage Analysis

If the DPU DSP or interface board CPUs are overloaded, the RNC will drop some user data.

The DPU DSP and interface board loads must be monitored closely.

Figure 4-9 Process for analyzing DPU DSP and interface board CPU usage

If the DPU DSP or interface board CPU usage is higher than 60%, add DPU boards or

interface boards.

Add hardware for capacity expansion if traffic increase or unbalanced transmission

causes the high loads.

4.4.7 PCH Usage Analysis

In most cases, PCHs are overloaded because a LAC area covers too many cells.

Replan LAC areas to resolve the PCH overload issue.

RAN14.0




33

Figure 4-10 Process for analyzing PCH usage

4.4.8 FACH Usage Analysis

Usually no FACH congestion will occur if the UE state transition switch is turned off.

However, the UE state transition switch is turned on by default to transfer low traffic services

to FACHs. This saves radio resources but increases traffic on FACHs.

Two solutions are available for resolving the FACH congestion issue:

Decrease values of PS inactive timers to transfer PS services to the CELL_PCH or IDLE

state and set up RRC connections on DCHs instead of FACH if DCH resources are

sufficient.

Add an SCCPCH to carry FACHs

RAN14.0




34

Figure 4-11 Process for analyzing FACH usage

RAN14.0

Capacity Monitoring Guide 5 Counter Definitions



35

5 Counter Definitions

Counter Name Counter Definition

Congestion Counter

Call drop ratio Vs.Call.Block.Rate (custom) Vs.RRC.Block.Rate +

(<RRC.SuccConnEstab.sum>/(<VS.RRC.AttCon

nEstab.CellDCH> +

<VS.RRC.AttConnEstab.CellFACH>)) x

Vs.Rab.Block.Rate

RRC congestion

ratio

Vs.RRC.Block.Rate (custom) (<VS.RRC.Rej.ULPower.Cong> +

<VS.RRC.Rej.DLPower.Cong> +

<VS.RRC.Rej.ULIUBBand.Cong> +

<VS.RRC.Rej.DLIUBBand.Cong> +

<VS.RRC.Rej.ULCE.Cong> +

<VS.RRC.Rej.DLCE.Cong> +

<VS.RRC.Rej.Code.Cong>)/<VS.RRC.AttConn

Estab.Sum>

RAB congestion

ratio

Vs.RAB.Block.Rate (custom) (<VS.RAB.FailEstabCS.ULPower.Cong> +

<VS.RAB.FailEstabCS.DLPower.Cong>

+<VS.RAB.FailEstabPS.ULPower.Cong> +

<VS.RAB.FailEstabPS.DLPower.Cong> +

<VS.RAB.FailEstabCS.ULCE.Cong> +

<VS.RAB.FailEstabPS.ULCE.Cong> +

<VS.RAB.FailEstabCs.DLCE.Cong> +

<VS.RAB.FailEstabPs.DLCE.Cong> +

<VS.RAB.FailEstabCs.Code.Cong> +

<VS.RAB.FailEstabPs.Code.Cong> +

<VS.RAB.FailEstabCS.DLIUBBand.Cong> +

<VS.RAB.FailEstabCS.ULIUBBand.Cong> +

<VS.RAB.FailEstabPS.DLIUBBand.Cong> +

<VS.RAB.FailEstabPS.ULIUBBand.Cong>)/VS.

RAB.AttEstab.Cell

RAN14.0




36


Call attempts VS.RAB.AttEstab.Cell (custom) (<VS.RAB.AttEstCS.Conv.64> +

<VS.RAB.AttEstab.AMR> +

<VS.RAB.AttEstabPS.Conv> +

<VS.RAB.AttEstabPS.Str> +

<VS.RAB.AttEstabPS.Inter> +

<VS.RAB.AttEstabPS.Bkg>)

Usage Counter

Power Usage Counter

R99_TCP_Utiliz

ation_Ratio

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

CP (43 dBm or 46 dBm)

Total_TCP_Utili

zation_Ratio

VS.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 Usage Counters

IUB BW usage NODEB_Throughput (custom)

NODEB_Trans_Cap (custom)

NODEB_Throughput/NODEB_Trans_Cap

NODEB_Trans_

Cap

VS.IPDLTotal.1

VS.IPDLTotal.2

VS.IPDLTotal.3

VS.IPDLTotal.4

(VS.IPDLTotal.1 + VS.IPDLTotal.2 +

VS.IPDLTotal.3 + VS.IPDLTotal.4)

NODEB_Throug

hput

NODEB_Throughput_DL (custom)

NODEB_Throughput_UL (custom)

MAX(NODEB_Throughput_DL,

NODEB_Throughput_UL)

NODEB_Throug

hput_DL

VS.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_UL

VS.IPULAvgUsed.1

VS.IPULAvgUsed.2

VS.IPULAvgUsed.3

VS.IPULAvgUsed.4

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

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

RAN14.0




37


PCH/FACH Usage Counter

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

FACH usage VS.CRNCIubBytesFACH.Tx

VS.PCH.Bandwidth.UsageRate

VS.SRBNum.FACH

VS.OneSRBTTINum.FACH

VS.IndepTRBNum.FACH

(1) Utilization of FACH carried on

non-standalone SCCPCH

FACH Utility Ratio =

VS.CRNCIubBytesFACH.Tx *8/((60 *<SP>

*168*1/0.01) *VS.PCH.Bandwidth.UsageRate

*6/7 + (60 *<SP> *360 *1/0.01)*(1-

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

where,

VS.PCH.Bandwidth.UsageRate =

<VS.CRNCIubBytesPCH.Tx>

/( <VS.CRNC.IUB.PCH.Bandwidth> * SP

*60.0)

(2) Utilization of FACH carried on standalone

SCCPCH

FACH Utility Ratio =

((VS.SRBNum.FACH-VS.OneSRBTTINum.FA

CH)/2 +VS.OneSRBTTINum.FACH +

VS.IndepTRBNum.FACH) /(3600/0.01)

OVSF Usage Counter

OVSF usage VS.RAB.SFOccupy VS.RAB.SFOccupy

OVSF usability

ratio

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

DCH OVSF ratio DCH_OVSF_Utilization [(<VS.SingleRAB.SF4> + <VS.MultRAB.SF4>)

x 64 + (<VS.MultRAB.SF8> +

<VS.SingleRAB.SF8>) x 32 +

(<VS.MultRAB.SF16> +


(<VS.SingleRAB.SF32> +

<VS.MultRAB.SF32>) x 8 +

(<VS.MultRAB.SF64> +



<VS.MultRAB.SF128>) x 2 +


<VS.MultRAB.SF256>)]/256

CPU Usage Counter

SPU usage VS.XPU.CPULOAD.MEAN VS.XPU.CPULOAD.MEAN

MPU usage VS.XPU.CPULOAD.MEAN VS.XPU.CPULOAD.MEAN

RAN14.0




38


DPU usage VS.DSP.UsageAvg VS.DSP.UsageAvg

INT CPU Load VS.INT.CPULOAD.MEAN

VS.INT.TRANSLOAD.RATIO.MEA

N

VS.INT.CPULOAD.MEAN

VS.INT.TRANSLOAD.RATIO.MEAN

NodeB CPU

usage

VS.BRD.CPULOAD.MEAN VS.BRD.CPULOAD.MEAN

Credit Usage Counter

UL_CE_MEAN

_RATIO

VS.NodeB.ULCreditUsed.Mean

VS.LC.ULCreditUsed.Mean

VS.LC.DLCreditUsed.Mean

if VS.NodeB.ULCreditUsed.Mean>0

Sum_AllCells_of_NodeB(VS.NodeB.ULCreditU

sed.Mean /2) / MIN(NodeB License UL CE

Number, NodeB Physical UL CE Capacity)

else

Sum_AllCells_of_NodeB(VS.LC.ULCreditUsed.

Mean/2) / MIN(NodeB License UL CE Number,

NodeB Physical UL CE Capacity)

DL_CE_MEAN

_REMAIN

Sum_AllCells_of_NodeB(VS.LC.DLCreditUsed.

Mean) / MIN(NodeB License DL CE Number,

NodeB Physical DL CE Capacity)

5.Capacity Monitoring Guide

Documents

new network

huawei trademarks

document issue

network resource bottlenecks

network resource counters

type of network resource

huawei proprietary

proper network expansion