Capacity Monitoring Guide - R18

RAN18.
1
Capacity Monitoring Guide
(BSC6910-based)
Issue 03
Date 2016-10-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright © Huawei Technologies Co., Ltd. 2016. 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: support@huawei.com
About This Document
1.1 Overview
Growing traffic in mobile networks requires more and more network resources. Lack of
network resources will affect user experience. Therefore, monitoring network resources,
locating bottlenecks, and performing capacity expansion in real time are critical to the
provision of high quality services.
This document describes how to monitor the usage of various network resources and
locate network resource bottlenecks.
This document applies to BSC6910s and 3900 series base stations.
For details about the MML commands, parameters, alarms, and performance counters, see section
"Operation and Maintenance" in the BSC6910 UMTS Product Documentation or 3900 Series Base
Station Product Documentation.
1.2 Intended Audience

Before reading this document, one should familiarize themselves with UMTS basics and
Huawei UMTS RAN products.
This document is intended for personnel who:
 Monitor UMTS RAN network resources
 Optimize UMTS RAN networks
1.3 Change History

This section provides information about the changes in different document versions. There
are two types of changes:
 Technical change
Changes in features and parameters of a specified version
 Editorial change
Changes in wording or addition of information and any related parameters affected by
editorial changes
03 (2016-10-30)
Compared with Issue 02 (2016-04-28) of RAN18.1, 03 of RAN18.1 includes the following
changes.
Change Type Change Description

Technical change None
Editorial change Added descriptions on how to monitor capacity of the NIU
and DEU boards.
02 (2016-04-28)
Compared with Issue 01 (2016-02-29) of RAN18.1, 02 of RAN18.1 includes the following
changes.

Editorial change  Added an item for monitoring the license rate of PS traffic.
 Added differences in license rate monitoring counters
between single-operator scenarios and multi-operator
scenarios.
01 (2016-02-29)
This issue does not include any changes.
Draft A (2015-12-31)
Compared with Issue 02 (2015-05-8) of RAN17.1, Draft A of RAN18.1 includes the
following changes.
Editorial change  Optimized descriptions on optimization suggestions by using

flow charts.
 Optimized descriptions on resource monitoring by using
tables.
 Added descriptions on monitoring thresholds.
Contents
About This Document

1.1 Overview
1.2 Intended Audience
1.3 Change History
1 Overview
1.1 Network Resources
1.2 Monitoring Methods
2 Network Resource Monitoring

2.1 Monitoring Metrics and Procedure
2.2 CP/UP CPU Load
2.3 RMP CPU Load
2.4 Interface Board CPU Load
2.5 SCU CPU Load
2.6 RNC License
2.7 NIU CPU Load
2.8 DEU CPU Load
2.9 Common Channel Usage
2.10 Downlink Load
2.11 Uplink Load
2.12 OVSF Code Usage
2.13 HS-PDSCH Code Usage
2.14 HS-SCCH Code Usage
2.15 Iub/Iu/Iur Bandwidth Usage
2.16 CE Usage
2.17 NodeB CNBAP Load
2.18 HSPA Users
3 Network Resource Troubleshooting

3.1 Possible Block and Failure Points in the Basic Call Flow
3.2 Counters Related to Call Congestion
3.3 Resource Usage Analysis
4 Metrics Definitions
5 Reference Documents
1 Overview
This chapter introduces network resources and monitoring methods.
1.1 Network Resources

Figure 1-1 lists the network resources to be monitored.
Figure 1-1 Network resources to be monitored
1.1.1 RNC Resources

The RNC resources to be monitored include the following:
 Control Plane/User Plane (CP/UP)
In the RNC, GPU boards process signaling on the CP and services on the UP. With
an increase in the traffic volume, if the CP and UP loads of GPU boards exceed the
predefined processing capacity, CP/UP will become a system bottleneck.
 Resource Management Processing (RMP)
The RMP is the main processing unit. If it is heavily loaded, service access will be
affected.
 Interface Board (INT)
RNC interface boards provide transmission ports and resources, process transport
network messages, and exchange data between RNC boards and between the RNC
and external devices. Resource overload on interface boards increases the packet loss
rate, interrupts communications, and affects user experience.
 GE Switching network and Control Unit (SCU)
The SCU provides the function of inter-subrack information exchange in the RNC. If
the traffic volume of inter-subrack communication approaches the overload threshold,
voice service quality, data service quality, and network KPIs deteriorate, affecting
system stability.
 RNC License
The RNC license (BSC6910) can be controlled based on the following license
resource items:
− PS user-plane traffic volume
− Voice traffic volume (Erlangs)
− HSDPA traffic volume
− HSUPA traffic volume
− RNC hardware capacity
− Cell-level HSDPA/HSUPA user number
1.1.2 NodeB Resources

The NodeB resources to be monitored include the following:
 Channel Element (CE)
CEs are baseband processing resources. New call requests will be rejected in the case
of CE insufficiency.
 Common NodeB Application Part (CNBAP)
CNBAP load is used to assess the NodeB processing capacity. CNBAP overload
lowers the NodeB processing capacity, which then affects KPIs related to the NodeB.
 High Speed Packet Access (HSPA) users
HSPA services are carried on the BBP boards in a NodeB. Therefore, the number of
HSPA users determines BBP board loads. If BBP boards are overloaded with HSPA
users, new users may fail to access the network.
1.1.3 Cell Resources

The cell resources to be monitored include the following:
 Received Total Wideband Power (RTWP)
RTWP is used to monitor uplink load. If the RTWP value is too large, the cell
coverage shrinks, the quality of admitted services declines, or new service requests
are rejected.
 Transmitted Carrier Power (TCP)
The TCP refers to the full-carrier power transmitted by a cell. It is used to monitor
downlink load. If the TCP is low, the cell coverage and user throughput shrink, the
quality of admitted services declines, or new service requests are rejected.
 Orthogonal Variable Spreading Factor (OVSF)
OVSF in this document refers to downlink spreading code resources. Insufficient
downlink OVSFs affects UEs' access to the network.
 HS-PDSCH
HS-PDSCHs are used to carry HSDPA services. Insufficient HS-PDSCH codes will
decrease HSDPA data rates.
 HS-SCCH
The HS-SCCH is used to carry control information for HS-PDSCHs. Insufficient HS-
SCCH codes will increase data transmission delay.
 Paging Channel (PCH)
PCH usage is affected by the location area and routing area planning. PCH overload
decreases the paging success rate.
 Random Access Channel (RACH) and Forward Access Channel (FACH)
RACH and FACH carry signaling and a small amount of user-plane data. RACH or
FACH overload decreases the network access success rate and affects user
experience.
1.1.4 Transmission Resources
The transmission resources to be monitored involve the following interfaces:
 Iu interface
The Iu interface lies between the RNC and the CN. Iu interface congestion will cause
RRC connection setup and RAB setup failures.
 Iub interface
The Iub interface lies between the NodeB and the RNC. Insufficient Iub interface
bandwidth leads to admission failures, transmission KPI deterioration (such as delay,
jitter, and packet loss), and UMTS service quality degradation.
 Iur interface
The Iur interface lies between an RNC and its neighboring RNC (NRNC). Iur
interface congestion may cause RRC connection setup and RAB setup failures or
cause inter-RNC handover failures.
1.2 Monitoring Methods

Table 1-1 lists the monitoring methods for network resources.
Table 1-1 Monitoring methods

Method Description Advantage Disadvantage Detailed In
Proactive It is used to It is easy to If resource Network

monitoring simultaneously implement consumption is Resource
monitor various and suitable consistently Monitoring
network for daily greater than its
resources. resource upper threshold,
monitoring. capacity
expansion is
required to
relieve resource
congestion.
Problem- This method It maximizes This method Network

driven can be used to system requires higher Resource
analysis determine capacity. troubleshooting Troubleshooting
system skills.
bottlenecks by
locating
problems.
2 Network Resource Monitoring
This chapter discusses only proactive monitoring.
2.1 Monitoring Metrics and Procedure
2.1.1 Monitoring Metrics

Metrics are defined to monitor the usage or load of UTRAN resources. Resource
thresholds are also recommended based on specific criteria.
Defining peak hours is important for monitoring metrics. It is recommended that you set
the peak hours to the time when the corresponding resource usage is at its highest.
Helping ensure stable network operation, capacity monitoring employs the following thresholds:
 Warning threshold: If this threshold is reached, the corresponding resource status becomes
"Warning" on the PRS.
 Capacity expansion threshold: If this threshold is reached, the corresponding resource status
becomes "Critical" on the PRS. This threshold is lower than the alarm threshold.
Table 2-1 lists RNC resources, counters, and monitoring thresholds.
Table 2-1 RNC resources, counters, and monitoring thresholds

Resource Counter Monitoring
Threshold
CP CPU load VS.CPPOOL.CPULOAD.MEAN 50%
UP CPU load VS.UPPOOL.CPULOAD.MEAN 60%

RMP CPU load VS.CPU.CPULOAD.MEAN 50%
SCU CPU load VS.CPU.CPULOAD.MEAN 60%

Interface board VS.CPU.CPULOAD.MEAN 50%
CPU load
Interface board VS.INT.TRANSLOAD.RATIO.MEAN 70%
Forwarding
load
Table 2-2 lists NodeB resources, counters, and monitoring thresholds.
Table 2-2 NodeB resources, counters, and monitoring thresholds

Resource Monitoring Item Counter Capa
Expan
Thres
CE CE usage  VS.NodeB.ULCreditUsed.Mean 70%
 VS.LC.ULCreditUsed.Mean
 VS.LC.DLCreditUsed.Mean
 VS.HW.DLCreditAvailable
 VS.HW.ULCreditAvailable
CNBAP NodeB CNBAP load  VS.RadioLink.Recv.Mean 60%

 VS.DedicMeaRpt.MEAN
 VS.BTS.CnbapCap.UseRate
HSPA users Percentage of number  VS.BOARD.UsedHsdpaUserRatio.Mean 60%
of HSPA users to the  VS.BOARD.UsedHsupaUserRatio.Mean
configured number of
HSPA users
Table 2-3 Cell resources, counters, and monitoring thresholds

Resource Monitoring Counter Capacity Expansion
Item Threshold
Common PCH usage VS.UTRAN.AttPaging1  70% (paging message
channels re-transmitted)
 60% (paging message
not re-transmitted)
FACH usage VS.CRNCIubBytesFACH.Tx 70%

VS.CRNCIubBytesPCH.Tx
VS.CRNC.IUB.PCH.Bandwidth
RACH usage VS.CRNCIubBytesRACH.Rx 70%

VS.TRBNum.RACH
VS.TRBNum.RACH
DL load Non-HSPA VS.MeanTCP 70%

power usage
TCP usage VS.MeanTCP.NonHS 85%

VS.HSDPA.MeanChThroughput
Resource Monitoring Counter Capacity Expansion
Item Threshold
UL load RTWP VS.MeanRTWP  Higher than –100 dBm
OVSF codes VS.MinRTWP or lower than –110
dBm (for
VS.MinRTWP)
 –90 dBm (for
VS.MeanRTWP)
ENU VS.RAC.UL.EqvUserNum 75%

UlTotalEqUserNum
DCH OVSF VS.RAB.SFOccupy 70%
Usage
HS-PDSCH HS-PDSCH VS.PdschCodeAvail.Mean 70%
codes Code Usage VS.PdschCodeAvail.Mean
HS-SCCH HS-SCCH VS.ScchCodeUtil.Mean 70%

codes Code Usage
Table 2-4 Transport resources, counters, and monitoring thresholds

Resource Monitoring Counter Capacity
Item Expansion
Threshold
Iub/Iur/Iu ATM Admission success VS.AAL2.CAC.Succ 99%
rate VS.AAL2.CAC.Att
Control-plane VS.SAALLNK.PVCLAYER.TXBYTES 70%
bandwidth usage VS.SAALLNK.PVCLAYER.RXBYTES
User-plane VS.AAL2PATH.PVCLAYER.TXBYTES 70%
bandwidth usage VS.AAL2PATH.PVCLAYER.RBYTES
Iub/Iur/Iu IP Admission success VS.ANI.IP.Conn.Estab.Succ 99%

