PTT (Eran15.1 Draft A)

eRAN
PTT Feature Parameter Description
Issue Draft A
Date 2019-01-05
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. i

eRAN
PTT Feature Parameter Description Contents
Contents
1 Change History.............................................................................................................................. 1
1.1 eRAN15.1 Draft A (2019-01-05)................................................................................................................................... 1
2 About This Document.................................................................................................................. 3

2.1 General Statements......................................................................................................................................................... 3
2.2 Applicable RAT.............................................................................................................................................................. 4
2.3 Features in This Document.............................................................................................................................................4
2.4 Feature Differences Between FDD and TDD.................................................................................................................6
3 General Principles......................................................................................................................... 8
3.1 Introduction.................................................................................................................................................................... 8
3.2 Architecture.................................................................................................................................................................... 9
3.3 Basic Principles and Functions..................................................................................................................................... 11
3.3.1 Voice Codec............................................................................................................................................................... 11
3.3.2 Service Model Mode Management............................................................................................................................11
3.3.3 Radio Bearer Management........................................................................................................................................ 12
3.3.4 Admission and Congestion Control...........................................................................................................................14
3.3.5 Performance Optimization.........................................................................................................................................15
3.3.5.1 QoS Improvement...................................................................................................................................................15
3.3.5.2 Capacity Improvement........................................................................................................................................... 15
3.3.5.3 Coverage Enhancement.......................................................................................................................................... 15
3.3.5.4 Quality Improvement..............................................................................................................................................16
3.3.5.5 Power Consumption and Delay Improvement........................................................................................................17
3.4 MCPTT......................................................................................................................................................................... 18
4 Enhanced Extended QCI............................................................................................................ 19

4.1 Principles...................................................................................................................................................................... 19
4.2 Network Analysis......................................................................................................................................................... 20
4.2.1 Benefits...................................................................................................................................................................... 20
4.2.2 Impacts.......................................................................................................................................................................21
4.3 Requirements................................................................................................................................................................ 22
4.3.1 Licenses..................................................................................................................................................................... 22
4.3.2 Software.....................................................................................................................................................................23
4.3.3 Hardware................................................................................................................................................................... 23
4.3.4 Others.........................................................................................................................................................................24
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. ii

eRAN
4.4 Operation and Maintenance..........................................................................................................................................24

4.4.1 Data Configuration.................................................................................................................................................... 24
4.4.1.1 Data Preparation..................................................................................................................................................... 24
4.4.1.2 Using MML Commands......................................................................................................................................... 26
4.4.1.3 Using the CME to Perform Batch Configuration................................................................................................... 27
4.4.2 Activation Verification.............................................................................................................................................. 27
4.4.3 Network Monitoring.................................................................................................................................................. 28
5 PTT over eMBMS........................................................................................................................ 30

5.1 Principles...................................................................................................................................................................... 30
5.1.1 Process of Creating a DMA/DSA..............................................................................................................................31
5.1.2 Process of Updating a DMA/DSA.............................................................................................................................34
5.1.3 Process of Releasing a DMA/DSA............................................................................................................................37
5.2.1 Benefits...................................................................................................................................................................... 39
5.2.2 Impacts.......................................................................................................................................................................39
5.3 Requirements................................................................................................................................................................ 39
5.3.1 Licenses..................................................................................................................................................................... 39
5.3.2 Software.....................................................................................................................................................................39
5.3.3 Hardware................................................................................................................................................................... 40
5.3.4 Networking................................................................................................................................................................ 40
5.3.5 Others.........................................................................................................................................................................40
5.4.1.3 Using the CME....................................................................................................................................................... 48
5.4.2 Activation Observation..............................................................................................................................................48
6 MCPTT QoS Management........................................................................................................ 49

6.1 Principles...................................................................................................................................................................... 49
6.2.1 Benefits...................................................................................................................................................................... 49
6.2.2 Impacts.......................................................................................................................................................................50
6.3 Requirements................................................................................................................................................................ 50
6.3.1 Licenses..................................................................................................................................................................... 50
6.3.2 Software.....................................................................................................................................................................51
6.3.3 Hardware................................................................................................................................................................... 51
6.3.4 Networking................................................................................................................................................................ 51
6.3.5 Others.........................................................................................................................................................................52
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. iii

eRAN

6.4.1.3 Using the CME to Perform Batch Configuration................................................................................................... 52
7 Congestion Control for Public Safety......................................................................................57

7.1 Principles...................................................................................................................................................................... 57
7.2.1 Benefits...................................................................................................................................................................... 61
7.2.2 Impacts.......................................................................................................................................................................62
7.3 Requirements................................................................................................................................................................ 64
7.3.1 Licenses..................................................................................................................................................................... 64
7.3.2 Software.....................................................................................................................................................................64
7.3.3 Hardware................................................................................................................................................................... 66
7.3.4 Others.........................................................................................................................................................................66
7.4.1.3 Using the CME....................................................................................................................................................... 68
8 RRC and DRX Policy for Public Safety...................................................................................71

8.1 Principles...................................................................................................................................................................... 71
8.2.1 Benefits...................................................................................................................................................................... 72
8.2.2 Impacts.......................................................................................................................................................................72
8.3 Requirements................................................................................................................................................................ 73
8.3.1 Licenses..................................................................................................................................................................... 73
8.3.2 Software.....................................................................................................................................................................74
8.3.3 Hardware................................................................................................................................................................... 75
8.3.4 Networking................................................................................................................................................................ 75
8.3.5 Others.........................................................................................................................................................................75
8.4.1.3 Using the CME....................................................................................................................................................... 81
8.4.2 Activation Observation..............................................................................................................................................81
9 MCPTT Voice Management...................................................................................................... 83

9.1 Principles...................................................................................................................................................................... 83
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. iv

eRAN

9.2.1 Benefits...................................................................................................................................................................... 84
9.2.2 Impacts.......................................................................................................................................................................84
9.3 Requirements................................................................................................................................................................ 86
9.3.1 Licenses..................................................................................................................................................................... 86
9.3.2 Software.....................................................................................................................................................................87
9.3.3 Hardware................................................................................................................................................................... 87
9.3.4 Networking................................................................................................................................................................ 87
9.3.5 Others.........................................................................................................................................................................87
9.4.1.3 Using the CME....................................................................................................................................................... 89
10 Uplink PUSCH RB Reservation for MCPTT Voice Services............................................ 93

10.1 Principles.................................................................................................................................................................... 93
10.2 Network Analysis....................................................................................................................................................... 93
10.2.1 Benefits.................................................................................................................................................................... 93
10.2.2 Impacts.....................................................................................................................................................................94
10.3 Requirements.............................................................................................................................................................. 95
10.3.1 Licenses................................................................................................................................................................... 96
10.3.2 Software...................................................................................................................................................................96
10.3.3 Hardware................................................................................................................................................................. 96
10.3.4 Others.......................................................................................................................................................................96
10.4 Operation and Maintenance........................................................................................................................................96
10.4.1 Data Configuration.................................................................................................................................................. 97
10.4.1.1 Data Preparation................................................................................................................................................... 97
10.4.1.2 Using MML Commands....................................................................................................................................... 97
10.4.1.3 Using the CME..................................................................................................................................................... 98
10.4.2 Activation Verification............................................................................................................................................ 98
10.4.3 Network Monitoring................................................................................................................................................ 98
11 Parameters................................................................................................................................... 99
12 Counters.................................................................................................................................... 100
13 Glossary..................................................................................................................................... 101
14 Reference Documents............................................................................................................. 102
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. v

eRAN
PTT Feature Parameter Description 1 Change History
1 Change History
This chapter describes changes not included in the "Parameters", "Counters", "Glossary", and
"Reference Documents" chapters. These changes include:
l Technical changes
Changes in functions and their corresponding parameters
l Editorial changes
Improvements or revisions to the documentation
1.1 eRAN15.1 Draft A (2019-01-05)

This issue introduces the following changes to eRAN13.1 01 (2018-04-10).
Technical Changes
Change Parameter Change RAT Base Station
Description Model
Added uplink Modified the FDD l 3900 and 5900

PUSCH RB CellRbReserve.Rb TDD series base
reservation for RsvMode parameter. stations
MCPTT voice l DBS3900
services. For details, LampSite and
see 10 Uplink DBS5900
PUSCH RB LampSite
Reservation for
MCPTT Voice l BTS3912E
Services. l BTS3911E
Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 1

eRAN
PTT Feature Parameter Description 1 Change History
Change Parameter Change RAT Base Station

Description Model
Added counters. For None FDD l 3900 and 5900

details, see: TDD series base
6.4.3 Network stations
Monitoring l DBS3900
7.4.3 Network LampSite and
Monitoring DBS5900
LampSite
l BTS3912E
l BTS3911E
Modified MCPTT Added the FDD l 3900 and 5900

voice optimization McpttVoiceCaSwit TDD series base
in CA scenarios. For ch option to the stations
details, see 3.3.5.4 CaMgtCfg.CellCaA l DBS3900
Quality lgoSwitch LampSite and
Improvement. parameter. DBS5900
LampSite
l BTS3912E
l BTS3911E
Added the impacts None FDD l 3900 and 5900

of PTT functions on series base
the short TTI stations
function. For details, l DBS3900
see the LampSite and
corresponding DBS5900
"Impacts" sections. LampSite
l BTS3912E
l BTS3911E
Editorial Changes
Change Description RAT
Modified MML command examples. For FDD

details, see 10.4.1.2 Using MML TDD
Commands.
Added the impacts of MCPTT QoS FDD

management on eMTC introduction. For TDD
details, see 6.2.2 Impacts.

eRAN
PTT Feature Parameter Description 2 About This Document
2 About This Document
2.1 General Statements

Purpose
This document is intended to acquaint readers with:
l The technical principles of features and their related parameters
l The scenarios where these features are used, the benefits they provide, and the impact
they have on networks and functions
l Requirements of the operating environment that must be met before feature activation
l Parameter configuration required for feature activation, verification of feature activation,
and monitoring of feature performance
NOTE
This document only provides guidance for feature activation. Feature deployment and feature
gains depend on the specifics of the network scenario where the feature is deployed. To achieve
the desired gains, contact Huawei professional service engineers.
Software Interfaces
Any parameters, alarms, counters, or managed objects (MOs) described in this document
apply only to the corresponding software release. For future software releases, refer to the
corresponding updated product documentation.
Trial Features
Trial features are features that are not yet ready for full commercial release for certain
reasons. For example, the industry chain (terminals/CN) may not be sufficiently compatible.
However, these features can still be used for testing purposes or commercial network trials.
Anyone who desires to use the trial features shall contact Huawei and enter into a
memorandum of understanding (MoU) with Huawei prior to an official application of such
trial features. Trial features are not for sale in the current version but customers may try them
for free.
Customers acknowledge and undertake that trial features may have a certain degree of risk
due to absence of commercial testing. Before using them, customers shall fully understand not

eRAN
only the expected benefits of such trial features but also the possible impact they may exert on
the network. In addition, customers acknowledge and undertake that since trial features are
free, Huawei is not liable for any trial feature malfunctions or any losses incurred by using the
trial features. Huawei does not promise that problems with trial features will be resolved in
the current version. Huawei reserves the rights to convert trial features into commercial
features in later R/C versions. If trial features are converted into commercial features in a later
version, customers shall pay a licensing fee to obtain the relevant licenses prior to using the
said commercial features. If a customer fails to purchase such a license, the trial feature(s)
will be invalidated automatically when the product is upgraded.
Feature Differences Between RATs

The feature difference section only describes differences in switches or principles.
Unless otherwise stated, descriptions in this document apply to all RATs. If a description does
not apply to all RATs, the specific RAT that it does apply to will be stated.
For example, in the statement "TDD cells are compatible with enhanced MU-MIMO", "TDD
cells" indicates that this function cannot be used in non-TDD cells.
2.2 Applicable RAT

This document applies to FDD/TDD.
2.3 Features in This Document

This document describes the following FDD features.
Feature ID Feature Name Section
LBFD-131110 Support of PTT 4 Enhanced Extended QCI

5 PTT over eMBMS
6 MCPTT QoS
Management
7 Congestion Control for
Public Safety
8 RRC and DRX Policy
for Public Safety
9 MCPTT Voice
Management
10 Uplink PUSCH RB
Reservation for MCPTT
Voice Services
LOFD-081218 Enhanced Extended QCI 4 Enhanced Extended QCI
LOFD-110201 PTT over eMBMS 5 PTT over eMBMS
LTROFD-111201 MCPTT QoS Management 6 MCPTT QoS

Management

eRAN
LTROFD-111202 Congestion Control for 7 Congestion Control for

Public Safety Public Safety
LTROFD-111203 RRC and DRX Policy for 8 RRC and DRX Policy
Public Safety for Public Safety
LTROFD-111204 MCPTT Voice Management 9 MCPTT Voice

Management
This document describes the following TDD features.
TDLBFD-110101 Support of PTT 4 Enhanced Extended QCI

5 PTT over eMBMS
6 MCPTT QoS
Management
7 Congestion Control for
Public Safety
8 RRC and DRX Policy
for Public Safety
9 MCPTT Voice
Management
10 Uplink PUSCH RB
Reservation for MCPTT
Voice Services
TDLOFD-110230 Enhanced Extended QCI 4 Enhanced Extended QCI

(Trial)
TDLOFD-110203 PTT over eMBMS 5 PTT over eMBMS
TDLOFD-121103 MCPTT QoS Management 6 MCPTT QoS

Management
TDLOFD-121104 Congestion Control for 7 Congestion Control for

Public Safety Public Safety
TDLOFD-121105 RRC and DRX Policy for 8 RRC and DRX Policy
Public Safety for Public Safety
TDLOFD-121106 MCPTT Voice Management 9 MCPTT Voice

Management

eRAN
2.4 Feature Differences Between FDD and TDD

FDD FDD TDD TDD Difference Section
Feature ID Feature Feature ID Feature
Name Name
LBFD-1311 Support of TDLBFD-11 Support of None 4 Enhanced

10 PTT 0101 PTT Extended
QCI
5 PTT over
eMBMS
6 MCPTT
QoS
Manageme
nt
7
Congestion
Control for
Public
Safety
8 RRC and
DRX Policy
for Public
Safety
9 MCPTT
Voice
Manageme
nt
10 Uplink
PUSCH RB
Reservation
for MCPTT
Voice
Services
LOFD-0812 Enhanced TDLOFD-11 Enhanced None 4 Enhanced

18 Extended 0230 Extended Extended
QCI QCI (Trial) QCI
LOFD-1102 PTT over TDLOFD-11 PTT over None 5 PTT over

01 eMBMS 0203 eMBMS eMBMS
LTROFD-11 MCPTT TDLOFD-1 MCPTT None 6 MCPTT

1201 QoS 21103 QoS QoS
Management Management Manageme
nt

eRAN
FDD FDD TDD TDD Difference Section

Feature ID Feature Feature ID Feature
Name Name
LTROFD-11 Congestion TDLOFD-1 Congestion When the 7

1202 Control for 21104 Control for congestion Congestion
Public Public control for Control for
Safety Safety public safety Public
is enabled Safety
for FDD, the
McpttMsgC
ntSwitch
parameter
can be
configured.
This feature
is not
supported by
TDD.
LTROFD-11 RRC and TDLOFD-1 RRC and None 8 RRC and

1203 DRX Policy 21105 DRX Policy DRX Policy
for Public for Public for Public
Safety Safety Safety
LTROFD-11 MCPTT TDLOFD-1 MCPTT None 9 MCPTT

1204 Voice 21106 Voice Voice
Management Management Manageme
nt

eRAN
PTT Feature Parameter Description 3 General Principles
3 General Principles
3.1 Introduction
PTT services are group voice communication services, which originate from the Trunked
Radio System (TRS) and can be provided in an analog or digital TRS. PTT services that are
based on the cellular mobile communication network and use the Voice over Internet Protocol
(VoIP) technique are also called push-to-talk over cellular (PoC) services. Huawei PTT is a
voice solution based on the PoC standard provided by Open Mobile Alliance (OMA).
LTE PTT provides group voice communication services that are carried on an IP transport
network and set up between multiple UEs and the PTT server on an LTE network. Huawei
provides LTE integrated Trunked Radio Access (LiTRA), a complete solution (comprising the
PTT server) based on LTE networks to meet PTT service requirements.
LTE PTT is referred to as PTT herein. PTT services comprise common PTT services (in non-
public safety scenarios) and mission-critical push-to-talk (MCPTT) services (in public safety
scenarios). The application scenarios of the two types of PTT services are as follows:
l Common PTT services: in scenarios such as petrol stations, plants, and gatherings.
l MCPTT services: in scenarios such as anti-terrorism, emergency services, and disaster
relief.
Figure 3-1 shows the service networking for PTT.

eRAN
Figure 3-1 Service networking for PTT
Among a UE group (containing UEs A, B, C, D, and E) shown in Figure 3-1, after UE B

initiates a group call, UEs A, C, D, and E can receive the session content from UE B at the
same time. Once the session initiated by UE B ends, the floor is preempted by UE A, C, D, or
E.
3.2 Architecture
Figure 3-2 shows the NE networking for PTT.
Figure 3-2 NE networking for PTT
Table 3-1 describes the function of each NE for PTT.

eRAN
Table 3-1 Function of each NE for PTT

NE Function
GCS AS Indicates the group communication service application server (GCS

AS), which processes signaling and exchanges data for calls at the
PTT application layer. The GCS AS functions as the PTT server.
PTT UE Carries the UE group communication service enabler (GCSE)

application module to implement PTT. The UE GCSE application is
an application on a common UE and is used to transmit and receive
PTT services.
eNodeB Receives PTT service data sent from the evolved packet core (EPC)
and forwards the data to PTT UEs over the Uu interface.
Receives uplink data from PTT UEs and forwards the data to the
EPC.
EPC l Responsible for connection management and mobility

management for PTT UEs.
l Manages dedicated bearers for PTT services, identifies PTT
service packets, and receives and forwards application-layer
packets sent from the PTT server and PTT UEs.
PCRF Indicates the policy and charging rules function (PCRF), which
controls dynamic QoS policies of PTT services.
HSS Indicates the home subscriber server (HSS), which stores

subscription data about IP multimedia subsystem (IMS) users on a
home network.
Provides management interfaces for operators and end users to
customize and modify subscription data.
The HSS stores the following information: IMS subscriber identity,
security context, routes, and service subscription.
MCE l Receives Multimedia Broadcast Multicast Service (MBMS)

session control messages from the GCS AS and transfers these
messages to eNodeBs.
l Coordinates radio resources on eNodeBs and ensures that the
same radio resources are occupied by each cell in a single
MBSFN area (MA). MBSFN stands for Multimedia Broadcast
multicast service Single Frequency Network.
l Manages MBMS sessions.
l Processes signaling over the MGs interface between the multi-
cell/multicast coordination entity (MCE) and the GCS AS, and
configures dynamic MBSFN areas (DMAs) and dynamic service
areas (DSAs).
MBMS GW Indicates the Multimedia Broadcast Multicast Service (MBMS)

gateway, which transfers MBMS session control messages to the
EPC and forwards MBMS service data to eNodeBs.

eRAN
NE Function
BM-SC Indicates the broadcast/multicast service center (BM-SC), which

authenticates and registers PTT sessions and manages broadcast/
multicast session resources.
3.3 Basic Principles and Functions
3.3.1 Voice Codec

The PTT server and UEs negotiate and determine the voice codec scheme to be used. The
negotiated process is unperceivable to the RAN. The commonly used voice codec
technologies in the industry are Low Bitrate Codec (iLBC) and adaptive multirate codec
(AMR codec). Huawei PTT server uses AMR codec to negotiate with UEs and uses it as the
voice codec technology for PTT services.
3.3.2 Service Model Mode Management

