Huawei Eran7

eRAN3.
0
Capacity Monitoring Guide
Issue 04
Date 2013-11-28
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. 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
Issue04 (2013-11-28) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
eRAN3.0
Capacity Monitoring Guide About This Document
About This Document
Purpose
Growing traffic in mobile networks, especially in newly deployed networks, requires more
and more resources such as radio and transport resources. Lack of resources will affect user
experience. Therefore, monitoring network resources, locating the bottlenecks and performing
network optimization or expansion are essential tasks for operators for provisions of high
quality services.
This document provides the guidelines on LTE FDD capacity monitoring including the detail
on how to identify resource allocation problem. It helps the operators to gain knowledge on
how to monitor the network resource usage and prevent network congestion.
The description in this document is based on 3900 series base station.
NOTE
For definitions of the man-machine language (MML) commands, parameters, alarms, and performance
counters mentioned in this document, see the "Operation and Maintenance" part in 3900 Series LTE
eNodeB Product Documentation.
Intended Audience
This document is intended for:
Field engineers
Network planning engineers
Change History
This section describes changes in each issue of this document.
04 (2013-11-28)
03 (2013-06-28)
02 (2013-03-30)
01 (2012-12-30)
04 (2013-11-28)
This is the fourth official release.
Compared with Issue 03 (2013-06-28), Issue 04 (2013-11-28) includes the following changes.
Issue04 (2013-11-28) Huawei Proprietary and Confidential ii

eRAN3.0
Change Changed Part Change Description

Type
Addition None None

Modification 2.12.2 Monitoring Methods Modified the unit of bandwidth
Deletion None None
03 (2013-06-28)
This is the third official release.

Type
Addition Section "2.7.3 Suggested Measures" Added the suggested measures

when the uplink or downlink PRB
usage reaches or exceeds 90%
Sections "Monitoring Methods" in Added the descriptions about how
chapter 2 "Capacity Monitoring" to query parameter values.
Section 2.3.2 "Monitoring Methods" Added the SFN cell scenarios.
Section 3.1 "Resource Congestion Added counters related KPIs.
Indicators"
Modification Section1.2.2 "eNodeB Resources" Modified the description of
Main-control-board CPU, LBBP
CPU, Transport resource group and
Ethernet port.
Section "1.3 Capacity Monitoring and Modified the Figure 1-2.
Handling Process"
Section 2.1 "Introduction" Modified tables.
Section 2.2.1 "Monitoring Principles" Modified the descriptions of
Section 2.6.1 "Monitoring Principles" monitoring principles.
Section 2.9.1 "Monitoring Principles"
Section 2.11.1 "Monitoring
Principles"
Section 2.4.3 "Suggested Measures" Modified suggested measures.
Section 2.5.3 "Suggested Measures"
Section 2.11.3 "Suggested Measures"
Section "3.2 Resource Allocation Modified the Figure 3-1.
Problem Identification Process"
The summary of Chapter 1, Chapter2 Optimize the summary.
and Chapter 3.
Issue04 (2013-11-28) Huawei Proprietary and Confidential iii

eRAN3.0

Type
Deletion Section "2.4.1 Monitoring Principles" Deleted about the ACK

descriptions.
Appendix Deleted the chapter Appendix.
02 (2013-03-30)
This is the second official release.

Type
Addition Appendix Added the chapter Appendix.
Modification document name The document name has been
changed from Capacity Monitoring
Guidelines to Capacity Monitoring
Guide.
1.3 "Capacity Monitoring and Modified the general process of
Handling Process" capacity monitoring and handling.
1 "Overview" Modified these chapters to conform
to a new template.
2 "Capacity Monitoring"
3 "Resource Allocation Problem
Identification"
Deletion None None
01 (2012-12-30)
This is the first official release.
Issue04 (2013-11-28) Huawei Proprietary and Confidential iv

eRAN3.0 Capacity Monitoring Guide Contents
Contents
About This Document .................................................................................................................... ii

1 Overview......................................................................................................................................... 1
1.1 Capacity Monitoring Methods.......................................................................................................................... 1
1.2 Network Resources .......................................................................................................................................... 1
1.2.2 eNodeB Resources .................................................................................................................................. 2
1.2.3 Cell Resources ........................................................................................................................................ 2
1.3 Capacity Monitoring and Handling Process ..................................................................................................... 4
2 Capacity Monitoring..................................................................................................................... 6
2.1 Introduction ...................................................................................................................................................... 6
2.2 Connected User License Usage ........................................................................................................................ 7
2.2.1 Monitoring Principles ............................................................................................................................. 7
2.2.2 Monitoring Methods ............................................................................................................................... 7
2.2.3 Suggested Measures ................................................................................................................................ 8
2.3 PRB Usage ....................................................................................................................................................... 8
2.3.3 Suggested Measures ................................................................................................................................ 9
2.4 PUCCH Resource Usage .................................................................................................................................. 9
2.4.3 Suggested Measures .............................................................................................................................. 10
2.5 SRS Resource Usage ...................................................................................................................................... 10
2.5.1 Monitoring Principles ........................................................................................................................... 10
2.5.2 Monitoring Methods ............................................................................................................................. 11
2.6 PRACH Resource Usage ................................................................................................................................ 12
2.7 PDCCH Resource Usage ................................................................................................................................ 13
Issue04 (2013-11-28) Huawei Proprietary and Confidential v

