HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

eRAN Feature Documentation

Product Version: eRAN8.1
Library Version: 01
Date: 03/23/2015

For any question, please contact us.

Copyright Huawei Technologies Co., Ltd. 2015. All rights reserved.

Flow Control
Contents
3.6.3 Flow Control

eRAN

Flow Control Feature Parameter Description

Issue

01

Date

2015-03-23

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2015. 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

3.6.3 Contents

1 trong 13

1 About This Document

1.1 Scope
1.2 Intended Audience
1.3 Change History
1.4 Differences Between eNodeB Types
2 Overview
2.1 Introduction
2.2 Benefits
2.3 Application Scenarios
2.4 Basic Principles of Flow Control
2.4.1 Control-Plane Data Flows and Protocols
2.4.2 User-Plane Data Flows and Protocols
2.4.3 OAM Data Flows
2.4.4 Logical Architecture of an eNodeB
2.5 Flow Control Mechanism
3 Control-Plane Flow Control
3.1 MME Overloadtriggered Flow Control
3.1.1 Objective
3.1.2 Principle
3.1.3 Monitoring
3.2 Flow Control for Random Access Preamble
3.2.1 Objective
3.2.2 Principle
3.2.2.1 Flow Control Points
3.2.2.2 Flow Control Actions
3.2.3 Monitoring
3.3 Initial Access Request Control
3.3.1 Objective
3.3.2 Principle
3.3.2.1 Flow Control Points
3.3.2.2 Flow Control Actions

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

3.3.3 Monitoring
3.4 Paging Message Flow Control
3.4.1 Objective
3.4.2 Principle
3.4.2.1 Flow Control Points
3.4.2.2 Flow Control Actions
3.4.3 Monitoring
3.5 RRC Reject Wait time
3.5.1 Objective
3.5.2 Principle
3.5.3 Monitoring
3.6 AC Control
3.6.1 Objective
3.6.2 Principle
3.6.3 Monitoring
3.7 Uplink Synchronized UE Number Control
3.7.1 Objective
3.7.2 Principle
3.7.3 Monitoring
4 User-Plane Flow Control
4.1 Downlink User-Plane Flow Control
4.1.1 Objective
4.1.2 Principle
4.1.2.1 Flow Control Points
4.1.2.2 Flow Control Actions
4.1.3 Monitoring
4.2 Uplink User-Plane Flow Control
4.2.1 Objective
4.2.2 Principle
4.2.2.1 Flow Control Points
4.2.2.2 Flow Control Actions
4.2.3 Monitoring
5 OAM Flow Control
5.1 OAM Flow Control
5.1.1 Objective
5.1.2 Principle
5.1.3 Monitoring
6 CPU Core Deployment and CPU Usage Monitoring
6.1 LMPT
6.1.1 CPU Core Deployment
6.1.2 CPU Usage Monitoring
6.1.2.1 Counters Related to the CPU Usage on the LMPT
6.1.2.2 Alarm Related to CPU Overload on the LMPT
6.1.2.3 CPU Usage Monitoring on the U2000 or LMT
6.2 UMPT
6.2.1 CPU Core Deployment
6.2.2 CPU Usage Monitoring
6.2.2.1 Counters Related to the CPU Usage on the UMPT
6.2.2.2 Alarm Related to CPU Overload on the UMPT
6.2.2.3 CPU Usage Monitoring on the U2000 or LMT
6.3 LBBP
6.3.1 CPU Core Deployment
6.3.2 CPU Usage Monitoring
6.3.2.1 CPU Usage Counters
6.3.2.2 Alarm Related to CPU Overload on the LBBP
6.3.2.3 CPU Usage Monitoring on the U2000 or LMT
6.4 UBBP
6.4.1 CPU Core Deployment
6.4.2 CPU Usage Monitoring
6.4.2.1 CPU Usage Counters
6.4.2.2 Alarm Related to CPU Overload on the UBBP
6.4.2.3 CPU Usage Monitoring on the U2000 or LMT
7 Parameters
8 Counters
9 Glossary
10 Reference Documents

About This Document

Scope

This document describes eNodeB flow control, including its technical principles, related features, network impact, and engineering guidelines.
Any managed objects (MOs), parameters, alarms, or counters described herein correspond to the software release delivered with this document. Any future updates will be described in the product documentation delivered with future software releases.
This document applies only to LTE FDD. Any "LTE" in this document refers to LTE FDD, and "eNodeB" refers to LTE FDD eNodeB.
This document applies to the following eNodeBs.
eNodeB Type

Model

Macro

3900 series eNodeBs

LampSite

DBS3900 LampSite

Intended Audience

This document is intended for personnel who:

Need to understand the features described herein
Work with Huawei products
Change History

This section provides information about the changes in different document versions. There are two types of changes:
Feature change
Changes in features and parameters of a specified version
Editorial change
Changes in wording or addition of information and any related parameters affected by editorial changes

eRAN8.1 01 (2015-03-23)
This issue includes the following changes.
Change Type

Change Description

Parameter Change

Affected Entity

Feature change

None

None

Editorial change

Added the following sections:

2.4 Basic Principles of Flow Control
2.5 Flow Control Mechanism
3.2 Flow Control for Random Access Preamble

Added the following parameters:

RSCGRPALG.TCSW
RSCGRPALG.CTTH
RSCGRPALG.CCTTH

3.3.2.1 Flow Control Points

3.3.2.2 Flow Control Actions
3.4.2.1 Flow Control Points
3.4.2.2 Flow Control Actions
4.1.2.1 Flow Control Points
4.1.2.2 Flow Control Actions
4.2.1 Objective
4.2.2 Principle
4.2.3 Monitoring
6 CPU Core Deployment and CPU Usage Monitoring

eRAN8.1 Draft A (2015-01-15)

Compared with Issue 01 (2014-04-26) of eRAN7.0, Draft A (2015-01-15) of eRAN8.1 does not include any changes.
Differences Between eNodeB Types

2 trong 13

The features described in this document are implemented in the same way on macro and LampSite eNodeBs.

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

Overview

Introduction

With flow control, an eNodeB controls input and output flow to prevent overload and improve equipment stability. Flow control includes control-plane, user-plane, OAM data flow control, and uplink synchronized UE number control.
Flow control is implemented in the following ways:
An eNodeB controls input flow to prevent overload of the eNodeB and ensure the eNodeB's processing capability when services increase dramatically.
An eNodeB controls output flow to prevent overload of the peer network element (NE).
Benefits

When services increase dramatically, flow control decreases the possibility of eNodeB reset and deteriorating access and handover success rates, thereby improving eNodeB stability.
Application Scenarios

As shown in Figure 2-1, three types of data flows exist in LTE networks: control-plane, user-plane, and OAM data flows.
Figure 2-1 eNodeB data flows

According to data flow and load, there are eight load points in LTE networks, as shown in Table 2-1.

Table 2-1 Load points in LTE networks

Data Flow Type

Data Flow

Load Point

Control-plane data flow

Uplink signaling data flows from UEs to an eNodeB

Load point 5: An eNodeB is overloaded if UEs send too much signaling to the eNodeB.

Uplink signaling data flows from an eNodeB to an MME

Load point 1: An MME is overloaded if an eNodeB sends too much signaling to the MME.

Downlink signaling data flows from an MME to an eNodeB

Load point 3: An eNodeB is overloaded if an MME sends too much signaling to the eNodeB.

Downlink signaling data flows from an eNodeB to a UE

N/A

Signaling data flows between eNodeBs

Load point 6: An eNodeB is overloaded if a peer eNodeB sends too much signaling to the eNodeB.

Uplink service data flows from UEs to an eNodeB

Load point 5: An eNodeB is overloaded if UEs send too much service data to the eNodeB.

Uplink service data flows from an eNodeB to an S-GW

Load point 2: An S-GW is overloaded if an eNodeB sends too much service data to the S-GW.

Downlink service data flows from an S-GW to an eNodeB

Load point 4: An eNodeB is overloaded if an S-GW sends too much service data to the eNodeB.

Downlink service data flows from an eNodeB to a UE

N/A

Service data flows between eNodeBs

Load point 6: An eNodeB is overloaded if a peer eNodeB sends too much service data to the eNodeB.

Uplink OAM data flows from an eNodeB to the operations support system
(OSS)

Load point 7: The OSS is overloaded if an eNodeB sends too much OAM data to the OSS.

Downlink OAM data flows from the OSS to an eNodeB