rate VS.ANI.IP.Conn.Estab.Att
VS.ANI.IP.FailResAllocForBwLimit
Control-plane VS.SCTP.TX.BYTES 70%

bandwidth usage VS.SCTP.RX.BYTES
User-plane VS.IPPOOL.ANI.IPLAYER.TXBYTES 70%
bandwidth usage VS.IPPOOL.ANI.IPLAYER.RXBYTES
2.1.2 Monitoring Procedure
This section discusses the network resource monitoring procedure, which can be easily
implemented and works in most scenarios.
The procedure starts with individual resource monitoring. When a resource exceeds a
predefined threshold, it should be cross checked against other resources.
For example, if CE usage is greater than 70% but RTWP, TCP, or OVSF resources are
normal, this indicates that the cell load is normal but CEs are insufficient. In this scenario,
increase the number of CE licenses or add baseband processing boards rather than expand
the NodeB capacity.
Figure 2-1 shows the resource monitoring flowchart.
Figure 2-1 Resource monitoring flowchart
This procedure applies to most resource monitoring scenarios, but sometimes the system
may be overloaded because of other abnormalities instead of traffic increases. Some of
these abnormalities can be discovered by resource cross-checking. If more extensive
resource cross-checking is unsuccessful, advanced troubleshooting is required. Chapter 3
"Network Resource Troubleshooting" addresses advanced troubleshooting procedures.
For the sake of simplicity, it is assumed that there are no other abnormalities on the
network during the proactive monitoring process described in chapter 2 "Network
Resource Monitoring."
2.2 CP/UP CPU Load
2.2.1 Monitoring Principles
Table 2-5 CP/UP resources monitoring

Resource Function Impact of Resource
Insufficiency
CP It is used to process Uu interface If CP is overloaded, new messages

signaling and transmit control-plane are discarded. That is, new call
signaling. requests are rejected, which
significantly affects user
experience.
UP It is used to process and distribute If UP is overloaded, user-plane

user-plane data flows. data is partially discarded. This
causes voice and data service
quality to deteriorate.
GPU boards process services on the RNC user plane and control plane. The CPs and UPs
of all GPU boards in the RNC form a CP pool and a UP pool, respectively. The RNC can
adjust the multi-core digital signal processors (DSPs) allocated to the CPs and UPs based
on service requirements in order to balance the load between the CPs and UPs.
 Run the ADD BRD command to set the logical function type of a GPU board. If the
Logical function type parameter is set to UCUP, the GPU board is used for "UMTS
RNC control-plane and user-plane processing". Slots 8 and 9 of subrack 0 in the RNC
permanently hold GPU boards whose logical function type is RMP, which are used
only for resource management. Other slots can hold GPU boards whose logical
function type is UCUP, which are used for UMTS RNC control-plane and user-plane
processing.
 Run the SET UCPUPFLEXCFG command to dynamically adjust the CP and UP
subsystems. In this command, the FlexCfgMode parameter specifies the mode for
adjusting the CP and UP subsystems, and the CPProportionInTotal parameter
specifies the percentage of CPU usage for the CP in the total CPU usage. You can use
these two parameters to manually configure the ratio of CPs to UPs in order to
distinguish CP and UP subsystems.
2.2.2 Monitoring Methods

The CP or UP CPU load is obtained by measuring the average CPU usage of all the
subsystems in the CP or UP resource pool. They are defined as follows:
 CP CPU Load = VS.CPPOOL.CPULOAD.MEAN (Average CPU Usage of the UMTS
CP Resource Pool)
 UP CPU Load = VS.UPPOOL.CPULOAD.MEAN (Average CPU Usage of the UMTS
UP Resource Pool)
2.2.3 Optimization Suggestions
Figure 2-2 Capacity expansion scheme
If the peak-hour CPU load reaches the capacity expansion threshold within n days (n is
specified based the actual situation; 3 days by default) in a week, prepare for capacity
expansion as instructed in Figure 2-3.
Figure 2-3 Capacity expansion procedure

2.3 RMP CPU Load
Table 2-6 RMP resources monitoring

Insufficiency
RMP Slots 8 and 9 of subrack 0 in the RNC If the GPU boards are overloaded,
permanently hold GPU boards whose service access will be impacted.
logical function type is RMP, which
are used only for resource
management.
The GPU boards in slots 8 and 9
work in active/standby mode.

The RMP CPU load is obtained by measuring the CPU usage of an RMP in the
measurement period. It is defined as follows:
RMP Load=VS.CPU.CPULOAD.MEAN
The VS.CPU.CPULOAD.MEAN counter measures the CPU load on each RMP
subsystem.
If the peak-hour RMP CPU load reaches 50% within n days (n is specified based on the
actual situation; 3 days by default) in a week, a warning is released. If the peak-hour RMP
CPU load exceeds 60% within n days (n is specified based on the actual situation; 3 days
by default) in a week, contact Huawei for technical support.
2.4 Interface Board CPU Load
Table 2-7 Interface board monitoring

Insufficiency
Interface RNC interface boards provide The packet loss rate increases,
board transmission ports and resources, adversely affecting
process transport network messages, communications and user
and exchange data between RNC experience.
boards and between the RNC and
external devices. If all interface boards for an
interface (Iub for example) are
These boards also forward and overloaded in Channel Identifiers
process data for the Iub, Iu, and Iur (CIDs), User Datagram Protocol
interfaces. (UDP), or Tunnel Endpoint ID
(TEIDs), this interface will fail to
work.
 In effective mode, run the MML command LST BRD to query information about a specific board,
for example, whether the board is an interface board.
 In ineffective mode, find the MML command ADD BRD in the RNC configuration file. If the
value of the BRDCLASS parameter is INT, the board is an interface board. You can obtain
information about this interface board using this command.

To obtain the interface board CPU load, monitor the control-plane CPU load, user-plane
forwarding load, and the average usage of CIDs, UDPs, or TEIDs.
The counters used to monitor the interface board CPU load are as follows:
 VS.CPU.CPULOAD.MEAN: Average CPU Usage of the CPU
 VS.INT.TRANSLOAD.RATIO.MEAN: Average Forwarding Ratio of Interface Boards
 VS.INT.TRM.FLOW.UDP.RESUSAGE.MEAN: Average Usage of UDP Ports of
Interface Boards
 VS.INT.TRM.FLOW.CID.RESUSAGE.MEAN: Average Usage of CID of Interface
Boards
 VS.INT.TRM.FLOW.TEID.RESUSAGE.MEAN: Average Usage of TEIDs of Interface
Boards

When the RNC detects that the CPU load on interface boards exceeds a specified overload
threshold, ALM-20256 CPU Overload is reported.
If the peak-hour usage of any item reaches the capacity expansion threshold within n days
(n is specified based the actual situation; 3 days by default) in a week, prepare for capacity
For details about the Transmission Resource Pool in RNC feature, see Transmission Resource Pool
in RNC Feature Parameter Description in the RAN Feature Documentation.
2.5 SCU CPU Load
Table 2-8 SCU board monitoring

Insufficiency
SCU Ports on an SCU board form a trunk Restricted by their switching

group that connects the MPS to the capacities, SCU boards are likely
EPS. to be congested when
Two SCU boards are installed each configurations are unbalanced
subrack. SCUb/SCUc boards are between subracks and when the
permanently installed in slots 20 and inter-subrack traffic is heavy.
21 of each subrack. Two SCU When the traffic volume of inter-
boards in the same subrack work in subrack communication
active/standby mode. approaches the overload
threshold, voice service quality,
data service quality, and network
KPIs deteriorate, causing the
system to become unstable.

Both the SCU CPU load and inter-subrack bandwidth need to be monitored for SCU
boards.
Monitoring of SCU CPU Load

The SCU CPU load is measured as follows:
SCU CPU load = VS.CPU.CPULOAD.MEAN
When the RNC detects that the CPU load on an SCU subsystem exceeds a specified
overload threshold, ALM-20256 CPU Overload is reported. You can query the overload
threshold by running the LST CPUTHD command.
Monitoring of Inter-Subrack Bandwidth

Inter-subrack bandwidth usage is defined as follows:
Frame Mean Usage = VS.Frame.Flux.Mean.TxRate/Inter-subrack bandwidth x 100%
When a pair of active and standby SCUb boards are configured, the inter-subrack
bandwidth is 40 Gbit/s (40,000,000 kbit/s). When a pair of active and standby SCUc
boards are configured, the inter-subrack bandwidth is 320 Gbit/s (320,000,000 kbit/s). If
either the active or standby SCUb/SCUc board becomes faulty, the inter-subrack
bandwidth is reduced by half.

 If the SCU CPU load reaches 60%, contact Huawei for technical support.
 If the value of Frame Mean Usage exceeds 40%, contact Huawei for technical support.
 If VS.Frame.Flux.DropPackets exceeds the threshold (0.02%), ALM-20277
Communication Between Subracks Faulty is reported. In the case of other faults,
contact Huawei for technical support.
2.6 RNC License

KPIs such as the licensed RNC-level CS and PS traffic volumes as well as hardware
capacity can be obtained using RNC license files. The usage of each license can be
evaluated based on the obtained KPIs and the RNC's actual traffic volume.
RNC Traffic Volume License Utilization Rate

Obtain the utilization rate of each license by dividing the counters related to peak hour
traffic volume by the related licensed values.
The utilization rate of each license is calculated as follows:
 CS License Ratio
CS License Ratio = CSLoad/Voice Erlang - Erlang x 100%
 PS R99 Throughput License Ratio
PS R99 Throughput License Ratio = (R99PSLoad_UL + R99PSLoad_DL)/(PS
throughput only (per Mbit/s) x 1000) x 100%
 HSDPA Throughput License Ratio
HSDPA Throughput License Ratio = HSDPAPSLoad/(HSDPA Throughput (per
Mbit/s) x 1000) x 100%
 HSUPA Throughput License Ratio
HSUPA Throughput License Ratio = HSUPAPSLoad/(HSUPA Throughput (per
Mbit/s) x 1000) x 100%
 PS License Ratio
PS Throughput License Ratio = PSLoad/(PS throughput only (per Mbit/s) x 1000) x
100%
Table 2-9 Counters pertaining to license utilization in single-operator scenarios

and multi-operator scenarios
Item Counter (Single-Operator Counter (Multi-Operator
Scenario) Scenario)
CSLoad VS.CSLoad.Erlang.Equiv.RNC VS.CSLoad.Erlang.Equiv.

PLMN.RNC
R99PSLoad_U VS.R99PSLoad.ULThruput.RNC VS.R99PSLoad.ULThruput.

L PLMN.RNC
R99PSLoad_D VS.R99PSLoad.DLThruput.RNC VS.R99PSLoad.DLThruput.

L PLMN.RNC
HSDPAPSLoa VS.HSDPAPSLoad.DLThruput.R VS.HSDPAPSLoad.DLThrup

d NC ut. PLMN.RNC
HSUPAPSLoa VS.HSUPAPSLoad.ULThruput.R VS.HSUPAPSLoad.ULThrup

d NC ut. PLMN.RNC
PSLoad VS.PSLoad.Thruput.RNC VS.PSLoad.Thruput.

PLMN.RNC
Table 2-10 Licenses related to traffic volume

License Item Abbreviation Sales Unit
Voice Erlang-Erlang LQW1CS01 Erl
PS throughput only (per Mbit/s) LQW1PO01 Mbit/s
HSDPA Throughput (per Mbit/s) LQW1HSDPAT01 Mbit/s

HSUPA Throughput (per Mbit/s) LQW1HSUPAT01 Mbit/s
RNC Hardware Capacity License Utilization Rate

The hardware capacity license utilization rate is defined as follows:
RNC Hardware Capacity License Utilization Rate = VS.HWLicense.Thruput.RNC/(RNC
Throughput Hardware Capacity (per 50 Mbit/s)License allocated x 50 x 1000) x 100%
The license related to the hardware capacity is listed in the following table.
License Item Abbreviation Sales Hardware

