Capacity Monitoring Guide: Issue 01 Date 2016-03-07
Capacity Monitoring Guide: Issue 01 Date 2016-03-07
Issue 01
Date 2016-03-07
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.
Website: http://www.huawei.com
Email: [email protected]
Purpose
Growing traffic in mobile networks requires more and more resources. Lack of resources will
affect user experience. This document provides guidelines on LTE FDD and LTE TDD
capacity monitoring including details on how to identify resource allocation problem and on
how to monitor network resource usage. Capacity monitoring provides data reference for
network reconfiguration and capacity expansion and enables maintenance personnel to take
measures before resources insufficiency affects network QoS and user experience.
NOTE
The main control, transmission, and baseband processing units are deployed on the same board and share the
CPU for BTS3202E, BTS3203E and BTS3911E. The main control board and baseband board in this
document are boards in BTS3202E, BTS3203E and BTS3911E. The CPU usage of the main control board is
the CPU usage of boards in BTS3202E, BTS3203E and BTS3911E.
This document does not apply to scenarios where a large amount of traffic volume is involved. For guidance
in these scenarios, contact Huawei technical support.
The following table lists the eNodeB types and the corresponding eNodeB models.
eNodeB Types eNodeB Models
Product Version
The following table lists the product version related to this document.
BTS3900 l eRAN11.1
BTS3900A
BTS3900L
DBS3900
DBS3900
LampSite
BTS3202E
BTS3203E
BTS3911E
Intended Audience
This document is intended for:
l Field engineers
l Network planning engineers
Organization
1 Changes in eRAN Capacity Monitoring Guide
2 Overview
This section describes the types of network resources to be monitored and the method of
performing capacity monitoring.
This section describes how to identify resource congestion problems. Network exceptions can
be found through KPI monitoring. If a KPI deteriorates, users can analyze relevant access
counters to decide whether the deterioration is caused by resource congestion.
6 Related Counters
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
General Conventions
The general conventions that may be found in this document are defined as follows.
Convention Description
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Convention Description
Keyboard Operations
The keyboard operations that may be found in this document are defined as follows.
Format Description
Key Press the key. For example, press Enter and press Tab.
Key 1+Key 2 Press the keys concurrently. For example, pressing Ctrl
+Alt+A means the three keys should be pressed
concurrently.
Key 1, Key 2 Press the keys in turn. For example, pressing Alt, A means
the two keys should be pressed in turn.
Mouse Operations
The mouse operations that may be found in this document are defined as follows.
Action Description
Drag Press and hold the primary mouse button and move the
pointer to a certain position.
Contents
6 Related Counters......................................................................................................................... 40
01 (2016-03-07)
This is the first official release.
Compared with issue Draft A (2015-12-30), this issue does not include any change.
Draft A (2015-12-30)
This is a draft.
Compared with issue 02 (2015-06-20) of V100R010C10, this issue does not include any new
information or changed any issues.
Compared with issue 02 (2015-06-20) of V100R010C10, this issue deleted the following
issues:
l Transport Resource Group Bandwidth Usage.
l Ethernet Port Bandwidth Usage.
2 Overview
This section describes the types of network resources to be monitored and the method of
performing capacity monitoring.
Table 2-1 describes the types of network resources to be monitored and impacts of resource
insufficiency on the system.
Table 2-2 describes the types of network resources to be monitored and impacts of resource
insufficiency on the system.
1. Thresholds defined for resource monitoring are generally lower than those triggering alarms so that risks
of resource insufficiency can be detected as early as possible.
2. Thresholds given in this document apply to networks experiencing a steady growth. Thresholds are
determined based on product specifications and experiences in working with existing networks. For
example, the CPU usage threshold 60% is specified based on the CPU flow control threshold 80%. The
eNodeB's RRC connected user license usage threshold 60% is specified based on the peak-to-average
ratio (about 1.5:1). When the average usage reaches 60%, the peak usage approaches 100%. Threshold
determining considers both average and peak values.
3. When a network's load increases abruptly and even exceeds product specifications, you can determine
whether to perform a capacity expansion and take capacity expansion actions by referrring to the methods
provided in this document. (The methods described in this document apply to steadily growning
networks.) Alternatively, you can tailor a new scheme based on the operator's understanding of network
operation quality. For example, a capacity expansion can be triggered as long as a network is overloaded.
4. Telecom operators are encouraged to formulate an optimization solution for resource capacity based on
prediction and analysis for networks that are experiencing fast development, scheduled to deploy new
services, or about to employ new charging plans. If you require services related to resource capacity
optimization, such as prediction, evaluation, optimization, reconfiguration, and capacity expansion,
contact Huawei technical support.
3.1 Overview
This section describes monitoring principles and methods, as well as related counters, of all
types of service resources. Information about how to locate resource bottlenecks and the
related handling suggestions are also provided. Note that resource insufficiency may be
determined by usage of more than one type of service resource. For example, a resource
bottleneck can be claimed only when both RRC connected user license usage and main-
control-board CPU usage exceed the predefined thresholds.
3.2 Downlink User Perception
3.3 User Capacity Usage
3.4 PRACH Performance
3.5 PDCCH Resource Usage
3.6 Throughput License Usage
3.7 Paging Resource Usage
3.8 Main-Control-Board CPU Usage
3.9 Baseband-Processing-Unit CPU Usage
3.1 Overview
This section describes monitoring principles and methods, as well as related counters, of all
types of service resources. Information about how to locate resource bottlenecks and the
related handling suggestions are also provided. Note that resource insufficiency may be
determined by usage of more than one type of service resource. For example, a resource
bottleneck can be claimed only when both RRC connected user license usage and main-
control-board CPU usage exceed the predefined thresholds.
NOTE
For accurate monitoring, all resources must be monitored during busy hours. It is recommended that busy
hours be defined as a period when the system or a cell is undergoing the maximum resource consumption of a
day.
Table 3-2 Thresholds and handling suggestions for the resources to be monitored
Res Resource Conditions Handling Suggestions
ourc Monitoring
e Item
Typ
e
3.5 PDCCH CCE usage PDCCH Add carriers, split cells, or optimize
Resource ≥ 80% Symbol RF performance.
Usage Number
Adjust
Switchis set to
OFF(Off).
PDCCH
Symbol
Number
Adjust
Switchis set to
ON(On), and
uplink or
downlink PRB
usage reaches
or exceeds
70%.
Monitoring Principles
Growing traffic leads to a continuous increase in PRB usage, and UE rates decrease as an
increasing number of UEs share the limited PRBs. The PRB usage reflects the degree of
bandwidth usage over the air interface while the perceived-rate reflects user experience.
Monitoring the two items together can reflect user experience under a certain bandwidth
usage over the air interface.
As downlink is a major concern in an LTE network, this document describes only how to
monitor the user-perceived downlink rate.
NOTE
The monitoring principles also apply to uplink.
Monitoring Methods
The following items are used in monitoring this case:
Suggested Measures
If the downlink PRB usage reaches or exceeds 70% and the downlink user-perceived rate is
smaller than a user-defined threshold (3 Mbit/s by default) for X days (three days by default)
in a week:
l If the average CQI of the cell is lower than the threshold (7 by default), you are advised
to increase the cell throughput by optimizing RF performance.
l If the average CQI of the cell is higher than the threshold, you are advised to:
– Add carriers or expand the bandwidth of the existing carrier.
– Add eNodeBs.
In the preceding formula, L.ChMeas.CQI.DL.Y indicates the number of wideband CQI reports
with the value of Y.
Monitoring Principles
User capacity usage can be evaluated by the following three items:
l Synchronized user capacity usage of a cell
l RRC connected user capacity usage of a board
l RRC connected user license usage of an eNodeB
An RRC connected user in the LTE is one who is in the RRC_Connected state, and a
synchronized user is an RRC connected user in the synchronization state. When the number of
users processed within a cell or by a board exceeds the maximum number defined in the
product specifications, network KPIs deteriorate. When the number of users processed by an
eNodeB exceeds the maximum number defined in the license, user admission failures.
NOTE
When the number of users reaches or exceeds the preconfigured threshold, the user-perceived rate has already
decreased to an unacceptable level. Therefore, the user-perceived rate should be considered first. The number
of users should be considered first when capacity takes priority over user experience.
Monitoring Methods
l Synchronized user capacity usage of a cell
The calculation formula is as follows:
Synchronized user capacity usage of a cell = L.Traffic.User.Ulsync.Avg / Maximum
number of synchronized users in a cell x 100%
where
– L.Traffic.User.Ulsync.Avg indicates the average number of uplink synchronized
users in a cell.
– To learn the maximum number of synchronized users in a cell, see Technical
Specifications of the eNodeB FDD in 3900 Series Base Station Technical
Description.
The maximum number of synchronized users is 200 for BTS3202E, BTS3203E and
BTS3911E LTE.
l RRC connected user capacity usage of a board
The RRC connected user capacity usage of a board involves the baseband processing
unit (BBP) and the main control board. The calculation formula is as follows:
RRC connected user capacity usage of a board = ∑(L.Traffic.User.Avg) / Maximum
number of RRC connected users of a board x 100%
where
– ∑(L.Traffic.User.Avg) indicates the total number of RRC connected users in all
cells served by a board.
– To learn the maximum number of RRC connected users of a BBP or main control
board, see Technical Specifications of the eNodeB FDD in 3900 Series Base Station
Technical Description.
l RRC connected user license usage of an eNodeB
The calculation formula is as follows:
RRC connected user license usage of an eNodeB = ∑(L.Traffic.User.Avg) / Number of
licensed RRC connected users of an eNodeB x 100%
where
– ∑(L.Traffic.User.Avg) indicates the total number of RRC connected users in all
cells served by an eNodeB.
– The method of querying the licensed number of RRC connected users is as follows:
Run the command DSP LICINFO: FUNCTIONTYPE=eNodeB;. In the displayed
command output, view the line in which Model is LT1S0ACTUS00. The value in
the Allocated column is the number of licensed RRC connected users.
Suggested Measures
l If the synchronized user capacity usage of a cell reaches or exceeds 60% for X days
(three days by default) in a week, you are advised to take either of the following
measures:
– Release UEs in idle mode as early as possible: Reduce the UE inactivity timer
length by running the MOD RRCCONNSTATETIMER command with the
UeInactiveTimer parameter specified. This measure lifts signaling overhead and
increases CPU usage.
– Transfer UEs out of the local cell: If a neighboring cell is lightly loaded, adjust the
antenna downtilt angle or decrease the transmit power of the local cell to shrink the
coverage area and reduce the number of users in the local cell. In addition, expand
the coverage area of the neighboring cell for load balancing.
– Add cells or expand the local cell bandwidth.
– Split the local cell into multiple cells.
l If the RRC connected user capacity usage of a main control board reaches or exceeds
60% for X days (three days by default) in a week, you are advised to take measures
given in 3.8 Main-Control-Board CPU Usage.
l If the RRC connected user capacity usage of a BBP reaches or exceeds 60% for X days
(three days by default) in a week, you are advised to take measures given in 3.9
Baseband-Processing-Unit CPU Usage.
l If the RRC connected user license usage of an eNodeB reaches or exceeds 60% for X
days (three days by default) in a week, you are advised to determine the main-control-
board CPU usage first by referring to 3.8 Main-Control-Board CPU Usage:
– If the main-control-board CPU usage is less than 60%, you are advised to expand
the capacity defined in the license.
– If the main-control-board CPU usage reaches or exceeds 60%, you are advised to
add eNodeBs.
Monitoring Principles
The physical random access channel (PRACH) transmits preambles during random access
procedures. Preamble is classified into contention preamble and non-contention preamble.
Contention preambles are used in the following scenarios: initial connection establishment,
reestablishment, handover, downlink data transmission for UEs in the out-of-synchronization
state, and uplink data transmission for UEs in the out-of-synchronization state. Non-
contention preambles are used in two scenarios: handover and downlink data transmission for
UEs in the out-of-synchronization state. Therefore, PRACH performance can be measured
using the following factors:
l Conflict probability for contention-based preambles: The more frequently the
contention-based access is performed, the higher probability that the preambles are
conflicted. When the conflict probability reaches a certain extent, the access delay
increases, severely affecting user experience.
l Assignment success rate for dedicated preambles: The assignment success rate for
dedicated preambles decreases with the increase of non-contention-based accesses.
When the success rate decreases to a certain extent, the handover delay increases,
affecting user experience.
Monitoring Methods
l Conflict probability for contention-based preambles =
L.RA.UeRaInfoRspWithCon.Num / L.RA.UeRaInfoRsp.Num x 100%
NOTE
Values of the counter in the formula takes effect only when the UeRaInforInqSwitch is set to on
and there are UEs supporting 3GPP Release 9 and later on the network. You can query the value of
the UeRaInforInqSwitch by running the LST CELLALGOSWITCH: LocalCellId=xxx;
command.
l Assignment success rate for dedicated preambles =
L.RA.Dedicate.PreambleAssign.Num / L.RA.Dedicate.PreambleReq.Num x 100%
where
l L.RA.UeRaInfoRspWithCon.Num indicates number of times the
UEInformationResponse message in which contentionDetected IE value is TRUE is
received, that is, the number of times the conflicting UEInformationResponse message is
received.
l L.RA.UeRaInfoRsp.Num indicates the number of times the UEInformationResponse
message containing RACH information is received.
l L.RA.Dedicate.PreambleAssign.Num indicates the number of times the non-connection-
based preambles are assigned.
l L.RA.Dedicate.PreambleReq.Num indicates the number of times the non-contention-
based preamble is requested.
Suggested Measures
l If the conflict probability for contention-based preambles reaches or exceeds 5% for
X days (three days by default) in a week, enable the RACH adjustment algorithm by
running the command MOD CELLALGOSWITCH: LocalCellId=x,
RachAlgoSwitch=RachAdjSwitch-1.
l If the assignment success rate for dedicated preambles is less than 99% for X days
(three days by default) in a week, enable the RACH resource adjustment algorithm and
reuse of dedicated PRACH preambles between UEs by running the command MOD
CELLALGOSWITCH: LocalCellId=x, RachAlgoSwitch=RachAdjSwitch-1,
RachAlgoSwitch=MaksIdxSwitch-1;.
Monitoring Principles
This capacity indicator measures the number of control channel elements (CCEs) that can be
used by the PDCCH. If the CCE usage is excessively high, CCEs may fail to be allocated to
the new UEs to be scheduled, which will result in a long service delay and unsatisfactory user
experience.
Monitoring Methods
The following item is used in monitoring this case:
where
3 MHz 1/6 2 7 12
1/2 2 7 12
1 2 7 12
2 1 6 11
5 MHz 1/6 4 13 21
1/2 4 12 21
1 3 12 20
2 2 11 19
10 MHz 1/6 10 26 43
1/2 9 26 42
1 8 25 41
2 6 23 39
15 MHz 1/6 15 40 65
1/2 14 39 64
1 12 37 62
2 9 34 59
20 MHz 1/6 20 54 87
1/2 19 52 86
1 17 50 84
2 13 46 80
l The number of PDCCH symbols depends on the PDCCH Symbol Number Adjust
Switch parameter value, which can be queried by running the LST
CELLPDCCHALGO command.
– If the parameter value is On, the number of PDCCH symbols is 3.
– If the parameter value is Off, the number of PDCCH symbols is equal to the
PDCCH Initial Symbol Number parameter value.
l The value of Ng is equal to the PHICH resource parameter value, which can be queried
by running the LST PHICHCFG command.
Suggested Measures
If the CCE usage during busy hours reaches or exceeds 80% for X days (three days by
default) in a week, perform the following operations:
l If the PDCCH Symbol Number Adjust Switch parameter value is Off, you are advised
to set this parameter to On by running the command MOD CELLPDCCHALGO:
LocalCellId=x, PdcchSymNumSwitch=ON;.
l If the PDCCH Symbol Number Adjust Switch parameter value is On, you are advised
to:
– Add cells or split existing cells.
– Optimize RF performance to reduce the interference to PDCCH from neighboring
cells.
Monitoring Principles
When the eNodeB throughput reaches or exceeds the licensed throughput, user perception and
customer income are affected.
Monitoring Methods
The following item is used in monitoring this case:
Throughput license usage of an eNodeB = ∑(L.Thrp.bits.UL.PDCP.SDU + L.Thrp.bits.DL) /
(Licensed eNodeB throughput x measurement period (in the unit of second)) x 100%
where
l L.Thrp.bits.UL.PDCP.SDU and L.Thrp.bits.DL the uplink traffic volume and downlink
traffic volume of a cell, respectively. ∑(L.Thrp.bits.UL.PDCP.SDU + L.Thrp.bits.DL)
indicates the sum of uplink and downlink throughput of all cells served by an eNodeB.
l The method of querying the licensed eNodeB throughput is as follows:
Run the command DSP LICINFO: FUNCTIONTYPE=eNodeB;. In the displayed
command output, view the line in which Model is LT1S0ACTUS00. The value in the
Allocated column is the licensed throughput of the eNodeB.
Suggested Measures
If the eNodeB throughput license usage reaches or exceeds 80% for X days (three days by
default) in a week, you are advised to increase the licensed throughput.
Monitoring Principles
Paging messages are sent over the S1 interface. Therefore, paging resource usage can be
evaluated by the percentage of paging messages received on the S1 interface. If the number of
paging times exceeds the maximum, the paging messages sent from the eNodeB to UEs may
be discarded, resulting in a decreased call success rate.
On the eNodeB side, paging messages received by the main control board over the S1
interface will be finally sent over the air interface through the baseband processing unit
(BBP). If all the cells served by an BBU belong to the same tracking area identified by the
tracking area code (TAC), all the paging messages received by the main control board need to
be sent out through each BBP. Whether the paging messages can be sent out through the BBP
depends on the overall paging capability of the BBP.
The overall paging capability of the BBU is determined by the smaller specification between
the main control board and BBP. The specifications of the main control board and BBP are as
follows:
l UMPT/LBBPd3/UBBPd: 2400 messages/second.
l LMPT/LBBPc/LBBPd1/LBBPd2: 1800 messages/second.
The eNodeBs BTS3202E, BTS3203E and BTS3911E can send a maximum of 500 paging
messages per second.
Monitoring Methods
The paging resource usage is evaluated by the percentage of paging messages received on the
S1 interface. The calculation formula is as follows:
In the preceding formula, L.Paging.S1.Rx indicates the number of paging messages received
over the S1 interface.
Suggested Measures
If the percentage of paging messages received on the S1 interface reaches or exceeds 60%
for X days (three days by default) in a week, you are advised to take either of the following
measures:
l Decrease the number of cells in the tracking area list (TAL) that the congested cell
belongs to.
l Adjust the paging policy of the core network. That is, reduce the number of paging
messages sent after the first or second paging failures to reduce signaling overhead.
l Enable the precise paging function if the core network is deployed by Huawei.
Monitoring Principles
The CPU usage of the main control board becomes high occasionally due to some reasons.
However, the occasional high CPU usage is not necessarily the basis for capacity expansion.
Therefore, the main-control-board CPU usage is jointly evaluated by the average main-
control-board CPU usage and the percentage of times that the main-control-board CPU usage
reaches or exceeds a preconfigured threshold (85%).
The main-control-board CPU usage reflects the busy level of the eNodeB. If the main-control-
board CPUs are busy processing control plane or user plane data, signaling-related KPIs may
deteriorate, and UEs may experience a low access success rate, low E-RAB setup success
rate, or high service drop rate.
Monitoring Methods
The main-control-board CPU usage is evaluated by the average CPU usage and the percent of
times that the main-control-board CPU usage reaches or exceeds a preconfigured threshold
(85%).
l Average CPU usage: VS.BBUBoard.CPULoad.Mean
l Percentage of times that the main-control-board CPU usage reaches or exceeds a
preconfigured threshold (85%) = VS.BBUBoard.CPULoad.CumulativeHighloadCount /
Measurement period (in the unit of second) x 100%
where, VS.BBUBoard.CPULoad.CumulativeHighloadCount indicates the number of times
that the CPU usage of the board exceeds a preconfigured threshold.
Suggested Measures
The main-control-board CPU of a local eNodeB becomes overloaded if either of the following
conditions is met for X days (three days by default) in a week:
l VS.BBUBoard.CPULoad.Mean reaches or exceeds 60%.
l The percentage of times that the main-control-board CPU usage reaches or exceeds
85% is greater than or equal to 5%.
Take one of the following measures:
1. Transfer UEs from the local eNodeB: If a neighboring eNodeB is lightly loaded, adjust
the antenna downtilt angles or decrease the transmit power of the local eNodeB to shrink
the coverage area and reduce the CPU load of the local eNodeB. In addition, expand the
coverage area of the neighboring eNodeB for load balancing.
2. Replace the main control board with a UMPT: If the main control board is an LMPT,
replace it with a UMPT. This measure can not be used in BTS3202E, BTS3203E and
BTS3911E.
3. Add eNodeBs.
Monitoring Principles
The CPU usage of the baseband processing unit (BBP) becomes high occasionally due to
some reasons. However, the occasional high CPU usage is not necessarily the basis for
capacity expansion. Therefore, the BBP CPU usage is jointly evaluated by the average BBP
CPU usage and the percentage of times that the BBP CPU usage reaches or exceeds a
preconfigured threshold (85%).
This capacity indicator measures the BBP CPU usage. If the eNodeB receives too much
traffic, the BBP CPU responsible for user plane processing will be heavily loaded. As a result,
the eNodeB will experience a low RRC setup success rate, low E-RAB setup success rate,
low handover success rate, and high service drop rate.
Monitoring Methods
Based on the type of data processed by the BBP, the BBP CPU usage is classified into
control-plane CPU usage and user-plane CPU usage. The BBP CPU usage is jointly evaluated
by the average BBP CPU usage and the percentage of times that the BBP CPU usage reaches
or exceeds a preconfigured threshold (85%). The involved indicators are described as follows:
Control-plane CPU usage
l Average control-plane CPU usage: VS.BBUBoard.CPULoad.Mean
l Percentage of times that the control-plane CPU usage reaches or exceeds a preconfigured
threshold (85%) = VS.BBUBoard.CPULoad.CumulativeHighloadCount / Measurement
period (in the unit of second) x 100%
where, VS.BBUBoard.CPULoad.CumulativeHighloadCount indicates the number of times
that the control-plane CPU usage of the board exceeds a preconfigured threshold.
User-plane CPU usage
l Average user-plane CPU usage: L.Traffic.Board.UPlane.CPULoad.AVG
l Percentage of times that the user-plane CPU usage reaches or exceeds a preconfigured
threshold (85%) = L.Traffic.Board.UPlane.CPULoad.CumulativeHighloadCount /
Measurement period (in the unit of second) x 100%
where, L.Traffic.Board.UPlane.CPULoad.CumulativeHighloadCount indicates the number of
times that the user-plane CPU usage of the board exceeds a preconfigured threshold.
Suggested Measures
The BBP CPU of a local eNodeB becomes overloaded if either of the following conditions is
met for X days (three days by default) in a week:
l VS.BBUBoard.CPULoad.Mean reaches or exceeds 60%.
l The percentage of times that the BBP CPU usage reaches or exceeds 85% is greater
than or equal to 5%.
When the BBP CPU usage is high, you are advised to perform capacity expansion as follows:
1. Migrate cells in the eNodeB. If the eNodeB has multiple BBPs and one of them is
overloaded, move cells from the overloaded BBP to a BBP with a lighter load.
The BBP load can be indicated by the average CPU usage, the percentage of times that
the CPU usage reaches or exceeds a preconfigured threshold, or the number of cells
established on a BBP.
2. Replace a BBP with low specifications with one with high specifications. For example, if
the BBP is an LBBPc, replace the LBBPc with an LBBPd or a UBBP. If the BBP is an
LBBPd, replace the LBBPd with a UBBP.
3. Add a BBP. If the eNodeB has vacant slots, add a BBP and migrate existing cells to the
new BBP for load sharing.
4. Add eNodeBs. Add an eNodeB for capacity expansion if the number of BBP boards has
reached the maximum value that can be added.To expand the capacity of a BTS3202E or
BTS3911E, you can only add another BTS3202E, BTS3203E or BTS3911E.
4.1 Introduction
This section describes principles and methods, as well as related counters, for monitoring each
type of resources. Information about how to identify resource insufficiency and the related
handling suggestions are also provided. Resource insufficiency may be determined jointly by
more than one indicator. For example, a resource insufficiency problem can be claimed only
when both RRC Connected User License Utility Ratio and CPU load Avg of MPT(%) exceed
the predefined thresholds.
4.2 User Throughput
4.3 RRC Connected User
4.4 PRACH Resource Usage
4.5 CCE Utilization Rate
4.6 RRC Connected User License Utility Ratio
4.7 Traffic Volume License Utility Ratio
4.8 Paging Resource Utility Ratio
4.9 CPU load Avg of MPT(%)
4.10 CPU load Avg of BBP(%)
4.1 Introduction
This section describes principles and methods, as well as related counters, for monitoring each
type of resources. Information about how to identify resource insufficiency and the related
handling suggestions are also provided. Resource insufficiency may be determined jointly by
more than one indicator. For example, a resource insufficiency problem can be claimed only
when both RRC Connected User License Utility Ratio and CPU load Avg of MPT(%) exceed
the predefined thresholds.
NOTE
For accurate monitoring, busy hours must be determined. It is recommended that busy hours be defined
as a period when the system or a cell is undergoing the maximum resource consumption during a day.
The following table describes the thresholds and handling suggestions for the resources to be
monitored.
Table 4-1 Thresholds and handling suggestions for the resources to be monitored
Resource Resource Criteria for Determining Handling
Type Monitoring Resource Insufficiency Suggestion
Indicator
Uplink or Expand
downlink PRB capacity, add
usage ≥ 50% carriers, or split
cells.
eNodeB RRC Connected RRC Connected CPU load Avg Increase the
resources User License User License of MPT(%) < licensed
Utility Ratio Utility Ratio ≥ 60% number of
60% RRC_CONNE
CTED users.
Monitoring Methods
Uplink and downlink user perception are evaluated based on the uplink and downlink PRB
usages and user-perceived rates, which are calculated using the following formulas:
Suggested Measures
If the downlink PRB usage is greater than or equal to 30% and a user-perceived rate is smaller
than the user rate threshold (which is customized and set to 5 Mbit/s by default):
l If the spectral efficiency in the cell is smaller than 1.3 bit/Hz, increase the throughput by
performing RF optimization or adding eNodeBs.
l If the spectral efficiency in the cell is greater than or equal to 1.3 bit/Hz:
– Add carriers or increase the carrier bandwidth.
– Add eNodeBs.
The downlink PRB usage threshold varies with the downlink user rate threshold, according to
the following chart. Eg: If the customer requires that the downlink user rate threshold be set to
2 Mbit/s, the downlink PRB usage threshold must be changed to 50%.
Table 4-3 Downlink PRB usage threshold varying with the downlink user rate threshold
Downlink User Rate Threshold Downlink PRB Usage Threshold
(Mbit/s)
1 60%
2 50%
3 43%
4 37%
5 30%
6 25%
7 20%
resources and therefore the number of synchronized users needs to be monitored. By default,
the number of synchronized users is approximately equal to the number of
RRC_CONNECTED users. Therefore, the number of RRC_CONNECTED users (instead of
synchronized users) is monitored.
When the number of RRC_CONNECTED users in a cell reaches or exceeds the preconfigured
threshold, the user-perceived rate has already decreased to an unacceptable level. Therefore, the user-
perceived rate should be preferentially considered. The number of RRC_CONNECTED users in a cell
can be preferentially considered when the capacity of a cell takes priority over user experience.
Monitoring Methods
l Synchronized user capacity usage of a cell
The calculation formula is as follows:
Synchronized user capacity usage of a cell = L.Traffic.User.Max/Synchronized user
capacity of a cell x 100%
where
L.Traffic.User.Max indicates the maximum number of uplink synchronized users in a
cell.
The following table lists the synchronized user capacity of a cell.
BBP Model Item Number of
Users
Supported
by a Single
Cell
where
– Σ(L.Traffic.User.Avg) indicates the total number of RRC_CONNECTED users in
all cells served by a board.
– The following table lists the RRC_CONNECTED user capacity of a board.
BBP Model Item Number of
Users Supported
by a Single Cell
Suggested Measures
If the synchronized user capacity usage of a cell exceeds 60%, take the following measures:
l Reduce the UE inactivity timer length by running the MOD
RRCCONNSTATETIMER command with the UeInactiveTimer parameter specified.
This measure increases the signaling overhead and CPU usage.
l If a neighboring cell is lightly loaded, adjust the antenna downtilt or decrease the
transmit power of the local cell to reduce the coverage area and to reduce the number of
users in the local cell, and expand the coverage area of the neighboring cell for load
sharing.
l Add carriers or increase the carrier bandwidth.
l Split the local cell into multiple cells.
Monitoring Methods
The PRACH resource usage is evaluated based on the usage of preambles for contention-
based or non-contention-based random access, which is calculated using the following
formulas:
l Usage of preambles for contention-based random access =
(L.RA.GrpA.Att + L.RA.GrpB.Att)/3600/N x 100%
l Usage of preambles for non-contention-based random access = L.RA.Dedicate.Att/
3600/100 x 100%
In the preceding formulas,
l L.RA.GrpA.Att indicates the number of times that the preamble in group A for
contention-based random access is received.
l L.RA.GrpB.Att indicates the number of times that the preamble in group B for
contention-based random access is received.
l L.RA.Dedicate.Att indicates the number of times that the preamble for non-contention-
based random access is received.
l The value of N is specified as follows:
– When the system bandwidth is 15 MHz or 20 MHz, the value of N is 100.
Suggested Measures
l When the usage of preambles for contention-based random access is greater than or
equal to 75% in X (configurable, 3 by default) days in a week, run the following
command to enable the PRACH backoff algorithm, which decreases the peak load and
average delay on the RACH:
MOD CELLALGOSWITCH: LocalCellId=x, RachAlgoSwitch=BackOffSwitch-1;
In this case, if the system bandwidth is 5 MHz or 10 MHz, run the following command
to enable the PRACH resource adjustment algorithm:
MOD CELLALGOSWITCH: LocalCellId=x, RachAlgoSwitch= RachAdjSwitch-1;
l When the usage of preambles for non-contention-based random access is greater than or
equal to 75% in X (configurable, 3 by default) days in a week, run the following
command to enable the PRACH resource adjustment algorithm and dedicated preamble
multiplexing algorithm, which reduce the probability that UEs use preambles for
contention-based random access and decrease the access delay for UEs:
MOD CELLALGOSWITCH: LocalCellId=x, RachAlgoSwitch= RachAdjSwitch-1,
RachAlgoSwitch=MaksIdxSwitch-1;
In each radio frame, the eNodeB allocates CCEs to UEs to be scheduled in the uplink and
downlink, and to other common control signaling. The number of CCEs for the PDCCH must
be properly configured and allocated to minimize the downlink control overhead as well as to
ensure satisfactory user-plane throughput.
If PDCCH symbols are insufficient, CCEs may fail to be allocated to UEs to be scheduled,
which will increase the scheduling delay and affect user experience. If the number of PDCCH
symbols is excessive (indicating that the PDCCH CCE usage is low), resources that can be
used by PDSCH decreases, which will decrease the spectral efficiency.
Monitoring Methods
The PDCCH resource usage is evaluated using the CCE Utilization Rate, which is calculated
using the following formula:
Suggested Measures
If CCE Utilization Rate is greater than 50%:
l If PDCCH symbol adaptation is disabled, run the following command to enable this
function:
MOD CELLPDCCHALGO:LocalCellId=x,PdcchSymNumSwitch=ON;
l If PDCCH symbol adaptation is enabled and the downlink or uplink PRB usage is
greater than 50%, expand capacity, add carrier, or split cells. Otherwise, perform RF
optimization to reduce interference from neighboring cells to the PDCCH.
Monitoring Methods
The RRC Connected User License Utility Ratio is calculated using the following formula:
RRC Connected User License Utility Ratio = ∑(L.Traffic.User.Avg)/Licensed number of
RRC_CONNECTED users x 100%
In the preceding formula:
l L.Traffic.User.Avg indicates the average number of users in a cell.
l ∑(L.Traffic.User.Avg) indicates the sum of the average number of RRC_CONNECTED
users in each cell under an eNodeB.
l The licensed number of RRC_CONNECTED users can be queried by running the
following command:
DSP LICENSE: FUNCTIONTYPE=eNodeB;
In the command output, the value in the Allocated column corresponding
to LLT1ACTU01 is the licensed number of RRC_CONNECTED users.
Suggested Measures
In addition to this indicator, also consider CPU load Avg of MPT(%) for capacity expansion.
If the RRC Connected User License Utility Ratio reaches or exceeds 60% in X (configurable,
3 by default) days in a week, you are advised to take the following measures:
l If CPUload Avg of MPT(%) is less than 60%, increase the licensed number of
RRC_CONNECTED users.
Monitoring Methods
The Traffic Volume License Utility Ratio is calculated using the following formula:
Traffic Volume License Utility Ratio = ∑(L.Thrp.bits.UL + L.Thrp.bits.DL)/(Licensed
eNodeB throughput volume x 3600) x 100%
In the preceding formula,
l The related counters are described as follows:
– L.Thrp.bits.UL and L.Thrp.bits.DL indicate the uplink throughput volume and
downlink throughput volume of a cell, respectively.
– ∑(L.Thrp.bits.UL + L.Thrp.bits.DL) indicates the sum of uplink and downlink
traffic volumes of all cells under an eNodeB.
l The licensed eNodeB traffic volume can be queried by running the following command:
DSP LICENSE: FUNCTIONTYPE=eNodeB;
In the command output, the value in the Allocated column corresponding
to LLT1THRUL01 is the licensed eNodeB traffic volume.
Suggested Measures
If the Traffic Volume License Utility Ratio in busy hours reaches or exceeds 80% in X
(configurable, 3 by default) days in a week, increase the licensed eNodeB traffic volume.
Monitoring Methods
The Paging Resource Utility Ratio is evaluated by the value of L.Paging.Dis.Num and the
percentage of paging messages received on the S1 interface, which is calculated using the
following formula:
Percentage of paging messages received on the S1 interface = L.Paging.S1.Rx/3600/
Maximum number of paging messages that can be sent per second x 100%
In the preceding formula, L.Paging.S1.Rx indicates the number of paging messages that the
eNodeB receives on the S1 interface.
Suggested Measures
If the percentage of paging messages received on the S1 interface per day reaches or exceeds
60% for X (configurable, 3 by default) days in a week, take the following measures:
l Decrease the number of cells in the TAL to which the congested cell belongs.
l Modify the paging policies on the core network side to reduce the number of re-pagings
upon paging failures to decrease the signaling load.
l Enable the precise paging function if the core network is provided by Huawei.
Monitoring Methods
The CPU load Avg of MPT(%) is evaluated by the following factors:
l VS.BBUBoard.CPULoad.Mean, which indicates the average CPU usage of boards.
l Percentage of the number of times that the CPU load Avg of MPT(%) exceeds the
threshold (85%), which is calculated using the following formula:
Percentage of the number of times that the CPU load Avg of MPT(%) exceeds the
threshold (85%) = VS.Board.CPULoad.CumulativeHighloadCount/(3600/5) x 100%
In the preceding formula, VS.Board.CPULoad.CumulativeHighloadCount indicates the
number of times that the CPU usage of boards exceeds a preconfigured threshold.
Suggested Measures
Take measures if either of the following conditions is met:
l The CPU load Avg of MPT(%) (VS.Board.CPUload.Mean) reaches or exceeds 60% in X
(configurable, 3 by default) days in a week.
l The percentage of the number of times that the CPU load Avg of MPT(%) exceeds the
threshold (85%) reaches or exceeds 5% in X (configurable, 3 by default) days in a week.
l If a neighboring eNodeB is lightly loaded, adjust the antenna downtilt or decrease the
power to reduce the local eNodeB's coverage area and to decrease the CPU load of the
local eNodeB. At the same time, expand the coverage area of the neighboring eNodeB to
share the load.
l If the LMPT is used, replace it with the UMPT.
l Add eNodeBs at existing or new sites.
Monitoring Methods
The CPU load Avg of BBP(%) is evaluated by the following factors:
Suggested Measures
The BBP CPU is heavily loaded if either of the following conditions is met:
In this case, expand the eNodeB user-plane capacity. The following measures are suggested
for capacity expansion:
l If the eNodeB has multiple BBPs and one of them is overloaded, transfer the cells
established on the overloaded BBP to a BBP with a lighter load.
The BBP load can be evaluated based on the average CPU usage, the percentage of times
that the CPU usage exceeds the threshold, or the number of cells established on a BBP.
l If the eNodeB already has six (maximum number) BBPs and more BBPs are required,
add eNodeBs.
This section describes how to identify resource congestion problems. Network exceptions can
be found through KPI monitoring. If a KPI deteriorates, users can analyze relevant access
counters to decide whether the deterioration is caused by resource congestion.
The fault location process begins with the identification of abnormal KPIs, followed up by
selecting and performing a KPI analysis on the top N cells.
Cell congestion mainly results from insufficient system resources. Bottlenecks can be
detected by analyzing the access counters (RRC resource congestion rate and E-RAB resource
congestion rate).
6 Related Counters