Load point 8: An eNodeB is overloaded if the OSS sends too much OAM data to the eNodeB.

User-plane data flow

OAM data flow

This document describes flow control at the preceding eight load points.
Basic Principles of Flow Control

3 trong 13

Three types of data flows exist in LTE networks:

Control-plane data flow
User-plane data flow
Operation, administration and maintenance (OAM) data flow
Flow control includes intra-eNodeB flow control and flow control between eNodeBs and other NEs.
The basic principles of flow control include:
Controls UE access and reduces data transmission rates based on the received back pressure indicator when a module is overloaded.
Identifies and suppresses low-priority services based on service priorities to ensure the high-priority services are performed preferentially.
2.4.1 Control-Plane Data Flows and Protocols
Figure 2-2 shows control-plane data flows:

Uplink signaling data flows from a UE to an eNodeB

Uplink signaling data flows from an eNodeB to an MME
Downlink signaling data flows from an MME to an eNodeB
Downlink signaling data flows from an eNodeB to a UE
Signaling data flows between eNodeBs
Figure 2-2 Control-plane data flows

Figure 2-3 and Figure 2-4 show the protocol stacks related to the control plane.

Figure 2-3 Control-plane protocol stacks between the UE and the MME

Figure 2-4 Control-plane protocol stacks between eNodeBs

2.4.2 User-Plane Data Flows and Protocols

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

Figure 2-5 shows user-plane data flows:

Uplink service data flows from a UE to an eNodeB

Uplink service data flows from an eNodeB to an S-GW
Downlink service data flows from an S-GW to an eNodeB
Downlink service data flows from an eNodeB to a UE
Service data flows between eNodeBs
Figure 2-5 User-plane data flows

Figure 2-6 shows the protocol stacks related to the user plane.

Figure 2-6 User-plane protocol stacks

2.4.3 OAM Data Flows

Figure 2-7 shows OAM data flows:

Uplink OAM data flows from an eNodeB to the operations support system (OSS)
Downlink OAM data flows from the OSS to an eNodeB
Figure 2-7 OAM data flows

2.4.4 Logical Architecture of an eNodeB

Figure 2-8 shows the functions of an eNodeB.

The main processing and transmission unit (MPT) provides the following functions:
Control plane functions, including:
RRC functions over the Uu interface
S1AP/X2AP functions over the S1 and X2 interfaces
User plane functions, which are GTP-U functions implemented by the TRAN module, including S1 and X2 user plane functions and transmission functions
OAM plane functions
The baseband processing unit (BBP) provides the following functions:
Control plane functions, including the Uu interface resource allocation function implemented by the CELLM module
User plane functions, including PDCP, RLC, and MAC functions
OAM plane functions
Figure 2-8 Logical architecture of an eNodeB

Flow Control Mechanism

4 trong 13

Figure 2-9 shows the flow control mechanism, which includes the following procedures:

Measurement
The eNodeB collects statistics about CPU usage and number of received signaling messages or data volumes, and then determines whether to perform flow control based on the statistics.
Flow control actions
Open-loop control. For example, the eNodeB performs flow control based on the number of received signaling messages or data volumes, including:
Random Access Preamble
RRC Connection Request
Handover Request
RRC Connection Re-establishment Request
Paging
Downlink data volume
Closed-loop control. For example, the eNodeB performs flow control on received signaling messages or user-plane data based on CPU usage, including rejecting handover or access requests and discarding messages based on priorities.

NOTE:
Physical downlink control channel (PDCCH), physical uplink control channel (PUCCH), and sounding reference signal (SRS) resources are reserved based on their own specifications to support the maximum number of UEs that the eNodeB can handle. Therefore, flow control
does not need to be designed for these resources. For details, see Physical Channel Resource Management Feature Parameter Description.
Monitoring
Intra-eNodeB flow control effect can be monitored through performance counters.

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

Figure 2-9 Flow control mechanism

Both the MPT and BBP are multi-core processing systems. Flow control is triggered by the load of each CPU core or thread, not the average load of all CPUs. The purpose is to ensure that flow control can be performed in time when overload occurs and therefore ensure system reliability.
Table 2-2 lists the CPU cores required for diffident flow control actions. The description of each type of CPU is as follows:

CP Mng CPUs
CPUs for the CELLM module and OAM module
CP Traffic CPUs
CPUs for the RRC, S1AP, and X2AP modules
UP Mng CPUs
CPUs for user-plane management at the cell or eNodeB level
UP Traffic CPUs
CPUs for user-plane protocol stack processing at the UE level

Table 2-2 CPU cores required for different flow control actions
Flow Control Action

Board Type

CPU Type

Control plane: Paging

MPT

CP Mng CPUs

BBP

LBBP: CP Mng CPUs

UBBP: CP Mng CPUs and CP Traffic CPUs

Control plane: Random Access Preamble

BBP

LBBP: CP Mng CPUs

UBBP: CP Mng CPUs and CP Traffic CPUs

Control plane: RRC Connection Request/RRC Connection Re-establishment Request/Handover MPT

Request

CP Traffic CPUs

User plane

BBP

UP Traffic CPUs

OAM plane

MPT

CP Mng CPUs

BBP

LBBP: CP Mng CPUs

UBBP: CP Mng CPUs and CP Traffic CPUs

For details about the CPU cores and CPU usage monitoring for MPT and BBP boards, see 6 CPU Core Deployment and CPU Usage Monitoring.

Control-Plane Flow Control

This chapter describes the objectives, principles, and monitoring methods of control-plane flow control.
MME Overloadtriggered Flow Control
3.1.1 Objective

The objective of MME overload-triggered flow control is to relieve the impact of MME overload caused by a large number of UEs requesting access to the network. MME overload-triggered flow control corresponds to load point 1 in Figure 2-1.
3.1.2 Principle

When an MME is overloaded, the MME sends an OVERLOAD START message to eNodeBs, instructing the eNodeBs to start flow control. The eNodeBs then limit the number of UEs accessing the network. When the MME is no longer overloaded, the MME sends an OVERLOAD STOP message to
the eNodeBs, instructing them to stop flow control. For details about MME overload-triggered flow control, see 3GPP TS 36.413 Release 9 or Release 10. Figure 3-1 shows the signaling exchange between an MME and an eNodeB in MME overload-triggered flow control.
Figure 3-1 MME overloadtriggered flow control

After receiving an OVERLOAD START message, the eNodeB processes access requests according to 3GPP TS 36.413 Release 9 or Release 10 as follows:
If the Overload Action IE in the Overload Response IE within the OVERLOAD START message is set to
-"reject RRC connection establishments for non-emergency mobile originated data transfer" (i.e., reject traffic corresponding to RRC cause "mo-data" and "delayTolerantAccess" in TS 36.331 [16]), or
-"reject RRC connection establishments for signalling" (i.e., reject traffic corresponding to RRC cause "mo-data", "mo-signalling" and "delayTolerantAccess" in TS 36.331 [16]), or
-"only permit RRC connection establishments for emergency sessions and mobile terminated services" (i.e., only permit traffic corresponding to RRC cause "emergency" and "mt-Access" in TS 36.331 [16]), or
-"only permit RRC connection establishments for high priority sessions and mobile terminated services" (i.e., only permit traffic corresponding to RRC cause "highPriorityAccess" and "mt-Access" in TS 36.331 [16]), or
-"reject only RRC connection establishment for delay tolerant access" (i.e., only reject traffic corresponding to RRC cause "delayTolerantAccess" in TS 36.331 [16]).
The eNodeB shall ensure that only signalling traffic corresponding to permitted RRC connections is sent to the MME.
3.1.3 Monitoring
Table 3-1 lists the counters related to MME overloadtriggered flow control. For details, see eNodeB Performance Counter Reference.

Table 3-1 Counters related to MME overloadtriggered flow control

Counter Name

Counter Description

L.RRC.ConnReq.Msg.disc.FlowCtrl

Number of times the RRC Connection Request message is discarded due to flow control

L.RRC.SetupFail.Rej.FlowCtrl

Number of times the eNodeB sends an RRC Connection Reject message to the UE due to flow control

L.HHO.PrepAttIn.disc.FlowCtrl

Number of times the HANDOVER REQUEST message is discarded over the S1 or X2 interface due to flow control (without returning a
preparation failure message)

L.HHO.Prep.FailIn.FlowCtrl

Number of times the target eNodeB sends a handover preparation failure message for an intra-duple-mode handover over the S1 or X2
interface to the source eNodeB due to flow control

