Beruflich Dokumente
Kultur Dokumente
Contents
3.2.8 Connection Management
3.2.28 QoS Management
eRAN
Connection Management Feature Parameter
Description
Issue 03
Date 2015-06-20
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.
Website: http://www.huawei.com/
Email: support@huawei.com
3.2.8 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 Architecture
2.3.1 Random Access
2.3.2 Signaling Connection Management
2.3.3 Radio Bearer Management
3 Related Concepts
3.1 Tracking Area
3.2 Access Stratum States
3.3 Non-Access Stratum States
3.4 Call Types in the Non-Access Stratum
6 Related Features
6.1 Features Related to LBFD-002007 RRC Connection Management
6.2 Features Related to LBFD-002008 Radio Bearer Management
6.3 Features Related to LBFD-002010 Random Access Procedure
7 Network Impact
7.1 LBFD-002007 RRC Connection Management
7.2 LBFD-002008 Radio Bearer Management
7.3 LBFD-002010 Random Access Procedure
8 Engineering Guidelines
8.1 When to Use Connection Management
8.2 Required Information
8.3 Planning
8.4 Deployment
8.4.1 Process
8.4.2 Requirements
8.4.3 Data Preparation
8.4.4 Precautions
8.4.5 Initial Configuration
8.4.5.1 Using the CME to Perform Batch Configuration for Newly Deployed eNodeBs
8.4.5.2 Using the CME to Perform Batch Configuration for Existing eNodeBs
8.4.5.3 Using the CME to Perform Single Configuration
8.4.5.4 Using MML Commands
8.4.6 Activation Observation
8.4.7 Deactivation
8.4.7.1 Using the CME to Perform Batch Configuration
8.4.7.2 Using the CME to Perform Single Configuration
8.4.7.3 Using MML Commands
8.5 Performance Monitoring
8.6 Troubleshooting
9 Parameters
10 Counters
11 Glossary
12 Reference Documents
1.1 Scope
Micro BTS3202E
LampSite DBS3900
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 as well as the affected
entities
• Editorial change
Changes in wording or addition of information and any related parameters affected
by editorial changes. Editorial change does not specify the affected entities.
eRAN8.1 03 (2015-06-20)
eRAN8.1 02 (2015-04-30)
eRAN8.1 01 (2015-03-23)
Function Difference
UE release The UE release process varies with the base station types.
• A micro eNodeB detects whether the UE is attached to the
network after releasing the UE. A macro eNodeB does not
perform this action.
• A micro eNodeB attempts to restore the UE's uplink
synchronization before releasing the UE, and delays to
release the UE by a preset period of time.
For details, see 4.5 Signaling Connection Release.
2 Overview
2.1 Introduction
Connection management is a basic network feature and a prerequisite for enabling UEs to
access the network and perform services on established bearers.
2.3 Architecture
NOTE:
Security mode control as shown in Figure 2-1 is not described in this document. For details, see Radio
Security Feature Parameter Description.
Random access in LTE is the only way for a UE to set up or restore uplink
synchronization with an eNodeB. Random access is classified into contention-based and
non-contention-based random access:
• In contention-based random access, the access may fail because a random access
channel (RACH) may not be allocated to the UE.
• In non-contention-based random access, the eNodeB allocates a dedicated RACH to
the UE to ensure successful access. If dedicated RACHs are insufficient, the
eNodeB has to instruct the UE to initiate contention-based random access.
For details about random access, see Random Access Control and RACH Optimization Feature
Parameter Description.
An evolved packet system (EPS) bearer carries traffic with the same QoS class between a
UE and a Packet Data Network Gateway (P-GW). An EPS bearer consists of an RB, S1
bearer, and S5/S8 bearer. As shown in Figure 2-2, bearers related to the eNodeB in EPS
bearers include RBs and S1 bearers. An RB is set up between the UE and the eNodeB,
and an S1 bearer is set up between the eNodeB and the serving gateway (S-GW).
Figure 2-2 RBs in the end-to-end service
RBs are classified into signaling radio bearers (SRBs) and data radio bearers (DRBs)
according to carried information.
• SRBs carry signaling in the control plane. There are three types of SRBs:
▪ SRB0
SRB0 carries RRC signaling through a common control channel (CCCH) in
transparent mode (TM) at the radio link control (RLC) layer before the RRC
connection is successfully set up.
▪ SRB1
SRB1 carries RRC signaling messages after the RRC connection is successfully
set up, and carries pre-SRB2-setup non-access stratum (NAS) messages. SRB1
is transmitted through a dedicated control channel (DCCH) in acknowledged
mode (AM) at the RLC layer. For details about NAS, see 3.3 Non-Access Stratum
States and 3.4 Call Types in the Non-Access Stratum.
▪ SRB2
SRB2 carries NAS signaling through a DCCH in AM at the RLC layer. SRB2
has a lower priority than SRB1, and SRB2 can be set up only after the security
mode is activated.
• DRBs carry data in the user plane. A maximum of eight DRBs can be set up
between the UE and the eNodeB. The actual number depends on different QoS
classes.
For details about signaling messages carried by SRB0, SRB1, and SRB2, see chapter
6.2.2 in 3GPP TS 36.331 V9.16.0.
RB management indicates that the eNodeB sets up and modifies SRB2 bearers, and sets
up, modifies, and releases DRBs in secure mode as shown in Figure 2-1. For details, see 5
Radio Bearer Management.
3 Related Concepts
Tracking areas (TAs) are introduced in LTE for UE location management. Each TA is
identified by a tracking area identity (TAI), which consists of a mobile country code
(MCC), mobile network code (MNC), and tracking area code (TAC).
The MME allocates a tracking area list (TAL) consisting of multiple TAs to a UE when
the UE attaches to the network. After the network attach, no TA update is required when
the UE moves between the TAs, thereby reducing location update signaling used for TA
updates. When the UE moves into a TA not belonging to the TAL allocated by the MME,
the MME allocates a new TAL to the UE for a TA update. The newly allocated TAL may
include some of the TAs belonging to the original TAL.
Each cell of an eNodeB belongs to only one TA. TA information that is broadcast in a
cell is related to only the TA of this cell. A paging message for a UE is sent by the MME
to all the cells within the TAL to which this UE belongs.
3.2 Access Stratum States
An access stratum (AS) state is a connection state at the RRC layer between a UE and an
eNodeB. AS states are classified into RRC_IDLE and RRC_CONNECTED states:
• When a UE is in the RRC_IDLE state, the eNodeB does not have the UE context
and no signaling connection is set up between the eNodeB and UE. In the
RRC_IDLE state, the UE can receive system information (SI) and paging messages
for cell selections and reselections. When the UE needs to set up a signaling
connection with the eNodeB for service initiation, location update, paging, or other
purposes, it initiates RRC connection setup. After an RRC connection is set up, the
UE enters the RRC_CONNECTED state. For details about UE behaviors in the
RRC_IDLE state, see Idle Mode Management Feature Parameter Description.
• When a UE is in the RRC_CONNECTED state, the eNodeB has the UE context and
a signaling connection has been set up between the eNodeB and UE. In the
RRC_CONNECTED state, the UE can receive system messages and the messages
used to control data transmissions, handovers, and scheduling of the UE. The
eNodeB can receive information such as channel quality feedback provided by the
UE.
3.3 Non-Access Stratum States
An NAS state is a connection state between a UE and an MME. Based on UE registration
states and states of dedicated S1 connections, NAS states are classified into the following
four states:
• EMM-DEREGISTERED
EMM stands for EPS mobility management.
When a UE is in the EMM-DEREGISTERED state, the MME does not have the UE
context or location information; in addition, it cannot provide services to the UE. A
powered-off UE is in the EMM-DEREGISTERED state.
• EMM-REGISTERED
When a UE is in the EMM-REGISTERED state, the MME creates and stores the UE
context and can provide services to the UE. In this state, the MME and UE maintain
the TAL information about this UE.
• ECM-IDLE
ECM stands for EPS connection management.
A UE is in the ECM-IDLE state if an NAS signaling connection (a dedicated S1
connection) is not set up between the UE and the MME. In this state, the eNodeB
cannot obtain the UE context.
• ECM-CONNECTED
A UE is in the ECM-CONNECTED state if a dedicated S1 connection is set up
between the UE and the MME. In this state, the eNodeB creates and stores the UE
context.
3.4 Call Types in the Non-Access Stratum
Call types in the NAS are determined by NAS procedures and causes for RRC connection
setup.
NAS procedures include attach, detach, tracking area update, service request, and
extended service request.
The cause for an RRC connection setup is included in the RRC Connection Request
message when an RRC connection is set up. The causes are MO-signaling, MO-data,
MT-access, emergency, highPriorityAccess, and delayTolerantAccess, as specified in
3GPP specifications. MO stands for mobile originating, and MT stands for mobile
terminating.
Call types in the NAS include originating signaling, originating call, terminating call, and
emergency call.
When a UE in the ECM-IDLE state needs to send an initial NAS message, the UE
requests a dedicated S1 connection. Then, it selects a cause for RRC connection setup
based on the NAS procedure and informs lower layers.
Table 3-1describes the relationships among NAS procedures, causes for RRC connection
setup, and call types.
Table 3-1 Relationships among NAS procedures, causes for RRC connection setup, and call
types
If a request for RRC connection setup is rejected, the UE must wait a period before
resending a request. The wait time is specified by the timer RrcConnStateTimer.T302.
This timer starts when the UE receives a rejection message and stops when the UE enters
the RRC_CONNECTED state or reselects a cell.
4 Signaling Connection Management
This chapter describes the basic feature LBFD-002007 RRC Connection Management.
A signaling connection for a service consists of an RRC connection and a dedicated S1
connection, as shown in Figure 4-1. Generally, a signaling connection is set up for the
establishment of a service bearer. It can also be set up for a signaling procedure (such as a
UE location update).
Signaling connection procedures involve:
• Setting up a signaling connection between the UE and the MME
• Releasing the signaling connection and service bearer
Figure 4-1 Signaling connection protocol stack in LTE
RRC connection setup at layer 3 is initiated by a UE. Before an S1 connection is set up,
the eNodeB cannot obtain the UE context from the evolved packet core (EPC).
Therefore, security mode activation and SRB1encryption and integration protection are
not required during RRC connection setup.
Measurement configuration can be performed for a UE during RRC connection setup, but
the UE can be handed over only after the security mode is activated.
Figure 4-2 shows an RRC connection setup procedure.
Figure 4-2 RRC connection setup procedure
NOTE:
The RRC Connection Request message contains UE_ID. If upper layers provide an SAE Temporary
Mobile Station Identifier (S-TMSI), the UE sends the S-TMSI to the eNodeB. Otherwise, the UE
sends a random value ranging from 0 to (240 – 1) to the eNodeB. The International Mobile
Subscriber Identity (IMSI) of the UE is unknown to the eNodeB.
NOTE:
The eNodeB starts another timer to wait for the UE to send other messages over the Uu interface.
The timer length is specified by either of the following parameters:
• ENODEBCONNSTATETIMER.UuMessageWaitingTimer if no services with QCI 1 are
running on the UE
• ENODEBCONNSTATETIMER.UuMessageWaitingTimerQci1 if services with QCI 1 are
running on the UE
5. The UE performs radio resource configurations and then sends the eNodeB an RRC
Connection Setup Complete message containing NAS messages.
After the eNodeB receives the RRC Connection Setup Complete message, the RRC
connection is set up.
4.2 RRC Connection Reestablishment
This section describes the RRC connection reestablishment procedure on the UE side.
RRC connection reestablishment involves SRB1 reestablishment and security
reactivation. If the security mode is not activated for the AS, the UE cannot initiate RRC
connection reestablishment. If the security mode is activated for the UE in the
RRC_CONNECTED state, the UE can initiate RRC connection reestablishment to retain
RRC connection.
4.2.1 Conditions for Triggering RRC Connection Reestablishment
NOTE:
• Upon receiving consecutive N310 "out-of-sync" indications from lower layers while neither T300,
T301, T304, nor T311 is running, the UE starts T310.
• Upon receiving consecutive N311 "in-sync" indications from lower layers while T310 is running, the
UE stops T310. For details about T300, T301, T304 (RRCCONNSTATETIMER.T304ForEutran
and RRCCONNSTATETIMER.T304ForGeran), T310, T311, and N311, see eNodeB Parameter
Reference.
NOTE:
If the UE fails to be authenticated, the eNodeB rejects the RRC connection reestablishment request
of the UE.
This section describes RRC connection management on the eNodeB side. RRC
connection management applies when the UEs transit from the connected state to the idle
state. UEs in the connected state are classified into UEs in the synchronization state and
UEs in the out-of-synchronization state.
The UE states are classified as follows:
• Connected state: A UE has set up an RRC connection with the eNodeB. The
connected state is further classified as follows:
▪ Synchronization state: A UE in the connected state maintains uplink
synchronization with the eNodeB, and the eNodeB allocates physical uplink
control channel (PUCCH) and sounding reference signal (SRS) resources for
the UE.
▪ Out-of-synchronization state: A UE in the connected state does not maintain
uplink synchronization with the eNodeB, and the eNodeB releases physical
uplink control channel (PUCCH) and sounding reference signal (SRS)
resources for the UE.
• Idle state: A UE does not set up an RRC connection with the eNodeB, and the UE
monitors the paging channel of the eNodeB.
The RrcConnStateTimer.UeInactiveTimer parameter controls the transition of the
connected and idle states of a UE. When the timer specified by the
RrcConnStateTimer.UeInactiveTimer parameter expires, the RRC connection release
procedure is triggered and the UE changes to the idle state. The
RrcConnStateTimer.UlSynTimer parameter controls the transition of the synchronization
and out-of-synchronization states of a UE.
RRC connection management enables the eNodeB to manage RRC connections based on
UEs' uplink quality. Currently, the eNodeB performs the following functions for RRC
connection management:
• Uplink out-of-synchronization management
• UE inactivity timer management
• Radio link failure detection
4.3.1 Uplink Out-Of-Synchronization Management
In UE inactivity timer management, if a UE does not transmit or receive any data within
a period specified by the RrcConnStateTimer.UeInactiveTimer parameter if no services
with QCI 1 are running on the UE or RrcConnStateTimer.UeInactiveTimerQci1 parameter
if services are running on the UE, the eNodeB releases RRC connections for the inactive
UE. This prevents inactive UEs from occupying system resources for a long period. The
causes for a UE to become inactive are as follows:
• The UE has no data to transmit or receive within the specified period.
• The UE has lost contact with the eNodeB because of abnormal radio environment.
After the release, if an E-RAB exists for the UE, the eNodeB sends the EPC an E-RAB
RELEASE INDICATION or UE CONTEXT RELEASE REQUEST message containing
the cause value "User Inactivity."
4.3.3 Radio Link Failure Detection
The eNodeB determines whether a UE experiences a radio link failure (RLF) based on
the following principles:
• If the TimeAlignmentTimer.TimeAlignmentTimer parameter is set to a value other
than INFINITY(Infinity), the eNodeB checks whether an RLF occurs based on the
status of the time alignment (TA) timer.
▪ If the timer does not expire, the radio link of the UE is functional.
▪ If the timer expires, the eNodeB instructs the UE to initiate random access
when the eNodeB needs to transmit data to the UE, or the UE proactively
initiates random access when the UE needs to transmit data to the eNodeB. In
this situation, the eNodeB attempts to restore uplink synchronization for the
UE. If the synchronization succeeds, the radio link of the UE recovers. If the
synchronization fails, an RLF has occurred. In this case, the eNodeB releases
the RRC connection for the UE.
• If the GLOBALPROCSWITCH.UeLinkAbnormalDetectSwitch parameter is set to
ON(On), the RLF detection function is enabled. With this function, the eNodeB
determines an RLF based on the channel quality indicator (CQI) reported by the UE.
If the radio link is abnormal, the eNodeB releases the RRC connection for the UE.
When the eNodeB releases the RRC connection for a UE due to an RLF and an E-RAB
exists for the UE, the eNodeB sends the EPC an E-RAB RELEASE INDICATION or UE
CONTEXT RELEASE REQUEST message containing the cause value "Radio
Connection With UE Lost."
4.4 Dedicated S1 Connection Setup
NOTE:
This document does not describe how to select an MME when an eNodeB connects to multiple
MMEs. For details, see S1-Flex Feature Parameter Description.
2. The MME obtains the cause for this connection setup from the NAS messages,
handles the UE service request, and assigns the dedicated S1APID to the UE.
3. The MME sends an Initial Context Setup Request message to the eNodeB. This
message may contain the UE context and EPS bearer context.
4. The eNodeB creates a context for the UE, generates security keys for the service
bearer and signaling connection based on the received security parameters.
NOTE:
The eNodeB selects a security algorithm supported by both the eNodeB and UE and then sends the
algorithm to the UE in a Security Mode Command message. This document does not describe how
to set up a security mode. For details, see Radio Security Feature Parameter Description.
NOTE:
The eNodeB starts a timer to wait for S1AP-related messages from the MME. The timer length is specified
by either of the following parameters:
• ENodeBConnStateTimer.S1MessageWaitingTimer if no services with QCI 1 are running on the
UE
• ENodeBConnStateTimer.S1MsgWaitingTimerQci1 if services with QCI 1 are running on the UE
This chapter describes the basic features LBFD-002008 Radio Bearer Management.
RB management is performed after encryption and integrity protection is complete. RB
management involves setting up, modifying, and releasing SRB2 and DRBs. The SRB2
is not released using RB management but released together with the SRB1 during
signaling connection release.
In RB management, the UE communicates with the eNodeB based on RRC connection
reconfiguration messages, not based on dedicated signaling messages. The RRC
connection is reconfigured when:
• An RB needs to be set up, modified, or released.
• Handover measurement information needs to be configured or modified.
The RadioResourceConfigDedicated IE contained in an RRC Connection
Reconfiguration message indicates the preceding reconfiguration scenarios.
5.1 SRB2 Setup and Modification
After encryption and integrity protection are complete during dedicated S1 connection
setup, the eNodeB instructs the UE to set up SRB2 based on an srb-ToAddModList value
in the RadioResourceConfigDedicated IE contained in an RRC Connection
Reconfiguration message.
Upon receiving the message, the UE performs the following operations:
• Sets up a Packet Data Convergence Protocol (PDCP) entity, and configures related
security parameters.
• Sets up and configures an RLC entity.
• Sets up and configures a DCCH.
The procedures for SRB2 setup and dedicated S1 connection setup are the same. For
details, see 4.4 Dedicated S1 Connection Setup.
5.1.2 SRB2 Modification
SRB2 is modified only when the related configuration information is changed. Upon
receiving an RRC Connection Reconfiguration message, the UE reconfigures the
corresponding PDCP entity, RLC entity, and DCCH. Figure 5-1 shows an SRB2
modification procedure.
Figure 5-1 SRB2 modification procedure
SRB2 is released with SRB1 during signaling connection release. For details about
signaling connection release, see 4.5 Signaling Connection Release.
5.3 DRB Setup and Modification
A DRB can be set up after encryption and integrity protection are complete and the UE
context is created. Figure 5-2 shows a DRB setup procedure.
Figure 5-2 DRB setup procedure
The MME initiates DRB modification by sending an E-RAB Modify Request message to
the eNodeB. Then, the eNodeB sends an RRC Connection Reconfiguration message to a
UE. According to the instructions in this message, the UE reconfigures the PDCP entity,
RLC entity, and DTCH. Figure 5-3 shows a DRB modification procedure.
Figure 5-3 DRB modification procedure
A data radio bearer (DRB) can be released by the MME using an E-RAB Release
Command message or released in a signaling connection release procedure.
When data transmission is faulty for one or more DRBs over the Uu interface, for
example, when the maximum number of RLC retransmissions specified by the
RLCPDCPPARAGROUP.UeMaxRetxThreshold parameter is reached, the eNodeB
postpones releasing faulty DRBs based on the configured release delay timers. The
lengths of the release delay timers configured for DRBs with standardized and extended
QCIs are specified by the CELLSTANDARDQCI.TrafficRelDelay and
CELLEXTENDEDQCI.TrafficRelDelay parameters, respectively. If multiple DRBs have
been set up for a UE, the shortest timer among the release delay timers for all the DRBs
is used for the UE. When an eNodeB initiates a DRB release, the eNodeB sends the EPC
an E-RAB RELEASE INDICATION or UE CONTEXT RELEASE REQUEST message
containing the cause value "Radio Connection With UE Lost."
During a DRB release, the RRC Connection Reconfiguration message contains a drb-
ToReleaseList field under the Radio Resource Config Dedicated IE. Based on the field
value, the UE releases all the resources related to the DRB. Figure 5-4 shows a DRB
release procedure.
Figure 5-4 DRB release procedure
6 Related Features
Prerequisite Features
None
Impacted Features
None
6.2 Features Related to LBFD-002008 Radio Bearer Management
Prerequisite Features
None
Impacted Features
None
6.3 Features Related to LBFD-002010 Random Access Procedure
Prerequisite Features
None
Impacted Features
None
7 Network Impact
System Capacity
No impact.
Network Performance
No impact.
7.2 LBFD-002008 Radio Bearer Management
System Capacity
No impact.
Network Performance
No impact.
7.3 LBFD-002010 Random Access Procedure
System Capacity
No impact.
Network Performance
No impact.
8 Engineering Guidelines
None
8.2 Required Information
N/A
8.3 Planning
N/A
8.4 Deployment
8.4.1 Process
N/A
8.4.2 Requirements
N/A
8.4.3 Data Preparation
N/A
8.4.4 Precautions
N/A
8.4.5 Initial Configuration
8.4.5.1 Using the CME to Perform Batch Configuration for Newly Deployed eNodeBs
None
8.4.5.2 Using the CME to Perform Batch Configuration for Existing eNodeBs
None
8.4.5.3 Using the CME to Perform Single Configuration
None
8.4.5.4 Using MML Commands
None
8.4.6 Activation Observation
8.4.7 Deactivation
None
8.4.7.2 Using the CME to Perform Single Configuration
None
8.4.7.3 Using MML Commands
None
8.5 Performance Monitoring
To monitor RRC setup, E-RAB setup, and E-RAB release, observe the related counters
on the U2000 client and calculate the KPIs using specific formulas. To monitor radio
bearer status, observe the KPIs related to E-RAB setup and release.
The KPIs are calculated as follows:
• RRC connection setup success rate (service)
Table 8-1 lists the related counters and formula.
Table 8-1 Counters and formula related to the RRC connection setup success rate (service)
Counter • L.RRC.ConnReq.Att.Emc
• L.RRC.ConnReq.Att.HighPri
• L.RRC.ConnReq.Att.Mt
• L.RRC.ConnReq.Att.MoData
• L.RRC.ConnReq.Succ.Emc
• L.RRC.ConnReq.Succ.HighPri
• L.RRC.ConnReq.Succ.Mt
• L.RRC.ConnReq.Succ.MoData
8.6 Troubleshooting
Fault Description
The value of the counter L.E-RAB.SuccEst is much less than that of the counter L.E-
RAB.AttEst, indicating that the E-RAB setup success rate deteriorates significantly.
NOTE:
If the RRC setup success rate deteriorates significantly, contact Huawei for technical support.
Fault Handling
Check whether the ping operation is disabled. If the fault persists, perform the following
steps to rectify the fault:
1. On the U2000 client, start S1 interface tracing and obtain the tracing result, as
shown in Figure 8-4.
Figure 8-4 S1 interface tracing result
2. View the tracing result to check whether there are a large number of
S1AP_INITIAL_CONTEXT_SETUP_FAIL messages, as shown in Figure 8-5.
• If yes, go to the next step.
• If no, contact Huawei for technical support.
Figure 8-5 S1AP_INITIAL_CONTEXT_SETUP_FAIL message
4. Run the MOD GTPU command to enable the detection function for the GTP-U
tunnel corresponding to the S1 interface. In this step, set Static Check Switch to
ENABLE(Enable), as shown in Figure 8-7.
Figure 8-7 Enabling the GTP-U tunnel detection function
5. Run the ADD ENODEBPATH command to add the application type of the IP path
corresponding to the S1 interface. In this step, set Application Type to S1(S1).
Figure 8-8 Adding the application type of the IP path corresponding to the S1 interface
6. Run the DSP IPPATH command to check the status of the IP path, as shown in
Figure 8-9.
If IP Path Check Result is Fault, the IP path is faulty. In this case, check whether
the IP path is correctly configured according to the network plan. If not, correct it
according to the network plan.
Figure 8-9 IP path status
Alarm
LBFD- Radio af
002008 Bearer in
Management be
pa
no
be
G
U
A
D
G
U
A
D
10 Counters
Table 10-1 Counters
Counter ID Counter Name Counter Description Feature ID Feature Name
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
GSM: Basic
None Scheduling
UMTS: Basic
None Scheduling
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
UMTS:
None
LTE:
LBFD-
002007
TDLBFD-
002007
TDLBFD-
002007
LTE:
LBFD-
002010
TDLBFD-
002010
UMTS: RRC
None Connection
LTE: Management
LBFD- Downlink
002007 Dynamic Inter-
TDLBFD- Cell
002007 Interference
LOFD- Coordination
00101401 Downlink Static
LBFD- Inter-Cell
00202201 Interference
Coordination
TDLBFD-
00202201 Downlink Static
Inter-Cell
LOFD- Interference
060201 Coordination
TDLOFD- Adaptive Inter-
060201 Cell
Interference
Coordination
Adaptive Inter-
Cell
Interference
Coordination
LTE:
LBFD-
002007
TDLBFD-
002007
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
LOFD-
070206
TDLOFD-
001037
LOFD-
070206
LOFD-
070206
TDLOFD-
001037
LOFD-
070206
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
LOFD-
070206
TDLOFD-
001037
LOFD-
070206
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
TDLBFD- Basic
002008 Scheduling
TDLOFD- Hybrid RAN
001036 Sharing
TDLOFD-
001037
TDLBFD-
002025
LOFD-
070206
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002007
LTE:
LBFD-
002007
TDLBFD-
002007
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
GSM: Basic
None Scheduling
UMTS: Basic
None Scheduling
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
GSM: Basic
None Scheduling
UMTS: Basic
None Scheduling
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
TDLBFD-
002007
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD- Radio/transpor
002008 resource pre-
LBFD- emption
002024
TDLBFD-
002024
LOFD-
00102901
TDLOFD-
00102901
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002007
TDLBFD-
002007
TDLBFD-
002007
GSM: RRC
None Connection
UMTS: Management
None
LTE:
LBFD-
002007
TDLBFD-
002007
LTE:
LBFD-
002007
TDLBFD-
002007
UMTS:
None
LTE:
LBFD-
002007
TDLBFD-
002007
UMTS: RRC
None Connection
LTE: Management
LBFD- Uplink
002007 Dynamic Inter-
TDLBFD- Cell
002007 Interference
LOFD- Coordination
00101402 Uplink Static
LBFD- Inter-Cell
00202202 Interference
Coordination
TDLBFD-
00202202 Uplink Static
Inter-Cell
LOFD- Interference
060201 Coordination
TDLOFD- Adaptive Inter-
060201 Cell
Interference
Coordination
Adaptive Inter-
Cell
Interference
Coordination
LTE:
LBFD-
002007
TDLBFD-
002007
UMTS: Basic
None Scheduling
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
LOFD-
070206
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002007
TDLBFD-
002007
TDLBFD-
002007
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD- Basic
002008 Scheduling
TDLOFD- Hybrid RAN
001036 Sharing
TDLOFD-
001037
TDLBFD-
002025
LOFD-
070206
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
GSM: Basic
None Scheduling
UMTS: Basic
None Scheduling
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
LTE: Basic
LBFD- Scheduling
002008 Radio Bearer
LOFD- Management
001036 RAN Sharing
LOFD- with Common
001037 Carrier
LBFD- RAN Sharing
002025 with Dedicated
TDLBFD- Carrier
002008 Basic
TDLOFD- Scheduling
001036 Hybrid RAN
TDLOFD- Sharing
001037
TDLBFD-
002025
LOFD-
070206
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
TDLBFD- Basic
002008 Scheduling
TDLOFD- Hybrid RAN
001036 Sharing
TDLOFD-
001037
TDLBFD-
002025
LOFD-
070206
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
TDLBFD- Basic
002008 Scheduling
TDLOFD- Hybrid RAN
001036 Sharing
TDLOFD-
001037
TDLBFD-
002025
LOFD-
070206
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
TDLBFD- Basic
002008 Scheduling
TDLOFD- Hybrid RAN
001036 Sharing
TDLOFD-
001037
TDLBFD-
002025
LOFD-
070206
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
TDLBFD- Basic
002008 Scheduling
TDLOFD- Hybrid RAN
001036 Sharing
TDLOFD-
001037
TDLBFD-
002025
LOFD-
070206
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
TDLBFD- Basic
002008 Scheduling
TDLOFD- Hybrid RAN
001036 Sharing
TDLOFD-
001037
TDLBFD-
002025
LOFD-
070206
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
LBFD-
002025
TDLBFD-
002025
LOFD-
070206
TDLOFD-
001037
LOFD-
070206
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
GSM: Basic
None Scheduling
UMTS: Basic
None Scheduling
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LOFD-
070206
TDLBFD-
002025
LOFD-
070206
LOFD-
070206
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002023
TDLBFD-
002023
TDLOFD-
001037
LOFD-
070206
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
TDLBFD-
002024
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD- Radio/transpor
002024 resource pre-
TDLBFD- emption
002024
LOFD-
00102901
TDLOFD-
00102901
TDLBFD- Radio/transpor
002008 resource pre-
LBFD- emption
002024 Radio/transpor
TDLBFD- resource pre-
002024 emption
LOFD-
00102901
TDLOFD-
00102901
TDLBFD-
002024
TDLOFD-
001037
LOFD-
070206
LOFD-
070206
TDLOFD- Congestion
001037 Control
LOFD- Congestion
070206 Control
LBFD- Radio/transpor
002024 resource pre-
TDLBFD- emption
002024 Radio/transpor
LOFD- resource pre-
00102901 emption
TDLOFD-
00102901
UMTS: RRC
None Connection
LTE: Management
LBFD-
002007
TDLBFD-
002007
LTE: Admission
LBFD- Control
002008
TDLBFD-
002008
LBFD-
002023
TDLBFD-
002023
TDLBFD-
002008
TDLBFD-
002008
LBFD-
002023
TDLBFD-
002023
LOFD-
070206
TDLOFD-
001037
LOFD-
070206
TDLOFD-
001037
LOFD-
070206
LTE: Basic
LBFD- Scheduling
002008 Hybrid RAN
TDLBFD- Sharing
002008 RAN Sharing
LBFD- with Common
002025 Carrier
TDLBFD- RAN Sharing
002025 with Dedicated
LOFD- Carrier
070206 RAN Sharing
LOFD- with Common
001036 Carrier
LOFD- RAN Sharing
001037 with Dedicated
TDLOFD- Carrier
001036
TDLOFD-
001037
TDLOFD-
001037
LTE:
LBFD-
002007
LOFD-
001105
TDLOFD-
001105
LTE:
LBFD-
002007
LOFD-
001105
TDLOFD-
001105
LTE:
LBFD-
002007
LOFD-
001105
TDLOFD-
001105
LTE:
LBFD-
002007
TDLBFD-
002007
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
GSM: Basic
None Scheduling
UMTS: Basic
None Scheduling
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
UMTS:
None
LTE:
LBFD-
002007
TDLBFD-
002007
TDLBFD-
002007
GSM: RRC
None Connection
UMTS: Management
None
LTE:
LBFD-
002007
TDLBFD-
002007
LTE:
LBFD-
002007
TDLBFD-
002007
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
UMTS: Basic
None Scheduling
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
UMTS:
None
LTE:
LBFD-
002007
TDLBFD-
002007
TDLBFD-
002007
GSM: RRC
None Connection
UMTS: Management
None
LTE:
LBFD-
002007
TDLBFD-
002007
LTE:
LBFD-
002007
TDLBFD-
002007
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
LTE: Basic
LBFD- Scheduling
002008 Uplink Power
TDLBFD- Control
002008 Uplink Power
LBFD- Control
002025
TDLBFD-
002025
LBFD-
002026
TDLBFD-
002026
LBFD-
002025
TDLBFD-
002025
LBFD-
002026
TDLBFD-
002026
TDLBFD-
002025
LBFD-
002026
TDLBFD-
002026
LBFD-
002026
TDLBFD-
002026
TDLBFD-
002026
LBFD-
002025
TDLBFD-
002025
LBFD-
002026
TDLBFD-
002026
TDLBFD-
002025
LBFD-
002026
TDLBFD-
002026
LBFD-
002026
TDLBFD-
002026
TDLBFD-
002026
UMTS: Basic
None Scheduling
LTE: Uplink Power
LBFD- Control
002008 Uplink Power
TDLBFD- Control
002008
LBFD-
002025
TDLBFD-
002025
LBFD-
002026
TDLBFD-
002026
LBFD-
002025
TDLBFD-
002025
LBFD-
002026
TDLBFD-
002026
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
UMTS:
None
LTE:
LBFD-
002008
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLBFD-
002025
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
TDLAOFD-
080405
LBFD-
002025
TDLBFD-
002025
UMTS: Basic
None Scheduling
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
LTE: Basic
LBFD- Scheduling
002008 RAN Sharing
TDLBFD- with Common
002008 Carrier
LBFD- RAN Sharing
002025 with Common
TDLBFD- Carrier
002025 RAN Sharing
LOFD- with Dedicated
001036 Carrier
TDLOFD- RAN Sharing
001036 with Dedicated
LOFD- Carrier
001037 Hybrid RAN
TDLOFD- Sharing
001037
LOFD-
070206
LOFD-
070206
TDLOFD-
001037
LOFD-
070206
TDLBFD-
002008
TDLBFD-
002023
LBFD-
002023
TDLOFD-
001037
LTE:
LBFD-
002007
TDLBFD-
002007
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
GSM: Enhanced
None Extended QCI
UMTS: Enhanced
None Extended QCI
LTE:
LBFD-
002008
TDLBFD-
002008
LOFD-
081218
TDLOFD-
081215
TDLOFD-
081215
LTE: Basic
LBFD- Scheduling
002008 Enhanced
TDLBFD- Extended QCI
002008 Enhanced
LBFD- Extended QCI
002025
TDLBFD-
002025
LOFD-
081218
TDLOFD-
081215
TDLBFD-
002008
LTE:
LBFD-
002008
TDLBFD-
002008
LBFD-
002025
TDLBFD-
002025
LOFD-
081218
TDLOFD-
081215
UMTS:
None
LTE:
LBFD-
002007
TDLBFD-
002007
11 Glossary
12 Reference Documents
10. Random Access Control and RACH Optimization Feature Parameter Description
11.
eRAN
QoS Management Feature Parameter
Description
Issue 02
Date 2015-04-30
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.
Website: http://www.huawei.com/
Email: support@huawei.com
3.2.28 Contents
1 About This Document
1.1 Scope
1.2 Intended Audience
1.3 Change History
1.4 Differences Between eNodeB Types
3 Basic Principles
3.1 EPS Bearer Architecture
3.2 EPS Bearer Types
3.3 Bearer-Level QoS Parameters
6 Related Features
7 Network Impact
8 Engineering Guidelines
8.1 When to Use QCI-based QoS Management
8.2 Required Information
8.3 Planning
8.4 Deployment
8.4.1 Requirements
8.4.2 Data Preparation
8.4.3 Precautions
8.4.4 Hardware Adjustment
8.4.5 Initial Configuration
8.4.6 Activation Observation
8.4.7 Reconfiguration
8.4.8 Deactivation
8.5 Performance Monitoring
8.6 Parameter Optimization
8.7 Troubleshooting
9 Parameters
10 Counters
11 Glossary
12 Reference Documents
1.1 Scope
This document describes quality of service (QoS) management, including its technical
principles, related features, network impact, and engineering guidelines.
This document applies to the following types of eNodeBs.
eNodeB Type Model
Micro BTS3202E
LampSite DBS3900
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 as well as the affected
entities
• Editorial change
Changes in wording or addition of information and any related parameters affected
by editorial changes. Editorial change does not specify the affected entities.
eRAN8.1 02 (2015-04-30)
eRAN8.1 01 (2015-03-23)
The features described in this document are implemented in the same way on macro,
micro and LampSite eNodeBs.
2.1 Introduction
QoS is a key indicator of Evolved Packet System (EPS) performance. QoS of an EPS
defines the comprehensive service capability of the EPS and determines customer
satisfaction with services provided by operators. An EPS consists of an Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) and an Evolved Packet Core
(EPC). QoS management is a mechanism that helps an EPS meet service quality
requirements.
2.2 Benefits
QoS management ensures service quality based on coordination between all network
elements (NEs) involved, from service initiation to service response. This document
describes QoS management on the eNodeB.
2.3 Improvements
QoS management is performed on EPS bearers. The NEs involved are described as
follows:
• The PCRF dynamically generates QoS policies and then sends them to the P-GW,
which implements them. During QoS policy implementation, the P-GW identifies
the service data flow (SDF) according to the traffic flow template (TFT) and binds
the SDF to an available EPS bearer. The TFT is dynamically generated by the PCRF
or, if the PCRF is unavailable, statically configured on the P-GW.
• The S-GW manages packet routing and forwarding and maps S5 bearers to S1
bearers.
• The MME obtains UE subscription data from the HSS and transfers the QoS
parameters among the NEs.
• The HSS stores UE subscription data and subscribed QoS policies.
• The eNodeB establishes bearers for UEs and schedules UE data based on the QoS
parameter settings and the status of radio and transport resources. The eNodeB uses
differentiated resource management and allocation policies to meet the QoS
requirements of the bearers.
For details about EPS bearers in QoS management, see chapter 13 in 3GPP TS 36.300
V10.10.0.
This document only covers the general QoS management specified in 3GPP TS 36.300.
For details about feature-specific QoS management, see the relevant feature parameter
description documents.
3 Basic Principles
In the EPS, QoS management works on a per EPS bearer basis, upon which SDFs are
created. SDFs mapped to the same EPS bearer receive the same bearer-level QoS
treatment, including scheduling and radio bearer policies. To provide different QoS
management policies for different SDFs, these SDFs must be mapped to different EPS
bearers.
Figure 3-1 illustrates the EPS bearer service architecture defined in 3GPP specifications.
Figure 3-1 EPS bearer service architecture
In the LTE system, an EPS bearer carries one or more SDFs with the same QoS attribute
between a UE and a P-GW. In Figure 3-1, the bearer between the UE and eNodeB is a
radio bearer, and the bearer between the eNodeB and S-GW is an S1 bearer. The radio
bearer and S1 bearer form an E-UTRAN radio access bearer (E-RAB). QoS management
is performed at a granularity of bearers. This document only describes QoS management
on E-RABs.
3.2 EPS Bearer Types
• GBR bearers are used for real-time services, such as voice, video, and real-time
gaming. These bearers are dedicated bearers.
• Non-GBR bearers are used to carry non-real-time services, such as emails, File
Transfer Protocol (FTP) services, and Hypertext Transfer Protocol (HTTP) services.
EPS bearers can also be classified into default and dedicated bearers.
Table 3-2 EPS bearer types (II)
Default bearer Allocated by the EPC to a UE when the UE is initially attached to the
EPS. If the UE have multiple access point names (APNs), the EPS
sets up a default bearer for each APN, for example, one for IMS APN
and another for Internet APN. The default bearer remains established
to ensure a short delay for the UE to start a service and provide the
UE with always-on IP connectivity.
The default bearer is a non-GBR bearer.
Dedicated Set up for a UE if the default bearer cannot meet the QoS
bearer requirements.
A dedicated bearer can generally meet more stringent QoS
requirements than the default bearer. Multiple dedicated bearers can
be set up for a UE simultaneously.
The EPC sets up dedicated bearers for a UE based on QoS
requirements. A dedicated bearer can be a GBR or non-GBR bearer.
A maximum of eight bearers with different QCIs can be set up between a Huawei
eNodeB and a UE.
3.3 Bearer-Level QoS Parameters
The EPS provides various packet services such as videophone, audio, video, web
browsing, and email. Subscriber requirements vary according to the service type. For
example, subscribers demand clear voice, uninterrupted video streaming, and fast web
browsing. The EPS maps these requirements to QoS parameters, which can be interpreted
and processed by each NE. Table 3-3 describes the QoS parameters of EPS bearers.
Table 3-3 QoS parameters of EPS bearers
QoS Description
Parameter
QCI QoS class identifiers (QCIs) are classified into standardized QCIs and
extended QCIs. According to 3GPP specifications, nine standardized
QCIs are defined, and extended QCIs ranging from 10 to 254 help
provide diversified services. These QCIs standardize QoS requirements.
Each QCI specifies a set of requirements in terms of the resource type,
priority, packet delay budget, and packet error loss rate for a type of
service. QCIs are transmitted between network nodes, with no need to
negotiate or transmit a large quantity of QoS parameters. The EPS
implements QoS management policies based on the QCIs.
SDFs with different QCIs are mapped to different EPS bearers. For
details about QCI usage, see 5.2 QCI-based QoS Management.
GBR and A GBR is the bit rate that can be expected to be provided by a GBR
MBR bearer, and a maximum bit rate (MBR) is the maximum bit rate that can
be expected to be provided for a GBR bearer.
The GBR and MBR are used for managing the bandwidths of GBR
bearers. The EPS admits all SDFs at bit rates lower than or equal to the
GBR, for example, by reserving resources and rejects all SDFs at bit
rates higher than the MBR. If the bit rates of SDFs are higher than the
GBR but lower than the MBR, the EPS rejects the SDFs when the
network is congested or admits the SDFs when the network is not
congested.
The MBR and GBR for a GBR bearer are the same in the current version.
For details about GBR and MBR usage, see 5.4 GBR-/MBR-based QoS
Management.
UE-AMBR An Aggregate Maximum Bit Rate (AMBR) is used by the EPS to limit the
or APN- total bit rate of a group of non-GBR bearers. AMBRs are categorized as
AMBR follows:
• UE-AMBR: per UE aggregate maximum bit rate. Bandwidth
management based on UE-AMBR limits the total bit rate of all the
non-GBR bearers created for a UE.
QoS Description
Parameter
The QCI and ARP parameters apply to both GBR and non-GBR bearers.
The GBR and MBR parameters apply only to GBR bearers, and the rates must be
enforced to ensure the service quality of GBR services.
The AMBR parameter applies only to non-GBR bearers and imposes constraints on the
total bit rate of all the bearers associated with the AMBR. If only one of the bearers is
carrying data, the data rate of this bearer can be as high as the AMBR. The eNodeB
implements the UE-AMBR, and the P-GW or UE implements the APN-AMBR. QoS
management is performed based on layers, and NEs at the same layer perform QoS
management based on the same QoS parameters. Table 3-4 lists the QoS parameters of the
NEs.
Table 3-4 QoS parameters of the NEs
eNodeB QoS management consists of radio QoS management and transport QoS
management. Radio QoS management ensures the quality of services on radio bearers,
and transport QoS management ensures the quality of services on S1 bearers.
In the service setup request phase, admission control over the requests is performed on
both the Uu and S1 interfaces, and the eNodeB provides bearer services only for those
admitted. In addition, the eNodeB maps QoS parameters to differentiated services code
points (DSCPs) for transport QoS management.
After a service is set up, the eNodeB performs QoS management on services based on
QCIs. To ensure the quality of high-priority services, congestion control is performed on
low-priority services when the Uu interface and transport network are congested. In
addition, continuity of QoS treatment must be ensured during UE movements.
QoS management is an end-to-end service quality mechanism that requires the
cooperation of multiple features. Table 4-1 lists the features involved. Among the features,
those related to admission control, preemption, and congestion control may not be
concurrently applied on the S1 and X2 interfaces.
Table 4-1 Features involved in QoS management
In QoS management, while ensuring the service quality of a single subscriber based on
the subscriber's QoS parameters, the eNodeB provides differentiated services (DiffServ)
for multiple subscribers based on each subscriber's QoS parameters.
4.2 QoS Guarantees for a Single Subscriber
QoS management provides QoS guarantees for a single subscriber by using a variety of
functions. Based on these functions, the eNodeB provides the basic service quality for the
subscriber by binding the service to an appropriate radio bearer and setting associated
parameters. In addition, the eNodeB ensures service continuity by monitoring link quality
during UE movements.
QoS management provides QoS guarantees for an entire service process implemented
during the service setup request phase and post-service-setup phase.
4.2.1 Service Setup Request Phase
The service setup request phase requires QoS parameter mapping and admission control
based on the availability of cell resources.
This section describes the mapping between QoS and transport parameters based on the
LBFD-00300201 DiffServ QoS Support feature, and the mapping between QoS and radio
bearer parameters based on other features.
During the service setup request phase, the eNodeB maps the QoS parameters of a
service, such as the QCI, GBR, and MBR, to the service's radio bearer and transport
parameters, providing consistent QoS parameters for eNodeB QoS management.
Radio bearer parameter configuration maps QoS parameters to radio bearer parameters
and includes eNodeB-level, cell-level, and operator-level QCIs configurations. For
details, see 8.4.2 Data Preparation.
eNodeB-level QCI configuration maps QoS parameters to scheduling priorities and to the
radio link control (RLC) and Packet Data Convergence Protocol (PDCP) transmission
modes and transport parameters. Cell-level QCI configuration maps QoS parameters to
service-based discontinuous reception (DRX), scheduling request indicator (SRI), and
handover parameters. Operator-level QCI configuration maps QoS parameters to service-
based inter-RAT handover and inter-frequency handover policies.
Transport parameter configuration maps QoS parameters to transport parameters. The
S1and X2 interfaces use the technique of IP transmission. DiffServ is imported to ensure
the QoS of IP transmission. In DiffServ, the DSCP values of IP packet headers inform all
routers on the transmission path of the IP packets' QoS requirements. The DSCP value
ranges from 0 to 63 with a larger value indicating a higher scheduling priority of an IP
packet. The eNodeB allocates a proper DSCP value for IP packets sent to the S-GW
based on the QoS requirements of services on the S1/X2 interfaces. The DSCP value
configuration includes the setting of parameters User Data Type Number and User
Data Type Transfer Parameter Group ID. For details, see 8.4.2 Data Preparation.
For details about radio bearers, see Connection Management Feature Parameter Description,
Scheduling Feature Parameter Description, and DRX and Signaling Control Feature Parameter
Description. For details about the transport resource configuration, see Transport Resource
Management Feature Parameter Description.
Power Control
This section describes QoS management based on power control features LBFD-002016
Dynamic Downlink Power Allocation and LBFD-002026 Uplink Power Control.
After a service is set up, power control limits the transmit power for the service within an
appropriate range. This function ensures correct data reception and improves power
efficiency. Based on power control and scheduling, the block error rate (BLER) can
converge to the target value. For details about power control, see Power Control Feature
Parameter Description.
Mobility Management
This section describes QoS management based on mobility management features LBFD-
00201805 Service Based Inter-frequency Handover, LOFD-001043 Service based inter-
RAT handover to UTRAN, and LOFD-001046 Service based inter-RAT handover to
GERAN.
Service quality may deteriorate when a UE moves to the cell edge. By using the handover
function, the eNodeB promptly triggers a handover to enable the UE to be served by
another cell and thereby ensures service continuity.
Service-based handover polices can be divided into:
• Service-based inter-frequency handover
The LBFD-00201805 Service Based Inter-frequency Handover feature enables
frequency steering based on services. Services with a certain QCI can be steered to a
specific frequency. To implement service-based inter-frequency handovers, the
operator must specify QCI-based frequency selection policies and configure the
frequency that is preferentially used to carry services with a certain QCI.
• Service-based inter-RAT handovers to UTRAN/GERAN
In Service-based inter-RAT handovers to UTRAN/GERAN, the eNodeB hands over
a UE to a different RAT based on the QCI type of the service running on the UE.
Whether service-based inter-RAT handovers are required, allowed, or not allowed
can be configured for those services with QCIs ranging from 1 to 9.
For details about handovers, see Mobility Management in Connected Mode Feature
Parameter Description.
Scheduling
This section describes QoS management based on the scheduling feature LOFD-
00101502 Dynamic Scheduling.
Scheduling consists of downlink and uplink scheduling. In scheduling, the eNodeB
determines the scheduling priorities of radio bearers and UEs based on the input QoS
parameters and the quality of PUSCH and PDSCH. This maximizes system throughput
while meeting UEs' QoS requirements. Scheduling helps ensure basic quality for
services. For example, scheduling ensures acceptable transmission delay for data packets
of delay-sensitive voice over IP (VoIP) services, and ensures the service rate and packet
delay budget (PDB) for GBR services. Scheduling also ensures that the rates of FTP
services are not lower than min_GBR, which are throughput-sensitive services.
For details about scheduling, see Scheduling Feature Parameter Description.
4.3 DiffServ for Multiple Subscribers
In scenarios with multiple subscribers, the eNodeB must provide DiffServ to different
subscribers and ensure the fairness of resource allocation while meeting each subscriber's
QoS requirements. DiffServ aims to serve more subscribers with limited system resources
while ensuring the expected quality of services of subscribers.
4.3.1 Principles of Differentiated Services
Preemption
This section describes QoS management based on the preemption feature LOFD-
00102901 Radio/transport Resource Pre-emption.
The principle of radio resource preemption is similar to that of transport resource
preemption. In transport resource preemption, after the preemption relationships of
services and subscribers are configured, a high-priority service is allowed to preempt
low-priority services in case it fails to be admitted initially. This ensures the access
success rates of high-priority services. The IE preemption vulnerability in the ARP
parameter specifies whether transport resources allocated to a bearer can be preempted. If
the preemption is successful and the redirection function is enabled, the UE performs
redirection on the services whose transport resources are preempted. If the preemption
fails and the redirection function is enabled, the UE performs redirection on the services
that fail to preempt transport resources.
In addition, emergency services are allowed to preempt the resources of other services,
but the resources of emergency services cannot be preempted. The value of the IE
Priority Level in the ARP parameter specifies the preemption priority of services. The
IE value of the service to be preempted is greater than that of the preempting service.
For details about DiffServ during the service setup request phase, see Admission and
Congestion Control Feature Parameter Description and Transport Resource Management Feature
Parameter Description.
This section describes QoS management based on the LBFD-002024 Congestion Control,
LOFD-00301103 Transport Resource Overload Control, and LOFD-00301102 Transport
Differentiated Flow Control features.
If the network is congested, the eNodeB releases resources of some admitted services
(excluding emergency services). This mechanism reduces cell loads to maintain system
stability. Low-priority services are usually selected first for resource release.
• Congestion control on the Uu interface
The quality of non-GBR services is not required to be guaranteed. To guarantee the
quality of GBR services, the eNodeB performs congestion control on GBR services
on the Uu interface based on the GBR service satisfaction rate. If the GBR service
satisfaction rate is low, the eNodeB releases low-priority services based on the ARP
priorities. Low-priority services are usually selected first for resource release, which
ensures the overall service quality in a cell at the cost of low-quality service quality.
For details about congestion control on the Uu interface, see Admission and Congestion
Control Feature Parameter Description.
Scheduling
ARP-based QoS management ensures equal subscriber resource use in traditional packet
services. Requirements of high-priority subscribers cannot be fully met with these
traditional services.
ARP-based QoS management provides DiffServ by using admission and congestion
control based on service priority information contained in subscription data.
During the setup of an E-UTRAN radio access bearer (E-RAB), the EPC transmits an
ARP (which includes subscription data) to the eNodeB. The eNodeB then maps the ARP
to a service priority (gold, silver, or bronze). The mapping between ARPs and service
priorities can be set by CellRacThd.GoldServiceArpThd (ARP threshold for gold services)
or CellRacThd.SilverServiceArpThd (ARP threshold for silver services). If the mapping is
not specified by either parameter, the ARP is mapped to a bronze service. A larger ARP
value indicates a lower priority. The probability that the services fail admission control is
higher when the network is congested.
Table 5-1 Mapping between ARPs and service priority
ARPs Service Priority
1 to 5 Gold
6 to 10 Silver
11 to 15 Bronze
The eNodeB next determines load control policies for services based on ARPs or service
priorities. For example, different admission thresholds are set for gold, silver, and bronze
services for admission control; different resource release thresholds or rate decrease
thresholds are set for gold, silver, and bronze services for congestion control. For details,
see Admission and Congestion Control Feature Parameter Description.
5.2 QCI-based QoS Management
3 3 50 ms 10-3 Real-time
gaming
… … …
… … …
… … …
… … …
… … …
… … …
Standardized and extended QCIs are sent by the MME to the eNodeB. The eNodeB then
performs QoS management based on these QCIs.
Operators can set radio bearer and transmission parameters on the eNodeB for QCIs.
Radio bearer parameters include RLC-related parameters, PDCP-related parameters,
media access control (MAC) scheduling parameters, and handover parameters.
To set the QCIs, operators can run the following commands:
• MOD STANDARDQCI and MOD CELLSTANDARDQCI: used to modify
parameters related to standardized QCIs
• ADD EXTENDEDQCI and ADD CELLEXTENDEDQCI: used to set parameters
related to extended QCIs
Operators can define their own extended QCIs in an EPS. Standardized QCIs from 5 to 9
can each be extended to multiple QCIs that correspond to different subscriber classes.
Operators can provide different QoS policies for different classes of subscribers when
these subscribers use the same service. As a result, high-priority users are preferentially
admitted to cells, allocated resources, and scheduled for services. In addition, operators
can provide different services for different service types.
Extended QCIs are defined by operators and must be negotiated between the EPC and the
E-UTRAN to ensure consistent QoS policies.
The eNodeB configures QoS parameters and sets up radio bearers based on QCIs,
enabling radio bearers to meet QoS requirements for different service types.
The parameters StandardQci.RlcPdcpParaGroupId and ExtendedQci.RlcPdcpParaGroupId
in standardized and extended QCIs can be set by referring to
RlcPdcpParaGroup.RlcPdcpParaGroupId. The parameters in the RlcPdcpParaGroup
MO can be set by running the ADD RLCPDCPPARAGROUP command. The RLC
transmission modes can be configured for different radio bearers based on services' QCIs.
It is recommended that the RLC transmission mode be set to Unacknowledged Mode for
the delay-sensitive radio bearers to ensure real-time data transmission. It is also
recommended that the RLC transmission mode be set to Acknowledged Mode for the
general radio bearers to ensure accurate data transmission.
The default RLC/PDCP-related parameter group is set for each QCI based on the QCIs
for typical services listed in Table 5-2 so that every service type can obtain proper QoS
guarantee. It is not recommended that a QCI be configured for a service that is not
provided in Table 5-2 for this QCI. For example, the bearers with QCI of 5 takes an
absolute priority of carrying IMS signaling as defined in 3GPP protocols. Therefore, it is
not recommended other types of services be carried on the bearers with this QCI. For
bearers with other QCIs, whether the parameter settings in the
RLCPDCPPARAGROUP MO for a QCI can meet the service requirements must be
checked. For details about the parameters in the RLCPDCPPARAGROUP MO, see
8.4.2 Data Preparation.
The eNodeB provides different scheduling services on radio interfaces based on the QCIs
of the services. During scheduling, the eNodeB categorizes data packets into different
priority queues based on the QCIs, and preferentially schedules data packets in a high-
priority queue.
For details about scheduling, see Scheduling Feature Parameter Description.
Handover Parameter Setting
The eNodeB can configure different handover parameters and policies for different
service types based on the QCIs of these services. This function meets the key
requirements for mobility, coverage continuity, and service drop rates. In addition, this
function helps perform handover promptly, improve UE data transmission performance
before the handover, decrease the number of UE measurements, reduce the number of
handovers, and lower the probability of ping-pong handovers.
For details about handovers, see Mobility Management in Connected Mode Feature
Parameter Description.
The eNodeB transmits S1/X2 interface data through an IP network. QoS management in
the IP network classifies services and defines QoS requirements based on differentiated
services code points (DSCPs). QoS management uses per-hop behavior (PHB) policies
such as resource allocation, queue scheduling, and packet discarding policies. All the
network nodes comply with PHB policies according to the DSCP in the IP packet. The IP
network specifies PHB policies for IP packets based on DSCPs.
The eNodeB maps QCIs to DSCPs and specifies DSCPs for uplink IP packets.
Performing these actions enables eNodeB interface boards to differentiate service data
packets transmitted over an eNodeB interface board.
For details about transport resource management (TRM), see Transport Resource Management
Feature Parameter Description.
To implement differentiated services for different users and services, the eNodeB can
determine the scheduling weight factors of bearers for users based on the ARPs and QCIs
carried in the E-RABs when E-RABs are set up. Users can set the
UserPriority.ArpSchSwitch parameter to enable ARP scheduling for QCIs ranging from 6
to 9.
The eNodeB obtains the ARPs and QCIs carried by the E-RABs from the EPC and
determines the mapping relationships between gold, silver, and bronze users based on the
UserPriority.ARPxPriority(x=1-15) parameter of the UserPriority MO. For example, if
UserPriority.ARP1Priority is set to GOLD, the users for ARP 1 are gold users. Then,
based on the user priorities (gold, silver, and bronze) and QCIs, the eNodeB determines
the weight factors for the uplink and downlink scheduling priorities, which are controlled
by the following parameters:
• UserQciPriority.GoldUlSchPriorityFactor
• UserQciPriority.GoldDlSchPriorityFactor
• UserQciPriority.SilverUlSchPriorityFactor
• UserQciPriority.SilverDlSchPriorityFactor
• UserQciPriority.BronzeUlSchPriorityFactor
• UserQciPriority.BronzeDlSchPriorityFactor
Table 5-3provides an example. A user with a higher priority and higher QCI will obtain a
higher scheduling priority.
Table 5-3 Example of ARP- and QCI-based scheduling priorities
User Priority QCI Uplink scheduling priority factor Downlink scheduling priority
factor
QoS management for GBR services is based on GBR and MBR, whereas QoS
management for non-GBR services is not.
The GBR and MBR are sent by the EPC to the eNodeB. The eNodeB then manages the
bandwidth for GBR services based on the GBR.
The eNodeB accepts or rejects the admission request of a GBR service based on the GBR
QoS satisfaction level, PRB admission policy, and ARP. During uplink and downlink
scheduling, the eNodeB must preferentially meet the data rate and delay requirements of
GBR services.
The eNodeB does not ensure the data rates and PDBs of non-GBR services. However,
operators can satisfy downlink and uplink minimum data rates for non-GBR services by
setting min_GBR-related parameters (including StandardQci.UlMinGbr,
ExtendedQci.UlMinGbr, StandardQci.DlMinGbr and ExtendedQci.DlMinGbr) and by
setting the parameter related to prioritized bit rate (PBR) (including
StandardQci.PrioritisedBitRate, StandardQci.LogicalChannelPriority,
ExtendedQci.PrioritisedBitRate, ExtendedQci.LogicalChannelPriority, and
GlobalProcSwitch.LcgProfile). For details, see Scheduling Feature Parameter Description.
5.5 AMBR-based QoS Management
The UE and P-GW ensure that the total bit rate of all the non-GBR bearers created by a
UE under an APN does not exceed the APN-AMBR. The eNodeB ensures that the total
bit rate of all the non-GBR bearers created by a UE does not exceed the UE-AMBR.
The eNodeB limits the data rates of non-GBR services based on the UE-AMBR at the
transport layer. If the buffer time at the transport layer is longer than the congestion time
threshold RSCGRPALG.CTTH, the data packets arriving at the transport layer are not
transmitted. If the number of buffered queues at the transport layer is greater than the
threshold for the number of lost packets RSCGRPALG.DROPPKTNUM, the data packets
arriving at the transport layer are discarded.
The eNodeB preferentially schedules UEs whose bit rates have not reached the UE-
AMBR.
6 Related Features
Prerequisite Features
This chapter describes only the LBFD-002032 Extended-QCI feature. Other features
mentioned in this document are described in their respective feature parameter
description documents.
DiffServ based on extended QCIs requires the following features:
• LOFD-00101502 Dynamic Scheduling
• LBFD-00300201 DiffServ QoS Support
• LOFD-00301102 Transport Differentiated Flow Control
None
Impacted Features
None
7 Network Impact
System Capacity
The E-UTRAN QoS features have the following impact on system capacity:
• The admission control and congestion control algorithms satisfy the QoS
requirements of admitted UEs and maximize system capacity in both the radio
access network and the transport network.
• Uplink scheduling and uplink power control ensure uplink coverage, minimize
uplink interference, and maximize uplink capacity.
• Downlink scheduling and downlink power control ensure downlink coverage and
maximize downlink capacity.
• Intra-LTE load balancing balances inter-cell loads and maximizes the system load.
Network Performance
The E-UTRAN QoS features have the following impact on network performance:
• Inappropriate admission control and congestion control increase the service drop
rate and decrease the access success rate in both the radio access network and the
transport network.
• Uplink and downlink scheduling features affect the cell throughput and the
throughput and QoS satisfaction level of cell-edge UEs.
• Uplink and downlink power control features affect the cell throughput.
• Mobility-related features affect the service drop rate and handover success rate.
During handovers, the QoS requirements of services must be satisfied, while the
service drop rate and handover success rate must be maintained.
8 Engineering Guidelines
QoS management for the E-UTRAN is achieved through features such as scheduling,
power control, load control, mobility management, load balancing, and transport resource
management. QoS management can take effect only after these features are enabled. This
chapter provides engineering guidelines for configuring QCIs. For engineering guidelines
for these features, see their parameter description documents.
8.1 When to Use QCI-based QoS Management
To ensure service quality based on only service types, operators can deploy QoS
management based on standardized QCIs. The standardized QCIs are the basis for QoS
management and are automatically created.
To ensure service quality based on both service types and service priorities, operators
need to deploy QoS management based on extended QCIs. One service type can be
mapped to multiple extended QCIs, and each of these QCIs corresponds to a service
priority. Extended QCIs need to be manually configured, and relevant parameters need to
be planned.
8.2 Required Information
None
8.3 Planning
RF Planning
N/A
Network Planning
N/A
Hardware Planning
N/A
8.4 Deployment
8.4.1 Requirements
Operating Environment
Extended QCIs are defined by operators. The EPC must support extended QCIs, and NEs
in the EPS (including the MME, S-GW, and P-GW) must negotiate extended QCIs for
consistent QoS policies.
Transmission Networking
None
License
None
8.4.2 Data Preparation
This section describes the data that you need to collect for setting parameters. Required
data is data that you must collect for all scenarios. Collect scenario-specific data when
necessary for a specific feature deployment scenario. There are three types of data
sources:
• Network plan (negotiation not required): parameter values planned and set by the
operator
• Network plan (negotiation required): parameter values planned by the operator and
negotiated with the evolved packet core (EPC) or peer transmission equipment
• User-defined: parameter values set by users
QoS guarantee requires the mapping between QoS parameters, eNodeB parameters, and
handover policies.
The configuration of eNodeB-level QCIs maps QCI configurations to scheduling
priorities and transmission modes and transport parameters on Radio Link Control (RLC)
and Packet Data Convergence Protocol (PDCP).
The configuration of cell-level QCIs maps QCI configurations to service-based
discontinuous reception (DRX), scheduling request indicator (SRI), and handover
parameters.
The configuration of operator-level QCIs maps QCI configurations to service-based inter-
RAT handover and inter-frequency handover policies.
eNodeB-level QCIs
not
required)
The following table describes the parameters that must be set in the UserQciPriority
MO.
configuration is not
necessary.
based on the
network plan.
Retain the
default value
unless there
are special
requirements.
not RLC/PDCP
required) parameter
group. Configure
this parameter
based on the
network plan.
retransmissions,
which limits the
maximum
number of AM
PDU
retransmissions.
When the
number of RCL
ARQ
retransmissions
reaches this
parameter value,
the RRC
connection
reestablishment
is triggered.
Configure this
parameter
based on the
network plan.
Retain the
default value
unless there are
special
requirements.
is triggered.
Configure this
parameter
based on the
network plan.
Retain the
default value
unless there are
special
requirements.
Retain the
default value
unless there are
special
requirements.
not
required)
Cell-level QCIs
manual
operation.
(negotiation parameter
not based on
required) the
network
Local cell ID CellExtendedQci.LocalCellId Network plan.
plan
(negotiation
not
required)
Operator-level QCIs
network
plan.
8.4.3 Precautions
None
8.4.4 Hardware Adjustment
N/A
8.4.5 Initial Configuration
Using the CME to Perform Batch Configuration for Newly Deployed eNodeBs
Enter the values of the parameters listed in Table 8-1, Table 8-2, and Table 8-3 in a summary
data file, which also contains other data for the new eNodeBs to be deployed.
Then, import the summary data file into the Configuration Management Express (CME)
for batch configuration. For detailed instructions, see "Creating eNodeBs in Batches" in
the initial configuration guide for the eNodeB, which is available in the eNodeB product
documentation.
The summary data file may be a scenario-specific file provided by the CME or a
customized file, depending on the following conditions:
• The MOs in Table 8-1, Table 8-2, and Table 8-3 are contained in a scenario-specific
summary data file. In this situation, set the parameters in the MOs, and then verify
and save the file.
• Some MOs in Table 8-1, Table 8-2, and Table 8-3 are not contained in a scenario-specific
summary data file. In this situation, customize a summary data file to include the
MOs before you can set the parameters.
Table 8-1 eNodeB-level QCIs
Batch reconfiguration using the CME is the recommended method to activate a feature on
existing eNodeBs. This method reconfigures all data, except neighbor relationships, for
multiple eNodeBs in a single procedure. The procedure is as follows:
1. After creating a planned data area, choose CME > Advanced > Customize
Summary Data File (U2000 client mode), or choose Advanced > Customize
Summary Data File (CME client mode), to customize a summary data file for
batch reconfiguration.
NOTE:
For context-sensitive help on a current task in the client, press F1.
2. Choose CME > LTE Application > Export Data > Export Base Station Bulk
Configuration Data (U2000 client mode), or choose LTE Application > Export
Data > Export Base Station Bulk Configuration Data (CME client mode), to
export the eNodeB data stored on the CME into the customized summary data file.
3. In the summary data file, set the parameters in the MOs listed in Using the CME to
Perform Batch Configuration for Newly Deployed eNodeBs and close the file.
4. Choose CME > LTE Application > Import Data > Import Base Station Bulk
Configuration Data (U2000 client mode), or choose LTE Application > Import
Data > Import Base Station Bulk Configuration Data (CME client mode), to
import the summary data file into the CME, and then start the data verification.
5. Choose CME > Planned Area > Export Incremental Scripts (U2000 client mode),
or choose Area Management > Planned Area > Export Incremental Scripts (CME
client mode), to export and activate the incremental scripts.
On the CME, set the parameters listed in the "Data Preparation" section for a single
eNodeB. The procedure is as follows:
1. In the planned data area, click Base Station in the upper left corner of the
configuration window.
2. In area 1 shown in Figure 8-1, select the eNodeB to which the MOs belong.
Figure 8-1 MO search and configuration window
NOTE:
• To view descriptions of the parameters in the MO, press F1 in area 4.
• Area 5 displays the details of a selected area-4 entry in vertical format. Click Details to show
or hide this area.
3. On the Search tab page in area 2, enter an MO name, for example, CELL.
4. In area 3, double-click the MO in the Object Name column. All parameters in this
MO are displayed in area 4.
5. Set the parameters in area 4 or 5.
6. Choose CME > Planned Area > Export Incremental Scripts (U2000 client mode) or
choose Area Management > Planned Area > Export Incremental Scripts (CME
client mode), to export and activate the incremental scripts.
For details about how to observe features such as power control, load control, transport
resource management, mobility management, scheduling, load balancing, and congestion
control, see related feature parameter description documents.
This section describes how to determine that the bearers of related QCIs have been set up
properly.
Before you perform the observation, ensure that a standardized QCI (such as QCI 9) has
been configured on the HSS for the default bearer.
Verify the QoS parameter settings for a default bearer as follows:
1. Start an S1 tracing task as follows:
On the U2000 client, choose Monitoring > Signaling Trace > Signaling Trace
Management. In the navigation tree of the Signaling Trace Management
window, choose Trace Type > LTE > Application Layer > S1 Interface Trace,
and click New.
2. Enable a UE to access the cell and ensure that the QCI for the default bearer is 9.
3. In the S1AP_INITIAL_CONTEXT_SETUP_REQ message, check the QCI of the
bearer whose e-RAB-ID is 5. If the QCI is 9, the QoS parameter settings for the
default bearer are correct, as shown in Figure 8-2.
Figure 8-2 Configuration example 1
Before you perform the observation, ensure that a dedicated bearing port has been
configured on the EPC side.
Verify the QoS parameter settings for a dedicated bearer as follows:
1. Start an S1 tracing task as follows:
On the U2000 client, choose Monitoring > Signaling Trace > Signaling Trace
Management. In the navigation tree of the Signaling Trace Management
window, choose Trace Type > LTE > Application Layer > S1 Interface Trace,
and click New.
2. Enable a UE to access the cell and ensure that a dedicated bearer with a QCI of 3 is
established for the UE.
3. In the S1AP_ERAB_SETUP_REQ message, check whether the QCI of the
requested bearer is 3. If the QCI is 3, the QOS parameter settings are correct, as
shown in Figure 8-3.
Figure 8-3 Configuration example 2
The unified service node (USN) and unified packet gateway (UGW) on the EPC must
support extended QCIs so that you can create bearers with extended QCIs. Before you
perform the observation, ensure that an extended QCI (such as QCI 131) has been
configured on the HSS for the default bearer.
If an operator does not plan to use extended QCIs, skip the following steps.
Verify the QoS parameter settings for a default bearer as follows:
1. Start an S1 tracing task as follows:
On the U2000 client, choose Monitoring > Signaling Trace > Signaling Trace
Management. In the navigation tree of the Signaling Trace Management
window, choose Trace Type > LTE > Application Layer > S1 Interface Trace,
and click New.
2. Enable a UE to access the cell and ensure that a default bearer with a QCI of 131 is
established for the UE.
3. In the S1AP_INITIAL_CONTEXT_SETUP_REQ message, check the QCI of the
bearer whose e-RAB-ID is 5. If the QCI is 131, the QoS parameter settings for the
default bearer are correct, as shown in Figure 8-4.
Figure 8-4 Configuration example 3
The USN and UGW on the EPC must support extended QCIs so that you can create
bearers with extended QCIs. Before you perform the observation, ensure that a dedicated
bearing port has been configured on the EPC side.
If an operator does not plan to use extended QCIs, skip the following steps.
Verify the QoS parameter settings for a dedicated bearer as follows:
1. Start an S1 tracing task as follows:
On the U2000 client, choose Monitoring > Signaling Trace > Signaling Trace
Management. In the navigation tree of the Signaling Trace Management
window, choose Trace Type > LTE > Application Layer > S1 Interface Trace,
and click New.
2. Enable a UE to access the cell and ensure that a dedicated bearer with a QCI of 131
is established for the UE.
In the S1AP_ERAB_SETUP_REQ message, check the QCI of the bearer whose e-
RAB-ID is 6. If the QCI is 131, the QoS parameter settings for the dedicated bearer
are correct, as shown in Figure 8-5.
Figure 8-5 Configuration example 4
EPS Bearer
Verify the QoS parameter settings for a default bearer and a dedicated bearer as follows:
1. Set the AMBR to 180 Mbit/s, the ARP to 6, and the QCI to 9 for the default bearer
of the UE.
2. Start an S1 tracing task as follows:
On the U2000 client, choose Monitoring > Signaling Trace > Signaling Trace
Management. In the navigation tree of the Signaling Trace Management
window, choose Trace Type > LTE > Application Layer > S1 Interface Trace,
and click New.
3. Enable a UE to access the cell.
4. In the S1AP_INITIAL_CONTEXT_SETUP_REQ message, check the QCI and
ARP of the bearer whose e-RAB-ID is 5 and uplink and downlink AMBRs are
both 1.8 Mbit/s. If the QCI is 9 and the ARP is 6, the QoS parameter settings for
the default bearer are correct, as shown in Figure 8-6.
Figure 8-6 Configuration example 5
8.4.7 Reconfiguration
None
8.4.8 Deactivation
Batch reconfiguration using the CME is the recommended method to deactivate a feature
on eNodeBs. This method reconfigures all data, except neighbor relationships, for
multiple eNodeBs in a single procedure. The procedure for feature deactivation is similar
to that for feature activation described in Using the CME to Perform Batch Configuration for Existing
eNodeBs. In the procedure, modify parameters according to Table 8-4, Table 8-5, and Table 8-
6.
On the CME, set parameters according to MOs listed in Table 8-4, Table 8-5, and Table 8-6.
For detailed operations, see Using the CME to Perform Single Configuration.
eNodeB-level QCIs
Run the RMV EXTENDEDQCI command to delete the extended QCI configuration.
(Optional) Run the MOD USERPRIORITY command to disable ARP scheduling.
Cell-level QCIs
Run the RMV CELLEXTENDEDQCI command to delete a data record for a cell-level
extended QCI.
Operator-level QCIs
For details about how to configure a CNOPERATOR MO using MML commands, see
RAN Sharing Feature Parameter Description.
eNodeB-level QCIs
RMV EXTENDEDQCI: ExtendedQci=131;
MOD USERPRIORITY: ArpSchSwitch= ArpPrioritySchSwitch-0;
Cell-level QCIs
RMV CELLEXTENDEDQCI: ExtendedQci=131, LocalCellId=0;
Operator-level QCIs
RMV CNOPERATOREXTENDEDQCI: CnOperatorId=1, ExtendedQci=131;
Traffic volume and the number of UEs that have data with QCIs 1 to 9 in a cell can be
monitored based on the counters in the following table.
No counter is specified for the extended QCI. If an extended QCI is specified, the number
of UEs that have data in the uplink buffer with extended QCIs and that have data in the
downlink buffer with extended QCIs can be calculated using the following formulas:
• Number of UEs that have data in the uplink buffer with extended QCIs =
L.Traffic.ActiveUser.UL.QCI.Total – Sum (L.Traffic.ActiveUser.UL.QCI.1 to
L.Traffic.ActiveUser.UL.QCI.9)
• Number of UEs that have data in the downlink buffer with extended QCIs =
L.Traffic.ActiveUser.DL.QCI.Total– Sum (L.Traffic.ActiveUser.DL.QCI.1 to
L.Traffic.ActiveUser.DL.QCI.9)
For details about these counters, see eNodeB Performance Counter Reference.
8.6 Parameter Optimization
None
8.7 Troubleshooting
Fault Description
After extended QCIs are configured, UEs cannot access the network or dedicated bearers
fail to be set up for UEs.
Fault Handling
If… Then…
If… Then…
The settings are inconsistent with the Change these settings based on the
network plan network plan.
3. On the eNodeB side, run the LST EXTENDEDQCI, LST UDTPARAGRP, and
LST UDT commands to check the extended QCIs and related parameters.
If… Then…
The parameter settings are inconsistent Change parameters based on the network
plan.
The step configuration is incorrect and the Reconfigure EPC parameters based on
QCI is not on the mapping table the network plan.
5. If the problem persists, seek help from the EPC administrator or Huawei technical
support.
9 Parameters
TDLOFD-
001015
TDLOFD- Enhanced
00101502 Scheduling
TDLBFD-
002025
TDLOFD-
001015
TDLOFD- Enhanced
00101502 Scheduling
TDLOFD-
001015
TDLOFD- Enhanced
00101502 Scheduling
TDLOFD-
001015
/ on QoS
TDLOFD- Grade
00301103
LOFD-
003016 /
TDLOFD-
003016
TDLBFD-
00201805
TDLOFD- SRVCC to
001023 GERAN
UTRAN and
CDMA2000
10 Counters
TDLBFD-
002007
11 Glossary
12 Reference Documents