eRAN3.0 Capacity Monitoring Guide Contents

2.8 Paging Resource Usage .................................................................................................................................. 15
2.9 Main-Control-Board CPU Usage ................................................................................................................... 15
2.10 LBBP CPU Usage ........................................................................................................................................ 16
2.10.1 Monitoring Principles ......................................................................................................................... 16
2.10.2 Monitoring Methods ........................................................................................................................... 16
2.10.3 Suggested Measures ............................................................................................................................ 17
2.11 Transport Resource Group Usage ................................................................................................................. 17
2.11.1 Monitoring Principles .......................................................................................................................... 17
2.11.2 Monitoring Methods............................................................................................................................ 18
2.12 Ethernet Port Traffic ..................................................................................................................................... 19
2.12.1 Monitoring Principles ......................................................................................................................... 19
2.12.2 Monitoring Methods ........................................................................................................................... 19
3 Resource Allocation Problem Identification ......................................................................... 21

3.1 Resource Congestion Indicators ..................................................................................................................... 21
3.1.2 RRC Resource Congestion Rate ........................................................................................................... 21
3.1.3 E-RAB Resource Congestion Rate ....................................................................................................... 22
3.2 Resource Allocation Problem Identification Process ..................................................................................... 23
Issue04 (2013-11-28) Huawei Proprietary and Confidential vi

eRAN3.0 Capacity Monitoring Guide 1 Overview
1 Overview
This chapter details the method of procedure on how to perform monitoring and handling the
LTE network resources - eNodeB and Cell.
1.1 Capacity Monitoring Methods

Capacity monitoring can be implemented using the following two methods:
Prediction-based monitoring: monitors various types of resource consumption and makes
room for preventive measures such as optimization or expansion to prevent network
congestion. This method applies to daily monitoring because it is simple and easy to
follow. For details, see chapter 2 "Capacity Monitoring."
Problem-driven analysis: uses analysis tools and techniques to identify resource
allocation problems when network congestion occurs. This method helps utilize potential
network value and reduce demands on network expansion. For details, see chapter 3
"Resource Allocation Problem Identification."
1.2 Network Resources

Figure 1-1 shows the network resources to be monitored.
Figure 1-1 Network resources to be monitored
Issue04 (2013-11-28) Huawei Proprietary and Confidential 1

1.2.2 eNodeB Resources

The following are the eNodeB resources to be monitored:
Connected user license
The connected user license specifies the maximum permissible number of users in
RRC_CONNECTED mode. Each connected user consumes radio, device, and transport
resources.
If there are too many connected users, they cannot be well served by the eNodeB and
new services cannot be admitted.
Paging resources
If the actual number of paging messages exceeds the paging capacity, the eNodeB will
be unable to process all the paging messages and user experience will be affected.
Main-control-board CPU
If the load on the main control board exceeds the CPU processing capability,
deterioration in key performance indicators (KPIs) occurs.
The main control board may be LTE main processing and transmission unit (LMPT) or
universal main processing and transmission unit (UMPT).
LBBP CPU
If the load on an LTE baseband process unit (LBBP) exceeds the CPU processing
capability, deterioration in KPIs occurs.
Transport resource groups
Transport resource groups each carry a set of data streams. They are located at the link
layer of the TCP/IP model.
If the load on a transport resource group exceeds the bandwidth configured for the group,
exceptions may occur (for example, packets may be lost), affecting user experience.
Ethernet ports
Ethernet ports are located on the main control board.
If the load on an Ethernet port exceeds the bandwidth configured for the port, exceptions
may occur (for example, packets may be lost), affecting user experience.
1.2.3 Cell Resources

PRBs
The usage of physical resource blocks (PRBs) reflects the uplink and downlink
bandwidth consumed on the air interface.
PUCCH resources
Insufficient physical uplink control channel (PUCCH) resources have negative impacts
on the following:
Admission of new services and handovers
Number of UEs that can be scheduled
Cell throughput and UE throughput
Uplink scheduling delay
SRS resources
Sounding reference signal (SRS) resources are allocated to UEs for network access. If an
LBBPd is used, UEs can access the network even when SRS resources are not allocated
to them.

If SRS resources are insufficient, the eNodeB cannot obtain accurate measurement
information, which then affects efficient use of radio resources.
PRACH resources
Physical random access channel (PRACH) resources are random access preambles
carried on the PRACH.
If PRACH resources are insufficient for handling all access attempts, access delays are
prolonged or even access attempts fail.
PDCCH resources
If physical downlink control channel (PDCCH) resources are limited, scheduling delays
are long and user experience is affected.

1.3 Capacity Monitoring and Handling Process