Flow Control for Random Access Preamble

5 trong 13

3.2.1 Objective

Flow control on the Random Access Preamble messages is to protect an eNodeB from being overloaded due to the random access of a large number of UEs. A large number of UEs' access requests lead to high load and even reset of the eNodeB. Flow control on Random Access Preamble
corresponds to load point 5 shown in Figure 2-1.
3.2.2 Principle
3.2.2.1 Flow Control Points

The flow control point for the contention-based preambles is located on the CELLM module, which is marked 1 shown in Figure 3-2.
The eNodeB does not perform flow control on non-contention-based preambles.
Figure 3-2 Flow control points for Random Access Preamble

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

3.2.2.2 Flow Control Actions

Flow control on the Random Access Preamble message is implemented by controlling the number of preambles to be processed. The CELLM module adaptively adjusts the number of preambles to be processed based on the CPU usage of the BBP control plane. Table 3-2 provides the detailed flow
control actions.

Table 3-2 Flow control actions

CPU Usage (N)

Flow Control Action

N 95%

The eNodeB discards all preambles to prevent the BBP from breaking down.

85% N < 95%

The eNodeB adjusts the preamble processing capability to 100 times per second and discards additional preambles to prevent the BBP from breaking down.

80% N < 85%

The eNodeB adjusts the preamble processing capability to 300 times per second.

N < 80%

The eNodeB adjusts the preamble processing capability to 400 times per second.

3.2.3 Monitoring
Table 3-3 describes the counters related to flow control on Random Access Preamble messages. For details, see eNodeB Performance Counter Reference.

Table 3-3 Counters related to flow control on Random Access Preamble messages
Counter Name

Description

L.RA.GrpA.Att

Number of times the contention-based preamble in group A is received

L.RA.GrpA.Resp

Number of times a cell sends a Random Access Response message after receiving a preamble in group A

L.RA.GrpB.Att

Number of times the contention preamble in group B is received

L.RA.GrpB.Resp

Number of times a cell sends a Random Access Response message after receiving a preamble in group B

Initial Access Request Control

6 trong 13

3.3.1 Objective

The objective of initial access request control is to relieve the impact of eNodeB overload caused by a large number of UEs' access requests. A large number of UEs' access requests lead to heavy load and even causes the eNodeB to reset. Initial access request control corresponds to load points
5 and 6 in Figure 2-1.
3.3.2 Principle

Initial access requests include RRC connection requests, S1 handover requests, and X2 handover requests. An initial access request is the start of an access procedure. After an eNodeB accepts an initial access request, a lot of subsequent processing is required, causing numerous overheads.
Therefore, initial access request control can reduce the eNodeB load from the beginning.
To ensure high-priority services, initial access request control processes access requests based on priorities. Access requests with the following causes are prioritized in descending order:
1. Emergency
2. High priority
3. Handover
4. CS paging
5. PS paging
6. Mobile-terminated access
7. Mobile-originated signaling
8. Mobile-originated data
9. Delay Tolerant Access
When an eNodeB is overloaded, the eNodeB rejects or discards some initial access requests based on the CPU usage of the main control board or baseband board as follows:
When the CPU usage of the main control board or baseband board is equal to or greater than 80% and less than 90% (not configurable, with 5s as the smooth filtering value), and the CPU usage is increasing, the eNodeB starts initial access request control based on the priorities of initial
access requests. The eNodeB sends an RRC Connection Reject message to a UE if the eNodeB rejects the access request.
When the CPU usage of the main control board or baseband board is equal to or greater than 90%, the eNodeB discards initial access request messages of the rejected UEs to prevent a breakdown and the eNodeB does not send RRC Connection Reject messages to these UEs.
When the CPU usage of the main control board or baseband board drops to less than 80%, the eNodeB stops initial access request control based on the priorities of initial access requests.
When the CPU usage of the main control board or baseband board is equal to or greater than 80% and less than 90%, and the CPU usage is decreasing, the eNodeB sends an RRC Connection Reject, S1 HANDOVER FAILURE, or X2 HANDOVER FAILURE message to a UE if the
eNodeB rejects the access request. The RRC Connection Reject message contains the RRC Reject Wait time IE. For details, see 3.5 RRC Reject Wait time.
If the eNodeB load is heavy for a long time, the eNodeB controls the number of signaling messages received from peer NEs to reduce the load as follows:
The eNodeB decreases the SCTP buffer threshold to reduce the number of signaling messages sent from the MME to the eNodeB, thereby reducing the load in the downlink. For details, see SCTP Congestion Control Feature Parameter Description.
The eNodeB reduces the frequency of UEs' access to the network using Access Class (AC) Barring to reduce the load in the uplink. For details about AC Control, see 3.6 AC Control.
3.3.2.1 Flow Control Points

The RRC Connection Request and Handover Request messages have the same flow control points (located on the RRC processing module on the MPT control plane), which are marked 2 shown in Figure 3-3 and 1 shown in Figure 3-4.
As shown in Figure 3-3, there are two flow control points for the RRC Connection Request message. One is located on the MAC module of the BBP (marked 1), and the other is located on the RRC processing module on the MPT control plane (marked 2).
The flow control point for the Handover Request message is located on the RRC S1AP/X2AP module of the MPT. The S1 Handover Request and X2 Handover Request messages have the same flow control priority.
The flow control point for the RRC Connection Re-establishment Request message is also located on the RRC processing module on the MPT control plane, which is marked 1 shown in Figure 3-4.
Figure 3-3 Flow control points for the RRC Connection Request message

Figure 3-4 Flow control point for the Handover Request and RRC Connection Re-establishment Request messages

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

3.3.2.2 Flow Control Actions

Flow Control Actions on the BBP

The BBP performs the open loop flow control.
The MAC module of the BBP measures the number of RRC Connection Request messages received per second. If the number exceeds a predefined threshold, the BBP discards the exceeded messages and increases the L.RRC.ConnReq.Msg.disc.FlowCtrl counter value.
The purpose of limiting the number of RRC Connection Request messages on the BBP is to prevent excessive messages from being transferred to the MPT and consuming too much load processing capability of the eNodeB.
Table 3-4 lists the current message processing capabilities of different BBPs.

Table 3-4 Message processing capabilities of different BBPs

Board Type

Maximum Number of RRC Connection Request Messages That Can Be Processed

LBBPc

80 per second

LBBPd

150 per second

UBBPd3/d4

360 per second

UBBPd5/d6

410 per second

Flow Control Actions on the MPT

The MPT performs flow control for RRC Connection Request and Handover Request messages. Table 3-5 lists the current message processing capabilities of different MPTs.

Table 3-5 Message processing capabilities of different MPTs

Board Type

Maximum Number of RRC Connection Request and Handover Request Messages That Can Be Processed

LMPT

130 per second

UMPT

300 per second

The MPT also performs flow control for RRC Connection Re-establishment Request messages. Table 3-6 lists the current message processing capabilities of different MPTs.

Table 3-6 Message processing capabilities of different MPTs

Board Type

Maximum Number of RRC Connection Re-establishment Request Messages That Can Be Processed

LMPT

130 per second

UMPT

225 per second

The MPT performs flow control for RRC Connection Request and Handover Request messages based on CPU usage of the control plane and signaling message priorities. The following lists the message priorities in descending order:
RRC Connection Request for emergency services
RRC Connection Request for high-priority services
Handover Request
RRC Connection Request for mobile-terminated (MT) access
RRC Connection Request for mobile-originated (MO) signaling
RRC Connection Request MO data
RRC Connection Request for delay tolerant access
Table 3-7 lists the flow control actions on the MPT based on CPU usage.

Table 3-7 Flow control actions on the MPT based on CPU usage
CPU Usage (N)

Flow Control Action

N 90%

The MPT discards RRC Connection Request and Handover Request messages.

80% N < 90%

The MPT starts flow control and responds with an RRC Connection Reject or Handover Failure message for rejected UEs based on the priorities.

N < 80%

The MPT does not perform flow control on RRC Connection Request or Handover Request.

3.3.3 Monitoring

For details, see 3.1 MME Overloadtriggered Flow Control.

Paging Message Flow Control

7 trong 13

3.4.1 Objective

The objective of paging message flow control is to relieve the impact of eNodeB overload caused by a large number of paging messages. A large number of paging messages lead to heavy load and even causes the eNodeB to reset. Paging message flow control corresponds to load point 3 in
Figure 2-1 .
3.4.2 Principle