The PTT service model provides the offline mode, online idle mode, and online calling mode,
as shown in Figure 3-3.
Figure 3-3 PTT service model modes
l PTT offline mode

This is the initial mode of a PTT UE. A PTT UE can neither initiate nor receive calls in
this mode. A user needs to register first (by entering a user name and password for login)
and performs PTT services only when the registration is successful.
l PTT online idle mode
In this mode, PTT UEs have been registered successfully. A PTT UE can actively initiate
a new group call session, join an existing group call session, or wait to be invited into a
group call session by another UE.

eRAN
l PTT online calling mode

In this mode, a PTT UE has joined a call session. UEs in the group session perform
group communications. Only one UE can initiate a call and the other UEs can only
receive the call at the same time. UEs can apply for the floor only after the previous UE
releases the floor. If none of the UEs in the session has applied for the floor, the session
will be in the floor-idle mode.
In conclusion, the online calling mode is divided into three sub-modes:
– Media sending mode: In this mode, a PTT UE sends voice data to the PTT server
every 20 ms.
– Media receiving mode: The PTT server copies the received voice data and quickly
sends multiple data copies to other PTT UEs in the receiving mode in the group.
– Floor-idle mode: The PTT server and UEs stop sending data.
NOTE
All the preceding data is media data and complies with Real-Time Transport Protocol (RTP). In addition,
in the calling mode, handover signaling for controlling PTT UE modes is generated. The signaling is
triggered by events, complies with Real-Time Transport Control Protocol (RTCP), and is not under the
restrictions of the preceding modes.
3.3.3 Radio Bearer Management

QoS requirements vary with services, and therefore different QCI bearer configuration
policies are used for different services. Section 6.1.7 "Standardized QoS characteristics" of
3GPP TS 23.203 V13.3.0 defines standardized QCIs, including priorities, transmission delay,
and packet loss rate. Extended QCIs (non-standardized QCIs) are generally defined by
operators.
There are currently no standards for dedicated bearer configuration policies for PTT services.
Operators must specify separate bearer management policies on the EPC and eNodeB sides
based on service types supported by the PTT server and user characteristics of PTT services.
Table 3-2 describes the advantages, disadvantages, and recommended scenarios for different
bearer management policies.
Table 3-2 PTT bearer management policies

Bearer Advantage Disadvantage Recommended Scenario
Management
Policy
Using default The QoS is not This policy is used when PTT
bearers configurations guaranteed and UEs have low reliability
are simple, services are not requirements or when the
reducing prioritized. number of UEs is small
signaling during initial LTE network
interactions. deployment.

eRAN
Bearer Advantage Disadvantage Recommended Scenario

Management
Policy
Using dedicated This policy There are currently This policy is used when UEs
bearers with applies to no standardized have high reliability
standardized various types of QCIs dedicated to requirements and the
QCIs (1 to 9) UEs, and PTT voice services. extended QCI feature is not
different QoS Therefore, QCI supported.
priorities can be conflict will occur
configured for with other services.
PTT services.
Using dedicated High QoS UEs must support UEs have extremely high
bearers with priorities can be extended QCIs. reliability requirements, and
extended QCIs configured for standardized QCIs have been
PTT services planned or reserved for other
and no QCI services.
conflict will
occur with
other
standardized-
QCI services.
Using bearers High QoS UEs must support Operators in national public
with priorities can be standardized QCIs safety scenarios have the
standardized configured for 65, 66, 69, and 70. highest reliability and
QCIs 65, 66, PTT services emergency requirements, and
69, and 70 and no QCI standardized QCIs 65, 66, 69,
conflict will 70 can be used in such
occur with scenarios.
other
standardized-
QCI services.
NOTE
If a non-Huawei EPC is used, mapping tests must be performed between the EPC and Huawei eNodeBs
before an operator configures PTT bearer management policies.
PTT service data includes control signaling data and user media data. Table 3-3 provides an
example of dedicated bearer configurations for PTT services based on Huawei LiTRA
solution.
Table 3-3 Example of dedicated bearer configurations for PTT services based on Huawei
LiTRA solution.
Data Type QCI Bearer Configuration GBR Attribute
Call control Standardized QCI (69) Non-GBR

signaling

eRAN
Data Type QCI Bearer Configuration GBR Attribute
Floor control Standardized QCI (65 or 66) GBR

signaling
Voice media Standardized QCI (65 or 66) GBR

data
Video media Standardized QCI (6, 7, or 8) Non-GBR

data
File media data Standardized QCI (70) Non-GBR
NOTE
Call control signaling is used for negotiation and adjustment of PTT service attributes (such as the voice
codec scheme) before PTT UEs perform PTT services. Floor control signaling is a type of PTT service
data that PTT UEs use to apply for and release the floor when performing PTT services.
3.3.4 Admission and Congestion Control

The eNodeB monitors indicators such as the physical resource block (PRB) usage and the
QoS satisfaction rate of GBR services of a cell to learn its status. Based on the monitoring
results, the eNodeB determines whether to admit GBR services. Once congested, the eNodeB
releases GBR services with low allocation/retention priorities (ARPs) to guarantee QoS of
other services accessing the eNodeB. The QciPara.FlowCtrlType parameter specifies the
flow control mechanism for a type of service based on the QCI for the bearer that carries the
services.
Admission and congestion control for PTT services is conducted as follows:
l If PTT services are carried on the bearer with a QCI configured for non-GBR services,
admission and congestion control rules for non-GBR services are used for PTT services.
For details, see Admission and Congestion Control.
l If PTT services are carried on the bearer with a QCI configured for GBR services:
– The eNodeB measures the QoS satisfaction rate separately for QCI 65 and
determines whether to perform admission and congestion control for services
carried on QCI 65 bearers based on the satisfaction rate. The eNodeB calculates the
satisfaction rates for PTT services with QCIs 1 and 66 and enhanced extended
QCIs, and then determines whether to perform admission and congestion control
based on the threshold for QCI 1 VoLTE services.
– The CellQciPara.HandoverAdmissionThreshold parameter set for QCI 65
indicates the threshold for admitting incoming services carried on QCI 65 bearers
based on the QoS satisfaction rate. The
CellQciPara.HandoverAdmissionThreshold parameter set for QCI 66 indicates the
threshold for admitting incoming services carried on QCI 66 bearers based on the
QoS satisfaction rate. The CellQciPara.HandoverAdmissionThreshold parameter
set for QCI 1 indicates the threshold for admitting incoming services carried on
bearers with enhanced extended QCIs based on the QoS satisfaction rate.
– The CellQciPara.CongestionThreshold parameter set for QCI 65 indicates the
congestion threshold for QCI 65 services, and that set for QCI 1 indicates the
congestion threshold for services with QCI 66 or enhanced extended QCIs. For the
related principles, see Admission and Congestion Control.

eRAN
When PTT services are voice services, the PTTOffloadSwitch option of the
CellAlgoSwitch.MlbAlgoSwitch parameter can be used to enable PTT voice service offload,
reducing the cell load and relieving congestion. Before enabling the function, select the
VoIPOffloadSwitch option of the CellAlgoSwitch.MlbAlgoSwitch parameter. For details
about the technical description, see Intra-RAT Mobility Load Balancing.
3.3.5 Performance Optimization
3.3.5.1 QoS Improvement

When non-GBR policies are used for PTT services, other non-GBR services and even GBR
services (such as VoLTE services) may exist in LTE cells. This increases PTT service delay,
causes QoS deterioration, and affects user experience. In this situation, the QoS bearer
policies for PTT services must be adjusted, including using GBR policies and raising the
scheduling priority, to improve PTT QoS.
3.3.5.2 Capacity Improvement

The following functions can be enabled to increase the capacity for PTT services:
l Robust header compression (ROHC)

ROHC reduces the number of bytes of headers of PTT service packets, reducing air-
interface overhead and increasing the service capacity. For details about ROHC, see
ROHC Feature Parameter Description.
l Semi-persistent scheduling
When the eNodeB capacity is limited because CCEs for the PDCCH are insufficient,
semi-persistent scheduling can be used to reduce PDCCH resource overhead, increasing
the service capacity. Uplink semi-persistent scheduling is controlled by the
EnhExtQCISpsSchSwitch option of the CellAlgoSwitch.UlSchExtSwitch parameter,
and downlink semi-persistent scheduling is controlled by the EnhExtQCISpsSchSwitch
option of the CellAlgoSwitch.DlSchSwitch parameter. For details about semi-persistent
scheduling, see VoLTE Feature Parameter Description.
NOTE
If multiple bearers can be set up for a UE, semi-persistent scheduling takes effect only when there
is only one voice bearer, one bearer for voice SIP control messages, and no more than one data
service bearer. Uplink semi-persistent scheduling takes effect only when no data is being
transmitted on the data service bearer.
l Evolved multimedia broadcast/multicast service (eMBMS)
When eMBMS is used, UEs in a group use the same resources to receive service data,
increasing the service capacity. For details about eMBMS, see eMBMS Feature
Parameter Description.
3.3.5.3 Coverage Enhancement

Operators can enable the following functions to improve PTT service coverage in weak
coverage areas:
l ROHC
ROHC reduces the number of bytes of headers of PTT service packets to shorten the
length of PTT service packets. As a result, fragmentation is reduced to ensure correct

eRAN
packet transmission at a higher probability, improving coverage of PTT services at cell

edges. For details about ROHC, see ROHC Feature Parameter Description.
l TTI bundling
When the channel quality of UEs is poor at the cell edge, TTI bundling can be used. It
enables a data block to be transmitted in four consecutive TTIs, which are bound
together and treated as the same resource. Different hybrid automatic repeat request
(HARQ) redundancy versions of the same data block are transmitted in different TTIs.
TTI bundling makes full use of HARQ combining gains to improve cell edge coverage.
TTI bundling is controlled by the EnhExtQCITtiBundlingSwitch option of the
CellAlgoSwitch.UlSchExtSwitch parameter. For details about TTI bundling, see VoLTE
Feature Parameter Description.
3.3.5.4 Quality Improvement

The following functions can be enabled to improve quality of PTT voice services and improve
user experience:
l Uplink compensation scheduling for PTT services

Uplink compensation scheduling for PTT services is a technique in which an eNodeB
identifies PTT UEs and measures the duration in which a UE is not scheduled in the
uplink. If the duration reaches a threshold, the eNodeB sends a UL Grant to the UE to
ensure that uplink voice packets can be transmitted in a timely manner. In this way, this
function shortens the waiting time of voice packets and reduces the number of packets
discarded because of the expiry of PDCP Discard Timer. This function is controlled by
the UlPttSchOptSwitch option of the CellAlgoSwitch.UlSchExtSwitch parameter.
l Voice characteristic awareness scheduling
Voice characteristic awareness scheduling includes uplink delay-based dynamic
scheduling and estimation of the PTT data volume for uplink dynamic scheduling.
For uplink delay-based dynamic scheduling, an eNodeB prioritizes voice packets based
on their waiting time. Ranking scheduling priorities based on delay for PTT services
brings balanced scheduling sequence. This helps improve PTT voice quality.
Specifically, voice quality improves for UEs with poor channel quality that are far from
the cell center. Uplink delay-based dynamic scheduling is enabled by setting the
CellUlschAlgo.UlDelaySchStrategy parameter to VOIP_DELAYSCH(VoIP Service
Delay Scheduling).
With estimation of the PTT data volume for uplink dynamic scheduling, an eNodeB
calculates the PTT data volume for uplink dynamic scheduling based on the PTT service
model and the uplink scheduling interval. This ensures that the scheduling is completed
at a time, reducing delay and improving PTT voice quality. Estimation of the PTT data
volume for uplink dynamic scheduling is enabled by selecting the
UlPttDataSizeEstSwitch option of the CellAlgoSwitch.UlSchExtSwitch parameter.
l Voice-specific AMC
With voice-specific AMC, an eNodeB adjusts the signal to interference plus noise ratio
(SINR) based on the specified target uplink initial block error rate (IBLER) for PTT UEs
adopting uplink dynamic scheduling, and then performs initial MCS selection to ensure
transmission reliability and improve PTT voice quality. The
CellQciPara.SinrAdjustTargetIbler parameter specifies the target uplink IBLER for
PTT voice UEs. This parameter takes effect only on PTT voice UEs not in the TTI
bundling state.

eRAN
NOTE
If the CellQciPara.SinrAdjustTargetIbler parameter value is changed, it does not take effect

immediately on a UE that has already accessed the cell. It takes effect on such a UE only after a
service of the UE is established, modified, or released.
l TBS-based MCS selection for downlink PTT services
The PTT_TBS_BASED_MCS_SEL_SWITCH option of the
CellAlgoSwitch.DlSchExtSwitch parameter controls this function. When this option is
selected, an eNodeB checks the number of online UEs and IBLER and then determines
whether to apply the TBS-based MCS selection function to PTT services. If the function
takes effect, the eNodeB makes decisions based on the packet size during a PTT voice
call to select a relatively low MCS while ensuring that the number of RBs remains
unchanged. In this way, IBLER is reduced.
l MCPTT voice optimization in CA scenarios
Optimization is performed for MCPTT voice services in CA scenarios, specifically as
follows:
– When the SccBlindCfgSwitch option of the eNodeBAlgoSwitch.CaAlgoSwitch
parameter is deselected, UEs that have already initiated PTT voice services do not
enter the CA state. The GAP measurement is not delivered to these UEs when the
eNodeB configures SCells. When the option is selected, UEs that have already
initiated PTT voice services can enter the CA state.
– The McpttVoiceCaSwitch option of the CaMgtCfg.CellCaAlgoSwitch parameter
can be used to specify whether MCPTT UEs can perform inter-frequency
measurements for SCell configuration or PCC anchoring for RRC_CONNECTED
UEs.
NOTE
The PTT service model (interval for sending data packets and packet size) is similar to that of VoLTE
services. Therefore, you can refer to VoLTE to learn details about the preceding functions.
3.3.5.5 Power Consumption and Delay Improvement

PTT services burst out more frequently and last longer than common voice services.
Therefore, PTT UEs use independent RRC and DRX policies to reduce access delay and UE
power consumption.
This function provides three timers:
l UE Inactive Timer for QCI (QciPara.UeInactiveTimerForQci parameter)

This timer can be independently set for QCIs of bearers used to carry PTT services, so
that RRC connections over the air interface can be maintained for a long period of time.
This ensures that calls are set up quickly when PTT UEs initiate calls again and reduces
the delay in preempting the floor. In this situation, the existing UE inactivity timer
controls only non-PTT UEs.
l UE Inactivity Timer Dynamic DRX for QCI (QciPara.UeInactivityTimerDynDrxQci
parameter)
This timer is used as the inactivity timer for PTT UEs when the
CellAlgoSwitch.DynDrxSwitch parameter is set to ON(On).
l Uplink Synchronization Timer for QCI (QciPara.UlSynTimerForQci parameter)
This timer can be set for PTT UEs when the CellAlgoSwitch.DynDrxSwitch parameter
is set to OFF(Off) or UEs do not support DRX. When this timer expires, UEs enter the

eRAN
out-of-synchronization state and no longer occupy PUCCH and SRS resources, reducing
power consumption.
NOTE
The value of the QciPara.UlSynTimerForQci parameter should be less than that of the
QciPara.UeInactiveTimerForQci parameter, so that PTT UEs enter the out-of-synchronization state
earlier, reducing UE power consumption and ensuring that UEs are in RRC_CONNECTED mode.
3.4 MCPTT
MCPTT services apply to special scenarios and have higher QoS requirements than common
PTT services. Section 6.1.7 "Standardized QoS characteristics" in 3GPP TS 23.203 V13.3.0
defines QCIs 65, 66, 69, and 70, which are used to carry control signaling and media data
services of MCPTT services. QCIs 65 and 66 are used to carry MCPTT voice media data,
QCI 69 is used to carry control signaling for MCPTT service setup, and QCI 70 is used to
carry MCPTT video and file media services. 3GPP TS 23.203 also provides QoS
requirements of various MCPTT services, such as priority, delay, and packet loss rate.

eRAN
PTT Feature Parameter Description 4 Enhanced Extended QCI
4 Enhanced Extended QCI
4.1 Principles
Enhanced extended QCIs have higher scheduling priorities than extended QCIs, enhancing
the reliability of services carried on bearers with extended QCIs. Higher priorities are
assigned to PTT services with enhanced extended QCIs than those with extended QCIs.
Operators can enable enhanced extended QCI by setting the

CellAlgoSwitch.LtePttQoSSwitch parameter and determine whether an enhanced extended
QCI is used as the dedicated QCI for PTT services by setting the
QciPara.LtePttDedicatedExtendedQci parameter. The following functions are adopted to
improve experience of PTT services carried on bearers with enhanced extended QCIs:
l Functions described in 3.3.4 Admission and Congestion Control are used to ensure the
QoS satisfaction rate of PTT services in congestion scenarios.
l PTT services with enhanced extended QCIs can adopt GBR policies and use the same
uplink and downlink scheduling priorities as QCI 1 VoLTE services by default. The
uplink and downlink scheduling priorities of PTT services can be adjusted using the
QciPara.LtePttUplinkPriority and QciPara.LtePttDownlinkPriority parameters,
respectively, to improve the QoS of PTT services.
NOTE
When the QciPara.LtePttUplinkPriority and QciPara.LtePttDownlinkPriority parameters are set

to HIGHER_PRI_THAN_QCI1, the priority of PTT services with enhanced extended QCIs is
higher than that of QCI 1 services only if the GlobalProcSwitch.LcgProfile parameter is set to
LCG_PROFILE_0.
l Functions described in 3.3.5.2 Capacity Improvement, 3.3.5.3 Coverage
Enhancement, and 3.3.5.4 Quality Improvement are used to improve the PTT service
capacity, coverage, and voice quality, respectively.
l Functions described in 3.3.5.5 Power Consumption and Delay Improvement are used
to reduce PTT service access delay and UE power consumption.
When using GBR policies, PTT services with enhanced extended QCIs have higher priorities
than non-PTT services and can preempt resources of non-PTT services. However, to prevent
PTT services from preempting resources without restrictions, operators can use dynamic
resource reservation to limit the ratio of resources that can be used by PTT services. Dynamic
resource reservation is controlled by the PttAcSwitch option of the

eRAN
CellAlgoSwitch.RacAlgoSwitch parameter and works based on the uplink and downlink PRB
usages of PTT services:
l If the uplink or downlink PRB usage of PTT services on the live network is greater than
the value of CellOp.OpPttUlRbHighThd or CellOp.OpPttDlRbHighThd, respectively,
new PTT services will not be admitted in the uplink or downlink.
l If the uplink or downlink PRB usage of PTT services on the live network is less than the
value of CellOp.OpPttUlRbLowThd or CellOp.OpPttDlRbLowThd, respectively, new
PTT services are admitted in the uplink or downlink.
NOTE
Dynamic resource reservation applies only to PTT services carried on bearers with enhanced extended
QCIs.
The prerequisite for activating this function is that PTT services can be carried on dedicated
bearers with extended QCIs. IP data of PTT services triggers the setup of bearers with
extended QCIs. The related engineering guidelines are described in EPC documentation.
Before enabling this function, perform the following operations to collect the required
information:
1. Check that PTT services with default QCIs are running properly on the live network, and
check the uplink and downlink bandwidths of PTT services and port numbers in use.
2. Check the expected extended QCI to be used and ensure that this extended QCI is
dedicated to PTT services. In RAN sharing scenarios, check that other operators are
using this QCI.
3. Check that GlobalProcSwitch.LcgProfile is set to LCG_PROFILE_0 for the operator's
network.
Before enabling dynamic resource reservation, ROHC, semi-persistent scheduling, TTI

