Professional Documents
Culture Documents
Issue
01
Date
2012-04-30
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.
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
Audience
This document is intended for network maintenance personnel.
Organization
This document consists of the following chapters.
Chapter
Description
1 Network Resource
Monitoring Methods
2 Network Resource
Counters
3 HSPA Related
Resources
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.
Issue 01 (2012-04-30)
ii
RAN14.0
Capacity Monitoring Guide
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.
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.
Issue 01 (2012-04-30)
iii
RAN14.0
Capacity Monitoring Guide
Contents
Contents
About This Document .................................................................................................................... ii
1 Network Resource Monitoring Methods ................................................................................. 1
1.1 Network Resource Introduction ....................................................................................................................... 1
1.2 Resource Monitoring Procedure ....................................................................................................................... 3
Issue 01 (2012-04-30)
iv
RAN14.0
Capacity Monitoring Guide
Contents
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
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."
In addition to the preceding two methods, other methods may also be used by network maintenance
engineers for system problem analysis.
Issue 01 (2012-04-30)
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.
RAN14.0
Capacity Monitoring Guide
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.
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.
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.
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.
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.
WCDMA main processing and transmission unit (WMPT): The WMPT 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.
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.
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
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."
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
Figure 2-1 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:
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.
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
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:
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.3 CE Usage
CEs are baseband resources provided by NodeBs. One CE corresponds to the resource
consumed by a 12.2 kbit/s voice call. If available CE resources are insufficient, a new call
request may be rejected.
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 are sufficient and the CE resources are only
limited by licenses, you can implement capacity expansion by only upgrading license files.
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
For Huawei RANs, various counters are available to monitor CE resources. Once the CE
resource usage of a cell is higher than its upper threshold (such as 70%) in the busy hour for
two or three days in one week, the cell is overloaded. Add CE resources.
For Huawei equipment on the RAN side, the following counters are defined to indicate CE
usage:
Separate baseband processing units are used in the uplink and downlink directions of a NodeB,
and therefore uplink CE resources are managed independently of downlink CE resources.
Uplink and downlink CE usages are defined as:
NodeB_UL_CE_MEAN_RATIO = (VS.LC.ULMean.LicenseGroup +
VS.LC.ULMean.LicenseGroup.Shared)/(VS.LC.ULCreditAvailable.LicenseGroup.Dedicated
+ VS.LC.ULCreditAvailable.Shared)
NodeB_DL_CE_MEAN_RATIO = (VS.LC.DLMean.LicenseGroup +
VS.LC.DLMean.LicenseGroup.Shared)/(VS.LC.DLCreditAvailable.LicenseGroup.Dedicated
+ VS.LC.DLCreditAvailable.Shared)
where
VS.LC.ULCreditAvailable.LicenseGroup.Dedicated + VS.LC.ULCreditAvailable.Shared:
indicates the total number of available uplink CEs in a license group.
VS.LC.DLCreditAvailable.LicenseGroup.Dedicated + VS.LC.DLCreditAvailable.Shared:
indicates the total number of available downlink CEs in a license group.
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
OVSF_Utilization = VS.RAB.SFOccupy/256
DCH_OVSF_Utilization = DCH_OVSF_CODE/256
Issue 01 (2012-04-30)
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
10
RAN14.0
Capacity Monitoring Guide
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.
where
Number of session setup or release times (per second): 500 for a single-core interface
board (1000 for the GOUa and FG2a) and 3000 for a multi-core interface board.
It is recommended that you expand the interface board capacity if the mean CPU usage (for
forwarding load or session load) is higher than 60% for three consecutive days in one week.
Issue 01 (2012-04-30)
11
RAN14.0
Capacity Monitoring Guide
An FACH is used to transport user signaling and a small amount of user data to a UE that is in
CELL_FACH state.
Common channel analysis needs to be conducted based on monitoring of both PCHs and
FACHs. 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:
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.
Issue 01 (2012-04-30)
12
RAN14.0
Capacity Monitoring Guide
If the WMPT is overloaded, a radio link fails to be set up or no response to a radio link setup
request is received. This decreases KPIs, such as success ratios of RRC and RAB setup. For
Huawei NodeBs, control NBAP (CNBAP) is used to assess the WMPT processing capacity.
CNBAP usage
where
If the CNBAP usage is higher than 60% in the busy hour for three consecutive days in one
week, the WMPT is becoming overloaded. Add a baseband board or an extension
transmission board, or split the NodeB.
Issue 01 (2012-04-30)
13
RAN14.0
Capacity Monitoring Guide
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
Issue 01 (2012-04-30)
14
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
15
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
16
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
17
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
18
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
19
RAN14.0
Capacity Monitoring Guide
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 >
Issue 01 (2012-04-30)
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
20
RAN14.0
Capacity Monitoring Guide
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
Issue 01 (2012-04-30)
21
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
22
RAN14.0
Capacity Monitoring Guide
UE Type
Solution
No signaling connection
release indication (SCRI)
Nokia, Samsung, or
Motorola feature phones
iPhone (R6)
Issue 01 (2012-04-30)
23
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
24
RAN14.0
Capacity Monitoring Guide
Number of Consumed
CEs on the Uplink
Number of Consumed
CEs on the Downlink
CS 64 kbit/s
PS 64 kbit/s
PS 128 kbit/s
PS 144 kbit/s
PS 384 kbit/s
10
SF32 (HSUPA)
N/A
SF16 (HSUPA)
N/A
SF8 (HSUPA)
N/A
SF4 (HSUPA)
N/A
2xSF4 (HSUPA)
16
N/A
2xSF2 (HSUPA)
32
N/A
Issue 01 (2012-04-30)
25
RAN14.0
Capacity Monitoring Guide
Service Type
Number of Consumed
CEs on the Uplink
Number of Consumed
CEs on the Downlink
2xSF2+2xSF4 (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.
Issue 01 (2012-04-30)
26
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
27
RAN14.0
Capacity Monitoring Guide
Thresholds for the preceding code congestion-related operations must be set based on
operators' requirements for services quality.
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.
Issue 01 (2012-04-30)
28
RAN14.0
Capacity Monitoring Guide
Issue 01 (2012-04-30)
29
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
30
RAN14.0
Capacity Monitoring Guide
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.
Issue 01 (2012-04-30)
31
RAN14.0
Capacity Monitoring Guide
If the DPU DSP or interface board CPU usage is higher than 60%, add DPU boards or
interface boards.
Issue 01 (2012-04-30)
32
RAN14.0
Capacity Monitoring Guide
Issue 01 (2012-04-30)
33
RAN14.0
Capacity Monitoring Guide
Issue 01 (2012-04-30)
34
RAN14.0
Capacity Monitoring Guide
5 Counter Definitions
5
Counter Name
Counter Definitions
Counter
Definition
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
Congestion
Counter
Issue 01 (2012-04-30)
35
RAN14.0
Capacity Monitoring Guide
5 Counter Definitions
Counter Name
Counter
Definition
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>)
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
NODEB_Throughput (custom)
NODEB_Throughput/NODEB_Trans_Cap
Usage Counter
Power Usage
Counter
IUB Usage
Counters
IUB BW usage
NODEB_Trans_Cap (custom)
NODEB_Trans_
Cap
VS.IPDLTotal.1
VS.IPDLTotal.2
(VS.IPDLTotal.1 + VS.IPDLTotal.2 +
VS.IPDLTotal.3 + VS.IPDLTotal.4)
VS.IPDLTotal.3
VS.IPDLTotal.4
NODEB_Throug
hput
NODEB_Throughput_DL (custom)
NODEB_Throug
hput_DL
VS.IPDLAvgUsed.1
NODEB_Throughput_UL (custom)
VS.IPDLAvgUsed.2
MAX(NODEB_Throughput_DL,
NODEB_Throughput_UL)
(VS.IPDLAvgUsed.1 + VS.IPDLAvgUsed.2 +
VS.IPDLAvgUsed.3 + VS.IPDLAvgUsed.4)
VS.IPDLAvgUsed.3
VS.IPDLAvgUsed.4
NODEB_Throug
hput_UL
VS.IPULAvgUsed.1
VS.IPULAvgUsed.2
(VS.IPULAvgUsed.1 + VS.IPULAvgUsed.2 +
VS.IPULAvgUsed.3 + VS.IPULAvgUsed.4)
VS.IPULAvgUsed.3
VS.IPULAvgUsed.4
Issue 01 (2012-04-30)
36
RAN14.0
Capacity Monitoring Guide
Counter Name
5 Counter Definitions
Counter
Definition
PCH usage
VS.UTRAN.AttPaging1
VS.UTRAN.AttPaging1/(60 x 60 x 5/0.01)
FACH usage
VS.CRNCIubBytesFACH.Tx
PCH/FACH
Usage Counter
VS.PCH.Bandwidth.UsageRate
VS.RAB.SFOccupy
VS.RAB.SFOccupy
OVSF usability
ratio
VS.RAB.SFOccupy.Ratio
VS.RAB.SFOccupy/256
DCH_OVSF_Utilization
[(<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>)]/256
SPU usage
VS.XPU.CPULOAD.MEAN
VS.XPU.CPULOAD.MEAN
DPU usage
VS.DSP.UsageAvg
VS.DSP.UsageAvg
INT usage
VS.INT.CPULOAD.MEAN
VS.INT.CPULOAD.MEAN
VS.INT.TRANSLOAD.RATIO.MEA
N
VS.INT.TRANSLOAD.RATIO.MEAN
VS.BRD.CPULOAD.MEAN
VS.BRD.CPULOAD.MEAN
CPU Usage
Counter
NodeB CPU
usage
Issue 01 (2012-04-30)
37
RAN14.0
Capacity Monitoring Guide
Counter Name
5 Counter Definitions
Counter
Definition
UL_CE_MEAN
_RATIO
VS.LC.ULMean.LicenseGroup
UL_CE_MEAN
_REMAIN
VS.LC.ULCreditAvailable.LicenseGro
up.Dedicated
(VS.LC.ULMean.LicenseGroup +
VS.LC.ULMean.LicenseGroup.Shared)/(VS.LC.
ULCreditAvailable.LicenseGroup.Dedicated +
VS.LC.ULCreditAvailable.Shared)
Credit Usage
Counter
VS.LC.ULMean.LicenseGroup.Shared
VS.LC.ULCreditAvailable.Shared
UL_CE_MAX_
RATIO
UL_CE_MAX_
REMAIN
VS.LC.ULMax.LicenseGroup
VS.LC.ULMax.LicenseGroup.Shared
VS.LC.ULCreditAvailable.LicenseGroup.Dedica
ted + VS.LC.ULCreditAvailable.Shared VS.LC.ULMean.LicenseGroup VS.LC.ULMean.LicenseGroup.Shared
VS.LC.ULMax.LicenseGroup
VS.LC.ULMax.LicenseGroup.Shared
(VS.LC.ULMax.LicenseGroup +
VS.LC.ULMax.LicenseGroup.Shared)/(VS.LC.U
LCreditAvailable.LicenseGroup.Dedicated +
VS.LC.ULCreditAvailable.Shared)
VS.LC.ULCreditAvailable.LicenseGroup.Dedica
ted + VS.LC.ULCreditAvailable.Shared VS.LC.ULMax.LicenseGroup VS.LC.ULMax.LicenseGroup.Shared
DL_CE_MEAN
_RATIO
DL_CE_MEAN
_REMAIN
VS.LC.DLMean.LicenseGroup
VS.LC.DLMean.LicenseGroup.Shared
VS.LC.DLCreditAvailable.LicenseGro
up.Dedicated
VS.LC.DLCreditAvailable.Shared
DL_CE_MAX_
RATIO
DL_CE_MAX_
REMAIN
VS.LC.DLMax.LicenseGroup
VS.LC.DLMax.LicenseGroup.Shared
(VS.LC.DLMean.LicenseGroup +
VS.LC.DLMean.LicenseGroup.Shared)/(VS.LC.
DLCreditAvailable.LicenseGroup.Dedicated +
VS.LC.DLCreditAvailable.Shared)
VS.LC.ULCreditAvailable.LicenseGroup.Dedica
ted + VS.LC.ULCreditAvailable.Shared VS.LC.ULMean.LicenseGroup VS.LC.ULMean.LicenseGroup.Shared
VS.LC.DLMax.LicenseGroup
VS.LC.DLMax.LicenseGroup.Shared
VS.CE.ULMean.UlGroup
VS.CE.ULAvailable.UlGroup
ULGROUP_CE_
MEAN_Ratio
(VS.LC.DLMax.LicenseGroup +
VS.LC.DLMax.LicenseGroup.Shared)/(VS.LC.D
LCreditAvailable.LicenseGroup.Dedicated +
VS.LC.DLCreditAvailable.Shared)
VS.LC.DLCreditAvailable.LicenseGroup.Dedica
ted + VS.LC.DLCreditAvailable.Shared VS.LC.DLMax.LicenseGroup VS.LC.DLMax.LicenseGroup.Shared
VS.CE.ULMean.UlGroup/VS.CE.ULAvailable.
UlGroup
Issue 01 (2012-04-30)
38