A paging message is the start of a procedure. A large number of successfully processed paging messages lead to a large number of UEs' access to the network and excessive signaling overheads on the eNodeB. Therefore, paging message flow control reduces the eNodeB load from the
beginning.
To guarantee the user experience for high-priority services, paging message flow control takes different actions to process paging messages with different causes. 3GPP Release 8, Release 9, and Release 10 define paging causes as follows:
According to 3GPP Release 8 and Release 9, the CN domain IE is used to distinguish CS and PS services. The following table describes the CN domain IE.

IE/Group Name

Presence

Range

IE type and reference

Semantics description

CN Domain

ENUMERATED(PS, CS)

According to 3GPP Release 10, the Paging Priority IE is used to distinguish between CS and PS services. According to 3GPP Release 10, an eNodeB determines the paging priorities of only CS fallback (CSFB) and IP multimedia subsystem enhanced multimedia priority service
(IMS-eMPS), which have high paging priorities to ensure user experience for CS services. Paging priorities of PS services need to be planned by operators and configured on the core network. The following table describes the Paging Priority IE.

IE/Group Name

Presence

Range

IE type and reference

Semantics description

Paging Priority

ENUMERATED (PrioLevel1, PrioLevel2, PrioLevel3, PrioLevel4, PrioLevel5,

PrioLevel6, PrioLevel7, PrioLevel8, )

Lower value code point indicates higher priority

3.4.2.1 Flow Control Points

As shown in Figure 3-5, there are two flow control points for paging messages. One is located on the S1AP module of the MPT (marked 1), and the other is located on the CELLM module of the BBP (marked 2).
Figure 3-5 Flow control points for paging messages

3.4.2.2 Flow Control Actions

Table 3-8 and Table 3-9 describe the flow control actions for paging messages on the MPT and BBP, respectively.

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

Table 3-8 Flow control actions for paging messages on the MPT
CPU Usage

Flow Control Action

85%

The MPT starts flow control and gradually decreases its paging message processing capability to the minimum value (150 times per second). If the number of paging messages to be processed exceeds the
processing capability, the MPT discards paging messages based on their priorities and discards paging messages for PS services first.

< 85%

The MPT does not perform flow control on paging messages and processes paging messages using the maximum processing capability.
Note:
Maximum number of paging messages processed by the LMPT per second: 1800
Maximum number of paging messages processed by the UMPT per second: 2400

Table 3-9 Flow control actions for paging messages on the BBP
CPU Usage

Flow Control Action

90%

The BBP discards paging messages.

< 90%

The BBP does not discard paging messages.

3.4.3 Monitoring
Table 3-10 describes the counters related to paging message flow control. For details, see eNodeB Performance Counter Reference.

Table 3-10 Counters related to paging message flow control

Counter Name

Description

L.Paging.S1.Rx

Number of received paging messages over the S1 interface in a cell

L.Paging.UU.Att

Number of UEs contained in paging messages transmitted over the Uu interface in a cell

L.Paging.UU.Succ

Number of successful paging responses from the UE in a cell

L.Paging.Dis.Num

Number of discarded paging messages from the MME to UEs

RRC Reject Wait time

3.5.1 Objective

The objective of sending the RRC Reject Wait time IE is to prevent signaling bursts caused by UEs' frequent access to the network. When an eNodeB rejects a UE's access request, the eNodeB includes the RRC Reject Wait time IE in the RRC Connection Reject message to inform the UE of the
wait time before the UE initiates another access request. The function of sending the RRC Reject Wait time IE corresponds to load point 5 in Figure 2-1 .
3.5.2 Principle

When an eNodeB is overloaded, the eNodeB includes the RRC Reject Wait time IE in the RRC Connection Reject message to inform the UE of the wait time before the UE initiates another access request. The UE processes the RRC Reject Wait time IE according to 3GPP TS 36.331. Figure 3-6
shows the signaling exchange between the eNodeB and UE.
Figure 3-6 Signaling exchange between the eNodeB and UE

When the CPU usage of the main control board or baseband board is equal to or greater than 80% (not configurable, with 5s as the smooth filtering value), the eNodeB starts initial access request control and includes the RRC Reject Wait time IE in the RRC Connection Reject message.
The value of the RRC Reject Wait time IE is configurable. You can run the MOD RRCCONNSTATETIMER command to set the RrcConnStateTimer.T302 parameter. For details, see eNodeB MML Command Reference.
3.5.3 Monitoring

For details, see 3.1 MME Overloadtriggered Flow Control.

AC Control
3.6.1 Objective

As defined in 3GPP TS 36.331, access class (AC) control is a method used to control the UE access to the network. The objective is to relieve the impact of eNodeB overload caused by a large number of UEs requesting access to the network. AC control corresponds to load point 5 in Figure 2-1.
3.6.2 Principle

With AC control, the eNodeB broadcasts AC control parameters to UEs in a cell through System Information Block 2 (SIB2) messages. UEs then determine whether they can access the cell based on the received AC control parameters. Figure 3-7 shows the signaling exchange between the eNodeB
and UE for AC control.
Figure 3-7 Signaling exchange between the eNodeB and UE for AC control

AC control can be classified in to static AC control and intelligent AC control:

Static AC control
With static AC control, after AC control parameters are configured on the OSS by an operator, the eNodeB broadcasts parameters to UEs through system information (SI) update, without considering the current network condition. The eNodeB implements static AC control on the
following objects:
Emergency
Mobile-originated data
Mobile-originated signaling
Multimedia telephony voice
Multimedia telephony video
CSFB
You can adjust the frequencies of UEs' access to the network by running the MOD CELLACBAR command on the eNodeB side and configuring the parameters CellAcBar.AcBarringFactorForCall, CellAcBar.AcBarringFactorForSig, CellAcBar.AcBarFactorForMVoice,
CellAcBar.AcBarFactorForMVideo, and CellAcBar.AcBarFactorForCsfb.
Intelligent AC control
With intelligent AC control, the eNodeB automatically triggers or cancels AC control by adjusting the mobile-originated signaling and mobile-originated data access frequencies based on the load of a cell. For details, see Access Class Control Feature Parameter Description.
3.6.3 Monitoring

For details, see 3.1 MME Overloadtriggered Flow Control.

Uplink Synchronized UE Number Control
3.7.1 Objective

The objective of uplink synchronized UE number control is to relieve the impact of eNodeB overload caused by too many uplink synchronized UEs in a short time in special scenarios such as festivals. Uplink synchronized UE number control corresponds to load point 5 in Figure 2-1.
3.7.2 Principle

When the number of UEs in a cell is too large, the eNodeB selects some uplink synchronized UEs that have not transmitted or received data for a period and changes the status of these UEs to out of synchronization. This releases physical uplink control channel (PUCCH) and sounding reference
signal (SRS) resources for UEs attempts to access or be handed over to the cell.
You can run the MOD ENODEBFLOWCTRLPARA command to set the eNodeBFlowCtrlPara.AdaptUnsyncUserNumThd and eNodeBFlowCtrlPara.AdaptUnsyncTimerLen parameters. The eNodeBFlowCtrlPara.AdaptUnsyncUserNumThd parameter indicates the number of uplink synchronized
UEs, and the eNodeBFlowCtrlPara.AdaptUnsyncTimerLen parameter indicates the duration in which no data is transmitted. For details, see eNodeB MML Command Reference.
3.7.3 Monitoring
Table 3-11 lists the counters related to uplink synchronized UE number control. For details, see eNodeB Performance Counter Reference.

Table 3-11 Counters related to uplink synchronized UE number control

Counter Name

Description

L.Traffic.User.Avg

Average number of users in a cell

L.Traffic.User.Max

Maximum number of users in a cell

L.Traffic.User.Ulsync.Avg

Average number of UL synchronized users in a cell

User-Plane Flow Control

This chapter describes the objectives, principles, and monitoring methods of user-plane flow control.
Downlink User-Plane Flow Control

8 trong 13

4.1.1 Objective

The objective of downlink user-plane flow control is to ensure eNodeB reliability when the amount of downlink user-plane data exceeds the eNodeB's processing capability. Downlink user-plane flow control corresponds to load points 4 and 6 in Figure 2-1.
4.1.2 Principle