Figure 1-2 Capacity monitoring and handling process

Some indicators need to be used with others in order to locate resource bottlenecks. For
example, the connected user license usage must be used with the main-control-board CPU
usage; the PDCCH resource usage must be used with the uplink or downlink PRB usage. For
details about capacity monitoring, please refer to chapter 2 "Capacity Monitoring".
The process shown in Figure 1-2 is applicable in most cases. If the resource overload is not
due to increased traffic but other factors, find out the association between these factors and
resource bottlenecks, and identify resource allocation problems by referring to chapter 3
"Resource Allocation Problem Identification."

eRAN3.0 Capacity Monitoring Guide 2 Capacity Monitoring
2 Capacity Monitoring
2.1 Introduction
Various counters are defined to represent the resource usage or load of a E-UTRAN system.
In addition, upper thresholds for these counters are predefined.
NOTE
For better monitoring, it is recommended that the monitoring be performed during busy hours and the
period with maximum resource consumption be defined as busy hours.
Table 2-1, Table 2-2, and Table 2-3 describe the counters related to radio, device, and
transport resources, respectively.
Table 2-1 Counters related to radio resources
Resource Type Counter Resource Usage

Threshold
Connected user L.Traffic.User.Avg 60%
license
PRBs L.ChMeas.PRB.UL.Used.Avg 90%
L.ChMeas. PRB.DL.Used.Avg
PUCCH and SRS L.Traffic.User.Ulsync.Avg 60%
resources
PRACH resources L.RA.GrpA.Att 75%
L.RA.GrpB.Att
L.RA.Dedicate.Att
PDCCH resources L.ChMeas.CCE.CommUsed 80%
L.ChMeas.CCE.ULUsed
L.ChMeas.CCE.DLUsed
Paging resources L. Paging.S1.Rx 60%
L. Paging.Dis.Num 1500

Table 2-2 Counters related to device resources

Threshold
CPUs VS.Board.CPUload.Mean 60%

VS.Board.CPULoad.CumulativeHi 5%
ghloadCount
Table 2-3 Counters related to transport resources

Threshold
Transport resource VS.RscGroup.TxPkts 0.05%
groups
VS.RscGroup.TxDropPkts
VS.RscGroup.TxMeanSpeed 80%
VS.RscGroup.TxMaxSpeed 90%
Ethernet ports VS.FEGE.TxMeanSpeed 70%
VS.FEGE.TxMaxSpeed 85%
VS.FEGE.RxMeanSpeed 70%
VS.FEGE.RxMaxSpeed 85%
2.2 Connected User License Usage

2.2.1 Monitoring Principles
The connected user license specifies the maximum permissible number of users in
RRC_CONNECTED mode. If the connected user license usage exceeds a preconfigured
threshold, users may fail to access the network. If the main-control-board CPU usage is also
abnormal, you can perform capacity expansion.
2.2.2 Monitoring Methods

The following item is used in monitoring this case:
Connected user license usage = SUM (L.Traffic.User.Avg)/Licensed number of connected
users x 100%
where

L.Traffic.User.Avg indicates the average number of connected users in a cell. SUM

(L.Traffic.User.Avg) indicates the sum of the average number of connected users in all
cells in an eNodeB.
The licensed number of connected users can be queried by running the following
command:
DSP LICENSE: FUNCTIONTYPE=eNodeB;
In the command output, the value of LLT1ACTU01 in the Allocated column is the
licensed number of connected users.
2.2.3 Suggested Measures

If the connected user license usage reaches or exceeds 60% for X days (three days by default)
in a week, you are advised to take the following measures:
If the main-control-board CPU usage is less than 60%, increase the licensed limit.
If the main-control-board CPU usage reaches or exceeds 60%, add an eNodeB.
For details about main-control-board CPU usage, please refer to section 2.9 .
2.3 PRB Usage

When the data volume in a cell is high, the PRB usage is high. If the cell is not expanded
promptly, UEs may not be able to access the cell and user experience is affected.

The following items are used in monitoring this case:
Non-SFN cell
Uplink PRB usage = L.ChMeas.PRB.UL.Used.Avg/Total number of uplink PRBs x
100%
Downlink PRB usage = L.ChMeas.PRB.DL.Used.Avg/Total number of downlink
PRBs x 100%
SFN cell
Uplink PRB usage = L.ChMeas.PRB.UL.Used.Avg/(Total number of uplink PRBs x
Number of SFN cell) x 100%
Downlink PRB usage = L.ChMeas.PRB.DL.Used.Avg/(Total number of uplink PRBs
x Number of SFN cell) x 100%
where
L.ChMeas.PRB.UL.Used.Avg indicates the average number of used uplink PRBs.
L.ChMeas.PRB.DL.Used.Avg indicates the average number of used downlink PRBs.
The total number of uplink or downlink PRBs can be obtained from Table 2-2.

Table 2-4 Mapping between bandwidth and the number of PRBs
Bandwidth Number of PRBs