Unit Dependency
RNC Throughput Hardware Capacity LQW1HWCL03 50 GPU
(per 50Mbit/s) Mbit/s
RNC ENIUa License Utilization Rate

The BSC6910 ENIUa license utilization rate is calculated using the following formula:
RNC ENIUa License Utilization Rate = VS.NIUPSLoad.Thruput.RNC/(Evolved Network
Intelligence Processing Throughput License allocated x 50 x 1000) x 100%
The license related to the BSC6910 ENIUa traffic is described in the following table.
License Item Abbreviation Sales

Unit
Evolved Network Intelligence Processing LGW1DPIHC02 50
Throughput (per 50Mbit/s) Mbit/s
RNC Active User Number License Utilization Rate

The Active User License Utilization Rate is calculated using the following formula:
Active User License Utilization Rate = (VS.CellDCHUEs.RNC +
VS.CellFACHUEs.RNC)/(RNC Active User Hardware Capacity (per 1000 Active
Users)License allocated x 1000) x 100%
Associated counters are as follows:
 VS.CellDCHUEs.RNC
 VS.CellFACHUEs.RNC
The license related to active user number capacity is described in the following table.
The BSC
RNC Active User Hardware Capacity (per LQW1HWCL04 1000 Active Users
1000 Active Users)
Cell-Level HSDPA/HSUPA User Number License Utilization Rate
 Cell HSDPA Users License Utilization Rate
Cell HSDPA Users License Utilization Rate = VS.HSDPA.UE.Mean.Cell/Max
HSDPA users of the HSDPA users license per cell x 100%
 Cell HSUPA Users License Utilization Rate
Cell HSUPA Users License Utilization Rate = VS.HSUPA.UE.Mean.Cell/Max
HSUPA users of the HSUPA users license per cell x 100%
 VS.HSDPA.UE.Mean.Cell
 VS.HSUPA.UE.Mean.Cell
In the preceding formulas:

 The value of VS.HSDPA.UE.Mean.Cell is equal to the value of VS.HSDPA.UE.Mean.Cell for
the cell with the largest number of HSDPA users in the RNC.
 The value of Max HSDPA users of the HSDPA users license per cell is equal to the maximum
licensed value of the number of HSDPA users in a cell configured.
 The value of VS.HSUPA.UE.Mean.Cell is equal to the value of VS.HSUPA.UE.Mean.Cell for
the cell with the largest number of HSUPA users in the RNC.
 The value of Max HSUPA users of the HSUPA users license per cell is equal to the maximum
licensed value of the number of HSUPA users in a cell configured.
The licenses related to the cell-level HSDPA/HSUPA user number capacity are listed in
the following table.

32 HSDPA Users per LQW1HSDPA05RES Mbit/s
Cell
Cell
Cell
Cell
60 HSUPA Users per LQW1HSUPA07RES Mbit/s
Cell

Cell
Cell
160 HSPA Users per Cell LQW1160HURES Mbit/s

192 HSPA Users per Cell LQW1192HURES Mbit/s
If the peak- hour utilization rate reaches the capacity expansion threshold for n days (n is
specified based on the actual situation; 3 days by default), license purchase is required.
2.7 NIU CPU Load

The NIU is an evolved network intelligence processing board that implements service
awareness and collects PS service statistics. You can use the ENIUa or EGPUb to
implement functions of the NIU. If the SCUb board is used, install the ENIUa and EGPUb
boards in slot 0 to 7, 16 to 19, or 22 to 25. If they are installed in other slots, the ENIUa
and EGPUb board cannot implement such functions due to insufficient switching
capability.
NIU overload will adversely affect service awareness and PS service statistics.

The VS.SUBSYS.CPULOAD.MEAN counter provides the average CPU usage of a
subsystem in the measurement period. It indicates the load and performance of the CPU on
the subsystem in the measurement period.
The NIU CPU load is calculated using the following formula:
NIU CPU Load = AVG(VS.SUBSYS.CPULOAD.MEAN)

If the peak-hour NIU CPU usage reaches 50% within n days (n is specified based on site
requirements; 3 days by default) in a week, you are advised to initiate pre-expansion; if the
usage exceeds 60%, you are advised to initiate emergency capacity expansion.
To expand the capacity, insert more NIU boards.
2.8 DEU CPU Load

The DEU is an evolved data processing board that implements enhanced UMTS data
processing. DEU overload will adversely affect enhanced UMTS data processing. When
the CPU is not overloaded, DEU performance will also be affected if resources required
for the following features exceed the preset threshold: eTrFO.
The VS.DEU.DSP.UsageAvg counters provide the average CPU usage of a subsystem on
the DEUa, respectively, in the measurement period. They indicate the load and
performance of the CPU on the subsystem in the measurement period.
The CPU load is calculated using the following formula:
DEU Load = AVG(VS.DEU.DSP.UsageAvg)
The DEU specification usage for the eTrFO feature is calculated using the following
formula:
DEU Specification Usage (eTrFO) = (VS.AMRNB.TrFO.TransCoder.Frame.Num x
20)/1000/60/Total DEU Capacity
Where
Total DEU capacity equals the number of DEU boards multiplied by the specifications of
each DEU board. The eTrFO specifications of a DEU board are 1000.
The VS.AMRNB.TrFO.TransCoder.Frame.Num counter provides the number of UL
AMR-NB speech frames that are transcoded after TrFO UL rate reduction fails on an
RNC. Its value in Erlang equals (VS.AMRNB.TrFO.TransCoder.Frame.Num x
20)/1000/60.

If the peak-hour DEU CPU usage reaches 50% within n days (n is specified based on site
requirements; 3 days by default) in a week, you are advised to initiate pre-expansion; if the
usage exceeds 60%, you are advised to initiate emergency capacity expansion.
If the peak-hour resource usage for the eTrFO features reaches 70% within n days (n is
specified based on site requirements; 3 days by default) in a week, you are advised to
initiate pre-expansion; if the resource usage exceeds 80%, you are advised to initiate
emergency capacity expansion.
To expand the capacity, insert more DEU boards.
2.9 Common Channel Usage

Common channels include paging channels (PCHs), forward access channels (FACHs),
and random access channels (RACHs).
Table 2-11 Common channel monitoring

Insufficiency
PCH PCHs are downlink channels used Paging messages may be lost.
to transmit paging messages.
Insufficiency
FACH FACHs are downlink FACH insufficiency will cause a

transmission channels used to large number of state transitions for
transmit signaling data and a PS services, occurrence of RRC
small amount of user data. signaling storms, and loss of
signaling messages or user data.
RACH RACHs are uplink transmission RACH insufficiency will decrease

channels used to transmit the network access success rate and
signaling data and a small amount deteriorate user experience.
of user data.

Based on the RNC's default parameter settings, the usages of PCHs, FACHs, and RACHs
are calculated using the following formulas, respectively:
PCH Usage
PCH usage = VS.UTRAN.AttPaging1/(<SP> x 60 x 5/0.01)
where
 <SP> indicates the measurement period expressed in minutes.
 60 indicates 60 seconds in a minute.
 5 indicates the typical configuration (that is, five users in each TTI) of the PCH.
 0.01 indicates the length (that is, 0.01s) of a PCH TTI.
FACH Usage
If a secondary common control physical channel (SCCPCH) carries both a FACH and a
PCH, the FACH usage is calculated using the following formula:
Usage of an FACH carried on a non-standalone SCCPCH = VS.CRNCIubBytesFACH.Tx
x 8/[(60 x <SP> x 168 x 1/0.01) x VS.PCH.Bandwidth.UsageRate x 6/7 + (60 x <SP> x
360 x 1/0.01) x (1 - VS.PCH.Bandwidth.UsageRate x 6/7)]
where
 VS.PCH.Bandwidth.UsageRate =<
VS.CRNCIubBytesPCH.Tx>/(<VS.CRNC.IUB.PCH.Bandwidth> x <SP> x 60)
 8 indicates 8 bits in a byte.
 <SP> indicates the measurement period in minutes.
 1 indicates one packet transmitted per TTI.
 6/7 indicates the payload ratio in a PCH frame.
 168 indicates the size of a TB on the signaling plane of a FACH.
 360 indicates the size of a TB on the user plane of a FACH.
 VS.CRNCIubBytesFACH.Tx
 VS.CRNCIubBytesPCH.Tx
 VS.CRNC.IUB.PCH.Bandwidth
If an SCCPCH only carries a FACH, the FACH usage is calculated using the following
formula:
FACH Usage = ((VS.SRBNum.FACH - VS.OneSRBTTINum.FACH)/2 +
VS.OneSRBTTINum.FACH + VS.IndepTRBNum.FACH)/(<SP> x 60/0.01)
where
 2 indicates scenarios where two SRB TBs are transmitted within one TTI.
 VS.SRBNum.FACH
 VS.OneSRBTTINum.FACH
 VS.OneSRBTTINum.FACH
 VS.IndepTRBNum.FACH
RACH Usage
Each cell has only one RACH. When signaling and user data coexist on the RACH, the
RACH usage is calculated using the following formula:
RACH Usage = ((VS.CRNCIubBytesRACH.Rx - VS.TRBNum.RACH x 360/8) x
8/168)/(<SP> x 60 x 4/0.02) + VS.TRBNum.RACH/(<SP> x 60 x 4/0.02)
where
 360 indicates the size of a TB on the user plane of a FACH.
 8 indicates 8 bits in a byte.
 168 indicates the size of a TB on the signaling plane of a FACH.
 4 indicates that each TTI on the RACH can accommodate four UEs.
 0.02 indicates the TTI of 0.02s (or 20 ms).
 VS.CRNCIubBytesRACH.Rx
 VS.TRBNum.RACH
 VS.TRBNum.RACH

If the peak-hour usage of a measurement item reaches the capacity expansion threshold
within n days (n is specified based the actual situation; 3 days by default) in a week,
prepare for capacity expansion as instructed in Figure 2-8.
2.10 Downlink Load
Table 2-12 Downlink resource monitoring

Insufficiency
Downlink Detailed in the following part. When the downlink transmit power
resources is insufficient, the following occurs:
 The cell coverage shrinks.
 The data throughput decreases.
 The service quality declines.
 New service requests are likely to
be rejected.
The downlink capacity of a cell is limited by its total available transmit power, which is
determined by the NodeB power amplifier's capability and the power configured for the
cell.
The downlink transmit power consists of the following, as shown in Figure 2-9:
 Common channel (CCH) power
 Power for DPCH
 HSPA power
 Power margin
Figure 2-9 Dynamic power resource allocation

Downlink power resources are allocated as follows:
 Downlink power resources are first reserved for common physical channels and
allocated to the DPCH. The remaining power resources are available for HSPA,
including HSUPA and HSDPA.
 The HSPA power resources are first allocated to the HSUPA downlink control
channels, including the E-AGCH, E-RGCH, and E-HICH. The remaining power
resources are available for HSDPA.
 The HSDPA power resources are first allocated to the downlink control channel HS-
SCCH. The remaining power resources are available for the traffic channel HS-
PDSCH.
Downlink power consumption is related to cell coverage, UE locations, and the traffic load
in the cell. Large cell coverage, UEs being far away from the cell center, and heavy traffic
load all contribute to large downlink power consumption. Therefore, downlink power
overload is more likely to occur in hotspots or in cells with large coverage.

The downlink cell load is indicated by the mean utility ratio of transmitted carrier power in
a cell.
 The mean utility ratio of the transmitted carrier power for non-HSPA users in a cell
(including non-HSPA users on CCHs) is calculated using the following formula:
MeanTCP (NonHS) Usage = MeanNonHSTCP/MAXTXPOWER x 100%
 The mean utility ratio of the transmitted carrier power for all users in a cell is calculated
using the following formula:
MeanTCP Usage = MeanTCP/MAXTXPOWER x 100%
where


 To obtain MAXTXPOWER, run the LST UCELL command to query the value of the
Max Transmit Power of Cell parameter, and convert the parameter value from the
unit "0.1 dBm" to "W".
 VS.MeanTCP
 VS.MeanTCP.NonHS
 VS.HSDPA.MeanChThroughput