Downlink user-plane flow control reduces the number of downlink packets, including packets carried by guaranteed bit rate (GBR) and non-GBR bearers. An eNodeB preferentially performs flow control on packets carried by non-GBR bearers. If congestion persists after the eNodeB has performed
flow control on all packets carried by non-GBR bearers, the eNodeB performs flow control on packets carried by GBR bearers until the eNodeB is no longer congested.
4.1.2.1 Flow Control Points
Figure 4-1 shows the flow control points for downlink user plane, which are marked 1 and 2.

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

Generally, the data processing capability of the TRAN module is not a bottleneck that affects traffic specifications. For details about the flow control mechanism of the TRAN module, see Transport Resource Management Feature Parameter Description.
The downlink protocol stack processing module (PDCP/RLC/MAC) becomes overloaded when the data volume on the user plane is excessively large. Therefore, downlink user plane flow control is performed based on the CPU usage of the user plane.
Figure 4-1 Flow control points for downlink user plane

The downlink open loop flow control is performed on the TRAN module of the MPT to ensure the total throughput for a BBP is below the 1.2 times the BBP peak throughput specifications. Additional data flows will be discarded. During closed-loop flow control, the BBP sends a flow control indicator
to the MPT based on its load, and the TRAN module of the MPT dynamically adjusts the data rate.
When the PDCP/MAC/RLC stack processing module is overloaded, the module sends a back pressure to the TRAN module to request a decrease in the data volume. On the contrary, the module sends a back pressure cancelation to TRAN module. The measurements are performed on a per
second basis. The following table lists the related CPU usage thresholds.
Board Type

UP Overload Threshold

UP Idle Threshold

LBBPc

90%

85%

LBBPd1/d2

80%

74%

LBBPd3

74%

68%

After receiving a back pressure indicator, the TRAN module decreases the downlink data volume to reduce the data load being processed by the BBP. After receiving a back pressure cancelation indicator, the TRAN module gradually restores the downlink data volume. The flow control algorithm
implements optimal matching between the data volume and the processing capability of the BBP.
4.1.2.2 Flow Control Actions

The TRAN module of the MPT performs flow control based on the back pressure indicator.
In the congestion state, the MPT decreases the allowed data volume by 10% based on the currently allowed volume at an interval of 10s. When receiving the back pressure indicator, the MPT does not discard data. Instead, it buffers the data that cannot be sent in time.
In the normal state, the MPT increases the allowed data volume by a semi-persistent increment based on the currently allowed volume. This increment increases twice at an interval of 10s.
The TRAN module decreases or increases the packet transmission rates of both GBR and non-GBR bearers. During the packet transmission rate decrease, the TRAN module preferentially decreases the packet transmission rate of non-GBR bearers. If the CPU usage of the BBP cannot be
released even when no packets on all non-GBR bearers are allowed to be delivered, the TRAN module decreases the packets on GBR bearers.
4.1.3 Monitoring
Table 4-1 describes the counters related to downlink user-plane flow control. For details, see eNodeB Performance Counter Reference.

Table 4-1 Counters related to downlink user-plane flow control

Counter Name

Description

L.PDCP.Tx.Disc.Trf.SDU.QCI.1

Number of downlink traffic SDUs discarded by the PDCP layer for services with the QCI of 1 in a cell

L.PDCP.Tx.Disc.Trf.SDU.QCI.2

Number of downlink traffic SDUs discarded by the PDCP layer for services with the QCI of 2 in a cell

L.PDCP.Tx.Disc.Trf.SDU.QCI.3

Number of downlink traffic SDUs discarded by the PDCP layer for services with the QCI of 3 in a cell

L.PDCP.Tx.Disc.Trf.SDU.QCI.4

Number of downlink traffic SDUs discarded by the PDCP layer for services with the QCI of 4 in a cell

L.PDCP.Tx.Disc.Trf.SDU.QCI.5

Number of downlink traffic SDUs discarded by the PDCP layer for services with the QCI of 5 in a cell

L.PDCP.Tx.Disc.Trf.SDU.QCI.6

Number of downlink traffic SDUs discarded by the PDCP layer for services with the QCI of 6 in a cell

L.PDCP.Tx.Disc.Trf.SDU.QCI.7

Number of downlink traffic SDUs discarded by the PDCP layer for services with the QCI of 7 in a cell

L.PDCP.Tx.Disc.Trf.SDU.QCI.8

Number of downlink traffic SDUs discarded by the PDCP layer for services with the QCI of 8 in a cell

L.PDCP.Tx.Disc.Trf.SDU.QCI.9

Number of downlink traffic SDUs discarded by the PDCP layer for services with the QCI of 9 in a cell

L.Traffic.Board.UPlane.CPULoad.MAX
L.Traffic.Board.UPlane.CPULoad.AVG

The usages of data processing CPUs are sampled every second and the maximum one is taken as the sampling result. The average of every five consecutive sampling
results is used as the filtered CPU usage.
The average of these filtered CPU usages is indicated by L.Traffic.Board.UPlane.CPULoad.AVG, and the maximum of these filleted CPU usages is indicated by
L.Traffic.Board.UPlane.CPULoad.MAX.

Uplink User-Plane Flow Control

For details about uplink user-plane flow control, seeTransport Resource Management Feature Parameter Description. Uplink user-plane flow control corresponds to load point 2 in Figure 2-1.
4.2.1 Objective

The objective of uplink user-plane flow control is to ensure the eNodeB reliability when the amount of uplink user-plane data exceeds the eNodeB processing capability.
4.2.2 Principle
4.2.2.1 Flow Control Points

Uplink user-plane flow control on the BBP is performed on the PDCP/RLC/MAC module based on the usage of UP Traffic CPUs, which is marked 1 in Figure 4-2. Uplink user-plane flow control on the MPT is performed on the TRAN module, which is marked 2 in Figure 4-2.
Figure 4-2 Flow control points for uplink user plane

Uplink user-plane flow control is performed based on the CPU usage of the protocol stack processing module and the buffered time of packets over the S1/X2 interface. The following table lists the CPU usage thresholds for the uplink user-plane flow control.
Board Type

UP Overload Threshold

UP Idle Threshold

LBBPc

95%

95%

LBBPd1/d2

82%

82%

LBBPd3

75%

75%

When the CPU usage of the user plane exceeds the overload threshold, the MAC scheduler reduces the total amount of uplink data that is allowed to be transmitted to the BBP over the Uu interface. In this way, UEs send less uplink data to the eNodeB, thereby reducing the CPU usage on the user
plane.
When the CPU usage of the user plane is lower than the idle threshold, the MAC scheduler increases the total amount of uplink data that is allowed to be transmitted to the BBP over the Uu interface.
When the buffered time of packets over the S1/X2 interface meets congestion or congestion cancelation conditions, the MPT sends the related congestion or congestion cancelation indicator to the BBP. The BBP then decreases or increases the maximum uplink data volume in UE level to accomplish
the flow control.
4.2.2.2 Flow Control Actions

Flow Control for the Overload on the PDCP/RLC/MAC Module of the BBP
As described in 4.2.2.1 Flow Control Points, PDCP/RLC/MAC flow control is based on CPU usage. The BBP monitors its overload state at an interval of 100 ms. If the BBP is overloaded, the BBP sends an indicator to instruct the uplink scheduler to decrease the maximum transport block size (TBS)
for the BBP by 1%. If the BBP is not overloaded, it sends an indicator to the uplink scheduler to increase the maximum TBS for the BBP by 1%.

Flow Control for S1/X2 Interface Congestion

9 trong 13

The back pressure algorithm is controlled by RSCGRPALG.TCSW. The algorithm takes effect only when the switch is turned on.

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

If the buffered time of packets over the S1/X2 interface is greater than the value of the congestion threshold parameter RSCGRPALG.CTTH , the MPT is overloaded, and sends a back pressure indicator to the BBP.
If the buffered time of packets over the S1/X2 interface is less than the value of RSCGRPALG.CCTTH , the MPT enters the idle state and sends a back pressure cancelation indicator to the BBP.
The uplink flow control algorithm for S1/X2 interface congestion is controlled by the UlUuFlowCtrlSwitch option of the ENODEBALGOSWITCH.TrmSwitch parameter. Uplink user-plane flow control for the MAC module of the BBP takes effect only when this option is turn on. When the uplink
transmission is congested, the MPT sends an indicator to the uplink scheduler to limit the uplink UE rate to resolve congestion. For details, see Transport Resource Management Feature Parameter Description.
In the congestion state, the BBP decreases the target TBS of UEs by 10%, and the uplink scheduler of the MAC performs related scheduling of the low data volume. At the same time, the BBP stops transmitting the data for all non-real-time services.
In the normal state, the BBP increases the target TBS of the UEs, and the uplink scheduler of the MAC performs related scheduling of the high data volume. At the same time, the BBP restarts the transmission of the data for all non-real-time services.
4.2.3 Monitoring