1.4 MHz 6
3 MHz 15
5 MHz 25
10 MHz 50
15 MHz 75
20 MHz 100

Consider the PRB usage and the PDCCH resource usage before performing system expansion.
For details about the PDCCH resource usage, see section 2.7 "PDCCH Resource Usage."
2.4 PUCCH Resource Usage

PUCCH resources include:
Scheduling request indicator (SRI) resources used by scheduled UEs
Channel quality indicator (CQI) resources used by scheduled UEs
The impacts of insufficient PUCCH resources are as follows:
UE admission and handover failure: When a UE requests an RRC connection to be
established for a service admission or a handover, the eNodeB allocates CQI resources,
SRI resources for the UE. If the allocation of SRI and CQI resources fails, the UE
handover admission fails.
Limited number of scheduled UEs: If an out-of-synchronization UE requests uplink
synchronization for data transmission, the eNodeB allocates CQI resources, SRI
resources for the UE. If the allocation of SRI and CQI resources fails, the UE cannot
restore uplink synchronization and therefore cannot transmit data.
Decrease in cell throughput and UE throughput: If CQI resources are insufficient or
limited, the eNodeB selects a CQI reporting period of 40 ms for UEs, which results in
less accurate CQIs and lower spectral efficiency. In addition, these UEs cannot be chosen
to perform frequency selective scheduling.
Increase in uplink scheduling delay: If SRI resources are insufficient or limited, the
eNodeB selects an SRI period of 20 ms for UEs, which results in longer uplink
scheduling delays for these UEs.


PUCCH resource usage = L.Traffic.User.Ulsync.Avg/Maximum number of UEs supported by

the PUCCH x 100%
where
L.Traffic.User.Ulsync.Avg indicates the average number of scheduled UEs.
For the eNodeB base station, the maximum number of UEs supported by the PUCCH
can be obtained by running the MML command: LST CELLALGOSWITCH.
If the value of PUCCH algorithm switch is PucchSwitch: On, search Table 2-5 for
the maximum number of UEs supported by the PUCCH.
Table 2-5 Maximum number of UEs supported by the PUCCH
System Bandwidth Maximum Number of UEs Supported by the

(Configurable) PUCCH
5 MHz 200
10 MHz 400
15 MHz 400
20 MHz 400
If the value of PUCCH algorithm switch is PucchSwitch:Off, turn on the switch by

referring to section 2.4.3 "Suggested Measures."

If the PUCCH resource usage reaches or exceeds 60% for X days (three days by default) in a
week, you are advised to take the following measures:
If the value of PUCCH algorithm switch is PucchSwitch:Off, turn on the switch by
running the following command:
MOD CELLALGOSWITCH: LocalCellId=xxx, PucchAlgoSwitch=PucchSwitch-1;
If the value of PUCCH algorithm switch is PucchSwitch:On, perform capacity
expansion. The common measures are as follows:
Add a carrier.
Add an eNodeB.
Divide the coverage of the eNodeB into more cells.
2.5 SRS Resource Usage

The eNodeB allocates sounding reference signal (SRS) resources to UEs that access the
network. By measuring SRSs, the eNodeB can estimate uplink channel quality for uplink
adaptive modulation and coding (AMC) and frequency selective scheduling. In addition, the
eNodeB can measure the UE uplink timing to maintain uplink synchronization. For each UE,
the SRS is not sent together with the physical uplink shared channel (PUSCH) or PUCCH.


SRS resource usage = L.Traffic.User.Ulsync.Avg/Maximum number of UEs supported by
SRS resources x 100%
where
L.Traffic.User.Ulsync.Avg indicates the average number of scheduled UEs.
For the eNodeB base station, the maximum number of UEs supported by SRS resources
can be queried by running the MML command: LST CELLALGOSWITCH:
If the value of SoundingRS algorithm switch is SrsSubframeRecfSwitch:On,
search Table 2-6 for the maximum number of UEs supported by SRS resources.
Table 2-6 Maximum number of UEs supported by SRS resources

System Bandwidth Maximum Number of UEs Supported by SRS
(Configurable) Resources
5 MHz 200
10 MHz 400 (for normal CP)
370 (for extended CP)
15 MHz 400
20 MHz 400
If the value of SoundingRS algorithm switch is SrsSubframeRecfSwitch:Off, turn

on the switch by referring to section 2.5.3 "Suggested Measures."

If the SRS resource usage reaches or exceeds 60% for X days (three days by default) in a
week, you are advised to take the following measures:
If the value of SoundingRS algorithm switch is SrsSubframeRecfSwitch:Off, turn on
the switch by running the following command:
MOD CELLALGOSWITCH: LocalCellId=x, SrsAlgoSwitch=SrsSubframeRecfSwitch-1;
If the value of SoundingRS algorithm switch is SrsSubframeRecfSwitch:On, perform
capacity expansion. The common measures are as follows:
Add a carrier.
Add an eNodeB.
Divide the coverage of the eNodeB into more cells.

2.6 PRACH Resource Usage