If the peak-hour usage of a measurement item reaches the capacity expansion threshold
within n days (n is specified based the actual situation; 3 days by default) in a week,
prepare for capacity expansion as instructed in Figure 2-11.
2.11 Uplink Load
Table 2-13 Uplink resource monitoring

Insufficiency
Uplink RTWP reflects the interference to If the RTWP value is too large, the
resources a NodeB and indicates the signal cell coverage shrinks, the quality of
strength on the RX port of the RF admitted services declines, or new
module. service requests are rejected.
RTWP measures the uplink cell capability on WCDMA networks.

RTWP includes the following:
 Background noise
 Intra-system interference, including uplink signals sent by the UEs in the serving and
neighboring cells
 RF interference, including RF interference from an external source (for example, RF
interference from another RAT or from equipment other than communication
equipment) and intra-system RF interference (for example, intermodulation
interference produced by hardware components)
The NodeB measures the RTWP on each receive channel in each cell. The cell RTWP
obtained by the RNC is the linear average of the RTWPs measured on all receive channels
in a cell under the NodeB. The RTWP indicates the interference to a NodeB and the signal
strength on the RX port on the RF module.
The uplink cell capacity is restricted by the rise over thermal (RoT), which equals the
RTWP minus the cell's background noise. The formula is as follows:
If there is no RF interference, the RoT is generated by intra-system interference. Under

this condition, the RoT is used as a criterion to evaluate the uplink load.
The relationship between the RoT and the uplink load factor is as follows:
For example, a 3 dB noise increase corresponds to 50% of the uplink load and a 6 dB noise
increase corresponds to 75% of the uplink load.
Figure 2-12 Relationship between RTWP, noise increase, and uplink load
A large RTWP value in a cell is caused by traffic overflow, hardware faults (for example,
poor quality of antennas or feeder connectors), or external interference.

The RTWP and Equivalent Number of Users (ENU) are indicated by the following
counters:
 VS.MeanRTWP: Mean Power of Totally Received Bandwidth for Cell
 VS.MinRTWP: Minimum Power of Totally Received Bandwidth for Cell
 VS.RAC.UL.EqvUserNum: Mean Number of UL Equivalent Voice UEs in
CELL_DCH State for Cell
 UlTotalEqUserNum: total number of equivalent users in the uplink, which can be
queried using the RNC MML command LST UCELLCAC.
The UL ENU Ratio is calculated using the following formula:
UL ENU Ratio = VS.RAC.UL.EqvUserNum/UlTotalEqUserNum
In some areas, the background noise increases to -106 dBm or above due to external
interference or hardware faults. If this occurs, the value of the VS.MinRTWP counter (the
RTWP value obtained when the cell carries no traffic) is considered the background noise.
The RTWP of a cell is considered high when the value of the VS.MeanRTWP counter is
greater than -100 dBm during off-peak hours or greater than -90 dBm during peak hours
for two or three consecutive days in a week.
A cell is considered heavily loaded if the UL ENU Ratio exceeds 75% during peak hours
for two or three consecutive days in a week.

Perform capacity expansion in the following scenarios:
 If the value of the VS.MinRTWP counter is greater than –100 dBm or less than –110
dBm during off-peak hours for n days (n is specified based on the actual situation; 3
days by default) in a week, there may be hardware faults or external interference.
Locate and rectify the faults and attempt to eliminate the interference.
The following table lists the RF alarms reported by the NodeB.
Table 2-14 RF alarms

Alarm ID Alarm Name
ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced
ALM-26521 RF Unit RX Channel RTWP/RSSI Too Low
ALM-26532 RF Unit Hardware Fault

ALM-26752 ALD Hardware Fault
ALM-26758 TMA Running Data and Configuration Mismatch
Alarm ID Alarm Name
ALM-26755 TMA Bypass
ALM-26757 RET Antenna Running Data and Configuration Mismatch
ALM-26541 ALD Maintenance Link Failure
ALM-26529 RF Unit VSWR Threshold Crossed
 If the value of the VS.MeanRTWP counter is greater than –90 dBm during peak hours
for n days (n is specified based on the actual situation; 3 days by default) in a week,
there may be hardware faults or external interference. Locate and rectify the faults
and attempt to eliminate the interference. If the value of the VS.MeanRTWP counter
is still greater than –90 dBm after hardware faults are rectified and external
interference is eliminated, enable the following features as required:
− WRFD-140215 Dynamic Configuration of HSDPA CQI Feedback Period
− WRFD-010712 Adaptive Configuration of Traffic Channel Power offset for
HSUPA
If the uplink capacity of the cell still does not meet the requirements after the
preceding features are enabled, add carriers. If there are no additional UARFCNs
available, add NodeBs.
 For details about how to enable the WRFD-140215 Dynamic Configuration of HSDPA CQI
Feedback Period feature, see Dynamic Configuration Based on the Uplink Load Feature
Parameter Description in the RAN Feature Documentation.
 For details about how to enable the WRFD-010712 Adaptive Configuration of Traffic Channel
Power offset for HSUPA feature, see Power Control Feature Parameter Description in the RAN
Feature Documentation.
 If the number of uplink ENUs is insufficient and the amount of uplink power is
sufficient, run the MOD UCELLCAC command with the UL total equivalent user
number parameter set to a larger value. In addition, run the SET UADMCTRL
command with the AF of hsupa interactive service and AF of hsupa background
service parameters set to 10.
2.12 OVSF Code Usage
Table 2-15 Code resource monitoring

Insufficiency
OVSF OVSF codes are used to Network access is affected.

codes distinguish downlink physical
channels for UEs.
In a WCDMA system, channels are identified by codes. Two types of codes are used for
each channel. One is the scrambling code and the other is the Orthogonal Variable
Spreading Factor (OVSF) code.
In the uplink, each UE is allocated a unique scrambling code. In the downlink, each cell is
allocated a unique scrambling code; all UEs in a cell use the same scrambling code but
each of them is allocated a unique OVSF code. Therefore, OVSF codes distinguish the
downlink physical channels of different UEs in a cell.
In a WCDMA cell, different user data is distinguished by the CDMA technique, and all
user data is transmitted over the same central frequency almost at the same time. OVSF
codes provide perfect orthogonality, minimizing interference between different users.
Figure 2-13 shows an OVSF code tree.
Figure 2-13 OVSF code tree
In the downlink, the maximum spreading factor (SF) is 256.

An OVSF code tree can be divided into 4 SF4 codes, 8 SF8 codes, 16 SF16 codes, ..., 256
SF256 codes. Codes with various SFs can be considered equivalent to SF256 codes. For
example, a code with SF8 is equivalent to 32 codes with SF256. Using this method, the
OVSF code usage can be calculated for a user or a cell.
In a cell, only one OVSF code tree is available. In the OVSF code tree, sibling codes are
orthogonal to each other, but are non-orthogonal to 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. Downlink OVSF code resources are limited. If available OVSF codes are
insufficient, a new call request is rejected.
After HSDPA is introduced, HSDPA and R99 services share OVSF codes. HS-PDSCH
code resource management can be performed at both RNC and NodeB levels. RNC-
controlled static or dynamic code allocation is enabled through the Allocate Code Mode
parameter. NodeB-controlled dynamic code allocation is enabled through the DynCodeSw
parameter.
Figure 2-14 shows RNC-controlled static code allocation.
Figure 2-14 RNC-controlled static code allocation
Figure 2-15 shows RNC-controlled dynamic code allocation.
Figure 2-15 RNC-controlled dynamic code allocation

The system reserves code resources for HSDPA services, and these code resources can be
shared among HSDPA services. Therefore, HSDPA services do not require admission
control based on cell code resources.
Figure 2-16 shows NodeB-controlled dynamic code allocation.
Figure 2-16 NodeB-controlled dynamic code allocation
NodeB-controlled dynamic code allocation is more flexible than RNC-controlled dynamic

code allocation. It shortens the response time and saves the Iub signaling used for code
allocation.

Huawei RNCs monitor the average usage of an OVSF code tree based on the number of
equivalent codes with SF256, which is measured by the VS.RAB.SFOccupy counter.
The number of codes used by the dedicated channel (DCH) can be calculated using the
following formula:
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>)
The maximum number of codes available for the DCH can be calculated using the
following formula:
DCH_OVSF_CODE_Ava = 256 - (Codes occupied by CCHs + Codes occupied by E-
AGCHs + Codes occupied by E-RGCHs and E-HICHs + Codes reserved for HS-PDSCHs
+ HS-SCCH codes)
For example, if the following conditions are met:
 A cell that supports HSPA is configured with one SCCPCH, one E-AGCH, one E-
RGCH/E-HICH, and two HS-SCCHs.
 At least one code is reserved for HSDPA services.
Then, DCH_OVSF_CODE_Ava = 256 - (8 + 1 + 2 + 16 + 4) = 225.
OVSF code usages are calculated as follows:
 OVSF Usage = VS.RAB.SFOccupy/256 x 100%
 DCH OVSF Usage = DCH_OVSF_CODE/DCH_OVSF_CODE_Ava

If the peak-hour usage reaches the capacity expansion threshold within n days (n is
specified based the actual situation; 3 days by default) in a week, prepare for capacity
For details about how to enable the WRFD-010631 Dynamic Code Allocation Based on NodeB
feature and the WRFD-010653 96 HSDPA Users per Cell feature, see HSDPA Feature Parameter
Description in the RAN Feature Documentation.
2.13 HS-PDSCH Code Usage
Table 2-16 HS-PDSCH code resource monitoring

Insufficiency
HS- HS-PDSCHs are used to carry HSDPA service rates will be

PDSCH HSDPA services. affected.
codes

The HS-PDSCH code usage in a measurement period is calculated using the following
formula:
HS-PDSCH Code Usage =
Sum_AllCells_of_NodeB(VS.PdschCodeUsed.Mean)/Sum_AllCells_of_NodeB(VS.Pdsc
hCodeAvail.Mean)
where
Sum_AllCells_of_NodeB means a sum of this counter value for all cells under a NodeB.
 VS.PdschCodeUsed.Mean
 VS.PdschCodeAvail.Mean

The following suggestions are provided on the assumption that the HS-PDSCH Code
Usage is greater than 70% during peak hours for n days (n is specified based on the actual
situation; 3 days by default) in a week and the value of VS.HSDPA.MeanChThroughput is
less than what is required by users (for example, 300 kbit/s).
 If the number of licensed HS-PDSCH codes is greater than the number of available HS-
PDSCH codes, increase carriers with the TCP usage taken into consideration.
 If the number of licensed HS-PDSCH codes is less than or equal to the number of
available HS-PDSCH codes, purchase more licenses.
2.14 HS-SCCH Code Usage
Table 2-17 HS-SCCH code resource monitoring

Insufficiency
HS-SCCH HS-SCCH codes are used to Insufficient HS-SCCH codes will

codes carry HS-PDSCH-related control increase data transmission delay and
information. reduce the maximum number of UEs
The number of HS-SCCH codes that are performing delay-sensitive
determines the number of services in a cell.
HSDPA users that can be
scheduled in each transmission
time interval (TTI).

The HS-SCCH code usage is calculated using the following formula:
HS-SCCH Code Usage = VS.ScchCodeUtil.Mean/1000

If the HS-SCCH Code Usage is greater than 70% during peak hours for n days (n is
specified based on the actual situation; 3 days by default) in a week and the number of
configured HS-SCCHs is less than 4, add more HS-SCCHs.
2.15 Iub/Iu/Iur Bandwidth Usage
Table 2-18 Iub/Iu/Iur resource monitoring

Insufficiency
Iub The Iub interface lies between the Iub bandwidth congestion will cause
bandwidth NodeB and the RNC. This RRC connection setup and RAB
interface uses ATM or IP setup failures. Table 2-19 describes
transmission. Iub bandwidth congestion scenarios.
In IP transmission, the BSC6910
supports only transmission
resource pool mode and does not
support resource groups.
Iu The Iu interface lies between the