bundling, UL compensation scheduling, voice characteristic awareness scheduling, and voice-
specific AMC for PTT services with enhanced extended QCIs, TBS-based MCS selection for
downlink PTT services, and PTT voice service offload, check whether all operators have PTT
service requirements and collect the proportion of resources each operator expects to allocate
to PTT services in RAN sharing scenarios.
4.2 Network Analysis
4.2.1 Benefits
Operators are advised to activate enhanced extended QCIs when they meet the prerequisite of
enabling extended QCIs and can provide high QoS priorities for PTT services with extended
QCIs.
This function is not recommended in the following scenarios:
l LTE UEs on the operator's network do not support extended QCIs, and EPC devices are
not provided by Huawei.
l The operator's network provides PTT services but the operator does not have high QoS
requirements for the PTT services.
l GlobalProcSwitch.LcgProfile is set to LCG_PROFILE_1 or LCG_PROFILE_2 for
the operator's network.

eRAN
With this function, PTT services are carried on bearers of enhanced extended QCIs to ensure
the high QoS priorities for such PTT services. Additionally, when bearers with enhanced
extended QCIs are used to carry PTT voice services, the coverage and cell capacity of such
services are improved.
4.2.2 Impacts
Network Impacts
l Power consumption and delay improvement
When dynamic DRX is disabled:
– A smaller value of the QciPara.UeInactiveTimerForQci parameter indicates that
RRC connections of UEs not performing PTT services are released earlier. This
results in frequent RRC connection setup requests initiated by UEs and improves
network KPIs, such as the service drop rate, due to more normal releases.
– A larger value of the QciPara.UeInactiveTimerForQci parameter indicates that
RRC connections of UEs not performing PTT services are released later. This
results in more radio resource consumption because such UEs will stay in
connected mode longer. In addition, network KPIs, such as the service drop rate,
deteriorate due to fewer normal releases.
– A smaller value of the QciPara.UlSynTimerForQci parameter indicates a higher
probability that UEs enter the out-of-synchronization state, increasing the number
of random accesses for maintaining the uplink synchronization and increasing
signaling load caused by the random accesses.
– A larger value of the QciPara.UlSynTimerForQci parameter indicates that UEs
cannot enter the out-of-synchronization state in time, affecting UE power
consumption and occupying additional PUCCH and SRS resources.
When dynamic DRX is enabled:
– A smaller value of the QciPara.UeInactivityTimerDynDrxQci parameter indicates
that RRC connections of UEs not performing PTT services are released earlier. This
results in frequent RRC connection setup requests initiated by UEs and improves
network KPIs, such as the service drop rate, due to more normal releases.
– A larger value of the QciPara.UeInactivityTimerDynDrxQci parameter indicates
that RRC connections of UEs not performing PTT services are released later. This
results in more radio resource consumption because such UEs will stay in
connected mode longer. In addition, network KPIs, such as the service drop rate,
deteriorate due to fewer normal releases.
l PTT voice service offload

In multi-band networks overloaded with PTT voice services, enabling the PTT voice
service offload function increases the initial E-RAB setup success rate of PTT voice
services when admission control is activated, while decreases the packet loss rate of PTT
voice services when admission control is not activated.
For detailed network impacts of the following functions, see 9.2.2 Impacts.
l ROHC
l TTI bundling

eRAN
l Uplink compensation scheduling

Function Impacts
RAT Function Function Reference Description
Name Switch
FDD ROHC CellAlgoS ROHC ROHC increases the network

TDD witch.Roh capacity and coverage when
cSwitch enhanced extended QCIs are used.
FDD Short TTI SHORT_T Short TTI The eNodeB does not schedule a
TI_SW (FDD) UE in short TTI mode if a PTT
option of bearer has been set up for this UE.
the If a PTT bearer is set up during
CellShort short TTI scheduling, the eNodeB
TtiAlgo.Stt immediately stops short TTI
iAlgoSwitc scheduling for this UE.
h
parameter
4.3 Requirements
4.3.1 Licenses
The operator has purchased and activated the license control items listed in the following
table.
RAT Feature ID Feature Name Model Sales Unit
FDD LOFD-081218 Enhanced LT1S0EEQCI0 Per cell

Extended QCI 0
TDD TDLOFD-1102 Enhanced LT1SEEQCI00 Per cell

30 Extended QCI 0
NOTE
Enhanced extended QCI is also under license control on Huawei MME and S-GW. For details, see the
related EPC documentation.

eRAN
4.3.2 Software
Prerequisite Functions
Name Switch
FDD Extended None QoS The enhanced extended QCI is

TDD QCI Manageme dependent on the function
nt architecture of the extended QCI.
Mutually Exclusive Functions

None
4.3.3 Hardware
Base Station Models

No requirements
Boards
None
RF Modules
None
Cells
PTT services have bandwidth requirements. Therefore, the uplink and downlink rates of cell
edge users (CEUs) must meet the minimum requirements for PTT services to guarantee user
experience. Table 4-1 lists the requirements on the uplink and downlink rates for CEUs.
Table 4-1 Requirements on the uplink and downlink rates for CEUs
Scenario Better User Experience Basic User Experience
Uplink rate ≥ 55 kbit/s ≥ 40 kbit/s
Downlink rate ≥ 55 kbit/s ≥ 40 kbit/s
NOTE
The rates vary based on PTT devices because the codec formats and transmission models are different
between vendors. The rates in Table 4-1 are for Huawei PTT devices. For details about the rates
supported by devices from other vendors, contact related PTT vendors.

eRAN
4.3.4 Others
One of the following requirements must be met:
l UEs must support extended QCIs.

l Huawei EPC devices are used.
Huawei EPC devices can map extended QCIs to standardized QCIs. This avoids dedicated
bearer setup failures when UEs do not support extended QCIs.
4.4 Operation and Maintenance
4.4.1 Data Configuration
4.4.1.1 Data Preparation

The following table describes the parameters that must be set in the QCIPARA and
CELLALGOSWITCH MOs.
Parameter Name Parameter ID Setting Notes
PTT Dedicated Extended QciPara.LtePttDedicatedE If a new extended QCI is to

QCI xtendedQci be used by PTT voice
services, you are advised to
set this parameter to YES.
RLC PDCP Parameter QciPara.RlcPdcpParaGrou The value 0 is

Group ID pId recommended.
PTT QoS Switch CellAlgoSwitch.LtePttQoS -

Switch
The following table describes the parameters that must be set in the CELLALGOSWITCH
MO.
Uplink Schedule Extended CellAlgoSwitch.UlSchExtS -

Switch witch
DL schedule switch CellAlgoSwitch.DlSchSwit -

ch
The following table describes the parameter that must be set in the CELLALGOSWITCH
MO.

eRAN

Switch witch
The following table describes the parameters that must be set in the CELLALGOSWITCH
and CELLULSCHALGO MOs.

Switch witch
Uplink Delay-based CellUlschAlgo.UlDelaySch -

Scheduling Strategy Strategy
The following table describes the parameter that must be set in the CELLQCIPARA MO.
SINR Adjustment Target CellQciPara.SinrAdjustTar -

IBLER getIbler
MO.
RAC algorithm switch CellAlgoSwitch.RacAlgoS -

witch
The following table describes the parameters that must be set in the CELLOP MO.
Operator PTT UL RB CellOp.OpPttUlRbHighTh -

Utilization High Thd d
Operator PTT UL RB CellOp.OpPttUlRbLowThd -

Utilization Low Thd
Operator PTT DL RB CellOp.OpPttDlRbHighTh -

Utilization High Thd d
Operator PTT DL RB CellOp.OpPttDlRbLowThd -

Utilization Low Thd

eRAN
The following table describes the parameters that must be set in the QCIPARA MO.
UE Inactive Timer for QCI QciPara.UeInactiveTimer- The recommended value is

ForQci 30.
Uplink Synchronization QciPara.UlSynTimerForQc This parameter takes effect

Timer for QCI i when the
CellAlgoSwitch.DynDrxSw
itch parameter is set to
DynDrxSwitch-0 or when
UEs do not support DRX.
The following table describes the parameter that must be set in the QCIPARA MO.
UE Inactivity Timer QciPara.UeInactivityTimer -

Dynamic DRX for QCI DynDrxQci
MO.
DL Scheduling Extension CellAlgoSwitch.DlSchExtS -

Switch witch
MO.
Load balancing algorithm CellAlgoSwitch.MlbAlgoS -

switch witch
4.4.1.2 Using MML Commands
Activation Command Examples

//Creating an extended QCI for PTT voice services
ADD QCIPARA: Qci=150, ServiceType=LowDelay, LtePttDedicatedExtendedQci=YES,
RlcPdcpParaGroupId=0;
//Turning on the PTT QoS switch

MOD CELLALGOSWITCH: LocalCellId=0, LtePttQoSSwitch=ON;

eRAN
Optimization Command Examples

//Enabling semi-persistent scheduling and TTI bundling for PTT services
MOD CELLALGOSWITCH: LocalCellId=0,
UlSchExtSwitch=EnhExtQCISpsSchSwitch-1&EnhExtQCITtiBundlingSwitch-1,
DlSchSwitch=EnhExtQCISpsSchSwitch-1;
//Enabling UL compensation scheduling for PTT services

MOD CELLALGOSWITCH: LocalCellId=0, UlSchExtSwitch=UlPttSchOptSwitch-1;
//Enabling voice characteristic awareness scheduling in the uplink for PTT

services
MOD CELLALGOSWITCH: LocalCellId=0, UlSchExtSwitch=UlPttDataSizeEstSwitch-1;
MOD CELLULSCHALGO: LocalCellId=0, UlDelaySchStrategy=VOIP_DELAYSCH;
//Configuring parameters for uplink voice-specific AMC for PTT services

MOD CELLQCIPARA: LocalCellId=0, Qci=150, SinrAdjustTargetIbler=10;
//Enabling dynamic resource reservation for PTT services

MOD CELLALGOSWITCH: LocalCellId=0, RacAlgoSwitch=PttAcSwitch-1;
//Adjusting PTT service admission thresholds

MOD CELLOP: LocalCellId=0,TrackingAreaId=0, OpPttUlRbHighThd=10,
OpPttUlRbLowThd=5, OpPttDlRbHighThd=10, OpPttDlRbLowThd=5;
//(Optional, required when dynamic DRX is disabled) Adjusting the QCI-based UE

inactivity timer and uplink synchronization timer for PTT services
MOD QCIPARA: Qci=150, UeInactiveTimerForQci=30, UlSynTimerForQci=20;
//(Optional, required when dynamic DRX is enabled) Adjusting the QCI-based UE

inactivity timer in dynamic DRX mode
MOD QCIPARA: Qci=150, UeInactivityTimerDynDrxQci=200;
//Enabling TBS-based MCS selection for downlink PTT services

MOD CELLALGOSWITCH: LocalCellId=0, DlSchExtSwitch=PTT_TBS_BASED_MCS_SEL_SWITCH-1;
//Enabling PTT voice service offload

MlbAlgoSwitch=VoIPOffloadSwitch-1&PTTOffloadSwitch-1;
Deactivation Command Examples

//Turning off the PTT QoS switch
MOD CELLALGOSWITCH: LocalCellId=0, LtePttQoSSwitch=OFF;
//Removing the extended QCI for PTT voice services

RMV QCIPARA: Qci=150;
4.4.1.3 Using the CME to Perform Batch Configuration

l Fast Batch Activation
This feature can be batch activated using the Feature Operation and Maintenance
function of the CME. For detailed operations, see the following section in the CME
product documentation or online help: CME Management > CME Guidelines >
Enhanced Feature Management > Feature Operation and Maintenance.
l Single/Batch Configuration
This feature can be activated for a single eNodeB or a batch of eNodeBs on the CME.
For detailed operations, see CME-based Feature Configuration.
4.4.2 Activation Verification

Activation verification for enhanced extended QCI

eRAN
Step 1 On the menu bar of the U2020 client, choose Monitor > Signaling Trace > Signaling Trace
Management. In the navigation tree in the left pane of the Signaling Trace Management
window, choose Trace Type > LTE > Application Layer > S1 Interface Trace to create an
S1 interface trace task.
Step 2 In the displayed S1 Interface Trace dialog box, select all trace message types.
Step 3 Enable a UE to access the cell and set up a dedicated bearer (for example, with a QCI of 150)
for PTT services.
Expected result: The value of QCI contained in the message is 150 and the uplink and
downlink GBR bandwidths are not 0.
----End
Activation verification for semi-persistent scheduling for PTT services
Step 1 Observe the values of the L.Sps.UL.SchNum.Ptt and L.Sps.DL.SchNum.Ptt counters.

Expected result: The counter values are not 0.
----End
Activation verification for dynamic resource reservation
Step 1 Run the MOD CELLOP command with Operator PTT UL RB Utilization High Thd,
Operator PTT UL RB Utilization Low Thd, Operator PTT DL RB Utilization High Thd,
and Operator PTT DL RB Utilization Low Thd set to low values to facilitate observation.
Step 2 Constantly add UEs to the target cell and perform PTT services.
Step 3 Compare the uplink and downlink RB usage (the values of

L.ChMeas.PRB.UL.PttUsed.Avg.PLMN and L.ChMeas.PRB.DL.PttUsed.Avg.PLMN)
for PTT services reported from the eNodeB with the thresholds of uplink and downlink RB
usage set in Step 1 to check whether dynamic PTT resource reservation has taken effect.
Expected result: PTT services whose RB usage is lower than the thresholds are admitted and
whose PRB usage is higher than the thresholds are not admitted.
----End
Activation verification for TBS-based MCS selection for downlink PTT services
Step 1 On the U2020 client, choose Monitor > Signaling Trace > Signaling Trace Management.
Step 2 In the left pane of the displayed window, choose User Performance Monitoring > BLER
Monitoring. Set the tracing duration and MME ID.
Step 3 Check on the U2020 client whether the IBLER values converge.
----End
Observation of the CA state of PTT UEs
For details about how to observe the CA state of PTT UEs, see Carrier Aggregation.
4.4.3 Network Monitoring

You can monitor PTT service performance based on the performance counters described in
Table 4-2.

eRAN
Table 4-2 Performance counters related to PTT services

Counter ID Counter Name
1526736847 L.E-RAB.SuccEst.QCI.PTT
1526736848 L.E-RAB.AttEst.QCI.PTT
1526736849 L.E-RAB.InitAttEst.QCI.PTT
1526736850 L.E-RAB.InitSuccEst.QCI.PTT
1526736851 L.E-RAB.AttEst.HOIn.QCI.PTT
1526736852 L.E-RAB.SuccEst.HOIn.QCI.PTT
1526736853 L.E-RAB.AbnormRel.QCI.PTT
1526736854 L.PDCP.Tx.TotRev.Trf.SDU.QCI.PTT
1526736855 L.Traffic.UL.PktLoss.Loss.QCI.PTT
1526736856 L.E-
RAB.FailEst.NoRadioRes.DLSatis.PTT
1526736857 L.E-
RAB.FailEst.NoRadioRes.ULSatis.PTT
1526736858 L.E-RAB.NormRel.QCI.PTT
1526736859 L.E-RAB.NormRel.HOOut.QCI.PTT
1526736860 L.E-RAB.AbnormRel.HOOut.QCI.PTT
1526736861 L.PDCP.Tx.Disc.Trf.SDU.QCI.PTT
1526736862 L.Traffic.UL.PktLoss.Tot.QCI.PTT
1526737849 L.Traffic.DL.PktUuLoss.Loss.QCI.PTT
1526737850 L.Traffic.DL.PktUuLoss.Tot.QCI.PTT
1526740480 L.Sps.UL.SchNum.Ptt
1526740481 L.Sps.DL.SchNum.Ptt
1526740482 L.Sps.UL.ErrNum.Ptt
1526740483 L.Sps.DL.ErrNum.Ptt

eRAN
PTT Feature Parameter Description 5 PTT over eMBMS
5 PTT over eMBMS
5.1 Principles
Based on the GCSE introduced in 3GPP TS22.468 V12.0.0, this function enables PTT
services to be carried on evolved multimedia broadcast/multicast services (eMBMSs).
Multiple UEs can use one bearer to receive data, and an EPS bearer does not need to be set up
for each UE. The number of PTT UEs in a cell is only restricted by the specifications related
to the number of RRC connections, and can be greater than the number of common VoLTE
UEs in a cell.
When a large number of group UEs are gathering (for example, in firefighting, venue security
protection, and critical event assurance scenarios) or when the network is heavily loaded,
some PTT services may fail to be set up in unicast mode because the number of PTT UEs is
limited by the network capacity. Non-PTT UEs may also be affected, and user experience and
KPIs deteriorate. To resolve these issues, PTT over eMBMS is introduced to transmit PTT
services in multicast mode.
Figure 3-2 shows the networking for PTT over eMBMS. For details about eMBMS-related
technologies, see eMBMS. MB2 interfaces between the BM-SC and the PTT server are
introduced to enable eMBMS sessions to carry PTT group calls. The MB2-C interface on the
control plane is used to manage the eMBMS sessions used by PTT group calls, including pre-
establishing eMBMS session modes before PTT group calls are initiated and dynamically
adjusting eMBMS session modes and instructing UEs to switch the mode to multicast mode
after PTT groups calls are set up. The MB2-U interface on the user plane is used by the PTT
server to send downlink data of PTT group calls to the BM-SC.
Generally, eMBMS sessions are transmitted in a planned area. However, if no PTT group UEs
exist in some cells, transmitting services in these cells in multicast mode waste radio resource.
To resolve this issue, dynamic MBSFN areas (DMAs) and dynamic service areas (DSAs) are
introduced. Using these areas, the eNodeB can dynamically plan and adjust MBSFN areas and
service areas of groups based on PTT UE distribution. In this way, PTT services are broadcast
in cells where only PTT group UEs exist, increasing the overall system capacity.
The DMBSFNAREACFG.DynamicMBSFNAreaSwitch parameter of the eCoordinator
controls DMAs and DSAs, including creating, updating, and releasing them. Table 5-1
describes the terms related to this function.

eRAN
Table 5-1 Term description

Term Definition
DMA Indicates a dynamic MBSFN area, which is dynamically planned by the

MCE based on UE distribution.
DSA Indicates a dynamic service area, which is dynamically planned by the

MCE based on UE distribution.
SMA Indicates a static MBSFN area. An SMA can be planned only after
MBSFNCOMCFG.DMASwitch is set to OFF on the MCE.
VMA Indicates a virtual MBSFN area. A VMA can be planned only after
MBSFNCOMCFG.DMASwitch is set to ON on the MCE.
Only one DMA can be created in a VMA, and the DMA uses the ID of
the VMA. The DMA uses the same MA parameter configurations as
the VMA.
DMA center cell Indicates a cell in which the number of UEs in the same group exceeds
the MBMSCRTL.DynamicMbsfnAreaThdHigh parameter value. UEs
in such a cell perform services in multicast mode.
DMA edge cell Indicates certain neighboring cells of a DMA center cell. Group UEs in
these neighboring cells can receive data transmitted in unicast and
multicast modes.
DMA candidate Indicates a cell in which the number of UEs in the same group does not
cell exceed the MBMSCRTL.DynamicMbsfnAreaThdHigh parameter
value.
NOTE
The DMA and DSA are different names of the same concept for the eCoordinator. For detailed causes,
see the descriptions of MAs and SAs in eMBMS.
Before deploying this function, collect the following information about PTT groups for
setting the higher and lower thresholds of dynamically planning MBMS areas.
l Maximum number of UEs in a group
l Maximum number of UEs per cell
l Maximum number of UEs in a group per cell
l Average number of UEs per cell
l Average number of UEs in a group per cell
5.1.1 Process of Creating a DMA/DSA

Figure 5-1 shows the process of creating a DMA/DSA.