The PRACH transmits preambles during contention-based or non-contention-based random
access procedures.
If the number of contention-based random access attempts in a second reaches or exceeds N,
the preamble conflict probability and access delay increase. Here, N denotes 50 for 5 MHz or
10 MHz, and 100 for the bandwidth of 15 MHz or 20 MHz. The values of N are determined
during preamble design, considering factors such as that the preamble conflict probability
should be less than 1%.
If more than 100 non-contention-based random access attempts are initiated per second,
dedicated preambles will become insufficient and the eNodeB will instruct the UE to initiate
contention-based random access instead, increasing the access delay for the UE. In handover
scenarios, the handover procedure is prolonged.

Random preamble usage = (L.RA.GrpA.Att + L.RA.GrpB.Att)/3600/N x 100%
Dedicated preamble usage = L.RA.Dedicate.Att/3600/100 x 100%
where
If the bandwidth is 5 MHz or 10 MHz, set N to 50. If the bandwidth is 15 MHz or 20
MHz, set N to 100.
L.RA.GrpA.Att indicates the number of times that random preambles in group A are
received.
L.RA.GrpB.Att indicates the number of times that random preambles in group B are
received.
L.RA.Dedicate.Att indicates the number of times that dedicated preambles are received.

You are advised to take the following measures:
If the random preamble usage reaches or exceeds 75% for X days (three days by default)
in a week, enable the adaptive backoff function by running the following command to
help reduce the peak RACH load and average access delay:
MOD CELLALGOSWITCH: LocalCellId=x, RachAlgoSwitch=BackOffSwitch-1;
If the dedicated preamble usage reaches or exceeds 75% for X days (three days by
default) in a week, enable reuse of dedicated preambles between UEs by running the
following command:
MOD CELLALGOSWITCH: LocalCellId=x, RachAlgoSwitch=MaksIdxSwitch-1;
This helps reduce the probability of UEs initiating contention-based random access in the
case of dedicated preamble insufficiency and therefore helps reduce the access delay.

2.7 PDCCH Resource Usage

This capacity indicator measures the number of control channel elements (CCEs) that can be
used by the PDCCH.
In each radio frame, CCEs must be allocated to uplink and downlink UEs to be scheduled and
common control signaling. PDCCH CCEs must be properly configured and allocated to
minimize downlink control overheads 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 result in a long service delay and unsatisfactory user experience.
In addition to the long service delay, if the UEs to be scheduled have small-sized buffers
but need to transmit a large amount of user plane data, the PRBs and power allocated to
the physical downlink shared channel (PDSCH) and PUSCH may be more than
necessary, resulting in low spectral efficiency.
If PDCCH symbols are excessive, which indicates that the usage of PDCCH CCEs is low,
the resources that can be used by the PDSCH decreases. This will also result in low
spectral efficiency.

CCE usage = (L.ChMeas.CCE.CommUsed + L.ChMeas.CCE.ULUsed +
L.ChMeas.CCE.DLUsed)/3600/1000/Maximum number of PDCCH CCEs x 100%
where
L.ChMeas.CCE.CommUsed indicates the number of PDCCH CCEs used for common
signaling.
L.ChMeas.CCE.ULUsed indicates the number of PDCCH CCEs used for uplink
scheduling.
L.ChMeas.CCE.DLUsed indicates the number of PDCCH CCEs used for downlink
scheduling.
The maximum number of PDCCH CCEs can be queried by performing the following
steps:
Step 1 Run the LST CELLPDCCHALGO command to query the value of PDCCH Symbol
Number Adjust Switch.
If the value is On, the number of PDCCH symbols is 3.
If the value is Off, run the LST CELLPDCCHALGO command to query the value
of PDCCH Initial Symbol Number, which indicates the number of
PDCCH symbols.
Step 2 Run the LST PHICHCFG command to query the value of PHICH resource. The
value may be ONE_SIXTH, HALF, ONE, or TWO, corresponding to the
value of Ng in Table 2-7.
Step 3 Search Table 2-7 for the maximum number of PDCCH CCEs based on the
system bandwidth, the value of Ng, and the number of PDCCH symbols.

Table 2-7 Maximum number of PDCCH CCEs
System Bandwidth Ng Maximum Number of PDCCH CCEs
Number of Number of Number of

PDCCH PDCCH PDCCH
Symbols = 1 Symbols = 2 Symbols = 3
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
----End

If the CCE usage reaches or exceeds 80% and the uplink or downlink PRB usage is less than
90% for X days (three days by default) in a week:
If the value of PDCCH Symbol Number Adjust Switch is On, you do not need to take
any measures.
The reason is that the eNodeB automatically adjusts the number of PDCCH symbols
based on the CCE load to meet the CCE requirement while preventing excessive PDSCH
resource consumption.
If the value of PDCCH Symbol Number Adjust Switch is Off, turn on the switch by
running the following command :
MOD CELLPDCCHALGO: LocalCellId=x, PdcchSymNumSwitch=ON;
If the uplink or downlink PRB usage reaches or exceeds 90%, no processing is required.