bandwidth RNC and the CN. This interface
uses ATM or IP transmission.
However, the BSC6910 supports
only IP transmission for the Iu-
PS interface.
In IP transmission mode, the Iu
interface supports both
transmission resource pool mode
and other modes.
In transmission resource pool
mode, the RNC requires no IP
paths and does not support
transmission groups.
Iur The Iur interface lies between

bandwidth RNCs. This interface uses ATM
or IP transmission.
In IP transmission mode, the Iur
interface supports both
transmission resource pool mode
and other modes.
In transmission resource pool
mode, the RNC requires no IP
paths and does not support
transmission groups.
ATM and IP transmission resources can be classified into physical resources, logical port
(LP) resources, resource groups, and link resources, as shown in Figure 2-19 and Figure 2-
20.
Figure 2-19 ATM transmission resources
Figure 2-20 IP transmission resources
Table 2-19 Iub bandwidth congestion scenarios

Scenario Description
The physical transmission Admission control is performed based on the
resources are sufficient, but sufficiency of transmission resources. If
the admission fails. transmission resources are insufficient, the
admission fails. Admission control prevents
excessive service admission and ensures the
quality of admitted services.
The physical transmission The physical transmission bandwidth between the
bandwidth is insufficient. RNC and NodeB is insufficient.
ATM Transmission
On an ATM transport network, the RNC can monitor the uplink and downlink load on
their interface boards. The Iub/Iu/Iur bandwidth usage is indicated by the ratio of the
actual uplink or downlink load to the configured bandwidth. For the Iub interface, the
NodeB can also monitor the uplink and downlink load on their interface boards.
The RNC monitors the admission success rate and bandwidth usage for each NodeB.
1. Bandwidth-based admission success rate
The bandwidth-based admission success rate is calculated using the following
formula:
Bandwidth-based admission success rate = VS.AAL2.CAC.Succ/VS.AAL2.CAC.Att
− VS.AAL2.CAC.Succ: Number of Successful AAL2 Path Admissions
− VS.AAL2.CAC.Att: Number of AAL2 Path Resource Admissions
2. Bandwidth usage
(1) Control plane
The uplink and downlink bandwidth usages of the SAAL links (for both NCP and
CCP) on the control plane over the Iub/Iu/Iur interface are calculated using the
following formulas, respectively:
− UL Iub/Iu/Iur Usage on Control Plane = VS.SAALLNK.PVCLAYER.RXBYTES
x 8/1000/<SP>/RX BW_CFG
− DL Iub/Iu/Iur Usage on Control Plane = VS.SAALLNK.PVCLAYER.TXBYTES
x 8/1000/<SP>/TX BW_CFG
where
− 8 indicates 8 bits in a byte.
− 1000 indicates 1 kbit/s.
− <SP> indicates the measurement period in minutes.
− TX BW_CFG indicates the configured transmit bandwidth, which can be got by
running the command LST ATMBW.
− RX BW_CFG indicates the configured transmit bandwidth, which can be got by
− VS.SAALLNK.PVCLAYER.TXBYTES
− VS.SAALLNK.PVCLAYER.RXBYTES
(2) User plane
The uplink and downlink bandwidth usages of the user plane on the Iub/Iu/Iur
interface are calculated using the following formulas, respectively:
− UL Iub/Iu/Iur Usage on User Plane = Sum
(VS.AAL2PATH.PVCLAYER.RXBYTES) x 8/<SP>/1000/RX BW_CFG
− DL Iub/Iu/Iur Usage on User Plane = Sum
(VS.AAL2PATH.PVCLAYER.TXBYTES) x 8/<SP>/1000/TX BW_CFG
where
− TX BW_CFG indicates the configured transmit bandwidth, which can be got by
− RX BW_CFG indicates the configured transmit bandwidth, which can be got by
− VS.AAL2PATH.PVCLAYER.TXBYTES
− VS.AAL2PATH.PVCLAYER.RXBYTES
IP Transmission
On an IP transmission network, the RNC and NodeB can monitor the average uplink and
downlink loads on their interface boards. The Iub/Iu/Iur bandwidth usage is represented by
the ratio of the average uplink or downlink load to the configured Iub/Iu/Iur bandwidth.
For the Iub interface, the NodeB can also monitor the uplink and downlink load on their
interface boards. In addition, the RNC and NodeB can dynamically adjust the bandwidth
of a service based on the QoS requirements of the service and user priority and improve
the Iub bandwidth usage using the reserve pressure algorithm on their interface boards.
1. Admission success rate (or IP connection setup success rate)
The IP connection setup success rate is calculated using the following formula:
IP connection setup success rate =
VS.ANI.IP.Conn.Estab.Succ/VS.ANI.IP.Conn.Estab.Att
− VS.ANI.IP.Conn.Estab.Succ
− VS.ANI.IP.Conn.Estab.Att
− VS.ANI.IP.FailResAllocForBwLimit
2. Bandwidth usage
(1) Control plane
The uplink and downlink traffic volumes of the SCTP links (for NCP, CCP, and
ALCAP) on the control plane over the Iub interface are calculated using the
following formulas, respectively:
− SCTP UL KBPS = VS.SCTP.RX.BYTES x 8/<SP>/1000
− SCTP DL KBPS = VS.SCTP.TX.BYTES x 8/<SP>/1000
where
− VS.SCTP.TX.BYTES
− VS.SCTP.RX.BYTES
(2) User plane
The uplink and downlink Iub bandwidth usages on a transmission resource pool are
calculated using the following formulas, respectively:
− UL Iub/Iu/Iur Usage on User Plane = VS.IPPOOL.ANI.IPLAYER.RXBYTES x
8/<SP>/1000/RX BW_CFG
− DL Iub/Iu/Iur Usage on User Plane = VS.IPPOOL.ANI.IPLAYER.TXBYTES x
8/<SP>/1000/TX BW_CFG
where
− TX BW_CFG indicates the configured transmit bandwidth.
− VS.IPPOOL.ANI.IPLAYER.TXBYTES
− VS.IPPOOL.ANI.IPLAYER.RXBYTES

 If ALM-21542 SCTP Link Congestion is reported on the Iub interface, bandwidth congestion has
occurred on the control plane.
 If ALM-21532 SAAL Link Congestion is reported on the Iu interface, bandwidth congestion has
occurred on the control plane.
 If the value of the VS.ANI.IP.FailResAllocForBwLimit counter is not zero, bandwidth congestion
has occurred on the user plane.
If the peak-hour Iub/Iu/Iur bandwidth usage exceeds 70% or the admission success rate is
lower than 99% within n days (n is specified based the actual situation; 3 days by default)
in a week, prepare for capacity expansion as instructed in Figure 2-22.
The following part uses the Iub interface as an example to introduce how to implement
capacity expansion.
Scenario 1: Bandwidth Congestion on the ATM Control Plane

If an SAAL link is congested, increase the bandwidth configured for the SAAL link by
running the following commands:
ADD ATMTRF: TRFX=NewIndex, ST=NRTVBR, UT=KBIT/S, PCR=NewValue,
SCR= NewValue;
MOD SAALLNK: SRN=1, SN=2, SAALLNKN=20, CARRYT=IMA,
CARRYSRN=1, CARRYSN=NewIndex, CARRYIMAGRPN=NewIndex;
Scenario 2: Bandwidth Congestion on the IP Control Plane

If an SCTP link is congested, check whether the transmission bandwidth between the RNC
and NodeB is sufficient and whether the DSCP of the SCTP link is appropriately set. If the
transmission bandwidth is sufficient and the DSCP is appropriately set, add an SCTP link
by running the following command:
ADD SCTPLNK: SRN=1, SN=2, SCTPLNKN=2, MODE=SERVER, APP=NBAP,
DSCP=48, VLANFLAG1=DISABLE, VLANFLAG2=DISABLE,
SWITCHBACKFLAG=YES;
Scenario 3: Physical Bandwidth Congestion on the ATM and IP User Planes

Increase the physical bandwidth of the Iub interface as required.
Scenario 4: Admission Bandwidth Congestion on the ATM and IP User Planes, Not
Accompanied by Physical Bandwidth Congestion
Step 2 Decrease the activity factor for PS services to enable the system to admit more UEs.
Query the activity factor used by the adjacent node by checking the configuration data of
the following command:
ADD ADJMAP: ANI=10, ITFT=IUB, TRANST=IP, CNMNGMODE=SHARE,
FTI=OldIndex;
Step 3 Run the ADD TRMFACTOR command to add an activity factor table. The
recommended value for PSINTERDL, PSINTERUL, PSBKGDL, PSBKGUL,
HDINTERDL, and HDBKGDL is 10. The following is an example:
ADD TRMFACTOR:FTI=NewIndex, REMARK="IUB_USER", PSINTERDL=10,
PSINTERUL=10, PSBKGDL=10, PSBKGUL=10, HDINTERDL=10, HDBKGDL=10;
Step 4 Run the MOD ADJMAP command to use the new activity factor on the adjacent node.
The following is an example:
MOD ADJMAP: ANI=XXX, ITFT=IUB, FTI=NewIndex;
The activity factor equals the ratio of actual bandwidth occupied by a UE to the bandwidth allocated
to the UE during its initial access. It is used to predict the bandwidth required by admission. Each
NodeB can be configured with its own activity factor. The default activity factor for voice services is
70%, and the default activity factor for PS BE services is 40%.
----End
2.16 CE Usage
Table 2-20 CE resource monitoring

Insufficiency
CEs CE resources are baseband New service requests will be

processing resources in a NodeB. rejected.
The more CEs a NodeB supports,
the stronger the NodeB's service
processing capability.
Uplink CE resources can be shared in an uplink resource group, but not between uplink
resource groups. Downlink CE resources are associated with the baseband processing
boards where a cell is set up. CE resources allocated by licenses are shared among services
on the NodeB. (CE resources are shared on a per operator basis in MOCN scenarios.)
The NodeB sends the RNC a response message that carries its CE capability. The NodeB's
CE capability is limited by both the installed hardware and the configured software
licenses.
The methods of calculating the credit resource usage of admitted UEs are different before
and after the CE Overbooking feature is enabled. Table 2-21 describes the details.
Table 2-21 Credit resources consumed by admitted UEs before and after CE
Overbooking is enabled
Before or After CE Credit Resource Consumed by Admitted UEs
Overbooking is Enabled
Before CE Overbooking is The RNC calculates the usage of CEs for admitted UEs by
enabled adding up credit resources reserved for each UE.
 R99 UE: The RNC calculates the usage of credit resources
for an R99 UE based on the maximum bit rate (MBR).
 HSUPA UE: The RNC calculates the usage of credit
resources for an HSUPA UE based on MAX (GBR, Rateone
RLC PDU).
After CE Overbooking is The NodeB calculates the usage of credit resources for all
enabled admitted UEs at the cell and NodeB levels and periodically
reports the calculation results to the RNC through
measurement reports (MRs).
 R99 UE: The NodeB calculates the usage of credit
resources for an R99 UE based on the MBR.
 HSUPA UE using a 10 ms transmission time interval (TTI):
The NodeB adjusts the credit resource usage of such a UE
based on the UE's rate. After the adjustment, the credit
resources consumed by such a UE must not exceed the credit
resources required by Rateone RLC PDU.
 HSUPA UE using a 2 ms TTI: The NodeB adjusts the credit
resource usage of such a UE based on the UE's rate and the
minimum number of CEs (specified by
CERSVFOR2MSUSER) reserved for admitting such a UE.
After the adjustment, the credit resources consumed by such
a UE must not exceed the credit resources required by
Rateone RLC PDU.
The minimum number of CEs reserved for admitting an HSUPA UE

using a 2 ms TTI is 4 by default. The value range is 1 to 8.
For details about CE Overbooking, see CE Overbooking Feature Parameter Description.
CCHs do not require extra CE resources because the RNC reserves CE resources for
services on these channels. Signaling carried on an associated channel of the DCH does
not consume extra CE resources, either. One CE can be consumed by a 12.2 kbit/s voice
call.
For details about CE number consumed by different services, see CE Resource
Management Feature Parameter Description.

The RNC provides counters to monitor CE usage.
The NodeB uses separate baseband processing units in the uplink and downlink.
Therefore, the NodeB manages uplink and downlink CE resources separately.
License-based Downlink CE Usage