eRAN
Figure 5-1 Process of creating a DMA/DSA
1. The GCS AS determines to create a DMA/DSA and sends a CREATE DSA REQUEST
message to the eCoordinator.
As shown in Figure 5-2, two VMAs, VMA1 (MAID = 129) and VMA2 (MAID = 130),
are planned on the network, and PTT group UEs exist in cells 1, 3, 5, 9, and 10. The
numbers of UEs in cells 1 and 3 exceed the preset
MBMSCRTL.DynamicMbsfnAreaThdHigh parameter value. The GCS AS determines
that cells 1 and 3 are DMA center cells. The numbers of UEs in cells 5, 9, and 10 do not
exceed the parameter value, and the GCS AS determines that these cells are DMA
candidate cells. The GCS AS sends a CREATE DSA REQUEST message containing
center cells 1 and 3 and candidate cells 5, 9, and 10 to the eCoordinator.

eRAN
Figure 5-2 Example of creating a DMA/DSA
2. The eCoordinator allows DMA creation and initiates a neighboring cell list (NCL) query
to the related eNodeBs.
In the example, the eCoordinator applies for a DSA ID for the DMA to be created for the
GCS AS, and determines whether DMA center cells 1 and 3 can be added to the DMA.
Cell 1 is not within any VMA and cannot be added to the DMA. Cell 3 can be added to
the DMA because it meets the following conditions: Cell 3 is within VMA1, the number
of MAs to which it belongs is less than 3 (maximum number), and the remaining
licensed number of cells in the DMA is not 0. In this situation, the eCoordinator sends an
NCL QUERY REQUEST message to the eNodeB serving cell 3 for querying the NCL of
cell 3.
NOTE
l If none of the center cells can be added to the DMA, the eCoordinator directly returns a
CREATE DSA RESPONSE message indicating the DMA/DSA creation failure to the GCS
AS. The process ends.
l The DSA ID preferentially starts from 50000, specified by the
DMBSFNAREACFG.DSAStartIndex parameter. New DSA IDs must not be the same as a
static SA ID and the existing DSA IDs.
3. The eNodeB returns the NCL and number of successful handovers of each cell to the
eCoordinator.
The eNodeB ranks the intra-frequency neighboring cells 9, 10, 17, 18, and 19 of center
cell 3 based on the numbers of successful handovers with cell 3 in descending order, and
sends an NCL QUERY RESPONSE message containing information about a maximum
of 20 intra-frequency neighboring cells to the eCoordinator.
4. The eCoordinator filters edge cells, adds them to the created DMA/DSA, and sends a
DSA configuration request to the related eNodeBs.
In the example, the eCoordinator first adds neighboring cells 9 and 10 serving as
candidate cells as the edge cells of center cell 3. If the number of candidate cells does not
exceed the preset DMBSFNAREACFG.NeighborCellNum parameter value (4 is used
as an example), the eCoordinator selects top N neighboring cells with the largest
numbers of handovers to center cell 3. N is the difference between the
DMBSFNAREACFG.NeighborCellNum parameter value and the number of cells that
have been added as edge cells, and N is set to 2 in this example. The eCoordinator then
adds neighboring cells 17 and 18 as the edge cells of center cell 3. The eCoordinator
adds center cell 3 and its edge cells 9, 10, 17, and 18 to DMA1_129, and sends a CFG
DSA REQUEST message containing the obtained DSA ID to the eNodeBs serving all
cells in DMA1_129.

eRAN
NOTE
l All center cells and neighboring cells must be within the planned VMAs and can belong to
different VMAs.
l If the cells belong to different VMAs, different DMAs need to be planned. Otherwise, only
one DMA needs to be planned.
l Configurations of the created DMAs and VMAs are similar, including MA IDs, common
MBSFN parameter configurations, and MCCH parameter configurations.
5. The eNodeB adds the DSA ID configuration to the cells in the DMA and returns a CFG
DSA RESPONSE message to the eCoordinator.
NOTE
The DSAs added to the eNodeB can be queried by running the DSP DYNAMICSERVICEAREA
command, but cannot be modified or added using commands.
6. The eCoordinator summarizes all cell configuration responses and sends a CREATE
DSA RESPONSE message to the GCS AS.
The eCoordinator sends the GCS AS a CREATE DSA RESPONSE message, which, in
this example, contains center cell 3 and edge cells 9, 10, 17, and 18, and the cause value
for DMA creation failure of cell 1.
7. The eNodeB sends an ENB CONFIGURATION UPDATE message to the MCE over the
M2 interface, notifying it of the DSA configuration change.
8. The GCS AS sets up a multicast bearer and notifies UEs of the bearers over the GC1
interface.
5.1.2 Process of Updating a DMA/DSA

The process of updating a DMA/DSA is similar to the creation process. The difference is that
DSA ID allocation is not required in the update process. Figure 5-3 shows the process of
updating a DMA/DSA.

eRAN
Figure 5-3 Process of updating a DMA/DSA
1. The GCS AS determines to add cells to a DSA or delete cells from a DSA, and triggers
the DMA/DSA update process.
As shown in Figure 5-4, the number of PTT group UEs in cell 2 exceeds the preset
threshold, and the DMA/DSA update is triggered. The GCS AS adds cells 2 and 3 as the
DMA center cells for the PTT group, and sends an UPDATE DSA REQUEST message
containing the DSA ID, center cells 2 and 3, and candidate cells 5, 6, 7, 9, and 10 to the
eCoordinator.

eRAN
Figure 5-4 Example of updating a DMA/DSA
2. The eCoordinator determines whether the updated center cells can be added to the DMA,
and sends an NCL QUERY REQUEST message to the related eNodeB (the eNodeB
serving cell 2 in this example) for querying the NCL.
NOTE
If none of the center cells is within the VMA, the eCoordinator directly returns an UPDATE DSA
RESPONSE message indicating the DMA/DSA update failure and containing the failure cause
value to the GCS AS. The process ends.
3. The eNodeB returns the NCL and number of successful handovers of each cell to the
eCoordinator.
In this example, the eNodeB returns the NCL QUERY RESPONSE message containing
neighboring cells 6, 7, 8, 14, and 16 of center cell 2.
4. The eCoordinator filters edge cells, adds them to the created DMA/DSA, and sends a
DSA configuration request to the related eNodeBs.
In the example, the eCoordinator first adds neighboring cells 6 and 7 of the candidate
cell as the edge cells of center cell 2. Then, the eCoordinator selects the top N
neighboring cells with the largest numbers of handovers to the center cell from the
remaining neighboring cells. N is the difference between the
DMBSFNAREACFG.NeighborCellNum parameter value and the number of cells that
have been added as edge cells, and N is set to 2 in this example. That is, the eCoordinator
adds neighboring cells 17 and 18 as the edge cells of center cell 2. The eCoordinator
adds center cell 2 and edge cells 6, 7, 14, and 16 to DMA1_129 and sends a CFG DSA
REQUEST message containing the obtained DSA ID to the eNodeBs serving all the new
cells in DMA1_129.
NOTE
If new center cells and the existing DMA do not belong to the same VMA, new DMAs need to be
planned for the new cells.

eRAN
5. Each new cell completes the DSA ID configuration, and then the eNodeBs serving the
new cells send a CFG DSA RESPONSE message to the eCoordinator.
6. The eCoordinator summarizes all cell configuration responses and sends an UPDATE
DSA RESPONSE message to the GCS AS.
8. The GCS AS updates the multicast bearer.
5.1.3 Process of Releasing a DMA/DSA

Figure 5-5 shows the process of releasing a DMA/DSA.
Figure 5-5 Process of releasing a DMA/DSA
1. The GCS AS determines the DSA to be deleted and triggers the DMA/DSA release
process.
As shown in Figure 5-6, the GCS AS determines that the numbers of PTT group UEs in
cells 2 and 3 are less than the preset DMBSFNAREACFG.NeighborCellNum
parameter value and the DMA/DSA needs to be released. The GCS AS sends a DELETE
DSA REQUEST message containing the DSA ID to the eCoordinator.

eRAN
Figure 5-6 Example of releasing a DMA/DSA
2. The eCoordinator deletes the DMA/DSA and sends a CFG DSA REQUEST message to
the eNodeB.
In this example, the eCoordinator deletes center cells 2 and 3 and their respective edge
cells 6, 7, 14, 16 and 9, 10, 17, and 18 from DMA1_129. DMA1_129 is released because
it has no cells. The eCoordinator deletes center cells 2 and 3 and their respective edge
cells 6, 7, 14, 16 and 9, 10, 17, and 18 based on the DSA ID, and sends a CFG DSA
REQUEST message to the related eNodeBs to delete the DSA ID of these cells.
3. The eNodeB deletes the DSA configuration and sends the configuration result to the
eCoordinator.
In this example, the eNodeB deletes the DSA ID configuration of center cells 2 and 3
and their respective edge cells 6, 7, 14, 16 and 9, 10, 17, and 18, and sends a CFG DSA
RESPONSE message to the eCoordinator.
4. The eCoordinator summarizes all cell configuration results and sends a DELETE DSA
RESPONSE message to the GCS AS. If all configurations fail, the DELETE DSA
RESPONSE message indicates the DSA ID release failure. If any configuration
succeeds, the message indicates the DSA ID release success.
6. The GCS AS releases the multicast bearer for PTT groups and notifies UEs of the result
over the GC1 interface.

eRAN
5.2.1 Benefits
This function is suitable for areas where eMBMS has been activated or where resource usage
of PTT services in unicast mode needs to be reduced. This enables PTT services to be carried
on eMBMSs and increases the capacity of PTT services.
5.2.2 Impacts
Network Impacts
None
Function Impacts
Name Switch
h
parameter
TDD None N/A N/A N/A
5.3 Requirements
5.3.1 Licenses
There are currently no license requirements for trial functions.
5.3.2 Software
Name Switch
FDD eMBMS CellMBM eMBMS The implementation of this

TDD SCfg.MB function depends on MBMSs.
MSSwitch

eRAN

None
5.3.3 Hardware
Base Station Models
No requirements
Boards
None
RF Modules
None
5.3.4 Networking
Before deploying the function, plan VMAs properly:
l Multiple VMAs do not overlap.
l VMA parameters are properly configured to prevent coverage holes within the VMAs.
In addition, configure the Se interface between the eCoordinator and eNodeB and ensure that
the Se link is working properly.
NOTE
For details about the Se interface, see IPv4 Transmission. For details about how to configure the Se
interface, see Interface Self-planning.
5.3.5 Others
This function also has the following requirements:
l This function requires that the eNodeB, eCoordinator, and GCS AS be deployed and that
applications supporting PTT services be installed on UEs. The eNodeB and eCoordinator
must be provided by Huawei, and the eNodeB must use UMPT or LMPT and LBBPc,
LBBPd, or UBBP boards.
l When a third-party GCS AS and UEs are used, they must interconnect with Huawei
eNodeB and eCoordinator over the open interface provided by Huawei.
l This function has the following requirements on the operating environment:
– The eMBMS feature has been deployed and common eMBMSs can be performed.
– Huawei eNodeB and eCoordinator (ECO6910) are used. A third-party eNodeB or
MCE is not supported.
– If a third-party GCS AS is used, the GCS AS must interconnect with the
eCoordinator (ECO6910) over the open interface provided by Huawei.

eRAN

l eNodeB Data Preparation
Transmission links need to be configured between the eNodeB and the eCoordinator, and the
related MOs include SCTPTEMPLATE, SCTPHOST, SCTPPEER, USERPLANEHOST,
USERPLANEPEER, EPGROUP, and EP2RSCGRP. For details, see S1 and X2 Self-
Management.
The following table describes the parameters that must be set in the ECO MO.
Table 5-2 Parameters used for activation

ECO ID ECO.EcoId N/A
End Point Group Config ECO.EpGroupCfgFlag The default value is

Flag recommended.
Control Plane End Point ECO.CpEpGroupId N/A

Group ID
User Plane End Point Group ECO.UpEpGroupId N/A

ID
l eCoordinator (ECO6910) Data Preparation

The following table describes the parameters that must be set in the SCTPLNK MO.
SCTP Link ID SCTPLNK.SCTPLNKID This parameter uniquely

identifies an SCTP link on
the eCoordinator.
Application Type SCTPLNK.APP This parameter specifies the

upper-layer application type
of an SCTP link.
Set this parameter to SEAP.
Signalling link mode SCTPLNK.MODE This parameter specifies the

working mode of an SCTP
link.
Set this parameter to
SERVER.

eRAN
Differentiated Service SCTPLNK.DSCP This parameter labels each

Codepoint data packet on the network
and allocates the
corresponding service
levels.
Local SCTP port No. SCTPLNK.LOCPN This parameter specifies the

local port number of an
SCTP link.
First local IP address SCTPLNK.LOCIP1 This parameter specifies the

first local IP address that
communicates with the peer
end.
Second local IP address SCTPLNK.LOCIP2 This parameter specifies the

second local IP address that
communicates with the peer
end.
The following table describes the parameters that must be set in the IPRT MO.
Subrack No. IPRT.SRN This parameter specifies the

subrack number of a board.
Slot No. IPRT.SN This parameter specifies the

slot number of a board.
Destination IP address IPRT.DSTIP This parameter specifies a

destination IP address.
Destination address mask IPRT.DSTMASK This parameter specifies a

subnet mask.
Next hop type IPRT.NEXTHOPTYPE This parameter specifies the

type of the next hop on an
IP route.
Set this parameter to
Gateway.
Forward route address IPRT.NEXTHOP This parameter specifies the

next-hop IP address.
Priority IPRT.PRIORITY This parameter specifies the

route priority.
The following table describes the parameters that must be set in the ENODEB MO.

eRAN
eNodeB Index ENODEB.eNodeBIndex This parameter uniquely

identifies an eNodeB on the
eCoordinator.
eNodeB Name ENODEB.eNodeBName This parameter specifies the

name of an eNodeB.
Mobile Country Code ENODEB.MCC This parameter specifies the

mobile country code (MCC)
that identifies the country to
which a UE belongs.
Mobile Network Code ENODEB.MNC This parameter specifies the

mobile network code
(MNC) that identifies the
public land mobile network
(PLMN) to which a mobile
user belongs.
eNodeB ID ENODEB.eNodeBId This parameter uniquely

identifies an eNodeB on the
eCoordinator.
The following table describes the parameters that must be set in the EENODEBCONN MO.
NE Index Type EENODEBCONN.QueryN This parameter specifies the

eIdType type of an NE index.
eNodeB Index EENODEBCONN.eNodeB This parameter uniquely

Index identifies an eNodeB on the
eCoordinator.
eNodeB Name EENODEBCONN.eNodeB This parameter specifies the

Name name of an eNodeB.
Application Type EENODEBCONN.APP This parameter specifies the

upper-layer application type
of bottom-layer links.
Set this parameter to SEAP.
SCTP Link ID EENODEBCONN.SCTPL This parameter uniquely

NKID specifies an SCTP link.
The following table describes the parameters that must be set in the MGSINTERFACE MO.

eRAN
MGs Interface ID MGSINTERFACE.MgsInt This parameter specifies the

erfaceId ID of an MGs interface.
MGs Interface Name MGSINTERFACE.MgsInt This parameter specifies the

erfaceName MGs interface name.
SCTP Link ID MGSINTERFACE.SCTPL This parameter specifies the

NKID ID of an SCTP link.
Security Switch MGSINTERFACE.SECU This parameter specifies

RITYSWITCH whether to use security
policies for the MGs
interface.
l When this parameter is
set to ON,
MGSINTERFACE.PK
EY needs to be
configured for the MGs
interface.
l When this parameter is
set to OFF,
MGSINTERFACE.PK
EY does not need to be
interface.
Pre-shared Key MGSINTERFACE.PKEY This parameter specifies the

preshared key. Both ends
must use the same preshared
key in negotiation.
The following table describes the parameters that must be set in the MBSFNCOMCFG MO.
MBSFN Area ID MBSFNCOMCFG.Mbsfn This parameter specifies the

AreaId ID of an MBSFN area.
DMA Switch MBSFNCOMCFG.DMAS This parameter specifies

witch whether a DMA can be
created in the current MA.
Set this parameter to ON.
The following table describes the parameters that must be set in the DMBSFNAREACFG
MO.

eRAN
Dynamic MBSFN Area DMBSFNAREACFG.Dyn This parameter specifies

Switch amicMBSFNAreaSwitch whether to enable DMA
planning.
Neighbor Cell Num DMBSFNAREACFG.Neig This parameter specifies the

hborCellNum number of neighboring cells
of a center cell. When a
DMA is generated, the
number of edge cells added
for each center cell is less
than the value of this
parameter.
Set this parameter to 5.
DSA Start Index DMBSFNAREACFG.DSA This parameter specifies the

StartIndex start ID of a DSA.
l GCS AS Data Preparation

The following table describes the parameters that must be set in the MGSINTERFACE MO.
MGs Interface ID MGSINTERFACE.MGsInt This parameter specifies the

erfaceId ID of an MGs interface.
MGs Interface Name MGSINTERFACE.MGsInt This parameter specifies the

erfaceName MGs interface name.
SCTP Link ID MGSINTERFACE.SCTPL This parameter specifies the

NKID ID of an SCTP link.
Security Switch MGSINTERFACE.SECU This parameter specifies

RITYSWITCH whether to use security
policies for the MGs
interface.
When this parameter is set
to ON,
MGSINTERFACE.PKEY
needs to be configured for
the MGs interface.
When this parameter is set
to OFF,
MGSINTERFACE.PKEY
does not need to be
interface.

eRAN
Pre-shared Key MGSINTERFACE.PKEY This parameter specifies the

preshared key. Both ends
must use the same preshared
key in negotiation.
The following table describes the parameters that must be set in the MBMSCRTL MO.
DMA Switch MBMSCRTL.DMASwitch This parameter specifies

whether to enable DMA
planning.
Dynamic Mbsfn Area Thd MBMSCRTL.DynamicMb This parameter specifies the

High sfnAreaThdHigh threshold of changing a cell
to a center cell of a DMA.
When the number of UEs in
a PTT group of a cell is
greater than or equal to the
value of this parameter, the
GCS AS adds the cell to the
list of center cells of the
DMA.
The value of this parameter
is greater than that of
MBMSCRTL.DynamicMb
sfnAreaThdLow.
Dynamic Mbsfn Area Thd MBMSCRTL.DynamicMb This parameter specifies the

Low sfnAreaThdLow threshold of changing a
center cell in the DMA to a
non-center cell. When the
number of UEs in a PTT
group of a cell is less the
value of this parameter, the
GCS AS adds the cell to the
list of non-center cells of the
DMA.
The value of this parameter
is less than that of
MBMSCRTL.DynamicMb
sfnAreaThdHigh.

eRAN

l Configurations on the eNodeB
//Adding an SCTP template
ADD SCTPTEMPLATE: SCTPTEMPLATEID=0, SWITCHBACKFLAG=ENABLE;
//Adding an SCTP host on the eNodeB

ADD SCTPHOST: SCTPHOSTID=0, IPVERSION=IPv4, SIGIP1V4="5.5.3.37",
SIGIP1SECSWITCH=DISABLE, SIGIP2SECSWITCH=DISABLE, PN=36412, SCTPTEMPLATEID=0;
//Adding an SCTP peer on the eNodeB

ADD SCTPPEER: SCTPPEERID=0, IPVERSION=IPv4, SIGIP1V4="138.32.1.20",
SIGIP1SECSWITCH=DISABLE, SIGIP2SECSWITCH=DISABLE, PN=36412;
//Adding a user-plane host on the Se interface

ADD USERPLANEHOST: UPHOSTID=0, IPVERSION=IPv4, LOCIPV4="5.5.3.37",
IPSECSWITCH=DISABLE;
//Adding a user-plane peer on the Se interface

ADD USERPLANEPEER: UPPEERID=0, IPVERSION=IPv4, PEERIPV4="195.168.1.28",
IPSECSWITCH=DISABLE;
//Adding an end point group

ADD EPGROUP: EPGROUPID=0;
//Adding the SCTP host to the end point group