Whether uplink user-plane flow control is performed cannot be observed based on throughput-related counters because the throughput on the user plane is changed according to various factors. However, the counter of CPU usage of the BBP can be used to evaluate whether uplink user-plane flow
control is performed. For details, see eNodeB Performance Counter Reference.

Table 4-2 Counters related to uplink user-plane flow control

Counter Name

Description

L.Traffic.Board.UPlane.CPULoad.MAX
L.Traffic.Board.UPlane.CPULoad.AVG

The usages of data processing CPUs are sampled every second and the maximum one is taken as the sampling result. The average of every five consecutive sampling
results is used as the filtered CPU usage.
The average of these filtered CPU usages is indicated by L.Traffic.Board.UPlane.CPULoad.AVG, and the maximum of these filleted CPU usages is indicated by
L.Traffic.Board.UPlane.CPULoad.MAX.

OAM Flow Control

This chapter describes the objectives, principles, and monitoring methods of OAM flow control.
OAM includes software upgrades, file downloads and uploads, logs, MML commands, alarms, performance counters, and performance monitoring data. OAM requires a large amount of data transmission and CPU usage, which negatively impacts the control-plane and user-plane data transmission
during busy hours. The priorities of most OAM tasks are lower than those of control-plane and user-plane data transmission. OAM flow control releases CPU resources for control-plane and user-plane data transmission.
OAM Flow Control
5.1.1 Objective

The objective of OAM flow control is to prevent OAM tasks from occupying too many resources and negatively affecting control-plane and user-plane data transmission. OAM flow control corresponds to load points 7 and 8 in Figure 2-1.
5.1.2 Principle

When services are busy, an eNodeB performs flow control to tasks of log recording, software management, and performance monitoring based on service priorities to ensure that the key performance indicators (KPIs) are maintained.
The priorities of control-plane, user-plane, and OAM services are described as follows in descending order:
1. High-priority OAM tasks, including tasks related to MML commands, alarms, performance counters, and high-priority logs
2. Control-plane and user-plane data transmission
3. Medium-priority OAM tasks, including tasks related to medium-priority logs
4. Low-priority OAM tasks, including tasks related to low-priority logs, performance monitoring, and software download

NOTE:
High-, medium-, and low-priority logs are defined as follows:
High-priority log: including security, running, user operation, and statistics logs
Medium-priority log: call history record (CHR)
Low-priority log: debug log
When an eNodeB is overloaded, the eNodeB performs OAM flow control as follows:
The eNodeB does not perform flow control to high-priority OAM tasks.
When the CPU usage of the main control board or baseband board is equal to or greater than 70% (not configurable, with 5s as the smooth filtering value), the eNodeB rejects new performance monitoring tasks. The eNodeB also stops ongoing performance monitoring tasks.
The eNodeB stops log recording based on log priorities. When the CPU usage of the main control board or baseband board is equal to or greater than 70%, the eNodeB stops low-priority log recording. When the CPU usage of the main control board or baseband board is equal to or
greater than 80%, the eNodeB stops medium-priority log recording.
When the CPU usage of the main control board or baseband board is less than 70%, the eNodeB accepts new performance monitoring tasks.
When the CPU usage of the main control board or baseband board is less than 80%, the eNodeB restarts medium-priority log recording. Similarly, when the CPU usage of the main control board or baseband board is less than 70%, the eNodeB restarts low-priority log recording.
5.1.3 Monitoring

OAM flow control interrupts performance monitoring tasks and a message indicating that tasks are stopped because of flow control is displayed on the U2000.

CPU Core Deployment and CPU Usage Monitoring

This chapter describes the CPU core deployment and CPU usage monitoring for MPT and BBP boards.
LMPT
6.1.1 CPU Core Deployment

LMPT CPUs comprise of the following types:

CP Mng CPUs
The load of CP Mng CPUs is mainly caused by OAM, paging message processing, and SCTP message processing. Therefore, flow control on OAM and paging messages is performed based on the usage of CP Mng CPUs. Generally, usage of these CPUs is not related to the number of
UEs and traffic volumes. Therefore, no counters are designed for CP Mng CPUs usage reporting. However, the usage of CP Mng CPUs can be monitored on the U2000 or LMT.
CP Traffic CPUs
The loads of CP Traffic CPU are mainly caused by the signaling messages over the S1, Uu, and X2 interfaces. Flow control on RRC messages and handover messages is performed based on the usage of CP Traffic CPUs. Some counters are designed for them. For details about related
counters, see 6.1.2.1 Counters Related to the CPU Usage on the LMPT .
6.1.2 CPU Usage Monitoring
6.1.2.1 Counters Related to the CPU Usage on the LMPT

Counter Name

Description

VS.BBUBoard.CPULoad.Max

The usages of the CP Traffic CPUs are sampled every second and the maximum one is taken as the sampling result. The average of every five consecutive sampling results is used as the filtered
CPU usage.
The average of these filtered CPU usages is indicated by VS.BBUBoard.CPULoad.Mean, and the maximum of these filleted CPU usages is indicated by VS.BBUBoard.CPULoad.Max .

VS.BBUBoard.CPULoad.Mean

6.1.2.2 Alarm Related to CPU Overload on the LMPT

If the usage of any CPU among CP Traffic CPUs and CP Mng CPUs is greater than 90% in 30 consecutive seconds, the eNodeB reports ALM-26202 Board Overload.
6.1.2.3 CPU Usage Monitoring on the U2000 or LMT

The usage of CP Mng CPUs is reported. The reporting period can be configured to a value within the range of 5s to 30s on the U2000 or LMT.
UMPT
6.2.1 CPU Core Deployment

UMPT CPUs comprise of the following types:

CP Mng CPUs
CP Traffic CPUs
6.2.2 CPU Usage Monitoring
6.2.2.1 Counters Related to the CPU Usage on the UMPT

Counter Name

Description

VS.BBUBoard.CPULoad.Max

The usages of CP Traffic CPUs and CP Mng CPUs are sampled every second and the maximum one is taken as the sampling result. The average of every five consecutive sampling
results is used as the filtered CPU usage.
The average of these filtered CPU usages is indicated by VS.BBUBoard.CPULoad.Mean, and the maximum of these filleted CPU usages is indicated by VS.BBUBoard.CPULoad.Max .

VS.BBUBoard.CPULoad.Mean

6.2.2.2 Alarm Related to CPU Overload on the UMPT

If the usage of any CPU among CP Traffic CPUs and CP Mng CPUs is greater than 90% in 30 consecutive seconds, the eNodeB reports ALM-26202 Board Overload.
6.2.2.3 CPU Usage Monitoring on the U2000 or LMT

The Average usage of CP Mng CPUs and CP Traffic CPUs is reported. The reporting period can be configured to a value within the range of 5s to 30s on the U2000 or LMT.
LBBP
6.3.1 CPU Core Deployment

LBBP CPUs comprise of the following types:

CP Mng CPUs
UP Mng CPUs
These CPUs serve as resources pools to be scheduled between cells.
UP Traffic CPUs
These CPUs mainly serve as the resource pool for processing PDCP, RLC, and MAC. The CPU usage increases with the number of users and the load of services.
6.3.2 CPU Usage Monitoring
6.3.2.1 CPU Usage Counters

Counter Name

Description

VS.BBUBoard.CPULoad.Max

The usages of the CP Mng CPUs are sampled every second and the maximum one is taken as the sampling result. The average of every five consecutive sampling results is used as the filtered

10 trong 13

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

Counter Name

Description

VS.BBUBoard.CPULoad.Mean

CPU usage.
The average of these filtered CPU usages is indicated by VS.BBUBoard.CPULoad.Mean, and the maximum of these filleted CPU usages is indicated by VS.BBUBoard.CPULoad.Max .
The usages of the UP Traffic CPUs are sampled every second and the maximum one is taken as the sampling result. The average of every five consecutive sampling results is used as the filtered
CPU usage.
The average of these filtered CPU usages is indicated by L.Traffic.Board.UPlane.CPULoad.AVG, and the maximum of these filleted CPU usages is indicated by L.Traffic.Board.UPlane.CPULoad.MAX.

