HEEX Startpage.pdf

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.

NoticeThe 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: [email protected]

3.6.3 Contents

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



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

1 trong 13 5/19/2015 6:28 PM

3.3.3 Monitoring

3.4 Paging Message Flow Control

3.4.1 Objective

3.4.2 Principle



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.3 Monitoring

4.2 Uplink User-Plane Flow Control

4.2.1 Objective

4.2.2 Principle



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.2.1 Counters Related to the CPU Usage on the UMPT

6.2.2.2 Alarm Related to CPU Overload on the UMPT


6.3 LBBP



6.3.2.1 CPU Usage Counters

6.3.2.2 Alarm Related to CPU Overload on the LBBP


6.4 UBBP




6.4.2.2 Alarm Related to CPU Overload on the UBBP


7 Parameters

8 Counters

9 Glossary

10 Reference Documents

1 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







4.2.1 Objective

4.2.2 Principle

4.2.3 Monitoring

6 CPU Core Deployment and CPU Usage Monitoring

Added the following parameters:

RSCGRPALG.TCSW

RSCGRPALG.CTTH

RSCGRPALG.CCTTH

-

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

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


2 trong 13 5/19/2015 6:28 PM

2 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.

User-plane data flow 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.

OAM data flow 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.

This document describes flow control at the preceding eight load points.

Basic Principles of Flow Control

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


3 trong 13 5/19/2015 6:28 PM

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

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 controldoes 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.


4 trong 13 5/19/2015 6:28 PM

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


Control plane: RRC Connection Request/RRC Connection Re-establishment Request/HandoverRequest

MPT CP Traffic CPUs

User plane BBP UP Traffic CPUs

OAM plane MPT CP Mng CPUs

BBP LBBP: CP Mng 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.

3 Control-Plane Flow ControlThis 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 tothe 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 apreparation 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 X2interface to the source eNodeB due to flow control

Flow Control for Random Access Preamble

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 Preamblecorresponds to load point 5 shown in Figure 2-1.

3.2.2 Principle


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 trong 13 5/19/2015 6:28 PM


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 flowcontrol 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

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 points5 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:

Emergency1.

High priority2.

Handover3.

CS paging4.

PS paging5.

Mobile-terminated access6.

Mobile-originated signaling7.

Mobile-originated data8.

Delay Tolerant Access9.

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 initialaccess 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 theeNodeB 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.


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


6 trong 13 5/19/2015 6:28 PM


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

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 inFigure 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 thebeginning.

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 M - 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 M - ENUMERATED (PrioLevel1, PrioLevel2, PrioLevel3, PrioLevel4, PrioLevel5,PrioLevel6, PrioLevel7, PrioLevel8, )

Lower value code point indicates higher priority


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


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