ADD SCTPHOST2EPGRP: EPGROUPID=0, SCTPHOSTID=0;
//Adding the SCTP peer to the end point group

ADD SCTPPEER2EPGRP: EPGROUPID=0, SCTPPEERID=0;
//Adding the user-plane host of the Se interface to the end point group
ADD UPHOST2EPGRP: EPGROUPID=0, UPHOSTID=0;
//Adding the user-plane peer of the Se interface to the end point group
ADD UPPEER2EPGRP: EPGROUPID=0, UPPEERID=0;
//Adding the eCoordinator

ADD ECO: EcoId=0, EpGroupCfgFlag=CP_UP_CFG, CpEpGroupId=457, UpEpGroupId=457;
l Configurations on the eCoordinator

//Adding an SCTP link
ADD SCTPLNK: SCTPLNKID=1, APP=SEAP, MODE=SERVER, SpecifyLOCPNFlag=NO, LOCPN
=5000, LOCIP1="11.11.11.11", PEERIP1="11.11.11.111", PEERPN=10000,
SWITCHBACKFLAG=YES;
//(Optional) Adding an IP route

ADD IPRT: SRN=3, SN=20, DSTIP="35.35.35.35", DSTMASK="255.255.255.255",
NEXTHOPTYPE=Gateway, NEXTHOP="26.26.26.28", PRIORITY=HIGH, REMARK="route1";
//Adding an eNodeB
ADD ENODEB: eNodeBName="eNodeB88", MCC="460", MNC="04", eNodeBId=88;
//Adding a connection between the eCoordinator and the eNodeB

ADD EENODEBCONN: QueryNeIdType=BYID, eNodeBIndex=1, APP=SEAP, SCTPLNKID=10;
//Adding an SCTP link

ADD SCTPLNK: SCTPLNKID=2, APP=SEAP, MODE=SERVER, SpecifyLOCPNFlag=NO, LOCPN
=5000, LOCIP1="11.11.11.11", PEERIP1="11.11.11.222", PEERPN=20000,
SWITCHBACKFLAG=YES;
//(Optional) Adding an IP route

ADD IPRT: SRN=3, SN=20, DSTIP="35.35.35.35", DSTMASK="255.255.255.255",
NEXTHOPTYPE=Gateway, NEXTHOP="26.26.26.28", PRIORITY=HIGH, REMARK="route1";

eRAN
//Adding an MGs interface

ADD MGSINTERFACE: MgsInterfaceId=0, MgsInterfaceName="mgs", SCTPLNKID=1,
SECURITYSWITCH=ON, PKEY="*****";
//Turning on the DMA switch

ADD MBSFNCOMCFG: MbsfnAreaId=56, DmaSwitch=ON;
//Turning on the dynamic MBMS area switch

SET DMBSFNAREACFG: DynamicMBSFNAreaSwitch=ON, NeighborCellNum=5, DSAStartIndex=0;

N/A

//Turning off the dynamic MBMS area switch
SET DMBSFNAREACFG: DynamicMBSFNAreaSwitch=OFF, NeighborCellNum=5, DSAStartIndex=0;
5.4.1.3 Using the CME

5.4.2 Activation Observation

The purpose of activating this feature is to generate DMAs. Check whether this feature has
taken effect by observing whether DMAs are generated. Observe whether DMAs are
generated on the eNodeB or eCoordinator:
l Observing the configuration results on the eNodeB
Step 1 Run the DSP DYNAMICSERVICEAREA command to query the DSA information about
cells.
Expected result: DSA information is available in the cell and the feature is activated
successfully.
----End
l Observing the configuration results on the eCoordinator
Step 1 Run the DSP DSAINFO command to check whether new DMAs exist.
Expected result: New DMAs exist, and the feature is activated successfully.
----End

None

eRAN
PTT Feature Parameter Description 6 MCPTT QoS Management
6 MCPTT QoS Management
6.1 Principles
MCPTT QoS management enables MCPTT services to be carried on bearers with QCIs 65,
66, 69, and 70, and optimizes the scheduling priorities of these QCIs to raise the scheduling
priorities of MCPTT services. This ensures MCPTT UE's service experience even when cells
are heavily congested.
The McpttQosSwitch option of the CellAlgoSwitch.McpttSwitch parameter determines
whether to enable MCPTT QoS management to raise the QoS priorities of MCPTT services.
For details about the scheduling priority for each standardized QCI, see section 6.1.7
"Standardized QoS characteristics" in 3GPP TS 23.203 V13.3.0. Before enabling this
function, perform the following operations:
1. Check that UEs on the live network and the EPC support standardized QCIs 65, 66, 69,
and 70.
2. Check that PTT services carried on bearers of the default QCIs are running properly on
the live network, and check the uplink and downlink bandwidths of PTT services and
port numbers in use.
6.2.1 Benefits
This function is suitable for scenarios where operators can use standardized QCIs 65, 66, 69,
and 70 and expect to provide higher QoS priorities for MCPTT voice services carried on
bearers with these QCIs.
MCPTT QoS management enables MCPTT services to be carried on bearers with QCIs 65,
66, 69, and 70, and optimizes the scheduling priorities of these QCIs to raise the scheduling
priorities of MCPTT services. This ensures MCPTT UE's service experience even when cells
are heavily congested.

eRAN
6.2.2 Impacts
Network Impacts
None
Function Impacts
Name Switch
FDD eMTC EMTC_SWIT eMTC eMTC UEs do

TDD introduction CH option of not support
the MCPTT QoS
CellEmtcAlgo. management.
EmtcAlgoSwitc
h parameter
FDD Short TTI SHORT_TTI_ Short TTI The eNodeB

SW option of (FDD) does not
the schedule a UE
CellShortTtiAl in short TTI
go.SttiAlgoSwit mode if a PTT
ch parameter bearer has been
set up for this
UE. If a PTT
bearer is set up
during short
TTI scheduling,
the eNodeB
immediately
stops short TTI
scheduling for
this UE.
6.3 Requirements
6.3.1 Licenses
RAT Feature ID Feature Name Model Sales Unit
FDD LTROFD-1112 MCPTT QoS LT1SMCPTTQ Per cell

01 Management SM
TDD TDLOFD-1211 MCPTT QoS LT4SMCPQSE Per cell

03 Management 00

eRAN
NOTE
MCPTT services carried on bearers with standardized QCIs 65, 66, 69, and 70 are also under license
control on the MME and S-GW. For details, see the related EPC documentation.
6.3.2 Software
None

None
6.3.3 Hardware
Base Station Models

No requirements
Boards
None
RF Modules
None
Cells
MCPTT services have bandwidth requirements. Therefore, the uplink and downlink rates of
CEUs must meet the minimum requirements for MCPTT services to guarantee user
experience. Table 6-1 lists the requirements on the uplink and downlink rates for CEUs.
Table 6-1 Requirements on the uplink and downlink rates for CEUs
Scenario Better User Experience Basic User Experience
Uplink rate ≥ 55 kbit/s ≥ 40 kbit/s
Downlink rate ≥ 55 kbit/s ≥ 40 kbit/s
NOTE
The rates vary based on PTT devices because the codec formats and transmission models are different
between vendors. The rates in Table 6-1 are for Huawei PTT devices. For details about the rates
supported by devices from other vendors, contact related PTT vendors.
6.3.4 Networking
None

eRAN
6.3.5 Others
One of the following requirements must be met:
l UEs must support standardized QCIs 65, 66, 69, and 70, and comply with 3GPP Release
12.
l The core network must support standardized QCIs 65, 66, 69, and 70, and comply with
3GPP Release 12.

Parameters of standardized and extended QCIs are configured in the QciPara, CellQciPara,
and CnOperatorQciPara MOs.
The following table describes the parameter that must be set in the CellAlgoSwitch MO.
MCPTT Switch CellAlgoSwitch.McpttSwitc N/A

h

//Turn on the MCPTT QoS management switch
MOD CELLALGOSWITCH: LocalCellId=0, McpttSwitch=McpttQoSSwitch-1;

N/A

//Turning off the MCPTT QoS management switch
MOD CELLALGOSWITCH: LocalCellId=0, McpttSwitch=McpttQoSSwitch-0;
6.4.1.3 Using the CME to Perform Batch Configuration


eRAN

Management. In the navigation tree in the left pane of the Signaling Trace Management
window, choose Trace Type > LTE > Application Layer > S1 Interface Trace to create an
S1 interface trace task.
Step 2 In the displayed S1 Interface Trace dialog box, select all trace message types.
Step 3 Enable the UE to access the cell and set up the default bearer with QCI 69 for PTT services
and a bearer of QCI 65 dedicated to voice services.
Expected result: The S1AP_INITIAL_CONTEXT_SETUP_REQ message contains a default

bearer with QCI 69 or the S1AP_ERAB_SETUP_REQ message contains a dedicated bearer
with QCI 69. Then, the S1AP_ERAB_SETUP_REQ message contains a dedicated bearer
with QCI 65 and the uplink and downlink GBR bandwidths are not 0.
----End

You can monitor PTT service performance based on the performance counters described in
Table 6-2.
Table 6-2 Performance counters related to MCPTT services

1526741973 L.E-RAB.AttEst.QCI.65
1526741974 L.E-RAB.SuccEst.QCI.65
1526741981 L.E-RAB.InitAttEst.QCI.65
1526741982 L.E-RAB.InitSuccEst.QCI.65

eRAN
1526742018 L.E-RAB.AttEst.HOIn.QCI.65
1526742022 L.E-RAB.SuccEst.HOIn.QCI.65
1526742001 L.E-RAB.Est.TimeAvg.QCI.65
1526742005 L.E-RAB.Est.TimeMax.QCI.65
1526741989 L.E-RAB.AbnormRel.QCI.65
1526741993 L.E-RAB.NormRel.QCI.65
1526742026 L.E-RAB.NormRel.HOOut.QCI.65

eRAN
1526742030 L.E-RAB.AbnormRel.HOOut.QCI.65
1526748742 L.E-RAB.FailEst.MME.QCI65
1526748743 L.E-RAB.FailEst.TNL.QCI65
1526748744 L.E-RAB.FailEst.RNL.QCI65
1526748745 L.E-RAB.FailEst.NoRadioRes.QCI65
1526748746 L.E-
RAB.FailEst.NoRadioRes.UserSpec.QCI
65
1526748747 L.E-RAB.FailEst.SRBReset.QCI65
1526748748 L.E-RAB.FailEst.NoReply.QCI65
1526748750 L.E-RAB.FailEst.Conflict.Hofail.QCI65
1526748749 L.E-RAB.FailEst.X2AP.QCI65
1526748751 L.E-RAB.AbnormRel.MME.QCI65
1526748752 L.E-RAB.AbnormRel.TNL.QCI65
1526748753 L.E-RAB.AbnormRel.Radio.QCI65
1526748754 L.E-
RAB.AbnormRel.Radio.SRBReset.QCI6
5
1526748755 L.E-
RAB.AbnormRel.Radio.ULSyncFail.QCI
65
1526748756 L.E-
RAB.AbnormRel.Radio.UuNoReply.QCI
65
1526748757 L.E-RAB.AbnormRel.HOFailure.QCI65
1526748758 L.E-RAB.AbnormRel.Cong.QCI65
1526748766 L.E-RAB.FailEst.MME.QCI69
1526748767 L.E-RAB.FailEst.TNL.QCI69
1526748768 L.E-RAB.FailEst.RNL.QCI69
1526748769 L.E-RAB.FailEst.NoRadioRes.QCI69

eRAN
1526748772 L.E-RAB.FailEst.NoReply.QCI69
1526748771 L.E-RAB.FailEst.SRBReset.QCI69
1526748770 L.E-
69
1526748775 L.E-
RAB.FailEst.NoRadioRes.RrcUserLic.Q
CI69
1526748774 L.E-RAB.FailEst.Conflict.Hofail.QCI69
1526748773 L.E-RAB.FailEst.X2AP.QCI69
1526748776 L.E-RAB.AbnormRel.MME.QCI69
1526748778 L.E-RAB.AbnormRel.Radio.QCI69
1526748779 L.E-
RAB.AbnormRel.Radio.SRBReset.QCI6
9
1526748784 L.E-
RAB.AbnormRel.Radio.DRBReset.QCI6
9
1526748780 L.E-
RAB.AbnormRel.Radio.ULSyncFail.QCI
69
1526748781 L.E-
RAB.AbnormRel.Radio.UuNoReply.QCI
69
1526748782 L.E-RAB.AbnormRel.HOFailure.QCI69

eRAN
PTT Feature Parameter Description 7 Congestion Control for Public Safety
7 Congestion Control for Public Safety
7.1 Principles
Congestion control for public safety monitors the QoS satisfaction rate of MCPTT guaranteed
bit rate (GBR) services, dynamically adjusts radio resources, and triggers MCPTT services to
preempt resources of other services, ensuring the QoS satisfaction rate of MCPTT services
when the system is congested.
The McpttCongCtrlSwitch option of the CellAlgoSwitch.McpttSwitch parameter

determines whether to enable congestion control for public safety. The functions described in
3.3.4 Admission and Congestion Control are used to perform admission and congestion
control for MCPTT services. MCPTT services apply to emergencies related to public safety.
Therefore, the QciPara.FlowCtrlType parameter applies only to services carried on QCIs
other than QCIs 65 and 66. Flow control is not performed for MCPTT services carried on
QCIs 65 and 66 by default and this parameter is not configurable for such services to ensure
service reliability.
Selection Policy of Separate MLB

For MCPTT services, the eNodeB supports the selection policy of separate mobility load
balancing (MLB). The CellQciPara.QciAlgoSwitch parameter is used to enable the inter-
frequency or inter-RAT load balancing for MCPTT services carried on bearers with QCI 65,
66, 69, or 70. For details, see Intra-RAT Mobility Load Balancing and Inter-RAT Mobility
Load Balancing.
Resource Preemption of High-ARP MCPTT Services

To ensure voice quality and admission of MCPTT services in congestion scenarios, high-ARP
MCPTT services can preempt the resources of other low-ARP services.
l When there are IMS-based emergency call services on the network and the
EmcAdmitCongSwitch option of the CellAlgoSwitch.RacAlgoSwitch parameter is
selected, resources for emergency call services can also be preempted.
l When this option is deselected, their resources cannot be preempted even though their
ARPs are lower than those of MCPTT services.

eRAN
NOTE
In scenarios where SRS and PUCCH resources are insufficient, high-ARP MCPTT services cannot
preempt resources of other services when the EmcAdmitCongSwitch option is deselected. When this
option is selected, MCPTT services can preempt resources of other services (including emergency call
services).
E-RAB Setup Success Rate Assurance for MCPTT Services

In congestion scenarios, the number of bearers that can be preempted is increased and the
satisfaction rate is configured specifically for incoming handed-over services to ensure the E-
RAB setup success rate of MCPTT services.
The increased number of bearers that can be preempted and the satisfaction rate dedicated to
services handed over to a cell are specified by the CellRacThd.PreemptableBearerNum and
CellQciPara.HandoverAdmissionThreshold parameters, respectively.
l The CellRacThd.PreemptableBearerNum parameter indicates the number of low-

priority services that can be preempted per second in the uplink or downlink and released
in congestion scenarios. When both MCPTT QoS management and congestion control
for public safety are enabled, this parameter takes effect. When this parameter takes
effect:
– When the parameter takes effect and a cell has only one operator, the number of
low-priority services that can be preempted per second in the uplink or downlink
and released in congestion scenarios in the cell is indicated by the
CellRacThd.PreemptableBearerNum parameter.
– When the parameter takes effect and a cell has multiple operators,
When the CellAlgoSwitch.RanShareModeSwitch parameter is set to ON, the
number of bearers that can be preempted per second in the uplink or downlink and
released in congestion scenarios for all operators in the cell is configured by the
CellRacThd.PreemptableBearerNum parameter.
Number of preempted bearers of each operator =
CellRacThd.PreemptableBearerNum/Number of operators (rounding down).
When the calculation result is less than 10, the number of preempted bearers of each
operator is 10.
When the CellAlgoSwitch.RanShareModeSwitch parameter is set to OFF, each
operator has the chance to use 100% of cell resources. The number of preemptable
bearers is indicated by the CellRacThd.PreemptableBearerNum parameter.
l The CellQciPara.HandoverAdmissionThreshold parameter set for QCI 65 indicates the
threshold for admitting handed-over MCPTT services with QCI 65 based on the QoS
satisfaction rate. When both MCPTT QoS management and congestion control for public
safety are enabled, this parameter takes effect. When the parameter takes effect, handed-
over MCPTT services with QCI 65 can be admitted if the QoS satisfaction rate of voice
services in the cell is higher than or equal to the threshold. If the QoS satisfaction rate is
lower than the threshold, these services cannot be admitted before triggering the
preemption of resources for low-priority services.
l The CellQciPara.CongestionThreshold parameter set for QCI 65 indicates the threshold
for determining the congested state of services with QCI 65. When both MCPTT QoS
management and congestion control for public safety are enabled, this parameter takes
effect. When the parameter takes effect, the cell enters the congestion state if the QoS
satisfaction rate of voice services with QCI 65 in the cell is lower than the threshold and
the system resource usage is high. Otherwise, the cell status is normal.

eRAN
l The CellQciPara.HandoverAdmissionThreshold parameter set for QCI 66 indicates the

threshold for admitting handed-over MCPTT services with QCI 66 based on the QoS
satisfaction rate. When both MCPTT QoS management and congestion control for public
safety are enabled, this parameter takes effect. When the parameter takes effect, handed-
over MCPTT services with QCI 66 can be admitted if the QoS satisfaction rate of voice
services in the cell is higher than or equal to the threshold. If the QoS satisfaction rate is
lower than the threshold, these services cannot be admitted before triggering the
preemption of resources for low-priority services.
Fast Release of Low-Priority Services

In congestion scenarios, parameters can be used to adjust the bearer releasing period of low-
priority bearers and the number of these bearers that can be released per period in the cell,
relieving congestion. The bearer release period is controlled by the
CellRacThd.CongBearRelPeriod parameter, and the bearer release number is controlled by
the CellRacThd.CongestionBearerRelCount parameter. When both MCPTT QoS
management and congestion control for public safety are enabled, this parameter takes effect.
Intelligent Access Class Control (FDD)

Compared with common data or voice services, MCPTT services involve group calls and
instant accesses of a large number of UEs. When accesses of a large number of services
simultaneously occur, intelligent access class control must be used. For details about
intelligent access priority control, see Access Class Control.
When the McpttCongCtrlSwitch option of the CellAlgoSwitch.McpttSwitch parameter is
selected, the EnodebFlowCtrlPara.McpttMsgCntSwitch parameter can be configured.
l When this parameter is set to OFF, intelligent access class control does not take effect.
l When this parameter is set to HIGH, MEDIUM, or LOW, the service access number
differs depending on the configuration level. The higher the configuration level of RRC
Connection Request messages is, the more easily low-priority UEs can access and the
harder the intelligent access control is triggered.
NOTE
If the number of instantly admitted high-access-class MCPTT UEs exceeds processing capabilities of
baseband processing boards or main control boards, flow control is triggered. RRC connection is
rejected or discarded and the intelligent access control cannot take effect.
QCI 65 Bearer Queuing

If the admission of services with QCI 65 based on the QoS satisfaction rate fails or resource
preemption fails, the eNodeB buffers bearers with QCI 65 to the queue to provide a second
attempt for these bearers carrying public safety services. This improves the E-RAB setup
success rate of QCI 65.
When the eNodeB receives an E-RAB Setup Request message requesting that the eNodeB
establish a dedicated bearer with QCI 65, this bearer needs to be queued if one of the
following conditions is met:
l Resource preemption is disabled by deselecting the PreemptionSwitch option of the
CellAlgoSwitch.RacAlgoSwitch parameter, and the service admission based on air
interface resources (such as PUCCH and SRS) and QoS satisfaction rates fails.
l Resource preemption is enabled, and the service admission based on air interfaces (such
as PUCCH and SRS) and satisfaction rates fails.