2.8 Paging Resource Usage

The eNodeB can process a maximum of 750 paging messages per second. If the number of
paging messages exceeds that capacity, the eNodeB may discard paging messages, which
leads to a decrease in the call completion rate.

Percentage of paging messages received over the S1 interface =
L.Paging.S1.Rx/3600/Maximum number of paging messages that can be processed per
second x 100%
L.Paging.Dis.Num
where
L.Paging.S1.Rx indicates the number of paging messages received over the S1 interface.
L.Paging.Dis.Num indicates the number of paging messages discarded over the Uu
interface.

You are advised to decrease the number of cells in the tracking area list (TAL) that the
congested cell belongs to if either of the following conditions is met for X days (three days by
default) in a week:
The percentage of paging messages received by the eNodeB over the S1 interface
reaches or exceeds 60%.
1500 or more paging messages from the mobility management entity (MME) to UEs are
discarded in a day.
2.9 Main-Control-Board CPU Usage

The 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
users may experience a low access success rate, low E-RAB setup success rate, or high
service drop rate.
Operators can determine whether KPI deterioration is caused by insufficient
main-control-board CPU processing capability or poor radio conditions. The evaluation is as
follows:
If the MCS measurement and initial-transmission failure measurement indicate that the
channel quality is poor, KPI deterioration may not be caused by main-control-board CPU
overload but by deterioration in channel quality.

If the KPIs deteriorate and the main-control-board CPU usage exceeds a preconfigured
threshold, you are advised to perform capacity expansion according to section 2.9.3
"Suggested Measures."

VS.Board.CPUload.Mean
Percentage of times that the main-control-board CPU usage reaches or exceeds a
preconfigured threshold = VS.Board.CPULoad.CumulativeHighloadCount/3600 x 100%
where
VS.Board.CPUload.Mean indicates the average main-control-board CPU usage.
VS.Board.CPULoad.CumulativeHighloadCount indicates the number of times that the
main-control-board CPU usage exceeds a preconfigured threshold.

The main-control-board CPU becomes overloaded if either of the following conditions is met
for X days (three days by default) in a week:
The average main-control-board CPU usage reaches or exceeds 60%.
The percentage of times that the main-control-board CPU usage reaches or exceeds 85%
is greater than or equal to 5%.
When the main-control-board CPU is overloaded, you are advised to add an eNodeB and
connect it to the evolved packet core (EPC) through a new S1 interface.
2.10 LBBP CPU Usage

If the eNodeB receives too much traffic volume, which is expressed either in bit/s or packet/s,
the LBBP CPU responsible for user plane processing is heavily loaded. As a result, the
eNodeB has a low RRC connection setup success rate, low E-RAB setup success rate, low
handover success rate, and high service drop rate.

VS.Board.CPUload.Mean
Percentage of times that the LBBP CPU usage reaches or exceeds a preconfigured
threshold = VS.Board.CPULoad.CumulativeHighloadCount/3600 x 100%
where
VS.Board.CPUload.Mean indicates the average LBBP CPU usage.
VS.Board.CPULoad.CumulativeHighloadCount indicates the number of times that the
LBBP CPU usage exceeds a preconfigured threshold.


The LBBP CPU becomes overloaded if either of the following conditions is met for X days
(three days by default) in a week:
The average LBBP CPU usage reaches or exceeds 60%.
The percentage of times that the LBBP CPU usage reaches or exceeds 85% is greater
than or equal to 5%.
When the LBBP CPU is overloaded, you are advised to perform capacity expansion on the
eNodeB user plane as follows:
If the LBBP is an LBBPc, replace the LBBPc with an LBBPd.
Add an LBBP to share the network load, and then determine whether to move existing
cells or add new cells based on the number of UEs. The capacity expansion methods are
as follows:
If the radio resources are sufficient (that is, the usage of each type of radio resources
is lower than the threshold), move cells from the existing LBBP to the new LBBP.
If the radio resources are insufficient, set up new cells on the new LBBP.
If the eNodeB has multiple LBBPs and one of them is overloaded, move cells from the
overloaded LBBP to an LBBP with a lighter load.
LBBP load can be indicated by the following:
Average CPU usage
Percentage of times that the CPU usage reaches or exceeds a preconfigured threshold
Number of cells established on an LBBP
If the eNodeB already has a maximum of six LBBPs and more LBBPs are required, add
an eNodeB.
2.11 Transport Resource Group Usage

A transport resource group carries a set of data streams, which can be local data or forwarded
data. Local data is classified into control plane, user plane, operation and maintenance (OM),
and IP clock data. Forwarded data is not divided into different types. If a transport resource
group is congested, it cannot transmit or forward data, which affects service provision.
A transport resource group for user plane data is a monitored object.
Figure 2-1 shows the position of transport resource group in the TCP/IP model

Figure 2-1 The position of the transport resource group