L.Traffic.Board.UPlane.CPULoad.MAX
L.Traffic.Board.UPlane.CPULoad.AVG

6.3.2.2 Alarm Related to CPU Overload on the LBBP

If the usage of any CPU among CP Traffic CPUs and CP Mng CPUs is greater than 90% in 30 consecutive seconds, the eNodeB reports ALM-26202 Board Overload.
6.3.2.3 CPU Usage Monitoring on the U2000 or LMT

The average CP Mng CPUs usage is taken as the result of CPU Usage Monitoring. The CPU usage reporting period can be set to 5s to 30s on the U2000 or LMT.
UBBP
6.4.1 CPU Core Deployment

UBBPd CPUs comprise of the following types:

CP Mng CPUs
CP Traffic CPUs
UP Mng CPUs
UP Traffic CPUs
6.4.2 CPU Usage Monitoring
6.4.2.1 CPU Usage Counters

Counter Name

Description

VS.BBUBoard.CPULoad.Max

The usages of CP Traffic CPUs and CP Mng CPUs are sampled every second and the maximum one is taken as the sampling result. The average of every five consecutive sampling results is
used as the filtered CPU usage.
The average of these filtered CPU usages is indicated by VS.BBUBoard.CPULoad.Mean, and the maximum of these filleted CPU usages is indicated by VS.BBUBoard.CPULoad.Max .

VS.BBUBoard.CPULoad.Mean

The usages of the UP Traffic CPUs are sampled every second and the maximum one is taken as the sampling result. The average of every five consecutive sampling results is used as the filtered
CPU usage.
The average of these filtered CPU usages is indicated by L.Traffic.Board.UPlane.CPULoad.AVG, and the maximum of these filleted CPU usages is indicated by L.Traffic.Board.UPlane.CPULoad.MAX.

L.Traffic.Board.UPlane.CPULoad.MAX
L.Traffic.Board.UPlane.CPULoad.AVG

6.4.2.2 Alarm Related to CPU Overload on the UBBP

When the average usage of CP Mng CPUs and CP Traffic CPUs exceeds 90% for 30 consecutive seconds, the eNodeB reports ALM-26202 Board Overload.
6.4.2.3 CPU Usage Monitoring on the U2000 or LMT

The average usage of CP Traffic CPUs and CP Mng CPUs is taken as the result of CPU Usage Monitoring. The CPU usage reporting period can be set to 5s to 30s on the U2000 or LMT.

Parameters

Table 7-1 Parameter description

MO

Parameter ID

MML Command

Feature ID

RrcConnStateTimer

T302

MOD
RRCCONNSTATETIMER
LST RRCCONNSTATETIMER

LBFD-002007 / TDLBFD- RRC Connection

002007
Management

Feature Name

Meaning: Indicates the length of timer T302. T302 specifies the time during which a UE whose RRC connection request is rejected has
to wait before the UE can initiate a request again. This timer is started when the UE receives an RRCConnectionReject message and
stopped when the UE enters the RRC_CONNECTED mode or performs cell reselection.
GUI Value Range: 1~16
Unit: s
Actual Value Range: 1~16
Default Value: 4

Description

CellAcBar

AcBarringFactorForCall

MOD CELLACBAR
LST CELLACBAR

LBFD-002009 / TDLBFD- Broadcast of system

002009
information

Meaning: Indicates the access probability factor for mobile-originated calls. A mobile-originated call is granted access if the random
number generated by the UE is less than this access probability factor; otherwise, the access request is rejected. According to 3GPP
TS 36.331, if any of the parameters AC11BarforCall, AC12BarforCall, AC13BarforCall, AC14BarforCall, and AC15BarforCall is set to
BOOLEAN_TRUE, the eNodeB sends UEs P00 as the access probability factor for mobile-originated calls in the system information
block type 2 (SIB2), regardless of the actual setting of the AcBarringFactorForCall parameter.
GUI Value Range: P00(0%), P05(5%), P10(10%), P15(15%), P20(20%), P25(25%), P30(30%), P40(40%), P50(50%), P60(60%),
P70(70%), P75(75%), P80(80%), P85(85%), P90(90%), P95(95%)
Unit: %
Actual Value Range: P00, P05, P10, P15, P20, P25, P30, P40, P50, P60, P70, P75, P80, P85, P90, P95
Default Value: P95(95%)

CellAcBar

AcBarringFactorForSig

MOD CELLACBAR
LST CELLACBAR

LBFD-002009 / TDLBFD- Broadcast of system

002009
information

Meaning: Indicates the access probability factor for signaling. Signaling from a UE is granted access if the random number generated
by the UE is less than this access probability factor; otherwise, the access request is rejected. According to 3GPP TS 36.331, if any of
the parameters AC11BarForSig, AC12BarForSig, AC13BarForSig, AC14BarForSig, and AC15BarForSig is set to BOOLEAN_TRUE,
the eNodeB sends UEs P00 as the access probability factor for signaling in the system information block type 2 (SIB2), regardless of
the actual setting of the AcBarringFactorForSig parameter.
GUI Value Range: P00(0%), P05(5%), P10(10%), P15(15%), P20(20%), P25(25%), P30(30%), P40(40%), P50(50%), P60(60%),
P70(70%), P75(75%), P80(80%), P85(85%), P90(90%), P95(95%)
Unit: %
Actual Value Range: P00, P05, P10, P15, P20, P25, P30, P40, P50, P60, P70, P75, P80, P85, P90, P95
Default Value: P95(95%)

CellAcBar

AcBarFactorForMVoice

MOD CELLACBAR
LST CELLACBAR

LBFD-002009 / TDLBFD- Broadcast of system

002009
information

Meaning: Indicates the access probability factor for multimedia telephony (MMTEL) voice services. An MMTEL voice service is
granted access if the random number generated by the UE is less than this access probability factor; otherwise, the access request is
barred.
GUI Value Range: P00(0%), P05(5%), P10(10%), P15(15%), P20(20%), P25(25%), P30(30%), P40(40%), P50(50%), P60(60%),
P70(70%), P75(75%), P80(80%), P85(85%), P90(90%), P95(95%)
Unit: %
Actual Value Range: P00, P05, P10, P15, P20, P25, P30, P40, P50, P60, P70, P75, P80, P85, P90, P95
Default Value: P95(95%)

CellAcBar

AcBarFactorForMVideo

MOD CELLACBAR
LST CELLACBAR

LBFD-002009 / TDLBFD- Broadcast of system

002009
information

Meaning: Indicates the access probability factor for multimedia telephony (MMTEL) video services. An MMTEL video service is
granted access if the random number generated by the UE is less than this access probability factor; otherwise, the access request is
barred.
GUI Value Range: P00(0%), P05(5%), P10(10%), P15(15%), P20(20%), P25(25%), P30(30%), P40(40%), P50(50%), P60(60%),
P70(70%), P75(75%), P80(80%), P85(85%), P90(90%), P95(95%)
Unit: %
Actual Value Range: P00, P05, P10, P15, P20, P25, P30, P40, P50, P60, P70, P75, P80, P85, P90, P95
Default Value: P95(95%)

CellAcBar

AcBarFactorForCsfb

MOD CELLACBAR
LST CELLACBAR

LBFD-002009 / TDLBFD- Broadcast of system

002009
information

Meaning: Indicates the access probability factor for CS fallback (CSFB) services. If the random number generated by a UE is less than
the parameter value, the eNodeB accepts the CSFB service access request; otherwise, the eNodeB rejects the access request.
GUI Value Range: P00(0%), P05(5%), P10(10%), P15(15%), P20(20%), P25(25%), P30(30%), P40(40%), P50(50%), P60(60%),
P70(70%), P75(75%), P80(80%), P85(85%), P90(90%), P95(95%)
Unit: %
Actual Value Range: P00, P05, P10, P15, P20, P25, P30, P40, P50, P60, P70, P75, P80, P85, P90, P95
Default Value: P95(95%)

eNodeBFlowCtrlPara

AdaptUnsyncUserNumThd

MOD
ENODEBFLOWCTRLPARA
LST
ENODEBFLOWCTRLPARA

None

None

Meaning: Indicates the threshold of the ratio of uplink-synchronized UEs in a cell or a baseband processing unit. If the ratio of uplinksynchronized UEs in a cell or a baseband processing unit exceeds this threshold, the eNodeB adaptively enables some UEs that do not
transmit or receive data for a period of time greater than the AdaptUnsyncTimerLen parameter value to enter the asynchronization
state. As a result, PUCCH resources can be released and used by other UEs.
GUI Value Range: 50~100
Unit: %
Actual Value Range: 50~100
Default Value: 100