eRAN
The eNodeB buffers the bearers with QCI 65 to the queue as follows:
1. The eNodeB checks whether the queue is full, that is, whether the number of bearers
with QCI 65 in the queue exceeds the queue length.
2. If the queue is not full, the eNodeB requests new bearers with QCI 65 to the queue, and
records the time as T_request. If the PollTimerLen timer is not enabled (fixed to 500 ms
by default), the timer starts.
3. If the queue is full, the eNodeB checks whether the ARP of bearers with QCI 65 is
higher than that of the original bearers in the queue.
– If the original bearers in the queue have the lower ARP:
n The eNodeB removes the bearer with the lowest ARP from the queue. If
multiple bearers have the lowest ARP, the eNodeB removes the bearer with the
longest queuing time from the queue. Bearers removed from the queue are
handled according to the process of failed service admission.
n The eNodeB records the time when the new bear enters the queue as
T_request.
– If no bearer in the queue has the lower ARP, the eNodeB rejects the new bearer
entering the queue, and the service admission fails. The bearer is handled based on
the procedure for failed service admission.
NOTE
Queue Length = min{60, (CellQciPara.MaxQueueDuration/PollTimerLen) x 6} (PollTimerLen is

fixed to 500 ms)
The supplementary descriptions are as follows:

l Delay may increase due to the queuing and handover scenarios are delay-sensitive.
Therefore, queuing is not supported for handover messages. Otherwise, the cell may
experience call drops.
l Queuing is not supported for UEs whose RRC connection is reestablished because the
length of the T301 timer is 2s. Otherwise, UEs consider the RRC connection
reestablishment failed.
l If emergency call services are carried by bearers with QCI 65 and the admission and
congestion control switch for emergency call services are disabled, handle these services
based on the procedure for a common emergency call. Otherwise, these services are
handled based on the queuing procedure.
l If two bearers in the same E-RAB setup request message from the same UE are
established simultaneously or successively and a bearer needs to queue, the eNodeB
sends a response message after the queuing is finished. This prolongs the response time
for bearers that do not need to queue.
l Bearers with QCI 65 cannot queue during a bearer modification procedure.
l If the queuing algorithm is activated and carrier aggregation (CA) is enabled, bearers
with QCI 65 need to establish only in the primary serving cell (PCell). Otherwise,
multiple component carriers (CCs) poll the queue. For example, in two-carrier scenarios,
if the admission fails on the first carrier, the bearer needs to queue. If the admission fails
after the queuing, the bearer attempts to establish on the second carrier. The queuing time
may be uncontrollable.

eRAN
Admission of Bearers in a Queue

Admission of bearers in a queue is triggered periodically. When the timer expires, the eNodeB
selects six bearers with the highest priority in the queue and allows bearers to be admitted
based on services. The procedure is the same as that for service-based admission as follows:
l If the selected bearers are admitted successfully, the eNodeB performs the procedure of
successful service admission.
l If the admission fails and the queuing does not time out (T_elapsed is less than or equal
to the value of CellQciPara.MaxQueueDuration - PollTimerLen) (PollTimerLen is
fixed to 500 ms), the bears enter the queue again. Otherwise, the eNodeB performs the
procedure of failed service admission.
l If the queuing of a bearer times out (T_elapsed is greater than the value of
CellQciPara.MaxQueueDuration - PollTimerLen) (T_elapsed = Current time -
T_request), the queuing fails and the eNodeB performs the procedure of failed service
admission.
NOTE
If T_elapsed is greater than the value of (CellQciPara.MaxQueueDuration - PollTimerLen), the

bearer has no time for another queuing. Therefore, the bearer is removed from the queue and does
not require another queuing period.
Operator or Operator Group Scenarios

Each operator or operator group maintains a queue separately.
Length of a queue of an operator or operator group = Length of a queue/Number of operators
or operator groups in a cell (rounded up to an integer.)
l Each operator separately determines whether bearers enter a queue or are admitted. The
queuing procedure is the same as the cell-level queuing procedure. Each cell uses a
PollTimerLen timer.
l If the timer expires, each operator or operator group can remove N bearers from the
queue.
N = 6/Number of operators or operator groups in a cell (rounded up to an integer.)
7.2.1 Benefits
The following are suggestions on enabling this function:
l When there are emergency call services, it is recommended that the
EmcAdmitCongSwitch option of the CellAlgoSwitch.RacAlgoSwitch parameter be
selected to enable the MCPTT services to preempt the resources from emergency call
services.
l When cell congestion occurs, it is recommended that the
CellRacThd.CongBearRelPeriod parameter be set to a value smaller than the default
one and the CellRacThd.CongestionBearerRelCount parameter to a value larger than
the default one to quickly relieve the congestion. When MCPTT services can only be
admitted after preempting the resources from other low-priority services and there are
many MCPTT services admitted every second, it is recommended that the

eRAN
CellRacThd.PreemptableBearerNum parameter be set to a value larger than the default

one.
Congestion control for public safety monitors the QoS satisfaction rate of MCPTT GBR
services, dynamically adjusts radio resources, and triggers MCPTT services to preempt
resources of other services, ensuring the QoS satisfaction rate of MCPTT services when the
cell is congested. It mainly involves the following:
l If the admission of services with QCI 65 based on the QoS satisfaction rate fails or
resource preemption fails, the eNodeB buffers bearers with QCI 65 to the queue to
provide a second attempt for these bearers. This improves the E-RAB setup success rate
of QCI 65.
l For admission control based on QoS satisfaction rates, if the admission threshold is set to
a smaller value, MCPTT GBR services are easier to be admitted and the admission
success rate of such GBR services increases. However, the service quality of other
admitted GBR services becomes poorer.
l In multi-band networks overloaded with PTT voice services, enabling the PTT voice
service offload function increases the initial E-RAB setup success rate of PTT voice
services when admission control is activated. Disabling this function decreases the
packet loss rate of PTT voice services when admission control is not activated.
l When the eNodeBFlowCtrlPara. McpttMsgCntSwitch parameter is not set to OFF, for
MCPTT services with high access priority, the rejection and discarding due to flow
control decrease and the RRC connection success rate increases.
l The larger the value of the CellRacThd.PreemptableBearerNum parameter, the larger
the number of bearers that can be preempted per second and the number of E-RAB
releases of preempted services, and the higher the E-RAB setup success rate of
preempting services. The CPU usage also increases. On the contrary, the smaller the
value of this parameter, the smaller the number of bearers that can be preempted per
second and the number of E-RAB releases of preempted services, and the lower the E-
RAB setup success rate of preempting services. The CPU usage also decreases.
l The larger the value of the CellQciPara.MaxQueueDuration parameter, the longer the
period that bearers with QCI 65 can queue and the higher the admission success rate
when the cell has insufficient resources. However, if this parameter is set too large, the
service access delay is too long. On the contrary, the smaller the value of this parameter,
the shorter the period that bearers with QCI 65 can queue and the lower the admission
success rate when the cell has insufficient resources. This parameter must be set to a
value less than the length of the bearer setup timer in the MME. Otherwise, the bearer
setup is abnormal.
l Intelligent access class control is related to the UE penetration rate on the networks. Its
actual block effect and gains on live networks depend on the penetration rate of the UEs
that support 3GPP Release 8 and access barring. The higher the rate, the greater the
gains.
7.2.2 Impacts
Network Impacts
This function has the following network impacts:
l If network congestion results in limited system capacity, the implementation of

admission control algorithm decreases the access success rate and handover success rate.

eRAN
l If the EmcAdmitCongSwitch option of the CellAlgoSwitch.RacAlgoSwitch parameter

is selected, emergency call services can be preempted by MCPTT services, increasing
the call drop rate of emergency call services.
l When the eNodeBFlowCtrlPara.McpttMsgCntSwitch parameter is not set to OFF:
– The decrease in the number of UEs with RRC connections may cause network
access failures of UEs with low access priority. In this case, average cell throughput
and UE throughput decrease and the experience of UEs with low access priority
deteriorates.
– The number of newly admitted UEs with low access priority decreases, reducing the
number of online UEs, UEs with RRC connections, and UEs transmitting data.
l Delay occurs during system message update and delivery, and processing delay occurs
during the triggering of intelligent access class control. Therefore, too many
instantaneous RRC messages may cause flow control and the accesses of MCPTT UEs
with high access class may be rejected or discarded.
l A large value of the CellRacThd.PreemptableBearerNum parameter leads to an
increase in the CPU usage. This causes the eNodeB to perform flow control on the
preemption procedure messages, reducing the E-RAB setup success rate.
If the cell bandwidth is smaller than 5 MHz, a large value of the
CellRacThd.PreemptableBearerNum parameter may lead to insufficient resources on
preempted bearers and therefore, preemption failures. This also causes a reduction in the
E-RAB setup success rate.
l If the CellQciPara.HandoverAdmissionThreshold parameter for QCI 65 is set to a
small value, the admission threshold for handed-over services carried on bearers with
QCI 65 is low, and the QoS of the admitted services cannot be ensured. If this parameter
is set to a large value, the admission threshold for handed-over services carried on
bearers with QCI 65 is high, decreasing admission success rates of these services.
l The lower the value of the CellRacThd.CongBearRelPeriod parameter is, the more
services with low priority are released, increasing the E-RAB release rate. The larger the
value of this parameter is, the fewer services with low priority are released, decreasing
the E-RAB release rate.
l The larger the value of the CellRacThd.CongestionBearerRelCount parameter is, the
more services with low priority are released, increasing the E-RAB call drop rate. The
smaller the value of this parameter is, the more services with low priority are released,
increasing the E-RAB call drop rate.
Function Impacts
Name Switch
h
parameter

eRAN

Name Switch
7.3 Requirements
7.3.1 Licenses
RAT Feature ID Feature Model Sales Unit
Name
FDD LTROFD-111202 Congestion LT1S00CCPS0 Per cell

Control for 0
Public
Safety
TDD TDLOFD-121104 Congestion LT4SCCFPSF0 Per cell

Control for 0
Public
Safety
7.3.2 Software
Name Switch
FDD MCPTT McpttQos PTT Congestion control for public

TDD QoS Switch safety provides QoS guarantee for
manageme option of MCPTT voice services carried on
nt the bearers with QCI 65 or 66 when
CellAlgoS the system is congested.
witch.Mcp Therefore, this function depends
ttSwitch on MCPTT QoS management.
parameter

eRAN

Name Switch
FDD Admission DlSwitch Admission Congestion control for public

TDD control and and safety depends on this function to
UlSwitch Congestion admit MCPTT services based on
options of Control the satisfaction rate, preventing the
the system congestion caused by
CellAlgoS excessively admitted MCPTT
witch.Rac services and the service quality
AlgoSwitc deterioration.
h
parameter
FDD Congestion DlLdcSwit Admission It is recommended that congestion

TDD control ch and and control be enabled so that GBR
UlLdcSwit Congestion services of low priorities are
ch options Control released and MCPTT services can
of the obtain sufficient resources with
CellAlgoS ensured QoS.
witch.Rac
AlgoSwitc
h
parameter
FDD Intelligent l ACBA Access After MCPTT services are set up,
access R_SWI Class a large number of paging messages
class TCH_ Control cause unexpected UE accesses.
control DYNA The RRC connection setup success
MIC rate decreases due to the flow
option control performed on main control
of the boards or baseband processing
CellAlg units. In these scenarios, it is
oSwitc recommended that intelligent
h.AcBa access class control be enabled.
rAlgoS When this function is enabled, the
witch accesses of low-priority RRC-
paramet connected UEs carrying cause
er values mo-Data and mo-Signalling
l DYNA are gradually blocked to relieve
MIC_F cell congestion, and increase the
OR_M RRC connection setup success rate
O and access success rate of MCPTT
option UEs.
of the
CellAlg
oSwitc
h.AcBa
rAlgofo
rDynS
witch
paramet
er

eRAN

None
7.3.3 Hardware
Base Station Models

No requirements
Boards
None
RF Modules
None
7.3.4 Others
None

Table 7-1 and Table 7-2 describe the parameters used for function activation and
optimization, respectively.

h
Table 7-2 Parameters used for optimization
Load balancing algorithm CellAlgoSwitch.MlbAlgoS N/A

switch witch

eRAN
RAC algorithm switch CellAlgoSwitch.RacAlgoS N/A

witch
Congestion Bearer Release CellRacThd.CongBearRel N/A

Period Period
Congestion Bearer Release CellRacThd.CongestionBe N/A

Count arerRelCount
Preemptable Bearer Number CellRacThd.PreemptableB N/A

earerNum
Handover Admission CellQciPara.HandoverAd N/A

Threshold missionThreshold
Congestion Threshold CellQciPara.CongestionTh N/A

reshold
Max Queue Duration CellQciPara.MaxQueueDu N/A

ration

//Enabling congestion control for public safety
MOD CELLALGOSWITCH: LocalCellId=0, McpttSwitch=McpttCongCtrlSwitch-1;

//Enabling PTT voice service offload
MlbAlgoSwitch=VoIPOffloadSwitch-1&PTTOffloadSwitch-1;
//Enabling admission and congestion control for emergency call services

MOD CELLALGOSWITCH: LocalCellId=0, RacAlgoSwitch=EmcAdmitCongSwitch-1;
//Configuring the bearer release period

MOD CELLRACTHD: LocalCellId=0,CongBearRelPeriod=1;
//Configuring the number of bearers that can be released

MOD CELLRACTHD: LocalCellId=0,CongestionBearerRelCount=15;
//Configuring the number of bearers that can be preempted

MOD CELLRACTHD: LocalCellId=0,PreemptableBearerNum=60;
//Configuring the congestion threshold for services with QCI 65

MOD CELLQCIPARA:LocalCellID=0,QCI=65, CongestionThreshold=55;
//Configuring the handover admission threshold for services with QCI 65

MOD CELLQCIPARA:LocalCellID=0,QCI=65,HandoverAdmissionThreshold=80;
//Configuring the handover admission threshold for services with QCI 66

MOD CELLQCIPARA:LocalCellID=0,QCI=66,HandoverAdmissionThreshold=85;
//Configuring the longest queue duration for bearers with QCI 65

MOD CELLQCIPARA:LocalCellID=0,QCI=65, MaxQueueDuration=3;

eRAN

//Disabling congestion control for public safety
MOD CELLALGOSWITCH: LocalCellId=0, McpttSwitch=McpttCongCtrlSwitch-0;


Observation of admission control based on QoS satisfaction rates
Management. In the left navigation tree of the Signaling Trace Management window,
choose Trace Type > LTE > Application Layer > S1 Signaling Trace. Create an S1
standard signaling trace task and choose Cell Performance Monitoring > QoS Satisfaction
Rate Monitoring to start monitoring service QoS satisfaction rates.
Step 2 Create GBR data transmission services with QCI 65 for UEs that access the network. Move
some UEs toward the cell center and increase the traffic volume of GBR services on these
UEs. Move some UEs toward the cell edge until the cell is congested, which can be monitored
based on Congestion State in the monitoring results.
Step 3 Initiate a request for setting up a new bearer with QCI 65.
Expected result: Admission of new GBR services fails. View the S1 signaling messages
S1AP_ERAB_SETUP_REQ and S1AP_ERAB_SETUP_RSP. If the cause value for E-RAB
setup failures is "radioNetwork: radio resources not available" in the
S1AP_ERAB_SETUP_RSP messages, or if the number of services (specified by L.E-
RAB.AttEst.QCI.65) does not increase with the increase of S1AP_ERAB_SETUP_REQ
messages, the new GBR service requests have been rejected.
----End
Service preemption observation
In the S1 signaling message S1AP_ERAB_SETUP_REQ, view the QCIs and ARP values of
different GBR services and check whether these services can preempt resources of other
services or can be preempted and their preemption attributes (0 indicates that resources of the
services are not preemptable and 1 indicates that the resources are preemptable). A larger
ARP value indicates a lower priority. Figure 7-1 shows the ARP values and preemption
attributes.

eRAN
Figure 7-1 S1AP_ERAB_SETUP_REQ message that includes the ARP value and the
preemption attributes
Step 1 Start related trace tasks on the U2020 client. For details, see Step 1.
Step 2 Enable some UEs to access the network and set up low-priority services with QCI 3 for the
UEs.
Step 3 Enable some UEs to access the network and create high-priority services with QCI 65.
Simulate a congestion based on the instruction provided in Step 2.
Step 4 Initiate a request for setting up a new bearer with QCI 65.
Expected result: Services with QCI 65 preempt resources of services with QCI 3 and are
admitted to the cell successfully. The bearer with QCI 3 is released because its resources are
preempted.
----End
PTT voice service offload observation
For details about the activation verification of PTT voice service offload, see the activation
verification of voice service offload in Intra-RAT Mobility Load Balancing.

You can monitor the performance of this function based on the performance counters
described in Table 7-3.
Table 7-3 Performance counters related to congestion control for public safety
1526741997 L.E-
RAB.FailEst.NoRadioRes.DLSatis.QCI65
1526741998 L.E-
RAB.FailEst.NoRadioRes.DLSatis.QCI66
1526741999 L.E-
RAB.FailEst.NoRadioRes.ULSatis.QCI65
1526742000 L.E-
RAB.FailEst.NoRadioRes.ULSatis.QCI66
1526728171 L.EMC.E-RAB.Abnormrel

eRAN
1526748746 L.E-
65
1526748770 L.E-
69
1526748775 L.E-
RAB.FailEst.NoRadioRes.RrcUserLic.Q
CI69

eRAN
PTT Feature Parameter Description 8 RRC and DRX Policy for Public Safety
8 RRC and DRX Policy for Public Safety
8.1 Principles
RRC and DRX policy for public safety configures independent inactivity timers and
discontinuous reception (DRX) parameter groups for MCPTT UEs, reducing UE access delay.
UEs in DRX state can dynamically turn on or off its receiver to determine whether to receive
data and signaling from the network to reduce UE power consumption.
The McpttRrcDrxSwitch option of the CellAlgoSwitch.McpttSwitch parameter specifies
whether to enable RRC and DRX policy for public safety, and the functions described in
3.3.5.5 Power Consumption and Delay Improvement are used to reduce the access delay
and power consumption of MCPTT UEs. To better increase energy efficiency of MCPTT
services in DRX scenarios, the eNodeB provides a set of dedicated DRX parameter values.
The bearers for carrying MCPTT voice media services are mapped to QCI 65, and bearers
with QCI 69 are also required for carrying signaling during MCPTT service setup. Therefore,
when QCIs (65 and 69) of different levels are used for MCPTT services, the
DrxParaGroup.LongDrxCycle parameter must be set to the minimum value for QCI 65 to
ensure that the eNodeB selects the DRX parameters mapped to QCI 65 as the DRX
parameters of the related MCPTT UE. For details about the recommended DRX parameter
settings for MCPTT services, see Table 8-1.
Table 8-1 Recommended DRX parameter settings for MCPTT services

Parameter ID Recommended Value Recommended Value
(Semi-Persistent (Semi-Persistent
Scheduling Enabled) Scheduling Disabled)
DrxParaGroup.LongDrxC SF20 SF40

ycle
DrxParaGroup.OnDuratio PSF10 PSF10

nTimer
DrxParaGroup.DrxInactivi PSF80 PSF80

tyTimer

eRAN
Parameter ID Recommended Value Recommended Value

(Semi-Persistent (Semi-Persistent
Scheduling Enabled) Scheduling Disabled)
DrxParaGroup.DrxReTxTi PSF8 PSF8

mer
DrxParaGroup.SupportSh UU_DISABLE UU_DISABLE