The downlink CE usage is defined as follows:
License-based downlink CE usage = DL NodeB Mean CE Used Number/DL License CE
Number
where
 DL NodeB Mean CE Used Number = VS.NodeB.DLCreditUsed.Mean
 DL License CE Number can be obtained by choosing License > NE License
Management > NodeB on the U2000.
The associated counter is VS.NodeB.DLCreditUsed.Mean.
License-based Uplink CE Usage

The uplink CE usage is defined as follows:
License-based uplink CE usage = UL NodeB Mean CE Used Number/UL License CE
Number
 UL NodeB Mean CE Used Number = (VS.NodeB.ULCreditConsumed.Mean +
VS.NodeB.CoordinatingRL.ULCreditUsed.Mean)/2
where
"/2" indicates the number of uplink CEs because the number of uplink credit
resources is twice the number of uplink CEs, whereas the number of downlink credit
resources is equal to the number of downlink CEs.
 UL License CE Number can be obtained by choosing License > NE License
Management > NodeB on the U2000.
 VS.NodeB.ULCreditConsumed.Mean
 VS.NodeB.CoordinatingRL.ULCreditUsed.Mean
Hardware-based downlink CE usage

Hardware-based downlink CE usage is defined as follows:
Hardware-based downlink CE usage = DL NodeB Mean CE Used Number/DL CE
Capacity Number
where
 The value of DL NodeB Mean CE Used Number equals that used for calculating the
license-based downlink CE usage.
 DL CE Capacity Number = VS.HW.DLCreditAvailable
Hardware-based Uplink CE Usage
Hardware-based downlink CE usage is defined as follows:
Hardware-based uplink CE usage = UL NodeB Mean CE Used Number/UL CE Capacity
Number
where
 The value of UL NodeB Mean CE Used Number equals that used for calculating the
license-based uplink CE usage.
 UL CE Capacity Number = VS.HW.ULCreditAvailable
The CE resource usage can be monitored by alarms. If the CE hardware capacity is
exceeded, ALM-28230 Base Station Service Overload is reported.

If the uplink/downlink license- or hardware-based CE usage is greater than 70% during
peak hours for n days (n is specified based on the actual situation; 3 days by default) in a
week, perform capacity expansion as follows:
 If the license-based CE usage exceeds its capacity expansion threshold, CE resources
are limited by the license. In this situation, upgrade the license file.
 If the hardware-based CE usage exceeds the capacity expansion threshold, CE resources
are limited by the hardware capacity. In this situation, add WBBP boards.
If capacity expansion is inapplicable, perform the following operations:
 Run the RNC MML command SET UCORRMALGOSWITCH. In this step, select
the DRA_DCCC_SWITCH and
DRA_BASE_ADM_CE_BE_TTI_RECFG_SWITCH check boxes under the
Dynamic Resource Allocation Switch parameter to enable the DCCC algorithm and
the TTI dynamic adjustment algorithm for admission CE-based BE services,
respectively.
 Run the RNC MML command SET UUSERGBR with the Uplink GBR for BE
service parameter set to D32.
Newly added CE resources can share the traffic in hotspots and relieve CE congestion
caused by traffic overflow.
2.17 NodeB CNBAP Load
Table 2-22 CNBAP resource monitoring

Insufficiency
CNBAP CNBAP load is used to assess a CNBAP overload will cause radio
NodeB's processing capability. link setup failures, thereby
decreasing the RRC connection
setup and RAB setup success rates.

The CNBAP load on a NodeB can be measured by license- and hardware-based CNBAP
usage.
License-based CNBAP Usage

License-based CNBAP Usage = (VS.RadioLink.Recv.Mean +
VS.DedicMeaRpt.MEAN/12)/License CNBAP
where
License CNBAP = NodeB License CNBAP Cfg Number, which can be got by running the
NodeB command DSP LICENSE.
 VS.RadioLink.Recv.Mean
 VS.DedicMeaRpt.MEAN
Hardware-based CNBAP Usage

Hardware-based CNBAP Usage = VS.BTS.CnbapCap.UseRate
The associated counter is VS.BTS.CnbapCap.UseRate.
CNBAP usage can be monitored by alarms. If the CNBAP hardware capacity is exceeded,
ALM-28230 Base Station Service Overload is reported.

If the peak-hour CNBAP usage reaches the capacity expansion threshold within n days (n
is specified based the actual situation; 3 days by default) in a week, prepare for capacity
 The features mentioned in Figure 2-24 refer to WRFD-010202 UE State in Connected Mode
(CELL_DCH, CELL_PCH, URA_PCH, CELL_FACH) and WRFD-020500 Enhanced Fast
Dormancy.
 For details about how to enable the WRFD-010202 UE State in Connected Mode (CELL_DCH,
CELL_PCH, URA_PCH, CELL_FACH) feature, see State Transition Feature Parameter
Description in the RAN Feature Documentation.
 For details about how to enable the WRFD-020500 Enhanced Fast Dormancy feature, see
Enhanced Fast Dormancy Feature Parameter Description in the RAN Feature Documentation.
 The maximum CNBAP capability of a NodeB is 1500. When the CNBAP capability configured
for a NodeB is less than 1500, replace boards to expand the capacity if CNBAP overload occurs.
For the CNBAP capabilities of the WBBP boards, see 3900 Series Base Station Technical
Description.
2.18 HSPA Users
Table 2-23 HSPA user resource monitoring

Insufficiency
HSPA HSPA services are carried on the If BBP boards are overloaded with
users BBP boards in a NodeB. HSPA users, new users may fail to
Therefore, the number of HSPA access the network.
users determines BBP board
loads.

The following NodeB counters are used to monitor the percentage of the number of HSPA
users on a BBP board to the configured number of HSPA users:
 VS.BOARD.UsedHsdpaUserRatio.Mean
 VS.BOARD.UsedHsupaUserRatio.Mean

If the percentage of the number of HSDPA/HSUPA users on a WBBP or UBBP board to
the configured number of HSDPA/HSUPA users exceeds 60% during peak hours within n
days (n is specified based the actual situation; 3 days by default) in a week, prepare for
capacity expansion as instructed in Figure 2-25.
 For details about how to enable the WRFD-150242 HSDPA Scheduler Pool feature, see HSDPA
Scheduler Pool Feature Parameter Description in the RAN feature documentation. For details
about how to enable the WRFD-170205 HSUPA Scheduler Pool feature, see HSUPA Scheduler
Pool Feature Parameter Description in the RAN feature documentation.
 The number of HSPA users supported by a WBBP board varies according to board type. For
detailed numbers of HSPA users supported by different WBBP boards, see 3900 Series Base
Station Technical Description.
3 Network Resource Troubleshooting
The monitoring method described in chapter 2 "Network Resource Monitoring" is

effective in most scenarios. However, other scenarios may require more detailed
troubleshooting to determine if high resource occupancy is caused by traffic increases or
other abnormalities.
This chapter describes how to locate network resource problems that require more
complex troubleshooting and is intended for personnel who:
 Have a deep understanding of WCDMA networks
 Are familiar with the signaling procedure
 Are familiar with the operation and maintenance of Huawei products
3.1 Possible Block and Failure Points in the Basic Call Flow
When network resources are insufficient, accessibility-related KPIs are likely to be
affected first.
Figure 3-1 uses a mobile terminated call (MTC) as an example to illustrate the basic call
flow, with possible block/failure points indicated. For details about the basic call process,
see 3GPP TS 25.931.
Figure 3-1 Basic call flow chart and possible block/failure points
The basic call flow illustrated in Figure 3-1 is described as follows:

Step 1 The CN sends a paging message to the RNC.
Step 2 Upon receiving the paging message, the RNC broadcasts the message on a PCH. If the
PCH is congested, the RNC may drop the message at block point #1.
Step 3 The UE may not receive the paging message or access the network, and fails to respond
to RNC's paging message. See failure point # 2.
Step 4 If the UE receives the paging message, it sends an RRC connection setup request to the
RNC.
Step 5 If the RNC is congested when receiving the RRC connection setup request, the RNC
may drop the request message. See block point #3.
Step 6 If the RNC receives the RRC connection setup request and does not discard it, the RNC
determines whether to accept or reject the request. The request may be rejected due to
insufficient resources, as shown in block point #4.
Step 7 If the RNC accepts the request, the RNC instructs the UE to set up an RRC connection.
The UE may not receive RNC's response message or may find that the configuration does
not support RRC connection setup. 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 of
RAN. See block point #7.
Step 10 If the RNC accepts the RAB assignment request, it initiates an RB setup process. During
the process, the RNC sets up radio links (RLs) to the NodeB over the Iub interface and
sends an RB setup message to the UE over the Uu interface. The RL or RB setup process
may incur failures. See failure points #8 and #9.
----End
3.2 Counters Related to Call Congestion

As shown in Figure 3-1, call congestion may occur during paging, RRC connection setup,
or RAB setup. This section describes counters related to call congestion. For details about
these counters, see chapter 4 "Metrics Definitions."
3.2.1 Paging Loss

The counters measuring RNC- and cell-level paging loss are as follows:
 RNC-level paging loss
The counters measuring paging loss caused by Iu-interface flow control, CPU
overload, or RNC-level PCH congestion are as follows:
− VS.RANAP.CsPaging.Loss: number of failed responses after the RNC receives
CS paging messages from the CN
− VS.RANAP.PsPaging.Loss: number of failed responses after the RNC receives
PS paging messages from the CN
− VS.RANAP.CsPaging.Att: number of CS paging messages received by the RNC
from the CN
− VS.RANAP.PsPaging.Att: number of PS paging messages received by the RNC
from the CN
Calculation formula:
IU Paging Congestion Ratio (RNC) = [(VS.RANAP.CsPaging.Loss +
VS.RANAP.PsPaging.Loss)/(VS.RANAP.CsPaging.Att +
VS.RANAP.PsPaging.Att)] x 100%
 Cell-level paging loss
The counters measuring paging loss caused by cell-level PCH congestion are as
follows:
− VS.RRC.Paging1.Loss.PCHCong.Cell: number of discarded paging messages
due to PCH congestion in a cell
− VS.UTRAN.AttPaging1: number of paging messages of paging type 1 sent by the
RNC in a cell
Calculation formula:
Iu-interface paging loss ratio (cell) =
(VS.RRC.Paging1.Loss.PCHCong.Cell/VS.UTRAN.AttPaging1) x 100%
3.2.2 RRC Congestion

The following table describes the mapping between reasons of RRC connection setup
rejections and corresponding counters.
Rejection Reason Counter

Uplink power VS.RRC.Rej.ULPower.Cong: Number of RRC Connection
congestion Rejects for Cell (UL Power Congestion)
Downlink power VS.RRC.Rej.DLPower.Cong: Number of RRC Connection

congestion Rejects for Cell (DL Power Congestion)
Uplink CE resource VS.RRC.Rej.ULCE.Cong: Number of RRC Connection
congestion Rejects for Cell (UL CE Resource Congestion)
Downlink CE VS.RRC.Rej.DLCE.Cong: Number of RRC Connection
resource congestion Rejects for Cell (DL CE Resource Congestion)
Uplink Iub bandwidth VS.RRC.Rej.ULIUBBand.Cong: Number of RRC
resource congestion Connection Rejects for Cell (UL Iub Bandwidth Congestion)
Downlink Iub VS.RRC.Rej.DLIUBBand.Cong: Number of RRC

bandwidth resource Connection Rejects for Cell (DL Iub Bandwidth Congestion)
congestion
Downlink code VS.RRC.Rej.Code.Cong: Number of RRC Connection
resource congestion Rejects for Cell (Code Resource Congestion)
The RRC block rate is calculated using the following formula:

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.ULCE.Cong > +< VS.RRC.Rej.DLCE.Cong > + <
VS.RRC.Rej.ULIUBBand.Cong > + < VS.RRC.Rej.DLIUBBand.Cong > + <
VS.RRC.Rej.Code.Cong >
 VS.RRC.AttConnEstab.Sum: Number of Processed RRC Connection Requests for Cell