eNodeBFlowCtrlPara

AdaptUnsyncTimerLen

MOD
ENODEBFLOWCTRLPARA
LST
ENODEBFLOWCTRLPARA

None

None

Meaning: Indicates whether an adaptive asynchronization UE is selected when the adaptive asynchronization function is enabled. If a
UE does not transmit or receive data for a period of time that is longer than the AdaptUnsyncTimerLen parameter value, the UE is a
candidate adaptive asynchronization UE. When this parameter value is larger than or equal to the UeInactiveTimer parameter value, the
adaptive asynchronization function does not take effect.
GUI Value Range: 1~20
Unit: s
Actual Value Range: 1~20
Default Value: 4

Counters

Table 8-1 Counter description

Counter ID

Counter Name

Counter Description

Feature ID

Feature Name

1526726833

L.PDCP.Tx.Disc.Trf.SDU.QCI.1

Number of downlink PDCP SDUs discarded for

services carried on DRBs with a QCI of 1 in a cell

Multi-mode: None
GSM: None

Radio Bearer Management

Radio Bearer Management

11 trong 13

5/19/2015 6:28 PM

HEEX Startpage

Counter ID

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

Counter Name

Counter Description

Feature ID

Feature Name

UMTS: None
LTE: LBFD-002008
TDLBFD-002008
LBFD-002025
TDLBFD-002025

Basic Scheduling
Basic Scheduling

1526726839

L.PDCP.Tx.Disc.Trf.SDU.QCI.2

Number of downlink PDCP SDUs discarded for

services carried on DRBs with a QCI of 2 in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002008
TDLBFD-002008
LBFD-002025
TDLBFD-002025

Radio Bearer Management

Radio Bearer Management
Basic Scheduling
Basic Scheduling

1526726845

L.PDCP.Tx.Disc.Trf.SDU.QCI.3

Number of downlink PDCP SDUs discarded for

services carried on DRBs with a QCI of 3 in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002008
TDLBFD-002008
LBFD-002025
TDLBFD-002025

Radio Bearer Management

Radio Bearer Management
Basic Scheduling
Basic Scheduling

1526726851

L.PDCP.Tx.Disc.Trf.SDU.QCI.4

Number of downlink PDCP SDUs discarded for

services carried on DRBs with a QCI of 4 in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002008
TDLBFD-002008
LBFD-002025
TDLBFD-002025

Radio Bearer Management

Radio Bearer Management
Basic Scheduling
Basic Scheduling

1526726857

L.PDCP.Tx.Disc.Trf.SDU.QCI.5

Number of downlink PDCP SDUs discarded for

services carried on DRBs with a QCI of 5 in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002008
TDLBFD-002008
LBFD-002025
TDLBFD-002025

Radio Bearer Management

Radio Bearer Management
Basic Scheduling
Basic Scheduling

1526726863

L.PDCP.Tx.Disc.Trf.SDU.QCI.6

Number of downlink PDCP SDUs discarded for

services carried on DRBs with a QCI of 6 in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002008
TDLBFD-002008
LBFD-002025
TDLBFD-002025

Radio Bearer Management

Radio Bearer Management
Basic Scheduling
Basic Scheduling

1526726869

L.PDCP.Tx.Disc.Trf.SDU.QCI.7

Number of downlink PDCP SDUs discarded for

services carried on DRBs with a QCI of 7 in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002008
TDLBFD-002008
LBFD-002025
TDLBFD-002025

Radio Bearer Management

Radio Bearer Management
Basic Scheduling
Basic Scheduling

1526726875

L.PDCP.Tx.Disc.Trf.SDU.QCI.8

Number of downlink PDCP SDUs discarded for

services carried on DRBs with a QCI of 8 in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002008
TDLBFD-002008
LBFD-002025
TDLBFD-002025

Radio Bearer Management

Radio Bearer Management
Basic Scheduling
Basic Scheduling

1526726881

L.PDCP.Tx.Disc.Trf.SDU.QCI.9

Number of downlink PDCP SDUs discarded for

services carried on DRBs with a QCI of 9 in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002008
TDLBFD-002008
LBFD-002025
TDLBFD-002025

Radio Bearer Management

Radio Bearer Management
Basic Scheduling
Basic Scheduling

1526726884

L.Paging.S1.Rx

Number of received paging messages over the S1

interface in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002011
TDLBFD-002011

Paging
Paging

1526726885

L.Paging.UU.Att

Number of UEs contained in paging messages

transmitted over the Uu interface in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002011
TDLBFD-002011

Paging
Paging

1526726886

L.Paging.UU.Succ

Number of Successful Paging Responses from the

UE in a Cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002011
TDLBFD-002011

Paging
Paging

1526727212

L.Paging.Dis.Num

Number of discarded paging messages from the

MME to UEs

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002011
TDLBFD-002011

Paging
Paging

1526727215

L.RA.GrpA.Att

Number of times the contention preamble in group A

is received

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002010
TDLBFD-002010

Random Access Procedure

Random Access Procedure

1526727216

L.RA.GrpA.Resp

Number of times a cell sends a Random Access

Response message after receiving a preamble in
group A

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002010
TDLBFD-002010

Random Access Procedure

Random Access Procedure

1526727218

L.RA.GrpB.Att

Number of times the contention preamble in group B

is received

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002010
TDLBFD-002010

Random Access Procedure

Random Access Procedure

1526727219

L.RA.GrpB.Resp

Number of times a cell sends a Random Access

Response message after receiving a preamble in
group B

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002010
TDLBFD-002010

Random Access Procedure

Random Access Procedure

1526727379

L.Traffic.User.Max

Maximum number of users in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002007
TDLBFD-002007

RRC Connection Management

RRC Connection Management

1526728333

L.Traffic.User.Ulsync.Avg

Average number of UL synchronized users in a cell

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002007
TDLBFD-002007

RRC Connection Management

RRC Connection Management

1526728489

L.RRC.ConnReq.Msg.disc.FlowCtrl

Number of times the RRC Connection Request

message is discarded due to flow control

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002007
TDLBFD-002007

RRC Connection Management

RRC Connection Management

12 trong 13

5/19/2015 6:28 PM

HEEX Startpage

file:///C:/Users/tuyennd1483/Desktop/eRAN Feature Documentation ...

Counter ID

Counter Name

Counter Description

Feature ID

Feature Name

1526728490

L.RRC.SetupFail.Rej.FlowCtrl

Number of times the eNodeB sends an RRC

Connection Reject message to the UE due to flow
control

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-002007
TDLBFD-002007

RRC Connection Management

RRC Connection Management

1526728491

L.HHO.PrepAttIn.disc.FlowCtrl

Number of times the HANDOVER REQUEST

message is discarded over the S1 or X2 interface
because of flow control (without returning a
preparation failure message)

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-00201801
LBFD-00201802
TDLBFD-00201801
TDLBFD-00201802

Coverage Based Intra-frequency Handover

Coverage Based Inter-frequency Handover
Coverage Based Intra-frequency Handover
Coverage Based Inter-frequency Handover

1526728492

L.HHO.Prep.FailIn.FlowCtrl

Number of times that the target eNodeB sends a

handover preparation failure message for an intraduple-mode handover over the S1 or X2 interface to
the source eNodeB because of flow control

Multi-mode: None
GSM: None
UMTS: None
LTE: LBFD-00201801
LBFD-00201802
TDLBFD-00201801
TDLBFD-00201802

Coverage Based Intra-frequency Handover

Coverage Based Inter-frequency Handover
Coverage Based Intra-frequency Handover
Coverage Based Inter-frequency Handover

1526737817

L.Traffic.Board.UPlane.CPULoad.AVG

Average control-plane CPU usage of a board in an

eNodeB

None

None

1526737818

L.Traffic.Board.UPlane.CPULoad.MAX

Maximum control-plane CPU usage of a board in an

eNodeB

None

None

Glossary

For the acronyms, abbreviations, terms, and definitions, see Glossary.

10

13 trong 13

Reference Documents

1. 3GPP TS 36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)"
2. 3GPP TS 36.331, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification"
3. Transport Resource Management Feature Parameter Description
4. SCTP Congestion Control Feature Parameter Description

5/19/2015 6:28 PM