ortDrx
The process of deploying RRC and DRX policy for public safety is as follows:
1. Map MCPTT services to the specified standardized QCIs 65, 66, 69, and 70 using the
static or dynamic PCC function of the EPC.
2. Use a bearer with QCI 65 or 66 to carry new MCPTT voice services, a bearer with QCI
69 to carry signaling of MCPTT services, and a bearer with QCI 70 to carry MCPTT
data services.
3. Turn on the switch for RRC and DRX policy for public safety.
8.2.1 Benefits
This function is recommended in scenarios where operators can deploy standardized QCIs 65,
66, 69, and 70 and expect UEs that use bearers of these QCIs to carry MCPTT services can
use dedicated RRC inactivity timers and DRX parameter groups.
MCPTT services burst out more frequently and last longer than common voice services.
Therefore, MCPTT UEs use independent DRX inactivity timers and DRX parameter groups
to reduce access delay and UE power consumption.
8.2.2 Impacts
Network Impacts
When dynamic DRX is disabled:
l A smaller value of the QciPara.UeInactiveTimerForQci parameter indicates that RRC
connections of UEs not performing PTT services are released earlier. This results in
frequent RRC connection setup requests initiated by UEs and improves network KPIs,
such as the service drop rate, due to more normal releases.
l A larger value of the QciPara.UeInactiveTimerForQci parameter indicates that RRC
connections of UEs not performing PTT services are released later. This results in more
radio resource consumption because such UEs will stay in connected mode longer. In
addition, network KPIs, such as the service drop rate, deteriorate due to fewer normal
releases.
l A smaller value of the QciPara.UlSynTimerForQci parameter indicates a higher
probability that UEs enter the out-of-synchronization state, increasing the number of
random accesses for maintaining the uplink synchronization and increasing signaling
load caused by the random accesses.

eRAN
l A larger value of the QciPara.UlSynTimerForQci parameter indicates that UEs cannot

enter the out-of-synchronization state in time, affecting UE power consumption and
occupying additional PUCCH and SRS resources.
When dynamic DRX is enabled:
l A smaller value of the QciPara.UeInactivityTimerDynDrxQci parameter indicates that
RRC connections of UEs not performing PTT services are released earlier. This results in
frequent RRC connection setup requests initiated by UEs and improves network KPIs,
such as the service drop rate, due to more normal releases.
l A larger value of the QciPara.UeInactivityTimerDynDrxQci parameter indicates that
RRC connections of UEs not performing PTT services are released later. This results in
more radio resource consumption because such UEs will stay in connected mode longer.
In addition, network KPIs, such as the service drop rate, deteriorate due to fewer normal
releases.
Function Impacts
Name Switch
h
parameter
8.3 Requirements
8.3.1 Licenses
Name
FDD LTROFD-111203 RRC and LT1S0RDPPS0 Per cell

DRX 0
Policy for
Public
Safety

eRAN

Name
TDD TDLOFD-121105 RRC and LT4SRCDPPS0 Per cell

DRX 0
Policy for
Public
Safety
8.3.2 Software
Name Switch
FDD MCPTT McpttQos PTT RRC and DRX policy for public
TDD QoS Switch safety uses RRC inactivity timers
Manageme option of and DRX parameter groups
nt the dedicated to MCPTT services
CellAlgoS carried on bearers with QCIs 65,
witch.Mcp 66, 69, and 70. Therefore, this
ttSwitch function can be used only after
parameter MCPTT QoS management is
enabled.
FDD DRX CellDrxPa DRX and This function affects MCPTT

TDD ra.DrxAlg Signaling services carried on bearers with
Switch Control QCIs 65, 66, 69, and 70.
Dedicated DRX parameter groups
are configured for QCIs 65, 66, 69,
and 70, reducing MCPTT UE
power consumption.
l If the RRC connection
inactivity timer for MCPTT
UEs is set to a large value,
MCPTT UEs can remain online
for a long period of time,
reducing delay in accessing the
cell again but increasing power
consumption.
l It is recommended that DRX
be enabled to configure proper
DRX parameter groups for
MCPTT UEs, reducing UE
power consumption. For details
about DRX, see DRX and
Signaling Control.

eRAN

None
8.3.3 Hardware
Base Station Models

No requirements
Boards
None
RF Modules
None
8.3.4 Networking
None
8.3.5 Others
None

The following table describes the parameters that must be set in the CellAlgoSwitch MO.
MCPTT Switch CellAlgoSwitch.McpttSwitc -

h
Dynamic DRX switch CellAlgoSwitch.DynDrxSw -

itch
The following table describes the parameters that must be set in the QciPara MO.
UE Inactive Timer for QCI QciPara.UeInactiveTimer- The recommended value is

ForQci 30.

eRAN
UE Inactivity Timer QciPara.UeInactivityTimer If an MCPTT UE sets up

Dynamic DRX for QCI DynDrxQci multiple bearers, the UE
inactivity timer for QCI 69
is used for UEs that have
entered DRX mode.
Uplink Synchronization QciPara.UlSynTimerForQc If an MCPTT UE sets up

Timer for QCI i multiple bearers, the uplink
synchronization timer for
QCI 69 is used.
Configure parameters in the CellDrxPara MO for MCPTT UEs:

1. The following table describes the parameters that must be set in the CellDrxPara MO.
DRX switch CellDrxPara.DrxAlgSwitch -
Short DRX Cycle Switch CellDrxPara.ShortDrxCycl Set this parameter to ON if

eSwitch there are high delay
requirements.
2. The following table describes the parameters that must be set in the DrxParaGroup MO.
DRX parameter group ID DrxParaGroup.DrxParaGr -

oupId
Enter DRX Switch DrxParaGroup.EnterDrxS l The value OFF is

witch recommended for bearers
with tight delay
constraints.
l The value ON is
recommended for bearers
without tight delay
constraints.
On Duration Timer DrxParaGroup.OnDuratio You are advised to set this

nTimer parameter to PSF10 if
DrxParaGroup.LongDrxC
ycle is set to SF320.

eRAN
DRX Inactivity Timer DrxParaGroup.DrxInactivi A larger parameter value

tyTimer results in a longer active
time upon the arrival of new
data in an on duration timer.
You are advised to set this
parameter to PSF100 if
DRX Retransmission Timer DrxParaGroup.DrxReTxTi -

mer

eRAN
Long DRX Cycle DrxParaGroup.LongDrxC l You are advised to set

ycle this parameter to a value
less than or equal to 320
ms if
TimeAlignmentTim-
er.TimingAdvCmdOptS-
witch is set to ON.
Otherwise, the uplink
time alignment
performance of UEs is
affected.
l You are advised to set
this parameter to SF320a
and
TimeAlignmentTim-
er.TimeAlignmentTimer
to SF10240 for
smartphones with high
power-saving
requirements.
l For VoIP services with
QCI 1, if the
SpsSchSwitch option of
the
CellAlgoSwitch.DlSchS
witch parameter is
selected, set this
parameter to a value less
than or equal to the semi-
persistent scheduling
period (20 ms).
Otherwise, downlink
semi-persistent
scheduling cannot take
effect.
l The length of the long
DRX cycle must be less
than the value of
RlcPdcpParaGroup.Dis
cardTimer (indicating
the length of the PDCP
data discard timer for the
corresponding QCI,
where PDCP is short for
Packet Data
Convergence Protocol).
Otherwise, packet loss
occurs during ping

eRAN
operations or low-traffic
services.
Short-Cycle DRX Supported DrxParaGroup.SupportSh -

Indication ortDrx
Short DRX Cycle DrxParaGroup.ShortDrxC You are advised to set this

ycle parameter to SF80 if
DRX Short Cycle Timer DrxParaGroup.DrxShortC You are advised to set this
ycleTimer parameter to 1 if
a: Theoretically, a long DRX cycle of 320 ms prolongs the interval at which the measured
RSRP is reported. This may reduce the handover success rate, which is closely related to
UE mobility and weak-coverage networking. Lab tests need to be conducted for specific
scenarios. If the test results meet customer expectations, a long DRX cycle of 320 ms can
be used. In cells where UEs move at high speeds, use the default long DRX cycle of 40 ms.
3. The following table describes the parameters that must be set in the CellQciPara MO.
QoS Class Indication CellQciPara.Qci -
DRX parameter group ID CellQciPara.DrxParaGrou Modify the DRX parameters

pId mapped to the QCI, if
required, in the identified
parameter group.
QCI Priority For DRX CellQciPara.QciPriorityFo If the bearers for a UE have

rDrx multiple QCIs and the
CellDrxPara.DrxPolicyMo
de parameter is set to
QCIPRIORITY, the
eNodeB selects the DRX
parameter group for the UE
based on the QCI-specific
priorities.
4. The following table describes the parameter that must be set in the TimeAlignmentTimer
MO.

eRAN
Uplink time alignment timer TimeAlignmentTim- When the

er.TimeAlignmentTimer DrxParaGroup.LongDrxC
ycle parameter value is
greater than or equal to 80
ms, change the
TimeAlignmentTim-
parameter value from 1920
ms (the default value) to
10240 ms to ensure that a
long DRX cycle does not
affect synchronization.
You are advised to set this
parameter to SF10240 if the
TimeAlignmentTim-
er.TimingAdvCmdOptS-
witch parameter is set to
ON. If the
TimeAlignmentTim-
parameter is set to a small
value, for example, less than
5120 ms, the probability of
uplink out-of-
synchronization for UEs in
DRX mode increases.

//Turning on the switch for the RRC and DRX Policy for Public Safety feature
MOD CELLALGOSWITCH: LocalCellId=0, McpttSwitch=McpttRrcDrxSwitch-1;
//(Optional, required when dynamic DRX is disabled) Adjusting the QCI-based UE

inactivity timer and uplink synchronization timer for PTT services
MOD QCIPARA: Qci=69, UeInactiveTimerForQci=30, UlSynTimerForQci=20;
//(Optional, required when dynamic DRX is enabled) Adjusting the QCI-based UE

inactivity timer in dynamic DRX mode
MOD QCIPARA: Qci=69, UeInactivityTimerDynDrxQci=200;
//Configuring DRX parameters

//Configuring performance-preferred DRX parameters
MOD CELLDRXPARA: DrxAlgSwitch=ON, ShortDrxCycleSwitch=ON;
MOD CELLQCIPARA: LocalCellId=0, Qci=69, DrxParaGroupId=3;
MOD TATIMER: LocalCellId=0, TimeAlignmentTimer=SF1920;
MOD CELLDRXPARA: LocalCellID=0, FddEnterDrxThd =1000, FddExitDrxThd = 1000;
MOD DRXPARAGROUP: LocalCellId=0, DrxParaGroupId=3, EnterDrxSwitch=ON,
OnDurationTimer=PSF2, DrxInactivityTimer=PSF80, DrxReTxTimer=psf8,
LongDrxCycle=SF40, SupportShortDrx=UU_ENABLE, ShortDrxCycle=SF20,
DrxShortCycleTimer=1;
//Configuring power saving-preferred DRX parameters
MOD CELLDRXPARA: DrxAlgSwitch=ON, ShortDrxCycleSwitch=ON;

eRAN
MOD CELLQCIPARA: LocalCellId=0, Qci=69, DrxParaGroupId=3;

MOD TATIMER: LocalCellId=0, TimeAlignmentTimer=SF10240;
MOD CELLDRXPARA: LocalCellID=0, FddEnterDrxThd =1000, FddExitDrxThd = 1000;
MOD DRXPARAGROUP: LocalCellId=0, DrxParaGroupId=3, EnterDrxSwitch=ON,
OnDurationTimer=PSF10, DrxInactivityTimer=PSF100, DrxReTxTimer=psf8,
LongDrxCycle=SF320, SupportShortDrx=UU_ENABLE, ShortDrxCycle=SF80,
DrxShortCycleTimer=1;

N/A

//Turning off the switch for the RRC and DRX Policy for Public Safety feature
MOD CELLALGOSWITCH: LocalCellId=0, McpttSwitch=McpttRrcDrxSwitch-0;

8.4.2 Activation Observation

Step 1 Run the LST CELLQCIPARA command to query the DRX parameter group ID for the QCI
of the bearer carrying PTT services.
Step 2 Run the LST DRXPARAGROUP command.
If the command output shows that the Enter DRX Switch parameter value is On for a QCI of
the bearer carrying PTT services, DRX has been activated for this QCI.
Step 3 Enable a PTT UE to access the network and observe the RRC Connection Reconfiguration
message (displayed as RRC_CONN_RECFG).
If the message contains DRX parameters shown in Figure 8-1, the eNodeB has instructed the
PTT UE to enter DRX mode.

eRAN
Figure 8-1 DRX parameters contained in the RRC Connection Reconfiguration message
----End

None

eRAN
PTT Feature Parameter Description 9 MCPTT Voice Management
9 MCPTT Voice Management
9.1 Principles
The McpttVoiceMgtSwitch option of the CellAlgoSwitch.McpttSwitch parameter
determines whether to enable MCPTT voice management, and the functions described in
3.3.5.2 Capacity Improvement, 3.3.5.3 Coverage Enhancement, and 3.3.5.4 Quality
Improvement are used to increase the capacity and improve the coverage and voice quality
of MCPTT voice services, respectively.
The process of deploying MCPTT Voice management is as follows:
1. Map MCPTT services to the specified standardized QCIs 65, 66, 69, and 70 using the
static or dynamic PCC function of the EPC.
2. Use a bearer with QCI 65 or 66 to carry new MCPTT voice services, a bearer with QCI
69 to carry signaling of MCPTT services, and a bearer with QCI 70 to carry MCPTT
data services.
3. If ROHC is to be used, check whether the licenses required for this function have been
activated.
4. Configure the switch for MCPTT voice management.
a. Turn on the MCPTT voice management switch.
b. Configure parameters related to MCPTT voice optimization.
n (Optional) Enable ROHC for MCPTT voice services.
n (Optional) Enable semi-persistent scheduling for MCPTT services.
n (Optional) Enable TTI bundling for MCPTT services.
n (Optional) Enable UL compensation scheduling for MCPTT services.
n (Optional) Enable voice-specific AMC for MCPTT services.
n (Optional) Enable voice characteristic awareness scheduling for MCPTT
services.
n (Optional) Enable TBS-based MCS selection for downlink MCPTT services.

eRAN
9.2.1 Benefits
This function is recommended in scenarios where operators meet the conditions of using
standardized QCIs 65, 66, 69, and 70 and expect to use MCPTT voice services carried on
bearers with QCIs 65 and 66. This improves the performance, coverage, and capacity while
reducing the voice packet loss rate.
9.2.2 Impacts
Network Impacts
l ROHC
When ROHC is enabled:
– It reduces the amount of data transmitted over the air interface. For voice service
users at the cell edge, it helps to reduce the number of Radio Link Control (RLC)
segments and decrease the voice packet delivery delay. It can increase the uplink
coverage by about 1 dB to 2 dB and ensure voice quality, for example, maintaining
the voice quality at a mean opinion score (MOS) of 3.0.
– It reduces the number of bytes of the headers of PTT service packets, reducing air
interface overhead and RBs occupied by voice UEs. This ensures that more RBs are
allocated to UEs performing data services, increasing throughput of data services.
After semi-persistent scheduling is enabled, PDCCH resources do not hinder PTT
service capacity because PDCCH resources are consumed only when semi-persistent
scheduling is initially activated or reactivated or when semi-persistently allocated
resources are released. Therefore, enabling semi-persistent scheduling can increase the
number of supported PTT UEs. However, semi-persistent scheduling consumes more
RBs than dynamic scheduling. As a result, RBs that can be used by UEs performing data
services are reduced, decreasing the service throughput.
Fixed-position resource allocation is adopted after semi-persistent scheduling is enabled.
Compared with dynamic scheduling, semi-persistent scheduling may increase the
scheduling wait time.
l TTI bundling
TTI bundling increases the uplink PUSCH coverage, increases the MCS in uplink weak-
coverage areas, and reduces the packet loss rate. However, this feature increases
signaling overhead because the entry and exit of the TTI bundling state require the
exchange of RRC messages. When the number of TTI bundling mode reconfiguration
messages (indicated by the counters L.Signal.Num.TtiBundling.Enter and
L.Signal.Num.TtiBundling.Exit) increases, the average board CPU usage, indicated by
the counter VS.BBUBoard.CPULoad.Mean (%), slightly increases.
As defined in 3GPP specifications, TTI bundling uses a maximum of three PRBs and
adopts QPSK with the highest MCS order of 10. That is, after TTI bundling is enabled,
the maximum TBS that can be transmitted is 504 bits. This restricts the uplink
throughput of TTI bundling. The logical channel priority of signaling and voice services
is higher than that of data services, which means that UEs preferentially send signaling
and voice services. As a result, the uplink throughput of data services is further
restricted.
Estimation of the PTT data volume for uplink dynamic scheduling shortens the voice
service delay, reduces the uplink packet loss rate, and improves voice quality when a cell

eRAN
is heavily loaded and DRX is enabled. However, this function increases the number of
RBs consumed by voice UEs and lowers MCS indexes selected for voice UEs. When
there are many voice UEs, this function also reduces cell throughput.
When the CellUlschAlgo.UlDelaySchStrategy parameter is set to
VOIP_AND_DATA_DELAYSCH(VoIP and Data Delay Scheduling) in heavy cell
load scenarios, the impact on network performance is as follows:
– Improved voice quality
– Prolonged E-RAB setup time, RRC connection setup time, ping delay, time of
transition from RRC_IDLE mode to RRC_CONNECTED mode, and attach delay
– Slightly decreased cell throughput
When the CellUlschAlgo.UlDelaySchStrategy parameter is set to
VOIP_AND_DATA_DELAYSCH(VoIP and Data Delay Scheduling) in heavy cell
load scenarios, the impact on network performance is as follows:
– Improved voice quality
– Increased uplink throughput of data services
– Increased ping delay and attach delay
– Reduced downlink throughput of data services
l Uplink compensation scheduling
UL compensation scheduling reduces the uplink packet loss rate for PTT voice UEs in
heavy traffic scenarios, shortens the voice packet delay, and improves voice quality for
PTT services. However, it increases RB and CCE overhead. When there are many PTT
voice UEs, this function also reduces cell throughput.
In addition, UL compensation scheduling decreases the possibility that uplink control
information of PTT voice UEs is transmitted over the PUCCH and increases the
possibility that uplink control information of PTT voice UEs is transmitted over the
PUSCH. This affects the possibility that PDSCH ACK/NACK is detected as DTX and
slightly increases the downlink packet loss rate of PTT voice services (indicated by
L.Traffic.DL.PktUuLoss.Loss.QCI.65/L.Traffic.DL.PktUuLoss.Tot.QCI.65).
This feature affects voice quality in the following aspects:
– If the CellQciPara.SinrAdjustTargetIbler parameter is set to a smaller value for a
QCI used for PTT voice services, the uplink MCS indexes selected for UEs
performing voice services are smaller. For PTT voice UEs in the cell center, the
uplink packet loss rate may slightly decrease and the voice quality almost remains
unchanged. For PTT voice UEs not in the cell center, the number of uplink RLC
segments increases and the uplink QCI packet loss rate may increase in the case of
heavy load. As a result, voice quality becomes worse and voice capacity decreases.
– If the CellQciPara.SinrAdjustTargetIbler parameter is set to a larger value for a
QCI used for PTT voice services, the uplink MCS indexes selected for UEs
performing voice services are larger. In the uplink, the IBLER, RBLER, and QCI
packet loss rate increase, and voice quality becomes worse. In the downlink, the
QCI packet loss rate also increases and voice quality also becomes worse because
the demodulation performance deteriorates for ACKs/NACKs and channel status
information transmitted on the PUSCH.
This feature may also affect cell throughput and data service throughput. If the
CellQciPara.SinrAdjustTargetIbler parameter is set to a smaller value for a QCI used
for PTT voice services, the uplink MCS indexes selected for UEs performing voice