3.2.3 RAB Congestion

The following table describes the mapping between reasons of RAB setup rejections and
corresponding counters.
Rejection Counter
Reason
Power congestion  VS.RAB.FailEstabCS.ULPower.Cong: Number of Failed CS
RAB Establishments for Cell (UL Power Congestion)
 VS.RAB.FailEstabCS.DLPower.Cong: Number of Failed CS
RAB Establishments for Cell (DL Power Congestion)
 VS.RAB.FailEstabPS.ULPower.Cong: Number of Failed PS
RAB Establishments for Cell (UL Power Congestion)
 VS.RAB.FailEstabPS.DLPower.Cong: Number of Failed PS
RAB Establishments for Cell (DL Power Congestion)
Uplink CE  VS.RAB.FailEstabCS.ULCE.Cong: Number of Failed CS
congestion RAB Establishments for Cell (UL CE Congestion)
 VS.RAB.FailEstabPS.ULCE.Cong: Number of Failed PS RAB
Establishments for Cell (UL CE Congestion)
Downlink CE  VS.RAB.FailEstabCs.DLCE.Cong: Number of Failed CS RAB
congestion Establishments for Cell (DL CE Congestion)
 VS.RAB.FailEstabPs.DLCE.Cong: Number of Failed PS RAB
Establishments for Cell (DL CE Congestion)
Downlink code  VS.RAB.FailEstabCs.Code.Cong: Number of Failed CS RAB

resource Establishments for Cell (Code Congestion)
congestion  VS.RAB.FailEstabPs.Code.Cong: Number of Failed PS RAB
Establishments for Cell (Code Congestion)
Iub bandwidth  VS.RAB.FailEstabCS.DLIUBBand.Cong: Number of Failed
congestion CS RAB Establishments for Cell (DL Iub Bandwidth
Congestion)
 VS.RAB.FailEstabCS.ULIUBBand.Cong: Number of Failed
CS RAB Establishments for Cell (UL Iub Bandwidth
Congestion)
 VS.RAB.FailEstabPS.DLIUBBand.Cong: Number of Failed
PS RAB Establishments for Cell (DL Iub Bandwidth
Congestion)
 VS.RAB.FailEstabPS.ULIUBBand.Cong: Number of Failed
PS RAB Establishments for Cell (UL Iub Bandwidth
Congestion)
The RAB block rate is calculated using the following formula:

VS.RAB.Block.Rate = Total number of failed RAB establishments regardless of the cause
of failure/VS.RAB.AttEstab.Cell
where VS.RAB.AttEstab.Cell measures the total number of RAB setup requests in a cell.
This counter is calculated as follows:
VS.RAB.AttEstab.Cell = VS.RAB.AttEstabCS.Conv + VS.RAB.AttEstabCS.Str +
VS.RAB.AttEstabPS.Conv + VS.RAB.AttEstabPS.Bkg + VS.RAB.AttEstabPS.Int +
VS.RAB.AttEstabPS.Str
3.3 Resource Usage Analysis
Figure 3-2 illustrates the general troubleshooting procedure for resource usage issues.
Figure 3-2 General troubleshooting procedure for resource usage issues
In most cases, the troubleshooting procedure includes detecting abnormal KPIs, selecting
top N cells, and analyzing abnormal KPIs.
In the case of system bottlenecks, accessibility-related KPIs are usually checked first
because most of the access congestion issues are caused by insufficient system resources.
Figure 3-3 shows key points for bottleneck analysis. The following sections then describe
these key points.
Figure 3-3 Key points for bottleneck analysis
3.3.1 CP CPU Load Analysis

Current networks are generally vulnerable to signaling storms caused by smartphones, and
the CP's signaling processing capability is most likely to become the system bottleneck.
If the CP CPU load exceeds the predefined alarm threshold, the RNC starts flow control to
discard some RRC connection setup requests or paging requests. From the perspective of
maintenance, the CP CPU load must be less than the alarm threshold to guarantee system
safety.
Figure 3-4 illustrates the procedure for analyzing the CP CPU load.
Figure 3-4 Procedure for analyzing the CP CPU load
As shown in Figure 3-4, if the CP CPU load exceeds 50%, analyze the cause of the
problem and prevent the CPU load from increasing further. In addition, perform an in-
depth analysis of the high CPU load, for example, check whether the parameter
configurations are appropriate. If the high CPU load is caused by an increase in traffic
volume, it is recommended that you expand hardware capacity.
CP/UP flexible deployment can adjust the hardware resources in the CP and UP pools so
that these pools have basically the same average load. Because the non-pooled load in the
CP cannot be shared, dynamic cell allocation is required to balance this load in the CP
pool.
If the traffic model changes, the load can be balanced between CP and UP pools to a
certain degree but cannot be completely balanced. For example, if the CP CPU load is
lower than the UP CPU load but the remaining CP resources are insufficient to bear new
NodeBs and cells, it is recommended that you reduce the number of cells in the RNC or
add new boards.
3.3.2 UP CPU Load Analysis

If the load on the GPU board or interface board is too high, the RNC discards some user-
plane data. Figure 3-5 illustrates the procedure for analyzing the UP CPU load.
Figure 3-5 Procedure for analyzing the UP CPU load
If the UP CPU load exceeds 60%, analyze the cause of the problem and prevent the CPU
load from increasing further. If the high CPU load is caused by an increase in traffic
volume, it is recommended that you expand hardware capacity.
3.3.3 CE Resource Analysis

Both CE congestion and CE resource monitoring require CE resource analysis. If CE
usage remains greater than the preset overload threshold or if CE congestion occurs, CE
resources are insufficient and must be increased to ensure system stability.
Figure 3-6 illustrates the procedure for analyzing CE congestion.
Figure 3-6 Procedure for analyzing CE congestion
CE resources can be shared within a resource group. Therefore, CE usage on the NodeB
must be calculated to determine whether CE congestion occurs in a resource group or the
NodeB. If CE congestion occurs in a resource group, reallocate CE resources among
resource groups. If CE congestion occurs in the NodeB, perform capacity expansion.
3.3.4 Iub Resource Analysis

Figure 3-7 illustrates the procedure for analyzing Iub bandwidth congestion.
Figure 3-7 Procedure for analyzing Iub bandwidth congestion
3.3.5 Power Resource Analysis

If the uplink RTWP and downlink TCP values are greater than the preset thresholds,
power congestion occurs.
If power congestion occurs in the downlink, enable the load reshuffling (LDR) and
overload control (OLC) functions. If power congestion occurs in the uplink, analyze
whether the problem is caused by interference or traffic increases.
If the RTWP value remains greater than -97 dBm, identify root causes and troubleshoot
the problem.
If the problem is caused by heavy traffic instead of signaling storms, perform the
following operations:
 Enable LDR and OLC for temporary troubleshooting.
 Add carriers or split cells for a long-term solution.
Figure 3-8 illustrates the procedure for analyzing power resource usage.
Figure 3-8 Procedure for analyzing power resource usage
Generally, adding a carrier is the most effective means of relieving uplink power
congestion. If no additional carrier is available, add a NodeB or reduce the downtilt of the
antenna.
3.3.6 PCH Usage Analysis

In most cases, PCHs are overloaded because an LA covers too many cells. Replan LAs to
resolve the PCH overload.
Figure 3-9 illustrates the procedure for analyzing PCH usage.
Figure 3-9 Procedure for analyzing PCH usage
3.3.7 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.
Methods of relieving FACH congestion are as follows:
 Shorten the period during which PS services are carried on FACHs to enable fast UE
state 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.
Figure 3-10 illustrates the procedure for analyzing FACH usage.
Figure 3-10 Procedure for analyzing FACH usage

4 Metrics Definitions
Counter Description
elated Metrics
Vs.Call.Block.Rate (customized) Vs.RRC.Block.Rate + (<RRC.SuccConnEstab.sum>/(<VS.RRC.AttConnEstab.CellDCH> +
<VS.RRC.AttConnEstab.CellFACH>)) x Vs.Rab.Block.Rate
Vs.RRC.Block.Rate (customized) (<VS.RRC.Rej.ULPower.Cong> + <VS.RRC.Rej.DLPower.Cong> + <VS.RRC.Rej.ULIUBB

<VS.RRC.Rej.DLIUBBand.Cong> + <VS.RRC.Rej.ULCE.Cong> + <VS.RRC.Rej.DLCE.Co
<VS.RRC.Rej.Code.Cong>)/<VS.RRC.AttConnEstab.Sum>
Vs.RAB.Block.Rate (customized) (<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.AttEstabCS.Conv + VS.RAB.AttEstab
VS.RAB.AttEstabPS.Conv + VS.RAB.AttEstabPS.Bkg + VS.RAB.AttEstabPS.Int +
VS.RAB.AttEstabPS.StrRAB)
VS.RAB.AttEstab.Cell (customized) (<VS.RAB.AttEstCS.Conv> + <VS.RAB.AttEstab.CS.Str> + <VS.RAB.AttEstabPS.Conv> +

<VS.RAB.AttEstabPS.Str> + <VS.RAB.AttEstabPS.Int> + <VS.RAB.AttEstabPS.Bkg>)
-related Metrics
VS.MeanTCP.NonHS
where MAXTXPOWER is the maximum power configured for a cell. Measured in watts.
VS.MeanTCP
where MAXTXPOWER is the maximum power configured for a cell. Measured in watts.
VS.MeanRTWP VS.MeanRTWP
VS.MinRTWP VS.MinRTWP
VS.RAC.UL.EqvUserNum VS.RAC.UL.EqvUserNum/UlTotalEqUserNum
Counter Description
Resource Usage-related Metrics

VS.AAL2.CAC.Succ VS.AAL2.CAC.Succ/VS.AAL2.CAC.Att
VS.AAL2.CAC.Att
VS.SAALLNK.PVCLAYER.TXBYTES DL Iub Usage on Control Plane = VS.SAALLNK.PVCLAYER.TXBYTES x 8/1000/<SP>/TX

VS.SAALLNK.PVCLAYER.RXBYTES
UL Iub Usage on Control Plane = VS.SAALLNK.PVCLAYER.RXBYTES x 8/1000/<SP>/RX
 ATM Transmission ATM Transmission

VS.AAL2PATH.PVCLAYER.TXBYTES DL Iub Usage on User Plane = Sum (VS.AAL2PATH.PVCLAYER.TXBYTES) x 8/<SP>/10
VS.AAL2PATH.PVCLAYER.RXBYTES BW_CFG
 IP transmission in non-pooled networking: IP transmission in non-pooled networking:
VS.IPPATH.IPLAYER.TXBYTES DL Iub Usage on User Plane = Sum (VS.IPPATH.IPLAYER.TXBYTES) x 8/<SP>/1000/TX
VS.IPPATH.IPLAYER.RXBYTES IP transmission in resource pool networking:
 IP transmission in resource pool networking: DL Iub Usage on User Plane = VS.IPPOOL.ANI.IPLAYER.TXBYTES x 8/<SP>/1000/TX B
VS.IPPOOL.ANI.IPLAYER.TXBYTES ATM Transmission
VS.IPPOOL.ANI.IPLAYER.RXBYTES UL Iub Usage on User Plane = Sum (VS.AAL2PATH.PVCLAYER.RXBYTES) x 8/<SP>/10
BW_CFG
IP transmission in non-pooled networking:
UL Iub Usage on User Plane = Sum (VS.IPPATH.IPLAYER.RXBYTES) x 8/<SP>/1000/RX
IP transmission in resource pool networking:
UL Iub Usage on User Plane = VS.IPPOOL.ANI.IPLAYER.RXBYTES x 8/<SP>/1000/RX B
VS.ANI.IP.Conn.Estab.Succ VS.ANI.IP.Conn.Estab.Succ/VS.ANI.IP.Conn.Estab.Att
VS.ANI.IP.Conn.Estab.Att
Usage-related Metrics
VS.UTRAN.AttPaging1 VS.UTRAN.AttPaging1/(<SP> x 60 x 5/0.01)
Counter Description
VS.CRNCIubBytesFACH.Tx (1) Utilization of FACH carried on non-standalone SCCPCH