Packet loss rate = VS.RscGroup.TxDropPkts/VS.RscGroup.TxPkts x100%
Proportion of the average transmission rate to the configured bandwidth =
VS.RscGroup.TxMeanSpeed/Bandwidth configured for the transport resource group x
100%
Proportion of the maximum transmission rate to the configured bandwidth =
VS.RscGroup.TxMaxSpeed/Bandwidth configured for the transport resource group x
100%
where
VS.RscGroup.TxDropPkts indicates the number of packets discarded because of
transmission failures of a transport resource group.
VS.RscGroup.TxPkts indicates the number of packets transmitted by a transport resource
group.
VS.RscGroup.TxMeanSpeed indicates the average transmission rate of a transport
resource group.
VS.RscGroup.TxMaxSpeed indicates the maximum transmission rate of a transport
resource group.
The bandwidth configured for a transport resource group can be queried by running the
following command:
DSP RSCGRP: CN=x, SRN=x, SN=x, BEAR=xx, SBT=xxxx, PT=xxx;
In the command output, the value of Tx Bandwidth is the bandwidth configured for the
transport resource group.

A transport resource group is congested if one of the following conditions is met:
The packet loss rate reaches or exceeds 0.05% for five days in a week
The proportion of the average transmission rate to the configured bandwidth reaches or
exceeds 80% for five days in a week.

The proportion of the maximum transmission rate to the configured bandwidth reaches
or exceeds 90% for two days in a week.
When a transport resource group is congested, you are advised to expand the bandwidth of the
transport resource group. The following is an example command:
MOD RSCGRP: CN=x, SRN=x, SN=x, BEAR=IP, SBT=BASE_BOARD, PT=ETH, PN=x, RSCGRPID=x, RU=x,
TXBW=xxxx, RXBW=xxxx;
If the problem persists after the bandwidth adjustment, you are advised to expand the eNodeB
bandwidth.
2.12 Ethernet Port Traffic

The Ethernet port traffic is the channel traffic at the physical layer, including uplink and
downlink traffic. The eNodeB Ethernet port traffic reflects the throughput and communication
quality of the Ethernet ports on the main control board of the eNodeB. Based on the
monitoring results, you can determine whether the transmission capacity allocated by an
operator for the S1 and X2 interfaces on the eNodeB meet the requirements for uplink and
downlink transmissions.

(Item 1) Proportion of the average uplink transmission rate to the allocated bandwidth =
VS.FEGE.TxMeanSpeed/Allocated bandwidth x 100%
(Item 2) Proportion of the maximum uplink transmission rate to the allocated bandwidth
= VS.FEGE.TxMaxSpeed/Allocated bandwidth x 100%
(Item 3) Proportion of the average downlink reception rate to the allocated bandwidth =
VS.FEGE.RxMeanSpeed/Allocated bandwidth x 100%
(Item 4) Proportion of the maximum downlink reception rate to the allocated bandwidth
= VS.FEGE.RxMaxSpeed/Allocated bandwidth x 100%
where
VS.FEGE.TxMeanSpeed indicates the average transmission rate of an Ethernet port.
VS.FEGE.TxMaxSpeed indicates the maximum transmission rate of an Ethernet port.
VS.FEGE.RxMeanSpeed indicates the average reception rate of an Ethernet port.
VS.FEGE.RxMaxSpeed indicates the maximum reception rate of an Ethernet port.
The allocated bandwidth can be queried by running the LST LR command.
If LR Switch is set to Disable, set the allocated bandwidth in the formulas for items
1 and 2 to 1 Gbit/s for the UMPT or 360 Mbit/s for the LMPT.
If LR Switch is set to Disable, set the allocated bandwidth in the formulas for items
3 and 4 to 1 Gbit/s for the UMPT or 540 Mbit/s for the LMPT.
If LR Switch is set to Enable, set the allocated bandwidth in the formulas for items 1
and 2 to the value of UL Committed Information Rate (Kbit/s).
If LR Switch is set to Enable, set the allocated bandwidth in the formulas for items 3
and 4 to the value of DL Committed Information Rate (Kbit/s).

The types of main control boards can be queried by running the following command:
DSP BRD: CN=x, SRN=x, SN=x;
In the command output, the value of Config Type is the type of the main control board.

You are advised to perform transmission capacity expansion if either of the following
conditions is met:
The proportion of the average uplink transmission rate (or downlink reception rate) to the
allocated bandwidth reaches or exceeds 70% for at least five days in a week.
The allocated bandwidth is 750 Mbit/s by default. The actually allocated bandwidth can
be obtained from the operator.
The proportion of the maximum uplink transmission rate (or downlink reception rate) to
the allocated bandwidth reaches or exceeds 85% for at least two days in a week.

eRAN3.0 Capacity Monitoring Guide 3 Resource Allocation Problem Identification
3 Resource Allocation Problem

Identification
This chapter describes how to assess the network congestion cause and feasible solutions.
3.1 Resource Congestion Indicators

Resource congestion indicators (such as the RRC resource congestion rate and E-RAB
resource congestion rate) can be used to check whether the network is congested. Table 3-1
lists the counters related to KPIs.
Table 3-1 Counters related to KPIs
Performance Counter Description
L.RRC.ConnReq.Att Number of RRC Connection Request messages received