eRAN
services are smaller and the number of consumed RBs increases. When there are many
PTT voice UEs, cell throughput decreases.
This function reduces downlink HARQ retransmissions and the BER of initial
transmissions for PTT voice services.
This function prevents UEs that have initiated PTT voice services from entering the CA
state, ensuring voice quality. However, it may decrease cell throughput.
Function Impacts
Name Switch
FDD ROHC N/A ROHC ROHC improves the network

TDD capacity and coverage when
MCPTT voice management is
enabled.
h
parameter
9.3 Requirements
9.3.1 Licenses
Name
FDD LTROFD-111204 MCPTT LT1SMCPTTV Per cell

Voice M0
Manageme
nt
TDD TDLOFD-121106 MCPTT LT4SMCPTVM Per cell

Voice 00
Manageme
nt

eRAN
9.3.2 Software
Name Switch
FDD MCPTT McpttQos PTT MCPTT voice management

TDD QoS Switch optimizes MCPTT voice services
manageme option of with QCIs 65 and 66. Therefore,
nt the this function can be used only after
CellAlgoS MCPTT QoS management is
witch.Mcp enabled.
ttSwitch
parameter

None
9.3.3 Hardware
Base Station Models

No requirements
Boards
No requirements
RF Modules
No requirements
9.3.4 Networking
None
9.3.5 Others
None

eRAN

Table 9-1 and Table 9-2 describe the parameters used for function activation and
optimization, respectively.


h
Table 9-2 Parameters used for optimization

ROHC switch CellAlgoSwitch.RohcSwitc N/A

h
Uplink Schedule Extended CellAlgoSwitch.UlSchExtS N/A

Switch witch
DL schedule switch CellAlgoSwitch.DlSchSwit N/A

ch
DL Scheduling Extension CellAlgoSwitch.DlSchExtS N/A

Switch witch
SINR Adjustment Target CellQciPara.SinrAdjustTar N/A

IBLER getIbler
Min UL Compensate CellUlschAlgo.UlCompenS N/A

Scheduling Period in Spurt chPeriodinSpurt
Min UL Compensate CellUlschAlgo.UlCompenS N/A

Scheduling Period in chPeriodinSilence
Silence
Uplink Delay-based CellUlschAlgo.UlDelaySch N/A

Scheduling Strategy Strategy

//Turning on the MCPTT QoS management switch
MOD CELLALGOSWITCH: LOCALCELLID=0, McpttSwitch=McpttQoSSwitch-1;
//Turning on the MCPTT voice management switch

MOD CELLALGOSWITCH: LocalCellId=0, McpttSwitch=McpttVoiceMgtSwitch-1;

//Enabling ROHC
MOD CELLALGOSWITCH: LocalCellId=0,RohcSwitch=ON;

eRAN
//Enabling semi-persistent scheduling for PTT services

MOD CELLALGOSWITCH:
LocalCellId=0,UlSchExtSwitch=EnhExtQCISpsSchSwitch-1,DlSchSwitch=EnhExtQCISpsSchSw
itch-1;
//Enabling TTI bundling for PTT services

MOD CELLALGOSWITCH: LocalCellId=0,UlSchExtSwitch=EnhExtQCITtiBundlingSwitch-1;
//Enabling UL compensation scheduling for PTT services

MOD CELLALGOSWITCH: LocalCellId=0,UlSchExtSwitch=UlPttSchOptSwitch-1;
//Enabling voice characteristic awareness scheduling in the uplink for PTT

services
MOD CELLULSCHALGO: LocalCellId=0,UlDelaySchStrategy=VOIP_DELAYSCH;
MOD CELLALGOSWITCH: LocalCellId=0,UlSchExtSwitch=UlPttDataSizeEstSwitch-1;
//Configuring parameters for uplink voice-specific AMC for PTT services

MOD CELLQCIPARA: LocalCellId=0,Qci=65,SinrAdjustTargetIbler=10;
MOD CELLQCIPARA: LocalCellId=0,Qci=66,SinrAdjustTargetIbler=10;
//Enabling TBS-based MCS selection for downlink PTT services

MOD CELLALGOSWITCH: LocalCellId=0, DlSchExtSwitch=PTT_TBS_BASED_MCS_SEL_SWITCH-1;

//Turning off the MCPTT voice management switch
MOD CELLALGOSWITCH: LocalCellId=0, McpttSwitch=McpttVoiceMgtSwitch-0;


The procedure for activation observation is as follows:
l ROHC activation observation
a. On the U2020 client, create and start a Uu interface tracing task.
b. Use an ROHC-capable UE to perform an MCPTT service. Check the
RRC_UE_CAP_INFO message, as shown in Figure 9-1, to determine whether the
UE supports ROHC and which profiles the UE supports.

eRAN
Figure 9-1 RRC_UE_CAP_INFO message
c. Check the RRC_CONN_RECFG message to determine whether ROHC has been

activated, as shown in Figure 9-2.
n If the information elements (IEs) pdcp-Config > headerCompression > rohc
are displayed, ROHC has been activated.
n If the IEs pdcp-Config > headerCompression > notUsed: NULL are displayed,
ROHC has not been activated.

eRAN
Figure 9-2 RRC_CONN_RECFG message
l Activation observation for semi-persistent scheduling of MCPTT services

Observe the values of the L.Sps.UL.SchNum.Ptt and L.Sps.DL.SchNum.Ptt counters.
l Activation observation for TTI bundling of MCPTT services
Observe the values of the L.Signal.Num.TtiBundling.Enter and
L.Signal.Num.TtiBundling.Exit counters.
l Activation observation for voice characteristic awareness scheduling of MCPTT services
Observe the values of the L.Traffic.UL.PktLoss.Loss.QCI.65 and
L.Traffic.UL.PktLoss.Tot.QCI.65 counters.
Expected result: The value of L.Traffic.UL.PktLoss.Loss.QCI.65/
L.Traffic.UL.PktLoss.Tot.QCI.65 becomes smaller.
l Activation observation for UL compensation scheduling for MCPTT services
Observe the values of the L.Traffic.UL.PktLoss.Loss.QCI.65 and
L.Traffic.UL.PktLoss.Tot.QCI.65 counters.
Expected result: The value of L.Traffic.UL.PktLoss.Loss.QCI.65/
L.Traffic.UL.PktLoss.Tot.QCI.65 becomes smaller.
l Activation observation for voice-specific AMC of MCPTT services
MCPTT services carried on bearers with only QCI 65 are performed in the cell. The UL
IBLER of uplink voice UEs is calculated using the following formula:
UL IBLER = (L.Traffic.UL.SCH.QPSK.ErrTB.Ibler + L.Traffic.UL.SCH.
16QAM.ErrTB.Ibler + L.Traffic.UL.SCH.64QAM.ErrTB.Ibler)/

eRAN
(L.Traffic.UL.SCH.QPSK.TB + L.Traffic.UL.SCH.16QAM.TB +
L.Traffic.UL.SCH.64QAM.TB)
Expected result: The uplink IBLER of uplink voice UEs calculated using the preceding
formula is close to the configured value.
l Activation Observation for TBS-based MCS Selection for Downlink MCPTT Services
Step 1 On the U2020 client, choose Monitor > Signaling Trace > Signaling Trace Management.
Step 2 In the left pane of the displayed window, choose User Performance Monitoring > BLER
Monitoring. Set the tracing duration and MME ID.
Step 3 Check on the U2020 client whether the IBLER values converge.
----End
l Observation of the CA state of MCPTT UEs
For details about how to observe the CA state of MCPTT UEs, see Carrier Aggregation.

You can monitor the performance of this feature based on the performance counters described
in Table 9-3.
Table 9-3 Performance counters related to MCPTT services

1526742120 L.Traffic.UL.PktLoss.Loss.QCI.65
1526742121 L.Traffic.UL.PktLoss.Loss.QCI.66
1526742124 L.Traffic.UL.PktLoss.Tot.QCI.65
1526742125 L.Traffic.UL.PktLoss.Tot.QCI.66

eRAN 10 Uplink PUSCH RB Reservation for MCPTT Voice
PTT Feature Parameter Description Services
10 Uplink PUSCH RB Reservation for

MCPTT Voice Services
10.1 Principles
This function allows certain number of RBs at a specified position to be reserved for MCPTT
voice services on the PUSCH.
l MCPTT voice services can preferentially use reserved RB resources. If the reserved RB
resources are used up, MCPTT voice services can use non-reserved RB resources.
l However, non-MCPTT voice services cannot use reserved RB resources.
l The number of reserved RBs cannot exceed 50% of RBs available in the system
bandwidth.
Uplink PUSCH RB reservation for MCPTT voice services is enabled by setting

CellRbReserve.RbRsvMode to MCPTT_RB_RESERVED. The
CellRbReserve.RbRsvType parameter must be set to UPLINK_MODE. The
CellRbReserve.RbRsvStartIndex parameter specifies the start position of reserved RBs, and
the CellRbReserve.RbRsvEndIndex parameter specifies the end position of reserved RBs.
10.2.1 Benefits
When MCPTT voice services use reserved RBs, the RBs allocated for UEs performing
MCPTT services do not overlap those allocated for UEs performing other services. This
reduces the interference of UEs performing other services on UEs performing MCPTT
services, decreasing the uplink packet loss rate of UEs performing MCPTT services.
l It is recommended that this function be enabled in heavy-load scenarios. Specifically, the

average interference to the PUSCH on the full bandwidth (measured by
L.UL.Interference.Avg) is greater than –110 dBm.
l It is recommended that this function not be enabled in scenarios where RB resources are
limited in a cell with a bandwidth of 5 MHz or less.

10.2.2 Impacts
Network Impacts
After RBs are reserved, the uplink access success rate of non-MCPTT services, average user
rate, and throughput decrease, and the call drop rate increases.
MCPTT services can use full-band RBs, and non-MCPTT services can use only non-reserved
RBs. As a result, the RB usage of non-MCPTT services increases.
Function Impacts
Name Switch
FDD eMTC EMTC_SWIT eMTC It is not

TDD introduction CH option of recommended
the that uplink
CellEmtcAlgo. PUSCH RB
EmtcAlgoSwitc reservation for
h parameter MCPTT voice
services and
eMTC
introduction be
enabled at the
same time. The
reserved RBs
may conflict
with the RBs
used by eMTC
UEs, affecting
eMTC services.
If these two
functions need
to be enabled at
the same time,
it is
recommended
that the
reserved RBs
be different
from the RBs
used by eMTC
UEs.


Name Switch
FDD Compact Cell.Customize Compact If compact

bandwidth dBandWidthCf Bandwidth bandwidth is
gInd (FDD) enabled, the
number of RBs
reserved for this
function cannot
exceed 50% of
available RBs
of the standard
bandwidth that
can be
deployed. For
example, if
compact
bandwidth is
enabled in the
12.5 MHz cell
bandwidth, the
number of
reserved RBs
cannot exceed
50% of
available RBs
in the 10 MHz
cell bandwidth.
FDD Short TTI SHORT_TTI_ Short TTI The eNodeB

SW option of (FDD) does not
the schedule a UE
CellShortTtiAl in short TTI
go.SttiAlgoSwit mode if a PTT
ch parameter bearer has been
set up for this
UE. If a PTT
bearer is set up
during short
TTI scheduling,
the eNodeB
immediately
stops short TTI
scheduling for
this UE.
10.3 Requirements

10.3.1 Licenses
None
10.3.2 Software
Name Switch
FDD MCPTT QoS McpttQosSwit PTT Uplink PUSCH

TDD management ch option of the RB reservation
CellAlgoSwitc for MCPTT
h.McpttSwitch voice services
parameter requires
MCPTT QoS
management.

None
10.3.3 Hardware
Base Station Models

No requirements
Boards
The LBBPc does not support this function.
RF Modules
No requirements
Cells
Uplink PUSCH RB reservation for MCPTT voice services cannot be enabled in cells with less
than 5 MHz bandwidth.
10.3.4 Others
None


Table 10-1 describes the parameters used for function activation.

RB Reserve Mode CellRbReserve.RbRsvMod The parameter specifies

e whether to reserve PUSCH
RBs for UEs performing
MCPTT voice services in
the uplink.
RB Reserve Type CellRbReserve.RbRsvType This parameter specifies the

RB reservation type. Set this
parameter to
UPLINK_MODE.
RB Reserve Start Index CellRbReserve.RbRsvStart This parameter specifies the

Index start position of the reserved
RB for UEs performing
the uplink.
RB Reserve End Index CellRbReserve.RbRsvEndI This parameter specifies the

ndex end position of the reserved
RB for UEs performing
the uplink.

//Turning on the MCPTT QoS management switch
MOD CELLALGOSWITCH: LOCALCELLID=0, McpttSwitch=McpttQoSSwitch-1;
//Enabling PUSCH RB reservation for UEs performing MCPTT voice services in the
uplink
ADD CELLRBRESERVE: LOCALCELLID=0, INDEX=0, RbRsvMode=MCPTT_RB_RESERVED,
RbRsvType=UPLINK_MODE, RbRsvStartIndex=10, RbRsvEndIndex=19;

//Disabling PUSCH RB reservation for UEs performing MCPTT voice services in the
uplink
RMV CELLRBRESERVE: LOCALCELLID=0, INDEX=0;


This function can be activated for a single eNodeB or a batch of eNodeBs on the CME. For
detailed operations, see CME-based Feature Configuration.

Observe the counters L.UL.Interference.Avg.PRB0 to L.UL.Interference.Avg.PRB99,
which are used to measure the average interference and noise.
PUSCH RB reservation for voice service UEs has taken effect if the average interference and
noise on the reserved RBs are significantly lower than the average interference and noise on
the non-reserved RBs.

You can monitor the performance of this feature based on the performance counters described
in Table 10-2.
The number of UEs performing MCPTT voice services in a cell (1526745700 and
1526745701) and number of RBs used by these UEs (1526746006) are used to determine the
number of reserved RBs in a cell. The interference received by PRBs on the PUSCH
(1526730620 to 1526730719) helps determine the position of reserved RBs in a cell.
Table 10-2 Counters related to uplink PUSCH RB reservation for MCPTT voice services
1526745700 L.Traffic.User.MCPTT.Avg
1526745701 L.Traffic.User.MCPTT.Max
1526746006 L.ChMeas.PRB.UL.DrbUsed.Avg.QCI65
1526730620~1526730719 L.UL.Interference.Avg.PRB0 to
L.UL.Interference.Avg.PRB99

eRAN
PTT Feature Parameter Description 11 Parameters
11 Parameters
The following hyperlinked EXCEL files of parameter reference match the software version
with which this document is released.
l Node Parameter Reference: contains device and transport parameters.
l eNodeBFunction Parameter Reference: contains all parameters related to radio access
functions, including air interface management, access control, mobility control, and radio
resource management.
NOTE
You can find the EXCEL files of parameter reference for the software version on the live network from
the product documentation delivered with that version.
FAQ: How do I find the parameters related to a certain feature from parameter
reference?
Step 1 Open the EXCEL file of parameter reference.
Step 2 On the Parameter List sheet, filter the Feature ID column. Click Text Filters and choose
Contains. Enter the feature ID, for example, LOFD-001016 or TDLOFD-001016.
Step 3 Click OK. All parameters related to the feature are displayed.
----End

eRAN
PTT Feature Parameter Description 12 Counters
12 Counters
The following hyperlinked EXCEL files of performance counter reference match the software
version with which this document is released.
l Node Performance Counter Summary: contains device and transport counters.
l eNodeBFunction Performance Counter Summary: contains all counters related to radio
access functions, including air interface management, access control, mobility control,
and radio resource management.
NOTE
You can find the EXCEL files of performance counter reference for the software version used on the live
network from the product documentation delivered with that version.
FAQ: How do I find the counters related to a certain feature from performance counter
reference?
Step 1 Open the EXCEL file of performance counter reference.
Step 2 On the Counter Summary(En) sheet, filter the Feature ID column. Click Text Filters and
choose Contains. Enter the feature ID, for example, LOFD-001016 or TDLOFD-001016.
Step 3 Click OK. All counters related to the feature are displayed.
----End

eRAN
PTT Feature Parameter Description 13 Glossary
13 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

eRAN
PTT Feature Parameter Description 14 Reference Documents
14 Reference Documents
1. Admission and Congestion Control

2. ROHC
3. VoLTE
4. eMBMS
5. Intra-RAT Mobility Load Balancing
6. Inter-RAT Mobility Load Balancing
7. Carrier Aggregation
8. Scheduling
9. QoS Management
10. Interface Self-planning
11. S1 and X2 Self-Management
12. Access Class Control
13. DRX and Signaling Control
14. IPv4 Transmission
15. eMTC
16. Short TTI (FDD)
17. Compact Bandwidth (FDD)

PTT (Eran15.1 Draft A)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PTT (Eran15.1 Draft A)

Uploaded by

Copyright:

Available Formats

eRAN

PTT Feature Parameter Description

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. i

2 About This Document.................................................................................................................. 3

4 Enhanced Extended QCI............................................................................................................ 19

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. ii

4.4 Operation and Maintenance..........................................................................................................................................24

5 PTT over eMBMS........................................................................................................................ 30

6 MCPTT QoS Management........................................................................................................ 49

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. iii

6.4.1.2 Using MML Commands......................................................................................................................................... 52

7 Congestion Control for Public Safety......................................................................................57

8 RRC and DRX Policy for Public Safety...................................................................................71

9 MCPTT Voice Management...................................................................................................... 83

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. iv

9.2 Network Analysis......................................................................................................................................................... 83

10 Uplink PUSCH RB Reservation for MCPTT Voice Services............................................ 93

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. v

1.1 eRAN15.1 Draft A (2019-01-05)

Added uplink Modified the FDD l 3900 and 5900

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 1

Change Parameter Change RAT Base Station

Added counters. For None FDD l 3900 and 5900

Modified MCPTT Added the FDD l 3900 and 5900

Added the impacts None FDD l 3900 and 5900

Modified MML command examples. For FDD

Added the impacts of MCPTT QoS FDD

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 2

2 About This Document

2.1 General Statements

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 3

Feature Differences Between RATs

2.2 Applicable RAT

2.3 Features in This Document

Feature ID Feature Name Section

LBFD-131110 Support of PTT 4 Enhanced Extended QCI

LOFD-081218 Enhanced Extended QCI 4 Enhanced Extended QCI

LOFD-110201 PTT over eMBMS 5 PTT over eMBMS

LTROFD-111201 MCPTT QoS Management 6 MCPTT QoS

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 4

Feature ID Feature Name Section

LTROFD-111202 Congestion Control for 7 Congestion Control for

LTROFD-111204 MCPTT Voice Management 9 MCPTT Voice

This document describes the following TDD features.

Feature ID Feature Name Section

TDLBFD-110101 Support of PTT 4 Enhanced Extended QCI

TDLOFD-110230 Enhanced Extended QCI 4 Enhanced Extended QCI

TDLOFD-110203 PTT over eMBMS 5 PTT over eMBMS

TDLOFD-121103 MCPTT QoS Management 6 MCPTT QoS

TDLOFD-121104 Congestion Control for 7 Congestion Control for

TDLOFD-121106 MCPTT Voice Management 9 MCPTT Voice

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 5

2.4 Feature Differences Between FDD and TDD

LBFD-1311 Support of TDLBFD-11 Support of None 4 Enhanced

LOFD-0812 Enhanced TDLOFD-11 Enhanced None 4 Enhanced

LOFD-1102 PTT over TDLOFD-11 PTT over None 5 PTT over

LTROFD-11 MCPTT TDLOFD-1 MCPTT None 6 MCPTT

Issue Draft A (2019-01-05) Copyright © Huawei Technologies Co., Ltd. 6

FDD FDD TDD TDD Difference Section

LTROFD-11 Congestion TDLOFD-1 Congestion When the 7