7 trong 13 5/19/2015 6:28 PM

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 theprocessing 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


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 thewait 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-6shows 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


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 eNodeBand 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 thefollowing 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


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 referencesignal (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 synchronizedUEs, 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


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

4 User-Plane Flow ControlThis chapter describes the objectives, principles, and monitoring methods of user-plane flow control.

Downlink User-Plane Flow Control

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 performedflow 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.


Figure 4-1 shows the flow control points for downlink user plane, which are marked 1 and 2.


8 trong 13 5/19/2015 6:28 PM

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 indicatorto 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 persecond 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 algorithmimplements optimal matching between the data volume and the processing capability of the BBP.


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 bereleased 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


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.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 samplingresults 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 byL.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


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 userplane.

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 accomplishthe flow control.


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

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


9 trong 13 5/19/2015 6:28 PM

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 uplinktransmission 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 flowcontrol is performed. For details, see eNodeB Performance Counter Reference.

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


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 samplingresults 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 byL.Traffic.Board.UPlane.CPULoad.MAX.

5 OAM Flow ControlThis 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 transmissionduring 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:

High-priority OAM tasks, including tasks related to MML commands, alarms, performance counters, and high-priority logs1.

Control-plane and user-plane data transmission2.

Medium-priority OAM tasks, including tasks related to medium-priority logs3.

Low-priority OAM tasks, including tasks related to low-priority logs, performance monitoring, and software download4.

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 orgreater 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.

6 CPU Core Deployment and CPU Usage MonitoringThis chapter describes the CPU core deployment and CPU usage monitoring for MPT and BBP boards.

LMPT


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 ofUEs 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 relatedcounters, see 6.1.2.1 Counters Related to the CPU Usage on the LMPT.


6.1.2.1 Counters Related to the CPU Usage on the LMPT


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 filteredCPU 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.


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


UMPT CPUs comprise of the following types:

CP Mng CPUs

CP Traffic CPUs


6.2.2.1 Counters Related to the CPU Usage on the UMPT


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 samplingresults is used as the filtered CPU usage.


6.2.2.2 Alarm Related to CPU Overload on the UMPT



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


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.




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


CPU usage.


L.Traffic.Board.UPlane.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 filteredCPU 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.AVG

6.3.2.2 Alarm Related to CPU Overload on the LBBP



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


UBBPd CPUs comprise of the following types:

CP Mng CPUs

CP Traffic CPUs

UP Mng CPUs

UP Traffic CPUs




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 isused as the filtered CPU usage.


L.Traffic.Board.UPlane.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 filteredCPU 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.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.


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.

7 ParametersTable 7-1 Parameter description

MO Parameter ID MML Command Feature ID Feature Name Description

RrcConnStateTimer T302 MODRRCCONNSTATETIMER

LST RRCCONNSTATETIMER

LBFD-002007 / TDLBFD-002007

RRC ConnectionManagement

Meaning: Indicates the length of timer T302. T302 specifies the time during which a UE whose RRC connection request is rejected hasto wait before the UE can initiate a request again. This timer is started when the UE receives an RRCConnectionReject message andstopped 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

CellAcBar AcBarringFactorForCall MOD CELLACBARLST CELLACBAR

LBFD-002009 / TDLBFD-002009

Broadcast of systeminformation

Meaning: Indicates the access probability factor for mobile-originated calls. A mobile-originated call is granted access if the randomnumber generated by the UE is less than this access probability factor; otherwise, the access request is rejected. According to 3GPPTS 36.331, if any of the parameters AC11BarforCall, AC12BarforCall, AC13BarforCall, AC14BarforCall, and AC15BarforCall is set toBOOLEAN_TRUE, the eNodeB sends UEs P00 as the access probability factor for mobile-originated calls in the system informationblock 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 CELLACBARLST CELLACBAR

LBFD-002009 / TDLBFD-002009


Meaning: Indicates the access probability factor for signaling. Signaling from a UE is granted access if the random number generatedby the UE is less than this access probability factor; otherwise, the access request is rejected. According to 3GPP TS 36.331, if any ofthe 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 ofthe actual setting of the AcBarringFactorForSig parameter.


Unit: %



CellAcBar AcBarFactorForMVoice MOD CELLACBARLST CELLACBAR

LBFD-002009 / TDLBFD-002009


Meaning: Indicates the access probability factor for multimedia telephony (MMTEL) voice services. An MMTEL voice service isgranted access if the random number generated by the UE is less than this access probability factor; otherwise, the access request isbarred.


Unit: %



CellAcBar AcBarFactorForMVideo MOD CELLACBARLST CELLACBAR

LBFD-002009 / TDLBFD-002009


Meaning: Indicates the access probability factor for multimedia telephony (MMTEL) video services. An MMTEL video service isgranted access if the random number generated by the UE is less than this access probability factor; otherwise, the access request isbarred.


Unit: %



CellAcBar AcBarFactorForCsfb MOD CELLACBARLST CELLACBAR

LBFD-002009 / TDLBFD-002009


Meaning: Indicates the access probability factor for CS fallback (CSFB) services. If the random number generated by a UE is less thanthe parameter value, the eNodeB accepts the CSFB service access request; otherwise, the eNodeB rejects the access request.


Unit: %



eNodeBFlowCtrlPara AdaptUnsyncUserNumThd MODENODEBFLOWCTRLPARA

LSTENODEBFLOWCTRLPARA

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 uplink-synchronized UEs in a cell or a baseband processing unit exceeds this threshold, the eNodeB adaptively enables some UEs that do nottransmit or receive data for a period of time greater than the AdaptUnsyncTimerLen parameter value to enter the asynchronizationstate. As a result, PUCCH resources can be released and used by other UEs.


Unit: %


Default Value: 100

eNodeBFlowCtrlPara AdaptUnsyncTimerLen MODENODEBFLOWCTRLPARA

LSTENODEBFLOWCTRLPARA

None None Meaning: Indicates whether an adaptive asynchronization UE is selected when the adaptive asynchronization function is enabled. If aUE does not transmit or receive data for a period of time that is longer than the AdaptUnsyncTimerLen parameter value, the UE is acandidate adaptive asynchronization UE. When this parameter value is larger than or equal to the UeInactiveTimer parameter value, theadaptive asynchronization function does not take effect.


Unit: s


Default Value: 4

8 CountersTable 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 forservices carried on DRBs with a QCI of 1 in a cell

Multi-mode: None

GSM: None

Radio Bearer Management



11 trong 13 5/19/2015 6:28 PM


UMTS: None

LTE: LBFD-002008

TDLBFD-002008

LBFD-002025

TDLBFD-002025

Basic Scheduling

Basic Scheduling


Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002008

TDLBFD-002008

LBFD-002025

TDLBFD-002025



Basic Scheduling

Basic Scheduling


Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002008

TDLBFD-002008

LBFD-002025

TDLBFD-002025



Basic Scheduling

Basic Scheduling


Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002008

TDLBFD-002008

LBFD-002025

TDLBFD-002025



Basic Scheduling

Basic Scheduling


Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002008

TDLBFD-002008

LBFD-002025

TDLBFD-002025



Basic Scheduling

Basic Scheduling


Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002008

TDLBFD-002008

LBFD-002025

TDLBFD-002025



Basic Scheduling

Basic Scheduling


Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002008

TDLBFD-002008

LBFD-002025

TDLBFD-002025



Basic Scheduling

Basic Scheduling


Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002008

TDLBFD-002008

LBFD-002025

TDLBFD-002025



Basic Scheduling

Basic Scheduling


Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002008

TDLBFD-002008

LBFD-002025

TDLBFD-002025



Basic Scheduling

Basic Scheduling

1526726884 L.Paging.S1.Rx Number of received paging messages over the S1interface 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 messagestransmitted 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 theUE 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 theMME 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 Ais received

Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002010

TDLBFD-002010

Random Access Procedure


1526727216 L.RA.GrpA.Resp Number of times a cell sends a Random AccessResponse message after receiving a preamble ingroup A

Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002010

TDLBFD-002010



1526727218 L.RA.GrpB.Att Number of times the contention preamble in group Bis received

Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002010

TDLBFD-002010



1526727219 L.RA.GrpB.Resp Number of times a cell sends a Random AccessResponse message after receiving a preamble ingroup B

Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002010

TDLBFD-002010



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


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



1526728489 L.RRC.ConnReq.Msg.disc.FlowCtrl Number of times the RRC Connection Requestmessage is discarded due to flow control

Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002007

TDLBFD-002007




12 trong 13 5/19/2015 6:28 PM


1526728490 L.RRC.SetupFail.Rej.FlowCtrl Number of times the eNodeB sends an RRCConnection Reject message to the UE due to flowcontrol

Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-002007

TDLBFD-002007



1526728491 L.HHO.PrepAttIn.disc.FlowCtrl Number of times the HANDOVER REQUESTmessage is discarded over the S1 or X2 interfacebecause of flow control (without returning apreparation 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



1526728492 L.HHO.Prep.FailIn.FlowCtrl Number of times that the target eNodeB sends ahandover preparation failure message for an intra-duple-mode handover over the S1 or X2 interface tothe source eNodeB because of flow control

Multi-mode: None

GSM: None

UMTS: None

LTE: LBFD-00201801

LBFD-00201802

TDLBFD-00201801

TDLBFD-00201802





1526737817 L.Traffic.Board.UPlane.CPULoad.AVG Average control-plane CPU usage of a board in aneNodeB

None None

1526737818 L.Traffic.Board.UPlane.CPULoad.MAX Maximum control-plane CPU usage of a board in aneNodeB

None None

9 GlossaryFor the acronyms, abbreviations, terms, and definitions, see Glossary.

10 Reference Documents3GPP TS 36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)"1.

3GPP TS 36.331, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification"2.

Transport Resource Management Feature Parameter Description3.

SCTP Congestion Control Feature Parameter Description4.


13 trong 13 5/19/2015 6:28 PM

Date post:	17-Dec-2015
Category:	Documents
Upload:	radio
View:	22 times
Download:	6 times