from UEs in a cell (excluding retransmitted messages)
L.RRC.ConnReq.Succ Number of RRC Connection Setup Complete messages
received from UEs in a cell
L.E-RAB.AttEst Number of E-UTRAN radio access bearer (E-RAB) setup
attempts initiated by UEs in a cell
L.E-RAB.SuccEst Number of successful E-RAB setups initiated by UEs in a
cell
L.E-RAB.AbnormRel Number of times that the eNodeB abnormally releases
E-RABs that are transmitting data in a cell
L.E-RAB.NormRel Number of times that the eNodeB normally releases
E-RABs in a cell
3.1.2 RRC Resource Congestion Rate

The RRC resource congestion rate is a cell-level indicator. It is calculated using the following
formula:

RRC resource congestion rate = L.RRC.SetupFail.ResFail/L.RRC.ConnReq.Att x 100%

where
L.RRC.SetupFail.ResFail indicates the number of RRC connection setup failures due to
resource allocation failures.
L.RRC.ConnReq.Att indicates the number of RRC connection setup requests.
3.1.3 E-RAB Resource Congestion Rate

The E-RAB resource congestion rate is a cell-level indicator. It is calculated using the
following formula:
E-RAB resource congestion rate = L.E-RAB.FailEst.NoRadioRes/L.E-RAB.AttEst x 100%
where
L.E-RAB.FailEst.NoRadioRes indicates the number of E-RAB setup failures due to
radio resource insufficiency.
L.E-RAB.AttEst indicates the number of E-RAB setup attempts.

3.2 Resource Allocation Problem Identification Process

Figure 3-1 Resource allocation problem identification process
The fault location procedure 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 KPIs.


Huawei Eran7

Загружено:

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

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

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

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

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

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

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

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

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

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

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

Huawei Eran7

Загружено:

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

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

eRAN3.

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue04 (2013-11-28) Huawei Proprietary and Confidential i

About This Document

Issue04 (2013-11-28) Huawei Proprietary and Confidential ii

Change Changed Part Change Description

Addition None None

Deletion None None

Change Changed Part Change Description

Addition Section "2.7.3 Suggested Measures" Added the suggested measures

Issue04 (2013-11-28) Huawei Proprietary and Confidential iii

Change Changed Part Change Description

Deletion Section "2.4.1 Monitoring Principles" Deleted about the ACK

Change Changed Part Change Description

Issue04 (2013-11-28) Huawei Proprietary and Confidential iv

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

Issue04 (2013-11-28) Huawei Proprietary and Confidential v

2.7.3 Suggested Measures .............................................................................................................................. 14

3 Resource Allocation Problem Identification ......................................................................... 21

Issue04 (2013-11-28) Huawei Proprietary and Confidential vi

1.1 Capacity Monitoring Methods

1.2 Network Resources

Figure 1-1 Network resources to be monitored

Issue04 (2013-11-28) Huawei Proprietary and Confidential 1

1.2.2 eNodeB Resources

1.2.3 Cell Resources

Issue04 (2013-11-28) Huawei Proprietary and Confidential 2

Issue04 (2013-11-28) Huawei Proprietary and Confidential 3

1.3 Capacity Monitoring and Handling Process

Issue04 (2013-11-28) Huawei Proprietary and Confidential 4

Issue04 (2013-11-28) Huawei Proprietary and Confidential 5

Table 2-1 Counters related to radio resources

Resource Type Counter Resource Usage

Issue04 (2013-11-28) Huawei Proprietary and Confidential 6

Table 2-2 Counters related to device resources

Resource Type Counter Resource Usage

CPUs VS.Board.CPUload.Mean 60%

Table 2-3 Counters related to transport resources

Resource Type Counter Resource Usage

2.2 Connected User License Usage

2.2.2 Monitoring Methods

Issue04 (2013-11-28) Huawei Proprietary and Confidential 7

L.Traffic.User.Avg indicates the average number of connected users in a cell. SUM

2.2.3 Suggested Measures

2.3 PRB Usage

2.3.2 Monitoring Methods

Issue04 (2013-11-28) Huawei Proprietary and Confidential 8

Table 2-4 Mapping between bandwidth and the number of PRBs

Bandwidth Number of PRBs

2.3.3 Suggested Measures

2.4 PUCCH Resource Usage

2.4.2 Monitoring Methods

Issue04 (2013-11-28) Huawei Proprietary and Confidential 9

PUCCH resource usage = L.Traffic.User.Ulsync.Avg/Maximum number of UEs supported by

Table 2-5 Maximum number of UEs supported by the PUCCH

System Bandwidth Maximum Number of UEs Supported by the

If the value of PUCCH algorithm switch is PucchSwitch:Off, turn on the switch by

2.4.3 Suggested Measures

2.5 SRS Resource Usage

Issue04 (2013-11-28) Huawei Proprietary and Confidential 10

2.5.2 Monitoring Methods