VS.PCH.Bandwidth.UsageRate FACH Usage = VS.CRNCIubBytesFACH.Tx x 8/((60 x <SP> x 168 x 1/0.01) x
VS.SRBNum.FACH VS.PCH.Bandwidth.UsageRate x 6/7 + (60 x <SP> x 360 x 1/0.01) x (1 - VS.PCH.Bandwidth
6/7))
VS.OneSRBTTINum.FACH
where,
VS.IndepTRBNum.FACH
VS.PCH.Bandwidth.UsageRate = <VS.CRNCIubBytesPCH.Tx>/(<VS.CRNC.IUB.PCH.Band
<SP> x 60)
(2) Utilization of FACH carried on standalone SCCPCH
FACH Usage = ((VS.SRBNum.FACH - VS.OneSRBTTINum.FACH)/2 + VS.OneSRBTTINu
VS.IndepTRBNum.FACH)/(<SP> x 60/0.01)
VS.CRNCIubBytesRACH.Rx RACH Usage = ((VS.CRNCIubBytesRACH.Rx - VS.TRBNum.RACH x 360/8) x 8/168)/(<S

VS.TRBNum.RACH 4/0.02) + VS.TRBNum.RACH/(<SP> x 60 x 4/0.02)
VS.TRBNum.RACH
-related Metrics
VS.RAB.SFOccupy VS.RAB.SFOccupy
VS.RAB.SFOccupy.Ratio VS.RAB.SFOccupy/256
 VS.SingleRAB.SF4 DCH OVSF Usage = DCH_OVSF_CODE/DCH_OVSF_CODE_Ava

 VS.MultRAB.SF4 where
 VS.MultRAB.SF8 DCH_OVSF_CODE = (<VS.SingleRAB.SF4> + <VS.MultRAB.SF4>) x 64 + (<VS.MultRA
 VS.SingleRAB.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.Single
 VS.MultRAB.SF16 x 4 + (<VS.SingleRAB.SF128> + <VS.MultRAB.SF128>) x 2 + (<VS.SingleRAB.SF256> +
 VS.SingleRAB.SF16 <VS.MultRAB.SF256>)
 VS.SingleRAB.SF32
 VS.MultRAB.SF32
 VS.MultRAB.SF64
 VS.MultRAB.SF128
 VS.MultRAB.SF256
 VS.PdschCodeUsed.Mean HS-PDSCH Code Usage =

 VS.PdschCodeAvail.Mean Sum_AllCells_of_NodeB(VS.PdschCodeUsed.Mean)/Sum_AllCells_of_NodeB(VS.PdschCo
VS.ScchCodeUtil.Mean HS-SCCH Code Usage = VS.ScchCodeUtil.Mean/1000

Counter Description
lated Metrics
VS.CPPOOL.CPULOAD.MEAN CP Load =VS.CPPOOL.CPULOAD.MEAN
VS.UPPOOL.CPULOAD.MEAN UP Load =VS.UPPOOL.CPULOAD.MEAN
VS.CPU.CPULOAD.MEAN VS.CPU.CPULOAD.MEAN
VS.INT.TRANSLOAD.RATIO.MEAN VS.INT.TRANSLOAD.RATIO.MEAN
rce Usage-related Metrics

VS.NodeB.ULCreditUsed.Mean DL NodeB Mean CE Used Number/DL License CE Number
VS.LC.ULCreditUsed.Mean
VS.LC.DLCreditUsed.Mean
VS.HW.DLCreditAvailable
UL NodeB Mean CE Used Number/UL License CE Number
VS.HW.ULCreditAvailable
VS.NodeB.CoordinatingRL.ULCreditUsed.Mean
VS.NodeB.ULCreditConsumed.Mean
DL NodeB Mean CE Used Number/DL CE Capacity Number
UL NodeB Mean CE Used Number/UL CE Capacity Number
Load-related Metrics
VS.Frame.Flux. Mean.TxRate Frame Mean Usage = VS.Frame.Flux.Mean.TxRate/Inter-subrack bandwidth x 100%
AP Load-related Metrics
VS.RadioLink.Recv.Mean License-based CNBAP Usage = (VS.RadioLink.Recv.Mean + VS.DedicMeaRpt.MEAN/12)/L
VS.DedicMeaRpt.MEAN CNBAP
VS.BTS.CnbapCap.UseRate
Counter Description
Hardware-based CNBAP Usage = VS.BTS.CnbapCap.UseRate
elated Metrics
VS.BOARD.UsedHsdpaUserRatio.Mean VS.BOARD.UsedHsdpaUserRatio.Mean
VS.BOARD.UsedHsupaUserRatio.Mean VS.BOARD.UsedHsupaUserRatio.Mean
Ratio Metrics
 In single-operator scenarios:
VS.CSLoad.Erlang.Equiv.RNC CS License Ratio = VS.CSLoad.Erlang.Equiv.RNC/Voice Erlang - Erlang x 100%
VS.CSLoad.Erlang.Equiv. PLMN.RNC  In multi-operator scenarios:
CS License Ratio= VS.CSLoad.Erlang.Equiv. PLMN.RNC/Voice Erlang - Erlang x 100%
VS.R99PSLoad.ULThruput.RNC PS R99 Throughput License Ratio = (VS.R99PSLoad.ULThruput.RNC +
VS.R99PSLoad.DLThruput.RNC VS.R99PSLoad.DLThruput.RNC)/(PS throughput only (per Mbit/s) x 1000) x 100%
VS.R99PSLoad.ULThruput. PLMN.RNC  In multi-operator scenarios:
VS.R99PSLoad.DLThruput. PLMN.RNC PS R99 Throughput License Ratio = (VS.R99PSLoad.ULThruput. PLMN.RNC +
VS.R99PSLoad.DLThruput. PLMN.RNC)/(PS throughput only (per Mbit/s) x 1000) x 100
HSDPA Throughput License Ratio = VS.HSDPAPSLoad.DLThruput.RNC/(HSDPA Thro
VS.HSDPAPSLoad.DLThruput.RNC Mbit/s)) x 1000) x 100%
VS.HSDPAPSLoad.DLThruput. PLMN.RNC  In multi-operator scenarios:
HSDPA Throughput License Ratio = VS.HSDPAPSLoad.DLThruput. PLMN.RNC/(HSDP
Throughput (per Mbit/s)) x 1000) x 100%
HSUPA Throughput License Ratio = VS.HSUPAPSLoad.ULThruput.RNC/(HSUPA Thro
VS.HSUPAPSLoad.ULThruput.RNC Mbit/s) x 1000) x 100%
VS.HSUPAPSLoad.ULThruput. PLMN.RNC  In multi-operator scenarios:
HSUPA Throughput License Ratio = VS.HSUPAPSLoad.DLThruput. PLMN.RNC/(HSUP
Throughput (per Mbit/s)) x 1000) x 100%
PS Throughput License Ratio= VS.PSLoad.Thruput.RNC/(PS throughput only (per Mbit/s
VS.PSLoad.Thruput.RNC 100%
VS.PSLoad.Thruput. PLMN.RNC  In multi-operator scenarios:
PS Throughput License Ratio= VS.PSLoad.Thruput. PLMN.RNC/(PS throughput only (pe
1000) x 100%
Counter Description
RNC Hardware Capacity License Utilization Rate = VS.HWLicense.Thruput.RNC/(RNC Thro

VS.HWLicense.Thruput.RNC
Hardware Capacity (per 50 Mbit/s)License allocated x 50 x 1000) x 100%
RNC ENIUa License Utilization Rate = VS.NIUPSLoad.Thruput.RNC/(Evolved Network Inte

VS.NIUPSLoad.Thruput.RNC
Processing Throughput License allocated x 50 x 1000) x 100%
VS.CellDCHUEs.RNC Active User License Utilization Rate = (VS.CellDCHUEs.RNC + VS.CellFACHUEs.RNC)/(R

VS.CellFACHUEs.RNC User Hardware Capacity (per 1000 Active Users)License allocated x 1000) x 100%
Cell HSDPA Users License Utilization Rate = VS.HSDPA.UE.Mean.Cell/Max HSDPA users

VS.HSDPA.UE.Mean.Cell
users license per cell x 100%
Cell HSUPA Users License Utilization Rate = VS.HSUPA.UE.Mean.Cell/Max HSUPA users

VS.HSUPA.UE.Mean.Cell
users license per cell x 100%
5 Reference Documents
This chapter lists the documents referenced within the text and provides the document
name, document package, and document package download path at
http://support.huawei.com.
Document Name Document Package Document Package

Download Path at
http://support.huawei.com
3900 Series Base Station 3900 Series Base Wireless -> WCDMA-RAN ->
Technical Description Station Product WCDMA-NodeB
Documentation
Flow Control Feature Parameter RAN Feature Wireless -> WCDMA-RAN ->
Description Documentation WCDMA-RAN Public
Transmission Resource Pool in
RNC Feature Parameter
Description
Dynamic Configuration Based on

the Uplink Load Feature
Parameter Description
Power Control Feature Parameter
Description
HSDPA Feature Parameter

Description
CE Resource Management
Feature Parameter Description
CE Overbooking Feature
State Transition Feature

Capacity Monitoring Guide - R18

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Capacity Monitoring Guide - R18

Загружено:

Авторское право:

Доступные форматы

RAN18.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base

1.2 Intended Audience

1.3 Change History

Change Type Change Description

Change Type Change Description

Change Type Change Description

Technical change None

Editorial change  Optimized descriptions on optimization suggestions by using

About This Document

2 Network Resource Monitoring

3 Network Resource Troubleshooting

This chapter introduces network resources and monitoring methods.

1.1 Network Resources

Figure 1-1 Network resources to be monitored

1.1.1 RNC Resources

1.1.2 NodeB Resources

1.1.3 Cell Resources

1.2 Monitoring Methods

Table 1-1 Monitoring methods

Proactive It is used to It is easy to If resource Network

Problem- This method It maximizes This method Network

This chapter discusses only proactive monitoring.

2.1 Monitoring Metrics and Procedure

2.1.1 Monitoring Metrics

Table 2-1 lists RNC resources, counters, and monitoring thresholds.

Table 2-1 RNC resources, counters, and monitoring thresholds

UP CPU load VS.UPPOOL.CPULOAD.MEAN 60%

SCU CPU load VS.CPU.CPULOAD.MEAN 60%

Table 2-2 NodeB resources, counters, and monitoring thresholds

CNBAP NodeB CNBAP load  VS.RadioLink.Recv.Mean 60%

Table 2-3 Cell resources, counters, and monitoring thresholds

FACH usage VS.CRNCIubBytesFACH.Tx 70%

RACH usage VS.CRNCIubBytesRACH.Rx 70%

DL load Non-HSPA VS.MeanTCP 70%

TCP usage VS.MeanTCP.NonHS 85%

ENU VS.RAC.UL.EqvUserNum 75%

HS-SCCH HS-SCCH VS.ScchCodeUtil.Mean 70%

Table 2-4 Transport resources, counters, and monitoring thresholds

Iub/Iur/Iu IP Admission success VS.ANI.IP.Conn.Estab.Succ 99%

Control-plane VS.SCTP.TX.BYTES 70%

Figure 2-1 Resource monitoring flowchart

2.2 CP/UP CPU Load

2.2.1 Monitoring Principles

Table 2-5 CP/UP resources monitoring

CP It is used to process Uu interface If CP is overloaded, new messages

UP It is used to process and distribute If UP is overloaded, user-plane

2.2.2 Monitoring Methods

2.2.3 Optimization Suggestions

Figure 2-2 Capacity expansion scheme

Figure 2-3 Capacity expansion procedure

2.3.1 Monitoring Principles

Table 2-6 RMP resources monitoring

2.3.2 Monitoring Methods

2.3.3 Optimization Suggestions

Figure 2-4 Capacity expansion scheme

2.4.1 Monitoring Principles

Table 2-7 Interface board monitoring

2.4.2 Monitoring Methods

2.4.3 Optimization Suggestions

Figure 2-5 Capacity expansion scheme